WEP has a number of well-documented vulnerabilities that significantly limit its ability to safeguard data. The problem is the way that RC4 is implemented. In particular, the implementation of IVs is flawed because it allows IVs to be repeated and hence, violate the No. Newsham exposed another vulnerability of WEP by demonstrating that the key generator used by many vendors is flawed for bit key generation.
Using a typical laptop, he was able to crack a bit key is less than a minute. This weakness, exploited by commonly available tools such as AirSnort, WEPCrack and dweputils, has the ability to crack WEP keys by analyzing traffic from totally passive data captures. If your network is consistently generating traffic at peak speeds, the WEP key 64 or bit can be cracked after capturing just a few hours of encrypted data.
On a network with minimal activity, this attack could take days or even weeks to capture the requisite traffic. Some packet injection techniques, however, have the ability to artificially flood the network with activity to reduce the amount of time it takes to collect enough packets for an FMS attack. On the other hand, keep in mind that vendors who include weak key avoidance techniques in their firmware which most do are not vulnerable to FMS attacks.
So, be sure to update your firmware on a periodic basis! These issues don't make WEP useless, it just means that you have to be careful about how and when you use it. If you aren't able to implement anything else such as WPA , and the only thing you have is WEP , then go ahead and use it.
If you're in a network with minimal security requirements, WEP may be appropriate. I recommend using WEP and changing keys on a regular basis, if for no other reason, then because it identifies your network as private.
Since the I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time. Pearson Education, Inc. This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site.
Please note that other Pearson websites and online products and services have their own separate privacy policies. To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:. For inquiries and questions, we collect the inquiry or question, together with name, contact details email address, phone number and mailing address and any other additional information voluntarily submitted to us through a Contact Us form or an email.
We use this information to address the inquiry and respond to the question. To understand WEP's major flaw, let's imagine a company that produces puzzle books. These books are renowned for being filled with incredibly tricky puzzles which require a lot of computational power to solve. Due to the extreme difficulty of the book, people like to collaborate to solve the puzzles. The writers of the book want to fill it with enough content so that they can publish another one before the readers complete the current edition.
If the general public solves the book before the book publishers release a new one, they have to get a new book out ASAP. From these three properties, you can make a rough estimate of how long it will take to solve a whole book.
For example, if it takes a month for one person to solve one puzzle, and the book contains a thousand puzzles, it'll take a dedicated team of one hundred people to solve the book within 10 months. As such, the next book should be ready to go before 10 months has passed. This does mean that the older the puzzle book, the higher the chance that it's solved already. This is especially true for the first few editions of books, which contains easier and fewer puzzles than later versions.
In the same vein, WEP's age makes it an insecure choice for encryption. It was the first protocol created for Wi-Fi, it has been out since , and millions of people have used it since then. From the puzzle book example, WEP would be the very first puzzle book to be released and fully solved.
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. What about the middle ground? There are a limited number of possible IVs so it is acceptable to use a different IV for most frames but eventually start reusing IVs that have been used in the past.
The simple answer is that this is not acceptable? Let's look at why IV reuse is a problem. We have said that the IV should be different for every frame. However, the original IEEE Intuitively you might think that the best approach would be to generate a random value. However, with random selection there is a good chance that you will get a repeating IV quite quickly.
This is known as the birthday paradox see sidebar. In the case of IVs, it means that you are likely to get a duplicate IV sooner than you expect if you pick random values. The best way to allocate IVs is simply to increment the value by 1 each time. This gives you the longest possible time before a repeating value. However, with a bit IV, an IV collision use of a previous value is guaranteed after 2 24 frames have been transmitted nearly 17 million.
At frames a second, the IV space would be all used up in around seven hours. In reality a collision is likely much sooner because there may be many devices transmitting, each incrementing a separate IV value and using it with the same key assuming default keys are in use.
Implementation errors can compound the problem. Imagine that ten users come into work and start up their laptops. Depending on who does what, the IV counter of some will get ahead of others, but there will be a rich harvest of IV collisions to be had by an observer. IV collisions are a fact of life for WEP so let's look again at why collisions are a problem. The Birthday Paradox When you meet someone, there is only a 1 in chance that the person has the same birthday as you.
However, the chance of meeting someone with your birthday increases surprisingly fast as you meet more people. This is a surprising fact, which is probably why it is called a paradox. If you know the key stream corresponding to a given IV value, you can immediately decode any subsequent frame that uses the same IV and secret key.
This is true regardless of whether the secret key is 40 bits, bits, or 1, bits. To decode every message, you would have to know the key stream for every possible IV value. Because there are nearly 17 million possible IV values, that seems like a daunting task.
However, it's not impossible: If you want to store a 1,byte key stream, for every possible IV you need a storage space of 23Gbytes?
With such a database, you could decode every message sent without ever knowing the secret key. However, you still have to find out all those key streams and that's not so easy. Suppose you have captured two messages encrypted using the same IV and secret key. You know that the key stream is the same in both cases, although you don't know what it is yet. Using our simple notation:.
This is true because XORing the same value twice takes you back to your original value. So the attacker now has a message that is the XOR of two plaintexts. Is that useful? No not yet. However, some of the values of plaintext are definitely known, such as certain fields in the header. In other fields the value is not known, but the purpose is known. For example, the IP address fields have a limited set of possible values in most networks.
Over a period of time, if you collect enough samples of duplicated IVs, you can probably guess substantial portions of the key stream and hence decode more and more. It's like a collapsing building: Each block you knock away makes it more likely that the whole lot will fall down. It's hacker's celebrity squares in which you have some of the letters in a word and you try to guess the whole sentence.
But once you succeed for a given IV, you can decode every subsequent frame using that IV and generate forged frames using the same IV. All without knowing the key. However, it was not considered a major threat to everyday use. After all, it would take a huge effort to decode a significant number of frames and the need for intelligence in guessing the plaintext makes it hard to create an automatic script tool. So the cryptographers cringed and the manufacturers worried, but the world went on after this attack was publicized.
But there was worse to come. The fundamental part of RC4 is not encryption but pseudorandom number generation. Once we have a string of pseudorandom bytes, we can use them to encrypt the data by the XOR function. As we have seen, using this simple XOR function is a source of weakness if it is not applied correctly; but for the moment, let's concentrate on the pseudorandom sequence, or key stream. RC4 works by setting up a byte array containing all the values from 0 to That is, each value from 0 to appears once and only once in the array.
However, the order in which they appear is "randomized. What's more, the values are reorganized continuously as each pseudorandom byte is generated so there is a different permutation of the array each time. Each pseudorandom byte is generated by picking a single value from the permutation based on two index values, i and j , which also change each time. There are very many permutations or arrangements of values that can be made. This property of RC4 makes it very powerful despite its simple implementation.
It is amazingly hard to distinguish an RC4 pseudorandom sequence from a real random sequence. RC4 has been studied by many cryptographers and yet the best known method for distinguishing an RC4 stream from true random data requires a continuous sample of 1Gbyte of the stream before it can reliably decide that the stream was generated by RC4.
The phrase "once it gets going" in the last sentence is important. It signals the fact that RC4 has a potential weakness. To understand the weakness, let's quickly review how RC4 works. First it creates a table the S-box with all the values 0? Then it creates a second byte table with the key, repeated over and over until the table is full. Then it rearranges the S-box based on values in the key table. This is the initialization phase.
The first pseudorandom byte is generated by rearranging the S-box again and picking a byte. The problem here is that there are not many rearrangements between the initial setup of the key table and the first pseudorandom byte.
Fluhrer et al. Let's look at this weakness in another way : Ideally if you change any one bit in the key, then the output key stream should be totally different. The paper showed that this was not the case.
Some bits of the key had a bigger effect than others. Some bits had no effect at all on the first few bytes of key stream. This is bad for two reasons. First, if you reduce the number of effective bits, it is easier to attack the keys. Second, the first few bytes of plaintext are usually easier to guess. If you know the plaintext, you can derive the key stream and start attacking the key. There is a very simple way to avoid the weakness: Discard the first few bytes of the RC4 key stream.
In other words, wait until the RC4 algorithm gets going before starting to use the output. It was introduced as a part of the original As an early-day solution, its goal was to prevent Man-in-the-Middle attacks, which it did for a time. WEP encrypts all traffic using a 64 or bit key in hexadecimal. This is a static key, which means all traffic, no matter the device, is encrypted using the single key. This protocol stood up for a while until the computing power in everyday computers grew with the improvements in IPC and clock speeds of processors.
At this point, the standard was considered insecure and was deprecated. The WEP attack took maybe 5 minutes and was able to penetrate the network, all at the hands of a class of high schoolers.
0コメント