TESORO

This article may rely excessively on sources too closely associated with the subject, potentially preventing the article from being verifiable and neutral. Please help improve it by replacing them with more appropriate citations to reliable, independent, third-party sources. (July 2014) (Learn how and when to remove this message)

TRESOR ( acrónimo recursivo de "TRESOR ejecuta cifrado de forma segura fuera de la RAM", y también la palabra alemana para una 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 el caché de la CPU en su lugar. ^[1] Se desarrolló a partir de su predecesor AESSE, presentado en EuroSec 2010 y presentado en USENIX Security 2011. ^[2] Los autores afirman que permite que la RAM sea tratada como no confiable desde un punto de vista de seguridad sin obstaculizar el sistema.

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (September 2012) (Learn how and when to remove this message)

En el ámbito de la seguridad informática , un problema habitual en materia de seguridad de datos es cómo un intruso puede acceder a los datos cifrados de un ordenador. Los algoritmos de cifrado modernos, correctamente implementados y con contraseñas seguras , suelen ser indescifrables con la tecnología actual, por lo que se ha hecho hincapié en técnicas que evitan este requisito, aprovechando aspectos de la seguridad de los datos en los que el cifrado se puede "descifrar" con mucho menos esfuerzo o, en su defecto, eludir por completo.

Un ataque de arranque en frío es uno de esos medios por los cuales un intruso puede vencer el cifrado a pesar de la seguridad del sistema, si puede obtener acceso físico a la máquina en funcionamiento. Se basa en las propiedades físicas de los circuitos dentro de los dispositivos de memoria que se utilizan comúnmente 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 generalmente se almacenan de forma temporal en la memoria física, en un formato legible simple. (Mantener estas claves en forma "simple" durante el uso es difícil o imposible de evitar con los sistemas habituales, ya que el sistema mismo debe poder acceder a los datos cuando se lo indique el usuario autorizado). Por lo general, esto no es beneficioso para un intruso no autorizado, porque no puede acceder ni usar esas claves, por ejemplo, debido a la seguridad incorporada en el software o el sistema. Sin embargo, si se puede acceder a los dispositivos de memoria fuera del sistema en funcionamiento sin pérdida de contenido, por ejemplo, reiniciando rápidamente la computadora o quitando los dispositivos a un dispositivo diferente, entonces el contenido actual, incluidas las claves de cifrado en uso, se pueden leer y usar claramente. Esto puede ser importante si el sistema no se puede usar para ver, copiar o acceder a esos datos; por ejemplo, el sistema está bloqueado, puede tener trampas explosivas u otros controles de intrusión, o se necesita en una forma intacta garantizada para fines forenses o probatorios .

Dado que se trata de una propiedad física del propio hardware y que se basa en las propiedades físicas de los dispositivos de memoria, no se puede vencer fácilmente con técnicas de software puro, ya que todo el software que se ejecuta en la memoria en el punto de intervención se vuelve accesible. Como resultado, cualquier software de cifrado cuyas claves puedan accederse de esta manera es vulnerable a este tipo de ataques. Por lo general, un ataque de arranque en frío implica enfriar los chips de memoria o reiniciar rápidamente el equipo y aprovechar el hecho de que los datos no se pierden inmediatamente (o no se pierden si se restablece la energía muy rápidamente) y los datos que se conservaban en el punto de intervención quedarán accesibles para su examen.

Por lo tanto, los ataques de arranque en frío pueden ser un medio de robo, pérdida o acceso no autorizado a los datos. Dichos ataques pueden anularse si las claves de cifrado no son accesibles a nivel de hardware para un intruso (es decir, los dispositivos en los que se almacenan las claves cuando se utilizan no son susceptibles de ataques de arranque en frío), pero este no es el caso habitual.

TRESOR es un enfoque de software que busca resolver esta inseguridad mediante el almacenamiento y la manipulación de claves de cifrado casi exclusivamente en la CPU y en registros accesibles solo 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 o después de un ataque de arranque en frío. TRESOR está escrito como un parche para el núcleo que almacena claves de cifrado en los registros de depuración x86 y utiliza generación de claves sobre la marcha , atomicidad y bloqueo del acceso habitual de ptrace a los registros de depuración para la seguridad.

TRESOR fue anticipado por una tesis de 2010 de Tilo Muller que analizaba el problema de los ataques de arranque en frío. Concluyó que los procesadores x86 modernos tenían dos áreas de registro donde el cifrado del núcleo basado en la CPU era realista: los registros SSE que, en efecto, podrían volverse privilegiados al deshabilitar todas las instrucciones SSE (y necesariamente, cualquier programa que dependa de ellas), y los registros de depuración que eran mucho más pequeños pero no tenían esos problemas. Dejó que otros los examinaran y desarrolló una distribución de prueba de concepto llamada Paranoix basada en el método de registro SSE. ^[3]

Sus desarrolladores afirman que "al ejecutar TRESOR en una CPU de 64 bits que soporta AES-NI , no hay ninguna penalización de rendimiento comparado 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]

This section is in list format but may read better as prose. You can help by converting this section, if appropriate. Editing help is available. (April 2022)

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

• Aunque no pueden descartar que los datos de la CPU se filtren a la RAM, no pudieron observar ningún caso en el que esto sucediera durante las pruebas formales. Se espera que cualquier caso de este tipo pueda solucionarse.
• El acceso de root a las claves de cifrado a través del núcleo de un sistema en ejecución es posible usando módulos de núcleo cargables o memoria virtual ( /dev/kmem ) y memoria física ( /dev/mem ), si se compila para soportarlos, pero de lo contrario parece no 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 S3 (suspensión a RAM) y S4 (suspensión a disco) de ACPI, ya que la CPU se apaga para estos.
• Ataques de arranque en frío en la CPU: - en los procesadores reales, los registros se borran a cero tanto en los reinicios de hardware como en los reinicios de software (" Ctrl-Alt-Delete "). Sin embargo, los registros de la CPU son vulnerables actualmente en las 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 defecto aparente en muchas implementaciones de máquinas virtuales, pero señalan que los sistemas virtuales serían inherentemente vulnerables incluso si esto se rectificara, ya que es probable que todos los registros de una máquina virtual sean accesibles mediante el sistema host.
• TRESOR es resistente a ataques de temporización y ataques basados ​​en caché por 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 (excepto algunos i3) y sus sucesores, AMD Bulldozer y ciertos procesadores VIA PadLock .
• En 2012, un artículo llamado TRESOR-HUNT mostró cómo un ataque DMA podría romper este sistema, inyectando código que funcionaría de forma invisible en el anillo 0 (el nivel de privilegio más alto), eludiendo el "bloqueo" impuesto por TRESOR, lo que le permitiría leer las claves de los registros de depuración y transferirlas a la memoria habitual. El artículo también propuso formas de mitigar este tipo de ataques. ^[6]

• Cifrado de disco
• Seguro por diseño

• Página de inicio de TRESOR