< draft-housley-aes-key-wrap-with-pad-00.txt   draft-housley-aes-key-wrap-with-pad-01.txt >
INTERNET DRAFT R. Housley INTERNET DRAFT R. Housley
Intended Status: Informational Vigil Security Intended Status: Informational Vigil Security
M. Dworkin M. Dworkin
NIST NIST
Expires: 29 July 2009 29 January 2009 Expires: 23 August 2009 23 February 2009
Advanced Encryption Standard (AES) Key Wrap Algorithm with Padding Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm
<draft-housley-aes-key-wrap-with-pad-00.txt> <draft-housley-aes-key-wrap-with-pad-01.txt>
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
This document specifies a padding convention for use with the AES Key This document specifies a padding convention for use with the AES Key
Wrap algorithm specified in RFC 3394. This convention eliminates the Wrap algorithm specified in RFC 3394. This convention eliminates the
requirement that the key to be wrapped is a multiple of 64 bits, requirement that the length of the key to be wrapped is a multiple of
allowing a key of any practical length to be wrapped. 64 bits, allowing a key of any practical length to be wrapped.
1. Introduction 1. Introduction
Management of cryptographic keys often leads to situations where a Management of cryptographic keys often leads to situations where a
symmetric key is used to encrypt and integrity protect another key, symmetric key is used to encrypt and integrity protect another key,
which can be either a symmetric key or an asymmetric key. The which can be either a symmetric key or an asymmetric key. The
operation is often called key wrapping. operation is often called key wrapping.
This document specifies an extension the Advanced Encryption Standard This document specifies an extension of the Advanced Encryption
(AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this extension, Standard (AES) Key Wrap algorithm [AES-KW1,AES-KW2]. Without this
the input to the AES Key Wrap algorithm must be a multiple of 64 extension, the input to the AES Key Wrap algorithm, called the key
bits. data, must be a sequence of two or more 64-bit blocks.
The AES Key Wrap with Padding algorithm can be used to wrap a key of The AES Key Wrap with Padding algorithm can be used to wrap a key of
any practical size with an AES key. The AES key-encrypting key (KEK) any practical size with an AES key. The AES key-encryption key (KEK)
can be 128, 192, or 256 bits. The AES Key Wrap algorithm requires must be 128, 192, or 256 bits. The input key data may be as short as
the input to be at least two 64-bit blocks. This specification 9 octets, which will result in an output of two 64-bit blocks or 16
allows inputs as short as 9 octets, which will result in 16 output octets. Although the AES Key Wrap algorithm does not place a maximum
octets or two 64-bit blocks. Although the AES Key Wrap algorithm bound on the size of the key data that can be wrapped, this extension
does not place a maximum bound on the number of blocks that can be does so. The use of a 32-bit fixed field to carry the octet length
wrapped, this specification does so. The use of a 32-bit fixed field of the key data bounds the size of the input at 2^32 octets. Most
to carry the key length bounds the size of the input octet string at systems will have other factors that limit the practical size of key
2^32 octets. Most systems will have other factors that limit the data to much less than 2^32 octets.
practical size of key data to much less than 2^32 octets.
A message length indicator (MLI) is defined as an "Alternative A message length indicator (MLI) is defined as part of an
Initial Value" in keeping with the statement in 2.2.3.2 of [AES-KW1], "Alternative Initial Value" in keeping with the statement in 2.2.3.2
which says: of [AES-KW1], which says:
Also, if the key data is not just an AES key, it may not always be Also, if the key data is not just an AES key, it may not always be
a multiple of 64 bits. Alternative definitions of the initial a multiple of 64 bits. Alternative definitions of the initial
value can be used to address such problems. value can be used to address such problems.
2. Notation and Definitions 2. Notation and Definitions
The following notation is used in the algorithm descriptions: The following notation is used in the algorithm descriptions:
MSB(j, W) Return the most significant j bits of W MSB(j, W) Return the most significant j bits of W
LSB(j, W) Return the least significant j bits of W LSB(j, W) Return the least significant j bits of W
B1 | B2 Concatenate B1 and B2 B1 | B2 Concatenate B1 and B2
K The key-encryption key K The key-encryption key
m The number of octets in the key data m The number of octets in the key data
n The number of 64-bit key data blocks n The number of 64-bit blocks in the padded key data
Q[i] The ith plaintext octet in the key data Q[i] The ith plaintext octet in the key data
P[i] The ith plaintext 64-bit block in the padded key data P[i] The ith 64-bit plaintext block in the padded key data
C[i] The ith ciphertext data block C[i] The ith 64-bit ciphertext data block
A The 64-bit integrity check register A The 64-bit integrity check register
3. Alternative Initial Value 3. Alternative Initial Value
The Alternative Initial Value (AIV) required by this specification The Alternative Initial Value (AIV) required by this specification is
comprises a 32-bit constant concatenated to a 32-bit MLI. The a 32-bit constant concatenated to a 32-bit MLI. The constant is (in
constant is (in hexadecimal) A65959A6 and occupies the high-order hexadecimal) A65959A6 and occupies the high-order half of the AIV.
half of the AIV. Note that this differs from the high order 32 bits Note that this differs from the high order 32 bits of the default IV
of the default IV in [AES-KW1] Section 2.2.3.1, so there is no in [AES-KW1] Section 2.2.3.1, so there is no ambiguity between the
ambiguity between the two. The 32-bit MLI, which occupies the low- two. The 32-bit MLI, which occupies the low-order half of the AIV,
order half of the AIV, is a unsigned binary integer equal to the is an unsigned binary integer equal to the octet length of the
number of octets in the key data being wrapped. When the MLI is not plaintext key data, in network order, that is with the most
a multiple of 8, the key data is padded on the right with the least significant octet first. When the MLI is not a multiple of 8, the
number of octets sufficient to make a multiple 8. The value of each key data is padded on the right with the least number of octets
padding octet shall be 0 (eight binary zeros). sufficient to make a multiple of 8. The value of each padding octet
shall be 0 (eight binary zeros).
Notice that for a given number of 64-bit plaintext blocks, there are Notice that for a given number of 64-bit plaintext blocks, there are
only 8 values of MLI that can have that outcome. For example, the only eight values of MLI that can have that outcome. For example,
only MLI values that are valid with 4 plaintext blocks are 32 (with the only MLI values that are valid with four 64-bit plaintext blocks
no padding octets), 31 (with one padding octet), 30, 29, 28, 27, 26, are 32 (with no padding octets), 31 (with one padding octet), 30, 29,
and 25 (with seven padding octets). When the AES Key Unwrap yields n 28, 27, 26, and 25 (with seven padding octets). When the AES Key
64-bit blocks with an AIV, the eight valid values for the MLI are Unwrap yields n 64-bit blocks of key data with an AIV, the eight
8*n, (8*n)-1, ..., and (8*n)-7. Therefore, the integrity check for valid values for the MLI are 8*n, (8*n)-1, ..., and (8*n)-7.
the AIV requires the following steps: Therefore, the integrity check for the AIV requires the following
steps:
1) Check that MSB(32,A) = A65959A6. 1) Check that MSB(32,A) = A65959A6.
2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let 2) Check that 8*(n-1) < LSB(32,A) <= 8*n. If so, let
MLI = LSB(32,A). MLI = LSB(32,A).
3) Let b = (8*n)-MLI, and then check that the rightmost b octets of 3) Let b = (8*n)-MLI, and then check that the rightmost b octets of
the plaintext are zero. the plaintext are zero.
If all three checks pass, then the AIV is valid. If any of the If all three checks pass, then the AIV is valid. If any of the
checks fail, then the AIV is invalid and the AES Key Unwrap operation checks fail, then the AIV is invalid and the AES Key Unwrap operation
must return an error. must return an error.
4. Algorithms 4. Specification of the AES Key Wrap with Padding Algorithm
The specification of the key wrap algorithm requires the use of the The AES Key Wrap with Padding algorithm consists of a wrapping
AES codebook [AES] and provide a padding technique for use with the process and an unwrapping process, both based on the AES codebook
AES Key Wrap [AES-KW1,AES-KW2]. The next two sections describe the [AES]. It provides an extension to the AES Key Wrap algorithm
key wrap with padding algorithm and the key unwrap with padding [AES-KW1,AES-KW2] that eliminates the requirement that the length of
algorithm. the key to be wrapped is a multiple of 64 bits. The next two
sections specify the wrapping and unwrapping processes, called the
Extended Key Wrapping process and the Extended Key Unwrapping
process, respectively. These names distinguish these processes from
the ones specified in [AES-KW1,AES-KW2].
4.1. Key Wrap with Padding 4.1. Extended Key Wrapping Process
The inputs to the key wrapping process are the KEK and the plaintext The inputs to the extended key wrapping process are the KEK and the
to be wrapped. The plaintext consists of between 9 and 2^32 octets, plaintext to be wrapped. The plaintext consists of between 9 and
containing the key data being wrapped. The key wrapping process is 2^32 octets, containing the key data being wrapped. The key wrapping
described below. process is described below.
Inputs: Plaintext, m octets {Q1, Q2, ..., Qm}, and Inputs: Plaintext, m octets {Q1, Q2, ..., Qm}, and
Key, K (the KEK). Key, K (the KEK).
Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}. Outputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}.
1) Initialize variables 1) Append padding
If m is not a multiple of 8, pad the plaintext octet string on If m is not a multiple of 8, pad the plaintext octet string on
the right with octets {Qm+1, ..., Qr} of zeros, where r is the the right with octets {Qm+1, ..., Qr} of zeros, where r is the
smallest multiple of 8 that is greater than m. smallest multiple of 8 that is greater than m. If m is a
multiple of 8, then there is no padding, and r = m.
Set n = r/8, which is the same as CEILING(m/8). Set n = r/8, which is the same as CEILING(m/8).
For i = 1, ..., n For i = 1, ..., n
j = 8*(i-1) j = 8*(i-1)
P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] . P[i] = Q[j+1] | Q[j+2] | ... | Q[j+8] .
Set A = AIV, the Alternative Initial Value as defined in 2) Wrapping
Section 3.
2) Key wrapping
Use the AES Key Wrap algorithm with the AIV as defined in Apply the wrapping process specified in Section 2.2.1 of
Section 3, the padded plaintext {P1, ..., Pn}, and K (the KEK). [AES-KW2] to the padded plaintext {P1, ..., Pn} and K (the KEK),
The result is (n+1) 64-bit ciphertext blocks {C0, C1, ..., Cn}. with the AIV as defined in Section 3 above as the initial value.
The result is n+1 64-bit blocks {C0, C1, ..., Cn}.
4.2 Key Unwrap with Padding 4.2 Extended Key Unwrapping Process
The inputs to the key unwrap algorithm are the KEK and (n+1) 64-bit The inputs to the extended key unwrapping process are the KEK and n+1
ciphertext blocks consisting of previously wrapped key. The AES Key 64-bit ciphertext blocks consisting of a previously wrapped key. If
Unwrap returns n 64-bit plaintext blocks, which are then mapped to m the ciphertext is a validly wrapped key, then the (original)
octets of decrypted key data, as indicated by the MLI embedded in the unwrapping process returns n 64-bit plaintext blocks, which are then
AVI. mapped in this extension to m octets of decrypted key data, as
indicated by the MLI embedded in the AIV.
Inputs: Ciphertext, (n+1) 64-bit values {C0, C1, ..., Cn}, and Inputs: Ciphertext, (n+1) 64-bit blocks {C0, C1, ..., Cn}, and
Key, K (the KEK). Key, K (the KEK).
Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}. Outputs: Plaintext, m octets {Q1, Q2, ..., Qm}, or an error.
1) Key unwrapping 1) Key unwrapping
Use the AES Key Unrap algorithm with the AIV as defined in Apply Steps 1 and 2 of the unwrapping process specified in
Section 3, (n+1) 64-bit ciphertext blocks {C0, C1, ..., Cn}, and Section 2.2.2 of [AESKW2] to the n+1 64-bit ciphertext blocks,
K (the KEK). The result is the padded plaintext blocks {C0, C1, ..., Cn}, and the KEK, K. Define the padded plaintext
{P1, ..., Pn}; also the A value is also needed to validate the blocks, {P1, ..., Pn}, as specified in Step 3 of that process,
AIV and remove the padding. with A[0] as the A value. Note that checking "If A[0] is an
appropriate value" is slightly delayed to Step 2 below since the
padded plaintext is needed to perform this verification when the
AIV is used.
2) AIV validation 2) AIV verification
Perform the three checks described in Section 3. If any of the Perform the three checks described in Section 3 above on the
checks fail, then return an error. padded plaintext and the A value. If any of the checks fail,
then return an error.
3) Remove padding 3) Remove padding
Let m = the MLI value extracted from A. Let m = the MLI value extracted from A.
For i = 1, ... , n Let P = P1 | P2 | ... | Pn.
j = 8*(i-1)
Q[j+1] | Q[j+2] | ... | Q[j+8] = P[i] For i = 1, ... , m
Q[i] = LSB(8, MSB(8*i, P))
5. Algorithm Identifiers 5. Algorithm Identifiers
Some security protocols employ ASN.1 [X.690], and these protocols Some security protocols employ ASN.1 [X.690], and these protocols
employ algorithm identifiers to name cryptographic algorithms. To employ algorithm identifiers to name cryptographic algorithms. To
support these protocols, the AES Key Wrap with Padding algorithm has support these protocols, the AES Key Wrap with Padding algorithm has
been assigned the following algorithm identifiers, one for each AES been assigned the following algorithm identifiers, one for each AES
KEK size. The AES Key Wrap (without padding) algorithm identifiers KEK size. The AES Key Wrap (without padding) algorithm identifiers
are also included here for convenience. are also included here for convenience.
skipping to change at page 5, line 44 skipping to change at page 6, line 4
aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101) csor(3) us(840) organization(1) gov(101) csor(3)
nistAlgorithm(4) 1 } nistAlgorithm(4) 1 }
id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 } id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } id-aes128-wrap-pad OBJECT IDENTIFIER ::= { aes TBD }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 } id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } id-aes192-wrap-pad OBJECT IDENTIFIER ::= { aes TBD }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 } id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }
id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes TBD } id-aes256-wrap-pad OBJECT IDENTIFIER ::= { aes TBD }
In all cases, the AlgorithmIdentifier parameter field must be NULL. In all cases, the AlgorithmIdentifier parameter field must be absent.
6. Padded Key Wrap Example 6. Padded Key Wrap Example
The example in this section was generated using the index-based The example in this section was generated using the index-based
implementation of the AES Key Wrap algorithm along with the padding implementation of the AES Key Wrap algorithm along with the padding
approach specified in Section 4 of this document. The example wraps approach specified in Section 4 of this document. The example wraps
20 octets of Key Data with a 128-bit KEK. All values are shown in 20 octets of Key Data with a 192-bit KEK. All values are shown in
hexadecimal. hexadecimal.
KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8 KEK : 5840df6e29b02af1 ab493b705bf16ea1 ae8338f4dcc176a8
Key : c37b7e6492584340 bed1220780894115 5068f738 Key : c37b7e6492584340 bed1220780894115 5068f738
Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a Wrap : 138bdeaa9b8fa7fc 61f97742e72248ee 5ae6ae5360d1ae6a
: 5f54f373fa543b6a : 5f54f373fa543b6a
7. Security Considerations 7. Security Considerations
Implementations must protect the key-encryption key (KEK). Implementations must protect the key-encryption key (KEK).
Compromise of the KEK may result in the disclosure of all keys that Compromise of the KEK may result in the disclosure of all keys that
have been wrapped with the KEK, which may lead to the compromise of have been wrapped with the KEK, which may lead to the compromise of
all traffic protected with those wrapped key. all traffic protected with those wrapped keys.
If the KEK and wrapped key are associated with different If the KEK and wrapped key are associated with different
cryptographic algorithms, the effective security provided to data cryptographic algorithms, the effective security provided to data
protected with the wrapped key is determined by the weaker of the two protected with the wrapped key is determined by the weaker of the two
algorithms. If, for example, data is encrypted with 128-bit AES and algorithms. If, for example, data is encrypted with 128-bit AES and
that AES key is wrapped with a 256-bit AES key, then at most 128 bits that AES key is wrapped with a 256-bit AES key, then at most 128 bits
of protection is provided to the data. If, for another example, a of protection is provided to the data. If, for another example, a
128-bit AES key is used to wrap a 4096-bit RSA private key, then at 128-bit AES key is used to wrap a 4096-bit RSA private key, then at
most 128 bits of protection is provided to any data that depends on most 128 bits of protection is provided to any data that depends on
that private key. Thus, implementers must ensure that key-encryption that private key. Thus, implementers must ensure that key-encryption
algorithms are as strong or stronger than other cryptographic algorithms are as strong or stronger than other cryptographic
algorithms employed in an overall system. algorithms employed in an overall system.
The use of different constants in the A value ensures that a padded The AES Key Wrap and the AES Key Wrap with Padding algorithms use
key will no be confused with an unpadded key. In addition, the two different constants in the initial value. The use of different
algorithms provide roughly the same amount of integrity protection. values ensures that the recipient of padded key data cannot
successfully unwrap it as unpadded key data, or vice versa. This
remains true when the key data is wrapped using the AES Key Wrap with
Padding algorithm but no padding is needed.
The AES Key Wrap with Padding algorithm provides almost the same
amount of integrity protection as the AES Key Wrap algorithm.
A previous padding technique was specified for wrapping HMAC keys A previous padding technique was specified for wrapping HMAC keys
with AES [OLD-KW]. The technique in this document is preferred, and with AES [OLD-KW]. The technique in this document is preferred, and
the technique in this document is not limited to wrapping HMAC keys. the technique in this document is not limited to wrapping HMAC keys.
The key wrapping technique specified in this document requires the
length of the key data to be at least nine octets because a single
application of the AES codebook is sufficient to protect up to eight
octets of key data. In particular, if the key data consists of eight
or fewer octets, then a 64-bit integrity check value could be
prepended to the key data to form a single 128-bit block. For
example, the integrity check value could consist of a fixed seven
octet value followed by a single octet length value. The wrapping
and unwrapping processes employing such an integrity check value and
a single AES codebook operation could be defined analogous to those
in Section 4 if there is a need to wrap keys that are smaller than
nine octets.
8. References 8. References
8.1. Normative References 8.1. Normative References
AES National Institute of Standards and Technology. FIPS Pub AES National Institute of Standards and Technology. FIPS Pub
197: Advanced Encryption Standard (AES). 26 November 2001. 197: Advanced Encryption Standard (AES). 26 November 2001.
AES-KW1 National Institute of Standards and Technology. AES Key AES-KW1 National Institute of Standards and Technology. AES Key
Wrap Specification. 17 November 2001. Wrap Specification. 17 November 2001.
[http://csrc.nist.gov/encryption/kms/key-wrap.pdf] [http://csrc.nist.gov/encryption/kms/key-wrap.pdf]
 End of changes. 32 change blocks. 
89 lines changed or deleted 117 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/