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

111–120 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#111

Post by daveoc64 »

Aleklart wrote: post #105
daveoc64 wrote: post #88

Earlier quoted context omitted.

Windows 10 was released in 2015, so they will have offered 10 years of support, which was the standard policy in place ever since Windows Vista (Windows Vista, 7, 8/8.1, 10). Apple does not support any macOS version for that long, and is unlikely to support a current version of macOS on any given device for that long.

You say “support” like the moment they stop it, OS cease to work. OSX Leopard is usable for most of tasks. Lot of people still running Windows 7 and Windows XP without any need for “support”. Windows 10 will be even better without constant “support” reboots. Can’t say this for Windows 11, as it so tightly stuffed with spyware and online integrations, it might just not boot if MS plug some server switch.

I would not want to run an unsupported OS of any variety.

Modern web browsers will stop working on older operating systems - so will other apps.

Not only is it a massive security risk, but it will simply become impractical for most users.

Besides, if you're afraid of the TPM vulnerability described in this article, you ought to be more worried about running an out of date OS!

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#112

Post by als0 »

dathinab wrote: post #65
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?

Mine and I want a TPM, it's a device essential for modern laptop security. _Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_ through potential a different implementation and not some of the features build on top of it like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the…

TPM is more or less an API specification. The specification is fine but people are worried about implementation backdoors and pre-provisioned keys. It should be possible to have an open source public trustable implementation that anyone can synthesise onto an FPGA or a real chip design. This ought to avoid fears about backdoors, while keeping a mature security model and good software support. I suspect there isn't sufficient demand or skill for such a project.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#113

Post by PrimeMcFly »

galangalalgol wrote: post #85
PrimeMcFly wrote: post #64

Earlier quoted context omitted.

There have been several, but what makes Windows Windows is the ecosystem, and no distro can replicate that.

What is that ecosystem now? What do households with windows use that isn't on the cloud?

A lot of stuff is moving to web/cloud stuff, but we are not there entirely.

As one example, I had to take a proctored exam recently, and the only supported OS was Windows or MacOS. Linux was not an option.

Then there is games, Proton is great but plenty of AAA titles are still not compatible.

Just for starters.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#114

Post by cwerling »

als0 wrote: post #108

It's worth mentioning that standalone TPM chips from Infineon and others are a lot more hardened than Intel or AMD's fTPMs. Infineon's TPMs are tested against fault injection attack, package removal, side channels and so on.

Please note, though, that's imperative to then go for a BitLocker TPM+PIN configuration at least. A standalone (discrete) TPM with TPM-only protectors can be attacked by bus sniffing, a hardware attack much simpler than ours. [1]

The beauty of a discrete TPM is its anti-hammering protection, making a numerical PIN a very effective security measure (akin to a SIM/SmartCard).

[1] https://www.sciencedirect.com/science/article/pii/S089812211...

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#115

Post by brookst »

sidewndr46 wrote: post #76
jhoelzel wrote: post #5

Honestly TPM is probably creating more bad than good at this point. Every time I think about the millions of computers that will be declared worthless this year, it makes me a little bit more angrier.

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

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#116

Post by Sunspark »

labcomputer wrote: post #79
Mindwipe wrote: post #69

Earlier quoted context omitted.

There aren't really any mainstream DRM systems that use a general computing platform TPM, precisely because they have a terrible track record of being breached.

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.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#117

Post by nightfly »

roblabla wrote: post #94
whynotmaybe wrote: post #86

Earlier quoted context omitted.

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 ?

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

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#118

Post by MrStonedOne »

dathinab wrote: post #65
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?

Mine and I want a TPM, it's a device essential for modern laptop security. _Even if you would be able to control every bit of firmware on your computer and there was no DRM or similar you still would want a TPM!_ through potential a different implementation and not some of the features build on top of it like something like a TKey integrated into your CPU with some additions for securing the boot chain (including the…

Any security model that can not differentiate the device owner from a threat actor misses the point of who security is meant to protect.

TPM and secure boot combined can create computers that run key-per-cpu encrypted system binaries that can not be modified by the device owner meaning next time microsoft does something fucky there will be no path out, no programs to disable it, its just how you have to live now.

Its not worth it to head down that path.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#119

Post by brookst »

Aleklart wrote: post #105
daveoc64 wrote: post #88

Earlier quoted context omitted.

Windows 10 was released in 2015, so they will have offered 10 years of support, which was the standard policy in place ever since Windows Vista (Windows Vista, 7, 8/8.1, 10). Apple does not support any macOS version for that long, and is unlikely to support a current version of macOS on any given device for that long.

You say “support” like the moment they stop it, OS cease to work. OSX Leopard is usable for most of tasks. Lot of people still running Windows 7 and Windows XP without any need for “support”. Windows 10 will be even better without constant “support” reboots. Can’t say this for Windows 11, as it so tightly stuffed with spyware and online integrations, it might just not boot if MS plug some server switch.

"Support" can mean a lot of things.

Apple does not provide security updates for Catalina, which was released 3.5 years ago. People would be crazy to run unpatched OSes for any use case involving the internet or wifi.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#120

Post by dathinab »

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…

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 pushed for moving (parts of) the DRM into the firmware (i.e. in a context where TPM doesn't matter much), which is where vendor-locked secure enclaves and similar come in which are related to TPM2.0 but not the same. For example on some ARM/Android chips part of the DRM system is in a locked secure co-processor.

And just because something can be abused doesn't mean it isn't useful or it's fundamentally bad. Through you seem to be making exactly that argument now with a "but it was designed with bad things in mind" added, which is a IMHO pointless argument. What matters is what it _is now_, not why it ended up there.

And what it is now is an _essential_ security feature for laptops, which also can be abused iff used in combination with some other features and that other features are tweaked to harm the user (e.g. don't allow custom keys for secure boot).

Post reply on HN