💻 computer science

ENOLA: Linear-Space and Low-Overhead Control-Flow Attestation for Microcontroller-based Systems

Este artículo presenta ENOLA, una solución de atestación de flujo de control de espacio lineal y baja sobrecarga para sistemas basados en microcontroladores que aprovecha mediciones asistidas por hardware y almacenamiento basado en registros para superar las limitaciones de escalabilidad, seguridad y rendimiento de los enfoques existentes.

Autores originales: Md Armanuzzaman, Engin Kirda, Ziming Zhao

Publicado 2026-08-12

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Md Armanuzzaman, Engin Kirda, Ziming Zhao

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que eres el guardia de seguridad de un diminuto robot alimentado por batería que vive en un bosque remoto. Este robot tiene un trabajo muy importante: debe seguir un conjunto específico de instrucciones para regar las plantas. Si un hacker se infiltra y engaña al robot para que tome un camino equivocado, las plantas podrían morir o, peor aún, el robot podría ser secuestrado para hacer algo peligroso. Para asegurarse de que el robot está haciendo su trabajo correctamente, un humano en la estación base necesita preguntarle al robot: "Muéstrame exactamente por dónde pasaste". Este proceso se llama Atestación de Flujo de Control (Control-Flow Attestation). Es como pedirle al robot que entregue un registro detallado de cada uno de los pasos que dio.

Sin embargo, hay un inconveniente: el robot es diminuto y tiene muy poca memoria y batería. Si el robot intenta escribir cada paso en un cuaderno gigante y desordenado, se quedará sin tinta (memoria) y batería mucho antes de terminar su trabajo. Además, si un hacker logra infiltrarse en la memoria del robot y borrar o cambiar el registro, el humano en la base no sabrá que el robot fue engañado. Las soluciones existentes para computadoras más grandes y potentes son como intentar cargar una biblioteca de enciclopedias en una mochila; son demasiado pesadas y lentas para estos diminutos robots. La gran pregunta es: ¿Cómo podemos lograr que un robot pequeño y débil demuestre que recorrió el camino correcto sin agotar sus recursos o permitir que un hacker falsifique la prueba?

Aquí entra ENOLA, una solución ingeniosa diseñada específicamente para estos sistemas basados en microcontroladores diminutos. Piensa en ENOLA como una brújula mágica y un escriba súper eficiente trabajando juntos. En lugar de hacer que el robot escriba cada paso en una lista larga y aburrida, ENOLA utiliza un truco especial: solo registra dónde se detuvo el robot a mirar alrededor (los "bloques básicos") y cuántas veces visitó cada lugar. Esto convierte un registro masivo y disperso en una lista de verificación pequeña y ordenada que cabe en el bolsillo del robot.

Pero ENOLA no solo reduce el tamaño de la lista; también la hace inalterable. Utiliza una característica de hardware especial integrada en los microchips modernos (llamada Autenticación de Punteros) para estampar la lista con un sello digital que es matemáticamente imposible de falsificar sin la clave secreta. Crucialmente, en lugar de escribir este sello en un papel que un hacker podría romper o rayar (la memoria), ENOLA mantiene el sello guardado dentro de un bolsillo especial y protegido dentro del cerebro del robot (un registro de hardware). Esto significa que, incluso si un hacker intenta manipular la memoria del robot, no puede tocar la prueba.

Los investigadores probaron ENOLA en aplicaciones del mundo real, incluyendo un programa que controla una bomba de jeringa y una gran biblioteca de seguridad llamada wolfSSL. Los resultados fueron impresionantes: en comparación con métodos anteriores, ENOLA redujo la cantidad de datos que el robot tenía que enviar de vuelta a la base en un promedio de 52 veces. Por ejemplo, mientras que un método antiguo podría haber enviado de vuelta 21,009 bytes de datos para un programa de prueba estándar, ENOLA solo necesitó 397 bytes. Más importante aún, ENOLA logró manejar programas enormes y complejos como wolfSSL, que tenía 5,480 bloques básicos, algo que los métodos anteriores no podían hacer sin colapsar o tardar demasiado.

El artículo muestra que ENOLA no es solo una idea teórica, sino un prototipo funcional. Demostró con éxito que se puede verificar la ruta de un programa en un dispositivo diminuto y con recursos limitados sin ralentizarlo demasiado ni hacerlo vulnerable a ataques de memoria. Si bien esto añade una pequeña cantidad de trabajo para el robot (una sobrecarga que varía según el programa, a veces alrededor del 1.3% y otras veces mayor dependiendo de la tarea), la compensación vale la pena porque finalmente hace posible la verificación segura para los miles de millones de dispositivos diminutos en los que dependemos cada día. Los autores sugieren que, aunque este es un gran paso adelante, todavía hay margen para hacerlo incluso más rápido en el futuro, quizás utilizando diferentes características de hardware o simplificando el proceso aún más.

Resumen Técnico: ENOLA – Atestación de Flujo de Control de Espacio Lineal y Baja Sobrecarga para Sistemas Basados en Microcontroladores

Declaración del Problema

La Atestación de Flujo de Control (CFA, por sus siglas en inglés) tiene como objetivo verificar la ruta de ejecución de un programa ante un verificador remoto. Sin embargo, las soluciones existentes (por ejemplo, C-FLAT, LO-FAT, OAT, Blast) son fundamentalmente incompatibles con los sistemas de microcontroladores (MCU) con recursos limitados debido a tres limitaciones principales:

Escalabilidad de la Transmisión de Datos: El tamaño de los datos de medición y de traza transmitidos en los esquemas existentes escala de forma deficiente. A menudo crece exponencialmente con el número de bloques básicos (debido a la enumeración de rutas en bucles) o linealmente con la longitud de las trazas de ejecución. Esto las hace poco prácticas para programas grandes, incluso en microprocesadores de alto rendimiento, y enteramente inviables para MCUs.
Vulnerabilidad de la Memoria: Las claves criptográficas y los datos de medición se almacenan típicamente en la memoria sin cifrado ni protección de integridad. Esto las expone a ataques de arranque en frío (cold boot) y de corrupción de memoria, una amenaza crítica para dispositivos desplegados en campo. Incluso los Entornos de Ejecución Confiables (TEEs) como ARM TrustZone aíslan la memoria, pero no la cifran inherentemente.
Sobrecarga de Rendimiento: La dependencia de funciones hash basadas en software y los frecuentes cambios de contexto entre el Entorno de Ejecución Rico (REE) y el TEE, tanto para eventos de flujo de control hacia adelante (llamada/salto) como hacia atrás (retorno), introducen una latencia significativa en MCUs con recursos limitados.

Metodología: El Enfoque ENOLA

ENOLA es una solución de CFA diseñada específicamente para sistemas basados en MCU (con el objetivo de la arquitectura ARMv8.1-M) que aborda los desafíos mencionados mediante una combinación de diseño algorítmico, utilización de hardware e instrumentación del compilador.

1. Diseño de Autenticador de Espacio Lineal

ENOLA introduce una estructura de autenticador novedosa, $Auth = (T, M)$, donde $T$ es una traza de ocurrencia de bloques básicos y $M$ es un par de mediciones acumulativas ( $M_f$ para rutas hacia adelante, $M_b$ para rutas hacia atrás).

Traza ( $T$ ): En lugar de registrar trazas de ejecución completas o enumeraciones de rutas, ENOLA registra el recuento de ocurrencias de la dirección de inicio de cada bloque básico ( $v_i.s$ ) y una lista de objetivos de salto indirecto inválidos. Esto asegura que el tamaño de la traza escale linealmente con el número de bloques básicos ( $O(|V|)$ ), independientemente de las iteraciones de los bucles o la longitud de la ejecución.
Mediciones ( $M$ ): Las rutas hacia adelante y hacia atrás se procesan mediante una cadena de MAC (Código de Autenticación de Mensaje) con clave.
- Hacia adelante ( $M_f$ ): Se computa en la entrada de los bloques básicos de destino para saltos directos.
- Hacia atrás ( $M_b$ ): Se computa en los retornos de función. Crucialmente, ENOLA no reporta la traza de la ruta hacia atrás al TEE, eliminando los cambios de contexto para los eventos de retorno.

2. Seguridad y Eficiencia Asistidas por Hardware

Autenticación de Punteros (PA): ENOLA aprovecha la extensión de Autenticación de Punteros (PA) de ARMv8.1-M (específicamente la instrucción pacg) para el cómputo de la medición. Esto proporciona generación de MAC acelerada por hardware, ofreciendo una velocidad significativamente mayor que las funciones hash basadas en software (por ejemplo, BLAKE2).
Reserva de Registros: Para prevenir ataques de corrupción de memoria, ENOLA reserva dos registros de propósito general ( $r10$ y $r11$ ) exclusivamente para almacenar las cadenas de medición acumulativas ( $M_f$ y $M_b$ ). Estos registros nunca se vuelcan (spill) a la memoria. Las claves de medición se cargan en los registros de PA dentro del TEE y nunca se exponen a la memoria del REE.
Despachador de ISR Seguro: Para manejar las Rutinas de Servicio de Interrupción (ISR) que están fuera de la Base de Computación Confiable (TCB), ENOLA emplea un despachador seguro. Este intercepta las interrupciones, guarda el contexto del programa y el estado de la medición en memoria segura, marca la pila del programa como de solo lectura durante la ejecución de la ISR y restaura el estado al retornar. Las desviaciones en el comportamiento de la ISR se señalan en la traza.

3. Flujo de Trabajo del Compilador y del Sistema

Tiempo de Compilación: El compilador ENOLA (basado en LLVM) instrumenta el código fuente para:
- Insertar llamadas a interfaces de reporte seguras (report_direct, report_indirect) para las ocurrencias de bloques básicos.
- Insertar instrucciones pacg para actualizar las mediciones en los objetivos de salto y retornos de función.
- Generar una Lista de Objetivos Indirectos (ITL) para que el verificador valide los destinos de saltos indirectos.
- Escanear el binario para asegurar que no haya instrucciones no autorizadas (por ejemplo, msr a las claves de PA, gadgets ROP) que puedan manipular los registros reservados.
Tiempo de Ejecución: El programa atestiguado se ejecuta en el estado normal (REE), mientras que el motor de atestación se ejecuta en el estado seguro (TEE). El motor configura las claves de PA, aplica políticas de MPU (W⊕X) y recolecta la traza y las mediciones.
Verificación: El verificador remoto reconstruye el grafo de flujo de control, realiza la ejecución abstracta guiada por la traza y verifica las mediciones contra el autenticador recibido.

Contribuciones Clave

Análisis Formal de la Complejidad de CFA: El artículo formaliza la complejidad de espacio de los esquemas de CFA existentes, identificando que su dependencia de los datos de traza o medición crea un cuello de botella fundamental de escalabilidad para los MCUs.
Autenticador ENOLA: Un diseño de autenticador novedoso que logra una complejidad de espacio lineal ( $O(|V|)$ ) respecto al número de bloques básicos, permitiendo la atestación escalable para programas grandes.
Seguridad Integrada con Hardware: La primera implementación que utiliza PA de ARM para la atestación de flujo de control en sistemas embebidos, manteniendo las claves y cadenas de medición en registros/hardware de PA para frustrar la corrupción de memoria.
Reducción de Cambios de Contexto: Eliminación de los cambios de contexto del TEE para las mediciones de borde posterior (retorno) mediante el cómputo directo en el REE usando instrucciones PA.
Implementación y Evaluación: Una implementación completa en el Cortex-M85 (ARMv8.1-M) utilizando pasos de LLVM, validada en aplicaciones del mundo real incluyendo la suite Embench y wolfSSL.

Resultados

La evaluación se realizó en un MCU Cortex-M85 funcionando a 25 MHz, comparando ENOLA con Blast (el trabajo previo más eficiente) y otros esquemas.

Sobrecarga de Transmisión de Datos: ENOLA reduce drásticamente el tamaño del reporte de atestación. En la suite Embench, ENOLA redujo los datos transmitidos en un promedio de 52x en comparación con Blast. Por ejemplo, Blast produjo un promedio de 21,009 bytes de datos de atestación, mientras que ENOLA requirió solo 397 bytes.
Escalabilidad: ENOLA escaló con éxito a aplicaciones grandes y reales como wolfSSL (específicamente el módulo RSA con 5,480 bloques básicos), una tarea donde las soluciones previas fallaron o se vieron limitadas a fragmentos pequeños.
Sobrecarga de Rendimiento:
- Tiempo de Ejecución: La sobrecarga de ENOLA varía según la aplicación y el nivel de optimización. Para la aplicación de la bomba de jeringa (syringe pump), logró una baja sobrecarga del 1.3% para la ruta move-syringe. A través de los benchmarks de Embench, las sobrecargas variaron significativamente (por ejemplo, de 9.81% a más del 1000% en casos específicos), pero fueron generalmente competitivas o menores que las de Blast cuando se considera la granularidad de la atestación (nivel de bloque básico vs. nivel de función).
- Cambios de Contexto: El cambio de contexto representó aproximadamente el 26% de la sobrecarga total del tiempo de ejecución bajo la optimización O2.
Tamaño de Código: La sobrecarga del tamaño de código promedió alrededor del 30-40% con la optimización O2, significativamente menor que la sobrecarga del 64% de Blast en Embench.

Significado y Reivindicaciones

El artículo afirma que ENOLA representa un paso significativo para hacer que la Atestación de Flujo de Control sea factible para sistemas basados en microcontroladores. Al desacoplar el tamaño de la atestación de la longitud de la traza de ejecución y aprovechar las primitivas de hardware (PA, TrustZone, MPU) para asegurar los estados de medición sin almacenamiento en memoria, ENOLA permite la verificación de aplicaciones embebidas grandes y complejas por primera vez. Los autores posicionan a ENOLA no solo como una mejora de rendimiento, sino como una evolución necesaria para abordar las limitaciones fundamentales de escalabilidad y seguridad de los enfoques de CFA existentes en el dominio embebido. El trabajo es de código abierto para facilitar la investigación y adopción posteriores.