You can encrypt sessions to the TPM. To do that you need to securely know a public key for the TPM.
The protocol spoken to a TPM is like a micro-TLS. You get to encrypt, or not. You get to authenticate the TPM (like a server), or not. You get to do ephemeral-static key exchange (unlike TLS 1.3, which wants ephemeral-ephemeral key exchange). And you get to do PSK (password), and you get to do it in ways that are not subject to off-line dictionary attacks by eavesdroppers.
But you don't have to do encryption or authentication of the TPM, and the easiest thing to do is not to do either, which is what much software does. There's been this assumption that if it's on the motherboard, you can't mount active -or even just passive- attacks, but that is very much not true.
I really did not know what to read into the "TPM interdiction" comment in the context of bitwarden, but I've left comments elsewhere in this sub-thread.
You can generally sniff the LPC bus to the TPM. Even with TPM2.0+ that allows optional encryption on the transport layer, Windows dosn't bother using it.
But I was referring more to a malicious software component between the data flow between the user interface and the TPM, even before the TPM's protocol stack is in the loop.
Yes, quite, which is why it's important to use encrypted sessions to the TPM.
> Even with TPM2.0+ that allows optional encryption on the transport layer, Windows dosn't bother using it.
They really really should.
> But I was referring more to a malicious software component between the data flow between the user interface and the TPM, even before the TPM's protocol stack is in the loop.
For something like bitlocker or bitwarden you really need the unlock step to happen so early in boot (or wake) that the only vulnerabilities present are those in the blessed firmwares and kernel that you're running. Once you have the OS fully booted the possibility of executing malicious code that intercepts the UI to the TPM is just too great indeed.
