Freigeben über

BitLocker Drive Encryption in Windows Vista

  • Artikel

Applies To: Windows Server 2008

Windows BitLocker™ Drive Encryption (BitLocker) is a security feature in the Windows Vista® and Windows Server® 2008 operating systems that can provide protection for the operating system on your computer and data stored on the operating system volume. In Windows Server 2008, BitLocker protection can be extended to volumes used for data storage as well.

What does Windows BitLocker Drive Encryption do?

BitLocker performs two functions:

  • BitLocker encrypts all data stored on the Windows operating system volume (and configured data volumes). This includes the Windows operating system, hibernation and paging files, applications, and data used by applications.

  • BitLocker is configured by default to use a Trusted Platform Module (TPM) to help ensure the integrity of early startup components (components used in the earlier stages of the startup process), and "locks" any BitLocker-protected volumes so that they remain protected even if the computer is tampered with when the operating system is not running.

In Windows Server 2008, BitLocker is an optional component that must be installed before it can be used. To install BitLocker, select it in Server Manager or type the following at a command prompt:

ServerManagerCmd -install BitLocker -restart

What are the requirements for this feature?

To take advantage of all BitLocker features, your computer must meet the hardware and software requirements listed in the table below.

BitLocker hardware and software requirements

Requirement Description

Hardware configuration

Computer must meet the minimum requirements for Windows Vista. For more information about Windows Vista requirements, see https://go.microsoft.com/fwlink/?LinkId=83233.

Operating system

Windows Vista Ultimate or Windows Vista Enterprise. Both include BitLocker Drive Encryption.

Hardware Trusted Platform Module (TPM)*

TPM version 1.2

BIOS configuration
  • Trusted Computing Group (TCG)-compliant BIOS.

  • BIOS must be set to start first from the hard disk, and not the USB or CD drives.

  • BIOS must be able to read from a USB flash drive during startup.

File system

Two NTFS disk partitions, one for the system volume and one for the operating system volume. The system volume partition must be at least 1.5 gigabytes (GB) and set as the active partition.

*A TPM is not required for BitLocker; however, only a computer with a TPM can provide the additional security of pre-startup system integrity verification.

Who will be interested in this feature?

The following groups might be interested in BitLocker:

  • Administrators, IT security professionals, and compliance officers who are tasked with ensuring that confidential data is not disclosed without authorization

  • Administrators responsible for securing computers in remote or branch offices

  • Administrators responsible for servers or Windows Vista client computers that are mobile

  • Administrators responsible for the decommissioning of servers that have stored confidential data

Are there any special considerations?

To make use of its full functionality, BitLocker requires a system that has a compatible TPM microchip and BIOS. A compatible TPM is defined as a version 1.2 TPM. A compatible BIOS must support the TPM and the Static Root of Trust Measurement as defined by the Trusted Computing Group. For more information about TPM specifications, visit the TPM Specifications section of the Trusted Computing Group's Web site (https://go.microsoft.com/fwlink/?LinkId=72757).

BitLocker requires that the active partition (sometimes called the system partition) be a non-encrypted partition. The Windows operating system is installed to a second partition that is encrypted by BitLocker.

Whenever dealing with the encryption of data, especially in an enterprise environment, you must consider how that data can be recovered in the event of hardware failure, changes in personnel, or other situations in which encryption keys are lost. BitLocker supports a robust recovery scenario, which is described later in this article.

What new functionality does this feature provide?

The major features of BitLocker include full-volume encryption, verification of the integrity of early startup components, a robust recovery mechanism, and support for a secure decommissioning process.

Full-volume encryption

Everything written to a BitLocker-protected volume is encrypted. This includes the operating system itself, and all applications and data.

Why is this functionality important?

This helps protect data from unauthorized access. While the physical security of servers remains important, BitLocker can help protect data whenever a computer is stolen, shipped from one location to another, or otherwise out of your physical control.

Encrypting the disk helps prevent offline attacks such as the removal of a disk drive from one computer and its installation in another in an attempt to bypass Windows security provisions, such as permissions enforced by NTFS access control lists (ACLs).

What works differently?

BitLocker is implemented in code in the early startup components ((master boot record (MBR), boot sector, boot manager, Windows Loader)), and as a filter driver that is an integral part of the operating system.

When BitLocker is first enabled, existing data on the volume must be encrypted. You can continue to use the computer during this process, but you might notice reduced performance during this initial encryption.

After the initial encryption is complete, using the encrypted volume causes a slight performance penalty on disk access. While highly dependent on particular hardware and usage patterns, an estimate of 3 to 5 percent is reasonable. On client systems, this is not usually noticeable to users. On heavily-loaded servers, you should evaluate the performance of the disk subsystem.

Using a BitLocker-enabled disk is transparent to the operating system and all applications.

For more information about the specifics of the BitLocker encryption algorithm, see AES-CBC + Elephant diffuser (https://go.microsoft.com/fwlink/?LinkId=82824).

Integrity checking

In conjunction with the TPM, BitLocker verifies the integrity of early startup components, which helps prevent additional offline attacks, such as attempts to insert malicious code into those components.

Why is this functionality important?

Because the components in the earliest part of the startup process must be available unencrypted so that the computer can start, an attacker could change the code in those early startup components, and then gain access to the computer, even though the data on the disk was encrypted. Then, if the attacker gains access to confidential information such as the BitLocker keys or user passwords, BitLocker and other Windows security protections could be circumvented.

What works differently?

On computers equipped with a TPM, each time the computer starts, each of the early startup components (such as the BIOS, the MBR, the boot sector, and the boot manager code) examines the code about to be run, calculates a hash value, and stores the value in the TPM. Once stored in the TPM, that value cannot be replaced until the system is restarted. A combination of these values is recorded.

These recorded values can also be used to protect data, by using the TPM to create a key that is tied to these values. When this type of key is created, the TPM encrypts it, and only that specific TPM can decrypt it. Each time the computer starts, the TPM compares the values generated during the current startup with the values that existed when the key was created. It decrypts the key only if those values match. This process is called "sealing" and "unsealing" the key.

By default, BitLocker examines and seals keys to the measurements of the Core Root of Trust (CRTM), the BIOS and any platform extensions, option read-only memory (ROM) code, MBR code, the NTFS boot sector, and the boot manager. This means that if any of these items are changed unexpectedly, BitLocker will lock the drive and prevent it from being accessed or decrypted.

By default, BitLocker is configured to look for and use a TPM. You can use Group Policy to allow BitLocker to work without a TPM, and store keys on an external USB flash drive; however, BitLocker cannot then verify the early startup components.

How do I resolve these issues?

You should consider the availability of a TPM as part of your hardware purchasing decision. In the absence of a TPM, the physical security of the server becomes even more important.

BitLocker should be disabled during planned maintenance that will change any of the measured early startup components. BitLocker can be re-enabled after the maintenance is complete, and new platform measurements will be used for the keys. Disabling and re-enabling does not require the decryption and re-encryption of the disk.

Recovery options

BitLocker supports a robust series of recovery options to ensure that data is available to legitimate users.

Why is this functionality important?

It is essential that an organization's data can be decrypted, even if the most commonly used decryption keys become unavailable. Recoverability is designed into BitLocker, without any "back doors," but enterprises can easily ensure that their data is both protected and available.

What works differently?

When BitLocker is enabled, the user is prompted to store a "recovery password" that can be used to unlock a locked BitLocker volume. The BitLocker setup wizard requires that at least one copy of the recovery password is saved.

In many environments, however, you might not be able to rely on users keeping and protecting recovery passwords; therefore, you can configure BitLocker to save recovery information to Active Directory or Active Directory Domain Services (AD DS).

We recommend that recovery passwords be saved to Active Directory in enterprise environments.

How do I resolve these issues?

Group Policy settings can be used to configure BitLocker to require or prevent different types of recovery password storage, or to make them optional.

Group Policy settings can also be used to prevent BitLocker from being enabled if the keys cannot be backed up to Active Directory.

For more information about how to configure Active Directory to support recovery options, see Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information (https://go.microsoft.com/fwlink/?LinkId=82827).

Remote management

BitLocker can be managed remotely by using Windows Management Instrumentation (WMI) or a command-line interface.

Why is this functionality important?

In an environment with many computers or computers in remote or branch offices, it is difficult or impossible to manage features and settings on an individual basis.

What works differently?

BitLocker features are exposed through the WMI subsystem. WMI is an implementation of the Web-Based Enterprise Management (WBEM) structures and functions. Accordingly, administrators can use any WMI-compliant WBEM software to manage BitLocker on local or remote computers.

For more information about BitLocker and WMI, see BitLocker Drive Encryption Provider (https://go.microsoft.com/fwlink/?LinkId=82828).

Windows also includes a command-line interface to BitLocker implemented as a script called manage-bde.wsf. You can use manage-bde.wsf to control all aspects of BitLocker on a local or remote computer. For a full list of manage-bde commands and syntax, type the following at a command prompt:

manage-bde.wsf /?

Remote management of BitLocker is an optional component that can be installed on Windows Server 2008 to allow you to manage other computers without enabling BitLocker on the server you are using.

How do I resolve these issues?

The optional component for BitLocker remote management is called BitLocker-RemoteAdminTool. This optional component package contains manage-bde.wsf and the associated .ini file. To install only the remote management component, you must type the following at a command prompt:

ServerManagerCmd -install RSAT-BitLocker

Secure Decommissioning

BitLocker can help provide a cost-effective and quick way to prevent confidential data from being found on equipment that has been decommissioned or reassigned.

Why is this functionality important?

At some point, all computers need to be removed from service and many are reassigned to different purposes during their useful life. Enterprises might have plans to recycle equipment, donate or sell it, or return it at the expiration of a lease, but every enterprise must also ensure that no confidential data can be retrieved from the decommissioned or reassigned equipment. Most processes that remove confidential data from disk drives are time consuming, costly, or result in the permanent destruction of the hardware. BitLocker provides other cost-effective options.

What works differently?

BitLocker helps ensure that data is never stored on disk in a way that would be useful to an attacker, thief or new hardware owner. Because everything written to the disk is encrypted, you can render the data permanently and completely inaccessible by destroying all copies of the encryption keys. The disk itself is unharmed, and can be reused for other purposes.

You can choose from a number of approaches for decommissioning volumes that have been protected by BitLocker:

  • You can choose to delete all copies of keys from the volume metadata, while keeping them archived in a secure central site. This can enable systems to be transported safely, or to be temporarily decommissioned if they will be left unattended for log periods of time. This ensures that authorized users could still access the data, but not any unauthorized users, such as new owners of the equipment.

  • You can choose to delete all copies of keys from the volume metadata, and from any archives, such as Active Directory (perhaps by creating new keys that are not stored). Because no decryption keys then exit, it is infeasible for anyone to recover or retrieve the data.

In either of these cases, the removal and destruction of the keys contained in the volume metadata is almost instantaneous, and can be performed across multiple systems by an administrator. A minimal investment of time and effort is required but results in a very high level of permanent protection.

The format tool in Windows Server 2008 has been updated so that a format command deletes the volume metadata and uses methods accepted by the security community to delete and overwrite any sectors that could potentially be used to obtain BitLocker keys.

How do I resolve these issues?

In evaluating how to deploy BitLocker, you should consider what decommissioning process will be used when servers reach the end of their duty cycle. Determine in advance which recovery keys will be destroyed and which, if any, would be archived.

What settings have been added or changed?

Two new sets of Group Policy settings have been introduced to support BitLocker and management of the TPM. All of the policy settings are explained in the Local Group Policy Editor and the Group Policy Management Console (GPMC). To view more detailed explanations, open the Local Group Policy Editor by typing gpedit.msc at an elevated command prompt or in the Start Search text box, and then examine the description provided for each of the settings in the following table.

Group Policy settings that affect BitLocker are located in Computer Configuration/Administrative Templates/Windows Components/BitLocker Drive Encryption. The following table summarizes these settings.

Setting name Default Description

Turn on BitLocker backup to Active Directory Domain Services

Disabled

This policy setting controls whether BitLocker recovery information is backed up in AD DS. If enabled, it also can control whether backup is required or optional and whether only a recovery password or a full recovery package is saved.

Control Panel Setup: Configure recovery folder

None (User selects)

This policy setting specifies a default location shown to the user to save recovery keys. Can be a local or network location. User is free to choose other locations.

Control Panel Setup: Configure recovery options

None (User selects)

This policy setting allows you to configure whether the BitLocker Drive Encryption setup wizard will ask the user to save BitLocker recovery options.

Two recovery options can unlock access to BitLocker-encrypted data. The user can type a random 48-digit numerical recovery password. The user can also insert a USB flash drive containing a random 256-bit recovery key.

Each of these can be required or disallowed. If you disallow both options, backup to AD DS must be enabled.

Control Panel Setup: Enable advanced startup options

Disabled

This policy setting allows you to configure whether BitLocker can be enabled on computers without a TPM, and whether multi-factor authentication may be used on computers with a TPM.

Configure encryption method

AES 128 bit with Diffuser

This policy setting configures the length of the AES encryption key and whether or not the Diffuser is used.

Prevent memory overwrite on restart

Disabled (memory will be overwritten)

BitLocker keys can persist in memory between restarts if the computer is not powered off. Therefore, BitLocker instructs the BIOS to wipe all memory on "warm" restarts. This can result in a noticeable delay on systems with large amounts of memory. Enabling this setting can improve restart performance, but does increase security risk.

Configure TPM platform validation profile

PCRs 0, 2, 4, 8, 9, 11

Configures which of the TPM platform measurements stored in platform control registers (PCRs) are used to seal BitLocker keys.

Group Policy settings that control TPM behavior are located in Computer Configuration/Administrative Templates/System/Trusted Platform Module services. The following table summarizes these settings.

Setting name Default Description

Turn on TPM backup to Active Directory Domain Services

Disabled

This policy setting controls whether TPM owner password information is backed up in AD DS. If enabled, it also can control whether backup is required or optional.

Configure the list of blocked TPM commands

None

This policy allows specific TPM functions to be disabled or enabled, but the next two settings can restrict which commands are available. Group Policy–based lists override local lists. Local lists can be configured in the TPM Management console.

Ignore the default list of blocked TPM commands

Disabled

By default, certain TPM commands are blocked. In order to enable these commands, this policy setting must be enabled.

Ignore the local list of blocked TPM commands

Disabled

By default, a local administrator can block commands in the TPM Management console. This setting can be used to prevent that behavior.

For more information about working with the TPM and using the TPM Management console, see Windows Trusted Platform Module Management Step-by-Step Guide (https://go.microsoft.com/fwlink/?LinkId=82830).

Do I need to change any existing code?

No change to existing code is required for BitLocker.

How should I prepare to deploy this feature?

Prior to enabling BitLocker, you should consider the following:

  • Hardware requirements. If existing hardware is not powerful enough to handle the encryption, consider upgrading. To use the system integrity features, the hardware platform must be equipped with a version 1.2 TPM.

  • Corporate policies. Evaluate your current policies regarding data retention, encryption, and compliance. Ensure that you have a plan for data recovery.

  • How recovery information will be stored. We recommend using Active Directory Domain Services for backups of recovery information in enterprise environments.

Is this feature available in all editions of Windows Server 2008?

BitLocker is an optional component in all editions of Windows Server 2008, with no difference in functionality between editions. BitLocker is available on 32-bit and 64-bit platforms.

BitLocker is available in Windows Vista Enterprise and Windows Vista Ultimate, and can help significantly in protecting data stored on client computers, particularly mobile ones.

Additional references