The following figure shows an overview of the process of generating a key pair for a Signer by the SAM service.
Figure 19: Overview of the Generate_Signer_Key_Pair operation flow
A Privileged User or Signer uses the SAM Peer Interface (SAM PI) to request the operation. Authentication and identification of the requesting user is required beforehand.
When the request is retrieved, the SAM service verifies that the requestor is authenticated and identified (based on the processes and configuration outlined above).
If the authenticity and identity check is successful, the SAM service generates the Signer's key pair. Specifically, the SAM service requests
Requests the cryptographic module (SAM HSM) to generate a key pair,
The SAM firmare
generates the Wrapped Key based on the generated key pair, signs the Wrapped Key,
generates a certificate request based on the generated key pair, signs the certificate request
sends both the Wrapped Key and the certificate request back to the SAM service,
The SAM service then requests storage of the Wrapped Key in the Key Manager (KM), stores the signed certificate request in the key manager (KM). Otherwise, an error is returned.
Keys generated by the CM are exported as a secured key using the CM's module key (CM wrapped key) and stored as part of a signed container (Wrapped Key) in the Key Manager (KM). A key stored outside the generating CM is protected in terms of confidentiality and integrity. The integrity of keys is protected by using the wrapped key structure, which is signed before it is stored in the KM. Key confidentiality is protected by using the CM's module key for encryption, resulting in the CM Wrapped Key.
A Wrapped Key has the following structure: {CMwrappedKey, KeyID, Metadata}. Metadata' contains metadata specific to the remote signature, such as the ID of the associated Signer.
|
Purpose |
This process is invoked by the requestor to generate a new key pair and assign it to a specific user. |
||
|
Interface |
SAM Peer Interface (see [IF_SPI]) |
||
|
Method of use |
The operation is called by client software according to the SAM peer interface specification (see [IF_SPI]). |
||
|
Inputs |
Parameter |
Typ |
Description |
|
userid |
String |
UserID of the user for whom the key pair is to be generated |
|
|
algorithm |
String |
Algorithm (EC or RSA) |
|
|
parameters |
RSAparameters | ECparameters |
Algorithm specific parameters: RSAparameters: key length in bits. ECparameters: named curve as OID |
|
|
Output |
Parameter |
Typ |
Description |
|
keyid |
String |
The KeyID of the generated key pair |
|
|
publickey |
Binary |
A public key signed with a private key used exclusively by the SAM |
|
|
Error Messages |
Typ |
Reason |
|
|
ContainerParseError |
If the input cannot be parsed into a message container |
||
|
MessageParseError |
If the input data cannot be parsed into the specified message type |
||
|
UnknownMessageType |
The contained message type was not known to the processor |
||
|
UnknownCredentialType |
The credential type included was not known to the processor |
||
|
|
|||
|
|
AuthenticationError |
The credential could not be validated |
|
UnknownUser |
The credential could not be associated with a user |
|
|
NotAuthorized |
If the acting user is not authorized to perform the current operation When a regular user specifies the UserID of another user |
|
|
NotOperational |
A component (e.g. , HSM) is not available or not in an operational state |
|
|
UnexpectedError |
When an error condition occurs that was not anticipated |
|
|
Security Audit Log Entry |
In case of success An audit record is created that contains at least the following information
The following errors emit regular log messages, but no audit log entries (since no acting user could be inferred):
An audit record is created containing at least the following information
|
|
Table 20: Description of the Create_Signer_Key_Pair operation