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
• Access Control: No unauthorized access
WEP
Encryption
• RC4 Stream Cipher
• CRC-32 Integrity checking
• 40 or 104-bit key
Decryption
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
XOR cancels
keystream
so knowing one plaintext will get you the other
- but usually just having the XOR of two plaintexts is good enough
WEP Insecurities
-- Initial Vector (IV) problem
Why is IV reused?
1) IV only 24-bits in WEP, IV must repeat after 2^24 or ~ 16.7M packets
-practical?
 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
-IV sent in clear with ciphertext, easy collision detection
WEP Insecurities
-- Checksum (ICV)
• CRC-32 is NOT a hash function!
Linear Properties: CRC-32(P  C) = CRC-32(P)  CRC-32(C)
• Still can be malicious
- Bit flipping
• Already a CRC in network stack to detect errors
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 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 Insecurities
Don’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!
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
WEP
FMS stats
http://www.securityfoc
us.com/infocus/1814
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
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
• PSK
802.1x Authentication
• pass phrase
• other improvements:
-key generated from pw + salt + PRNG
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
TKIP
Encryption Graph
TKIP
Decryption Graph
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
intermediate key
Feistel structure
TKIP
Michael – 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
TKIP
WEP
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
Outside of 802.11i, but
de facto standard
EAP
EAP-TLS
Authentication / Key Dist.
CCMP / TKIP / WRAP
Encryption / Integrity
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
• 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 “EAPSuccess” 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 – 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.
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:
(1) EAP-Request
(2) EAP-Response
(3) EAP-Success
(4) EAP-Failure
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
EAP
Layered Model
EAP Method
EAP Method
Type X
Type Y
EAP Method
EAP Method
Type X
Type Y
EAP Peer Layer
EAP Auth Layer
EAP Layer
EAP Layer
Lower Layer
Lower Layer
EAPoL
EAPoL
EAP is a general protocol
•EAPoL-Start
•EAPoL-Key
MAC addr
Header
Protocol
Version
Packet Packet Body
Type
Length
Packet Body
•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)
EAPoL
•EAPoL-Start
•EAPoL-Key
MAC addr
Header
Protocol
Version
Packet Packet Body
Type
Length
Packet Body
•EAPoL-Packet
•EAPoL-Logoff
•EAPoL-Encapsulated-ASF-Alert
2) Key exchange. Vague in 802.1x. 802.11i modifies
this message
EAPoL
•EAPoL-Start
•EAPoL-Key
MAC addr
Header
Protocol
Version
Packet Packet Body
Type
Length
•EAPoL-Packet
•EAPoL-Logoff
•EAPoL-Encapsulated-ASF-Alert
3) Just a container
4) Supplicant wishes to disconnect
5) Not used typically
Packet Body
EAP
Packet header:
Code
Identifier
Data . . .
Code: Message type
Identifier: To pair up messages
Length: Header + Data size
- Integrity depends on lower layers
Length
EAP
Packet header, 1(Request) or 2(Response):
Code
Type
Identifier
Length
Type Data . . .
Types:
1 Identity
5 One Time Password (OTP)
2 Notification
6 Generic Token Card (GTC)
3 Nak (Response only)
254 Expanded Types
4 MD5-Challenge
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…
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
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
Message format
Code Identifier Length Authenticator
Attributes
• 1-byte: Type
128-bits.
• 1-byte: Length
• Rest: data, i.e. EAP
messages(79)
Access-Request(..type..)
Access-Accept OR
Access-Reject OR
Access-Challenge
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?
MAC addr &
Nonce & PMK
PMK
ANonce
SNonce
•
•
•
•
Data Encryption key (128 bits)*
Data Integrity key (128 bits)*
EAPoL-Key Encryption (128 bits)
EAPoL-Key Integrity key (128 bits)
KCK
Keygen
Algorithm
STA MAC
AP MAC
* Combined when using full RSN, i.e. AES
KEK
TK*
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
...
E
...
E
E
padding
B0
B1
...
Bk 0
padding
Bk+1
Header
...
Br
0
Tag
Message
Not encrypted
C
S1
A1
E
...
Am
D
Sm
E
S0
A0
E
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-CCMP
Full CCMP Encryption
PN
Start val
MAC
addr
1st block
CBC-MAC
Counter
Compute
MIC
Concat
to MPDU
Encrypt
MPDU:
AES-CTR
mode
Len
Plaintext
MPDU
TK
Ciphertext
MPDU
Checkpoint: Compare
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)
{AA, ANonce, n, msg1}
{AA, ANonce, n, msg1}
msg 2 {. . .}
msg 3 { . . . }
msg 4 { . . . }
802.11i Attacks (DoS)
• 2 ways: Flood (memory exhaust), periodically (deauthenticate)
• 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 USER
Stateful Per User Firewalls
PROTECTING THE CONNECTION
IPSec, VPN
PROTECTING THE NETWORK
Device Level Authentication
PROTECTING THE AIR
RF Spectrum Security
Wireless IDS
PROTECTING THE DATA
Link Layer Encryption
Too much
Lots of parts:
- EAP (many different modes, PEAP, EAP-TLS, EAPTTLS)
- 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
MAC addr. || Nonce
h
h
.
.
.
h
0
h = a fast hashing algorithm, MD5,
1
n
SHA-1? Possibly Michael (for speed)
Lightweight Modification
 Send in reverse order
Message x:
MAC addr. || Nonce || Data
h
h
.
.
.
h
0
1
n
802.11 Hdr
Data…
64-bit hash
Data…
Message 0
Message 1
.
.
.
Message n
- 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 my
afs space:
/afs/cs.wisc.edu/u/c/y/cychosz/public/wireless-sec/