El llenado de un disco duro grande con / dev / urandom antes del cifrado puede ser extremadamente lento (incluso con netcat, varias instancias en paralelo, etc.) y por esta razón, estoy seguro de que muchos usuarios omiten este consejo incluso si es práctica recomendada e insegura para omitir.
En los nuevos kernels de Linux, el dispositivo /dev/urandom usa ChaCha20 para la aleatoriedad, en lugar de una función de mezcla SHA1 más lenta, lo que permite que sea muy, muy rápido. Si no tienes un kernel más nuevo, una solución simple es usar OpenSSL o dm-crypt para crear aleatoriedad.
OpenSSL es el más simple, requiere solo un comando:
openssl aes-128-ctr -nosalt -in /dev/zero -out /dev/sdX -k $(head -c16 /dev/urandom | base64)
Usar dm-crypt es más complejo, pero a menudo puede hacer uso de criptografía acelerada por el kernel más rápida:
cryptsetup open -M plain -c aes-cbc-plain -s 128 -d /dev/urandom /dev/sdX wipeme
cat /dev/zero > /dev/mapper/wipeme
cryptsetup close wipeme
Mi pregunta es: supongamos que un usuario ha omitido este paso de llenar el disco con / dev / urandom, o solo lo ha hecho parcialmente. ¿Se pueden seguir algunos pasos después de que el HDD se haya cifrado para que sea más difícil realizar el criptoanálisis en el disco?
Primero que nada, el problema no es que facilite el criptoanálisis . AES no es tan débil que los simples gigabytes de texto sin formato conocido generan una recuperación de claves. Algunos de los PRNG más potentes generan datos aleatorios al cifrar un flujo nulo con una clave aleatoria. El problema es más bien la fuga de metadatos a nivel del sistema de archivos (saber qué bloques son gratuitos y cuáles no), lo que revela el diseño general de su sistema de archivos. Esto puede filtrar no solo la cantidad de espacio que se ha utilizado, sino también mucha más información, como el tamaño de los archivos, las posiciones, las posibles acciones previas realizadas en los archivos y más. Ha habido casos de arrestos y condenas basadas solo en los metadatos de un archivo cifrado (por ejemplo, tamaños).
Supongo que el mejor escenario para el atacante sería si el usuario llenara todo el disco con / dev / zero y luego lo cifrara. ¿Ayudaría entonces si el usuario llenara todo el disco (después de haberlo cifrado) escribiendo / dev / zero en algún archivo arbitrario en el sistema de archivos, y luego eliminara el archivo para recuperar el espacio 'usado'? ¿No eliminaría esto los bytes nulos perdidos en el dispositivo y reemplazaría todo con datos cifrados?
Eso sería bueno, sí. No es perfecto, porque todavía habrá áreas del sistema de archivos que no se borrarán aunque se rellenen. Por ejemplo, el usuario no root no puede sobrescribir el último 5% del espacio en un sistema de archivos ext4 de forma predeterminada. Y ningún usuario puede sobrescribir ciertos campos de metadatos que pueden no inicializarse cuando se crea el sistema de archivos, y dejarlos como bytes nulos. Tendría que examinar el formato en disco y las técnicas de formato utilizadas por su sistema de archivos en particular para comprender qué campos pueden no estar inicializados y pueden filtrar información confidencial. Como a menudo esta es una tarea tan compleja, generalmente es más fácil comenzar con un dispositivo de bloque aleatorio.
Una publicación muy útil para comprender el problema al dejar algunos datos sin encriptar es aquí . La publicación trata específicamente sobre TRIM en los SSD, pero el efecto es el mismo, como los bloques de ceros de TRIM que se liberan, filtrando información sobre qué bloques son gratuitos y cuáles no. Esto también puede responder a su pregunta sobre cómo se aplica esto a los SSD.