面向移动云数据存储的高效去中心化多授权机构属性加密方案
摘要
移动云数据存储允许移动用户将个人和企业数据外包到云端,以实现灵活性和节省资金。然而,数据外包带来了较高的机密性和隐私风险。针对移动云数据存储中存在的上述问题,属性加密因其加密策略的灵活性和细粒度的访问控制被提出。然而,现有的多授权中心属性加密方案仍然需要一个可信的中央授权中心发布系统参数和生成用户私钥。它们赋予可信中央授权机构足够的权限来访问用户的明文信息,这个问题被称为密钥托管问题。此外,它们对不同的操作实体要求较高的计算和通信开销。本文提出了一种高效的去中心化多授权中心属性移动云数据存储方案。该方案在不使用任何全局用户身份的情况下,消除了中心授权中心,从而解决了密钥托管问题。通过在线和离线两种方式证明了该方案是灵活的,数据用户端的通信和计算开销更小,并在判定双线性diffie-hellman假设下证明了其安全性。
介绍
移动云存储是移动云计算的主要兴趣服务之一,允许移动用户在云上存储数据,并使用他们选择的任何设备从任何地方访问它们。根据思科全球云指数(CGCI)预测全球数据中心和基于云的IP流量增长的持续努力(白皮书,2010),到2020年,超过92%的工作负载将由云数据中心处理,而8%仍将由传统数据中心处理,这意味着越来越多的企业和组织将迁移到云。此外,更多的人将使用他们的移动设备而不是个人电脑(PC)来访问他们的数据(白皮书,2016),呼吁设计对移动设备友好的云数据共享解决方案。
动机
尽管移动云数据存储所描述的从任何设备在任何地方访问数据的承诺,有一个固有的风险,机密性和隐私的损失,任何旨在解决这些问题的解决方案必须考虑到移动设备的内在限制,低处理能力,有限的存储空间,间歇性的互联网连接和有限的可用能源,如(Abolfazli等人,2015年)所述。对于云服务器和未授权用户而言,数据机密性是设计云数据外包方案的主要安全需求之一,因此必须得到保证(Ali等人,2015)。属性加密(ABE)是Sahai和Waters, 2005年提出的一种解决云数据存储中的访问授权问题的方法。然而,许多现有的ABE方案存在两个方面的问题。第一种是要求其中一个实体具有足够的权限访问机密内容,并要求它是一个可信的实体。二是现有的解决方案计算量大,实体间通信开销大,不适用于资源受限的移动设备。因此,我们基于属性加密设计了一个协议,在保证实体间通信和计算开销最小的同时,没有任何实体具有足够的可见性来获取用户的秘密内容。
技术挑战
在移动云数据存储中,属性加密在保证数据机密性和数据隐私方面面临两个主要挑战。首先,任何实体都不需要拥有足够的权限来生成所有的秘密参数。其次,要执行的不同操作应该承担总体最小的计算和通信开销。现有技术的局限性
在Kamara和Lauter, 2010年,提出了一种数据外包前加密的解决方案。然而,加密限制了可以对数据执行的操作类型,并且要求用户在本地下载所有数据进行解密会导致数据传输负载过大和高昂的财政支出(Ren et al., 2012)。然而,现有的ABE方案如(Michalas和Weingarten, 2017;bethcourt等人,2007;奥斯特洛夫斯基和沃特斯,2007;Müller等,2009;Waters, 2011),依赖一个中央权威来管理系统中的所有属性,以产生系统参数并为用户生成用户密钥。在多授权机构管理不同属性子集的大规模跨域访问控制中,授权机构可能成为性能和安全方面的瓶颈。此外,这样的授权机构拥有足够的权限,可以解密根据给定授权机构的一组属性在访问策略下加密的用户数据,从而导致密钥托管问题。中央机构必须是可信任的,这一额外要求在当今复杂的攻击场景和不惜一切代价获取经济利益的巨大吸引力中不再适用(Ali等人,2015)。因此,解决密钥托管问题是一个重要的需求,解决方案是在利益相关者之间分享在系统中生成秘密参数的权力,使他们中任何人都不能自己生成所有秘密参数。为了提高ABE计算的性能,Zhang等人(2018)提出将数据所有者和最终用户的访问结构和属性相关操作卸载到雾节点上,以减少计算开销。该方案允许属性更新,但由于密钥授权机构是完全可信的,因此仍然继承了中央授权机构方案的缺点。其他作品在(Müller et al., 2009;Chase, 2007)为用户分配GID (global identity)或PKu (public user key),使得不同的属性授权机构可以独立地为用户生成属性密钥。这种方案鼓励服务器合谋攻击,有可能建立一个完整的用户画像,从而解密用户上传的密文。Vaanchig等人,2018年提出的方案通过依赖特定属性的特殊属性授权机构、病态密文和密文-健康-密钥来解决属性和用户撤销问题,从而解决了密钥托管问题。然而,它没有考虑计算迁移,利用了用户全局标识符,助长了属性授权机构合谋攻击。因此,它不太适合移动计算。方法和结果
针对上述挑战,本文提出了一种高效的去中心化移动云存储多授权ABE。我们的方案阻止任何授权机构拥有足够的权限来完全生成用户密钥参数。该方案基于bethcourt等人,2007年提出的CP-ABE方案,以及Li等人,2013年提出的基于半可信云实体的方案,以减少数据用户的计算和通信开销,使操作保持简单且开销恒定。但是,对于不同的用户,我们不使用任何全局标识符,而是委托数据所有者来生成系统参数。本文提出了云用户助手(cloud user assistant, CUA),这是一个基于云的资源丰富的实体,为移动用户提供网关服务,允许独立于系统中属性授权机构数量的恒定计算和通信开销,并可以部分解密用户请求的密文。每个属性权威管理一组不相交的属性,从而带来更大的灵活性(Chase, 2007)。此外,该方案不会产生较大的离线或在线计算开销,在设备本地执行的操作可视为离线,而需要通过异构无线网络与其他实体通信的操作可视为在线。通过修改现有的CP-ABE工具包(bethcourt等人,2006)来评估所提出方法的性能,以适应所提出方案的操作。我们对访问策略和用户密钥中存在的不同属性数量的加密和解密速度进行了经验评估,并将结果与(Vaanchig等人,2018;Chase和Chow, 2009),因为他们采用了一个多机构方案,其结构更类似于我们的研究,而不是(Zhang等人,2018)单一机构方案。本文还提供了我们的工作与两项工作之间在配对、指数和乘法方面的计算和通信开销的理论比较(Zhang et al., 2018;Vaanchig等人,2018)。我们还提供了加密和解密速度的经验比较,并将结果与(Vaanchig等人,2018;蔡斯和周,2009;张等,2018)。结果表明,该方案在执行不同的操作时,所有实体的计算和通信开销都更少,加密和解密操作的速度都有所提高。在双线性判定diffie-hellman假设下证明了该方案是安全的。
本文的主要贡献如下:
- 针对大属性域的移动云数据存储,提出了一种灵活的去中心化多授权ABE,解决了密钥托管问题。
- 引入云用户助手作为雾计算节点与数据用户进行交互,以减少用户端的整体计算和通信开销。此外,该方案只对用户密钥的掩码部分进行操作,数据用户与属性授权机构之间不存在任何预共享密钥。
- 证明了所提方案在判定双线性diffiehellman (DBDH)假设下是安全的,并通过广泛的性能分析证明了所提方案的高效性、有效性和鲁棒性。
论文组织
本文其余部分的结构如下。第2节回顾了相关工作,第3节给出了与属性加密相关的定义背景。在第4节中,我们给出了我们的系统模型、安全模型和设计目标;在第5节中,我们给出了我们的移动云数据共享协议的实现。第6节对我们的方案进行了安全性分析。我们将在第7节中进行广泛的性能分析。最后,第八部分是本文的结论。相关的工作
对移动云计算、属性加密和密钥托管问题3类相关工作进行综述。移动云计算
移动云计算(MCC)通过异构无线网络利用弹性云资源,为固有的资源受限的移动设备提供功能扩展,所有这些都以随用随付的方式进行(Sanaei等人,2014)。为了向移动用户提供基于云的服务,MCC由移动设备、各种无线网络和云资源组成的三层架构,每一层都表现出各自的安全和隐私问题。通过将资源密集型任务从移动设备外包到云服务平台,MCC的执行时间和能耗得到显著改善。然而,利用远程资源会带来一些安全挑战,如(Sood, 2012)中讨论的信任、安全性、可靠性或隐私。与有线通信相比,通过异构无线网络进行通信更耗能,因此需要减少移动设备资源消耗,为移动终端用户提供可持续的按需服务(Shon等人,2014)。根据Riley等人(2011)和Esposito和Ciampi(2015)的研究,移动云计算中两个最重要的安全问题是用户认证和用户授权。本文主要研究存储在云服务平台上的外包数据用户授权问题。我们的解决方案应该对移动设备资源友好,同时加强数据机密性和隐私性。
基于属性的加密
Sahai和Waters, 2005年提出属性加密(Attribute-based encryption, ABE)是为了解决云存储平台上外包数据的访问授权问题。它提供了灵活的加密策略和细粒度的访问控制,成功地提高了其在外包数据安全系统中的应用速度。在ABE中,数据拥有者根据访问策略对其数据进行加密,只有用户的关键属性满足密文中的属性才能解密。属性加密方案主要有两种类型,即Goyal等人2006年提出的密钥策略属性加密(KP-ABE)和bethcourt等人2007年提出的密文策略属性加密(CP-ABE),这取决于访问策略是在用户私钥中指定还是在密文中指定。为了允许跨组织或域的访问控制的灵活性并提高性能,多授权ABE被提出(Chase, 2007;Chase和Chow, 2009)或(Müller等人,2009),其中属性由不同的属性机构独立管理,信任和工作负载分布在多个属性机构上。基于属性的多授权机构授权方案研究面临诸多挑战。然而,现有的多授权机构属性加密工作仍然存在密钥托管限制,即其中一个实体拥有足够的权限来读取和解密用户消息。此外,由于ABE上的操作通常会产生较大的计算和通信开销,所提出的方案应承担最小的计算和通信开销。密钥托管问题
现有的ABE方案依赖于一个中央机构来产生系统参数并为用户生成用户密钥(Michalas and Weingarten, 2017;bethcourt等人,2007;奥斯特洛夫斯基和沃特斯,2007;Müller等,2009;Zhang et al., 2018),赋予中央授权机构足够的权限来解密用户消息。这种问题被描述为密钥托管问题。多权威ABE在(Chase, 2007;蔡斯和周,2009;Müller等人,2009)来解决密钥托管问题。然而,所提出的方案仍然依赖于一个中央机构来产生初始的系统参数集(包括公开参数和秘密参数)以及用户密钥。这样的方案仍然给了中央机构太多的权力,允许它解密给用户的消息。另外提出的方案需要大量的计算和通信开销来生成系统初始参数,以避免所有权限集中在一个实体上。Vaanchig等人,2018年提出的方案通过同时依赖访问结构和用户密钥中的一个基本属性来解决密钥托管问题,并利用病态密文和ciphertext- healkey来解决用户和属性撤销问题。然而,这些操作都不是外包的,这不利于用户在资源有限的移动设备上的体验。需要设计一种既能解决密钥托管问题,又能提供低计算和通信开销的方案。为了解决密钥托管问题,通过将属性授权中心密钥生成和部分密文加密外包给云用户助手,在不需要属性授权中心交互的情况下,由数据拥有者生成公开和主密钥参数,减少数据用户在线和离线的计算量。此外,我们还保证在我们的工作中,没有任何一个授权机构有足够的权限来生成所有的用户秘密参数。我们的工作基于(bethcourt等人,2007)中描述的CP-ABE框架,该框架经过修改以适应我们提出的多机构场景。文中提出了云用户助手(CUA)的思想,类似于Li等人的工作(2013),它在移动用户与多个属性授权中心交互时充当网关,以减少用户端的整体计算和通信开销。不同于(Li et al., 2013)的半可信授权机构(semi-trusted authority, STA)思想,我们的方案中CUA只生成部分用户密钥,并且我们的方案不使用移动用户和不同属性授权机构之间的任何预共享密钥。CUA背后的主要思想是将依赖于访问结构和属性操作的用户端ABE计算开销卸载到云中的一个资源更丰富的实体上,该实体遵循弹性资源供应模型。针对属性加密方案计算和通信开销大的问题,本文将部分密文解密任务从用户处卸载给云用户助手,并利用云用户助手和多个属性授权中心将部分用户密钥生成任务外包给云端,以降低用户端的成本。与(De and Ruj, 2018)等人的工作不同,该方案不需要用户变换密钥进行部分解密,而是使用用户的部分密钥进行部分密文解密。
技术预备
双线性组
设G0和GT是素数阶p的两个乘性循环群,设h是G0的生成器,e是一个双线性映射。双线性映射e具有下列性质:
- 双线性性:对于和,有
- 非简并性:
如果群运算和双线性映射都是可有效计算的,则称G0是双线性群。我们可以注意到映射e是对称的,因为。
线性的秘密共享方案
设q是一个素数,U是所有属性的集合。在U上实现存取结构的秘密共享方案Π在Zq上是线性的,如果:- 秘密对应属性的份额可以构成Zq上的一个向量。
- 对于U上的每个访问策略A,存在一个矩阵,称为共享生成矩阵,以及一个函数p,将M的行映射为属性,即。满足以下条件:假设列向量是矩阵的转置,其中从Zq中随机选取。那么根据Π的秘密s的l份向量等于。对于,份额“属于”属性p(j)。
决策双线性diffie-hellman假设
决策双线性diffie - hellman(DBDH)假设在一个生成元g的素数p阶的双线性组G0的定义如下:在输入和,其中是一个双线性映射,,没有概率多项式时间的对手可以决定是否满足,这是决定是否z=abc或z是一个≠abc的随机元素,有不小的优势。该假设基于离散对数在大数域上难以求解的事实。然后基于DBDH假设证明了所设计方案的安全性。模型和设计目标
在这一部分中,我们给出了系统模型,安全模型,并确定了我们的设计目标。系统模型
协议中有5个主要的网络实体,即云服务提供商(cloud service provider, CSP)、数据所有者(data owner, DO)、数据用户、云用户助手(cloud user assistant, CUA)以及一个或多个扮演相同角色的属性授权机构(attribute authority, AA),如图1所示。- 数据拥有者(data owner, DO)生成系统公共参数和主密钥,建立访问策略,并在该策略下对要外包的数据进行加密。我们假设在我们的方案中,DO有一个本地存储的用户列表来认证每个用户,以满足MCC中的用户认证需求,如Riley等人,2011;埃斯波西托和Ciampi, 2015)。DO负责生成称为数据所有者密钥DO_key的部分用户密钥,并通过安全通道将其发送给授权用户,以及向每个已建立的属性授权机构发送随机盲化密钥参数𝜙,以便它们生成属性授权密钥。
- 云服务提供商(cloud service provider, CSP)提供普通的云存储服务,不拥有任何密钥或秘密信息,无法解密密文并恢复原始消息。
- 该方案中的属性授权中心(AA)负责管理来自其他AA的不相交属性集合,并向数据所有者颁发属性以实现对加密数据的访问策略。方案中的AA进一步生成属性私钥并通过安全信道发送给云用户助手。该方案的属性密钥由AAi_key指定,即AAi的属性密钥,AAi是第i个AA。
- 在本文中,云用户助手(CUA)是一个运行在云上的实体,作为数据用户与不同属性授权机构通信的网关。CUA还代表用户实现了对密文的部分解密。用户将计算开销转移到CUA,通过云用户助手将访问结构和属性操作的开销从移动用户场所转移到云端,大大降低了用户端的整体开销。在本文的工作中,当CUA通过安全信道接收到请求的时,将它们组合成一个单一的结构CUA_key,并仅当嵌入在CUA_key中的属性满足密文中的访问策略时才能对密文进行部分解密。用户将请求CUA_key密钥部分和部分解密的密文用于进一步的解密步骤。由于我们关心的是多机构ABE场景,我们在工作中至少需要两个AA,这样使用云用户助手才更有意义。
- 在收到CUA_key、部分解密密文PCT和DO_key后,数据用户将DO私钥部分和集成的AA私钥部分结合起来生成最终的私钥。工作中的数据用户密钥由user_key描述。此外,当CUA或CSP在云中运行并执行简单操作恢复原始消息时,数据用户从二者下载部分解密的密文PCT。
安全模型
根据有关云计算安全的文献(Yu et al., 2010;Shao等人,2014),我们认为云服务提供商(CSP)是诚实但好奇的。即CSP忠实地遵循所设计的协议,但可以通过被动或主动攻击来获取上传密文的更多信息,并且由于不能访问任何秘密信息,不能参与与任何其他实体的合谋攻击。另一方面,数据用户希望通过独立或合作发起攻击,超出其访问权限访问数据。他们在这项工作中被认为是不可信的。该机构拥有明文信息,并且是生成系统参数和部分数据用户保密参数的机构,因此被认为是可信机构。在我们的方案中,每个AA都被认为是诚实但好奇的。在我们的工作中,每个AA都遵循设计的协议,但可能会与其他AA或其他用户合谋,例如建立一个完整的用户属性概要或获取尽可能多的信息以解密密文。我们假设通信信道被现有的方法(如传输层安全(TLS))很好地保护,并且我们只关注共享数据的机密性。该方案能够抵抗AA合谋攻击、数据用户合谋攻击以及AA和数据用户合谋攻击。设计目标
在本节中,我们将介绍高效的去中心化多授权机构属性加密方案的主要目标:- 细粒度访问控制:数据所有者(DO)应该能够实现对共享数据的访问策略,使对数据的访问控制适用于用户的底层。
- 灵活的访问策略:数据拥有者可以根据自己的意愿共享数据,并且可以在加密数据之前随时更改访问策略。
- 无密钥托管:除了拥有明文信息的数据所有者之外,没有任何授权机构能够拥有足够的权限来生成完整的系统密钥参数集。
- 数据机密性:只有数据用户的属性满足密文中的访问策略,才能解密密文并访问数据。不满足访问策略的数据用户将无法访问共享数据。
- 低计算和通信开销:为了满足移动设备的友好性要求,方案应确保执行最小的计算开销,并且方案中的实体通信开销尽可能低,特别是对于数据拥有者和数据使用者。
一种高效的移动云数据存储协议
在本节中,我们将介绍一个用于移动云数据存储的多授权ABE协议,包括7个操作:系统设置、DO密钥生成、数据加密、AA密钥生成、AA密钥聚合、用户密钥生成和数据解密。在深入研究我们所提出方案的细节之前,我们先回顾一下(bethcourt等人,2007)提出的CP-ABE方案的不同步骤。CP-ABE方案
在本节中,CP-ABE模型的构造包括以下算法:- Setup:设置算法由中心机构执行。以确定有限群大小的隐式安全参数作为输入,选取素数阶p的双线性群G0,生成元g作为输入,输出系统公钥PK和主密钥MK。
- Encrypt:加密算法由数据所有者执行,它在属性的全域上以访问结构A对消息M进行加密,并给定系统公钥PK。
- Keygen:密钥生成算法由中央机构执行,并将主密钥MK和一组描述用户的属性S作为输入。输出用户私钥SK。
- Decrypt:由数据用户运行解密生成算法,将数据用户私钥SK、公开参数PK和包含访问策略A的密文CT作为输入,如果数据用户属性集合S满足CT中的访问结构A,则输出原始消息M。
- Delegate:委托算法由数据用户运行,并允许他为另一个用户生成密钥,以解密密文CT。该算法以某属性集合S对应的密钥SK和一组属性作为输入,输出该属性集对应的密钥。
提出了一种高效的多授权机构ABE方案
我们的新方案是围绕第5节介绍的7个操作构建的。我们的构建
设G0是一个素数阶p的双线性群,设g是G0的生成元。设为双线性映射。是一个安全参数,它将定义组的大小。我们还使用拉格朗日系数Δi,S对于和中的元素集合S。我们进一步利用哈希函数建模为随机预言机,将任何描述为二进制字符串的属性映射为随机组元素。我们的七个操作如下所示。- Setup。该算法选取一个素数阶p的双线性群G0,生成元为g,再选取两个的随机指数,发布公钥或公开参数PK:和主密钥MK:。
- Encrypt(PK,M,T)。该加密算法在给定访问树T的情况下加密消息M。该算法首先为树T的每个节点x(包括叶子节点)选择一个多项式qx。从根节点R开始,按照以下方式自顶向下选择不同的多项式。对于树中的每个节点x,设置度dx比该节点的阈值kx小1,即dx=kx−1。该算法从根节点R出发,随机选择一个秘密,并设置,然后随机选择多项式qR的其他点dR,对其进行完整定义。对于任意其他节点x,设置qx(0) = qparent(x)(index(x)),随机选择dx其他点来完全定义qx。设T中的叶节点集合Y,通过给定树型访问结构T,计算出来构造密文。
- 。数据拥有者密钥生成算法将系统公钥PK和系统主密钥MK作为输入,随机选取一个和一个,计算出DO密钥为,其中。该算法进一步计算密钥,并将其发送到不同的AA槽安全通信信道,从而产生属性授权密钥。
- 。属性机构密钥生成算法需要作为输入数据域所有者的公钥PK,一组属性和一个秘密参数出具keygenDO期间通过安全的方式操作,,为了输出特定用户的密钥被一组美国所需的属性的算法进一步选择j,随机和计算AA密钥。
- 。属性授权私钥聚合将系统公钥PK、用户访问的密文CT以及请求的不同AA产生的不同作为输入,每个AA管理一个不相交的属性集合,并对其编号为N。算法将产生的所有输出为,其中,等于。当且仅当中的属性集合满足CT中的访问结构T时,计算出部分解密密文CT,从而生成部分解密密文PCT。我们将部分解密过程定义为一个递归算法。首先定义了一个递归算法,该算法以密文,与用户属性集合相关联的不同属性授权聚合密钥CUA_key,以及CT中来自T的节点x作为输入。如果节点x是叶节点,则令,定义如下:如果,那么。
我们现在考虑x是非叶节点的递归情况。然后,算法DecryptNode(CT, CUA_key, x)进行如下操作:对于x的所有节点z个子节点,它调用DecryptNode(CT, CUA_key, z)并将输出存储为Fz。设Sx是任意大小的子节点z的集合,使Fz≠⊥。如果不存在这样的集合,则节点不满足,函数返回⊥。否则,我们计算:,其中。
(使用多项式插值)
现在我们已经定义了DecryptNode函数,接下来可以定义部分解密算法。算法首先简单地调用树t的根节点R上的函数。如果树满足S,我们设置。将PCT中的部分解密结果通过安全通信信道发送给用户,完成解密过程。
- 。数据用户密钥生成算法将系统公共参数PK、DO生成的私钥DO_key和云用户助手生成的聚合CUA_key作为输入。算法输出用户密钥为,其中等于。
- Decrypt(PK,PCT,user_key)。该算法以公钥PK、部分解密密文PCT和用户私钥user_key作为输入。
该算法首先计算。此外,解密的算法通过计算。
如前所述,我们提出的数据共享协议包括以下操作:系统设置、DO密钥生成、数据加密、AA密钥生成、AA密钥聚合、用户密钥生成和数据解密。我们假设云用户助手(CUA)和属性授权机构(AA)已经在我们的方案中运行。
- 系统设置:在此阶段,数据所有者以安全参数𝜆作为输入,运行Setup(𝜆)以生成其域的公共参数或公共密钥PK和主密钥MK。在这个阶段,所有的计算都是离线执行的,因此在本地执行,这意味着在这个阶段没有通信开销。这一阶段的高级描述可以在图2中看到,除了DO外,所有其他主管部门都不执行任何操作。
- 生成密钥:在这个阶段,数据所有者(DO)在本地保存一个用户列表,以便对他们进行身份验证。一旦用户成功通过身份验证,数据发布者将使用keygenDO(PK, MK)操作生成其部分的用户秘密密钥,输入为公开密钥PK和主密钥MK。在这一阶段,数据发布者将生成DO_key,该DO_key将通过安全通道发送给数据用户。DO还将向请求用户发布PK以及一个秘密参数𝜙,该参数将被发送到不同的AA槽安全通信信道,用于为特定用户计算属性授权密钥。在这个阶段,有一个来自DO的离线成本,包括对用户进行身份验证和生成DO_key。该阶段的在线开销包括通过安全信道接收用户的认证信息,将生成的DO_key和公钥PK发送给合法用户,最后将秘密参数𝜙安全发送给每个AA。图3给出了数据所有者密钥生成的高级描述。
- 数据加密:一旦DO确定了他想要用于实现访问策略的属性以及负责这些属性的AA,它将向这些AA发布它的公钥PK以及请求的属性列表。成功获取请求属性后,DO将形成加密策略T,并运行encrypt(PK,M,T)操作,将公钥PK、明文M和访问策略T作为输入,输出密文CT并上传到云服务提供商(CSP)。
在此阶段,离线计算包括密文CT生成。这个阶段的在线费用包括收到请求AA的PK。图4提供了数据加密操作的高级描述。
- AA密钥生成:这一阶段的客观性是为用户生成属性授权密钥AA_key,如前所述,云用户助手(CUA)代表数据用户。一旦CUA收到数据用户发送的用户属性配置文件和系统公钥PK,它就向请求的管理这些属性的AA发送属性密钥请求。数据用户的请求包含对管理这些属性的各种AA的一组属性的查询,以及从DO接收到的公钥PK。因此,不同的AA将运行keygenAA(PK, S,𝜙)方法来生成与请求的属性集S相对应的属性密钥。各AA的通过安全通道发送给云用户助手,实现聚合操作。该阶段的离线计算主要是对数据用户的不同属性请求使用公钥加密,并计算。这一步的在线开销涉及将属性配置文件请求上传到CUA,以及由CUA将属性请求上传到每个对应的AA,以及接收各种AA密钥。更多高层次的细节可以在图5中找到。
- AA key 聚合:云用户助手(CUA)在此阶段提供了巨大的帮助,因为其目标是减少数据用户的通信和计算开销。一旦CUA从不同的AA接收到,CUA将通过运行将所有产生的不同的聚合为一个单一的结构,产生,并通过安全信道发送给数据用户用于本地存储。当且仅当中的属性集合S满足CT中的访问结构T时,云用户助理负责部分解密密文CT。该阶段的离线计算代价包括生成和部分解密密文CT。该阶段的在线开销包括从不同的AA接收以及向数据用户发送。关于AA key聚合的详细视图可以在图6中看到。
- 用户密钥生成:用户密钥生成阶段完全由用户在收到DO私钥部分DO_key和CUA私钥部分CUA_key后完成。然后数据用户将运行KeygenUser(PK, DO_key, CUA_key)来生成它的密钥user_key。这一阶段的离线计算开销只用于组装不同的密钥组件以生成user_key。相关的在线成本包括从DO下载DO_key和从云用户助手下载CUA_key。图7给出了该步骤的高层描述。
- 数据解密:数据解密阶段的目标是从部分解密的密文中恢复原始消息。数据用户现在有了自己的私钥user_key,将从云请求部分解密的密文PCT。数据用户运行解密操作(PK, PCT, user_key),产生原始消息m。在此阶段,离线计算开销是由于用户运行解密操作恢复明文。同时,在线代价与下载部分解密后的密文PCT有关,图8给出了解密操作的更高层细节。
安全分析
在本节中,我们将分析高效的多授权ABE在移动云存储中的安全性。我们将在判定双线性diffiehellman (DBDH)假设下证明所提方案的鲁棒性,并重新讨论使我们的移动云数据共享协议安全的细节。我们还将证明,我们的方案具有灵活的访问控制和灵活的共享,并解决了用户撤销问题。在DBDH假设下证明了方案的安全性
回忆一下,定义了生成器为g的素数阶双线性群G0上的判定双线性diffie-hellman(DBDH)问题:在输入上,其中,决定是否满足,即决定是否满足或z是不同于abc的随机元素。在下面的代码中,我们证明了我们的方案在DBDH假设下是安全的。 1. 定理
如果敌手在安全博弈中具有不可忽视的优势,那么存在至少一个概率多项式时间算法可以求解具有不可忽视优势的DBDH问题。
2. 证明
假设在我们的安全博弈中,一个概率多项式时间的对手的优势是𝜖。我们证明了下面的DBDH博弈可以以𝜖/2的优势求解。
设是一个双线性映射,其中G0是素数阶p的乘性循环群,g是它的生成器。首先,DBDH挑战者投掷一枚二值硬币,如果,他设置;否则集合,其中是随机选取的。然后挑战者给出模拟器。然后模拟器在接下来的DBDH游戏中扮演挑战者的角色。
Init:敌手Adv控制妥协机构(在AA中至少有两个机构不受Adv控制),而其余机构由模拟器控制。然后,Adv声明了一个访问策略T0,其中一些属性由模拟器控制的AA管理,而一些属性由非妥协机构管理。
如果敌手在安全博弈中具有不可忽视的优势,那么存在至少一个概率多项式时间算法可以求解具有不可忽视优势的DBDH问题。
2. 证明
假设在我们的安全博弈中,一个概率多项式时间的对手的优势是𝜖。我们证明了下面的DBDH博弈可以以𝜖/2的优势求解。
设是一个双线性映射,其中G0是素数阶p的乘性循环群,g是它的生成器。首先,DBDH挑战者投掷一枚二值硬币,如果,他设置;否则集合,其中是随机选取的。然后挑战者给出模拟器。然后模拟器在接下来的DBDH游戏中扮演挑战者的角色。
Init:敌手Adv控制妥协机构(在AA中至少有两个机构不受Adv控制),而其余机构由模拟器控制。然后,Adv声明了一个访问策略T0,其中一些属性由模拟器控制的AA管理,而一些属性由非妥协机构管理。
Setup:模拟器sim设置:,,,其中均随机选取。同时,模拟器设置参数,并将此公共参数赋给Adv。
阶段1:Adv查询任意数量的属性授权中心私钥,这些私钥对应属性集,由所有授权中心分开管理,但没有一个满足策略T0。模拟器在接收到密钥查询后,根据Adv请求计算出对应的私钥组件。对于所有属性,模拟器随机选取,计算得到,。然后模拟器sim将创建的私钥返回给Adv。
挑战:敌手Adv向挑战者提交两个挑战消息m0和m1。挑战者抛一枚二进制硬币并返回以下密文到Adv。。如果和,我们有和。
阶段1:Adv查询任意数量的属性授权中心私钥,这些私钥对应属性集,由所有授权中心分开管理,但没有一个满足策略T0。模拟器在接收到密钥查询后,根据Adv请求计算出对应的私钥组件。对于所有属性,模拟器随机选取,计算得到,。然后模拟器sim将创建的私钥返回给Adv。
挑战:敌手Adv向挑战者提交两个挑战消息m0和m1。挑战者抛一枚二进制硬币并返回以下密文到Adv。。如果和,我们有和。
因此,是消息的有效密文,Di是私钥的有效组成部分。否则,如果,,则得到。由于是随机元素,从Adv的角度来看,E0是GT中的随机元素(如果DBDH在素数阶群GT中是硬的),因此不包含关于的信息。
阶段2:自适应地重复阶段1。
猜测:Adv提交了一个猜测的。如果,模拟器sim输出,表明它得到了一个有效的DBDH元组,否则输出,表明他得到了一个随机的5元素元组。
猜测:Adv提交了一个猜测的。如果,模拟器sim输出,表明它得到了一个有效的DBDH元组,否则输出,表明他得到了一个随机的5元素元组。
在游戏的构造过程中,模拟器sim计算公开参数和私钥的方式与我们的方案相同。当时,敌手Adv没有得到关于的信息,因此我们有:,其中Pr代表概率。自从模拟器模拟输出他的猜测当时,我们有:。如果,敌手Adv将得到的有效密文。Adv的优势在这种情况下由我们定义:,因为模拟器当给了猜想,我们有:。
DBDH博弈的整体优势是:
如果我们的安全博弈中一个多项式时间的概率攻击者(PPTA)的优势是𝜖,那么在DBDH博弈中PPTA的优势是𝜖/2。因此,如果敌手在我们的安全博弈中具有不可忽视的优势,那么他在解决DBDH问题上也具有不可忽视的优势。基于没有PPTA能够以不可忽视的优势解决DBDH问题的假设,从逻辑上推断出在我们的安全博弈中没有敌手具有显著的优势。因此,所提出的面向移动云存储的高效多授权ABE是安全的。
我们高效数据共享协议的安全性
我们高效数据共享协议的安全性所有ABE系统的基本安全级别都是抗合谋的,这意味着两个或多个授权机构不能通过组合他们的秘密参数来获得非法的额外权限。在我们的方案中,生成数据拥有者私钥需要随机选择一个私钥r来防止用户合谋攻击,随机选择一个来防止用户伪造自己的私钥。AA私钥的生成也涉及到选择一个秘密rj以防止AA共谋攻击,其中秘密𝜙=g(r+𝛾)将用于防止AA与用户共谋攻击。在全局级别上,云用户助理将所有为特定用户生成的属性授权密钥组装到一个名为CUA_key的结构中。由于属性授权机构不拥有数据用户生成的参数g𝛾,因此不能从部分解密后的密文PCT=e(g,g)(r+𝛾)s中获得任何信息,因此CUA的部分解密性能同样良好。此外,如第5.2.1小节所述,资料使用者不能使用gr参数,而该参数的计算是在民政事务总署的协助下,透过机管局与资料使用者之间的盲化计算而完成的。然而,我们注意到,给定g𝛾,很难提取𝛾的值,因为有限域的固有安全性质,其离散对数是一个难题,换而言之,给定g𝛾,很难恢复秘密𝛾,因此,在DO密钥部分发送g𝛾给用户,在AA密钥生成中发送g(r+𝛾)给CUA是完全安全的。然而,g𝛾或g(r+𝛾)值可能被任何未经授权的嗅探实体滥用,因此通过安全通信通道发送。
利用数字信封技术(DET)对数据进行加密,并将密钥嵌入到密文中,使得只有满足访问策略属性的用户才能恢复对称密钥并解密,从而保证了数据的机密性。此外,数据用户使用公钥加密向不同的AA发送属性请求,使得CUA无法获知每个用户请求的属性集。
细粒度的访问控制和灵活的数据共享方案基于CP-ABE,允许DO为用户指定一个描述其个人属性的访问策略。因此,年龄≤40和职业=牙医或姓名= 'John Doe'等访问策略允许以年龄小于或等于40岁的牙医或姓名为'John Doe'的人为目标,这实际上展示了一种细粒度和高度灵活的方法。
用户撤销
在我们的方案中,用户撤销问题是指拒绝对被撤销用户的数据进行访问。这可以简单地通过在用户密钥中嵌入时钟或时间戳来实现,这样我们可以确保用户需要更新其密钥参数才能访问加密信息。这保证了对数据用户访问控制的某种延迟撤销。更复杂的撤销机制包括使用代理重加密重新计算不同访问策略下的密文,或者不断更新公开参数并为未撤销的用户颁发密钥,但这超出了本文的范围。在(Wei et al., 2018)中可以找到一篇关于用户撤销和属性撤销的很好的工作。性能分析
在本节中,我们从数据拥有者和数据使用者的离线和在线计算开销方面评估了所提出的移动云数据共享协议的性能。本文还提供了在概念验证实现中对数据分发系统的计算开销的估计。我们在Linux Ubuntu IntelⓇCore™i5-2450 M上进行了实验,该系统具有4 GB RAM和2.5 Ghz的中央处理器(CPU)。我们的代码来源于CP-ABE工具包(bethcourt et al., 2006)。我们使用了PBC(pairing-based cryptography,林恩版本0.5.12),在实现中使用了类型A曲线。计算一次配对运算的时间为6ms,在G0上计算一次幂运算的时间为5ms,而在GT上计算一次幂运算的时间为0.7 ms。在G0和GT上计算一次乘法的时间为0.03 ms。我们在表1中提供了几个用于性能分析的变量,并比较了我们的方案、具有属性更新的高效外包单授权机构(Zhang et al., 2018)、开创性的无密钥托管的多授权机构ABE(Chase and Chow, 2009)以及具有双重撤销的无密钥托管的多授权机构ABE(Vaanchig et al., 2018)。在线计算成本
性能目标是尽可能地减少数据拥有者和数据使用者两端的在线计算。在本文中,我们考虑在线计算和在线通信这两个术语可以互换。在我们的方案的系统设置阶段,没有在线成本,因为一切都是由DO离线执行。数据加密阶段需要将公钥PK上传到AA,下载形成访问策略所需的属性,对明文数据进行加密,最后将密文上传到云服务提供商(CSP)。数据拥有者密钥生成阶段要求DO将公钥以及用户生成的部分密钥发送给合法用户,这意味着首先需要对用户进行身份验证,然后需要向每个请求的AA发送一个秘密参数𝜙=g(r+𝛾)。用户密钥生成阶段要求数据用户下载组装好的属性授权私钥CUAkey和DO私钥部分DO_key,生成最终私钥user_key。最后,数据解密阶段要求用户从云端下载部分密文。基于在线计算的性能设置,我们将所提方案与Zhang et al., 2018)和in (Vaanchig et al., 2018)中的工作进行了比较。此外,由于每个实体都需要公钥来执行大多数操作,因此本文没有描述下载或上传公共参数的成本。表2和表3分别给出了数据拥有者和数据使用者在线计算代价的渐近值。在第8节可以对表项进行比较。
离线计算成本
我们的另一个性能目标是,与之前的方案相比,确保在数据所有者和数据用户前提下执行的操作是高效和安全的,特别是Vaanchig等人的工作(Vaanchig等人,2018)和Zhang等人的工作(Zhang等人,2018)。在本节中,我们还对(Chase和Chow, 2009)提出的一个非常有趣的问题做出了回应,即在不需要中央授权机构的情况下,是否有一个解决方案来解决属性授权机构(AA)在系统设置中的计算和通信开销,因为通常每个AA都需要相互通信以生成系统范围的公钥。我们在本小节中给予肯定答复,因为我们委托数据所有者产生系统公开参数和主密钥。 分析了G0和GT下的乘法、幂乘和配对运算的计算开销,以及给定访问结构和用户密钥中属性个数时的加解密速度。
乘法、乘幂和配对代价
让Cm表示G0中乘法的代价,Ce表示G0中幂运算的代价,Cp表示GT中配对的代价。对于数据所有者和数据用户执行的操作,我们给出了我们的方案、Vaanchig等人2018年的工作和Zhang等人2018年的工作之间的计算比较。结果见表4和表5。第8节对不同方案下数据拥有者和数据使用者的离线计算代价进行了比较分析。加密和解密时间
我们对该方案的加解密运算速度进行了实证比较,并将结果与Vaanchig等人(2018)以及Chase和Chow(2009)的工作进行了比较。由于(Zhang等人,2018年)中的方案与我们的方案不具有相同的架构,我们将该方案与(Vaanchig等人,2018年)和在(Chase and Chow, 2009年)中的工作进行比较。速度测量的结果如图9和图10所示。讨论
根据上面第7节的性能分析,表2显示我们的方案在密钥生成阶段产生的在线计算开销比(Zhang et al., 2018)和(Vaanchig et al., 2018)中的方案更多。(Zhang et al., 2018)中的方案是一个优秀的方案,但它没有针对多个授权中心的应用进行设计。此外,由于密钥授权机构是可信任的,因此继承了密钥托管方案的局限性。该方案(Vaanchig et al., 2018)依赖属性授权机构生成用户私钥。然而,它确实依赖于用户GID,这鼓励了服务器共谋攻击。我们通过依赖数据所有者生成部分用户密钥来解决这两个问题。这个要求是强制性的,以防止我们的方案使用任何用户全局id,并提供一个无密钥托管的方案。 此外,通过信任数据拥有者(DO)发布公开参数(PK)和主密钥(MK),解决了Chase和Chow, 2009)提出的在设置操作中不需要属性授权机构交互就能生成系统范围公钥的问题。除生成密钥外,对数据所有者的在线计算代价的其他阶段相同,证明了所提方案在安全性和灵活性方面比Zhang et al., 2018年的方案和Vaanchig et al., 2018年的方案更高效。
基于表3,由于使用了云用户助手,用户不直接与各属性授权机构通信,数据用户对部分解密密文执行简单操作,降低了用户端在线计算的开销。
离线计算中,由于数据拥有者负责生成初始参数集和生成部分用户密钥,因此在系统设置和密钥发放阶段存在一定的开销,如表4所示。如前所述,这些开销保证了一个无密钥托管的方案和一个灵活的模型,而不需要使用用户全局id。移动用户级的离线计算与(Zhang et al., 2018)中优秀的单授权密钥托管方案一样低。
同时,我们注意到,考虑到图9和图10所示的属性数量,我们的方案在加密和解密速度方面表现更好。该方案比Vaanchig等人,2018年提出的方案和Chase and Chow, 2009年提出的方案具有更高的效率。
离线计算中,由于数据拥有者负责生成初始参数集和生成部分用户密钥,因此在系统设置和密钥发放阶段存在一定的开销,如表4所示。如前所述,这些开销保证了一个无密钥托管的方案和一个灵活的模型,而不需要使用用户全局id。移动用户级的离线计算与(Zhang et al., 2018)中优秀的单授权密钥托管方案一样低。
同时,我们注意到,考虑到图9和图10所示的属性数量,我们的方案在加密和解密速度方面表现更好。该方案比Vaanchig等人,2018年提出的方案和Chase and Chow, 2009年提出的方案具有更高的效率。