Thales nShield HSM for EJBCA

News Posted by: dymar on 05/03/2018 10:42

Thales nShield HSM for EJBCA


 

EJBCA have support for THALES nShield HSM (nShield Edge, nShield Solo, nShield Connect). Each HSM has it’s own interface for key generation and maintenance, specific to the HSM and independent of EJBCA. You should make sure you are familiar with how your HSM works.

 

When configuring a CA to use a HSM in the administration GUI it is a property field where properties unique to this very HSM is specified. All implemented HSM modules are using the same property keywords to define the identity and the purpose of the keys to be used.

 

These keywords are:

  • certSignKey – the key to be used when signing certificates, can be RSA or ECDSA.

  • crlSignKey – the key to be used when signing CLSs, can be RSA or ECDSA.

  • keyEncryptKey – the key to be used for key encryption and decryption, this must be an RSA key.

  • testKey – the key to be used by HSM status checks, can be RSA or ECDSA.

  • hardTokenEncrypt – the key to be used for hardtoken encryption and decryption. PUK will be decrypted by this key.

  • defaultKey – the key to be used when no other key is defined for a purpose. If this is the only definition then this key will be used for all purposes.

  • pin – optional pin code used for auto-activation of CA token, see below. Not recommended for high security set-ups, but very useful in some cases.

 

You may omit defaultKey if you want to be sure that the right key is used, but then all the other keys must be specified. It’s recommended that the certificate and CRL signing keys are linked to the same key since different keys are rarely supported by verifying applications.

 

When implementing support for a new HSM the ‘KeyStrings’ class could be used to manage the key properties described above. When it is an JCA/JCE API for the HSM it could also be wise to extend the BaseCAToken class.

 

The same activation code must be used for all keys used by a CA.

 

There are four additional key properties that can (optionally) be used when renewing CA keys and to produce roll-over certificates..

  • previousCertSignKey – this is the alias of the previous signature key, as opposed to ‘certSignKey’ which is the current signature key.

  • previousSequence – this is the sequence identifying the previous signature key, as opposed to the current sequence that is held in the CA token. This sequence will replace the current sequence in the caRef field when signing a request with the CAs previous key.

  • nextCertSigningKey – this is the alias of a new generated key on the HSM. When updating a CA signed by an external CA this is used to send a request, but the CA is still active using the old key. When the certificate response is received this key is activate and moved to certSignKey/crlSignKey.

  • nextSequence – this is the sequence identifying the next signature key.

  • Share this