来源: https://blog.cloudflare.com/post-quantum-ipsec/
虽然超过三分之二的人类生成的流向 Cloudflare 的 TLS 流量已经受到后量子加密技术的保护，但站点到站点网络领域的情况却截然不同。多年来，IPsec 社区一直面临着互联网规模互操作性的高标准和专用硬件的特定需求之间的两难困境。如今，这一差距正在缩小。
本月初，我们宣布受量子计算领域近期多项进展的推动，Cloudflare 已将全面实现后量子安全的目标提前至 2029 年。为了推进这一目标的实现，我们已正式向公众开放 Cloudflare IPsec 中的后量子加密功能。
使用新的 IETF 混合 ML-KEM 草案（FIPS 203 ），我们已成功测试了与Fortinet和Cisco分支连接器的互操作性——这意味着您今天就可以使用您已有的硬件开始保护您的广域网 (WAN) 免受“先收集后解密”攻击。
这篇文章解释了我们如何实现新的混合 IPsec 握手，为什么它比其 TLS 对应版本晚了四年才最终实现，以及业界最终如何围绕一个可在互联网规模上运行的标准进行整合。
Cloudflare IPsec
Cloudflare IPsec是一种广域网即服务 (WAN Network-as-a-Service)，它通过将数据中心、分支机构和云虚拟私有云 (VPC) 连接到 Cloudflare 的全球IP Anycast网络，取代了传统的网络架构。客户可以获得简化的配置、高可用性（如果某个数据中心不可用，流量会自动重新路由到最近的可用数据中心）以及 Cloudflare 全球网络的扩展能力。这一切都通过加密的 IPsec 隧道实现，这些隧道支持站点到站点的广域网连接、出站互联网连接以及与Cloudflare One SASE 平台的连接。
IPsec中的后量子加密
Cloudflare IPsec 现在采用混合 ML-KEM（ FIPS 203 ）的后量子加密技术，以阻止“先窃取后解密”攻击。这类攻击是指攻击者在今天窃取数据，然后在 Q 日之后解密。届时，强大的量子计算机将能够破解互联网上普遍使用的传统公钥加密技术。随着Q 日的临近速度超出预期， “先窃取后解密”攻击正日益引起越来越多组织的关注。
ML-KEM（基于模块格的密钥封装机制）是一种后量子密码算法，它基于一些数学假设，这些假设目前已知不会受到量子计算机的攻击。它不需要特殊的硬件，也不需要发送方和接收方之间专用的物理链路。ML-KEM 的设计初衷就是为了能够在标准处理器上以软件形式实现，从而为网络流量提供后量子加密。
Draft-ietf-ipsecme-ikev2-mlkem规范了使用混合 ML-KEM的 IPsec 后量子加密。该规范将经典 Diffie-Hellman 加密的成熟安全性与 ML-KEM 的后量子安全性结合在一个符合标准的握手过程中。具体来说，首先执行经典 Diffie-Hellman 交换，其派生的密钥加密第二个 ML-KEM 交换，并将两次交换的输出混合到会话密钥中，从而保护使用封装安全有效载荷 (ESP) 协议发送的 IPsec 数据平面流量。
我们的互操作性实现
此前，我们宣布在 Cloudflare IPsec 产品中对 draft-ietf-ipsecme-ikev2-mlkem 标准进行封闭测试，并与参考实现（strongswan）进行了对比。现在，该标准已正式发布，我们也确认了其与包括 Cisco 和 Fortinet 在内的多家厂商的互操作性，这对该新标准而言是一项重大胜利。
Cisco： 使用Cisco 8000 系列安全路由器 26.1.1 版本之后版本作为分支连接器的客户现在也可以根据 draft-ietf-ipsecme-ikev2-mlkem 建立后量子 Cloudflare IPsec 隧道。
Fortinet： 使用Fortinet FortiOS 7.6.6 及更高版本作为其分支连接器的客户现在可以按照 draft-ietf-ipsecme-ikev2-mlkem 建立到 Cloudflare 全球网络的后量子 Cloudflare IPsec 隧道。
互操作性的重要性
鉴于密码学升级难度大且耗时数年，我们计划于 2029 年全面升级到后量子密码学，这需要集中精力。因此，我们希望 IPsec 社区继续专注于开发互操作标准，例如 draft-ietf-ipsecme-ikev2-mlkem。
让我们解释一下这些标准为何至关重要。IPsec 中混合 ML-KEM 的完整规范 draft-ietf-ipsecme-ikev2-mlkem 直到 2025 年底才发布。这比 TLS 对混合 ML-KEM 的支持晚了大约四年。（事实上，Cloudflare早在 2022 年就启用了与 TLS 的混合后量子密钥协商，甚至早于 NIST 最终确定 ML-KEM 的标准化，因为 TLS 社区迅速达成共识，采用单一的、可互操作的方法并将其投入生产。如今，Cloudflare 网络中超过三分之二的人为 TLS 流量都受到混合 ML-KEM 的保护。）
四年的延迟很可能部分归因于IPsec社区对量子密钥分发（QKD）的持续关注，该技术已在2020年发布的RFC 8784中进行了规范。我们之前曾撰文解释过为什么QKD不属于我们的后量子战略：QKD需要专用硬件和双方之间的专用物理链路，这从根本上说意味着它无法在互联网规模下运行。此外，QKD不提供身份验证，因此您仍然需要后量子密码技术来阻止主动攻击者。而且，很难找到能够跨厂商互操作的QKD实现。
美国国家安全局、德国联邦信息安全局和英国国家网络安全中心都曾警告不要仅仅依赖量子密钥分发（QKD）。相比之下，后量子密码技术可以在你现有的硬件上运行，对两端的参与方进行身份验证，并且可以在互联网上实现端到端的加密。
2023 年发布的 RFC 9370 为 IPsec 开启了后量子密码学的大门，允许最多七个密钥交换与经典的 Diffie-Hellman 密钥交换并行运行。然而，RFC 9370 并未明确规定这些并行密钥交换应使用哪些密码套件。由于缺乏相关规范，一些厂商在混合 ML-KEM 草案发布之前，就根据 RFC 9370 发布了早期实现，并定义了自己的密码套件，其中一些甚至不符合 NIST 标准。这正是NIST SP 800 52r2 所警告的“密码套件臃肿”问题。而这种互操作性风险也已在实践中显现：Cloudflare IPsec 目前尚无法与 Palo Alto Networks 基于 RFC 9370 的实现互操作，因为后者发布于 draft-ietf-ipsecme-ikev2-mlkem 草案发布之前。
幸运的是，我们现在有了 draft-ietf-ipsecme-ikev2-mlkem，它填补了 RFC 9370 的空白，将混合 ML-KEM 指定为可以与经典 Diffie-Hellman 并行运行的关键交换机制之一。随着业界继续围绕 draft-ietf-ipsecme-ikev2-mlkem 进行整合，我们希望将 Palo Alto Networks 添加到可互操作的后量子分支连接器列表中。
但迈向可互操作的后量子IPsec标准的征程尚未结束。虽然draft-ietf-ipsecme-ikev2-mlkem支持后量子加密 ，但我们仍然需要后量子认证的IPsec标准， 以便在量子日之后阻止量子攻击者对运行系统的攻击。鉴于全面实现后量子就绪的时间已经缩短，我们希望IPsec社区继续专注于可互操作的后量子认证（PQC）实现，而不是将注意力转移到量子密钥分发（QKD）的小众用例上。