罗王平 , 冯朝胜 , 秦志光 , 袁 丁 , 廖娟平 , 刘 霞
1(四川师范大学 计算机科学学院,四川 成都 610101)
2(网络与数据安全四川省重点实验室(电子科技大学),四川 成都 610054)
对于企业信息中心而言,如果要将数据存储外包给公有云并同时保证数据安全性和隐私性,一般做法为:将数据加密后再上传到云端.但如果企业信息中心还想利用这种外包模式构建文件共享框架,问题将变得非常复杂.
解决外包云数据共享的一般方案是:用每个共享用户的公钥加密数据加密密钥,然后将加了密的数据加密密钥发送给共享者.显然,这种方法的代价过大:计算量和通信量都和共享用户的数量成正比,使得它难以实施.针对这个问题,学术界提出了一种称为密文策略的基于属性的加密算法CP-ABE(ciphertext-policy attribute-based encryption).由于该算法包含的访问控制方法类似于企业信息系统常用的基于角色访问控制方法RBAC(rolebased access control),且具有“一次加密,多人分享”的特点,因此,在外包数据共享中具有可实施性.然而,该算法要求运算量较大的加解密运算都由用户客户端负责且由较多私钥子项组成的用户私钥也都由用户保管,这对其实施特别是在移动设备上的实施造成阻碍.针对这一问题,利用公有云中的云计算服务器来分担大量的计算工作和存储全部用户私钥,提出一种面向公有云环境的密文共享方案.本文的具体贡献包括:
(1) 提出一种面向公有云的文件共享框架.在该框架中,共享数据的数据加密密钥先要基于安全存储访问结构树在用户客户端进行加密.共享时,由云服务器分担近一半文件共享访问结构树对应密文子项的计算.访问结构树的叶子节点不仅可以对应属性,还可以直接对应用户标识符,使得该方案同时支持基于属性的共享和基于身份的共享.
(2) 设计一种面向公有云的文件共享方案.基于所提出的文件共享框架和经典的CP-ABE 算法,设计一种具体的可实施的面向公有云的文件共享方案.在该方案中,构成用户私钥的绝大多数私钥子项由云服务器进行存储,用户只需要安全存储两个私钥子项.
(3) 证明方案的有效性.安全性分析表明,所提出的方案和经典的CP-ABE 具有相同的安全性.性能分析则表明,该方案在计算量和存储量上对用户客户端要求很低,个人电脑和移动设备亦能胜任.
本文首先指出云密文共享存在的主要问题及解决思路并说明主要贡献.第1 节对密文策略基于属性加密算法的研究现状进行总结,并分析其优缺点.第2 节提出一种面向公有云的密文共享框架.第3 节基于所提出的共享框架,构建一种面向公有云的密文共享方案.第4 节从安全性和性能上对所提出的共享方案进行分析.第5节对本文方案进行实验分析.最后对本文进行总结.
Bethencourt 等人[1]率先提出CP-ABE 的构造方法.该算法包括初始化、密钥生成、加密和解密4 个基本部分.他们证明了所提出的方案在一般群模型和随机预言模型下是可以对抗选择明文攻击的,同时还证明了它可以抵御合谋攻击.2007 年,针对Bethencourt 等人方案的访问策略不支持“NOT”逻辑运算的问题,Cheung 等人[2]将属性分成正、负和不相关3 种状态,率先实现在CP-ABE 方案中支持“NOT”逻辑运算.但他们的方案却不能支持“OR”逻辑运算.2008 年,Goyal 等人针对Bethencourt 等人所提出算法的安全性仅仅建立在一般群模型上以及Cheung 等人的方案虽然将安全性扩展到d-BDH(decisional bilinear Diffie-Hellman)假设条件但访问策略仅能支持“AND”逻辑运算这一不足,提出一种有界CP-ABE 算法[3].该算法与以往算法显著不同是:密文与访问树关联,密钥和访问树关联,这使得算法在d-BDH 假设条件下支持“AND”和“OR”运算,但也使得该算法过于复杂而无法实施.Bobba 等人[4]对基于属性的算法进行扩展,提出了密钥策略的基于属性集的加密算法CP-ASBE(ciphertextpolicy attribute-set based encryption).与CP-ABE 不同的是:分配给用户的数据集的元素本身可以不是属性而是属性子集;支持给用户分配多个一样的属性但这些属性分属不同的属性子集(同一属性子集不能出现相同的属性).与CP-ABE 相比,CP-ASBE 能够处理更复杂的用户属性结构和访问控制逻辑,因而更加灵活,应用价值更大.但无论是用户属性的分配、访问结构树的构建,还是解密操作,该算法都过于复杂,特别是当用户属性结构深度超过2 时,方案的复杂程度会大为增加.2011 年,Water 等人[5]发现,KP-ABE(key-policy attribute-based encryption)方案之所以较容易实现在d-BDH 假设条件下的安全,主要原因在于密文和属性关联使得仅根据是否在密文属性集中就能实现属性公开参数的不同处理;而在CP-ABE 中,密文关联的是复杂得多的访问策略(同一属性可能会多次出现),这使得属性公开参数的区别处理变得十分困难.鉴于此,Bethencourt 等人的方案[1]的安全性基于GGM(generic group model),而Goyal 等人[3]的方案需要将CP-ABE 转变为KP-ABE 才能实现d-BDH 假设条件下的安全.考虑到任何访问策略都可以表示成树,而任何树都可以转变为LSSS(linear secret sharing scheme)[6,7],他们提出基于LSSS 的CP-ABE 方案.在他们方案中,使用矩阵实现访问策略和秘密共享,矩阵的每一行都和一个属性关联.只有满足访问策略的用户私钥才能恢复秘密共享数,进而解密密文.该方案的安全性基于d-BDH 假设,在效率上也有较大的提升[8].2013 年,Balu 等人[9]针对Water 等人的方案存在访问策略中属性重复需要专门方法处理且重复出现次数有限制这一问题,提出在CP-ABE 方案中用线性整数秘密共享方案LISS(linear integer secret scheme)代替LSSS 并给出了构建共享矩阵的3 个原则.LISS 和LSSS 一样能够表示任意访问策略,但其不是在有限群上而是在整数区间上实现秘密共享且效率比LSSS 更高.其方案的安全性同样基于d-BDH 假设.2010 年,Yu 等人考虑到:在ABE 的多数实际应用场景中,数据存储服务器一般是半可信的且始终在线,将代理加密技术引入到CP-ABE 中,提出利用外包环境中的服务器来辅助用户属性撤销的CP-ABE 方案[10].该方案在属性的状态上效仿Cheung 等人的方案[2],要求用3 倍于属性空间的数来描所有属性的正、负、不相关3 种状态,要求用户存储的密钥子项数量等于属性空间大小,消耗了大量空间,增加了用户密钥管理负担.文献[11]针对已有的直接撤销模式的CP-ABE 方案基本都是基于身份进行撤销即通过撤销用户所拥有的全部属性来撤销用户密文访问权限而无法实现对某一个或几个属性撤销的问题,在合数阶双线性群上,基于双系统加密的思想,提出一种支持完全细粒度属性撤销的CP-ABE 方案并证明该方案在标准模型下是安全的.该方案建立在合数阶群上,增加了方案的复杂性;公钥参数数量随用户数量线性增加也是其不足.2011 年,Hur 等人针对授权机构可以解密任何密文的问题,他们将两方计算2PC(two party computation)协议引入到密钥的生成过程中,为每个用户生成标志参数;授权机构和数据存储中心基于该协议生成密钥生成参数,两个机构分别生成部分密钥子项[12].这一改变使得授权机构和数据存储中心都无法单独生成用户密钥,进而也就无法解密任一密文.文献[13]结合云计算的特点对CP-ASBE 进行了改进,提出一种基于云计算环境的分层的CP-ASBE 方案,即CP-HASBE(ciphertextpolicy hierarchical attribute-set based encryption).在密钥管理和密钥分配上,该方案没有给出效率较高的方法,密钥分配非常麻烦,用户需要自己管理的密钥数据较多.在云计算的利用上,该方案只利用了云的存储能力,而没有利用云的计算能力.2014 年,文献[14]提出一种面向云中大数据的支持访问控制策略动态更新的CP-ABE.该文献针对3 种类型的访问策略即单调的访问控制树、基于线性秘密共享方案的访问结构和一般的具有门限功能的访问控制树,分别设计了策略动态更新算法.该方案之所以能够实现策略的动态更新,要点之一是加密方保存了数据加密时产生的随机数,而这些随机数正是新旧策略联系的纽带.该方案的另一大优势是充分利用了云计算服务器的存储能力和计算能力.但是,为实现动态策略更新要求保存大量随机数给数据所有者带来很大负担,特别是在文件较多的情况下.
从上面的分析不难发现,已有的密文共享还存在诸多问题,用户客户端计算量过大、密钥保存量过多和只支持基于属性的共享而不支持基于身份的共享是其中3 个比较突出的问题.
针对用户客户端计算量过大、密钥存储量过多的问题,将授权中心标识符作为特殊属性引入到用户属性中.为授权中心标识符生成密钥子项,该子项利用安全信道发送给用户秘密保存.改造访问结构树:根节点操作符为“AND”,左子树为反映访问逻辑表达式的属性树或用户身份标识符对应的叶子节点,而根节点的右子树为叶子节点,与授权中心标识符对应.
改造后,将主要的计算和存储迁移到云端,除授权中心标识外所有用户属性对应的密钥子项都存储在云端.加密时,客户端只负责近一半密文子项的生成,另一半则由云服务器完成.解密时,除授权中心标识符对应的密文子项需要由用户客户端解密完成外,其他解密工作都外包给云服务器.所有密文子项也全部存储在云服务器上.由于缺少授权中心标识符对应的密钥子项这一关键数据,云服务器无法解密存放在其上的任何密文数据.
针对已有CP-ABE 方案的密文共享只能基于属性而无法针对个人用户,将身份标识符作为特殊属性加入到用户个人属性中.在用户私钥分配时,给用户身份标识符分配相应的密钥子项.在创建访问结构时,利用用户属性或身份标识符构建访问结构树.构建访问结构树时,如果只使用用户属性,则和以前基于属性的密文共享方式一样,实现的是基于角色的访问控制;如果只使用用户标识符属性,就属于基于个人身份的共享,实现的是基于身份的访问控制;如果既有用户属性又有个人属性,则属于既包含属性授权又包含个人授权的混合访问授权.
在面向公有云的密文共享框架中,主要包括授权中心、云服务器、数据所有者和用户,如图1 所示.授权中心位于企业可信域中,负责用户密钥的生成、分配、更新和撤销.云服务器位于云域,负责密文和用户私钥的存储.用户,可能在可信域中也可能在不可信域中,或作为数据所有者,利用客户端加密数据后上传到云端保存;或作为数据共享者,从云端读取并解密授权共享密文.在本文中,假设云服务器是半可信的(会忠实执行用户要求的操作,但也可能利用自己所拥有的数据甚至和恶意用户合谋去解密非授权密文).
Fig.1 Ciphertext-sharing framework for public cloud图1 面向公有云的密文共享框架
先用对称加密算法对共享文件的数据进行加密,再采用ABE 算法对数据加密密钥进行加密.
在已有的密文共享方案中,几乎都采取的是文件加密和密文共享同时在用户客户端进行的方式,而在实际的文件共享中,无论文件是否需要加密,都是先要将文件上传到存储服务器,再进行文件共享.基于该事实,将文件共享分成前后相随的两个阶段:文件安全存储和密文共享,下面分别进行说明.
(1) 文件安全存储
敏感文件在共享前,需要先存储到云端.为确保文件数据的机密性,需要对数据进行加密.这里,也采用CP-ABE 进行加密,访问结构如图2 所示,uidi和uid0分别为数据所有者标识符和授权中心标识符.在共享前,由于能够匹配密文访问结构树的只有数据所有者,故只有他能够解密数据.
Fig.2 Access tree of secure storage of cloud file图2 云文件安全存储访问结构树
(2) 密文共享
为实现共享,数据所有者首先根据访问策略或访问逻辑表达式构建文件共享访问结构树;然后,根据共享访问结构树计算各叶子节点的秘密共享数;最后计算每个叶子节点对应的两个密文子项中的一个.将文件共享结构树和叶子节点对应的一半密文子项以及用于计算另一半密文子项的相关数据上传到云端.
云服务器根据安全存储访问结构树和文件共享结构树构造云文件共享访问结构树(如图3 所示).基于安全存储访问结构树和文件共享访问结构树,构造云文件访问结构树的具体过程为:生成“OR”节点,用其替代安全存储访问结构树中代表数据所有者的用户标识符属性对应的节点,而用户标识符属性对应的叶子节点成为这个新建“OR”节点的左孩子,文件共享访问结构树则成为这个新建“OR”节点的右子树.图3 中的文件共享访问结构树表达的是能够访问密文的用户:要么是计算机学院云计算实验室的教师(基于属性的访问控制),要么是身份标识符UID 的值为uidj或uidk的计算机学院教师(基于身份的访问控制).云文件共享访问结构树除包含文件共享访问结构树的逻辑外,还允许数据所有者访问自己以密文形式存储在云端的数据.
云服务器还要利用数据所有者上传的相关数据,完成另一半密文子项的计算.
Fig.3 Access tree of cloud file sharing图3 云文件共享访问结构树
和一般的ABE 方案一样,面向公有云的安全文件共享方案也包括初始化、私钥生成、加密和解密4 个模块.
(1) 初始化:Setup(A,AID,d)
d为安全参数.授权中心选择一个阶为大素数p的双线性群G0和G1,记G0的生成元为g,对应的双线性映射为e:G0×G0→G1.定义系统所需的属性空间A={a1,a2,…,an},和用户身份空间AID={uid0,uid1,uid2,…,uidm}(uid0为授权中心标识符),定义一个哈希函数H:{0,1}*→G0.最后随机选择,将如下系统公钥信息发往云服务器并公开:
授权中心秘密保存主私钥:MK={gα,β}.
(2) 生成用户私钥:KeyGen(w,MK)
授权中心为用户Ui分配一对公私钥,将发往云服务器并公开,SEKuidi由用户秘密保存.
设用户Ui对应的属性集合为w′⊆A,令用户属性身份集(分别为授权中心和用户的标识符).随机选择;对于每个元素aj∈w,随机选择.生成的私钥如下:
将uid0对应的私钥子项通过安全信道发送给用户秘密保存,将其他私钥子项保存在云端的用户私钥表中.
(3) 加密:Encrypt(m,T,PK)
数据所有者Ui构造安全存储访问结构树T(如图2 所示).在需要共享时,将T改造为云文件共享访问结构树(如图3 所示).
①文件安全存储
设需要安全存储的文件为f.用户客户端使用对称加密算法(如AES)和数据加密密钥kf加密文件得数据密文Ekf(f).为安全存储访问结构树T根节点随机选择一个一元一次多项式Qr(x)和,使得s=Qr(0)且Qr(1)和Qr(2)分别为其左右子树根节点的取值.然后计算数据加密密钥的密文如下:
用户客户端将Ekf(f)、CT和Qr(1)的密文一起上传保存到云端.
② 密文共享
在文件共享阶段,数据所有者根据访问逻辑表达式构建文件共享访问结构树T′.为在访问结构树T′中每个操作符为“AND”的非叶子节点x随机选择一个一元多项式函数Qx(x).令T′的根节点对应的秘密共享数为Qr(1)(用解密求得).对于任意节点x且其父节点操作符为“AND”,,index(x)为x在兄弟中的序号(从左往右进行编号);对于任意节点x且父节点操作符为“OR”,.按照以上方式从上至下最终可以为每个叶子节点赋值表示T′叶子节点的集合.随机选择,计算用户共享密文子项:
其中,att()用来求叶子节点对应的属性.将CT′和上传到云端.
云服务器先利用T′将T改造为云文件共享访问结构树.计算T′对应的云共享密文子项:
kf完整的共享密文如下:
(4) 解密:Decrypt(CT,SK)
解密时,先在云服务器上完成部分解密,再在用户客户端上完成最后的解密工作.
①云服务器解密
共享情况下解密基于T′,叶子节点和非叶子节点有着不同的解密算法.
对于叶子节点x(aj=att(x)),其解密算法为
对于非叶子节点x,解密算法为
安全存储情况下只对用户标识符对应的叶子节点解密,其解密算法同于上面叶子节点解密算法,解密结果为:
② 用户客户端解密
用户再利用kf将文件密文进行解密以恢复文件f.
采用和Bethencourt 等人提出原始方案(下面称作BSW 方案)进行对比来分析所提出方案的安全性.和BSW方案相比,所提出方案向云服务器多暴露了所有用户除授权中心标识符外其他所有属性对应的私钥子项.下面通过两个挑战游戏证明方案能够确保数据的机密性.
游戏0:BSW 方案采用的安全游戏.
游戏1:基于本文所提出方案开展的游戏.与BSW 方案相比,攻击者还拥有所有用户的除授权中心标识符外其他所有属性对应的私钥子项;攻击者还可以从授权中心获得指定属性身份集(不满足密文访问策略)的私钥.
引理.攻击者赢得游戏1 和赢得游戏0 的优势是一样.
证明:在安全游戏中,攻击者(含云服务器在内的恶意用户)向挑战者(数据所有者)提交两个等长的消息m0和m1.挑战者随机从{0,1}中选择一个数(记为b),加密mb并将其密文E发回给攻击者.攻击者根据自身拥有的信息猜测E是m0还是m1的密文.设攻击者的猜测值为b′,如果猜中即b=b′,攻击者赢得游戏.如果攻击者每次猜中的概率与猜不中的概率的差值可忽略不计,则称为以可忽略优势赢得游戏即可抵御选择明文攻击;否则,称作以不可忽视优势赢得游戏即不可抵御选择明文攻击.
用多项式时间算法A和B分别表示游戏1 和游戏0 的攻击者.
Begin
假设前m次密钥查询使用的属性身份集刚好对应于m个用户的属性身份集(不包括数据所有者身份标识符);
End
由算法B可知,算法A赢得游戏1 的优势并不比算法B高,当然也不会比B低(因为知道更多信息),故算法A和算法B有着一样的优势.因此,攻击者赢得游戏1 和赢得游戏0 的优势是一样.□
定理.本文所提出的方案,在一般群模型和随机预言模型下可抵御选择明文攻击.
证明:如引理所证,攻击者赢得游戏1 和赢得游戏0 的优势是一样的,而Bethencourt 等人已经证明在一般群模型和随机预言模型下,攻击者赢得游戏0 的优势可忽略不计,故在同样条件下,攻击者赢得游戏1 的优势同样可忽略不计.所以本文所提出的方案,即使多个用户合谋或云服务器与用户合谋,在一般群模型和随机预言模型下可抵御选择明文攻击.□
下面从计算和存储两个方面讨论所提出方案的性能.
(1) 计算性能
由于数据处理时,最耗费时间的运算依次是双线性运算B和指数运算E,所以用这2 个指标来衡量性能.
解密时,客户端解密一次叶子节点(与授权中心标识符对应)的计算代价为2B.解密云共享文件访问结构树根节点的代价为2E,完成最后的解密代价为1B,故用户客户端解密总的计算代价为3B+2E.数据所有者解密时,云服务器只需对一个叶子节点即uidi对应的密文子项进行解密,计算代价为2B.共享者解密时,在非叶子节点对应逻辑操作都为“AND”的情况下,云服务器解密文件共享访问结构树T′的每个节点(根除外)都要参与一次指数运算,故云服务器的计算代价为2(|TL|-2)B+(|T|-3)E.BSW 方案与本文所提出方案在用户客户端的计算代价比较见表1.
Table 1 Comparison of user client computing overhead表1 用户客户端计算开销对比
(2) 存储性能
在所提出的方案中,无论是用户私钥还是用户数据都以外包形式存放在公有云上,用户唯一需要安全保存的是授权中心分配给他的与授权中心标识对应的私钥子项,大大减轻了密钥管理的负担.云服务器负责管理其他用户私钥子项,所需存储空间大小与用户所拥有的属性数量成线性关系.对某一个文件,采用本方案需要的密文存储空间和采用基本CP-ABE 方案需要的存储空间相当,只是多了两个密文子项(需要4 个群元素的存储空间),分别和用户标识符与授权中心标识符对应.
利用双线性对加密库(http://crypto.stanford.edu/pbc/)和CP-ABE 开发工具包(http://acsc.csl.sri.com/cpabe/),基于本文所提出方案在Hadoop 环境下实现了一个面向公有云的密文共享系统并进行性能实验.实验使用的虚拟机配置为:1 个Intel(R) Xeon(R) CPU(E5-2620 2.0GHZ);内存1GB;系统CentOS6.5 64 位.所有算法采用Java语言编写,双线性映射和幂运算等有关椭圆曲线加密的操作均来自双线性对加密库JPBC.所实现的系统采用160 位椭圆曲线群,椭圆曲线为512 位有限域上的超奇异椭圆曲线y2=x3+x.
加密和解密实验分别针对BSW 方案和本文方案各进行20 轮,每轮使用相同大小的数据和相同的文件访问结构树(为方便比较,访问结构树的非叶子节点对应的逻辑运算均取为“AND”);每轮实验进行20 次,取20 次实验的平均值为最终实验结果.访问结构树叶子节点数量依轮次递增,前 10 轮实验加密时间对比见表2.
Table 2 Comparison of experimental data of encryption time表2 加密时间实验数据对比
从实验数据可以看出,BSW 方案客户端和本文方案加密时间都随着叶子节点数量不断增加,加密时间与叶子节点数量呈线性关系(如图4 所示),但本文方案的加密时间更短.随着叶子节点数量增加,二者加密时间的差距增大即本文方案节约的时间增多,这和上一节所作的性能分析结果是一致的.
Fig.4 Comparison chart of encryption time图4 加密时间的对比图
解密前10 轮实验解密时间(客户端)对比见表3.
Table 3 Comparison of experimental data of decryption time表3 解密时间实验数据对比
从实验结果(如图5 所示)可以看出,BSW 方案解密时间随用户与访问结构树匹配属性数增加而线性增加,而本文方案客户端解密时间比较稳定,在42ms 左右,这使得一般个人电脑、平板电脑和手机(和实验虚拟机配置相当)也能较快地解密共享密文.
Fig.5 Comparison chart of decryption time图5 解密时间的对比图
由于实现了细粒度的访问控制和在密文共享上具有“一对多”的显著优势,加之和企业信息系统广泛采用的基于角色访问控制方法相似,CP-ABE 可能成为企业外包云密文数据共享的重要访问控制方法.然而,已有的基于CP-ABE 的密文共享方案存在客户端计算量过大、用户管理密钥过多、不支持个人共享等问题.考虑到公有云强大的计算能力和存储能力,将公有云引入到密文共享方案的设计之中,提出一种面向公有云的安全文件共享框架,基于该框架设计一种面向公有云的密文共享方案.该方案将绝大多数计算和存储都外包给公有云,用户只需保存两个空间占用很小的私钥子项且客户端只需进行少量计算就能完成共享文件的解密.安全性分析表明,该方案在不仅能够对抗恶意用户的合谋攻击,还能在一般群模型和随机预言模型下对抗选择明文攻击.