What is the difference between ATA Secure Erase and Security Erase? How can I ensure they worked?
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 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/sdXcommand will report something like this:
Security: Master password revision code = 65534 supported enabled not locked not frozen not expired: security count supported: enhanced erase Security level high 2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
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
168min for SECURITY ERASE UNIT. 168min for ENHANCED SECURITY ERASE UNIT.
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
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:
The disk manufacturer gives you enough details about what the disk implements, and guarantees the wiping (preferably contractually).
You resort to good old physical destruction. Bring out the heavy duty shredders, the hot furnace and the cauldron of acid !
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.
I need to RMA a 1TB Seagate SSHD which is reporting SMART errors after only 127 hours powered on! Unfortunately, it's reporting 100 mins for both secure erase and enhanced secure erase. So... writing to the disk surface then. And NOT doing multiple passes for the enhanced version. Unfortunately, as Sophit says, #1 is not an option for consumers, and, in this case, option #2 is not an option as I don't expect the retailer will want a pile of HDD bits RMAed to them! :-(
#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.
I think I disagree with "2 minutes are not enough to overwrite the whole disk" because my understanding of how SSDs generally implement this is that they send a zero to every block, almost simultaneously. My disk says 2 minutes for SE and 8 minutes for Enhanced SE. I'm guessing the second does the same but for non-zero data?
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?
Interesting note about the quick execution of SE. On my SSD it was shown that both the normal SE and the enhanced version would take 4 min. The actual execution time was about half that. Interestingly, after I requested this operation I observed the contents read back from the SSD _were actually zero_, which was unexpected. I was expecting invalid data to be returned (i.e. unencrypted using the newly generated key, yielding bad data). I suppose the firmware could maintain `last-access` information that would return zero for read requests to regions that were not yet written using the new key.
@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.
I have a drive here where enhanced erase is 2 minutes (actually less than 1 second) and regular erase is 8+ hours. ```more than 508min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.```