Ensuring Message Integrity with Message Authentication Codes

1. Cryptography Lecture 10

2. Secrecy vs. integrity • So far we have been concerned with ensuring secrecy of communication • What about integrity? – I.e., ensuring that a received message originated from the intended party, and was not modified • Standard error-correction not enough! – The right tool is a message authentication code

3. Passive attacks vs. active attacks • So far we have been considered only passive (i.e., eavesdropping) attacks – Attacker simply observes the channel (even if it might also carry out a chosen-plaintext attack) • In the setting of integrity, we explicitly consider active attacks – Attacker has full control over the channel

4. m’, t’ m, t k k m Vrfyk(m’, t’) = 1? t = Mack(m)

5. Secrecy vs. integrity • Secrecy and integrity are orthogonal concerns – Possible to have either one without the other – Sometimes you might want one without the other – Most often, both are needed • Encryption does not (in general) provide any integrity – None of the schemes we have seen so far provides any integrity!

6. c1c2…c’n c1c2…cn k k m1m2…m’n:= (c1c2…c’n)k c := (m1m2…mn)k

7. Message authentication code (MAC) • A message authentication code is defined by three PPT algorithms (Gen, Mac, Vrfy): – Gen: takes as input 1n; outputs k. (Assume |k|≥n.) – Mac: takes as input key k and message; outputs a tag t t  Mack(m) – Vrfy: takes key k, message m, and tag t as input; outputs 1 (“accept”) or 0 (“reject”) For all m and all k output by Gen, Vrfyk(m, Mack(m)) = 1

8. Security? • Only one standard definition • Threat model – “Adaptive chosen-message attack” – Assume the attacker can induce the sender to authenticate messages of the attacker’s choice • Security goal – “Existential unforgeability” – Attacker should be unable to forge a valid tag on any message not previously authenticated by the sender

9. m1, t1 k m2, t2 t1:= Mack(m1) t2:= Mack(m2) … ti:= Mack(mi) … mi, ti m, t k Vrfyk(m, t) ??

10. Formal definition • Fix A,  • Define randomized experiment ForgeA,(n): 1. k  Gen(1n) 2. A interacts with an oracle Mack(·) ; let M be the set of messages submitted to this oracle 3. A outputs (m, t) 4. A succeeds, and the experiment evaluates to 1, if Vrfyk(m, t)=1 and mM

11. Security for MACs •  is secure if for all PPT attackers A, there is a negligible function  such that Pr[ForgeA,(n) = 1] ≤ (n)

12. Security? • Is the definition too strong? – We don’t want to make any assumptions about what the sender might authenticate – We don’t want to make any assumptions about what forgeries are “meaningful” • A MAC satisfying this definition can be used anywhere integrity is needed

13. Replay attacks • Note that replay attacks are not prevented – No stateless mechanism can prevent them • Replay attacks are often a significant real- world concern • Need to protect against replay attacks at a higher level – Decision about what to do with a replayed message is application-dependent

14. A fixed-length MAC

15. Intuition? • We need a keyed function Mac such that: – Given Mack(m1), Mack(m2), …, – …it is infeasible to predict the value Mack(m) for any m{m1, …, } • Let Mac be a pseudorandom function!

16. Construction • Let F be a length-preserving, keyed function • Construct the following MAC : – Gen: choose a uniform key k for F – Mack(m): output Fk(m) – Vrfyk(m, t): output 1 iff Fk(m)=t • Theorem: If F is a pseudorandom function, then  is a secure MAC

17. Proof by reduction m1 t1 … m1 t1 … mi ti mi ti PRF/random m t* m, t if (m is new and t=t*) output 1 D

18. Analysis • When D interacts with Fkfor uniform k, the view of the adversary is identical to its view in the real MAC experiment – Pr[DFkoutputs 1] = Pr[ForgeAdv, (n) = 1] • When D interacts with uniform f, then seeing f(m1), …, f(mi) does not help predict f(m) for any m {m1, …, mi} – Pr[Dfoutputs 1] ≤ 2-n

19. Analysis • Since F is a pseudorandom function, | Pr[DFkoutputs 1] - Pr[Dfoutputs 1] | < negl(n)  Pr[ForgeAdv, (n) = 1] = Pr[DFkoutputs 1] ≤ 2-n+ negl(n)

20. Drawbacks? • This only works for fixed-length messages • This only works for short messages – E.g., AES has a 128-bit block size (shorter than a tweet!) • So the previous construction is limited to authenticating short, fixed-length messages

21. Suggestions? • Can you construct a secure MAC for variable- length messages from a MAC for fixed-length messages? • One natural idea: – Mac’k(m1, …, ml) = Mack(m1), …, Mack(ml) – Vrfy’k(m1, …, ml, t1, …, tl) = 1 iff Vrfyk(mi, ti) = 1 for all i – Is this secure? • Other suggestions?

22. A construction • Need to prevent (at least) – Block reordering – “Mixing-and-matching” blocks from multiple messages – Truncation • One solution: – Mac’k(m1, …, ml) = r, Mack(r | l | 1 | m1), Mack(r | l | 2 | m2), … – Not very efficient – can we do better?

23. (Basic) CBC-MAC m2 ml m1   … Fk Fk Fk t

24. CBC-MAC vs. CBC-mode • CBC-MAC is deterministic (no IV) – MACs do not need to be randomized to be secure – Verification is done by re-computing the result • In CBC-MAC, only the final value is output • Both are essential for security – Exercise: show attacks on variants

25. Security of (basic) CBC-MAC? • If F is a pseudorandom function with block length n, then for any fixed l, basic CBC-MAC is a secure MAC for l-block messages • The sender and receiver must agree on the length parameter l in advance – Basic CBC-MAC is not secure if this is not done! – Exercise: show attacks