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.
>
> > 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
