43

One of our clients is asking for DOD-7 Pass Erase method for SSD's.

We tried wiping an SSD 256 GB (Samsung Make) via Tabernus lan, but it's taking too much time.

Please guide me how to wipe the SSD from Tabernus lan 7.3.1 version.

enter image description here

13
  • 6
    1 pass should normally be enough if NSA isn't after you. But don't SSDs have some form of the TRIM command that makes data inaccessible without actually deleting it (saving write cycles)? Jul 18, 2016 at 9:00
  • 5
    You should look at Samsung's "Magician" software (a bootable disk that allows you to run the "secure erase" command). Now, whether TRIM or an SSD's "Secure Erase" meet DoD compliance is another thing... I wouldn't know.
    – Kinnectus
    Jul 18, 2016 at 9:29
  • 5
    @PaulStelian - don't forget this is SSD's the OP is talking about - erasing an SSD is a completely different thing to a traditional mechanical HDD.
    – Kinnectus
    Jul 18, 2016 at 9:30
  • 17
    the safest (but more expensive) is to melt it with fire Jul 18, 2016 at 11:46
  • 7
    The DoD doesn't even use that ancient standard anymore. It's utterly irrelevant and destructive if performed on an SSD. Jul 18, 2016 at 20:32

5 Answers 5

64

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.

2
10

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 Erase1 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 stuff3, 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 RZAT2 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:

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

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

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

9
  • 1
    Since SSDs implement so many block movements under the hood for performance, and may be over provisioned (more space than advertised so that it can do the above manipulations), writing data to an SSD can never be assumed to actually remove all data. The vendor reset is the only way to really clear the cells (and it wipes them, and there's no way to recover them). This is unlike hard drives, where there may be magnetic residue that could be read by an attacker (although with data density on modern drives, even a single write is enough these days). Jul 18, 2016 at 13:12
  • 1
    @AlanShutko only if the drive has hardware encryption. Otherwise SANITIZE BLOCK ERASE / ATA Secure Erase would only work like TRIM (or at least, might; so far all the SSDs I've seen have them implemented that way). The caveat of using ATA commands to "securely" erase your drive, is equal to "trust your vendors" on that.
    – Tom Yan
    Jul 18, 2016 at 13:18
  • 2
    It doesn't seems that shred assures that the data is erased on SSD and for each kind of filesystem. From its man CAUTION: Note that shred relies on a very important assumption: that the file system overwrites data in place. Can you please add the references on how shred works (which command sends) when works on a full partition?
    – Hastur
    Jul 18, 2016 at 13:23
  • 1
    @Hastur it's talking about shreding files on a filesystem, not when you shred a partition/disk.
    – Tom Yan
    Jul 18, 2016 at 13:25
  • 1
    "Unfortunately, unlike ATA Security being supported in hdparm, there seems to be no utility supports the more recent feature set yet." As of 2018, hdparm offers --sanitize-block-erase (start block erase operation), --sanitize-crypto-scramble (change the internal encryption keys that used for used data), and --sanitize-overwrite PATTERN (overwrite the internal media with constant PATTERN): sourceforge.net/p/hdparm/feature-requests/19 May 29, 2018 at 7:07
7

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.

13
  • 1
    @TomYan You can read the answer of a serverfault moderator that refers to the same ATA specifications on which is based the answer above. DISCLAIMER: This will erase all your data, and will not be recoverable by even data recovery services.
    – Hastur
    Jul 18, 2016 at 13:14
  • 1
    A secure erase time of two minutes does not indicate that a drive is self-encrypting. Wherever that bit of nonsense came from, it's just plain wrong. The two minutes is the time required to erase all of the drive's blocks. And simply rotating a key on a self-encrypting drive requires less than two seconds. Jul 19, 2016 at 2:30
  • 1
    @MichaelHampton It's a sentence reported from the same archlinux page. I agree about the 2 seconds for the keys, even if two minutes it seems to me a too short time to erase all the blocks even if it is an internal command (max writing speed 70 MB/s *120 sec ~8.4G = 1/10 of 80GB). Moreover in an answer on security SE site they said:_"2 minutes are not enough to overwrite the whole disk, so if that disk implements some actual "secure erase", it must be with the encryption mechanism"_.If you have any reference about it please add, it will be useful.
    – Hastur
    Jul 19, 2016 at 8:17
  • 1
    @Hastur actually it takes shorter than half a minute to do a full device block erase on most 240GB SSD. Truth is, that's already the time consisting of overhead of TRIM commands. If you use Secure Erase or BLOCK ERASE of SANITIZE DEVICE to trigger the erase, it might take only a few seconds or even a blink. 2min is just the mininum value of Secure Erase required time specified in the ACS standards.
    – Tom Yan
    Jul 19, 2016 at 14:46
  • 1
    FWIW, do not consider the ArchWiki as an accurate source of knowledge. Truth is the page can be written / edited by anyone. It's even well-known among many Arch users that there are quite some non-sense and bad/silly ideas on some of the pages from time to time.
    – Tom Yan
    Jul 19, 2016 at 14:50
2

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.

1

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

Not the answer you're looking for? Browse other questions tagged .