Capítulo 16 — Segurança quântica e pós-quântica: métodos II
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["16.1 Opções de assinatura"]
N1["16.2 Atividade prática — Laboratório B"]
N2["16.3 Mudanças na PKI interna"]
N3["16.4 Assinatura de código e de firmware"]
N4["16.5 Caso resolvido"]
N5["16.7 HSMs e formatos de chave"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["16.1 Opções de assinatura"]
N1["16.2 Atividade prática — Laboratório B"]
N2["16.3 Mudanças na PKI interna"]
N3["16.4 Assinatura de código e de firmware"]
N4["16.5 Caso resolvido"]
N5["16.7 HSMs e formatos de chave"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX031"]
[16.1 Opções de assinatura]
|
v
[16.2 Atividade prática — Laboratório B]
|
v
[16.3 Mudanças na PKI interna]
|
v
[16.4 Assinatura de código e de firmware]
|
v
[16.5 Caso resolvido]
|
v
[16.7 HSMs e formatos de chave]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) explicar o ML-DSA, o SLH-DSA, o LMS e o XMSS do ponto de vista de um implementador; (2) estimar os tamanhos das cadeias de certificados; (3) planejar as mudanças na PKI interna; e (4) escolher as assinaturas para a assinatura de código e de firmware.
16.1 Opções de assinatura
ML-DSA (FIPS 204): rápido, tamanhos moderados (44/65/87: chaves públicas de 1.312/1.952/2.592 bytes; assinaturas de 2.420/3.309/4.627 bytes). SLH-DSA (FIPS 205): premissas apenas de hash, chaves públicas de 32 a 64 bytes, assinaturas de 7.856 a 49.856 bytes, assinatura mais lenta. LMS/XMSS (SP 800-208): compactos, com estado, para uso em módulos de hardware que gerenciam o estado.
Na KLS, a escolha segue o uso: ML-DSA para a AC interna, o mTLS da malha e a assinatura de versões; SLH-DSA ou LMS apenas onde a assinatura é rara e os verificadores são simples, como o firmware dos leitores. O estado exclui o LMS para qualquer signatário que não seja um módulo de hardware com contadores gerenciados.
16.2 Atividade prática — Laboratório B
# Lab B (ch 16): bytes of authentication in a TLS handshake for different signature choices.
# Sizes in bytes: (public key, signature). ML-DSA from FIPS 204; SLH-DSA-128s from FIPS 205.
algs = {"ECDSA P-256": (65, 72), "RSA-2048": (270, 256), "ML-DSA-44": (1312, 2420),
"ML-DSA-65": (1952, 3309), "SLH-DSA-SHA2-128s": (32, 7856)}
def chain_bytes(alg, depth=2, scts=2):
pk, sig = algs[alg]
certs = depth * (pk + sig + 400) # leaf + intermediate: key + CA signature + ~400 B fields
return certs + sig + scts * sig # + CertificateVerify + embedded SCT signatures
for a in algs:
print(f"{a:20s} ~{chain_bytes(a):6d} bytes of certificates and signatures")
Saída esperada:
ECDSA P-256 ~ 1290 bytes of certificates and signatures
RSA-2048 ~ 2620 bytes of certificates and signatures
ML-DSA-44 ~ 15524 bytes of certificates and signatures
ML-DSA-65 ~ 21249 bytes of certificates and signatures
SLH-DSA-SHA2-128s ~ 40144 bytes of certificates and signatures
O modelo conta dois certificados (final e intermediário), cada um com uma chave pública, uma assinatura da AC e cerca de 400 bytes de outros campos, mais a assinatura do CertificateVerify e duas assinaturas de SCT embutidas. Ele é aproximado de propósito, mas a ordem é robusta: o ECDSA P-256 precisa de cerca de 1,3 kB, o RSA-2048 de cerca de 2,6 kB, o ML-DSA-44 de cerca de 15,5 kB, o ML-DSA-65 de cerca de 21,2 kB e o SLH-DSA-SHA2-128s de cerca de 40,1 kB. O aumento de 14.234 bytes do ML-DSA-44 em relação ao ECDSA é o que a KLS pondera para a malha. Observe que os SCTs pertencem aos certificados públicos; uma cadeia interna sem SCTs é menor, então execute de novo a função com scts=0 para os certificados finais da malha.
16.3 Mudanças na PKI interna
Para a AC interna: confirme o suporte do HSM à geração de chaves e à assinatura com ML-DSA; crie uma raiz e uma intermediária ML-DSA em laboratório; emita certificados finais de teste; teste a validação da cadeia em todas as partes confiantes (ingress, sidecars da malha, serviços Java, agentes de monitoramento); depois distribua a raiz aos repositórios de confiança em produção antes de emitir certificados finais de produção. Mantenha a hierarquia clássica em paralelo.
A lista de partes confiantes da KLS para o piloto tinha onze entradas; os agentes de monitoramento e dois serviços Java falharam na validação da cadeia na primeira execução do laboratório e precisaram de atualizações de biblioteca antes que a raiz pudesse ser distribuída. Essa constatação é o motivo pelo qual a hierarquia clássica paralela continua em uso até que todas as partes confiantes passem.
16.4 Assinatura de código e de firmware
Para os artefatos de versão verificados por anos, o ML-DSA é a escolha prática quando as ferramentas de empacotamento o suportarem; considere assinaturas duplas (clássica mais ML-DSA) durante a transição, para que os verificadores antigos continuem funcionando. Para um firmware assinado raramente, o LMS num HSM ou o SLH-DSA são atraentes, porque a verificação é simples e as premissas são conservadoras.
Os artefatos de versão da KLS são verificados pelas ferramentas de implantação dos clientes por anos, então as assinaturas duplas são o caminho prático: a assinatura RSA-3072 existente para os verificadores atuais e uma assinatura ML-DSA para os atualizados. O fornecedor dos leitores é questionado se o seu bootloader consegue verificar LMS ou SLH-DSA na próxima geração de hardware.
16.5 Caso resolvido
A malha da KLS usa certificados finais ECDSA de 90 dias. O Laboratório B sugere que as cadeias ML-DSA-44 acrescentam ~14 kB por handshake. Dentro de um data center, esse custo é aceitável; nos enlaces celulares dos leitores, pode não ser. Plano: ML-DSA-44 para o mTLS da malha depois da validação em laboratório; os leitores continuam clássicos até a renovação do fornecedor, documentado como risco residual.
O plano também registra por que os leitores são diferentes: uma cadeia de 14 kB a cada reconexão num enlace celular com perdas acrescenta segmentos e retransmissões, e a biblioteca TLS do fornecedor não consegue verificar o ML-DSA de qualquer forma. A decisão da malha é reversível, porque os certificados finais são de 90 dias e a hierarquia clássica permanece, então um canário com falha significa reemitir certificados finais ECDSA, e não reconstruir a PKI.
16.6 Erros comuns e limites
- Usar LMS/XMSS em software sem estado protegido.
- Emitir certificados finais PQ antes que os repositórios de confiança aceitem a raiz.
- Ignorar o suporte do firmware do HSM.
Cada erro tem um custo específico. Um estado do LMS guardado num arquivo de software pode ser restaurado de um backup e um índice reutilizado, o que quebra o esquema; é por isso que a SP 800-208 espera um gerenciamento de estado em hardware. Emitir certificados finais PQ cedo falha na validação em todo lugar onde a raiz está ausente, como o laboratório da KLS mostrou com os serviços Java. E um HSM cujo firmware não tem o ML-DSA transforma uma cerimônia planejada num projeto de atualização com o fornecedor; a KLS verifica o suporte do firmware antes de marcar as datas das cerimônias.
16.7 HSMs e formatos de chave
Os fornecedores de HSM acrescentam algoritmos pós-quânticos em versões de firmware, e os formatos de chave diferem entre produtos. Antes de se comprometer com uma raiz ML-DSA, teste em laboratório: a geração de chaves dentro do HSM, a assinatura de um certificado, a exportação da chave pública na codificação que o software da sua AC espera, o backup e a restauração da chave segundo o procedimento do fornecedor e o failover entre os membros do cluster. Registre as versões de firmware e os procedimentos no documento da cerimônia de chaves. Descobrir uma incompatibilidade de formato durante uma cerimônia de produção custa muito mais do que um dia de testes em laboratório.
Exercícios
- EX031 — Tamanho da cadeia. Pelo Laboratório B, quantos bytes o ML-DSA-44 usa a mais do que o ECDSA P-256? Rubrica: 3 = 14.234 bytes.
- EX032 — Escolha da assinatura. Escolha uma assinatura para a assinatura de imagens de contêiner da KLS e justifique. Rubrica: 3 = ML-DSA (possivelmente dupla), com raciocínio sobre o suporte dos verificadores.
Síntese
A migração das assinaturas troca tamanho, velocidade, estado e premissas. Os implementadores começam pela PKI interna e pela assinatura de longa duração, depois de confirmar o suporte dos HSMs e das partes confiantes.
Continue estudando — capítulo 16 de 30
← Capítulo 15 · Índice de capítulos do curso · Capítulo 17 →
Siga para a próxima lição escrita.