Cloudflare abre la beta cerrada de GeoKey Manager con un esquema híbrido postcuántico
La nueva versión de GeoKey Manager combina ML-KEM-768 y X25519 para limitar dónde se pueden desenvolver claves privadas, dentro de Data Localization Suite. Está en beta cerrada y no decide por sí sola dónde se enruta o inspecciona el tráfico; Cloudflare prevé la disponibilidad general para Q1 de 2027.
Cloudflare presenta una nueva arquitectura de GeoKey Manager dentro de su Data Localization Suite (DLS), ahora en beta cerrada. La función intenta asegurar que una clave privada de descifrado solo pueda desenvolverse en la geografía elegida por el cliente, aunque Cloudflare distribuya por su red claves cifradas y metadatos. La disponibilidad general está prevista para el primer trimestre de 2027; por ahora, el anuncio describe una prueba, no un servicio listo para cualquier cuenta.
-InfraCrew dice: Que el ciphertext viaje no significa que la llave también tenga que hacer turismo.-
La geografía importa por dos motivos que se cruzan en servicios cloud: obligaciones de residencia y el riesgo de cosechar hoy y descifrar mañana. Un atacante puede guardar datos cifrados ahora y esperar a que futuros avances permitan romper la protección clásica. Cloudflare combina ese riesgo con otro requisito: replicar información para mantener disponibilidad global sin permitir que cualquier punto de presencia lea el texto claro.
La región vive en la jerarquía de claves
Cloudflare explica que la nueva versión cambia la arquitectura de claves, no se limita a activar un algoritmo cuántico. La versión anterior de GeoKey Manager ya restringía dónde podían desenvolverse las claves privadas de conexión; en 2022 pasó a cifrado basado en atributos para describir conjuntos de regiones. La compañía dice que no existe hoy un esquema de ese tipo postcuántico listo para producción y que sus clientes no necesitan una cantidad grande de regiones, así que simplificó el modelo a límites regionales explícitos.
En la ruta actual de Cloudflare One, la capa híbrida emplea ML-KEM-768 junto con X25519. ML-KEM-768 es uno de los parámetros del KEM ML-KEM que NIST normalizó en FIPS 203; X25519 mantiene un componente clásico. Cloudflare lo integra con HPKE, HKDF-SHA-256 y AES-256-GCM. La combinación busca que el secreto siga protegido mientras al menos uno de los dos componentes de encapsulación resista, según la descripción de Cloudflare. Esto no convierte cualquier cifrado del producto en “a prueba de cuántica”: el alcance descrito es la envoltura de claves privadas para servicios compatibles.
-InfraCrew dice: Poner “postcuántico” en el diagrama queda bien; saber qué clave envuelve a cuál es lo que evita que el diagrama mienta.-
La jerarquía comienza con una clave raíz regional, un secreto simétrico de 256 bits asociado a una geografía. De ella se deriva un par de claves específico para cada servicio, como Gateway o Tunnel. Cada clave privada envuelta lleva metadatos con contexto de servicio, región y epoch, es decir, la generación de la raíz usada para protegerla. La clave pública del par envuelve el material del cliente; para abrirlo hace falta la parte privada derivada y la raíz correspondiente.
La distribución separa disponibilidad de acceso criptográfico. Quicksilver, el sistema global de configuración de Cloudflare, replica claves ya envueltas y sus metadatos. Las raíces regionales recorren otro camino: un servicio de aprovisionamiento las guarda y entrega solo a servidores autorizados para esa zona. Cloudflare dice que usa Vault autogestionado en sus instalaciones para ese servicio. El ciphertext puede ser global; la raíz no.
Cómo decide un servidor qué puede abrir
Antes de recibir una raíz, cada servidor de borde presenta una identidad de hardware respaldada por un TPM. El inventario interno Zinc asocia esa identidad con un centro de datos y su ubicación; después, el aprovisionador emite un token que permite recuperar únicamente las raíces asignadas allí. Cloudflare carga esas raíces en el kernel keyring, no en disco. Un reinicio elimina la copia volátil y obliga al servidor a autenticarse y provisionarse otra vez.
Cloudflare describe una política fail closed (rechaza ante una comprobación fallida): si falta una raíz configurada, el servicio de claves no inicia; si una solicitud llega a un nodo que no tiene la raíz de esa región, se rechaza. Eso evita que una avería de aprovisionamiento termine abriendo la clave fuera de zona, pero sí convierte la disponibilidad del plano de control y de la configuración regional en una dependencia de servicio. -InfraCrew dice: Si la clave no llega, la política de residencia funciona perfectamente; el runbook tiene que explicar qué pasa con la aplicación.-
La explicación también deja ver dónde se concentra el riesgo. Las claves de aplicación se reutilizan para el mismo servicio, región y epoch; Cloudflare señala que comprometer una clave Tunnel de Alemania podría exponer varias claves de ese mismo contexto, mientras que comprometer la raíz regional afectaría a más claves derivadas de esa generación. La compañía propone rotaciones soft —mantener acceso controlado a alguna generación anterior para facilitar la transición— y hard, que reenvuelven las claves para retirar el acceso a la época anterior. La continuidad mejora con la primera; la segunda reduce antes la ventana de confianza.
Una valla para claves, no para todo el tráfico
El límite del producto es importante en una evaluación de soberanía. GeoKey Manager controla dónde puede desenvolverse y usarse la clave privada; no determina dónde se enrutan las solicitudes, terminan los túneles ni se inspecciona el tráfico. Cloudflare atribuye esas decisiones a Regional Services y a trabajos separados. Por tanto, mantener la clave dentro de una región no demuestra por sí solo que todo el procesamiento de datos ocurra allí.
La beta cerrada se integra con Data Localization Suite y la compañía dice que ofrecerá la mayoría de sus regiones, con salvedades por producto. La nueva integración con CDN sigue en desarrollo; Cloudflare invita a ciertos clientes DLS a manifestar interés en probarla antes de la disponibilidad general, pero todavía no publica una fecha de transición. Q1 de 2027 es una previsión de GA, no una fecha de despliegue para cada servicio.
Para una organización que evalúe el diseño, la verificación debe mirar más allá de la clave: qué productos y geografía cubre la beta, qué ocurre durante reinicios o fallos de aprovisionamiento, qué claves comparten servicio/región/epoch y qué evidencia respalda la ubicación del procesamiento, además de la clave. La arquitectura publicada es la explicación del propio proveedor y no equivale a una auditoría independiente. Antes de convertirla en requisito de cumplimiento, conviene contrastarla con las obligaciones regulatorias y con la configuración de Regional Services.
Diccionario de la Crew
DLS — Data Localization Suite, conjunto de servicios de Cloudflare para configurar controles de localización de datos.
Cosechar hoy y descifrar mañana — Estrategia que conserva ciphertext actual para intentar descifrarlo cuando haya capacidades futuras.
ML-KEM-768 — Parámetro de seguridad 768 del mecanismo ML-KEM, estandarizado por NIST para encapsular claves.
KEM — Mecanismo de encapsulación de claves que permite acordar un secreto compartido a través de un canal público.
X25519 — Función de intercambio de claves basada en la curva Curve25519.
HPKE — Esquema híbrido para cifrar información a una clave pública usando encapsulación y cifrado simétrico.
Clave raíz regional — Secreto simétrico asociado a una región del que se derivan claves de aplicación.
Epoch — Generación de una clave raíz, usada para identificar la versión criptográfica vigente o anterior.
TPM — Módulo de hardware que puede respaldar la identidad criptográfica de un dispositivo.
Quicksilver — Sistema global de Cloudflare para distribuir configuración por su red.
FIPS 203 — Estándar de NIST que especifica el mecanismo de encapsulación ML-KEM.
Zinc — Inventario de servidores de Cloudflare que vincula una identidad de hardware con su centro de datos y ubicación.
Kernel keyring — Almacén de claves en memoria que ofrece el kernel Linux a procesos autorizados.
Fail closed — Comportamiento que rechaza una operación si no puede confirmar todas las condiciones de seguridad.
