Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

mkukri.xyz

Post reply on HN
Print view View original

91–100 of 136 posts

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#91

Post by cryptonector »

jprete wrote: post #69
RedShift1 wrote: post #26

TPM seems beyond useless to me. I wanted to protect a certificate and private key for a Java application, so that you can't just copy the pkcs12 file and use it elsewhere, but there is no decent API in Java to use a TPM 2 chip. So the road ends there... The only protection now is a hardcoded passphrase in the application but you don't have to be a genius to figure that out...

Totally off-topic: You could always write a JNI shim to a C/C++-compatible API, if you know what OS it's running on. I know it's awful, but probably not as awful as a hardcoded passphrase.

There are TPM 2.0 APIs for Java.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#92

Post by cryptonector »

patmorgan23 wrote: post #48
sim7c00 wrote: post #28

Earlier quoted context omitted.

its meant for secureboot, but i suppose the rest of the platform, built usually by other ppl than ones who designed the TPM, needs to also implement it correctly. an d as this article shows, this is not an easy feat. (this attack seems silly but it's really clever tbh. good inspired idea likely based in lots of domain expertise). - if you can protect the boot-chain with secureboot, what you can do for your private ke…

TPM isn't just for secure boot. Windows utilizes it for Bitlocker full disk encryption. It's just not widely used for other applications.

That's still essentially part of the boot process. You can't use dTPMs as HSMs for TLS or whatever because dTPMs are way too slow.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#93

Post by RedShift1 »

cryptonector wrote: post #91
jprete wrote: post #69

Earlier quoted context omitted.

Totally off-topic: You could always write a JNI shim to a C/C++-compatible API, if you know what OS it's running on. I know it's awful, but probably not as awful as a hardcoded passphrase.

There are TPM 2.0 APIs for Java.

No, they are all for TPM 1.2

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#94

Post by jwells89 »

A bit tangential, but it’s a bit shocking how consistently bad firmware for x86 motherboards and laptops is, as is most visible in the UEFI configuration screen. It makes me wonder if a new entrant in the motherboard/laptop space couldn’t make a name for themselves by simply caring about the quality of their firmware and trying to make it good.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#95

Post by wtallis »

kukrimate wrote: post #81
p_l wrote: post #3

Earlier quoted context omitted.

Funnily enough, in TPM 2.0 there's way around MITM attacks like that - you can establish encrypted connection between TPM and CPU, which outside first-time configuration (which should happen in controlled environment anyway) should provide reasonable roadblock to successful MITM attack. But CPU-side software needs to use it, and without default well-known keys...

Unfortunately encrypted sessions without an interactively provided secret like a PIN are no defence against attacker with physical access. You either need an interactively provided PIN, or a TPM integrated into the CPU/SoC to be secure in such a scenario.

Why doesn't a key exchange in a secure environment before any attacker has physical access give the same security benefits of "an interactively provided secret like a PIN"?

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#96

Post by justaj »

jwells89 wrote: post #94

A bit tangential, but it’s a bit shocking how consistently bad firmware for x86 motherboards and laptops is, as is most visible in the UEFI configuration screen. It makes me wonder if a new entrant in the motherboard/laptop space couldn’t make a name for themselves by simply caring about the quality of their firmware and trying to make it good.

Such an entrant exists. It's called Libreboot.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#97

Post by marshray »

voxic11 wrote: post #72
CivBase wrote: post #67

Earlier quoted context omitted.

Couldn't they just reset their TPM to change their "identity"? Or use a different computer or VM? Also, I'd be pretty frustrated if I was sharing a PC with someone and they got me banned from a game.

If you are sharing a computer with a hacker then your account would be banned anyways. All the tpm does is ensure you can't just make another account and use it from that computer.

Apparently on some motherboards the TPM is on a pluggable module available for ~$15 on Amazon.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#98

Post by Vogtinator »

p_l wrote: post #3
michaelt wrote: post #2

> If attacker have physical access, the discrete TPM is an attack surface anyway and even a known attack already. If you're wondering what they mean by this, [1] has been around since 2018. It's not unusual for a motherboard to put the TPM on a removable module, so you don't even have to desolder the chip to MITM the communications. The most recent Intel and AMD CPUs have "firmware TPMs" that run in the CPU's so-call…

Funnily enough, in TPM 2.0 there's way around MITM attacks like that - you can establish encrypted connection between TPM and CPU, which outside first-time configuration (which should happen in controlled environment anyway) should provide reasonable roadblock to successful MITM attack. But CPU-side software needs to use it, and without default well-known keys...

Doesn't work either: To establish the secure connection, you need some way to verify the other end (through public keys, certificates). That verification happens before any measurements can be done securely, so it can be bypassed.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#99

Post by marshray »

StillBored wrote: post #85

Ok, I understand how a TPM gets attached to a muxable GPIO block. But, did no one stop and question whether a TPM should have been on a dedicated block that couldn't be reprogrammed rather than assuming there wouldn't be bugs or whatever in the GPIO pin muxing? Never mind all the additional complexity of assuming page permissions access/etc to shared purpose MMIO regions? So, IMHO this starts as a hardware bug.

The CPUs and OSs (other than Windows 11) support operation without any TPM.

So either the pin is configurable, or you've wasted a pin that could otherwise be used for decorating the motherboard with RGB LEDs.

Also, the pin layout has to be standardized by the socket specification (eg "LGA 2011"), which may have to retain compatibility for a decade or more. This strongly favors defining reconfigurable over fixed-function pins.

Re: TPM GPIO fail: How bad OEM firmware ruins Intel TPM security

#100

Post by transpute »

kukrimate wrote: post #84
transpute wrote: post #83

Earlier quoted context omitted.

> discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC What are your thoughts on Microsoft Pluton and Google OpenTitan as TPM alternatives/emulators? Should system attestation roots of trust be based on open-source firmware? Recent AI/Copilot PCs based on Qualcomm SDXE/Or…

> What are your thoughts on Microsoft Pluton and Google OpenTitan as TPM alternatives/emulators? I am not familiar enough of the technical details of Pluton or OpenTitan to make a meaningful statement on their security. > Should system attestation roots of trust be based on open-source firmware? Yes, and not only root of trusts, I am strong believer in open source firmware in general. I have been developing coreboot…

Microsoft has supported open firmware for OCP Caliptra RoT, https://news.ycombinator.com/context?id=40131126

Hopefully we will see open firmware (Rust TockOS) on some version of Pluton, https://news.ycombinator.com/context?id=40557081

Post reply on HN