Bypassing disk encryption on systems with automatic TPM2 unlock – https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/
oddlama writes: '"Most TPM2 unlock setups fail to verify the LUKS identity of the decrypted partition. Since the initrd must reside in an unencrypted boot partition, an attacker can inspect it to learn how it decrypts the disk and also what type of filesystem it expects to find inside. By recreating the LUKS partition with a known key, we can confuse the initrd […]"' #tpm #linux #Encryption
=> More informations about this toot | More toots from kernellogger@fosstodon.org
@kernellogger Wow, great overview! Thanks for sharing, I learned a lot again.
On my previous installation, Fedora Silverblue 39, I experimented with automatic TPM2 unlock and had some heated discussions in my team. But that it's even worse I didn't anticipate.
At the moment I use FIDO2, and I guess a similar attack might be feasible if the attacker could get hold of my hardware token as LUKS only checks for presence. I believe my token does not support unlocking with PIN entry that I could at least use with TPM2.
=> More informations about this toot | More toots from fluchtkapsel@nerdculture.de
@kernellogger Thanks for the great article and documentation! Ironically I started fiddling with TPM-based LUKS decryption during bootup recently and I asked myself those questions (as most guides online will only suggest measuring PCR 1 and 7, e.g. when using Clevis. Which might be sufficient if the threat model is considering it secure enough).
I fear securing bootup on Linux will take years, even if the tools like systemd's features are already in place.
=> More informations about this toot | More toots from elfy@chaos.social This content has been proxied by September (ba2dc).Proxy Information
text/gemini
