Upload
stanley-butler
View
217
Download
0
Embed Size (px)
Citation preview
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/