Designing Trustworthy Layered Attestations

Este artículo propone un enfoque de atestación en capas que, mediante la estructuración del sistema y el uso de hardware y software ampliamente disponibles como TPM y SELinux, logra generar evidencias de confianza fiables y de bajo costo frente a adversarios definidos, aplicando principios universales que también se extienden a tecnologías de computación confidencial como AMD SEV-SNP.

Lo esencial

Imagina que quieres enviar un paquete muy valioso (datos sensibles) a una casa lejana. Antes de enviarlo, necesitas estar 100% seguro de que la casa no está llena de ladrones disfrazados de empleados, ni tiene trampas ocultas en las paredes.

¿Qué es la "Atestación"?
En el mundo de la ciberseguridad, la "atestación" es como pedirle a esa casa lejana un reporte de seguridad en tiempo real. Es una prueba digital que dice: "¡Hola! Estoy limpio, mis puertas están cerradas y nadie ha entrado por la fuerza".

El problema, como explica este paper, es que un ladrón muy astuto (un hacker) podría falsificar ese reporte. Podría disfrazarse de empleado, borrar las cámaras de seguridad y decir: "Todo está bien", mientras roba el paquete.

La Solución: La Torre de Capas (Atestación en Capas)
Los autores proponen que no basta con mirar una sola cosa (como si solo miraras la puerta principal). Necesitas una torre de confianza construida por capas, como una cebolla o una muñeca rusa. Si un ladrón engaña una capa, las otras capas lo delatan.

Aquí están los 5 Principios (Máximas) que usan para construir esta torre, explicados con analogías sencillas:

1. El Principio del "Círculo Pequeño" (Maxim 1)

• La idea: No intentes vigilar todo el sistema, es demasiado grande y fácil de engañar.
• La analogía: Imagina que tienes un castillo. En lugar de vigilar cada ladrillo del muro exterior, te concentras en una pequeña habitación segura dentro del castillo donde se guarda el tesoro. Solo permites que entren cosas que pasan por un filtro estricto.
• En la práctica: Usan un sistema llamado SELinux para crear "burbujas" de seguridad. Solo los programas autorizados pueden tocar los archivos importantes. Si un virus intenta entrar, la burbuja lo bloquea.

2. El Principio del "Camarero de un Solo Pedido" (Maxim 2)

• La idea: Los programas que viven mucho tiempo y reciben datos de extraños son peligrosos. Si se infectan, siguen infectados para siempre.
• La analogía: Imagina un camarero en un restaurante. Si el camarero está envenenado, envenenará a todos los clientes que atienda.
  • La solución: En lugar de un camarero fijo, imagina que cada cliente recibe un camarero nuevo y virgen que solo sirve ese plato y luego desaparece. Si el plato estaba envenenado, el camarero muere, pero el siguiente cliente recibe un camarero limpio.
• En la práctica: El sistema crea un proceso nuevo para cada mensaje que recibe. Si un mensaje es malicioso, solo afecta a ese proceso momentáneo, no al sistema entero.

3. El Principio del "Secreto que no se Queda" (Maxim 3)

• La idea: Las llaves maestras para firmar los reportes de seguridad no deben guardarse en la memoria del ordenador, porque un hacker podría robarlas si entra brevemente.
• La analogía: No guardes la llave de tu caja fuerte en tu bolsillo (memoria RAM), porque si te roban el bolsillo, te roban la caja. En su lugar, guarda la llave en un cofre de acero indestructible (un chip de hardware llamado TPM) que solo se abre bajo condiciones muy específicas.
• En la práctica: Usan un chip de hardware (TPM) que guarda la llave de firma. El ordenador no puede "ver" la llave, solo puede pedirle al chip que firme algo si todo está bien.

4. El Principio del "Origen Confiable" (Maxim 4)

• La idea: El reporte de seguridad debe demostrar que nació de un sistema que arrancó correctamente, no de un sistema hackeado.
• La analogía: Es como un sello de autenticidad en una botella de vino. No basta con que la botella diga "Vino de Calidad". Necesitas un sello que diga: "Esta botella fue llenada en la bodega oficial, con la receta original, y nadie la abrió hasta ahora".
• En la práctica: El chip de hardware (TPM) solo firma el reporte si verifica que el sistema arrancó con el software correcto (como verificar que el motor del coche es el original y no uno clonado).

5. El Principio de la "Línea de Tiempo" (Maxim 5)

• La idea: Debes verificar las partes fundamentales del sistema antes de verificar las partes que dependen de ellas.
• La analogía: Si quieres verificar que un edificio es seguro, primero revisa los cimientos. Si los cimientos están podridos, no importa si el techo está perfecto; el edificio se caerá. No puedes verificar el techo si no has verificado que los cimientos sostienen el edificio.
• En la práctica: Primero verifican el hardware y el arranque (UEFI), luego el sistema operativo (Kernel), y finalmente las aplicaciones. Si el sistema operativo está corrupto, las pruebas de las aplicaciones no sirven de nada.

---

¿Cómo funciona en la vida real? (El Ejemplo del Filtro)

Los autores probaron esto con un sistema llamado CDS (Solución de Dominio Cruzado). Imagina un filtro de agua que conecta un río contaminado (Internet abierto) con un tanque de agua potable (Red segura).

• El sistema revisa que el filtro (software) sea el correcto.
• Verifica que nadie haya cambiado las mangueras (configuración).
• Usa el chip de seguridad para firmar un reporte que dice: "El agua que sale es limpia".

¿Es lento?
¡No! Los autores probaron el sistema y descubrieron que el "peso" de hacer todas estas verificaciones es casi invisible. Es como si tu coche hiciera un chequeo de seguridad cada 15 segundos y solo le costara un 1.3% más de gasolina. ¡Es muy eficiente!

Conclusión

Este paper nos enseña que para confiar en una computadora remota, no podemos confiar en una sola prueba. Necesitamos una cadena de confianza que vaya desde el chip de hardware, pasando por el sistema operativo, hasta las aplicaciones, verificando que nadie ha saltado ningún eslabón.

Incluso proponen dos mejoras para el futuro:

1. Usar tecnologías de computación confidencial (como cámaras de seguridad dentro del chip) para que el sistema operativo no pueda mentir sobre su estado.
2. Mejorar el sistema operativo para que las llaves de seguridad sean aún más difíciles de robar.

En resumen: La confianza no se da, se construye capa por capa.

Resumen técnico

Aquí presento un resumen técnico detallado del artículo "Designing Trustworthy Layered Attestations" (Diseño de Attestaciones en Capas Confiables), estructurado según los puntos solicitados.

1. El Problema

La atención (attestation) es el proceso de proporcionar evidencia de que un sistema remoto es digno de confianza para una interacción sensible. Aunque se utiliza en control de acceso y entornos de ejecución confiables, los sistemas actuales a menudo dependen de "attestaciones superficiales" que solo verifican unos pocos componentes.

• Vulnerabilidades: Un adversario sofisticado puede manipular estas attestaciones superficiales. Por ejemplo, un malware puede obtener privilegios de root, ocultarse de las herramientas de seguridad o secuestrar mecanismos del kernel, engañando a la parte que confía (relying party).
• El Dilema de la Confianza: Para confiar en la evidencia de una attestación, el sistema que la genera debe ser confiable. Si solo se basa en evidencia de tiempo de ejecución, no hay un fundamento sólido. Se necesita una raíz de confianza y una forma de "arrancar" (bootstrap) la confianza desde el hardware hacia el software.
• Complejidad: Combinar mecanismos existentes (como TPM, SELinux, IMA) de manera efectiva es difícil. Algunos son demasiado limitados (solo detectan malware en espacio de usuario), otros son desactualizados (solo miden en el arranque) y otros son frágiles (un solo valor opaco que no permite auditoría granular).

2. Metodología

Los autores proponen un enfoque basado en el razonamiento adversarial y el diseño de attestaciones en capas. En lugar de intentar defender todo el sistema, se estructura para que la confianza dependa de un conjunto limitado de componentes medibles y robustos.

Los 5 Principios (Maxims) de Diseño

El núcleo de la metodología son cinco máximas que guían el diseño de sistemas y sus mecanismos de attestación:

1. Restricción de Interacciones: Las propiedades atestiguadas deben depender solo de partes limitadas, predecibles y medibles del sistema (ej. usando SELinux para aislar procesos).
2. Re-medición en Tiempo de Ejecución: Los servicios de larga duración que manejan entradas no confiables necesitan re-medición de su estado (invariantes). Los procesos de corta vida (que manejan una sola entrada) evitan la necesidad de re-medición constante.
3. Independencia de Secretos Transitorios: La attestación no debe depender de secretos que podrían revelarse por corrupciones transitorias (ej. una clave de firma no debe residir en la memoria del kernel o procesos de usuario).
4. Traza de Origen Confiable: Cada attestación debe demostrar que provino de un software no corrompido ejecutándose bajo un arranque confiable (usando políticas de TPM).
5. Dependencia Acíclica: Las mediciones deben seguir un orden de dependencia acíclico (medir capas inferiores antes que las superiores) para evitar que una corrupción reciente de un componente base invalide la medición de capas superiores.

Caso de Estudio y Variantes

• Caso Principal: Una Solución de Dominio Cruzado (CDS) que filtra y reescribe mensajes entre redes de diferentes niveles de seguridad. Se implementó en Linux con SELinux, IMA (Integrity Measurement Architecture) y LKIM (Linux Kernel Integrity Measurement), utilizando un TPM como raíz de confianza.
• Variante 1: Aplicación de los principios a un sistema de control de documentos distribuido.
• Variante 2: Uso de Computación Confidencial (AMD SEV-SNP) como raíz de confianza de hardware en lugar del TPM, demostrando la adaptabilidad de los principios.

3. Contribuciones Clave

El artículo presenta cinco contribuciones principales:

1. Modelo de Adversario Realista: Definición de un modelo de amenaza avanzado para sistemas Linux con SELinux e IMA, que incluye capacidades de root, modificación de archivos, arranques maliciosos y corrupción temporal del kernel, pero excluye ataques de "arranque rápido" (fast attestation-triggered) y ataques de cadena de suministro al firmware.
2. Evidencia Empírica y Formal: Demostración de que el sistema diseñado gana el "juego de la attestación" defendiéndose de las amenazas o detectando corrupciones exitosas.
3. Las Cinco Máximas: Un conjunto de principios reutilizables que resumen el razonamiento impulsado por el adversario.
4. Validación en Múltiples Contextos: Aplicación exitosa de las mismas máximas en dos variantes del sistema (control de documentos y computación confidencial).
5. Recomendaciones de Arquitectura: Identificación de dos limitaciones en el hardware/software actual y propuestas de mejora:
   • Recomendación 1: Ejecutar LKIM en una máquina virtual separada (hipervisor) para romper el ciclo de dependencia con el kernel.
   • Recomendación 2: Implementar localidades extendidas del TPM en el kernel de Linux y SELinux para controlar estrictamente qué procesos pueden solicitar firmas, eliminando la necesidad de secretos en memoria.

4. Resultados

• Implementación y Evaluación: Se implementó un prototipo funcional de la CDS en Fedora 41.
• Desempeño: La sobrecarga de rendimiento de la attestación es negligible (aprox. 1.3%). La attestación completa del sistema tarda unos 5.48 segundos, de los cuales el 92% corresponde a la medición del kernel (LKIM).
• Pruebas de Seguridad:
  • Se probaron ataques de inyección de módulos del kernel, modificación de políticas SELinux/IMA y reemplazo de binarios de usuario.
  • El sistema detectó todas las corrupciones no reparadas.
  • Se demostró que las claves de firma (ASK) permanecen protegidas incluso si el kernel se corrompe temporalmente, siempre que no se exploten las limitaciones actuales de las "localidades del TPM" (que se proponen corregir).
• Análisis Formal: Se utilizó el lenguaje Copland y herramientas de análisis formal para verificar que, bajo el modelo de adversario definido, no existe una secuencia de acciones que permita al adversario engañar al evaluador sin ser detectado.

5. Significancia

Este trabajo es significativo porque:

• Cambia el Paradigma: Pasa de la idea de "prevenir todo ataque" a la de "detectar y reportar con certeza" mediante una arquitectura de confianza escalonada.
• Practicidad: Demuestra que es posible construir sistemas de attestación robustos utilizando hardware y software estándar (TPM, Linux, SELinux) sin necesidad de soluciones propietarias exóticas.
• Guía de Diseño: Las cinco máximas proporcionan un marco mental claro para ingenieros de seguridad que diseñan sistemas críticos, ayudándoles a identificar puntos débiles y dependencias cíclicas.
• Futuro: Las recomendaciones sobre la virtualización de LKIM y las localidades del TPM ofrecen una hoja de ruta para que las futuras generaciones de sistemas operativos y hardware alcancen niveles de confianza más altos, permitiendo attestaciones confiables incluso contra adversarios más fuertes.

En resumen, el artículo establece que la confianza en sistemas remotos no es binaria, sino que se construye mediante una composición cuidadosa de mecanismos de seguridad en múltiples capas, donde cada capa valida a la siguiente, todo ello guiado por principios de diseño que minimizan la superficie de ataque y maximizan la detectabilidad.