[whiatp]

Something worth calling out is that, as far as I've seen, most server TPM implementations are not great against physical access attacks. If servers might be physically compromised (eg. you are leaving a server unsupervised in a colo) shenanigans are still possible.

The TPMs are on separate chips from the main processor. If something were to man-in-the-middle the communications with the TPM, the hash digests can be "corrected" so the TPM thinks the boot artifacts were in the intended state. At least the ones I've worked with were SPI, but I've seen I2C ones as well. Either way, these are low speed, easy to mess with buses.

Also you want to pay real close attention to how you onboard new devices. The article states

> The EK comes with a x509 cert signed by the manufacture’s PKI. So the EK proves the TPM is legit.

This lets you know the TPM you are performing remote attestation of is made by a particular manufacturer, but an attacker can go buy a TPM chip from the right manufacturer off digikey, and feed it the intended hashes in pcr extend commands. For the attacks the TPM is supposed to prevent, you have to assume they could re-direct the tpm requests your remote validation service is trying to run to their own device by compromising the boot artifacts. You still have to figure out how to make sure your workflows are onboarding the TPM from _your_ hardware, not just a TPM from the same manufacturer.

[crote]

Don't most (all?) modern CPUs have an embedded TPM? Plug-in TPMs were indeed a thing early on, but I thought that was a thing of the past by now. You can't exactly get in between the CPU and another part of the same CPU.

Also, isn't the EK (and therefore its cert) unique per-device, allowing you to tell it apart? The fact that the manufacturer used the same upstream key to sign both certs doesn't matter, just like a CA can sign multiple TLS certs with one root key.

[whiatp]

Yeah, if the CPU has a an embedded TPM that would be way better than the external ones. I'll admit that my experience comes from somewhat dated hardware.

The point I was making was about registering new EKs/certs into your set of trusted servers. While you can tell the TPMs apart from each other, knowing the EK/cert belongs to your hardware's TPM vs someone else's is the tricky part.

[mike_hearn]

TPMs were moved into the Northbridge (I think) many years ago, at least on Intel systems.

PC hardware still isn't tamper resistant though. Memory may be encrypted but its contents can be tampered with in other ways. Only SGX made a serious attempt to be tamper resistant, although Intel eventually sacrificed that to boost performance.

[UltraSane]

Newer AMD CPUs have TPMs in them.

[simonjgreen]

I recall an event some years ago around Supermicro that was along these lines. Chips added during manufacturing by nation state that interfered with the operation of the BMC and TPM. Wasn't it the catalyst that pushed hardware supply chain concerns in to mainstream media?

[Dibby053]

Have the CPU and the security chip derive their private keys from physical unclonable functions (to prevent extraction), let them exchange public keys once during manufacture, and from that point onward encrypt the SPI bus.

This is what some smartphones seem to do. I don't know if server motherboards do it but it would help a lot against this kind of attack.

[mapkkk]

There's support for encrypted communication with TPMs, but if I remember correctly this is almost never enabled by default.