Capítulo 11 — Segurança quântica e pós-quântica: verificação
Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["11.1 Verifique a negociação, não a configuração"]
N1["11.2 Atividade prática — Laboratório V"]
N2["11.3 Controles negativos"]
N3["11.4 Encerrando com evidências"]
N4["11.5 Caso resolvido"]
N5["11.6 Atividade prática"]
N6["11.7 Verificando após outras mudanças"]
N7["11.9 O que a verificação não mostra"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["11.1 Verifique a negociação, não a configuração"]
N1["11.2 Atividade prática — Laboratório V"]
N2["11.3 Controles negativos"]
N3["11.4 Encerrando com evidências"]
N4["11.5 Caso resolvido"]
N5["11.6 Atividade prática"]
N6["11.7 Verificando após outras mudanças"]
N7["11.9 O que a verificação não mostra"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[11.1 Verifique a negociação, não a configuração]
|
v
[11.2 Atividade prática — Laboratório V]
|
v
[11.3 Controles negativos]
|
v
[11.4 Encerrando com evidências]
|
v
[11.5 Caso resolvido]
|
v
[11.6 Atividade prática]
|
v
[11.7 Verificando após outras mudanças]
|
v
[11.9 O que a verificação não mostra]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) verificar se as mudanças atingiram o seu objetivo; (2) executar testes de resposta conhecida e testes negativos no laboratório; (3) usar controles negativos; e (4) encerrar o trabalho com evidências.
11.1 Verifique a negociação, não a configuração
Uma configuração pode dizer híbrido enquanto as conexões negociam clássico. Verifique do lado do cliente (saída das ferramentas) e do lado do servidor (logs). No SSH, confira o algoritmo de KEX no ssh -v; nas VPNs, confira o status do túnel.
Use os dois lados: a saída da ferramenta de cliente mostra o que um cliente obteve, e os logs do servidor mostram o que todos os clientes obtiveram. No HHG, a configuração do portal do hóspede listava o híbrido, mas os logs mostravam apenas 3 % de híbrido. Verifique com mais de um tipo de cliente, incluindo um cliente antigo, para confirmar que o fallback continua funcionando como pretendido.
11.2 Atividade prática — Laboratório V
# Lab V (ch 11): known-answer and negative tests - the habit behind validating PQC libraries.
import hashlib
KATS = [ # (function, input, expected hex prefix) - published test values for SHA-3 / SHAKE on empty input
("sha3_256", b"", "a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a"),
("shake_128/32", b"", "7f9c2ba4e88f827d616045507605853ed73b8093f6efbc88eb1a6eacfa66ef26"),
]
def run(name, data):
if name == "sha3_256": return hashlib.sha3_256(data).hexdigest()
return hashlib.shake_128(data).hexdigest(32)
for name, data, want in KATS:
print(f"KAT {name:13s}", "PASS" if run(name, data) == want else "FAIL")
SIZES = {"ML-KEM-512": 800, "ML-KEM-768": 1184, "ML-KEM-1024": 1568} # encapsulation-key bytes, FIPS 203
def validate_ek(param, ek):
if len(ek) != SIZES[param]: raise ValueError(f"{param}: expected {SIZES[param]} bytes, got {len(ek)}")
return True
for param, n in [("ML-KEM-768", 1184), ("ML-KEM-768", 1183), ("ML-KEM-512", 1184)]:
try: validate_ek(param, bytes(n)); print(f"negative/positive test {param} len {n}: accepted")
except ValueError as e: print(f"negative/positive test {param} len {n}: rejected ({e})")
Saída esperada:
KAT sha3_256 PASS
KAT shake_128/32 PASS
negative/positive test ML-KEM-768 len 1184: accepted
negative/positive test ML-KEM-768 len 1183: rejected (ML-KEM-768: expected 1184 bytes, got 1183)
negative/positive test ML-KEM-512 len 1184: rejected (ML-KEM-512: expected 800 bytes, got 1184)
Os testes de resposta conhecida verificam se as funções produzem as saídas publicadas; os testes negativos verificam se entradas com comprimento errado são rejeitadas.
A primeira parte confere duas funções de hash contra as saídas publicadas para a entrada vazia; a segunda verifica se chaves de encapsulamento com comprimento errado para cada conjunto de parâmetros do ML-KEM são rejeitadas. Um PASS nas respostas conhecidas e as rejeições corretas mostram que as verificações funcionam. São os mesmos hábitos usados ao validar bibliotecas pós-quânticas reais: confirmar as saídas corretas e confirmar que entradas ruins são recusadas. Altere um byte de um valor esperado e confirme que o teste agora relata FAIL.
11.3 Controles negativos
Para confiar numa verificação, mostre que ela pode falhar: execute-a contra um servidor com o híbrido removido e confirme que ela relata clássico. Uma verificação que sempre diz "passou" é inútil.
No HHG, após o OPS-430, o controle negativo na homologação mostrou 0 % de híbrido com o híbrido removido, provando que o painel mostraria uma falha se ela ocorresse. Execute o controle negativo na homologação ou no laboratório, nunca removendo a proteção em produção. Registre o resultado do controle negativo no ticket, com o horário e a configuração usada.
11.4 Encerrando com evidências
Anexe ao ticket as saídas, capturas de tela do painel com horários e a versão da configuração. Anote qualquer coisa inesperada, mesmo que a mudança tenha funcionado.
No HHG, o ticket OPS-430 foi fechado com os resultados dos clientes, o número de 85 % dos logs do balanceador de carga e o controle negativo da homologação. Quem ler o ticket meses depois consegue ver o que foi verificado e quando. Evidência ausente significa que a mudança não está verificada, por melhor que ela pareça funcionar. Guarde as evidências na pasta combinada e vincule-as a partir do ticket, em vez de colar saídas grandes.
11.5 Caso resolvido
Após o OPS-430, o operador verifica: três tipos de cliente contra o portal de produção (dois híbridos, um cliente mais antigo clássico, como esperado); os logs do balanceador de carga mostram 85 % de híbrido; o controle negativo na homologação (híbrido removido) mostra corretamente 0 %. Evidências anexadas; ticket fechado.
A verificação cobre os dois lados, inclui clientes antigos como o fallback esperado e acrescenta um controle negativo que prova que a verificação pode falhar. Cada resultado é anexado ao ticket. Um auditor conseguiria verificar o trabalho apenas pelo ticket, sem perguntar ao operador. Use-o como modelo.
11.6 Atividade prática
Verifique uma mudança de laboratório dos lados do cliente e do servidor e inclua um controle negativo.
Use uma mudança do Capítulo 10, como a reordenação dos grupos. Registre os resultados dos clientes com as versões, as linhas de log do servidor e a versão da configuração. Para o controle negativo, remova o híbrido no laboratório, confirme que a verificação relata clássico e depois restaure-o. Anexe todas as saídas a um ticket de prática, como se fosse fechar uma mudança de produção, e anote qualquer coisa inesperada. Peça a um colega que o revise. Guarde o ticket com as suas anotações de laboratório.
11.7 Verificando após outras mudanças
A verificação não serve apenas para as suas próprias mudanças. Reverifique a negociação híbrida após qualquer atualização que mexa na pilha TLS ou SSH — patches do sistema operacional, firmware do balanceador de carga, reconstrução de imagens de contêiner —, porque essas atualizações podem redefinir a configuração. Uma verificação curta, em script, executada após cada janela de patches detecta regressões em poucas horas.
No HHG, uma atualização de firmware do balanceador de carga redefiniu o perfil TLS da API de reservas; uma verificação em script após a janela de patches a teria encontrado no mesmo dia. Acrescente a verificação ao procedimento de patches.
11.8 Erros comuns e limites
- Verificar apenas a configuração.
- Nenhum controle negativo.
- Fechar tickets sem evidências.
Cada erro deixa uma mudança sem comprovação. A configuração sozinha pode dizer híbrido enquanto os clientes negociam clássico, como no portal do hóspede do HHG antes do OPS-430. Uma verificação sem controle negativo pode relatar sucesso aconteça o que acontecer. Um ticket fechado sem evidências não pode ser auditado e não dá ao próximo operador nada com que comparar após uma atualização. Confira cada ticket fechado quanto aos três. Corrija o que encontrar antes que o ticket seja revisado. Anote o que você mudou.
11.9 O que a verificação não mostra
Uma negociação híbrida bem-sucedida mostra que a chave de sessão foi acordada com ML-KEM e X25519 juntos. Ela não mostra que o certificado do servidor é pós-quântico (provavelmente ainda é ECDSA ou RSA), que todos os outros saltos do caminho estão protegidos nem que a biblioteca está livre de falhas de implementação. Escreva esses limites no ticket, para que ninguém leia "verificado" como "o serviço inteiro é seguro contra o quântico". A qualidade da implementação vem do uso de bibliotecas avaliadas e atualizadas; falhas passadas, como o problema de tempo KyberSlash (Bernstein et al., 2024), foram corrigidas por atualizações de bibliotecas, não por configuração.
Anote esses limites em todo ticket de verificação.
Exercícios
- EX031 — Dois lados. Nomeie a evidência do lado do cliente e a do lado do servidor para a negociação híbrida no TLS. Rubrica: 3 = saída da ferramenta e logs do servidor.
- EX032 — Controle negativo. Projete um controle negativo para a verificação do SSH híbrido. Rubrica: 3 = remover o híbrido, esperar clássico.
- EX033 — Verificação pós-patch. Escreva três passos de uma verificação pós-patch. Rubrica: 3 = executar os clientes, conferir logs/painel, comparar com a linha de base.
Síntese
A verificação confere a negociação real dos dois lados, inclui controles negativos, é repetida após outras atualizações e encerra o trabalho com evidências.
Continue estudando — capítulo 11 de 18
← Capítulo 10 · Índice de capítulos do curso · Capítulo 12 →
Siga para a próxima lição escrita.