Usable Security for Wi-Fi LANs

1. Usable Security for Wi-Fi LANs Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh jcb@cs.pitt.edu Joint work with Haidong Xia

2. Motivation • Weaknesses of original Wi-Fi security well-publicized • However, poor usability is arguably the more worrisome problem • about 2 out of every 3 Wi-Fi networks are open • anybody can get in • about 1 out of every 3 Wi-Fi networks operate in out-of-the-box configuration with default passwords • anybody can change firmware Jose' Brustoloni

3. How can security be made more usable? In general, there are three alternatives • Make security transparent / “just work” • Improve user interfaces for security functions • Better educate/train users We exploit and compare all three alternatives in this work Jose' Brustoloni

4. What do Wi-Fi hotspots do? • Need to interoperate readily with whatever hardware/software users have • No on-site tech support available • Primary security concern is theft of service • Increasing concern about man-in-the-middle (aka “evil twin” or rogue access point attack) Jose' Brustoloni

5. User authentication in Wi-Fi hotspots:Captive portals AP • Readily interoperable, easy-to-use authentication • User’s Web browser automatically redirected to captive portal • SSL-secured page where user enters id and password • may use a variety of back-ends for authentication (Kerberos, RADIUS, LDAP) • After authentication, user’s MAC and IP addresses are authorized • First proposed by Stanford’s SPINACH project (INFOCOM’99) • Widely used in university campuses and commercial hotspots Internet plain Wi-Fi Captive portal default client AP intranet AP Jose' Brustoloni

6. Theft of service bysession hijacking • Hijacker snoops victim’s MAC and IP addresses and access point’s MAC address • Periodically sends to victim 802.11 disassociation or deauthentication notifications purported to come from access point (causing denial-of-service) • Hijacker uses victim’s MAC and IP addresses to obtain unauthorized access Jose' Brustoloni

7. Contribution: Transparently detecting and blocking session hijackings Session id checking: • Captive portal sends to client a session management page with cookie containing a cryptographically random session id • Session management page is SSL-secured and tagged with http-equiv = “refresh” directive • Client’s browser periodically sends to captive portal request to refresh the session management page • Each request accompanied by cookie with session id • Captive portal deauthorizes MAC and IP addresses of client whose refresh request and session id cookie were not received in the previous period Jose' Brustoloni

8. Evaluation of session id checking: throughput Jose' Brustoloni

9. Evaluation of session id checking:CPU utilization For 1 s refresh Jose' Brustoloni

10. Victim continues to communicate (no denial of service) If victim does not have personal firewall, victim may respond to packets destined to freeloader (e.g., TCP RST), disrupting freeloader’s communication However, if victim has personal firewall, victim does not respond to such packets Both victim and freeloader get access: potential for collusion Theft of service by freeloading Jose' Brustoloni

11. Contribution:Transparently detecting freeloading • Each 802.11 packet contains a 12-bit sequence number • Increments by one for each new packet sent; remains the same in case of MAC-layer fragmentation or retransmission • Implemented in adaptor’s firmware; cannot be changed by host • In case of freeloading, sequence numbers of packets using the same MAC and IP addresses form two (or more) trend lines Jose' Brustoloni

12. Blocking freeloading Jose' Brustoloni MAC sequence number tracking: Access point tracks MAC sequence numbers of packets from each associated client In case MAC sequence number returns from a trend line to the previous trend line, access point notifies captive portal for deauthorizing client’s MAC and IP addresses

13. Evaluation of MAC sequence number tracking • Passive technique: • no network overhead • little CPU or memory requirements • In summary, the theft of service problem can be solved in a manner that users find transparent / intuitive Jose' Brustoloni

14. Client-side security • Users expected to use SSL, SSH, or IPsec to protect their communication • Well-studied, trusted protocols • In principle, should provide all security users would need • But do users actually use these protocols securely? • Surprisingly, expectation not actually substantiated by research Jose' Brustoloni

15. Access Point Stronger or Closer Access Point (Tool: Airsnarf) SSID: “goodguy” SSID: “badguy” Wi-Fi Card SSID: “ANY” “goodguy” “badguy” Evil twin attack Jose' Brustoloni

16. Certificate verification (in theory) • Browser has public keys of major certifying authorities (CAs, e.g., Verisign) • Secure site supposed to get certificate from one of these CAs, with: • CA’s signature • certificate expiration • site’s name • site’s public key • Browser supposed to: • check CA’s signature, expiration, site’s name, CA’s revocation list • get site’s public key and use it to authenticate site Jose' Brustoloni

17. Certificate verification (in practice) • Public-key infrastructure (PKI) not universally deployed • Certificate verification errors are common • Browsers warn users of errors, but allow users to continue despite errors → Vulnerability to MITM attacks despite HTTPS Jose' Brustoloni

18. Certificate verification (in practice) • Public-key infrastructure (PKI) not universally deployed • Certificate verification errors are common • Browsers warn users of errors, but allow users to continue despite errors → Vulnerability to MITM attacks despite HTTPS Jose' Brustoloni

19. Why certificate verification fails • Browser does not have public key of certificate’s issuer • very common for internal sites → often not attack • uncommon for public sites → high risk of attack • Certificate expired • may result from simple inattention • unlikely to be attack • Certificate’s subject not desired site • if subject in same domain as desired site → unlikely to be attack • otherwise → high risk of attack Current browsers allow user to proceed despite error in all of these cases Jose' Brustoloni

20. Contribution: Context-Sensitive Certificate Verification (CSCV) CSCV-aware private CA: • Distributes its public key to organization members, on removable media (e.g., floppy disk or USB key) • Includes administrator’s contact information in issued certificates If certificate verification fails because issuer’s public key unknown, CSCV-aware browser: • Asks user for key on removable media • If user does not have it, uses information in certificate to guide user on how to contact CA’s administrator to overcome error • Does not allow user to continue without correcting error Jose' Brustoloni

21. Unencrypted passwords Existing browsers warn against unencrypted transmission, but: • Do not discriminate between passwords and other data • Warnings occur quite frequently • Often ignored or disabled by users Jose' Brustoloni

22. Contribution:Specific Password Warnings (SPW) • Browser detects user about to send password unencrypted • Asks if password protects important account • If so, strongly discourages user from continuing: • Tells user signs of secure site (https:, closed padlock) • Asks user to consider possibility of MITM replica of usually secure site • Asks user to consider consequences of financial or privacy loss Jose' Brustoloni

23. Just-in-Time Instruction (JITI) • Warn-and-Continue (WC) – e.g., Internet Explorer (IE): • Uses concepts that users do not understand • Does not fully disclose possible consequences • Does not tell users how to overcome error • Can be ignored by users Jose' Brustoloni

24. Improving JITI • Guidance Without Override (GWO) – e.g., CSCV: • Addresses all four shortcomings in WC • Not always possible • Guidance With Override (G+O) – e.g., SPW: • Unlike GWO, can be ignored by user • More generally applicable, but less secure Jose' Brustoloni

25. Well-in-Advance Instruction (WIAI) • Whitten’s alternative to JITI • Safe staging: each stage enables only data and functions that user knows how to manipulate safely • Our instantiation: Staged PKI Client (SPKIC) • Use browser with restricted functions and learn to reject unverified certificates, not to send unencrypted passwords, and how to get CA’s public key • Learn about MITM attacks, set up CA, issue bona fide and bogus certificates • Use IE without restrictions Jose' Brustoloni

26. User studies Male CS undergrads • Untrained, using unmodified IE • Untrained, using modified Mozilla with CSCV, SPW • After staged security training, using unmodified IE Scenario • Check balance at “rewards” site in students’ university – with HTTPS, certificate from unknown CA, correct local contact info • Spend rewards to buy one or more items at e-merchant site – with HTTPS, certificate from unknown CA, bogus contact info • Get order confirmation message at Web-based email site – with HTTP only / no certificate Jose' Brustoloni

27. Experimental results • Alarming insecurity for untrained users with existing • browsers • Users actually behaved less securely with HTTPS • CSCV, SPW, and SPKIC all had highly significant benefits • CSCV’s effect significantly higher than SPKIC’s Jose' Brustoloni

28. Caveats • Task completion bias • Difficulty effect • Age, gender, education level, ability not controlled Jose' Brustoloni

29. Related work • Usable security (Adams & Sasse, Anderson, Zurko & Simon, Sandhu, Xia & Brustoloni) • Whitten & Tygar – PGP • Out-of-band certificate fingerprint verification • Identity-based cryptography • Ackerman & Cranor – critics • Ye & Smith – browser trusted paths • Yan & al. – education on password selection Jose' Brustoloni

30. Conclusions • Session id checking and MAC sequence number tracking secure network side transparently • Client side more difficult to secure because most users do not understand certificates, ignore warnings • Delegating security decisions to users defeats security • CSCV: User interface discriminates context in which certificate verification fails & guides user in correction • Greater benefit than user education • SPW: User interface warns possible consequences of sending passwords unencrypted • Benefit similar to that of user education Jose' Brustoloni

31. Significance analysis Jose' Brustoloni

32. Dialog for certificate on removable media Jose' Brustoloni

33. Dialog for determining relationship between client and server Jose' Brustoloni

34. Dialog guiding inside member for getting certificate Jose' Brustoloni

35. Dialog cautioning public client about certificate error Jose' Brustoloni

36. Dialog for unencrypted password – important account Jose' Brustoloni