Gemalto (Safenet) IDBridge K30 (Fina QSCD) support #2335
Conversation
|
There was a problem with idprime_process_index() trying to read index file of 1700 or so bytes (only 500 or so bytes are needed for all entries) - it was failing with SC_ERROR_INVALID_DATA. I will try to correct the label/IDs next. They are given numbered names with open idprime, whereas closed one gives better names (like key/certificate DN) Also # before patch: pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so -O
error: PKCS11 function C_GetSlotInfo failed: rv = CKR_DATA_INVALID (0x20)
Aborting.
# after patch: pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so -O
Using slot 0 with a present token (0x0)
...snip...
Certificate Object; type = X.509 cert
label: Certificate 3
subject: DN: C=HR, O=Financijska agencija, CN=Fina RDC 2015
ID: 0003
...snip...
Profile object 36xxxxx76
profile_id: '4'
# official output: $ pkcs11-tool --module /opt/fina-gemalto/lib/libeToken.so -O
Using slot 0 with a present token (0x0)
...snip...
Certificate Object; type = X.509 cert
label: RDC CA 2015
subject: DN: C=HR, O=Financijska agencija, CN=Fina RDC 2015
ID: 3632xxxxxxxx3331
...snip...Also have noticed that list-slots command gives different flags and serial - is that important? ### pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so --list-slots
Available slots:
Slot 0 (0x0): Gemalto USB Shell Token V2 (95FE422C) 00 00
token label : FINA
token manufacturer : Gemalto
token model : PKCS#15 emulated
token flags : login required, token initialized, PIN initialized
hardware version : 0.0
firmware version : 0.0
serial num : 40c0xxxxxxxx2a77
pin min/max : 4/16
### pkcs11-tool --module /opt/fina-gemalto/lib/libeToken.so --list-slots
Available slots:
Slot 0 (0x0): Gemalto USB Shell Token V2 (95FE422C) 00 00
token label : FINA
token manufacturer : Gemalto
token model : ID Prime MD
token flags : login required, rng, token initialized, PIN initialized, other flags=0x200
hardware version : 0.0
firmware version : 0.0
serial num : BEA9xxxxxxxx2AA4
pin min/max : 4/16 |
maxrd2
force-pushed
the
gemalto-qscd-support
branch
3 times, most recently
from
bb713a9
to
45d9e71
Compare
|
This pull request introduces 1 alert when merging baa00f5 into 35a8a1d - view on LGTM.com new alerts:
|
|
Did another commit to show correct labels and key_id. Had to figure file format in hexeditor (not sure how successful I was) there are few constant amount of bytes to skip, and then random list of repeating tags that follow the same pattern and seems to always end with 49. In case it fails to find key ID (or label) it will fallback to to use the counter - as it was before. Does anyone know if there is format description of pubk[sx]cNNp11 files somewhere? Or what exactly are they. # official closed driver - libeToken.so
Certificate Object; type = X.509 cert
label: CN=Fina Root CA, O=Financijska agencija, C=HR
subject: DN: C=HR, O=Financijska agencija, CN=Fina Root CA
ID: 3730313832353431
Certificate Object; type = X.509 cert
label: RDC CA 2015
subject: DN: C=HR, O=Financijska agencija, CN=Fina RDC 2015
ID: 3632313634373331
# opensc-pkcs11.so
Certificate Object; type = X.509 cert
label: RDC CA 2015
subject: DN: C=HR, O=Financijska agencija, CN=Fina RDC 2015
ID: 3632313634373331
Public Key Object; RSA 4096 bits
label: RDC CA 2015
ID: 3632313634373331
Usage: verify
Access: none
Certificate Object; type = X.509 cert
label: CN=Fina Root CA, O=Financijska agencija, C=HR
subject: DN: C=HR, O=Financijska agencija, CN=Fina Root CA
ID: 3730313832353431
Public Key Object; RSA 4096 bits
label: CN=Fina Root CA, O=Financijska agencija, C=HR
ID: 3730313832353431
Usage: verify
Access: none |
maxrd2
force-pushed
the
gemalto-qscd-support
branch
2 times, most recently
from
25f2659
to
359a359
Compare
|
Last commit implemented get_challenge and fixed this error: now test works fine (although official one implements # pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so --test
Using slot 0 with a present token (0x0)
C_SeedRandom() and C_GenerateRandom():
seeding (C_SeedRandom) not supported
seems to be OK
Digests:
all 4 digest functions seem to work
MD5: OK
SHA-1: OK
RIPEMD160: OK
Signatures (currently only for RSA)
Signatures: no private key found in this slot
Verify (currently only for RSA)
No private key found for testing
Decryption (currently only for RSA)
No errorsthere are still differences with official driver: #### pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so --list-mechanisms
Using slot 0 with a present token (0x0)
Supported mechanisms:
SHA-1, digest
SHA224, digest
SHA256, digest
SHA384, digest
SHA512, digest
MD5, digest
RIPEMD160, digest
GOSTR3411, digest
RSA-PKCS, keySize={1024,2048}, hw, decrypt, sign, verify
SHA256-RSA-PKCS, keySize={1024,2048}, sign, verify
SHA384-RSA-PKCS, keySize={1024,2048}, sign, verify
SHA512-RSA-PKCS, keySize={1024,2048}, sign, verify
RSA-PKCS-PSS, keySize={1024,2048}, hw, sign, verify
SHA256-RSA-PKCS-PSS, keySize={1024,2048}, sign, verify
SHA384-RSA-PKCS-PSS, keySize={1024,2048}, sign, verify
SHA512-RSA-PKCS-PSS, keySize={1024,2048}, sign, verify
RSA-PKCS-OAEP, keySize={1024,2048}, hw, decrypt
#### pkcs11-tool --module /opt/fina-gemalto/lib/libeToken.so --list-mechanisms
Using slot 0 with a present token (0x0)
Supported mechanisms:
DES3-MAC, keySize={24,24}, sign, verify
DES3-MAC-GENERAL, keySize={24,24}, sign, verify
AES-MAC, keySize={16,32}, sign, verify
AES-MAC-GENERAL, keySize={16,32}, sign, verify
DES3-CBC, keySize={24,24}, encrypt, decrypt, wrap, unwrap
DES3-CBC-PAD, keySize={24,24}, encrypt, decrypt, wrap, unwrap
AES-CBC, keySize={16,32}, encrypt, decrypt, wrap, unwrap
AES-CBC-PAD, keySize={16,32}, encrypt, decrypt, wrap, unwrap
AES-CTR, keySize={16,32}, encrypt, decrypt, wrap, unwrap
mechtype-0x1088, keySize={16,32}, encrypt, decrypt, wrap, unwrap
RSA-PKCS-KEY-PAIR-GEN, keySize={2048,2048}, hw, generate_key_pair
RSA-PKCS, keySize={2048,2048}, hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap
RSA-PKCS-OAEP, keySize={2048,2048}, hw, encrypt, decrypt, wrap, unwrap
RSA-PKCS-PSS, keySize={2048,2048}, hw, sign, verify
SHA1-RSA-PKCS-PSS, keySize={2048,2048}, verify
SHA256-RSA-PKCS-PSS, keySize={2048,2048}, hw, sign, verify
SHA384-RSA-PKCS-PSS, keySize={2048,2048}, hw, sign, verify
SHA512-RSA-PKCS-PSS, keySize={2048,2048}, hw, sign, verify
SHA1-RSA-PKCS, keySize={2048,2048}, verify
SHA256-RSA-PKCS, keySize={2048,2048}, hw, sign, verify
SHA384-RSA-PKCS, keySize={2048,2048}, hw, sign, verify
SHA512-RSA-PKCS, keySize={2048,2048}, hw, sign, verify
ECDSA-KEY-PAIR-GEN, keySize={256,256}, hw, generate_key_pair, EC F_P, EC OID, EC uncompressed
ECDSA, keySize={256,256}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
ECDSA-SHA1, keySize={256,256}, verify, EC F_P, EC OID, EC uncompressed
ECDSA-SHA256, keySize={256,256}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
ECDSA-SHA384, keySize={256,256}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
mechtype-0x80000045, keySize={256,256}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
ECDSA-SHA512, keySize={256,256}, hw, sign, verify, EC F_P, EC OID, EC uncompressed
ECDH1-DERIVE, keySize={256,256}, hw, derive, EC F_P, EC OID, EC uncompressed
DES3-KEY-GEN, keySize={24,24}, generate
AES-KEY-GEN, keySize={16,32}, generate
PBE-SHA1-DES3-EDE-CBC, keySize={24,24}, generate
GENERIC-SECRET-KEY-GEN, keySize={112,2048}, generate
PBA-SHA1-WITH-SHA1-HMAC, keySize={160,160}, generate
PKCS5-PBKD2, generate
SHA-1-HMAC-GENERAL, keySize={112,2048}, verify
SHA-1-HMAC, keySize={112,2048}, verify
mechtype-0x252, keySize={112,2048}, sign, verify
SHA256-HMAC, keySize={112,2048}, sign, verify
mechtype-0x262, keySize={112,2048}, sign, verify
SHA384-HMAC, keySize={112,2048}, sign, verify
mechtype-0x272, keySize={112,2048}, sign, verify
SHA512-HMAC, keySize={112,2048}, sign, verify
SHA-1, digest
SHA256, digest
SHA384, digest
SHA512, digest
mechtype-0x80006001, keySize={24,24}, generate |
maxrd2
force-pushed
the
gemalto-qscd-support
branch
2 times, most recently
from
5467ef9
to
8607b8b
Compare
|
Thank you for the contributions. Looks like a good job for zero experince with smart cards/opensc and first pull request :) I just checked with my IDPrime card and all looks good. But because of unrelated bug, the
This is part of PKCS #11 3.0 and the Profile object is provieded by the OpenSC, not the card so this is not a problem. The proprietary driver probably supports only PKCS #11 2.40 or something older.
The serial number of a card is collected from here with some comment. I think it was different also for me from the windows driver, but I did not find a better way to find the same value. If you will figure out how to get same value as the proprietary driver, it would be great. The token flags do not look important.
I used only my observations for parsing this as far as I remember. Did not find much useful documentation. The CIFuzz already found a possible crash in your PR. Can you check its report: |
src/libopensc/card-idprime.c
Outdated
| prkey_info->id.value[1] = (*entry)->fd & 0xff; | ||
| prkey_info->id.len = 2; | ||
| memcpy(prkey_info->id.value, (*entry)->key_id, 8); | ||
| prkey_info->id.len = 8; |
There was a problem hiding this comment.
My IDPrime does not have the key id property so it falls back to the counter, but causes 7 bytes zero padding, which does not look great. Can the fallback use the length of 2 again? Probably by storing the length of the key_id alongside it.
There was a problem hiding this comment.
should be solved with 55f3c4d
There was a problem hiding this comment.
I'm not sure the functions I have added for extracting the key info are good.
Could you toggle #if 0 here with your card and see if it logs correct fields?
OpenSC/src/libopensc/card-idprime.c
Line 172 in 55f3c4d
They work in my case but I'm skipping some bytes here:
OpenSC/src/libopensc/card-idprime.c
Line 242 in 55f3c4d
The
if() in that line that decides how many bytes to skip and is likely wrong.I had '1' there on CA certificates and '2' on personal certs.
If you don't have time for that would appreciate if you could dump the pubk[sx]cNNp11 files from the card and share them somehow (maybe just ones for CA keys so you don't share your personal info) and will try to improve parsing more.
There was a problem hiding this comment.
I suppose you're getting correct key labels now?
Those seem to be at fixed position from pubk file start for me.
The key_id is immediately following certificate string tags (C/O/CN/L/...) - problem is those tags do not start at constant offset from file start :(
thanks... glad it does :)
ooh.. i thought it was only with mine card.. was to address that next.
I saw that, but my card's serial (at least what official driver is reporting) is completely different. Does that function extract correct S/N in your case?
ok... I've added rng flag (CKF_RNG / SC_CARD_CAP_RNG) with commit d31a948 as support was implemented with 8607b8b. My card also reports CKF_DUAL_CRYPTO_OPERATIONS (0x200) but this doesn't seem to be in use/supported by openSC. Speaking of support I did a little ATR parser to figure what's in there and have noticed a comment here that I believe is wrong: Here's what historical bytes in ATR header mean if I did it right: Which takes me to "Pre-issuing data" byte 0x65 with value 0xb0850300ef.
Think I've fixed that with c43c83a - have added logging of filenames on card it might help with supporting some new devices. |
no. I think I searched everywhere without success too. I assume it will be some checksum of some data, made in the proprietary driver, but its a lot of trial-and-errors or de-compiling ...
Right. I think we do not support this in OpenSC PKCS#11 module
Yeah. Your historical bytes are bit different from mine:
I copied the comment from the ATR parser, but clearly with the mask applied, it does not have to apply to all configurations so feel free to remove it.
Probably not. I think this is mostly for the issuing party to mark some data for the card. I think it will be same for all different cards issues by one party/in one batch/by one TPS and so on. But it can be used as part of the hash to generate the unique SN More unique information can be collected from the card ID (as it is now used for SN), from the CPLC you can get also some unique serial numbers and dates: https://stackoverflow.com/questions/39238382/how-do-i-get-cplc-data-from-a-smart-card
After some idiots started to use the github CI for bitcoin mining, for new contributors we need to approve the code before the CI is started. |
maxrd2
force-pushed
the
gemalto-qscd-support
branch
from
d31a948
to
50b7024
Compare
maxrd2
force-pushed
the
gemalto-qscd-support
branch
from
50b7024
to
b5dfd15
Compare
maxrd2
force-pushed
the
gemalto-qscd-support
branch
from
b5dfd15
to
a0d6c5d
Compare
|
So I went a bit further with debugging signature during test. It was like this: #### pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so --test --pin xxx
Using slot 0 with a present token (0x0)
C_SeedRandom() and C_GenerateRandom():
seeding (C_SeedRandom) not supported
seems to be OK
Digests:
all 4 digest functions seem to work
MD5: OK
SHA-1: OK
RIPEMD160: OK
Signatures (currently only for RSA)
testing key 0 (MLADEN MILINKOVIĆ)
error: PKCS11 function C_SignFinal failed: rv = CKR_FUNCTION_FAILED (0x6)
Aborting.In commit 5f6ab8d have changed reference for #### pkcs11-tool --module /usr/lib/pkcs11/opensc-pkcs11.so --test --pin xxx
Using slot 0 with a present token (0x0)
C_SeedRandom() and C_GenerateRandom():
seeding (C_SeedRandom) not supported
seems to be OK
Digests:
all 4 digest functions seem to work
MD5: OK
SHA-1: OK
RIPEMD160: OK
Signatures (currently only for RSA)
testing key 0 (MLADEN MILINKOVIĆ)
all 4 signature functions seem to work
testing signature mechanisms:
RSA-PKCS: OK
SHA256-RSA-PKCS: ERR: verification failed
testing key 1 (CN=Fina Root CA, O=Financijska agencija, C=HR) with 1 mechanism
error: PKCS11 function C_Sign failed: rv = CKR_FUNCTION_NOT_SUPPORTED (0x54)
Aborting.
RSA-PKCS: Now... key 1 is root CA... i don't think they placed root CA private key on my card... am i wrong? I have noticed that 3rd byte in index entry contains some nice value which I have used to calculate key_reference: Support for V3 key references Have pushed commit a0d6c5d which dumps whole entry and extra details when parsing card index file. Have started looking to do READ RECORD in order to get EF.DIR and EF.ATR/INFO - think that might provide some more info on key_reference or am I just wasting time? thanks |
They usually don't do that :) It is probably only the certificate (and maybe public key) on the card, which can allow the applications to verify your user certificate on the card (or at least copy the cert from the card to local store). Some vendors do that and these might require some different handling in the driver (not adding private key to the pkcs15 structs). My IDPrime has only the certs with keys so I did not try to handle this case. Is there any difference in the index file between the certs with keys and without?
What OS version does your card have? It should be visible in the debug log with OPENSC_DEBUG=9.
It might be that the key_id here is not just the counter of know objects but also unknown or anything else. This was also mostly guesswork and approximation from my card and debug logs provided by couple of people here (finding already four different versions that work and 1 that does not at all).
No idea here. |
ok.. will try to figure a way to differentiate those.. it would be really helpful to get index file and maybe some pubkey files from other token models.
0x03 - card->type = SC_CARD_TYPE_IDPRIME_V3
yeah.. mine says it's V3 but has different key_reference offset I wonder if there are V3 cards that would have third offset. In my case 4 keys are named in index file: ksc01, kxc00, kxc10, kxc11 - key_id was taken from last ASCII number before mine patch. Will keep diging and try to figure more stuff... maybe I'll find some nice disassembler and try that way :-/ |
|
I have OS version 1: My index parsing (on your branch) looks like this: @kirichkov originally reported the issue #2202 based on which I added the offsets. You can try to get in touch with him if you will be able to figure out differences between your cards. |
|
How can I help? I have access to both v3 and v4 idprimes. They both function the same save for the offsets. P.S. I have two pair of keys on my card and the second slot is the one that currently has the pair with valid certificate. The first slot has a pair with an expired certificate. Maybe that's what's causing the mismatch? Is it possible that keys are enumerated rather than slots this would explain the difference of 2 (F5 being the first key, F6 the second?). |
@Jakuje Your start[2] == 5 on all files.. so that's completely different from my index
I'm wondering if code change I did to calculate key_reference works correctly on your V3, so it would be great if you could try that.
Are keys from both slots listed in your index file? Would be great if you could also paste the debug output of EDIT: oh... you need to compile my branch for that output |
|
I think I can handle safely transplanting #2342 on top of your branch, it's just a few lines. Also, some info from the minidriver: |
How did you get the applet version? I was able to find only the OS version in the CPLC. |
|
Unfortunately your branch, together with #2342 is not working - Firefox gives me SEC_ERROR_TOKEN_NOT_LOGGED_IN doing Here's the list-slots - https://gist.github.com/kirichkov/9b804c3462c05307087f0f4889c1b80c. |
Gemalto provides a software on their website - Windows only, and there you can get that information, so they must have some way of extracting this data from the card. The Linux software they ship - SafeNet Authentication Client Tools - also shows the Applet version - @maxrd2 also mentions it. I did a APDU capture and it must be somewhere in this log. |
Thank you.. login error is probably due to wrong key_references... they are calculated as F5/F6 instead of F7/F8. |
|
I have noticed that proprietary driver before selecting the IDPrime app sends the adpu with INS:A6 - not sure what that is. here is mine: here is one from kirichkov capture: his successful response to A6 contains different bytes before IDPrimeApp - wonder if that is something important |
|
APDU: 00 A4 04 00 0B A0 00 00 00 18 80 00 00 00 06 62 Note that OpenSC has many drivers, and during the card match phase, some drivers send a SELECT FLE with AID. A well behave card will return file not found, and not reset its internal state. We have seen drivers that did not handle |
|
P.S. Also note if you have more then one application running (or starting a second application) may also |
In my dump I was running only the proprietary software which retrieves the applet version. |
Yes... I understand that - it's already used in card-idprime.c. |
|
I don't see 'A6' as a command either. My copy is older then yours. But reading #2335 (comment) 'A6' fails, then SELECT FILE AID is sent, then 'A6' works. So it looks like the applet knows how to support it. Many cards handle the SELECT FILE AID in the Card OS to switch select the applet and send all other commands to the active applet. Looks like the applet with AID A0 00 00 00 18 80 00 00 00 06 62 knows how to handle A6. |
|
Was there any progress on this PR? I would be happy to merge the general improvements for idprime, but not sure about the key references rearrangements, as they seem to work for one card, but not for others. |
I didn't manage to correctly find key references yet (was busy with other things) I think 59bf32b and 32f3851 are safe for merging. Still have to do more work on rest. Would you like me to make separate PR for those two? EDIT: in meantime I've also had to renew keys.. I wonder what ids will those end up having |
|
Thank you for the update. It would be probably best to take these two into separate PR, if you still plan to have a look into the rest of the stuff separately. |
|
The "index" as shown in #2335 (comment) is the used for Microsoft minidriver. The vendor may have done this so they do not need to supply a minidriver for Windows. So another approach is to treat this card as a GID card. OpenSC has a card-gids.c which can run on any system. try this to see if has the applet: Try running some tests by forcing the driver. This can be done in the opensc.conf file by giving ATR and driver, or with environment variable "OPENSC_DRIVER=gids" Try something like: If this works, and meets your needs, this may be a better way to use the new card which is an easy change. |
|
This does not work for me with my Gemalto IDPrime card: |
|
OK, so your card does not have a GIDS applet. But does it have the "index" that look like it is for the minidriver? @maxrd2 can you try the In any case knowing the "index" is a Microsoft object, could help in understanding what is going on. |
|
I get this: I've "downloaded" all files from the card, and there I've been looking into this and reading the docs, but didn't get to doing any tests yet. |
|
OK, thanks for testing if it has a Microsoft GIDS applet. |
|
What's the status of this PR? Initially it looks like a success story, but the later comments seem to indicate some problems with other versions of Gemalto's applet... |
The commits 59bf32b and 32f3851 seems good as they fix reading index on my device and don't break other devices. Rest of the commits fix my device, but break other two - haven't figured a way yet to reliably read the key information on all devices. Having access only to my device makes this especially hard :( Should I rebase and cherry-pick two good commits into separate PR? |
|
We have some work in progress for supporting more IDPrime smart cards in #2666 -- can you have a look if these changes make any difference for your cards? We also have now couple of cards we can try your changes on. It looks like the content of the IDPrime cards is very dependent on the way how the card/token were enrolled/provisioned but the #2666 already moved quite a bit from the current version. |
|
@maxrd2 Slovenia issues the same certificate USB (IDBridge K30), and we're trying to read it to sign a file in p7m, would this PR work for that? Thanks |
@bostjanpisler I'm really not sure. Last time I've tried i was able to use all keys that were on my card. @Jakuje Will test and let you know ASAP - I haven't used the card and played with it for >1yr, so have to start from scratch |
|
What's the status of this topic, is there anything to do? |
This is first of series of patches to support my Gemalto USB eToken.
I'm not sure of exact model as it's distributed by croatian finance agency under the name Fina QCSD.
On google I found image of Gemalto (Safenet) IDBridge K30 that looks exactly like my token.
I have it working correctly under linux with opensc and official closed source binary driver (libeToken.so.10.7.77, libIDPrimePKCS11.so.10.7.77) - installed from safenetauthenticationclient_10.7.77_amd64.deb
I've managed to get wireshark captures with official driver. I have zero/minimal knowledge/experience of OpenSC and tokens so any help recommendations would be helpful.
I'm patching card-idprime.c code, I don't think I need to create completely separate driver for this?
Checklist