Luna HSM Client allows you to clone keys between Luna 6 partitions, Luna 7 partitions, and Thales Data Protection on Demand (DPoD) Luna Cloud HSM services. This includes creating HA groups made up of different HSM versions. This configuration is useful for:
>migrating your keys directly from Luna 6 to your new Luna 7 HSMs
>migrating your keys from Luna Network HSM 7 to the cloud, or vice-versa
>gradually upgrading your on-premises production environment from Luna 6 to Luna 7 HSMs
>maintaining a real-time, cloud-based backup of your cryptographic objects
This page contains guidelines and general considerations for cloning keys between the different HSMs, or using mixed-version HA groups. Mixed-version HA groups have all the same requirements of standard HA groups (see Planning Your HA Group Deployment), in addition to the considerations listed below.
>Luna On-Premises/Luna Cloud HSM Cloning
>Supported Software/Firmware Versions
>Mismatched Partition Policies and FIPS Mode
>Mismatched Key Types/Cryptographic Mechanisms
>RSA-186 Mechanism Remapping for FIPS Compliance
>Cloning between multifactor quorum and password-authenticated HSM partitions
Luna On-Premises/Luna Cloud HSM Cloning
Cloning between Luna partitions and Luna Cloud HSM services require the following special considerations, in addition to the general considerations below.
NOTE This feature requires minimum Luna HSM Client 10.2.0 for password-authenticated partitions, and minimum Luna HSM Client 10.4.1 for multifactor quorum-authenticated partitions. The scope is expanded with Universal Cloning in Luna HSM Firmware 7.8.0 and Luna HSM Client 10.5.1.
Authentication
Luna Cloud HSM services use password authentication, but you can use them with multifactor quorum-authenticated Luna HSM partitions by importing a domain PED key secret during initialization. This feature requires minimum Luna HSM Client 10.4.1. Refer to Initializing a Luna Cloud HSM Service for the procedure.
NOTE All PED FW versions are currently compatible with Luna Cloud HSM.
Network Latency and Luna Cloud HSM as Active HA Member
Requests performed by cloud services like Luna Cloud HSM may experience greater network latency than those sent to on-premise HSMs. Thales recommends using a Luna Cloud HSM service as a standby HA member to achieve the best performance. By default, you can add a Luna Cloud HSM service as a standby HA member only. If all other HA members fail and the Luna Cloud HSM service becomes active, it will revert to standby when another member recovers.
If you prefer to use the Luna Cloud HSM service as an active HA member, you must first edit the following toggle in the Chrystoki.conf/crystoki.ini configuration file (see Configuration File Summary):
[Toggles]
lunacm_cv_ha_ui = 0
CAUTION! HA failover from multifactor quorum-authenticated Luna partitions to Luna Cloud HSM requires minimum Luna HSM Client 10.5.0. Refer to known issue LUNA-23945.
Cloning Capacity Limitations
The following limitations apply to clients accessing a
>100 token objects (or 50 RSA-2048 key pairs) per
>100 session objects (or 50 RSA-2048 key pairs) per application.
>100 simultaneous sessions per application.
Clients that exceed the token object and session object limits can experience slow or failed request responses. The session limit is enforced, and the client receives the error CKR_MAX_SESSION_COUNT when the application reaches the limit.
If you exceed the recommended maximum number of objects cloned to/from a Luna Cloud HSM service in a single cloning operation, the operation sometimes fails with CKR_DEVICE_ERROR. In the case of HA groups, this could include key creation operations, since objects are then cloned to the Luna Cloud HSM service.
Supported Software/Firmware Versions
Thales supports cloning between Luna 6/7 partitions and Luna Cloud HSM services using combinations of appliance software/firmware as outlined in the table below.
NOTE Luna HSM Firmware 7.7.0 is not compatible with older Luna versions or Luna Cloud HSM.
| Client Software | Luna Appliance Software | Luna HSM Firmware |
|---|---|---|
| Luna only: 10.3.0 or higher | 7.7.0 or higher | 7.7.0 or higher |
|
Luna Cloud HSM with password-authenticated Luna 6/7: 10.2 or higher Luna Cloud HSM with multifactor quorum-authenticated Luna 6/7: 10.4.1 or higher Luna 6/7: 7.2 or higher |
6.2.1 or higher | 6.10.9 or higher |
Mismatched Partition Policies and FIPS Mode
Partitions in an HA group, and the HSMs on which they reside, must be configured with the same policy settings
Ensure that policies common to Luna 6/7/Luna Cloud HSM members have the same settings, according to your deployment requirements.
lunacm:> partition showpolicies
When setting up HA groups, note the following:
>If you are using Luna HSM Client 10.4.0 or newer, you can set up an HA group with a mix of FIPS and non-FIPS partitions as members. However, some limitations must be considered. For more information, refer to Key Replication.
>If you are using Luna HSM Client 10.3.0 or older, you cannot set up an HA group with a mix of FIPS and non-FIPS partitions as members.
Mismatched Key Types/Cryptographic Mechanisms
Cloning is limited to key types that are recognized by the firmware on both HSMs. If an HSM does not recognize the type of key being cloned to it, the cloning operation may fail. Ensure that the firmware on the destination HSM is capable of recognizing all cryptographic objects that are to be cloned to the source HSM.
NOTE Luna HSMs comply closely with the relevant FIPS standards and their generally accepted interpretations. These are moving targets, as the crypto and security climate continues to evolve. It is possible for a validated HSM version (firmware) to be fully compliant when its NIST certificate is issued, and for same-model HSMs with newer firmware and more stringent restrictions to refuse to accept "less secure" objects.
Alternatively, the more up-to-date HSM might accept an object from an earlier-firmware HSM, but permit only limited uses of such an object. This can affect the operation of HA groups, and other situations, where applications attempt operations against old keys, or with the use of antiquated mechanisms.
If you are cloning between HSMs operating in FIPS mode, please consult Supported Mechanisms, for the destination HSM's version, to determine if all key types can be cloned.
Mixed-version HA groups are limited to functions that are common to all member partitions. Mechanisms are added to/removed from new firmware releases, to provide new functionality and fix vulnerabilities. Operations assigned by load-balancing to a member lacking the correct mechanism will fail. Keys created on one member may fail to replicate to the other group members.
Ensure that your applications use only mechanisms that are available on all HA group members. Use LunaCM to see a list of mechanisms available on each partition/service.
lunacm:> partition showmechanism
Minimum Key Sizes
Minimum key sizes are enforced when using certain cryptographic algorithms. These minimums may differ between versions. If a Luna 6 partition creates a key that is smaller than the minimum size required by Luna 7 or Luna Cloud HSM, the key will not be replicated to the other partitions in the HA group.
NOTE Minimum key sizes for many mechanisms are larger in FIPS mode, and FIPS minimums may vary among firmware releases.
To avoid this, use LunaCM to check a mechanism's minimum key size. Check the same mechanism on each HA member slot, and always use the highest minimum reported in the HA group.
lunacm:> partition showmechanism -m <mechanism_ID>
SafeXcel 1746 Co-Processor
Luna 6 HSMs include the SafeXcel 1746 security co-processor, which is used to offload packet processing and cryptographic computations from the host processor. Applications using this co-processor are not compatible with mixed-version HA groups.
The co-processor is not enabled by default. If you have previously enabled it on your Luna 6 HSMs, you can disable it by editing the Chrystoki.conf/crystoki.ini configuration file as follows:
[Misc] PE1746Enabled=0
RSA-186 Mechanism Remapping for FIPS Compliance
Under FIPS 186-3/4, the only RSA methods permitted for generating keys are 186-3 with primes and 186-3 with aux primes. RSA PKCS and X9.31 key generation is not approved in a FIPS-compliant HSM. While Luna 6.10.9 firmware allows these older mechanisms, later firmware does not (and keys created using these mechanisms cannot be replicated to Luna 7 HSMs or Luna Cloud HSM services).
If you have older applications that use RSA PKCS and X9.31 key generation, you can remap these calls to use the newer, secure mechanisms. Add a line to the Chrystoki.conf/crystoki.ini configuration file as follows:
[Misc] RSAKeyGenMechRemap=1
NOTE This setting is intended for older applications that call outdated mechanisms, to redirect calls to FIPS-approved mechanisms. The ideal solution is to update your applications to call the approved mechanisms.
Mechanism remapping is automatic, and ignores the configuration file entry if:
>you are using Luna HSM Client 10.1.0 or newer, and
>HSM firmware is older than Luna HSM Firmware 7.7.1 (which introduced FIPS mode on individual partitions; clients up to and including Luna HSM Client 10.3.0 are unaware of the independent partition setting and do not remap mechanisms).
Luna HSM Client 10.4.0 and newer are aware of the change in Luna HSM Firmware 7.7.1 and perform the mechanism remapping as expected when the current partition is in FIPS mode.
HA Performance Optimization
Luna Network HSM 7 7 provides significant (10x) performance improvements over Luna 6 HSMs. In a mixed-version HA group, operations assigned to Luna 6 member partitions will take longer than those assigned to Luna 7 members. The HA logic does not compensate for these performance differences, and schedules operations on the partition with the shortest queue. Since Luna 7 partitions complete operations more quickly, they will naturally be assigned more operations, but a mixed-version HA group generally does not perform as well as an HA group made up entirely of Luna 7 partitions.
The performance of Luna Cloud HSM services may be limited by network latency, compared to on-premises Luna HSMs. See Luna On-Premises/Luna Cloud HSM Cloning.
Thales recommends that you set a Luna 7 partition as the primary HA member (the first member specified when creating the HA group). All key generation takes place on the primary HA member, so this allows you to take advantage of the Luna Network HSM 7's vastly improved performance for:
>key generation
>random number generation
The load-balancing logic is determined by the Luna HSM Client software, so the Luna 7 behavior applies to mixed-version HA (see Load Balancing).
NOTE The primary HA member may not remain the same over time. If the primary member fails, another member takes over all key generation operations. If you notice a significant drop in performance for key generation operations, it could mean that a Luna 6 partition or Luna Cloud HSM service has become the primary member. By default, a Luna Cloud HSM service will revert to standby once another HA member recovers.
Cloning between multifactor quorum and password-authenticated HSM partitions
Beginning with Luna HSM Firmware 7.8.0 and Luna HSM Client 10.5.0, Extended Domain Management allows you to clone keys and objects between multifactor quorum-authenticated and password-authenticated HSM partitions, including Luna Cloud HSM services, in either direction.
>Luna HSM Firmware 7.8.0 introduced the ability for any partition to have up to three cloning/security domains,
•the original domain, created when the partition is first initialized and,
•one or two more that can, optionally, be added later by command.
>Luna HSM Client 10.5.0 introduced the client-side commands to manage the additional domains.
Prior to Luna HSM Firmware 7.8.0, each application partition had a single domain that was created at partition initialization and remained until the partition was reinitialized or deleted. Cloning operations (including HA and backup) could take place between a partition with a given domain and any other partition (or service) with the same domain.
See Universal Cloning.
