基于CP-ABE的自定义读写策略的云数据共享方案
2019-08-27胡奥婷胡爱群
胡奥婷, 胡爱群
(东南大学 网络空间安全学院,江苏,南京 210096)
云服务器存储数据,作为大数据时代的重要应用,让用户把本地数据上传到云服务器中保存. 安全性和实用性是云存储服务的要素. Sahai和Waters[1]在2005年提出基于属性加密算法(attribute-based encryption,ABE). 其后,Bethencort等[2]在2007年提出CP-ABE(ciphertext-policy attribute-based encryption,CP-ABE)算法,数据拥有者自定义数据加密策略,并将数据加密策略与密文关联后上传至云服务器,使得满足属性条件的用户可以自行下载解密,不满足属性条件的人不能解密. 这种加密机制十分适合云存储场景. 此后大量的研究对CP-ABE算法完善和拓展,主要集中在多权威机构的CP-ABE[3-5],CP-ABE安全撤销的研究[6-8],隐蔽接入策略的CP-ABE[9-12]等方面.
然而,在众多研究中,关于对用户读写权限分类的CP-ABE的研究较少. 用户在云数据共享时,可能分为不同的权限,如只读权限和读写权限. 只读权限的用户只允许其下载和阅读数据,但是不能修改数据,读写权限的用户允许其下载解密修改并重新上传数据. 多人修改同一份文件时就需要用到此功能. 本文提出一个基于CP-ABE算法的用户权限分类的云数据共享方案. 与现有相关的研究相比,有更简单的算法和更高的计算通信效率,且可以弥补现有文献的安全漏洞.
1 模型和算法架构
1.1 云共享模型
本方案使用的云共享模型如图1所示,实体包括云服务提供者(cloud service provider, CSP),数据拥有者(data owner),属性权威机构(authorities),只读用户和读写用户. 用户注册阶段,属性权威机构给用户分发属性密钥. 数据加密阶段,数据拥有者制定消息MSG的接入政策,包括只读政策x和修改政策y. 只读政策x与消息MSG绑定用于生成密文CT,读写政策y中的属性计算参量集合附在密文CT后面,全部上传至CSP,用于云服务器判断用户权限. 用户解密时,用户向云服务器CSP申请数据,CSP把密文CT发给用户,当且仅当用户属性满足只读政策x时用户解密数据. 想要修改数据的读写用户必须证明其属性集合满足读写政策y才可以修改数据.
图1 云共享模型Fig.1 Model of cloud data sharing system
修改数据的协议模型见图2. 该模型包括3个实体,即读写用户、云服务提供商和验证权威机构. 协议的步骤为:
图2 用户修改数据模型Fig.2 The model of modifying data on cloud
① 用户申请对消息MSG的修改权限;
② CSP把密文和挑战直接发给用户,同时CSP把挑战用户的唯一识别号、随机数和公钥发送给验证权威机构;
③ 用户拿到挑战,计算proof,证明自己有修改权限,并把proof发送给验证权威机构;
④ 验证权威机构验证等式判断用户是否有修改权限,如果用户验证通过,则验证权威机构发送确认用户修改权限给云服务器,同时返回确认给用户;
⑤ 用户收到认证通过的消息,就可以修改数据. 用户修改数据并重新上传数据.
1.2 安全模型
本节提出安全模型,在1.1节描述的云共享模型中提到有3类实体,包括云服务器,权威机构,用户(数据拥有者、只读用户和读写用户). 本文认为云服务器是半可信(semi-trusted)的,即会忠实执行用户存储数据修改数据的操作,但是对用户数据好奇. 权威机构是完全可信(full- trusted)的,即不会泄露用户的密钥也不允许与任何机构共谋. 用户是好奇的(curious),其可能会试图获取自己权限之外的数据. 例如只读权限的用户想要获取修改数据的权限. 不满足该数据接入条件的用户试图解密数据. 另外存在外来入侵者(outside intruder),可能会观察通信信道试图截取数据并解密数据,试图伪造权限证明.
1.3 方案组成算法
本方案的去中心化的可分开制定读写策略的CP-ABE算法由以下5个算法组成.
① Global Setup(λ)→GP:输入安全参数λ,输出全局参数GP.
② Authority Setup(GP)→SK,PK:每个权威机构输入GP全局参数,输出自己的公私钥对SK,PK.
③ KeyGen(GID,GP,i,SK)→Ki,GID:每个权威机构输入用户的身份GID,全局参数,一个属性i,属性机构的私钥SK. 输出针对用户GID的属性为i的私钥Ki,GID.
④ Encrypt(M,(A,ρ),(B,μ),GP,{PK})→CT:数据拥有者输入消息M,只读接入矩阵(A,ρ),读写接入矩阵(B,μ),全局参数GP,各个权威机构的公钥,输出密文CT.
⑤ Decrypt(CT,GP,{Ki,GID})→M:用户输入全局参数GP,密文CT,属性密钥{Ki,GID},当属性密钥满足接入矩阵时,可以输出明文M. 否则,解密失败.
2 方案构造
本文提出基于CP-ABE的去中心化的分别自定义读写策略的云数据共享方案的算法. 方案包括4个部分:系统初始化、加密算法、解密算法和用户修改数据.
2.1 系统初始化
系统初始化包括3部分算法:全局初始化GlobalSetup(λ)→GP,权威机构初始化AuthoritySetup(GP)→SK,PK和用户注册KeyGen(GID,GP,i,SK)→Ki,GID.
① GlobalSetup(λ)→GP.
定义一个素数p阶的双线性群G,g为其生成元,双线性群GT. 定义双线性运算e:G×G→GT. 定义哈希函数H:{0,1}*→G,H2:GT→p. 每个用户分配一个全局身份标识GID.
② AuthoritySetup(GP)→SK,PK.
由权威机构At执行,每个权威机构对其管理的属性有着互不重叠的编号i,这个属性编号在全局中是独一无二的. 对每个属性i,权威机构选取随机指数αt,i,yt,i∈p,计算PKt,i={e(g,g)αt,i,gyt,i}作为公钥,私钥为SKt,i={αt,i,yt,i∀i}.
③ KeyGen(GID,GP,i,SK)→Ki,GID.
一个全局编号为GID的用户,要去各个属性机构处注册登记获取自己的属性密钥. 某个属性机构At给用户GID的属性i颁发属性密钥,其用私钥SKt,i计算:
Ki,GID=gαiH(GID)yi,
(1)
并把私钥Ki,GID安全的传送给用户.
2.2 加 密
加密算法为Encrypt(M,(A,ρ),(B,μ),GP,{PK})→CT,由数据拥有者执行.
某数据拥有者全局编号为GID,想要加密消息M,首先他需要制定只读策略(A,ρ),也就是解密该消息所需要的属性集合. 矩阵A是一个n×l的接入矩阵,函数ρ将其行向量映射到每个属性. 然后选择一个随机数s∈p和一个随机向量是其第一个元素. 本文定义λx=Ax·v,Ax表示矩阵A的第x行. 同时选择随机向量使0作为他的第一个元素. 定义ωx=Ax·w. 对每一个行向量Ax,选择随机数rx∈p. 加密的密文计算为
C0=Me(g,g)s,
C1,x=e(g,g)λxe(g,g)αρ(x)rx,
C2,x=grx,C3,x=gyρ(x)rxgωx∀x.
(2)
然后用户定义读写策略(B,μ),矩阵B是一个m×t的接入矩阵,函数μ将其行向量映射到每个属性. 然后选择一个随机数s′∈p和一个随机向量是其第一个元素. 对随机数s′,计算
v2=gH2(e(g,g)s′).
(3)
D1,x=e(g,g)τxe(g,g)αμ(x)ux,
D2,x=gux,D3,x=gyμ(x)uxgφx∀x.
(4)
定义CTR={C0,C1,x,C2,x,C3,x∀x},W={D1,x,D2,x,D3,x∀x},CT=(CTR,W). 加密结束后,用户把CT‖v2上传至云服务器保存.
2.3 解 密
用户如果想要解密消息CT(可以解密数据的用户分为两种:第一种是只能解密数据且不能修改数据;第二种是既能解密数据又能修改数据),那么给云发送请求数据,云服务器把CTR返回给用户,用户可以开始解密工作. 首先用户用自己的唯一标识GID计算哈希H(GID). 如果用户拥有属性Ax的密钥Kρ(x),GID,并且这些属性的线性组合包含(1,0,…,0),那么用户就可以进行以下解密. 对每个属性x,用户计算
e(g,g)λxe(H(GID),g)ωx.
用户选择常数cx∈p使得然后计算:
∏x(e(g,g)λxe(H(GID),g)ωx)Ex=e(g,g)s.
最后解密消息为
(5)
2.4 用户修改数据
当用户申请修改数据时,先发送修改数据的请求给云服务器,云服务器收到请求后发给他密文和一个随机数挑战i,随机数为了防止重放攻击(replay attack). 用户收到密文CT后,计算出证明自己修改权限的σ,云服务器验证通过后,用户就可以修改数据. 具体计算步骤如图3所示.
图3 用户修改数据协议Fig.3 The protocol of modifying data on cloud
① 用户发送修改请求给云服务器;
② 云服务器找到对应的密文CT,并生成随机数i,并把挑战和密文i‖CT发送给用户,与此同时,云服务器把i‖GID‖v2发送给验证权威机构. 此处假设云服务器和验证权威机构的信道是安全的.
③ 用户收到密文CT后,解剖出W. 用户用自己的唯一标识GID计算哈希h=H(i‖GID)如果用户拥有属性Bx的密钥Kρ(x),GID,并且这些属性的线性组合包含(1,0,…,0),那么用户就可以进行以下解密. 对每个属性x,用户计算
e(g,g)τxe(H(GID),g)φx.
用户选择常数dx∈p使得然后计算
∏x(e(g,g)τxe(H(GID),g)φx)dx=e(g,g)s′.
最后用户计算签名令牌σ并发送给验证权威机构用作验证.
σ=hH2(e(g,g)s′).
④ 验证权威机构收到用户的签名令牌σ,同时计算h←H(GID‖i),然后验证等式
e(h,v2)=e(g,σ).
(6)
验证完成后回复ACK给CSP,CSP转发给用户. 当验证通过时ACK=1,验证失败时ACK=0.
⑤ 当用户收到ACK=1时,用户可以修改数据并重新加密上传该数据,过程与创建一个文件类似,只是在云服务器上会用新的密文替代原来的密文CTR,W和v2保持不变.
3 安全性分析
3.1 解密正确性
本方案的正确解密含义是,不论何时,输入一个全局参数GP,M通过加密算法产生的密文CT,用户GID对应的属性密钥集合{Ki,GID},只要属性密钥集合满足接入结构,那么Decrypt(CT,GP,{Ki,GID})=M.
证明 某用户A的全局身份标识为GID,其计算哈希函数H(GID),他的密钥为{Ki,GID}. 密文的加密政策为(A,ρ). 用户选择一些Ax对应的密钥,使得向量(1,0,…,0)是他们的一种线性组合. 然后用户解密如下,对于这样的x,他计算
e(g,g)λxe(H(GID),g)ωx.
然后用户选择常数cx∈p使得然后计算:
∏x(e(g,g)λxe(H(GID),g)ωx)cx=
最后用户解密消息M为C0/e(g,g)s=M.
3.2 抗伪造性
t′≥t+2τcA(qs+qH),ε′≤ε/2eqs.
证明 由于该证明就等价于Gap签名的安全性,所以在文献[13]中有完整的安全性证明,在此不赘述.
3.3 抗共谋攻击和重放攻击
本方案在数据解密时抗共谋攻击、在用户修改权限认证时抗重放攻击、共谋攻击.
e(g,g)λxe(H(GIDA),g)ωx,
e(g,g)λxe(H(GIDB),g)ωx.
本方案可以在用户验证修改权限协议时防止多个用户共谋产生签名令牌σ. 和前文解密防止共谋的方法是类似,只是在修改权限认证协议中,两个或以上的用户共谋所针对的是读写策略(B,μ). 但是由于两个用户GID的不同,一样不能在解密步骤约去后一项并计算出e(g,g)s′,因此也就不能共谋产生签名令牌σ.
除此之外,该签名令牌σ还能防止重放攻击. 在用户修改数据协议(图3)中,未防止攻击者窃听截获截获信道数据,每次用户发起用户修改数据协议,云服务器都生成新的随机挑战i,所以即使攻击者截获之前的通信数据,也不能通过再次重放获取能通过验证权威机构的正确认证.
4 功能和计算复杂度
首先,对比了文献[5,14-15]对与本文的功能比较,结果见表1. 从表1可以看出,同类型的文章可以实现去中心化的支持读写功能的有文献[5,14],虽然文献[15]不支持用户的读写权限分开定义,但是因为其是经典的去中心化ABE方案,且文献[14]也采用其去中心化思路,所以列入其中方便下文的计算复杂度分析. 文献[5,14]用的读写策略分开定义的方法是相同的,都是单独采用了ABS签名算法,让用户另外对每个消息加密时产生相应的签名,用于验证用户身份. 区别是文献[14]只支持一个属性权威机构,不能应用于去中心化的多属性权威机构场景. 综上所述,只有文献[4]实现的功能与本文类似. 因此在相同的实现功能下,只需比较文献[5]与本文的计算量和存储量高低,比较结果见表2和表3.
表1 功能比较Tab.1 Functionality
表2 计算量比较Tab.2 Computation complexity
表3 存储量比较Tab.3 Storage overhead
其次,对比了文献[5,14-15]和本文方案的加密时计算量、签名计算量、验证写权限计算量,结果见表2. 其中EG为群元素计算一次指数运算的时间,tPair为群元素计算一次双线性运算时间,tHash为一次哈希函数的运行时间. 本文的加密计算量比其他文献略高,签名计算量与文献持平,但是本文有着明显较少的验证修改权限的计算量. 这是因为本文采用的BLS签名算法比文献[5,14]更见简便,另外,值得注意的是,文献[5,14]都是采用云服务器对用户修改权限判断和验证,如果云服务器不是完全可信的话,极易存在数据被不法分子擅自篡改的问题.
最后,对比了文献[13-15]和本方案的存储量比较,包括签名、属性密钥、密文数量,结果见表3. 从表3看出,本文签名和属性密钥数量都远远优于同类文献,其中nGID为用户GID持有的属性数量. 密文数量与同类文献比较基本持平. 增加的密文量主要是为了保证第三方权威机构可以替代云服务器检验用户的可修改数据权限,从而避免云服务器不诚实带来的数据篡改问题.
5 结 论
本文提出了一个去中心化的基于CP-ABE的自定义用户读写权限的数据共享机制. 该机制可以让数据拥有者自行定义用户的只读和修改权限的属性条件,并把条件和密文相关,上传到云服务器保存. 之后用户就可以自行下载数据并修改数据. 只有满足只读条件的用户才能解密数据,只有满足修改权限的用户才能修改数据. 其他用户包括半可信的云服务器都不能解密或者随意篡改数据. 本机制比同类方案的优点在于系统参数少、签名长度短、验证计算量小、通信量小,并且能够防止不诚实的云服务器蓄意篡改数据带来的危险.