Luna HSMs regularly qualify against relevant standards that are important in the information security, data protection, and transaction protection spaces, and for which a business case supports the resource expenditure. Validation is repeated/updated when product changes warrant doing so, according to the respective standards and the requirements of the qualified testing laboratories.. HSM validations are reacquired when major new versions of applicable standards are released, and are also kept up with minor submissions and adjustments when a standard is tweaked or when interpretations shift on the part of testing/validation laboratories.
Under Common Criteria, Thales has looked to qualify our Luna HSM products against eIDAS standards relevant to general purpose hardware security modules.
Luna HSMs are eIDAS certified as Qualified Signature Creation Devices and Qualified Seal Creation Devices (QSCD), and are used by Qualified Trust Service Providers (QTSP) in the role of their root of trust.
See https://cpl.thalesgroup.com/compliance/eidas and https://cpl.thalesgroup.com/compliance/americas/fips-140-2
CC takes the view that a solution is validated for a purpose, which generally means that a number of moving parts are considered in concert. Thus an HSM is evaluated as an element of an overall solution that also includes software products, procedures, and systems all interacting. The following documents provide expanded detail on the relevant topics.
DOW0006186 (KB0023049) is "Thales Luna K7(+) Cryptographic Module COMMON CRITERIA USER GUIDANCE - PART 1: PREPARATIVE PROCEDURES"
DOW0006187 (KB0023050) is "Thales Luna K7(+) Cryptographic Module COMMON CRITERIA USER GUIDANCE - PART 2: OPERATIONAL GUIDANCE"
DOW0006188 (KB0023051) is "Thales Luna K7(+) Cryptographic Module COMMON CRITERIA USER GUIDANCE - PART 3: EIDAS GUIDANCE"
DOW0006189 (KB0023052) is "Thales Luna K7(+) Cryptographic Module COMMON CRITERIA USER GUIDANCE - PART 4 TOE INTEGRATION FOR USE IN COMPOSITE EVALUATION"
The K7 module referred to, in those document titles,
>is the heart of the Luna Network HSM 7 (Luna Network HSM appliance) and
>is also available in a separate PCIe card format for insertion in a host system (Luna PCIe HSM).
| Roles | Principal Duties |
|---|---|
|
HSM Security Officer
|
The HSM SO is responsible for managing the HSM. As such, they are authorized to install and configure the HSM, set and maintain global HSM security policies. They are also able to request the load of new HSM firmware update files (FUF), new Configuration Update Files (CUF) and new Functional Modules (FM). The HSM SO is able to create and delete partitions, but is not authorized to generate, load or use keys stored on the user partitions that have been created. The HSM SO is able to create, manage and use keys created in the Admin Partition alongside is responsible for initializing the ‘Administrator role’. The HSM SO can reset the Administrator password (configuration dependent). The HSM can have only one HSM SO. |
|
[Admin Partition Role] |
The Administrator is authorized to create, use, transfer and destroy key objects contained in the Admin partition. This role has privileges that are a subset of the HSM SO role. |
|
Partition Security Officer (Partition SO)
[User Partition Role] |
The Partition SO creates the partition level Partition CO role, activates partition, sets and changes partition-level policies, with an option to reset the Partition CO password (configuration dependent). |
|
Partition Crypto Officer (Partition CO)
[User Partition Role] |
The Partition CO role is authorized to create, use, destroy and transfer key objects for a given partition. The Partition CO can optionally create the Partition LCO and Partition CU, and perform initial assignment of key authorization data. |
|
Partition Limited Crypto Officer (Partition LCO)
[User Partition Role] |
The Partition LCO is an optional partition role authorized to create and use key objects, and perform initial assignment of key authorization data. The role is only permitted to delete key objects where per-key authorization is used and the correct authorization data for a given key object can be presented to the cryptographic module. |
|
Partition Crypto User (Partition CU)
[User Partition Role] |
The Partition CU is the partition role authorized to use the key objects within the partition (e.g. sign, encrypt/decrypt). |
| Audit User [Admin Partition Role] | The Audit User initializes the secret key used to generate Message Authentication Code (MAC) for secure audit messages alongside configuring logging levels for the HSM. |
|
Key Owner [Admin or User Partition Role] |
Implicit role used to authenticate the owner of a key through verification of the related key authorization data. |
| STC User [Admin or User Partition Role] | The STC user is optional role used with a remote Thales Luna client to initiate a secure tunnel with a target partition. Once successfully authenticated based on pre-registered authentication credentials, the STC user is able to submit commands to the target partition over a trusted channel. |
Network HSM
This section is an overview of how the Luna Network HSM 7 can fit in, and satisfy the requirements for deployment in an environment complying with the demands of Common Criteria.
Consider a fresh/raw from the factory appliance, or an appliance that has been re-imaged (see Re-Imaging the Appliance to Baseline Software/Firmware Versions). You want to use it in a relevant Common Criteria environment, such as eIDAS compliant.
Planning deployment
In order to provide data security in depth, you must house your HSM appliance in a suitably secure environment, and surround it with proper data-handling procedures to ensure the security of your data, or your clients' data, both before it goes into the HSM and after it comes out.
First, where will your network HSM appliance reside?
The document 007-013968-001_K7_CC_User_Guidance_Part1_AGD_PRE_RevE.pdf or newer (available on the Thales Support Portal) goes into the specifics of site selection and site security in more detail, but at the very least consider a dedicated area (secure server farm or data center) with monitored, audited, and controlled physical access by vetted personnel. Also, consider if you have redundancy requirements, necessitating backup/standby/fail-over HSMs, and whether a suitable disaster-recovery plan would require redundant installation at widely separated sites.
The HSM is a secure, tamper-resistant, tamper-evident, hardware cryptographic module, connected to the PCIe bus, and embedded within its host, a network-accessible, hardened, tamper-resistant, tamper-evident, rack-mountable appliance.
For configuration and management of the cryptographic module, and of the appliance that provides network availability, access is achieved via one of the appliance interfaces:
>local serial connection for initial network configuration and for recovery (see Opening a Serial Connection),
>SSH for configuration and management activity of the appliance, and configuration and management of the cryptographic module inside (see Configuring the Luna Network HSM 7 for Your Network),
>NTLS/STC for crypto operations on the HSM, once it has been configured with the proper partitioning and roles(see Client-Partition Connections),
>REST API for appliance management and management and use of the embedded crypto module, once the appliance has been initially configured to the point of launching the webservice that handles REST interactions (see webserver and REST API References).
1.Connect to the appliance, log into the appliance as "admin" and change the password (see Logging In to LunaSH).
2.Configuring IP and Network Parameters.
3.Enable the built-in appliance Monitor and appliance Operator accounts if your situation will make use of administrative users who require less than the full "admin" access/authority, or alternatively create any named users that have desired levels of access. This can be revisited later.
•You can make accounts that copy the access of the default accounts, but give them names that are more appropriate in your situation/industry/market.
•As well, you can go further and create named appliance administrative accounts that have access to only a specific list of commands that you choose for them.
To access the cryptographic module, within the Luna Network HSM 7, for administrative operations, you log into the outer appliance as users, to which are applied roles that specify the set of appliance-administration commands that role can use, and the set of crypto-module commands that role can access (see Appliance Users and Roles)and see also CustomRoleTemplate for a list of all appliance-admin and HSM/crypto-module-admin commands (except Audit user commands) that you can copy or edit for fine control of access by a named user/role.
Equally as important, you should determine who is permitted access to the appliance via any of the appliance roles. That is, you must have processes and procedures, developed and approved in advance,
•to track and control who can have possession of appliance-level and crypto-module-level credentials,
•along with predetermined responses to possible compromise of personnel or credentials, and
•standing practices with respect to refresh or rollover of credentials (password-change interval).
4.Initialize the HSM and log in (this presupposes successful appliance login, as the HSM or cryptographic module resides within the appliance).
a.If the HSM is Password authenticated, then all roles and activities within the HSM are protected by text strings, which must be secured by procedures that mandate who is allowed to know them, and that frequently rotate/change passwords. Password security is basically "the honor system"; you must trust your personnel to keep the authentication text strings secure.
b.If the HSM is multi-factor quorum authenticated then the iKey (PED Key) tokens must be physically and procedurally managed to ensure that only authorized personnel have access. For the most sensitive roles, you can split an authentication secret such that a quorum of trusted personnel must present their portions in order to gain access. Separation of roles is ensured by separating who is able to physically access the relevant physical tokens while also knowing the passcode (PED PIN) associated with an iKey token.
5.Initialize partitions that will be the logically distinct areas within the HSM where your important keys and data objects are handled. The HSM Security Officer (SO) has overall management authority over the HSM (including creation and deletion of partitions), but you can configure such that the HSM SO has no view or access inside partitions. Partition SOs have administrative authority inside their partition and create the roles (Crypto Officer, Limited Crypto Officer, Crypto User that provide application access to perform cryptographic operations.
Options to perform partition management include:
>doing so via ssh session to the appliance, using the lunash commands (Luna Shell is a restricted shell within the hardened Network HSM appliance, that accesses and implements all the features and capabilities, see About the LunaSH Command Reference) - this might be done in situations where the HSM SO is also expected to own other roles
>using a client NTLS
•Network Trust Link Service (see Client-Partition Connections), the default SSL-based protocol secured with self-signed or CA-signed certificates, between the client and the network HSM appliance that then passes commands and results to and from the embedded cryptographic module
or
using an STC connection (see Creating an STC Connection)
•Secure Trusted Channel, provides a tunnel from the remote application directly into the HSM, affording confidentiality, integrity, and anti-replay protection for data submitted from outside the cryptographic module
...in either case, making use of lunacm and other client-side tools - this is the approach when partition and application-related roles are held separately from HSM administration
>using the REST API (see REST API References) to provision and manage the HSM - once the appliance admin has launched the webserver, the REST API provides equivalents to the lunash commands.
6.Exchange certificates and register client hosts with the partitions where your application(s) will create and use crypto keys and objects.
The HSM maintains all contents encrypted, as a matter of course, and decrypts them only in temporary memory for immediate use. In the case where large numbers of keys/objects must be securely maintained, the Scalable Key Storage option (SKS Scalable Key Storage - requires firmware 7.7.0 onward) allows those keys and objects to be exported to your file system or database in the form of encrypted blobs. The SKS Master Key (SMK) that encrypts/decrypts those blobs, is itself always protected within an HSM/cryptographic module. Your keys and objects, stored in blob form, are brought back to the HSM when your application needs to use them. This extends the HSM's cryptographic perimeter and complies with any requirement that sensitive data be kept logically separate from other data in the IT environment.
The secure handling and management of (for example) Data To Be Signed (DTBS), coming to the HSM, and the result (such as a signature) coming from the HSM is the responsibility of you and the application(s) that you use.
Audit
The HSM logs events within the HSM. You must initialize the Audit role within the HSM, to configure the criteria (such as event severity, whether certain key usage is logged for first use only, or for every use, etc.), to ensure a balance between logging necessary for the regime under which you operate, and the effect on cryptographic performance as logging demands increase. The more events are logged, the faster the HSM memory fills, and the more urgent the need for you to configure rotation of log entries off the HSM and into log files in the host file-system. The secure audit function ensures that audit log integrity can be validated. It is then your responsibility to secure the further handling of such logs within your organization.
The appliance also logs system events, which is a separate function from HSM logging.
The HSM (cryptographic module) and the appliance that hosts it provide their logs (as configured), but what you do with them is determined by the security regime under which you operate.
Compliance
Common Criteria validation ensures that a given version of HSM is suitable and can be used in conformity with the stipulated behaviors within the larger framework of operational security for applications and services. Thales Group regularly submits HSM products for Common Criteria evaluation, and provides links and updates as appropriate.
