Los mejores métodos actuales para prevenir la fuga de datos del SSD

5

Me pregunto cuáles son las mejores prácticas actuales para garantizar la confidencialidad de los datos en una SSD utilizada como unidad de arranque del sistema operativo (bajo Linux). Las consideraciones importantes son:

  1. Garantiza contra la fuga de datos en las condiciones habituales (unidad robada, & c .; la protección de datos en movimiento es, por supuesto, una pregunta aparte)
  2. Permite el borrado de datos completo y seguro a pedido, preferiblemente bajo control de software puro
  3. No interfiere demasiado con el uso normal

El primer paso obvio es usar el cifrado de disco completo, aquí LUKS. Esto satisface más o menos la condición 1 (o debería). También ayuda en gran medida la condición 2, ya que en teoría, si se borra el encabezado, el resto de los datos se hace permanentemente inaccesible. Sin embargo, en un SSD hay algunos problemas potenciales con esto.

Pregunta 1: ¿Cuál es la mejor manera de borrar de forma segura un área específica (el encabezado LUKS) de un SSD? El comando TRIM aparentemente está destinado a esto, pero no estoy seguro de su confiabilidad. En una unidad de disco duro me sentiría bastante confiado si solo sobrescribiera repetidamente los bloques en cuestión, pero aparentemente la nivelación de desgaste puede evitar que esto funcione en el SSD.

Pregunta 2: si no se puede destruir solo el encabezado, ¿qué hay de borrar todo el disco? Intuitivamente, sobrescribir repetidamente todo el disco debería evitar que la nivelación del desgaste sea un problema, ya que eventualmente todos los sectores se sobrescribirían. Sin embargo, esto no parece prudente confiar, dada la posibilidad de, por ejemplo Los sectores aún legibles se marcan como incorrectos y se excluyen de la tabla de mapeo. ¿El comando de borrado seguro ahora es confiable? Hay un estudio de alrededor de 2010 que dice que no estaba disponible en muchos discos; ¿Existen datos más recientes? (Parece que al menos algunos discos ahora usan su propio cifrado interno, e implementan Secure Erase sobrescribiendo las claves que se usan allí. Esto está bien, si realmente funciona, pero los mecanismos de código cerrado y no auditables implementados dentro de la propia unidad no No me llenes de confianza.)

También existe la posibilidad de usar algo como el modo de encabezado separado de LUKS para evitar que los datos clave se almacenen en el SSD. Esto requeriría una configuración no estándar en el sistema, pero nada irrazonablemente difícil. Sin embargo, sí introduce un problema de gallina y huevo para garantizar que el dispositivo con el encabezado sea seguro y pueda borrarse. Si guardo el encabezado en una tarjeta SD o unidad flash por separado, ¿es más fácil borrar esto? ¿Qué otro tipo de dispositivo podría usarse?

    
pregunta Tom Hunt 17.02.2017 - 18:37
fuente

2 respuestas

1

La respuesta breve a su primera pregunta es que si no confía en la implementación de borrado seguro, y su unidad usa nivelación de desgaste, no puede estar satisfecho, todos los datos se eliminan completamente del SSD sin destruirlo físicamente. [1]

Un método para agregar más tranquilidad al borrado seguro sería tratar de borrar lo más posible de antemano. Por ejemplo, sobrescribiendo todo el dispositivo y luego ejecutando el borrado seguro después, como se muestra aquí:

# dd if=/dev/zero of=/dev/X bs=4096
# hdparm --user-master u --security-set-pass <PASS> /dev/X
# time hdparm --user-master u --security-erase <PASS> /dev/X

Donde "X" es su dispositivo, y es una contraseña. Aquí hay guías que pueden proporcionar más detalles sobre la limpieza con dd:

enlace

Y utilizando el borrado seguro:

enlace

El comando dd debería poner a cero todo el almacenamiento que no se mantiene en reserva o en mal estado, y el borrado seguro "debería" obtener todo. La única pregunta que me queda es cómo funciona la nivelación de desgaste: es posible que ejecutar el comando dd en varias ocasiones sobrescriba los bloques que no se escribieron la primera vez, pero esto requeriría un conocimiento sobre la nivelación de desgaste que no tengo. .

Por supuesto, esto borraría todo el dispositivo (como en la segunda pregunta), no solo una sección. Para borrar una sección puede sobrescribir los datos, así como todo el espacio libre en lugar de todo el dispositivo. Esto se puede hacer usando dd, con la salida dirigida a un archivo en lugar de un dispositivo. Debería hacerse como root para asegurar que el espacio reservado para el usuario root también se sobrescriba. Esto agrega la capa del sistema de archivos al procedimiento, por lo que es posible que no se obtenga todo el almacenamiento debido a las restricciones allí.

Si coloca el encabezado en un dispositivo separado, simplemente podría usar un dispositivo que esté dispuesto a destruir físicamente para asegurarse de que el encabezado no sea recuperable. Otra opción es usar un dispositivo seguro (como NitroKey / SmartCard) para almacenar almacenar la clave (o tal vez incluso el encabezado separado), que podría ser lo suficientemente largo como para garantizar que los ataques de fuerza bruta no sean factibles en el dispositivo de almacenamiento. / p>

[1] Si hay alguna manera de confiar en el borrado seguro; p.ej. Por supuesto, haga ingeniería inversa u obtenga información sobre la función de borrado seguro en la unidad, luego ejecutar el borrado seguro lo hará, por supuesto.

    
respondido por el DougC 02.05.2017 - 20:32
fuente
-1

La mayoría de las SSDS son compatibles con Opal. Esta es una característica de encriptación administrada por hardware diseñada para hacer que mucho de lo que usted menciona sea fácil. Busque OpalTool y otra documentación de Opal para conocer los rangos, permisos, borrado seguro, etc.

    
respondido por el Russ 10.07.2017 - 03:41
fuente

Lea otras preguntas en las etiquetas