The ability to employ cloning protocol version 4 (CPv4) becomes available when using Luna HSM Client 10.5.0 and newer, with HSMs at Luna HSM Firmware 7.8.0 or newer.

In order to enable the use of CPv4, the HSM Security Officer must set the clock either before or immediately after the firmware has been updated.

No additional configuration steps are required; the Luna Cloud HSM service is compatible.

NOTE   There is no plan to update the 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, Luna HSM Client 10.4.1 and older 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.

>Prior rules about Functionality Modules are preserved where the current partition has FMs allowed:

•can clone out to non-FM partitions (allowed to clone from lesser-security to greater-security environment)

•non-FM partitions cannot clone in (not allowed to clone from greater-security to lesser-security environment)

>In Cloud HSM service, CPv4 is the default protocol; however if only one side has CPv4 available, it reverts to CPv1.

>Partition Policy 8 in Luna Cloud HSM fdisplays both CPv1 and CPv4, however when paired with Luna HSM Client 10.4.1 and earlier clients, only CPv1 is permitted.

Where is copying, sharing, migration of keys possible - from what source to what destination?

This section summarizes paths and limitations for getting keys and objects from one HSM to another, starting with the most general case and proceeding through more particular and sheltered use cases.

Moving or copying objects from any HSM to any Luna HSM or any Luna HSM to any HSM

Only objects whose properties allow them to be wrapped-off of an HSM and wrapped-onto another HSM can be transferred or migrated(*) in this fashion between Luna HSMs and non-Luna HSMs.

By manipulating HSM or partition policies, it is possible to modify the handling options for keys/objects having secret and private attributes. This requires pre-planning (before creating and using such objects) for these reasons:

>because the changes to such policies tend to be destructive of partition contents;

>because, while in many cases it is possible to override policy-change destructiveness defaults by using a Partition Policy Template that was adjusted for the purpose, when creating a partition, this same action is refused by the HSM if the HSM detects an attempted modification that would compromise security.

Moving or copying objects from any Luna HSM to any other Luna HSM

Luna HSMs have more options for sharing/migrating keys and objects with other Luna HSMs, although specific cooperation and prearrangement are needed.
That is, you can share keys with virtually any Luna HSM, but only if you want to allow it. Your HSM and its application partitions and their contents are not open to other Luna HSMs without your permission and action. When testing requests for copying/migrating keys and objects, a Luna HSM needs to recognize the other HSM by its Hardware Origin Certificate, derived from its Hardware Origin Key.

Moving or copying objects from any Luna HSM that you control to another Luna HSM that you control

This is the situation where you own/control both HSMs that are to be exchanging key material ("control", in addition to outright ownership of on-premises HSMs, could refer to a Luna Cloud HSM service subscription). The parameters of such a situation might be either:

>before firmware 7.8.0, any other HSM of the same authentication type, Password-auth vs Multifactor Quorum, can clone objects with each other of the same authentication type (as pre-configured before being populated), but not with the other type.

or

>starting with firmware 7.8.0,

•source can be either Password-authenticated or Multifactor Quorum authenticated, and

• destination can be either Password-authenticated or Multifactor Quorum authenticated

•as long as

–at least one of the HSMs is at firmware version 7.8.0 or newer and

–the affected partition has Partition Policy 44 Allow Extended Domain Management set to ON, and

•as long as the intended source and destination partitions have at least one security/cloning domain in common between them and

•as long as both have matching cloning cipher suites available (in other words, not disabled).

Two arrangements

That is, both parties to the transaction can have firmware 7.8.0 or newer and have Policy 44 set to ON, which offers maximum flexibility, as either participant could import a domain from the other (depending on which selection was more convenient).

Or just one party could have the newer firmware and policy setting, while the other (perhaps with older firmware) could have only its original default domain, and in that case, the partition with up to three domains must import the domain from the partition with only the single domain it acquired at initialization.

Across authentication types

In general, if cloning is desired between a password-authenticated partition and a multifactor quorum-authenticated partition, it is more convenient to share the password-auth domain string to become one of the domains on the multifactor quorum-auth partition, since the latter would already have a PED connection, whereas to share an iKey secret from a multifactor quorum partition to a password-auth partition requires that a Remote PED connection be established to the password-auth partition's HSM for just that purpose. However, both options are open, if your situation imposes constraints.

Restriction to any Luna HSM that you control that has certain configurations

Configuration settings that differ between participating source-vs-target HSM partitions (or at the level of the containing HSM) might imply constraints that could affect whether an object is acceptable to clone, or if cloned-in or wrapped-in, whether it can be used in the same ways as on the source partition. Some such configuration differences might include:

>If the source is set to allow use of non-FIPS algorithms and key sizes and curve types, etc., while the destination is restricted to FIPS-only crypto mechanisms, or perhaps the same mechanisms are available on both, but with restricted operations on the target, and so on;

>Similarly, if the firmware versions of source and destination differ, then so might available mechanisms, key sizes, etc.;

>Functionality Modules

An HSM might have the option to invoke Functionality Modules, meaning it has firmware version 7.4.0 or newer and was manufactured with both the regular HOK / HOC that all Luna HSMs have, and also the FM-HOK and FM-HOC included, on standby, and might never have FMs activated (by never having HSM Policy 50 Allow Functionality Modules set to ON

•cloning is permitted from an HSM that has FMs allowed to another HSM that has had FMs allowed (FM license is installed and HSM Policy 50 is ON)

•cloning is permitted from an FM-allowed HSM to a never-FM-allowed HSM

•cloning is not permitted from an HSM where FMs have never been allowed (the HSM retains its HOK/HOC) to an FM-allowed HSM (has only FM-HOK/FM-HOC) - this is considered an attempt to clone from a higher-security environment to a lower-security environment.