The wrapping key is exactly the same key that is used by CCA today, with one exception. Instead of using the base key itself (master key or key-encrypting key), ICSF will use a key that is derived from that base key. The derived key will have the control vector applied to it in the standard CCA manner, and then use the resulting key to wrap the new-format target key token. The reason for using a derived key is to ensure that no attacks against this wrapping scheme are possible using the existing CCA functions. For example, it was observed that an attack was possible by copying the wrapped key into an ECB CCA key token, if the wrapping key was used instead of a derivative of that key.

The key will be derived using a method defined in the NIST standard SP 800-108, "Recommendation for Key Derivation Using Pseudorandom Functions" (October, 2009). Derivation will use the method "KDF in Counter Mode" using pseudorandom function (PRF) HMAC-SHA256. This method provides sufficient strength for deriving keys for any algorithm used.

The HMAC algorithm is defined as follows:

HMAC(K, text) = H((K0 XOR opad ) || H((K0 XOR ipad) || text))

where opad is the constant 0x5C repeated to form a string the same length as K0, and ipad is the constant 0x36 repeated to form a string the same length as K0. If the key K is equal in length to the input block size of the hash function (512 bits for SHA-256), then K0 is set to the value of K. Otherwise, K0 is formed from K by hashing and/or padding.

The KDF specification calls for inputs optionally including two byte strings, Label and Context. The context will not be used. The label will contain information on the usage of this key, to distinguish it from other derivations that CCA may use in the future for different purposes. Since the security of the derivation process is rooted in the security of the derivation key and in the HMAC and KDF functions themselves, it is not necessary for this label string to be of any particular minimum size. The separation indicator byte of 0x00 specified in the NIST document will follow the label.

The label value will be defined so that it will be unique to derivation for this key wrapping process. This means that in any future designs which use the same KDF, ICSF must use a different value for the label. The label will be the 16 byte value consisting of the following ASCII characters:

ENHANCEDWRAP2010  (X‘454E4841 4E434544 57524150 32303130')

The parameters for the counter mode KDF defined in SP 800-108 are as follows:

• Fixed values:
  • h (length of output of PRF) = 256 bits
  • r (length of the counter, in bits) = 32 - the counter will be an unsigned 4-byte value
• Inputs:
  • KI (input key) will be the key we are deriving from
  • Label will be the value shown above (ASCII ENHANCEDWRAP2010)
  • Separator byte of 0x00 will follow the label value
  • Context will be a null string (no context is used)
  • L will be the length of the derived key to be produced, rounded up to the next multiple of 256
  • PRF (pseudorandom function) will be HMAC-SHA256

The KDF function will produce a pseudorandom bit string that is a multiple of 256 and will use as many bits of that as are required for the key to be produced. Bits for the key will be taken starting from the leftmost bit of the pseudorandom string, and any unused bits at the right will be discarded.