2

Question 1:
Can you confirm that in a full disk encryption setup like BitLocker, when we normally boot the system, use the password, and log in, the key to decrypt the disk is loaded into RAM?
If so, this means it is stored in plaintext and is vulnerable to cold boot attacks or memory dump attacks.

I ask this because I read here that the "TPM ensures that keys never get out of the system unencrypted."
This seems contradictory, as the decryption key must be loaded into RAM at some point for the system to perform disk operations. Is this understanding correct?

Question 2:
If the above is true, and the key indeed resides in RAM, what is the practical advantage of using TPM with BitLocker for full disk encryption?

In a non-TPM system encrypted with BitLocker, the user enters the password at boot to decrypt the drive. In such a case, an attacker who doesn't know the password would need to brute force it since the key isn’t stored in plaintext.

So, what makes the with-TPM setup different?
In both cases—with or without TPM—an attacker seems to face the same challenge: brute-forcing the decryption key if they can't access it directly.

Any clarification on these points would be greatly appreciated!

Improve this question
2
  • How would not loading the decryption key into RAM work?? Commented Dec 29, 2024 at 13:30
  • 1
    @security_paranoid: If the TPM performed all cryptographic operations itself, then there would be no need to load the key into RAM. But TPMs aren't powerful enough for that, so the full disk encryption has to be done by the CPU (with the key kept in RAM). Commented Dec 29, 2024 at 13:31

3 Answers 3

Reset to default
2

As @Ja1024 mentions, the TPM is only used as a "protector" to unlock the VMK, which in turn is used to decrypt the VMEK, which lives in (kernel) memory. So regarding question 1, Yes, the key to decrypt the disk is loaded into RAM, generally speaking. (One possible exception is for drives with on-board encryption hardware; I don't know how those work exactly but plausibly the key for them is passed directly from the CPU registers to the appropriate I/O address for the drive, and never actually stored in physical RAM.)

For your second question, there are a number of practical benefits to the use of a TPM with Bitlocker:

  1. The TPM protects against modification of the pre-boot code (e.g. tampering with the bootloader, which of course lives in plain text). Even knowing what the pre-boot code should be, it would be very difficult to make the TPM cough up the Bitlocker protector key if the actual boot code is modified. This greatly raises the bar for "evil maid" attacks or similar, which could otherwise do things like install a keylogger in the bootloader. Combined with Secure Boot, this ensures the integrity of the entire boot process, before and after unlocking the encrypted volume.
  2. Unlike boot-time "PINs"[1], there is no practical way to attack the TPM protector offline. The TPM is strongly tamper-resistant and only a very sophisticated attacker would have a realistic chance of extracting the key while the device is "cold", even knowing the expected sequence of extensions into the PCRs.
  3. The TPM doesn't depend on human-memorable secrets. People are terrible at choosing passwords, much less numeric PINs, and tend to reuse them. An attacker who knows the likely PINs/passwords of their victim through some means (e.g. breached password lists, https://xkcd.com/792/, shoulder surfing, etc.) can potentially guess the Bitlocker PIN easily, even if the attacker doesn't actually know it. Obviously the TPM only helps here if either only the drive (not the whole computer) is available to the attacker, or the attacker doesn't know the OS password and can't pull off a hardware (e.g. cold boot) attack, but that does cover a number of cases (e.g. disposal of old drives, theft of backup mirrors, etc.)
  4. TPM-only mode (which is actually the default) can provide moderate protection to the machine's data without requiring a boot-time password at all. While requiring a second factor (a memorized secret "PIN" or a key stored on a removable drive) obviously increases security, Windows does its best to remain secure with TPM-only mode (e.g. restricting DMA, especially before user login), assuming that the OS user login password isn't known to the attacker (and the use of Bitlocker, even only with the TPM, prevents the kind of disk-modification attacks usually used to bypass the OS login security). This is much more convenient than requiring a boot PIN, especially if the device may be used by multiple users or may run without a keyboard connected.

[1] By default, Bitlocker only supports numeric PINs for boot-time memorized secrets. While the reasoning for this choice makes some sense - the pre-boot code doesn't know what keyboard layout the OS uses, but the digits and especially the F-keys are the same keyboard codes for all languages and layouts - it's lazy and IMO badly designed. A simple fix would be to have an option - one that doesn't require using the freaking Group Policy Editor or manually changing registry values - to say "let me use non-numeric values anyhow", with an explanation of the risks. A smarter option would be to automatically convert the keyboard input to what the bootloader keyboard driver would use when recording the Bitlocker password, with a warning to the user that if they ever connect a different keyboard they will need to hit the same keys, rather than enter the same text. Alternatively they could stuff support for different keyboard layouts into the bootloader, and let the user specify when they're using a different one.

Improve this answer
7
  • 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? Commented Dec 30, 2024 at 15:37
  • 2
    @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. Commented Dec 30, 2024 at 16:26
  • @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? Commented Dec 30, 2024 at 17:29
  • 1
    @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). Commented Dec 30, 2024 at 21:24
  • 1
    @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. Commented Nov 10, 2025 at 5:48
6

BitLocker uses multiple keys. The data on the disk is encrypted with a Full Volume Encryption Key (FVEK). Bitlocker then encrypts the FVEK with a Volume Master Key (VMK) and the VMK with a key protector – like a TPM. The VMK is only decrypted if you've passed the checks of the key protector. But after you've done that, yes, the VMK resides in RAM as plaintext and can be dumped given sufficient permissions.

So the TPM doesn't do the actual disk encryption and therefore cannot hide the VMK from the (unlocked) system. It was never designed for this purpose and is far too slow to process large amounts of data. Instead, the TPM can be used in conjunction with Secure Boot to check the integrity of the operating system and only release the VMK if this check has passed. This is exactly what BitLocker does. In other words, the point of a TPM is to protect the VMK as long as the system is locked, not afterwards.

Improve this answer
10
  • 1
    @allexj: 1) Secure Boot in the context of BitLocker prevents the key(s) from being exposed to kernel-level rootkits. If the kernel has been manipulated, the TPM can detect that its signature no longer matches the known signature from Microsoft. Userspace programs are not covered by Secure Boot, so this only protects against particular malware. 2) Brute-forcing a 256-bit key is hopeless, so if the VMK is protected with a TPM, then an attacker cannot simply remove the disk from the system. They would either have to be physically present or attack the system after it has been unlocked. Commented Dec 29, 2024 at 14:38
  • 1
    @allexj: 2.1) If the key is protected with both a TPM and a password, then, yes, an attacker with physical access only has to brute-force the password. 2.2) Correct, the VMK can only be decrypted after you’ve passed all checks of all key protectors. In your case, you have a TPM and a PIN, so the VMK isn’t available until both the Secure Boot verification was successful and you’ve entered the correct pin. Commented Dec 29, 2024 at 15:25
  • 1
    @allexj: Correct. A TPM in conjunction with Secure Boot helps against malicious bootloaders and kernel rootkits (but not other malware). In principle, TPM 2.0 supports arbitrarily complex policies, so it could do a lot more to protect the VMK, e.g., require the user to prove ownership of a separate key (ideally stored on a smartcard or some other hardware token). But I don’t believe there are any plans for implementing this in BitLocker. Commented Dec 29, 2024 at 16:49
  • 1
    @allexj: The text talks about the (private) key inside the TPM which decrypts the VMK, not the VMK itself. The VMK is eventually decrypted and provided to the OS as plaintext, but the key used by the TPM for this purpose stays within the TPM and is never exposed. Commented Dec 30, 2024 at 15:19
  • 1
    @allexj: Yes, the sensitive area of the key created with tpm2_createprimary stays within the TPM and is never exposed to the outside world. The sealed data ("testpw") does get exposed when unsealing it with tpm2_unseal. Commented Dec 30, 2024 at 16:20
1

A TPM protector enables unattended decryption/startup of the host using a single BitLocker protector. If that is what you want.

This is vulnerable to interception on the low pin count bus so it should not be used on hosts that aren't physically secure (mobile).

TPM is also used for recording and measurement of various aspects of the host during startup to ensure it hasn't changed or been compromised (attestation).

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.