faulTPM: Exposing AMD fTPMs' Deepest Secrets

Post by snvzz » Tue, May 02, 2023, 11:38 PM UTC

Sunspark wrote: post #230

1827163 wrote: post #215

Earlier quoted context omitted.

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

On par? Depends which year you're targeting and perhaps what applications. If you mean on par with current year then it'll be a long time before that happens because AMD and Intel are able to run power-hungry while ARM and RISC-V try to use less power.

Post by bo1024 » Wed, May 03, 2023, 12:39 AM UTC

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.

Post by astrange » Wed, May 03, 2023, 1:08 AM UTC

doubled112 wrote: post #153

mardifoufs wrote: post #150

Earlier quoted context omitted.

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?

Post by astrange » Wed, May 03, 2023, 1:13 AM UTC

salawat wrote: post #234

cryptonector wrote: post #190

Earlier quoted context omitted.

The first link said nothing about TPMs. The second link is nonsense. The third link says the NSA "teams" with the TCG, which could be concerning indeed, but there's no details there. The fourth link is light on details and full of FUD. The fifth link says roughly the same as the third, and is equally light on details. The sixth link is like the fourth but it does have some actually useful information that says you're…

>Er, well, this fails because there is no way to compress cryptographic material, and we're talking about random or pseudo-random keys being compressed (which, you can't) then encrypted. So this particular idea fails immediately. Excuse me, but wtf. That's BS. Cryptographic material is nothing but data . A Huffman encode will work on a number that happens to be a public key just as happily as it will a anything else.…

Post by riedel » Wed, May 03, 2023, 1:17 AM UTC

hnj2 wrote: post #134

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."