Report: Current SSD ‘Secure Erase’ Methods Don’t Work

Last spring, we posted an article that took a look at data recovery on SSDs; essentially, the difficulty of. Thanks to TRIM, once a file is deleted on an SSD, it’s difficult to recover, and in our tests, common recovery applications simply didn’t work. In a recent report, though, techies at the University of California have have found that data is recoverable, and that even “secure erase” programs might not work.

Most of the problem boils down to the fact that the ATA or SCSI drivers used in the OS are unable to keep track of the exact points on NAND flash where data is stored. The OS might think it’s one place, but in fact it might be in another, due to how SSDs shift data around. In a test of twelve different SSD models, only four passed. The others all had data that could in fact be recoverable (save for the lone encrypted drive).

When files are deleted on a per-file basis, the results are even worse, with between 4 – 75% of data remaining recoverable. Yes, that’s after a “secure erase” had been run. It’s clear that since we posted our article, better methods of recovery have evolved, as even TRIM doesn’t solve this problem according to the study.

So what to do if you care about data security? One option is to use an encrypted drive, or at least an encrypted file system (I am not sure if this is possible in Windows… would love a heads-up if it is). Aside from that, we’ll have to wait until proper secure erase tools are released, but that might take a while. It’d be easy (you’d think) to write an application to securely erase an entire drive, but to handle things on a per-file basis… that sounds a lot harder. It might actually be up to the chipset vendors (such as SandForce) to come up with the ideal solutions we’ll need.

The core of the problem is that unlike magnetic media, SSD drives save data to physical pages but erase from logical block addresses (LBAs), a process which is managed through a flash translation layer (FTL). This creates a mismatch between where the ATA or SCSI drivers think the data is and where it physically resides which the drives compensate for by copying data around. It is this copying that leaves insecure traces littered around the drive.