Thanks for the pointers....
On Mon, Apr 23, 2001 at 06:03:18PM -0700, Geoff Thorpe wrote:
> On Mon, 23 Apr 2001, Bade wrote:
>
> > On Mon, Apr 23, 2001 at 11:40:14AM -0700, Geoff Thorpe wrote:
> > >
> > > Um, could you be more specific, because in various ways and forms this already
> > > *does* exist and is being used by a number of people. In fact, this doesn't even
> > > have much to do with the ENGINE API (although the engine code provides some
> > > extra specifics) ... the RSA, DSA, and DH code all directly support the ability
> > > to provide alternative "methods" with external implementations of these
> > > algorithms - and they do so in such a way that allow the keys to be opaque. That
> > > is, if the "method" can work with private keys inside HSMs rather than in
> > > memory, then OpenSSL doesn't mind.
> >
> > Aha.. That's something I have not been able to figure out a clean way... Can
> > you give me a pointer in the right general direction. I realize that it does
> > not have much to do with the engine code specifically, but it is a logical area
> > where the hooks might be added to generalize it.
>
> Try taking a look at the hw_ncipher.c code - it has support for hardware-based
> private keys. The only real trouble is how to *create* an RSA (or DSA, DH, etc)
> key corresponding to a particular hardware device (ie. corresponding to a
> particular [RSA|DSA|DH]_METHOD). Obviously you can't use PEM_read_PrivateKey or
> some such call because OpenSSL will expect to read a regular private key
> complete with all the private key components. This is where the ENGINE stuff can
> be of assistance - ie. using the ENGINE_load_[private|public]_key() calls allow
> you to get past that problem (again, see hw_ncipher.c).
>
> However, using the ENGINE-based key loading requires that applications *call*
> those functions, normally they do not. :-) I've seen other approaches, including
> creating fake private keys that look like regular private keys (ie. the standard
> software-oriented encoding and decoding works), but the private components
> loaded aren't the real ones, instead their "numbers" contain embedded hints to
> the hardware-specific RSA_METHOD about how to access the private key in
> hardware. This kludge works because any attempt to validate the private key
> components involves doing a private key operation, which of course involves
> calling your method's private key function handlers which notice what's going on
> and act appropriately. That's a pretty ugly thing to try and do though as you
> end up in encoding spaghetti pretty quickly.
>
> Anyway, if you get past that problem (eg. if you're writing your own application
> code and can call any key-load function you like), the rest is pretty easy. Your
> method gets used for all key operations so the fact the private key components
> aren't present in memory shouldn't affect any code except your method
> implementation. Also, the RSA (and other) key structures have an "ex_data"
> member where you can store per-key information specific to your method. Just a
> quick warning though: the init() handler isn't the place to set this up because
> there is no key-information available at the time it gets called. Unfortunately
> you either do your per-key initialisation inside your special key-loading code,
> or you have to code your regular key operation method functions (eg.
> private_encrypt(), etc) to initialise your own data on "first-use". Also, you're
> advised to leave the public key components there rather than figuring you can
> scrub them too, because they tend to get examined from other code for things
> like checking key-sizes, doing padding, etc.
>
> > I've been asked several times to figure out how to hook a PKCS#11 token
> > (regardless of ones personal feelings about PKCS#11) into openSSL. Hooking
> > the "mechanisms" into the very nice engine architecture is pretty straight
> > forward. The problem comes in when having to represent the keys as PKCS#11
> > objects. But it sounds like this may be possible as well...
>
> Hell yeah, should be no problem. My "personal feelings about PKCS#11" (combined
> with a lack of any special motivation otherwise) have prevented me from even
> considering doing this, but if all you need to finish it off is a way to store
> per-key information, then you're sorted quite straightforwardly. Ie. the
> CRYPTO_EX_DATA element ("ex_data") I mentioned before can be used to stash
> information - examples include indexes to private key information, device or key
> handles/contexts, cached authorisation information to make subsequent private
> key operations easier, etc etc etc. I assume you'll always have access to the
> public key data right? In which case, a public (RSA) key, together with the
> RSA_FLAG_EXT_PKEY and RSA_METHOD_FLAG_NO_CHECK flags, and a method that doesn't
> require the private key components, will all work *as* a private key as far as
> the rest of OpenSSL is concerned. The only thing you have to solve is how to
> create that RSA structure with whatever PKCS#11-device information it needs. If
> you're prepared to write your own "RSA_weirdpkcs11_thing_keyload()" function,
> then you have no problems. You could also take the approach of allowing a
> software-load of a regular public key (or load a certificate and pull out the
> public key), and then define a "RSA_weirdpkcs11_public_to_private(....)"
> function that provides the necessary information for the public key to be able
> to do private key operations as well.
>
> The biggest obstacle, as I mentioned, is how to do this in such a way that
> existing applications will work with HSM keys without too much alteration.
> Given existing applications tend to use things like "PEM_load_RSAPrivateKey",
> there's no obvious solution to that yet - but we're getting closer to it. :-)
>
> Cheers,
> Geoff
>
>
>
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Steven A. Bade
AIX E-Commerce/Network Security Cryptographic Strategy and Development Architecture
[EMAIL PROTECTED]
T/L 678-4799
(512)-838-4799
--
To convert from Hogsheads to Cubic Feet - Multiply by 8.4219
"Two-way communication is necessary to proactively facilitate acceptance
and involvement and to get insights about the journey it takes to get where
we want"
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
