Capítulo 32 — Segurança quântica e pós-quântica: confiabilidade
Mapa da aula
Aula 32 publicada. Mapa, exemplo, EX063.
flowchart TD
N0["32.1 Riscos de confiabilidade"]
N1["32.2 Fallback seguro"]
N2["32.3 Capacidade dos esquemas com estado"]
N3["32.4 Falhas silenciosas"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX063"]
Desenho lógico
flowchart LR
N0["32.1 Riscos de confiabilidade"]
N1["32.2 Fallback seguro"]
N2["32.3 Capacidade dos esquemas com estado"]
N3["32.4 Falhas silenciosas"]
N4["Nota de engenharia"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX063"]
[32.1 Riscos de confiabilidade]
|
v
[32.2 Fallback seguro]
|
v
[32.3 Capacidade dos esquemas com estado]
|
v
[32.4 Falhas silenciosas]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX063]
Objetivos de aprendizagem
Você vai (1) identificar os riscos de confiabilidade trazidos por mensagens maiores e novos caminhos de código; (2) projetar um comportamento de fallback e de novas tentativas que preserve a segurança; (3) planejar a capacidade dos esquemas de assinatura com estado; e (4) monitorar falhas silenciosas. O capítulo parte dos Capítulos 23 e 30.
32.1 Riscos de confiabilidade
Riscos novos: fragmentação e descartes por middleboxes; timeouts em dispositivos restritos e lentos; falhas na interpretação de certificados; bugs de biblioteca em código novo; chaves de assinatura com estado esgotadas; limites de desempenho dos HSMs. Cada um precisa de detecção e de resposta.
Cada risco tem um sinal correspondente: os descartes aparecem como falhas de handshake por caminho, os timeouts como caudas de latência em classes de dispositivos, as falhas de interpretação como erros de certificado nos logs dos clientes e as chaves com estado esgotadas como um contador se aproximando do limite. O plano de monitoramento da BPA lista o sinal, o limiar e o responsável por cada risco, para que um alerta chegue a alguém que sabe o que fazer, e não a uma fila genérica.
32.2 Fallback seguro
O fallback pode preservar a disponibilidade, mas não pode criar um rebaixamento silencioso. Regras de projeto: fallback apenas para algoritmos aprovados; registrar cada fallback com o motivo; alertar quando as taxas de fallback subirem; definir uma data de expiração para a permissão de fallback; nunca fazer fallback em falhas de autenticação, apenas em incompatibilidade demonstrável.
A última regra é crítica: uma falha de autenticação pode sinalizar um ataque, então tentar de novo com configurações mais fracas daria ao atacante o que ele quer. O portal da BPA, por isso, só faz fallback após um reset de conexão num caminho listado como incompatível, nunca após um erro de certificado ou de assinatura.
32.3 Capacidade dos esquemas com estado
Uma chave LMS com árvore de altura 20 suporta cerca de um milhão de assinaturas; uma árvore de altura 10, cerca de mil. A capacidade precisa exceder, com margem, o volume de assinaturas esperado ao longo da vida da chave; alertas de monitoramento em limiares (por exemplo, 70% usados) disparam uma troca de chave planejada.
A altura da árvore troca capacidade por tempo de geração da chave e tamanho da assinatura: cada nível a mais dobra a capacidade e acrescenta um pouco a cada assinatura. Como a troca de chave exige distribuir antecipadamente uma nova chave pública aos dispositivos, o limiar de alerta precisa deixar assinaturas restantes suficientes para cobrir esse período de distribuição.
32.4 Falhas silenciosas
A pior falha de confiabilidade é a segurança desativada em silêncio: uma configuração que, por causa de um erro de digitação, faz fallback para apenas o clássico em todo lugar. Monitorar os grupos negociados (Capítulo 29) detecta isso.
A BPA se protege disso com uma verificação diária que compara a parcela híbrida negociada com a da semana anterior; uma queda repentina para perto de zero dispara um alerta mesmo que nenhuma conexão tenha falhado. As mudanças de configuração na política criptográfica também exigem um segundo revisor, o que detecta erros de digitação antes da implantação. Uma falha silenciosa não pode ser vista nos logs de erro, porque nada dá erro; ela só pode ser detectada medindo o que é negociado.
32.5 Exemplo resolvido
A BPA assina cerca de 2.000 imagens de firmware por ano, somando todas as famílias de dispositivos. Uma árvore LMS de altura 15 (32.768 assinaturas) por local de assinatura dura mais de uma década no volume atual; a equipe ainda assim define alertas em 50% e 80% e documenta a troca para uma nova chave, com distribuição antecipada da sua chave pública.
A 2.000 assinaturas por ano, uma árvore de 32.768 assinaturas dura cerca de dezesseis anos por local, e é por isso que a capacidade não é a restrição. Os alertas ainda importam, porque o volume pode mudar, por exemplo se uma nova família de dispositivos for acrescentada. Distribuir cedo a próxima chave pública significa que a troca de chave não exige nenhuma atualização de firmware emergencial.
32.6 Erros comuns e limites
- Fallback sem registro nem expiração.
- Chaves com estado subdimensionadas.
- Monitorar a configuração em vez da negociação.
Um fallback sem registro e sem expiração transforma uma ferramenta de transição num caminho permanente de rebaixamento. Uma chave LMS pequena demais se esgota antes que os dispositivos possam receber uma nova chave pública, deixando sem nenhuma forma de assinar atualizações. Monitorar a configuração em vez da negociação deixa escapar as falhas silenciosas descritas acima, em que tudo parece ativado, mas nada está protegido. Cada um desses erros foi visto nas primeiras implantações de outras organizações, e é por isso que o plano da BPA nomeia um controle para cada um.
Nota de engenharia
As revisões de confiabilidade também devem cobrir relógios e expirações. Certificados de transição, PSKs com datas de rotação e permissões de fallback expiram por projeto; se a automação de renovação falhar, o resultado é uma interrupção que parece uma falha criptográfica. Registre as expirações no sistema de monitoramento, com alertas a 30, 14 e 3 dias, e teste os caminhos de renovação no ambiente réplica, porque a primeira renovação do certificado de um algoritmo novo é um lugar clássico para aparecerem incompatibilidades de interpretação ou de política.
Exercícios
- EX063 — Política de fallback. Escreva uma política de fallback para o TLS de borda que satisfaça as regras de 32.2. Rubrica: 3 = as cinco regras incorporadas.
- EX064 — Capacidade. Um local assina 15 documentos por minuto, continuamente, com LMS. Uma árvore de altura 20 basta para um ano? Rubrica: 3 = 7,9 milhões de assinaturas/ano > 1.048.576 — não basta; propõe HSS/várias árvores ou ML-DSA.
Síntese
A engenharia de confiabilidade em PQC antecipa falhas de tamanho e de caminhos de código, projeta um fallback registrado, com expiração e seguro quanto à autenticação, dimensiona as chaves com estado com margem e monitora os resultados negociados.
Continue estudando — capítulo 32 de 50
← Capítulo 31 · Índice de capítulos do curso · Capítulo 33 →
Siga para a próxima lição escrita.