Wireless Security Overview

Paul Cychosz

March 2005

Wireless Security

Topics:

WEP

- attacks

WPA / TKIP

RSN (802.11i)

- RADIUS

- EAP

- AES-CCMP

Small Case study

WEPGoals:

• Integrity: No tampering with messages

• Confidentiality: No eavesdropping

• Access Control: No unauthorized access

WEP

• RC4 Stream Cipher

• CRC-32 Integrity checking

• 40 or 104-bit key

Encryption

Decryption

WEP Insecurities

RC4 Encryption = E(...), C = ciphertext, P = plaintext, k = key

C1 = P1 E(IV, k)

C2 = P2 E(IV, k)

then XOR ciphertext together,

1 C 2 = ( 1 C P ( , )E IV k ) ( 2 P ( , )E IV k )

= P1 P2 so knowing one plaintext will get you the other

- but usually just having the XOR of two plaintexts is good enough

-- Initial Vector (IV) problem

XOR cancels keystream

WEP Insecurities

Why is IV reused?

1) IV only 24-bits in WEP, IV must repeat after 2^24 or ~ 16.7M packets

-practical?

-IV sent in clear with ciphertext, easy collision detection

-- Initial Vector (IV) problem

yes, since WEP key rarely changes

yes, usually less than 16 million packets (some keys filtered)

yes, implementations make it worse

• IV reset, multi-user shared key

WEP Insecurities

-- Checksum (ICV)

• CRC-32 is NOT a hash function!

• Still can be malicious

• Already a CRC in network stack to detect errors

Linear Properties: CRC-32(P C) = CRC-32(P) CRC-32(C)

- Bit flipping

WEP Insecurities

Combining Ideas

A B: (IV || C)

= RC4(IV,k) (M || CRC-32(M) )

-- hash collision similarities

Oscar calculates C’ such that it decrypts to M’.

Where M’ = M X, X is specially selected.

O B: (IV || C’) = RC4(IV,k) (M’ || CRC-32(M) )

WEP Insecurities

Combining Ideas

Leads to message injection (math omitted)

WEP authentication: Challenge supplicant that they really know k.

M

(IV || M || CRC-32(M)) E(IV,k))

-- Worthless, unless Oscar only one using network

WEP InsecuritiesEven more!

• IP Redirection

• Double-Encryption

• Decryption Dictionaries (~ 24GB via FMS / DHCP / Parallel attacking, more about this in a minute…)

-- Some vendors make it worse. (nonsequential IV, constant IV, etc.)

See: Mobicom ’01: Borisov, Goldberg, Wagner.

Intercepting Mobile Communications: The Insecurity of 802.11.

WEP InsecuritiesDon’t even have to understand how WEP works!

Airsnort, WEPcrack, kismet, dwepcrack, aircrack, many others

WEP2• 128-bit IV

• Never fully supported

• Still not secure, still uses CRC-32

• key/IV size doesn’t even matter!

• WEP2 barely exists, no one uses. . .

. . .

. . .

Moving on!

WEP2001: Fluhrer, Mantin, Shamir

Weaknesses in the Key Scheduling Algorithm of RC4.

• completely passive attack

• Inductive chosen plaintext attack

• Takes 5-10M. packets to find secret key

• linear complexity attack (2048-bit? No problem!)

• Showed that WEP is near useless

WEP FMS stats

http://www.securityfocus.com/infocus/1814

WEPSince FMS: Optimized attacks via statistical analysis, defeats dynamic re-keying of WEP (previous proposed solution)

• Attack only takes several thousand packets

• Looks at packets w/ unique IV, exploits DHCP and ICMP echo (ping)

• Optimizations on this: WEP key cracked in minutes

http://www.securityfocus.com/infocus/1824

WPA• April 2003

• Snapshot of “in progress” 802.11i standard

• Only temporary solution

• Fixes many WEP problems

• Based on TKIP

• Same Encryption as WEP (RC4)

WPA• Designed to work with a 802.1x authentication server

• 104-bit key 128-bit

• 24-bit IV 48-bit IV

• MIC: CRC-32 “Michael”

• Frame counter (TSC)

WPA• 2 modes: WPA-Personal, WPA-Enterprise

802.1x Authentication• PSK

• pass phrase

• other improvements:

-key generated from pw + salt + PRNG

TKIPTemporal Key Integrity Protocol

• Cryptographic message integrity code (MIC) forgery

• New IV sequencing (TSC) replay

• Per-Packet mixing function weak IV

• Re-keying key reuse

TKIP

Encryption Graph

TKIP

Decryption Graph

TKIP• Key Mixing: Use temporal key instead of base key

• Key regenerated frequently

• Per packet temporal key

intermediate key

S-box

Feistel structure

“d” = dummy byte created in a way to prevent weak keys

TKIPMichael – replacement MIC for CRC-32

• Made to be fast

• A bit problematic

• Requires addtl. countermeasures: Rekeying, Rate limit rekeying, etc.

TKIP• Just a wrapper around WEP, overhead

• Long term security questionable

WEP

TKIP

TKIP Main goal achieved: Backward compatibility

Fixed major vuln. without changing hardware

Underappreciated

802.11i (WPA 2)

• Current flagship heavyweight solution

• Robust Secure Network (RSN)

• Ratified June 2004

• Based on newer AES encryption

• Can use authentication server or PSK

• Backward compatibility modes, need new hardware for AES

802.11i

Terms:

• 802.1x: Authentication standard• RADIUS: Authentication Server• EAP: Extensible Authentication Protocol• CCMP: Encryption based on AES counter mode with

CBC-MAC

802.11i Parts

Robust Secure Network (RSN)

802.1x / EAPoL

RADIUS EAP

EAP-TLS

CCMP / TKIP / WRAP

Outside of 802.11i, but de facto standard

Authentication / Key Dist.

Encryption / Integrity

802.11i - Auth. Goals1. Mutual authentication2. Identity privacy3. Dictionary attack resistance4. Replay attack resistance5. Derivation of strong session keys6. Tested implementation7. Delegation: Allow guests through clients8. Fast reconnect: Mobile IP, different auth. procedure,

see 802.11r, modified handshaking

802.1x / EAPoL• 802.11i process starts with EAP

• Port-based security

• Does not use IP

Terms:

AS: Authentication server

STA: Station / Supplicant / Client

AP: Access Point

802.1x- Link Security

-Can only communicate with AS, e.g. RADIUS, until “EAP-Success” message received

-DHCP Blocked

802.11i – First half

STA AP AS

Capability Discovery

802.1x Authentication

802.1x Key Management Keygen & Distribution

Encryption + Additional handshaking

802.11i – InitFirst: Capability discovery, any point on proceeding?

AP client: RSN Information Element (RSN IE)

“1” means:

802.1x and CCMP support

Pre-Auth, GK for unicast, etc.

WEP-40/104, TKIP, CCMP, WRAP, Vendor specific

802.1x auth, key mgmt, vendor spec.

EAP

(Step 0) Link Control Phase w/ AP to initiate “EAP-Start” (EAPoL-Start)

- AP usually just a “pass-through” until end of EAP

4 message types:

(1) EAP-Request

(2) EAP-Response

(3) EAP-Success

(4) EAP-Failure

• Extensible Authentication Protocol - The transport protocol to authenticate users• "EAP is used to select a specific authentication mechanism, typically afterthe authenticator requests more information in order to determine thespecific authentication method to be used." –RFC 3748, page 3

EAP

General EAP Message Flow

EAP Layered Stack Model – 4 Levels

(1) Lower layer: Responsible for transmitting and receiving EAP frames between the station and authenticator. Variations of lower layer include UDP, TCP, etc.

(2) EAP layer: Duplicate detection, retransmission

(3) EAP Peer/Auth: Sets up packet based on Code field

(4) EAP Method: Implement authentication algorithms, fragmentation

EAPLayered Model

EAP Method EAP Method

Type X Type Y

EAP Peer Layer

EAP Layer

Lower Layer

EAP Method EAP Method

Type X Type Y

EAP Auth Layer

EAP Layer

Lower Layer

EAPoL

EAPoLEAP is a general protocol

•EAPoL-Start

•EAPoL-Key

•EAPoL-Packet

•EAPoL-Logoff

•EAPoL-Encapsulated-ASF-Alert

1) Sent to special group multicast address reserved for 802.1X authenticators (this sometimes preempted, h/w)

MAC addr Header

Protocol Version

Packet Type

Packet Body Length Packet Body

EAPoL

•EAPoL-Start

•EAPoL-Key

•EAPoL-Packet

•EAPoL-Logoff

•EAPoL-Encapsulated-ASF-Alert

2) Key exchange. Vague in 802.1x. 802.11i modifies this message

MAC addr Header

Protocol Version

Packet Type

Packet Body Length Packet Body

EAPoL

•EAPoL-Start

•EAPoL-Key

•EAPoL-Packet

•EAPoL-Logoff

•EAPoL-Encapsulated-ASF-Alert

3) Just a container

4) Supplicant wishes to disconnect

5) Not used typically

MAC addr Header

Protocol Version

Packet Type

Packet Body Length Packet Body

EAP

Code Identifier Length

Data . . .

Packet header:

Code: Message type

Identifier: To pair up messages

Length: Header + Data size

- Integrity depends on lower layers

EAP

Code Identifier Length

Type Type Data . . .

Packet header, 1(Request) or 2(Response):

Types:

1 Identity

2 Notification

3 Nak (Response only)

4 MD5-Challenge

5 One Time Password (OTP)

6 Generic Token Card (GTC)

254 Expanded Types

255 Experimental use

EAP• If all goes well, EAP-Success sent

• Authentication server gives AP the key to continue with 2nd half of 802.11i communication

• EAP info can be sent insecurely if bad EAP mode chosen.

Many flavors of EAP

LEAP, PEAP, EAP-TLS (This is de facto standard), EAP-TTLS,

Others…

EAPEAP Types:

PEAP (Protected EAP): Uses a digital certificate on AP side, password / certificate on station side. Mutual Authentication. Native support, 3rd-party packages.

EAP-TLS (EAP with Transport Level Security): RFC 2716. Certificates on both client & AP side. Mutual Authentication. Well supported.

EAP-TTLS (Tunneled Transport Layer Security): Certificate on AP side, password / token / certificate on client side. Mutual Auth. Encrypts exchange, including the username. Good support.

LEAP: Cisco solution, vuln. to dictionary attack. “Asleap” cracking tool. Dropping support for PEAP.

Combine EAP-TTLS and PEAP, no certificates needed.

Full 802.1x: EAP / RADIUS

RADIUS

. . .

AP Not Encrypted* RADIUS

• RADIUS - Remote Authentication Dial In User Service, RFC 3597

• If Oscar is on inside, can easily ARP-Poison and interject forged messages to RADIUS server and get valid responses.

• Widely deployed protocol for network access authentication, authorization and accounting (AAA)

• Not part of 802.11i!

* standard doesn’t req. encryption, but can if needed and often is, IPsec, etc.

RADIUS Stores database of login info typically in relational DB or Unix /etc/passwd file

• Access-Request. Network access connection attempt from a client

• Access-Accept. Sent from RADIUS server when client is authenticated and authorized.

• Access-Reject. Sent by a RADIUS if either the credentials are not authentic or the connection attempt is not authorized.

• Access-Challenge. Sent by a RADIUS server in response to an Access-Request message. Client must respond to this

• Accounting-Request. Sent by a RADIUS client to specify accounting information for a connection that was accepted.

• Accounting-Response. This message acknowledges the successful receipt and processing of the Accounting-Request message.

RADIUS

Code Identifier Length Authenticator Attributes

Message format

128-bits.

Access-Request(..type..)

NonceICV(Nonce)

Access-Accept OR Access-Reject OR Access-Challenge

• 1-byte: Type

• 1-byte: Length

• Rest: data, i.e. EAP messages(79)

802.1x: EAP-TLS / RADIUS (1)

AP-RADIUS key

802.1x: EAP-TLS / RADIUS (2)

RADIUS• Mature, DIAMETER replacement? Unlikely anytime soon.

• Security can depend on EAP mode also.

• FreeRADIUS, Microsoft IAS, etc.

• AP-AS relationship relies on static key (), AP sends challenges to RADIUS, expects back: MD5(data || key || challenge)

• EAP-TLS/RADIUS: Rogue AP/certificate problem

•WPA2-Personal: No RADIUS server, PSK

• AP can act as authentication server

802.11i – Part 2• Next: 4-way handshake

• Triggered on ‘EAP-Success” message

-RADIUS copies PMK to AP via attribute (!)

-MS-MPPE-Recv-key

Basic Idea:

802.11i Handshake details

{AA, ANonce, n, msg1}

{SPA, SNonce, n, msg2, MICPTK(SNonce, n, msg2)}

{AA, ANonce, n + 1, msg3, MICPTK(ANonce, n + 1, msg3)}

{SPA, n + 1, msg4, MICPTK(n + 1, msg4)}

802.11i Message 1, not protected, doesn’t matter though

AP STA: {AA, ANonce, n, msg1}

AA: MAC Address of AP

ANonce: random value

n: sequence identifier

msg1: PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AA || SPA).

• Client uses ANonce and PMK to compute PTK

• PMK never sent over network during handshake

…else he has a chance to make your life miserable

802.11i – Key Mgmt. What is the PTK?

• Data Encryption key (128 bits)*• Data Integrity key (128 bits)*• EAPoL-Key Encryption (128 bits)• EAPoL-Key Integrity key (128 bits)

MAC addr & Nonce & PMK

PMKANonceSNonce

STA MACAP MAC

TK*

KEK

KCKKeygen

Algorithm

* Combined when using full RSN, i.e. AES

802.11i – Key Heirarchy

Cipher-suite dependent

802.11i Message 2

STA AP: {SPA, SNonce, n, msg2, MICPTK(SNonce, n, msg2)}

SPA: MAC Address of STA

SNonce: random value

n: sequence identifier, matches msg1

msg2: RSN IE of STA

Verifies no MITM attack

• AP uses SNonce and PMK to compute PTK

• AP can timeout and tear down authentication

802.11i Message 3

AP STA: {AA, ANonce, n + 1, msg3, MICPTK(ANonce, n + 1, msg3)}

AA: MAC Address of AP

ANonce: random value again

n: sequence identifier, to match msg4

msg3: Informs STA that TK ready to use, RSN IE of AP.

MIC: to verify the above. Silently discarded if MIC fails.

Verifies no MITM attack happening

802.11i Message 4

STA AP: {SPA, n + 1, msg4, MICPTK(n + 1, msg4)}

SPA: MAC Address of STA

n: sequence identifier, to match msg3

MIC: to verify the above. Silently discarded if MIC fails.

• This message dropped in some implementations.

• Only kept for convention

See: Altunbasak, Owen. Alternative Pair-wise Key Exchange Protocols for Robust Security Networks (IEEE 802.11i) in Wireless LANs. 2004

802.11i - Multicast

What is the GTK?

Group Transient Key: Created / used to maintain AP efficiency.

• GMK / GTK: Derived like PTK.

• AP uses PRNG for 256-bit value.

• For multicast traffic

• Distributed using KEK derived from PTK

GTK - Keygen

• Hardware approach

• Many Ph.d thesis on LFSRs

• Goal: unpredictable, nonlinear

802.11i - GTK

{Keys, ACK, GroupRx, Group, KeyID, GNonce, RSC, MIC(…), EKEK(GTK)}

{Group, EKEK(MIC(…))}

• RSC: Starting Replay Sequence Counter minimizes replay to STAs joining the group late

Note: GNonce means nothing here. Possibly used in future for change notification.

802.11i - Encryption

“ NIST estimates that a machine that can break 56-bit DES key in 1 second would take about 149 trillion years to crack a 128-bit AES key (unless someone is very lucky)”

New encryption based on modification of AES

AES-CCMP: CTR-mode/CBC-MAC (Required)

TKIP and WRAP also part of 802.11i.

WRAP

• Similar to CCMP, just AES-OCB (Offset Codebook) mode.

• A patent mess, politics killing WRAP

802.11i – AES-CCMP

Br

E

B0

E...

B1 Bk

Header Message Tag

A1 AmE E

A0 E

...

Not encrypted

0

padding

0

padding

Bk+1...

... E

Sm...S1 S0

DC

802.11i – AES-CCMP• Only can do 128-bit blocks.

• Block cipher, so must pad

• “IV” comparable to nonce plus counter – much harder to exploit

• Nonce to start things: 48-bits, called PN

802.11i – AES-CCMP Integrity

MIC: CBC-MAC / per packet algorithm

128-bit generation, but only take first 64-bits

XOR blocks, hence “block-chaining”

MIC computed on packet header

MIC then encrypted (using IV = 0, CTR mode) and appended to payload

802.11i – AES-CCMPFull CCMP Encryption

Compute MIC

Concat to MPDU

Counter

1st block CBC-MAC

Encrypt MPDU:

AES-CTR mode

PN

Plaintext MPDU

TK

MAC addr

Len

Ciphertext MPDU

Start val

Checkpoint: Compare

802.11i OverviewFinally secure? Hard to say.

802.11i made up of many parts, implementation / administrative errors. (i.e. PSK compromise)

Light years ahead of WEP

AES: no known provably successful attacks.

AES: Young block cipher

New H/W means slow transition

802.11i Attacks (DoS){AA, ANonce, n, msg1}

msg 2 {. . .}

msg 3 { . . . }

msg 4 { . . . }

{AA, ANonce, n, msg1}

802.11i Attacks (DoS)

• 2 ways: Flood (memory exhaust), periodically (de-authenticate)

• Attack somewhat feasible, but not a huge problem

• Some fixes already

• See whitepaper for details:

2004: He, Mitchell. Analysis of the 802.11i 4-Way Handshake.

802.11i Attacks (XSL)•eXtended Sparse Linearization

• Attack on AES itself

• Analyzes cipher, basically boils down to solving 8000 simultaneous quadratic equations with 1600 variables

• NP-hard with no decent approximations

• Doesn’t break AES, yet

• Don’t ask about details, don’t know much about this!

802.11 Attacks (General) Wireless spectrum inherently weak against DDoS/DoS attacks.

Any attacker with knowledge/equipment can bring down all 802.11 networks (hosts and APs).

This is how MITM attacks become feasible.

Can do nothing to stop this (unless you’re the military with a large budget for adv. radio equipment)

Physical layer

Fortunately, not common (but not infeasible)

Wireless Security: Overview

PROTECTING THE AIRRF Spectrum SecurityWireless IDS

PROTECTING THE NETWORKDevice Level Authentication

PROTECTING THE CONNECTIONIPSec, VPN

PROTECTING THE USERStateful Per User Firewalls

PROTECTING THE DATALink Layer Encryption

Too muchLots of parts:

- EAP (many different modes, PEAP, EAP-TLS, EAP-TTLS)

- RADIUS (Link based control, extra server*)

- Encryption (RC4, AES )

- Often encryption not that important to user, don’t care

Do care if someone poses as them to do something bad

- Public hotspots

Lightweight Modification-- My current case study

-- Utilize hash chaining to prevent injection attacks

Idea: Pre-compute a large hash table where each hash depends on previous

h

h

h

. .

.

0

1

n

h = a fast hashing algorithm, MD5, SHA-1? Possibly Michael (for speed)

MAC addr. || Nonce

Lightweight Modification

h

h

h

. .

.

0

1

n

Send in reverse order

MAC addr. || Nonce || Data

Message n

Message 1

Message 0

. . .

Message x:

802.11 Hdr Data…

64-bit hash Data…

- Message 0 contains nonce in data

Lightweight Modification How / when to compute hash table?

Alternative 1) Compute table for every MSDU, where each hash pairs with a MPDU

-Advantage: Can be done in device driver. Transparent to OS / Applications

Alternative 2) Watch send(), sendto() system calls. Compute table on buffer argument passed to sys. call.

-Advantage: Can be done in kernel, faster thus can use a better hashing algorithm.

Questions? Comments? Corrections?

For these slides, whitepapers, and other references see myafs space:

/afs/cs.wisc.edu/u/c/y/cychosz/public/wireless-sec/