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 a 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 that are “pseudo-random.”

In the early days, multiple passes were needed for full drive sanitization. Today, because of the accuracy with which we can write to magnetic media, a single pass can fully erase an HDD. Also to be noted here is that no special processes or procedures can be applied to extend the life of that drive.

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 actually will 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 that 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 that needs to be discussed here 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 will most likely still reside inside pages now delegated to the grown defect list. These pages also 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 particular command or their firmware may not forensically sanitize the drive based on the “erase” command that was issued.

Before continuing with how SSDs can be fully sanitized, we need to understand how this technology processes commands.

Any SSD has a front-end controller that uses a SATA, SAS, FC, PCI or USB interface. A back-end NAND controller 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” cycle, “read” cycle and “block_erase” cycle. 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 will address the full block. This includes all the pages in all the blocks regardless of whether they were designated as bad (defective) or not.

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” 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 (available at http://cseweb.ucsd.edu/~swanson/papers/Fast2011SecErase.pdf), 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 sanitized only partially and another group showed no overwriting.

However, since this study was published, the world of electronic data storage has evolved and there is currently a bit more consistency among SSDs and the “secure_erase” command. It needs to be stated, however, that many variations still exist among SDDs and that this command does not always result in forensic-level data erasure on all SDDs.
 

Erasure limitations

The only way to completely sanitize an SSD is through issuing the “block_erase” command. This being said, and for reasons including a lack of standardization inside the industry, not all manufacturers have their firmware programmed to implement this command. They 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 present in the “out-of-rotation” addresses and will not perform forensic-level sanitization.

Vendors also vary in terms of how the “block_erase” command is invoked. 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 can seem. For this reason, each vendor has a unique set of circumstances required for forensic-level data sanitization, and data sanitization software providers must work closely with an individual manufacturer to understand its particular SSD architecture.
 

Validated results

Verification is extremely important with any data sanitization process. If the sanitization software cannot confirm (verify) that all data and data fragments have been successfully erased from the drive, then 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 any financial ramifications that could result from a data breach pertaining to that “sanitized” drive.

SSDs can be forensically sanitized. While no one procedure can successfully sanitize all drive models from every manufacturer, techniques are available that allow for automated processes and efficient sanitization of high volumes of SSDs.

The author is the marketing manager for ITRenew, Newark, California, and can be reached at 408-744-9600 or through www.itrenew.com. This feature first appeared in the September/October 2014 issue of Storage & Destruction Business, a sister publication of Recycling Today.