TKIP was designed to run on WEP hardware without slowing the hardware down significantly. To do this, TKIP is a preprocessing step before WEP encryption. RC4 is still the encryption algorithm, and the WEP CRC-32 could not be eliminated. However, TKIP adds features into the selection of the per-frame key, and introduces a new MIC to sit beside the CRC-32 and provide better integrity.
The first change is to expand the IV and key ID fields to eight bytes total (see Table 1). The expanded fields gives a six-byte IV, now called the TKIP sequence counter(TSC). The goal is to give plenty of room so that the TSC nearly never needs to wrap. Furthermore, if it does get close to wrapping, the client is required to renegotiate a new PTK. This prevents key reuse. Finally, the TSC is used to provide the replay protection missing in WEP. The TSC is required to go up by one for each message. Each side keeps the current TSC that it is sending with, and the one it last received successfully from the other side. If a frame comes in out of order—that is, if it is received with an old TSC—the receiver drops it. An attacker can no longer replay valid but old frames. And, of course, although it can try to invent new frames, even with higher TSCs, the receiver won't update the last good TSC unless the frame is decryptable, and it will not be because the attacker does not know the key.
Expanded IV | Data | MIC | ICV |
|---|---|---|---|
8 bytes | n - 8 bytes | 8 bytes | 4 bytes |
The second change is to come up with a better way of producing the per-frame key. The per-frame key for TKIP uses a new algorithm that takes into account not only the now larger IV and the PTK, but the transmitter's address as well. This algorithm uses a cryptographic device known as an S-box to spread out the per-frame key in a more even, random-looking pattern. This helps avoid the problems with weak RC4 per-frame keys, which were specific WEP per-frame keys that caused RC4 to leak information. The result of this algorithm is a brand new per-frame key for each frame, which avoids many of the problems with WEP.
Unfortunately, the underlying encryption is still WEP, using a linear cipher vulnerable to bit flipping. To catch more of the bit flips, a new, cryptographically "better" MIC was needed. WPA uses Michael, a special MIC designed to help with TKIP without requiring excessive computation. It is not considered to be cryptographically secure in the same sense as is WPA2, but is considered to be significantly better than CRC-32, and thus can be used to build secure networks with some caveats. In this case, the designers were aware of this limitation up front, and designed Michael to be good enough to provide that transition from WEP to something more secure down the road (which became AES).
The Michael MIC is not just a function of the data of the packet. It also depends on the sender's address, the receiver's address, and the priority of the packet, as well as the PTK. Michael is designed to avoid the iterative guessing and bit flipping that WEP is vulnerable to. Furthermore, it is based on the entire frame, and not just individual fragments, and so avoids some fragmentation attacks that can be used against WEP. The result of Michael is the eight-byte MIC, which is placed at the end of the frame before it is sent for WEP encryption.
Because the designers know that Michael isn't enough, they also built in a provision for detecting when an attack is under way. Attackers try to modify frames and submit them, and see if the modified frames get mistaken as being authentic. Most of the time, they fail, and these modified frames are not decryptable. With WEP, a nondecryptable frame is silently dropped, with no harm. However, a frame with a bad MIC should never happen in a properly functioning system, and is a sign that the network is under attack. To help prevent these attacks from being successful, WPA adds the concept of countermeasures. If two frames with bad MICs (but good FCSs, so that we know they are not corrupted by radio effects) are received in a 60-second interval, the access point kicks all of the clients off and requires them to renegotiate new keys. This drastic step introduces a painful denial-of-service vulnerability into TKIP, but is necessary to prevent attackers from getting information easily. Of course, having countermeasures doesn't increase the robustness of the underlying algorithms, but kicking off all of the clients ensures that the attacker has to start from scratch with a new PTK.
Overall, TKIP was an acceptable bridge from WEP to WPA2. The designers rightfully recognize that TKIP is itself flawed, and is subject to a few vulnerabilities of its own. Besides the obvious denial-of-service attacks, TKIP also still allows for attacks that attempt to guess at certain parts of the particular messages and make some minor, but arbitrary, alterations to the packets successfully. Although workarounds exist for these types of attacks, TKIP will never be entirely hassle-free.
Therefore, I recommend that you migrate to WPA2 for every device on the network.
No comments:
Post a Comment