WEP is seriously flawed in this respect. Administration of WEP keys is not well designed and difficult to do on large networks. Users tend to change keys very infrequently which gives a potential hacker lots of time to collect enough packets to launch an attack.
WEP does have a message integrity check but hackers can change messages and recompute a new value to match. This makes the checking ineffective against tampering. Although WEP is far from an ideal security solution you should still use it. Some security is better than none. A determined attacker may be able to discover your keys given time and enough weak IVs, but thats no reason to leave all of your doors open. Check if your equipment manufacturer has an updated driver that avoids sending weak IVs.
Use bit encryption if your equipment supports it. Change the key if there is any suspicion of an attack. If your router or its firmware is of relatively recent vintage within the last months , it may support WPA2, which provides further improvements over WPA, including using AES encryption by default. Eric Geier is a freelance tech writer. Now Trending. What is WPA3? Note that our attacks apply to both bit and the so-called bit versions of WEP equally well.
They also apply to networks that use The A secondary function of WEP is to prevent unauthorized access to a wireless network; this function is not an explicit goal in the WEP relies on a secret key that is shared between a mobile station eg. The secret key is used to encrypt packets before they are transmitted, and an integrity check is used to ensure that packets are not modified in transit.
The standard does not discuss how the shared key is established. In practice, most installations use a single key that is shared between all mobile stations and access points. More sophisticated key management techniques can be used to help defend from the attacks we describe; however, no commercial system we are aware of has mechanisms to support such techniques. The following two sections describe the problems in the algorithm and the technical details of our attacks; they assume some background understanding of cryptographic protocols.
You may wish to skip to the following section, which discusses the practicality of the attacks. WEP uses the RC4 encryption algorithm, which is known as a stream cipher. A stream cipher operates by expanding a short key into an infinite pseudo-random key stream. The sender XORs the key stream with the plaintext to produce ciphertext.
The receiver has a copy of the same key, and uses it to generate identical key stream. XORing the key stream with the ciphertext yields the original plaintext. This mode of operation makes stream ciphers vulnerable to several attacks.
If an attacker flips a bit in the ciphertext, then upon decryption, the corresponding bit in the plaintext will be flipped. Also, if an eavesdropper intercepts two ciphertexts encrypted with the same key stream, it is possible to obtain the XOR of the two plaintexts.
Knowledge of this XOR can enable statistical attacks to recover the plaintexts. The statistical attacks become increasingly practical as more ciphertexts that use the same key stream are known. It may also be done by allowing access to anyone who can prove he has possession of a certificate or some other electronic pass.
IEEE However, identification of devices is only done by MAC address, so there is an implication that a list of acceptable MAC addresses exists somewhere. Many systems implement a simple scheme whereby a list of allowed MAC addresses can be entered into the access point, even when you are operating without WEP. However, given the ease with which MAC addresses can be forged, this cannot be considered as a serious security mechanism.
If the mobile station doesn't know the correct WEP key, then the frames it sends will produce an ICV error when decrypted. Therefore, the frames will be discarded and, effectively, the device is denied access. This last line of defense is really all that the original IEEE Let's suppose you are an attacker with a wireless sniffer that is able to capture all the frames sent between an access point and a mobile device.
You observe that a new user has turned on her laptop and connected to the network. Maybe the first thing that happens is that the server sends her a login message and she enters her user name and password.
Of course, you can't see the actual messages because they are encrypted. However, you might be able to guess what's going on, based on the length of the messages. Later on, you notice the user has shut down and gone home. So now is your chance. Bring up your own client using her MAC address and connect to the network. As we have seen earlier, that part is easy. Now, if you are lucky, you'll receive a message to log in.
Again, you won't be able to decode it, but you can guess what it is from the size. So now you send a copy of the message the legitimate user sent at that point. You are replaying an old message without needing to know the contents. If there were no replay protection, the access point would correctly decode the message; after all, it was originally encrypted with a valid key before you recorded it.
The access point passes the message to the login server, which accepts it as a valid login. You, as an attacker, just successfully logged into the network and the server. It's not clear where you would go from there. However, from a security standpoint, this is a serious breach. There are many other examples in which a replay attack can breach security unless the network is designed specifically to detect and reject old copies of messages.
The wireless security protocol should allow only one copy of a message to be accepted. By this time, it may come as no surprise to discover that WEP has no protection against replay at all. It was just not considered in the design. There is a sequence number in the MAC frame that must increase monotonically.
However, it is not included in the WEP protection so it is easy to modify the sequence number to be valid without messing with the encrypted portion on the frame.
WEP has a mechanism that is designed to prevent message modification. Message modification can be used in subtle ways. The first thing people think about when message modification is proposed is to change the contents of the message in an obvious way. For example, changing the destination bank account number on a deposit or changing the amount transferred.
However, in reality such large-scale modifications would be very hard to mount and assume that you can read the original message and effectively forge new messages. If you are unable to decrypt the message, it is not obvious how modifying the ciphertext would be useful. However, even in this case modifications can be used to extract information. A technical paper by Borisov et al. They pointed out that the position of the IP header is usually known after encryption because WEP does not rearrange the byte positions.
Because the IP header has a checksum, changing one bit in the header causes the checksum to fail. However, if you also change bits in the checksum, you might get a match.
The researchers showed that, by flipping a few bits at a time and seeing whether the IP frame was accepted, based on whether responses came back, they could eventually decode portions of a frame. We looked at this briefly in the previous section on frame formats. The idea behind the ICV is simple: compute a check value or CRC cyclic redundancy check over all the data to be encrypted, append the check value to the end of the data, and then encrypt the whole lot.
If someone changes a bit in the ciphertext, the decrypted data will not have the same check word and the modification will be detected. The thinking is that, because the ICV is encrypted, you cannot go back and correct its value to compensate for the other changes you have made.
It is only intended to provide protection to the ciphertext. If an attacker already knows the keys, he can modify the data and recompute the ICV before re-encrypting and forwarding the frame. So use of the ICV protects the ciphertext from tampering? Wrong again! Borisov et al. It turns out that, with a linear method, you can predict which bits in the ICV will be changed if you change a single bit in the message.
The ICV is 32 bits. Let's suppose the message is 8, bits 1, bytes and you flip bit position You can then compute which bits in the ICV will be changed as a result. It is typically not a single bit but a combination of bits that will change. Note that we used the word "change," not "set" or "clear. Unfortunately, because WEP works by XORing the data to get the ciphertext, bit flipping survives the encryption process. Flipping a bit in the plaintext always flips the same bit in the ciphertext, and vice versa.
If you've hung in through the argument in the last paragraph, you will see that, because of the fact that bit flipping survives encryption; the assumption that the ICV is protected by encryption just doesn't hold water. Its actual value is protected, but you can reliably flip its bits. And because you can work out which bits to flip corresponding to a change in the data, you can completely defeat its protection. With a muffled thump, another of WEP's protections just hit the floor.
The reality is that WEP provides no effective protection against ciphertext modification. This is the big one : attacking the encryption method of WEP. We have seen that the other protections have already been stripped away; but, at the end of the day, if the encryption method holds up, then the attacker is very limited in what he can do. So far, it's just watching shadows or throwing rocks at the window; but if the encryption can be breached, the attacker is inside the house.
There are two main objectives in attacking the encryption: decode a message or get the keys. The ultimate success is to get the keys. Once an attacker has the keys, he is free to explore and look for the valuables. Possession of the keys doesn't automatically mean access to confidential information because there are other layers of security inside, such as server passwords and operating system protections.
However, the issue of network access is put aside. Furthermore, if an attacker can get the keys, he can probably go undetected, which is important to buy the time to find useful information.
If an attack is detected, the WEP keys can be changed, putting the attacker back to square one. The next best thing to getting the keys is to be able to get the plaintext. If you can get the plaintext in a reasonably fast and reliable way, you have access to a range of other types of attacks using message modification and replay.
That information can also be used as a stepping-stone to getting the keys. Walker pointed out a number of potential weaknesses, but especially focused on the issue of IV reuse. Let's quickly review how the IV is used. The value of the IV is sent in the frame so the receiving device can perform the decryption. One purpose of the IV is to ensure that two identical messages don't produce the same ciphertext. Let's suppose for a moment that there was no IV and only the secret key is used for encryption.
For every frame, the RC4 algorithm is initialized with the key value prior to the start of the pseudorandom key stream generation. But if the key were to remain fixed, the RC4 algorithm would be initialized to the same state every time. Therefore the key stream produced would be the same sequence of bytes for every frame. This is disastrous because, if the attacker can figure out what that key stream is, he can decode every frame simply by XORing the frame with the known sequence.
He doesn't need to know the key. By adding the IV value to the key each time, RC4 is initialized to a different state for every frame and so the key stream is different for each encryption?
Let's review that statement because there is an implicit assumption: The IV value is different for every frame. If the IV is a constant value, you are no better off than in the static key case. So we see that constant IV is useless. We can also see that using a different IV for every frame, and I mean every frame, is a good idea.
0コメント