How long is your pin? The IDPrime driver should accept pins from 4 to 16 characters:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-idprime.c#L98

I used a bit different version of IDPrime (probably Gemalto IDPrime 3810) with slightly different ATR:

https://smartcard-atr.apdu.fr/parse?ATR=3B+7F+96+00+00+80+31+80+65+B0+84+41+3D+F6+12+0F+FE+82+90+00

Unfortunately, the debug log now excludes the PIN APDUs so it is not clear whether the error is returned by the driver or by the card.

I see also

P:60978; T:0x8644701696 12:44:30.727 [opensc-pkcs11] card-idprime.c:256:idprime_init: Unknown OS version received: 3

which comes from here:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-idprime.c#L256

I tested with OS version 1 and 2, but I do not know what differences in PIN handling are in the OS version 3.

You can get complete debug log including Verify APDUs with OPENSC_DEBUG=9 (note, that it will include actual PIN!). If you have official driver, you can try to log APDUs it sends and compare it with the Verify APDU sent by OpenSC. If there will be some difference, it should be easy to update OpenSC to work also with your card.

How long is your pin? The IDPrime driver should accept pins from 4 to 16 characters:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-idprime.c#L98

I was suspecting the pin length might be the issue. When I submitted the bug report it was 4 characters long. Afterwards I changed the pin on windows with Gemalto's MiniDriver to 6 characters long and retested but I still got the same error.

I used a bit different version of IDPrime (probably Gemalto IDPrime 3810) with slightly different ATR:

https://smartcard-atr.apdu.fr/parse?ATR=3B+7F+96+00+00+80+31+80+65+B0+84+41+3D+F6+12+0F+FE+82+90+00

Unfortunately, the debug log now excludes the PIN APDUs so it is not clear whether the error is returned by the driver or by the card.

I see also

P:60978; T:0x8644701696 12:44:30.727 [opensc-pkcs11] card-idprime.c:256:idprime_init: Unknown OS version received: 3

which comes from here:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-idprime.c#L256

I tested with OS version 1 and 2, but I do not know what differences in PIN handling are in the OS version 3.

You can get complete debug log including Verify APDUs with OPENSC_DEBUG=9 (note, that it will include actual PIN!). If you have official driver, you can try to log APDUs it sends and compare it with the Verify APDU sent by OpenSC. If there will be some difference, it should be easy to update OpenSC to work also with your card.

Here's a with debug = 9. I changed the PIN just in case my redacting capabilities were insufficient.

About the official driver - I did get an installer package, but I'll need some guidance how to log the actual APDUs. I think I can also do that on linux and windows, if you can give me a guide.

If you debug on linux, simplest way is to start pcscd in a separate window. (You may have to kill it first.)
sudo /usr/sbin/pcscd -f -a

The run a test using their driver.

Then running a simple test to query the login state which returns the number of retries before the card is locked:
opensc-tool -s "00:20:00:80:00" will show opensc finding a driver, and in the last two lines this APDU:

00000987 [140303072691968] APDU: 00 20 00 80 00 
00018388 [140303072691968] SW: 63 CA 

63 Cn means you have n number of retries, in my case it was 10

From your debug log the command would be:
opensc-tool -s "00:20:00:11:00"
and card returned 63 C3 i.e. 3 retries.

There are a number of different way a cards a card handles a PIN. In you debug log it shows the driver is sending just the pin. I assume you redacted the pin to be 00 00 00 00 00 00. i.e. 00 20 00 11 06 00 00 00 00 00 00

Assuming your pin is 123456, the above should look like
00 20 00 11 06 31 32 33 34 35 36. If their driver could also be sending 00 20 00 11 03 12 23 56.

Another way is sending "FF" padded version of the pin like:
00 20 00 11 08 31 32 33 34 35 36 FF FF

If the max is really 16, then
00 20 00 11 10 31 32 33 34 35 36 FF FF FF FF FF FF FF FF FF FF

You may want to try this, but be careful not to send one of these with the wrong pin, as you could lock the card.
If you get close, use card with a working driver and login to reset the retry counter.

opensc-tool -s "00:20:00:11:00" -s "00 20 00 11 10 31 32 33 34 35 36 FF FF FF FF FF FF FF FF FF FF" -s "00:20:00:11:00"
would show the retry count before and after. if the pin was accepted, it would return 90 00 for the last two APDU.

Thanks so much for your help!

Here's my findings:

The correct APDU to query for remaining pin attempts is: 00:21:00:11
The correct login APDU for a PIN of 123456 would be: 00 21 00 11 10 31 32 33 34 35 36 00 00 00 00 00 00 00 00 00 00

i.e. it is zero padded.

I'll start working on a PR. I'd create a new model - V3, but if you can give me some direction where I can adjust the APDU sequences I'd be very grateful!

Thanks for checking. I tried that padding with zeroes to 16 bytes does not work with my (v1) card. Can you try the following commit if it works for you:

d6bc421 (from this branch: https://github.com/Jakuje/OpenSC/tree/idprime-v3)

On Linux both your branch and the 0.21.0 release give me error: PKCS11 function C_GetSlotInfo failed: rv = CKR_MECHANISM_INVALID (0x70)

The last APDUs I see is:

00000263 [139890680776448] APDU: 00 21 00 11 
00010031 [139890680776448] SW: 63 C3 
00001877 [139890680776448] APDU: 00 CB 00 FF 05 A0 03 83 01 83 
00010975 [139890680776448] SW: 61 21 
00000283 [139890680776448] APDU: 00 C0 00 00 21 
00003513 [139890680776448] SW: A0 1F 83 01 83 8C 04 F0 00 00 00 9C 04 F0 00 00 00 DF 21 04 00 FF A5 04 DF 27 02 FF FF DF 28 01 10 90 00 
00000599 [139890680776448] APDU: 00 CB 00 FF 05 A0 03 83 01 83 
00010824 [139890680776448] SW: 61 21 
00000297 [139890680776448] APDU: 00 C0 00 00 21 
00003567 [139890680776448] SW: A0 1F 83 01 83 8C 04 F0 00 00 00 9C 04 F0 00 00 00 DF 21 04 00 FF A5 04 DF 27 02 FF FF DF 28 01 10 90 00 

I'm currently downloading XCode and I'll try to compile it and report back. On macOS I do get to the PIN prompt.

Are you trying the --test (in that case, it sounds like follow-up issue) or just something simpler as ./src/tools/pkcs11-tool --login --pin 123456 -O, which will login and try to list the objects?

I compiled your branch on OS X there is some progress:

Listing objects pkcs11-tool --login -O on the card works!

I tried using the pkc11 module from firefox but that fails with CKR_GENERAL_ERROR

the general test fails too:

$ pkcs11-tool --login --test
Using slot 0 with a present token (0x0)
Logging in to " ".
Please enter User PIN: 
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  ERR: C_GenerateRandom failed: CKR_DATA_LEN_RANGE (0x21)
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only for RSA)
  testing key 0 (Private key 1) 
error: PKCS11 function C_SignFinal failed: rv = CKR_GENERAL_ERROR (0x5)
Aborting.

I've uploaded the (I think) relevant section of the debug=9 log here. Let me know if I missed something

On linux src/tools/pkcs11-tool --login --pin 123456 -O also results in an error, so it must be a separate issue.

error: PKCS11 function C_GetSlotInfo failed: rv = CKR_MECHANISM_INVALID (0x70)
Aborting.

I compiled your branch on OS X there is some progress:

Listing objects pkcs11-tool --login -O on the card works!

Good to hear that.

[...]
I've uploaded the (I think) relevant section of the debug=9 log here. Let me know if I missed something

Yeah, that is the actual sign operation, which goes wrong for some reason. It looks like this is another place where the card will behave a bit differently.

From your log:

Incoming APDU (2 bytes):
6A 88 j.

The SW 0x6A88 means DATA NOT FOUND so it sounds like the key reference is wrong in this case. But this key reference is set in the previous APDU (set security environment -- idprime_set_security_env()). Please attach also some log before this.

The key reference is already magic number in both versions I had a chance to interact with so it is quite expected that it will need some tweak also for a new version.

I think the official driver provides also a pkcs11 module, so you should be able to run the opensc's pkcs11-tool tests on the proprietary module, logging APDUs also for the signature operations to get what key references are used.

The APDU for setting security environment is here (0x22):

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/iso7816.c#L835

It will look like:

00:22:41:B6:80:01:[key_ref_byte]:something

The "magic" code for getting the right key reference for v1 and v2 cards is here:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-idprime.c#L198

It might already help to try the same method that is used with V2 cards (at this moment, the V1 is used for unknown versions).

On linux src/tools/pkcs11-tool --login --pin 123456 -O also results in an error, so it must be a separate issue.

error: PKCS11 function C_GetSlotInfo failed: rv = CKR_MECHANISM_INVALID (0x70)
Aborting.

This sounds suspicious. C_GetSlotInfo should not return CKR_MECHANISM_INVALID as it does not do anything with mechanisms. Can you get also debug log from that case? I would be interested to see what is going on there.

Gist updated. I removed only the certificates.

I think the official driver provides also a pkcs11 module, so you should be able to run the opensc's pkcs11-tool tests on the proprietary module, logging APDUs also for the signature operations to get what key references are used.

Indeed I have a propriatery module as well. By tests do you mean, to run pkcs11-tool --test via the command line against the propriatery module?
If so I'll run it and report back what I find. Is the --module /path/to/properiatery.so the correct parameter to utilize it?

This sounds suspicious. C_GetSlotInfo should not return CKR_MECHANISM_INVALID as it does not do anything with mechanisms. Can you get also debug log from that case? I would be interested to see what is going on there.

I'll get you a debug=9 on linux as well. I just want to clarify that I'm running linux under virtualbox and passing through the USB card reader device. Although I doubt this should have any impact. If you suspect it might be an issue, I have a raspberry Pi which I can run it "natively".

Gist updated. I removed only the certificates.

I updated my branch with the changed key reference for V3:

https://github.com/Jakuje/OpenSC/commits/idprime-v3

I think the official driver provides also a pkcs11 module, so you should be able to run the opensc's pkcs11-tool tests on the proprietary module, logging APDUs also for the signature operations to get what key references are used.

Indeed I have a propriatery module as well. By tests do you mean, to run pkcs11-tool --test via the command line against the propriatery module?
If so I'll run it and report back what I find. Is the --module /path/to/properiatery.so the correct parameter to utilize it?

Yes. Sorry, I wanted to add a command-line arguments, but forgot.

This sounds suspicious. C_GetSlotInfo should not return CKR_MECHANISM_INVALID as it does not do anything with mechanisms. Can you get also debug log from that case? I would be interested to see what is going on there.

I'll get you a debug=9 on linux as well. I just want to clarify that I'm running linux under virtualbox and passing through the USB card reader device. Although I doubt this should have any impact. If you suspect it might be an issue, I have a raspberry Pi which I can run it "natively".

Thanks. Using Virtualbox with pass-through USB should not cause any issues I would know about. I used that (the other way round) in qemu for some work without any issues.

I cleaned, pulled and recompiled but (without looking at the debug log) I get the same error message.

I think solving the Linux issue is a precondition to getting the macOS issue resolved, as I don't know how to look into the APDUs sent on macOS and ifdread has no command line options.

Full macOS gist

Full linux gist

Linux proprietary module command line
Linux proprietary module APDUs

It still fails with the same error (even though there is different key reference) so we will need a log from proprietary driver. From there:

APDU: 00 22 41 B6 06 80 01 02 84 01 F7 
APDU: 00 22 41 B6 06 80 01 02 84 01 F8 

There are two keys, one with key reference 0xF7 (247) and the other with 0xF8 (248) (the last byte)

In OpenSC the keys have reference 0x31 (49) and 0x32 (50)

Outgoing APDU (11 bytes):
00 22 41 B6 06 80 01 02 84 01 31 ."A¶......1\

(the first key is used in the opensc log)

I updated my branch with an attempt to guess correct key reference for your card. Unfortunately, I did not figure out any better way than using another magic numbers.

For the Linux log, it looks like the error comes from here:

P:20079; T:0x140004607953792 09:23:38.131 [opensc-pkcs11] framework-pkcs15.c:343:pkcs15_bind: cannot register mechanisms; CKR 0x70
P:20079; T:0x140004607953792 09:23:38.131 [opensc-pkcs11] slot.c:320:card_detect: Gemalto USB Shell Token V2 (50CC86A8) 00 00: cannot bind 'generic' token: rv 0x70

The functions around registering mechanisms do not provide much logging, but I assume it is because you do not have openssl devel package installed and therefore it fails to add the RSA-PSS mechanisms in sc_pkcs11_register_sign_and_hash_mechanism() (even though the idprime should not need openssl to do these operations if I am right as it can do the RSA-PSS padding on the card. This should be handled better.

Additionally, there is

P:20079; T:0x140004607953792 09:23:38.123 [opensc-pkcs11] card-idprime.c:583:idprime_read_binary: compression not supported, no zlib

which prevents the idprime driver the decompress the certificate. They are stored in compressed format on the card and zlib devel package is needed for building opensc with support for compressed certificates.

Sorry about the missing libraries - the Windows application showed "uncompressed" in the UI, but perhaps that's wrong.

Linux:

OpenSC Debug
pkcs11-tool STDOUT
pkcs11-tool proprietary STDOUT
pkcs11-tool proprietary APDU

One thing I noticed is that when using the proprietary driver pkcs11-tool says "Logging in to "CARD ..." while the OpenSC driver says "Logging in to "Name on certificate". I don't know whether this has any relevance.

P.S. for some reason pkcs11-tool does not generate a debug file when the proprietary module is used. To me it makes sense - likely the proprietary module doesn't have that functionality at all.

MacOS Debug - this time properly compiled with OpenSSL and ZLIB

Sorry about the missing libraries - the Windows application showed "uncompressed" in the UI, but perhaps that's wrong.

Linux:

OpenSC Debug
pkcs11-tool STDOUT

Do I read it right that the current version with changes in the branch works for you now?

pkcs11-tool proprietary STDOUT
pkcs11-tool proprietary APDU

One thing I noticed is that when using the proprietary driver pkcs11-tool says "Logging in to "CARD ..." while the OpenSC driver says "Logging in to "Name on certificate". I don't know whether this has any relevance.

This is just the name of the token presented by the pkcs11 module -- opensc tries to make it user friendly by providing the name from certificate, while the propriatery driver probably does not bother.

P.S. for some reason pkcs11-tool does not generate a debug file when the proprietary module is used. To me it makes sense - likely the proprietary module doesn't have that functionality at all.

the OPENSC_DEBUG is generated by the opensc pkcs11 library, not by the pkcs11-tool.

The last log from #2202 (comment) is missing couple of first columns, especially the APDUs.

I think the only thing that does not work correctly at present is the pkcs11 module that I use in Firefox for identification purposes. Firefox gives me SEC_ERROR_PKCS11_GENERAL_ERROR. That's under both Linux and macOS. It does request a PIN and the pin is accepted, unlike before.

I tried signing documents with an external software that works with OpenSC - signing works. I'm a bit puzzled why Firefox fails to work.

On Linux I tried the PKCS11 authentication with OpenSC vs Proprietary, here's both logs:

What I see is a difference in the APDUs sent - Gist with both logs

OpenSC sends:
00 22 41 B6 06 80 01 00 84 01 F8
Proprietary driver sends:
00 22 41 B6 06 80 01 45 84 01 F8

The 8th number is 45, and not 00. I have no idea how relevant this is.

The 8th byte is algorithm reference (I wrote this wrongly in the comment yesterday #2202 (comment)). The value 0x45 means RSA-PSS with SHA256:

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-idprime.c#L637

But the value 0x00 is suspicious as we do not have this value in our the above code. It might be that the card attempts to use raw-RSA or something. In any case, the response to the following APDU is 0x6985, which means CONDITION_NOT_SATISFIED (whatever it means). I do not see this APDU in the previous debug logs. You can use debug and debug_file configuration options in opensc.conf to get full debug log also from firefox to see what it actually does with opensc.

Output from pkcs11-tool -M would be also helpful to check what mechanisms are reported by opensc for your card. It should not report the raw-rsa as it is not supported in IDPrime cards as far as I know.

Output of pkcs11-tool -M:

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

Firefox Debug and APDU log

The mechanisms look good.

From the log:

framework-pkcs15.c:3999:pkcs15_prkey_sign: Initiating signing operation, mechanism 0xd.

mechanism 0xd is CKM_RSA_PKCS_PSS, which is fine.

framework-pkcs15.c:4131:pkcs15_prkey_sign: Selected flags 200110. Now computing signature for 32 bytes. 256 bytes reserved.

The flags here mean SC_ALGORITHM_RSA_PAD_PSS | SC_ALGORITHM_RSA_HASH_NONE | SC_ALGORITHM_MGF1_SHA256, which sounds fine too.

pkcs15-sec.c:613:sc_pkcs15_compute_signature: supported algorithm flags 0xE0E032, private key usage 0x20E
pkcs15-sec.c:565:sc_pkcs15_compute_signature: called
pkcs15-sec.c:613:sc_pkcs15_compute_signature: supported algorithm flags 0xE0E032, private key usage 0x20E
padding.c:470:sc_get_encoding_flags: called
padding.c:474:sc_get_encoding_flags: iFlags 0x200110, card capabilities 0xE0E032
padding.c:526:sc_get_encoding_flags: pad flags 0x0, secure algorithm flags 0x10
padding.c:527:sc_get_encoding_flags: returning with: 0 (Success)
pkcs15-sec.c:670:sc_pkcs15_compute_signature: DEE flags:0x00200110 alg_info->flags:0x00e0e032 pad:0x00000000 sec:0x00000010

What we are interested in are the last sec flag, which is only SC_ALGORITHM_RSA_PAD_PSS (without any hash algorithm), which is the reason why we do not set any algorithm reference in idprime_set_security_env(). I just tried the same with my card and indeed CKM_RSA_PKCS_PSS mechanism do not work. At this moment, I am not sure if ever worked.

I have tests for RSA_PSS mechanisms in p11test (src/tests/p11test/), but I do not have logs from previous executions so it will certainly require some love, but good thing is that I can reproduce the current issue also with my card.. It works fine with SHA256_RSA_PKCS_PSS mechanisms though. I will need to reread again what was the difference between these two.

Well thanks a lot for the work you've done so far! I do have to admit that this issue is out of my league, but I'll be standing by to test and provide logs if you come up with a solution!

The use of CKM_RSA_PKCS_PSS is another reason to change the "flags" from 32 to 64 bits, so a card driver can register the PSS hash it supports. (alg_info->flags:0x00e0e032 pad:0x00000000 sec:0x00000010)

The use of CKM_RSA_PKCS_PSS is another reason to change the "flags" from 32 to 64 bits, so a card driver can register the PSS hash it supports. (alg_info->flags:0x00e0e032 pad:0x00000000 sec:0x00000010)

AFAIK the flags are already there

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/card-idprime.c#L305

They are already needed for the CKM_SHAXXX_RSA_PKCS_PSS mechanisms, where it works fine. The issue here is, if I understand it right, that these flags are lost on the way to set security environment (because driver supports them), but I did not have time to look more into that yet.

Missed that. This might work. (not tested or compiled.)

diff --git a/src/libopensc/padding.c b/src/libopensc/padding.c
index 5bcb2bb8..80a6c3f4 100644
--- a/src/libopensc/padding.c
+++ b/src/libopensc/padding.c
@@ -491,6 +491,8 @@ int sc_get_encoding_flags(sc_context_t *ctx,
        } else if ((caps & SC_ALGORITHM_RSA_PAD_PSS) &&
                        (iflags & SC_ALGORITHM_RSA_PAD_PSS)) {
                *sflags |= SC_ALGORITHM_RSA_PAD_PSS;
+               *sflags |= iflags & SC_ALGORITHM_MGF1_HASHES;
+               *pflags = iflags & ~(iflags & (SC_ALGORITHM_MGF1_HASHES | SC_ALGORITHM_RSA_PAD_PSS));
 
        } else if ((caps & SC_ALGORITHM_RSA_RAW) &&
                                (iflags & SC_ALGORITHM_RSA_PAD_PKCS1

Split the iflags up between sflags done by card, and pflags done by software.

Thanks. I used the above change and it looks like working fine for me (after updating the driver to use the MGF1 values rather than the HASH ones, which are not present for this mechanism.

I can confirm that with the latest commit it works under both Linux and MacOS!

P.S. It doesn't seem to be usable in Safari/Mail or found by the security command but I believe this is more in the scope of OpenSCToken since the OpenSC binaries and modules do work with Firefox.

pkcs11-tool --test --login also has an error SHA256-RSA-PKCS: ERR: verification failed. But I don't see this impacting me negatively so far.

Thanks for verifying the fix. I used the p11test to check all works fine. It has the whole matrix of HASH/MGF1/salt_length combinations, but just couple of them work in OpenSC generally.

I think the error from pkcs11-tool is there because the pkcs11-tool --test does not actually support PSS mechanisms at all.

@Jakuje Thank you!

I also managed to get the certificate to show up in Safari and Mail and in sc_auth identities but it won't ask me for a pin, but I did manage to do this by mixing 0.21.0's OpenSCTokenApp and the the self-compiled OpenSC with idPrime v3, and something tells me this might be the reason. In any event I'll wait for this patch to be released officially before chasing the issue further.

Some more feedback regarding macOS: I installed the latest nightly which includes the v3 code. Safari does display the certificate selection screen but never asks for a pin. On the other hand sc_auth pair doesn't pair the card with the account, but this could be due to the card not using the correct slot. It's the same behavior on both 10.15 and 11.0.
Should I raise this in https://github.com/frankmorgner/opensctoken?

Other than that the Firefox security module is working fine and so do the signing applications.

Thanks for verification. Probably yes. I do not know what Safari and macOS do with smart cards.