Re: homed, LUKS2 passphrase encoding, and recovery key

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 11.12.19 01:52, Chris Murphy (lists@xxxxxxxxxxxxxxxxx) wrote:

> 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.

I have the suspicion that this is something the UI should primarily
care for, i.e. when you enter weird chars in the input box for your
hdd password it should popup a small warning saying what the issue is.

>
> 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.

homed systematically cares for multiple authentication mechanisms in
place in parallel, and that includes multiple passphrases.

I think what you are asking for is mostly a UI thing, i.e. when
prompting for a passphrase to encrypt a HDD with GNOME should always
setup a recovery pw for the user too, which it should auto-generate,
and maybe display as QR code on screen in parallel to the pw the user
types in.

I am not sure we need much explicit support in the lower layers for
this, neither in luks nor in homed, as such a recovery password is in
effect the very same thing as the primary one, it just differs in how
its generated and displayed. After its set once we cannot recover it
anyway for display hence after its set there's no point in
distuingishing it from the primary, user supplied pw.

Recovery pws are particularly useful when yubikeys are used i guess,
since people might lose yubikeys, and need a way back in.

Hence, if I were a GNOME designer, then I'd design the UI for setting
a user pw like this:


   [ Enter your user password here ]
   [ Repeat it here ]

   > Register a Yubikey here <

   Oh, btw, we are setting this recovery password up for you, write it
   down or scan it off:

   SOME WEIRD HEX CHARS THAT ARE EASY TO READ AND WRITE DOWN   +----+
                                                               | Q  |
                                                               |  R |
                                                               +----+


(And the QR code would contain the very same info as the weird hex
chars. But of course the QR code only makes sense if there's a
somewhat reasonable workflow for picking it up with typical android
phones and storing it safely.)

And to homed the UI above would just pass two equivalent passwords:
the primary one the user entered and the generated recovery one. On
the lower levels they'd be entirely equivalent.

At login it would hence be fine to use either of the three
credentials: the primary pw, the recovery pw or the yubikey.

How precisely gnome generates the recovery pw is ultimately up to
gnome. It can use libpwquality which has some algorithms for that
which generates long, weildy passwords matching the required entropy
and even defines somewhat sensible defaults so that GNOME doesn't have
to care much.

Lennart

--
Lennart Poettering, Berlin
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel