Authenticated encryption

GCM - CCM

Lorenzo Peraldo, Vittorio Picco

December 20, 2007

Contents

1 Introduction 21.1 Authenticated Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Generic composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Single-Pass combined modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Two-pass combined modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 CCM, Counter with Cipher Block Chaining-Message Authentication Code 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Formatting function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Length of the MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Efficiency and performances of CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Criticism of CCM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.7 A possible attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 GCM, Galois/Counter Mode 113.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 IV and Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.2 IV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.4 Implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Conclusions 19

Bibliography 20

1

Chapter 1

Introduction

1.1 Authenticated Encryption

Authenticated Encryption (AE) is a term used to describe encryption systems which simultaneouslyprotect confidentiality and authenticity (integrity) of communications. These goals have long beenstudied, but they have only recently enjoyed a high level of interest from cryptographers due to thecomplexity of implementing systems for privacy and authentication separately in a single applica-tion. For decades the solution to this problem has been to combine privacy and authentication ina straightforward manner using the so-called ”generic composition”, but recently there have beena number of new construction which achieve this two goals simultaneously, often much faster thangeneric composition solutions.

What we’ll analyze regards authenticated encryption in a symmetric-key model. Thus a single keyK will be chosen randomly and then shared between the sender and the receiver. Once the two partieshave the key, we have to provide them an AE algorithm such that the sender can process a selectedmessage M with the AE algorithm along with the key K (and possibly a nonce N), and then send theresulting output to the receiver. The output of this processing will be a ciphertext C, the nonce N

and a short message authentication tag, T . Then the receiver should be able to recover M using C,N and his copy of the key K, and to verify the authenticity of the received message using the aboveparameters along with the tag T .

To make an AE algorithm good we have many requirements. For example performance, portability,simplicity, parallelizability, freedom from patents and of course security.

This last requirement is maybe the most important one as an AE scheme has two goals, privacyand authenticity,and it won’t serve our needs if it’s not secure. Privacy means that a passive attackerthat views the ciphertext C and the nonce N , cannot read the content of the message M . to achievethis we could make C indistinguishable from a random bit string. Authenticity, instead, means thatan active attacker cannot easily generate a valid ciphertext C, a nonce N and a tag T such that thereceiver will believe it was generated by the authorized sender.

In many applications we do not only encrypt and authenticate our message, but we also need toinclude some additional information A which must be authenticated too. For example in a networkpacket we should encrypt the payload and authenticate both the header and the payload. For thisreason associated data needs to be included as input to the AE schemes. Schemes that allow associateddata are called AEAD (Authenticated Encryption with Associated Data).

One unfortunate aspect of most cryptographic schemes it that we cannot prove that any schememeets the formal goals required of it. We can prove only some things related to security depending onthe type of cryptographic object we analyze. If it is a primitive such as a block cipher, there’s no proofof security possible, so we can just hope for security after showing that none of the known attacks areworking (differential cryptanalysis). For algorithms that are built on top of these primitives we canprove at best that they are as secure as the underlying primitives.

2

1.2 Generic composition

The traditional way to obtain both authenticity and confidentiality was, until recently, to find twowell designed protocols, one for encryption and one for authentication, and then use them in sequence.This is really straightforward and, at least at a first glance, completely safe. Is both the algorithmsare safe, so their combination in sequence would be safe as well.

In general the approach was to choose a strong mode of operations for block ciphers, like CBC,and then to use it with authentication protocols that do not use keyed-hash functions. This kind ofapproach has been proved as wrong, and the best example to show it is the WEP protocol.

Wired Equivalent Privacy protocol is a common choice to protect WiFi networks. It providedauthentication with a simple CRC hash and then used a stream cipher to encrypt the data. Themechanism is very simple and is also very simple to circumvent it.

Another common mistake is to use the same key both for the authentication and encryptionoperations. This a weaker requirement, though, and a smart implementation could reduce a lot therelated security risks.

There are three available choices when using generic composition:

• MAC then Encrypt (MtE): we compute a MAC of the plaintext, add to it and then encrypt thewhole;

• Encrypt then MAC(EtM): we first encrypt the plaintext and then authenticate the resultingciphertext;

• Encrypt and MAC (E&M): we first encrypt the plaintext and then authenticate the plaintextagain.

Some studies has been done on which of these three strategies is the best to achieve authenticatedencryption in the safest way, and the result was that in general Encrypt then MAC is the best choice.Performing such an operation gives the MAC a property called ”strongly unforgeable”, while usingthe other two methods there could be confidentiality problems.

The conclusion of these studies was that EtM can be considered safe if provided of a secureencryption algorithm and of a secure MAC, each using independent keys. MtE and E&M can beconsidered secure if attention is paid on the choice of the combination encryption algorithm-MACcomputation.

In addition of their extremely simplicity, the generic composition methods have the interestingcharacteristic that since the two operation are completely independent, is possible to encrypt only asubset of the total transmitted data. In this way we can add to a message some additional data thatwill not be encrypted and therefore is useful for authentication only.

On the other hand, the obvious drawback of the generic composition is the long time needed toprocess two times the message, with two different keys.

1.3 Single-Pass combined modes

Until 2000 there was no way to obtain authenticated encryption with only a single pass over themessage. Generic composition was the only way to provide AE. In 2000 IAPM has been developed.

If with generic composition we needed to invoke 2 · m times the block cipher (where m is thenumber of blocks in which the plaintext has been splitted), with IAPM we need just m + log(m)invocations. This is because IAPM compute certain values, called the seeds, before the encryption;seeds calculation is used to achieve authentication and needs only log(m) invocations of the encryptionalgorithm.

After the release of IAPM many researchers started to work on their own solution of single-passAE, generally modifying the original structure of IAPM. The researchers understood the power of themodes they were developing, so they all patented their discoveries. This was also their biggest mistake.It has been never verified whether all these patents override each other, even though probably someof them do, because of the hype of that period on single-pass AE. Since now there has never been

3

requests of verifying the possible overrides in court, but the possible users of the proposed methodsare quite afraid that if they choose to implement one of these solutions there could be legal actionsagainst them.

In conclusion, Single-pass combined modes has never been used as a standard in any applicationand furthermore other teams of researchers have quited they work in this field because they couldhave accused of violating some Intellectual Property. Now the interest of researchers has moved inanother direction, the two-pass combined mode.

1.4 Two-pass combined modes

The Intellectual Property problems raised by the Single-pass combined mode had clearly shown thatit was important to find good solutions to the authenticated encryption problems, and that thesesolution should be patent-free.

The two-pass combined modes represent a class of algorithms with performances not so far fromthe single-pass ones, but all with no intellectual property restriction.

The first to be developed was the CCM (which will be explained in the details later), then EAXtried to solve some of the CCM problems, then CWC has been developed to improve EAX and finallyGCM has been created. GCM is probably the best algorithm available now and will also be explainedin all its aspects later.

CCM is not much better than just generic composition, because in fact it uses a standard MACgeneration algorithm (CBC-MAC) and then a standard CTR encryption, but it offers some advantages.The biggest is the use of only a single key to encrypt and generate the MAC. We said that this couldbe a security problems but CCM designers paid a lot of care on this topic and therefore CCM has nowbeen proved as secure. CCM has also become the mandatory mode for the 802.11 wireless networks.

EAX solved some of the CCM problems, in particular the issue of knowing the message lengthin advance and its complicated definition that used some unnatural parametrization. EAX uses amodified CBC-MAC called OMAC, and then the CTR mode of operations.

CWC has been developed because both CCM and EAX can’t be parallelized in hardware, becausethe CBC-MAC (or its variants) is inherently serial and so can’t achieve high throughput. CWCcould operate up to 10Gbit per second. The features of CWC, though, can be exploited in a parallelcomputing environment only, in a normal computer its performances are not any better of the previoustechniques.

GMC is the latest developed algorithm and is the one with the highest performances. It hasbeen developed by one of the researcher of CWC and therefore has been totally devoted to improveCWC performances and to fill its lacks. GMC has been created starting from a modification in themathematical construct that lays at the CWC basis. While CWC operated in a modulo 127 integerenvironment, the GMC makes use of the Galois field mathematics: this apparently abstract choiceallows the implementers to carry out a much much simpler hardware circuit that realizes the hashingfunction. This allow GCM to perform with throughput of more than 10Gbit per second. The onlypossible competitor for GCM is the OCB (that is a single-pass mode), but many reasons (other thanintellectual property) makes GCM a best choice. For example OCB needs two different schemes, onefor encryption and one for decryption, while GCM only needs one.

4

Chapter 2

CCM, Counter with Cipher BlockChaining-Message AuthenticationCode

2.1 Introduction

CCM is a mode of operation for a symmetric key block cipher algorithm. It combines the techniques ofthe Counter (CTR) mode and the Cipher Block Chaining-Message Authentication Code (CBC-MAC)algorithm to provide confidentiality and authenticity of the data.

The Counter mode with CBC-MAC mode is designed to use the Advanced Encryption Standard(AES) block cipher, or any other block cipher with a block size of 128 bits or more, to provideauthentication and encryption using a single key. As the secret key is only one, being this a symmetrickey algorithm, it must be established beforehand and be known only by the two parties involved in thetransmission of the data. For this purpose CCM requires a well-designed key management structure.

CCM is intended for use in a packet environment and thus it can’t be used with stream data. Theplaintext input includes a header, which is authenticated but not encrypted, and a payload, which isboth authenticated and encrypted. Each packet must be an integral number of bytes and must beassigned a unique value, called nonce. The maximum number of packets that can be authenticatedwith the same key is determined by the size of the nonce, which is one of the parameters that mustbe decided when designing the algorithm.

CCM processing expands the packet size by appending an encrypted authentication tag. Successfulverification of this authentication tag provides assurance that the packet originated from a source withaccess to the block cipher key and it also provides assurance that the packet wasn’t altered after thegeneration of the authentication tag. Failed verification of the tag is designed to reveal both accidentaland intentional, unauthorized modifications of the packet.

CCM allows pre-computation of the key stream if the nonce value is known, allowing half of thecomputational load to be pre-processed. This property can be used to improve the efficiency of animplementation. The size of the implementation can be minimized as well, as CCM uses only theforward encryption function of the block cipher and not the inverse function.

CCM mode was designed by Russ Housley, Doug Whiting and Niels Ferguson. At the time CCMmode was developed, Russ Housley was employed by RSA Laboratories.

A minor variation of the CCM, so called CCM*, is used in ZigBee standard. CCM* includes allof the features of CCM and additionally offers encryption-only and integrity-only capabilities.

2.2 Description

CCM consists of two main processes: generation-encryption and decryption-verification. These twoprocesses combine the counter mode encryption and the cipher block chaining-message authenticationcode to compute a MAC to provide authentication.

5

Before the implementation of CCM it is important to have a valid key establishment and keymanagement to ensure the efficiency of the block cipher algorithm used for encryption. The secret keyfor this algorithm must be generated randomly and be shared only by the parties to the informationor the whole cipher algorithm would be useless. Moreover the same key can be used for a maximumnumber of invocations of the cipher block algorithm and this limit should be set to 261.

As we said the CCM combines two cryptographic mechanisms based on this cipher block algo-rithm. The first one is the Counter mode, used for confidentiality, which requires the generation ofa sufficiently long sequence of blocks (counter blocks) that will then be used to encrypt the message.These blocks don’t need to be secret but must be distinct within a single invocation and any otherinvocation of the cipher block algorithm under the same secret key.

The other mechanism used in CCM is CBC-MAC. This method is basically an adaption of thecipher block chaining mode used for authentication. Starting from a zero initialization vector CBCis applied to the data to be authenticated and the last block generated, truncated at an establishedlength, is used as an authentication tag called MAC.

Note that the same key is used both for the CTR and the CBC-MAC.For the generic CCM mode there are two parameter choices. The first one is the size of the

authentication tag M , which involves a trade-off between message expansion and the probability thatan attacker can undetectably modify a message. Valid values for M are 4, 6, 8, 10, 12, 14 and 16bytes. The second choices is on parameter L, the size of the length field, which requires a trade-offbetween the maximum message size and the size of the nonce. Therefore the length of the messagewe want to encrypt and authenticate must be defined beforehand.

Generation-encryption

To authenticate and encrypt the message we need the following input information:

• an encryption key K for the block cipher;

• a nonce N ;

• the message, also called payload P , of length determined by the choice of the parameter L;

• additional authenticated associated data A, used to authenticate plaintext packet headers, orother information about the message.

CCM produces as output the ciphertext C.The first step for authentication is to generate the authentication tag M . This is done using

CBC-MAC. First a formatting function is applied to 3 of the inputs, the payload, the associated dataand the nonce, to produce blocks B0, B1, ..., Bn. These blocks provide the input for the CBC-MACfunction that generates the MAC we need using the key K for the cipher block chaining.

Then we need to perform encryption. Once we have the authentication tag M, the Counter modeis applied to generate the counter blocks CTR0, CTR1, ..., CTRm. Thanks to these blocks we canencrypt the message by XORing the various octets of the payload with the blocks CTR1, ..., CTRm.CTR0 is instead XORed with the authentication tag M to generate an authentication value.

The final output of the generation-encryption process is the ciphertext C which consists of theencrypted payload followed by the encrypted authentication value computed before. This is the detailof the steps needed for generation-encryption:

1. Apply the formatting function to (N,A,P ) to produce the blocks B0, B1, ..., Br ;

2. Set Y0 = CIPHK(B0);

3. For i = 1 to r, do Yi = CIPHK(Bi ⊕ Yi − 1);

4. Set T = MSBT len(Yr);

5. Apply the counter generation function to generate the counter blocks Ctr0, Ctr1, ..., Ctrm;

6

6. For j = 0 to m, do Sj = CIPHK(Ctrj);

7. Set S = S1‖S2‖...‖Sm;

8. Return C = (P⊕ MSBP len(S))‖(T⊕ MSBT len(S0)).

Decryption-verification

For the process of decryption and the verification of authenticity and integrity we need the followinginformation:

• the received ciphertext C;

• the associated data A;

• the nonce N ;

• the cipher key K.

As an output this process produces our message in plaintext or INVALID if the verification fails.First of all the counter mode decryption is applied to the received ciphertext with the key K to

produce the payload and the associated authentication tag (MAC). Then the nonce, the associateddata and the computed payload are formatted according to the formatting function in order to produceblocks for the CBC-MAC mechanism. This is applied to recomputed the MAC and compare it withthe received one in order to verify it. If this is not verified then the decryption-verification functionreturns the error message INVALID, else it gives as output the payload.

To provide higher security, when an INVALID message is returned, the payload P and the MACshould not be revealed and the implementation should ensure a third party not to be able to distinguishwhat step the error message results from. This is the detail of the steps needed for decryption-verification:

1. If Clen ≤ T len, then return INVALID;

2. Apply the counter generation function to generate the counter blocks Ctr0, Ctr1, ..., Ctrm;

3. For j = 0 to m, do Sj = CIPHK(Ctrj);

4. Set S = S1‖S2‖...‖Sm;

5. Set P = MSBClen−T len(C)⊕ MSBClen−T len(S);

6. Set T = LSBT len(C)⊕ MSBT len(S0);

7. If N , A, or P is not valid, then return INVALID, else apply the formatting function to (N,A,P )to produce the blocks B0, B1, ..., Br;

8. Set Y0 = CIPHK(B0);

9. For i = 1 to r, do Yj = CIPHK(Bi ⊕ Yi−1);

10. If T 6= MSBT len(Yr), then return INVALID, else return P .

2.3 Formatting function

The blocks B0, B1, ..., Bn used by the CBC-MAC mechanism are generated by a formatting functionthat acts on the nonce, the payload and the associated data. The value of n depends on this formattingfunction. This formatting function must hold the following properties for any key used:

• the first block B0 uniquely determines the nonce N ;

7

• the formatting data uniquely determines the payload P and the associated data A;

• the first block B0 is distinct from any counter blocks used across all the invocations of CCMunder a given key; this means that the formatting function and the counter generation functionshould not be constructed independently.

The formatting function also defines which values (bit lengths) of payload, associated data, nonceand authentication tag are valid. In fact the formatting function imposes some restriction on theseparameters that must be respected.

The bit lengths of N , A and P must be multiple of 8 bits and the same is for the authenticationtag. The first block of the formatted data represents the binary representation of the length of thepayload. The length of this block can be called q and it’s a parameter of the formatting function wehave to define. Therefore q determines the maximum length of the payload so that p < 28q. Thevalue of q also determines the length of the nonce n, because the sum q + n must be constant. Thuswe’ll have a trade-off between the maximum number of invocations of CCM under a given key andthe maximum length of the payload for these invocations.

Formatted input data

The formatted data, in the form of blocks B0, B1, ..., Bn, must be well defined. The first block B0

contains a byte dedicated to four flags, the nonce and the binary representation of the message lengthas we said before.

The four flag are the following: the first bit is Reserved and the second is for Adata; then follow2 strings of 3 bits which contain the encoded values of t and q.

Byte number 0 1...15 − q 16 − q...15

Contents Flags N Q

Table 2.1: Formatting of B0

If the Adata field is 0 then there’s no associated data, else the associated data is formatted in thisway: the associated data length a is encoded and the encoding is concatenated with the associateddata A, followed by the minimum number of 0 needed so that the resulting string can be partitionedinto 16 bytes blocks B1, ..., Bm, where m depends on the associated data length a.

Depending on the value of a, it can be encoded into 2, 6 or 10 bytes.The last n−m blocks Bm+1, Bm+2, ..., Bn represent the payload followed by the minimum number

of 0 such that this string can be partitioned into 16bytes blocks.Not only the input data must be formatted, but also the counter blocks used in the CTR mode

need to be formatted in the following way:

Byte number 0 1...15 − q 16 − q...15

Contents Flags N [i]8q

Table 2.2: Formatting of CTRi

Each block CTRi contains the nonce N , the encoding of the index i and a field with flags. Thefirst 2 bits of these flags are reserved for future use; these are followed by 3 bits set to 0 to ensure thatall the counter blocks are different from B0 and the last 3 bits contain the encoding of q as in B0.

2.4 Length of the MAC

The length of the MAC is one of the most important security parameters within CCM.During the decryption-verification process we determine whether the purported ciphertext is a

valid ciphertext, which means that it’s been generated by a generation-encryption process with access

8

to the secret key, the nonce and the associated data, or not. The assurance of authentication ofCCM is based on the scarcity of ciphertext. This means that an attacker without the key or withno access to the generation-encryption process cannot generate a ciphertext easily and therefore ifa ciphertext passes the decryption-verification process it’s very likely to be a valid and legitimatelygenerated ciphertext.

The first thing we verify in a purported ciphertext is that it’s length is at least equal to the lengthof the authentication tag (MAC), which we’ll call Tlen. The decryption-verification process comparesthe MAC decrypted from the ciphertext with the MAC computed for the received payload, the nonceand the associated data. If the MACs are equal then the result is positive and the process outputsthe payload, else the output will be the error message INVALID. In this case one between the payloadand the associated data is not authentic. If the result is positive and we get the payload then boththe payload and associated data are authentic, but this assurance cannot be absolute as an attackercould still have a small probability to generate a valid ciphertext. This probability depends on Tlen

and in particular it is less than 2−T len. As an attacker could present many ciphertexts to increase thisprobability or intercept a valid ciphertext and replay it, the receiver should have proper controllingprotocols.

So we could state that the larger Tlen we choose, the greater authentication we assure, but wemust beware of the trade-off that the choice of Tlen implies. In fact larger values of Tlen require morebandwidth for the ciphertext and this could not always be available for some connections.

To ensure a good security n low risks we should always choose a value of Tlen greater than 64. asmaller value for Tlen could be chosen for example for low bandwidth connections where there’s notthe possibility to attempt many trials. We can say that Tlen should satisfy the following inequality:

Tlen > lg

(

MaxErrs

Risk

)

Where Risk is the highest acceptable probability for an inauthentic message to pass the decryption-verification process, and MaxErrs is the number of times that the output can be the error messageINVALID before the key is retired.

To preserve security, implementations need to limit the total amount of data that is encrypted witha single key; the total number of block cipher encryption operations in the CBC-MAC and encryptiontogether cannot exceed 261. (This allows nearly 264 octets to be encrypted and authenticated usingCCM. This is roughly 16 million terabytes, which should be more than enough for most applications).

In an environment where this limit might be reached, the sender must ensure that the total numberof block cipher encryption operations in the CBC-MAC and encryption together does not exceed 261.Receivers that do not expect to decrypt the same message twice may also check this limit.

2.5 Efficiency and performances of CCM

Performances depend on the speed of the block cipher implementation. In hardware, for large packets,the speed achievable for CCM is roughly the same as that achievable with the CBC encryption mode.

Encrypting and authenticating an empty message, without any additional authentication data,requires two block cipher encryption operations. For each block of additional authenticated data oneadditional block cipher operation is required. Each message block requires two block cipher encryptionoperations. The worst-case situation is when both the message and the additional authentication dataare a single octet. In this case, CCM requires five block cipher encryption operations.

Both CCM encryption and CCM decryption operations require only the block cipher encryptionfunction. In AES, the encryption and decryption algorithms have some significant differences. Thus,using only the forward encrypt operation can lead to a significant saving in code size and hardwareimplementation and size.

In hardware, CCM can compute the message authentication code and perform encryption in asingle pass. This means that the implementation doesn’t have to wait for the calculation of the MACto be completed to start the encryption. Thus there is a good advantage in the speed of this algorithm.

9

CCM was designed for use in a packet processing environment. The authentication processingrequires the message length to be known in advance, which makes one-pass processing difficult insome environments. However, in almost all environments message or packets lengths are well knownso we don’t have this problem.

2.6 Criticism of CCM

There are several problems regarding different aspects of CCM that have been analyzed.In terms of efficiency the first problem with CCM is that it doesn’t work on-line. This means that

it can’t work on a stream of data as we’ve already said but must have the input data n needs to knowthe length of the message before starting the process. On the other hand it’s true that CCM is oftenused in environments where packet length are well known even if in many context we can’t know thelength of the message we’re handling until it’s finished.

Length-prepend annotation also causes another problem for the associated data: CCM disrupts itsword-alignment. This problem may cause significant losses in the performances, as modern machinesperform operations much more efficiently when pointers into memory fall along word-boundaries. Thiscan’t be done when we prepend the length-annotation to the associated data. This problem becomesmore relevant when the associated data is long, but we usually expect the associated data to be justa few bytes.

Another problem related to the associated data comes from the fact that CCM can’t pre-processstatic associated data. This would be very useful in contexts where the associated data is the sameduring a whole communication session so that we could process it once for all in order to reduce thetime needed for encryption and decryption. This cannot be done because the algorithm encodes thenonce and the message length before the associated data rather than after it.

Parametrization of CCM is another aspect that is often criticized. The main points of this criticisminclude the fact that a trade-off between the length of the nonce and the message length, induced bythe choice the user has to do before using CCM, is apparently without any sense as the two parametershave nothing to do with each other. Furthermore byte orientation of CCM, as it’s defined only onoctet strings, could be seen as a limit for this mode of operation.

2.7 A possible attack

A common slogan in the design of Internet protocols is ”be conservative in what you send, and liberalin what you accept”. Imagine a CCM implementation respecting this slogan literally; the senderalways send 16-byte tags messages, but the receiver accept messages with valid tags of any permittedlength. An attacker could choose to create 4-byte tags and generate a valid ciphertext after 232 tries.However this attack could be of limited value as it’s a blind forgery and the attacker couldn’t controlwhether the message is accepted or not.

Another possible scenario is the same: a smarter attacker can fully control what message therecipient will accept. This happens because the transmitted ciphertext has the form of C ‖ T whereT is the authentication tag (MAC) and the received message M is computed as a function of C.the direct forgery attack can be performed as follows if an attacker intercepts a valid ciphertext for amessage M . The attacker may want to flip certain bits positions in M and then generate 232 ciphertextin the form M ′ ‖ T ′ where M ′ is obtained XORing M with the difference the attacker decides to flipsome bits, and T ′ varies over all 4-byte values. One of these ciphertext will be accepted as a validencryption of M ′. Thus an attacker can forge any message with 232 trials, given a single ciphertextthat was authenticated with a 128-bit tag.

One possible countermeasure to this kind of attack would be to fix the tag length parameter atkey-negotiation time so that only sender and receiver know it. In this way the recipient will acceptonly one value of the tag length, in order to avoid the direct forgery attack, and won’t accept a newtag length until the end of the session.

10

Chapter 3

GCM, Galois/Counter Mode

3.1 Introduction

The GCM is a mode of operation for block ciphers, that provides authenticated encryption. It makesuse of the finite fields mathematics (Galois fields) to provide authentication and uses the CTR modeof operation for the AES cipher to provide encryption.

The GCM has been developed to meet the growing need of fast algorithms, capable of handling thefastest and fastest networks speed. In the era of Gigabit networks, a reliable and fast authenticatedencryption algorithm is desired: the encryption is usually a fast operation, that can be realized in manyways, and many protocols provide efficient encryption techniques; many of them can be implementedin software and in hardware, make the most of pipelining and parallelization. The real bottleneck isthe authentication part. Although many algorithms provide authentication, almost none can keep upthe pace of Gigabit links, and in fact a standard doesn’t exist.

GCM is an authenticated encryption mode of operation that can be realized both in softwareand hardware, can be pipelined and work in a multiprocessor environment, and is free of intellectualproperty restrictions, thus is a perfect candidate to fill the emerging need.

The Galois Counter Mode is based on the CTR, but adds a MAC, computed with operations in aGalois field. This choice has been made because the operation of multiplication is extremely easy toperform within such a field. It only involves basic operations that can be implemented in hardware.The function that computes the MAC is called GHASH and it produces a tag; this tag is sent withthe ciphertext and must be verified by the recipient in order to authenticate the message. One of themost interesting features of the GCM is that the function GHASH doesn’t need to be applied to anencrypted text, but it can be used alone, only to provide authentication: in this case the algorithm iscalled GMAC. What is remarkable is that if one changes a few bits of the plaintext and then computethe MAC again, the computational effort needed is proportional to the number of bits changed.

Another useful characteristic of GCM, that makes it particularly attractive, is that it needs anInitialization Vector (IV), but this vector does not have a fixed length, it can be arbitrary. Since theIV is often a nonce, any available nonce can be used, spreading the field of application of the GCM.

GCM has been designed to be used with AES, in particular AES-128, that is a common choice formany applications. In any case the 128 bit is just a suggestion, the Galois Counter Mode can be usedwith other lengths. The key used for encryption and to generate the MAC is the same: this choicesimplifies the operation of key distribution.

3.2 Description

GCM has two main functions, called authenticated encryption and authenticated decryption. We’regoing to analyze them separately, even though they are almost identical.

Authenticated encryption

This function needs 4 inputs:

11

• the plaintext, called P ;

• the secret key, called K;

• the initialization vector, IV ;

• the additional authentication data, shortly AAD, indicated with A in the formulas.

The output produced are only 2:

• the ciphertext, called C;

• an authentication tag, called T .

We will now describe how this algorithm works, providing also other information on the input andoutput data. We assume to use the AES-128 as the underlying encryption cipher but as we’ve alreadysaid, the size of the cipher is not important.

The authenticated encryption function acts on two different levels: one for encryption and one forauthentication. Let’s consider encryption first.

The plaintext length can be up to 239 − 256 bits, that is about 64 gigabytes of data. The plaintextis encrypted with the key K, whose length is appropriate to cipher one, in our case 128 bits. To startthe encryption the initialization vector IV must be provided; IV can be of any length but the bestchoice is 12 bytes (96 bits), because in this case the algorithm is optimized; for applications whereefficiency is a must, this length should be chosen.

The input data are organized in this way. The plaintext is divided in sub-blocks of 128 bits (orthe given cypher block size). At the end there are n blocks of 128 bits and a last block composed ofthe remaining bits, that are not enough to form a 128 bits block.

Here is the encryption algorithm:

1. H = E(K, 0128);

2. Y0 =

{

IV ‖ 0311 if len(IV ) = 96GHASH(H, {}, IV ) otherwise

;

3. Yi = incr(Yi − 1) for i = 1, ..., n;

4. Ci = Pi ⊕ E(K,Yi) for i = 1, ..., n − 1;

5. C∗

n = P ∗

n⊕ MSBu(E(K,Yn));

6. T = MSBt(GHASH(H,A,C) ⊕ E(K,Y0)).

Y is the counter of the CTR, that is initialized to the IV (padded with 31 zeros and 1 one). If IV

is not 96 bits long a GHASH operation is performed to reduce (or expand) it to the 128 bits standardlength. This is the reason why it’s suggested to use a 12 byte IV in efficiency-bounded applications:in this way the IV is used as-it-is and no GHASH operation must be performed. We will return lateron the GHASH functioning.

The value of the counter is then encrypted with the key and the result is XORed with the firstblock of data. Then the counter is increased by one. This operation is done modulo 232, that is nomore than saying that every time the counter reaches the value 232 is then set to zero. The new valueof the counter is encrypted and XORed with the next data block and so on. For the last data blockthe operations are the same but only the most significant bits are considered.

At the end we have n ciphertext blocks, each of them corresponding to a plaintext block. Theblocks can be assembled and sent, or sent separately, possibly with sequence number to allow therecipient to reconstruct the original message. The choice of adopting the CTR mode of operationmakes possible to treat each ciphertext block separately, so that the decryption operations can bepipelined in hardware to maximize the throughput.

12

Now the authentication part. To authenticate the data of the plaintext a MAC is used. ThisMessage Authentication Code is computed using the GHASH function. We’re not going to describe indetail the definition of this function but we will only outline its main features. The GHASH is basedon two basic operations easy to implement in hardware: the XOR and the multiplication in a Galoisfield. The GHASH needs 3 inputs:

• the encrypted all zeros string, aka the hash sub-key, called H;

• the authenticated data A, up to 264 bits;

• the ciphertext block C.

The hashing function computes many different XOR and multiplications in GF (2128). The outputis a 128 bit string, but this string is not immediately the authentication tag T , it is the base to computeit. T is computed using this string and the ciphertext, taking only a certain number of bits of theoutput to allow the user choose the level of security of the tag.

Since the output of the GHASH is a 128 bit string it’s natural to use it to resize a non-128 bits IV.In this case the input data of the function are not the same of the previous case, the authenticateddata is replaced by an empty string and the ciphertext is replaced with the IV. Since the ciphertexthas got the same length of the plaintext that can be from 0 to 239 − 256 bits, this is also the possiblesize of the IV.

Authenticated decryption

This function needs 5 inputs:

• the secret key, called K;

• the initialization vector, IV ;

• the ciphertext, called C;

• the additional authentication data, shortly AAD, indicated with A;

• the authentication tag, called T ;

At the output we obtain only 1 item:

• the plaintext P or the FAIL special symbol if anything in the authenticated decryption goeswrong.

How does it work? It performs exactly the same operations of the encryption, with the exceptionthat the hash function is done before the encryption. This is possible because the ciphertext is obtainedXORing the encrypted counter value with the plaintext. The XOR is the inverse operation of itself soafter receiving the encrypted data if sufficient to encrypt the local counter (that must start with thesame value of the encryption algorithm, the IV ) and XOR it with the received ciphertext.

This is the procedure:

1. H = E(K, 0128);

2. Y0 =

{

IV ‖ 0311 if len(IV ) = 96GHASH(H, {}, IV ) otherwise

;

3. T ′ = MSBt(GHASH(H,A,C) ⊕ E(K,Y0)).

4. Yi = incr(Yi − 1) for i = 1, ..., n;

5. Pi = Ci ⊕ E(K,Yi) for i = 1, ..., n;

6. P ∗

n = C∗

n⊕ MSBu(E(K,Yn));

T ′ is compared to the T received with the ciphertext; if the two values match then the messageis authentic and decryption is performed, otherwise the FAIL symbol is produced and the procedureaborted.

13

GMAC

The GMAC is the name given to the Galois Counter Mode of operation in the case only authenticationis needed. This could be done for many reasons, the simplest of which is that there could not be theinterest in encrypting the data but only in their authentication; another case is that we only want totake advantage of the speed of the GMAC algorithm with small plaintexts.

To explain the latter we have to make a few considerations on the context where GCM couldbe applied. We have seen that the authenticated encryption function encrypts the plaintext P only,and not the additional data A, that is passed to the GHASH function to compute a hash, but isnever being encrypted by the encryption function E. In conclusion we have two kinds of data: theplaintext (encrypted and authenticated) and the additional data (only authenticated). There are alot of applications that could take advantage of this characteristic and one of the most important ispacket routing over a network.

The header of a, for example, IP packet, carries a lot of information that is needed to routers toforward the packet in a direction rather than another. If these data are encrypted routing can’t bedone easily. On the contrary, using GCM, is possible to encrypt the payload of the packets and let inclear text the header. Moreover, if we just want to authenticate the packets but not encrypt them wecan apply the GMAC function only.

It is very interesting to know of what the Internet traffic is made of. Some studies have been doneon this topic and they all lead to the same, and quite surprising, conclusion. First of all, TCP packetsrepresent almost 90% of the Internet traffic. The surprising part is that almost 60% of the worldwideInternet traffic is made of packets smaller or equal to 44 bytes! This is due to the very low size butthe very frequent use of ACK or SYN packets, that are very small. An analysis of GCM/GMACperformances compared to other similar authenticated encryption techniques shows that it is the bestperforming mode of operations in the Internet environment.

3.3 IV and Keys

The initialization vector and the symmetric key are two of the most critical elements of this mode ofoperation. If not used properly they can compromise the security offered by GCM. We will analyzethem separately.

There is a very important constraint in choosing the IV and the key, that is strongly stated inthe official NIST publication. The document refer to the following principle as the ”uniqueness”requirement:

The probability that the authenticated encryption function ever will be invoked with thesame IV and the same key on two (or more) distinct sets of input data shall be no greaterthan 2−32.

This limitation is obviously imposed to achieve a high security level, and must be obeyed in allGCM implementations.

3.3.1 Keys

First of all, the key. In symmetric encryption ciphers, the key is the most important element, asstated in the Kerchoff’s principles. It has no importance keeping the algorithm secret if the key arenot handled in a safe way, and, moreover, the security of the cipher relies entirely on the key.

The official Recommendation, though, is not giving any indication on how to create and to dis-tribute the keys; it only says that a given key should be ”fresh” and that the mechanism of creatingthe keys should resist to attacks and tampering. In addition, no method is specified for key distri-bution, so an implementation of GCM should carefully take into account this aspects, and choose aproper way to create and distribute the keys, otherwise the security of the system would be seriouslyimpaired.

14

3.3.2 IV

About the IVs, the recommendation is more strict. It specifies two frameworks to create the initial-ization vectors, one deterministic and the other based on random number generator. We’re not goingto enter in the details of these two methods, but we will only describe them briefly, to highlight themain differences. We will refer to the two frameworks respectively as the deterministic-based and theRBG-based (RBG stands for Random Bit Generator).

Both the systems does not specify the length of the IV, that is arbitrary, and treat the IV as thecomposition of two fields, but their logical meaning is different in the two cases.

In the deterministic-based construction the first part is called fixed field, the second one the invo-cation field. Each device in the network has got a unique fixed field and every time the authenticatedencryption function is called, the invocation field is incremented, to guarantee that no ciphertext arecreated using the same IV in a reasonable amount of time.

In the RBG-based construction the two fields are called the random field and the free field. Therecommendation is that the random field is at least 96 bits, while the free field could be 0 bits long.The random field can be either a real random number generated in a secure way, or the increment ofa previous random number. The free field can assume the value of any number that we like, but thesuggestion is that is 0, so that the IV is a completely random number.

Doesn’t matter which method is used, we cannot generate infinite IVs always using the same key,otherwise we won’t met the requirement expressed in the Recommendation. No more than 232 IVscan be used with the same key, but in general the number of IVs used depends on the length of thekey and on the number of devices implementing the GCM. The value 232 is valid only if there are only2 devices using a 128 bits long key. In other cases, that make use of shorter keys or with a highernumber of devices, a fewer initialization vectors can be used before changing the key.

In any case the Recommendation states clearly that the probability of using the algorithm withthe same key and IV must be lower than 2−32, otherwise a high security level is not guaranteed.

3.4 Implementations

We have seen that GCM can be implemented both in hardware and software, so we’re going to takea brief look to these implementations, in particular for the hardware one.

Software

For what relates to software implementations we are just going to show that there are 2 directlyproportional variables: the memory occupation and the amount of computation. We consider theGHASH function only because it is the only real operation needed to keep into account: the otheroperations are XORs, increments (both performed in 1 clock cycle), and the encryption (that dependson the underlying block cipher, AES, and not on the GCM structure).

The GHASH operation that costs more in term of time (apart from the encryption) is the multi-plication over the Galois field. This operation, though, has got an interesting property: it is linear inthe bits of one of the factors. For example, if we want to compute H ·X, where H is the encrypted nullvector and X an arbitrary bit string, the operation is linear in the bits of X. This means that given avalue of H, is possible to construct a table with the result of certain values of the multiplication anduse them as a basis to compute the final result.

It can be shown that considering the string X (128 bits) split in 16 parts, each 8 bits long, theoperation H ·X can be performed storing a table of intermediate results 65,536 bytes large. This tablemust be computed every time a certain key is going to be used, computing the value H and then allthe table entries. If we want to save memory we can consider X as split in 32 parts, each 16 bits long,and in this case the needed table is only 8,192 bytes large.

In table 3.1 is shown the amount of memory needed and the correspondent throughput expressedin cycles per byte.

15

Method Storage requirement Throughput

Simple, 8-bit tables 65,535 bytes/key 13.1

Simple, 4-bit tables 8,192 bytes/key 17.3

Shoup’s, 8-bit tables 1024 bytes + 4096 bytes/key 32.1

Shoup’s, 4-bit tables 64 bytes + 256 bytes/key 69.3

No tables 16 bytes/key 119

Table 3.1: Throughput of GHASH on a Motorola G4 processor

Hardware

One of the design goals of GCM was the efficiency and the possibility to be implemented in hardwarein a simple way, to allow GCM deal with authenticated encryption over Gigabit networks. The choiceof a hardware implementation is the only possible in such an environment, but it also a very goodchoice in other cases where the speed factor is not so relevant.

A possible and straightforward implementation is the one represented in figure 3.1

Figure 3.1: GCM basic hardware implementation scheme

The function requires 4 inputs: the IV, the additional data AAD, the plaintext and the key, that isnot explicitly represented in the figure. The rhomboids represent the point where data are switched.The left part of the diagram is the part devoted to authentication, while the right part is the oneperforming encryption.

At the very first cycle the IV is incremented and then sent to the encryption block (this blockitself can be realized in hardware in many ways, but here we’re looking at it as a black box, sincethe explanation must be architectural independent). Now the data are sent to the left part of thediagram, to the XOR operation, and here they wait for the other data to be computed.

The left part takes as input the AAD, performs the multiplication with H (remember, H is the

16

encrypted null vector) and sends the result to the XOR block where the data just computed arewaiting. Note that this operation can be done in parallel to the first one.

Now the first cycle is done and the switches are toggled. The IV is incremented and encryptedagain, but this time the result is sent to the right part and XORed with the first block of plaintextwaiting. This time the encrypted data block is sent to the multiplication block instead of the AAD,that will no longer be used. The operations go on until the plaintext is finished, and at the output wereceive the plaintext and the authentication tag.

There are some very interesting considerations to do on this scheme.The first thing is that if we look at figure 1 we see that the two parts of the scheme, the two

pipelines, are independent except for the tag creation part. If we can build two distinct encryptionblock, performing the AES operations, we could completely split the two pipelines, so that they couldrun completely in parallel.

The second observation is about the multiplying block. This part must perform the operation inGF (2128), or, generally speaking, in GF (2q) (remember that to achieve the top speed, the 128 bit ciphershould be chosen). The multiplication in such a field can be realized in hardware in many ways, eachwith different requirements in terms of area occupation and time to compute the result. The fact is thata parallel multiplier can do the operation in just 1 clock cycle, with an area occupation proportionalto q2. In any case the area of this multiplier would be at maximum about 30% of the area needed bythe AES encryption block, so it doesn’t affect a lot the total occupation. Only in applications wherearea occupation is very strongly limited we should consider other implementations of the multiplier,noting that all other solutions need an area and a time to provide the result proportional to q.

3.5 Security

To analyze GCM security, it’s necessary to introduce a lot of mathematics. This is not the goal ofthis text, so we just briefly report the lines to follow to achieve the result.

Consider this experiment. We have what is called a permutation oracle that act in this way: it is ablack box that gives as output a bit string; sometimes the bit string is a completely random sequenceand sometimes it is a pseudo-random function (PRF), that is the result of an encryption with a givenkey. In the general case the probability of emitting random or pseudo-random streams is 0.5. Anattacker can query the permutation oracle and obtain a result; he then has to determine whether theoutput string is a random sequence or the result of an encryption. If he can make it we have what iscalled the distinguishing advantage.

In another experiment there are two oracles: the tag-generation oracle and the tag-verificationoracle. The first receives as input a string from the attacker and generates an authentication tagfor that string; the second receives a message and a tag, and tells if the tag actually verifies thatmessage or not. The attackers can use the tag-generation oracle to construct message-tag pairs, tryto understand the way it works and then provide a pair to the tag-verification oracle. Obviously themessages built by the first oracle will be accepted by the second one, but we indicate as the forgeryadvantage the probability that an attacker can build on his own a message/tag pair accepted by thetag-verification oracle.

The distinguishing advantage is related to encryption security and the forgery advantage is relatedto authentication security. The goal of securing an authenticated encryption operation is to reduceto the minimum possible these two advantages, so that an attacker can’t exploit them to be able tobuild ad hoc messages or, worst case, recover the key.

The proof of GCM security is not particularly complicated but requires some mathematics to beused and therefore we are not going to explain all the passages. The results are quite intuitive andtell us that to achieve a very high security we need a long tag (128 bits is advised) and not to usetoo long IVs as well as encrypting too long messages. In particular we observe that the distinguishingadvantage is quadratic in the length of the plaintext and linear both in the length of the plaintext andthe length of the IV ; the forgery advantage is quadratic in the length of P , and linear in the lengthof the pair C, A.

If we use a long IV it will be hashed by the algorithm and therefore we increase the probability of

17

collisions using longer and longer IVs; in addition, if we encrypt very long messages we increase theprobability of collisions in the authentication tag T .

Obviously the security of a mode of operations relies on the security of the underlying bock cipher,so we can’t expect high security levels if we choose the right IVs, we don’t encrypt very long messages,but we use a key of only 32 bits...

The official recommendation gives us some advices to increase the security provided by GCM.The first advice is about the keys and is quite obvious. Keys should be kept strictly secret and

changed whenever is needed, distributing them in a safe way.The second advice is about IV. The repetition of an IV in the authenticated encryption function

causes serious problems because of how the CTR mode of operation is built. Remember that GCMis based on the CTR technique. If we can induce a bit flipping in the ciphertext, a corresponding bitflip will be produced in the plaintext upon decryption. An attacker with an authenticated decryptionoracle could induce strategic bit flipping to see the results in the plaintext. In any case there is theMAC, so performing such an attack to GCM should be useless because there is the tag.

There is a problem though, when IVs are repeated. In this case the computed tag is only a functionof the hash sub-key H, so it could theoretically possible to recover the sub-key, with specific attacks.An attacker with H at his disposal, could modify a ciphertext and then compute a valid authenticationtag. The receiver would notice that the IV used is the same, but could think that the sender was ingood faith, so would try to decrypt the message, and since the authentication would be verified hecould think that the message is authentic. In conclusion IVs must be changed any time a transmissionis performed and it must be guaranteed that also in the case of a power down the same IV must notbe used twice.

The third advice is about the tags. We know that given a tag of length t the probability ofobtaining a collision (i.e.: the same tag with different ciphertexts) is 2−t. With GCM an attackercould use techniques that increase this probability. Any of these forgery attacks that succeed increasesthe probability that other attacks of the same kind come through, and finally the hash sub-key H

could be compromised, canceling any authentication assurance.The fourth and last advice is related to the protection against replay attacks. To avoid this kind

of attacks is sufficient to follow the general principle of the second advice, instructing the recipientto discard messages with duplicated IVs for a given key, and, furthermore, to use timestamps in theadditional authenticated data.

18

Chapter 4

Conclusions

Authenticated Encryption is probably one of the best available examples to show what a wrong useof Intellectual Properties could do. The problem of AE is quite important, especially in a high speednetwork environment, and a reliable, fast and easy to implement AE protocol is needed. We’ve seen,though, that the best technical solution has been actually blocked by a dull use of the IntellectualProperty concept.

The two described solutions are good ways to solve the problem and are free of Intellectual Proper-ties restrictions, but are not optimal solutions. They both use the two-pass combined mode strategy;CCM does it in a very simple way, because it was one of the first solutions of this type ever pro-posed; GCM is better in many ways, but in any case the approach is only slightly better than genericcomposition.

So why choose an authenticated encryption protocol? One of the reason is that is often goodto have a unique solution to solve two problems, just because it could be cheaper to implement, forinstance. The advantage of saving time is unfortunately quite limited, since the single-pass solutionsare in fact unavailable. It is useful, though, to have an algorithm like GCM that could implement justauthentication, and AE when needed only.

Let’s have a look at the main properties CCM offers.The main security function offered is of course authenticated encryption. There is no error prop-

agation during the generation process. Sender and recipient must be synchronized as they both needto use the same nonce, based for example on a counter. The encryption process can be parallelizedif needed but this is not true for the authentication process so CCM algorithm can’t be parallelized.The process needs a unique key, shared by sender n receiver and used both for the counter mode andthe cipher block encryption, a nonce and a counter, which are part of the counter block. In terms ofmemory requirements CCM requires memory for the encrypt operation of the underlying block cipheralgorithm, for the plaintext, the ciphertext and a packet counter.

One important feature of CCM is that the encryption key stream can be precomputed, saving timeand increasing speed. Unluckily the same cannot be said for authentication.

To what relates GCM we can briefly summarize its main features.Like CCM there is no error propagation, because is based on a mode that operates with independent

blocks. GCM can be efficiently parallelized, improving a lot the performances. It needs one key only:the structure of the algorithm is designed to eliminate the security issues that could rise from theuse of the same key for the authentication and encryption parts. The IVs can have arbitrary length,although the suggested one is 96 bits, and should never be reused with the same key. GCM is on-line,in the sense that the recipient do not need to know the length of the incoming message, but canprocess the data blocks as they arrive. The authentication tag has a variable length, from 0 to 128bits and the ciphertext has the same length of the plaintext.

Probably the most important feature of GCM is its possibility to be easily implemented in hard-ware, allowing throughput of more than 10Gbps.

19

Bibliography

[1] NIST Special Publication 800-38C.

[2] NIST Special Publication 800-38D.

[3] www.wikipedia.org

[4] J. Black. Authenticated encryption.

[5] P. Rogaway, D. Wagner. A Critique of CCM.

[6] J. Jonsson. On The Security of CTR + CBC-MAC.

[7] D. Whiting, R. Housley, N. Ferguson. Counter with CBC-MAC (CCM) IETF Internet Draft

[8] D. A. McGrew, J. Viega. The Security and Performance of the Galois/Counter Mode (GCM) ofOperation

[9] D. A. McGrew, J. Viega. The Galois/Counter Mode of Operation (GCM)

[10] D. A. McGrew, J. Viega. Flexible and Efficient Message Authentication in Hardware and Software

[11] K. Claffy, G. Miller, K. Thompson The nature of the beast: recent traffic measurements froman Internet backbone

20