From: Michael J Cafarella (mjc@cs.washington.edu)
Date: Mon Nov 22 2004 - 15:36:05 PST
Intercepting Mobile Communications: The Insecurity of 802.11
By Borisov, Goldberg, Wagner
Review by Michael Cafarella
CSE561
November 24, 2004
The authors describe a series of problems with 802.11's WEP system.
WEP is designed to encrypt wireless traffic so that nearby receivers
cannot overhear ongoing WiFi traffic. There are two problem areas
with WEP: the keystream system for encrypting traffic, and the
CRC-32 checksum for checking message integrity.
The keystream is a sequence of randomly-generated bytes that are used
to XOR the plaintext, thus encrypting it. It's generated using the private
key and something called the intialization vector. While keys can be up
to 128 bits long, the initialization vector is fixed at 24 bits. Further,
the standard offers no guidance as to how to choose an i.v. Many tested
systems simply use an incrementing counter that starts at 0.
When an attacker can guess an i.v and plaintext pair, it becomes very
easy to compromise the keystream. The attacker can then decrypt any
message computed using that keystream. The length of the key now provides
no extra security, as the attacker can obtain a number of keystreams without
any reference to the key at all.
The CRC-32 checksum is designed to catch transmission errors, not guarantee
a message against modification by a foe. We saw in a recent homework that
it's possible to intelligently modify a message without changing the checksum!
Cryptographic-strength checksum algorithms are designed so that minor
peturbations in the plaintext result in very different output hashes.
The technical problems with WEP are very interesting, and the authors do a
good job at explaining what could go wrong.
However, the paper also tries to make a broader point about engineering
security. The engineers for 802.11 made mistakes that were well-known
in the security community. For example, most security researchers consider
keystream-based approaches to be so difficult to use properly that they
are best avoided altogether. If the 802.11 authors had been more concerned
with security, had made the specification more freely available, and had
sought help with security-related matters, 802.11 would have been better
for it.
This paper I think is most useful for political and social reasons, rather
than technical. None of the technical observations have much use beyond their
application to the now-dying WEP standard. But if the authors can use the
chance to improve general protocol security practices, it will have been a
very helpful contribution.
This archive was generated by hypermail 2.1.6 : Mon Nov 22 2004 - 15:36:06 PST