On 10/25/2012 3:12 AM, Mathias Tausig wrote: > On Wednesday 24. October 2012 10:45:12 you wrote: >> On 10/24/2012 9:44 AM, Mathias Tausig wrote: >>> Hy! >>> >>> OK, I did install 0.13.0pre1 and patched with your patch, ran pkcs11-tool >>> very verbose. Still no success, but at least a little improvement: >>> >>> Oct 24 16:35:40 off17 pcscd[4490]: 00006361 APDU: 00 A4 08 0C 02 50 15 >>> Oct 24 16:35:40 off17 pcscd[4490]: 00013633 SW: 6A 82 >>> Oct 24 16:35:40 off17 pcscd[4490]: 00000390 APDU: 00 A4 08 00 02 50 31 00 >>> Oct 24 16:35:40 off17 pcscd[4490]: 00013839 SW: 6A 82 >>> Oct 24 16:35:40 off17 pcscd[4490]: 00000499 APDU: 00 A4 08 00 02 2F 02 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00013895 SW: 6A 82 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000453 APDU: 00 A4 08 0C 04 50 4B 00 >>> 01 Oct 24 16:35:41 off17 pcscd[4490]: 00014052 SW: 6A 82 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000495 APDU: 00 A4 08 0C 04 30 00 00 >>> 01 Oct 24 16:35:41 off17 pcscd[4490]: 00014010 SW: 6A 82 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000434 APDU: 00 A4 08 00 04 10 03 B2 >>> 00 00 Oct 24 16:35:41 off17 pcscd[4490]: 00014184 SW: 6A 82 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00007703 APDU: 00 A4 08 0C 02 1F FF >>> Oct 24 16:35:41 off17 pcscd[4490]: 00022255 SW: 90 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000243 APDU: 00 20 00 81 06 31 32 33 >>> 34 35 36 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00040760 SW: 90 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00009640 APDU: 00 A4 08 0C 02 1F FF >>> Oct 24 16:35:41 off17 pcscd[4490]: 00019360 SW: 90 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000359 APDU: 00 20 00 81 06 31 32 33 >>> 34 35 36 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00040640 SW: 90 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00002532 APDU: 00 A4 08 0C 02 1F FF >>> Oct 24 16:35:41 off17 pcscd[4490]: 00016460 SW: 90 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000383 APDU: 00 22 01 B6 03 83 01 02 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00010609 SW: 90 00 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000477 APDU: 00 2A 9E 9A 80 00 01 FF >>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF >>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF >>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF >>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 05 >>> 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A >>> 34 9E 0C 47 BB 80 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00048524 SW: 67 00 >> >> Actually here is the problem. The above 67 00 is wrong length. The >> card-cardos.c tried this: >> 0xb721d900 16:35:41.223 [opensc-pkcs11] >> card-cardos.c:836:cardos_compute_signature: trying RSA_PURE_SIG (padded >> DigestInfo) >> >> but it failed, so it tries again: >> 0xb721d900 16:35:41.272 [opensc-pkcs11] >> card-cardos.c:842:cardos_compute_signature: trying RSA_SIG (just the >> DigestInfo) >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000378 APDU: 00 2A 9E 9A 23 30 21 30 >>> 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 >>> A4 1C 7A 34 9E 0C 47 BB 80 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00023629 SW: 69 82 >> >> The 69 82 is Command not allowed, Security Status not satisfied (i.e. >> user_consent) >> >> The question is why does it try the padded DigestInfo first? >> See the comments in card-cardos.c at line 821. >> If the right FLAGS are set, it should get it right the first time. > > You are right! Reselecting the signature DF keeps the security status active > (I tried it). I looked at the source code of the corresponding part (card- > cardos.c, line 821), and the commentary gives it away: > > /* XXX As we don't know what operations are allowed with a > * certain key, let's try RSA_PURE etc. and see which operation > * succeeds (this is not really beautiful, but currently the > * only way I see) -- Nils > * > * We also check for several caps flags here to pervent generating > * invalid signatures with duplicated hash prefixes with some cards > */ > > This is wrong. You can read those informations from the supportedAlgorithms > sequence in the TokenInfo file (I have to lines there with RSA_PKCS and > SHA1_RSA_PKCS as mechanisms and both with RSA2_SIG for the algorithm (which is > also the algorithm of the key)). > >> There are 4 other pkcs15-*.c modules that use the card-cardos.c driver. >> It looks like your card is not one of them. This is were others on the list >> with CardOS cards could help. > > I don't understand that. Do you mean, that it selects the wrong card driver? > I have manually created the PKCS#15 application to reference a seperate > signature application.
There are 4 pkcs15 emulation modules that appear to use the card-cardos.c driver, pkcs15-aactalis.c, pkcs15-infocamere.c, pkcs15-postecert.c, and pkcs15-tccardos. The PKCS15 emulation modules help fill in some of the details. The setting of the SC_CARD_CAP_ONLY_* flags used in card-cardos.c, are set in pkcs15.c in a fix_starcos-pkcs15-card(), and maybe a similar response to the type of problem you are seeing. (but not a generic fix, if the flags can be derived form some information on the card.) I don't have any CardOS cards or experience with them but others on this list do, and they should respond. What might be the issue is CardOS is not a true PKCS15 card, or does not store all the FLAGS that are required, or none of the previous cards supported user_consent, or user_consent was never set on and keys on these cards. I see the problem, but without any CardOS cards, don't know the best way to fix it. > >> >>> Oct 24 16:35:41 off17 pcscd[4490]: 00000377 APDU: 00 2A 9E 9A 14 04 75 95 >>> D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 >>> Oct 24 16:35:41 off17 pcscd[4490]: 00015614 SW: 69 82 >> >> It tried a third time, but the Security status is not satisfied. >> >>> Now it doesn't change back to the PKCS#15 DF anymore, but it reselects the >>> signature DF anyhow, with the same result. >>> >>> The decicsive lines in the debug log appear to be those: >>> >>> 0xb721d900 16:35:41.195 [opensc-pkcs11] pkcs15- >>> sec.c:479:sc_pkcs15_compute_signature: Private key path '3f001fff' >>> 0xb721d900 16:35:41.195 [opensc-pkcs11] pkcs15-sec.c:42:select_key_file: >>> called 0xb721d900 16:35:41.195 [opensc-pkcs11] card.c:610:sc_select_file: >>> called; type=2, path=3f001fff >>> 0xb721d900 16:35:41.195 [opensc-pkcs11] >>> card-cardos.c:439:cardos_select_file: called >>> >>> It seems like sc_pkcs15_compute_signature selects the path of the private >>> key without a prior check, if it is already there. Do you agree? >>> >>> cheers >>> Mathias >>> >>> P.S.: Did you exclude the mailing list on purpose? >> >> No sorry, must have just hit reply vs reply all. >> >> Getting others involved would be a good idea, as there >> are a number of cards that use the same code, and it looks >> like user_consent was not considered when the sc_pkcs11_compute_signature >> was written. >> >> If you want, send your response to this message to the list. >> > > Done ;-) > > cheers > Mathias > >>> On Wednesday 24. October 2012 08:56:35 you wrote: >>>> On 10/24/2012 7:31 AM, Mathias Tausig wrote: >>>>> On Tuesday 23. October 2012 09:42:51 Douglas E. Engert wrote: >>>>>> On 10/23/2012 3:43 AM, Mathias Tausig wrote: >>>>>>> On Monday 22. October 2012 13:45:36 Douglas E. Engert wrote: >>>>>>>> Based on the information in this thread, it looks like >>>>>>>> pkcs11-tool is is missing two lines that would check >>>>>>>> if the CKA_ALWAYS_AUTHENTICATE is set for the key >>>>>>>> in the sign_data routine. >>>>>>>> >>>>>>>> Can you try the attached patch? >>>>>> >>>>>> The patch I sent you was for 0.13.0pre1. >>>>>> >>>>>> It looks like you applied it to some earlier version, as >>>>>> 0.12.2 and above have: >>>>>> >>>>>> ATTR_METHOD(ALWAYS_AUTHENTICATE, CK_BBOOL); >>>>>> which is equivelent to the line you added: >>>>>> static CK_BBOOL getALWAYS_AUTHENTICATE (CK_SESSION_HANDLE sess, >>>>>> CK_OBJECT_HANDLE obj); >>>>> >>>>> OK. Do you think it would be useful to try out the 0.13 beta version? >>>> >>>> Depending on you needs you could try with 0.12.2 or 0.13.0pre1. >>>> but any fixes will only go into 0.13. >>>> >>>> OK, so it looks like the card is enforcing user_consent. >>>> The best thing to do is modify the opensc.conf something like: >>>> >>>> debug_level = 7; >>>> debug_file = /tmp/opensc-debug.log; >>>> >>>> If you then use the modified pkcs11-tool with the pkcs11-spy, >>>> add a -v or maybe -v -v -v -v -v -v -v, as pkcs11-tool may >>>> modify the debug_level. >>>> >>>> The card-cardos.c may be called by at least 4 different >>>> pkcs15-*.c modules. I suspect that the card-cardos.c is being >>>> over conservative in re-selecting the 50 15 and 1F FF files >>>> when it does not need to. The trace will show >>>> what modules are involved in this select. >>>> >>>>>> the C_Sign really does C_SignInit, C_SignUpdate, C_SignFinal. >>>>>> >>>>>> Two things might be happening here. Depending on how the card driver >>>>>> >>>>>> was written I suspect it is in the card driver or opensc , that is >>>>>> >>>>>> reselecting the 50 15 and 1F FF file each time (case (B) issue): >>>>>> >>>>>> (A) login(session,CKU_CONTEXT_SPECIFIC); may need to be done just >>>>>> before >>>>>> the C_SignFinal, to put it just before the crypto operation. >>>>>> In the PKCS11-spy output, line 16 should be between lines 18 and 19. >>>>>> >>>>>> (B) Even doing (A) is not good enough as the card driver is sending >>>>>> some select commands between the pin and the crypto operation. >>>>>> In the ADPU trace the order need to be: >>>>>> >>>>>> (1) APDU: 00 A4 08 00 02 50 15 >>>>>> (2) APDU: 00 A4 08 00 02 1F FF >>>>>> (3) APDU: 00 22 01 B6 03 83 01 02 >>>>>> >>>>>> (4) APDU: 00 20 00 81 06 31 32 33 34 35 36 >>>>>> >>>>>> (5) APDU: 00 2A 9E 9A 80 00 01 FF FF FF... >>>>>> >>>>>> >>>>>> Or maybe (4) could be between (2) and (3) >>>>>> >>>>>> You could test if this is correct by using multiple -s options >>>>>> with the opensc-tool adding a -s option for each of the APDUs >>>>>> listed in your trace and using : between bytes. >>>>>> >>>>>> opensc-tool -s 00:A4:08:00:02:50:15 \ >>>>>> >>>>>> -s 00:A4:08:00:02:1F:FF \ >>>>>> -s 00:22:01:B6:03:83:01:02 \ >>>>>> -s 00:20:00:81:06:31:32:33:34:35:36 \ >>>>>> -s 00:2A:9E:9A:80:00:01:FF:FF:(and add the rest ov the >>>>>> line) >>>>> >>>>> Yes, those are the correct commands. Select the signature DF, set the >>>>> security> >>>>> environment, verify the pin and issue the sign command. Here is the >>> >>> output: >>>>> opensc-tool -s 00:A4:08:00:02:50:15 \ >>>>> >>>>> -s 00:A4:08:00:02:1F:FF \ >>>>> -s 00:22:01:B6:03:83:01:02 \ >>>>> >>>>> -s 00:20:00:81:06:31:32:33:34:35:36 \ >>>>> -s "00 2A 9E 9A 14 70 37 80 71 98 C2 2A 7D 2B 08 07 37 1D >>>>> 76 >>>>> 37 >>>>> >>>>> 79 A8 4F DF CF 80" >>>>> Using reader with a card: Cherry SmartBoard XX44 00 00 >>>>> Sending: 00 A4 08 00 02 50 15 >>>>> Received (SW1=0x90, SW2=0x00) >>>>> Sending: 00 A4 08 00 02 1F FF >>>>> Received (SW1=0x90, SW2=0x00) >>>>> Sending: 00 22 01 B6 03 83 01 02 >>>>> Received (SW1=0x90, SW2=0x00) >>>>> Sending: 00 20 00 81 06 31 32 33 34 35 36 >>>>> Received (SW1=0x90, SW2=0x00) >>>>> Sending: 00 2A 9E 9A 14 70 37 80 71 98 C2 2A 7D 2B 08 07 37 1D 76 37 79 >>>>> A8 >>>>> 4F DF CF 80 >>>>> Received (SW1=0x90, SW2=0x00): >>>>> 43 B9 4E 55 83 FF 74 3C 14 62 40 92 B2 73 99 A0 C.NU..t<.b@..s.. >>>>> AE 0E BD 34 CE 2F 65 0B 1A 39 88 80 26 89 58 A7 ...4./e..9..&.X. >>>>> 75 C3 61 A8 B6 38 14 B8 88 BD 05 59 CE B8 DF C3 u.a..8.....Y.... >>>>> 58 9D E2 A4 AC 64 01 D4 90 82 E8 21 FF A4 44 98 X....d.....!..D. >>>>> 5E F2 DB 26 55 91 96 0D E3 E5 A4 3B D6 36 F2 52 ^..&U......;.6.R >>>>> 25 4C F6 44 A5 44 AD 42 03 F0 0A 9B 4F EC DE EB %L.D.D.B....O... >>>>> 99 94 44 8F 66 9B FD E2 D9 71 C6 FC 3E 8A 3C 50 ..D.f....q..>.<P >>>>> FC F9 C5 D2 2F 4C 66 3B 45 2D B0 D7 7E 46 A0 93 ..../Lf;E-..~F.. >>>>> >>>>> I tried to make it work by using the PKCS#11 library directly (without >>>>> pkcs11- tool), but that didn't help either. Just calling OpenSession -> >>>>> Login -> FindObject -> SignInit -> Sign does the very same thing (switch >>>>> DF after verifying). Trying to issue another C_Login before and/or after >>>>> C_SignInit fails even earlier, as it returns a >>>>> CKR_USER_ALREADY_LOGGED_IN >>>>> error.> >>>>> >>>>>> If that does not work, try moving the PIN up one line. >>>>>> >>>>>>> I tried it out and had to adapt it a little bit to make it compile >>>>>>> (the >>>>>>> getALWAYS_AUTHENTICATE function needed a forward declaration). But I'm >>>>>>> afraid it didn't help. It did do an extra C_Login call: >>>>>>> >>>>>>> 12: C_FindObjectsFinal >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 13: C_SignInit >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> pMechanism->type=CKM_SHA1_RSA_PKCS >>>>>>> [in] hKey = 0x92c09e8 >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 14: C_GetAttributeValue >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> [in] hObject = 0x92c09e8 >>>>>>> >>>>>>> [in] pTemplate[1]: >>>>>>> CKA_ALWAYS_AUTHENTICATE bfa0ef23 / 1 >>>>>>> >>>>>>> [out] pTemplate[1]: >>>>>>> CKA_ALWAYS_AUTHENTICATE True >>>>>>> >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 15: C_GetTokenInfo >>>>>>> [in] slotID = 0x1 >>>>>>> >>>>>>> [out] pInfo: >>>>>>> label: 'GLOBALTRUST test card (Signatur ' >>>>>>> manufacturerID: 'CardOS V4.4 (C) Siemens AG 1994-' >>>>>>> model: 'PKCS#15 ' >>>>>>> serialNumber: '910E207A1616152D' >>>>>>> ulMaxSessionCount: 0 >>>>>>> ulSessionCount: 0 >>>>>>> ulMaxRwSessionCount: 0 >>>>>>> ulRwSessionCount: 0 >>>>>>> ulMaxPinLen: 8 >>>>>>> ulMinPinLen: 6 >>>>>>> ulTotalPublicMemory: -1 >>>>>>> ulFreePublicMemory: -1 >>>>>>> ulTotalPrivateMemory: -1 >>>>>>> ulFreePrivateMemory: -1 >>>>>>> hardwareVersion: 0.0 >>>>>>> firmwareVersion: 0.0 >>>>>>> time: ' ' >>>>>>> flags: 50c >>>>>>> >>>>>>> CKF_LOGIN_REQUIRED >>>>>>> CKF_USER_PIN_INITIALIZED >>>>>>> CKF_PROTECTED_AUTHENTICATION_PATH >>>>>>> CKF_TOKEN_INITIALIZED >>>>>>> >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 16: C_Login >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> [in] userType = CKU_CONTEXT_SPECIFIC >>>>>>> [in] pPin[ulPinLen] bfa1109d / 6 >>>>>>> >>>>>>> 31323334 3536 >>>>>>> >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 17: C_Sign >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> [in] pData[ulDataLen] bfa0f348 / 4 >>>>>>> >>>>>>> 626C610A >>>>>>> >>>>>>> Returned: 257 CKR_USER_NOT_LOGGED_IN >>>>>>> >>>>>>> >>>>>>> 18: C_SignInit >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> pMechanism->type=CKM_SHA1_RSA_PKCS >>>>>>> [in] hKey = 0x92c09e8 >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 19: C_SignUpdate >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> [in] pPart[ulPartLen] bfa0f348 / 4 >>>>>>> >>>>>>> 626C610A >>>>>>> >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> 20: C_SignFinal >>>>>>> [in] hSession = 0x92c5f10 >>>>>>> Returned: 257 CKR_USER_NOT_LOGGED_IN >>>>>>> >>>>>>> >>>>>>> 21: C_Finalize >>>>>>> Returned: 0 CKR_OK >>>>>>> >>>>>>> >>>>>>> Here are the coresponding APDUs >>>>>>> >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00008338 APDU: 00 A4 08 00 02 1F FF >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00020184 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00001183 APDU: 00 20 00 81 06 31 32 >>>>>>> 33 >>>>>>> 34 35 36 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00047776 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00007895 APDU: 00 A4 08 00 02 1F FF >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00022121 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00001175 APDU: 00 20 00 81 06 31 32 >>>>>>> 33 >>>>>>> 34 35 36 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00048801 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00009766 APDU: 00 A4 08 00 02 50 15 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00020231 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00000181 APDU: 00 A4 08 00 02 1F FF >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00020820 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00000128 APDU: 00 22 01 B6 03 83 01 >>>>>>> 02 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00018865 SW: 90 00 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00000169 APDU: 00 2A 9E 9A 80 00 01 >>>>>>> FF >>>>>>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF >>>>>>> FF >>>>>>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF >>>>>>> FF >>>>>>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF >>>>>>> FF >>>>>>> FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 30 21 30 09 06 >>>>>>> 05 >>>>>>> 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 B4 A4 1C >>>>>>> 7A >>>>>>> 34 9E 0C 47 BB 80 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00039823 SW: 69 82 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00000132 APDU: 00 2A 9E 9A 23 30 21 >>>>>>> 30 >>>>>>> 09 06 05 2B 0E 03 02 1A 05 00 04 14 04 75 95 D0 FA E9 72 FB ED 0C 51 >>>>>>> B4 >>>>>>> A4 1C 7A 34 9E 0C 47 BB 80 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00016864 SW: 69 82 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00000982 APDU: 00 2A 9E 9A 14 04 75 >>>>>>> 95 >>>>>>> D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 >>>>>>> Oct 23 10:38:15 off17 pcscd[4499]: 00015032 SW: 69 82 >>>>>>> >>>>>>> The problem remains the same: After verifiying the PIN, the PKCS#15 DF >>>>>>> is >>>>>>> selected without doing anything there, and then the signature DF is >>>>>>> reselected and the authentication is lost in the process. This >>>>>>> behaviour >>>>>>> makes me think, that the problem is rathe in opensc-pkcs11.so and not >>>>>>> in >>>>>>> pkcs11-tool. I also tried to use the pinpad to enter the pin (instead >>>>>>> of >>>>>>> specifying it on the command line), but the outcome was the same. >>>>>>> >>>>>>> cheers >>>>>>> Mathias >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> opensc-devel mailing list >>>>>>> opensc-devel@lists.opensc-project.org >>>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel >>>>> >>>>> _______________________________________________ >>>>> opensc-devel mailing list >>>>> opensc-devel@lists.opensc-project.org >>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel > > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
