By Kevin Beaver, Peter T. Davis, Devin K. Akin

Security researchers have discovered security problems that let malicious users compromise the security of WLANs (wireless local area network) that use WEP (Wired Equivalent Privacy) — these, for instance:

  • Passive attacks to decrypt traffic:These are based on statistical analysis.
  • Active attacks to inject new traffic from unauthorized mobile stations:These are based on known plaintext.
  • Active attacks to decrypt traffic: These are based on tricking the access point.
  • Dictionary-building attacks: These are possible after analyzing enough traffic on a busy network.

The biggest problem with WEP is when the installer doesn’t enable it in the first place. Even bad security is generally better than no security.

When people do use WEP, they forget to change their keys periodically. Having many clients in a wireless network — potentially sharing the identical key for long periods of time — is a well-known security vulnerability. If you keep your key long enough, someone can grab all the frames he needs to crack it.

Can’t blame most access-point administrators for not changing keys — after all, the WEP protocol doesn’t offer any key management provisions. But the situation is dangerous: When someone in your organization loses a laptop for any reason, the key could become compromised — along with all the other computers sharing the key. So it’s worth repeating . . .

Shared keys can compromise a wireless network. As the number of people sharing the key grows, so does the security risk. A fundamental tenet of cryptography is that the security of a system is largely dependent on the secrecy of the keys. Expose the keys and you expose the text. Share the key, and a cracker only has to crack it once. Moreover, when every station uses the same key, an eavesdropper has ready access to a large amount of traffic for analytic attacks.

As if key management problems weren’t enough, you have other problems with the WEP algorithm. Check out these bugbears in the WEP initialization vector:

  • The IV is too small and in cleartext. It’s a 24-bit field sent in the cleartext portion of a message. This 24-bit string, used to initialize the key stream generated by the RC4 algorithm, is a relatively small field when used for cryptographic purposes.
  • The IV is static. Reuse of the same IV produces identical key streams for the protection of data, and because the IV is short, it guarantees that those streams will repeat after a relatively short time (between 5 and 7 hours) on a busy network.
  • The IV makes the key stream vulnerable. The 802.11 standard does not specify how the IVs are set or changed, and individual wireless adapters from the same vendor may all generate the same IV sequences, or some wireless adapters may possibly use a constant IV. As a result, hackers can record network traffic, determine the key stream, and use it to decrypt the ciphertext.
  • The IV is a part of the RC4 encryption key. The fact that an eavesdropper knows 24-bits of every packet key, combined with a weakness in the RC4 key schedule, leads to a successful analytic attack that recovers the key after intercepting and analyzing only a relatively small amount of traffic. Such an attack is so nearly a no-brainer that it’s publicly available as an attack script and as open-source code.
  • WEP provides no cryptographic integrity protection. However, the 802.11 MAC protocol uses a non-cryptographic Cyclic Redundancy Check (CRC) to check the integrity of packets, and acknowledges packets that have the correct checksum. The combination of non-cryptographic checksums with stream ciphers is dangerous — and often introduces vulnerabilities. The classic case? You guessed it: WEP.

    There is an active attack that permits the attacker to decrypt any packet by systematically modifying the packet, and CRC sending it to the AP and noting whether the packet is acknowledged. These kinds of attacks are often subtle, and it is now considered risky to design encryption protocols that do not include cryptographic integrity protection, because of the possibility of interactions with other protocol levels that can give away information about ciphertext.

    Only one of the problems listed above depends on a weakness in the cryptographic algorithm. Therefore substituting a stronger stream cipher will not help. For example, the vulnerability of the key stream is a consequence of a weakness in the implementation of the RC4 stream cipher — and that’s exposed by a poorly designed protocol.

    One flaw in the implementation of the RC4 cipher in WEP is the fact that the 802.11 protocol does not specify how to generate IVs. Remember that IVs are the 24-bit values that are pre-pended to the secret key and used in the RC4 cipher. The IV is transmitted in plaintext. The reason we have IVs is to ensure that the value used as a seed for the RC4 PRNG is always different.

    RC4 is quite clear in its requirement that you should never, ever reuse a secret key. The problem with WEP is that there is no guidance on how to implement IVs.

    Microsoft uses the RC4 stream cipher in Word and Excel — and makes the mistake of using the same keystream to encrypt two different documents. So you can break Word and Excel encryption by XORing the two ciphertext streams together to get the keystream to dropsout. Using the key stream, you can easily recover the two plaintexts by using letter-frequency analysis and other basic techniques. You’d think Microsoft would learn. But they made the same mistake in 1999 with the Windows NT Syskey.

    The key, whether it’s 64 or 128 bits, is a combination of a shared secret and the IV. The IV is a 24-bit binary number. Do we choose IV values randomly? Do we start at 0 and increment by 1? Or do we start at 16,777,215 and decrement by 1? Most implementations of WEP initialize hardware using an IV of 0; and increment by 1 for each packet sent. Because every packet requires a unique seed for RC4, you can see that at higher volumes, the entire 24-bit space can be used up in a matter of hours. Therefore we are forced to repeat IVs — and to violate RC4’s cardinal rule against ever repeating keys. Ask Microsoft what happens when you do. Statistical analysis shows that all possible IVs (224) are exhausted in about 5 hours. Then the IV re-initializes, starting at 0, every 5 hours.

    Leave a Reply

    Please log in using one of these methods to post your comment:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out /  Change )

    Google photo

    You are commenting using your Google account. Log Out /  Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out /  Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out /  Change )

    Connecting to %s

    This site uses Akismet to reduce spam. Learn how your comment data is processed.