Wireless Security.pdf - PDF Archive

Wireless LAN Security 419
Frame
header
40-bit WEP key
24-bit IV
IV header
IV
Pad Key
ID
RC4
algorithm
Encrypted
Frame body
RC4
key stream
ICV
Figure 18.7 : Data integrity in WEP
X
Data ICV
Data
CRC-32
WEP, ICV is implemented as a Cyclic Redundancy Check-32 bits (CRC-32) checksum
which breaks this assumption. The reason for this is that CRC-32 is linear and is not
cryptographically computed, i.e., the calculation of the CRC-32 checksum does not use a
key/shared secret. Also, this means that the CRC32 has the following interesting property:
CRC(X ⊕ Y) CRC(X) ⊕ CRC(Y)
Now, if X represents the payload of the 802.11 packet over which the ICV is calculated,
the ICV is CRC(X) which is appended to the packet. Consider an intruder who wishes
to change the value of X to Z. To do this, they calculate Y X Z. Then she captures
the packet from the air-interface, XORs X with Y and then XORs the ICV with CRC(Y).
Therefore, the packet changes from { X, CRC(X) } to { X Y, CRC(X) CRC(Y) }
or simply { X Y, CRC(X Y) } . If the intruder now re-transmits the packets to the
receiver, the receiver would have no way of telling that the packet was modified in transit.
This means that we can change bits in the payload of the packet while preserving the
integrity of the packet if we also change the corresponding bits in the ICV of the packet.
Note that an attack like the one described above works because flipping bit x in the
message results in a deterministic set of bits in the CRC that must be flipped to produce
the correct checksum of the modified message. This property stems from the linearity of
the CRC32 algorithm.
Realize that even though the ICV is encrypted (cryptographically protected) along
with the rest of the payload in the packet, it is not cryptographically computed; that
is, calculating the ICV does not involve keys and cryptographic operations. Simply
encrypting the ICV does not prevent an attack like the one discussed above. This is so
www.newnespress.com