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

Reply via email to