Re: [openssl.org #11] Fw: trustway pkcs11 engine for openssl

[Zoran Radenkovic]

>> "Steven Bade <[EMAIL PROTECTED]>
>> I'm not sure about the second question, but we found that the eracom
>> engine submission was much more generic.   When one of my co-workers
>> tried to get our PKCS#11 libraries (openCryptoki) used by the Trustway
>> module there were many issues, as well as specific calls directly to
>> PKCs#11 functions rather than through the function list.   If I remember
>> correctly the Eracom submission from last year was much more generic and
>> we had to do nothing except point it to our shared library...  No
>> requirements for GKPCS11 headers, no direct function calls...
>

> "afchine madjlessi" <[EMAIL PROTECTED]>
>I think that in the case of Eracom card, keys are generated by an external way.
>Trustway card generates and stores keys, it's the reason of changes in the RSA methods.
>If needed, I can add the include files in the patch, so it doesn't require to get gpkcs11 headers.

With Eracom PKCS11 engine we tried to work in boundaries defined with engine API with minimal impact on openssl core code base. As well we wanted to have "key handling" transparent to application build up on openssl (not need to change source and rebuild application).

Problem of key generation is not simple as generate key in a HSM. What if you already have a key approved from CA and want to put in HSM. That if you have key on multiple smart card in multi custodian key-management environment …, or you want to generate key but you want to have key components back-up in smart cards, protected by different pins.

This is the reason (for time being – while openssl come up with it's own model), we decoupled "HSM key" generation from "openssl key" generation. Our user has key generation utility which covers all aspects mentioned above, and openssl utilities are used "to tell" that corresponding keys are stored on HSM.

Cheers,
Zoran