HSMs protect the private keys they hold using a variety of mechanisms,
including physical tokens, passphrases, and other methods. When use of
the private key is required by some agent, they need to authenticate
themselves with the HSM and be authorized to access this data.
Whatever the mechanism protecting the keys on the HSM, this will
commonly require some interaction with the agent. The most common form
of interaction required is for the agent to present a passphrase. The
intent is generally that this is carried out by a real person, rather than
produced mechanically by the agent. Other forms of interaction may include
prompting the operator to insert a specific card into a card reader, for
example.
The requirement for an operator to enter a passphrase renders automated
startup of services using the HSM impossible, however. Although weaker
from a security standpoint, the server is able to conduct an
automated dialog with a HSM when it requires access to a private key,
presenting specific responses to specific requests, including feeding
passphrases to it. (This will, of course, be futile if the dialog calls
for the insertion of a physical token in a device.)
The dialogue for different keys on the same device will often be the
same. For example, a number of keys on an nCipher HSM may require the
server to present an operator passphrase for a pre-inserted card in a
card-reader. The specific dialogues are therefore associated with the
cryptographic engine.
Each dialogue consists of a set of expected request/generated response
pairs. The "expected request" takes the form of a regular expression. When
the cryptographic device prompts for input, the text of this prompt
is compared against each expected request in the conversation, until
a match is found. Once matched, the corresponding "generated response"
is delivered to the HSM.
In the simplest case, consider a HSM producing the following prompt
| | |
|
Enter passphrase for operator card Operator1:
| |
| | |
|
We can identify this, for example with the following regex:
"passphrase.*Operator1"
In the configured conversation, we can make the expected response to
this prompt the passphrase for the specific card, for example:
"tellNoOne"
The server is somewhat at the mercy of the HSM for how this dialog
continues: if the HSM continues to prompt for requests, the server can
only attempt to respond. You may set the "maximum expected challenges"
setting on the conversation to indicate a maximum number of prompts
to expect from the HSM, at which point the server will do its best
to terminate the conversation, almost certainly failing to load the
affected key.
|