Feature request: handle multiple encryption subkeys on different smart cards intelligently

[Naftuli Tzvi Kay]

I've also done some more hacking on trying to figure out a way to work
around the issue currently.

I've attempted to do the following:

   1. Determine the card serial number by using gpg --card-status and
   parsing with sed, grep, etc.
   2. Pair the card serial number with the encryption key known in advance
   to be used by the card. (ie: simple shell "case" statement to select
   encryption key id "DEADBEEF" for card "010101010" etc.)
   3. When decrypting, pass --default-user $decrypt_key_id! .

This way, I'm more or less forcing GnuPG to attempt using that key, which
is an encryption subkey.

This unfortunately still fails in the initramfs setting. When I run my
script from the operating system, it works as planned. In initramfs, it
doesn't work.

My next step will be to do something really janky: split my secring.gpg
into multiple secret keyrings, each containing only a single stub for the
key required, and then switch GnuPG's keyring using --secret-keyring to the
keyring which contains only the encryption key requested. This should
*hopefully* solve the problem, but I hope you can see how ridiculous this
is.

I've tested my script in a running OS with all three of my hardware smart
cards and decryption works as expected.

I'm not certain why GnuPG (1.4.18) is functioning differently in an
initramfs setting than in the normal OS, but it is. I've attached my script
to this email. The script is decidedly *not* working, but hopefully I can
hack a workaround by using different secret ring files.

Thanks,
 - Naftuli Tzvi

On Tue, Jun 9, 2015 at 12:26 PM, Naftuli Tzvi Kay <rfkrocktk at gmail.com>
wrote:

> Thank goodness! I'm glad I was on to something here, moreso glad that I'm
> not hearing "it's not a bug, it's a feature™" as is unfortunately common to
> hear these days.
>
> I've yet to try using the --try-all-secrets in --batch mode, I'm not sure
> if that will help remedy the problem. Do note that I'm using GnuPG 1, as
> it's in an initramfs setting. Would that setting help remedy the problem in
> the interrim?
>
> I don't know what my options are in initramfs for using GnuPG without
> piping the password in with the cryptsetup askpass command; I assume that
> askpass does some magic to grab keyboard input that the gpg binary itself
> probably wouldn't be able to do. If I'm able to get gpg working
> interactively instead of reading the passphrase from STDIN, I can just
> endure having to press 'c' several times until everything is right in the
> world and it finds the right decryption key in hardware.
>
> Thanks,
>  - Naftuli Tzvi
>
> On Tue, Jun 9, 2015 at 5:57 AM, NIIBE Yutaka <gniibe at fsij.org> wrote:
>
>> Hello,
>>
>> Thank you for detailed report.  It helps me a lot to understand your
>> situation.
>>
>> Let me explain current GnuPG implementation.
>>
>> Basically, current implementation processes OpenPGP packets one by
>> one.
>>
>> On 06/09/2015 07:16 AM, Naftuli Tzvi Kay wrote:
>> > The process it seems to use is like this:
>> >
>> >  1. Check if $ENC_SUBKEY_A's secret key is present: it's not.
>> >  2. Complain about the card not being present:
>> >     Please remove the current card and insert the one with serial
>> number:
>> >         XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>> >     Hit return when ready or enter 'c' to cancel
>> >  3. Hit c until it gets to the right key and prompts for the smart
>> >     card PIN. This can take a while, as I have 3 cards per identity.
>>
>> Correct.  Note that this behavior is not for smartcard only, it also
>> applies to private keys on file system.
>>
>> > What it /should/ do is this:
>> >
>> >  1. Examine the file and determine which keys can decrypt it. _If_ a
>> >     smart card is present _and_ the smart card's secret key stub in
>> >     secring.gpg can decrypt the file, immediately defer to using that
>> >     card.
>> >  2. If no card is present or the file is --hidden-recipient, try
>> >     decrypting with any present keys in the keyring whose smart card is
>> >     present.
>> >  3. If there are no present keys, the present key can't decrypt the
>> >     file, or the present key failed to decrypt the file, then start
>> >     prompting to "insert the key known as ...".
>>
>> Yes, I agree.
>>
>> From the implementation viewpoint, it will be something like:
>>
>>    (1) gpg frontend parses all packets for ESK (Encrypted Session Key)
>>        sequence.
>>
>>    (2) Then, talks to gpg-agent for available private keys to decide
>>        which private key to decrypt.
>>
>>    (3) Asks gpg-agent to decrypt.
>> --
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150702/9b29fc3a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decrypt_yubikey
Type: application/octet-stream
Size: 1866 bytes
Desc: not available
URL: </pipermail/attachments/20150702/9b29fc3a/attachment-0001.obj>