|
Home > |
|---|
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 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 host or application server, 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 (see "About Activation " ).This allows administrators of the PED-authenticated 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 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 client applications can no longer access the partition, regardless of 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):
• You could choose not to invoke M of N for any HSM authentication secret - so only one blue SO key, and one black User key, one red cloning key, one orange Remote PED key, and one purple Secure Recovery Key, would be needed to access the respective HSM functions. One person could perform each function without oversight.
•You could choose to invoke M of N for some secrets and not for others. For example, HSM-level access could be configured to require multiple blue PED Keys while, say, the partition-level access needs only one black PED Key. The HSM security officer would need M people to agree that she/he had the right to log into the HSM, each time, but any individual partition owner/User could activate her/his own partition with no oversight. The reverse could also be true, with the SO needing just a single blue key for HSM login and HSM administration, but the various partition owners needing multiple persons with black key splits to activate or deactivate their partitions.
•You could invoke M of N for every role, but set different M and N values per role. HSM administration might have a pool (N) of 5 blue keys and need 3 (M) of them for any HSM login event. Meanwhile the pool of black keys (N) for a given partition might be 3 or 6 or 10 or as many as 16, but the number of holders (M) needed to activate the partition might be just 2 (or any number up to N)... and so on, in as many combinations and permutations as make sense for your situation. Similar choices would apply for red, orange, and purple key secrets and for the Audit role. As well, while you can choose to reuse a black PED Key (or an M of N set of black PED Key splits) to create and access multiple HSM Partitions (on a single HSM where permitted, or on different HSMs), you could also choose to imprint a different black PED Key secret (or separate M of N sets of black PED Key splits) for every partition, or any combination of those options.
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 (see "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:
•no PED PIN
•the same PED PIN as other members of a set
•a completely different PED PIN.
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.
Decide whether you want M of N before you initialize your Luna HSM or create a new partition. Read the other pages in this section, to determine what you expect from the feature and whether it fits your policy and operational considerations.
In general, you would determine the number of persons who are to be trusted with single M of N shares and assign that number as N. This applies individually to each authentication secret (blue, black,and red, as well as orange and purple if you are using those). Then, you would decide how many of those people your policy will require to be present whenever the HSM Admin or the Owner logs in to the HSM (or Activates the HSM). Assign that number as M.
You must have quantity N of blank PED Keys in order to implement M of N for a given authentication secret. You need that many keys when you initialize an HSM and choose M value and N value greater than one, when prompted by the PED. They should be blank, or (if they were previously used) no longer needed for any other purpose, because they will be overwritten with new authentication data during this procedure.
To initialize a Luna HSM with M of N (example uses N =5, M = 3) for the SO secret :
1.Open a lunacm session and select the appropriate HSM (if you have more than one installed).
2.Run the hsm init command.
Type:
lunacm:> hsm init -label myLuna
The following warning appears:
WARNING: Are you sure you wish to re-initialize this HSM?
All containers [HSM Partitions] and data will be erased.
Type 'proceed' to delete the container, or 'quit' to exit now
Type:
proceed
3.The initialization proceeds as described in "Initializing an HSM (Trusted Path option)" as each secret is created, the PED prompts for "M value =" and "N value =". For any secret, set M and N equal to "1" if you do not wish to invoke MofN secret splitting for that secret. Set M and N larger than "1" if you require secret splitting (multi-person access control) for that secret - SO, domain, etc.
4.If you are splitting the current secret, insert a blank PED Key and press [Enter] on the PED touchpad. Create a PED PIN for that split, if you wish, or just press [Enter][Enter] for no PED PIN.
5.The same sequence of PED
prompts reappears. Insert another same-color PED Key and press [Enter].
During this process, you must supply a fresh same-color PED Key at each
prompt. Do not present the same PED Key twice.
6.Repeat until Luna PED stops asking for more that-color PED Keys. It requests as many blank keys as the quantity "N value" that you supplied in the opening PED prompts for this secret's creation (in this example, 5). Label the PED Keys to avoid mix-ups.
7.The procedure
that you started in "Initializing an HSM (PED Authenticated option)"
continues until you need to login. First, Luna PED prompts for the blue
HSM Admin PED Key, as described in the standard procedure. Then, Luna
PED begins demanding blue imprinted PED Keys until it has received "M" different ones from that MofN set.
8.Continue to insert one of the imprinted SO-split (blue) PED Keys and press [Enter], and repeat until Luna PED is satisfied. You must insert M different keys when authenticating. Luna PED recognizes if you attempt to present the same key more than once during an authentication attempt. So, in this example, 3 of the 5 blue keys are needed - any 3 from that imprinted set of 5, as long as they are different.
9.Complete the rest of the hsm init procedure, then hand out the imprinted PED Keys to separate, trusted persons whose job it is to come together whenever HSM authentication is needed.
Once you have completed the initialization with M of N, then every time you need to authenticate to this Luna HSM, you will need M of the N blue or red (or any other authentication - black, orange - for which you specified M greater than 1) PED Keys in that group.
Normally, M should be smaller than N, so that you can login to the HSM (or Activate/autoActivate it) while some of the trusted N persons are away for business, vacation, illness, etc.
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 HSM 5 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), via M of N, 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 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.