802.11ac and 802.11ad: What raw speed means for security

I’ve written previously about the possibilities for gigabit Wi-Fi coming with the future 802.11ac and 802.11ad standards. In today’s post, I’ll be taking a closer look about what that raw speed means for security. (As far as the title goes, well, let’s just say that in the mid-1980s, I was just like every other boy in my school. I wanted to be a U.S. Navy fighter pilot.)

In Wi-Fi security, there is a natural dividing line in 2004, which is the year that the IEEE finally approved the 802.11i-2004 amendment after three years of debate and refinement. The technologies specified in 802.11i, in particular the Counter Mode with CBC-MAC Protocol (CCMP), were used as the linchpin in the Wi-Fi Alliance’s WPA2 certification program.

CCMP was originally used at data rates of 54 Mbps with the existing 802.11a/b/g networks. For 802.11n, CCMP was extended to work with new handshakes, but was largely unchanged. In fact, security had become so critical by the time of 11n standardization that CCMP is the only standard method of protecting fast 11n frames.

Cryptographic systems are composed of multiple components. Many people focus on the encryption algorithm itself (in the case of CCMP on Wi-Fi, it’s AES), but there are additional considerations. Encryption algorithms can be used in different ways, and these precise specifications are called “modes.” Modes describe how many bytes of data are encrypted at a time, and how the encryption is extended over large numbers of bytes for payloads like a LAN frame or TCP segment.

A rough analogy would be to say that if the encryption algorithm is the task of driving, then the mode would be like the individual laws in each jurisdiction. Same core task, but it can be done slightly differently – consider the speed laws on the Autobahn in Germany versus superhighways elsewhere, or the way that some countries drive on the right side of the road versus the left side of the road. (Even though I learned to drive in the United States, I have an odd preference for driving on the left, but that is another story.)

CCM, the Counter Mode with CBC-MAC, describes a particular way of using AES. As it’s written, AES only encrypts 16 bytes at a time, which means that the mode of operation needs to handle all lengths of WLAN data frames, from the shortest ARP frame on up to a maximal-length aggregate. To deal with frames of arbitrary length, CCM divides the encryption payload into chunks (or “blocks”) of 16 bytes, and then it “chains” them together.

The first 16 bytes chunk is encrypted, and its output is used as part of the encryption of the second 16 byte chunk, whose output is used for the third 16-byte chunk, and so on. This “chaining” process that strings together chunks is also reflected in the name – the “CBC” in “CBC-MAC” refers to this process, which is called cipher block chaining.

For implementation purposes, chaining requires that each 16-byte chunk be encrypted sequentially, so frame encryption requires that the entire data frame be processed one block at a time. For technical reasons, CCMP also requires two AES operations per chunk, so a standard 1500-byte Ethernet frame requires roughly 200 AES operations.

Both the high number of AES operations and the need to process them sequentially have many engineers within the 802.11 working group questioning whether CCMP can scale to gigabit rates, especially for use with very large (but very efficient) aggregate frames.

Fortunately, there is appropriate technology available. The same AES encryption algorithm continues to be used, but with a slightly different framework called the Galois/Counter Mode (GCM). Compared to the older CCM, Galois/Counter Mode is significantly more efficient in both operation and implementation. GCM requires only one AES operation per block, which is half the load.

More importantly, GCM is not a chained mode. When implementing GCM, each block of data can be processed independently, which can be used by hardware engineers to build parallel circuits with higher throughput because there is no need to wait for the previous block operation to complete.

GCM has been widely standardized: it appears in 802.1AE-2006 (MACsec) and IPsec’s Encapsulating Security Payload (ESP), for example.

GCM is being standardized as part of a protocol named GCMP, the Galois/Counter Mode Protocol. The only downside to adopting a new security protocol is that it is not backwards-compatible with existing Wi-Fi radio chips, much like the early radio chips used for 802.11b did not support AES. GCMP can’t be retrofitted on to existing 802.11n APs, nor can it be added into existing devices that perform Wi-Fi cryptographic operations. At Aerohive, the security is built into the AP. When you upgrade APs to get more speed, you get hardware capable of better security as part of the package.

All that you’ll miss out on is worrying about whether your controller is fast enough to keep up with the new traffic load. Centralized WLAN controllers are often set up to perform the existing CCMP decryption. The capacity of a centralized encryption concentrator, however, doesn’t grow as you upgrade to new radio standards, nor does the controller’s specialized CCMP crypto hardware learn to speak GCMP.

Matthew Gast is the Director of Product Management at Aerohive Networks. He currently serves as chair of both the Wi-Fi Alliance's security task groups, was the first chair of the Wireless Network Management Marketing task group, and is the past chair of the IEEE 802.11 revision task group.

Our latest thought leaders