Because of manufacturers’ inconsistent implementations, the only sure method of secure data deletion without the use of restore hardware/software to double-check the procedure is to physically destroy the drive.
Solid State Drives
Erasing data from SSD -- not so simple
Wiping programs and SSD wear-leveling
SSDs have a feature known as wear-leveling and with this feature, data is sent through a flash translation layer. Instead of writing a set of ones and zeros to location A on the SSD, the flash translation layer would instead redirect those ones and zeros to locations B, C and D. In trying to ensure that no one part of the SSD is worn down quickly by too many writes, wear-leveling prevents the secure overwrite from succeeding and some portions of the SSD remain untouched by the overwrite.
Hence, wiping programs (like DBAN or Eraser) might not be effective. In fact, they can reduce the SSD’s longevity by conducting excessive writes. Wiping programs typically perform only a handful of writes on a drives built to survive 1,000 if not 10,000 writes on each memory cell. The SSD’s firmware could misdirect many such writes to a single spot in the SSD’s chips, prematurely aging that particular spot.
Secure erase tools provided by SSD manufacturers
To achieve a secure wipe, many articles advise using the ATA Secure Erase command. So, the real question is how drive manufacturers have implemented erasures and what they have installed to accomplish the task. Reports from UCSD’s Non-Volatile Systems Laboratory (2010-2011) led to this discouraging conclusion:
Our results show that naively applying techniques designed for sanitizing hard drives on SSDs, such as overwriting and using built-in secure erase commands… is unreliable and sometimes results in all the data remaining intact.
Another approach is to rely on TRIM, a different aspect of SSD firmware. SSDs have a built-in TRIM capability that will promptly and automatically clean out the contents of deleted files, rather than leave recoverable traces of them as in HDDs. With the TRIM function, the operating system notifies the SSD when a file is deleted. This notification is necessary because the SSD does not have its own direct way of sensing when the user or a program tells the operating system to delete a file. Upon receiving that notification, the SSD erases (within its memory cells) those places that contain that file’s data. The erasure takes place shortly (often immediately) after the file is deleted in the operating system. TRIM thus ensures that deleted items are truly and irreversibly deleted, and also keeps the SSD decluttered for best performance. This approach is completely different from an HDD, which marks the space of deleted files as available for overwriting but does not actually overwrite or delete the space until a new file arrives.
Thus SSDs with TRIM, unlike HDDs, should not be full of supposedly deleted files, just waiting to be restored by file recovery software. Instead, if an SSD marked a segment of space as “free space”, the segment should really be empty with no recoverable data in it. There should be no need for a secure erase function on an SSD. Just delete the files, leave the drive connected to a power source and wait for TRIM to do it garbage collection work. According to one forensic article (Bell & Boddington, 2010, p. 11), this takes place “after only a few minutes of sitting idle.” Similarly, if the user deleted all files from the drive, TRIM should then clean the drive, and every space that was cleared should be completely empty, with no magnetic residue or other possible means of recovering supposedly deleted files.
Here, again, it has been reported that manufacturers do not implement the capability consistently or as expected. One writer found thousands of supposedly deleted files still available for recovery via easy-to-use freeware. The persistence of deleted files could be due to a variety of factors, including: drive corruption, non-NTFS formatting, or use of a non-SATA connection. However, those factors do not explain the residue of recoverable files on the tester’s C drive.
Don’t store data you want to protect unencrypted on a Solid State Drive. Encrypt the whole drive from the beginning. This way, even if an attacker could recover data from the SSD, it would be encrypted and unreadable.
If the drive is fully encrypted and there is no worry of the decryption key being used, a simple format will work.
If you need to dispose of an SSD and had at some point stored unencrypted data on it, or if the decryption key may have been compromised, you might choose physical destruction.