BSI TR-02102-1 e criptografia pós-quântica: as recomendações de 2026

A BSI TR-02102-1 é a diretriz técnica sobre mecanismos criptográficos publicada pelo Escritório Federal Alemão de Segurança da Informação (BSI, Bundesamt für Sicherheit in der Informationstechnik). A versão 2026-01, datada de 23 de janeiro de 2026, recomenda o acordo de chaves pós-quântico híbrido, considera o acordo de chaves clássico usado isoladamente como recomendado apenas até o fim de 2031 (fim de 2030 quando as necessidades de proteção são muito altas) e estabelece chaves RSA de pelo menos 3000 bits. Trata-se de uma diretriz técnica, não de uma lei, e este artigo mostra como transformar esses três pontos em uma configuração TLS que você pode testar.

O que a TR-02102-1 é, e o que ela não é

A TR-02102-1 lista os mecanismos criptográficos que o BSI considera adequados, cada um com tamanhos de chave e um horizonte temporal associados. É uma orientação. Por si só, não cria nenhuma obrigação para uma empresa privada. Ela só se torna vinculante quando outro instrumento a torna vinculante: um contrato com um cliente alemão, uma regra setorial, um requisito de compra pública ou uma política criptográfica interna que a cite. Esta última frase é a nossa leitura de como o documento é usado na prática, não uma citação da diretriz.

Daí decorrem duas consequências para equipes que atendem clientes alemães. Primeiro, cite sempre a versão. Todos os números deste artigo vêm da versão 2026-01, e você deve citá-los novamente a partir da versão em vigor no momento da sua auditoria. Segundo, um questionário de fornecedor que pergunta se você está em conformidade com a TR-02102-1 está, na verdade, perguntando se a sua configuração implantada corresponde aos mecanismos recomendados e aos seus horizontes. Os marcos datados estão resumidos na nossa página de referência sobre a BSI TR-02102-1, e a própria diretriz é publicada pelo BSI em PDF: BSI TR-02102-1.

A posição da versão 2026-01 sobre acordo de chaves

A diretriz recomenda o acordo de chaves pós-quântico híbrido. Híbrido significa combinar um acordo de chaves clássico, como o Diffie-Hellman em curvas elípticas (ECDH), com um mecanismo de encapsulamento de chaves (KEM) pós-quântico, de modo que a chave de sessão permaneça segura se qualquer um dos componentes resistir. No TLS 1.3, o componente pós-quântico em produção hoje é o ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), padronizado pelo NIST como FIPS 203 em 13 de agosto de 2024.

Duas datas importam. O acordo de chaves clássico usado isoladamente é recomendado apenas até o fim de 2031. Quando as necessidades de proteção são muito altas, isso passa a ser o fim de 2030. São recomendações com um horizonte, não uma data de desativação imposta por um regulador.

O acordo de chaves vem primeiro por uma razão física, não regulatória. O tráfego TLS gravado é protegido apenas pela troca de chaves que gerou as suas chaves de sessão. Um atacante que armazena texto cifrado hoje pode decifrá-lo mais tarde se a troca de chaves se tornar quebrável, um padrão conhecido como harvest now, decrypt later (HNDL). Assinaturas e certificados não têm essa propriedade: uma assinatura verificada hoje não pode ser forjada retroativamente. É por isso que o horizonte do acordo de chaves chega antes de qualquer migração de assinaturas.

RSA de pelo menos 3000 bits, e o que isso não garante

A versão 2026-01 define um tamanho mínimo de chave RSA de 3000 bits. Na prática, autoridades certificadoras, módulos de segurança de hardware e bibliotecas TLS trabalham com chaves RSA de 3072 bits, que atendem ao limite e são amplamente suportadas. Verificar o tamanho da chave de um certificado implantado leva um único comando.

openssl x509 -in server.crt -noout -text | grep -i public-key

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out server.key
openssl req -new -key server.key -out server.csr

Seja preciso sobre o que isso alcança. Uma chave RSA mais longa eleva o nível de segurança clássico. Ela não torna a chave resistente a computadores quânticos: RSA, ECDSA, EdDSA, ECDH, Diffie-Hellman em corpos finitos e DSA são todos quebrados pelo algoritmo de Shor em um computador quântico suficientemente grande, qualquer que seja o tamanho da chave. O mínimo de 3000 bits e a recomendação de acordo de chaves híbrido respondem a dois problemas diferentes, e atender a um não satisfaz o outro.

Para comparação, o NIST IR 8547 propõe descontinuar os algoritmos vulneráveis à computação quântica no nível de segurança de 112 bits, o que inclui o RSA-2048, após 2030, e proibir todos os algoritmos de chave pública vulneráveis à computação quântica após 2035. Esse documento é um rascunho público inicial publicado em 12 de novembro de 2024 e continua sendo um rascunho: NIST IR 8547 (ipd). Um mínimo alemão de 3000 bits e uma proposta de descontinuação americana, ainda em rascunho, das chaves de 2048 bits apontam na mesma direção, a partir de dois textos diferentes com dois status diferentes.

Traduzindo a recomendação em uma configuração TLS

A diretriz recomenda um mecanismo, o acordo de chaves híbrido. A escolha do grupo TLS 1.3 concreto é uma decisão de implementação, e o que se segue é o nosso mapeamento prático, não uma citação. Os grupos híbridos registrados na IANA são X25519MLKEM768 (codepoint 0x11EC, 4588), SecP256r1MLKEM768 (0x11EB, 4587) e SecP384r1MLKEM1024 (0x11ED, 4589), listados no registro de parâmetros TLS da IANA. O seu uso no TLS 1.3 é descrito na RFC 10024 (agosto de 2026). As versões atuais do Chrome, do Edge e do Firefox já oferecem X25519MLKEM768 por padrão, portanto habilitá-lo no lado do servidor muda imediatamente o que os navegadores reais negociam.

Etapa 1: confirme que a biblioteca suporta os grupos

O OpenSSL 3.5 ou posterior é necessário para os grupos TLS ML-KEM no OpenSSL. Verifique antes de mexer em qualquer configuração de servidor.

openssl version
openssl list -tls-groups | grep -i mlkem

Etapa 2: ofereça o grupo híbrido primeiro e mantenha um fallback clássico

A ordem importa: o grupo híbrido vem primeiro, e os grupos clássicos ficam atrás dele para que clientes mais antigos continuem se conectando. Nunca remova o fallback clássico na mesma alteração.

# nginx, built against OpenSSL 3.5 or later
ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

# Apache httpd with mod_ssl, OpenSSL 3.5 or later
SSLProtocol -all +TLSv1.2 +TLSv1.3
SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1

Os nomes das diretivas e o suporte variam entre distribuições e entre builds da mesma versão de servidor, portanto verifique no seu próprio pacote em vez de presumir. Receitas completas para nginx, Apache, HAProxy e Caddy estão no nosso guia para habilitar o ML-KEM nos servidores web mais comuns. Teste em homologação antes da produção.

Etapa 3: verifique o que é realmente negociado

openssl s_client -connect example.de:443 -tls1_3 -groups X25519MLKEM768 </dev/null | grep -i negotiated

Um handshake bem-sucedido exibe o grupo negociado. Repita o mesmo teste sem o grupo híbrido para confirmar que os clientes clássicos continuam se conectando.

Como o horizonte alemão se compara a outros cronogramas

As datas alemãs não existem isoladamente. Se você atende clientes em vários países, o horizonte aplicável mais próximo determina o plano.

Evidências que um cliente ou auditor alemão vai solicitar

A NIS2, Diretiva (EU) 2022/2555, Artigo 21(2)(h), exige políticas e procedimentos relativos ao uso de criptografia e, quando apropriado, de cifração. Para entidades financeiras, as normas técnicas regulamentares da DORA, Regulamento Delegado (EU) 2024/1774 da Comissão, Artigo 6, exigem uma política de cifração e de controles criptográficos que inclua disposições para atualizar ou alterar a tecnologia criptográfica com base na evolução da criptoanálise. Nenhum dos dois textos menciona algoritmos pós-quânticos.

A nossa interpretação, claramente identificada como tal: citar a TR-02102-1 e a sua versão nessa política, com os mecanismos que você aceita e o horizonte que aplica, é uma forma prática de mostrar que a política está ancorada em uma referência reconhecida e possui um gatilho de revisão. Mantenha os artefatos simples e datados: a própria política, um inventário dos endpoints TLS com os seus grupos negociados e tamanhos de chave dos certificados, e um resultado de varredura por endpoint. A nossa página sobre o Artigo 21(2)(h) da NIS2 detalha o que a diretiva exige. Este artigo é informativo e não constitui aconselhamento jurídico.

Próximo passo: verifique o que os seus servidores negociam hoje

Antes de redigir qualquer plano, meça o estado atual. Analise o seu domínio com o PQC Status para ver quais versões de TLS, grupos de acordo de chaves e algoritmos de certificado o seu servidor realmente oferece, incluindo se um grupo híbrido ML-KEM é negociado. Uma varredura descreve apenas a configuração TLS visível externamente: não é uma certificação nem um atestado de conformidade. Use o resultado como a primeira linha do seu inventário, depois habilite o grupo híbrido em homologação, mantenha o fallback clássico e registre o antes e o depois de cada endpoint.