|
|
Now that you have seen all of the protocols on which 802.11i builds, I'll describe what exactly it is responsible for. Intuitively, people expect that 802.11i should encrypt their packets so that "other people" cannot read them, which is true. The question to ask though is "which other people"? People outside your organization who are not authorized to use your wireless network? Well, certainly. What about other people who have a legitimate reason to use your wireless? In other words, should employees be able to read each other's mail as it flies by? Preferably not, but at least this is less of a problem. Both of these questions are really questions of confidentiality, in security lingo.
The next biggest concern people have is that of authentication. You want to ensure that the only people who can connect to your network are ones authorized to do so. Notice that all of the protocols discussed so far were focused solely on authentication, not confidentiality. EAP/RADIUS/802.1X, as they have been described, are concerned with making users prove that they are authorized to use the network. Once they have done that, these protocols have done nothing to encrypt the communication that takes place afterward. Dialup links and Ethernet, even when protected by strong authentication that sits on top of EAP, are not encrypted once authentication takes place. It is this gap that 802.11i spends most of its time filling. There are more subtle concerns about security. One related to wireless is that of integrity. When you receive a packet on your wireless network, you want to be sure that it wasn't modified (or even injected by someone else). Finally, another concern about wireless security is replay protection. This was a serious problem with WEP. Even when attackers didn't know the WEP key, they could blindly replay packets and use this to generate traffic, which in turn could be used to recover the WEP key. 802.11i takes strong precautions to address all of these problems.
As it turns out, once you have a strong authentication mechanism in place, solving the rest of these problems is significantly easier. This section first delves into the details of authentication in an 802.11i environment. Once this is covered, all of the other problems become much more simple to address.
Having covered 802.1X and RADIUS, the authentication aspect of 802.11i looks a lot like that of a user plugging a laptop into an 802.1X-protected Ethernet jack. Instead of passing EAP packets (wrapped up in EAPOL) over Ethernet, the packets are passed over 802.11 (still wrapped up in EAPOL). Instead of a switch being the authenticator and authenticating physical ports, the access point now acts as the authenticator and authenticates everyone who associates. Figure 3-15 shows a simplified association/authentication exchange when using 802.11i with an authentication server.
Up until this point, everything in the 802.11i authentication exchange phase directly resembles that of Ethernet when using 802.1X (excluding the 802.11 association requests and responses, of course). It is after this point that 802.11i really starts to dictate what happens and where wireless security starts to diverge from wired.
If the sole thing you were interested in was protecting your wireless network from outsiders authenticating to it, you would be finished. The authentication server would be able to distinguish between legitimate users and attackers, and the AP would only let legitimate users in. In short, this would be a very brief section.
The problem is that you also want to protect your users from connecting to rogue access points. If the protocol just stopped, a rogue AP could simply pretend to authenticate the end-user, accepting whatever username/password (or any other authentication credentials they sent). Another problem that needs to be addressed is ensuring that authenticated sessions aren't hijacked. While it is difficult to hijack someone's authenticated 802.1X Ethernet session (you would need physical access to the wire), no such barrier exists in 802.11.
If the protocol stopped where it does in Figure 3-15, any halfway competent attacker trying to get on the network would just wait for a legitimate user to authenticate, DoS them off the network, and clone their MAC address. The access point would never know. The solution to both of these problems is to provide a much stronger binding between the AP and client than just a MAC addresses. You need a secret key.
Though so far this chapter has largely been concerned with authenticating dialup users with usernames and passwords, such a simple scheme is unacceptable with 802.11i. In order to prevent users from being tricked by rogue access points, and to stop attackers from simply stealing the MAC address of authenticated stations, 802.11i requires that the access point and the user share a secret key. In 802.11i terminology, this key is called the pairwise master key (PMK). The easiest way to explain what a PMK is and how it is generated is to consider a real-life authentication session.
Figure 3-16 shows an authentication exchange between a user and an authentication server using EAP-TLS. TLS is the successor of the SSL protocol, which is used to authenticate web servers (to you) as well as encrypt subsequent communication (such as your credit card number). When used in secure HTTP exchanges, TLS doesn't usually authenticate users to the server (since users don't have certificates). However, TLS does include support for mutual authentication, which is used in EAP-TLS.
The way EAP-TLS works is that the server presents the client with a certificate, which the client must verify. The client then presents the server with his certificate, which the server must verify. Assuming both certificates check out, the client and server negotiate a session key. Though the details of the negotiation are left out, conceptually it is fairly simple. Since the client has the server's certificate (and, therefore, the public key), the client generates a random number (the premaster secret) and sends it to the server encrypted with the server's public key. After that, the client and server mix in a few other random numbers and call it a session key.
In HTTPS, this session key would be used to initialize a stream cipher, and the rest of the communications over HTTP would be encrypted using it. In EAP-TLS, you are not interested in using TLS to encrypt the 802.11 packets. EAP-TLS uses TLS for three things: To authenticate the server to the client, to authenticate the client to the server, and finally to generate a cryptographically secure session key, which you will use for your own purposes.
If you look closely at Figure 3-16, you will notice that RADIUS is doing something new. In this example, the RADIUS server is not only telling the access point to accept the user authentication, but it is also delivering the PMK to the AP. The RADIUS server has to do this because the access point has no idea what session key the client and authentication server negotiated.
The AP is not looking into the authentication details of the EAP packets it passes around, and even if it was, it couldn't decrypt the premaster secret used to generate the TLS session key. Therefore, the RADIUS server has to send the AP the PMK that has been negotiated. The AP uses this secret to ensure that the wireless client it is talking to is the one the authentication server authenticated.
If the authentication protocol used is well designed (such as EAP-TLS), then there should be no way for an eavesdropper to determine what PMK the client and the authentication server have negotiated. In the case of EAP-TLS, the eavesdropper would have to compromise the private key associated with the authentication server's certificate.
At this point, it should be noted that key delivery is not something that RADIUS was originally designed to do. Clearly, you need to protect keys as they traverse the network between the authentication server and access point. Currently, this is handled by an extension to RADIUS developed by Microsoft and is documented in RFC 2548.
At this point, you know how an access point and an end-user can both end up with a dynamically generated cryptographically secure key, called the pairwise master key (PMK), without it being exposed to an attacker over the air. When using 802.11i in enterprise mode, this key is generated at an authentication server and delivered to the AP over RADIUS. It is the dynamic generation of this key that necessitates the use of so many different protocols (EAP, EAPOL, and RADIUS to be specific). Now that the client and access point both have this key, you are almost finished.
Now the AP must prove to the user that it does, in fact, have the key that the user negotiated with the authentication server. Doing this prevents an attacker from waiting until the user has authenticated to the authentication server and then attempting to launch an attack designed to redirect the user to a rogue access point. Remember, in the previous TLS example the client authenticated the authentication server via his certificate, not the AP. Just because an AP has the same name and MAC address as the one you were just talking to a second ago, doesn't mean it really is the same one. This is what makes wireless security so tricky.
Similarly, the AP needs to ensure that the client actually possesses the PMK. Otherwise, an attacker could just let a legitimate user authenticate with the authentication server, wait for the authentication server to send an access-accept message to the AP, and then disable the client and steal his MAC address. The possession of the PMK proves the identity of both the client and the AP to each other.
Now, all the AP and the client need to do is convince each other they actually possess the PMK. They also need to do this without transmitting the key over the air. They accomplish this with a simple challenge-response protocol, as shown in Figure 3-17. In reality, a slightly more complicated exchange is used.
In the protocol shown in Figure 3-17 (which I have modeled off the real four-way handshake employed in 802.11i), the first thing that happens is the AP sends the client a random number. This number is called the A-nonce (for authenticator-nonce). The AP expects the client to compute a hash of the A-nonce combined with the PMK. If the client responds with the correct hash, he must know the PMK. Similarly, the client picks a random number called the S-nonce (for supplicant-nonce) and sends it to the AP. If the AP responds with the correct hash, she also must know the PMK.
This concludes the detailed explanation of 802.11i's authentication mechanisms. This section covered how the authentication server and station dynamically generate cryptographic keys and how those keys are delivered over RADIUS to the AP. It also covered why the AP and the client need to mutually authenticate each other. As you will see later, the PMK is used to derive a series of other keys, without which 802.11i could not provide confidentiality or integrity of packets.
Now that authentication has been covered at length, you know how 802.11i ensures that users end up talking only to the right AP, and APs talk only to the right user. You also know how unique PMKs are created during the authentication phase and delivered to the AP from the RADIUS server. This is important because confidentiality in 802.11i assumes that the AP and client already have the PMK in place.
As mentioned previously, 802.11i describes two data confidentiality protocols, TKIP and CCMP. Though the details of how a packet is encrypted depends on each protocol, for now you are concerned with key distribution and key hierarchy. Neither of these aspects is dependent on the specific confidentiality protocol.
You might think that since both the AP and user now have the PMK, you can just throw it into an encryption algorithm and finally start sending some data. However, you aren't done dealing with keys. Although having one key at the AP and another at the client is a good start, when it comes to cryptographic keys in 802.11i, the more the merrier.
Although the PMK is in place at the AP and at the client, you are going to perform a few logically distinct cryptographic operations. The most obvious of these is computing a Message Integrity Check (MIC) over all the packets and also encrypting them. These are two different operations when using TKIP, and it would be a poor design choice to use the same key for different things.
The 802.11i key hierarchy defines a way that the PMK can be used to create a set of temporary keys. These keys are called temporal keys. When TKIP is being used, four temporal keys are created: One for encryption, one for integrity, and two other keys that aren't delved into here. Actually, TKIP uses two unique 64-bit keys for integrity, one for transmission and one for receiving, but let's not worry about the details.
When using CCMP, the data encryption/integrity roles are actually combined (through the use of a clever AES mode of operation), and only three keys are needed. For simplicity, let's refer to the entire set of temporal keys at once. This set of combined keys is called the pairwise transient key (PTK).
The PTK is recomputed every time a station associates and may be recomputed at regular intervals when exchanging data with an AP. This helps ensure that the derived PTK is unique, even if the PMK is the same. When using 802.11i in pre-shared key mode (also known as personal mode) this is important because, in that case, the PMK is usually constant across all users (the 802.11i spec does say how to use per-user pre-shared keys, but it is rarely implemented or used).
Generating the PTK from the PMK is relatively straightforward. All you are doing is expanding one random 256-bit number into three or four unrelated random 128-bit numbers. You also need the derived numbers to be a function of some information exchanged during the four-way handshake. The PTK is defined as follows:
PTK = PRF-512(PMK, "pairwise key expansion", MAC1 MAC2 nonce1 nonce2)
This function is a pseudo-random number generator defined in the 802.11i standard. It returns a 512-bit number and takes the PMK as well as various nonces and the MAC address of the AP and client as input. As mentioned previously, when using CCMP, only three 128-bit keys are needed and PRF-384 is called instead.
You might be wondering what that "pairwise key expansion" string is doing. The PRF family of functions is used elsewhere in the standard as well. This motivated the IEEE to use constant strings (such as the "pairwise key expansion" string) as input to ensure that even if the same pseudo-random number generator is called using the same nonce and MAC addresses, but for a varying purposes, different output is produced. Attention to small details like this is critical when designing security protocols.
The four-way handshake was alluded to in the section on authentication. In that case, it was simplified to provide only authentication. In reality, the four-way handshake serves two purposes. One purpose is to prove that both the AP and the client possess the PMK. This feature was explained earlier in "Authentication Using 802.11i." The second purpose is to provide the relevant values that need to be plugged in to create the PTK. In particular, these values are the nonces used to derive the PTK mentioned previously. The full four-way handshake is shown in Figure 3-18. The fact that this handshake is doing two things at once throws people off, so it is covered in some detail.
The first message in the four-way handshake consists of the AP sending the client its nonce. A nonce is a number that should never be used again. In practice, it is probably a number that will very likely never be used again, such as a large random number. Once the client has the A-nonce, she has all the information needed to compute the PTK.
Now that the client has the A-nonce, she chooses her own S-nonce and derives the PTK. She takes the S-nonce and puts it in a EAPOL-key message that is sent back to the AP. Using one of the keys contained in the PTK, she also computes a MIC over this packet. By computing this MIC, she proves to the AP that she knows the PMK. If the client didn't know the PMK, she couldn't have derived the PTK. Without the PTK, she could not have computed the MIC.
Once the AP receives the second message, he knows the S-nonce chosen by the client. The AP then derives the same PTK and computes the MIC over the received packet. If the computed MIC doesn't match, then the client did not derive the PTK and, therefore, is lying and will not be allowed access. Assuming the MIC the client sent matches, the AP responds with a message informing her that she has successfully authenticated and to go ahead and install the key. This message is protected by a MIC that the client must verify to ensure the AP has possession of the PMK. Assuming the MICs on both ends are correct, the AP and the client have proven possession of the PMK (via successful derivation of the PTK), and they have authenticated each other.
Once the client verifies the MIC on the AP's message informing her to install the keys, she sends back a response, and the AP and client install the keys and start to encrypt the data.
Once all of the work of authenticating to the network (and the network to the client) is completed, encrypting packets is relatively straightforward. Since authentication has already happened, the client and the AP share a secret key (the PMK). This key is expanded from one random 256-bit value into multiple key values that represent the pairwise transient key (PTK). Contained within the PTK is an individual key, called the temporal encryption key, which is used to initialize encryption via TKIP or CCMP.
The next security problem that 802.11i solves is that of integrity. After authenticating, the AP and client end up with a shared PMK. After association, 802.11i creates temporary keys (the collection of which are referred to as the pairwise transient key or PTK). One of the individual keys contained in the PTK protects the integrity of messages. Before talking about how this works, let's consider what would happen if 802.11i didn't provide any sort of integrity check.
Many people think that because their messages are encrypted, they don't need to worry about them being modified. Since an attacker can't read them, how could he meaningfully modify them? While it's true that an attacker cannot read them, he still might be able to flip random bits and gum up the works. He might not know what he is changing, but he could still try to modify messages.
A bigger problem is that even if an attacker doesn't know the key, he could still try to inject data into your network. With no integrity check, consider what happens when an attacker crafts an arbitrary packet and sends it directly to you (bypassing the AP). When you get his packet, you'll decrypt it, and since the packet wasn't properly encrypted to begin with, you'll transform the payload into a stream of nonsensical bits in the process. The attacker can't choose what the bits will look like when they're decrypted (because he doesn't know the key), but he can try to inject something. The question is, how do you know that this nonsensical packet wasn't sent by a legitimate network user?
Well, you might say that no real user would send you a stream of bits that isn't a valid IP packet (which is mostly true), but you don't want your wireless device driver sitting around trying to guess if a packet was sent by a real user or an attacker trying to inject something (even if just random noise). The way this is accomplished is with a Message Integrity Check (MIC).
In 802.11 (and other IEEE 802. standards) the term Message Integrity Check is used instead of the more accepted Message Authentication Code because the acronym MAC was already taken. MIC is IEEE-speak for what everyone else calls a message authentication code.
Conceptually, a MIC is straightforward. Since the goal of the MIC is to prevent the data from being modified in transit, the sender computes a hash over the data and sends a hash as well. Of course, if the attacker can modify the bits of the message, she could modify bits of the hash. Instead of having the sender just compute the hash of the data, she computes a hash of the data plus a secret key. The key used in 802.11i is the temporal integrity key (contained in the PTK). Mathematically, this can be written as
MIC = hash(packet, temporal integrity key)
When using TKIP, the hashing algorithm is called Michael. CCMP uses the Cipher Block Chaining Message Authentication Check (CBC-MAC). A diagram of a packet processed by 802.11i is shown in Figure 3-19. In this diagram, the 802.11 header contains all of the normal stuff you would expect to find (addresses and so on). The 802.11i field contains parameters specific to the TKIP/CCMP, so the format varies, but the most important thing here is the initialization vector. After that, you have the actual payload of the packet, followed by the MIC.
| Caution |
The Michael MIC protects only a subset of the 802.11 header, most importantly the source and destination address. |
Notice that the MIC itself is also encrypted. When the recipient of this packet receives it, she will have to decrypt the payload and the MIC. She will then compute the keyed hash over the header and payload and compare it to the MIC. If the MIC doesn't match, she'll discard the packet. This prevents an attacker from modifying packets as they fly by (how could he make the MIC match his modifications?), and it also stops unauthenticated users from injecting packets (how would they know what key to use to compute the MIC?).
The last feature that 802.11i provides is replay protection. Compared to the other problems 802.11i addresses, replay protection might seem a little less important. You already know how to stop attackers from getting on the network, reading packets, modifying packets, and injecting their own packets. The last thing that an attacker might try (perhaps out of frustration that she couldn't do anything else) is replay packets that a legitimate client already sent.
Imagine an attacker replaying a packet that tells the bank to transfer money to her account; if successful, she could increase the amount of money transferred by replaying the legitimate transaction one or more times. That is obviously a pretty cooked-up example, but it does provide some motivation to prevent it. In reality, the biggest threat that replaying packets poses is the ability to generate illegitimate traffic on a LAN.
While this might not sound like that big of a threat, the lack of replay protection contributes significantly to the speed at which a WEP key can be recovered, so it is still important to consider.
The solution to preventing replay attacks is simple. Simply add an incrementing number to every packet exchanged between the client and access point. In TKIP, this field is called the TKIP Sequence Counter (TSC), and in CCMP, it is just called the Packet Number (PN). Since these numbers perform the same logical function, I'll call them serial numbers.
Whenever a client associates to an AP, it starts counting the packets it sends. The first packet gets serial number one. These numbers restart whenever the client negotiates a new PTK (by disconnecting and reassociating, or through regular key rotation). This serial number is embedded in the 802.11i header of every packet.
If the AP wants to determine if a packet has been replayed, it just checks to see if the serial number is fresh. Intuitively, you might think that the AP could expect the serial counter to always increase by one; but in reality packets get dropped, and the protocol needs a little slack to compensate. Currently, the standard says that any packets that arrive with a serial number equal to the expected serial number, minus a small window (currently 16), will be processed. Any packets with a value less than this, which would be an old replayed packet, are dropped. This small window allows the protocol to deal easily with the occasional lost packet, while still preventing an attacker from replaying old data.
This serial number is unencrypted in the 802.11i header. A smart attacker who wanted to replay a packet could simply modify the serial number and retransmit it, right? That would be possible, except the serial number is used as input for the decryption process. By trying to reinject an old packet with a modified serial number, the packet will fail to decrypt (the MIC won't be correct), and it will be dropped.
|
|
