Capítulo 5 — Segurança quântica e pós-quântica: alternativas de projeto

Mapa da aula

Aula 05 publicada. Mapa, exemplo, EX021.

flowchart TD
  N0["5.1 Alternativas de estabelecimento de chaves"]
  N1["5.2 Alternativas de autenticação"]
  N2["5.3 Atividade prática — Laboratório B"]
  N3["5.4 Política de parâmetros"]
  N4["5.5 Caso resolvido"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX021"]

Desenho lógico

flowchart LR
  N0["5.1 Alternativas de estabelecimento de chaves"]
  N1["5.2 Alternativas de autenticação"]
  N2["5.3 Atividade prática — Laboratório B"]
  N3["5.4 Política de parâmetros"]
  N4["5.5 Caso resolvido"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX021"]

[5.1 Alternativas de estabelecimento de chaves]
    |
    v
[5.2 Alternativas de autenticação]
    |
    v
[5.3 Atividade prática — Laboratório B]
    |
    v
[5.4 Política de parâmetros]
    |
    v
[5.5 Caso resolvido]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX021]

Objetivos de aprendizagem

Você vai (1) enumerar as alternativas de projeto para o estabelecimento de chaves, a autenticação e a proteção dos dados; (2) comparar os projetos pós-quântico puro, híbrido, aumentado por PSK e de minimização; (3) quantificar os custos em bytes da autenticação; (4) escolher os conjuntos de parâmetros segundo a política; e (5) documentar as alternativas para que os revisores possam questionar a escolha.

5.1 Alternativas de estabelecimento de chaves

O híbrido PQ/T (no sentido da RFC 9794) combina o ML-KEM com o ECDH, de modo que a sessão seja segura se qualquer um deles se mantiver; é o projeto de transição padrão no TLS (X25519MLKEM768) e no IKEv2 (trocas de chaves adicionais da RFC 9370). O pós-quântico puro usa apenas o ML-KEM; ele reduz a complexidade e é atraente onde a política o exige ou onde o componente tradicional não acrescenta valor, mas remove a proteção contra uma quebra inesperada ou uma falha de implementação. O aumento por PSK mistura uma chave simétrica pré-compartilhada no handshake (como na RFC 8784 para o IKEv2); é uma proteção provisória rápida contra o HNDL em alguns enlaces fixos, mas escala mal. A minimização e a rearquitetura enviam menos dados de vida longa — um controle independente dos algoritmos. A SP 800-227 discute a composição de KEMs e os requisitos dos combinadores.

5.2 Alternativas de autenticação

Opções para os certificados: manter os certificados clássicos enquanto se monitora a prontidão do ecossistema (aceitável onde o risco de falsificação posterior é baixo e os certificados têm vida curta); emitir certificados ML-DSA primeiro em ecossistemas fechados, como a PKI interna e as frotas de dispositivos; usar abordagens de certificados duplos ou compostos durante a transição, onde as normas e os produtos as suportarem; e usar assinaturas baseadas em hash (SLH-DSA, LMS, XMSS) onde o conservadorismo ou a simplicidade da verificação importam, notadamente no firmware.

Escolha pelo ecossistema. A PKI interna e as frotas de dispositivos da NRHT são fechadas, então o ML-DSA pode começar por elas. Os certificados públicos da web continuam clássicos até que os navegadores e as autoridades certificadoras suportem a emissão pós-quântica em escala. Para o firmware, as assinaturas baseadas em hash servem ao caso conservador, desde que o estado seja gerenciado corretamente.

5.3 Atividade prática — Laboratório B

# Lab B (ch 5): 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

Para uma malha de serviços interna numa rede de data center, 15 kB por handshake é aceitável. Para dispositivos de clínicas em enlaces restritos, ou protocolos com limites pequenos de mensagem, pode não ser. A resposta de projeto é escolher onde a autenticação pós-quântica entra primeiro, enxugar as cadeias e medir — e não supor.

Os tamanhos do laboratório vêm das normas; os 400 bytes de outros campos do certificado e as duas assinaturas embutidas são hipóteses aproximadas. Mude a profundidade da cadeia ou o número de assinaturas embutidas para ver com que rapidez os totais crescem. Use o resultado para decidir onde medir primeiro e depois meça em handshakes reais num laboratório.

5.4 Política de parâmetros

Os conjuntos de parâmetros se associam às categorias do NIST: ML-KEM-512/768/1024 às categorias 1/3/5; ML-DSA-44/65/87 às 2/3/5. Um especialista define a política explicitamente (por exemplo, categoria 3 por padrão, categoria 5 para parceiros ligados à segurança nacional) e registra o porquê. Parâmetros máximos uniformes desperdiçam bytes e ciclos; escolhas improvisadas tornam as auditorias penosas.

Escreva a política na norma criptográfica, com um motivo curto para cada padrão e cada exceção. Na NRHT, o padrão para o novo estabelecimento de chaves é o híbrido com ML-KEM-768. Revise a política quando as normas mudarem, como quando o FN-DSA for finalizado.

5.5 Caso resolvido

A replicação do EHR entre locais da NRHT roda sobre IPsec. Alternativas: (a) IKEv2 híbrido com ML-KEM-768 nos equipamentos do fornecedor A (suportado agora); (b) PSKs da RFC 8784 para os dois locais do fornecedor B até 2027; (c) rearquitetar a replicação para enviar apenas os deltas, cortando o volume em 70 %; (d) ML-KEM puro — rejeitado porque a implementação do fornecedor A é nova e a proteção do híbrido é valiosa. Escolhido: (a) + (b) + (c), com (b) expirando quando o fornecedor B entregar o suporte híbrido. A autenticação continua clássica por enquanto; o plano da PKI interna (Capítulo 8) a trata.

Registre a alternativa rejeitada e o seu motivo no registro de projeto, para que ela possa ser reconsiderada quando a implementação do fornecedor A amadurecer.

5.6 Erros comuns e limites

• Escolher o pós-quântico puro para "ser moderno" sem considerar a proteção do híbrido.
• Esquemas de PSK sem rotação e sem distribuição segura.
• Ignorar a minimização porque ela não é criptografia.

Cada erro tem uma salvaguarda. Mantenha o híbrido a menos que haja um motivo para abandoná-lo, e registre esse motivo. Para as PSKs, escreva como as chaves são geradas, distribuídas e rotacionadas, e quando expiram. Conte a minimização como um controle de segurança ao lado dos criptográficos. Na NRHT, as PSKs do fornecedor B receberam uma expiração vinculada ao suporte híbrido, e a replicação foi reprojetada para enviar deltas, cortando o volume em 70 %.

Exercícios

• EX021 — Tabela de alternativas. Compare o híbrido, o pós-quântico puro, o aumento por PSK e a minimização quanto à proteção contra o HNDL, à complexidade, à escalabilidade e ao risco residual. Rubrica: 3 = quatro alternativas × quatro critérios, defensável.
• EX022 — Orçamento de bytes. A partir do Laboratório B, por que fator o ML-DSA-65 excede o ECDSA P-256 em bytes de autenticação? Rubrica: 3 = 21.249/1.290 ≈ 16,5.
• EX023 — Política de parâmetros. Escreva uma política de parâmetros de duas linhas para a NRHT, com justificativa. Rubrica: 3 = categorias por uso, justificativa.
• EX024 — Expiração das PSKs. Especifique as condições sob as quais a alternativa (b) de 5.5 precisa terminar. Rubrica: 3 = suporte do fornecedor verificado, migração testada, data-limite.
• EX025 — Caso do pós-quântico puro. Descreva um contexto em que o ML-KEM puro é a melhor escolha. Rubrica: 3 = exigência de política ou contexto restrito, com a perda da proteção do híbrido argumentada.

Síntese

As alternativas de projeto abrangem as abordagens híbrida, pura, aumentada por PSK e de minimização para o estabelecimento de chaves, e as abordagens em estágios, começando pelos ecossistemas fechados, para a autenticação. Uma política de parâmetros explícita e orçamentos de bytes tornam a escolha revisável.