Quando o Clássico e o Pós-Quântico se Encontram no TLS: O Que Aprendi Validando um Handshake Híbrido em Laboratório
- Cyber Security Brazil
- há 4 dias
- 5 min de leitura
A criptografia que protege praticamente toda a comunicação segura na internet tem um prazo de validade. Não é catastrofismo — é uma conclusão técnica bem documentada, que motivou o NIST a publicar, em agosto de 2024, os primeiros padrões de criptografia pós-quântica da história. E é o problema que decidimos investigar de forma experimental no SENAI CIMATEC.
Este artigo descreve o que fizemos, o que encontramos e o que isso significa para quem trabalha com infraestrutura, segurança ou arquitetura de sistemas.
O problema: por que a criptografia clássica não é suficiente
RSA e ECC (criptografia de curvas elípticas) são seguros porque resolver os problemas matemáticos por trás deles — fatoração de inteiros e logaritmo discreto — é inviável para qualquer computador clássico disponível.
Essa premissa muda com computadores quânticos. O algoritmo de Shor, executado em um computador quântico de capacidade suficiente, quebra RSA e ECC em tempo polinomial. Não se sabe ao certo quando esse computador existirá — estimativas variam entre 10 e 20 anos —, mas o risco já é real hoje por outro motivo.
O ataque "harvest now, decrypt later" (HNDL) consiste em capturar e armazenar tráfego cifrado agora para decifrar no futuro, quando o computador quântico existir. Segredos industriais, registros médicos, comunicações estratégicas — qualquer dado com longevidade que trafegue hoje pela internet sob criptografia clássica está potencialmente exposto a esse vetor. A ameaça não começa quando o computador quântico chegar. Ela já está em andamento.
A resposta: criptografia pós-quântica e a inevitabilidade dos ambientes híbridos
O NIST padronizou três algoritmos resistentes à computação quântica: ML-KEM (FIPS 203, para troca de chaves), ML-DSA (FIPS 204, para assinatura digital) e SLH-DSA (FIPS 205, assinatura alternativa).
A migração, porém, não acontece de uma vez. A infraestrutura atual — servidores, clientes, certificadoras, dispositivos legados — não pode ser substituída da noite para o dia. O cenário inevitável é o ambiente híbrido: sistemas em que algoritmos clássicos e pós-quânticos coexistem, às vezes dentro do mesmo handshake TLS.
Essa coexistência levanta perguntas práticas que nenhuma especificação responde sozinha: como configurar isso? O que muda no TLS? A PKI existente precisa ser refeita? Qual o custo de performance? É exatamente aí que entra o nosso trabalho.
O que fizemos: metodologia experimental em seis etapas
Toda a pesquisa foi conduzida em laboratório, sobre Rocky Linux 9.5, usando exclusivamente ferramentas open source. A escolha não foi apenas pragmática — foi deliberada: qualquer instituição com acesso à internet consegue reproduzir cada etapa.
Etapa 1 — Análise do handshake TLS 1.3 Começamos pelo começo: capturar e dissecar o que realmente acontece quando um cliente e um servidor estabelecem uma sessão TLS. Com Wireshark e tcpdump, inspecionamos ao nível de pacote o Client Hello, o Server Hello, a troca de certificados e o estabelecimento da sessão criptografada. Essa linha de base é essencial — sem entender o handshake clássico em detalhe, não há como avaliar o que muda quando inserimos algoritmos pós-quânticos.
Etapa 2 — Implementação de PKI local Criamos uma Autoridade Certificadora raiz com OpenSSL, emitimos e assinamos certificados digitais, e configuramos a validação da cadeia de confiança com OpenSSL e curl. O objetivo foi ter controle total sobre a PKI para os experimentos seguintes.
Etapa 3 — Servidor TLS 1.3 com NGINX Subimos um servidor NGINX com TLS 1.3 usando os certificados emitidos pela nossa CA local. Isso estabeleceu o ambiente base sobre o qual adicionaríamos os algoritmos pós-quânticos.
Etapa 4 — Integração OpenSSL 3.x + OQS Provider O OQS Provider é um módulo desenvolvido pela iniciativa Open Quantum Safe que adiciona algoritmos pós-quânticos ao OpenSSL 3.x. Compilar, instalar e validar essa integração foi tecnicamente o passo mais delicado — o provider é explicitamente experimental, a documentação é escassa, e erros de configuração resultam em falhas silenciosas ou mensagens pouco descritivas.
Etapa 5 — Validação do handshake TLS híbrido Com o OQS Provider operacional, configuramos cliente e servidor para negociar a suíte híbrida x25519_mlkem512: uma combinação de X25519 (clássico) com ML-KEM-512 (pós-quântico, NIST FIPS 203). O resultado:
O handshake híbrido funcionou. A PKI clássica (certificado ECDSA P-256) continuou válida — o que muda é apenas a camada de troca de chaves, não a estrutura de confiança.
Etapa 6 — Análise do KMS e crypto-agility Por fim, mapeamos o ciclo de vida das chaves em um Key Management System orientado à transição PQC: geração, armazenamento, rotação e revogação de chaves em um ambiente que precisa suportar algoritmos clássicos e pós-quânticos simultaneamente.
O que aprendemos: quatro desafios reais da migração
A validação técnica foi bem-sucedida, mas o processo revelou quatro frentes de desafio que vão muito além de “trocar o algoritmo":
1. Interoperabilidade: Sistemas clássicos e pós-quânticos precisam se comunicar durante toda a transição. A suíte híbrida resolve isso para a troca de chaves — mas certificados, protocolos de revogação (CRL/OCSP) e outros componentes da PKI também precisarão evoluir.
2. Performance: As chaves do ML-KEM são significativamente maiores do que as do X25519 clássico (chave pública ~800 bytes vs. ~32 bytes). O handshake fica mais pesado. Em ambientes de alta escala, isso se traduz em latência e custo computacional que precisam ser quantificados e gerenciados.
3. Gerenciamento do ciclo de vida das chaves: Um KMS que suporte PQC precisa ser capaz de gerar, armazenar, rotar e revogar chaves de algoritmos distintos, com políticas diferentes, sem comprometer a operação dos sistemas legados que ainda dependem do clássico. Isso é muito mais complexo do que um KMS tradicional.
4. Crypto-agility: A capacidade de trocar de algoritmo sem reengenharia profunda da aplicação — o que chamamos de agilidade criptográfica — deixa de ser um "nice to have" e se torna uma capacidade crítica de segurança. Sistemas que hoje têm o algoritmo "hard-coded" terão custos de migração exponencialmente maiores.
O que vem a seguir: Quantum OWASP Top 10
Uma das conclusões mais importantes do trabalho foi perceber que a migração para PQC cria novas superfícies de ataque que ainda não têm framework de análise consolidado. Configurações híbridas mal feitas podem, paradoxalmente, ser menos seguras do que configurações clássicas — por exemplo, se permitirem fallback silencioso para o componente clássico quando o pós-quântico falha.
Como trabalho futuro, estamos desenvolvendo o Quantum OWASP Top 10: um framework para mapear sistematicamente os riscos específicos da transição pós-quântica — falhas de configuração, vetores de downgrade, gestão inadequada de chaves em ambientes bimodais e ausência de crypto-agility em sistemas críticos.
Reflexão final
A segurança pós-quântica não é um problema do futuro. É um problema de hoje, que exige planejamento hoje — especialmente para sistemas com longos ciclos de atualização e dados com longevidade.
O que validamos em laboratório é encorajador: a integração é tecnicamente viável, com ferramentas acessíveis, sem reescrever toda a infraestrutura existente. Mas a viabilidade técnica é apenas o começo. A migração real exige maturidade operacional, crypto-agility e uma nova forma de pensar o ciclo de vida das chaves.
"A segurança pós-quântica também é um desafio de adaptação operacional."
Agradecimentos Ao Prof. João Marcelo Silva Souza, pela orientação e visão do projeto. Ao SENAI CIMATEC e ao projeto Integração Clássico e Quântico pelo ambiente de pesquisa.
O resumo completo foi apresentado no XI SAPCT 2026. Está disponível para quem tiver interesse.
Ney Ricardo Lopez Junior — Pesquisador em Comunicação e Tecnologia Quântica | SENAI CIMATEC