TRAK-CPABE

 

本文是来源于Journal of Information Security and Applications的一篇论文：

• 题目：TRAK-CPABE: A novel Traceable, Revocable and Accountable Ciphertext-Policy Attribute-Based Encryption scheme in cloud computing
• doi: https://doi.org/10.1016/J.JISA.2021.102914

 

这篇论文读完之后，发现了一些小问题，感觉不能实现其文中提到的属性撤销、密钥更新等问题。其方案本身可能也存在一些错误。本文再次尝试对该论文进行分析。（说明，由于公式符号难以输入，故方案并未描述得很详细，阅读时可对照原文。）

 

文章架构介绍

1. 介绍

云计算是最近最有前途的技术之一。它按需提供大量服务。存储即服务是云中的主要服务之一。它为数据用户提供了强大的计算能力和数据存储空间。因此，个人或商业公司受益于易于共享和节约成本的优势。但是，安全性被认为是云计算的主要问题。一旦数据用户将敏感数据外包给公共云服务器，数据用户就失去了直接控制，因为云服务器提供商在大多数时候管理着资源集。由于这些原因对于存储在云中数据，数据用户希望对其私有数据进行加密和强制自我授权，以限制访问。传统的加密方法分别为每个授权用户加密数据并生成密钥。一对一加密保证了数据的保密性。但是，这无疑是增加了数据所有者的开销。

基于属性的加密(ABE)提出了一种新的加密原语。在外包给云服务器之前，确保数据加密和访问控制。它被认为是一对多加密。ABE在用户私钥和密文之间定义了一个访问结构和一组描述性属性。基于密文策略属性的加密(CPABE)和基于密钥策略属性的加密(KPABE)提出了两种加密方案。在CPABE中，数据所有者在加密时将访问结构嵌入到密文中。用户的私钥用一组描述性属性进行标记。在KPABE中，密文由数据所有者用一组属性标记，而用户的私钥则根据访问结构交付。KPABE方案适用于具有预定义规则和属性的结构化组织。因此，它无法部署在用户和属性数量庞大的大规模环境中。而CPABE不仅保护了用户数据的隐私，还保护了用户的访问策略和解密密钥。它确保了可伸缩性、灵活性、抗共谋和细粒度访问。然而，这种访问控制机制不能确保可追溯性、撤销性和问责性。

所以，作者本文的目标是提出了一个基于可追溯(T)、可撤销(R)、可问责(a)和密钥托管免费(K)的CPABE解决方案(TRAK-CPABE)。且作者也说明该方案使用白盒跟踪和完全可信的审计人员来确保问责。为了避免关键的托管问题，我们调用两个授权机构。它们各自生成部分密钥。最后，在切分数据后，通过对单个随机切片进行重新加密来实现撤销。

2. 一些相关工作

文中区分了两种可追溯性，即白盒可追溯性（追踪密钥）和黑盒可追溯性（跟踪解密设备，不知密钥详细使用流程）。白盒跟踪基于格式良好的解密密钥作为输入，而黑盒跟踪以解密设备作为输入。黑盒可跟踪性隐藏解密密钥，但搜索解密设备中使用的用户身份。在黑盒跟踪中，叛徒（泄露自己合法密钥的用户）应该在共享之前屏蔽解密密钥。然而，追踪隐藏密钥的复杂性需要大量的双线性映射。因此，掩蔽和跟踪算法的复杂性变得非常重要。跟踪算法的用户范围大，属性灵活，增加了算法的计算时间。此外，黑盒可追溯性通常具有较低的加密和解密效率。因此，具有黑盒可追溯性的CPABE的商业应用在一定程度上受到了限制。由于当解密密钥不是格式良好的时候，白盒可跟踪性就会失效，因此在将密钥交付给适当的用户之前，显然需要验证密钥的合法性。总之，应用白盒跟踪，使用格式良好的密钥，提高了效率，减少了跟踪成本和时间，并支持可伸缩性和大范围。它是一种轻量级和高效的跟踪方法。因此，它更适合商业应用。

追踪恶意用户是必要的，但最重要的是阻止他们。所以要考虑用户撤销问题。

撤销表示阻止非授权用户访问的行为（撤销用户）。为此，需要确定安全目标，以便选择合适的撤销模型。文中区分直接和间接撤销解决方案。直接撤消，数据所有者必须根据撤消列表定期向未撤消的用户发出更新密钥（密钥不被更新者即为撤销用户）。在间接撤销中，数据所有者在加密时将撤销列表嵌入到密文中。

作者提出的方案是免密钥托管的，但是在表1中，表头“Key escrow”改为“Key escrow free”更为合适。另外通看全文，本文只提出用户撤销方案，并未涉及到属性撤销以及密钥更新功能。

 

3. TRAK-CPABE

3.1 TRAK-CPABE模型

（图3中，存在一处错误，CSS与DU的交互，应是CSS指向DU，且是“download　ciphertext”）

• DO：将数据外包和发布，在适当的数据中定义和嵌入访问结构，基于撤销列表对随机切片执行重新加密。
• TPA: 一个好奇但诚实的权威。它生成部分公钥和主密钥。它负责跟踪恶意用户和检查密钥是否正常
• CAS: 专用的云服务器，用于访问控制。它使用TPA执行设置，keygen和跟踪算法，以避免密钥托管问题。它提供部分密钥。它将数据分成n个共享，在一个随机选择的切片中执行对称重加密，并将其发送给数据所有者以执行重加密。
• CSS: 表示存储服务器
• DU: 如果描述性属性集与访问结构匹配，则解密数据, 他应该通过匹配，然后根据随机切片解密过程，并且不应该出现在撤销列表中。
• Auditor: 如果跟踪用户声明自己是无辜的，则以公开方式验证接收到的密钥的有效性。

3.２方案说明：

1. 首先是系统初始化，TPA生成全局参数。DU、CAS和TPA都生成部分公钥和主密钥，以避免密钥托管问题。
2. 用户密钥是分布式生成的。部分机密组件被发送给适当的用户。密钥生成过程的去中心化旨在解决密钥托管问题。
3. 数据所有者对数据进行加密、嵌入访问结构并发布数据。
4. 数据用户要求访问加密数据。如果他被授权，他会使用密钥来解密密文。否则，他应该执行匹配，然后解密阶段。在解密数据之前，他应该先解密随机切片。
5. 如果发生任何撤销，数据所有者将基于新的访问结构执行重新加密。
6. 为了确保问责制，实施了审计和跟踪算法
7. 为了保证白盒可追溯性的良好运行，设置了密钥完整性检查机制，防止密钥被伪造。

3.３ 详细方案

１.初始化阶段：

分为TPA初始化、CAS初始化、DU初始化。

TPA首先公布了全局参数GP，然后进行初始化，生成TPA的主密钥$MS{K}_{TPA}$$MSK_{TPA}$，和TPA的公共参数$P{P}_{TPA}$$PP_{TPA}$。

CAS进行初始化，生成CAS的主密钥$MS{K}_{CAS}$$MSK_{CAS}$，和CAS的公共参数$P{P}_{CAS}$$PP_{CAS}$。其中，文中提到CAS选择随机值${\beta }_1$$\beta_1$和${\beta }_2$$\beta_2$，但是根据后文内容，此处应为$\beta$$\beta$和${\beta }_2$$\beta_2$。

DU进行初始化，接受了TPA发送过来的GP，生成私钥$secre{t}_{du}$$secret_{du}$和公钥$P{P}_{du}$$PP_{du}$。

２.密钥生成阶段：

为了避免密钥托管问题，由DU和trak双方（TPA、CAS）共享密钥生成算法。DU向TPA发送随机、签名、身份、公共验证密钥和一组描述性属性。事务管理处应先根据该签名核实DU的合法性。然后，它生成并以安全的方式发送部分密钥。随后，CAS生成用户密钥的第二部分。所以该阶段分为DU密钥生成、TPA密钥生成、CAS密钥生成、DU计算出完整用户密钥sk。

DU首先选择随机值ｒ生成签名sign，并向TPA发送了随机值ｒ，签名sign，公钥$P{P}_{du}$$PP_{du}$，用户ID和用户属性集合S。

TPA对DU发送过来的签名进行验证，验证通过后，TPA将在TPA-list记录表中根据r和ID去查找，如果匹配到了，将r替换成r'，否则，在列表中添加一条新记录。然后计算生成部分密钥$S{K}_{TPA}$$SK_{TPA}$。其中$D_{TPA}^{{}^{‴}}=g^{\frac{{\alpha }_3}{{\beta }_2+h_2^{{}^{\prime }}}{g}_1^{a_1}}$$D_{TPA}^{'''}=g^{\frac{\alpha_3}{\beta_2+h_2^{'}}g_1^{a_1}}$表达错误，应为$D_{TPA}^{{}^{‴}}=g^{\frac{{\alpha }_3}{{\beta }_2+h_2^{{}^{\prime }}}}{g}_1^{a_1}$$D_{TPA}^{'''}=g^{\frac{\alpha_3}{\beta_2+h_2^{'}}}g_1^{a_1}$。

CAS根据$S{K}_{TPA}$$SK_{TPA}$计算生成第二部分密钥$S{K}_{CAS}$$SK_{CAS}$。

DU由$S{K}_{CAS}$$SK_{CAS}$计算出完整用户密钥sk。

3.加密和重加密阶段：

在将数据外包之前，应进行加密，以避免未经授权的访问。数据所有者使用LSSS访问结构来实施访问控制。重加密算法确保撤销。云访问服务器分成多个共享，随机选择单个切片，并根据重新加密的密钥执行撤销。

DO加密：利用LSSS（线性密钥共享方案）作为访问结构加密原数据，并选择r作为秘密值（这里问题来了，在生成用户密钥过程中，r已经作为DU的随机值并被记录在TPA和CAS的列表中，即TPA、CAS、DU都知道r，那么此处还用r做DO加密的秘密值，就很离奇。如果DO/DU的r不一致，解密过程无法计算。若r一致，则不是“一对多”加密，是“一对一加密”，每个DU生成的r是不一致的，此方案至此已存在很大的问题了，对这里有不同看法的同学可以联系我，一起讨论哦）。当然，论文里最终还是给出了密文CT。

重加密过程：

撤销过程是基于单个随机切片的重新加密（重新加密就算是撤销用户了？）。如果被撤销的用户成功检索并解密所选共享，就可以上传（这里应该是download吧，原文是upload，为什么是上传呢？不理解！）密文。否则，访问将被阻塞。撤销过程是数据所有者和云访问服务器之间的共享操作。

CAS将CT切分为n份，利用对称密钥k1对其中随机选择的一份加密，加密后提交给CSS进行存储。如果发生了撤销，DO检索到这块切片，使用新的访问结构再次加密。

4.解密阶段：

由于我认为加密阶段存在问题，解密过程暂时不做分析。

5.额外的算法：

论文作者提到本文满足白盒追踪，但是应用白盒跟踪的基础是用户的密钥要求格式完整。什么是所谓的格式完整。要满足论文5.2.5节中提出的1-5公式验证。

其中第2个公式，等号后面不应该是对号间隔，而应该是乘号操作。

第5个公式是不成立的。等号前后内容不相等。所以此处也存在一些错误。

 

4. 总结

研读完这篇论文，感觉漏洞百出，错误很多，比如说缺乏安全模型介绍，图4中CAS、TPA向DU共享MSK是不正确的，文中很明确的说明了MSK不共享，单独持有。总之很不推荐给大家读这篇文章。（PS：不过你都看到这里了，应该是正在读吧）我在看这篇论文时，心里也有很多问号，在网上再查询不到有关于这篇论文的分析，那就我来吧。当然这篇论文中也有一些值得学习的地方，毕竟期刊还是很不错的。（PS：我啥时候可以发一篇呢）

本文所写有些内容是对文章的翻译，有些是自己的理解，个人理解有限，有不同意见的同学欢迎一起探讨，共同补充这篇博文。