Mapa da aula
Aula 17 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["17.1 Integridade primeiro"]
N1["17.2 Repetição"]
N2["17.3 Lendo a execução"]
N3["17.4 Custos operacionais"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["17.1 Integridade primeiro"]
N1["17.2 Repetição"]
N2["17.3 Lendo a execução"]
N3["17.4 Custos operacionais"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[17.1 Integridade primeiro]
|
v
[17.2 Repetição]
|
v
[17.3 Lendo a execução]
|
v
[17.4 Custos operacionais]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) explicar códigos de autenticação de mensagem e por que, em TO, a integridade muitas vezes importa mais que o sigilo; (2) usar hmac e hashlib da biblioteca padrão; (3) impedir a repetição (replay) com contadores; e (4) listar os custos operacionais da criptografia em dispositivos com recursos limitados.
17.1 Integridade primeiro
A leitura de um medidor de calor não é segredo para o seu dono, mas uma leitura forjada muda uma conta, e um comando de controle forjado muda um processo. Um código de autenticação de mensagem (MAC) permite que um receptor que compartilha uma chave secreta verifique que a mensagem veio de quem tem a chave e não foi alterada. O HMAC com SHA-256 é uma construção muito usada, padronizada no FIPS 198-1. Na LDHP, o que está em jogo é uma conta e uma caldeira. Uma leitura de medidor forjada reduz a conta de uma residência; uma escrita forjada no registrador 100 do PLC-H muda o calor fornecido a todas as residências. O laboratório de HMAC usa leituras de medidores porque é ali que a questão da integridade fica mais clara.
17.2 Repetição
Uma mensagem válida capturada ontem continua criptograficamente válida hoje. Incluir um contador estritamente crescente (ou um carimbo de tempo verificado contra uma janela) dentro dos dados autenticados permite que o receptor rejeite repetições.
"""Lab 17: HMAC-protected meter readings with a replay counter (synthetic key)."""
import hmac, hashlib
KEY = b"synthetic-lab-key-not-for-use"
def tag(ctr, kwh): return hmac.new(KEY, f"{ctr}|{kwh}".encode(), hashlib.sha256).hexdigest()[:16]
last = 0
msgs = [(1, 120.5, tag(1, 120.5)), (2, 121.0, tag(2, 121.0)), (2, 121.0, tag(2, 121.0)), (3, 99.0, tag(3, 121.4))]
for ctr, kwh, t in msgs:
if not hmac.compare_digest(t, tag(ctr, kwh)): print(ctr, kwh, "REJECT bad tag")
elif ctr <= last: print(ctr, kwh, "REJECT replay")
else: last = ctr; print(ctr, kwh, "accept")
Execute com python3 lab_hmac.py. Saída verificada:
1 120.5 accept
2 121.0 accept
2 121.0 REJECT replay
3 99.0 REJECT bad tag
No laboratório de HMAC, uma leitura aceita uma vez com o contador 2 é rejeitada quando os mesmos bytes chegam de novo, embora a sua tag esteja correta; só o significado do contador é diferente. Para os medidores da LDHP, isso impede que um morador com equipamento de rádio repita a leitura mais baixa do mês anterior, que é o caso de abuso escrito no Capítulo 26.
17.3 Lendo a execução
A mensagem 2 é aceita uma vez e rejeitada na segunda vez como repetição, mesmo com a tag correta. A mensagem 3 traz uma tag calculada para 121,4 kWh, mas declara 99,0 kWh, então a verificação falha. Observe o hmac.compare_digest, que compara em tempo constante e evita vazar quantos caracteres iniciais coincidiram. Para a LDHP, a segunda rejeição é o cenário do morador: uma leitura mais baixa capturada e repetida para a conta do mês seguinte falha no contador, embora todos os bytes da tag sejam genuínos. A terceira rejeição é adulteração em trânsito: um gateway ou atacante que muda 121,4 kWh para 99,0 kWh sem a chave do medidor não consegue produzir uma tag correspondente.
17.4 Custos operacionais
As chaves precisam ser provisionadas por dispositivo, trocadas e revogadas; um medidor substituído após uma falha precisa de uma chave nova, e uma chave compartilhada por toda a frota significa que uma única chave extraída forja todos os medidores. Dispositivos limitados podem não ter hardware para armazenamento seguro de chaves. A provisão 5.4 da ETSI EN 303 645 pede que os parâmetros sensíveis de segurança sejam armazenados com segurança e que não se usem parâmetros críticos de segurança fixos no código do software do dispositivo. A estimativa de tamanho de Maya põe o custo de rádio em 1,5 MB por dia para 4.000 medidores; o processo de chaves é o custo maior.
Exemplo resolvido (LDHP sintética)
Maya calcula o acréscimo de tamanho: uma tag truncada de 16 caracteres hexadecimais (64 bits) mais um contador de 8 bytes acrescentam 16 bytes por leitura. A uma leitura por hora por medidor, em 4.000 medidores, isso dá 1,5 MB por dia — irrelevante para a rede, mas o processo de gestão de chaves é o custo real.
Caso sintético — Lakeside District Heating Plant. A chave do laboratório é uma string de exemplo; nunca embuta chaves no código.
Erros e limites
Truncar MACs reduz a resistência à falsificação; 64 bits é um mínimo comum nesse tipo de projeto. Um hash sozinho (sem chave) não oferece autenticação. Criptografia sem proteção de integridade pode ser maleável.
Exercícios
- EX049 — Detectando um contador reiniciado. Depois de uma atualização de firmware do medidor, o contador recomeça em 1. O que o receptor do laboratório faz, e como o projeto deveria tratar isso?
Mostrar critérios de avaliação
Rubrica: 3 = rejeita como repetição; trocar a chave ou persistir o contador com um campo de época da chave; 2 = só o comportamento; 1 = aceita; 0 = nada. - EX050 — Por que não SHA-256 puro? Explique por que anexar SHA-256(leitura) não impede a falsificação.
Mostrar critérios de avaliação
Rubrica: 3 = não há segredo: qualquer um pode recalcular o hash de um valor forjado; 2 = parcial; 1 = "o SHA-256 é fraco"; 0 = nada. - EX051 — Risco de uma chave para toda a frota. Descreva a consequência de os 4.000 medidores compartilharem uma única chave HMAC.
Mostrar critérios de avaliação
Rubrica: 3 = extraí-la de um medidor permite forjar leituras de qualquer medidor; chaves por dispositivo limitam o raio de impacto; 2 = parcial; 1 = vago; 0 = nada.
Síntese
Para dados de TO, integridade autenticada com proteção contra repetição é o principal objetivo criptográfico, e é a gestão de chaves — não o algoritmo — que decide se ela funciona.