How can I securely wipe an SSD? [duplicate]

Solution 1:

Brief:

A multiple (7) pass overwrite erase does not do what you expect it to do on a SSD. If needed you can implement it and tell the client that you did, but do not expect it to wipe all data.

Background:

To clean data from a conventional harddisk you had the following solutions:

• Wipe the index (e.g. diskpart clean). Easy to recover from.
• Overwrite the whole disk. This wipes it for normal users. If you have access to a very sensitive hardware, the kind only governments have access to, then you may be able to recover some of the data. Think of it as erasing pencil written notes and writing new text. A shadow remains.
• Overwrite the disk several times with varying patterns, defeating even the most capable attackers.

SSDs work differently. They have a number of blocks which are grouped. Writes can only happen to a group. Think of it as a book where you can only write to a page. If you want to add a sentence then the SSD's controller will read the whole page and write a new page (with the extra sentence) to a different location. It will then mark the old page as empty and assign the old page number to the new page.

This means that there is no direct mapping between what the OS sees are sectors (pages) and what is on disk.

You could fill the whole disk with a new file (say one containing only zero's) and the reserve space would not be touched. So there is still recoverable data. You could do this 7 times and still have the same data recoverable.

Good news

The good news is that SSDs often ship with on disk encryption. Throw away the encryption key and the data is worthless.

Even better news is that this data encryption can always be used. Even when you did not explicitly enable encryption. In that case the disk still writes encrypted data with a key stored somewhere on the SSD. Tell it to throw away this key and replace it with a new one and you are done. It is fast and secure.

There is even a command to do this (ATA secure erase).

This is the only correct technical solution. Do it even if they insist on 7 pass overwrites (doing the latter only so you conform to their demands, and the first for the intention of those demands).

Slowness of the bad method

I have no experience with tabernus lan. But almost any SSD will accept over 100MB/sec sustained writes. With that speed, even a very slow SSD should finish within an hour. A medium fast SSD should finish under a fifth of that time.

If you get nowhere near that performance then I suspect that your solution is doing a sector by sector write. That is bad. It should be flushing sectors as fast as it can with a queue depth of 32. Without that you get to the page analogy from above.

Starting with a full page with 8 sentences written.

• Wipe sentence 1.

  • Read whole page.
  • Delete first sentence
  • Write a whole page with 7 sentences to a different block/page

• Wipe sentence 2.

  • Read whole page.
  • Delete 2nd sentence
  • Write a whole page with 6 sentences to a different block/page

• Wipe sentence 3.

  • Read whole page.
  • Delete 3rd sentence
  • Write a whole page with 5 sentences to a different block/page

• Wipe sentence 4.

  • Read whole page.
  • Delete 4th sentence
  • Write a whole page with 5 sentences to a different block/page

• Wipe sentence 5.

  • Read whole page.
  • Delete 5th sentence
  • Write a whole page with 3 sentences to a different block/page

• Wipe sentence 6.

  • Read whole page.
  • Delete 6th sentence
  • Write a whole page with 2 sentences to a different block/page

• Wipe sentence 7.

  • Read whole page.
  • Delete 7th sentence
  • Write a whole page with 1 sentence to a different block/page

• Wipe sentence 8.

  • Mark on page as deleted (but do not actually erase it until you need some more space)

Notice how long that text was? Same thing with SSD speed.

Solution 2:

The software you used is apparently NOT working correctly. One of your screenshots shows 97MB/s as speed. With that speed, 7-pass of full disk overwriting on a 256GB drive should take around 5 hours. Simple calculation.

You might want to try Blancco 5 instead. As you can see, the link that was for Tabernus Erase LAN is redirected to its site. You may also consider the latest DBAN, which appears to be the free version of Blannco.

To be honest, I've never used any pieces of the above software. I doubt that they are really doing a better job than a simple random overwriting.

Personally, I use shred in GNU coreutils:

shred -v -n 7 /dev/sdX

I won't really use -n 7 though. At most I'll leave it to the default: 3-pass, and maybe with an extra single-pass zero-filling at the end (-z).

Or, openssl:

openssl enc -aes-256-ctr -in /dev/zero -out /dev/sdX -pass file:/dev/urandom -nosalt

which you can write a simple bash loop to make it do multiple passes. It does not report progress like shred though.

By the way, according to quite some random sources on the Internet (just Google please), it appears that US DoD has already obsoleted the spec(s) for data sanitizing. Now it seems to only recognize physical destruction.

One of the possible reasons, that is of your concern, is that simple overwriting may not "reach" all the reserved space behind the scene on an SSD for so-called over-provisioning (done in the firmware) and/or bad sectors reallocation. Unfortunately, multiple passes of random data filling is probably the best thing you can do, if your SSD does not support hardware encryption.

Do NOT count on ATA DSM/TRIM if you need the data to be securely wiped. TRIM may OR EVEN MAY NOT make the SSD "look" (i.e. hexdump) fully wiped, but it does not actually destroy data behind the scene like overwriting anyway.

One should NOT really trust ATA Secure Erase¹ either. ACS standards merely requires it to perform (single-pass) pattern filling. Normal mode should have either zeros or ones as the pattern, while the enhanced mode should have a vendor-specific pattern (but it's still pattern filling) and erase also "Reallocated User Data".

However, the feature set has long been abused by vendors to do non-standard stuff³, when ATA SANITIZE DEVICE had not been introduced. So the behaviour of ATA Secure Erase can be TOTALLY vendor-specific, especially on SSD.

On an SSD, ATA Secure Erase is often implemented as the same thing as BLOCK ERASE of ATA SANITIZE DEVICE, which is pretty much an equivalence of full disk ATA TRIM (on an RZAT² SSD).

Fixed pattern filling (which might be incorporated in some implementation of "DOD erase" that doesn't have SSD in mind) is not really worth doing because the "smart" controllers in SSD can do compression and even ignore on such repeated overwriting.

If it is really wanted to be done, for some reason, I suppose OVERWRITE of ATA SANITIZE DEVICE is the best way to use. (Since, hopefully, the vendors will make sure that the controller will not "play smart" when the user issue that to the drive.)

On HDD/SSD that has so-called hardware encryption, the enhanced mode of ATA Secure Erase is often implemented as the same thing as CRYPTO SCRAMBLE of ATA SANITIZE DEVICE, which triggers a regeneration of the encryption key and so. It may be the best "quick" method to use if you want to so-called securely wipe the drive, since that's pretty much the whole point of those non-Opal hardware encryption (while people usually wrongly thought its main point is to work with ATA password).

FWIW, one always need to enable the ATA Security feature set first (i.e. "user password") before erasing, which often bricks the drive due to bad implementation (well, or PEBKAC). If the drive supports ATA SANITIZE DEVICE, it should really be preferred. Unfortunately, unlike ATA Security being supported in hdparm, there seems to be no utility supports the more recent feature set yet. One can at best manually form a SCSI ATA PASS-THROUGH command for that and send it with sg_raw in sg3_utils.

Note:

¹ The standard command name of ATA Secure Erase is SECURITY ERASE UNIT, which is a mandatory command in the ATA Security feature set

² Return zeroes data after trim; see ACS standards for its exact definition

³Specification of Intel 530 SATA SSDs; see "5.3 Security Mode Feature Set"; an example of major vendor "abusing" the ATA Security feature set

Solution 3:

From this archlinux page about SSD memory cell clearing following the ATA secure Erase page it is suggested to

1. Step 1 - Make sure the drive security is not frozen
2. Step 2 - Enable security by setting a user password
3. Step 3 - Issue the ATA Secure Erase command

Some details more

• For the step 1, you can check that the drive is not frozen with

  hdparm -I /dev/sdX
  

  If the command output shows "frozen" one cannot continue to the next step. Some BIOSes block the ATA Secure Erase command by issuing a "SECURITY FREEZE" command to "freeze" the drive before booting an operating system.

• For the step 2, read [1] for the warning relative to Lenovo computers:

  hdparm --user-master u --security-set-pass PasSWorD /dev/sdX security_password="PasSWorD"
  

  and it should answer something like

  /dev/sdX:
  Issuing SECURITY_SET_PASS command, password="PasSWorD", user=user, mode=high
  

  then to check again

  hdparm -I /dev/sdX
  

• For the step 3:

  hdparm --user-master u --security-erase PasSWorD /dev/sdX
  

  It exists the parameter --security-erase-enhanced for the enhanced security erase. It is reported ^[1] that "A short time (like 2 minutes) in turn indicates the device is self-encrypting and its bios function will wipe the internal encryption key instead of overwriting all data cells", meanwhile a longer requested time should indicate a not encrypted device.

  On encrypted devices the same expected time can be reported for the --security-erase and --security-erase-enhanced option. In this case it is supposed that it will be used the same algorithm ^[3]. Note that for the normal HDD the enhanced parameter, among the other differences, should overwrites even sectors which are no longer used because they triggered an I/O error at some point and were remapped. We should assume it will act in the same way for the SSD too, even because the number of this blocks should be not enough big to be reflected in a time difference bigger then a minute. Read more in this answer on Security SE.

  In the example case of the SSD memory cell clearing page, for the Intel X25-M 80GB SSD it is however reported a time of 40 seconds.

  Wait until the command completes. This example output shows it took about 40 seconds for an Intel X25-M 80GB SSD.

Note: after the 3 steps the drive is erased and the drive security should automatically be set to disabled (thus not requiring a password for the access).

Update

From the ATA secure Erase page:

This procedure describes how to use the hdparm command to issue a Secure Erase ATA instruction to a target storage device. When a Secure Erase is issued against a SSD drive all its cells will be marked as empty, restoring it to factory default write performance.

DISCLAIMER: This will erase all your data, and will not be recoverable by even data recovery services.

Solution 4:

Since an SSD doesn't care about how many passes of data you put in it (except it just wears out faster), and data recovery isn't possible after a complete pass (unless you put data in over provisioned space), just writing it completely with 1's will remove all existing data.

The problem you're facing will mostly be in the non-user-accessible storage, such as any overprovisoned space used to do wear-levelling, any caches and possible NVRAM which may hold data identifying a system, OS or something like that.

To securely wipe an SSD, it needs to explicitly support that, and that is currently still controller- and firmware-specific. Using secure erasing software that was designed for magnetic media is pointless here as the way data is securely erased basically has no relation between solid state storage and magnetic storage. With magnetic storage you could theoretically recover previous states of bits, but with flash memory, a bit can't really have a 'previous' state that you could detect. It holds either a 0 or a 1 and not a magnetic pole with varying strength depending on what values it previously held.

I'd just put the PCB in an industrial blender, and then grand the flash chip die into powder. No getting any data off of that. Reselling used SSD's isn't really a thing either since they don't yet have that much of a known lifespan/usage pattern as HDD's have. At best they have a 'wear status' SMART data.

Solution 5:

If this is really important data that should never be recovered, it's not safe to use the disk anymore.

As others have said, overwriting doesn't work on SSDs, and if the manufacturer has got the encryption wrong (cut corners to save money, incompetence etc) then even removing the key won't help.

Effective immediately, DSS will no longer approve overwriting procedures for the sanitization or downgrading (e.g. release to lower level classified information controls) of IS storage devices (e.g., hard drives) used for classified processing.

If you work with confidential data (especially that involving the government) you need something a little more secure. I'd recommend a blowtorch:

Source, CNET