[Genbox]

BitLocker does validation of the Platform Configuration Register (PCR) in the Trusted Platform Module (TPM). It does this to prevent a whole slew of exploitation techniques.

PCR banks 0 to 7 have well-defined values, so an accumulator in the TPM hashes the values and BitLocker uses the values as part of the encryption key derivation algorithm. If the PCR hash changes, the BitLocker key will become invalid.

However, BitLocker can have several "protectors" as they are called. One that is enabled by default is a "Recovery Key" protector, which is not protected by the TPM. It is a 48 digit password that must either be printed, stored on a non-encrypted medium (like an USB device) or uploaded to an Azure AD or Microsoft account.

Your colleagues must have enabled BitLocker themselves, as it is not enabled by default. They must also have been through the "backup recovery key" process, as BitLocker requires manual user interaction for this part.

It sucks when there is an update to PCR banks - and usually the update won't install if PCR7 binding is enabled - but users that enable advanced security features also have part of the responsibility to ensure they don't get locked out of their own systems.

[kmitz]

Thanks for the explanation. We bought the laptops from Dell, and after reading your message this is what I found on their website :

"All computers that Dell currently ships are Modern Standby compliant and the above applies. A registry key that Dell leaves in a neutral state controls this behavior, neither prohibiting nor enforcing encryption. Windows interprets this as approval to encrypt." https://www.dell.com/support/kbdoc/fr-fr/000124361/bitlocker...

So for the end-user bitlocker is enabled by default. It is obscure enough that our team missed that they had to backup something before using their computers.

[colejohnson66]

OP seems to imply it’s affected their entire “fleet”. Genuine question: is it possible the OEM they bought from enabled it? Cause you’re right: if you enable BL, you have a responsibility to not lose your recovery key. But if it was, say, in the box that was thrown away, is it the user’s fault?

[Nextgrid]

In general, at least one PCR will be extended with the hash of the EFI executable that's being run (with it being responsible for extending other PCRs with the hashes it executes, as to perpetuate the chain of trust). Without this, the whole system becomes pointless if you can load untrusted code (which can then set its own PCR values) without irrevocably messing up at least one PCR in the process.

If the OS updates the EFI binary or the files the bootloader will load (and thus extend PCRs based off of), the OS is responsible to "seal" the keys with the (predicted) values of the PCRs corresponding to the new files.

If the OS updates the files and fails to properly do this step, you get in this situation and your only way out is to use a backup key or somehow make the PCRs match what's actually being sealed (which is difficult, as the whole point is to prevent you from doing that - booting from a Linux USB or even merely changing BIOS settings or entering the boot menu will change PCR values) to make the TPM unseal the disk encryption key.

[kmitz]

I confirm this was enabled by default. The laptop were shipped from Dell with Pro versions of Windows. The end-users did not go through bitlocker setup process and therefore were not aware that they had to backup their security key.