Cloudflare's Post-Quantum GeoKey Manager Architecture
Cloudflare's redesigned GeoKey Manager addresses data sovereignty and post-quantum security challenges by employing a hybrid key encapsulation mechanism (ML-KEM-768 and X25519) and a regional root key architecture. The system emphasizes a 'fail-closed' design for critical security checks and introduces an epoch-based key rotation model to ensure high availability during transitions. This architectural shift from attribute-based encryption highlights trade-offs between flexibility, performance, and post-quantum readiness.
Read original on InfoQ CloudOverview of GeoKey Manager Redesign
Cloudflare's GeoKey Manager underwent a significant redesign to concurrently address two critical requirements: data sovereignty rules, which mandate plaintext processing within specific geographic regions, and protection against harvest-now, decrypt-later attacks enabled by future quantum computers. The previous attribute-based encryption (ABE) scheme was replaced due to the lack of production-ready post-quantum variants and reduced customer need for its complexity.
Key Management Architecture
The new architecture leverages Hybrid Public-Key Encryption (HPKE), specifically RFC 9180, combining ML-KEM-768 and X25519 for key encapsulation. It introduces two primary key types:
- Regional Root Keys: 256-bit symmetric secrets, one per region, stored in Vault and provisioned via a separate secure path.
- Application-Specific Key Pairs: Derived from a regional root key for a single service (e.g., Tunnel, Gateway) and a specific "epoch" (key generation). These are wrapped by the key-management service under its public component.
Wrapped customer private keys and metadata are stored globally in Quicksilver, Cloudflare's replicated key-value store, which sits outside the core trust boundary as it never holds plaintext keys. Regional root keys, however, follow a highly secure provisioning path, undergoing TPM hardware identity verification, server inventory lookup (Zinc), and provisioning service authorization before being loaded into the kernel keyring (volatile memory) of authorized edge servers, ensuring they are not persisted to disk.
Key Rotation and "Fail-Closed" Design
The system employs an epoch model for key rotation to ensure zero downtime. A soft rotation creates a new epoch while maintaining usability of a limited number of previous epochs. A hard rotation rewraps affected keys under the new epoch and revokes access to older ones. This allows for seamless transitions while minimizing exposure.
Intentional Fail-Closed Design
Cloudflare adopted a "fail-closed" design as a critical security measure. Any failure in service context, region, or epoch checks results in rejecting the request. At the edge, a missing or malformed key prevents the service from starting. While ensuring security, this design choice has the potential for region-wide outages if provisioning, synchronization, or rotation mechanisms fail, a trade-off explicitly acknowledged by Cloudflare.