Hi there,
On Thu, 8 Feb 2001, Dr S N Henson wrote:
> Personally I'd like to see symmetric support at some point. I like the
> idea of being able to increase security by not keeping secret keys in
> memory but only references to them. Unfortunately that's a bit tricky
> with OpenSSLs current EVP interface and some extensions would be needed.
Yep - in fact at that time I think it will probably be appropriate to
restructure a few things in ENGINE. Specifically it was originally created
to be as thin a layer of code as possible passing directly onto the
underlying RSA/DSA/DH/RAND methods that everyone was familiar with. It was
also supposed to require no memory allocation or deallocation so that the
failure to call an appropriate finish() (existing applications would
obviously not be built for this) didn't leak. However, we're already using
a "load_builtin_engines()" function - specifically to let the linker rule
in or out the extra ENGINE code plus its dependencies on DSO - so I think
there's already an argument there for suggesting we could now have a more
meaningful structure in place. It will certainly need some tidy-up to
support arbitrary lists of implemented algorithms - and how to deal with
the registration of "default engines" and the algorithms they should be
defaults for.
(1) We need EVP_PKEY_METHODs first. :-) (This is where key generation,
loading, saving, etc would go - hopefully it might also handle ASN?)
(2) We'd need to move code towards using EVP abstractions so that the
hooking is possible without hacking. Eg. currently there's a lot of code
calling algorithm-specific functions, such as RSA_*** or DH_***, requiring
the hooks I put into the RSA/DSA/DH code - they work around that by
routing operations back through whatever the default ENGINE for *that*
algorithm is. In fact, in the asymmetric case, there's no choice about
that anyway (see (1) above). This will *not* be possible with symmetric
crypto however - the list of possible algorithms and modes is not only
huge, but it should be extensible.
(3) I think EVP_CIPHER, EVP_MD, and friends will need some work too. :-)
> That kind of thing has been done in the past but I've never liked it.
> What we should really be doing is only storing the public key components
> in the bignum structure and having separate information which contains a
> reference to the private key (engine name, key name and application
> specific information) which is then handled transparently by the
> appropriate routine.
Want to write an ASN1 definition for that Steve? ;-)
> I've been toying with the idea of something like that. We could have a
> specific PEM format for hardware private keys. This might include the
> public key components, engine name, key name and any additional engine
> specific data. Then PEM_*_PrivateKey() should be able to handle it
> largely transparently and applications should be able to use the keys
> even if they aren't ENGINE aware.
>
> One issue with that is the PIN handling though. An application might
> supply a callback for the passphrase entry which we would then need to
> pass through to the appropriate ENGINE. However this doesn't work too
> well with some PIN entry models, for example the case where PIN entry is
> needed every time a private key is used rather than once when it is
> initially loaded.
Yeah, how to do this meaningfully will be tricky (doing it with hacks
would be less painful to begin with but probably doubly painful later on).
Also, callbacks aren't always the way forward, but the PEM (and i2d_, d2i_
functions) give us little choice because they don't provide any return
other than success or failure. Though in this particular case - there's
nothing in principle stopping a ENGINE_ctrl() being used to feed callbacks
through to engines, and callbacks could be invoked not just on key load-up
but also per operation (if desired) by using them inside the engine's own
methods.
Back to that PEM stuff for a moment; I suspect this would be possible, but
applications would have to examine the error stack upon failures to spot
things like "engine not present", "hardware doesn't have the key", "need
to set a PIN/password callback", etc.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
