Multifactor Quorum Authentication

The Luna USB HSM 7 can be initialized to use multifactor quorum authentication for all roles on the HSM. The authentication secrets are stored on USB iKeys, and are presented by inserting them directly into the Luna USB HSM 7. This means that the iKeys and direct access to the Luna USB HSM 7 are the only method of accessing the HSM's administrative functions. This prevents key-logging exploits on workstations connected to the client HSM, because authentication takes place entirely within the device itself. No password is entered via computer keyboard.

This section contains the following information about Luna USB HSM 7 multifactor quorum authentication:

>Multifactor Quorum Authentication Architecture

•Comparing Password and Multifactor Quorum Authentication

>iKeys

•iKey Types and Roles

•Shared iKey Secrets

•Domain iKeys

•iKey PINs

•M of N Split Secrets (Quorum)

>iKey Management Using Luna USB HSM 7

Multifactor Quorum Authentication Architecture

The multifactor quorum authentication architecture consists of the following components:

>Luna USB HSM 7: Role secrets stored on iKeys are presented directly to the Luna USB HSM 7 by connecting them to the USB-C input.

>Authentication secrets: Cryptographic secrets generated by the HSM and stored on iKeys. 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.

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

•Shared Secrets: iKeys of the same type can be reused or shared among HSMs or partitions, allowing domain sharing (necessary for backup configurations) and other custom configurations. See Shared iKey Secrets.

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

•M of N Split Key Scheme: optional configuration which allows a role to split its authentication secret across multiple iKeys, 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 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 iKey is mandatory >For backup/restore, ownership of both black CO and red domain iKeys 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 iKey, 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 iKey(s) ownership and optional PIN knowledge
Two-factor authentication for remote access	>Not available	>Remote PED and orange (Remote PED Vector) iKey deliver highly secure remote management of HSM, including remote backup

iKeys

The iKey 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 USB HSM 7 does not hold the authentication secrets. They reside only on the portable iKeys.

iKeys are created when an HSM, partition, or role is initialized. Each iKey can contain only one authentication secret at a time, but it can be overwritten with a new authentication secret. See iKey Management Using Luna USB HSM 7.

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

iKey Types and Roles

Once initialized for multifactor quorum authentication, the Luna USB HSM 7 uses iKeys for all credentials. You can apply the appropriate labels included with your iKeys, according to the table below, as you create them.

The iKey colors correspond with the HSM roles described in HSM Roles and Partition Roles. The following table describes the keys associated with the various roles:

Lifecycle	iKey	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 iKeys. Mandatory
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 iKeys. 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

NOTE   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 iKeys.

Shared iKey Secrets

The Luna USB HSM 7 identifies the type of authentication secret on an inserted iKey, 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 iKey(s) to authenticate multiple HSMs or partitions. This is useful for:

>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 iKeys)

>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 iKey secret to authenticate multiple roles, HSMs, or partitions is less secure than giving each its own iKey. Refer to your organization's security policy for guidance.

Domain iKeys

A red domain iKey holds the key-cloning vector (the domain identifier) that allows key cloning between HSMs and partitions, and is therefore the iKey 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 the 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 or partition.

iKey PINs

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

PINs can be set only at the time of key creation, and can be changed only by changing the secret on the iKey. Duplicate keys are true copies with the same PIN, intended as backups for one person (see Duplicating an Existing iKey Using Luna USB HSM 7). Duplicates of the iKey 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 iKeys.

M of N Split Secrets (Quorum)

The Luna USB HSM 7 can split an authentication secret among multiple 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.

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 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 scenario, the HSM SO authentication secret is split among five blue iKeys, and at least three of those keys must be presented to the Luna USB HSM 7 to log in as HSM SO.

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 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 recommended only when you want multiple people to access the role, each with their own unique iKey PIN.

NOTE   Using an M of N split secret can greatly increase the number of iKeys you require. Ensure that you have enough blank or rewritable iKeys on hand before you begin initializing 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 iKey (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 iKeys) before normal operations can resume.