This is a follow-up of the How to TPM blog post. I read a bit more about FDE on Windows. Windows differs between “device encryption” used on devices running Windows Home edition and BitLocker available only on Windows Pro/Enterprise. Both variations rely on the TPM (binding PCR 7 and 11) and are automatically enabled by default. Technically, the encryption works the same way, but BitLocker gives you more configuration options.
I did some tests. I fresh-installed Windows 11 Home and I made the same experience like this person: During the installation, I was asked to log in to my Microsoft Account. I don’t have on. I used a common trick to bypass this, ending up using a local account.
Device encryption was not enabled on my device. Windows 11 requires a TPM 2.0, a Microsoft acccount and Secure Boot enabled. Checking the FDE requirements using the “system information” tool, it said: Secure Boot disabled, can not bind PCR 7. I disabled Secure Boot to boot ventoy. After re-enabling it, Windows automatically started to encrypt the device in the background. But: When I checked the device encryption settings, I got a warning: “FDE setup not completed, please log in to your Microsoft account”.
At this point the disk is encrypted. But the FDE key is stored unprotected inside the disk metadata. I plugged the disk into a different computer (was also a Windows machine by accident) and was able to read all the data. “Device encryption” is a simplified version of BitLocker. It needs the Microsoft account to save the recovery key there. From the UI perspective, there is no other way to store the recovery key somewhere else. BitLocker allows different things at this point: Save recovery key to file, print it or save it in the Microsoft account/Active Directory. If I had used a Microsoft account during the Windows installation, encryption would just have worked (I guess).
Using the command line (still without a Microsoft account) I was able to enable “the protection” using:
manage-bde C: -protectors -add -recoverypassword
manage-bde C: -protectors -add -tpm
manage-bde -status
After rebooting into Windows, the device got decrypted without manual intervention. Then, as a test, I disabled Secure Boot in the firmware again. Booting into Windows, it asked me for the recovery key (PCR 7 mismatch, as expected):
The error message clearly says that there is a PCR 7 mismatch (sorry it’s german). It also shows the current and expected PCR 7 hash values. When booting Arch Linux from a USB drive, I was able to decrypt and mount the BitLocker partition using cryptsetup and the recovery key:
sudo cryptsetup open --type=bitlk /dev/sda3 bitlocker
After enabling Secure Boot again, Windows bootet again without any problems (so PCR 7 matched again). When using “device encryption” on Windows Home, it’s not possible to enable pre-boot authentication. It was also not possible from the command line:
manage-bde C: -protectors -add -TPMandPIN
There was an error message saying that this feature is not available on Windows Home.
To sum up
Both variations are vulnerable to cold boot attacks, TPM sniffing attacks and the still unfixed bitpixie vulnerability. Pre-boot authentication helps a lot. This mitigates two of the issues completely and in terms of cold boot attack the attacker only has one single try. Unfortunately, you can not enable pre-boot authentication on Windows Home. Also, having the recovery key stored in the Microsoft account is problematic, especially if cops are part of your threat model.