Mounting frustration with PGP Whole Disk Encryption has me revisiting BitLocker options this week. We last touched on this subject back in the early days of Vista. It appears that enough has changed with Windows 7 that we need to do some policy updates.
First off, I discovered that the BitLocker system volume encryption wizard was not presenting me with startup PIN or startup key options. Further, it also was not backing up recovery key data to Active Directory, as we originally designed it to under Vista. Why? Because Vista BitLocker policies do not apply to Windows 7! A quick step through the “Windows 7″-specific settings in Computer->Policies->Administrative Templates->Windows Components->BitLocker Drive Encryption (and the child “Operating System Drives” settings), and we are back in action.
Next, I noticed new settings related to smart cards in the new Group Policy settings. Does BitLocker now support storage of drive encryption keys on a Smart Card? No… not for system volumes anyway. Still, I was intrigued by option for removable and non-system volumes, and decided to try encrypting my office eSATA drive using BitLocker and a Smart Card certificate.
Microsoft provides the following information on certificate template requirements for BitLocker:
Madeningly, they specify that you should provide the ‘Enhanced Key Usage OID value of 184.108.40.206.4.1.3220.127.116.11′, if you are going to specify an OID. They also say that your “key usage attribute” should be one of three possible options with names like “CERT_DATA_ENCIPHERMENT_KEY_USAGE
“. The problem with this guidance is that the Certificate Template Manager MMC snapin does not expose any such options, and I cannot find docmentation for management of certificate templates using “certutil.exe”, or any other available command line utilities. Am I supposed to use ADSI edit to do all my certificate management these days? Sheesh.
Some googling determined the following:
- Enhanced Key Usage, or EKU, is labeled “Application Policies” in the Certificate Template MMC, and they are exposed under the “Extensions” tab of a template properties dialog box.
- OID info is not displayed in the list of Application Policies. However, OID 18.104.22.168.4.1.322.214.171.124 maps to the friendly name “BitLocker Drive Encryption”. Select this policy and add it as a cirtical extension, or just leave the Application Policies list empty. Note that you will need to have the “BitLocker Drive Encryption” feature activated on any system from which you you are editing the Certificate Template (I am indebted to DXter for this post which led me on the path to solving this little mystery).
- The “key usage attribute” referred to in the BitLocker documentation also is exposed in the “Extensions” tab of the Certificate Template properties dialog. In this case, we will be looking at the “Key Usage” extension. Selecting a value of “Allow key exchange only with key encryption (key encipherment)” appears to work.
- Under the “Request Handling” tab, I also specified that the certificate will be used for “Encryption”, and not “smartcard logon”, since I don’t want to use this same cert for Smart card logon… perhaps that will change later on. We also needed to enforce the use of the “Microsoft Smart Card Key Storage Provider” under the “Cryptography” tab, since we want to generate the certificate key on the smart card. (Note that you need CNG-compliant cards to use this option. CNG cards are the way to go!)