Anti-rollback persistente em firmware industrial: por que importa

Imagine este cenário, comum o suficiente para ter virado padrão de relatório de incidente: um equipamento industrial está rodando firmware v1.07, com três CVEs públicos corrigidos em relação à v1.04. O atacante consegue acesso à rede de manutenção — VPN com credencial vazada, técnico distraído, USB esquecido — e dispara uma atualização. O firmware que ele envia é a v1.04 original do próprio fabricante, assinada digitalmente com a chave válida da época. O bootloader verifica a assinatura, confirma que o binário é autêntico, e instala. O equipamento volta a operar com as três CVEs reabertas. Nenhuma assinatura foi falsificada. Esse é o ataque de downgrade, e ele só é bloqueado por uma defesa: contador anti-rollback persistente.

O que é um ataque de downgrade

Um ataque de downgrade força o sistema a aceitar uma versão mais antiga — e legítima — de software, porque essa versão carrega vulnerabilidade conhecida que o atacante pretende explorar. Diferente de uma "atualização", em que o sistema migra para versão mais nova, o downgrade caminha no sentido inverso para reabrir buracos que a engenharia já havia fechado.

O caso histórico mais didático é LogJam (CVE-2015-4000), de 2015, em que o atacante de rede forçava cliente e servidor TLS a negociarem cifras DHE_EXPORT — grupos Diffie-Hellman de 512 bits, herdados da política de exportação dos anos 1990. Foi necessário patch coordenado entre navegadores e servidores para remover as cifras vulneráveis.

No firmware industrial o padrão se repete. Vários CVEs em equipamentos OT — citamos a família CVE-2018-10628 em SCADA, em que versões antigas aceitavam comandos sem autenticação — permanecem exploráveis enquanto existir caminho para reinstalar a versão vulnerável. Do bootloader, a diferença entre atualização e downgrade é uma comparação numérica: a versão recebida é maior ou menor que o mínimo aceito?

Por que assinatura digital sozinha não basta

Esse é o ponto que confunde quem aprendeu cibersegurança industrial pelos slides do fornecedor. Assinatura digital (Ed25519, RSA, ECDSA) prova autoria e integridade: garante que o binário foi produzido por quem detém a chave privada, e que nenhum bit foi alterado depois. Não prova que é a versão mais recente.

Um binário antigo, assinado em 2022 pela mesma chave que assinou o binário novo de 2026, continua tendo assinatura válida — a matemática não enxerga tempo. Se o esquema usa rotação de chaves, o bootloader armazena slots antigos para manter a frota bootável; logo, mesmo binários muito antigos passam pela verificação.

A defesa que falta é o contador anti-rollback persistente. O equipamento mantém, em armazenamento que sobrevive a reset e corte de energia, um número que representa a menor versão que aceita instalar. Toda atualização declara, em campo do header, sua "anti-rollback version": se a versão recebida é maior ou igual ao contador, a atualização é considerada; se for menor, é rejeitada. O contador é monotonicamente crescente — uma vez avançado, jamais retrocede em operação normal.

Mecanismos clássicos

A prática embarcada oferece quatro famílias para o contador persistente.

Página dedicada em flash. Setor reservado para o contador. Simples e barato, mas flash tem endurance limitada (10.000 a 100.000 ciclos por página); se escreve a cada boot, a página queima em meses. Exige wear-leveling.

Fuses OTP. Em vez de incrementar, queima um fuse por versão liberada. Irreversível. Desvantagem: número finito (32, 64 ou 128); esgotamento é definitivo. Usado em silício de alto valor (Apple Secure Enclave, consoles).

Counter em RTC com bateria. Contador em registrador do RTC alimentado por bateria de moeda. Sobrevive a reset e corte da alimentação primária. Depende da bateria viva.

TAMP backup registers. Versão moderna do anterior em STM32 e equivalentes. Registradores com proteção contra adulteração, zeráveis se pino de tamper for acionado. É o que o AEM-60DC8 utiliza.

Sistemas robustos colocam o contador no dispositivo, em hardware que o firmware aplicativo não rebaixa — counter em RAM persistido por software é frágil, counter em servidor central depende de canal.

Contadores TAMP com backup por bateria

Microcontroladores STM32 das famílias G0/G4/L4/H7 oferecem o periférico TAMP (Tamper and backup registers), com registradores de 32 bits no domínio de backup do RTC. O domínio é alimentado pelo pino VBAT — tipicamente CR2032 ou supercapacitor — e mantém conteúdo durante reset, sleep profundo e ausência total da alimentação principal.

Em uso prático, um registrador TAMP de 32 bits acomoda um contador uint32_t. Saturação em 4.294.967.295 — inalcançável: a uma atualização por mês durante 100 anos, são 1.200 incrementos. Com uint16_t, o teto cai para 65.535, ainda folgado. A regra é usar tipo mais largo do que se imagina precisar.

O AEM-60DC8 mantém o número exato de bits, layout de registradores e regra de transição como objeto de validação técnica sob NDA, alinhado à postura de não publicar detalhes que reduzam a defesa em profundidade. Em homologação ou auditoria conduzida pelo cliente, esses detalhes estão em evidência técnica sob acordo de confidencialidade.

A bateria CR2032 é substituível em campo. Substituição precisa ser autenticada e registrada para não virar caminho de downgrade — edge case na seção dedicada.

Política de versionamento

A regra anti-rollback só funciona com política clara sobre o que é a "versão" e quando o mínimo aceitável sobe.

O AEM-60DC8 adota major.minor.patch (SemVer industrial). A versão visível ao operador (v1.03 atual) é a representação textual; internamente, o header de update carrega inteiro de 32 bits empacotando os três campos, mais um anti_rollback_version dedicado, independente da SemVer.

Por que separar? Porque nem toda release deve subir o piso. Um patch v1.03.1 que corrige bug cosmético no LCD não precisa fechar v1.03.0. Mas se v1.04 corrige CVE séria, a política diz: ao liberar v1.04, o anti_rollback_version sobe, e o bootloader, ao bootar v1.04 com sucesso, avança o contador TAMP. A partir desse ponto, v1.03 está banida — até reset autorizado por service mode.

Quem decide? Em processo alinhado a IEC 62443-4-1, um release committee com representação de engenharia, segurança e produto. Critério: subir o piso sempre que a release nova fecha vulnerabilidade que a anterior abre. Não subir é decisão consciente, justificada por escrito.

Como o AEM-60DC8 implementa

A v1.03 do firmware do AEM-60DC8 — Plataforma Industrial de Supervisão DC da LRI — implementa anti-rollback persistente em registradores TAMP do MCU STM32G0B0RE, no domínio de backup alimentado por bateria CR2032. O whitepaper WP01 — Modbus RTU sob Secure by Design documenta a validação de boot em nove camadas, com o contador anti-rollback como filtro de versão antes da verificação Ed25519.

Pontos relevantes:

• Contador no domínio TAMP, sobrevive a reset e corte da alimentação enquanto a CR2032 estiver viva.
• Avanço pós-boot bem-sucedido — evita lock-out se uma atualização aborta.
• Anti-rollback version independente da SemVer, controlada por release committee interno.
• Política de não-retrocesso documentada e disponível sob NDA.
• IEC 62443-4-2 SL2 como meta de certificação em progresso — o projeto não declara certificação concluída; a LRI publicará o status quando emitido pelo organismo certificador.

Anti-rollback em ambiente regulado

Em setores regulatórios, o contador deixa de ser detalhe e vira artefato auditável.

IEC 62443-3-3 SR 3.4 — Software and information integrity estabelece, como requisito de sistema, que o sistema de controle deve detectar, registrar, relatar e proteger contra acessos não autorizados e alterações em software e informação durante operação, comissionamento, manutenção e reparo. O contador anti-rollback responde a esse SR.

No mercado norte-americano, NERC CIP-010-4 obriga concessionárias bulk a manter baseline de configuração — incluindo versão de firmware — e justificar mudanças. Equipamento que aceita downgrade silencioso é incompatível: a baseline perde valor se pode ser revertida sem rastro.

Evidência típica solicitada por auditor: documento de processo descrevendo como o contador é incrementado; relatório de teste mostrando rejeição de imagem com anti_rollback_version menor; documentação do service mode e autorização; registro de release committee aprovando o piso de cada release. A LRI fornece essa evidência sob NDA durante homologação.

Edge cases que importam

Substituição de hardware em campo. Equipamento sai de operação por queima; sobressalente é instalado. O sobressalente sai da fábrica com contador inicial baixo. Se a planta opera v1.07, o runbook de site manda instalar v1.07 antes da produção — contador avança no novo equipamento. Cuidado: não retornar o equipamento queimado ao estoque sem reset autorizado.

Restore de configuração. Configuração (parâmetros Modbus, calibração, baudrate) é dado, não firmware. Restore não toca no contador. A separação entre "binário" e "configuração" é deliberada: operador pode restaurar backup de seis meses atrás sem reabrir CVE.

Upgrade legítimo via service mode autenticado. Cenários raros exigem rebaixar o contador — diagnóstico, retorno à fábrica para análise forense, transferência de equipamento. A resposta é service mode com autenticação forte (token físico, credencial de fábrica, presença física) e log persistente. Service mode não é "bypass" — é caminho documentado, raro, rastreado. No AEM-60DC8 está documentado sob NDA e não é exposto pelo barramento Modbus RTU operacional.

FAQ

1. Se o atacante remover a bateria CR2032, ele zera o contador anti-rollback? Remoção com o equipamento desenergizado limpa o domínio de backup. Por isso o projeto trata substituição como evento de manutenção controlada, com procedimento documentado e — em ambientes regulados — log físico. O tamper detection do TAMP pode ser configurado para registrar a perda de alimentação de backup, gerando evidência forense.

2. Anti-rollback é mesmo necessário se já temos assinatura Ed25519 e prefixo de domínio? Sim. Assinatura prova autoria e integridade; prefixo de domínio prova que o binário é daquele produto; nada disso prova que é a versão certa do momento. Sem o contador, um binário antigo legitimamente assinado entra sem alarme.

3. O contador anti-rollback satura em uso real? Com 32 bits, não. A uma atualização por mês durante um século, são 1.200 incrementos — abaixo do teto de 4.294.967.295.

4. Quem decide subir o piso anti-rollback de uma release para outra? Em processo alinhado a IEC 62443-4-1, um release committee interno com engenharia, segurança e produto. Critério: subir quando a release nova fecha vulnerabilidade que a anterior abre.

5. O AEM-60DC8 já é certificado em IEC 62443-4-2 SL2? O projeto tem IEC 62443-4-2 SL2 como objetivo de certificação. O processo está em progresso. A LRI Engenharia publicará o status formal quando emitido pelo organismo certificador. Este post não declara certificação concluída.

---