目前在计算机科学领域，有两项技术正在影响和改变着我们的世界。一个是大家都熟悉AI，另一个就是量子计算。全球高科技公司和机构正竞相打造实用性的量子计算机，以解决传统超级计算机也不能解决的计算问题。可以预言的是量子计算机将会深深的改变我们所处的IT基础架构，尤其是对网络安全的负面影响更是无法估量，量子计算将会打破几十年来严重依赖安全加密技术，直接威胁着互联网的安全。

目前实际上已经受到一种潜在的数据安全威胁，这种威胁叫“先抓包后解码（Harvest now, decrypt later，HNDL）”威胁，攻击者通过拦截并大量存储关键的加密流量，然后在未来借助量子计算机进行解密。为了最大可能缓解这一威胁，使用后量子(PQ)加密算法迫在眉睫。作为全球最大的免费代理Cloudflare在这方面的探索处于业界领先，他们正在探索和实践通过重新设计WebPKI架构，以Merkle树证书(MTC)提案来解决PQ 算法在替换传统算法中诸多问题。今天就让我们一起来学习一下MTC及其相关的种种细节。

除了“先抓包后解码（Harvest now, decrypt later，HNDL）”威胁。量子计算机还可以用来破解网站TLS证书，使攻击者能够冒充服务器，诱导用户访问其篡改的内容，进行“中间人”攻击。

安全科学家已经推出了可以抵御量子解密的PQ算法。但是明显不能像一般性算法替换那样将其无缝替换到TLS中去，要启用PQ算法需要对Web公钥基础设施 (WebPKI)进行重大修改。这项工作面对着的是一个最庞大、最复杂，牵涉面最广、安全至关重要的巨大系统工程。

庞大工程之一是在算法方面。以目前最成熟，性能最高的PQ算法ML-DSA-44为例：

ML-DSA-44算法签名长度为2420字节，公钥长度为1312字节。作为对比目前最流行的非PQ签名算法ECDSA-P256，其签名仅为64字节，公钥长度也仅为64字节。对比ECDSA-P256计算量大幅增加（约20倍）。

再者，在HTTPS传输协议握手过程中牵扯到多个公钥和签名，总共算过来，使用ML-DSA-44算法单次HTTPS握手的开销高达数十KB，严重影响TLS的性能。

很明显现成的直接替换PQ证书的方案在今天难以推广。

为此，需要找到一种方法，让后量子证书足够简易且高效，以便每个人默认都能部署，而且不会带太大负担。通过研究和探索Cloudflare联合IETF提出 Merkle树证书(MTC)提案来解决这个问题。在提案中改造TLS握手认证过程，将使用的公钥和签名数量减少到最低限度，且不会造成任何影响安全。联合谷歌Chrome安全中心，他们已经部署了试验性质的MTC基础（相关组件以通过Github开源），根据Cloudflare提供的数据，目前其流量中大约一半（48.3%）已经使用了PQ算法加密。

当你的浏览器连接到一个网站时，它会要求服务器进行身份验证，以确保它正在与真正的服务器而不是冒名顶替者通信。这通常通过一种称为数字签名方案（例如ECDSA或ML-DSA）的加密算法来实现。在TLS中，客户端和服务器使用不对称的加密方式进行加密通讯：客户端使用服务器的公钥对客户端和服务器之间交换的消息进行签名；服务器使用私钥验证签名。通过这种方式，服务器向客户端确认它们进行了相同的对话，因为只有服务器才能生成有效的签名。

如果客户端已经知道（保存）服务器的公钥，那么只需要一个签名即可验证服务器身份。然而，在实践中，这并非一个可行的方案。如今的网络由大约十亿台TLS服务器组成，因此为每个客户端保存每台服务器的公钥是不现实的。此外，随着新服务器上线以及现有服务器密钥的轮换，公钥集也会随着时间推移而发生变化，因此需要一种方式将这些变化推送给客户端。这个扩展问题是所有PKI设计的核心。

服务器可能不需要客户端提前知道服务器的公钥，而是在TLS握手期间发送自己的公钥。但是客户端如何确认收到公钥确实是属于服务器而不是别人冒充的呢？这就需要证书来作保。

证书将公钥与服务器的身份绑定在一起，通常是域名名称，例如： ijz.me证书由客户端已知的证书颁发机构 (CA),Cloudflare公钥签名。除了验证服务器的握手签名外，客户端还要验证该证书的签名。这便建立了一条信任链：客户端接受该网站证书（CA签发），即表示其信任CA已验证该公钥确实属于具有相应身份的服务器。

客户端通常配置为信任多个CA，并且保存每个CA的公钥（根证书）。由于CA数量有限，只有几十到上百个（操作系统和浏览器默认安装时带的），而不是数十亿个，对其处理简单得多。此外，无需更新客户端即可创建新证书。

这样使得实现成本相对较低：每次TLS握手，每个用户只需要+1签名和+1公钥，总共需要2个签名（域签名和消息签名）和1个公钥（网站公钥）。

然而，随着WebPKI的发展，这些信任链也变得越来越长。如今，信任链通常由两个或多个证书组成。这是因为CA有时需要像服务器一样轮换密钥。但在开始使用新密钥之前，它们必须将相应的公钥分发给客户端。这需要时间，因为它需要数十亿客户端更新其信任库。为了弥补这一差距，CA有时会使用旧密钥为新证书颁发证书，并将此证书附加到信任链的末尾。

也就是说，这样就需要+1签名和+1公钥，总计要3个签名和2个公钥。

CA的主要职责是验证服务器是否对其申请证书的域名拥有控制权。多年来，这一流程已从高接触度、特定于CA的流程演变为标准化、基本自动化的流程，用于颁发网络上的大多数证书。确保错误颁发可被检测到是证书透明度(CT)生态系统的职责。其基本理念是，每个由 CA 颁发的证书都会被添加到公共日志中。服务器可以审计这些日志，以查找以其名义颁发的证书。如果颁发了非服务器自行申请的证书，服务器运营商可以证明该证书确实被颁发PKI生态系统也可以采取措施，防止客户端信任该证书。

主流浏览器（包括火狐、Chrome及其衍生产品）都要求证书必须经过日志记录才能被信任。例如，Chrome、Safari和火狐仅当服务器证书出现在浏览器配置为信任的至少两个日志记录中时，才会接受该证书。这项政策说起来容易，但在实践中却很难实施：

首先，维护CT日志的成本都相当高昂。日志在其生命周期内会吸收数十亿份证书：当事件发生时，或者仅仅是在高负载下，日志都可能需要一些时间才能为审计人员提供新的记录。

另外，客户端实际上无法自己审核日志，因为这会将他们的浏览历史记录（即他们想要连接的服务器）暴露给日志操作员。

解决这两个问题的方法是将CT日志的签名与证书一起包含在内。该签名会在记录证书的请求后立即生成，并证明日志会在24小时内将证书记录到日志中。

根据浏览器策略，每个日志证书透明度会在TLS握手中增加2个签名，这样典型TSL握手中，总共就需要5个签名和2个公钥。

WebPKI是一个充满活力、高度分布式的系统。多年来，不得不多次通过修修补补维持正常运行，但总的来说，直到现在仍然很好地满足了互联网需求。

以前，每当我们需要更新WebPKI中的某些内容时，都会添加另一个签名。这种策略之所以有效，是因为传统密码学的成本非常低。但是，对于即将出现的更大规模的PQ算法签名来说，每次TLS握手平均需要的5个签名和2个公钥，成本有点太大。

好消息是，通过巧妙地重新设计，可以大幅减少所需的签名数量。为此Cloudflare引入一个全新算法架构Merkle树。

Merkle树证书(MTC)是Cloudflare的下一代WebPKI研究实践，并已经提交IETF的提案。其主要功能如下：

客户端验证Merkle树证书所需的所有信息都可以在带外传播。如果客户端足够及时更新，则TLS握手只需要1个签名、1个公钥和1个 Merkle树包含证明。即使使用后量子算法，其交互数据量也相当小。

MTC规范让每个CA运行其颁发的证书的日志，从而使证书透明度成为PKI的首要特性。

稍微深入一下。下面为一个测试生成的MTC示例，它会在TLS握手过程中从服务器传输到客户端：

看起来像是普通的PEM编码证书。可以通过openssl解码一下，看看其内容：

openssl x509 -in merkle-tree-cert.pem -noout -text

结果大多数参数看起来都很熟悉，但其他一些参数则可能看起来有点特别。熟悉的参数中，主题和公钥正如所预期的那样：DNS名称是cloudflareresearch（dot）com公钥用于一种常见的签名算法，即ECDSA-P256。当然，该算法还不是PQ算法，将来会用ML-DSA-44算法替换。

结果中OpenSS似乎无法识别签发者的签名算法，而只是打印原始的OID和签名的字节数。实际上， MTC中根本就没有签名。这是因为，通过巧妙设计Merkle树认证机构 (MTCA) 会 批量生成无签名证书，而不会单独生成一个个的证书。证书无需签名，而是会提供证书证明。 该证明直接包含在MTCA签名的一批证书中。

为了理解包含证明的工作原理，针对MTC规范做个教学简化版。为了签发一批证书，MTCA 将未签名的证书排列成一个称为Merkle树的 数据结构，如下所示：

树的每个叶子节点对应一个证书，每个内部节点等于其子节点的哈希值。为了对批次进行签名，MTCA使用其密钥对树的头部进行签名。树的结构保证了批次中的每个证书都由MTCA签名：如果尝试调整任何一个证书的位，树的头部最终都会具有不同的值，从而导致签名失败。

证书的包含证明由从证书到树头的路径上每个兄弟节点的哈希值组成：

给定一个已验证的树头，这串哈希值就足以证明证书包含在树中。这杨，为了验证MTC，客户端还需要从MTCA获取已签名的树头。MTC高效的关键：

签名的树头证书可以通过带外方式分发给客户端，并进行离线验证。每个已验证的树头证书都可以用来验证相应批次中的任意证书，无需为每个服务器证书获取签名。

在TLS握手过程中，客户端会告知服务器它拥有哪些树头。如果服务器拥有一个由这些树头之一覆盖的无签名证书，则可以使用该证书进行身份验证。这意味着每次握手都需要1个签名、1个公钥和1个包含证明，这三个证书都用于被身份验证的服务器。

另外MTC本身还有一些额外的功能。首先，它不会为每个批次创建单独的Merkle树，而是生长一棵大树，用于提高透明度。随着这棵树的生长，会定期选择（子）树头发送到浏览器，这被称之为地标 。在常见情况下，浏览器将能够获取最新的地标，服务器可以等待批量颁发，但还有一个后备方案：MTC支持可以立即颁发且不需要验证地标的证书，但这些证书没有那么小。这样服务器可以提供两种类型的Merkle树证书：常见情况下快捷高效的地标子树头；以及特殊情况下的比较大的树证书验证，比较慢，但至少保证可以工作。

Merkle树证书 (MTC) 通过将签名和公钥的数量降至最低，同时保留WebPKI的基本属性，解决了面对量子时代Web安全基础的问题，这是对未来WebPKI有益的探索和实践，希望这个方案能更快的推广，来保证量子计算时代的互联网安全根基，同时也解决时下已经潜在的先抓包后解码（Harvest now, decrypt later，HNDL）”威胁