Trust Nothing: RTOS Security without Run-Time Software TCB (Extended Version)

Este trabajo presenta una arquitectura de capacidades novedosa que, mediante la implementación en FPGA y un sistema operativo en tiempo real basado en Zephyr, logra la seguridad de dispositivos embebidos sin un núcleo de confianza de software en tiempo de ejecución, aislando completamente todos los subsistemas y periféricos no confiables sin requerir cambios en el hardware.

Lo esencial

Imagina que tu dispositivo electrónico (como un router, un sensor industrial o un dispositivo médico) es como una casa muy segura.

En el mundo actual, los ladrones (los hackers) pueden entrar de tres formas diferentes:

1. Robando la llave de la puerta principal: Un error en el software de la aplicación (el inquilino).
2. Entrando por la ventana del administrador: Un fallo en el sistema operativo (el dueño de la casa).
3. Entrando por el sistema de riego o la electricidad: Un dispositivo periférico (como una tarjeta de red o un sensor) que tiene acceso directo a la memoria y puede actuar como un "caballo de Troya".

La mayoría de los sistemas de seguridad actuales solo protegen contra dos de estas tres amenazas. Si proteges la puerta y la ventana, pero confías ciegamente en el sistema de riego, el ladrón puede entrar por ahí.

Este paper presenta una solución radical llamada Skadi (el sistema operativo) y Bredi (el chip de hardware). Su lema es: "No confíes en nada".

Aquí te explico cómo funciona usando analogías sencillas:

1. El problema: La "Caja Fuerte" tradicional

Normalmente, los sistemas operativos funcionan como un gerente de seguridad (el kernel) que tiene todas las llaves maestras. Si el gerente es corrupto o es engañado por un ladrón, todo el edificio cae. Además, si el sistema de riego (un dispositivo) tiene una llave maestra, puede robar todo lo que quiera.

2. La solución: El sistema de "Billetes de Banco" (Capacidades)

En lugar de tener un gerente con llaves maestras, Skadi y Bredi usan un sistema de "Billetes de Banco" (llamados capacidades o tokens).

• No hay llaves maestras: Nadie tiene una llave que abra todo.
• Solo tienes lo que te dan: Si quieres abrir una puerta (acceder a un archivo), necesitas un billete específico que diga exactamente: "Puedes entrar a esta habitación, solo por 5 minutos, y solo para leer".
• El billete es inviolable: Estos billetes están protegidos por el hardware mismo (el chip Bredi). Un hacker no puede falsificarlos, no puede inventar uno nuevo y no puede robar uno que no le pertenece.

3. La gran innovación: Desconfiar de todo

Lo revolucionario de este trabajo es que no confían en nadie, ni siquiera en el propio sistema operativo o en los dispositivos conectados.

• El Sistema Operativo (Skadi) está fragmentado: Imagina que el sistema operativo no es un solo edificio gigante, sino una ciudad de pequeñas casitas aisladas (sub-sistemas).

  • Hay una casita para la red.
  • Hay otra para la memoria.
  • Otra para los drivers de los dispositivos.
  • Ninguna casita puede entrar a la otra a menos que reciba un "billete" específico. Si la casita de la red se infecta, el ladrón queda atrapado allí y no puede saltar a la casita de la memoria.

• Los dispositivos son sospechosos: Incluso si un dispositivo de red (como un chip WiFi) es malicioso, el hardware (Bredi) le dice: "Solo puedes tocar estos 10 bytes de memoria, nada más". Si intenta tocar algo más, el hardware le cierra la puerta inmediatamente.

4. ¿Cómo funciona sin un "Jefe" de confianza?

Aquí viene la magia:

1. Al encender el dispositivo: Un pequeño programa de arranque (el "Cargador") crea todas las casitas y les entrega sus billetes iniciales.
2. El truco final: Una vez que todo está listo, el Cargador se autodestruye. Se borra a sí mismo.
3. Resultado: Ahora el dispositivo está en funcionamiento, pero no hay ningún software de confianza corriendo. Si un hacker intenta atacar el sistema, no hay "jefe" que pueda ser engañado. Solo hay pequeñas casitas aisladas que se vigilan entre sí.

5. ¿Y si algo se bloquea? (Tiempo Real)

Un problema común en seguridad es que si un programa se cuelga, todo el sistema se detiene. Skadi soluciona esto con interrupciones no enmascarables.

• Imagina que tienes un botón de pánico que nadie puede desactivar, ni siquiera el sistema operativo. Si un programa se vuelve loco y entra en un bucle infinito, el hardware puede forzarlo a detenerse y llamar a un guardia de seguridad (una rutina de interrupción) para que limpie el desastre, asegurando que el dispositivo siga funcionando.

En resumen: ¿Por qué es importante?

Hasta ahora, para tener seguridad total, teníamos que confiar en que el "gerente" (el kernel) y los "dispositivos" (drivers) eran honestos.

Skadi y Bredi dicen: "No confíes en nadie. Divide y vencerás".

• Dividen el sistema en miles de piezas pequeñas e independientes.
• Usan un hardware que actúa como un guardián estricto que solo deja pasar a quien tiene el billete correcto.
• Eliminan al "jefe" una vez que todo está listo, para que no haya nadie que pueda ser corrompido.

El resultado: Un sistema que puede resistir ataques de software, fallos del sistema operativo y dispositivos maliciosos, todo mientras sigue funcionando rápido y de manera segura, ideal para el futuro de los dispositivos críticos (como redes 5G, coches autónomos o infraestructura médica).

Es como construir una fortaleza donde, en lugar de tener un solo muro alto, tienes miles de celdas individuales. Si un ladrón entra en una celda, no puede salir a robar el resto del tesoro, y no hay un guardián central que pueda ser sobornado.

Resumen técnico

Resumen Técnico: Trust Nothing (RTOS de Seguridad sin TCB de Software en Tiempo de Ejecución)

1. El Problema

Los dispositivos embebidos enfrentan una amenaza creciente que proviene de tres vectores principales:

1. Software de aplicación: Vulnerabilidades en el código de usuario.
2. Kernel del Sistema Operativo: Vulnerabilidades en el núcleo (RTOS o Linux).
3. Dispositivos Periféricos: Ataques a través de dispositivos con acceso directo a memoria (DMA) que pueden actuar como "caballos de Troya" de hardware.

Las defensas arquitectónicas existentes suelen proteger contra solo dos de estos vectores simultáneamente. Por ejemplo, los sistemas basados en MMU (Unidad de Gestión de Memoria) protegen contra aplicaciones maliciosas y dispositivos, pero requieren confiar en el kernel para configurar la MMU correctamente, lo que mantiene un TCB (Base de Confianza Computacional) de software en tiempo de ejecución. Si el kernel es comprometido, todo el sistema cae. Por otro lado, las arquitecturas de capacidades modernas (como CHERI) reducen el TCB de software, pero a menudo confían en controladores de dispositivos o no protegen contra ataques DMA.

El objetivo de este trabajo es cerrar esta brecha: lograr seguridad contra software malicioso, kernels comprometidos y dispositivos DMA maliciosos sin depender de ningún TCB de software en tiempo de ejecución, manteniendo al mismo tiempo garantías de tiempo real suave (soft real-time).

2. Metodología

Los autores proponen un diseño conjunto de hardware y software que combina una nueva arquitectura de capacidades llamada Northcape con una implementación de hardware específica y un sistema operativo modificado.

• Arquitectura Northcape: Se basa en capacidades de token que se gestionan a nivel del bus del sistema (Northbridge), no dentro del CPU. Esto permite que tanto el software como los dispositivos DMA sean tratados como entidades no confiables. Las capacidades contienen metadatos (límites, permisos, restricciones) que se resuelven en hardware antes de permitir cualquier acceso a la memoria.
• Implementación de Hardware (Bredi): Es la primera implementación física de Northcape en un SoC (System on Chip) basado en FPGA. Utiliza un procesador cva6 RISC-V modificado, un MMU de capacidades (NC MMU), un resolvedor de capacidades y un MMU para dispositivos DMA (AXI MMU).
• Sistema Operativo (Skadi): Una RTOS basada en Zephyr que ha sido completamente descompuesta. En lugar de un kernel privilegiado, todas las funciones (planificador, asignador de memoria, controladores, manejo de interrupciones) se ejecutan como subsistemas aislados mutuamente.

3. Contribuciones Clave

A. Arquitectura de Hardware (Bredi)

• Resolución de Capacidades en el Bus: La traducción de tokens de capacidad a direcciones físicas ocurre en el Northbridge, no en el CPU. Esto protege a los dispositivos DMA al igual que al CPU.
• Manejo de Interrupciones No Confiables: Se introdujeron extensiones en el CPU cva6 para permitir que las Rutinas de Servicio de Interrupción (ISRs) sean no confiables.
  • Apilamiento de Registros: Se duplica el conjunto de registros para separar el estado del subsistema interrumpido del de la ISR.
  • Vectorización de Interrupciones: Las interrupciones desencadenan llamadas de subsistema a manejadores específicos, manteniendo el aislamiento.
  • Interrupciones No Enmascarables (NMI): Garantizan la disponibilidad de manejadores críticos incluso si un atacante intenta deshabilitar interrupciones.
• Protección Temporal y Espacial: Uso de nonces aleatorios y restricciones de ID de subsistema para evitar ataques de adivinación y reutilización de capacidades (use-after-free).

B. Sistema Operativo (Skadi)

• Cero TCB en Tiempo de Ejecución: El único componente confiable es el Cargador (Loader), que existe solo durante el arranque. Una vez que todos los subsistemas están cargados, el cargador se autodestruye (usando una "trampilla" o trapdoor), eliminando cualquier privilegio de software en tiempo de ejecución.
• Aislamiento de Subsistemas: Todos los componentes (planificador, asignador de memoria, controladores de red, etc.) son subsistemas independientes. No hay un kernel centralizado.
• Llamadas de Subsistema: Mecanismo para la comunicación entre subsistemas que cambia atómicamente el ID del subsistema activo y el flujo de control, asegurando que un subsistema no pueda acceder a los datos de otro sin una capacidad explícita.
• Controladores y DMA No Confiables: Los controladores de dispositivos y los manejadores de DMA son subsistemas no confiables. El hardware garantiza que solo puedan acceder a la memoria que se les delegó explícitamente.

C. Mecanismos de Seguridad Específicos

• Restricciones de ID de Subsistema: Las capacidades pueden estar vinculadas a un ID de subsistema específico. Si un subsistema intenta usar una capacidad que no le pertenece (incluso si adivina el token), el hardware bloquea el acceso.
• Operaciones de Bloqueo (Lock): Permiten el acceso exclusivo a una capacidad, evitando condiciones de carrera (TOCTOU) entre subsistemas o dispositivos.
• Revocación Segura: La operación revoke sobrescribe la memoria con ceros al destruir una capacidad, evitando fugas de información.

4. Resultados y Evaluación

Los autores implementaron un prototipo en una FPGA (Digilent Genesys 2) y evaluaron el rendimiento y la seguridad.

• Seguridad: El sistema logra las propiedades de Confidencialidad (C), Integridad (I) y Disponibilidad (A) sin un TCB de software en tiempo de ejecución. Los subsistemas están aislados incluso si el planificador o el asignador de memoria son maliciosos.
• Rendimiento Computacional:
  • En benchmarks de cómputo puro (Coremark, Stream), Skadi tiene un rendimiento casi idéntico a Zephyr estándar (la diferencia es <0.2%), ya que la resolución de capacidades en caché (NTLB) es muy rápida.
  • Linux muestra un rendimiento inferior debido a fallos de TLB en su configuración de prueba.
• Rendimiento de E/S y Red:
  • Existe una sobrecarga en escenarios de E/S (red) debido a la gran cantidad de llamadas de subsistema necesarias para la compartimentación estricta.
  • La latencia de red (ping) es aproximadamente 3-4 veces mayor que en Zephyr estándar, pero sigue siendo práctica para aplicaciones embebidas.
  • El rendimiento de TCP es menor que en Linux, pero esto se atribuye más a la pila de red de Zephyr que a la arquitectura de seguridad en sí.
• Tiempo Real:
  • Skadi cumple con los requisitos de tiempo real suave. La latencia de interrupción es de aproximadamente 68 µs (frente a ~24 µs en Zephyr estándar), lo cual es aceptable para la mayoría de las aplicaciones críticas.
  • El uso de NMI garantiza que los manejadores críticos siempre se ejecuten.
• Área de Chip: La implementación de Northcape añade una sobrecarga de área de aproximadamente un 31% en LUTs en la FPGA, principalmente debido a la jerarquía de caché de capacidades (NTLB L2) y el resolvedor.

5. Significado e Impacto

Este trabajo representa un avance fundamental en la seguridad de sistemas embebidos:

1. Paradigma "Trust Nothing": Demuestra que es posible construir sistemas donde ningún componente de software en tiempo de ejecución (ni kernel, ni controladores, ni aplicaciones) debe ser confiado. La seguridad se delega enteramente al hardware y a un cargador efímero.
2. Protección Integral: Es una de las primeras arquitecturas que protege simultáneamente contra aplicaciones, kernels y dispositivos DMA maliciosos sin requerir cambios en el hardware de los periféricos (los dispositivos son tratados como no confiables por defecto).
3. Viabilidad Práctica: A pesar de la sobrecarga de rendimiento en E/S, el sistema es lo suficientemente rápido para ser utilizado en infraestructura de red crítica (como estaciones base 5G) y dispositivos de seguridad.
4. Futuro: Abre la puerta a un diseño de seguridad "Security-by-Design" donde la compartimentación fina es nativa del hardware, reduciendo la superficie de ataque y facilitando la integración de componentes de código cerrado o de terceros sin comprometer la seguridad del sistema.

En conclusión, Skadi y Bredi establecen un nuevo estándar para la seguridad en sistemas embebidos críticos, demostrando que la eliminación del TCB de software en tiempo de ejecución es técnicamente factible y ofrece una postura de seguridad superior a las soluciones actuales.