PED-authenticated HSM Planning
Planning for configuration of a PED-authenticated SafeNet Luna HSM involves a number of layered, interlocking considerations that should be carefully thought through, in advance. You must determine:
>Whether the HSM authentication secrets should fall under your organization's rules for password change cycles. For example, it could be a major undertaking to change passwords for all PED keys and their backup copies every couple of months.
>Your backup policy for PED keys:
•How many copies of each PED key should exist
•How they should be stored (on-site and off-site)
•Who has control of the backup copies of your HSM authentication
>HSM and partition text labels, in keeping with your organization's requirements.
>Whether it is necessary or desirable to have split-secret, quorum or multi-person access control (MofN) for any or all of the roles and secrets of the HSM.
>Whether it is necessary or desirable to invoke "something you know" secrets (PED PINs) in addition to the "something you have" PED key for any or all of the roles and secrets of the HSM.
>If PED PINs are used, how your organization's security policy deals with the departure or replacement of personnel who know the PED PINs.
>Which person or role within your organization will hold the PED key(s) and passwords for each role:
•SO of the HSM
•SO of each application partition
•Crypto Officer and Crypto User
•Auditor (optional)
•Cloning Domain(s),
•RPK (for optional Remote PED operation)
>How PED keys should be physically identified (which one is which copy), especially if you have invoked quorum access control, or MofN.
PED Key Planning
Plan your PED key options and choices before you begin the actions that will invoke PED keys.
The various PED keys contain secrets that are created by an HSM, and are imprinted on the PED key at the time that a triggering action is called - for example, both the HSM and a blue SO PED key are imprinted with the HSM SO secret at the time the HSM is initialized.
Optionally, the PED dialog allows you to present a key with an existing secret (of the appropriate type for the current action) that was previously created by this HSM or by some other HSM. In that second case, the secret from the key is imprinted on the HSM, and that key can now unlock its function on both the previous HSM and the current HSM. This can be repeated for any number of HSMs that you wish accessible by the one secret.
PED Prompts
Some questions/prompts from the PED when any key/access secret is first invoked are:
Reuse
>No: You wish to have the current HSM generate a new secret and imprint it on the PED key
>Yes: You wish to accept an old secret from the currently inserted PED key, and imprint that secret onto the HSM
If you want this HSM to be accessed by the same secret that accesses this function/role on one or more other HSMs, reuse the PED key secret. Sometimes, it is advantageous to have a single secret for a group of HSMs managed by a single person.
Sometimes, security or operational rules require that each HSM must have a different secret (for the role being configured).
The option to reuse an existing secret applies only within the same type of secret. For example, you cannot tell a partition to accept a secret from a black (Crypto User) PED key if you are setting up domain.
MofN (split-secret, or quorum, access control)
>M=1, N=1: refuse MofN
>N > M > 1: invoke MofN
Invoking MofN splits the current secret over quantity N same-color PED keys, such that quantity M of them will always be needed to assemble the full secret and authenticate that role. You invoke MofN by providing the M value and the N value using the PED keypad, when prompted. MofN is the more secure choice, when you require multiple persons (a quorum) to be present (with their splits of the role secret) in order to access that role and perform its functions. In summary, you would likely have one person whose job it is to perform an HSM role, but would require a quorum of partial-secret holders (M) to let that person access his or her role on the HSM. To ensure that enough partial-secrert holders would normally be available
Overwrite
During create/initialize/imprint events, when the PED has received answers to its preliminary questions, it prompts you to insert a key and press Enter on the keypad. This is the first point at which it actually looks at the inserted key. The PED then tells you what is on the inserted key (could be blank, could be any of several authentication secrets) and asks if you wish to overwrite. This is an opportunity to reconsider the key that you have inserted, before something irreversible happens.
>No: Do not overwrite what was found. Remove the key and go back to the PED prompt.
>Yes: Overwrite the secret on the inserted PED key.
If you say Yes, the PED gives you one more chance to reconsider with the prompt, "WARNING*** Are you sure...". The PED is very thorough about making sure that you do not accidentally overwrite a useful authentication secret.
PED PIN
>No: Press Enter on the PED keypad without entering any digits.
>Yes: Type a minimum of four digits on the PED keypad and press Enter.
If you type any digits, then the typed digits (the new PED PIN) are XOR'd with the secret from the HSM, before the combined secret goes onto the PED key. This means that the secret on the PED key is not identical to the secret from the HSM, so in future you must always type those PED PIN digits to reverse the XOR and present the HSM with the secret it is expecting.
With a PED PIN applied, the secret for that role is now two-factor - "something you have" (the version of the secret that is imprinted on the key) and "something you know" (the secret that you type in, to be XOR'd with the contained secret).
Duplicate
>Yes: Duplicate the secret imprinted on the current PED key onto another PED key.
>No: Do not duplicate the secret.
You should always have duplicate keys for each role (or duplicate MofN sets, per role, if you chose to invoke the MofN split), so that you can have at least one off-site backup, and an on-site standby or backup set as well. Your security and operational policies will dictate how many sets you need.
HSM Initialization and the Blue SO PED Key
The first action that invokes Luna PED is HSM initialization.
When you initialize, you are creating an SO (security officer) identity and space on the HSM. In most cases, this is an administrative position and the only keys or objects that are ever stored there are system keys, not user keys. The SO sets policies for the overall HSM, and creates partitions.
When creating an access secret for the SO, you are creating a secret for an administrator who sets up the HSM and is rarely needed thereafter. You might have a single person who has the job of overseeing several HSMs, in which case, only the first HSM creates a secret to imprint on a blue PED key. The second, and all future HSMs to be administered by that person (or role/job in your organization) would accept that secret from a provided blue PED key, rather than creating their own unique SO PED keys. In that situation, you would choose to "Reuse an existing keyset" when initializing every HSM after the first one.
Alternatively, you might have a very compartmentalized organization where a separate individual must have administrative authority over each HSM, so in that case you would use blank blue keys each time you initialized a new HSM, and each HSM would imprint its own uniquely generated SO secret onto a unique blue key. As well, you would have the opportunity to apply PED PINs to any or all of the unique SO PED keys.
If your organization enforces a policy of password changes at certain intervals, or at events like firings and personnel turnover, then you have options and requirements - you might need to change the secret on the PED key (hsm changepw command) or you might satisfy the password-changing requirement by simply changing the PED PIN.
Furthermore, when you initialize an HSM with a new secret, you have the opportunity to split that secret using the MofN feature. Consider how complicated your administration and key-handling/key-update procedures should be.
Before you begin the HSM init process, have your blue PED keys ready, either with an existing SO secret to reuse, or blank (or outdated secret) to be overwritten by a unique new SO secret generated by the HSM. At the same time, you must also have appropriate red PED keys ready, because assigning/creating a cloning domain for the HSM is part of the HSM init process. See HSM Cloning Domain and the Red Domain PED Key.
HSM Cloning Domain and the Red Domain PED Key
All the points, options, decisions listed above for the SO key apply equally to the Cloning domain key, with two exceptions.
1.You must apply the same cloning domain secret to each HSM that is to backup and restore HSM configuration data to one another. By maintaining close control of the red PED key, you control which HSMs the current HSM can clone to.
2.There is no provision to reset or change a cloning domain. An HSM domain is part of an HSM until it is reinitialized. An HSM partition domain is part of an HSM partition for the life of that partition.
Before you begin the HSM initialization process, have your red PED keys ready, either with an existing cloning domain secret to reuse, or blank (or outdated secret) to be overwritten by a unique cloning domain secret generated by the HSM. See Domain Planning.
Partition Security Officer Blue PED Key
The Partition SO also has a blue PED key. Once the partition is initialized, the Partition SO administers all partition policies, and initializes the Crypto Officer role. The blue PED key for a partition (or group of partitions):
>Allows the holder to log in as the Partition SO to perform administrative tasks on the partition
>Allows the holder to Activate the partition - applications can then present the partition challenge secret and make use of the partition.
When a partition is initialized and a blue PED key imprinted, you are prompted to provide a domain for the new partition. At your option, your partition can:
>Take on the same cloning domain (red PED key) as the HSM in which it resides.
>Take on a new, unique cloning domain, generated by the HSM at partition creation.
>Take on a cloning domain from an existing, imprinted red PED key that already holds the domain secret for another partition - this is how you allow the new partition to accept objects from a Backup HSM or to be part of an HA group.
Regardless of whether the HSM (SO space) and the partition share a domain, it is not possible to copy/clone objects between the two. A shared domain between partitions allows you to clone between/among those partitions, and to make such partitions members of a High Availability group. All members of an HA group must share a common cloning domain.
Before you begin the partition initialization process, have your blue PED keys ready, either with an existing Partition SO secret to reuse, or blank (or outdated secret) to be overwritten by a new Partition SO secret generated by the HSM. At the same time, you must also have appropriate red PED keys ready, because assigning/creating a cloning domain for the partition is part of the partition creation process. See HSM Cloning Domain and the Red Domain PED Key.
Crypto Officer Black PED Key
The Crypto Officer secret on the black PED key allows Read-Write access to the contents of the partition, for performing cryptographic operations. If the partition is Activated, the black PED key secret is cached, and applications can access the partition by providing a partition challenge secret set by the Partition SO (and subsequently changed by the CO).
Crypto User Gray PED Key
The Crypto User secret on the gray PED key allows Read-Only access to the contents of the partition, for performing cryptographic operations. If the partition is Activated, the gray PED key secret is cached, and applications can access the partition by providing a partition challenge secret set by the Crypto Officer (and subsequently changed by the CU).
Remote PED Orange PED Key (RPK)
This key is not tied to a fundamental activity like initializing an HSM or creating a partition. Instead, if you don't expect to use the Remote PED option, you never need to create an orange PED key.
If you do have a SafeNet PED, and want to use it for remote authentication, then the HSM and the PED that is remotely hosted must share a Remote PED Vector (RPV). The RPV is generated by the HSM when you instruct it to set a PED vector and imprinted onto an orange PED key, or it is accepted from an existing Remote PED key and imprinted onto the HSM.
When you invoke
Before you begin the PED vector initialization process, have your orange PED keys ready, either with an existing RPV secret to reuse, or blank (or outdated secret) to be overwritten by a unique RPV secret generated by the HSM. The RPV can be initialized with a locally connected PED, or remotely, using a one-time numeric PIN for authentication. After that, you can take the orange PED key (and your other PED keys for that HSM) to any host anywhere that has PEDserver running and has a SafeNet PED attached. See About Remote PED in the Administration Guide for directions.
Auditor White PED Key
The Audit role is completely separate from other roles on the HSM. It is optional for operation of the HSM, but might be mandatory according to your security regime. The Audit role can be initialized at any time, and does not require that the HSM already be initialized.
When you invoke audit init, to create/imprint an Audit role secret, the PED prompt sequence is similar to the sequence for the blue, black, or gray PED keys, with the same questions about reuse, MofN, duplicates, etc.
Before you begin the Audit init process, have your white PED keys ready, either with an existing Auditor secret to reuse, or blank (or outdated secret) to be overwritten by a unique new Auditor secret generated by the HSM.
