1. Security Analysis and Improvements for IEEE 802.11i
Changhua He, John C Mitchell
Stanford University

2. Acronym List CCMP: Counter-mode/CBC-MAC Protocol
RSNA: Robust Security Network Association
RSN IE: RSN Information Element
PTK: Pairwise Transient Key
GTK: Group Transient Key
TKIP: Temporal Key Integrity Protocol
EAP: Extensible Authentication Protocol
PSK: Pre-Shared Key
MIC: Message Integrity Code

3. Outline Wireless Threat Models IEEE 802.11i Attacks and Solutions
Possible threats and their practicality in wireless networks
IEEE i
Data Confidentiality & Integrity: CCMP
Mutual Authentication: RSNA Establishment Procedure
Availability: not an original design objective, problematic
Attacks and Solutions
On Authentication: Security level rollback, reflection attack
On Availability: Michael countermeasure attack, RSN IE poisoning, 4-Way Handshake blocking
Failure Recovery and improved i
Conclusions

4. Wireless Threats Passive Eavesdropping/Traffic Analysis
Easy, most wireless NICs have promiscuous mode
Message Injection/Active Eavesdropping
Easy, some techniques to gen. any packet with common NIC
Message Deletion and Interception
Possible, interfere packet reception with directional antennas
Masquerading and Malicious AP
Easy, MAC address forgeable and s/w available (HostAP)
Session Hijacking
Man-in-the-Middle
Denial-of-Service: cost related evaluation
In cryptography, a man-in-the-middle attack (MITM) is an attack in which an attacker is able to read, insert and modify at will, messages between two parties without either party knowing that the link between them has been compromised. The attacker must be able to observe and intercept messages going between the two victims. The MITM attack is particularly applicable to the original Diffie- Hellman key exchange protocol, when used without authentication.
Session hijacking is the act of taking control of a user session after successfully obtaining or generating an authentication session ID. Session hijacking involves an attacker using captured, brute forced or reverse-engineered session IDs to seize control of a legitimate user's Web application session while that session is still in progress.
HTTP is stateless, so application designers had to develop a way to track the state between multiple connections from the same user, instead of requesting the user to authenticate upon each click in a Web application. A session is a series of interactions between two communication end points that occurs during the span of a single connection. When a user logs into an application a session is created on the server in order to maintain the state for other requests originating from the same user.
Applications use sessions to store parameters which are relevant to the user. The session is kept "alive" on the server as long as the user is logged on to the system. The session is destroyed when the user logs-out from the system or after a predefined period of inactivity. When the session is destroyed, the user's data should also be deleted from the allocated memory space.

5. IEEE 802.11a/b/g WEP Weakness in WEP
Key (IV (24) + shared key (40 or 104))
Encryption algorithm: RC4
Data integrity: ICV (Integrity Check Value), which is linear and un-keyed function of the message.
Open system (no authentication)
Shared key authentication (challenge response handshake)
Weakness in WEP
Key scheduling problem due to the short IV.
Weak one direction authentication.
No protection mechanism (such as timestamp, nonce) against replay attack.
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack.

6. WPA: a interim solution
WPA (Wi-Fi protected Access)
Data integrity:
TKIP (Temporal Key Integrity Protocol) using key mixing function and IV space extension.
A weak keyed MIC (Message Integrity Code) is introduced to improve the ICV.
Monotonically increasing sequence number to prevent replay attacks.
Two more authentication schemes
PSK (Pre-Shared Key) to authenticate peers. Besides, based on PSK, 128 bit encryption key and 64 bit MIC key can be generated.
IEEE 802.1X+EAP (Extensible Authentication Protocol) is stronger.
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack.

7. Is WPA good enough?
It seems that WPA patches every vulnerabilities in WEP.
Weakness is predestined since WPA wants to re-use the legacy hardware:
TKIP’s key mixing function is not strong as expected.
Whole security is broken for the duration of a Temporal Key if two per-packet keys with the same IV32.
It is possible to find the MIC key given one per-packet key.
802.1x still vulnerable to session hijacking and man-in-the-middle attack.
Long term solution: IEEE i
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack.

8. IEEE i
Ratified on June 24, 2004.
Proposed to provide enhanced MAC layer security.
Data confidentiality and integrity
Encryption in Link Layer
WEP: Wired Equivalent Privacy
TKIP: Temporal Key Integrity Protocol
CCMP: Counter-mode/CBC-MAC Protocol
Mutual authentication
RSNA: Robust Security Network Association
EAP-TLS/802.1X/RADIUS
Key management: 4-Way handshake, Group key handshake, etc.
Availability
not an original design objective
Some real vulnerabilities exist
Why not PHY layer or IP and above layer?
It is hard to do it in PHY layer because it requires significant modifications of current PHY. Proposed solutions include proper antenna selecting and positioning, RF firewall architecture.
IP and above layer makes network more complicated. More importantly, it beaks the fact that is for MAC and below layers. Practical question, station needs to gain partly access before any application layer authentication can be initiated.

9. RSNA Establishment Procedures
Through these handshakes, the supplicant and the authenticator mutually authenticate each other and establish a secure session for data transmissions.

10. 802.11i: Confidentiality & Integrity
WEP, TKIP for backward compatibility (802.11a/b/g)
CCMP: long-term solution
AES: 128-bit key, 128-bit block, Counter mode + CBC-MAC
48-bit Packet Number for replay prevention
Use the same key for both Encryption and MIC
Counter and init. vector not overlap
better to use different key for different purpose
Message Integrity Code or MIC is used to refer to a cryptographic checksum used in the handshaking process.
This is equivalent to what is often referred to as a MAC or Message Authentication Code. The acronym MAC stands for Media Access Control in networking.
With a fresh key, i CCMP is believed secure for confidentiality and integrity !

11. 802.11i: Mutual Authentication
RSNA Establishment Procedures
Network and Security Capability Discovery
Open System Authentication and Association
EAP/802.1X/RADIUS Authentication
4-Way Handshake
Group Key Handshake
Secure Data Communications
RSNA security analysis gives:
can provide satisfactory authentication and key management
could be problematic in Transient Security Networks (TSN)
reflection attack could be possible if not implemented correctly

12. RSNA Conversations 4-Way Handshake Supplicant Auth/Assoc
802.1X UnBlocked
PTK/GTK
Authenticator Auth/Assoc
Authentica-tion Server (RADIUS)
No Key
Group Key Handshake
Supplicant
Auth/Assoc
802.1X UnBlocked
New GTK
Authenticator Auth/Assoc
Authentica-tion Server (RADIUS)
No Key
MSK
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator Auth/Assoc
Authentica-tion Server (RADIUS)
No Key
Data Communication
Supplicant
Auth/Assoc
802.1X UnBlocked
PTK/GTK
Authenticator Auth/Assoc
Authentica-tion Server (RADIUS)
No Key
EAP/802.1X/RADIUS Authentication
Supplicant
Auth/Assoc
802.1X Blocked
MSK
Authenticator Auth/Assoc
No Key
Authentica-tion Server (RADIUS)
Supplicant
UnAuth/UnAssoc
802.1X Blocked
No Key
Supplicant
Auth/Assoc
802.1X Blocked
No Key
Authenticator Auth/Assoc
Authentica-tion Server (RADIUS)
Association
Authenticator UnAuth/UnAssoc
802.1X Blocked
No Key
Authentica-tion Server (RADIUS)
No Key

13. Outline Wireless Threat Models IEEE 802.11i Attacks and Solutions
On Authentication:
1. Security level rollback
2. reflection attack
On Availability:
3. Michael countermeasure attack
4. RSN IE poisoning
5. 4-Way Handshake blocking
Failure Recovery and improved i
Conclusions

14. Security Level Rollback Attack
Supplicant
RSNA enabled
Pre-RSNA enabled
Authenticator RSNA enabled
Pre-RSNA enabled
Bogus Beacon (Pre-RSNA only)
Beacon + AA RSN IE
Probe Request
Bogus Probe Response (Pre-RSNA only)
Probe Response + AA RSN IE
Authentication Request
Authentication Response
Bogus Association Request (Pre-RSNA only)
Association Request + SPA RSN IE
Association Response
Pre-RSNA Connections

15. Security Rollback: solutions
Security Level Rollback Attack
Similar to general version-rollback attack
Destroy the security since WEP is completely insecure
Not a real vulnerability of i standard, but an implementation problem of TSN
Very possible mistake for transparency requirement
Solutions
Allow only RSNA connections: secure, but too strict for common network systems, where TSN is more convenient
Adopt both, supplicant manually choose to deny or accept a connection, authenticator restrict pre-RSNA (WEP) connections to only insensitive data

16. Reflection Attack Adversary Impersonates Communicating Peers
Legitimate Devices
Authenticator and Supplicant
{A1, Nonce1, sn, msg1}
{A2, Nonce1, sn, msg1}
{A1, Nonce2, RSN IE, sn, msg2, MIC}
{A2, Nonce2, RSN IE, sn, msg2, MIC}
{A1, Nonce1, RSN IE, GTK, sn+1, msg3, MIC}
{A2, Nonce1, RSN IE, GTK, sn+1, msg3, MIC}
{A1, sn+1, msg4, MIC}
{SPA, sn+1, msg4, MIC}
Bogus Authentication
Peers Authenticated

17. Reflection Attack: Solutions
Possible in ad hoc networks
Each participant plays the role of both authenticator and supplicant
Violate the mutual authentication concept
Less damage if strong confidentiality adopted
Adversary fool the peers to send packets
Cannot decrypt the packet and generate response
Solutions:
Restrict each participant to play only one role: ok for WLAN, but inappropriate for ad hoc networks
Each participant play both roles, but under different PMK

18. 802.11i: Availability Not an original design objective
Physical Layer DoS attack
Inevitable but expensive and detectable
Network and upper Layer DoS attack
Depend on protocols, not our focus
Link Layer DoS attack
Flooding attack: could be detected and located
Some Known DoS attacks on networks
DoS attack on Michael countermeasure in TKIP
RSN IE Poisoning/Spoofing
4-Way Handshake Blocking

19. Known DoS attacks and Solutions
DoS attacks on plain networks
Forge unprotected management frames, like Deauthentication/Disassociation frame
Exploit virtual carrier sense mechanism by forging unprotected control frames, like RTS/CTS etc.
802.11i still has these problems, solutions could be
Authenticate management frames
Validate virtual carrier sense in control frames
DoS attacks on EAP messages
Forge EAPOL-Start, EAPOL-Success, EAPOL-Logoff, EAPOL-Failure
802.11i can eliminate these by simply ignoring them !
Send more than 255 association request to exhaust the EAP identifier space (8 bits)
Adopt separate EAP identifier counter for each association

20. Michael Countermeasure
TKIP Michael algorithm and countermeasures
Message Integrity Code (MIC), provide 20-bit security
one successful forgery / 2 min., need countermeasures
Cease communication for 60 sec. if two Michael MIC failures detected in one minute, re-key & deauthentication
Limit to one successful forgery / 6 month
Check order: FCS < ICV < TSC < MIC
Update TSC unless MIC is validated
MAC
IV/KeyID
TKIP MPDU Format
Ext. IV
Data/MSDU
MIC
ICV
FCS
Encrypted
Contains TSC

21. Michael DoS and Solutions
DoS attack through MIC failures
Intercept a packet with valid TSC (possible)
Modify packet and corresponding values of FCS, ICV (easy)
Send modified packet twice in one minute (easy)
MIC always invalid, TSC always valid
Solutions
When MIC failure, cease communication only, no re-keying and deauthentication
Update TSC before MIC is validated
What happens if modify TSC to extremely large number?
Change TSC also change encryption key, wrong decryption
Some confidence on TKIP key schedule algorithm
Mitigation but not elimination

22. RSN IE Poisoning Supplicant Unauthenticated Unassociated
802.1X Blocked
Authenticator Unauthenticated
Unassociated
802.1X Blocked
(1) Beacon + AA RSN IE
Bogus Beacon + Modified RSN IE
(2) Probe Request
(3) Probe Response + AA RSN IE
Bogus Probe Response + Modified RSN IE
Legitimate Message Exchanges
(18) {AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC}
RSN IE confirmation failed, Disassociation
Disassociate the Supplicant

23. RSN IE Poisoning: Solutions
Easy to launch the attack
Legitimate participants unaware of it
Continue message exchanges, waste resources
Adversary have more time to repeat the attack
Solutions
Authenticate management frames
Difficult to authenticate Beacon and Probe Response frame
Confirm RSN IE as soon as possible (EAP-TLS)
Necessary modifications on the standard
Relax the condition of RSN IE confirmation
Ignore insignificant bits, only confirm authentication suite
If authentication suite modified, probably error at the beginning of associations

24. 4-Way Handshake Blocking
Supplicant
Auth/Assoc
802.1X Blocked
PMK
Authenticator Auth/Assoc
802.1X Blocked
PMK
AA, ANonce, sn, msg1
PTK Derived
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
AA, ANonce[1], sn, msg1
PTK Derived
Random GTK
AA, ANonce[n], sn, msg1
AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC
SPA, sn+1, msg4, MIC
PTK and GTK
802.1X Unblocked
PTK and GTK 802.1X Unblocked

25. 4-Way Blocking: Solutions
Random-Drop Queue: not so effective
Authenticate Message 1
Make use of the share PMK, but need to modify packet format
Re-use supplicant nonce
Supplicant re-use SNonce, eliminate memory DoS
Performance degradation, more computations in the supplicant
Combined solution:
Supplicant re-use SNonce
Store one entry of received ANonce and derived PTK
If ANonce in Message 3 matches the entry, use PTK directly; otherwise derive PTK from Message 3 and use it
Eliminate the attack, ensure performance in “friendly” scenarios, only minor modifications on the algorithm

26. Failure Recovery Important for large protocols like 802.11i
Not affect protocol correctness, but efficiency
Not eliminate DoS vulnerabilities, but make DoS more difficult
802.11i adopts a simple scheme
Whenever failure, restart from the beginning, inefficient !
Tradeoffs
Defensive DoS attack vs Captured DoS attack
Assumptions on adversary’s capability and network scenario
A better failure recovery for i
If failure before 802.1X finishes, restart everything
Otherwise restart components from nearest point
channel scanning time >> protocol execution time

27. Improved 802.11i Architecture
Stage 1: Network and Security Capability Discovery
Stage 2: 802.1X Authentication
(mutual authentication, shared secret, cipher suite)
Stage 3: Secure Association (management frames protected)
Stage 4: 4-Way Handshake
(PMK confirmation, PTK derivation, and GTK distribution)
Stage 5: Group Key Handshake
Stage 6: Secure Data Communications
Michael MIC Failure or Other Security Failures
Group Key Handshake Timout
4-Way Handshake Timout
Association Failure
802.1X Failure

28. Conclusions 802.11i provides Some implementation mistakes
Satisfactory data confidentiality & integrity with CCMP
Satisfactory mutual authentication & key management
Some implementation mistakes
Security Level Rollback Attack in TSN
Reflection Attack on the 4-Way Handshake
Availability is a problem
Simple policies can make i robust to some known DoS
Possible attack on Michael Countermeasures in TKIP
RSN IE Poisoning/Spoofing
4-Way Handshake Blocking
Inefficient failure recovery scheme
Improved i

29. Highlight Our Findings
ATTACKS
SOLUTIONS
security rollback
supplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data.
reflection attack
each participant plays the role of either authenti-cator or supplicant; if both, use different PMKs.
attack on Michael countermeasures
cease connections for a specific time instead of re-key and deauthentication; update TSC before MIC and after FCS, ICV are validated.
RSN IE poisoning
Authenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage;
Relax the condition of RSN IE confirmation.
4-way handshake blocking
adopt random-drop queue, not so effective;
authenticate Message 1, packet format modified;
re-use supplicant nonce, eliminate memory DoS.