Encrypting solid state disks


When the battery failed on my beloved ThinkPad X41 notebook and I ran into serious hardware limitations on the fully upgraded machine at about the same time, I decided it was time to replace it (it served me well for over three and a half years). As usual when buying hardware on my tight budget, I did a lot of research on how to get the most for my money, but this time I was willing to spend a bit more to get serious performance. I just really wanted to get a fast laptop this time. The X41 always had issues performance-wise: Lenovo shipped it with an 1.8inch hard drive with a non-standard connector. It was only available in a couple of configurations with different disk sizes, but they were all rotating at painfully slow 4200 rounds per minute. As far as I know these three or four hard drives where the only ones of their kind ever produced. When I finally got tired of the extremely slow performance, I spent a hundred bucks to replace it with the only solid state disk I could find to fit this damn non-standard size/connection combination, a Solidata M2. Now I had a really small disk with only 32 GB, but that was fine because it really improved the speed. It was still not nearly as fast as a proper 2.5inch HDD, but it was a huge improvement.

The encryption doesn’t care about the drive used, but does the drive care about being encrypted?

Now, back then I just went straight for a full disk encryption (FDE) using LUKS for my Linux installation as I always do with my laptops. I store sensitive personal information on it and take it pretty much everywhere I go, which is why I think it is a really bad idea not to use encryption on a laptop, ever (this is a big problem with smartphones because they hold the same sensitive information but can’t be protected as easily). But this time, when I was shopping for my new notebook and wanted to get the best performance, I thought about spending the 200 bucks on a new 120 GB SSD like the Intel X25-M which would give me speeds I could never even dream of with a traditional hard disk. Having a hunch, I googled encrypted SSDs and found out some interesting things:

The way SSDs work can have implications on encryption security

First of all, TrueCrypt generally recommends against the use of their encryption software on any device using wear-leveling technology, which includes modern SSDs (if you want to know what this is and a lot more about SSDs, I highly recommend “The SSD Anthology” on AnandTech). However, the kind of attack described there is a bit academic and – especially in the stolen laptop scenario – unlikely. A thief would try a couple of easy passwords and then just wipe the drive and fence the hardware. So, IMHO it is okay to ignore this warning as long as

  1. you don’t change the passphrase (if it’s compromised, securely erase the drive before setting up new encryption),
  2. the data is not yet stored on the device unencrypted (again, wipe the drive first!) and
  3. you don’t need plausible deniability.

The way the encryption works seems to have implications on the performance

A more serious issue, however, are reports of performance impacts up to a point where your expensive SSD would actually be slower than a cheap hard disk. Now, seeing a performance penalty is not a surprise: I can see why encryption would prevent the SSD controller from doing some of the magic that is important for the incredible speeds these devices achieve, e.g. compression. Using software encryption will also put a bit of load on the CPU, which could be a factor at the high throughput rates of a modern SSD, but these numbers were a lot worse than what I would have expected.

The ultimate solution?

Now comes the really frustrating part of the story: There are quite a few really good and affordable SSDs available on the market based on the SandForce SF-1200 controller, e.g. the highly popular OCZ Vertex 2. They come with the promise of “128-Bit AES encryption” (the next generation devices which will hit the shelves in a few weeks use newer SandForce controllers which improve this by using 256-bit AES). Now this sounds totally awesome: We are talking about encryption/decryption done by the controller, which not only means your CPU won’t have to do a single operation for this feature but it could also be implemented independent from the operating system. This would not only allow for much easier usage (think “setting a passphrase in the BIOS”) , but also radically improve the security of FDE against attackers who are not just interested in selling your fancy laptop on eBay, but are targeting you (or your company) directly.

Excursus: Attacking FDE for criminals > petty thieves

The problem with FDE solutions like TrueCrypt or LUKS is that they rely on a piece of software (the TC boot loader or the Linux kernel for LUKS) that cannot be encrypted for obvious reasons. This is why FDE provides good security against some crook who snatches your laptop and hopes to get some credit card details which would probably be worth a lot more than the hardware itself. However, when someone has a big interest in getting data that he suspects to be on this specific laptop, he can do one of the following. The first attack is pretty obvious but often-overlooked and brilliantly explained by Randall Munroe in this XKCD strip:

XKCD comic #538: Security

Another attack is much more subtle and known as the “evil maid attack“: In this scenario, an attacker tries to get to the data without the victim being aware of it. To do this, the evil maid replaces the unencrypted software mentioned above with a modified version that behaves exactly the same, but includes at least a key logger. The attacker can then come back the next time to grab the key and unlock the hard disk – or the malware could even transmit the key over a network.

As you can see, when you move the unencrypted software that asks for the passphrase to a lower level (e.g. the BIOS), the evil maid attack gets more difficult (a BIOS is just harder to modify and replace than a boot loader) – and combined with read-only memory for the software that unlocks the disk and trusted computing modules, we could get to a whole new level of hard drive security.

Back to the possibly ultimate solution (which is no solution at all)

However, when I tried to find documentation on how to use this feature, I found out that it is actually not the ultimate solution, but pretty close to being completely useless crap: The good part:

  • it’s enabled by default and can’t be disabled and
  • the keys are randomly generated (i.e. they are not derived from the drive’s serial number or something as stupid as that – which is a beginner’s mistake a lot of companies do).

But that’s about it. The bad part: All it really does is generate the random key and encrypt all data sent to the drive with it. When the data is read, the controller uses that key to decrypt it again. It is not, however, possible to set a password for this, although it seems that this is possible by design: OCZ promised to provide this feature in their “toolbox” software often in their support forums, but they have not released it up to today. And even if they did: This would be a windows-based solution so after you set a password on the drive with it you would need to boot windows and run their toolbox to unlock the drive – meaning it would not be possible to use the disk as a boot device any more and again rendering the encryption feature completely useless.

(To be completely honest, this encryption feature is useful for one use case: when you use the ATA secure erase feature, the generated encryption key will be wiped and regenerated by the controller. This means the key to decrypt all the data will be lost, making it a good solution to securely erase a drive.)


Now all of this is pretty frustrating if you are serious about speed as well as security for your laptop: When you want to get the performance benefits of a solid state disk, you can’t really use encryption. As a trade-off, you could leave the operating system unencrypted and only encrypt your home folder – this would still result in much faster boot and application loading times while protecting your personal data. However, that would make “evil maid” attacks even easier because you can place your malware at a higher level or just install other malicious software straight into the operating system. It would still protect you against the scenario of the stolen laptop, though.

Because of all this, I currently would recommend against using a SSD in a laptop – even if the performance improvement of SSD drives are very tempting. There is a compromise solution I will try: Seagate’s Momentus-XT hard drive combines a lot of (up to 500GB) fast (7200 rpm) traditional storage with the speed benefit of a 4GB SSD cache. The controller will move the most-often read sectors to the SSD so if you launch your Browser often, it will probably be stored in the cache and load much faster. I hope that this solution does not suffer as much from FDE as a normal SSD and will try to offer some benchmarks when it arrives.

Update March 2: There are other articles suggesting that an encrypted SSD is still much faster than a HDD. Also, Samsung seems to offer SSDs with real encryption, but I did not look into that because it’s only available on the 256GB model which is too expensive for me and I already ordered the Momentus-XT.

This entry was posted in Uncategorized and tagged , , , , , , , , , , , , , , . Bookmark the permalink.

2 Responses to Encrypting solid state disks

  1. Pingback: Benchmark: Samsung XT hybrid, with and without full disk encryption | c089

  2. Mvaldez says:

    This is an old but still relevant post. Just a couple of comments regarding the performance issues: 1) Sandforce chipsets don’t pèrform well with large blocks of incompressible data (for example, when using full-disk encryption) because part of their performance gain comes from the real-time compression they do on the data; 2) if your CPU have AES hardware acceleration (the AES-NI extension) the bottleneck is no longer the CPU (a common issue with old hardware with new a SSD) and you’ll see almost same performance than unencrypted disks; 3) SSD with unaligned partitions may perform poorly. So, yes, combining a SSD with a SandForce chipset with a CPU without AES acceleration with misaligned partitions will have a very poor performance. I have an old laptop with a SSD and its performance is roughly the same than when using the old HDD (both with LUKS), and it’s not a Sandforce chipset and the partitions are aligned: the bottleneck is the CPU. But I also have several desktops all with AES-NI (mostly AMD FX processors) with Crucial and AData SSD and their performance is pretty good.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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