PED Authentication
The SafeNet Luna PIN Entry Device (Luna PED) provides PIN entry and secret authentication to a SafeNet 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.
SafeNet Luna PCIe HSM release 7.x requires Luna PED firmware version 2.7.1 or higher. This firmware is backward-compatible with legacy SafeNet Luna PCIe HSM 6.x.
This chapter contains the following sections about PED authentication:
>SafeNet Luna PED Hardware Functions
•Initializing the Remote PED Vector (RPV) and Creating the Orange PED Key
•Installing PEDserver and Setting Up the Remote Luna PED
•Opening a Remote PED Connection
•Ending or Switching the Remote PED Connection
•Performing PED Authentication
•Consequences of Losing PED Keys
•Duplicating Existing PED Keys
PED Authentication Architecture
The PED Authentication architecture consists of the following components:
>SafeNet 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 SafeNet 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 and Procedures. 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. 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
|
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.
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 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.
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), allowing applications to perform cryptographic functions without having to present a black or gray PED key (see Activation and Auto-activation on 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.
