From: Andrew Putnam (aputnam@cs.washington.edu)
Date: Wed Nov 24 2004 - 02:57:47 PST
Intercepting Mobile Communications: The insecurity of 802.11
Nikita Borisov, Ian Goldberg, and David Wagner
Summary: The Wired-Equivalency Protocol (WEP) used to provide security
for wireless 802.11 connections is shown to be insecure. Various
methods of defeating the encryption methods are examined and shown to
be very simple and practical.
The authors point out a number of security flaws in WEP that show
WEP to be clearly insufficient for secure wireless communication. The
most disturbing part of this paper is that WEP was developed very
recently, yet it was done so poorly. All of the attacks used to break
WEP are variants of attacks used to break previously proposed
protocols.
There are a number of basic security lessons that have been
extensively mentioned in security literature, yet the WEP design shows
just how difficult these principles are to follow. The first and most
important principle: poor implementation of perfect security mechanisms
leads to an insecure system. Stream cyphers like RC4 are very secure
and extremely difficult to break, but not when implemented using small,
repeated initial value keys. Second: security features that are
difficult to use will frequently go unused. In the case of WEP, the
system administration issues associated with distributing and changing
keys means that administrators rarely change the keys. In light of the
other security vulnerabilities, this apparent workaround becomes
infeasible. Third: public review of encryption protocols is critical.
Had WEP been publicly scrutinized before becoming a standard, many of
the difficulties of revamping a deployed system. Fourth: integrity
checks should always be keyed. If an attacker can calculate the
integrity check, then the integrity of a message cannot be guaranteed.
There is one critical oversight that the WEP designers failed to
realize when developing the WEP standard: making the key length (and IV
length for the stream cypher) a fixed length immediately determines the
protocols date of obsolescence. As technology gets faster and faster,
it becomes easier and easier to break encryption keys. Unless keys are
sufficiently long such that technology would several decades or more to
produce machines capable of breaking encryption keys by brute force,
then the key length must be easily changed. This only impacts backwards
compatibility if adaptability to longer key lengths is not made part of
the protocol standard.
One of the reasons given for using CRCs and stream cyphers is their
speed, which seems necessary when dealing with slow wireless networks.
The authors even acknowledge that this makes CECs and stream cyphers
attractive from an engineering standpoint. I believe that the authors
(and possibly the engineers) are making a false connection between fast
encryption and fast wireless communication. The encryption is done in
the hardware (either the microprocessor or the NIC), where the
encryption can be done quickly. The actual network latency is
relatively independent of the encryption method employed, especially
for slow channels. The only way encryption will significantly slow
communications in a slow channel are if the encryption adds a
significant number of bits to the message. From this perspective, the
speed of the encryption mechanisms is irrelevant to the viability of
the design.
This archive was generated by hypermail 2.1.6 : Wed Nov 24 2004 - 02:57:48 PST