Re: [OpenCA-Devel] New HSM - Problems

[Martin B. <vc...@cy...>]

Hi,

> Anyway I have a problem when it comes to the CA/RA Operator's certifica=
tes
> and KeyPairs. I would like not to use the HSM partition (i.e. generate =
the
> Key within the HSM) for RA/CA because due to configuration options, it
> could be impossible to export them. Therefore I need a way to use
> different
> tokens when using the CA key or "other" keys... do you have encountered
> the same problem with other HSMs? How did you solved this ?

I think it's more a feature than a bug that a key cannot be exported
from the HSM. Why do you want it to be exportable?
If this is really desired you could create the key outside the HSM,
e. g. with OpenSSL and import the RSA key into the module, but I don't
think this is how a CA should handle key material...

Concerning RA officer keys I think these should not be kept in the
HSM but in possession of the RA officer. Either in software or in
a hardware token, depending on the desired security level.
With the nCipher hardware it is possible to specify Engine support
for RSA key generation, in this case the module's RNG is used for
RSA key generation which in turn is done in software. I think this
is quite sensible and OK for user keys.

> In detail, the HSM need to use a command line tool to generate internal=
ly
> a keypair and the openssl to generate the reference to the key (in the
> normal cakey.pem file).

This is similar to nCipher HSMs.

> If I use the same command to generate CA/RA
> keypairs

> the problem is that:
> 1- It may be impossible to export the keys (depends on the HSM config)
>
> 2- Each key is identified by a label assigned during the creation proce=
ss
>     it is not possible to create more keypairs with the same label, any=
way
>     in the token.xml configuration I have put only one KEY_ID option (t=
he
>     one to be used with the CA)
> The idea is to not modify the genKey command, instead, to have a way
> within
> the module which enables the two different behaviours.
> The fastest solution would be the adoption of ad additional parameter t=
o
> the keyGen command in Tokens to identify the key "scope", e.g. CA/RA/Ot=
her
> and then having the module to perform different actions.

I'd suggest to configure the CA token to use the HSM, that way you can
use HSM protected key for certificate and CRL issuance.
The default token could be configured to use the OpenSSL (software)
module but use the OpenSSL -engine option for genrsa to utilize the
hardware RNG of the module.

cheers

Martin