Agilidade criptográfica: definição e como incorporá-la aos sistemas

Agilidade criptográfica (crypto agility) é a capacidade de um sistema de trocar seus algoritmos, parâmetros e chaves criptográficos sem reescrever o código da aplicação e sem esperar uma nova versão do produto. Não é um recurso que se compra: é um conjunto de propriedades de engenharia, principalmente configuração em vez de escolhas fixas no código, negociação no nível do protocolo, um inventário atualizado, fronteiras de abstração bem definidas e ciclos de vida automatizados de chaves e certificados. Os reguladores agora descrevem a mesma capacidade com suas próprias palavras: por exemplo, as normas técnicas do DORA exigem uma política de criptografia com disposições para mudar a tecnologia criptográfica conforme a criptoanálise evolui.

O que significa agilidade criptográfica

Uma definição de trabalho útil: um sistema é criptograficamente ágil quando um operador competente consegue trocar um algoritmo, um tamanho de chave ou uma versão de protocolo em uma janela de mudança controlada, usando configuração e automação que já existem, e consegue comprovar depois o que está em uso. O teste é operacional, não teórico. Se mudar um grupo de troca de chaves exige editar código-fonte, reconstruir uma imagem de contêiner, renegociar com um fornecedor ou descobrir dependências não documentadas, o sistema não é ágil, seja o que for que sua documentação afirme.

Vale a pena ter em mente três distinções:

• Agilidade não é o mesmo que prontidão pós-quântica. A criptografia pós-quântica (PQC) é um destino. A agilidade é o veículo. Um servidor que oferece hoje uma troca de chaves híbrida pós-quântica, mas não consegue alterá-la no ano que vem, resolveu uma migração e não se preparou para nenhuma outra.
• Agilidade não é apenas negociação. O Transport Layer Security (TLS) negocia. Formatos de dados armazenados, firmware assinado, módulos de segurança de hardware (HSMs), terminais de pagamento e dispositivos embarcados frequentemente não negociam. É nesses pontos que a agilidade precisa ser projetada, e não apenas configurada.
• A agilidade tem uma ordem de prioridade. Colher agora, decifrar depois (harvest now, decrypt later, HNDL) descreve o tráfego gravado que um adversário guarda até que a decifração se torne possível. As sessões gravadas são protegidas apenas pela troca de chaves, e é por isso que o estabelecimento de chaves migra primeiro e as assinaturas podem vir depois. Nosso artigo sobre harvest now, decrypt later explica essa ordem em detalhes.

Configuração em vez de código, negociação em vez de valores fixos

A primeira propriedade é que a seleção de algoritmos fica em uma configuração sob responsabilidade de um operador, em um único lugar por host ou por serviço, e é revisada como qualquer outro controle. Uma política criptográfica centralizada é melhor do que flags por aplicação, porque flags por aplicação são justamente o que acaba esquecido.

TLS: grupos nomeados e uma lista de preferência ordenada

No TLS 1.3, a troca de chaves é um grupo nomeado, negociado a cada conexão. O registro da Internet Assigned Numbers Authority (IANA) lista os grupos híbridos X25519MLKEM768 (codepoint 0x11EC), SecP256r1MLKEM768 (0x11EB) e SecP384r1MLKEM1024 (0x11ED), ao lado dos grupos ML-KEM puros (parâmetros TLS da IANA). O ML-KEM é o mecanismo de encapsulamento de chaves (KEM) padronizado pelo NIST no FIPS 203 em 13 de agosto de 2024. O RFC 10024 (agosto de 2026) especifica o acordo de chaves híbrido pós-quântico e tradicional para o TLS 1.3.

Uma configuração ágil declara uma preferência ordenada e mantém um fallback clássico, para que um cliente que não suporta o grupo híbrido ainda consiga se conectar. O OpenSSL 3.5 ou posterior é necessário para os grupos ML-KEM:

# /etc/ssl/openssl.cnf (OpenSSL 3.5 or later)
openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Groups = X25519MLKEM768:X25519:P-256
MinProtocol = TLSv1.2

Verifique de fora, antes e depois de qualquer mudança, com um teste somente leitura:

# read-only test: does the server accept the hybrid group?
openssl s_client -groups X25519MLKEM768 -connect example.com:443 < /dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Na camada do servidor web, a mesma preferência é uma única diretiva, por exemplo ssl_ecdh_curve X25519MLKEM768:X25519; no nginx compilado com um OpenSSL adequado. Nosso guia para habilitar o ML-KEM no nginx, Apache, HAProxy e Caddy apresenta a sintaxe de cada produto e as versões mínimas. Teste primeiro em homologação e mantenha o grupo de fallback.

SSH: o mesmo padrão, já entregue

O OpenSSH é um bom modelo de agilidade na prática. A versão 9.0 (8 de abril de 2022) tornou padrão uma troca de chaves híbrida. A versão 9.9 (19 de setembro de 2024) adicionou mlkem768x25519-sha256. A versão 10.0 (9 de abril de 2025) o tornou o acordo de chaves padrão, e a 10.1 (6 de outubro de 2025) emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico, por meio de WarnWeakCrypto, habilitado por padrão (notas de versão do OpenSSH). Os operadores que haviam expressado preferências na configuração herdaram a mudança; os que haviam fixado um único algoritmo em scripts, não.

# list what this client supports, then set an ordered preference
ssh -Q kex

# /etc/ssh/sshd_config (OpenSSH 9.9 or later), classical fallback last
KexAlgorithms mlkem768x25519-sha256,sntrup761x25519-sha512@openssh.com,curve25519-sha256

Inventário, abstração e automação

Um inventário que se pode consultar, não uma planilha que se reescreve

Não é possível mudar o que não se consegue listar. Um inventário justifica sua existência quando responde a uma pergunta em minutos: quais serviços ainda negociam uma troca de chaves apenas clássica, quais certificados usam qual algoritmo de assinatura, quais bibliotecas fornecem as primitivas e quem é o responsável por cada um. Registre no mínimo o ativo, o protocolo e a versão, os algoritmos e tamanhos de chave, a finalidade, o responsável, a versão da biblioteca ou do módulo e o mecanismo de renovação. Uma lista de materiais criptográficos (CBOM) é uma forma legível por máquina de manter essas informações; veja o que é um CBOM. Trate o CBOM como uma prática que sugerimos, e não como uma exigência legal.

Camadas de abstração que ocultam o algoritmo

O código da aplicação deve solicitar uma capacidade, não um nome. Quatro padrões concentram a maior parte do benefício:

• Faça as chamadas por meio de um provider ou de uma biblioteca interna enxuta. Um único módulo traduz a política em primitivas, de modo que uma única mudança se propaga.
• Versione todo formato armazenado. Prefixe textos cifrados, tokens e envelopes assinados com um identificador de algoritmo e uma versão de formato, para que os dados antigos continuem legíveis enquanto os novos usam o novo algoritmo.
• Nunca presuma tamanhos. As chaves públicas e os textos cifrados do ML-KEM, assim como as assinaturas do ML-DSA, são consideravelmente maiores do que seus equivalentes em curvas elípticas. Colunas de banco de dados de tamanho fixo, buffers fixos, limites de tamanho de mensagem e campos de protocolo dimensionados para chaves de 32 bytes são o bloqueio rígido mais comum. Prefira campos com prefixo de comprimento.
• Mantenha um caminho de verificação duplo. Aceite e verifique tanto o algoritmo antigo quanto o novo durante a transição e, depois, remova o antigo seguindo um cronograma com datas definidas.

Chaves e certificados que se renovam sem intervenção humana

Uma rotação feita manualmente uma vez por ano não é um controle, é um ensaio no qual você vai falhar. Emissão e renovação automatizadas, certificados de curta validade e um alerta para certificados não renovados são o que torna rotineira uma troca de algoritmo: quando o algoritmo de assinatura muda, o pipeline simplesmente emite certificados diferentes. Os exercícios de rotação devem constar do calendário de mudanças. As assinaturas baseadas em hash com estado (LMS e XMSS, padronizadas no NIST SP 800-208) são a exceção que confirma a regra: o gerenciamento de estado delas torna insegura a duplicação ingênua de uma chave de assinatura, por isso exigem um gerenciamento de chaves deliberado, e não uma automação genérica.

Onde a regulação exige agilidade, e quais evidências são adequadas

Vários textos exigem essa capacidade sem usar a expressão. A tabela separa o que cada texto diz literalmente da forma como sugerimos evidenciá-lo. Trata-se de informação, não de aconselhamento jurídico: confirme suas próprias obrigações com seu assessor jurídico ou com seu supervisor.

Leia a redação exata no Regulamento (EU) 2024/1774 e consulte nossas páginas sobre o DORA e o PCI DSS v4.0.1 para conhecer os marcos com datas. Mantenha as ressalvas corretas: o EU Coordinated Implementation Roadmap v1.1 é uma orientação coordenada para os Estados-Membros, e não um regulamento que vincule empresas; a BSI TR-02102-1 é uma diretriz técnica; a ANSSI declara que suas recomendações pós-quânticas ainda não são obrigações regulatórias fora de seu escopo regulado; e o NIST IR 8547 continua sendo um rascunho público inicial.

Armadilhas que anulam a agilidade silenciosamente

• Fixar um único algoritmo no código ou em scripts em vez de expressar uma preferência ordenada na configuração.
• Remover o fallback clássico cedo demais. Mantenha o X25519 depois do X25519MLKEM768 até que sua base de clientes tenha sido medida.
• Manter grupos obsoletos anteriores à padronização. Os grupos TLS do rascunho Kyber estão obsoletos: migre para o X25519MLKEM768 e os demais híbridos registrados.
• Um inventário sem responsáveis. Uma lista pela qual ninguém responde não gera mudança.
• Esquecer os artefatos de longa duração: firmware assinado, assinaturas de documentos, backups e dados arquivados sobrevivem aos sistemas que os criaram.

Meça o que seus sistemas negociam hoje

A agilidade começa com uma linha de base honesta, e a parte visível externamente é rápida de obter: analise seu domínio com o PQC Status para ver quais versões de TLS, cipher suites, grupos de troca de chaves e algoritmos de certificado o seu servidor realmente negocia. Uma análise descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade, como explica nossa página de metodologia. O próximo passo concreto é pegar esse resultado, registrar cada serviço no seu inventário criptográfico com um responsável e, em seguida, mover a seleção de algoritmos de um serviço para a configuração central e ensaiar sua mudança em homologação.