I know it is very bad practice to reply to one's own posting, but I made an error that I wanted to correct.
When WEP processing occurs, the ICV is calculated as a hash of the clear-text payload of a data packet. The 4-byte ICV is then appended to the data payload, and the payload+ICV is encrypted with RC4.
Following the completion of WEP processing, a CRC-32 hash is calculated as a measure to detect "accidental" frame corruption in transit, not as a security mechanism to protect against tampering. This is known as the frame check sequence or FCS, and is appended to the end of frame, following the encrypted (or unencrypted) payload.
So, guoquan was correct in that the ICV is part of the encrypted payload. Ethereal reports the "not verified" ICV, but it is only reporting the last four encrypted bytes of the payload, not the actual hash value derived from the clear-text payload processing. If you specify the WEP keys that were used to encrypt the traffic before processing the packet with Ethereal, the packet dissector will decrypt and attempt to verify the ICV value on the clear-text data payload.
I was surprised that the FCS was not included at the end of the file, but after reading through the source code for the 802.11 packet dissector I realized that the some drivers do not properly report the FCS to libpcap, and there is no way to know the correct length of the packet - it's not possible to tell if the FCS is present or not. Selecting the "Assume packets have FCS" option will make Ethereal report the last 4 bytes as the FCS, and the previous 4 bytes as the ICV (if the WEP bit is set), but this may or may not be the actual case depending on the driver used to capture the traffic. YMMV.
Thanks to Solomon for writing clear code with great comments in the 802.11 packet dissector.
-Joshua Wright
Senior Network and Security Architect
Johnson & Wales University
Joshua.Wright@xxxxxxx
http://home.jwu.edu/jwright/
pgpkey: http://home.jwu.edu/jwright/pgpkey.htm
fingerprint: FDA5 12FC F391 3740 E0AE BDB6 8FE2 FC0A D44B 4A73
> > i have a question about reading wireless
> > data (802.11b) using ethereal. i suppose that
> > plain text and ICV should be encrypted before
> > being transmitted. But why is ethereal able to
> > display its ICV value? thanks
> >
> > example:
> > WEP ICV: 0x12345678 (not verified)
>
> The ICV is not encrypted, it is just a CRC-32 that is
> appended to the end of the frame, based on the encrypted payload.
