Domain Planning and Key Cloning
You can clone key material between partitions to back up the keys, or to migrate the keys from one HSM to another. The rules, prerequisites, and procedures for migrating your key material are described in the following topics:
>Cloning Objects to Another Application Partition
>Domain Planning and Key Cloning
•Mismatched Partition Policies and FIPS Mode
•Mismatched Key Types/Cryptographic Mechanisms
Overview and Key Concepts
A Crypto Officer can clone the cryptographic objects (keys) from one user partition to another user partition provided that:
>The user partitions share the same domain. See Domain Planning.
>The user partitions use the same authentication method (iKey or password).
>The CO has the required credentials on both user partitions.
>The capabilities and policies set on the source and target HSM and user partitions allow cloning. See HSM Capabilities and Policies and Partition Capabilities and Policies.
Domain Planning
The cloning or security domain is an element of Layered Encryption.
What is a security domain or cloning domain?
A security domain or cloning domain is a layer of encryption that is created, during initialization, on an HSM or HSM partition that you control. The domain determines whether a cryptographic object can leave the HSM, and where it can go if it is allowed to leave.
Cloning is a secure-copy operation by which sensitive HSM objects are copied, while strongly encrypted, from one HSM to another HSM. The security domain, or cloning domain, is a special-purpose secret that is attached to a partition on an HSM. It determines to which, and from which, other partitions (on the same HSM or on other HSMs) the current partition can clone objects. Partitions that send or receive partition objects by means of the cloning protocol must share identical cloning domain secrets. That is, the protocol verifies that the destination domain matches the source domain; otherwise an error is displayed and the attempted operation fails. This is important for cloning in backup and restore operations.
Only one domain per partition - no copying across domains
An application partition can have one cloning domain. It is not possible to clone objects from two or more different cloning domains to a single partition. By design, there is no provision to change the cloning domain of a partition without initializing it, which destroys any objects in that partition.
No common domains across password-authenticated and multifactor quorum-authenticated HSMs
Password-authenticated application partitions with identical security domains can clone partition contents one to the other, if the partition policies support cloning.
Multifactor Quorum-authenticated application partitions with identical security domains can clone partition contents one to the other, if the partition policies support cloning.
Password-authenticated HSM partitions cannot perform cloning with multifactor quorum-authenticated HSM partitions.
The security design consideration is that, if you have a key or object stored in a multifactor quorum-authenticated partition:
>It cannot be altered to a less-secure state and moved outside the protection of its original security/cloning domain.
>You are assured that the key or object has never been outside its original security/cloning domain, or in any less-secure state.
Characteristics of Cloning Domains
Password-authenticated HSMs have text-string cloning domains for the HSM admin partition and for any partitions that are created on the HSM. HSM and Partition domains are typed at the command line of the client computer, when required. Password authentication cloning domains are created by you.
Multifactor Quorum-authenticated cloning domains are created by a Luna HSM, which could be the current HSM, or a previously-initialized HSM that you wish to include in a cloning group with the current HSM. Multifactor Quorum-authenticated HSMs have cloning domains in the form of encrypted secrets on red iKeys, for the admin partition and for any partitions that are created on the HSM.
The following characteristics are common to security (cloning) domains on all Luna HSMs.
>The unique admin partition security domain can be created in the HSM at initialization time, or it can be imported, meaning that it is shared with one-or-more other HSMs.
>The application partition security domain can be created by the current HSM when the partition is initialized, or it can be imported, meaning that it is shared with one-or-more other HSM partitions, and therefore direct cloning and backup/restore can be performed among the partitions that share a given domain.
>The application partition security domain is usually distinct from the HSM domain, as they are controlled by different people; on multi-partition HSMs, the PSO is usually not the same person as the HSM SO, but on a single-partition HSM the two SOs might be the same person.
>The application partition security domain can be the same as the domain of another partition on the same HSM (for HSMs that support multiple partitions).
For multifactor quorum-authenticated HSMs, the domain secret for the admin partition or for an application partition can be a single red iKey, or it can be split (by the MofN quorum feature) over several red keys, which are then distributed among trusted personnel such that no single person is able to provide the cloning domain without oversight from other trusted personnel.
In scenarios where multiple HSM partitions are in use, it can be useful to segregate those partitions according to department or business unit, or according to function groups within your organization. This ensures that personnel in a given group are able to clone or backup/restore only the contents of partitions sharing the domain for which they are responsible. The segregation is maintained by physical and procedural control of the relevant iKeys that each group is allowed to handle.
For password-authenticated HSMs, that sort of segregation is maintained entirely by procedure and by trust, as you rely on personnel not to share the domain text strings, just as you rely on them not to share other passwords.
Have your naming conventions and allotments planned out ahead of HSM initialization and partition creation, including a well-thought-out map of who should control cloning domain access for admin partitions and for application partitions. These decisions must be made before you create the partitions.
Cloning Objects to Another Application Partition
You can back up partition objects from an application partition to any other partition that shares its cloning domain. The Crypto Officer of both partitions can perform this operation using LunaCM.
Prerequisites
>Partition policy 0: Allow private key cloning must be set to 1 (ON) on both the source and target partitions.
>The target partition must be initialized with the same cloning domain as the source partition.
>You require the Crypto Officer credential for both the source and the target partition.
>Both partitions must be visible as slots in LunaCM.
>[Remote PED] This procedure is simpler when both partitions are activated (see Activation on Multifactor Quorum-Authenticated Partitions). If the partitions are not activated, you must connect the source partition to PEDserver before logging in, disconnect it, and then connect the target partition to PEDserver by specifying its slot.
lunacm:> ped connect [-ip <IP>] [-port <port>]
lunacm:> ped disconnect
lunacm:> ped connect -slot <target_slot> [-ip <IP>] [-port <port>]
To clone partition objects to another application partition
1.In LunaCM, set the active slot to the source partition and log in as Crypto Officer.
lunacm:> slot set -slot <slotnum>
lunacm:> role login -name co
2.[Optional] View the partition objects and their object handles.
lunacm:> partition contents
3.Clone objects on the partition to the target partition by specifying the target slot. You can choose which objects to clone by specifying a comma-separated list of object handles, or specify all to clone all objects on the partition. Present the target partition's Crypto Officer credential when prompted.
lunacm:> partition clone -slot <slotnum> -objects <comma-separated_list/all>
The specified objects are cloned to the target partition. Any objects that already exist on the target are not cloned.
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 USB 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/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.
Authentication
Luna Cloud HSM services use password authentication, and therefore they can clone objects to and from password-authenticated Luna USB HSM 7s only. It is not possible to clone keys between a Luna Cloud HSM service and a multifactor quorum-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 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.
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.
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.
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>
