Capítulo 28 — Segurança quântica e pós-quântica: implementação I
Mapa da aula
Aula 28 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["28.1 Seleção de bibliotecas"]
N1["28.2 Integração por provedores"]
N2["28.3 Identificadores e codificações"]
N3["28.4 Assinaturas com estado"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["28.1 Seleção de bibliotecas"]
N1["28.2 Integração por provedores"]
N2["28.3 Identificadores e codificações"]
N3["28.4 Assinaturas com estado"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX055"]
[28.1 Seleção de bibliotecas]
|
v
[28.2 Integração por provedores]
|
v
[28.3 Identificadores e codificações]
|
v
[28.4 Assinaturas com estado]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) selecionar bibliotecas verificadas e módulos validados; (2) integrar o ML-KEM e o ML-DSA por meio de interfaces de provedores; (3) tratar codificações, identificadores e interoperabilidade; e (4) implementar com segurança a gestão de assinaturas com estado. O capítulo parte dos Capítulos 9, 14 e 27.
28.1 Seleção de bibliotecas
Use implementações mantidas e revisadas, com código em tempo constante, vetores de teste e, quando exigido, validação no Cryptographic Module Validation Program (CMVP) do NIST. Prefira bibliotecas que implementem as versões finais das FIPS, e não o Kyber/Dilithium de rascunho. Registre no CBOM a biblioteca, a versão e os identificadores de algoritmo.
A validação no CMVP leva tempo, então uma biblioteca pode suportar bem o ML-KEM muito antes de a sua versão validada estar disponível. A política da BPA aceita bibliotecas não validadas em pilotos e exige módulos validados em produção nos sistemas regulados, com as datas acompanhadas no plano.
28.2 Integração por provedores
A maioria das plataformas expõe a criptografia por meio de provedores (provedores do OpenSSL, provedores de segurança do Java, PKCS#11 para HSMs). Integre a PQC acrescentando ou atualizando provedores e configurando os nomes dos algoritmos pela política. As aplicações que chamam interfaces genéricas (Capítulo 9) não precisam de mudanças de código; as que chamam funções específicas de algoritmo precisam.
É aqui que a refatoração com Signer compensa: o serviço de documentos eletrônicos da BPA precisa apenas de um novo provedor e de uma entrada na política, enquanto os serviços que ainda chamam funções específicas de algoritmo precisam, cada um, de mudanças de código. O CBOM registra o padrão que cada aplicação usa, o que transforma uma estimativa vaga de esforço numa contagem de itens de trabalho.
28.3 Identificadores e codificações
A interoperabilidade depende de identificadores exatos: codepoints do TLS (0x11EC para o X25519MLKEM768 no registro da IANA), identificadores de objeto X.509 para as chaves ML-DSA e ML-KEM e codificações de chave (semente versus chave expandida). As incompatibilidades causam falhas que parecem defeitos de rede.
Um codepoint errado faz o servidor ignorar o compartilhamento do cliente, de modo que a conexão cai para o fallback ou falha, o que um engenheiro pode diagnosticar erradamente como problema de firewall. Os testes de interoperabilidade, portanto, comparam identificadores e codificações com o registro e as normas antes de verificar qualquer outra coisa.
28.4 Assinaturas com estado
A assinatura com LMS/XMSS nunca pode reutilizar um índice de chave de uso único. Controles: assinar num HSM que imponha estado monotônico; reservar faixas de índices por assinante; proibir a restauração do estado a partir de backups; monitorar a capacidade de assinatura restante (a SP 800-208 exige geração de chaves e assinatura em módulo de hardware para esses esquemas). Se esses controles forem inviáveis, prefira o SLH-DSA, sem estado, ou o ML-DSA.
Para o firmware dos guindastes da BPA, uma chave de 2^15 assinaturas com algumas versões por ano nunca se esgota, então o monitoramento da capacidade é uma formalidade; o controle real é a recusa do HSM em retroceder o estado.
28.5 Exemplo resolvido
A BPA integra o ML-DSA-65 para os conhecimentos de embarque. O serviço de assinatura usa um HSM via PKCS#11; os verificadores nos sistemas dos parceiros usam outra biblioteca. Os testes de interoperabilidade revelam que uma biblioteca esperava um formato de chave privada expandida — irrelevante para os verificadores, mas impedindo a importação da chave num HSM de backup. Solução: padronizar o armazenamento das chaves em forma de semente e testar a importação/exportação nos dois HSMs antes da produção.
O problema só teria aparecido durante uma recuperação de desastre, quando o HSM de backup fosse necessário, que é o pior momento para descobri-lo. Testar a importação e a exportação antes da produção transformou uma interrupção futura numa decisão de configuração.
28.6 Erros comuns e limites
- Misturar implementações de rascunho e finais dos algoritmos.
- Assinatura em software para esquemas com estado.
- Supor que os identificadores coincidem entre fornecedores.
O código Kyber ou Dilithium de rascunho não interopera com o ML-KEM ou o ML-DSA finais, então misturá-los causa falhas que parecem aleatórias. A assinatura só em software para LMS ou XMSS não consegue garantir que o estado nunca seja reutilizado, e a SP 800-208 exige um módulo de hardware. Os identificadores e as codificações dos fornecedores precisam ser verificados em testes, como mostrou o problema da chave expandida; um teste que importa cada chave nos dois HSMs detecta isso cedo.
Nota de engenharia
Planeje os formatos de chaves e certificados pensando na migração. Guarde as chaves privadas ML-KEM e ML-DSA como sementes onde a norma e o módulo permitirem, porque as sementes são compactas e se expandem de forma determinística, o que simplifica o backup e a migração entre HSMs. Registre no CBOM a codificação que cada sistema usa, teste a exportação e a importação entre cada par de módulos antes da produção e mantenha um procedimento escrito para as cerimônias de chaves que nomeie o conjunto de parâmetros, a codificação, a versão do firmware do módulo e as testemunhas.
Exercícios
- EX055 — Lista para escolher biblioteca. Escreva uma lista de verificação para selecionar uma biblioteca de PQC. Rubrica: 3 = versões finais das FIPS, tempo constante, KATs, manutenção, validação.
- EX056 — Plano de estado. Projete a gestão de estado do LMS para dois locais de assinatura. Rubrica: 3 = particionamento de índices, sem retrocesso, monitoramento da capacidade.
Síntese
Implemente a PQC por meio de provedores verificados e validados, identificadores e codificações exatos e uma gestão rigorosa do estado nas assinaturas com estado.
Continue estudando — capítulo 28 de 50
← Capítulo 27 · Índice de capítulos do curso · Capítulo 29 →
Siga para a próxima lição escrita.