WEP: introduction to the mechanism of operation
Number 0x01: 03/23/2006
[ --- The Bug! Magazine
_____ _ ___ _
/__ \ |__ ___ / __\_ _ __ _ / \
/ /\/ '_ \ / _ \ /__\// | | |/ _` |/ /
/ / | | | | __/ / \/ \ |_| | (_| /\_/
\/ |_| |_|\___| \_____/\__,_|\__, \/
|___/
[ M . A . G . A . Z . I . N . E ]
[ Numero 0x01 <---> Edicao 0x01 <---> Artigo 0x05 ].> 23 de Marco de 2006,
.> The Bug! Magazine < staff [at] thebugmagazine [dot] org >
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
WEP: introduction to the mechanism of operation
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.> 21 de Marco de 2006,
.> Gustavo Bittencourt a.k.a spud < gustavo [at] rfdslabs [dot] com [dot] br >
Table of Contents
- Objective
- Introduce
- General characteristics
- 3.1. Checksumming
- 3.1.1 Mathematical model of the CRC
- 3.1.2 Implementing the CRC algorithm
- 3.2. Encryption
- 3.2.1 Vernam Cipher
- 3.2.2 RC4
- 3.3 Transmission
- 3.3.1. General frame structure
- 3.3.2. Frame Control
- 3.3.3. WEP frame structure
- 3.3.4. 802.11 frame types
- Operating mechanism
- Conclusion
- References
1. Objective
The initial idea when I started writing this article, was to present in a conceptual way some important flaws that, if employed efficiently, can significantly compromise the confidentiality of data transmission in Wi-Fi environments that use WEP (Wired Equivalent Privacy) as the main security mechanism.
However, during the development of this document, the fear that some relevant information could go unnoticed, led me to address in a more detailed way the topics about the fundamental concepts of the data encapsulation mechanism used by WEP. For this reason, I ended up extending my work to describe the fundamental processes involved in the communication layer, leading to a natural segmentation of my work in different parts.
The first published article seeks to show, in a general way, the technical concepts involved in the wireless communication process, using WEP as a security mechanism. The topics covered in this document are of fundamental importance for a good understanding of the general functioning of the protocol and consequently, the flaws involved in its implementations.
This article will not present any flaws, being the study of them reserved for another stage of this work. This way, I can focus more efficiently on the technical and practical details, giving more emphasis to the content of each chapter. I commit myself with the readers to publish in the next editions of the magazine, some of the exploration practices employed in these environments.
2. Introduction
The continuous study carried out by the IEEE 802.11 Working Group has led to the ratification of new wireless communication technologies and standards, among these technologies, the research involving WLANs stands out. At the same time that they have provided great connectivity solutions, Wi-Fi networks have brought new challenges and paradigms to be faced, especially in relation to security.
The main difference between wired and wireless networks concerns the change in the transmission medium. Instead of cables, this technology uses the air to send data, modulating radio waves and transmitting within a well-defined band in the electromagnetic spectrum. The frequencies used can vary according to the standard of the technology, and the restrictions imposed by federal laws regarding the use of the band.
Due to problems involving the transmission medium, wireless networks face crucial problems regarding the confidentiality of the data transmitted between stations. Unlike wired networks, where in order to access information you must be physically interconnected to the rest of the network, intercepting traffic from wireless networks is relatively simple by tuning a receiver (which can be the network adapter itself) to the same frequency that the devices are operating on.
The transmission medium is undoubtedly the critical point in securing wireless networks. However, we must emphasize that no less important issues, such as those related to configuration, infrastructure, and authentication, are critical to ensure an acceptable level of security.
The IEEE 802.11 solution to this problem came with the ratification of WEP (Wired Equivalent Privacy) in September 1999. WEP, in short, is a communication protocol that tries to guarantee confidentiality and integrity, to the content in network traffic, the basic pillars of any cryptographic mechanism. To fulfill this role efficiently, WEP makes use of RC4, the famous encryption algorithm successfully implemented in SSL, along with CRC-32, a kind of checksum to ensure the integrity of the transmitted content.
3. General features
The security proposed by the protocol is based on a secret key k, shared between the stations and the DS (Distribution System), used to protect the content being transmitted. The transmission mechanism proposed by WEP can be basically divided into three fundamental steps: chechsumming, encryption and transmission.
3.1. Checksumming
The checksumming mechanism is used to ensure the integrity of the transmitted content. For this purpose, algorithms capable of generating a certain value from a fixed database are usually employed. A very popular and commonly employed method is CRC (Cyclic Redundancy Check).
The methodology employed by CRC agorithms consists basically in doing a series of mathematical calculations over a block of data and return a value, known as checksum, which represents the data organization within the block. By comparing the checksum of one block with another, we are able to tell if there has been any change in relation to the initial organization of the data.
CRC algorithms are often used to detect errors caused by noise on the transmission channel. Most networking protocols use CRC to ensure that data sent is identical to data received. WEP makes use of CRC-32, an easily analyzable algorithm that is mathematically implemented to generate a 32-bit checksum known as ICV (Integrity Check Value).
Most of the content and mathematical models presented in the next two sections were compiled and extracted from information originally contained in Wikipedia [5].
3.1.1 CRC mathematical model
The operation of the algorithm is based on the space generated by the polynomials of integer coefficients, these coefficients are defined according to an arithmetic of modulo 2. In other words, we are talking about the set of polynomials of coefficients 0 or 1 with well-defined arithmetic. Based on this model, we can represent a vector of bits as the coefficients of a polynomial, where the size of the vector is directly linked to its degree. Thus we obtain a mathematical relationship between a polynomial and a bit vector.
A representation of this model can be found below:
Let the following polynomial be given,
P(x) = x6 + x4 + 1
this polynomial can be expanded to the following form,
P(x) = 0x7 + 1x6 + 0x5 + 1x4 + 0x3 + 0x2 + 0x1 + 1x0
representing this polynomial from a bit vector we will have,
P(x) = [ 0 ][ 1 ][ 0 ][ 1 ][ 0 ][ 0 ][ 0 ][ 1 ]
To calculate the ICV we must divide the polynomial that represents the bit vector by a fixed polynomial previously chosen. The ICV will be formed by the coefficients of the polynomial generated by the rest of this division. There are certain characteristics for the choice of fixed polynomials, according to which they make the result more efficient to detect errors. It is beyond the scope of this paper to discuss these features, we will only briefly present how the model works, thus clarifying future approaches about the mechanisms to exploit the vulnerabilities of the algorithm's implementation. Just for illustration purposes, the polynomials most used in 32-bit implementations of CRC are: 0x04C11DB7 and 0xEDB88320.
We can use the remainder theorem to exemplify how the algorithm works. It is worth mentioning that all operations must be performed according to a modulo 2 arithmetic.
M(x) * xn = Q(x) * K(x) + R(x)
Let's assume that M(x) is the polynomial that represents the bit vector of the original message. K(x) represents the fixed polynomial and Q(x) the quotient obtained in the division. The term M(x) * xn, where n is the degree of the fixed polynomial, results in the original message followed by n zeros. Finally R(x) represents the polynomial remainder, generated from the division of M(x) by K(x) and used as ICV integrity value.
Let's exemplify this model:
admit the polynomial x3 + x2 + x, divided by the polynomial x + 1,
(x3 + x2 + x)/(x + 1) = (x2 + 1) - 1/(x + 1)
rewriting the result in another way,
(x3 + x2 + x) = (x2 + 1)(x + 1) - 1
In the example above, x2 + x + 1 represents the original message, the fixed polynomial is x + 1, and 1 is the remainder of the division, which in polynomial notation (x0) represents the integrity value. The degree of the fixed polynomial is 1, so we must multiply the message by x1 to get x3 + x2 + x.
3.1.2 Implementing CRC algorithm
The basic principle of error detection during data transfer is to notify the recipient that the message received differs from that transmitted by the sender. A simple way to verify this is to compare the checksum of the message before transmission with the checksum obtained after the data has been transmitted. It is not possible to get the same checksum if there is a significant change in the database.
Let us assume that we have a message M(x) that we wish to transmit. In a communication, the sender of the message must concatenate at its end the coefficients of the polynomial R(x), these coefficients, as noted earlier, constitute the ICV. On the other hand, the receiver in possession of M(x) and R(x) checks to see if M(x) * xn - R(x) = Q(x) * K(x), if the values match, the receiver automatically assumes that the bits contained in the transmitted message are correct. Note that the term M(x) * xn - R(x) corresponds to the value of the ICV concatenated by the sender in the original message.
Now that we know how the process of verification and validity of sent messages occurs, we need an algorithm that is able to calculate the ICV efficiently. Below we can find a method to obtain the integrity value that can be generically applied to any situation.
function crc(bit array bitString[1..len], int polynomial)
{
shiftRegister := initial value // commonly all 0 bits or all 1 bits
for i from 1 to len
{
if most significant bit of shiftRegister xor bitString[i] = 1
shiftRegister := (shiftRegister left shift 1) xor polynomial
else
shiftRegister := shiftRegister left shift 1
}
return shiftRegister
}Some clarifications are necessary regarding the code shown:
- bitString: Corresponds to the bit vector of the original message that represents the polynomial that will be used for the calculations.
- shiftRegister: We can think of this unit as a local variable with 32 bits, that is, 4 bytes, where the checksum value will be stored at the end of the division process. The fact that the name of the algorithm is CRC-32, indicates that the generated ICV size will be 32 bits.
- polynomial: Vector of bits that represents the fixed polynomial used as the basis for the ICV calculation. As we saw earlier, for the case of CRC-32, this polynomial can assume two distinct values: 0x04C11DB7 and 0xEDB88320.
CRC algorithms, while very useful for detecting transmission errors, cannot be reliably employed to guarantee message integrity. Due to the linear structure of polynomials, significant changes to the message content can be made intentionally, without the checksum value being alerted. For this purpose, algorithms with hash functions are the most suitable. We will see in the next sections that one of the main flaws in the WEP implementation lies in the fact that the CRC-32 algorithm is used.
3.2. Encryption
Cryptographic processes can be divided between symmetric and asymmetric key mechanisms. In the asymmetric key mechanism, each side in the communication channel has a pair of keys, called public and private. The use of these keys is alternated according to the act of encrypting and decrypting the content in traffic. On the other hand, in the symmetric key mechanism, both sides of the communication channel share the same key, used both to encrypt the content and to decrypt it.
As mentioned earlier, WEP makes use of the symmetric key method, using an algorithm called RC4 to encrypt the contents of messages. This algorithm is the same one implemented in the SSL (Security Socket Layer) protocol. Its working principle is based on the Vernam Cipher model, and its mechanism will be explored in more detail in the following sections.
3.2.1 Vernam Cipher
The Vernam Cipher model was initially proposed by Gilbert Vernam, an engineer at AT&T Bell Lab, in 1917. The model proposed by Vernam is now characterized as a stream cipher, i.e. the message is encrypted by simple XOR operations against a pseudo-random byte string with size identical to the message.
The security of the model is based on a symmetric secret key, known to both sides of the communication channel. This key serves as input to a PRNG (Pseudo Random Number Generator) algorithm, which is responsible for generating the pseudo-randomized string that will be used to encrypt the content in the future.
One of the main security problems presented by Vernam Ciphers is the fact that identical messages will produce results with the same encryption pattern, i.e. equal results. An alternative to overcome this problem is to make part of the bytes of the secret key assume different values each time the algorithm is used. It is important to make sure that the range of values used by the key is large enough to avoid repetition in a short period of time. Algorithms that work based on this mechanism are also known as one-time pad.
Below is a simplified schematic of a Vernam Cipher:
+----------------+
| secret key | ----------------+
+----------------+ |
|
v
+-----------------------------------------+
| pseudo-random number generator [ PRNG ] |
+-----------------------------------------+
|
|
v
+---------------------+ +-------------+ +------------------+
| plaintext data byte | XOR | random byte | = | cipher data byte |
+---------------------+ +-------------+ +------------------++ encryption : P XOR R = C
+ decryption : C XOR R = P
The WEP model brings with it the use of a vector concatenated to the beginning of the secret key. This vector has a fixed size of 24 bits, i.e. the first 3 bytes of the key, and is called Initialization Vector or simply IV. The purpose of using the IV is exactly the same as explained above. The idea of its implementation is to make the encrypted messages sufficiently random, ensuring more security to the encryption process.
3.2.2. RC4
Originally RC4 was created by Ronald Rivest of RSA Security in 1987. At first the code was secret, but the algorithm was reverse engineered and a similar code was anonymously published in 1994 in the Cyperpunks mailinglist. After several studies it was verified the validity of the algorithm in relation to the original, becoming public its mechanism of operation. Nowadays RC4 is also referred to as ARCFOUR, due to trendmarks issues and reasons.
The main characteristic of RC4, besides the fact that it is based on a Vernam Cipher, is that the algorithm was specially designed for software level implementations. Due to the fact that it consumes few system resources, performing only simple operations by manipulating bytes, it is recommended for use in systems with few resources and limited processing power.
The study of the RC4 algorithm can be divided into two parts:
- key-scheduling algorithm [ KSA ]
- pseudo-random generation algorithm [ PRGA ]
KSA, key-scheduling algorithm:
Basically the algorithm initializes a station array S, and performs several permutations based on the values of the secret key. The purpose of this first step of RC4 is to satisfactorily shuffle the information contained in the array S.
Algoritmo KSA:
ksa(key)
initialization:
for i from 0 to 255
S[i] := i
j := 0
scrambling:
for i from 0 to 255
j := (j + S[i] + key[i mod n]) mod 256
swap(S[i], S[j])Uses modular arithmetic based on modulo 256.
The indices i and j point to 8-bit regions inside the array S.
The array key corresponds to the secret key, typically between 40 and 128 bits.
The constant n represents the modulo the array key must obey.
The n can vary between 5 and 16 according to the size of the secret key.
Algoritmo KSA ilustrado:
key = [ ][ ][ ][ ... ][ ][ ... ][ ][ ][ ]
0 1 2 i n-3 n-2 n-1
|
+-------------+
|
v
< j + S[i] + key[i] = j >
^ ^ |
| | +-------+
+-----------+-----+ |
| | v
S = [ ][ ][ ][ ... ][ ][ ... ][ ][ ... ][ ][ ... ][ ][ ][ ]
0 1 2 i j 253 254 255
^
^ |
S[i] | swap | S[j]
+-----------------------+PRGA, pseudo-random generation algorithm:
The main goal of the algorithm is to perform more permutations inside the state array S, and output a byte that will be used to encrypt a byte of the original message. Each iteration increases the randomness inside the array S. After all iterations, we will have as output a stream of random bytes of the same size of the message we want to encrypt, these bytes are also called key stream.
Algoritmo PRGA:
prga(S)
initialization:
i := 0
j := 0
generation loop:
while generating output
i := (i + 1) mod 256
j := (j + S[i]) mod 256
swap(S[i], S[j])
output S[(S[i] + S[j]) mod 256]Algoritmo PRGA illustrated:
S[i] + S[j]
+-----------------+
| |
| +-----------+
| S[i] | swap | S[j]
v v v
S = [ ][ ][ ][ ... ][ ][ ... ][ ][ ... ][ ][ ... ][ ][ ][ ]
0 1 2 | i j 253 254 255
|
| output byte
+-------------> S[ S[i] + S[j] ]
3.3. Transmission
In the previous sections we have been acquainted with the basic mechanisms of the encryption system used by WEP. Now it is necessary to present the process used by the 802.11 standard to transmit data. To accomplish this task, the standard makes use of 3 different types of frames: control, management and data.
Each frame has its own header, with a great variety of fields that are interpreted in the Data Link Layer, more specifically in the MAC sublayer (Media Access Control). There are also some headers that are interpreted in the Physical Layer, however, they concern issues involving the modulation techniques used by the standard, and will not be covered in this discussion, since they are beyond our scope. More information about frame structures and the contents of headers in 802.11 can be obtained from the documents found on the official page of the 802.11 Working Group [6].
3.3.1 General frame structure
Below is the general frame structure of 802.11. This representation will be the basic skeleton for building any kind of frame. Previously we can observe the existence of some fundamentally important fields like Addrs, which will be responsible for carrying, among others, the source and destination addresses of the frame.
Bytes:
2 2 6 6 6 2 6 0-2312 4
+----+----------+-------+-------+-------+------+-------+----------+----------+
| FC | Duration | Addr1 | Addr2 | Addr3 | Seq. | Addr4 | Data | Checksum |
+----+----------+-------+-------+-------+------+-------+----------+----------+
<--------------------- MAC Header --------------------->Below is a more detailed presentation of how the different frames generally work, and what each field means:
- Frame Control: This field, particularly, is very important. It is responsible for ensuring that the frame is transmitted correctly. Because it has several subfields, this particular topic will be covered in more detail in the next section.
- Duration / ID: This field is responsible for informing how long the frame is being transmitted. Through this field it is possible to predict how long it will take to complete its transmission, i.e., it becomes possible to calculate the average time that the frame will occupy the communication channel. Stations also use this field for NAV (Network Allocation Vector) calculation mechanisms.
- Addresses (1-4): Altogether 802.11 standard frames can contain up to four addresses. The addresses are represented by the MAC of the adapter, the fields can correspond to: Basic Service Set Identifier (BSSID), Destination Address (DA), Source Address (SA), Receiver Address, and Transmitter Address (TA). These addresses are arranged according to the type of frame, i.e. there is no rigid order in which the fields are filled in. Another not-so-important feature is that frames do not have to contain all address fields.
- Sequence Control: The third field that appears in the 802.11 standard structure is Sequence Control. This field is composed of two sections: Sequence Number and Fragment Number. These two subfields are used to represent the order of frames when divided into multiple fragments, aiding in the recognition of duplicate packets.
Bits: 4 12
+-----------------+-----------------+
| Fragment Number | Sequence Number |
+-----------------+-----------------+
<------ Sequence Control Field ----->- Data: This field has volatile size, varying between 0 and 2312 bytes approximately, it contains the information that will be transmitted or received through the frame.
- Checksum: Contains a 32 bits value, generated from the CRC-32 (Cyclic Redundancy Check) algorithm, that represents the integrity of the frame content. The ICV (Integrity Check Value) is calculated based on all the other fields in the frame. More details about the process by which the ICV is generated can be found in the previous sections.
3.3.2 Frame Control
The first field that appears in the 802.11 standard concerns Frame Control, referred to in the figure as FC. With a total of 11 fields and a size of 2 bytes, the main function of FC is to guarantee control over the transmission of the frame in question.
802.11 frame control structure:
Bits:
2 2 4 1 1 1 1 1 1 1 1
+---------+------+---------+------+--------+----+-------+-----+------+---+---+
| Version | Type | Subtype | ToDS | FromDS | MF | Retry | Pwr | More | W | O |
+---------+------+---------+------+--------+----+-------+-----+------+---+---+Description of the fields:
- Protocol Version: This field contains the version of the protocol, specified by the 802.11 standard that is being used in the transmission. The value corresponding to the initial version of the protocol was set to 0, being incremented with each new change in the standard.
- Type and Subtype: These fields define the purpose of the frame. As we saw earlier, there are 3 types of frames: control, data and management. These types are combined with the subtypes: RTS, CTS, ACK, among others. The official documentation about the 802.11 standard provides more detailed information as tables and binary representation of the possible combinations.
- FromDS and ToDS: The FromDS and ToDS bits are responsible for controlling the direction of frames, indicating whether they are on their way to, or leaving, the DS. There are some special combinations between the two fields that inform when the frame is being transmitted directly from station to station, or from AP to AP, without passing through the DS.
- More Fragments: Responsible for indicating if the data or management frames are unique, or if there are proceeding frames. The bit takes the value 0 if there are no other frames, otherwise the value 1 will be set.
- Retry: The field is responsible for indicating if the current frame is a retransmission of a previously sent frame. The use of this bit serves to signal to a receiving station that duplicate frames are discarded.
- Power Management: Bit responsible for indicating which mode a station will be in after the end of the sequence of frames being transmitted. An important characteristic is that the bit always assumes value 0 for all frames transmitted by the AP.
- More Data: Indicates to the station the reception of future frames still buffered.
- WEP: The value of this bit means that the payload and checksum fields have been processed according to the encryption methods applied by WEP. A value of 1 indicates that the data was submitted to the process, on the other hand, a value of 0 represents the opposite.
- Order: Tells the receiver that the processing order of the sequence of frames marked with this bit must be taken into account. The frames whose fields are marked with the value 1 are specially processed by special sending functions that guarantee the order in which the frames are received by the recipient.
3.3.3 WEP frame structure
The frames processed according to WEP (Wired Equivalent Provision) receive an additional field, represented in the figure above by section IV, this field is composed of two sections: Initialization Vector and KeyID.
Bytes:
2 2 6 6 6 2 6 4 0-2312 4
+----+----------+-------+-------+-------+------+-------+----+------+----------+
| FC | Duration | Addr1 | Addr2 | Addr3 | Seq. | Addr4 | IV | Data | Checksum |
+----+----------+-------+-------+-------+------+-------+----+------+----------+Field IV in more detail:
<--- encrypted --->
+----+------+----------+
| IV | Data | Checksum |
+----+------+----------+
|
| +-----------------------+-------+
+---> | Initialization Vector | KeyID |
+-----------------------+-------+
Bits: 24 8The KeyID subfield is responsible for carrying the number corresponding to the secret key, informing which key was used to encrypt the frame content, the KeyID is only used in mechanisms that implement an encryption system based on rotating keys. The Initialization Vector, as seen before, is concatenated with the secret key and is responsible for guaranteeing randomness to the keystrem generated through RC4.
3.3.4. 802.11 frame types
The above information is by no means definitive, it only serves to clarify the general way frames are constructed. Each specific frame has different formats, in certain frames some fields are omitted, because their presence is not necessary.
The frames can be of three types: control, data and management.
Data Frames:
The data frames are responsible for transmitting the information coming from the higher layers. This information is stored in the Data field, shown in the general frame model presented above. The information transmitted can be of any type, and is normally encapsulated within the TCP/IP headers. It is worth noting that the 802.11 standard defines just one more data encapsulation mechanism.
Consider for example the HTTP protocol, we would have :
+-------------------------------------------------------------+
| +----------------------------------------------+ |
| | +-----------------------------------+ | |
| | | +-----------------------+ | | |
| | | | +----------+ | | | |
| 802.11 | IP | TCP | HTTP | Data | | | | |
| | | | +----------+ | | | |
| | | +-----------------------+ | | |
| | +-----------------------------------+ | |
| +----------------------------------------------+ |
+-------------------------------------------------------------+Control Frames:
Control frames act as delivery assistants between stations, managing traffic control and ensuring that the frames are delivered to their destination correctly. Control frames have the following subtypes:
- Request To Send (RTS)
- Clear To Send (CTS)
- Acknowledgment (ACK)
- Power-Save Poll (PS-Poll)
- CF-End
- CF-End + CF-Ack
Management Frames:
Management frames are undoubtedly one of the most common types of frames found in Wi-Fi network traffic. They are responsible for the control and signaling of information related to the network in general, being of fundamental importance in the creation and maintenance of communication between the stations. The management frames have the following subtypes:
- Beacon
- Disassociation
- Association Request
- Association Response
- Reassociation Request
- Reassociation Response
- Probe Request
- Probe Response
- Authentication
- Deauthentication
- IBSS Announcement Trafic Indication Message (ATIM)
Some of the names shown in the control and management frames are suggestive enough to deduce their purposes, others not so much. It is worth reinforcing that detailed information about the constitution of these frames can be found in the official documentation of the 802.11 standard.
4. Working mechanism
To guarantee integrity and confidentiality of the transmitted content, WEP applies the mechanisms presented in the sections related to checksumming and encryption. These processes together with the help of the frames explained earlier guarantee the complete operation of the protocol illustrated in the figure.
key ->-----+ +-----<- key
| |
| |
plaintext +------------+ ciphertext +------------+ plaintext
-----------> | encryption | ------+-----> | decryption | ----------->
+------------+ | +------------+
|
+-------> eavesdropperLet's assume we have a message M and want to submit it to WEP encapsulation and transmission processes. First, we compute the checksum for the message CRC(M) = ICV, then the ICV is concatenated with the original message forming the plaintext P = <M,ICV>.
In a second step, the plaintext must be encrypted following the RC4 model presented in the previous sections. To do this we must concatenate the IV with the secret key K, forming the pair <IV,K>, this pair will be used as input to the RC4 algorithm generating our keystrem RC4(IV,K). In possession of the keystrem it becomes easy to get the ciphertext, just perform an xor between the two byte strings as follows.
C = P <XOR> RC4(IV,K)This mechanism is shown in the diagram below:
[ IV ] ---+
| +-----------+
+---> seed = [ IV,K ] ---> | RC4(IV,K) | ---> [ keystream ] -+
| +-----------+ |
[ K ] ----+ -
XOR
[ message ] ---+--------------------------------+ -
| | |
| +-----> [ message + ICV ] -+
| +--------+ | |
+---> | CRC-32 | ---> [ ICV ] ---+ |
+--------+ |
|
[ WEP Frame ] = [ IV ] + [ ciphertext ] <--------------------+To decrypt the message content, the receiver must do the reverse path of the one shown above. First it is necessary to generate the same keystream used by the sender to encrypt the content, so the receiver must concatenate the IV sent in the packet frame with its copy of the secret key K, forming the pair <IV,K>. After that, it must use the RC4(IV,K) keystream to recover the originally transmitted plaintext.
P' = C <XOR> RC4(IV,K)
P' = [P <XOR> RC4(IV,K)] <XOR> RC4(IV,K)
P' = PIn a second step, the recipient must calculate the ckecksum of the received message CRC(M'), comparing it with the ckecksum sent as an attachment in the contents of the packet. If the equality is confirmed, i.e. CRC(M') = CRC(M), the message is validated by the receiver.
This mechanism is illustrated in the following diagram:
+- [ IV ] + [ chiphertext ] ----------------> [ chiphertext ] -+
| |
| +- XOR
| +-----------+ |
+---> seed = [ IV,K ] ---> | RC4(IV,K) | ---> [ keystream ] -+
| +-----------+ |
| |
+- [ K ] |
+--- [ message ] + [ ICV ] <------------------+
|
| ---+---> checking [ ICV = ICV' ? ]
| +--------+
+---> | CRC-32 | --> [ ICV' ]
+--------+
5. Conclusion
Throughout this article it was possible to contemplate the general mechanism of WEP operation. A good understanding of the content exposed in this publication is a basic prerequisite for understanding the flaws that exist in the implementations of the model. In the same way, the knowledge acquired in the topics above is required to make possible the main ways of exploiting the protocol.
The information presented is by no means definitive. If necessary, the references will guide the reader to a more in-depth view of a specific topic.
6. References
- WEP (Wired Equivalent Privacy) http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
- Stream Cipher http://en.wikipedia.org/wiki/Stream_cipher
- Vernam Cipher http://en.wikipedia.org/wiki/Vernam_cipher
- RC4 http://en.wikipedia.org/wiki/Rc4
- CRC (Cyclic Redundancy Check) http://en.wikipedia.org/wiki/Cyclic_redundancy_check
- Wireless LAN Media Access Control (MAC) and Physical Control. Specifications at http://standards.ieee.org/getieee802/download/802.11-1999.pdf
