-
-
-
-
-
-
- |
-
- Windows 8.1
without TPM |
-
- Windows 8.1 Certified
(with TPM) |
-
-
-|
- Bootkits and
Rootkits |
-Without TPM, boot integrity checking is not available |
-Secure by default when UEFI-based Secure Boot is enabled and a firmware password is required to change settings |
-
-
-|
- Brute Force
Sign-in |
-Secure by default, and can be improved with account lockout Group Policy |
-Secure by default, and can be improved with account lockout and device lockout Group Policy settings |
-
-
-|
- DMA
Attacks |
-If policy is deployed, secure by default for all lost or stolen devices because new DMA devices are granted access only when an authorized user is signed in |
-If policy is deployed, secure by default for all lost or stolen devices because new DMA devices are granted access only when an authorized user is signed in |
-
-
-|
- Hyberfil.sys
Attacks |
-Secure by default; hyberfil.sys secured on encrypted volume |
-Secure by default; hyberfil.sys secured on encrypted volume |
-
-
-|
- Memory
Remanence
Attacks |
-Password protect the firmware and disable booting from external media. If an attack is viable, consider pre-boot authentication |
-Password protect the firmware and ensure Secure Boot is enabled. If an attack is viable, consider pre-boot authentication |
-
-
-
-**Table 1.** How to choose the best countermeasures for Windows 8.1
-
-
-
-
-
-
- |
-
- Windows 10
without TPM |
-
- Windows 10 Certified
(with TPM) |
-
-
-|
- Bootkits and
Rootkits |
-Without TPM, boot integrity checking is not available |
-Secure by default when UEFI-based Secure Boot is enabled and a firmware password is required to change settings |
-
-
-|
- Brute Force
Sign-in |
-Secure by default, and can be improved with account lockout Group Policy |
-Secure by default, and can be improved with account lockout and device lockout Group Policy settings |
-
-
-|
- DMA
Attacks |
-If policy is deployed, 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; certified devices do not expose vulnerable DMA busses.
Can be additionally secured by deploying policy to restrict DMA devices:
-
- |
-
-
-|
- Hyberfil.sys
Attacks |
-Secure by default; hyberfil.sys secured on encrypted volume |
-Secure by default; hyberfil.sys secured on encrypted volume |
-
-
-|
- Memory
Remanence
Attacks |
-Password protect the firmware and disable booting from external media. If an attack is viable, consider pre-boot authentication |
-Password protect the firmware and ensure Secure Boot is enabled.
The most effective mitigation, which we advise for high-security devices, is to configure a TPM+PIN protector, disable Standby power management, and shut down or hibernate the device before it leaves the control of an authorized user. |
-
-
-
-**Table 2.** How to choose the best countermeasures for Windows 10
-
-The latest Modern Standby devices, primarily tablets, are designed to be secure by default against all attacks that might compromise the BitLocker encryption key. Other Windows devices can be secure by default too. DMA port–based attacks, which represent the attack vector of choice, are not possible on Modern Standby devices because these port types are prohibited. The inclusion of DMA ports on even non-Modern Standby devices is extremely rare on recent devices, particularly on mobile ones. This could change if Thunderbolt is broadly adopted, so IT should consider this when purchasing new devices. In any case, DMA ports can be disabled entirely, which is an increasingly popular option because the use of DMA ports is infrequent in the non-developer space. To prevent DMA port usage unless an authorized user is signed in, you can set the DataProtection/AllowDirectMemoryAccess policy by using Mobile Device Management (MDM) or the Group Policy setting **Disable new DMA devices when this computer is locked** (beginning with Windows 10, version 1703). This setting is **Not configured** by default. The path to the Group Policy setting is:
-
-**Computer Configuration|Administrative Templates|Windows Components|BitLocker Drive Encryption**
-
-Memory remanence attacks can be mitigated with proper configuration; in cases where the system memory is fixed 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 find the attack vector extremely unreliable, as has been shown in the DRDC Valcartier group’s analysis (see [An In-depth Analysis of the Cold Boot Attack](http://www.dtic.mil/cgi-bin/GetTRDoc?AD=ADA545078)).
-
-Windows 7 PCs share the same security risks as newer 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 fixed 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 configuration, 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 computer 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 find 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.
-
-## See also
-- [Types of attacks for volume encryption keys](types-of-attacks-for-volume-encryption-keys.md)
-- [BitLocker Countermeasures](bitlocker-countermeasures.md)
-- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
-- [BitLocker overview](bitlocker-overview.md)
-
-
diff --git a/windows/security/information-protection/bitlocker/images/kernel-dma-protection.png b/windows/security/information-protection/bitlocker/images/kernel-dma-protection.png
new file mode 100644
index 0000000000..297809afdc
Binary files /dev/null and b/windows/security/information-protection/bitlocker/images/kernel-dma-protection.png differ
diff --git a/windows/security/information-protection/bitlocker/images/pre-boot-authentication-group-policy.png b/windows/security/information-protection/bitlocker/images/pre-boot-authentication-group-policy.png
new file mode 100644
index 0000000000..94d0720c76
Binary files /dev/null and b/windows/security/information-protection/bitlocker/images/pre-boot-authentication-group-policy.png differ
diff --git a/windows/security/information-protection/bitlocker/protect-bitlocker-from-pre-boot-attacks.md b/windows/security/information-protection/bitlocker/protect-bitlocker-from-pre-boot-attacks.md
deleted file mode 100644
index d67cd69a82..0000000000
--- a/windows/security/information-protection/bitlocker/protect-bitlocker-from-pre-boot-attacks.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Protect BitLocker from pre-boot attacks (Windows 10)
-description: This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration.
-ms.assetid: 24d19988-fc79-4c45-b392-b39cba4ec86b
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: security
-author: brianlic-msft
-ms.date: 04/19/2017
----
-# Protect BitLocker from pre-boot attacks
-
-
-**Applies to**
-- Windows 10
-
-This detailed guide will help you understand the circumstances under which the use of pre-boot authentication is recommended for devices running Windows 10, Windows 8.1, Windows 8, or Windows 7; and when it can be safely omitted from a device’s configuration.
-
-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 system’s integrity, disk encryption solution (for example, encryption keys), and the PC’s data from offline 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 flash drive as a key.
-
-Full-volume encryption using BitLocker Drive Encryption is vital for protecting data and system integrity on devices running the Windows 10, Windows 8.1, Windows 8, or Windows 7 operating system. It is equally important to protect the BitLocker encryption key. On Windows 7 devices, sufficiently protecting that key often required pre-boot authentication, which many users find inconvenient and complicates device management.
-
-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 (in other words, shut down 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 can’t access their PC without a recovery key. With a properly configured infrastructure, the organization’s support will be able to provide the recovery key, but doing so increases support costs, and users might lose hours of productive work time.
-
-Starting with Windows 8, 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 devices are fundamentally physically resistant to sophisticated attacks against the computer’s memory, and now Windows authenticates the user before making devices that may represent a threat to the device and encryption keys available for use.
-
-## In this topic
-
-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.
-
-- [Types of attacks for volume encryption keys](types-of-attacks-for-volume-encryption-keys.md)
-- [BitLocker countermeasures](bitlocker-countermeasures.md)
-- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
-
-## See also
-
-- [BitLocker overview](bitlocker-overview.md)
-
-
diff --git a/windows/security/information-protection/bitlocker/types-of-attacks-for-volume-encryption-keys.md b/windows/security/information-protection/bitlocker/types-of-attacks-for-volume-encryption-keys.md
deleted file mode 100644
index d96b30a8c5..0000000000
--- a/windows/security/information-protection/bitlocker/types-of-attacks-for-volume-encryption-keys.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Types of attacks for volume encryption keys (Windows 10)
-description: There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware Interface (UEFI) secure boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account lockouts.
-ms.assetid: 405060a9-2009-44fc-9f84-66edad32c6bc
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: security
-author: brianlic-msft
-ms.date: 10/27/2017
----
-
-# Types of attacks for volume encryption keys
-
-**Applies to**
-- Windows 10
-
-There are many ways Windows helps protect your organization from attacks, including Unified Extensible Firmware Interface (UEFI) Secure Boot, Trusted Platform Module (TPM), Group Policy, complex passwords, and account lockouts.
-
-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 offline. Each section begins with a graphical overview of the attack’s strengths and weaknesses as well as suggested mitigations.
-
-### 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 files, 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 malware’s 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 PC’s BIOS firmware, giving the malware low-level access and potentially the ability to install or hide malware, even if it’s cleaned or removed from the hard disk.
-
-Regardless of the operating system or encryption method, rootkits have access to confidential data once installed. Application-level rootkits can read any files the user can access, bypassing volume-level encryption. Kernel-, library-, hypervisor-, and firmware-level rootkits have direct access to system files on encrypted volumes and can also retrieve an encryption key from memory.
-
-Windows 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 offline. For example, an attacker might boot a PC from a USB flash drive containing malware that starts before Windows. The malware can replace system files or the PC’s firmware or simply start Windows under its control.
-
-To sufficiently protect a PC from boot and rootkits, devices must use pre-boot authentication or Secure Boot, or the encryption solution must use the device’s 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. On devices with Secure Boot enabled, you do not need to use pre-boot authentication to protect against boot and rootkit attacks.
-
-Although password protection of the UEFI configuration is important for protecting a device’s configuration and preventing an attacker from disabling Secure Boot, use of a TPM and its Platform Configuration Register (PCR) measurements (PCR7) to ensure that the system’s bootloader (whether a Windows or non-Microsoft encryption solution) is tamper free and the first code to start on the device is critical. An encryption solution that doesn’t use a device’s TPM to protect its components from tampering may be unable to protect itself from bootkit-level infections that could log a user’s password or acquire encryption keys.
-
-For this reason, when BitLocker is configured on devices that include a TPM, the TPM and its PCRs are always used to secure and confirm the integrity of the pre–operating system environment before making encrypted volumes accessible.
-
-Any change to the UEFI configuration invalidates the PCR7 and requires the user to enter the BitLocker recovery key. Because of this feature, it’s not critical to password-protect your UEFI configuration. 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 find any password if you allow them to guess enough times. The process of trying millions of different passwords until you find 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 user’s BitLocker PIN or an equivalent authenticator. The TPM mitigates this approach by invoking an anti-hammering 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. Specifically, 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 configure Windows 8.1 and Windows 8 to automatically restart and require the user to enter the BitLocker 48-digit recovery key after a specified 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 device’s system memory. For example, if you use Thunderbolt to connect another device to your computer, the second device automatically has Read and Write access to the target computer’s memory.
-
-Unfortunately, DMA ports don’t use authentication and access control to protect the contents of the computer’s memory. Whereas Windows can often prevent 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](http://www.lostpassword.com/), [ElcomSoft](http://elcomsoft.com/), and
-others, and then use a DMA attack to read confidential data from a PC’s memory. Because encryption solutions store their encryption keys in memory, they can be accessed by a DMA attack.
-
-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
-
-To perform a DMA attack, attackers typically connect a second PC that is running a memory-scanning tool (for example, 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 efficient 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 flash drive and distribute it to employees of a target organization. When connected, the attacking device could use a DMA attack to scan the PC’s memory for the encryption key. It could then transmit the key (or any data in the PC’s memory) using the PC’s 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).
-
-Today, one of the most common uses for DMA ports on Windows devices is for 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. Microsoft’s view is that because of the inherent security risks of DMA ports, they do not belong on mobile devices, and Microsoft has prohibited their inclusion on any Modern Standby-certified devices. Modern Standby devices offer mobile phone–like power management and instant-on capabilities; at the time of writing, they are primarily found in Windows tablets.
-
-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.
-
-To mitigate a port-based DMA attack an administrator can configure policy settings to disable FireWire and other device types that have DMA. Also, many PCs allow those devices to be disabled by using firmware settings. Although the need for pre-boot authentication can be eliminated at the device level or through Windows configuration, 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.
-
-### Hiberfil.sys Attacks
-
-The hiberfil.sys file is the Windows hibernation file. 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 hiberfil.sys file.
-
-Like the DMA port attack discussed in the previous section, tools are available that can scan the hiberfile.sys file and locate the encryption key, including a tool made by [Passware](http://www.lostpassword.com/). Microsoft does not consider Windows to be vulnerable to this type of attack, because Windows stores the hiberfil.sys file within the encrypted system volume. As a result, the file 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 hiberfil.sys would grant an attacker additional access is if an administrator had changed the default Windows configuration and stored the hiberfil.sys file on an unencrypted drive. By default, Windows 10 is 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 PC’s memory is often considered to be cleared when the PC is restarted, memory chips don’t immediately lose their memory when you disconnect power. Therefore, an attacker who has physical access to the PC’s memory might be able to read data directly from the memory—including the encryption key.
-
-When performing this type of cold boot attack, the attacker accesses the PC’s 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](http://www.youtube.com/watch?v=JDaicPIgn9U). With the encryption key, the attacker would be able to decrypt the drive and access its files.
-
-To acquire the keys, attackers follow this process:
-
-1. Freeze the PC’s memory. For example, an attacker can freeze the memory to −50°C 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 flash 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 drive’s data.
-
-If the attacker is unable to boot the device to another operating system (for example, if bootable flash drives have been disabled or 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 group’s analysis (see [An In-depth Analysis of the Cold Boot Attack](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 Princeton’s 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:
-
-- Secure Boot prevents the malicious tools that the Princeton attack depends on from running on the target device.
-- Windows 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 by using 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 system’s configuration 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 find the attack unreliable. For detailed info 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](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 flash drive or DVD). The latter option is often a better choice, because it provides sufficient protection without inconveniencing users with pre-boot authentication.
-
-## See also
-
-- [BitLocker countermeasures](bitlocker-countermeasures.md)
-- [Choose the right BitLocker countermeasure](choose-the-right-bitlocker-countermeasure.md)
-- [Protect BitLocker from pre-boot attacks](protect-bitlocker-from-pre-boot-attacks.md)
-- [BitLocker overview](bitlocker-overview.md)