Corinne Dive-Reclus wrote:
>
>
>
> >
> > CDive> Anyway, any help about key generation (no ENGINE hook
> > CDive> available? cannot dynamically create a key into an ENGINE ?)
> > CDive> and key management will be greatly appreciated.
> >
> > So far, we've extended the collection of engine hooks when there's
> > been more things it could support on the hardware we've been playing
> > with. Since the engines play with hidden data, extending with new
> > hooks isn't too difficult. Perhaps it's time to check what we really
> > should support in an engine and write it a little bit more in stone.
> > Ideas?
> So far, the current ENGINE seems good to me. Your choice to hook
> only asymmetric operations seems reasonnable for a SSL implementation.
> Symmetric keys are only session keys and today do not need the same level of
> protection. Even if the hardware is capable of symmetric operations, it is
> probably to slow to go down to it to perform the operation. The other choice
> you've made to hook either the crypto mechanism (rsa_sign, rsa_priv_dec) or
> the math operation ( rsa_modexp) allows the flexibility to talk to different
> types of hardware from "clever" engine to "pure math" one.
>
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.
> I am still too new in OpenSSL to know what key management features
> are implemented so perhaps the following remarks are irrelevant and in this
> case, let me know:
> - A hardware can contain more than 1 key pair (ours can
> contain several hundreds and can be accessed by several Crypto Applications
> simultaneously).
> - At key pair generation, the engine can be called and
> return a "key name". If flags contains RSA_FLAG_EXT_PKEY, bignum will point
> to a null-terminated string rather than a bignum array.
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.
> - When the key is serialised and saved
> (PEM_write_bio_RSAPrivateKey() ?), we can decide not to encrypt it and
> serialise just the key name.
> - When a private key is to be used, the application reads it
> (PEM_read_bio_RSAPrivateKey() ?) and a rsa_st is rebuilt from it. This
> structure is passed as it is to the ENGINE rsa operation, the engine will
> use the name into rsa_st to identify the key to use into the hardware.
> - Perhaps the key name should identify the ENGINE itself
> like "ENGINE id | key name". Like that by name introspection an application
> can know what key is where.
> - load_private_key won't be necessary except if we want to
> use a key not generated by OpenSSL and already into the hardware. It would
> be greate too if this file format is the same as
> PEM_write_bio_RSAPrivateKey, like that the key can used later as generated
> from OpenSSL ( i.e. probably very useful for read-only devices like
> smartcards for SSL clients).
> - we can provide too a RSA/DSA_delete_private_key.
>
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.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
