Realizing the possibilities

A common misconception among the IT asset disposition (ITAD) community is that solid state drives (SSDs) cannot be fully sanitized. While the underlying technology used in these devices does present a challenge for comprehensive data erasure, forensic-level data sanitization is possible; it just takes the right set of procedures based on the manufacturer, make and model of the individual drive.

While this article presents an aerial view of SSD technology and is not intended to be highly technical, it will outline the basic differences between SSD and hard disk drives (HDDs) as well as provide an overview of the process for effectively sanitizing SSDs.
 

SSD and HDD differences

Before we can understand how SSDs can be sanitized, we need to understand the difference between them and HDDs. While both use either a one or a zero to store information at the granular level, the differences end here.

HDDs are a form of magnetic media. Every address (location) on that media is always available for write and read operations. To comprehensively erase an HDD, a simple “wipe” operation can be used. A wipe operation will write a predetermined pattern to each and every address on the media, replacing any data that may be there. Wipe patterns can be all ones, all zeros or any of a number of preset patterns, including some which are “pseudo-random.”

In the early days, multiple passes were needed for full sanitization. Today, because of the accuracy with which we can write to magnetic media, a single pass can fully erase an HDD.

SSD architecture uses multiple computer (NAND flash) chips that ultimately allow individual transistors to store the ones and zeros. (NAND flash is a nonvolatile computer storage medium that can be electronically erased and reprogrammed.)

Unlike magnetic media, every transistor in each computer chip located inside an SSD can cycle between one and zero a finite number of times. To extend the life of an SSD, therefore, a process known as “wear leveling” is employed.

Wear leveling is made possible by the fact that each SSD is manufactured with more storage capacity than is accessible to the user at any time. As an example, an SSD rated for 200 gigabytes will actually contain 16 NAND chips, each with a storage capacity of 16 gigabytes. Doing the simple math tells us that this particular drive could actually hold up to 256 gigabytes of information. With 256 gigabytes of storage embedded in the drive and only 200 gigabytes being used, what is the other 56 gigabytes of storage being used for?

At any time, only the logical blocks are available for write operations. The remaining storage space, the other 56 gigabytes of physical addresses (blocks) in this case, is temporarily quarantined from use. Intuitively this may seem inefficient, but it is necessary.

Inside an SSD, data are written to what the firmware (control system) has designated as the “available” logical blocks. For the purpose of making sure every address block inside the drive has received a similar number of write cycles, complex algorithms are used to rotate all physical blocks in and out of use. Think of this as player substitution in sporting events. As players reach a certain amount of game time, they are brought out of the game, and other players are brought in.

One thing to note here is that when a block is rotated out of use, any live data residing in that “out-of-use” block are duplicated in the new location. It is with the physical versus logical blocks that the challenges associated with comprehensive data sanitization of SSDs are found. The control system will not waste a write cycle to erase the data in what is now an unused and inaccessible location.

One last concept to discuss is defect lists. When a NAND chip is manufactured, certain areas (pages) inside that chip may not be functioning properly. The back-end control system is smart enough to recognize these pages and take them out of use and rotation.

Also, as the drive and the NAND chips experience repeated write cycles, certain pages may go bad or even reach their maximum number of write cycles. When this happens, the controller will recognize that these pages should no longer be used and add them to what is termed the “grown defect list.” It is important to recognize that (legacy) data still will most likely reside inside pages now delegated to the grown defect list. These pages must be accessed for comprehensive data sanitization.
 

Key commands

For comprehensive, forensic-level data sanitization of SSDs, both the physical and logical blocks must be accessed and cleared of data.

The good news is that a specific firmware command can be invoked for complete data removal on any SSD. This command will apply wipe algorithms to the SSD’S logical and physical blocks.

The bad news is that because of a current lack of standards, vendors may not support this command or their firmware may not forensically sanitize the drive based on the issued “erase” command.

Before continuing with how SSDs can be fully sanitized, we need to understand how they process commands.

Any SSD has a front-end controller that uses a SATA, SAS, FC, PCI or USB interface. A back-end NAND controller also acts as the traffic cop for physical and logical blocks/addresses. The front-end interface allows for communications and is used to initiate procedures such as write, retrieve or sanitize. The back-end NAND controller directs and implements what is actually being done.

With the back-end NAND controller, only a few commands can be implemented. These include “program,” “read” and “block_erase.” The “program” cycle and “read” cycle commands are applied at the block level while still recognizing the defect page register and not doing anything to the those pages. The “block_erase” command ignores the defect register and always addresses the full block. This includes all the pages in all the blocks regardless of whether they were designated as bad (defective).

One other command that is important in our discussion is “secure_erase.” According to the study “Reliably Erasing Data From Flash-Based Solid State Drives” (available at http://cseweb.ucsd.edu/~swanson/papers/Fast2011SecErase.pdf), published in February 2011 and authored by Michael Wei, Laura M. Grupp and Steven Swanson of the Department of Computer Science and Engineering at the University of California, San Diego, and Frederick E. Spada of the Center for Magnetic Recording and Research at the University of California, San Diego, the results produced by a “secure_erase” command varied among SSD devices from different vendors. Some devices that were issued this command received full forensic-level sanitization, others were only partially sanitized and another group showed no effect (no data overwriting).

Since this study, there is more consistency with SSDs and the “secure_erase” command. However, many variations still exist, and this command does not always result in forensic-level data erasure.
 

Erasure limitations

The only way to completely sanitize an SSD is by issuing the “block_erase” command. However, not all manufacturers have firmware programmed to implement this command. Manufacturers may use other techniques designed to overwrite data, but this action is performed only on the logical addresses. Any command other than “block_erase” will leave data in the “out-of-rotation” addresses and will not perform forensic-level sanitization.

Vendors also vary in how to invoke the “block_erase” command. Depending on the mechanism used to lock out (quarantine) defect list pages and physical addresses, gaining access on demand may not be as easy as it seems. For this reason, each vendor has a unique set of circumstances required for forensic-level data sanitization. Data sanitization software providers must work with a manufacturer to understand its SSD architecture.

Validated results

One thing that is extremely important to note with any data sanitization process is the verification step. If the sanitization software cannot confirm (verify) that all data and data fragments have been successfully erased, a Certificate of Sanitization (CoS) should not be issued.

With a CoS, the issuing party accepts responsibility not only for the efficacy of the software used to overwrite the drive but also for financial ramifications that could result from a data breach associated with that (sanitized) drive.

SSDs can be forensically sanitized. While no one procedure is applicable to all drive models from every manufacturer, techniques can allow for automated processes and efficient sanitization of high volumes of drives.

Leigh Kimmelman is the marketing manager of ITRenew, Newark, California. He can be reached through www.itrenew.com.