Wireless Security Overview

1

• Wireless Security Overview
• Paul Cychosz
• March 2005

2
Wireless Security

• Topics
• WEP
• - attacks
• WPA / TKIP

• RSN (802.11i)
• - RADIUS
• - EAP
• - AES-CCMP
• Small Case study

3
WEP

• Goals
• Integrity No tampering with messages
• Confidentiality No eavesdropping
• Access Control No unauthorized access

4
WEP
Encryption

• RC4 Stream Cipher
• CRC-32 Integrity checking
• 40 or 104-bit key

Decryption
5
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

6
WEP Insecurities
-- Initial Vector (IV) problem

• Why is IV reused?
• IV only 24-bits in WEP, IV must repeat after 224
  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

7
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
8
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) )
9
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
10
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.

11
WEP Insecurities
Dont even have to understand how WEP works!
Airsnort, WEPcrack, kismet, dwepcrack, aircrack,
many others
12
WEP2

• 128-bit IV
• Never fully supported
• Still not secure, still uses CRC-32
• key/IV size doesnt even matter!
• WEP2 barely exists, no one uses. . .
• . . .
• . . .
• Moving on!

13
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

14
WEP
FMS stats http//www.securityfocus.com/infoc
us/1814
15
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

16
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)

17
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)

18
WPA

• 2 modes WPA-Personal, WPA-Enterprise

802.1x Authentication

• PSK
• pass phrase
• other improvements
• -key generated from pw salt PRNG

19
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

20
TKIP
Encryption Graph
21
TKIP
Decryption Graph
22
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
23
TKIP
Michael replacement MIC for CRC-32

• Made to be fast
• A bit problematic
• Requires addtl. countermeasures Rekeying,
  Rate limit rekeying, etc.

24
TKIP

• Just a wrapper around WEP, overhead
• Long term security questionable

TKIP
WEP
25
TKIP

• Main goal achieved Backward compatibility
• Fixed major vuln. without changing hardware
• Underappreciated

26
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

27
802.11i

• Terms
• 802.1x Authentication standard
• RADIUS Authentication Server
• EAP Extensible Authentication Protocol
• CCMP Encryption based on AES counter mode
  with CBC-MAC

28
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.
29
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
30
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
31
802.1x

• - Link Security
• Can only communicate with AS, e.g. RADIUS, until
  EAP-Success message received
• DHCP Blocked

32
802.11i First half
STA AP AS
Capability Discovery
802.1x Authentication
802.1x Key Management
Keygen Distribution
Encryption Additional
handshaking
33
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.
34
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

35
EAP
General EAP Message Flow
36
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

37
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
38
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)
39
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
40
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

1. Just a container
2. Supplicant wishes to disconnect
3. Not used typically

41
EAP
Packet header
Code Identifier Length
Data . . .
Code Message type Identifier To pair up
messages Length Header Data size - Integrity
depends on lower layers
42
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
43
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
44
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.
45
Full 802.1x EAP / RADIUS
46
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 doesnt req. encryption, but can if
  needed and often is, IPsec, etc.

47
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.
48
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
49
802.1x EAP-TLS / RADIUS (1)
AP-RADIUS key
50
802.1x EAP-TLS / RADIUS (2)
51
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

52
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
53
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)
54
802.11i

• Message 1, not protected, doesnt 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
55
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
56
802.11i Key Heirarchy
Cipher-suite dependent
57
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

58
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
59
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

60
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

61
GTK - Keygen

• Hardware approach
• Many Ph.d thesis on LFSRs
• Goal unpredictable, nonlinear

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

63
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

64
802.11i AES-CCMP
...
...
E
E
E
padding
padding
Br
B1
Bk
...
Bk1
...
B0
0
0
Tag
Header
Message
Not encrypted
D
C
Sm
...
S1
S0
A0
A1
Am
E
E
E
65
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

66
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

67
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
68
Checkpoint Compare
69
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

70
802.11i Attacks (DoS)
AA, ANonce, n, msg1
AA, ANonce, n, msg1
msg 2 . . .
msg 3 . . .
msg 4 . . .
71
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.

72
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
• Doesnt break AES, yet
• Dont ask about details, dont know much about
  this! ?

73
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 youre the
  military with a large budget for adv. radio
  equipment)
• Physical layer
• Fortunately, not common (but not infeasible)

74
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
75
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,
  dont care
• Do care if someone poses as them to do
  something bad
• - Public hotspots

76
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
77
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
78
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.

79
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/