Capítulo 19 — Identidade e criptografia
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX018.
flowchart TD
N0["19.1 Primitivas"]
N1["19.2 Autenticando a telemetria"]
N2["19.3 Gestão de chaves"]
N3["19.4 Identidade para pessoas e dispositivos"]
N4["19.6 Atividade prática: Laboratório 8"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX018"]
Desenho lógico
flowchart LR
N0["19.1 Primitivas"]
N1["19.2 Autenticando a telemetria"]
N2["19.3 Gestão de chaves"]
N3["19.4 Identidade para pessoas e dispositivos"]
N4["19.6 Atividade prática: Laboratório 8"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX018"]
[19.1 Primitivas]
|
v
[19.2 Autenticando a telemetria]
|
v
[19.3 Gestão de chaves]
|
v
[19.4 Identidade para pessoas e dispositivos]
|
v
[19.6 Atividade prática: Laboratório 8]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX018]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) explicar a criptografia simétrica e a de chave pública, hashes e MACs, e escolher entre eles; (2) projetar a autenticação de mensagens com proteção contra repetição para uma telemetria com recursos limitados; (3) planejar a gestão de chaves — geração, distribuição, armazenamento, rotação, revogação — para uma frota de campo; e (4) projetar identidade e autenticação para pessoas e dispositivos. Ele se apoia nos capítulos 4, 13 e 18 e prepara os capítulos 27–28.
19.1 Primitivas
- As funções de hash (SHA-256, FIPS 180-4) mapeiam dados para um resumo de tamanho fixo; encontrar colisões ou pré-imagens deve ser inviável. Um hash sozinho não autentica nada.
- A cifração simétrica (AES, FIPS 197) usa uma única chave compartilhada para a confidencialidade.
- Os códigos de autenticação de mensagem (HMAC, FIPS 198-1; RFC 2104) permitem a quem detém uma chave compartilhada verificar que uma mensagem não foi alterada e veio de alguém que detém a chave.
- A criptografia de chave pública, introduzida por Diffie and Hellman (1976) e realizada para assinaturas por Rivest, Shamir and Adleman (1978), usa pares de chaves: qualquer um pode verificar uma assinatura com a chave pública; só quem detém a chave privada pode assinar.
- A cifração autenticada (por exemplo, AES-GCM) fornece confidencialidade e integridade juntas.
Nunca projete suas próprias primitivas ou protocolos quando um padrão servir; o TLS 1.3 (RFC 8446) é o padrão para enlaces IP que conseguem executá-lo.
19.2 Autenticando a telemetria
Para um enlace com recursos limitados, um projeto comum é: carga útil mais um contador monotônico (ou um carimbo de tempo), um MAC sobre ambos, o receptor verifica o MAC em tempo constante e depois verifica se o contador é maior do que o último valor aceito. O contador derrota a repetição; um carimbo de tempo com uma janela de atualidade derrota ataques de atraso, mas exige relógios sincronizados. Truncar o HMAC-SHA256 para 128 bits é comum por causa da largura de banda, com uma margem contra falsificação correspondentemente reduzida, mas ainda muito grande. Persista o último contador ou troque as chaves no reinício, ou um reinício reabre a repetição (EX018).
19.3 Gestão de chaves
As chaves são onde a criptografia encontra as operações. Decida: quem gera as chaves e onde (de preferência em hardware, nunca à mão); como elas chegam aos dispositivos (provisionamento de fábrica, cadastro seguro); onde ficam armazenadas (elementos seguros, não arquivos de configuração); como são trocadas (de forma agendada e após suspeita de comprometimento); como são revogadas; e quem pode acessá-las. Uma chave por par de dispositivos limita o raio de impacto: comprometer uma RTU não deve permitir que um atacante se passe por outra. Uma única chave para toda a frota é uma causa comum com $\beta \approx 1$ (Capítulo 7).
19.4 Identidade para pessoas e dispositivos
As pessoas precisam de contas nominais, autenticação forte (multifator resistente a phishing onde for possível — veja o NIST SP 800-63B), papéis mapeados a tarefas e remoção imediata quando saem. Os dispositivos também precisam de identidades — certificados ou chaves provisionadas — para que um gateway saiba com qual RTU está falando. Credenciais compartilhadas ou padrão são a falha de identidade mais comum na TO. No TMRP, os operadores usam contas nominais com autenticação forte nos servidores SCADA, e cada RTU tem sua própria chave, de modo que o gateway sabe qual estação enviou cada mensagem.
19.5 Exemplo resolvido: o formato de mensagem do TMRP (sintético)
O ADR-007 escolheu HMAC com contadores. O quadro do Laboratório 8 leva um contador de 8 bytes, um ID de estação de 2 bytes, um nível de 2 bytes e um HMAC-SHA256 truncado de 16 bytes: 28 bytes, dos quais 22 são sobrecarga em relação a uma carga útil de 6 bytes sem autenticação. As chaves por estação são geradas no elemento seguro do gateway no cadastro e armazenadas no repositório de chaves da RTU; o lado do SCADA as mantém num módulo de segurança de hardware (HSM). As chaves são trocadas anualmente e imediatamente diante de suspeita de comprometimento; o contador é persistido em memória não volátil a cada incremento de 1.000, com um salto à frente no reinício, de modo que a repetição de mensagens antigas continua impossível.
19.6 Atividade prática: Laboratório 8
# Lab 8 - authenticated telemetry with a counter: tamper and replay are rejected (synthetic key, offline)
import hmac, hashlib, struct
KEY = bytes.fromhex("00112233445566778899aabbccddeeff00112233445566778899aabbccddeeff") # demo key only
def seal(ctr, station, level_cm):
body = struct.pack(">QHH", ctr, station, level_cm)
return body + hmac.new(KEY, body, hashlib.sha256).digest()[:16]
class Receiver:
def __init__(self): self.last = {}
def accept(self, msg):
body, tag = msg[:12], msg[12:]
if not hmac.compare_digest(tag, hmac.new(KEY, body, hashlib.sha256).digest()[:16]): return "reject: tag"
ctr, st, lvl = struct.unpack(">QHH", body)
if ctr <= self.last.get(st, -1): return "reject: replay"
self.last[st] = ctr; return f"ok st={st} ctr={ctr} level={lvl}cm"
r = Receiver(); m1, m2 = seal(1, 3, 312), seal(2, 3, 309)
forged = m2[:10] + struct.pack(">H", 150) + m2[12:]
for name, m in [("m1", m1), ("m2", m2), ("replay m1", m1), ("forged", forged)]: print(f"{name:10}", r.accept(m))
print("frame bytes:", len(m1), "overhead vs 6-byte payload:", len(m1) - 6)
Saída esperada:
m1 ok st=3 ctr=1 level=312cm
m2 ok st=3 ctr=2 level=309cm
replay m1 reject: replay
forged reject: tag
frame bytes: 28 overhead vs 6-byte payload: 22
A chave do laboratório é um valor de demonstração publicado; chaves reais nunca devem aparecer no código-fonte.
As duas primeiras mensagens da estação três são aceitas, com contadores crescentes. A repetição da primeira mensagem é recusada porque seu contador não é maior do que o último valor aceito, e a mensagem forjada, com o nível alterado de 309 para 150 centímetros, reprova na verificação da etiqueta. A última linha confirma o tamanho de quadro usado no ADR-007: vinte e oito bytes, vinte e dois deles de sobrecarga. O laboratório mantém o estado apenas na memória, e é por isso que o EX018 pergunta o que acontece após um reinício.
19.7 Erros comuns e limites
- Hashes ou CRCs usados como se fossem MACs.
- Comparação de etiquetas que não é em tempo constante.
- Proteção contra repetição perdida no reinício.
- Chaves compartilhadas por toda a frota; chaves em arquivos de configuração ou no código-fonte.
- Senhas padrão e contas compartilhadas.
- Escolhas criptográficas sem um plano para a vida útil do sistema (agilidade de algoritmos).
O projeto do TMRP responde a cada item: as etiquetas são comparadas em tempo constante, os contadores persistem entre reinícios, as chaves são por estação, em hardware seguro, e o formato de mensagem ganha um identificador de suíte para futuras mudanças de algoritmo. Cada escolha tem um teste.
Exercícios — capítulo 19
EX037 — Persistência do contador. Objetivo: projetar uma proteção contra repetição segura diante de reinícios. Entradas: §19.5 (persistir a cada 1.000 incrementos). Passos: explique por que a RTU precisa saltar à frente no reinício e em quanto, no mínimo; diga o que o receptor precisa persistir. Evidência esperada: explicação. Rubrica: 3 = salto ≥ 1.000 além do último valor persistido, para que nenhum contador seja reutilizado, receptor persiste o último aceito por estação ou troca as chaves; 2 = apenas um dos lados; 1 = vago; 0 = nada.
EX038 — Raio de impacto. Objetivo: comparar projetos de chaves. Entradas: 42 estações de campo; opção A, uma chave para a frota; opção B, uma chave por estação. Passos: compare a consequência de extrair uma chave de uma RTU roubada, o esforço de rotação após esse roubo e o armazenamento necessário no SCADA. Evidência esperada: tabela e recomendação. Rubrica: 3 = A permite ao ladrão forjar qualquer estação e força a rotação em toda a frota; B confina a falsificação a uma estação, com uma rotação; armazenamento trivial; recomendação B; 2 = falta uma dimensão; 1 = recomendação sem raciocínio; 0 = nada.
Síntese do capítulo
Escolha primitivas padrão para a propriedade de que você precisa: hashes para impressões digitais, MACs ou assinaturas para autenticidade, cifração autenticada para confidencialidade com integridade. Acrescente atualidade para derrotar a repetição e mantenha-a entre reinícios. A gestão de chaves é o sistema de verdade: chaves por dispositivo em hardware, rotação e revogação. Dê a pessoas e dispositivos identidades distintas e fortemente autenticadas.
Continue estudando — capítulo 19 de 50
← Capítulo 18 · Índice de capítulos do curso · Capítulo 20 →
Siga para a próxima lição escrita.