Hardware Accelerated BitLocker Encryption: Microsoft Windows 8 eDrive Investigated with Crucial M500

Most modern SSDs come with some form of hardware encryption. On these drives with hardware encryption, it’s usually permanently turned on - all data written to the NAND is typically stored in encrypted form. This stems from the fact that all writes to NAND had to be scrambled to begin with (writing long repeated strings of data to NAND can cause problems for data retention). The earliest implementations weren’t sophisticated enough to be considered real encryption, but these days it’s not uncommon to see hardware AES-128/256 support.

The bad news has been that relying on OS driven filesystem encryption always meant the use of software encryption on top of your drive’s native encryption. This was particularly a problem on SandForce based drives, where full disk encryption basically ruined any of the performance advantages of the controller’s native compression/de-dupe (you can’t further reduce encrypted data). Other drives suffered (just not as much) due to the added overhead from having to leverage the host CPU to encrypt all data before writing it to disk. There’s also the fact that if you encrypt your entire drive (free space included), the drive ends up looking like a completely full drive - which has performance implications of its own. This was the world that existed with BitLocker under Windows 7 and FileVault under OS X.

With Windows 8, the story is a bit different.

I hadn’t heard of Microsoft’s eDrive standard for Windows 8 until I started working on the Crucial M500 review. It turns out that if you have a storage device (e.g. SSD, eMMC, etc...) that meets the right encryption standards, Windows 8’s BitLocker will leverage the device’s hardware encryption engine, bypassing the software based encryption altogether. The result should be better performance and lower power consumption.

The M500 is the first drive that I’m aware of to support Microsoft’s eDrive standard. Because of its TCG Opal 2.0 and IEEE-1667 compliance, the M500 is eDrive compatible. There are some platform requirements to get eDrive working as well. You’ll obviously need a system that will support BitLocker (although hardware TPM isn’t necessary, you can still go the USB key route). It’s important to note that you have to enable UEFI boot and make sure you have a UEFI enabled Windows 8 install in order for this to work. Your platform will specifically need to support UEFI 2.3.1 (Class II no CSM/Class III). Often times UEFI boot support on motherboards can be tricky, particularly on earlier firmware revisions, so be sure you’re updated (this was the problem I ran into with my test hardware). I've had varied luck with getting DIY desktop PC hardware to behave appropriately with UEFI and BitLocker enabled, so your mileage may vary. The experience on a TPM enabled notebook should be far cleaner from what I've heard.

With all of your ducks in a row, all you need to do is enable BitLocker at this point. If everything is eDrive compliant you won’t be asked whether or you want to encrypt all or part of the drive, after you go through the initial setup BitLocker will just be enabled. There’s no extra encryption stage (since the data is already encrypted on your SSD). If you’ve done something wrong, or some part of your system isn’t eDrive compliant, you’ll get a progress indicator and a somewhat lengthy software encryption process.

For example, with 107GB in use my test 240GB M500 was fully encrypted with BitLocker enabled after a couple of seconds. Just a pause, then boom, BitLocker was enabled. My 256GB Samsung SSD 840 Pro on the other hand took about 21 minutes to encrypt the very same data using software encryption.

The gallery below shows all of the steps I went through to enable BitLocker/eDrive support on my Intel DX79SI motherboard with Crucial’s M500.

The ability to quickly enable/disable BitLocker is a nice perk, but it’s only part of the story. There’s basically no change in performance with BitLocker enabled on the M500 since the encryption is all done on the drive (and was always being done there to begin with).

The sad reality is, Samsung’s 256GB 840 Pro with software encryption enabled ends up being faster than the M500 running as an eDrive, but in theory if the drives were equal performers you’d see a clear advantage to the eDrive compliant hardware. PCMark 7 isn’t the most stressful test and we’re really only measuring peak performance here however. Given that the 840 Pro should look like a completely full drive with its free space encrypted, I ran a short 4KB random write test to see whether or not that was the case:

Now this is much more interesting. On a mostly empty drive, the 840 Pro behaves like it’s full of data and thus shows lower peak 4KB random write performance. The M500 on the other hand behaves like it’s empty. As neither one of these drives has the best behavior after extended usage in a full state, the long term performance benefits are tremendous.

There should be power savings associated with running as an eDrive, although since my testbed is a desktop PC they aren’t all that visible. The irony here is that none of the modern (UEFI 2.3.1 hit in mid 2011) PC notebook hardware I have on hand will support a 2.5" SSD.

As someone who regularly uses full disk encryption, I can’t tell you how excited I am at the thought of eDrive compliant SSDs. There’s absolutely no reason this shouldn’t be how all OS level encryption works. Kudos to Microsoft for making this happen and to Crucial for supporting it.

I’m hoping we’ll see more eDrive compliant SSDs in the future. For now, anyone who is required to run with BitLocker enabled should seriously consider Crucial’s M500.

On the Mac side, I do hope Apple will follow Microsoft’s lead here and build similar support in to OS X for FileVault. The power and performance savings are worth it, especially when you consider that SandForce based SSDs are now in Apple’s official parts bin.