PED Authentication

The Luna PIN Entry Device (Luna PED) provides PIN entry and secret authentication to a Luna HSM that requires Trusted Path Authentication. The requirement for PED or password authentication is configured at the factory, according to the HSM model you selected at time of purchase.

The Luna PED and PED keys are the only means of accessing the PED-authenticated HSM's administrative functions. They prevent key-logging exploits on workstations connected to the host HSM, because authentication is delivered directly from the hand-held PED to the HSM via the independent, trusted-path interface. No password is entered via computer keyboard.

NOTE   Luna PCIe HSM 7.x requires Luna PED firmware version 2.7.1 or higher. This firmware is backward-compatible with Luna PCIe HSM 6.x.

This chapter contains the following sections about PED authentication:

>PED Authentication Architecture

•Comparing Password and PED Authentication

>PED Keys

•PED Key Types and Roles

•Shared PED Key Secrets

•Domain PED Keys

•PED PINs

•M of N Split Secrets (Quorum)

>Luna PED Received Items

>Luna PED Hardware Functions

>Updating Luna PED Firmware (for older-version PED that requires a power-block)

>Local PED Setup

>About Remote PED

>Remote PED Setup

>PED Key Management

>PEDserver and PEDclient

PED Authentication Architecture

The PED Authentication architecture consists of the following components:

>Luna PED: a PIN Entry Device with a local or remote connection to the HSM. The PED reads authentication secrets from PED keys on behalf of an HSM or partition (see Luna PED Hardware Functions).

>Authentication secrets: Cryptographic secrets generated by the HSM and stored on PED keys. These secrets serve as login credentials for the various roles on the HSM. They can be shared among roles, HSMs, and partitions according to your security scheme.

>PED Keys: physical USB-connected devices that contain authentication secrets, created by the HSM (see PED Keys). PED Keys have the following custom authentication features:

•Shared Secrets: PED keys of the same type can be reused or shared among HSMs or partitions, allowing domain sharing (necessary for HA and backup configurations), legacy-style Security Officer authentication, and other custom configurations. See Shared PED Key Secrets.

•PED PINs: optional PINs associated with specific PED keys, set by the owner of the PED key at the time of creation. PED PINs offer an extra layer of security for PED keys which could be lost or stolen. See PED PINs.

•M of N Split Key Scheme: optional configuration which allows a role to split its authentication secret across multiple PED keys, and require a minimum number of those keys for authentication. This scheme can be customized to be as simple or complex as your organization's security policy dictates. See M of N Split Secrets (Quorum).

Comparing Password and PED Authentication

The following table describes key differences between password- and PED-authenticated HSMs.

	Password-authentication	PED-authentication
Ability to restrict access to cryptographic keys	>Knowledge of role password is sufficient >For backup/restore, knowledge of partition domain password is sufficient	>Ownership of the black Crypto Officer PED key is mandatory >For backup/restore, ownership of both black CO and red domain PED keys is mandatory >The Crypto User role is available to restrict access to read-only, with no key management authority >Option to associate a PED PIN with any PED key, imposing a two-factor authentication requirement on any role
Dual Control	>Not available	>MofN (split-knowledge secret sharing) requires "M" different holders of portions of the role secret (a quorum) in order to authenticate to an HSM role - can be applied to any, all, or none of the administrative and management operations required on the HSM
Key-custodian responsibility	>Password knowledge only	>Linked to partition password knowledge >Linked to black PED key(s) ownership and optional PED PIN knowledge
Two-factor authentication for remote access	>Not available	>Remote PED and orange (Remote PED Vector) PED key deliver highly secure remote management of HSM, including remote backup

PED Keys

A PED key is a USB authentication device, embedded in a molded plastic body. It contains a secret, generated by the HSM, that authenticates a role, cloning domain, or remote PED server. This secret is retained until deliberately changed by an authorized user.

The Luna PED does not hold the authentication secrets. They reside only on the portable PED keys.

PED keys are created when an HSM, partition, role, or Remote PED vector is initialized. A PED key can contain only one authentication secret at a time, but it can be overwritten with a new authentication secret. See PED Key Management.

CAUTION!   Do not subject PED keys to extremes of temperature, humidity, dust, or vibration. Use the included key cap to protect the USB connector.

PED Key Types and Roles

The PED uses PED keys for all credentials. You can apply the appropriate labels included with your PED keys, according to the table below, as you create them.

The PED key colors correspond with the HSM roles described in HSM Roles. The following table describes the keys associated with the various roles:

Lifecycle	PED Key	PED Secret	Function
HSM Administration	Blue	HSM Security Officer (HSM SO) secret	Authenticates the HSM SO role. The HSM SO manages provisioning functions and security policies for the HSM. Mandatory
	Red	HSM Domain or Key Cloning Vector	Cryptographically defines the set of HSMs that can participate in cloning for backup. See Domain PED Keys. Mandatory
	Orange	Remote PED Vector	Establishes a connection to a Remote PED server. See * below table. Optional
HSM Auditing	White	Auditor (AU) secret	Authenticates the Auditor role, responsible for audit log management. This role has no access to other HSM services. Optional
Partition Administration	Blue	Partition Security Officer (PO) secret	Authenticates the Partition SO role. The PO manages provisioning activities and security policies for the partition. NOTE: If you want the HSM SO to also perform Partition SO duties, you can use the same blue key to initialize both roles. Mandatory
	Red	Partition Domain or Key Cloning Vector	Cryptographically defines the set of partitions that can participate in cloning for backup or high-availability. See Domain PED Keys. Mandatory
Partition Operation	Black	Crypto Officer (CO) secret	Authenticates the Crypto Officer role. The CO can perform both cryptographic services and key management functions on keys within the partition. Mandatory
	Gray	Limited Crypto Officer (LCO) secret **	Authenticates the Limited Crypto Officer role. The LCO can perform a subset of the actions available to the Crypto Officer. Optional (used in eIDAS-compliant schemes)
	Gray	Crypto User (CU) secret	Authenticates the Crypto User role. The CU can perform cryptographic services using keys already existing within the partition. It can create and back up public objects only. NOTE: If administrative separation is not important, you can use a single black key to initialize the Crypto Officer and Crypto User roles and still have two separate challenge secrets to distinguish read-write and read-only role privileges. Optional

*

**

Shared PED Key Secrets

The Luna PED identifies the type of authentication secret on an inserted PED key, and secrets of the same type (color designation) can be used interchangeably. During the key creation process, you have the option of reusing an authentication secret from an existing key rather than have the HSM create a new one. This means that you can use the same PED key(s) to authenticate multiple HSMs or partitions. This is useful for:

>legacy-style authentication schemes, where the HSM SO also functions as the owner of application partitions. This is achieved by using the same blue PED key to initialize the HSM and some or all of the partitions on the HSM.

>allowing a single HSM SO to manage multiple HSMs, or a single Partition SO to manage multiple partitions

>ensuring that HSMs/partitions share a cloning domain (see Domain PED Keys)

>allowing a read-write Crypto Officer role and a read-only Crypto User role to be managed by the same user

It is not necessary for partitions in an HA group to share the same blue Partition SO key. Only the red cloning domain key must be identical between HA group members.

NOTE   Using a single PED key secret to authenticate multiple roles, HSMs, or partitions is less secure than giving each its own PED key. Refer to your organization's security policy for guidance.

Domain PED Keys

A red domain PED key holds the key-cloning vector (the domain identifier) that allows key cloning between HSMs and partitions, and is therefore the PED key most commonly shared between HSMs or partitions. Cloning is a secure method of copying cryptographic objects between HSMs and partitions, required for backup/restore and within HA groups. It ensures that keys copied between HSMs or partitions are:

>strongly encrypted

>copied only between HSMs and partitions that share a cloning domain.

NOTE   An HSM or partition can be a member of only one domain, decided at initialization. A domain can only be changed by re-initializing the HSM. Partition domains may not be changed after initialization.

PED PINs

The Luna PED allows the holder of a PED key to set a numeric PIN, 4-48 characters long, to be associated with that PED key. This PIN must then be entered on the PED keypad for all future authentication. The PED PIN provides two-factor authentication and ensures security in case a key is lost or stolen. If you forget your PED PIN, it is the same as losing the PED key entirely; you cannot authenticate the role.

PED PINs can be set only at the time of key creation, and can be changed only by changing the secret on the PED key. Duplicate keys made at the time of creation can have different PED PINs, allowing multiple people access to the role (see Creating PED Keys). Copies made later are true copies with the same PED PIN, intended as backups for one person (see Duplicating Existing PED Keys). Duplicates of the PED key all have the same PED PIN.

If you are using an M of N configuration, each member of the M of N keyset may set a different PED PIN.

CAUTION!   Forgetting a PED PIN is equivalent to losing the key entirely; you can no longer authenticate the role, domain, or RPV. See Consequences of Losing PED Keys.

M of N Split Secrets (Quorum)

The Luna PED can split an authentication secret among multiple PED keys (up to 16), and require a minimum number of the split keys (a quorum of key-holders) to authenticate the role. This provides a customizable layer of security by requiring multiple trusted people (sometimes called the quorum) to be present for authentication to the role.

This can be likened to a club or a legislature, with some arbitrary number of members. You don't need all members present, to make a decision or perform an action, but you do not want a single person to be able to arbitrarily make decisions or take action affecting everyone. So your security rules set out a number of participants - a quorum - who must be assembled in order to perform certain actions

For example, you could decide (or your security policy could dictate) that at least three trusted people must be present for changes to the HSM policies or for client partition assignments. To accommodate illness, vacations, business travel, or any other reasons that a key-holder might not be present at the HSM site, it is advisable to split the authentication secret between more than three people. If you decide on a five-key split, you would specify M of N for the HSM SO role, or for the cloning domain to be 3 of 5. That is, the pool of individual holders of spits of that role secret is five persons, and from among them, a quorum of three must be available to achieve authentication (any three in this 3 of 5 scenario, but cannot be the same key presented more than once during an authentication attempt).

In this scenario, the HSM SO authentication secret is split among five blue PED keys, and at least three of those keys must be presented to the Luna PED to log in as HSM SO.

This feature can be used to customize the level of security and oversight for all actions requiring PED authentication. You can elect to apply an M of N split-secret scheme to all roles and secrets, to some of them, or to none of them. If you do choose to use M of N, you can set different M and N values for each role or secret. Please note the following recommendations:

>M = N is not recommended; if one of the key holders is unavailable, you cannot authenticate the role.

>M = 1 is not recommended; it is no more secure than if there were no splits of the secret - a single person can unlock the role without oversight. If you want multiple people to have access to the role, it is simpler to create multiple copies of the PED key.

NOTE   Using an M of N split secret can greatly increase the number of PED keys you require. Ensure that you have enough blank or rewritable PED keys on hand before you begin backing up your M of N scheme.

Activated Partitions and M of N

For security reasons, the HSM and its servers are often kept in a locked facility, and accessed under specific circumstances, directly or by secure remote channel. To accommodate these security requirements, the Crypto Officer and Crypto User roles can be Activated (to use a secondary, alpha-numeric login credential to authenticate - Partition Policy 22), allowing applications to perform cryptographic functions without having to present a black or gray PED key (see Activation and Auto-activation on Multi-factor- (PED-) Authenticated Partitions). In this case, if the HSM is rebooted for maintenance or loses power due to an outage, the cached PED secret is erased and the role must be reactivated (by logging in the role via LunaCM and presenting the requisite M number, or quorum, of PED keys) before normal operations can resume. A further measure called Auto-Activation (Partition Policy 23) can cache the authenticated state as long as two hours, allowing automatic, hands-off resumption of operation.

PED-Authenticated HSMs with Firmware 7.7.0 (and newer)

HSM 7.7.0 and associated PEDs introduce new communications security protocols for compliance with evolving standards.

Updated HSMs need updated PEDs

An HSM at firmware 7.7.0 or newer requires connection with a PED that has f/w 2.7.4 (old PED series with power block) or f/w 2.9.0 (newer PED series with USB power).

Two PED-firmware update packages are available. Old-series PEDs (f/w 2.6.x through 2.7.2) have an upgrade path to PED f/w version 2.7.4.

New-series PEDs (f/w 2.8.x ) have an upgrade path to PED f/w version 2.9.0.

When an HSM is at f/w version 7.7.0 or newer, it verifies that any connecting PED is at PED f/w 2.7.4 or 2.9.0, respectively, or the HSM refuses the connection and issues an error (LUNA_RET_PED_UNSUPPORTED_PROTOCOL).

Earlier version HSMs function with updated PEDs

A PED at f/w version 2.7.4 (older-series powered by power-block) or 2.9.0 (newer-series USB-powered) is able to work with updated HSMs and with older HSMs.

The result is that an updated PED can function with older HSMs (HSM f/w 5.x and 6.x) that will not be updated with the new PED communication protocols, or with earlier f/w 7.x HSMs that have yet to be updated for compliance with current eIDAS/Common Criteria and NIST standards.

This means that, if you have PED-Authenticated version pre-7.7.0 HSMs that are to be updated to f/w 7.7.0 (or newer), then you must update at least one PED first, so that you can continue to authenticate to roles on the HSM while updating.

Orange PED Keys have changed

The RPV of an orange PED Key, created with PED firmware 2.7.4 or 2.9.0 against a firmware 7.7.0 HSM has additional features compared to previous RPVs, necessary for current authentication standards. An older PED can use a newer RPV without issue (unaware of the additional crypto components). An older PED can duplicate a newer RPV onto another orange key, but only imprinting the older components - the newer security components are lost. The duplicated RPV can then be used with pre-firmware-7.7.0 HSMs, but since the newer security components are missing, the 'duplicate' orange key (and any copy of it) cannot be used with HSMs at version 7.7.0 or newer.

However, when updating PEDs and HSM firmware, existing orange PED Keys can be migrated to the new format. The same is true for a newer-style RPV that had the newer security components stripped by copying with a non-updated PED.

A blank orange PED Key receiving a new Remote PED Vector (RPV) must have the operation performed over a local connection between PED and HSM.

New-series PED Behavior Notes

All of the following points apply to the newer-series PED (firmware versions 2.8.0, 2.8.1, or 2.9.0).

>If a PED is connected via USB to a version 7.x HSM (whether that HSM is installed in a host computer or is embedded in a Network HSM appliance), if the server housing the HSM is booted from a power-off condition, the PED display might come up blank. The PED must be reset.

>If a new-series PED is powered via USB from a 7.x HSM, and the HSM is reset, the PED will become unresponsive. The PED must be reset.

>If a PED is connected via USB to a PED server (for Remote PED), if the server is booted from a power-off condition, the PED display might come up blank OR the PED might be unresponsive to the PED server. The PED must be reset.

>A new-series PED will be unresponsive after a 7.x HMS firmware update or rollback, and/or the display might come up blank. The PED must be reset.

References to resetting the PED mean cycling the power. This can be done by disconnecting and reconnecting the USB cable.

A new-series PED, powered by a 7.x HSM over USB retains the AC power socket of the older-series model. If an AC power block is plugged into the power socket of the PED, this will reset the PED.

Updating or Rolling-back PED-auth HSM Firmware

After a version 7.x HSM is updated to f/w version 7.7.0, or rolled back to an earlier f/w version, a USB-connected PED should be power cycled. Without this action, attempted operations against the HSM can result in "device error".