Cryptography Reference
In-Depth Information
The choice of RC4 was also reasonable at the time, since it was well respected
and widely deployed in other applications, including SSL (although RC4 was
originally a proprietary stream cipher, the details were publicly known by
the time of the design of WEP). It would not be regarded as a good choice
today, since the security of RC4 is no longer regarded as sufficient for modern
applications.
2. A simple
CRC checksum
for data integrity. The problem with this type of
checksum is that, in a similar way to using a hash function on its own to
provide data integrity (see Section 6.2.2), an attacker can modify the data
and then recompute the correct CRC checksum for the modified data. Hence
this checksum can only be relied upon to detect accidental changes to
the data.
3. A simple challenge-response protocol to provide entity authentication.
CONFIDENTIALITY AND INTEGRITY MECHANISMS IN WEP
In many ways, the cryptographic design of WEP was very naive. We now look at
the mechanisms for providing confidentiality and data integrity in more detail,
in order to illustrate some of the design errors.
The first WEP design decision was to use a
shared, fixed symmetric key
in
each WLAN. This same key is used by all devices, for several different purposes,
when communicating using a WEP-secured WLAN. This almost eliminates any
issues regarding key establishment, however, it introduces considerable risks.
In particular, if one of the devices is compromised then this key may become
known to an attacker, and hence the entire network will be compromised. The
original version of WEP only used a 40-bit key, but later adaptations allow much
longer keys.
As discussed in Section 4.2.4, one problemwith deploying a stream cipher such
as RC4 is the need for synchronisation, especially in a potentially noisy channel
such as a wireless one. Thus WEP requires each packet of data to be encrypted
separately, so that loss of a packet does not affect the rest of the data being
sent. This introduces a new problem. In Section 4.2.2 we discussed the negative
consequences of re-using keystream for more than one plaintext. It follows that
WEP requires a mechanism for making sure that the same keystream is not reused
for subsequent packets.
The solution to this problem in WEP was to introduce an initialisation vector
(IV), which just like the IVs used in several of the modes of operation of a block
cipher (see Section 4.6), varies each time the WEP key is used to encrypt a
packet. However, RC4 does not easily allow an IV to be incorporated into the
encryption process, hence the WEP IV is directly appended to the key. In this
way WEP defines a 'per-packet' key, which consists of a 24-bit IV appended to
the WEP key.
If Alice wants to set up a secure WLAN connection with Bob, based on the
shared, fixedWEP key
K
, the encryption process for each packet of data to be sent
is depicted in Figure 12.3 and is as follows.
