WEP
WEP (Wired Equivalent Privacy) was the first attempt to secure 802.11. Unfortunately, the privacy it provided was neither equivalent to wired nor very good. Its very design does not protect against replays, meaning that an attacker can record prior valid traffic and replay it later, getting the network to repeat actions (such as charging credit cards) without detecting it. Furthermore, WEP uses for encryption RC4, an algorithm that was not designed to be used in the way WEP uses it, leading to ways of reverse-engineering and cracking the encryption without the key. Finally, WEP uses a very poor message integrity code.
All of that said, WEP is a good place to look to learn the mechanics of security in 802.11, as the later and better security additions replaced the broken pieces but did not destroy the framework.
| Note |
It is the author's recommendation to not use WEP in existing or new networks, under any circumstances, because of the known flaws. Please consider the studying of WEP to be an academic exercise at this point, and do not allow vendors to talk you into using it.
|
1) Keying
WEP starts off with an encryption key, or a piece of knowledge that is known by the access point and the client but is sufficiently complicated that outsiders—attackers, that is— shouldn't be able to guess it.
There is one and may be two or more WEP keys. These keys are each either 40 bits (WEP-40) or 104-bits (WEP-104) long, and are usually created usually from text passwords, although they can be entered directly as hexadecimal numbers. Manually entered keys are called pre-shared keys (PSK). WEP provides very little signaling to designate that encryption is in use, and there is no way to denote whether the short or long keys are being used. If any security, at all, is used in the network, the "Privacy" flag in the network's beacons are set. Clients that want to use WEP had to associate to the network and start sending encrypted traffic. If the keys matched, the network made forward progress and the user was happy. If the keys did not match, the user would not be able to do much, but would otherwise not know what the error was. As you can see, this is not an ideal situation, and is avoided in the modern, post-WEP protocols.
There are some more complicated possibilities, which are not worth going over, except to note that the origin of the confusing 802.11 term "authentication" for the first phase of a client's connection to the network came from an old method of using WEP to verify the key before association. This security method is completely ignored by post-WEP protocols, which use a different concept to ensure that clients have the right key. Therefore, the two Authentication frames are now considered vestigial, and carry no particularly useful information in them.
2) Encryption
The encryption key is not used directly to encrypt each packet. Instead, it is concatenated with a per-packet number, called the initialization vector (IV), to create the key that RC4 uses to encrypt the data. The initialization vector can be any number. Transmitters would start at zero, and add one for each frame sent, until it hit the end of the three-byte sequence, where it would start over at zero again. Why have a per-packet key, when the original key was supposedly secret? To answer this, let's look at the encryption algorithm for WEP, which is based on RC4.
RC4 is a stream cipher, meaning that it is designed to protect a large quantity of flowing, uninterrupted data, with minimal overhead. It is used, for example, to protect secure web traffic (HTTPS), because web traffic goes across in a stream of HTML. RC4 is really a pseudorandom number generator, with cryptographic properties to ensure that the stream of bits that comes out is hard to reverse-engineer. When given a key, RC4 generates an infinite number of bits, all appearing to be random. These bits are then matched up, bit-by-bit, to the incoming plaintext, or not yet encrypted, data. Each bit of the plaintext is added to each matching bit of the RC4 stream, without carry. This is also known as taking the exclusive or of two bits, and the logic goes that the resulting "sum" bit is 1 if either of the incoming bits are 0, and 0 otherwise. The mathematical operation is represented by the ⊕ symbol, and so the four possibilities for the exclusive or are as follows: 0 ⊕ 0 = 0, 0 ⊕ 1 = 1, 1 ⊕ 0 = 1, and 1 ⊕ 1 = 0. When applied to the plaintext and RC4 together, the resulting stream looks as random as the original RC4 stream, but has the real data in it. Only a receiver with the right key can recreate the RC4 stream, do the same bitwise exclusive or to the encrypted data, and recover the original data. (The exclusive or operation has the property that any number that has any other number added twice provides the same number back: n ⊕ d ⊕ d = n. Therefore, applying the exclusive or of the RC4 stream twice to the original data, once by the encryption algorithm and once by the decryption algorithm, gets the plaintext data back.)
So far, so good. However, an attacker can use the properties of the exclusive or to recover the plaintext in certain cases, as well. If two frames come using the same per-frame key— meaning the same IV and WEP key—an eavesdropper can just add the two encrypted frames together. Both frames have the same per-frame key, so they both have the same RC4 stream, causing the exclusive or of the two encrypted frames to cancel out the identical RC4 stream and leave just the exclusive or of the two original, plaintext frames. The exclusive or of two plaintext frames isn't terribly different from having the original plaintext: the attacker can usually guess at the contents of one of the frames and make quick work discovering the contents of the other.
This isn't a flaw with RC4 itself, as it is with using any exclusive or cipher—a type of linear cipher, because ⊕ is really addition modulo 2—as they are vulnerable to bit-by-bit attacks unless other algorithms are brought in as well.
Okay, so that explains the per-frame keying and the IV, and why it is not a good solution for security. In summary, replays are allowed, and the IV wraps and key reuse reveals the original plaintext. Finally, the per-frame key doesn't include any information about the sender or receiver. Thus, an attacker can take the encrypted content from one device and inject it as if it were from another. With that, three of the problems of WEP are exposed. But the per-frame keying concept in general is sound.
3) Integrity
To attempt to provide integrity, WEP also introduces the integrity check value (ICV). This is a checksum of the decrypted data—CRC-32, specifically—that is appended to the end of the data and encrypted with it. The idea is that an attacker might want to capture an encrypted frame, make possibly trivial modifications to it (flipping bits or setting specific bits to 0 or 1), and then send it on. Why would the attacker want to do this? Most active attacks, or those that involve an attacker sending its own frames, require some sort of iterative process. The attacker takes a legitimate frame that someone else sends, makes a slight modification, and sees if that too produces a valid frame. It discovers if the frame was valid by looking for some sort of feedback—an encrypted frame in the other direction—from the receiver. As mentioned earlier, RC4 is especially vulnerable to bit flipping, because a flipped bit in the encrypted data results in the flipping of the same bit in the decrypted data. The ICV is charged with detecting when the encrypted data has been modified, because the checksum should hopefully be different for a modified frame, and the frame could be dropped for not matching its ICV.
As mentioned before, however, WEP did not get this right, either. CRC-32 is not cryptographically secure. The effect of a bit flip on the data for a CRC is known. An attacker can flip the appropriate bits in the encrypted data, and know which bits also need to be flipped in the CRC-32 ICV to arrive at another, valid CRC-32, without knowing what the original CRC-32 was. Therefore, attackers can make modifications pretty much at will and get away with it, without needing the key. But again, the concept of a per-framemessage integrity code in general is sound.
4) Overall
WEP alters the data packet, then, by appending the ICV, then encrypting the data field, then prepending the unencrypted IV. Thus, the frame body is replaced with what is in Table 1.
IV
|
Key ID
|
Data
|
ICV
|
|---|---|---|---|
3 bytes
|
1 byte
|
n—8 bytes
|
4 bytes
|
The issues described are not unique to RC4, and really applies to how WEP would use any linear cipher. There are also some problems with RC4 itself that come out with the way RC4 is used in WEP, which do not come out in RC4's other applications. All in all, WEP used some of the right concepts, but a perfect storm of execution errors undermined WEP's effectiveness. Researchers and attackers started publishing what became an avalanche of writings on the vulnerability of WEP. Wi-Fi was at risk of becoming known as hopelessly broken, and drastic action was needed. Thus, the industry came together and designed 802. Hi.
No comments:
Post a Comment