Empire of the Air: WEP and EAP

In this second in a series, explore Wired Equivalent Privacy and Extensive Authentication Protocol.

• By Bill Boswell
• May 01, 2003

This time, let’s look at the principles of securing wireless network communications using Wired Equivalent Privacy (WEP) as laid out in the original 802.11 standard and how the 802.1x standard augments WEP with Extensible Authentication Protocol (EAP) and secure key exchange using Transport Layer Security (TLS).

Wired Equivalent Privacy
Our next-door neighbors recently had a baby. Being conscientious parents, they purchased a baby monitor. One day, they admitted somewhat sheepishly that they could occasionally hear our cell phone conversations over the monitor. (What they actually heard in those conversations, they wouldn’t admit.) The situation was easily resolved, in the short term, by our purchase of a phone that operated in a different frequency range than their baby monitor. However, the long-term problem of maintaining mobile phone privacy in a large suburban community lies outside the scope of this column.

Wireless network adapters have similar privacy issues as their mobile phone cousins. The spread-spectrum technique used to smear a digital signal over several channels is well documented, making the reconstruction of a data stream simply an engineering exercise. Protecting the contents of the data stream requires some form of encryption. The WEP authentication mechanism in the 802.11 standard defines a method for exchanging keys between wireless stations and access points. Once these keys have been exchanged, they’re used as cipher keys for RC4 streaming encryption.

RC4 uses the exclusive OR or XOR function, in combination with a cipher key, to encrypt a stream of data. Here’s a truth table for the XOR function:

The contents of any column in the table can be obtained simply by doing an XOR on the other two columns, making XOR an extremely fast symmetric key algorithm, well-suited for handling fast data streams. The cipher key is changed for each frame by feeding the key used in the last frame into the key production algorithm to produce a new key, a technique called chaining.

The RC4 cipher key used in WEP is a combination of a static element and a dynamic element.

The static element, called the secret key, was originally defined in 802.11 as a 40-bit alphanumeric value (10 hex or 5 ASCII characters). In addition, with the relaxation in export restrictions, vendors now typically support a 104-bit value (26 hex or 13 ASCII characters). The wireless stations and their access point share the same secret key.

The dynamic element, called the Initialization Vector (IV), is a 24-bit alphanumeric value. A new and unique IV is created for each WEP session. The 24-bit IV is concatenated with the 40- or 104-bit static WEP key to yield either a 64- or 128-bit seed value that is then converted into a cipher key by a pseudorandom number generator.

Most wireless vendors offer a confusing mix of “40-bit and 128-bit encryption” because putting “40-bit and 104-bit encryption” on the box would make their products appear less secure than the product from a less scrupulous competitor. Figure 1 shows a typical secret key configuration window.

Figure 1. A typical WEP secret key configuration. (Click image to view larger version.)

Here’s how access points and wireless stations use the WEP cipher elements: When a station first associates with an access point, the access point notifies the station that WEP is required for authentication. The station generates a 24-bit IV, concatenates its copy of the secret key and feeds the result into a pseudorandom number generator to produce a cipher key. The station then uses RC4 to XOR the cipher key with the data frame to produce an encrypted frame that is sent, along with the IV, to the access point.

The access point extracts the IV from the frame and uses it to create a copy of the same cipher key used by the station. The access point then decrypts the data sent by the station. If the decrypted contents match the original contents, based on a 32-bit CRC called an Integrity Check Value (ICV) placed in the data by the client, the access point opens a port for the station. In the subsequent data stream, the station and access point increments the IV by one for each data frame to produce a series of cipher keys.

WEP Weaknesses
The essential problem with WEP is the small IV. With only 24 bits available, the total possible population of cipher keys is exhausted quickly in a session. This means that a cipher key is likely to be reused. As soon as a cipher key is repeated, an attacker can use a simple formula to determine the plain text in the encrypted packets. From there, the shared key and IV can be reverse-calculated and the data stream laid bare.

In addition, the CRC algorithm used to produce the ICV is well known, making it relatively straightforward for an attacker to change the content of an encrypted frame, then manipulate the ICV to hide the changes. A variety of tools can exploit these WEP vulnerabilities.

802.1x Port-Based Security
Once the weaknesses in WEP became clear, the industry set to work to produce an improved method for protecting authentication transactions and securely exchanging WEP keys. The result was IEEE standard 802.1x, Port-Based Network Access Control.

The 802.1x protocol augments the standard WEP transaction in two ways. First, it improves the initial authentication by replacing the shared key transaction with a version of the EAP documented in RFC 2284. Second, it protects the WEP key exchange mechanism by using TLS. Let’s start with a look at the EAP over LAN (EAPOL) mechanism defined in 802.1x.

Figure 2 shows a standard EAP transaction, in which a client, called a peer, negotiates an authentication protocol with a network access device, called an authenticator. When the peer requests to connect, the authenticator first sends an EAP-Request/Identity packet. The client responds with its name and a flag indicating that it’s ready to start an EAP transaction. The authenticator then sends an EAP Request containing the required authentication type. (The original EAP RFC defined MD5-Challenge, One-Time Password and Generic Token Card as authentication types. Many others are now in use.) The peer responds with the required credentials. The authenticator validates the credentials then sends an EAP Success message.

Figure 2. The process through which a wireless station authenticates to the network.

Authenticating Through RADIUS
Figure 3 shows how the EAPOL mechanism defined by 802.1x modifies the basic EAP transaction by introducing a third party called a Remote Access Dial-Up Services (RADIUS) server. The network access point (which can be a wireless access point, switch, remote access server, and so on) is the EAP authenticator. The client (a wireless station, in our case) is called a supplicant. The RADIUS server is called an authentication server. See RFC 2869 for details on RADIUS. Here is a typical transaction (the terminology is slightly different from standard EAP):

1. The wireless station (supplicant) sends a standard 802.11 authentication request to the access point (authenticator).

2. The access point responds with an EAP Request/Identity.

3. The station replies with an EAP Response/Identity that the AP then repackages into a RADIUS Access Request and forwards to a RADIUS server. From this point forward, the access point simply acts as a go-between and can be ignored.

4. The RADIUS server sends the station a RADIUS Access Challenge, essentially a demand for credentials.

5. The station replies with the requested credentials.

6. The RADIUS server validates the credentials and, if they pass muster, returns a RADIUS Access-Accept.

7. The AP repackages this into an EAP Success message that it forwards to the station. It also acknowledges the RADIUS Access-Accept by placing the station’s port into an Authenticated status. The station can now begin communicating with the access point.

Figure 3. Using a RADIUS server introduces a new authentication element.

TLS and 802.1x
EAP protects the initial wireless authentication. The next vulnerable portion of the transaction, the WEP key exchange, is protected using TLS. The authentication phase of a standard TLS transaction is designed to exchange a unique cipher key for use in encrypting subsequent data transfers. As we’ll see, TLS can generate cipher keys of any length, making it ideal for creating truly random WEP keys. To understand how the next generation of wireless access points will protect your data, it’s important to know how TLS authentication operates.

TLS authentication uses public key certificates to validate the identity of a client and a server. The principals validate each other’s certificates by comparing the digital signature of the certificate’s issuing authority to a copy of the certificate issued to the Certification Authority (CA). Figure 4 shows an example of such a certificate.

Figure 4. Certificate used in the Transport Layer Security authentication process. (Click image to view larger version.)

Inside the certificate is the public key of the issuing CA and a chain of CAs that extends right up to the root CA. Every certificate is digitally signed using the private key issued to the issuing CA. When a TLS server sends its certificate to a client, the client validates the certificate by decrypting the digital signature using the public key of the issuing CA. This means the client must have a copy of the issuing CA’s certificate.

The same is true in reverse if the TLS server needs to verify the identity of the client. As you might expect, given the potential for man-in-the-middle attacks in wireless communications, it’s highly desirable to use mutual authentication in wireless deployments of 802.1x. Here lies the rub. To achieve mutual authentication using certificates, the clients and the RADIUS servers must use certificates issued by trusted CAs. Trusted, in this case, means that each machine must have a valid copy of the root CA certificate and any subordinate issuing CA certificates.

Microsoft preloads root CA certificates from a variety of vendors into Windows, but certificates from these third parties don’t come cheap. Prices vary, but you can expect to pay $150 to $300 for a computer certificate and to pay again for each renewal. To avoid this cost, you can deploy your own CAs using Windows servers, but you must arrange to get a copy of the root CA certificate to the clients and RADIUS servers. Next month, we’ll see how to avoid the pain of distributing certificates to every user and computer, but this may require upgrading your access points and wireless adapters.

Master Secret Generation
TLS uses a PseudoRandom Function (PRF) that can generate all manner of secret keys, including WEP keys. The PRF is a hashing mechanism. A hash is a fixed-length value derived from a variable-length input in such a way that the input can’t be deduced from the output, similar to the operation of inexpensive Chinese restaurants.

The PRF uses two hashing algorithms, MD5 and SHA-1. The input is first divided in half, with one half hashed with MD5 and the other hashed with SHA-1. The results are then XOR’d together to produce a cipher key. If the output is shorter than the required key, the process is repeated again and again with the output of one cycle becoming the input to the next.

To get a unique output from the PRF, the initial inputs must be unique. TLS uses something called a “master secret” as a unique PRF input. The master secret isn’t actually exchanged between the client and server. Instead, the two principals exchange these elements:

A 28-byte random number generated by the client.

A 28-byte random number generated by the server.

A 46-byte pre-master secret generated by the client and delivered to the server in encrypted form.

The two 28-byte random numbers act as salt to prevent pre-calculating the PRF results and building an attack dictionary. (A “salt value” is defined by Microsoft’s Security Glossary as, “random data that is sometimes included as part of a session key.” The lack of salt in the generation of NTLM password hashes is the reason it’s so simple to mount a dictionary attack on Windows servers.)

To protect the pre-master secret, the client encrypts it with the server’s public key. It obtains this public key from the server via a certificate exchange. The server uses the associated private key to decrypt the pre-master secret. (Strictly speaking, the transaction could use Diffie-Hellman or some other method for generating a shared pre-master secret, but most TLS implementations use RSA certificates.)

Armed with identical copies of the two salt values and the pre-master secret, the client and the server now use the PRF to generate identical copies of a 48-byte master secret. The pre-master secret is discarded once the master secret has been generated.

The master secret isn’t actually a cipher key, though. It just forms one of the inputs into the PRF, which then generates a cipher key. These inputs are:

The master secret.

The fixed text phrase “Key Expansion.”

The 28-byte salt value generated by the client.

The 28-byte salt value generated by the server.

The PRF is capable of generating cipher material of any length. If the principals (wireless station and access point) negotiate 40-bit encryption, the PRF generates five bytes of cipher material. For 128-bit encryption, the PRF generates 16 bytes of cipher material.

TLS uses a suite of protocols to identify entities and protect data streams. These protocols are layered, so that a high-level protocol can make use of a more fundamental protocol. One of the fundamental TLS protocols is the Record protocol. This protocol defines how to exchange information about the TLS participants. 802.1x implementations such as EAP-TLS use the TLS Handshake protocol, which is layered on top of the TLS Record protocol. You’ll see referenced to both protocols in a network trace. The TLS Handshake protocol is used to exchange the following information: Client and server identity Client and server certificates Client and server cipher keys TLS Client_Hello The first step in the handshake is a TLS Client_Hello. When a client wants to connect to a TLS server, it sends a TLS Client_Hello message (see Figure a). This message contains the following information: SSL version (either 3.0 or 3.1) Session ID (set to NULL in first handshake) Timestamp (used to prevent replay attacks) Cipher Suite list (each of the encryption algorithms supported by the client) If the client wants to use compression and the compression type A 28-byte random number called a premaster secret (used a little later on in the handshake to create the TLS master secret) TLS Handshake Figure a. The TLS Client_Hello message. (Click image to view larger version.) TLS Server_Hello The server that receives the hello responds with a TLS Server_Hello message (see Figure b) and a TLS Certificate message that contain the following information: SSL version supported by the server Timestamp (used to prevent replay attacks) Session ID (used to permit quick reauthentications in later transactions) Cipher Suite selection (chosen from list supplied by client. In the example, the server selected RSA's RC4 streaming encryption with a 128-bit cipher key derived from an MD5 hash) Compress method (chosen from list supplied by client) Random number (used to salt any secret keys generated by TLS to support the selected cipher suite algorithm—salt prevents precomputational attacks.) Public key certificate for the server (as you can see from the screen shot, the certificate contains the name of the server and the clear-text portion of the certificate along with the public key). Figure b. The TLS Server_Hello and TLS Certificate messages. (Click image to view larger version.) TLS Client Key Exchange, Change Cipher Spec and Client Finish Now that we know how the client and server generate cipher keys using shared random numbers and premaster secrets, let's see how that information is exchanged. As a result of the initial handshake, the client now has a copy of the server's public key inside a public key certificate. The client validates this certificate by comparing the public key of the Certification Authority that issued the TLS server's certificate with the public key used to digitally sign the TLS server's certificate. If the certificate is valid, the client generates a 46-byte premaster secret and encrypts it with the server's public key obtained from the certificate. In this example (see Figure c), the client sends three different TLS messages in the same frame: Client Key Exchange (contains the premaster secret) Change Cipher Spec Client Finished (always sent after a Change Cipher Spec - note that Ethereal designates a "Finished Message" as "Encrypted Handshake Message") Figure c. TLS Client Key Exchange, Change Cipher Spec, and Client Finish. (Click image to view larger version.) TLS Change Cipher Spec and Server Finish At this point, the server must acknowledge the client's Change Cipher Spec with a Change Cipher Spec message if its own followed by a Server Finish message. With this handshake completed, the client and server are now free to exchange data using the TLS Record messages set aside for data transfers. The data will be encrypted using the protocol in the Change Cipher Spec message and the cipher keys generated from the master secret created from the premaster secret delivered by the client to the server. —Bill Boswell

Into the Air at Last
At this point, you've been introduced to each member of the cast of characters required to set up a secure wireless network. Next month, I'll address how to set up the various 802.1x configurations necessary to protect a wireless deployment.