用 Merkle Tree Certificates 构建面向后量子时代的证书颁发机构

2026-09-29 19 预计阅读时间: 1 分钟
来源: blog.cloudflare.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：11 分钟

后量子签名正在改变 TLS 证书系统的成本结构。许多候选算法的公钥和签名明显大于今天常用的椭圆曲线方案；如果仍然为每张证书附带一份独立签名，TLS 握手、证书分发和证书透明度日志都会承担额外的网络与存储压力。

Merkle Tree Certificates（MTC）的核心方向，是把一批证书声明放进 Merkle 树，由 CA 对树根及其上下文签名，再让每张证书携带自己的 Merkle 包含证明。Cloudflare 披露的新证书颁发机构将支持大规模签发 MTC，这使该方案不再只是密码学层面的压缩技巧，也成为值得工程团队评估的 CA 架构。

从“每张证书一次签名”转向“每批证书一次承诺”

传统证书的信任关系可以简化为：CA 对单张证书中的主体、公钥、有效期和扩展字段签名。验证者拿到证书后，直接验证这份签名。

在一种典型的 MTC 设计中，流程会变成：

  1. CA 将一批规范化后的证书声明分别哈希为叶子节点。
  2. 这些叶子节点组成 Merkle 树。
  3. CA 对包含树根、批次标识、有效时间和算法标识的 Tree Head 签名。
  4. 每张证书携带叶子数据、到树根的包含证明，以及对应的已签名 Tree Head。
  5. 客户端先重算 Merkle 路径，再验证 Tree Head 的 CA 签名。

如果一个批次包含 N 张证书，那么包含证明通常需要大约 log2(N) 个哈希值。它并没有消除密码学数据，而是用较短的哈希路径替代每张证书中重复出现的大型后量子签名，将一次签名的成本摊销到整个批次。

这也带来了新的取舍：批次越大，签名摊销效果越好，但 Merkle 路径会略微变长，而且 CA 可能需要等待批次形成。对要求秒级签发的系统来说，批次大小不能只按压缩率决定，还要同时约束最大等待时间。

TLS 和透明度系统会发生什么变化

MTC 最直接的收益是减少重复的 CA 签名材料。对于后量子 TLS，这可能缓解三类压力：

  • 握手字节数：证书链中的大型签名会直接增加握手负载，在高延迟或容易丢包的网络上尤其明显。
  • 透明度日志体积：如果每份日志记录都完整复制较大的证书与签名，存储、同步和审计成本会持续增长。
  • CA 签名吞吐量：批量承诺允许 CA 将一次签名覆盖到多份证书声明，不过叶子构造、批次管理和证明生成仍需可靠实现。

但“更紧凑”不等于可以绕过透明度。真正可审计的部署仍要明确回答：Tree Head 如何发布，监控者如何发现不一致的树根，日志记录证书叶子还是批次承诺，以及客户端如何获得足够证据判断一张证书确实属于公开批次。

兼容性也是现实约束。现有 TLS 客户端通常理解的是传统 X.509 证书链，不会自动识别新的包含证明。实际迁移可能需要双轨签发、能力协商，或者先在受控客户端和内部服务之间部署，而不是直接替换全部公网证书。

用 Python 理解包含证明

下面是一个可以直接运行的教学示例。它展示如何把四条证书声明放入 Merkle 树，并验证其中一条声明的包含证明。

这个示例不是 MTC 标准实现：它没有证书字段编码、Tree Head 元数据、CA 签名、算法协商和透明度日志，仅用于验证最核心的 Merkle 包含关系。生产系统应使用协议规定的规范化编码和域分离规则，不能直接把这里的字符串拼接方式用于真实证书。

将以下内容保存为 mtc_demo.py：

from hashlib import sha256


def leaf_hash(data: bytes) -> bytes:
    # 0x00 用于区分叶子哈希和内部节点哈希
    return sha256(b"\x00" + data).digest()


def node_hash(left: bytes, right: bytes) -> bytes:
    # 0x01 防止不同节点类型产生歧义
    return sha256(b"\x01" + left + right).digest()


def build_tree(items: list[bytes]) -> list[list[bytes]]:
    if not items:
        raise ValueError("tree must contain at least one item")

    levels = [[leaf_hash(item) for item in items]]
    while len(levels[-1]) > 1:
        current = levels[-1]
        next_level = []
        for i in range(0, len(current), 2):
            left = current[i]
            right = current[i + 1] if i + 1 < len(current) else left
            next_level.append(node_hash(left, right))
        levels.append(next_level)
    return levels


def inclusion_proof(levels: list[list[bytes]], index: int):
    proof = []
    for level in levels[:-1]:
        if index % 2 == 0:
            sibling_index = index + 1 if index + 1 < len(level) else index
            proof.append(("R", level[sibling_index]))
        else:
            proof.append(("L", level[index - 1]))
        index //= 2
    return proof


def verify(item: bytes, proof, expected_root: bytes) -> bool:
    current = leaf_hash(item)
    for side, sibling in proof:
        if side == "L":
            current = node_hash(sibling, current)
        else:
            current = node_hash(current, sibling)
    return current == expected_root


certificates = [
    b"example.com|key=K1|not_after=2026-06-01",
    b"api.example.com|key=K2|not_after=2026-06-01",
    b"shop.example.net|key=K3|not_after=2026-06-01",
    b"internal.example.org|key=K4|not_after=2026-06-01",
]

levels = build_tree(certificates)
root = levels[-1][0]
proof = inclusion_proof(levels, index=1)

print("root:", root.hex())
print("proof length:", len(proof))
print("valid certificate:", verify(certificates[1], proof, root))
print(
    "tampered certificate:",
    verify(b"api.example.com|key=ATTACKER|not_after=2026-06-01", proof, root),
)

运行：

python mtc_demo.py

预期结果中，原始声明验证为 True，被替换公钥后的声明验证为 False。在真正的 CA 中，还需要对类似下面的结构进行后量子签名，而不是只签裸树根：

TreeHead = {
  version,
  batch_id,
  merkle_root,
  valid_from,
  valid_until,
  signature_algorithm,
  canonicalization_version
}

把版本、有效期和算法标识纳入签名范围，可以避免同一个树根被错误地复用到另一批次或另一套解释规则中。

落地 CA 时要重点检查什么

MTC 改变的不只是证书格式，还会改变 CA 的签发流水线。准备原型时，可以按下面的清单拆分工作：

  • 规范化编码：同一份证书声明在所有实现中必须产生完全相同的字节序列。JSON 字段顺序、Unicode 处理或可选字段差异都可能导致根哈希不一致。
  • 批次策略：同时设置最大叶子数和最大等待时间，避免低流量时证书长时间停留在队列里。
  • 签名上下文：签名对象应覆盖树根、协议版本、批次标识、有效期和算法信息，而不只是一个哈希值。
  • 密钥隔离：批次签名仍应在 HSM 或等价隔离环境中完成。摊销签名次数不能成为降低私钥保护等级的理由。
  • 证明分发：证书主体、包含证明和已签名 Tree Head 必须保持一致，并支持缓存、重建和灾难恢复。
  • 透明度与监控：需要能够发现 CA 为不同观察者发布冲突 Tree Head 的情况，不能只验证本地包含证明。
  • 撤销与短周期证书：Merkle 包含证明只能说明“曾被某个已签名批次包含”，不会自动解决撤销和当前状态问题。
  • 算法敏捷性：后量子算法仍在演进，格式中应明确算法与参数，避免将系统永久绑定到单一签名方案。
  • 兼容与回退：迁移期间应定义传统证书链、MTC 和混合签名之间的选择规则，并防止攻击者强制降级。

对团队而言，较稳妥的采用路径不是立即重写公网 PKI，而是先建立可测量的试验环境：记录传统证书与 MTC 的握手字节数、签发等待时间、证明生成吞吐量、日志增长速度和客户端验证耗时。只有当这些指标连同透明度、撤销和兼容方案都能闭环时，Merkle Tree Certificates 才真正从“节省签名字节”升级为可运营的后量子 CA 架构。

# Cloudflare # 云平台 # 平台工程

相关推荐