OPAQUE 协议：密码认证密钥交换的安全范式革命

概述

HTTP 登录页面上，用户输入密码、点击"登录"——这个看似简单的操作背后隐藏着一个被长期忽视的安全真空：服务器必须以明文形式读取用户提交的密码，才能与数据库中保存的加盐哈希值进行比对。无论传输过程是否使用 HTTPS，密码在服务端内存中以明文形式存在，这意味着日志记录、内存转储、内部威胁都可能造成灾难性泄露。

OPAQUE 是解决这一问题的现代密码学方案。

OPAQUE（Oblivious Pseudo-random Function-based Augmented Password-Authenticated Key Exchange，基于不经意伪随机函数的非对称密码认证密钥交换协议）由 Stanislaw Jarecki、Hugo Krawczyk 和 Jiayu Xu 于 2018 年提出，是首个具有形式化安全证明的增强型 aPAKE 协议。其核心突破是：服务器永远不需要知道用户的密码，也不需要存储密码的等效值，却仍然能够在不暴露密码的前提下完成身份认证和会话密钥协商。

IETF Crypto Forum Research Group (CFRG) 于 2025 年 7 月在 RFC 9807 中正式标准化 OPAQUE 协议。该协议融合了 OPRF（Oblivious Pseudo-Random Function，不经意伪随机函数）和 AKE（Authenticated Key Exchange，认证密钥交换）两大密码学原语，成为第一个从学术构造走向 IETF 标准、具备工业部署条件的 aPAKE 协议。

理解 OPAQUE，不仅能掌握下一代认证协议的设计思路，也能深入理解数据泄露场景下的零信任认证架构。

PAKE 协议演进

PAKE 的形式化定义

一个密码认证密钥交换（PAKE）协议要求两方基于共同持有（或一方持有密码、另一方持有密码衍生值）的低熵共享秘密，协商出一个高强度的共享密钥。PAKE 的安全性要求可形式化为：

$$\text{Adv}_{PAKE}(A) = \left| 2\Pr[\text{Test}_A = 1] - 1 \right| \leq Q \cdot \frac{1}{|\mathcal{D}|} + \text{negl}(\lambda)$$

其中 $\mathcal{D}$ 是密码字典，$Q$ 是协议会话尝试次数。这意味着攻击者只能通过猜测密码来破解，而无法从协议交互中提取其他信息。

三代 PAKE 的演进

OPAQUE 协议基础

OPAQUE 协议栈

OPAQUE 由三个密码学原语层叠组成：

┌─────────────────────────────────┐
│    OPAQUE-aPAKE 协议             │  RFC 9807 标准化
├─────────────────────────────────┤
│    AKE 协议（如 3DH, SIGMA-I）   │  经典认证密钥交换
├─────────────────────────────────┤
│    OPRF（基于 ECC 或哈希）       │  RFC 9497 标准化
└─────────────────────────────────┘

#### 1. OPRF（Oblivious Pseudo-Random Function）

OPRF 是一个两方计算协议，客户端持有输入 $x$，服务器持有密钥 $k$。协议结束后：

• 客户端获得 $y = OPRF_k(x)$（看起来随机的值）
• 服务器不知道 $x$ 是什么（"不经意"）
• 客户端不知道 $k$ 是什么（客户端只能获得 $y$，无法反推密钥）

$$OPRF_k(x) = H(x)^k$$

客户端选择随机盲化因子 $r$，发送 $H(x)^r$ 给服务器。服务器计算 $(H(x)^r)^k = H(x)^{rk}$ 返回。客户端去盲化：$y = H(x)^{rk} / H(x)^r$ 的去盲结果 $= H(x)^k$。

#### 2. AKE（Authenticated Key Exchange）

AKE 协议负责在完成 OPRF 派生后生成会话密钥。OPAQUE 设计为"AKE 无关"——可以选用：

• 3DH (Triple Diffie-Hellman)：类似 Signal X3DH 的三次密钥交换
• SIGMA-I：带有签名确认的密钥交换
• TLS 1.3：作为一种广义 AKE 使用

OPAQUE 双阶段协议

#### 阶段一：凭据注册（Registration）

Client (knows pwd)              Server (knows nothing yet)
──────────────────────────────────────────────────────────────
  1. 生成随机盲化因子 α
     发送 EnvelopeRequest(pwd, α)
                                2. 生成随机 OPRF 密钥 k
                                   存储 k（与用户 ID 关联）
                                   返回 OPRF_key_ack(k)

  3. 计算 OPRF_y = OPRF_k(pwd)（去盲化后）
     rwd = HKDF(OPRF_y, "OPAQUE")   // 派生随机包装密钥

  4. 生成客户端长期密钥对 (csk, cpk)
     加密 envelope = Enc(rwd, csk)
                         ──发送 envelope, cpk──→
                                                   5. 存储 {k, cpk, envelope, user_id}

关键工程细节：发送的不是 $pwd$，只有 OPRF 协议消息。服务器端最终存储的是：

• $k$：OPRF 密钥（随机值，不是密码的函数）
• $cpk$：客户端公钥（与密码无关）
• $envelope$：加密信封（需要 $rwd = OPRF_k(pwd)$ 才能解开）

Client (knows pwd)              Server (cpk, envelope, k)
──────────────────────────────────────────────────────────────
  1. 生成随机盲化因子 α
     发送 LoginRequest(user_id, α)
                                2. 查找 {k, cpk, envelope}
                                   返回 k, cpk, envelope

  3. 计算 OPRF_y = OPRF_k(pwd)（与注册时相同）
     rwd = HKDF(OPRF_y, "OPAQUE")
     
  4. 解密 csk = Dec(rwd, envelope)
     
  5. 执行 AKE 协议（3DH 或 SIGMA-I）
       客户端私钥 = csk
       服务器公钥 = cp（来自 TLS 证书或单独发送）
     
  6. 双方获得会话密钥 SK

安全性分析：如果在步骤 4 中解密失败（密码错误），$rwd$ 不正确，得到的 $csk$ 是随机垃圾值，后续 AKE 协议将产生与服务器不匹配的密钥——登录被拒绝。服务器端在这个过程中从未接触到明文密码。

OPAQUE 在 TLS 中的集成

OPAQUE-over-TLS

一种集成方式是"OPAQUE 握手内嵌在 TLS 1.3 握手完成后"，利用 TLS 建立的加密通道保护 OPAQUE 消息。这种模式下，TLS 负责传输层安全，OPAQUE 负责密码认证——两层防护。

OPAQUE-EA（Exported Authenticators）

IETF 草案 draft-irtf-cfrg-opaque 还定义了 OPAQUE-EA，将 OPAQUE 消息嵌入 TLS 的 Exported Authenticator（RFC 9261）扩展中。流程：

• 先执行标准 TLS 1.3 握手：服务器通过证书认证身份
• 客户端发送 Authenticator Request：包含用户名 + OPRF 数据
• 服务器返回 Envelope + 自己的 OPRF 响应（通过 Authenticator Response）
• 客户端解密信封并响应：通过第二个 Authenticator Response 证明持有 $csk$
• 双方获得会话密钥：OPAQUE 的 AKE 部分最终与 TLS 会话密钥组合

与 WebAuthn 的对比

OPAQUE 的核心安全分析

安全场景分析

#### 场景 1：传输窃听（传统 PAKE 能力）

攻击者窃听通信流量——无法获得密码。传统 PAKE 即提供此能力。

#### 场景 2：数据库泄露（OPAQUE 核心优势）

攻击者窃取服务器数据（$k$, $cpk$, $envelope$）：

• 传统方案：攻击者拥有 $H(pwd \| salt)$，可对每个用户离线猜测密码
• SRP：攻击者持有 $verifier = g^{H(salt \| pwd)}$，可通过离线猜测恢复密码
• OPAQUE：攻击者持有 $k$（OPRF 密钥）和 $envelope$。要猜测密码 $pwd'$，必须在线协议交互——猜测一次只能进行一次（否则触发速率限制）

#### 场景 3：内存泄露

攻击者抓取服务器内存——只能看到 OPRF 协议中间状态（临时值），无法获得明文密码。因为服务器端从不需要明文密码。

形式化安全证明

Jarecki 等人在 2018 年论文中，在通用可组合（UC）框架下证明了以下安全性质：

• 离线字典攻击安全：服务器端数据泄露后，攻击者仍需要在线交互，无法离线预计算
• 会话密钥安全：满足 AKE 安全规范（loose independence of OPRF and AKE）
• 前向保密：若选用 3DH 等提供前向保密的 AKE 实例，则具备部分前向保密

工程实践中的关键问题

1. OPRF 曲线选择

IETF 在 RFC 9497 中标准化了基于 ECC 的 OPRF，推荐了两个密码组：

2. 信封加密的密钥派生

# 伪代码：信封密钥派生（概念示意）
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
from cryptography.hazmat.primitives import hashes

def derive_envelope_key(oprf_output: bytes) -> bytes:
    """
    将 OPRF 输出派生为对称密钥（用于加密信封）
    - oprf_output: 椭圆曲线点序列化结果（33-65 字节）
    - 返回均匀化的对称密钥（32 字节）
    """
    hkdf = HKDF(
        algorithm=hashes.SM3(),  # 国密场景；国际场景用 SHA-256
        length=32,               # SM4-256 的密钥长度
        salt=None,
        info=b"OPAQUE-envelope-v1"
    )
    return hkdf.derive(oprf_output)

3. 与现有密码数据库的迁移

OPAQUE 引入了与传统加盐哈希不同的用户凭据表示，迁移策略：

• 新系统直接创建：新用户注册时创建 OPAQUE 凭据
• 旧凭据渐进迁移：用户下次登录时，先用旧哈希验证，成功后创建 OPAQUE 凭据（存入新字段，标记旧字段已迁移）
• 不可自动迁移：旧哈希无法"转换"为 OPAQUE 信封，因为服务器不知道 $pwd$

4. 安全部署检查清单

OPAQUE 标准化进展与产业动态

IETF 标准化历程

产业部署

• Cloudflare：2022 年发布 OPAQUE 概念验证原型，使用 Go + WebAssembly 实现浏览器端
• Facebook Novi (Meta)：研究 OPAQUE 保护数字货币钱包凭据
• 1Password：2024 年宣布部署 OPAQUE 作为核心认证协议
• Zcash 基金会：研究用于匿名数字资产的 OPAQUE 认证

总结

OPAQUE 协议代表了密码认证范式的一次重要演进：从"服务器需要知道密码（等效值）"到"服务器完全不知道密码但不影响认证"。其核心价值在于：通过 OPRF 将密码认证与服务器端数据存储解耦，即使遭遇最严重的数据库泄露事件，攻击者仍然无法批量离线破解用户密码；通过 AKE 与前向保密实例的组合，在不牺牲可用性的前提下提升安全边界。

RFC 9807 的标准化（2025 年 7 月）为 OPAQUE 的工业部署铺平了道路。随着服务端安全威胁日益严峻和零信任架构的普及，OPAQUE 有望成为继 FIDO2/WebAuthn 之后的下一个主流认证基础设施。

参考来源

• RFC 9807 — The OPAQUE Augmented PAKE Protocol
• Jarecki, Krawczyk, Xu: "OPAQUE: An Asymmetric PAKE Protocol Secure Against Pre-Computation Attacks", Eurocrypt 2018
• RFC 9497 — OPRF Protocol
• RFC 9261 — Exported Authenticators
• Cloudflare Blog: OPAQUE - The Best Passwords Never Leave your Device
• IETF CFRG OPAQUE Draft

相关实践

• 国密算法在 JWT 中的应用：SM2-SM3 签名与 SM4-CBC 加密实战
• FIDO2 与 WebAuthn：无密码认证协议的原理与架构
• SM2 密钥交换协议实战：基于 GM/T 0003.3-2012 的密钥协商