11 ieee 802.11 (wifi) wired equivalent privacy (wep)
TRANSCRIPT
11
IEEE 802.11 (WiFi)
Wired Equivalent Privacy (WEP)
22
IEEE 802.11 – Two modes
(Independent) Basic Service Set (IBSS)
(ad-hoc network)
Extended Service Set (ESS) (infrastructure network)
See in lab #4
33
Network Lab 1996
44
55
8.1.1 Open System Authentication
► “Essentially it is a null authentication algorithm.”
► simple handshake – just two messages
► station’s application for authentication is not required to be successful (AP may be too busy to accept another station)
► this is the default
66
8.1.2 Shared-Key Authentication
“Shared Key authentication supports authentication of STAs as either a member of those who know a shared key or a member of those who do not.”
“The required secret, shared, key is presumed to have been delivered to participating STAs via a secure channel that is independent of IEEE 802.11.”
77
Encryption with RC4 stream cipher
plaintext 0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1keystream 1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0ciphertext 1 1 0 1 1 1 1 0 0 0 0 1 0 1 0 1
Detection of the keystream
C XOR P = (K XOR P) XOR P = K
plaintext 0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1ciphertext 1 1 0 1 1 1 1 0 0 0 0 1 0 1 0 1keystream 1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0
“During the Shared Key authentication exchange, both the challenge and the encrypted challenge are transmitted.”
We had this demonstration in discussion of stream ciphers:
Will this be a problem in WEP?
88
Shared Key Authentication involves exchange of four frames:
Frame 1 – requester to responder:
“I want to be a member of the ‘in’ group.”
Frame 2 - responder to requester:
Responder uses WEP to generate a 128-octet challenge text and transmits it to requester.
Frame 3 – requester to responder:
Requester copies the challenge text into the frame data area and transmits it using WEP (thereby encrypting the text).
Frame 4 – responder to requester:
Responder decrypts challenge and compares with original.
Code for “OK” or “not OK”
99
8.2 The Wired Equivalent Privacy (WEP) Algorithm
Objective is to protect users from “casual eavesdropping”
8.2.2 Properties of the WEP Algorithm
► It is reasonably strong
► It is self-synchronizing – will explain later
► It is efficient – may be implemented in either hardware or software
► It may be exportable
► It is optional
“Data confidentiality depends on an external key management service to distribute data enciphering/deciphering keys.”
10
128 bits
Length of Message
Figure 2.8 Stream Cipher Diagram
Reminder from Chapter 2: Stream cipher operation
Given the key, a key-stream is generated as long as the plaintext.
1111
8.2.3 WEP theory of operation
“The WEP algorithm is a form of electronic code book [not in the same sense as we used ECB in Chapter 2] in which a block of plaintext is bitwise XORed with a pseudorandom key sequence of equal length. The key sequence is generated by the WEP algorithm.”
8.2.4 WEP Algorithm Specification
WEP uses the RC4 PRNG
1212
Unlike the IV necessary with a block cipher using CBC, this IV would not have been required in this design using a stream cipher, but it was adopted to expand the secret key and avoid using the same key repeatedly (IV is a “salt”).
“The secret key remains constant while the IV changes periodically. Each new IV results in a new seed and a new key sequence …The IV may be changed as frequently as each MPDU [frame] and, since it travels with the message, the receiver will always be able to decipher any message [self-synchronizing]”
The PRNG seed is 64 bits = 24-bit IV || 40-bit Secret Key
(later option: seed 128 bits = 24-bit IV || 104-bit secret key – became widely used).
1313
1414
Figure 45 – WEP decipherment block diagram
1515Figure 6 - 802.11 frame format
Wired Ethernet Frame Format
Recall from CS 334/534:
8.2.5 WEP Frame Body Expansion
CRC-32
1616Figure 46 – Construction of expanded WEP frame body
CRC-32
CRC-32
1717
1818
“The WEP mechanism is invisible to entities outside the 802.11 data path.”
End of excerpt from IEEE 802.11 1999 standard
WEP applies only within a BSS
1919
Recall from Chapter 2 - Manipulation of message:
If a bit in the ciphertext is flipped, this produces an undetectable change in the decrypted message!
2020
Encryption with RC4 stream cipher
plaintext 0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1keystream 1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0ciphertext 1 1 0 1 1 1 1 0 0 0 0 1 0 1 0 1
Detection of the keystream
C XOR P = (K XOR P) XOR P = K
plaintext 0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1ciphertext 1 1 0 1 1 1 1 0 0 0 0 1 0 1 0 1keystream 1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0
“Factoring out the Keystream”
C1 XOR C2 = (P1 XOR K ) XOR (P2 XOR K)
= P1 XOR P2 XOR K XOR K = P1 XOR P2
However, this is the keystream, not the key itself
2121
Problems with WEP
After standard was issued in 1999, there was a flurry of criticism in 2001.
► Possible Attacks in Principle
1. If an attacker flips a bit in the ciphertext, then on decryption the corresponding bit in the plaintext will be flipped.
2. XOR of two ciphertexts encrypted with same keystream yields the XOR of the two plaintexts (“factors out the
keystream”)
If both plaintext and ciphertext are known, XOR gives keystream.► Claimed Defenses
1. To ensure that a packet has not been modified in transit, WEP includes an ICV within the encrypted packet
2. To avoid encrypting two plaintexts with the same keystream, an IV is used to produce a different RC4 key for each packet.
Borisov paper – July 2001
2222
► Claimed Defenses (repeat)
1. To ensure that a packet has not been modified in transit, WEP uses an ICV within the encrypted packet.
2. To avoid encrypting two plaintexts with the same keystream, an IV is used to produce a different RC4 key for each packet.
2323
► Claimed Defenses (repeat)
1. To ensure that a packet has not been modified in transit, WEP uses an ICV within the encrypted packet.
2. To avoid encrypting two plaintexts with the same keystream, an IV is used to produce a different RC4 key for each packet.► Defense Failures
1. The ICV is implemented as a CRC-32 checksum; flipping bit n in the encrypted message results in a deterministic set of bits that must be flipped in the encrypted ICV to produce a correct
checksum for the modified message.
2. IV is only 24 bits, sent “in the clear,” so in a busy network it will recycle fairly quickly (“IV collision”); usually all stations in the network use the same key, so it will not be hard to find two
messages encrypted with the same keystream.
Additionally, IV changes are not required by the 1999 standard
2424
A Note on the CRC-32 cyclic redundancy check (“checksum”)
We first meet it in the wired Ethernet Frame Format:
CRC-32 is extremely good at detecting random transmission errors, but useless against intentional changes made by Darth.
CRC-16 detects all random errors with an odd number of bits, all double errors, all burst errors with length 16 or less, 99.997% of 17-bit error bursts, and 99.998% of 18-bit and longer bursts.
2525
► Attacks in Practice
Passive Attack to Decrypt Traffic
Wait for an IV collision, then XOR ciphertexts to get XOR of plaintexts;
XOR of plaintext and ciphertext gives keystream for that IV.
Active Attack to Inject Traffic
Knowing keystream from above, Darth can construct a correctly encrypted packet;
Variant: Darth flips selected bits in the ciphertext and adjusts the ICV to make it correct for the altered message.
2626
Active Attack involving Internal and External Machines
Since WEP is applied only on the wireless link, if attacker has access to an external host (anywhere in the Internet) and knows the IP address of a machine inside the BSS, he can send a message to that machine, viewing the encrypted version on the wireless link
(this would be a “chosen plaintext attack”).
Darth!
Alternative: Copy encrypted packet on wireless link, guess destination IP address, change IP destination address to own external machine,
adjust ICV and send to AP;
AP will decrypt message and forward plaintext to attacker’s machine.
2727
Table-Based Attack
“The small space of possible IVs allows an attacker, over time, to build a decryption table. Once he learns the plaintext for some packet, he can compute the RC4 keystream generated by particular IV used in that packet …. Attacker can decrypt every packet that is sent over the wireless link until the secret key is changed.”
► Conclusion
“Wired Equivalent Privacy (WEP) isn’t.”
None of these attacks reveal the secret key
2828
Vulnerability of Challenge/Response, by Arbaugh et al (March, 2001)
Genuine authentication:
128-octet challenge
Frame 2
STA AP
Frame 3
128-octet challenge || 4-octet ICVIV3
2929
Vulnerability of Challenge/Response, by Arbaugh et al (March, 2001)
Genuine authentication:
128-octet challenge
Frame 2STA AP
Frame 3
128-octet challenge || 4-octet ICVIV3
Darth applies for authentication. He will receive a different 128-octet challenge. He transmits it using IV3 and the above 132-octet keystream.
He is authenticated.
Darth has observed both 128-octet challenge (so can compute the ICV) and the 132-octet response, so by XORing the strings computes
the 132-octet keystream for IV3.
Shared-key authentication less secure than Open Key!
ICV
3030
Brief [Non-Rigorous] Description of Fluhrer Attack (August, 2001)
3-octet IV || 5-octet secret key is used to seed RC4.
Introduce variable keybyte = 1..5 for the 5 octets of the secret key.
Fluhrer, Mantin and Shamir showed that certain IVs are “weak.”
The form of the weak IVs is (keybyte + 3, 0xFF, N) where N = anything.
For these weak IVs, the first byte of the keystream depends only on three internal 1-octet variables in RC4.
If we know the first octet of the keystream, we have a good chance of guessing the corresponding byte of the secret key.
The key, not just the keystream
3131
But how can we know the first byte of the keystream?
When an IP datagram is encapsulated in an 802.11 frame, this is the format:
For IP traffic, the contents of the first 6 octets after the 802.11 headers and the IV are fixed – first octet is 0xAA
So we know both the plaintext and ciphertext byte and can XOR.
To guess first octet of secret key, look for IVs of form
00000100 11111111 xxxxxxxx
Recall 802.11 Frame Format:
3232
Paper by Stubblefield, Ioannidis, and Rubin (August, 2001)
They demonstrated the theoretical Fluhrer attack in practice.
“ … protocol designers without a strong grounding in cryptography and security may not be aware of the correct way to implement them, and that is exactly what happened in the case of WEP.”
RSA Security, Inc. now recommends that the first 256 bytes of RC4 output be discarded.
Download “cracking” packages, such as Airsnort, quickly became available.
Stubblefield recommendations: (1) assume WEP provides no security!
(2) Use IPSec or SSH
(3) Treat all 802.11 systems as external; place all APs outside firewall
3333
Slides will follow the handout
“Wi-Fi Protected Access (WPA)”
This is a composite of Stallings’ Section 6.2 and two other books.
3434
What can be done to repair WEP?
By the end of 2001 it was clear that WEP was “broken,” and had to be replaced by a more secure algorithm.
Problem: Millions of pieces of WEP-oriented equipment, particularly Access Points had been deployed (“legacy equipment”). A replacement algorithm had to run on this equipment.
► software/firmware upgrades only – no chip replacement
► WEP encryption algorithm (RC4) is “wired in”
by special-purpose hardware
Three major constraints on a replacement algorithm
WEP Replacement is “Wi-Fi Protected Access” (WPA)
► only a few spare cycles available in usual AP microprocessor
3535
Figure 45 – WEP decipherment block diagram
In the AP these are done in a hardware “encryption engine,” not in software
3636
WPA and WPA2
WPA, introduced in April, 2003 was based on draft 3 of IEEE 802i
It was an interim “fix” designed to rescue “legacy” equipment and therefore subject to the severe constraints listed earlier.
In July, 2004 IEEE approved the final 802.11i specification as the Robust Security Network and the WiFi alliance adopted this as WPA2.
WPA2 provided all of the mechanisms available in WPA, plus:
Strong encryption (AES) and authentication support for infrastructure and ad-hoc networks (WPA is limited to infrastructure networks)
RSN/WPA2 involves an Authentication Server with protocol IEEE 801X and uses AES/CBC for encryption. This will probably be appropriate in and Enterprise (large company) situation.
We shall content ourselves with studying WPA in Small Office/Home Office (SOHO) Mode.
3737
IEEE 802i Phases of Operation – preview (Stallings page 184-6)
Phase 1 - Discovery
Phase 2 - Authentication
Phase 3 - Key Generation and Distribution to STA and AP
Phase 4 - Actual User Data Transfer
Phase 5 - Connection Termination when Transfer Complete
802.11i security is provided only over the wireless link within a BSS, not externally.
3838
Phase 1 – Discovery
The purpose of this phase is for STA and AP to establish (unsecure) contact and negotiate a set of security algorithms to be used in subsequent phases.
STA and AP need to decide on:
► The methods to be used in phase 3 to perform
mutual authentication of STA and AP and generate/distribute keys.
► Confidentiality and integrity algorithms to protect user data in phase 4
3939
The discovery phase uses three message exchanges (CS334/534):
► Probe request/response (or observation of a beacon frame)
► Authentication request/response
WEP Open System Authentication, for backward compatibility (provides no security)
APs advertize their capabilities (WEP, WPA, etc.) in InformationElements in their beacon frames and in their probe responses.
► Association request/response
STA chooses methods to be used from AP’s menu
(we will study the case that the station chooses WPA/TKIP)
STA uses an Information Element in Association Request
to inform AP
4040Figure 6.6 (upper) Phase 1 Discovery
This is not Phase 2/3
Authentication!
Phase 1
4141
There are two methods for providing the PSK:
► the exact 256-bit number can be provided and used as PMK
► a passphrase can be adopted, keyed in by user and expanded to 256 bits by the system.
Phase 2 - Authentication
SOHO Mode
A pre-shared key (PSK), is provided in advance to the station and AP by a method external to 802.11i
In this case the lower half of figure 6.6 is bypassed (and was not shown in the previous slide).
In WPA SOHO mode STA and AP delay authenticating each other until phase 3, when they demonstrate that each knows information
derived from the PSK.
4242
Phase 3 – Key Generation and Distribution
In SOHO mode the PSK has already been shared, so no more distribution is needed and key generation can proceed.
Next step in SOHO: The PSK is adopted as the Pairwise Master Key (PMK) (misnomer!)
Figure 6.8 (upper)
4343
The Pairwise Master Key is not used directly in any security operation.
Instead, it will be used to derive a set of keys, the Pairwise Transient Key, to protect the link between AP and station.
Protection is needed during two phases:
► in phase 3 - the handshake between station an AP
(protocol called “EAPOL”)
► in phase 4 - Passing user data during actual use of the link
4444
In both phases separate keys are needed for integrity and encryption, so the total number of keys needed is four:
► EAPOL-key Encryption key (KEK)
► EAPOL-key Confirmation key (KCK) (Integrity)
► Data Encryption Key (part of Temporal Key)
► Data Integrity Key (part of Temporal Key)
Figure 6.8 (middle)
PSK
4545
Computation of the PTK from the PMK
The PTK is re-computed every time a station associates with an AP.
We want the PTK to be different for each STA-AP pair and different each time a STA associates with an AP (so as not to re-use old keys)
Four-way handshake:
TKIP/WPA uses a four-way handshake during establishment of the association relationship between an AP and a station
APSTA
Preview
4646
Recall that in the discovery phase the STA sent its association request to the AP, including the selection of WPA/TKIP for security.
For later use, we can think of the STA randomly generating a nonce (Nonce1) at that point, but not transmitting it.
The standard refers to the Supplicant S (the STA seeking authentication) and the Authenticator A (the AP granting authentication).
We can force the PTK to be different for each STA-AP pair by mixing their MAC addresses into the computation of the PTK.
But since these do not change between associations, there must also be some dynamic input to the PTK - nonces.
4747
Four-Way Handshake
Frame 1: AP to STA: a nonce chosen by the AP (Nonce2)Nonce2 gives the STA the last piece of informationit needs to compute the 512-bit PTK:
Computation of PTK from PMK
4848
Four-Way Handshake - continued
Frame 2: STA to AP:
Nonce1, together with a message integrity code (MIC)
Nonce1 gives the AP the last piece of information it needs to compute the PTK, so key exchange is complete. This enables the AP to check the validity of the MIC. If correct, this proves that that the STA possesses the PMK and authenticates the STA.
Each side has chosen a nonce, and both nonces have been mixed into the computation of the PTK, so PTK is unique to
each AP-STA pair and to each association session .
4949
Four-Way Handshake - continued
Frame 3: AP to STA: message “AP able to turn on encryption”(includes MIC, so STA can check that AP knows PMK)
Frame 4: STA to AP: message “STA about to turn on encryption”
After sending frame 4, STA activates encryption; on receipt of frame 4, AP activates encryption.
At this point Phase 3 is complete – we have authenticated the STA and the AP, using the EAPOL keys, and have generated the 256-bit
Temporal Key for use in phase 4.
We can proceed to phase 4 – secure transmission of user data.
TKIP stands for Temporal Key Integrity Protocol
(“temporal” = “temporary” - only for this association session)
5050
WPA/TKIP adds new capabilities to WEP:
■ A cryptographic message integrity code, or MIC, called Michael, to replace CRC-32 and defeat forgeries
Designed by Niels Ferguson - will be executed in software;
■ A new IV sequencing discipline, to remove replay attacks from the attacker’s arsenal; the IV is expanded to 48 bits;
■ A per-packet key mixing function, to de-correlate the public IVs from Fluhrer’s “weak keys” and provide different encryption keys for each direction of transfer (to/from AP),
and each successive packet.
Phase 4 – Protected Data Transfer
(Recall that we’ve already generated different keys for each STA-AP pair and each association session)
5151
Defeating Forgeries: Michael
We’ll have to do the integrity-checking by software, since we can’t change the encryption/decryption chip.
Very few computing cycles available – cannot use SHA or MD5
New algorithm “Michael” designed to make minimal demands on microprocessor (e.g. no multiply instructions).
Recall that the WEP encryption engine used a copy the standard Ethernet CRC, placing it inside the encrypted payload. Borisov pointed out that, since CRC is linear, this does not provide significant protection against content tampering. So we cannot use the integrity-checking capability of the legacy chip.
5252
Defeating Replays: IV Sequence Enforcement
Recall that 802.11 allowed, but did not require, changes in IV
“To defeat replays, TKIP re-uses the IV as a packet sequence number.”
Sequence numbers initialized to zero when station associates with an AP;
If a frame arrives with sequence number the same as, or lower than, the previous correctly-received frame, the new frame is discarded.
5353
Defeating Weak-Key Attacks: Key Mixing
Invented by Doug Whiting and Ron Rivest (RSA)
Design goals:
► generate different encryption keys
for each AP-to-station direction
accomplished by “Phase 4.1”
► avoid the Fluhrer “weak keys” and generate different keys for each successive packet
accomplished by “Phase 4.2”
5454
Preview Both Phases:
5555
Phase 4.1 – generate different keys for each AP/Station direction
Mixes upper 32 bits of 48-bit IV with MAC addresses of sender (station or AP) with the temporal key (encryption) to produce the “Intermediate Key.”
“Intermediate Key” (80 bits)
The Intermediate Key needs to be recomputed only when the low-order 16 bits of the IV recycles.
AP or STA
Temporal key (encryption)
5656
Phase 4.2 – avoid Fluhrer “weak IVs” and different key each packet
The low-order 16 bits of the IV will be incremented by 1 for each frame, so the final RC4 encryption key is recomputed for each frame.
Anything except 0xFF
A “Tiny cipher” is used to encrypt the sequence number
under the intermediate key.
5757
Figure 45 – WEP decipherment block diagram
In the AP these are done in a hardware “encryption engine,” not in software
Repeat slide of WEP’s use of (unmodifiable) hardware:
5858
Feed into “Legacy” encryption engine
The legacy encryption engine does not know
or care about the significance of the 128
bit key.
Repeat diagram of WPA/TKIP phase 4.2:
5959
Summary
“WPA/TKIP is a wrapper around WEP and does not constitute an ideal security protocol design. The TKIP MIC is weak enough to require countermeasures to be effective, but together these are strong enough to diminish the likelihood that forgeries succeed. The key mixing function is extra work that would be unnecessary if the original WEP design had selected almost any cipher other than RC4, but preserves the original hardware investment.”
“Its design team includes well-known cryptographers and, unlike WEP, it has received extensive reviews both by the broader security community for correctness and by the 802.11 hardware vendors for feasibility.”
6060
The Known-PSK attack by Stations within the ESS
The normal SOHO practice is to have a single PMK for all stations and APs within an ESS. Therefore, to generate the PTK used by any station/AP pair, a station within the ESS that wishes to spy needs to learn only the two MAC addresses and two nonces.
All of this is available during the Four-Way Handshake. Any device can passively listen for these frames and then generate the PTK.
Thus even though each unicast station/AP pairing in the ESS has unique keys (PTK) there is nothing private about these keys to any other device in the ESS, because they all have the same PMK.
6161
End of WEP/WPA/TKIP/WPA2 material
END OF COURSE!!!
6262
Exam #2
Thursday, August 2, 2012
5:30 – 7:00pm
In this room