This commit is contained in:
Paolo Matarazzo 2023-09-25 13:08:30 -04:00
parent e7b1512e60
commit 5ee4f6b5ec
5 changed files with 30 additions and 56 deletions

View File

@ -711,43 +711,6 @@ The following list identifies all of the available PCRs:
> [!WARNING] > [!WARNING]
> Changing from the default platform validation profile affects the security and manageability of a computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs. > Changing from the default platform validation profile affects the security and manageability of a computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
### Reset platform validation data after BitLocker recovery
This policy setting determines if platform validation data should refresh when Windows is started following a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
| Item | Info |
|:---|:---|
|**Policy description**|With this policy setting, it can be controlled whether platform validation data is refreshed when Windows is started following a BitLocker recovery.|
|**Drive type**|Operating system drives|
|**Policy path**|*Computer Configuration* > *Administrative Templates* > *Windows Components* > *BitLocker Drive Encryption* > *Operating System Drives*|
|**Conflicts**|None|
|**When enabled**|Platform validation data is refreshed when Windows is started following a BitLocker recovery.|
|**When disabled**|Platform validation data isn't refreshed when Windows is started following a BitLocker recovery.|
|**When not configured**|Platform validation data is refreshed when Windows is started following a BitLocker recovery.|
#### Reference: Reset platform validation data after BitLocker recovery
For more information about the recovery process, see the [BitLocker recovery guide](bitlocker-recovery-guide-plan.md).
### Use enhanced Boot Configuration Data validation profile
This policy setting determines specific Boot Configuration Data (BCD) settings to verify during platform validation. A platform validation uses the data in the platform validation profile, which consists of a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
| Item | Info |
|:---|:---|
|**Policy description**|With this policy setting, Boot Configuration Data (BCD) settings to verify during platform validation can be specified.|
|**Drive type**|Operating system drives|
|**Policy path**|*Computer Configuration* > *Administrative Templates* > *Windows Components* > *BitLocker Drive Encryption* > *Operating System Drives*|
|**Conflicts**|When BitLocker is using Secure Boot for platform and Boot Configuration Data integrity validation, the **Use enhanced Boot Configuration Data validation profile** Group Policy setting is ignored (as defined by the **Allow Secure Boot for integrity validation** Group Policy setting).|
|**When enabled**|Additional BCD settings can be added and specified BCD settings can be excluded. Also a customized BCD validation profile can be created by combining inclusion and exclusion lists. The customized BCD validation profile gives the ability to verify BCD settings.|
|**When disabled**|The computer reverts to a BCD profile validation.|
|**When not configured**|The computer verifies the default BCD settings in Windows.|
#### Reference: Use enhanced Boot Configuration Data validation profile
> [!NOTE]
> The setting that controls boot debugging (0x16000010) is always validated, and it has no effect if it's included in the inclusion or the exclusion list.
## FIPS setting ## FIPS setting
The Federal Information Processing Standard (FIPS) setting for FIPS compliance can be configured. As an effect of FIPS compliance, users can't create or save a BitLocker password for recovery or as a key protector. The use of a recovery key is permitted. The Federal Information Processing Standard (FIPS) setting for FIPS compliance can be configured. As an effect of FIPS compliance, users can't create or save a BitLocker password for recovery or as a key protector. The use of a recovery key is permitted.
@ -782,16 +745,3 @@ To disable all available sleep states, disable the Group Policy settings located
- **Allow Standby States (S1-S3) When Sleeping (Plugged In)** - **Allow Standby States (S1-S3) When Sleeping (Plugged In)**
- **Allow Standby States (S1-S3) When Sleeping (Battery)** - **Allow Standby States (S1-S3) When Sleeping (Battery)**
## About the Platform Configuration Register (PCR)
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The scope of the values can be specific to the version of the operating system.
Changing from the default platform validation profile affects the security and manageability of a computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
### About PCR 7
PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can use Secure Boot for integrity validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on and which keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4, which have the measurements of the exact firmware and Bootmgr images loaded. This process reduces the likelihood of BitLocker starting in recovery mode as a result of firmware and image updates, and it provides with greater flexibility to manage the preboot configuration.
PCR 7 measurements must follow the guidance that is described in [Appendix A Trusted Execution Environment EFI Protocol](/windows-hardware/test/hlk/testref/trusted-execution-environment-efi-protocol).
PCR 7 measurements are a mandatory logo requirement for systems that support Modern Standby (also known as Always On, Always Connected PCs), such as the Microsoft Surface RT. On such systems, if the TPM with PCR 7 measurement and secure boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.

View File

@ -11,5 +11,5 @@ This policy setting allows you to configure the encryption type used by BitLocke
| | Path | | | Path |
|--|--| |--|--|
| **CSP** | ``./Device/Vendor/MSFT/BitLocker/`[FixedDrivesEncryptionType](/windows/client-management/mdm/bitlocker-csp#fixeddrivesencryptiontype) | | **CSP** | `./Device/Vendor/MSFT/BitLocker/`[FixedDrivesEncryptionType](/windows/client-management/mdm/bitlocker-csp#fixeddrivesencryptiontype) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **BitLocker Drive Encryption** > **Fixed Data Drives** | | **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **BitLocker Drive Encryption** > **Fixed Data Drives** |

View File

@ -7,7 +7,12 @@ ms.topic: include
### Reset platform validation data after BitLocker recovery ### Reset platform validation data after BitLocker recovery
This policy setting allows you to control whether or not platform validation data is refreshed when Windows is started following BitLocker recovery. If you enable this policy setting, platform validation data will be refreshed when Windows is started following BitLocker recovery. If you disable this policy setting, platform validation data will not be refreshed when Windows is started following BitLocker recovery. If you do not configure this policy setting, platform validation data will be refreshed when Windows is started following BitLocker recovery. This policy setting determines if platform validation data should refresh when Windows is started following a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
If you enable this policy setting, platform validation data will be refreshed when Windows is started following BitLocker recovery. This is the default behavior.\
If you disable this policy setting, platform validation data will not be refreshed when Windows is started following BitLocker recovery.
For more information about the recovery process, see the [BitLocker recovery guide](bitlocker-recovery-guide-plan.md).
| | Path | | | Path |
|--|--| |--|--|

View File

@ -7,7 +7,12 @@ ms.topic: include
### Use enhanced Boot Configuration Data validation profile ### Use enhanced Boot Configuration Data validation profile
This policy setting allows you to choose specific Boot Configuration Data (BCD) settings to verify during platform validation. If you enable this policy setting, you will be able to add additional settings, remove the default settings, or both. If you disable this policy setting, the computer will revert to a BCD profile similar to the default BCD profile used by Windows 7. If you do not configure this policy setting, the computer will verify the default Windows BCD settings. Note: When BitLocker is using Secure Boot for platform and Boot Configuration Data (BCD) integrity validation, as defined by the "Allow Secure Boot for integrity validation" group policy, the "Use enhanced Boot Configuration Data validation profile" group policy is ignored. The setting that controls boot debugging (0x16000010) will always be validated and will have no effect if it is included in the provided fields. This policy setting determines specific Boot Configuration Data (BCD) settings to verify during platform validation. A platform validation uses the data in the platform validation profile, which consists of a set of Platform Configuration Register (PCR) indices that range from 0 to 23.
If you don't configure this policy setting, the device will verify the default Windows BCD settings.
> [!NOTE]
> When BitLocker is using Secure Boot for platform and BCD integrity validation, as defined by the *Allow Secure Boot for integrity validation* GPO, this policy setting is ignored. The setting that controls boot debugging `0x16000010` is always validated, and it has no effect if it's included in the inclusion or exclusion list.
| | Path | | | Path |
|--|--| |--|--|

View File

@ -19,6 +19,9 @@ If multiple changes are necessary to bring the drive into compliance, BitLocker
In other scenarios, to bring the drive into compliance with a change in policy settings, BitLocker may need to be disabled and the drive decrypted followed by re-enabling BitLocker and then re-encrypting the drive. An example of this scenario is when the BitLocker encryption method or cipher strength is changed. The [`manage-bde`](/windows-server/administration/windows-commands/manage-bde) command-line can also be used in this scenario to help bring the device into compliance. In other scenarios, to bring the drive into compliance with a change in policy settings, BitLocker may need to be disabled and the drive decrypted followed by re-enabling BitLocker and then re-encrypting the drive. An example of this scenario is when the BitLocker encryption method or cipher strength is changed. The [`manage-bde`](/windows-server/administration/windows-commands/manage-bde) command-line can also be used in this scenario to help bring the device into compliance.
> [!IMPORTANT]
> Most of the BitLocker settings are applied when BitLocker is initially turned on for a drive. Encryption isn't restarted if settings change.
## Settings list ## Settings list
The list of settings is sorted alphabetically and organized in four tabs: The list of settings is sorted alphabetically and organized in four tabs:
@ -28,9 +31,6 @@ The list of settings is sorted alphabetically and organized in four tabs:
- **Fixed data drives**: settings applicable to any local drives, except the operating system drive - **Fixed data drives**: settings applicable to any local drives, except the operating system drive
- **Removable data drives**: settings applicable to any removable drives - **Removable data drives**: settings applicable to any removable drives
> [!IMPORTANT]
> Most of the BitLocker settings are applied when BitLocker is initially turned on for a drive. Encryption isn't restarted if settings change.
#### [:::image type="icon" source="images/locked-drive.svg"::: **Common settings**](#tab/common) #### [:::image type="icon" source="images/locked-drive.svg"::: **Common settings**](#tab/common)
The following table lists the BitLocker policies applicable to all drive types, indicating if they're applicable via configuration service provider (CSP) and/or group policy (GPO). Select the policy name for more details. The following table lists the BitLocker policies applicable to all drive types, indicating if they're applicable via configuration service provider (CSP) and/or group policy (GPO). Select the policy name for more details.
@ -142,3 +142,17 @@ The following table lists the BitLocker policies applicable to all drive types,
[!INCLUDE [removable-drives-excluded-from-encryption](includes/removable-drives-excluded-from-encryption.md)] [!INCLUDE [removable-drives-excluded-from-encryption](includes/removable-drives-excluded-from-encryption.md)]
--- ---
## Platform Configuration Register (PCR)
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The scope of the values can be specific to the version of the operating system.
Changing from the default platform validation profile affects the security and manageability of a computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or decreased depending on inclusion or exclusion (respectively) of the PCRs.
### About PCR 7
PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can use Secure Boot for integrity validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on and which keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4, which have the measurements of the exact firmware and Bootmgr images loaded. This process reduces the likelihood of BitLocker starting in recovery mode as a result of firmware and image updates, and it provides with greater flexibility to manage the preboot configuration.
PCR 7 measurements must follow the guidance that is described in [Appendix A Trusted Execution Environment EFI Protocol](/windows-hardware/test/hlk/testref/trusted-execution-environment-efi-protocol).
PCR 7 measurements are a mandatory logo requirement for systems that support Modern Standby (also known as Always On, Always Connected PCs), such as the Microsoft Surface RT. On such systems, if the TPM with PCR 7 measurement and secure boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.