参考文献为2023年发表的Achieving Revocable Attribute Group-Based Encryption for Mobile Cloud Data: A Multi-Proxy Assisted Approach

动机

对于目前的代理辅助的可撤销基于属性加密来说，外包解密存一些缺点。当多个具有相同属性的用户请求外包转换时，代理服务器必须执行多次转换操作，这增加了代理服务器计算开销和用户请求时间。由于移动设备计算能力较小，所有才有了外包解密，将大部分计算开销让代理服务器计算，将小部分计算开销留给移动设备上的数据使用者。传统的代理服务器外包解密系统如下图所示，当数据使用者请求某一个云上的加密数据时，它需要先从云中下载密文，然后将密文和转换密钥一起发送给代理服务器解密后，代理服务器再将部分解密的密文发送给数据使用者，然后数据使用者在解密。我们可以看出，在基于属性的加密中，如果很多用户属性相同，并且他们都想要对应于该属性加密的密文，那么这个系统的通信开销就会很大，对于代理服务器来说计算开销也很大，因为每次都要对想用的密文进行一个部分解密。本篇论文的就是解决相同属性的用户解密时和代理服务器之间多次冗余的通信和计算开销。

知识补充

撤销机制

        撤销机制分为三类：直接撤销、间接撤销、服务器辅助撤销。在直接撤销中，数据使用者将撤销列表和密文一起发送，并且需要在撤销的时候更新；对于间接撤销需要为未撤销用户更新私钥以及更新密文。而服务器辅助撤销如上说所，将解密分为两个部分，对于被撤销的用户，服务器拒绝为其解密第一部分。对于直接撤销中，撤销列表和密文是如何嵌在一起的还是有点疑惑。

群签名   

        论文底层使用了一个群签名的，可以参考上一篇博客内容群签名

结果

        代理服务器拥有属性集合，具有想用的属性集合的用户会被分配到该代理服务器中，这说明用户和代理服务对于一个密文具有想用的解密能力，实现细粒度访问控制（论文中说群签名实现细粒度访问控制，我对这一个说法有点不理解）。用户不在具有转换密钥，也不再直接云服务器交互，这些功能直接全部给了代理服务器从而减少了用户和云以及代理服务器的交互通信开销。当发生撤销时，无需更新密文和用户密钥，具体是通过让撤销用户恢复不出秘密值而解不了密。

方案构建

        系统中有五个实体存在：云服务、数据拥有者、中心权威机构、代理服务器、数据使用者。系统模型如下图：

方案有以下算法组成：

        初始化：

        转换密钥生成：对于每一个代理服务器（对于一个属性集合）分配一个转换密钥 

        用户密钥生成：对于一个代理服务器，在转换密钥生成阶段CA会为其分配一个z次的多项式。此时，CA会为群中的每一个用户都为其分配z对（x,y）用于帮助用户恢复秘密值k。

         加密：就是普通的ABE加密的方式

        申请访问：使用了上面提过的群签名方案，单纯就是应用没有任何的修改。这里用户作为证明者，证明自己拥有合法的私钥即SDH的知识。代理服务器在这里作为验证者，验证用户提交的知识签名是否有效。

        转换阶段：首先根据群签名的验证算法，验证收到的签名是否有效，如果有效则继续进行下一步。代理服务器查看自己的属性是否满足访问策略如果满足则进行下一步。 对于原始密文代理服务器会用转换密钥对其进行第一次解密，生成了一个含有k次的双线配对运算B。

        解密阶段：

         追踪阶段：也只是用了群签名的方案里面的特性。

         撤销阶段：首先CA更新秘密值，然后使用更新的去更新新的转换密钥，使用新的转换密钥就会是部分解密中带有新的秘密值。然后根据撤销表，对没有撤销的用户进行广播密钥更新的信息，这样子未撤销的用户还能通过插值恢复秘密值而被撤销的用户就无法恢复出新的秘密值。