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

201–210 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#201

Post by cryptonector »

amluto wrote: post #177
cryptonector wrote: post #175

Earlier quoted context omitted.

Note that the SPI bus sniffing attacks on dTPMs are simpler to mount (being passive) but also require direct access to the bus (motherboard), and unlike this attack can be prevented in software by knowing the public key of a primary key object on the TPM (e.g., the endorsement key) and using it to authenticate the TPM to the host. That said, even a host using a dTPM with proper authentication of the dTPM has a proble…

I haven't looked closely at the TPM protocols lately, but I think this doesn't help against active bus attacks against a dTPM. The host can (I think) reboot the dTPM and send an arbitrary sequence of PCR changes to the dTPM, and the dTPM will believe it. And then the host can ask the dTPM to unseal something, and it will. This won't help break a PIN that is protected by the dTPM, but it will fully break any protectio…

TPM 2.0 Extended Access policies can be very complex. You can make it so that in order to unlock key objects in the TPM you have to have more than matching PCRs, but also a PIN, and the software on the host shouldn't provide the PIN if the PCRs don't match what it expects. Of course, TPM-using software is still too simple in this regard so that you're correct right now, but it doesn't have to be that way.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#202

Post by MrStonedOne »

flangola7 wrote: post #90
taraharris wrote: post #13

Why not simply abandon TPM and focus on making simple, trustable, massively parallel general-purpose hardware without backdoors for spy agencies and corporations? Whose computer is this, anyway?

Without a TPM servers can't verify that their genuine app is being used. https://developer.apple.com/documentation/devicecheck/valida...

Why should they have that right?

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#204

Post by yarg »

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 ?

Very little.

It's an idealogical flamewar, that in most cases is without impact.

The binary format of the log file still seems to me to be a bad idea - it introduces corruptibility and complexity to a vital service that should be simple and uncorruptible.

If a failing system starts to do weird things, plain text append only logging is preferable.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#205

Post by einpoklum »

crote wrote: post #97
einpoklum wrote: post #83

Earlier quoted context omitted.

[flagged]

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) because nobody tried to secure a live-ISO-based system, which is something you typically use as a "rescue disk" or to diagnose hardware.

So - is this a screw-up? Yes. Does it reflect significantly on Devuan as a project? Not really.

To draw a parallel - the fact that systemd has had bugs which other init systems didn't, or had gotten over decades before, does not mean it's an undesirable project. My (and many people)'s problems with systemd regard its fundamental design philosophy, as well as its governance/behavior as a software project.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#206

Post by labcomputer »

dathinab wrote: post #120
labcomputer wrote: post #73

Earlier quoted context omitted.

Erm… yes, actually. For DRM to work, it has to be running in a trusted environment where the user can’t just load up a debugger as superuser and read the keys from memory. The way you do that is by using secure boot to ensure that you are running a trusted kernel that enforces appropriate access controls… which requires TPM. One of the main selling points of TPM is that you have chain of trust to ensure the boot proc…

no secure boot only enforces you run a trusted kernel not that the kernel enforces access controls and in a full secure boot implementation the user can freely choose what _they_ trust and attacks which mess with the boot chain have been a huge problem for a long time for enterprises, TPM likely would have ended up very similar to how it did even if there wouldn't be DRM. Also the DRM lobby has since a long time push…

> no secure boot only enforces you run a trusted kernel not that the kernel enforces access controls

Yes, I am aware of that. But having DRM that is not completely ineffective has a prerequisite that it runs on a kernel that does enforce those access controls. The only way that works is with a trusted boot chain.

You originally responded “no” to a post saying that one purpose of TPM is to facilitate DRM.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#207

Post by wkat4242 »

cryptonector wrote: post #183
Cheeeetah wrote: post #146

Earlier quoted context omitted.

The manufacturers perhaps. They provide the keys in the modules anyway. BTW, there is Chinese passport law which states that the algorithm should be independently developed. The law once blocked TPM 1.0 but allows TPM 2.0

Yes, if you want to recover keys from a dTPM you have two options: - decap it, scan it with an electron scanning microscope, reverse engineer it (or have already done so), and read the seeds and all NVRAM on the chip - force the manufacturer to record the seeds even though they have processes to never do so, then force the manufacturer to reveal the seeds a dTPM shipped with given an EKpub for it A few nation states…

They have some weaknesses. A dTPM uses an unencrypted protocol to communicate with the CPU (simple i2c or SPI) and it's pretty easy to sniff it if you manage to get legit access. But you do need a legit user to log in to the machine once. This is a bit of an achilles heel.

Example: https://arstechnica.com/gadgets/2021/08/how-to-go-from-stole...

In this sense an integrated solution is better because there is no simple bus to sniff, but it does have to be properly implemented of course. Which seems to be not the case here.

By the way a dTPM should have a real entropy RNG so technically it shouldn't have any (usable) seed. It's basically a smartcard soldered onto the mainboard. Of course smartcards can also have key generation flaws like the Infineon flaw a while back. https://www.schneier.com/blog/archives/2017/10/security_flaw...

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#208

Post by yarg »

ridgered4 wrote: post #110
jeroenhd wrote: post #47

Earlier quoted context omitted.

It'll work fine, Microsoft even explains how to upgrade: https://support.microsoft.com/en-us/windows/installing-windo... They chose an arbitrary cut-off date for hardware support for their new OS. They decided not to support old stuff anymore and they had to pick a date/technology platform. It was always going to be arbitrary. In my opinion they should've picked a clearer distinction (i.e. require a certain level of…

That link does not say it will work fine. It says it is not recommended or supported and if it blows up it is your problem. Additionally it says you might not get any updates. Certainly, it sounds like it might just be some ass covering on their part but they were also testing a nag watermark for unsupported installs like this so maybe not. Either way it doesn't sound like a really solid path forward.

He said it'll work fine, not that Microsoft is promoting it as such.

There're no fundamental changes to what's actually required, the limitations are arbitrary and set by Microsoft (and they provide a means to get around them).

It'll work fine.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#209

Post by the8472 »

cryptonector wrote: post #199
the8472 wrote: post #193

Earlier quoted context omitted.

You cut off the "including the firmware signing keys" part, that's critical. Otherwise the vendor could be coerced or subverted to sign malicious firmware which then subverts your system at runtime. Only when you can bring your own keys for the entire boot and trust chain can you untether yourself from the vendor once you have purchased the hardware.

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 you can't trust the system. But the DRM vendor can well enough for their purposes. Which makes them a negative.

> I.e., I'm objecting to this focus on TPM in TFA and this discussion because a voltage fault injection vulnerability in the SP is fatal to security regardless of TPM usage/non-usage.

Yes, agreed.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#210

Post by labcomputer »

hnj2 wrote: post #143
labcomputer wrote: post #73

Earlier quoted context omitted.

Erm… yes, actually. For DRM to work, it has to be running in a trusted environment where the user can’t just load up a debugger as superuser and read the keys from memory. The way you do that is by using secure boot to ensure that you are running a trusted kernel that enforces appropriate access controls… which requires TPM. One of the main selling points of TPM is that you have chain of trust to ensure the boot proc…

Author here: TPMs are not a TEE (trusted execution environment), and the TEE included in AMD's CPUs function completely separately from the TPM. So you could disable the TPM and still have the TEE run DRM code. The fact that both TEE and fTPM run on the PSP (or AMD-SP) might add a little confusion, but is nevertheless interesting.

> TPMs are not a TEE (trusted execution environment),

I was using the phrase “trusted environment” more generally than that.

I do not mean a separate environment from the main CPU. Rather, that applications (like software DRM, or even the graphics driver) running on the CPU can’t trust the OS to enforce access controls without a secure boot environment.

How do you know that windows won’t let the user spin up a debugger and dump all your memory (or load a modified driver that lets them dump the frame buffer after content has been decrypted) for later use?

You need to trust that you are running in an environment where users haven’t just loaded whatever kernel modules or graphics drivers they want.

TPM is generally how you get a secure boot chain, so it is a prerequisite. Hence, TPM facilitates DRM.

Post reply on HN