Capítulo 28 — Segurança quântica e pós-quântica: análise de falhas
Mapa da aula
Aula 28 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["28.1 FMEA para a mudança criptográfica"]
N1["28.2 Resposta à quebra de um algoritmo"]
N2["28.3 Atividade prática — Laboratório A"]
N3["28.4 Recuperação e critérios de saída"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["28.1 FMEA para a mudança criptográfica"]
N1["28.2 Resposta à quebra de um algoritmo"]
N2["28.3 Atividade prática — Laboratório A"]
N3["28.4 Recuperação e critérios de saída"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[28.1 FMEA para a mudança criptográfica]
|
v
[28.2 Resposta à quebra de um algoritmo]
|
v
[28.3 Atividade prática — Laboratório A]
|
v
[28.4 Recuperação e critérios de saída]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) aplicar a análise de modos de falha e efeitos (FMEA) a uma migração; (2) planejar para a quebra de um algoritmo; (3) usar um registro orientado por política para ganhar agilidade; e (4) definir procedimentos de recuperação e critérios de saída.
28.1 FMEA para a mudança criptográfica
A FMEA lista, para cada componente, as maneiras como ele pode falhar, o efeito, a causa, como a falha seria detectada e uma prioridade de risco. Os modos de falha da migração incluem: falha do handshake por causa do tamanho das mensagens; retorno silencioso ao clássico; falha na validação de certificados em clientes antigos; degradação do desempenho em dispositivos restritos; descompasso na gestão de chaves entre HSMs; e um algoritmo deixar de ser confiável depois de uma criptoanálise.
Pontuar cada modo de falha quanto à gravidade, à probabilidade e à detectabilidade torna a classificação explícita e aberta a questionamento. As falhas silenciosas merecem atenção especial, porque nada alerta sobre elas por padrão.
28.2 Resposta à quebra de um algoritmo
O Rainbow e o SIKE mostram que um esquema pode cair de repente. Um plano de resposta diz quem decide, com que rapidez a configuração consegue remover o algoritmo, quais sistemas precisam de uma nova versão e quais precisam de hardware, e qual fallback é aceitável. Os híbridos tornam isso sobrevivível: se o ML-KEM fosse inesperadamente enfraquecido, os fluxos híbridos ainda se apoiariam no X25519 enquanto um substituto é implantado.
O plano deve ser ensaiado no laboratório antes de ser necessário. Sem um plano, a HCU estaria decidindo sob pressão quais agências e terminais mudar primeiro, e a resposta dependeria de quem estivesse de plantão.
28.3 Atividade prática — Laboratório A
# Lab A (ch 28): crypto-agility through a policy-driven registry instead of hard-coded algorithms.
import hashlib, hmac
REGISTRY = {"hmac-sha256": lambda k, m: hmac.new(k, m, hashlib.sha256).digest(),
"hmac-sha3-256": lambda k, m: hmac.new(k, m, hashlib.sha3_256).digest()}
POLICY = {"tag-algorithm": "hmac-sha256", "accept": ["hmac-sha256", "hmac-sha3-256"]}
def protect(key, msg):
alg = POLICY["tag-algorithm"]; return alg, REGISTRY[alg](key, msg)
def check(key, msg, alg, tag):
if alg not in POLICY["accept"]: return False # algorithm identifier is authenticated by policy
return hmac.compare_digest(REGISTRY[alg](key, msg), tag)
k, m = b"k" * 32, b"member statement 42"
a1, t1 = protect(k, m)
POLICY["tag-algorithm"] = "hmac-sha3-256" # migration = one policy change
a2, t2 = protect(k, m)
print("old tag still verifies during transition:", check(k, m, a1, t1))
print("new tag verifies:", check(k, m, a2, t2), "| algorithms:", a1, "->", a2)
POLICY["accept"] = ["hmac-sha3-256"] # retire the old algorithm
print("old tag after retirement:", check(k, m, a1, t1))
Saída esperada:
old tag still verifies during transition: True
new tag verifies: True | algorithms: hmac-sha256 -> hmac-sha3-256
old tag after retirement: False
A migração é uma mudança de política, e não de código. O identificador do algoritmo viaja com os dados; durante a transição, os dois algoritmos são aceitos, e depois da aposentadoria o antigo é recusado. Usar um MAC aqui mantém o laboratório simples; o mesmo padrão se aplica às assinaturas e aos KEMs.
Num sistema real, o registro guardaria identificadores de KEMs e de assinaturas, e a política seria carregada da configuração, em vez de definida no código. O laboratório também mostra por que a aposentadoria é uma etapa separada: as tags criadas sob o algoritmo antigo deixam de ser verificadas, então os dados que precisam continuar válidos precisam ser protegidos de novo antes.
28.4 Recuperação e critérios de saída
Cada estágio precisa de um procedimento de rollback e de um critério de saída. O rollback restaura rapidamente a configuração anterior se as falhas excederem o orçamento. Os critérios de saída dizem quando um estado de transição termina, como "negociação apenas clássica abaixo de 0,5 % por 90 dias", para que o fallback não se torne permanente.
Os dois devem ser acordados antes de o estágio começar, e não depois que um problema aparecer. A HCU escreve os passos de rollback no chamado de mudança e os testa no laboratório, porque um rollback que nunca foi executado tende a falhar no momento em que é necessário. O critério de saída é revisado em cada decisão de estágio, e qualquer prorrogação é registrada com um motivo e uma nova data.
28.5 Exemplo resolvido
A FMEA da HCU classifica em primeiro lugar o "retorno silencioso ao clássico na VPN das agências": grave para o HNDL, provável por erro de configuração, difícil de detectar sem monitoramento. Controle: alertar quando qualquer agência negociar sem o método pós-quântico, relatório semanal da parcela de fallback. O "ClientHello grande descartado por proxy legado" fica em segundo: aparece rapidamente, então o controle é a implantação em estágios e um runbook de rollback.
A FMEA é revisada depois de cada estágio da implantação, já que os resultados medidos podem mudar a classificação. Os dois controles são testados no laboratório antes de o piloto começar.
28.6 Erros comuns e limites
- Considerar apenas as falhas de disponibilidade, e não as falhas silenciosas de segurança.
- Nenhum plano para a quebra de um algoritmo.
- Fallbacks de transição sem critérios de saída.
- Pontuar a detectabilidade de forma generosa demais para falhas que não produzem erro.
- Escrever procedimentos de rollback que nunca foram ensaiados.
- Classificar os modos de falha uma vez e nunca revisitá-los depois que a implantação produz dados reais.
- Deixar os descompassos na gestão de chaves fora do escopo porque ficam com outra equipe.
Cada um desses deixa na mesa um risco que a análise deveria expor.
Exercícios
- EX055 — Linha da FMEA. Escreva uma linha da FMEA para "falha na validação de certificados em clientes legados depois dos certificados pós-quânticos". Rubrica: 3 = modo, efeito, causa, detecção, prioridade.
- EX056 — Resposta à quebra. Esboce cinco passos que a HCU dá se for anunciada uma fraqueza séria num algoritmo pós-quântico implantado. Rubrica: 3 = responsável pela decisão, avaliação, mudança de configuração, novas versões/hardware, comunicação.
Síntese
A FMEA expõe tanto as falhas barulhentas quanto as silenciosas; a agilidade, os híbridos, os runbooks de rollback e os critérios de saída tornam sobrevivíveis a mudança e a quebra de algoritmos.
Continue estudando — capítulo 28 de 40
← Capítulo 27 · Índice de capítulos do curso · Capítulo 29 →
Siga para a próxima lição escrita.