PIN not sent to card before signing

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

PIN not sent to card before signing

Bugzilla from mathias.tausig@a-cert.at
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        
      0000 - 07 80                                             ..
   28:d=2  hl=2 l=   1 prim:   OCTET STRING      
      0000 - 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        
      0000 - 05                                                .
      0002 - <SPACES/NULS>
   43:d=2  hl=2 l=   2 prim:   BIT STRING        
      0000 - 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      
      0000 - 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]: 00006755 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]: 00001410 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]: 00005039 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]: 00001737 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]: 00000164 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]: 00000185 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Douglas E. Engert


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
>        0000 - 07 80                                             ..
>     28:d=2  hl=2 l=   1 prim:   OCTET STRING
>        0000 - 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
>        0000 - 05                                                .
>        0002 - <SPACES/NULS>
>     43:d=2  hl=2 l=   2 prim:   BIT STRING
>        0000 - 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
>        0000 - 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]: 00006755 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]: 00001410 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]: 00005039 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]: 00001737 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]: 00000164 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]: 00000185 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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Viktor Tarasov-3
In reply to this post by Bugzilla from mathias.tausig@a-cert.at
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        
>       0000 - 07 80                                             ..
>    28:d=2  hl=2 l=   1 prim:   OCTET STRING      
>       0000 - 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        
>       0000 - 05                                                .
>       0002 - <SPACES/NULS>
>    43:d=2  hl=2 l=   2 prim:   BIT STRING        
>       0000 - 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      
>       0000 - 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]: 00006755 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]: 00001410 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]: 00005039 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]: 00001737 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]: 00000164 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]: 00000185 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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Bugzilla from mathias.tausig@a-cert.at
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
> >    
> >       0000 - 07 80                                             ..
> >    
> >    28:d=2  hl=2 l=   1 prim:   OCTET STRING
> >    
> >       0000 - 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
> >    
> >       0000 - 05                                                .
> >       0002 - <SPACES/NULS>
> >    
> >    43:d=2  hl=2 l=   2 prim:   BIT STRING
> >    
> >       0000 - 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
> >    
> >       0000 - 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]: 00006755 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]: 00001410 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]: 00005039 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]: 00001737 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]: 00000164 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]: 00000185 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 = 0xffffffff
[out] pInfo:
      slotDescription:        'Virtual hotplug slot            '
                              '                                '
      manufacturerID:         'OpenSC (www.opensc-project.org) '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   6
        CKF_REMOVABLE_DEVICE            
        CKF_HW_SLOT                      
Returned:  0 CKR_OK


5: C_GetSlotInfo
[in] slotID = 0x1
[out] pInfo:
      slotDescription:        'Cherry SmartBoard XX44 00 00    '
                              '                                '
      manufacturerID:         'OpenSC (www.opensc-project.org) '
      hardwareVersion:         0.0
      firmwareVersion:         0.0
      flags:                   7
        CKF_TOKEN_PRESENT                
        CKF_REMOVABLE_DEVICE            
        CKF_HW_SLOT                      
Returned:  0 CKR_OK


6: C_GetTokenInfo
[in] slotID = 0x1
[out] pInfo:
      label:                  '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


7: C_OpenSession
[in] slotID = 0x1
[in] flags = 0x6
pApplication=(nil)
Notify=(nil)
[out] *phSession = 0x953bf10
Returned:  0 CKR_OK


8: C_GetTokenInfo
[in] slotID = 0x1
[out] pInfo:
      label:                  '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


9: C_Login
[in] hSession = 0x953bf10
[in] userType = CKU_USER
[in] pPin[ulPinLen] bfcc30ce / 6
    31323334 3536
Returned:  0 CKR_OK


10: C_FindObjectsInit
[in] hSession = 0x953bf10
[in] pTemplate[1]:
    CKA_CLASS             CKO_PRIVATE_KEY      
Returned:  0 CKR_OK


11: C_FindObjects
[in] hSession = 0x953bf10
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x1
Object 0x95369e8 matches
Returned:  0 CKR_OK


12: C_FindObjectsFinal
[in] hSession = 0x953bf10
Returned:  0 CKR_OK


13: C_SignInit
[in] hSession = 0x953bf10
pMechanism->type=CKM_SHA1_RSA_PKCS            
[in] hKey = 0x95369e8
Returned:  0 CKR_OK


14: C_Sign
[in] hSession = 0x953bf10
[in] pData[ulDataLen] bfcc05eb / 4
    626C610A
Returned:  257 CKR_USER_NOT_LOGGED_IN


15: C_SignInit
[in] hSession = 0x953bf10
pMechanism->type=CKM_SHA1_RSA_PKCS            
[in] hKey = 0x95369e8
Returned:  0 CKR_OK


16: C_SignUpdate
[in] hSession = 0x953bf10
[in] pPart[ulPartLen] bfcc05eb / 4
    626C610A
Returned:  0 CKR_OK


17: C_SignFinal
[in] hSession = 0x953bf10
Returned:  257 CKR_USER_NOT_LOGGED_IN


18: C_Finalize
Returned:  0 CKR_OK

Displaying the private key with pkcs11-tool shows, that
CKA_ALWAYS_AUTHENTICATE is set corrrectly:

Private Key Object; RSA
  label:      Signaturschlüssel
  ID:         42
  Usage:      sign
  Access:     always authenticate


cheers
Mathias
>
> Kind regards,
> Viktor.
>
> > _______________________________________________
> > opensc-devel mailing list
> > [hidden email]
> > http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Douglas E. Engert
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
>>>
>>>        0000 - 07 80                                             ..
>>>
>>>     28:d=2  hl=2 l=   1 prim:   OCTET STRING
>>>
>>>        0000 - 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
>>>
>>>        0000 - 05                                                .
>>>        0002 - <SPACES/NULS>
>>>
>>>     43:d=2  hl=2 l=   2 prim:   BIT STRING
>>>
>>>        0000 - 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
>>>
>>>        0000 - 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]: 00006755 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]: 00001410 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]: 00005039 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]: 00001737 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]: 00000164 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]: 00000185 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 = 0xffffffff
> [out] pInfo:
>        slotDescription:        'Virtual hotplug slot            '
>                                '                                '
>        manufacturerID:         'OpenSC (www.opensc-project.org) '
>        hardwareVersion:         0.0
>        firmwareVersion:         0.0
>        flags:                   6
>          CKF_REMOVABLE_DEVICE
>          CKF_HW_SLOT
> Returned:  0 CKR_OK
>
>
> 5: C_GetSlotInfo
> [in] slotID = 0x1
> [out] pInfo:
>        slotDescription:        'Cherry SmartBoard XX44 00 00    '
>                                '                                '
>        manufacturerID:         'OpenSC (www.opensc-project.org) '
>        hardwareVersion:         0.0
>        firmwareVersion:         0.0
>        flags:                   7
>          CKF_TOKEN_PRESENT
>          CKF_REMOVABLE_DEVICE
>          CKF_HW_SLOT
> Returned:  0 CKR_OK
>
>
> 6: C_GetTokenInfo
> [in] slotID = 0x1
> [out] pInfo:
>        label:                  '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
>
>
> 7: C_OpenSession
> [in] slotID = 0x1
> [in] flags = 0x6
> pApplication=(nil)
> Notify=(nil)
> [out] *phSession = 0x953bf10
> Returned:  0 CKR_OK
>
>
> 8: C_GetTokenInfo
> [in] slotID = 0x1
> [out] pInfo:
>        label:                  '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
>
>
> 9: C_Login
> [in] hSession = 0x953bf10
> [in] userType = CKU_USER
> [in] pPin[ulPinLen] bfcc30ce / 6
>      31323334 3536
> Returned:  0 CKR_OK
>
>
> 10: C_FindObjectsInit
> [in] hSession = 0x953bf10
> [in] pTemplate[1]:
>      CKA_CLASS             CKO_PRIVATE_KEY
> Returned:  0 CKR_OK
>
>
> 11: C_FindObjects
> [in] hSession = 0x953bf10
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x1
> Object 0x95369e8 matches
> Returned:  0 CKR_OK
>
>
> 12: C_FindObjectsFinal
> [in] hSession = 0x953bf10
> Returned:  0 CKR_OK
>
>
> 13: C_SignInit
> [in] hSession = 0x953bf10
> pMechanism->type=CKM_SHA1_RSA_PKCS
> [in] hKey = 0x95369e8
> Returned:  0 CKR_OK
>
>
> 14: C_Sign
> [in] hSession = 0x953bf10
> [in] pData[ulDataLen] bfcc05eb / 4
>      626C610A
> Returned:  257 CKR_USER_NOT_LOGGED_IN
>
>
> 15: C_SignInit
> [in] hSession = 0x953bf10
> pMechanism->type=CKM_SHA1_RSA_PKCS
> [in] hKey = 0x95369e8
> Returned:  0 CKR_OK
>
>
> 16: C_SignUpdate
> [in] hSession = 0x953bf10
> [in] pPart[ulPartLen] bfcc05eb / 4
>      626C610A
> Returned:  0 CKR_OK
>
>
> 17: C_SignFinal
> [in] hSession = 0x953bf10
> Returned:  257 CKR_USER_NOT_LOGGED_IN
>
>
> 18: C_Finalize
> Returned:  0 CKR_OK
>
> Displaying the private key with pkcs11-tool shows, that
> CKA_ALWAYS_AUTHENTICATE is set corrrectly:
>
> Private Key Object; RSA
>    label:      Signaturschlüssel
>    ID:         42
>    Usage:      sign
>    Access:     always authenticate
>
>
> cheers
> Mathias
>>
>> Kind regards,
>> Viktor.
>>
>>> _______________________________________________
>>> opensc-devel mailing list
>>> [hidden email]
>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

pkcs11-tool.diff.txt (522 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Bugzilla from mathias.tausig@a-cert.at
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]: 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel

pkcs11-tool.diff.txt (707 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

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]: 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
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Bugzilla from mathias.tausig@a-cert.at
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
> > [hidden email]
> > http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Bugzilla from mathias.tausig@a-cert.at
In reply to this post by Bugzilla from mathias.tausig@a-cert.at
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
> >>>>> [hidden email]
> >>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
> >>>
> >>> _______________________________________________
> >>> opensc-devel mailing list
> >>> [hidden email]
> >>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Douglas E. Engert


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

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.

>
>>
>>> 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
>>>>>>> [hidden email]
>>>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>>>>
>>>>> _______________________________________________
>>>>> opensc-devel mailing list
>>>>> [hidden email]
>>>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
> _______________________________________________
> opensc-devel mailing list
> [hidden email]
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: PIN not sent to card before signing

Bugzilla from mathias.tausig@a-cert.at
On Thursday 25. October 2012 09:13:58 Douglas E. Engert wrote:

> [...]
> >>> 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.
>
> 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
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-devel