170 Chapter 5 www.newnespress.com • Outsider Rejection: No wireless device other than a trusted sender can send a message correctly encrypted. • Authenticity and Forgery Protection: The recipient can prove who the original composer of the message is. • Integrity: The message cannot be modified by a third party without the message being detected as having been tampered with. • Replay Protection: A older but valid message cannot be resent by an attacker later, thus preventing attackers from replaying old transactions. Some of these properties are contained in how the encryption keys get established or sent from device to device, and the rest are contained in how the actual encryption or decryption operates. 5.6.1 Wi-Fi Security Technologies Let’s start with the earliest security for Wi-Fi. It is useful to read about WEP, the first and oldest method for Wi-Fi security, to understand the basic terms and concepts for wireless security in general. 5.6.1.1 WEP WEP (Wired Equivalent Privacy) was the first attempt to secure 802.11. Unfortunately, the privacy it provided was neither equivalent to wired nor very good. Its very design does not protect against replays, meaning that an attacker can record prior valid traffic and replay it later, getting the network to repeat actions (such as charging credit cards) without detecting it. Furthermore, WEP uses for encryption RC4, an algorithm that was not designed to be used in the way WEP uses it, leading to ways of reverse-engineering and cracking the encryption without the key. Finally, WEP uses a very poor message integrity code. All of that said, WEP is a good place to look to learn the mechanics of security in 802.11, as the later and better security additions replaced the broken pieces but did not destroy the framework. NOTE: It is the author’s recommendation to not use WEP in existing or new networks, under any circumstances, because of the known flaws. Please consider the studying of WEP to be an academic exercise at this point, and do not allow vendors to talk you into using it. 5.6.1.1.1 Keying WEP starts off with an encryption key, or a piece of knowledge that is known by the access point and the client but is sufficiently complicated that outsiders—attackers, that is— shouldn’t be able to guess it. Introduction to Wi-Fi 171 www.newnespress.com There is one and may be two or more WEP keys. These keys are each either 40 bits (WEP- 40) or 104-bits (WEP-104) long, and are usually created usually from text passwords, although they can be entered directly as hexadecimal numbers. Manually entered keys are called pre-shared keys (PSK). WEP provides very little signaling to designate that encryption is in use, and there is no way to denote whether the short or long keys are being used. If any security, at all, is used in the network, the “Privacy” flag in the network’s beacons are set. Clients that want to use WEP had to associate to the network and start sending encrypted traffic. If the keys matched, the network made forward progress and the user was happy. If the keys did not match, the user would not be able to do much, but would otherwise not know what the error was. As you can see, this is not an ideal situation, and is avoided in the modern, post-WEP protocols. There are some more complicated possibilities, which are not worth going over, except to note that the origin of the confusing 802.11 term “authentication” for the first phase of a client’s connection to the network came from an old method of using WEP to verify the key before association. This security method is completely ignored by post-WEP protocols, which use a different concept to ensure that clients have the right key. Therefore, the two Authentication frames are now considered vestigial, and carry no particularly useful information in them. 5.6.1.1.2 Encryption The encryption key is not used directly to encrypt each packet. Instead, it is concatenated with a per-packet number, called the initialization vector (IV), to create the key that RC4 uses to encrypt the data. The initialization vector can be any number. Transmitters would start at zero, and add one for each frame sent, until it hit the end of the three-byte sequence, where it would start over at zero again. Why have a per-packet key, when the original key was supposedly secret? To answer this, let’s look at the encryption algorithm for WEP, which is based on RC4. RC4 is a stream cipher, meaning that it is designed to protect a large quantity of flowing, uninterrupted data, with minimal overhead. It is used, for example, to protect secure web traffic (HTTPS), because web traffic goes across in a stream of HTML. RC4 is really a pseudorandom number generator, with cryptographic properties to ensure that the stream of bits that comes out is hard to reverse-engineer. When given a key, RC4 generates an infinite number of bits, all appearing to be random. These bits are then matched up, bit-by-bit, to the incoming plaintext, or not yet encrypted, data. Each bit of the plaintext is added to each matching bit of the RC4 stream, without carry. This is also known as taking the exclusive or of two bits, and the logic goes that the resulting “sum” bit is 1 if either of the incoming bits are 0, and 0 otherwise. The mathematical operation is represented by the ⊕ symbol, and so the four possibilities for the exclusive or are as follows: 0 ⊕ 0 = 0, 0 ⊕ 1 = 1, 1 ⊕ 0 = 1, and 1 ⊕ 1 = 0. When applied to the plaintext and RC4 together, the resulting stream looks 172 Chapter 5 www.newnespress.com as random as the original RC4 stream, but has the real data in it. Only a receiver with the right key can recreate the RC4 stream, do the same bitwise exclusive or to the encrypted data, and recover the original data. (The exclusive or operation has the property that any number that has any other number added twice provides the same number back: n ⊕ d ⊕ d = n. Therefore, applying the exclusive or of the RC4 stream twice to the original data, once by the encryption algorithm and once by the decryption algorithm, gets the plaintext data back.) So far, so good. However, an attacker can use the properties of the exclusive or to recover the plaintext in certain cases, as well. If two frames come using the same per-frame key— meaning the same IV and WEP key—an eavesdropper can just add the two encrypted frames together. Both frames have the same per-frame key, so they both have the same RC4 stream, causing the exclusive or of the two encrypted frames to cancel out the identical RC4 stream and leave just the exclusive or of the two original, plaintext frames. The exclusive or of two plaintext frames isn’t terribly different from having the original plaintext: the attacker can usually guess at the contents of one of the frames and make quick work discovering the contents of the other. This isn’t a flaw with RC4 itself, as it is with using any exclusive or cipher—a type of linear cipher, because ⊕ is really addition modulo 2—as they are vulnerable to bit-by-bit attacks unless other algorithms are brought in as well. Okay, so that explains the per-frame keying and the IV, and why it is not a good solution for security. In summary, replays are allowed, and the IV wraps and key reuse reveals the original plaintext. Finally, the per-frame key doesn’t include any information about the sender or receiver. Thus, an attacker can take the encrypted content from one device and inject it as if it were from another. With that, three of the problems of WEP are exposed. But the per-frame keying concept in general is sound. 5.6.1.1.3 Integrity To attempt to provide integrity, WEP also introduces the integrity check value (ICV). This is a checksum of the decrypted data—CRC-32, specifically—that is appended to the end of the data and encrypted with it. The idea is that an attacker might want to capture an encrypted frame, make possibly trivial modifications to it (flipping bits or setting specific bits to 0 or 1), and then send it on. Why would the attacker want to do this? Most active attacks, or those that involve an attacker sending its own frames, require some sort of iterative process. The attacker takes a legitimate frame that someone else sends, makes a slight modification, and sees if that too produces a valid frame. It discovers if the frame was valid by looking for some sort of feedback—an encrypted frame in the other direction—from the receiver. As mentioned earlier, RC4 is especially vulnerable to bit flipping, because a flipped bit in the encrypted data results in the flipping of the same bit in the decrypted data. The ICV is Introduction to Wi-Fi 173 www.newnespress.com charged with detecting when the encrypted data has been modified, because the checksum should hopefully be different for a modified frame, and the frame could be dropped for not matching its ICV. As mentioned before, however, WEP did not get this right, either. CRC-32 is not cryptographically secure. The effect of a bit flip on the data for a CRC is known. An attacker can flip the appropriate bits in the encrypted data, and know which bits also need to be flipped in the CRC-32 ICV to arrive at another, valid CRC-32, without knowing what the original CRC-32 was. Therefore, attackers can make modifications pretty much at will and get away with it, without needing the key. But again, the concept of a per-frame message integrity code in general is sound. 5.6.1.1.4 Overall WEP alters the data packet, then, by appending the ICV, then encrypting the data field, then prepending the unencrypted IV. Thus, the frame body is replaced with what is in Table 5.15. Table 5.15: 8.02.11 Frame Body with WeP (Compare with Table 5.2) IV Key ID Data ICV 3 bytes 1 byte n−8 bytes 4 bytes The issues described are not unique to RC4, and really applies to how WEP would use any linear cipher. There are also some problems with RC4 itself that come out with the way RC4 is used in WEP, which do not come out in RC4’s other applications. All in all, WEP used some of the right concepts, but a perfect storm of execution errors undermined WEP’s effectiveness. Researchers and attackers started publishing what became an avalanche of writings on the vulnerability of WEP. Wi-Fi was at risk of becoming known as hopelessly broken, and drastic action was needed. Thus, the industry came together and designed 802.11i. 5.6.1.2 RSNA with 802.11i 802.11i addresses the major problems with WEP. The first problem, the inability to establish per-connection keys, and the inability to use different encryption algorithms, was fixed by a better protocol. On top of that, 802.11i introduced two new encryption and integrity algorithms. Wi-Fi Protected Access (WPA), version one, was created to quickly work around the problems of WEP without requiring significant changes to the hardware that devices were built out of. WPA introduced the Temporal Key Integrity Protocol (TKIP), which sits on top of WEP and fixes many of the problems of WEP without requiring new hardware. TKIP was designed 174 Chapter 5 www.newnespress.com intentionally as a transition, or stopgap, protocol, with the hopes that devices would be quickly retired and replaced with those that supported the permanent solution, the second of the two algorithms. Wi-Fi Protected Access version 2 (WPA2), as that permanent solution, required completely new hardware by not worrying about backwards compatibility. WPA2 uses AES to provide better security and eliminate the problems of using a linear stream cipher. A better integrity algorithm ensures that the packet has not been altered, and eliminates some of the denial-of- service weaknesses that needed to be introduced into TKIP to let it ward off some of the attacks that can’t be directly stopped. A word, first, on nomenclature. For those of you in the know, you might know that WPA has both TKIP and AES modes, 802.11i has slightly different TKIP and AES modes, and that both were harmonized in WPA2. However, practically, there really is no need to know that. For the remainder of this chapter, I will use WPA to mean TKIP as defined in WPA, WPA2 to mean AES as defined in the standard, and 802.11i to mean the framework under which WPA and WPA2 operate. This is actually industry convention—WPA and TKIP go hand in hand, and WPA2 and AES go hand in hand—so product documentation will most likely match with this use of the terms, but when there is doubt, ask your vendors whether they mean TKIP or AES. 802.11i first introduced the idea of a per-connection key negotiation. Each client that comes into the network must first associate. For WEP, which has no per-connection key, the client always used the user-entered WEP key, which is the same for every connection. But 802.11i introduces an additional step, to allow for a fresh set of per-connection keys every time, yet still based on the same master key. Networks may still used preshared keys. These are now bumped up to be 128 bits long. For WPA or WPA2, this mode of security is known as Personal, because the preshared key method was intended for home use. Enterprises can also use 802.1X and a RADIUS server to negotiate a unique key per device. This mode of security is known as Enterprise. For example, “WPA2 Enterprise” refers to using WPA2 with 802.1X. Either way, the overall key is called the pairwise master key (PMK). This is the analog to the original WEP key. Now, when the client associates, it has to run a four-message protocol, known as the four-way handshake, to determine what should be used as the key for the connection, known as the PTK (the pairwise temporal key or pairwise transient key). This whole concept of derived keys is known as a key hierarchy. The four way handshake is made of unencrypted data frames, with Ethernet type of EAPOL (0x888E), and show up as the specific type of Extensible Authentication Protocol over LAN (EAPOL) message known as an EAPOL Key message. These four messages can be seen by wireless capture programs, and mark the opening of the data link between the client and the Introduction to Wi-Fi 175 www.newnespress.com access point. Before the four-way handshake, clients and access points cannot exchange any data besides EAPOL frames. After the handshake, both sides can use the agreed-upon key to send data. Message 1 of the four-way handshake is sent by the access point to the client, and signals the security settings of the access point (as contained in something called the RSN IE, shown in Table 5.16). The RSN IE contains the selection of encryption and integrity algorithms. The message also contains something called a nonce, which is a random number that the access point constructs (more on this shortly) and which will be mixed in with the PMK to produce the PTK. Table 5.16: The security settings in the RSN IE Element ID Length Version Group Cipher Suite Pairwise Cipher Suite Count Pairwise Cipher Suite List AKM Suite Count AKM Suite List RSN Capabilities PMKID Count PMKID List 1 bytes 1 byte 2 bytes 4 bytes 2 bytes n bytes 2 bytes m bytes 2 bytes 2 bytes p bytes Message 2 is sent in response, from the client to the access point, and includes the same information, but from the client: a client RSN IE, and a client nonce. Once the client has chosen its nonce, it has enough information to produce the PTK on its end. The PTK is derived from the two nonces, the addresses of the access point and client, and the PMK. At this point, it might seem like the protocol is done: the client knows enough to construct a PTK before sending Message 2, and the access point, once it gets the message, can use the same information to construct its own PTK. If the two devices share the same PMK—the master key—then they will pick the same PTK, and packets will flow. This is true, but the protocol needs to do a little bit more work to handle the case where the PMKs do not agree. To do this, the client “signs” Message 2 with a message integrity code (MIC). The MIC used is a cryptographic hash based on both the contents of the message and the key (PTK). Thus, the access point, once it derives its own PTK from its PMK and the nonces, can check to see whether the client’s sent MIC matches what it would generate using its own PTK. If they match, then the access point knows that message 2 is not a forgery and the client has the right key. If they do not match, then the access point drops the message. If Message 2 is correct, then Message 3 is sent by the access point, and is similar to Message 1 except that it too is now “signed” by the MIC. This lets the client know that the access point has the right key: at Message 2, only the access point could detect an attacker, but not the client. Also, the client can now verify that the access point is using the same security algorithms as the client—a mismatch would only occur if an attacker is injecting false RSN IEs into the network to try to get one side or both to negotiate to a weaker algorithm (say, TKIP) if a stronger algorithm (say, AES) is available. Finally, for WPA2, the 176 Chapter 5 www.newnespress.com client learns of the multicast key, the group temporal key (GTK), this way, as it is encrypted with the PTK and sent as the last part of the message. Message 4 is a response from the client to the access point, and validates that the client got Message 3 and installed all of the correct keys. The nonces exist to prove to each side that the other side is not replaying these messages— that is, that the other side is alive and is not an attacker. Imagine that the access point sends its nonce. An attacker trying to replay a previous, valid handshake for the same client could send an old Message 2, but the MIC on that Message 2 can never be correct, because it would always be based on the access point nonce recorded previously and was used in that previous handshake, and not the new one that the access point just created. Thus, the access point always can tell the difference between a client that is really there, and one that is just replayed from the past. The client can use its nonce to do the same thing. Also, if either side has the wrong PMK—which would happen with preshared keys if someone typed one of the keys wrong—the devices can catch it in the four-way handshake and not pretend to have a working connection. Overall, the four-way handshake lets the two sides come together on a fresh connection key every time. The four way handshake is the same, except for some minor details such as choice of algorithm, for WPA and WPA2. By the way, keep in mind that the four-way handshake is only designed to provide a new PTK every time based on the same PMK, to provide a fresh PTK and eliminate the problem of old or stale keys that WEP has. The four-way handshake is not designed to hide the PTK from attackers who have the PMK. This is an important point: if an attacker happens to know the PMK already—such as a preshared key that he or she stole or remembered—then every PTK ever generated from that PMK, in the past and in the future, can be broken with minimal effort. This is known as a lack of forward secrecy and is a major security flaw in preshared key networks. In other words, you must keep the PMK secret. Do not share preshared keys, ever—even if you have stopped using that preshared key and moved to a new one long ago. If an attacker had been recording your past conversations, when the old preshared key was in use, and someone leaks the preshared key to this attacker, your old conversations are in jeopardy. This has serious consequences for voice mobility networks, and will be reiterated in Chapter 8 on security for voice mobility. 5.6.1.3 WPA and TKIP 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 Introduction to Wi-Fi 177 www.newnespress.com The first change is to expand the IV and key ID fields to eight bytes total (see Table 5.17). 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. 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 Table 5.17: 8.02.11 Fram Body with WPA (Compare with Table 5.15) Expanded IV Data MIC ICV 8 bytes n - 8 bytes 8 bytes 4 bytes 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. 178 Chapter 5 www.newnespress.com 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. 5.6.1.4 WPA2 and AES WPA2 introduces a new encryption algorithm, using the Advanced Encryption Standard (AES). This cipher was produced to be used as a standard algorithm wherever encryption is needed. AES is a block cipher, unlike RC4. A block cipher takes blocks of messages—fixed chunks of bytes—and encrypts each block, producing a new block of the same size. These are nonlinear ciphers, and so the bit-flip attacks are significantly harder. AES was specifically designed and is believed to be practically impervious to those styles of attacks. With block ciphers, each block starts off independently, a bit of a downside compared to stream ciphers. To remove that independence, WPA2 also uses what is called Counter mode, a simple concept where later blocks are made to depend on previous blocks. The MIC used is also based on AES, but is used as a cryptographic hash. This use is called cipher block chaining (CBC), and essentially uses the same concept of making later blocks Introduction to Wi-Fi 179 www.newnespress.com Table 5.18 shows the frame body used with WPA2. As with WPA, WPA2 has essentially the same expanded IV. Because WPA2 isn’t using TKIP, the name has been changed to the packet number (PN), but serves the same purpose, starting at 0 and counting up. The PN is used for replay detection, as well as ensuring per-frame keying. The MIC is also eight bytes, but uses CBC-MAC rather than Michael. With new hardware, the last vestige of WEP can be dropped, and the old ICV is removed. Because the WPA2 MIC is considered to be cryptographically strong, the designers of WPA2 eliminated the countermeasures that WPA has. It is still true that no frame should come in with an invalid MIC; however, the administrator can be alerted to deal with it in his own time, as there are not any known exploits that can be successfully mounted against WPA2 using an invalid MIC to date. 5.6.1.5 Wi-Fi Link Security: Summary To summarize, 802.11 security is provided by three different grades of technology: the outdated and broken WEP, the transition-providing WPA, and the secure and modern WPA2. WPA and WPA2 are both built on the same framework of 802.11i, which provides a rich protocol for 802.11 clients and access points to communicate and negotiate which over-the- air encryption and integrity algorithms should be used. Networks start off with a master key—either a preshared key, entered as text by the user into the access point and mobile device, or generated in real time by enterprise-grade authentication systems. This master key is then used to derive a per-connection key, called the PTK. The PTK is then used to encrypt and provide integrity protection for each frame, using either TKIP for WPA or AES for WPA2. It bears repeating that preshared keys, for all grades of 802.11 security, have problems that cause both security and management headaches. The biggest security headache is that the privacy of the entire network is based on that PSK being kept private for eternity. If a PSK is ever found out by an attacker—even if that key has been retired or changed a long time ago—then the attacker can use that key to decrypt any recordings of traffic that were taken Table 5.18: 8.02.11 Fram Body with WPA2 (Compare with Table 5.15) PN = IV Data MIC 8 bytes n−8 bytes 8 bytes depend on earlier ones, but only outputting the last block as the result. This small block (128 bits) is dependent on every bit of the input, and so works as a signature, or hash. The overall algorithm used is known as Counter Mode with Cipher Block Chaining- Message Authentication Code (CCMP). . in the standard, and 802.11i to mean the framework under which WPA and WPA2 operate. This is actually industry convention—WPA and TKIP go hand in hand, and WPA2 and AES go hand in hand—so product. well. Okay, so that explains the per-frame keying and the IV, and why it is not a good solution for security. In summary, replays are allowed, and the IV wraps and key reuse reveals the original plaintext capture programs, and mark the opening of the data link between the client and the Introduction to Wi-Fi 175 www.newnespress.com access point. Before the four-way handshake, clients and access points