Symmetric Encryption 2: Integrity

Transcription

1 Symmetric Encryption 2: Integrity With material from Dave Levin, Jon Katz, David Brumley 1

2 Summing up (so far) Computational security Adversary receives encryption of either m0 or m1 Can t do better than guess which it is Secure PRF: Adversary can t distinguish between PRF and actual random function Block ciphers: Secure when used properly (IVs!) Multiple encryption modes 2

3 Message integrity and authentication 3

4 Privacy and integrity are orthogonal Up to now we ve had privacy without integrity Now we will do integrity without privacy And later, both at once Reminder: Goal is to detect tampering Not to prevent it! 4

5 Goal: Integrity Eve should not be able to alter m without detection. message m: curiouser and curiouser! ERROR! E Public channel D Alice Bob message m : curious and curious? Eve 5

6 Message authentication (MAC) m true or false S Public channel V Alice k s m t k s Bob t = Sign(m, ks) Verify(m,t,ks)?= true Only someone who knows ks could have sent the message! 6

7 Non-repudiation A special case of authentication Only Alice can have sent the message Bob could not have made it up Alice cannot effectively deny having sent it Why would you want this? 7

8 MAC definition t:t = S(k,m) V(k,m,t) = yes or no V(k, m, S(k,m)) = yes 8

9 Straw example #1: CRC CRC = cyclic redundancy check Binary division gives short, deterministic summary of data S(k,m) = CRC(m) What s wrong with this plan? 9

10 MAC security Alice sends message m with tag t Attacker s power: Chosen plaintext Can observe correct (mi, ti) pairs Can use MAC oracle to get tx for chosen mx Attacker s goal: Generate some valid m, t for m not previously seen m does not have to make sense! Secure if: Pr[V(k, m, t ) == yes] is very small 10 Called: Existential forgery

11 Replay attacks Does a MAC prevent a replay attack? NO Must be prevented at a higher level Application-dependent scenario Nonce, timestamp, etc. (more later) 11

12 Straw example #2: Block cipher Suppose message is exactly one block t = S(k,m) = E(k,m) t is 128 bits long under AES Is this secure? Why? 12

13 Security sketch Since E(k,m) is a secure block cipher, can conceptually replace E(k,m) with a random permutation. Seeing E(k,m1) E(k,mn) doesn t help predict unseen mn+1 Probability of a random guess is 1/2 L L = length of output tag (in bits) Need to make sure L is long enough! But this only works for tiny messages! 13

14 Encrypted CBC (ECBC) IV = 0 m1 m2 m3 m4 Using key k0 E E E E Using key k1 Verify: Same algorithm as signing E t 14

15 ECBC vs. CBC Output only one block instead of many Don t need to recover the plaintext AES => chance of guessing We used two keys Necessary to prevent existential forgery Both require serial computation 15

16 Why two keys? Attacker requests tag for message m (m1.. mn) Get corresponding tag t = c[n] Attacker creates message m (one block long) Request tag t for (t XOR m ) Resulting t is valid for m m Uh oh. 16

17 MACs with Hashes 17

18 Hash functions A pseudorandom, one-way function Does not require a key H(m) = h Input m = pre-image, can be arbitrary length Output h = digest or hash, fixed small length Generally very fast to compute 18

19 Cryptographic hash Pre-image resistance: Given H(m), it s hard to find m Collision resistant: Given H(m), it s hard to find m s.t. m!= m H(m ) = H(m) Even more: Pr[any bit matching] = 1/2 19

20 Example hash functions MD5: Known collision attacks, still frequently used SHA-1, SHA-256, SHA-512, etc. SHA1: theoretically broken since 2005 Deprecated by NIST in 2011 Practical attack (SHAttered) as of February! (Still in use many places) New SHA-3 (224, 256, 385, 512) Public contest Officially standardized August

21 Hash-MAC Most widely used MAC on internet General idea: hash then PRF (short MAC) Translate arbitrary message into one block Works if H and E are both secure m H E t Using key k 21

22 Aside: Birthday paradox How likely 2 people in a room share a birthday? Pr > 50% with 23 people! Why? There are n 2 different pairs With X possibility space and n samples: Pr[xi = xj] ~ 50% when n = X 1/2 22

23 Integrity vs. Authentication Recall: What is the difference? Don t forget non-repudiation Do symmetric MACs like ECBC and Hash-Mac give one, or both? Which? Problem: More than one person knows the key 23

24 Authenticated Encryption 24

25 Previously: Privacy / secrecy Integrity Now: Both at once 25

26 Ciphertext integrity Maintain semantic secrecy under CPA attack Attacker cannot create a new ciphertext that decrypts properly! Encryption oracle Decrypt c or error m1 mn c1 = E(k,m1) cn c (not in c1 cn) Eve (polynomial time) Ciphertext integrity IFF prob. of decryption without error is very small 26

27 CCA revisited Eve can get a cipher text decrypted c = E(k,m) E VPN D m m Bob Alice c = forged cipher text Eve 27

28 CCA game Attacker gets encryption oracle + decryption oracle (Encryption oracle not shown) Decryption oracle c1 cn m1 = D(k,c1) mn Challenge: Choose b = x or y at uniform random mx and my (not in m1 mn) c = E(k,mb) Eve (polynomial time) Eve s job: Guess whether x or y was picked. CCAsecure IFF no better than guessing 28

29 CBC is not CCA-secure Challenge: Choose b = x or y at uniform random mx and my mx = my = 1 blk c = E(k,mb) = IV c[0] Decryption oracle c = (IV xor 1) c[0] m = D(k,c ) = mb xor 1 Eve (polynomial time) Uh oh. 29

30 Ciphertext integrity (aka authenticated encryption) can protect against CCA! Because only someone who knows k can send a message that will decrypt properly. 30

31 Auth. Encr. limitations Does not protect against replay Does not protect against e.g. timing attacks 31

32 Constructing authenticated encryption 32

33 Three basic options Can you guess? Encrypt and MAC MAC then encrypt Encrypt then MAC 33

34 Encrypt and MAC m S ki E k E c t Send E(m) MAC(m) This is not secure b/c MAC may leak information about the message Secrecy is not a MAC property 34

35 MAC then encrypt m ki m S E k E t c Send E(m MAC(m)) This can be insecure in some combinations Always follow standards! 35

36 Encrypt then MAC m E k E c S ki c t Send E(m) Mac(E(m)) This is always secure! Intuition: MAC reveals only info about ciphertext (OK) MAC ensures ciphertext has not been tampered 36

37 Key exchange 37

38 Up to now, we have assumed Alice and Bob share a secret key How did that happen? How does this scale to many users? 38

39 One solution: Trusted third party (TTP) U1 k1 k2 U2 TTP U3 k3 k4 U4 TTP is a bottleneck for every message TTP must be online at all times TTP can read every message Does not solve bootstrapping problem 39

40 Session keys and tickets Used for Kerberos kat Bob KAB, Ticket TTP Ticket = E(KBT, Alice Bob kab ) (fresh kab) kab Hi Alice Ticket TTP is a bottleneck for every message TTP must be online at all times TTP can read every message Does not solve bootstrapping problem Bob 40

41 A (very) little number theory p => a random, large prime number g => a generator for p: 1 < g < p For all k between 1 and p: There is some i, s.t. k = g i mod p This is called discrete log Easy: Given p, g, x, compute y = g x mod p Believed hard: Given p, g, y, compute x Candidate one-way function! 41

42 Generator examples: p = 7 g = 3 g = mod mod mod mod mod mod 7 1 YES 2 1 mod mod mod mod mod mod 7 1 NO 42

43 Diffie-Hellman protocol 1 Compute A = g x mod p 2 p, g, A Alice secret value x Compute B = g y mod p B k = g xy mod p 4 3 Bob secret value y 5 k = B x mod p k = A y mod p 6 Successful secret key exchange! 43

44 Diffie-Hellman today Widely used on the internet for session keys (forward secrecy) Can be broken if parameters chosen poorly Precompute some of the attack to speed it up ( Logjam ) Currently switching to elliptic curves 44