]>
Authenticated Encryption with AES-CBC and HMAC-SHA
<!-- (and other generic combinations of CBC and HMAC) -->
Cisco Systems, Inc. 13600 Dulles Technology Drive HerndonVA20171US(408) 525 8651mcgrew@cisco.comhttp://www.mindspring.com/~dmcgrew/dam.htmRoyal 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) [BN00] 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 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.
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 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.
In CBC-HMAC, the nonce 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.
An Initialization Vector (IV) is generated randomly or
pseudorandomly, as described in ,
for use in the cipher.
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, and the IV
generated in the previous step. We denote the
ciphertext output from this step as S, and it MUST
include the IV as its prefix.
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. 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. If those values are identical, then A and
C are considered valid, and processing is
continued. 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 decrypted, using the initial 16 octets of
the ciphertext as the IV. The value ENC_KEY is used
as the decryption key.
The padding string is removed. Note that the length
of PS can be inferred from the value of the final
octet of P || PS, if that value is between 00 and 0F
(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 and stateless. It is based on
the CBC-HMAC algorithm detailed above. It 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 AES
in the cipher block chaining (CBC) mode of operation as
defined in Section 6.2 of , with
the padding method used by PEM, PKCS, and TLS.
The input key K is 32 octets long.
The AES CBC IV is 16 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 48 octets,P_MAX is 2^64 - 1 octets,A_MAX is 2^64 - 1 octets,N_MIN is zero octets, N_MAX is 2^64 octets, andC_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.
AEAD_AES_128_CBC_HMAC_SHA1 is based on AEAD_AES_128_CBC_HMAC_SHA_256,
but with the following differences:
HMAC-SHA1 is used instead of HMAC-SHA-256. Test cases for
HMAC-SHA1 are provided in .
MAC_KEY_LEN is 20 octets.
The length of the input key K is 36 octets.
The HMAC-SHA-1 value is truncated to T_LEN=12 octets
instead of 16 octets. (Note that this matches the
truncation used in .)
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 AEAD_AES_128_CBC_HMAC_SHA1 16 20 12
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.
SP 800-90 describes suitable pseudorandom generators.
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 applicaiton 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 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 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-SHA1 because it is widely deployed and is
adequately secure, and HMAC-SHA-2, because it is used in newer
standards and is expected to become widely deployed. 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.
A future version of this note will contain test cases for all of the
AEAD algorithms that it defines.
An earlier version of this document benefitted from some review.
Comments on this version are requested and should be forwarded to the
IRTF Crypto Forum Research Group (CFRG).
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.
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 and John Foley for their
constructive feedback; special thanks to John for his generation
of the test cases. Thanks also to Kelly Burgin and Michael Peck
for their suggestions and help.
&rfc2104;
&rfc2119;
&rfc2202;
&rfc2404;
&rfc4231;
&rfc4868;
&rfc5116;
FIPS 180-2: Secure Hash Standard,FIPS 197: Advanced Encryption Standard (AES)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 . 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,
The function CIPHER-INV(K, C) denotes the decryption of the
block C with the block cipher; 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 the number of bits that
the block cipher accepts as its plaintext input,
C_0, C_1, C_2, ... , C_n denotes the sequence of ciphertext blocks,
where each block contains exactly the number of bits that
the block cipher accepts as its plaintext input,
P_i and C_i denote the ith blocks of the plaintext, and
IV denotes the initialization vector, which contains exactly
the number of bits that the block cipher accepts as its
plaintext input.
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 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. 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
a sequence of m ciphertext blocks and produces a sequence
of m-1 plaintext blocks as follows: