4 Up votes0 Down votes

2.4K views26 pagesAnd this is the first homework of Alberto Grand for Computer System Security! As the abstract says, a block cipher is a symmetric key cipher which operates on ﬁxed-length 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 conﬁdentiality or authentication.

Feb 21, 2008

© Attribution Non-Commercial (BY-NC)

PDF, TXT or read online from Scribd

And this is the first homework of Alberto Grand for Computer System Security! As the abstract says, a block cipher is a symmetric key cipher which operates on ﬁxed-length 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 conﬁdentiality or authentication.

Attribution Non-Commercial (BY-NC)

2.4K views

And this is the first homework of Alberto Grand for Computer System Security! As the abstract says, a block cipher is a symmetric key cipher which operates on ﬁxed-length 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 conﬁdentiality or authentication.

Attribution Non-Commercial (BY-NC)

- Encryption in Wireless Systems
- Tutorial 2 Solution
- Answer Review Week 4_Suryadin Akbar_1113100.pdf
- Network Security Essentials Applications and Standards 4e ALL Tests SOLUTIONS AT THE END OF FILE
- Real-Time Operating Systems Laboratory Report
- Parallel and Distributed Programming on Low Latency Clusters
- CryptacusNewsletter-September17.pdf
- Chapter 3 Review Questions
- Characterization of Technological Processes
- cryptography-and-network-security
- [slides] Block Cipher Modes of Operation and CMAC for Authentication
- Authentication Function 2: Message Authentication Code
- UNIT_1_ANS
- Seminar on Network Security
- Tutorial 11 Solutions
- etr_237e01p.pdf
- TKIP
- A NEW DNA BASED APPROACH OF GENERATING KEYDEPENDENTMIXCOLUMNS TRANSFORMATION
- Paper 11
- View Conference Program 2010

You are on page 1of 26

and

the CMAC Mode for Authentication

Alberto Grand

December 20, 2007

Abstract

A block cipher is a symmetric key cipher which operates on fixed-

length 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 algo-

rithm that features the use of a symmetric key block cipher algorithm

to provide an information service, such as confidentiality or authenti-

cation. The first part of this article aims at outlining five NIST recom-

mended 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 mes-

sage 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 ap-

proved encryption algorithms.

1

Contents

1 Cipher block modes of operation 3

1.1 Five confidentiality modes of operation . . . . . . . . . . . . . 3

1.1.1 Electronic Codebook (ECB) . . . . . . . . . . . . . . . 3

1.1.2 Cipher Block Chaining (CBC) . . . . . . . . . . . . . . 5

1.1.3 Cipher Feedback (CFB) . . . . . . . . . . . . . . . . . 7

1.1.4 Output Feedback (OFB) . . . . . . . . . . . . . . . . . 11

1.1.5 Counter (CTR) . . . . . . . . . . . . . . . . . . . . . . 12

1.2 Generation of Initialization Vectors . . . . . . . . . . . . . . . 15

1.3 Padding-related issues . . . . . . . . . . . . . . . . . . . . . . 15

1.3.1 Padding techniques . . . . . . . . . . . . . . . . . . . . 15

1.3.2 Ciphertext stealing (CTS) . . . . . . . . . . . . . . . . 16

1.4 Related-mode attacks . . . . . . . . . . . . . . . . . . . . . . . 18

1.4.1 Exploiting an ECB Oracle to attack the CTR mode . . 18

1.4.2 Exploiting a CBC Oracle to attack the CTR mode . . 18

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Cipher Block Chaining MAC (CBC-MAC) . . . . . . . . . . . 19

2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.2 Weaknesses . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3 CMAC Specification . . . . . . . . . . . . . . . . . . . . . . . 21

2.3.1 Subkeys generation . . . . . . . . . . . . . . . . . . . . 21

2.3.2 CMAC generation . . . . . . . . . . . . . . . . . . . . . 22

2.3.3 CMAC verification . . . . . . . . . . . . . . . . . . . . 22

2.4 Security issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.4.1 Length of the MAC . . . . . . . . . . . . . . . . . . . . 23

2.4.2 Message span of the key . . . . . . . . . . . . . . . . . 24

2.4.3 Protection against replay attacks . . . . . . . . . . . . 25

References 26

2

1 Cipher block modes of operation

1.1 Five confidentiality modes of operation

1.1.1 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:

can be carried out in parallel on different blocks; this is one of the few ad-

vantages, 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 cor-

responding 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 posi-

tion 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.

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.

4

1.1.2 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 pre-

vious 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:

Cj = CIP Hk (Pj ⊕ Cj−1 ) for j = 2...n

Pj = CIP Hk−1 (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 opera-

tion, 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.

5

Figure 5: CBC decryption.

Due to block chaining, bit errors in a single ciphertext block cause cor-

ruption 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.

pher 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:

6

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 fed-

eral 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:

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

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

⊕Ci−1 ⊕ Pi−1

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

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

⊕Ci−1 ⊕ Pi−1

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 gener-

ate output blocks; the latter are then XORed with the plaintext to produce

ciphertext (whereas in the CBC mode the XOR operation precedes the ci-

phering). 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 seg-

ment 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 for j = 2...n

Oj = CIP Hk (Ij ) for j = 1...n

Cj# = Pj# ⊕ M SBs (Oj ) for j = 1...n

CFB decryption: I1 = IV

#

Ij = LSBb−s (Ij−1 )||Cj−1 for j = 2...n

Oj = CIP Hk (Ij ) for j = 1...n

Pj# = Cj# ⊕ M SBs (Oj ) for j = 1...n

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 ci-

pher operation depends on the result of the previous one. Although encryp-

tion 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 db/se 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 di/se 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.

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 popu-

lar 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 en-

crypted 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].

10

1.1.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 = IV

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

Oj = CIP Hk (Ij ) for j = 1...n

Cj = Pj ⊕ Oj for j = 1...n − 1

Cn∗ = Pn∗ ⊕ M SBu (On )

OFB decryption: I1 = IV

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

Oj = CIP Hk (Ij ) for j = 1...n

Pj = Cj ⊕ Oj for j = 1...n − 1

Pn∗ = Cn∗ ⊕ M SBu (On )

this prevents from performing multiple cipher operations at the same time.

Nonetheless, if the IV is known, then the keystream blocks can be pre-

computed, 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.

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 mean-

ing; 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:

Cj = Pj ⊕ Oj for j = 1...n − 1

Cn∗= Pn∗ ⊕ M SBu (On )

Pj = C j ⊕ O j for j = 1...n − 1

Pn∗= Cn∗ ⊕ M SBu (On )

13

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 plain-

text/ciphertext blocks independent from one another; multiple forward ci-

pher functions can thus be performed in parallel, providing greater hard-

ware 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.

tion 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 .

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.

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.

1.3.1 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.

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 mis-

takenly 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.

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.

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.

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 correspond-

ing 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, en-

crypt 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 poten-

tially 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:

3. Dn = Pn ||LSBb−m (En−1 )

Decryption:

3. Pn = M SBm (Dn )

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.

crypted twice and some additional bit-wise operations are required. Allow-

ing 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.

17

1.4 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 “related-

cipher 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 oper-

ation, 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].

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 Pi0 and Ci0 denote, respec-

tively, the current plaintext and ciphertext blocks used in the interaction

with the oracle O. Having intercepted Ci , the attacker chooses Pi0 = C0 + i

to feed the ECB encryption and hence obtains Ci0 = CIP Hk (C0 + i). Since

Ci = CIP Hk (C0 + i) ⊕ Pi , he can easily compute Pi = Ci ⊕ Ci0 . 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.

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

0 0

oracle with the the plaintext block Pi−1 and gets the ciphertext block Ci−1 .

0 0

He then chooses Pi = Ci−1 ⊕ (C0 + 1) and queries again the oracle, obtaining

Ci0 = CIP Hk (Ci−1

0

⊕ Pi0 ) = CIP Hk (C0 + 1). This value is directly related to

an intermediate value in CTR, since Ci = Pi ⊕ Ci0 , 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.

2.1 Introduction

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 function-

based 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 refine-

ment, which was initially submitted as the One-Key CBC-MAC (OMAC)

and, later, as OMAC1, which included additional security analysis and effi-

ciently reduced the key size of XCBC. CMAC is equivalent to OMAC1.

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.

The CMAC mode addresses many of the weaknesses of the original Cipher

Block Chaining MAC (CBC-MAC). In order to better understand its mech-

anism, 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.

19

2.2.1 Description

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 authenti-

cation 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 mes-

sages. An attacker who knows two distinct messages, m0 and m00 , with their

associated CBC-MACs, t0 and t00 , can produce a third message m∗ , whose

CBC-MAC will also be t00 . This is done by simply XORing the first plaintext

block of m00 with t0 and then chaining m0 with the thus modified m00 :

As a matter of fact, when the receiver computes the CBC-MAC over the

received message m∗ , the first block of m00 will be XORed with the last ci-

phertext block of m0 , which is in fact t0 . XORing of two identical bit-vectors

yields the zero vector, which results, in practice, in computing the CBC-MAC

over m00 only, “undoing” all past history (represented by m0 ):

= M ACIV =t ((m001 ⊕ t)km002 k...km00q )

= M ACIV =0 (m00 )

= t00

The MAC verification will therefore succeed and the message will be mistak-

enly 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 dif-

ferent purposes is bad practice in general, in this particular case the mistake

may lead to an unparallaled attack.

20

Suppose a message m = m1 km2 k...kmq is encrypted using the CBC mode

under the key k, yielding the ciphertext c1 kc2 k...kcq . 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.

2.3.1 Subkeys generation

The CMAC mode for authentication requires two additional parameters, be-

sides 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 con-

sequence, 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 )

else K1 ← (L << 1) ⊕ Rb

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.

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 ← dMlen /be

2. if Mn∗ is a complete block then Mn ← K1 ⊕ Mn∗

else Mn ← K2 ⊕ (Mn∗ k10j ), 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 CBC-

MAC algorithm. The final step truncates the last CBC output block accord-

ing 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.

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 suc-

cesfully.

2.4.1 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 fun-

damental 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 con-

sequence, 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.

protection. Choosing a length that is less than 64 bits should be accompa-

nied 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 probabil-

ity for an inauthentic message to pass the verification process. Tlen should

then satisfy the following inequality:

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]

= 18 + 17 87

= 14

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 mes-

sages is much higher than the number of all possible MACs. However, col-

lisions should not occur among the messages for which MACs are actually

generated with a given key. The probability that at least one collision ac-

tually 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.

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).

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-of-

sequence messages or missing messages.

25

References

[1] Morris Dworkin. Recommendation for Block Cipher Modes of Operation.

Methods and techniques. NIST Special Publication 800-38A, 2001.

http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

The CMAC Mode for Authentication. NIST Special Publication 800-38B,

2001.

http://csrc.nist.gov/publications/nistpubs/800-38B/SP 800-38B.pdf

http://www.wikipedia.org/

By OpenPGP

http://eprint.iacr.org/2005/033.pdf

tices. IV edition, Prentice-Hall, 2005.

Mode

http://ijns.nchu.edu.tw/contents/ijns-v4-n3/ijns-2007-v4-n3-p282-287.pdf

http://crypt.cis.ibaraki.ac.jp/omac/docs/omac.pdf

26

- Encryption in Wireless SystemsUploaded byNeatStick
- Tutorial 2 SolutionUploaded byrasikalis
- Answer Review Week 4_Suryadin Akbar_1113100.pdfUploaded byHonest Syarof Esabella
- Network Security Essentials Applications and Standards 4e ALL Tests SOLUTIONS AT THE END OF FILEUploaded bya1606209
- CryptacusNewsletter-September17.pdfUploaded byPetrescu Mircea
- Chapter 3 Review QuestionsUploaded byJason Reed
- cryptography-and-network-securityUploaded bysanchamp
- [slides] Block Cipher Modes of Operation and CMAC for AuthenticationUploaded byProject Symphony Collection
- Authentication Function 2: Message Authentication CodeUploaded bylavanyakodidasu
- UNIT_1_ANSUploaded byVikramaditya
- Seminar on Network SecurityUploaded byapi-3735095
- Tutorial 11 SolutionsUploaded byDA Wei Sun
- etr_237e01p.pdfUploaded byMCSESEC
- TKIPUploaded byMohamedSalah
- A NEW DNA BASED APPROACH OF GENERATING KEYDEPENDENTMIXCOLUMNS TRANSFORMATIONUploaded byAIRCC - IJCNC
- Paper 11Uploaded byRakeshconclave

- Real-Time Operating Systems Laboratory ReportUploaded byProject Symphony Collection
- View Conference Program 2010Uploaded byProject Symphony Collection
- Characterization of Technological ProcessesUploaded byProject Symphony Collection
- Parallel and Distributed Programming on Low Latency ClustersUploaded byProject Symphony Collection
- Testing of the Cache Memory in the OpenSPARC T1Uploaded byProject Symphony Collection
- Custom Instruction on FPGA for Viterbi AlgorithmUploaded byProject Symphony Collection
- Telecommunication ElectronicsUploaded byProject Symphony Collection
- [slides] Microprocessor-Based Systems - 48/32-bit division algorithm - flow chartUploaded byProject Symphony Collection
- Radio Frequency Devices - Homework ReportsUploaded byProject Symphony Collection
- [slides] Software Requirements for Safety-Related SystemsUploaded byProject Symphony Collection
- [slides] Parallel and Distributed Computing on Low Latency ClustersUploaded byProject Symphony Collection
- Fault Tolerant Processor Using Hybrid Hardware RedundancyUploaded byProject Symphony Collection
- Intrusion Detection and Prevention SystemsUploaded byProject Symphony Collection
- H.264/AVC intra coding and JPEG 2000 comparisonUploaded byProject Symphony Collection
- Video Multiple Description Coding (MDC)Uploaded byProject Symphony Collection
- Real-Time Operating Systems Homework ReportUploaded byProject Symphony Collection
- Anti-Spam TechniquesUploaded byProject Symphony Collection
- Secure Sockets Layer for Virtual Private NetworksUploaded byProject Symphony Collection
- GLE-MiPS Compiler RequisitesUploaded byProject Symphony Collection
- Porting serial Fortran 77 numerical computation code for OpenMP applicationsUploaded byProject Symphony Collection
- Authenticated Encryption GCM - CCMUploaded byProject Symphony Collection
- Designing a custom DLX processor with Very Long Instruction Word supportUploaded byProject Symphony Collection
- Abusing HTML 5 Structured Client-side StorageUploaded byProject Symphony Collection
- GLE-MiPS Documentation ReportUploaded byProject Symphony Collection
- [slides] OpenSSL - User Manual and Data FormatUploaded byProject Symphony Collection
- [slides] Misra C Software Development StandardUploaded byProject Symphony Collection
- [slides] Block Cipher Modes of Operation and CMAC for AuthenticationUploaded byProject Symphony Collection
- [slides] Authenticated Encryption GCM - CCMUploaded byProject Symphony Collection
- [slides] Microprocessor-Based Systems - 48/32-bit division algorithmUploaded byProject Symphony Collection

- Study Guide Test#3Uploaded byGypsy
- How-To_88_Configuring_pxGrid_in_an_ISE_Distributed_Environment.pdfUploaded byjstr
- Ne7207 Nis Unit 1 Question BankUploaded byalgatesgiri
- Firepower Threat Defense Lab v1Uploaded byAbuzar Gorar
- AN APPROACH OF SUBSTITUTION METHOD BASED ON ASCII CODES IN ENCRYPTION TECHNIQUEUploaded byIJASCSE
- Red Hat Enterprise Linux-7-SELinux Users and Administrators Guide-En-USUploaded byPamela Johnson
- Identikey Server Getting Started GuideUploaded byjviverosPY
- Cns 4 and 5 Unit McqsUploaded bysiddharth
- Cyber Security on AzureUploaded byBheemesh Chowdary
- c831Uploaded byehaunter
- Fortiweb v5.9.0 Administration GuideUploaded byzaeish
- Mona Secure Multi-Owner Data SharingUploaded bynandhaku2
- Michael Chandy's Project.docxUploaded byMichael Manjakunnel
- DIGITAL SIGNATURE CONTROLLER AUTHORITYUploaded bySajanBentennison
- Chap2User ManagementUploaded byArshen Naidu
- Case Studies on Cryptography and SecurityUploaded bynooti
- A Location Based encryption technique and some of its applicationsUploaded byHardik
- Idea CryptUploaded bySyed Hadi Hussain Shah
- assignment cs520 week5 chelsea hittUploaded byapi-374891391
- Cclaves WifiUploaded byvictor
- Journal Hall TicketUploaded bysoujana
- 17.the Three-Tier Security Scheme in Wireless Sensor Networks With Mobile SinksUploaded byDipali Akhare
- IdsUploaded byLeonard Leo
- secret messages in a ping.pdfUploaded byElsa Cristina David
- Course ProjectUploaded bySrinivas Aditya
- Rd-te-r05702-008 Endpoint Security for Industrial Control SystemsUploaded byfharoon1
- Deloitte Global Cyber Executive Briefing-2014Uploaded byowais800
- ch18.pdfUploaded byGyhgy Ewfdew
- Background Guide of UNSCUploaded byArchit Sharma
- DigUploaded byrakeshdwivedi21

## Much more than documents.

Discover everything Scribd has to offer, including books and audiobooks from major publishers.

Cancel anytime.