Proposal for multiple keys on an OpenPGP smart card
Achim Pietig
achim at pietig.com
Sat Apr 4 12:50:16 CEST 2015
Hi Joey,
the discussion to support multiple key sets is old and relaunches from time to time.
I have a ready design while using Security Environments, as you proposed.
Up to now the idea was rejected by several people because of the complexity in GnuPG and other software that handles the card.
Multiple users also require multiple password sets - this will extend the handling of the card a lot.
Because actual smart cards always belong to a single identity, this topic will get no high priority.
In a few days the next version 3 of the card specification will be launched - it adds elliptic curve cryptography and storage for more certificatees to use the card in other envirionment.
These topics are much more requested than multiple users/key-sets.
After finalising the spec and programming the new card I will check how much space ist available for other key sets - so the topic can be added in a version 3.x later.
An important goal of the actual card is a good price for small volumes! The actual chip has abaut 20K for program and data and I think it will be used completely for the new functions.
Adding multiple keys will lead into a bigger chip with higher costs - it must be checked kow many people need this enhancement and will pay much more for a card...
Regards
Achim
Am 03.04.2015 um 23:30 schrieb Jose Castillo:
> Ever since reading a wishlist for a next-gen OpenPGP card in February [1], the idea of multiple decryption keys on a card has seemed like a great idea to me. Others in the conversation suggested that it might be advantageous to have generic slots for keys, such that a card could contain more than one signing or authentication key. After delving into the relevant ISO smart card specs, I have a thought as to how this could be added to the OpenPGP smart card specification. I’ve written up a proposal, which I’m including below.
>
> The proposal uses the ISO 7816 “Manage Security Environment” command to swap between different sets of keys on a single card. I added this to an existing JavaCard implementation as a quick experiment [2], and was able to fit 21 2048-bit RSA keys on a stock 40K card before running out of space. Swapping between these keys is simple; the command just manipulates a pointer to the current security environment, and it’s backwards-compatible; gpg --card-status only sees the default security environment since it resets whenever the application is selected.
>
> This isn’t a fully-formed idea yet, and I’m not a smart card expert; there may be something completely off base in here. Still I wanted to throw it out there in the hope that it might move the conversation forward. I’d love to see some way to support multiple keys on an OpenPGP smart card in the future.
>
> - Joey
>
> [1]: https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052683.html
> [2]: https://github.com/josecastillo/OpenPGP-Card/tree/securityenvironment/
>
> -----
>
> Proposal: Multiple keys on OpenPGP Smart Card
> =============================================
>
> The OpenPGP smart card supports the use of three keys: a key each for signature, decipherment and authentication. The goal of this proposal is to include a standards-compliant method for supporting multiple keys of each type on the same smart card. There are two main use cases for this functionality:
>
> 1. Allow for the storage of expired or revoked decipherment keys, such that users can continue to decipher old messages with their card even if they generate a new key.
> 2. Allow for the storage of multiple identities on a single smart card.
>
> The mechanism proposed for this functionality is the ISO 7816 command MANAGE SECURITY ENVIRONMENT, which according to the spec, "prepares secure messaging and security commands (e.g., EXTERNAL, INTERNAL and GENERAL AUTHENTICATE, see also PERFORM SECURITY OPERATION)".
>
> Under this proposal, cards may support up to 20 security environments. The security environment encapsulates all data related to cryptographic tasks that are performed on the card; specifically, each security environment encapsulates:
>
> * Slots for signing, decipherment and authentication keys.
> * A set of key fingerprint DO's (C7, C8, C9)
> * A set of key generation timestamp DO's (CE, CF, D0)
> * If supported, a writable set of algorithm attributes (C1, C2, C3)
> * An independent signature counter
>
> When the OpenPGP application is selected, it is operating in the default security environment, which has a SEID of 1. Using the commands outlined below, the terminal can switch the card into another security environment.
>
> When the terminal queries the data objects listed above, or any constructed DO that includes them, the card returns the relevant data for the current SE. PUT DATA commands for these DO's store the data in the current SE. Commands that put or generate keys store them in the current SE. PSO and INTERNAL AUTHENTICATE operations operate with the keys in the current SE. Signatures made while in a SE increment the signature counter for that SE.
>
> Indicating support for Security Environments
> --------------------------------------------
>
> Support for the functionality in this proposal could be indicated by setting a flag in the first byte of the Extended Capabilities DO, which currently has three bits reserved for future use.
>
> Modifications to existing commands
> ----------------------------------
>
> This proposal requires one modification to an existing command. Space on smart cards is limited, and it may be possible for a card to run out of space before filling all of the available slots for keys. Therefore, when the terminal issues a PUT DATA or GENERATE ASYMMETRIC KEY command, and the card does not have sufficient memory to store the data or key, the card will respond with a SW1-SW2 of 6A84 (Not enough memory space in file), and return the card to the state it was in before the command was issued.
>
> New commands and access conditions
> ----------------------------------
>
> * RESTORE SECURITY ENVIRONMENT
> - Access Condition: Always
> * ERASE SECURITY ENVIRONMENT
> - Access Condition: VERIFY of PW3
> * STORE SECURITY ENVIRONMENT
> - Access Condition: VERIFY of PW3
>
> RESTORE SECURITY ENVIRONMENT
> ----------------------------
>
> * Command:
> - INS: 22
> - P1: F3
> - P2: The SEID to switch to (0x01-0x14)
> * Response SW1-SW2:
> - 9000: Success
> - 6A88: Referenced data not found (SEID out of range)
>
> This command switches the card into the requested security environment. After issuing this command, the terminal should query the Application Related Data DO (6E), which will contain the key metadata and algorithm attributes for the security environment that was requested.
>
> ERASE SECURITY ENVIRONMENT
> --------------------------
>
> * Command:
> - INS: 22
> - P1: F4
> - P2: The SEID to erase
> * Response SW1-SW2:
> - 9000: Success
> - 6985: Condition of use not satisfied
> - 6A88: Referenced data not found (SEID out of range)
>
> This command erases the keys and DO's in the security environment specified in P2. Implementations that allocate space for keys and DO's on demand may reclaim the space at this time.
>
> STORE SECURITY ENVIRONMENT
> --------------------------
>
> * Command:
> - INS: 22
> - P1: F2
> - P2: The SEID to overwrite
> * Response SW1-SW2:
> - 9000: Success
> - 6985: Condition of use not satisfied
> - 6A88: Referenced data not found (SEID out of range)
>
> This command moves the keys and DO's in the current SE to the SE specified in P2, overwriting any keys and DO's in that environment, and then switches the card to that SE. The previous SE is replaced with an empty SE.
>
> For example: If the current environment is the default (SE 1), and the terminal issues a STORE SECURITY ENVIRONMENT command for SE 2, all keys and data will be moved to SE 2, and SE 1 will be empty. At the conclusion of the command, the current SE will be SE 2.
>
> Backwards Compatibility
> -----------------------
>
> Since the card will always be in the default SE when powered up, this proposal is generally backwards compatible; terminals that do not understand the new commands will always interact with the default security environment, and there are no changes to the format of the data returned from the card.
>
> There is a scenario in which a card with an available key slot in the default SE may not have room for a new key; in this case, the card would return an unexpected response of 6A88 to a PUT DATA or GENERATE ASYMMETRIC KEY command. This scenario bears investigation.
>
> Implications for compatible clients
> -----------------------------------
>
> This proposal adds a bit of additional complexity to the use of smart cards; in particular, it might no longer be sufficient for the client to note the serial number of the card where a key is stored. Compatible clients might also have to note which security environment the key resides in. Furthermore, the ability to move keys between security environments might make this even more difficult.
>
> In its desire to be backwards compatible, this proposal does not modify any of the responses from the card application; as such, getting information about all the keys on a card requires switching into each of the available security environments and querying the application related data. It might make sense to add an additional constructed DO for GET DATA that returns information about the available security environments and keys, or expand the Application Related Data DO to add information about the available security environments.
>
>
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel
>
More information about the Gnupg-devel
mailing list