Processing configuration files

Additional configuration options or duplicated options (for example, specifying a strength multiple times in the policy) are invalid configurations. A valid strength configuration file is required by openCryptoki. Otherwise, openCryptoki returns CKR_GENERAL_ERROR while processing the C_Initialize() function and produces an error message in syslog. If a valid policy configuration file is found, openCryptoki enforces the defined policy. If no policy configuration is found, openCryptoki does not restrict any key or operation, but still computes the strength for all keys.

Processing of EP11 tokens: An EP11 token also checks the signing and verification key used for the mechanism CKM_IBM_ATTRIBUTEBOUND_WRAP (that is, attribute-bound wrapping and unwrapping).

Processing of ICSF tokens: An ICSF token processing the CKM_TLS_KEY_AND_MAC_DERIVE mechanism might generate up to four keys. All keys are checked for proper strength.

Providing information

For an existing policy configuration, the output of function C_GetMechanismList() only returns mechanisms that do apply to the defined policy. Consequently, function C_GetMechanismInfo() returns information only for allowed mechanisms and issues a CKR_MECHANISM_INVALID message for mechanisms that are not allowed by the policy. The minimum and maximum key size of a mechanism returned by C_GetMechanismInfo() is also adjusted to key sizes allowed by the policy.

Checking operations

openCryptoki performs checks to the initialization functions of the various encrypt, decrypt, digest, sign, and verify functions. Furthermore, it also checks wrap, unwrap, derive and key(-pair) generation functions. Checking depends on the attempted operation. If the policy forbids an operation either because the mechanism is not allowed, or because one of the involved keys is too weak, or because the input or output is too small, then CKR_FUNCTION_FAILED is returned and the function aborts. Furthermore, the ulDeviceError field of the session info is set to CKR_POLICY_VIOLATION to aid in debugging the problem. Also, various trace messages identify the policy violation.

Key loading

Keys are loaded either implicitly when the token initializes or when the user logs into the token. Furthermore, keys are loaded during C_FindObjects(). In these cases, only sufficiently strong keys can be loaded. The strength of the key is determined based on the attributes in the key object.

Key creation

During key creation with C_CreateObject(), the user provides a template for the key including the key type and the attributes used to derive the strength. This is then used to classify the key and, if the classification is too low or the elliptic curve is not supported, key creation is aborted.

Key or key pair generation

During key or key pair generation, the strength of the key or key pair to be generated is computed. If it is too small or the elliptic curve is not supported, generation is aborted. Furthermore, the key or key pair generation mechanism must be allowed by the profile.

Key derivation and unwrapping

During key derivation and unwrapping, both the input key and the output key(s) are checked for appropriate strength and allowed elliptic curve. If either check fails, derivation or unwrapping is aborted. Furthermore, the derivation and unwrapping mechanisms must be allowed.

Encryption and decryption

Keys are checked only during the initialization functions of these operations. For updates and finalization no further checks are needed.

Signing and verifying

For signatures, the key must be allowed, and the size of the signature must be at least as big as the signature property of the active strength configuration. If either the key is not allowed or the signature is not large enough, the operation is aborted.

Digests

The digest output length in bits is compared to the digest property of the active strength configuration. If it is smaller, the operation is aborted.