Capítulo 39 — Segurança quântica e pós-quântica: manutenibilidade
Mapa da aula
Aula 39 publicada. Mapa, exemplo, EX077.
flowchart TD
N0["39.1 Agilidade como manutenibilidade"]
N1["39.2 Atividade prática — Laboratório A"]
N2["39.3 Aposentadoria"]
N3["39.4 Documentação e inventário"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX077"]
Desenho lógico
flowchart LR
N0["39.1 Agilidade como manutenibilidade"]
N1["39.2 Atividade prática — Laboratório A"]
N2["39.3 Aposentadoria"]
N3["39.4 Documentação e inventário"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX077"]
[39.1 Agilidade como manutenibilidade]
|
v
[39.2 Atividade prática — Laboratório A]
|
v
[39.3 Aposentadoria]
|
v
[39.4 Documentação e inventário]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX077]
Objetivos de aprendizagem
Você vai (1) projetar para a agilidade criptográfica, para que as mudanças futuras sejam baratas; (2) implementar a seleção de algoritmos orientada por política; (3) gerenciar a aposentadoria de algoritmos; e (4) manter o inventário e a documentação atualizados. O capítulo parte dos Capítulos 9, 18 e 27.
39.1 Agilidade como manutenibilidade
A transição pós-quântica não será a última: os conjuntos de parâmetros podem mudar, o HQC e o FN-DSA vão chegar e algum algoritmo pode enfraquecer. O CSWP 39 descreve a agilidade em protocolos, aplicações, hardware e infraestrutura. Sistemas manuteníveis fazem da mudança de algoritmo uma operação de rotina, medida em dias.
A meta da BPA é que trocar um algoritmo em qualquer serviço no escopo leve dias, não meses. O Laboratório A mostra o padrão em poucas linhas: um registro de implementações, uma política que escolhe uma delas e uma lista de aceitação que controla o que ainda é confiável. A métrica de tempo de substituição testa se esse projeto se sustenta nos sistemas reais, onde suposições fixas no código costumam se esconder.
39.2 Atividade prática — Laboratório A
# Lab A (ch 39): 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"meter reading 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
O laboratório usa MACs simétricos para manter o código curto; o padrão — registro, política, lista de aceitação, aposentadoria — é idêntico para KEMs e assinaturas.
Observe a ordem das etapas: o novo algoritmo é introduzido enquanto o antigo continua na lista de aceitação, para que as tags existentes ainda sejam verificadas; só então o algoritmo antigo é removido. Inverter a ordem quebraria todas as tags armazenadas de uma só vez. O identificador do algoritmo viaja com a tag, mas é verificado contra a política, então um atacante não consegue escolher um algoritmo fraco trocando o rótulo. Acrescente ao registro um terceiro algoritmo, deliberadamente fraco, e confirme que ele é rejeitado porque a política não o aceita.
39.3 Aposentadoria
Aposentar um algoritmo tem fases: parar de gerar novos usos; aceitar os usos antigos durante uma janela de transição; rejeitar após uma data; remover o código. Cada fase é uma mudança de política mais o monitoramento do uso residual.
Monitorar o uso residual diz à BPA quando é seguro passar à fase seguinte: se os handshakes somente clássicos caíram para um punhado de clientes conhecidos, a data de rejeição pode ser definida e esses clientes, contatados. Remover o código por último evita a reativação acidental por um erro de configuração. Cada fase tem uma data publicada com antecedência, para que os parceiros possam planejar.
39.4 Documentação e inventário
Mantenha o CBOM, os documentos de controle de interface, as políticas e os runbooks atualizados por meio de automação sempre que possível (geração do CBOM no build, painéis alimentados por telemetria). Uma documentação desatualizada torna a próxima migração tão difícil quanto a primeira.
A BPA trata a documentação como parte do sistema: um build que muda dependências criptográficas regenera o CBOM, e uma mudança de política atualiza o documento de controle de interface pelo mesmo pipeline. Quando a documentação precisa ser escrita à mão, como os runbooks, ela tem um responsável e uma data de revisão. O objetivo é que a próxima migração comece de um retrato preciso, e não de mais um projeto de descoberta.
39.5 Exemplo resolvido
A BPA mede o tempo de substituição trocando, por política, o algoritmo de MAC interno num serviço de teste: 2 dias, incluindo os testes. O mesmo exercício num serviço legado com algoritmos fixos no código leva 6 semanas — um argumento quantificado para a refatoração.
Dois dias contra seis semanas dão um fator de cerca de vinte, o que torna concreto o argumento da refatoração para quem detém o orçamento. As seis semanas vêm sobretudo de encontrar cada ponto de chamada fixo no código e testar cada um, o mesmo trabalho de que o serviço de documentos eletrônicos da BPA precisou para as suas 41 chamadas rsa_sign(). Refatorar uma vez remove esse custo de todas as mudanças futuras.
39.6 Erros comuns e limites
- Tratar a migração PQC como um projeto único.
- Aceitar identificadores de algoritmo vindos de entradas não confiáveis sem verificação de política.
- Aposentar algoritmos sem monitorar o uso residual.
Tratar a migração PQC como um projeto único deixa os sistemas tão rígidos quanto antes, prontos para repetir o esforço quando o HQC ou o FN-DSA chegarem. Aceitar identificadores de algoritmo vindos de entradas não confiáveis permite que um atacante escolha a opção mais fraca, o que o Laboratório A impede com a sua lista de aceitação. Aposentar sem monitorar arrisca quebrar clientes que ainda dependem do algoritmo antigo, o que a BPA evita publicando as datas de rejeição apenas depois que o uso residual está perto de zero.
Nota de engenharia
A agilidade também é contratual. A linguagem das compras deve exigir que os fornecedores suportem a substituição de algoritmos por configuração, publiquem os inventários criptográficos dos seus produtos, forneçam atualizações de segurança para novos algoritmos dentro de prazos declarados e divulguem as bibliotecas que embutem. A BPA acrescenta essas cláusulas a todo contrato novo de equipamentos e software; ao longo de um ciclo de renovação de hardware, a parcela dos ativos que pode trocar de algoritmo sem substituição cresce, e a próxima migração fica mais barata por projeto.
Exercícios
- EX077 — Ampliar o Laboratório A. Acrescente um terceiro algoritmo e uma verificação de data de aposentadoria. Rubrica: 3 = funciona e falha de forma fechada após a data.
- EX078 — Tempo de substituição. Projete uma medição do tempo de substituição para o KEM de borda da BPA. Rubrica: 3 = eventos de início e fim e evidências definidos.
Síntese
Manutenibilidade significa agilidade: algoritmos orientados por política, aposentadoria em fases, inventário atualizado e um tempo de substituição medido.
Continue estudando — capítulo 39 de 50
← Capítulo 38 · Índice de capítulos do curso · Capítulo 40 →
Siga para a próxima lição escrita.