1. Protocol analysis, wireless networking, and mobility John Mitchell Stanford University

2. Many security Protocols uChallenge-response ISO 9798-1,2,3; Needham-Schroeder, … uAuthentication Kerberos uKey Exchange SSL handshake, IKE, JFK, IKEv2, uWireless and mobile computing Mobile IP, WEP, 802.11i uElectronic commerce Contract signing, SET, electronic cash, …

3. Mobile IPv6 Architecture IPv6 Mobile Node (MN) Corresponding Node (CN) Home Agent (HA) Direct connection via binding update uAuthentication is a requirement uEarly proposals weak

4. 802.11i Wireless Authentication

5. TLS protocol layer over TCP/IP Network interface Transport (TCP) Physical layer Internet (IP) Applicationtelnet httpftp nntp SSL/TLS

6. C ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone S [Certificate], ClientKeyExchange, [CertificateVerify] Finished switch to negotiated cipher Finished switch to negotiated cipher

7. Handshake Protocol ClientHello C  S C, Ver C, Suite C, N C, Suite S, N S, S, K S ServerHello S  C Ver S, Suite S, N S, sign CA { S, K S } ClientVerify C  S sign CA { C, V C } { Ver C, Secret C } N S sign C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash(Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } (Change to negotiated cipher) N S ServerFinished S  C { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + S + Master(N C, N S, Secret C ) + Pad 1 )) } N S ClientFinished C  S { Hash( Master(N C, N S, Secret C ) + Pad 2 + N S Hash( Msgs + C + Master(N C, N S, Secret C ) + Pad 1 )) } SKSSKS S Master(N C, N S, Secret C )

8. IKE subprotocol from IPSEC A, (g a mod p) B, (g b mod p) Result: A and B share secret g ab mod p AB m1 m2, signB(m1,m2) signA(m1,m2) Analysis involves probability, modular exponentiation, complexity, digital signatures, communication networks

9. Explicit Intruder Method Intruder Model Analysis Tool Formal Protocol Informal Protocol Description Find error

10. Run of protocol A B Initiate Respond C D Correct if no security violation in any run Attacker

11. Automated Finite-State Analysis uDefine finite-state system Bound on number of steps Finite number of participants Nondeterministic adversary with finite options uPose correctness condition Can be simple: authentication and secrecy Can be complex: contract signing uExhaustive search using “verification” tool Error in finite approximation  Error in protocol No error in finite approximation  ???

12. Mur j [Dill et al.] uDescribe finite-state system State variables with initial values Transition rules Communication by shared variables uScalable: choose system size parameters uAutomatic exhaustive state enumeration Space limit: hash table to avoid repeating states uResearch and industrial protocol verification

13. Applying Mur j to security protocols uFormulate protocol Assume finite participants –Example: 2 clients, 2 servers Assume finite message space –Represent random numbers by r1, r2, r3, … –Do not allow unbounded encrypt(encrypt(encrypt(…))) uAdd adversary Control over “network” (shared variables) Possible actions –Intercept any message –Remember parts of messages –Generate new messages, using observed data and initial knowledge (e.g. public keys)

14. Needham-Schroeder in Mur j (1) const NumInitiators: 1; -- number of initiators NumResponders: 1; -- number of responders NumIntruders: 1; -- number of intruders NetworkSize: 1; -- max. outstanding msgs in network MaxKnowledge: 10; -- number msgs intruder can remember type InitiatorId: scalarset (NumInitiators); ResponderId: scalarset (NumResponders); IntruderId: scalarset (NumIntruders); AgentId: union {InitiatorId, ResponderId, IntruderId};

15. Needham-Schroeder in Mur j (2) MessageType : enum { -- types of messages M_NonceAddress, -- {Na, A}Kb nonce and addr M_NonceNonce, -- {Na,Nb}Ka two nonces M_Nonce -- {Nb}Kb one nonce }; Message : record source: AgentId; -- source of message dest: AgentId; -- intended destination of msg key: AgentId; -- key used for encryption mType: MessageType; -- type of message nonce1: AgentId; -- nonce1 nonce2: AgentId; -- nonce2 OR sender id OR empty end;

16. Needham-Schroeder in Mur j (3) -- intruder i sends recorded message ruleset i: IntruderId do -- arbitrary choice of choose j: int[i].messages do -- recorded message ruleset k: AgentId do -- destination rule "intruder sends recorded message" !ismember(k, IntruderId) & -- not to intruders multisetcount (l:net, true) < NetworkSize ==> var outM: Message; begin outM := int[i].messages[j]; outM.source := i; outM.dest := k; multisetadd (outM,net); end; end;

17. Run of Needham-Schroeder uFind error after 1.7 seconds exploration uOutput: trace leading to error state  Mur j times after correcting error:

19. State Reduction on N-S Protocol

20. Security Protocols in Mur  uStandard “benchmark” protocols Needham-Schroeder, TMN, … Kerberos uStudy of Secure Sockets Layer (SSL) Versions 2.0 and 3.0 of handshake protocol Include protocol resumption uTool optimization uAdditional protocols Contract-signing Wireless networking … ADD YOUR PRODUCT HERE …

21. CS259 Term Projects iKP protocol familyElectronic votingXML Security IEEE 802.11i wireless handshake protocol Onion RoutingElectronic Voting Secure Ad-Hoc Distance Vector Routing An Anonymous Fair Exchange E-commerce Protocol Key Infrastructure Secure Internet Live Conferencing Windows file-sharing protocols Homework

22. Wireless Threats uPassive Eavesdropping/Traffic Analysis Easy, most wireless NICs have promiscuous mode uMessage Injection/Active Eavesdropping Easy, some techniques to gen. any packet with common NIC uMessage Deletion and Interception Possible, interfere packet reception with directional antennas uMasquerading and Malicious AP Easy, MAC address forgeable and s/w available (HostAP) uSession Hijacking uMan-in-the-Middle uDenial-of-Service: cost related evaluation Changhua He

23. Wireless Security Evolution u802.11 (Wired Equivalent Protocol) Authentication: Open system (SSID) and Shared Key Authorization: some vendor use MAC address filtering Confidentiality/Integrity: RC4 + CRC Completely insecure uWPA: Wi-Fi Protected Access Authentication: 802.1X Confidentiality/Integrity: TKIP Reuse the legacy hardware, still problematic uIEEE 802.11i (Ratified on June 24, 2004 ) Mutual authentication Data confidentiality and integrity: CCMP Key management Availability

24. Authentica- tion Server (RADIUS) No Key Authenticator UnAuth/UnAssoc 802.1X Blocked No Key Supplicant UnAuth/UnAssoc 802.1X Blocked No Key Supplicant Auth/Assoc 802.1X Blocked No Key Authenticator Auth/Assoc 802.1X Blocked No Key Authentica- tion Server (RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication Supplicant Auth/Assoc 802.1X Blocked MSK Authenticator Auth/Assoc 802.1X Blocked No Key Authentica- tion Server (RADIUS) MSK Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK Authentica- tion Server (RADIUS) No Key 4-Way Handshake Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key Group Key Handshake Supplicant Auth/Assoc 802.1X UnBlocked New GTK Authenticator Auth/Assoc 802.1X UnBlocked New GTK Authentica- tion Server (RADIUS) No Key Data Communication Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Authenticator Auth/Assoc 802.1X UnBlocked PTK/GTK Authentica- tion Server (RADIUS) No Key RSNA Conversations

25. Security Level Rollback Attack Probe Request Supplicant RSNA enabled Pre-RSNA enabled Authenticator RSNA enabled Pre-RSNA enabled Bogus Beacon (Pre-RSNA only) Bogus Probe Response (Pre-RSNA only) 802.11 Authentication Request 802.11 Authentication Response Bogus Association Request (Pre-RSNA only) 802.11 Association Response Pre-RSNA Connections Beacon + AA RSN IE Probe Response + AA RSN IE Association Request + SPA RSN IE

26. Solutions uSecurity Level Rollback Attack Similar to general version rollback attack Destroy security since WEP is insecure Not vulnerability of 802.11i standard, but an implementation problem uSolutions Allow only RSNA connections: secure, but too strict for common networks, where Transient Security Network is more convenient Deploy both, but –Supplicant manually choose to deny or accept –Authenticator limit pre-RSNA connections to only insensitive data

27. Reflection Attack Adversary Impersonates Communicating Peers {A2, Nonce2, RSN IE, sn, msg2, MIC} {A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {A1, sn+1, msg4, MIC} Legitimate Devices Authenticator and Supplicant Bogus Authentication Peers Authenticated {A1, Nonce1, sn, msg1} {A2, Nonce1, sn, msg1} {A1, Nonce2, RSN IE, sn, msg2, MIC} {A2, Nonce1, RSN IE, GTK, sn+1, msg3, MIC} {SPA, sn+1, msg4, MIC}

28. Reflection Solutions uPossible in ad hoc networks uViolates mutual authentication uSolutions: Restrict each entity to single role –Access point is not wireless station Allow one entity to have two roles –But require different pairwise master keys (PMK)

29. 802.11i Availability uNot an original design objective uPhysical Layer DoS attacks Inevitable but detectable, not our focus uNetwork and upper Layer DoS attack Depend on protocols, not our focus uLink Layer attack Flooding attack: Lots of traffic and power req’d Some Known DoS attacks in 802.11 networks DoS attack on Michael algorithm in TKIP RSN IE Poisoning/Spoofing 4-Way Handshake Blocking Failure Recovery

30. 4-Way Handshake Blocking AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC PTK Derived Random GTK PTK and GTK 802.1X Unblocked PTK and GTK 802.1X Unblocked Supplicant Auth/Assoc 802.1X Blocked PMK Authenticator Auth/Assoc 802.1X Blocked PMK AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce, sn, msg1

31. Countermeasures uRandom-Drop Queue Randomly drop a stored entry if the queue is full Not so effective uAuthenticate Message 1 Use the share PMK; must modify the packet format uReuse supplicant nonce Reuse SNonce, derive correct PTK from Message 3 Performance degradation, more computation in supplicant uCombined solution Supplicant reuses SNonce Store one entry of ANonce and PTK for the first Message 1 If nonce in Message 3 matches the entry, use PTK directly Eliminate memory DoS, only minor change to algorithm Adopted by TGi

32. Failure Recovery uFailure recovery is important Can reduce but not eliminate DoS vulnerabilities uCurrent 802.11i method When failure, restart everything: inefficient uA better failure approach If 802.1X does not finish, restart everything Otherwise restart from nearest completed subprotocol Channel scanning time is significantly larger than the protocol execution time

33. Improved 802.11i Stage 1: Network and Security Capability Discovery Stage 2: 802.1X authentication (mutual authentication, shared secret, cipher suite) Stage 3: Secure Association (management frames protected) Stage 4: 4-Way Handshake (PMK confirmation, PTK derivation, and GTK distribution) Stage 5: Group Key Handshake Stage 6: Secure Data Communications Michael MIC Failure or Other Security Failures Group Key Handshake Timout 4-Way Handshake Timout Association Failure 802.1X Failure

34. Summary of larger study ATTACKSSOLUTIONS security rollbacksupplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data. reflection attackeach participant plays the role of either authenti- cator or supplicant; if both, use different PMKs. attack on Michael countermeasures cease connections for a specific time instead of re-key and deauthentication; update TSC before MIC and after FCS, ICV are validated. RSN IE poisoningAuthenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage; Relax the condition of RSN IE confirmation. 4-way handshake blocking adopt random-drop queue, not so effective; authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory DoS.

35. 802.11i correctness proof in PCL uEAP-TLS Between Supplicant and Authentication Server Authorizes supplicant and establishes access key (PMK) u4-Way Handshake Between Access Point and Supplicant Checks authorization, establish key (PTK) for data transfer uGroup Key Protocol AP distributes group key (GTK) using KEK to supplicants uAES based data protection using established keys Our proof covers subprotocols 1, 2, 3 alone and in various combinations

36. SSL/TLS C ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone S [Certificate], ClientKeyExchange, [CertificateVerify] Finished switch to negotiated cipher Finished switch to negotiated cipher

37. TLS Protocol: Client The TLS Server actions also defined by a straight-line sequential process (cord)

38. TLS Properties uAuthentication: client and the server agree on Master secret Protocol version and crypto suite Each other’s identities Protocol completion status uSecrecy The master secret must not be known to any other principal

39. Theorems: Agreement and Secrecy Client is guaranteed: there exists a session of the intended server this server session agrees on the values of all messages all actions viewed in same order by client and server there exists exactly one such server session Similar specification for server

40. Invariants required by TLS Server Side Recommendation: If the server reuses Public Key in a protocol different from TLS, then it should not send decryptions of incoming messages

41. 4-Way handshake: Authenticator Supplicant actions also defined by a straight-line sequential process (cord)

42. 4-Way Handshake properties uThe pairwise key (PTK) is fresh and correctly generated from the PMK uMessages 2 and 4 assure authenticator that supplicant messages are current (not replay) uMessage 3 assures supplicant that authenticator messages are current (not replay) uPairwise key PTK derivation produces shared secret between supplicant and authenticator

43. 4-way Handshake Properties Similar specification for server

44. 4-Way : Relating invariants to deployment Recommendation: One Principal should not act as both authenticator and supplicant ! Otherwise, reflection attack. Consider careful deployment in Sensor Network scenarios

45. Group-Key Protocol

46. Group key handshake u Authenticator guarantee: If principal has the group key, then it must have a shared PTK with the authenticator uSupplicant guarantee: the GTK received was transmitted by the Access Point, and correctly supersedes any GTK from earlier handshakes (4-Way or Group Key) Observation: For assurance of GTK freshness, important that the first handshake uses 4-Way protocol; one principal should not be authenticator and supplicant, as in the 4-way handshake.

47. Composition u All necessary invariants are satisfied by basic blocks of all the sub- protocols u The postconditions of TLS imply the preconditions of the 4-Way handshake uThe postconditions of 4-Way handshake imply the preconditions of the Group Key protocol

48. Complex Control Flows Simple FlowComplex Flow

49. And what about mobility … ? uIPv4: Triangle routing All traffic routed through home agent uIPv6: Binding update Mobile node sends new “care-of address” Many risks –Attacker can subvert existing connection Announce false care-of address –Also, can send lots of packets to target Announce that target is new care-of address for many connections Arnab Roy

50. Representative protocol X Y H Mobile node Home agent Corresponding node X, Y, H 1 1 X, Y, hash(m, n, H, X) 4 4 Y, X, nY, H, m, X 2222 H, X, m, Y 3 3

51. Current situation uUnder strong assumptions Assume limited read access to messages Can prove that CN receives a good address uUnder more realistic assumptions Have found many attacks

52. Conclusions uProtocol analysis methods Model checking is fairly easy to apply Ready for industrial use uWireless 802.11i Automated study led to improved standard Deployment recommendations also uMobile networking Partial analysis so far No clear guarantees without key infrastructure