1 / 53

Analysis of Security Protocols for Wireless Networks

Analysis of Security Protocols for Wireless Networks. Changhua He Stanford University May 31 st , 2005. Outline. Wireless Security Overview Wireless threats IEEE 802.11i Finite-state Verification on 4-Way Handshake Breaking and Fixing IEEE 802.11i Standard

lamya
Download Presentation

Analysis of Security Protocols for Wireless Networks

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. Analysis of Security Protocols for Wireless Networks Changhua He Stanford University May 31st, 2005

  2. Outline • Wireless Security Overview • Wireless threats • IEEE 802.11i • Finite-state Verification on 4-Way Handshake • Breaking and Fixing IEEE 802.11i Standard • Modular Proof of 802.11i Security • 802.11i Helps Ad Hoc Routing Security • Conclusions

  3. Wireless Everything Public Internet Printing Outdoor Home/Office Cellular Network Hands-free Headset Synchronization Dial-Up Networking 802.16 BS Mobile Data Services WiMAX 802.11 WLAN Bluetooth PAN Human Interface Devices Hands-free Speakerphone

  4. Wireless Threats • Passive Eavesdropping/Traffic Analysis • Easy, most wireless NICs have promiscuous mode, cheap man-made antenna can enlarge the signal range greatly • Message Injection/Active Eavesdropping • Easy, some techniques to gen. any packet with common NIC, exploit MAC cooperation to interfere in a timely way • Message Deletion and Interception • Possible, interfere packet reception with directional antennas • Masquerading and Malicious AP • Easy, MAC address forgeable and software available (HostAP) • Session Hijacking • Man-in-the-Middle • Denial-of-Service (DoS)

  5. Wireless Security Evolution • 802.11 WEP (Wired Equivalent Protocol) • Authentication: Open System (SSID) or Shared Key • Authorization: some vendor use MAC address filtering • Confidentiality/Integrity: RC4 + CRC • Completely insecure – bad use of good crypto • 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, e.g., EAP-TLS/802.1X/RADIUS • Data confidentiality and integrity: CCMP (believed secure) • Key management protocols [Walker00], [Wagner01], [Arbaugh et al 01], [Arbaugh02], [FMS01] …

  6. 802.11i: RSNA Procedures Supplicant Auth/Assoc 802.1X Blocked MSK Supplicant Auth/Assoc 802.1X Blocked PMK Supplicant Auth/Assoc 802.1X UnBlocked New GTK Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK Supplicant Auth/Assoc 802.1X Blocked No Key Supplicant UnAuth/UnAssoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X Blocked PMK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorUnAuth/UnAssoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X Blocked No Key AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X UnBlocked New GTK Authentica-tion Server(RADIUS) 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 802.11 Association EAP/802.1X/RADIUS Authentication MSK 4-Way Handshake Group Key Handshake Data Communication

  7. Outline • Wireless Security Overview • Finite-state Verification on 4-Way Handshake • Use Murφ to verify 4-Way Handshake • Attacks and solutions in detail • Breaking and Fixing IEEE 802.11i Standard • Modular Proof of 802.11i Security • 802.11i Helps Ad Hoc Routing Security • Conclusions

  8. Using Murφ to Verify Protocols Informal Protocol Description Formal Protocol Intruder Model Murj code Murj code, similar for all protocols RFC, IEEE Std. Analysis Tool Find error/Diagnose Set initial states, specify security conditions, run Murj

  9. The 4-Way Handshake Supplicant Auth/Assoc 802.1X UnBlocked PTK/GTK AuthenticatorAuth/Assoc 802.1X UnBlocked PTK/GTK Authentica-tion Server(RADIUS) No Key 802.11 Association EAP/802.1X/RADIUS Authentication {AA, ANonce, sn, msg1, PMKID} {SPA, SNonce, SPA RSN IE, sn, msg2, MIC} {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC} {SPA, sn+1, msg4, MIC} Group Key Handshake Data Communication MSK

  10. Study of the 4-Way Handshake • Assumption • PMK is shared between the Supplicant and the Authenticator • Handshake Goals • Confirm the possession of PMK in peers • Derive a fresh session key for data transmission • Murj Modeling • one association between each pair of authenticator and supplicant • Each association has a uniquely shared PMK • Multiple handshakes in one association • Intruder can impersonate, eavesdrop, intercept, modify, etc. • Analysis • Based on the 2003 specifications of the 4-Way Handshake • Murj verification using “rationale reconstruction”

  11. Authenticator Sends Msg 1 (Murj) ruleset i: AuthenticatorId do ruleset j: AgentId do rule 20 "Authenticator sends Message 1 to associated Supplicants" !ismember(j, AuthenticatorId) & -- no message to Authenticators !ismember(j, IntruderId) & -- no message to Intruders multisetcount(l:net, true) < NetworkSize & (aut[i].associations[j].session.state = A_PMKSA | aut[i].associations[j].session.state = A_DONE) ==> var outM: Message; -- outgoing message begin outM.source := i; outM.dest := j; outM.mtype := M_1; outM.nonce := freshNonce(); outM.sequence := freshSequence(); outM.address := i; multisetadd(outM, net); aut[i].associations[j].peer := j; aut[i].associations[j].pmk := usePMK(i, j); aut[i].associations[j].sequence := outM.sequence; aut[i].associations[j].nonce := outM.nonce; aut[i].associations[j].session.state:= A_WAITFORNS; end; end; end; Similar Codes for the supplicant and other states

  12. Invariant: Security Conditions • Invariants represent security conditions • Violations in any state indicate possible attacks invariant "PTKs are consistent and fresh" forall i: AuthenticatorId do forall j: SupplicantId do aut[i].associations[j].session.state = A_DONE -> (sup[j].associations[i].session.state = S_DONE & ptkEqual(aut[i].associations[j].session.ptk, sup[j].associations[i].session.ptk) & aut[i].associations[j].sid = sup[j].associations[i].sid) | (sup[j].associations[i].session.state = S_PTKSA & aut[i].associations[j].sid <= sup[j].associations[i].sid) end; end;

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

  14. 4-Way Blocking Exposed • What is wrong here ? • Message 1 is vulnerable • Noticed, TPTK/PTK to eliminate the problem • Suppose only one handshake on-going • Not true in wireless scenario ! • Interleaving handshakes are possible • Authenticator can enforce only one handshake • Reject unexpected messages • Supplicant cannot • Must accept Msg 1 in any state due to packet loss and retransmission • Attacker forges Msg 1 to cause parallel incomplete handshakes • Supplicant MUST keep state for every Msg 1 • DoS, similar to TCP SYN flooding attack

  15. 4-Way Blocking: Solution 1 Random-Drop Queue: Randomly drop a stored entry to adopt the state for the incoming Message 1 if the queue is filled. Not so effective

  16. 4-Way Blocking: Solution 2 • Authenticate Message 1 • To reuse the algorithms/hardware, set nonces to special values, e.g., 0, and derive PTK. • Calculate MIC for Msg 1 using the derived PTK • Good solution if PMK is fresh • If PSK and cached PMK, replay attacks ! • Add a monotonically increasing global sequence counter • Use local time in authenticator side • Sufficient space in Message 1 ( 8-octet sequence field ) • No worry about time synchronization Modifications on packet format

  17. 4-Way Blocking: Solution 3 • Re-Use Nonce • Supplicant re-use SNonce until one 4-way handshake completes successfully • Derive correct PTK from Message 3 • Authenticator may (or may not) re-use ANonce • Solve the problem, but • Attacker might gather more information about PMK by playing with Message 1, ok if PMK is strong PTK=PRF{PMK, AA||SPA||ANonce||SNonce} • More computations in the supplicant Performance Degradation

  18. 4-Way Blocking: Final Solution • Combined solution • Supplicant re-use SNonce • Store one entry of ANonce and PTK for the first Message 1 • If nonce in Message 3 matches the entry, use PTK directly; otherwise derive PTK again and use it. • Advantages • Eliminate the memory DoS attack • Ensure performance in “friendly” scenarios • Only minor modifications on the algorithm in the Supplicant • No modifications on the packet format • Adopted by TGi • Simple solution, but not immediate

  19. Outline • Wireless Security Overview • Finite-state Verification on 4-Way Handshake • Breaking and Fixing IEEE 802.11i Standard • Authentication problems • Security level roll back attack, reflection attack • Availability problems • 4-Way blocking, RSN IE Poisoning/Spoofing, Michael algorithm • Modular Proof of 802.11i Security • 802.11i Helps Ad Hoc Routing Security • Conclusions

  20. Security Level Rollback Attack Bogus Beacon (Pre-RSNA only) Bogus Probe Response (Pre-RSNA only) Bogus Association Request (Pre-RSNA only) Pre-RSNA Connections Supplicant RSNA enabled Pre-RSNA enabled AuthenticatorRSNA enabled Pre-RSNA enabled Beacon + AA RSN IE Probe Request Probe Response + AA RSN IE 802.11 Authentication Request 802.11 Authentication Response Association Request + SPA RSN IE 802.11 Association Response Pre-RSNA connection is INSECURE!

  21. Security Rollback: solutions • Consequences of rollback attack • Similar to general version-rollback attack • Destroy the security since WEP is completely insecure • Not a real vulnerability of 802.11i standard, but an important deployment problem • Solutions • Allow only RSNA connections • too strict if Transient Security Network is still in use • Deploy both, but • Allow supplicant to manually choose to deny or accept • Authenticator may limit pre-RSNA (WEP) connections to less sensitive data

  22. Reflection Attack {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} Bogus Authentication Peers Authenticated Adversary Impersonates Communicating Peers Legitimate Devices Authenticator and Supplicant

  23. Reflection Attack: Solutions • Consequences of reflection attack • Possible in ad hoc networks: Each participant plays the role of both authenticator and supplicant • Violate mutual authentication • Solutions • Restrict each entity to single role • Access Point should not act as wireless station • Allow one entity to have two roles • But require different Pairwise Master Keys (PMK) • Derive different PTKs for the two handshakes • The pairing relationship (address, nonce) is different • But requires modifications, incompatibility caused

  24. 802.11i: Availability • Not an original design objective • Physical Layer DoS attack • Inevitable but expensive and detectable, not our focus • Network and upper Layer DoS attack • Depend on protocols, not our focus • Link Layer DoS attack • Flooding attack: lots of traffic and power required • Some Known DoS attacks on unprotected management frames • 4-Way Handshake Blocking • RSN IE Poisoning/Spoofing • Attack on TKIP Michael Countermeasure • Failure Recovery These risks can be reduced!

  25. 4-Way Handshake Blocking AA, ANonce, sn, msg1 SPA, SNonce, SPA RSN IE, sn, msg2, MIC AA, ANonce[1], sn, msg1 AA, ANonce[n], sn, msg1 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

  26. 4-Way Blocking: Solutions • Random-Drop Queue: not so effective • Authenticate Message 1 • Make use of the share PMK, but need to modify packet format • Re-use supplicant nonce • Supplicant re-use SNonce, eliminate memory DoS • Performance degradation, more computations in the supplicant • Combined solution (Adopted by TGi) • Supplicant re-use SNonce • Store one entry of received ANonce and derived PTK • If ANonce in Message 3 matches the entry, use PTK directly; otherwise derive PTK from Message 3 and use it • Eliminate the attack, ensure performance in “friendly” scenarios, only minor modifications on the algorithm

  27. RSN IE Poisoning Bogus Beacon + Modified RSN IE Bogus Probe Response + Modified RSN IE Disassociate the Supplicant RSN IE confirmation failed, Disassociation Supplicant Unauthenticated Unassociated 802.1X Blocked AuthenticatorUnauthenticated Unassociated 802.1X Blocked (1) Beacon + AA RSN IE (2) Probe Request (3) Probe Response + AA RSN IE Legitimate Message Exchanges (18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}

  28. RSN IE Poisoning: Solutions • Consequences of RSN IE Poisoning • Less work for the attacker, easy to launch the attack • Lots of work for legitimate parties, wasting resources • Solutions • Authenticate management frames • Difficult to authenticate Beacon and Probe Response frame • Confirm RSN IE as soon as possible (EAP-TLS) • Necessary modifications on the standard • Relax the condition of RSN IE confirmation • Ignore insignificant bits, only confirm authentication suite • If authentication suite modified, probably fails at the beginning of associations and retry new APs

  29. Michael and Countermeasures MAC IV/KeyID Ext. IV Data/MSDU MIC ICV FCS Contains TSC Encrypted TKIP MPDUFormat • TKIP Michael algorithm and countermeasures • Michael algorithm provides 20-bit security for MIC • Exhaustive forgery attempts only need 2 minutes in 11Mbps • Rate limit the forgery attempts • If two Michael MIC failures logged in one minute • Cease communication for 60 seconds • Need 6 months for exhaustive forgery attempts • MIC failure logged only after FCS, ICV, TSC are validated • FCS and ICV can be computed easily MIC: Message Integrity Code ICV: Integrity Check Value (from WEP) FCS: Frame Check Sequence TSC: TKIP Sequence Counter

  30. Michael DoS and Solutions • DoS attack by enforcing MIC failures • Obtain a packet with valid TSC but invalid MIC • Intercept a packet with valid TSC • Modify the packet and corresponding values of FCS, ICV • Send modified packet twice to cause two MIC failures • Send the same packet again and again … • TSC is updated only after MIC is validated • Solutions • Update TSC before MIC is validated • What happens if modify TSC to extremely large number? • Change TSC => change encryption key => wrong decryption • Not a problem if TKIP key schedule algorithm not broken • Mitigate but not eliminate the vulnerability

  31. Unprotected Management Frame • DoS attacks on plain 802.11 networks • Forge the management frame • Deauthentication/Disassociation • Exploit virtual carrier sense mechanism • Forge unprotected control frame RTS/CTS • 802.11i still has these problems, solutions could be • Authenticate management frames • Validate virtual carrier sense in control frames • DoS attacks on EAP messages • Forge EAPOL-Start/Success/Logoff/Failure packets • 802.11i can eliminate these by simply ignoring such messages ! • Send more than 255 association requests • Exhaust EAP identifier space (8 bits) • Solution: separate EAP identifier counter for each association [Arbaugh et al 01] [Lynn02] [Moore02] [Bellardo et al 03] [Chen04] …

  32. Summary of Vulnerabilities

  33. Failure Recovery • Failure recovery is important • Can reduce but not eliminate DoS vulnerabilities • 802.11i adopts a simple scheme • Whenever failure, restart from the beginning, inefficient ! • A better failure recovery for 802.11i • If 802.1X does not finish, restart everything • Otherwise restart from nearest completed components • Difficult to forge an 802.1X authentication • User moves to another AP after 802.1X authentication ? • Not a problem since channel scanning time is significantly larger than the protocol execution time

  34. Improved 802.11i Architecture 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

  35. Outline • Wireless Security Overview • Finite-state Verification on 4-Way Handshake • Breaking and Fixing IEEE 802.11i Standard • Modular Proof of 802.11i Security • Correctness Proof of each components • Staged composition of 802.11i • 802.11i Helps Ad Hoc Routing Security • Conclusions

  36. General Ideas • Proof of security is necessary and useful • “Head-scratching” approach is inconvincible • Finite-state verification is incomplete • Proof for unbounded number of participants and sessions • Intuition • Reason about local information • I know my own actions and private data • Incorporate knowledge of protocol • Honest people faithfully follow the protocol • No explicit reasoning about intruder • Divide-and-conquer paradigm in security • Divide a large protocol into several components • Reason the security properties of each component • Analyze the compositions of all components

  37. Protocol Composition Logic • Abstraction based on Dolev-Yao Model [1983] • “Black-box” cryptography • No partial knowledge, no statistical tests, … • Cord calculus as protocol programming language • Arrows-and-messages are informal • “Cord” program for each protocol role • Execution model: Protocol, initial configuration, run • Protocol logic to state security properties • Modal form: ┣ [ actions ]P • Proof system to formally prove the properties • Axioms, proof rules, soundness theorem • Composition Reasoning

  38. 4-Way Authenticator Formalism Key Secrecy 4way,sec Honest(X)  Honest(Y)  Has(X, PTKXY)  Has(Y, PTKXY)  (Has(Z, PTKXY)  (Z = X  Z = Y)) Session Authentication4way,auth Y. Honest(X)  Honest(Y)  ActionsInOrder( Send(X, {X, Y, Message 1}), Receive(Y, {X, Y, Message 1}), Send(Y, {Y, X, Message 2}), Receive(X, {Y, X, Message 2}), Send(X, {X, Y, Message 3}), Receive(Y, {X, Y, Message 3}), Send(Y, {Y, X, Message 4}), Receive(X, {Y, X, Message 4})) 4WAY:AUTH = (X, Y, PMKXY)[ new x; send X, Y, x, m1; receive Y, X, z; match z/y,m2,mic1; match Hash(PMKXY,x,y)/ PTKXY; match mic1/Hash(PTKXY,y,m2); send X,Y,x,m3,Hash(PTKXY,x,m3); receive Y, X, w; match w/m4, mic2; match mic2/Hash(PTKXY, m4)]X Pre-condition θ4way Has(X, PMKXY)  Has(Y, PMKXY)  (Has(Z, PMKXY)  (Z = X  Z = Y))

  39. 4-Way Authenticator Guarantee Theorem 1 (4-Way Authenticator) (i) 4way,1 ∧ 4way,2 ∧ 4way,3┣ θ4way [4WAY:AUTH]X4way,auth∧ 4way,sec (ii) 4WAY┣ 4way,1 ∧ 4way,2 (i) On execution of the authenticator role, key secrecy and session authentication are guaranteed if 4way,1, 4way,2 and4way,3 hold. (ii) 4way,1 and 4way,2 are invariants of the 4-Way Handshake; 4way,3 is an assumption on the environment. Similar theorem for the supplicant

  40. Invariants & Operating Environment • Invariants identify the environmental requirements • Satisfied by the protocol • Preserved by concurrent protocols • For the 4-Way Handshake • 4way,1 states that honest parties never disclose the shared PMK to others • 4way,2 states that the party who computes PTK will never send out PTK over the network • 4way,3 states that the honest party should have single role, this is an assumption on the environment 4way,1:= Honest(X)  Honest(Y)  (Has(Z, PMKXY)  (Z = X  Z = Y)) 4way,2 := Computes(X, Hash(PMKXY,x,y)) ¬(Send(X, m)  Contains(m, Hash(PMKXY,x,y) )) 4way,3 := Honest(X)  Receive(X, Message 1) ¬ Send(X, Message 3)  Honest(X)  Send(X, Message 1) ¬ Send(X, Message 2)  ¬ Send(X, Message 4)

  41. Results for Other Components • Improved 4-Way Handshake • Re-use SNonce in the supplicant to eliminate DoS • While{…} loop to express the protocol • Same guarantees for key secrecy and session authentication • TLS • key secrecy and session authentication, similar to 4-Way • Both side proofs • Identify the operational environment • Group Key Handshake • Key ordering for the supplicant • Key secrecy for the authenticator • Identify the operational environment

  42. 802.11i: Staged Composition • Control Flow • Intended run is sequential • Different Failure Recovery mechanisms can be implemented for efficiency • Periodically update Group Key, PTK, PMK (omit here) • Hybrid modes • Pre-Shared Key (PSK) used directly instead of EAP authentication methods • Cached PMK might be used for mobile users • Alternatives for EAP-TLS, e.g., PEAP, LEAP EAP-TLS PMK 4-Way PTK Group Key GTK Data Transmission

  43. Study of Compositions • Composition requirements • Non-destructive combination • Ensure that the components do not degrade each other’s security (invariants) • Additive combination: • Accumulate security properties of combined parts, assuming they do not interfere • Composition theorems • Parallel composition • Sequential composition • Staged Composition • 802.11i components compose safely • All failure recovery methods are correct • Can choose according to deployment conditions • Hybrid modes (PSK, Cached PMK) still guarantee correctness

  44. 802.11i Proof Sketch Step 1.i,i┣ θi [Pi]Xi Separate proof of individual components TLS, 4-Way, and Group Key Handshake; Step 2.i, j,Pi┣ j Necessary invariants are satisfied by all components; Step 3.i,i θi+1 The postconditions of TLS imply preconditions of 4-Way; postconditions of 4-Way imply preconditions of Group Key; Step 4.i,θi [Q]Xθi The preconditions of each component are preserved by subsequent components. Applying the Staged Composition Theorem, 802.11i is correct.

  45. Outline • Wireless Security Overview • Breaking and Fixing IEEE 802.11i Standard • Finite-state Verification on 4-Way Handshake • Modular Proof of 802.11i Security • 802.11i Helps Ad Hoc Routing Security • 802.11i enforces local attacker model • Link security + secure routing under local attacker model • Conclusions

  46. Ad Hoc Routing Security • Secure routing is important • Previous work: common routing + cryptographic improvements • Most proposals based on on-demand (reactive) routing • No false route accepted • Common problems • Many secure routing is very complicated • Some attacks are still possible • Assume key management among everybody prior to routing • Motivations • To make it secure, keep it simple ! • 802.11i is supposed to be widely deployed, can we take advantage of that?

  47. Observations A F D S T E B C • 802.11i provides hop-by-hop security • Neighborhood authentication + Identity Binding • IPsec or other protocols to provide end-to-end security • If all good nodes, common routing protocol works • Compromised nodes can cause problems • Link layer security => Local Attacker model • Eliminate outside attacker, only inside attacker • Reduce global attacker to local attacker

  48. Link Security + “Weaker” Routing • Local Attacker Model • Compromised node or geographic limitations • Attacker can only touch its neighbors • A weaker attacker model • Network is not controlled by the attacker • If the attacker wants to control the network, it will try to attract all traffic passing through itself • Secure routing under local attacker model • Find good route with high probability • Idea (informal) • Link security + secure routing under local attacker model gives secure routing under global attacker model • Advantages • Decompose secure routing to two problems • “Simplify” the secure routing design (802.11i already done) • No need for key pre-distribution among everybody

  49. Dynamic Source Routing A F D S T E B C • Route Discovery • An initiator sends out Route Request <SID, TID, REQ-ID> • Each intermediate node either discards the request if already process it or appends its own address and rebroadcasts • The target sends Route Reply back to initiator • Don’t consider • Route maintenance: route error messages • Routing optimization: caching routes • Mobility

  50. Defend Against Local Attacker • Reply a false route • Target node authenticate the route reply • Claim false path to target • Not always success to reach target • Source randomly pick one from multiple routes • If transmit fail, use other routes • Duplicate suppression • Source pick REQ-ID randomly • Rushing attack • Intermediate node randomly pick one to forward among k requests • Wormhole attack • Not possible if only one node compromised • Not a problem if multiple nodes compromised but no side channel • If side channel exists, need other restrictions • Route request flooding can be reduced by rate limit

More Related