The best-known encryption for wireless networks (as well as the only type of encrpytion we found being used in Barcelona) is also the least secure. With the right computer and enough traffic, a WEP-based wireless network can be broken in as little as 15 minutes.
WEP can use a 40-bit, 64-bit, or 128-bit encryption key to generate a RC4 key stream. However, findings by Borisov, Goldberg, and Wagner state that there is not even a proportional increase in security as a result of increased key lengths. Some of the encryption standards below seek to fix this problem by eliminating the need for a static key, such as the one used by WEP. As a relevant example, the wireless network we set up at La Ciutat was believed to be hacked by a random traveller with merely a wireless card and simple laptop.
WEP had two good security features designed into its specification. First, in order to avoid hackers modifying the packets sent accross the network, WEP has an Integrity Check (IC) built into the system where the sender adds an IC field to the packet, which is then checked by the receiver (essentially as a checksum) to make sure the packet was not modified. In the specification, this is suppused to be implemented through a CRC-32 checksum. However, the CRC-32 checksum is a linear checksum, meaning all a hacker would have to do is flip the correct number of bits (ie, flipping certain bits to account for any change the hacker descides to make to the packet) and the receiver would never know the difference. As such the actual implementation provides no real benefit to security.
The second good security feature to be designed in was the Initialization Vector (IV). Two separate packets of ciphertext which are encrypted with the same key (from the key stream) provide a very good indicator of what the actual key (the static key that generates the key stream) really is. To prevent this, the IV is used to augment the static key to ensure that the key generated from the key stream is different for each packet. But once again, the design was poorly implemented. Only a 24-bit field was allocated for the IV, meaning that anyone with enough time on their hands can wait until the same IV is used again to attempt to decrypt the packet into plaintext and thus get an idea of what the actual static key is. Thus again, this feature generates very little additional security.
Decrypting Traffic - This kind of attack takes advantage of the Initialization Vector mentioned above. When around an access point with a decent amount of traffic from a single user, the IV key can be broken in five hours. This still provides a decent amount of security if the hacker doesn't have much time, as the hacker would need to get a fair number of packets with the same IV key to decode the actual plaintext, as well as needing a fair number of IV keys in order to determine what the actual key is in order to read that particular user's packets. But, if all the users have the same static key, not only will the hacker be able to read everyone's packets, but redundant IV keys will be a much more common occurence. A much more dangerous tactic is when the hacker sends packets with known plaintext into the network and then analyzes the ciphertext. This allows him or her to break the encryption even faster.
Injecting Traffic - Once a hacker has decrypted a packet and knows its plaintext, he or she can use this to create new packets. These fabricated packets may be injected into the network and anyone who receives the packet will not have the slightest clue that it is fake. A version of this kind of attack is to take advantage of the weakness in the Integrity Check mentioned above. A hacker, without complete knowledge of the network, may change certain bits to change the nature of the packet. Examples of this include changing data (eg, bank account numbers of amounts) or commands (eg, on telnet).
Both Ends - Combining the two attacks listed above, it turns out a hacker merely needs enough information to determine the header of a packet in order to cause significant damage. For example, a hacker could determine the IP header to find out what the destination of the packet is and then take advantage of the CRC-32 checksum flaw to change the destination and route it to an outside computer he controls. Once this packet leaves the wireless network, its is unencrypted. The outside computer can do almost anything to this packet, including forwarding it to the primary destination (with or without changing it) so that the interception it is never detected by the original user.
Table-Based Attack - The hardest and most time consuming of the attacks is the most complete, specifically creating a table of all the possible IV keys and the packets sniffed in order to determine the true IV key for every encrypted packet. This could take a significant amount of time (anywhere from a couple hours to a day or two) and a decent amount of hard drive space (one source said approximately 15 GB). If this is in any way assuring to anyone with a wireless network that WEP provides good enough protection to block all but the most determined hackers, it shouldn't be. There are far more intelligent means of attacks (some are listed above). Table-based attacks therefore are used mainly on other (more secure) systems, primarily wireless networks that are not connected in any way to the internet.
