28、密码认证密钥交换：协议与安全模型解析

密码认证密钥交换：协议与安全模型解析

1. 对称密码认证密钥交换（PAKE）进展

在密码认证密钥交换（PAKE）领域，存在多种高效且轮数最少的 EKE 版本。例如，Abdalla 等人（2020）提出了 UC PAKE 功能的“懒提取”放松概念，指出包括 SPAKE2、SPEKE、CPace 和 TBPEKE 在内的多个高效最小轮 EKE 版本，在对应 BPR 模型证明所使用假设的间隙版本下，能在随机预言机模型（ROM）中实现懒提取 UC PAKE 模型。

McQuoid 等人（2020）则表明，使用特定两轮 Feistel 结构实现加密的 EKE2，在 ROM 中的 CDH 假设下，能实现 Canetti 等人（2005）提出的 UC PAKE 概念。目前，最有效且轮数最少的 EKE 版本是 EKE2 和 SPAKE2，它们分别在 CDH 和 GapDH 假设下实现了 UC PAKE 和懒提取 UC PAKE。具体成本如下表所示：
| 协议 | 每方成本 |
| ---- | ---- |
| EKE2（按 McQuoid 等人 2020 年实现方式） | 1fb + 1vb 加上 2 个 RO 哈希到一个群 |
| SPAKE2 | 3fb + 1vb |

2. 非对称 PAKE（aPAKE）

• 基本概念与原理 ：Bellovin 和 Merritt（1993）为客户端 - 服务器场景提出了增强型 PAKE（aPAKE）。在该场景中，服务器持有密码哈希值 hpw = f(pw) 而非密码本身。协议会检查客户端 C 和服务器 S 分别持有的 pw C 和 hpw S 是否满足 f(pwdC) = hpw S。如果 f 是一个紧密的单向函数（OWF），那么攻击者破解服务器持有的 hpw 后，恢复密码 pw 需要 Ω(2d) 的努力，其中 d 是密码熵。在 ROM 中，可以设置 f(x) = H(x)，但 aPAKE 协议会依赖于 H 的电路复杂度。而设置 f(x) = gH(x) 在通用群模型和 ROM 中仍是一个紧密的 OWF，并且可以实现高效的 aPAKE，用于检查客户端持有的 hpw C = H(pw C) 是否是服务器持有的 hpw S 的离散对数。这可以通过 Diffie - Hellman KEM 或离散对数的零知识证明（ZK）来完成，且在这两种情况下，离散对数关系验证都必须防止离线攻击。
• 相关解决方案与进展 ：沿着这些思路发展的 aPAKE 解决方案有多种称呼，如增强型、扩展型、基于验证器型或非对称 PAKE。Gentry 等人（2006）将 aPAKE 的 UC 概念形式化为 Canetti 等人（2005）的 UC PAKE 模型的扩展，并展示了一种 Ω 方法，这是一种通用编译器，使用任何签名在 ROM 中将 UC PAKE 转换为 UC aPAKE，需要额外的两个流（如果最后一个 PAKE 流是从服务器到客户端，则只需一个）以及客户端的签名生成和服务器的签名验证。

其他 PAKE 到 aPAKE 的编译器由 Hwang 等人（2018）给出，使用 DH KEM 或离散对数的零知识证明，去除了 Ω 方法中的服务器到客户端的流。Shoup（2020）表明，基于 KEM 增强的 SPAKE2 +（Cash 等人 2008）在 ROM 中的 CDH 假设下实现了 UC aPAKE（类似于 Abdalla 等人 2020 年的放松版本）。SPAKE2 + 和使用 SPAKE2 实例化的通用编译器都能给出 3 流的 UC aPAKE，每方有两个基于变量的（vb）指数运算，或者客户端为 1 个，服务器为 2 个。

最近，Gu 等人（2021）展示了一种编译器，从具有密钥隐藏属性的基于公钥的密钥交换（AKE）创建 UC aPAKE，得到一个 4 流的 UC aPAKE，在 ROM 中的 GapDH 假设下，每方有 1 个 vb 指数运算，成本基本与对称 UC PAKE 和普通密钥交换相当，但轮数复杂度不同。

aPAKE 与“基于 TLS 的密码认证”相比，安全性更强，因为后者依赖于公钥基础设施（PKI）来认证服务器 S 到客户端 C。不过，基于 TLS 的密码认证支持（私有）加盐密码哈希，这可以增加攻击者的工作量。Boyen（2009b）展示了第一个私有加盐 aPAKE，Jarecki 等人（2018）在 UC 框架中将私有加盐 aPAKE 定义为 UC 强 aPAKE（saPAKE），其中一个特定实例 OPAQUE 在 ROM 中的 One More GapDH 假设（OM - GapDH）下是安全的，在 IETF CFRG 非对称 PAKE 类别竞赛中被选中。另一个 UC saPAKE 由 Bradley 等人（2019b）展示，有两个流，每方有 1 或 2 个 vb 指数运算，但有更多的固定基指数运算。

下面是 aPAKE 相关协议的比较流程图：

graph LR
    A[aPAKE 协议] --> B[Gentry 等人 2006 方法]
    A --> C[Hwang 等人 2018 编译器]
    A --> D[Shoup 2020 SPAKE2 +]
    A --> E[Gu 等人 2021 编译器]
    B --> B1[额外流与签名操作]
    C --> C1[去除服务器到客户端流]
    D --> D1[3 流 UC aPAKE]
    E --> E1[4 流 UC aPAKE]

3. 阈值 PAKE（T - PAKE）

• 基本原理 ：除了非对称 PAKE，服务器持有的数据可以通过使用 (t, n) - 阈值密码系统来保护。在这种系统中，服务器的数据在服务器 S1, …, Sn 之间进行秘密共享，任何 t 个服务器被攻破都不会泄露信息，而 t + 1 个服务器足以在单服务器 PAKE 方案中模拟服务器。原则上，任何 PAKE 都可以使用多方计算（MPC）来实现，但实际上需要一个对 MPC 友好的服务器代码。
• 相关研究进展 ：
  • 早期提案 ：Ford 和 Kaliski Jr.（2000）以及 Jablon（2001）提出了 T - PAKE 提案，但安全论证不正式。
  • 高效 T - PAKE ：MacKenzie 等人（2002）给出了第一个高效的 (t, n) - 阈值 PAKE（T - PAKE），在 ROM 中的多服务器扩展 BPR 模型中是安全的，需要三轮服务器到服务器的通信，但假设使用 PKI 进行 Si 到 C 的认证。
  • 密码仅设置下的 T - PAKE ：Di Raimondo 和 Gennaro（2003）展示了 KOY 协议的 MPC 版本，得到了密码仅设置下的第一个 T - PAKE，适用于 t < n/3，在标准模型中安全，但通信复杂度为 Ω(κ3)，至少需要 12 轮通信。
  • 其他 T - PAKE 方案 ：Abdalla 等人（2005a）展示了一个密码仅设置的 T - PAKE（有一个专用服务器获取会话密钥），适用于 t < n/2，在 ROM 中的一个 DH 假设变体下安全，需要五轮服务器到服务器的通信（包括三轮可靠广播）。

Bagherzandi 等人（2011）给出了基于游戏的密码保护秘密共享（PPSS）方案的定义，Camenisch 等人（2014）在 UC 框架中将其定义为阈值密码认证秘密共享（TPASS）。PPSS/TPASS 意味着以最小的开销实现 T - PAKE，因为恢复的秘密可以包含让客户端 C 与每个服务器运行 AKE 的密钥凭证。不同方案的比较如下表所示：
| 方案 | 适用场景 | 安全模型 | 通信轮数 | 特点 |
| ---- | ---- | ---- | ---- | ---- |
| MacKenzie 等人 2002 | 通用 | 多服务器扩展 BPR 模型（ROM） | 3 轮服务器到服务器通信 | 假设 PKI 认证 |
| Di Raimondo 和 Gennaro 2003 | 密码仅设置（t < n/3） | 标准模型 | 至少 12 轮通信 | 通信复杂度高 |
| Abdalla 等人 2005a | 密码仅设置（t < n/2） | ROM 中 DH 假设变体 | 5 轮服务器到服务器通信（含 3 轮可靠广播） | 有专用服务器获取会话密钥 |
| Bagherzandi 等人 2011（PPSS） | PKI 模型 | ROM 中 DDH | 2 轮 C 到 Si 通信 | 改进 PKI 模型 T - PAKE 轮数 |
| Camenisch 等人 2014（TPASS） | 密码仅设置（有 CRS） | ROM 中 DDH | 5 轮 C 到 Si 通信 | 成本与 Abdalla 等人 2005a 相当 |
| Yi 等人 2015 | 通用 | 标准模型（非 ROM） | 4 轮服务器到服务器通信（含 2 广播） | 改进假设和轮数复杂度 |
| Jarecki 等人 2014、2016、2017 | 通用 | ROM 中（广义）OM - GapDH | 2 轮 T - PAKE（C 到 Si 单轮通信） | 成本低 |

4. 两服务器 PAKE（2 - PAKE）

• 基本概念 ：(t, n) = (1, 2) 的 T - PAKE 情况被称为两服务器 PAKE 或 2 - PAKE。在 PKI 模型中，验证注册的秘密共享密码和客户端提交的秘密共享密码是否相等，等同于验证秘密共享数据的相等性。
• 相关协议与特点 ：
  • PKI 模型 2 - PAKE ：Brainard 等人（2003）和 Szydlo 与 Kaliski Jr.（2005）的 PKI 模型 2 - PAKE 仅使用两个服务器之间交换的三条消息。
  • 密码仅设置下的 2 - PAKE ：Katz 等人（2005）给出了一个高效的密码仅设置（有 CRS）的 2 - PAKE，只有 5 个消息流，在标准模型（非 ROM）中的 DDH 假设下安全。Camenisch 等人（2012）展示了一个密码仅设置的两服务器 TPASS，意味着一个 2 - PAKE，但他们的协议在 ROM 中的 DDH 假设下有 6 个消息流。Camenisch 等人（2015a）展示了具有主动安全的两服务器 TPASS，即对瞬态故障的安全性，这也意味着 2 - PAKE 具有相同级别的安全性。其他 2 - PAKE 由 Yang 等人（2006）和 Jin 等人（2008）给出，与 Katz 等人（2005）的协议相比，消息数量略有减少，但对 DDH 假设下的安全性论证不太正式。2 - PAKE 的概念也在 Zhang 等人（2016）和 Kiefer 与 Manulis（2016）的 UC 设置中得到了形式化。

5. 分布式密码验证（DPV）

Camenisch 等人（2015b）给出了分布式密码验证（DPV）协议的 UC 定义。DPV 协议类似于 PKI 模型中的 T - PAKE，但有一个指定的服务器（如 S1）在登录时以明文形式获取客户端的密码，该协议允许 S1 和其他服务器确认该密码是否对应于密码注册期间秘密共享的密码（或加盐密码哈希）。Camenisch 等人（2015b）的 DPV 协议仅支持 t = n - 1 情况，S1 使用 3 次指数运算，其他每个 Si 使用 1 次指数运算，支持主动更新，并且在 ROM 中的 OM - DH 假设下安全。

Everspaugh 等人（2015）使用部分遗忘伪随机函数（POPRF）的阈值实现构建了通用 (t, n) 阈值情况下的 DPV。他们的计算成本比 Camenisch 等人（2015b）略高，因为他们的方案使用了双线性映射群，并且只给出了基于游戏的安全分析。其他 DPV 方案由 Schneider 等人（2016）和 Lai 等人（2017）为 n = 2 服务器的特定情况给出，它们扩展了 DPV 功能，包括仅更新每个服务器存储的密钥的主动更新，带宽为 O(1)，然后只有服务器 S1 本地执行 O(m) 的工作来更新 m 个用户的（加密）密码数据。

下面是 DPV 相关方案的比较流程图：

graph LR
    A[DPV 协议] --> B[Camenisch 等人 2015b 方案]
    A --> C[Everspaugh 等人 2015 方案]
    A --> D[Schneider 等人 2016 和 Lai 等人 2017 方案]
    B --> B1[t = n - 1 情况]
    B --> B2[3 次指数运算（S1）和 1 次（其他 Si）]
    B --> B3[支持主动更新]
    C --> C1[通用 (t, n) 阈值情况]
    C --> C2[使用双线性映射群]
    D --> D1[n = 2 服务器情况]
    D --> D2[扩展功能与主动更新]

综上所述，密码认证密钥交换领域在非对称 PAKE、阈值 PAKE 等方面都有丰富的研究成果，不同的协议和方案在安全性、轮数复杂度、计算成本等方面各有优劣，未来可以根据具体的应用场景选择合适的方案。

密码认证密钥交换：协议与安全模型解析

6. 各类 PAKE 协议总结与对比

为了更清晰地了解不同类型 PAKE 协议的特点，我们对前面介绍的各类协议进行总结对比，如下表所示：
| 协议类型 | 代表协议 | 安全模型 | 轮数复杂度 | 计算成本 | 适用场景 |
| ---- | ---- | ---- | ---- | ---- | ---- |
| 对称 PAKE | EKE2、SPAKE2 | CDH、GapDH（ROM） | 低轮数 | EKE2：1fb + 1vb + 2 RO 哈希；SPAKE2：3fb + 1vb | 通用对称密钥交换场景 |
| 非对称 PAKE（aPAKE） | SPAKE2 +、OPAQUE | CDH、OM - GapDH（ROM） | 3 - 4 流 | 2 - 3 vb exp/party | 客户端 - 服务器场景，增强安全性 |
| 阈值 PAKE（T - PAKE） | MacKenzie 等、Jarecki 等 | 多服务器扩展 BPR 模型、（广义）OM - GapDH（ROM）等 | 2 - 12 轮 | 不同方案成本不同 | 服务器数据需秘密共享场景 |
| 两服务器 PAKE（2 - PAKE） | Katz 等 | DDH（标准模型或 ROM） | 5 - 6 消息流 | 不同方案成本不同 | 两服务器场景 |
| 分布式密码验证（DPV） | Camenisch 等 | OM - DH（ROM） | 不同方案轮数不同 | 不同方案成本不同 | 服务器秘密共享密码验证场景 |

从这个表格中可以看出，不同的 PAKE 协议在安全模型、轮数复杂度和计算成本上存在显著差异。在选择协议时，需要根据具体的应用场景和安全需求进行权衡。例如，如果对安全性要求极高且对轮数复杂度不太敏感，可以选择基于更复杂安全假设的协议；如果追求高效的通信和计算，可以选择轮数少、计算成本低的协议。

7. 安全模型与假设分析

在 PAKE 协议的研究中，安全模型和假设起着至关重要的作用。常见的安全模型包括随机预言机模型（ROM）和标准模型，常见的假设如 CDH（计算 Diffie - Hellman 假设）、DDH（决策 Diffie - Hellman 假设）、OM - GapDH（One More GapDH 假设）等。
- 随机预言机模型（ROM） ：ROM 是一种理想化的模型，假设存在一个随机预言机，所有参与者都可以查询该预言机。在 ROM 中，许多协议可以更容易地证明其安全性，但 ROM 是一种理论上的抽象，实际应用中可能存在与理论不符的情况。例如，一些基于 ROM 的协议在实际实现时，可能会受到哈希函数实现的影响，导致安全性降低。
- 标准模型 ：标准模型不依赖于随机预言机，更接近实际的密码学环境。在标准模型中证明协议的安全性通常更加困难，但得到的安全性保证更可靠。例如，一些在标准模型中安全的协议，在实际应用中能够更好地抵御各种攻击。
- 安全假设 ：不同的安全假设对协议的安全性和性能有不同的影响。CDH 假设保证了在给定 Diffie - Hellman 元组的情况下，计算共享密钥的困难性；DDH 假设则更强，它要求区分 Diffie - Hellman 元组和随机元组是困难的。OM - GapDH 假设在一些协议中用于增强安全性，特别是在处理多次密钥交换或更复杂的安全场景时。

下面是安全模型与假设关系的流程图：

graph LR
    A[安全模型] --> B[随机预言机模型（ROM）]
    A --> C[标准模型]
    B --> B1[依赖随机预言机]
    B --> B2[部分协议易证安全]
    C --> C1[不依赖随机预言机]
    C --> C2[安全性保证更可靠]
    D[安全假设] --> E[CDH 假设]
    D --> F[DDH 假设]
    D --> G[OM - GapDH 假设]
    E --> E1[计算共享密钥困难]
    F --> F1[区分元组困难]
    G --> G1[增强多次交换安全性]

8. 未来发展趋势展望

随着信息技术的不断发展，PAKE 协议面临着新的挑战和机遇，未来可能会朝着以下几个方向发展：
- 更高的安全性 ：随着计算能力的提升和攻击技术的发展，对 PAKE 协议的安全性要求将越来越高。未来的协议可能会基于更复杂、更强大的安全假设，或者采用新的密码学技术来增强安全性。例如，结合量子密码学的思想，设计出能够抵御量子攻击的 PAKE 协议。
- 更低的复杂度 ：在保证安全性的前提下，降低协议的轮数复杂度和计算成本是一个重要的发展方向。这可以通过优化协议设计、采用更高效的算法和数据结构来实现。例如，利用新的密码学原语，减少不必要的计算和通信步骤。
- 更好的兼容性 ：随着不同系统和设备之间的互联互通需求增加，PAKE 协议需要具备更好的兼容性。未来的协议可能会支持更多的密码学算法和数据格式，以便在不同的平台和环境中使用。
- 更广泛的应用场景 ：除了传统的客户端 - 服务器场景和服务器数据保护场景，PAKE 协议可能会在更多的领域得到应用。例如，物联网、区块链等领域对安全密钥交换的需求日益增长，PAKE 协议可以为这些领域提供安全可靠的解决方案。

9. 实际应用建议

在实际应用中，选择合适的 PAKE 协议是关键。以下是一些选择协议的建议：
1. 明确安全需求 ：首先要确定应用场景对安全性的要求。如果对安全性要求极高，如涉及金融交易、敏感数据传输等场景，应选择基于强安全假设且经过严格安全证明的协议。
2. 考虑轮数复杂度 ：如果应用场景对通信延迟敏感，如实时通信、移动设备应用等，应选择轮数复杂度低的协议，以减少通信开销和延迟。
3. 评估计算成本 ：不同的协议在计算成本上存在差异。对于计算资源有限的设备，如物联网设备、移动终端等，应选择计算成本低的协议，以避免影响设备的性能。
4. 关注兼容性 ：确保选择的协议与现有的系统和设备兼容。如果需要与其他系统进行互操作，应选择支持通用密码学算法和数据格式的协议。

通过综合考虑以上因素，可以选择出最适合实际应用场景的 PAKE 协议，从而保障通信的安全性和效率。

总之，密码认证密钥交换领域是一个充满活力和挑战的研究领域。随着技术的不断进步，我们可以期待更多高效、安全的 PAKE 协议出现，为各种应用场景提供更好的安全保障。