Hacker News Reader

Comment by aquova | Hacker News Reader

Very interesting video. For those who can't watch, he creates a PCB with a RPi Pico and some data pins which can sniff the BitLocker key as it's sent from the TPM chip back to the CPU. I was surprised to see that this was sent in plaintext, so although his board probably will only work for that particular motherboard, the method would be sound for other computers as well.

I'll leave the comments about MS requiring TPM chips for Win11 to others.

View on HN

It's a bit of a chicken-egg problem when the TPM is the root of trust for the entire system. Sure you can encrypt the data on the bus, but where do you store that key?

You don't need to store that key anywhere, just like you don't need to store any keys to validate TLS connections.

TPM can always store the (root) private key inside the TPM, but where will the other side of the channel (CPU, HD etc.) store their private key?

It could be burned into the CPU die by blowing fuses, or stored in a tiny bit of on-die flash, or stored encrypted in SPI flash, encrypted with a factory secret key burned into the CPU at manufacture.

But more generally, you don’t need a long term key to prevent sniffing attacks like this; Diffie-Hellman is a thing. Doing an unauthenticated DH would make this attack harder and slower (active MitM probably requires removing the TPM chip from the board) but would not prevent it.

Maybe it would be more practical MITMing near the CPU. Some plastic "extender" routing the relevant pins through an external device but still allowing for cooling?

But could the communication be authenticated? Like in CPU having a public cert, self signed. TPM then can authenticate the CPU that generates the key and later sends it only over an authenticated TLS session to the same CPU.

You use a Diffie-Hellman key exchange, signed by a cert stored in the CPU on one side and verified by the TPM on the other. CPUs already have such secret certs inside of them, for example for Intels' SGX.

But as you can read in the article linked by /u/osy, the TPM ecosystem is a victim of design by committee where such things as a threat model are not a thing. They were focused on building a "generic security solution" or some other nonsense, instead of making a threat model, then a protocol, then a verification of the protocol under the threat model - like people did for example with TLS 1.3.

> instead of making a threat model

because they want the threat model to be "what any customer who is going to buy this shit might have as a threat".

Or you use fTPM, the one inside your CPU, which is how most computers that run Windows 11 (without bypassing the restrictions) do it.

Unless you happen to have an fTPM that is permanently vulnerable to such attacks: https://www.amd.com/en/resources/product-security/bulletin/a...

Exactly. An attacker that has full access to the device can get past encrypted TPM parameters, it would just slow them down. The best method is pre-boot auth where the TPM itself requires a PIN to release the keys. Windows doesn't use that by default, but it can be enabled.

TPM 2.0 provides encrypted sessions specifically to handle this problem.

Of course you need to first use them...

Reply on news.ycombinator.com