SSDs, encryption and decommissioning

Filed Under: Data loss, Privacy

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.

, , , , , , , ,

You might like

4 Responses to SSDs, encryption and decommissioning

  1. Douglas Leeder · 1684 days ago

    I believe TrueCrypt have similar worries:

    As well as decommissioning the key area can need to be overwritten if the password is changed, and wear-leveling can leave the old key area around, which means the old password would still allow decryption. This would be very bad if the password change was due to the old password being leaked.

    • Michael · 1684 days ago

      Well - they also put their pants on one leg at a time. I don't expect any competitor to be in a better position here.

  2. Mike Kirby · 1684 days ago

    Throw it in the furnace.

  3. James Gilliver · 1684 days ago

    I've used my trusty lump hammer for years..!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Michael A Schmidt is the primary security contact within Sophos Data Protection Group (DPG) software development. He has been with Utimaco (the predecessor of the DPG) development for many years, filling various development- and security-related positions. Currently, he is harassing the other developers in the group with the promotion of a security-oriented software development process. Even more, Michael is forming a group of conspirators within Sophos to run a world-wide, 'Distributed Promotion of Secure Coding' attack.