Wired Equivalent Privacy _WEP_ Functionality_ Weak Points_ Attacks by bestt571


More Info
									                     Wired Equivalent Privacy (WEP)
                    Functionality, Weak Points, Attacks

                                         Alexander Gutjahr

                                 Albert Ludwigs University, Freiburg

       Abstract. This paper describes the WEP (wired equivalent privacy) protocol as defined in
       IEEE 802.11 and its shortcomings. The WEP mechanism is described and systematic prob-
       lems and shortcomings are identified. Common attack vectors are explained and a selection
       of interesting attacks is described and evaluated.

1     Introduction
Wired Equivalent Privacy (WEP) is part of the IEEE 802.11 standard. It was introduced in the
first revision of the document in 1999. WEP was supposed to provide confidentiality for messages
passed between authorized users in IEEE 802.11 compatible networks. Today WEP is not state of
the art anymore. There is a number of commonly known attacks against it and more sophisticated
methods have been introduced to provide security in wireless networks. Never the less WEP is still
in use by a large number of mainly private operated networks. Additionally it is a nice example of
protocol miss-design and its consequences.

In this paper an overview of the WEP mechanism is given. Along with the functional descrip-
tion an explanation of the systematic shortcomings of WEP is given. A general set of possible
attack vectors is introduced and based thereon concretely implemented attacks against WEP are

2     WEP - Wired Equivalent Privacy
2.1   Functional description
In normal IEEE 802.11 communication the transmitted packets are not encrypted. WEP introduces
an encryption on the 2nd ISO/OSI layer, the data-link layer. Due to the layering design-paradigm
no protocols operating on higher or lower layers need to provide compatibility of any kind with
WEP. The additional encryption process is transparent to the upper and lower layers.
WEP is designed to achieve three main security goals:
 – Access control: Only authorized stations can access the network. A station is considered au-
   thorized, as soon as it knows the pre-shared key.
 – Confidentiality: The communication is protected against eavesdropping. The content of a trans-
   mitted message should not be readable by stations that are not part of the network.
 – Message integrity: A message sent over the network can not be altered during the transmission
   without the receiving station noticing the manipulation and subsequently discarding the invalid
The working principle of WEP can be explained by following one complete communication process
consisting of encryption, transmission and decryption.

Sending WEP is using the pre-shared key K to encrypt the payload of frames (message M )
transported between the communication partners A and B. First an integrity checksum c(M )
over the message body is calculated with the CRC32 algorithm. The result of CRC32 is a four
bytes value, such that the following holds: (M ◦ c(M ))modCRCgenerator = CRCremainder , where
CRCgenerator and CRCremainder are known polynomials. The generated checksum is concatenated
2      Alexander Gutjahr

with the message to obtain the plaintext P . (P = M ◦ c(M )) Next a three Bytes initialization
vector (IV ) is chosen. The WEP standard does not specify in which way the IV s should be
picked. The IV is then concatenated to the pre-shared key. The key is either 40 bit or 104 bit long
and in addition to the 24 bit of the IV this results in a total RC4-Key length of 64 bit or 128 bit.
Next the RC4 algorithm is used to generate the key-stream. RC4 is a stream-cypher algorithm,
this means that it generates an infinite sequence of pseudo random bits. Which bit sequence it
generates depends only on the initialization of the algorithm. In this case IV and pre-shared key
are used to initialize it. The obtained pseudo random sequence is XORed with the plaintext P to
obtain the cipher-text C. (C = P ⊕ RC4(key + IV )) The cypher-text and the IV is then handed
down to the physical layer for transmission. This is also illustrated in Fig. 1.

                               Fig. 1. WEP mechanism: encryption [1]

Receiving After a packet has been received and delivered to the data-link layer, the payload
needs to be decrypted. First the IV is extracted from the received data. Then the IV and the
pre-shared key are used to create the same RC4 key-stream, that was used to encrypt the plaintext
P . Next the received cipher-text C is XORed with the generated key-stream. Since the binary
operation XOR is its own inverse function, the result of this operation is the original plaintext
P . It holds that C = P ⊕ RC4(key + IV ) and P = C ⊕ RC4(key + IV ), and hence P = P ⊕
RC4(key + IV ) ⊕ RC4(key + IV ). Since the original plaintext is not known by the receiver,
there is no telling wether the calculated value is the actual plaintext. The decryption process
would also work when different key-streams were used for encryption and decryption. This would
obviously result in different plaintext on the sender- and receiver-side. Therefore the next step is to
check, wether the integrity checksum included in the plaintext is still correct. For that purpose the
property (M ◦ c(M ))modCRCgenerator = CRCremainder is checked again. If it holds, everything
was correct and the decrypted and verified message Msender is handed to the next layer for further
processing. [1]

                               Fig. 2. WEP mechanism: decryption [1]

2.2   RC4

RC4 is a stream cipher originally developed by Ronald L. Rivest for RSA Security in 1987. (thus
the name RC4 = Ron’s Code 4) The algorithm was kept as a trade-secret by RSA until it leaked
                                                                        Wired Equivalent Privacy (WEP)             3

                               Fig. 3. WEP mechanism: encryption and decryption [1]

     in 1994. It takes a key of fixed length as input and it generates a sequence of pseudo random
     numbers as output. The algorithm will always generate the same output sequence for the same
     key. The algorithm consists of two main parts: a key scheduling algorithm (KSA) and a pseudo
     random generator algorithm (PRGA). The KSA takes the secret key as input and generates an
     initial permutation for the symbol generation array S as shown in the code listing 4. For symbols
     of length x there are 2x different symbols in the array. The algorithm works for every x, but in
     the WEP implementation x = 8 is used, resulting in 28 = 256 symbols with 8 bit length each.
     After the initial shuffling the steps described in 5 are executed for every step in the pseudo random
     generation, resulting in a constant re-ordering of the symbols.

1    by te S [N ] ; // symbol g e n e r a t o r array , h e r e N = 2ˆ8 = 256
2    by te K[ L ] ; // k e y o f l e n g t h L
3    int i , j ;
4    f o r ( i =0; i <N; i ++){ // i n i t i a l l i n e a r f i l l i n g
5                 S[ i ] = i ;
6    }
7    f o r ( i =0; i <N; i ++){ // i n i t i a l p e r m u t a t i o n
8                  j = i + S [ i ] + K[ i%L ] % 2 5 6 ;
9                  swap ( S [ i ] , S [ j ] ) ;
10   }

                                        Fig. 4. RC4 key scheduling algorithm

1    by te S [N ] ; // from KSA
2    i n t count = xxx , i =0, j =0; // number o f pseudo random b y t e s needed
3    f o r ( i =1; i<=count ; i++ % 2 5 6 ) {
4                  j = j + S [ i ] % 256;
5                  swap ( S [ i ] , S [ j ] ) ;
6                  p r i n t f ( ”%d” , S [ S [ i ]+S [ j ] ] % 2 5 6 ) ; // pseudo random b y t e f o r t h i s round
7    }

                                        Fig. 5. RC4 random symbol generator

         The quality of stream ciphers is measured by their cycle length. The cycle length is the length
     of the key-stream before a repetition of a sequence occurs. Generally RC4 scores quite good. It
4       Alexander Gutjahr

is very likely to generate a sequence with a cycle length of 10100 or longer. Also, in an efficient
implementation it only takes eight to sixteen machine instructions to generate one symbol. [2]
However, RC4 has special characteristics that need to be kept in mind when implementing or
using it. Most of the cryptographic attacks on WEP rely on the failure of the protocol design
to take care of these characteristics properly. The individual weak-points and problems will be
explained as needed in the following chapters. [3]

2.3   Systematic shortcomings and problems
In the previous chapter the design and working principal of WEP was introduced without reflection
on security aspects of the protocol. WEP has several design flaws that can be exploited in order
to attack the security goals of the protocol. The most interesting problems are described here:

Master key is used directly In WEP the master key is used directly to feed the RC4 cipher
in the encryption and decryption process. This means that once the key for one transmission is
recovered, all transmissions are compromised. Usually it is a better idea to use the master key to
generate temporary session keys for the individual transmissions or for a certain time period. That
way the loss of one generated key does not compromise the other keys or the master key.

Key size The original WEP specification uses a 64 bit generator key for the RC4 algorithm. These
64 bit are split up into a 40 bit pre-shared key and the 24 bit initialization vectors (IVs). Generally
this splitting is a good idea. The pre-shared key part provides protection agains unauthorizes
communication partners, while the IV part that changes with each packet protects against key-
stream re-use. Unfortunately the key size was chosen too short. Although 40 bit must have seemed
reasonable in 1997, a key of this length does not offer enough permutations to protect against brute
force attacks with modern hardware. Vendors of wifi equipment extended the key length to 104 bit
later, resulting in a total of 128 bit with IV, but that does solve the more general problems of the

Key management The WEP standard does not specify any key management procedure. That
means there is no standardized way to generate or distribute keys among wifi devices. Hence
keys have to be chosen and distributed by hand. This does not have any direct impact on the
cryptographic security of the protocol, but it leads to the use of simpler keys, that also stay in use
for extensive periods of time. This considerably increases the impact of a successful attack on the

Use of RC4 The way WEP uses RC4results in the existence of weak keys. This means that there
is more correlation between the key (pre-shared key + IV) and the resulting key-stream than there
should be. Since with the IV 3 bytes of the key are transmitted in plaintext it is easy to identify
packets that were encoded with a weak key. Out of the 224 IVs available, about 9000 are considered
weak. An attacker can just listen in on the traffic and wait for packets with weak IVs. Then, thanks
to the bigger correlation, just a small fraction of the possible key space must be checked to find
the key. At the beginning of every WEP packet there is a SNAP-header. This header always starts
with the same bytes, thus making the beginning of every cipher-text known to the attacker. With
that information the success of the key guessing process can be checked quite easily.

Short IVs WEP uses IVs of 24 bit length. This means for a single pre-shared key there can be
224 or 16 million different RC4 key-streams. A 54MBit wifi network with a cannel utilization of
25% and an average packet length of 1000 byte can transmit about 1700 packets/second. This
means that the 16 million packets can be reached in as little as 2,75 hours, making key-stream
reuse inevitable. Unfortunately this scenario has to be considered a best case, since WEP does not
specify a way to choose the next IV. Some devices start with the IV 0 and increment with each
packet sent, some others choose the IV randomly from the possible values. Although the random
method looks better at first glance, after as little as 5000 packets the chance to pick a previously
used IV rises to 50%. Key-stream reuse is a serious threat, because an attacker has much time to
calculate the key-stream between the packets. Then he can decrypt the second packet on the fly.
                                                             Wired Equivalent Privacy (WEP)         5

Integrity check algorithm WEP uses CRC32 as integrity check algorithm. While CRC32 is
widely and successfully used to detect bit-errors in data transmissions, is is not a good choice for a
cryptographic hashing algorithm. CRC32 is a linear function of the message text, that means that
a potential attacker could manipulate the encrypted payload of a packet and fix the CRC32 value
to make it aper valid, without knowledge of the key. This mechanism is independent of the used
encryption method and the key length. Although this weakness can not be used to recover the key
or decrypt packets, the integrity of sent messages can easily be violated.

Authentication mechanism When using IEEE 802.11 with WEP, there are two possible meth-
ods to authenticate new clients. The first is the open system authentication. As the name indicates,
this basically authenticates every station that asks for it. The authentication process is not en-
crypted, even if WEP is configured. The second method is the shared key authentication, which
implements simple challenge response protocol. This can easily be broken, as discuss in chapter
3.2. [4]

3     Attacks on WEP
3.1   Attack types
The many known attacks agains WEP can be categorized into different groups according to their
 – Fake Authentication attacks allow the attacker to associate illegitimate clients with a network.
   This is a requirement for all active attack types.
 – Message Modification takes place, when an attacker modifies a message during its transmission
   without the other stations knowing.
 – Message Decryption allows the attacker to obtain the plaintext corresponding to the cipher-
   texts of messages intercepted in the network.
 – Message Injection allows the attacker to actively generate new valid messages and send them
   to stations associated with the network.
 – Key Recovery is the process of obtaining the pre-shared WEP key. This is the most interesting
   attack type, because successfully executed it allows the attacker full access to the network. [5]

3.2   Fake authentication
Fake authentication attacks allow an attacker to authenticate himself with a network, even though
he does not know the pre-shares key. There are methods to execute this attack type for both
authentication methods available in IEEE 802.11:

Open System Authentication When open system authentication is used, every client can
associate itself with the network by simply sending an unencrypted authentication request to the
access-point. This is not an attack for that matter, as the client just uses the protocol as it was

Shared Key Authentication To circumvent the shared key authentication, a more sophisti-
cated approach is necessary. In the authentication process the access-point sends an unencrypted
challenge to the new client. The client has to encrypt the challenge with the pre-shared key and
send it back to the access-point. If the response was correct, the new client is granted access to
the network. This seams reasonable, unless the attacker has obtained a partial key-stream and
the corresponding IV. This can be achieved by executing the chopchop-attack (chapter ??) or by
simply listening in on a successful authentication process. After the observed successful authenti-
cation of one client, the attacker knows the challenge-text P , the IV and the encrypted challenge
C. Since C = P ⊕ key − stream, the key-stream can be obtained by keystream = C ⊕ P . Now
the attacker can ask the access-point for a challenge P2 of its own and XOR it with the key-
stream to obtain a correctly encrypted cypher-text C2 = P2 ⊕ keystream. Now C2 needs to be
prepended with the IV and sent to the access-point to complete the authentication. Once obtained,
the pairing of key-stream and IV can even be used to forge and inject arbitrary packets after the
authentication. [4]
6      Alexander Gutjahr

3.3   Message Modification

A message modification attack allows an attacker to modify a message while it is in transmission.
With WEP, this can easily be achieved, even without knowledge of the pre-shared key or the key-
stream for this packet. First the message to modify must be intercepted. That means the attacker
receives the message, but prevents the designated receiver from receiving it. Then he can exploit
the properties of CRC32. The value of the CRC32 checksum is a linear function of the message
payload. Lets assume, that the CRC32 function is denoted by crc(). The linearity of the function
leads to this property:
                                   crc(a ⊕ b) = crc(a) ⊕ crc(b)
Recall that the cipher-text C of a message M is generated by C = RC4(IV, K) ⊕ {M ◦ crc(M )}.
Now assume the attacker wants to modify the message by XORing an offset O to it, with |O| = |M |.

                                     Cnew = C ⊕ {O ◦ crc(O)}

Replacing C in the formula with its definition from above leads to:

                       Cnew = RC4(IV, K) ⊕ {M ◦ crc(M )} ⊕ {O ◦ crc(O)}

After re-ordering the XOR operations with the CRC32 property from above we get:

                       Cnew = RC4(IV, K) ⊕ {M ⊕ O ◦ crc(M ) ⊕ crc(O)}

Considering this it becomes obvious, that Cnew remains the same, wether the offset O is XORed
before or after the encryption process. To execute this attack in a controlled manner, the attacker
needs to know the internal structure of the packets, since he can not read the encrypted cipher-text.
Fortunately parts of the internal structure of the message are known, since it uses protocol with
defined headers.

3.4   Message Decryption: the chopchop attack

The chopchop attack was proposed by a user with the pseudonym KoreK on the netstumbler.org-
forum in 2004. It allows the decryption of an intercepted message without knowledge of the pre-
shared key. The attacker simply lets the access-point decrypt the packet for him. This works,
because IEEE 802.11 requires different reactions from the access-point for correct and incorrect
packets and because of some special properties of the CRC32 algorithm. If an access-point receives
a packet with a correct CRC32 checksum from a client that is not authenticated, it generates an
error-message to inform the user that his correct packet will be discarded. If the checksum is not
correct, the access-point will silently discard the package.
Recall that as shown in chapter 3.3 it does not matter wether CRC32 operations are executed be-
fore or after the encryption of the packet. Assume the attacker has obtained the message-payload of
a WEP encrypted packet C. C consists of the message-text M and the CRC32 checksum crc(M ),
hence C = M ◦ crc(M ). The CRC32 is checked, by dividing C with the CRC32 generator polyno-
mial, with an expected remainder. CmodCRCgen = CRCremainder If C was altered randomly, it
is most likely that also the result CRCremainder will change.
Now consider that L denotes the last byte of C and C denotes C wihout L, or in other words
C = C ◦ L. Now C will most likely result in an incorrect CRCremainder after the integrity check.
Assuming the attacker knows the plaintext value of L, then he can repair the CRC32 by XORing
the result of CRCremainder + (X 8 )−1 (CRCremainder + L) to C , where (X 8 )−1 is a bit-shifting
operation that shifts 8 bits to the right. If the value for L was correct, the packet has a correct
CRC32 value and the access-point will react accordingly. If not the attacker can try a different
value for L. On average it will take 128 guesses per byte. As soon as the byte was guessed cor-
rectly, the attacker also has a one byte shorter packet with a correct CRC32 checksum and can
start over with that to attack the 2nd last byte. This can be carried on until the whole packet is
decrypted. Knowing the plaintext and the cipher-text of the packet, the attacker can also obtain
the key-stream as discuss in chapter 3.2. [6] [7]
                                                             Wired Equivalent Privacy (WEP)         7

                       Fig. 6. chopchop attack: repairing the CRC32 checksum

3.5   Message Injection

There are two requirements for a successful packet injection:

 1. The attacker needs to be authenticated with the access-point in order for his packets to be
    accepted. This can easily be arranged as discuss in chapter 3.2.
 2. The attacker needs a packet with a correct checksum that is encrypted with a key-stream
    matching the IV and the pre-shared key. The easiest way to achieve this is to re-inject an
    unmodified packet that was captured before. In this case the attacker has no control over the
    content of the packet. An other possibility is to forge a new packet with custom content. This
    is possible, as soon as the attacker has obtained a valid key-stream and the corresponding IV.
    As discuss in chapter 3.2 and 3.4 this is no problem either.

3.6   Key Recovery

Key recovery is the most interesting attack goals, since upon success it allows the attacker full
access to the network. Accordingly there are several known attacks that shall be described here.

FMS attack The FMS-attack was proposed by Fluhrer, Mantin and Shamir in [3] in 2001. It was
the first key recovery attack against WEP. It relies on the fact that there are correlations between
the key-stream and the pre-shared key, when the algorithm is initialized with certain weak IVs. As
discuss earlier, the key that is used to initialize the RC4 algorithm consists of the IV concatenated
with the pre-shared key. Since the IV is transmitted in cleartext, the first three bytes of the key
are known for each packet. These three bytes are different for each packet but the following bytes
are always the same. Only the process to obtain the 4th byte of the key is described here, but the
method works similar for all the following bytes in the key.
With the IV the attacker knows the first three bytes of the RC4 initialization key K. He can execute
the first three rounds of the key scheduling algorithm as described in Fig.4. This leads to j3 and S3 ,
the versions of j and S after the 3rd round. In the next step j4 will be set to j3 + K[3] + S3 [3] and
S3 [3] and S3 [j4 ] will be swapped. If the attacker could gain knowledge of S4 [3], he could recover
K[3], since the following holds:
                                   K[3] = S3 [S4 [3]] − j3 − S3 [3]

In the FMS attack this is achieved by only considering packets with special IVs. Particularly, the
IVs need to have the form (a + 3, 255, x), where a is the position of the pre-shared key byte that
is currently under attack and x is a random value. In this case the attacker needs packets with
the IV (3, 255, x). If packets with these IVs are used, under certain circumstances the first Byte of
8      Alexander Gutjahr

the key-stream KS[0] will be S4 [3]. For this to hold it is necessary that the values at the positions
S[1], S[S[1]] and S[3] are not swapped around in the remaining process of the key scheduling
algorithm. Since the attacker has no knowledge of the rest of the Key K, he can not know for
sure that the relevant positions in S remain unchanged. Assuming a random switching of positions
in the remaining process, the probability that the three important positions are not swapped is
e−3 ≈ 5%.
The first byte in a WEP encrypted packet is always 0xBB, since this is the first byte of the
SNAP-Header with witch every packet starts. By XORing the first cipher-text byte with 0xBB
the attacker can obtain the first byte of the key-stream KS[0] = C[0] ⊕ 0xBB.After executing
these calculations the attacker knows the first byte of the pre-shared key with a certainty of 5%.
Consider that the byte has 256 possible values and with an even probability distribution every
value should occur in 100/256 = 0, 39% of the cases. The 5% are considerably more likely, but not
likely enough to rely only on that information. The result of the calculation has to be interpreted
as a vote for a certain value for K[0]. The attacker needs to repeat the process with different values
for x is the IV, until one value for K[0] has significantly more votes than the others. Then this
value is assumed to be correct for K[0] and the process can be started for K[1], using IVs of the
form (4, 255, x) this time. In general notation the attack can be denoted as:
                K[x] = f ms(K[0], ..., K[x − 1], KS[0]) = Sx [KS[0]] − jx − Sx [x]

After the execution of the calculations for all bytes of the pre-shared key the attacker obtains a

                               Fig. 7. Decision-Tree in the FMS-attack

decision tree as shown in 7. When the attacker has obtained a possible value for all key-bytes, he
can perform some test decryptions. If the decrypted packet is valid, the attack was successful. If
not, the attacker has to backtrack in his tree and choose a different value that was also likely for
one of the bytes in the key. All leaves following the byte that was chosen differently have to be
re-calculated, since the previous key-bytes are used in the calculation of the subsequent ones. To
get a success probability of 50% the attacker needs to collect 4 ∗ 106 to 6 ∗ 106 packets. [6] [3]

KoreK attack In 2004 KoreK posted an implementation of an advanced WEP attack tool to
the netstumbler.org-forum. Basically this was an advanced version of the FMS attack. FMS uses
a correlation between the first x bytes of the pre-shared key, the first byte of the key-stream and
the x + 1 byte of the pre-shared key. The Korek attack uses several similar correlations, including
some that were previously discuss in public, the one from the original FMS paper and several ones
that were found by KoreK himself. The attack follows the same pattern as the FMS attack:
                                                             Wired Equivalent Privacy (WEP)            9

Correlations between the first x pre-shared key bytes, the first two bytes of the key-stream and
the byte x + 1 of the pre-shared key are used to gather votes for different values for the different
bytes. The result is a decision tree that allows the attacker to obtain the pre-sahred key with a
trial and error method.
With the additional correlations the number of packets with unique IVs necessary for a 50% success
chance is reduced to about 700000. [6] [8]

PTW attack Tews, Weimann and Pyshkin proposed a new type of WEP key recovery attack in
2007 in [9]. Their attack is somewhat similar to the FMS-type attacks, but they introduce two new
concepts that distinguish their approach from the previous ones:
1. All previously known correlations had rather complex prerequisites. As a result of these limita-
tions, only a fraction of all captured packets could be used to vote for each byte of the pre-shared
key. In [10] Klein showed a correlation that does not rely on any pre-requisites such as special IVs.
All captured packets can be used to generate votes with this correlation.
          klein(K[0], ..., K[x − 1], KS[x − 1]) = Sx [x − KS[x − 1]] − (Sx [x] + jx ) = K[x]

This correlation holds with a probability of approximately 1, 37/256. This is not as high as the
probability in the FMS attack, but the bigger number of votes makes up for that.
2. The next new concept is the introduction of a new attack structure. The FMS- and KoreK-type
attacks used a decision-tree to consolidate the data from the votes for the different bytes. This
has the disadvantage, that a part of the results has to be re-calculated after a back tracking in
the tree. In contrast to this approach, Tews, Weimann and Pyshkin altered Klein’s correlation to
vote for a sum of pre-sahred key bytes. They generate votes for the sum of the first i bytes of the
pre-shared key and denote the sum k=0 K[k] with σi . So for every packet and every i {1, .., 13}
the calculate
      ptwi (K[0], ..., K[x − 1], KS[x + m − 2]) = Sx [x + i − 1 − KS[x + i − 2]] − (         Sx [a])

Note, that this function only depends on the three bytes of the IV and that it generates votes
for σi−1 . The attacker proceeds as follows: He captures a certain amount of packets and recovers
the necessary amount of key-stream as discuss earlier. Then he calculates ptwi for each available
packet and each i {1, .., 13}, obtaining votes for σ0 , ..., σ12 . The bytes of the pre-shared key can
be calculated by K[0] = σ0 and K[i] = σi − σi−1 . A few test decryptions show wether the key is
correct. If not, a different choice for one of the σi values is made and the key is re-calculated. For
this re-calculation there is no need to re-evaluate the packets to obtain new values for σi . This
reduces the calculation effort significantly compared with the FMS-type attacks.
For a success probability of 50% 35000 to 40000 packets are needed. The required computation
time is negligible on modern computers. [6] [9]

4     Practicality of attacks
4.1    Wireless communication hardware
To execute any of the discuss attack methods an attacker needs access to the wireless communi-
cation channel. As such, the attacker needs equipment that enables him to send and receive on
the correct frequencies and he needs a logic that can modulate and demodulate the physical-layer
protocol. Fortunately, widely available wifi cards and USB-dongles can do just that, although spe-
cially crafted drivers that enable injection of arbitrary packets and a monitor-mode that intercepts
all packet on the channel are necessary. These drivers are available for a great number of different
devices. Availability of equipment is no problem in this context.

4.2    Attack implementations: aircrack-ng
With equipment and software up to the physical-layer available the next requirement is an imple-
mentation of the described attacks in software. Fortunately this is readily available for all methods
10      Alexander Gutjahr

discuss in this paper. A de-facto standard in this area is the aircrack-ng suite. It is available for
linux OS and comes with all tools and drivers necessary. While the handling of the software is
somewhat tricky, the excellent documentation and active community make up for it. Availability
of implementations is also no hindrance for activity in this field.

4.3   Judicial implications
In Germany paragraph 202c of the StGB regulates the handling of so called ”hacker tools”. A
hacker tool is defined in this context via its potential to be used in illegal activities. Manufacturing,
acquisition and propagation of such tools is considered a ”gefaehrliche Vorbereitungshandlungen”
to computer criminality and punishable by law.
The software discuss in chapters 4.1 and 4.2 clearly fulfill this criteria. While there are no technical
obstacles with the usage of these tools, there very well are judicial implication to be considered.
However to the best of the knowledge of the author, there have not been any cases against legitimate
users (such as research and development) since the introduction of this law in 2006.

5     Conclusion
Attacks against WEP protected wireless networks are very sophisticated. Software and hardware
necessary for an attack is widely available and almost no understanding of the theory behind the
used mechanisms is required for a successful attack. Under optimal conditions the key of a WEP
protected network can be recovered in as little as one minute.
Therefore WEP should not be used to provide security or privacy in a wireless network. Different
alternatives like WPA or VPN-solutions are available and should be used if possible. Never the less
WEP is a nice example for a protocol design with flaws that were not immediately visible. Just as
interesting is the nicely working correction-process in the definition of its successor WPA.

 1. IEEE: Ieee standard for information technology-telecommunications and information exchange between
    systems-local and metropolitan area networks-specific requirements - part 11: Wireless lan medium
    access control (mac) and physical layer (phy) specifications. IEEE Std 802.11-2007 (Revision of IEEE
    Std 802.11-1999) (2007) C1–1184
 2. RSA: http://www.rsa.com/rsalabs/node.asp?id=2250. (2009)
 3. Fluhrer, S., Mantin, I., Shamir, A.: Weaknesses in the key scheduling algorithm of rc4. In: RC4”,
    Proceedings of the 4th Annual Workshop on Selected Areas of Cryptography. (2001) 1–24
 4. Halil Ibrahim Bulbul, I.B., Ozel, M.: Wireless network security: comparison of wep mechanism, wpa and
    rsn security protocols. In: e-Forensics ’08: Proceedings of the 1st international conference on Forensic
    applications and techniques in telecommunications, information, and multimedia and workshop, ICST,
    Brussels, Belgium, Belgium, ICST (2008) 1–6
 5. Borisov, N., Goldberg, I., Wagner, D.: Intercepting mobile communications: the insecurity of 802.11.
    In: MobiCom ’01: Proceedings of the 7th annual international conference on Mobile computing and
    networking, New York, NY, USA, ACM (2001) 180–189
 6. Tews, E., Beck, M.: Practical attacks against wep and wpa. In: WiSec ’09: Proceedings of the second
    ACM conference on Wireless network security, New York, NY, USA, ACM (2009) 79–86
 7. KoreK: http://www.netstumbler.org/f50/chopchop-experimental-wep-attacks-12489/. (2004)
 8. KoreK: http://www.netstumbler.org/f18/next-generation-wep-attacks-12277/index3.html. (2004)
 9. Tews, E., Weinmann, R.P., Pyshkin, A.: Breaking 104 bit wep in less than 60 seconds. Cryptology
    ePrint Archive, Report 2007/120 (2007) http://eprint.iacr.org/.
10. Klein, A.: Attacks on the rc4 stream cipher. Des. Codes Cryptography 48(3) (2008) 269–286

To top