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 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 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 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’. WhereM’ = 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.securityfocus.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 • pass phrase • other improvements: • -key generated from pw + salt + PRNG 802.1x Authentication
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 Feistel structure intermediate key
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 CCMP / TKIP / WRAP Encryption / Integrity EAP RADIUS EAP-TLS Outside of 802.11i, but de facto standard Authentication / Key Dist.
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 “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 – 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: • EAP-Request • EAP-Response • EAP-Success • EAP-Failure
EAP General EAP Message Flow
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
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 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)
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
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
EAP Packet header: Code Identifier Length Data . . . Code: Message type Identifier: To pair up messages Length: Header + Data size - Integrity depends on lower layers
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
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.
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 • 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) AP-RADIUS key