I think disk encryption should be widely used, but the draft plan is not quite nailed down, and some directions it could go give me pause. Particularly, storage of entire keys in TPM2, and fscrypt.
Storing an entire key(file) in the TPM is no doubt required for systems that (re)boot unattended, and is the best way I know to do that. However, if user data is protected by such a key, security depends on the TPM firmware being free of bugs and backdoors (that might deniably look like bugs). This secureboot fakery was not a TPM bug, but it does show that the space of possible problems may include, “let’s not do the cryptography and pretend we did”.
I tried to convince the UAPI group to avoid the TPM being a single point of failure by hashing a TPM-sealed secret salt with the user password on the host CPU, but I failed to communicate sufficiently well.
The problem with fscrypt (at least from what I remember of how it works on ext4) is that only file names and data are encrypted, but not file sizes or directory layouts. That makes it vulnerable to a kind of known-plaintext attack when the plaintext is a few large files or multiple files, such as an archived Youtube channel, a source code repository, a wikileaks dump, etc. If secret data ever leaves the device, an adversary can prove that the user is in possession of it.
Fscrypt is enough to protect browser session cookies, and saved passwords or credit card numbers, which satisfies Googles desires for Android. But I am dismayed to see it expanding elsewhere while that problem remains.
Honestly, I like systemd-homed. It solves the multi-user problem, LUKS prevents metadata leakage, and TRIM support keeps its volumes from consuming more disk space that the data within.
Whatever ends up implemented should be no less secure against any threat model than the status-quo with LUKS+password. That is, block-level encryption of /, but not /boot, with a key derived from a password stored nowhere else but inside the user’s brain, unless they explicitly write it down. The reason is that if some threats require changing the standard configuration in a visible way, users who face those threats will be marked as suspicious. As a particular example if something weaker replaces the status quo:
Prompting for decryption is a major driver of needing framebuffer support in the initrd.
“What do you need a custom initrd for, citizen?”
This is a bit of a problem with the status quo too, but a lot of people are using strong FDE who otherwise wouldn’t, to cover the lost laptop threat model.
Aside, on the subject of evil-maid attacks and their prevention:
An evil maid is allowed to hide cameras or microphones in the space around your computer, without tampering with it at all. This can even be done in advance before you check into the hotel. Such attacks are probably easier and more general than preparing evil initrds that imitate the correct bootsplashe for every common OS, and then guaranteeing enough time alone with victims’ computers to install them. There is no substitute for physical security.
For this reason, I don’t think schemes that provide resistance to evil-maid attacks should be chosen if they are less secure in other respects than less evil-maid-resistant schemes.