◇ OpenCyber Academy
Engenharia · Capítulo 5 · Português

Capítulo 5 — Comunicação em engenharia

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 5 — Comunicação em engenharia

Mapa da aula

Aula 05 publicada. Mapa, exemplo, EX013.

flowchart TD
  N0["5.1 Escrever para o conselho"]
  N1["5.2 Linguagem de segurança honesta"]
  N2["5.3 Registros de decisão"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX013"]

Desenho lógico

flowchart LR
  N0["5.1 Escrever para o conselho"]
  N1["5.2 Linguagem de segurança honesta"]
  N2["5.3 Registros de decisão"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX013"]
[5.1 Escrever para o conselho]
    |
    v
[5.2 Linguagem de segurança honesta]
    |
    v
[5.3 Registros de decisão]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX013]

Objetivos de aprendizagem

Você vai (1) explicar decisões criptográficas para não especialistas; (2) escrever um registro de decisão para uma escolha de gerenciamento de chaves; (3) evitar linguagem de segurança enganosa.

5.1 Escrever para o conselho

O conselho da Ridgeway inclui um agricultor, uma enfermeira aposentada e um contador. Aiyana precisa explicar por que os medidores precisam de leituras autenticadas. Ela começa pela decisão necessária, aprovar um orçamento para as chaves dos medidores, e depois enuncia o risco em palavras simples: sem autenticação, alguém poderia alterar as leituras e as contas. Ela define o jargão uma única vez: um código de autenticação de mensagem é uma tag curta que prova que uma leitura veio do medidor e não foi alterada. Marcus Webb lhe diz que o conselho não precisa da matemática, mas precisa saber o que pode dar errado e quanto custa evitar.

5.2 Linguagem de segurança honesta

Aiyana evita palavras como "inquebrável" ou "de nível militar", que prometem mais do que qualquer engenheiro pode entregar. Em vez disso, escreve que o HMAC-SHA256, especificado na RFC 2104 e no FIPS 198-1, é amplamente revisado e não tem ataques práticos conhecidos quando as chaves estão protegidas, e que o principal risco é o manuseio das chaves, e não o algoritmo. Ela lista o que o controle não faz: ele não esconde as leituras de quem escuta a comunicação, o que exigiria cifração. Afirmações precisas protegem a companhia quando auditores ou jornalistas perguntarem, mais tarde, o que foi prometido e por quê.

5.3 Registros de decisão

Aiyana escreve um registro de decisão para a primeira grande escolha: uma chave de autenticação única por medidor, derivada de uma chave mestra no serviço de chaves da companhia, em vez de uma chave compartilhada por todos os medidores. O registro informa contexto, opções, decisão, consequências, data e aprovador. Sua consequência principal é explícita: roubar a chave de um medidor permite a um atacante forjar apenas as leituras daquele medidor, e não as da frota inteira. Anos depois, quando um prestador de serviços propõe uma chave compartilhada para simplificar o provisionamento, o registro explica em dois minutos por que essa opção foi rejeitada.

Exemplo resolvido

A nota de uma página de Aiyana para o conselho pede um orçamento para o serviço de chaves, explica as leituras forjadas em palavras simples, evita "inquebrável" e remete a um registro de decisão que escolhe chaves por medidor.

Caso sintético. O conselho e a decisão são inventados; a RFC 2104 e o FIPS 198-1 são reais.

Erros e limites

Simplificar demais pode enganar: dizer "cifrado" quando os dados estão apenas autenticados é um erro factual. Registros sem as opções rejeitadas perdem metade do seu valor.

Exercícios

Síntese

Uma comunicação clara e honesta e registros de decisão tornam as escolhas criptográficas compreensíveis para quem decide e duráveis diante das mudanças na equipe.

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

← Capítulo 04 · Índice das aulas · Capítulo 06 →

Continue para a próxima aula já escrita.