Got a Warning For Enabling Firmware TPM

Solution 1:

First of all, as the quoted text mentions, note that the same system volume can have multiple decryption keys added. In addition to a TPM-protected key, the system volume will usually have a numeric recovery key.

As long as you have the recovery key written down, you can always use it to unlock the volume – even if the TPM has been changed or refuses to do the job, or even if you're accessing it through Linux, or even if the disk is moved to a different computer entirely.

(If you have Windows Pro and use the full version of BitLocker (as opposed to the reduced "Device Encryption" feature that Windows Home has), you might have seen that it also supports USB-stored key files and even ordinary passwords. Each of those "protectors" is completely independent from the rest, and only the ones which actually mention "TPM" in their name depend on a TPM – the rest will continue to work without.)

Since I never want to enable BitLocker and I only enabled TPM so I can upgrade to Windows 11 in the future, is this warning safe to ignore for my case?

Yes – if you're sure that BitLocker hasn't been automatically enabled, either.

(If you didn't have the TPM before, then most likely it hasn't, as the automatic "Device Encryption" feature requires a TPM – but it never hurts to double-check, e.g. using manage-bde -status c:.)

Note that the TPM can be used for other purposes besides BitLocker, so clearing its data might disconnect the computer from Azure AD or Windows Hello for Business, or lose license activations in some third-party apps. But if you didn't have the TPM enabled before, then you're not using any of those features anyway.

Where is this "Intel ME data region" going to be located? It doesn't sound like something that I can get to using Windows Explorer.

It's a flash memory area inside your CPU. The OS has no direct access to it at all (much like it wouldn't have direct access to a real TPM's memory, or indeed even to the NVRAM that stores your firmware settings).

Also, what is the "firmware TPM key" used for?

It's the "root" encryption key that protects all other data managed by the TPM.

Other data, such as your BitLocker keys, is not stored in the TPM itself – it has only a very small amount of secure flash memory, just enough for 3–4 cryptographic keys. Everything else is returned back to the OS, just encrypted using the "root" key, such that only the TPM itself can decrypt it. (So the BitLocker TPM protector is really stored on the disk itself.)

This gives the illusion of the TPM having practically infinite storage (by having the OS automatically swap things in and out of the TPM's RAM), while also allowing that storage to be instantly "cleared" (by destroying the root key).

Regarding "when the BIOS ROM chip is replaced," does this mean that users who turn on BitLocker should first turn it off before they replace their BIOS ROM chips?

Yes, or they should suspend BitLocker – instead of decrypting all data, this just stores the master decryption key right on the disk, without any protection. (When BitLocker is "resumed", it wipes that key.) Suspending the encryption in this way is very fast, while fully disabling BitLocker and decrypting a terabyte-sized disk can take many hours.

However, they also should have the recovery key written down. Ignore the mistaken "or" that's in your quote – knowing the recovery key makes you completely independent from the TPM or any other system hardware.

If so, what happens if they make the mistake of replacing their BIOS ROM chip before turning off BitLocker? Can they just put the old BIOS ROM chip back and turn BitLocker off, or did they just permanently encrypt their system?

Not sure, because there are really two things in play: the root encryption key that's used by fTPM, and the system state measurement that is done with all TPMs.

First, even with a discrete TPM, the "sealing" process used by Windows deliberately binds the BitLocker key to certain bits of the system state. For example, booting from a USB stick or disabling Secure Boot will make the TPM refuse to unseal the key because the system state has changed. But this doesn't destroy anything, and returning to original settings will allow the key to be unsealed again.

However, with an fTPM, it's the firmware that actually holds the actual root encryption key that's used for sealing. It's most likely to be in the CPU, not in the "BIOS ROM", but it is possible that changing things around may cause the firmware to completely reset the fTPM, making all previously sealed data irrecoverable.