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. However, the WPA attacks required the use of a dictionary and never found the password to the network.
The key does not change with every packet that is transmitted, so a hacker can listen in and, with patience, gather enough packets to decipher the encryption key. This length of a key is not very secure with the amount of computing power that people have in their pockets. WEP is not a good encryption standard; however, it is better than no security. It encrypted all traffic to and from the access point using a static key, which was its downfall.
There's a reason it allows up to 63 characters or 64 hex digits for the key. Use something long and the more random the better. To continue this discussion, please ask a new question. Get answers from your peers along with millions of IT pros who visit Spiceworks.
With that said, please help me figure out the following: I know that it's very easy to hack into a WEP and that's why most users use WPA. Best Answer.
View this "Best Answer" in the replies below ». Popular Topics in Wireless. Spiceworks Help Desk. The help desk software for IT. Track users' IT needs, easily, and with only the features you need.
Learn More ». Thai Pepper. Hank the Hacker This person is a verified professional. Verify your account to enable IT peers to see that you are a professional. Ghost Chili. Doesn't really apply in IT, but I thought it was somewhat interesting. Doughnut This person is a verified professional.
JoeMatuscak This person is a verified professional. Galen in Laguna wrote: and using reaver WPA isnt that hard to hack either That's not really the case. 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. 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.
A recommendation from RSA Labs is to discard the first bytes of the key stream, but of course WEP does not do this and such a change would mean that old systems would no longer interoperate. You might think that this is not so bad. After all, you might not be using a weak key; or if you know which keys are weak, you could avoid them, right? Think again. Remember the IV is added to the secret key.
And the IV is always changing. So sooner or later, the IV guarantees that a weak key is generated. It brings tears to your eyes, doesn't it! But there's worse to come. In their landmark paper, Fluhrer et al. There are two cases, one in which the IV is appended after the secret key and one in which the IV is prepended before the secret key.
The prepend case is the more vulnerable? If you are interested in how the attacks work, get a college degree in mathematics and read the paper. But in overview, the idea is based on exploiting the weak key problem in the first bytes. First assume that you know the plaintext for the first few bytes, which you do for IEEE
0コメント