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

51–60 of 136 posts

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

#51

Post by michaelt »

Foxboron wrote: post #41
michaelt wrote: post #39

Earlier quoted context omitted.

> TPMs give you fine and adequate protections in many scenarios [...] my `ssh-tpm-agent` project I agree that's adequate, in the sense that keeping the an SSH key as a password-protected file on disk is adequate, and having it be a password-protected secret in the TPM is no less secure than that. But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine…

> But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine. An attacker with root can simply replace the software that reads your PIN with a modified version that also saves it somewhere. Then they can use the key whenever your computer is online, even if they can't copy the key off. It protects against extraction, not usage on the machine itself. Of c…

> It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.

Yes, this is why I was careful to say that the benefits are obscure, rather than saying they're entirely nonexistent.

I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on.

Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.

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

#52

Post by Foxboron »

michaelt wrote: post #51
Foxboron wrote: post #41

Earlier quoted context omitted.

> But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine. An attacker with root can simply replace the software that reads your PIN with a modified version that also saves it somewhere. Then they can use the key whenever your computer is online, even if they can't copy the key off. It protects against extraction, not usage on the machine itself. Of c…

> It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine. Yes, this is why I was careful to say that the benefits are obscure, rather than saying they're entirely nonexistent. I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-si…

> I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on

None of this is needed to take advantage of TPMs.

> Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.

Yubikeys are expensive devices, and TPMs are ubiquitous. Better tooling solves this problem.

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

#53

Post by LeifCarrotson »

bee_rider wrote: post #29
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.

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.

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

#54

Post by hun3 »

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.

You could scramble/authenticate the signals though, if you don't mind the huuuuuuuge performance penalty.

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

#55

Post by AnthonyMouse »

michaelt wrote: post #27
izacus wrote: post #18

Earlier quoted context omitted.

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,…

> 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 login screen, when the user authenticates the system uses their credentials to get the FDE decryption key from the directory server. Bonus: Now the FDE keys are stored in the directory server and if the system board fails in the laptop you can remove the drive and recover the data.

An attacker with physical access could modify the unencrypted partition to compromise the user's password the next time the user logs in, but they could do the same thing with a hardware keylogger.

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

This could be implemented the same way using Microsoft's servers, given that they seem to insist you create a Microsoft account these days anyway.

It's not clear that unsophisticated users actually benefit from default-FDE though. They're more likely to lose their data to it than have it protect them from theft, and losing your family photos is generally more of a harm than some third party getting access to your family photos.

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

#56

Post by michaelt »

Foxboron wrote: post #52
michaelt wrote: post #51

Earlier quoted context omitted.

> It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine. Yes, this is why I was careful to say that the benefits are obscure, rather than saying they're entirely nonexistent. I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-si…

> I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on None of this is needed to take advantage of TPMs. > Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by…

> None of this is needed to take advantage of TPMs.

You're not binding the secret to PCR values? I thought TPM fans loved those things?

I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

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

#58

Post by klysm »

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?

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

#59

Post by Foxboron »

michaelt wrote: post #56
Foxboron wrote: post #52

Earlier quoted context omitted.

> I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on None of this is needed to take advantage of TPMs. > Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by…

> None of this is needed to take advantage of TPMs. You're not binding the secret to PCR values? I thought TPM fans loved those things? I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

> You're not binding the secret to PCR values? I thought TPM fans loved those things?

Binding things to PCR values doesn't imply you need Secure Boot, signed initrd, lockdown mode, shim and signed kernel modules. All of these things are individual security measures that can be combined depending on your threat model.

> I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.

The v2.0 version of TPM doesn't really make PCR policies easier to use, so I've had troubles getting them properly integrated into the tools I write as you need to deal with a key to sign updated policies. `systemd-pcrlock` might solve parts of this but it's all a bit.. ugly to deal with really.

The entire TPM specc is not great. But I find TPMs too useful to ignore.

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

#60

Post by HeatrayEnjoyer »

xattt wrote: post #30
rwmj wrote: post #16

Earlier quoted context omitted.

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.

Relays can be prevented with a round-trip timeout. Limit to 8ft/c, should be plenty for a keyboard. You can't outpace light.
Post reply on HN