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

Resumo Técnico: Tráfego de VPN em Tempo Real sobre Entrega de Chaves ETSI GS QKD 014 com uma Plataforma QKD LuxQuanta NOVA

Definição do Problema
A Distribuição de Chaves Quânticas (QKD) gera material de chave simétrica entre sites distantes usando estados quânticos e pós-processamento clássico autenticado, oferecendo segurança baseada em leis físicas em vez de dureza computacional. No entanto, em sistemas implantados, as capacidades quânticas brutas não são consumidas diretamente pelas aplicações. Em vez disso, elas são mediadas por Entidades de Gerenciamento de Chaves (KMEs) que expõem interfaces voltadas para a aplicação. Embora o padrão ETSI GS QKD 014 defina uma API baseada em REST (HTTPS/JSON) para que Entidades de Aplicação Segura (SAEs) solicitem e recuperem chaves, ele deixa intencionalmente fora de seu escopo o transporte de identificadores de chave entre aplicações. O desafio abordado por este experimento é se uma aplicação de rede convencional, especificamente uma VPN no espaço do usuário Linux, pode interoperar com sucesso com uma infraestrutura QKD real, aderindo ao modelo de recuperação de chaves mestre/escravo do ETSI 014 sem depender de protocolos proprietários ou chaves pré-compartilhadas estáticas.

Metodologia
O experimento seguiu uma metodologia de validação em três estágios para isolar a lógica de implementação, a conformidade com padrões e a interoperabilidade de hardware:

1. Implementação da VPN: Um protótipo Python de processo único e orientado a eventos foi desenvolvido para Linux. Ele cria uma interface TUN, encaminha pacotes IP sobre um túnel UDP e criptografa quadros usando AES-256-GCM. A VPN atua como uma SAE, obtendo chaves de transmissão de uma KME via endpoint enc_keys do ETSI e recuperando chaves de pares via dec_keys. Crucialmente, a VPN implementa um mecanismo de transporte in-band, incorporando o key_ID do ETSI no cabeçalho do quadro do túnel (como parte dos Dados Autenticados Adicionais - AAD) para permitir que o par receptor resolva a chave de decriptação correta.
2. Simulação Controlada: Antes dos testes de hardware, a VPN foi validada contra um pacote kms customizado que simulava a API ETSI 014. Este simulador emulou o contrato voltado para a aplicação, incluindo autenticação mTLS, topologia SAE, propriedade de chave e o ciclo de vida de emissão e recuperação de chaves (excluindo chaves após a recuperação para mimetizar as pós-condições do ETSI).
3. Teste em Mundo Real: O estágio final substituiu o simulador por um backend QKD LuxQuanta NOVA real. O ambiente de teste consistiu em dois kits de desenvolvedor NVIDIA Jetson Xavier NX rodando Ubuntu 24.04. Cada Jetson executava um par de VPN conectado a uma unidade QKD LuxQuanta NOVA local (QKD A e QKD B). As unidades QKD foram interconectadas via um canal quântico fornecido pelo fabricante e um canal de pós-processamento clássico. A VPN tratou a camada QKD como opaca, interagindo apenas com a API local ETSI GS QKD 014.
   • Tráfego: Áudio e vídeo em tempo real (H.264/AAC sobre MPEG-TS/UDP) foram transmitidos bidirecionalmente durante oito horas.
   • Parâmetros: O sistema utilizou um intervalo de rotação de chave de 60 segundos, chaves AES-256-GCM de 256 bits e um MTU TUN de 1400 bytes. O link direto usou a sub-rede 10.0.0.0/24, enquanto o túnel criptografado usou 10.10.0.0/24.

Principais Contribuições

• Validação Orientada à Implementação: O artigo fornece uma implementação concreta do padrão de aplicação ETSI GS QKD 014, demonstrando que uma aplicação de rede padrão pode atuar tanto como "mestre" (solicitando chaves) quanto como "escravo" (recuperando chaves) dependendo da direção do tráfego.
• Transporte de Identificador In-Band: O trabalho aborda explicitamente a lacuna deixada pelo padrão ETSI quanto ao transporte do identificador de chave. Ele demonstra um método onde o key_ID é criptograficamente vinculado ao texto cifrado via AAD de AES-GCM, garantindo que a adulteração do identificador cause falha na decriptação.
• Interoperabilidade de Hardware: O experimento validou com sucesso o fluxo de ponta a ponta desde uma aplicação clássica (VPN), através de uma API padronizada (ETSI 014), até uma plataforma de hardware QKD de Variável Contínua (CV) específica (LuxQuanta NOVA), provando que a aplicação não precisa compreender a camada óptica quântica subjacente.

Resultos
O experimento estabeleceu com sucesso um túnel VPN criptografado entre os dois pares Jetson usando chaves entregues pela plataforma LuxQuanta NOVA.

• Conectividade: Ambos os pares autenticaram-se em suas respectivas KMEs locais usando certificados X.509, configuraram interfaces TUN e começaram a trocar quadros de dados e keepalive criptografados.
• Desempenho: O sistema sustentou um teste bidirecional de áudio/vídeo de oito horas com boa qualidade e reprodução em tempo real.
• Gerenciamento de Chaves: Com um intervalo de rotação de 60 segundos, cada direção solicitou aproximadamente uma nova chave de 256 bits por minuto. Não foi observada evidência de saturação na entrega de chaves; as solicitações enc_keys tiveram sucesso, e os pares receptores resolveram com êxito os valores de key_ID dos pares via dec_keys sem interrupção da mídia.
• Segurança: A decriptação bem-sucedida dos pacotes confirmou que ambos os lados obtiveram bytes de chave idênticos, que as autorizações das SAEs estavam corretas e que o transporte do identificador de chave funcionou conforme pretendido.

Significância e Alegações
O artigo alega que o ETSI GS QKD 014 é suficiente como um protocolo de entrega de chaves voltado para a aplicação para consumidores do tipo VPN, desde que a aplicação forneça seu próprio transporte de identificador e vínculo criptográfico. A significância reside no isolamento do mecanismo essencial de interoperabilidade: a aplicação consome contêineres de chaves ETSI e transporta valores de key_ID sem incorporar suposições ópticas específicas de QKD.

Os autores são modestos quanto ao escopo da demonstração:

• O protótipo usou chaves derivadas de QKD como chaves AES-256-GCM rotacionadas periodicamente, não como um one-time pad para cada pacote.
• O design é um estudo de viabilidade, não um protocolo pronto para produção. Carece de recursos como handshakes entre pares, conjuntos de parâmetros negociados, protocolos de recuperação, controle de congestionamento ou travessia de NAT.
• A construção do nonce depende de números de sequência monotônicos, o que exigiria estado persistente ou mecanismos de sessão explícitos para uso em produção para evitar a reutilização após reinicializações.

Em última análise, o trabalho valida um padrão de integração coerente onde o sistema QKD lida com a geração e sincronização, enquanto a aplicação lida com a proteção de pacotes e a notificação do identificador de chave, preenchendo a lacuna entre a infraestrutura quântica e as aplicações de rede clássicas.