[pkg-cryptsetup-devel] Bug#888916: cryptsetup: Patch that enables using OpenPGP card to unlock encrypted root

[Guilhem Moulin]

Hi Rian,

(Sorry for taking that long to come back to you.)  As I wrote back in
January(!), I think OpenPGP smartcard support would be a nice addition
to src:cryptsetup.  Another recent bug [#903163] was requesting the same
thing and made me come back to this.  We've not decided which of these
two codebases to adopt yet; I'm currently reviewing both and while IMHO
neither can be merged in as is, there are good ideas from both so I'm
sure together we can find a solution that fits all needs :-)

Here is my review (CC'ing lamby who filed #903163 — not sure if these
two should be merged or not):

cryptgnupgpcard:
 * Since the recent refactoring in 2:2.0.3-2, the ‘cryptgnupg’ hook file
   changed drastically [0].  2:2.0.3-2 wasn't released yet when you
   filed #888916, but now ‘cryptgnupgpcard’ should be modified
   accordingly :-P
 * `gpg --list-packets`'s output is not meant to be parsable.  (And
   without `--list-only` it tries to decrypt the file, which is not
   needed.)  I'm not aware of a mechanic way to find out the recipient
   of an encrypted file, so I'd suggest to use a configuration option in
   /etc/cryptsetup-initramfs/conf-hook instead.  Or just hardcode
   /etc/cryptsetup-initramfs/pubring.gpg (or even …/gnupghome/…): for
   ‘dropbear-initramfs’ the authorized_keys(5) file needs to be
   pre-generated as well, after all.
 * To avoid blowing up the size of the initramfs image with large keys,
   one can use `--export-options export-minimal` (public key material is
   the only thing that's useful, non-selfsigs aren't).

cryptroot-unlock-gnupg-pcard:
  * I don't understand the comment justifying a temporary GNUPGHOME.
    How does the unlock fail if you use the GNUPGHOME from the initramfs
    image?  Even if a temporary GNUPGHOME is indeed required, there is
    no need to list the public keys first: `gpg --homedir … --export |
    gpg --homedir … --import` exports and reimports the whole public
    keyring.
  * The socat(1) hack is not needed for SSH servers supporting Unix
    socket forwarding, and I'd rather *not* have code that depends on
    the SSH server in use.

decrypt_gnupg_pcard:
  * Running `ipconfig` each time the keyscript is run sounds overkill.
    In fact remote unlocking via a forwarded gpg-agent might be a neat
    feature, but IMHO orthogonal to OpenPGP smartcard support and I
    don't think we should do that by default.  Furthermore, messing up
    with the network configuration is more the job of a boot script that
    a key script.  But again, with a SSH server supporting Unix socket
    forwarding, there is no need to add a new IP to the loopback
    interface, so this is SSHd-dependent.
  * The script falls back to a normal prompt if `--card-status` fails.
    That behavior would be unique to that keyscript and I don't think we
    should do this by default, because it assumes that the plaintext
    passphrase contains only characters one can type in (hence no
    linefeed nor NUL).  If a fallback system is desired, IMHO the right
    way to do it is to to introduce a new crypttab(5) option,
    ‘keyscript-ignore-failure’ or something, that fallbacks to the prompt
    and tries *every* key slot (so one can have a fallback passphrase on
    another key slot).  It's a job for the cryptroot boot script though,
    not for keyscripts'.

Thanks for your contribution!
Cheers,
-- 
Guilhem.

[0] https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/master/debian/initramfs/hooks/cryptgnupg
-------------- 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/20180730/81666c0c/attachment.sig>