¿Qué tan seguro es un sistema de archivos LUKS encriptado?


34

Recientemente instalé 11.10 en un disco nuevo usando encriptación de disco completo. ¿Alguien puede decirme qué tan seguro es el algoritmo de cifrado? ¿Ha habido infracciones recientes con dicho algoritmo? Utilizo una frase de contraseña aleatoria de 36 caracteres, así que sé que no es un enlace débil. ¿Cuáles son las posibilidades de que los datos de mi cliente puedan verse comprometidos si se roba el disco duro?


Tal vez sea mejor preguntar cuánto tiempo (en promedio) le tomaría a alguien romper esa frase de contraseña. También podría ayudar saber si la persona que lo roba sabría que tiene datos de tarjetas de crédito, por ejemplo. Creo que se puede argumentar que si no se trata de tarjetas de crédito, nadie lo impondrá por la fuerza bruta, sin dinero.
jcollum

11
¿Seguro contra qué? Romper el cifrado con una súper computadora - difícil pero no imposible. Descifrando el código con una llave de $ 10 - más fácil imgs.xkcd.com/comics/security.png
Panther

Aquí le mostramos cómo ver qué cifrado está usando en LUKS: ¿Qué se usa en el cifrado de disco completo 12.10?
gertvdijk

1
@Panther ¿Se requiere realmente una llave de $ 10? Estoy seguro de que hay soluciones más baratas. Requerir una barrera de entrada tan costosa en el criptoanálisis es perjudicial para el campo.
Mateen Ulhaq

Respuestas:


31

Sí, es seguro Ubuntu usa AES-256 para encriptar el volumen del disco y tiene una respuesta de cifrado para ayudar a protegerlo de ataques de frecuencia y otros ataques que apuntan a datos encriptados estáticamente.

Como algoritmo, AES es seguro y esto se ha demostrado mediante pruebas de análisis de criptas. La debilidad en realidad reside en el cifrado y el software para pasarle las claves. Específicamente se encuentra en el almacén de claves (que se almacena en el encabezado del volumen), el almacén de claves está protegido por una frase de contraseña. Las frases de contraseña están, por supuesto, abiertas a algunos ataques, como diccionario / fuerza bruta (si esto fuera exitoso, descifraría el almacén de claves). El uso de contraseñas largas "complejas" que no sean palabras reduciría la posibilidad de que esto ocurra.

La única otra posibilidad de descifrar es usar dispositivos de grabación o ingeniería social para determinar su frase de contraseña.

En resumen, ¡su computadora es razonablemente segura a menos que esté sujeto a un delito cibernético organizado serio o investigación gubernamental!


18
Sin embargo, debe tener en cuenta que si su computadora se toma mientras se ejecuta o en modo de suspensión (la hibernación está bien), existen varias técnicas bastante fáciles de extraer la contraseña de la RAM. Por lo tanto, recomendaría precaución sobre en qué estado deja su computadora portátil mientras viaja, pero en general debe estar a salvo de la mayoría de los escenarios potenciales de pérdida de datos.
ternaryOperator

@ternaryOperator no realmente, esto solo se aplica a las computadoras portátiles. Cuando la computadora pierde energía, los datos de RAM se descomponen bastante rápido hasta que es ilegible (es por eso que no solo usamos RAM en lugar de SSD para un almacenamiento súper rápido, el problema no fue solo la velocidad; varias compañías están tratando de encontrar un sin embargo (memristors)) A menos que al tomarlo quisieras acceder físicamente mientras todavía está encendido.
Cestariano

@Cestarian, sí, quiero decir que incluso si el disco está encriptado, los datos son vulnerables mientras la máquina está encendida (incluso cuando está bloqueada o en modo de suspensión). Entonces, por ejemplo, si deja su computadora encendida o en modo de suspensión durante la noche, o por alguna otra razón, alguien puede acceder a su computadora cuando no está completamente apagada, entonces tendrán una muy buena posibilidad de acceder a sus datos accediendo al contenido de RAM (y se ha demostrado que rociar la RAM con spray de refrigerante reduce significativamente la descomposición de los datos en la RAM, lo que puede permitir que la máquina se reinicie para ejecutar el software de recuperación).
ternaryOperator

@ternaryOperator es una posibilidad remota, para acceder cuando está activado tienen que: A: Iniciar sesión en mi servidor NAS (lo que requiere descifrar uno de los dos posibles 10+ caracteres, y no está en una ubicación muy conveniente para esto ... (pequeña sala de almacenamiento) supongo que podrían intentar usar ssh aunque) B: Espero que puedan secuestrar las claves de cifrado de mi RAM (¿No se eliminan las claves de cifrado de la RAM tan pronto como se han utilizado? Esto básicamente no entonces sucede.) que es el enfoque más plausible pero requiere más experiencia. Como un simple tipo normal, no merezco la pena.
Cestariano

1
@Cestarian Esto funciona mediante la opción B, accediendo a las claves de cifrado desde la RAM. La clave de cifrado se almacena en caché en algún lugar de la RAM, ya que el sistema operativo la necesita cada vez que lee / escribe datos en el disco cifrado. Estoy de acuerdo en que la mayoría de las personas necesitan este nivel de paranoia con respecto al cifrado de disco, y mi interés es principalmente académico, sin embargo, este es uno de los escenarios más prácticos para atacar el cifrado de disco con una contraseña decente y no necesita un equipo especial. Los detalles de estos ataques están cubiertos en este artículo de Wikipedia: en.wikipedia.org/wiki/Cold_boot_attack .
ternaryOperator

7

Aquí hay dos recursos sobre ataques en este tipo de sistema de archivos que parecen ser interesantes: http://dx.eng.uiowa.edu/dave/luks.php http://www.jakoblell.com/blog/2013/12 / 22 / practico-maleabilidad-ataque-contra-cbc-encrypted-luks-partitions /

En resumen, el último documento describe que es posible inyectar una puerta trasera de ejecución remota de código en la configuración LUKS creada por el instalador Ubuntu 12.04. Este ataque solo necesita acceso al disco duro cifrado (no depende de la manipulación de la /bootpartición no cifrada o el BIOS).

Si bien el ataque es bastante malo, no se aplica a las configuraciones modernas de LUCS. El ataque solo se puede aplicar si el modo de bloqueo es CBC, por ejemplo, si aes-cbc-essivse utiliza el cifrado . Las configuraciones modernas usan otros modos de bloque, como el cifrado aes-xts-plain64(consulte este artículo en la wiki de ArchLinux ).

Para verificar qué cifrado utiliza su configuración, ejecute:

sudo cryptsetup status [device]

¿Dónde [device]está tu mapeo /dev/mapper/sda3_crypt?


1
Bienvenido a Ask Ubuntu! Si bien esto puede responder teóricamente la pregunta, sería preferible incluir aquí las partes esenciales de la respuesta y proporcionar el enlace para referencia.
guntbert

Estoy bastante preocupado por el ataque práctico de maleabilidad, por ejemplo, hay una cadena que se puede encontrar fácilmente en cualquier partición ext4 (perdida + encontrada), la cantidad de cadenas posibles aumenta enormemente si se trata de una partición del sistema, pero es más oscura si el contenido de las unidades es desconocido. No es necesario preocuparse de que la frase de contraseña sea recuperable de la RAM, si su computadora está atrapada en un estado en línea, lo más probable es que sus unidades ya estén en estado descifrado. Por lo tanto, debe asegurarse de que su sistema se pueda apagar con solo presionar un botón en el momento en que se sienta amenazado.
Cestariano

LUKS, no LUCS.
Cees Timmerman

1

He creado un programa de Windows que realizará un ataque de diccionario en los volúmenes de Luks. http://code.google.com/p/luks-volume-cracker/

Es lento por diseño, probando alrededor de 3 teclas por segundo. Otros ataques del diccionario serán igualmente lentos, por lo que, a menos que haya elegido una frase de contraseña fácil, la debilidad no será el algoritmo.

Sin embargo, tenga en cuenta el robo de claves de la memoria y el almacenamiento en caché de archivos.


1
Esto no responde a la pregunta qué tan seguro es . Esta es una respuesta a una pregunta sobre cómo realizo un ataque de diccionario en mi dispositivo LUKS. .
gertvdijk

2
@gertvdijk Creo que esto puede responder la pregunta. "a menos que haya elegido una frase de contraseña fácil, la debilidad no será el algoritmo". El resto podría considerarse una demostración de ese principio. La última oración es sobre el tema también.
Eliah Kagan

1
@EliahKagan No estoy de acuerdo. La pregunta es explícitamente sobre el algoritmo en sí. Simplemente decir "la debilidad no será el algoritmo" no es una respuesta a eso, en mi opinión. No me malinterpreten, todavía tiene puntos válidos y valiosos, pero no para esta pregunta.
gertvdijk

1
@gertvdijk Esta respuesta también mide cuánto tiempo lleva descifrar el algoritmo, con un enlace a una demostración. No digo que esta sea la mejor respuesta, pero creo que está del lado de ser una respuesta (a esta pregunta). Además, qué tan seguro es el algoritmo , en realidad es solo una de varias partes de la pregunta.
Eliah Kagan

1
Creo que esto sirve para demostrar el nivel de posible ataque contra LUKS. 3 intentos por segundo de un diccionario nunca van a descifrar una frase de contraseña semidecente.
Oli

-2

El método de cifrado LUKS es potencialmente inseguro, al menos en la forma en que maneja el proceso de cifrado. Vamos a darle el beneficio de la duda de que los algoritmos son seguros y podemos compararlos con el código de algoritmo que ha sido auditado. Dejando eso de lado, como usuario, no puedes crear una clave que encripte tus datos. Eso es como decirle a alguien, hey, inventaré una contraseña que encripte tu cuenta bancaria, no a ti. Pero, seré tan amable de dejarte inventar una contraseña que encripte mi contraseña. Existe la debilidad de seguridad con LUKS tal como lo veo.

LUKS usa una clave maestra o lo que llaman una clave unificada. Esta clave se genera utilizando los programas 'aleatorio' y 'urandom' instalados en el sistema Linux. Si estos programas se ven comprometidos de alguna manera, su llave maestra se debilita. No importa cuán fuerte sea su contraseña, el método de creación de la Clave maestra crea una vulnerabilidad.

Compare esto con TrueCrypt, que misteriosamente se apagó durante las mayores filtraciones contra el espionaje estadounidense. Los volúmenes TrueCrypt que se han cifrado correctamente de acuerdo con la documentación de TrueCrypts no se han dividido. El gobierno arrojó todo el dinero de los contribuyentes a los volúmenes de TrueCrypt y no pudo romperlos. Este es un registro legal. https://en.wikipedia.org/wiki/TrueCrypt#Legal_cases (TrueCrypt es la cuarta enmienda aprobada)

TrueCrypt permite al usuario crear la clave maestra. Durante la creación del volumen, TrueCrypt permite al usuario mover el mouse en la interfaz de TrueCrypt durante el tiempo que desee, lo que manipula al azar el valor de la clave maestra que se está creando. Eso pone el poder del caos en la mano del usuario donde pertenece. LUKS no permite esta característica programática fácil.


44
ADVERTENCIA: El uso de TrueCrypt no es seguro, ya que puede contener problemas de seguridad no corregidos. Ahora, aparte de eso, LUKS admite frases de contraseña definidas por el usuario <= 512 y archivos de clave <= 8MiB de datos binarios arbitrarios. En segundo lugar, los dispositivos aleatorios de Linux pueden verse comprometidos si el sistema (es decir, la cuenta raíz) está comprometido. TrueCrypt no tiene un escudo mágico para este escenario. Por último, el kernel de Linux recopila automáticamente su entropía para (u) al azar de muchos dispositivos, incluido el mouse. En pocas palabras
Adrian Günter

1
No entiendes cómo funciona la generación de claves. TrueCrypt (al igual que sus sucesores) utiliza el mismo proceso que LUKS para generar la clave maestra: recopilar la entropía por diversos medios, incluidos los movimientos del mouse, alimentarla en un generador de números pseudoaleatorios y usar la salida de dicho PRNG como clave maestra. La diferencia es que TrueCrypt usa su propio algoritmo para generar la clave en lugar del sistema RNG. Es probable que el algoritmo de TrueCrypt sea tan defectuoso como el RNG proporcionado por el sistema operativo. Esta respuesta es FUD, y es peligrosa para usuarios desinformados. LUKS es seguro.
Elzo
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.