Multiple encryption subkeys on hardware smart cards

Question

I've created a PGP key set which consists of the following:

• A master RSA key with only signing capabilities, stored offline.
  • Multiple OpenPGP cards, each with three RSA keys:
    1. An encryption key
    2. A signing key
    3. An authentication key for SSH

My reasoning behind making it this way is so that if a single hardware card gets stolen, I can revoke all of its certificates in a way that doesn't "damage" my remaining infrastructure. (Except, of course, that I now need to re-encrypt my encrypted data to exclude this key and that I need to recreate long-lasting signatures with a different signature subkey, but these things don't damage my identity: they're just really inconvenient.)

Granted, multiple encryption keys is not the best idea, but I'm particularly concerned with encrypting and decrypting backup files and not emails as much. I'm not sure if there's a way for an emailing user to have their emails encrypted to all three of my encryption keys at once, but it's not the end of the world (though really inconvenient) if it's only encrypted to one encryption key.

The problem I'm currently facing involves trying to setup a LUKS boot with a GPG encrypted keyfile. My current setup works, but it only allows decryption with one of the cards. My public and secret keyrings look fine, the secret keyring contains stubs for all of the smart cards. If I try decrypting with another one of the cards, it chokes and fails, prompting me to insert the "right" card.

My key file is encrypted like this:

gpg --output /keyfile.gpg --encrypt --recipient $MASTER_KEY_ID \
    --encrypt-to $ENC_SUBKEY_1! --encrypt-to $ENC_SUBKEY_2! \
    --encrypt-to $ENC_SUBKEY_3!

Note how I'm using ! to force it to encrypt for these subkeys specifically. On boot with cryptsetup, I see the following message if I have a different card inserted:

gpg: error reading application data
gpg: decryption failed: secret key not available
cryptsetup: cryptsetup failed, bad password or options?

If I use the card containing $ENC_SUBKEY_1, decryption works and the OS boots.

My key script is fairly close to the one provided by cryptsetup:

if ! /lib/cryptsetup/askpass "Enter passphrase for key $1: " \
    /usr/bin/gpg -q --batch --no-random-seed-file --homedir /lib/cryptsetup/gpg \
        --ignore-valid-from --ignore-time-conflict --passphrase-fd 0 --decrypt $1; then
    return 1
fi

return 0

If I do the same kind of encryption on a file in my running operating system, I'll get an interesting output when I try decrypting with a key other than the first one passed as --encrypt-to:

Please remove the current card and insert the one with serial number:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Hit return when ready or enter 'c' to cancel

If I hit c up to twice, it'll eventually "find" the right key and decrypt the file. Presumably because it's in --batch mode on boot, it won't prompt and will instead just fail.

Is there a way to bypass this problem? Is there a way I can tell GPG to just keep trying until nothing at all works? ie: key for card 1 can decrypt; card 1 not present; key for card 2 can decrypt; card not present; key for card 3 can decrypt; card present; decrypt.

Answer 1

The problem is, that "stub" keys for all of the three cards are stored in your computer, and GnuPG is trying all of them.

Sadly, I'm not aware of an option to define a fixed decryption subkey, skimming through GnuPG's man page also did not reveal any.

As far as I see, the only option you have would be to remove all but the currently used encryption subkey from the keychain, and switching keychains if necessary. Be aware that before GnuPG 2.1, merging subkeys is a pain, so be sure to keep a keyring around containing all subkeys.

Answer 2

The canonical way seems to be to have one and only active encryption key. Quoting the manual:

Finally, it only makes sense to have one valid encryption subkey on a keyring. There is no additional security gained by having two or more active subkeys. There may of course be any number of expired keys on a keyring so that documents encrypted in the past may still be decrypted, but only one subkey needs to be active at any given time.

There's also a command to disable currently unused keys.

Otherwise put, the right course of action is to disable and/or archive all other keys, possibly keeping the only one encryption key on all cards.