I'd like to wipe a stack of drives (spinning and SSD) securely. I'm familiar with the ATA Secure Erase (SE) command via hdparm, but I'm not sure if I should use the Security Erase (SE+) command instead.

There is some evidence that these commands don't work on all drives. How can I ensure the drive is really wiped, including reserve areas, reallocated sectors, and the like?

I'm planning to use a linux live CD (on USB). Ubuntu provides a workable live CD with which I can install hdparm, but is there a smaller live CD distro with updated software versions I should use instead?

So, in summary:

What are the pros and cons of SE versus SE+?

How can I ensure the drive was truly and thoroughly wiped?

Which linux distribution should I use?

  • As a general rule it's best not to include multiple questions in one question. It makes for longer, more complicated answers and is more difficult to look up questions. Just a tip -- I'm not trying to chide you! – Eric Lagergren Jul 2 '14 at 2:08
up vote 25 down vote accepted

As quoted from this page:

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, including sectors that are no longer in use due to reallocation.

This sentence makes sense only for spinning disks, and without encryption. On such a disk, at any time, there is a logical view of the disk as a huge sequence of numbered sectors; the "secure erase" is about overwriting all these sectors (and only these sectors) once, with zeros. The "enhanced secure erase" tries harder:

  • It overwrites data several times with distinct bit patterns, to be sure that the data is thoroughly destroyed (whether this is really needed is subject to debate, but there is a lot of Tradition at work here).

  • It also overwrites sectors which are no longer used because they triggered an I/O error at some point, and were remapped (i.e. one of the spare sectors is used by the disk firmware when the computer reads or writes it).

This is the intent. From the ATA specification point of view, there are two commands, and there is no real way to know how the erasure is implemented, or even whether it is actually implemented. Disks in the wild have been known to take some liberties with the specification at times (e.g. with data caching).

Another method for secure erasure, which is quite more efficient, is encryption:

  • When it is first powered, the disk generates a random symmetric key K and keeps it in some reboot-resistant storage space (say, some EEPROM).
  • Every data read or write will be encrypted symmetrically, using K as key.
  • To implement a "secure erase", the disk just needs to forget K by generating a new one, and overwriting the previous one.

This strategy is applicable to both spinning disks and SSD. In fact, when a SSD implements "secure erase", it MUST use the encryption mechanism, because the "overwrite with zeros" makes a lot less sense, given the behaviour of Flash cells and the heavy remapping / error correcting code layers used in SSD.

When a disk uses encryption, it will make no distinction between "secure erase" and "enhanced secure erase"; it may implement both commands (at the ATA protocol level), but they will yield the same results. Note that, similarly, if a spinning disk claims to implement both modes as well, it may very well map both commands to the same action (hopefully, the "enhanced" one).

As described in this page, the hdparm -I /dev/sdX command will report something like this:

       Master password revision code = 65534
       not     locked
       not     frozen
       not     expired: security count
               supported: enhanced erase
       Security level high

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. On the other hand, if hdparm reports this:


then we can conclude that:

  • This disk performs a full data overwrite (that's the only reason why it would take almost three hours).
  • The "secure erase" and "enhanced secure erase" for that disk are probably identical.

Depending on the disk size and normal performance for bulk I/O (can be measured with hdparm -tT /dev/sdX, one may even infer how many times the data is purportedly overwritten. For instance, if the disk above has size 1 terabyte and offers 100 MB/s write bandwidth, then 168 minutes are enough for a single overwrite, not the three or more passes that "enhanced secure erase" is supposed to entail.

(There is no difference between Linux distributions in that area; they all use the same hdparm utility.)

One must note that the encryption-based secure erase really wipes the data only to the extent of the quality of the encryption and key generation. Disk encryption is not an easy task, since it must be secure and yet support random access. If the firmware simply implements ECB, then identical blocks of plaintext will leak, as is usually illustrated by the penguin picture. Moreover, the key generation may be botched; it is possible that the underlying PRNG is quite weak, and the key would be amenable to exhaustive search.

These "details" are very important for security, and you cannot test for them. Therefore, if you want to be sure about the wiping out of the data, there are only two ways:

  1. The disk manufacturer gives you enough details about what the disk implements, and guarantees the wiping (preferably contractually).

  2. You resort to good old physical destruction. Bring out the heavy duty shredders, the hot furnace and the cauldron of acid !

  • 1
    I'll never get #1 unless I'm a large customer. As an individual I've never even found how any SSDs implement encryption, never mind wiping. – Sophit Aug 1 '14 at 20:13
  • Very good and thorough answer! – jmiserez Aug 1 '14 at 23:20
  • 3
    #1½. You run another layer of proper FDE on top of what protection the drive offers, and determine ahead of time what needs to be done to overwrite all copies of the FDE scheme's keys. (For example, with LUKS, overwriting the first ~10MB of the container will be almost guaranteed to overwrite all copies of the keys, rendering the rest of the container just random data. Once the software FDE keys are gone, you certainly can perform an ATA Secure Erase as well, but even if that is poorly implemented your data should remain reasonably secure if the software FDE is done right. – Michael Kjörling Feb 1 '15 at 0:01
  • 2
    When it pertains to security, I'm suspicious of code (meaning ROMs) I can't compile and burn/install myself. We already know the NSA has intercepted newly purchased routers and installed back doors into them. Why not sabotage a hard drive's built-in encryption also? In fact why not make that standard operating procedure? – user447607 Jan 25 '17 at 16:12
  • 2
    @sherrellbc: That's actually not so unexpected. An SSD uses a "physical-to-logical" mapping. For security reasons, you would want to reset this mapping after a secure erase as well. In particular, you want to reset all logical sectors to a sentinel "no mapping". This would be hardcoded to all zeroes; only on the first write would the SSD create an actual mapping. – MSalters Apr 9 at 12:13

When I looked in to this, I got the impression that ATA secure erase and other features aren't well implemented by all manufacturers yet in terms of actual data deletion/sanitization. ATA security erase on SSD http://arstechnica.com/security/2011/03/ask-ars-how-can-i-safely-erase-the-data-from-my-ssd-drive/

My (limited) understanding is that securely erasing SSDs is still not fully standardized, even for hdparm's secure erase feature. The data isn't necessarily erased, though Polynomial's reply to the previous question indicates the only remaining data would be encrypted. Your best bet might be to contact the vendor and see what they say.

With regard to traditional HDDs, DBAN should suffice, though it won't guarantee all data is truly erased. (see http://www.dban.org/about)

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.