Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

faulTPM: Exposing AMD fTPMs' Deepest Secrets

arxiv.org

Post reply on HN
Print view View original

211–220 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#211

Post by labcomputer »

Sunspark wrote: post #116
labcomputer wrote: post #79

Earlier quoted context omitted.

The point isn’t to store keys in the TPM. The point is to ensure you’re running an unmolested version of Windows that will enforce whatever security controls the DRM maker wants to have. Part of that is things like: * Don’t load an unsigned (or wrongly-signed) GPU driver, because it might be modified to allow a user to read from framebuffer memory after content has been decrypted.

All this effort for nothing making life difficult for the end-user. Physical video splitters are a thing. They are asked to respect HDCP, but they don't have to. It's how streamers are able to play a game on their monitor while also streaming the video of them playing the game.

Oh, no argument from me there, I’m just pointing out that you kinda need TPM to make your DRM not trivially bypassable.

I imagine that the MPAA et. al. are planning to attack the splitter thingy one day, so they’ll want to make sure you can’t slurp the frame buffer when that avenue is gone.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#212

Post by Arnavion »

einpoklum wrote: post #205
crote wrote: post #97

Earlier quoted context omitted.

You mean the Devuan which for more than a year and a half had a bug which resulted in the empty string being set as root password?[0] [0]: https://linuxiac.com/devuan-users-are-at-risk/

Nope. 1. That link is dead ("Access Denied") 2. The bug is not in Devuan, it's in something called refractainstaller, which is used for Devuan live-ISOs. If you just install Devuan that doesn't happen. 3. With a refractainstaller live-ISO, and if you chose to not define a root user, then this bug manifests. The bug seems to have lingered for so long because despite being rather obvious (i.e. you can just become root)…

>1. That link is dead ("Access Denied")

Works for me.

>2. The bug is not in Devuan, it's in something called refractainstaller, which is used for Devuan live-ISOs. If you just install Devuan that doesn't happen.

From the link:

>>When you download and install the desktop-live Devuan image, you will be prompted to create a user account at the end of the process.

... ie it seems to be talking about the normal process for installing a Linux distro - you make a live CD, boot it, and run the installer.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#214

Post by halJordan »

cma wrote: post #80
CircleSpokes wrote: post #75

Earlier quoted context omitted.

Not only do they hide it under a group policy even when you enable an "Enhanced PIN" there is a maximum length of 20.

Why do they do this, Samsung does the same tiny length limit for Secure Folder. Is it law enforcement requested?

It's because tpms are small and have small storage. The outrageous "its a secret cabal" voices are a prime example of what people cook up when faced with something they cant explain due to ignorance but feel the need to have an answer. Its as outrageous as a Republican saying "Q did it."

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#215

Post by 1827163 »

BlueTemplar wrote: post #149
Sunspark wrote: post #124

Earlier quoted context omitted.

I sometimes wonder if it'll be a selling point of Chinese CPUs in the future, "our CPU might not be the fastest, but it's the only one running at any given time!". People don't need "flagship" CPUs for every single purpose. There is no reason why one cannot have a slower more private system for specific purposes, say general purpose computing, and the faster one with the autonomous network-aware CPU and OS be used fo…

Issue here is that I trust the Chinese even less to not have something like this hidden in the hardware.

Interesting it is the Chinese processors (e.g. Allwinner, T-Head, Rockchip) that happen to be free of this secure boot garbage by default. If you want to you can blow an efuse (with power applied to the VPP pin) and enable secure boot. But otherwise it's off.

I am waiting for a high performance ARM or RISC-V chip that's on par with AMD and Intel performance. One without secure boot. The moment that comes out, my Ryzen system is going in the bin immediately.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#216

Post by Dylan16807 »

halJordan wrote: post #214
cma wrote: post #80

Earlier quoted context omitted.

Why do they do this, Samsung does the same tiny length limit for Secure Folder. Is it law enforcement requested?

It's because tpms are small and have small storage. The outrageous "its a secret cabal" voices are a prime example of what people cook up when faced with something they cant explain due to ignorance but feel the need to have an answer. Its as outrageous as a Republican saying "Q did it."

Wondering if something was requested by law enforcement isn't implying a cabal, chill.

Also a couple kilobytes of flash costs basically nothing. And you could hash keys over a certain length, which is much better than having such a short limit on a human-typed string.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#217

Post by ilyt »

Tuna-Fish wrote: post #157
moring wrote: post #95

Earlier quoted context omitted.

Amateur-me thinks that it would not be too hard to prevent such an attack: Have a voltage fault detection circuit at all (TPM-relevant) supply pins that hard-locks the chip until it gets power cycled, and have those circuits be powered by on-chip capacitors that survive just a little longer than their time-to-trigger. Would that be feasible?

This mitigation helps until the attackers stop confining themselves to the supply pins. You can do voltage fault injection through any exposed metal (or metal that can be made exposed), and the attacker can be entirely happy with attacks where they don't actually pull the voltage plane down, but instead just make some specific circuit a bit iffy by injecting an opposite voltage at some specific point and with low eno…

If you spike the voltage on other pin you'd most likely trigger ESD protection which is just a diode that's connected to one of the power rails, and spike the chip's power supply.

Which would be detected if internal watchdog monitors voltages. But if spikes are short enough they might be pretty hard (or just expensive) to detect.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#218

Post by ilyt »

whynotmaybe wrote: post #86
einpoklum wrote: post #83

Earlier quoted context omitted.

[flagged]

I'm a windows user since 3.1 and don't know much about linux except the few trials and my pihole. What's the impact of having systemd (or not) for the everyday layman like me that just uses Visual Studio Code to build flutter apps ?

> What's the impact of having systemd (or not) for the everyday layman like me that just uses Visual Studio Code to build flutter apps ?

Compared to initrd, after Debian upgrading to systemd, the system boots slightly faster and shuts down slightly slower (or same speed, depends really what you run)

By "unencumbered by systemd" they mostly mean "works worse". We've removed tens of thousands lines of fixes for "easy", "simple" sysv scripts when we upgraded our servers to version that runs systemd.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#219

Post by ilyt »

kaetemi wrote: post #181
CameronNemo wrote: post #158

Earlier quoted context omitted.

You have no idea who designed the thing, who manufactured it, or who swapped it out while it was in shipping to you Wait, what? In most cases you 100% know who designed and manufactured it. Regarding "swapping out" a TPM, how do you do that for fTPMs or TPMs that are on the same die as the CPU? Come up with a perfect replica AMD CPU with a bugged TPM? Desolder the original CPU and put the replica in?

The only one that would fit my mainboard I bought on Amazon, and I only got it to upgrade Windows. The indication on it is "made in China". As a consumer I also have no idea how these suspicious chips that I'm required to plug into my mainboard are supposedly trusted, and by whom, and what for. "Plug this chip that says made in China into your mainboard, for security reasons, to continue." is not really emitting trus…

> "Plug this chip that says made in China into your mainboard, for security reasons, to continue." is not really emitting trust or confidence in any way. "

I'm sure 30 other chips made in china on same board are entirely fine

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#220

Post by cryptonector »

the8472 wrote: post #209
cryptonector wrote: post #199

Earlier quoted context omitted.

Yes, you can get compromised through firmware updates. But then, not using a TPM also leaves you vulnerable to firmware and software updates. If NSA has compromised all TPM vendors, then you can expect that they've compromised much more still, and so you've basically lost the fight against them. Key management is always a weak link in the chain. I.e., I'm objecting to this focus on TPM in TFA and this discussion beca…

> Yes, you can get compromised through firmware updates. It's not just about updates through regular channels but about evil maid attacks with signed malicious firmware. This vector would be avoidable if you could sever the trust relationship. Another wrinkle is that some of the blobs are encrypted (e.g. ME), so they can't even be audited. Currently too much of the trust chain relies on untrustworthy components. So y…

> It's not just about updates through regular channels but about evil maid attacks with signed malicious firmware.

Yes, evil maid attacks are the primary way for targeted attacks using malicious firmware.

So this is something that maybe the TCG should tackle. It should be possible (maybe it is?) to require that the host meet some policy before the firmware update can run -- this would prevent unauthenticated evil maid attacks.

Post reply on HN