Cloning protocols for Luna HSMs have evolved along with abilities of HSMs and the complexities of inter-operation. Cloning protocols are not actions that you perform directly; rather, they are previously-agreed-upon methods used when you request cloning operations for:
>direct partition-to-partition cloning of single objects or bulk copying,
>synchronization between/among HA group member partitions,
>cloning between on-premises HSM partitions and Luna Cloud HSM services, or
>backup/restore operations with dedicated Backup HSMs.
The most straightforward circumstances for those operations are situations where all members (or all source and target combinations):
>are at the same firmware version,
>have the same partition type
•pre-7.7.0, or
•V0 , or
•V1,
>have the same settings to allow or disallow non-FIPS-approved cryptographic mechanisms, and
>have the same FM-enabled status, either:
•never been enabled (dual HOC -- regular HOC is primary and is the only one used, while FM-HOC is on standby in case FMs are enabled)
•have been enabled at some point (single HOC -- the original primary HOC was deleted, leaving only FM-HOC).
Changing any of those variables adds considerations that affect migrating/HA/cloning, where some differences might disallow the ability to clone from a source partition in one condition to a target in a different condition. When combinations of the variables coexist in the cloning scenario, that scope expands. This page sorts out who can clone (or HA) with whom, and what versions of firmware and client are needed.
In general, the cloning operation involves three parties:
>the source,
>the target, and
>the host application (examples include lunacm, Luna shell (lunash), ckdemo, or possibly your application) that invokes the client library.
Each party has a different responsibility. The host application acts as a middle-man, and the cloning rules are enforced by the general-purpose HSMs and Backup HSMs. Source HSMs use only their highest-available protocol to clone objects out, and do not allow an object to be cloned to an HSM (or, more specifically, to a partition / slot of an HSM, or a Luna Cloud HSM service)
>that does not share the same cloning / security domain, or
>that has a lower security profile than the source.
Additional information regarding the security aspects of cloning is available publicly from NIST Computer Security Resource Center.
| Protocol | When? | What for? |
|---|---|---|
| CPv0 | Legacy products, f/w 4.8.5 through end of f/w 5.x | End of life. No longer used. |
| CPv1 | Luna products before release 7.7.0 |
The Luna HSM cloning work-horse protocol for many years. (Uses token wrapping certificate TWC3 based on RSA 2048-bit key-pair) For Luna Cloud and Luna on-premises HSMs, as long as both devices supported the same object type algorithms, then interoperability and hybrid operation were available in both FIPS and non-FIPS mode of operation. At firmware release 7.7.0, protocol used to clone keys to Luna Cloud HSM was CPv3, and CPv1 was disabled for that purpose |
| CPv2 | -- briefly |
For Small Form-factor backup (SFF) - not used by any other product, and no longer supported. |
| CPv3 | 7.7.0 |
Advantages Addresses certification issues. (Uses a token wrapping certificate based on RSA 4096-bit key-pair - can clone objects out only using CPv3; can clone objects in via CPv0, CPv1, or CPv3, but permits only the highest supported by the sending HSM) >Compliance with FIPS SP800-131Ar2, SP800-56Br2 and current interpretations of FIPS in general >Common Criteria certifications >Uses a 4096-bit certificate, signed by the primary HOK of the HSM >Backup HSM for FM-Enabled HSMs >SKS Blob Based Backup instead of cloning based backup >Support for old client applications and old client libraries >General security improvements >Functionality Module-Enabled HSM can clone out to an FM-Disabled HSM >FM-Disabled HSM prevented from cloning out to an FM-Enabled HSM(*) Constraints Satisfying all the wide-ranging requirements met by CPv3 resulted in CPv1 support being dropped, which limited the ability of Luna on-premises HSMs to share keys with Luna Cloud HSM. Keys could flow from Cloud to on-premises, but not the other way. CPv1 is enabled or disabled via partition policy 42 setting (introduced with firmware 7.7.1). When CPv1 is enabled, CPv3/CPv4 are disabled. |
| CPv1 bi-directional | 7.7.1 |
Re-added support for CPv1 when in non-FIPS mode. However, many use-cases require/mandate FIPS mode. Having policy 42 on - Allows interoperability between CPv1 HSMs (pre-7.7.0 Luna Network HSM 7 and Luna PCIe HSM 7, and Luna Cloud HSM) on the one hand, and CPv3 (7.7.x) HSMs on the other >Cloning objects in both directions (to/from) the CPv1-only and CPv3- or CPv4-capable HSMs >Mixed-mode HA, including Luna Network HSM 7 partitions with Luna Cloud services ("partitions") >does not deal with incompatibility where multifactor quorum authentication was not supported by Luna Cloud HSM at the time this was released >when policy 42 is on for a partition, CPv3 and CPv4 options are overridden and the use of CPv1 is forced for both incoming and outgoing cloning operations, so the operations can proceed only if both source and target partitions have CPv1 available. •pre-7.7.1 firmware, CPv1 is always available •Luna HSM Firmware 7.7.1 or newer, CPv1 can be disabled/enabled by policy See CPv3 characteristics below for additional information regarding CPv3. CPv1 is enabled or disabled via partition policy 42 setting (introduced with firmware 7.7.1). When CPv1 is enabled, CPv3/CPv4 are disabled. |
| CPv4 | 7.8 |
CPv4, along with Extended Domain Management, implements universal cloning. Multiple strong cipher-suites are available to choose from and they can be activated or deactivated at will. Each partition can have up to three cloning/security domains, allowing you to clone keys and objects, in both directions, when in FIPS mode or in non-FIPS mode, between: >on-premises multifactor quorum-authenticated partitions and either >on-premises password-authenticated partitions or >Luna Cloud HSM services. Extended Domain Management permits: >rotation of domain secrets (similar to password rotation) >shifting of domains >splitting of domains >joining of domains. Having CPv4 available requires Luna HSM Firmware 7.8.0 or later. Using CPv4 requires that the other HSM(s) involved in cloning, HA, etc., also have Luna HSM Firmware 7.8.0 or later; no additional configuration is needed to make CPv4 available (except CPv1, policy 42 must be off). Luna Cloud HSM is already updated to interact with on-premises HSMs at Luna HSM Firmware 7.8.0 >CPv4 is configured by commands to display and select cipher suites that can potentially be used by CPv4, as well as the suite used by CPv3, and allows enabling or disabling of any, or all, of the individual supported suites. >Sessions in CPv4 do not persist indefinitely. CPv4 times-out and re-establishes sessions for Perfect Forward Secrecy. This is done transparently to the user and requires no overt action from you. >When CPv4 is negotiated between two partitions (or a partition and a cloud service), the protocol clones all objects specified by the command during a single negotiated session. This contrasts with CPv1 and CPv3, which open and close a session for each individual object. See Universal cloning (CPv4) characteristics below for additional information regarding CPv4. CPv1 is enabled or disabled via partition policy 42 setting (introduced with firmware 7.7.1). When CPv1 is enabled, CPv3/CPv4 are disabled. |
(* An FM-Enabled target is not trusted compared to one that has never had external/foreign code introduced. Enabling FMs on an HSM is a one-way operation, because it deletes the standard Luna hardware origin key [HOK] and asserts an FM-HOK.)
CPv1 partition policy 42 can never be ON for V1 partitions.
For V0 partitions, whether created new, or updated from pre-7.7.x by firmware update, HSM policy 12 is OFF; therefore CPv1 partition policy 42 is OFF initially.
CPv3 characteristics
1.The Backup HSM prevents objects, cloned in by CPv3, from being cloned back out with CPv1.
2.The Backup HSM prevents cloning objects from a pre-FM HSM (firmware older than Luna HSM Firmware 7.4.0) to an HSM with FMs enabled.
3.The Backup HSM prevents cloning objects from an FM-never-enabled HSM ( any firmware) to an FM-Enabled HSM.
4.A single Backup HSM can be used with most Luna HSMs, while preventing the Backup from moving keys to an HSM with known vulnerabilities. The Backup HSM must use CPv3 and be FM-Disabled, but it is allowed to move keys
•to a CPv1 HSM or
•to an FM-Enabled HSM
if the object or SIM secret came from a CPv1 or FM-Enabled HSM.
5.Luna HSM Firmware 7.7.0 clones objects out only using the CPv3, and clones in via CPv3, CPv1 or CPv0, depending on the cloning source.
•V0 partitions use CPv3 to clone cryptoki object or SMK to a Luna Backup HSM G5 or an HSM with Luna HSM Firmware 7.7.0 or newer.
•V1 partitions use CPv3 to clone SMK to a Luna Backup HSM G5 or to an HSM with Luna HSM Firmware 7.7.0 or newer. Cryptoki objects can be extracted in a SIM4 SKS blob structure only.
6.The Backup HSM can clone objects out using CPV3 or CPV1 depending on the target HSM to which it attempts to clone.
7.For HA groups that include members with firmware versions 5.x, 6.x, 7.x (older than Luna HSM Firmware 7.7.0), HSM migration to an HA group of Luna HSM Firmware 7.7.0 HSMs requires that each 7.x HSM member be upgraded to Luna HSM Firmware 7.7.0 firmware. The master must be the last updated to allow cloning from protocol v1 to protocol v 3 as the reverse is not possible.
8.The firmware no longer drops unrecognized attributes in incoming flattened objects, and generally refuses to create the object if any are encountered during the un-flattening process. To ensure maximum backward compatibility while maintaining security, certain newer attributes (like CKA_ASSIGNED) that are in the false/unset state are excluded from this behavior (so the attribute is, in fact stripped), allowing an object to be cloned to an HSM that does not support the attribute. This is possible because both copies of the object would remain functionally equivalent. By contrast, an attribute like CKA_PER_KEY_AUTH_DATA, if present on an object, has no default and is mandatory, so if such an attribute is set it is always included when the object is cloned (if the cloning-target partition supports that attribute to allow cloning of the object).
To summarize: former behavior was to strip/drop unknown attributes and permit the reduced object to be cloned, while the new behavior is to simply refuse to clone a source object (that is set) if the destination is not configured to support the attribute.
9.If Luna Backup HSM G5 is used, full backup support for CPv3 HSMs requires Luna Backup HSM G5 Firmware 6.28.0.
10.Cloning with CPv3 is more complex than CPv1, and therefore might take slightly longer per individual operation.
Backup
The Backup HSM and the general-purpose HSMs (at whatever firmware versions) generally determine what is properly allowed to be backed-up and restored. The Backup HSM prevents itself from being used as a gateway device to allow keys to be cloned in from what we consider a more secure environment and be cloned out to a less secure environment. For example, it is not permissible to clone a key from an FM-Disabled HSM to a Backup HSM, and then clone that key from the backup HSM to an FM-Enabled HSM.
Universal cloning (CPv4) characteristics
Application is required to drive cloning-session renegotiation - Universal cloning session negotiation is a multi-step process, and if the CPv4 configuration changes while the negotiation is in progress - perhaps by making a negotiated algorithm unavailable - the negotiation might fail. Initial negotiation is part of the protocol, but re-negotiation would need the driving application to perform the re-negotiation. This is likely a rare combination, but possible. However, once a negotiation is complete, the CPv4 session is self-contained, and can be used until it expires or is closed.
Validity timestamps have some forgiveness - The protocol messages, the negotiated session keys, and the extracted key blobs, have timestamps that define for how long they are valid. In order to avoid the chance of clock-related problems, or network latency and delays, during negotiation, the protocol is forgiving of a delta up to 5 minutes out-of-sync between members - any greater, and the universal cloning negotiation fails with CKR_CLOCK_NOT_IN_SYNC.
HSM clock management by SO - The Audit role has always been able to set time, and beginning with Luna HSM Firmware 7.8.0 and newer, clock management can be performed by the HSM SO using
HSM clock sync with host time - The HSM clock syncs against host time every 24 hours. If time has become so far out-of-sync that the HSM clock will not accept automatic update, then an Alarm is logged and attempts to synchronize are stopped until an administrator (SO or Audit roles) updates by command -- after which, automatic synchronization resumes.
Functionality Module cloning restrictions - Universal cloning continues to enforce the Functionality Module (FM) restrictions, where objects from a non-FM-Enabled HSM are not permitted to be transferred to an HSM that is FM-enabled. That is, keys can flow only from an FM-Enabled HSM
>to an FM-never-Enabled HSM or
>to an FM-Disabled or never-enabled HSM, and
>never in the other direction.
Unknowns are rejected - Universal cloning rejects
>any object that it does not recognize,
as well as
>any object with an attribute that it does not recognize.
The HSM returns OBJECT_TYPE_UNKNOWN and ATTRIBUTE_TYPE_UNKNOWN.
Non-extractable must remain non-extractable - Keys that are in a Luna HSM where they are not extractable cannot be moved to an environment where they could be extracted.
Interoperability of universal cloning - For improved compatibility when sharing keys with other HSMs, non-standard PKCS11 attributes are stripped when they have values that are safe to remove (that is, if they have the permissive default values).
>PKA attributes (Per Key Authorization) are removed if PKA has not been set for the key; CPv4 is allowed for objects* only in V0 partitions (cloning partitions), so the PKA attributes should not be set.
>CKA_ASSIGNED is removed if it is false, which it should be for V0 partitions.
>DES3 counters are removed.
>Key Ring related attributes are removed.
NOTE * In V1 partitions, CPv4 is used to clone the SKS master key (SMK) and blobs encrypted by it (for HA and backup), but not individual keys and objects.
No Network Replication - CPv4 is always allowed when the corresponding cloning policies are enabled; the Network Replication policy 16 (which, in previous HSM versions could have overridden the cloning policies) does not apply to CPv4. Network Replication is considered almost irrelevant when most applications use HA, and many also use STC. But if your application requires it, then simply disable CPv4 by disabling all its cipher suites.
Enabling Extended Domain Management - Extended Domain Management is enabled with Partition Policy 44 - Enable/Allow Extended Domain Management (where the capability is always ON (following firmware update) and the policy is initially OFF by default, for backward compatibility. Optionally add up to two additional security/cloning domains to a partition, in addition to the original domain that is imprinted when the partition is initialized. This permits previously disallowed or inconvenient key-cloning actions like:
>cloning keys across domains that differ from the original, as long as source and target partitions share at least one domain in common,
>cloning in both directions between password-authenticated partitions (including Luna Cloud HSM services) and multifactor quorum-authenticated partitions.
As a general rule, to establish a security/cloning domain in common between a password-authenticated partition, and a multifactor quorum-authenticated partition,
>you require a locally-connected Luna PED at the password-authenticated HSM, if you choose to import a domain secret PED key into a password-authenticated partition, but
>you do not need a Luna PED at the password-authenticated partition location if you are adding its text domain into a multifactor quorum-authenticated partition.
Domain labeling - when and how - Extended Domain Management implements the naming / labeling of domains in order to distinguish them - the initial domain can be labeled, but is initially unlabeled, for backward compatibility (where only one domain was ever used), whereas if more domains are added, then all must have different labels. The feature is managed by lunacm commands:
>partition domainlist and
>partition domainadd and
>partition domainchangelabel and
Which domain is primary and how to change - All partitions, after initialization, have the current or original security/cloning domain marked as the primary, the domain that is chosen by default for cloning. For a partition with more than one domain, either of the others can be designated as primary, instead, using the partition domainadd and partition domainchangelabel commands, by invoking their -primary option.
Partition PO role login is required, to create or change a domain (after the first domain created by partition initialization). Use of command requires partition policy 44 to be set to ON.
Domain ordering unaltered by deleting - If three domains exist, and you delete the middle one, that does not alter the domain ordering, nor does it alter which one is the primary. You cannot delete the primary domain from a partition at Luna HSM Firmware 7.8.0, or newer, even if other non-primary domains are set; you must set a different primary first.
Increase of existing partition size - At firmware update, from pre-7.8.0 versions, all pre-existing partitions are given a little more space to store domain labels and universal cloning configuration. This would generally not be noticed, as it is negligible against the size increase afforded by the prior Luna HSM Firmware 7.7.0 update (with SKS, PKA, etc.).
Primary domain - On pre-firmware 7.8.0 HSM partitions the single possible domain is effectively the primary domain. For firmware 7.8.0 and newer, partitions can have as many as three domains. Of the three possible, one domain is always primary, but the status of primary can be moved to another domain if needed. "Primary" in this context means "the one that is tried first". If there is no match for the primary domain on the source partition, the systems goes on to try for other matching domains.
[Summary]
When cloning from a partition of an HSM with firmware version lower than 7.8.0 to a version 7.8.0 or higher with multiple domains, the primary domain is used.
[Explanation]
On firmware version 7.8.0-or-newer HSM partitions, the partition always has at least one domain, and can have as many as three, any of which can be a password-style text domain, or a multi-factor quorum type (PED key-secret domain. One of the three possible domains is designated primary, and is the first one looked at when a cloning/migration operation is attempted.
If a firmware version 7.8.0-or-newer target is already a member of the same domain as a pre-7.8.0 firmware source partition, and that domain is primary on the v7.8.0-or-newer partition, then cloning/migration can proceed straightaway.
If the target HSM partition is at firmware 7.8.0 or newer, then if its partition initially has a different domain from the source partition, the target partition can:
•use Extended Domain Management to add the source partition's domain as one of the three domains that the target can support and
•make the domain that was obtained from the source become the primary domain on the target by using the -primary option when adding a domain with partition domainadd, and
•cloning/migration can proceed (includes backup, HA, etc.).
