Avoid BitLocker recovery mode by customizing the TPM validation profile

• Author
• Recent Posts

Wolfgang Sommergut

Wolfgang Sommergut has over 20 years of experience in IT journalism. He has also worked as a system administrator and as a tech consultant. Today he runs the German publication WindowsPro.de.

Latest posts by Wolfgang Sommergut (see all)

• New Group Policy settings in Windows 11 23H2 - Mon, Nov 20 2023
• Windows Server 2025 will support SMB over QUIC in all editions - Fri, Nov 17 2023
• Switch between Windows Terminal and the legacy console - Thu, Nov 16 2023

A trusted PC that has not been tampered with is a vital requirement for strong BitLocker protection. For instance, if an attacker can replace the bootloader, they can intercept the encryption key from the TPM.

Ideally, BitLocker secures the entire boot process, from the firmware to the operating system, by utilizing the data stored in the Platform Configuration Register (PCR) of the TPM.

Here are descriptions of the individual registers:

• PCR 0: Core root-of-trust for measurement, EFI boot and run-time services, EFI drivers embedded in system ROM, ACPI static tables, embedded SMM code, and BIOS code.
• PCR 1: Platform and motherboard configuration and data. Handoff tables and EFI variables that affect system configuration.
• PCR 2: Option ROM code.
• PCR 3: Option ROM data and configuration.
• PCR 4: Master boot record (MBR) code or code from other boot devices.
• PCR 5: Master boot record (MBR) partition table. Various EFI variables and the GPT table.
• PCR 6: State transition and wake events.
• PCR 7: Computer manufacturer-specific.
• PCR 8: NTFS boot sector.
• PCR 9: NTFS boot block.
• PCR 10: Boot manager.
• PCR 11: BitLocker access control.

It is evident that the verification process becomes more likely to fail as more criteria need to be met for a PC to be considered trustworthy.

PCR for securing system startup

If BitLocker detects any deviations in the system compared to its original state, it will display the recovery console and prompt the user to enter the recovery key.

After entering the key, BitLocker unlocks the corresponding drive and resets the validation profile so that the recovery console does not appear again on the next startup. To prevent a validation profile update, you can disable the Reset Platform Validation Data on BitLocker Recovery Group Policy.

Unlocking the PC using the recovery key typically results in a helpdesk request. If many employees of a company work remotely with their laptops, it can be cumbersome to reliably identify users and securely transmit the key.

For this reason, it may be useful to customize the PCRs used by BitLocker. The Group Policies provide a setting for this purpose.

Adjusting the validation profile

You can find it under Computer Configuration > Policies > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives, and it exists in three variations:

• Configure TPM platform validation profile for native UEFI firmware configurations
• Configure TPM platform validation profile for BIOS-based firmware configurations
• Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2)

The last two are unlikely to be relevant in most environments when using modern hardware with a current version of Windows.

Group Policy for configuring the TPM platform validation profile

On BIOS-based computers, PCR 0, 2, 4, 8, 9, 10, and 11 are enabled by default. On UEFI-based PCs with Secure Boot enabled, only PCR 7 and 11 are active. Secure boot takes on a significant portion of the PC validation through PCR 7, replacing PCR 0, 2, and 4.

Adjusting the validation profile is most needed on older BIOS-based PCs and on UEFI systems when Secure Boot is not desired or not possible, such as when the UEFI compatibility support module is enabled because of specific hardware components.

In such cases, PCR 2 and 4 become potential candidates that can quickly trigger recovery mode. Simply changing the boot order of drives can be sufficient to cause this behavior.

If the Windows partition was encrypted after the computer was booted from a PXE server, the PXE server must always be available to avoid entering the recovery password in the future. In these cases, it can be helpful to configure BitLocker to ignore specific BCD entries. The setting responsible for this is Use enhanced Boot Configuration Data validation profile.

The syntax for BCD settings that need additional verification or exclusion is described on this page of Microsoft's documentation.

Conflicting settings

If you have enabled the Allow Secure Boot for integrity validation setting and, at the same time, you want to customize the TPM platform validation profile using one of the Group Policies mentioned above, it is important to ensure that PCR 7 is selected. Otherwise, you will overwrite the Secure Boot setting.

Group Policies that can be overridden by conflicting settings

If you are using Secure Boot for system integrity verification, the mentioned setting for checking BCD entries will be ignored. The validation by Secure Boot is flexible enough to cope with changes in the boot order.

Query the current validation profile

To determine which PCRs BitLocker currently uses for system integrity validation, you can use the manage-bde.exe utility:

manage-bde -protectors -get %systemdrive%

Use manage bde to display which PCRs are used for system validation

The PowerShell cmdlets from the BitLocker module are not helpful in this case. Instead, you would need to retrieve the relevant information through WMI, which is what Get-BitLockerVolume does with the help of Invoke-CimMethod. However, this method does not provide information about the PCRs.

The system information (msinfo32.exe) contains the PCR7 status but only tells you whether BitLocker is bound to Secure Boot or not.

Output the status of the PCR7 configuration using msinfo32

Summary

BitLocker utilizes a relatively complex combination of criteria to assess the trustworthiness of a system before releasing the encryption key from the TPM. The most user-friendly configuration on modern hardware involves using PCR 7 and 11.

Secure Boot ensures the integrity of most components and adapts flexibly to certain system changes, such as updates in the BCD store, reducing the need for users to enter the recovery key.

If the hardware does not support Secure Boot or if it is not desired due to potential complications, then optimizing the validation profile becomes important. This can help reduce the frequency of recovery mode.

It's important to consider that BitLocker records the system state during the initial encryption process and measures any deviations from it. Therefore, the PC should be in an appropriate state during that time.

The settings described here are specific to systems with TPM. If TPM is not available, the trustworthiness of the system cannot be validated. In such cases, it is mandatory to use an additional protector anyway.