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

151–160 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#151

Post by codedokode »

shitter wrote: post #140
anthk wrote: post #133

Earlier quoted context omitted.

Did you try OpenBSD with bioctl? You can tamper with the bootloader, but not the rest. And you can always set the bootloader in another media and always boot from that.

Tampering with the bootloader is game over. And what, are you keeping this other bootloader medium on your person and in your sight at all times? It's never ever unattended?

Using TPM with closed source firmware, especially written and designed by Microsoft, probably full of backdoors, when you don't even know what it's doing is a worse choice.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#152

Post by seized »

nightfly wrote: post #117
roblabla wrote: post #94

Earlier quoted context omitted.

Nothing. Systemd is a suite of software that handle a lot of the low-level operations on Linux (In particular, the service manager, some network configuration, along with some other stuff). Historically, those operations were handled by different services (like SysvInit). A lot of people are mad about it for a lot of reasons, but if you're not a system administrator, it's probably better to stick with systemd, since…

I _am_ a system administrator and systemd has been an overwhelmingly net positive for me

Amen to this. I understand some of the complaints with it getting into name resolution and other things, but having had to decipher vendors init scripts it's a huge improvement for managing services.

When you add in things like Podman and it's use of systemd it's overall not a bad thing at all.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#153

Post by doubled112 »

mardifoufs wrote: post #150
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…

Which is amazing since windows 11 is full of mentions of green energy, lowering energy consumption and asking you to lower screen brightness to lower carbon emissions. Total green washing when you consider the gigantic amounts of ewaste that arbitrary cut off date will lead to. It's just funny tbh, like I get it's most likely very different teams working on those things but it's tone deaf at best. But hey at least th…

This is what most of the consumer facing eco trends feel like.

Kool-aid Jammers are my latest laugh. Plastic pouch. Plastic straw wrapper. Paper straw.

Right, the straw was the enemy here?

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#154

Post by sidewndr46 »

brookst wrote: post #115
sidewndr46 wrote: post #76

Earlier quoted context omitted.

It's called the TPM because it is trusted. The real question is, who is it that trusted that thing?

Eh, not a great bit of rhetoric. TPM = Trusted Platform Module. Trusted is an adjective modifying platform. The business case is that software should not run on untrusted platforms because hardware can always attack software. So, the promise is that TPM will allow software to guarantee* to users that the hardware is not malicious. * as much as one can guarantee anything in tech

I agree, my rhetoric on TPM is rather elementary.

From my perspective TPM is mostly about compliance with security directives. Actual security engineers would realize the TPM's security provided is about as far as you can throw it. You have no idea who designed the thing, who manufactured it, or who swapped it out while it was in shipping to you.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#155

Post by yrro »

labcomputer wrote: post #73
dathinab wrote: post #46

Earlier quoted context omitted.

no they are for boot chain security which is an essential featur for any laptop TPM by itself never prevents anyone from doing anything but it's used with features like secure boot, but as long as they fully implement the spec they don't prevent you from doing with your laptop what you want as long as you don't install software which does so secure enclave and similar used for DRM isn't directly a TPM feature but mor…

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…

There is some confusion because there _are_ DRM systems that require users to use Secure Boot with a TPM:

https://www.reddit.com/r/pcgaming/comments/phutif/riot_games...

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#156

Post by hnj2 »

dhx wrote: post #52
goolz wrote: post #16

Earlier quoted context omitted.

Does this line imply then it is mostly a concern for Windows users? I don't mind only using Linux, it is Best in Slot for most tasks anyways.

It could also be a concern for Linux users if they have configured their system to use systemd-cryptenroll (even with --tpm2-with-pin=yes or --fido2-with-client-pin=yes). The user is not asked for a secure passphrase in addition to having a TPM present. The user is just asked for a short PIN that is provided to the TPM2 or FIDO2 device and the device is not meant to return the secret without a valid PIN being provide…

There is actually an interesting point regarding TPM+PIN and systemd-cryptenroll: The data sealed in the TPM can directly be used to decrypt the disk (it is base64 encoded and used as a passphrase for a luks key slot). The PIN is only used to authenticate the TPM's unsealing of the data. In contrast, the unsealed BitLocker data still needs to be decrypted with the pin to get to the VMK.

When our attack is successfully executed on a target, this means that TPM+PIN is broken on systemd-cryptenroll, and as secure as PIN-only with the same PIN on BitLocker.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#157

Post by Tuna-Fish »

moring wrote: post #95
patrakov wrote: post #24

The most important sentences of the article: "Our attack utilizes the AMD-SP’s vulnerability to voltage fault injection attacks [14] to extract a chip-unique secret from the targeted CPU." "The attack requires access to the motherboard of the target system (4.1), particularly its SPI bus and voltage regulators." In other words, it is required to open the laptop and connect custom (but cheap) hardware to the motherboa…

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 enough current that it's undetectable when looking at the chip as whole.

Approaches such as yours do make the attack require a lot more skill to accomplish.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#158

Post by CameronNemo »

sidewndr46 wrote: post #154
brookst wrote: post #115

Earlier quoted context omitted.

Eh, not a great bit of rhetoric. TPM = Trusted Platform Module. Trusted is an adjective modifying platform. The business case is that software should not run on untrusted platforms because hardware can always attack software. So, the promise is that TPM will allow software to guarantee* to users that the hardware is not malicious. * as much as one can guarantee anything in tech

I agree, my rhetoric on TPM is rather elementary. From my perspective TPM is mostly about compliance with security directives. Actual security engineers would realize the TPM's security provided is about as far as you can throw it. You have no idea who designed the thing, who manufactured it, or who swapped it out while it was in shipping to you.

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?

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#159

Post by _georgesim_ »

wyager wrote: post #127
copper-float wrote: post #107

Earlier quoted context omitted.

Source? That would be very shocking.

Would it? Apple crippled iCloud image encryption for years at the request of federal LEAs.

Can you share a source for this please? Not finding anything useful.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#160

Post by sidewndr46 »

CameronNemo wrote: post #158
sidewndr46 wrote: post #154

Earlier quoted context omitted.

I agree, my rhetoric on TPM is rather elementary. From my perspective TPM is mostly about compliance with security directives. Actual security engineers would realize the TPM's security provided is about as far as you can throw it. You have no idea who designed the thing, who manufactured it, or who swapped it out while it was in shipping to you.

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?

I think if you went back in time, you'd find people saying that openssl was developed by a consortium of open source contributors.

It's painfully obvious nowadays that openssl was written by the NSA (or equivalent state level entity) via intermediaries deliberately adding subtle but significant vulnerabilities.

Let me propose this metaphor: you buy a front door to your house. For some reason I (the door vendor) include a complete lockset. I tell you that the lockset is totally secure. I offer you volumes of academic research and attestations that this is true. But there is no practical means by which you can establish the security of that lockset.

Do you believe that no one else can open your front door?

Post reply on HN