代理重加密(Proxy Re-Encryption):从委托加密到云存储的跨用户安全共享

密码学概念 · 2026-08-14

概述

在现代云存储和协作系统中,一个经典的安全难题是:如何在不信任云服务商的前提下,允许用户A将其加密文件分享给用户B,而无需A亲自将文件传输给B?

传统的PKI方案只能支持"A直接加密给B",无法处理"委托转加密"的场景。代理重加密(Proxy Re-Encryption,简称PRE)正是为了解决这一问题而提出的密码学原语。

核心思想

PRE的核心思想是引入一个代理(Proxy)角色:

  • 用户A持有自己的私钥 $sk_A$,用户B持有私钥 $sk_B$
  • A生成一个重加密密钥 $rk_{A\rightarrow B}$,该密钥允许代理将A的密文转换为B可解密的密文
  • 代理使用 $rk_{A\rightarrow B}$ 将 $Enc_A(m)$ 转换为 $Enc_B(m)$
  • 代理和云存储服务器无法看到明文,只能看到密文形式的转换

应用场景

场景问题PRE解决方案
云存储共享用户上传加密文件后,如何分享给其他人?用户生成重加密密钥上传至云
医疗数据共享患者将病历加密存储,授权医生访问患者生成PRE密钥,医生解密查看
供应链协作供应商加密发货信息,物流公司需要解密供应商生成重加密密钥给物流公司
区块链智能合约加密数据的多方共享与权限管理PRE实现细粒度的委托访问

基本定义与安全属性

形式化定义

代理重加密方案 $\Pi = (\text{Setup}, \text{KeyGen}, \text{ReKeyGen}, \text{Encrypt}, \text{ReEncrypt}, \text{Decrypt})$ 包含以下算法:

  • Setup$(1^\lambda) \rightarrow params$:系统参数生成
  • KeyGen$(params) \rightarrow (pk_i, sk_i)$:用户密钥对生成
  • ReKeyGen$(sk_A, pk_B) \rightarrow rk_{A\rightarrow B}$:重加密密钥生成
  • Encrypt$(pk, m) \rightarrow C$:加密
  • ReEncrypt$(rk_{A\rightarrow B}, C_A) \rightarrow C_B$:重加密
  • Decrypt$(sk, C) \rightarrow m$:解密

正确性要求

对于任意消息 $m$、任意用户 $A, B$:

$$\text{Decrypt}(sk_B, \text{ReEncrypt}(rk_{A\rightarrow B}, \text{Encrypt}(pk_A, m))) = m$$

同时要求:

$$\text{Decrypt}(sk_A, \text{Encrypt}(pk_A, m)) = m$$

安全属性

PRE方案需要满足两个核心安全属性:

#### 1. 隐藏性(Hiding)

非授权用户无法从密文获取明文信息。形式化定义为:

  • IND-CPA-RE(选择明文攻击下的不可区分性):攻击者即使拥有重加密密钥 $rk_{A\rightarrow B}$,也无法区分挑战密文是对应 $m_0$ 还是 $m_1$
#### 2. 密钥独立性(Key Independence)

重加密密钥不应泄露任何关于源密钥或目标密钥的信息:

  • CMA-RE(抗选择消息攻击):即使攻击者能查询多个重加密密钥,也无法伪造有效的重加密密钥
#### 安全模型对比

模型攻击者能力安全性保证
IND-CPA-RE查询加密预言机、重加密密钥预言机密文不泄露明文
IND-CCA2-RE查询加密预言机、重加密密钥预言机、解密预言机强安全性,抗选择密文攻击
CMA-RE查询重加密密钥生成预言机重加密密钥不泄露源密钥

基于配对的PRE构造

Boneh-Franklin IBE扩展

最经典的PRE方案由Boneh和Franklin在2001年提出,基于他们的身份基加密(IBE)方案改进而来。

#### 系统参数

设 $G_1$ 是阶为素数 $q$ 的加法循环群,$G_2$ 是阶为 $q$ 的乘法循环群,$e: G_1 \times G_1 \rightarrow G_2$ 是一个双线性配对。

系统参数:$params = (G_1, G_2, q, e, P, H)$

其中 $P$ 是 $G_1$ 的生成元,$H: \{0,1\}^* \rightarrow G_1$ 是哈希函数。

#### 算法定义

1. KeyGen$(params, ID) \rightarrow (pk_{ID}, sk_{ID})$

  • 随机选择 $s \in \mathbb{Z}_q^*$ 作为主密钥
  • 计算 $P_{pub} = sP$
  • 用户ID的公钥:$pk_{ID} = H(ID)$
  • 用户ID的私钥:$sk_{ID} = s \cdot H(ID)$
2. Encrypt$(params, pk_{ID}, m) \rightarrow (U, V)$

  • 随机选择 $r \in \mathbb{Z}_q^*$
  • 计算 $U = rP$
  • 计算 $V = m \oplus H_2(e(pk_{ID}, P_{pub})^r)$
  • 密文:$(U, V)$
3. Decrypt$(params, sk_{ID}, (U, V))$

  • 计算 $H_2(e(U, sk_{ID}))$
  • 恢复明文:$m = V \oplus H_2(e(U, sk_{ID}))$
4. ReKeyGen$(sk_A, pk_B) \rightarrow rk_{A\rightarrow B}$

$$rk_{A\rightarrow B} = sk_A \cdot H(pk_B) = s \cdot H(pk_A) \cdot H(pk_B)$$

其中 $sk_A = s \cdot H(pk_A)$ 是 A 的用户私钥,$s$ 是 KGC 主密钥。重加密密钥不包含任何用户的完整私钥,只包含两个私钥的"乘积混合"。

5. ReEncrypt$(rk_{A\rightarrow B}, (U_A, V_A), pk_B) \rightarrow (U_B, V_B)$

  • 计算 $e(U_A, rk_{A\rightarrow B}) = e(rP, s \cdot H(pk_A) \cdot H(pk_B))$
  • 利用双线性:$= e(P, P)^{rs \cdot H(pk_A) \cdot H(pk_B)}$
  • 计算新密文:$U_B = U_A$,$V_B = V_A \oplus H_2(e(U_B, sk_B))$
这里的关键性质是:

$$e(U_A, rk_{A\rightarrow B}) = e(rP, s \cdot H(pk_A) \cdot H(pk_B)) = e(rP, sk_A \cdot H(pk_B))$$

而目标用户B解密时:

$$e(U_B, sk_B) = e(rP, s \cdot H(pk_B))$$

因此:

$$H_2(e(U_A, rk_{A\rightarrow B})) = H_2(e(rP, sk_A \cdot H(pk_B))) = H_2(e(rP, s \cdot H(pk_A) \cdot H(pk_B)))$$

验证:

$$e(rP, s \cdot H(pk_A) \cdot H(pk_B)) = e(rP, H(pk_A))^{s \cdot H(pk_B)}$$

$$= e(rP, H(pk_A))^{sk_B} = e(r \cdot H(pk_A), sk_B) = e(U_A, sk_B)$$

这正是B解密时需要的值,因此重加密是正确的。

安全性分析

为什么代理无法获取明文?

重加密密钥 $rk_{A\rightarrow B} = s \cdot H(pk_A) \cdot H(pk_B)$ 不包含 $sk_A$ 或 $sk_B$ 的完整信息,只包含两者的乘积。代理即使知道 $rk_{A\rightarrow B}$,也无法从中分离出 $s$ 或 $H(pk_A)$。

为什么B无法伪造A的重加密请求?

B只知道 $pk_B$ 和 $rk_{A\rightarrow B}$,不知道 $sk_A$,因此无法自行生成针对其他用户的重加密密钥。


安全性模型与证明

IND-CPA-RE 安全性

在IND-CPA-RE游戏中:

  • 挑战者生成系统参数和用户密钥对
  • 攻击者获得加密预言机访问权限
  • 攻击者输出两个等长消息 $m_0, m_1$
  • 挑战者随机选择 $b \in \{0,1\}$,加密 $m_b$ 为目标用户B生成挑战密文
  • 攻击者继续访问预言机,最终输出 $b'$
  • 如果 $b' = b$,攻击者成功
安全性证明思路:基于BDH(Bilinear Diffie-Hellman)假设,挑战者的密文结构使得攻击者无法区分 $m_0$ 和 $m_1$。

CMA-RE 安全性

在CMA-RE游戏中:

  • 攻击者可以获得任意用户对的重加密密钥(除了挑战对)
  • 攻击者试图伪造一个针对挑战对 $(A, B)$ 的有效重加密密钥
安全性证明思路:基于q-SDH(Strong Diffie-Hellman)假设,攻击者无法在不知道 $sk_A$ 的情况下生成有效的 $rk_{A\rightarrow B}$。


应用场景详解

云存储加密共享

假设用户A上传加密文件到云存储,希望用户B也能访问:

CODE
流程:
1. A生成密钥对 (pk_A, sk_A)
2. A加密文件:C_A = Encrypt(pk_A, m)
3. A生成重加密密钥:rk = ReKeyGen(sk_A, pk_B)
4. A上传 C_A 和 rk 到云端
5. 云端使用 rk 重加密:C_B = ReEncrypt(rk, C_A)
6. B下载 C_B 并解密:m = Decrypt(sk_B, C_B)

关键优势:

  • 云端无法看到明文
  • A不需要将文件传输给B
  • B只能解密被授权的文件

多用户委托共享

对于大规模场景,可以构建委托链:

CODE
A → B → C 表示A可以委托B,B可以委托C

重加密密钥传递:
rk_{A→B} = ReKeyGen(sk_A, pk_B)
rk_{B→C} = ReKeyGen(sk_B, pk_C)

云存储存储:
- C_A(原始密文,只有B能重加密)
- C_B = ReEncrypt(rk_{A→B}, C_A)(C也能重加密)
- C_C = ReEncrypt(rk_{B→C}, C_B)(最终密文)

性能优化:

  • 单次重加密:O(1) 配对运算
  • 深度为d的委托链:O(d) 配对运算
  • 可通过并行化优化

细粒度访问控制

结合属性基加密(ABE),可以实现基于属性的重加密:

CODE
场景:医院系统中,只有特定科室的医生可以访问患者记录

实现:
1. 患者生成ABE密钥
2. 患者生成PRE重加密密钥,绑定属性策略
3. 医生只有满足属性策略时才能解密


国密适配路径

SM2 下的 PRE 挑战

国密标准SM2基于特定的椭圆曲线和配对友好的曲线选择有限。主要挑战包括:

  • 配对友好性:标准SM2曲线不是配对友好的,无法直接使用配对运算
  • 哈希函数:SM2使用SM3哈希,需要适配PRE的哈希到曲线映射
  • 密钥封装:SM2没有标准的KEM接口,需要扩展

可能的适配方案

方案一:SM2 + 自定义配对

使用配对友好的椭圆曲线(如SM9使用的曲线),在国密框架下实现PRE:

  • 使用SM9的双线性配对基础
  • 保留SM3哈希和SM2签名机制
  • 扩展SM9密钥派生函数用于PRE
方案二:SM2 扩展为 IBE-PRE

基于SM2的椭圆曲线结构,扩展为身份基加密(IBE)方案,然后实现PRE:

  • 定义SM2风格的密钥生成
  • 扩展加密和解密算法
  • 实现重加密密钥生成和重加密
方案三:混合方案

结合国密算法和国际PRE方案:

  • 使用国际PRE构造(如基于配对的PRE)
  • 用SM2密钥替换其中的椭圆曲线参数
  • 用SM3替换哈希函数

推荐路径

短期:直接使用 SM9 的配对基础实现 PRE,因为 SM9 标准已经定义了完整的双线性配对方案,且 SM9 的 IBE 加密算法天然支持委托重加密:

  • 用户 A 使用 SM9 IBE 加密文件:$C_A = \text{SM9.Enc}(pk_B, m)$
  • 生成重加密密钥:$rk_{A\rightarrow B} = d_A \cdot H(pk_B)$(基于 SM9 私钥派生结构)
  • 代理重加密:$C_B = \text{SM9.ReEncrypt}(rk_{A\rightarrow B}, C_A) = \text{SM9.Enc}(pk_B, m)$ 的重加密形式
  • B 解密:$m = \text{SM9.Dec}(d_B, C_B)$
中期:如果必须基于 SM2,可考虑两种路径:
  • SM2 + 自定义配对曲线:在 SM2 曲线之外,额外定义一条配对友好曲线(类似 SM9 的曲线),使用 SM3 哈希和 SM2 签名机制组合
  • SM2 扩展为 IBE-PRE:基于 SM2 的椭圆曲线结构,扩展为身份基加密(IBE)方案,然后实现 PRE
长期:推动 GM/T 标准委员会制定基于 SM2 的 PRE 标准,明确:
  • 配对友好的曲线选择(或确认 SM9 曲线作为默认选项)
  • 哈希到曲线的映射方法
  • 密钥封装机制
  • 安全性模型和证明

与其他密码学原语的比较

原语核心特性与PRE的区别
属性基加密(ABE)基于属性的访问控制ABE关注"谁能解密",PRE关注"谁能转加密"
多方计算(MPC)多方协同计算MPC需要多方参与计算,PRE只需单方委托
门限加密多方共同解密门限加密需要t个用户合作解密,PRE是单点委托
广播加密一对多加密广播加密是静态的,PRE是动态委托
混淆电路黑盒函数实现混淆电路实现通用计算,PRE专用于委托加密

组合使用

在实际系统中,PRE常常与其他原语组合使用:


工程实现要点

性能优化

  • 批量重加密:当需要重加密多个密文时,可以并行化配对运算
  • 缓存重加密密钥:同一用户对的重加密密钥可以缓存复用
  • 渐进式重加密:对于大文件,可以分块重加密,避免一次性计算开销

密钥管理

  • 重加密密钥生命周期:设置重加密密钥的有效期,过期自动失效
  • 撤销机制:支持动态撤销重加密权限,可通过密钥轮换实现
  • 审计日志:记录所有重加密操作,用于事后审计

兼容性考虑

  • 跨域委托:不同信任域之间的PRE委托需要额外的信任桥
  • 版本兼容:不同版本的PRE方案需要保持向后兼容
  • 国密与国际标准:在国密场景下,需要考虑与国际标准的互操作性

总结

代理重加密(PRE)是一种强大的密码学原语,解决了云存储和协作系统中的委托加密问题。本文从基本定义出发,深入解析了基于配对的PRE构造、安全性模型、应用场景以及国密适配路径。

核心要点回顾:

  • 定义清晰:PRE允许委托方将密文从发送给A转换为发送给B,无需委托方接触明文
  • 构造有效:基于配对的PRE构造简洁高效,安全性基于BDH和q-SDH假设
  • 应用广泛:在云存储、医疗数据共享、供应链协作等场景中具有重要价值
  • 国密适配可行:可以通过SM9配对基础或SM2扩展实现国密版本的PRE
未来展望:

随着国密标准的不断完善,未来有望看到基于SM2的标准化PRE方案。这将为国密环境下的细粒度访问控制和数据共享提供更完善的密码学基础。


相关实践

参考资料

  • Boneh, D., & Franklin, M. (2001). Identity-based encryption from the Weil pairing. *SIAM Journal on Computing*, 32(3), 586-615.
  • Ateniese, G., Fu, K., Green, M., & Hancey, J. (2006). Improved proxy re-encryption schemes with applications to secure distributed storage. *ACM Transactions on Storage (TOS)*, 3(1), 1-30.
  • Blaze, M., Bleumer, G., & Strauss, M. (1998). Divertible protocols and atomic proxy cryptography. In *International Conference on the Theory and Applications of Cryptographic Techniques* (pp. 127-141). Springer.
  • GM/T 0044-2016《SM9标识密码算法》
  • GB/T 47471-2026《信息安全技术 SM9标识密码加密签名消息语法规范》