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

121–130 of 136 posts

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

#121

Post by kukrimate »

userbinator wrote: post #119
kukrimate wrote: post #114

Earlier quoted context omitted.

TPMs are a cryptographic coprocessor with added platform state attestation functionality. That can for example be used locally for secure secret storage that is only available in certain platform states, or remotely to certify the state of a device trying to access a corporate network. Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA…

Of course TPMs can be (ab)used for DRM, but the same property in general to many ideas in cryptography. We still don't say AES or RSA are tools designed to restrict your rights. AES and RSA are just algorithms, not implementations. I'd compare TPMs to HDCP, AACS, or CSS (the DVD one) instead.

Except that was never the purpose of TPMs unlike HDCP

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

#122

Post by tiberious726 »

dTal wrote: post #115
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…

>robust system state attestation (both local and remote) against attackers with physical access Phrases like this give me the shivers, as it translates into "mandatory surveillance by some authority telling me what I can and can't do with my computer". TPM is an evil concept. Physical access should be final.

So I get my hands on your laptop for a few minutes, there should be nothing you can do to impede me from doing whatever I want to it?

TPMs are awesome of you use them correctly, it's like having a yubikey built into your computer

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

#123

Post by tiberious726 »

Foxboron wrote: post #40
blueflow wrote: post #38

Earlier quoted context omitted.

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

There are like three operating systems in common use. An attacker being familiar with the one you use certainly isn't a "Hollywood level threat scenarios".

Buying the same model laptop and swapping it with your targets is an elementary level targeted attack

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

#124

Post by oasisaimlessly »

kukrimate wrote: post #109
wtallis wrote: post #95

Earlier quoted context omitted.

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.

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

eFuses, maybe? Or a bit of battery-backed SRAM. Lots of devices have a small amount of hardened storage for e.g. encryption keys. FPGAs supporting bitstream encryption and Atmel's ATSHA device line are examples.

> CryptoAuthentication devices have full metal shields over all of the internal circuitry, so that if an attacker cuts or short circuits any trace in the shield, the product stops functioning.

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

#125

Post by AnthonyMouse »

vel0city wrote: post #120
AnthonyMouse wrote: post #112

Earlier quoted context omitted.

If the machine is already on but asleep, the keys are in memory, they only have to be downloaded from the server on first login. If the machine has been off and you have no network connection then you need the long password to unlock it instead of the short one, but for most users that is already irrelevant because everything else requires a network connection too.

Ah ok, so I'll need to memorize the super long password whenever I'm out and about and want to just check something real quick. I guess I'll just put that on the sticky note on the bottom of the computer.

You want to check something real quick on what... the internet? Then you have internet access. You also have access to the local data on the machine as long as it was asleep rather than off, which will be the case the vast majority of the time.

Keeping the key stored on the machine, TPM or no, is also less secure than keeping it somewhere else. If someone steals your laptop, you deny all access to the key on the server and they can't get it even if they could guess the pin (or the user wrote that on the bottom of the computer), and there is no way to use an offline method to extract the key from the TPM because it isn't there.

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

#126

Post by vel0city »

AnthonyMouse wrote: post #125
vel0city wrote: post #120

Earlier quoted context omitted.

Ah ok, so I'll need to memorize the super long password whenever I'm out and about and want to just check something real quick. I guess I'll just put that on the sticky note on the bottom of the computer.

You want to check something real quick on what... the internet? Then you have internet access. You also have access to the local data on the machine as long as it was asleep rather than off, which will be the case the vast majority of the time. Keeping the key stored on the machine, TPM or no, is also less secure than keeping it somewhere else. If someone steals your laptop, you deny all access to the key on the serv…

> You want to check something real quick on what

Computers have these neat things called "local filesystems". They're a real hoot. Maybe you can get one on your computer.

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

#127

Post by AnthonyMouse »

vel0city wrote: post #126
AnthonyMouse wrote: post #125

Earlier quoted context omitted.

You want to check something real quick on what... the internet? Then you have internet access. You also have access to the local data on the machine as long as it was asleep rather than off, which will be the case the vast majority of the time. Keeping the key stored on the machine, TPM or no, is also less secure than keeping it somewhere else. If someone steals your laptop, you deny all access to the key on the serv…

> You want to check something real quick on what Computers have these neat things called "local filesystems". They're a real hoot. Maybe you can get one on your computer.

So the sole legitimate use case for a TPM is when you're somewhere with neither cellular service nor Wi-Fi (rare) and your portable device is off rather than asleep (rare) and you can't remember a long passphrase, which doesn't have to be unmemorable, it's just less convenient to type.

This seems like it isn't worth the cost in authoritarianism?

For that matter you could still implement even that with just a secure enclave that will only release the key given the correct PIN (and then rate limits attempts etc.), but then does actually release the key in that case and doesn't do any kind of remote attestation or signing.

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

#128

Post by dTal »

tiberious726 wrote: post #122
dTal wrote: post #115

Earlier quoted context omitted.

>robust system state attestation (both local and remote) against attackers with physical access Phrases like this give me the shivers, as it translates into "mandatory surveillance by some authority telling me what I can and can't do with my computer". TPM is an evil concept. Physical access should be final.

So I get my hands on your laptop for a few minutes, there should be nothing you can do to impede me from doing whatever I want to it? TPMs are awesome of you use them correctly, it's like having a yubikey built into your computer

>So I get my hands on your laptop for a few minutes, there should be nothing you can do to impede me from doing whatever I want to it?

Correct. This is true of all my other possessions as well.

Ultimately, the physical hardware of the computer cannot tell the difference between a legitimate user and an illegitimate one. The distinction is social, not mathematical - the kind of thing one might litigate in court, rather than by multiplying some large primes together. Technologically enforcing the concept of ownership over an object implies the construction of a parallel, extra-legal system of rights management, with some final higher authority that is neither you nor in all likelihood your government. Here's how that plays out: yes, you paid for the computer, yes, you "legally" own it, but you did something to it that Microsoft doesn't approve of and so we're afraid it doesn't work anymore. Might makes right. Too bad!

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

#129

Post by vel0city »

AnthonyMouse wrote: post #127
vel0city wrote: post #126

Earlier quoted context omitted.

> You want to check something real quick on what Computers have these neat things called "local filesystems". They're a real hoot. Maybe you can get one on your computer.

So the sole legitimate use case for a TPM is when you're somewhere with neither cellular service nor Wi-Fi (rare) and your portable device is off rather than asleep (rare) and you can't remember a long passphrase, which doesn't have to be unmemorable, it's just less convenient to type. This seems like it isn't worth the cost in authoritarianism? For that matter you could still implement even that with just a secure e…

> a secure enclave that will only release the key given the correct PIN

So...a TPM?

> This seems like it isn't worth the cost in authoritarianism?

You know what's really authoritarian? Having your computer practically only decryptable by some remote directory server, potentially not even under your control.

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

#130

Post by RedShift1 »

cryptonector wrote: post #90
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…

I wasn't looking to use it as a HSM, just decrypting a passkey would have been enough.
Post reply on HN