💻 computer science

State Authenticity under Multiple Bus Masters: A Non-Secure DMA Gap and Mitigation for TrustZone-M Proofs of Executio

Este artículo revela que las pruebas de ejecución de TrustZone-M son vulnerables a la manipulación de estados mediante controladores DMA no seguros debido a que sus garantías de seguridad dependen únicamente del aislamiento de la CPU, y propone una mitigación ligera mediante la seguridad de DMA por canal para asegurar la autenticidad del estado contra todos los maestros de bus.

Autores originales: Arash Razban

Publicado 2026-07-30

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Arash Razban

Artículo original bajo licencia CC BY 4.0 (https://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 un mundo donde pequeñas y baratas computadoras están esparcidas por todas partes: dentro de tu termostato inteligente, en tu monitor de actividad física e incluso en los sensores de una planta de producción. Estos pequeños dispositivos se supone que son reporteros honestos, enviando datos como lecturas de temperatura o conteos de movimiento. Pero, ¿qué pasaría si un hacker tomara el control de uno de estos dispositivos y comenzara a mentir, alimentando una gigantesca base de datos en la nube con datos falsos? Para detener esto, utilizamos una "prueba de ejecución" digital. Piensa en ello como un notario público para computadoras: el dispositivo firma un recibo diciendo: "Prometo que ejecuté este problema matemático específico exactamente como se me pidió, sin que nadie manipulara los números".

Para que esto funcione, el dispositivo necesita dos cosas: una forma segura de demostrar que ejecutó el código correcto y una forma de demostrar que los datos que utilizó (el "estado") no han sido manipulados. El documento que estamos analizando examina una versión de alta tecnología de este sistema de prueba llamado TrustZone-M, que está integrado en muchos microchips modernos. Es como una bóveda súper segura dentro del chip que separa las tareas "confiables" de las "no confiables". La gran pregunta es: si un hacker irrumpe en el lado "no confiable", ¿puede cambiar sigilosamente los datos mientras la computadora realiza sus cálculos, engañando al sistema para que firme un recibo falso? Este documento investiga si las reglas actuales de la bóveda son lo suficientemente fuertes como para detener a un ayudante astuto e invisible que puede escribir datos sin que la computadora principal se dé cuenta.

El bolígrafo invisible: Cómo un hacker "fantasma" engañó a un chip seguro

En el juego de alto riesgo de la seguridad embebida, investigadores propusieron recientemente un esquema ingenioso llamado SLAPP (Pruebas de Ejecución con Estado). Imagina a SLAPP como un bibliotecario muy estricto que quiere verificar que un estudiante (el dispositivo) resolvió un problema matemático correctamente. El bibliotecario comprueba dos cosas: primero, que el estudiante usó el libro de texto adecuado (el código) y, segundo, que el estudiante no hizo trampa cambiando los números en su cuaderno (el estado) mientras resolvía el problema.

La lógica del bibliotecario era simple y parecía infalible: "Si el estudiante intenta cambiar los números en su cuaderno, primero debe abrir el libro de texto para encontrar las instrucciones sobre cómo hacerlo. Pero como tenemos un escáner mágico que vigila el libro de texto, cualquier cambio en las instrucciones sería detectado de inmediato. Por lo tanto, si el libro de texto parece perfecto, los números en el cuaderno también deben ser honestos".

Este documento, sin embargo, corre la cortina para revelar un fallo en esa lógica. Los investigadores descubrieron que el "estudiante" no es el único que puede escribir en el cuaderno. Hay un segundo escritor invisible: un controlador DMA (Acceso Directo a Memoria).

El escritor "fantasma"

Para entender el DMA, imagina que el procesador principal de la computadora (la CPU) es un chef ocupado picando verduras. El chef es el único que tiene permitido tocar la tabla de cortar (la memoria) en la cocina. El chef es vigilado por una cámara de seguridad (el aislamiento de TrustZone-M) que asegura que nadie más pueda tocar la tabla.

¡Pero espera! Hay un brazo robótico (el controlador DMA) sentado en la cocina. Este robot está programado para mover ingredientes desde la nevera hacia la tabla de cortar automáticamente. La cámara de seguridad solo está vigilando las manos del chef. No sabe que el robot existe. El robot puede acercarse, agarrar una bolsa de harina y volcarla sobre la tabla de cortar mientras el chef está ocupado picando. El chef nunca ve al robot, y la cámara de seguridad no parpadea porque las manos del chef no se movieron.

En el mundo del esquema de seguridad SLAPP, el "robot" es el controlador DMA. Los investigadores descubrieron que el sistema de seguridad solo estaba vigilando al chef (la CPU). Asumía que si el libro de recetas (la memoria del programa) no se cambiaba, nadie podía cambiar los ingredientes (el estado). Pero el robot podía cambiar los ingredientes sin tocar el libro de recetas.

El ataque: Un envenenamiento silencioso

Los investigadores configuraron una prueba en un chip real (un microcontrolador STM32L5) para ver si este escritor "fantasma" podía realmente romper el sistema. Crearon un escenario donde un hacker, que ya había tomado el control de la parte "no confiable" del chip, utilizó el robot DMA para reemplazar un número legítimo por uno falso justo en medio del cálculo.

Así fue como funcionó el truco:

La verificación: La parte segura del chip revisó el cuaderno y vio que los números estaban limpios. Dio el visto bueno.
El intercambio: Inmediatamente después de la verificación, pero antes de que se firmara el resultado final, el robot DMA se lanzó y reemplazó el número con un valor "envenenado".
La firma: El chip terminó las matemáticas usando el número envenenado y firmó el recibo.
El resultado: La cámara de seguridad miró el libro de recetas, vio que estaba intacto y aceptó el recibo como válido.

El resultado fue una "prueba de ejecución" matemáticamente válida pero fácticamente falsa. El sistema certificó un resultado basado en datos que habían sido manipulados, todo mientras la computadora principal pensaba que todo estaba bien.

Por qué fallaron las defensas habituales

Los investigadores se preguntaron entonces: "¿Por qué el sistema de seguridad integrado en el chip no detuvo esto?". Probaron tres defensas estándar, y cada una falló por una razón distinta y curiosa:

El intento de "Bloquear al Robot": Intentaron decirle al sistema de seguridad que bloqueara el brazo del robot. Pero el sistema dijo: "Yo no controlo robots; yo solo controlo al chef". La puerta de seguridad simplemente no se aplicaba al robot.
El intento de "Bloquear la Mesa": Intentaron bloquear la tabla de cortar para que nadie pudiera tocarla. ¡Pero esto era demasiado estricto! El chef también necesitaba escribir en la tabla. Si bloqueaban la tabla, el chef no podía hacer su trabajo y todo el sistema se detenía.
El intento de la "Alarma": Intentaron configurar una alarma que sonaría si el robot tocaba la tabla. Pero la alarma solo suena si alguien rompe una regla. Dado que el robot tenía permitido tocar la tabla (era solo el tipo de toque incorrecto para esta regla de seguridad específica), la alarma permaneció en silencio.

La solución: Domar al robot

La solución no fue construir un muro más grande o una alarma más fuerte. Fue darle al robot su propia identificación de seguridad. Los investigadores descubrieron que el robot (el controlador DMA) tenía en realidad un interruptor oculto en su interior que podía ser activado por el chef seguro.

Al activar este interruptor, el mundo seguro podía decir: "Este brazo robótico específico está ahora bajo mi control. Si el hacker intenta ordenarle que se mueva, ignorará al hacker y lanzará una bandera roja".

Esta solución fue sorprendentemente barata y fácil. No ralentizó al chef ni requirió hardware nuevo. Los investigadores la probaron asegurando todos los brazos robóticos del chip. Cuando intentaron el ataque de nuevo, el robot se negó a moverse, la alarma sonó y el recibo falso fue rechazado.

La gran lección

La lección más importante de este documento no trata solo de un chip específico o de un truco de hacker específico. Es una lección sobre cómo pensamos acerca de la seguridad.

Durante mucho tiempo, los diseñadores de seguridad asumieron que si protegías al cerebro principal (la CPU), protegías todo lo demás. Este documento demuestra que, en los chips modernos, hay otras "manos" alcanzando la memoria que el cerebro no ve. Si quieres confiar en los datos de una computadora, no puedes solo vigilar al cerebro; tienes que vigilar cada mano que pueda tocar los datos.

Los investigadores demostraron que el sistema SLAPP, tal como fue publicado, tenía un agujero en su lógica porque olvidó a las "manos robóticas". No solo encontraron el agujero; mostraron exactamente cómo parchearlo con una solución simple y ligera. Es un recordatorio de que, en el mundo de las computadoras diminutas, los hackers más peligrosos podrían no ser los que escriben en un teclado, sino los robots invisibles trabajando en segundo plano, esperando a que alguien olvide revisar su identificación.

Resumen Técnico: Autenticidad del Estado bajo Múltiples Maestros de Bus

Planteamiento del Problema
El artículo identifica una brecha crítica de solidez en las pruebas de ejecución con estado en plataformas de consumo Arm TrustZone-M, dirigiéndose específicamente al esquema SLAPP (publicado en IEEE TIFS 2025). SLAPP tiene como objetivo proporcionar garantías de atestación remota de que un dispositivo embebido de gama baja ejecutó una función correctamente sobre un estado auténtico y no modificado, incluso si el mundo no seguro está completamente comprometido.

La vulnerabilidad central reside en la Propiedad P4 (Autenticidad del Estado). El argumento de seguridad de SLAPP se basa en una reducción: asume que cualquier adversario que manipule el estado atestatado ( $S$ ) durante la ejecución debe modificar la memoria del programa ($PMEM$) para hacerlo. Dado que SLAPP mide la integridad de $PMEM$, concluye que la manipulación del estado sería detectada.

Sin embargo, esta reducción es unsound (carece de solidez lógica) en el hardware TrustZone-M. El aislamiento basado en direcciones de la plataforma (SAU/IDAU) restringe únicamente a la CPU. Otros maestros de bus, como los controladores DMA, no están sujetos a estos atributos de seguridad centrados en la CPU. En la plataforma objetivo STM32L5, los controladores DMA son no seguros y programables por defecto. Un adversario puede programar un canal DMA para escribir directamente en el estado atestatado en la memoria de datos sin que la CPU ejecute ninguna instrucción, modificando así $S$ mientras deja $PMEM$ intacto. Consecuentemente, la medición $h = H(PMEM, \dots)$ sigue siendo válida y la prueba es aceptada sobre un estado envenenado.

Metodología
Los autores validan esta brecha utilizando el mismo hardware de referencia y el modelo de adversario definido por SLAPP:

Modelo de Amenaza: Un mundo no seguro totalmente comprometido con acceso a todo el código y datos no seguros, pero sin acceso a la memoria segura o fallos de hardware.
Construcción del Ataque: Los autores implementaron un ataque puramente basado en software en una placa NUCLEO-L552ZE-Q:
- Un adversario no seguro pre-arma un canal DMA (configurado para transferencia de memoria a memoria) para sobrescribir el estado protegido (un caché de respuesta aleatorizada) con un valor de veneno.
- El ataque se dispara dentro de la ventana "check-then-commit" (verificar-luego-confirmar): después de que el mundo seguro verifica el estado (CheckState) pero antes de que el estado sea confirmado (SetState).
- La transferencia DMA se ejecuta de forma autónoma, corrompiendo el estado sin intervención de la CPU.
Evaluación de la Atomicidad: Los autores probaron el ataque contra la configuración estricta de SLAPP (interrupciones deshabilitadas) y su configuración relajada. Demostraron que deshabilitar las interrupciones de la CPU no restringe al maestro de bus DMA, lo que significa que el ataque tiene éxito incluso en la configuración estrictamente atómica, tal como fue publicada.
Análisis de Defensas Nativas: El artículo evalúa sistemáticamente por qué las instalaciones de aislamiento nativas de TrustZone-M fallan en mitigar esto:
- Controlador de Seguridad de Periféricos (TZSC): No gobierna los controladores DMA; intentar asegurar los mismos vía TZSC provoca un fallo de arranque (boot fault).
- Protección de Memoria Basada en Bloques (MPCBB): Filtra basándose en atributos de transacción de seguridad (seguro vs. no seguro) en lugar del maestro emisor. No puede distinguir entre una escritura legítima de la CPU no segura y una escritura maliciosa de un DMA no seguro; asegurar los bloques de memoria bloquea la CPU, rompiendo el esquema.
- Controlador de Acceso Ilegal (TZIC): Solo reporta violaciones; no puede prevenir la transferencia si el acceso es técnicamente "legal" (un maestro no seguro escribiendo en memoria no segura).

Contribuciones Clave

Primera Demostración en Silicio: El artículo proporciona la primera prueba empírica de que un esquema publicado de prueba de ejecución con estado en TrustZone-M (SLAPP) falla en imponer su propiedad de autenticidad de estado contra un adversario DMA no seguro en su propio hardware de referencia.
Independencia de la Atomicidad: Los autores muestran que la vulnerabilidad no es resultado de relajaciones opcionales de la atomicidad, sino que afecta a la configuración estrictamente atómica, ya que el enmascaramiento de interrupciones de la CPU no restringe a los maestros de bus.
Análisis Sistemático de Defensa: Un análisis detallado que explica por qué las tres primitivas de aislamiento naturales de TrustZone-M (TZSC, MPCBB, TZIC) son insuficientes, estableciendo restricciones de diseño específicas para cualquier mitigación correcta.
Mitigación Ligera: Los autores proponen y validan una corrección mínima utilizando la seguridad por canal nativa del controlador DMA (DMA_CCRx.SECM). Al asegurar el canal DMA desde el mundo seguro durante el arranque, se impide que el software no seguro reprograme el canal. Esto bloquea al adversario al nivel del maestro sin afectar la capacidad de la CPU para leer/escribir el estado.
Principio General: El artículo establece que para cualquier esquema de atestación sobre estado mutable en una plataforma de múltiples maestros, la autenticidad debe ser mediada contra cada maestro de bus capaz de escribir el estado, no solo la CPU.

Resultados

Éxito del Ataque: En la placa de referencia, el adversario corrompió con éxito el estado atestatado dentro de la ventana del protocolo. El esquema no levantó errores y el verificador del prototipo aceptó la prueba sobre la salida envenenada.
Éxito de la Mitigación: Cuando se aseguraron los 16 canales DMA del dispositivo durante el arranque:
- El intento del adversario de reprogramar el canal DMA fue interceptado (se disparó la interrupción de acceso ilegal).
- El estado permaneció sin corrupción.
- El protocolo benigno se ejecutó correctamente con un overhead insignificante (la corrección es una escritura de registro única en tiempo de arranque).
- Se demostró que la corrección es "quirúrgica", bloqueando la ruta DMA mientras preserva el acceso legítimo de la CPU al estado.
Análisis de Overhead: La configuración de atomicidad estricta (deshabilitar interrupciones) incurre en un costo de tiempo real significativo (~654ms de ventana enmascarada) pero proporciona cero beneficio de seguridad contra la amenaza DMA. La configuración relajada elimina este costo sin sacrificar la seguridad contra este vector de ataque específico.

Significancia y Reivindicaciones
El artículo afirma que el esquema SLAPP publicado específicamente no tiene ejecución de su garantía de autenticidad de estado contra un adversario DMA no seguro en su hardware de referencia. El fallo radica en una reducción unsound en su argumento formal, que erróneamente equipara la integridad del código con la integridad del estado bajo un supuesto de un único escritor (CPU).

Los autores enfatizan que esto es un fallo del argumento y de la implementación específica, no una prueba de que no sea posible una atestación de estado segura en TrustZone-M. La mitigación propuesta (seguridad de DMA por canal) es suficiente para la carga de trabajo publicada de SLAPP (que no utiliza DMA) y restaura la propiedad de seguridad pretendida. El artículo concluye que cualquier esquema de atestación futuro que razone sobre estados mutables en plataformas de múltiples maestros debe mediar explícitamente todos los maestros de bus, no solo la CPU.