The security of an HSM and its cryptographic contents depends on well-controlled access to that HSM. A controlled access policy is defined by:
>the set of users with valid login credentials for
>the actions each user is allowed to perform when logged in (the user's role)
For example, an access policy that adheres to the PKCS#11 standard requires two roles: the security officer (SO), who administers the user account(s), and the standard user, who performs cryptographic operations. When a user logs in to the HSM, they can perform only those functions that are permitted for their role.
All cryptographic operations take place on an application partition. This partition is created on the HSM by the HSM SO and assigned to a registered client over a network (see Application Partitions). Partition roles allow the partition to function as an independent virtual HSM, with its own Security Officer and users. This design provides more flexibility in meeting the security needs of your organization. Personnel holding the roles described below must have administrative access to a client workstation with a partition assigned to it and Luna HSM Client installed. They do not require SSH access to LunaSH on the Luna Network HSM 7 appliance.
The partition-level roles are as follows:
Partition Security Officer (PO)
The Partition SO handles all administrative and configuration tasks on the application partition, including:
>Initializing the partition, setting the PO credential, and setting a cloning domain for the partition (see Initializing an Application Partition)
>Configuring partition policies (see Partition Capabilities and Policies)
>Initializing the Crypto Officer role (see Initializing the Crypto Officer Role)
>Activating the partition (see Activation on Multifactor Quorum-Authenticated Partitions)
Managing the Partition SO Role
Refer also to the following procedures to manage the PO role:
>Logging In to the Application Partition
>Changing a Partition Role Credential
Crypto Officer (CO)
The Crypto Officer is the primary user of the application partition and the cryptographic objects stored on it. The Crypto Officer has the following responsibilities:
>Creating, deleting, and modifying cryptographic objects via user applications
>Performing cryptographic operations via user applications
>Managing backup and restore operations for partition objects (see Partition Backup and Restore)
>Create and configure HA groups (see Setting Up an HA Group)
>Initializing the Crypto User role (see Initializing the Crypto User Role)
>The CO can modify keys - must provide per-key authorisation (PKA) data for unassigned keys
>The CO can unblock blocked (due to per-key auth failures) PKA keys
>The CO can increment usage counters and change/set the limit
>The CO can perform SMK rollover
Managing the Crypto Officer Role
Refer also to the following procedures to manage the CO role:
>Logging In to the Application Partition
>Changing a Partition Role Credential
Limited Crypto Officer (LCO)
The Limited Crypto Officer is a role needed for eIDAS compliance and the performance of Per Key Authorization functions, with a subset of the abilities and responsibilities of the Crypto Officer, but wider authority and ability than the Crypto User. The LCO is created by the partition CO. The LCO role is visible and accessible in V1 partitions if the Client software version is 10.3 or newer. The Limited Crypto Officer has the following abilities and responsibilities:
>Creating, deleting, and modifying cryptographic objects via user applications
>Performing cryptographic operations via user applications
•The LCO can copy and modify keys and private objects- must provide per-key authorisation (PKA) data for unassigned keys
•The LCO can increment usage counters, but cannot change/set the limit
•The LCO cannot unblock blocked (due to per-key auth failures) PKA keys
•The LCO can wrap/unwrap keys - must specify the per-key auth data for both the wrapping/unwrapping keys and the wrapped/unwrapped keys
•The LCO can derive keys - must provide the per-key auth data for the key used for derivation and specify the per-key auth data for the key being derived in the template
•The LCO can derive-and-wrap - must provide per-key auth data as above
•The LCO can perform SKS operations (SIMExtract / SIMInsert)
•The LCO cannot perform SMK rollover
>Creating and configuring HA groups (see Setting Up an HA Group)
>Initializing the Crypto User role (see Initializing the Crypto User Role)
Managing the Limited Crypto Officer Role
Refer also to the following procedures to manage the LCO role:
>Logging In to the Application Partition
>Changing a Partition Role Credential
>The LCO role does not support cloning
>The LCO role is not visible for V0 partitions.
>The LCO role is subject to role-affecting partition policies like
•Minimum PIN length [25]
•Maximum PIN length [26]
•Maximum failed challenge responses [15]
•Maximum failed user logins allowed [20]
–Upon reaching the limit, the LCO is locked out; CO and CU remain operational
–Partition CO can unlock a locked LCO by resetting its credentials
>The LCO can create and destroy private objects
>The LCO can generate keys assigned or unassigned, but cannot assign a key after it is generated.
>The LCO can delete keys
•Unlike CO role, LCO must provide per-key authorization (PKA) data
•LCO supports the “single-use signing keys” scenario where a user generates a key, signs with that key, and deletes the key
>The LCO can modify keys - must provide per-key authorisation (PKA) data for unassigned keys
>The LCO can increment usage counters but, unlike CO, cannot change/set the limit
>The LCO can wrap/unwrap
•PKA behaviour for wrap: must provide the per-key auth data for both the wrapping and the wrapped keys
•PKA behaviour for unwrap: must provide the per-key auth data for unwrapping key and specify the per-key auth data for the unwrapped key in the template
>For PKA operation
•The LCO can derive keys
•The LCO can derive-and-wrap
>The LCO can extract/insert in all scenarios
•Including SKS key migration (old SKS: Insert; no Extract)
•Including new SKS (Extract and Insert)
>The LCO cannot clone/replicate in any scenario - this means that LCO is not self-sufficient for HA; the CO is needed to clone SMK(s)
>Unlike the CO, the LCO cannot perform SMK rollover
Crypto User (CU)
The Crypto User is an optional role that can perform cryptographic operations using partition objects in a read-only capacity, but can create only public objects. This role is useful in that it provides limited access; the Crypto Officer is the only role that can make significant changes to the contents of the partition. The Crypto User has the following capabilities:
>Performing operations like encrypt/decrypt and sign/verify using objects on the partition
>Creating and backing up public objects (see Partition Backup and Restore)
>The CU can increment usage counters but, unlike CO, cannot change/set the limit
Managing the Crypto User Role
Refer also to the following procedures to manage the CU role:
