Skip to content

Boot drive encryption security on Windows

Windows supports encryption of the boot drive with two separate features, BitLocker and Device Encryption.

The two features

Device Encryption

This feature is available on Windows 10 and 11 Home SKUs (or above) on supported hardware and is enabled by default. It uses the TPM as the key protector. The same underlying infrastructure as BitLocker Drive Encryption is used – but is restricted in this deployment scenario.

Device Encryption requires mandatory key escrow to a Microsoft account (personal or Azure Active Directory) to be armed.

BitLocker

This feature requires a Professional SKU (or above). It uses the TPM as a key protector by default.

This can however be changed via gpedit.msc to provide a higher security level. For example, that mechanism can be used to impose a boot-up PIN. As such a configuration is not the default, an out-of-the-box configuration only relies on measured boot.

TPM key protector?

Which PCRs are used?

For the Trusted Platform Module to provide the drive encryption key to the host, the Platform Configuration registers have to match. This is a measured boot mechanism. The TPM releases the key only if measurements match.

In the case of a system with Secure Boot, a limited set of PCRs (7, 11) is used notably to limit the risk of entering BitLocker Recovery, in which case the user would need to type the recovery key.

Wait, the TPM has the whole drive encryption key?

Yes, when the defaults are used with BitLocker (TPM key protector), the TPM has the whole drive encryption key. No user action is required on boot up to decrypt the drive’s contents.

This creates a substantial attack class not present on other drive encryption systems, which do not exclusively rely on measured boot.

This can allow to recover user data despite consumers thinking that their data is secure with another party having physical access (example: stolen device) with drive encryption.

Does that mean that a vulnerable boot chain can be used to gain access to user data?

Yes, CVE-2022-29127 is just one of those issues. A vulnerable boot loader allows to extract user data despite drive encryption/BitLocker being on, without any component of user credentials being required.

BitLocker Security Feature Bypass Vulnerability

A successful attacker could bypass the BitLocker Device Encryption feature on the system storage device. An attacker with physical access to a powered off system could exploit this vulnerability to gain access to encrypted data.

Microsoft Security Response Center

Are these the guarantees that users expect?

I don’t think that users expect drive encryption to potentially not protect them at all against a device being stolen, so no.

This is unlike other solutions in the industry, such as Apple’s FileVault, which does ask for user credentials before being able to decrypt the data volume.

edit: more info on Device Encryption.

Leave a Reply

Your email address will not be published. Required fields are marked *