Cloning Keys Between Luna 6, Luna 7, and Luna Cloud HSM
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 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.
>Supported Software/Firmware Versions
>Mismatched Partition Policies and FIPS Mode
>Mismatched Key Types/Cryptographic Mechanisms
>RSA-186 Key Remapping for FIPS Compliance
Luna/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 client version 10.1. See Version Dependencies by Feature for more information.
Authentication
Luna Cloud HSM services use password authentication, and therefore they can clone objects to and from password-authenticated Luna Network HSMs only. It is not possible to clone keys between a Luna Cloud HSM service and a PED-authenticated Luna 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
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 which 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 services.
| 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 service with Luna 6/7: 10.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
CAUTION! In particular, FIPS mode must be consistent across all HA members (on or off).
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 stored on 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 Key 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.
This remapping is automatic if you are using Luna HSM Client 10.1 or newer, and the configuration file entry is ignored.
HA Performance Optimization
Luna Network HSM 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/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'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.
