usable security for wi-fi lans dr. josé carlos brustoloni dept. computer science university of...
TRANSCRIPT
Usable Security for Wi-Fi LANsUsable Security for Wi-Fi LANs
Dr. José Carlos BrustoloniDept. Computer ScienceUniversity of [email protected] work with Haidong Xia
Jose' Brustoloni 2May 16, 2006
MotivationMotivation
♦ 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 3May 16, 2006
How can security be made more usable?How can security be made more usable?
In general, there are three alternatives1. Make security transparent / “just work”2. Improve user interfaces for security functions 3. Better educate/train users
We exploit and compare all three alternatives in this work
Jose' Brustoloni 4May 16, 2006
What do Wi-Fi hotspots do?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 5May 16, 2006
User authentication in Wi-Fi hotspots:User authentication in Wi-Fi hotspots:Captive portalsCaptive portals
♦ 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
AP
AP
AP
Captiveportal
defaultclient
Internet
intranet
plainWi-Fi
Jose' Brustoloni 6May 16, 2006
Theft of service byTheft of service bysession hijackingsession 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 7May 16, 2006
Contribution: Transparently detecting and Contribution: Transparently detecting and blocking session hijackingsblocking 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 8May 16, 2006
Evaluation of session id checking: throughputEvaluation of session id checking: throughput
Jose' Brustoloni 9May 16, 2006
Evaluation of session id checking:Evaluation of session id checking:CPU utilizationCPU utilization
For 1 s refresh
Jose' Brustoloni 10May 16, 2006
Theft of service by freeloadingTheft of service by freeloading
♦ 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
Jose' Brustoloni 11May 16, 2006
Contribution:Contribution:Transparently detecting freeloadingTransparently 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 12May 16, 2006
Blocking freeloadingBlocking freeloading
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
Jose' Brustoloni 13May 16, 2006
Evaluation of MAC sequence number trackingEvaluation 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 14May 16, 2006
Client-side securityClient-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 15May 16, 2006
Access Point
SSID: “goodguy”
SSID: “badguy”
Stronger or CloserAccess Point(Tool: Airsnarf)
“ANY”
Wi-Fi Card
SSID: “goodguy”“badguy”
Evil twin attackEvil twin attack
Jose' Brustoloni 16May 16, 2006
Certificate verification (in theory)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 17May 16, 2006
Certificate verification (in practice)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 18May 16, 2006
Certificate verification (in practice)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 19May 16, 2006
Why certificate verification failsWhy certificate verification fails
1. 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
2. Certificate expired may result from simple inattention unlikely to be attack
3. 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 20May 16, 2006
Contribution: Context-Sensitive Contribution: Context-Sensitive Certificate Verification (CSCV)Certificate Verification (CSCV)
CSCV-aware private CA:1. Distributes its public key to organization members, on
removable media (e.g., floppy disk or USB key)2. Includes administrator’s contact information in issued
certificates
If certificate verification fails because issuer’s public key unknown, CSCV-aware browser:
1. Asks user for key on removable media2. If user does not have it, uses information in certificate to
guide user on how to contact CA’s administrator to overcome error
3. Does not allow user to continue without correcting error
Jose' Brustoloni 21May 16, 2006
Unencrypted passwordsUnencrypted 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 22May 16, 2006
Contribution:Contribution:Specific Password Warnings (SPW)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 23May 16, 2006
Just-in-Time Instruction (JITI)Just-in-Time Instruction (JITI)
♦ Warn-and-Continue (WC) – e.g., Internet Explorer (IE):
1. Uses concepts that users do not understand2. Does not fully disclose possible consequences3. Does not tell users how to overcome error4. Can be ignored by users
Jose' Brustoloni 24May 16, 2006
Improving JITIImproving 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 25May 16, 2006
Well-in-Advance Instruction (WIAI)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)1. Use browser with restricted functions and learn to
reject unverified certificates, not to send unencrypted passwords, and how to get CA’s public key
2. Learn about MITM attacks, set up CA, issue bona fide and bogus certificates
3. Use IE without restrictions
Jose' Brustoloni 26May 16, 2006
User studiesUser studies
Male CS undergrads
1. Untrained, using unmodified IE
2. Untrained, using modified Mozilla with CSCV, SPW
3. After staged security training, using unmodified IE
Scenario
1. Check balance at “rewards” site in students’ university –
with HTTPS, certificate from unknown CA, correct local contact info
2. Spend rewards to buy one or more items at e-merchant site –
with HTTPS, certificate from unknown CA, bogus contact info
3. Get order confirmation message at Web-based email site –
with HTTP only / no certificate
Jose' Brustoloni 27May 16, 2006
Experimental resultsExperimental 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 28May 16, 2006
CaveatsCaveats
♦ Task completion bias♦ Difficulty effect♦ Age, gender, education level, ability not
controlled
Jose' Brustoloni 29May 16, 2006
Related workRelated 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 30May 16, 2006
ConclusionsConclusions♦ 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 31May 16, 2006
Significance analysisSignificance analysis
Jose' Brustoloni 32May 16, 2006
Dialog for certificate on removable mediaDialog for certificate on removable media
Jose' Brustoloni 33May 16, 2006
Dialog for determining relationship between Dialog for determining relationship between client and serverclient and server
Jose' Brustoloni 34May 16, 2006
Dialog guiding inside member for Dialog guiding inside member for getting certificategetting certificate
Jose' Brustoloni 35May 16, 2006
Dialog cautioning public client about Dialog cautioning public client about certificate errorcertificate error
Jose' Brustoloni 36May 16, 2006
Dialog for unencrypted password – Dialog for unencrypted password – important accountimportant account