|
Home > |
|---|
Luna HSM roles and authentications cover basic PKCS #11 roles, as well as some additional authentications to support Luna features.
Those roles and authentications have equivalents for Password-authenticated and for PED-authenticated Luna HSMs (with exceptions - see table).
| Role or Feature | Format for Password Authenticated |
Security and Control [see Note 1] |
Format for PED Authenticated |
Security and Control [see Note 2] |
What if I lose/forget this? |
|---|---|---|---|---|---|
| HSM SO (HSM/admin level) |
human-readable password string |
Control access to the HSM. Must trust personnel or somehow control to whom they communicate the password. Change the password whenever personnel depart, or the chain of control and trust lapses. |
Blue PED Key for administrative login at HSM level | Procedures needed to control and track who has access to the PED Key and to the HSM | HSM Administrator/ Security Officer (SO) cannot log in to perform any HSM-level administration, including setting policies, creation or deletion of application partitions. Must re-initialize the HSM, losing all content. |
|
Application Partition SO |
human-readable password string |
Must trust personnel or somehow control to whom they communicate the password. Change the password whenever personnel depart, or the chain of control and trust lapses. |
Blue PED Key for administrative login by partition SO at partition level | Procedures needed to control and track who has access to the PED Key and to the HSM | Application partition Security Officer (SO) cannot log in to perform any partition-level administration, including creation or deletion of Crypto Officer, adjusting policies, etc. Must re-initialize the partition, losing all content. |
| Cloning Domain (HSM/admin level, or per application partition) |
human-readable domain string for setting or authenticating cloning domain between two or more HSMs, or two or more application partitions |
Must trust personnel or somehow control to whom they communicate the cloning-domain string | Red PED Key for setting or authenticating cloning domain between two or more HSMs or two-or-more application partitions | Procedures needed to control and track who has access to the PED Key and to the HSM | Objects on any HSM or on any partition that shares this cloning domain can no longer be cloned to any other HSM or partition or token, including backup/restore or use in an HA group. HSM or partition must be re-initialized (losing all content) and a new cloning domain imprinted. |
| Crypto Officer (per application partition) |
human-readable password string |
Must trust personnel or somehow control to whom they communicate the password - client/application and CO have same password | Black PED Key for admin and role/partition Activation, plus human-readable password string for client app |
Procedures needed to control and track who has access to the PED Key and to the HSM - the text string password for client/application keeps CO management function separate from operational use. |
Application partition Crypto Officer (CO) cannot log in to perform any CO-level administration, including creation or deletion of CU role, or activation of partition for object-modifying operational access by application. PSO must re-create the CO role, losing any objects or subsidiary role that were created by the original CO role. |
| Crypto User (per application partition) |
human-readable password string |
Must trust personnel or somehow control to whom they communicate the password - client/application and CU have same password | Gray PED Key for admin and role/partition Activation, plus human-readable password string for client app |
Procedures needed to control and track who has access to the PED Key and to the HSM - the text string password for client/application keeps CU management function separate from operational use. |
Application partition Crypto Officer (CU) cannot log in to perform any CU-level administration, including activation of partition for object-using operational access by application. CO must re-create the CU role, losing any objects that were owned by that role. |
| Auditor (HSM level) |
human-readable password string |
Must trust personnel or somehow control to whom they communicate the password | White PED Key for administrative login to Audit function | Procedures needed to control and track who has access to the PED Key and to the HSM | Can no longer validate any logs created by that auditor. Existing logs still available (except for any records that were in the HSM, waiting to be exported to a log file), but you can no longer demonstrate trust for audit purposes. Create a new auditor. |
| Remote PED Key (RPK, HSM level) |
N/A | N/A | N/A | Procedures needed to control and track who has access to the PED Key and to the HSM | Cannot perform PED operations remotely with any HSM that shared that RPK. Must generate a new RPK and imprint it on all HSMs that are to be accessed with it, and copies of the new orange PED Key must be brought to all Remote PEDs that will be used with those HSMs. |
| Secure Recovery Key (SRK, HSM level) |
N/A | N/A | N/A | Procedures needed to control and track who has access to the PED Key and to the HSM | Cannot recover from hardware tamper events, or from Secure Transport Mode. If lost SRK was valid (meaning, that portion of the secret existed only on the lost PED Key, and not inside the HSM), then a new SRK cannot be created without return of HSM to Gemalto for re-manufacture; all contents are lost. |
| [Note 1: Always store a written copy of the string in a safe and secure lockup, in case security personnel who have memorized it become unavailable. Have a procedure for accessing that stored copy in time of need (including for updates when passwords are changed - does not apply to domain string, which cannot be changed). Gemalto has no way to recover your lost or forgotten authentication strings. See Note 3, below.] | |||||
| [Note 2: Always make sufficient copies of any important, imprinted PED Keys, sufficient to have at least one on-site backup copy (in secure storage) of each key, and at least one off-site backup copy (in secure storage) of each key. Gemalto has no way to recover lost PED Key data. See Note 3, below.] | |||||
| [Note 3: The HSM does not store authentication secrets; it encrypts material using the authentication secrets. That material can be decrypted temporarily, for use, when those secrets are requested by the HSM and provided by you. The temporary decryption occurs in volatile memory, inside the HSM, and disappears with power loss or at end of session.] | |||||
A basic concept for cryptographic operations with HSMs is the separation of roles. For security and oversight, it is desirable to separate administrative functions from operational cryptographic functions. To that end, Luna HSM products support a variety of roles and users. The different types of HSM, and the options available to them, support a variety of operational and security regimes.
The following diagram summarizes the Cryptoki roles.
Note: In addition to providing the Crypto User password,
a Client application must also pass the user type CKU_RESTRICTED_USER
(or the alias CKU_CRYPTO_USER).
To work with a Partition as Crypto Officer,
OR for applications that use the
existing standard, your application must pass the user type CKU_USER (along
with the Crypto Officer / Partition Owner password). However, this type
now has an alias CKU_CRYPTO_OFFICER, which you might prefer to use for
reasons of clarity. (This concerns you only if you are an application
developer.)
Note: The Partition SO role exists only for HSMs with firmware 6.22.0 or newer, and with Per-Partition SO enabled.
For all other HSMs, the application partitions are administered by the HSM SO.