You are here: Administration & Maintenance Manual > HSM Administration > Authenticating - PED and Password > Password Authentication (option) > What is initialization?

What is initialization? (Password-authentication)

(This page is not instructions. This page is background information that might help make some operations more obvious.)

For Luna HSMs, there are two kinds of initialization:

Both are launched by the same command, hsm init -l <hsmlabel>.

 

 



Condition/Effect

Soft init

 

Hard init 

 

 SO authentication required?   Yes  No
 Can set new HSM label   Yes  Yes
 Creates new SO identity   No  Yes
 Creates new Domain   No  Yes
 Destroys partitions   Yes  No (none exist to destroy) *
 Destroys SO objects   Yes  No (none exist to destroy) *

* hsm factoryReset was performed, and destroyed partitions and objects, before the hard init... otherwise, it could not be a hard init.

 

 

Hard Initialization

Coming from the factory, the Luna SA:

Network setup of the appliance takes care of the first two items on that list. That is described elsewhere ( "Configure IP and Network Parameters" ).

Initialization takes care of the third item, which pertains specifically to the HSM portion of the appliance.

When you initialize a new (or factoryReset) HSM, several things happen, but the most important ones from your operational perspective are:

For Luna SA with Password Authentication, all authentication secrets, including the Security Officer authentication and the Cloning Domain secret are text strings that you type in at a keyboard (either via local serial console, or via SSH session).

From the hsm init command, the eventual outcome is an initialized HSM, that can be accessed by a specific SO password and Cloning Domain . How you get there can vary slightly, depending upon starting conditions. For this description, we assume a factory-fresh HSM. Alternatively, you can run hsm factoryReset (at the local serial console) to place the HSM in a similar "like new" state.

Initializing

Logging In, Once You Have Initialized

 

Soft Initialization

The above description covers the situation where your HSM is new from the factory, or where you have recently run hsm factoryReset command. The result of hsm init is different if the HSM is not in factory reset state.

If you run hsm init -l <hsmlabel> on an HSM that is currently in initialized state, then you are performing a "re-initialization", or a soft init, and not a full, hard initialization.

In this situation, hsm init -label <hsmlabel> means remove any partitions (and their contents) and erase any token objects that reside in SO space on the HSM. The SO identity is preserved, as is the cloning domain. The HSM label can be any string - you do not need to retain the previous label - you can change the previous label with this command. The password is required, to prove that you are entitled to perform the initialization.

Why choose Hard Init or Soft Init?

A good example of a situation where you might generally prefer to perform soft initialization is when provisioning with Crypto Command Center for virtual clients. When a client (virtual or otherwise) is done with a Luna HSM resource - say, a partition or a group of partitions - the resource must be cleared (removed and re-created, re-deployed) for the next customer.

Either kind of initialization operation takes care of destroying the partitions and contents, but a soft init leaves the SO identity and the cloning domain intact. The HSM remains within its established environment, under control of the Crypto Command Center administrator, who has no need to change SO and domain, but who does wish to create new user partitions for the next deployment.

A hard initialization (factoryreset followed by init) prepares the HSM for any environment, since the factoryreset removes any traces of the previous environment (SO and domain) and makes the HSM ready to accept new authentication.

The hard init is always the safest approach to take, since you can always choose to use the existing password and cloning-domain strings - emulating the end result of a soft init, but if you have security-policy reasons for not allowing the SO or domain to remain, the hard init addresses those reasons.

Similarly, if you had been validating an HSM in a laboratory environment before deploying it to a production HA environment, a soft init would leave the HSM with the lab domain in place. The domain used by your production HA group of HSMs would not match, thereby preventing the new HSM from cloning with that group (so no HA, no synchronization). A hard init of the new HSM when introducing it to the HA group would ensure that it was initialized with the domain needed to participate in that HA group.

 

See Also