Cloning Keys Between Luna 6, Luna 7, and HSM on Demand
Luna HSM Client allows you to clone keys between Luna 6 partitions, Luna 7 partitions, and SafeNet Data Protection on Demand (DPoD)'s HSM on Demand 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 SafeNet 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/HSMoD Cloning
Cloning between Luna partitions and HSMoD 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
HSMoD services use password authentication, and therefore they can clone objects to and from password-authenticated SafeNet Luna Network HSMs only. It is not possible to clone keys between an HSMoD service and a PED-authenticated Luna HSM.
Network Latency and HSMoD as Active HA Member
Requests performed by cloud services like HSMoD may experience greater network latency than those sent to on-premise HSMs. Thales Group recommends using a HSMoD service as a standby HA member to achieve the best performance. By default, you can add an HSMoD service as a standby HA member only. If all other HA members fail and the HSMoD service becomes active, it will revert to standby when another member recovers.
If you prefer to use HSMoD 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 an HSMoD 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 HSMoD service.
Supported Software/Firmware Versions
Thales Group supports cloning between Luna 6/7 partitions and HSMoD services using combinations of appliance software/firmware as outlined in the table below.
| Client Software | Luna Appliance Software | Luna HSM Firmware |
|---|---|---|
|
HSMoD 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/HSMoD 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 SafeNet 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 HSMoD, 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 HSMoD 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
SafeNet 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 HSMoD services may be limited by network latency, compared to on-premises Luna HSMs. See Luna/HSMoD Cloning.
Thales Group 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 SafeNet 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 HSMoD service has become the primary member. By default, an HSMoD service will revert to standby once another HA member recovers.
