Re: [opensc-devel] PIN not sent to card before signing

2012-10-23 Thread Mathias Tausig
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

2012-10-23 Thread Douglas E. Engert


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