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

21–30 of 136 posts

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

#21

Post by Foxboron »

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.

`tpm2-totp` defeats the entire "replace the laptop" threat scenario.

https://github.com/tpm2-software/tpm2-totp

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

#22

Post by p_l »

SSLy wrote: post #11
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...

vast majority of fTPM 2.0's are chips placed on the CPU die anyway

it's a misnomer, a bit.

fTPM is a firmware-based TPM implemented, usually, by coprocessor (or trustzone style enclave) inside the CPU, yes. It's not related to what TPM standard it implements

You can also have external TPM 2.0 compliant devices (commonly referred to as dTPM, probably brought the naming from iGPU/dGPU), and in fact many options offered for making desktops fully compliant with windows 11 (which requires TPM 2.0) involve a dedicated TPM 2.0 chip.

Ultimately, TPM standard does not care where the chip is, it just provides mechanisms for their use, which do include encrypted tamper protected interface... if one wants to use it.

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

#23

Post by michaelt »

izacus wrote: post #10
wooosh wrote: post #6

Earlier quoted context omitted.

Probably not the most practical attack, but it is very possible to MITM the connection between the keyboard itself and the motherboard.

And then return me my laptop and steal it again?

A high grade hardware implant doesn't just capture your password, it'll also replay your password along with a curl | sudo bash at 4am

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

#24

Post by SSLy »

p_l wrote: post #22
SSLy wrote: post #11

Earlier quoted context omitted.

vast majority of fTPM 2.0's are chips placed on the CPU die anyway

it's a misnomer, a bit. fTPM is a firmware-based TPM implemented, usually, by coprocessor (or trustzone style enclave) inside the CPU, yes. It's not related to what TPM standard it implements You can also have external TPM 2.0 compliant devices (commonly referred to as dTPM, probably brought the naming from iGPU/dGPU), and in fact many options offered for making desktops fully compliant with windows 11 (which require…

You're correct, but also I'm reasonably certain that, as much bullshit the list of Win 11 supported CPUs is, all the CPUs on it have fTPM 2.0 available.

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

#25

Post by p_l »

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.

Attestation closes this vulnerability, for example through tools like Ultrablue [1] which provides a self-hosted method of verifying that the TCB has not been modified through external tool (in this case, your phone running Ultrablue)

[1] https://github.com/ANSSI-FR/ultrablue

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

#26

Post by RedShift1 »

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

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

#27

Post by michaelt »

izacus wrote: post #18
xzjis wrote: post #17

Earlier quoted context omitted.

You have to consider what kind of risk you are protecting yourself against. It's highly unlikely that you would be the target of such a highly sophisticated attack, but a hacker could get into a place where you left your computer without surveillance (such as your home or a hotel) for about 15 minutes, and install it inside your computer. If you think you could be the target of such an attack, you could maybe enable…

I'm mostly asking because the original poster was painting a process that can be sniffed off the bus (that is - buy a stolen laptop off ebay, try to boot it, sniff the key off the bus) with a process that requires active targeting and multiple breakins to work as equivalent. It seems like these security discussions always devolve into rather funny moving of goalposts without actually considering how much work each ex…

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, it lets them log in with a 4-digit PIN or with biometrics, so it's got usability benefits for them too. If every OS now needs Microsoft's signature of approval, or a really fiddly setup process? Well they were running Windows anyway, so no problem.

These usability/support benefits rely on self-unlocking disk encryption, which is vulnerable to sniffing if someone gets a stolen laptop on ebay.

For the kind of technically sophisticated, security enthusiast users who comment on blog posts about TPMs? We're more than happy to key in a strong unique password at every boot, and if we forget the password and lose access to everything on that disk that's just the system working as it's supposed to.

For us, the benefits of TPMs and measured boot for personal use are a lot more obscure. You'll sometimes hear people claim it protects against 'evil maid attacks' where an attacker repeatedly gets physical access to your laptop. The truth is it provides no such protection.

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

#28

Post by sim7c00 »

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

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 key, what for example AV vendors do, is have a (efi?)driver that contains the certificate, which is a boot-driver protected by secure-boot. - for windows this might require Microsoft cooperation to assign you a driver level so other stuff can't disable it (otherwise it's still tricky and possible to get around your protections likely). (windows -> process protection light / telam drivers). Optionally you could also have the certificate provided by an EFI applcation somehow that's signed / secured by secureboot. (could drop it on disk somewhere, efi partition is easily accessible...).

If the chain is protected by the tpm, this method if implemented correctly through the whole chain should protect your cert and pkey.

that being said _should_ is the keyword,. i dont think any platform really managed to escape all attacks, though a lot in this area do need hw access (the tweezers previously implemented by the author :)).

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

#29

Post by bee_rider »

rf15 wrote: post #19

> briefly grounding the reset pin of a discrete TPM device with a pair of tweezers Ah, the tweezers strike again, just not for Nintendo this time. Truly the most universal hardware hacking tool.

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.

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

#30

Post by xattt »

rwmj wrote: post #16
izacus wrote: post #10

Earlier quoted context omitted.

And then return me my laptop and steal it again?

Bluetooth keyloggers are a thing. The attacker would need to be nearby.

Not if there’s some sort of cell bridging device nearby as well.
Post reply on HN