Re: [opensc-devel] PIN not sent to card before signing
On Thursday 25. October 2012 09:13:58 Douglas E. Engert wrote: [...] Oct 24 16:35:41 off17 pcscd[4490]: 0477 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]: 0378 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. I have written a patch, which uses the algorithm information which is stored in the TokenInfo file of PKCS#15, and issued a pull request for it: https://github.com/OpenSC/OpenSC/pull/97 cheers Mathias ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN not sent to card before signing
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]: 6361 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]: 0390 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]: 0499 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]: 0453 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]: 0495 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]: 0434 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]: 7703 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]: 0243 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]: 9640 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]: 0359 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]: 2532 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]: 0383 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]: 0477 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]: 0378 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. Oct 24 16:35:41 off17 pcscd[4490]: 0377 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]
Re: [opensc-devel] PIN not sent to card before signing
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]: 6361 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]: 0390 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]: 0499 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]: 0453 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]: 0495 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]: 0434 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]: 7703 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]: 0243 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]: 9640 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]: 0359 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]: 2532 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]: 0383 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]: 0477 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]: 0378 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
Re: [opensc-devel] PIN not sent to card before signing
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? 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 Xd.!..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.BO... 99 94 44 8F 66 9B FD E2 D9 71 C6 FC 3E 8A 3C 50 ..D.fq...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
Re: [opensc-devel] PIN not sent to card before signing
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? 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]: 8338 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]: 1183 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]: 7895 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]: 1175 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]: 9766 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]: 0181 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]: 0128 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]: 0169 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]: 0132 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]: 0982 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--- src/tools/pkcs11-tool.c 2011-07-05 13:28:53.0 +0200 +++ src/tools/pkcs11-tool.c 2012-10-23 10:20:51.817544765 +0200 @@ -50,6 +50,7 @@ extern void *C_LoadModule(const char
Re: [opensc-devel] PIN not sent to card before signing
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); 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) 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]: 8338 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]: 1183 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]: 7895 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]: 1175 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]: 9766 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]: 0181 APDU: 00 A4 08 00 02 1F
Re: [opensc-devel] PIN not sent to card before signing
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?
On 10/22/2012 3:10 AM, Mathias Tausig wrote:
On Sunday 21. October 2012 17:24:41 you wrote:
Hello,
Le 19/10/2012 15:02, Mathias Tausig a écrit :
I am writing a PKCS#15 application for a (cardos v4.4) smartcard which
references an external signature application. The RSA key and the PIN are
stored in that external application, the PIN needs to be verified upon
every key usage.
To accomplish this, I have set the userConsent value in the
PrivateKeyDictionaryFile to 1.
Here is the content of the PrkDF (output from openssl):
0:d=0 hl=2 l= 67 cons: SEQUENCE
2:d=1 hl=2 l= 30 cons: SEQUENCE
4:d=2 hl=2 l= 18 prim: UTF8STRING:Signaturschlüssel
24:d=2 hl=2 l= 2 prim: BIT STRING
- 07 80 ..
28:d=2 hl=2 l= 1 prim: OCTET STRING
- 11.
31:d=2 hl=2 l= 1 prim: INTEGER :01
34:d=1 hl=2 l= 14 cons: SEQUENCE
36:d=2 hl=2 l= 1 prim: OCTET STRING :B
39:d=2 hl=2 l= 2 prim: BIT STRING
- 05.
0002 - SPACES/NULS
43:d=2 hl=2 l= 2 prim: BIT STRING
- 03 b8 ..
47:d=2 hl=2 l= 1 prim: INTEGER :02
50:d=1 hl=2 l= 17 cons: cont [ 1 ]
52:d=2 hl=2 l= 15 cons: SEQUENCE
54:d=3 hl=2 l= 6 cons:SEQUENCE
56:d=4 hl=2 l= 4 prim: OCTET STRING
- 3f 00 1f ff ?...
62:d=3 hl=2 l= 2 prim:INTEGER :0400
66:d=3 hl=2 l= 1 prim:INTEGER :14
69:d=0 hl=2 l= 0 prim: EOC
The problem is, that when I try to use the card with pkcs11-tool (either
with the --test option or with a --sign command), it doesn't verify the
pin before signing. Here is the relevant part of the APDU output:
Oct 19 14:40:20 off17 pcscd[4590]: 6755 APDU: 00 A4 08 00 02 1F FF
Oct 19 14:40:20 off17 pcscd[4590]: 00024106 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 1410 APDU: 00 20 00 81 06 31 32 33
34 35 36
Oct 19 14:40:20 off17 pcscd[4590]: 00048516 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 5039 APDU: 00 A4 08 00 02 50 15
Oct 19 14:40:20 off17 pcscd[4590]: 00024963 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 1737 APDU: 00 A4 08 00 02 1F FF
Oct 19 14:40:20 off17 pcscd[4590]: 00028271 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 0164 APDU: 00 22 01 B6 03 83 01 02
Oct 19 14:40:20 off17 pcscd[4590]: 00019795 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 0185 APDU: 00 2A 9E 9A 80 00 01 FF
FF FF FF FF FF FF FF FF F
F 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 F
F 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 F
F 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 9
5 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80
Oct 19 14:40:20 off17 pcscd[4590]: 00039821 SW: 69 82
In the first two commands the signature DF (1fff) is entered and the PIN
verified, thant it switches back to the PKCS#15 DF without doing anything
there (APDU#3). Than the signature DF is reentered and a signing command
is tried without prior authentication.
Is this a bug, is the userConsent field not heeded, or am I missing
something?
Please confirm (or not) -- in your test you are not using the current OpenSC
pkcs#11 module but only using the pkcs11-tool.
According to your logs, the application DF is selected between the PIN
verifying and 'sign' operation. That's the behavior of the previous
versions of OpenSC.
Could you tell us more about the application that generates the APDUs?
If it based on the older OpenSC version, try to change the 'lock_login'
configuration option.
I am using opensc-12.2, the version shipped with openSuse 12.2 (32 bit), which
is the most current stable version (according to the opensc homepage).
Here is the p11spy output produced by
pkcs11-tool --module pkcs11-spy.so --sign --login --input-file /tmp/csr --
output-file /tmp/csr.sig -m SHA1-RSA-PKCS --verbose --pin 123456
*** OpenSC PKCS#11 spy *
Loaded: /usr/lib/pkcs11/opensc-pkcs11.so
0: C_GetFunctionList
Returned: 0 CKR_OK
1: C_Initialize
[in] pInitArgs = (nil)
Returned: 0 CKR_OK
2: C_GetSlotList
[in] tokenPresent = 0x0
[out] pSlotList:
Count is 4
[out] *pulCount = 0x4
Returned: 0 CKR_OK
3: C_GetSlotList
[in] tokenPresent = 0x0
[out] pSlotList:
Slot -1
Slot 1
Slot 5
Slot 9
[out] *pulCount = 0x4
Returned: 0 CKR_OK
4: C_GetSlotInfo
[in] slotID = 0x
[out] pInfo:
slotDescription:'Virtual hotplug
Re: [opensc-devel] PIN not sent to card before signing
Hello,
Le 19/10/2012 15:02, Mathias Tausig a écrit :
I am writing a PKCS#15 application for a (cardos v4.4) smartcard which
references an external signature application. The RSA key and the PIN are
stored in that external application, the PIN needs to be verified upon every
key usage.
To accomplish this, I have set the userConsent value in the
PrivateKeyDictionaryFile to 1.
Here is the content of the PrkDF (output from openssl):
0:d=0 hl=2 l= 67 cons: SEQUENCE
2:d=1 hl=2 l= 30 cons: SEQUENCE
4:d=2 hl=2 l= 18 prim: UTF8STRING:Signaturschlüssel
24:d=2 hl=2 l= 2 prim: BIT STRING
- 07 80 ..
28:d=2 hl=2 l= 1 prim: OCTET STRING
- 11.
31:d=2 hl=2 l= 1 prim: INTEGER :01
34:d=1 hl=2 l= 14 cons: SEQUENCE
36:d=2 hl=2 l= 1 prim: OCTET STRING :B
39:d=2 hl=2 l= 2 prim: BIT STRING
- 05.
0002 - SPACES/NULS
43:d=2 hl=2 l= 2 prim: BIT STRING
- 03 b8 ..
47:d=2 hl=2 l= 1 prim: INTEGER :02
50:d=1 hl=2 l= 17 cons: cont [ 1 ]
52:d=2 hl=2 l= 15 cons: SEQUENCE
54:d=3 hl=2 l= 6 cons:SEQUENCE
56:d=4 hl=2 l= 4 prim: OCTET STRING
- 3f 00 1f ff ?...
62:d=3 hl=2 l= 2 prim:INTEGER :0400
66:d=3 hl=2 l= 1 prim:INTEGER :14
69:d=0 hl=2 l= 0 prim: EOC
The problem is, that when I try to use the card with pkcs11-tool (either with
the --test option or with a --sign command), it doesn't verify the pin before
signing. Here is the relevant part of the APDU output:
Oct 19 14:40:20 off17 pcscd[4590]: 6755 APDU: 00 A4 08 00 02 1F FF
Oct 19 14:40:20 off17 pcscd[4590]: 00024106 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 1410 APDU: 00 20 00 81 06 31 32 33 34
35
36
Oct 19 14:40:20 off17 pcscd[4590]: 00048516 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 5039 APDU: 00 A4 08 00 02 50 15
Oct 19 14:40:20 off17 pcscd[4590]: 00024963 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 1737 APDU: 00 A4 08 00 02 1F FF
Oct 19 14:40:20 off17 pcscd[4590]: 00028271 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 0164 APDU: 00 22 01 B6 03 83 01 02
Oct 19 14:40:20 off17 pcscd[4590]: 00019795 SW: 90 00
Oct 19 14:40:20 off17 pcscd[4590]: 0185 APDU: 00 2A 9E 9A 80 00 01 FF FF
FF
FF FF FF FF FF FF F
F 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 F
F 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 F
F 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 9
5 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80
Oct 19 14:40:20 off17 pcscd[4590]: 00039821 SW: 69 82
In the first two commands the signature DF (1fff) is entered and the PIN
verified, thant it switches back to the PKCS#15 DF without doing anything
there
(APDU#3). Than the signature DF is reentered and a signing command is tried
without prior authentication.
Is this a bug, is the userConsent field not heeded, or am I missing something?
Please confirm (or not) -- in your test you are not using the current OpenSC
pkcs#11 module
but only using the pkcs11-tool.
According to your logs, the application DF is selected between the PIN
verifying and 'sign' operation.
That's the behavior of the previous versions of OpenSC.
Could you tell us more about the application that generates the APDUs?
If it based on the older OpenSC version, try to change the 'lock_login'
configuration option.
cheers
Mathias
Kind regards,
Viktor.
___
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] PIN not sent to card before signing
Hello! I am writing a PKCS#15 application for a (cardos v4.4) smartcard which references an external signature application. The RSA key and the PIN are stored in that external application, the PIN needs to be verified upon every key usage. To accomplish this, I have set the userConsent value in the PrivateKeyDictionaryFile to 1. Here is the content of the PrkDF (output from openssl): 0:d=0 hl=2 l= 67 cons: SEQUENCE 2:d=1 hl=2 l= 30 cons: SEQUENCE 4:d=2 hl=2 l= 18 prim: UTF8STRING:Signaturschlüssel 24:d=2 hl=2 l= 2 prim: BIT STRING - 07 80 .. 28:d=2 hl=2 l= 1 prim: OCTET STRING - 11. 31:d=2 hl=2 l= 1 prim: INTEGER :01 34:d=1 hl=2 l= 14 cons: SEQUENCE 36:d=2 hl=2 l= 1 prim: OCTET STRING :B 39:d=2 hl=2 l= 2 prim: BIT STRING - 05. 0002 - SPACES/NULS 43:d=2 hl=2 l= 2 prim: BIT STRING - 03 b8 .. 47:d=2 hl=2 l= 1 prim: INTEGER :02 50:d=1 hl=2 l= 17 cons: cont [ 1 ] 52:d=2 hl=2 l= 15 cons: SEQUENCE 54:d=3 hl=2 l= 6 cons:SEQUENCE 56:d=4 hl=2 l= 4 prim: OCTET STRING - 3f 00 1f ff ?... 62:d=3 hl=2 l= 2 prim:INTEGER :0400 66:d=3 hl=2 l= 1 prim:INTEGER :14 69:d=0 hl=2 l= 0 prim: EOC The problem is, that when I try to use the card with pkcs11-tool (either with the --test option or with a --sign command), it doesn't verify the pin before signing. Here is the relevant part of the APDU output: Oct 19 14:40:20 off17 pcscd[4590]: 6755 APDU: 00 A4 08 00 02 1F FF Oct 19 14:40:20 off17 pcscd[4590]: 00024106 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 1410 APDU: 00 20 00 81 06 31 32 33 34 35 36 Oct 19 14:40:20 off17 pcscd[4590]: 00048516 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 5039 APDU: 00 A4 08 00 02 50 15 Oct 19 14:40:20 off17 pcscd[4590]: 00024963 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 1737 APDU: 00 A4 08 00 02 1F FF Oct 19 14:40:20 off17 pcscd[4590]: 00028271 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 0164 APDU: 00 22 01 B6 03 83 01 02 Oct 19 14:40:20 off17 pcscd[4590]: 00019795 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 0185 APDU: 00 2A 9E 9A 80 00 01 FF FF FF FF FF FF FF FF FF F F 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 F F 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 F F 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 9 5 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 19 14:40:20 off17 pcscd[4590]: 00039821 SW: 69 82 In the first two commands the signature DF (1fff) is entered and the PIN verified, thant it switches back to the PKCS#15 DF without doing anything there (APDU#3). Than the signature DF is reentered and a signing command is tried without prior authentication. Is this a bug, is the userConsent field not heeded, or am I missing something? cheers Mathias ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PIN not sent to card before signing
On 10/19/2012 8:02 AM, Mathias Tausig wrote: Hello! I am writing a PKCS#15 application for a (cardos v4.4) smartcard which references an external signature application. The RSA key and the PIN are stored in that external application, the PIN needs to be verified upon every key usage. To accomplish this, I have set the userConsent value in the PrivateKeyDictionaryFile to 1. Here is the content of the PrkDF (output from openssl): 0:d=0 hl=2 l= 67 cons: SEQUENCE 2:d=1 hl=2 l= 30 cons: SEQUENCE 4:d=2 hl=2 l= 18 prim: UTF8STRING:Signaturschlüssel 24:d=2 hl=2 l= 2 prim: BIT STRING - 07 80 .. 28:d=2 hl=2 l= 1 prim: OCTET STRING - 11. 31:d=2 hl=2 l= 1 prim: INTEGER :01 34:d=1 hl=2 l= 14 cons: SEQUENCE 36:d=2 hl=2 l= 1 prim: OCTET STRING :B 39:d=2 hl=2 l= 2 prim: BIT STRING - 05. 0002 - SPACES/NULS 43:d=2 hl=2 l= 2 prim: BIT STRING - 03 b8 .. 47:d=2 hl=2 l= 1 prim: INTEGER :02 50:d=1 hl=2 l= 17 cons: cont [ 1 ] 52:d=2 hl=2 l= 15 cons: SEQUENCE 54:d=3 hl=2 l= 6 cons:SEQUENCE 56:d=4 hl=2 l= 4 prim: OCTET STRING - 3f 00 1f ff ?... 62:d=3 hl=2 l= 2 prim:INTEGER :0400 66:d=3 hl=2 l= 1 prim:INTEGER :14 69:d=0 hl=2 l= 0 prim: EOC The problem is, that when I try to use the card with pkcs11-tool (either with the --test option or with a --sign command), it doesn't verify the pin before signing. Here is the relevant part of the APDU output: Oct 19 14:40:20 off17 pcscd[4590]: 6755 APDU: 00 A4 08 00 02 1F FF Oct 19 14:40:20 off17 pcscd[4590]: 00024106 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 1410 APDU: 00 20 00 81 06 31 32 33 34 35 36 Oct 19 14:40:20 off17 pcscd[4590]: 00048516 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 5039 APDU: 00 A4 08 00 02 50 15 Oct 19 14:40:20 off17 pcscd[4590]: 00024963 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 1737 APDU: 00 A4 08 00 02 1F FF Oct 19 14:40:20 off17 pcscd[4590]: 00028271 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 0164 APDU: 00 22 01 B6 03 83 01 02 Oct 19 14:40:20 off17 pcscd[4590]: 00019795 SW: 90 00 Oct 19 14:40:20 off17 pcscd[4590]: 0185 APDU: 00 2A 9E 9A 80 00 01 FF FF FF FF FF FF FF FF FF F F 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 F F 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 F F 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 9 5 D0 FA E9 72 FB ED 0C 51 B4 A4 1C 7A 34 9E 0C 47 BB 80 Oct 19 14:40:20 off17 pcscd[4590]: 00039821 SW: 69 82 In the first two commands the signature DF (1fff) is entered and the PIN verified, thant it switches back to the PKCS#15 DF without doing anything there (APDU#3). Than the signature DF is reentered and a signing command is tried without prior authentication. Is this a bug, is the userConsent field not heeded, or am I missing something? It sounds like a bug, in that, the opensc-pkcs11 will support the PKCS#11 CKA_ALWAYS_AUTHENTICATE flag i.e. PKCS15 user_consent, but the pkcs11-tool does not test for it, and prompt for the pin again or use the pin from the command line again. It would not take too much to add the code to pkcs11-tool. Can you run your test using the pkcs11-spy.so as the module with pkcs11-tool? (Mozilla NSS used by TB and FF have the same issue.) OpenSC 0.13.0-rc1 has a new option in the opensc.conf to allow the pin to be cached for uses be applications that do not yet support CKA_ALWAYS_AUTHENTICATE. cheers Mathias ___ 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
