4. 后量子密钥交换在VPN中的集成实现

把 Kyber/ML-KEM 集成进 VPN，本质上不是“换一个加密算法”，而是把一个新的密钥封装机制（KEM）嵌入到既有握手状态机中，并让双方在算法协商、密钥派生、报文编码三个层面都能互操作。本节以 IKEv2 和 TLS 1.3 两条主流路径为主线，说明如何借助 OpenSSL OQS provider 或 liboqs 完成集成，构建混合密钥交换原型，并用握手成功率作为第一层验收指标。

一、先厘清集成对象：KEM 与 DH 的语义差异

传统 IKEv2 使用 Diffie-Hellman（DH）交换：双方各发一个公开值，各自计算共享秘密。ML-KEM 则是封装/解封装模型——发起方持有接收方公钥，执行 Encaps 得到密文 ct 和共享秘密 ss；接收方用私钥执行 Decaps(ct) 恢复同一个 ss。因此集成时不能简单“把 DH 的报文换成 KEM 报文”，而要处理三件事：公钥如何分发（IKEv2 中可放在 KE 载荷，TLS 1.3 中放在 key_share）、密文如何回传、以及共享秘密如何进入既有的密钥派生函数（IKEv2 的 SKEYSEED 派生、TLS 1.3 的 HKDF-Expand-Label）。

混合密钥交换（Hybrid KEM）是工程上更稳妥的选择：同时运行一条经典 DH/ECDH 和一条 ML-KEM，把两个共享秘密拼接后再送入 KDF。这样即使 ML-KEM 实现存在未知缺陷，安全性也不低于经典算法；同时为后量子迁移积累真实握手数据。拼接顺序必须双方约定一致，通常写作 ss = ss_ecdh || ss_mlkem，并在实现文档中固定下来，避免互操作时出现“各自拼接顺序不同导致派生密钥不一致”的隐蔽故障。

二、基于 OpenSSL OQS provider 的 TLS 1.3 集成路径

如果 VPN 采用 TLS 1.3 作为控制通道（例如 OpenVPN 的 TLS 模式、WireGuard 之外的 TLS 隧道方案），最省力的集成方式是使用 OpenSSL 3.x 的 provider 机制加载 OQS provider。它把 ML-KEM 注册为 OpenSSL 可识别的密钥类型与 KEM 算法，使 TLS 1.3 的 key_share 扩展可以直接协商混合组。典型环境准备如下：

# 1. 安装 liboqs 与 oqs-provider（示例版本，实际以发行版为准）
git clone --depth 1 https://github.com/open-quantum-safe/liboqs.git
cmake -S liboqs -B liboqs/build -DBUILD_SHARED_LIBS=ON
cmake --build liboqs/build -j
sudo cmake --install liboqs/build

git clone --depth 1 https://github.com/open-quantum-safe/oqs-provider.git
cmake -S oqs-provider -B oqs-provider/build \
      -DOPENSSL_ROOT_DIR=/usr/local/ssl
cmake --build oqs-provider/build -j
sudo cmake --install oqs-provider/build

# 2. 在 openssl.cnf 中启用 provider
# [provider_sect]
# oqsprovider = oqs_sect
# [oqs_sect]
# module = /usr/local/lib/ossl-modules/oqsprovider.so
# activate = 1

# 3. 验证算法可见性
openssl list -kem-algorithms | grep -i mlkem
openssl list -tls-groups | grep -i mlkem

验证通过后，服务端与客户端在 TLS 1.3 握手中协商混合组，例如 X25519MLKEM768（不同 provider 命名可能略有差异，需以 openssl list -tls-groups 输出为准）。此时抓包会看到 ClientHello 的 key_share 中同时携带 X25519 公钥与 ML-KEM 公钥，ServerHello 回传对应份额，后续 Finished 校验通过即说明双方派生出相同密钥。若握手在 ServerHello 后立即失败，优先检查双方 provider 版本与组名是否一致，而不是怀疑算法本身。

三、基于 liboqs 的 IKEv2 原型改造

IKEv2 没有现成的“KEM 扩展”，需要自行在 KE 载荷中承载 KEM 数据，并修改密钥派生逻辑。以 strongSwan 为例，可在其 crypto 插件层新增一个 hybrid KEM 实现，核心改动集中在三处：

• 算法注册：在 proposal 中新增自定义 transform ID（例如 MLKEM768_X25519），使双方能在 IKE_SA_INIT 的 SA 载荷中协商到该组合；
• KE 载荷编码：发起方把 Q_i 与 ML-KEM 公钥按固定长度前缀拼接后放入 KEi；响应方解析后回传 Q_r 与 ct；
• 密钥派生：在计算 SKEYSEED 前，把 ss_ecdh 与 ss_kem 按约定顺序拼接，替换原来的单一 DH 共享秘密输入。

一个可参考的 liboqs 调用片段如下，用于在发起方完成封装：

#include <oqs/oqs.h>

OQS_KEM *kem = OQS_KEM_new(OQS_KEM_alg_ml_kem_768);
uint8_t *pk = malloc(kem->length_public_key);
uint8_t *ct = malloc(kem->length_ciphertext);
uint8_t *ss_kem = malloc(kem->length_shared_secret);

/* pk 来自对端在 KEi/KEr 中携带的公钥 */
OQS_STATUS rc = OQS_KEM_encaps(kem, ct, ss_kem, pk);
if (rc != OQS_SUCCESS) { /* 记录失败原因并终止握手 */ }

/* 与 ECDH 共享秘密拼接，顺序必须双方一致 */
uint8_t ss_hybrid[32 + kem->length_shared_secret];
memcpy(ss_hybrid, ss_ecdh, 32);
memcpy(ss_hybrid + 32, ss_kem, kem->length_shared_secret);

注意 OQS_KEM_encaps 的返回值必须检查：封装失败可能源于公钥长度不符或内存分配异常，这类错误若被忽略，会表现为“握手随机失败”，极难定位。建议在原型阶段把每次握手的算法组名、公钥长度、密文长度、派生密钥摘要（不记录密钥本身）写入结构化日志，便于后续统计。

四、握手成功率验证方法与判据

原型跑通单次握手只是起点，真正要验证的是稳定性。建议设计三组对照：纯经典组（X25519）、纯后量子组（ML-KEM-768）、混合组（X25519+ML-KEM-768），每组执行不少于 1000 次完整握手，统计成功率、平均握手时延与失败原因分布。成功率判据可设为：混合组成功率不低于纯经典组，且失败样本中不存在“密钥不一致”类错误（该类错误说明拼接顺序或编码存在缺陷，属于必须修复的逻辑问题，而非环境抖动）。

下表给出一个示例统计口径，数值为合理假设的教学示例，不代表真实实测结果：

五、常见集成故障与排查要点

实践中最高频的问题有三类。第一类是组名不匹配：客户端与服务端 provider 版本不同，导致同一算法在两端注册名不一致，表现为协商阶段直接拒绝。第二类是报文长度超限：ML-KEM-768 公钥约 1184 字节、密文约 1088 字节，叠加 ECDH 份额后可能超过某些设备对 IKEv2 单报文或 TLS ClientHello 的隐含上限，需要确认 MTU 与分片策略。第三类是密钥派生输入不一致：拼接顺序、是否包含长度前缀、是否对共享秘密做哈希预处理，任一处不一致都会导致派生密钥不同，最终在 Finished 或 IKE_AUTH 阶段暴露为校验失败。

建议在原型阶段就固定一份“集成契约”文档，写明算法组名、KE 载荷编码格式、拼接顺序、KDF 输入构造方式与日志字段，双方实现严格按契约执行。这样后续替换 provider 版本或升级到正式 ML-KEM 标准时，只需核对契约差异，而不必重新逐字节比对报文。握手成功率达标之后，再进入下一阶段的性能压测与长稳测试，才能把“能握手”推进到“可部署”。