TheLuna PED is an authentication device to permit access to the administrative interface of the PED-authenticated HSM. Multi-factor (PED) authentication is only available with the Luna S series. The PED client and server are software components that allow the HSM PED to communicate via a Transmission Control Protocol/Internet Protocol (TCP/IP) network. The PED server resides on the host computer where a remote-capable Luna PED is USB connected. The PED server client resides on the system hosting the HSM, which can request PED services from the PED server through the network connection. Once the data path is established and the PED and HSM communicate, it creates a common data encryption key (DEK) used for PED protocol data encryption and authenticates each other. Sensitive data in transition between a PED and HSM is end-to-end encrypted.
Understanding What a PED Key is and Does
A PED is an electrically programmed device with a USB interface embedded in a molded plastic body for ease of handling. Specifically, a PED Key is a SafeNet iKey authentication device model 1000 with FIPS configuration. In conjunction with PED 2 or PED 2 Remote, a PED Key can be electronically imprinted with identifying information, which it retains until deliberately changed. A PED Key holds a generated secret that might unlock one or more HSMs.
That secret is created by initializing the first HSM. The secret can then be copied (using PED 2.x) to other PED Keys for backup purposes or to allow more than one person to access HSMs protected by that secret. The secret can also be copied to other HSMs (when those HSMs are initialized) so that one HSM secret can unlock multiple HSMs. The HSM-related secret might be the access control for one or more HSMs, the access control for Partitions within HSMs, or the Domain key that permits secure moving/copying/sharing of secrets among HSMs that share a domain.
The PED and PED Keys are the only means of authenticating and permitting access to the administrative interface of the PED-authenticated HSM. They are the first part of the two-part Client authentication of the FIPS 140-2 level 3 compliant SafeNet HSM with the Trusted Path Authentication. PED and PED Keys prevent key-logging exploits on the host HSM. The authentication information is delivered directly from the hand-held PED into the HSM via the independent, trusted-path interface. Users do not type the authentication information on a computer keyboard, and the authentication information does not pass through the computer’s internals, where malicious software could intercept it.
The HSM or Partition does not know PED Key PINs, the PIN and secret are stored on the PED key. The PIN is entered on the PED and unlocks or allows the secret, stored on the PED key, to be presented to the HSM or Partition for authentication. The PED does not hold the HSM authentication secrets. The PED facilitates the creation and communication of those secrets, but the secrets themselves reside on the portable PED Keys. An imprinted PED Key can be used only with HSMs that share a particular secret, but PEDs are interchangeable.
Types of PED Roles
PED Keys are generated with a specific role in mind. These are determined when certain events take place on the HSM. Using these roles, a quorum of M of N PED Keys can be created, where M is the number of keys necessary to complete run a command as that role and N is the total number of keys created. The following roles are the types of roles that can be created on a Luna HSM:
Security Officer – SO
The first actions with a new SafeNet HSM involve creating an SO PIN and imprinting an SO PED Key. A PED PIN (an additional, optional password typed on the PED touchpad) can be added. SO PED Keys can be duplicated for backup and shared among HSMs by imprinting subsequent HSMs with an SO PIN already on a PED Key. The SO identity is used for further administrative actions on the HSMs, such as creating HSM Partition users and changing passwords, backing up HSM objects, and controlling HSM Policy settings. It is recommended that a quorum of 3/7 be used with Blue keys.
Partition User or Crypto Officer
HSM Partition User key. This PED Key is required to login as the HSM Partition Owner or Crypto Officer. It is needed for Partition maintenance, creation, and destruction of key objects, etc. The local portion of the login is necessary to permit remote Client (or Crypto User) access to the partition. A PED Key Challenge (an additional, optional password typed in LunaCM) can be added. Black User PED Keys can be duplicated and shared among HSM Partitions using the “Group PED Key” option. It is recommended that a quorum of 3/7 be used with Black keys.
The Crypto User has restricted read-only administrative access to application partition objects. The challenge secret generated by the Crypto User can grant client applications restricted, sign-verify access to partition objects. It is recommended that a quorum of 3/7 be used with Gray keys.
Key Cloning Vector (KCV) or Domain ID key
This PED Key carries the domain identifier for any group of HSMs for which key-cloning/backup is used. The red PED Key is created/imprinted upon HSM initialization. Another is created/imprinted with each HSM Partition. A cloning domain key carries the domain (via PED) to other HSMs or HSM partitions to be initialized with the same domain, thus permitting backup and restore among (only) those containers and tokens. The red Domain PED Key receives a domain identifier the first time it is used, at which time a random domain is generated by the HSM and sent to both the red Domain key and the current HSM Partition. Once imprinted, that domain identifier is intended to be permanent on the red Domain PED Key – and on any HSM Partitions or tokens that share its domain. Any future operations with that red Domain PED Key shall copy that domain onto future HSM Partitions or backup tokens (via PED) so that they are able to participate in backup and restore operations. Red PED Keys can be duplicated for backup or multiple key copies. It is recommended that a quorum of 3/7 be used with Red keys.
The audit is an HSM role that takes care of audit logging under independent control. The audit role is initialized and imprints a white PED Key without the need for the SO or another role. The Auditor configures and maintains the audit logging feature, determining what HSM activity is logged and other logging parameters, such as rollover period, etc. The purpose of the separate Audit role is to satisfy certain security requirements while ensuring that no one else – including the HSM SO – can modify the logs or hide any actions on the HSM. The Audit role is optional until initialized.
PED Key Management Best Practices
Number of off-site full sets
Does the organization intend to use common authentication for many Luna HSMs? There is no limit. The authentication secret on a single blue SO PED Key, for example, can be used with as many HSMs as they like. However, if the organization wishes to limit the risk of compromising a common blue PED Key, they will need to have groups of HSMs with a distinct blue PED Key for each group. Each time the organization initializes, the HSM (via the PED) allows them to “Reuse an existing keyset” – make the current HSM part of an existing group that is unlocked by an already-imprinted PED Key (or an already-imprinted M of N keyset) – or to use a fresh, unique secret generated by the current HSM.
Number of HSMs per group
That will tell the organization the number of groups and how many different blue PED Keys they need. Now double that number, at least, to allow off-premises backup copies to be kept in secure storage if one is lost or damaged. In most cases, the contents of an HSM are of some value, so at least one backup per blue PED Key must exist. If the organization has only one blue PED Key for a group of HSMs, and that PED Key is lost or damaged, the HSMs of that group must be re-initialized (all contents lost) and a new blue PED Key imprinted.
One for One
The organization might prefer a separate blue SO PED Key containing a distinct/unique Security Officer authentication secret for each HSM in their system. No single blue PED Key can unlock more than one HSM in that scenario. The number of blue keys they need is the number of HSMs. Now double that number to have at least one backup of each blue key.
Many for One or M of N (Recommended)
Does the organization’s security policy allow them to trust its personnel? Perhaps the organization wishes to spread the responsibility – and reduce the possibility of unilateral action – by splitting the SO authentication secret and invoking multi-person authentication. Choose the M of N option so that no single blue PED Key is sufficient to unlock an HSM. Two or more blue PED Keys (their choice, up to a maximum of 16 splits of each SO secret) would be needed to access each HSM. Distribute each split to a different person, ensuring that no one person can unlock the HSM.
Partition BLACK PED Keys
Each HSM can have multiple partitions. The number depends upon their operational requirement and the number the organization purchased, up to the product maximum per unit per HSM. Each partition requires authentication – a black PED Key.
The organization has all the same options for the blue SO PED Key(s) – the organization shall have at least one backup per primary black PED Key. The organization might have multiple partitions with a unique authentication secret; therefore, each would have a unique PED Key. Or, the organization might elect to group their partitions under common ownership so that groups of partitions (on one or more HSMs) might share black PED Keys.
As with the SO secret, the organization can also elect to split the partition black PED Key secret by invoking the M of N option (when prompted by the PED for “M value” and “N value” – those prompts do not appear if the organization chose to “Reuse an existing keyset” at the beginning of the partition creation operation).
Domain RED PED Keys
Each HSM has a domain. Each HSM partition has a domain. That domain is carried on a red PED Key and must be shared with another HSM if the organization wishes to clone the HSM content from one to another, for example, when making a backup.
Domains must match across partitions for the organization to clone or back up their partitions or assemble HSM partitions into an HA group.
For the red PED Keys, the organization can make arrangements regarding uniqueness, grouping, M of N (or not), etc.
Other PED Keys
The organization might have orange PED Keys if they are using the Remote PED option (orange Remote PED Keys (RPK) containing the Remote PED Vector (RPV)). The organization might have white PED Keys if they invoke the Audit role Audit role option (white Audit PED Keys containing the authentication for the Auditor, who controls the audit logging feature). The organization can invoke M of N, or not, as they choose, which affects the number of orange or white PED keys that they must manage.
Orange Remote PED Keys and white Audit PED Keys can be shared/common among multiple HSMs and PED workstations, just like all other PED Key colors.
All other PED Key roles allow them to overwrite any key (any color) with a new secret. A warning is given if a key is not blank, but the organization can choose to overwrite or pause. At the same time, the organization finds an empty or outdated key (“outdated” in this case means a previously imprinted PED Key that they have made irrelevant by re-initializing an HSM or deleting/re-creating a partition, or other activities that make the secret contained on a particular PED Key no longer relevant; PED Keys do not “age” and become invalid during their service life – only deliberate action on an HSM would cause the secret on a PED Key to become invalid).
With all of the above in mind, it is not possible to suggest one “correct” number of PED Keys for their situation. It depends upon the choices that the organization makes at several stages. In all cases, we repeat the recommendation to have at least one backup in case a PED Key (any color) is lost or damaged.