IgNiTeD SoUL

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.

To get the absolute best security with Windows Vista, run one of the x64 versions of

the operating system.That’s because the x64 versions of

Windows Vista include a few unique security features that are not available or as

effective in the 32-bit versions of the operating system. These include:

• A new feature called Address Space Layout Randomization (ASLR) that randomly

loads key system files in memory, making them harder to attack remotely.

• A hardware-backed version of Data Execution Protection (DEP) that helps prevent

buffer overflow-based attacks.

• x64 drivers must be digitally signed, which suggests (but doesn’t ensure) that

x64 drivers will be more stable and secure than 32-bit drivers, which are often

the cause of instability issues in Windows.

Of course, x64 versions of Windows Vista have their own compatibility issues, both

with software and hardware. The tradeoff is yours to make: Better security and reliability

or compatibility.