Advances in BitLocker Drive Encryption
At a Glance:
- Enhancements to BitLocker
- Getting and installing BitLocker
- Using BitLocker on a server
- Considerations for complete data protection
In last year's security issue of TechNet Magazine, I took you on a short tour of some of the features of Windows BitLocker Drive Encryption in order to show how it was implemented in the initial release of Windows Vista. Now, with the release of Service Pack 1 for
Windows Vista® and the new Windows Server® 2008 operating system, the time has come to revisit BitLocker®.
In this article, I will discuss some of the changes found in the latest version, give an overview of how to install and use BitLocker on a server, and touch on some recently reported considerations to bear in mind. (By the way, to read last year's article, "Keys to Protecting Data with BitLocker Drive Encryption," go to technet.microsoft.com/magazine/cc138009.aspx.)
The changes introduced with this release of BitLocker bring new flexibility without altering any basic operations. The changes I'll review are support for data volumes; allowing three-factor authentication for machine access; support for Unified Extensible Firmware Interface (UEFI), the new industry-standard firmware for 64-bit systems; better protection against cryptographic attacks on volume metadata; and increased use of the Trusted Platform Module (TPM).
When Windows Vista was first released, the BitLocker control panel only allowed you to turn on encryption for the Windows® operating system volume (usually the C: drive). For many consumers, this was perfectly adequate, since home computers are typically configured with all of the user's data and programs stored on the same volume as the operating system. In businesses, though, and certainly on servers, this is often not the case. As a result, one of the most common requests we heard from customers was for the ability to encrypt data volumes—volumes other than the OS volume that are installed in the computer (note that BitLocker is not designed to encrypt removable media).
As you can see in Figure 1, I have three usable volumes on this computer. (I actually have four if you include the small active partition used for startup.) My operating system is installed on drive C: (this is actually shown by the Windows "flag" on the icon), and two data volumes are also present, E: and P:. The P: volume has already been encrypted with BitLocker and is currently locked. The E: volume is not yet encrypted. In Windows Vista SP1 and Windows Server 2008, I can encrypt and unlock these data volumes from the BitLocker Control Panel applet.
Figure 1** The Bitlocker interface **(Click the image for a larger view)
If your operating system volume is encrypted with BitLocker, the default behavior is that encrypted data volumes are unlocked whenever the operating system volume is unlocked. If you use the control panel to unlock a data volume, you can see this option presented as a checkbox, as in Figure 2.
Figure 2** Saving keys for autounlock **(Click the image for a larger view)
To turn a data volume's "autounlock" on or off, use the manage-bde.wsf command-line tool. Manage-bde.wsf is a powerful script included with Windows that uses the underlying Windows Management Instrumentation (WMI) providers installed with BitLocker.
For example, to mark data volume P: so that it must be manually unlocked, use the following command:
manage-bde.wsf –autounlock –disable P:
To turn autounlock back on for P:, use:
manage-bde.wsf –autounlock –enable P:
The BitLocker control panel does not expose everything you can do with BitLocker and data volumes, so you should use the -? option to explore the manage-bde.wsf commands. The manage-bde.wsf syntax is also included in the "Windows BitLocker Drive Encryption Design Guide" and the "Windows BitLocker Deployment Guide," which are available from the Microsoft Download Center at go.microsoft.com/fwlink/?LinkId=115215.
Customers also wanted to be able to use additional authentication factors with BitLocker. BitLocker uses the TPM chip in your computer in order to verify the integrity of the platform—in other words, to determine that the early startup components, including the BIOS, have not been tampered with or corrupted. However, since the release of Windows Vista, you can now also require either a PIN or the presence of a USB flash drive containing a key created when you enabled BitLocker.
With Windows Server 2008 and Windows Vista SP1, you can now combine all three. The TPM continues to verify platform integrity, the USB key represents "something you have," and the PIN represents "something you know." This configuration provides very strong protection against unauthorized users being able to start the computer and unlock BitLocker-protected drives.
As with many things in security, however, this represents a trade-off. Obviously, when BitLocker is configured this way, a computer cannot automatically restart. In the case of a server, for example, you must decide which is more important: a seamless restart or higher levels of protection.
With Windows Server 2008 and Windows Vista SP1, support has also been added for computers equipped with a Unified Extensible Firmware Interface (UEFI). UEFI is a specification that represents a modernization of the traditional BIOS used by most computers at startup. For more information about the UEFI specification, please visit www.uefi.org.
When BitLocker detects that the system has been changed, or if a required PIN or USB key is not available at startup, BitLocker enters recovery mode. In recovery, BitLocker-enabled volumes remain locked and a text-mode dialog called the Recovery Console is presented to the user.
To unlock the drive, the user must enter a recovery password (a 48-digit number) either from the keyboard or from a USB flash drive. (When stored on a USB flash drive, the password is sometimes called a recovery key, because it is a binary, not text, format.)
BitLocker uses the recovery password to decrypt the keys stored in the volume metadata—the Volume Master Key (VMK) and then the Full Volume Encryption Key (FVEK)—to unlock the drive. For recovery to be successful, a copy of the recovery password must be available.
Because of this, in addition to storage by the user (such as on a USB flash drive), I highly recommend that you also store the recovery password centrally. The operating system includes functionality for storing recovery passwords in Active Directory® Domain Services (ADDS).
Secrets stored in the volume metadata, such as the VMK, are encrypted and the integrity of the entire volume metadata is cryptographically protected. If BitLocker detects that the volume metadata has been tampered with, it will refuse to use any of the metadata and it won't unlock any protected volumes. Note that the recovery password alone will not unlock a drive in this state.
It is important to stress that this situation only occurs with a deliberate security attack against the computer. If it happens, there's a good chance your computer is already in the hands of an evil-doer and out of your control. It will not arise from a simple unplanned change to the platform or if you forget your PIN.
To unlock the volume, you will need the following three items:
- The recovery password (as text to type in or on a USB flash drive)
- The binary key package that includes encrypted versions of the FVEK and VMK
- The BitLocker Repair Tool
In short, you need to make sure your enterprise always has access to all of these things.
The recovery password can be backed up manually or automatically. I recommend using the Group Policy setting to automatically back up the recovery password to Active Directory Domain Services.
When you configure this setting, as shown in Figure 3, include the option to back up the binary key package. The binary key package includes encrypted versions of the VMK and FVEK, allowing you to use the BitLocker Repair Tool, if necessary.
Figure 3** Configuring Group Policy to include key packages in recovery information **(Click the image for a larger view)
The BitLocker Repair Tool has been designed to help you recover data from damaged disks that are BitLocker-enabled. Note that this is an advanced tool, meant for use by experienced administrators. For more information on the BitLocker Repair Tool, read the Microsoft Knowledge Base article at support.microsoft.com/kb/928201, or watch my webcast, "Microsoft BitLocker in the Enterprise: BitLocker Tools to Make Your Life Easier" (which includes a live demo), at go.microsoft.com/fwlink/?LinkId=114985.
This is a good place to point out that BitLocker does not replace the need to back up your data. If your disk is damaged or has been deliberately attacked, there is no certainty that the BitLocker Repair Tool will be able to recover any, let alone all, of the data.
Broader TPM Usage
Technically, this isn't a BitLocker change, but it's cool enough to be worth mentioning. Prior to SP1, the only part of the Windows OS that made use of TPM was BitLocker, but now the TPM is also used for some other functions as well. For one, when Windows sees that a TPM is available, it uses the TPM as a source of increased entropy when generating random numbers. This improves the quality of all sorts of encryption (and might even make your game play better, too).
However, this also means that not all TPM-related events shown in the Event Viewer are necessarily related to BitLocker. As an IT pro, you want to be aware that other system components—and potentially software from other vendors—can and will make use of the TPM, and therefore will cause events to be logged.
BitLocker in Windows Server 2008
Because of the shared codebase between Windows Vista and Windows Server 2008, the BitLocker changes appearing in SP1 are part and parcel of Windows Server 2008. But why is BitLocker relevant on a server? After all, BitLocker, by design, protects a computer from offline attacks. In other words, BitLocker offers no protection to a running system and servers, of course, are generally expected to be running all the time.
As it turns out, there are occasions where a server, or a hard disk from a server, could be exposed to an offline attack. Even if that never happens, BitLocker can help greatly when it is time to decommission a server or a hard disk, as we'll see. First, let's look at how to get BitLocker installed and running on a server.
Getting and Installing BitLocker
BitLocker is included in all editions of Windows Server 2008, but it is an optional component, or feature, that must be installed from either Server Manager or the command line. BitLocker is implemented, in part, as an NTFS filter driver. Installing this filter driver requires a restart of the computer, so be aware that activating BitLocker on a server will require a reboot. Also, as with Windows Vista, BitLocker requires a split-load configuration, where the active partition used to start the computer remains unencrypted. The BitLocker Drive Preparation tool is available to help you correctly configure your hard disks to support BitLocker if the server has not come pre-configured from the manufacturer. If you are comfortable with hard drive partitioning, however, you can certainly configure the hard disks manually.
To install BitLocker into Windows Server 2008, you can use the Server Manager graphical interface to select BitLocker from the list of features, as shown in Figure 4, or you can use the Server Manager command-line interface, by issuing the command:
Figure 4** Selecting BitLocker in Server Manager **(Click the image for a larger view)
ServerManagerCmd –install BitLocker –restart
When you use Server Manager, it installs BitLocker and the management tools for BitLocker. You can also install the management components without installing BitLocker itself. This avoids the need for the restart since the filter driver is not included. The name of this component is "RSAT-BitLocker."
BitLocker works just fine on computers running the Server Core installation option, but you can't use Server Manager to install BitLocker on Server Core or use the graphical user interface to manage BitLocker on Server Core. Instead, to install the components, use the command-line tools pkgmgr or ocsetup.
Once you have the BitLocker binaries installed and your disks configured in the required split-load configuration, you can enable BitLocker on the OS volume. The BitLocker control panel applet has the same icons and options in Windows Server 2008 as it does in Windows Vista SP1. In order to enable the advanced modes of BitLocker, you will need to adjust the default settings using the Local Policy Editor or a Group Policy Object that applies to the server.
On Server Core, or if you just don't want to use the control panel, you can use manage-bde.wsf to enable BitLocker. To enable BitLocker on drive C:, type
manage-bde.wsf –on C: -RecoveryPassword –RecoveryKey F:\
where C: is the volume to encrypt, and F:\ is a USB key or another volume where a copy of the recovery key will be stored (in binary format). You can also use a UNC path to store the recovery key on a network drive. A recovery password (in numeric text format) will also be generated and displayed. You might wish to add the –skiphardwaretest parameter if you are certain the hardware platform meets all BitLocker requirements. This will save one reboot.
Now, let's discuss some specific scenarios where BitLocker is useful for servers. Bear in mind that, as I mentioned, BitLocker is designed to help protect you against offline attacks—the kind of attacks carried out when Windows is not running.
Branch Offices One of the first and most obvious uses for BitLocker on a server is as part of the Windows Server 2008 branch office strategy. Between one-quarter and one-third of servers are installed in branch offices—that is, offices that may have lower physical security, less access to IT support, and perhaps less connectivity to datacenters. Branch offices are also an attractive target for attacks. In conjunction with features such as read-only domain controllers (RODCs), BitLocker can help protect sensitive data that must be stored in a branch office to be useful, but is not as easily physically secured as it would perhaps be in a datacenter.
This is a good opportunity to give some thought to the right level of protection. Which is more important—preventing unauthorized access to data, or requiring that a server come back up immediately and without intervention? My suggestion is that in many branch offices, it would be acceptable to require the entry of a PIN to restart a server, but that is a decision that each company has to make.
Disks in Shipment It is often necessary to ship data on a hard drive to a faraway location. This may include shipping a single disk, or pre-configuring and shipping an entire server. During shipment, the data on those disks is out of your control and could be copied, lost, or stolen.
To mitigate this risk, enable BitLocker on the volumes in the computer before shipment, then remove all of the key protectors except a recovery key or recovery password. This key or password can be hand-carried separately from the server or even communicated by phone or encrypted e-mail to staff at the receiving end. Once the computer or disk is received, the recovery password is used to unlock the drive. The drive can be left encrypted (add back any other key protectors), or the disk can be fully decrypted after delivery, if desired.
This is a particularly effective way to prestage domain controllers or servers for branch offices.
Theft of a Server As noted in the previous section, there is a very real danger of a server (especially a domain controller) being stolen. Thieves may grab a laptop out of opportunity, but a server might be a carefully chosen target. If BitLocker is configured to require only TPM integrity checking, the stolen server could simply be powered up and booted. In contrast, if the drives in a server are protected with BitLocker and BitLocker is configured in an advanced mode—requiring a USB key, a PIN, or both—it is very difficult for the thieves to get any useful information in any reasonable time frame.
Theft of a Disk Conversely, however, if just a disk is stolen, the TPM still provides a great deal of protection. Only the TPM from the original server can be used to unlock the BitLocker-protected drive, so the disk cannot simply be inserted into another computer and read.
Reduced Exposure By ordering server hardware that includes a TPM chip and using BitLocker platform integrity checking, you increase the defense against some forms of malware. In particular, BitLocker will detect changes made while Windows is offline or changes made to early startup components, especially if malware, such as a rootkit, requires a reboot to install. This is not a total solution, but combined with features such as Windows code integrity and products such as Microsoft® ForefrontTM Client Security, it is another effective layer of defense-in-depth.
Secure Decommissioning One of the most useful scenarios for BitLocker comes at the end of the lifecycle of a server or disk. How often have you heard about servers, or their disks, being disposed of without being properly decommissioned? Did you know that used hard drives sometimes sell for more on auction sites than new ones, as unscrupulous buyers hope to skim useful information from those disks?
Happily, rather than undertaking an expensive and time-consuming process to cleanse the disk of useful data, BitLocker allows another approach. Basically, no information is ever written to the disk in a useful format. Since the encrypted data is unusable, it is a quick, simple step to remove all of the key information. After that, it doesn't matter what happens to the disk hardware—it can be sold, recycled, repurposed, or whatever without the fear that the data could fall into the wrong hands.
In Windows Vista and Windows Server 2008, the format command was updated to wipe the BitLocker keys, including multiple overwrites. Now you have a simple and effective way to decommission a drive.
As I write this, admittedly several weeks before you get to hold the publication, a number of recent articles, papers and news reports have discussed some interesting hardware characteristics and how they affect BitLocker, other Windows security features, and other encryption products from various vendors. I'd like to take a moment to address some of the findings.
One such item was published by researchers at Princeton University who demonstrated (very effectively!) a trait of modern computer memory sometimes termed "DRAM remanence" (available at citp.princeton.edu/pub/coldboot.pdf). In simple terms, the content of computer memory can be accessed for some period of time after power is removed from the memory. BitLocker, of course, keeps keys to decrypt data in memory while Windows is running, and the concern is that the keys could be acquired by unauthorized users.
Another demonstration by Adam Boileau (security-assessment.com/files/presentations/ab_firewire_rux2k6-final.pdf) showed how IEEE 1394 (often called FireWire) allows direct memory access (DMA), which can be used to acquire secrets from Windows, such as passwords or decryption keys. What's interesting about this is that DMA is almost the point of 1394; it's not a flaw, but rather what Firewire is designed to do.
What both of these attacks have in common, though, is that they require physical access to a running (or at least a very recently running) computer. BitLocker is not designed to protect against online attacks, and it does not eliminate the need for some amount of physical security. Proper defense-in-depth requires using a number of tools and features, creating an environment of physical security, outlining essential corporate policies and continually educating users.
As well, these are not new discoveries. They have been known about for some time, and, in fact, are discussed in the Microsoft® Data Encryption Toolkit (DET). The risk analysis provided in the DET is intended to help customers balance security with usability, and with the cost of implementation and management. This is no small point. We believe that educated customers are best suited to make decisions about the trade-offs of security, usability, and cost.
In addition to the DET, some of my colleagues have provided some excellent commentary and guidance. First, Russ Humphries discussed security trade-offs in the context of DRAM remanence in his blog entry at go.microsoft.com/fwlink/?LinkId=115217. Furthermore, Douglas MacIver wrote about additional specific configurations steps and countermeasures that you can take today, on the System Integrity (SI) team blog at go.microsoft.com/fwlink/?LinkId=115218. I highly recommend taking the time to read both of these helpful blog entries. You should also read the DET.
Key among these recommendations is to use an advanced mode (that is, one that requires a USB key or PIN) and not to leave a computer unattended in sleep mode (use hibernate instead).
BitLocker remains one the most useful features of Windows Vista. With the release of SP1, it has been enhanced in direct response to customer feedback to enable more scenarios and meet a wider range of needs for data protection. Expanding that data-at-rest protection into Windows Server 2008 gives you more ways to protect data and maintain compliance whether that data is stored on servers or client workstations, in the datacenter, the branch office, or with a mobile worker.
Byron Hynes is an Enterprise Technology Strategist with the Microsoft Enterprise and Partner Group (EPG), focusing on security features and products. Prior to joining EPG, he worked in the Windows Server Division and closely with BitLocker (System Integrity) since 2005. Your comments and questions are welcome. Grab his attention at Tech•Ed 2008, or send an e-mail to firstname.lastname@example.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.