M of N is designed to provide additional 'eyes' on the setup and deployment of an HSM in a customer environment. The feature implements a balance between this multi-person control and the requirement for these M of N key holders to be present for all operations. The typical deployment of a Luna SA appliance is for it to be installed in a secure area of a data-center, typically near the certificate servers that it is servicing. Customers demand that this appliance is secure, but alongside that requirement they need to ensure that their processes and procedures aren't hindered by the addition of this HSM - this is the age-old security-versus- usability discussion. The typical deployment of a Luna G5 HSM is either attached to an application server, perhaps to serve as the root of a PKI, or attached to a Luna SA appliance to serve in a similar capacity as part of a "PKI bundle". The typical deployment of a Luna PCI-E (K6) HSM is inside its application server - again, as the root of a PKI, or as the cryptographic engine to an application on that server.
In all those scenarios, it is frequently the case that the HSM and its server(s) are kept in a locked facility and either accessed remotely by secure channels or accessed directly and physically only under specific conditions.
To satisfy these design requirements we have a concept of Partition Activation ( "About Activation & AutoActivation ").This allows administrators of the HSM to put it into such a state that the calling application is responsible for its own connections and sessions with the HSM, without requiring the presence of the operators for each and every login. This is important when an application or operating system might be rebooted for maintenance, or a power outage might occur (up to two hours duration), and it would be challenging to get the 3 or 5 management personnel together to present the M of N keys. Another way to describe this might be: The black PED Key(s) is presented in order to set the partition into a state of "open for business". When that is true, clients can connect. Clients must still provide their own credentials (certificates were exchanged, to register the link) and present a challenge secret (previously distributed) to enable them to perform cryptographic operations on the partition. At any time, the holder of the partition User/Owner black PED Keys can close the partition to access (deactivate it) and clients can no longer access the partition, regardless of their registered status and their possession of the challenge secret.
A common customer scenario would see the HSM configured and brought into production at a datacenter. This activity would need, first, the quantity M holders of blue SO PED Keys, so that the HSM administrator could log in and create partitions, adjust policies, and so on. Then, quantity M holders of black User PED Keys would be needed in order to activate each partition, making it available for customer connection. At this time the key holders (who would typically be management personnel, rather than day-to-day operational personnel) would give their approval to access the HSM by presenting the M keys at first login, or first partition activation. This is the electronic equivalent of them 'signing off' that the HSM is properly installed where it should be, that the security officer, partition owner and cloning domain holder - as well as the PIN holders if separate - are the correct authorized personnel.
Note that M of N is optional (until you decide to invoke it when a secret is first created), and that it is optional per secret. That is (for example):
Note also that, in addition to the "something you have" authentication factor, each secret-share can also (optionally) have a "something you know" authentication factor. That is, for every split of every HSM secret, you have the option - or not - to declare a PED PIN ( "What is a PED PIN?" ) that must be entered at the keypad when that PED Key is presented.
As with M of N, the PED PIN secret is an option that is chosen via the PED. For each key that is imprinted, you are given the option to set a PED PIN secret (typed on the keypad) in addition to the secret contained inside that PED Key. As each PED Key is unique, it can be given:
As you can imagine, combining permutations of M of N with permutations of PED PINs could make for a very complicated security scheme. You have these options; it is up to you to choose and combine them in ways that meet your security needs without over-complicating the lives of your personnel.
Once M of N is set (either M=1 and N=1 for no multi-person access, or M and N each larger than 1 to invoke multi-person access control), that setting remains in place until the HSM or partition is zeroized and re-initialized.
So, if you decided that you wanted to stop using/requiring M of N, or that you wanted to have M of N, but with a different total number of split-keys (N) or a different minimum quantity of keys that must be presented (M) to re-construct the secret (blue, black, red, etc.), then you would need to zeroize (factory reset) and re-initialize the HSM. Or for just individual partitions, you would need to delete the partition and create a new one with the new authentication. To preserve the HSM and partition contents, you would perform backup before re-initializing the HSM, and then restore from backup afterward.
Historical Note:
On Luna SA 4.x systems, if one HSM had M of N (using the legacy green PED Keys), and you wanted another HSM to use the same M of N splits, you had the option to clone M of N from the first HSM to the second.
Current Practice:
With Luna SA 5 (containing the K6 HSM keycard) where M of N is a condition of each authentication secret independently, there is no provision to "clone M of N". Instead, if you wish to have two HSMs share the same M of N scheme, you must initialize one with the desired scheme, then initialize the second (and any additional) HSM and have it re-use the secret(s) from the first HSM.
At secret-creation time for the HSM, when the PED is invoked, the PED asks if you wish to re-use an existing secret. If you say "yes" to that question, then the PED expects you to offer a PED Key (for example a blue PED Key, when you are initializing) that is already imprinted with a suitable secret. If you offer a blue key that contains a partial secret - a split from your other HSM - the PED accepts that key. The connected HSM recognizes that the secret is only a split, not a full SO secret, so the PED demands additional keys from that set, until it has received M of them, enough to reconstitute the secret. It will not accept fewer than M different portions of the secret, and it will not accept members of another set.
Once the reconstituted secret has been imprinted on the new HSM, then that HSM can accept any M splits out of the full set of N, even though it has never seen some of those splits. Both HSMs now accept the same M of N authentication secret. You can do the same, individually for any of the other secrets on the new HSM (black partition User keys, red cloning Domain keys, orange RPV keys). The only exception is the purple PED Key (or Keys), since the MTK and SRK are unique to each HSM and cannot be cloned or shared.
Purple Keys:
You can duplicate a purple PED Key while you are in the process of imprinting it (SRK enable, SRK resplit).
You can split the purple-key secret (which is already one split of a larger secret inside the HSM) so that the Secure Recovery Vector secret needs multiple purple key holders to invoke it.
You can re-split the internal MTK of your HSM, resulting in a new SRV portion imprinted on the external purple key (or keys, if M and N are greater than 1).
You cannot generate a new master secret on the HSM - the MTK is unique and permanent for each HSM and can be changed only by remanufacturing. Factory reset and initialization have no effect on the MTK.
You cannot imprint a purple key secret from one HSM onto another (for the same reason as above), unlike all the other key colors where sharing/grouping are important options.
You cannot duplicate a purple PED Key via the PED's stand-alone (no HSM present) Admin menu. The "raw" duplication function, which works for all other PED Keys, refuses to duplicate purple keys. This is a security feature, so that no one can duplicate a purple key without access to the HSM that created it. This applies to splits of the SRK as it applies to a single SRK purple key.
Here is one suggestion for having the security benefit of M of N, including backups, but without the risk of accidentally mixing
If your M and N numbers are small, like (say) 3 of 5, simply declare a large N (up to 16 splits is permitted, so in this case use 3 of 15) and simply gather them into groups of (say) 5, one group for regular operations, one group for standby, one group for off-site backup storage. In this way, all the splits are valid together in any combination- any three of the 15 can unlock the HSM. You do, of course, need to control distribution of, and access to, all those secret-split keys.
If your M number is larger, then this idea becomes less practical, since you have a maximum N of 16 to work with. It depends on how many sets of M you need. At the very least, you should have one backup of every HSM authentication secret, preferably in secure off-site storage.
M of N is not for everybody. For those who need it, it is crucial, and the added administrative task is a "cost of doing business". If you don't need M of N in your security regime, then we suggest that you not use it.
If your security policy demands that you use M of N multi-person access control and also demands that M be relatively large, consider carefully if your policy might need review. Any security regime should be no more complicated than it needs to be - no more complicated than yields a net-positive security benefit. The more complicated or onerous a security policy, the more your own personnel - even the most trust-worthy - are motivated to circumvent or simplify, in order to get on with their tasks.