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 on, 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 an 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 SSDs.
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:
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 hdparm reports this:
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 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:
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!
