Capítulo 27 — Segurança quântica e pós-quântica: projeto de controles | Engenharia Segurança quântica e pós-quântica

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX053.

flowchart TD
  N0["27.1 Controles do combinador"]
  N1["27.2 Atividade prática — Laboratório C"]
  N2["27.3 Controles de negociação"]
  N3["27.4 Controles de gestão de chaves"]
  N4["27.5 Controles de política"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX053"]

Desenho lógico

flowchart LR
  N0["27.1 Controles do combinador"]
  N1["27.2 Atividade prática — Laboratório C"]
  N2["27.3 Controles de negociação"]
  N3["27.4 Controles de gestão de chaves"]
  N4["27.5 Controles de política"]
  N5["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX053"]

[27.1 Controles do combinador]
    |
    v
[27.2 Atividade prática — Laboratório C]
    |
    v
[27.3 Controles de negociação]
    |
    v
[27.4 Controles de gestão de chaves]
    |
    v
[27.5 Controles de política]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX053]

Objetivos de aprendizagem

Você vai (1) projetar os controles que tornam segura a troca de chaves híbrida — combinadores, vínculo com a transcrição e negociação; (2) projetar controles de gestão de chaves para os novos tipos de chave; (3) especificar controles de política para os algoritmos permitidos; e (4) testar um combinador. O capítulo parte dos Capítulos 24–26.

27.1 Controles do combinador

Uma troca de chaves híbrida precisa derivar a chave de sessão dos dois segredos compartilhados, para que o comprometimento de um não revele a chave. No X25519MLKEM768, os segredos são concatenados (primeiro o ML-KEM) e entram no escalonamento de chaves do TLS 1.3, que os vincula à transcrição do handshake (RFC 10024). Combinadores próprios fora de protocolos padronizados devem seguir os métodos de derivação de chaves da SP 800-56C, que a FIPS 203 permite para os segredos compartilhados do ML-KEM, e vincular o contexto (identidades, textos cifrados, transcrição).

27.2 Atividade prática — Laboratório C

# Lab C (ch 27): a hybrid key combiner. The session key depends on BOTH shared secrets.
import hashlib, hmac
def hkdf_extract(salt, ikm): return hmac.new(salt, ikm, hashlib.sha256).digest()
def combine(ss_pq, ss_trad, context):
    # Concatenate secrets (PQ first, as in X25519MLKEM768), bind the transcript/context, then extract.
    return hkdf_extract(b"\x00" * 32, ss_pq + ss_trad + context).hex()[:16]
pq, trad, ctx = b"P" * 32, b"T" * 32, b"handshake-transcript-hash"
print("baseline              ", combine(pq, trad, ctx))
print("PQ secret changed     ", combine(b"Q" * 32, trad, ctx))
print("traditional changed   ", combine(pq, b"U" * 32, ctx))
print("context changed       ", combine(pq, trad, b"other-transcript"))

Saída esperada:

baseline               d48e982e8c06ca60
PQ secret changed      d4c36ea2d90b2e9c
traditional changed    8dcefa12ded3d99c
context changed        af06eca8abcd45a9

Mudar qualquer um dos segredos ou o contexto muda a saída: a chave derivada depende dos dois componentes e do que foi negociado.

Note que só os primeiros caracteres da saída hexadecimal são mostrados, para facilitar a leitura; uma derivação real usaria a saída completa e uma etapa adequada de expansão HKDF. Experimente passar um contexto vazio e compare: o resultado ainda depende dos dois segredos, mas não mais da transcrição, que é exatamente a fraqueza que o vínculo com o contexto evita.

27.3 Controles de negociação

A negociação dos algoritmos precisa ser autenticada. O TLS 1.3 assina a transcrição, então um atacante que remove os grupos híbridos é detectado, a menos que consiga falsificar a assinatura do servidor. Uma lógica de aplicação que repete a tentativa sem grupos híbridos após qualquer falha reabre o rebaixamento; controles: registrar e alertar sobre fallback e desativar o fallback onde todos os pares suportam híbridos.

O portal da BPA registra todo handshake que termina sem um grupo híbrido quando o cliente ofereceu um. Um aumento desses eventos dispara um alerta, já que pode significar um ataque ou um middlebox com mau comportamento, e os dois precisam de investigação.

27.4 Controles de gestão de chaves

Os novos tipos de chave precisam de controles de ciclo de vida: geração em módulos aprovados, armazenamento, rotação, backup e destruição. As chaves de desencapsulamento do ML-KEM podem ser guardadas como uma semente de 64 bytes, conforme a FIPS 203; as chaves de assinatura baseadas em hash com estado exigem proteção do estado contra retrocesso; as chaves ML-DSA precisam de suporte no HSM.

A forma de semente de 64 bytes é compacta e evita incompatibilidades de formato, como mostra o problema de importação no HSM do exemplo do próximo capítulo. A destruição também exige cuidado: uma chave precisa ser removida de todos os backups e partições de HSM, e a entrada do CBOM fechada com a data.

27.5 Controles de política

Uma lista de permissões de algoritmos e conjuntos de parâmetros por contexto — por exemplo, "TLS de borda: X25519MLKEM768, SecP256r1MLKEM768; fallback X25519 até 2027-12-31" —, implementada na configuração e verificada pela telemetria.

A entrada de fallback tem uma data de término para que não fique para sempre; depois dessa data, o X25519 sozinho é removido do TLS de borda. A telemetria confirma o que a configuração afirma, contando os grupos negociados por dia. Quando a contagem de conexões só clássicas se aproxima de zero, a equipe tem evidência de que a remoção não vai quebrar os parceiros, e a mudança pode passar sem um longo debate.

27.6 Exemplo resolvido

Uma equipe da BPA propõe fazer XOR dos dois segredos compartilhados para economizar uma chamada de KDF. A revisão rejeita: o XOR não oferece vínculo com o contexto e é frágil em algumas provas de segurança; use o combinador padrão do protocolo ou a derivação da SP 800-56C com os dois segredos e o contexto.

Economizar uma chamada de KDF não ganha nada mensurável: calcular o hash de algumas dezenas de bytes custa microssegundos, enquanto um combinador fraco poderia minar a própria razão de usar um híbrido. A revisão registra a decisão nas notas de projeto da equipe, para que a ideia não seja proposta de novo.

27.7 Erros comuns e limites

Combinadores improvisados (XOR, truncamento).
Fallback silencioso, sem registro.
Tratar chaves com estado como chaves comuns no backup.

XOR e truncamento parecem inofensivos, mas descartam o vínculo com o contexto e podem enfraquecer as provas de segurança, como explicou o exemplo resolvido. O fallback silencioso esconde o rebaixamento, e é por isso que a BPA registra todo handshake sem o grupo híbrido. Fazer backup de uma chave de assinatura com estado como se fosse uma chave comum convida ao retrocesso do estado e à reutilização de chaves de uso único após uma restauração; a BPA exclui essas chaves dos backups rotineiros e mantém o estado delas no HSM.

Exercícios

EX053 — Revisão de combinador. Revise uma proposta que calcula o hash apenas do segredo de PQC "porque é mais forte". Rubrica: 3 = explica a perda da proteção dupla e recomenda o combinador padrão.
EX054 — Arquivo de política. Escreva uma lista de permissões de política para a borda e os serviços internos da BPA, com datas de expiração para os fallbacks. Rubrica: 3 = conjuntos de parâmetros explícitos, expiração datada.

Síntese

A segurança dos híbridos depende de controles: combinadores padronizados com vínculo ao contexto, negociação autenticada sem fallback silencioso, gestão do ciclo de vida dos novos tipos de chave e listas de permissões datadas.