[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: PKCS#11



Hi Bob,

I just saw now your last answer (my previous message was not aware of it...)

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?

I guess not. But even if yes, I imagine the object should be removed from the
card before the end of the run. And I did not find any call to
C_DestroyObject in the code. Another possibility is that C_CreateObject, in the
PKCS11 implementations you used, does not physically write on the card. But I
would find this strange.


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.

Yes, I am integrating a new PKCS11 library, that is not mentioned between the
ones you support.


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.

I think the wrong label written on the card is a minor problem.


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.

For the moment I simply commented the call to CSM_Pkcs11::SetPin. Starting next week I'll be able to work on your suggestions.

Thanks

Bye

Marco
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.