This article offers background, explanations, and tips to aid in decision-making when encrypting SSD drives using encryption software tools.
Data Security For SSD Drives – Importance and Issues
As with any data storage medium, protecting the data on a solid-state drive (SSD) is important and needs to be reliable. Regardless of the software tool in use, if whole-drive encryption available, it should be used.
Whole-drive encryption means encrypting all sectors on the drive. The aim is to provide complete data security.
SSDs, however usually designed with special mechanisms for managing their data. In the process of managing the data, copies of rewritten and deleted data left scattered throughout the drive. These copies are typically inaccessible to encryption software, and they remain as unclosed holes in SSD data security.
Sensitive Periods In The SSD Life Cycle
It is best to use an encryption tool right away before sensitive data written to the drive. Doing so can sidestep most of the risks inherent in SSD behavior.
When decommissioning an SSD at its end of life, overwriting its key storage area (KSA) will not be sufficient. The rest of the drive will still hold data that might be recoverable by malicious third parties. Even the KSA itself cannot be sanitized, because old copies of it will remain on the drive.
One approach to solving this problem is to use self-encrypting and decrypting SSDs. Failing this, it will be necessary to physically destroy the drive.
Problems Of SSD Internal Data Management
Particular care taken when encrypting SSDs. Unlike the older ATA/SCSI hard drives, SSDs use the same technology as USB drives. An internal controller writes data to pages (equivalent to sectors in a disk drive) using an internal algorithm.
The order in which the pages written is unrelated to the chronological order or apparently available space on the drive. Moreover, when the controller deletes data from the SSD, it does not actually erase the data. It merely marks the page with the deleted data invalid, leaving it physically in place.
For these reasons, external software tools such as encryption applications cannot operate directly on an SSD. The controller acts as a buffer between the outside world and the internal structure of the SSD. Only the controller has the low-level access needed for control of the data’s physical placement on the drive.
Working on the SSD using external tools is different from using the older ATA or SCSI drives. Those older drives gave driver software full access and control at each physical address on the device. In contrast, with SSDs, the only way to ensure full encryption is to encrypt the data before entrusting it to the SSD controller.
Why Wear Leveling Drives SSD Behavior
More details about the technical background of SSD internal data management and sanitization for SSDs will clarify the problems involved in encrypting the data on an SSD. A key issue is “wear leveling.” SSDs, as mentioned already, organized into physical pages.
Each page has a limited usable lifetime of perhaps 10,000 writes before it fails. The SSD controller attempts to even out (“level”) this wear through a complex algorithm that distributes data writes evenly to all pages in the drive.
In carrying out these internal operations, the controller must keep track of both the logical address of each file and also the physical address of the SSD pages containing that file. The controller translates logical addresses to physical pages.
Each time a file is written to the same logical address, the controller usually picks a new physical page to avoid overusing the existing page. In the process, it leaves the existing page in place, marked inactive.
In fact, SSD internal data management, including garbage collection, leaves behind more than one inactive copy. As many as 16 older copies of a file may linger on the drive, in plain text if it was written before the drive was encrypted.
The details of SSD garbage collection are not usually available to users. It appears to find and erase free space when the SSD is idle. Some SSDs may attempt to use NTFS algorithms to erase free space, but encryption impedes this operation.
SSD Data Management Leads To Security Gaps
So wear leveling, while extending the life span of the drive as a whole, also leaves old inactive copies of the file’s data scattered over the drive. The internal management of these copies creates a level of indirection that, as mentioned above, blocks ordinary users from full access to their data and therefore full data security.
Since the internal translation algorithm not accessible to users or outside software, the physical locations of pages cannot be determined by querying the controller. A further level of indirection appears in certain SSDs that compress data at the same time as translating from logical to physical addresses.
SSD internal management thus creates potentially unencrypted data fragments that are also inaccessible to the user. There is no method generally available to sanitize the data copies left over from SSD wear-leveling.
Sanitization is any process, including encryption, of denying third parties access to sensitive data, either by removing it from a medium or file or by rendering it unrecoverable. Sanitization was far easier on ATA or SCSI drives than on current SSDs.
Security-related commands familiar with working with ATA or SCSI drives often fail to work for SSDs. They are inconsistently implemented across SSDs. They may operate unreliably or not at all. If they fail, they may do so without error messages or warnings.
The TRIM command, useful on ATA and SCSI drives, is unsatisfactory on SSDs. It can only request the SSD garbage collection mechanism to erase a physical area. There is no guarantee that the command carried out or when it will be done.
SSD vendors may provide tools to erase pages holding deleted data, but these tools cannot give verification of correct operation. If the SSD has already partitioned into multiple volumes, then even more data will be left insecure.
Faced with these problems, researchers seeking to understand SSD controller operation have found ways to access the physical pages on the SSD, bypassing the controller itself. On reading SSD flash chips using special readers, they have found that the actual data capacity of most SSDs is 10%-30% larger than the official specifications.
The extra space appears to support the wear-leveling process. At the same time, it often contains unsanitized data. Some SSDs lack this extra space, but when they approach full capacity, their performance degrades to unacceptable levels.
There is nothing to stop determined malicious third parties from using the same techniques as the researchers to extract these unencrypted SSD pages. The cost ranges from only $200-$1,000.
Further Implications For SSD Data Encryption
SSD internal behavior thus clearly points to encrypting as soon as possible, before sensitive data written to the drive. The behavior of the SSD internal data management process has a strong impact on how users should perform initial encryption.
If the software tool offers a choice between regular and fast initial encryption, regular chosen. Regular initialization writes to all logical addresses, thus touching most or all the physical pages of the SSD. At most 10%-30% left unencrypted. 0% unencrypted would be ideal but is currently unattainable.
In contrast, fast initialization will only write a few of the physical pages, leaving most of them unencrypted and therefore at risk. Most previously deleted or overwritten pages will, of course, be unencrypted in that scenario.
The Future Of SSD Encryption And Security
Some software vendors are working to develop firmware to provide users with greater control over the physical view of SSD data. The history of software and hardware development trends, however, suggests that industry acceptance may be problematic and incomplete at best.