View source for CBC-MAC

{{Short description|Message authentication code algorithm}}
In [[cryptography]], a '''cipher block chaining message authentication code''' ('''CBC-MAC''') is a technique for constructing a [[message authentication code|message authentication code (MAC)]] from a [[block cipher]].  The message is encrypted with some block cipher algorithm in [[Block cipher modes of operation#Cipher block chaining (CBC)|cipher block chaining (CBC) mode]] to create a chain of blocks such that each block depends on the proper encryption of the previous block.  This interdependence ensures that a change to any of the plaintext bits will cause the final encrypted block to change in a way that cannot be predicted or counteracted without knowing the key to the block cipher.
[[Image:CBC-MAC structure (en).svg|thumb|400px|CBC-MAC construction]] 
To calculate the CBC-MAC of message {{mvar|m}}, one encrypts {{mvar|m}} in CBC mode with zero [[initialization vector]] and keeps the last block. The following figure sketches the computation of the CBC-MAC of a message comprising blocks <math>m_1\|m_2\|\cdots\|m_x</math> using a secret key {{mvar|k}} and a block cipher {{mvar|E}}:
CBC-MAC on its own is not secure for variable-length messages<ref name="BKR"/> (see the discussion below) and is currently used to construct a [[pseudorandom function family]]{{sfn|Cliff|Boyd|Gonzalez Nieto|2009|p=5}} and as a component of the [[CCM mode]].

== Use in standards ==
The CBC-MAC construct is used as part of the [[CCM mode]] utilized in [[IEEE 802.11i]] and [[NIST SP 800-97]] (as [[CCMP (cryptography)|CCMP]], the CCM encryption protocol for [[WPA2]]), [[IPsec]],<ref>{{IETF RFC|4309}} Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)</ref> and [[Transport Layer Security|TLS]] 1.2,<ref>{{IETF RFC|6655}} AES-CCM Cipher Suites for Transport Layer Security (TLS)</ref> as well as [[Bluetooth Low Energy]] (as of [[Bluetooth#Bluetooth 4.0|Bluetooth 4.0]], see [[NIST SP 800-121]] Rev2).<ref>{{Cite web |url=https://www.bluetooth.com/~/media/files/specification/bluetooth-low-energy-security.ashx?la=en |title=Bluetooth Low Energy Security |access-date=2017-04-20 |archive-url=https://web.archive.org/web/20160402235955/https://www.bluetooth.com/~/media/files/specification/bluetooth-low-energy-security.ashx?la=en |archive-date=2016-04-02 |url-status=dead }}</ref> It is available for TLS 1.3, but not enabled by default in [[OpenSSL]].<ref>{{cite web|url=https://openssl-library.org/post/2017-05-04-tlsv1.3/ |title=Using TLS1.3 With OpenSSL |first=Matt |last=Caswell |date=2017-05-04 |access-date=2024-10-11 |publisher=[[OpenSSL]] blog}}</ref> 

CBC-MAC is also used as a "conditioning component" (a.k.a. randomness extractor,{{sfn|Cliff|Boyd|Gonzalez Nieto|2009| p=5}} a method to generate bitstrings with [[full entropy]]) in [[NIST SP 800-90B]].

===Standards that define the algorithm===
[[FIPS PUB 113]] ''Computer Data Authentication'' is a (now obsolete) [[Federal Information Processing Standard|U.S. government standard]] that specified the CBC-MAC algorithm using [[Data Encryption Standard|DES]] as the block cipher.

The CBC-MAC algorithm is also included into ANSI X9.9, ANSI X9.19, ISO 8731-1, and [[ISO/IEC 9797-1]] MAC (Algorithm 1).{{sfn|Preneel|van Oorschot|1999|p=7}}

==Security with fixed and variable-length messages==
If the block cipher used is secure (meaning that it is a [[pseudorandom permutation]]), then CBC-MAC is secure for fixed-length messages.<ref name="BKR">M. Bellare, J. Kilian and P. Rogaway. [https://cseweb.ucsd.edu/~mihir/papers/cbc.pdf The security of the cipher block chaining message authentication code.] JCSS 61(3):362–399, 2000.</ref> However, by itself, it is not secure for variable-length messages. Thus, any single key must only be used for messages of a fixed and known length. This is because an attacker who knows the correct [[authentication tag]] (i.e. CBC-MAC) pairs for two messages <math>(m, t)</math> and <math>(m', t')</math> can generate a third message <math>m''</math> whose CBC-MAC will also be <math>t'</math>. This is simply done by XORing the first block of <math>m'</math> with {{mvar|t}} and then concatenating {{mvar|m}} with this modified <math>m'</math>; i.e., by making <math>m'' = m \| [(m_1' \oplus t) \| m_2' \| \dots \| m_x']</math>. When computing the MAC for the message <math>m''</math>, it follows that we compute the MAC for {{mvar|m}} in the usual manner as {{mvar|t}}, but when this value is chained forwards to the stage computing <math>E_{K_\text{MAC}}(m_1' \oplus t)</math> we will perform an exclusive OR operation with the value derived for the MAC of the first message. The presence of that tag in the new message means it will cancel, leaving no contribution to the MAC from the blocks of plain text in the first message {{mvar|m}}: <math>E_{K_\text{MAC}}(m_1' \oplus t \oplus t) = E_{K_\text{MAC}}(m_1')</math> and thus the tag for <math>m''</math> is <math>t'</math>.

This problem cannot be solved by adding a message-size block to the end.<ref name=":0" /> There are three main ways of modifying CBC-MAC so that it is secure for variable length messages: 1) Input-length key separation; 2) Length-prepending; 3) Encrypt last block.<ref name=":0" /> In such a case, it may also be recommended to use a different mode of operation, for example, [[CMAC]] or [[HMAC]] to protect the integrity of variable-length messages.

=== Length prepending ===
One solution is to include the length of the message in the first block;<ref>[http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=30656 ISO/IEC 9797-1:1999 ''Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher''], clause 6.1.3 Padding Method 3</ref> in fact CBC-MAC has been proven secure as long as no two messages that are prefixes of each other are ever used and prepending the length is a special case of this.<ref name=":1">C. Rackoff and S. Gorbunov. On the Security of Block Chaining Message Authentication Code.</ref> This can be problematic if the message length may not be known when processing begins.

=== Encrypt-last-block ===
[[Image:CBC-MAC (encrypt last block) structure.svg|right|300px|thumb|Computation of CBC-MAC Encrypt-last-block.]]
Encrypt-last-block CBC-MAC (ECBC-MAC)<ref>http://spark-university.s3.amazonaws.com/stanford-crypto/slides/05.3-integrity-cbc-mac-and-nmac.pptx {{Webarchive|url=https://web.archive.org/web/20170422060816/http://spark-university.s3.amazonaws.com/stanford-crypto/slides/05.3-integrity-cbc-mac-and-nmac.pptx |date=2017-04-22 }} {{Bare URL inline|date=September 2022}}</ref> is defined as {{math|CBC-MAC-ELB(<var>m</var>, (<var>k</var><sub>1</sub>, <var>k</var><sub>2</sub>)) {{=}} <var>E</var>(<var>k</var><sub>2</sub>, CBC-MAC(<var>k</var><sub>1</sub>, <var>m</var>))}}.<ref name=":0">See Section 5 of Bellare, et al.</ref> Compared to the other discussed methods of extending CBC-MAC to variable-length messages, encrypt-last-block has the advantage of not needing to know the length of the message until the end of the computation.

==Attack methods against incorrect use==

As with many cryptographic schemes, naïve use of ciphers and other protocols may lead to attacks being possible, reducing the effectiveness of the cryptographic protection (or even rendering it useless). We present attacks which are possible due to using the CBC-MAC incorrectly.<ref>[https://blog.cryptographyengineering.com/2013/02/15/why-i-hate-cbc-mac/ Why I hate CBC-MAC] by [[Matthew D. Green]]</ref>

===Using the same key for encryption and authentication===
One common mistake is to reuse the same key {{mvar|k}} for CBC encryption and CBC-MAC. Although a reuse of a key for different purposes is a bad practice in general, in this particular case the mistake leads to a spectacular attack:

Suppose Alice has sent to Bob the cipher text blocks <math>C = C_1 \| C_2 \| \dots \| C_n</math>. During the transmission process, Eve can tamper with any of the <math>C_1 , \dots , C_{n-1}</math> cipher-text blocks and adjust any of the bits therein as she chooses, provided that the final block, <math>C_n</math>, remains the same. We assume, for the purposes of this example and without loss of generality, that the initialization vector used for the encryption process is a vector of zeroes.

When Bob receives the message, he will first decrypt the message by reversing the encryption process which Alice applied, using the cipher text blocks <math>C=C_1 \| C_2 \| \cdots \| C_n</math>. The tampered message, delivered to Bob in replacement of Alice's original, is <math>C'=C_1' \| \dots \| C_{n-1}' \| C_n</math>.

Bob first decrypts the message received using the shared secret key {{mvar|K}} to obtain corresponding plain text. Note that all plain text produced will be different from that which Alice originally sent, because Eve has modified all but the last cipher text block. In particular, the final plain text, <math>P_n'</math>, differs from the original, <math>P_n</math>, which Alice sent; although <math>C_n</math> is the same, <math>C_{n-1}' \not = C_{n-1}</math>, so a different plain text <math>P_n'</math> is produced when chaining the previous cipher text block into the exclusive-OR after decryption of <math>C_n</math>: <math>P_n' = C_{n-1}' \oplus E_K^{-1}(C_n)</math>.

It follows that Bob will now compute the authentication tag using CBC-MAC over all the values of plain text which he decoded. The tag for the new message, <math>t'</math>, is given by:

: <math>t' = E_K(P_n' \oplus E_K(P_{n-1}' \oplus E_K( \dots \oplus E_K(P_1'))))</math>

Notice that this expression is equal to

: <math>t' = E_K(P_n' \oplus C_{n-1}')</math>

which is exactly <math>C_n</math>:

: <math>t' = E_K(C_{n-1}' \oplus E_K^{-1}(C_n) \oplus C_{n-1}') = E_K(E_K^{-1}(C_n)) = C_n</math>

and it follows that <math>t' = C_n = t</math>.

Therefore, Eve was able to modify the cipher text in transit (without necessarily knowing what plain text it corresponds to) such that an entirely different message, <math>P'</math>, was produced, but the tag for this message matched the tag of the original, and Bob was unaware that the contents had been modified in transit. By definition, a Message Authentication Code is ''broken'' if we can find a different message (a sequence of plain-text pairs <math>P'</math>) which produces the same tag as the previous message, {{mvar|P}}, with <math>P \not = P'</math>. It follows that the message authentication protocol, in this usage scenario, has been broken, and Bob has been deceived into believing Alice sent him a message which she did not produce.

If, instead, we use different keys for the encryption and authentication stages, say <math>K_1</math> and <math>K_2</math>, respectively, this attack is foiled. The decryption of the modified cipher-text blocks <math>C_i'</math> obtains some plain text string <math>P_i'</math>. However, due to the MAC's usage of a different key <math>K_2</math>, we cannot "undo" the decryption process in the forward step of the computation of the message authentication code so as to produce the same tag; each modified <math>P_i'</math> will now be encrypted by <math>K_2</math> in the CBC-MAC process to some value <math>\mathrm{MAC}_i \not = C_i'</math>.

This example also shows that a CBC-MAC cannot be used as a collision-resistant one-way function: given a key it is trivial to create a different message which "hashes" to the same tag.

===Allowing the initialization vector to vary in value===

When encrypting data using a block cipher in [[cipher block chaining]] (or another) mode, it is common to introduce an [[initialization vector]] to the first stage of the encryption process. It is typically required that this vector be chosen randomly (a [[Cryptographic nonce|nonce]]) and that it is not repeated for any given secret key under which the block cipher operates. This provides semantic security, by means of ensuring the same plain text is not encrypted to the same cipher text, allowing an attacker to infer a relationship exists.

When computing a message authentication code, such as by CBC-MAC, the use of an initialization vector is a possible attack vector.

In the operation of a ciphertext block chaining cipher, the first block of plain text is mixed with the initialization vector using an exclusive OR (<math>P_1 \oplus IV</math>). The result of this operation is the input to the block cipher for encryption.

However, when performing encryption and decryption, we are required to send the initialization vector in plain text - typically as the block immediately preceding the first block of cipher text - such that the first block of plain text can be decrypted and recovered successfully. If computing a MAC, we will also need to transmit the initialization vector to the other party in plain text so that they can verify the tag on the message matches the value they have computed.

If we allow the initialization vector to be selected arbitrarily, it follows that the first block of plain text can potentially be modified (transmitting a different message) while producing the same message tag.

Consider a message <math>M_1 = P_1 | P_2 | \dots</math>. In particular, when computing the message tag for CBC-MAC, suppose we choose an initialization vector <math>IV_1</math> such that computation of the MAC begins with <math>E_K(IV_1 \oplus P_1)</math>. This produces a (message, tag) pair <math>(M_1, T_1)</math>.

Now produce the message <math>M_2 = P_1' | P_2 | \dots</math>. For each bit modified in <math>P_1'</math>, flip the corresponding bit in the initialization vector to produce the initialization vector <math>IV_1'</math>. It follows that to compute the MAC for this message, we begin the computation by <math>E_K(P_1' \oplus IV_1')</math>. As bits in both the plain text and initialization vector have been flipped in the same places, the modification is cancelled in this first stage, meaning the input to the block cipher is identical to that for <math>M_1</math>. If no further changes are made to the plain text, the same tag will be derived despite a different message being transmitted.

If the freedom to select an initialization vector is removed and all implementations of CBC-MAC fix themselves on a particular initialization vector (often the vector of zeroes, but in theory, it could be anything provided all implementations agree), this attack cannot proceed.

To sum up, if the attacker is able to set the IV that will be used for MAC verification, he can perform arbitrary modification of the first data block without invalidating the MAC.

=== Using predictable initialization vector ===
Sometimes IV is used as a counter to prevent message replay attacks.
However, if the attacker can predict what IV will be used for MAC verification,
he or she can replay previously observed message by modifying the first data block to compensate for the change in the IV that will be used for the verification.
For example, if the attacker has observed message <math>M_1 = P_1 | P_2 | \dots</math> with <math>IV_1</math> and knows <math>IV_2</math>, he can produce 
<math>M_1' = (P_1 \oplus IV_1 \oplus IV_2)| P_2 | \dots</math> that will pass MAC verification with <math>IV_2</math>.

The simplest countermeasure is to encrypt the IV before using it (i.e., prepending IV to the data). Alternatively MAC in CFB mode can be used, because in CFB mode the IV is encrypted before it is XORed with the data.

Another solution (in case protection against message replay attacks is not required) is to always use a zero vector IV.<ref>Introduction to Modern Cryptography, Second Edition by Jonathan Katz and Yehuda Lindell</ref> Note that the above formula for <math>M_1'</math> becomes <math>M_1' = (P_1 \oplus 0 \oplus 0)| P_2 | \dots = P_1 | P_2 | \dots = M_1</math>. So since <math>M_1</math> and <math>M_1'</math> are the same message, by definition they will have the same tag. This is not a forgery, rather the intended use of CBC-MAC.

==See also==
* [[CMAC]] – A block-cipher–based MAC algorithm which is secure for messages of different lengths (recommended by [[NIST]]).
* [[One-key MAC|OMAC]] and [[PMAC (cryptography)|PMAC]] – Other methods to turn block ciphers into message authentication codes (MACs).
* [[One-way compression function]] – Hash functions can be made from block ciphers. But note, there are significant differences in function and uses for security between [[Message authentication code|MACs]] (such as CBC-MAC) and [[Cryptographic hash function|hashes]].

== References ==
{{reflist}}

== Sources ==
* {{cite book | last1=Cliff | first1=Yvonne | last2=Boyd | first2=Colin | last3=Gonzalez Nieto | first3=Juan | series=Lecture Notes in Computer Science | volume=5536 | pages=53–70 | title=Applied Cryptography and Network Security | chapter=How to Extract and Expand Randomness: A Summary and Explanation of Existing Results | publisher=Springer Berlin Heidelberg | publication-place=Berlin, Heidelberg | year=2009 | isbn=978-3-642-01956-2 | issn=0302-9743 | doi=10.1007/978-3-642-01957-9_4 | chapter-url=https://eprint.iacr.org/2009/136.pdf}}
* {{cite journal | last1=Preneel | first1=B. | last2=van Oorschot | first2=P.C. | title=On the security of iterated message authentication codes | journal=IEEE Transactions on Information Theory | publisher=Institute of Electrical and Electronics Engineers (IEEE) | volume=45 | issue=1 | year=1999 | issn=0018-9448 | doi=10.1109/18.746787 | pages=188–199 | url=http://cr.yp.to/bib/1999/preneel.pdf}}

{{Cryptography navbox | hash}}

[[Category:Message authentication codes]]
[[Category:Block cipher modes of operation]]