¿Cómo borrar lo más posible un SSD sin ATA Secure Erase?

No sé por qué dice que los SSD implementan el borrado de seguridad ATA de manera incorrecta. Los modernos lo implementan utilizando SED (que usa una clave de cifrado conocida por el disco y almacenada en una memoria no volátil para todos sus datos, lo que le permite simplemente borrar la clave para hacer que los datos sean ilegibles al instante), mientras que otros marcan todos los sectores para TRIM , que debería borrar efectivamente los datos cuando el recolector de basura llega a ellos. Estoy seguro de que hay algunos por ahí que lo implementan incorrectamente (no es particularmente raro), pero lo mismo se aplica a los discos duros.

Es cierto que los discos USB SSD y HDD externos suelen tener problemas con el borrado de seguridad ATA, pero esto se debe a problemas con las interfaces USB que no funcionan bien con el estándar ATA. Además, las unidades flash USB (no las llamaría "SSD") no implementan el Borrado de Seguridad ATA, debido a que tienen un firmware extremadamente simple y microcontroladores de muy bajo costo (en comparación con los SSD y HDD, que tienen procesadores muy potentes, a menudo doble núcleo, a veces incluso quad). Un SSD es una computadora completa conectada a una FTL y una variedad de chips flash. Una unidad flash es un microcontrolador con memoria flash incorporada.

En cuanto a la eliminación de las herramientas del espacio de usuario, ninguno de ellos afectará al DCO, y ninguno de ellos afectará directamente al espacio de sobreavisión. Solo utilizando ATA Security Erase podrás borrar todo eso. Está diseñado para eliminar sectores reasignados (siempre que no estén demasiado muy dañados), así como el HPA. El DCO es solo datos de configuración, por lo que no contendrá nada ahora que no contuvo cuando lo obtuvo de la tienda. Si realmente desea borrarlo, puede restablecerlo a los valores predeterminados de fábrica utilizando la herramienta hdparm de Linux, que tiene un comando para restaurar el DCO.

Tenga en cuenta que badblocks -w escribe un patrón predecible, y algunos SSD lo detectarán y lo comprimirán, lo que provocará que no se escriba realmente todo el contenido en la unidad. Para fines de destrucción de datos, esto es casi inútil. Deberá escribir un patrón aleatorio para evitar esto.

Simplemente use ATA Security Erase. Si sabe a ciencia cierta que su firmware SSD específico tiene una implementación defectuosa, y no puede actualizar su firmware para repararlo, entonces use hdparm para enviar el comando TRIM a todos los sectores y use dd (o un comando similar como ddrescue o dcfldd) para escribir datos aleatorios en su disco y hacer esto varias veces. Es necesario hacerlo varias veces, no porque haya una manera de recuperar los datos eliminados, sino porque el espacio de sobreaprovisionamiento no se puede escribir en una sola pasada.

No podrá borrar completamente los sectores dañados. Si la unidad detecta que un sector tarda más de lo normal en devolver los datos, los datos que se devuelven no coinciden con la suma de comprobación interna, o si tienen que volver a intentarlo con demasiada frecuencia, se moverán a un sector bien conocido y marcarán tan malo Hará lo mismo si un sector simplemente se ha escrito más de un cierto número de veces (ya que fallan después de un número bastante predecible de ciclos de borrado, a menudo alrededor de 2000). Se puede convencer a la unidad para que marque manualmente el sector como bueno de nuevo con el fin de borrarlo o colocar datos en él (lo que hace el Borrado de seguridad de ATA, y que puede hacer hdparm), pero eso es solo si se marcó como malo mientras solo estaba perdiendo salud. Si el sector se dañó tanto que no puede devolver ningún datos, y las escrituras se detienen indefinidamente / fallan completamente, entonces no hay nada que usted o la unidad puedan hacer. El sector es inalcanzable sin que usted (o un investigador forense avanzado) lo examine físicamente. Puede determinar si hay sectores dañados utilizando el paquete smartmontools:

# find out how many sectors are reallocated, and how many reallocations occurred
smartctl -a /dev/sda | grep -i reallocated

Un ejemplo, si no puede usar ATA Security Erase, para borrar /dev/sda de la forma más segura posible:

# find our max sectors (geometry = 91201/255/63, sectors = 1465149168, start = 0)
hdparm -g /dev/sda

# disable the HPA
hdparm -N p1465149168 /dev/sda

# trim every sector in the drive, from 0 to the max
hdparm --trim-sector-ranges 0:1465149168 /dev/sda

# create a crypt device with a random key, and overwrite it a few times
cryptsetup open -M plain -c aes -d /dev/urandom /dev/sda wipe
for i in {0..6}; do dcfldd bs=256k pattern=0$i of=/dev/mapper/wipe; sync; done
cryptsetup close wipe

# restore DCO to factory defaults (this can mess up the SSD, so do it last)
hdparm --dco-restore /dev/sda

Pero igual te recomendaría que utilices ATA Security Erase en su lugar, si puedes:

# initiate an ATA Security Erase which can't be disabled until it completes
hdparm --security-set-pass NULL /dev/sda
hdparm --security-erase-enhanced NULL /dev/sda

Y la próxima vez, ¡encripta tus datos!

Respuesta corta: deshabilitar el HPA y restablecer el DCO solo muestra los sectores previamente reservados en el disco y no implica ningún borrado seguro. Solo hace que estos sectores estén disponibles para el sistema para su posterior eliminación por las herramientas del sistema.

  

Actualización 2:

     

Ahora, lo que necesito saber es: ¿la implementación del borrado y deshabilitación respectivos de DCO y HPA es efectiva, y no está mal hecha como para el borrado seguro de ATA?

Puede deshabilitar el HPA (es decir, establecer su tamaño en 0) y puede restablecer el DCO a los valores predeterminados de fábrica. Ninguno de estos implica borrado. A diferencia del HPA, el DCO no puede contener información personal (mientras que el HPA puede contener datos que se eliminaron pero no se sobrescribieron). El DCO es solo una pequeña cantidad de datos de configuración. Si incluso fuera posible borrarlo por completo, bloquearías tu disco. Todo lo que puede hacer es restablecerlo a los valores predeterminados de fábrica. No debe preocuparse por eliminarlo de forma segura, ya que no se le habrá escrito nada desde el día en que lo compró en la tienda.

Ejemplo de la información almacenada en el DCO, para mostrar cuán poco realmente almacena:

# hdparm --dco-identify /dev/sda
/dev/sda:
DCO Revision: 0x0001
The following features can be selectively disabled via DCO:
    Transfer modes:
         mdma0 mdma1 mdma2
         udma0 udma1 udma2 udma3 udma4 udma5 udma6(?)
    Real max sectors: 1465149168
    ATA command/feature sets:
         SMART self_test error_log security HPA 48_bit
         (?): selective_test conveyance_test write_read_verify
         (?): WRITE_UNC_EXT
    SATA command/feature sets:
         (?): NCQ SSP

  

Además, una pregunta ingenua aquí: ¿Deshabilitar el HPA significa que este último también se borrará?

No. Piense en el HPA como una partición oculta. Configurar el HPA es similar a redimensionar esta partición de reserva. Deshabilitar el HPA está configurando el tamaño a 0, lo que permite que su sistema operativo ahora vea y use el espacio que antes estaba reservado. Una vez que está deshabilitado (establecido en 0), ese espacio intocable anteriormente puede ahora ser eliminado mediante herramientas del sistema. Pero la única manera de interactuar con el HPA que importa es estableciendo su tamaño.

Tenga en cuenta que el DCO también es capaz de ocultar datos al hacer que la unidad se presente a sí misma como más pequeña de lo que realmente es, aunque de una manera diferente a como lo hace el HPA. Algunos proveedores reducirán intencionalmente el tamaño a través del DCO para hacer un tamaño de unidad, lo paralizarán limitando el tamaño con el DCO y lo venderán a un precio reducido, vendiendo la versión de tamaño completo (es decir, la versión sin limitaciones de DCO) a precio completo Puede eliminar cualquier limitación potencial restableciendo su DCO a los valores predeterminados de fábrica antes de realizar cualquier borrado, aunque tenga en cuenta que cualquier cambio de configuración de bajo nivel en una unidad conlleva riesgos

Con respecto a su comentario sobre mi primera respuesta (no puedo responder en los comentarios ya que esta es una cuenta de invitado), el documento que vinculó parece estar hablando de SSD más antiguos que implementan incorrectamente el estándar de borrado de seguridad de ATA. Como dije, no es particularmente raro que el firmware esté escrito lo suficientemente mal como para fallar en su implementación. Sin embargo, todas las unidades modernas utilizan SED, lo que niega el problema de la remanencia de la memoria de la celda flash. En general, es probable que una unidad moderna sea más confiable, por lejos, que badblocks, por órdenes de magnitud.

Una prueba simple sería sobrescribir la unidad con un patrón como 0xdeadbeef, iniciar el borrado de seguridad ATA (con una unidad habilitada para SED) y verificar que el patrón no se encuentre en ninguna parte. Con esto, puedes saber si se ha implementado correctamente. Si el comando regresa casi instantáneamente y el patrón desaparece, es muy probable que el SED se haya implementado correctamente.

Suponiendo que puede configurar el cifrado antes del primer uso (y luego perder la clave para realizar una limpieza) no importa si borra todo. Es completamente irrelevante.

Si ya tiene datos en el dispositivo pero no está cifrado, entonces es demasiado tarde para eso. Como señaló, todas las herramientas disponibles tienen fallas (a través del balanceo de desgaste, bloqueo, etc.) por lo tanto, si los datos deben borrarse de manera segura, su única opción confiable es destruir físicamente el SSD.

Así que sugiero una trituradora industrial ( hay otros métodos de destrucción disponibles )