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 crypto 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, and
>Synchronization in HA groups.
There is no provision to clone between an application partition and an HSM administrative partition, but you can apply the same domain secret for ease of administration. Password authenticated application partitions, with identical security domains, can clone partition contents one to the other, and PED authenticated application partitions, with identical security domains, can clone partition contents one to the other, but password authenticated HSMs (and their partitions) cannot perform cloning with PED-authenticated HSMs (and their partitions).
Characteristics of Cloning Domains
Password authenticated HSMs have text-string cloning domains for the HSM SO space 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.
PED authenticated cloning domains are created by a SafeNet 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. PED authenticated HSMs have cloning domains in the form of encrypted secrets on red PED keys, for the HSM SO space and for any partitions that are created on the HSM.
The following characteristics are common to security (cloning) domains on all SafeNet Luna HSMs.
>The unique HSM SO-space 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.
>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 PED authenticated HSMs, the domain secret for the SO space 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. The segregation is maintained by physical and procedural control of the relevant PED keys 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 HSM SO spaces and for application partitions. These decisions must be made before you create the partitions.
