Security Issues with Wi-Fi, Bluetooth, and ZigBee

There is hardly a consumer product today that does not have one or more wireless interfaces. Cell phones typically add Wi-Fi and Bluetooth® radios. In home thermostats, “smart appliances,” and power meters using ZigBee® are starting to enable power monitoring and regulation via the Smart Grid, while ZigBee RF4CE-powered remote controls make life even easier for “couch potatoes.”

Each of these protocols has security issues that, if not recognized and addressed at the design stage, can have serious repercussions. This article will examine the security issues with these widely used wireless protocols. It will take a chip- and protocol-oriented approach and avoid issues like computer security or problems relating to different network topologies, each of which deserves a separate article, if not a book.

Wi-Fi

With over a billion Wi-Fi chipsets shipping each year, the Wi-Fi Alliance’s claim that “Wi-Fi is everywhere” is hardly an exaggeration. While Wi-Fi is by far the most widely used wireless networking protocol, it has gone through numerous iterations in an attempt to resolve its security problems, which are now arguably behind it – with one caveat.

WEP
When the original IEEE 802.11 standard was ratified in September 1997, it relied on the wireless equivalency protocol (WEP) for security. In the shared-key authentication version of WEP, the client sends an authentication request to the access point, which replies with a plain text challenge; the client then encrypts the challenge using a WEP key and sends it back. If the returned key matches, access is granted.

WEP uses the RC4 stream cipher, the same one used in secure socket layers (SSL) to protect Internet traffic. Initially 64-bit WEP used a 40-bit key (later 104 bits) that was concatenated with the 24-bit initialization vector (IV) to form the RC4 key. Unfortunately the IV key was transmitted as plain text and used repeatedly, making it fairly straightforward for an eavesdropper to recover the key. When the FBI was able to crack WEP encryption within three minutes, the search for a better mousetrap began.

WPA
While the IEEE was working on IEEE 802.11i, in April 2003 the Wi-Fi Alliance rolled out Wi-Fi Protected Access (WPA) based on a subset of that pending standard. For encryption, WPA used the Temporal Key Integrity Protocol (TKIP), which generated a new 128-bit key for each packet, thereby plugging the major security hole in WEP.

To verify the integrity of packets, WPA uses much stronger message authentication codes than the cyclical redundancy checks (CRC) used by WEP. WPA relies on IEEE 802.1X, which defines an authentication mechanism for 802.11 networks. For enterprise users, WPA uses the Extensible Authentication Protocol (EAP) – specifically EAP-TLS, which provides transport layer security; for residential and consumer users, WPA uses a pre-shared key (PSK) system. While WPA is far more secure than WEP from passive attacks, its PSK implementation can be fairly easily cracked by a brute force attack if you have a weak password.

WPA was always intended as an interim solution until IEEE 802.11i was ratified. WPA is far more robust than WEP but not nearly as strong as WPA2, which replaced it.

WPA2
The Wi-Fi Alliance rolled out WPA2 based on IEEE 802.11i after it was ratified in June 2004. IEEE 802.11i added two new handshake protocols to the original 802.11 specification in order to enable robust security network associations (RSNAs).

For encryption, WPA2 utilizes the Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP), which does AES encryption using a 128-bit key and a 128-bit block size. CCMP replaced TKIP, which had proved vulnerable to a variety of attacks. Without getting into the details of AES encryption, suffice it to say it has been the Mount Everest of code crackers since the National Institute of Standards and Technology (NIST) first introduced it in 2001. It took ten years before the first successful key recovery attack on AES-128, which required 2^126.1 operations. Bottom line: Wi-Fi with WPA2 is quite secure.

Table 1 summarizes the major differences between WEP, WPA, and WPA2. Texas Instruments’ “Introduction to Wi-Fi Technology” product training module (PTM) provides a good overview of the technology, including security protocols.

	WEP	WPA	WPA2
Encryption	Manual key assignment, shared keys using Rivest Cipher 4 (RC4) stream cipher	TKIP based on RC4 stream cipher	Counter Mode with Cipher Block Chaining Message Authentication Code Protocol (CCMP) with 128-bit AES block cipher
Data Integrity	Linear hash function	Cryptographic hash function
Key management	No	Yes
Replay detection	No	Yes

There is still one weak spot in Wi-Fi security: Wi-Fi Protected Setup. For the average non-geek user, setting up a Wi-Fi network can be a daunting task. In 2007, the Wi-Fi Alliance introduced Wi-Fi Protected Setup, which greatly simplifies the procedure. Now instead of having to manually enter PSKs and SSIDs, users can simply enter a PIN code or even push a button on the router while the access point is nearby, quickly pairing the two devices. But the usual trade-off for increased simplicity is decreased complexity, which in this case resulted in reduced security. Wi-Fi Protected Setup has some well-documented design flaws that leave it open to equally well-documented brute force attacks. The bottom line is if your router features Wi-Fi Protected Setup and you're a geek – turn it off. SSIDs just aren’t that intimidating. If you’re designing an embedded device that uses Wi-Fi, don’t enable this feature.

In 2004, the Wi-Fi Alliance officially deprecated WEP, and since 2006, WPA2 has been mandatory in order to receive official certification. So it was with considerable surprise when I turned on my 2.4 GHz packet sniffer and discovered that some of my neighbors were still using the older technology (see Figure 1). While three of us are using WPA2 (RSNA-CCMP), 2WIRE464 is using WPA (WPA-TKIP) and two others are relying on WEP. If you’re concerned about Wi-Fi security, start by checking out your existing equipment. New embedded designs will certainly use the newer protocols.

Wi-Fi Solutions
The simplest way to resolve problems is to avoid them in the first place; when adding Wi-Fi to your embedded design, choosing to go with a module ensures that security issues are covered. DigiKey stocks quite a number of Wi-Fi modules, including the RabbitCore RCM5400W from Digi International, a C-programmable Wi-Fi core module; a Wi-Fi adaptor board from Future Designs; plus an assortment of modules from Multi-Tech Systems, RFM, and Sagrad.

If you choose to develop your own Wi-Fi designs, several manufacturers make evaluation and/or development kits to assist in that effort. CSR PLC makes the Radio Pro™ reference design kit for developing Wi-Fi-based Internet applications. RFM’s WSN802GDK-A development kit includes a router and a board based on its WSN802G transceiver module designed for 802.11g sensor networks. Texas Instruments’ CC3000FRAMEMK is a full turnkey Wi-Fi evaluation and demonstration tool for MSP430™ FRAM MCUs and TI's Simplelink™ Wi-Fi. Freescale Semiconductor’s TWR-WIFI-G1011MI kit enables you to design 802.11b-based applications using their Kinetis® Tower development system. Finally, Digi International’s Wi-ME S integration kit lets you evaluate their Digi Connect Wi-ME modules for your intended design.

Bluetooth

Whereas Wi-Fi was created as a wireless replacement for Ethernet, Erickson created Bluetooth® (IEEE 802.15.1) to replace RS-232 cables. With RS-232 having all but disappeared, Bluetooth now provides almost ubiquitous connectivity for headphones, computer mice, printers, cameras, and a host of embedded devices.

Bluetooth operates in the 2.4 GHz ISM band using frequency hopping spread spectrum (FHSS) to cover 79 one-megahertz channels. Unlike ZigBee, Bluetooth is a connection oriented protocol designed to stream data at a moderately high speed while still remaining low power. Like wireless USB, Bluetooth has a master/slave architecture that enables the master to communicate with up to seven slaves in a piconet at 721.2 kbps for Basic Rate (BR), 2.1 Mbps for Extended Data Rate (EDR), and up to 24 Mbps with the 802.11 alternative MAC and PHY (AMP). Bluetooth piconets involve a host and one or more controllers: one primary controller and one or more secondary controllers. A host is a logical entity consisting of all of the layers below the non-core profiles and above the host controller interface (HCI); a controller consists of all the layers below the HCI (see Figure 2). Bluetooth implements various security schemes at different points in the architecture, depending on the security mode selected.

The Bluetooth specification defines four security modes:

• Security Mode 1 is non-secure, with authentication and encryption turned off. This mode is only supported in v2.0+ EDR and earlier devices.
• Security Mode 2 is a service level-enforced mode, initiated after Link Manager Protocol (LMP) link establishment but before the Logical Link Control and Adaptation Protocol (L2CAP) channel establishment. L2CAP resides in the data link layer and provides connection oriented and connectionless data services to upper layers; however, the authentication and encryption mechanisms in this mode are implemented in the LMP layer, which is below L2CAP. In this mode, the security manager can implement different security policies and trust levels for different applications.
• Security Mode 3 is a link level-enforced mode, initiating security procedures before the physical link is fully established. Once that link is established, the security features are based on a separate secret link key that is shared by paired devices.
• Security Mode 4 is as a service level-enforced mode in which security procedures are initiated after link set up. Unique to Mode 4 is Secure Simple Pairing (SSP), which uses Elliptic Curve Diffie-Hellman (ECDH) public key cryptography for key exchange and link key generation. The National Security Agency (NSA) uses ECDH to verify key agreement, so it is safe to say that any concerns about Bluetooth Mode 4 are largely academic.

TI’s product training module “What is Bluetooth?” provides a good overall grounding in Bluetooth fundamentals.

Bluetooth Solutions
Bluetooth is a well-traveled road, so there is plenty of design help available along the way. TI’s CC2540DK-MINI mini development kit (see Figure 3) enables you to develop Bluetooth Low Energy applications using the CC2540 wireless MCU. The Bosch Sensortec Application Board incorporates a Bluetooth interface for sensor-based applications. There are numerous evaluation and/or development kits from leading Bluetooth chip makers, including Laird Technologies and STMicroelectronics.

If you’re looking for a drop-in solution, DigiKey stocks a variety of Bluetooth dongles and adaptors (both serial and Ethernet) from Laird Technologies – Wireless M2M, Roving Networks, Assmann WSW Components, BlueRadios, and Free2Move.

ZigBee

Some of the spikes on the panoramic display in Figure 1 are from nearby ZigBee devices. ZigBee – like Bluetooth, 6LoWPAN, WirelessHART, and a number of others – is based on IEEE 802.15.4, which defines the PHY and MAC layers for low cost, low power, low data rate wireless personal area networks (LR-WPANs). ZigBee typically operates in low-power mesh or star sensor networks, providing a maximum data rate of 250 kbps.

The IEEE 802.15.4-2003 specification defines not one, but several different PHYs depending on the modulation type and operating frequency. Three of the PHYs support DSSS in the 868/915 MHz bands using either OBPSK or QPSK, the latter being used in the 2.4 GHz ISM band. ZigBee uses the two PHY layers that operate in the 868/915 MHz and 2.4 GHz bands. ZigBee occupies 16 non-overlapping channels in the 2.4 GHz band (worldwide) and ten channels on the 915 MHz band in the U.S.

The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel using a CSMA-CA mechanism. Its responsibilities may also include transmitting beacon frames, synchronization, and providing a reliable transmission mechanism.

ZigBee implements most security procedures (see Figure 4) at the network (NWK) and application support sub-layer (APS). These services include methods for key establishment, key transport, frame protection, and device management. The security suite is AES-CCM, a 128-bit symmetric key block cipher algorithm, making ZigBee basically as secure as Wi-Fi – if you set it up correctly. There are several suites of ZigBee security services with ascending security levels:

• No security
• Confidentiality: AES-CTR
• Authentication: AES-CBC-MAC with 32-, 64-, or 128-bit MAC
• Confidentiality and Authentication: AES-CCM with 32-, 64-, or 128-bit MAC

Figure 4: Security in the ZigBee Stack (Courtesy ZigBee Alliance).

The available security services depend on the security suite. There are also some recommended implementation options:

• Use a key sequence counter
• Use the “Protected-ACK” frame type
• Use a Trust Reference Value (TRV)
• Use Flash memory to store nonce states

ZigBee RF4CE
ZigBee RF4CE is an even lower power, simplified version of the ZigBee architecture (see Figure 5) designed to replace IR-based remote controls in consumer electronics. Operating in the 2.4 GHz band, RF4CE only hops over three channels instead of ZigBee’s 16; and it simplifies the pairing mechanisms while still utilizing an AES-128 CCM security scheme. While it is possible, it is unlikely that anyone will be able to hack into your RF4CE-connected embedded device. However, if you are considering using RF4CE for a mission critical application, think twice before using such a simple protocol.

ZigBee Solutions
The increasing popularity of ZigBee in embedded applications is apparent from the large number of evaluation and/or development boards available from Ember, Digi International/MaxStream, Laird Embedded Wireless Solutions, CEL, NXP Semiconductors, and STMicroelectronics.

If you’re looking for a ZigBee RF front-end – integrating a PA and LNA – Skyworks, Texas Instruments, and CEL have it covered. If you would rather design from scratch, as of this writing DigiKey stocks 211 ZigBee transceivers from which to choose.

If you’re still not convinced that ZigBee makes sense for your application, check out the RFM ZigBee product training module, which addresses the question “Why ZigBee?” in some detail.

Summing Up

Embedded designs are increasingly wireless, often sporting several different RF interfaces. While this makes them more capable it also opens up potential security holes that must be understood during the planning phase and addressed at the design stage. By understanding the potential risks and designing around them, security drops out of the equation and the choice between Wi-Fi, Bluetooth, and ZigBee comes back to features, functions, and price—which is as it should be.

References:

1. The State of Wi-Fi Security, Wi-Fi Alliance.
2. Bluetooth Specifications, Bluetooth SIG.
3. Guide to Bluetooth Security, National Institute of Standards and Technology (NIST).
4. Bluetooth Security Review (Part 1, Part 2), Symantec Corporation.
5. ZigBee Specifications, ZigBee Alliance.
6. ZigBee Security, ZigBee Alliance Presentation.
7. IEEE 802.11i-2004, IEEE.
8. Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality, NIST