1 / 63

Wireless Security Potpourri

Wireless Security Potpourri. William A. Arbaugh Department of Computer Science University of Maryland waa @ cs.umd.edu http://www.cs.umd.edu/~waa. Students. Aram Khalili (LTS Funded) Nick Petroni (LTS Funded) Chuk Seng (LTS Funded) Arunesh Mishra Min-ho Shin (LTS Funded) Zhongchao Yu

vine
Download Presentation

Wireless Security Potpourri

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. Wireless Security Potpourri William A. Arbaugh Department of Computer Science University of Maryland waa @ cs.umd.edu http://www.cs.umd.edu/~waa

  2. Students • Aram Khalili (LTS Funded) • Nick Petroni (LTS Funded) • Chuk Seng (LTS Funded) • Arunesh Mishra • Min-ho Shin (LTS Funded) • Zhongchao Yu • Yuan Yuan

  3. Outline of Talk • Technology • Empirical Analysis of 802.11 hand-offs • Neighbor graphs • Proactive caching • Proactive key distribution for LANs and Interworking • Double Reverse NAT (DrNAT) • Ad-hoc networking • Probablistic based routing • Secure service discovery • Contextual based security associations

  4. Outline cont. • Standards Activity • TGf • Proactive caching • Network wide DoS found • Tgi • Proactive key distribution • Numerous DoS attacks • IETF • EAP • AAA • SEND

  5. One View of the Future CDMA1x Ad hoc extension WLAN

  6. Properties Required • Transparency • Security • Ubiquity • Performance

  7. Characterize the Problem • Roamingdelay = Layer1delay + Layer2delay + Layer3delay • We want the total roaming delay to be less than 50ms.

  8. Layer 2 (Inter-LAN) • Layer2delay = Probe + Decision + Association + Authentication • Probe – delay of scanning for next AP • Decision - delay of initiating roam • Associaiton – IEEE 802.11b association delay • Authentication – IEEE 802.11 authentication delay

  9. Prism2 (Zoomair) Data from Arunesh Mishra and Min-ho Shin

  10. Cisco Aironet 340

  11. Lucent

  12. STA APs PROBE PHASE Probe requests Probe responses New AP Other APs REASSOCIATION PHASE Reassociatiion request IAPP Reassociatiion response The Handoff Procedure • Probe Phase • STA scans for APs • Reassociation Phase • STA attempts to associate to preferred AP

  13. Average Values of Handoff Latencies The Handoff Procedure – Probe Phase • Empirical Results: • High latencies • Large variation Variation in Handoff Latencies

  14. Why is this important? • Hand-off times MUST be efficient to support synchronous connnections, e.g. VoIP • ITU guidance on TOTAL hand-off latency is that it should be less than 50 ms. Cellular networks try to keep it less than 35 ms.

  15. STA New AP Old AP Reassociation Request Send Security Block IAPP Messages Ack Security Block Move Notify Move Response Reassociation Response The Handoff Proceduure- Reassociation Phase - IAPP • Four IAPP Messages • IAPP Latency > 4 * RTT • Move Request and Move Response messages over TCP

  16. Neighbor Definition and Graph • Two APs i and j are neighbors iff • There exists a path of motion between i and j such that it is possible for a mobile STA to perform a reassociation • Captures the ‘potential next AP’ relationship • Distributed data-structure i.e. each AP or RS can maintain a list of neighbors A B A E C E C B D D 1

  17. AP Neighborhood Graph – Automated Learning • Construction • Manual configuration for each AP/RS or, • AP can learn: • If STA c sends Reassociate Request to AP i, with old-ap = AP j : • Create new neighbors (i,j) (i.e. an entry in AP i, for j and vice versa) • Learning costs only one ‘high latency handoff’ per edge in the graph • Enables mobility of APs, can be extended to wireless networks with an ad-hoc backbone infrastructure • Dynamic, i.e. stale entries time out • Easily extended to a server

  18. 3 STA B STA’s path of motion 2 Security Context STA 1 Proactive Caching Algorithm • Key Idea : • Propagate security contexts to potential ‘next’ APs to eliminate IAPP latency during reassociation 1. STA associates to AP A 2. AP A sends security context to AP B proactively (new IAPP message) 3. STA moves to AP B – does fast reassociation since B has security context in cache A

  19. Proactive Caching – The Algorithm • When STA c associates/reassociates to AP i • If context(c) in cache: • Send Reassociate Response to client • Send Move-Notify to Old-AP • If context(c) not in cache, perform normal IAPP operation • Send security context to all Neighbours(i) • Cache Replacement : Least Recently Used • Cache size vendor dependent

  20. IAPP Messages with Proactive Caching • STA reassociates to AP A • AP A has security context in cache • AP A propagates context to AP B (all neighbors of A) • STA reassociates to AP B which again has security context in cache STA AP A AP B Context in Cache Reassociation Request Reassociation Response Propagate context Context stored in cache Reassociation Request Context in Cache Reassociation Response

  21. Proactive Caching – Latency Improvements • Measurements based on Soekris/OpenBSD platform using Prism2 HostAP driver. • AP shared secrets preloaded on AP’s, i.e. no RADIUS or security block messages included. • Basic Reassociation : 1.119 ms • Reassociation with IAPP : 16.392 ms • IAPP with Proactive-caching : 1.319 ms

  22. Proactive Caching – Latency Improvements • Measurements based on Pentium 4 laptop (IBM Thinkpad T23) using Prism2 HostAP driver. • AP shared secrets preloaded on AP’s, i.e. no RADIUS or security block messages included. • Basic Reassociation : 1.583 ms • Reassociation with IAPP : 12.67 ms • IAPP with Proactive-caching : 1.982 ms

  23. Proactive Caching – Expected Performance • Handoff latencies play a role in performance when mobility is high • With LRU cache, higher the mobility, higher the cache-hit ratio (on average), implies larger number of fast-handoffs Cache Hit Ratio Mobility

  24. TGi Fast Roaming Goals • Handoff to next AP SHOULD NOT require a complete 802.1x re-authentication. • Compromise of one AP MUST NOT compromise past or future key material, i.e. back traffic protection and perfect forward secrecy.

  25. TGi Trust Assumptions • AAA Server is trusted • AP to which STA is associated is trusted.

  26. Only Two Ways • Exponentiation support for assymmetric cryptographic operations at AP, or • Trusted Third Party, i.e. Roaming Server

  27. Proactive Key Distribution (TGi) • Extend Neighbor Graphs and Proactive Caching to a Roaming Server • Eliminates problems with sharing key material amongst multiple APs • Easily extended to support WAN roaming • Possibly extendable to support Interworking

  28. Master Key (MK) Pairwise Master Key (PMK) = TLS-PRF(MasterKey, “client EAP encryption” | clientHello.random | serverHello.random) Pairwise Transient Key (PTK) = EAPoL-PRF(PMK, AP Nonce | STA Nonce | AP MAC Addr | STA MAC Addr) Key Confirmation Key (KCK) – PTK bits 0–127 Key Encryption Key (KEK) – PTK bits 128–255 Temporal Key – PTK bits 256–n – can have cipher suite specific structure TGi Pairwise Key Hierarchy

  29. Key Locations MK PMK RADIUS (AAA) PMK PTK AP1 AP2 MK PMK PTK

  30. A B A E C E C B D D Roaming Example • Given the following infrastructure with associated neighbor graph with STA about to associate to AP A.

  31. Pre Association RADIUS (AAA) A B C D E

  32. Post Authentication and 4-handshake MK PMK RADIUS (AAA) PMK PTK A B C D E MK PMK PTK

  33. Pre-authentication Full 802.1X Authentication Via Next AP MK PMK RADIUS (AAA) PMK PTK A B C D E MK PMK PTK

  34. Problems with Pre-Auth • Expensive in terms of computational power for client, and time (Full EAP-TLS can take seconds depending on load at RADIUS Server). • Requires well designed and overlapping coverage areas • Edge cases

  35. Proactive Key Distribution MK,PMK MK PMK Roam Server RADIUS (AAA) PMK PTK A B C D E MK PMK PTK

  36. Proactive Key DistributionPost Authentication MK PMKA Roam Server PMKB=TLS-PRF(MK, PMKA, APB-MAC-Addr, STA-MAC-Addr) PMKE=TLS-PRF(MK, PMKA, APE-MAC-Addr, STA-MAC-Addr) RADIUS (AAA) PMKE PMKB PMKA PTK PMKB A B C D E PMKE MK PMKA PTK

  37. Proactive Key DistributionSTA Roam to AP B MK PMKA Roam Server PMKB Old and new AP’s inform RS PMKE RADIUS (AAA) RS builds Neighbor Graph PMKA PTK PMKB A B C D E PMKE PMKB=TLS-PRF(MK, PMKA, APB-MAC-ADDR, STA-MAC-ADDR) PTK via standard 4-way handshake

  38. Proactive Key DistributionSTA Roam to AP B Roam Server MK PMKA’ PMKB PMKC PMKD PMKE’ RADIUS (AAA) PMKB PTK A PMKA’ B C PMKC D PMKD E PMKE’ MK PMKB PTK

  39. Proactive Key Distribution Protocol • STA associates to AP1. • STA performs 802.1X EAP-TLS authentication with (AP1, AS). • AS and STA derive the PMK = TLS-PRF(MasterKey, "client EAP Encryption" | clientHello.random | serverHello.random). • AS sends PMK to AP1. • AP1 and STA derive PTK via any method, e.g. 4-way handshake • AP1 and STA derive GTK in usual way • AS constructs PMK2 = TLS-PRF(MasterKey, PMK1, AP2-MAC-Addr, STA-MAC-Addr) • AS sends PMK2 to AP2 • Steps 7 and 8 performed for each AP in Neighbor(AP1)

  40. Protocol cont. • STA roams to AP2 • STA derives PMK2 = TLS-PRF(MasterKey, PMK1, AP2-MAC-Addr, STA-MAC-Addr) • AP2 and STA derive PTK via key agreement, e.g. 4-way handshake • AP2 and STA derive GTK in usual way • STA can resume data traffic • AP1 and AP2 inform AS of the roam • AS constructs PMK3 = TLS-PRF(MasterKey, PMK2, AP3-MAC-Addr, STA-MAC-Addr) • AS sends PMK3 to AP3 • Steps 7 and 8 done for each AP in Neighbor(AP2)

  41. Why a Roaming Server? • Not actually required (could use current AAA server) but: • May load RADIUS/DIAMETER host too much • Requires retention of state which RADIUS tries to avoid

  42. Inter-LAN and Intra-WAN Roaming • IP address change too costly (Layer 3 delay) • Current solutions (Mobile IP and IPv6) suffer from deployment problems. • Mobile IP suffers from additional delays due to home agent

  43. Our Approach • Use double reverse network address translation (DRNAT) to eliminate IP address change. • If a second device is used, use “smart” look ahead

  44. DRNAT Host A Can be placed In edge router IP A DRNAT IP 1 Net 2 IP 3 Host B IP 2 Net 1 DRNAT IP B

  45. Advantages of DRNAT • Can be realized in software or hardware • Requires no infrastructure changes • Can be placed in the infrastructure to support non-mobile hosts

  46. Inter-LAN Roaming • Proactive key distribution handles security well. • Proactive caching handles other AP context well.

  47. Intra-LAN and WAN Roaming • The approach will be to define a Roaming station to Roaming station message protocol for AAA. • DRNAT remains useable as a client only approach which requires no standards activity.

  48. Ad Hoc Network Security We’re focusing on: • Availability • The major function of routing • A non-trivial aspect of ad hoc network security

  49. SUCV • SUCV Address • Due to the cryptography difficulty, it’s hard to impersonate a given SUCV address node, by using another private-public key pair. • Dilemma: the malicious node is able create arbitrary virtual nodes, with new SUCV addresses. Routing prefix (64 bits) SUCV ID (64 bit) SUCV ID = Hash1 [ Hash2(imprint), Hash2(Public Key)]

  50. Problems with SUCV S T Virtual network Assign corresponding SUCV address Malicious node Virtual node Create public-private key pair

More Related