The short answer is:
Perhaps you can’t. Well, you can, but that means that you need to use a hammer.
The long answer:
You could use the build in ATA Secure Erase command (if your drive supports that), or you can overwrite the SSD multiple times, but…
There are studies out there showing that the data could be recovered even after overwriting multiple times.
Note that a data recovery will most likely only be possible by pulling out the flash and accessing it directly. Someone would need to put some effort into this to (maybe) get to (some of) your data.
The ATA Secure Erase command is a feature implemented by the manufacturer of a Solid State Drive.
It pretends to securely erase a SSD in just a few minutes (or less). I say ‘pretend’ as this is not always working like expected. Various scientific papers proofed that this feature is not always implemented the right way and sometimes the data is not even erased.
So you need to trust the vendor in this case, which is a bad idea in general.
Let’s say we trust those guys and use this feature to erase our SSD.
ATA Secure Erase
The drive must be connected via SATA or ESATA, USB won’t work. First we’ll check if ATA Secure Erase is supported by the drive:
hdparm -I /dev/sdx
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
The output should look similar. We see that our drive supports 2 modes:
Secure Erase and Enhanced Secure Ersae. So what is the difference?
And again, it’s the manufacturer who would need to tell us. I asked Kingston and they answered as follows:
Secure erase overwrites all user data areas with binary zeroes. Enhanced secure erase writes predetermined data patterns (set by the manufacturer) to all user data areas.
I guess Secure Erase will do the job.
We also see that our disk in not frozen, which is good. What do we do if it’s frozen?
There is a simple solution which worked for my SSD’s. We send our system to sleep and wake it up again. This will remove the frozen status from the disk.
echo -n mem > /sys/power/state
Now we use hdparm
again to check if the drive is unfrozen:
hdparm -I /dev/sdx
Once the drive is not frozen, we can start the Secure Erase procedure.
Activating security (we can replace PASS with whatever we like):
hdparm --user-master u --security-set-pass PASS /dev/sdx
hdparm --user-master u --security-erase PASS /dev/sdx
The output will look like this and we have to wait a while:
security_password="PASS"
/dev/sdx:
Issuing SECURITY_ERASE command, password="PASS", user=user
That was quick, what? Our drive should be erased. You don’t trust the vendor? Nor do I.
Overwriting the drive
Multiple overwriting would be another option if we want to keep the drive.
Let’s check if there is any HPA (Host Protected Area).
This is a protected area which will not be erased if we overwrite the whole disk.
Checking for HPA:
hdparm -N /dev/sdx
We will see something like the following if HPA is disabled:
/dev/sda:
max sectors = 1565152896/1565152896, HPA is disabled
On the right side we have the real hardware sector limit of the disk, on the left side we see the value set for the HPA. Here, the numbers are the same which indicates that HPA is disabled.
So what do we do if its enabled?
We change the value to the real maximum sector count. hdparm
will do that for us.
hdparm –N 1565152896 /dev/sdx
Note that this is not permanent and will be restored after boot. Use hdparm –N p1565152896
if you want to make that permanent.
Now we could run a dd if=/dev/zero of=/dev/sdx
to write zeros to the entire drive.
Conclusion
Don’t store important data unencrypted on a SSD. Disable the HPA and encrypt the whole drive from the beginning. If a data recovery would be successful, it would at least only show the encrypted data.
If you stored data unencrypted, you might go for the hammer.
It’s definitely NOT a good idea to overwrite a SSD with zeros. Controller firmware implementation is often ‘intelligent’ enough to detect full-zero data blocks and will not write the zeros, but simply mark the block as ‘all zero’ in order to reduce the number of write accesses and therefore increase disk lifespan.
I could verify this with a Corsair SSD I own, gaining full SATA interface speed even ‘writing’ gigabytes of zeros! Also, this disk does not actually read zero blocks, but simply detects the ‘all zero’ flag and hammers out zeros at the interface.
So, if you try to overwrite an SSD, always use numbers apart from zero, not necessarily random.
Anyway, overwriting is not the solution.
For the vast majority of use cases, secure erase is “good enough” – you’re trying to ensure that a drive is unreadable for all but the most determined attackers once it is out of your control.
Always bear in mind that a determined enough attacker or organisation will probably try to obtain data via other means (subversion of the running system) or may simply resort to rubber hose cryptography. ( https://xkcd.com/538/)
Any SSD manufacturer whose products accept an ATA standard “SECURITY ERASE UNIT” or “ENHANCED SECURITY ERASE UNIT” command and does not completely erase all previously written data should be fined by the Federal Trade Commission for deceptive adversising, and if supported by the products’ drive controllers, the manufacturer should be forced to provide firmware updates in order to enable full secure erasure of their products.
Blanking all physical data sectors does not just ensure the data is destroyed, but also places the drive into a state where it can be re-used at “factory fresh” write performance, as the drive will not have to erase any blocks while they are re-written for the first time.
The DISCARD command can also mark LBAs as unused without the inconvenience of erasing all data. eg: fstrim(8)
Instead of “dd if=/dev/zero of=/dev/sdX” I suggest “cat /dev/zero of=/dev/sdX”. Simply because it’s faster: it does not do “read block from /dev/zero, write block to /dev/sdX, read block from /dev/zero, write block to /dev/sdX”, but insteads streams /dev/zero and leaves the block size determination to the OS. Thus you gain much more speed.
dd performs reasonably well if you set a larger block size, eg: `-bs=64m`
There seems to be a broad misconception regarding the “SECURITY ERASE UNIT” or “ENHANCED SECURITY ERASE UNIT” method of wiping an SSD. It seems to stem from the fact that this process is extremely quick, even on large 1TB+ drives.
Most (all?) SSDs are encrypted by design. This encryption isn’t to safeguard your data in the traditional sense. The sole purpose of the encryption is to allow for a secure erase of all data by simply deleting the encryption key – and leaving behind the encrypted data. This is why it is so fast!
The encryption key is stored in a specific place on the drive that ensures “delete” means “delete”.
While it wouldn’t surprise me, I can’t see why/how any drive manufacturer would implement this incorrectly. This is why I always encrypt my data myself – then I don’t have to worry about the drive if stolen or I’m done with it.
Ok, please tell me. Once you encrypt your ssd and then erase and encrypt with other passwords. And the end can you decrypt ssd.?????
It is not possible to answer this question without even knowing what encryption you are using.
Assuming you used good encryption and did it the right way, recovering the data will be close to impossible at this point in time.
If you have any concerns or doubts, destroy the SSD an get a new one.
I agree with you, given the low cost of many SSD’s (other than 2TB+ sizes), if one feels insecure about the end result of secure erase, then a hammer to smash all chips will do the job.
These are easily disassembled for the job, can smash each into bits & if still a bit queasy, flush each smashed NAND module down toilet. Once removed from PCB, are very small. No need to worry over data thieves.
On the other hand, I’ve purchased a few MLC SSD’s which were secure erased & could not find any files using Recuva ‘deep scan’ option. Nor was able to recreate partition structure using the Pro version of bootable MiniTool Power Data Wizard (Linux based media). Have also used the Samsung utility to perform secure erase and again was not able to recover data nor partitions. Haven’t tried the Intel version, so can’t speak on how well it does.
Some says to use a few quick formats to the entire drive (this won’t reach ‘spare’ cells) will secure erase a SSD beyond the typical consumer ability to recover data. It’s like this, if a government or other source wants data on a given person (be it a suspected crime investigation or financially well off), the targeted will have to do a lot more than wiping a SSD. The targeted person will have to be behind a strong VPN with kill switch protection at boot, plus install a extension in browser to prevent WebRTC leaks.
The everyday Home user is not likely to be targeted, therefore the standard secure erase tools should do the job. If TRIM & GC are working as should, then cells which has been used & now aren’t gets a natural wipe anyway. I leave my computers on in a locked state for 24 hours per month to get best effect from this. Some will say to boot into BIOS for this, however TRIM is controlled by OS & if logged in then lock for an extended period of time, this will delete a lot of data in itself.
Do you have any update? From my recent research, the “sanitize” command came out and that seems to be better but it’s still not standardized or certified by any standards org. See https://nvmexpress.org/wp-content/uploads/Session-3-Verifying-SSD-Sanitization_Micron_Toshiba_Final-as-of-4.26.pdf.