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

[Naftuli Tzvi Kay]

Here's a little background on what I'm experiencing:
https://security.stackexchange.com/questions/91054/multiple-encryption-subkeys-on-hardware-smart-cards/91068

Basically, I have two PGP identities: mine and my wife's. For each
identity, we have multiple hardware smart cards storing 3 RSA certificates:
one for encryption, one for signing, and one for authentication.

It kind of looks like this:


   - Identitiy: me (master key, RSA signing key only)
      - Card: 1001
         - Encryption Subkey A
         - Signing Subkey B
         - Authentication Subkey C
      - Card: 1002:
         - Encryption Subkey D
         - Signing Subkey E
         - Authentication Subkey F
      - Identity: wife (master key, RSA signing key only)
      - Card: 1003:
         - Encryption Subkey G
         - Signing Subkey H
         - Authentication Subkey I
      - Card: 1004:
      - Encryption Subkey J
         - Signing Subkey K
         - Authentication Subkey L


Both my wife and I should have access to a given file X, therefore I
encrypt it like this:

    gpg --encrypt --recipient me --encyrpt-to $ENC_SUBKEY_A! --encrypt-to
$ENC_SUBKEY_D! \
        --recipient wife --encrypt-to $ENC_SUBKEY_G! --encrypt-to
$ENC_SUBKEY_J!

This encrypts the file for myself and for my wife, and forces it to encrypt
it for all of our subkeys.

Decrypting this file, however, proves to be problematic. Since each
identity has multiple encryption subkeys and all encryption subkeys live on
smart cards, GPG seems to get confused by things and dosen't seem to
execute certain commands in the right order.

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.


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 ...".


An explanation of my setup and why I did what I did is in order. I and my
wife will be primarily using a single smart card each to access our data
and boot our computers. Our encrypted key files will be encrypted for both
of our identities and all of our smart cards. The reason for this is
redundancy: if I lose access to my primary smart card, I'll be able to grab
my backup smart card, revoke the keys of the first smart card, and decrypt
the encrypted key file using the second smart card. As my wife will also
need to boot the computer, she can use her primary smart card to decrypt
the key file, falling back to her other one if the first one is
compromised. My disk is encrypted using LUKS and a key file encrypted by
GPG.

This setup, though possibly confusing, gives me the best flexibility in
terms of key compromise, as I can grab the backup hardware key and keep
going. I can immediately issue a revocation for the keys on the first smart
card, and begin reencyrpting all of my valuable data to exclude the
compromised key. By keeping a reasonable amount of keys per identity and
storing them in secure locations, I get all the benefits of strong
encryption that GnuPG provides, the ability to recover in case of
compromise, and the security of knowing my private keys only exist in
hardware.

Please see my inquiry on security.stackexchange and evaluate my setup and
LUKS decrypt script, and you'll hopefully see what's going wrong and what
could be improved in this regard.

As far as I know, I can still accomplish what I want to by hacking my LUKS
decryption script, but the process could be streamlined tremendously to one
step for the user rather than up to 6 steps in my case (ie: hit c 5 times,
then finally enter the PIN). In --batch mode, it just fails outright, which
really shouldn't happen: it should see if it can decrypt with *any* present
secret key (hardware or otherwise) and only then it should fail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150608/dbad5619/attachment.html>