[systemd-devel] homed, LUKS2 passphrase encoding, and recovery key

Chris Murphy lists at colorremedies.com
Wed Dec 11 08:52:14 UTC 2019


I stumbled onto a LUKS2 keymapping story on the dm-crypt list [1] that
nearly ended in user data loss. The two suggestions for how to avoid
such problems is to use either ASCII or modhex based passphrases. [3]

I'm curious about whether this is something homed can help deal with:
users who want to use a single login+encryption passphrase in their
native language, keyboard mapping, and character set (likey UTF-8). Or
otherwise, enforce limits on the passphrase characters so that the
user doesn't unwittingly get stuck unable to access their data or even
login.

The implementation details don't really concern me. But I am
interested in whether there's a role for homed to play; or some other
component; and maybe even time frame for a near term policy vs down
the road enhancement.

Maybe near term just enforce ASCII or modhex (or make it
configurable)? That's very biased against non-Latin languages, which I
don't like, but I'd rather see that restriction enforced than users
getting dumped on an island where they may very well just give up and
lose data over it.

A longer term strategy is homed adds another layer of indirection
where the LUKS2 passphrase is random, modhex based. And then itself
encrypted, and protected by a KEK based on the user's passphrase where
all the things that can affect the encoding of that passphrase are
included in the identity metadata. That way if that state differs, the
user can be informed or even given a hint what aspect of the system
has changed compared to when the passphrase was originally set.

Also, somewhat unrelated, is if homed can provide a mechanism for
setting up a recovery key for LUKS2 images? I'm not fussy on whether
this would or should be something a desktop first boot program (or
create new user panel) would opt into, or opt out of. I think it'd be
sane if homed just always created one, reporting the random passphrase
by varlink to the desktop's setup/create user program, and if that
program wants to drop this information - well whatever. But the DE
could offer to save it to a USB stick, display it for manual recording
or screenshotting, or display it as a printable+scannable code. Or
perhaps a variation on this for yubikey setup is the option to setup
two keys.



[1]
the setup
https://www.saout.de/pipermail/dm-crypt/2019-December/006279.html
the cause
https://www.saout.de/pipermail/dm-crypt/2019-December/006283.html

[2]
modhex
https://www.saout.de/pipermail/dm-crypt/2019-December/006285.html
ASCII, although actually personally excludes upper case
https://www.saout.de/pipermail/dm-crypt/2019-December/006287.html


-- 
Chris Murphy


More information about the systemd-devel mailing list