Wednesday 15 May 2013

Wireless Part 3

WEP (Wired Equivalent Privacy)

In September 1999 802.11(legacy) was released. This was the beginning of wireless LAN communications, but required some security, otherwise anybody could intercept/sniff passwords, usernames or any other data which was desired out the the airwaves. Thus WEP was created, with the intention of privacy, allowing for a passkey to encrypt wireless traffic. The major problem with WEP was it was broken before it was implemented, in other words it was never secure, when it was first proposed their were papers being published talking about flaws.

How it works

WEP uses RC4 algorithm which is a symmetric key algorithm, meaning that both parties have identical keys which are used to encrypt and decrypt the data. It is also worth noting that due to things like this, WEP was very low resource usage on the device which was using it, allowing for basic hardware to run it, thus it is still used today in some cases.

WEP is only used in the frame body of a packet. This frame body is split into 3 parts, IV, Data and ICV. IV or initialization vector is a non-encrypted part (which we will come to why later), which begins to show some vulnerability. One of the fields of this was for key id's and was 2-bits large, allowing for 4 different pass phrases to be used. Finally the IV was 24-bits large (important in a minute).

The next part was the data. This is just the data which you wish to send (nothing majorly important here for the purposes of cracking WEP.

Finally we have the ICV. This is the Integrity Check Value. This is also encrypted in WEP. The ICV merely acts as a check-sum to verify that the data has been sent/received correctly.

The steps of WEP

  1. First the IV is generated at random, this is a 24-bit value. This is added to the WEP key which can be either 40-bits or 104-bits. This provides us with a value of 64-bits or 128-bits (which is why its length being 24-bits was important before). This is then inputted into the RC4 algorithm, giving us a random key stream.
  2. At the same time, CRC-32 is applied to the data. This is a basic algorithm using a 32-bit chunk of data and applying a mathematical operation to give a value, which is then appended to the data.
  3. Finally with a key stream the same size as the data to be sent + the ICV, a XOR operation is applied to both the result of step 1 and the result of step 2. This gives us our final cipher text. Now this data should be completely impossible to read, whether your the AP or client, which is a problem, so the IV is put infront of the cipher text, giving us the completed data set for the frame body.


Now if that was abit hard to keep up with, don't fret as there is a diagram incoming :)

This image was lifted from another blogger called Zero-Krangkaian

I think this is enough for this week, and next week I shall begin the basics on where the vulnerabilities are exactly, and how to get past them.

As always thanks for reading :) - Spectr3

No comments:

Post a Comment