At the highest level, Key Migration is a facility to move keys securely between our various forms of HSMs. The list of HSMs currently includes the Luna Network HSM 7 appliance, Luna PCIe HSM 7, Luna Backup HSM G5), and Luna USB HSM 7 form factors, as well as Luna Cloud HSM services.
The Luna HSM product has two main requirements on where and how keys can be shared:
>I want my keys to exist only in Thales Luna HSMs.
>I want my keys to exist only in Thales Luna HSMs/Partitions that I control.
What is universal cloning?
Universal cloning is the combination of two features added by Luna HSM Firmware 7.8.0 and client Luna HSM Client 10.5.0:
>Cloning protocol version 4 (CPv4), which makes new cipher suites available to the cloning process and adds flexibility in handling and choosing among options
>Extended Domain Management, which adds the ability for a partition to have up to three cloning domains, any of which can be text-strings (Password Authentication) or can be multifactor quorum secrets, regardless of the nominal authentication mode of the current partition.
Prior to Luna HSM Firmware 7.8.0, Luna HSM partitions were generally limited to cloning objects between partitions that had the same single cloning security domain. As of firmware 7.8.0 and newer, application partitions can each optionally have as many as three cloning domains, and these can be added and deleted without risk to keys and other objects contained within the partition. With firmware 7.8.0 and client Luna HSM Client 10.5.0 the introduction of Extended Domain Management along with cloning protocol version 4 (CPv4) - increases your flexibility in choice of form factor:
>Originally chose on-premises HSM, but want to move to the cloud.
>Originally chose the cloud but have a need to repatriate back to on-premises HSM.
>Want to use both types seamlessly, such as in hybrid HA groups.
Extended Domain Management allows you to specify the source of a partition's domain, and provides the ability to have more than one domain in a partition, permitting:
>changing/rollover of cloning domains similar to what is done for passwords when your security regime mandates a refresh/rollover/password-change interval for all forms of authentication,
>migration of keys and objects between multifactor quorum authenticated partitions using authentication secrets on ikeys and
>migration of keys and objects between password authenticated partitions (on-premises HSMs) and services (Luna Cloud HSM) using text strings,
>migration of keys and objects between on-premises multifactor quorum authenticated HSM partitions and password authenticated partitions that share a common domain.
>migration of keys and objects between on-premises multifactor quorum authenticated HSM partitions and Luna Cloud HSM services that share a common domain.
In other words, if at least one of [as many as] three domain secrets on one partition is a match for at least one domain on the other partition, you can migrate objects between them. If more than one domain matches, then if one has been set as primary, that one is selected for the operation.
Enabling before using CPv4
To enable the use of CPv4, the HSM Security Officer MUST set the clock either before or immediately after the firmware has been updated. This is needed by the timing requirements inherent in the protocol.
No additional configuration steps are required as the Luna Cloud HSM service is compatible.
NOTE There is no plan to update the older Luna Backup HSM G5 (nor any version of firmware 6) to support CPv4.
CPv4 is handled like the prior CPv1 cloning protocol.
>The default cloning configuration displays both CPv1 and CPv4. (However UC 10.4.x users and below can clone using only CPv1).
>Any scenario where CPv1 can be used, CPv4 can be used.
>Any scenario where CPv1 cannot be used, CPv4 cannot be used.
> CPv4 can be used to clone objects in V0 partitions, and clone the SMK in V1 partitions.
>The same set of roles that can use CPv1 can use CPv4. This includes the allowance for the Crypto-User to clone public objects.
>In Luna Cloud HSM service, CPv4 is the default protocol; however if only one side has CPv4 available the cloning process reverts to CPv1.
>Partition Policy 8 in Luna Cloud HSM displays both CPv1 and CPv4; however when paired with UC 10.4.x and lower only CPv1 is permitted.
NOTE The Partition Policy difference between Luna Network HSM 7 and Luna Cloud HSM is as follows:
- Luna Network HSM 7 slot Policy “42: Allow CPv1 : 1” means to force CPv1 and disable all other cloning protocols.
- Luna Cloud HSM slot Policy “8: Allow CPv1 (Cryptovisor Only) : 1” means to allow CPv1 but you can also clone using CPv4.
Preconditions for Universal Cloning with Cloud or On-premises HSM Partitions
In order to use the Universal Cloning feature, the following must be true:
>you have Luna HSM Client 10.5.0 or newer
>you have either
•Luna Cloud HSM, and on-premises HSM at firmware version 7.8.0 or newer
OR
•an on premises Luna HSM at firmware 7.8.0
and
another on-premises Luna HSM at any firmware version suitable for Migrating Keys to Your New HSM
or
another on-premises Luna HSM at any firmware 7.8.0 and onward for the widest range of domain management and key-cloning cipher options
>the source partition's security policy allows cloning of private and secret keys
>Partition policy 44: Allow Extended Domain Management is set to ON for at least one firmware 7.8.0 or newer partition.
>you have an uninitialized destination Luna Cloud HSM service (if cloning to Luna Cloud HSM rather than on-premises HSM)
>if your client host is a Windows device, you have installed pscp (PuTTY Secure Copy Protocol).
To clone cryptographic keys from one HSM to another, the HSMs must share the same cloning domain. As a result, you must initialize the destination partition with the source partition's cloning domain. The cloning domain was specified as a string when the source partition was initialized. However, with the advent of Extended Domain Management, you can add up to two additional security/cloning domains to any on-premises HSM partition (where the firmware is at version 7.8.0 or later).
The key migration process does not impose that both platforms use the same authentication mechanism. Key migrations are possible between HSMs that use Password or multifactor quorum authentication mechanisms. The only requirements on authorization, at either end, are that the user must be authenticated AND the user must be authorized to perform the migration.
To move objects between HSMs/Partitions that have different default security/cloning domain types (whether multifactor quorum/multifactor quorum,or password/password, or multifactor quorum/password) ensure that both source and target have at least one common domain among the three that each can have with Extended Domain Management (as of firmware 7.8.0).
CAUTION! Domain secret strings for password-authenticated HSMs and Luna Cloud HSMs are used to generate the secret key for cloning, and are as cryptographically sensitive as a user password. The domain label associated with a domain string is not sensitive, and is used only to distinguish the domain from others assigned to the same partition. Never use the same string for the domain label and for the domain secret.
The commands to manage domains are:
For more information about CPv4, see Where is copying, sharing, migration of keys possible - from what source to what destination?
Next steps
When you have arranged for two application partitions to have at least one domain in common
