Graphics Programs Reference
In-Depth Information
After an IV collision is discovered, some educated guesses about the
structure of the plaintexts can be used to reveal the original plaintexts by
XORing the two ciphertexts together. Also, if one of the plaintexts is known,
the other plaintext can be recovered with a simple XORing. One method
of obtaining known plaintexts might be through spam email, where the
attacker sends the spam and the victim checks mail over the encrypted
wireless connection.
0x783
IV-Based Decryption Dictionary Tables
After plaintexts are recovered for an intercepted message, the keystream for
that IV will also be known. This means that this keystream can be used to
decrypt any other packet with the same IV, providing it's not longer than the
recovered keystream. Over time, it's possible to create a table of keystreams
indexed by every possible IV. Since there are only 2 24 possible IVs, if 1,500
bytes of keystream are saved for each IV, the table would only require about
24GB of storage. Once a table like this is created, all subsequent encrypted
packets can be easily decrypted.
Realistically, this method of attack would be very time consuming and
tedious. It's an interesting idea, but there are much easier ways to defeat WEP.
0x784
IP Redirection
Another way to decrypt encrypted packets is to trick the access point into
doing all the work. Usually, wireless access points have some form of Internet
connectivity, and if this is the case, an IP redirection attack is possible. First, an
encrypted packet is captured, and the destination address is changed to an
IP address the attacker controls, without decrypting the packet. Then, the
modified packet is sent back to the wireless access point, which will decrypt
the packet and send it right to the attacker's IP address.
The packet modification is made possible due to the CRC32 checksum
being a linear, unkeyed function. This means that the packet can be strate-
gically modified and the checksum will still come out the same.
This attack also assumes that the source and destination IP addresses
are known. This information is easy enough to figure out, just based on
the standard internal network IP addressing schemes. Also, a few cases of
keystream reuse due to IV collisions can be used to determine the addresses.
Once the destination IP address is known, this value can be XORed with
the desired IP address, and this whole thing can be XORed into place in the
encrypted packet. The XORing of the destination IP address will cancel out,
leaving behind the desired IP address XORed with the keystream. Then, to
ensure that the checksum stays the same, the source IP address must be
strategically modified.
For example, assume the source address is 192.168.2.57 and the
destination address is 192.168.2.1. The attacker controls the address
123.45.67.89 and wants to redirect traffic there. These IP addresses
Search WWH ::




Custom Search