Linux, TRESOR y XTS

Question

Linux, TRESOR y XTS

#1 de forest (2 votos)

24

Quiero cambiar de usar LUKS para el cifrado completo del disco a TRESOR . TRESOR intenta prevenir los ataques de arranque en frío almacenando la clave de cifrado en los registros de la CPU. Utiliza la API criptográfica del kernel para cosas como obtener IVs y usar un modo como XTS. Sin embargo, la clave real se solicita una vez que el núcleo arranca y las claves pasadas al cifrado a través de la API criptográfica más tarde se ignoran.

Cuando se usa el modo XTS, la clave generalmente se divide en dos mitades y una se usa como la clave real y la otra para generar IV. Pero dado que TRESOR ignora todas las claves, el núcleo termina usando dos claves AES idénticas. De lo que puedo reunir de esta pregunta y los documentos vinculados allí, XTS es vulnerable a un ataque de texto cifrado cuando se usa de esa manera.

¿Puede esto convertirse en un problema en la práctica? ¿Y qué modos de operación puedo usar en su lugar? Al mirar el código, parece que cbc-essiv también necesita proporcionar su propia clave.

encryption linux disk-encryption dm-crypt

pregunta twisted_pear 13.10.2014 - 00:12

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption linux disk-encryption dm-crypt

Acceso a la base de código en grandes compañías [duplicado] ¿Por qué hay pocas bibliotecas de cifrado fáciles de usar (ninguna)?

score 2 · Answer 1

Es probable que esto se convierta en un problema, si simplemente intenta utilizar tresor-xts-plain o tresor-xts-plain64. Si bien no lo he probado exhaustivamente, incluso cuando probé TRESOR incluso con cbc-essiv, resultó en un sistema que no funcionaba. Sólo funcionó cbc-plain, que utiliza una sola clave. La forma en que yo personalmente uso TRESOR es con tresor-cbc-plain encadenado con serpent-xts-plain64. Supongo que si alguien realiza un ataque de arranque en frío contra mí y logra obtener la clave de la serpiente, no podrá realizar ataques de maleabilidad contra la llanura de Cbc, porque los ataques de arranque en frío no son particularmente sigilosos. Si bien hay otras debilidades con cbc, la confidencialidad generalmente se mantiene.

Sin embargo, puede haber soluciones. Hay un parche para el hipervisor BitVisor, llamado TreVisor que puede usar TRESOR con las teclas XTS. No he leído el parche extensivamente. Tal vez mirando la función tresor_xts_crypt() podría proporcionar alguna idea. Su página principal es aquí , en el centro.

También hay RamCrypt , que utiliza TRESOR para cifrar la memoria. Páginas de procesos individuales. Utiliza el modo de operación XEX, que es similar a XTS (también utiliza claves de ajuste, pero la clave de ajuste es la misma que la clave de datos). La función ramcrypt_page_crypt() puede ser un buen punto de partida. Su página principal es aquí .

TreVisor, al menos, tiene una solución inteligente para este problema. Como el modo XTS requiere una clave adicional, la clave de ajuste, TreVisor simplemente usa una clave de la mitad del tamaño (128 bits en lugar de 256) para el cifrado, y utiliza los 128 bits gratuitos para almacenar la clave de ajuste. Creo que RamCrypt hace algo similar. Vea las macros read_key_0 y read_key_1 , y el argumento up para las macros encrypt_block y decrypt_block en el parche TreVisor.