Home >

Administration Guide > PED Key Management > Updating PED Keys – Example

Updating PED Keys – Example

The following is just an illustrative example of changing PED Keys (or the authentication secrets on the PED Keys and the corresponding secrets on HSMs). For the purposes of the example, we will ignore additional complicating factors like PED PINs and MofN that might apply to your situation.

Say, for example, that you had shared PED Keys among three HSMs, and that you also made three other copies of that SO PED Key, so that you and two other persons could each work with one (or any) of the HSMs, and so that the fourth PED Key could be stored away securely.

Risk of Losing access

If you were to “Change PIN” for your own PED Key (and your HSM), then that PED Key would work for that HSM, but the PED Key would no longer work for any of the other HSMs and none of the other PED Key holders of your group could access your HSM. Your HSM would expect the new PIN, and the other people would be holding PED Keys with the original PIN.

Immediately, you see that any time you change passwords (PINs) it must be done for all HSMs (or Partitions) in such a group, and for all PED Key duplicates associated with that group of HSMs (or Partitions if you are changing black User PED Keys).

PIN-change Procedure for Multiple HSMs

CAUTION:  You must retain at least one old-PIN PED Key until all HSMs have the new PIN, or you will find yourself unable to access old-PIN HSMs.

1.Choose an HSM and login as SO (with a blue PED Key).

2.Request a change of SO PED Key:

lunash:> hsm changePw
 

3.Respond to the PED prompts as follows:

Getting current SO PIN...
Reading SO PIN...
Insert a blue Key
           

This is where you insert a currently valid SO PED Key to confirm that you are the key holder.

<Press ENT>
 

The PED requests the key because an indeterminate amount of time might have elapsed since the last HSM login and confirmation is needed that the person asking for a change of secret is the person who logged in (and not an unauthorized person taking advantage of an unattended login session).

Reading SO PIN
Please wait..
Would you like to reuse an existing keyset? (Y/N)
 

Here you respond "NO" so that a new SO secret is generated.

M value  (1-16)
>0
M value  (1-16)
>0
Writing SO PIN...
Insert an SO Key
 

This is where you insert the first SO PED Key to be overwritten; it might be the same one that you just inserted to authenticate as SO

<Press ENT>
Writing SO PIN...
PED Key will be overwritten
 

The PED detects existing (old) data on the key and warns you that it will be overwritten if you proceed.

<Press ENT>
Writing SO PIN...
Enter new PED PIN
 

This is a new secret, so you have the opportunity to add a PED PIN to it, if you wish.

Writing PED PIN...
Confirm new PED PIN
Are you duplicating this keyset? (Y/N)
 

Answer "YES" because you want to overwrite the old secret on two of the remaining three PED Keys (in this example).

Writing SO PIN...
Insert SO key
 

This is where you insert the second SO PED Key

<Press ENT>
Writing SO PIN...
PED Key will be overwritten.
<Press ENT>
Writing SO PIN...
Enter new PED PIN
 

You can add a PED PIN to this duplicate key if you wish, or not. If you add a PED PIN it does not need to be the same as on the other key.

Writing PED PIN...
Confirm new PED PIN
Would you like to 
make another'
duplicate set? (Y/N)
 

Respond "YES" and make the change on the third SO key, but leave the fourth key with the old secret for now.

Command Result : 0 (Success)
[luna22] lunash:>
 

At this point, you now have ONE HSM and three of your four SO keys imprinted with the new SO authentication secret. Ensure that you keep the keys separate and well identified. One PED key MUST retain the old secret until all HSMs are updated to the new secret.

4.Go to the second of your SafeNet appliances, login as admin.

5.Request a change of SO PED Key (this time you will not be changing key contents, you will be logging in with the old secret, then copying the new secret from one of the updated keys onto the second HSM):

lunash:> hsm changePw
 

6.Respond to the PED prompts as follows:

SO login...
 

This example step shows that if you had not already logged in prior to requesting "hsm changePw" then a login is forced.

Insert blue PED Key
 

Insert the old-secret PED Key, to login -- this HSM still has the old secret.

<Press ENT>
Getting current SO PIN...
Reading SO PIN...
Insert a blue PED key
 

The system does not track how long ago the login occurred, so before a key change is permitted, it requires you to prove that you are the valid keyholder, by producing the key again.

<Press ENT>
Reading SO PIN
Please wait...
Setting SO PIN
Would you like to
reuse an existing
keyset? (Y/N)
 

Here you respond "YES" so that the new SO secret will be read from the new-secret-containing key that you are about to insert.

Reading SO PIN...
Insert a blue PED Key
 

This is where you insert a new-secret SO PED Key so that its secret can be read and then imprinted on this second HSM.

<Press ENT>
Would you like to 
make another'
duplicate set? (Y/N)
 

Respond "NO". This HSM now has the new secret.

Command Result : 0 (Success)
[luna22] lunash:>
 

At this point, you now have TWO HSMs and three of your four SO keys imprinted with the new SO authentication secret. Ensure that you keep the keys separate and well identified. One PED key MUST retain the old secret until all HSMs are updated to the new secret.

7.Remove the new-secret key from the PED and place it with the other new-secret keys.

8.Bring a PED and the remaining old-secret key to the third appliance and login as admin.

9.Request a change of SO PED Key (you will be logging in with the old secret, then copying the new secret from one of the updated keys onto the third HSM, then overwriting the final old-secret key with the new secret, once the old secret is no longer needed).

Note:  You can explicitly login (with "hsm login") before issuing "hsm changePw", or you can wait until you issue the change command and be prompted to login.

lunash:> hsm changePw
 

10.Respond to the PED prompts as follows:

SO login...
Insert blue PED Key
 

This prompt appears if the HSM was not already in the login state. Insert the old-secret PED Key, to login -- this HSM still has the old secret.

<Press ENT>
Getting current SO PIN...
Reading SO PIN...
Insert a blue PED Key

Here, the PED wants the same secret that you used to login.

<Press ENT>
Reading SO PIN
Please wait...
Setting SO PIN
Would you like to
reuse an existing
keyset? (Y/N)
 

Here you respond "YES" so that the new SO secret will be read from the new-secret-containing key that you are about to insert.

Reading SO PIN...
Insert a blue PED Key
 

This is where you insert a new-secret SO PED Key so that its secret can be read and then imprinted on this third HSM.

<Press ENT>                              
Would you like to 
make another'
duplicate set? (Y/N)
 

Respond "YES", and supply the last old-secret PED Key as the "blank".

Command Result : 0 (Success)
[luna22] lunash:>
 

At this point, you now have all three HSMs and all four SO keys imprinted with the new SO authentication secret.

If you prefer to be more cautious, you could have left the final PED Key with the old secret until you verified that all three HSMs are now unlockable by the new secret, and only then invoke the command one more time to imprint the last key with the new secret.

Alternatively, on a SafeNet PED 2.x, you can perform iKey PED Key copying or duplication at the PED without invoking commands at the HSM (however you still require a connection between PED and HSM to power the PED).

Note:  You can perform the same operations with blue SO PED Keys, in similar circumstances, and observing the same precautions. Also, this sort of operation could be scaled up for larger groups of HSMs (if they share a group-User or group-SO PED Key) and for larger numbers of duplicate PED Keys.

Note:  To avoid confusion, it's probably best if you mark each key to identify it, and keep a careful log of which key and which HSM has what operation done to it, at each step.