RE: PKCS#11

Marco:

Unfortunately, you happen to be using the least tested of our CTILs.  I am
very surprised the CTIL even writes to the card, I did not expect this.  I
am not the author of the PKCS11 interface, I will have to take time to
investigate the logic you outline below.  Do you know if it is necessary to
write the PIN to the card in order to perform signature operations?  This
would be a PKCS11 interface question, the CTIL only does what is necessary
based on the undercarriage crypto library (in this case PKCS11).  I am aware
that the original author had problems with the various PKCS11 libraries in
attempting to match certificates with private keys.  The logic you have been
investigating attempts various approaches based on the PKCS11 object data
structures to match them; I believe there are now 3 different techniques for
the various supported libraries (due to the authors of the PKCS11 libs, each
interpreted the specifications differently; this is not under our control).

After looking at your previous e-mail, I see that you are integrating a new
PKCS11 library.  Architecturally, I am surprised our logic writes an object
to the card for the PIN.  Even if this is necessary, it would seem it should
be deleted at the end.  If you can indicate to me that this is not necessary
for proper PKCS11 operation, then I will investigate re-arranging the PKCS11
library to not perform this operation and keep track of this information
internally (or at the least, delete the object at the end).  The "..."
characters on the object name imply that something is different in your
incarnation that we expected for the naming (a string).  I will have to
investigate further.

In the mean-time, you might consider keeping the created object handle in
the PKCS11 CTIL class memory, and if not NULL destroying it at the end; we
do call the destructors on the CTILs.  I would override the name to be a
constant string as you suggest.  This should get you operational in a short
amount of time.  Please let me know if this works, we can attempt to
implement this in the other libraries and re-test.  The logic that writes to
the card may have been necessary for a particular PKCS11 library we have
tested with, update testing will indicate this.  If this is the case, we
will #ifdef the write logic for that particular library if possible (perhaps
by input PKCS11 library file name).

After viewing the referenced code, it would appear that the "m_hPinObject"
object is not destroyed.  You should be able to destroy this object upon
CSM_Pkcs11 destruction (or the inheriting class) and fix your problem.
Please let me know.  I agree that your returned name should be "Data object
for Pin", since this is hardcoded in the logic.  Could your library be
losing track of this string?  Or perhaps not tracking it properly if our
logic does not close the session?  Further testing will show; please let me
know if this works, I will update the baseline.

There were not relevant changes to the SFL R1.10 version.

Bob Colestock
VDA.

-----Original Message-----
From: Marco Scarsi [mailto:[email protected]]
Sent: Tuesday, May 22, 2001 6:02 AM
To: [email protected]; [email protected]
Subject: RE: PKCS#11


Hallo Bob,

always about PKCS#11:

When calling CSM_Pkcs11::CreateInstances, one starts looping over all the 
certificate found on the card, in order to create an instance for each of 
them. Everytime a certificate with the corresponding private key is found, 
CSM_Pkcs11::CreateInstances calls CSM_Pkcs11::SetPin (line 318 of 
sfl\SMIME\alg_libs\sm_pkcs11\sm_pkcs11.cpp). CSM_Pkcs11::SetPin calls 
CSM_Pkcs11::CreateObject, who in turns calls sfl_c_createObject to write a 
new object on the card. This object should be labeled "Data object for Pin" 
(line 534 of sfl\SMIME\alg_libs\sm_pkcs11\sm_pkcs11.cpp).

This means that, for every execution of CSM_Pkcs11::CreateInstances, "n" new

objects are created on the card (where "n" is the number of private keys). 
Is that normal?

After a few executions of CSM_Pkcs11::CreateInstances, certain private keys 
are not found anymore by CSM_Pkcs11::CreateInstances on the card, and it 
becomes impossible to sign with the card.

Moreover, the objects written on the card are labeled "Data" or "Data..." 
(where ... stands for some strange symbols), instead than "Data object for 
Pin".

Do you have any idea/suggestion about this point?

Thanks,

Marco Scarsi

PS: I am still using SFL Version 1.9. Hence, line numbers refer to that 
version. Are there significant changes in 1.10 concerning sm_pkcs11Free3DLL 
or sm_pkcs11DLL?





>From: "Colestock, Robert" <[email protected]>
>To: 'Marco Scarsi' <[email protected]>, "Colestock, Robert"  
><[email protected]>
>CC: "'[email protected]'" <[email protected]>
>Subject: RE: PKCS#11
>Date: Thu, 17 May 2001 15:40:55 -0400
>MIME-Version: 1.0
>Received: from [206.137.100.2] by hotmail.com (3.2) with ESMTP id 
>MHotMailBCCD7378008640043252CE89640280300; Thu May 17 12:37:32 2001
>Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19)id 
><KZJ94QRH>; Thu, 17 May 2001 15:40:56 -0400
>From [email protected] Thu May 17 12:39:24 2001
>Message-ID: <[email protected]>
>X-Mailer: Internet Mail Service (5.5.2653.19)
>
>Marco:
>
>Glad to hear it.  The certificate file extensions you mention are all 
>binary
>ASN.1 encoded formats I believe; they should be fine.  The extension does
>not matter to the SFL, but it must be a binary ASN.1 encoded format.
>
>If you are using our test utilities for your verification, we report 
>success
>even if the signatures fail; you have to check the output reports very
>carefully to see the message like "SignerInfo number 1 WAS VERIFIED" before
>the test can be considered a success.  If you are using the SFL API 
>classes,
>then you must check the individual SignerInfo classes for the verified flag
>(demonstrated in the client level class, CL_MsgToVerify::Report()).  You
>could also simply breakpoint in your CTIL/lib to check results.
>
>Please be careful to check results; the "sm_pkcs11Free3DLLd" project is
>quite new, and relatively untested (powerful).  Please let me know if you
>have any updates to this specific project/sources to support your project.
>
>Bob Colestock
>VDA.
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.