|
Home > |
|---|
This section contains suggestions for your handling of PED keys. Naturally you should be guided primarily by your organization's security policies. At a minimum, in an operational environment, have at least one working set and one full backup set, and a way to tell them apart. You will require additional PED keys if you decide to use the MofN security feature.
For both Local and Remote PED use, the only way for another person to discover a PED PIN password while you input it is if you allow that person to observe while you use the PED keypad.
The use of PED and PED keys prevents key-logging exploits on the host HSM, because the authentication information is delivered directly from the hand-held PED into the HSM via the independent, trusted-path interface. You do not type the authentication information at a computer keyboard, and the authentication information does not pass through the internals of the computer, where it could possibly be intercepted by spy software.
This section contains the following:
•Forcing Automatic Password Input
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 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
Combining permutations of MofN with permutations of PED PINs could make for a very complicated security scheme. 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.
When you initialize a PED-authenticated HSM (or create a partition, or perform any action that imprints a PED key), and you choose to associate a PED PIN with the PED key secret, you must ensure that the PED PIN will be remembered when it is needed. That normally means writing it down on paper or recording it electronically. This represents a security risk to not record the PED PIN and be unable to remember it.
Before you tuck that yellow-sticky with the PED PIN into your safe, try it once, to verify that you did set the PED PIN that you think you set (or that you correctly recorded what you actually set). In the case of a red key, that would mean you would need to attempt a cloning or backup/restore operation before storing your record of the PED PIN.
Other than tracking
•Where PED keys are,
•To which HSMs they apply,
•Who is in possession of, or has access to, each PED key,
Maintaining your PED keys means
•Making new copies if any suffer damage, and
•Ensuring that the secrets on the keys, and any associated passwords (PED PINs, client challenge secrets) are updated in a prompt and orderly fashion, in case of suspected compromise, and in compliance with any "password-change" security policy requirements at your organization.
Consider some of the examples like PED PIN and MofN combination, and how much logistical and organizational effort would be involved in a mass password change for one secret.
These considerations are important when you develop your authentication and security schemes around SafeNet Luna HSMs and PED keys.
If you have a service running, in limited circumstances you can force your application’s administrator to provide the partition’s password each time the service or application server is restarted.
If an application directly accesses the HSM partition, must initialize the library and open a session on the HSM. Then the application provides the partition authentication when needs to perform actions on partition contents. For either Password-authenticated or PED-authenticated HSMs, the partition password (or partition challenge) secret must be available to the application so that it can provide that secret when access to partition objects is needed. The application provides the partition secret to say that it has the right to perform partition-object actions. This usually means that the secret is stored somewhere on the host's file system or registry (most likely encrypted) for retrieval when needed.
The application, then, is already providing the partition password (or challenge secret) string whenever it is demanded by the HSM.
For PED-authenticated HSMs, the PED key data for that partition must be provided to the HSM before the partition secret string is provided. In almost all cases, for PED-authenticated HSMs, customers would Activate the partition when first setting up, so the PED key data for that partition would be cached. That is, the customer would be making an authenticated administrative declaration that the partition was "open for business" and an application with the partition challenge secret could then access partition objects at any time.
The application could open and close sessions at will, and whenever it needed to manipulate partition objects, the application would provide the partition (challenge) secret. Once the Partition PED key data is available, the action of accessing and using partition objects is identical for PED-authenticated or Password-authenticated HSMs.
If the partition is autoActivated, then the black PED key data is cached in the HSM, just as for Activation, except it is now protected against power failure for as much as two hours.
So, for the direct application-to-HSM scenario, if you want to force the application owner to perform an authentication beyond what already performs with each access to partition objects, then you would need to:
1.Use a PED-authenticated HSM, and
2.Ensure that the PED key data for that partition was NOT cached - therefore, no Activation or autoActivation (Partition Policies 22 and 23 would be set to off).
The application still has access to the partition challenge secret, but the partition is not "open for business" A PED key must be provided (possibly a PED PIN as well, if you set one). However, the drawback is that EVERY access of partition objects now requires PED key authentication, in addition to the partition challenge secret. The PED would remain connected to the HSM, the key for that partition would remain inserted, and somebody would have to press the PED's Enter key every time the application needed to manipulate a partition object.
The above is the situation for direct access to the HSM by an application; it is only for very specialized situations where the partition is rarely accessed, and extremely close control is required.
If you insert a service between your application(s) and the HSM, then the application no longer needs to know anything about HSM and its authentication. Instead, the service must handle all that, translating between the application and the HSM. The conditions described earlier now apply to the service.
Similarly, if you insert a provider (a translation layer like our CSP or KSP or JSP) between your application and the HSM, or between your service and the HSM, then the provider takes care of safeguarding and using the partition password (or partition challenge) secret as needed.
In either case, the need for PED key presentation and PED button pressing is determined by the state of Partition Policies 22 and 23.