3 ms·

It doesn't need to be the NSA; if your chip is vulnerable and exploits published online I don't think it's too far fetched that a resourceful thief could try to

It doesn't need to be the NSA; if your chip is vulnerable and exploits published online I don't think it's too far fetched that a resourceful thief could try to unlock your disk if he thinks it has valuable content (bank accounts, cryptocurrency, passwords, etc.) Why take unnecessary risks when you can just use GRUB+LUKS and type the passphrase at boot?

Nextgrid 3y ago
GRUB+LUKS can also have exploits published online? If that happens, you upgrade to a newer version. TPM is the same - any known vulnerabilities would generally get patched as part of firmware updates released by your vendor. If the TPM is known vulnerable and a patch doesn't exist then fair enough you can stop using it depending on your threat model, but the same can be said for software implementations. > when you can just use GRUB+LUKS and type the passphrase at boot? This is a user experience drawback and opens you to other avenues of attack like passphrase bruteforce if you don't choose a strong (and inconvenient/slow to type) one. It's also impossible for servers or embedded devices which you want to be able to boot unattended.
- rnhmjoj 3y ago
  > TPM is the same It's not really: LUKS is an open standard and GRUB is a free software that implements it. With a TPM you're likely to get a chip that is 100% a black box, with the exception of a few people who signed NDAs and researches that have knowledge and tools to poke into it. > generally get patched as part of firmware updates released by your vendor If it can even be fixed with a softwar update. Also, you're very lucky to get maybe a couple of years of firmware updates, then your're on your own.
  - Nextgrid 3y ago
    > with the exception of a few people who signed NDAs and researches that have knowledge and tools to poke into it. This is good enough for the 90% of people who currently operate without full-disk-encryption at all. It would be a huge improvement. Obviously, it's up to each individual user to evaluate their threat model and proceed accordingly. Nobody is forcing you to use a TPM, you can still use LUKS/etc and completely ignore the TPM.
- chlorion 3y ago
  That's not really true all of the time, some AMD fTPMs have physical vulnerabilities for example, that allow compromising the entire thing with some tools and a few hours of time. Software can't fix this since it's a flaw in the hardware itself, you'd need to buy new hardware to fix this. https://arxiv.org/abs/2304.14717 https://arxiv.org/abs/2304.14717
  - Nextgrid 3y ago
    Thanks, very interesting. Is there a distilled version of this or an announcement with a list of vulnerable chips?
    - chlorion 3y ago
      I don't seem to have bookmarked anything except for the link I posted earlier and the HN thread that discussed this (posted below). From my memory it was every zen module up to and including zen3. It's possible that zen4 has been fixed but I'm not certain about that. There is a "requirements" section of the PDF that talks a little bit more about which CPUs were effected but that isn't distilled! https://news.ycombinator.com/item?id=35787195 https://news.ycombinator.com/item?id=35787195

Nextgrid 3y ago

GRUB+LUKS can also have exploits published online? If that happens, you upgrade to a newer version. TPM is the same - any known vulnerabilities would generally get patched as part of firmware updates released by your vendor. If the TPM is known vulnerable and a patch doesn't exist then fair enough you can stop using it depending on your threat model, but the same can be said for software implementations. > when you can just use GRUB+LUKS and type the passphrase at boot? This is a user experience drawback and opens you to other avenues of attack like passphrase bruteforce if you don't choose a strong (and inconvenient/slow to type) one. It's also impossible for servers or embedded devices which you want to be able to boot unattended.

rnhmjoj 3y ago
> TPM is the same It's not really: LUKS is an open standard and GRUB is a free software that implements it. With a TPM you're likely to get a chip that is 100% a black box, with the exception of a few people who signed NDAs and researches that have knowledge and tools to poke into it. > generally get patched as part of firmware updates released by your vendor If it can even be fixed with a softwar update. Also, you're very lucky to get maybe a couple of years of firmware updates, then your're on your own.
- Nextgrid 3y ago
  > with the exception of a few people who signed NDAs and researches that have knowledge and tools to poke into it. This is good enough for the 90% of people who currently operate without full-disk-encryption at all. It would be a huge improvement. Obviously, it's up to each individual user to evaluate their threat model and proceed accordingly. Nobody is forcing you to use a TPM, you can still use LUKS/etc and completely ignore the TPM.
chlorion 3y ago
That's not really true all of the time, some AMD fTPMs have physical vulnerabilities for example, that allow compromising the entire thing with some tools and a few hours of time. Software can't fix this since it's a flaw in the hardware itself, you'd need to buy new hardware to fix this. https://arxiv.org/abs/2304.14717 https://arxiv.org/abs/2304.14717
- Nextgrid 3y ago
  Thanks, very interesting. Is there a distilled version of this or an announcement with a list of vulnerable chips?
  - chlorion 3y ago
    I don't seem to have bookmarked anything except for the link I posted earlier and the HN thread that discussed this (posted below). From my memory it was every zen module up to and including zen3. It's possible that zen4 has been fixed but I'm not certain about that. There is a "requirements" section of the PDF that talks a little bit more about which CPUs were effected but that isn't distilled! https://news.ycombinator.com/item?id=35787195 https://news.ycombinator.com/item?id=35787195