AB-ACCS 一种云存储密文访问控制方法.doc_第1页
AB-ACCS 一种云存储密文访问控制方法.doc_第2页
AB-ACCS 一种云存储密文访问控制方法.doc_第3页
AB-ACCS 一种云存储密文访问控制方法.doc_第4页
AB-ACCS 一种云存储密文访问控制方法.doc_第5页
已阅读5页,还剩3页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

AB-ACCS:一种云存储密文访问控制方法发表时间:2011-1-10 洪澄 张敏 冯登国 来源:万方数据随着云计算概念的流行,云存储也在越来越多地被提及。云存储依靠其低成本、可扩展的特点得到了广泛的支持和关注,但是也带来了新的安全问题:大多数情况下,用户并不能完全信任云存储服务提供商,从而需要对数据加密以保证数据的机密性。目前已有的基于密文的访问控制技术中,数据属主(Owner)需要为每一个用户维护和发放数据密钥,这样在用户数目众多的情况下,Owner端会成为应用的瓶颈。针对此问题提出了一种新的访问控制方法AB-ACCS,其核心思想是采用基于密文属性的加密算法为用户私钥设置属性,为数据密文设置属性条件,通过私钥属性和密文属性的匹配关系确定解密能力。因此数据属主只需要通过控常I数据的密文属性进行权限管理,而不需要为用户分发数据密钥,降低了权限管理的复杂度,避免了这一应用瓶颈。 云存储是从云计算概念衍生和发展起来的新技术之一,它通过网络将大量各种不同类型的存储设备集合在一起协同运作,为用户提供在线数据存储服务,世界知名IT企业(如Amazon,Google,Microsoft等)都在这一领域投下了巨资,并迅速成长为云存储服务提供商(Cloud Storage Provider,CSP),云存储已成为近年来成长最快的互联网服务之一,云存储提供了易于使用的数据接口和极强的可扩展性,在云存储服务模式下,用户无需关心存储系统的组成架构,也不必购买专门的存储设备和雇用专业数据维护人员。因此,云存储正在更多地成为广大组织机构的存储选择。然而,云存储服务在带来便利的同时,也引起了用户对于安全性的广泛担忧。一项调查显示,出于安全方面的考虑,多达70%的用户仍然不愿意将关键数据置于自身控制域之外。事实上,Google Docs,The Linkup等多家著名云服务商都曾出现过各种安全问题,并导致了严重的后果。安全技术的缺失已经成为云存储普及的最重要障碍。 访问控制是实现用户数据机密性和进行隐私保护的重要手段。目前有很多云存储服务都提供了简单的访问控制功能,譬如支持为文件设置访问权限,但是这些安全机制完全依赖于服务器端的控制,其安全性建立在对CSP的信任之上。在复杂的网络环境和多变的商业利益之间,CSP能否保证安全机制的有效性,能否坚守对用户的服务承诺? 密文访问控制技术是服务器端不可信场景下的数据机密性解决方案。数据属主在存储数据之前预先对其进行加密,通过控制用户对密钥的获取权限来实现访问控制目标。一个典型的密文访问控制结构如图1所示。当前已经有许多针对密文访问控制技术进行的研究。此类方法可以较好地解决数据机密性的问题,但是由于用户对数据密钥的获取权限完全由数据属主控制,权限管理的复杂程度将随数据量和用户量的增长显著提高,从而导致属主端成为系统的瓶颈。图1:典型密文访问控制架构 针对上述问题,本文首先确立了一个实现密文访问控制功能的基础架构ACCS,然后在ACCS的基础上提出了优化的基于属性的密文访问控制方法(AB-ACCS),该方法通过用户属性和数据属性的匹配关系确定解密能力,显著降低了密文访问控制的复杂性,简化了云存储环境下的权限管理。最后本文对使用AB-ACCS和未使用AB-ACCS的2种存储方案进行了实验测对比,证明了AB-ACCS在读写和权限管理方面的有效性。一、相关工作 在最初的密文访问控制方法中,数据属主将每个数据文件分别使用单独的密钥加密,并通过特定渠道向用户分发数据密钥。为了降低分发代价,Goh等人提出将数据密钥以用户的公钥加密,并存储于服务器端,用户直接访问服务器获取数据密钥。在上述2类方法中,系统都需要维护大量的数据密钥信息。为了减少需要维护的密钥数量,Damiani等人提出了一种层次访问控制方法(hierachical access control,HAC),让用户可以通过用户私人密钥以及一份公开的信息表(token)推导出被授权访问的数据密钥。HAC是一种经典的密文访问控制方法,许多不可信存储环境下的访问控制技术研究都是以HAC为基础的。但是目前HAC至少存在2个问题:首先,token表完全由数据属主维护且具有复杂的结构,每次进行权限变更都必须对相应文件的token表进行繁琐的操作,因此难以被应用于云存储下的大规模多用户读写环境。其次,token表的安全性也难以保证:token表也保存于服务器端,同样面临着来自不可信CSP的威胁。虽然提出了一种针对token表的安全保护方法,但是该方法仍然难以抵抗恶意服务器发起的重放攻击。 另外一类方法认为服务器可以是部分可信(“honest but curious”)的,即不能将数据明文泄露给服务器端,但是除此之外服务器所有的行为都是忠实的。一种采用了代理重加密技术,数据属主根据用户信息计算出一个代理重加密密钥交付给CSP,CSP利用代理重加密密钥对储存的密文数据进行重加密,生成只有指定用户能够解密的密文数据。另外一种使用双层加密技术,在CSP端实施一层额外的加密保护,通过更改CSP层的密钥实现不同的访问控制策略。我们认为部分可信这一前提不够安全,因此刚刚说的两种的数据机密性是难以保证的。二、安全假定 本节描述AB-ACCS的基本安全假定,这些假定是设计整个方案的出发点。 2.1 不可信服务器 如上所述,有的方法假定云存储中的服务器是“honest but curious”的,可以将一部分访问控制机制指派给服务器。我们认为这个前提假设在真实的云存储环境中不成立。实际上,CSP完全可能因为利益关系而违背访问控制策略,从而破坏数据的机密性。因此CSP完全有可能不忠实履行第2层加密,导致用户被撤销权限之后仍然可以访问数据。我们对本文中的CSP的恶意程度进行定义如下: CSP可能将拥有的任意数据进行任意计算并发送给予任意用户。 由于本文只讨论云存储中的数据机密性问题,而不涉及数据可用性等其他方面,因此还需要进行如下限定: CSP不会恶意删除数据或者拒绝响应用户的请求。 2.2 对用户的透明性 为了确保安全性,云存储下的访问控制机制必须依赖于加密。我们认为这一加密机制应对用户透明,即尽量少地让用户涉及密钥生成、密钥发布等事务,让用户访问数据的体验类似于普通文件系统中的访问控制机制。在不可信的存储系统中,完全实现这一点且满足安全性是困难的,因此我们引入了可信介质的概念。在我们的设计中,可信介质是一个容量有限的用于保存访问控制信息的可信存储空间,它可以位于数据属主私人的存储上,也可以位于其他可信方的存储介质上。访问控制信息是以密文+签名的形式存储的,因此该介质的内容允许被暴露,但是不会被篡改。 在对用户透明的系统中,用户发起的数据访问请求自动被解释为如下步骤:客户端首先从可信介质处获得访问控制信息,然后向云存储取得密文数据,最后使用用户私钥和访问控制信息计算出数据密钥、解密数据,得到数据明文。 2.3 懒惰重加密(lazy-revocation) 在密文访问控制中,取消用户对数据的访问权限通常意味着需要对数据进行重新加密,而频繁重新加密数据的代价通常是难以接受的。lazy-revocation也就是懒惰重加密的概念,指出在权限撤销时并不进行重新加密,而直到该文件内容改变时才进行重新加密;考虑到用户和服务器完全有可能在此前有权限访问数据时就自行保留数据的副本,我们认为lazy-revocation可能造成的旧数据泄露代价是可接受的。 我们默认采用如下的方法来实现lazy-revocation: 2.3.1 当某个用户被撤销数据的读权限时,Owner将该数据的密钥K更换为K,但是并不立即使用K对数据进行重新加密,而是将K发布给所有有写权限的用户,由用户在下次写入时使用K写入数据; 2.3.2 有写权限的用户一般也具有读权限,则当lazy-revocation事件发生时,写者会同时拥有2个数据密钥:K和K;读取数据需要使用K而写数据需要使用K;当写入事件发生后K被废弃,读、写均使用K。三、ACCS方法 本节将描述一个实现了基本密文访问控制功能的存储架构,我们称之为Access Control for Cloud Storage(ACCS),ACCS是ABACCS的基础。 3.1 读写权限控制 读写数据是云存储系统的基本需求,而简单地将数据使用一个密钥K(data)加密无法区分读写权限。为了实现读写权限控制,每份数据除了需要密钥K(data)用于加密之外,还需要一个公私钥对K(sign)K(verify):K(sign)授予写者,用于对加密后的数据进行签名;K(verify)授予读者,用于对签名结果进行验证。ACCS将采用上述方法实现读写(RW)和只读(RO)2种用户权限的区分。 3.2 体系结构 ACCS的体系结构如图2所示。每个用户对应一个RSA公私钥对K(pub),K(priv),其中K(pub)公开发布,而K(priv),由用户私人持有。图2:ACCS结构图 每个文件F具有一个AES对称密钥K(data)用于加密数据,一个RSA公私钥对K(sign)K(verify)用于对加密后的数据进行签名/验证。数据密文E(F)和签名SIG(F)都保存在CSP端。 我们在可信介质S上为每个文件F都保存一个元数据表Grantee,用于保存有权访问F的用户信息列表。 Grantee的每一个元数据项都对应于一个有权访问F的用户,例如A具有F的读写权限,则属主使用A的公钥K(A pub)加密K(data),K(sign),K(verify),并存储在元数据项GranteeA中。又如B具有F的只读权限,则属主使用B的公钥K(B pub)加密K(data),K(sign),K(verify),并存储在元数据项GranteeB中。为了保证元数据的真实性,Owner还需要对每个Grantee项使用自己的私钥K(O priv),进行签名。显然地,数据属主Owner默认具有F的读写权限,即Grantee中默认存在元数据项GranteeO。 3.3 ACCS:数据读写 以下分别以用户A读/写文件F为例,描述对数据进行读写的流程。 3.3.1 读取数据 A在可信介质S中查询F对应的Grantee表获取GranteeA; A使用Owner的公钥K(O priv)和自己的私钥K(A pub)解密GranteeA得到K(data)和K(verify); A从CSP处获取F的密文E(F)和签名SIG(F); A使用K(verify)验证SIG(F)的正确性; A使用K(data)解密E(F)。 3.3.2 写入数据: A在可信介质S中查询F对应的Grantee表获取GranteeA; A使用Owner的公钥K(O priv)和自己的私钥K(A pub)解密GranteeA,得到K(data)和K(verify); A使用K(data)加密文件F得到E(F),使用K(sign)对E(F)进行签名,得到SIG(F); A将E(F)和SIG(F)发送给CSP。 3.4 ACCS:访问控制 以下分别以数据属主O授予/取消用户B读写文件F的权限为例,描述对数据进行访问控制的流程。 3.4.1 读写权限授予 O在可信介质S中查询F对应的Grantee表获取Grantee(O); O解密Grantee(O)得到K(data),K(sign),K(verify); O先使用B的公钥K(B pub)加密K(data),K(sign)K(verify),再使用自己的私钥K(O priv)加密,得到GranteeB; O将GranteeB插入F对应的Grantee表。 3.4.2 读写权限撤销 O在可信介质S中查询F对应的Grantee表; O从Grantee表中删除GranteeB信息; O生成新的数据密钥K(data)新的签名/验证密钥K(sign),K(verify); O对文件F使用K(sign),K(verify)进行重签名; O对所有有权访问F的用户i,更新Grantee表内对应项Granteei内的K(data),K(sign),K(verify)为K(data),K(sign),K(verify)。 由于篇幅限制,以上仅列出RW权限授予/撤销的实施步骤,其他如RO权限授予/撤销、RO权限升级为RW权限、RW权限降级为RO权限等操作的步骤均与上述步骤类似。四、AB-ACCS方法 ACCS具有足够的安全性,并且实现了基本的访问控制功能。但是在ACCS中,数据属主需要为每个有权限访问文件的用户都储存一个元数据项。这样在云存储的多用户应用场景下,众多的元数据项给数据属主带来的存储、更新、检索等维护代价都是难以接受的。本节针对这个问题提出了优化方法Attributes-Based ACCS(AB-ACCS)。 4.1 基于密文属性的加密 Bethencourt等人提出了一种基于密文属性的加密算法(ciphertext-policy attribute-based encryption,CP-ABE),CP-ABE将用户私钥关联到一组属性,而将数据密文关联到一组属性判断条件,若用户私钥的属性满足属性判断条件,则用户具有解密该数据的能力。相比直接分发密钥的方法,使用CP-ABE方法更易于密钥管理,具有更强的用户透明性。 CP-ABE算法的主要内容如下: 定义1,属性。 设P=P(1),P(2),P(n)为所有属性的集合,则每个用户的属性A是P的一个非空子集,A包含于P(1),P(2),P(n)。 例如我们定义属性的全集为经理,雇员,市场部,IT部,武汉,北京,一个用户甲的属性A可以为经理,IT部,武汉)。可见,N个属性可用于鉴别2的N次方个用户。 定义2,访问结构。 访问结构T是全集P(1),P(2),P(n)的一个非空子集。即T包含于2的P(1),P(2),P(n)次方。T代表了一个属性判断条件:在T中的属性集合称为授权集,不在T中的属性集合称为非授权集。 例如可以定义一个访问结构T代表属性集“北京的经理或者市场部经理”(见图3),显然用户甲的属性A是T的非授权集。 定义3,访问结构树。 访问结构树用于描述一个访问结构。树的每个叶节点代表一个属性项,而每个内部节点代表一个关系函数,关系函数可以是AND,OR,N of M门限等。如图3所示。图3:访问结构树一例 CP-ABE算法包括4个步骤: Setup生成主密钥MK和公开参数PK CT=Encrypt(PK,M,T)。使用PK、访问结构T加密数据明文M加密为密文CT。 SK=KeyGen(MK,S)。使用MK、用户属性值S生成用户的私钥SK。 M=Decrypt(CT,SK)。使用私钥SK解密密文CT得到明文M。实现的算法保证了只有S是T的授权集的条件下,Decrypt()操作才能成功。 由于上述优良特性,CP-ABE可以用于我们的密文访问控制场景中,但是CP-ABE体系属于非对称加密算法,效率过低,难以直接用于加密大量数据,因此我们嚅要采用ACCS的基本架构,先使用对称密钥K(data)作为数据密钥对数据实行加密。而后使用CP-ABE加密K(data),以保证K(data)只能被合法用户访问。 4.2 AB-ACCS:基本设计 我们称利用CP-ABE对ACCS实施改进后的方案为AB-ACCS,其设计如图4所示:图4:AB-ACCS结构图 体系结构: Owner维护主密钥MK和公开参数PK; Owner为每个用户U(i)设定属性值V(i); Ownerv为每个用户U(i)生成私钥K(i priv)=KeyGenMK,V(i),并发布给用户。 可信介质、元数据表Grantee的概念仍然与ACCS的设计相同;不同之处是表Grantee现在只具有2个元数据项GranteeRW,GranteeRO,分别代表对F具有读写权限的访问结构T(RW)和只读权限的访问结构T(RO)。默认地,T(RW)对Owner身份无条件成立。 以下分别以用户A读/写文件F为例,描述对数据进行读写的流程。 4.2.1 读取数据 A在可信介质S中查询F对应的Grantee表获取GranteeRO; A使用Decrypt【GranteeRO,K(A priv)】得到K(data),K(verify); A从CSP处获取加密文件E(F)和签名SIG(F); A使用K(verify)验证SIG(F)的正确性; A使用K(data)解密E(F),读取数据。 4.2.2 写入数据 A在可信介质S中查询F对应的Grantee表获取GranteeRW; A使用Decrypt【GranteeRW,K(A priv)】得到K(data),K(sign)和; A使用K(data)。加密文件F得到E(F),使用K(sign)对E(F)进行签名得到SIG(F); A将E(F)和SIG(F)发送给CSP。 以下分别以数据属主O授予/取消用户B读写文件F的权限为例,描述对数据进行访问控制的流程。 4.2.3 读写权限授予 数据属主O在可信介质S中查询F对应的GranteeRW; O执行Decrypt【GranteeRW,K(O priv)得到K(data),K(sign),K(verify); O生成新的访问结构T=TV(B); O生成新的元数据项GranteeRW=Encrypt(PK,K(data),K(sign),K(verify),T); O从F对应的Grantee表中删除GranteeRW,并插入GranteeRW。 4.2.4 读写权限撤销 定义V(B)为B的补集中所有属性的析取, V(B)=P(1)P(2) P(N),P(i)C(VB); 数据属主O生成新的数据密钥K(data),新的签名/验证密钥K(sign)刚K(verify); O生成新的访问结构T=TV(B); O生成新的元数据项GranteeRW=Encrypt(PK,K(data),K(sign),K(verify),T),GranteeRO=Encrypt(PK,K(data),K(verify,T); O对文件F使用K(sign),K(verify)进行重签名; O从F对应的Grantee表中删除GranteeRW,Grantee

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论