|
Home > |
|---|
You can perform this operation locally or remotely.
The Luna PED automatically detects the active interface that it is plugged into, and defaults to the appropriate mode after the first command is sent to it. The Luna PED waits in either Remote PED-USB mode (if the PED is connected to a USB port) or in its Scanning state (if the PED is connected to an SCP port) until a command is received from the HSM.
•If the PED is directly connected to the HSM via USB port, it enters Local PED-USB mode.
•If the PED is remotely connected to the HSM via remote host, it enters Remote PED-USB mode.
•If the PED is directly connected to the HSM via SCP port, it enters Local PED-SCP mode.
If you need to manually switch between these modes, press < to navigate to the main menu. Then, press 1 to enter Local PED-SCP mode or press 0 to enter Local PED-USB mode.
If you wish to perform this operation remotely, see Remote PED Setup and Configuration
This section describes the following aspects of setup and imprinting your PED keys:
Insert your PED key:
The first question from the PED is whether you wish to "Reuse" an existing SO/HSM Admin authentication secret. This means that you have a PED key from another HSM, or you have a PED key from a previous initialization of this HSM. The PED is asking if you wish to import the secret from that key onto the HSM. Options at this point are:
•You have only fresh blank PED keys that have not been used previously with any HSM (No - do not reuse).
•You have a previously used PED key, but the secret it contains is not one you wish to preserve or reuse (No - do not reuse).
•You have a previously used PED key, with a secret from this HSM, and you don't mind reusing it (Yes - reuse).
•You have a previously used PED key, from another HSM, and you wish to reuse it so that the key can unlock both the current HSM and the other HSM (Yes - reuse).
If you choose to not reuse the content of an existing key, then the secret that the current HSM generated is imprinted onto the key that is currently inserted into the PED.
If you elect to reuse the content of an existing key, then the secret that the current HSM generated is discarded, and the secret from the reused PED key overwrites onto the HSM. This ensures that the PED key and the HSM have the same authentication secret, and the key can unlock the HSM. If the secret on the key was from another HSM that is still operational, then the PED key has become a group PED key that unlocks the equivalent aspects of both HSMs. In this manner, you can include as many HSMs as you wish in a group.
You can reuse an existing secret only for the same type of secret that is currently being requested by the HSM and the PED. If you say Yes to "Would you like to reuse an existing keyset?" while preparing to set the HSM's Security Officer (SO) secret, then you must present a valid, imprinted blue PED key. Any other type, or a blank key, is rejected.
This "group" of HSMs is related only by the convenience of being able to use one PED key to unlock any of them. This "group" concept is not the same as the HA Group concept for high availability.The HSM slots that form an HA group interact with their client(s) via a virtual HSM slot, such that any of the real HSM slots behind the HA group is interchangeable and can be swapped in and out as needed. But members of an HA group do not need to be members of a PED key group. In an HA group, any or all of the members could have the same or different authentication secrets, without affecting the HA function. Only the cloning domain must be identical across all HA group members.
These questions from the PED prompt for M and N values, so that you could set up MofN split-secret, multi-person access control for an extra layer of security when authenticating.
M and N both set to 1 indicate to the PED that you will not invoke the MofN security measure.
If you invoke MofN, two or more of a given color of PED keys (up to a maximum of 16 splits of each secret) would be needed to access that role or that secure function on each HSM.
For example, if you decide that you want 3 different people to be present whenever a particular role authenticates to the HSM, you should also allow a few extra splits of that secret to accommodate accidents, illness, vacations, business travel, or other reasons that would take some key-holders away from the HSM site. Perhaps you settle on 2 additional splits as sufficient additional key-holders.
You have thus specified MofN to be 3 of 5. If this example applied to the HSM SO, then each HSM's SO secret might be split into 5 components or partial secrets imprinted onto a set of 5 blue PED keys, of which any 3 from that set can combine to reconstitute the SO secret, but never less than 3.
The purple bars show N=5 for every choice of M, the orange bars in this example.
•M=N is not recommended because it allows no scope for one of the holders to be unavailable, while still allowing you to access your HSM.
•M=1 is not recommended, because it is no more secure than if there were no splits of the secret - a single person can unlock the HSM role or function without oversight.
•Any choice where N>M>1 is prudent and useful, as it ensures oversight but allows for at least one split-holder to be unavailable, while still permitting authorized access to the HSM roles and functions.
You can elect to split none of the HSM roles and secrets, some of them, or all of them. If you do elect to impose MofN for roles and secrets, you can set different values of M and N, independently per HSM role or secret.
Keeping in mind the need for backup sets, if you impose MofN for some or all secrets, that choice can drastically increase the number of PED keys that must be imprinted, tracked, and managed, while the ability to group authentication secrets across some or all of your HSMs can help reduce the numbers of PED keys in play.
The chart below shows how the two options interact:
It is frequently the case that the HSM and its server(s) are kept in a locked facility and either accessed remotely by secure channels or accessed directly and physically only under specific conditions.
To satisfy these design requirements we have a concept of Partition Activation (See Activation and Auto-Activation on PED-Authenticated Partitions). This allows administrators of the HSM to put it into a state the calling application is responsible for its own connections and sessions with the HSM, without requiring the presence of the operators. This is important when an application or operating system might be rebooted for maintenance, or a power outage and it would be the 3 or 5 management personnel together to present the MofN keys.
To achieve Partition Activation:
•The black PED key(s) is presented in order to set the partition into a state of "open for business". When that is true, clients can connect.
•Clients must still provide their own credentials (certificates were exchanged, to register the link) and present a challenge secret (previously distributed) to enable them to perform cryptographic operations on the partition.
•At any time, the holder of the partition User/Owner black PED keys can close the partition to access (deactivate it) and clients can no longer access the partition, regardless of their registered status and their possession of the challenge secret.
The PED provides the opportunity to add an additional layer of authentication security to the current secret.
A PED PIN is a numeric secret typed on the PED keypad. For two-factor authentication, a PED PIN is "something you know" and is associated with "something you have," or the PED key. The PED PIN is combined with the secret stored on the key, and the resulting PinKey is sent to the HSM. The combined secret-and-PED-PIN is what the HSM recognizes as its unlocking secret.
Press Enter when prompted by the PED. No PED PIN flag is set on the current PED key.
Type in some digits on the PED's keypad. That sequence becomes a PED PIN that must be typed whenever you wish to use that key in future.
Whatever your response, the PED asks you to confirm by typing it in again.
Note: Do not use zero for the first digit. When the leading digit is zero, the PED ignores any digits following the exact PED PIN. An attacker attempting to guess the PED PIN must get the first digits correct, but does not need to know the exact length of the PED PIN. If the PED PIN is started with any digit other than zero, extra digits are detected as an incorrect attempt.
The PED PIN is optional only for the first PED key imprinted at initialization time - if you choose to make duplicates of that PED key, then they all get the flag for the PED PIN (or no PED PIN if you so choose) that you gave for the first key. PED PINs can be invoked for some, all, or none of the PED key types.
If you are using MofN, each member of the MofN key set may have a different PED PIN, just like any regular key.