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

Technology

59298 readers
4992 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 (2 children)

Say it with me now: LUUUUUKS

[–] baseless_discourse@mander.xyz 36 points 9 months ago* (last edited 9 months ago) (1 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 (2 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.

[–] HelloHotel@lemm.ee 15 points 9 months ago* (last edited 9 months ago) (2 children)

I wondered why LUUUUUKS didnt use the TPM, why do i have to put my password in... this is absolutely why.

Edit: fixed spelling of LUUUUUKS

[–] cooopsspace@infosec.pub 4 points 9 months ago* (last edited 9 months ago)

Also yes you can, I wouldn't recommend it though. Maybe in addition to your password though.

Wait until you see Dracut and Tang.

[–] mlaga97@lemmy.mlaga97.space 3 points 9 months ago (1 children)

What exactly is the point of full disk encryption if the system auto-unlocks on boot?

[–] rambling_lunatic@sh.itjust.works 1 points 9 months ago

Protection against tampering, maybe?

Bad excuse, but that is the logic I've heard.