InfoQ

Cloudflare’s Post-Quantum GeoKey Manager Enters Closed Beta Without Attribute-Based Encryption

8.5内容质量
Cloudflare’s Post-Quantum GeoKey Manager Enters Closed Beta Without Attribute-Based Encryption

TL;DR · AI 摘要

Cloudflare推出基于ML-KEM-768和X25519的后量子GeoKey Manager封闭测试版，替代原有基于属性的加密方案。

核心要点

  • 采用ML-KEM-768与X25519混合加密方案应对量子计算威胁
  • HPKE协议结合RFC 9180标准实现密钥封装机制
  • 区域根密钥通过TPM验证和Zinc服务器库存校验确保安全

结构提纲

按章节快速跳转。

  1. §产品发布

    Cloudflare宣布GeoKey Manager后量子版本进入封闭测试阶段。

  2. ·技术架构

    采用ML-KEM-768与X25519混合加密方案替代原有ABE机制。

  3. ›设计需求

    需同时满足数据主权规则和量子解密攻击防护需求。

  4. ·密钥管理

    通过HPKE协议实现区域根密钥与应用密钥的分层保护。

  5. ›安全验证

    TPM硬件验证、Zinc库存校验和Provisioning服务联合控制密钥分发。

  6. ·未来规划

    2027年第一季度计划向所有客户开放该方案。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • Cloudflare GeoKey Manager
    • 后量子加密方案
      • ML-KEM-768
      • X25519
    • 密钥管理机制
      • HPKE协议
      • 区域根密钥
      • 应用密钥对
    • 安全验证流程
      • TPM硬件验证
      • Zinc库存校验
      • Provisioning服务控制

金句 / Highlights

值得收藏与分享的关键句。

#Cloudflare#后量子加密#GeoKey Manager#HPKE
打开原文

Cloudflare的后量子GeoKey Manager进入封闭测试版 未采用基于属性的加密 - InfoQ

InfoQ 主页 News Cloudflare的后量子GeoKey Manager进入封闭测试版 未采用基于属性的加密

开发

扩展OpenTelemetry：管理收集器、配置和成本（11月19日网络研讨会）

Cloudflare的后量子GeoKey Manager进入封闭测试版 未采用基于属性的加密

2026年10月31日 3分钟阅读

作者

  • Steef-Jan Wiggers

#### 关注我们

YouTube

232K关注者

LinkedIn

26K关注者

Instagram

新

RSS

19K读者

X

57.1k关注者

Facebook

21K点赞

Bluesky

收听本文 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

Cloudflare已将GeoKey Manager的后量子重构版本移入封闭测试版，通过结合ML-KEM-768和X25519的混合方案保护地理围栏解密密钥，并用混合公钥加密方案（HPKE）取代自2022年以来服务依赖的基于属性的加密。该测试版于10月23日向现有数据本地化套件客户开放，计划于2027年第一季度正式发布。

Chetan Agrawal、Arka Nayan和Erik Engstrom将此次重构描述为同时满足两项需求：将明文处理限制在特定区域的数据主权规则，以及"现在捕获、未来解密"攻击（即当前捕获的流量在量子计算机出现后才被解密）。GeoKey Manager最初于2017年用于TLS密钥，2022年转向密文策略基于属性的加密。Cloudflare给出弃用该方案的两个原因：目前尚无可用的后量子变体方案，且客户无需该方案支持的大量区域表达能力。

取而代之的是，密钥保护采用RFC 9180定义的HPKE混合公钥加密方案，包含结合ML-KEM-768和X25519的密钥封装机制（KEM）、HKDF-SHA-256和AES-256-GCM。两种类型的密钥取代了策略表达式：区域根密钥是每个区域单独持有的256位对称密钥；应用专用密钥对则从单个服务（如Tunnel或Gateway）和单个epoch（Cloudflare对密钥生成轮换周期的称谓）的根密钥派生。密钥管理服务会生成应用密钥对，并用其公钥部分封装客户私钥。

（来源：Cloudflare博客）

两种类型的密钥采用不同路径传输：Quicksilver（Cloudflare的全球复制键值存储）在各处传输封装密钥和元数据，而区域根密钥则通过单独路径经由配置服务传输至Vault存储。在边缘服务器接收到根密钥前，必须通过三项检查：TPM硬件身份验证、Zinc（Cloudflare服务器清单）中将身份映射到数据中心和位置的查询，以及配置服务关于该服务器可持有哪些根密钥的决策。

授权服务器随后将区域根密钥加载到内核密钥环而非磁盘中。由于该内存是易失性存储，"机器重启会清除密钥"，服务器需要重新认证。随着网络变化，区域成员资格每天刷新数次，与密钥轮换独立进行且无需客户操作。

Dabeer Shaikh，HashiCorp 的高级解决方案工程师，在 Cloudflare 宣布其方案时提出了一个关于如何在不中断服务的情况下轮换地理围栏密钥的问题。该文章通过其纪元模型回答了这个问题。软轮换会创建一个新的纪元，同时允许一定数量的旧纪元继续使用，从而确保过渡期间服务的持续可用性；硬轮换则会在替换后的纪元下重新封装受影响的密钥，并移除对旧纪元的访问权限。

Mark Tehrani，CyberSeQ 创始人兼网络安全教授，在同一条推文中提出了五个问题。其中四个问题涉及被入侵的区域根密钥的爆炸半径、被入侵的 Zinc 库存或供应服务是否可能将区域密钥交给区域外的服务器、轮换前暴露的密钥如何保护，以及被入侵的控制平面是否能修改区域成员资格。第五个问题涉及该设计的核心权衡：

如果区域密钥的供应、同步或轮换失败，失败时关闭的设计是否会导致整个区域的服务中断？

Cloudflare 的文章明确说明了这种行为。任何对服务上下文、区域或纪元的检查失败都会拒绝请求，而在边缘节点，缺失或格式错误的密钥会导致服务无法启动。作者将这种失败时关闭的设计称为“一个非常明确的设计选择”。信任边界涵盖密钥管理、供应和授权边缘密钥服务；Quicksilver 则位于信任边界之外，因为它只存储封装后的密钥和元数据。

此次重构延续了 Cloudflare 在抗量子计算工作中的模式。如 InfoQ 之前报道的，Cloudflare 在 3 月将其 IPsec 服务升级为混合 ML-KEM 方案时，其网络上已有超过 60% 的人工生成 TLS 流量使用该方案，此后公司也制定了量子安全证书颁发机构的实施计划。大多数区域将在发布时覆盖，但会有产品特定的注意事项。该测试版将展示的是，当设计在检查失败时选择拒绝服务，这种做法是否能被客户在区域级规模接受。

关于作者

作者信息

#### Steef-Jan Wiggers

显示更多

显示更少

#### 本内容属于加密技术主题

##### 相关主题：

  • 开发
  • 架构与设计
  • DevOps
  • Cloudflare
  • 量子计算
  • 安全
  • 加密
  • 云计算
  • 相关编辑内容
  • 相关赞助商 [智能代理 AI 威胁：为什么你的 Java 补丁策略已不再足够]
  • 相关赞助商 了解 Azul 如何帮助 Java 团队降低 JVM 漏洞风险，加强应用安全性，并为智能代理 AI 做好 Java 环境准备。发现如何在保持性能和可靠性的同时，为 Java 工作负载制定安全策略。了解更多。

InfoQ 新闻通讯

每周五发送 InfoQ 最新内容摘要。加入超过 250,000 名高级开发者的社区。查看示例

我们保护您的隐私。