|
Home > |
|---|
(This page is not instructions. This page is background information that might help make some operations more obvious.)
For SafeNet HSMs, there are two kinds of initialization:
•"hard" init - occurs when the HSM is in a factory [re]fresh state
•"soft" init - occurs when the HSM is not in factory [re]fresh state
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.
Coming from the factory, the SafeNet Network HSM:
•has network settings left over from our manufacturing process and not recommended for your production network
•has only default certificates in place
•has an undifferentiated HSM with no associations or ownership declared
•has not yet had virtual HSMs (HSM Partitions) created or assigned
•has not been introduced to the Clients (your Clients) with which it will be working.
Network setup of the appliance takes care of the first two items on that list. See Configure the IP Address and Network Parameters in the Configuration Guide.
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:
•you set up Security Officer or HSM Administrator (two names for the same entity) ownership of the HSM, and
•you apply a cloning domain to permit secure backup and restore, and secure cloning/replication of HSM objects to other HSMs.
For SafeNet Network HSM 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.
•Issue the hsm init command, with a suitable HSM label - also include the HSM's SO password and a string for cloning domain (the domain determines with which other HSMs your HSM can clone objects).
•At this point, the HSM is initialized .
•Further actions are needed to prepare for use by your Clients, but you can now log in as SO/HSM Admin and perform HSM administrative actions.
•To login, you issue the hsm login command at the lunash:> command line.
•When prompted, type the password. The HSM checks what it receives against what it expects. If it finds a mismatch, it records a bad-login attempt against the bad-login counter. You have two more chances to present the correct SO/HSM Admin authentication, or the SO is locked out and the HSM must be re-initialized (where it is zeroized and all contents are gone) before it can be used again.
•When you login successfully, the bad-login counter is reset to zero.
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.
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 SafeNet 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.