Big Changes in BitLocker

If you use Windows Vista Enterprise or Ultimate, or any version of Windows Server 2008, you may have heard about a feature called BitLocker Drive Encryption (BDE). This awesome feature will enable you to encrypt the operating system volume. However, in Vista RTM, Microsoft doesn't make it very apparent how to encrypt additional volumes. In Vista SP-1 and Server 2008, you can encrypt data volumes through the UI.

Of course, if you're a fan of the command prompt, the %SystemRoot%\system32\manage-bde.wsf file gave you all the commands necessary to manage your BitLocker volumes.

Or, you could get your hot little hands on the BDE WMI object model and write your own UI in Visual Studio 2008. I went with this approach.

My first blog post talked about building this tool and my need to learn where BitLocker policy settings were stored in the Registry. Well, BDE in Windows 7 is GREATLY expanded.

Microsoft has introduced a bunch of new policy settings, with backwards compatibility to Vista/Server 2008. But there are a ton of new settings for "Windows 7 family."

They've pretty much broken these up into three groups: system (OS) volume, fixed data volumes and removable data volumes. So you can get really granular with how BitLocker behaves with various volumes, whether they're hard drives inside the computer or removable media, such as flash drives.

Windows 7 BDE includes something called BitLocker To Go, which gives great flexibility in the encryption of removable volumes, including policies on whether or not to allow read/write access to unencrypted media as well as read/write access to BDE-encrypted media from another organization (this piece made possible by two new policy settings: primary BitLocker identifier and secondary BitLocker identifier).

I think Microsoft scored big with BitLocker. Now I think they made it better and more flexibile.

Security is everyone's responsibility. If Microsoft really wants to make this a winner, they will include BitLocker with all versions of Windows 7, not just Enterprise/Ultimate.

~M

BitLocker Registry Keys

I wrote a UI that enables me to easily manage all of my BitLocker encrypted drives. Even with Windows Vista SP-1 (or Server 2008), which has a better BitLocker UI that allows you to manage hard drives beyond the system drive, you still can't easily encrypt non-hard drives, like flash drives.

Basically, if you can format the file system to NTFS, you can probably encrypt it with BitLocker. I've tested out hard drives and flash drives, but not other devices like digital media cards (SD, Compact Flash). Anyhow, I digress...

One thing I found was that there is ZERO good documentation on where BitLocker's configuration is stored. Sure, if you fire up MMC and load the Group Policy Object Editor snap-in, you can configure BitLocker's settings, but sometimes you get policy pushed down to you from a domain controller. Domain policy supercedes local policy, and you can run Resultant Set of Policy (RSoP.msc) to see that configuration.

But what if you want to programmatically check the configuration? Where exactly is this information stored? Well, today is your lucky day! I've checked all of these out and I think they are correct. I tinkered with various settings and checked the Registry after each change to see what fields are available, what changes, etc.

CAUTION: Always use the Group Policy Object Editor to make your changes to BitLocker's configuration. Do NOT make changes directly to the Registry. These fields are provided for your reference. In my case, I use them to make available or hide certain options in the UI.

All of the BitLocker keys can be found in HKEY_LOCAL_MACHINE (HKLM).

Registry Location: HKLM\SOFTWARE\Policies\Microsoft\FVE

Key Backup to Active Directory Domain Services (3 entries)
Name: RequireActiveDirectoryBackup
Type: REG_DWORD
Values: 0x0, 0x1 or nonexistent
Explanation: 0x1 requires a key backup; 0x0 makes it optional. Nonexistent means the policy is not enabled.

Name: ActiveDirectoryBackup
Type: REG_DWORD
Values: 0x0, 0x1 or nonexistent
Explanation: 0x1 backs up the key to AD; 0x0 doesn't back it up. Nonexistent means the policy is not enabled.

Name: ActiveDirectoryInfoToStore
Type: REG_DWORD
Values: 0x0, 0x1
Explanation: 0x0 backs up only passwords; 0x1 backs up both passwords and key packages. Nonexistent means the policy is not enabled; nothing will be backed up.


Configure Recovery Folder
Name: DefaultRecoveryFolderPath
Type: REG_SZ
Values: Any valid physical drive path or UNC location
Explanation: Configures the path presented to the user as a default location to save the recovery password. If nonexistent (not configured), the top-level folder view is displayed for the user to choose a path.


Configure Recovery Options
Name: UseRecoveryDrive
Type: REG_DWORD
Values: 0x0, 0x1 or nonexistent
Explanation: 0x0 prohibits the user from generating a 256-bit recovery key (BEK file); 0x1 requires a BEK. Nonexistent means the policy is not configured, which makes the option of a BEK available to the user, but it's not required.

Name: UseRecoveryPassword
Type: REG_DWORD
Values: 0x0, 0x1 or nonexistent
Explanation: 0x0 prohibits the user from generating or printing a 48-digit recovery password; 0x1 requires a password. Nonexistent means the policy is not configured, which makes the option of a password available to the user, but it's not required.


Enable Advanced Startup Options
Name: EnableNonTPM
Type: REG_DWORD
Values: 0x0, 0x1 or nonexistent
Explanation: 0x1 is the only value that allows encryption of the system drive on a computer without a TPM. If 0x0 or nonexistent (the latter being "not configured"), a TPM is required to encrypt the system drive.

Name: UsePIN
Type: REG_DWORD
Values: 0x0, 0x1, 0x2 or nonexistent
Explanation: Controls whether or not the user can create a PIN for use in unlocking the system drive at boot time. Mutually exclusive with UsePartialEncryptionKey. 0x0 disallows a PIN; 0x1 requires it; 0x2 allows the user to create or skip it. Nonexistent (not configured) causes only basic steps to be displayed to users on computers with a TPM; no additional startup key or PIN can be created. If set to 0x1, UsePartialEncryptionKey MUST be 0x0. Otherwise a policy error occurs.

Name: UsePartialEncryptionKey
Type: REG_DWORD
Values: 0x0, 0x1, 0x2 or nonexistent
Explanation: Controls whether or not the user can create a PIN for use in unlocking the system drive at boot time. Mutually exclusive with UsePIN. 0x0 disallows a key; 0x1 requires it; 0x2 allows the user to create or skip it. Nonexistent (not configured) causes only basic steps to be displayed to users on computers with a TPM; no additional startup key or PIN can be created. If set to 0x1, UsePIN MUST be 0x0. Otherwise a policy error occurs.


Encryption Method
Name: EncryptionMethod
Type: REG_DWORD
Values: 0x0, 0x1, 0x2, 0x3, 0x4 or nonexistent
Explanation: Controls which encryption method is used to encrypt a drive. When set to 0x0 or nonexistent, the default of AES 128-bit with Diffuser is used, but the user is allowed to select a different encryption method via a UI tool or command prompt. When set to 0x1 through 0x4, the user may NOT select a different method (they get an error if they try). The methods for 0x1 through 0x4 are: 0x1 - AES 128-bit with Diffuser; 0x2 - AES 256-bit with Diffuser; 0x3 - AES 128-bit; 0x4 - AES 256-bit.


Prevent Memory Overwrite on Reboot
Name: MorBehavior
Type: REG_DWORD
Values: 0x0, 0x1 or nonexistent
Explanation: This setting affects reboot performance at the risk of exposing BitLocker secrets. When nonexistent (not configured) or set to 0x0, memory is overwritten at reboot to clear BitLocker secrets. Setting to 0x1 (not recommended) prevents the memory overwrite, which increases the risk of exposing BitLocker secrets.


That's it for now. I hope you find this information useful!

~M