OpenCryptoki's Soft token based on openssl, was never intended to be a FIPS capable function, its simply intended to be an example for those who might wish to a) test PKCS#11 applications without having to have a card b) implement a token for an accelerator, other examples in opencryptoki are ICA (IBM Cryptographic Accelerator - which has also been permuted on Z Linux to access what ever crypto exists in a CLEAR KEY format.), the Broadcom support.
As peter points out, there are some design decisions in the accelrator token model which preclude FIPS. Integration of a FIPS module under OC is possible, but the integration points need to be much higher up in the actual token stack, because one really needs to be passing encrypted "blobs" as keys to the module and have a true separation of the Module, from the API... Possible, yes, just does not exist today Peter Waltenberg wrote: > There are some things that are "quite hard" problems doing it the other way > round. FIPS certification with the OpenSSL engine plugin active is probably > the worst. > With PKCS#11 on top of OpenSSL you have an "industry standard" API, which > most hardware cards support. So you could swap a FIPS certified hardware > card with a FIPS certified PKCS#11 on top of OpenSSL. Using OpenSSL with > the engine code underneath doesn't make much sense in this context. > > Note that IBM does have an open source PKCS#11 which sits on top of > OpenSSL, search for opencryptoki. That doesn't solve the FIPS problem > though due to some details of it's design. > > There are downsides in PKCS#11, various vendors have interpreted the > standard in their own unique manner - so even though it's "standardized", > you still need some implementation specific code to function across vendor > implementations. It also has more (a lot more) setup overhead than OpenSSL > and although the user API isn't bad to implement, the provider side is > painful. > > I can guarantee it's feasible, but it is a lot of work. > > Peter > > > > > > > From: "Victor B. Wagner" <[EMAIL PROTECTED]> > > > > To: openssl-dev@openssl.org > > > > Date: 19/11/2007 20:27 > > > > Subject: PKCS#11 wrapper around OpenSSL > > > > > > > > > I was asked by one user if we are planning to provide PKCS#11 module, > based on OpenSSL (it was in the context of adding GOST algorithms > support to the Mozilla-based software). > > I doubt is this solution is technically feasable. > > As far as I know, most people do it other way around - write interfaces > which allow to USE PKCS#11 modules from within OpenSSL. I've seen at > least two engines which interface external PKCS#11 modules, and both are > incomplete, so if there is a PKCS#11 module which implements new public > key algorithm, they wouldn't allow to use it. > > But question is - is it a good idea to write PKCS#11 module which uses > OpenSSL (with all its engine support) for cryptography and supports > everything OpenSSL supports. > > I haven't studied PKCS#11 specification in great detail - it is very huge. > From the first glance it looks like just a big enough coding effort - > OpenSSL contains all neccessary cryptography routines and ASN.1 support > to provide PKCS#11 interface. > > May be someone on this list hav dug a bit deeper in the PKCS#11 > specification and can give more arguments pro or contra? > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
