HMAC Key Wrap: Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key
How to lock an HMAC key of any length inside a Triple-DES or AES key so it can be stored or sent safely.
Schaad, J. and R. Housley, "Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key", RFC 3537, DOI 10.17487/RFC3537, May 2003, <https://www.rfc-editor.org/info/rfc3537>.
@misc{rfc3537,
series = {Request for Comments},
number = 3537,
howpublished = {RFC 3537},
publisher = {RFC Editor},
doi = {10.17487/RFC3537},
url = {https://www.rfc-editor.org/info/rfc3537},
author = {J. Schaad and R. Housley},
title = {{Wrapping a Hashed Message Authentication Code (HMAC) key with a Triple-Data Encryption Standard (DES) Key or an Advanced Encryption Standard (AES) Key}},
pagetotal = 9,
year = 2003,
month = may,
} RFC text
Contents
Network Working Group J. Schaad
Request for Comments: 3537 Soaring Hawk Consulting
Category: Standards Track R. Housley
Vigil Security
May 2003
Wrapping a Hashed Message Authentication Code (HMAC) key
with a Triple-Data Encryption Standard (DES) Key
or an Advanced Encryption Standard (AES) Key
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document defines two methods for wrapping an HMAC (Hashed
Message Authentication Code) key. The first method defined uses a
Triple DES (Data Encryption Standard) key to encrypt the HMAC key.
The second method defined uses an AES (Advanced Encryption Standard)
key to encrypt the HMAC key. One place that such an algorithm is
used is for the Authenticated Data type in CMS (Cryptographic Message
Syntax).
1. Introduction
Standard methods exist for encrypting a Triple-DES (3DES) content-
encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES-
WRAP], and for encrypting an AES CEK with an AES KEK [AES-WRAP].
Triple-DES key wrap imposes parity restrictions, and in both
instances there are restrictions on the size of the key being wrapped
that make the encryption of HMAC [HMAC] keying material difficult.
This document specifies a mechanism for the encryption of an HMAC key
of arbitrary length by a 3DES KEK or an AES KEK.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[STDWORDS].
2. HMAC Key Guidelines
[HMAC] suggests that the key be at least as long as the output (L) of
the hash function being used. When keys longer than the block size
of the hash algorithm are used, they are hashed and the resulting
hash value is used. Using keys much longer than L provides no
security benefit, unless the random function used to create the key
has low entropy output.
3. HMAC Key Wrapping and Unwrapping with Triple-DES
This section specifies the algorithms for wrapping and unwrapping an
HMAC key with a 3DES KEK [3DES].
The 3DES wrapping of HMAC keys is based on the algorithm defined in
Section 3 of [3DES-WRAP]. The major differences are due to the fact
that an HMAC key is of variable length and the HMAC key has no
particular parity.
In the algorithm description, "a || b" is used to represent 'a'
concatenated with 'b'.
3.1 Wrapping an HMAC Key with a Triple-DES Key-Encryption Key
This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm
is:
1. Let the HMAC key be called KEY, and let the length of KEY in
octets be called LENGTH. LENGTH is a single octet.
2. Let LKEY = LENGTH || KEY.
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple
of 8, the PAD has a length of zero. If the length of LKEY is not
a multiple of 8, then PAD contains the fewest number of random
octets to make the length of LKEYPAD a multiple of 8.
4. Compute an 8 octet key checksum value on LKEYPAD as described in
Section 2 of [3DES-WRAP], call the result ICV.
5. Let LKEYPADICV = LKEYPAD || ICV.
6. Generate 8 octets at random, call the result IV.
7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK. Use the
random value generated in the previous step as the initialization
vector (IV). Call the ciphertext TEMP1.
8. Let TEMP2 = IV || TEMP1.
9. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP3.
10. Encrypt TEMP3 in CBC mode using the 3DES KEK. Use an
initialization vector (IV) of 0x4adda22c79e82105.
Note: 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).
3.2 Unwrapping an HMAC Key with a Triple-DES Key-Encryption Key
This algorithm decrypts an HMAC key using a 3DES KEK. The algorithm
is:
1. If the wrapped key is not a multiple of 8 octets, then error.
2. Decrypt the wrapped key in CBC mode using the 3DES KEK. Use an
initialization vector (IV) of 0x4adda22c79e82105. Call the
output TEMP3.
3. Reverse the order of the octets in TEMP3. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP2.
4. Decompose the TEMP2 into IV and TEMP1. IV is the most
significant (first) 8 octets, and TEMP1 is composed of the
remaining octets.
5. Decrypt TEMP1 in CBC mode using the 3DES KEK. Use the IV value
from the previous step as the initialization vector. Call the
plaintext LKEYPADICV.
6. Decompose the LKEYPADICV into LKEYPAD, and ICV. ICV is the least
significant (last) 8 octets. LKEYPAD is composed of the
remaining octets.
7. Compute an 8 octet key checksum value on LKEYPAD as described in
Section 2 of [3DES-WRAP]. If the computed key checksum value
does not match the decrypted key checksum value, ICV, then error.
8. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the
most significant (first) octet. KEY is the following LENGTH of
octets. PAD is the remaining octets, if any.
9. If the length of PAD is more than 7 octets, then error.
10. Use KEY as an HMAC key.
3.3 HMAC Key Wrap with Triple-DES Algorithm Identifier
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
protocols employ algorithm identifiers to name cryptographic
algorithms. To support these protocols, the HMAC Key Wrap with
Triple-DES algorithm has been assigned the following algorithm
identifier:
id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 11 }
The AlgorithmIdentifier parameter field MUST be NULL.
3.4 HMAC Key Wrap with Triple-DES Test Vector
KEK : 5840df6e 29b02af1
: ab493b70 5bf16ea1
: ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340
: bed12207 80894115
: 5068f738
IV : 050d8c79 e0d56b75
PAD : 38be62
ICV : 1f363a31 cdaa9037
LKEYPADICV : 14c37b7e 64925843
: 40bed122 07808941
: 155068f7 38be62fe
: 1f363a31 cdaa9037
TEMP1 : 157a8210 f432836b
: a618b096 475c864b
: 6612969c dfa445b1
: 5646bd00 500b2cc1
TEMP3 : c12c0b50 00bd4656
: b145a4df 9c961266
: 4b865c47 96b018a6
: 6b8332f4 10827a15
: 756bd5e0 798c0d05
Wrapped Key : 0f1d715d 75a0aaf6
: 6f02e371 c08b79e2
: a1253dc4 3040136b
: dc161118 601f2863
: e2929b3b dd17697c
4. HMAC Key Wrapping and Unwrapping with AES
This section specifies the algorithms for wrapping and unwrapping an
HMAC key with an AES KEK [AES-WRAP].
The AES wrapping of HMAC keys is based on the algorithm defined in
[AES-WRAP]. The major difference is inclusion of padding due to the
fact that the length of an HMAC key may not be a multiple of 64 bits.
In the algorithm description, "a || b" is used to represent 'a'
concatenated with 'b'.
4.1 Wrapping an HMAC Key with an AES Key-Encryption Key
This algorithm encrypts an HMAC key with an AES KEK. The algorithm
is:
1. Let the HMAC key be called KEY, and let the length of KEY in
octets be called LENGTH. LENGTH is a single octet.
2. Let LKEY = LENGTH || KEY.
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple
of 8, the PAD has a length of zero. If the length of LKEY is not
a multiple of 8, then PAD contains the fewest number of random
octets to make the length of LKEYPAD a multiple of 8.
4. Encrypt LKEYPAD using the AES key wrap algorithm specified in
section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption
key. The result is 8 octets longer than LKEYPAD.
4.2 Unwrapping an HMAC Key with an AES Key
The AES key unwrap algorithm decrypts an HMAC key using an AES KEK.
The AES key unwrap algorithm is:
1. If the wrapped key is not a multiple of 8 octets, then error.
2. Decrypt the wrapped key using the AES key unwrap algorithm
specified in section 2.2.2 of [AES-WRAP], using the AES KEK as
the decryption key. If the unwrap algorithm internal integrity
check fails, then error, otherwise call the result LKEYPAD.
3. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the
most significant (first) octet. KEY is the following LENGTH of
octets. PAD is the remaining octets, if any.
4. If the length of PAD is more than 7 octets, then error.
5. Use KEY as an HMAC key.
4.3 HMAC Key Wrap with AES Algorithm Identifier
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these
protocols employ algorithm identifiers to name cryptographic
algorithms. To support these protocols, the HMAC Key Wrap with AES
algorithm has been assigned the following algorithm identifier:
id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 12 }
The AlgorithmIdentifier parameter field MUST be NULL.
4.4 HMAC Key Wrap with AES Test Vector
KEK : 5840df6e 29b02af1
: ab493b70 5bf16ea1
: ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340
: bed12207 80894115
: 5068f738
PAD : 050d8c
LKEYPAD : 14c37b7e 64925843
: 40bed122 07808941
: 155068f7 38050d8c
Wrapped Key : 9fa0c146 5291ea6d
: b55360c6 cb95123c
: d47b38cc e84dd804
: fbcec5e3 75c3cb13
5. Security Considerations
Implementations must protect the key-encryption key (KEK).
Compromise of the KEK may result in the disclosure of all HMAC keys
that have been wrapped with the KEK, which may lead to loss of data
integrity protection.
The use of these key wrap functions provide confidentiality and data
integrity, but they do not necessarily provide data origination
authentication. Anyone possessing the KEK can create a message that
passes the integrity check. If data origination authentication is
also desired, then the KEK distribution mechanism must provide data
origin authentication of the KEK. Alternatively, a digital signature
may be used.
Implementations must randomly generate initialization vectors (IVs)
and padding. The generation of quality random numbers is difficult.
RFC 1750 [RANDOM] offers important guidance in this area, and
Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
The key wrap algorithms specified in this document have been reviewed
for use with Triple-DES and AES, and have not been reviewed for use
with other encryption algorithms.
6. References
6.1 Normative References
[3DES] American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation.
1998.
[3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217,
December 2001.
[AES] National Institute of Standards and Technology. FIPS Pub
197: Advanced Encryption Standard (AES). 26 November
2001.
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, September 2002.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2 Informative References
[DSS] National Institute of Standards and Technology. FIPS Pub
186: Digital Signature Standard. 19 May 1994.
[RANDOM] Eastlake 3rd, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC 1750,
December 1994.
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988.
[X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988.
7. Authors' Addresses
Jim Schaad
Soaring Hawk Consulting
EMail: jimsch@exmsft.com
Russell Housley
Vigil Security
918 Spring Knoll Drive
Herndon, VA 20170
USA
EMail: housley@vigilsec.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1The Problem: Wrapping a Key of Any Length
Key wrapping means encrypting one cryptographic key with another. The key doing the encrypting is the key-encryption key (KEK). Standard methods already exist for wrapping a Triple-DES (3DES) content-encryption key with a 3DES KEK (RFC 3217) and an AES content-encryption key with an AES KEK (RFC 3394).
Neither fits an HMAC key well. Triple-DES key wrap imposes parity restrictions, and both methods restrict the size of the key being wrapped. An HMAC key has no particular parity and can have a variable length.
RFC 3537 therefore specifies a way to encrypt an HMAC key of arbitrary length with either a 3DES KEK or an AES KEK. It uses the requirement words MUST, SHOULD and so on as defined in RFC 2119.
There are already special boxes for locking up some kinds of keys, but they only fit keys of certain sizes. This memo makes a box that can fit a secret of any length.
§2HMAC Key Guidelines
The memo starts with a short reminder from the HMAC specification (RFC 2104) about key size. The key should be at least as long as the output (called L) of the hash function in use.
When a key is longer than the block size of the hash algorithm, it is hashed first and the resulting hash value is used. Using keys much longer than L gives no security benefit, unless the random function used to create the key has low entropy output.
This is why the wrapping has to cope with many key lengths: HMAC keys are not a fixed size.
A secret key should be about as long as the lock's answer, and making it much longer does not help. But people still use lots of different lengths, so the box has to fit them all.
§3Wrapping with Triple-DES
The 3DES method is based on the algorithm in Section 3 of RFC 3217, changed because an HMAC key is variable length and has no parity. The steps for wrapping are:
- Call the HMAC key
KEYand its length in octetsLENGTH, which is a single octet. FormLKEY = LENGTH || KEY. - Add
PAD, the fewest random octets needed to make the total a multiple of 8 octets (zero if it already is). The result isLKEYPAD. - Compute an 8 octet key checksum on
LKEYPADas described in RFC 3217, call itICV, and append it to getLKEYPADICV. - Generate 8 random octets as
IVand encryptLKEYPADICVin CBC mode with the 3DES KEK. Call the ciphertextTEMP1. - Form
TEMP2 = IV || TEMP1, reverse the order of its octets to getTEMP3, and encryptTEMP3in CBC mode with the KEK using the fixed initialization vector0x4adda22c79e82105.
Unwrapping runs the steps in reverse. It must reject a wrapped key that is not a multiple of 8 octets, a checksum that does not match, and a PAD longer than 7 octets. When the same HMAC key is wrapped under different 3DES KEKs, a fresh IV must be generated each time.
You write down how long the secret is, add some filler so it fits neatly, add a check number, then scramble it twice, flipping it backwards in between. To open it, you do everything backwards and check the numbers match.
§4Wrapping with AES
The AES method reuses the AES key wrap algorithm of RFC 3394 and differs only by adding padding, since an HMAC key length may not be a multiple of 64 bits. Wrapping builds LKEYPAD exactly as in the 3DES case (a length octet, the key, then 0 to 7 random pad octets) and then encrypts it with the AES key wrap algorithm using the AES KEK. The result is 8 octets longer than LKEYPAD.
Unwrapping rejects a wrapped key that is not a multiple of 8 octets, runs the AES key unwrap algorithm and fails if its internal integrity check fails, then splits out LENGTH, KEY and PAD. A PAD of more than 7 octets is an error. Otherwise KEY is used as the HMAC key.
This is simpler than the 3DES method because the AES algorithm already has its own integrity check, so no separate checksum or double encryption is needed.
With AES the strong box already has a built-in seal that tells you if it was tampered with. You only need to add the length note and some filler before you lock it.
| Method | Built on | Integrity check | OID final arc |
|---|---|---|---|
| Triple-DES | RFC 3217, CBC twice with a reversal | 8 octet ICV checksum | 11 |
| AES | RFC 3394 AES key wrap | Internal to AES unwrap | 12 |
§5Algorithm Identifiers
Protocols that use ASN.1 name their cryptographic algorithms with object identifiers. The memo assigns two, one for each method. In both cases the AlgorithmIdentifier parameter field MUST be NULL.
id-alg-HMACwith3DESwrapis{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 11 }.id-alg-HMACwithAESwrapis{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 12 }.
The abstract names one place such an algorithm is used: the Authenticated Data type in the Cryptographic Message Syntax (CMS).
Each kind of box gets its own name tag so the two sides of a conversation can say which box they used. The tags are a long number made of small parts, and the last part tells the boxes apart.
§6Test Vectors
The RFC gives one worked example for each method so implementers can check their code. Both use the same KEK, 5840df6e 29b02af1 ab493b70 5bf16ea1 ae8338f4 dcc176a8, and the same HMAC key, c37b7e64 92584340 bed12207 80894115 5068f738.
For 3DES, the example lists the random IV (050d8c79 e0d56b75), the PAD (38be62), the ICV and every intermediate value up to the final wrapped key. For AES, the pad is 050d8c and the wrapped key is shown in full. The values are given in full in the RFC.
The memo includes a worked example with all the numbers filled in, like an answer key, so people building their own can check they got the same result.
§7Security Considerations
Implementations must protect the KEK. If it is compromised, every HMAC key wrapped with it may be disclosed, which may lead to loss of data integrity protection.
Wrapping provides confidentiality and data integrity but not necessarily data origination authentication, because anyone holding the KEK can create a message that passes the integrity check. If origin authentication is wanted, the KEK distribution mechanism must provide it, or a digital signature may be used.
Implementations must generate IVs and padding randomly, and the RFC warns that good random numbers are difficult to produce, pointing to RFC 1750. Finally, the algorithms have been reviewed only for use with Triple-DES and AES, not other encryption algorithms.
If someone steals the key that makes the strong box, they can open every box made with it, so guard it well. Also, the box shows nothing was tampered with, but not who packed it.