Come cancellare il più possibile un SSD senza ATA Secure Erase?

Non so perché dici che gli SSD implementano impropriamente la cancellazione di sicurezza ATA. I moderni lo implementano usando SED (che utilizza una chiave di crittografia nota all'unità e memorizzata in una memoria non volatile per tutti i tuoi dati, consentendole di cancellare semplicemente la chiave per rendere immediatamente illeggibili i dati), mentre altri contrassegnano tutti i settori per essere TRIMED , che dovrebbe cancellare in modo efficace i dati quando il garbage collector arriva a loro. Sono sicuro che ci sono alcuni là fuori che lo implementano impropriamente (non è particolarmente raro), ma lo stesso vale per i dischi rigidi.

È vero che gli SSD USB esterni e gli HDD hanno spesso problemi con ATA Security Erase, ma ciò è dovuto a problemi con le interfacce USB che non si adattano bene allo standard ATA. Inoltre, le unità flash USB (che non chiamerei quelle "SSD") non implementano ATA Security Erase, grazie al firmware estremamente semplice e ai microcontroller di fascia molto bassa (rispetto agli SSD e HDD, che hanno processori molto potenti, spesso dual core, a volte anche quad). Un SSD è un computer completo collegato a un FTL e una serie di chip flash. Una flash drive è un microcontrollore con memoria flash integrata.

Come per la cancellazione con gli strumenti userspace, nessuno di questi avrà effetto sul DCO, e nessuno di questi influenzerà direttamente lo spazio di overprovisioning. Solo usando ATA Security Erase sarai in grado di cancellare tutto ciò. È progettato per cancellare i settori riallocati (a patto che non siano troppo gravemente danneggiati), così come l'HPA. Il DCO è solo dati di configurazione, quindi non conterrà nulla ora che non contiene quando lo hai ricevuto dal negozio. Se vuoi veramente cancellarlo, puoi ripristinarlo alle impostazioni di fabbrica usando lo strumento hdparm di Linux, che ha un comando per ripristinare il DCO.

Si noti che badblocks -w scrive uno schema prevedibile, e alcuni SSD lo rileveranno e lo comprimeranno, con il risultato di non scrivere effettivamente l'intera cosa sull'unità. Per scopi di distruzione dei dati, questo è quasi inutile. Dovrai scrivere un modello casuale per impedirlo.

Basta usare ATA Security Erase. Se sai per certo che il tuo specifico firmware SSD ha un'implementazione bacata e non puoi aggiornare il firmware per ripararlo, quindi usa hdparm per inviare il comando TRIM a tutti i settori, e usa dd (o un comando simile come ddrescue o dcfldd) per scrivere dati casuali sull'unità e farlo più volte. È necessario farlo più volte non perché esiste un modo per recuperare i dati cancellati, ma perché lo spazio di overprovisioning non può essere scritto in un unico passaggio.

Non sarai in grado di cancellare completamente settori danneggiati. Se l'unità rileva che un settore impiega più tempo del normale per restituire i dati, i dati restituiti non corrispondono al checksum interno, oppure devono riprovare troppo spesso, quindi lo spostano in un settore noto e contrassegnati è così brutto. Farà lo stesso se un settore è stato semplicemente scritto più di un certo numero di volte (dato che falliscono dopo un numero piuttosto prevedibile di cicli di cancellazione, spesso intorno al 2000). L'unità può essere persuasa a contrassegnare manualmente il settore come di nuovo buono per pulirlo o inserirvi dati (quale ATA Security Erase fa e quale hdparm può fare), ma è solo se è stato contrassegnato male mentre stava semplicemente perdendo Salute. Se il settore è stato così gravemente danneggiato che non può restituire nessun dato e scrive stallo indefinitamente / fallisce completamente, allora non c'è nulla che tu o l'unità possiate fare. Il settore è irraggiungibile senza di te (o di un ricercatore forense avanzato) che lo esamina fisicamente. Puoi determinare se ci sono settori danneggiati usando il pacchetto smartmontools:

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

Un esempio, se non puoi usare ATA Security Erase, per cancellare /dev/sda nel modo più sicuro possibile:

# 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

Tuttavia, ti consiglio comunque di utilizzare ATA Security Erase, se possibile:

# 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

E la prossima volta, cripta i tuoi dati!

Risposta breve: la disattivazione dell'HPA e la reimpostazione del DCO mostrano solo i settori riservati in precedenza sull'unità e non comportano alcuna cancellazione sicura. Rende questi settori disponibili al sistema solo per la cancellazione successiva dagli strumenti di sistema.

Update 2:

Now, the remaining thing I need to know is: Does the implementation of DCO and HPA respective erasure and disabling is effective -and not badly done like it is for ATA secure erase- ?

È possibile disabilitare l'HPA (ad esempio impostando la sua dimensione su 0) ed è possibile ripristinare il DCO alle impostazioni di fabbrica. Nessuno di questi comporta la cancellazione. A differenza dell'HPA, il DCO non può contenere informazioni personali (mentre l'HPA potrebbe contenere dati che sono stati cancellati ma non sovrascritti). Il DCO è solo una piccola quantità di dati di configurazione. Se fosse anche possibile cancellarlo completamente, rovineresti la tua guida. Tutto ciò che puoi fare è resettarlo alle impostazioni di fabbrica. Non devi preoccuparti di eliminarlo in modo sicuro, perché non ti è stato scritto nulla dal giorno in cui lo hai acquistato dal negozio.

Esempio di informazioni memorizzate nel DCO, per mostrare quanto poco è effettivamente memorizzato:

# 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

Furthermore, a naive question here: Does disabling the HPA means this latter will get erased too ?

No. Pensa all'HPA come a una partizione nascosta. La configurazione di HPA è come ridimensionare questa partizione di riserva. La disattivazione di HPA sta impostando la dimensione su 0, consentendo al sistema operativo di visualizzare e utilizzare lo spazio che era stato precedentemente riservato. Una volta disattivato (impostato su 0), lo spazio precedentemente inaffidabile può ora essere soggetto alla cancellazione mediante gli strumenti di sistema. Ma l'unico modo per interagire con l'HPA che conta è impostarne le dimensioni.

Si noti che il DCO è anche in grado di nascondere i dati facendo in modo che l'unità si presenti più piccola di quanto non sia in realtà, anche se in modo diverso rispetto all'HPA. Alcuni fornitori ridurranno intenzionalmente le dimensioni attraverso il DCO per creare una dimensione di unità, paralizzarla limitando la dimensione con il DCO e venderla a un prezzo ridotto, vendendo la versione completa (ovvero la versione senza limitazioni DCO) a prezzo pieno Puoi eliminare qualsiasi potenziale limitazione reimpostando il tuo DCO alle impostazioni di fabbrica prima di eseguire qualsiasi cancellazione, anche se fai attenzione che eventuali modifiche di configurazione di basso livello a un'unità comportano dei rischi

Riguardo al tuo commento sulla mia prima risposta (non posso rispondere nei commenti poiché si tratta di un account ospite), la carta che hai collegato sembra parlare di vecchi SSD che implementano impropriamente lo standard ATA Security Erase. Come ho detto, non è particolarmente raro che il firmware sia scritto abbastanza male da non riuscire a implementarlo. Tuttavia, tutte le unità moderne utilizzano il SED, che nega il problema della rimanenza di memoria delle celle flash. Nel complesso, è probabile che un disco moderno sia più affidabile, di gran lunga, rispetto ai blocchi difettosi, per ordine di grandezza.

Un semplice test sarebbe quello di sovrascrivere l'unità con un pattern come 0xdeadbeef, avviare ATA Security Erase (con un'unità abilitata per SED) e verificare che il pattern non si trovi da nessuna parte. Con questo, puoi sapere se è stato implementato correttamente. Se il comando ritorna quasi istantaneamente e il pattern è sparito, è probabile che SED sia stato implementato correttamente.

Supponendo che tu possa impostare la crittografia prima del primo utilizzo (e poi perdere la chiave per effettuare una cancellazione) non importa se elimini tutto. È completamente irrilevante.

Se hai già dati sul dispositivo ma non sono crittografati, è troppo tardi. Come hai sottolineato, gli strumenti disponibili hanno tutti difetti (attraverso il bilanciamento dell'usura, il blocco, ecc.), Quindi se i dati devono essere cancellati in modo sicuro, l'unica opzione affidabile è distruggere fisicamente l'SSD.

Quindi suggerirei un trituratore industriale ( altri metodi di distruzione disponibili )