Capítulo 35 — Ateliê de projeto II
Mapa da aula
Aula 35 publicada. Mapa, exemplo, EX069.
flowchart TD
N0["35.1 Enunciado"]
N1["35.2 Esboço da solução de referência"]
N2["35.3 Crítica da banca"]
N3["Nota de engenharia"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX069"]
Desenho lógico
flowchart LR
N0["35.1 Enunciado"]
N1["35.2 Esboço da solução de referência"]
N2["35.3 Crítica da banca"]
N3["Nota de engenharia"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX069"]
[35.1 Enunciado]
|
v
[35.2 Esboço da solução de referência]
|
v
[35.3 Crítica da banca]
|
v
[Nota de engenharia]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX069]
Objetivos de aprendizagem
Você vai (1) projetar a autenticação pós-quântica de um ecossistema de documentos e firmware; (2) escolher entre ML-DSA, SLH-DSA e assinaturas baseadas em hash com estado; (3) projetar a validação de longo prazo com carimbos de tempo; e (4) defender o projeto diante de uma banca. O capítulo integra os Capítulos 26–34.
35.1 Enunciado
Projete assinaturas pós-quânticas para (a) os conhecimentos de embarque eletrônicos da BPA, verificáveis por 12 anos por parceiros e tribunais, e (b) o firmware de 3.000 dispositivos de campo, com vida útil de 10–20 anos e bootloaders restritos. Restrições: o software de verificação dos parceiros varia; alguns dispositivos não podem ser atualizados além de mais uma versão do bootloader.
As duas partes diferem na sua restrição principal. Os conhecimentos de embarque precisam ser verificáveis por tribunais e parceiros com software que a BPA não controla, então a compatibilidade e a evidência de longo prazo são o que mais importa. Os dispositivos de firmware podem receber apenas mais uma atualização de bootloader, então o que for escolhido agora precisa durar o restante da vida do dispositivo. As equipes que tratam as duas partes como um único problema costumam escolher um único algoritmo que não serve bem a nenhuma delas.
35.2 Esboço da solução de referência
(a) Conhecimentos de embarque: assinar com ML-DSA-65 ao lado da assinatura ECDSA existente durante a transição (assinaturas duplas no formato do documento), acrescentar carimbos de tempo confiáveis e planejar o recarimbo (renovação do carimbo de tempo de arquivo), para que a evidência continue válida se um algoritmo enfraquecer. (b) Firmware: a versão final do bootloader aceita duas chaves de verificação — LMS (SP 800-208, apenas verificação no dispositivo, assinatura no HSM com controle de estado) e ML-DSA-44 —, para que o comprometimento ou a quebra de uma deixe a outra; assinar cada imagem com as duas.
As duas partes usam dois algoritmos pelo mesmo motivo: vida longa sem segunda chance.
35.3 Crítica da banca
O jurídico pergunta se as assinaturas duplas confundem os tribunais — resposta: a política do documento declara que qualquer uma das assinaturas válidas basta durante a transição, e que as duas são exigidas após uma data. As operações perguntam pela vazão de assinaturas — a capacidade do LMS é dimensionada conforme o Capítulo 32. A segurança pergunta por que não o SLH-DSA para o firmware — as suas assinaturas maiores (7,8 kB ou mais na variante pequena) podem exceder os orçamentos de tempo de boot e de armazenamento nos menores dispositivos, mas ele continua candidato para os outros.
Cada resposta remete a uma decisão já tomada, que é o que a banca quer ver: evidências, não opiniões novas.
35.4 Erros comuns e limites
- Âncoras de confiança de um único algoritmo em dispositivos que não podem ser atualizados de novo.
- Ignorar a validação de longo prazo e a renovação dos carimbos de tempo.
- Escolher assinaturas com estado sem capacidade de gerenciamento de estado.
Dispositivos que não podem receber outra atualização de bootloader precisam de duas âncoras de confiança agora, já que não haverá chance posterior de acrescentar uma. A evidência jurídica precisa continuar válida por doze anos, o que exige a renovação dos carimbos de tempo se um algoritmo enfraquecer. Assinaturas com estado sem estado imposto pelo HSM arriscam a reutilização de índices após uma restauração, então as equipes sem essa capacidade devem preferir o ML-DSA ou o SLH-DSA.
Nota de engenharia
A validação de longo prazo merece um teste próprio. Simule a verificação de um conhecimento de embarque num ano futuro, configurando a política do verificador para rejeitar o ECDSA e aceitar apenas o ML-DSA e os carimbos de tempo renovados; os documentos assinados no início da transição ainda precisam ser validados pela sua cadeia de carimbos de tempo de arquivo. Executar esse teste agora revela se o formato do documento, a autoridade de carimbo de tempo e o software verificador realmente suportam as regras de transição que o jurídico aprovou no papel.
Exercícios
- EX069 — Projeto do documento. Especifique os campos de assinatura e a política de validação dos conhecimentos de embarque com assinatura dupla. Rubrica: 3 = regras de transição e renovação dos carimbos de tempo.
- EX070 — Chaves do bootloader. Justifique o projeto de bootloader com dois algoritmos e o seu custo. Rubrica: 3 = benefício da diversidade vs. tamanho do código e custo de assinatura.
Síntese
A autenticação de vida longa precisa de diversidade de algoritmos, carimbos de tempo com renovação e escolhas de assinatura adequadas às restrições dos dispositivos e à capacidade de gerenciamento de estado.
Continue estudando — capítulo 35 de 50
← Capítulo 34 · Índice de capítulos do curso · Capítulo 36 →
Siga para a próxima lição escrita.