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 crypto object can leave the HSM, and where it can go if it is allowed to leave. That is, a security or cloning domain is a method for administrators to limit key migration such that your keys will only exist in specifically your Thales HSMs and not in simply any Thales HSM.
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
>Synchronization in HA groups.
Domains per partition - (copying across domains)
Copying of keys and objects, which is controlled and constrained by domains assigned to a partition, has generally been consistent over many Luna releases. Luna HSM Firmware 7.8.0 expands the historic capability, while retaining integration with existing customer applications. That is, with respect to domains, Luna HSM Firmware 7.8.0 (and newer)
> defaults to pre-existing domain-related behavior,
•An application partition can have one cloning domain, which is either a password-like typed string, or a randomly generated PED key domain string.
•A cloning domain is not labeled, because there is no use for a label when only one is possible.
•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.
>but expands the domain-related behavior, if desired
•An application partition is initialized with a domain that can optionally have a label, or remain unlabeled.
•Up to two additional domains can be added to a partition
–a label allows you to visually distinguish which domain is which
–the original domain is designated "primary", but you have the option to declare a new domain to be the primary
•A new domain can be a text string (for password-authenticated domains) or a domain secret stored on a PED key
–if you include a string, that is used
–if you do not include a string, when adding a domain, the dialog prompts for PED input.
No common domains across password-authenticated and multifactor quorum-authenticated HSMs (superseded restriction)
NOTE The information in this section concerns Luna HSM firmware versions older than Luna HSM Firmware 7.8.0.
Password-authenticated application partitions, with identical security domains, can clone partition contents one to the other, if the HSM type supports cloning. Multifactor Quorum-authenticated application partitions, with identical security domains, can clone partition contents one to the other, if the HSM type supports cloning.
Prior to firmware version 7.8.0, 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.
[The firmware 7.8.0 and newer Extended Domain Management allows you to clone keys and objects across domains, as long as you have control of the domain(s) on the source partition and on the destination partition - nobody can transfer any partition content, or invoke any other domain, without your authorization]
>You are assured that the key or object has never been outside its original security/cloning domain, or in any less-secure state.
[Firmware 7.8.0 and newer Extended Domain Management modifies this proviso to "has never been outside a domain under your control".]
Using Luna HSM Firmware 7.7.0 or newer, any V1 (non-backward-compatible) partitions, backup and HA replication of crypto objects are accomplished with SKS encrypted blobs, and the cloning protocol is reserved for the SMK - the key that encrypts the SKS blobs.
Cloning Domains Using Luna HSM Firmware 7.8.0 and CPv4
Luna HSM Firmware 7.8.0 introduced Extended Domain Management, the ability for an application partition to support up to three KCVs (Key Cloning Vectors) or cloning/security domains. The original domain is retained as a PSK (pre-shared secret or pre-shared key) for CPv4 negotiation, so that existing workflows are not affected. Two additional domains can optionally be added, for greater operational flexibility, if needed. See partition domainadd.
Additional domains are optional, and can be typed (as for password-authenticated HSM partitions) or can be input from a PED, if the -dped option is used with the partition domainadd command.
Extended Domain Management permits:
>rotation of domain secrets (similar to password rotation)
>shifting of domains
>splitting of domains
>joining of domains.
As indicated elsewhere, it is possible to affect the availability of cloning protocols
>by turning CPv1 on with partition policy 42 "Allow CPv1" setting (which disables the use of CPv3 and CPv4, and must be decided in advance because it is destructive), or
>by using the partition cipherenable and partition cipherdisable commands to control the availability of cipher suites.
If the use of CPv1 or CPv3 is forced (by disabling all the CPv4 cipher-suite choices), then only the use of a single domain is supported. If more than one exists in a partition, the primary is used. By default, the primary domain is the one that was imprinted when the partition was initialized, but you can make a different domain the primary by specifying the -primary option when using the partition domainadd command.
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 host 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 it could be 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 PED keys, 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, backup/restore, and HA sync operations 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 multipartition 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 PED key, 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.
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.
