Password Authentication
In general, there are two paths to access the SafeNet appliance and its HSM:
>The administrative path, via SSH or via local serial link, which uses the LunaSH command-line interface
>The client path, via SSL, by which client applications use the SafeNet Luna Network HSM API to perform cryptographic functions within pre-assigned virtual HSMs (called partitions) on the SafeNet system
For SafeNet Luna HSMs with Password Authentication, the various, layered roles are protected by passwords.
HSM Admin
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 be logged in to LunaSH as admin, then you must further be logged in as HSM Admin (of which there can be only one per SafeNet Luna HSM). Good security practices suggest that the HSM Admin password should be different from the appliance admin password. However, your corporate policies may differ. As the HSM Admin, you can connect locally, via a serial terminal, or remotely via SSH – you must first be logged in as admin to have access to LunaSH commands.
Partition Owner
To access HSM Partitions, in order to perform partition-specific administration tasks (set partition-specific policies, assign Partition to Clients, revoke Clients, etc.), you must be logged in to LunaSH as admin, then you must further be logged in as Partition Owner (of which there can be several - one for each partition in the HSM) , using the Partition Password. Good security practices suggest that the Partition Password should be different from the appliance admin password, different than the HSM Admin password, and different than other Partition Passwords (for other partitions). However, your corporate policies may differ. As the Partition Owner, you can connect locally, via a serial terminal, or remotely via SSH – you must first be logged in as admin to have access to LunaSH commands.
Client
To access HSM Partitions with an application to perform cryptographic operations on data, you must connect remotely via SSL (called NTLS in our implementation) as a Client (one that has been registered by certificate exchange and assigned by the Partition Owner 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). The password used by a Client is the same Partition Password that is used by the Partition Owner for the particular partition. What limits the scope of operations that a registered, authenticated Client can perform on a partition is the fact that partition administrative commands can be issued only via LunaSH. Thus, for security, Clients must not be allowed to learn the appliance admin password that gives access to LunaSH.
Authentication
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 (password) imparted by the HSM Admin or the partition User respectively.
If you cannot present the secret (the password) 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.
NOTE The administrative role secret is also the application-authentication secret: one plain-text secret used for two purposes. On a Password-authenticated HSM, once the administrator (Crypto Officer or Crypto User) has distributed the secret to the application(s), the only way to restrict access by applications (or personnel) that have come into possession of that secret is to change the password - which also changes the authentication for the associated administrative role.
Advantages
Using password authentication, as opposed to PED authentication, has the following advantages:
>Convenience: changing passwords and authentication secrets is easy in the case of personnel changes or suspected compromise
>Direct mapping to organizational policies: password change policies already existing in an organization are easy to map onto a password authenticated framework
Disadvantages
Passwords are less secure than the two-factor authentication provided by the PED, and thus have the following disadvantages:
>Vulnerability to observation: passwords being typed can be easily observed in person, through a camera, or with mal-ware like keystroke loggers
>Record-keeping: secure passwords are obscure and must be written, with its record securely stored
>Accountability: it is difficult to know who might have seen or been told a password
