Cloudflare 如何利用 AI 规划抗量子加密迁移

随着全球各地的实验室竞相构建具备密码学意义的量子计算机，我们 Cloudflare 也在朝着2029 年实现全面后量子就绪的目标期限全力冲刺。虽然我们已经将许多产品迁移至后量子加密，但要支持后量子身份验证并在整个平台实现全面后量子就绪，我们仍有工作要做。

我们采取了极简主义立场（“一切皆 PQ！”），因为作为全球基础设施提供商，我们希望让客户放心：使用 Cloudflare 可以确保他们的流量能够抵御量子对手的威胁，实现面向未来的安全保障。

但是，在一个像我们这样规模和体量的组织中，如何完成如此大规模的迁移呢？毕竟，密码学是全球几乎所有数字系统的基础层，包括支持我们平台的软件服务和网络协议。

为了推动我们的 PQ 迁移，我们设定了三个关键目标。

首先，我们希望帮助我们的产品和工程团队了解密码学的使用方式以及应如何进行升级。这应涵盖后量子加密和后量子身份验证的升级。我们的许多产品已经升级到基于 TLS 1.3 的后量子加密，但我们仍需覆盖长尾的 TLS 连接，并升级其他所有公钥加密的使用场景。与此同时，我们部署后量子身份验证的工作仍处于早期阶段。

其次，我们希望为迁移提供进度指标。这些指标可能包括每个代码库和每个产品中经典密码学和后量子密码学的使用计数。

最后，我们希望尽早发现先决条件。如果我们的产品或平台依赖于尚无 PQ 迁移计划的协议（因为尚未考虑系统的 PQ 变体，因为 PQ 标准尚不存在或缺乏共识，或者因为软件库或其他关键生态系统组件尚未提供 PQ 支持），那么我们需要现在就了解情况。这样我们就可以与相关利益相关者、标准机构和生态系统合作，推动他们的 PQ 迁移计划，从而确保我们能够实现 2029 年的 PQ 迁移时间表。

这篇文章讲述了我们如何开展这项工作。我们解释了如何利用 AI 来帮助解决部分问题，以及我们如何开发名为 CryptoLabe 的内部工具来提供支持。CryptoLabe 以航海星盘命名，这是一种由葡萄牙航海家改进的导航仪器。正如星盘帮助水手确定位置并规划航线一样，CryptoLabe 帮助我们在代码中发现密码学应用，了解其使用方式，并规划后量子迁移路径。

CryptoLabe 是针对我们内部系统（代码库、工单系统和内部文档流程）高度定制的，并且随着我们的持续开发而不断演进，因此我们不会将其提供给客户。尽管如此，我们还是分享了我们的经验，以便其他组织在进行各自的 PQ 迁移之旅时，能够借鉴我们的成果。

问题的规模

驱动大多数 Cloudflare 产品的软件位于我们单一的集中式源代码管理平台中。这意味着我们只需查看代码库，就能找到我们平台中绝大多数的加密技术使用情况。

虽然代码库的集中化对我们来说是一个显著优势，但我们仍需应对随这一问题的规模而带来的三大挑战。首先，我们的代码分布在许多存储库中。其次，加密技术在代码中很少会直接显露出来。相反，它隐藏在

• 存储库导入但可能并未实际调用的共享库中
• 上游和协议默认设置，例如配置为协商经典密钥交换（如 X25519）而非后量子 X25519MLKEM768 的 TLS 1.3 监听器
• 在远离使用代码的地方选择算法的配置文件，例如密钥交换协议固定在存储于不同存储库的 YAML 文件中的 TLS 响应程序
• 死代码、仅用于测试的代码或即将被弃用的代码路径

第三，加密技术发现不仅仅是模式匹配。通过 Grep 搜索某些算法名称（例如“RSA”或“X25519”）会产生重复计算，因为它会找到未使用的代码中的加密技术。Grep 搜索也会导致统计不足，因为它会遗漏默认设置以及依赖项和配置中的间接使用。最重要的是，它无法告诉你加密技术是如何被使用的。一个经典的 ECDSA 签名可能是 JWT、IPsec、TLS 或 SSH 的一部分，而每种情况都有完全不同的迁移路径。许多使用方式还取决于连接的另一端：TLS 服务器可能同时支持后量子密钥交换和经典密钥交换；它选择使用哪一种取决于客户端。

转向 AI

事实证明，AI 在执行超越简单 Grep 搜索的任务方面表现相当出色。模型可以搜索代码库、追踪跨文件的证据，并返回结构化分析。它还可以通过从其他来源（如我们的内部文档和工单系统）提取信息来丰富发现结果。事实上，AI 甚至可以解释加密技术是如何被使用的以及应该如何更新。在开发 CryptoLabe 的过程中，我们一直在测试这一想法。

正如我们之前所说，我们的前两个目标是 (1) 发现并了解代码库中密码学的使用情况，以及 (2) 获取关于我们 PQ 迁移状态的指标。为了实现这些目标，我们目前实现的 CryptoLabe 分两个阶段执行扫描，如下图所示。

第一个“发现”阶段从映射存储库开始。然后，它通过源代码、配置、清单、锁文件、脚本、测试和文档搜索加密技术。除其他事项外，该扫描还会查找密钥协商、签名、非对称加密、PKI、令牌、凭据、硬件安全模块集成等加密技术的使用情况。此发现阶段会生成一组“原始观察结果”。

每一项原始观测结果都会进入第二阶段的运行。这个“分析”阶段首先会根据源代码重新核查观测结果。随后，它会调查加密操作在运行时是如何被使用的、存储库扮演了什么角色，以及它依赖哪些内部或外部方。必要时，它可以检查其他存储库中的相关代码以完成分析。最后，它会审视自己的结论，搜索缺失或冲突的证据，例如配置覆盖、仅用于测试的代码，或对运行时行为的不正确假设。

接下来，模型会为发现的问题分配一个分类。如果证据不足以进行分类，模型会将其标记为 More evidence needed（需要更多证据）、External dependency（外部依赖）或 Unknown（未知），而不是进行猜测。

这是 CryptoLabe 目前使用的分类列表，其中包含了一些全能型分类器，随着我们迁移工作的推进，这些分类器可能会进一步细化。（例如，我们可以通过将“加密”分类器拆分为 密钥协商 和 HPKE 来细化我们的分类器；你明白这个意思就行。）

最后，它会生成一份报告，服务于两类受众：(1) 需要了解迁移对产品意味着什么的产品经理，以及 (2) 需要足够细节来执行迁移的工程师。

这是我们报告的一份（裁剪后的）视图：

虽然我们一直在根据源代码并与相关工程师进行迭代式审查，但我们目前还没有一个基准数据集，无法对我们为 CryptoLabe 尝试的不同提示词版本进行可重复的比较。

基于 Cloudflare 的开发者平台构建

我们基于 Cloudflare 的开发者平台构建了 CryptoLabe。以下是其架构：

CryptoLabe 运行在两个 Cloudflare Workers 上。其中一个扫描 Worker 负责执行扫描，另一个库存 Worker 则负责提供仪表板、公开 API，并将所有数据存储在 D1 数据库中。两者通过 Service Bindings 进行通信。当有人从仪表板发起请求时，扫描便会开始，库存 Worker 会将请求传递给扫描 Worker。

编排扫描

我们需要一种方法来保持扫描从始至终处于活跃并按计划进行，且无需构建我们自己的作业编排系统。我们通过 Agents SDK 实现了这一点。每个代码仓库都有一个基于 Durable Object (DO) 构建的持久化协调器。协调器前端的有限队列限制了同时运行的扫描数量。当轮到某个扫描时，协调器会跟踪其进度并处理取消、重试和恢复操作。

协调器本身并不执行分析。它将工作交给 Cloudflare Workflows，以便它们能够持久化进度并自动重试失败的步骤。协调器将每个代码仓库推进四个阶段：

1. 发现 Workflow（产生原始观测结果的第一个扫描阶段）
2. 深度分析 Workflow（第二个阶段，在每个原始观测结果上运行）
3. 合并 Workflow（为给定的代码仓库构建发现列表，包括合并重复或相似的发现）
4. 发布 workflow（将结果交还给库存 Worker）

前两个工作流需要模型能够访问代码仓库的代码。我们希望这种访问是隔离的，以免冒损坏代码库的风险。因此，CryptoLabe 会在每次扫描开始时，针对特定的提交（commit）下载一次代码仓库，然后将该快照存储在 R2 中。随后，每个 Workflow 会将快照恢复到一个全新的、生命周期短暂的 Cloudflare Sandbox（隔离容器）中。即使在扫描运行期间代码库发生了变化，模型也会通过一组只读工具，在不可变的代码快照上与 Sandbox 进行交互。

大规模调用模型

如果我们想要扫描我们所有的（许多！）代码仓库，就必须考虑成本和容量问题。

在成本方面，模型循环通过 AI Gateway 将请求发送到托管在 Workers AI 上的高性价比开放权重模型。将模型置于 AI Gateway 之后，当有更好或更便宜的模型可用时，也能轻松切换模型。

当我们同时扫描多个代码仓库时，容量成为了一个问题。突发的模型请求开始触发来自 AI Gateway 的 HTTP 429（速率限制）响应，而独立重试的扫描只会让突发情况变得更糟。我们通过一个单一的全局 Durable Object 解决了这个问题，它会对所有扫描（包括重试）中的每个模型请求进行限速。当任何扫描达到速率限制时，冷却时间是共享的，所有扫描会共同退避，因此并发扫描会共享可用容量，而不是相互竞争。

先决条件和困难案例

现在让我们进入第三个目标：尽早发现先决条件和困难案例。

关于 PQ 迁移的生态系统就绪性，人们已经讨论得非常多了，现在我们打算再多聊一点。众所周知，PQ 迁移不可能在真空中进行。为了迁移成功，相关的软件库（例如 BoringSSL）以及参与生态系统的各方（例如客户端、浏览器、源站、云代理、证书颁发机构等）必须支持后量子密码学。标准也是生态系统支持的重要指标，尽管处于“草案”阶段的标准并不一定意味着无法进行部署。例如，我们早在 2022 年就在 TLS 1.3 中部署了 X25519MLKEM768，当时它在互联网工程任务组（IETF）仍处于“草案”阶段，直到 2026 年才最终定稿为 RFC 10024。

无论如何，我们的观点是，为了将系统升级到 PQ 密码学，我们需要了解其依赖关系和生态系统的支持水平。

这就是为什么 CryptoLabe 使用“先决条件”的概念来突出那些无法由单个产品团队单独立即修复的问题。

先决条件可以非常直观，例如“我们目前在迁移到后量子 JWT 时受阻”。我们说这很直观，是因为后量子 JWT 已经有了标准（RFC 9964）。然而，如果我们的软件库尚不支持验证后量子 JWT，或者我们使用的令牌颁发者尚未颁发后量子 JWT，我们就无法在全公司范围内要求每个产品团队开始对其 JWT 进行 PQ 升级。在解决其核心先决条件之前，此迁移将处于受阻状态。CryptoLabe 允许我们将（可能）具有相同先决条件的发现结果归类在一起，这也有助于我们决定如何优先解决这些先决条件。

例如，下方的快照显示了 CryptoLabe 中以后量子 SAML 作为先决条件的六个发现结果。（SAML 是一种用于单点登录（SSO）的协议。）

另一方面，可能存在一些甚至缺乏基本生态系统支持的密码学应用。我们一直称这些为“困难案例”。为了找到它们，我们编写了一个单独的提示词，忽略“常规”的密码学应用（例如内部系统之间的普通 TLS），转而寻找自定义密码协议、密钥或在空间受限字段中使用的签名、内置于硬件中的密码学、专门的密码结构（如 盲签名）、没有 PQ 标准的协议，以及对尚未支持 PQ 密码学的外部方的依赖。

这个提示词比用于 CryptoLabe 的提示词更短、更简单，因为它的唯一任务就是寻找困难案例。在我们的定性审查中，我们发现当它一次性针对我们所有的代码库运行，同时结合我们内部工单和文档系统的上下文时，它能获得更好的结果。

以下是我们发现的一个“棘手案例”示例：在 HTTP 标头中传输的证书。后量子证书和签名比传统的同类产品更大，因此如果标头（或中间件，或处理标头的应用程序）预设了证书的大小，那么更改签名算法可能会导致系统崩溃。我们的下一步是确定这段代码是否会长期使用。如果会，我们需要测量相关的尺寸限制，并决定如何容纳更大的证书。

这里的一个重要教训是，没有单一的扫描方式能发现所有问题。我们逐个存储库的扫描对于发现常见的加密使用情况非常有效。与此同时，这种针对性扫描在处理“棘手案例”时效果更好，因为它忽略了已知的加密技术，并对每个产品及其依赖项拥有更多的上下文信息。

底线是，不同的方法会发现不同的问题，而且每一个发现的结果仍然需要由了解系统实际运作方式的工程师进行核查。

分享我们的提示词

在过去的几个月里，我们一直在摸索为 CryptoLabe 编写提示词的最佳方式。我们目前还没有用于比较不同提示词性能的基准数据集，也不确定我们是否 100% 覆盖了代码库中所有的加密使用场景。相反，我们通过运行扫描、与维护存储库的工程师一起审查发现结果、调查审查过程中出现的遗漏并修改提示词来进行迭代。尽管如此，我们还是决定发布 精选提示词，以便其他团队可以学习并调整我们的方法。这些提示词只是起点，而非 CryptoLabe 的独立版本，其结果质量将取决于所使用的模型、工具、上下文以及工程审查。

思考您自己的 PQ 迁移

在 Cloudflare，我们对 PQ 迁移采取了最大化方案，因为我们的目标是为客户和整个互联网提供后量子密码学服务。但大多数组织 并不需要 从查找其每个产品中每个存储库的每一次加密使用开始。事实上，大多数组织不应该这样做，因为在当前阶段，这是一种宝贵资源的浪费。

在扫描单个存储库之前，您可以尽可能批量保护流量。如果您的网站通过 Cloudflare 运行，我们 今天就已经 使用后量子加密技术保护您的传输数据；请通过我们的 新 PQ 可见性功能 查看详情。我们的 SASE 平台 Cloudflare One 为私有网络流量提供后量子加密。后量子加密 无需额外费用 提供，且无需您升级企业网络中的每个源服务器或私有应用程序。这为您在发现和了解自身系统内部加密使用情况的过程中提供了一种补偿性控制措施。

详尽的加密清单并不是采取行动的前提。相反，组织应首先确定那些一旦受损影响最大的系统，发现它们对加密的使用情况，然后按优先级对这些加密进行 PQ 升级。以下是一种开始的方法：

1. 为某个重要系统选择一个代码仓库。 从处理敏感或长期数据、验证用户或软件身份，或者暴露在公共互联网上的系统开始。
2. 针对该仓库运行密码学发现工具。 我们希望对 CryptoLabe 的介绍能为这项工作提供帮助！
3. 验证结果。 请系统所属团队验证密码学发现的结果，并确认该密码学发现是否需要长期保留以及是否需要升级至 PQ。请务必记住，如果存在其他补偿性控制措施，则不一定需要立即升级至 PQ。
4. 确定行动优先级。 弄清楚哪些升级可以立即进行，哪些升级目前受阻。记录下需要库、供应商、标准组织或组织内其他部门协助的共同先决条件。对发现的问题进行优先级排序，并制定计划，优先处理影响最大的系统和先决条件。

这为您提供了一个 PQ 过渡计划的开端，而无需对组织内的每一项密码学操作进行完整映射。CryptoLabe 仍在不断演进，但其扫描结果在我们规划迁移时极具启发性。我们希望这些分享的经验教训能在您继续进行 PQ 迁移的过程中有所帮助。

致谢：Cloudflare 的许多同事为 CryptoLabe 提供了反馈并做出了贡献，包括 Davide Marquês、Peter Wu、Phil Schmieder、JP Aumasson、Andrew Galloni、Christopher Patton、Luke Valenta、Mari Galicer、Vânia Gonçalves，以及审阅了该工具生成报告的 Client、Tunnel 和 Gateway 团队。