[Date Prev][Date Next]
Hardware Crypto Support w/ openssl-engine (ITS#1339)
Full_Name: blair christensen.
OS: Solaris 8
Submission from: (NULL) (126.96.36.199)
We are currently running OpenLDAP on several Solaris/Sparc servers, which of
course do not provide a /dev/(u)random. In the past we have used the ANDIrand
package which provides a /dev/(u)random (quality of which I'm not entirely
certain). Now, however, we are purchasing hardware crypto cards to use on all
of our machines.
The crypto cards do not provide a /dev/(u)random interface, but instead, using
openssl-engine, you can tell openssl to use a specific hardware engine (in our
case "cswift" but there are a few others as well) at run time (*not* compile
time). The default is to use the "openssl" engine, which basically tells
openssl to behave normally, using a /dev/(u)random if present.
I have currently made changes such that slapd (based upon changes in
libraries/libldap/tls.c and a few other places), if given a TLSCryptEngine
configuration option in slapd.conf, will use the hardware crypto and this seems
to work. However, I've realized that using my current methods, everything in
$PREFIX/bin, $PREFIX/libexec, and $PREFIX/sbin would probably need to be
explicitly modified to support the hardware crypto engine. That is *ugly*.
Which brings me to my question/RFC: Do you have any suggestions/preferences for
how I implement this (as I intend to submit all of my patches) such that is
general enough to work across all binaries? Should the crypto engine be set at
compile time in libraries/libldap/tls.c (with a possible run time directive to
override this) or should I take a different approach? Perhaps an option in
ldap.conf for the client tools to explicitly set the engine to use?