Enabling BitLocker for the First Time

Full Disk Encryption

Since the release of Windows 2000, you have been able to encrypt files stored on your computer's hard disk with EFS. But there are some issues with EFS that prevent it from being the magic bullet to solve the laptop security problem.

EFS requires user interaction to specify which files to encrypt. Although the new group policy settings in Vista allow an administrator to specify that some folders, such as a user's Documents folder, will be encrypted, there are still a great many other places where sensitive data could be stored, such as places like Temporary Internet Files or automatically created backup copies of word processing files. It's very labor intensive to find all of these locations and ensure they are encrypted. BitLocker, conversely, simply encrypts every data sector on the volume. That's why it's called "full disk encryption" or "full volume encryption."

Sometimes, technical terms get thrown around a bit too loosely, so let's agree to use a few of them consistently.

A partition is a structure on a physical disk, usually defined in the disk's partition table (a specific data structure stored in the first few sectors of a disk). A volume is a logical structure in Windows made up of one or more partitions. In Vista, as with other versions of Windows, the volume is what gets a drive letter assigned to it, so what we normally call "drive C:" is a volume.

The volume manager is a Windows component that organizes the partitions into volumes, and the rest of the Windows system does not deal with partitions directly. In almost all cases in Vista, a volume and a partition will have a one-to-one relationship, and this is called a simple volume. Servers often have other types of volumes. For example, one volume could be stored on several partitions for redundancy or performance, such as in a RAID array. Bit-Locker works at the volume level, not the partition level. In Vista, BitLocker works with simple volumes.

One partition on the disk is marked as the active partition. The active partition is the partition from which the computer boots, or as Microsoft describes it, "The system partition refers to the disk volume that contains the hardware-specific files that are needed to start Windows." Ever since Windows NT was released, this has caused some confusion: the active partition is called the system partition, and the partition on which Windows is installed is called the boot partition, or "the disk volume that contains the Windows operating system files (by default, in the Windows\ folder) and its support files (by default in the Windows\System32 folder)." The "easy" way to remember this is that "you boot from the system partition, and the system is installed on the boot partition." In many cases-well, probably most cases of client installations before Vista-the boot partition and the system partition are the same. (For more information, see http://www.support.microsoft.com/kb/314470/.)

In most of the Windows Vista documentation you will see the terms Windows OS Volume, which means the former boot partition and is the volume on which windows has been installed; and active partition, the former system partition, and it is the partition from which the computer will boot. You can have multiple Windows OS volumes, if you have multiple operating systems installed, but you can only ever have one active partition at a time.

The terms disk and drive can mean different things depending on context. Drive can refer to a physical unit ("the hard drive failed") or a logical structure ("drive C:"). I try to avoid this the term except to use it when referring to a volume that has a drive letter assigned. End users, however, are probably much more likely to use the word "drive" than the word "volume." And, of course, BitLocker Drive Encryption has the word "drive" in its name.

A sector is the smallest addressable block of space on a disk. Almost all sectors today are 512 bytes in size, but as disks keep growing, sector sizes will likely climb. A cluster is a group of sectors, and is the smallest block of space that can be assigned to a file. Cluster sizes can vary according to the capacity of your volume, but since nobody I know uses 2 GB (or smaller) hard drives anymore, you can expect most volumes today (2006) to have a cluster size of 4,096 bytes (this is 4 KB, or 8 sectors). This means that if you want to write a 1 byte file, the file will still be assigned an entire cluster, and 4 KB of disk space will be used. (For more information, see http://www.support.microsoft.com/kb/314878/.)

The first sector of a volume is called the boot sector and contains code that can be used to start the computer if that volume is also the active partition.

The point of all this defining is to help explain what is not encrypted by BitLocker and how the BitLocker encryption algorithm works.

So what's not encrypted? First of all, to use BitLocker you will need two volumes. The active partition will be a smaller, unencrypted volume that is used to start the computer. Since this is not encrypted, you should avoid storing any confidential information on this volume.

Tip 

In fact, administrators should set NTFS permissions so that users cannot write to this volume at all.

The second volume is the Windows OS volumes, with Vista installed. The Windows OS volume will be completely encrypted by BitLocker except for the following:

• The boot sector

• Any bad sectors (sectors marked as unreadable by the file system)

• The volume metadata

The volume metadata is a data structure that BitLocker uses to store encrypted versions of the keys needed to decrypt the data, and some other statistical and reference information about the volume. The BitLocker system writes three redundant copies of the metadata to ensure that if one copy (or even two!) develops a bad sector, you can still get your data from the disk. A BitLocker-encrypted volume, then, would look something like Figure 5.1.

Figure 5.1: Typical layout of a BitLocker-encrypted volume

Although the metadata sectors are not encrypted as a whole, any keys stored in the meta-data are strongly encrypted with other keys. More about that in a bit.

This architecture means that anything and everything written to the disk is encrypted by BitLocker. In some cases, this means things would even be encrypted twice. For example, if you encrypt a file with EFS, it is encrypted by EFS before being encrypted again by BitLocker.

To achieve this complete encryption, BitLocker uses a filter driver. A filter driver is a kernel-mode software component that communicates with the volume manager and the file system. A simplified view of the BitLocker filter driver architecture looks like Figure 5.2.

Figure 5.2: BitLocker filter driver overview

In Windows Vista, you cannot talk to the Windows OS volume without BitLocker knowing about it.

Encryption Algorithm

Up to now, I have simply said that the data is "encrypted" without explaining in much more detail. Let's look a bit more at how the encryption is done.

In 2006, one of the designers of BitLocker, Niels Ferguson, wrote a detailed paper about how the team sought and selected the best encryption algorithm for BitLocker, given the constraints imposed. Microsoft published his paper and you can download the complete PDF here: http://www.microsoft.com/downloads/details.aspx?FamilyID=&DisplayLang=en.

The encryption algorithm selected had to meet these goals:

• It encrypts and decrypts sectors that are 512 bytes, but also larger sectors (which will be likely during the lifetime of Vista).

• It must be able to implement different algorithms for different sectors.

• It protects confidentiality of the plaintext.

• It is fast enough to be nearly unnoticeable to users.

• It has been validated by public scrutiny and is generally considered safe.

• An attacker cannot control or predict any of the plaintext by changing the ciphertext.

And, the resulting ciphertext couldn't occupy more space on the disk (since when you encrypt the whole disk, there is no "extra" space).

In the end, Microsoft decided to use the Advanced Encryption Standard (AES), which is well regarded as one of the most secure and robust encryption algorithms. Microsoft, however, added a few additional pieces to the encryption process.

First, a different key is used for every sector on the disk. One part of the key is derived from the sector number. This makes it easy to create, and it doesn't need to be stored or managed, but not easy to discover from the encrypted data. Second, BitLocker adds a two-pass diffuser prior to the AES encryption. It's hard to explain what a diffuser does without delving deep into the cryptography. Basically, the diffuser, in this case, rearranges the bytes before the AES encryption to remove the possibility that changes made to the plaintext could result in changes to the ciphertext that might help an attacker to break the encryption. In other words, it makes the encryption even stronger.

So, after all is said and done, the resulting encryption algorithm looks something like Figure 5.3.

Figure 5.3: Overview of the BitLocker encryption algorithm

The algorithm is designed to use a 512-bit key, called the full volume encryption key (FVEK). The FVEK is split into two (each part being unique and different from the other). One part is used to derive the sector key, used by the diffuser, and the other part is used for as the AES encryption key. BitLocker is designed to use 256-bit keys for each part, but by default, BitLocker uses 128-bit keys. Longer keys result in higher security but decreased performance. You can configure BitLocker to use the larger key sizes, if desired.

Key Storage

Speaking of keys…where do we get keys and where are they stored? In the preceding section, you learned about two keys, the FVEK and the sector key-but that's just the tip of the iceberg.

We'll start with the easy one: the sector key does not need to be stored. Rather, each time it is needed, it is easily derived, given the FVEK and the sector number of the sector being encrypted or decrypted. There is a good reason to go to all of this trouble. If every sector used the same key, then an attacker could write a large number of identical sectors of known data and try to determine information about the key by seeing what the resulting output looked like. But using the sector keys, this ensures that even identical plaintext data written to different sectors will result in different output ciphertext.

The FVEK is a very, very important key. It's like the master key that can open any door in a large office building. The FVEK is created for each new volume encrypted by BitLocker and is used for every sector that is encrypted. BitLocker stores this key in a handy place: the volume metadata. This means three redundant copies are stored, and that it travels with the encrypted volume. For example, if your motherboard blows up one morning, and you need to remove the disk, the FVEK stays on the disk.

Of course, it won't do to just leave the FVEK lying around in plaintext in the volume meta-data. That would defeat the purpose of encrypting the disk. Instead, the FVEK is encrypted with another key, the volume master key (VMK). So, bear with me…in order to use the FVEK to read the data on the disk, you need to have the VMK.

Where's the VMK?

The VMK is actually also stored in the volume metadata. This is what allows BitLocker, in its default configuration, to start up and access an encrypted volume without any user intervention. Again, the VMK is obviously not just stored in plaintext; it too is encrypted, or in the language of BitLocker, it is protected by one or more key protectors.

In BitLocker, there have to be a number of ways to get the data that is encrypted. An important part of any enterprise-level encryption scheme is planning for the potential of needing to recover data if the normal access to the encryption keys is not available for some reason. For each way to access the data-in normal operation or in recovery after a problem-the VMK is encrypted and stored slightly differently, with a different key protector.

With default settings, BitLocker will create a recovery password and also use the TPM. This will create two key protectors, the "TPM Only" key protector and the "numeric password" key protector. Let's look at the TPM Only key protector.

You may hear someone say that the VMK is "stored in the TPM," but that is not correct. As far as the TPM is concerned, BitLocker is just another application. BitLocker presents a "blob" of data (that contains the VMK) to the TPM, and asks the TPM to "wrap" it (by encrypting it with the TPM's SRK), and seal it (by making decryption available only when values stored in the PCRs match). The TPM then returns an encrypted, sealed, and wrapped version of the data, and that is what BitLocker stores in the volume metadata. In this case, it is both wrapped and sealed by the TPM.

In other words, the VMK is protected by the TPM. The TPM is the bouncer at the exclusive club. Nobody gets in without his say-so; but when you show the right VIP guest pass (the integrity check), he simply steps aside.

Whenever talking about recovering encrypted data, you need to talk about how to get it back if something goes wrong. In BitLocker terms, this is called recovery. To facilitate recovery, a second key protector is used. In the graphical user interface, this is called a recovery password, although there are two variations used internally: a numerical recovery password or a binary recovery key. Although a "recovery key" and a "recovery password" have slightly different characteristics, the BitLocker user interface only uses "recovery password" to avoid confusing end users. You're not confused, are you?

When you enable BitLocker, you must create a recovery password, which can be stored in Active Directory Domain Services (AD DS), on a USB flash memory device, in a text file, or printed. This recovery password is your emergency "get out of encryption jail" card, and can be used to regain access to the disk no matter what the state of the TPM, or even if a PIN has been set and forgotten. Recovery is discussed in detail a bit later in this chapter.

If you choose to save the recovery password to a folder, or to print it, or if Group Policy is used to store just the recovery password in AD DS, a recovery password that uses only the digits 0 to 9 is created and used as a key protector. If you choose the menu option to save it on a USB drive, or if Group Policy is used to store a full recovery package in AD DS, then the binary version with the full 256 bits is created and used as a key protector. Since the user (by default) must choose at least one method of storing a recovery key, at least one of these key protectors will appear. Depending on the user's choices, you can have both versions.

In any case, another encrypted copy of the VMK is stored in the volume metadata, encrypted ("protected") by the recovery password or recovery key. See later in the chapter for a discussion about using the recovery password. Figure 5.4 shows these relationships.

Figure 5.4: Default key protectors

You may have wondered why Microsoft bothers with the VMK. It would have been possible to just to apply the key protectors to the FVEK and store it, but that would run the risk of needing to perform some computationally expensive operations a little too frequently. Instead, the VMK provides a level of abstraction that is essential to making it efficient to keep data encrypted on the disk. Here's what I mean by "a level of abstraction": one of the basic principles of security and encryption is that if a key is compromised, everything that was encrypted with it must be re-encrypted.

Imagine a situation where someone loses a recovery password, and they are worried that it might fall into the wrong hands. If the recovery key unlocked the FVEK, you would want to create a new FVEK and re-encrypt the data. But, think about that for a minute. How big is your hard drive? How long does decrypting it and re-encrypting it take? Re-encrypting the data is an "expensive" operation, so we'd like to avoid it. By using an intermediary key (in this case, the VMK), it reduces the likelihood that the drive would need to be re-encrypted.

In fact, it also opens up some interesting features. Sometimes, you might want to disable BitLocker. It would be a rather time-consuming task to decrypt the drive, do whatever you wanted to do, and then re-encrypt the drive. Instead, you can turn off BitLocker temporarily.

In this case, the VMK is encrypted with a new key, and that new key is simply written to the volume metadata in the clear. (This key, cleverly enough, is called a "clear key.") So, to access the data in this case, the clear key is easily read (no TPM, user input, or validation required), and used to decrypt the FVEK. This is still a type of key protector, although explicitly designed to not "protect" access to the data.

When you reenable BitLocker, a new VMK is generated, the clear key protector is deleted, and the other key protectors (such as the TPM and the recovery password) are reapplied to the new VMK, including resealing with the TPM. This means that the data did not have to be re-encrypted, and the user did not have to replace recovery passwords, or, for example, learn a new PIN. Abstraction can be your friend.

Note 

Yes, there is a slight risk that the keys could be compromised if an untrusted person gained access to the computer while a clear key is in effect. Therefore using a clear key-or "disabling" BitLocker without decrypting-and then reenabling the original keys is not recommended in high-security environments. It's also not a very secure idea to leave BitLocker in the Disabled state-with a clear key-for long periods of time.

You might want to disable BitLocker like this if you were deliberately making changes to your computer that would otherwise invalidate the signatures stored in the TPM PCRs, such as upgrading to a new motherboard, or to move a BitLocker-protected drive from one computer to another.