TESORO

TRESOR ( acrónimo recursivo de "TRESOR Runs Encryption Securely Outside RAM", y también la palabra alemana para caja fuerte ) es un parche del kernel de Linux que proporciona cifrado utilizando solo la CPU para defenderse contra ataques de arranque en frío en sistemas informáticos al realizar el cifrado dentro de los registros de la CPU en lugar de la memoria de acceso aleatorio (RAM). Es una de las dos soluciones propuestas para computadoras de propósito general. La otra, llamada "caché congelada", utiliza la caché de la CPU en su lugar. ^{[ 1 ]} Fue desarrollado a partir de su predecesor AESSE , presentado en EuroSec 2010 y presentado en USENIX Security 2011. ^{[ 2 ]} Los autores afirman que permite tratar la RAM como no confiable desde un punto de vista de seguridad sin obstaculizar el sistema.

En seguridad informática , un problema común para la seguridad de los datos es cómo un intruso puede acceder a los datos cifrados en un ordenador. Los algoritmos de cifrado modernos, implementados correctamente y con contraseñas seguras , suelen ser inquebrantables con la tecnología actual, por lo que se ha puesto énfasis en técnicas que sortean este requisito, explotando aspectos de la seguridad de los datos donde el cifrado puede ser "roto" con mucho menos esfuerzo, o incluso eludido por completo.

Un ataque de arranque en frío es uno de los métodos mediante los cuales un intruso puede eludir el cifrado a pesar de la seguridad del sistema, si logra acceder físicamente al equipo en funcionamiento. Se basa en las propiedades físicas de los circuitos de los dispositivos de memoria comúnmente utilizados en las computadoras. El concepto es que, cuando un sistema informático tiene datos cifrados abiertos, las claves de cifrado utilizadas para leer o escribir esos datos se almacenan temporalmente en la memoria física, en formato legible. (Es difícil o imposible evitar que estas claves se almacenen en formato legible durante su uso en los sistemas habituales, ya que el propio sistema debe poder acceder a los datos cuando el usuario autorizado lo solicite). Normalmente, esto no supone ninguna ventaja para un intruso no autorizado, ya que no puede acceder ni utilizar esas claves, por ejemplo, debido a la seguridad integrada en el software o el sistema. Sin embargo, si se puede acceder a los dispositivos de memoria fuera del sistema en funcionamiento sin perder su contenido, por ejemplo, reiniciando rápidamente la computadora o transfiriendo los dispositivos a otro dispositivo, entonces el contenido actual, incluidas las claves de cifrado en uso, puede leerse y utilizarse libremente. Esto puede ser importante si el sistema no se puede utilizar para ver, copiar o acceder a esos datos; por ejemplo, si el sistema está bloqueado, o puede tener sistemas de seguridad u otros controles de intrusión, o si se necesita en un formato inalterado garantizado para fines forenses o probatorios .

Dado que se trata de una propiedad física del hardware en sí, basada en las propiedades físicas de los dispositivos de memoria, no puede ser fácilmente vulnerada mediante técnicas de software, ya que todo el software que se ejecuta en la memoria en el momento de la intervención se vuelve accesible. En consecuencia, cualquier software de cifrado cuyas claves puedan ser accedidas de esta manera es vulnerable a tales ataques. Generalmente, un ataque de arranque en frío implica enfriar los chips de memoria o reiniciar rápidamente el ordenador, aprovechando que los datos no se pierden de inmediato (o no se pierden si se restablece la energía muy rápidamente) y que los datos que se encontraban en el momento de la intervención quedan accesibles para su análisis.

Por lo tanto, los ataques de arranque en frío pueden ser un medio para el robo, la pérdida o el acceso no autorizado a datos. Dichos ataques pueden neutralizarse si las claves de cifrado no son accesibles a nivel de hardware para un intruso (es decir, si los dispositivos en los que se almacenan las claves durante su uso no son vulnerables a los ataques de arranque en frío), pero esto no suele ser lo habitual.

TRESOR es un enfoque de software que busca resolver esta vulnerabilidad almacenando y manipulando las claves de cifrado casi exclusivamente en la CPU , y en registros accesibles únicamente en el anillo 0 (el nivel de privilegio más alto), con la excepción del breve período de cálculo inicial al comienzo de una sesión. Esto garantiza que las claves de cifrado casi nunca estén disponibles para el código del espacio de usuario ni tras un ataque de arranque en frío. TRESOR se implementa como un parche para el kernel que almacena las claves de cifrado en los registros de depuración x86 y utiliza la generación de claves de ronda sobre la marcha , atomicidad y el bloqueo del acceso habitual de ptrace a los registros de depuración para mayor seguridad.

TRESOR fue anticipado por una tesis de Tilo Muller de 2010 que analizaba el problema del ataque de arranque en frío. Concluyó que los procesadores x86 modernos tenían dos áreas de registros donde el cifrado del kernel basado en la CPU era viable: los registros SSE, que de hecho podían convertirse en privilegiados deshabilitando todas las instrucciones SSE (y, por consiguiente, cualquier programa que dependiera de ellas), y los registros de depuración, que eran mucho más pequeños pero no presentaban tales problemas. Dejó que otros examinaran estos últimos y desarrolló una distribución de prueba de concepto llamada Paranoix basada en el método de los registros SSE. ^{[ 3 ]}

Sus desarrolladores afirman que "al ejecutar TRESOR en una CPU de 64 bits que admite AES-NI , no hay penalización de rendimiento en comparación con una implementación genérica de AES " ^{[ 4 ]} y se ejecuta ligeramente más rápido que el cifrado estándar a pesar de la necesidad de recálculo de clave, un resultado que inicialmente también sorprendió a los autores. ^{[ 2 ]}

El artículo de los autores señala lo siguiente:

• Si bien no pueden descartar que los datos de la CPU se filtren a la RAM, no observaron ningún caso en el que esto ocurriera durante las pruebas formales. Se espera que cualquier problema de este tipo pueda solucionarse mediante un parche.
• El acceso de administrador a las claves de cifrado a través del núcleo de un sistema en ejecución es posible utilizando módulos de núcleo cargables o memoria virtual ( /dev/kmem ) y memoria física ( /dev/mem ), si se ha compilado para admitirlos, pero de lo contrario no parece ser accesible de ninguna manera conocida en un sistema en ejecución estándar.
• Estados de suspensión y bajo consumo de energía de ACPI : - en los procesadores reales, los registros se restablecen a cero durante los estados ACPI S3 (suspensión a RAM) y S4 (suspensión a disco), ya que la CPU se apaga para estos estados.
• Ataques de arranque en frío a la CPU: en procesadores reales, los registros se borran a cero tanto en reinicios de hardware como de software (" Ctrl+Alt+Supr "). Sin embargo, los registros de la CPU son vulnerables en máquinas virtuales , ya que se reinician durante los reinicios de hardware simulados, pero no durante los reinicios de software. Los autores consideran que esto es un fallo evidente en muchas implementaciones de máquinas virtuales, pero señalan que los sistemas virtuales serían inherentemente vulnerables incluso si se corrigiera este problema, ya que es probable que todos los registros de una máquina virtual sean accesibles desde el sistema anfitrión.
• TRESOR es resistente a ataques de temporización y ataques basados ​​en caché gracias al diseño de la instrucción AES-NI, donde la CPU admite extensiones del conjunto de instrucciones AES . ^{[ 5 ]} Los procesadores capaces de manejar extensiones AES a partir de 2011 son Intel Westmere y Sandy Bridge (con la excepción de algunos i3) y sus sucesores, AMD Bulldozer y ciertos procesadores VIA PadLock .
• En 2012, un artículo titulado TRESOR-HUNT demostró cómo un ataque DMA podría vulnerar este sistema, inyectando código que funcionaría de forma invisible en el anillo 0 (el nivel de privilegio más alto). Este código eludiría el bloqueo impuesto por TRESOR, permitiéndole leer las claves de los registros de depuración y transferirlas a la memoria habitual. El artículo también propuso métodos para mitigar este tipo de ataques. ^{[ 6 ]}

• Cifrado de disco
• Seguro desde el diseño

• Página principal de TRESOR