SSDs, encryption and decommissioning

SSDThe research paper about secure erasure of SSDs that Chet Wisniewski wrote about earlier this month has raised quite some discussion also here in Sophos’s Data Protection Group.

As you may imagine, it’s our objective to provide you with the best protection that encryption can deliver. With SSDs or any other flash-based block storage devices, though, there’s a couple of things you need to know:

Device encryption (also known as Full Disk Encryption – FDE) software products encrypt entire volumes or even hard disks on a sector level. As they have to start out with a plain text disk, they perform an initial encryption process where the volume or disk is encrypted by a background process sector-by-sector.

On a classic hard disk, this in-place encryption guarantees that every sector of a volume gets encrypted and no plain text sectors remain left.

On an SSD, however, encryption is not performed in-place, and unencrypted pages (this is the actual SSD-speak for sectors) may remain in its internal store of redundant pages. The reason for that is the wear leveling strategy, which aims at evenly wearing out all pages of an SSD.

Although these surplus pages cannot be accessed over the regular hard disk interface of a computer, they can be accessed when the flash chips are dismantled from the SSD and read out in a dedicated reader device. The research paper numbers the mere hardware cost of such a device from US $200-1000. Of course, advanced hardware skills are necessary to construct one.

But back to our device encryption scenario: The surplus pages can apparently only contain sensitive plain text data at all if these data had already existed on the disk before initial encryption was done.

So if you install device encryption and complete initial encryption before any confidential enterprise data could ever reach the disk, you’re off the hook.

Data encryption

Another important issue is the availability of ‘Fast Initial Encryption’ (FIE, this is the Sophos term; other products may call it differently).

With FIE, put simply, the only hard disk sectors that are (initially) encrypted are those that contain valid file data (as opposed to empty areas or areas with remnants of deleted files).

When using FIE with a classic hard disk, you already have to be aware of the potential threat that plain text remnants of files, that had been deleted before initial encryption was run, survive the initial encryption process. And they can be read easily, e.g. with a sector-level disk editor! On disks with a short file operation history (e.g. new disks), this may be an acceptable risk.

With FIE run on an SSD, however, things become more delicate: When FIE is run, the affected pages are encrypted and written to new pages (as a consequence of wear leveling).

If only a small portion of the volume is actually allocated, however, the original pages are hardly erased at all, and most or all remain present in plain text (this is, in the area of surplus pages), at least for some time. Attack devices, as described above, can still read them.

On a fairly full volume, this effect is less relevant, since the surplus pages will be overwritten again on short term, this time with encrypted data.

Keep this issue in mind when you consider using FIE on an SSD in order to preserve a sufficient amount of unused space (which is a general recommendation for good performance with SSDs). In our experience, SSDs that have a sufficient store of redundant pages (and this is the majority) do not require this performance measure.

And there’s even one more issue: Sophos Device Encryption (and probably other FDE products as well) offers a mechanism for instant decommissioning of a volume.

In short, by overwriting the Key Storage Area (KSA) sectors of the volume, encrypted data without a decryption key is left behind, which is equivalent to (useless) random data for any attacker. When you overwrite the KSA on an SSD, though, you cannot guarantee that no stale copies are left behind.

I can already see the twinkling eyes of those of you who have always argued that a sledge hammer was the only satisfactory way to decommission a hard disk.

Man and sledgehammer

Self-encrypting hard disks (e.g. following the Opal standard) typically implement a decommissioning feature to efficiently erase their KSA(s). If decommissioning is an issue for you, a self-encrypting SSD is an option.

Unfortunately, we’re dependent on the vendor claims here that KSA erasure is done securely, and verification is hardly possible outside the vendor premises (according to the research paper, there is reason to be skeptical about the proper implementation of such commands).

It is up to the vendors to provide us with more confidence here, e.g. by submitting samples of their self-encrypting disks to independent security test labs.

To summarize, device encryption with SSDs comes along with some security issues that you need to take care of.

Whenever possible, roll out encryption before any sensitive data can reach the disk. If there’s already sensitive data on the disk, don’t use FIE. If fast decommissioning is important to you, consider self-encrypting disks, but only if you trust the vendor.

Last, but not least, when the SSD reaches its end of life, you should think about destroying it physically.