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

71–80 of 136 posts

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

#71

Post by bee_rider »

II2II wrote: post #64
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 problem with that approach is that it also weakens security for people who genuinely need it.

There’s some value to being able to lock a device against somebody who physically has control of it. Like it is nice that stolen iPhones have reduced value.

But there’s a pretty big social harm to locking people out of their devices, like the generation of tech-illiterate kids growing up that haven’t been allowed to break their computers well enough to learn anything about them.

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

#72

Post by voxic11 »

CivBase wrote: post #67
CodeArtisan wrote: post #63

Earlier quoted context omitted.

Each TPM having an unique certificate, you may use that to trace a specific machine to a specific user. Game developers could use that to ban (toxic) players from an online service, for example.

Couldn't they just reset their TPM to change their "identity"? Or use a different computer or VM? Also, I'd be pretty frustrated if I was sharing a PC with someone and they got me banned from a game.

If you are sharing a computer with a hacker then your account would be banned anyways. All the tpm does is ensure you can't just make another account and use it from that computer.

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

#73

Post by jnwatson »

Foxboron wrote: post #44
RedShift1 wrote: post #37

Earlier quoted context omitted.

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.

It's not meant for Secure Boot. They are two separate, but adjacent, technologies that provide their own security properties in a boot chain. This is a common misconception.

It is absolutely used and designed for secure boot. There are now simpler mechanisms to accomplish the same thing, but if you want remote attestation, you need a TPM.

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

#74

Post by dist-epoch »

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.

A solution would be to have two passwords, and display a secret security image between them.

User is required to not enter the second password if the wrong security image is displayed.

You can still attack it with a fancy radio transmitter which transmits the security image from the stolen laptop when it's displayed after you've entered the first password to the second laptop.

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

#75

Post by hedora »

blueflow wrote: post #49
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.

Windows Fastboot (active per default) is suspend disguised as shutdown: https://www.windowscentral.com/how-disable-windows-10-fast-s...

I'd like to add that the VNC relay machine only has to fool the end user once. So, the attacker wins as long as they think "the bios is a bit janky this morning, and this is more kernel panicky than usual", and type their pin/password anyway.

Of course, it's much easier to just pop the original laptop open and interpose on the keyboard. Even easier: use acoustics to snoop the keystrokes. The snooper could even be 5g/wifi/gps, assuming it's easy to steal some power from the mainboard. I guess fingerprint + camera ID make that attack harder. Still, the hypothetical device could stream HDMI at a few FPS if it was easy to splice into the display panel cable. (I haven't cracked a laptop recently, but those used to be socketed + unencrypted.)

Miniaturization is weird. The latter attack is probably easier to pull off these days than the former. If you wanted to swap my laptop, you'd need to replicate the dents and stickers. Good luck doing that!

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

#76

Post by hedora »

blueflow wrote: post #32
p_l wrote: post #25

Earlier quoted context omitted.

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.

I think some of those hardware attestation thingies use clocks and tight latency jitter bounds to make replay attacks harder. If it takes more than "2 x time light takes to move 10 ft + deterministic delay from the other side", or less than the deterministic delay, then they refuse to unlock.

Some cars even get this right these days. Most don't.

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

#77

Post by mindslight »

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

Not the only uses, but certainly all of the widespread implementations of trusted hardware just haven't been able to avoid that temptation of privileging the manufacturer while securing against the user themselves. Every little hole is another setback that keeps the designers/implementers working on this layer instead of starting to tighten the noose on the next one.

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

#79

Post by zoeysmithe »

michaelt wrote: post #2

> If attacker have physical access, the discrete TPM is an attack surface anyway and even a known attack already. If you're wondering what they mean by this, [1] has been around since 2018. It's not unusual for a motherboard to put the TPM on a removable module, so you don't even have to desolder the chip to MITM the communications. The most recent Intel and AMD CPUs have "firmware TPMs" that run in the CPU's so-call…

and by recent, TPM was external last in gen 8 of intels, so this attack works on cpus released last in October 2017. That's almost 7 years ago. Most organizations have a 3-5 year replacement schedule.

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

#80

Post by kukrimate »

Foxboron wrote: post #13
michaelt wrote: post #2

> If attacker have physical access, the discrete TPM is an attack surface anyway and even a known attack already. If you're wondering what they mean by this, [1] has been around since 2018. It's not unusual for a motherboard to put the TPM on a removable module, so you don't even have to desolder the chip to MITM the communications. The most recent Intel and AMD CPUs have "firmware TPMs" that run in the CPU's so-call…

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 opinion is unattended unlock.

I think discrete TPMs don't really have a future in systems that need robust system state attestation (both local and remote) against attackers with physical access. TPMs should be integrated into the CPU/SoC to defend against such attacks.

Post reply on HN