Quando a Criptografia Clássica Encontra a Pós-Quântica no TLS: Bastidores de um Handshake Híbrido em Laboratório
A criptografia que sustenta praticamente toda a comunicação segura na internet – de acesso a bancos a APIs corporativas – está vivendo seus últimos anos como solução isolada. Não se trata de alarmismo, e sim de uma constatação técnica: os mesmos fundamentos matemáticos que hoje blindam RSA e ECC serão vulneráveis diante de computadores quânticos com escala suficiente. Foi esse cenário que levou à publicação, em agosto de 2024, dos primeiros padrões oficiais de criptografia pós-quântica pelo NIST, e foi exatamente esse desafio que nos propusemos a investigar na prática, em laboratório, no SENAI CIMATEC.
A seguir, apresento o que foi feito, o que observamos e, principalmente, o que tudo isso representa para quem lida com infraestrutura, segurança, redes ou arquitetura de sistemas que precisam sobreviver à era quântica.
—
Por que a Criptografia Clássica Deixa de Ser Suficiente
Hoje, RSA e ECC (criptografia de curvas elípticas) são considerados seguros porque os problemas matemáticos em que se baseiam – fatoração de inteiros de grande porte e logaritmo discreto – são computacionalmente inviáveis para qualquer computador clássico disponível. A segurança está, essencialmente, no “impossível na prática” de resolver esses quebra-cabeças em tempo hábil.
Esse cenário muda radicalmente com a computação quântica. O algoritmo de Shor, rodando em um computador quântico com qubits estáveis e em número suficiente, consegue quebrar RSA e ECC em tempo polinomial. Ninguém sabe ao certo quando essa máquina estará pronta para uso operacional – as projeções oscilam em geral entre 10 e 20 anos -, mas o risco não começa quando o hardware finalmente surgir. Ele já existe agora.
A razão atende por um nome que deveria estar no radar de qualquer profissional de segurança: o ataque “harvest now, decrypt later” (HNDL). A ideia é simples e perversa: interceptar hoje grandes volumes de tráfego criptografado e armazená-los, na certeza de que, no futuro, um computador quântico será capaz de quebrar a proteção clássica e revelar o conteúdo.
Isso inclui segredos industriais, contratos de longo prazo, comunicações governamentais, registros médicos e qualquer tipo de dado que permaneça sensível por muitos anos. Em outras palavras: a confidencialidade de longo prazo de dados trafegando hoje sob TLS tradicional está, potencialmente, comprometida. O problema de segurança não nasce com o computador quântico – ele só se concretiza de maneira mais visível. A ameaça, porém, já está em andamento.
—
A Resposta: Criptografia Pós-Quântica e o Mundo Híbrido
Diante desse panorama, a resposta técnica tem nome e sobrenome: criptografia pós-quântica (PQC). Em 2024, o NIST publicou os primeiros padrões oficiais voltados a resistir a ataques com computadores quânticos:
– ML-KEM (FIPS 203) – voltado à troca de chaves;
– ML-DSA (FIPS 204) – esquema de assinatura digital resistente a quântica;
– SLH-DSA (FIPS 205) – outro mecanismo de assinatura digital com abordagem distinta.
Esses algoritmos foram pensados para substituir, ao longo do tempo, os mecanismos de troca de chaves e assinatura digital clássicos. Mas a migração não é um simples “desliga o antigo, liga o novo”.
Infraestruturas legadas, aplicações críticas, dispositivos embarcados, cadeias de certificados, appliances de segurança, bibliotecas em produção há anos – nada disso pode ser aposentado da noite para o dia. O resultado prático é inevitável: teremos por um bom tempo ambientes híbridos, nos quais algoritmos clássicos e pós-quânticos coexistem. Em muitos casos, inclusive, dentro do mesmo handshake TLS.
Quando se fala em TLS híbrido, surgem dúvidas muito concretas:
– Como habilitar, na prática, suites de cifra híbridas?
– A estrutura de PKI (Autoridades Certificadoras, cadeias de confiança, certificados) precisa ser refeita do zero?
– O que, exatamente, muda no fluxo do handshake TLS 1.3?
– Qual o impacto de performance e de consumo de recursos?
Foi sobre essas perguntas que construímos nossa pesquisa experimental em laboratório.
—
Como Estruturamos os Experimentos: Seis Etapas
Todos os testes foram feitos em ambiente controlado, sobre Rocky Linux 9.5, exclusivamente com ferramentas de código aberto. Essa escolha foi proposital: qualquer organização com acesso básico à internet consegue reproduzir os passos, estudar o comportamento do handshake e ajustar as configurações aos seus próprios cenários.
Etapa 1 – Anatomia do Handshake TLS 1.3
Antes de “pós-quantizar” qualquer coisa, era essencial entender em detalhes o funcionamento do handshake clássico. Utilizamos Wireshark e tcpdump para capturar o tráfego e analisar, pacote a pacote, cada mensagem envolvida na negociação TLS 1.3:
– `ClientHello` e as extensões enviadas;
– `ServerHello` e a escolha de parâmetros;
– envio e validação de certificados;
– estabelecimento dos segredos compartilhados e chaves de sessão.
Essa linha de base é fundamental. Sem dominar o fluxo de um handshake convencional – suites de cifra, negociação de chave, autenticação do servidor e, quando aplicável, do cliente – fica impossível avaliar o que, de fato, muda ao incluir algoritmos pós-quânticos na equação.
Etapa 2 – Construção de uma PKI Local
O passo seguinte foi montar nossa própria Infraestrutura de Chaves Públicas (PKI). Criamos uma Autoridade Certificadora (CA) raiz usando OpenSSL, emitimos certificados intermediários e finais, e configuramos a validação da cadeia de confiança tanto via OpenSSL quanto via curl.
Ter uma PKI local trouxe três vantagens principais:
1. Controle total sobre algoritmos, tamanhos de chave e períodos de validade;
2. Cenário realista, mas isolado, para experimentar quebras controladas, revogações e reemissões;
3. Liberdade para testar interações entre certificados clássicos e mecanismos pós-quânticos sem impactar sistemas de produção.
Etapa 3 – Servidor TLS 1.3 com NGINX
Com a PKI operacional, configuramos um servidor NGINX com suporte a TLS 1.3, utilizando os certificados ECDSA emitidos pela CA local. Esse servidor foi o “campo de provas” sobre o qual aplicaríamos as modificações pós-quânticas posteriormente.
Nesse estágio, validamos:
– compatibilidade com clientes comuns (curl, navegadores);
– conformidade do handshake clássico;
– logging adequado para depuração de erros de negociação.
Esse ambiente clássico consolidado serviu como ponto de comparação para qualquer comportamento anômalo que surgisse após a introdução dos algoritmos PQC.
Etapa 4 – Integração OpenSSL 3.x + OQS Provider
A etapa tecnicamente mais sensível foi integrar o OQS Provider (projeto Open Quantum Safe) ao OpenSSL 3.x. Esse módulo adiciona suporte experimental a algoritmos pós-quânticos, incluindo os candidatos e padrões NIST.
O processo de compilação e instalação exigiu atenção a detalhes como:
– versão exata do OpenSSL compatível com o provider;
– caminhos de instalação de bibliotecas compartilhadas;
– configuração adequada de `openssl.cnf` para carregar o provider em paralelo ao provedor default.
Um ponto crítico é que o OQS Provider é explícita e assumidamente experimental. Erros de configuração nem sempre resultam em falhas claras; muitas vezes surgem comportamentos silenciosos, algoritmos não sendo negociados apesar de estarem “habilitados” ou mensagens de erro pouco intuitivas. Parte relevante da pesquisa foi justamente mapear esses pontos de atrito.
Etapa 5 – Validando o Handshake TLS Híbrido
Com o provider operacional, configuramos cliente e servidor para negociar a suite de troca de chaves híbrida `x25519_mlkem512`. Essa combinação une:
– X25519 – mecanismo clássico de acordo de chaves baseado em curvas elípticas;
– ML-KEM-512 – algoritmo pós-quântico padronizado pelo NIST (FIPS 203), voltado à troca de chaves resistente a ataques quânticos.
O resultado prático:
– o handshake híbrido foi estabelecido com sucesso;
– a PKI clássica permaneceu plenamente funcional, usando certificados ECDSA P-256;
– o que muda é apenas a camada de key exchange, não a estrutura de confiança baseada em certificados.
Isso significa que é possível, hoje, fortalecer a confidencialidade contra futuros adversários quânticos sem necessariamente substituir imediatamente toda a cadeia de certificados ou migrar a assinatura digital para esquemas pós-quânticos. É um ponto de transição importante: primeiro, robustecemos a troca de chaves; depois, planejamos com calma a evolução da camada de identidade e assinatura.
Etapa 6 – KMS e Crypto-Agility em Ambiente de Transição
Por fim, mapeamos o ciclo de vida das chaves em um Key Management System (KMS) orientado à transição para PQC. O foco aqui não era só “conseguir gerar chaves novas”, mas garantir:
– geração segura de chaves clássicas, pós-quânticas e híbridas;
– armazenamento segmentado, com políticas distintas por tipo de algoritmo;
– rotação programada de chaves, levando em conta a obsolescência acelerada dos esquemas clássicos;
– revogação e destruição controlada de material criptográfico que não deve permanecer acessível no longo prazo.
A noção de crypto-agility – a capacidade de alternar algoritmos sem reescrever o sistema inteiro – deixa de ser um “plus de arquitetura” e passa a ser um requisito de sobrevivência. Ao observarmos o comportamento das chaves no KMS, ficou claro que arquiteturas rígidas, acopladas a um único conjunto de algoritmos, sofrerão muito mais na migração para PQC.
—
O Que Esses Resultados Significam para a Infraestrutura
Do ponto de vista prático, nossos experimentos apontam alguns recados diretos para equipes de infraestrutura e segurança:
1. É possível testar hoje handshakes híbridos TLS 1.3 com ferramentas abertas, sem depender de soluções proprietárias.
2. A PKI clássica não precisa ser descartada imediatamente. Em um primeiro momento, é viável manter certificados ECDSA ou RSA enquanto se fortalece a troca de chaves com mecanismos pós-quânticos.
3. A maior complexidade está na integração e configuração adequada de bibliotecas criptográficas (como OpenSSL) com providers adicionais. O gargalo é mais operacional do que teórico.
4. A análise de tráfego com ferramentas como Wireshark continua sendo indispensável – inclusive para validar que, de fato, o algoritmo híbrido foi negociado e não houve fallback silencioso para uma opção puramente clássica.
—
Impactos de Performance: O Custo do Híbrido
Uma preocupação recorrente em qualquer projeto de adoção de PQC é o impacto em desempenho. Ainda que nosso foco inicial não tenha sido benchmark exaustivo, alguns pontos emergem com clareza:
– Algoritmos pós-quânticos, em geral, possuem tamanhos de chave e mensagens maiores do que seus equivalentes clássicos;
– Em handshakes híbridos, há um overhead adicional por combinar dois mecanismos de troca de chaves;
– Em ambientes de alta escala, como APIs de grande volume ou proxies reversos atendendo milhões de conexões diárias, esse custo precisa ser medido com cuidado.
Do ponto de vista de segurança, porém, o custo de não migrar – ou de migrar tarde demais – tende a superar, em muito, o custo de CPU ou latência adicional por handshake. A recomendação prática é: comece a medir esse impacto em laboratório agora, para não ser surpreendido quando políticas regulatórias ou requisitos de clientes exigirem PQC em produção.
—
O Papel da Arquitetura: Planejar para Trocar de Algoritmo
Uma das lições mais importantes da experiência de laboratório é que a arquitetura de sistemas precisa prever mudança de algoritmos como algo rotineiro, e não como uma reforma extraordinária. Isso implica:
– abstrair a camada criptográfica por meio de módulos bem definidos;
– evitar espalhar detalhes de algoritmos (nomes, parâmetros) pelo código de aplicação;
– privilegiar configurações externas e políticas de segurança para controlar que suites de cifra são permitidas;
– planejar desde cedo a coexistência de múltiplos algoritmos em paralelo.
Sistemas que hoje permitem ativar ou desativar suites de cifra via configuração, sem recompilação, terão muito mais facilidade na transição para PQC.
—
Por Onde Começar na Prática
Para equipes que ainda não deram o primeiro passo rumo à criptografia pós-quântica, uma rota de ação pragmática poderia incluir:
1. Mapeamento de ativos: identificar quais serviços críticos usam TLS, quais bibliotecas criptográficas e quais versões de protocolo estão em produção.
2. Piloto de laboratório: reproduzir um cenário similar ao descrito aqui – TLS 1.3, PKI local, integração com OQS Provider ou solução equivalente.
3. Validação de compatibilidade: testar clientes diversos (navegadores, agentes internos, aplicações legadas) contra um endpoint híbrido, verificando possíveis quebras.
4. Medição de desempenho: coletar métricas de tempo de handshake, uso de CPU e memória com e sem PQC habilitado.
5. Plano de transição de chaves: desenhar um cronograma para redução gradual da dependência de algoritmos mais frágeis, como RSA de tamanhos menores, e aumento da adoção de mecanismos híbridos.
—
Conclusão: O Futuro Já Está Misturado
O principal aprendizado ao validar um handshake TLS híbrido em laboratório é que o futuro da criptografia não será puramente clássico nem puramente pós-quântico por um bom tempo. Ele será, inevitavelmente, híbrido.
Em vez de esperar por um “dia da virada” em que todos os sistemas mudarão simultaneamente para algoritmos pós-quânticos, a abordagem realista é conviver com várias gerações de criptografia em paralelo, gerenciando riscos e desempenho com precisão cirúrgica.
Começar por um ambiente controlado, entendendo o handshake em profundidade, montando uma PKI própria, integrando providers pós-quânticos e observando o ciclo de vida das chaves em um KMS preparado para crypto-agility não é um exercício acadêmico. É um ensaio geral para o que, em poucos anos, será exigido de qualquer organização que queira garantir a confidencialidade de longo prazo de seus dados.
Quem começar essa jornada agora terá tempo de errar, ajustar e amadurecer. Quem deixar para a última hora pode descobrir que a criptografia que protegeu a internet por décadas não é mais suficiente – justamente quando já for tarde para reagir com calma.