47、去中心化可追踪属性签名与代理重加密的安全增强与效率提升-优快云博客

本文链接：https://blog.youkuaiyun.com/perl8/article/details/154333256

去中心化可追踪属性签名与代理重加密的安全增强与效率提升

1. 去中心化可追踪属性签名

1.1 分布式标签加密方案要求

在分布式标签加密方案中，有几个关键的算法和安全要求。ShareVerify(pk, svki, t, Cdtbe, νi) 用于验证解密份额 νi，输出 0 或 1；Combine(pk, {svki}n i=1, {νi}n i=1, Cdtbe, t) 输出消息 m 或 ⊥。除了正确性，还需要满足选择性标签弱不可区分性对抗自适应选择密文攻击（ST - wIND - CCA）和解密一致性（DEC - CON）。前者要求攻击者在获得除目标标签外的任何标签下的密文解密预言机时，无法区分哪个挑战消息被加密；后者要求攻击者不能输出一个密文的两组不同解密份额，且这些份额解密结果不同。

1.2 通用构造

1.2.1 构造概述

通用构造消除了一些先前构造所需的昂贵工具，如伪属性技术和用于证明追踪正确性的昂贵零知识证明，从而在提供更强安全性的同时获得更高效的构造。

1.2.2 所需工具

NIZK 知识证明系统 NIZK
选择性标签弱 IND - CCA 鲁棒非交互式（1 - out - of - 1）分布式标签加密方案 DT BE
带标签签名方案 T S
抗弱选择消息攻击的存在不可伪造签名方案 WDS
强不可伪造一次性签名方案 OT S
两个抗碰撞哈希函数 ˆH : {0, 1}∗→TDT BE 和 H : {0, 1}∗→MOT S

1.2.3 系统设置

Setup 算法为 NIZK 生成公共参考字符串 crs，并运行 DT BE.Setup 生成服务器的秘密 esk、验证密钥 esvk 和公钥 epk。系统公共参数设置为 pp := (1λ, crs, epk, esvk, ˆH, H)，追踪权威的密钥设置为 tk := esk。
新属性权威加入系统时，为带标签签名方案 T S 创建验证/秘密密钥对 (avkaid, askaid)。
用户加入系统时，为数字签名方案 WDS 生成验证/秘密密钥对 (uvk[uid], usk[uid])。

1.2.4 密钥生成与签名过程

为用户 uid 的属性 α 生成签名密钥时，管理属性权威使用其秘密带标签签名密钥对用户的公钥 uvk[uid]（用作标签）和属性 α 进行签名，得到的签名 σα 作为用户 uid 该属性的秘密密钥 skuid,α。
对消息 m 按照签名策略 P 进行签名时，用户执行以下步骤：
1. 为一次性签名 OT S 选择一个新的密钥对 (otsvk, otssk)。
2. 使用分布式标签加密方案 DT BE（可能使用一些随机数 μ）以 ˆH(otsvk) 作为标签加密其公钥 uvk[uid]，得到密文 Cdtbe。
3. 使用数字签名方案 WDS 和其个人秘密密钥 usk[uid] 对 ˆH(otsvk) 进行签名，得到签名 σ。
4. 使用 NIZK 计算证明 π，证明以下几点：
  - 正确加密了其公钥。
  - 拥有对 ˆH(otsvk) 的签名 σ，且该签名相对于其公钥 uvk[uid] 可验证。
  - 其公钥上有足够的属性满足签名谓词 P。这通过一个由矩阵 S 表示的跨度程序来证明，用户证明知道一个秘密向量 z ∈Z|P| p，使得 zS = [1, 0, …, 0]，并且对于签名谓词 P 中 z 对应元素非零的每个属性，拥有有效的带标签签名。对于签名者不拥有的属性，选择随机签名。
5. 使用一次性签名 OT S 对 (H(m, P), π, Cdtbe, otsvk) 进行签名，得到一次性签名 σots。

1.2.5 签名验证与追踪

验证签名时，验证证明 π 和一次性签名 σots。
追踪签名时，追踪权威使用其秘密密钥生成密文 Cdtbe 的解密份额 ν，从而使任何人都能恢复加密的用户公钥 vkuid。然后在公钥表 uvk 中搜索匹配 vkuid 的条目，如果存在则返回 (uid, ν)，否则返回 (0, ν)。验证追踪正确性时，法官只需验证解密份额 ν 的有效性，然后恢复明文并验证其解密为相关用户。

1.3 标准模型实例化

1.3.1 实例化 I

T S 使用 AGHO1 签名方案，WDS 和 OT S 分别使用弱和完整的 Boneh - Boyen 签名方案，NIZK 使用 Groth - Sahai 系统，DT BE 使用图 6 中的方案。
签名时，需要证明以下方程：
- 为证明 zS = [1, 0, …, 0]，证明者证明：
  [
  \sum_{i = 1}^{|P|}(z_i \tilde{S} {i,1}) = 1
  ]
  [
  \sum {i = 1}^{|P|}(z_i \tilde{S}_{i,j}) = 0, \text{ for } j = 2, …, \beta
  ]
- 为证明 zi ̸= 0 ⇒T S.Verify(avkaid(αi), uvk[uid], αi, σαi) = 1，签名者对 σαi 进行重新随机化，并证明一系列方程。
- 为证明 WDS.Verify(uvk[uid], ˆH(otsvk), σ) = 1，证明者证明：
  [
  e(\sigma, \sim uvk[uid])e(\sigma, \tilde{G} \hat{H}(otsvk))e(G, \tilde{G}) = 1
  ]
  [
  G - G = 0
  ]
- 为证明 DT BE.Enc(epk, ˆH(otsvk), uvk[uid]; (r1, r2)) = Cdtbe，证明 ˜C1 = ˜Hr1, ˜C2 = ˜V r2 和 ˜C3 = ˜U r1 · ˜U r2 · ∼ uvk[uid]。
签名的总大小为 G27·|P|+19 1 + G22·|P|+15 2 + Zβ+3 p。

1.3.2 实例化 II

T S 使用 AGHO2 签名方案，需要对 WDS 的公钥和签名组件选择的组进行转置，DT BE 中的组也进行转置，其余工具与实例化 I 相同。
签名时的证明与实例化 I 类似，但 z 在 G2 中进行承诺，而密文在 G1 中。
签名的总大小为 G30·|P|+18 1 + G30·|P|+16 2 + Zβ+3 p。

1.4 效率比较

方案	签名大小	模型	设置	追踪大小	计算	验证
[11]	G	P	+β+7	ROM Composite	N/A	N/A
[10]	G34·	P	+28 1 + G32·	P	+32 2 + Zβ+1 p	STD
Inst. I	G27·	P	+19 1 + G22·	P	+15 2 + Zβ+3 p	STD
Inst. II	G30·	P	+18 1 + G30·	P	+16 2 + Zβ+3 p	STD

2. 代理重加密的重加密可验证性

2.1 代理重加密概述

代理重加密（PRE）是传统公钥加密（PKE）的有趣扩展。除了 PKE 的正常操作外，半可信的代理可以使用接收者 A 生成的专用重加密密钥，将发往用户 A 的一类密文转换为发往用户 B 的密文，且代理对明文完全不知情。本文关注的是单跳单向 PRE，即密文只能转换一次，且用于将用户 A 的密文转换为用户 B 的密文的重加密密钥不能用于相反方向的转换。

2.2 重加密可验证性

2.2.1 定义

在具有重加密可验证性的 PRE 方案（可验证 PRE，或 VPRE）中，重加密密文的接收者可以验证接收到的密文是否由代理从原始密文正确转换而来，从而检测代理的非法活动。

2.2.2 安全模型与方案扩展

对 VPRE 方案的安全模型进行了形式化，并表明 Hanaoka 等人（CT - RSA 2012）的单跳单向 PRE 方案可以扩展为安全的 VPRE 方案。

2.3 流程总结

graph LR
    A[用户加入系统] --> B[生成WDS密钥对]
    B --> C[新属性权威加入系统]
    C --> D[生成TS密钥对]
    D --> E[为用户属性生成签名密钥]
    E --> F[用户签名消息]
    F --> G[选择OTS密钥对]
    G --> H[加密公钥]
    H --> I[签名H(otsvk)]
    I --> J[计算证明π]
    J --> K[签名(H(m, P), π, Cdtbe, otsvk)]
    K --> L[验证签名]
    L --> M[追踪签名]
    N[原始密文] --> O[代理重加密]
    O --> P[接收者验证重加密密文]

通过以上介绍，我们可以看到在去中心化可追踪属性签名和代理重加密领域，通过新的构造和功能扩展，实现了安全性和效率的提升。在实际应用中，可以根据具体需求选择合适的方案和实例化方式。

2.4 代理重加密的详细操作步骤

2.4.1 密钥生成

接收者 A ：生成自己的公钥 (pk_A) 和私钥 (sk_A)，同时生成用于将密文重加密给接收者 B 的重加密密钥 (rk_{A→B})。
接收者 B ：生成自己的公钥 (pk_B) 和私钥 (sk_B)。

2.4.2 加密过程

发送者使用接收者 A 的公钥 (pk_A) 对消息 (m) 进行加密，得到原始密文 (C_A)。加密公式可表示为 (C_A = Enc(pk_A, m))。

2.4.3 重加密过程

代理接收到原始密文 (C_A) 和重加密密钥 (rk_{A→B}) 后，将其转换为发往接收者 B 的重加密密文 (C_B)。重加密操作可表示为 (C_B = Re - Enc(rk_{A→B}, C_A))。

2.4.4 验证过程

接收者 B 接收到重加密密文 (C_B) 后，进行验证操作。
- 首先，根据已知的原始密文 (C_A)（可能通过某种方式传递）、重加密密钥 (rk_{A→B}) 和公钥 (pk_A)、(pk_B) 等信息，验证 (C_B) 是否是由 (C_A) 正确转换而来。
- 验证公式可能涉及到一些加密算法的特性和相关参数，例如验证 (C_B) 是否满足 (C_B = Re - Enc(rk_{A→B}, C_A)) 所规定的转换规则。

2.5 代理重加密与去中心化可追踪属性签名的关联

虽然代理重加密和去中心化可追踪属性签名是两个不同的概念，但在某些场景下可以相互结合使用。例如，在一个安全的分布式系统中：
- 数据共享场景 ：用户可以使用去中心化可追踪属性签名对自己的数据进行签名，以证明其合法性和属性满足某些策略。同时，当需要将数据共享给其他用户时，可以使用代理重加密将数据的密文进行转换，并且接收者可以验证重加密的正确性，确保数据在传输和转换过程中的安全性。
- 权限管理场景 ：属性权威可以使用带标签签名方案对用户的属性进行签名，用户根据这些属性进行签名操作。而在数据访问过程中，代理重加密可以用于在不同用户之间安全地传递加密数据，并且通过重加密可验证性检测代理的非法操作。