Capítulo 8 — Segurança quântica e pós-quântica: casos difíceis
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX036.
flowchart TD
N0["8.1 Dispositivos médicos e embarcados"]
N1["8.2 PKI interna"]
N2["8.3 Assinaturas baseadas em hash com estado"]
N3["8.4 Assinaturas e arquivos de longo prazo"]
N4["8.5 Resposta à quebra de um algoritmo"]
N5["8.6 Caso resolvido"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX036"]
Desenho lógico
flowchart LR
N0["8.1 Dispositivos médicos e embarcados"]
N1["8.2 PKI interna"]
N2["8.3 Assinaturas baseadas em hash com estado"]
N3["8.4 Assinaturas e arquivos de longo prazo"]
N4["8.5 Resposta à quebra de um algoritmo"]
N5["8.6 Caso resolvido"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX036"]
[8.1 Dispositivos médicos e embarcados]
|
v
[8.2 PKI interna]
|
v
[8.3 Assinaturas baseadas em hash com estado]
|
v
[8.4 Assinaturas e arquivos de longo prazo]
|
v
[8.5 Resposta à quebra de um algoritmo]
|
v
[8.6 Caso resolvido]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX036]
Objetivos de aprendizagem
Você vai (1) analisar migrações que envolvem dispositivos médicos e embarcados, a PKI interna, arquivos de longo prazo e terceiros; (2) aplicar controles compensatórios onde a migração é impossível; (3) gerenciar as assinaturas baseadas em hash com estado; (4) planejar a validade das assinaturas de longo prazo; e (5) raciocinar sobre a resposta à quebra de um algoritmo.
8.1 Dispositivos médicos e embarcados
Os dispositivos têm aprovações regulatórias, vidas longas e firmware controlado pelo fornecedor. Mudar a criptografia pode exigir uma nova certificação. Opções: firmware do fornecedor com troca de chaves híbrida, onde oferecido; segmentação da rede e gateways que terminam os protocolos pós-quânticos na frente dos dispositivos; fluxos de dados minimizados; e requisitos de compras para as substituições. A segurança dos pacientes governa as janelas de mudança.
Na NRHT, a frota de bombas de infusão ilustra as escolhas: a troca de chaves híbrida chega com uma versão de firmware do fornecedor depois de testes clínicos, enquanto a verificação de boot não pode mudar e é tratada com controles compensatórios até a substituição. Acorde as janelas de mudança com a engenharia clínica e registre os testes de segurança feitos antes de cada atualização.
8.2 PKI interna
A PKI interna ancora as VPNs, as identidades dos dispositivos e o TLS entre serviços. Um plano de PKI pós-quântica: montar uma raiz e intermediárias ML-DSA em HSMs que suportem a FIPS 204; distribuir a nova raiz às partes confiantes; emitir certificados pós-quânticos primeiro nos ecossistemas fechados; manter a hierarquia clássica em paralelo; e definir datas de término para a emissão clássica alinhadas à norma interna.
Planeje a distribuição da nova raiz a todas as partes confiantes antes de emitir a partir dela; uma raiz em que os clientes não confiam quebra os serviços. Teste primeiro a emissão e a validação num laboratório com clientes representativos. Registre no plano quais ecossistemas mudam primeiro e a data em que a emissão clássica termina para cada um.
8.3 Assinaturas baseadas em hash com estado
A SP 800-208 aprova o LMS e o XMSS com o requisito de que as chaves e o estado sejam gerenciados em módulos de hardware e não sejam exportados. Elas servem para a assinatura de firmware. Planeje a capacidade de assinaturas, proteja o estado contra o retrocesso durante o failover dos HSMs e teste a recuperação de desastres para que a recuperação nunca reutilize um índice.
Registre o número de assinaturas que cada chave consegue produzir e acompanhe o uso em relação a ele. Teste o failover dos HSMs de um modo que prove que o estado não pode retroceder, porque reutilizar um índice quebra a segurança. Mantenha o plano junto com o procedimento de assinatura de firmware e revise-o depois de cada mudança nos HSMs.
8.4 Assinaturas e arquivos de longo prazo
Os documentos clínicos assinados e os formulários de consentimento precisam continuar verificáveis por décadas. Os carimbos de tempo de arquivo e a renovação dos registros de evidência podem preservar a validade ao longo das transições de algoritmo, desde que a renovação aconteça enquanto o algoritmo mais antigo ainda for confiável. Os arquivos cifrados já expostos em trânsito não podem ser reparados pela recifração.
Agende a renovação bem antes que o algoritmo mais antigo deixe de ser confiável, e registre cada renovação. Nos arquivos cifrados, distinga os dados em repouso, que podem ser recifrados, das cópias que atravessaram redes sob troca de chaves clássica, que não podem ser reparadas. Relate as duas no registro de riscos.
8.5 Resposta à quebra de um algoritmo
O Rainbow (Beullens, 2022) e o SIKE (Castryck e Decru, 2022) mostram que esquemas candidatos podem cair rapidamente; o KyberSlash (Bernstein et al., 2024) mostra que as implementações podem vazar. Um plano de resposta nomeia o fórum de decisão, os caminhos de configuração para desativar um algoritmo, os sistemas que precisam de novas versões ou de hardware, o fallback (os híbridos ajudam) e as comunicações aos fornecedores e aos reguladores. A seleção do HQC como KEM de reserva oferece uma alternativa futura com uma base matemática diferente.
Ensaie o plano uma vez por ano com um exercício de mesa, usando um caso realista, como uma fraqueza encontrada numa implementação do ML-KEM. Registre quanto tempo leva para desativar o algoritmo em cada plataforma; as plataformas que levam mais tempo são as primeiras candidatas à agilidade orientada por política.
8.6 Caso resolvido
A frota de bombas de infusão da NRHT (sintética, 4.000 unidades) usa firmware assinado com RSA, verificado por uma ROM de boot, e ECDH com um hub de gestão. O fornecedor oferece a troca de chaves híbrida numa versão de firmware de 2027; a verificação de boot não pode mudar. Plano: segmentar as bombas numa VLAN dedicada; adotar o firmware de 2027 depois dos testes de segurança clínica; aceitar o risco residual de falsificação posterior no firmware até a substituição da frota em 2031, com controles compensatórios (lista de atualizações assinadas permitidas no hub, monitoramento de anomalias); exigir a verificação de boot com ML-DSA ou LMS na licitação da substituição.
Registre o risco residual no registro com a sua expiração vinculada à substituição de 2031, e revise-o se a data da substituição atrasar. Garanta que o requisito de verificação de boot pós-quântica da licitação da substituição seja escrito nas compras agora.
8.7 Erros comuns e limites
- Aplicar as janelas de mudança de TI aos dispositivos clínicos.
- Construir uma raiz pós-quântica sem um plano de distribuição às partes confiantes.
- Assinatura LMS apenas em software.
Cada erro tem uma salvaguarda neste capítulo. Acorde as janelas de mudança clínicas com a engenharia clínica. Escreva o plano de distribuição às partes confiantes antes de montar uma raiz pós-quântica. Mantenha as chaves e o estado do LMS e do XMSS em módulos de hardware, como a SP 800-208 exige, e teste o failover. Na NRHT, o plano de firmware das bombas foi acordado com a engenharia clínica, a raiz ML-DSA interna tem um plano de distribuição às partes confiantes, e as chaves de assinatura de firmware ficam em módulos de hardware, com o failover testado para que nenhum índice seja reutilizado.
Exercícios
- EX036 — Controles compensatórios. Liste quatro controles compensatórios para os dispositivos que não podem migrar. Rubrica: 3 = quatro controles distintos e eficazes.
- EX037 — Sequência da PKI. Ordene os passos do plano da PKI e justifique a ordem. Rubrica: 3 = raiz, distribuição, ecossistemas fechados, emissão ampla, encerramento do clássico.
- EX038 — Capacidade do LMS. Uma árvore LMS com 2^15 assinaturas assina 40 imagens de firmware por ano. Quantos anos de capacidade? Rubrica: 3 = 819 anos, com comentário sobre várias árvores/failover dos HSMs.
- EX039 — Momento da renovação do arquivo. Quando a NRHT deve renovar os registros de evidência do arquivo baseados em carimbos de tempo assinados com RSA? Rubrica: 3 = bem antes de uma fraqueza crível do RSA, calendário definido por política.
- EX040 — Simulação de quebra. Projete um exercício de mesa para "fraqueza anunciada no ML-KEM-768". Rubrica: 3 = cenário, participantes, decisões, critérios de sucesso.
Síntese
Os casos difíceis — dispositivos, PKI, assinaturas com estado, arquivos e quebras de algoritmos — precisam de controles compensatórios, sequenciamento cuidadoso, estado guardado em hardware, renovação no tempo certo e resposta ensaiada.
Continue estudando — capítulo 08 de 12
← Capítulo 07 · Índice de capítulos do curso · Capítulo 09 →
Siga para a próxima lição escrita.