权限机制范文（精选4篇）
权限机制 第1篇
移动互联网领域, Android智能手机的使用越来越广泛, 越来越多的用户习惯于利用手机来储存和处理私人及商业信息。Android应用市场上急剧膨胀的应用程序, 其滥用权限已越发严重, 在被315晚会曝光之后, 引起了用户的普遍担心。
目前已有的滥用权限的软件, 大多是在权限申请时申请过多的权限, 然后在后台执行一些特定的行为, 包括窃取用户隐私数据或者通过发送短信等方式消耗用户话费。曾有人提出了一种适用于Android手机平台的权限检测系统, 其通过反编译APK文件和解析Android Manifest.xml文件及设定筛选机制筛选出访问敏感权限的程序和APK文件, 但其只是简单的检测, 并不能进行有效控制。
1 Android系统的权限控制机制
基于权限的安全策略是Android系统安全机制的重要组成部分, 采用权限机制可以限制应用程序的能力, 主要是允许或拒绝应用程序访问受限的API或者系统资源, 应用程序要想访问对应的资源必须申请对应的permission, 应用程序通过在Android Manif-est.xml文件中使用
该权限机制存在的问题, Android在安装应用程序时不能有选择性的同意和拒绝应用程序申请的权限, 只能被迫全部接受以完成安装或拒绝而无法安装, 这种粗粒度的权限机制注定给用户隐私泄露带来了安全隐患。
2 Android系统权限控制机制缺陷的验证
2.1 实例分析
为了验证Android系统的权限控制机制存在的问题, 本文开发了一款音乐播放器, 该软件宣传的功能只是简单的本地音乐播放, 但实际上其还拥有窃取用户短信、通讯录、通话记录等功能。
2.2 实现原理
通过分析, 该软件通过在播放器所需操作的基础上额外添加多余操作并在Android Manifest.xml里面申请多余的权限, 以此达到窃取用户隐私的目的。工作流程图如图1所示。
程序运行, 其中主线程内进行正常的音乐播放。线程2内为:开启Service服务2, 首先读取联系人、通话记录、短信, 并通过短信程序发送到预先指定的号码, 这是为了窃取手机上已有的隐私信息 (联系人、通话记录、短信) , 同时监听接收短信的广播, 如果收到该广播, 则获取短信内容, 并发送到指定号码, 这是为了窃取手机新收到的短信。线程3内为:开启服务3, 使用Content Observer分别监听通讯录、通话记录、短信数据库变化, 如果监听到通讯录和通话记录数据库有变化, 则获取变化的内容, 并通过短信发送到指定号码, 这是为了窃取通讯录、通话记录更新的数据, 如果监听到短信发件箱数据库有变化, 且目的地号码不是指定号码, 则获取变化的内容, 并通过短信发送到指定号码, 这是为了将用户自己新发送的短信窃取到指定号码。最后短信发送完毕之后, 为了不在短信发件箱内留下痕迹和证据, 需要将发件箱中指定号码的内容删除。
该软件申请的权限如表1所示, 从上面的实例分析, 可以看出该音乐播放器通过申请过多的权限以及相应的操作, 可以实现窃取用户手机上的通讯录、通话记录、短信息, 这些都是在用户未察觉的情况下进行的恶意功能, 这也充分说明Android系统自带的权限控制机制存在着问题, 普通Android用户如果没有其他安全软件进行辅助, 很难控制恶意软件对手机的恶意操作。
3 一种有效控制应用程序滥用权限的方法
Android市场上比较流行的权限控制软件主要分为两类:安装时控制和运行时控制。这里以软件“APK权限修改器”作为安装时控制的代表, 以软件“LBE安全大师”作为运行时控制的代表, 本文先分析这两类权限控制软件的优缺点, 如表2所示, 然后在其基础上进行结合和改进。
(1) APK权限修改器
这是一款用来在Android应用程序安装时, 对安装的程序进行权限修改的软件, 对不想授予的权限选择, 然后点击去除权限安装, 则该软件即对应用程序的Android Manifest.xml配置文件修改, 并重新打包和签名, 再进行安装去除了权限的软件, 实现对应用程序的权限的控制。
APK权限修改器的不足:没有自定义默认权限控制策略, 自身不能主动的控制应用程序申请的权限, 只能是用户人为的对申请的权限进行控制, 这样必然加重用户的负担以及给非专业用户带来安全隐患。解决方法:引入Kirin策略可用于检测要求危险权限组合的程序, 即在程序安装时引入了静态分析策略, 在检测时如果检测到满足策略的权限即主动拒绝该权限, 减轻了用户的负担, 以及提高了设备的安全性。
(2) LBE安全大师
LBE安全大师功能强大, 这里只分析其控制权限的功能, LBE运行时, 本文的音乐播放器和平时一样正常安装, 但是LBE会在音乐播放器安装结束之后自动按照LBE自带的权限控制策略对音乐播放器申请的各种权限进行控制, 有允许、提示、拒绝三种选择, 同时手机用户可以在任何时间打开LBE按照自己的意愿主动对音乐播放器申请的权限进行配置, 然后LBE会在音乐播放器运行时按照前面配置的权限进行控制对系统API的访问。
LBE安全大师的不足:只能对应用程序申请的部分权限进行控制, 如不能对SD卡的读写进行控制, 以及自带的默认权限控制策略比较简单, 如对申请的android.per-mission.READ_PHONE_STATE一律允许, 对申请的联网权限一律允许, 对其他申请的权限基本都是提示, 直接拒绝的权限没有, 即权限控制策略过于简单。解决方法:增加LBE内部需要控制权限的数据库和策略集, 实现对所有申请的权限都可以进行控制。
所以结合二者的优点, 并改善它们的不足:加入静态分析策略Kirin、改进动态分析策略集, 那么一个新的控制Android应用程序滥用权限的系统设计将能够很好的解决目前的问题。基于如上分析, 设计了系统运行的流程图, 如图2所示, 设定设计的权限控制系统名为A。
4 实验结果与分析
实验在Android SDK2.3.3模拟器上进行了测试, 并在华为C8650真机上进行了应用检测, 有程序申请安装时触发A, 运行效果如图3所示, 打开A主界面对本文已安装的音乐播放器进行权限控制, 运行效果如图4所示。本文中主要进行了功能测试, 即系统能否检测出访问敏感权限的恶意程序, 并加以控制。从Android应用市场下载了40个程序进行测试, 它们有浏览器、多媒体播放器、游戏等, 经检测, 多达一半以上的应用程序都申请了多余的权限, 而本文设计的权限控制系统对这些程序的滥用权限行为都进行了有效的控制。
本文设计克服了APK权限修改器没有默认权限控制策略而给用户带来负担的缺点, 也克服了LBE安全大师不能对所有申请的权限进行控制 (如不能对SD卡的读写进行控制) 而给用户带来安全隐患的缺点。
5 结束语
本文以作者开发的音乐播放器为例对Android系统的权限控制机制缺陷进行了验证, 分析了Android市场上现有的两类权限控制软件的不足, 提出了加入静态分析策略Kirin和改进动态策略集的改进方法, 并进行了验证, 基本达到了预期的效果, 但系统仍有一些不足, 如加入的静态分析策略可能阻止某些合法软件的安装, 造成误判, 而且系统性能方面还需要优化, 下一步将对这些不足加以改进。
摘要：针对Android应用程序滥用权限造成用户隐私泄露的问题, 开发了一款音乐播放器为实例, 分析了其恶意操作的原理, 反映了Android自身安全机制存在着不足, 然后分析了Android市场上两类权限控制软件的优缺点, 在此基础上结合两者的优点, 并加以改进, 加入了静态分析策略kirin, 改进了动态分析策略集, 设计了一款对权限滥用进行有效控制的系统。
关键词：Android,权限,恶意操作,控制,静态分析策略
参考文献
[1]Enck W, Ongtang M, Mcdaniel P.On lightweight mobile phone application certification[C]//Proc of the 16th ACM Conference on Computer and Communication Security.New York:ACM, 2009:235-245.
[2]21CN财经综合.央视315曝光安卓手机软件盗取用户信息[Z/OL]. (2013-03-15) .http://finance.21cn.com/news/cjyw/a/2013/0315/23/20688218.shtml.
[3]闫梅, 彭新光.基于Android安全机制的权限检测系统[J].计算机工程与设计, 2013, 34 (3) :854-858.
[4]蒋绍林, 王金双, 张涛, 等.Android安全研究综述[J].计算机应用与软件, 2012 (10) :205-210.
[5]李中平, 邱健峰, 李璐, 等.Android手机远程控制关键技术分析[J].计算机应用与软件, 2013, 30 (4) :113-115, 127.
[6]杨珉, 王晓阳, 张涛, 等.国内Android应用商城中程序隐私泄露分析[J].清华大学学报:自然科学版, 2012, 52 (10) :1420-1426.
权限机制 第2篇
关键词：云存储,密文访问控制,权限撤销,动态重加密,CP-ABE,DR-PRO
0引言
随着云存储技术的不断发展,其云存储服务逐渐受到个人和企业用户的青睐。与此同时,云存储中用户数据保护与服务性能问题也得到产业界与学术界越来越多的关注。为了满足云存储服务中用户数据保护的安全性需求,引入密文访问控制机制,用于保证用户数据存储与共享应用安全[1]。但是,密文访问控制机制增加了云存储用户的计算与带宽代价,特别是在用户访问权限更改次数过多的情况下,间接降低了云存储服务访问的效率与处理性能,造成用户访问延时等。因此,在保持云存储服务中用户数据高安全性的条件下,如何有效解决用户权限撤销代价过大、复杂度过高等问题,成为云存储数据信息安全保护的热点研究方向。
近年来,国内外研究学者已开展了深入研究,如文献[1]提出一种基于完全重加密的用户访问权限撤销机制,在将用户数据信息传输至云存储服务器之前,此机制对云存储用户数据信息统一进行重加密,进行权限撤销时,数据拥有者再次重新加密全部数据信息。尽管保证了云存储服务中用户数据信息的高安全性,然而完全重加密其计算与带宽代价过大,出现很大的云存储服务性能瓶颈;文献[2]提出一种懒惰重加密的用户访问权限撤销机制,试图改变完全重加密代价过大的问题,但是,在云存储服务用户数据信息安全性上确有所降低,该机制只能应用于用户数据访问权限要求不够严格的情况下;文献[3]与文献[4]分别提出一种基于双层重加密与代理重加密的用户访问权限撤销机制,此类机制均需要一个假设的可信第三方,主要用于完成用户访问权限撤销过程中的数据重加密工作,处理部分数据拥有者指定的操作步骤,目的是为了降低密文访问控制机制带来的计算与带宽代价,然而,此类机制可能会暴露或泄露操作的详细用户数据,存在一定的安全风险;基于代理重加密算法,研究学者们提出了众多改进的代理重加密算法[5,6,7],此处不过多描述;文献[8]提出一种密钥撤销的用户访问权限撤销机制,与前面的各种重加密算法不同,该机制中的密钥表示的是用户特征,通过撤销用户特征实现对用户访问权限的撤销,其优点是权限变更频繁时,仍能保持简洁的访问控制模型,并有效降低了重加密算法中的计算与带宽代价,缺点在于其密钥撤销技术实现难度大;在文献[8]的基础之上,文献[9]设计出一种基于身份加密的用户访问权限撤销机制,但不能应用于CP⁃ABE密文访问控制方案;基于密钥撤销技术,研究学者们同样设计出很多改进的用户访问权限撤销机制[10,11,12],但均存在一定的局限性。
针对上述问题,本文以CP⁃ABE密文访问控制作为方案背景,提出一种基于动态重加密的云存储权限撤销优化机制,即DR⁃PRO。该机制利用(k,n)门限方案,将数据信息划分成若干块,动态地选取某一数据信息块实现重加密,依次通过数据划分、重构、传输、提取以及权限撤销等子算法完成用户访问权限撤销实现过程。理论分析与实验评估表明,在保证云存储服务数据高安全性的前提下,DR⁃PRO机制有效地降低了用户访问权限撤销的计算与带宽代价,其性能效率得到了进一步优化与提高。
1(k,n)门限方案
(k,n)门限方案可以将整个数据信息F划分为n份不同的共享数据块,假设某个人获取到n份共享数据块中的k份,那么说明可以重构F。与之对应,若获取的共享数据块少于k份,那么就缺少有效数据信息,不可以重构F。(k,n)门限方案可以存储数据拥有者的有效信息,存储具有持久性、高安全性,并且无需维护相关密钥信息。所以,(k,n)门限方案被广泛应用于存储系统中。
正是基于(k,n)门限方案的存储持久性、高安全性的特点,在云存储权限撤销优化机制中引入了(k,n)门限方案中k=n时的特定情况,即将整个数据信息F划分为n份不同的共享数据块之后,只有完全获取到n份共享数据块才可以重构F,此时也称之为(n,n)门限方案。(n,n)门限方案的实现方式可以是两种:第一种可以直接指定k=n或丢失n-k份共享数据块;第二种就是直接形成一个(n,n)门限方案。假设D表示共同拥有的秘密信息,第一步随机产生n-1个与D相同大小的信息X1,X2,⋯,Xn;第二步通过X1⊕X2⊕⋯⊕Xn-1⊕D获取Xn;第三步获取D的n份共享数据块X1,X2,⋯,Xn。除了上述特点之外,(n,n)门限方案可以动态地选取某一数据信息块实现重加密,进行用户访问权限撤销处理时,其计算与带宽代价降低至完全重加密的1 n,同时也有效降低了秘密共享代价。
与此同时,研究学者们基于(k,n)门限方案设计出很多存储空间利用率更高的改进门限方案。如文献[13]设计出一种数据分散算法,其所需存储空间更小,其计算与带宽代价得到提升,然而其数据安全性逊色于(k,n)门限方案;文献[14]设计出一种新型的信息编码机制,实现原理与(n,n)门限方案类似,因此又称为(n+1,n+1)门限方案,此机制的信息编码性能较高,复杂度较低,在数据安全应用中得到广泛推广。
2 DR⁃PRO机制
2.1动态重加密
动态重加密是处于完全重加密与懒惰重加密之间的一种折中机制,分别汲取了各自优势,其基本原理如下:结合某种编码运算技术,首先将整个数据文件F划分成n份不同的共享数据块,然后将其传输至云存储服务器;对F进行重加密操作时,动态地选取某一共享数据块进行实现,用于代替重加密全部数据文件。如图1所示,其中静态数据表示F中无需重加密部分,相对应,动态数据表示F中需要重加密部分。
2.2云存储权限撤销优化算法
以CP⁃ABE的密文访问控制方案作为理论背景,动态重加密机制可通过相关数据流程子算法加以实现,主要由数据划分、重构、传输、提取以及权限撤销等子算法完成用户访问权限撤销的实现过程。
2.2.1数据划分子算法
此处基于文献[14]中的信息编码机制,对文献[13]中的数据分散算法进行改进实现。
(1)使用文献[14]中的信息编码机制完成数据文件F的编码运算;
(2)使用文献[13]中的数据分散算法将编码运算结果划分为n份不同的共享数据块。若数据文件F有t字节大小,字节长度是w比特,E表示基于密钥的数据加密算法,其数据划分子算法伪代码如下:
算法1:数据划分子算法
编码运算结果ct+1可应用于数据信息完整性校验操作。从本质而言,数据划分子算法相当于(n,n)门限优化方案。
2.2.2数据重构子算法
与数据划分相对应,数据重构是其逆向操作,其数据重构子算法的伪代码如下:
算法2:数据重构子算法
2.2.3数据传输子算法
数据文件F被划分之后,传输至云存储服务器中需要通过数据传输子算法实现,其算法伪代码如下:
算法3:数据传输子算法
2.2.4数据提取子算法
由于原始数据文件F已被加密处理,当被传输至云存储服务器之后,URL标识无需进行数据保护,全部数据用户均可以获取URL标识,但只有对应权限的数据用户才能解密提取原始数据文件F。其数据提取子算法伪代码如下:
算法4:数据提取子算法
数据文件F传输至云存储服务器之后,用户可能因某种原因需更新数据文件F相对应的访问控制结构T,此时需要对用户权限进行授予操作。
2.2.5权限撤销子算法
基于动态重加密的权限撤销实现细节较为复杂,用户需先对E′T(K1+K2)进行提取,然后对动态数据进行重加密操作,其中动态数据是随机选取的。其算法伪代码如下:
算法5:权限撤销子算法
3理论分析与实验评估
3.1安全性分析
DR⁃PRO机制的安全性分析主要包括以下两个部分。
3.1.1密文安全性
数据文件F传输至云存储服务器之后的密文种类主要有E′T(K1+K2),与s1,s2,⋯,si-1,si+1,⋯,sn。E′T(K1+K2)是通过基于CP⁃ABE的云存储密文算法产生而来,符合可证安全性要求。s1,s2,⋯,si-1,si+1,⋯,sn是由文献[14]的信息编码机制计算获得,若无si,攻击者只可以获取si,而得不到有效数据信息,所以说明s1,s2,⋯,si-1,si+1,⋯,sn具有计算安全性。对于而言,整个权限撤销实现过程进行了两次加密操作,现依次进行分析。
第一次加密是在信息编码环节,数据文件F编码运算时采取的密钥信息K1是基于CP⁃ABE加密产生的。因此,攻击者只有同时获取K1与s1,s2,⋯,sn时,才有可能重构数据。即使这样,攻击者得到了si,仍需破解K1才可以获取si中的有效数据。破解K1的惟一方式只有枚举法,假定K1是w′比特长度,那么攻击者破解K1的复杂度是2w′。所以,在信息编码环节的加密操作是具有计算安全性的。
第二次加密是在数据划分环节,首先通过数据划分子算法,数据文件F被划分成n份不同的共享数据块;其次,对si进行对称加密操作。攻击者只有得到s1,s2,⋯,sn才可以重构数据。si通过(n,n)门限优化方案编码产生,具有计算安全性,并且对称加密的密钥信息K2是基于CP⁃ABE加密产生的,具有可证安全性。所以,攻击者破解si与K2,同样需要通过枚举法,其复杂度太大。从而说明,在数据划分环节的加密操作具有计算安全性。
3.1.2动态重加密安全性
主要从以下两种常见攻击方式着手,分析基于动态重加密的DR⁃PRO机制的安全性。
(1)不可信CSP攻击。若不可信CSP具有长期存储数据能力,在数据文件F传输至云存储服务器之后,即使移除了数据信息,仍有可能实现数据恢复。在数据传输环节,对CSP而言,数据文件F的安全状态转换如图2所示。当数据文件F传输至云存储服务器时,CSP不可以得到有关F的有效数据,处于锁定状态。当权限撤销完成实现之后,用户重加密sj用于替换ET(si)。若i≠j,那么CSP可以得到si与sj,即获得s1,s2,⋯,sn。然而,CSP无法获取K1,无法重构数据。对CSP来说,F的安全状态转换成信息编码锁定。
(2)用户恶意非授权攻击。若用户具有一定的缓存能力,如可缓存密钥信息等。一般情况下,用户不具备完全限制数据缓存能力,对用户而言,数据文件F的安全状态转换如图3所示。在用户被授权可访问数据之前,数据文件F一直处于锁定状态。在访问授权之后,用户依次获取了E′T(K1+K2),K1,K2以及F,安全状态转换成打开。在权限撤销实现过程完成之后,用户进行动态重加密处理,调整K2且重加密动态数据,F的安全状态转换成数据划分锁定。
通过上述分析可知,在不可信CSP与用户恶意非授权攻击方式下,基于动态重加密的DR⁃PRO机制具有较高的计算安全性。
3.2性能分析
结合数学形式化思维对基于动态重加密的DR⁃PRO机制进行优化性能分析。设置相关常变量参数,如表1所示。
假定Tsplit表示数据划分所需的时间长度,可知:
假定Treconstruct表示数据重构所需时间长度,可知:
假定Ttransfer,Tretrive分别表示数据传输与提取所需时间长度,依据Tsplit与Treconstruct,在E′T(K1+K2)=K1+K2的前提下,可知:
假定Trevoke表示权限撤销所需时间长度,计算如下:
此处将与文献[1]与文献[2]提出的权限撤销机制进行性能比较。假定100 MB的数据文件F,划分块数为10,(n,n)门限方案的编码速度是50 MB/s,有N=13 107 200,n=10,Eida=Dida=50,那么基于动态重加密的DR⁃PRO机制与文献[1]与文献[2]提出的权限撤销机制性能对比如图4所示。
从图4可知,基于动态重加密的DR⁃PRO机制是文献[1]与文献[2]提出的权限撤销机制之间的折中方案。在权限撤销环节,DR⁃PRO机制性能高于文献[1]机制,尽管文献[2]机制计算与带宽代价较低,然而其安全性最差。在数据传输与提取阶段,DR⁃PRO机制由于补充了数据划分与重构处理,其时间代价较高,然而降低了本身计算与带宽代价。
用户总时间代价是数据传输与权限撤销时间代价的总和:
假定x表示重加密次数,当达到某一阈值xi时,DR⁃PRO机制优化能力逐渐得到体现。如图5所示。
3.3实验与结果分析
此处基于C++的CP⁃ABE的密文云存储平台对DR⁃PRO机制进行性能测试实验,平台运行在Linux环境下。测试实验过程中需引用部分算法实现,如AES⁃192,SHA⁃256等;需添加CP⁃ABE工具库[15],完成CP⁃ABE加密;需结合信息划分算法开源示例,完成(n,n)门限方案的实现。
实验原型平台由一个服务器端运行程序与客户端运行程序组成,用户执行服务器端运行程序,可完成数据传输与权限撤销环节;用户执行客户端运行程序,可完成数据提取环节。在服务器端实现CP⁃ABE算法,服务器端运行程序与客户端运行程序均由单线程实现,云存储平台使用Hadoop的HDFS,将其安装运行在Ubuntu系统上。实验设备所需配置要求如表2所示。
由于密钥相对于数据文件而言,大小可忽略不计。因此实验中不考虑密钥存储代价,只关注动态重加密存储代价。
此处仍使用文献[1]与文献[2]的重加密机制与本文DR⁃PRO机制进行实验对比。现考虑以下两种实验情况,如图6,图7所示。
(1)数据文件F大小逐渐增加,数据块大小保持不变。从图6中可知,尽管DR⁃PRO机制中数据传输与提取环节的计算与带宽代价均高于文献[1]与文献[2]中重加密机制,但其权限撤销环节的计算与带宽代价远小于文献[1]的重加密机制,并长期保持稳定水平。
(2)数据文件F大小保持不变,数据块大小逐渐增加。从图7中可知,当数据文件被划分成共享数据块的个数逐渐增加时,文献[1]的重加密机制的权限撤销始终保持较高代价,而DR⁃PRO机制的权限撤销代价逐渐降低,其性能得到进一步优化。
4结语
权限机制 第3篇
关键词：云存储,密文访问控制,权限撤销,动态重加密,密文策略的属性加密体制,动态重加密的云存储权限撤销优化机制
近年来，随着云存储技术的日益发展，与之相关的服务同样开始受到业界人士的关注。另一方面，用户数据保护与服务性能等方面的知识同样获得业内的青睐。为使数据保护安全性需求得到满足，密文访问控制机制被用来应对这一个问题。然而，这一个方法却在很大程度上提高了用户的成本，尤其是当其访问权限更改次数太频繁的时候，使得云存储服务性能有了一定程度的降低，且引发一系列的问题，例如访问延时等。鉴于这一个方面的原因，在充分确保用户数据高安全性的前提下，怎样科学合理地应对权限撤销成本太高、太过繁琐等相关问题，已经发展为该领域的一个重要课题。
关于这一个课题，业界大量专家展开细致的探讨，取得大量有益的成果，有学者[1]在研究过程中阐明了架构于完全重加密之下的用户访问权限撤销机制，在把用户信息传到云存储服务器前，由这一机制负责重加密工作，当实施用户权限撤销的时候，用户可以对所有数据进行重新加密。这一个机制虽然充分确保了数据安全性，但是这种方法所需要的计算和带宽成本相对较高，这属于其中的一大弊端。基于前者的成果，还有学者[2]在研究过程中阐明了懒惰重加密的机制，在研究过程中，他们希望将文献[1]所提出方法的成本太高这一问题解决，然而，却在一定程度上降低了安全性，鉴于这一个方面的原因，这一个机制只有在对访问权限要求相对较宽松的时候才较为适用。还有相关专家[3,4]在研究过程中，依次阐明了基于双层重加密与代理重加密的机制，这两个方法都必须一个假设的可信第三方，旨在尽可能地减小计算与带宽等方面的成本，但是，这种方法同样存在着一定的不足之处，其有暴露有关信息的可能性，因此，具有或多或少的风险;对文献[4]提出的机制，许多相关专家在研究过程中阐明了优化的算法[5,6,7]，在这里我们不再一一赘述。除此之外，还有专家[8]在研究过程中阐明了基于密钥撤销的机制，与上文中阐述的机制存在着一定的差异，这一个算法之中的密钥是指用户特征，主要是利用撤销密钥的方式来完成对访问权限的撤销，这种算法具有其自身的优势:当用户权限频繁变更的时候，依旧能够保持相对简单的特点，同时在很大程度上缩减了计算与带宽成本，但其也存在一定的不足之处:实现其密钥撤销并非易事。基于前者[8]的研究结果，还有学者[9]在研究过程中阐明了基于身份加密算法，然而该种算法无法在CP-ABE密文访问控制方案之中使用;对这种算法，业界专家人士也进行了一系列的探索，阐明了大量的优化算法[10,11,12]，但都或多或少存在着不足之处。
根据上文中的各种问题，我们在这里主要以CP-ABE密文访问控制为基础，阐明了基于动态重加密的云存储权限撤销优化机制(本文简称为DR-PRO)。这一个算法主要通过(k,n)门限方案来对数据进行分类，将其分为几个块，从中确定某块来进行重加密，利用各种子算法来实现访问权限撤销。通过进一步的研究发现，在充分确保高安全性的基础上，这一个算法在很大程度上减少了计算与带宽代价，同时使其性能明显提升。
1(k,n)门限方案
这一个方案能够实现进一步细分数据信息F，将其分成n个的共享数据块，假设某人得到其中的k个，在这种情况下，则表示能够重构F。相反地，如果得到的块的数目在k份以下，则表示有效数据信息不足，无法实现重构F。这一个方案能够对数据拥有者的有效信息进行存储，同时其安全性相对较高、且相对持久，除此之外，不需要对有关密钥进行维护。鉴于这些原因，这一个方案在存储系统之中非常普及。
恰恰是因为这一个方案所具有的上述优点，在云存储权限撤销优化机制之中对其进行应用，也就是把F分成n份以后，当获得n份的时候才能够重构F，该种特殊情况还叫做(n,n)门限方案。具体来说，其能够通过下面两种方式实现，其一，能够指定k=n或丢失n-k份共享数据块;其二，形成(n,n)门限方案:假定D是指共同具备的秘密信息，首先随机形成n-1个和D一样大小的信息X1,X2，…，Xn，其次，利用X1X2…Xn-1D获取Xn，其次获取D的n份共享数据块X1,X2，…，Xn。不仅如此，(n,n)门限方案还能够随机确定其中的数据信息块对其进行重加密，访问权限撤销的过程中，其计算与带宽代价大幅减少，减小到完全重加密的1/n，另一方面，还在很大程度上缩减了秘密共享代价。
除去以上算法，相关专家人士在研究过程中，基于(k,n)门限方案提出一系列的优化方案。例如，有专家[13]在研究过程中阐明了数据分散算法，这种技术需要相对较小的存储空间，同时在很大程度上降低了计算与带宽代价，但是其安全性相对较差，比不上(k,n)门限方案。还有专家[14]在研究过程中阐明了信息编码机制，其具体的机理大致上和(n,n)门限方案相同，正是由于这个原因，才被叫做(n+1,n+1)门限方案，其具有非常明显的优势:相对简单、具有较高的编码性能，因此得以逐渐普及。
2 DR-PRO机制
2.1 动态重加密
具体来说，这是集合了懒惰与完全重加密两者优势的算法，该种算法主要原理见下文所示。
结合编码运算方法，第一步，把F分为n份不同的共享数据块，在此基础上，把它向云存储服务器传送。第二步，重加密F，在这个过程中，随机从中确定某数据块来实现，用于将重加密所有数据文件替代。具体见图1，静态数据是指F里面不需要进行再次加密的内容，同样动态数据就指F中需进行加密处理的内容。
2.2 云存储权限撤销优化算法
把CP-ABE当做参考依据，动态重加密机制能够利用一系列子算法来完成，具体我们将在下文中一一阐述。
2.2.1 数据划分子算法
在这里我们主要参考相关专家[14]提出的信息编码机制，来进一步优化相关文献[13]提出的算法。首先，通过文献[14]在研究过程中提出的算法来对F实施编码运算，其次，通过文献[13]在研究过程中阐明的算法把结果进一步细分成n份。如果F大小是t字节，字节为w比特，E是指基于密钥的数据加密算法，其伪代码具体我们在下表中列出。
算法1:数据划分子算法
输入:F:m1,m2，…，mt;数据划分大小:n
输出:密钥信息K1，数据块:s1,s2，…，sn
1)求解F的完整性度量参数mt+1=hash(m1,m2，…，mt);
2)选择某临时密钥信息K，在E的加密运算中使用;
3)编码运算
4)获取同时满足以下公式:hi=hash(ci);
5)关联编码运算结果，把它当做(n,n)门限方案的输入参数;
6)按照[13]提出的算法，将n份:s1,s2，…，sn输出。
这样，ct+1能够在数据信息完整性校验之中使用。实质来说，数据划分子算法与(n,n)门限优化方案大致类似。
2.2.2 数据重构子算法
具体来说，数据重构是数据划分的反向过程，其伪代码我们将在下列表格之中阐明。
算法2:数据重构子算法
输入:K1，数据块:s1,s2，…，sn;
输出:F:m1,m2，…，mt;数据总有:n。
1)获取所有数据块s1,s2，…，sn，按照文献[13]里面提出的算法，对F进行重构;
2)划分重构数据信息:c1,c2，…，ct,ct+1;
3)获取同时满足以下公式:hi=hash(ci);
5)获取m't+1=hash(m1,m2，…，mt);
7)重构失败;
8)else;
9)重构成功，输出F:m1,m2，…，mt;
10)end if。
2.2.3 数据传输子算法
进一步划分F以后，接着把它传到云存储服务器中，利用数据传输子算法来完成，其伪代码具体如下。
算法3:数据传输子算法
输入:数据文件F:m1,m2，…，mt;数据划分大小:n
输出:数据存储位置，使用URL标识叙述
1)执行数据划分子算法，获取密钥信息K1与共享数据块s1,s2，…，sn;
2)选取其中某一个si,(1≤i≤n)作为动态数据;
3)选取某一个密钥信息K2;
4)执行
5)执行E'T(K1+K2)，且E'表示一个基于CP-ABE的云存储密文算法，T表示数据信息的访问控制模型;
7)输出与第6步的数据结果相对应的URL标识。
2.2.4 数据提取子算法
由于原始数据文件F已被加密处理，当被传输至云存储服务器之后，URL标识无需进行数据保护，全部数据用户均可以获取URL标识，但只有具备对应权限的数据用户才能解密提取原始数据文件F。其数据提取子算法伪代码如下。
算法4:数据提取子算法
输入:用户私钥信息SK,URL标识
输出:数据文件F:m1,m2，…，mt。
1)依据URL标识，得到
2)if SK的特征集合S不满足访问控制结构T then;
3)数据提取失败;
4)end if
5)执行E'T(K1+K2)，得到密钥信息K1与K2;
6)执行
7)依据K1与s1,s2，…，sn，执行数据重构子算法;
8)if数据重构失败then
9)数据提取失败;
10)else;
11)数据提取成功，输出数据文件F:m1,m2，…，mt;
12)end if。
数据文件F传输至云存储服务器之后，用户可能由于某种原因需更新数据文件F相对应的访问控制结构T，此时需要对用户权限进行授予操作。
2.2.5 权限撤销子算法
基于动态重加密的权限撤销实现细节较为复杂，用户需先对E'T(K1+K2)进行提取，然后对动态数据进行重加密操作，其中动态数据是随机选取的。其算法伪代码如下。
算法2-5:权限撤销子算法。
输入:数据文件F的访问控制结构T',URL标识。
1)依据URL标识，得到
2)执行E'T(K1+K2)，然后获得K1和K2;
3)执行得到si;
4)选取临时K;
5)设定K2=K，执行E'T(K1+K2);
6)选取临时标记j,j∈[1，…，n];
7)if i≠j then;
8)依据URL标识获得sj;
9)执行Ek2(sj);
10)更新传送到云存储服务器，将原有的移除;
11)else;
12)执行
13)更新到云存储服务器中，将原有的移除;
14)end if。
3 理论分析与实验评估
3.1 安全性分析
3.1.1 密文安全性
F至云存储服务器后的密文类型大体上包括以下几方面即利用基于CP-ABE的云存储密文算法获得的，其满足可证安全性要求。s1,s2，…，si-1,si+1，…，sn主要是通过学者[14]阐明的方法而来，如果没有si，攻击者仅仅能够得到si，并无法获得有效数据，这就暗示着s1,s2，…，si-1,si+1，…，sn满足计算安全性。就来说，权限撤销时实施加密操作两次，接下来我们将一一阐明。
在信息编码的时候进行首次加密，F编码运算过程中选择的K1主要是来自于CP-ABE加密。所以，攻击者在同一个时间内获取K1和s1,s2，…，sn的情况下，方可进行重构。就算如此，获得si之后，依旧需要破解K1才能够得到si里面存在的有效数据。在这里，只有枚举法能够破解K1，假定K1是w'比特长度，在这种情况下破解K1的复杂度为2 w'。因此，在这一个过程中具有计算安全性。
在数据划分过程中进行第二次加密操作，第一步，利用数据划分子算法将F分为n份。第二步，对si进实施对称加密。只有在攻击者获得s1,s2，…，sn之后才能够进行重构操作。si主要来自于(n,n)门限优化方案，其具有计算安全性，同时K2主要是来自于CP-ABE加密，具有可证安全性。因此，破解si和K2，也必须利用枚举法才能够进行，但是这个过程的复杂度很高。因此，在这一个过程中具有计算安全性。
3.1.2 动态重加密安全性
大体上从下面两个途径出发，来对这一个问题进行探讨。
(1)不可信CSP攻击。
如果该方式具有长期存储数据能力，当F被传送到云存储服务器后，就算是将数据信息移除了，同样存在实现数据恢复的可能。传输过程中，就CSP来说，F的安全状态转换我们将通过下图2进行具体描述。当F传到云存储服务器的时候，CSP无法获得F的有效数据，其保持锁定。当权限撤销以后，用户重加密sj，通过这种方式来将ET(si)替代。在这里，如果满足i≠j，在这种情况下CSP能够获得si和sj，也就是得到s1,s2，…，sn。但是，CSP却不能得到K1，也就是不能进行重构。就CSP而言，F的安全状态将变成信息编码锁定。
(2)用户恶意非授权攻击。
如果用户具备一定程度的缓存能力。通常来说，其没有完全限制数据缓存能力，就用户来说，F的安全状态转换我们将通过下图进行具体描述(图3)。在用户被授权可以对数据进行访问之前，F始终保持在锁定状态。授权以后，用户按照顺序就得到了E'T(K1+K2),K1,K2与F，在这种情况下就打开了安全状态。权限撤销以后，用户实施动态重加密操作，适当地对K2进行调整，同时进行重加密，这样F就进入到数据划分锁定状态。
综上所述，我们不难看出，在上面的两种方式之下，我们所提出的加密算法的计算安全性相对较为理想。
3.2 性能分析
下面将通过数学形式化思维对我们所提出的算法的实施性能分析。设置常变量参数，详细情况我们在表1之中进行列举。
假设Tsplit用来指代数据划分的时间，这样就会得到下面的式子:
假设Treconstruct用来指代重构的时间，那么则会得到下面的式子:
假设Ttransfer,Tretrive依次用来指代数据传输和提取的时间，按照Tsplit和Treconstruct，在E'T(K1+K2)=K1+K2的基础上，则会得到下面的式子:
假设Trevoke用来指代权限撤销的时间，那么可以通过下面的式子进行求解:
在这里，我们对文献[1]和文献[2]提出的两个算法加以对比分析。假设F大小为100 MB，将其分成10份，(n,n)门限方案编码为50 MB/s，在这种情况下，就会得出N=13 107 200,n=10,Eida=Dida=50，则我们所提出的算法和学者[1]和学者[2]阐明的算法的性能存在以下区别，具体见图4。
通过图形不难看出，我们所提出的算法属于文献[1,2]阐明算法的折中算法。权限撤销过程中，我们所提出的算法具有比文献[1]的算法更好的性能，虽然文献[2]提出的算法具有相对较低的计算和带宽代价，却具有相对较差的安全性。数据传输和提取过程中，由于本文所提出的算法在一定程度上对数据划分和重构处理进行了补充，它具有相对偏高的时间代价，但是却在很大程度上缩减了其计算与带宽代价。
用户总时间代价具体可以通过下面的公式进行计算:
假设x用来指代重加密次数，当达到某阈值xi时，所提出的新算法的优化能力将会不断反映出来。具体见图5。
3.3 实验与结果分析
在这里，我们主要利用C++的CP-ABE的密文云存储系统来测试我们提出的新算法，运行环境为Linux。测试的时候需引用部分算法，主要包括AES-192、SHA-256等，另一方面，还要添加CP-ABE工具库[15]，实现CP-ABE加密;除此之外，还要通过信息划分算法开源示例，来达到(n,n)门限方案实现的目的。
测试系统主要包括1个服务器端和客户端运行程序，数据传输与权限撤销过程主要通过执行服务器端运行程序来实现;另一方面，数据提取主要是通过执行客户端运行程序来实现。CP-ABE算法在服务器端实现，两者都通过单线程实现，云存储平台为HDFS。测试设备的配置我们通过下表进行描述(表2)。
与数据文件相对比来说，密钥非常小，可以不予考虑。正是由于这一原因，测试过程中可以忽略密钥存储代价，仅仅考虑动态重加密存储代价即可。
在这里，我们还是通过文献[1,2]提出的算法来和我们所提出的新算法进行对比分析。我们主要分析下列两个基本状况。具体见图6、图7。
第一，F不断增大，而数据块大小却始终处于固定状态。通过图6我们能够看出，虽然我们提出的新算法的在第一个环节的代价比学者[1,2]的算法高，然而在权限撤销过程中其代价却明显比学者[1,2]的算法低，同时始终处于相对稳定的状态。
第二，F保持固定，数据块不断增大。通过图7我们能够看出，数据块数目不断提高的时候，学者[1]提出的算法的权限撤销代价一直处于一个偏高的水平，但是我们所提出的新算法的权限撤销代价却不断减小，非常明显，其性能得以显著改进。
4 结束语
权限机制 第4篇
在软件项目的设计规划中, 权限系统的设计往往既要保证稳固性和可靠性, 以满足业务上的要求, 同时也要尽可能地考虑可维护性, 以适应未来需求的变化。在软件项目的设计规划中, 权限系统的设计往往既要保证稳固性和可靠性, 以满足业务上的要求, 同时也要尽可能的考虑可维护性, 以适应未来需求的变化。大多数权限需求的复杂性, 往往跟权限所处的组织机构、人事制度的复杂性密不可分。下面是某金融机构风险管理类系统的需求描述片段:
1.纪检监察、内审等监督部门及行领导可登录浏览本单位所有模块的信息内容。
2.上级行纪检监察、内审、事后监督、办公室 (包括法律事务) 等监督部门及行领导可登录浏览下级行的所有模块的信息内容。
3.业务部门经授权可浏览查看下级行对口业务部门信息。
4.下级行可登录浏览上级行的监督动态、规章制度2个模块信息, 不能浏览查看其他模块信息的具体内容。
5.用户可浏览本单位监督动态、规章制度等模块的信息, 不得浏览其它模块内容。
6.各单位的部门用户可登录本部门浏览本部门所有信息。部门操作员可登录系统录入、修改本部门的监督动态、规章制度、风险控制、部门检查、行领导检查和本部门各类统计表。对设置在部门的监督部门检查、上级行检查, 部门操作人员只可登录浏览, 不得修改, 由监督检查主体的操作员负责录入、修改。
可以看出, 项目的权限需求囊括了省市县所有的业务部门、不同的用户类型, 也隐含了复杂的上下级关系, 以及针对不同业务模块的访问限制。
需求分析首先要对角色 (Role) 和资源 (Resource) 进行剖析。一般来说, 把用户每次的操作目标理解为资源, 最后通过排除法化繁为简, 是比较聪明的做法。这样经过几次反复得出的资源角色矩阵, 并不是最终结果。我们还要考虑以下的一些因素。
第一, 资源与上下文的关系。比如模块和子模块的权限往往存在某种继承关系;又如页面中的同一个控件, 当处于不同的上下文时, 就会存在不同的行为。
第二, 角色与上下文的关系。比如想定义一个叫做“综合员”的角色, 希望该角色可以在大多数部门中拥有增删改查的权限, 但在某些特定部门中弱化其某些权限。常见的做法是把角色按部门进行细化:A部门综合员、B部门综合员N部门操作员, 然后分别定义其权限范围。其结果是角色定义凌乱, 管理成本上升。
第三, 简化配置环节。多而繁的配置环节是现在大多数权限系统的通病。根据经验很多权限的配置并不需要最终用户去干预, 而系统维护人员更青睐基于文本的管理方式。因此, 权限系统的设计要考虑尽量精简的用户接口, 提供更易于理解的可运维管理方式。
第四, URL访问控制。B/S系统中用户既可以通过菜单的方式访问系统, 也可以通过URL直接访问。URL的控制应该和菜单系统整合到一起, 共用统一的权限控制流程, 提供统一的访问入口, 提高了系统安全性。
基于上述问题, 我们引入资源权限树的概念。
二、资源权限树
B/S系统中的导航功能, 通常都是以XML为组织形式, 通过树的方式表达。在权限体系中, 权限所对应的资源, 也可以通过XML树的形式表示。因此, 把权衡树和导航树进行整合, 就可以形成以资源访问路径为依托的资源权限树。
首先来想象一下, 用户是如何访问系统资源的:用户登录授权获取用户权限获取和权限相关的导航菜单通过链接进入要访问的页面页面显示受控的内容。以此为前提, 得出以下几个关键问题:用户权限如何表达;导航菜单如何动态产生;页面该如何自我控制;URL的访问控制。
(一) 用户权限的表示
一般情况下, 用户权限都是通过角色来定义的。为了让角色的定义和上下文解耦, 我们把角色分解为“上下文+角色”。这里的上下文, 可以理解为一些权限系统中的分组或部门, 但使用起来更为灵活。用户登录授权后, 获得自己所属的上下文 (部门) 和角色 (多个) , 并组合成“上下文名:角色名”这样的角色表达式集合。角色表达式定义如下:
角色表达式=[上下文名:角色名], 例如:办公室:综合员。
(二) 导航菜单的生成
不同的用户权限, 应该获得不同的菜单。为此, 我们构建一棵大的菜单树 (XML) , 根据每条菜单的读/写/拒绝等操作, 赋予每一个操作所对应的权限表达式。权限列表定义如下:
权限表达式=[角色表达式1|角色表达式2|], 例如:办公室:综合员|监察室:综合员。
考虑到通用性, 这里的角色表达式允许通配符 (规则表达式) 。例如:“*:综合员”表示所有部门的综合员;“办公室:*”表示办公室中的所有人。
权限模块根据用户的角色表达式集合, 遍历菜单树进行过滤。最终生成和用户权限对应的菜单, 返回给前台页面。
(三) 页面的权限控制
最终生成的菜单树, 根据权限比对结果 (true/false) , 返回页面所需要的控制标志位。例如:办公室的综合员, 权限模型解析到
(四) URL访问控制
把以上的方式和URL地址进行绑定, 可以实现URL级的访问控制。例如:在J2EE中通过定义拦截器的方式来捕获用户的URL, 并通过和菜单树进行权限匹配, 从而动态判断用户是否拥有访问当前URL的权限。
三、规则引擎
规则引擎是一种中间件技术, 实现了将业务决策从应用程序代码中分离, 使用预定义的语义编写业务规则, 并根据业务规则做出业务决策。其基本的原理是通过把决策数据输入到推理引擎中, 通过和知识库中的规则进行一系列复杂的比对运算, 最终输出为某一特定的决策路径。在这个过程中, 决策数据可以基于规则被改变, 从而实现知识库不断的自我完善。
规则引擎的另一大优势是支持动态加载。这样, 通过在运行时改变配置可以实现业务规则的动态改变。
(一) 部门的规则设置
在上文中我们使用了“[部门名:角色名]”这样的形式定义了角色表达式。在权限系统中这里的“部门名”是一类部门的简称, 例如用“人事”来表示“人事科 (市) 、人事处 (省) 、人事司 (总) ”等同一类部门。
又比如, 报表中需要获取部门所在地区的省/市/县级别, 从而在标题中给出分行/中支/支行等相应抬头。常见做法是把这些跟部门相关的属性放到部门表的字段中进行维护, 然而随着需求复杂性的提高, 维护的难度也越来越大。事实上, 通过规则引擎可以获取更灵活的解决方案。
规则引擎需要一个输入。我们定义代表部门的GroupInfo类对象作为输入, 然后我们定义一系列规则, 例如:如果部门名包含“人事”两个字, 那么就定义其简称为“人事”, 如果其名称中包含“中心支行”, 那么其级别就是“中支”等。这样, 经过规则的动态运算后, GroupInfo对象获取了我们需要的属性。规则文件有自己的语法, 接近于自然语言, 由引擎负责解释并动态执行, 我们随时可以修改规则以适应需求变更。
(二) 用户角色的自动生成
利用规则引擎在用户登录后为用户生成角色集合。需要同时传入UserInfo和GroupInfo两个类对象作为输入, 经过规则运算生成属于当前用户角色表达式集合。
使用规则引擎的另一个好处是可以在规则引擎中随时引入规则的特例。
(三) 规则引擎的调用流程
在J2EE应用中, 规则引擎有着以下的生命周期:
系统加载时, 加载规则引擎;加载部门数据, 调用规则引擎解析部门规则, 获取部门的规则定义;用户登录时, 调用规则引擎获取当前用户的角色列表;当规则文件被修改, 规则引擎感知变化, 重新解析规则文件。
