WEP Weaknesses

Security researchers have discovered security problems that let malicious
users compromise the security of WLANs that use WEP — 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.