On Tue, Aug 20, 2002, Matthias Loepfe wrote: > Hi > > I just want to give you some background information why AdNovum has > choosen the let's call it the 'interceptor-way' of implementing > the PKCS#11 functionality. > > We are working in an environment where the main purpose of the > hardware security modules (HSM) is not crypto acceleration but > secure storage of private keys and trust ankers. And in may > situations we have more than one (different) device active. > For example one for user authentication (removable chipcard) > and the other one for server/sevice authentication. > > The problem with the ENGINE aproach is, that if you load and > register an engine for let's say RSA, the ALL RSA operations > are directed to this engine. That's not what we expect. We ONLY > want the RSA operations bound to the objects (keys, certs) > stored on the HSM, be executed on it. Under the cover we also > create an ENGINE but we do not register it, but simply use > it for the key objects. >
That only happens if the appropriate ENGINE calls state that that ENGINE provides the default implementation. It doesn't have to. > Our second goal was to implement a solution which was a plug > replacement for a 'normal' OpenSSL. That means there is NO need > to modify any application to use PKCS#11 instead of file based > keys and certs. We 'mangled' all the necessary parameters into > one string (like an URL). > There are some problems with that approach if a fully featured PKCS#11 ENGINE is to be written at some point and with some planned OpenSSL extensions. Such an ENGINE might be able to supply the default implementation for some algorithms. A pretty good match for an ENGINE in PKCS#11 terms is a library and slot combination. Then an application might be able to use (say) slot #0 of library foo-pkcs11 for default RSA. This can be handled with the ctrl mechanism of OpenSSL 0.9.7, which isn't in previous versions. The config file stuff can also be used to allow existing applications to work with little or no modification. In this context a PKCS#11 ENGINE would be a kind of 'virtual' enging which would behave like the 0.9.7 dynamic ENGINE. An application (possibly via the config file mechanism) would load the PKCS#11 ENGINE, send it some ctrls which would say which file and slot to use and its new name. So what it might say is 'use slot #0 or library foo-pkcs11 and call it bar'. Any references to 'bar' after that would be routed to the slot and library combination. Under this scheme the key name would just map to CKA_NAME. Support for file based keys can be handled by some minor modifcation to OpenSSLs PEM handler. This might involve a special key with appropriate header "ENGINE KEY" perhaps? This special key format would have various bits of info in it. Minimally this might just be an ENGINE and key name and possibly some ctrls. We'd also have a utility to create the files (options to 'engine' perhaps?). When OpenSSL encountered such a key it would load the ENGINE referenced, optionally perform the ctrls on it then call ENGINE_load_private_key returning the EVP_PKEY structure to the application. This would all go on "under the hood" and the application should largely be able to handle this kind of key in the same way as an ordinary key. Steve. -- Dr. Stephen Henson [EMAIL PROTECTED] OpenSSL Project http://www.openssl.org/~steve/ ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
