Data Integrity Messages

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

The 802.11 standard only specified that the algorithm to be used should be exportable, reasonably strong, self-synchronizing, computationally efficient and optional. Furthermore, the standard required that the implementation should support three security goals: data integrity, confidentiality and access control/authentication. It is important to note here that the standard did not address other security measures like non-repudiation, auditing and authorization. Let's take a deeper look into the three security goals as defined in the 802.11 standard.

1. Data Integrity

The 802.11 standard requires a mean to provide data integrity for messages transmitted between the clients and the access points. Data Integrity means that the system should reject any messages that were changed during the transmission from the original sender to the destined receiver. For data integrity the standard defines the use of CRC-32 (Cyclic Redundancy Check - 32 bits).

2. Access Control / Authentication

The 802.11 standard specifies two modes of authentication namely open-system authentication and shared-key authentication. By authentication we mean validating a user or verifying the identity of the client station. This leads to access control of the network by denying access to nodes that fail to authenticate.

As the name suggest the shared-key authentication is based on shared-key cryptography and the other one behaves as an open-system i.e. anybody can connect to the system and the identity of the client station is not verified at all. Please note that the standard defines the authentication to be one way i.e. only the client station is authenticated and the access points are trusted by default. The 802.11 standard defines a challenge-response based protocol that uses RC4 as a shared-key cipher for authentication. The authentication algorithm is also a part of Wired Equivalent Privacy (WEP) protocol.

3. Confidentiality

The confidentiality is obviously achieved by encrypting the data before it released into the open air. In others words all the communication that takes place between the client and the access point is encrypted. By confidentiality we mean that the data or messages cannot be read by client stations other than the one it is destined for. The 802.11 standard defined Wired Equivalent Privacy (WEP) protocol to achieve this goal and the name comes from the fact that it is intended that the privacy is at par with its wired counterpart.

  • Wired Equivalent Privacy (WEP)

The security in 802.11 suite of standard is largely provided by the Wired Equivalent Privacy (WEP) protocol. This protocol is used to protect link-level data during the wireless transmission between the clients and access points. It is important to remember that the involvement of WEP as defined in the standard is limited to wireless part of the communication and does have any contribution on the wired side.

WEP is a simple algorithm that uses a RC4 stream cipher and Pseudo-Random Number Generator (PRNG). This protocol was considered to be secure since its details were generally not available but all this changed when somebody placed the source code in the “cypherpunks” mailing list [9].

  • Working of WEP Encryption [Fulfills Confidentiality]

Let's define some terms before we dwell into the working of WEP protocol.

Stream Cipher

An algorithm that expands a short key (input) into an infinite pseudo-random key stream (output).

XOR (Exclusive OR)

XOR is a binary function that produces 1 if one of the two input bits is 1 and produces 0 if either both of the input bits are 0 or both are 1.


Actual message that needs to be transmitted.


Message after encryption.

Now, we move our attention to the actual working of the WEP protocol. The sender and the receiver use RC4 stream cipher to create identical pseudo-random strings from the shared key also termed as WEP key. The sender XORs the plaintext with the pseudo-random string to produce the ciphertext. The receiver then reverses this process i.e. it XORs the ciphertext with the pseudo-random string (produced with shared key) to get the actual message or plaintext. Please note that the behavior of the XOR function is such that when a message is XORed with a key you get a ciphertext and when this ciphertext is XORed again with the same key the plaintext is produced.

The following steps explain the process in detail:


  • A 24-bit Initialization Vector (IV) [just a 24-bit number] is generated (can be sequential) and pre-pended to the secret key.
  • This combination of IV and secret key is supplied to the RC4 algorithm to produce a seed value for the WEP pseudo-random number generator (PRNG).
  • The WEP pseudo-random generator produces the cipher stream that will be used for encryption.
  • The cipher stream from the PRNG is then XORed with the plaintext to get the ciphertext. Here the plaintext means the original message appended with the integrity check value (ICV) - a CRC32 string used to ensure integrity as discussed in the previous section.
  • Lastly, the ciphertext is pre-pended with the IV (in clear text) and transmitted.


  • The 24-bit clear text IV is removed from the received packet.
  • The combination of removed 24-bit IV and the shared key is supplied to the RC4 algorithm to produce a seed value for the WEP pseudo-random number generator.
  • The PRNG produces the cipher stream that will be used for decryption (will be the same cipher stream that was used for encryption).
  • The cipher stream from the PRNG is then XORed with the ciphertext to get the plaintext (remember the XOR function property). Please note that received plaintext will be the original message appended with the integrity check value (ICV).
  • Not part of the encryption process but to ensure data integrity an ICV or CRC-32 is computed onto the decrypted message (message without the received ICV) and the generated ICV is computed with the received ICV.
  • Working of Shared Key Authentication [Fulfills Authentication]

The following steps explain the process in detail:

  • The client station sends an authentication request management frame indicating that shared key authentication is to be used.
  • The access point (or other client for that matter) sends back an authentication management frame containing 128 octets of challenge text to the client station. The challenge text is randomly generated by WEP pseudo-random number generator (PRNG) with the shared key and a random initialization vector (IV) [passed through RC4 to create a seed for PRNG, same as in WEP encryption process].
  • The client station upon receiving the management frame copies the challenge text from the management frame into a response management frame.
  • This new management frame is then encrypted using the WEP encryption process defined in the previous section.
  • The access point upon receiving the response from the client station, decrypts the response (the decryption process is same as defined in the WEP process), compares it with the original challenge text, verifies the ICV (CRC-32).
  • If the ICV is valid and the decryption response matches the original challenge text then authentication is considered successful and client station is associated, otherwise the authentication fails and client is not allowed to associate.

Example to clear up the WEP working logic

Let's take a look at a very simplified example to understand the logic involved behind WEP protocol. For simplicity sake 8-bit key and 8-bit message is used and 3 bits IV are used. Furthermore, ICV or integrity checksum is ignored.

P = Plaintext

C = Ciphertext

IV = Initialization Vector

K = Shared Key

R(IV,K) = Cipher Stream produced by PRNG by accepting the seed value generated from RC4 on the basis of initialization vector (V) and shared key (K).

ICV = Integrity Checksum Value (CRC-32)

K = 10101100

IV = 111

R(IV,K) = 10101111 [Assumed, the value is not actually calculated from K and IV]

P = 11110010 (assumed that this includes the ICV as well)

Sender calculates

C = P XOR R(IV,K) = 11110010 XOR 10101100 = 01011101

Receiver calculates

P = C XOR R(IV,K) = 01011101 XOR 10101111 = 11110010

Please note that IV in above is received as clear text in the message and since receiver also has the key it can now generate the same R(IV,K).

  • How to Hack the Shared Key Authentication of WEP (Flaws)

If we take a look again at the example given in the previous section we can conclude that if a ciphertext and a plaintext combination is known then we can produce a cipher stream R(IV,K) without even knowing the shared key. This means that we can encrypt and decrypt the messages without knowing the shared key. Let's clear things up by continuing with the previous example.

P = 11110010 [given in the previous example]

C = 01011101 [produced in the previous example]

Now, R(IV,K) = P XOR C = 11110010 XOR 01011101 = 10101111

Which is the same as the one used to encrypt and decrypt message (look at the example in previous section). The important thing to remember here is that this R(IV,K) is valid for a particular IV and key combination. We don't expect key to change but IV can change but thanks to the working of WEP the IV is appended to the message in clear text.

This flaw or weakness in the WEP protocol leads to an interesting attack that be used by a hacker client station to authenticate to an access point. Let's go through some facts that make the attack possible:

  • Remember that in wireless network all the traffic flows through open air. This means that anybody can read the traffic or messages (in wired on has to tap into the wire but in wireless you just need to be in the vicinity).
  • Authentication management frame has a defined structure so a hacker listening to the traffic can figure out an authentication management frame from others.
  • Only the challenge text changes from one authentication frame to other authentication frame.

After considering the above facts the following outlines the working of the attack:

  • The attacker captures the second (containing challenge in plaintext) and third authentication (containing response which is encrypted challenge) management messages.
  • The attacker knows the challenge and encrypted challenge so now he or she can compute the pseudo-random stream R(IV,K) from them.
  • Please note that the attacker also retrieve and stores the initialization vector IV from the authentication response message as it will be required for the successful creation of the new response (remember IV is pre-pended to the message).
  • Now, the attacker requests authentication with the access point.
  • The access point responds with a challenge (in clear text).
  • The attacker takes the challenge, the computed cipher stream R(IV,K) from step 2 and calculates a valid response (by XORing the two values).
  • The attacker then computes the new integrity check (ICV), appends it at the end of the message.
  • The attacker then pre-pends the stored IV in step 3 and constructs a valid authentication response frame.
  • This new frame is send to the access point and the hacker's client station is authenticated [and all this happened without actually knowing the key].

It is important to note here that the successful authentication does not necessarily mean that the hacker's station will be able to communicate with access points or other clients since WEP encryption can be active. Though, the authentication certainly acts a first step into hacking the system. Furthermore, in many wireless deployments WEP encryption is not enabled, so once you successfully authenticate you are free to use the system.