MofN Secret Sharing (quorum or multi-person access control)
Setting up
When a Luna HSM with multifactor quorum authentication is initialized, or a partition on such an HSM is initialized, the roles and domain secrets are mediated by the PIN Entry Device (PED). As each role or secret is brought into existence, PED keys are imprinted with the corresponding secret. This can occur in one of two ways:
>a fresh, unique secret is generated on the HSM, and is imprinted on an PED key, making the current HSM-or-partition completely independent and stand-alone, or the first of a new group
>if the option to reuse an existing PED key is selected, then no new secret is generated, and a secret created for another HSM or partition is read from an already-imprinted PED key and saved to the current HSM - this is how roles and domains can be shared among HSMs and partitions, and how exclusive groups of HSMs and partitions can be created for specific operational and security-regime purposes.
While an authentication or domain secret is being imprinted on PED keys, the HSM (via the Luna PED) offers the following options:
>have the current secret be complete on a single PED key to be held / controlled by one officer
>divide the secret into several splits/shards/components and specify how many of those components must later be brought together to reconstruct that secret
The Luna convention is that "N" is the total number of splits (up to sixteen, but a smaller number is generally recommended*) into which a secret is divided, and "M" is the necessary-and-sufficient number of splits that must be brought together (usually fewer than N) in order to recreate the full secret.
Using
The HSM prompts, by means of PED key input device (historicallyLuna PED), for the individual components of the MofN split secret that accesses the roles or the cloning/security domain associated with the HSM or partition currently being addressed.
The split values from individual PED keys, as they are passed to the HSM, are validated as being part of the correct type of secret (appropriate role [SO, CO, CU, Audit...], domain, RPV) and as being component members of the particular secret, and as not being an attempt to offer the same split portion more than once.
If the correct type** and number of the sub-components are received by the HSM to recreate the needed secret, the HSM permits access to the current partition/slot by that role, or permits cloning operations in-or-out of the partition for backup/restore, HA synchronization, etc.
* Thales recommends that you choose M as a reasonable quorum of officers that must be available every time you need to present the secret, and then choose N sufficiently larger to allow some co-officers to be unavailable [vacation, sickness, business travel] while still having enough split-holders to achieve quorum. The larger the number for M, the more time it takes to complete authentications, which might run up against timeouts and require you to adjust timeout values.
** When PED keys containing splits are offered, they must be be part of the specific secret that is needed here, and must not be a split (or a copy of a split) that was already presented during the current attempt. A lapse of any of those requirements results in the attempt being declined.
