|
Home > |
|---|
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.
Note: 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. See "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.
•For Luna SA, the PED connection is on the appliance front panel.
•For Luna PCI-E, 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 Luna G5, the PED connection is an external connection to the device (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 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, the various layered roles are protected by a combination of PED Keys and passwords:
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. (Named users can later be added with admin, operator, or monitor authority.) The password is typed at the command line (operator and monitor are restricted identities that have access to subsets of the lunash command set used by admin).
As the appliance admin, you can connect and log in locally, via a serial terminal, or remotely via SSH. With no further authentication, admin can perform general, appliance-level administration (not accessing the HSM), and can run view/list/show/display commands on the HSM that do not make changes.
Admin sees the full available command set, while operator- and monitor-level users see only subsets.
If any administrative user attempts an HSM command that needs authentication, the interface prompts for that authentication. On PED-authenticated systems, you are directed to the PED, which prompts for PED Keys and keypad actions.
EXCEPTION: You can also log in through the local (serial link) console connection as an identity called "recover" (password "PASSWORD").
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 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.
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.
Thus, anyone wishing to issue HSM-wide administrative 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.
To access HSM Partitions to perform Partition-specific administration tasks, such as
•set Partition-specific policies
•assign Partition to Clients
•revoke Clients, etc.
You must be authenticated as Partition User (of which there can be one per HSM on Luna PCI-E or Luna G5, or there can be several on Luna SA -- one for each Partition in the HSM), and for that you use the Partition User black PED Key.
The authentication data for Partition User (also known as Crypto Officer in some security and authentication schemes) 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 on Luna SA, you must first be logged in as admin to have access to lunash commands.
For Luna PCI-E and Luna G5, you simply need access to the host computer, where you can use lunacm commands. For the Partition User/Crypto Officer 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. 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 lunash or lunacm commands to administer the Partition. The Crypto User password allows only a limited set of cryptographic activities via a Client application.
For Luna SA, 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 might vary.
To access HSM Partitions with an application to perform cryptographic operations on data, (for Luna SA only, requires that you connect remotely via SSL as a Client that has been registered by certificate exchange and assigned by the Partition User to this Partition ), 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).
At this point, the two models diverge:
•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 Luna SA 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 (for Luna SA) that gives access to lunash command line. For Luna PCI-E and Luna G5, the password or other authentication that gives access the client application (that uses the HSM for crypto operations) 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.
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.
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.
By default, Luna PED is connected locally, and powered by the HSM using one cable. However, Luna PED can also be used remotely from the HSM or HSMs for which it manages access control. See "About Remote PED".