You are here: Administration & Maintenance Manual > HSM Administration > Authenticating - PED and Password > PED (Trusted Path) Authentication - About

About Trusted Path Authentication

Front-view drawing of Luna PED A picture of an iKey PED Key, with no label.

This section applies to versions of SafeNet HSM that control access via Trusted Path Authentication - that is, HSMs that control access by means of the PED and PED Keys, rather than by typed-in text strings. For Luna HSMs, this is sometimes referred to as "FIPS 140-2 Level 3" or simply "FIPS Level 3" or "FIPS 3" authentication.

If you did not receive a Luna PED and PED Keys, then your Luna HSM probably uses Password Authentication, and not Trusted Path Authentication (verify with the hsm displayLicenses command), and the pages in this section do not apply to you.
"About Password Authentication", instead.

You can also verify the type of a Luna HSM by running the hsm showPolicies command. The output includes these lines near the top:
Description                          Value
===========                          =====
Enable PIN-based authentication                   Disallowed
Enable PED-based authentication               Allowed

The above result is from a PED-authenticated HSM.
A Password-authenticated HSM would show:
Description                           Value
===========                           =====
Enable PIN-based authentication             Allowed
Enable PED-based authentication      Disallowed

The Trusted Path is the connection between the Luna PED and the Luna HSM front panel. For local PED, the connection is a secure physical link, directly to the HSM, bypassing the computer memory and bus. For Remote PED, the connection is a cryptographically secured link across the network - when credentials travel between PED and HSM, they are encrypted throughout the journey. 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 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 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.

For SafeNet HSM with Trusted Path Authentication (see this diagram), the various, layered roles are protected by a combination of PED Keys and passwords:

appliance admin - more -
When you login to the Luna appliance via lunash the accepted IDs are "admin" which requires the admin password, "operator", which requires the operator password, or "monitor" which requires the monitor password. The password is typed at the command line (operator and monitor are restricted identities that have access to subsets of the lush command set used by admin).
As the appliance admin, you can connect and login locally, via a serial terminal, or remotely via SSH. With no other authentication, admin can perform general, appliance-level administration (not accessing the HSM).
EXCEPTION: You can also log in through the local (serial link) console connection as an identity called "recover" (password "SafeNet")
HSM Admin or Security Officer - more -
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 logged in to lunash as admin, then you must further be authenticated as SO or HSM Admin(of which there can be only one per Luna HSM) .

The authentication data for SO/HSM Admin is not a password. It is a secret carried on a blue PED Key. As the HSM Admin, you can connect locally, via a serial terminal, or remotely via SSH. You must first be logged in as appliance admin to have access to lunash commands (there is no provision for performing HSM administration via a Client connection).

For the SO to login and issue HSM commands, someone must be present at the connected Luna PED to insert the required blue PED Key, when prompted. Otherwise, HSM commands cannot be used.

Thus, anyone wishing to issue HSM commands to the Luna appliance must be present in the room with the Luna PED, and must have the cooperation of the SO/HSM Admin blue PED Key holder (who, in turn, needs physical access to the connected Luna PED).

The options are to perform such authentication via a PED connected physically to the HSM appliance, or to perform authentication via a PED connecting through a secured Remote PED connection.
Partition User (or Crypto Officer) - more -
To access HSM Partitions to perform Partition-specific administration tasks, such as
you must be logged in to lunash as admin, then you must further be authenticated as Partition User(of which there can be several -- one for each Partition in the HSM) , using the Partition User black PED Key.

The authentication data for Partition User/Crypto Officer is both a password and a secret carried on a black PED Key. As the Partition User/Crypto Officer, you can connect locally, via a serial terminal, or remotely via SSH. To perform Partition administration, you must first be logged in as admin to have access to lunash commands. There is no provision for performing Partition administration via a Client application.

For the Partition User/Crypto Officer to login and issue Partition administration commands, someone must be present at the connected Luna PED to insert the required black PED Key, when prompted or the Partition must have been left in Activated state. Otherwise, Partition administration commands cannot be used.
If you have invoked the Crypto Officer/Crypto User distinction, then there are two Partition Passwords, but only the Crypto Officer password allows you to run lush commands to administer the Partition. The Crypto User password allows only a limited set of cryptographic activities via a Client application.
Good security practices suggest that the Partition Password should be different than the appliance admin password and different than other Partition Passwords (for other Partitions). If Crypto Officer/Crypto User are in force, then their passwords should differ as well. However, your corporate policies may vary. As the Partition User, you can connect locally, via a serial terminal, or remotely via SSH, but you must first be logged in as admin to have access to lunash administration commands.
Client (or Crypto User) - more -
To access HSM Partitions with an application to perform cryptographic operations on data, you must connect remotely via SSL as a Client(one that has been registered by certificate exchange and assigned by the Partition User to this Partition ) , then pass a User-type (this is done invisibly by your client application), and present the Partition Password (also done automatically by your application).

At this point, the two models diverge:

What's The One-Sentence Summary of How This Works?

How about two sentences?

Objects on the HSM are encrypted by the owner of the HSM Admin space 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.

Audit

Not mentioned above is the 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. These roles are distinct and separate from other roles on the appliance and the HSM, conforming to the requirements of auditing standards.