Block Cipher Modes of Operation and the CMAC Mode for Authentication

Alberto Grand December 20, 2007
Abstract A block cipher is a symmetric key cipher which operates on fixedlength groups of bits. Whenever the input plaintext exceeds the block size, a so called “mode of operation” must be employed along with the block cipher. A block cipher mode, or mode, for short, is an algorithm that features the use of a symmetric key block cipher algorithm to provide an information service, such as confidentiality or authentication. The first part of this article aims at outlining five NIST recommended modes of operation which provide confidentiality (but do not ensure message integrity): Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB) and Counter (CTR). The second part of the article focuses on a message authentication code (MAC) algorithm based on a symmetric key block cipher, the CMAC algorithm. The CMAC authentication mode is also one of the seven modes which may be used with NIST’s approved encryption algorithms.


1 Cipher block modes of operation 1.1 Five confidentiality modes of operation . . . . . . . . . . . 1.1.1 Electronic Codebook (ECB) . . . . . . . . . . . . . 1.1.2 Cipher Block Chaining (CBC) . . . . . . . . . . . . 1.1.3 Cipher Feedback (CFB) . . . . . . . . . . . . . . . 1.1.4 Output Feedback (OFB) . . . . . . . . . . . . . . . 1.1.5 Counter (CTR) . . . . . . . . . . . . . . . . . . . . 1.2 Generation of Initialization Vectors . . . . . . . . . . . . . 1.3 Padding-related issues . . . . . . . . . . . . . . . . . . . . 1.3.1 Padding techniques . . . . . . . . . . . . . . . . . . 1.3.2 Ciphertext stealing (CTS) . . . . . . . . . . . . . . 1.4 Related-mode attacks . . . . . . . . . . . . . . . . . . . . . 1.4.1 Exploiting an ECB Oracle to attack the CTR mode 1.4.2 Exploiting a CBC Oracle to attack the CTR mode 2 The CMAC Mode for Authentication 2.1 Introduction . . . . . . . . . . . . . . . . . 2.2 Cipher Block Chaining MAC (CBC-MAC) 2.2.1 Description . . . . . . . . . . . . . 2.2.2 Weaknesses . . . . . . . . . . . . . 2.3 CMAC Specification . . . . . . . . . . . . 2.3.1 Subkeys generation . . . . . . . . . 2.3.2 CMAC generation . . . . . . . . . . 2.3.3 CMAC verification . . . . . . . . . 2.4 Security issues . . . . . . . . . . . . . . . . 2.4.1 Length of the MAC . . . . . . . . . 2.4.2 Message span of the key . . . . . . 2.4.3 Protection against replay attacks . References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 3 5 7 11 12 15 15 15 16 18 18 18 19 19 19 20 20 21 21 22 22 23 23 24 25 26

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .



Cipher block modes of operation
Five confidentiality modes of operation
Electronic Codebook (ECB)

The Electronic Codebook (ECB) is the simplest, and the most insecure, of the five modes of operation hereby described. Each input block is processed independently of all others. The algorithm lies, for each and every block, in a permutation over the set of all input blocks. The term codebook is used because, for a given key, there is a unique ciphertext for every block of plaintext. Therefore, we can imagine a gigantic codebook in which there is an entry for every possible plaintext pattern showing its corresponding ciphertext. This mode of operation requires that the input plaintext size be a multiple of the block size; if this is not the case, padding must be added to the last input block. Padding techniques, along with possible drawbacks, will be furtherly discussed. The mode of operation is defined as follows: ECB encryption: Cj = CIP Hk (Pj )

Figure 1: ECB encryption.

−1 ECB decryption: Pj = CIP Hk (Pj )

Every block being processed separately, both encryption and decryption can be carried out in parallel on different blocks; this is one of the few advantages, if any, of the ECB mode of operation. Because of this peculiarity of the ECB mode, bit errors in a single ciphertext block only cause the corresponding decrypted block to be incorrect and do not affect other blocks. A 3

Figure 2: ECB decryption. single bit error in a ciphertext block may produce an error in any bit position of the decrypted block, with an expected error rate of 50% (depending, however, on the underlying block cipher). On the other hand, identical plaintext blocks always get encrypted into identical ciphertext blocks. This is a serious weakness of the ECB mode of operation, because it results in data patterns being scarcely hidden. To some extent, message confidentiality is even compromised. An example of how ineffectively data patterns in the plaintext are handled is given in Figure 3.

(a) Original

(b) Encrypted with ECB

Figure 3: ECB maintains data patterns.

Protocols which do not provide integrity protection are also more exposed to replay attacks when the ECB mode is used. The ECB mode is ideal for a short amount of data, such as an encryption key. Thus, if we want to transmit a DES key securely, ECB is the appropriate mode to use.



Cipher Block Chaining (CBC)

To overcome the security deficiencies of ECB, we would like a technique in which the same plaintext block, if repeated, produces different ciphertext blocks. The Cipher Block Chaining (CBC) mode of operation features the combining (hence the word “chaining”) of each plaintext block with the previous ciphertext block by means of XORing. This way our requirement is satisfied. The CBC mode requires an initialization vector (IV), which is combined with the first plaintext block. The IV does not need to be secret, but it must be unpredictable and its integrity must be preserved; the generation of IVs will be discussed later on. Like the ECB mode, the CBC mode requires padding when the plaintext size is not an integer multiple of the block size in use. The mode of operation is the following: CBC encryption: C1 = CIP Hk (P1 ⊕ IV ) Cj = CIP Hk (Pj ⊕ Cj−1 ) for j = 2...n

Figure 4: CBC encryption.
−1 CBC decryption: P1 = CIP Hk (C1 ) ⊕ IV −1 Pj = CIP Hk (Cj ) ⊕ Cj−1 for j = 2...n

In CBC encryption, the input block to each forward cipher operation (but the first one) depends on the previous encrypted block; therefore, it is not possible to perform such operations in parallel. Each CBC decryption operation, however, only takes as inputs ciphertext blocks, thus allowing multiple operations to occur in parallel. For the same reason, random access to the blocks is possible when decrypting.


Figure 5: CBC decryption. Due to block chaining, bit errors in a single ciphertext block cause corruption of the corresponding decrypted block and of its successor. A one-bit change may produce errors in any bit position of the current decrypted block and inverts the corresponding bit in the following block. A specific problem exists concerning the IV. An exposed IV might allow a man-in-the-middle (MITM) to change the IV value in-transit. Changing the IV changes only the deciphered plaintext for the first block, without garbling the second block. Any or all bits of the first block plaintext can be changed systematically with complete control. In marked contrast, when ciphertext is changed in CBC mode, it does change the next block plaintext bit-for-bit, but it also garbles the plaintext for the current block and so is easily detected. An obvious solution to prevent deliberate MITM changes to the first block by altering the IV is to encipher the IV. Another possibility is to use a message number value known to both parties to produce the IV by means of ciphering. Techniques to reset the message number and maintain synchronization would of course be required. We must, however, bear in mind that CBC does not provide integrity, but only confidentiality. If higher assurance of message integrity are required, authentication (which ensures integrity) might be necessary. Propagating Cipher Block Chaining (PCBC) The Propagating Cipher Block Chaining (PCBC) mode is a variant of the CBC mode which was designed to propagate small errors (one-bit errors) in the ciphertext. Encryption and decryption routines are as follows: PCBC encryption: Ci = CIP Hk (Pi ⊕ Pi−1 ⊕ Ci−1 ), P0 ⊕ C0 = IV
−1 PCBC decryption: Pi = CIP Hk (Ci ) ⊕ Pi−1 ⊕ Ci−1 , P0 ⊕ C0 = IV


Since a single-bit error in a cipherblock thus affects all subsequent blocks, the entire message is very likely to be rejected. Whether this is a desirable feature for a mode of operation largely depends on the application. In some cases, a one-bit change may indicate a possible attack; it is therefore most preferrable to discard the entire message. On the other hand, when bit errors are more likely to be introduced by the transmission line, rather than by a malicious user, resilience of the data may be favourable. The PCBC mode of encryption has not been formally published as a federal or national standard, and it does not have widespread general support. It was used in Kerberos v4, but was abandoned starting from version 5 because the exchange of two adjacent blocks does not affect subsequent blocks. As a matter of fact, when Ci and Ci+1 are received in order: Pi
−1 = CIP Hk (Ci ) ⊕ Pi−1 ⊕ Ci−1

Pi+1 = CIP Hk −1(Ci+1 ) ⊕ Pi ⊕ Ci −1 −1 = CIP Hk (Ci+1 ) ⊕ CIP Hk (Ci ) ⊕ Ci ⊕ Ci−1 ⊕ Pi−1
−1 Pi+2 = CIP Hk (Ci+2 ) ⊕ Pi+1 ⊕ Ci+1 −1 −1 −1 = CIP Hk (Ci+2 ) ⊕ CIP Hk (Ci+1 ) ⊕ CIP Hk (Ci ) ⊕ Ci+1 ⊕ Ci ⊕ ⊕Ci−1 ⊕ Pi−1

When Ci and Ci+1 are exchanged: Pi
−1 = CIP Hk (Ci+1 ) ⊕ Pi−1 ⊕ Ci−1

−1 Pi+1 = CIP Hk (Ci ) ⊕ Pi ⊕ Ci+1 −1 −1 = CIP Hk (Ci+1 ) ⊕ CIP Hk (Ci ) ⊕ Ci+1 ⊕ Ci−1 ⊕ Pi−1 −1 Pi+2 = CIP Hk (Ci+2 ) ⊕ Pi+1 ⊕ Ci −1 −1 −1 = CIP Hk (Ci+2 ) ⊕ CIP Hk (Ci+1 ) ⊕ CIP Hk (Ci ) ⊕ Ci+1 ⊕ Ci ⊕ ⊕Ci−1 ⊕ Pi−1

The two expressions for Pi+2 are identical. 1.1.3 Cipher Feedback (CFB)

The Cipher Feedback (CFB) mode of operation turns the underlying block cipher into a stream cipher. A stream cipher is a symmetric cipher where plaintext bits are combined with a pseudorandom cipher bitstream, called 7

a keystream. The CFB mode of operation is very close to the CBC mode. It entails the feedback of ciphertext segments which are ciphered to generate output blocks; the latter are then XORed with the plaintext to produce ciphertext (whereas in the CBC mode the XOR operation precedes the ciphering). For this mode of operation the plaintext size need not be a multiple of the block size. As a matter of fact, a further parameter s, named the segment size, is considered; it can assume any value between 1 and the block size b. The plaintext is thus decomposed into n segments Pj# , which are # encrypted into n ciphertext segments Cj . The algorithm operates as follows: CFB encryption: I1 = IV # Ij = LSBb−s (Ij−1 )||Cj−1 Oj = CIP Hk (Ij ) # Cj = Pj# ⊕ M SBs (Oj ) for j = 2...n for j = 1...n for j = 1...n

Figure 6: CFB encryption. CFB decryption: I1 = IV # Ij = LSBb−s (Ij−1 )||Cj−1 Oj = CIP Hk (Ij ) # Pj# = Cj ⊕ M SBs (Oj )

for j = 2...n for j = 1...n for j = 1...n

In both CFB encryption and decryption, the IV is enciphered to produce the first output block. The s most significant bits of the first output block (of length b) are then XORed with the first plaintext segment, while the b − s least significant bits are discarded. Starting from the second iteration, 8

Figure 7: CFB decryption. the b − s least significant bits of the previous input block are concatenated with the previous ciphertext segment to form the current input block. This operation is equivalent to shifting the previous input block to the left by s positions and replacing the s least significant bits of the result with the last ciphertext segment. In CFB encryption, just like CBC encryption, the input block to each cipher operation depends on the result of the previous one. Although encryption cannot be executed in parallel on multiple blocks, a form of pipelining is possible, since the only encryption step that requires the actual plaintext is the last. This is useful when low latency between the arrival of plaintext and the output of the corresponding ciphertext is required (e.g., in some applications of streaming media). Decryption can be performed in parallel. A further advantage of the CFB mode is that the cipher function is only ever used in the forward direction. The CFB mode of operation relates to bit errors in the opposite way with respect to the CFB mode. A single-bit error in a ciphertext block results in an error in the same bit position of the corresponding decrypted block and may affect the following b/s segments in an unpredictable way. Bit errors in the IV affect, at a minimum, the decryption of the first ciphertext segment and possibly following segments, depending on the position of the rightmost bit error in the IV; in general, a bit error in the i th position (counting from the left) affects the decryption of the first i/s segments. The CFB mode is exposed to the risk of intentional introduction of bit errors in specific bit positions when it is used with an underlying block cipher which does not provide data integrity. Unlike other modes of operation, however, the existence of such errors may be inferred by their randomizing 9

effects on the following ciphertext segments. The insertion or deletion of bits into a ciphertext segment spoils the synchronization of the segment boundaries. The decryption of the subsequent segments will almost certainly be incorrect until synchronization is restored. When the 1-bit CFB mode (i.e., the CFB mode with a segment size of 1 bit) is used, the synchronization is automatically restored after b + 1 segments. For other values of s the synchronization must be restored manually. Attacking the OpenPGP CFB mode The OpenPGP Message Format is a very popular and commonly used format for signing and encrypting data files, particularly for signing and encrypting email. The formats described in the OpenPGP RFC have been implemented in a wide variety of popular freeware and commercial encryption products. Symmetric encryption in OpenPGP is performed using a variant of the standard CFB mode. The main difference with the OpenPGP variant is that a plaintext initialization vector, as described above, is not used, but instead a random block R is encrypted as the first block of ciphertext. Two bytes of R are repeated in the second block in order to quickly check whether the session key K is incorrect upon decryption. This “quick check” is really an integrity check on the key and it is this ad-hoc integrity mechanism, used in a mode of operation that wasn’t designed to accommodate it, that allows the attack. The successful outcome of the attack relies on two assumptions: 1) the first 2 bytes of the first plaintext block can be easily guessed, and 2) an oracle O that, when given a purported ciphertext encrypted using the OpenPGP CFB mode of operation with a given key, will correctly determine whether or not the integrity check was successful is available. Both these assumptions are reasonable. As a matter of fact, compression algorithms are very often used along with the OpenPGP CFB mode; the first 2 bytes of the message are therefore likely to be a known packet tag and a known compression algorithm identifier. This justifies the first assumption. As to the second assumption, mechanisms to inform the end user that the integrity check failed on the encrypted message are very likely to be available on a system implementing the OpenPGP CFB mode. If, however, this should not be the case, timing attacks would always be possible, since the decryption of the message does not start if the integrity check fails. The knowledge of the first 2 bytes of the message enable a malicious user, after an initial setup of about 215 oracle queries, to find out 16 bits of any block with 215 queries for each block. Further details, mathematical proofs, as well as extensive discussion of possible solutions, is given in [4].



Output Feedback (OFB)

The Output Feedback (OFB) mode of operation, just like CFB, converts the underlying block cipher into a stream cipher. It features the iteration of the forward cipher function on an IV to generate keystream blocks, which are combined with the plaintext blocks by means of XORing. The plaintext size is not requested to be an integer multiple of the block size. The last block may be a partial block of size u; in that case, it is XORed with the u most significant bits of the last keystream block to produce the last (partial) ciphertext block. It is defined as follows: OFB encryption: I1 Ij Oj Cj ∗ Cn = IV = Oj−1 = CIP Hk (Ij ) = Pj ⊕ Oj ∗ = Pn ⊕ M SBu (On ) for j = 2...n for j = 1...n for j = 1...n − 1

Figure 8: OFB encryption. OFB decryption: I1 Ij Oj Pj ∗ Pn = IV = Oj−1 = CIP Hk (Ij ) = Cj ⊕ Oj ∗ = Cn ⊕ M SBu (On )

for j = 2...n for j = 1...n for j = 1...n − 1

Both encryption and decryption make use of recurrent ciphering of an IV; this prevents from performing multiple cipher operations at the same time. Nonetheless, if the IV is known, then the keystream blocks can be precomputed, prior to the availability of the plaintext or ciphertext data. 11

Figure 9: OFB decryption. The OFB requires the IV to be a nonce, i.e. that the IV be unique for every message that is encrypted with a given key. When this requirement is not met, the confidentiality of the encrypted message may be compromised. If a plaintext block is known to a malicious user, the latter can easily reconstruct the corresponding keystream block from the ciphertext block. Reusage of the same IV therefore enables the malicious user to gain knowledge of the corresponding block of information by simply XORing the ciphertext block with the keystream block. The same holds when any of the input blocks to the forward cipher is designated as the IV for the encryption of another message under the same key. Bit errors within a ciphertext block only affect the decryption of that block; flipping a bit in the ciphertext produces a flipped bit in the plaintext at the same location. This property is useful, in that it allows many error correcting codes to function normally even when applied before encryption. However, OFB is less resistant to message stream modification attacks. An attacker may in fact systematically change bits of his choosing in every block and correspondingly alter the checksum part of the message in such a way that the modifications will not be detected by an error-correcting code. Conversely, bit errors in the IV affect the decryption of all ciphertext blocks. 1.1.5 Counter (CTR)

As with the OFB mode of operation, the Counter (CTR) mode of operation, also known as Segmented Integer Count (SIC), makes a block into a stream cipher. Keystream blocks are generated by encrypting a sequence of input blocks, named counters. The word “counter” assumes here a broader meaning; it can be any function which is known to produce a sequence of blocks 12

that do not repeat for a long time. An actual counter is the simplest and most popular of such functions. The property that all counter blocks must be different does not apply to a single message: across all of the messages that are encrypted under a given key, counters must be distinct. Given a sequence of counters T1 , T2 , ..., Tn , the CTR mode is defined as follows: CTR encryption: Oj = CIP Hk (Tj ) Cj = Pj ⊕ Oj ∗ ∗ Cn= Pn ⊕ M SBu (On ) for j = 1...n for j = 1...n − 1

Figure 10: CTR encryption. CTR decryption: Oj = CIP Hk (Tj ) Pj = C j ⊕ O j ∗ ∗ Pn = Cn ⊕ M SBu (On ) for j = 1...n for j = 1...n − 1

Figure 11: CTR decryption.


The CTR mode can operate with input plaintexts whose size is not an ∗ integer multiple of the block size b. In that case, the last block Cn will be a partial block. Both CTR encryption and decryption work on counter blocks and plaintext/ciphertext blocks independent from one another; multiple forward cipher functions can thus be performed in parallel, providing greater hardware efficiency than all other modes of operation. The only limitation is the amount of parallelism that can be achieved on a given machine. In addition, the CTR mode provides true random access to any particular ciphertext block. The forward cipher function can also be applied to each of the counters in advance, so that decryption can start as soon as ciphertext blocks are available. A further advantage of the CTR mode is its simpicity, since the cipher algorithm is only needed for encryption, while simple XOR operations are used for decryption. This matters most when the decryption algorithm differs substantially from the encryption algorithm, as it does for AES. In order to ensure the uniqueness of each counter block, two aspects must be taken into account. First, an appropriate incrementing function that generates the counter blocks from any initial counter block must guarantee that counters do not repeat within a given message. Second, the initial counter blocks for every message must be chosen in such a way that counter blocks do not repeat across all messages that are encrypted under a given key. The Standard Incrementing Function The standard incrementing function can apply either to an entire block or to a part of a block. Let m be the number of bits involved in the incrementation. This m-bit string can be regarded as a binary non-negative number x; the incrementing function takes the binary number x and returns x + 1 mod 2m . This way, the uniqueness requirement for the counter blocks is satisfied within a given message of n blocks, provided that n ≤ 2m . Choice of the Initial Counter Blocks Two possible approaches are discussed here. The first approach entails the sequential encryption of all the messages that are ever encrypted under a given key. Any initial block of b bits may be chosen as the initial counter block for the first message. For all successive messages, the initial counter block is obtained by applying the standard incrementing function to the last counter block of the previous message. 14

This approach requires that the total number of blocks, across all messages, be at most 2m ; care should also be taken to ensure the proper sequencing of the messages. A second approach lies in the assignment of a unique identifier (i.e., a nonce) to every message. The nonce is a (b−m)-bit string that is incorporated in every counter block of a given message. To ensure that it is used only once, it should be time-variant or generated with enough random bits to guarantee a probabilistically insignificant chance of collision. The incrementing function is applied to the remaining m bits. The nonce and the actual counter can be subsequently concatenated, added or XORed to produce the unique counter block.


Generation of Initialization Vectors

Four of the modes of operation hereby described (i.e., all but the ECB mode) require an initialization vector. For the CBC and CFB modes, the IV must be unpredictable. This means that, given a plaintext, it must not be possible to predict the IV that will be associated to it in advance of its generation. A method to produce unpredictable IVs is to apply the forward cipher function to a nonce. As an alternative, an unpredictable IV may be obtained by resorting to a FIPS-approved random number generator. The OFB mode does not require the IV to be unpredictable, but it must be unique to the execution of the encryption operation. It can be a nonce or a message number. The same observation applies to the CTR mode, where each of the counter blocks may be regarded as an IV.


Padding-related issues
Padding techniques

For three of the modes of operation formerly described, the input plaintext must be a sequence of complete blocks (for the ECB and CBC modes) or segments (for the CFB mode). If the initial plaintext does not satisfy this property, extra bits must be appended at the end of the last (partial) block or segment to complete it. Two simple ways of padding a message are bit padding and byte padding. A bit padding scheme is described in RFC1321 and was originally used with the DES algorithm. A single set (‘1’) bit is added at the trailing end of the message and then as many reset (‘0’) bits as required are appended. This method can be used to pad blocks of any size, not necessarily an integer 15

number of bytes. For the above padding method, the padding bits can be removed unambiguously, provided that the receiver can determine that the message is indeed padded. In order to ensure that the receiver does not mistakenly remove bits from an unpadded message, the sender may be required to pad every message, even though the last block is already complete. In that case, an entire block of padding is added. Byte padding schemes are defined in a number of official papers. In ANSI X.923 a byte padding scheme is specified for use with blocks whose size is an integer number of bytes. Null bytes are padded and the last byte defines the padding boundaries or the number of padded bytes. ISO 10126 describes a very similar padding scheme which uses random bytes instead of null bytes. In the PKCS7 scheme, defined in RFC3852, the value of each padding byte is the total number of padded bytes (e.g. N bytes are added, each of value N ). Finally, the zero padding scheme pads all bytes with null bytes. Besides incrementing the amount of data to be transmitted, padding may have other outcomes. Padding with random values may be necessary when a regular, known data pattern needs to be sent; this has the side benefit of making some kinds of cryptanalysis more difficult. However, in some circumstances the use of padding may expose the exchange of a message to timing attacks. 1.3.2 Ciphertext stealing (CTS)

In some applications, such as data streaming, or when a number of messages whose sizes do not align to block boundaries need to be transmitted, the use of padding may be inconvenient. Some nifty techniques have been developed to avoid the transmission of extra ciphertext; one of them is ciphertext stealing (CTS). In order to produce ciphertext of the same length as the corresponding plaintext, we must avoid adding extra, unneeded information, such as padding. Block ciphers, however, need entire plaintext blocks to perform encryption. One may at this point decide to pad the incomplete block, encrypt it and discard as many bits of the corresponding ciphertext block as the padding bits, mistakenly judging them unnecessary. This is not so. Since a block cipher is being used, no direct kinship between a bit in the plaintext and the corresponding bit in the ciphertext can be assumed (or else the block cipher would be a stream cipher!) and all bits in the ciphertext are potentially necessary to reconstruct a single bit of plaintext. The CTS technique can be applied to the ECB and CBC modes of operation and provides a 16

workaround to this problem. The goal is achieved at the cost of an increased complexity of the encryption and decryption process. The encryption and decryption algorithms for the ECB mode only are described below. Encryption: 1. En−1 = CIP Hk (Pn−1 )
∗ 2. Cn = M SBm (En−1 )

3. Dn = Pn ||LSBb−m (En−1 ) 4. Cn−1 = CIP Hk (Dn ) Decryption:
−1 1. Dn = CIP Hk (Cn−1 ) ∗ 2. En−1 = Cn ||LSBb−m (Dn )

3. Pn = M SBm (Dn )
−1 4. Pn−1 = CIP Hk (En−1 )

During encryption, all plaintext blocks except the last one are encrypted normally. After the second-to-last block has been encrypted, the m most significant bits are taken to create the last partial ciphertext block. The remaining bits are then appended to the last incomplete plaintext block and the block thus obtained is enciphered to create the second-to-last ciphertext block. This way we transmit as many bits as were in the original message. The receiver normally decrypts all blocks except the last one. The m most significant bits of the plaintext block obtained from the decryption of the second-to-last ciphertext block give the last plaintext block, whereas the remaining b − m bits are concatenated to the last ciphertext block and decrypted, yielding the second-to-last plaintext block. As we can notice, a portion of the second-to-last plaintext block is encrypted twice and some additional bit-wise operations are required. Allowing for even higher complexity when the CBC mode is used, and bearing in mind that really short messages (i.e. messages that fit in less than one full block) can still not be encrypted without padding, the CTS technique is nowadays hardly ever worthwhile. The CBC mode of operation is being largely replaced by the CTR mode, which does not need padding.



Related-mode attacks

Block ciphers are often proposed with several variants, in terms of a different secret key size and corresponding number of rounds. The so called “relatedcipher attack” model refers to a situation in which some ciphers are related, in the sense that they are exactly identical to each other, differing only in the key size and most often also in the total number of rounds. The knowledge that one cipher is being used and the availability of an oracle which provides the forward and inverse cipher functions of a related cipher can be exploited in order to attack the exchange of information enciphered using the first cipher. The concept has then been extended to a larger class of related models, in particular to cipher encryptions with different block cipher modes of operation, but with the underlying block cipher being identical. This new model has been named a “related-mode attack” model. It has been shown that when an adversary has access to an oracle for any one mode of operation (ECB, CBC, CFB, OFB, CTR), then almost all other related cipher modes can be easily attacked. Examples of such attacks are briefly outlined in the following paragraphs. Further examples may be found in [6]. 1.4.1 Exploiting an ECB Oracle to attack the CTR mode

We suppose the attacker has access to an ecnryption-only oracle O under ECB mode and strives to attack another related cipher in the CTR mode. Let Pi and Ci denote, respectively, the current plaintext and ciphertext blocks of the related-cipher mode being attacked, while Pi and Ci denote, respectively, the current plaintext and ciphertext blocks used in the interaction with the oracle O. Having intercepted Ci , the attacker chooses Pi = C0 + i to feed the ECB encryption and hence obtains Ci = CIP Hk (C0 + i). Since Ci = CIP Hk (C0 + i) ⊕ Pi , he can easily compute Pi = Ci ⊕ Ci . In summary, he only needs one chosen plaintext (CP) query encrypted under ECB to obtain the plaintext block corresponding to any ciphertext block encrypted under CTR. 1.4.2 Exploiting a CBC Oracle to attack the CTR mode

The adversary can in a similar way attack the CTR mode having access to a CBC encryption-only oracle. First the adversary queries the encryption oracle with the the plaintext block Pi−1 and gets the ciphertext block Ci−1 . He then chooses Pi = Ci−1 ⊕ (C0 + 1) and queries again the oracle, obtaining Ci = CIP Hk (Ci−1 ⊕ Pi ) = CIP Hk (C0 + 1). This value is directly related to an intermediate value in CTR, since Ci = Pi ⊕ Ci , and enables the attacker 18

to find Pi . On the whole, two CP queries under CBC are required to obtain a block enciphered under CTR.


The CMAC Mode for Authentication

The CMAC is a block cipher-based message authentication code algorithm which may be used to provide assurance of the authenticity and, hence, the integrity of binary data. Its role is analogous to the standard hash functionbased MAC (HMAC) and it may be appropriate for information systems where an approved block cipher is more readily available than an approved hash function. The ancestor of the CMAC mode for authentication is the Cipher Block Chaining MAC (CBC-MAC) algorithm, a block cipher-based algorithm to create MACs that has serious security deficiencies. A first improvement of the CBC-MAC was proposed by Black and Rogaway and submitted to NIST under the name XCBC. Iwata and Kurosawa provided a further refinement, which was initially submitted as the One-Key CBC-MAC (OMAC) and, later, as OMAC1, which included additional security analysis and efficiently reduced the key size of XCBC. CMAC is equivalent to OMAC1. CMAC, like any well-designed MAC algorithm, provides stronger assurance of data integrity than a checksum or an error detecting code. The verification of a checksum or an error detecting code is designed to detect only accidental modifications of the data, while CMAC is designed to detect intentional, unauthorized modifications of the data, as well as accidental modifications.


Cipher Block Chaining MAC (CBC-MAC)

The CMAC mode addresses many of the weaknesses of the original Cipher Block Chaining MAC (CBC-MAC). In order to better understand its mechanism, as well as the attacks to which a message authentication code (MAC) may be exposed, a brief overview of the CBC-MAC, along with its drawbacks, is provided in the following paragraphs.




In the Cipher Block Chaining MAC, the message is encrypted with some underlying block cipher algorithm using the CBC mode of operation and zero IV, so as to create an interdependence between each block and its predecessor. As a consequence, 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. The final ciphertext block is taken as the message authentication code (MAC) for the current message. 2.2.2 Weaknesses

Given a secure underlying block cipher, the CBC-MAC mode for authentication is secure for fixed-length messages (i.e., when the two parties agreed on a message length and any message of a different length will be discarded, as considered inauthentic). However, it is not secure for variable-length messages. An attacker who knows two distinct messages, m and m , with their associated CBC-MACs, t and t , can produce a third message m∗ , whose CBC-MAC will also be t . This is done by simply XORing the first plaintext block of m with t and then chaining m with the thus modified m : m∗ = m [(m1 ⊕ t) m2 ... mq ] As a matter of fact, when the receiver computes the CBC-MAC over the received message m∗ , the first block of m will be XORed with the last ciphertext block of m , which is in fact t . XORing of two identical bit-vectors yields the zero vector, which results, in practice, in computing the CBC-MAC over m only, “undoing” all past history (represented by m ): M ACIV =0 (m∗ )= M ACIV =0 (m [(m1 ⊕ t) m2 ... mq ]) = M ACIV =t ((m1 ⊕ t) m2 ... mq ) = M ACIV =0 (m ) =t The MAC verification will therefore succeed and the message will be mistakenly accepted as authentic. Another security problem of the CBC-MAC arises when the same key is used for CBC encryption and CBC-MAC. Although reuse of a key for different purposes is bad practice in general, in this particular case the mistake may lead to an unparallaled attack.


Suppose a message m = m1 m2 ... mq is encrypted using the CBC mode under the key k, yielding the ciphertext c1 c2 ... cq . We here assume that the IV for the encryption is obtained by forward-ciphering a bit-vector (e.g., a nonce), which we will call m0 . The same key is then used to produce a CBC-MAC t for the IV and the message. An attacker may now change every bit before the last ciphertext block cq , and the MAC will still be valid. This is because t = CIP Hk (mq ⊕cq−1 ) = cq , so as long as the last ciphertext block remains unaltered, the CBC-MAC verification will succeed. This is also the reason why inexperienced users often make such a gross mistake: it allows to encrypt the message and compute its MAC in a single pass, increasing performance by a factor of two. This also shows that the CBC-MAC cannot be used as a collision resistant one-way function: given a key, it is trivial to find a different message which maps to the same MAC.


CMAC Specification
Subkeys generation

The CMAC mode for authentication requires two additional parameters, besides the block cipher key. These parameters, named the subkeys, K1 and K2 , are derived from the block cipher key; they must be kept secret. The subkeys are fixed for any invocation of CMAC under a given key. As a consequence, they do not need to be recomputed anew every time; they may, instead, be calculated once and stored along with the block cipher key. The subkeys are generated as follows: 1. L ← CIP Hk (0b ) 2. if M SB1 (L) = 0 then K1 ← L << 1 else K1 ← (L << 1) ⊕ Rb 3. if M SB1 (K1 ) = 0 then K2 ← K1 << 1 else K2 ← (K1 << 1) ⊕ Rb In step 1, 0b indicates the bit string that consists of b 0s. The value that is obtained from applying the forward cipher function to the zero string must also be kept secret. In step 2 and 3 the parameter Rb appears; this value is a bit string that is completely determined by the block size b. For example, for the AES underlying block cipher the block size is 128 bits and Rb = 0120 10000111; for the other currently approved block cipher, TDEA, the block size is 64 bits and the corresponding value of Rb is 059 11011. Given a block size b, in order to find Rb we must find the lexicographically first among all irreducible 21

polynomials of degree b having the minimum possible number of nonzero terms. If we let that polynomial be ub + cb−1 ub−1 + ... + c2 u2 + c1 u + c0 , then Rb is the bit string cb−1 cb−2 ...c2 c1 c0 . The generation of K1 and K2 is essentially equivalent to multiplication by u and u2 , respectively, within the Galois field that is determined by this polynomial. 2.3.2 CMAC generation

Once the subkeys K1 and K2 have been computed (or retrieved, together with the shared secret K), the CMAC can be generated from the plaintext message. Unlike CBC-MAC, CMAC is secure for variable-length messages. Mathematical proof is provided in [7]. The CMAC is generated as follows: 1. if Mlen = 0 then n ← 1 else n ← Mlen /b
∗ ∗ 2. if Mn is a complete block then Mn ← K1 ⊕ Mn ∗ else Mn ← K2 ⊕ (Mn 10j ), where j = nb − Mlen − 1

3. C0 ← 0b 4. for i ← 1 to n do Ci ← CIP Hk (Ci−1 ⊕ Mi ) 5. T ← M SBTlen (Cn )
∗ The two subkeys K1 and K2 are used to mask the last block Mn . When the latter is a complete block, then it is simply masked with K1 and the sequence of blocks M1 M2 ...Mn is the formatted message. When the last block is incomplete, a padding string is appended to it, composed by a single ‘1’ followed by as many ‘0’s (possibly none) as are necessary to complete the block. The padded block is subsequently masked with K2 , yielding Mn . After the initial formatting, the following step is identical to the CBCMAC algorithm. The final step truncates the last CBC output block according to the MAC length parameter. The formatting of the message does not need to complete for the CBC operations to start. These two processes may occur in parallel.


CMAC verification

After an authorized party has applied the CMAC generation process to the data to be authenticated to produce a MAC, any authorized party can apply the verification process to the received data and the received MAC. Successful verification provides assurance of data authenticity and, hence, of integrity. 22

Figure 12: Two cases of CMAC generation. The verification of the MAC involves two steps. Prior to verification, the received data must be decrypted using the appropriate mode of operation and underlying algorithm. The CMAC algorithm is applied to the decrypted data and a MAC is generated. The result is then compared with the received MAC. Upon successful comparison, the verification process terminates succesfully.


Security issues
Length of the MAC

A parameter that has great incidence on security-related issues is the length of the MAC. Choosing an appropriate length for the MAC may prove fundamental in resisting to guessing attacks. The verification process determines whether an alleged MAC is a valid output of the CMAC generation process applied to the message the MAC came with. If the verification process fails, then the message is undoubtedly inauthentic i.e., it was not produced by an authorized party, and is therefore discarded. Upon successful verification, CMAC provides sufficient assurance that the message is authentic and, hence, was not corrupted in transit. This assurance, however, is not absolute. An attacker might have, for instance, simply guessed the correct MAC for the message. By selecting a MAC at random from the set of all possible bit strings of length Tlen , the attacker has a probability of 1/2Tlen that his or her guess will be correct. As a consequence, using a longer MAC provides better protection against guessing attacks. On the other hand, larger values of Tlen require more storage space and bandwidth, which may not be acceptable for some applications. The attacker might also repeatedly attempt to guess the right MAC, thereby increasing his chances of succeeding in the attack. For that reason, 23

care should be taken to ensure that the maximum number of unsuccessful CMAC verifications on a given system be limited. For most applications, a value of at least 64 bits should provide sufficient protection. Choosing a length that is less than 64 bits should be accompanied by careful pondering of the risks of accepting an inauthentic message as authentic and by restricing the number of unsuccessful attempts. More specific guidance in the choice may be quantified in terms of two parameters: M axInvalids, a limit on the number of times that the verification process may fail before the key is retired, and Risk, the highest acceptable probability for an inauthentic message to pass the verification process. Tlen should then satisfy the following inequality: Tlen ≥ log2 (M axInvalids/Risk) A simple example may be useful to understand the above formula. Suppose we want at most 25% of the messages we receive to be mistakenly accepted as authentic; we also allow only one attempt. The resulting value for Tlen is thus 2 bits. This is correct, since there is a probability of 1/4 that a malicious user can guess the correct MAC out of the 4 possible 2-bit patterns. We now increase the number of attempts to two, always with a risk of 25%. The above equation yields Tlen = 3. As a matter of fact: P[ correct guess ]=P[1st guess correct]+ +P[2nd guess correct |1st guess incorrect] 7 = 1 + 18 8 7 =1 4 2.4.2 Message span of the key

The message span of a given key is the total number of messages to which the CMAC algorithm is applied under the same key. The message span of a key affects the security of the system against attacks that are based on the detection of a pair of distinct messages which lead to the same MAC before its truncation. Such an event is called a collision. An attacker might exploit a collision to append the MAC of a message to a new message whose content may largely differ from the original one. Collisions cannot be utterly avoided, because the number of all possible messages is much higher than the number of all possible MACs. However, collisions should not occur among the messages for which MACs are actually generated with a given key. The probability that at least one collision actually occurs during the lifetime of the key depends on the message span of 24

the key, relative to the block size of the underlying block cipher. For a given block size b, a collision is expected to exist among a set of 2b/2 messages. The message span of a key should therefore be reasonably limited, with respect to the value of the data involved in the exchange. For general-purpose applications, the message span is measured in terms of the total number of messages the same key is used with. When the block size of the underlying block cipher is 128 bits, such as with AES, the message span should be limited to no more than 248 messages; when the block size is 64 bits, as it is the case with TDEA, the limit is 221 messages. For applications which require a higher level of security, the message span is expressed in terms of message blocks. In this case, when the block size of the underlying algorithm is 128 bits, a message span of at most 248 message blocks (222 GB) is recommended; for a block size of 64 bits, the recommended limit is 221 blocks (16 MB). Within these limits, the probability that a collision will occur is proved to be less than 10−9 for a block size of 128 bits and less than 10−6 for a block size of 64 bits. Sometimes the limit for the message span of a given key may be established by restraining the time span during which the key remains in use (i.e., its cryptoperiod). 2.4.3 Protection against replay attacks

The successful verification of the MAC gives assurance that the source of the message executed the MAC generation algorithm. However, this does not ensure that the sender of the message is the actual source that produced it. An attacker may in fact intercept a legitimate message with its MAC, store it and send it at a later time, claiming to be an authorized party. Therefore, the CMAC algorithm does not inherently provide any protection against replay attacks. Such protection must be provided, instead, by the protocol or application that is using the CMAC mode to authenticate its messages by inserting some identifying information at the beginning of the message. For instance, a sequential number, a timestamp, a nonce etc. may be incorporated in each message, in order to make it possible to detect replayed messages, out-ofsequence messages or missing messages.


[1] Morris Dworkin. Recommendation for Block Cipher Modes of Operation. Methods and techniques. NIST Special Publication 800-38A, 2001. [2] Morris Dworkin. Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication. NIST Special Publication 800-38B, 2001. 800-38B.pdf [3] Wikipedia. The free encyclopedia. [4] S. Mister, R. Zuccherato. An Attack on CFB Mode Encryption As Used By OpenPGP [5] W. Stallings. Cryptography and Network Security. Principles and Practices. IV edition, Prentice-Hall, 2005. [6] D. Wang, D. Lin, W. Wu. Related-Mode Attacks on CTR Encryption Mode [7] T. Iwata, K. Kurosawa. OMAC: One-Key CBC MAC


Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.