Below are some suggested holders of PED Keys by role.
|
Lifecycle |
PED Key |
Operational Role |
Function |
Custodian |
|
PED keys enforce division of operational roles and prevent unilateral action by key holders |
||||
|
Admin |
or (*)
|
Security Officer |
Token/HSM Administration Set token security policy Select token initialization parameters Create Users |
CSO |
|
or (*)
|
Domain Cloning |
Set Cloning Policy Create/Transfer Cloning Domains Token Backup |
Domain Administrator WAN Administrator |
|
|
or (*)
|
Secure Recovery | Recover from Secure Transport Mode or tamper event | CSO | |
|
or (*)
|
Remote PED | Establish a Remote PED connection | System Administrator | |
|
Daily Operation |
or (*)
|
HSM Partition User or |
Key Generation Signing Decryption |
System Administrator |
|
Ongoing Auditing |
or (*)
|
Audit User |
HSM Audit logging HSM Audit Archiving |
Auditor |
[*In each case, you have the option, instead of a single PED Key of a particular color and function for a particular role, to split the relevant authentication secret across several PED Keys of that color and function (we show 4, in the table, but you could have any number of splits up to 16 for each secret). This is the M of N split-knowledge shared-secret option that you set when a PED Key is created. The M of N option is set, or not, as a result of your choices when responding to PED prompts for "M value" and "N value".
Set "M" and "N" to 1, and no split occurs. The secret - blue SO key, red Domain key, black User or Partition Owner key, purple Secure Recovery key, white Audit Key, or orange Remote PED key - is not split, and is imprinted on just a single key of that color. The result is that a single person can hold/control the entire authentication authority for that role.
Set "M" and "N" to values higher than 1, and the secret gets split across "N" different keys of the relevant color. A minimum of "M" of those keys must be brought together in order to authenticate. This allows the role to be spread over multiple persons, with no one holder able to authenticate by himself/herself.
The multiple keys of a split secret are NOT to be confused with DUPLICATE or COPY keys. During key creation (and at other times) the PED enables you to make extra copies of the complete secret for, say, the SO or the Partition User. Those are identical copies that you can
If you do not set M of N (example N = 1), and you ask for copies, then the PED makes 1 copy of the 1 key that holds the complete secret. You can make as many copies as you wish, but each one alone is capable of unlocking that function/role on the HSM. No other person is needed in order to unlock and use that function/role of the HSM. No other person knows about that usage, except after the fact if you have set up Audit Logging.
If you do set M of N (example, 3 of 5), and ask for copies, then the PED makes 1 copy of each of the 5 original splits. Each split within a set is unique in that set. Authenticating with M of N requires that you present M different splits to reconstitute the authentication secret. Avoid mixing members of M of N sets.To illustrate why this is bad, if your SO authentication was split over N=5 keys and needed M=3 different splits to authenticate, and you presented split-1 and split-2 from the original set, along with split-1 from a copy set, authentication would fail. From the perspective of the PED, you have tried to present split-1 twice, rather than providing three different splits from the secret. The PED would rightly refuse to authenticate.
Because M of N is controlled on the PED, you can choose to have some secrets split and others not split. You could have just one blue key needed for SO administrative actions, but (say) 3 black keys needed for each partition activation.
The point is to use M of N where it is important that a single person not be able to perform that role without supervision/participation by other co-key-holders. Each organization can have its own rules in that respect.
The M of N trade-off is greater security for greater management load. Split secrets increase security by requiring agreement and participation among multiple persons and thereby preventing unilateral action by a single person. But split secrets mean the existence and tracking and management of more physical keys and holders of those keys.]
