摘要

云存储中的数据共享在信息通信技术领域备受关注，因为它可以为用户提供高效、有效的存储服务。为了保护共享敏感数据的机密性，通常采用密码技术。但是，在数据共享的云存储中，数据保护仍然面临着巨大的挑战。其中，如何保护和撤销密钥是最根本的挑战。为了解决这个问题，我们提出了一种新的云存储数据保护机制，它具有以下属性。
1）加密密钥由这两个因素保护。只有当两个因素中的一个起作用时，加密密钥的保密性才会保持。
2）通过集成代理重加密和密钥分离技术，可以有效地撤销加密密钥。
3）采用基于属性的加密技术，对数据进行细粒度保护。安全性分析和性能评估分别表明了该方案的安全性和有效性。

索引术语：双因素，可撤销性，细粒度，基于属性的加密，代理重新加密，云存储

引言

近年来，基于云的应用程序的开发和部署在工业界和研究界获得了巨大的推动力，受其诱人的按需特性和优势的驱动。云存储是最成功的基于云的应用[1]-[7]，因为它很好地匹配了巨大的数据共享需求。与多个数据共享者共享巨大的数据是一项成本消耗的任务，数据所有者端的成本通常与数据共享者的数量成正比。而在云存储的帮助下，这个成本可以降低到共享数据的大小。数据共享者需要做的唯一一件事就是将数据上传到云端，并授予数据共享者访问权限。之后，数据共享者可以从云端获取数据，而不是数据所有者。
尽管云存储中的数据共享有很多好处，但它也给对手带来了许多未经授权访问共享数据的机会。为了保护共享数据的机密性，通常采用密码方案。密码方案的安全性来源于底层密码密钥的安全性。目前，在大多数现有的密码方案中，密码密钥只是简单地存储在计算机中。虽然有报道称，某些病毒[8]可以泄露存储的密钥。为了解决密钥暴露问题，人们提出了许多技术，如密钥隔离公钥技术[9]、[10]和并行密钥隔离公钥技术[11]、[12]。
据我们所知，直到Liu等人[13](后来被命名为LLS+15)的工作，云存储中的密码密钥暴露和撤销问题才被揭示。在[13]中，他们提出了一种新的双因素数据保护机制。密码密钥分为两部分。一个保存在用户的计算机和另一个存储在一个安全设备(如智能卡)，这是类似于电子银行。只有当这两个部分中的一个对对手保密时，加密密钥的机密性才会被保留。因此，“双因素”被命名。此外，一旦用户的安全设备丢失或被盗，可以通过使用代理重新加密技术来撤销它。而LLS+15的目标是解决数据存储的安全问题，而不是云计算中的数据共享场景。特别是，LLS+15中的一个密文本质上是一个基于身份的密文，只能由一个用户解密，而不能像在数据共享场景中那样由一组用户解密。最近，数据共享越来越受到人们的关注。虽然隐私仍然是关键问题，也是一个同样显著的挑战，它降低了云[14]中数据共享的增长。

原始的解决方案：乍一看，我们似乎只需要将LLS+15中的IBE方案替换为ABE方案就可以解决数据共享场景中的密钥暴露和撤销问题。然而，由于LLS+15的低效率和云存储的“按次付费”性质的矛盾，它不能很好地用于云存储的数据共享。
在LLS+15中，一旦云服务器接收到加密的数据，它将使用与用户安全设备对应的公钥加密(public key encryption, PKE)对数据进行加密。而在数据共享场景中，密文将用于多个用户，云服务器将数据加密为多个公钥下的多个密文。此外，即使数据是与一个用户共享的，它也应该被解密两次。具体来说，一个用于IBE加密，另一个用于PKE加密。这使得解决方案效率低下。
LLS+15还有一个潜在的缺点。为了实现密钥撤销，LLS+15中的密钥生成中心需要存储每个安全设备的秘密。当IBE方案直接被ABE方案取代时，秘密的大小会增加。这将是密钥生成中心的负担。

我们的技术方案：针对原始方案的不足，我们集成了基于属性的加密技术、代理重加密技术和密钥分离技术，在解决密钥暴露和撤销问题的同时，消除了PKE的使用和密钥生成中心存储安全设备的秘密，并支持细粒度的访问控制。在ls +15中，密文有两种格式。一个是IBE密文，一个是PKE密文。然而，我们提出的框架中所有的密文都是ABE密文。使我们的框架工作良好的主要困难是如何撤销旧的安全设备和如何新的安全设备可以正确地进行解密。为了撤销旧的安全设备，我们需要云在使用代理重新加密技术将旧的密文发送给用户之前更新它们。当用户请求新的安全设备时，用户应该向密钥生成中心提供一个新的密钥，以生成一个新的密钥，用于解密更新后的密文。

与LLS+15相比，我们提出的解决方案具有以下特性。
  • LLS+15主要针对安全数据存储，而我们主要关注的是安全数据共享。这是由不同类型的加密解决方案提供的两种不同的功能。
  • 我们采用另一种方法实现了双因素技术来解决密钥暴露和密钥撤销问题。因此，我们的解决方案中只存在一种密文，这使得我们的解决方案更容易理解和实现。此外，我们的方案中的密钥生成中心除了自己的私钥外，不需要存储任何其他秘密。
  • 我们明确地展示了如何在不泄露存储在安全设备中的秘密的情况下进行解密。而这部分在LLS+15中没有提到。
  • 当我们使用ABE作为IBE时，我们的方案在计算成本和存储成本方面比LLS+15更高效。详情见第六节。

相关工作

在本节中，我们将简要回顾具有数据共享场景中所需的类似功能的加密方案，并解释为什么它们不能完全实现我们的目标。
1）处理密钥暴露问题的密码方案：2002年，Dodis等人[9]提出了一个密钥隔离的公钥方案，这是第一篇处理私钥暴露问题的论文。在这样的系统中，有两个密钥。一个名为主密钥的密钥存储在物理安全但计算有限的设备(安全设备)中;另一个存储在不安全的设备(如计算机)中，可以使用主密钥定期更新。主密钥和公钥始终保持不变。后来，Dodis等人[10]将关键的绝缘技术引入到数字签名中。但是，私钥更新越频繁，主密钥暴露的风险就越大。为了解决这个问题，2006年，Hanaoka等人[11]引入了并行密钥绝缘公钥加密。在[11]中，有两个独立的主秘钥，这大大降低了主秘钥暴露的风险。但是[11]的安全性证明是在随机oracle模型中得到的。2007年，Libert等人[12]提出了一种在标准模型中安全的并行密钥绝缘公钥加密方法。2008年，Liu等[15]应用关键绝缘方法解决了环签名中的关键暴露问题。
在上述方案中，都使用安全设备定期更新每个用户的私钥。而且，一旦更新了私钥，安全设备就不再参与解密阶段。但根据云计算数据共享场景的要求，不希望用户的私钥在每个时间段都更新，每个解密阶段都需要安全设备的参与。
2）具有细粒度访问控制的加密方案：2005年，Sahai等人在[16]中首次引入了基于属性的加密(attribute based encryption, ABE)的概念，并在[17]中进行了进一步的讨论。后来，在2006年，Goyal等人[18]形式化了两种互补的ABE：密钥策略ABE (KP-ABE)和密文策略ABE (CP-ABE)。在KP-ABE中，私钥与策略(布尔公式)相关联，密文与一组属性相关联。而CP-ABE则是KP-ABE的相反情况。在[18]中，提出的ABE方案只支持单调访问结构。随后，Ostrovsky等人提出了一种新的支持非单调访问结构的KP-ABE方案。他们还给出了一个基于[20]技术的CP-ABE结构，其中提出了一个CP-ABE安全的随机oracle模型。2007年，张等人[21]在标准模型中提出了一种具有非单调访问结构的CP-ABE方案。随后，许多高效、安全、富有表现力的ABE方案被提出[22]-[25]。然而，利用这些方案只能实现细粒度的访问控制，而不能实现云计算数据共享场景所需的可撤销性和双因素保护。
2016年，Liu等[26]利用基于双因素和属性的签名技术，提出了基于web的云计算服务的细粒度双因素认证访问控制系统。他们专注于用保护隐私、细粒度和防止密钥暴露的方式构建用户身份验证。因此，Liu等人的方案不能像我们在本文中所做的那样对密文提供细粒度的访问控制，而且密钥撤销也不在[26]的范围内。此外，[26]中采用了成本高的零知识证明技术，这与云存储的“付费阅读”特性相违背。因此，[26]中使用的方法不能用于我们的建议，需要新的方法来实现双因素技术。
3）具有可撤销性的密码方案：由于本文提出的解决方案是基于可撤销性的，我们将回顾具有可撤销性的可撤销性的密码方案。2008年，Boldyreva等人[27]引入了一种可撤销的ABE方案，该方案是对其主要贡献——可撤销的IBE的扩展。在他们的方案中，未被撤销的用户需要定期更新他们的私钥，这非常不方便。
为了解决这一问题，Attrapadung等人[28]提出了一种新的具有可撤销性的ABE方案，在该方案中，未被撤销的用户不再需要定期更新他们的私钥，但发送方需要知道撤销列表。为了解决这个问题，同年，Attrapadung等人[29]提出了另一种ABE方案，作者得出结论，有两种方法可以让ABE具有可撤销性，即直接方法和间接方法。直接撤销要求发送方在加密过程中知道撤销列表，而间接撤销要求未被撤销的用户定期更新他们的私钥。直接撤销相对于间接撤销的优点是，未被撤销的用户不需要定期更新他们的私钥。相反，间接撤销相对于直接撤销的优点是发送方不需要知道撤销列表。他们结合了直接撤销和间接撤销两种方法的优点，提出了第一种混合可撤销ABE方案。随后在[30]，[31]中提出了完全安全的可撤销ABE。他们使用复合阶双线性群来实现完全安全，这比素数阶双线性群效率低。但是，在我们的提议中，我们只需要发布一个新的安全设备来撤销旧密钥，而不需要更新所有其他安全设备，我们不需要为所有被撤销的安全设备维护一个撤销列表。因此，我们认为我们的方案提供了一种替代方法来解决长期存在的ABE可撤销性问题。

文章组织

其余的论文组织如下。在第二部分中，我们给出了方案的模型和设计目标。在第三节中，我们给出了复杂性假设的必要背景。在此之后，我们在第四节给出了我们的云存储细粒度双因素数据保护机制，在第五节给出了我们的安全性分析，在第六节给出了我们的方案的性能评估，最后在第七节给出了结论。