Since the inception of NAND flash-based storage devices, there have been a number of studies and many debates about the integrity of flash including: what is the appropriate method of destroying data stored on NAND flash memory components?

With flash, there are variables which obstruct a simple approach of overwriting the medium with a basic or even complicated pattern as a means of forensic data sanitization. For this reason alone, adopters of flash who mandate forensic-grade data sanitization should reject a data erasure vendor’s claims of any solid-state drive (SSD) data sanitization method that is based on an overwrite technique.

Whenever we think of a solid-state disk, we will think of a storage disk with a SATA or SAS interface. This interface is known as the device’s frontend and it communicates with the controller using the ATA or SCSI protocol. The SSD device also contains a backend interface that is used to communicate with the NAND flash components. NAND flash also has its own command protocol which is governed by the Open NAND Flash Interface (ONFI) Workgroup. When the host system issues a WRITE command to the SSD, it will utilize the ATA or SCSI WRITE command to the drive. And it will then utilize the drive’s firmware and Flash Translation Layer (FTL) to interpret and translate the operation to the OFNI defined command, PROGRAM CYCLE.

With OFNI, there are only a handful of commands (operational code) that are defined as mandatory for which we will always assume to be implemented as they are, well, mandatory. The common commands utilized during an effective SSD sanitization tool are: BLOCK ERASE, PROGRAM, READ and READ STATUS.

COMMAND

OPCODE

Block Erase

60h/D0h

Change Read Column

05h/E0h

Change Write Column

85h

Program

80h/10h

Read

00h/30h

Read ID

90h

Read Parameter Page

ECh

Read Status

70h

Reset

FFh

Table: Mandatory list of OFNI-defined operational codes for accessing NAND flash storage.

For a perfect SSD sanitization, the first step would be to put together the full inventory of NAND addressing/layout by the means of the READ ID and READ PARAMETER PAGES. At this stage, we are only concerned with the NAND NOT identified through the manufacturing defect map. From this point, a BLOCK ERASE is issued to all blocks outside the manufacturing defect map. This will address all the provisioned, un-provisioned, flagged for remap and remapped (post manufacturing map) blocks. Since the BLOCK ERASE function is defined to include the verification, there is no need to issue the READ command to the blocks or pages.

The challenge with achieving the perfect sanitization of an SDD is that it’s not possible to bypass the FTL and send the native flash commands directly to the NAND flash. What is exposed on the frontend is an ATA or SCSI interface and a logical block address (LBA) range and not the full physical NAND address map.

SSD Data Sanitization Vulnerability #1: Multiple Overwrites

As mentioned earlier, the device’s firmware and FTL will translate the ATA/SCSI commands to OFNI-defined commands, but addressing is not translated. The device’s flash manager will add complexity for translated WRITE commands when issuing the PROGRAM cycles to the flash as physical addresses are never guaranteed due to the flash manager’s wear leveling algorithms, which are put into place to preserve the integrity of the drive by always rotating in younger blocks and rotating out the older dirty blocks.

How then is an overwrite method going to address this? Some vendors will say if you overwrite a drive multiple times, then it will get around the wear leveling. However, this is not accurate and will leave a drive vulnerable to “chip off” attack, which involves removing a NAND flash memory chip from a device and copying its data. Some SSD devices will minimize the internal overhead of wear leveling and rotate a block after X amount of program cycles. If you know what X is, then overwriting the drive X times will reduce the risk, but still not eliminate the risk.

SSD Data Sanitization Vulnerability #2: Uncompressible Data

There is a message being spread throughout the industry that if you use “uncompressible” data to overwrite the SSD, it will sanitize the SSD device. The term uncompressible means no compression. If someone develops a patent for overwriting an SSD device with “uncompressible” data, which uses a statistical measurement to prove that the pattern employs an acceptable threshold window of randomness, then that window is what you need to be concerned about. The outcome is not an absolute “no compression” and since it is not absolute, this leaves room for characters in the pattern to repeat. And if you have repeating characters, then you have a compressible pattern.

The other concern is this: if an uncompressible pattern is required as the means of sanitizing an SSD drive, then why is it necessary to issue a firmware-based erasure command after? It is because the overwrite passes are not capable of forensically sanitizing an SSD device, where the firmware-based command is capable.

SSD Data Sanitization Vulnerability #3: Any Standalone Overwrite

The perfect sanitization method outlined earlier did not use any PROGRAM commands to the NAND flash. The reason is the PROGRAM and READ flash commands have a grave limitation in that they do not cover flagged blocks or defect maps. NAND flash is designed to have high performance. Over time, as the gates within the cells wear out, they become corroded to where the cycle times are impacted.

A page could have user data, and within that page the overall block could become flagged where the next PROGRAM cycle will rotate the block out of the provisioned area. At this point, it will become a bad block; one that will contain user data and one that will be missed by the PROGRAM command. The only way to process the blocks will be through the BLOCK ERASE command. The BLOCK ERASE command will not check any status registers of post-manufacturing defect maps and will automatically erase the data contents of the block.

Conclusion

When choosing a data sanitization tool for SSD devices, it is important to partner with a solution provider that does not focus on using an overwriting technique as a means of sanitizing the device. Security compliance should be based on an absolute forensic-level data sanitization technique that eliminates risk rather than focusing merely on minimizing risk.

About the Author
As the Director of Product Development, Matt Mickelson is responsible for development of ITRenew’s data sanitization product line. This includes Teraware, an enterprise-grade data sanitization and asset management software platform, and Terabot, a line of do-it-yourself data erasing machines that are powered by Teraware software. Matt also directs all aspects of the ITRenew Innovation Center, an R&D facility and data security think tank. The center’s core charter is to intimately understand – and stay ahead of – the various technologies that storage manufacturers develop and customers deploy in order to ensure compatibility with Teraware data center decommissioning.