¿Qué tan resistentes son los volúmenes encriptados VeraCrypt y LUKS contra la corrupción de datos?

19

La pregunta ha sido parcialmente respondida, pero aún así no es exactamente lo que estoy buscando. Ver para la actualización 1 abajo bere

Estoy planeando encriptar algunos sistemas de archivos con VeraCrypt y LUKS, pero me temo que si ocurre un solo problema, no podría volver a montar las particiones y perder todos los datos almacenados en ellas. (debido a sectores / bloques dañados, falla de energía durante una operación de escritura, errores del sistema de archivos, etc.)

Además, VeraCrypt puede haber bifurcado las herramientas de reparación de TrueCrypt, pero no cuento con eso y busco más sobre casos reales.

También sé sobre RAID y copias de seguridad / bóvedas, pero no es lo que estoy buscando.

Entonces la pregunta es: ¿Qué tan resistentes son las particiones cifradas con VeraCrypt y LUKS?

Actualización 1 :

Mi pregunta es más sobre la resistencia de la partición cifrada y sus datos, en lugar de guardar la clave maestra, los metadatos o los encabezados. El problema es similar a un archivo 7zip sólido: si un solo bit está dañado en el medio, entonces pierde todo el archivo.

¿Las particiones cifradas serán tan vulnerables? (excluyendo clave maestra, metadatos y encabezados)

PD: Lo siento si no respondo de inmediato, estoy trabajando y viajando por todo el mundo, lo que hace que esta publicación esté relacionada, y a menudo me enfrento a negocios que exprimen el tiempo. Pero definitivamente responderé con seguridad.

X.LINK
fuente

Respuestas:

13

En la práctica, es casi tan resistente con el cifrado como sin él, siempre que haga una copia de seguridad de la clave maestra y los metadatos correctamente.

Además de los metadatos, la corrupción afectaría solo el bloque del bit dañado, en la mayoría de los casos, solo 16 bytes.

Para la mayoría de las situaciones de corrupción de datos, con la clave y las herramientas (como su contraseña y Veracrypt / LUKS), tiene el mismo acceso que un disco no encriptado, tal como lo hace normalmente con el uso diario de un disco encriptado. El cifrado solo agregaría un paso adicional (abrir una partición cifrada) de lo normal. Entonces, en este caso, se comporta igual que los datos no cifrados.

Con Veracrypt o Luks, debe almacenar la clave maestra en el disco, que está cifrada con su contraseña. Dañar este sector (es) causaría la pérdida permanente de datos. Esto se puede resolver fácilmente con la copia de seguridad de la clave maestra (algunos kilobytes de tamaño), algo fácil de hacer con ambos software, y es muy recomendable para todos.

Detalles sobre metadatos no

Tanto Veracrypt como Luks usan XTS hoy. En este modo, se calcula una clave para cada bloque. En una simplificación, para cifrar el bloque i, use una clave generada con las claves maestras y el número de bloque. Entonces, el cifrado de un bloque es independiente de otro. Si corrompe alguna información, se restringirá a ese bloque.

En XTS, rompe el bloque en subbloques (generalmente de 16 bytes) y crea una clave, y encripta ese subbloque con él. Eso significa que si cambiamos un poco, solo estos 16 bytes se verían afectados.

Como prueba, al cambiar un solo bit en un volumen Luks, cambia 16 bytes del archivo original a galimatías, pero los otros 496 aún permanecen sin cambios. En un archivo 7zip, utiliza un método de flujo, que todos los bytes están encadenados, por lo que un cambio de byte afectaría a todos los restantes, este no es el caso aquí.

Algunos consideran que esto es un problema, ya que puede saber con precisión de 16 bytes cuándo y dónde cambia un texto sin formato, comparando solo los datos cifrados.

Se puede encontrar más información interesante sobre esto en estos enlaces:

/crypto/6185/what-is-a-tweakable-block-cipher

/security/39306/how-secure-is-ubuntus-default-full-disk-encryption

https://en.wikipedia.org/wiki/Disk_encryption_theory

Detalles sobre la llave maestra

LUKS

LUKS tiene algunos sectores al comienzo de la partición (o disco) con metadatos, que almacenan métodos de encriptación, otros parámetros y 8 ranuras de teclas. Para cifrar y descifrar el disco, utiliza una clave maestra , un gran número aleatorio generado al crear un contenedor LUKS. Para almacenarlo, encripta la clave maestra con su contraseña, iterando una función hash criptográfica muchas veces sobre la contraseña y generando una clave específica para esa ranura. Puede tener 8 contraseñas diferentes para el mismo disco, cada una encriptando la clave maestra con una contraseña diferente en una ranura. Cuando cambia la contraseña, es tan simple como cifrar la clave maestra y no cambiar toda la partición.

Entonces, cuando estas ranuras y metadatos están dañados, no puede recuperar la clave maestra que realmente se usa para descifrar, perdiendo todos los datos en el disco. Esta es una manera fácil de destruir rápidamente todos sus datos. Pero si tiene una copia de seguridad del encabezado de volumen, es bastante fácil recuperarlo.

A continuación se muestra una copia de las preguntas frecuentes de LUKS sobre la copia de seguridad extraída de https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequencyAskedQuestions#6-backup-and-data-recovery

6.2 ¿Cómo hago una copia de seguridad de un encabezado LUKS?

Si bien puede copiar el número apropiado de bytes desde el inicio de la partición LUKS, la mejor manera es usar la opción de comando "luksHeaderBackup" de cryptsetup. Esto también protege contra errores cuando se han utilizado parámetros no estándar en la creación de particiones LUKS. Ejemplo:

cryptsetup luksHeaderBackup --header-backup-file <file> <device>

Para restaurar, use el comando inverso, es decir

cryptsetup luksHeaderRestore --header-backup-file <file> <device>

Si no está seguro acerca de la restauración de un encabezado, primero haga una copia de seguridad del actual. También puede probar el archivo de encabezado sin restaurarlo utilizando la opción --header para un encabezado separado como este:

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

Si eso desbloquea tus llaves, eres bueno. No olvide cerrar el dispositivo nuevamente.

En algunas circunstancias (encabezado dañado), esto falla. Luego use los siguientes pasos:

Primero determine el tamaño de la clave maestra:

cryptsetup luksDump <device>

da una línea del formulario

MK bits:        <bits>

con bits iguales a 256 para los valores predeterminados antiguos y 512 para los valores predeterminados nuevos. 256 bits equivale a un tamaño de encabezado total de 1'052'672 Bytes y 512 bits, uno de 2MiB. (Consulte también el Artículo 6.12) Si luksDump falla, asuma 2MiB, pero tenga en cuenta que si restaura eso, también puede restaurar el primer 1M más o menos del sistema de archivos. ¡No cambie el sistema de archivos si no pudo determinar el tamaño del encabezado! Con eso, restaurar una copia de seguridad de encabezado demasiado grande todavía es seguro.

En segundo lugar, volcar el encabezado al archivo. Hay muchas formas de hacerlo, prefiero las siguientes:

head -c 1052672 <device>  >  header_backup.dmp

o

head -c 2M <device>  >  header_backup.dmp

para un encabezado de 2MiB. Verifique el tamaño del archivo de volcado para asegurarse. Para restaurar dicha copia de seguridad, puede probar luksHeaderRestore o hacer una operación más básica

cat header_backup.dmp  >  <device>

Veracrypt

Veracrypt es similar a LUKS. No estoy acostumbrado con él como lo estaba con Truecrypt, pero la idea general se mantiene.

Veracrypt solo tiene una ranura para teclas, por lo que no puede tener más de una contraseña al mismo tiempo. Pero puede tener un volumen oculto: almacena los metadatos al final de la partición (o disco o archivo). El volumen oculto tiene una clave maestra diferente y utilizará el final de la partición como espacio superpuesto. La idea de que debe hacer una copia de seguridad es la misma. Esto se puede hacer con Tools -> Backup Volume Headery Tools -> Restore Volume Header. Con el cifrado del sistema, solía crear un disco de arranque con copia de seguridad de clave que recupera el cargador y las claves de Truecrypt si ocurre algún daño. Se realiza antes de cifrar cualquier cosa, y que yo sepa, Veracrypt continúa haciendo lo mismo.

Para obtener más detalles, consulte este enlace https://veracrypt.codeplex.com/wikipage?title=Program%20Menu

Consideraciones de seguridad sobre las claves de respaldo

Si tiene una contraseña filtrada, por ejemplo, y cambia la contraseña del volumen a una nueva, segura y segura, alguien con acceso a la copia de seguridad aún podría descifrar los archivos con la contraseña anterior. La copia de seguridad es básicamente la clave maestra cifrada con la contraseña (antigua). Entonces, al cambiar las contraseñas, también es necesario hacer una nueva copia de seguridad y destruir las más antiguas. Y destruir datos permanentemente puede ser muy complicado.

Para cada copia de seguridad que tenga con esa contraseña, es una forma posible de descifrar los datos con esa contraseña. Esto se puede usar en Veracrypt, por ejemplo, usando una "Contraseña universal" (como en una corporación), haciendo una copia de seguridad y cambiando por otra contraseña. Entonces el departamento de TI. podría recuperar el acceso a ese volumen incluso si alguien perdió la contraseña (piense como una contraseña maestra, pero no confunda con la clave maestra de antes).

Reflexiones finales (TL; DR)

La probabilidad de dañar el sector específico con la clave maestra es menos probable que una falla completa del disco. Entonces, si estos datos son importantes, debe tener una copia de seguridad de ellos en lugar de solo los encabezados de volumen (Clave maestra).

Y la corrupción de los datos se extendió poco (16 bytes), resultando aceptable para la mayoría de los usos.

Por lo tanto, un bloque defectuoso en el medio de la partición o disco afectaría solo a ese bloque. Y algunos errores de bits en un sector están restringidos a ese sector, y ni siquiera afectarán totalmente a un sector de 512 bytes.

Actualización (23/01/2017): agregue más información basada en los comentarios de OP.

Allan Deamon
fuente
1
Wow, esa fue una respuesta muy extensa e informativa, ¡muchas gracias! Sin embargo, mi pregunta es más sobre la resistencia de la partición cifrada y los datos en sí mismos, en lugar de la clave maestra y los metadatos. El problema es similar a un archivo 7zip sólido: si un solo bit está dañado en el medio, entonces pierde todo el archivo. ¿Las particiones cifradas actuarán igual? (clave maestra y metadatos excluidos)
X.LINK
4

He compilado a continuación información sobre la resistencia de los contenedores VeraCrypt / TrueCrypt.

De la corrupción de datos de Veracrypt :

TC / VC almacena el encabezado del volumen en dos lugares: al inicio y al final del volumen. El que está al inicio es el principal y el que está al final es para respaldo. Este mecanismo suele ser suficiente para permitir el acceso cuando una parte de la unidad está dañada o dañada porque el daño suele ser local. Si el daño se produce tanto en el inicio como en el final de la unidad, es casi seguro que la unidad está muerta.

Tenga en cuenta que en caso de una unidad dañada o dañada, tendrá la misma pérdida de datos que cuando no utiliza el cifrado. Esto significa que incluso si puede montar el volumen, la lectura de datos puede estar dañada. Por lo tanto, siempre piense en la copia de seguridad de datos porque el cifrado no protege contra la corrupción de datos.

De las preguntas frecuentes de VeraCrypt :

¿Qué sucederá cuando una parte de un volumen VeraCrypt se corrompa?

En los datos cifrados, un bit dañado generalmente corrompe todo el bloque de texto cifrado en el que se produjo. El tamaño del bloque de texto cifrado utilizado por VeraCrypt es de 16 bytes (es decir, 128 bits). El modo de operación utilizado por VeraCrypt asegura que si la corrupción de datos ocurre dentro de un bloque, los bloques restantes no se verán afectados.

¿Qué hago cuando el sistema de archivos cifrado en mi volumen VeraCrypt está dañado?

El sistema de archivos dentro de un volumen VeraCrypt puede corromperse de la misma manera que cualquier sistema de archivos sin cifrar normal. Cuando eso suceda, puede usar las herramientas de reparación del sistema de archivos suministradas con su sistema operativo para solucionarlo. En Windows, es la herramienta 'chkdsk'. VeraCrypt proporciona una manera fácil de usar esta herramienta en un volumen VeraCrypt: haga clic con el botón derecho en el volumen montado en la ventana principal de VeraCrypt (en la lista de unidades) y en el menú contextual seleccione 'Reparar sistema de archivos'.

La corrupción de datos pequeños debería tener solo un efecto local y no destruirá todo el contenedor. Sin embargo, desaconsejo encriptar un volumen / partición completo y especialmente la unidad del sistema, ya que la recuperación puede ser más complicada. Realice buenas copias de seguridad, especialmente para el encabezado del volumen. Y recuerde que, al igual que para un disco o carpeta real, la corrupción en los encabezados de disco / archivo puede dificultar la recuperación de datos y puede requerir utilidades avanzadas.

Creo que LUKS no tiene un segundo encabezado en el disco, por lo que debe tener aún más cuidado al mantener una copia de seguridad.

harrymc
fuente
Los he leído pero esto sigue siendo un poco confuso. Además de las recuperaciones realizadas a través de los encabezados de los contenedores y los sistemas de archivos dentro de los contenedores, ¿significa que un sector defectuoso justo en el medio de un contenedor no lo hará completamente muerto e imposible de montar? Como puedo entender bien, ¿un bloque de texto cifrado funciona exactamente como dentro de un archivo 7-zip no sólido / ext3 sin cifrar aún montable que tiene sectores físicos defectuosos?
X.LINK
No puedo hablar por volúmenes cifrados, pero cambiar un solo bit en un texto cifrado cifrará basura para todo el bloque. El tamaño del bloque puede ser 128 bytes o 256 bytes o 4kb. No evitará que el resto del texto cifrado se descifre. No hay forma de que el algoritmo de cifrado sepa que la basura es mala. No hay suma de verificación ni nada (para AES-CBC). Si ese bloque estaba dentro de un archivo de texto, solo se verá como basura en el Bloc de notas. Si era parte de la estructura del directorio, entonces el sistema de archivos se verá confuso y requerirá chkdsk.
Chloe
@ X.LINK: Un bit malo corromperá todo su "sector" de 16 bytes. Dependiendo de dónde esté ubicado ese sector, el resultado puede ser nada si cae en un área no utilizada, o basura en ese lugar en el archivo o, en el peor de los casos, una estructura de directorio incorrecta que requiere el uso de utilidades de recuperación. Esto es muy similar a un disco físico donde tiene sectores no utilizados, datos de archivos y tablas de discos, y su copia de seguridad debe seguir pautas similares.
harrymc
0

Gracias a todas las respuestas proporcionadas por las personas, la respuesta definitiva es 100% completa.

No tengo mucho tiempo en estos días, así que editaré mi "propia" respuesta más tarde. Dado que todas las respuestas que las personas dieron aquí son completamente útiles, esto será solo un resumen de lo que dijeron, además de mis hallazgos también.

De todos modos, aquí está uno de mis hallazgos que desacreditará mucha confusión que conocí, y se refería principalmente a ... qué significa bloque, ya que es un término que se usa de manera excesiva y errónea:

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Además, encontrará una forma "estándar" de hablar sobre las cosas aquí, y evitará la confusión de "bloqueo":

/superuser/1176839/what-are-every-possible-names-of-hard-drives-structure-parts

En términos breves, puede cambiar un bloque cifrado que contiene la palabra "400" para que sea "800". Esto significa que la capa cifrada a nivel de bloque es completamente no sólida, en lugar de creer que "esto actuará como un sistema de archivos normal" (es decir, Preguntas frecuentes de Veracrypt).

Además, debería haber tropezado con ese enlace hace dos meses:

/unix/321488/full-image-of-internal-hdd-drive-dd-dd-rescue-with-truecrypt-bad-sectors/

Como VeraCrypt es una bifurcación de TrueCrypt, ciertamente funcionará igual.

PD:

Cualquier respuesta adicional es bienvenida y se agregará a mi "propia" respuesta.

X.LINK
fuente