Firmware assinado Ed25519: por que importa em chão de fábrica

Quando o Stuxnet apareceu em 2010, a indústria descobriu que firmware comprometido em um único CLP podia destruir centrífugas físicas em uma instalação nuclear. Seis anos depois, o Industroyer interrompeu por uma hora o fornecimento elétrico em Kiev, manipulando protocolos industriais a partir de payloads carregados em equipamentos de subestação. Em 2022, o Industroyer2 foi descoberto antes de causar dano semelhante. O padrão comum desses incidentes é desconfortável: o atacante não precisa estar no chão, precisa apenas conseguir que um firmware adulterado seja carregado em um equipamento confiável.

Firmware assinado digitalmente corta uma parte significativa dessa superfície de ataque. Este post explica o que é uma assinatura digital, por que Ed25519 é o padrão prático para microcontroladores industriais em 2026, quais ataques ele previne, e o que perguntar para o fornecedor do seu próximo PLC, HMI ou medidor antes de assinar o pedido de compra.

O que é uma assinatura digital

A analogia mais útil é o carimbo do tabelião. Quando um documento sai do cartório com selo e firma reconhecida, quem recebe pode verificar sem ligar para o tabelião que o documento foi de fato carimbado por aquele cartório, e que ninguém alterou nada depois. O carimbo prova autoria, e a integridade do papel prova que o conteúdo está intacto.

Uma assinatura digital faz o mesmo com matemática no lugar de tinta. Quem assina possui um par de chaves: uma chave privada que nunca sai do seu poder, e uma chave pública que pode ser distribuída livremente. A chave privada gera, sobre um bloco de bytes (no nosso caso, a imagem de firmware), uma sequência curta — a assinatura — que só pode ter sido produzida por quem possui aquela chave privada. A chave pública permite que qualquer terceiro verifique a assinatura sem nunca ter visto a chave privada.

O equipamento em campo, ao aceitar uma atualização, calcula um hash criptográfico sobre os bytes recebidos, usa a chave pública gravada no bootloader para verificar a assinatura contra esse hash, e só prossegue se a comparação bater. Qualquer alteração de um único bit no payload, ou qualquer tentativa de forjar a assinatura sem a chave privada, faz a verificação falhar.

Esse modelo é o oposto da prática ainda comum em equipamentos legados, em que a "verificação" é apenas um CRC-32 — projetado para detectar erros aleatórios de transmissão, não para resistir a um adversário. CRC bate facilmente com bytes adversariais escolhidos, e por isso não substitui assinatura.

Por que Ed25519, e não RSA

RSA dominou assinatura digital durante três décadas, mas em microcontroladores modestos paga um custo alto. Uma verificação RSA-2048 em Cortex-M0+ a 64 MHz, sem aceleração de hardware, leva tipicamente 30 a 60 milissegundos e exige biblioteca grande e uma aritmética modular cuidadosa para não vazar a chave em ataques de canal lateral. A chave pública tem 256 bytes; a assinatura, outros 256.

Ed25519 foi publicado em 2011 por Daniel J. Bernstein e colaboradores, e padronizado em RFC 8032 em 2017. É um esquema baseado em curva elíptica de Edwards — uma forma matemática diferente das curvas NIST tradicionais — escolhida especificamente para evitar várias armadilhas práticas de implementação. Em um Cortex-M0+, a verificação Ed25519 em bibliotecas modernas (BearSSL, libsodium, monocypher) executa em torno de 1,5 milissegundo. A chave pública ocupa 32 bytes; a assinatura, 64 bytes. Em um bootloader que precisa caber em 16 ou 32 KB de flash, 1,5 ms vs 30 ms é a diferença entre boot perceptivelmente instantâneo e boot lento.

Os atributos de segurança também pesam. Ed25519 oferece nível equivalente a RSA-3072 — não RSA-2048 — segundo as recomendações atuais do NIST e do ANSSI francês. O esquema é determinístico por construção: a assinatura é função apenas da chave privada e da mensagem, não depende de gerador de números aleatórios no momento de assinar. Essa propriedade elimina a classe inteira de ataques que destruiu a chave do PlayStation 3 em 2010, quando a Sony reutilizou o mesmo número aleatório em duas assinaturas ECDSA. Ed25519 também resiste por design a vários ataques de canal lateral graças à aritmética constante-tempo nas implementações de referência.

Para firmware embarcado em 2026, Ed25519 é mais rápido, mais compacto, com segurança equivalente ou superior, e com menor superfície de erro de implementação.

O que esta defesa previne

Quatro famílias de ataque deixam de funcionar quando firmware é assinado corretamente.

Substituição maliciosa. Um atacante intercepta o canal de atualização e injeta um firmware modificado, com backdoor ou exfiltração. Sem assinatura, o equipamento aceita o que receber desde que o CRC bata; com assinatura, a imagem falsa é rejeitada antes de ser gravada.

Downgrade attack. O atacante captura uma versão antiga legitimamente assinada com vulnerabilidade conhecida (CVE público) e força a instalação em equipamento já patcheado. A assinatura é válida; a defesa exige contador anti-rollback persistente, descrito adiante na camada que o AEM-60DC8 implementa.

Replay attack. O atacante captura uma atualização legítima de um produto e tenta entregá-la para outro produto ou outra família, esperando que o bootloader aceite por reconhecer a assinatura. A defesa é o prefixo de domínio (domain separation): a mensagem que o esquema Ed25519 assina não é a imagem nua, é a imagem prefixada por um identificador único do produto e da família — por exemplo LRI:AEM-60DC8:fw:v1 antes do hash. Uma assinatura válida para esse domínio não verifica em um equipamento que espera LRI:AEM-90AC:fw:v1.

Comprometimento do build pipeline. O ataque à SolarWinds em 2020 demonstrou que adversários sofisticados atacam a fábrica que produz o produto: comprometem o servidor de build e inserem código malicioso antes da etapa de assinatura, de modo que o binário resultante é assinado pela chave legítima. A defesa exige que a chave privada nunca toque o servidor de build automatizado — ela reside em hardware (YubiKey FIPS, HSM, smart card), e cada assinatura exige presença física (PIN, toque) de um engenheiro responsável. Essa é a cerimônia de assinatura, descrita mais adiante.

Como uma cadeia de confiança é construída

O termo chain of trust descreve a hierarquia de chaves que permite operar uma frota durante anos sem expor a chave mais valiosa.

No topo há uma chave-mestra de root, idealmente offline, guardada em HSM ou YubiKey FIPS em cofre. É usada raramente — apenas para autorizar novas chaves de assinatura de release.

Um nível abaixo estão chaves de assinatura de release, com rotação periódica (anual, por exemplo). Cada chave tem um identificador e um slot pré-reservado no bootloader. Quando rotacionada, a próxima release passa a usar a chave nova; releases antigas continuam verificáveis pelas chaves anteriores armazenadas nos demais slots.

O bootloader contém em flash imutável uma lista de chaves públicas autorizadas — tipicamente quatro slots independentes. Os benefícios:

• Rotação não-disruptiva. Comprometeu-se uma chave? Próxima release vai pelo slot seguinte. Frota antiga continua bootando porque seu firmware foi assinado por chave ainda ativa em outro slot.
• Multi-vendor. Slots separados permitem que vendor e integrador assinem releases distintas em domínios separados.
• Defesa em profundidade. Comprometimento de uma chave não derruba imediatamente a frota: requer ainda quebrar o anti-rollback, o prefixo de domínio e o restante da pilha de validação.

O prefixo de domínio garante separação criptográfica entre produtos, versões e contextos. É barato de implementar e elimina classes inteiras de ataque cross-versão.

Cerimônia de assinatura

Em uma fábrica responsável, o fluxo típico para liberar uma versão tem entre quatro e seis passos. Um exemplo simplificado:

1. Build reproduzível. O servidor de build (CI) compila a partir de um commit Git assinado por GPG, produzindo um binário cujo hash é documentado.
2. Revisão por par. Outro engenheiro confere as mudanças e o hash gerado. Em equipes sob IEC 62443-4-1, esse passo é evidência auditável do processo de desenvolvimento seguro.
3. Transferência ao operador da chave. O binário é transferido por canal autenticado para o notebook do engenheiro responsável pela assinatura — não para um robô.
4. Assinatura com hardware. O engenheiro pluga o YubiKey, executa a ferramenta de assinatura, insere PIN e toca o sensor. A chave privada nunca aparece em memória do computador.
5. Empacotamento e selo. O binário, a assinatura, o nível anti-rollback e o domínio são empacotados no envelope de release; o artefato é arquivado e seu hash registrado em log de release.
6. Deploy controlado. A release é disponibilizada para um piloto interno antes do rollout amplo. O canal de distribuição pode ser inseguro — o bootloader vai verificar.

Esse fluxo é a separação concreta entre quem escreve código e quem autoriza que ele rode em campo. Em ambientes regulados, é também rastro de auditoria.

Como o AEM-60DC8 implementa

A v1.03 do firmware do AEM-60DC8 — plataforma industrial de supervisão DC da LRI — adota Ed25519 (RFC 8032) como camada criptográfica do canal de atualização. As escolhas relevantes para quem audita ou homologa:

• Chave-mestra fora do computador de build. A chave privada de release reside em YubiKey FIPS; cada assinatura exige PIN e toque físico.
• Quatro slots de chave pública no bootloader. Rotação sem brick da frota; chaves antigas removidas em releases futuras conforme política.
• Prefixo de domínio próprio no início da mensagem assinada.
• Validação de boot em nove camadas. Antes de transferir controle ao firmware aplicativo, o bootloader executa palavra mágica, versão de header, CRC-32 do header, hardware ID, tamanho declarado, CRC-32 do payload, plausibilidade da tabela de vetores, selo de fim e, finalmente, verificação Ed25519. Falha em qualquer uma devolve o equipamento ao modo de atualização, jamais ao modo operacional comprometido.
• Anti-rollback persistente em registradores TAMP do MCU (STM32 backup domain) com bateria CR2032 substituível em campo.
• Anti-brick por construção. O bootloader reside em região de flash que o canal Modbus jamais escreve. Atualização interrompida deixa o equipamento aguardando nova tentativa pelo mesmo barramento Modbus RTU.

O projeto adota como referência de cibersegurança o IEC 62443-4-2 SL2, em progresso. A certificação formal está em andamento; este post não declara certificação concluída e a LRI Engenharia publicará o status quando emitido pelo organismo certificador.

Checklist para perguntar ao fornecedor de PLC/HMI

Antes de assinar o pedido do próximo CLP, supervisório ou gateway, leve essas oito perguntas:

1. O firmware é assinado digitalmente? Qual algoritmo e tamanho de chave? Resposta aceitável: Ed25519, RSA-3072+, ECDSA-P256+. Resposta inaceitável: "CRC" ou "checksum".
2. A chave privada de assinatura reside em hardware (HSM/YubiKey) ou em servidor de build? Hardware é o padrão correto.
3. Existe contador anti-rollback persistente, e como ele sobrevive a corte de energia? Bateria, NVRAM dedicada ou flash protegido são respostas aceitáveis; "depende da hora do RTC" não é.
4. Quantos slots de chave pública o bootloader suporta? Qual a política de rotação? Um único slot fixo é fragilidade conhecida.
5. A mensagem assinada inclui prefixo de domínio (produto/família/versão major)? Defesa contra replay cross-produto.
6. O equipamento exibe nas suas telas/registradores Modbus o hash ou versão da imagem em execução? Auditoria operacional depende disso.
7. Em caso de falha de validação durante atualização, o equipamento fica acessível para nova tentativa, ou bricka? Anti-brick é diferencial em sites remotos.
8. Existe documentação de processo de desenvolvimento seguro alinhada a IEC 62443-4-1? Resposta sólida traz nomes de procedimentos internos, não slogans.

Fornecedores sérios respondem essas perguntas em e-mail; quem rodeia ou redireciona para "fale com nosso parceiro" sinaliza que a maturidade ainda não chegou ao firmware.

Próximos passos

A profundidade técnica completa do modelo de cinco camadas, com tabelas e exemplos práticos, está documentada no whitepaper WP01 — Modbus RTU sob Secure by Design, disponível em /pt-br/whitepapers/. A especificação formal do Ed25519 está em RFC 8032, leitura recomendada para quem assina e para quem audita.

Para discussão de roadmap, integração e homologação, a LRI Engenharia pode ser contactada pelos canais publicados no site do produto.

FAQ

1. Posso usar Ed25519 em microcontroladores sem aceleração criptográfica em hardware? Sim. Implementações em C portável (BearSSL, monocypher, libsodium) executam verificação Ed25519 em torno de 1,5 ms em Cortex-M0+ a 64 MHz, sem coprocessador. O custo de flash típico está entre 4 e 8 KB.

2. O que acontece se a única chave de assinatura for comprometida em um produto que não tem múltiplos slots? Toda a frota fica vulnerável a injeção de firmware adversarial até que uma atualização de bootloader seja entregue por outro canal — frequentemente exigindo recall físico. Múltiplos slots no bootloader convertem esse incidente em rotação de rotina.

3. Por que CRC-32 não substitui assinatura digital? CRC foi projetado para detectar erros aleatórios de transmissão. Um adversário consegue construir bytes que satisfazem um CRC alvo em frações de segundo. CRC continua útil para integridade de canal, mas não autentica origem.

4. Anti-rollback é mesmo necessário se o firmware é assinado? Sim. Sem contador anti-rollback, um atacante pode forçar a instalação de uma versão antiga, legitimamente assinada, que contenha vulnerabilidade pública conhecida — e a verificação de assinatura aceita porque a versão antiga foi de fato assinada por chave válida na época.

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.

---