¿Cómo limpiar los discos antes del cifrado con dm-crypt si CBC o XTS se usan internamente?

Question

¿Cómo limpiar los discos antes del cifrado con dm-crypt si CBC o XTS se usan internamente?

#1 de sebastian nielsen (0 votos)

2

Primero, perdóneme si publico esta pregunta en la comunidad incorrecta. Siéntase libre de migrar esta publicación a la comunidad correcta si me equivoqué.

Soy bastante nuevo en el cifrado de todo el disco (pero no con el cifrado), especialmente con dm-crypt. Actualmente estoy ejecutando Arch Linux y he leído la documentación dedicada a esa distribución de GNU / Linux. Corríjame si me equivoco al suponer que hago en el siguiente resumen: Quiero comenzar mi conocimiento sobre bases sólidas. ;-)

Allí , los escritores / mantenedores de wiki nos aconsejan que preparemos el disco primero. es decir: eliminar / borrar todo el contenido anterior. Esto es necesario por 2 razones:

(obviamente) evita que los datos antiguos que residen en el disco se recuperen;
lo que es más importante, evita que el disco revele el patrón de uso.

Entendí el segundo punto, ya que: como el cifrado solo cifra los nuevos bloques de datos que escribimos, debemos borrar de forma segura los datos anteriores para evitar mostrarle a un posible atacante los límites del contenedor cifrado. Si hubiésemos escrito ceros en su lugar, los atacantes podrían darse cuenta y pensar así: "¡hey, miren! Aquí vemos basura, y allí, todo está lleno de ceros, sé dónde debo concentrarme en tratar de descifrar los datos".

También la misma documentación de Arch Linux explica el modo de cifrado CBC (Cipher Block Chaining). Según lo que entendí, este método usa sectores físicos y los divide por el tamaño del bloque que usa el algoritmo. Por ejemplo, si tomamos AES que usa un bloque de tamaño de cifrado de 128 bits y tenemos un sector físico de tamaño de 512 octetos (aparte del Formato avanzado), el cálculo para determinar el número de bloques sería 512 * 8 bits = 4096/128 = 32 bloques. Donde se utiliza un bloque del sector para el IV (vector de inicialización). Si se usa CBC con dmcrypt, esto significa que el mismo contenido sin cifrar aparecerá cifrado de manera diferente en dos ubicaciones diferentes en el disco. De esa manera, cuando preparamos el disco para el cifrado, podemos borrar el contenido del disco creando primero un contenedor cifrado y llenándolo con ceros. Si se usa CBC, los ceros aparecerán de manera diferente en el disco en cada ubicación. Si no se usa CBC, necesitamos usar urandom.

Después de algunas preguntas sobre IRC, parece que este es XTS que se usa de forma predeterminada con dm-crypt. De acuerdo con lo que entendí, XTS es solo una variante de CBC que permite dividir un tamaño de sector físico por el tamaño del bloque del algoritmo utilizado independientemente de su tamaño (por ejemplo: si un bloque de 512 sectores no era divisible por el 128 bits del algoritmo AES, XTS permitiría eso).

EDIT : xts no es realmente el valor predeterminado, esto depende de cómo se haya compilado dmcrypt en la distribución GNu / Linux. Para ver qué algoritmos y tamaños de clave se están utilizando, simplemente escriba

$ cryptsetup --help
[...]
Default compiled-in device cipher parameters:
        loop-AES: aes, Key 256 bits
        plain: aes-cbc-essiv:sha256, Key: 256 bits, Password hashing: ripemd160
        LUKS1: aes-xts-plain64, Key: 256 bits, LUKS header hashing: sha256, RNG: /dev/urandom

Por lo tanto, antes de corregir la wiki de Arch Linux, quiero asegurarme de lo que realmente se usa detrás de dm-crypt: CBC o el método de encriptación anther. Debido a que se recomienda aquí nunca usar ceros con dm-crypt, pero esa razón es incorrecta ya que los datos no cifrados aparecen cifrados de manera diferente en dos ubicaciones de disco diferentes. Si no se usa CBC o una variante, tendré que corregir el supuesto descrito en la página wiki "Limpiar el disco de forma segura".

Además, Arno Wagner, el mantenedor oficial de preguntas frecuentes de dmcrypt, describe en el punto 2.19 , que usa ceros directamente en el disco puede tardar mucho tiempo y ese "uso de cryptsetup y un dispositivo dm-crypt simple con una clave aleatoria, es mucho más rápido y le brinda el mismo nivel de seguridad".

Luego agrega el siguiente comando para escribir: cryptsetup open --type plain -d /dev/urandom /dev/<block-device> to_be_wiped , pero aún usa urandom y no ceros. No puedo entender por qué no usa ceros en su lugar y por qué usar urandom en un contenedor sería mucho más rápido que fuera del contenedor, directamente en el disco.

EDIT : Ok, Argo agregó una precisión en sus preguntas frecuentes. -d /dev/urandom solo se usa como una contraseña aleatoria para el cifrado.

También, ya que necesito instalar el cifrado en 3 máquinas diferentes utilizando 3 tipos de dispositivos: un SSD nuevo, un SSD ya usado y un HDD estándar. Como los SSD usan flash, no sé cómo preparar el disco. La pregunta sigue presente con el nuevo SSD, ¿tengo que borrarlo primero con valores aleatorios? ¿Qué pasa con TRIM? ¿Es Linux lo suficientemente inteligente como para darse cuenta de que no tiene que usar TRIM ya que esto está debilitando el cifrado?

La ayuda es muy apreciada.

disk-encryption aes dm-crypt

pregunta wget 23.08.2015 - 18:40

fuente

1 respuesta

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

ssh dns advertencia de suplantación de identidad: ¿posible investigación? verificar el resumen firmado con clave privada usando un programa C

score 0 · Accepted Answer

Siempre que el algoritmo de encriptación sea lo suficientemente fuerte, el uso de un nuevo SSD prístino no debería generar ningún problema de seguridad, ya que cualquier archivo que elimines dentro del contenedor seguirá encriptado en el disco, por lo tanto, aunque algunas partes del archivo permanezcan sin usarse o celdas flash no disponibles, estas partes todavía están encriptadas. Sin embargo, un peligro es si decide cambiar la clave o la contraseña de descifrado. Esto podría hacer que ciertos o todos los datos de su disco aún puedan ser descifrados con la clave / contraseña antigua, posiblemente comprometida.

Por supuesto, cualquier cambio de clave / contraseña se debe hacer haciendo una copia de seguridad segura de los datos, luego borre de forma segura la unidad (no el contenedor). Luego, cree un nuevo contenedor en la unidad con su nueva contraseña, vuelva a mover los datos respaldados. Luego haga un borrado seguro en el medio utilizado para la copia de seguridad. Hecho, el cambio de contraseña se completa.

Cuando se trata de unidades usadas, independientemente de si es SSD o HDD, la pregunta principal es: si contienen o contienen información confidencial del uso anterior. Si la respuesta es no, es suficiente escribir una pasada de ceros para "vaciar" el disco y luego instalar el contenedor. Tenga en cuenta que la mayoría del software de contenedor aún cifrará el espacio libre en el contenedor, por lo que, desde una vista externa, el contenedor seguirá mostrando datos aleatorios incluso en las partes no utilizadas del contenedor.

Sin embargo, si las unidades contenían información confidencial previamente, debe "prepararlas" bien. Los SSD están construidos de tal manera que realmente no se pueden borrar del exterior. Muchos SSD más nuevos, para este propósito, tienen un comando ATA interno llamado "borrado seguro", que realizará un borrado, normalmente borrando una clave de cifrado utilizada para el cifrado de hardware incorporado. Esto hará que cualquier contenido antiguo sea inaccesible. Si la unidad informa que el comando "Borrado seguro" no está disponible o no es compatible, la única forma de deshacerse de los datos de manera segura es enviar la unidad a un centro de eliminación de datos o destruirla usted mismo.

Sin embargo, las unidades de disco duro se pueden borrar de forma segura. Recomendaría el método "DoD Short" dentro del software DBAN (Dariks Boot and Nuke), que escribirá 2 pases de datos pseudoaleatorios y una pasada de ceros (para preparar el disco para su uso posterior) en el disco. También verificará que Todo sea realmente ceros para garantizar que el disco no tenga errores demasiado graves. En ese caso, DBAN generará un error, en tal error, la única manera es enviar el disco duro físico a una instalación de eliminación o destruir la unidad usted mismo.

DoD Short, es suficiente para "datos personales privados". Es posible recuperar la unidad en un laboratorio, utilizando microscopios magnéticos altamente especializados, que pueden leer las diferencias sutiles en el "desgaste" magnético de la célula magnética en cuestión, y así descubrir cuántas veces "uno" (1) y cuántas veces se ha escrito un "cero" (0) en esa celda, y luego usar ecuaciones, cálculos y posibilidades, en combinación con formatos conocidos de archivos y formatos de datos, para recuperar datos parciales o totales. Tenga en cuenta que los datos parciales también pueden ser desagradables, imagine recuperar 100 bits de una clave de 128 bits. Los últimos 28 bits serían bastante fáciles de descifrar.

PERO : dicho trabajo de recuperación cuesta entre diez y miles de dólares. Es por eso que DoD Short es bueno para datos privados personales y "datos no clasificados". Debido a que nadie va a gastar de diez a miles de dólares para MAYOR obtener acceso a su cuenta bancaria con unos pocos tousands o diez tousands de dólares en. El riesgo es demasiado alto y la ganancia es demasiado baja.

Sin embargo, si los datos son MUY sensitivos, digamos que trabajas para militares. Entonces, es posible que algún gobierno quiera gastar diez mil dólares para recuperar su información. Luego, debe usar los esquemas de borrado más largos, como el estándar DoD (7 pases), que borrarán los datos más cerca de lo irrecuperable.