6: Which MAC to Choose?

96



Part II



■



Message Security



careful that this statement is sufficient for all the security properties that you

need. For example, Eve could record a message from Alice to Bob, and then

send a copy to Bob at a later time. Without some kind of special protection

against these sorts of attacks, Bob would accept it as a valid message from

Alice. Similar problems arise if Alice and Bob use the same key K for traffic in

two directions. Eve could send the message back to Alice, who would believe

that it came from Bob.

In many situations, Alice and Bob want to authenticate not only the message

m, but also additional data d. This additional data includes things like the

message number used to prevent replay attacks, the source and destination of

the message, and so on. Quite frequently these fields are part of the header of

the authenticated (and often encrypted) message. The MAC has to authenticate

d as well as m. The general solution is to apply the MAC to d m instead of

just to m. (Here we’re assuming that the mapping from d and m to d m is

one-to-one; otherwise, we’d need to use a better encoding.)

The next issue is best captured in the following design rule:

The Horton Principle: Authenticate what is meant, not what is said.

A MAC only authenticates a string of bytes, whereas Alice and Bob want to

authenticate a message with a specific meaning. The gap between what is said

(i.e., the bytes sent) and what is meant (i.e., the interpretation of the message)

is important.

Suppose Alice uses the MAC to authenticate m := a b c, where a, b, and

c are some data fields. Bob receives m, and splits it into a, b, and c. But how

does Bob split m into fields? Bob must have some rules, and if those rules

are not compatible with the way Alice constructed the message, Bob will

get the wrong field values. This would be bad, as Bob would have received

authenticated bogus data. Therefore, it is vital that Bob split m into the fields

that Alice put in.

This is easy to do in simple systems. Fields have a fixed size. But soon you

will find a situation in which some fields need to be variable in length, or a

newer version of the software will use larger fields. Of course, a new version

will need a backward compatibility mode to talk to the old software. And here

is the problem. Once the field length is no longer constant, Bob is deriving it

from some context, and that context could be manipulated by the attacker. For

example, Alice uses the old software and the old, short field sizes. Bob uses

the new software. Eve, the attacker, manipulates the communications between

Alice and Bob to make Bob believe that the new protocol is in use. (Details

of how this works are not important; the MAC system shouldn’t depend on

other parts of the system being secure.) Bob happily splits the message using

the larger field sizes, and gets bogus data.



Chapter 6



■



Message Authentication Codes



This is where the Horton Principle [122] comes in.1 You should authenticate

the meaning, not the message. This means that the MAC should authenticate

not only m, but also all the information that Bob uses in parsing m into its

meaning. This would typically include data like protocol identifier, protocol

version number, protocol message identifier, sizes for various fields, etc. One

partial solution is to not just concatenate the fields but use a data structure like

XML that can be parsed without further information.

The Horton Principle is one of the reasons why authentication at lower

protocol levels does not provide adequate authentication for higher-level

protocols. An authentication system at the IP packet level cannot know how

the e-mail program is going to interpret the data. This precludes it from

checking that the context in which the message is interpreted is the same as the

context in which the message was sent. The only solution is to have the e-mail

program provide its own authentication of the data exchanged—in addition

to the authentication on the lower levels, of course.

To recap: whenever you do authentication, always think carefully about

what other information should be included in the authentication. Be sure that

you code all of this information, including the message, into a string of bytes in

a way that can be parsed back into the fields in a unique manner. Do not forget

to apply this to the concatenation of the additional data and the message we

discussed at the start of this section. If you authenticate d m, you had better

have a fixed rule on how to split the concatenation back into d and m.



6.8



Exercises



Exercise 6.1 Describe a realistic system that uses CBC-MAC for message

authentication and that is vulnerable to a length extension attack against

CBC-MAC.

Exercise 6.2 Suppose c is one block long, a and b are strings that are a

multiple of the block length, and M(a c) = M(b c). Here M is CBC-MAC.

Then M(a d) = M(b d) for any block d. Explain why this claim is true.

Exercise 6.3 Suppose a and b are both one block long, and suppose the

sender MACs a, b, and a b with CBC-MAC. An attacker who intercepts

the MAC tags for these messages can now forge the MAC for the message

b (M(b) ⊕ M(a) ⊕ b), which the sender never sent. The forged tag for this

1 For



readers who did not grow up in the U.S.: this is named after one of the characters of

Dr. Seuss, who was a writer of children’s books [116].



97



98



Part II



■



Message Security



message is equal to M(a b), the tag for a b. Justify mathematically why this

is true.

Exercise 6.4 Suppose message a is one block long. Suppose that an attacker

has received the MAC t for a using CBC-MAC under some random key

unknown to the attacker. Explain how to forge the MAC for a two-block

message of your choice. What is the two-block message that you chose? What

is the tag that you chose? Why is your chosen tag a valid tag for your two-block

message?

Using an existing cryptography library, compute the MAC of



Exercise 6.5

the message



4D 41 43 73 20 61 72 65 20 76 65 72 79 20 75 73

65 66 75 6C 20 69 6E 20 63 72 79 70 74 6F 67 72

61 70 68 79 21 20 20 20 20 20 20 20 20 20 20 20



using CBC-MAC with AES and the 256-bit key

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01.



Using an existing cryptography library, compute the MAC of



Exercise 6.6

the message



4D 41 43 73 20 61 72 65 20 76 65 72 79 20 75 73

65 66 75 6C 20 69 6E 20 63 72 79 70 74 6F 67 72

61 70 68 79 21



using HMAC with SHA-256 and the key

0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b

0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b 0b.



Exercise 6.7

the message



Using an existing cryptography library, compute the MAC of

4D 41 43 73 20 61 72 65 20 76 65 72 79 20 75 73

65 66 75 6C 20 69 6E 20 63 72 79 70 74 6F 67 72

61 70 68 79 21



using GMAC with AES and the 256-bit key

80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01



and the nonce

00 00 00 00 00 00 00 00 00 00 00 01.



CHAPTER



7



The Secure Channel



Finally we come to the first of the real-world problems we will solve. The

secure channel is probably the most common of all practical problems.



7.1



Properties of a Secure Channel



Informally, we can define the problem as creating a secure connection between

Alice and Bob. We’ll have to formalize this a bit before it becomes clear what

we are talking about.



7.1.1



Roles



First, most connections are bi-directional. Alice sends messages to Bob, and

Bob sends messages to Alice. You don’t want to confuse the two streams of

messages, so there must be some kind of asymmetry in the protocol. In real

systems, maybe one party is the client and the other the server, or maybe it is

easier to speak of the initiator (the party that initiated the secure connection)

and the responder. It doesn’t matter how you do it, but you have to assign the

Alice and Bob roles to the two parties in question in such a way that each of

them knows who is playing which role.

Of course, there is always Eve, who tries to attack the secure channel in

any way possible. Eve can read all of the communications between Alice and

Bob and arbitrarily manipulate these communications. In particular, Eve can

delete, insert, or modify data that is being transmitted.

99



100



Part II



■



Message Security



We always talk about transmitting messages from Alice to Bob, and most of

the time our mental image is of two separate computers sending messages to

each other over a network of some sort. Another very interesting application

is storing data securely. If you think of storing data as transmitting it to

the future, then all the discussions here apply. Alice and Bob might be the

same person, and the transmission medium could be a backup tape or a USB

stick. You still want to protect the medium from outside eavesdroppers and

manipulations. Of course, when you send data to the future, you cannot have

an interactive protocol, since the future cannot send a message back to the past.



7.1.2 Key

To implement a secure channel, we need a shared secret. In this case we

will assume that Alice and Bob share a secret key K, but that nobody else

knows this key. This is an essential property. The cryptographic primitives

can never identify Alice as a person. They can at most identify the key. Thus

Bob’s verification algorithm will tell him something like: ‘‘This message was

sent by somebody who knows the key K and who played the role of Alice.’’

This statement is only useful if Bob knows that knowledge of K is restricted,

preferably to himself and Alice.

How the key is established is not our business here. We just assume the key

is there. We will talk about key management in great detail in Chapter 14. The

requirements for the key are as follows:

The key K is known only to Alice and Bob.

Every time the secure channel is initialized, a new value is generated for

the key K.

The second item is also important. If the same key is used over and over

again, then messages from older sessions can be replayed to Alice or Bob, and

lead to much confusion. Therefore, even in situations where you have a fixed

password as key, you need a key negotiation protocol between Alice and Bob

to set up a suitable unique key K, and you must re-run this protocol every

time a secure channel is established. A key such as K that is used for a single

communication session is called a session key. Again, how K is generated will

be discussed in Chapter 14.

The secure channel is designed to achieve a security level of 128 bits.

Following our discussion in Section 3.5.7, we will use a 256-bit key. Thus, K is

a 256-bit value.



7.1.3 Messages or Stream

The next question is whether we look at the communications between Alice

and Bob as a sequence of discrete messages (such as e-mails) or as a continuous

stream of bytes (such as streaming media). We will only consider systems that