On Wed, 29 May 2019 at 12:26:12 +0100, Dominic Raferd wrote:
> Thanks but I am using the standard Debian recipe (via Ubuntu alternate
> installer which uses anaconda) for drive encryption (LUKS + dm-crypt, with
> LVM on top) and this does not give any chance (AFAIK) to specify a special
> parameter for cryptsetup.

That flag is to be passed to `open` (or `refresh`) at initramfs stage,
not `luksFormat` at d-i stage.  I suppose it doesn't change much though,
as --disable-keyring, and --token-* flags can't be specified to Debian's
crypttab(5) at the moment.

> The idea of reusing key from first crypt device when creating second crypt
> device is that once the first crypt device is decrypted in initramfs (by
> user entering password) then the second one can be decrypted using the key
> from the first.

You have a backup key slot on the device unlocked with decrypt_derived,
right?  Otherwise you'll loose both devices if the source is lost or
damaged.

As written in /usr/share/doc/cryptsetup-initramfs/README.initramfs.gz
decrypt_derived doesn't work with LUKS2 on Linux ≥4.10, because the
volume key of the source device is offloaded to the kernel keyring thus
not readable by userspace.  Since --disable-keyring can't be
persistently written into the LUKS header as of 2.1.0, nor can it be
toggled from crypttab(5), I guess that if you want to stick to
decrypt_derived your options are to use `luksFormat --type luks1` (or
`convert --type luks1`); or to write your own unlocking logic at
initramfs stage.

Alternatively, you could use decrypt_keyctl to temporarily cache the
passphrase into the kernel keyring.

    rootpv0_crypt $DEV_PV0 rootpv luks,keyscript=decrypt_keyctl
    rootpv1_crypt $DEV_PV1 rootpv luks,keyscript=decrypt_keyctl

(This also works for LUKS1 and non-LUKS devices, see our README.keyctl.)

For LUKS2 it's also possible to rely on cryptsetup's native
auto-activation support via token keyrings, see upstream's
‘docs/Keyring.txt’:

    cryptsetup token add --key-description cryptsetup:rootpv $DEV_PV1

In principle one could then use a “normal” crypttab entry and let
cryptsetup do the magic natively:

    rootpv1_crypt $DEV_PV1 none luks

But unfortunately this doesn't work well with the Debian initramfs
scripts right now (I believe the same goes for systemd), because the
password prompt is spawned first.  Entering an empty or dummy passphrase
works.  Using /dev/null as key file should work too, at the expense of
warnings regarding insecure permissions.  Once Buster is released I
guess we'll work on a better support for keyring tokens in the Debian
initramfs boot script.

-- 
Guilhem.