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

81–90 of 136 posts

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

#81

Post by kukrimate »

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...

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.

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

#82

Post by kukrimate »

nottorp wrote: post #57

Can you use this to install linux on motherboards locked to windows boot loaders in firmware? :)

No.

But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please.

Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.

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

#83

Post by transpute »

kukrimate wrote: post #80
Foxboron wrote: post #13

Earlier quoted context omitted.

BUS interposers are trivially defeated with encrypted sessions and a PIN. Bitlocker is traditionally the implementation susceptible for this attack, but for that I'll just defer to Chris Fenner. https://www.dlp.rip/tpm-genie

The PIN is the important part there, encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation, and defeated by both the interposer attack, and the tweezer attack. (Or the TPM hack to rule them all, e.g. desoldering the chip and connecting it to a microcontroller you control) I supposse a PIN is a slight improvement over a regular password, but a big appeal of TPM FDE in my opini…

> 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/Oryon/Nuvia, AMD Zen5 and Intel Lunar Lake include Microsoft Pluton.

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

#84

Post by kukrimate »

transpute wrote: post #83
kukrimate wrote: post #80

Earlier quoted context omitted.

The PIN is the important part there, encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation, and defeated by both the interposer attack, and the tweezer attack. (Or the TPM hack to rule them all, e.g. desoldering the chip and connecting it to a microcontroller you control) I supposse a PIN is a slight improvement over a regular password, but a big appeal of TPM FDE in my opini…

> 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 as a hobby for a long time. I wish their was more industry support for such things, especially at the lowest levels of modern systems.

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

#85

Post by StillBored »

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.

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

#86

Post by Foxboron »

kukrimate wrote: post #82
nottorp wrote: post #57

Can you use this to install linux on motherboards locked to windows boot loaders in firmware? :)

No. But on essentially all existing UEFI systems you can trivially overwrite the "db" keystore in flash and install anything you please. Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.

> Also most (all?) UEFI systems are not locked to Windows and allow customizing the keystore via the firmware console interface anyhow.

All of them.

The Secured Core machines still allows you to reset Secure Boot into user mode as mandated by the spec.

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

#87

Post by RedShift1 »

klysm wrote: post #58
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...

What about systemd credentials?

App runs on Windows

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

#88

Post by kukrimate »

LeifCarrotson wrote: post #53
bee_rider wrote: post #29

Earlier quoted context omitted.

I have to believe there are hardware engineers out there who know locking people out of their devices is essentially bad, and so they leave in those tweezer based attacks on purpose. Although, designing against physical attacks is very difficult, so I guess there’s no need to imagine a good-hearted conspiracy of conscientious hardware folks.

The fundamental operation in hardware engineering is the digital signal, pulling a pin to one or zero - which is all the tweezer attack does. It's comparable to writing a byte of memory. Imagine how hard software security would be if your adversaries could write arbitrary data to your process: there's no ASLR or even an MMU to randomize trace layouts on physical circuit boards.

Well yes, but there is a difference between a signal being accessible on a PCB trace I can see with my eyes, vs it being accessible only on the inside of a 7nm silicon die.

There is a reason why a lot of system integrate the security processor on the same piece of silicon whose state the security processor is meant to protect.

The reason discrete TPMs exist is supposed compliance with crypto standards, and physical protection against key extraction, but they sort of miss the forest before the trees. What matters to users is the protection of their data, not the TPM's secrets, and discrete TPMs arent very good at the former.

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

#89

Post by cryptonector »

Foxboron wrote: post #13
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…

BUS interposers are trivially defeated with encrypted sessions and a PIN. Bitlocker is traditionally the implementation susceptible for this attack, but for that I'll just defer to Chris Fenner. https://www.dlp.rip/tpm-genie

Problem is that the BCM and the BIOS/UEFI and every component talking to the TPM all need to store one (or more) public keys for it (and the corresponding templates and/or save files) in order to set up encrypted sessions to the TPM.

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

#90

Post by cryptonector »

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...

Discrete (i.e., chip) TPMs (dTPMs) are slow. They are way too slow to use as HSMs.

Firmware TPMs (fTPMs) are faster, but I doubt they're really fast enough to use as an HSM.

There are TPM APIs for Java, so you can do this, but it's not surprising that the Java keystore providers lack builtin support because of the performance issues.

Ideally fTPMs should come with EKcerts and platform certificates and they would be very fast and as secure as (more so than) dTPMs. Then using fTPMs as HSMs might take off.

Post reply on HN