Slide1 l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 79

Wireless Security Overview Paul Cychosz March 2005 PowerPoint PPT Presentation


  • 236 Views
  • Uploaded on
  • Presentation posted in: General

Wireless Security Overview Paul Cychosz March 2005. Wireless Security. Topics: WEP - attacks WPA / TKIP. RSN (802.11i) - RADIUS - EAP - AES-CCMP Small Case study. WEP. Goals: Integrity: No tampering with messages Confidentiality: No eavesdropping

Download Presentation

Wireless Security Overview Paul Cychosz March 2005

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Slide1 l.jpg

Wireless Security Overview

Paul Cychosz

March 2005


Wireless security l.jpg

Wireless Security

  • Topics:

  • WEP

  • - attacks

  • WPA / TKIP

  • RSN (802.11i)

  • - RADIUS

  • - EAP

  • - AES-CCMP

  • Small Case study


Slide3 l.jpg

WEP

  • Goals:

  • Integrity: No tampering with messages

  • Confidentiality: No eavesdropping

  • Access Control: No unauthorized access


Slide4 l.jpg

WEP

Encryption

  • RC4 Stream Cipher

  • CRC-32 Integrity checking

  • 40 or 104-bit key

Decryption


Wep insecurities l.jpg

WEP Insecurities

-- Initial Vector (IV) problem

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

  • C1 = P1  E(IV, k)

  • C2 = P2  E(IV, k)

  • then XOR ciphertext together,

    C1  C2 = (P1 E(IV, k))  (P2 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

XOR cancels keystream


Wep insecurities6 l.jpg

WEP Insecurities

-- Initial Vector (IV) problem

Why is IV reused?

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

  • 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 insecurities7 l.jpg

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 insecurities8 l.jpg

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’.

WhereM’ = M  X, X is specially selected.

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


Wep insecurities9 l.jpg

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 insecurities10 l.jpg

WEP Insecurities

  • Even 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 insecurities11 l.jpg

WEP Insecurities

Don’t even have to understand how WEP works!

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


Slide12 l.jpg

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!


Slide13 l.jpg

WEP

2001: 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


Slide14 l.jpg

WEP

FMS stats

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


Slide15 l.jpg

WEP

Since 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


Slide16 l.jpg

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)


Slide17 l.jpg

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)


Slide18 l.jpg

WPA

  • 2 modes: WPA-Personal, WPA-Enterprise

  • PSK

  • pass phrase

  • other improvements:

  • -key generated from pw + salt + PRNG

802.1x Authentication


Slide19 l.jpg

TKIP

  • Temporal Key Integrity Protocol

  • Cryptographic message integrity code (MIC) forgery

  • New IV sequencing (TSC) replay

  • Per-Packet mixing function weak IV

  • Re-keying key reuse


Slide20 l.jpg

TKIP

Encryption Graph


Slide21 l.jpg

TKIP

Decryption Graph


Slide22 l.jpg

TKIP

  • Key Mixing: Use temporal key instead of base key

  • Key regenerated frequently

  • Per packet temporal key

S-box

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

Feistel structure

intermediate key


Slide23 l.jpg

TKIP

Michael – replacement MIC for CRC-32

  • Made to be fast

  • A bit problematic

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


Slide24 l.jpg

TKIP

  • Just a wrapper around WEP, overhead

  • Long term security questionable

TKIP

WEP


Slide25 l.jpg

TKIP

  • Main goal achieved: Backward compatibility

  • Fixed major vuln. without changing hardware

  • Underappreciated


802 11i wpa 2 l.jpg

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 l.jpg

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 l.jpg

802.11i Parts

Robust Secure Network (RSN)

802.1x / EAPoL

CCMP / TKIP / WRAP

Encryption / Integrity

EAP

RADIUS

EAP-TLS

Outside of 802.11i, but de facto standard

Authentication / Key Dist.


802 11i auth goals l.jpg

802.11i - Auth. Goals

1. Mutual authentication

2. Identity privacy

3. Dictionary attack resistance

4. Replay attack resistance

5. Derivation of strong session keys

6. Tested implementation

7. Delegation: Allow guests through clients

8. Fast reconnect: Mobile IP, different auth. procedure, see 802.11r, modified handshaking


802 1x eapol l.jpg

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 l.jpg

802.1x

  • - Link Security

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

  • DHCP Blocked


802 11i first half l.jpg

802.11i – First half

STA AP AS

Capability Discovery

802.1x Authentication

802.1x Key Management

Keygen & Distribution

Encryption + Additional handshaking


802 11i init l.jpg

802.11i – Init

First: 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.


Slide34 l.jpg

EAP

  • Extensible Authentication Protocol - The transport protocol to authenticate users

  • "EAP is used to select a specific authentication mechanism, typically after

  • the authenticator requests more information in order to determine the

  • specific authentication method to be used." –RFC 3748, page 3

(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:

  • EAP-Request

  • EAP-Response

  • EAP-Success

  • EAP-Failure


Slide35 l.jpg

EAP

General EAP Message Flow


Slide36 l.jpg

EAP

  • Layered Stack Model – 4 Levels

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

  • EAP layer: Duplicate detection, retransmission

  • EAP Peer/Auth: Sets up packet based on Code field

  • EAP Method: Implement authentication algorithms, fragmentation


Slide37 l.jpg

EAP

Layered Model

EAP Method EAP Method

Type X Type Y

EAP Method EAP Method

Type X Type Y

EAP Peer Layer

EAP Layer

Lower Layer

EAP Auth Layer

EAP Layer

Lower Layer

EAPoL


Eapol l.jpg

EAPoL

EAP is a general protocol

  • EAPoL-Start

  • EAPoL-Key

  • EAPoL-Packet

  • EAPoL-Logoff

  • EAPoL-Encapsulated-ASF-Alert

MAC addr Header

Protocol Version

Packet Type

Packet Body Length

Packet Body

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


Eapol39 l.jpg

EAPoL

  • EAPoL-Start

  • EAPoL-Key

  • EAPoL-Packet

  • EAPoL-Logoff

  • EAPoL-Encapsulated-ASF-Alert

MAC addr Header

Protocol Version

Packet Type

Packet Body Length

Packet Body

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


Eapol40 l.jpg

EAPoL

  • EAPoL-Start

  • EAPoL-Key

  • EAPoL-Packet

  • EAPoL-Logoff

  • EAPoL-Encapsulated-ASF-Alert

MAC addr Header

Protocol Version

Packet Type

Packet Body Length

Packet Body

  • Just a container

  • Supplicant wishes to disconnect

  • Not used typically


Slide41 l.jpg

EAP

Packet header:

Code Identifier Length

Data . . .

Code: Message type

Identifier: To pair up messages

Length: Header + Data size

- Integrity depends on lower layers


Slide42 l.jpg

EAP

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

Code Identifier Length

Type Type Data . . .

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


Slide43 l.jpg

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…


Slide44 l.jpg

EAP

EAP 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 l.jpg

Full 802.1x: EAP / RADIUS


Radius l.jpg

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.


Radius47 l.jpg

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.


Radius48 l.jpg

RADIUS

Message format

Code

Identifier

Length

Authenticator

Attributes

  • 1-byte: Type

  • 1-byte: Length

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

128-bits.

Nonce

ICV(Nonce)

Access-Request(..type..)

Access-Accept OR Access-Reject OR Access-Challenge


802 1x eap tls radius 1 l.jpg

802.1x: EAP-TLS / RADIUS (1)

AP-RADIUS key


802 1x eap tls radius 2 l.jpg

802.1x: EAP-TLS / RADIUS (2)


Radius51 l.jpg

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 l.jpg

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 11i53 l.jpg

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 11i54 l.jpg

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 l.jpg

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

PMK

KCK

ANonce

Keygen

Algorithm

SNonce

KEK

STA MAC

TK*

AP MAC

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


802 11i key heirarchy l.jpg

802.11i – Key Heirarchy

Cipher-suite dependent


802 11i57 l.jpg

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 11i58 l.jpg

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 11i59 l.jpg

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 l.jpg

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 l.jpg

GTK - Keygen

  • Hardware approach

  • Many Ph.d thesis on LFSRs

  • Goal: unpredictable, nonlinear


802 11i gtk l.jpg

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 l.jpg

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 l.jpg

802.11i – AES-CCMP

...

...

E

E

E

padding

padding

B1

...

Bk

Bk+1

...

Br

B0

0

0

Tag

Header

Message

Not encrypted

C

D

S1

...

Sm

S0

A0

A1

E

Am

E

E


802 11i aes ccmp65 l.jpg

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 ccmp66 l.jpg

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 ccmp67 l.jpg

802.11i – AES-CCMP

Full CCMP Encryption

PN

Start val

1st block

CBC-MAC

MAC addr

Counter

Len

Plaintext

MPDU

TK

Compute

MIC

Concat

to MPDU

Encrypt

MPDU:

AES-CTR

mode

Ciphertext MPDU


Checkpoint compare l.jpg

Checkpoint: Compare


802 11i overview l.jpg

802.11i Overview

Finally 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 l.jpg

802.11i Attacks (DoS)

{AA, ANonce, n, msg1}

{AA, ANonce, n, msg1}

msg 2 {. . .}

msg 3 { . . . }

msg 4 { . . . }


802 11i attacks dos71 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

Wireless Security: Overview

PROTECTING THE NETWORK

Device Level Authentication

PROTECTING THE USER

Stateful Per User Firewalls

PROTECTING THE AIR

RF Spectrum Security

Wireless IDS

PROTECTING THE CONNECTION

IPSec, VPN

PROTECTING THE DATA

Link Layer Encryption


Too much l.jpg

Too much

  • Lots 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 l.jpg

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

MAC addr. || Nonce

h

0

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

h

1

.

.

.

h

n


Lightweight modification77 l.jpg

Lightweight Modification

  • Send in reverse order

Message x:

MAC addr. || Nonce || Data

802.11 Hdr

Data…

h

Message 0

0

64-bit hash

Data…

h

Message 1

1

.

.

.

.

.

- Message 0 contains nonce in data

.

h

Message n

n


Lightweight modification78 l.jpg

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.


Slide79 l.jpg

Questions? Comments? Corrections?

For these slides, whitepapers, and other references see my

afs space:

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


  • Login