|
Home > |
|---|
The MofN feature provides a means by which organizations employing cryptographic modules for sensitive operations can enforce multi-person control over access to the cryptographic module, or selected aspects of it. The feature is available in all Luna HSMs configured to use Luna PED, the PIN Entry Device (PED), and associated PED Keys for authentication.
MofN involves a splitting of an authentication secret into multiple parts or splits. The shared secret is distributed (or “split”) among several PED Keys (“split-knowledge access control”). Every type of PED-administered HSM authentication secret can be split when it is created:
•blue SO PED Key,
•red Cloning Domain PED Key,
•blue Partition SO PED Key,
• black Crypto Officer PED Key,
•gray Crypto User PED Key,
•orange Remote PED Vector Key,
•purple Secure Recover Key,
•white Audit PED Key.
For a non-PED-authenticated (that is, for Password authenticated) HSM, you could simulate a weak form of MofN by giving two persons (or more) each a portion of the text string to authenticate to a role or a function on the HSM. Then you would need a third person to oversee each authentication to ensure that the holders of the partial password strings entered them in the correct order and did not view each other's portions.
For PED-authenticated HSMs, real MofN is a much more robust, self-enforcing feature.
Without MofN, you can initialize an HSM such that you must produce just a single blue HSM Admin/SO PED Key in order to login and perform HSM management functions, and you must produce a single black Crypto Officer PED Key in order to activate a Partition to receive Client connections and allow Client applications to perform operations within the Partition, and similarly for any of the other roles and authentication secrets listed above. And that can be the extent of your security and oversight. If that is sufficient, you can stop reading this topic.
With MofN, the authentication secret contained on one blue SO PED Key or one black Crypto Officer PED Key (or red Domain key or gray Crypto User key or orange Remote PED key or purple Secure Recovery key or white Auditor key) is still necessary, but is no longer sufficient for authentication. Access now requires additional authentication by an overseer, or several overseers or cooperating co-key-holders. That additional oversight constitutes "M" holders of separate portions of the role secret, which is now the MofN "split knowledge shared secret". What that means is that the SO secret, or partition Crypto Officer secret, or cloning Domain (as well as the Remote PED secret and the Secure Recovery secret and the Audit secret and the Crypto User secret, if used) can be split into portions (over several PED Keys of the current color, rather than just one), and a defined number of those portions must be brought together in order to re-create the complete secret. One person, with one PED Key can no longer authenticate for an HSM role or function that has MofN set.
At initialization time, or role creation time, you are referred to the PED, where you get to specify into how many splits or shares each authentication secret is divided - this is quantity N (which can be any number from 1 to 16). You also specify how many of those splits or shares must be joined together by Luna PED in order to re-create the secret - this is the quantity M. M can be less than or equal to N. Specify those quantities by providing the "Nvalue" and the "Mvalue" when prompted by Luna PED. Those values become associated with the secret, and required, for the life of that secret - until you cause a new secret to be created. That might occur when changing or resetting a "password" (PED Key secret) for a role, or when generating a new Remote PED Vector, or generating a new Secure Recovery Vector. It could also occur if you factory reset, then re-initialized the HSM, but only if you chose not to reuse existing PED keysets (see "Reuse" below).
In the above illustration, the right-hand side depicts the SO secret (could be HSM Admin/SO, or could be application partition SO in a per-partition SO context) split among four blue PED Keys. This is not four copies of a secret - this is four different pieces, or splits, of a single secret. As indicated, the Mvalue, the quantity of those splits that will be needed in any future authentication, could be set to any value between 1 and Nvalue (in this case 4).
•Setting M to 1 would be pointless. You might as well have set Nvalue to 1, also, and just made identical copies of that single complete-secret key for your spares.
•Setting Mvalue to 4 is valid, but requires that all holders of blue-key splits must be present whenever authentication is prompted - no blue-key holder can take vacation or sick-leave, or travel for business, without handing control of her/his split to an alternate responsible person, not one of the existing split-holders.
•Suitable Mvalue settings, when Nvalue is 4, would be either M=3 or M=2.
N=4 is just a handy example size. We could have used any nValue up to 16, but larger numbers would make for a more cumbersome example to explain the concept.
To log in or authenticate with MofN in force, you are first prompted to supply, for example, a blue PED Key (or a black PED Key, or whichever of the colors is appropriate to the task), then you are prompted to supply an additional (different) key of that color, from that set, and to repeat until M splits have been presented - those can be any M of those keys, in any order, as long as all are different. That is, the secret is spread over N keys, but you need only M of them to recreate the complete secret when required (where M is usually less than N).
As illustrated below, if you set MofN to N=4 and M=3, then any three of the set can be presented, when Luna PED prompts for SO login.
Secret splits 2, 3, and 4 (above) combine to reproduce the complete SO authentication secret.
Secret split 1 is grayed out, to indicate that you do not need it when authenticating, if you present 2, 3, and 4 when prompted by the PED.
Or, secret splits 1, 3, and 4 combine to reproduce the complete SO authentication secret, with 2 not needed.
Or, secret splits 1, 2, and 4 combine to reproduce the complete SO authentication secret, with 3 not needed.
Or, secret splits 1, 2, and 3 combine to reproduce the complete SO authentication secret, with 4 not needed.
From an MofN = 3of4 set, any of the above 3-PED-Key combinations will get you into that HSM or partition.
When seeking an MofN divided secret, Luna PED does not ask for a specific split. All it wants is a split that is a portion of the requested secret, but different from any previous splits you have offered, during this authentication attempt. When it successfully receives the number of different splits that are indicated in the PED Key header, the authentication attempt is made at the HSM.
Use MofN when you want a selected type of HSM access to require the presence of more than one person. MofN is invoked per authentication secret. That is, it applies to only those secrets where you deliberately choose to invoke MofN as the secret is being created/imprinted. Thus you could have MofN multi-person control imposed for HSM SO and for Cloning Domain, but not for Partition Crypto Officer, nor SRK, nor RPV... or any other combination that made sense in your environment. Please review "How Many PED Keys Do I Need?" before you make any decisions about invoking MofN for one-or-more authentication secrets for an HSM.
During initialization and administration of the HSM, the HSM Administrator or Security Officer [SO] invokes MofN if desired as the procedure reaches the point of creating/imprinting each authentication secret. The HSM SO supervises the imprinting of a blue PED Key or a set of N blue keys. The SO specifies how many shares (also sometimes called “splits”) will make up the shared secret. This total number is N and may be any number up to 16. The SO then specifies how many of that total number of (current color) PED Keys are to be required at each login/authentication of the role or secret. This second number, M, can be any number up to N. During initialization, the SO would also be presented with the same choices for the HSM administrative partition's cloning domain.
From that point on, any future login or invocation of that particular authentication (blue key, or red key) to the HSM requires that quantity M of that-color share keys be provided. The result is that no single person can operate that aspect of the HSM.
The same choices then occur as an application partition is created and has roles and secrets created for it. One holder of the Crypto Officer key or the HSM Admin/SO key (for example) must bring together M different share-holders (including himself/herself), each with one of the black or blue keys, as appropriate, before the HSM or partition can be unlocked.
Again, the same applies to any of the other colors (roles/secrets), RPK, SRK, Auditor,for which MofN was invoked.
|
HSM Role or Secret |
Number of splits required per role/secret if one role/secret has MofN invoked | |
|---|---|---|
| Number of Splits created (N) [Note 1] |
Number of splits needed to authenticate (M) [Note 2] |
|
| Blue - HSM Administrator or Security Officer (SO) | Any value from 1 to 16 | Any value from 1 to N |
| Blue - Application Partition Security Officer (SO) | Any value from 1 to 16 | Any value from 1 to N |
| Red - Cloning Domain | Any value from 1 to 16 | Any value from 1 to N |
| Black - Crypto Officer (sometimes called application partition Owner for "legacy" partitions without Partition SO) |
Any value from 1 to 16 | Any value from 1 to N |
| Gray - Crypto User | Any value from 1 to 16 | Any value from 1 to N |
| Orange - Remote PED Vector | Any value from 1 to 16 | Any value from 1 to N |
| White - Auditor | Any value from 1 to 16 | Any value from 1 to N |
| Purple - Secure Recovery Vector | Any value from 1 to 16 | Any value from 1 to N |
| [Note 1 - Selecting an Nvalue of 1, when imprinting a role or secret, means no MofN splitting for that role/secret; a single PED Key unlocks that role or function. Selecting an Nvalue greater than 1, when imprinting a role or secret, means that secret is split across quantity N of that-color PED Keys.] |
||
| [Note 2 - Mvalue is usually not selected as 1 (when N > 1), since that would mostly defeat the purpose of setting MofN. Mvalue is usually not selected as N, since that leaves no scope to authenticate while one or more holders of secret-split PED Key is unavailable due to illness, vacation, business travel, or other reasons. Therefore, 1 < M < N is usually the case.] |
||
The purpose of the above table is to emphasize explicitly that MofN settings are completely independent, per role or secret, on an HSM.
•Setting MofN, or not, for one role or function secret, has no influence on whether or not MofN can be set for any other role or secret.
•Setting Mvalue and Nvalue for one role or function secret has no influence on the values you might set for another.
MofN is not a splitting of the private signing key; it is splitting of the Luna HSM's individual authentication/access secrets. That is, MofN is a splitting of the secret that lets you unlock a function of the HSM, but not a split of the working (encrypting, decrypting, signing, verifying) secrets - your keys and certificates - contained inside the HSM.
Note: In general, use MofN if you will be giving each split-containing PED Key to a different person. We recommend that you use MofN only if you have established a definite need for it. The additional security of split-knowledge, shared-secret, multi-person access control imposes additional administrative overhead, and increased possibility of making an administrative or handling error that could leave you unable to access your keys and certificates.
When a PED Key contains an authentication secret from an HSM or partition, and you are imprinting a secret for a new HSM or partition, you are prompted to "Reuse an existing keyset?", or to overwrite any content of the PED Key (explained in detail at "Shared or Group PED Keys").
If you present a PED Key containing a single split from an MofN set, the PED detects that it is viewing a partial secret, and prompts you for additional splits of that secret, in order to reproduce it and impose the reconstructed secret onto the current HSM (for that role). That is, you cannot use a single split from an MofN group as a complete secret on another HSM or partition. If the other HSM had MofN for that secret or role, and you choose to reuse, you must reuse all of it, and therefore you are choosing MofN for that role on the new HSM, just as it was on the original HSM.
In previous versions of Luna HSM, MofN was a selection made at the command-line (either lunash:> or lunacm:>) via the hsm init command. You could elect to use MofN or not, by means of options to the hsm init command. MofN, was a separate secret, spread across N green keys. If you invoked MofN, then it was always in force for that HSM (until the HSM was re-initialized). If you invoked MofN, it was in force HSM-wide. As explained above, modern MofN behaves very differently, and we recommend taking time to understand the differences and implications if you are migrating from older Luna HSMs.