[pkg-cryptsetup-devel] Bug#917067: Bug#917067: Bug#917067: cryptsetup-bin: Opening a LUKS image which resides inside of the /home/ partition

[Guilhem Moulin]

On Sun, 23 Dec 2018 at 04:19:45 +0100, Guilhem Moulin wrote:
> If your encrypted disk image is in LUKS2 format (otherwise upgrade from
> LUKS1 possible) you can also get away without workaround if you don't
> mind re-enabling systemd-cryptsetup-generator(8).  First you need to add
> a keyring token for that device:
> 
> cryptsetup token add --key-slot 0 --key-description cryptkey-c1 /home/me/luks/some.img
> 
> (The “cryptkey-” prefix in the key description comes from
> decrypt_keyctl, but is currently undocumented.  If it ever changes you'd
> be prompted for the passphrase — something which anyway will happen if
> the key expires before all devices have been opened — but I guess we
> could just document the prefix.)
> 
> Then with a “simple” crypttab(5) entry (without keyscript)
> 
> some_img    /home/me/luks/some.img  none  luks
> 
> systemd should be able to open the device in an unattended fashion, if
> one of the devices unlocked earlier (at initramfs stage) have ‘c1’ as
> third column ‘keyscript=decrypt_keyctl’ in the crypttab(5) option column.
> Cf. https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/Keyring.txt
> for details.

Oops apologies, this is pretty much totally wrong.  I should have
spawned a test VM before sending these suggestions…

Native LUKS2 auto-activation via token keyring might come in due time in
systemd, but as of v240 there is no mention of crypt_activate_by_token().
That's not how systemd-ask-password(1) or systemd-cryptsetup(1) use the
kernel keyring currently.

AFAICT, when systemd tries to open a LUKS device, it starts by searching
in the user keyring for a key named “cryptsetup”.  If found, the content
is interpreted as a NUL-delimited list of passphrases, each one being
successfully tried against the device to open.  At this point, if the
device is still locked, the user is prompted for the passphrase until
the device opens, or until the maximum number of tries exceeds; moreover
each passphrase entered (whether it's valid or not) is appended to the
NUL-delimited list contained in the key named “cryptsetup”.

However I'm personally extremely reluctant to adopt such logic in
src:cryptsetup (for instance in cryptdisks_start(8) or in our initramfs
scripts), because 1/ splitting on NUL bytes breaks binary passphrases,
which are currently allowed through askpass' passfifo; and 2/
successively trying each passphrase previously entered is a waste of time
and resources, especially with modern PBKDFs.  (That said, on systems
where these drawbacks are acceptable, it's easy to modify or duplicate
decrypt_keyctl and change the key name to “cryptsetup”; and probably
harder to split the content on NUL bytes and try each passphrase
successfully.)

Using crypt_activate_by_token() in systemd is definitely the way forward
for LUKS2.  The two logics can even co-exist.  I'll see if I can provide
a patch, or at least file a bug.

-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20181224/3eae52c4/attachment.sig>