Show the Table of Contents
What is initialization? (PED-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:
- "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>.
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:
- 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. 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:
- 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 Luna SA with PED (Trusted Path) Authentication, the 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 Luna 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 non-Trusted Path 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.
Initializing
- Your Luna PED must be
connected with "Awaiting command..." showing on its display.
- When you issue the hsm
init command, the HSM passes control
to the Luna 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).
- Luna 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.
- Luna 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.
- Luna PED checks the
key you provide. If the PED Key is not blank, and your answer to "...reuse an existing keyset" was "Yes", then Luna 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, Luna PED asks "Are you sure...".
- Assuming that you are using a new secret, and not reusing an existing one, Luna 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 "About M of N" for details).
- Luna PED asks if you wish
to use a PED PIN (an additional secret; "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).
- Luna 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, Luna 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 Luna 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.
Logging In, Once You Have Initialized
- To login, you issue the
hsm login command at the lunash:> command line. Control is passed
to Luna 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 via the Trusted Path 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), you type it on the PED keypad,
Luna 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/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.
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).
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. You are prompted by Luna 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.
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 (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.
See Also
Show the Table of Contents