密文策略 ABE（CP-ABE）

在密文策略基于属性的加密（CP-ABE）中，加密方会将访问策略直接嵌入密文。用户持有一把编码其属性集合的秘密密钥。当且仅当用户的属性满足嵌入密文中的访问策略时，解密才能成功。加密方可以在加密时指定策略，从而控制谁能够解密。

CP-ABE 中的访问策略以属性上的单调布尔公式表示，通常表示为线性秘密共享方案（LSSS）或访问树。策略可以包含 AND 门、OR 门和阈值门。AND 门要求列出的所有属性；OR 门只要求其中任意一个；“n 中取 t”的阈值门要求列出的 n 个属性中至少有 t 个。这些门可以嵌套，从而表达复杂的访问结构。

请考虑一个医院信息系统。一份医疗报告可能使用以下策略加密：（角色=医生 AND 部门=心脏科）OR 角色=管理员。心脏科医生具有属性集合{角色=医生，部门=心脏科}，因此可以解密。放射科医生具有属性集合{角色=医生，部门=放射科}，由于缺少部门=心脏科这一属性，因此无法解密。管理员具有{角色=管理员}，始终可以解密。该策略通过密码学机制强制执行，而不只是依靠访问控制列表。

最具影响力的实用 CP-ABE 构造由 Waters 于 2011 年提出，基于椭圆曲线上的双线性配对。在该构造中，授权机构生成主密钥和公钥，并针对特定属性集合生成用户秘密密钥。加密过程使用线性秘密共享来创建编码访问策略的密文。在 DBDH 假设下，可以证明该构造的安全性。

CP-ABE 方案在处理属性空间的方式上有所不同。小属性空间构造要求在初始化时确定所有可能属性的完整集合，这限制了灵活性，但可以实现更高效的方案。大属性空间构造（Rouselakis-Waters，2013；Attrapadung，2014）允许从指数规模的属性空间中选择属性，而无需在初始化时预先确定属性，因此可以支持用户标识符或时间戳等属性，而不必预先声明所有可能性。

CP-ABE 可以支持密钥委托：授权机构可以向下级机构签发包含部分属性的密钥，而下级机构可以进一步限制密钥能力，但不能扩大这些能力。这支持分层的属性管理：公司级授权机构签发部门级密钥，部门授权机构再签发员工密钥。该性质称为密钥委托安全性：被委托的密钥不能用于解密委托方无法解密的任何内容。

Java 配对密码学（jpbc）库和用于原型开发的 charm-crypto Python 框架都提供了实用的 CP-ABE 实现。OpenABE 库（Zeutro）是一个 C++ 实现，支持 CP-ABE 和 KP-ABE，适合用于生产环境。RABE 是 CP-ABE 的 Rust 实现。这些库实现了基于配对的运算，支持 BN-256 和 BLS12-381 曲线。

CP-ABE 的典型应用是在云存储中实现细粒度访问控制。文件所有者会在上传前使用某个策略加密文档。任何属性满足该策略的用户都可以下载并解密，而云服务提供商既不需要知道谁会访问文档，也不需要维护访问控制列表。云服务提供商只需向请求者提供密文，策略本身由密文强制执行。

CP-ABE 运算包含双线性配对计算，其速度明显慢于对称加密。在现代 CPU 上，BN-256 上的一次配对运算大约需要 1—3 毫秒。解密开销随满足条件的属性数量线性增长。对于包含 10—20 个属性的策略，解密需要 10—60 毫秒，这对于面向用户的应用是可以接受的，但对于高频自动化系统来说过慢。

标准 CP-ABE 会向所有看到密文的人公开访问策略，策略本身不会被加密。隐藏策略 CP-ABE（或部分隐藏策略 CP-ABE）会向未获授权方隐藏部分或全部策略属性，从而提供额外的隐私保护。实现完整的策略隐藏需要更加复杂的构造，并会带来显著更高的性能开销。大多数实际部署仍使用标准的（策略可见）CP-ABE，并接受访问策略可以被观察到这一事实。

CP-ABE 中的密钥撤销是一个重大的实际挑战。如果用户的属性发生变化（例如离开某个部门，或其凭证被撤销），则重新加密所有针对其原有属性加密的密文会非常昂贵。实际方法包括属性版本化（递增每个属性中的版本号）、使用代理重加密来更新密文，或者将 CP-ABE 与基于时间的属性结合，并要求用户定期从授权机构刷新密钥。

在 CP-ABE 中，访问策略嵌入在哪里？

CP-ABE 将访问策略嵌入密文，将属性集合编码到用户密钥中。当属性满足策略（AND、OR 和阈值门）时，解密成功。Waters 2011 年提出的构造是基于双线性配对的奠基性实用构造。大属性空间变体支持动态属性空间。CP-ABE 已部署于云存储中，用于实现细粒度访问控制，而无需服务器端访问控制列表。密钥撤销仍然是一个实际挑战，可以通过属性版本化或代理重加密来应对。