Show the Table of Contents

NTLS Keys in Hardware or in Software

In this context, "in hardware" means inside the HSM, while "in software" means on the appliance's hard disk, within the file system.

The default for Luna HSM appliances prior to Luna SA 5 has been to have the securing keys for the NTLS link generated by the lunash command sysconf regenCert, and stored in the file system on the appliance's hard disk.

Moving into 'Hardware' (the HSM)

In Luna SA 5.x, it is also possible to create the ssl keys directly in the HSM and store them there, using the lunash command sysconf hwRegenCert.

A third option is to preserve software-created-and-stored keys and transfer them onto the HSM, using the lunash command sysconf secureKeys.

Either of the latter two options requires the creation of a special HSM partition named "Cryptoki User" to store those NTLS keys. This partition must be manually created with lunash command partition create.

Following creation or migration onto the HSM, the partition containing the NTLS keys must be activated with the lunash command ntls activateKeys.

You can verify if the system is using keys in hardware with the lunash command ntls show.

The keys in hardware feature creates a special container "Cryptoki User" to keep the RSA key pair for NTLS. Even though it shows in the partition list, this container is not meant to be managed by customers directly. Once it is created you should never to need touch this partition at all.

If sets of NTLS keys exist in both software (on the appliance's file system) and hardware (inside the HSM), only one set is valid and registered with clients.

Going Back to 'Software'

If you were using hardware secured (stored on the HSM) keys for your NTLS links between clients and appliance, and you decide to go back to using software-stored NTLS keys, you will need to generate new keys and certificates for NTLS, as you cannot move the existing NTLS keys from the "Cryptoki User" partition back to the appliance hard disk.

First, deactivate the "Cryptoki User" partition with the lunash command ntls deactivateKeys.

Then, remove the "Cryptoki User" partition with the lunash command partition delete.

Then, regenerate the NTLS keys and certificates in software with the lunash command sysconf regenCert.

Finally, restart NTLS service with the lunash command service restart ntls.

Additional Notes

Most customers are expected to choose one option or the other (NTLS keys in HSM or NTLS keys on file system) and remain with that. Probably the only situation where you might encounter the above scenarios is in a lab, while trying the options before operational deployment.

If you deploy using one scheme, then wish to change at a later date by regenerating certificates (whether in hardware or in software), you must re-register all your clients with the new certificates.

If you migrate an existing set of keys from software (the file system) to hardware (the HSM), using sysconf secureKeys, you can carry on with your current registrations, because the NTLS keys have not changed. However, you do have to activate the NTLS partition and restart the NTLS service after any restart or power failure.  [This is a limitation of having the NTLS private key in hardware.  NTLS needs to open a session with a known appid that is already created and logged in by admin using “ntls activatekey” command.   Every time the appliance reboots, the admin must issue the ntls command and restart NTLS before any NTLS connections can be established between Clients and their working partitions. ]

Show the Table of Contents