]>
Authenticated Encryption with AES-CBC and HMAC-SHA
<!-- (and other generic combinations of CBC and HMAC) -->
Cisco Systems 13600 Dulles Technology Drive HerndonVA20171USmcgrew@cisco.comhttp://www.mindspring.com/~dmcgrew/dam.htmCisco Systems 7025-2 Kit Creek Road Research Triangle ParkNC14987USfoleyj@cisco.comRoyal Holloway, University of London TW20 0EX EghamSurreyTW20 0EXUK +44 1784 414393 Kenny.Paterson@rhul.ac.uk http://www.isg.rhul.ac.uk/~kp/
General
Encryption, Authentication
This document specifies algorithms for authenticated
encryption with associated data (AEAD) that are
based on the composition of the Advanced Encryption Standard
(AES) in the Cipher Block Chaining (CBC) mode of operation for
encryption, and the HMAC-SHA message authentication code
(MAC).
These are randomized encryption algorithms, and thus are
suitable for use with applications that cannot provide
distinct nonces to each invocation of the AEAD encrypt
operation.
Authenticated Encryption (AE) is a form of
encryption that, in addition to providing confidentiality for the
plaintext that is encrypted, provides a way to check its integrity and
authenticity. This combination of features can, when properly
implemented, provide security against adversaries who have access to
full decryption capabilities for ciphertexts of their choice, and
access to full encryption capabilities for plaintexts of their
choice. The strong form of security provided by AE is known to be
robust against a large class of adversaries for general purpose
applications of AE, including applications such as securing network
communications over untrusted networks. The strong security properties
of AE stand in contrast to the known weaknesses of "encryption only"
forms of encryption, see for examples.
Authenticated encryption with Associated Data, or AEAD , adds the ability to check the integrity and
authenticity of some associated data (sometimes called
"additional authenticated data") for which confidentiality is
not required (or is not desirable). While many approaches to
building AEAD schemes are known, a particularly simple,
well-understood, and cryptographically strong method is to
employ an "Encrypt-then-MAC" construction. This document
defines new AEAD algorithms of this general type, using the
interface defined in , based on the
Advanced Encryption Standard (AES) in
the Cipher Block Chaining (CBC) mode of operation and HMAC using the Secure Hash Algorithm
(SHA) , with security levels of 128,
192, and 256 bits.
Comments on this version are requested and should be forwarded to the
IRTF Crypto Forum Research Group (CFRG). An earlier version of this
document benefited from some review from that group.
This subsection describes the revision history of this Internet Draft.
It should be removed by the RFC Editor before publication as an RFC.
The changes of version 05 from version 05 consist only of
changes in Appendix A and the test cases. A variable Q was
defined to make the legacy encoding more clear, after
discussion between the authors and Mike Jones.
The changes of version 02 from version 01 are:
Added test cases for each of the five operational modes.
Added John as a coauthor.
Adds a legacy-style interface in Appendix B.
The changes of version 01 from version 00 are:
MIN_LEN_A and associated logic was eliminated.
Padding String (PS) typo corrected in Section 2.1.
Decryption Step 3 refers to the appropriate step in the
encryption process.
Random IV min-entropy clarified in Section 3.
HMAC keys are now the same size as the truncated output
(128 or 256 bits). Previously, the HMAC keys were the
same size as the full hash output (256, 384, or 512
bits).
An algorithm based on the combination of AES-256 and
HMAC-SHA-384 has been added, for compatibility with
draft-burgin-kerberos-aes-cbc-hmac-sha2.
The test cases in the previous version are no longer
valid, and thus have been removed. New test cases have
been computed (and the authors thank John Foley for this
contribution) but have not been included, pending
confirmation from a second, independent implementation.
We use the following notational conventions.
CBC-ENC(X,P) denotes the CBC encryption of P using the cipher
with the key X
MAC(Y, M) denotes the application of the Message
Authentication Code (MAC) to the message M, using the key Y
The
concatenation of two octet strings A and B is denoted as A || B
len(X) denotes the number of bits in the string X,
expressed as an unsigned integer in network byte order.
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 .
This section defines CBC-HMAC, an algorithm based on the the
encrypt-then-MAC method defined in Section 4.3 of . That method constructs a randomized
AEAD algorithm out of a randomized cipher, such as a block
cipher mode of operation that uses a random initialization
vector, and a MAC.
and define the
CBC-HMAC encryption and decryption algorithms, without
specifying the particular block cipher or hash function to
be used. , , and
define instances of CBC-HMAC that specify those details.
We briefly recall the encryption interface defined in
Section 2 of . The AEAD
encryption algorithm takes as input four octet strings: a
secret key K, a plaintext P, associated data A, and a
nonce N. An authenticated ciphertext value is provided as
output. The data in the plaintext are encrypted and
authenticated, and the associated data are authenticated,
but not encrypted. The key MUST be generated in a way
that is uniformly random or pseudorandom; guidance on
random sources is provided in .
In CBC-HMAC, the nonce N MUST be a zero-length string; a
nonce is not needed and is not used (see for further background).
The CBC-HMAC encryption process is as follows, or
uses an equivalent set of steps:
The secondary keys MAC_KEY and ENC_KEY are generated
from the input key K as follows. Each of these two
keys is an octet string.
MAC_KEY consists of the initial MAC_KEY_LEN octets of
K, in order.ENC_KEY consists of the final ENC_KEY_LEN octets of
K, in order.
Here we denote the number of octets in the MAC_KEY as
MAC_KEY_LEN, and the number of octets in ENC_KEY as
ENC_KEY_LEN; the values of these parameters are specified
by the AEAD algorithms (in and
). The number of octets in the
input key K is the sum of MAC_KEY_LEN and ENC_KEY_LEN.
When generating the secondary keys from K, MAC_KEY and ENC_KEY
MUST NOT overlap.
Prior to CBC encryption, the plaintext P is padded by
appending a padding string PS to that data, to ensure
that len(P || PS) is a multiple of 128, as is needed
for the CBC operation. The value of PS is as follows:
Note that padding MUST be added to the
plaintext; if the number of bits in P is a
multiple of 128, then 128 bits of padding will be
added.
The plaintext and appended padding P || PS is
CBC encrypted using ENC_KEY as the key, as described in
. We denote the ciphertext output
from this step as S.
The octet string AL is equal to the number
of bits in A expressed as a 64-bit unsigned integer in network byte
order.
A message authentication tag T is computed by applying
HMAC to the following data, in
order:
the associated data A, the ciphertext S computed in the previous step, and the octet string AL defined above.
The string MAC_KEY is used as the MAC key. We denote
the output of the MAC computed in this step as T.
The AEAD Ciphertext consists of the string S, with the
string T appended to it. This Ciphertext is returned as
the output of the AEAD encryption operation.
The encryption process can be illustrated as follows. Here
P, A, and C denote the AEAD plaintext, associated data, and
ciphertext, respectively.
MAC_KEY = initial MAC_KEY_LEN bytes of K
ENC_KEY = final ENC_KEY_LEN bytes of K
S = CBC-ENC(ENC_KEY, P || PS),
T = MAC(MAC_KEY, A || S || AL),
C = S || T.
The authenticated decryption operation has four inputs: K,
N, and A, as defined above, and the Ciphertext C. As
discussed above, N is an empty string in AES-CBC and is
not used below. It has only a single output, either a
plaintext value P or a special symbol FAIL that indicates
that the inputs are not authentic. The authenticated
decryption algorithm takes is as follows, or uses an
equivalent set of steps:
The secondary keys MAC_KEY and ENC_KEY are generated
from the input key K as in Step 1 of .
The final T_LEN octets are stripped from C. Here T_LEN
denotes the number of octets in the MAC, which is a
fixed parameter of the AEAD algorithm. We denote
the initial octets of C as S, and denote the final
T_LEN octets as T.
The integrity and authenticity of A and C are checked
by computing HMAC with the inputs as in Step 6 of
.
The value T, from the previous step, is compared to the
HMAC output, using a comparison routine that takes
constant time to execute. If those values are
identical, then A and C are considered valid, and the
processing continues. Otherwise, all of the data used
in the MAC validation are discarded, and the AEAD
decryption operation returns an indication that it
failed, and the operation halts. The value S is CBC decrypted, as described in , using the value ENC_KEY is as the
decryption key.
The padding string is stripped from the resulting
plaintext. Note that the length of PS can be inferred
from the value of the final octet of P || PS, if that
value is between 01 and 10 (hexadecimal). If the
final octet has a value outside that range, then all
of the data used in the processing of the message is
zeroized and discarded, and the AEAD decryption
operation returns an indication that it failed, and
the operation halts.
The plaintext value is returned.The length of the ciphertext can be inferred from that of the
plaintext. The number L of octets in the ciphertext is given by
L = 16 * ( floor(M / 16) + 2) where M denotes the number of octets in the
plaintext, and the function floor() rounds its argument down
to the nearest integer. This fact is useful to applications
that need to reserve space for a ciphertext within a message
or data structure.This algorithm is randomized; each invocation of the
encrypt operation makes use of a random value (the IV
described in ). It is based on the
CBC-HMAC algorithm detailed above, and uses the HMAC message
authentication code with the
SHA-256 hash function to
provide message authentication, with the HMAC output truncated
to 128 bits, corresponding to the HMAC-SHA-256-128 algorithm
defined in . For encryption, it uses
the Advanced Encryption Standard (AES)
block cipher in CBC mode.
The input key K is 32 octets long.
ENC_KEY_LEN is 16 octets.
The SHA-256 hash algorithm is used in HMAC. MAC_KEY_LEN is 16
octets. The HMAC-SHA-256 output is truncated to T_LEN=16 octets,
by stripping off the final 16 octets. Test cases for
HMAC-SHA-256 are provided in .
The lengths of the inputs are restricted as follows:K_LEN is 32 octets,P_MAX is 2^64 - 1 octets,A_MAX is 2^64 - 1 octets,N_MIN and N_MAX are zero octets,C_MAX is 2^64 + 47 octets.
AEAD_AES_192_CBC_HMAC_SHA_384 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
AES-192 is used instead of AES-128.
SHA-384 is used in HMAC instead of SHA-256.
ENC_KEY_LEN is 24 octets.
MAC_KEY_LEN is 24 octets.
The length of the input key K is 48 octets.
The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 16 octets.
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
AEAD_AES_256_CBC_HMAC_SHA_384 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
AES-256 is used instead of AES-128.
SHA-384 is used in HMAC instead of SHA-256.
ENC_KEY_LEN is 32 octets.
MAC_KEY_LEN is 24 octets.
The length of the input key K is 56 octets.
The HMAC-SHA-384 value is truncated to T_LEN=24 octets instead of 16 octets.
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
AEAD_AES_256_CBC_HMAC_SHA_512 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
AES-256 is used instead of AES-128.
SHA-512 is used in HMAC instead of SHA-256.
ENC_KEY_LEN is 32 octets.
MAC_KEY_LEN is 32 octets.
The length of the input key K is 64 octets.
The HMAC-SHA-512 value is truncated to T_LEN=32 octets instead of 16 octets.
The input length restrictions are as for AEAD_AES_CBC_128_HMAC_SHA_256.
The parameters of the CBC-HMAC algorithms are summarized in the following table.
algorithm ENC_KEY_LEN MAC_KEY_LEN T_LEN AEAD_AES_128_CBC_HMAC_SHA_256 16 16 16 AEAD_AES_192_CBC_HMAC_SHA_384 24 24 24 AEAD_AES_256_CBC_HMAC_SHA_384 32 24 24 AEAD_AES_256_CBC_HMAC_SHA_512 32 32 32
Each IV MUST be unpredictable to the adversary. It MAY be chosen
uniformly at random, in which case it SHOULD have min-entropy
within one bit of len(IV). Alternatively, it MAY be generated
pseudorandomly, using any method that provides the same level of
security as the block cipher in use. However, if a pseudorandom
method is used, that method MUST NOT make use of ENC_KEY or
MAC_KEY.
The CBC-HMAC AEAD algorithms defined in this note are intended to be useful in
the following applications:
systems that have the CBC and HMAC algorithms available, but do
not have dedicated AEAD algorithms such as GCM or CCM ,
scenarios in which AEAD is useful, but it is undesirable to have
the application maintain a deterministic nonce; see Section 4 of
for more background,
new systems, such as JSON Cryptography and W3C Web Crypto, which can
omit unauthenticated symmetric encryption altogether by providing
CBC and HMAC through an AEAD interface.
These algorithms are not intended to replace existing
uses of AES-CBC and HMAC, except in those circumstances where the
existing use is not sufficiently secure or sufficiently
general-purpose.
The algorithms in this note truncate the HMAC output to half of the
size of the output of the underlying hash function. This size is the
recommended minimum (see Section 5 of ), and
this parameter choice has withstood the test of time.
The length of the associated data input A is included in the HMAC
input to ensure that the encrypter and the decrypter have the same
understanding of that length. Because of this, an attacker cannot
trick the receiver into interpreting the initial bytes of C as the
final bytes of A, or vice-versa.
The padding method used in this note is based on that of Privacy
Enhanced Mail (PEM) and the Public Key Cryptography Standards (PKCS),
because it is implemented in many environments.
The encrypt-then-MAC method is used because of its better security
properties. It would be possible to define AEAD algorithms based on
the MAC-encode-encrypt (MEE) method that is used by the Transport
Layer Security (TLS) protocol . That
alternative would provide more code-sharing opportunities for an
implementation that is co-resident with a TLS implementation. It is
possible (but tricky) to implement MEE in a way that provides good
security, as was shown in . But its negatives
outweigh its positives; its security is inadequate for some parameter
choices, and it has proven to be very difficult to implement in a way
that resists padding oracle and related timing attacks
. For future uses of CBC and HMAC, it is better
to use encrypt-then-MAC.
This note uses HMAC-SHA-2 because it is widely deployed, it is
mandated in newer standards, and because SHA1 is being deprecated. It
has been recently announced that the SHA-3 standard will be based on
KECCAK, but this note does not incorporate that hash function. To do
so would be to speculate on the final form of the SHA-3 standard. In
addition, while the use of KECCAK as a hash function is
straightforward, there are multiple options for its use in
authenticated encryption. The focus of this note is the definition of
AEAD algorithms based on currently used cryptographic mechanisms, so
SHA-3 is out of scope.
The algorithms defined in this document use the generic composition
of CBC encryption with HMAC authentication, with the encrypt-then-MAC
method defined in Section 4.3 of . This
method has sound and well-understood security properties; for details,
please see that reference. Note that HMAC is a good pseudorandom
function and is "strongly unforgeable", and thus meets all of
the security goals of that reference.
Implementations of the encryption and decryption algorithms should
avoid side channels that would leak information about the secret key.
To avoid timing channels, the processing time should be independent of
the secret key. The Encrypt-then-MAC construction used in this note
has some inherent strength against timing attacks because, during the
decryption operation, the authentication check is computed before the
plaintext padding is processed. However, the security of the
algorithm still relies on the absence of timing channels
in both CBC and HMAC. Additionally, comparison between
the authentication tag T and the HMAC output should be
done using a constant-time operation.
During the decryption process, the inputs A and C are mapped into the
input of the HMAC algorithm. It is essential for security that each
possible input to the MAC algorithm corresponds unambiguously to
exactly one pair (A, C) of possible inputs. The fact that this
property holds can be verified as follows. The HMAC input is
X = A || C || len(A). Let (A,C) and (A',C') denote two distinct input
pairs, in which either 1) A != A' and C = C', 2) C != C and A = A', or
3) both inequalities hold. We also let X' = A' || C' || len(A'). In
cases 1 and 2, X != X' follows immediately. In case 3, if len(A) !=
len(A'), then X != X' directly. If len(A) = len(A'), then X != X
follows from the fact that the initial len(A) bits of X and X' must be
distinct.
There are security benefits to providing both confidentiality and
authentication in a single atomic operation, as done in this note.
This tight binding prevents subtle attacks such as the padding
oracle attack.
As with any block cipher mode of operation, the security of AES-CBC
degrades as the amount of data that is process increases. Each fixed
key value SHOULD NOT be used to protect more than 2^64 bytes of data.
This limit ensures that the AES-CBC algorithm will stay under the
birthday bound, i.e. because of the limit, it is unlikely that there
will be two AES plaintext inputs that are equal. (If this event
occurs, information about the colliding plaintexts is leaked, so it
is desirable to bound the amount of plaintext processed in order to
make it unlikely.)
Thanks are due to Matt Miller for his constructive feedback, Kelly
Burgin, Michael Peck, and Mike Jones for their suggestions and
help, and Jim Schaad, Rob Napier, James Manger, and David Jacobson
for their excellent review and suggestions.
&rfc2104;
&rfc2119;
&rfc4231;
&rfc4868;
&rfc5116;
FIPS 180-2: Secure Hash Standard,FIPS 197: Advanced Encryption Standard (AES)
&rfc4086;
NIST Special Publication 800-38: Recommendation for
Block Cipher Modes of Operation
Authenticated encryption: Relations among notions and
analysis of the generic composition paradigmAuthenticated encryption with Associated-DataTag Size Does Matter: Attacks and Proofs for the TLS Record Protocol Security Flaws Induced by CBC Padding - Applications to SSL, IPSEC, WTLS .... Password Interception in a SSL/TLS Channel Security of CBC Ciphersuites in SSL/TLS: Problems and CountermeasuresOn the (in)security of IPsec in MAC-then-encrypt configurations.Attacking the IPsec Standards in Encryption-only
ConfigurationsPlaintext-Recovery Attacks Against Datagram TLSThe Perils of Unauthenticated Encryption: Kerberos Version 4Problem areas for the IP security protocols
&rfc5246;
The Cipher Block Chaining (CBC) mode of operation is defined
in Section 6.2 of . This section recalls how that
mode works, for the convenience of the reader.
The following notation is used:
K denotes the key of the underlying block cipher,
The function CIPHER(K, P) denotes the encryption of the
block P with the block cipher, where P contains exactly
b bits,
The function CIPHER-INV(K, Q) denotes the decryption of the
block Q with the block cipher, where Q contains exactly b
bits; this is the inverse operation of CIPHER(), and
CIPHER-INV(K, CIPHER(K, P)) = P for all P and all K,
P_1, P_2, ... , P_n denotes the sequence of plaintext blocks,
where each block contains exactly b bits,
Q_1, Q_2, ... , Q_n denotes the sequence of ciphertext blocks,
where each block contains exactly b bits,
P_i and Q_i denote the ith blocks of the plaintext, and
IV denotes the initialization vector, which contains exactly
b bits.
The CBC encryption operation (denoted as CBC-ENC) takes as input
a sequence of n plaintext blocks and produces a sequence
of n + 1 ciphertext blocks as follows:
The operation CBC-ENC(K, P_1 || P_2 || ... || P_n) returns
the value IV || Q_1 || Q_2 || ... || Q_n. Note that the
returned value is one block longer than the input value.
The IV MUST be generated using a uniformly random process, or a
pseudorandom process with a cryptographic strength equivalent to
that of the underlying block cipher; see for background on random sources. It MUST
NOT be predictable to an attacker; in particular, it MUST NOT be
set to the value of any previous ciphertext blocks.
The CBC decryption operation (denoted as CBC-DEC) takes as input
an octet string whose length is a multiple of b bits,
decomposes it as IV || Q_1 || Q_2 || ... || Q_m, then produces a
sequence of m plaintext blocks as follows:
The operation CBC-DEC(K, IV || Q_1 || Q_2 || ... || Q_m)
returns the value P_1 || P_2 || ... || P_m.
In some scenarios, cryptographic data such as the ciphertext,
initialization vector, and message authentication tag are
encoded separately. To allow for the use of the algorithms
defined in this document in such scenarios, this appendix
describes an interface in which those data elements are
discrete. New implementations SHOULD NOT use this interface,
because it is incompatible with other authenticated encryption
methods and is more complex; however, it MAY be useful
in scenarios in which the separate encoding is already
in use.
The alternative interface is as follows.
The inputs to the encryption operation the same as those
defined in (the secret key K, the
plaintext P, the associated data A).
The outputs of the encryption operation are:
the initialization vector IV as defined in ,
the ciphertext C, as defined in , and
the message authentication tag T, as defined in .
The inputs to the decryption operation (in addition to K and A) are:
the initialization vector IV as defined in ,
the ciphertext C as defined in ,
excluding the initial block C_0 (which is equal to the IV),
and
the message authentication tag T, as defined in .
The output of the decryption operation are the same as that
defined in (either a plaintext value P or a
special symbol FAIL that indicates that the inputs are not
authentic).
All processing other than the encoding and decoding of IV, C,
and T is done as defined above. In particular, the IV is an
output of the encryption operation, rather than an input.