Living With 802.11 Security... Securing 802.11 WLANs (Part 2 of 3)

We can use IPSec, SSL etc. over the wireless access medium between mobile hosts and APs to ensure secure communications. Does this solve our problem? 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 data being sent by those layers is being encrypted but what about data in the packet headers appended by lower layers. Data like routing and protocol information is sent without encryption and so an attacker might utilize the information inherent in the unencrypted data to find out the information (for e.g. the end-parties involved in the communication) that the user might not want to reveal.




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) and uses the 802.1X standard. The 802.1X standard for Port based Network Access Control provides an authentication framework for wireless LANs, allowing a user to be authenticated by a central authority.

802.1X Authentication and 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. This is very similar to HIPERLANs approach of security. 802.1X uses an existing protocol, the Extensible Authentication Protocol (EAP, RFC 2284), that works on Ethernet, token ring, or wireless LANs, 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 a wireless LAN with 802.1X, 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. See Figure below.) The access point 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, which uses an algorithm to authenticate the user and then returns an accept or reject message back to the access point. Assuming an accept was received, the access point changes the client's state to authorized and normal traffic can now take place.


Dual Port operation in 802.1X

It all looks good on paper, and indeed, vendors have already begun adding 802.1X support to their products. But the devil is in the details. The problem 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 in the wireless medium, it is very easy for a rogue node to masquerade as an AP. It has been shown [7] that all it takes is a handful of forged EAP packets sent by someone posing as an access point and the whole framework is compromised.

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). In 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. 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. Note however that the time period in which the intruder has to detect a key-collision has been reduced to a session-time. Since the duration of a session (usually in the order of seconds) can be controlled by the user 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.

Another option in 802.1x to improve upon the security provided by WEP, is called TKIP (Temporal Key Integrity Protocol) a.k.a. WEP key hashing. This feature defends against an attack on WEP in which the intruder uses the unencrypted initialization vector (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 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 access point and all associated client devices, adds a few bytes to each packet to make the packets tamper-proof

Numerous wireless architectural models use numerous security schemes even though the underlying concepts of all these schemes are the same : PKC for key distribution, SKC for encryption and one-way hash functions for data integrity and authentication. All architectures that I studied had some loopholes. Let us hope that these would hopefully be taken care of the near future and we would be able to communicate securely without Big Brother watching over our shoulder :)

About the Author

Praphul Chandra (PChandra@telogy.com) obtained his B.Tech in Electronics Engineering from IT-BHU and is currently working as a Software Engineer in Telogy Networks, a Texas Instruments company. He is also pursuing my MS in Electrical Engineering (part-time) in Columbia University. This paper "Security in Wireless Networks", written as a Project Report for my MSEE course work, represents his own thoughts and understanding of the subject matter, and in no way reflects official or unofficial position of Telogy Networks or its parent company Texas Instruments.

Got comments,feedback? Send it to WirelessDevNet

See Also "802.11 Security" Part I

---

Does your company have a solution, news, event, or scoop that WDN should know about?
Send details to editors@wirelessdevnet.com