Real-Time VPN Traffic over ETSI GS QKD 014 Key Delivery with a LuxQuanta NOVA QKD Platform

Resumen Técnico: Tráfico VPN en Tiempo Real sobre la Entrega de Claves ETSI GS QKD 014 con una Plataforma QKD LuxQuanta NOVA

Planteamiento del Problema
La Distribución de Claves Cuánticas (QKD) genera material de claves simétricas entre sitios distantes utilizando estados cuánticos y post-procesamiento clásico autenticado, ofreciendo seguridad basada en las leyes físicas en lugar de la dureza computacional. Sin embargo, en los sistemas desplegados, las capacidades cuánticas puras no son consumidas directamente por las aplicaciones. En su lugar, son mediadas por Entidades de Gestión de Claves (KME) que exponen interfaces orientadas a la aplicación. Si bien el estándar ETSI GS QKD 014 define una API basada en REST (HTTPS/JSON) para que las Entidades de Aplicación Segura (SAE) soliciten y recuperen claves, deja intencionadamente fuera de su alcance el transporte de los identificadores de clave entre aplicaciones. El desafío abordado por este experimento es si una aplicación de red convencional, específicamente una VPN de espacio de usuario de Linux, puede interoperar con éxito con una infraestructura QKD real adhiriéndose al modelo de recuperación de claves maestro/esclavo de ETSI 014 sin depender de protocolos específicos de un proveedor o de claves precompartidas estáticas.

Metodología
El experimento siguió una metodología de validación de tres etapas para aislar la lógica de implementación, la conformidad con los estándares y la interoperabilidad del hardware:

1. Implementación de la VPN: Se desarrolló un prototipo en Python de proceso único y orientado a eventos para Linux. Este crea una interfaz TUN, reenvía paquetes IP sobre un túnel UDP y cifra los tramas utilizando AES-256-GCM. La VPN actúa como una SAE, obteniendo claves de transmisión de una KME a través del endpoint enc_keys de ETSI y recuperando las claves de pares mediante dec_keys. Crucialmente, la VPN implementa un mecanismo de transporte en banda (in-band), incrustando el key_ID de ETSI dentro del encabezado de la trama del túnel (como parte de los Datos Autenticados Adicionales - AAD) para permitir que el par receptor resuelva la clave de descifrado correcta.
2. Simulación Controlada: Antes de las pruebas de hardware, la VPN fue validada contra un paquete kms personalizado que simulaba la API ETSI 014. Este simulador emulaba el contrato orientado a la aplicación, incluyendo la autenticación mTLS, la topología SAE, la propiedad de las claves y el ciclo de vida de la emisión y recuperación de claves (eliminando las claves tras su recuperación para imitar las post-condiciones de ETSI).
3. Pruebas en el Mundo Real: La etapa final reemplazó el simulador con un backend QKD LuxQuanta NOVA real. El banco de pruebas consistió en dos kits de desarrollo NVIDIA Jetson Xavier NX ejecutando Ubuntu 24.04. Cada Jetson ejecutaba un par de VPN conectado a una unidad QKD LuxQuanta NOVA local (QKD A y QKD B). Las unidades QKD estaban vinculadas mediante un canal cuántico provisto por el proveedor y un canal de post-procesamiento clásico. La VPN trató la capa QKD como opaca, interactuando únicamente con la API local ETSI GS 014.
   • Tráfico: Se transmitieron de forma bidireccional audio y video en tiempo real (H.264/AAC sobre MPEG-TS/UDP) durante ocho horas.
   • Parámetros: El sistema utilizó un intervalo de rotación de claves de 60 segundos, claves AES-GCM de 256 bits y una MTU de TUN de 1400 bytes. El enlace directo utilizó la subred 10.0.0.0/24, mientras que el túnel cifrado utilizó 10.10.0.0/24.

Contribuciones Clave

• Validación Orientada a la Implementación: El artículo proporciona una implementación concreta del patrón de aplicación ETSI GS 014, demostrando que una aplicación de red estándar puede actuar tanto como "maestro" (solicitando claves) como "esclavo" (recuperando claves) dependiendo de la dirección del tráfico.
• Transporte de Identificador en Banda (In-Band): El trabajo aborda explícitamente el vacío dejado por el estándar ETSI respecto al transporte del identificador de la clave. Demuestra un método donde el key_ID se vincula criptográficamente al texto cifrado mediante AES-GCM AAD, asegurando que la manipulación del identificador provoque un fallo de descifrado.
• Interoperabilidad de Hardware: El experimento validó con éxito el flujo de extremo a extremo desde una aplicación clásica (VPN) a través de una API estandarizada (ETSI 014) hasta una plataforma de hardware QKD de Variable Continua (CV) específica (LuxQuanta NOVA), probando que la aplicación no necesita comprender la capa óptica cuántica subyacente.

Resultados
El experimento estableció con éxito un túnel VPN cifrado entre los dos pares de Jetson utilizando claves entregadas por la plataforma LuxQuanta NOVA.

• Conectividad: Ambos pares se autenticaron ante sus KME locales utilizando certificados X.509, configuraron interfaces TUN y comenzaron a intercambiar tramas de keepalive y de datos cifradas.
• Rendimiento: El sistema sostuvo una prueba bidireccional de audio/video de ocho horas con buena calidad y reproducción en tiempo real.
• Gestión de Claves: Con un intervalo de rotación de 60 segundos, cada dirección solicitó aproximadamente una nueva clave de 256 bits por minuto. No se observó evidencia de saturación en la entrega de claves; las solicitudes enc_keys tuvieron éxito y los pares receptores resolvieron con éxito los valores de key_ID de los pares mediante dec_keys sin interrupciones en el medio.
• Seguridad: El descifrado exitoso de los paquetes confirmó que ambos lados obtuvieron bytes de clave idénticos, que las autorizaciones de las SAE eran correctas y que el transporte del identificador de la clave funcionó según lo previsto.

Significancia y Reivindicaciones
El artículo sostiene que ETSI GS 014 es suficiente como protocolo de entrega de claves orientado a la aplicación para consumidores tipo VPN, siempre que la aplicación suministre su propio transporte de identificadores y vínculo criptográfico. La significancia reside en aislar el mecanismo esencial de interoperabilidad: la aplicación consume contenedores de claves ETSI y transporta valores de key_ID sin integrar supuestos ópticos específicos de QKD.

Los autores son modestos respecto al alcance de la demostración:

• El prototipo utilizó claves derivadas de QKD como claves AES-256-GCM rotadas periódicamente, no como un one-time pad para cada paquete.
• El diseño es un estudio de viabilidad, no un protocolo listo para producción. Carece de características como handshakes entre pares, conjuntos de parámetros negociados, protocolos de recuperación, control de congestión o navegación NAT.
• La construcción del nonce depende de números de secuencia monotónicos, lo que requeriría un estado persistente o mecanismos de sesión explícitos para su uso en producción para evitar la reutilización tras reinicios.

En última instancia, el trabajo valida un patrón de integración coherente donde el sistema QKD gestiona la generación y la sincronización, mientras que la aplicación gestiona la protección de paquetes y la notificación del identificador de la clave, cerrando la brecha entre la infraestructura cuántica y las aplicaciones de red clásicas.