|
|
Wireless Security: Where WEP Went WrongIEEE 802.11 (or "802.11", for brevity), also known as Wi-Fi, was developed as a way to network disparate computing devices over relatively short physical distances. Like Ethernet, 802.11 provides a standard "physical" layer for devices to network over via various network protocols—like TCP/IP . But unlike Ethernet, the physical layer isn't as physical, and packets flying through the air are more prone to being intercepted than those flying down a wire. To lower the security risk of Wi-Fi, the IEEE added the WEP (Wired Equivalent Privacy) to the 802.11 standard. WEP's goal was to provide confidentiality, protect access to the network infrastructure by rejecting all non-WEP packets, and providing data integrity. There's just one problem with Wired Equivalent Privacy: It isn't. That's why WEP has been succeeded by WPA (Wi-Fi-Protected Access), which we'll look at in detail in our next article. But since so many WEP-based 802.11 networks have already been deployed, WEP's security gaps remain a significant security issue for many organizations. WEP uses a secret key shared between the communicators. Some versions use the 40-bit key that was originally used to formulate the standard, while other newer versions use a 128-bit (104 in reality) key.The actual encryption/decryption process used in WEP looks like this:The data frame is checksummed (using the CRC-32 algorithm) to obtain c(M); where M is the message. M and c(M) are concatenated to get the plaintext P=(M, c(M))P is encrypted using the RC4 algorithm. This generates a keystream as a function of the initialization vector (IV) v and the secret key k; which is notated as RC4 (v, k). The ciphezrtext results from applying the XOR (exclusive-or) function to the plaintext and the keystream. The ciphertext and the IV are then transmitted via radio.Decryption is just the reverse of encryption. The recipient regenerates the keystream and XORs it against the ciphertext to recover the initial plaintext. This message (P') is then split into the two parts of M' and c'. c(M') is then computed and compared with the received checksum c'. If it does not match, the message body has changed in some manner during transmission. Decryption generates the identical keystream used for encryption using the transmitted-with-the-packet IV and the shared secret key. The result is finally XORed with the ciphertext to reveal the message.WEPbusters Come CallingIt can be seen from the above that security is mathematically dependent on the secret key, and its resistance to discovery. But Nikita Borisov, Ian Goldberg and David Wagner presented a paper to the Mac-Crypto conference in January of 2001 that detailed 802.11's architectural security vulnerabilities. I draw heavily from that paper to explain what they found.The authors noted that stream ciphers (like RC4) are vulnerable if two messages are encrypted with the same IV and secret key. If the ciphertexts are XORed together, the keystream will cancel out and the XOR of the two plaintexts are left. In usual messages, there is duplication of plaintext which then can lead to the solving the XOR of the two. One might look for some known plaintext ("Password:" for example) which when XORed with itself computes to the text in the XOR of the two plaintexts. So, if the keystream is reused between messages, an attacker who has only partial knowledge of the plaintext has another chance to compromise the encryption.The authors realized that while the WEP standard recommends the IV (and hence the RC4 of that IV combined with the secret key) change after every packet, it does not require that this happen. Indeed, they found that in some PCMIA 802.11 cards they tested (Lucent's, for example) the IV reset to zero upon initializing and then just incremented a counter by one for every packet transmitted. Since initialization occurs every time the card is inserted into the laptop, this means that keystreams with IVs of a low value will occur frequently and would be identical for the lifetime of the secret key. An attacker would thus have multiple instantiations of the low-IV keystreams to use in his cracking efforts. Reuse is a widely known vulnerability of keystreams, and probably should have been addressed in the 802.11 standard so that a card manufacturer could not have used such a scheme and still be able to meet the standard.There are other architectural problems in 802.11. One of the most insidious is that the IV dataspace is only 24 bits wide. The problem may not become apparent until one considers that a 5Mbps network access point will go through 24 bits worth of packets in less than half a day. This means that the IV would routinely (and somewhat predictably) repeat even if low value IVs were not present in the dataflow. This is not comforting from a security viewpoint.The Reuse ExploitTwo packets encrypted with the same IV can be decrypted if the attacker knows the plaintext of one of them. Since most IP traffic is structured in a well-known manner, an attacker can make certain assumptions about a message and see if they fit the packets at hand. If the attacker has the full plaintext already available (say, if the attacker sends you e-mail and then waits for you to read it over an 802.11 link), the attack becomes trivial. The attacker needs a known plaintext to exploit the key reuse. To get this, he may build a "dictionary" of keystreams vs. IVs. Since the keyspace is 2 raised to the 24th power, that means the entire dictionary would occupy 1500 bytes (the average 802.11 keystream length) times 2 to the 24th, or about 24GB. That will fit on many current hard drives with room to spare. It just takes time and effort. Note that this sort of attack is not affected by length of the secret key, only the 24 bits length of the IV.Key Management IssuesThe 802.11 standard is mute on secret key management. As a result, most networks use a single key for 802.11, even though an optional key identifier field that specifies the index in the array of the key is present in a message. The field doesn't seem to be used in current practice, though that may change once the architectural vulnerabilities become more widely disseminated.The single key makes all of the previously described attacks easier to perform, especially with multiple users all sharing the secret key. And in the event of a key compromise, all users must replace their system drivers since all of them will have been compromised. This can be hard to manage and take time to effect, all of which favors the attacker.WEP Message AuthenticationI've mentioned the CRC-32 checksum performed on a message under WEP. It is supposed to function as a message integrity guarantor. It doesn't. CRC-32 is not immune to malicious attacks.Let's look at some checksum properties first. •The checksum is a linear function of the message. That is, it distributes evenly over the entire XOR operation on the message. This implies that there are ways to control the checksum so that it is acceptable to the protocol, but unlinked from the message content. Indeed, the authors offer a mathematical proof of this in their paper. Also, this sort of attack can be performed with only a partial knowledge of the packet content. So, a checksum can be fooled. It is not a guarantor of authentication. •The checksum is an unkeyed function. That is, it does not depend on the shared secret key. If the attacker knows the plaintext of the message, he can derive the CRC without knowing the shared key.The only way around this is to require a keyed message authentication code such as SHA-1/HMAC, which the 802.11 standard does not. An attack derived from a known plaintext can only succeed because of another WEP property, below. •IV values can be reused without the receiver knowing it. We've discussed this earlier; but it remains a fault of the standard.Using the Access Point to Crack WEPModifying packets is the mechanism that enables another sophisticated attack, which uses the physical access point to decrypt encoded messages. The IP redirection exploit is relatively simple in practice. First, the attacker sniffs an encrypted packet from the radiostream and then modifies it so that the packet is now sent to a controlled IP address. It will be sent in the clear because the access point decrypts it before it is sent out to the Internet.Changing an IP address is not that hard, computationally. If the high and low 16 bit words of the original IP address are Dh and Dl, we want to change them to Dh' and Dl'. If X is the original IP checksum, thenX' = X + Dh' +Dl'-Dh-Dl in one's complement math.If the attacker knows X by some means, he then figures out X as above and computes [X (XOR) X'] to get the checksum of the IP to which we want to redirect the packet. That's the simplest case. One may also make educated guesses about the IP address and see if they work. This is a reaction attack, in that the attack works by seeing what the reaction of the system is to forgeries. A correctly guessed IP will be accepted by the system, while a bad one causes the packet to be dropped into the bit bucket. This only works on TCP packets, because the attacker needs the acknowledgement that TCP sends (the TCP ACK packet is of a standard size) when the TCP checksum is correct. All of this shows the truth of the assertion that checksums are not a good way to guarantee message authentication. A message can be changed, and a new checksum for the forgery inserted without the system any wiser. A keyed function like a MAC could have prevented this sort of attack.So How Does It Get Fixed?It took a few years, but WPA was devised to address the faults of WEP. WPA deserves an article by itself. But, to appreciate it (as well as understand WEP and its vulnerabilities when a user enables it) one should appreciate just where and how WEP became vulnerable. Those who forget history are doomed to repeat it, as that guy said.
|
|
|
Data Protection Virtual Tradeshow
Available On-Demand
Join Cameron Crotty and experts as they explore best practices and solutions needed to maintain a secure flow of data.
|
|
|
