Multifactor Quorum Authentication

The Luna PIN Entry Device (Luna PED) provides PIN entry and secret authentication to a Luna HSM that requires trusted-path multifactor quorum authentication. The requirement for multifactor quorum 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 multifactor quorum-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 Luna PED to the HSM via the independent, trusted-path interface. No password is entered via computer keyboard.

This chapter contains the following sections about multifactor quorum authentication:

>Multifactor Quorum Authentication Architecture

•Comparing Password and Multifactor Quorum Authentication

>PED keys

•PED key Types and Roles

•Shared PED key Secrets

•Domain PED keys

•PINs

•Quorum Split Secrets (M of N)

>Luna PED Received Items

>Luna PED Hardware Functions

>Updating External Supply-Powered Luna PED Firmware

>Local PED Setup

>About Remote PED

>Multifactor Quorum PED key Management

>PEDserver and PEDclient

Multifactor Quorum Authentication Architecture

The multifactor quorum 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.

•PINs: optional PINs associated with specific PED keys, set by the owner of the PED key at the time of creation. PINs offer an extra layer of security for PED keys which could be lost or stolen. See 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 Quorum Split Secrets (M of N).

Comparing Password and Multifactor Quorum Authentication

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

	Password authentication	Multifactor Quorum 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 PIN with any PED key, imposing a two-factor authentication requirement on any role
Dual Control	>Not available	>Quorum (also called 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 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

PED keys are USB authentication devices, embedded in a molded plastic body. Each 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. Each PED key can contain only one authentication secret at a time, but it can be overwritten with a new authentication secret. See Multifactor Quorum 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 Luna 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	Authentication 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

* Orange PED keys (RPK) for use with Luna HSM Firmware 7.7.0 or newer, with enhanced security to address modern threat environments and to comply with updated standards, have increased infrastructure onboard the key. If such an initialized RPK is overwritten to become a different role PED key (example SO), this process that formerly would take about six seconds now takes about 36 seconds.

**  No use-case is anticipated that requires both the LCO and the CU roles at the same time (Crypto User for Luna use-cases and Limited Crypto Officer for eIDAS use-cases), so the gray Crypto User stickers should be adequate to identify either role as you manage and distribute PED keys.

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.

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 Luna PED keypad for all future authentication. The PIN provides two-factor authentication and ensures security in case a key is lost or stolen.

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 PINs, allowing multiple people access to the role (see Creating PED keys). Copies made later are true copies with the same PIN, intended as backups for one person (see Duplicating Existing PED keys). Duplicates of the PED key all have the same PIN.

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

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

Quorum Split Secrets (M of N)

The Luna PED can split an authentication secret among multiple PED key iKeys (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. The key splits are presented to the Luna PED and combined inside the Luna HSM firmware to authenticate the role.

This can be likened to a club, or a board of directors, 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 among 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, or any other role/function, to be 3 of 5. That is, the pool of individual holders of splits 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 example scenario, the HSM SO authentication secret is split among five blue PED key iKeys, and at least three of those keys must be presented to the Luna PED to log in as HSM SO. The PED enforces your quorum rule.

This feature can be used to customize the level of security and oversight for all actions requiring multifactor quorum authentication. You can elect to apply a quorum (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.

Activated Partitions and Quorum (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 on Multifactor Quorum-Authenticated Partitions). In this case, if the HSM is rebooted for maintenance or loses power due to an outage, the cached authentication 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.

If Auto-Activation is not allowed, or if it is common for your devices to experience outages greater than two hours in duration, you can invoke Remote PED operation and perform PED operations from a location that is distant from the HSM, and possibly more convenient for your authentication secret key holders to convene. See About Remote PED.

Updated Luna PED Behavior Notes

USB-powered and DC-powered Luna PEDs can be updated to Luna PED Firmware 2.9.0 and Luna PED Firmware 2.7.4 respectively.

>Updated Luna PEDs support new communications security protocols for compliance with evolving standards. For more information about these changes, refer to the following sections:

•Secure Communication Between the Local PED and Luna PCIe HSM 7s With Firmware 7.7.0 and Newer

•Secure Communication Between the Remote PED and Luna PCIe HSM 7s With Firmware 7.7.0 and Newer

>A Luna HSM at Luna HSM Firmware 7.7.0 or newer requires connection with an updated Luna PED.

• If you are updating to Luna HSM Firmware 7.7.0 or newer, refer to Special Considerations for Luna HSM Firmware 7.7.0 and Newer, Luna PED Firmware 2.9.0, and Luna PED Firmware 2.7.4 before proceeding with the update.

•For more information about PED behavior on Luna HSMs that contain V0 or V1 partitions, refer to Multifactor Quorum Authentication.

>PEDs with Luna PED Firmware 2.7.4 or Luna PED Firmware 2.9.0 or newer can also function with the following HSMs:

•HSMs with firmware 5.x and 6.x that will not be updated with the new PED communication protocols.

•HSMs with firmware 7.x that have yet to be updated for compliance with current eIDAS/Common Criteria and NIST standards.

New-series Luna 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 Luna Network HSM 7 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.

>In environments where the user is switching RPED connections to the same PED between a Luna PCIe HSM 7 with Luna HSM Firmware 7.7.0 and one with firmware older than 7.7.0, the following error may occur after receiving a prompt to present the orange PED key:

• PED_ERROR when running Luna HSM Client 10.3.0 or newer.

•DEVICE_ERROR when running Luna HSM Client 10.2.0 or older.

The user may need to clear the RPK from the PED's cache before attempting to switch connection to the non-7.7.0 HSM by pressing the < key, or repeat the command after encountering the error.

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 Multifactor Quorum-Authenticated HSM Firmware

After a version 7.x HSM is updated to Luna HSM Firmware 7.7.0 (or newer), or rolled back to an earlier firmware version, a USB-connected PED should be power cycled. Also restart the PED after any appliance reboot. Without this action, attempted operations against the HSM can result in "device error".