> using a fTPM would solve the problem. All TPMs support encrypted sessions to prevent these kind of MITM attacks. You use TPM2_StartAuthSession and specify encryption with each session command. But Bitlocker doesn't use one, which is epic fail. Microsoft need to fix it. Edit: For comparison, systemd uses encrypted sessions when using LUKS disk encryption with the TPM https://github.com/systemd/systemd/commit/acbb504…
This isn’t even a proper MitM attack, just passive sniffing. But, I ask as someone unfamiliar with TPM, how do authenticated sessions work? How does the OS prove its identity to the TPM in a way an attacker couldn’t spoof in a real MitM attack? Any secrets or keys stored by the OS side would have to reside unencrypted on disk, since it doesn’t have an encryption key yet. Or even if the OS verifies the TPM’s identity…
Your intuition is sound. The only way for the OS to prove it's identity is to have a secret only it knows, and prove to the TPM it knows it. TPM's do support that, but in this case the OS has nowhere that is robustly secure to store the secret.
Windows could store a obfuscate secret on disk, but it doesn't bother. To be fair, there probably isn't much point - if someone is willing to go to this much work, then it's very likely they would be willing to invest the additional effort to break the obfuscation.
This still gives you a level of protection you wouldn't have without the TPM. The disk can only be read when the TPM is present - so someone stealing disk, or walking away with a bit for bit copy of it won't get them very far. One place that's useful in cloud environments. If the cloud provided replaces a fail disk and doesn't wipe the old one - it's still useless unless someone unless they know what motherboard it was paid with.
Still, I think that's an anti-feature for a laptop. It means if the motherboard fails you've lost the data on the disk even though it's perfectly fine, and indeed that is the case with bitlocker. If you protect the disk with a password you entered on boot up it is immune to this sort of attack, and you can move it between machines. Win, win. That's what I do. But, I don't use Windows to do it.
> Or even if the OS verifies the TPM’s identity somehow
That can be solved using attestation. Attestation is just a secret TPM knows, signed by the manufacturer. Windows could choose to deal only with TPM's from manufacturers it trusts, and presumably a emulated one wouldn't be one of them. Secure boot should prevent you from modifying Windows to accept any manufacturer, so it's secure.
But I'd lay long odds Windows doesn't do this sort of verification.