CISC 490

Senior Project

An Analysis of Wireless Network

Security and
Practical Exploitation of the Weakness
in
the Encryption Algorithm of the 802.11b
Wired Equivalent Privacy Protocol

Qi Liao
Hartwick College
May 2005

Introduction
My motivation:
Wireless communication has taken off.
Great potential: convenience, increasing speed
and security.
How secure is it?
 Almost every Univ. & College has wireless
network on campus. Increasing necessity to
investigate its security.
My Goal:
This project is to explore two basic wireless
networks architecture here at Hartwick College:
open-system and WEP protected system, with
emphasis on breaking WEP.
Does WEP really achieve its goal: Wired
Equivalent Privacy?
My Architecture:
Two laptop computers with wireless cards and
one WEP encrypted AP.
One is used to passively intercept the
communication between the other computer and
the AP.
My Approach:
theoretical analysis supported with empirical
data, and some implementations of
programming.

Wireless Communications
Wireless networks are diverse. Three
categories:
Wireless Wide Area Networks
(WWAN)
(cell phones) 2G cellular, CDPD,
GSM, Mobitex.
Wireless Local Area Network
(WLAN)
802.11, HiperLAN
Wireless Personal Area Networks
(WPAN)
Bluetooth, IR, ad hoc (no
infrastructures needed)
Wireless technologies are changing
rapidly. New products and features
means new threats or vulnerabilities.
Security of cell phones, PDA, and other
ad hoc or Bluetooth networks are
interesting.
My focus: Security of WLAN

802.11 Wireless Local Area Network

(WLAN):
In contrast with traditional LAN, WLAN
has the following advantages:
User Mobility
Rapid Installation
Flexibility & Scalability
Low Implementation Cost
WLAN connects computers to the
network using an Access Point (AP)
device
WLAN are based on the IEEE 802.11
standard—Wireless LAN Medium
Access Control (MAC) and Physical
Layer Specifications--1999. (first
published in 1999)
Although 802.11g was available long
time ago, 802.11b is still the dominant
standard for WLAN for now.

802.11 Wireless Local Area Network

(WLAN):
Figure 1: A Basic Topology of a 802.11 WLAN

802.11 Wireless Local Area Network

(WLAN):

All the vulnerabilities that

exist in a conventional
wired network apply to
wireless technologies.
Furthermore, due to the
communications medium,
the airwave, is open to
intruders, making it the
logical equivalent of an
Ethernet port in the
parking lot.
How to protect our
privacy?--WEP

Wired Equivalent Privacy

(WEP):
WEP protocol protects link-level data
during wireless transmission between
clients and access points.
Overall, WEP provides three basic
security services as defined by IEEE for
the WLAN environment:
Authentication— “Are only authorized
persons allowed to gain access to my
network?”
Confidentiality—“Can any unauthorized
person view my confidential data in
transmission?”
Integrity—“Is the data coming into or
exiting the network trustworthy—has it
been modified?”

Open-system Authentication and

Shared-key Authentication and Privacy:
Open-system:
not truly authentication.
AP accepts any mobile station that
responds with a MAC address during
the two-message exchange.
the only required form by the 802.11
specification.
Shared-key System:
requires the knowledge of a secret
WEP key in order to get on the
network.
not mutual authentication.
the client does not authenticate the
AP.
rogue APs. As long as the signal is
stronger.

Figure 2: Taxonomy of 802.11 Authentication Techniques

Open-system Authentication and Shared-key

Authentication and Privacy:

Attacks to Open-System:
Architecture of Yager Hall Library: I
used
NetStumbler version 0.4.0 to obtain the
basic information of the APs and WLAN.
There are one Avaya AP on the 5th floor of
the library (channel 9) and the other on the
2nd floor (channel 3).
Figure 3: AP Information Obtained through NetStumbler

Attacks to Open-System:
I used Ethereal—the Network Protocol
Analyzer Version 0.10.9 to analyze
packet data.
I used “host 147.205.100.135” as both
source and destination address in the
capture filter to monitor all the traffic
come to and leave the machine that I
am testing in the lab on the 5th floor of
library.
It was more efficient in my own test
environment. More importantly it
prevented accidentally violate the
privacy of other users.
Below are the raw data of the packets
that I captured under the open-system
wireless network by using Microsoft
Outlook to send and receive emails.
As we can clearly see the user
information in Table 1, 2, and 3, the user
name is “LiaoQ” and password is
“M1234%^dd”. The message is also
sent in plain text, which is “This is a
secret message text here.”

Attacks to Open-System:
0000 00 02 b3 d0 cb 42 00 0d 88 58 ce 88 08 00 45
00 .....B...X....E.

0010 00 34 04 61 40 00 80 06 14 71 93 cd 64 87 93
cd .4.a@....q..d...

0020 55 d0 0b f5 00 6e 1a 65 34 a3 9a 38 87 2b 50
18 U....n.e4..8.+P.

0030 44 17 6b f9 00 00 55 53 45 52 20 6c 69 61 6f
71 D.k...USER liaoq

0040 0d
0a ..

Table 1: Captured Data under the Open-system Wireless

Network in Yager Hall Library. POP3 Logon User
Information.

0000 00 02 b3 d0 cb 42 00 0d 88 58 ce 88 08 00 45
00 .....B...X....E.
0010 00 38 04 62 40 00 80 06 14 6c 93 cd 64 87 93
cd .8.b@....l..d...

0020 55 d0 0b f5 00 6e 1a 65 34 af 9a 38 87 30 50
18 U....n.e4..8.0P.

0030 44 12 4d c3 00 00 50 41 53 53 20 4d 31 32 33
34 D.M...PASS M1234

0040 25 5e 64 64 0d
0a %^dd..

Table 2: Captured Data under the Open-system Wireless Network in Yager

Hall Library. POP3 Logon User’s Password Information.

00:02:b3:d0:cb:42 is the Destination MAC address

associated with IP address of 147.205.85.210, which
is the Hartwick Mail Exchange server:
hcexch.hartwick.edu. 00:0d:88:58:ce:88 is Source
MAC address of my test machine associated with IP
address of 147.205.100.135, which is translated as
yag5thd1.hartwick.edu.

Attacks to Open-System:
0000 00 02 b3 d0 cb 42 00 0d 88 58 ce 88 08 00 45
00 .....B...X....E.

0010 02 2b 04 5a 40 00 80 06 12 81 93 cd 64 87 93
cd .+.Z@.......d...

0020 55 d0 0b f4 00 19 1a 63 8d 18 9a 35 d0 5b 50
18 U......c...5.[P.

0030 43 4f 26 ec 00 00 46 72 6f 6d 3a 20 22 71 69
22 CO&...From: "qi"
0040 20 3c 6c 69 61 6f 71 40 68 61 72 74 77 69 63
6b <liaoq@hartwick

0050 2e 65 64 75 3e 0d 0a 54 6f 3a 20 3c 6c 69 61
6f .edu>..To: <liao

0060 71 40 68 61 72 74 77 69 63 6b 2e 65 64 75 3e
0d q@hartwick.edu>.

0070 0a 53 75 62 6a 65 63 74 3a 20 73 65 63 72 65
74 .Subject: secret

0080 20 6d 65 73 73 61 67 65 0d 0a 44 61 74 65 3a
20 message..Date:

0090 46 72 69 2c 20 34 20 46 65 62 20 32 30 30 35
20 Fri, 4 Feb 2005

00a0 31 35 3a 32 38 3a 33 36 20 2d 30 35 30 30 0d
0a 15:28:36 -0500..

00b0 4d 65 73 73 61 67 65 2d 49 44 3a 20 3c 4d 43
45 Message-ID: <MCE

00c0 45 4c 47 43 48 4c 45 50 44 46 42 46 41 50 4b
46 ELGCHLEPDFBFAPKF

00d0 48 43 45 41 42 43 41 41 41 2e 6c 69 61 6f 71
40 HCEABCAAA.liaoq@

00e0 68 61 72 74 77 69 63 6b 2e 65 64 75 3e 0d 0a
4d hartwick.edu>..M

00f0 49 4d 45 2d 56 65 72 73 69 6f 6e 3a 20 31 2e
30 IME-Version: 1.0

0100 0d 0a 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a
20 ..Content-Type:

0110 74 65 78 74 2f 70 6c 61 69 6e 3b 0d 0a 09 63
68 text/plain;...ch
0120 61 72 73 65 74 3d 22 69 73 6f 2d 38 38 35 39
2d arset="iso-8859-

0130 31 22 0d 0a 43 6f 6e 74 65 6e 74 2d 54 72 61
6e 1"..Content-Tran

0140 73 66 65 72 2d 45 6e 63 6f 64 69 6e 67 3a 20
37 sfer-Encoding: 7

0150 62 69 74 0d 0a 58 2d 50 72 69 6f 72 69 74 79
3a bit..X-Priority:

Table 3: Captured Data under the Open-system Wireless Network in Yager

Hall Library. POP3 Email Content.

Table 3: Captured Data under the Open-system Wireless Network in Yager

Hall Library. POP3 Email Content (continued).

0160 20 33 20 28 4e 6f 72 6d 61 6c 29 0d 0a 58 2d
4d 3 (Normal)..X-M

0170 53 4d 61 69 6c 2d 50 72 69 6f 72 69 74 79 3a
20 SMail-Priority:

0180 4e 6f 72 6d 61 6c 0d 0a 58 2d 4d 61 69 6c 65
72 Normal..X-Mailer

0190 3a 20 4d 69 63 72 6f 73 6f 66 74 20 4f 75 74
6c : Microsoft Outl

01a0 6f 6f 6b 20 49 4d 4f 2c 20 42 75 69 6c 64 20
39 ook IMO, Build 9

01b0 2e 30 2e 36 36 30 34 20 28 39 2e 30 2e 32 39
31 .0.6604 (9.0.291

01c0 31 2e 30 29 0d 0a 49 6d 70 6f 72 74 61 6e 63
65 1.0)..Importance

01d0 3a 20 4e 6f 72 6d 61 6c 0d 0a 58 2d 4d 69 6d
65 : Normal..X-Mime
01e0 4f 4c 45 3a 20 50 72 6f 64 75 63 65 64 20 42
79 OLE: Produced By

01f0 20 4d 69 63 72 6f 73 6f 66 74 20 4d 69 6d 65
4f Microsoft MimeO

0200 4c 45 20 56 36 2e 30 30 2e 32 38 30 30 2e 31
34 LE V6.00.2800.14

0210 34 31 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61
20 41....This is a

0220 73 65 63 72 65 74 20 6d 65 73 73 61 67 65 20
74 secret message t

0230 65 78 74 20 68 65 72 65
2e ext here.

Attacks to Open-System:

Attacks to Open-System:
The Webmail also sends message in
plain text both in send and receive
mode.
I used Webmail to send a short email to
myself. As we can see in the following
captured data, the message is “This is a
top sceret message here.” The detailed
packet information and interpretation
enclosed in the Appendix in my paper.
0000 00 02 b3 d0 cb 42 00 0d 88 58 ce 88 08 00 45
00 .....B...X....E.

0010 01 d9 0a ad 40 00 80 06 0c 7f 93 cd 64 87 93
cd ....@.......d...

0020 55 d1 0c 45 00 50 34 2f 89 33 d6 af 26 ae 50
18 U..E.P4/.3..&.P.

0030 41 1c bf 5f 00 00 43 6d 64 3d 73 65 6e 64 0a
4d A.._..Cmd=send.M

0040 73 67 54 6f 3d 6c 69 61 6f 71 40 68 61 72 74
77 sgTo=liaoq@hartw

0050 69 63 6b 2e 65 64 75 0a 4d 73 67 43 63 3d 0a
4d ick.edu.MsgCc=.M

Table 4: Captured Data under the Open-system Wireless Network in Yager

Hall Library. Webmail Message Content Sent

Attacks to Open-System:
Table 4: Captured Data under the Open-system Wireless Network in Yager
Hall Library. Webmail Message Content Sent (continued).

0060 73 67 42 63 63 3d 0a 75 72 6e 3a 73 63 68 65
6d sgBcc=.urn:schem

0070 61 73 3a 68 74 74 70 6d 61 69 6c 3a 69 6d 70
6f as:httpmail:impo

0080 72 74 61 6e 63 65 3d 31 0a 68 74 74 70 3a 2f
2f rtance=1.http://

0090 73 63 68 65 6d 61 73 2e 6d 69 63 72 6f 73 6f
66 schemas.microsof

00a0 74 2e 63 6f 6d 2f 65 78 63 68 61 6e 67 65 2f
73 t.com/exchange/s
00b0 65 6e 73 69 74 69 76 69 74 79 2d 6c 6f 6e 67
3d ensitivity-long=

00c0 0a 75 72 6e 3a 73 63 68 65 6d 61 73 3a 68 74
74 .urn:schemas:htt

00d0 70 6d 61 69 6c 3a 73 75 62 6a 65 63 74 3d 73
65 pmail:subject=se

00e0 63 72 65 74 20 6d 65 73 73 61 67 65 0a 75 72
6e cret message.urn

00f0 3a 73 63 68 65 6d 61 73 3a 68 74 74 70 6d 61
69 :schemas:httpmai

0100 6c 3a 68 74 6d 6c 64 65 73 63 72 69 70 74 69
6f l:htmldescriptio

0110 6e 3d 3c 21 44 4f 43 54 59 50 45 20 48 54 4d
4c n=<!DOCTYPE HTML

0120 20 50 55 42 4c 49 43 20 22 2d 2f 2f 57 33 43
2f PUBLIC "-//W3C/

0130 2f 44 54 44 20 48 54 4d 4c 20 34 2e 30 20 54
72 /DTD HTML 4.0 Tr

0140 61 6e 73 69 74 69 6f 6e 61 6c 2f 2f 45 4e 22
3e ansitional//EN">

0150 3c 48 54 4d 4c 3e 3c 48 45 41 44 3e 3c 4d 45
54 <HTML><HEAD><MET

0160 41 20 48 54 54 50 2d 45 51 55 49 56 3d 22 43
6f A HTTP-EQUIV="Co

0170 6e 74 65 6e 74 2d 54 79 70 65 22 20 43 4f 4e
54 ntent-Type" CONT

0180 45 4e 54 3d 22 74 65 78 74 2f 68 74 6d 6c 3b
20 ENT="text/html;
0190 63 68 61 72 73 65 74 3d 75 74 66 2d 38 22 3e
3c charset=utf-8"><

01a0 2f 48 45 41 44 3e 3c 42 4f 44 59 3e 3c 44 49
56 /HEAD><BODY><DIV

01b0 3e 54 68 69 73 20 69 73 20 61 20 74 6f 70 20
73 >This is a top s

01c0 63 65 72 65 74 20 6d 65 73 73 61 67 65 20 68
65 ceret message he

01d0 72 65 2e 3c 2f 44 49 56 3e 3c 2f 42 4f 44 59
3e re.</DIV></BODY>

01e0 3c 2f 48 54 4d 4c
3e </HTML>

Attacks to WEP
The basic network model that I used
consists of one WEP encrypted AP, one
laptop PC with Orinoco Silver Wireless
Card running Windows XP Professional
(used to intercept the wireless
communication data), and one laptop
PC with Orinoco Silver Wireless Card
running Red Hat Linux Fedora Core 3
(used to send and receive data).
Architecture at CISC clubhouse:
 There are two open-system APs of SSID of
Johnstone.
There is one WEP encrypted AP, running on
channel 6,located at Professor Lichtman’s office.
D-Link AirPremier DWL-2200AP 802.11g
Wireless 108Mbps Access Point with PoE.
Figure 6: Basic AP Information Obtained Through NetStumbler.

Attacks to WEP
A user needs a secret WEP key in order to
be connected to the CISC wireless network.
Figure 8: Connecting to the WEP Protected Wireless Network by Providing the
Shared Key.

Architecture at CISC clubhouse:

Capturing a WEP encrypted raw
packets is not easy.
There are basically three modes for
certain Network Interface Card (NIC):
Normal Mode
Promiscuous Mode
 Monitor Mode.
right chip + right driver = monitor mode
The two wireless cards that I used are
Orinoco PC Card Silver (5 volt) with blue
color, and Orinoco PC Card T2
Extended H1T2R1 Proxim World WEP
Kit Silver with purple color. (Show cards)
I checked out those cards from the
circulation desk in library, so they are
the cards that Hartwick students are
using.
Patches and Drivers for Orinoco cards
(Linux)
WaveLAN Station firmware Update
utility (WSU) version 606, 616, 728, 752,
810 by Lucent Technologies
Agere Systems v7.82 NDIS 5.x Miniport
Driver (Windows)
 Architecture at CISC clubhouse:
I used AirSnort v0.2.7c to capture WEP
raw packets.
demo version of AiroPeek(peek5.sys
and peek.dll) + AirSnort ==>capture in
monitor mode
How to view the contents of the
captured raw WEP packets?
AirSnort+Ethereal=0,
Ethereal+AirSnort=Blue Screen, modify
Ethereal source code=complicated, log
to file + Etheral=yes!
Figure 11: Using AirSnort to Capture the WEP Encrypted Packets with the
Wireless Card Set in Monitor Mode.

RC4 Encryption Algorithm and WEP

protocol
The RC4 encryption algorithm was
developed in 1987 by Ron Rivest, for
RSA Data Security.
was a propriety algorithm until 1994.
“RC” stands for “Ron’s Code” or “Rivest
Cipher.”
RSA claims that the algorithm is
immune to differential and linear
cryptanalysis.
RC4 actually consists of two parts:
the Key Scheduling Algorithm (KSA)
and
the Pseudo Random Generation
Algorithm (PRGA).
The RC4 algorithm generates a
keystream—i.e., a long sequence of
pseudorandom bytes—as a function of
the initialization vector (iv) and secret
WEP key (k)
keystream = RC4 (iv,k)
 RC4 Encryption Algorithm and WEP
protocol
Plaintext is the concatenation of
message and checksum.
P = (M,CRC32(M))
where M stands for the message, and
CRC32(M) is the Cyclic Redundancy
Checksum on M.
RC4 encryption algorithm uses
exclusive-OR (XOR)
XOR = (a ⋁ b) ⋀ ¬ (a ⋀ b).
0

XOR
1

We encrypt the plaintext by simply

XORing or adding modulo 2 the
keystream to the plaintext.
Encryption: C = P⊕keystream

RC4 Encryption Algorithm and WEP

protocol
Figure 12: Encrypted WEP frame.

To decrypt a frame protected by WEP, reverses the

encryption process.
Regenerates the keystream RC4(iv,k) and XORs it against
the ciphertext to recover the initial plaintext.

Decryption: P’ = C⊕keystream

= (P⊕keystream)⊕keystream

=P
decrypted plaintext P’ = (M’, c’). Verifies the checksum:

c(M’)?=c’

RC4 Encryption Algorithm and WEP

protocol
Figure 13: The WEP Encryption and Decryption using the RC4 Algorithm.

IV Collision Attack
The WEP standard recommends that the IV be
changed after every packet.
This way, each packet receives a different keystream.
However, it does not say anything else about how to
select IV’s, and each individual vendor does things
differently.
random vs constant
As through my observation, both my Orinoco PC Card
Silver (5 volt) by Lucent Technology, increments the
IV by one for each packet it transmits.

I unplugged and re-inserted the card

into the laptop each time I need it to re-
initialize the card.
Blue color:
For three sessions of capturing, I got packets
with IV ranging from 0x78df14--0x7ddf14,
0xc4d16a--0xcbd16a, 0xcffb78--d7fb78
My conjecture: it somehow stores a seed in the
firmware, so each time it initializes, it will start at
a different random number.
Purple color:
Resets the IV to a low number (although I was
never able to get a “0”) each time it was re-
initialized.
For five test sessions of capturing, I got packets
with such IV as 0x2e0000--0x310000, 0x130000-
-0x210000, 0x250000--0x2b0000, 0x050000--
0x120000, and 0x270000-- 0x2c0000.

IV Collision Attack
I will address my Brute-force attack later. But my first
approach is to explore the vulnerability of WEP
regardless of keysize.
No matter the 64-bit or 128-bit key, the IV field used
by WEP is only 24 bits wide, nearly guaranteeing that
the same IV will reused for multiple messages.
Statistically, an IV collision occurs for every 5000
packets with a random IV implementation.
I measured that the AP at CISC department send and
receive about 1000 packets each minute.
That means for every five minutes, there is an IV
collision.
When two packets assigned with two identical IV, or
an IV collision, happens, RC4(iv,k) will produce the
same keystream for the two packets since the secret
WEP key do not change. We can see an interesting
property here:

If C1 = P1⊕keystream

and C2 = P2⊕keystream

then C1⊕C2 = (P1⊕keystream)⊕(P2⊕keystream) =

P1⊕P2

In other words, XORing the two ciphertexts (C1 and

C2) together causes the keystream to cancel out, and
the result is the XOR of the two plaintexts (P1⊕P2).

IV Collision Attack
0000 08 41 d5 00 00 0f 3d fa 97 93 00 02 2d 29 26
25 .A....=.....-)&%

0010 00 02 b3 d0 cb 42 30 02 16 00 00 00 aa 17 65
a3 .....B0.......e.
0020 ba fe bd 42 68 60 2d 76 2e fb b3 3d 87 a5 39
10 ...Bh`-v...=..9.

0030 2f c5 6d 18 d8 c8 7e 7a 23 6e ce 7f 28 37 01
c5 /.m...~z#n..(7..

0040 4c 4c 80 0f f9 86 b3 7e 63 06 b1 9b d9 eb 59
42 LL.....~c.....YB

0050 50 93 5f ce d9 9a d4 45 da 87 0c 5f 38 90 f6
d1 P._....E..._8...

0060 8f 8d 30
c7 ..0.

Table 6: Captured Data of the First Packet with the

IV 0x160000.

0000 08 41 d5 00 00 0f 3d fa 97 93 00 02 2d 29 26
25 .A....=.....-)&%

0010 00 04 23 0d 6e 7c f0 01 16 00 00 00 aa 17 65
a3 ..#.n|........e.

0020 ba fe bd 42 68 a0 2d 20 20 ea f3 3d 38 a2 a7
05 ...Bh.- ..=8...

0030 2f c5 6d 18 d8 c8 7e 4b a0 74 01 24 80 d6 3b
e8 /.m...~K.t.$..;.

0040 09 4c 80 41 28 f3 a5 ae 5b 22 46 a8 48 22 09
17 .L.A(...["F.H"..

0050 c7 5c 03 bc d9 49 97 f9 da bd 58 dc a0 24 f5
d3 .\...I....X..$..

0060 d0 ef 29 79 6f ca 9c 48 1e 42 5e 8a 4a df a6
af ..)yo..H.B^.J...

0070 98 b8 c0 b4 dd 46 8b 55 f7 72 83 e7 f5 8e 5e
f8 .....F.U.r....^.
0080 cf e6 9c df 8a 04 8d 1e 3b ee 19 a9 1d fd 46
89 ........;.....F.

0090 60
5e `^

Table 7: Captured Data of the Second Packet with the IV 0x160000.

IV Collision Attack
I wrote a small program in Java to perform the XOR
operations on captured data.
Show my program.

00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000

00000000 11000000 00000000 01010110 00001110 00010001

01000000 00000000

10111111 00000111 10011110 00010101 00000000 00000000

00000000 00000000

00000000 00000000 00000000 00110001 10000011 00011010

11001111 01011011

10101000 11100001 00111010 00101101 01000101 00000000

00000000 01001110

11010001 01110101 00010110 11010000 00111000 00100100

11110111 00110011

10010001 11001001 01010000 01010101 10010111 11001111

01011100 01110010

00000000 11010011 01000011 10111100 00000000 00111010

01010100 10000011
10011000 10110100 00000011 00000010 11010000 11101111
00101001 01111001

01101111 11001010 10011100 01001000 00011110 01000010

01011110 10001010

01001010 11011111 10100110 10101111 10011000 10111000

11000000 10110100

11011101 01000110 10001011 01010101 11110111 01110010

10000011 11100111

11110101 10001110 01011110 11111000 11001111 11100110

10011100 11011111

10001010 00000100 10001101 00011110 00111011 11101110

00011001 10101001

00011101 11111101

Table 8: the Bitwise XOR Results of Two Binary Data

Captured with the IV Collision.

Note that the 0 bits mean the contents

of the two plain texts are all the
same.

IV Collision Attack
One may make an educative guess of
some components of the packet, such
as some fields of IP traffic, since
protocols usually have common
structures.
If the bit of C1⊕C2 is 1, then the bits in
P1 and P2 have to be of different parity,
namely one “0” and one “1”.
If the bit of C1⊕C2 is 0, then the bits in
P1 and P2 have to be the same.
Some linear ciphers can be solved by
analyzing frequency of English letters.
The first seven most frequently used
letters are E, T, N, R, I, O, and A, so
some probability approaches may work.
If we have n ciphertexts that all reuse
the same keystream, as n increases, it
gets easier to guess the contents.

Keystream Recovery Approach

One logic extension of the IV collision attack is that if
we capture two packets with the same IV and we
know the content of one of them, we can recover the
pseudo random keystream used to encrypt the
packet.
Recall that Encryption: C = P⊕keystream. We can
easily recover the keystream by XORing the cipher
text and plain text, that is:

keystream = C⊕P

If I send traffic from the outside to a host inside the

wireless network, since the contents of such traffic are
created by me, I know exactly what I send, yielding
known plaintexts.
Imagine such a scenario that I send emails to
legitimate users (professors or students) on the
Hartwick network and wait for them to check it over a
wireless link. Sending spam email might be a good
method of doing this without raising too many alarms.
In my test environment:
I used the Linux machine to send emails and did
some web browsing while running Ethereal to
record the original data coming and leaving that
machine.
On my Windows XP machine, I set up my
wireless card in monitor mode and used AirSnort
to capture the encrypted version of all those
communication by logging to a binary file.

Keystream Recovery Approach

0000 01 00 0c cc cc cc 00 30 c1 63 36 f2 00 84 aa
aa .......0.c6.....

0010 03 00 00 0c 20 00 01 b4 42 73 00 01 00 20 4d
49 .... ...Bs... MI

0020 4c 53 57 30 2e 35 35 2e 32 33 34 28 30 30 33
30 LSW0.55.234(0030

0030 63 31 2d 36 33 33 36 38 30 29 00 02 00 11 00
00 c1-633680)......

0040 00 01 01 01 cc 00 04 93 cd 37 ea 00 03 00 06
42 .........7.....B

0050 36 00 04 00 08 00 00 00 08 00 05 00 2d 52 65
76 6...........-Rev

0060 69 73 69 6f 6e 20 43 2e 30 39 2e 32 32 20 2f
73 ision C.09.22 /s

0070 77 2f 63 6f 64 65 2f 62 75 69 6c 64 2f 76 67
72 w/code/build/vgr

0080 6f 28 63
30 o(c0

0000 08 42 00 00 01 00 0c cc cc cc 00 0f 3d fa 97
93 .B..........=...

0010 00 30 c1 63 36 f2 10 eb f4 26 09 00 d7 4e f6
51 .0.c6....&...N.Q

0020 00 a5 b8 94 3f 54 2f d8 5f 09 c2 0f 74 02 da
c3 ....?T/._...t...

0030 e0 41 24 b3 2b 3d c7 7b 21 a4 64 a5 bb 7c 70
ea .A$.+=.{!.d..|p.

0040 0f 84 fd 53 79 89 9c 02 24 c2 80 8a 20 97 f9
e2 ...Sy...$... ...
0050 b6 a7 a8 f5 b1 f9 af 9d 97 dc 61 f2 63 56 66
3d ..........a.cVf=

0060 00 b2 53 2e f7 8a 89 9d 08 e7 e3 6a 0b 3b 0f
60 ..S........j.;.`

0070 78 c2 c5 9f 91 5b 53 8e 5a 24 e9 9c a2 45 ad
b0 x....[S.Z$...E..

0080 bf f9 e5 ea d6 00 02 17 db bc 6e b2 bb ec 7e
f9 ..........n...~.

0090 72 6f 79 43 9b c4 fc 86 f4 9b 7a 2b c7 af 14
14 royC......z+....

00a0 c7 1e 0c
3b ...;

Table 9: Original data with IV f4 26 09.

Table 10: WEP Encrypted Version of the Same Packet

with IV f4 26 09.

Keystream Recovery Approach

Using the same Java program that I developed to
XOR the two cipher texts, I recovered the value of the
keystream for this specific value of IV 0xf42609,
namely keystream = RC4(0xf42609, k), where k is the
secret WEP key.
11010110 01001110 11111010 10011101 11001100 01101001
10111000 10100100

11111110 00110111 00011001 00101010 01011111 10001101

01101000 10100101
01110111 00000010 11011010 11001111 11000000 01000001
00100101 00000111

01101001 01001110 11000111 01111010 00100001 10000100

00101001 11101100

11110111 00101111 00100111 11011010 00100001 10110001

11001000 01111101

01001011 10111010 10101000 00101010 00010100 11110010

10110011 10111010

01000011 10100110 11010100 11010100 10000101 10010100

10011110 11001101

10000001 11010000 10101111 10011111 10010111 11001101

01100001 11110010

01100011 01010111 01100111 00111100 11001100 10110010

01010111 10111101

00111010 10111101 01100011 10011101 00001011 11100111

11100101 00101000

00111101 00111011 00001011 01100000 01110000 11000010

11000101 10011111

10011001 01011011 01010110 10001110 01110111 01110110

10001100 11101010

11001011 00110110 11000100 11011111 11010001 11011001

10100110 11000100

11100110 00111001 00101100 00100101 11101001 10011100

01000001 11000001

11001100 11000011 00011101 10010110 00010110 00001010

01010110 00100001

11101110 10101101 10010000 11100010 11011011 11101101

00011101 01011001

10101000 10000111 01110111 00100100

Table 11: the Keystream Used to Encrypt Message under
the IV f4 26 09.

Keystream Recovery Approach

Note that the keystream is 132 bytes
long. It can be applied to any packet
less than or equal to 132 bytes with the
IV f4 26 09.
I can either XOR it with my arbitrary
data and send it as if I am the legitimate
user, or I can XOR it with any WEP
encrypted packet that I intercept and
decrypt its content, doing all of these
even without knowledge of the WEP
key!
Although we know the keystream = RC4
(iv, k) and we know iv, we do NOT know
k. Having the knowledge of the
keystream and the IV do not necessarily
yield the recovery of the private WEP
key since it is a one-way function.
Over time, I can build a table of the
keystreams corresponding to each IV,
provided that the WEP key remains
unchanged.
The full table has modest space
requirements, perhaps an average
length of 300 bytes of keystream for
each of the 224 possible IV’s, or roughly
(224 * 300) / 230 ≈ 4.69 GB.
I added a method to my program to
save the recovered keystream to the
hard disk.

Keystream Recovery Approach

With a dedicated effort, it is absolutely possible for me
to accumulate enough data to build a full decryption
dictionary or a database.
This approach can decrypt all traffic without even
knowing the secret WEP key.
This attack is effective regardless of key size. The
size of the dictionary depends NOT on the size of the
key, but solely on the size of the IV, which is fixed by
the standard at 24 bits.
Furthermore, for the wireless cards that I used for this
project, it reset the IV to 0 each time they were re-
initialized. For a public environment like the library,
people check out the wireless cards at the circulation
desk, plug them into their laptop and use them for a
relatively short time before leaving. Building a
dictionary for only the first few thousand IV’s will be
quite good enough for me to decrypt most of their
traffic directed towards the access point.
One thing I should mention here is since the RC4
algorithm determines the length of the generated
keystream according to the actual length per packet,
my recovered keystream might be shorter than the
actual ciphertext that I want to decrypt.
I can always send a known plaintext that is as long as
possible. However, there is another way to extend the
known keystream that I recovered. Here are some
pseudo codes for doing this.

Keystream Recovery Approach

Base Case: read in the cipher data with the IV;
read in the plain data with the same IV;
XOR (cipher data, plain data);
 saveResult(iv-keystream.dat); // the
keystream size = n
Inductive Case: create a message(m) of size n-3
instead of n-4;
ICV=CRC32(m); // compute the
checksum(4 bytes)
plain data = append(m, the first 3 bytes of
ICV);
cipher data = XOR (plain data, iv-
keystream.dat);
while (returned AP error) // max
loop=256=1 byte
{
cipher data = append(cipher data,
cipherByte);
send cipher data to AP;
}

// cipherByte⊕keyByte=ICV byte

keyByte=XOR(cipherByte, last byte of ICV);

// recovered the n+1 byte for the
keystream of size n
return keyByte;
 Brute-Force Attack
Brute forcing has been a panacea for breaking all
encryption of a moderate key length.
This mode of attack generally only requires two
packets.
Work well on a 64-bit system. Don’t try it on 128-bit
system, because it will take longer than your great-
great-grandchildren would want to wait.
My old, slow laptop:
HP Omnibook xe4100 running MS Windows XP
Pro v. 2002 SP 2 with Intel Celeron CPU of 1.20
GHz and 240 MB of RAM.
It seems I can get approximately 20,000
passphrases checked per second on my laptop
computer.
I needed to read passwords from a ASCII dictionary.
Doing I/O is expensive.
I used Java, which runs on a virtual machine, is
considered much slower than complied C codes.
What if we use a newer, faster computer, use
complied C, and test every combination of binary bits
instead of reading from a file?
Suppose we can test 10,000,000 keys per seconds, a
quick calculation shows 2104-1 / 10,000,000 ≈ 1024
seconds ≈ 32,157,549 billion years!
Normally, key sizes of greater than 80-bits, for robust
designs and implementations, make brute-fore
cryptanalysis an impossible task, since doing so
exceeds contemporary computing power.

Brute-Force Attack
Here is my algorithm for a dictionary-
based brute-force attack:
Read in 3 WEP encrypted packets (IV,
Mc+ICVc);
Loop:
Read in passphrasei from a
dictionary file;
ki=MD5(passphrasei); // or no hashing
function applied at all.

keystreami=RC4(IV, ki);
Mp’+ICVp’=(Mc+ICVc)⊕keystreami; //
try to decrypt
 if (CRC32(Mp’)=ICVp’
try the 2nd & 3rd packet and
do the same thing to see if they
match;
if match, return ki;
else move to next passphrase
and repeat above procedure.
else
repeat above procedure.

Brute-Force Attack
My algorithm involves some important
functions such as RC4, MD5, CRC32,
etc.
However, Java does not provide source
codes in c:\java\src.zip, but native
methods for RC4 algorithm
Tried many times, but got
java.security.InvalidAlgorithmParameter
Exception: ARCFOUR key generation
does not take any parameters
I concluded that it was not implemented
in Java API to specify a secret key with
the RC4 algorithm but we have to use
the default random key instead.
Finally, I decided to write my own RC4
class in Java. I used the algorithm
described in the famous paper
“Weakness in the Key Scheduling
Algorithm of RC4” written by Fluhrer,
Mantin, and Shamir.
The basic algorithm of RC4 is showed
below.

Brute-Force Attack
Pseudo Random Generation Algorithm
(PRGA)
Initialization:
i=0
j=0
Generation loop:
i=i+1
j=j+S[i]
swap(S[i],S[j])
Output z=S[S[i]+S[j]]
Key Scheduling Algorithm (KSA)
Initialization:
For i=0…N-1
S[i]=i
j=0
Scrambling:
For i=0…N-1
 j=j+S[i]+K[i mod l]
swap(S[i],S[j])
Table 12: KSA & PRGA Algorithms of RC4

Show my RC4 class.

Brute-Force Attack
Ok, we got RC4 done. What’s next?
MD5, also developed by Professor
Rivest of MIT, takes as input a message
of arbitrary length and produces as
output a 128-bit message digest of the
input.
Java supports MD5 natively.
MD5 is widely used on APs to generate
keys from a passphrase for 128 bits
keys. However, I could not make it work
with my program, as I could not specify
a size of 64 but only 128 in Java API.
After many tests, I found out the AP at
CISCClub, using 64-bit instead of 128-
bit key, does not apply MD5 but instead
directly uses the ASCII value of the
plaintext key of a length of five letters,
thus a 40-bit key. This made things even
easier.
CRC-32 calculates a checksum. The
“CRC” is acronym for “Cyclic
Redundancy Code” and “32” represents
the length of checksum in bits: 32 bits=4
bytes. This algorithm is based on the
polynomial division. The idea is to take
the data as a very long binary number
and divide it by a constant divisor. The
remainder is the CRC checksum.
Java also supports CRC32 natively.

Brute-Force Attack
If the key checks out, I should also
check it with another packet to make
sure the key is actually valid, since it is
possible that the packet can be
decrypted with an invalid key and the
checksum could still be valid.
CRC was designed primarily for
catching transmission errors not for
integrity protection purposes like MD5
and SHA-1 was designed for.
The probability that two messages will
produce exactly the same hash code
under CRC32 is 1/232. Since MD5 in
Java uses 128 bits, the probability is
further decreased to 1/2128, and for
SHA-1 about 1 in 2160. Therefore, by
testing three packets in my program, I
am extremely positive that the
recovered key is the right key since

where n is the number of packets.

Qi, show your Dictionary-based Brute-
force Attack source code and results.
 Countermeasure
The computing power has been increased
tremendously.
Although it is not outdated yet, RC4 is getting old. It is
therefore very likely that RC4 will not be a sufficient
encryption in the near future.
Some Network Administration Strategy:
Use strong passphrase. Use MAC Access
Control Lists (ACL). Change default SSID and
disable the broadcast SSID. Use Intrusion
Detection System (IDS). Not a fundamental
improvement to the algorithm and protocol.
Use WEP:
This sounds ridiculous, but the fact is that bad
security is generally better than no security at all.
Use SSH:
Assume that the current link layer offers no
security. Use higher-level security mechanisms.
Use VPN:
place the wireless network outside the college
firewall.
Use Remote Authentication Dial-In User Service
(RADIUS):
Increase key size:
>=128 bits
When I say key size, I not only mean the size of
cryptographic keys, but also the size of IVs. I
have shown in my paper that the IV collision
leads to the keystream reuse, significantly
impairing the security of WEP. 24-bit IVs are
definitely too short.

Countermeasure
Disable Weak Keys:
RC4 has a weak key schedule.
The probabilistic correlation between some bits of
the shared WEP key and some bits of the output
keystream (for a large class of weak keys) is one
of prime vulnerabilities of the RC4
implementation in WEP.
The firmware for the old 802.11b based wireless
cards can be modified (newer hardware now has
built-in feature) so that, the weak IVs are skipped
and no longer sent out as part of a WEP
encrypted packet.
Dropping the initial bytes from the RC4 output:
An alternative to disabling weak keys is to drop
some initial bytes, say 128 bytes, of the RC4
stream cipher.
Modifying the CRC algorithm:
Make it non-linear.
Dynamic key management techniques:
Cryptographic keys should be updated
automatically and changed frequently.
Use temporal keys.
Periodical change of keys:
Changing WEP keys will result in reconfiguring
AP and client machines.
How to change encryption key for EVERY
packet?!
Instead of doing keystream = RC4 (iv, key), we
can do keystream = RC4 (iv, MD5 (iv, key)).
Hashing the concatenation of the per-packet IV
and the secret WEP key before feeding it to a
RC4 stream generator would prevent the IV from
revealing any useful information about the shared
WEP key.
 Future Works and Trends
If I would have more time to spend on this one-
semester project, I would very much want to do more
work in the following fields.
Probabilistic Attack based on the Weakness in the
Key Scheduling Algorithm of RC4:
The basic idea is that the PRGA uses the state
array to create a pseudorandom sequence and
the first byte of output is given by S[ S[1] + S[
S[1] ] ], where S is the state array.
After the key setup phase, the first byte of output
depends on only 3 values of the state array: S[1],
S[S[1]], and S[ S[1] + S[ S[1] ] ].
There is a strong probabilistic correlation
between some bits of the WEP key and some
bits of the output keystream for a large class of
weak keys, which are of the form <i+3, 255, X>,
where i corresponds to the current WEP key byte
key[i], and the value of X is unrestricted.
If I had had enough time, I might have
implemented this attack in the Java program.
Distributed Brute-force Attack:
My Java program works well with a key length of
64 bits. But as the key bits increase, the time of a
Brute-force attack increases exponentially.
 It would be nice if I could have programmed
concurrently, testing a group of keys on each
Java Virtual Machine in a distributed computing
environment. The communication, cooperation
and security problem need to be considered.
Vulnerability of WPA and AES Encryption Algorithm:
RC4 and WEP are getting old. More advanced
algorithm and protocol are going to be deployed.
It would be very exciting and challenging to find
the vulnerability of these more advanced
encryption methods.

Future Works and Trends

Trends:
Shift from WEP to Wi-Fi Protected
Access (WPA):
Short-term solution.
Use Temporal Key Integrity Protocol (TKIP) to
change the key every 10,000 packets.
The basic idea is to keep current infrastructure
unchanged, but increase the key and IV size.
doubles the IV space from 24-bit size to a 48-bit
IV value.
 Uses 12-byte ICV instead of 4-byte in WEP.

Shift from RC4 to Advanced Encryption

Standard (AES):
AES has been adopted by the U.S. government
as the replacement for 3DES as the encryption
standard.
Require much more processing power than RC4,
which means the exiting infrastructures need to
be replaced.

Upgrade from 802.11b/g to 802.11i

(WPA2):
Use the IEEE 802.1X port-based access control
Enables an AP and client stations to mutually
authenticate one another.
Use TKIP and AES ciphers with a 256-bit key
and a “four way” key management handshake.

The End
Thank you!