Usable Security for Wi-Fi LANs Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh [email protected] Joint work with Haidong Xia

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


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


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)


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


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


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


Evaluation of session id checking: throughputEvaluation of session id checking: throughput


Evaluation of session id checking:Evaluation of session id checking:CPU utilizationCPU utilization

For 1 s refresh


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


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


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


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


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


Access Point

SSID: “goodguy”

SSID: “badguy”

Stronger or CloserAccess Point(Tool: Airsnarf)

“ANY”

Wi-Fi Card

SSID: “goodguy”“badguy”

Evil twin attackEvil twin attack


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


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


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


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


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


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


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


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


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


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


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


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


CaveatsCaveats

♦ Task completion bias♦ Difficulty effect♦ Age, gender, education level, ability not

controlled


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


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


Significance analysisSignificance analysis


Dialog for certificate on removable mediaDialog for certificate on removable media


Dialog for determining relationship between Dialog for determining relationship between client and serverclient and server


Dialog guiding inside member for Dialog guiding inside member for getting certificategetting certificate


Dialog cautioning public client about Dialog cautioning public client about certificate errorcertificate error


Dialog for unencrypted password – Dialog for unencrypted password – important accountimportant account

Documents

Usable Security for Wi-Fi LANs Dr. José Carlos Brustoloni Dept. Computer Science University of Pittsburgh [email protected] Joint work with Haidong Xia