Key Management
Key management is critical to successful deployment of a secure application. It is important to use the right tools and follow standard techniques wherever possible.
Backup and Restore
The KMU provides key backup and restore facilities for keys. Backup operations can only be performed if the keys were created with the right attributes.
The recommended procedure for key backup is to use the CKA_EXPORT and CKA_EXPORTABLE attributes for the KEK and working keys, respectively. These are preferable to CKA_WRAP and CKA_EXTRACTABLE because there is no control on setting the CKA_WRAP attribute (see Application Security). The CKA_EXPORT attribute can be set to TRUE on a key only when the security officer (SO) is logged in to the token. This prevents working key exposures by introducing a known KEK to the device. The SO creates export keys, while the user is able to use them but not create them.
Only keys that have the CKA_EXPORTABLE attribute set to TRUE can be exported, and only by keys that have the CKA_EXPORT attribute set to TRUE. This allows the possibility of keys that can never be exported from the device, or can be exported a limited number of times.
NOTE The backup/restore master KEK must be managed in clear components, for split key entry, or backed up with redundancy separately, either to disk or smart cards. The redundancy is a defense against one of the master key sets being physically damaged or one of the custodians being unable or unwilling to participate in the restore operation. It is normal in any KEK hierarchy for the highest-level keys to be managed by a semi-manual process under the control of highly trusted personnel. These keys are critical to the restore operation, and their loss would make restore operations impossible.
Key Replication
Key replication is normally done for one of two reasons:
>Fault-tolerant redundancy
>Load balancing
NOTE The normal key backup with a restore per replication is all that is required to do this job. There is no special key replication procedure. The backup/restore key will need to be present in all devices where the keyset will be replicated. For root-level keys, a semi-manual procedure is required as in key restorations (clear components or Smart Card key injection).
Key Generation Variations
DSA and DH key generation is a two step process, where generation parameters produced in step one may be used repeatedly for key pair generation in step two. SafeNet PKCS#11 specifies that step one is outside the API while step two, generation of the actual key pair, is inside. This implementation allows step one to be done inside the library. The support is invoked by not supplying the required “parameters” values in the key templates. Under these circumstances a fully compliant PKCS#11 implementation would return CKR_TEMPLATE_INCOMPLETE.
Note that the DSA and DH parameters may be generated separately using the other extension CKM_xxx_PARAMETER_GEN making this extension unnecessary. The use of the alternative mechanism (CKM_xxx_PARAMETER_GEN) is recommended.
PKCS#11 Interpretations
>The handle for an object may change over the lifetime of the token or object. The handle is allocated to the object when it is read from the token.
>C_GetObjectSize reports the sum of the sizes of all the attributes combined for the object. This gives a good indication of the amount of memory committed to the object although there would be some storage overhead for persistent objects.
>Certain key wrapping restrictions are not observed. For example, wrapping a multi DES key with a single DES key is not prevented.
>All key sizes for secret key algorithms, as reported by C_GetMechanismInfo, are reported in bytes not bits.
Software-Only Version Specific
>Token serial numbers are all fixed as “0”.
>Token removal processing has not been supported since software tokens cannot really be removed in the normal sense. The token can actually be removed by deleting, or renaming the “token” directory found in the “slot” directory, but automatic detection has not been implemented.
>File system errors are typically reported as CKR_DEVICE_ERROR.
Operator Authentication
SafeNet ProtectToolkit-C provides several methods of operator authentication.
>The conventional C_Login allows the user PIN to be presented directly to the Token.
>The PIN Challenge feature allows the operator to authenticate to a token by requesting and responding to a random challenge. This is a form of bi-directional authentication protocol. The main advantage of this system over the normal PKCS#11 C_Login command is that the clear PIN value never leaves the proximity of the operator. It is particularly useful when the operator is physically remote from the HSM.
>Temporary PINs allow a process to pass user authentication to another process without having to hold a long-term sensitive data authentication (such as the PIN) or require the operator to authenticate repeatedly.
A CKO_HW_FEATURE object called CKH_VD_USER allows the application to obtain the random challenge for either the User Password or SO Password.
The Object has an attribute an application can read to generate and obtain a random challenge.
A new challenge value will be generated each time the attribute is read. A separate Challenge is held for each registered application. The same challenge can be used for User or SO authentication (see CT_GetAuthChallenge).
The calling application converts the challenge into a Response by using the following algorithm:
Response = SHA-256( challenge | PVC)
Where PVC = LEFT64BIT( SHA1(password | userTypeByte)
A host-side static library function CT_Gen_Auth_Response is provided in the SDK to assist developers using this scheme.
The CKH_VD_USER has an attribute an application can read to generate and obtain a Temporary PIN. Only one SO and one User Temporary PIN may exist at any one time in any single Token. Each read from this attribute will generate a new Temporary PIN (see CT_GetTmpPin).
Any Temporary PINs in a Token are automatically destroyed when the generating process logs off or is terminated, or the HSM has reset – whichever comes first.
Under Cryptoki, all authentication of users to the HSM is valid for the calling process only. Each application must authenticate separately. Once a process has authenticated, it is granted appropriate access to the token's services.
With SafeNet ProtectToolkit-C, if a process forks a new process then the new process must authenticate itself - it can not inherit the authentication of the parent.
The Temporary PIN feature is a method where a parent process can pass on its authentication to a child process without having to pass the sensitive PIN value.
The Response and Temporary PIN are passed to the HSM using the C_Login function. The Function will be extended such that unused bits in the userType parameter will be set to indicate that a Response value or Temporary PIN is being used instead of the normal password.
The following bits are added to the userType parameter of the C_Login function to specify the type of authentication required:
#define CKF_AUTH_RESPONSE 0x00000100
#define CKF_AUTH_TEMP_PIN 0x00001000
Operator Authentication Use Cases
Setup
User sets the User and SO PINs in the usual manner (using ctkmu or ctconf tools or other applications)
Programmatic Challenge Response Activation
1.Remote client initiates activation by sending a message to the server
2.Server Process registers itself to HSMs using C_Initialise
3.Server Process opens a session to a Token
4.Server Process obtains a Random challenge by calling CT_GetAuthChallenge
5.Server Process sends challenge to Remote client
6.Client computes the response value using CT_Gen_Auth_Response and returns it to the Server
7.Server Process supplies response as PIN value to the C_Login function using a special userType parameter value
Pass Authentication to a New Process
1.Server Primary Process authenticates using Programmatic Challenge Response Activation
2.Server Primary Process obtains a temporary pin by calling CT_GetTmpPin
3.For each spawned process, the Primary Process passes the temporary PIN to it using an appropriate interprocess communication method (or by forking).
4.New Process registers itself to HSMs using C_Initialise
5.New Process opens a session to the Required Token
6.New Process authenticates to Token with C_Login function and the temporary PIN using a special userType parameter value
Key Usage Limits
Each private key object on a token may have usage limits applied by the START_DATE, END_DATE, DESTROY_ON_COPY, USAGE_COUNT and USAGE_LIMIT plus the CKA_ADMIN_CERT attributes.
The START_DATE and END_DATE attributes enforce limits on the use of a key based on the date.
The USAGE_COUNT and USAGE_LIMIT attributes enforce limits on the use of a key based on the number of operations of that key. The USAGE_COUNT attribute increases with each use of the key until USAGE_LIMIT is reached. If USAGE_COUNT equals or is greater than USAGE_LIMIT, the key is locked and cannot be used.
In order to stop abuse of the USAGE_COUNT/USAGE_LIMIT controls, any Object with a non-empty CKA_USAGE_LIMIT attribute will be automatically deleted after a successful Copy operation.
Without this rule, a key and its attributes may be copied and therefore the number of operation remaining is automatically doubled.
The START_DATE, END_DATE, USAGE_COUNT and USAGE_LIMIT attributes can be supplied in the template when a key is created or imported. The C_SetAttributeValue command can be used to add these attributes to a key if the object is modifiable. But the C_SetAttributeValue command cannot be used to modify these attributes.
The CKM_SET_ATTRIBUTES ticket mechanism changes the START_DATE, END_DATE, USAGE_COUNT and USAGE_LIMIT attributes of a specified object when used with the CT_PresentTicket function.
Programmatic Use Cases for a Developer
Create Usage Limited Key Object
Developer uses C_GenerateKeyPair to create a new key pair. The private key template should include limitation attributes and specify CKA_MODIFIABLE=False.
Set Usage Limits of an Object Directly
1.Developer uses CT_SetLimitsAttributes() to set usage limitation attributes. Note the key must have CKA_MODIFIABLE=True.
2.Developer sets CKA_MODIFIABLE=False by calling CT_MakeObjectNonModifiable().
Update Usage Limits of an Object Indirectly
1.Developer calls CT_GetObjectDigest on the remote machine (Recommend use of SHA-256 algorithm).
2.Developer sends Object Digest to the Master machine.
3.Optional: on Master machine, Developer locates signing key and reads its CKA_SUBJECT_STR and CKA_USAGE_COUNT attributes. The CKA_SUBJECT_STR value can be used as the issuerRDN value to identify the signing key in the certificate. The CKA_USAGE_COUNT attribute can be used as the certificate serial number.
4.Developer uses CT_Create_Set_Attributes_Ticket_Info() to create a ticketInfo data block. The CT_SetCKDateStrFromTime() function can help to construct CKA_START_DATE and CKA_END_DATE values.
5.Developer uses the signing key to create a signature of the ticketInfo data block. For RSA signing key the CKM_SHA256_RSA_PKCS mechanism is recommended.
6.Developer uses CT_Create_Set_Attributes_Ticket() to construct the Ticket data block.
7.Developer arranges that the Ticket data block is sent to the remote server machine.
8.Developer uses CT_PresentTicket() with CKM_SET_ATTRIBUTES mechanism on remote machine to change limits attributes on target key.
