Luna HSM PED Key Best Practices For End-To-End Encryption Channel

A Luna PED (PIN Entry Device) is the multi-factor authentication device that permits access to the administrative interface of PED-authenticated Luna HSMs. PED Keys are USB-format smartcard tokens that store HSM authentication secrets; they form the first factor of the trusted-path authentication for FIPS 140-2 Level 3 compliant HSM partitions. The PED delivers authentication credentials directly to the HSM via an independent trusted-path channel, bypassing the host computer’s memory and preventing keylogging attacks. Best practice is to use M-of-N quorum PED Key sets, maintain off-site backup copies, and assign each role to separate custodians so no single person can independently access an HSM or partition.

Quick Answer: What Are PED Keys and Why Do They Matter?

PED Keys are the physical authentication tokens that enforce multi-factor, multi-person control over Luna HSM administrative operations. Each key is color-coded to a specific role (SO, Crypto Officer, Crypto User, Domain, Remote PED, Audit); secrets are stored on the key, never in host memory. Authentication information passes from the PED directly to the HSM through an end-to-end encrypted trusted path that bypasses the host OS entirely. M-of-N quorum (typically 3-of-7) splits the secret so no single holder can access the HSM alone. Losing all copies of a key set without a backup forces re-initialization of the HSM and loss of all contents. For HSM deployment context, see our guide on HSMs and Key Management.

What Is the Luna PED and the Trusted Path?

The Luna PED is an authentication device with a USB interface and a keypad, used to permit access to the administrative interface of PED-authenticated HSMs. Multi-factor PED authentication is available with PED-authenticated Luna HSM models. The PED client and server are software components that allow the HSM PED to communicate over a TCP/IP network for remote administration scenarios.

The critical security property of the PED is its trusted path: authentication information is delivered directly from the hand-held PED into the HSM via an independent, trusted-path interface. Users do not type authentication information on a computer keyboard, and the authentication information does not pass through the computer’s internals where malicious software could intercept it. Once the data path is established and the PED and HSM communicate, they create a common data encryption key (DEK) used for PED protocol data encryption. Sensitive data in transit between the PED and HSM is end-to-end encrypted within this channel.

Understanding What a PED Key Is and Does

A PED Key is a USB-format smartcard authentication token (SafeNet iKey 1000 model in FIPS configuration). A PED Key holds a generated secret that unlocks one or more HSMs or partitions. That secret is created during initialization of the first HSM; it can then be copied to other PED Keys for backup or to allow multiple authorized personnel to access HSMs protected by that secret. The secret can also be propagated to other HSMs during their initialization so that one secret unlocks a group of HSMs.

Key points about how PED Keys operate:

• The HSM does not know or store PED Key PINs. The PIN and secret are stored on the PED Key itself. The PIN is entered on the PED keypad, unlocking the secret on the key, which is then presented to the HSM for authentication.
• The PED device facilitates creation and communication of secrets but does not hold the HSM authentication secrets itself. The secrets reside on the portable PED Keys.
• An imprinted PED Key can only be used with HSMs that share the specific secret it carries. PED devices themselves are interchangeable; any PED can be used to present any PED Key to any compatible HSM.
• PED and PED Keys prevent key-logging exploits on the host HSM: authentication information never touches the host computer’s keyboard or memory.

Types of PED Roles

PED Keys are generated with a specific role in mind, 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 a command as that role and N is the total number of keys created. The following roles can be created on a Luna HSM:

Security Officer (SO) – Blue Key

The first actions with a new Luna HSM involve creating an SO PIN and imprinting a blue SO PED Key. A PED PIN (an additional, optional password typed on the PED touchpad) can be added as a second factor. Blue 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 authorizes further administrative actions: creating HSM partition users and changing passwords, backing up HSM objects, and controlling HSM Policy settings. Recommended quorum: 3-of-7 M-of-N with blue keys.

Partition User or Crypto Officer – Black Key

The black Crypto Officer PED Key is required to log in as the HSM Partition Owner. It is needed for partition maintenance and for the creation and destruction of key objects. The local portion of the Crypto Officer 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. Recommended quorum: 3-of-7 M-of-N with black keys.

Crypto User – Gray Key

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. Recommended quorum: 3-of-7 M-of-N with gray keys.

Key Cloning Vector (KCV) or Domain ID Key – Red Key

The red Domain PED Key carries the domain identifier for any group of HSMs for which key-cloning or backup is used. It is created at HSM initialization and again when each HSM Partition is created. A domain key carries the domain via the PED to other HSMs or HSM partitions to be initialized with the same domain, permitting backup and restore operations only among containers and tokens that share the same domain. Once imprinted, the domain identifier is intended to be permanent on the red Domain PED Key; any future operations with that key copy the same domain onto future HSM Partitions or backup tokens. Domains must match across partitions for the organization to clone, back up partitions, or assemble HSM partitions into an HA group. Recommended quorum: 3-of-7 M-of-N with red keys.

Remote PED – Orange Key

The orange Remote PED Key (RPK) contains the Remote PED Vector (RPV). It pre-authorizes the PED Server to communicate with the HSM, ensuring that only an authorized PED device can establish a remote authentication session. The orange key is required when using the Remote PED option to administer HSMs in remote data centers without physical access to the appliance. Orange Remote PED Keys can be shared among multiple HSMs and PED workstations. M-of-N can be applied to orange keys based on organizational security policy.

Audit Key – White Key

The Audit role is initialized and imprints a white PED Key without SO or other role involvement. The Auditor configures and maintains audit logging: what HSM activity is logged, rollover periods, and other logging parameters. The separate Audit role satisfies security requirements ensuring that no one, including the HSM SO, can modify the logs or hide HSM actions. The Audit role is optional until initialized. White Audit PED Keys can be shared among multiple HSMs and PED workstations.

PED Key Management Best Practices

Number of Off-Site Full Sets

Organizations deploying multiple Luna HSMs must decide whether to use a common authentication secret across all HSMs or separate secrets per HSM (or per group of HSMs). Using a common blue SO PED Key simplifies management but means a single compromised key affects all HSMs sharing that secret. To limit risk, group HSMs and use a distinct blue PED Key per group. Each time an HSM is initialized, the PED prompts to reuse an existing keyset (making the current HSM part of an existing group) or generate a fresh unique secret. The number of PED Key sets required equals the number of groups, doubled to maintain at least one backup per primary key. Backup copies must be stored off-premises in a physically secure, access-controlled location.

One-for-One vs Group vs M-of-N

One-for-one: a separate blue SO PED Key per HSM with a distinct authentication secret for each. No single key unlocks more than one HSM. Total keys needed: (number of HSMs) x 2 (primary plus backup). Provides strongest isolation but highest key management overhead.

Group deployment: a common SO secret across a group of HSMs. One key set unlocks all HSMs in the group. Reduces key management overhead; increases the consequence of a single key compromise.

M-of-N (recommended): splits the SO secret across N keys so that M must be presented simultaneously to authenticate. No single key holder can unlock an HSM. Choose M and N based on available trusted custodians and organizational security policy. Up to 16 splits are supported. Distribute each split to a different person; no single person can unlock the HSM independently. Total keys: N primary plus N backup copies of the complete set, stored at separate secure off-site locations.

Partition Black PED Keys

Each HSM can have multiple partitions, each requiring its own black Crypto Officer PED Key authentication. Organizations have the same grouping and M-of-N options for black keys as for blue SO keys. Common partition keys across multiple partitions simplify management but increase exposure if a black key is compromised. M-of-N can be applied to partition keys for high-sensitivity partitions where two-person control is required. At minimum, one backup per primary black PED Key must be maintained off-site.

Domain Red PED Keys

Each HSM and each HSM partition has a domain. Domains must match across partitions for cloning, backup, and HA group assembly. Red Domain PED Keys must be shared with each HSM or partition that needs to participate in backup and restore operations. Losing all copies of a red domain key makes it impossible to restore keys from backup to a new partition; the data is cryptographically unrecoverable. Maintain at least one off-site backup of every red domain key.

Deployment Example: PED Key Management for Enterprise HSM Deployment

1. HSM grouping: 12 HSMs are organized into 4 groups of 3. Each group uses a common SO (blue) secret and a common domain (red) secret, reducing key management overhead while limiting the scope of a single key compromise to 3 HSMs.
2. M-of-N quorum setup: each group’s blue SO and black Crypto Officer keys are created as 3-of-7 M-of-N quorums. 7 key holders are assigned per group; 3 must be present simultaneously for any administrative HSM operation.
3. Key distribution: the 7 custodians for each quorum are distributed across 3 geographic locations; no single location holds more than 3 of the 7 keys. Physical compromise of one location cannot satisfy the 3-of-7 quorum.
4. Off-site backup: a complete duplicate set of 7 keys per quorum is stored at a fourth secure location under independent access controls. Backup keys are tested for accessibility annually.
5. Remote PED for data center operations: orange Remote PED Keys are provisioned for each group, allowing custodians to authenticate remotely to HSMs in locked data centers without physical travel to the appliance.
6. Audit role activation: white Audit PED Keys are provisioned and assigned to the organization’s compliance team. The Audit role is independent of the SO, ensuring the HSM SO cannot modify or suppress audit log entries.
7. HSMaaS integration: for organizations using Encryption Consulting’s HSMaaS, PED Key management procedures are coordinated with EC’s team; key ceremony support ensures the initial HSM initialization follows the M-of-N best practices above.

Failure-Mode Guidance

• Lost SO (blue) PED Keys without backup: HSM must be re-initialized; all HSM contents are lost. If M-of-N is in use and fewer than M keys have been lost, the quorum can still be satisfied and the HSM remains accessible. Mitigation: maintain duplicate key sets at separate secure locations.
• Lost Crypto Officer (black) PED Keys: the partition becomes inaccessible for administrative operations; keys within the partition cannot be used for signing or decryption until a valid black key is presented. If no backup exists, all key material in the partition is unrecoverable. Mitigation: maintain off-site black key backups; use Group PED Key option to share black keys across a trusted administrator group.
• Lost Domain (red) PED Keys: HSMs and partitions sharing that domain can no longer be used for backup or restore operations. Existing operations on current HSMs continue, but disaster recovery to a replacement HSM is impossible without the domain key. Mitigation: treat red domain key management with the same rigor as blue SO keys; off-site backup is mandatory.
• PED device failure: PED devices are interchangeable; any compatible PED device works with any PED Key of any color. A failed PED device does not affect key accessibility; replace the PED device and continue using the existing PED Keys.
• Custodian unavailability (M-of-N): if fewer than M custodians are available, HSM administrative operations requiring that quorum cannot proceed until quorum is satisfied. Mitigation: assign backup custodians for each quorum position; use off-site backup key sets; maintain current custodian contact information.

Managing Orange and White PED Keys

Orange Remote PED Keys and white Audit PED Keys can be shared among multiple HSMs and PED workstations, just like all other PED Key colors. M-of-N can be applied to orange and white keys based on organizational policy, though it is less commonly required for these roles than for SO and Crypto Officer keys.

All PED Key roles allow overwriting any key of any color with a new secret. A warning is given if a key is not blank, but overwriting can proceed. A previously imprinted PED Key that has been made irrelevant (by re-initializing an HSM, deleting a partition, or other deliberate HSM actions) retains its physical integrity; PED Keys do not age or expire during their service life. Only deliberate HSM administrative actions cause a PED Key’s secret to become invalid.

In all cases, maintaining at least one backup copy of every PED Key of every color, stored in a separate secure location from the primary keys, is the most important single practice for ensuring HSM recoverability. There is no universally correct number of PED Keys: the right number depends on the grouping strategy, M-of-N choices, number of HSMs, and the number of trusted custodians available. The principle is consistent: more backups mean more recovery options; fewer backups mean greater risk of unrecoverable loss.

How Encryption Consulting Can Help

Encryption Consulting offers HSM as a Service, HSM deployment and management services, and HSM training covering Luna HSM PED Key management, Security World design, and HSM operational best practices. Our experts have worked with Luna HSM deployments across PKI, code signing, payment, and enterprise key management environments and can advise on quorum sizing, key ceremony procedures, disaster recovery design, and Remote PED configuration. For HSM training covering the Entrust nShield platform, see our nShield HSM On-Demand Training course.

Frequently Asked Questions

What is a Luna PED Key and how does it work?

A USB-format smartcard (SafeNet iKey 1000, FIPS configuration) that stores an HSM authentication secret. Secrets are created inside the HSM and delivered to the PED Key via the PED’s trusted path, never through host memory. The key can be duplicated for backup or shared among HSMs so one secret unlocks a group. PED devices are interchangeable; PED Keys carry the role-specific secrets.

What is the trusted path in Luna PED authentication?

The direct, independent channel between the PED device and the HSM that bypasses the host computer entirely. Authentication information never passes through host CPU, memory, or OS. The PED and HSM negotiate a data encryption key (DEK) for end-to-end encryption of all PED protocol data. This prevents keylogging attacks even if the host OS is fully compromised.

What is M-of-N quorum for PED Keys and when should you use it?

Splits an authentication secret across N keys so M must be presented simultaneously. No single holder can authenticate independently. Use for CA root keys, HSM initialization, and any role where single-person control is unacceptable. Recommended default: 3-of-7. Set at initialization; cannot be changed afterward without re-initialization.

What PED Key colors correspond to which roles?

Blue: Security Officer (HSM administration). Black: Crypto Officer (partition management, key creation). Gray: Crypto User (restricted read-only access). Red: Domain key (cloning and backup operations). Orange: Remote PED Vector (remote administration sessions). White: Audit role (audit log configuration). Each role’s color is enforced by the HSM; a key imprinted for one role cannot be used for another.

How many PED Keys should an organization maintain?

At minimum, one backup per primary key of each color. For M-of-N quorums, one complete duplicate set of N keys stored at a separate secure off-site location. The exact number depends on grouping strategy (one-for-one vs group), number of HSMs, and M-of-N choices. Never operate with only one copy of any PED Key.

What is Remote PED and how does it maintain end-to-end encryption?

Remote PED allows custodians to authenticate to HSMs in remote data centers without physical access. The PED Server (where the PED device is USB-connected) and PED Client (on the HSM host) negotiate a DEK for an end-to-end encrypted channel between the PED device and the HSM. The orange Remote PED Key pre-authorizes the PED Server to the HSM, preventing unauthorized PED devices from connecting. Host software cannot observe the authentication exchange.