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).

PCMark 7 - Raw System Storage Score

Unencrypted

BitLocker Enabled

Perf Impact

Crucial M500 240GB (eDrive)

4644

4586

-1.2%

Samsung SSD 840 Pro 256GB

6195

5336

-13.9%

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:

Peak Performance - 4KB Random Write (8GB LBA Space, QD32)

Unencrypted

BitLocker Enabled

Perf Impact

Crucial M500 240GB (eDrive)

63334.8 IOPS

62865.8 IOPS

-0.7%

Samsung SSD 840 Pro 256GB

88911.3 IOPS

63097.53 IOPS

-29.0%

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.

There are tools that can decrypt BitLocker, TrueCrypt and PGP. But in order for them to work you need a memory dump of the system or the hibernation file so the encryption key can be pulled from memory. But then this is a "flaw" with all software based encryption, as proven by the CSS and AACS hacks to get DVD and Blu-ray working on Linux.

There are no backdoors in BitLocker. I work at Microsoft and lost my BitLocker recovery key (long story). I called our internal support and their answer was, "you're data is gone."

But the real proof has to do with one word: profits. If there were backdoors Windows would be disqualified for government and enterprise use. Profits go bye-bye. There are no backdoors.Reply

While I agree with you that no known backdoor exist in Bitlocker, your statement "data is gone" is completely wrong. Any encryption implementation would provision recovery keys managed by your organization. MS has a neat server called MBAM for that purpose. So if you loose the primary key, then your security officer could just ask the server to provide a spare (recovery) key.Of course that it is valid if your organization manages encryption, if you did it by your self then you've got a serious procedure problem at MS.Reply

I'm well aware of the key recovery tools. That part is covered under the "long story" part.

This was an interesting case with a new laptop, secure boot, a DisplayPort adapter and a new build of Win8. To make a long story shorter, the BitLocker recovery key was uploaded to Active Directory and I had it saved to a USB drive. When I disabled secure boot it appears that something changed the recovery identifier, which invalidated all the recovery keys.

The change happened just before I went into a reboot loop caused by a corrupt DisplayLink driver, so the change never got updated to MBAM/AD. With the invalid recovery key I was unable to get into safe mode to fix it ... at first. This is when I called internal support and they said, "good bye data."

Eventually I plugged the DisplayPort adapter back into the exact same USB port as the last boot and got back in normally, updated my recovery keys and have been running smoothly ever since (thanks to an updated DisplayLink driver). So I didn't end up losing my data, but had I been unable to get past my frowny of doom loop I would have.

Moral of the story, don't make any UEFI security changes once you've encrypted your drive without backing your recovery keys up immediately afterwards.Reply

"which invalidated all the recovery keys."Thats interesting, I hope you had the dev team look into this, as this seems like a bug, and should never happen."Moral of the story, don't make any UEFI security changes"..or pause Bitlocker before doing them :)Reply

"But the real proof has to do with one word: profits. If there were backdoors Windows would be disqualified for government and enterprise use. Profits go bye-bye. There are no backdoors."

Verisign had a backdoor which was made for the US government. And yes, it was catastrophic for their reputation when it came out. But you can't claim that no business will ever do it, because businesses did. And the US government used it despite having a backdoor in it.Reply