When Microsoft introduced Windows Vista, one of its most anxiously anticipated features was its encryption capability called BitLocker. Many mistakenly refer to BitLocker as whole-disk encryption, but the more accurate description is full-volume encryption.
The distinction is important. A single physical disk can be partitioned into multiple volumes. Whole-disk encryption would encrypt all of the data on the entire physical disk drive, while full-volume encryption protects each volume or partition separately. BitLocker might be encrypting the volume designated as the C: drive, but the data on other volumes may still be unencrypted.
The initial release of BitLocker encrypted only the Windows Vista boot volume. Granted, that is better than nothing, but for larger hard drives with multiple volumes it also left a significant amount of data unprotected. With the release of Windows Server 2008 and Windows Vista SP1, Microsoft expanded the scope of BitLocker so that any of the volumes could be encrypted. The upcoming Windows 7 operating system broadens the reach of BitLocker even farther by including the ability to encrypt data on removable media such as USB flash drives.
How does Bitlocker work?
BitLocker requires that a small unencrypted partition be created which contains core operating system files that Windows needs to start the boot process. Microsoft created the BitLocker Drive Preparation tool to automate the creation of the second partition and the migration of the files necessary to create the split-load configuration that BitLocker relies on to boot the operating system.
Once the drive is properly partitioned and the data is encrypted with BitLocker, there is a process the system follows to boot the system and decrypt the data so you can use it. As with any encryption process, it relies on keys.
The sectors of data on the drive are encrypted using the FVEK (full-volume encryption key). However, the FVEK is stored locally in encrypted form and the user never interacts with or uses the FVEK directly. The key that users work with is the VMK (volume master key). The VMK is used to encrypt and decrypt the FVEK which, in turn, encrypts and decrypts the actual data sectors.
BitLocker relies on TPM to authenticate system hardware
By default, BitLocker relies on a TPM (Trusted Platform Module) chip. The TPM is a chip wired to the motherboard which can create a unique hash signature related to the hardware configuration of the system and securely store the encryption key. The TPM provides a virtually incorruptible method of authenticating the system hardware.
By itself, the TPM would not prevent an unauthorized user from accessing a BitLocker encrypted volume. In TPM-only mode, an attacker can still cold boot the system, and as long as the TPM could validate the hardware signature hash, BitLocker would decrypt the data and allow the system to boot. For that reason, an additional authentication factor should be used along with the TPM. The available options for BitLocker include:
- TPM only
- TPM plus a PIN
- TPM plus a USB key
- TPM plus a PIN and a USB key
- USB key only
The last option, USB key only, is typically only used in situations where BitLocker is implemented on a system that is not equipped with a TPM chip. The option to enable BitLocker without a TPM has to be configured by modifying the security policy settings.
The USB key only and the TPM plus a PIN and USB key options have additional cost and administrative overhead in that USB keys must be provided and maintained. They are also easy to lose or misplace which could lead to an increase in support desk calls to retrieve lost encryption keys and gain access to BitLocker encrypted systems.
How to manage BitLocker keys
One of the most important aspects for enterprises to consider before encrypting data with BitLocker is how to store and manage recovery keys. In the event that a user forgets a PIN, loses a USB key or is unable to access their BitLocker-encrypted system for any reason, the support desk must have the ability to help them recover their data and gain access to their system.
Users can be supplied with a USB key containing the BitLocker recovery key to use as a backup when the need arises. For deployments that already use a USB key for BitLocker authentication, it would be an additional or backup USB key to use in the event of the primary USB key being lost or stolen. The downfall of this system is that the backup USB key would most likely be stored with the laptop and a thief that steals the laptop will also have the keys.
An alternate solution is to configure BitLocker to store a recovery key in Active Directory. An administrator can configure Group Policy to automatically generate a recovery key and store it in Active Directory when BitLocker is enabled. It is also possible to prevent BitLocker from encrypting any data until the recovery key is successfully backed up to Active Directory.
Tony Bradley is the director of security for Evangelyze Communications, and a Microsoft MVP in Windows security for the past three years.
Send comments on this technical tip to editor@searchmidmarketsecurity.com.
