知识库 / Merkle Tree Certificates：后量子时代 Web PKI 的架构重构

Merkle Tree Certificates：后量子时代 Web PKI 的架构重构

协议详解 · 2026-06-08

问题引出：后量子签名的尺寸危机

后量子密码学（PQC）的标准化已取得决定性进展。NIST 已于 2024 年发布 FIPS 204（ML-DSA）和 FIPS 205（SLH-DSA），IETF 也在推进 TLS 集成。然而，将 PQC 算法直接嵌入现有 X.509 证书体系面临一个根本性障碍：签名尺寸过大。

以下是主流算法的关键参数对比：

算法公钥大小（字节）签名大小（字节）安全级别
ECDSA P-2566464~128 bit
ML-DSA-441,3122,420~128 bit
ML-DSA-651,9523,309~192 bit
ML-DSA-872,5924,627~256 bit
FN-DSA-512897666~128 bit
SLH-DSA-SHA2-128s327,856~128 bit
一个典型的 TLS 握手携带 5 个签名 + 2 个公钥。如果将 ECDSA P-256 直接替换为 ML-DSA-44：

  • 当前：5 × 64 + 2 × 64 = 448 字节
  • 替换后：5 × 2,420 + 2 × 1,312 = 14,724 字节
  • 增长倍数：约 33 倍
这不是理论推演。Cloudflare 的实测数据显示，当 TLS 握手载荷超过 10 KB 时，约 5% 的连接会因中间件（防火墙、负载均衡器、IDS）无法处理 oversized TLS 记录而直接失败，其余连接则因超出 TCP 初始拥塞窗口（~14.5 KB）而触发额外的网络往返，导致延迟显著增加。

Google 的内部评估标准更为明确：

  • 增加 ~2 KB 的握手开销："非常痛苦，但尚可接受"
  • 增加 ~7 KB："不可行，除非量子计算机已迫在眉睫"
  • 增加 ~15 KB："完全不可接受"
没有任何已标准化的 PQC 签名方案能在包含 CT 证书透明度签名的情况下，将完整 TLS 认证数据控制在 7 KB 以内。

设计思想：从逐证书签名到批量承诺

Merkle Tree Certificates（MTCs）的核心洞察不是发明新的密码学算法，而是重新设计签名的应用方式——从"每个证书各签一次"变为"一次签名覆盖数百万证书"。

传统 X.509 签发模型

CODE
CA 签名证书₁ → 证书₁（含 CA 签名 + 2 个 CT SCT 签名）
CA 签名证书₂ → 证书₂（含 CA 签名 + 2 个 CT SCT 签名）
CA 签名证书₃ → 证书₃（含 CA 签名 + 2 个 CT SCT 签名）
...
CA 签名证书ₙ → 证书ₙ（含 CA 签名 + 2 个 CT SCT 签名）

每个证书独立携带完整的签名链。n 个证书需要 n 次签名操作和 n × 3 个签名。

MTC 批量签发模型

CA 不再逐个签名证书，而是：

  • 接收证书请求，构建包含所有待签发证书的 Merkle 树
  • 对树根哈希（Root Hash）进行一次签名——这就是 Landmark
  • 每个证书的"证明"变为从叶节点到根路径上的兄弟节点哈希链

MTC 系统架构

MTC 协议（IETF draft-ietf-plants-merkle-tree-certs）定义了五个角色：

各角色职责

角色职责
CA（证书颁发机构）构建 Merkle 树，签发 Landmark，管理证书批次
CT Log（证书透明度日志）存储证书哈希，提供 append-only 审计日志
Cosigner（共签者）独立验证日志的 append-only 性质，为 Landmark 提供共签
Authenticating Party（服务器）持有证书和包含证明，在 TLS 握手期间向客户端出示
Relying Party（浏览器/客户端）通过带外通道获取 Landmark 哈希，验证证书包含证明

两种证书类型

MTC 定义了两种证书类型，以应对不同客户端状态：

Landmark 证书（签名证书）

这是 MTC 的效率突破点。当客户端已通过带外通道（浏览器更新）获取了相关 Landmark 哈希时，服务器可以出示不含任何签名的证书。

CODE
Landmark 证书结构：
┌──────────────────────────────┐
│  certificate: 公钥 + 元数据   │  ← 与 X.509 类似
│  landmark:    树大小标识       │
│  inclusion_proof: [h₁, h₂,   │  ← Merkle 包含证明
│                  h₃, ..., hₖ] │
└──────────────────────────────┘

包含证明大小：对于包含 ~440 万证书的树，证明仅需 23 个 SHA-256 哈希 = 736 字节。

证明大小随树规模对数增长：

树规模证明长度（哈希数）证明大小（字节，SHA-256）
2,50012384
4,400,00023736
4,300,000,000321,024
关键优势：整个 TLS 握手仅需传输 1 个签名（Landmark 签名，由浏览器缓存）+ 1 个公钥 + 1 个包含证明。总认证数据可控制在 1 KB 以内，比当前 ECDSA 方案还小。

Standalone 证书（独立证书）

当客户端 Landmark 缓存过期或不可用时，服务器回退到 Standalone 模式：

CODE
Standalone 证书结构：
┌──────────────────────────────┐
│  certificate: 公钥 + 元数据   │
│  inclusion_proof: [h₁, ..., hₖ]│
│  cosignatures:               │
│    ┌─ CA 签名（PQ 算法）      │
│    └─ Cosigner 签名          │
└──────────────────────────────┘

Standalone 证书更大，但仍远小于朴素 PQ X.509 链，因为它只包含 1 个 CA 签名和 1 个 Cosigner 签名（而非 3-5 个）。

证书类型协商

TLS 握手期间，客户端通过新增的 mtc 扩展告知服务器自己已缓存的 Landmark 信息：

CODE
ClientHello {
    mtc_extensions {
        landmark_versions: [v₁, v₂, ...]  // 客户端已知的 Landmark 版本
    }
}

服务器据此选择最优证书类型：

  • 客户端有有效 Landmark → 返回 Landmark 证书（736 字节）
  • 客户端 Landmark 过期 → 返回 Standalone 证书（含签名）
  • 客户端不支持 MTC → 回退到传统 X.509 证书

与证书透明度的深度融合

MTC 的一个关键设计是将证书透明度（CT）从"附加组件"变为"结构必需"。

当前 CT 的困境

自 RFC 6962 标准化以来，CT 已成为 Web PKI 的重要组成部分。但当前 CT 存在结构性问题：

  • 额外签名开销：每个证书携带 2 个 SCT 签名（来自不同 CT 日志），增加了握手数据量
  • 量子脆弱性：SCT 使用经典签名算法（ECDSA/RSA），Shor 算法可伪造 SCT，使浏览器误信某个证书已被记录
  • 运维脆弱性：CT 日志是独立基础设施，一旦故障会影响所有证书签发
  • 数据膨胀：PQC 签名尺寸增大 10 倍，CT 日志的存储和镜像开销同步增大

MTC 的解决方案

CODE
当前模型（CT 附加）：
  证书 → CA 签名 + SCT₁ 签名 + SCT₂ 签名
  TLS 握手携带：证书 + 3 个签名

MTC 模型（CT 融合）：
  证书 → 包含在 Merkle 树中 → Landmark 签名覆盖整棵树
  TLS 握手携带：证书 + 包含证明（替代所有签名）

MTC 通过以下机制消除上述问题：

问题当前 CTMTC 融合 CT
SCT 签名每个证书 2 个0 个（包含证明替代）
量子脆弱性SCT 可被量子伪造Merkle 哈希抗量子
日志独立性独立第三方日志日志与签发流程不可分割
签发延迟先签发再提交日志先入树再签名，原子化
正如 IETF draft 主要作者 David Benjamin 所述：

"Merkle Tree Certificates 将 CT 融入证书签发流程，而非事后附加。"

安全分析

抗量子安全性

MTC 中唯一的密码学签名是 Landmark 签名（覆盖 Merkle 树根）。Google 和 Cloudflare 计划使用混合签名方案（如 ECDSA + ML-DSA），攻击者必须同时破解两种算法才能伪造 Landmark。

Merkle 树本身基于哈希函数（SHA-256 或 SM3），其安全性仅依赖于哈希函数的抗碰撞性，不受量子计算影响（Grover 算法仅将哈希安全性减半，256 位哈希仍有 128 位量子安全强度）。

Split-View 攻击防御

传统 CT 的最大威胁是日志服务器对不同客户端展示不同视图。MTC 通过多层防御应对：

签发延迟的新攻击面

MTC 的批量签发模型引入了新的时间维度：证书从请求到获得有效 Landmark 锚定可能需要数分钟到数小时（取决于 Landmark 生成频率）。在此期间：

  • 新签发证书无法立即使用：需要等待下一个 Landmark 生成
  • 时间窗口攻击：攻击者可能利用签发延迟窗口进行域名劫持
  • 缓解措施：服务器可同时持有传统 X.509 证书作为过渡

与其他 PQC 迁移方案的对比

方案TLS 认证开销兼容性标准化状态适用场景
MTC~736 字节需新基础设施IETF PLANTS draftWeb 浏览器
ML-DSA in X.509~14,700 字节完全兼容NIST FIPS 204不适合 Web TLS
复合证书~17,000-20,000 字节协议兼容IETF LAMPS 近 RFC企业 PKI、S/MIME
FN-DSA (Falcon)~5,000-8,000 字节完全兼容FIPS 206 草案CA 级别签名
KEMTLS~2,000-5,000 字节需 TLS 改动研究阶段未来优化
中间证书抑制节省 ~4,000-5,000 字节向后兼容多个 IETF 草案过渡期缓解
关键结论：没有任何已标准化的"即插即用"PQC 签名方案能满足 Google 的 7 KB 可行性阈值。MTC 通过架构创新而非算法改进绕过了这一限制。

实施路线与生态影响

Google 的三阶段推进计划：

阶段时间目标
Phase 12026 年（进行中）与 Cloudflare 联合可行性测试，约 1,000 个证书，Chrome 初步 MTC 支持
Phase 22027 Q1邀请 CT Log 运营商启动公共 MTC 基础设施
Phase 32027 Q3启动 Chrome Quantum-resistant Root Store (CQRS)，仅信任 MTC
Let's Encrypt 也于 2026 年 6 月宣布选择 MTC 作为其 PQC 迁移路径，目标 2026 年底在测试环境签发 MTC，2027 年生产环境部署。

对国密 PKI 体系的启示

MTC 架构对国密 PKI 的参考价值不在于直接复制（MTC 依赖 Web 浏览器生态），而在于其核心设计思想——通过批量化签名降低单次签名的尺寸和成本——可以启发国密体系的架构思考：

  • SM2 → 后量子算法的过渡策略：当前国密体系以 SM2 为核心签名算法。NIST PQC 标准发布后，国密体系同样面临后量子迁移压力。MTC 的批量签名架构提供了一种思路：当 SM2 需要替换为后量子算法（如 ML-DSA）时，可通过批量签发控制签名膨胀，而非简单地将每个证书替换为独立的 PQC 证书。
  • GM/T 0034-2014 体系的扩展可能：国密证书认证系统（GM/T 0034-2014）定义了证书签发、管理、撤销的完整流程。MTC 的 Merkle 树批量签发模型可以作为该标准的扩展参考——在保持国密算法（SM2/SM3/SM4）不变的前提下，引入批量签发机制以应对未来 PQC 迁移的尺寸挑战。
  • 国密 CT 日志的架构优化：当前国密 CT 日志（使用 SM3 替代 SHA-256）是独立于签发流程的附加组件。MTC 将 CT 融入签发流程的设计思想，可以指导国密 CT 日志从"事后审计"升级为"签发必需"，提升整体透明度。
注意：MTC 目前主要面向 Web 浏览器场景，国密 PKI 体系（尤其是金融、政务领域的离线 PKI）在架构上有本质差异。直接移植 MTC 不可行，但其批量签名和 Merkle 树包含证明的思想具有方法论层面的参考价值。

争议与挑战

生态碎片化

MTC 主要优化浏览器场景。非浏览器客户端（curl、Python、IoT 设备）面临 Landmark 分发难题。虽然可在操作系统层面部署 Landmark 缓存服务（如 /etc/ssl/treeheads），但这需要全新的基础设施。

企业 TLS inspection 失效

企业网络中的 TLS 检查代理、下一代防火墙、DLP 设备均硬编码解析 X.509 证书链。MTC 从根本上改变了 TLS 握手中的数据结构，除非安全厂商更新引擎，否则 MTC 流量可能被静默阻断。

签发延迟对 DevOps 的影响

传统 PKI 中 CA 签名并交付证书仅需毫秒级。MTC 的批量模型引入分钟到小时级的延迟。依赖即时证书签发的微服务架构需要重新设计签发工作流。

总结

Merkle Tree Certificates 代表了 Web PKI 自 X.509 标准以来最根本的架构变革。其核心创新不在于密码学算法本身，而在于重新设计了签名的应用粒度——从逐证书签名到批量承诺，再通过 Merkle 包含证明将验证开销压缩到对数级。

这一架构解决了后量子迁移中最紧迫的尺寸问题，同时将证书透明度从可选附加项提升为结构性必需。尽管生态碎片化和签发延迟等挑战仍然存在，但 Google、Cloudflare、DigiCert、Let's Encrypt 等关键基础设施参与者的共同推动，使 MTC 成为后量子 Web PKI 最可行的演进路径。

参考来源

相关实践

← 返回知识库