Anti-rollback persistente en firmware industrial: por qué importa

Imagine este escenario, ya común como plantilla de informe de incidente: un equipo industrial corre firmware v1.07, con tres CVE públicos corregidos desde v1.04. El atacante consigue acceso a la red de mantenimiento — credencial VPN filtrada, técnico distraído, USB olvidado — y dispara una actualización. El firmware que envía es la v1.04 original del fabricante, firmada digitalmente con la clave válida de la época. El bootloader verifica la firma, confirma que es auténtico, e instala. El equipo vuelve con los tres CVE reabiertos. Ninguna firma fue falsificada. Eso es un ataque de downgrade, bloqueado por una sola defensa: un contador anti-rollback persistente.

Qué es un ataque de downgrade

Un ataque de downgrade obliga al sistema a aceptar una versión más antigua — y legítima — de software, porque esa versión carga una vulnerabilidad conocida que el atacante pretende explotar. A diferencia de una "actualización", el downgrade va en sentido contrario, pensado por adversarios para reabrir agujeros que la ingeniería ya había cerrado.

El caso histórico más didáctico es LogJam (CVE-2015-4000), de 2015, donde el atacante de red forzaba a cliente y servidor TLS a negociar cifrados DHE_EXPORT — grupos Diffie-Hellman de 512 bits, herencia de la política estadounidense de exportación de los años 1990. Hizo falta un parche coordinado entre navegadores y servidores para retirar los cifrados vulnerables.

En firmware industrial el patrón se repite. Varios CVE documentados en equipos OT — la familia CVE-2018-10628 en SCADA, donde versiones antiguas aceptaban comandos sin autenticación — siguen explotables mientras exista camino para reinstalar la versión vulnerable. Desde el bootloader, la diferencia entre actualización y downgrade es numérica: ¿la versión recibida es mayor o menor que el mínimo aceptado?

Por qué la firma digital sola no basta

Este es el punto que confunde a quien aprendió ciberseguridad industrial por las diapositivas del proveedor. La firma digital (Ed25519, RSA, ECDSA) prueba autoría e integridad: garantiza que el binario fue producido por quien tiene la clave privada, y que ningún bit fue alterado. No prueba que sea la versión más reciente.

Un binario antiguo firmado en 2022 por la misma clave que firmó el binario nuevo de 2026 sigue teniendo firma válida — la matemática no ve el tiempo. Si el esquema usa rotación de claves, el bootloader almacena slots antiguos para mantener la flota arrancable; incluso binarios antiguos pasan la verificación.

La defensa que falta es el contador anti-rollback persistente. El equipo mantiene un número que representa la menor versión que acepta instalar, en almacenamiento que sobrevive a reset y corte de energía. Toda actualización declara su "anti-rollback version" en un campo del header: si es mayor o igual al contador, se considera; si es menor, se rechaza. El contador es monotónicamente creciente — una vez que avanza, jamás retrocede en operación normal.

Mecanismos clásicos

La práctica embebida ofrece cuatro familias para el contador persistente.

Página dedicada en flash. Sector reservado para el contador. Simple y barato, pero la flash tiene endurance limitada (10.000 a 100.000 ciclos por página); si escribe en cada boot, la página se quema en meses. Exige wear-leveling.

Fuses OTP. En lugar de incrementar, quema un fuse por versión liberada. Irreversible. Desventaja: número finito (32, 64 o 128); agotamiento definitivo. Usado en silicio de alto valor (Apple Secure Enclave, consolas).

Contador en RTC con batería. Contador en registro del RTC alimentado por pila de moneda. Sobrevive al reset y corte de la alimentación primaria. Depende de que la pila esté viva.

Registros TAMP de backup. Versión moderna del anterior en STM32 y equivalentes. Registros con protección anti-manipulación, ponibles a cero si un pin de tamper se activa. Es el que usa el AEM-60DC8.

Los sistemas robustos colocan el contador en el dispositivo, en hardware que el firmware aplicativo no puede rebajar — contador en RAM persistido por software es frágil, contador en servidor central depende de canal.

Contadores TAMP con respaldo por batería

Los microcontroladores STM32 de las familias G0/G4/L4/H7 ofrecen el periférico TAMP (Tamper and backup registers), con registros de 32 bits en el dominio de backup del RTC. El dominio se alimenta por el pin VBAT — típicamente CR2032 o supercondensador — y conserva contenido durante reset, sleep profundo y ausencia total de alimentación principal.

En uso práctico, un registro TAMP de 32 bits acomoda un contador uint32_t. Saturación en 4.294.967.295 — inalcanzable: a una actualización por mes durante 100 años, son 1.200 incrementos. Con uint16_t, el techo baja a 65.535, todavía holgado.

El AEM-60DC8 mantiene el número exacto de bits, el layout de registros y la regla de transición como objeto de validación técnica bajo NDA, alineado con la postura de no publicar detalles que reduzcan la defensa en profundidad. En homologación conducida por el cliente, esos detalles están en evidencia técnica bajo confidencialidad.

La pila CR2032 es reemplazable en campo. El reemplazo debe ser autenticado y registrado para no volverse camino de downgrade — edge case más abajo.

Política de versionado

La regla anti-rollback solo funciona con política clara sobre qué es la "versión" y cuándo sube el mínimo aceptable.

El AEM-60DC8 usa major.minor.patch (SemVer industrial). La versión visible al operador (v1.03 actual) es la representación textual; internamente, el header de update lleva entero de 32 bits empaquetando los tres campos, más un anti_rollback_version dedicado, independiente de SemVer.

¿Por qué separarlos? Porque no toda release debe elevar el piso. Un patch v1.03.1 que corrige bug cosmético en el LCD no necesita cerrar v1.03.0. Pero si v1.04 corrige CVE seria, al liberar v1.04 el anti_rollback_version sube, y el bootloader, al arrancar v1.04 con éxito, avanza el contador TAMP. A partir de ese punto, v1.03 queda prohibida — hasta reset autorizado por service mode.

¿Quién decide? En proceso alineado con IEC 62443-4-1, un release committee con ingeniería, seguridad y producto. Criterio: subir el piso siempre que la release nueva cierre vulnerabilidad que la anterior expone. No subir es decisión consciente, justificada por escrito.

Cómo lo implementa el AEM-60DC8

El firmware v1.03 del AEM-60DC8 — Plataforma Industrial de Supervisión DC de LRI — implementa anti-rollback persistente en registros TAMP del MCU STM32G0B0RE, en el dominio de backup alimentado por pila CR2032. El whitepaper WP01 — Modbus RTU bajo Secure by Design documenta la validación de boot en nueve etapas, con el contador anti-rollback como filtro de versión antes de la verificación Ed25519.

Puntos relevantes:

• Contador en el dominio TAMP, sobrevive al reset y corte de la alimentación principal mientras la CR2032 esté viva.
• Avance tras boot exitoso — evita lock-out si una actualización aborta.
• Anti-rollback version independiente de SemVer, controlado por release committee interno.
• Política de no-retroceso documentada disponible bajo NDA.
• IEC 62443-4-2 SL2 como meta de certificación en progreso — el proyecto no declara certificación concluida; LRI publicará el estado formal cuando lo emita el organismo certificador.

Anti-rollback en entorno regulado

En sectores regulatorios, el contador se vuelve artefacto auditable.

IEC 62443-3-3 SR 3.4 — Software and information integrity establece, como requisito de sistema, que el sistema de control debe detectar, registrar, reportar y proteger contra accesos no autorizados y alteraciones de software e información durante operación, comisionamiento, mantenimiento y reparación. El contador anti-rollback responde a ese SR.

En el mercado norteamericano, NERC CIP-010-4 obliga a las concesionarias del sistema eléctrico bulk a mantener baseline de configuración — incluyendo versión de firmware — y justificar cualquier cambio. Un equipo que acepta downgrade silencioso es incompatible: la baseline pierde valor si puede revertirse sin rastro.

Evidencia típica solicitada por auditor: documento de proceso describiendo cómo se incrementa el contador; informe de prueba mostrando rechazo de imagen con anti_rollback_version menor; documentación del service mode y autorización; registro del release committee aprobando el piso de cada release. LRI proporciona esa evidencia bajo NDA durante homologación.

Edge cases que importan

Sustitución de hardware en campo. Un AEM-60DC8 sale de operación por quema; un repuesto se instala. El repuesto sale de fábrica con contador inicial bajo. Si la planta opera v1.07, el runbook de sitio manda instalar v1.07 antes de producción — el contador avanza en el equipo nuevo. Cuidado: no devolver el equipo quemado al stock sin reset autorizado.

Restore de configuración. La configuración (parámetros Modbus, calibración, baudrate) es dato, no firmware. El restore no toca el contador. La separación entre "binario" y "configuración" es deliberada: el operador puede restaurar un backup de hace seis meses sin reabrir CVE.

Upgrade legítimo vía service mode autenticado. Escenarios raros exigen rebajar el contador — diagnóstico, devolución a fábrica para análisis forense, transferencia entre clientes. La respuesta es service mode con autenticación fuerte (token físico, credencial de fábrica, presencia física) y log persistente. Service mode no es "bypass" — es camino documentado, raro, rastreable. En el AEM-60DC8 está documentado bajo NDA y no se expone por el bus operativo Modbus RTU.

FAQ

1. Si el atacante retira la pila CR2032, ¿pone a cero el contador anti-rollback? Retirar la pila con el equipo desenergizado limpia el dominio de backup. Por eso el proyecto trata el reemplazo como evento de mantenimiento controlado, con procedimiento documentado y — en entornos regulados — log físico. La tamper detection del TAMP puede configurarse para registrar la pérdida de backup, generando evidencia forense.

2. ¿Es necesario el anti-rollback si ya tenemos firma Ed25519 y prefijo de dominio? Sí. La firma prueba autoría e integridad; el prefijo de dominio prueba que el binario es de ese producto; ninguno prueba que sea la versión correcta del momento. Sin el contador, un binario antiguo legítimamente firmado entra sin alarma.

3. ¿Llega el contador anti-rollback a saturarse en uso real? Con 32 bits, no. A una actualización por mes durante un siglo, son 1.200 incrementos — por debajo del techo de 4.294.967.295.

4. ¿Quién decide subir el piso anti-rollback de una release a otra? En proceso alineado con IEC 62443-4-1, un release committee interno con ingeniería, seguridad y producto. Criterio: subir cuando la release nueva cierre vulnerabilidad que la anterior expone.

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 formal cuando lo emita el organismo certificador. Este post no declara certificación concluida.

---