Skip to content

CLOUDFLARE 2026-10-23 Tier 1

Read original ↗

Cloudflare: Post-quantum cryptography for geographically fenced key management

Summary

Cloudflare launched (closed beta, GA targeted Q1 2027) a post-quantum GeoKey Manager for its Data Localization Suite (DLS): a system that guarantees a customer's decryption keys can only be unwrapped by Cloudflare edge servers physically located inside the customer's chosen geography. It wraps each customer private key so that unwrapping requires a regional root key that never leaves its region. The design simultaneously solves two problems — data sovereignty (keys usable only in-region) and the post-quantum transition (resisting harvest-now-decrypt-later on long-lived key material) — by combining hybrid ML-KEM-768 + X25519 HPKE key wrapping with a geographically-scoped symmetric key hierarchy, strict fail-closed enforcement, and TPM-attested edge-server provisioning. It is the third iteration of GeoKey Manager (geo-restricted TLS keys 2017 → ciphertext-policy ABE 2022 → PQ symmetric-root design 2026).

Key takeaways

  • GeoKey Manager controls where a key can be unwrapped, nothing else. It deliberately does not control where tunnels terminate, where traffic is inspected, or where requests are routed — those are Regional Services. But every one of those depends on GeoKey Manager, because TLS traffic can only be decrypted where the private key is available. (Source: body, "Global ciphertext, regional key unwrapping")
  • Two-level key hierarchy: a symmetric regional root key → derived asymmetric application-specific key pair. A regional root key is a 256-bit symmetric secret tied to one region. From it, the key-management service derives a per-service HPKE key pair; its public half wraps the customer private key, its private half (reachable only via the root key) unwraps it. Keys sharing the same (service context, regional boundary, epoch) reuse the same application key pair. (Source: body, "Defining key hierarchy" / "Symmetric roots with asymmetric key wrapping")
  • Hybrid post-quantum wrapping: ML-KEM-768 + X25519, HKDF-SHA-256, AES-256-GCM. The Cloudflare One path uses HPKE (RFC 9180) whose KEM combines PQ ML-KEM-768 (NIST FIPS 203) with classical X25519; confidentiality holds as long as at least one component stays unbroken. Cloudflare chose this over a post-quantum attribute-based-encryption scheme because no production-ready PQ ABE exists and customers need only a handful of regions — a simpler design is easier to operate. (Source: body, "The evolution of GeoKey Manager" / "HPKE with hybrid post-quantum KEM")
  • Two distribution planes, one trust boundary. Wrapped private keys + metadata ride Quicksilver (Cloudflare's global KV config-distribution system) to every POP. Regional root keys do not — a separate provisioning service (backed by on-prem HashiCorp Vault) delivers them only to authorized edge servers. Quicksilver is explicitly outside the trust boundary because it only ever sees wrapped keys, never roots. (Source: body, "How GeoKey Manager ensures" / "Security and availability tradeoffs")
  • Edge-server authorization gated on three inputs: TPM + Zinc + provisioning policy. Before an edge server receives a regional root key, the provisioning service checks (1) a Trusted Platform Module proves a registered hardware identity (remote attestation), (2) Zinc (Cloudflare's server-inventory system) maps that identity to a datacenter and location, (3) policy says which roots that location may access. It then issues a scoped token the server uses to fetch only its authorized roots. (Source: body, "Authorizing edge servers for a region")
  • Roots live in the Linux kernel keyring, never on disk. Authorized edge servers load regional root keys into the kernel keyring (volatile memory), not persistent storage. A reboot wipes them and forces re-attestation and re-provisioning — trading operational complexity for a smaller persistent-key attack surface. (Source: body, "Authorizing edge servers for a region")
  • Fail-closed is the explicit, load-bearing default. If a configured root key is missing/malformed at startup, the edge key service does not start. After startup, any request whose metadata names a locally-unavailable regional root key is rejected — a German key cannot be unwrapped in Spain or France because neither holds Germany's root. Failing open (unwrapping out-of-region) is never done. (Source: body, "Security and availability tradeoffs")
  • Membership is dynamic; two rotation modes exist. Which datacenters make up "Germany" is not static — Zinc updates it several times a day as the fleet changes, propagated via Quicksilver, with no customer action. Separately, key rotation comes in two flavors: soft rotation (new epoch; a bounded number of previous epochs stay usable, like a credit card's grace period for recurring charges) and hard rotation (rewrap affected keys under a replacement epoch so the old epoch's access can be fully revoked). (Source: body, "Designing for rotation" / "Operating GeoKey Manager")

Systems / concepts / patterns extracted

Systems - GeoKey Manager — primary subject. New dedicated page: systems/geokey-manager. - Data Localization Suite — the product line GeoKey Manager underpins; GeoKey Manager is now named its cornerstone for key-unwrap-location control. - Quicksilver — distributes wrapped private keys + metadata globally; explicitly outside the key trust boundary. - ML-KEM-768 — the PQ KEM half of the HPKE hybrid. - Cloudflare One, Gateway, Tunnel, Access — the "service contexts" each wrapped key is scoped to. - Zinc (server-inventory / fleet-membership system) and HashiCorp Vault (on-prem backing store for the provisioning service) — named supporting systems, not the article's subject; listed in frontmatter, no page minted.

Concepts — post-quantum-cryptography, harvest-now-decrypt-later, envelope-encryption (symmetric-root → derived-key-pair → wrapped-customer-key hierarchy), key-rotation (soft/hard, epoch-based), fail-open-vs-fail-closed (fail-closed as the invariant), digital-sovereignty, data-residency, geographic-sharding (region as the partition dimension for key access), remote-attestation (TPM-backed hardware identity), defense-in-depth (hybrid PQ+classical; multiple gates), end-to-end-encryption.

Patterns — algorithm negotiation-adjacent hybrid-KEM composition; GeoKey Manager fits Cloudflare's recurring default-on PQ migration posture (customer picks a region, Cloudflare manages the crypto).

Operational numbers / specifics

  • Regional root key: 256-bit symmetric secret.
  • HPKE suite (Cloudflare One path): KEM = ML-KEM-768 + X25519, KDF = HKDF-SHA-256, AEAD = AES-256-GCM (RFC 9180).
  • Key metadata triple: (service context, regional boundary, epoch).
  • Provisioning authorization inputs: TPM identity + Zinc location mapping + provisioning policy → scoped fetch token.
  • Root-key storage: Linux kernel keyring, volatile; wiped on reboot.
  • Fleet-membership refresh: several times per day (Zinc → Quicksilver).
  • Launch status: closed beta (Oct 2026); GA targeted Q1 2027.
  • Blast-radius reasoning (stated): compromising the Tunnel-Germany application key exposes every customer's Tunnel-Germany key for that epoch but not their Gateway keys; compromising the Germany regional root key exposes every application key derived from it for that epoch.

Caveats

  • Closed beta, not GA — the design is "validated" but the production envelope (latency overhead of per-request root-key checks, throughput, real rotation drills) is not quantified in the post.
  • ABE was abandoned, not failed — Cloudflare dropped the 2022 ciphertext-policy ABE design because no PQ ABE scheme is production-ready, and because customers don't need many regions. The new design is simpler but less expressive (fixed regional boundaries vs. attribute expressions like "EU" or "CA+US+MX"). This is a deliberate expressiveness-for-operability trade.
  • CDN path not yet migrated — older GeoKey Manager already geo-fences CDN certificate keys; bringing this PQ design to the CDN path is separate, in-progress work with no date.
  • Trust boundary is broad — key-management service, provisioning service, and every authorized edge key service can all touch regional root keys. The security story rests on keeping that set correct (TPM + Zinc + policy) and on volatile storage, not on roots being held by only one component.

Source

Last updated · 854 distilled / 2,448 read