homed's fscrypt should use argon2 instead of PBKDF

dkg commented 1 year ago

Component

systemd-homed

Is your feature request related to a problem? Please describe

key derivation from the user's password should be hard in order to prevent brute force attacks. PBKDF is fairly cheap, and easily parallelizable without any RAM costs.

Describe the solution you'd like

argon2 is the modern standard for password-based key derivation. it can be parameterized to be both memory-hard and CPU-hard.

new home directories created by homectl and handled by systemd-homed should be able to use argon2 instead of pbkdf. when changing passwords for a user, the new password should be stored with argon2, not pbkdf. this allows for fairly smooth migrations.

I'm not sure how the formatting of the xattr would need to be done to distinguish between pbkdf or argon2, or how the argon2 parameters would be encoded in the xattr.

Probably the right way to deploy this is to make the use of argon2 optional during homectl create, and have it default to PBKDF, while ensuring that systemd-homed can handle either of them. After a few releases where it's demonstrated to work, change the default to argon2.

Describe alternatives you've considered

There are many other possible password-based key derivation functions, but argon2 is the research community's consensus for CPU-hard and memory-hard purposes: see RFC 9106.

The LUKS implementation for systemd-homed already supports argon2, so this would bring fscrypt closer in parity to it.

The systemd version you checked that didn't have the feature you are asking for

I've looked at src/home/homework-fscrypt.c in the git main branch (currently 845824acddf2e7e08c94afe7cfee6e50a682c947), and it doesn't seem to support argon2. so i don't think version 253 supports it either.

poettering commented 1 year ago

if you care about security you probably wouldn't use fscrypt anyway, would you?

DemiMarie commented 1 year ago

if you care about security you probably wouldn't use fscrypt anyway, would you?

Android very much cares about security and does use fscrypt.

dkg commented 1 year ago

If you care about security, you might well want both full-disk encryption (e.g. a LUKS volume unlocked at boot that governs the entire block device) and then within that, a per-user fscrypt configuration.

Each type of variant provide different properties:

the system-level LUKS volume protects against extractions taken directly from the underlying storage medium
systemd-homed encrypted homedirs (using either fscrypt or an additional LUKS layer) protects against root-escalation attacks while the system is live but a given user is not logged in.
using fscrypt for homedir protection should also be able to offer automatic and efficient "safe deletion" -- where deletion of a file that uses an ephemeral key means that the contents of the file is unrecoverable from the block device even when the user's and machine's long-term secrets are revealed. block-level-device encryption like LUKS can't offer that kind of protection because it is unaware of file boundaries.

At any rate, there's no reason why someone who finds it more convenient to use fscrypt should also be obliged to use a KDF that is known to be suboptimal when we know that better mechanisms exist.

systemd / systemd