Capítulo 27 — Segurança quântica e pós-quântica: verificação

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX053.

flowchart TD
  N0["27.2 Verificando a negociação"]
  N1["27.3 Downgrade e fallback"]
  N2["27.4 Evidências"]
  N3["27.6 Atividade prática"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX053"]

Desenho lógico

flowchart LR
  N0["27.2 Verificando a negociação"]
  N1["27.3 Downgrade e fallback"]
  N2["27.4 Evidências"]
  N3["27.6 Atividade prática"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX053"]

[27.2 Verificando a negociação]
    |
    v
[27.3 Downgrade e fallback]
    |
    v
[27.4 Evidências]
    |
    v
[27.6 Atividade prática]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX053]

Objetivos de aprendizagem

Você vai (1) definir objetivos de verificação para uma migração; (2) testar se a troca de chaves híbrida é de fato negociada; (3) detectar downgrade e fallback num laboratório; e (4) coletar evidências de verificação que outras pessoas consigam reproduzir.

27.1 Objetivos de verificação

A verificação pergunta se o sistema faz o que o projeto diz. Numa migração, os objetivos incluem: o grupo híbrido é oferecido e selecionado para os clientes no escopo; o fallback clássico ocorre apenas onde é permitido; os certificados são validados em todos os clientes suportados; o desempenho fica dentro do orçamento; e os logs registram os algoritmos negociados.

Cada objetivo precisa de um método e de um resultado esperado registrados antes de os testes começarem, para que os resultados não possam ser reinterpretados depois. Na HCU, os objetivos são aplicados separadamente ao gateway web e à VPN das agências, porque eles usam produtos diferentes e falham de maneiras diferentes.

27.2 Verificando a negociação

A configuração diz o que um servidor oferece; o handshake mostra o que é selecionado. Verifique a seleção pelo lado do cliente (saída de um cliente de teste mostrando o grupo) e pelo lado do servidor (logs dos grupos negociados). No TLS 1.3, o grupo selecionado aparece no ServerHello em claro, então um sensor passivo autorizado consegue confirmá-lo. No IKEv2, os logs dos equipamentos ou as capturas de laboratório mostram os métodos de troca de chaves negociados conforme a RFC 9370.

As duas visões devem concordar. Se o cliente relata o grupo híbrido, mas os logs do servidor discordam, suspeite de um middlebox ou de um log que registra as ofertas, e não as seleções. A HCU verifica as duas visões em cada local.

27.3 Downgrade e fallback

O TLS 1.3 protege a integridade da negociação por meio do handshake vinculado à transcrição, então um atacante ativo não consegue simplesmente remover o grupo híbrido sem ser detectado. Mas o fallback ainda pode ocorrer legitimamente: um cliente que não suporta o grupo, ou um servidor configurado com preferência pelos grupos clássicos. Os testes de laboratório devem incluir clientes com e sem suporte híbrido e confirmar que cada um obtém o resultado esperado. Os experimentos de downgrade ativo pertencem apenas a um ambiente de teste isolado.

Cada resultado esperado deve ser registrado ao lado da versão do cliente no plano de testes.

27.4 Evidências

Registre os casos de teste, as versões dos clientes, os hashes da configuração do servidor, as saídas e as datas. Um relatório de verificação lista cada objetivo com aprovado, reprovado ou não testado, mais o local da evidência.

Os objetivos não testados são listados tão abertamente quanto as reprovações, porque um relatório que os omite exagera a cobertura. A HCU guarda o hash da configuração com cada resultado, para que um revisor posterior consiga dizer se uma aprovação ainda vale depois que a configuração do gateway mudar. Um relatório mais antigo que a configuração atual é tratado como desatualizado até que os testes sejam rodados de novo contra ela.

27.5 Exemplo resolvido

O laboratório da HCU verifica o gateway web piloto: um cliente com capacidade híbrida seleciona o X25519MLKEM768 (aprovado); um cliente legado seleciona o X25519 (fallback esperado, aprovado); a ordem de preferência do gateway foi configurada por engano com o X25519 primeiro, então até os clientes com capacidade híbrida escolheram o X25519 numa build de teste (reprovado, corrigido reordenando). Sem a verificação pelo lado do cliente, a configuração teria parecido correta.

A correção foi verificada rodando de novo os dois clientes depois da mudança. A lição para a HCU foi tornar a verificação pelo lado do cliente uma parte permanente de toda mudança no gateway, e não apenas do piloto, para que uma lista de preferências reordenada seja pega antes de chegar aos associados.

27.6 Atividade prática

Escreva uma lista de verificação com seis objetivos para um gateway da HCU com suporte híbrido, com o método e a evidência esperada para cada um.

Inclua pelo menos um objetivo sobre o fallback para clientes legados e um sobre o registro em log dos grupos negociados. Para cada objetivo, nomeie o cliente ou a ferramenta usada, o resultado esperado e onde a evidência será guardada. Depois marque quais objetivos podem ser verificados no laboratório e quais precisam de logs de produção, já que os do segundo tipo só podem ser confirmados depois que o piloto começar.

27.7 Erros comuns e limites

• Verificar a configuração em vez da negociação.
• Testar apenas clientes modernos.
• Rodar testes de downgrade na produção.
• Tratar um único handshake aprovado como prova para todos os locais e tipos de cliente.
• Esquecer de verificar de novo depois de uma mudança de configuração, de modo que a evidência anterior já não corresponde ao que roda.
• Ler a lista de ofertas do servidor como se fosse o grupo selecionado.
• Deixar os objetivos não testados fora do relatório, em vez de marcá-los como não testados.

Cada um desses faz um relatório parecer mais completo que a evidência por trás dele.

Exercícios

• EX053 — Oferecer versus selecionar. Explique como um servidor pode oferecer um grupo híbrido e, ainda assim, nunca selecioná-lo. Rubrica: 3 = ordem de preferência ou suporte do cliente explicados.
• EX054 — Registro de evidências. Liste cinco campos que todo registro de verificação deve conter. Rubrica: 3 = cinco campos pertinentes.

Síntese

A verificação confere o comportamento negociado, os caminhos de fallback e as evidências, e não apenas a configuração; os registros reprodutíveis transformam os testes em garantia.