Timeline for answer to Clarifying BitLocker Full Disk Encryption and the role of TPM by CBHacking
Current License: CC BY-SA 4.0
Post Revisions
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 10, 2025 at 11:56 | comment | added | allexj | @CBHacking thanks so much. | |
| Nov 10, 2025 at 10:19 | vote | accept | allexj | ||
| Nov 10, 2025 at 5:48 | comment | added | CBHacking | @allexj Because the operating system can't boot without being decrypted first? Only the bootloader and recovery tools live on the (decrypted) boot partition (EFI system partition) The bootloader has BitLocker code to get the key (querying TPM and/or user as needed) and decrypt files from the encrypted OS volume (this of course requires the key to be in memory!), which it uses to bootstrap the kernel. The kernel has its own BitLocker filter driver, which also requires the key in memory, which it uses to load wininit, drivers, winlogon, and boot-time services, etc., all before user login. | |
| Nov 8, 2025 at 15:40 | comment | added | allexj | @CBHacking sorry for late response, but are you sure that VMK is unsealed/put in RAM even if user has not yet performed login? why would it? | |
| Dec 30, 2024 at 21:24 | comment | added | CBHacking |
@allexj Yes, if you simply turn on Bitlocker and accept all default options (or use Bitlocker as "device encryption" on lower-tier Windows editions that don't support the options), it will run in TPM-only mode. You can manually change this after the fact using the manage-bde tool, which - because it's only changing the key protectors - can be done without decrypting and re-encrypting. You can also change the default through Group Policy (including on non-domain-joined machines using gpedit.msc).
|
|
| Dec 30, 2024 at 17:29 | comment | added | allexj | @CBHacking Regarding point 4, are you saying that by default, BitLocker operates in TPM-only mode? In this configuration, the TPM unseals and releases the VMK during the boot process as long as the PCR values are intact, even before the user enters their login PIN or password. Windows just relies on restricting DMA to protect the VMK. If that’s correct, does this mean that an attacker who has stolen the computer could simply power it on and, without knowing the user’s login credentials, perform a cold boot attack to retrieve the VMK and subsequently decrypt the disk offline? | |
| Dec 30, 2024 at 16:26 | comment | added | Ja1024 |
@allexj: "Sensitive portion" refers to the key created with tpm2_createprimary (and referenced with the prim.ctx file) . The sensitive area of this key only exists within the TPM and never leaves it. When you seal data with this key and later unseal it, the data does get exposed as plaintext to the OS.
|
|
| Dec 30, 2024 at 15:37 | comment | added | allexj |
Thanks for clarifying! I’m still unsure about the statement "The sensitive portion of a key is never released outside of the TPM2 device"... If the TPM releases the VMK to the OS to decrypt the FVEK, doesn’t that expose it? For example, in echo "testpw" | tpm2_create -g sha256 -u seal.pub -r seal.priv -i- -C prim.ctx, is prim.ctx the part that’s never exposed? I assume seal.priv contains the encrypted 'testpw', which is revealed in plaintext when unsealed. Does 'sensitive portion' refer to the prim.ctx used to encrypt the sealed object?
|
|
| Dec 30, 2024 at 10:33 | history | answered | CBHacking | CC BY-SA 4.0 |