Hacker News Reader

Comment by goolz | Hacker News Reader

Does this line imply then it is mostly a concern for Windows users? I don't mind only using Linux, it is Best in Slot for most tasks anyways.

View on HN

It could also be a concern for Linux users if they have configured their system to use systemd-cryptenroll (even with --tpm2-with-pin=yes or --fido2-with-client-pin=yes). The user is not asked for a secure passphrase in addition to having a TPM present. The user is just asked for a short PIN that is provided to the TPM2 or FIDO2 device and the device is not meant to return the secret without a valid PIN being provided.

There is actually an interesting point regarding TPM+PIN and systemd-cryptenroll: The data sealed in the TPM can directly be used to decrypt the disk (it is base64 encoded and used as a passphrase for a luks key slot). The PIN is only used to authenticate the TPM's unsealing of the data. In contrast, the unsealed BitLocker data still needs to be decrypted with the pin to get to the VMK.

When our attack is successfully executed on a target, this means that TPM+PIN is broken on systemd-cryptenroll, and as secure as PIN-only with the same PIN on BitLocker.

ChromeOS also heavily relies on TPM for disk encryption, and unlike Windows doesn't even give you the option of adding a passphrase or pin on top of it.

And there's probably some large enterprises that use regular Linux desktops with LUKS/Btrfs/ZFS encryption in TPM only mode, to match their Windows setups. Systemd e.g. added systemd-cryptenroll with ergonomics comparable to Windows' Bitlocker enrollment.

if Linux full disk encryption would have a more user friendly UX a lot of Linux users would probably use that too

its a very convenient feature

through is not convenient to setup

and a lot of Linux users never trusted it to be secure, i. e. a lot of people expected an attack like this sooner or later

The current state of userfriendly is quite good. In Ubuntu it's just a checkbox in the installer and input a passphrase.

yes and it does use the TPM and is affected by this attack ;=)

at least the recent ubuntu versions when using the default full disk encryption setup do setup decryption using TPM you still need an additional password as without you would e.g. lose access to your data if you change some hardware, you motherboard brakes or depending on how they set it up you also need the password after kernel upgrades etc.

but the vulnerability allow someone with hardware access to access all your data by booting their code but messing with the TPM in a way where it still measures as if it's was booting your code

The passphrase is what makes it a poor user experience. Many people simply need an encrypted disk that you can't boot offline and not the boot-time PIN/passphrase (which Microsoft abandoned as the default in Windows 8, I believe, again due to UX).

Typical Linux installation will not rely on TPM in any way. But if you use systemd-cryptenroll to provide BitLocker-like UX for FDE then the concerns are mostly same.

Reply on news.ycombinator.com