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

31–40 of 136 posts

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

#31

Post by Foxboron »

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

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

TPMs give you fine and adequate protections in many scenarios, even physical ones.

They also provide you with better protection for private key material.

I'll even give you an example:

https://github.com/Foxboron.keys

The last key is a TPM key from my `ssh-tpm-agent` project: https://github.com/Foxboron/ssh-tpm-agent

Here is the private key: https://paste.xinu.at/9fc2YJQuUCbg1Sa/

I don't remember if the key has a PIN (it was for a presentation/demonstration), but if it has it's like 4 digits long.

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

#32

Post by blueflow »

p_l wrote: post #25
blueflow wrote: post #15

Earlier quoted context omitted.

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

The TCB has not been modified - that's the point of that attack. Its just physically elsewhere. A high 24 dBi high gain antennae to close that gap costs 70 EUR and you would attest the device in the attackers hands, not the one in front of you.

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

#33

Post by blueflow »

Foxboron wrote: post #21
blueflow wrote: post #15

Earlier quoted context omitted.

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

The "replaced laptop" scenario is a full MITM on the hardware. TOTP generally does not protect against MITM. The required TOTP code is, in this scenario, generated by the device in the attackers hand. So the fake could also display it.

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

#34

Post by Foxboron »

blueflow wrote: post #33
Foxboron wrote: post #21

Earlier quoted context omitted.

`tpm2-totp` defeats the entire "replace the laptop" threat scenario. https://github.com/tpm2-software/tpm2-totp

The "replaced laptop" scenario is a full MITM on the hardware. TOTP generally does not protect against MITM. The required TOTP code is, in this scenario, generated by the device in the attackers hand. So the fake could also display it.

You need to decide between the attack here. Are you subverting hardware or are you replacing a laptop?

The TOTP token here is sealed inside TPM.

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

#35

Post by blueflow »

Foxboron wrote: post #34
blueflow wrote: post #33

Earlier quoted context omitted.

The "replaced laptop" scenario is a full MITM on the hardware. TOTP generally does not protect against MITM. The required TOTP code is, in this scenario, generated by the device in the attackers hand. So the fake could also display it.

You need to decide between the attack here. Are you subverting hardware or are you replacing a laptop? The TOTP token here is sealed inside TPM.

And what do you need to do to unseal it? And why cant the fake laptop relay that to the real laptop?

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

#36

Post by Foxboron »

blueflow wrote: post #35
Foxboron wrote: post #34

Earlier quoted context omitted.

You need to decide between the attack here. Are you subverting hardware or are you replacing a laptop? The TOTP token here is sealed inside TPM.

And what do you need to do to unseal it? And why cant the fake laptop relay that to the real laptop?

It's never unsealed. `tpm2-totp` does an encrypted session to the TPM and runs `TPM2_HMAC` on the TPM shielded key, you can also include PCRs to add further authentication to this entire exchange.

What do you mean with "relay"?

(All of this is trivially solved with glitter nail polish anyway.)

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

#37

Post by RedShift1 »

sim7c00 wrote: post #28
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 ke…

Heh I always thought that TPM was there to secure anything. If it's only meant for secure boot then I understand the poor tooling and absence of APIs to use the thing properly inside applications.

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

#38

Post by blueflow »

Foxboron wrote: post #36
blueflow wrote: post #35

Earlier quoted context omitted.

And what do you need to do to unseal it? And why cant the fake laptop relay that to the real laptop?

It's never unsealed. `tpm2-totp` does an encrypted session to the TPM and runs `TPM2_HMAC` on the TPM shielded key, you can also include PCRs to add further authentication to this entire exchange. What do you mean with "relay"? (All of this is trivially solved with glitter nail polish anyway.)

Yes and you can relay that authentication, too.

The same way the fake laptop can relay your password to me, i could also relay the generated TOTP code from the stolen laptop to the fake in front of you. As tried to convey, the fake laptop is basically a full MITM on your screen/keyboard.

Making a machine visuals non-reproducible helps that, but only if the attacker cannot easily switch the exterior parts (chassis, keyboard) between the two machines.

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

#39

Post by michaelt »

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

> 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. TPMs give you fine and adequate protections in many scenarios, even physical ones. They also provide you with better protection for private key…

> 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. 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. And although that's a bit limiting, once they've SSHed to a host as me once they can add their own key to authorized_keys in many cases.

That's why Yubikeys and U2F keys and suchlike have a physical button.

TPMs would be a lot more useful if the spec had mandated a physical button for user presence.

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

#40

Post by Foxboron »

blueflow wrote: post #38
Foxboron wrote: post #36

Earlier quoted context omitted.

It's never unsealed. `tpm2-totp` does an encrypted session to the TPM and runs `TPM2_HMAC` on the TPM shielded key, you can also include PCRs to add further authentication to this entire exchange. What do you mean with "relay"? (All of this is trivially solved with glitter nail polish anyway.)

Yes and you can relay that authentication, too. The same way the fake laptop can relay your password to me, i could also relay the generated TOTP code from the stolen laptop to the fake in front of you. As tried to convey, the fake laptop is basically a full MITM on your screen/keyboard. Making a machine visuals non-reproducible helps that, but only if the attacker cannot easily switch the exterior parts (chassis, ke…

> The same way the fake laptop can relay your password to me, i could also relay the generated TOTP code from the stolen laptop to the fake in front of you. Also any authentication to generate that TOTP in the first place. As tried to convey, the fake laptop is basically a full MITM on your screen/keyboard.

This is a hollywood level threat scenario.

It involves the attacker having intimate familiarity with the operating system, and having to break inn twice to even get this attack done.

If you do put inn the effort then I deserve to be hacked and can pick up sheep farming in the country side.

Post reply on HN