|
Home > |
Appliance Administration Guide > Configuration without One-step NTLS > [Step 1] Planning Your Configuration > PED-authenticated HSM Planning
|
|---|
Planning for configuration of a PED-authenticated SafeNet HSM involves a number of layered, interlocking considerations that should be carefully thought through, in advance.
•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.
•Determine your backup policy for PED Keys
–how many copies should exist of each PED Key,
–how they should be stored (on-site and off-site),
–who has control/oversight of the backup copies of your HSM authentication.
•Decide whether application partitions should be owned and administered by the HSM SO (pre-firmware 6.22.0 legacy) or by a partition SO (with firmware 6.22.0 or newer, and the Per-partition SO CUF installed)
•Determine HSM and partition text labels, in keeping with your organization's requirements.
•Determine whether it is necessary or desirable to have split-secret, multi-person access control for any or all of the roles and secrets of the HSM, that is, whether MofN should be invoked.
•Determine whether it is necessary or desirable to invoke "something you know" secrets in addition to the "something you have" PED Key for any or all of the roles and secrets of the HSM, that is, whether PED PINs should be invoked.
•If PED PINs are used, determine, in advance how your organization's security policy deals with the departure or replacement of personnel who know the PED PINs.
•Determine which person or role within your organization will hold the PED Key(s) and passwords for each role
–the SO of the HSM,
–the SO of each application partition (optional),
–the Crypto Officer and Crypto User, and
–the Auditor (optional), as well as
–the Cloning Domain(s),
–the RPK (for optional Remote PED operation),
–the SRK for optional tamper response or Secure Transport.
•Determine how PED Keys should be physically identified (which one is which copy), especially if you have invoked MofN.
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. With the exception of the purple SRK PED Key, all of the other PED Key types can take a newly-created secret that is unique in the world at the time the HSM creates it.
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 (example: allow the SO to log in) 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.
Some questions/prompts from the PED when any key/access secret is first invoked are:
Reuse - do you wish to have the current HSM generate this secret, and imprint it on the PED Key (the "No" or do not reuse option), or do you wish to accept a secret (of the correct type) from the currently inserted PED Key, and imprint that secret onto the current HSM, making that secret common for this HSM and any others that recognize the same PED Key (the "Yes" or do reuse option)?
The decision is: do you wish this HSM to be accessed by the same secret that accesses this function/role on one or more other HSMs? Or do you wish this HSM to have a new, unique secret that is recognized by no previous HSM. 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, so for example you cannot tell a partition to accept a secret from a blue SO PED Key. At partition creation, a partition must be imprinted either with a unique new key that also goes on a PED Key, or with a secret from an already-imprinted black PED Key.
The only exception, among the various PED Keys is the purple SRK PED Key, each of which is unique to its own HSM. No HSM can accept an SRV (the secret on the SRK) from outside. Each HSM creates its own.
MofN - do you wish to split 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. You refuse MofN by setting the M value and the N value both to "1". MofN is the more secure choice, when you require multiple persons to be present (with their splits of the role secret) in order to access that role and perform its functions. No MofN is the more convenient choice, as only one secret-carrying key must be carried and tracked, per role.
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. You can say "No" (don't overwrite what was found ), remove the key, and go back to being prompted to insert a key. If you say "Yes" to overwrite what the PED just told you is on this inserted key, the PED gives you another chance to reconsider: "WARNING*** Are you sure...". The PED is very thorough about making sure that you do not accidentally overwrite a useful authentication secret.
PED PIN - At the point where it has been decided that you are not reusing key content, and you are or are not splitting the new secret across multiple keys, and that you are absolutely certain that you wish to write a new secret on the inserted key, the PED prompts you to type a PED PIN. The PED is about to write onto the key a secret that was just generated by the HSM. If you simply press [Enter] on the PED keypad, without typing any digits, you are providing no PED PIN, and the secret that goes onto the key is the secret as provided by the HSM. If you type any digits, before pressing [Enter] (minimum of 4 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), to make the final secret that unlocks the HSM.
At this point, the key is imprinted. Now the PED inquires if you wish to duplicate the key you just made.
Duplicate - in general, 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 probably an on-site standby or backup set as well. Your security and operational policies will dictate how many sets you need. When the PED prompts to inquire if you wish to duplicate the current PED Key, you should be ready with the knowledge if you already have enough copies of that secret or if you need to make more. The more you make, the more you must track. But you must have enough to satisfy your organization's operational and security protocols.
The above paragraphs explain the meanings of each of the prompts that you would see from SafeNet PED while performing an action (like initialization) that imprints PED Keys with secrets. The following sections discuss some implications of the above choices for specific roles (PED Key colors).
The first action that invokes SafeNet PED (which must be connected, as described in the SafeNet PED option section of the hardware setup chapter) 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 policy 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 then rarely is 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.
Each person who is to act as SO for an HSM must be able to access the appropriate blue PED Key when needed. Either they carry it with them, or they sign it out when they are using it and sign it back into a secure lockup. If PED PINs are in use, then each SO and each SO backup/alternate personnel must know the PED PIN(s) for every HSM in their charge.
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. In this way, you ensure that a certain minimum number of personnel must be present with their blue PED Keys whenever the SO must log in. While making that choice, you should choose "M" to be the smallest number that satisfies the requirement. Similarly, "N" should be large enough to ensure that you have enough "spare" qualified SO split holders that you can assemble a quorum even when some holders are unavailable (such as for business travel, vacations, illness). Just as with a single, non-split SO secret, you can apply PED PINs to each blue key in an MofN set. Consider, before you do, how complicated your administration and key-handling/key-update procedures could become.
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 the next section, below.
All the points, options, decisions listed above for the SO key apply equally to the Cloning domain key, with two exceptions.
First, you MUST apply the same red key Cloning Domain secret to every HSM that is to :
•clone objects to/from each other
•participate in an HA group (synchronization uses cloning
•backup/restore.
By maintaining close control of the red PED Key, you control to which other HSMs the current HSM can clone.
Second, unlike the case of the blue SO PED Key secret and the black Partition Owner/User PED Key secret, there is no provision to reset or change a Cloning Domain. An HSM domain is part of an HSM until it is initialized. An HSM Partition domain is part of an HSM partition for the life of that partition. Objects that are created in an HSM with a particular domain can be cloned only to another HSM having the same domain.
Before you begin the HSM init 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.
All the points listed above for the SO key apply equally to the black PED Key when an HSM partition is created.
The black PED Key Partition Owner/User secret secures the HSM partition to which it is applied, and all contents of the partition.
The black PED Key for a partition (or a group of partitions) :
•allows the holder to log in as the Partition Owner/User to perform administrative tasks on the partition
•set the partition "open for business" by Activating the partition - when a partition is activated, applications can present the partition challenge secret and make use of the partition
When a partition is created, after the black PED Key is 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 (no other partition can share objects with this partition or be configured in HA with this partition, until the newly created domain is shared),
•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)
This is how you control which partitions (on the same or different HSMs) share a domain.
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 an HA group. All members of an HA group must share a common cloning domain.
On an HSM that supports multiple partitions, all partitions could have the same domain, or all could have different domains, or some combination could be in effect.
Before you begin the HSM init process, have your black PED Keys ready, either with an existing Partition Owner or User secret to reuse, or blank (or outdated secret) to be overwritten by a unique new partition Owner 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 the previous section, above.
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 Remote capable SafeNet PED, and want to use it for remote authentication, rather than always having the PED locally connected to the HSM, 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 "ped vector set" or similar command, to create/imprint a Remote PED Vector, the PED prompt sequence is similar to the sequence for the blue or black PED keys, with the same questions/choices for you to make about "reuse" (or a fresh, new secret), about MofN, about duplicates, etc.
Before you begin the PED vector init 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 new RPV secret generated by the HSM. The first time you set an RPV for an HSM, the PED must be locally connected. 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 remote-capable SafeNet PED attached.
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 created 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 or black PED keys, with the same questions/choices for you to make about "reuse" (or a fresh, new secret), about MofN, about 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.
The Secure Recovery Vector is imprinted onto a purple Secure Recovery Key, only if you have invoked SRK. The Master Tamper Key and the recovery components (one of which can be brought outside the HSM and kept on a purple PED Key) are explained elsewhere. What you need to know is that there is no need to create a purple PED Key unless you :
•need to enforce acknowledgment of tamper events by your personnel, before returning the HSM to service, or
•wish to invoke Secure Transport Mode.
When you invoke SRK, to remove one of the MTK recovery secret splits from the HSM and imprint it onto a purple PED Key, the PED prompt sequence DOES NOT include a "reuse" option. The purple PED Key is the only one that is unique to its HSM and cannot be reused. The secret is generated within the HSM and goes onto a purple PED Key (or several, if you choose MofN), but there is no ability for the HSM to accept an already imprinted purple key secret that came from another HSM. SRKs are always unique. That is, you can make as many copies as you wish, but they will work with only one HSM in the world.
Other than that, the PED prompt sequence is similar to the sequence for the blue or black PED keys, with the same questions/choices for you to make about MofN, about duplicates, etc.
Before you begin the SRK process, have your purple PED Keys ready, either a blank key, or outdated secret, to be overwritten by a unique new Secure Recovery Vector generated by the HSM.
In each case, have your materials and notes about your previously-made decisions on hand before you launch a command that invokes key creation or imprinting.
Predetermine which of your personnel will have access to which PED Keys, how many people should be required to perform a given authentication action, whether they will carry their PED Key(s), or will need to retrieve them from a secure lockup for each occasion that they are used, how many backup sets you expect to maintain.
Keep in mind that backups are good, but each backup set must be updated if the operational or master set is changed for any reason.
If your security policies do not require periodic changes to PED Key secrets (possible for any of the other PED Keys, but effectively impossible for red domain PED Keys), and if your physical and procedural security is strong enough, then it is quite possible to just create the set(s) of PED Keys that you need, and then not need to touch them again for years.
By contrast, if your policies demand periodic change, or if you think you might be forced to change PED Key secrets due to personnel departures or other events, then have a clear plan in place about how you will deal with such situations before you create your various PED Key sets.