[pkg-cryptsetup-devel] Bug#903163: Bug#903163: ITP: gpg-encrypted-root -- Encrypt root volumes with an OpenPGP smartcard

[Guilhem Moulin]

Hi Peter,

On Wed, 01 Aug 2018 at 17:51:43 +0200, Peter Lebbing wrote:
> On Mon, 30 Jul 2018 04:16:23 +0800 Guilhem Moulin <guilhem at debian.org> wrote:
>> * Copying not only the (encrypted) key file and the public keyring,
>> but also the private-keys-v1.d directory, sounds very odd to me.
>> What is the rationale for doing so?
> 
> First, a new GnuPG --homedir /etc/keys is created, and in that homedir,
> the smartcard stubs for the OpenPGP card are created (per README.md[1]).
> This separate GnuPG homedir, specifically meant just for the unlocking
> of the LUKS container, is then copied to the initramfs. If this were not
> done, you'd have to do "gpg --card-status" in your initramfs to create
> these stubs everytime you boot, before decryption. It'd get awkward if
> you forgot to insert your smartcard, because adding --card-status makes
> it a two-step process: first --card-status, second --decrypt. Right now,
> if you forgot to insert your smartcard, the --decrypt would fail and be
> retried. The failure would prompt you to insert your smartcard.
> 
> It's not copying your normal GnuPG private-keys-v1.d to initramfs,
> that'd be not so clever. Still, in the interest of clarity, it warns the
> user that if they dumped sensitive information in /etc/keys, they might
> want to reconsider.

I see, thanks for the explanation.  Still, I'm not fond of this because
it ties the code to gpg(1) implementation details, and if for some
reason someone uses that homedir to add generate an (on-disk) key, it'll
end up in the initramfs without apparent change on `update-initramfs -u`…

It's possible to copy only the stubs an not the real key material, but
the complexity is not worth it IMHO.  We already have some logic in
place to wait until the source device is present, so we can as well wait
until the card is present.  I pushed a branch to the Debian repo with a
shell loop; it might be cleaner to do it with gpg-connect-agent(1) (and
replace `gpg --card-status` with `gpg-connect-agent LEARN /bye`), but
I've not been able to that. (AFAICT its status code is always 0, and it
has way to echo text to a file descriptor other than stdout.)

>> decrypt_gnupg_sc:
>> * How common are the cards requiring pcscd(8) that don't work with the
>> existing ‘decrypt_opensc’ keyscript but do work with the
>> ‘decrypt_gnupg_sc’ keyscript?
> 
> It's more tied to the reader rather than the card. My own smartcard
> reader works great with the internal CCID driver of GnuPG, and my
> version of this script does not have pcscd. Erik Nellessen apparently
> has a smartcard reader that is not supported by GnuPG, but the card in
> it is still an OpenPGP smartcard, AFAIK. I'm glad I have a
> GnuPG-supported reader myself, it makes it all a lot smoother.

OK.  decrypt_* isn't the right place to start pcscd though, because we
want these scripts to work not only at initramfs stage, but also in the
main system.  I left it out for now, but I'll later adapt cryptopensc's
local-{top,bottom} scripts to ensure pcscd is started at early boot
stage.

By the way, I also added a local-bottom script to kill gpg-agent and
scdaemon before execution is turned over to the init binary :-)

Cheers,
-- 
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/20180923/0b0ec933/attachment.sig>