Message Authentication Codes – Definitions

The aim of a message authentication code is to prevent an adversary from modifying a message sent by one party to another, without the parties de-tecting that a modification has been made. As in the case of encryption, such a task is only possible if the communicating parties have some secret that the adversary does not know (otherwise nothing can prevent an adversary from impersonating the party sending the message). The setting that we con-sider here therefore assumes that the parties share the same secret key. Since the parties share the same key, the notion of a message authentication code belongs to the world ofprivate-key cryptography.

Loosely speaking, a message authentication code is an algorithm that is applied to a message. The output of the algorithm is aMAC tag(or justtag)

that is sent along with the message. Security is formulated by requiring that no adversary can generate a valid MAC tag on any message that was not sent by the legitimate communicating parties.

The syntax of a message authentication code. Before defining security, we first present the technical definition of what a message authentication code is. As with encryption, a message authentication code is made up of three algorithmsGen, Mac and Vrfy. The algorithm Gen generates a secret key; as with private-key encryption, we will assume that upon input 1ⁿ, the algorithm outputs a uniformly distributed string of lengthn. The algorithm Macgenerates MAC tags; i.e., it maps a keykand a messagemto a tagt. We write this asMack(m). Finally, the algorithmVrfyreceives a keyk, a message m, and a tagt, and outputs either 1 (meaningvalid) or 0 (meaninginvalid).

We write this asVrfy_k(m, t). We have the following formal definition:

DEFINITION 4.1 (message authentication code – syntax): A message authentication code or MAC is a tuple of probabilistic polynomial-time algo-rithms(Gen,Mac,Vrfy)fulfilling the following:

1. Upon input1ⁿ, the algorithmGenoutputs a uniformly distributed key k of lengthn; k←Gen(1ⁿ).

2. The algorithmMacreceives for input somek∈ {0,1}ⁿandm∈ {0,1}^∗, and outputs somet∈ {0,1}^∗. The valuet is called theMAC tag.

3. The algorithmVrfyreceives for input somek∈ {0,1}ⁿ, m∈ {0,1}^∗ and t∈ {0,1}^∗, and outputs a bit b∈ {0,1}.

4. For every n, every k ∈ {0,1}ⁿ and every m ∈ {0,1}^∗ it holds that Vrfy_k(m,Mack(m)) = 1.

If there exists a function`(·)such that Mack(·)is defined only over messages of length`(n)andVrfy_k(m, t)outputs0for everymthat is not of length`(n), then we say that(Gen,Mac,Vrfy)is afixed length MACwith length parameter`.

We remark that as for encryption, the second requirement in Definition 4.1 can be relaxed so that

Pr[Vrfy_k(m,Mack(m)) = 1]>1−negl(n)

where negl is a negligible function, and the probabilities are taken over the choice of kand any internal coin tosses ofMacandVrfy.

Security of message authentication codes. Definition 4.1 says nothing whatsoever about security. The intuitive idea behind the definition of security is that no polynomial-time adversary should be able to generate a valid MAC tag on any “new” message (i.e., a message not sent by the communicating

parties). As with any definition, we have to define the adversary’s power, as well as what is considered to be a “break” of the scheme. Regarding the adversary’s power, in the setting of message authentication, an adversary may be able to see many tagged messages that the parties send to each other.

Furthermore, the adversary may even be able to influence thecontentof these messages. For example, consider the case that the adversary is the personal assistant of one of the parties. In this case, the adversary may be responsible for the actual wording of many of the messages that are sent (of course, we assume that the assistant does not have access to the party’s key and that the party reviews any message before computing a MAC on it). Clearly, we need to ensure that this assistant is unable to generate any valid MAC on a message not reviewed by the legitimate party. In order to model the possibility that the adversary is able to effectively choose the messages that are tagged (or at least influence them to some extent), we provide the adversary with a MAC-generation box, or more technically, with a MAC oracle. During the adversarial attack, the adversary is able to request a MAC tag on any message that it wishes, where this tag is computed using the communicating parties’

secret key.

At the end of this attack, the adversary attempts to break the MAC scheme.

We model the break by saying that the adversary succeeds if it outputs a new message and a valid MAC tag upon that message. By a new message, we mean one that the adversary did not query to the MAC tag oracle. The final question that should be answered here is what form should the “new message” have. That is, should it be a valid English text, or a correctly encoded Word document? As you may have guessed, specifying any specific format would make the security of the MAC scheme dependent on a given application. Since cryptographic schemes should be secure for all applications, even those applications where random strings are tagged, we will consider a MAC scheme broken if the adversary generates any new message together with a valid MAC tag. This level of security is calledexistential unforgeability against a chosen message attack. The “existential unforgeability” refers to the fact that the adversary should not be able to generate a valid MAC tag onany message, and the “chosen message attack” refers to the fact that the adversary is able to obtain MAC tags on any messages it wishes during its attack. The formal definition of the experiment for the message authentication code Π = (Gen,Mac,Vrfy), with adversaryAand security parametern, is as follows:

The message authentication experimentMac-forge_A,Π(n).

1. A random key k← {0,1}ⁿ is chosen.

2. The adversaryAis given oracle access toMack(·)and outputs a pair(m, t). Formally,(m, t)← A^Mack(·)(1ⁿ). LetQ denote the queries asked by Aduring the execution.

3. The output of the experiment is defined to be 1 if and only if m /∈ QandVrfy_k(m, t) = 1.

The definition states that no efficient adversary should succeed in the above experiment with non-negligible probability.

DEFINITION 4.2 A message authentication codeΠ = (Gen,Mac,Vrfy)is existentially unforgeable under an adaptive chosen-message attack, or justsecure, if for all probabilistic polynomial-time adversaries A, there exists a negligible function neglsuch that:

Pr[Mac-forge_A,Π(n) = 1]≤negl(n)

We remark that a message authentication code can always be broken with negligible probability (that is, there is no hope of ensuring that an adversary’s success in the experiment is zero). In order to see this, letq(·) be a polynomial denoting the length of the MAC tags for the scheme (i.e., for a key of length nand messagem, the output tagtis of length at mostq(|m|+n)). Then, a naive attack that works for any scheme is to take anym(of any length) and simply choose a random string t of length q(|m|+n). The probability that this string is a valid MAC tag is at least 2^−q(|m|+n)because at least one string constitutes a valid MAC tag. Of course, such attacks are of little consequence because their success is too small. Nevertheless, this does give us a lower bound on the required length of the tag in a secure MAC scheme. Specifically, the tag must be super-logarithmic; otherwiseq(|m|+n) = O(logn) and so 2^−q(|m|+n) = 2^−O(logn) = 1/poly(n). In such a case, a random guess of the MAC tag is correct with non-negligible probability, and so the scheme cannot be secure.

Replay attacks and message authentication codes. Consider the fol-lowing scenario: a user Alice sends her bank an order to transfer $1,000 from her account to Bob’s account. Alice is the legitimate user, and so she also applies a message authentication code to the message so that the bank knows that it is authentic. Bob is unable to intercept the message and change the sum to $10,000 because this would involve forging the MAC scheme. However, nothing prevents Bob from intercepting Alice’s message and forwarding itten times repeatedly to the bank. If the bank accepts all of these messages, then

$10,000 will be transferred to Bob’s account, and not $1,000. Such an attack is called areplay attack and the MAC mechanism within itself does not pre-vent it. Rather, the application using the MAC is responsible for prepre-venting replays. The reason for this is that the legitimacy or illegitimacy of replays depends on the application. Furthermore, itcannot be solved by considering a single isolated message; rather the context and history must be taken into account. It is thus left to the higher-level application.

Two of the possible techniques for preventing replay are using unique se-quence numbers in transactions and using timestamps. When using unique sequence numbers, the idea is to not allow two transactions to have the same number (of course, this requires remembering previously used trans-action numbers, but there are solutions to this as well). When using sequence numbers, the MAC is applied to the transaction content together with the se-quence number. Note than any successful reply attack must forge the MAC in order to change the sequence number (if the exact same message is replayed, it will be rejected because the number has already been used). Timestamps have a similar effect: here, the message includes the current time, and some mechanism is employed so that no two transactions with the same timestamp are accepted. We stress again that the issue of replay attacks is a very real concern. However, this must be solved at the level of theapplication.