Lecture_4_Shared-key_Secure_Session.pptx

Course from Applied Cryptography course

1. CSE 3400 - Introduction to Cyber Security (aka: Computer and Information Security) Topic 4: Shared-Key Protocols Prof. Amir Herzberg Dept. of Computer Science & Engineering University of Connecticut Last updated: 3/9/2020

2. Cryptographic Protocols Encryption, MAC, etc. are crypto-schemes Usually used as part of crypto-protocols Exchange of msgs btw set of parties (PPT) algorithm π p and state for each party p Alg maps input-signal + state to out-signal, state Common signals: Signal Type Comments INIT( κ ) Input Initialize parties with shared key κ IN( μ ) Input Message μ received (via the network) Out( μ ,d) Output Send message μ to destination d (via the network)

3. Focus: two party shared key protocols MitM adversary model Complete knowledge, control of input/outputs Except random choices, e.g., bit in IND-CPA game Resiliency to key/state exposure Two basic goals: handshake and session Handshake : Authentication (of initiator/responder/ mutual ) Set-up of (shared) session keys Session : secure communication using key Authenticate, encrypt, compress, …  

4. Session Protocol: Order of Operation Compress first Remove redundancy Encrypt-then-Comp fails Length-leakage attacks! Encrypt then Auth ( EtA ) Prevent CCA Detect forgery attempt Finally , EDC / ECC Error Detection / Correction Code MAC fails attack! Message Compress Plaintext Encrypt Ciphertext MAC Ciphertext tag Code Ciphertext ECC tag

5. Shared-Key Handshake and Session Protocols: Topics Introduction to (shared key) crypto-protocols Entity Authentication Session Authentication ( entities+messages ) Key-setup handshakes GSM handshake case study, and: Key distribution Ciphersuite negotiation and downgrade attacks Improving resiliency to key exposures

6. 3/9/2020 6 Example : SNA’s Mutual Authentication Mutual, session authentication Multiple sessions allowed, each party may initiate Using encryption with shared key k A, N A E k (N A ),N B E k (N B ) Bob Alice SNA: IBM’s proprietary network architecture, dominated market @ [1975-1990s]. Still in use – mainly in banking. N a , N b - randomly chosen nonces

7. 3/9/2020 http://AmirHerzberg.com 7 Attack on SNA’s Mutual Authentication Eve opens two connections with Bob… sending N b to Bob in 2 nd connection to get E k (N b ) Bob Eve (spoofing as Alice) Connection 1 Connection 2 Connection 1 Connection 2 A, N A =1234 E k (1234),N B =5678 5678 A, N A =5678 E k (5678),N B =9012 E k (5678) E k (5678) Alice `identified` (spoofed)

8. Fixing Mutual Authentication Encryption does not ensure authenticity Use MAC to authenticate messages Prevent redirection Identify party in challenge Better: use separate keys for each direction Prevent replay and reorder Identify flow and connection Prevent use of old challenge: randomness, time or state Prevent chosen-plaintext, chosen-Ciphertext attacks Do not compute values from Adversary Include self-chosen nonce in the protected reply

9. Two-Party Mutual Authentication Protocol (2PP) Use MAC rather than encryption to authenticate Prevent redirection: include identities ( A,B ) Prevent replay and reorder: Nonces ( N A ,N B ) Separate 2 nd and 3 rd flows: 3 vs. 2 input blocks Secure against arbitrary interleaving attacks [B*91] Map msgs sent, received by Alice & Bob (except truncation) Mac k (2 || A  B ||N A || N B ): sent only by Bob when he gets A, N A Mac k (3 || A B || N A || N B ): sent only by Alice upon Mac k (2 || A  B ||N A || N B ) A, N A N B , Mac k (2 || A  B ||N A || N B ) Mac k (3 || A B || N A || N B ) Bob Alice

10. Two-Party Mutual Authentication Protocol (2PP) Use MAC rather than encryption to authenticate Prevent redirection: include identities ( A,B ) Prevent replay and reorder: Nonces ( N A ,N B ) Separate 2 nd and 3 rd flows: 3 vs. 2 input blocks Secure against arbitrary interleaving attacks [B*91] [BR93] Map msgs sent, received by Alice & Bob (except truncation) Mac k (2 || A  B ||N A || N B ): sent only by Bob when he gets A, N A Mac k (3 || A B || N A || N B ): sent only by Alice upon Mac k (2 || A  B ||N A || N B ) A, N A N B , Mac k (2 || A  B ||N A || N B ) Mac k (3 || A B || N A || N B ) Bob Alice Definition, proof: see [BR93] or cryptography course/books

11. Two-Party Mutual Authentication Protocol (2PP) Use MAC rather than encryption to authenticate Prevent redirection: include identities ( A,B ) Prevent replay and reorder: Nonces ( N A ,N B ) Separate 2 nd and 3 rd flows: 3 vs. 2 input blocks Secure against arbitrary attacks Aka 3-way handshake Can Bob compute, send MAC only after receiving (valid) MAC? (Weak) defense against Denial-of-Service attacks A, N A N B , Mac k (2 || A  B ||N A || N B ) Mac k (3 || A B || N A || N B ) Bob Alice

12. Two-Party Mutual Authentication Protocol (2PP) Use MAC rather than encryption to authenticate Prevent redirection: include identities ( A,B ) Prevent replay and reorder: Nonces ( N A ,N B ) Separate 2 nd and 3 rd flows: include flow number Secure against arbitrary (interleaving) attacks; why? How to authenticate messages , too? A, N A N B , Mac k (2 || A  B ||N A || N B ) Mac k (3 || A B || N A || N B ) Bob Alice

13. Shared-Key Handshake and Session Protocols: Topics Introduction to (shared key) crypto-protocols Entity Authentication Session Authentication ( entities+messages ) Key-setup handshakes GSM handshake case study, and: Key distribution Ciphersuite negotiation and downgrade attacks Improving resiliency to key exposures

14. 2PP: Extensions and Variants Authenticate messages m A , m B : include in MAC Note: also ensures freshness But: Bob sends `response’ before receiving ‘request’ How to authenticated fresh request-response ? A, N A m B , N B , Mac k (2 || A B ||N A || N B || m B ) m A , Mac k (3 || A B || N A || N B || m A ) Bob Alice

15. 2PP: Extensions and Variants Authenticate messages m A , m B : include in MAC Authenticated fresh request-response, V1: two rounds ‘Four-way handshake’ Can we ensure freshness but only in one round? A, N A N B req , Mac k (3 || A B || N A || N B || req ) Bob Alice resp , Mac k (4 || A B ||N A || N B || resp ) Remember N A ,N B

16. 2PP: Extensions and Variants Authenticate messages m A , m B : include in MAC Authenticated fresh request-response, V2: one-round, stateful Or : use (securely!) synchronized time instead of state Can we support many messages (in order – a session)? req , T A , Mac k (1 || A B || T A || req ) Bob Alice resp , Mac k (2 || A B ||T A || resp ) Validate T A is new Remember T A

17. 2PP: Extensions and Variants Authenticate session : add sequence numbers Can we also use the key to protect confidentiality, too? How? A, N A N B req1 , Mac k (3 || A B || N A || N B || req1 ) Bob Alice resp1 , Mac k (4 || A B ||N A || N B ||resp1 ) req2 , Mac k (5 || A B || N A || N B || req2 ) resp2 , N B , Mac k (6 || A B ||N A || N B ||resp2 )

18. 2PP: Extensions and Variants Secure connection: authentication, freshness, secrecy Independent keys: for encryption k.e , for authentication: k.a How can we derive them both from a single key k ? k.e = PRP k (“Encrypt”), k.a = PRP k (“MAC”) Hmm… same key encrypts all messages, in all sessions  Can we improve security, by changing keys, e.g., btw sessions ? A, N A N B E k.e ( req ) , Mac k.a (3 || A B || N A || N B || E k.e ( req ) ) Bob Alice E k.e ( resp ) , Mac k.a (4 || A B ||N A || N B || E k.e ( resp ))

19. Shared-Key Handshake and Session Protocols: Topics Introduction to (shared key) crypto-protocols Entity Authentication Session Authentication ( entities+messages ) Key-setup handshakes GSM handshake case study, and: Key distribution Ciphersuite negotiation and downgrade attacks Improving resiliency to key exposures

20. 2PP: Extensions and Variants Independent session keys, e.g. k=PRF MK (N A ,N B ) Or, `directly’ for authentication and for encryption: k.e =PRF MK (“Encrypt”, N A ,N B ), k.a =PRF MK (“MAC”, N A ,N B ) Improves security: Exposure of session key does not expose (long-term) ‘master key’ MK And does not expose keys of other sessions Limited amount of ciphertext exposed with each session key k (or k.e ) Better: separate keys from A B from keys from BA (why? how?) Later: reduce risk also from exposure of Master Key MK A, N A N B E k.e ( req ) , Mac k.a (3 || A B || N A || N B || E k.e ( req ) ) Bob Alice E k.e ( resp ) , N B , Mac k.a (4 || A B ||N A || N B || E k.e ( resp ))

21. Case study: WPA2 Handshake WEP vulnerabilities  WPA (2003), WPA2 (2004) But… vulnerable to Key-Reinstallation Attack [KRACK 2017; simplified] Trick client (victim) into re-installing, re-using an already-used key WPA2 (simplified): 4-way handshake Session key k  f κ (N A ||N B ) : apply PRF with master key κ over nonces 1,N A 2, N B 3,MAC k’ (3) Access Point (AP) Bob 4,MAC k’ (4) k,k ’  E κ (N A ||N B ) Association exchange & k,k ’  E κ (N A ||N B )

22. Case study: WPA2 Handshake Session protocol: Begins after receiving the handshake authentication message (MAC) F or simplicity, we ignore message authentication during session protocol Encryption: stream cipher, where is a counter of msgs from to Challenge: handling losses (wireless  common!)   1,P,N A 2, N B 3,MAC k’ (3) Access Point (AP) Bob 4,MAC k’ (4) k,k ’  E κ (N A ||N B ) Association exchange & k,k ’  E κ (N A ||N B )   1,    

23. WPA2: Handling loss During session: responsibility of application Typically, send ack or response to each message Ack /response not received? Retransmit What about loss of handshake? Retransmit 1,P,N A 2, N B 3,MAC k’ (3) Access Point (AP) Bob 4,MAC k’ (4) k,k ’  E κ (N A ||N B ) k,k ’  E κ (N A ||N B ) 1,   3,MAC k’ (3) retransmit 4,MAC k’ (4) retransmit

24. WPA2: Handling loss During session: responsibility of application Typically, send ack or response to each message Ack /response not received? Retransmit What about loss of handshake? Retransmit, but... what about session-messages & their counter? 1,P,N A 2, N B 3,MAC k’ (3) Access Point (AP) Bob 4,MAC k’ (4) k,k ’  E κ (N A ||N B ) k,k ’  E κ (N A ||N B ) 1,   3,MAC k’ (3) retransmit 1,   4,MAC k’ (4) retransmit

25. WPA2 4-Way Handshake: details r : replay counter, incremented at each transmission to ignore replays Session key k  f κ (N A ||N B ) : apply PRF with master key κ over nonces Bob receives msg 3 with valid MAC: send msg 4, begin session AP receives msg 4 with valid MAC: begin session 1, r, N A 3,r+1,MAC k (3,r+1) 4,r+1,MAC k (4,r+1) AE k ( req || 1) AE k ( resp || 1) k  f κ (N A ||N B ) Association exchange & k  f κ (N A ||N B ) AE k (resp2 || 2) AE k (req2 || 2) Up Up Access Point (AP) Bob (client/supplicant) 2,r, N B , MAC k (2||r||N B )

26. WPA2 Handshake: details 1, r, N A 3,r+1,MAC k (3,r+1) 4,r+1,MAC k (4,r+1) AE k ( req || 1) AE k ( resp || 1) k  f κ (N A ||N B ) Association exchange & k  f κ (N A ||N B ) AE k (resp2 || 2) AE k (req2 || 2) Up Up Access Point (AP) Bob (client/supplicant) 2,r, N B , MAC k (2||r||N B )

27. WPA2 Handshake: handling loss (1) Retransmissions ≠ replays. Upon timeout (no msg 2 or 4, after 1sec), AP retransmits ( msg 1 or 3, resp.) but also increments r Why does it increment r ? Seems a bug. Counter should not change at retransmit!! If message 3 (or 1) was lost, no problem: 1, r, N A 3,r+1,MAC k (3,r+1) AP Bob 4,r+2,MAC k (4,r+2) AE k ( req || 1) AE k ( resp || 1) k  f κ (N A ||N B ) & Association exchange k  f κ (N A ||N B ) Up Up 3,r+2,MAC k (3,r+2) 2,r, N B , MAC k (2||r||N B )

28. 1, r, N A 3,r+1,MAC k (3,r+1) AP Bob 4,r+2,MAC k (4,r+2) AE k ( req || 1) AE k ( resp || 1) k  f κ (N A ||N B ) & Association exchange k  f κ (N A ||N B ) Up Up 3,r+2,MAC k (3,r+2) 2,r, N B , MAC k (2||r||N B )

29. WPA2 Handshake: handling loss (2) Retransmissions ≠ replays. AP increments r upon timeout But if message 4 is lost: Bob signals Up anyway, possibly begins to send, e.g . req1 , via AP Upon receiving re- transtmit of msg 3: same thing… but now req2 3,r+1,MAC k (3,r+1) AP Bob 4,r+2,MAC k (4,r+2) AE k (req1 || 1) k  f κ (N A ||N B ) k  f κ (N A ||N B ) Up Up 3,r+2,MAC k (3,r+2) 4,r+2,MAC k (4,r+2) … (skipped) … 2,r, N B , MAC k (2||r||N B ) AE k (req2 || 1) Up

30. 3,r+1,MAC k (3,r+1) AP Bob 4,r+2,MAC k (4,r+2) AE k (req1 || 1) k  f κ (N A ||N B ) k  f κ (N A ||N B ) Up Up 3,r+2,MAC k (3,r+2) 4,r+2,MAC k (4,r+2) … (skipped) … 2,r, N B , MAC k (2||r||N B ) AE k (req2 || 1) Up

31. WPA2 Handshake: key re- init attack Drop msg 4: base increments r , resends msg 3 (after timeout) Bob receives re-sent msg 3: re-install key, restart session Same key, counter in both sessions  encrypt by XOR with same bits! Since WPA-2 always uses stream-cipher encryption (e.g., RC4) 3,r+1,MAC k (3,r+1) AP Bob 4,r+2,MAC k (4,r+2) AE k (req1 || 1) k  f κ (N A ||N B ) k  f κ (N A ||N B ) Up Up 3,r+2,MAC k (3,r+2) MitM 4,r+2,MAC k (4,r+2) … (skipped) … AE k (req2 || 1) 2,r, N B , MAC k (2||r||N B )

32. 3,r+1,MAC k (3,r+1) AP Bob 4,r+2,MAC k (4,r+2) AE k (req1 || 1) k  f κ (N A ||N B ) k  f κ (N A ||N B ) Up Up 3,r+2,MAC k (3,r+2) MitM 4,r+2,MAC k (4,r+2) … (skipped) … AE k (req2 || 1) 2,r, N B , MAC k (2||r||N B )

33. Shared-Key Handshake and Session Protocols: Topics Introduction to (shared key) crypto-protocols Entity Authentication Session Authentication ( entities+messages ) Key-setup handshakes GSM handshake case study, and: Key distribution Ciphersuite negotiation and downgrade attacks Improving resiliency to key exposures

34. Key Distribution Center (KDC) KDC: shares keys with all parties ( k A , k B …) Goal: help parties (A, B) establish k AB A time-based, stateless KDC variant: Alice: 2PP with KDC, receive k AB and Bob’s ticket Ticket: encrypted, authenticated k AB Use time to ensure freshness and limit usage Client (Alice) KDC Server (Bob) 2PP (Alice to KDC): k AB , Ticket Ticket + 2PP (Alice to Bob): use k AB as shared key

35. KDC Protocol KDC shares keys (enc.), (MAC) with Alice and , with Bob Goal: Alice and Bob share , then derive: ,  

36. Base Mobile s Ok   r I Home (KDC) I (r, s, k) KDC Case Study: GSM Security Protocol GSM: 90% of mobile networks Security: ‘Home’ provider acts as KDC K I  CK[I] r  $ ; ( s,k )  A38(K I ,r) ( k,s )  A38(K I ,r) Validate s I (=IMSI), K I ‘1’ is message counter; derive, use separate key for base mobile traffic

37. For simplicity: ‘merge’ Base, Home Or: ignore the interaction with home Use new triplet in each handshake Mobile s Ok   r I Base/Home ( k,s )  A38(K I ,r) Validate s I (=IMSI), K I K I  CK[I] r  $ ; ( s,k )  A38(K I ,r)

38. GSM : Fake-Base Replay Attack Protocol vulnerabilities: No authentication of base No prevention of replay by base Fake Base Replay Attack: Simple replay  same key !  key-pad reuse ! If k exposed… decrypt, impersonate as Base Fake base Client r IMSI Base s Ok r s Ok Eavesdrop Impersonate, decrypt IMSI Exercise : Small change to protocol, to foil simple replay attack )    

39. GSM: Cipher Suites GSM encryption algorithms : A5/0: none, A5/1: broken, A5/2: useless (break with only 1sec of ciphertext!), A5/3: Proprietary A5/1 `contributed’ by France A5/2 : efficient attacks; weakened version of A5/1 For some countries  Time-memory tradeoff known-plaintext attack CTO, due to use of ECC-then-encrypt All phones must support A5/2, A5/1 Mobile sends list of cipher-suites it supports Base selects best one that it also supports  

40. GSM: Cipher Suites GSM encryption algorithms: A5/0: none, A5/1: broken, A5/2: useless Base Mobile s Ok )   r ,A5/1 Home (KDC) IMSI (r, K, s) … (K,s)  A38 ( k i ,r) Validate s IMSI , Ciphers {A5/1, A5/2 }