Cloudflare avvia closed beta del GeoKey Manager post-quantum

Il 23 ottobre Cloudflare ha aperto ai clienti della Data Localization Suite la closed beta del GeoKey Manager riprogettato per il post-quantum: abbandona l’encryption basata su attributi e usa HPKE ibrido con ML-KEM-768 e X25519. La disponibilità generale è prevista nel primo trimestre del 2027¹.

La riprogettazione risponde a due vincoli: le regole di sovranità dei dati, che confinano l’elaborazione in chiaro a una regione, e gli attacchi harvest-now, decrypt-later, in cui il traffico catturato oggi viene decrittato quando esisteranno computer quantistici pratici¹. GeoKey Manager è nato nel 2017 per le chiavi TLS e nel 2022 è passato alla ciphertext-policy attribute-based encryption. Cloudflare indica due ragioni per abbandonarla: non esiste una variante post-quantum pronta per la produzione e i clienti non richiedono l’ampio numero di regioni che quel modello esprimeva¹.

Il nuovo meccanismo adotta HPKE, come definito in RFC 9180, con un KEM ibrido che combina ML-KEM-768 e X25519, più HKDF-SHA-256 e AES-256-GCM¹. Le policy lasciano posto a due classi di chiavi. Le root regionali sono segreti simmetrici a 256 bit, uno per regione. Da un root si derivano coppie di chiavi specifiche per applicazione e per epoca. Cloudflare chiama epoca una generazione di chiavi che avanza con la rotazione. Il servizio di gestione chiavi deriva la coppia applicativa e avvolge le chiavi private dei clienti sotto la componente pubblica¹.

Le due classi di chiavi seguono percorsi separati. Quicksilver, il key-value store replicato globalmente di Cloudflare, trasporta ovunque le chiavi avvolte e i metadati. Le root regionali viaggiano su un canale distinto attraverso il servizio di provisioning, che le conserva in Vault¹. Prima di ricevere un root, un server edge deve superare tre verifiche: attestazione dell’identità hardware tramite TPM, un lookup in Zinc, l’inventario server di Cloudflare che mappa l’identità a data center e posizione, e una decisione del provisioning su quali root quel server può detenere. I server autorizzati caricano poi i root nella kernel keyring, non su disco. Quella memoria è volatile: un riavvio rimuove le chiavi e il server deve autenticarsi di nuovo. L’appartenenza regionale si aggiorna più volte al giorno, separatamente dalla rotazione delle chiavi e senza azione del cliente¹.

Dabeer Shaikh, senior solutions engineer di HashiCorp, ha chiesto come ruotare una chiave geo-vincolata senza interruzioni. La risposta è nel modello a epoche: una soft rotation crea una nuova epoca e mantiene utilizzabili un numero limitato di epoche precedenti, così i clienti restano online durante la transizione. Una hard rotation reavvolge le chiavi coinvolte sotto l’epoca di sostituzione e rimuove l’accesso a quella precedente¹.

Mark Tehrani, fondatore di CyberSeQ e docente di cybersecurity, ha posto cinque domande: il raggio d’impatto di un root regionale compromesso, la possibilità che un Zinc o un provisioning compromessi consegnino root a server fuori regione, la protezione delle chiavi esposte prima di una rotazione, un piano di controllo compromesso che modifichi la membership. La quinta: se provisioning, sincronizzazione o rotazione falliscono, il design a fail-closed può causare un outage regionale¹? Il post è esplicito: qualsiasi controllo fallito su contesto di servizio, regione o epoca porta al rifiuto della richiesta. Al bordo, una chiave mancante o malformata impedisce l’avvio del servizio. Gli autori definiscono il fail-closed una scelta intenzionale. Il perimetro di fiducia include i servizi di gestione chiavi, provisioning e i servizi di chiave sugli edge autorizzati. Quicksilver resta fuori, perché contiene solo chiavi avvolte e metadati¹.

A marzo Cloudflare ha adottato ML-KEM ibrido per IPsec, quando oltre il 60% del traffico TLS generato da umani sulla sua rete già lo usava, e ha annunciato piani per una certificate authority quantum-safe. Al lancio la copertura riguarderà la maggior parte delle regioni, con caveat specifici per prodotto¹.