Pairwise Key Hierarchy | Real 802.11 Security: Wi-Fi Protected Access and 802.11i

The pairwise key hierarchy is the most complicated, so let's review that first. The hierarchy starts at the top with a pairwise master key (PMK) delivered from the upper-layer authentication server or with a preshared key. Let's put preshared keys aside for the moment and look at the server-key approach. The PMK is the top of the pairwise key hierarchy. There is a different PMK for each mobile device, and from this all other pairwise keys are derived. The following paragraphs show how the PMK is created and how it is used to generate the actual keys used in encryption.

Creating and Delivering the PMK

Let's do a one-paragraph review of IEEE 802.1X. In Chapter 8 we saw that the IEEE 802.1X model has three components: a supplicant, an authenticator, and an authentication server (which we abbreviate just to server here). The mobile device is the supplicant and connects to an access point containing the authenticator. The supplicant uses EAP to communicate, first with the authenticator (in the access point), and then to the server. The server makes a decision to admit (or block) the supplicant and informs both the authenticator and the supplicant. By this method the authentication and authorization is done centrally (at the server).

The highest key in the whole security context is held both by the user and the server, or the user's equipment and the server. This "supreme secret" key might be in a smart card, stored on a laptop disk, or remembered in a person's head. During the EAP authentication process, the chosen authentication method proves that both parties know the supreme secret. Chapter 9 outlined several ways to do this authentication. To be useful for RSN or WPA, the authentication method must, as a by-product of the authentication process, generate random-like key material that we can use for our key hierarchies. An authentication method that does this is called key-generating. Methods discussed in Chapter 9, such as TLS (SSL) and Kerberos, are key-generating.

When using upper-layer authentication, you use the key material generated during authentication to create the PMK. If, instead of upper-layer authentication, you are using a preshared key, this preshared key is used directly as the PMK.

Authentication occurs between the supplicant and the server, and the result is that both the mobile device and the server generate matching PMKs. But in order to use the keys to protect the wireless link, we need also to provide the PMK to the access point. How do we get the PMK from the server to the access point? In corporate networks, the access point(s) are connected to the authentication server by a network connection, usually using TCP/IP protocol, and it is necessary to transfer the PMK across the network. In small systems, it might be that a simple server is actually built into the access point unit. In this case, it is easy to transfer the key material.

The IEEE 802.11i specification does not explicitly say how the PMK should be transferred from the server to the access point, although recommendations are given. By contrast, WPA specifies transfer of the PMK to the access point using the RADIUS protocol. The RADIUS attribute MS-MPPE-Recv-key (vendor_id=17) is used for this purpose. More details of RADIUS are provided in Chapter 8.

At the end of the upper-level authentication phase and after completion of the key transfer, both the mobile device and the access point will have a copy of the PMK. The process of obtaining the PMK ends with the EAP-Success message being sent by the authentication, as described in Chapter 8. In the IEEE 802.1X model of the world, the EAP-Success message results in opening of the data port and data starting to flow. However, in WPA/RSN, this is not the case. There are further hurdles to clear before data is allowed. We need to derive keys for encryption between the access point and the mobile device. We need to verify that the keys are matching and we need to distribute a group key for use in broadcasts.

If you are using preshared keys, none of the upper-layer authentication process is required and the value of the PMK is programmed directly into the mobile device and access point independently. The PMK is required to be 256 bits long that is, 32 bytes. Because 32 bytes would be a very long password to remember, systems using preshared keys may allow users to enter a shorter password, which the system then expands to 256 bits. IEEE 802.11i has a suggested method for generating a key from a shorter pass phrase. This allows users to enter memorable text strings and have then converted into a preshared master key in a consistent manner.

Computing the Temporal Keys

In your enthusiasm to get encryption turned on, you might think at this stage that we are ready to slot the PMK into the encryption engine and get going. But we have a long way to go yet before we reach that stage. That is why it is called a hierarchy! The PMK is not used directly for any security operations. Instead it is used to derive a separate set of keys that will be used in protecting a link between two devices (for example, between the access point and a mobile device). Four separate keys are needed to do the job because there are two layers to protect the EAPOL handshake and the user's data and two cryptographic functions at each layer: encryption and integrity.^[1]

^[1] Chapter 12 explains that AES CCMP is designed so a single key can be used for both encryption and integrity, reducing by one the number of keys needed

Data Encryption key (128 bits)
Data Integrity key (128 bits)
EAPOL-Key Encryption key (128 bits)
EAPOL-Key Integrity key (128 bits)

These are referred to as the temporal keys because they are recomputed every time a mobile device associates to the access point. The collection of all four keys together is referred to as the pairwise transient key (PTK). For RSN/TKIP and WPA, each of these keys must be 128 bits long so that the PTK is a total of 512 bits long.

The first two temporal keys sound familiar. They are the ones used to encrypt the data and protect it from modification. The second two we have not seen before. These are used to protect the communications between the access point and mobile device during the initial handshake.^[2] For the moment, just accept that these EAPOL keys are needed; we will discuss them again shortly.

^[2] And for various notifications after the handshake.

Because the temporal keys are recomputed each time a mobile device connects, there has to be something that changes when the computation is done; otherwise, you'd end up with the same temporal keys every time. This is called adding liveness to the keys, ensuring that old keys no longer work. Liveness is achieved by including a couple of special values called nonces in the computation. The value of the nonce is quite arbitrary except in one respect: a nonce value is never used twice^[3] with the same key. The word "nonce" can be thought of as "N once" in other words, a value (N) only used once.^[4] They say lightning never strikes in the same place twice (which is not true) and similarly nonces never come up with the same value twice (which should be true by design).

^[3] In some practical systems, "never" is compromised to mean "extremely unlikely." For example, if a very large true random number is used, the probability of getting the same value twice might be considered acceptably low.

^[4] The word "nonce" actually derives from medieval English. For an interesting diversion, enter the phrase "for the nonce" into an Internet search engine (include the quotation marks) and choose among the numerous definitions.

The temporal keys are effectively shared between the two devices because both ends of the link compute an identical copy. It is not enough for one device to include its own nonce value. Each device must generate a nonce, pass its nonce to the other device, and then derive the temporal keys by including both nonces in the computation. Also, to make sure the identity of the two devices is bound into the keys, the MAC address of each is included in the computation. Figure 10.2 summarizes the process and shows the inputs to the temporal key computation and the four output keys. The inputs are the PMK, a nonce from each side, and the MAC address of each side. The outputs are four 128-bit keys. How the "key computation block" is implemented is described later.

Figure 10.2. Temporal Key Computation

graphics/10fig02.gif

Exchanging and Verifying Key Information

We have described how the authentication server and the mobile device mutually prove their identity and how key information must be derived by the mobile device and distributed to the access point. We have seen how the PMK is used to generate a set of temporal keys. However, one important step is missing: The mobile device has not yet verified that the access point is legitimate. Because we were able to talk to the server through the access point, it seems reasonable to assume it is trusted. However, it could be an access point that some hacker planted in the office and hooked up to the internal network. Maybe your janitor is a master hacker! Okay, maybe not, but the principle of security is trust no one so the access point must prove its credentials.

This is where the requirement for a secure connection between the authentication server and the access point is important. A secure connection requires that the server and the access point share their own secret so the janitor's AP cannot establish such a connection unless it knows the server's secret, even though it is connected inside the office. The access point can only receive the PMK from the server through the secure connection. So if the access point can prove to the mobile device that it possesses the PMK, then it proves that it is trusted by the authentication server, which is master of all security. So this defines the test: The access point and the mobile device must prove to each other that they both possess a copy of the secret PMK.

This idea of mutually proving possession of a secret key was also part of WEP but, as we saw in Chapter 6, the method used was completely broken and was easily tricked. In WPA/RSN the processes of proving key ownership is combined with the process of deriving the temporal keys using a key message exchange before the connection can be opened for business. There are four steps to the process, giving the name "four-way exchange," and the exchange is done using EAPOL-Key messages.

First we will look at the four-way exchange in overview and then drill down in more detail. The four-way exchange occurs between the access point and the mobile device. However, for consistency with IEEE 802.1X, these are referred to as the authenticator and the supplicant respectively. Remember, Authenticator = Access Point.

A Note on EAPOL-Key Messages

The standard for EAP does not specify by what type of network its messages should be sent. EAP was originally designed for use with PPP, which commonly runs over ordinary dial-up connections. IEEE 802.1X defined how to use EAP over a LAN and dubbed this "EAPOL." The standard also defined a "key message" that was intended to allow the supplicant and authenticator to exchange secret key information. The format of this key message is defined and also the method of encrypting the key value contained in the message. IEEE 802.11i uses the basic format of the EAPOL-Key message but modifies it in several ways to improve security.

The first step is for both the supplicant and authenticator to generate a nonce value. There is no connection between the two values they are independent however, there are specific rules about how the values are generated that are covered later in this chapter. The nonce selected by the authenticator is called ANonce and that of the supplicant is the SNonce. This is followed by the exchange of four messages that we refer to as A, B, C, and D.

Message (A): Authenticator Supplicant

The first EAPOL-Key message is sent from the authenticator to the supplicant and contains ANonce. This message is not encrypted or protected from tampering. Tampering with the value simply makes the handshake fail so there is no danger here.

Once the supplicant has received message (A), it has all the information it needs to compute the temporal keys. It already had the PMK, its own SNonce, and MAC address and now it has the ANonce and MAC address of the authenticator. So the supplicant now computes the four temporal keys using the algorithm described later in this chapter.

Message (B): Supplicant Authenticator

The authenticator cannot compute its keys yet because it does not know the value of SNonce. This is now sent by the supplicant using message (B). This message is unencrypted but it has a feature that was not in message (A): It includes a message integrity code (MIC) to prevent tampering. This is the first use of the EAPOL-Key Integrity key, one of the four temporal keys described earlier. Computing the MIC over the whole of message (B) prevents anyone from modifying the message without detection. However, more importantly, it allows the authenticator to verify that the supplicant really does know the PMK. If the supplicant's PMK doesn't match that of the authenticator, the MIC check will fail. Of course, the authenticator has not computed the keys yet; but because the message is not encrypted, it can first extract SNonce, and then compute all the temporal keys and finally go back and check the MIC value before moving to the next phase.

At this point the first half of the four-way exchange is completed. Both sides have now derived the four temporal keys and the authenticator has verified that the supplicant must have a matching PMK. So far, neither side has started encrypting.

Message (C): Authenticator Supplicant

This message is sent by the authenticator to tell the supplicant that it is ready to start using the new keys for encryption. It is important to synchronize this operation because, if either the access point or the mobile device turns on encryption before the other side is ready, the link will break. Message (C) includes a MIC check so the supplicant can verify that the authenticator has a matching PMK. It also contains the starting sequence number that will be used for the first encrypted frame to be sent using the key (normally, 0). Note that because the MIC is computed using a key derived from both the PMK and the supplicant's nonce, a message recorded from a previous handshake can't be successfully replayed.

The message is sent unencrypted and the authenticator does not install its temporal keys until it has received the final message (D). The authenticator waits to install the keys because, if message (C) fails to arrive at the supplicant, the authenticator must resend message (C). If the keys are installed too early, the resend would be encrypted and the supplicant would reject it.

Message (D): Supplicant Authenticator

When the supplicant receives message (C), it replies with message (D). This acknowledges completion of the four-way handshake and indicates that the supplicant will now install the keys and start encryption. The message is sent unencrypted and then the supplicant installs its keys. Upon receipt, the authenticator also installs its keys so subsequent messages are all encrypted.

Let's review what has been accomplished by this exchange:

ANonce and SNonce values have been exchanged.
Temporal keys have been computed.
Supplicant has proved knowledge of the PMK.
Authenticator has proved knowledge of the PMK.
Both devices have synchronized and turned on encryption of unicast packets.

Completing the Handshake

At this point both the mobile device and the access point have obtained, computed, and installed encryption keys. They are now communicating over a secure channel using encryption in both directions. However, we are not quite finished yet. Although the pairwise key hierarchy is now installed, we still have to set up the group key hierarchy so the access point can send broadcasts and multicast messages to the newly authenticated mobile device.