Home >

Appliance Administration Guide > Configuration without One-step NTLS > [Step 1] Planning Your Configuration > Crypto Officer & Crypto User

Crypto Officer & Crypto User

An available security layer is required in some security and authentication schemes, as follows:

For those who need the additional distinction, the Partition Owner role (black PED Key) can optionally be subdivided into two further roles:

 - Crypto Officer
 - Crypto User

In the past, and continuing, the separation of roles on the SafeNet HSM follows the standard Cryptoki model:

appliance admin

This is the basic administrative access to the a SafeNet HSM appliance. When you connect via ssh (putty.exe or other ssh utility), the SafeNet HSM presents the "login as:" prompt. The only ID that is accepted is "admin".

Note:  Use of older PuTTY versions, and related tools, can result in the appliance refusing to accept a connection. This can happen if a security update imposes restrictions on connections with older versions. To ensure compatibility, always use the versions of executable files included with the current client installer.

You must be logged in as the appliance "admin" before you can access further authentication layers such as HSM Admin, Partition Owner, Crypto Officer.   

The appliance "admin" performs network administration and some other functions that do not require the additional authentication. Therefore, by controlling access to passwords (for a SafeNet HSM with Password Authentication) or to PED Keys (for a SafeNet HSM with Trusted Path Authentication), you can compartmentalize the various administrative and security roles.   

HSM Admin

HSM Admin has control of the HSM within the a SafeNet HSM appliance. To access HSM Admin functions, you must first be logged in as appliance admin.   

In addition to all the other appliance functions, a user who has authenticated with the HSM Admin password (for a SafeNet HSM with Password Authentication) or the HSM Admin (blue) PED Key (for a SafeNet HSM with Trusted Path Authentication) can:

create and delete Partitions,

create and delete Partition Owners (black PED Key holders on a SafeNet HSM with Trusted Path Authentication only),

backup and restore the HSM,

change HSM Policies, etc.

HSM Partition Owner (or User)

HSM Partition Owner has control of one or more Partitions (virtual HSMs) within the SafeNet HSM appliance. To access HSM Partition Owner functions, you must first be logged in as appliance admin.

In addition to all the other appliance functions, a user who has authenticated with the HSM Partition Owner (black) PED Key (for a SafeNet HSM with Trusted Path Authentication) can:

modify partition policies

activate a partition for use by Clients

backup and restore Partition contents

Note:  Both a SafeNet HSM with Password Authentication and a SafeNet HSM with Trusted Path Authentication have at least two layers of access control for an HSM Partition:
- the appliance admin login
- the Partition authentication

Note:  SafeNetHSM with PED (Trusted Path) Authentication, splits the Partition access into two layers.  The HSM Partition Owner (a concept that exists only for a SafeNet HSM with PED Authentication) first authenticates to the Partition with the appropriate black PED Key, then activates the Partition for Clients. Thereafter, each Client must further authenticate with the Partition Password (generated by SafeNet PED when the Partition is created).

Note:  For SafeNet HSM with Password Authentication, the Partition Password is the only layer of authentication to a Partition. Therefore, any Client with that password has access to the Partition. What prevents a Client from manipulating objects on the Partition and performing Partition administration activities is the need to access the lunash command shell.

Note:  Therefore, in both access-control models, a Client with the Password can connect and perform object generation and deletion, and can use objects (sign, verify, encrypt, decrypt), but they cannot perform Partition management operations unless they can also login to LunaSH (lunash) as admin.

Client

A Client is a "working" or "production" user of one or more SafeNet Network HSM Partitions, that connects from a client computer (one that has set up a network trust link (NTL) by exchanging certificates and registering with the SafeNet Network HSM). If a Client can provide the Partition Password, it can generate, delete, and use cryptographic objects (keys and certificates) on the Partition, as long as the Partition is prepared to accept the connection.

In the case of SafeNet Network HSM with Password Authentication (assuming the HSM Partition has been previously created with the Password), the appliance simply needs to be powered on.

In the case of SafeNet Network HSM with Trusted Path Authentication (assuming the HSM Partition has been previously created and the Client given the Partition Password), the Partition must also be activated by the Partition Owner. That is, a Client, even with the proper Password cannot access a SafeNet Network HSM Partition unless that Partition has been placed in "activated" state by the HSM Partition Owner (using the black PED Key).

That authentication model continues unaffected, for those who prefer it. However an optional, enhanced Cryptoki model is also available, to separate the Partition Owner or Partition User role into a read-write entity and a separate read-only entity:

appliance admin

(Same as appliance admin description above. No change.)

HSM Admin

(Same as HSM Admin description above. No change.)

Crypto Officer (full Read-Write access)

(same capabilities as HSM Partition Owner and Client in the default model)

As above for HSM Partition Owner, except that two separate Passwords can now (optionally) be associated with the black PED Key. In both cases, the black PED Key must be presented, and the administrator at the lunash command-line can:

modify partition policies

activate a partition for use by Clients

backup and restore Partition contents   

The Partition Password is presented when a Client application needs to use the Partition. In this model, there are two Passwords. The Crypto Officer Partition Password allows the Client to perform any crypto-graphic operation, both manipulation (generation, deletion, wrap/unwrap), and use (encrypt/decrypt, sign/verify).   

The other password is used (along with the black PED Key) for the Crypto User. This is set by the HSM Admin when the Partition is created.

In operation, the Crypto Officer would log in at the management interface prompt for Partition maintenance tasks,

and/or

a Client application could connect to a registered Partition (authenticating with the Crypto Officer Password) in order to generate and manipulate cryptographic objects in the Partition.   

Crypto User   (or restricted Client user - Read-only)   

If the Partition has been readied for access by the black PED Key, a Client can connect with a Client application, authenticating with the Crypto User Password (a challenge secret, generated on command by the SafeNet PED, similar to the Crypto Officer or Partition Owner Password that is generated on the SafeNet PED when a Partition is created).   

The Crypto User Client can then make use of cryptographic materials already in the Partition (signing, verifying, encrypting, decrypting), but cannot manipulate those objects (no generating or deleting or wrapping/unwrapping).   

This distinction differs from the old model, with just the one Partition Password, where Client users could not be restricted from generating and deleting keys and certificates.   

Either model can be used. If you work in an environment that mandates the Crypto Officer / Crypto User distinction, it is available. If you have no need of the additional password, or if you have legacy applications that use the standard Cryptoki roles, then simply do not activate the Crypto Officer / Crypto User roles.

How the Roles are Invoked

By default, the Crypto User role does not exist, and so the black PED Key owner is HSM Partition Owner. You create a Crypto User (the restricted Client user) with the "partition createUser" command.

Bad Login Attempts

By default, both the Crypto Officer and the Crypto user can make 10 consecutive failed login attempts before invoking consequences. That is, the two bad-authentication counters are independent of each other.

Submissions of incorrect Partition Passwords (or Crypto Officer and Crypto User Passwords) are not counted as incorrect black PED Key attempts.

Note:  The SafeNet HSM must actually receive some information before it logs a failed attempt, so if you merely forget to insert a PED Key, or provide a wrong-color key, then that is not logged as a failed attempt. When you successfully login, the bad-attempt counter is reset to zero.