GemsafeV1 is compatible with iso7816 pin commands, including
SC_PIN_CMD_GET_INFO so it doesn't need to customize it.
Acked-by: João Poupino <joao.poupino@gmail.com>
Tested-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Nuno Goncalves <nunojpg@gmail.com>
The EPO hands this card out to attorneys and inventors to authenticate
with their online services. The applet on the card seems to be identical
to the one on Swedish eID cards.
Ludovic Rousseau's list identifies the card as Gemalto IDClassic 340.
Gemalto Classic Client identifies the card as GemSAFE V3.
Previously the EPO was using a GemSAFE V1 card, its ATR was added with
81bbddfc24 ("card-gemsafeV1: Add a GemSafe V1 ATR").
GemSAFE V1 cards support signing 36 bytes of free form data.
When signing a hash, the hash must be prepended by the DigestInfo
header. The PKCS#1 padding is done on the card. The 36 bytes limit
is sufficient for MD5 (16 + 18 bytes for the header), SHA1 and
RIPEMD160 (both use 20 + 15 bytes for the header) and MD5_SHA1
(16 + 20 bytes, no header). The algorithm reference ("cryptographic
mechanism reference" in ISO 7816 parlance) for signing free form data
is 0x12.
GemSAFE V3 cards changed the algorithm reference for signing free
form data to 0x02. In addition, they gained the ability to sign SHA256.
Since SHA256 exceeds the 36 bytes limit (32 + 19 bytes for the header),
it must be sent to the card *without* DigestInfo header. The header
will be prepended by the card and it is instructed to do so by sending
algorithm reference 0x42.
This scheme is also supported for SHA1, the algorithm reference is
0x12 in this case. However using this is not necessary as SHA1 fits
within the 36 bytes limit, including the header.
Supporting SHA256 is straightforward, we just add it to the flags
before adding the RSA algorithms. When sc_pkcs15_compute_signature()
calls sc_get_encoding_flags(), the input will be "iFlags 0x202, card
capabilities 0x8000021A" and the output will be "pad flags 0x0, secure
algorithm flags 0x202". I.e. the hash is neither prepended by the
DigestInfo header nor PKCS#1 padded and the hash algorithm is passed
to gemsafe_set_security_env() which can send the appropriate algorithm
reference 0x42 to the card.
However there's a catch: Once we add SHA256 to the flags, PKCS#11
applications will be unable to use the other hashes like SHA1 or
RIPEMD160. That's because register_mechanisms() checks if the card
supports no hashes, and if so, adds all of them:
if (!(rsa_flags & SC_ALGORITHM_RSA_HASHES)) {
rsa_flags |= SC_ALGORITHM_RSA_HASHES;
}
We cannot add these missing hashes to the flags like we did with SHA256
because like SHA256, they would be sent to the card *without* DigestInfo
header. What we want is to send all hashes *with* DigestInfo header,
*except* for SHA256.
We can achieve that by registering a fake RSA algorithm which includes
the missing hashes in its flags. This fake algorithm is never used
because sc_card_find_rsa_alg() searches the algorithm list in-order
and we register the fake algorithm *after* the real algorithms.
The fake algorithm persuades register_mechanisms() to register the
missing hashes because it ORs the flags of all RSA algorithms together:
num = card->algorithm_count;
while (num--) {
switch (alg_info->algorithm) {
case SC_ALGORITHM_RSA:
rsa_flags |= alg_info->flags;
break;
}
}
So when signing e.g. a RIPEMD160 hash and sc_pkcs15_compute_signature()
calls sc_get_encoding_flags(), the input will be "iFlags 0x102, card
capabilities 0x8000021A" and the output will be "pad flags 0x100, secure
algorithm flags 0x2". This will result in the hash being prepended by
the DigestInfo header, which is what we want.
* reduce to a few, supported functions.
* change all functions to take the debug level as parameter.
* use symbolic names for the debug levels.
* fix tools to pass "verbose"/"opt_debug" as ctx->debug.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@4118 c6295689-39f2-0310-b995-f0e70906c6a9
- Remove slot abstraction from internal API and all reader drivers. CT-API (from where it all comes from) readers with multiple slots (if still found) can be presented as separate readers, OpenCT should remove the slot abstraction, PC/SC never knew about it. None of the tools knew how to use slots.
- Add sc_cancel (translates to SCardCancel)
- Re-implement sc_wait_for_event; support a blocking call.
- Replace the "int reader" API with "* sc_reader_t" style; add "Get reader by name" functionality.
- Remove "action" parameter from sc_disconnect_card() (was not used)
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3931 c6295689-39f2-0310-b995-f0e70906c6a9
By Stanislav Brabec
entersafe_init_pin_info() was declared as int, but defined and used as
void, resulting in a function returning an unused pseudo-random value.
card-gemsafeV1.c uses comparison 'type == "DF"', which is always false,
as it compares pointer to a string with pointer to the string "DF" in
the code.
git-svn-id: https://www.opensc-project.org/svnp/opensc/trunk@3563 c6295689-39f2-0310-b995-f0e70906c6a9