Bringing post-quantum cryptography to geographically fenced key management

将抗量子密码学引入地理围栏密钥管理 | Cloudflare 博客

post

抗量子

零信任

Cloudflare One

数据本地化套件

地理密钥管理器

2026年10月23日

将抗量子密码学引入地理围栏密钥管理

Chetan Agrawal , Arka Nayan , 和 Erik Engstrom

13分钟阅读

复制链接

今天，Cloudflare 正式推出基于数据本地化套件（DLS）的封闭测试版的抗量子地理限制密钥管理器。这项新的 PQ GeoKey Manager 是 Cloudflare 数据主权解决方案的核心组成部分，确保客户的解密密钥仅在其选定的地理区域可访问。GeoKey Manager 通过将每个解密密钥包装为仅能被位于允许地理区域的 Cloudflare 服务器解密来实现这一目标。

尽管通用可用性（GA）计划于 2027 年第一季度推出，但今天的发布是我们支持客户数据主权目标并同时将所有 Cloudflare 产品迁移至抗量子（PQ）密码学的重要里程碑。

政府、金融机构、医疗保健提供者和国防组织处理高度敏感的数据，这些数据在生成后可能在数年甚至数十年内仍保持敏感。保护这些数据通常需要加密。当使用经典公钥加密时，对手今天不需要立即拥有量子计算机来危及这些数据：他们可以存储密文并保留到量子计算机能够破解保护它的公钥密码学时再进行解密——这种攻击策略被称为“现在收集，以后解密”。

对于具有地理要求的组织而言，抵御这种威胁只是挑战的一半。在 Cloudflare 的规模下，高可用性需要将客户数据复制到全球网络中的许多服务器上。然而，许多数据主权法规要求某些类型的数据只能在特定地理区域内处理。因此，我们必须确保数据端到端加密，仅允许该区域内的服务器访问明文。在本文中，我们将描述实现这一目标的系统。

GeoKey Manager 的演进

Cloudflare 于 2017 年通过 GeoKey Manager 首创了地理限制传输层安全（TLS）密钥的概念。这使客户能够控制其私有 TLS 密钥在 Cloudflare 的任播网络上解包的位置，从而提供更强的技术保证，确保请求被解密到特定区域。例如，客户可以选择仅在印度解包其私钥。因此，GeoKey Manager 确保每个客户的请求的 TLS 签名仅在我们的印度网络中进行，而不是允许整个全球网络进行解密。

2022 年，GeoKey Manager 再次演进，引入了基于属性的加密（ABE）密文策略。与将加密密钥绑定到固定数据中心集不同，ABE 使用诸如国家或地区等属性来表达地理要求，例如“region = 欧洲联盟”或“region = 加拿大 + 美国 + 墨西哥”。新授权的服务器可以接收匹配的解密能力，而无需重新包装每个客户的密钥。

这种灵活性为后量子过渡带来了挑战和机遇。目前尚无可用于生产的后量子ABE方案，且客户并不需要大量区域。更简单的设计既能满足需求，也更容易维护和操作。因此，Cloudflare采用混合ML-KEM-768和X25519保护方案，使用两种密钥。其中ML-KEM-768是NIST标准，同时也为高敏感客户打开了大门。区域根密钥是对称密钥，与特定区域绑定，然后从中派生出特定于应用的密钥对，用于单个服务（如Gateway或Tunnel）。这可以在不破坏区域密钥使用边界的情况下，防止私钥材料被提前获取并稍后解密。

全球密文，区域密钥解封

在新形态中，GeoKey Manager是Cloudflare数据主权解决方案的关键基础。它控制受保护的解密密钥可从哪些区域使用以及何时使用。独立的工作流确定隧道终止位置、流量检查位置、路由方式以及明文处理位置。但所有这些都依赖于客户私钥可被解封的区域，因为TLS流量只能在该密钥可用的区域进行解密。

初始化期间，边缘密钥服务（Cloudflare每个边缘服务器上用于解封客户私钥并使用它们处理请求的组件）会验证其配置所需的每个区域根密钥是否已加载。如果配置的密钥缺失或格式错误，该服务将无法启动。初始化完成后，如果请求的元数据标识的区域根密钥在本地不可用，单个请求也会失败（Cloudflare会拒绝请求，而不是冒险在错误区域解封密钥）。如果某个针对德国的请求试图在西班牙或法国解密，将失败，因为西班牙和法国都没有德国的区域根密钥。这保证了区域根密钥永远不会离开其所在区域，无论发生什么情况。

Cloudflare需要在保持客户区域化数据大规模安全的同时维持高性能。这就是下一代GeoKey Manager的作用所在。我们通过使用后量子密码学来限制客户私钥的解封位置，从而在逻辑上隔离网络，同时实现快速性能。大多数区域将向客户开放用于工作流区域化，但可能存在特定产品的限制。客户选择区域后，Cloudflare将负责管理所有其他必要操作，以确保私钥在区域边界内解封。

GeoKey Manager如何确保密钥仅在特定区域可用

GeoKey Manager控制加密的私钥在数据平面可被解封和使用的区域。它不控制请求的转发或路由位置（由区域服务负责），也不控制隧道终止位置或流量检查位置（同样由区域服务负责）。

GeoKey Manager 将全局分布的封装私钥与解封装所需区域根密钥分离开。我们的全球配置分发系统 Quicksilver 负责将封装私钥及其元数据分发到网络中的各个节点。该系统不会分发区域根密钥，区域根密钥的分发通过独立的预配服务完成，该服务存储区域根密钥并仅将其交付给每个区域授权的边缘服务器。区域根密钥遵循独立且受控的分发路径。在数据平面，节点所属区域的配置决定了哪些节点可以接收哪些区域根密钥。

定义密钥层次结构和应用专用密钥

每个封装的客户私钥都携带元数据，用于标识其服务上下文、区域边界和纪元。

服务上下文是指使用该密钥的 Cloudflare 服务，例如 Tunnel 或 Gateway。区域边界是指密钥可以被解封装和使用的批准 Cloudflare 数据中心集合，例如德国或欧盟的数据中心。纪元标识该密钥所属的区域根密钥代际；每次轮换都会生成新的纪元。

例如，Acme 公司可能在德国拥有一个 Tunnel 专用密钥（acme0001）和一个 Gateway 专用密钥（acme0002）。Road Runner 公司可能在德国拥有一个 Tunnel 专用密钥（runner0001）和一个欧盟范围的 Gateway 专用密钥（runner0002）。

具有相同服务上下文、区域边界和纪元的密钥会使用相同的专用应用密钥对。因此，如果 Tunnel-德国专用私钥被泄露，可能会暴露 acme0001 和 runner0001，但不会影响 Gateway 密钥。如果德国区域根密钥被泄露，可能会影响同一纪元下所有从该根密钥派生的应用专用密钥，包括 acme0001、acme0002 和 runner0001。

在当前架构中，应用专用密钥对是非对称的。公钥部分用于封装客户私钥材料，而私钥部分则用于解封装。生成的封装私钥会与其服务上下文（Access、Gateway、Tunnel、Cloudflare One 客户端）、区域和纪元一起分发。

区域根密钥的预配流程

区域根密钥的创建和预配流程

当 Cloudflare/Admin 为 CF1 用例配置一个区域时，密钥管理服务（同时也负责派生应用专用密钥对和封装客户私钥）会创建一个区域根密钥，并将其与区域边界和纪元关联，然后发送给预配服务进行存储和分发。预配服务在底层使用由我们本地管理的 Vault 进行操作。

为区域授权边缘服务器

区域根密钥分发流程

在边缘服务器能够接收区域根密钥之前，预配服务会评估三个输入：

• 可信平台模块（TPM）证明服务器拥有已注册的硬件身份
• Zinc（Cloudflare 的服务器库存系统）将该身份映射到数据中心和地理位置
• 预配服务确定服务器可以访问哪些区域根密钥

Zinc 会为每个边缘服务器更新其成员记录。这个异步过程会在网络扩展时添加新服务器，并在服务器退役时将其移除。当 Cloudflare 对德国数据中心进行维护时，Zinc 中定义哪些数据中心属于德国的规则会发生变化。该规则会通过 Quicksilver 快速传播到我们的网络中，以确保我们的边缘节点保持最新。反过来也是如此。当我们向网络中添加容量时，德国或其他任何地区的定义会在 Zinc 中更新，并通过 Quicksilver 快速传播到整个网络中。

Zinc 还会将注册的硬件身份与服务器及物理位置相关联，这支持 FIPS 140-3 合规性。基于 TPM 的身份、服务器库存数据和区域配置决定了边缘服务器所属的区域及其可访问的区域根密钥。

每个边缘服务器都会调用控制平面的配置服务，并提供其注册的硬件身份。配置服务在验证服务器的硬件身份和区域成员身份后，会颁发一个令牌，允许服务器仅检索为其位置授权的区域根密钥。每个边缘服务器获取令牌后，使用该令牌获取区域根密钥。

获得授权的边缘服务器会将区域根密钥加载到内核密钥环中，而不是将其持久化存储在磁盘上。进程级访问控制限制了哪些服务可以使用这些密钥。由于这种内存是易失性的，机器重启后密钥会被清除，服务器必须重新进行身份验证并重新配置密钥。这增加了操作复杂性，但减少了可能成为攻击者目标的持久密钥材料。

为全球分发封装私钥

当密钥管理服务接收到带有服务上下文和区域边界的客户私钥材料时，它会使用请求中的区域边界获取区域根密钥及其最新的配置纪元。然后，它会派生出相应的非对称应用密钥对，并使用其公钥部分对私钥进行封装。结果是一个封装后的私钥及其元数据。

随后，Quicksilver 会将封装后的私钥和元数据分发到我们的网络中。由于封装后的密钥需要指定区域才能解密，因此全球封装密钥的分发不会授予边缘服务器对私钥的全局访问权限，因为解封装仍然需要相应的区域根密钥和服务上下文。

客户私钥封装流程

在数据平面使用特定于应用的密钥进行解封装

客户私钥解封装流程

为什么选择这种密码设计

对称根密钥与非对称密钥封装

区域根密钥是 256 位对称密钥。GeoKey Manager 会从每个区域根密钥派生出特定于应用的密钥。对于当前的 Cloudflare One 路径，控制平面的密钥管理服务会派生出特定于应用的混合公钥加密（HPKE）密钥对。

混合后量子 KEM 的 HPKE

Cloudflare One 路径使用 RFC 9180 中定义的 HPKE。其密钥封装机制（KEM）结合了 ML-KEM-768 与 X25519，而 HKDF-SHA-256 提供密钥派生，AES-256-GCM 提供认证加密。结合后量子和经典组件可确保只要至少一个组件保持安全，就能保持机密性。

为轮换设计

经过验证的设计支持两种密钥轮换类型：软轮换和硬轮换。

软轮换会为区域根密钥创建新的纪元，同时保留对有限数量先前区域根密钥纪元的受控访问权限——例如，可以保留一个先前版本。客户的新私钥材料会使用最新的纪元进行封装，而旧的封装私钥在过渡期间仍可继续使用。这个概念类似于信用卡公司允许您在授权零售商处使用旧版信用卡进行定期支付。在这种情况下，我们支持的纪元数量决定了多少代先前封装的私钥（信用卡）可以继续使用。这使客户能够在过渡期间保持服务的正常运行时间。

硬轮换则会将受影响客户的封装私钥重新封装到替代纪元下，从而可以移除对先前纪元的访问权限。在这种情况下，就相当于信用卡公司完全禁止您在任何情况下使用旧版信用卡进行交易。

安全性与可用性权衡

默认拒绝是经过深思熟虑的设计选择。默认允许意味着在客户允许的区域之外解封装其私钥，而不是拒绝请求。我们从不这样做：如果任何必要检查失败（服务上下文、区域、纪元等），请求将被直接拒绝。启动时，每个边缘节点的密钥服务会从Linux内核密钥环中加载所有配置的区域根密钥。缺失或格式错误的根密钥会阻止边缘密钥服务初始化。运行后，边缘密钥服务使用内存副本，防止被篡改，从而避免跨区域或区域外的解封装。实际上，边缘服务器只有在其配置和密钥分配完成后，才会处理该区域的请求。

信任边界（所有可以访问区域根密钥的服务）包括密钥管理服务、配置服务和授权的边缘密钥服务，因为这些服务都可以访问区域根密钥。密钥管理服务使用它们派生特定于应用的密钥，配置服务存储并分发这些密钥，而边缘密钥服务使用本地授权的副本。Quicksilver位于此边界之外，因为它仅接收封装的私钥和相关元数据。

GeoKey Manager操作

Cloudflare的网络在持续变化。随着服务器加入或退出服务，Cloudflare的舰队清单会更新区域成员资格。这意味着组成西班牙等区域的数据中心列表并非静态。GeoKey Manager的配置层每天多次刷新该成员资格，根据网络变化授予或移除对区域根密钥的访问权限。此过程与密钥轮换独立，无需客户操作。

当区域成员资格发生变化时，配置服务会立即同步服务器的Linux内核密钥环与最新的授权区域根密钥。边缘密钥服务会在进程内存中缓存这些密钥，直到重启或缓存过期。之后，它会从内核密钥环重新加载当前授权的密钥集合。

下一步：Cloudflare One集成和CDN

GeoKey Manager是Cloudflare One改进版区域服务的基础；这些新功能将在几个月后公布。

GeoKey Manager的旧版本已经为与CDN证书关联的私钥提供了地理控制功能。我们正在开发一个独立的集成方案，将本文描述的新型后量子GeoKey Manager引入现有CDN能力。当相关工作就绪时，我们将分享测试和过渡细节。

入门

如果您是当前使用DLS且正在对CDN流量进行区域化管理的客户，可以在该功能对CDN流量普遍可用之前，通过此处注册测试该功能的意向。

感谢所有使这款产品成为现实的团队成员。这需要数据本地化套件、Cloudflare One和Cloudflare Research团队的巨大努力。

目录列

讨论列

相关标签及社交媒体链接

相关标签

在社交媒体上关注

• Cloudflare

电子邮件订阅