Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key
Extracted elements (17)
Existing 3DES and AES key wrap algorithms impose parity restrictions (for 3DES) and fixed key-size restrictions that make them unsuitable for wrapping variable-length HMAC keys. This document introduces a padding and length-prefix scheme to handle arbitrary HMAC key lengths, deviating from the standard CEK wrap approach.
The 3DES wrapping algorithm uses a double-CBC-encrypt with an octet-reversal step between passes (derived from RFC 3217 section 3), whereas the AES wrapping algorithm directly uses the AES Key Wrap (RFC 3394) with only a length-prefix and padding addition. The difference arises because RFC 3394 provides its own integrity check, eliminating the need for the ICV and reversal steps.
The key wrap algorithms defined in this document have been reviewed only for use with Triple-DES and AES as the KEK algorithm; they have not been reviewed for use with other encryption algorithms.
If the wrapped key input to either the 3DES or AES unwrap algorithm is not a multiple of 8 octets, the implementation must signal an error.
The AlgorithmIdentifier parameter field for both id-alg-HMACwith3DESwrap and id-alg-HMACwithAESwrap MUST be NULL.
When the same HMAC key is wrapped in different 3DES KEKs, a fresh initialization vector (IV) MUST be generated for each invocation of the HMAC key wrap algorithm (step 6 of the wrap procedure).
When unwrapping with 3DES, if the PAD recovered after extracting LENGTH and KEY is more than 7 octets, the implementation MUST treat this as an error.
When unwrapping with AES, if the PAD recovered after extracting LENGTH and KEY is more than 7 octets, the implementation MUST treat this as an error.
HMAC key guidelines recommend the key be at least as long as the hash output L. Keys longer than the hash block size are hashed before use; keys much longer than L provide no security benefit unless the key generation PRNG has low entropy.
HMAC key wrapping with 3DES uses a 10-step algorithm: the key is prefixed with its 1-octet length, padded to a multiple of 8 octets with random bytes, appended with an 8-octet ICV (key checksum), then double-encrypted in CBC mode with a random IV and a fixed IV of 0x4adda22c79e82105, with an octet-reversal step between the two encryptions.
HMAC key wrapping with AES uses a simpler algorithm: the key is prefixed with its 1-octet length, padded to a multiple of 8 octets with random bytes, then encrypted using the AES Key Wrap algorithm (RFC 3394 section 2.2.1). The result is 8 octets longer than the padded input.
The document assigns OID id-alg-HMACwith3DESwrap (1.2.840.113549.1.9.16.3.11) for the HMAC Key Wrap with Triple-DES algorithm, registered under the S/MIME alg arc.
The document assigns OID id-alg-HMACwithAESwrap (1.2.840.113549.1.9.16.3.12) for the HMAC Key Wrap with AES algorithm, registered under the S/MIME alg arc.
Implementations must protect the KEK; compromise of the KEK exposes all HMAC keys wrapped with it, leading to loss of data integrity protection. The key wrap functions provide confidentiality and integrity but not data origination authentication — any KEK holder can forge a wrapped key that passes the integrity check.
Implementations must randomly generate IVs and padding using a quality random number generator. RFC 1750 and FIPS 186 Appendix 3 are cited as guidance for generating cryptographically strong random values.
The LKEYPAD structure used in AES wrapping is: LENGTH (1 octet) || KEY (LENGTH octets) || PAD (0–7 random octets). AES wrapping (RFC 3394) adds an 8-octet integrity check value, so the wrapped output length is len(LKEYPAD) + 8.
The LKEYPADICV structure used in 3DES wrapping is: LENGTH (1 octet) || KEY (LENGTH octets) || PAD (0–7 random octets to make total a multiple of 8) || ICV (8 octets). The final wrapped output is the double-CBC-encrypted form of this structure prepended with the reversed IV.