Open topic with navigation
First, what is it?
The M of N feature provides a means by which organizations employing cryptographic modules for sensitive operations can enforce multi-person control over access to the cryptographic module. The feature is available in all Luna SAs configured to use Trusted Path authentication – using the PIN Entry Device (PED) and PED Keys.
M of N involves a splitting of the 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 secret can be split when it is created: blue SO PED Key, black User/Partition Owner PED Key, red Cloning Domain PED Key, orange Remote PED Vector key, purple Secure Recover Key.
Without M of N, you can initialize an HSM such that you must produce a single blue HSM Admin/SO PED Key in order to login and perform HSM management functions, and you must produce a single black Partition Owner/User PED Key in order to activate a Partition to receive Client connections and allow Client applications to perform operations within the Partition, and so on. And that can be the extent of your security and oversight. If that is sufficient, you can stop reading.
With M of N, the authentication secret on one blue SO PED Key or one black Partition Owner PED Key (or red Domain key or orange Remote PED key or purple Secure Recovery key) is still necessary, but is no longer sufficient for authentication. Access now requires additional authentication by an overseer, or several overseers. That additional oversight is the M of N "split knowledge shared secret". What that means is that the SO secret, or partition User/Owner secret, or cloning Domain (as well as the Remote PED secret and the Secure Recovery secret) can be split into portions (over several PED Keys of the current color, rather than just one), and those must be brought together in order to re-create the complete secret. At initialization time, 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.
Where/when to use it
Use M of N when you want a particular type of HSM access to require the presence of more than one person. M of N 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 SO and Domain, but not for Partition owner/user, nor SRK, nor RPV... or any other combination that made sense in your environment.
During initialization of the HSM, the HSM Admin or Security Officer [SO] invokes M of N if desired as the procedure reaches the point of creating/imprinting each authentication secret. 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. This second number, M, can be any number up to N. From that point on, any future login or invocation of that particular authentication (blue key, black, red, orange, purple) 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. One holder of the Owner key or the HSM Admin/SO key must bring together M different share-holders, each with one of the black or blue keys, as appropriate, before the HSM can be unlocked.
M of N is not a splitting of the private signing key; it is splitting of the Luna HSM's individual authentication/access secrets. That is, M of N is a splitting of the secret that lets you into the HSM, but not a split of the working (encrypting, decrypting, signing, verifying) secrets - your keys and certificates - contained inside the HSM.
Do not use M of N unless you will be giving each split-containing PED Key to a different person. We recommend that you not use M of N unless you have established a definite need for it. The additional security of split-knowledge shared-secret multi-person access control comes at the cost of additional administrative overhead, and increased possibility of making an administrative or handling error that could leave you unable to access your keys and certificates.
In previous versions of Luna SA, M of N was a selection made at the command-line (lunash) via the "hsm init" command. You could elect to use M of N or not, by means of options to the "hsm init" command. M of N, was a separate secret, spread across N green keys. If you invoked M of N, then it was always in force for that HSM (until the HSM was re-initialized). If you invoked M of N, it was in force HSM-wide.
Beginning with Luna SA 5.0, the green keys no longer exist. Each standard authentication secret (SO, User, Domain, RPK, SRK.) can itself be split into N different components, of which M of them are needed to reconstitute that authentication secret. The decision to invoke M of N for any of the HSM's authentication secrets is no longer made via the command line. Instead, M of N is a PED function, a choice that you make when the secret is created (such as during HSM initialization or partition creation). M of N can therefore be applied to some secrets of an HSM and not to others, at your discretion, and as your organization's security policy dictates.
In usual practice, you select a number M which is the number of trusted people who must be present when HSM authentication is performed - each of them is issued a colored PED Key containing one share of that total M of N secret. The larger the number, the more operationally difficult it can be to get them all together when needed. Then you select a number N which should be a little larger than M, to allow for substitutions. This allows you to achieve M different secret shares in order to access your HSM, even though some of the total key holders might be absent due to illness, travel, etc. That N is the total number of shares into which the M of N secret will be split.
To login with M of N, you are first prompted to supply a blue PED Key (or a black PED Key, as appropriate to the task), then you are prompted to supply each additional (different) key of that color until M splits have been presented - those can be any M of those keys, 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 secret when required (where M is usually less than N).
The rationale, and how the feature is implemented
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 datacenter, 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.
To satisfy these design requirements we have a concept of Partition Activation. 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 may be rebooted for maintenance 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.
The most 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 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.
Revoking Means Re-initializing
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.
How to Add an M of N Requirement Where There Was No M of N Before
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.
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 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.
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 members of original split set and backup split sets. [Remember, the risk is not that members of "original" and copy sets can't work together - they do - the risk is accidentally having copies of the same key together. The PED requires different splits when combining quantity M splits to recreate the authentication secret. If you offer it one split and then a copy of the same split (because they all look alike and you accidentally gathered them into incorrect groups), the PED will reject the identical offering because it assumes you are offering the same split twice.]
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 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 things done.
Open topic with navigation