Cryptographic Token Interface Standard

PKCS#11

KEA key derivation

The KEA key derivation mechanism, denoted CKM_KEA_DERIVE, is a mechanism for key derivation based on KEA, the Key Exchange Algorithm, as defined by NIST's "SKIPJACK and KEA Algorithm Specification Version 2.0", 29 May 1998.

It has a parameter, a CK_KEA_DERIVE_PARAMS structure.

This mechanism derives a secret value, and truncates the result according to the CKA_KEY_TYPE attribute of the template and, if it has one and the key type supports it, the CKA_VALUE_LEN attribute of the template. (The truncation removes bytes from the leading end of the secret value.) The mechanism contributes the result as the CKA_VALUE attribute of the new key; other attributes required by the key type must be specified in the template.

As defined in the Specification, KEA can be used in two different operational modes: full mode and e-mail mode. Full mode is a two-phase key derivation sequence that requires real-time parameter exchange between two parties. E-mail mode is a one-phase key derivation sequence that does not require real-time parameter exchange. By convention, e-mail mode is designated by use of a fixed value of one (1) for the KEA parameter Rb (pRandomB).

The operation of this mechanism depends on two of the values in the supplied CK_KEA_DERIVE_PARAMS structure, as detailed in the table below. Note that, in all cases, the data buffers pointed to by the parameter structure fields pRandomA and pRandomB must be allocated by the caller prior to invoking C_DeriveKey. Also, the values pointed to by pRandomA and pRandomB are represented as Cryptoki "Big integer" data (i.e., a sequence of bytes, most-significant byte first). 




 Table 68, KEA Parameter Values and Operations   

Value of boolean isSender

 

Value of big integer pRandomB

 

Token Action(after checking parameter and template values)

   



TRUE

 

0

 		Compute KEA Ra value, store it in pRandomA, return CKR_OK. No derived key object is created.   



TRUE

 

1

 		Compute KEA Ra value, store it in pRandomA, derive key value using e-mail mode, create key object, return CKR_OK.   



TRUE

 

>1

 		Compute KEA Ra value, store it in pRandomA, derive key value using full mode, create key object, return CKR_OK.   



FALSE

 

0

 		Compute KEA Rb value, store it in pRandomB, return CKR_OK. No derived key object is created.   



FALSE

 

1

 		Derive key value using e-mail mode, create key object, return CKR_OK.    



FALSE

 

>1

 		Derive key value using full mode, create key object, return CKR_OK.   

 



Note that the parameter value pRandomB ==0 is a flag that the KEA mechanism is being invoked to compute the party's public random value (Ra or Rb, for sender or recipient, respectively), not to derive a key. In these cases, any object template supplied as the C_DeriveKey pTemplate argument should be ignored.


The derived key inherits the values of the CKA_SENSITIVE, CKA_ALWAYS_SENSITIVE, CKA_EXTRACTABLE, and CKA_NEVER_EXTRACTABLE attributes from the base key. The values of the CKA_SENSITIVE and CKA_EXTRACTABLE attributes may be overridden in the template for the derived key, however. Of course, if the base key has the CKA_ALWAYS_SENSITIVE attribute set to TRUE, then the template may not specify that the derived key should have the CKA_SENSITIVE attribute set to FALSE; similarly, if the base key has the CKA_NEVER_EXTRACTABLE attribute set to TRUE, then the template may not specify that the derived key should have the CKA_EXTRACTABLE attribute set to TRUE.


For this mechanism, the ulMinKeySize and ulMaxKeySize  fields of the CK_MECHANISM_INFO structure specify the supported range of KEA prime sizes, in bits.


 
 



RSA Security Inc. Public-Key Cryptography Standards - 
PKCS#11 - v210