Show the Table of Contents

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 Luna HSM follows the standard Cryptoki model:

• appliance admin

  This is the basic administrative access to the a Luna HSM appliance. When you connect via ssh (putty.exe or other ssh utility), the Luna HSM presents the "login as:" prompt. The only ID that is accepted is "admin".
  
  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 Luna HSM with Password Authentication) or to PED Keys (for a Luna 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 Luna 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 Luna HSM with Password Authentication) or the HSM Admin (blue) PED Key (for a Luna HSM with Trusted Path Authentication) can:

  • create and delete Partitions,
  • create and delete Partition Owners (black PED Key holders on a Luna HSM with Trusted Path Authentication only),
  • backup and restore the HSM,
  • change HSM Policies, etc.
• HSM Partition Owner

  HSM Partition Owner has control of one or more Partitions (virtual HSMs) within the Luna 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 Luna HSM with Trusted Path Authentication) can:

  • modify partition policies
  • activate a partition for use by Clients
  • backup and restore Partition contents

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

  Luna HSM with PED (Trusted Path) Authentication, splits the Partition access into two layers.  The HSM Partition Owner (a concept that exists only for a Luna 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 Luna PED when the Partition is created).

  For Luna 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.

  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 Luna Shell (lunash) as admin.

• Client

  A Client is a "working" or "production" user of one or more Luna SA HSM Partitions, that connects from a client computer (one that has set up NTLS by exchanging certificates and registering with the Luna SA). 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 Luna SA 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 Luna SA 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 Luna SA 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 European Cryptoki model is also available:

• appliance admin

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

• HSM Admin

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

• Crypto Officer (same capabilities as HSM Partition Owner and Client in the old 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 lunash 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)

  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 Luna PED, similar to the Crypto Officer or Partition Owner Password that is generated on the Luna 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.

Please note that the Luna SA 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, that is not logged as a failed attempt. When you successfully login, the counter is reset to zero.

See also "Cryptoki Roles Diagram".

Show the Table of Contents