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 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
[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
[opensc-devel] Creating a new PKCS#15 profile
Hy! I have a smartcard which is initialized with a signature application. Now I want to add a PKCS#15 application to the card, which references that data. I have started to add a new DF with some basic information according to the PKCS#15 specifications, so far I have an Object directory file and a certificate directory file. I tried to access the card with pkcs15-tool --dump, but I got th error message: PKCS#15 binding failed: Unsupported card I assume, that I somehow have to create a new profile for the card. Is this correct? Is there some guidance, how this is done? cheers Mathias ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Creating a new PKCS#15 profile
On Tuesday 18. September 2012 16:21:29 Andreas Schwier wrote: Dear Matthias, what does opensc-tool -n report for this card ? The output is CardOS M4, the card is a CardOS v4.4 card. Did you check if the card OS is supported by OpenSC ? Andreas Am 18.09.2012 15:43, schrieb Mathias Tausig: Hy! I have a smartcard which is initialized with a signature application. Now I want to add a PKCS#15 application to the card, which references that data. I have started to add a new DF with some basic information according to the PKCS#15 specifications, so far I have an Object directory file and a certificate directory file. I tried to access the card with pkcs15-tool --dump, but I got th error message: PKCS#15 binding failed: Unsupported card I assume, that I somehow have to create a new profile for the card. Is this correct? Is there some guidance, how this is done? 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] Unsing engine_pks11 with openssl-fips 2.0
Hello! Has anybody been able to use engine_pkcs11 with the recently released FIPS approved version of openssl? I failed to do so. I was trying to sign a certificate with a FIPS enabled build of openssl (1.0.1c, FIPS object module 2.0) and the PKCS#11 engine (using a Safenet eToken). Opensc and engine_pkcs11 are the most recent versions (0.12.2 and 0.1.8) I did this procedure before (with the non-fips version) using an openssl config file: openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/lib/engines/engine_pkcs11.so MODULE_PATH = libeTPkcs11.so PIN = topsecret VERBOSE = EMPTY init = 0 [ca] ... and the command openssl ca -engine pkcs11 -in /tmp/testcsr -keyfile 2:74 -keyform engine -out /tmp/cert -batch -config /tmp/testConf -md sha1 -subj /C=AT/CN=Test -days 30 This worked like charm, but with the fips-build (engine_pkcs11 and the PKCS#11 client library are the same), I get a segmentation fault: Using configuration from /tmp/testConf initializing engine engine pkcs11 set. Looking in slot 2 for key: 74 Found 6 slots [0] Cherry SmartBoard XX44 00 no tok [1] AKS ifdh 00 00 login (eToken) [2] AKS ifdh 01 00 login (INTERN) [3]no tok [4]no tok [5]no tok Found slot: AKS ifdh 01 00 Found token: INTERN Found 2 certificates: 1INTERN (/C=AT/CN=INTERN/emailAddress=int...@test.at) 2INTERN SUB (/C=AT/CN=INTERN SUB/emailAddress=int...@test.at) Found 2 keys: 1 P INTERN 2 P INTERN SUB Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows countryName :PRINTABLE:'AT' commonName:PRINTABLE:'Test' Certificate is to be certified until Aug 10 10:17:22 2012 GMT (30 days) Segmentation fault All this is happening with the FIPS-capable build but without actually enabling FIPS-mode. I am quite lost here. Any ideas? cheers Mathias ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unsing engine_pks11 with openssl-fips 2.0
On 08/10/2012 03:41 PM, Douglas E. Engert wrote:
Not much to go on below.
Sorry. I will provide more information below.
Is there a core file produced?
No.
Can you get a stack trace?
Can the fips version be complied with debugging?
Can you run this under a debugger?
Three times yes. Here is the stacktrace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0x0001 in ?? ()
(gdb) bt
#0 0x0001 in ?? ()
#1 0x0822ff8a in ASN1_item_sign_ctx (it=0x829e674, algor1=0xb03aeff8,
algor2=0xb02fcff8,
signature=0xb0306ff0, asn=0xb05ccfcc, ctx=0xbfffe074) at a_sign.c:257
#2 0x081c77d9 in X509_sign_ctx (x=0xb04dbf98, ctx=0xbfffe074) at
x_all.c:100
#3 0x080a2caa in do_X509_sign (err=0xb7d28fc0, x=0xb04dbf98,
pkey=0xb0cbafe0, md=0x8302840,
sigopts=0x0) at req.c:1802
#4 0x080ae993 in do_body (xret=0xbfffe62c, pkey=0xb0cbafe0,
x509=0xb0b02f98, dgst=0x8302840,
sigopts=0x0, policy=0xb27e7fec, db=0xb05f2ff8, serial=0xb0600fec,
subj=0xb0cb /C=AT/CN=Test, chtype=4097, multirdn=0, email_dn=1,
startdate=0x825f5f6 today, enddate=0x0, days=30, batch=1,
verbose=0, req=0xb062aff0,
ext_sect=0xb2563ff0 usr_cert, lconf=0xb29f6ff0, certopt=0,
nameopt=0, default_op=1,
ext_copy=1, selfsign=0) at ca.c:2172
#5 0x080ad712 in certify (xret=0xbfffe62c, infile=0xb04c
/home/ad60095910/tmp/testcsr,
pkey=0xb0cbafe0, x509=0xb0b02f98, dgst=0x8302840, sigopts=0x0,
policy=0xb27e7fec,
db=0xb05f2ff8, serial=0xb0600fec, subj=0xb0cb /C=AT/CN=Test,
chtype=4097, multirdn=0,
email_dn=1, startdate=0x825f5f6 today, enddate=0x0, days=30, batch=1,
ext_sect=0xb2563ff0 usr_cert, lconf=0xb29f6ff0, verbose=0,
certopt=0, nameopt=0,
default_op=1, ext_copy=1, selfsign=0) at ca.c:1633
#6 0x080ac2cc in ca_main (argc=0, argv=0xbfffed98) at ca.c:1233
#7 0x0809c815 in do_cmd (prog=0xb36a9fa0, argc=20, argv=0xbfffed48) at
openssl.c:489
#8 0x0809c436 in main (Argc=20, Argv=0xbfffed48) at openssl.c:381
(gdb)
If not, can you turn on the debugging in opensc.conf
(Note: PINS and other sensitive data are traced)
I tried that, but no debug file was produced. I set debug=99 and
debug_file = /tmp/opensc-debug.log;
Or run it with opensc pkcs11-spy to get PKCS#11 trac
I don't know about pkcs11-spy, but I assume that it is a pkcs#11 tracer.
I already did create a log with the debug facility of the eToken driver
(reading and exporting it with Safenet's proprietary log viewer). Here
is the final part of the log:
0xb7e276c0 16:16:59.271 C_GetAttributeValue [4] ( pTemplate={
CKA_SENSITIVE=1 } )
0xb7e276c0 16:16:59.271 + C_GetAttributeValue( hSession=0x08730004
hObject=0x08ec0008 pTemplate={ CKA_EXTRACTABLE=1 } )
0xb7e276c0 16:16:59.274 C_GetAttributeValue [3] ( pTemplate={
CKA_EXTRACTABLE=0 } )
0xb7e276c0 16:16:59.274 + C_GetAttributeValue( hSession=0x08730004
hObject=0x08ec0008 pTemplate={ CKA_MODULUS=524 } )
0xb7e276c0 16:16:59.281 C_GetAttributeValue [7] ( pTemplate={
CKA_MODULUS=[256](9d f5 ef 5c b8 1d 15 cb 01 e7 bf ab fc 89 d0 52 cc 94
c2 6d dc 60 d9 b5 c8 12 06 a1 eb eb 4b 0d 92 76 f0 25 a5 96 44 cf 51 92
28 b4 fe 81 79 b4 e9 6a cc c4 87 73 1a 5e 32 f1 5c e4 1f e8 c2 78 25 fa
9a 88 ab 3f dd e9 78 e8 1a f6 5a 16 fa 29 05 e5 a3 1d 13 37 86 71 09 11
fa 5d 5c 1c b9 83 65 8c 83 5c b9 3e cc 01 4a de 8b db fb a2 ad 3c 56 0b
d5 16 d9 ca 88 b9 7f 4c df 3b f7 9a 7a 52 b1 74 79 c0 62 14 3c 64 30 f8
db c1 1d 33 ac 67 91 5f 63 ca 79 75 4d 48 76 b1 95 f7 7b f1 22 b3 8d f1
ca 9b 74 43 06 a6 70 4d 2f 1c 55 26 a2 fc 29 f1 0f 7e 3b e6 c6 53 30 1c
a4 21 10 3b dc 21 9e 1e df 78 35 d2 e4 48 e2 86 79 59 d0 85 e7 60 0e 3e
49 8e fc c1 9b 59 29 3d 0c ab 42 d9 a0 db ca 7b cf 26 ba 7c 63 31 42 ee
5a 49 28 7e f3 71 a4 e0 11 87 b5 7d 32 dd b0 bb b1 c4 63 cf d1 77) } )
0xb7e276c0 16:16:59.281 + C_GetAttributeValue( hSession=0x08730004
hObject=0x08ec0008 pTemplate={ CKA_PUBLIC_EXPONENT=524 } )
0xb7e276c0 16:16:59.286 C_GetAttributeValue [5] ( pTemplate={
CKA_PUBLIC_EXPONENT=[3](01 00 01) } )
0xb7e276c0 16:16:59.286 stop
Z:\home\ad60095910\tmp\etokenLog.fipsabsturz-20120808\Aug 10
[08-41]\openssl D502517D9 P24552 T-1209895232.trc
0xb37ffb70 16:16:59.559 - IFDHTransmitToICC( Lun=0x
TxLength=0x0005 *RxLength=0x0140 )
0xb37ffb70 16:16:59.559 TxBuffer(Send)=: TxBuffer=[5](00 a4 00
00 00)
0xb37ffb70 16:16:59.559 + eTSC_TransmitApdu( context=0xb6da2714
request=0xb37df364 requestLen=5 reply=0xb37ef370 replyLen=0xb37df19a )
0xb37ffb70 16:16:59.584 eTSC_TransmitApdu [25] ( )
0xb37ffb70 16:16:59.584 IFDHTransmitToICC [25] ( )
0xb37ffb70 16:17:07.653 - IFDHGetCapabilities( Lun=0x
Tag=0x0fb2 )
0xb37ffb70 16:17:07.653 Unknown Tag:
0xb37ffb70 16:17:07.653 rv=0266 IFDHGetCapabilities [0] ( )
I sent this trace to the Safenet support as well, they meant that it
didn't look peculiar to them.
I hope these informations help.
cheers
Mathias
On 8/10/2012 3:33 AM, Mathias Tausig wrote:
Hello!
Has
