1 / 53

Protocol analysis, wireless networking, and mobility

Protocol analysis, wireless networking, and mobility. John Mitchell Stanford University. Many security Protocols. Challenge-response ISO 9798-1,2,3; Needham-Schroeder, … Authentication Kerberos Key Exchange SSL handshake, IKE, JFK, IKEv2, Wireless and mobile computing

gaye
Télécharger la présentation

Protocol analysis, wireless networking, and mobility

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Many security Protocols • Challenge-response • ISO 9798-1,2,3; Needham-Schroeder, … • Authentication • Kerberos • Key Exchange • SSL handshake, IKE, JFK, IKEv2, • Wireless and mobile computing • Mobile IP, WEP, 802.11i • Electronic commerce • Contract signing, SET, electronic cash, …

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

  4. 802.11i Wireless Authentication

  5. Transport (TCP) Internet (IP) Network interface Physical layer TLS protocol layer over TCP/IP http ftp telnet Application nntp SSL/TLS

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

  7. Handshake Protocol ClientHelloCSC, VerC, SuiteC, NC ServerHelloS  CVerS, SuiteS, NS,signCA{S, KS} ClientVerify C  SsignCA{ C, VC} {VerC, SecretC} signC {Hash(Master(NC, NS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) } (Change to negotiated cipher) ServerFinished S  C{ Hash(Master(NC, NS, SecretC) + Pad2 + Hash(Msgs + S + Master(NC, NS, SecretC) + Pad1)) } ClientFinishedC  S{ Hash(Master(NC, NS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NS, SecretC) + Pad1)) } KS Master(NC, NS, SecretC) Master(NC, NS, SecretC)

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

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

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

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

  12. Murj [Dill et al.] • Describe finite-state system • State variables with initial values • Transition rules • Communication by shared variables • Scalable: choose system size parameters • Automatic exhaustive state enumeration • Space limit: hash table to avoid repeating states • Research and industrial protocol verification

  13. Applying Murj to security protocols • Formulate 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(…))) • Add 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 Murj(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 Murj(2) MessageType : enum { --types of messages M_NonceAddress, --{Na, A}Kb nonce and addr M_NonceNonce, --{Na,Nb}Ka two nonces M_Nonce --{Nb}Kbone 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 Murj(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; end; end;

  17. Run of Needham-Schroeder • Find error after 1.7 seconds exploration • Output: trace leading to error state • Murj times after correcting error:

  18. State Reduction on N-S Protocol

  19. Security Protocols in Mur • Standard “benchmark” protocols • Needham-Schroeder, TMN, … • Kerberos • Study of Secure Sockets Layer (SSL) • Versions 2.0 and 3.0 of handshake protocol • Include protocol resumption • Tool optimization • Additional protocols • Contract-signing • Wireless networking … ADD YOUR PRODUCT HERE …

  20. CS259 Term Projects Homework

  21. Changhua He Wireless Threats • Passive Eavesdropping/Traffic Analysis • Easy, most wireless NICs have promiscuous mode • Message Injection/Active Eavesdropping • Easy, some techniques to gen. any packet with common NIC • Message Deletion and Interception • Possible, interfere packet reception with directional antennas • Masquerading and Malicious AP • Easy, MAC address forgeable and s/w available (HostAP) • Session Hijacking • Man-in-the-Middle • Denial-of-Service: cost related evaluation

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

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

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

  25. Solutions • Security 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 • Solutions • 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

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

  27. Reflection Solutions • Possible in ad hoc networks • Violates mutual authentication • Solutions: • 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)

  28. 802.11i Availability • Not an original design objective • Physical Layer DoS attacks • Inevitable but detectable, not our focus • Network and upper Layer DoS attack • Depend on protocols, not our focus • Link 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

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

  30. Countermeasures • Random-Drop Queue • Randomly drop a stored entry if the queue is full • Not so effective • Authenticate Message 1 • Use the share PMK; must modify the packet format • Reuse supplicant nonce • Reuse SNonce, derive correct PTK from Message 3 • Performance degradation, more computation in supplicant • Combined 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

  31. Failure Recovery • Failure recovery is important • Can reduce but not eliminate DoS vulnerabilities • Current 802.11i method • When failure, restart everything: inefficient • A 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

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

  33. Summary of larger study

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

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

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

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

  38. 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

  39. 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

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

  41. 4-Way Handshake properties • The pairwise key (PTK) is fresh and correctly generated from the PMK • Messages 2 and 4 assure authenticator that supplicant messages are current (not replay) • Message 3 assures supplicant that authenticator messages are current (not replay) • Pairwise key PTK derivation produces shared secret between supplicant and authenticator

  42. 4-way Handshake Properties Similar specification for server

  43. 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

  44. Group-Key Protocol

  45. Group key handshake • Authenticator guarantee: If principal has the group key, then it must have a shared PTK with the authenticator • Supplicant 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.

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

  47. Complex Control Flows Simple Flow Complex Flow

  48. Arnab Roy And what about mobility … ? • IPv4: Triangle routing • All traffic routed through home agent • IPv6: 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

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

More Related