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

The conventional C_Login allows the user PIN to be presented directly to the Token.

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.

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.