Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
On Fri, Jan 24, 2020 at 11:42 AM Pascal wrote: > could cryptsetup be "insensitive" to the configured keyboard layout and > adopt/toggle the US/ASCII layout ? > as the physical keys on the keyboard do not move ;-), the end user would > enter the password he wants and cryptsetup would only receive ASCII > characters... > The CLI tool cannot do that, as it only receives text and not actual keypresses. So while this would be possible in the initramfs unlocker (just delay loadkeys until after unlocking), it wouldn't be possible when creating volumes or changing passphrases via Xterm or SSH. X11 programs *might* be able to do that, but I have a feeling it'd be a bit kludgy and unreliable... And either way, it would mean a passphrase entered via X11 couldn't be used via CLI and vice versa. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
could cryptsetup be "insensitive" to the configured keyboard layout and adopt/toggle the US/ASCII layout ? as the physical keys on the keyboard do not move ;-), the end user would enter the password he wants and cryptsetup would only receive ASCII characters... let's say I use "zézé" (french keyboard) as a password : well for me, as an end user, changing context doesn't change anything, I always press the same keys [Z] and [é2~] and I always think my password is "zézé", but the password that protects my data is in fact w2w2. Le ven. 24 janv. 2020 à 05:30, Andrei Borzenkov a écrit : > 24.01.2020 06:56, Alexander E. Patrakov пишет: > >> > >> I assume users want their login passphrase to use local characters. > > > > That's just an assumption, with no data presented to back it up. > > > > I have seen enough cases when users memorized Russian passwords and > entered ASCII characters based on keyboard layout mapping (they actually > mentally entered *Cyrillic* characters). I do not have any > scientifically relevant data though. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
24.01.2020 06:56, Alexander E. Patrakov пишет: >> >> I assume users want their login passphrase to use local characters. > > That's just an assumption, with no data presented to back it up. > I have seen enough cases when users memorized Russian passwords and entered ASCII characters based on keyboard layout mapping (they actually mentally entered *Cyrillic* characters). I do not have any scientifically relevant data though. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
On Fri, Jan 24, 2020 at 2:11 AM Chris Murphy wrote: > > Thanks for the answer, it's very useful. When I asked the question, I > didn't fully appreciate the cryptographic and anti-forensic > capabilities in LUKS that almost certainly should not be > re-implemented elsewhere. > > I'd like to better understand what it would take to support UTF-8 > passphrases for LUKS (luksFormat, luksOpen). Consistently and > reliably, in a portable user home context. Of course the keyboard > could change. Locale could, thus default local language of the host > system could be different. I think there is a very important thing missing in your email: analysis what works and what doesn't work in the context of non-Linux operating systems. > That's the short version. Everything below this line is a super > verbose explanation how I'm arriving at the above. > > I assume users want their login passphrase to use local characters. That's just an assumption, with no data presented to back it up. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
Thanks for the answer, it's very useful. When I asked the question, I didn't fully appreciate the cryptographic and anti-forensic capabilities in LUKS that almost certainly should not be re-implemented elsewhere. I'd like to better understand what it would take to support UTF-8 passphrases for LUKS (luksFormat, luksOpen). Consistently and reliably, in a portable user home context. Of course the keyboard could change. Locale could, thus default local language of the host system could be different. That's the short version. Everything below this line is a super verbose explanation how I'm arriving at the above. I assume users want their login passphrase to use local characters. Germans should of course be allowed to create a login passphrase using characters with umlaut; Japanese should of course be allowed to create passphrases using kanji. And so on. I further assume that this same login passphrase is what should be used for `cryptsetup luksFormat/luksOpen' in order to *avoid* more indirection, and being forced to invent new crypto, which entails a lot of work and risk: security and interoperability. Many users are conditioned to accept a restriction to the 95 printable of the first 128 ASCII characters for a LUKS passphrase. That's because the typical workflow demands volume unlocking in an environment with a limited input stack (initramfs and plymouth). But I assume a global user isn't prepared for, and shouldn't have to accept, such a limitation for their login password. And in a systemd-homed context, that means the login password, if it's what's handed off to cryptsetup, are the same and also cannot be limited to ASCII. So the question comes full circle. What are all of the things that can affect the encoding between the user's passphrase as it exists in their mind, and as handed off to cryptsetup? How to store that metadata? That way it can be tested against, and provide the user with helpful hints about why authentication isn't succeeding. Right now it's a one size fits all. There's no difference in the error between wrong passphrase (this user is not authentic) and encoding failure due to keyboard change, or keymapping change, or whatever else can affect encoding. Small problem? :D -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] homed, LUKS2 passphrase encoding, and recovery key
On Mi, 11.12.19 01:52, Chris Murphy (li...@colorremedies.com) 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] homed, LUKS2 passphrase encoding, and recovery key
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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
