[pkg-cryptsetup-devel] Bug#903163: Adding OpenPGP smartcard support to LUKS

[Guilhem Moulin]

On Wed, 07 Nov 2018 at 13:05:17 -0800, Kyle Rankin wrote:
> I've tested these debs and can confirm everything works.

Awesome, thanks for the feedback!

> I was also able to add this support to an existing LUKS root partition
> by just using luksAddKey and making sure the crypttab was updated and
> update-initramfs was run.

Yup, that's also what I tested, and I should add to the documentation
(not specific to that keyscript) that one might want to add ‘key-slot=1’
to the crypttab(5) entry.  Indeed the first (and only) passphrase after
`luksFormat` “occupies” the 0th keyslot, and after `luksAddKey` the new
passphrase “occupies” the first keyslot available.  If one doesn't add
‘--keyslot=$INDEX’ when unlocking, then all key slots are tried one
after the other until the passphrase manages to open one; in practice
the extra KDF runs needlessly delay the boot by a few seconds.

> Note that in the case of a root partition, boot splash needs to be
> disabled so you can enter the GPG PIN.

That's because of the pinentry prompt.  Compared to askpass it also
breaks unlocking via passfifo (hence remotely via SSH, although it's not
really the use-case in this context) — which is something I should
document, but I believe it's much more important to print the number of
remaining attempts on failure, given that too many failures will freeze
the card.  (It should be feasible to retrieve the “PIN retry counter”
values from the `gpg --card-status` output and add it to the askpass
prompt, but that adds complexity and clunkiness IMHO.)

Furthermore, as Peter pointed out earlier, another advantage of using
pinentry is that if needed the user is asked to insert the smartcard
identified with its Serial Number (taken from the private key stubs).
However that doesn't happen currently because I'm really worried about
copying real private key material to the initramfs along with the stubs;
GnuPG upstream was asked about a documented API to retrieve the stubs
but hasn't answered yet AFAIK.  I'm not sure if the implementation
currently found in our branch would choke if the wrong smartcard is
inserted: I wasn't able to test this as I have only one token :-)

-- 
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/20181108/013ac688/attachment.sig>