Securing WLAN Links: Part 3

Securing WLAN Links: Part 3
Depending on which side of the wireless LAN (WLAN) fence you are on, you may like or dislike the wireless equivalent privacy (WEP) protocol. However, there is no escaping the fact that WEP alone is not good enough to secure 802.11 WLANs. With this in mind, designers need to explore new technical options in order to improve security in WLAN designs.

This is the final-part in a three-part series on securing WLAN links. In Part 1, we examined the inherent challenges with the wireless medium. In Part 2, we looked at the security challenges plaguing the 802.11 specification. Now, in this part, we'll look at the impact of SSL, IPSec, 802.1x and more on WLAN security.

Security at the Physical Layer
Although implementing security at the physical layer is not intuitive, it can be done. Security implementation at the physical layer exploits the fact that modulation is done at this layer. In a frequency division multiple access (FDMA) system, for example, the source may invert the frequency spectrum before transmission. This frequency inversion is a level of deterrence providing security.

The same technique can be extended to provide better security in WLAN system architectures. For example, the sender may divide the spectrum into various frequencies and use the different frequencies in a pre-determined fashion. Obviously, this requires that both the sender and the receiver share this secret of frequency-pattern.

Spread-spectrum systems also have an inherent security mechanism since data meant for a particular receiver cannot be decoded by any other receiver. This means that even if a receiver has physical access to data meant for another receiver, he or she cannot decode the data unless he or she knows the destination's code.

Although, physical layer security implementations do not provide robust protection against attacks, they do create a level of deterrence against passive attacks or against possible cross-connects and adjacent channel interference.

Link Layer Security
All wireless data networks have security implementations at the data link layer. This is natural since ideally the media-specific characteristics should be hidden at the data-link layer so that the network and other higher layers do not have to handle these issues.

By securing the data link layer, designers can ensure that all traffic traveling over a WLAN channel is encrypted. Additionally, this providing security at this level ensure that security is provided to all applications/layers and yet is transparent to them. Thus, through data link layer encryption, design engineers can prevent a hacker from using the information present in the channel to tap into a WLAN network.

There are some problems with encrypting all traffic using data link layer encryption. For this encryption scheme to work, all intermediary nodes (switches, routers etc.), which process data must be capable of decrypting this data, which is not a sure bet in today's wireless networks.

Even if all nodes can decrypt data, there are still some security concerns here. Nodes in the network will decrypt data in the open. Thus, even though the WLAN system is secure, the overall network is still open to attacks.

Overhead is another issue here. Data link layer encryption requires a key exchange at every link in the network. This creates additional overhead on the nodes and the whole network.

IPSec Can Help
IPSec is IETF's solution to end-to-end security. It is a framework of open standards for ensuring secure, private communications over IP networks. IPSec combines several different security technologies into a complete system. In other words, IPSec does not enforce what algorithms to use; instead it is an umbrella protocol that specifies how key components should work together to achieve security.

IPSec operates in-between the network (IP) and the transport (TCP/UDP) layer. This means that all packets emitted by the transport layer are encrypted via IPSec into the IP layer. In Figure 3, IPSec gateways process IP packets without accessing the transport headers. Because of its position in the OSI stack, IPSec provides secure communication to all applications and does so without changing the IP layer. This is a great advantage.

Figure 3: Example of how an IPSec gateway process IP packets.

IPSec has three major elements: the authentication header (AH), encapsulation security payload (ESP), and Internet key exchange (IKE). IPSec uses various public key cryptography (PKC) techniques to ensure that keys are shared only between two devices. Once the keys are shared, all data going onto the public Internet from the LAN is encrypted using the session keys. At the same time, an authentication header is attached to each IP packet so that the remote end can ensure the validity of the data and the sender.

In Figure 3 above, the two IPSec gateways at site A and B would be responsible for implementing IPSec. None of the other nodes in the LAN implement (or are aware of) IPSec. The gateways are responsible for encrypting outgoing packets and authenticating incoming IP packets.

IPSec is a great security solution. It avoids the problems of decrypting and then encrypting at each node. Also, the application layer data remains encrypted till it reaches the destination and cannot be opened mid-way. The key negotiation is also done between communication end-points and this reduces overhead.

However, implementing security at the end-points, as IPSec does, means that data being sent by layers above the network layer is being encrypted. Lower layer data like routing and protocol information is sent without encryption. Hackers can tap into this unencrypted information and use it a a means to tunnel into the WLAN network.

Evaluating SSL
The secure socket layer (SSL) protocol provides another option for WLAN designers. SSL is used by web-browsers to secure data being exchanged by the browsers.

SSL, however, is not the best option for WLAN designers. The basic problem with SSL is that operates at the application layer. This leads to two drawbacks. First implementing security at the application layer means that each application which wants security needs to do so itself. In other words, the onus of responsibility is per-application. This means additional effort on part of the application and inter-operability issues for every application.

Second, packet headers of lower layers (almost the whole protocol stack) are plain-text. This means that although the data being sent by the application is secure, packets over the network can be sniffed to find out information present in the headers.

Problems Still Remain
Clearly, designers can use IPSec, SSL etc. over the wireless access medium between mobile hosts and APs to ensure secure communications. The question is does this solve our problem?

The answer here is yes and no. Yes, because using these techniques at different layers definitely increases the overall security of the network. No, because security mechanisms at higher layers mean that only data sent by layers is being encrypted. Data in the packet header still remain open to attacks.

A solution for securing the packet header could be on the way. The IEEE has proposed a long-term security architecture to fill the security loopholes of access control, authentication, and key management present in 802.11 architecture. The proposed solution is known as the robust security network (RSN), which is based on the 802.1x standard.

The 802.1x standard provides some interesting security benefits to WLAN system designs. Let's take a deeper look at how.

802.1x Authentication, Access Control
IEEE 802.1x provides an architectural framework on top of which an implementation can use various authentication schemes and algorithms. The actual algorithm that is used to determine whether a user is authentic is left open and multiple algorithms are possible.

802.1X uses an existing protocol, the extensible authentication protocol (EAP) for message exchange during the authentication process. The EAP is built around the challenge-response communication paradigm that is common in network security solutions.

In an 802.1x-equipped WLAN, a client (known as the supplicant) requests access to an access point (known as the authenticator). The access point forces the user (actually, the user's client software) into an unauthorized state that allows the client to send only an EAP start message. This is done by having two ports open per supplicant / client. The uncontrolled port allows only EAP packets to pass through into the LAN. The controlled port, which allows all packets is opened only after the supplicant/client has been authenticated (Figure 4).

Figure 4: Example of dual-port operation in an 802.1x-enabled system.

The access point (AP) returns an EAP message requesting the user's identity. The client returns the identity, which is then forwarded by the access point to the authentication server. The application server then uses an algorithm to authenticate the user and returns an accept or reject message back to the AP. Assuming an accept was received, the AP changes the client's state to authorized and normal traffic can now take place.

Clearly, 802.1x looks good on paper. But 802.1x provides some concerns as well.

The big problem facing 802.1x is that the authentication between the client and the network is still only one-way. This means that there is still no way for the client (mobile) to authenticate the network. The port on the client is always considered authenticated. The trust assumption that is reflected from this design is that the access points are trusted entities. This is an invalid assumption since rogue nodes can masquerade as an AP. It has been shown that a hacker can compromise an entire 802.1x-enabled network using a handful of forged EAP packets.⁷

802.1x key management
In WEP, wireless traffic is encrypted with RC4 by combining the IV and the shared key (root key) to generate an encryption key. It is unsafe to use the same encryption key twice. Without a mechanism to update the root key, the IV is the only thing preventing duplicate encryption keys. Unfortunately the WEP IV is far too short to meet this requirement given that a new encryption key is needed per transmitted frame.

To improve upon the security provided by WEP, 802.1x provides an optional capability called broadcast key rotation (BKR). Under this technique, the AP periodically broadcasts the WEP shared/root key. The period of broadcast is a user configurable interval. The mobiles create session encryption keys by combining the IV with the broadcast root key.

Two things are noteworthy here. One, the broadcast root/shared key is never directly used for encryption. Two, unlike WEP, "key-hopping" cycles not only through IV space but also through the session key set. The cryptographic implication is that the key-space is larger than before and whenever the WLAN comes close to running out of encryption keys, the AP may broadcast a new root key thus generating a brand new key-space.

Since the root key is broadcast over an unsafe network, an intruder may generate the session keys from the captured root key and then try to look for frames encrypted with the same IV. However, it's important to note that that the time period in which the intruder has to detect a key-collision has been reduced to a session-time. Since the users can control the duration of a session (usually in the order of seconds) by configuring the root key broadcast interval, BKR dramatically improves the level of security provided by WEP. However, BKR is an option and is turned off by default.

802.1x also provides an optional temporary key integrity protocol (TKIP). This feature defends against an attack on WEP in which the intruder uses the unencrypted IV in encrypted packets to calculate the WEP key. This is achieved by hashing the key just before using it for encrypting a packet. This removes the predictability that an intruder relies on to determine the root key by exploiting IVs.

Message Integrity
As far as message integrity is concerned, 802.11 fails because it uses the linear CRC-32 to ensure message integrity. In 802.1x, a non-linear message integrity code (MIC) prevents bit-flip attacks on encrypted packets. During a bit-flip attack, an intruder intercepts an encrypted message, alters it slightly, and retransmits it, and the receiver accepts the retransmitted message as legitimate. The MIC, implemented on both the AP and all associated client devices, adds a few bytes to each packet to make the packets tamper-proof.

Final Thoughts
In this three-part series, we've laid out some of the problems and potential solutions for improving WLAN security. Clearly, there are some definite benefits to implementing new architectures, like 802.1x. But, these new architectures also feature some security holes that will create headaches for designers. Fortunately, chip vendors, system houses, and standards organizations are stepping up here to address these issue and bring even high levels of security to WLAN links.

Editor's note: To view Part 1 of this series, Click Here, To view Part 2, Click Here.

References

1. Applied Cryptography — Bruce Schneier.
2. Wireless Security — Randall Nicholas & Panos Lekkas.
3. Unsafe at any key size; An analysis of the WEP encapsulation — Jesse R. Walker (Intel)
4. (In)Security of the WEP algorithm — Nikita Borisov, Ian Goldberg, David Wagner (University of California, Berkeley).
5. Cisco's White Paper on IPSec.
6. Pesky Home Networks Trouble Cable Behemoths -- Steven M. Cherry (IEEE Spectrum, April 2002)
7. An Initial Security Analysis of the IEEE 802.11X standard — Arunesh Mishra, William A.Arbaugh (University of Maryland, College Park)
8. Making Unbreakable Code -- Justin Mullins (IEEE Spectrum, May 2002)

About the Author
Praphul Chandra is a software design engineer at Teleogy Networks, a Texas Instruments Company. Praphul obtained his Bachelors in Electronics Engineering from IT-BHU, India. Prior to joining Telogy, he worked for Lucent Technologies and Tachion Networks. Praphul can be reached ay pchandra@telogy.com.

Author's Note: This article represents the author's own thoughts and understanding of the subject matter, and in no way reflects an official or unofficial position of Telogy Networks or its parent company Texas Instruments.