Subscribe via Email

Subscribe via RSS


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

FYI: Self Encrypting Drives must be uninitialized for BitLocker Hardware encryption

Got myself a new 1TB Crucial MX200 SSD today. This is a Self Encrypting Drive like my other SSDs. When I tried enabling BitLocker on it as I usually do, I noticed that it was asking me about how to encrypt the drive and taking more time with the encryption than I have seen in the past with SED drives that support the TCG OPAL standard. 

Not good if you get this screen!

Not good if you get this screen!

Something was not right. So I went back to Microsoft’s page on BitLocker and SEDs and noticed that one of the requirements was that the drive must be uninitialized! Damn! In the past I usually enable encryption and then copy over data, but today I had copied the data first (thus initializing the drive and creating partitions) and then I was trying toe enable encryption. Obliviously that was a no-go so I had to copy the data out of the drive, uninitialize it, and then turn on BitLocker encryption. 

Uninitializing is easy via diskpart

Now Disk Management will show the disk as uninitialized. 


Create partitions as usual but before writing any data to the disk turn on BitLocker encryption. This time it will be a one-second operation and you won’t get a prompt like above. 

To confirm that the drive is hardware encrypted (in case you wonder whether BitLocker didn’t just zip through coz the drive had no data on it) use the manage-bde command:

As you can see the drive is hardware encrypted. 

[Aside] Understanding SSD performance

Was reading up on SSD performance degradation and came across this (old) article from AnandTech. Good one! Explains why SSD performance degrades over time and what TRIM sorta does to improve things. The unfortunate truth seems to be that SSD performance will slowly degrade over time and the only way to restore performance then is to do a secure erase (see this PCWorld article too). 

Update: I don’t want to make a new post just to mention this so I’ll update this older post of mine. Here’s a post from Scott Hanselman on why Windows defrags your SSD drives and how that’s not such a bad idea. Upshot of the matter is this: fragmentation affects SSDs too, though not as much as HDDs (because SSDs have no performance hit unlike HDDs). With SSDs fragmentation affects performance in that (1) there’s a limit to the number of fragments a file can have, and once that limit is reached it can cause errors when writing/ updating; (2) more fragments means more time spent putting these fragments together when a file is read. To avoid these performance issues Windows automatically defrags SSDs once every month.

Self Encrypting Drives (SEDs), BitLocker, UEFI, Truecrypt, etc

Past few days I upgraded my laptops with SSD drives. Learnt a few bits and pieces on the way, this is just a dump of what I learnt in case it helps others.

SSDs are fast and can really speed up old hardware, but set your expectations right if you are using encryption. In my case, an aging laptop with a 5400rpm regular HDD was very fast (as expected) when replaced with SSD. But add Truecrypt encryption to the mix, and it slows down a bit. Not too much, but noticeably, and especially when it comes to waking up from hibernation. In retrospect this should be expected as encryption places demands on the CPU, and older laptops mean slower CPUs hence that becomes a bottleneck.

There are SSDs that support hardware based encryption too. These are usually $20-$30 more than the other SSDs but the advantage is that the encryption task is offloaded to the controller of the SSD freeing up your computer CPU and avoiding a performance hit.

There seem to be three varieties of SSDs that support hardware based encryption: (1) also known as Self Encrypting Drives, these are based on an OPAL standard developed by the TCG wherein the drive itself has an engine to encrypt everything written to it (hence the name “self encrypting” drive); (2) those where the hard disk enclosure has a smaller regular (non-encrypted) hard drive, accompanied by an encryptor chip that takes care of encryption; and (3) there is a separate encryptor chip placed between the computer and regular (non-encrypted) hard drive that takes care of the encryption.

Self Encrypting Drives seem to be the popular ones. The Crucial M500, which I used for one of my laptops, is such a drive. SEDs have a 256-bit AES encryption engine that encrypts everything written to the drive by default. On it’s own that’s useless though as there’s no password protecting the keys used to encrypt everything, so anyone can read data from the drive and it will happily decrypt too. To use the drive effectively one needs additional software that support the OPAL standard and which will interact with the drive to password protect the keys. There are many third party software for this but sadly most of them are for enterprises (so the software is very expensive and you can’t get more details until you contact the sales department etc). This is a pity, I wish drive manufacturers included such software for an additional reasonable cost as without such software the hardware-based encryption feature of such SSDs is useless.

From one of the Amazon reviews for the M500 I learnt that a user had good experiences using WinMagic’s SecureDoc. That software too is pricey (nearly as much as the SSD itself!) and I have two laptops so buying two copies of the software is not worth it.

There exists a “free” alternative though. If you are on Windows 8 (or Server 2012) and your SSD is OPAL 2 compliant (the M500 is) and your computer is UEFI 2.3.1 based and has the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL defined (and has the Compatibility Support Module (CSM) disabled in UEFI, and always boots natively from UEFI) then you can use BitLocker (which is a part of Windows 8) will encrypt the drive using its hardware-based encryption. (If you want to be doubly sure you can use the BitLocker PowerShell cmdlets to specify you want hardware encryption and later use the manage-bde -status command to verify hardware-based encryption is in use).

The UEFI requirement is only if the SSD is used as a startup drive though (i.e. the OS is installed on it and boots up from it). If you are using the SSD as an additional drive, then BitLocker can be used to for hardware-based encryption.

In my case, however, the SSD is a startup drive but neither computer had UEFI. Nor did the computer manufacturer have any updates for flashing UEFI. It does not seem possible to upgrade BIOS to UEFI either (at least not easily and there could be hardware limitations that prevent you from doing so too). So although I have an SED I can’t use BitLocker to use its hardware-based encryption features. Bummer!

For more info on SEDs: check out this KB article from Crucial on the encryption features of the M500; this forum post which clarifies hardware-based encryption does not work with Linux and also mentions SecureDoc; this and this article from AnandTech; this very informative article on how SEDs work.

UPDATE: Turns out I am not entirely correct in saying that SEDs are based on OPAL standards. Not all SEDs are based on OPAL standards. For instance, SSDs from Intel and Samsung (Intel SSD 520 Series, Samsung 840 Series) are SEDs but use a password you specify in the BIOS for hardware encryption. These SSDs require BIOS support for the password – known as ATA password. The drives always encrypt their data and once you specify a BIOS ATA password they keys are encrypted using a hash of this ATA password, thus locking the data (also see this FAQ and whitepaper in case the previous link is broken). (Also, if you are interested in ATA passwords and have a motherboard that does not support ATA passwords (not the same as BIOS passwords!) this forum post might be helpful).

See this page too from Softex.

UPDATE 2: Softex SecureDrive seems to be a reasonably priced product for OPAL SED drives. It’s about US$75 per license, which while high is still less that the US$100+ prices of others.