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