Firmware firmado con Ed25519: por qué importa en planta industrial

Cuando Stuxnet salió a la luz en 2010, la industria descubrió que un firmware comprometido en un único PLC podía destruir físicamente centrífugas dentro de una instalación nuclear. Seis años después, Industroyer cortó el suministro eléctrico en Kiev durante aproximadamente una hora manipulando protocolos industriales desde payloads cargados en equipos de subestación. En 2022, Industroyer2 fue descubierto antes de causar un daño similar. El patrón común resulta incómodo: el atacante no necesita estar en el piso, solo necesita conseguir que un firmware adulterado se cargue en un equipo de confianza.

Firmware firmado digitalmente corta una parte significativa de esa superficie de ataque. Este post explica qué es una firma digital, por qué Ed25519 es el estándar práctico para microcontroladores industriales en 2026, qué ataques previene y qué preguntar al proveedor del próximo PLC, HMI o medidor antes de firmar la orden de compra.

Qué es una firma digital

La analogía más útil es el sello del notario. Cuando un documento sale de la notaría con sello y firma reconocida, quien lo recibe puede verificar sin llamar al notario que el documento fue efectivamente sellado por esa notaría, y que nadie alteró nada después. El sello prueba autoría, y la integridad del papel prueba que el contenido está intacto.

Una firma digital hace lo mismo con matemáticas en lugar de tinta. Quien firma posee un par de claves: una clave privada que nunca abandona su poder, y una clave pública que puede distribuirse libremente. La clave privada genera, sobre un bloque de bytes (en nuestro caso, la imagen de firmware), una secuencia corta — la firma — que solo puede haber sido producida por quien posee esa clave privada. La clave pública permite que cualquier tercero verifique la firma sin haber visto nunca la clave privada.

El equipo en campo, al aceptar una actualización, calcula un hash criptográfico sobre los bytes recibidos, usa la clave pública grabada en el bootloader para verificar la firma contra ese hash, y solo prosigue si coinciden. Cualquier alteración de un solo bit en el payload, o cualquier intento de forjar la firma sin la clave privada, hace que la verificación falle.

Ese modelo es lo opuesto a la práctica todavía común en equipos heredados, donde la "verificación" es apenas un CRC-32 — diseñado para detectar errores aleatorios de transmisión, no para resistir a un adversario. El CRC se satisface fácilmente con bytes adversarios elegidos, y por eso no sustituye a la firma.

Por qué Ed25519, y no RSA

RSA dominó la firma digital durante tres décadas, pero en microcontroladores modestos paga un costo alto. Una verificación RSA-2048 en Cortex-M0+ a 64 MHz, sin aceleración de hardware, toma típicamente 30 a 60 milisegundos y exige biblioteca grande y aritmética modular cuidadosa para no filtrar la clave en ataques de canal lateral. La clave pública mide 256 bytes; la firma, otros 256.

Ed25519, publicado en 2011 por Daniel J. Bernstein y colegas y estandarizado en RFC 8032 en 2017, es un esquema basado en curva elíptica de Edwards — una familia matemática distinta de las curvas NIST tradicionales — elegida para evitar varias trampas prácticas de implementación. En un Cortex-M0+, la verificación Ed25519 en bibliotecas modernas (BearSSL, libsodium, monocypher) se ejecuta en torno a 1,5 ms. La clave pública ocupa 32 bytes; la firma, 64. En un bootloader que debe caber en 16 o 32 KB de flash, 1,5 ms frente a 30 ms es la diferencia entre arranque instantáneo y arranque lento.

Los atributos de seguridad también pesan. Ed25519 ofrece un nivel equivalente a RSA-3072 — no a RSA-2048 — según las recomendaciones del NIST y de la ANSSI. El esquema es determinístico por construcción: la firma es función solo de la clave privada y del mensaje, sin dependencia de un generador de números aleatorios al firmar. Esa propiedad elimina la clase de ataques que destruyó la clave de la PlayStation 3 en 2010, cuando Sony reutilizó el mismo número aleatorio en dos firmas ECDSA. Ed25519 también resiste por diseño varios ataques de canal lateral gracias a la aritmética en tiempo constante de sus implementaciones de referencia.

Para firmware embebido en 2026, Ed25519 es más rápido, más compacto, con seguridad equivalente o superior, y con menor superficie de error de implementación.

Qué previene esta defensa

Cuatro familias de ataque dejan de funcionar con firmware firmado correctamente.

Sustitución maliciosa. Un atacante intercepta el canal de actualización e inyecta firmware modificado con backdoor o exfiltración. Sin firma, el equipo acepta lo que reciba si el CRC coincide; con firma, la imagen falsa es rechazada antes de grabarse en flash.

Downgrade attack. El atacante captura una versión antigua legítimamente firmada con CVE público y fuerza la instalación en un equipo ya parcheado. La firma es válida; la defensa exige contador anti-rollback persistente, descrito más adelante en la capa que implementa el AEM-60DC8.

Replay attack. El atacante captura una actualización legítima e intenta entregarla a otro producto, esperando que el bootloader la acepte por reconocer la firma. La defensa es el prefijo de dominio (domain separation): el mensaje que Ed25519 firma no es la imagen desnuda, es la imagen prefijada por un identificador único de producto y familia — por ejemplo LRI:AEM-60DC8:fw:v1 antes del hash. Una firma válida para ese dominio no verifica en un equipo que espera LRI:AEM-90AC:fw:v1.

Compromiso del pipeline de build. El ataque a SolarWinds (2020) demostró que adversarios sofisticados atacan la fábrica que produce el producto: comprometen el servidor de build e insertan código malicioso antes del paso de firma, así el binario resultante queda firmado por la clave legítima. La defensa exige que la clave privada nunca toque el servidor automatizado — reside en hardware (YubiKey FIPS, HSM, smart card) y cada firma exige presencia física (PIN, toque) de un ingeniero responsable. Esa es la ceremonia de firma, descrita más adelante.

Cómo se construye una cadena de confianza

La chain of trust es la jerarquía de claves que permite operar una flota durante años sin exponer la clave más valiosa.

En la cima hay una clave maestra raíz, idealmente offline, en HSM o YubiKey FIPS en caja fuerte. Se usa raramente — solo para autorizar nuevas claves de firma de release.

Un nivel debajo están las claves de firma de release, con rotación periódica. Cada clave tiene identificador y slot preasignado en el bootloader. Al rotar, la siguiente release pasa a usar la clave nueva; releases antiguas siguen siendo verificables por las claves guardadas en los demás slots.

El bootloader contiene en flash inmutable una lista de claves públicas autorizadas — típicamente cuatro slots independientes. Los beneficios:

• Rotación no disruptiva. ¿Se comprometió una clave? La siguiente release va por el siguiente slot. La flota antigua sigue arrancando porque su firmware fue firmado por una clave aún activa en otro slot.
• Multi-vendor. Slots separados permiten que vendor e integrador firmen releases en dominios separados.
• Defensa en profundidad. El compromiso de una clave no derriba la flota: requiere además romper el anti-rollback, el prefijo de dominio y el resto de la pila de validación.

El prefijo de dominio garantiza separación criptográfica entre productos, versiones y contextos. Es barato de implementar y elimina clases enteras de ataques cross-versión.

Ceremonia de firma

En una fábrica responsable, el flujo típico para liberar una versión tiene entre cuatro y seis pasos. Un ejemplo simplificado:

1. Build reproducible. El servidor de build (CI) compila a partir de un commit Git firmado con GPG, produciendo un binario cuyo hash queda documentado.
2. Revisión por pares. Otro ingeniero verifica los cambios y el hash generado. En equipos bajo IEC 62443-4-1, ese paso es evidencia auditable del proceso de desarrollo seguro.
3. Transferencia al operador de la clave. El binario se transfiere por canal autenticado al notebook del ingeniero responsable de la firma — no a un robot.
4. Firma con hardware. El ingeniero conecta el YubiKey, ejecuta la herramienta de firma, introduce el PIN y toca el sensor. La clave privada nunca aparece en memoria del computador.
5. Empaquetado y sello. El binario, la firma, el nivel anti-rollback y el dominio se empaquetan en el envelope de release; el artefacto se archiva y su hash queda registrado en log de release.
6. Despliegue controlado. La release se pone a disposición de un piloto interno antes del rollout amplio. El canal de distribución puede ser inseguro — el bootloader va a verificar.

Ese flujo es la separación concreta entre quien escribe código y quien autoriza ejecutarlo en campo. En entornos regulados, es rastro de auditoría.

Cómo lo implementa el AEM-60DC8

La v1.03 del firmware del AEM-60DC8 — plataforma industrial de supervisión DC de LRI — adopta Ed25519 (RFC 8032) como capa criptográfica del canal de actualización. Las elecciones relevantes para quien audita u homologa:

• Clave maestra fuera del computador de build. La clave privada de release reside en YubiKey FIPS; cada firma exige PIN y toque físico.
• Cuatro slots de clave pública en el bootloader. Rotación sin brickear la flota; claves antiguas removidas en releases futuras según política.
• Prefijo de dominio propio al inicio del mensaje firmado.
• Validación de boot en nueve capas. Antes de transferir control al firmware de aplicación, el bootloader ejecuta palabra mágica, versión de header, CRC-32 del header, hardware ID, tamaño declarado, CRC-32 del payload, plausibilidad de la tabla de vectores, sello final y, finalmente, verificación Ed25519. Una falla en cualquiera devuelve el equipo al modo de actualización, jamás al modo operacional comprometido.
• Anti-rollback persistente en registros TAMP del MCU (STM32 backup domain) con batería de litio CR2032 sustituible en campo.
• Anti-brick por construcción. El bootloader reside en una región de flash que el canal Modbus jamás escribe. Una actualización interrumpida deja al equipo esperando un nuevo intento por el mismo bus Modbus RTU.

El proyecto adopta IEC 62443-4-2 SL2 como referencia de ciberseguridad, en progreso. La certificación formal está en curso; este post no declara certificación concluida y LRI Ingeniería publicará el estado cuando sea emitido por el organismo certificador.

Checklist para preguntar al proveedor de PLC/HMI

Antes de firmar la orden del próximo PLC o gateway, lleve estas ocho preguntas:

1. ¿El firmware está firmado digitalmente? ¿Qué algoritmo y tamaño de clave? Aceptable: Ed25519, RSA-3072+, ECDSA-P256+. Inaceptable: "CRC" o "checksum".
2. ¿La clave privada de firma reside en hardware (HSM/YubiKey) o en servidor de build? Hardware es el estándar correcto.
3. ¿Existe contador anti-rollback persistente, y cómo sobrevive a un corte de energía? Batería, NVRAM dedicada o flash protegido son aceptables; "depende del RTC" no lo es.
4. ¿Cuántos slots de clave pública soporta el bootloader? ¿Cuál es la política de rotación? Un único slot fijo es una fragilidad conocida.
5. ¿El mensaje firmado incluye prefijo de dominio (producto/familia/versión mayor)? Defensa contra replay cross-producto.
6. ¿El equipo expone, en pantallas o registros Modbus, el hash o versión de la imagen en ejecución? La auditoría operacional depende de eso.
7. En caso de falla de validación durante la actualización, ¿el equipo queda accesible para un nuevo intento, o se brickea? Anti-brick es diferencial en sitios remotos.
8. ¿Existe documentación de proceso de desarrollo seguro alineada con IEC 62443-4-1? Una respuesta sólida nombra procedimientos internos, no eslóganes.

Proveedores serios responden estas preguntas por correo; quien evade o redirige a "hable con nuestro socio" señala que la madurez aún no llegó al firmware.

Próximos pasos

La profundidad técnica completa del modelo de cinco capas está documentada en el whitepaper WP01 — Modbus RTU bajo Secure by Design, disponible en /es/whitepapers/. La especificación formal de Ed25519 está en RFC 8032, lectura recomendada para quien firma y para quien audita.

Para discusión de roadmap, integración u homologación, LRI Ingeniería puede ser contactada por los canales del sitio del producto.

FAQ

1. ¿Puedo usar Ed25519 en microcontroladores sin aceleración criptográfica en hardware? Sí. Implementaciones en C portable (BearSSL, monocypher, libsodium) ejecutan verificación Ed25519 en torno a 1,5 ms en Cortex-M0+ a 64 MHz, sin coprocesador. Costo típico de flash entre 4 y 8 KB.

2. ¿Qué ocurre si la única clave de firma se compromete en un producto sin múltiples slots? Toda la flota queda vulnerable a inyección de firmware adversario hasta que una actualización de bootloader sea entregada por otro canal — frecuentemente exigiendo recall físico. Múltiples slots convierten ese incidente en rotación de rutina.

3. ¿Por qué CRC-32 no sustituye a la firma digital? CRC fue diseñado para detectar errores aleatorios de transmisión. Un adversario puede construir bytes que satisfagan un CRC objetivo en fracciones de segundo. CRC sigue siendo útil para integridad de canal, pero no autentica origen.

4. ¿Es realmente necesario el anti-rollback si el firmware está firmado? Sí. Sin contador anti-rollback, un atacante puede forzar la instalación de una versión antigua legítimamente firmada que contenga una vulnerabilidad pública conocida — y la verificación de firma la acepta porque la versión antigua fue firmada por una clave válida en su momento.

5. ¿El AEM-60DC8 ya está certificado en IEC 62443-4-2 SL2? El proyecto tiene IEC 62443-4-2 SL2 como objetivo de certificación. El proceso está en progreso. LRI Ingeniería publicará el estado cuando sea emitido por el organismo certificador. Este post no declara certificación concluida.

---