|
Home > |
|---|
It can, occasionally, be less than obvious why a certain action requires that you authenticate to the HSM or to the Partition, while another action does not.
Such questions have been carefully considered, from a crypto-security perspective, and we believe that we have consistently made the correct determination in all cases.
An example might be:
If I activate an existing partition - make a service available to customers - I must have the black PED Key for that partition
But if I want to deactivate the same partition - withdraw/deny the service - I do not need the black key).
Is making a service available considered more dangerous than taking it away?
The rationale behind this behavior is that when you activate a partition you are making crypto services available to applications (that have the correct challenge password, of course). From a crypto module perspective, making crypto services available is a big thing and requires proper authentication. Removing that availability might be an operational issue but it is not a crypto security issue and, therefore, did not require the Black key.
As well, if an attacker wishing to deny service is given physical or command access to your HSM, he or she can do a lot more damage than simply issuing a partition deactivate. In other words, if you have let them get that deeply inside your security perimeter, then you have far worse problems than a "partition deactivate".
If you ever discover a situation where our implementation seems inconsistent with that philosophy, please let us know by contacting support@safenet-inc.com. We will either fix the problem or explain why it is not considered a problem.
If I have a service running, can I force my application's administrator to provide the partition's password each time the service is restarted and/or each time the application server is restarted?
It depends on the setup, and it depends on what you mean by password. But, in limited circumstances, yes, although you probably would not want to do that.
It doesn't really matter whether your application accesses the HSM directly, or whether a service or some other provider is between application and HSM.
If an application directly accesses the HSM partition, then when it first does so, the application must initialize the library, and open a session on the HSM. Then the application provides the partition authentication when the application 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 (the application) 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 .
This means that the application is already providing the partition password (or partition challenge secret) string whenever it is demanded by the HSM. So, in that sense, the answer to your question is already "yes".
But if you meant something stronger than the password-presenting action that the application must already perform when accessing partition objects, you probably need to consider PED authenticated HSMs.
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 (activating the partition) that the partition was "open for business", and an application with the partition challenge secret could then access partition objects at any time.
Note: Authentication differences - Password-authenticated vs PED-authenticated:
- When the HSM is PED-authenticated,
-- the administrative role secret contained on a black or gray PED Key is one secret, used only by administrative personnel, while
-- the challenge-secret or password is a second secret (plain text, initially presented on the PED screen, but you can change it), which is the application-authentication secret, that allows the HSM verify that the presenting application is entitled to perform cryptographic operations on the particular application partition.
The application can submit its own authentication (that second secret) only after the PED Key secret has "opened" the HSM partition for operation (by Activating) - that is, there are two levels of protection, one administrative, and the other operational, where the operational level is gated by the administrative level.
- When the HSM is Password-authenticated,
-- the administrative role secret is also the application-authentication secret, one plain-text secret used for two purposes; the application that knows that secret declares the application partition open-for-business while in the act of accessing it with that single secret as its authentication - a single level of protection that is both administrative and operational. On a Password-authenticated HSM, once the administrator (Crypto Officer or Crypto User) has distributed the secret to the application(s), the only way to restrict access by applications (or personnel) that have come into possession of that secret is to change the password - which also changes the authentication for the associated administrative role.
With the partition unlocked by Activation and the application in possession of the challenge secret or password, 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 the application already performs with each access to partition objects, then you would need:
a.to use a PED-authenticated HSM, and
b.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 its 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), every time authentication is needed.
The drawback, in that scenario, 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 her-or-his finger poised 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).