“Shoot Here.”: Does Secure-Erase Work to Protect Sensitive Military Data?
For many military applications, the ability to secure-erase (“zeroize”) flash memory and SSDs is a critical element to protecting classified information such as data, crypto keys, or software programs from falling into enemy hands. But the wide variance among flash drives means that each implementation of security commands must be individually tested before it can be trusted to properly sanitize the drive.
Does Secure Erase Actually Work?
In 2001, a Chinese fighter jet attempting an intercept collided with a US Navy EP-3 SIGINT aircraft. The EP-3 was forced to make an emergency landing on China-controlled Hainan, giving unauthorized access to classified US equipment, data, algorithms, and crypto keys. The Navy crew had 26 minutes to destroy sensitive equipment and data while in the air—using a fire axe, hot coffee, and other methods—plus another 15 minutes on the ground, but their efforts were widely reported to be only partially successful.
While this sounds far-fetched, the topic of sanitizing data is so critical—yet so unresolved—that allegedly some current-generation equipment includes a visible red X indicating exactly where an operator is to aim a bullet as a last-ditch effort to mechanically sanitize equipment.
For many military applications, the ability to “zeroize” flash memory and SSDs is a critical element to protecting classified information such as data, crypto keys, or software programs from falling into enemy hands. Interestingly, however, there doesn’t appear to be a single government specification that clearly spells out the procedure. I uncovered a draft NIST document that includes recommended steps to zerorize flash memory, with options such as:
- Overwrite the data “using organizationally approved and validated overwriting technologies/ methods/ tools” and at least one pass through by writing zeros into all locations.
- Leverage the “non-enhanced” ATA secure-erase feature built into the device, if supported.
- Use the ATA sanitize command via a) block erase and b) cryptographic erase (aka “sanitize crypto scramble”). One can optionally apply the block erase command after the sanitize command.
- Apply ATA secure-erase command, but the built-in (if available) sanitize command is preferred.
- Use the “cryptographic erase through TCG Opal SSC or Enterprise SSC”—which relies on media (drives, including SSDs) that use the FIPS 140-2 self-encrypting feature.
- Shred, disintegrate, pulverize, or incinerate the device. This literally means mechanically destroy the media such that if any 1s and 0s remain on the floating transistor gates, it’s not possible to reconstruct these bits into useful data.
In all of these cases, all procedures except for mechanical eradication rely on mechanisms built into the drive/media by the manufacturer. There is some question if this is as secure as intended and the NSA—America’s gold standard for all things crypto—has only one recommended procedure: strong encryption or mechanical shredding, as specified in “NSA/CSS Storage Device Sanitization Manual.”
From Pulverize to Zeroize
There’s a lot of room between the DoD’s wish to have classified data and programs zeroized and the NSA’s recommendation to pulverize. The middle ground is the NIST spec that relies heavily on flash memory manufacturers’ built-in secure-erase options, which is allegedly based on ATA recommendations of the same name. But research calls into question how well this command works or how well manufacturers are implementing it in their devices.
It is not acceptable to delete or reformat a flash device or SSD because the data remains intact (such as in over-provisioned blocks used for media endurance). The only way to successfully erase is to overwrite all user data in allocated blocks, file tables, and in reallocated defective blocks. Three types of ATA secure-erase (SE) methods were presented at the Flash Memory Summit in 2010 (about the time flash was gaining serious traction).
Type I software-based SE requires a user’s input via keyboard and utilizes a combination of SE command processor, flash bus controller, (ATA) host interface, and the device’s sanitize command. The device’s bad block table is erased, rendering the device (or the entire SSD using the flash components) useless for reuse.
Type II is a hybrid of software and hardware kicked off by an external line such as GPIO, but logic erases the device(s) to allow flash reuse once the drive is reformatted. For defense customers, it’s unclear which method of secure erase is better—the point is to sanitize the data. Reusing the drive, no matter how expensive the drive, is of secondary concern.
Type III SE kicks off via external GPIO but involves a high-voltage generator along with the controller to destroy the NAND flash transistors within seconds. The drive is not useable—ever—after a purge; it’s completely ruined. Note that this kind of erasure isn’t mentioned in the NSA’s “mechanical pulverization” sanitization procedures, and it’s unclear if Type III would meet the NSA’s guidelines for data removal.
These recommended SE procedures for flash made me wonder if the techniques applied to rotating HDDs would also work on SSDs, or if some users might think they are effective at securely sanitizing sensitive data stored on SSDs. After all, if the DoD/NSA recommendations are ambiguous…might users be misapplying them?
Refereed Research: Reliably Erasing SSDs?
An oft-sited refereed paper on the subject of SE appeared in 2011 “Reliably Erasing Data From Flash-Based Solid State Drives,” written by Michael Wei et al. Mr. Wei’s team at UCSD reached three key conclusions:
- Built-in (software) SE commands are effective, but manufacturers sometimes implement them incorrectly.
- Overwriting twice is usually, but not always, sufficient.
- None of the existing HDD techniques for individual file sanitization are effective on SSDs.
Wei and his colleagues investigated the ATA sanitization commands, software techniques to sanitize drives, and common software to securely erase individual files. Researchers dug deeply into the memories using forensic techniques—which is not unlike what a determined adversary might do when trying to extract classified data from a recovered DoD or military SSD.
Wei discovered that trying to sanitize individual files “consistently fail[s]” to remove data. As well, software sanitizing techniques—not built into the drives—are usually successful at the entire drive level, but the overwrite pattern may provide clues to the data or “may impact the effectiveness of overwriting.”
Another key point from Wei and his colleagues is that retrieving non- or poorly-sanitized data from SSDs is “relatively easy,” and can be done using tools and disassembly costing under $1,000 (in 2011). Comparable tools to recover erased files from rotating media HDDs was over $250,000. This points to the need for proper SE on SSDs.
Doing It Wrong…and Write
It seems that the only completely reliable way to erase all data on a flash drive is to mechanically obliterate it, which may not be pragmatic in all situations. After reading piles of data on this topic, my opinion is exactly what Wei recommended in 2011: users with sensitive data wishing to sanitize a drive can rely on the ATA Secure Erase command—as long as it’s correctly implemented. GMS offers this on all of its new products, and also offers an option for a custom hardware-based secure erase with a separate “panic” processor that erases the drive by writing random data over the drive data and continues to do so even if the system is powered off. Additionally, all non-volatile storage in the system is sanitized, including the BIOS.
For customers, we recommend testing the chosen drive(s) to verify that data is actually gone. When you find a vendor that meets your needs, put their drive under Source Control Drawing and Revision Control and stick with your Approved Vendor List. Buying a different drive might leave your data open to anyone’s interpretation.
Chief Technology Officer
General Micro Systems, Inc.