Migrar a assinatura de código para ML-DSA: um plano prático

A assinatura de código segue um relógio diferente do TLS. O tráfego gravado é protegido apenas pela troca de chaves, e é por isso que, nesse caso, o ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) híbrido vem primeiro. Uma assinatura só precisa resistir à falsificação enquanto sua âncora de confiança estiver ativa, mas o verificador que a confere pode permanecer em um bootloader por uma década, e não é possível corrigir um verificador com uma atualização que esse próprio verificador não consegue verificar. É esse prazo de preparação, e não a urgência da ameaça, que explica por que os cronogramas oficiais colocam a assinatura de software e firmware no início: o NSA CNSA 2.0 (Commercial National Security Algorithm Suite 2.0) exige o uso exclusivo de ML-DSA-87 ou LMS/XMSS para assinatura de software e firmware até o final de 2030 nos US National Security Systems, três anos antes de navegadores, servidores, serviços em nuvem e sistemas operacionais.

Por que os prazos de assinatura chegam antes dos prazos de troca de chaves

O cenário “harvest now, decrypt later” (coletar agora, decifrar depois) não se aplica a assinaturas. Ninguém consegue gravar uma assinatura hoje e, a partir dela, falsificar uma nova mais tarde. A exposição é outra: um atacante com capacidade quântica que consiga recuperar uma chave privada de assinatura a partir de sua chave pública poderia assinar firmware em que sua base instalada ainda confia. A mitigação consiste em levar um verificador pós-quântico a essa base instalada muito antes de a chave se tornar falsificável, e bases instaladas evoluem devagar.

Três características fazem da assinatura o item de maior prazo. Primeiro, os verificadores estão em toda parte e muitas vezes são imutáveis: estágios de boot em ROM, elementos seguros, ferramentas de provisionamento isoladas da rede, appliances de clientes, instaladores offline. Segundo, as âncoras de confiança são embarcadas, de modo que mudar de algoritmo significa distribuir novas chaves públicas por um canal que, ele próprio, é assinado. Terceiro, a última atualização que um dispositivo aceita sob o algoritmo antigo é a que precisa ensiná-lo o novo; assim, um dispositivo retirado do seu pipeline de atualização antes desse ponto permanece clássico para sempre. Planeje essa decisão de fim de vida de forma explícita, em vez de descobri-la em 2030.

Nada disso exige uma previsão sobre quando existirá um computador quântico criptograficamente relevante. As datas abaixo vêm de políticas e orientações publicadas, e são elas que o roadmap da sua engenharia de releases precisa cumprir.

ML-DSA, SLH-DSA, LMS e XMSS: a escolha por caso de uso

O NIST publicou o FIPS 204 (ML-DSA, Module-Lattice-Based Digital Signature Algorithm) e o FIPS 205 (SLH-DSA, Stateless Hash-Based Digital Signature Algorithm) como padrões finais em 13/08/2024 (FIPS 204, FIPS 205). Os esquemas baseados em hash com estado LMS e XMSS são aprovados pela NIST SP 800-208. O CNSA 2.0 indica ML-DSA-87 e LMS/XMSS para assinatura de software e firmware, com SHA-384 ou SHA-512 para hashing.

Para a maioria dos pipelines de release, o ML-DSA é o padrão, porque não tem estado e, portanto, pode ser executado com segurança em um sistema de CI distribuído com vários signatários. Os esquemas com estado são atraentes para bootloaders restritos, mas a regra operacional não perdoa: o estado do signatário nunca pode ser duplicado, o que exclui snapshots comuns de máquinas virtuais, clones em warm standby e a restauração de backup de um host de assinatura. Se você não puder garantir isso no seu ambiente, escolha um esquema sem estado.

O tamanho importa de uma forma que não importava com o ECDSA. Chaves públicas e assinaturas pós-quânticas são substancialmente maiores, e as assinaturas SLH-DSA são maiores ainda. Consulte as tabelas de parâmetros do FIPS 204 e do FIPS 205 antes de dimensionar um campo de assinatura em um cabeçalho de firmware, uma partição de flash, um esquema de manifesto ou um orçamento de atualização over-the-air. Um campo de assinatura de largura fixa em um formato de imagem existente é um bloqueio comum, e trata-se de uma mudança de formato, não de uma mudança de criptografia.

Verificador primeiro: a ordem de atualização que não pode ser invertida

A sequência abaixo é o plano completo. As etapas 2 e 3 precisam estar concluídas em toda a frota antes do início da etapa 5.

1. Inventarie os verificadores, não apenas os signatários. Liste todos os pontos em que uma assinatura é verificada: bootloaders, elementos seguros, gerenciadores de pacotes, frameworks de instalação, agentes de atualização, admission controllers, ferramentas de provisionamento, scripts de validação de parceiros. Registre quais deles você pode atualizar, por qual canal, e quais estão congelados.
2. Adicione a verificação pós-quântica sem deixar de aceitar o algoritmo clássico. O novo verificador deve ser tolerante: aceitar assinaturas antigas, aceitar as novas e registrar qual delas encontrou.
3. Distribua esse verificador pelo caminho existente, assinado de forma clássica, e depois distribua as novas âncoras de confiança. Meça a cobertura com telemetria real, por dispositivo e por versão, e não por suposição.
4. Registre as chaves de assinatura em hardware e execute de ponta a ponta um pipeline de assinatura paralelo, fora de produção, incluindo revogação e carimbo de tempo.
5. Inicie a dupla assinatura dos artefatos de produção quando o verificador tolerante representar a grande maioria.
6. Exija assinaturas pós-quânticas somente quando a telemetria mostrar que os verificadores antigos desapareceram, com uma decisão por escrito para os retardatários: suporte estendido, substituição em campo ou fim de vida documentado.
7. Remova a assinatura clássica por último, e mantenha a capacidade de reassinar artefatos arquivados para que releases antigos continuem verificáveis sob o novo esquema.

Dupla assinatura: os dois modos e a armadilha

Dupla assinatura significa anexar duas assinaturas independentes (uma clássica, uma pós-quântica) ao mesmo artefato, geralmente em um formato de contêiner que suporta vários slots de assinatura. Verifique se o seu formato suporta isso antes de projetar qualquer outra coisa: alguns formatos permitem vários signatários nativamente, outros exigem uma assinatura destacada fora de banda ou uma revisão do formato.

A decisão de design que importa é a política de verificação. No modo permissivo, o verificador aceita o artefato se qualquer uma das assinaturas for válida, o que mantém os clientes antigos funcionando, mas significa que sua segurança efetiva é a do mais fraco dos dois algoritmos. No modo estrito, o verificador exige ambas, o que aumenta a segurança, mas cria um risco de disponibilidade: um único erro em qualquer um dos pipelines bloqueia todos os releases. O caminho habitual é o modo permissivo durante a implantação, o estrito quando a frota estiver pronta e, depois, apenas pós-quântico. Documente a política por classe de verificador e por tipo de artefato, e torne explícitas as datas de transição; esse é exatamente o tipo de mudança planejada de algoritmo que a cripto-agilidade deveria tornar rotineira.

Suporte em HSM, PKI e ferramentas: o que verificar, sem presumir

O suporte a assinaturas pós-quânticas avança rapidamente em módulos de segurança de hardware, autoridades certificadoras e ferramentas de assinatura, e os requisitos de versão variam entre produtos e até entre branches de firmware do mesmo produto. Não trate um post no blog de um fornecedor como um compromisso. Peça as notas de release e o registro de validação, e teste em staging. Os itens abaixo são as perguntas a formalizar por escrito:

• O firmware do HSM implementa ML-DSA, com quais conjuntos de parâmetros, e existe uma versão validada FIPS 140-3 ou um roadmap datado para uma? Se o CNSA 2.0 se aplica a você, o conjunto de parâmetros relevante é o ML-DSA-87.
• A função está acessível pela interface que seu pipeline usa (mecanismo PKCS#11, tipos de objeto KMIP, API de KMS em nuvem, SDK do fornecedor), e as chaves podem ser geradas em hardware sem nunca serem exportadas?
• Para LMS ou XMSS: a geração de chaves e o avanço de estado são realizados dentro do módulo criptográfico, sem nenhum mecanismo capaz de duplicar o estado, como exige a SP 800-208?
• Sua autoridade certificadora consegue emitir certificados com chaves de titular pós-quânticas e assinar dados de revogação que seus verificadores aceitarão? As hierarquias podem precisar de uma cadeia pós-quântica paralela, em vez de uma alteração no local.
• Sua autoridade de carimbo de tempo suporta o novo algoritmo, para que as assinaturas continuem verificáveis após a expiração do certificado?
• Suas ferramentas de assinatura e transparência de artefatos, sistemas de build de pacotes e bibliotecas de verificação suportam o algoritmo nas versões exatas que você implanta? O OpenSSL, por exemplo, exige a versão 3.5 ou posterior para os grupos TLS ML-KEM; para o suporte a assinaturas, consulte as notas de release da versão específica que você distribui, tanto no ambiente de assinatura quanto no de verificação.
• Throughput e latência: assinaturas maiores e novos caminhos de código alteram o tempo de assinatura por artefato e o tamanho dos downloads. Faça benchmarks com o seu volume real de releases.

As datas para o planejamento

O conteúdo a seguir é informativo e não constitui aconselhamento jurídico. O status importa tanto quanto a data: um rascunho não é um padrão, e uma orientação aos Estados-Membros não é uma obrigação para as empresas.

Fontes primárias: OMB M-26-15, o EU Coordinated Implementation Roadmap, a FAQ de PQC da ANSSI, os cronogramas de migração do UK NCSC e o NIST IR 8547 ipd. Para o CNSA 2.0, as fontes publicadas são a CNSA 2.0 FAQ v2.1 (dezembro de 2024) e o comunicado CNSA 2.0 Algorithms (30/05/2025).

Os fabricantes de produtos também devem observar que o Cyber Resilience Act, Regulation (EU) 2024/2847, Annex I, Part I (2)(e) exige a proteção da confidencialidade por mecanismos de última geração e não menciona algoritmos pós-quânticos; suas obrigações de notificação se aplicam a partir de 11/09/2026 e ele se aplica integralmente a partir de 11/12/2027 (EUR-Lex). Trate a atualização segura e a verificação de assinaturas como parte desse argumento de estado da arte, e mantenha o inventário de chaves de assinatura no mesmo registro que o restante da sua criptografia.

Comece pelo que você pode medir hoje

A migração da assinatura é um programa de frota de vários anos, então comece pelas duas ações de baixo custo: uma lista de todos os verificadores sob sua responsabilidade, com seu canal de atualização, e um pipeline de assinatura em staging que produza de ponta a ponta um artefato com dupla assinatura. Em paralelo, confirme que o lado do transporte já utiliza troca de chaves híbrida, pois é ali que o tráfego gravado está em jogo e onde a correção é uma mudança de configuração, e não uma implantação em toda a frota. Você pode analisar seu domínio com o PQC Status para verificar se seus hosts de release, atualização e artefatos negociam X25519MLKEM768, quais versões de TLS e cipher suites oferecem e como é sua cadeia de certificados. A análise descreve apenas a configuração TLS visível externamente: não é uma certificação e não inspeciona seu pipeline de assinatura de código, portanto combine-a com o inventário de verificadores descrito acima.