Limpieza previa al cifrado, ¿por qué?


25

Quería saber por qué, antes de encriptarse e instalarse en el disco, Kali:

  1. borró todo el disco
  2. llenó el disco con 0s
  3. llenó el disco con 1s
  4. llenó el disco con datos aleatorios
  5. limpiado el disco de nuevo

Sé que Kali no está destinado a ser instalado, pero ese no es el punto aquí.

Entonces, ¿cómo es esto útil antes de instalar, digamos en un disco duro nuevo? Estoy acostumbrado a ver eso en la eliminación de HDD, no en la instalación.


Los pasos 1 a 3 suenan de forma similar a lo que badblockshace para verificar si hay sectores defectuosos, escribir y verificar 0's, 1's, 01's, 10's. Para el cifrado de disco completo, es común recomendar un relleno cero cifrado (para escribir datos cifrados en todas partes) por las razones en la respuesta de frostschultz (+1), pero hacer todo esto antes del cifrado es inusual, después de cifrar y luego ejecutar badblockso mkfs -cclograría lo mismo, además de identificar bloques defectuosos. Tal vez alguien en Kali es un poco paranoico acerca de la memoria flash (USB, SSD) que no siempre escribe el mismo sector en el mismo lugar e intercambia sectores hacia / desde las copias de seguridad
Xen2050

Respuestas:


36

No tiene sentido hacer múltiples pases. Una vez es suficiente.

Llenar una unidad para ser encriptada con datos aleatorios tiene principalmente dos usos:

  • deshacerse de los datos antiguos y sin cifrar
  • hacer que el espacio libre sea indistinguible de los datos cifrados

Por lo general, si cifra, no quiere que nadie vea sus datos. Por lo tanto, es probable que, si tuviera datos antiguos y sin cifrar en esta unidad, también desee deshacerse de ellos. Un SSD podría encargarse de él más fácil y rápidamente blkdiscard. De hecho, Linux mkfsTRIM almacena todos los datos sin siquiera pedirle confirmación, lo que hace imposible cualquier tipo de recuperación de datos. Hay demasiado TRIM en Linux.

El espacio libre es un poco gris. Si no rellena previamente con datos aleatorios, en un disco duro nuevo, los sectores en los que nunca se escribieron serán ceros. En un SSD, si permite descartar / TRIM, el espacio libre también será cero.

Si bien esto no afecta sus datos de ninguna manera (todavía está cifrado), revela cuánto espacio libre / datos reales tiene y dónde se encuentra este espacio libre / datos. Por ejemplo, un hexdump -CSSD recortado y encriptado se verá más o menos así:

# hexdump -C /dev/ssd | grep -C 2 '^\*'
...
--
b3eabff0  dc c9 c7 89 16 ca d3 4f  a3 27 d6 df a0 10 c3 4f  |.......O.'.....O|
b3eac000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f70000  5a 99 44 b5 9c 6b 1e 9c  81 cf 9a 43 b6 23 e9 0f  |Z.D..k.....C.#..|
b3f70010  2c e6 9a 5d 59 9b 46 5f  21 3f 4d 5f 44 5b 0a 6b  |,..]Y.F_!?M_D[.k|
--
b3f70ff0  5f 63 8d e8 c4 10 fd b1  a6 17 b5 7d 4a 57 09 68  |_c.........}JW.h|
b3f71000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
b3f72000  5d 1c 09 dd c9 6b 57 18  db 67 e1 35 81 57 45 8e  |]....kW..g.5.WE.|
b3f72010  0f a8 be 39 ae e5 5f cf  cf e3 8b a7 c1 25 1a a3  |...9.._......%..|
--
...

De esto se puede decir que tengo segmentos de espacio libre en la dirección 0xb3eac000 .. 0xb3f70000, b3f71000 .. b3f72000, ... y la inversa de la que es de segmentos de datos como supuesto 0xb3f70000 .. b3f71000.

¿Qué puedes hacer con eso? Pues nada(*).

(*) es lo que me gustaría decir. Pero la gente se vuelve creativa . Los patrones de espacio libre se pueden usar para derivar el tipo de sistema de archivos que usa (debido a cómo / dónde almacenan los metadatos; si hay espacio libre donde ext4almacenaría una de sus copias de seguridad de metadatos, es muy probable que no ext4, etc.). A veces, incluso revela qué distribución usa (si su instalador de Linux llena el sistema de archivos de manera determinista, los archivos siempre pueden terminar en las mismas direcciones físicas). En ese momento, alguien podría saber dónde se encuentra un archivo de sistema específico y podría modificarlo / dañarlo de alguna manera. (Los instaladores deben aleatorizar la forma en que pueblan los sistemas de archivos para evitar esto).

Sin embargo, tales consideraciones son muy teóricas y de muy bajo riesgo en comparación con la vulnerabilidad de la mayoría de las instalaciones encriptadas debido a otras razones. En la mayoría de las instalaciones listas para usar, es más probable / simple manipular los initramfs, o instalar un keylogger, o explotar el sistema en ejecución, que de alguna manera obtener acceso sin procesar y analizar datos cifrados y esperar lograr algo de esta manera.

Debería preocuparse por estos primero antes de preocuparse por revelar el espacio libre.

Con SSD, es completamente normal habilitar TRIM y, por lo tanto, tener espacio libre revelado en todo momento. Este también es el caso de las soluciones de cifrado que funcionan en una capa de archivo en lugar de en una capa de bloque.

Con HDD, principalmente realiza el borrado aleatorio incluso en un disco nuevo porque puede hacerlo, y no hay razón para no hacerlo, ya que no implica ningún costo (aparte de una configuración inicial) y sin inconvenientes.


1
Recortar no necesariamente borra todo el flash NAND recortado, porque parte de él podría estar en el mismo bloque de borrado que algunos sectores no recortados. (los bloques de borrado son más grandes que los bloques de escritura). Incluso si mkfs recorta una partición completa antes de escribir los nuevos metadatos, los datos de otras particiones (como la partición del sistema EFI) todavía están activos, y el firmware SSD no conoce las particiones.
Peter Cordes

¡Un enlace a en.wikipedia.org/wiki/Trim_(computing) podría ser útil en su respuesta!
Gaurav
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.