Multi-factor (PED) Authentication
The connection between the Luna PED and the SafeNet Luna HSM is a secure trusted path.
>For the SafeNet Luna Network HSM, the PED connection is on the appliance rear panel.
>For the SafeNet Luna PCIe HSM, the PED connection is a slot-edge connector, directly on the HSM card, accessible at the exterior of a tower or server computer (not through the host computer).
For Local PED, the connection is a secure physical link, directly to the HSM, bypassing the computer memory and bus.
For Remote PED, the PED Key information is made available from the PED location by a PedServer instance, and is received at the HSM location by a PedClient instance there. Two connection options are available:
>standard, or client-initiated Remote PED involves the PedClient reaching out to a PedServer; while the path is clear, the PED Key data is encrypted and secured at both ends by the Remote PED Vector (on an orange PED Key and in the HSM)
>peer-to-peer, or server-initiated Remote PED involves the PedServer instance reaching out to the PedClient instance, in order to satisfy HSM location behind a firewall that forbids outgoing initiation of connections; the PED Key data is secured at both ends by the Remote PED Vector (on an orange PED Key and in the HSM), and the network connection is secured by a TLS link, using previously exchanged certificates.
At no time does an authentication secret exist in-clear, anywhere in computer memory or on any computer bus.
In general, there are three paths to access the SafeNet Luna HSM:
>The administrative path, via SSH or via local serial link, which uses the LunaSH command-line interface
>The Client path, via TLS (our implementation is called NTLS), by which client applications use the SafeNet Luna HSM API to perform cryptographic functions within pre-assigned virtual HSMs (called Partitions) on the HSM
>The Trusted Path, used for authentication data passed from the PED and PED keys - this path ensures that HSM authentication data does not pass unencrypted through a host or terminal computer, where it might be subject to attack. This applies only to PED-authenticated (multi-factor) HSMs.
For SafeNet Luna HSMs with PED Authentication, the various layered roles are protected by a combination of PED keys and passwords.
HSM Admin (Security Officer)
To access the HSM to perform HSM-specific administration tasks (set HSM-wide policies, update firmware and capabilities, backup and restore the HSM, create and remove HSM Partitions, etc.), you must first be authenticated as SO (Security Officer) or HSM Admin (of which there can be only one per SafeNet Luna HSM). The authentication data for SO/HSM Admin is a secret carried on a blue PED key. For the SO to login and issue HSM commands, someone must be present at the connected local Luna PED, or at the configured Remote Luna PED, to insert the required blue PED key when prompted. Otherwise, HSM commands cannot be used.
Partition User (Crypto Officer)
To access HSM Partitions to perform partition-specific administration tasks, such as setting partition policies, assigning partitions to clients, or revoking clients, you must be authenticated as Partition User. There can only be one Partition User per HSM on the SafeNet Luna PCIe HSM, or there can be several on the SafeNet Luna Network HSM - one for each partition. The authentication data for the CO (Crypto Officer) or Partition User is both a password and a secret carried on a black PED key. As the Partition User/CO, you can connect locally, via a serial terminal, or remotely via SSH. To perform partition administration on SafeNet Luna Network HSM, you must first be logged in as admin to have access to LunaSH commands.
>For the SafeNet Luna PCIe HSM, you simply need access to the host computer, where you can use LunaCM commands. For the Partition User/CO to login and issue partition administration commands, someone must be present at the connected Luna PED (or the configured and validated Remote PED) to insert the required black PED key when prompted, or the partition must have been left in Activated state.
>For the SafeNet Luna Network HSM, good security practices suggest that the Partition Password be different than the appliance admin password, and different from other Partition Passwords.
If you have invoked the Crypto Officer/Crypto User distinction, there are two Partition Passwords, but only the Crypto Officer password allows you to run LunaSH or LunaCM commands to administer the partition. It is also recommended that the passwords for each of these roles differ.
Client (Crypto User)
To access HSM Partitions with an application to perform cryptographic operations on data, you must pass a User-type (this is done invisibly by your client application), and present the Partition Password (also done automatically by your application).
>For a standard "Client", the password is the same Partition Password that is used by the Partition User for the particular partition. What limits the scope of operations that a registered, authenticated Client can perform on a partition on a SafeNet Luna Network HSM is the fact that partition administrative commands can be issued only via LunaSH. Thus, for security, Clients should not be allowed to learn the appliance admin password that gives access to LunaSH command line. For SafeNet Luna PCIe HSM, the password or other authentication that gives access to the client application is often the same authentication that gives access to LunaCM for partition administration, so the ability to keep roles separate is more dependent on control of PED keys.
>For a Crypto User client, the password is different from the Crypto Officer password, offering another layer of protection for the partition and its contents.
Auditor
This role combines a special, limited-access appliance account and a special HSM role authenticated by the white PED key, for the purpose of managing HSM audit logs. The auditor is distinct and separate from other role on the appliance and the HSM, conforming to the requirements of auditing standards.
Remote PED
By default, Luna PED is connected directly to the HSM via a USB cable, and powered by the included power block. However, Luna PED can also be used remotely from the HSM(s) for which it manages access control. When it is not convenient to be physically near the host computer that contains a SafeNet Luna HSM you can operate remotely and securely.
The PED-Authenticated SafeNet Luna HSM, and one or more orange PED keys are imprinted with a Remote PED Vector (RPV). This can occur at any time before the HSM is deployed, and requires a locally connected PED. All future PED and PED key interactions can then be accomplished distantly from the HSM, as follows:
1.One computer, running a supported OS, hosts the HSM. This could be:
•A server or tower containing a SafeNet Luna PCIe HSM.
•A SafeNet Luna Network HSM appliance.
The HSM host computer must be network attached. HSM administration commands can be input locally, or via remote connection, but the network connection is essential for Remote PED operation.
2.A second computer (laptop, workstation, server running a supported OS) has a Luna PED (Remote Capable) attached via USB, and powered via its included power block. The Remote PED host computer must be network attached. The administration of the distant HSM host does not have to come from this Remote PED host computer, but it is usually done that way, since the person handling the PED must coordinate with the person giving commands to the HSM. The Remote PED host computer and PED must have the orange Remote PED Key (RPK) available, along with:
• Either blue, black and red (optionally, white) PED keys that were imprinted with the HSM previously
•Or blank blue, black, and red (optionally, white) PED keys that are about to be imprinted along with the HSM
3.The HSM is told to look to a remote PED for its authentication requests.
4.The PED host computer has the LunaPED driver installed, and runs the pedserver utility.
5.The HSM host computer runs the pedclient utility, and the HSM is told to connect to the Remote PED.
6.The Remote PED (via the pedserver) receives the request and prompts for the orange PED Key.
The Remote PED and the HSM (via the pedclient/pedserver connection) must agree that the provided orange PED key contains the same Remote PED Vector as the one imprinted on the HSM, and only then is the secure Remote PED link is established.
7.The HSM SO runs commands on the HSM (on the host computer) via remote desktop or SSH connection.
All future authentication for the HSM can be performed at the Remote PED, with no need for personnel to visit the HSM host, which could be locked away in a lights-off facility on the other side of the world.
Authentication
Objects on the HSM are encrypted by the owner of the HSM Admin space (rarely) or of the User space (partition), and can be decrypted and accessed only by means of the specific secret injected from the blue PED key (HSM Admin) or the black PED key (User) respectively.
If you cannot present the secret (the PED key) that encrypted the objects, then the HSM is just a secure storage device to which you have no access, and those objects might as well not exist.
Challenge Secrets
When the HSM is PED-authenticated:
> The administrative role secret contained on a black or gray PED key is one secret, used only by administrative personnel.
> The challenge-secret or password is a second secret (plain text, initially presented on the PED screen, but you can change it), which is the application-authentication secret, that allows the HSM verify that the presenting application is entitled to perform cryptographic operations on the particular application partition.
The application can submit its own authentication (that second secret) only after the PED key secret has "opened" the HSM partition for operation (by Activating it). That is, there are two levels of protection: one administrative, and the other operational, where the operational level is gated by the administrative level.
Activation
By default, PED-authenticated partitions require that a PED key and challenge password be provided each time a user or application authenticates to the HSM. For some use cases, such as key vaulting, the need to provide a physical key to access the HSM may be desirable. For most application use cases, however, requiring a physical key each time the application accesses the HSM is impractical.
Activation allows registered users and applications to authenticate to the HSM without a PED key, using only a challenge secret. The PED key secret for the CO or CU role is copied the first time you perform an action that requires authentication, and it is cached on the HSM.
The ability to use activation is determined by its corresponding policy. Enabling this policy will allow you to use activation.
Auto-Activation
In the event of a restart or short power outage, activated roles are deactivated and must re-authenticate with a PED key and challenge secret.
Auto-activation enables automatic re-activation of an activated role, so that users or applications do not have to provide a PED key again to reactivate their role.
The ability to use auto-activation is determined by its corresponding policy. Enabling this policy will allow you to use auto-activation.
Advantages
Using PED authentication, as opposed to password authentication, has the following advantages:
>Security: no written record of the secret or password exists, so it cannot be compromised
>Tracking: access and handling of physical devices (PED keys) can be tracked and controlled
>Duplication restrictions: duplication and promulgation can be prevented by physical security measures
>Physical device: using the PED to input passwords and PEN PINs prevents key-logging exploits that typed passwords are vulnerable to
Disadvantages
PED keys are physical items that can be lost or misplaced, unlike passwords, and thus have the following disadvantages:
>Password change policies: scheduled or mandated password-change cycles in an organization can be logistically intensive when HSMs share PED key secrets
>Inconvenience: handling of secrets requires hands-on, physical action by personnel to perform changes of authentication secrets in case of compromise
