Capítulo 21 — Criptografia e serviços de confiança: requisitos | Engenharia Criptografia e serviços de confiança

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Capítulo 21 — Criptografia e serviços de confiança: requisitos

Mapa da aula

Aula 21 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["21.1 Enunciados verificáveis"]
  N1["21.2 Apoiar-se nas normas"]
  N2["21.3 Requisitos de garantia"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["21.1 Enunciados verificáveis"]
  N1["21.2 Apoiar-se nas normas"]
  N2["21.3 Requisitos de garantia"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX061"]

[21.1 Enunciados verificáveis]
    |
    v
[21.2 Apoiar-se nas normas]
    |
    v
[21.3 Requisitos de garantia]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem

Você vai (1) escrever requisitos criptográficos verificáveis; (2) derivar das normas os requisitos de algoritmo e de tamanho de chave; (3) separar requisitos funcionais de requisitos de garantia.

21.1 Enunciados verificáveis

Aiyana reescreve metas vagas como requisitos verificáveis. "As leituras devem ser seguras" vira "Toda leitura carrega uma tag HMAC-SHA256 calculada com uma chave por medidor de 256 bits; o serviço de faturamento rejeita qualquer leitura cuja tag falhe na verificação." Cada requisito nomeia a propriedade, o mecanismo, o parâmetro e o comportamento observável. Um testador consegue conferi-lo sem adivinhar o que "seguro" queria dizer. Ela evita requisitos que ditam desnecessariamente detalhes de implementação, para que os fornecedores possam atendê-los de formas diferentes, mas é precisa onde a precisão evita usos indevidos, como no tamanho da chave e no comportamento da verificação.

21.2 Apoiar-se nas normas

Para as escolhas de algoritmo, Aiyana cita normas, e não preferências: AES-256-GCM segundo o FIPS 197 e o SP 800-38D para cifrar dados de configuração; SHA-256 segundo o FIPS 180-4; ECDSA P-256 segundo o FIPS 186-5 ou Ed25519 segundo a RFC 8032 para as assinaturas de firmware; TLS 1.3 segundo a RFC 8446 para os concentradores. Os tamanhos de chave e os criptoperíodos seguem o SP 800-57 Part 1. Ela acrescenta um requisito voltado ao futuro: o projeto de assinatura do firmware deve permitir a migração para assinaturas pós-quânticas, como o ML-DSA do FIPS 204, sem substituir os medidores. Citar normas também permite aos auditores conferir as escolhas contra critérios públicos, e não contra as preferências da equipe, e simplifica revisões futuras quando as orientações mudarem.

21.3 Requisitos de garantia

Os requisitos funcionais dizem o que o sistema faz; os requisitos de garantia dizem como a Ridgeway saberá que isso foi feito corretamente. Aiyana acrescenta itens de garantia: as bibliotecas devem vir de projetos mantidos, com avisos de segurança; os módulos de segurança de hardware devem ter um certificado de validação reconhecido; testadores independentes devem tentar forjar leituras antes da entrada em produção; as cerimônias de chaves devem ter duas testemunhas e ata registrada. Esses requisitos custam dinheiro e tempo, então ela os classifica por risco e registra quais são obrigatórios para o piloto e quais para a implantação completa.

Exemplo resolvido

O conjunto de requisitos de Aiyana especifica HMAC-SHA256 com chaves de 256 bits, algoritmos apoiados em normas, um caminho de migração pós-quântica e itens de garantia classificados.

Caso sintético. O conjunto de requisitos da Ridgeway é inventado; as normas citadas são reais.

Erros e limites

Especificar demais a implementação pode bloquear projetos melhores; especificar de menos os parâmetros convida a escolhas fracas. Os requisitos precisam de revisão periódica à medida que as normas mudam.

Exercícios

EX061 — Reescrever uma meta. Reescreva "as leituras devem ser seguras" como um requisito verificável. Rubrica: 3 = nomeia HMAC-SHA256, chave por medidor de 256 bits, rejeição quando a verificação falha;; 2 = mecanismo parcial;; 1 = vago;; 0 = nenhuma.
EX062 — Normas de assinatura. Que normas sustentam as opções de assinatura do firmware? Rubrica: 3 = FIPS 186-5 (ECDSA P-256) ou RFC 8032 (Ed25519);; 2 = uma;; 1 = vago;; 0 = nenhuma.
EX063 — Exemplo de garantia. Dê dois requisitos de garantia. Rubrica: 3 = dois entre bibliotecas mantidas, HSMs validados, testes independentes de falsificação, cerimônias com testemunhas;; 2 = um;; 1 = item funcional;; 0 = nenhuma.

Síntese

Bons requisitos criptográficos são verificáveis, fundamentados em normas, prontos para a migração e acompanhados de evidências de garantia.

Continue estudando — aula 21 (capítulo 21 de 50)

← Capítulo 20 · Índice das aulas · Capítulo 22 →

Continue para a próxima aula já escrita.