Hacker News Reader

Comment by gnabgib | Hacker News Reader

This isn't a trivial task (attaching probes to chip legs, or board connectors), and it's a good write-up, but sniffing seems like a poor word choice. This isn't picking up the data via covertly via existing attached components, or through some kind of software exploit - this is literally reading traveling messages which is nigh impossible to defend against aka "Reading data from the TPM"

Short of a physically sealed path from the chip to all components that benefit from its knowledge (impossible on a desktop?), that can only be destructively accessed (triggering an alarm; like case-open switches) - I don't see how this can be defended against.

View on HN

TPM 2.0 allows communications over the bus to be encrypted specifically to prevent this attack, though Windows apparently does not actually use this feature[0].

Newer CPUs (since about 5 years ago) have the TPM embedded in the CPU. Intel calls this PTT and AMD calls it fTPM.

[0] https://pulsesecurity.co.nz/articles/TPM-sniffing

The main problem is that you don't have a strong way of establishing that you're talking to the real TPM. It does raise the bar from passive interception to hardware MITM, but it doesn't absolutely solve the problem

It would if both the TPM and the chip talking to it use keys signed by the manufacturer. Then they could both verify the public signatures.

A public key for a fixedTPM+fixedParent primary on the TPM could be stored "securely" (i.e., read-only) on the host side, and then you can do key exchange with the TPM using RSA key transport or ECDH.

You can also use a shared secret, but storing a secret on the host side is even harder than storing a write-once (at factory), read-only PK.

Where does the key come from if the communication is encrypted?

This is complete speculation, but it could be like TLS.

That would make it much harder as you'd have to MITM the communication, not just sniff it. Maybe impossible to decrypt if both the TPM and the chip it's communicating with use keys signed by the manufacturer.

I might ask "why speculate when you can go find out?", but in this case finding out is non-trivial. See above for an explanation though.

Your comment wasn't there when I speculated.

Sounds pretty similar to TLS to me, in my non-expert opinion.

I think the difference with TLS is that, in the attacks the TPM should protect you from, the attacker controls the client and the network.

I don’t really see how it is possible to defend against that. But I don’t quite understand how the TPM checks what the CPU is doing either.

Disclaimer: I'm not an expert. At all.

I don't think it checks what the CPU is doing at all. It just makes software able to check if the platform is signed by the manufacturer.

The way I understand it is that the keys are burned into the TPM at time of manufacture, and there is no way to extract those keys, software can only ask the TPM to encrypt/decrypt/sign/verify certain data using the keys.

The TPM can then be used to verify certain operations, eg to retrieve the key for an encrypted hard drive.

But it's all a trojan horse because the manufacturer is the one who controls the keys, not the user.

It's "trusted" in the sense that the platform is "trusted" by the manufacturer, not the user.

The process for establishing an encrypted session goes like this:

0: Know the public key of a fixedTPM+fixedParent primary key (e.g., the "endorsement key") on the TPM ahead of time[0].

1: call TPM2_CreatePrimary() in the clear to "create" that key (this is deterministic given a public template and factory seed secret to the TPM) -- you need the "handle" for this key

2: call TPM2_StartAuthSession() with that handle as the bindKey, and various other parameters

3: use that session in all subsequent commands.

Note: only one parameter of every command can be encrypted: the first parameter (command or response parameter) of type TPM2B_PRIVATE. The rest can be authenticated but are otherwise exchanged in plaintext. This is mostly just fine.

[0] Well, you could validate the EK's certificate, and then you only need to know the trust anchors for the TPM's vendor. It's roughly the same thing, but with more steps, and it lets you replace the TPM w/o having to re-learn a public key for it (which might be important).

So who knows that key? The processor? Or the operating system?

What’s preventing an attacker from changing that key? Or is this just to change the attack from passive to active?

The public key has to be known by the BMC, BIOS, OS.

You can read the public key from the TPM. If you're using the endorsement key, it comes with a certificate issued by the vendor.

On intel systems at least the "firmware" tpm is really implemented in the PCH. It'd probably still be possible to sniff the i/o lines between the cpu & pch but still way more complex than between the tpm and cpu.

It's not Windows that's the problem. It's the BMCs and BIOSes. They don't use encrypted sessions. They should.

You can combine it all in a chip like the Apple T2 and then you would have to somehow probe the silicon, which is of course impossible. (Until you discover that the chip has some critical, unfixable software vulnerability like the T2)

You can also pair the chip and the CPU at the factory or on initial powerup and have them communicate encrypted from thereon. This is a bit like the iPhone 13 display having some FaceID chip on it where a replacement with a wholly new display will leave FaceID non-functioning.

probing silicon is just hard and expensive, not impossible! - though those might be similar enough for most purposes

Machines cost tens of millions or more, renting time on them at least hundreds of thousands.

I thought FIBs usually cost under $500k?

If this is what it takes to hack the TPM, the market for these machines will get bigger. That causes the price to drop.

People will find a way. In the end, if a target gets big enough, someone will do it.

> You can combine it all in a chip like the Apple T2 and then you would have to somehow probe the silicon

For the T2, at least macOS uses a key derived from useryou need both chip control _and_ user password to get in)

Windows does not, relying instead on TPM only in a default BitLocker configuration. (with a PIN option via Group Policy, not part of the regular flow)

As of why that's bad: https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

It is difficult to probe but not at all impossible. However, you can sometimes extract keys by monitoring the chip power supply current over a large number of crypto operations. Much easier than probing the chip internals.

https://scholar.google.com/scholar?as_q=%22Differential+Powe...

Reply on news.ycombinator.com