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. 

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.

Managing BitLocker disks on Server Core

I have a Server Core 2012 that has two BitLocker encrypted disks on it. When I encrypted those disks the server had the full GUI but after I converted to Core there’s obviously no GUI to just double click and be prompted for a password etc. So need to use the command line tools.

There seems to be two ways.

First are the BitLocker command line tools. Manage-bde looks like the most useful command here. Using this one can see the status of all the drives on the machine, lock, unlock, set auto-lock auto-unlock, and also turn on or off BitLocker encryption on a drive.

Typing manage-bde in the command prompt gives you all the options. Each of these options have further switches which you can discover by typing manage-bde <option-name> -?.

To view the status of all drives on the machine:

To unlock an encrypted drive (with drive letter D:) to use with the system:

I use passwords, hence the -pw switch. If you use recovery keys or certificates there are switches for that too. manage-bde prompts for a password and unlocks the drive, mounting it on the specified drive letter.

To set the drive (with drive letter D:) as auto-unlocked:

That’s all. From now on the drive will be automatically unlocked when attached to the system.

The syntax for disabling auto-unlock and locking a drive are pretty obvious from the examples above. The thing to remember is you always specify the manage-bde command followed by a dash switch specifying what you want to do, and after that you specify the drive letter.

There are two other commands: Repair-Bde for repairing corrupted BitLocker encrypted drives and BdeHdCfg for setting up a drive with BitLocker encryption (though it doesn’t seem to be required any more as Manage-Bde includes some of this functionality).

Apart from the BitLocker command line tools you can also manage BitLocker via PowerShell. This is only for Windows 8/ Windows Server 2012 and is available via the BitLocker module (requires RSAT on Windows 8).

To view the available drives on a system and their BitLocker status do:

You can also check the status of a specific drive with the above cmdlet by passing it the drive letter with the -MountPath switch.

To unlock a BitLocker drive (with letter D:) do:

The cmdlet does not prompt for a password. You have to pass it via the -Password switch. You can’t pass the password as plain text either, so have to convert it to a secure string. Use the ConvertTo-SecureString cmdlet for that or just use Read-Host and convert the inputted text to secure string on the fly.

To set auto-unlock on a drive (with letter D:) do:

Similar cmdlets exist for locking and auto-locking drives.

After writing this post I discovered a TechNet article that goes into more detail on the above command line tools and cmdlets. Go check it out.