El problema fundamental que aborda GeoKey Manager es la conciliación de la alta disponibilidad y la distribución global de datos con estrictos requisitos de soberanía de datos y la creciente amenaza de la computación cuántica. En un mundo donde los datos sensibles pueden ser interceptados hoy y descifrados en el futuro por computadoras cuánticas (ataque 'harvest now, decrypt later'), y donde las regulaciones exigen que ciertos datos nunca salgan de una región geográfica específica, las soluciones criptográficas tradicionales son insuficientes.
La necesidad de una solución como GeoKey Manager surge de la tensión inherente entre la arquitectura de red global anycast de Cloudflare, diseñada para la baja latencia y la resiliencia mediante la replicación de datos, y la demanda de los clientes de garantizar que sus claves de descifrado, y por extensión sus datos en texto plano, permanezcan estrictamente dentro de límites geográficos definidos. Esto se agrava con la inminente amenaza cuántica, que requiere una migración proactiva a algoritmos criptográficos resistentes a ataques cuánticos para proteger la confidencialidad a largo plazo de los datos.
Arquitectura del Sistema
La arquitectura de GeoKey Manager se basa en una separación lógica y física de las claves de descifrado. Las claves privadas de los clientes se 'envuelven' (wrapped) utilizando un esquema de cifrado híbrido post-cuántico (ML-KEM-768 y X25519) y se distribuyen globalmente a través de Quicksilver, el sistema de distribución de configuración global de Cloudflare. Sin embargo, estas claves envueltas solo pueden ser 'desenvueltas' (unwrapped) por servidores de borde (edge servers) que posean la 'clave raíz regional' (regional root key) correspondiente.
Las claves raíz regionales son secretos simétricos de 256 bits, estrictamente confinados a su región geográfica designada. Un servicio de aprovisionamiento separado, que utiliza Vault para el almacenamiento, es responsable de distribuir estas claves raíz solo a los servidores de borde autorizados para una región específica. La autorización de un servidor de borde se basa en una combinación de su identidad de hardware verificada por Trusted Platform Module (TPM), su ubicación física según el sistema de inventario de servidores Zinc, y la configuración regional. Las claves raíz regionales se cargan en el kernel keyring de Linux de los servidores de borde, lo que garantiza que no persistan en disco y se eliminen al reiniciar la máquina, aumentando la seguridad. A partir de estas claves raíz, el servicio de gestión de claves deriva pares de claves asimétricas específicas de la aplicación (Hybrid Public Key Encryption - HPKE) que se utilizan para envolver las claves privadas de los clientes, asociándolas con un contexto de servicio, un límite regional y una época (epoch) para la rotación de claves.
Flujo de Aprovisionamiento de Claves Raíz Regionales
- 1 Admin/Cloudflare Configura una región para un caso de uso (ej. Cloudflare One)
- 2 Key Management Service Crea una clave raíz regional, la asocia con región/época
- 3 Provisioning Service Almacena la clave raíz regional (usando Vault)
- 4 Edge Server (TPM) Proporciona identidad de hardware registrada
- 5 Zinc (Inventario) Mapea identidad a datacenter/ubicación, define membresía regional
- 6 Provisioning Service Verifica identidad y membresía, emite token de acceso a claves
- 7 Edge Server Usa token para obtener claves raíz regionales autorizadas
- 8 Linux Kernel Keyring Carga claves raíz regionales (en memoria, no persistente)
Flujo de Envoltorio y Desenvuelto de Claves de Cliente
- 1 Key Management Service Recibe clave privada de cliente, contexto de servicio, límite regional
- 2 Key Management Service Obtiene clave raíz regional y época, deriva par de claves HPKE asimétricas
- 3 Key Management Service Envuelve la clave privada del cliente con el componente público HPKE
- 4 Quicksilver Distribuye la clave privada envuelta y metadatos globalmente
- 5 Edge Key Service (en Edge Server) Recibe solicitud, verifica metadatos de clave (región, servicio, época)
- 6 Edge Key Service Intenta desenvolver la clave usando la clave raíz regional del kernel keyring
- 7 Edge Key Service Si la clave raíz regional no está disponible/autorizada, la solicitud falla (...
- 8 Edge Key Service Si es exitoso, usa la clave privada para descifrar el tráfico TLS
| Capa | Tecnología | Justificación |
|---|---|---|
| security | ML-KEM-768 | Algoritmo de encapsulación de claves (KEM) post-cuántico, estándar NIST, para proteger la confidencialidad contra ataques cuánticos futuros. |
| security | X25519 | Algoritmo de intercambio de claves clásico (curva elíptica) usado en un esquema híbrido para asegurar la confidencialidad incluso si ML-KEM-768 es comprometido. |
| security | Hybrid Public Key Encryption (HPKE) | Marco criptográfico (RFC 9180) que combina KEMs, derivación de claves (HKDF-SHA-256) y cifrado autenticado (AES-256-GCM) para envolver claves de forma segura. |
| storage | Vault | Almacenamiento seguro de claves raíz regionales por el servicio de aprovisionamiento, gestionado on-premises. |
| security | Trusted Platform Module (TPM) | Proporciona una identidad de hardware registrada y verificable para los servidores de borde, fundamental para la autorización regional. |
| orchestration | Zinc | Sistema de inventario de servidores de Cloudflare que mapea identidades de hardware a ubicaciones físicas y membresías regionales, actualizando la configuración de la red. |
| messaging | Quicksilver | Sistema de distribución de configuración global de Cloudflare, utilizado para distribuir claves privadas envueltas y sus metadatos a través de la red. |
| security | Linux Kernel Keyring | Almacenamiento en memoria volátil para claves raíz regionales en los servidores de borde, garantizando que las claves no persistan en disco y se eliminen al reiniciar. |
Trade-offs
Ganancias
- ▲ Protección contra ataques 'harvest now, decrypt later'
- ▲ Cumplimiento de regulaciones de soberanía de datos
- ▲ Control granular sobre la ubicación de descifrado de claves
- ▲ Resiliencia criptográfica (hibridación PQ)
Costes
- ▲ Complejidad operacional (gestión de claves raíz regionales, rotación, aprovisionamiento)
- △ Latencia potencial en el inicio del servicio (carga de claves en kernel keyring)
Fundamentos Teóricos
El concepto de restringir el acceso a datos y claves basado en atributos o ubicación geográfica se alinea con los principios de Attribute-Based Encryption (ABE), aunque el artículo señala que no hay un esquema ABE post-cuántico maduro para producción. ABE, introducido por Sahai y Waters en 2005, permite cifrar datos de tal manera que solo los usuarios con un conjunto específico de atributos pueden descifrarlos. En GeoKey Manager, la 'región' y el 'contexto de servicio' actúan como atributos implícitos que determinan la capacidad de descifrado.
La adopción de ML-KEM-768 (anteriormente Kyber) como parte del esquema de encapsulación de claves híbrido es una respuesta directa a la amenaza de la computación cuántica, un campo de investigación que ha ganado tracción significativa desde los trabajos seminales de Shor (1994) y Grover (1996) sobre algoritmos cuánticos que pueden romper la criptografía de clave pública actual. La estrategia de 'hibridación' (combinar un esquema post-cuántico con uno clásico como X25519) es una práctica recomendada para la transición, asegurando que la seguridad se mantenga incluso si uno de los componentes criptográficos falla, un concepto similar a la 'seguridad en capas' o 'defensa en profundidad' en la seguridad de sistemas.