Im about to upgrade my CPU that has TPM in it. Bitlocker is TPM+PIN+Keyfile. Now, naturally when upgrading CPU I will suspend Bitlocker, shutdown, change CPU and reboot. OK, I can understand that since plaintext key is/was stored in hdd, it can actually decrypt the secrets and boot the computer to Windows (exactly this one time). But, how the hell...?

  1. How can or can the new CPU/TPM cryptographically include the keyfile in the re-encrypting the Bitlocker secrets during this reboot? It has not seen that keyfile now, since bitlocker was suspended and no keyfile inserted.

  2. How can or can the CPU/TPM include the old PIN used to protect its secrets/Bitlocker during this reboot? It has not seen that PIN now, since bitlocker was suspended and no PIN entered + old CPU/TPM is no longer attached to computer.

I would understand if changing a component in the Bitlocker encryption would require old components to be present at the time new components are setup, so that they could be included in the new setup, for example, that you would need to boot the system once without those components ("Bitlocker suspended") but then it would ask those components to include them when re-encrypting Bitlocker secrets, or for example it would require two reboots to complete this (first without anything and second with the old keyfile etc.). But this is apparently not the case. Its one reboot and all is working again. How is this possible? When Bitlocker is suspended, only a plaintext encryption/decryption key is putted to hdd, nothing else. The secrets inside TPM nor the keyfile are putted there - and how the hell the keyfile could be, since Windows does not have access to it anymore (only Bitlocker decryption key is kept in memory after boot). But somehow Bitlocker can still include them when encrypting the Bitlocker secrets.

Please explain this to me in plain english.

  • I'm pretty sure the TMP is in a separate chip to the CPU- just like the secure enclave is different to the main processor. Commented Jul 9 at 4:24
  • No, AMD processors have buildin fTPM that Im talking about and using.
    – mmja
    Commented Jul 9 at 4:42
  • Sorry I didn’t see that you said you had a firmware CPU TMP :-) my bad. Commented Jul 9 at 5:05

1 Answer 1


The most likely state is that, in order to actually enable the new TPM, you'll need to supply the existing PIN and Keyfile. Otherwise, when you "resume protection" (erase the "key protector" that amounts to the volume master key itself in plain text), you won't actually be able to use the PIN+Keyfile to decrypt the drive again! If I were you, I'd make sure to have the recovery password handy. Hopefully, though, Windows will note that need to enter the PIN + Keyfile to re-initialize the combined key protector with the new TPM, before resuming protection (assuming it does in fact need that).

The BL metadata contains "key protectors", plain-text values that can be combined with externally-stored secrets to enable decryption of the volume master key. I don't actually know, cryptographically, exactly how the protectors work (especially for multi-secret protectors, such as TPM+PIN+Keyfile), but there's a few options. Aside from "you just can't safely resume protection without supplying the PIN+Keyfile", the following are ways that resuming protection could be safe after changing the boot process or resetting/replacing the PIN:

  • The keyfile might be an asymmetric (RSA or ECIES or similar) private key, and the PIN used to derive a symmetric key to unwrap (decrypt) another private key, such that the corresponding public keys (and the PIN's wrapped/encrypted private key) are stored in the key protector. In this way, the volume master key (or it already-partially-wrapped form) could be (further) encrypted to the public keys in a deterministic sequence, and only decryptable with the private keys, which require access to the keyfile and PIN. This would allow you to set up a new TPM without the existing keyfile and PIN. (Note that I'm not sure such "multi-layer" encryption schemes are secure; they might be doing something else such as XORing a bunch of independent values to produce the actual decryption key for the wrapped VMK).
  • The individual component secrets of the combined key protector might be stored (potentially in plain text but more likely in hashed form), either inside the metadata or in the volume itself, encrypted by the VMK. In this way, possession of the VMK through any channel would allow re-creation of the key protector even if neither of the usual user inputs nor the old TPM secret are available, but without the VMK the secrets would be safe. This could even be done only when BL is suspended to minimize the time that the secrets are stored under reversible encryption anywhere (though of course, "while BL is suspended" is the most dangerous time to do that).
  • Ofcourse, if all the secrets are stored (or backed up so to say) in the metadata and encrypted by VMK, then it could explain this. Being able to decrypt VMK by "Bitlocker suspend" would allow them to be read and used to wrap secrets again with new/cleared TPM. This would also be secure, since without VMK those secrets would remain secret and if attacker has VMK they can encrypt the drive contents anyway. HOWEVER, Microsoft does not tell us in any documentation, is this the case or what is. This is the bothering part. I dont know. There must be SOME sources for this, right?!?
    – mmja
    Commented Jul 9 at 19:36
  • Other things you sayed: I know for a fact that Bitlocker does not use public keys at all. Its just keyfile + secret in TPM (protected by PIN) + PIN itself (thats hashed to produce one more component). All these are symmetric, essentially keyfiles. I recall from somewhere that they are indeed XOR together, but cant be absolutely sure. If they are XOR and you have 2 out of 3 or 3 out of 4, you could recover the missing piece by doing a simple XOR. But not if you only have 1 out of 3 or 2 out of 4. But is this the case? Microsoft does not exactly say anywhere in documentation that I can find.
    – mmja
    Commented Jul 9 at 19:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .