# Cryptographic Acceleration - Conversation - Request:Response

## Contents
Conversations for Crypto Engines

## Conversations for Crypto Engines
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.