Illustrations by Jonas Ekman.

WiFi security is a mess. The subject has an acronym ratio that would make a NASA space shuttle manual proud and it seems like most areas of it overlap in some non-obvious fashion. I find that understanding why something strange is strange helps, but the “why” is never clearly explained in the various standards and design guidelines that constitute the pillars of the WiFi security morass. Yes, I prefer my metaphors mixed and non-sensical.

So the purpose of this text is to try to bring some clarity into the alphabet soup — without delving too deeply into the details — while also illuminating some of the reasons things ended up the way they are. There are a couple of good texts that explains the nitty-gritty but if you just want to know how the hell TKIP relates to RC4 or what the difference is between WPA2 and RSN: read on.

A concept that is important to keep straight is the difference between authentication and confidentiality. Usually people think “encryption” and are satisfied with that, because an encrypted communications channel of any quality provides both authentication and confidentiality. But for this discussion it is important to remember that the two concepts are different. Authentication means that you know with whom you are communicating. Confidentiality means that only the intended recipient can understand your communication. Clearly, confidentiality without authentication is a non-starter. After all, if you don’t know with whom you are communicating, you don’t know who is reading your messages. Authentication without confidentiality however, is conceivably useful. For instance, if you don’t care about keeping your messages secret, but want to prohibit your neighbour from freeloading on your WiFi network, then you might implement authentication without confidentiality.

I’ll be using the words “access point” and “station” a lot. An access point (or AP) is the WiFi “base station” — it might be a wireless router or an Apple TimeCapsule or a dedicated access point. It is the thing that provides WiFi access (hence the name) to a wired network. A station is the thing that connects to the access point — a PC or a tablet or a phone for example. If you want to be strict about it an access point is also a station but outside of the actual standard “station” usually means “a WiFi-device that is not an access point”. That is also what I will mean by “station”.

The need for WiFi security

Lets begin at the bottom: the ethernet layer. In a normal ethernet network, data is transmitted in the clear over physical wires. And people seem to be fine with that. Anyone with physical access can eavesdrop on all the traffic, but on the other hand anyone with physical access can cart off your whole computer. In a WiFi network, traffic is ending up all over the place. You can easily eavesdrop on WiFi traffic from a nearby location. You can also easily send fake traffic into the WiFi network. The designers of WiFi thought that this was a problem (because the only way to live with the dullness of standards work is vigorous porn surfing), so they added some security measures to the standard: something called Wired Equivalent Privacy, or WEP.

WEP

WEP is pretty simple to understand. It deals only with the ethernet layer. It provides two authentication methods called Open System (which is actually no authentication at all, so that makes sense…) and Shared Key. It also provides confidentiality by encryption using the RC4 cipher. Note the difference between confidentiality and authentication — it is perfectly fine to use Shared Key authentication but no encryption. If your WiFi adapter is steam powered perhaps traffic encryption is prohibitively slow but since the authentication procedure happens only once you could probably live with that being a bit sluggish.

I should mention here that Shared Key authentication has a flaw that makes it easier to crack a WEP encryption key. For this reason you should never use Shared Key authentication. If you must use WEP, use Open System authentication with traffic encryption (and also be aware that WEP as a whole is easily cracked these days).

Both the Shared Key authentication system and the RC4 traffic encryption needs some sort of key to work. The WiFi standard, IEEE 802.11, specifies what the keys should look like but not (yeah, I’m laying down the law here) how you get them. This is important. How the keys end up in the encryption engine is “out of scope of the standard” which is standardese for “if you ask us about this we’ll set fire to your car”. What this means in practice is that it is up the designer of the WiFi adapter to decide on a way to enter encryption keys into the system. It might be via a keyboard (sensible), via punch card (impractical) or via Aldis lamp (silly).

WEP keys can be 40 or 104 bits long and honest people calls that WEP-40 and WEP-104 while people who can’t count calls it WEP-64 and WEP-128 (because that sounds more secure).

It is worth mentioning that WEP keys are strings of binary data, not “passwords” in the usual sense (like your mothers maiden name for instance). The security professional, being a bit of a bastard, calls what you normally think of as a password a “pass phrase”. People normally find it easier to remember some kind of word than a string of hexadecimal digits so it would be nice to have some way to turn a pass phrase into a WEP key and there are indeed many ways that this can be accomplished. Unfortunately, translating a pass phrase to a WEP key is “out of scope of the standard”. Which means that any access point might do it their own way, resulting in incompatibilities and chaos. In fact, what most manufacturers do (if they support pass phrases at all) is allowing fixed-length pass phrases where the ASCII representation of the pass phrase is used directly as the key.
This is pretty simple to implement but it significantly weakens WEP because it effectively restricts the number of actual bits in the key which makes it easier to crack.

As you may have gathered by now, WEP is a bit crap. The standards guys soon started getting angry notes from their bosses about the porn surfing again. Being engineers, they immediately set to work trying to solve the problem properly by introducing lots of acronyms.

In all fairness it should be stated that WEP never was intended to be a super-secure solution. As the name implies it was intended to merely provide “wired-equivalent” security. Something some people, red faced and with veins pumping at the temples, will loudly denounce as “no security at all!”

802.11i – RSN

The 802.11i standards team meant to fix the security problems present in WEP. They defined something called a Robust Security Network, or RSN, by which they mean a WiFi network using the new security measures described in the 802.11i standard, as opposed to pre-RSN security measures (meaning WEP). In order for us to have another acronym a RSN is established through a RSN Association, or RSNA.

802.11i defines two new types of confidentiality, essentially types of encryption although calling them types of encryption can lead to some confusion as we will see.

The first type is called Temporal Key Integrity Protocol, or TKIP for short. TKIP is intended to be a transitional encryption type (translation : TKIP is also a bit crap, but less crap than WEP). TKIP uses the same type of encryption algorithm, RC4, as WEP which is what’s transitional about it — it is possible to implement TKIP on hardware designed for the original 802.11 standard, hardware that normally has RC4 encryption implemented in… er… hardware.

Why not call TKIP RC4 you ask? In fact, why not call WEP RC4 as well and get rid of two acronyms at once? Well, as the P in TKIP implies, TKIP is really a protocol. It specifies what the keys should look like. RC4 is a stream cipher and the data to be encrypted is packet based so the protocol also specifies such things as how the data to be encrypted should be “chunked” before being encrypted, how to pad any chunks that are too small, and so on. These details are different for WEP and TKIP, thus the different names. Another way of looking at it is that if the hardware supports RC4 encryption, TKIP and WEP can be implemented in software on top of it.

The second type of confidentiality is the splendidly named Counter Mode with Cipher-Block Chaining Message Authentication Protocol, or CCMP (if you don’t think the acronym makes sense, CCMP is actually short for CTR with CBC-MAC Protocol; “My acronym is too long guys. This calls for a new acronym!”). In the same way as TKIP is a protocol using the RC4 encryption algorithm, so CCMP is a protocol using the AES encryption algorithm.

CCMP — now that is a confidential type of confidentiality if you ever saw one. Rest assured, your porn is safe here! At least for the moment. At least as far as I know.

One important aspect of both TKIP and CCMP is that they use so-called Temporal Keys. A temporal key is only used for a short time and is then discarded. Limiting the amount of data being encrypted by the same key makes the key harder to break. Two parties that are to communicate using TKIP or CCMP needs to do a little dance called a “four-way handshake” during which they negotiate a set of temporal keys that are used only for this session. The four-way handshake derives the temporal keys from the “normal” key. This “normal” key is called a master key and is normally equivalent to a pass phrase (with some extra processing to make a binary blob out of it). There are two types of master keys. Pairwise Master Keys are used for unicast data and Group Master Keys are used for multicast data. Avoiding acronyms is just not serious security so these keys are called PMKs and GMKs for short. For the sake of this discussion the pairwise and group master keys behave in the same way so I’ll just say “master key” and you can substitute it with “PMK or GMK” if you like. How the master key ends up in the system is… you guessed it, “out of scope of the standard”, but it is commonly entered by the user (or the users children).

EAPOL

There is a slight problem: the four way handshake happens before encryption can start because the encryption needs the key that is the result of the four way handshake. This means that the four way handshake must happen in the clear. This is such a massively complicated concept (“First unencrypted? THEN encrypted??? My God, man! I need to go lie down for a bit.”), that we apparently needed another standard for it. 802.1x (not a typo, 802.1x is part of the 802.1 family of standards, not the 802.11 family, and is applicable to other types of networks as well) essentially describes, in a very complicated way, a model where you communicate using two ports. One encrypted port and one unencrypted port. These ports are opened and closed magically.

I’ll summarise the important points about 802.1x here: A 802.1x port has nothing to do with ports in a switch, ports in a firewall, ports in a storm, disgusting beverages or the left side of a boat. To quote Monthy Python and the Holy Grail : “It’s only a model.”. 802.1x defines a packet type, called EAPOL (for EAP Over LAN (or Extensible Authentication Protocol Over Local Area Network (are we LISP yet?))), which is used to negotiate authentication parameters in the clear. The four-way handshake is performed using EAPOL packets. Once a temporal key has been generated then traffic starts being encrypted. When the 802.1x standard says “sending to the unauthenticated port” it means sending data without encryption and when is says “sending to the authenticated port” it means sending data with encryption. The unauthenticated port only allows EAPOL packets, all other packets are discarded.

Establishing a RSN assumes that that both parties (the access point and the station) have copies of the same master key, which has been put there through occult means. The station connects to the access point using the Open System authentication method (in other words: the connection is unencrypted and unauthenticated). When the connection has been made a program called a “supplicant” on the station performs the four-way handshake with a program called an “authenticator” on the access point. As we’ve already seen this handshake is performed by exchanging EAPOL packets. When the handshake has been completed then the station and access point each have an agreed-upon temporal key which they then start to use. If you sniff the WiFi traffic when a RSN connection is set up you can see the EAPOL packets in the clear and then encrypted packets after the handshake has been completed.

One consequence of the use of temporal keys is that if you want to decrypt a TKIP or CCMP connection using a packet sniffer like Wireshark, it is not enough to have the pass phrase. The sniffer has to have access to all the packets in the four-way handshake because that information is necessary to generate the temporal key from the pass phrase.

WPA/WPA2

Now, you’d be excused for grumbling “Why are you going on and on about this RSN thing that no-one has ever heard of? I want to know about WPA.” There’s actually a funny story behind that…

Ok, the story is not that funny. What happened was that the IEEE group that developed the RSN-specification (called, as mentioned, 802.11i) took a long time to agree. The 802.11i specification spent years and years in “draft” status which meant that you could read it and comment on it but it was not approved as a finished standard. In stepped the WiFi Alliance: a group of super-villains^H^H^HWiFi Manufacturers that banded together to try to make WiFi easier to use. The WiFi Alliance actually owns the trademark on the word “WiFi”; if not for them you would have called it “802.11b and 802.11g and 802.11n and 802.11ac” instead, so be grateful.

The WiFi Alliance recognised the threat to porn surfing posed by the weakness of WEP and the delays of 802.11i, so they took action. By picking some of the most useful bits of the 802.11i draft they could set their own intermediate standard that manufacturers could start to use while waiting for the 802.11i working group to extract their digits from their posterior apertures. The result was named Wireless Protected Access, WPA for short. WPA is pretty similar to RSN but lacks some features such as pre-authentication. It uses the same four-way handshake, the same crypto (although CCMP is optional in WPA) and the same key types as RSN.

Access point capabilities are announced in something called “Information Elements”. RSN-capabilities are announced in a special RSN information element but WPA could not use this since it would conflict with 802.11i if that ever settled. Therefore WPA had to use a special information element that had been set aside for vendor-specific extensions: the so called Vendor Specific Information Element. The vendor is identified in the vendor-specific information element by including a OUI prefix and for some reason WPA uses the OUI prefix belonging to Microsoft. Don your tin-foil hat here.

The WiFi Alliance has also specified WPA2 which is based on the final 802.11i standard. WPA2 includes all parts of 802.11i that are mandatory and is fully compatible with 802.11i. So you might variously see security settings being named “802.11i”, “RSN”, “WPA2” or as combinations thereof — they all describe the same thing. If you want to be strict about it, 802.11i _defines_ RSN and WPA2 uses 802.11i to define a limited but compatible RSN, so the proper name for this type of security would really be “RSN”. Since WPA isn’t compatible with the RSN specified by 802.11i (because it uses a different information element) it cannot really be called a RSN (in my humble opinion). Device manufacturers might be forgiven for presenting the options as “WEP, WPA or WPA2” instead of “WEP, WPA or RSN”.

WPA-Personal and WPA-Enterprise

You may remember me claiming that the way the master key is entered into the system is out-of-scope of the standard (how could you possibly forget?). So how would you actually manage the master key in the real world? The simplest way, which is probably the most common, is as a so-called Pre-Shared Key. The Pre-Shared Key is a pass-phrase that you enter into your access point on the one hand and into the devices you want to connect to the access point on the other hand. It turns out that you sometimes need a more sophisticated solution though. For example, say that you manage an company with a few hundred employees. Every person who needs to use your WiFi network needs to know the pass phrase. This is already pretty bad because every employee can decrypt everyone else’s traffic when they know the pass phrase. Even worse, if you have to strap a minion to an ejection seat after they’ve sold company secrets to a competitor you need to change the pass phrase everywhere to keep him or her out.

Wouldn’t it be pretty convenient to have a key management system where you could assign pass phrases to individual users in a centralised fashion and then use those pass phrases to generate unique master keys for users as they try to connect to the WiFi network? Is that a “Hells Yes!”? I thought so.

In order to support a centralised key management system the access point must allow the station to somehow communicate with a third party for the key exchange : the station needs to verify the user pass phrase with the key management system. This is where the layering abstraction gets a bit muddled. It would be nice and clean if the 802.11i standard could just leave the whole key-management issue to some upper layer but unfortunately it can’t — it must provide a means for conveying the authentication traffic between the station and whatever key management system exist in the network. This traffic doesn’t really belong in the “ethernet” layer as it could span many different network technologies. If this makes you feel as if 802.11i is trespassing on OSI layers that it should leave well enough alone, I understand you. On the other hand, if the 802.11i working group had tried to fix it some other way they would have had to create a bunch of extra architecture-astronaut standards and there would probably have been XML in there somewhere. Let us count our blessings and live with the warts.

As fortune would have it, supporting authentication in a network is basically what our old friend 802.1x was designed for so 802.11i uses that. In 802.1x the password management system is called an authentication server (AS). The authentication server works together with the supplicant (on the station) and the authenticator (on the access point).

The role of the authenticator is different in the pre-shared key case and in the 802.1x case. With a pre-shared key the authenticator is the party that negotiates the temporal key generation with the supplicant. With 802.1x the authenticator only acts as an intermediary: it allows the supplicant to communicate with the authentication server using EAPOL while blocking all other traffic to prevent the station (which is still unauthenticated, remember) from accessing the network in any other way.

Using 802.1x for key management is a great idea and also a cause of terminological befuddlement. You see, the 802.11i standard calls the pre-shared key system “PSK” (for Pre-Shared Key), which is fine. But then it calls the password management system “802.1x” which is technically correct but confusing because the pre-shared key system also uses 802.1x for the four-way handshake.

In the interest of keeping things simple (an admirable goal) the WiFi Alliance left out the key-management parts of 802.11i from the “basic” WPA specification; what they called “WPA-Personal”,
sometimes also called “WPA-PSK”. Instead they defined an enhanced version of WPA called “WPA-Enterprise”, sometimes called “WPA-802.1x”, which includes the key-management support.

The most common key management system is called RADIUS. RADIUS is short for Remote Authentication Dial In User Service which tells you that RADIUS is not the most hip acronym on the block. Dial In was exciting back when porn was distributed on magnetic tape. In 802.11i RADIUS is not the only option for key management, other systems are allowed. However, WPA-Enterprise requires RADIUS and it is so common that when you speak of “RSN with 802.1x” (as you do) then RADIUS is often assumed.

The Brass Tacks

The brass… the… what? What? “Brass tacks”? Get it together English, that makes no sense at all.

What did we learn today? We learned that a RSNA using TKIP (RC4) or CCMP (AES) via PSK or a 802.1x AS is established through a WPA or RSN IE from STA to AP so the PTK/GTK can be derived from the PMK using EAPOL in IEEE 802.11i. FYI: that SOB is a real PITA.

Also, I lied when I titled this post “A Brief Guide…”