Cryptoki tips and reminders

In Cryptoki, there are several different types of operations which can be "active" in a session. An active operation is essentially one which takes more than one Cryptoki function call to perform. The types of active operations are object searching; encryption; decryption; message-digesting; signature with appendix; signature with recovery; verification with appendix; and verification with recovery.

A given session can have 0, 1, or 2 operations active at a time. It can only have 2 operations active simultaneously if the token supports this; moreover, those two operations must be one of the four following pairs of operations: digesting and encryption; decryption and digesting; signing and encryption; decryption and verification.

If an application attempts to initialize an operation (make it active), but this cannot be accomplished because of some other active operation(s), the application receives the error value CKR_OPERATION_ACTIVE. This error value can also be received if the application attempts to perform any of various operations which do not become "active", but which require cryptographic processing, such as using the token's random number generator, or generating/wrapping/unwrapping/deriving a key.

In general, different threads/processes of an application should not share sessions, unless they are extremely careful not to make function calls at the same time. Sharing sessions can easily lead to trouble.

In Cryptoki, every object (with the possible exception of RSA private keys) always possesses all possible attributes for an object of its type. This means, for example, that a Diffie-Hellman private key object always possesses a CKA_VALUE_BITS attribute, ''even if that attribute wasn't specified when the key was generated'' (in such a case, the proper value for the attribute is computed during the key generation process).

In general, a Cryptoki function which requires a template for an object needs the template to specify any atributes that are not specified elsewhere (explicitly or implicitly). If a template specifies a particular atttribute more than once, the function can return CKR_TEMPLATE_INVALID; or it can choose a particular value of the attribute from among those specified, and use that value. In any event, object attributes are single-valued.

Signing with recovery is a general alternative to ordinary digital signatures which is supported by certain mechanisms. Recall that for ordinary digital signatures, a signature of a message is computed as some function of the message and the signer's private key; this signature can then be used (together with the message and the signer's public key) as input to the verification process, which yields a simple "signature valid/signature invalid" decision.

Signing with recovery also creates a signature from a message and the signer's private key. However, to verify this signature, no message is required as input. Only the signature and the signer's public key are inputs to the verification process, and this process outputs either "signature invalid" or the original message (if the signature was valid).

Consider a simple example with the CKM_RSA_C_509 mechanism. Here, a message is a byte string which we will consider to be a number modulo n (the signer's RSA modulus). When this mechanism is used for ordinary digital signatures (signatures with appendix), a signature is computed by raising the message to the signer's private exponent modulo n. To verify this signature, a verifier raises the signature to the signer's public exponent modulo n, and accepts the signature as valus if and only if the result matches the original message.

If CKM_RSA_C_509 is used to create signatures with recovery, the signatures are produced in exactly the same fashion. For this particular mechanism, ''any'' number modulo ''n'' is a valid signature. To recover the message from a signature, the signature is raised to the signer's public exponent modulo ''n''.= Token profiles =

This appendix describes "profiles," i.e., sets of mechanisms, which a token should support for various common types of application. It is expected that these sets would be standardized as parts of the various applications, for instance within a list of requirements on the module that provides cryptographic services to the application (which may be a Cryptoki token in some cases). Thus, these profiles are intended for reference only at this point, and are not part of this standard.

The following table summarizes the mechanisms relevant to three common types of application:

Sections
Privacy-Enhanced Mail
Government authentication-only
Cellular Digital Packet Data

	Application
Mechanism	Privacy-Enhanced Mail	Government Authentication-only	Cellular Digital Packet Data
CKM_RSA_PKCS_KEY_PAIR_GEN	X
CKM_RSA_PKCS	X
CKM_RSA_9796
CKM_RSA_X_509
CKM_DSA_KEY_PAIR_GEN		X
CKM_DSA		X
CKM_DH_PKCS_KEY_PAIR_GEN			X
CKM_DH_PKCS_DERIVE			X
CKM_RC2_KEY_GEN
CKM_RC2_ECB
CKM_RC2_CBC
CKM_RC2_MAC
CKM_RC4_KEY_GEN			X
CKM_RC4			X
CKM_DES_KEY_GEN	X
CKM_DES_ECB	X
CKM_DES_CBC	X
CKM_DES_MAC
CKM_DES2_KEY_GEN	X
CKM_DES3_KEY_GEN
CKM_DES3_ECB	X
CKM_DES3_CBC
CKM_DES3_MAC
CKM_MD2	X
CKM_MD5	X
CKM_SHA_1		X
CKM_SHA_1_DERIVE

Cryptoki tips and reminders

Sections

Detailed Description