TPM GPIO fail: How bad OEM firmware ruins Intel TPM security • Hacker News Board

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

#101

Post by vel0city » Thu, Jun 06, 2024, 8:40 PM UTC

AnthonyMouse wrote: post #55

michaelt wrote: post #27

Earlier quoted context omitted.

The goalposts haven't moved in my mind, but I suppose I didn't make them clear in my first post. Basically the TPM provides a set of features that are really useful for corporate Windows deployments. No more forgotten passwords, because the self-unlocking disk encryption sends the user straight to the Windows login screen, and helpdesk can reset forgotten Windows passwords remotely. And for casual home Windows users,…

> Basically the TPM provides a set of features that are really useful for corporate Windows deployments. No more forgotten passwords, because the self-unlocking disk encryption sends the user straight to the Windows login screen, and helpdesk can reset forgotten Windows passwords remotely. Unclear why this requires a TPM. Boot the system from a static unencrypted partition containing no sensitive data, display the lo…

What happens when I try and login offline or unable to reach a directory server?

FWIW, Bitlocker already can store recovery keys in AD. It has been a feature for a long time.

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

#102

Post by fargle » Thu, Jun 06, 2024, 9:02 PM UTC

blueflow wrote: post #15

izacus wrote: post #4

Earlier quoted context omitted.

> Of course, that doesn't mean you're protected against attackers who have physical access to the machine; they can simply install a keylogger. How would that attack work if someone stole my Ryzen powered laptop with full disk encryption, TPM2.0 and secure boot with firmware password enabled?

I'd buy you an replacement laptop of the same model and then install a rendering of your boot process and password prompt on it. Doing a switcheroo and waiting in my bunker until the fake sends me the password you entered. The screen/keyboard is not authenticated to the user, and TPM is not capable of fixing that. It doesn't require some state actor to do that. Just money.

i like the way you think

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

#103

Post by IshKebab » Thu, Jun 06, 2024, 9:10 PM UTC

Vogtinator wrote: post #98

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

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.

I think he's saying you can verify the other end by manufacturing the PC yourself and making the initial connection in your factory.

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

#104

Post by logical_person » Thu, Jun 06, 2024, 9:13 PM UTC

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…

> encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation

this is completely incorrect, encrypted sessions defeat TPM interposers when there is a factory burned-in processor side secret to use. lol at being just "obfuscation" because you can spend $5m to decap and fetch the key then put the processor back into working order for the attack.

that just requires a vertically integrated device instead of a consumer part-swappable PC.

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

#105

Post by lowestdecks » Thu, Jun 06, 2024, 9:16 PM UTC

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

Real world example of a use of TPMs (outside of bootloaders) that has a positive effect on users: https://blog.chromium.org/2024/04/fighting-cookie-theft-usin...

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

#106

Post by [deleted] » Thu, Jun 06, 2024, 10:32 PM UTC

Foxboron wrote: post #45

blueflow wrote: post #42

Earlier quoted context omitted.

Why twice? You can keep the fake laptop. The OS does not matter? Grab the video output via HDMI/DisplayPort and insert the keypresses via USB. Thats likely gonna work. Basically what modern KVM switches do. And setup the fake laptop as VNC client. Same tech that companies can use to remotely manage servers.

> The OS does not matter? Of course it does. You are replaying the logos and screens. > Grab the video output via HDMI/DisplayPort and insert the keypresses via USB. Thats likely gonna work. Basically what modern KVM switches do. And setup the fake laptop as VNC client. Same tech that companies can use to remotely manage servers. You believe you can boot up an entire VNC client to display something that would take mo…

[deleted]

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

#107

Post by orf » Thu, Jun 06, 2024, 10:36 PM UTC

Foxboron wrote: post #47

blueflow wrote: post #46

Earlier quoted context omitted.

> You are replaying the logos and screens Which the real machine happily gives me via HDMI/DisplayPort. > You believe you can boot up an entire VNC client to display something that would take most machines under a second to display? Do i need to? That the user presses the power button does not mean the machine will freshly boot. It could also be an unsuspend/wakeup or some regular ACPI event if the machine is only ap…

> Do i need to? That the user presses the power button does not mean the machine will freshly boot. It could also be an unsuspend/wakeup or some regular ACPI event if the machine is only appearing to be off. This is a completely imaginary scenario. I'd be amazed to see it pulled off. EDIT: I hear Amazon is still getting pitches for Hacker 2. You might have a shot.

OP is trying to say that this TPM TOTP approach doesn’t help verify a machine is legitimate if there is a possibility that the machine you’re using has been swapped with a malicious one.

This doesn't really mesh well with what the TPM-TOTP idea is trying to solve: trust in the machine you’re using.

Hyperbolic or fairly extreme-sounding scenarios are common when discussing this kind of thing, partly because it makes discussion about a fairly boring topic a little bit more interesting. Don’t get distracted by that.

That being said, using a TPM-based TOTP is pretty extreme sounding in and of itself.

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

#108

Post by kukrimate » Thu, Jun 06, 2024, 10:41 PM UTC

logical_person wrote: post #104

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…

> encrypted sessions (and/or EK cert verification) without PIN are not much more then obfuscation this is completely incorrect, encrypted sessions defeat TPM interposers when there is a factory burned-in processor side secret to use. lol at being just "obfuscation" because you can spend $5m to decap and fetch the key then put the processor back into working order for the attack. that just requires a vertically integr…

What you are saying is sound, and I agree it could be done.

But there are multiple caveats: - How do you hide the secret so that only "legitimate" operating systems can use it for establishing their sessions and not "Mate's bootleg totally not malware live USB"? - And unfortunately current CPUs don't implement this. - Additionally don't be so smug to think you need to decap a CPU to extract on-die secrets. Fault injection attacks are very effective and hard to defend against.

I agree the security of this can somewhat be somewhat improved, but if you are building a custom CPU anyhow, you might as well move the TPM on-die and avoid this problem entirely.

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

#109

Post by kukrimate » Thu, Jun 06, 2024, 10:43 PM UTC

wtallis wrote: post #95

kukrimate wrote: post #81

Earlier quoted context omitted.

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"?

Because where do you store the CPU side private key after the exchange for future sessions?

The secure storage is the TPM, but here you cannot obviously store the secret in the TPM, it's a chicken and egg problem.

Thus your secret could only be on disk or in flash in and the attacker can just get it.

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

#110

Post by josephcsible » Fri, Jun 07, 2024, 1:51 AM UTC

Foxboron wrote: post #86

kukrimate wrote: post #82

Earlier quoted context omitted.

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.

Isn't this only true of x86 ones, not ARM ones?