Movatterモバイル変換

Network Working Group                                          J. SchaadRequest for Comments: 3537                       Soaring Hawk ConsultingCategory: Standards Track                                     R. Housley                                                          Vigil Security                                                                May 2003Wrapping a Hashed Message Authentication Code (HMAC) keywith a Triple-Data Encryption Standard (DES) Keyor an Advanced Encryption Standard (AES) KeyStatus 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.Schaad & Housley            Standards Track                     [Page 1]

RFC 3537                     HMAC Key Wrap                      May 2003   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 inBCP 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.Schaad & Housley            Standards Track                     [Page 2]

RFC 3537                     HMAC Key Wrap                      May 2003   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.Schaad & Housley            Standards Track                     [Page 3]

RFC 3537                     HMAC Key Wrap                      May 2003   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 500b2cc1Schaad & Housley            Standards Track                     [Page 4]

RFC 3537                     HMAC Key Wrap                      May 2003   TEMP3        :  c12c0b50 00bd4656                :  b145a4df 9c961266                :  4b865c47 96b018a6                :  6b8332f4 10827a15                :  756bd5e0 798c0d05   Wrapped Key  :  0f1d715d 75a0aaf6                :  6f02e371 c08b79e2                :  a1253dc4 3040136b                :  dc161118 601f2863                :  e2929b3b dd17697c4. 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.Schaad & Housley            Standards Track                     [Page 5]

RFC 3537                     HMAC Key Wrap                      May 20034.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 38050d8cSchaad & Housley            Standards Track                     [Page 6]

RFC 3537                     HMAC Key Wrap                      May 2003   Wrapped Key  :  9fa0c146 5291ea6d                :  b55360c6 cb95123c                :  d47b38cc e84dd804                :  fbcec5e3 75c3cb135. 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. References6.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.Schaad & Housley            Standards Track                     [Page 7]

RFC 3537                     HMAC Key Wrap                      May 2003   [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.comSchaad & Housley            Standards Track                     [Page 8]

RFC 3537                     HMAC Key Wrap                      May 20038. 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.Schaad & Housley            Standards Track                     [Page 9]