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

131–140 of 273 posts

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#131

Post by dathinab »

als0 wrote: post #112
dathinab wrote: post #65

Earlier quoted context omitted.

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 su…

> I suspect there isn't sufficient demand or skill for such a project.

IMHO more like: There is little to no profit in this, nor much motivations for AMD/Intel to provide this. But it does involve additional work, especially if the fTPM implementation they use currently does (partially) use code they got from other companies which they can't open source.

Through you wouldn't need a FPGA, for a TPM to really be secure you want it to be integrated into the CPU. And most times this means it's not a "special" physical chip but just a "standard co-processor" running some software. E.g. in case of ARM Android smart phones it's likely a more or less normal Cortex M0 processor (and it likely runs more then "just" a TPM, e.g. some DRM pipe protection code).

So theoretically you would just need to publish the "bar metal" code and anyone could analyze it and then build and run it e.g. using qemu (if qemu can handle co-processors idk.). And by also allowing to extract the build code from the CPU combined with reproducible builds you could also verify it runs what it says it runs (kinda, I mean who says there isn't a hardware backdoor rewriting the code, and it being a FPGA doesn't help there because the FPGA hardware could also rewrite the FPGA bin-code.... at least theoretically)

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#132

Post by shitter »

anthk wrote: post #81

And now I remember people telling me Windows is more secure than Unix because of TPM, foo... bar... No, thanks, bioctl(4) works well under OpenBSD for disk encryption and so will do under HyperbolaBSD.

Windows, Linux, OpenBSD - it doesn't matter. Without a TPM you're vulnerable to trivial attacks (Evil Maid), far easier than the one in this article.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#133

Post by anthk »

shitter wrote: post #132
anthk wrote: post #81

And now I remember people telling me Windows is more secure than Unix because of TPM, foo... bar... No, thanks, bioctl(4) works well under OpenBSD for disk encryption and so will do under HyperbolaBSD.

Windows, Linux, OpenBSD - it doesn't matter. Without a TPM you're vulnerable to trivial attacks (Evil Maid), far easier than the one in this article.

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.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#134

Post by hnj2 »

riedel wrote: post #129

Stupid question: was there no responsible disclosure and is there no cve assigned? Seems like a rather practical attack (or am I missing something? Do the researchers consider it a known fact that that fTPM is broken by design and thus do think that nobody will get hurt? It would make sense to require an additional passphrase on fTPM devices for bitlocker. Was there a statement from Microsoft or AMD?

From the paper: "All security-relevant findings discussed in this paper were responsibly disclosed to AMD, Microsoft, and the systemd-cryptenroll maintainers. The systemd-cryptenroll maintainers quickly got back to us to discuss specific mitigation strategies."

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#135

Post by kfreds »

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…

You're spot on.

TKey is based on ideas like TPM and DICE. Think of TKey as a TPM-in-time, and a discrete TPM on an x86 mainboard as a TPM-in-space. Both go through the load-hash-measure-trust/execute steps, but TKey only needs one hardware domain to accomplish this whereas a discrete TPM needs two.

Measurements and their results need to be computed in a context that can't be subverted by the object that is being measured. In the discrete-TPM case the host loads and hashes the object and then sends it to the TPM before letting the object influence the host's control flow.

The only difference in the TKey case is that instead of sending the hash to a TPM the TKey derives key material based on Hash(sk, Hash(object)) and then removes sk from RAM. This is roughly equivalent to TPM sealing.

The TKey equivalent of TPM quoting/attestation would involve a signing step using sk, and leaving the resulting certificate in RAM before letting the object influence control flow. A downside to this approach is that each measurement creates another level in a PKI-like structure. If you do the same thing with a discrete TPM you can do multiple measurements and still only have one signature attesting all of them.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#136

Post by anthk »

einpoklum wrote: post #83
neilv wrote: post #70

Earlier quoted context omitted.

Debian Stable welcomes refugees: https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/ (Or, for laptops with closed WiFi and no Ethernet, use this installer: https://cdimage.debian.org/cdimage/unofficial/non-free/cd-in... )

[flagged]

Better GNUinos or Trisquel, no propietary bits included.

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#137

Post by BlueTemplar »

daveoc64 wrote: post #111
Aleklart wrote: post #105

Earlier quoted context omitted.

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!

Windows 7 is only starting to get obsoleted now : while Microsoft is still updating it with critical security fixes, Qt and Chromium dropping it is pretty much the end for non-legacy usage. (Good bye Windows I guess...)

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#138

Post by coppsilgold »

Laaas wrote: post #74
netheril96 wrote: post #26

Earlier quoted context omitted.

> Physical access will always be king No. Your wording suggests that once attackers gain physical access, all is lost. It is not true. With a passphrase based full disk encryption, if the passphrase is strong and the machine is powered off, physical access doesn't imply data access.

Attach a microphone to the device while they are not looking, decode the keys they are pressing from the sounds, figure out what keys are the password, done. This is _trivial_ for any mildly sophisticated attacker.

You don't even need to attach it, other placements are sufficient as well. An example of how an attack can be performed: https://github.com/shoyo/acoustic-keylogger>

Room bugged = keyboard keylogged

Re: faulTPM: Exposing AMD fTPMs' Deepest Secrets

#140

Post by shitter »

anthk wrote: post #133
shitter wrote: post #132

Earlier quoted context omitted.

Windows, Linux, OpenBSD - it doesn't matter. Without a TPM you're vulnerable to trivial attacks (Evil Maid), far easier than the one in this article.

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?
Post reply on HN