Home / server / Questions / 909640
In Process
Residualfail
Asked: 2018-04-27 13:48:11 +0800 CST

Checking which PCR triggered for BitLocker recovery

  • 772

We have an MBAM server and tested policies which work normally for nearly every machine we've migrated. Though, I have seen 3 systems now that prompt for a recovery key instead of the users PIN. After recovering, each subsequent reboot asks for recovery keys again, requiring end users to contact support after each reboot. The recovery keys are being escrowed into AD\MBAM just fine.

Seeing as the process has worked on roughly 99% of systems so far, I'm assuming we're dealing with hardware or software level issues. In one case, I have reloaded the system and had BitLocker begin working normally indicating it was some machine state issue.

I've been through the gambit in terms of troubleshooting the TPM state, firmware upgrades, reviewing BitLocker logs, fully decrypting\re-encrypting devices but once the laptop is in this state, it always prompts for recovery.

Is there a way to discover which PCR exactly is triggering the recovery state so I can focus on a single PCR? We're about to go company wide with this process and I'm concerned that we might disrupt more users during migration. I'd at least like to have a plan to troubleshoot.

windows-10

1 Answers

  1. First, the reason why the systems keep prompting for the recovery key is because you did not reinitialize BitLocker to use the new PCR values. To do so, simply suspend BitLocker, reboot, and enable BitLocker again. However I would advice against this until you find out exactly what is causing the change in PCR values. In the worst case, it can be caused by a bootkit.

    The TCG event logs record the full sequence of TPM measurement operations and how they change the PCRs. Windows keep a copy of the logs in encoded form in C:\Windows\Logs\MeasuredBoot\. As described in Decode Measured Boot logs to track PCR changes, you can use either TBSLogGenerator (requires installing the Windows Hardware Lab Kit) or PCPTool (requires building it yourself from source) to decode them. Note that the PCPTool linked in the article only works for TPM 1.2. For TPM 2.0, use the new version at https://github.com/microsoft/TSS.MSR/tree/master/PCPTool.v11

    Assuming that your systems are on UEFI firmware, then as per BitLocker Group Policy settings, if the following GPO are not configured:

    • Allow Secure Boot for integrity validation
    • Configure TPM platform validation profile for native UEFI firmware configurations

    Then BitLocker is using either PCRs

    • 0, 2, 4 and 11, or
    • 7 and 11

    As far as I know, Windows does not record the expected value of each PCR used for unlocking BitLocker, so the only way to find out the offending PCR would be to compare the decoded log after hitting the recovery key prompt with one before when the system booted fine. Just narrow your search down to the aforementioned PCRs and you should be able to quickly find the culprit.

    • 1