Merge remote-tracking branch 'origin/master' into vsts17546553

This commit is contained in:
Justin Hall
2018-09-17 15:31:33 -07:00
167 changed files with 9766 additions and 8556 deletions

View File

@ -22,14 +22,13 @@
### [BitLocker Group Policy settings](bitlocker\bitlocker-group-policy-settings.md)
### [BCD settings and BitLocker](bitlocker\bcd-settings-and-bitlocker.md)
### [BitLocker Recovery Guide](bitlocker\bitlocker-recovery-guide-plan.md)
### [Protect BitLocker from pre-boot attacks](bitlocker\protect-bitlocker-from-pre-boot-attacks.md)
#### [Types of attacks for volume encryption keys](bitlocker\types-of-attacks-for-volume-encryption-keys.md)
#### [BitLocker Countermeasures](bitlocker\bitlocker-countermeasures.md)
#### [Choose the Right BitLocker Countermeasure](bitlocker\choose-the-right-bitlocker-countermeasure.md)
### [BitLocker Countermeasures](bitlocker\bitlocker-countermeasures.md)
### [Protecting cluster shared volumes and storage area networks with BitLocker](bitlocker\protecting-cluster-shared-volumes-and-storage-area-networks-with-bitlocker.md)
## [Encrypted Hard Drive](encrypted-hard-drive.md)
## [Kernel DMA Protection for Thunderbolt™ 3](kernel-dma-protection-for-thunderbolt.md)
## [Protect your enterprise data using Windows Information Protection (WIP)](windows-information-protection\protect-enterprise-data-using-wip.md)
### [Create a WIP policy using Microsoft Intune](windows-information-protection\overview-create-wip-policy.md)
#### [Create a WIP policy using the classic console for Microsoft Intune](windows-information-protection\create-wip-policy-using-intune.md)
@ -63,9 +62,6 @@
### [How Windows 10 uses the TPM](tpm/how-windows-uses-the-tpm.md)
### [TPM Group Policy settings](tpm/trusted-platform-module-services-group-policy-settings.md)
### [Back up the TPM recovery information to AD DS](tpm/backup-tpm-recovery-information-to-ad-ds.md)
### [Manage TPM commands](tpm/manage-tpm-commands.md)
### [Manage TPM lockout](tpm/manage-tpm-lockout.md)
### [Change the TPM owner password](tpm/change-the-tpm-owner-password.md)
### [View status, clear, or troubleshoot the TPM](tpm/initialize-and-configure-ownership-of-the-tpm.md)
### [Understanding PCR banks on TPM 2.0 devices](tpm/switch-pcr-banks-on-tpm-2-0-devices.md)
### [TPM recommendations](tpm/tpm-recommendations.md)

View File

@ -7,137 +7,185 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 10/27/2017
ms.date: 09/06/2018
---
# BitLocker Countermeasures
**Applies to**
- Windows 10
Windows uses technologies including TPM, Secure Boot, Trusted Boot, and Early Launch Antimalware (ELAM) to protect against attacks on the BitLocker encryption key.
BitLocker is 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:
Windows uses technologies including Trusted Platform Module (TPM), Secure Boot, and Measured Boot to help protect BitLocker encryption keys against attacks.
BitLocker is part of a strategic approach to securing data against offline attacks through encryption technology.
Data on a lost or stolen computer is vulnerable.
For example, there could be unauthorized access, either by running a software attack tool against it or by transferring the computers hard disk to a different computer.
- **Encrypting the hard drives on your computer.** For example, you can turn on BitLocker for your operating system drive, a fixed data 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 devices that have a TPM version 1.2 or higher, 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.
BitLocker helps mitigate unauthorized data access on lost or stolen computers before the authorized operating system is started by:
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.
- **Encrypting volumes on your computer.** For example, you can turn on BitLocker for your operating system volume, or a volume on a fixed or removable data drive (such as a USB flash drive, SD card, and so on). Turning on BitLocker for your operating system volume encrypts all system files on the volume, including the paging files and hibernation files. The only exception is for the System partition, which includes the Windows Boot Manager and minimal boot collateral required for decryption of the operating system volume after the key is unsealed.
- **Ensuring the integrity of early boot components and boot configuration data.** On devices that have a TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to make data accessible only if the computers BIOS firmware code and configuration, original boot sequence, boot components, and BCD configuration all appear unaltered and the encrypted disk is located in the original computer. On systems that leverage TPM PCR[7], BCD setting changes deemed safe are permitted to improve usability.
 
The next sections provide more details about how Windows protects against various attacks on the BitLocker encryption keys in Windows 10, Windows 8.1, and Windows 8.
### Protection before startup
For more information about how to enable the best overall security configuration for devices beginning with Windows 10 version 1803, see [Standards for a highly secure Windows 10 device](https://docs.microsoft.com/windows-hardware/design/device-experiences/oem-highly-secure).
Before Windows starts, you must rely on security features implemented as part of the device hardware, including TPM and Secure Boot. Fortunately, many modern computers feature TPM.
## Protection before startup
#### Trusted Platform Module
Before Windows starts, you must rely on security features implemented as part of the device hardware and firmware, including TPM and Secure Boot. Fortunately, many modern computers feature a TPM and Secure Boot.
Software alone isnt 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.
### Trusted Platform Module
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 configuring 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.
For more info about TPM, see [Trusted Platform Module](/windows/device-security/tpm/trusted-platform-module-overview).
A TPM is a microchip designed to provide basic security-related functions, primarily involving encryption keys.
On some platforms, TPM can alternatively be implemented as a part of secure firmware.
BitLocker binds encryption keys with the TPM to ensure that a computer has not been tampered with while the system was offline.
For more info about TPM, see [Trusted Platform Module](https://docs.microsoft.com/windows/device-security/tpm/trusted-platform-module-overview).
#### UEFI and Secure Boot
### 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 solutions encryption keys.
Unified Extensible Firmware Interface (UEFI) is a programmable boot environment that initializes devices and starts the operating systems bootloader.
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 benefits is to protect newer devices against a sophisticated type of malware called a bootkit through the use of its Secure Boot feature.
The UEFI specification defines a firmware execution authentication process called [Secure Boot](https://docs.microsoft.com/windows/security/information-protection/secure-the-windows-10-boot-process).
Secure Boot blocks untrusted firmware and bootloaders (signed or unsigned) from being able to start on the system.
Recent implementations of UEFI (starting with version 2.3.1) can verify the digital signatures of the devices firmware before running it. Because only the PCs 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.
By default, BitLocker provides integrity protection for Secure Boot by utilizing the TPM PCR[7] measurement.
An unauthorized EFI firmware, EFI boot application, or bootloader cannot run and acquire the BitLocker key.
Secure Boot 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 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.
### BitLocker and reset attacks
![the bios and uefi startup processes](images/bitlockerprebootprotection-bios-uefi-startup.jpg)
To defend against malicious reset attacks, BitLocker leverages the TCG Reset Attack Mitigation, also known as MOR bit (Memory Overwrite Request), before extracting keys into memory.
**Figure 1.** The BIOS and UEFI startup processes
>[!NOTE]
>This does not protect against physical attacks where an attacker opens the case and attacks the hardware.
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, UEFI verifies that the bootloader was signed using a trusted certificate.
## Security policies
If the bootloader passes these two tests, UEFI knows that the bootloader isnt a bootkit and starts it. At this point, Trusted Boot takes over, and the Windows bootloader, using the same cryptographic technologies that UEFI used to verify the bootloader, then verifies that the Windows system files havent been changed.
The next sections cover pre-boot authentication and DMA policies that can provide additional protection for BitLocker.
Starting with Windows 8, certified devices must meet several requirements related to UEFI-based Secure Boot:
### Pre-boot authentication
- They must have Secure Boot enabled by default.
- They must trust Microsofts 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.
Pre-boot authentication with BitLocker is a policy setting that requires the use of either user input, such as a PIN, a startup key, or both to authenticate prior to making the contents of the system drive accessible.
The Group Policy setting is [Require additional authentication at startup](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings#a-href-idbkmk-unlockpol1arequire-additional-authentication-at-startup) and the corresponding setting in the [BitLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp) is SystemDrivesRequireStartupAuthentication.
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:
BitLocker accesses and stores the encryption keys in memory only after pre-boot authentication is completed.
If Windows cant access the encryption keys, the device cant read or edit the files on the system drive. The only option for bypassing pre-boot authentication is entering the recovery key.
- **Use an operating system with a certified bootloader.** Microsoft can analyze and sign non-Microsoft bootloaders so that they can be trusted. The Linux community is using this process to enable Linux to take advantage of
Secure Boot on Windows-certified devices.
- **Configure UEFI to trust your custom bootloader.** Your device can trust a signed, non-certified bootloader that you specify in the UEFI database, allowing you to run any operating system, including homemade operating systems.
- **Turn off Secure Boot.** You can turn off Secure Boot. 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 non-certified 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-verification technology, regardless of the architecture or operating system, is vulnerable to bootkits, which can be used to compromise the encryption solution.
UEFI is secure by design, but its 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.1 Boot Process](https://technet.microsoft.com/windows/dn168167.aspx).
### Protection during pre-boot: Pre-boot authentication
Pre-boot authentication with BitLocker is a process that requires the use of either a Trusted Platform Module (TPM), user input, such as a PIN, or both, depending on hardware and operating system configuration, 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 pre-boot authentication is completed using one or more of the following options: Trusted Platform Module (TPM), user provides a specific PIN, USB startup key.
If Windows cant access the encryption key, the device cant 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 wont 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: Thats 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.
Pre-boot authentication is designed to prevent the encryption keys from being loaded to system memory without the trusted user supplying another authentication factor such as a PIN or startup key.
This helps mitigate DMA and memory remanence attacks.
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.
- **TPM-only.** Using TPM-only validation does not require any interaction with the user to unlock and provide access to the drive. If the TPM validation succeeds, the user sign in experience is the same as a standard logon. If the TPM is missing or changed or if BitLocker detects changes to the BIOS or UEFI code or configuration, critical operating system startup files, or the boot configuration, BitLocker enters recovery mode, and the user must enter a recovery password to regain access to the data. This option is more convenient for sign-in but less secure than the other options, which require an additional authentication factor.
- **TPM with startup key.** In addition to the protection that the TPM-only 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. TPMs also have [anti-hammering protection](https://docs.microsoft.com/windows/security/hardware-protection/tpm/tpm-fundamentals#anti-hammering) that is designed to prevent brute force attacks that attempt to determine the PIN.
- **TPM with startup key and PIN.** In addition to the core component protection that the TPM-only 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.
In the following Group Policy example, TPM + PIN is required to unlock an operating system drive:
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 10, 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).
![Pre-boot authentication setting in Group Policy](images/pre-boot-authentication-group-policy.png)
BitLocker-encrypted devices with DMA ports enabled, including FireWire or Thunderbolt ports, should be configured with pre-boot authentication if they are running Windows 10, Windows 7, Windows 8, or Windows 8.1 and disabling the ports using policy or firmware configuration is not an option. 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 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.
Pre-boot authentication with a PIN can mitigate an attack vector for devices that use a bootable eDrive because an exposed eDrive bus can allow an attacker to capture the BitLocker encryption key during startup.
Pre-boot authentication with a PIN can also mitigate DMA port attacks 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.
You can mitigate the risk of booting to a malicious operating system:
On the other hand, Pre-boot authentication prompts can be inconvenient to users.
In addition, users who forget their PIN or lose their startup key are denied access to their data until they can contact their organizations support team to obtain a recovery key.
Pre-boot authentication can also make it more difficult to update unattended desktops and remotely administered servers because a PIN needs to be entered when a computer reboots or resumes from hibernation.
- **Windows 10 (without Secure Boot), 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 10, Windows 8.1, or Windows 8 (certified or with Secure Boot).** Password protect the firmware, and do not disable Secure Boot.
To address these issues, you can deploy [BitLocker Network Unlock](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock).
Network Unlock allows systems within the physical enterprise security perimeter that meet the hardware requirements and have BitLocker enabled with TPM+PIN to boot into Windows without user intervention.
It requires direct ethernet connectivity to an enterprise Windows Deployment Services (WDS) server.
### Protection During Startup
### Protecting Thunderbolt and other DMA ports
During the startup process, Windows 10 uses Trusted Boot and Early Launch Antimalware (ELAM) to examine the integrity of every component. The sections that follow describe these technologies in more detail.
There are a few different options to protect DMA ports, such as Thunderbolt™3.
Beginning with Windows 10 version 1803, new Intel-based devices have kernel protection against DMA attacks via Thunderbolt™ 3 ports enabled by default.
This kernel DMA protection is available only for new systems beginning with Windows 10 version 1803, as it requires changes in the system firmware and/or BIOS.
**Trusted Boot**
You can use the System Information desktop app (MSINFO32) to check if a device has kernel DMA protection enabled:
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 kernel before loading it. The Windows 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 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.
![Kernel DMA protection](images/kernel-dma-protection.png)
Windows 10 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 process prior to Windows starting, at which point Trusted Boot protections could be bypassed or potentially disabled.
If kernel DMA protection *not* enabled, follow these steps to protect Thunderbolt™ 3 enabled ports:
**Early Launch Antimalware**
1. Require a password for BIOS changes
2. Intel Thunderbolt Security must be set to User Authorization in BIOS settings
3. Additional DMA security may be added by deploying policy (beginning with Windows 10 version 1607):
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.
- MDM: [DataProtection/AllowDirectMemoryAccess](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-dataprotection#dataprotection-allowdirectmemoryaccess) policy
- Group Policy: [Disable new DMA devices when this computer is locked](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings#disable-new-dma-devices-when-this-computer-is-locked) (This setting is not configured by default.)
Early Launch Antimalware (ELAM) is designed to enable the antimalware solution to start before all non-Microsoft drivers and apps. ELAM checks the integrity of non-Microsoft drivers to determine whether the drivers are trustworthy. Because Windows needs to start as fast as possible, ELAM cannot be a complicated process of checking the driver files against known malware signatures. Instead, ELAM has the simple task of examining every boot driver and determining whether it is on the list of trusted drivers. If malware modifies a boot-related driver, ELAM will detect the change, and Windows will prevent the driver from starting, thus blocking driver-based rootkits. ELAM also allows the registered antimalware provider to scan drivers that are loaded after the boot process is complete.
For Thunderbolt v1 and v2 (DisplayPort Connector), refer to the “Thunderbolt Mitigation” section in [KB 2516445](https://support.microsoft.com/help/2516445/blocking-the-sbp-2-driver-and-thunderbolt-controllers-to-reduce-1394-d).
For SBP-2 and 1394 (a.k.a. Firewire), refer to the “SBP-2 Mitigation” section in [KB 2516445](https://support.microsoft.com/help/2516445/blocking-the-sbp-2-driver-and-thunderbolt-controllers-to-reduce-1394-d).
## Attack countermeasures
Windows Defender in Windows 10 supports ELAM, as do Microsoft System Center 2012 Endpoint Protection and non-Microsoft antimalware apps.
This section covers countermeasures for specific types attacks.
To do this, ELAM loads 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.
### Bootkits and rootkits
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:
A physically-present attacker might attempt to install a bootkit or rootkit-like piece of software into the boot chain in an attempt to steal the BitLocker keys.
The TPM should observe this installation via PCR measurements, and the BitLocker key will not be released.
This is the default configuration.
- **Good.** The driver has been signed and has not been tampered with.
- **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.
A BIOS password is recommended for defense-in-depth in case a BIOS exposes settings that may weaken the BitLocker security promise.
Intel Boot Guard and AMD Hardware Verified Boot support stronger implementations of Secure Boot that provide additional resilience against malware and physical attacks.
Intel Boot Guard and AMD Hardware Verified Boot are part of platform boot verification [standards for a highly secure Windows 10 device](https://docs.microsoft.com/windows-hardware/design/device-experiences/oem-highly-secure).
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.
### Brute force attacks against a PIN
Require TPM + PIN for anti-hammering protection.
### Protection After Startup: eliminate DMA availability
### DMA attacks
Windows Modern Standbycertified devices do not have DMA ports, eliminating the risk of DMA attacks. On other devices, you can disable FireWire, Thunderbolt, or other ports that support DMA.
See [Protecting Thunderbolt and other DMA ports](#protecting-thunderbolt-and-other-dma-ports) earlier in this topic.
## See also
- [Types of Attacks for Volume Encryption Keys](types-of-attacks-for-volume-encryption-keys.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)
### Paging file, crash dump, and Hyberfil.sys attacks
These files are secured on an encrypted volume by default when BitLocker is enabled on OS drives.
It also blocks automatic or manual attempts to move the paging file.
### Memory remanence
Enable Secure Boot and require a password to change BIOS settings.
For customers requiring protection against these advanced attacks, 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.
## Attacker countermeasures
The following sections cover mitigations for different types of attackers.
### Attacker without much skill or with limited physical access
Physical access may be limited by a form factor that does not expose buses and memory.
For example, there are no external DMA-capable ports, no exposed screws to open the chassis, and memory is soldered to the mainboard.
This attacker of opportunity does not use destructive methods or sophisticated forensics hardware/software.
Mitigation:
- Pre-boot authentication set to TPM only (the default)
### Attacker with skill and lengthy physical access
Targeted attack with plenty of time; this attacker will open the case, will solder, and will use sophisticated hardware or software.
Mitigation:
- Pre-boot authentication set to TPM with a PIN protector (with a sophisticated alphanumeric PIN to help the TPM anti-hammering mitigation).
-And-
- Disable Standby power management and shut down or hibernate the device before it leaves the control of an authorized user. This can be set using Group Policy:
- Computer Configuration|Policies|Administrative Templates|Windows Components|File Explorer|Show hibernate in the power options menu
- Computer Configuration|Policies|Administrative Templates|System|Power Management|Sleep Settings|Allow standby states (S1-S3) when sleeping (plugged in)
- Computer Configuration|Policies|Administrative Templates|System|Power Management|Sleep Settings|Allow standby states (S1-S3) when sleeping (on battery)
These settings are **Not configured** by default.
For some systems, bypassing TPM-only may require opening the case, and may require soldering, but could possibly be done for a reasonable cost. Bypassing a TPM with a PIN protector would cost much more, and require brute forcing the PIN. With a sophisticated enhanced PIN, it could be nearly impossible. The Group Policy setting for [enhanced PIN](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings#a-href-idbkmk-unlockpol2aallow-enhanced-pins-for-startup) is:
Computer Configuration|Administrative Templates|Windows Components|BitLocker Drive Encryption|Operating System Drives|Allow enhanced PINs for startup
This setting is **Not configured** by default.
For secure administrative workstations, Microsoft recommends TPM with PIN protector and disable Standby power management and shut down or hibernate the device.
## See also
- [Blocking the SBP-2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to BitLocker](https://support.microsoft.com/help/2516445/blocking-the-sbp-2-driver-and-thunderbolt-controllers-to-reduce-1394-d)
- [BitLocker Group Policy settings](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-group-policy-settings)
- [BitLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp)

View File

@ -8,7 +8,7 @@ ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: brianlic-msft
ms.date: 07/27/2018
ms.date: 09/17/2018
---
# BitLocker Management for Enterprises
@ -21,7 +21,7 @@ Though much Windows BitLocker [documentation](bitlocker-overview.md) has been pu
Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1 (SCCM) or later can use an existing task sequence to [pre-provision BitLocker](https://technet.microsoft.com/library/hh846237.aspx#BKMK_PreProvisionBitLocker) encryption while in Windows Preinstallation Environment (WinPE) and can then [enable protection](https://technet.microsoft.com/library/hh846237.aspx#BKMK_EnableBitLocker). This can help ensure that computers are encrypted from the start, even before users receive them. As part of the imaging process, a company could also decide to use SCCM to pre-set any desired [BitLocker Group Policy](https://technet.microsoft.com/library/ee706521(v=ws.10).aspx).
Enterprises can use [Microsoft BitLocker Administration and Management (MBAM)](https://docs.microsoft.com/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201) or they can receive extended support until July 2024. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Azure Active Directory (Azure AD).
Enterprises can use [Microsoft BitLocker Administration and Monitoring (MBAM)](https://docs.microsoft.com/microsoft-desktop-optimization-pack/mbam-v25/) to manage client computers with BitLocker that are domain-joined on-premises until [mainstream support ends in July 2019](https://support.microsoft.com/en-us/lifecycle/search?alpha=Microsoft%20BitLocker%20Administration%20and%20Monitoring%202.5%20Service%20Pack%201) or they can receive extended support until July 2024. Thus, over the next few years, a good strategy for enterprises will be to plan and move to cloud-based management for BitLocker. Refer to the [PowerShell examples](#powershell-examples) to see how to store recovery keys in Azure Active Directory (Azure AD).
## Managing devices joined to Azure Active Directory

View File

@ -1,138 +0,0 @@
---
title: Choose the right BitLocker countermeasure (Windows 10)
description: This section outlines the best countermeasures you can use to protect your organization from bootkits and rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence attacks.
ms.assetid: b0b09508-7885-4030-8c61-d91458afdb14
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 10/27/2017
---
# Choose the right BitLocker countermeasure
**Applies to**
- Windows 10
This section outlines the best countermeasures you can use to protect your organization from bootkits and rootkits, brute force sign-in, Direct Memory Access (DMA) attacks, Hyberfil.sys attacks, and memory remanence attacks.
You can use BitLocker to protect your Windows 10 PCs. Whichever operating system youre using, Microsoft and Windows-certified devices provide countermeasures to address attacks and improve your data security. In most cases, this protection can be implemented without the need for pre-boot authentication.
Tables 1 and 2 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 configuration from the default settings.
<table>
<colgroup>
<col width="20%" />
<col width="25%" />
<col width="55%" />
</colgroup>
<tr>
<td></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 8.1<br>without TPM</strong></font></p></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 8.1 Certified<br>(with TPM)</strong></font></p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Bootkits and<br>Rootkits</p></font></td>
<td BGCOLOR="#FED198"><p>Without TPM, boot integrity checking is not available</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default when UEFI-based Secure Boot is enabled and a firmware password is required to change settings</p></td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Brute Force<br>Sign-in</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout Group Policy</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout and device lockout Group Policy settings</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">DMA<br>Attacks</p></font></td>
<td BGCOLOR="#99E4FB"><p>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</p></td>
<td BGCOLOR="#99E4FB"><p>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</p></td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Hyberfil.sys<br>Attacks</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Memory<br>Remanence<br>Attacks</p></font></td>
<td BGCOLOR="#FED198"><p>Password protect the firmware and disable booting from external media. If an attack is viable, consider pre-boot authentication</p></td>
<td BGCOLOR="#99E4FB"><p>Password protect the firmware and ensure Secure Boot is enabled. If an attack is viable, consider pre-boot authentication</p></td>
</tr>
</table>
**Table 1.**&nbsp;&nbsp;How to choose the best countermeasures for Windows 8.1<br><br>
<table>
<colgroup>
<col width="20%" />
<col width="25%" />
<col width="55%" />
</colgroup>
<tr>
<td></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 10<br>without TPM</strong></font></p></td>
<td BGCOLOR="#01BCF3">
<p><font color="#FFFFFF"><strong>Windows 10 Certified<br>(with TPM)</strong></font></p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Bootkits and<br>Rootkits</p></font></td>
<td BGCOLOR="#FED198"><p>Without TPM, boot integrity checking is not available</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default when UEFI-based Secure Boot is enabled and a firmware password is required to change settings</p></td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Brute Force<br>Sign-in</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout Group Policy</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default, and can be improved with account lockout and device lockout Group Policy settings</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">DMA<br>Attacks</p></font></td>
<td BGCOLOR="#99E4FB"><p>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</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; certified devices do not expose vulnerable DMA busses.<br>Can be additionally secured by deploying policy to restrict DMA devices:</p>
<ul>
<li><p><a href="https://msdn.microsoft.com/windows/hardware/commercialize/customize/mdm/policy-configuration-service-provider#DataProtection_AllowDirectMemoryAccess">DataProtection/AllowDirectMemoryAccess</a></p></li>
<li><p><a href="https://support.microsoft.com/en-us/kb/2516445">Block 1394 and Thunderbolt</a></p></li></ul>
</td>
</tr>
<tr class="even">
<td BGCOLOR="FF8C01">
<p><font color="#FFFFFF">Hyberfil.sys<br>Attacks</font></p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
<td BGCOLOR="#99E4FB"><p>Secure by default; hyberfil.sys secured on encrypted volume</p></td>
</tr>
<tr class="odd">
<td BGCOLOR="#FF8C01">
<p><font color="#FFFFFF">Memory<br>Remanence<br>Attacks</p></font></td>
<td BGCOLOR="#FED198"><p>Password protect the firmware and disable booting from external media. If an attack is viable, consider pre-boot authentication</p></td>
<td BGCOLOR="#99E4FB"><p>Password protect the firmware and ensure Secure Boot is enabled.<br>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.</p></td>
</tr>
</table>
**Table 2.**&nbsp;&nbsp;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 portbased 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 groups 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)
 
 

Binary file not shown.

After

Width:  |  Height:  |  Size: 263 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.2 MiB

View File

@ -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 devices 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 devices 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 systems integrity, disk encryption solution (for example, encryption keys), and the PCs 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 cant access their PC without a recovery key. With a properly configured 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.
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 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.
## 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)
 
 

View File

@ -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 attacks 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 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 firmware, 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 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 PCs 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 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. 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 devices 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 systems 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 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 configured on devices that include a TPM, the TPM and its PCRs are always used to secure and confirm the integrity of the preoperating 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, its 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 users 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 devices 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 computers memory.
Unfortunately, DMA ports dont use authentication and access control to protect the contents of the computers 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 PCs 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 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).
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. Microsofts 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 phonelike 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 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 memory—including 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](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 PCs 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 drives 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 groups 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 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:
- 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 systems 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)

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

View File

@ -0,0 +1,109 @@
---
title: Kernel DMA Protection for Thunderbolt™ 3 (Windows 10)
description: Kernel DMA Protection protects PCs against drive-by Direct Memory Access (DMA) attacks using PCI hot plug devices connected to Thunderbolt™ 3 ports.
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: aadake
ms.date: 09/06/2018
---
# Kernel DMA Protection for Thunderbolt™ 3
**Applies to**
- Windows 10
In Windows 10 version 1803, Microsoft introduced a new feature called Kernel DMA Protection to protect PCs against drive-by Direct Memory Access (DMA) attacks using PCI hot plug devices connected to Thunderbolt™ 3 ports.
Drive-by DMA attacks can lead to disclosure of sensitive information residing on a PC, or even injection of malware that allows attackers to bypass the lock screen or control PCs remotely.
This feature does not protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, ExpressCard, and so on.
## Background
PCI devices are DMA-capable, which allows them to read and write to system memory at will, without having to engage the system processor in these operations.
The DMA capability is what makes PCI devices the highest performing devices available today.
These devices have historically existed only inside the PC chassis, either connected as a card or soldered on the motherboard.
Access to these devices required the user to turn off power to the system and disassemble the chassis.
Today, this is no longer the case with Thunderbolt™.
Thunderbolt™ technology has provided modern PCs with extensibility that was not available before for PCs.
It allows users to attach new classes of external peripherals, such as graphics cards or other PCI devices, to their PCs with a hot plug experience identical to USB.
Having PCI hot plug ports externally and easily accessible makes PCs susceptible to drive-by DMA attacks.
Drive-by DMA attacks are attacks that occur while the owner of the system is not present and usually take less than 10 minutes, with simple to moderate attacking tools (affordable, off-the-shelf hardware and software) that do not require the disassembly of the PC.
A simple example would be a PC owner leaves the PC for a quick coffee break, and within the break, and attacker steps in, plugs in a USB-like device and walks away with all the secrets on the machine, or injects a malware that allows them to have full control over the PC remotely.
## How Windows protects against DMA drive-by attacks
Windows leverages the system Input/Output Memory Management Unit (IOMMU) to block external devices from starting and performing DMA unless the drivers for these devices support memory isolation (such as DMA-remapping).
Devices with compatible drivers will be automatically enumerated, started and allowed to perform DMA to their assigned memory regions.
Devices with incompatible drivers will be blocked from starting and performing DMA until an authorized user signs into the system or unlocks the screen.
## User experience
![Kernel DMA protection user experience](images/kernel-dma-protection-user-experience.png)
A device that is incompatible with DMA-remapping will be blocked from starting if the device was plugged in before an authorized user logs in, or while the screen is locked.
Once the system is unlocked, the device driver will be started by the OS, and the device will continue to function normally until the system is rebooted, or the device is unplugged.
The devices will continue to function normally if the user locks the screen or logs out of the system.
## System compatibility
Kernel DMA Protection requires new UEFI firmware support.
This support is anticipated only on newly-introduced, Intel-based systems shipping with Windows 10 version 1803 (not all systems). Virtualization-based Security (VBS) is not required.
To see if a system supports Kernel DMA Protection, check the System Information desktop app (MSINFO32).
Systems released prior to Windows 10 version 1803 do not support Kernel DMA Protection, but they can leverage other DMA attack mitigations as described in [BitLocker countermeasures](bitlocker/bitlocker-countermeasures.md).
>[!NOTE]
>Kernel DMA Protection is not compatible with other BitLocker DMA attacks countermeasures. It is recommended to disable the BitLocker DMA attacks countermeasures if the system supports Kernel DMA Protection. Kernel DMA Protection provides higher security bar for the system over the BitLocker DMA attack countermeasures, while maintaining usability of external peripherals.
## Enabling Kernel DMA protection
Systems running Windows 10 version 1803 that do support Kernel DMA Protection do have this security feature enabled automatically by the OS with no user or IT admin configuration required.
**To check if a device supports kernel DMA protection**
1. Launch MSINFO32.exe in a command prompt, or in the Windows search bar.
2. Check the value of **Kernel DMA Protection**.
![Kernel DMA protection](bitlocker/images/kernel-dma-protection.png)
3. If the current state of **Kernel DMA Protection** is OFF and **Virtualization Technology in Firmware** is NO:
- Reboot into BIOS settings
- Turn on Intel Virtualization Technology.
- Turn on Intel Virtualization Technology for I/O (VT-d). In Windows 10 version 1803, only Intel VT-d is supported. Other platforms can use DMA attack mitigations described in BitLocker Countermeasures.
- Reboot system into Windows 10.
4. If the state of **Kernel DMA Protection** remains Off, then the system does not support this feature.
## Frequently asked questions
### Do in-market systems support Kernel DMA protection for Thunderbolt™ 3?
In market systems, released with Windows 10 version 1709 or earlier, will not support Kernel DMA protection for Thunderbolt™ 3 after upgrading to Windows 10 version 1803, as this feature requires the BIOS/platform firmware changes and guarantees.
### Does Kernel DMA Protection prevent drive-by DMA attacks during Boot?
No, Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It is the responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt™ 3 ports during boot.
### How can I check if a certain driver supports DMA-remapping?
DMA-remapping is supported for specific device drivers, and is not universally supported by all devices and drivers on a platform. To check if a specific driver is opted into DMA-remapping, check the values corresponding to the following Property GUID (highlighted in red in the image below) in the Details tab of a device in Device Manager. A value of 0 or 1 means that the device driver does not support DMA-remapping. A value of 2 means that the device driver supports DMA-remapping.
Please check the driver instance for the device you are testing. Some drivers may have varying values depending on the location of the device (internal vs. external).
![Kernel DMA protection user experience](images/device-details-tab.png)
### What should I do if the drivers for my Thunderbolt™ 3 peripherals do not support DMA-remapping?
If the peripherals do have class drivers provided by Windows 10, please use these drivers on your systems. If there are no class drivers provided by Windows for your peripherals, please contact your peripheral vendor/driver vendor to update the driver to support this functionality. Details for driver compatibility requirements can be found here (add link to OEM documentation).
### Do Microsoft drivers support DMA-remapping?
In Windows 10 1803 and beyond, the Microsoft inbox drivers for USB XHCI (3.x) Controllers, Storage AHCI/SATA Controllers and Storage NVMe Controllers support DMA-remapping.
### Do drivers for non-PCI devices need to be compatible with DMA-remapping?
No. Devices for non-PCI peripherals, such as USB devices, do not perform DMA, thus no need for the driver to be compatible with DMA-remapping.
### How can an enterprise enable the “External device enumeration” policy?
The “External device enumeration” policy controls whether to enumerate external devices that are not compatible with DMA-remapping. Devices that are compatible with DMA-remapping are always enumerated. The policy can be enabled via Group Policy or Mobile Device Management (MDM):
- Group Policy: Administrative Templates\System\Kernel DMA Protection\Enumeration policy for external devices incompatible with Kernel DMA Protection
- MDM: [DmaGuard policies](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-dmaguard#dmaguard-policies)
## Related topics
- [BitLocker countermeasures](bitlocker/bitlocker-countermeasures.md)
- [DmaGuard MDM policies](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-dmaguard#dmaguard-policies)

View File

@ -6,7 +6,8 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
author: andreabichsel
ms.author: v-anbic
ms.date: 04/19/2017
---

View File

@ -6,7 +6,8 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
author: andreabichsel
ms.author: v-anbic
ms.date: 04/19/2017
---

View File

@ -7,7 +7,8 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: brianlic-msft
author: andreabichsel
ms.author: v-anbic
ms.date: 10/27/2017
---

View File

@ -1,24 +1,23 @@
---
title: View status, clear, or troubleshoot the TPM (Windows 10)
title: Troubleshoot the TPM (Windows 10)
description: This topic for the IT professional describes how to view status for, clear, or troubleshoot the Trusted Platform Module (TPM).
ms.assetid: 1166efaf-7aa3-4420-9279-435d9c6ac6f8
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 04/19/2017
author: andreabichsel
ms.author: v-anbic
ms.date: 09/11/2018
---
# View status, clear, or troubleshoot the TPM
# Troubleshoot the TPM
**Applies to**
- Windows 10
- Windows Server 2016
This topic for the IT professional describes actions you can take through the Trusted Platform Module (TPM) snap-in, **TPM.msc**:
- [View the status of the TPM](#view-the-status-of-the-tpm)
This topic provides information for the IT professional to troubleshoot the Trusted Platform Module (TPM):
- [Troubleshoot TPM initialization](#troubleshoot-tpm-initialization)
@ -32,15 +31,7 @@ For information about the TPM cmdlets, see [TPM Cmdlets in Windows PowerShell](h
## About TPM initialization and ownership
Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM. This is a change from previous operating systems, where you would initialize the TPM and create an owner password. Therefore, with Windows 10, in most cases, we recommend that you avoid configuring the TPM through **TPM.msc**. The one exception is that in certain circumstances you might use **TPM.msc** to clear the TPM. For more information, see [Clear all the keys from the TPM](#clear-all-the-keys-from-the-tpm), later in this topic.
## View the status of the TPM
To view the status of the TPM, open the TPM Management console (TPM.msc). In the center pane, find the **Status** box.
In most cases, the status will be **Ready**. If the status is ready but “**with reduced functionality**,” see [Clear all the keys from the TPM](#clear-all-the-keys-from-the-tpm), later in this topic.
If the status is **Not ready**, you can try the steps in [Clear all the keys from the TPM](#clear-all-the-keys-from-the-tpm), later in this topic. If this does not bring it to a **Ready** state, contact the manufacturer, and see the troubleshooting suggestions in the next section.
Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM. This is a change from previous operating systems, where you would initialize the TPM and create an owner password.
## Troubleshoot TPM initialization
@ -72,19 +63,13 @@ For example, toggling TPMs will cause BitLocker to enter recovery mode. We stron
## Clear all the keys from the TPM
With Windows 10, in most cases, we recommend that you avoid configuring the TPM through TPM.msc. The one exception is that you can use TPM.msc to clear the TPM, for example, as a troubleshooting step, or as a final preparation before a clean installation of a new operating system. Preparing for a clean installation in this way helps ensure that the new operating system can fully deploy any TPM-based functionality that it includes, for example, attestation. However, even if the TPM is not cleared before a new operating system is installed, most TPM functionality will probably work correctly.
You can use the Windows Defender Security Center app to clear the TPM as a troubleshooting step, or as a final preparation before a clean installation of a new operating system. Preparing for a clean installation in this way helps ensure that the new operating system can fully deploy any TPM-based functionality that it includes, such as attestation. However, even if the TPM is not cleared before a new operating system is installed, most TPM functionality will probably work correctly.
Clearing the TPM resets it to an unowned state. After you clear the TPM, the Windows 10 operating system will automatically re-initialize it and take ownership again.
> [!WARNING]
> Clearing the TPM can result in data loss. For more information, see the next section, “Precautions to take before clearing the TPM.”
There are several ways to clear the TPM:
- **Clear the TPM as part of a complete reset of the computer**: You might want to remove all files from the computer and completely reset it, for example, in preparation for a clean installation. To do this, we recommend that you use the **Reset** option in **Settings**. When you perform a reset and use the **Remove everything** option, it will clear the TPM as part of the reset. You might be prompted to press a key before the TPM can be cleared. For more information, see the “Reset this PC” section in [Recovery options in Windows 10](https://support.microsoft.com/en-us/help/12415/windows-10-recovery-options).
- **Clear the TPM to fix “reduced functionality” or “Not ready” TPM status**: If you open TPM.msc and see that the TPM status is something other than **Ready**, you can try using TPM.msc to clear the TPM and fix the status. However, be sure to review the precautions in the next section.
### Precautions to take before clearing the TPM
Clearing the TPM can result in data loss. To protect against such loss, review the following precautions:
@ -103,15 +88,19 @@ Membership in the local Administrators group, or equivalent, is the minimum requ
**To clear the TPM**
1. Open the TPM MMC (tpm.msc).
1. Open the Windows Defender Security Center app.
2. If the **User Account Control** dialog box appears, confirm that the action it displays is what you want, and then click **Yes**.
2. Click **Device security**.
3. Under **Actions**, click **Clear TPM**.
3. Click **Security processor details**.
4. You will be prompted to restart the computer. During the restart, you might be prompted by the UEFI to press a button to confirm that you wish to clear the TPM.
4. Click **Security processor troubleshooting**.
5. After the PC restarts, your TPM will be automatically prepared for use by Windows 10.
5. Click **Clear TPM**.
6. You will be prompted to restart the computer. During the restart, you might be prompted by the UEFI to press a button to confirm that you wish to clear the TPM.
7. After the PC restarts, your TPM will be automatically prepared for use by Windows 10.
## <a href="" id="turn-on-or-turn-off"></a>Turn on or turn off the TPM (available only with TPM 1.2 with Windows 10, version 1507 or 1511)
@ -149,20 +138,6 @@ If you want to stop using the services that are provided by the TPM, you can use
- If you did not save your TPM owner password or no longer know it, click **I do not have the TPM owner password**, and follow the instructions that are provided in the dialog box and subsequent UEFI screens to turn off the TPM without entering the password.
### Change the TPM Owner Password (available only with Windows 10, version 1607 and earlier versions)
If you have the [owner password](https://technet.microsoft.com/itpro/windows/keep-secure/change-the-tpm-owner-password) available, you can use TPM.msc to change the TPM Owner Password.
1. Open the TPM MMC (tpm.msc).
2. In the **Action** pane, click **Change the Owner Password**
- If you saved your TPM owner password on a removable storage device, insert it, and then click **I have the owner password file**. In the **Select backup file with the TPM owner password** dialog box, click **Browse** to locate the .tpm file that is saved on your removable storage device, click **Open**, and then click **Turn TPM Off**.
- If you do not have the removable storage device with your saved TPM owner password, click **I want to enter the password**. In the **Type your TPM owner password** dialog box, type your password (including hyphens), and then click **Turn TPM Off**.
This capability was fully removed from TPM.msc in later versions of Windows.
## Use the TPM cmdlets
You can manage the TPM using Windows PowerShell. For details, see [TPM Cmdlets in Windows PowerShell](https://docs.microsoft.com/powershell/module/trustedplatformmodule/?view=win10-ps).

View File

@ -20,12 +20,6 @@ This topic for the IT professional describes how to manage which Trusted Platfor
After a computer user takes ownership of the TPM, the TPM owner can limit which TPM commands can be run by creating a list of blocked TPM commands. The list can be created and applied to all computers in a domain by using Group Policy, or a list can be created for individual computers by using the TPM MMC. Because some hardware vendors might provide additional commands or the Trusted Computing Group may decide to add commands in the future, the TPM MMC also supports the ability to block new commands.
Domain administrators can configure a list of blocked TPM commands by using Group Policy. Local administrators cannot allow TPM commands that are blocked through Group Policy. For more information about this Group Policy setting, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#configure-the-list-of-blocked-tpm-commands).
Local administrators can block commands by using the TPM MMC, and commands on the default block list are also blocked unless the Group Policy settings are changed from the default settings.
Two policy settings control the enforcement which allows TPM commands to run. For more information about these policy settings, see [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md#ignore-the-default-list-of-blocked-tpm-commands).
The following procedures describe how to manage the TPM command lists. You must be a member of the local Administrators group.
**To block TPM commands by using the Local Group Policy Editor**

View File

@ -6,7 +6,8 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
author: andreabichsel
ms.author: v-anbic
ms.date: 04/19/2017
---

View File

@ -6,7 +6,8 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
author: andreabichsel
ms.author: v-anbic
ms.date: 08/16/2017
---

View File

@ -7,7 +7,8 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: brianlic-msft
author: andreabichsel
ms.author: v-anbic
ms.date: 05/16/2018
---

View File

@ -7,7 +7,8 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: brianlic-msft
author: andreabichsel
ms-author: v-anbic
ms.date: 08/21/2018
---

View File

@ -6,8 +6,9 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
ms.date: 06/29/2018
author: andreabichsel
ms.author: v-anbic
ms.date: 09/11/2018
---
# TPM Group Policy settings
@ -24,37 +25,7 @@ The Group Policy settings for TPM services are located at:
The following Group Policy settings were introduced in Window 10.
## Configure the list of blocked TPM commands
This policy setting allows you to manage the Group Policy list of Trusted Platform Module (TPM) commands that are blocked by Windows.
If you enable this policy setting, Windows will block the specified commands from being sent to the TPM on the computer. TPM commands are referenced by a command number. For example, command number 129 is **TPM\_OwnerReadInternalPub**, and command number 170 is **TPM\_FieldUpgrade**. To find the command number that is associated with each TPM command, at the command prompt, type **tpm.msc** to open the TPM Management Console and navigate to the **Command Management** section.
If you disable or do not configure this policy setting, only those TPM commands that are specified through the default or local lists can be blocked by Windows. The default list of blocked TPM commands is preconfigured by Windows.
- You can view the default list by typing **tpm.msc** at the command prompt, navigating to the **Command Management** section, and exposing the **On Default Block List** column.
- The local list of blocked TPM commands is configured outside of Group Policy by running the TPM Management Console or scripting using the **Win32\_Tpm** interface.
## Ignore the default list of blocked TPM commands
This policy setting allows you to enforce or ignore the computer's default list of blocked Trusted Platform Module (TPM) commands.
The default list of blocked TPM commands is preconfigured by Windows. You can view the default list by typing **tpm.msc** at the command prompt to open the TPM Management Console, navigating to the **Command Management** section, and exposing the **On Default Block List** column.
If you enable this policy setting, the Windows operating system will ignore the computer's default list of blocked TPM commands, and it will block only those TPM commands that are specified by Group Policy or the local list.
If you disable or do not configure this policy setting, Windows will block the TPM commands in the default list, in addition to the commands that are specified by Group Policy and the local list of blocked TPM commands.
## Ignore the local list of blocked TPM commands
This policy setting allows you to enforce or ignore the computer's local list of blocked Trusted Platform Module (TPM) commands.
The local list of blocked TPM commands is configured outside of Group Policy by typing **tpm.msc** at the command prompt to open the TPM Management Console, or scripting using the **Win32\_Tpm** interface. (The default list of blocked TPM commands is preconfigured by Windows.)
If you enable this policy setting, the Windows operating system will ignore the computer's local list of blocked TPM commands, and it will block only those TPM commands that are specified by Group Policy or the default list.
If you disable or do not configure this policy setting, Windows will block the TPM commands in the local list, in addition to the commands that are specified in Group Policy and the default list of blocked TPM commands.
## Configure the level of TPM owner authorization information available to the operating system
@ -115,7 +86,7 @@ For each standard user, two thresholds apply. Exceeding either threshold prevent
- [Standard User Total Lockout Threshold](#standard-user-total-lockout-threshold)   This value is the maximum total number of authorization failures that all standard users can have before all standard users are not allowed to send commands that require authorization to the TPM.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the Windows Defender Security Center. Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
If you do not configure this policy setting, a default value of 480 minutes (8 hours) is used.
@ -127,7 +98,7 @@ This setting helps administrators prevent the TPM hardware from entering a locko
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the Windows Defender Security Center. Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
If you do not configure this policy setting, a default value of 4 is used. A value of zero means that the operating system will not allow standard users to send commands to the TPM, which might cause an authorization failure.
@ -139,7 +110,7 @@ This setting helps administrators prevent the TPM hardware from entering a locko
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the TPM Management Console (tpm.msc). Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the Windows Defender Security Center. Each time an administrator resets the TPM's hardware lockout logic, all prior standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM normally.
If you do not configure this policy setting, a default value of 9 is used. A value of zero means that the operating system will not allow standard users to send commands to the TPM, which might cause an authorization failure.

View File

@ -6,8 +6,9 @@ ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
author: brianlic-msft
ms.date: 07/27/2017
author: andreabichsel
ms.author: v-anbic
ms.date: 09/11/2018
---
# Trusted Platform Module
@ -26,9 +27,6 @@ Trusted Platform Module (TPM) technology is designed to provide hardware-based,
| [TPM fundamentals](tpm-fundamentals.md) | Provides background about how a TPM can work with cryptographic keys. Also describes technologies that work with the TPM, such as TPM-based virtual smart cards. |
| [TPM Group Policy settings](trusted-platform-module-services-group-policy-settings.md) | Describes TPM services that can be controlled centrally by using Group Policy settings. |
| [Back up the TPM recovery information to AD DS](backup-tpm-recovery-information-to-ad-ds.md) | For Windows 10, version 1511 and Windows 10, version 1507 only, describes how to back up a computers TPM information to Active Directory Domain Services. |
| [Manage TPM commands](manage-tpm-commands.md) | Describes methods by which a local or domain administrator can block or allow specific TPM commands. |
| [Manage TPM lockout](manage-tpm-lockout.md) | Describes how TPM lockout works (to help prevent tampering or malicious attacks), and outlines ways to work with TPM lockout settings. |
| [Change the TPM owner password](change-the-tpm-owner-password.md) | In most cases, applies to Windows 10, version 1511 and Windows 10, version 1507 only. Tells how to change the TPM owner password. |
| [View status, clear, or troubleshoot the TPM](initialize-and-configure-ownership-of-the-tpm.md) | Describes actions you can take through the TPM snap-in, TPM.msc: view TPM status, troubleshoot TPM initialization, and clear keys from the TPM. Also, for TPM 1.2 and Windows 10, version 1507 or 1511, describes how to turn the TPM on or off. |
| [Troubleshoot the TPM](initialize-and-configure-ownership-of-the-tpm.md) | Describes actions you can take through the TPM snap-in, TPM.msc: view TPM status, troubleshoot TPM initialization, and clear keys from the TPM. Also, for TPM 1.2 and Windows 10, version 1507 or 1511, describes how to turn the TPM on or off. |
| [Understanding PCR banks on TPM 2.0 devices](switch-pcr-banks-on-tpm-2-0-devices.md) | Provides background about what happens when you switch PCR banks on TPM 2.0 devices. |
| [TPM recommendations](tpm-recommendations.md) | Discusses aspects of TPMs such as the difference between TPM 1.2 and 2.0, and the Windows 10 features for which a TPM is required or recommended. |