|
Home > |
|---|
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 HSM:
•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.
Initialization takes care of the ownership by establishing roles and separations of authority.
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 HSMs with PED (Trusted Path) Authentication, the HSM Security Officer authentication and the Cloning Domain secret are kept on portable physical memory devices called PED Keys ( About PED Keys ). PED Keys can interact with the HSM via the SafeNet PED which provides a protected data path or "Trusted Path". Use of the Trusted Path for authentication prevents observation or interception of passwords such as you would type at a keyboard when seeking access to password authenticated HSMs.
From the hsm init command, the eventual outcome is an initialized HSM, that can be accessed by a specific blue SO PED Key and red Domain PED Key (or the Password authentication equivalents). How you get there can vary slightly, depending upon starting conditions. For this description, we assume a factory-fresh HSM and factory-fresh ('blank') PED Keys. Alternatively, you can run hsm factoryReset (at the local serial console) to place the HSM in a similar "like new" state.
•Your SafeNet PED must be connected to the HSM, either locally/directly, or remotely via Remote PED connection (see About Remote PED), with "Awaiting command..." showing on its display.
•When you issue the hsm init command, the HSM passes control to the SafeNet PED, and the command line (lunash:>) directs you to attend to the PED prompts.
•A "default" login is preformed, just to get started (you don't need to supply any authentication for this step).
•SafeNet PED asks: "Do you wish to reuse an existing keyset?". If the answer is NO, the HSM creates a new secret which will reside on both the HSM and the key (or keys) that is (or are) about to be imprinted. If the answer is YES, then the HSM does not create a new secret and instead waits for one to be presented via the PED.
•SafeNet PED requests a blue PED Key. It could be blank to begin, or it could have a valid secret from another HSM (a secret that you wish to preserve), or it could have a secret that is no longer useful.
•SafeNet PED checks the key you provide. If the PED Key is not blank, and your answer to "...reuse an existing keyset" was "Yes", then SafeNet PED proceeds to copy the secret from the PED Key to the HSM.
•If the key is not blank, and your answer to "...reuse an existing keyset" was "No", then the PED inquires if you wish to overwrite its contents with a new HSM secret. If the current content of the key is of no value, you say "Yes". If the current content of the key is a valid secret from another HSM (or if you did not expect the key to hold any data) you can remove it from the PED and replace it with a blank key or a key containing non-useful data, before you answer "Yes" to the 'overwrite' question. Even so, SafeNet PED asks "Are you sure...".
•Assuming that you are using a new secret, and not reusing an existing one, SafeNet PED asks if you wish to split the new HSM secret. It does this by asking for values of "M" and "N". You set those values to "1" and "1" respectively, unless you require MofN split-secret, multi-person access control for your HSM (See Using MofN for details).
•SafeNet PED asks if you wish to use a PED PIN (an additional secret; see What is a PED PIN? for more info).
•If you just press ENTER (effectively saying 'no' to the PED PIN option), then the secret generated by the HSM is imprinted on the PED Key, that same secret is retained as-is on the HSM, and the same secret becomes the piece needed to unlock the Security Officer/HSM Admin account on the HSM.
•If you press some digits on the PED keypad (saying 'yes' to the PED PIN option), then the PED combines the HSM-generated secret with your PED PIN and feeds the combined data blob to the HSM. The HSM throws away the original secret and takes on the new, combined secret as its SO/HSM Admin secret.
•The PED Key contains the original HSM-generated secret, but also contains the flag that tells the PED whether to demand a PED PIN (which is either no digits, or a set of digits that you supplied, and must supply at all future uses of that PED Key).
•SafeNet PED gives you the option to create some duplicates of this imprinted key. You should make at least one duplicate for backup purposes. Make additional duplicates if your security policy permits, and your procedures require them.
•Next, SafeNet PED requests a red Domain PED Key. The HSM provides a cloning Domain secret and the PED gives you the option to imprint the secret from the HSM, or to use a domain that might already be on the key. You choose appropriately. If you are imprinting a new Domain secret, you have the same opportunities to split the secret, and to apply a PED PIN "modifier" to the secret. Again, you are given the option to create duplicates of the key.
•At this point, the HSM is initialized and SafeNet PED passes control back to the appliance (lunash:> ).
•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 role login command at the luncm:> command line. Control is passed to SafeNet PED.
•The PED prompts for the blue SO PED Key. You insert that PED Key.
•If there was no PED PIN (you chose none at initialization time), then the PED combines the secret on the blue key with ... nothing... and the unchanged secret is passed to the HSM. The HSM recognizes the secret and logs you in. This assumes that you provided the correct blue PED Key.
•If there was a PED PIN (you added one at initialization time), then you type it on the PED keypad, SafeNet PED combines the secret from the key with the digits that you type, and the modified secret is passed to the HSM. The HSM recognizes the modified secret and logs you in. This assumes that you provided the correct blue PED Key and the correct PED PIN digits.
•If you type an incorrect PED PIN, what the HSM receives is much the same as if you presented a wrong PED Key. The HSM checks what it receives against what it expects, finds a mismatch and records a bad-login attempt against the bad-login counter. You have two more chances to present the correct SO 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.
If you had also elected to split the login secret when you initialized, then the above sequence would need quantity M different blue keys from the set of quantity N, in order to reconstruct the needed secret (along with PED PINs, or not, for each partial-secret blue key).
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. You are prompted by SafeNet PED to insert the currently-valid blue SO PED Key (it is not changed by a soft init; it is needed only to validate your right to perform the soft initialization) and press [Enter] on the PED keypad. No other interaction is needed.
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 (or generate) new blue and red key data.
The hard init is always the safest approach to take, since you can always choose to use the existing blue and red PED Keys and imprint those onto the factoryreset HSM - 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 (in a soft init, the PED does not prompt for insertion of the red PED Key, since the HSM already has a domain). 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.