Countermeasures

Protecting BitLocker-
encrypted devices from
attacks
January 2014
Table of
contents
3 Attacks
3 Bootkit and rootkit attacks
5 Brute-force sign-in attacks
5 Direct memory access attacks
7 Hyberfl.sys attacks
8 Memory remanence attacks
10 Countermeasures
10 Protection before startup
14 Protection during pre-boot: pre-boot authentication
16 Protection during startup
17 Protection after startup: DMA attack protection
18 Choosing the right countermeasures
21 Summary
1 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Countermeasures
Protecting BitLocker-encrypted
devices from attacks
Full-volume encryption using BitLocker Drive Encryption
is vital for protecting data and system integrity on devices
running the Windows 8.1, Windows 8, or Windows 7
operating system. It is equally important to protect
the BitLocker encryption key. On Windows 7 devices,
suffciently protecting that key often required pre-boot
authentication, which many users fnd inconvenient and
complicates device management.
Microsoft has made improvements in Windows 8.1
and worked closely with hardware manufacturers
to deliver Windows 8.1 and Windows 8 devices
that are fundamentally resistant to known attacks
against the BitLocker encryption key. As a result,
many organizations can now meet their security
requirements without using pre-boot authentication,
reducing complexity and inconvenience.
This paper provides detailed information that will help
you understand the circumstances under which the use
of pre-boot authentication is recommended and when it
can be safely omitted from a devices confguration.
NOTE
For the latest information,
please see http://aka.ms/
bitlockerinfo.
2 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
BitLocker uses encryption to protect the data on your drive, but
BitLocker security is only effective when the encryption key is
protected. Many users have relied on pre-boot authentication to
protect the operating systems integrity, disk encryption solution
(e.g., encryption keys), and the PCs data from offine attacks. With
pre-boot authentication, users must provide some form of credential
before unlocking encrypted volumes and starting Windows. Typically,
they authenticate themselves using a PIN or a USB fash drive as a key.
Pre-boot authentication provides excellent startup security, but it
inconveniences users and increases IT management costs. Every
time the PC is unattended, the device must be set to hibernate
(i.e., shutdown and powered off); when the computer restarts, users
must authenticate before the encrypted volumes are unlocked.
This requirement increases restart times and prevents users from
accessing remote PCs until they can physically access the computer
to authenticate, making pre-boot authentication unacceptable in the
modern IT world, where users expect their devices to turn on instantly
and IT requires PCs to be constantly connected to the network.
If users lose their USB key or forget their PIN, they cant access their
PC without a recovery key. With a properly confgured infrastructure,
the organizations support will be able to provide the recovery key,
but doing so increases support costs, and users might lose hours of
productive work time.
Windows 8 and new devices designed for Windows 8 change
everything. The Unifed Extensible Firmware Interface (UEFI) Secure
Boot and Windows Trusted Boot startup process ensures operating
system integrity, allowing Windows to start automatically while
minimizing the risk of malicious startup tools and rootkits. In
addition, many modern mobile devices are fundamentally physically
resistant to sophisticated attacks against the computers memory, and
now Windows authenticates the user before making devices that may
represent a threat to the device and encryption keys available for use.
The sections that follow help you understand which PCs still
need pre-boot authentication and which can meet your security
requirements without the inconvenience of it.
The Unifed Extensible
Firmware Interface
(UEFI) Secure Boot and
Windows Trusted Boot
startup process ensures
operating system
integrity, allowing
Windows to start
automatically while
minimizing the risk of
malicious startup tools
and rootkits.
3 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Attacks
The next few sections describe each type of attack that could be used to compromise a volume
encryption key, whether for BitLocker or a non-Microsoft encryption solution. After an attacker
has compromised a volume encryption key, the attacker can read data from your system drive
or even install malware while Windows is offine. Each section begins with a graphical overview
of the attacks strengths and weaknesses as well as suggested mitigations for Windows 8 and
Windows 7certifed devices.
Bootkit and rootkit attacks
Rootkits are a sophisticated and dangerous type of malware that runs in kernel mode, using the
same privileges as the operating system. Because rootkits have the same or possibly even more
rights than the operating system, they can completely hide themselves from Windows and even
an antimalware solution. Often, rootkits are part of an entire suite of malware that can bypass local
logins, record passwords, transfer private fles, and capture cryptography keys.
Different types of bootkits and rootkits load at different software levels:
Kernel level Rootkits running at the kernel level have the highest privilege in the operating
system. They may be able to inject malicious code or replace portions of the core operating
system, including both the kernel and device drivers.
Application level These rootkits are aimed to replace application binaries with malicious
code, such as a Trojan, and can even modify the behavior of existing applications.
Library level The purpose of library-level rootkits is to hook, patch, or replace system calls
with malicious code that can hide the malwares presence.
Hypervisor level Hypervisor rootkits target the boot sequence. Their primary purpose is to
modify the boot sequence to load themselves as a hypervisor.
Firmware level These rootkits overwrite the PCs BIOS frmware, giving the malware low-
level access and potentially the ability to install or hide malware, even if its cleaned or
removed from the hard disk.
Regardless of the operating system or encryption method, rootkits have access to confdential
data once installed. Application-level rootkits can read any fles the user can access, bypassing
volume-level encryption. Kernel-, library-, hypervisor-, and frmware-level rootkits have direct
access to system fles on encrypted volumes and can also retrieve an encryption key from memory.
4 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Windows 7 offers substantial protection from bootkits and rootkits,
but it is possible to bypass operating system security when an
attacker has physical access to the device and can install the malware
to the device while Windows is offine. For example, an attacker might
boot a PC from a USB fash drive containing malware that starts
before Windows. The malware can replace system fles or the PCs
frmware or simply start Windows under its control.
To suffciently protect a PC from boot and rootkits, devices must use
pre-boot authentication or UEFI-based Secure Boot, or the encryption
solution must use the devices Trusted Platform Module (TPM) as a
means of monitoring the integrity of the end-to-end boot process.
Pre-boot authentication is available for any device, regardless of
the hardware, but because it is inconvenient to users, it should be
used only to mitigate threats that are applicable to the device. UEFI-
based Secure Boot is required for all Windows 8.1 and Windows 8
certifed devices. On those devices, you do not need to use pre-
boot authentication to protect against boot and rootkit attacks.
Although password protection of the UEFI confguration is important
for protecting a devices confguration and preventing an attacker
from disabling UEFIs Secure Boot feature, use of a TPM and its
Platform Confguration Register (PCR) measurements (PCR7) to
ensure that the systems bootloader (whether a Windows or non-
Microsoft encryption solution) is tamper free and the frst code to
start on the device is critical. An encryption solution that doesnt use
a devices TPM to protect its components from tampering may be
unable to protect itself from bootkit-level infections that could log
a users password or acquire encryption keys. For this reason, when
BitLocker is confgured on Windows 8 and Windows 7certifed
devices that include a TPM, the TPM and its PCRs are always used
to secure and confrm the integrity of the preoperating system
environment before making encrypted volumes accessible.
Any changes to the UEFI confguration invalidates the PCR7 and
require the user to enter the BitLocker recovery key. Because of this
feature, its not critical to password-protect your UEFI confguration.
If an attacker successfully turns off Secure Boot or otherwise changes
the UEFI confguration, they will need to enter the BitLocker recovery
UEFI-based Secure
Boot is required for
all Windows 8.1 and
Windows 8certifed
devices. On those
devices, you do not
need to use pre-boot
authentication to
protect against boot
and rootkit attacks.
5 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
key, but UEFI password protection is a best practice and is still required for systems not using a
TPM (such as non-Microsoft alternatives).
Brute-force sign-in attacks
Attackers can fnd any password if you allow them to guess enough times. The process of trying
millions of different passwords until you fnd the right one is known as a brute-force sign-in attack.
In theory, an attacker could obtain any password by using this method.
Three opportunities for brute-force attacks exist:
Against the pre-boot authenticator An attacker could attack the device directly by
attempting to guess the users BitLocker PIN or an equivalent authenticator. The TPM
mitigates this approach by invoking an antihammering lockout capability that requires the
user to wait until the lockout period ends or enter the BitLocker recovery key.
Against the recovery key An attacker could attempt to guess the 48-digit BitLocker
recovery key. Even without a lockout period, the key is long enough to make brute-force
attacks impractical. Specifcally, the BitLocker recovery key has 128 bits of entropy; thus, the
average brute-force attack would succeed after 18,446,744,073,709,551,616 guesses. If an
attacker could guess 1 million passwords per second, the average brute-force attack would
require more than 580,000 years to be successful.
Against the operating system sign-in authenticator An attacker can attempt to guess a
valid user name and password. Windows implements a delay between password guesses,
slowing down brute-force attacks. In addition, all recent versions of Windows allow
administrators to require complex passwords and password lockouts. Similarly, administrators
can use Microsoft Exchange ActiveSync policy or Group Policy to confgure Windows 8.1
and Windows 8 to automatically restart and require the user to enter the BitLocker 48-digit
recovery key after a specifed number of invalid password attempts. When these settings are
enabled and users follow best practices for complex passwords, brute-force attacks against
the operating system sign-in are impractical.
In general, brute-force sign-in attacks are not practical against Windows when administrators
enforce complex passwords and account lockouts.
Direct memory access attacks
Direct memory access (DMA) allows certain types of hardware devices to communicate directly
with a devices system memory. For example, if you use Thunderbolt to connect another device to
6 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
your computer, the second device automatically has Read and Write
access to the target computers memory.
Unfortunately, DMA ports dont use authentication and access control
to protect the contents of the computers memory. Whereas Windows
prevents system components and apps from reading and writing
to protected parts of memory, a device can use DMA to read any
location in memory, including the location of any encryption keys.
DMA attacks are relatively easy to execute and require little technical
skills. Anyone can download a tool from the Internet, such as those
made by Passware, ElcomSoft, and others, and then use a DMA attack
to read confdential data from a PCs memory. Because encryption
solutions store their encryption keys in memory, they can be accessed
by a DMA attack.
To perform a DMA attack, attackers typically connect a second PC
that is running a memory-scanning tool (e.g., Passware, ElcomSoft)
to the FireWire or Thunderbolt port of the target computer. When
connected, the software scans the system memory of the target
and locates the encryption key. Once acquired, the key can be
used to decrypt the drive and read or modify its contents.
A much more effcient form of this attack exists in theory: An attacker
crafts a custom FireWire or Thunderbolt device that has the DMA
attack logic programmed on it. Now, the attacker simply needs to
physically connect the device. If the attacker does not have physical
access, they could disguise it as a free USB fash drive and distribute
it to employees of a target organization. When connected, the
attacking device could use a DMA attack to scan the PCs memory for
the encryption key. It could then transmit the key (or any data in the
PCs memory) using the PCs Internet connection or its own wireless
connection. This type of attack would require an extremely high
level of sophistication, because it requires that the attacker create a
custom device (devices of these types are not readily available in the
marketplace at this time).
The most common, legitimate use for DMA ports is developer
debugging, a task that some developers need to perform and one
that few consumers will ever perform. Because USB; DisplayPort; and
other, more secure port types satisfy consumers, most new mobile
PCs do not include DMA ports. Microsofts view is that because of
NOTE
Not all port types
are vulnerable to
DMA attacks. USB in
particular does not
allow DMA, but devices
that have any of the
following port types
are vulnerable:
FireWire
Thunderbolt
ExpressCard
PCMCIA
PCI
PCI-X
PCI Express
7 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
the inherent security risks of DMA ports, they do not belong on
mobile devices, and Microsoft has prohibited their inclusion on
any InstantGo-certifed devices. InstantGo devices offer mobile
phonelike power management and instant-on capabilities; at the
time of writing, they are primarily found in Windows tablets. In 2014,
Microsoft expects to see InstantGo trickle down into more mobile
device types, such as convertibles and traditional laptops.
DMA-based expansion slots are another avenue of attack, but these
slots generally appear only on desktop PCs that are designed for
expansion. Organizations can use physical security to prevent outside
attacks against their desktop PCs. In addition, a DMA attack on the
expansion slot would require a custom device; as a result, an attacker
would most likely insert an interface with a traditional DMA port (for
example, FireWire) into the slot to attack the PC.
New to Windows 8.1 is a capability by which Windows wont enable
newly attached DMA devices until the operating system starts and a
user signs in. Every time the PC switches to suspend, hibernation, or
sleep mode, Windows waits for the user to sign in before granting
new devices DMA access. This delay helps prevent DMA attacks when
an authorized user isnt present. This new Windows 8.1 behavior
successfully mitigates the DMA attack vector and eliminates the need
for pre-boot authentication in most scenarios. Another option is for
administrators to confgure policy settings to disable FireWire and
other device types that have DMA; many PCs allow those devices to
be disabled by using frmware settings. Although the need for pre-
boot authentication can be eliminated at the device level or through
Windows confguration, the BitLocker pre-boot authentication
feature is still available when needed. When used, it successfully
mitigates all types of DMA port and expansion slot attacks on any
type of device.
Hyberfl.sys attacks
The hyberfl.sys fle is the Windows hibernation fle. It contains a
snapshot of system memory that is generated when a device goes
into hibernation and includes the encryption key for BitLocker and
other encryption technologies. Attackers have claimed that they have
successfully extracted encryption keys from the hyberfl.sys fle.
Windows 8.1 waits
for the user to sign in
before granting new
devices DMA access.
This new behavior
successfully mitigates
the DMA attack vector.
8 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Like the DMA port attack discussed in the previous section, tools are available that can scan the
hyberfle.sys fle and locate the encryption key, including a tool made by Passware. Microsoft does
not consider Windows to be vulnerable to this type of attack, because Windows stores the hyberfl.
sys fle within the encrypted system volume. As a result, the fle would be accessible only if the
attacker had both physical and sign-in access to the PC. When an attacker has sign-in access to the
PC, there are few reasons for the attacker to decrypt the drive, because they would already have
full access to the data within it.
In practice, the only reason an attack on hyberfl.sys would grant an attacker additional access is if
an administrator had changed the default Windows confguration and stored the hyberfl.sys fle
on an unencrypted drive. By default, both Windows 8 and Windows 7 are designed to be secure
against this type of attack.
Memory remanence attacks
A memory remanence attack is a side-channel attack that reads the encryption key from memory
after restarting a PC. Although a PCs memory is often considered to be cleared when the PC
is restarted, memory chips dont immediately lose their memory when you disconnect power.
Therefore, an attacker who has physical access to the PCs memory might be able to read data
directly from the memoryincluding the encryption key.
When performing this type of cold boot attack, the attacker accesses the PCs physical memory
and recovers the encryption key within a few seconds or minutes of disconnecting power. This type
of attack was demonstrated by researchers at Princeton University. With the encryption key, the
attacker would be able to decrypt the drive and access its fles.
To acquire the keys, attackers follow this process:
1. Freeze the PCs memory. For example, an attacker can freeze the memory to 50C by
spraying it with aerosol air duster spray.
2. Restart the PC.
3. Instead of restarting Windows, boot to another operating system. Typically, this is done by
connecting a bootable fash drive or loading a bootable DVD.
4. The bootable media loads the memory remanence attack tools, which the attacker uses to
scan the system memory and locate the encryption keys.
5. The attacker uses the encryption keys to access the drives data.
9 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
If the attacker is unable to boot the device to another operating system (for example, if bootable
fash drives have been disabled or UEFI Secure Boot is enabled), the attacker can attempt to
physically remove the frozen memory from the device and attach it to a different, possibly
identical device. Fortunately, this process has proven extremely unreliable, as evidenced by the
Defence Research and Development Canada (DRDC) Valcartier groups analysis (see An in-depth
analysis of the cold boot attack at http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078). On
an increasing portion of modern devices, this type of attack is not even possible, because memory
is soldered directly to the motherboard.
Although Princetons research proved that this type of attack was possible on devices that have
removable memory, device hardware has changed since the research was published in 2008:
Windows 8certifed devices include UEFI-based Secure Boot, which prevents the malicious
tools that the Princeton attack depends on from running on the target device.
Windows 8 and Windows 7 systems with BIOS or UEFI can be locked down with a password,
and booting to a USB drive can be prevented.
If booting to USB is required on the device, it can be limited to starting trusted operating
systems on Windows 8certifed devices (UEFI-based Secure Boot).
The discharge rates of memory are highly variable among devices, and many devices have
memory that is completely immune to memory remanence attacks.
Increased density of memory diminishes their remanence properties and reduces the
likelihood that the attack can be successfully executed, even when memory is physically
removed and placed in an identical system where the systems confguration may enable
booting to the malicious tools.
Because of these factors, this type of attack is rarely possible on modern devices. Even in cases
where the risk factors exist on legacy devices, attackers will fnd the attack unreliable. For detailed
information about the practical uses for forensic memory acquisition and the factors that make a
computer vulnerable or resistant to memory remanence attacks, read An in-depth analysis of the
cold boot attack at http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078.
The BitLocker pre-boot authentication feature can successfully mitigate memory remanence
attacks on most devices, but you can also mitigate such attacks by protecting the system UEFI
or BIOS and prevent the PC from booting from external media (such as a USB fash drive or
DVD). The latter option is often a better choice, because it provides suffcient protection without
inconveniencing users with pre-boot authentication.
10 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Countermeasures
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 computers 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 fxed 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 fash drive). Turning on BitLocker for your operating system
drive encrypts all system fles on the operating system drive, including the swap fles and
hibernation fles.
Ensuring the integrity of early boot components and boot confguration data On
Windows 7certifed 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
computers boot components appear unaltered and the encrypted disk is located in the
original computer. On Windows 8certifed 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 fnally 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 8certifed devices support all of these features.
Trusted Platform Module
Software alone isnt suffcient 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 diffcult to modify.
11 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
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, theyll probably destroy the chip in the process.
By binding the BitLocker encryption key with the TPM and properly
confguring the device, its nearly impossible for an attacker to
gain access to the BitLocker-encrypted data without obtaining an
authorized users 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 suffcient 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 systems boot-related components.
UEFI and Secure Boot
No operating system can protect a device when the operating system
is offine. For that reason, Microsoft worked closely with hardware
vendors to require frmware-level protection against boot and
rootkits that might compromise an encryption solutions encryption
keys in all Windows 8certifed 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 systems bootloader. As part of its introduction into
the preoperating system environment, UEFI serves a number of
purposes, but one of the key benefts 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 8certifed devices) can verify the digital signatures
By binding the
BitLocker encryption
key with the TPM and
properly confguring
the device, its nearly
impossible for an
attacker to gain access
to the BitLocker-
encrypted data
without obtaining
an authorized users
credentials.
12 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
of the devices frmware before running it. Because only the PCs
hardware manufacturer has access to the digital certifcate required
to create a valid frmware signature, UEFI can prevent frmware-based
bootkits. Thus, UEFI is the frst link in the chain of trust.
The UEFI-based Secure Boot feature is the foundation of
platform and frmware security and was created to enhance
security in the pre-boot environment regardless of device
architecture. Using signatures to validate the integrity of
frmware 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 frmware and bootloaders
(signed or unsigned) from being able to start on the system.
With the legacy BIOS boot process, the preoperating 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.
With Secure Boot enabled, UEFI, in coordination with the TPM, can
examine the bootloader and determine whether its trustworthy. To
determine whether the bootloader is trustworthy, UEFI examines the
bootloaders digital signature. Using the digital signature, the UEFI:
Verifes that the bootloader hasnt been
modifed since it was signed
Verifes that the bootloader was signed using a trusted
certifcate (in the case of Windows 8, Microsofts certifcate)
If the bootloader passes these two tests, the UEFI
knows that the bootloader isnt a bootkit and starts
FIGURE 1 The BIOS and
UEFI startup processes
BIOS
UEFI
Verified
OS loader
Any OS loader
(including malware)
OS Start
OS Start
13 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
it. At this point, Windows 8.1s Trusted Boot feature takes over, and the Windows 8
bootloader, using the same cryptographic technologies that UEFI used to verify the
bootloader, then verifes that the Windows system fles havent been changed.
All Windows 8certifed devices must meet several requirements
related to UEFI-based Secure Boot:
They must have Secure Boot enabled by default.
They must trust Microsofts certifcate (and thus any bootloader Microsoft has signed).
They must allow the user to confgure 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 certifed bootloader Because all Certifed for Windows 8
PCs must trust Microsofts certifcate, Microsoft offers a service to analyze and sign non-
Microsoft bootloaders so that they can be trusted by all Certifed for Windows 8 PCs. The
Linux community is using this process to enable Linux to take advantage of UEFI Secure Boot
on Windows-certifed devices.
Confgure UEFI to trust your custom bootloader All Certifed for Windows 8 PCs allow you
to trust a signed, noncertifed bootloader that you specify in the UEFI database, allowing you
to run any operating system, including homemade operating systems.
Turn off Secure Boot All Certifed 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 confgure the UEFI
frmware to trust a noncertifed bootloader or to turn off Secure Boot. Software cannot change the
Secure Boot settings.
Any device that doesnt require Secure Boot or a similar bootloader-verifcation 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 8certifed devices have UEFI-based
Secure Boot enabled.
UEFI is secure by design, but its critical to protect the Secure Boot confguration by using password
protection. In addition, although several well-publicized attacks against UEFI have occurred,
14 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
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 at http://
technet.microsoft.com/en-US/windows/dn168167.aspx.
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 fles. BitLocker accesses and stores the encryption key
in memory only after a user provides a specifc PIN or USB startup key.
If Windows cant access the encryption key, the device cant read or edit the fles on the system
drive. Even if an attacker takes the disk out of the PC or steals the entire PC, they wont be able
to read or edit the fles 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 specifcally designed to prevent the
operating system from starting: Thats merely a side effect of how BitLocker protects data
confdentiality 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 fles, 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 fash 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.
15 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
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 fash drive, and a PIN is required to
authenticate the user to the TPM. This confguration 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 recommends using pre-boot
authentication only on PCs running Windows 7 that have an enabled DMA port or any device that
is susceptible to memory remanence attacks.
Although effective, pre-boot authentication is inconvenient to users. In addition, if a
user forgets their PIN or loses their startup key, theyre denied access to their data until
they can contact their organizations support team to obtain a recovery key. Today,
most new PCs running Windows 8.1 or Windows 8 provide suffcient 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) certifcation from
Microsoft, new devices cant include a DMA port, eliminating the need for pre-boot authentication
to mitigate against a DMA port attack in most tablets and other Windows 8certifed devices.
Although this certifcation is currently implemented only on tablet devices, starting in 2014,
Microsoft expects to see devices such as convertibles and laptops certifed for InstantGo.
BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports,
should be confgured with pre-boot authentication if they are running Windows 7. Windows 8.1
devices do not need pre-boot authentication to protect against the most commonly used
DMA attack vectors because newly attached DMA devices get DMA access only after a user
authenticates and signs into Windows. Many customers fnd 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 bootstyle 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.
16 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
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
frmware password to prevent the attacker from changing that option.
Windows 8.1 or Windows 8 (certifed or with Secure Boot) Password protect the frmware,
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 Anti-
Malware (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 offduring the operating system
initialization phase. The bootloader verifes the digital signature of the Windows 8 kernel before
loading it. The Windows 8 kernel, in turn, verifes every other component of the Windows startup
process, including the boot drivers, startup fles, and ELAM driver. If a fle has been modifed 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, its possible for malware to
compromise the startup processprior to Windows starting, at which point
Trusted Boot protections could be bypassed or potentially disabled.
Early Launch Anti-Malware
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 dont 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 fagged as boot-
start can be executed. This approach provides the ability for an antimalware driver to register as a
17 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
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 classifcation that the ELAM
driver returns according to an initialization policy. IT pros have the ability to change this policy
through Group Policy.
ELAM classifes drivers as follows:
Good The driver has been signed and has
not been tampered with.
Bad The driver has been identifed as
malware. It is recommended that you not
allow known bad drivers to be initialized.
Bad but required for boot The driver
has been identifed 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 classifed by the ELAM boot-
start driver.
Protection after startup: DMA attack protection
Windows 8.1 minimizes the risk of DMA attacks by preventing newly attached DMA devices from
gaining DMA until a user authenticates by signing-in. This doesnt eliminate the risk, but it does
reduce the risk of an attacker connecting a DMA device to a PC and retrieving the encryption key
while the user is away from the PC.
To successfully perform a DMA attack on a Windows 8.1 device, the attacker would need a
malicious DMA device connected to the PC while the user was logged on. The attacker would not
simply be able to attach a DMA device when the user was at the PC, retrieve the encryption key,
and then leave with the device. The attacker would either need to:
Attach the device while the user was logged on
Attach the device at any time, wait for the user to log
on, and then return to retrieve the device
Windows 8 InstantGocertifed devices do not have DMA ports, eliminating the risk of DMA
attacks. On other devices, you might be able to disable FireWire, Thunderbolt, or other ports that
support DMA.
18 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Choosing the right countermeasures
Figure 2, Figure 3 on page 19, and Figure 4 on page 20 summarize the recommended
mitigations for different types of attacks against PCs running recent versions of Windows. The
orange blocks indicate that the system requires additional confguration from the default settings.
FIGURE 2 How to choose
the best countermeasures
for Windows 7
Windows 7
without TPM
Bootkits and
Rootkits
Without TPM, boot
integrity checking is
not available
Secure by default, and can
be improved with account
lockout Group Policy
Check devices for DMA
ports. Consider disabling
ports if not in use or require
BitLocker with pre-boot
authentication
Secure by default,
hyberfil.sys secured on
encrypted volume
Require a BIOS password
and disable booting from
external media. If an attack
is viable, consider pre-boot
authentication
Secure by default. Require
BitLocker with TPM for boot
integrity validation
Secure by default, and can
be improved with account
lockout Group Policy
Secure by default,
hyberfil.sys secured on
encrypted volume
Require a BIOS password
and disable booting from
external media. If an attack
is viable, consider pre-boot
authentication
Brute Force
Sign-in
DMA
Attacks
Hyberfil.sys
Attacks
Memory
Remanence
Attacks
Windows 7
with TPM
Check devices for DMA
ports. Consider disabling
ports if not in use or require
BitLocker with pre-boot
authentication
19 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS

FIGURE 3 How to choose
the best countermeasures
for Windows 8
Bootkits and
Rootkits
Without TPM, boot
integrity checking is
not available
Secure by default, and can
be improved with account
lockout Group Policy
Check devices for DMA
ports. Consider disabling
ports if not in use or require
BitLocker with pre-boot
authentication
Secure by default,
hyberfil.sys secured on
encrypted volume
Require a BIOS password
and disable booting from
external media. If an attack
is viable, consider pre-boot
authentication
Secure by default when
UEFI-based Secure Boot
is enabled and a password
is required to change
settings
Secure by default, and can
be improved with account
lockout and device lockout
Group Policy settings
Check devices for DMA
ports. Consider disabling
ports if not in use or require
BitLocker with pre-boot
authentication
Secure by default,
hyberfil.sys secured on
encrypted volume
Password protect the
firmware and ensure
Secure Boot is enabled. If
an attack is viable, consider
pre-boot authentication
Brute Force
Sign-in
DMA
Attacks
Hyberfil.sys
Attacks
Memory
Remanence
Attacks
Windows 8
without TPM
Windows 8
Certified
20 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
FIGURE 4 How to choose
the best countermeasures
for Windows 8.1
Bootkits and
Rootkits
Secure by default, and can
be improved with account
lockout Group Policy
Secure by default for all lost
or stolen devices because
new DMA devices are
granted access only when an
authorized user is signed in
Secure by default,
hyberfil.sys secured on
encrypted volume
Require a BIOS password
and disable booting from
external media. If an attack
is viable, consider pre-boot
authentication
Secure by default, and can
be improved with account
lockout and device lockout
Group Policy settings
Secure by default for all lost
or stolen devices because
new DMA devices are
granted access only when an
authorized user is signed in
Secure by default,
hyberfil.sys secured on
encrypted volume
Password protect the
firmware and ensure
Secure Boot is enabled. If
an attack is viable, consider
pre-boot authentication
Brute Force
Sign-in
DMA
Attacks
Hyberfil.sys
Attacks
Memory
Remanence
Attacks
Windows 8.1
without TPM
Windows 8.1
Certified
Without TPM, boot
integrity checking is
not available
Secure by default when
UEFI-based Secure Boot
is enabled and a password
is required to change
settings
21 PROTECTING BITLOCKER-ENCRYPTED DEVICES FROM ATTACKS
Summary
You can use BitLocker to protect your Windows 8.1, Windows 8, and Windows 6
client PCs. Whichever operating system youre using, Microsoft and Windows-
certifed devices provide countermeasures to address attacks and improve your
data security. In most cases, particularly on Windows 8 devices, this protection
can be implemented without the need for pre-boot authentication.
The latest Windows 8.1 InstantGo devices, primarily tablets, are designed to be secure by default
against all attacks that might compromise the BitLocker encryption key. Other Windows 8.1
devices can be, too. DMA portbased attacks, which represent the attack vector of choice, are not
possible on InstantGo devices, on which these port types are prohibited. DMA ports on even non-
InstantGo devices is increasingly rare, particularly on mobile devices. Regardless of the hardware
confguration, the risk of DMA attacks has been addressed in Windows 8.1 itself, which has been
updated to prevent new DMA devices that have been attached to a device from gaining DMA until
an authorized user signs-in. DMA ports can even be disabled entirely, which is increasingly popular
option because the use of DMA ports is rare in the non-developer space.
Memory remanence attacks can be mitigated with proper confguration; in cases where the
system memory is fxed and non-removable, they are not possible using published techniques.
Even in cases where system memory can be removed and loaded into another device, attackers
will fnd the attack vector extremely unreliable, as has been shown in the DRDC Valcartier groups
analysis (see An in-depth analysis of the cold boot attack at http://www.dtic.mil/cgi-bin/
GetTRDoc?AD=ADA545078).
Windows 7 PCs share the same security risks as Windows 8 devices but are far more vulnerable
to DMA and memory remanence attacks, because Windows 7 devices are more likely to include
DMA ports, lack support for UEFI-based Secure Boot, and rarely have fxed memory. To eliminate
the need for pre-boot authentication on Windows 7 devices, disable the ability to boot to external
media, password-protect the BIOS confguration, and disable the DMA ports. If you believe that
your devices may be a target of a memory remanence attack, where the system memory may be
removed and put into another machine to gain access to its contents, consider testing your devices
to determine whether they are susceptible to this type of attack.
In the end, many customers will fnd that pre-boot authentication improves
security only for a shrinking subset of devices within their organization. Microsoft
recommends a careful examination of the attack vectors and mitigations outlined in
this document along with an evaluation of your devices before choosing to implement
pre-boot authentication, which may not enhance the security of your devices and
instead will only compromise the user experience and add to support costs.
2014 Microsoft Corporation. All rights reserved.
This document is for informational purposes only and
is provided as is. Views expressed in this document,
including URL and any other Internet Web site references,
may change without notice. MICROSOFT MAKES NO
WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.