Why does Windows not enable TPM 2.0 parameter encryption to protect against bus sniffing of Bitlocker key?

Question

Comes from Bitlocker, does additional authentication at startup with TPM device provide any extra security?

You can sniff the key right from the bus currently:

As the decryption happens automatically, if we can sniff the VMK as its being returned by the TPM then we can enter that information into any number of BitLocker libraries and decrypt the drive. - -

TPM2.0 devices support command and response parameter encryption, which would prevent the sniffing attacks. Windows doesn’t configure this though, so the same attack a TPM1.2 device works against TPM2.0 devices.

Maybe Windows 11 will close this door?

Answer 1

To be clear, I don't work for Microsoft and I think they should use parameter encryption.

But I can offer a plausible explanation - one being of complexity. The component that takes in the user password or PIN is a bootloader component. To use encryption, the bootloader component would first need to verify whether the TPM is genuine or not, it needs to keep a secure copy of the Certificate Authorities (CAs) of all TPM manufacturers - it is straightforward to bundle these into the bootloader, but updating the bootloader later on to add new CAs is awkward to maintain. With the CAs in place, it then needs to validate the X.509 certificate chains of the TPM EK chain to see if it matches a trust anchor. Then, the bootloader needs to include expanded cryptographic capabilities because encrypted sessions require a lot of extra steps. Expanded cryptographic capabilities obviously increase the attack surface of the bootloader. They would likely also have to support both 1.2 and 2.0 methods, which is also extra complexity.

This is the only reason I can think of that explains why it's not done - but it does not excuse the threat we live with today.