Needs SecureEnclave, Android, and browser support to be comprehensive.

TPM interdiction is readily possible.

I web searched it and found a dedicated wikipedia page https://en.wikipedia.org/wiki/Interdiction but I still can't figure out what TPM interdiction is supposed to mean

Anyway if a TPM was trivially bypassable then there would be no point to having them so I'm doubtful of whatever this off-hand comment is supposed to mean

TPMs are not 'trivially' bypassable. There's attacks on how they're used, naturally, but those wouldn't apply in this case. In this case the main issue is that once you've unlocked your storage keys you get to use them, and since storage keys need to be software keys to perform acceptably, you could even steal them. But if your device is off, a TPM would be more than adequate to protect local storage.

I think they are talking about the definition under the Espionage section, i.e. a hardware supply chain attack:

> The term interdiction is also used by the NSA when an electronics shipment is secretly intercepted by an intelligence agency (domestic or foreign) for the purpose of implanting bugs before they reach their destination.

I read the original comment instead about sniffing the data path between the TPM and the user to get the PIN.

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.

https://pulsesecurity.co.nz/articles/TPM-sniffing

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.

> You can generally sniff the LPC bus to the TPM.

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.

Which is just one way of circumventing the pin (keylogger will work on pass phrase too!). But that's not brute forcing the pin.

There was a comment on another hacker news thread the other day that a difference between secure element and TPM is that the pin code is entered on the keyboard and passes through memory while with secure enclave, at least the biometric stuff is connected directly to the secure enclave instead. Maybe that's what

Some early/naive attacks in this category would be serial bus interposition.

If you have a key object that is not extractable and can only be used and it is password protected, then you can't bypass the TPM. Once the key is unlocked (if you have access to the relevant session, which, you would) you can use it, which is bad enough if the rest of the system is compromised. There's also a concept of restricted keys that can only be used for things like quote signing (for attestation), or credential activation, which means the user doesn't get to specify exactly what to sign or decrypt.

If you couple all of that with running golden/blessed firmwares and OS, and you do secure boot, then you can be pretty certain (early in boot time anyways) that you're not running firmware/software you didn't want to assuming those are not themselves compromised.

Now, for local storage keys you really need those to be in software as a TPM can't perform well enough (not even an fTPM), and even if they did, an attacker could just decrypt local storage w/o having access to the raw keys as long as they can compromise your OS.

So, in a way you're right. But a TPM would still give you something that software-only solutions wouldn't: you get to refuse to enter the password and then the attacker has no choice but to apply rubber hose attacks or mount more expensive attacks on the TPM itself.

Require a backup password when the TPM is offline.

Chicken-little argument doesn't improve security.