WIXLIB

1614Number of copiesof flash memory. Because of the mismatch in granularity between erase operations and program operations inflash, in-place update of the sector at an LBA is not possible.Instead, to modify a sector, the FTL will write the newcontents for the sector to another location and update themap so that the new data appears at the target LBA. As aresult, the old version of the data remains in digital formin the flash memory. We refer to these “left over” data asdigital remnants.Since in-place updates are not possible in SSDs, theoverwrite-based erasure techniques that work well forhard drives may not work properly for SSDs. Thosetechniques assume that overwriting a portion of the LBAspace results in overwriting the same physical media thatstored the original data. Overwriting data on an SSD results in logical sanitization (i.e., the data is not retrievablevia the SATA or SCSI interface) but not digital sanitization.Analog sanitization is more complex for SSDs than forhard drives as well. Gutmann [20, 19] examines the problem of data remnants in flash, DRAM, SRAM, and EEPROM, and recently, so-called “cold boot” attacks [21] recovered data from powered-down DRAM devices. Theanalysis in these papers suggests that verifying analogsanitization in memories is challenging because there aremany mechanisms that can imprint remnant data on thedevices.The simplest of these is that the voltage level on anerased flash cell’s floating gate may vary depending onthe value it held before the erase command. Multi-levelcell devices (MLC), which store more than one bit perfloating gate, already provide stringent control the voltage in an erased cell, and our conversations with industry[1] suggest that a single erasure may be sufficient. Fordevices that store a single bit per cell (SLC) a single erasure may not suffice. We do not address analog erasurefurther in this work.The quantity of digital remnant data in an SSD can bequite large. The SSDs we tested contain between 6 and25% more physical flash storage than they advertise astheir logical capacity. Figure 1 demonstrates the existence of the remnants in an SSD. We created 1000 smallfiles on an SSD, dismantled the drive, and searched forthe files’ contents. The SSD contained up to 16 stalecopies of some of the files. The FTL created the copiesduring garbage collection and out-of-place updates.Complicating matters further, many drives encryptdata and some appear to compress data as well to improve write performance: one of our drives rumored touse compression is 25% faster for writes of highly compressible data than incompressible data. This adds anadditional level of complexity not present in hard drives.Unless the drive is encrypted, recovering remnant data12108642002004006008001000File numberFigure 1: Multiple copies This graph shows The FTLduplicating files up to 16 times. The graph exhibits aspiking pattern which is probably due to the page-levelmanagement by the FTL.Figure 2: Ming the Merciless Our custom FPGA-basedflash testing hardware provides direct access to flashchips without interference from an FTL.from the flash is not difficult. Figure 2 shows the FPGAbased hardware we built to extract remnants. It cost 1000 to build, but a simpler, microcontroller-based version would cost as little as 200, and would require onlya moderate amount of technical skill to construct.These differences between hard drives and SSDs potentially lead to a dangerous disconnect between userexpectations and the drive’s actual behavior: An SSD’sowner might apply a hard drive-centric sanitization technique under the misguided belief that it will render thedata essentially irrecoverable. In truth, data may remainon the drive and require only moderate sophistication toextract. The next section quantifies this risk by applyingcommonly-used hard drive-oriented techniques to SSDsand attempting to recover the “deleted” data.

88-byte fingerprint512-Byte ATA SectorFingerprint 0(88 bytes)Fingerprint 1(88 bytes)Fingerprint 2(88 bytes)Fingerprint 3(88 bytes)Fingerprint 4Padding(88 bytes)(72 bytes)“Magic” Header (8 bytes)Generation #(8 bytes)LBA(8 bytes)Iteration #(8 bytes)Checksum(4 bytes)GUID(8 bytes)Bit Pattern(44 bytes)Figure 3: Fingerprint structure The easily-identifiedfingerprint simplifies the task of identifying and reconstructing remnant data.3Existing techniquesThis section describes our procedure for testing sanitization techniques and then uses it to determine how wellhard drive sanitization techniques work for SSDs. Weconsider both sanitizing an entire drive at once and selectively sanitizing individual files. Then we briefly discuss our findings in relation to government standards forsanitizing flash media.3.1Validation methodologyOur method for verifying digital sanitization operationsuses the lowest-level digital interface to the data in anSSD: the pins of the individual flash chips.To verify a sanitization operation, we write an identifiable data pattern called a fingerprint (Figure 3) to theSSD and then apply the sanitization technique under test.The fingerprint makes it easy to identify remnant digital data on the flash chips. It includes a sequence number that is unique across all fingerprints, byte patterns tohelp in identifying and reassembling fingerprints, and achecksum. It also includes an identifier that we use toidentify different sets of fingerprints. For instance, allthe fingerprints written as part of one overwrite pass orto a particular file will have the same identifier. Eachfingerprint is 88 bytes long and repeats fives times in a512-byte ATA sector.Once we have applied the fingerprint and sanitized thedrive, we dismantle it. We use the flash testing systemin Figure 2 to extract raw data from its flash chips. Thetesting system uses an FPGA running a Linux softwarestack to provide direct access to the flash chips.Finally, we assemble the fingerprints and analyze themto determine if the sanitization was successful. SSDsvary in how they spread and store data across flash chips:some interleave bytes between chips (e.g., odd bytes onone chip and even bytes on another) and others invertdata before writing. The fingerprint’s regularity makesit easy to identify and reassemble them, despite thesecomplications. Counting the number of fingerprints thatremain and categorizing them by their IDs allows us toSSD#ABCDEFGHIJ?K?L?Ctlr #& -TLC10-MLC11-MLCSECURITYSEC. ERASEERASE UNITUNIT ENHNot SupportedFailed sSuccessNot SupportedNot SupportedNot SupportedNot SupportedNot SupportedNot SupportedNot ot SupportedNot SupportedNot Supported Drive reported success but all data remained on drive†Sanitization only successful under certain conditions‡Drive encrypted, unable to verify if keys were deleted?USB mass storage device does not support ATA security [30]Table 1: Built-in ATA sanitize commands Support forbuilt-in ATA security commands varied among drives,and three of the drives tested did not properly executea sanitize command it reported to support.measure the sanitization’s effectiveness.3.2Whole-drive sanitizationWe evaluate three different techniques for sanitizing anentire SSD: issuing a built-in sanitize command, repeatedly writing over the drive using normal IO operations,and degaussing the drive. Then we briefly discuss leveraging encryption to sanitize SSDs.3.2.1Built-in sanitize commandsMost modern drives have built-in sanitize commands thatinstruct on-board firmware to run a sanitization protocol on the drive. Since the manufacturer has full knowledge of the drive’s design, these techniques should bevery reliable. However, implementing these commandsis optional in the drive specification standards. For instance, removable USB drives do not support them asthey are not supported under the USB Mass Storage Device class [30].The ATA security command set specifies an “ERASEUNIT” command that erases all user-accessible areas onthe drive by writing all binary zeros or ones [3]. There isalso an enhanced “ERASE UNIT ENH” command thatwrites a vendor-defined pattern (presumably because thevendor knows the best pattern to eliminate analog remnants). The new ACS-2 specification [4], which is stillin draft at the time of this writing, specifies a “BLOCKERASE” command that is part of its SANITIZE featureset. It instructs a drive to perform a block erase on allmemory blocks containing user data even if they are notuser-accessible.

We collected 12 different SSDs and determined if theysupported the security and sanitize feature sets. If theSSD supported the command, we verified effectivenessby writing a fingerprint to the entire drive several timesand then issuing the command. Overwriting severaltimes fills as much of the over-provision area as possible with fingerprint data.Support and implementation of the built in commandsvaried across vendors and firmware revisions (Table 1).Of the 12 drives we tested, none supported the ACS-2“SANITIZE BLOCK ERASE” command. This is notsurprising, since the standard is not yet final. Eight of thedrives reported that they supported the ATA SECURITYfeature set. One of these encrypts data, so we could notverify if the sanitization was successful. Of the remaining seven, only four executed the “ERASE UNIT” command reliably.Drive B’s behavior is the most disturbing: it reportedthat sanitization was successful, but all the data remainedintact. In fact, the filesystem was still mountable. Twomore drives suffered a bug that prevented the ERASEUNIT command from working unless the drive firmwarewas recently reset, otherwise the command would onlyerase the first LBA. However, they accurately reportedthat the command failed.The wide variance among the drives leads us to conclude that each implementation of the security commands must be individually tested before it can be trustedto properly sanitize the drive.In addition to the standard commands, several drivemanufacturers also provide special utilities that issuenon-standard erasure commands. We did not test thesecommands, but we expect that results would be similarto those for the ATA commands: most would work correctly but some may be buggy. Regardless, we feel thesenon-standard commands are of limited use: the typicaluser may not know which model of SSD they own, letalone have the wherewithal to download specialized utilities for them. In addition, the usefulness of the utilitydepends on the manufacture keeping it up-to-date andavailable online. Standardized commands should workcorrectly almost indefinitely.3.2.2Overwrite techniquesThe second sanitization method is to use normal IO commands to overwrite each logical block address on thedrive. Repeated software overwrite is at the heart ofmany disk sanitization standards [11, 26, 9, 13, 17, 10]and tools [23, 8, 16, 5]. All of the standards and toolswe have examined use a similar approach: They sequentially overwrite the entire drive with between 1 and 35 bitpatterns. The US Air Force System Instruction 5020 [2]is typical: It first fills the drive with binary zeros, thenbinary ones, and finally an arbitrary character. The dataSSDInit:ABCDFJKLSeq. 20 PassSeq.Rand. 20N/A 1N/A 22222121 hr.?270 hr.?2140 hr.?258 hr.?Rand. 20 PassSeq.Rand.N/A N/A N/A N/A 22N/A N/A 121 hr.?121 hr.?70 hr.?70 hr.?140 hr.?140 hr.?58 hr.?58 hr.? Insufficient drives to perform test? Test took too long to perform, time for single pass indicated.Table 2: Whole-disk software overwrite. The numberin each column indicates the number of passes needed toerase data on the drive. Drives G through I encrypt, sowe could not conclude anything about the success of thetechniques.is then read back to confirm that only the character ispresent.The varied bit patterns aim to switch as many of thephysical bits on the drive as possible and, therefore, makeit more difficult to recover the data via analog means.Bit patterns are potentially important for SSDs as well,but for different reasons. Since some SSDs compressdata before storing, they will write fewer bits to the flashif the data is highly compressible. This suggests thatfor maximum effectiveness, SSD overwrite proceduresshould use random data. However, only one of the driveswe tested (Drive G) appeared to use compression, andsince it also encrypts data we could not verify sanitization.Since our focus is on digital erasure, the bit patternsare not relevant for drives that store unencrypted, uncompressed data. This means we can evaluate overwritetechniques in general by simply overwriting a drive withmany generations of fingerprints, extracting its contents,and counting the number of generations still present onthe drive. If k generations remain, and the first generation is completely erased, then k passes are sufficient toerase the drive.The complexity of SSD FTLs means that the usagehistory before the overwrite passes may impact the effectiveness of the technique. To account for this, we prepared SSDs by writing the first pass of data either sequentially or randomly. Then, we performed 20 sequential overwrites. For the random writes, we wrote everyLBA exactly once, but in a pseudo-random order.Table 2 shows the results for the eight non-encryptingdrives we tested. The numbers indicate how many generations of data were necessary to erase the drive. Forsome drives, random writes were prohibitively slow, taking as long as 121 hours for a single pass, so we do not

perform the random write test on these drives. In mostcases, overwriting the entire disk twice was sufficient tosanitize the disk, regardless of the previous state of thedrive. There were three exceptions: about 1% (1 GB)of the data remained on Drive A after twenty passes. Wealso tested a commercial implementation of the four-pass5220.22-M standard [12] on Drive C. For the sequentialinitialization case, it removed all the data, but with random initialization, a single fingerprint remained. Sinceour testing procedure destroys the drive, we did not perform some test combinations.Overall, the results for overwriting are poor: whileoverwriting appears to be effective in some cases across awide range of drives, it is clearly not universally reliable.It seems unlikely that an individual or organization expending the effort to sanitize a device would be satisfiedwith this level of performance.3.2.3DegaussingWe also evaluated degaussing as a method for erasingSSDs. Degaussing is a fast, effective means of destroying hard drives, since it removes the disks low-level formatting (along with all the data) and damages the drivemotor. The mechanism flash memories use to store datais not magnetism-based, so we did not expect the degausser to erase the flash cells directly. However, thestrong alternating magnetic fields that the degausser produces will induce powerful eddy currents in chip’s metallayers. These currents may damage the chips, leavingthem unreadable.We degaussed individual flash chips written with ourfingerprint rather than entire SSDs. We used seven chips(marked with † in Table 5) that covered SLC, MLC andTLC (triple-level cell) devices across a range of processgeneration feature sizes. The degausser was a Security,Inc. HD-3D hard drive degausser that has been evaluated for the NSA and can thoroughly sanitize modernhard drives. It degaussed the chips by applying a rotating14,000 gauss field co-planar to the chips and an 8,000gauss perpendicular alternating field. In all cases, thedata remained intact.3.2.4EncryptionMany recently-introduced SSDs encrypt data by default,because it provides increased security. It also provides aquick means to sanitize the device, since deleting the encryption key will, in theory, render the data on the driveirretrievable. Drive E takes this approach.The advantage of this approach is that it is very fast:The sanitization command takes less than a second forDrive E. The danger, however, is that it relies on the controller to properly sanitize the internal storage locationthat holds the encryption key and any other derived values that might be useful in cryptanalysis. Given the bugswe found in some implementations of secure erase commands, it is unduly optimistic to assume that SSD vendors will properly sanitize the key store. Further, there isno way verify that erasure has occurred (e.g., by dismantling the drive).A hybrid approach called SAFE [29] can provide bothspeed and verifiability. SAFE sanitizes the key store andthen performs an erase on each block in a flash storagearray. When the erase is finished, the drive enters a “verifiable” state. In this state, it is possible to dismantle thedrive and verify that the erasure portion of the sanitization process was successful.3.3Single-file sanitizationSanitizing single files while leaving the rest of the datain the drive intact is important for maintaining data security in drives that are still in use. For instance, usersmay wish to destroy data such as encryption keys, financial records, or legal documents when they are no longerneeded. Furthermore, for systems such as personal computers and cell phone where the operating system, programs, and user data all reside on the same SSD, sanitizing single files is the only sanitization option that willleave the system in a usable state.Erasing a file is a more delicate operation than erasing the entire drive. It requires erasing data from oneor more ranges of LBAs while leaving the rest of thedrive’s contents untouched. Neither hard disks nor SSDsinclude specialized commands to erase specific regionsof the drive2 .Many software utilities [14, 5, 28, 23] attempt to sanitize individual files. All of them use the same approachas the software-based full-disk erasure tools: they overwrite the file multiple times with multiple bit patterns andthen delete it. Other programs will repeatedly overwritethe free space (i.e., space that the file system has not allocated to a file) on the drive to securely erase any deletedfiles.We test 13 protocols, published as a variety of government standards, as well as commercial software designed to erase single files. To reduce the number ofdrives needed to tests these techniques, we tested multiple techniques simultaneously on one drive. We formatted the drive under windows and filled a series of 1 GBfiles with different fingerprints. We then applied one erasure technique to each file, disassembled the drive, andsearched for the fingerprints.Because we applied multiple techniques to the drive atonce, the techniques may interact: If the first techniqueleaves data behind, a later technique might overwrite it.However, the amount of data we recover from each file2 The ACS-2 draft standard [4] provide a “TRIM” command thatinforms drive that a range of LBAs is no longer in use, but this does nothave any reliable effect on data security.

Overwrite operationFilesystem deleteGutmann [19]Gutmann “Lite” [19]US DoD 5220.22-M (7) [11]RCMP TSSIT OPS-II [26]Schneier 7 Pass [27]German VSITR [9]US DoD 5220.22-M (4) [11]British HMG IS5 (Enh.) [14]US Air Force 5020 [2]US Army AR380-19 [6]Russian GOST P50739-95 [14]British HMG IS5 (Base.) [14]Pseudorandom Data [14]Mac OS X Sec. Erase Trash [5]Data recoveredSSDsUSB4.3 - 91.3%99.4%0.8 - 4.3%71.7%0.02 - 8.7%84.9%0.01 - 4.1%0.0 - 8.9%0.01 - 9.0%0.0 - 23.5%1.7 - 8.0%0.0 - 16.2%5.3 - 5.7%0.0 - 9.3%5.6 - 6.5%0.0 - 11.5%4.3 - 7.6%0.0 - 34.7%5.8 - 7.3%0.0 - 63.5%6.91 - 7.07%1.1%7.07 - 13.86%1.1%6.3 - 58.3%0.6%6.16 - 75.7%1.1%67.0%9.8%Table 3: Single-file overwriting. None of the protocolstested successfully sanitized the SSDs or the USB drivein all cases. The ranges represent multiple experimentswith the same algorithm (see text).DriveC (SSD)CCL (USB key)LLOverwrites100 100 100 defrag.100 100 100 defrag.Free Space20 MB19,800 MB20 MB6 MB500 MB6 MBRecovered87%79%86%64%53%62%Table 4: Free space overwriting Free space overwriting left most of the data on the drive, even with varyingamounts of free space. Defragmenting the data had onlya small effect on the data left over (1%).is a lower bound on amount left after the technique completed. To moderate this effect, we ran the experimentthree times, applying the techniques in different orders.One protocol, described in 1996 by Gutmann [19], includes 35 passes and had a very large effect on measurements for protocols run immediately before it, so wemeasured its effectiveness on its own drive.All single-file overwrite sanitization protocols failed(Table 3): between 4% and 75% of the files’ contentsremained on the SATA SSDs

"secure erase" commands that should sanitize an entire disk. Physical destruction and degaussing are also effec-tive. Flash-based solid-state drives (SSDs) differ from hard drives in both the technology they use to store data (flash chips vs. magnetic disks) and the algorithms they use to manage and access that data. SSDs maintain a layer