BitLocker Countermeasures

Applies To: Windows 8.1

Windows uses technologies including Trusted Platform Module, UEFI and Secure Boot, Trusted Boot, and Early Launch Antimalware (ELAM) to protect against attacks on the BitLocker encryption key.

BitLocker was introduced in the Windows Vista operating system as part of a strategic approach to securing mobile data through encryption technology. Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software attack tool against it or by transferring the computer’s hard disk to a different computer. Today, BitLocker helps mitigate unauthorized data access on lost or stolen computers before the operating system is started by:

  • Encrypting the hard drives on your computer. For example, you can turn on BitLocker for your operating system drive (the drive on which Windows is installed), a fixed data drive (such as a different volume on the system drive or a separate internal hard drive), or a removable data drive (such as a USB flash drive). Turning on BitLocker for your operating system drive encrypts all system files on the operating system drive, including the swap files and hibernation files.

  • Ensuring the integrity of early boot components and boot configuration data. On Windows 7–certified devices that have a TPM version 2.0 or 1.2, BitLocker uses the enhanced security capabilities of the TPM to help ensure that your data is accessible only if the computer’s boot components appear unaltered and the encrypted disk is located in the original computer. On Windows 8–certified devices, a combination of UEFI and TPM helps ensure integrity.

The sections that follow provide more detailed information about the different technologies that Windows uses to protect against attacks on the BitLocker encryption key in four different boot phases: before startup, during pre-boot, during startup, and finally after startup.

Protection Before Startup

Before Windows starts, you must rely on security features implemented as part of the device hardware, including TPM and UEFI Secure Boot. Fortunately, many modern computers feature TPM, and all Windows 8.1– and Windows 8–certified devices support all of these features.

Trusted Platform Module

Software alone isn’t sufficient to protect a system. After an attacker has compromised software, the software might be unable to detect the compromise. Therefore, a single successful software compromise results in an untrusted system that might never be detected. Hardware, however, is much more difficult to modify.

A TPM is a microchip designed to provide basic security-related functions, primarily involving encryption keys. The TPM is usually installed on the motherboard of a computer and communicates with the rest of the system through a hardware bus. Physically, TPMs are designed to be tamper-proof. If an attacker tries to physically retrieve data directly from the chip, they’ll probably destroy the chip in the process.

By binding the BitLocker encryption key with the TPM and properly configuring the device, it’s nearly impossible for an attacker to gain access to the BitLocker-encrypted data without obtaining an authorized user’s credentials. Therefore, computers with a TPM can provide a high level of protection against attacks that attempt to directly retrieve the BitLocker encryption key.

On devices running Windows 8, the combination of a TPM and UEFI Secure Boot provides sufficient device integrity–related security. On devices running Windows 8 or Windows 7 without UEFI-based Secure Boot, the TPM will be used to protect the system’s boot-related components.

UEFI and Secure Boot

No operating system can protect a device when the operating system is offline. For that reason, Microsoft worked closely with hardware vendors to require firmware-level protection against boot and rootkits that might compromise an encryption solution’s encryption keys in all Windows 8–certified devices.

The UEFI is a programmable boot environment introduced as a replacement for BIOS, which has for the most part remained unchanged for the past 30 years. Like BIOS, PCs start UEFI before any other software; it initializes devices, and UEFI then starts the operating system’s bootloader. As part of its introduction into the pre–operating system environment, UEFI serves a number of purposes, but one of the key benefits is to protect newer devices against a sophisticated type of malware called a bootkit through the use of its Secure Boot feature.

Recent implementations of UEFI (starting with version 2.3.1, which is in all Windows 8–certified devices) can verify the digital signatures of the device’s firmware before running it. Because only the PC’s hardware manufacturer has access to the digital certificate required to create a valid firmware signature, UEFI can prevent firmware-based bootkits. Thus, UEFI is the first link in the chain of trust.

The UEFI-based Secure Boot feature is the foundation of platform and firmware security and was created to enhance security in the pre-boot environment regardless of device architecture. Using signatures to validate the integrity of firmware images before they are allowed to execute, Secure Boot helps reduce the risk of bootloader attacks. The purpose of Secure Boot is to block untrusted firmware and bootloaders (signed or unsigned) from being able to start on the system.

With the legacy BIOS boot process, the pre–operating system environment is vulnerable to attacks by redirecting bootloader handoff to possible malicious loaders. These loaders could remain undetected to operating system and antimalware software. The diagram in Figure 1 contrasts the BIOS and UEFI startup processes.

Figure 1. The BIOS and UEFI startup processes

With Secure Boot enabled, UEFI, in coordination with the TPM, can examine the bootloader and determine whether it’s trustworthy. To determine whether the bootloader is trustworthy, UEFI examines the bootloader’s digital signature. Using the digital signature, the UEFI:

  • With Secure Boot enabled, UEFI, in coordination with the TPM, can examine the bootloader and determine whether it’s trustworthy. To determine whether the bootloader is trustworthy, UEFI examines the bootloader’s digital signature. Using the digital signature, the UEFI:

  • Verifies that the bootloader was signed using a trusted certificate (in the case of Windows 8, Microsoft’s certificate)

If the bootloader passes these two tests, the UEFI knows that the bootloader isn’t a bootkit and starts it. At this point, Windows 8.1’s Trusted Boot feature takes over, and the Windows 8 bootloader, using the same cryptographic technologies that UEFI used to verify the bootloader, then verifies that the Windows system files haven’t been changed.

All Windows 8–certified devices must meet several requirements related to UEFI-based Secure Boot:

  • They must have Secure Boot enabled by default.

  • They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).

  • They must allow the user to configure Secure Boot to trust other signed bootloaders.

  • Except for Windows RT devices, they must allow the user to completely disable Secure Boot.

These requirements help protect you from rootkits while allowing you to run any operating system you want. You have three options for running non-Microsoft operating systems:

  • Use an operating system with a certified bootloader. Because all Certified for Windows 8 PCs must trust Microsoft’s certificate, Microsoft offers a service to analyze and sign non-Microsoft bootloaders so that they can be trusted by all Certified for Windows 8 PCs. The Linux community is using this process to enable Linux to take advantage of UEFI Secure Boot on Windows-certified devices.

  • Configure UEFI to trust your custom bootloader. All Certified for Windows 8 PCs allow you to trust a signed, noncertified bootloader that you specify in the UEFI database, allowing you to run any operating system, including homemade operating systems.

  • Turn off Secure Boot. All Certified for Windows 8 PCs allow you to turn off Secure Boot so you can run any software. This does not help protect you from bootkits, however.

To prevent malware from abusing these options, the user has to manually configure the UEFI firmware to trust a noncertified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings.

Any device that doesn’t require Secure Boot or a similar bootloader-verification technology, regardless of the architecture or operating system, is vulnerable to bootkits, which can be used to compromise the encryption solution. By default, all Windows 8–certified devices have UEFI-based Secure Boot enabled.

UEFI is secure by design, but it’s critical to protect the Secure Boot configuration by using password protection. In addition, although several well-publicized attacks against UEFI have occurred, they were exploiting faulty UEFI implementations. Those attacks are ineffective when UEFI is implemented properly.

For more information about Secure Boot, refer to Securing the Windows 8 Boot Process.

Protection During Pre-boot: Pre-boot Authentication

Pre-boot authentication with full-disk encryption products (including BitLocker) is a process that requires a user to authenticate prior to making the contents of the system drive accessible. In the case of BitLocker, BitLocker encrypts the entire drive, including all system files. BitLocker accesses and stores the encryption key in memory only after a user provides a specific PIN or USB startup key.

If Windows can’t access the encryption key, the device can’t read or edit the files on the system drive. Even if an attacker takes the disk out of the PC or steals the entire PC, they won’t be able to read or edit the files without the encryption key. The only option for bypassing pre-boot authentication is entering the highly complex, 48-digit recovery key.

The BitLocker pre-boot authentication capability is not specifically designed to prevent the operating system from starting: That’s merely a side effect of how BitLocker protects data confidentiality and system integrity. Pre-boot authentication is designed to prevent the encryption key from being loaded to system memory on devices that are vulnerable to certain types of cold boot attacks. Many modern devices prevent an attacker from easily removing the memory, and Microsoft expects those devices to become even more common in the future.

On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:

  • TPM-only. Using TPM-only validation does not require any interaction with the user to decrypt and provide access to the drive. If the TPM validation succeeds, the user logon experience is the same as a standard logon. If the TPM is missing or changed or if the TPM detects changes to critical operating system startup files, BitLocker enters its recovery mode, and the user must enter a recovery password to regain access to the data.

  • TPM with startup key. In addition to the protection that the TPM provides, part of the encryption key is stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the startup key.

  • TPM with PIN. In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN. Data on the encrypted volume cannot be accessed without entering the PIN.

  • TPM with startup key and PIN. In addition to the core component protection that the TPM provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM. This configuration provides Multifactor Authentication so that if the USB key is lost or stolen, it cannot be used for access to the drive, because the correct PIN is also required.

For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented. These mitigations may be inherent to the device or may come by way of configurations that IT can provision to devices and Windows itself.

Although effective, pre-boot authentication is inconvenient to users. In addition, if a user forgets their PIN or loses their startup key, they’re denied access to their data until they can contact their organization’s support team to obtain a recovery key. Today, most new PCs running Windows 8.1 or Windows 8 provide sufficient protection against DMA attacks without requiring pre-boot authentication. For example, most modern PCs include USB port options (which are not vulnerable to DMA attacks) but do not include FireWire or Thunderbolt ports (which are vulnerable to DMA attacks).

In fact, to achieve a Windows 8 InstantGo (formerly Connected Standby) certification from Microsoft, new devices can’t include a DMA port, eliminating the need for pre-boot authentication to mitigate against a DMA port attack in most tablets and other Windows 8–certified devices. Although this certification is primarily just implemented only on tablets and a few 2-in-1 devices such as a the Surface Pro 3, starting in 2015, Microsoft expects to see more 2-in-1 devices and laptops certified for InstantGo. Adoption of Thunderbolt on non-InstantGo devices is likely to increase in 2015, so we advise customers to keep this in mind as they purchase new devices and configure BitLocker on them.

BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be configured with pre-boot authentication if they are running Windows 7, Windows 8, or Windows 8.1 and disabling the ports using policy or firmware configuration is not an option. Windows 8.1 InstantGo devices do not need pre-boot authentication to defend against DMA-based port attacks, as the ports will not be present on certified devices. A non-InstantGo Windows 8.1 device requires pre-boot authentication if DMA ports are enabled on the device and additional mitigations described in this document are not implemented. Many customers find that the DMA ports on their devices are never used, and they choose to eliminate the possibility of an attack by disabling the DMA ports themselves, either at the hardware level or through Group Policy.

Many new mobile devices have the system memory soldered to the motherboard, which helps prevent the cold boot–style attack, where the system memory is frozen, removed, and then placed into another device. Those devices, and most PCs, can still be vulnerable when booting to a malicious operating system, however.

You can mitigate the risk of booting to a malicious operating system:

  • Windows 8.1 (without Secure Boot), Windows 8 (without UEFI-based Secure Boot), or Windows 7 (with or without a TPM). Disable booting from external media, and require a firmware password to prevent the attacker from changing that option.

  • Windows 8.1 or Windows 8 (certified or with Secure Boot). Password protect the firmware, and do not disable Secure Boot.

Protection During Startup

During the startup process, Windows 8.1 and Windows 8 use Trusted Boot and Early Launch Antimalware (ELAM) to examine the integrity of every component. The sections that follow describe these technologies in more detail.

Trusted Boot

Trusted Boot takes over where UEFI-based Secure Boot leaves off—during the operating system initialization phase. The bootloader verifies the digital signature of the Windows 8 kernel before loading it. The Windows 8 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM driver. If a file has been modified or is not properly signed with a Microsoft signature, Windows detects the problem and refuses to load the corrupted component. Often, Windows 8 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.

Windows 8 uses Trusted Boot on any hardware platform: It requires neither UEFI nor a TPM. However, without Secure Boot, it’s possible for malware to compromise the startup process prior to Windows starting, at which point Trusted Boot protections could be bypassed or potentially disabled.

Early Launch Antimalware

Because UEFI-based Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel or other Windows startup components, the next opportunity for malware to start is by infecting a non-Microsoft boot-related driver. Traditional antimalware apps don’t start until after the boot-related drivers have been loaded, giving a rootkit disguised as a driver the opportunity to work.

The purpose of ELAM is to load an antimalware driver before drivers that are flagged as boot-start can be executed. This approach provides the ability for an antimalware driver to register as a trusted boot-critical driver. It is launched during the Trusted Boot process, and with that, Windows ensures that it is loaded before any other non-Microsoft software.

With this solution in place, boot drivers are initialized based on the classification that the ELAM driver returns according to an initialization policy. IT pros have the ability to change this policy through Group Policy.

ELAM classifies drivers as follows:

  • Good. The driver has been signed and has not been tampered with.ReplaceThisText

  • Bad. The driver has been identified as malware. It is recommended that you not allow known bad drivers to be initialized.

  • Bad but required for boot. The driver has been identified as malware, but the computer cannot successfully boot without loading this driver.

  • Unknown. This driver has not been attested to by your malware-detection application or classified by the ELAM boot-start driver.

While the features listed above protect the Windows boot process from malware threats that could compromise BitLocker security, it is important to note that DMA ports may be enabled during the window of time between when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port related policies that have been configured. This period of time where the encryption key could be exposed to a DMA attack could be less than a minute on recent devices or longer depending on system performance. The use of pre-boot authentication with a PIN can be used to successfully mitigate against an attack.

Protection After Startup: eliminate DMA availability

Windows 8 InstantGo–certified devices do not have DMA ports, eliminating the risk of DMA attacks. On pre-Windows 8 certified devices, you can disable FireWire, Thunderbolt, or other ports that support DMA.

See also