It’s token-specific which functions are supported by a token. The PKCS#11 API provides the function C_GetFunctionList() to obtain the function available with a specific token.

A mechanism describes a specific set of cryptographic operations. For example, CKM_AES_CBC refers to AES encryption with the CBC mode of operation. A mechanism may apply to one or more cryptographic functions. For example, the CKM_AES_CBC mechanism may be used to define encryption, decryption, wrapping and unwrapping functions whereas CKM_ECDSA_KEY_PAIR_GEN, the mechanism to generate keys for the elliptic curve DSA signatures, only supports the key (pair) generation function.

The list of mechanisms supported depends on the tokens and can be queried using the C_GetMechanismList() function. Each mechanism has token-specific attributes, such as the set of supported functions, minimal and maximal supported key sizes or a hardware support flag. These attributes are token-specific and can be queried with C_GetMechanismInfo(). Some mechanisms have parameters such as CKM_AES_CBC, which define the initialization vector (IV) required by the CBC mode of operation.

Figure 4 shows a list of mechanisms and their supported functions. An x in the column headed with E/D means the mechanism to the left of the x supports encryption and decryption. Similarly, S/V stands for signing and verification; SR/VR stands for message signing and verification together with message recovery; Dig stands for message digests; Gen stands for key or key pair generation; U/W stands for key wrapping and unwrapping; and Der stands for key derivation. This is an excerpt of a similar list in the PKCS#11 standard, which for version 2.2 lists about 300 possible mechanisms.


Objects and Keys
PKCS#11 objects belong to different orthogonal classes, depending on their life span, access restrictions and modifiability:

Session objects exist for the duration of a session, whereas token objects are associated with a token and not with any running code.
Private objects can be accessed only by the PKCS#11 user if he has logged into the token, whereas public objects can always be accessed by both user and SO.
Read-only objects can’t be modified, whereas read-write objects can.
In addition, each object has a set of attributes. Most notably the attribute class (CKA_CLASS), which determines which further attributes are associated with an object. Other typical attributes contain the value of an object or determine whether an object is a token object.

The PKCS#11 API provides a set of functions to manage objects such as C_CreateObjects(), C_CopyObject(), C_DestroyObject(), C_GetObjectSize(), C_GetAttributeValue(), C_SetAttributeValue() and C_FindObjects().

Note, token objects must be stored in a token-specific object store.

6 Pages