this post was submitted on 07 Feb 2024
738 points (97.7% liked)

Technology

59534 readers
3195 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] fmstrat@lemmy.nowsci.com 31 points 9 months ago (9 children)

Say it with me now: LUUUUUKS

[–] baseless_discourse@mander.xyz 36 points 9 months ago* (last edited 9 months ago) (4 children)

LUKS is still vulnerable to this attack if you enable autodecrypt using TPM. This attack is based on the vulnerability that the CPU and TPM communicates uses plain text. And it is a pretty common attack against TPM:

https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-inside-the-company-network

SPI is a communication protocol for embedded systems and is extremely common amongst virtually all hardware. Due to its simplicity, there is no encryption option for SPI. Any encryption must be handled by the devices themselves. At the time of this writing BitLocker does not utilize any encrypted communication features of the TPM 2.0 standard, which means any data coming out of the TPM is coming out in plaintext, including the decryption key for Windows

And apparently Linux is not doing too hot on this regard either:

https://www.secura.com/blog/tpm-sniffing-attacks-against-non-bitlocker-targets

As we can see, parameter encryption simply isn't used in practice, and except for safeboot none of the solutions enforce PIN/MFA by default.

However, this attack is not viable for device with firmware based solution, like fTPM, Microsoft Pluton, secure enclave etc. in these case TPM is part of the cpu, hence have no exposed pins to sniff their connection.


So if you don't want people with physical access to your computer (a thief or a evil maiden) to access everything on your disk, don't setup TPM auto decrypt.

[–] phoenixz@lemmy.ca 15 points 9 months ago (3 children)

CPU communicates with TPM in plaintext

Because of course

[–] Eufalconimorph@discuss.tchncs.de 7 points 9 months ago (1 children)

CPU doesn't have any secure storage, so it can't encrypt or authenticate comms to the TPM. The on-CPU fTPMs are the solution, the CPU then has the secure storage.

[–] baseless_discourse@mander.xyz 2 points 9 months ago

That make sense, CPU has no place to store private keys, since that is the functionality of TPM...

Unless there is a firmware solution, which defeats the purpose of a standalone tpm.

load more comments (1 replies)
load more comments (1 replies)
load more comments (5 replies)