TRESOR ( acrónimo recursivo de "TRESOR Runs Encryption Securely Outside RAM", y también la palabra francesa para un tesoro) es un parche del kernel de Linux que proporciona cifrado basado solo en CPU para defenderse de los ataques de arranque en frío en sistemas informáticos al realizar un cifrado fuera del azar habitual. -memoria de acceso (RAM). Es una de las dos soluciones propuestas para computadoras de uso general (la otra usa caché de CPU para el mismo propósito [1] ), fue desarrollada a partir de su predecesora AESSE , presentada en EuroSec 2010 y presentada en USENIX Security 2011. [2] Los autores afirman que permite que la RAM sea tratada como no confiable desde el punto de vista de la seguridad sin obstaculizar el sistema.
Un artículo de 2012 llamado TRESOR-HUNT mostró cómo un ataque DMA puede romper este sistema, al inyectar código que funcionaría de manera invisible en el anillo 0 (el nivel de privilegio más alto), lo que le permitiría leer las claves y transferirlas a la memoria habitual. El documento también propuso formas de mitigar tales ataques. [3]
Motivación
En la 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 una computadora. Los algoritmos de cifrado modernos, implementados correctamente y con contraseñas seguras , a menudo son irrompibles con la tecnología actual, por lo que el énfasis se ha trasladado a técnicas que eluden este requisito, explotando aspectos de la seguridad de los datos donde el cifrado se puede "romper" con mucho menos esfuerzo, o bien omitido 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 ejecución. 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 encriptados abiertos, las claves de encriptación que se usan para leer o escribir esos datos generalmente se almacenan de manera temporal en la memoria física, de forma sencilla y legible. (Mantener estas teclas en forma "simple" durante el uso es difícil o imposible de evitar con los sistemas habituales, ya que el propio sistema debe poder acceder a los datos cuando así lo indique el usuario autorizado). Por lo general, esto no supone ningún beneficio para un intruso no autorizado, ya que no puede acceder ni utilizar 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 ejecución 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 puede leer claramente. y usado. 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, o 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 esta es una propiedad física del hardware en sí, y se basa en las propiedades físicas de los dispositivos de memoria, no se puede derrotar fácilmente mediante 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 a cuyas claves se pueda acceder de esta manera es vulnerable a tales ataques. Por lo general, un ataque de arranque en frío implica enfriar los chips de memoria o reiniciar rápidamente la computadora, y explotar el hecho de que los datos no se pierden de inmediato (o no se pierden si se restablece la energía muy rápidamente) y los datos que se conservaron en el punto de intervención se dejarán accesible para examen.
Por lo tanto, los ataques de arranque en frío pueden ser un medio de robo, pérdida o acceso de datos no autorizados. 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 están en uso no son susceptibles de ataques de arranque en frío, pero este no es el caso habitual.
El enfoque de TRESOR
TRESOR es un enfoque de software que busca resolver esta inseguridad almacenando y manipulando claves de cifrado casi exclusivamente en la CPU solamente, y en registros accesibles en el anillo 0 (el nivel de privilegio más alto) solamente; la excepción es el breve período de cálculo inicial en el inicio de una sesión. Esto garantiza que las claves de cifrado casi nunca estén disponibles a través del espacio del usuario o después de un ataque de arranque en frío. TRESOR está escrito como un parche del kernel que almacena las claves de cifrado en los registros de depuración x86 y utiliza la generación de claves redondas sobre la marcha , la atomicidad y el bloqueo del acceso ptrace habitual a los registros de depuración por motivos de seguridad.
TRESOR fue presagiado por una tesis de 2010 de Tilo Muller que analizó el problema del ataque de arranque en frío. Llegó a la conclusión de que los procesadores x86 modernos tenían dos áreas de registro donde el cifrado del núcleo basado en CPU era realista: los registros SSE que, de hecho, podrían convertirse en privilegiados desactivando 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 tales problemas. Dejó este último para que otros lo examinaran y desarrolló una distribución de prueba de concepto llamada paranoix basada en el método de registro SSE. [4]
Sus desarrolladores afirman que "al ejecutar TRESOR en una CPU de 64 bits que admita AES-NI , no hay ninguna penalización en el rendimiento en comparación con una implementación genérica de AES ", [5] y se ejecuta un poco más rápido que el cifrado estándar a pesar de la necesidad de recalcular la clave, un resultado que inicialmente sorprendió también a los autores. [2]
Posibles vulnerabilidades
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 que esto sucediera durante las pruebas formales. Se espera que cualquier caso de este tipo sea reparable.
- El acceso root a las claves de cifrado a través del kernel de un sistema en ejecución es posible utilizando módulos de kernel cargables o memoria virtual ( / dev / kmem ) y memoria física ( / dev / mem ), si se compila para admitirlos, pero por lo demás parece no ser accesible de ninguna manera conocida en un sistema en ejecución estándar.
- Estados de reposo y bajo consumo de ACPI : - en procesadores reales, los registros se restablecen a cero durante los estados de ACPI S3 (suspender en ram) y S4 (suspender en disco) ya que la CPU se apaga para estos.
- Ataques de arranque en frío en la CPU: - en 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 actualmente vulnerables en las máquinas virtuales , ya que se restablecen durante los restablecimientos de hardware simulados, pero no durante los restablecimientos de software. Los autores consideran que esto es un defecto aparente en muchas implementaciones de máquinas virtuales, pero observan 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 tiempo y ataques basados en caché por diseño de la instrucción AES-NI , donde la CPU admite extensiones de conjuntos de instrucciones AES . [6] Los procesadores capaces de manejar extensiones AES a partir de 2011 son Intel Westmere y Sandy Bridge (algunos i3 exceptuados) y 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 manera invisible en el anillo 0 (el nivel de privilegio más alto), evitando el "bloqueo" impuesto por TRESOR, que le permitiría leer las claves de los registros de depuración y transferirlas a la memoria habitual. El documento también propuso formas de mitigar tales ataques. [3]
Ver también
- Cifrado de disco
- Ataque de arranque en frío
- La seguridad informática
- Seguro por diseño
- Kernel de Linux
Referencias y notas
- ^ El otro se ha denominado caché congelado ; los dos son similares en el uso de almacenamiento de claves de cifrado basado en CPU, pero difieren en que la caché congelada usa la caché de la CPU para este propósito en lugar de los registros de la CPU. Erik Tews (diciembre de 2010). "Crypto Talk at 27C3: FrozenCache - Mitigación de los ataques de arranque en frío para el software Full-Disk-Encryption, día 3, 23:00, Saal 2" . 27º Congreso de Comunicación del Caos .
- ^ a b Müller, Tilo; Freiling, Felix C .; Dewald, Andreas (2011). "TRESOR ejecuta el cifrado de forma segura fuera de la RAM" (PDF) . Preimpresión .
- ^ a b Blass, Erik-Oliver; Robertson, William. "TRESOR-HUNT: Atacando el cifrado vinculado a la CPU" (PDF) . ACSAC 2012 .
- ^ Müller, Tilo (mayo de 2010). "Implementación de AES resistente al arranque en frío en el kernel de Linux" (PDF) . Tesis .
- ^ "TRESOR ejecuta el cifrado de forma segura fuera de la RAM" .
- ^ Los autores citan a Intel : Shay Gueron, Informe técnico sobre el conjunto de instrucciones de Intel Advanced Encryption Standard (AES), Rev. 3.0: "Más allá de mejorar el rendimiento, las instrucciones AES brindan importantes beneficios de seguridad. Al ejecutarse en un tiempo independiente de los datos y sin usar tablas, ayudan a eliminar los principales ataques basados en el tiempo y en la caché que amenazan las implementaciones de software basadas en tablas de AES ".
enlaces externos
- Página de inicio de TRESOR