S 4.337 Use of BitLocker drive encryption

Initiation responsibility: Head of IT

Implementation responsibility: Head of IT, User

The BitLocker drive encryption (BDE) offers the encryption of all data on the hard disk and monitors the integrity of the system's boot process. The protection of the system integrity requires that the system is equipped with a TPM (Trusted Platform Module).

On a server, BitLocker is included in Windows Server 2008 and higher versions; on a client, BitLocker is included in Windows Vista and higher versions (only in the Enterprise and Ultimate operating system versions).

The primary security objective of BitLocker is the confidentiality of data when the system is turned off. During the Windows start-up procedure, BitLocker downloads the keys for the encrypted hard disk partitions and has them available for the entire period of time during which the client is turned on. During live operation, BitLocker offers no protection of the confidentiality.

BDE should be used to protect the confidentiality of all data of a Windows client. This applies in particular to mobile clients exposed to the risk of loss and theft and whose hardware does not offer equal drive encryption and authentication. The protection requirements regarding the confidentiality and availability of the cryptographic key material must be considered to be at least as high as the protection requirements of the encrypted data itself. For the use of BitLocker on several systems, the key management should be planned in advance, which can be realised for BitLocker using Active Directory, for example.

For the use of BitLocker on several systems, M 1.7 Crypto-concept should also be applied.

Preparing to use BitLocker

If BDE is used, the Windows client should be equipped with a Trusted Platform Module (TPM) version 1.2. The TPM is a hardware module protected against manipulation on the main board of the system which provides the user with protected functionalities and an isolated storage unit. BitLocker uses the TPM to store cryptographic keys and to determine the system integrity during the boot process. When using BitLocker without TPM, only a USB storage medium is used to store keys. The integrity protection is not given in this configuration.

The BitLocker drive encryption encrypts partitions on data media. The terms "volume" and "partition" are used synonymously by Microsoft.

For BitLocker, at least two partitions must be set up:

If a Windows system does not have a separate start partition yet, it is automatically generated during the installation or during the activation of BitLocker in Windows 7 and higher. In Windows Vista, it must be created manually using the BitLocker Drive Preparation Tool (in Start | All programmes | Accessories | System Tools | BitLocker). The activation of BitLocker and the encryption process being executed in the background can result in incompatibilities with software already installed. To detect this promptly, BitLocker must be activated after the installation of Windows and prior to the installation of additional software. If the start partition is generated later, a backup of the current overall system should be created in advance.

The activation of BitLocker can be automated using the BitLocker command line tools. For this purpose, the automation scripts must not contain any recovery passwords. Instead, the central key management for BitLocker should be planned and activated in advance, which can be realised using Active Directory, for instance.

Consideration should be given to denying standard users write access to the unencrypted start partition. This can be achieved using the corresponding NTFS authorisations. Thus, the system integrity and the security of the start-up procedure are increased. Denying standard users write access prevents them from believing their data is confidential due to the protection offered by BDE even though they have accidentally written their data to the unencrypted start partition.

In particular when a higher protection level is required, additional partitions such as a data partition should also be encrypted unless there are reasons against this due to the incompatibility with certain applications. Only NTFS partitions should be used. In Windows Vista without Service Pack 1 installed, BitLocker does not support this and must be avoided on clients with several partitions.

Planning group policies

When BitLocker is used on several systems, group policies should be used in Windows Vista with Service Pack 1 and higher to control the encryption settings and ensure their compliance. If the central key management via Active Directory is used, it is absolutely necessary to plan the group policies.

In the following sections, the most important settings of the Computer Configuration | Administrative Templates | Windows Components | BitLocker Drive Encryption Windows group policy are described.

Selecting a secure authentication method for the system start

The administrator can configure different procedures for user authentication as well as combinations of these procedures to successfully start BitLocker while Windows is starting up.

A suitable form of user authentication for BitLocker must be selected. When making the selection, the following aspects must be taken into account and their advantages and disadvantages compared:

All four forms of authentication presented can also be used in computer pools, i.e. when a mobile client is available for use for several users. In this case, all users must use the same PIN and/or have the same key material available on a USB stick. As an alternative, an individual authentication key can be used on each USB stick in connection with a TPM (only possible using the command line).

In Windows 7 and higher, the group policy for complex PINs should be activated (Operating System Drives| Extended System Start PINs). Certain hardware and boot configurations, for example older PXE boot environments, do not support this and should not be used.

Recovery of encrypted Windows systems in emergencies

Recovery passwords and keys allow an administrator to recover encrypted data if the TPM is defective or the user has lost the start PIN or the USB stick. Furthermore, they allow the continuation of the Windows start-up procedure if BitLocker has detected manipulations on the BIOS or other boot components protected by BitLocker. The recovery password or the recovery key is needed to start Windows in the secure mode, for example to perform maintenance or eliminate an error.

When encrypting hard disk partitions, the administrator must set a 48-digit recovery password. For this purpose, a random password is generated by default. It should be accepted and can be printed or stored as text file. According to S 2.22 Escrow of passwords, how the recovery password is stored should be documented in detail. It must be treated as confidentially and carefully as the start PIN, the USB stick or the smart card.

According to S 4.86 Secure separation of roles and configuration with crypto modules, if and how recovery passwords and recovery keys are to be stored centrally and who may access them for recovery purposes must be regulated. In order to provide better protection of the confidentiality of this information and to accelerate the recovery in emergencies, it is recommended that this information be automatically stored in the Active Directory irrespective of the user interaction and that, otherwise, the system deny the activation of the BitLocker (Specify how BitLocker-protected operating system drives can be recovered group policy). For local key management, consideration should be given to making backup copies of the recovery password and of the recovery key and storing them at suitable, but separate, locations. In each case, the steps, persons and resources required for recovery should be documented in detail (according to the specifications of M 1.7 Crypto-concept).

If the recovery password is selected manually or changed subsequently by the administrator, then trivial passwords must be avoided (see S 2.11 Provisions governing the use of passwords).

If you suspect that the PIN, USB stick, recovery password, or recovery key were compromised, then the corresponding key must be set to a new value. This can be carried out using the manage-bde.wsf (Windows Vista, Server 2008) or manage-bde.exe (in Windows 7, Server 2008 R2 and higher) command line tools in connection with the recovery password or the recovery key. It is also possible using this tool to lock and recreate lost or defective USB sticks and/or PINs.

In addition to this, it can be determined using a group policy that a 256-bit recovery key is generated for each encrypted data medium. In this manner, the data medium can be accessed when the original authentication resources are no longer available. The recovery key cannot be printed and distributed orally, for example over the telephone. This increases the protection of the confidentiality of the data, but delays data recovery in emergencies. These recovery keys can only be stored on USB sticks, as files or in the Active Directory. On systems by means of which data with very high confidentiality requirements are processed, only recovery keys, but no recovery passwords should be allowed.

In addition to this, the administrator can install a data recovery agent (Group Policies Snap-in | Computer Configuration | Windows Settings | Security Settings | Public Key Policies | BitLocker) in Windows 7, Server 2008 R2 and higher. This is the public part of a universal recover key; it is installed uniformly on all BitLocker clients. The appropriate private key can decrypt the encrypted data media. The administrator should not possess this key. In principle, data recovery agents require a particularly high protection against misuse. If they are compromised, replacing them is very complicated. Therefore, they are not a replacement for recovery passwords or keys, but only additional protection against the loss of data for users who cannot participate in the central key management.

Destroying the key material

As soon as an encrypted data medium is disposed of or lost, all keys and passwords in connection with this data medium must be destroyed immediately. For centrally stored keys, the destruction should be recorded in a revision-proof manner provided that the encrypted data have higher protection requirements regarding confidentiality.

Monitoring the BitLocker maintenance mode

The BitLocker encryption must be temporarily disabled by the administrator for maintenance purposes, for instance for a BIOS update. In this maintenance mode, the internal BitLocker key material can be easily spied out by attackers and malicious software. Therefore, the system's Event Viewer should be permanently monitored for any BitLocker Driver messages. If unexpected or very long maintenance phases or unexpected decryption/encryption events were recorded, or if the events displayed are incomplete, the IT Security Officer should be informed about this. If it is a security incident, the affected client must be re-encrypted completely Changing the keys and recovery passwords alone is not sufficient in such a case (see T 3.97 Violation of confidentiality in spite of BitLocker drive encryption under Windows Vista and higher).

Training the users

In general, the users must be trained in handling BitLocker and informed of which hard drive partitions are encrypted by BitLocker and which are not.

Furthermore, the users must be informed which steps or contact partners apply to them if the start PIN, USB key or smart card are lost.

BitLocker in connection with standby modes

The users must be informed of how they should handle the standby modes available in terms of the effectiveness of the BitLocker encryption.

A Windows client that is not currently being used but that is not turned off may be in the standby mode. Windows systems offer the following standby modes: the Standby mode (in Windows 7 and higher referred to as "Sleep mode" or Suspend to Memory), the Hibernation mode (Hibernate mode or Suspend to Disk) and the Hybrid Sleep mode.

The Standby mode is a typical feature of mobile clients and is used to save energy. In the Standby mode, the BitLocker key material remains in memory (the RAM) of the Windows client. This endangers the confidentiality of the data encrypted by BitLocker by the attack vector against BitLocker keys in RAM (see the section above). In order to counteract this attack vector, it is recommended to not leave a Windows client unattended while in the Standby mode. Alternatives are the Hibernation mode and turning off the system completely.

The Hibernation mode is not threatened by the attack vector against BitLocker keys in RAM presented above provided that the TPM is not used exclusively for the BitLocker authentication. The reason for this is that the key material does not remain in the memory, but is encrypted on the hard disk and is downloaded in the memory after "waking up" only following a successful user authentication.

The Hybrid Sleep mode is a new feature in Windows Vista and higher versions. This mode combines the Standby mode with the Hibernation mode. Like the Standby mode, the Hybrid Sleep mode is vulnerable to the attack vector against BitLocker keys in RAM. The Hybrid Sleep mode should not be used for this reason when high confidentiality protection requirements are placed on the BitLocker and the Windows client is left unattended at least temporarily.

When using the Standby mode, Hibernation mode or the Hybrid Sleep mode, it should only be possible to unlock the IT system after the password has been entered again. This recommendation applies regardless of BitLocker. To ensure this is the case, the Prompt for password on resume from hibernate / suspend mode policy must be enabled in the corresponding group policy object under User Configuration | Administrative Templates | System | Power Management.

BitLocker for very high security requirements

The Deny write access to hard disk drives which are not protected by BitLocker group policy should be used (under BitLocker Drive Encryption | Hard Disk Drives). In general, this prevents it being possible to write on subsequently generated data partitions and on any additionally mounted internal hard disk. All regular data partitions, however, must be encrypted in this case.

The encryption strength can be raised from 128-bit AES diffuser to 256-bit AES diffuser (Select encryption procedure and encryption strength for drive group policy). Thus, the encryption process generates a significantly higher CPU load and should first be tested on weaker notebooks in particular before being used in the production environment.

In the Configure the TPM platform validation profile group policy, additional hardware integrity tests can be enabled to increase the protection against manipulation and rootkits. These settings, however, significantly increase the threats described in Loss of BitLocker-encrypted data.

The encryption of virtual data media using BitLocker To Go on hard disks, which have already been encrypted using BitLocker (double encryption), is basically possible, but useless, since the same encryption algorithm is always used and thus, no higher level of protection against decryption software is achieved. At the same time, the complexity and susceptibility to error of the key management increases and the system speed is reduced. Therefore, double encryption using BitLocker should be avoided.

BitLocker tools

Microsoft provides tools for preparing, configuring and administering BitLocker.

Limits of the areas of applications of BitLocker

If you need to be able to start another operating system in addition to Windows Vista and higher (multiboot system), then it is recommended to use a program for hard drive encryption that can decrypt operating system partitions individually and irrespectively of each other for any operating system. In practice, BDE is unsuitable for use on multiboot systems.

As an alternative to BitLocker, the Encrypting File System (EFS) encrypting individual files instead of partitions (see S 4.147 Secure use of EFS under Windows) can also be used.

The use of the EFS is also recommended when the data to be protected on a mobile client also needs to be available in the encrypted form when the mobile client is turned on and running Windows. BitLocker encryption does not offer effective protection of the confidentiality when the computer is turned on.

In order to realise this configuration without using EFS , virtual drives can be encrypted using BitLocker To Go in Windows 7 and Windows Server 2008 R2 and higher versions. Virtual drives are depicting files of data media and can be integrated and separated during live operation. Users without administrative authorisation can create virtual drives during regular operation using software from third-party providers and, comparable to USB sticks, integrate them temporarily.

Additional information on BitLocker

The manufacturer's documentation can be found in Microsoft Technet under the title Step-by-step instructions on BitLocker Drive Encryption. Additional information on BitLocker can be found in the "BitLocker Drive Encryption in Mobile and Stationary Corporate Applications" user guide on the BSI web site. The guide is the result of a security analysis conducted jointly by the BSI and the Fraunhofer Institute for Secure Information Technology and with the involvement of the Microsoft Product Group responsible for the development of BDE.

Review questions:

© Federal Office for Information Security. All rights reserved.