Hi
In order to be able to import keys using the Java Card framework it looks
quite impossible to use the import mechanism used in the OpenPGPCard
specification. So unfortunatly a none standard workaround has to be used
which I propse further down. Also since most (all?) java cards today only
support short Lc/Le, decryption using the OpenPGP card on Java card is no
possible due to length of data that need to be sent. This can be done
however using ENVELOPE to encapsulate and split APDUs using long Lc.
I have tried to describe some none standard additions as well as use of
the ENVELOPE command in a document included below. All of which I already
have implemented (however not tested yet) in my Java Card implementation
of the spec. Comments and suggestions are welcome.
Any chance of actually geting support for it implemented in GnuPG?
Anyone with the needed skill who has time to make an implementation for
GnuPG. I could make an attempt myself but it will likely take time, get
implemented upside down and in the wrong place.
Are there any need, interest and/or use for further extensions to the
card? Maybe the possibility for OpenPGP certificate for the public key to
be stored on card? Expand the card edge to make it have enough
functionality to be able to be used together with PKCS #11 (possible
making a PKCS #15 compatible structure)?
Such additions would be placed in the todo list however and not be part of
any 1.0 release (unless it is something trivial to implement that add a
lot).
Proposed none standard extentions for key import etc follows.
These are some extensions used by JOpenPGPCard that are not part of the
OpenPGP card specification as of version 1.1.
DOs for GET DATA
TagFormat Description
---
DF SExtra options 4 bytes
DOs in detail
Extra Options:
--
With this DO the card indicates features that are not standard in the
OpenPGP card specification as of version 1.1 but are needed for some
implementations, eg. Java Card. A set Bit(1) means that the function is
available. Bits are counted from 0-31 where lsb is 0.
This DO will be sent as part of the constructed DO 0x73 (Discretionary
data objects) and should not be parsed by applications not supporting it.
b0-b15 : Maximum number of octets that can be sent to the card using
ENVELOPE.
b16 : Maximum number of octets for ENVELOPE is announced in b0-b15.
This is announced as a service to applications that wish to use it.
If it is not set b0-b15 should be ignored.
b17-b29 : RFU (should be 0).
b30 : RSA key import has to be done using RSA modulus & private exponent.
b31 : RSA key import has to be done using RSA CRT notation.
NOTE: Key import methods in this field may only be specified if Extended
capabilities DO has key import unset. If key import is set in extended
capabilities applications should assume that key import is done as in the
original specification and ignore the import bits set in this DO.
Only one RSA key import method may be specified in the Extra Options.
DO for PUT DATA
===
If a key import method for RSA is specified in extra options and the
"support for Key Import" is not set in the Extended capabilities, the
Private key template DOs (DOs E0-E2) change as follows.
The private key template DO may be set multiple times for each key with
different tags in order to reduce the amount of data that has to be sent
at the same time. Each tag for a key should only be sent once. All tags
needed for the type of key import as specified in the extra options have
to be sent before the key is valid. The tags may be sent in any order.
Currently only RSA CRT key format is specified
Input of RSA CRT key. (xx = length)
E0,E1 or E2xx Tag to indicate a private key data object (signature,
decryption, authentification).
C0 xxPublic exponent e
C1 xxPrime1 p
C2 xxPrime2 q
C3 xxPublic modulus n
D1 xxPQ = q^-1 mod p
D2 xxDP1 = d mod (p - 1)
D3 xxDQ1 = d mod (q - 1)
Tags C0-C3, D1-D3 can be sent in any order using one or more (recommended)
PUT DATA to relevant DO (E0-E2). The tag for private key data object
(E0-E2) has to be present in each command.
Commands:
=
ENVELOPE
This is part of the OpenPGP card specification. This is a clarification of
the implementation based on the author's interpretation of the command.
This command is used under T=0 to be able to fragment APDUs using Lc.
The long APDU is split into one or more parts that are sent in the data
field of the ENVELOPE command. When all data has been sent an empty
ENVELOPE command is sent (i.e. with empty Lc & Le and no data field). The
data is then concatenated by the card in order it was received and the
resulting APDU is processed.
This is needed when e.g. decryption using 2048
