Ieee 802 11 wifi l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 62

IEEE 802.11 (WiFi) PowerPoint PPT Presentation


  • 52 Views
  • Uploaded on
  • Presentation posted in: General

IEEE 802.11 (WiFi). Wired Equivalent Privacy (WEP). 1. IEEE 802.11 – Two modes. (Independent) Basic Service Set (IBSS) (ad-hoc network). Extended Service Set (ESS) (infrastructure network). See in lab #4. 2. Network Lab 1996. 3. 4. 8.1.1 Open System Authentication

Download Presentation

IEEE 802.11 (WiFi)

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Ieee 802 11 wifi l.jpg

IEEE 802.11 (WiFi)

Wired Equivalent Privacy (WEP)

1


Slide2 l.jpg

IEEE 802.11 – Two modes

(Independent) Basic Service Set (IBSS) (ad-hoc network)

Extended Service Set (ESS) (infrastructure network)

See in lab #4

2


Slide3 l.jpg

Network Lab 1996

3


Slide4 l.jpg

4


Slide5 l.jpg

8.1.1 Open System Authentication

► “Essentially it is a null authentication algorithm.”

► this is the default

► 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)

5


Slide6 l.jpg

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.”

6


Slide7 l.jpg

“During the Shared Key authentication exchange, both the challenge and the encrypted challenge are transmitted.”

We had this demonstration in discussion of stream ciphers:

Encryption with RC4 stream cipher

plaintext0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1

keystream 1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0

ciphertext 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

plaintext0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1

ciphertext 1 1 0 1 1 1 1 0 0 0 0 1 0 1 0 1

keystream1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0

Will this be a problem in WEP?

7


Slide8 l.jpg

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”

8


Slide9 l.jpg

8.2 The Wired Equivalent Privacy (WEP) Algorithm

Objective is to protect users from “casual eavesdropping”

“Data confidentiality depends on an external key management service to distribute data enciphering/deciphering keys.”

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

9


Slide10 l.jpg

Reminder from Chapter 2: Stream cipher operation

Given the key, a key-stream is generated as long as the plaintext.

128 bits

Length of Message

Figure 2.8 Stream Cipher Diagram


Slide11 l.jpg

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

11


Slide12 l.jpg

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).

12


Slide13 l.jpg

13


Slide14 l.jpg

Figure 45 – WEP decipherment block diagram

14


Slide15 l.jpg

8.2.5 WEP Frame Body Expansion

Recall from CS 334/534:

Wired Ethernet Frame Format

CRC-32

Figure 6 - 802.11 frame format

15


Slide16 l.jpg

CRC-32

CRC-32

Figure 46 – Construction of expanded WEP frame body

16


Slide17 l.jpg

17


Slide18 l.jpg

“The WEP mechanism is invisible to entities outside the 802.11 data path.”

WEP applies only within a BSS

End of excerpt from IEEE 802.11 1999 standard

18


Slide19 l.jpg

Recall from Chapter 2 - Manipulation of message:

If a bit in the ciphertext is flipped, this produces an undetectable change in the decrypted message!

19


Slide20 l.jpg

Encryption with RC4 stream cipher

plaintext0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1

keystream 1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0

ciphertext 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

plaintext0 1 1 0 1 1 1 1 1 0 1 1 0 0 1 1

ciphertext 1 1 0 1 1 1 1 0 0 0 0 1 0 1 0 1

keystream1 0 1 1 0 0 0 1 1 0 1 0 0 1 1 0

However, this is the keystream, not the key itself

“Factoring out the Keystream”

C1 XOR C2 = (P1 XOR K ) XOR (P2 XOR K)

= P1 XOR P2 XOR K XOR K = P1 XOR P2

20


Slide21 l.jpg

Problems with WEP

After standard was issued in 1999, there was a flurry of criticism in 2001.

Borisov paper – July 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.

21


Slide22 l.jpg

► 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.

22


Slide23 l.jpg

► 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

23


Slide24 l.jpg

A Note on the CRC-32 cyclic redundancy check (“checksum”)

We first meet it in the wired Ethernet Frame Format:

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.

CRC-32 is extremely good at detecting random transmission errors, but useless against intentional changes made by Darth.

24


Slide25 l.jpg

► 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.

25


Slide26 l.jpg

Active Attack involving Internal and External Machines

Darth!

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 theencrypted version on the wireless link

(this would be a “chosen plaintext attack”).

Alternative: Copy encrypted packet on wireless link, guess destination IP address, change IP destination address to ownexternal machine, adjust ICV and send to AP;

AP will decrypt message and forward plaintext to attacker’s machine.

26


Slide27 l.jpg

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

27


Slide28 l.jpg

Vulnerability of Challenge/Response, by Arbaugh et al (March, 2001)

Genuine authentication:

Frame 2

AP

STA

128-octet challenge

Frame 3

128-octet challenge || 4-octet ICV

IV3

28


Slide29 l.jpg

Vulnerability of Challenge/Response, by Arbaugh et al (March, 2001)

Genuine authentication:

Frame 2

AP

STA

128-octet challenge

ICV

Frame 3

128-octet challenge || 4-octet ICV

IV3

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.

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.

Shared-key authentication less secure than Open Key!

29


Slide30 l.jpg

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

30


Slide31 l.jpg

But how can we know the first byte of the keystream?

Recall 802.11 Frame Format:

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

31


Slide32 l.jpg

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.

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

Download “cracking” packages, such as Airsnort, quickly became available.

32


Slide33 l.jpg

Slides will follow the handout

“Wi-Fi Protected Access (WPA)”

This is a composite of Stallings’ Section 6.2 and two other books.

33


Slide34 l.jpg

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.

Three major constraints on a replacement algorithm

► software/firmware upgrades only – no chip replacement

► only a few spare cycles available in usual AP microprocessor

► WEP encryption algorithm (RC4) is “wired in”

by special-purpose hardware

WEP Replacement is “Wi-Fi Protected Access” (WPA)

34


Slide35 l.jpg

Figure 45 – WEP decipherment block diagram

In the AP these are done in a hardware “encryption engine,” not in software

35


Slide36 l.jpg

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.

36


Slide37 l.jpg

IEEE 802i Phases of Operation – preview (Stallings page 184-6)

802.11i security is provided only over the wireless link within a BSS, not externally.

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

37


Slide38 l.jpg

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

38


Slide39 l.jpg

The discovery phase uses three message exchanges (CS334/534):

► Probe request/response (or observation of a beacon frame)

APs advertize their capabilities (WEP, WPA, etc.) in Information

Elements in their beacon frames and in their probe responses.

► Authentication request/response

WEP Open System Authentication, for backward compatibility (provides no security)

► 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

39


Slide40 l.jpg

Phase 1

This is not Phase 2/3 Authentication!

Figure 6.6 (upper) Phase 1 Discovery

40


Slide41 l.jpg

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).

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.

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.

41


Slide42 l.jpg

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!)

42

Figure 6.8 (upper)


Slide43 l.jpg

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

43


Slide44 l.jpg

In both phases separate keys are needed for integrity and encryption, so the total number of keys needed is four:

► EAPOL-key Confirmation key (KCK) (Integrity)

► EAPOL-key Encryption key (KEK)

► Data Integrity Key (part of Temporal Key)

► Data Encryption Key (part of Temporal Key)

PSK

44

Figure 6.8 (middle)


Slide45 l.jpg

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

STA

AP

Preview

45


Slide46 l.jpg

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.

The standard refers to the Supplicant S (the STA seeking authentication) and the Authenticator A (the AP granting authentication).

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.

46


Slide47 l.jpg

Four-Way Handshake

Frame 1:AP to STA:a nonce chosen by the AP (Nonce2)

Nonce2 gives the STA the last piece of information

it needs to compute the 512-bit PTK:

Computation of PTK from PMK

47


Slide48 l.jpg

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 .

48


Slide49 l.jpg

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)

49


Slide50 l.jpg

Phase 4 – Protected Data Transfer

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.

(Recall that we’ve already generated different keys for each STA-AP pair and each association session)

50


Slide51 l.jpg

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.

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).

51


Slide52 l.jpg

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.

52


Slide53 l.jpg

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”

53


Slide54 l.jpg

Preview Both Phases:

54


Slide55 l.jpg

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)

AP or STA

The Intermediate Key needs to be recomputed only when the low-order 16 bits of the IV recycles.

Temporal key (encryption)

55


Slide56 l.jpg

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.

A “Tiny cipher” is used to encrypt the sequence number under the intermediate key.

Anything except 0xFF

56


Slide57 l.jpg

Repeat slide of WEP’s use of (unmodifiable) hardware:

Figure 45 – WEP decipherment block diagram

In the AP these are done in a hardware “encryption engine,” not in software

57


Slide58 l.jpg

Repeat diagram of WPA/TKIP phase 4.2:

The legacy encryption engine does not know or care about the significance of the 128 bit key.

Feed into “Legacy” encryption engine

58


Slide59 l.jpg

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.”

59


Slide60 l.jpg

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.

60


Slide61 l.jpg

End of WEP/WPA/TKIP/WPA2 material

END OF COURSE!!!

61


Slide62 l.jpg

Exam #2

Thursday, August 2, 2012

5:30 – 7:00pm

In this room

62


  • Login