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

111–120 of 136 posts

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

#111

Post by logical_person »

kukrimate wrote: post #108
logical_person wrote: post #104

Earlier quoted context omitted.

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

before the popularity of ARM SoCs that contain everything on-die there were much fewer choices for vertically integrated devices. it's a different segment.

if you look at apple's vertically integrated devices, they chose a cryptography coprocessor that was not on die originally. with a key accessible only by both pieces of silicon's trusted execution environments, rather than the operating system directly, encrypted comms are established in a similar fashion as the TPM2.0 proposal.

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

#112

Post by AnthonyMouse »

vel0city wrote: post #101
AnthonyMouse wrote: post #55

Earlier quoted context omitted.

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

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.

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

#113

Post by Foxboron »

orf wrote: post #107
Foxboron wrote: post #47

Earlier quoted context omitted.

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

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

It's not. They are very much intended to derail serious discussions around threat models.

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

It's not. It's trivial to implement.

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

#114

Post by kukrimate »

userbinator wrote: post #68

Good. The only widespread uses of TPM are as user-hostile as any other DRM scheme. Stallman was right: https://www.gnu.org/philosophy/can-you-trust.en.html (Last few paragraphs.) See also: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...

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 are tools designed to restrict your rights.

In reality TPMs are almost always used to (attempt to) protect the user's data over restricting them.

I would argue that the discrete chip variation of them aren't very good at this (and even less good at DRM), but a lousy implementation doesn't mean the concept is bad. (As Foxboron mentioned earlier in this thread, discrete TPMs can still act as reasonably good "discounted" SmartCards, but they are bad at platforms state attestation.)

In fact I would have much preferred if the industry embraced the measured boot idea more instead of mainly pushing stricter verified boot schemes.

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

#115

Post by dTal »

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…

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

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

#116

Post by Foxboron »

josephcsible wrote: post #110
Foxboron wrote: post #86

Earlier quoted context omitted.

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

If ARM implements the UEFI specification then there are escape hatches to enroll your own PKI.

I don't own ARM machines with UEFI so I have no clue.

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

#117

Post by brendank310 »

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.

I get the reaction, but what about the trust factor of a box you own and have running on the other side of the world? TPM isn’t an evil concept, it’s fairly useful for some scenarios. Coercion to use TPMs, that sounds evil.

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

#118

Post by kukrimate »

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.

Is anyone here talking about survaillance??

That "attestation" in the full disk encryption case means your disk encryption key only being available to the operating system you chose to install. And disallowing the ability of a laptop thief to change that.

Or remote attestation can be used to restrict access to a corporate network to corporate controlled devices only. No one surveills you, or has access to your device in this scenario either, the TPM there is used to produce a certificate of the device state that can effectively act as access credentials to a resource.

This is about recognising the fact that the person in physical possession of a device isn't necessarily the legitimate owner.

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

#119

Post by userbinator »

kukrimate wrote: post #114
userbinator wrote: post #68

Good. The only widespread uses of TPM are as user-hostile as any other DRM scheme. Stallman was right: https://www.gnu.org/philosophy/can-you-trust.en.html (Last few paragraphs.) See also: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co...

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.

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

#120

Post by vel0city »

AnthonyMouse wrote: post #112
vel0city wrote: post #101

Earlier quoted context omitted.

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.

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.
Post reply on HN