Requisitos de criptografia do CRA para fabricantes de produtos

O Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) define seu requisito de criptografia no Annex I, Part I (2)(e): proteger a confidencialidade dos dados armazenados, transmitidos ou tratados de outra forma, por exemplo criptografando os dados relevantes em repouso ou em trânsito por meio de mecanismos de última geração (state of the art). O texto não cita algoritmos pós-quânticos. As obrigações de notificação previstas no Article 14 se aplicam a partir de 11 de setembro de 2026 e o regulamento se aplica integralmente a partir de 11 de dezembro de 2027. Por isso, as equipes de produto estão escolhendo agora a criptografia de dispositivos que continuarão recebendo suporte muito depois dessas datas.

O que o requisito diz, e o que não diz

O Annex I tem duas partes. A Part I lista os requisitos essenciais de cibersegurança do próprio produto, entre eles ser colocado no mercado sem vulnerabilidades exploráveis conhecidas, ter uma configuração segura por padrão e o requisito de confidencialidade do item (2)(e). A Part II lista os requisitos de tratamento de vulnerabilidades que valem durante todo o período de suporte declarado pelo fabricante. O texto está disponível no EUR-Lex (Regulation (EU) 2024/2847) e nosso resumo datado está na página sobre o regulamento CRA.

Disso decorrem três consequências para uma equipe de produto:

• O requisito é orientado a resultados. Ele cita a confidencialidade e mecanismos de última geração, não RSA, não ECDH, não ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, padronizado no NIST FIPS 203).
• A referência evolui. Um mecanismo defensável na avaliação de conformidade pode deixar de sê-lo enquanto o produto ainda recebe suporte.
• Nada no texto obriga você a entregar criptografia pós-quântica hoje. Da mesma forma, nada salva um projeto cuja criptografia não possa ser alterada quando o estado da arte evoluir.

Normas harmonizadas poderão detalhar futuramente como atender ao Annex I, e a conformidade com uma norma harmonizada publicada no Jornal Oficial da União Europeia confere presunção de conformidade. Enquanto essa norma não existir nem for publicada, seu conteúdo é desconhecido: não planeje com base em suposições sobre o que ela dirá a respeito de criptografia. O conteúdo jurídico aqui apresentado é informativo e não constitui aconselhamento jurídico.

As datas do calendário do CRA

Para um dispositivo com período de suporte de vários anos, o horizonte de planejamento não é 2027. É a última data em que você ainda deve atualizações de segurança para as unidades vendidas pouco antes do fim do suporte.

O que o estado da arte pode razoavelmente significar ao longo de um período de suporte

O CRA não publica uma lista de algoritmos. A forma honesta de raciocinar sobre o estado da arte é, portanto, observar o que autoridades públicas e organismos de normalização efetivamente publicaram, preservando o status de cada documento.

Fontes primárias: o roteiro da UE, a BSI TR-02102-1, o FAQ PQC da ANSSI, o NIST IR 8547 ipd e os prazos de migração do NCSC.

Nossa interpretação, claramente identificada como tal: nenhum desses textos torna a criptografia pós-quântica uma obrigação do CRA, e nenhuma autoridade afirmou que a criptografia clássica deixa de atender ao Annex I hoje. Porém, um produto cujo período de suporte se estende além de 2030 está sendo vendido para um período em que várias autoridades já publicaram datas para aposentar o estabelecimento de chaves clássico. A posição de engenharia defensável é, portanto, a agilidade: a capacidade de trocar algoritmos por meio de uma atualização normal, comprovada no dossiê de projeto.

Agilidade criptográfica no firmware

A agilidade é uma propriedade da implementação, não uma frase em uma política. Quatro perguntas determinam se um dispositivo já entregue consegue acompanhar o estado da arte, e é mais fácil respondê-las antes do tape-out do que depois. Tratamos o tema em profundidade no artigo sobre agilidade criptográfica.

• Negociação, não constantes. Identificadores de algoritmo, grupos nomeados e tamanhos de chave vêm da configuração ou do handshake do protocolo, nunca de uma constante compilada ou de um buffer de tamanho fixo. As chaves e os textos cifrados do ML-KEM são muito maiores que os valores de curvas elípticas, então uma struct dimensionada para chaves de 32 bytes é um bloqueio no nível do hardware.
• Margem. Reserve flash, RAM e tempo de handshake para material de chave maior. Meça no dispositivo-alvo, não em uma estação de trabalho.
• Fronteira da biblioteca. Chame a criptografia por meio de uma interface interna enxuta, para que o provedor possa ser substituído. Fixe a versão mínima no build: os grupos TLS com ML-KEM exigem OpenSSL 3.5 ou superior.
• Fallback clássico. Prefira o estabelecimento de chaves híbrido e mantenha um grupo clássico como alternativa, para que o dispositivo continue se conectando quando a outra ponta for mais antiga.

Em um build de teste, verifique o que a pilha realmente consegue oferecer e o que um endpoint do dispositivo negocia:

openssl version
# ML-KEM TLS groups require OpenSSL 3.5 or later
openssl list -tls-groups

# read-only test against a device endpoint, hybrid first, classical fallback
openssl s_client -connect device.example.com:443 -tls1_3 \
  -groups X25519MLKEM768:X25519 </dev/null

O grupo híbrido a preferir hoje é o X25519MLKEM768 (codepoint IANA 0x11EC), com SecP256r1MLKEM768 ou SecP384r1MLKEM1024 quando uma curva NIST for exigida; o perfil da IETF para acordo de chaves híbrido pós-quântico e tradicional no TLS 1.3 é o RFC 10024 (agosto de 2026). Os grupos de rascunho Kyber pré-padronização, como X25519Kyber768Draft00, estão obsoletos e devem ser removidos do firmware dos dispositivos. Teste em homologação antes da produção e mantenha o grupo clássico na lista.

Os planos de gerenciamento dos dispositivos merecem a mesma revisão. O OpenSSH 9.9 adicionou mlkem768x25519-sha256, o OpenSSH 10.0 o tornou o acordo de chaves padrão e o OpenSSH 10.1 emite um aviso quando uma conexão negocia um acordo de chaves não pós-quântico, conforme as notas de versão do OpenSSH.

Assinatura de atualizações: a parte que você não poderá corrigir depois

As chaves de transporte são renovadas a cada sessão. Uma raiz de confiança gravada no silício, não. O tráfego gravado é protegido apenas pela troca de chaves, e é por isso que o estabelecimento de chaves híbrido vem primeiro, enquanto as assinaturas podem migrar depois; mas a assinatura de atualizações é o único caminho de assinatura em que uma migração tardia pode ser impossível, porque o verificador fica em código de boot imutável.

Medidas práticas, em ordem de valor:

1. Prever mais de um slot de verificação ou hierarquia de chaves, para que um novo algoritmo de assinatura possa ser introduzido por atualização e não por recall.
2. Decidir agora qual família de assinatura pós-quântica o produto poderá aceitar: ML-DSA (FIPS 204), SLH-DSA (FIPS 205) ou os esquemas baseados em hash com estado LMS e XMSS do NIST SP 800-208, que exigem gerenciamento rigoroso de estado para evitar a reutilização de uma chave de uso único.
3. Manter o código e os parâmetros de verificação de assinatura em um estágio atualizável, quando o modelo de segurança permitir, limitando o estágio imutável à verificação desse estágio atualizável.
4. Documentar a rotação de chaves: quem detém as chaves, como uma chave comprometida ou descontinuada é aposentada e como um dispositivo em campo toma conhecimento da nova chave.

O CNSA 2.0 já define o fim de 2030 para o uso exclusivo de seus algoritmos na assinatura de software e firmware dos National Security Systems dos EUA. Isso não é uma obrigação da UE, mas é uma data publicada para o mesmo problema de engenharia, e constitui um insumo razoável quando você argumenta o que significa estado da arte para um produto com suporte além de 2030.

Associando o requisito a evidências

Próximo passo: medir o que seu produto expõe na rede

Antes de escrever uma única linha de documentação do CRA, descubra o que seus próprios endpoints e servidores de atualização realmente negociam hoje. Você pode analisar seu domínio com o PQC Status gratuitamente para ver as versões de TLS, os grupos híbridos ML-KEM, as cipher suites e a cadeia de certificados que um cliente externo observa. Uma análise 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 e, em seguida, avance para o firmware: tamanhos de chave nas structs, versões de bibliotecas no build e o número de slots de verificação na sua cadeia de boot.