Cloudflare’s Post-Quantum GeoKey Manager Enters Closed Beta Without Attribute-Based Encryption
Cloudflare has moved a post quantum rebuild of GeoKey Manager into closed beta, guarding geo fenced keys with hybrid ML KEM 768 and X25519 instead of the attribute based encryption used since 2022. Keys live only in kernel memory on verified regional servers, and any failed check rejects the request, a fail closed…

Cloudflare has moved a post-quantum rebuild of GeoKey Manager into closed beta, protecting geographically fenced decryption keys with a hybrid of ML-KEM-768 and X25519 and replacing the attribute-based encryption the service has relied on since 2022. The beta opened on October 23 to existing Data Localization Suite customers, with general availability planned for the first quarter of 2027.
Chetan Agrawal, Arka Nayan and Erik Engstrom describe the redesign as addressing two requirements at once: data sovereignty rules that confine plaintext processing to a region, and harvest-now, decrypt-later attacks in which traffic captured today is decrypted once a quantum computer exists. GeoKey Manager first shipped in 2017 for TLS keys and moved to ciphertext-policy attribute-based encryption in 2022. Cloudflare gives two reasons for dropping that scheme: no production-ready post-quantum variant exists, and customers don't need the large number of regions it was built to express.
In its place, key protection uses HPKE, the hybrid public-key encryption construction defined in RFC 9180, with a key encapsulation mechanism (KEM) combining ML-KEM-768 and X25519, HKDF-SHA-256 and AES-256-GCM. Two kinds of keys replace the policy expressions. Regional root keys are 256-bit symmetric secrets held one per region. Application-specific key pairs are derived from a root for a single service, such as Tunnel or Gateway, and a single epoch, Cloudflare's term for a key generation that rotation advances. The key-management service derives the application key pair and wraps customer private keys under its public component.

(Source: Cloudflare blog)
The two kinds of keys travel different paths: Quicksilver, Cloudflare's globally replicated key-value store, carries wrapped keys and metadata everywhere, while regional root keys move a separate path through the provisioning service, which stores them in Vault. Before an edge server receives a root key, it must clear three checks: TPM hardware identity verification, a lookup in Zinc, Cloudflare's server inventory, that maps the identity to a data center and location, and a decision by the provisioning service about which roots that server may hold.
Authorized servers then load regional root keys into the kernel keyring rather than onto disk. Because that memory is volatile, "a machine restart removes the keys," and the server has to authenticate again. Regional membership refreshes several times a day as the network changes, separately from key rotation and without customer action.

(Source: Cloudflare blog)
Dabeer Shaikh, a senior solutions engineer at HashiCorp, asked under Cloudflare's announcement how a geo-fenced key can be rotated without downtime, and the post answers that question through its epoch model. A soft rotation creates a new epoch while a limited number of previous epochs stay usable, so customers keep uptime during the transition; a hard rotation rewraps affected keys under a replacement epoch and removes access to the previous one.
Mark Tehrani, founder of CyberSeQ and a professor of cybersecurity, posted five questions on the same thread. Four concern the blast radius of a compromised regional root key, whether a compromised Zinc inventory or provisioning service could hand regional keys to an out-of-region server, what protects keys exposed before a rotation, and whether a compromised control plane could alter regional membership. The fifth goes to the design's central tradeoff:
If regional key provisioning, synchronization, or rotation fails, could the fail-closed design cause a region-wide service outage?
Cloudflare's post is explicit about that behavior. Any failed check on service context, region, or epoch rejects the request, and at the edge a missing or malformed key means the service does not start. The authors call failing closed "a very intentional design choice." The trust boundary covers the key-management, provisioning, and authorized edge key services; Quicksilver sits outside it because it only ever holds wrapped keys and metadata.
The rebuild extends a pattern in Cloudflare's post-quantum work. As previously reported on InfoQ, Cloudflare adopted hybrid ML-KEM for its IPsec service in March, when over 60% of human-generated TLS traffic on its network already used it, and the company has since set out plans for a quantum-safe certificate authority. Most regions will be covered at launch, with product-specific caveats. What the beta will show is whether the design's answer to a failed check, refusing to serve, is one customers accept at regional scale.
منتشرشده در
InfoQ
ادامه مطالعه





