Today’s designers are turning to wireless technology more than ever before to get devices to talk to each other. Especially when battery-powered, this means that we no longer need to string wires between network nodes, making deployment much easier and less costly.
But, largely for historical reasons, we’re blessed with three separate short-range wireless standards, each with its own domain. Wi-Fi is familiar for computer connections and home access points; Bluetooth connects accessories to your phone or computer, and IEEE 802.15.4 connects home and other equipment into a robust mesh network.
These standards are not interoperable. But, that’s changing as Bluetooth and 802.15.4 make room for IP-based traffic. The benefit is greater intercommunication between otherwise isolated domains — especially for the IoT. What’s less obvious is the downside: hackers focusing on IP now have access to a much bigger playing field. That places a bigger security burden on each of these standards. It means that the other layers in each protocol need to ratchet up their security to ensure that if anyone breaks through via IP, plenty of other defenses are in place to swat the intruder down.
Three stacks to rule them all
Among the three protocols, Wi-Fi is the natural carrier of IP. It relies on 802.11 for the physical and link layers and then implements a typical IP-based stack, with TCP or UDP as transport and the familiar applications like HTTP, FTP, email, and evolving IoT home standards like Apple’s HomeKit or OIC Iotivity.
UDP (User Datagram Protocol) is an alternative TCP used primarily for establishing low-latency and loss-tolerating connections between applications on the Internet. Both UDP and TCP run on top of the Internet Protocol (IP).
Bluetooth, by contrast, has an end-to-end complete stack, from the physical layer all the way to the applications on top. Originally optimized for streaming data, the newer Bluetooth Low Energy protocol, or Bluetooth SMART, is better suited to IoT communications, but it cannot handle IP traffic. Any content based on IP would have to be converted in a gateway before it could be sent to a Bluetooth-based device.
ZigBee has a unique stack built upon the 802.15.4 MAC/PHY layers. Above that, it’s different from the Wi-Fi and Bluetooth all the way up to the ZigBee Cluster Library that defines application-level inter-operation. This means that none of these protocols have anything in common, at any layer.
Fig. 1: The Wi-Fi, ZigBee, and Bluetooth Low Energy protocol stacks share no common elements at any level, preventing interoperability.
Leveraging IP everywhere
This picture is changing, however, as both ZigBee and Bluetooth take steps that will accommodate IP-based traffic. While this doesn’t change the original native-protocol traffic that each standard now sees, it enables additional traffic to cross more easily from one to another.
In the 802.15.4/ZigBee world, a new network sub-layer protocol, 6LoWPAN (IPv6 over Low-power Wireless Personal Area Networks) adapts IP traffic to the underlying 802.15.4 layer. It takes care of IP header compression, fragmentation, and reassembly to fit in an 802.15.4 packet.
The Thread protocol is one implementation of IPv6 over the 802.15.4 radios; layering UDP on as the transport layer over 6LoWPAN. Thread and ZigBee have recently announced collaboration that will enable the ZigBee clusters Library at the application level to operate over Thread as an alternative.
Finally, Bluetooth 4.2 has added an IP Support Profile (IPSP) that leverages 6LoWPAN. This enables communication and paves the way for an IP-based stack above the IPSP in the same manner as seen with ZigBee. While 6LoWPAN was originally conceived as a way to implement IPv6 over 802.15.4, it has been further adapted to perform the same role in Bluetooth.
Fig. 2: Each of the three wireless protocols now has a means of accepting IP-based packets, meaning that all three can implement the same stack above the IP layer.
One of the most important protections is authentication. While the use of authentication is common, it’s typically done in only one direction; a node will be authenticated onto a network, but the network will not be authenticated on the node. In order to assure full protection for the node and the network, an IoT node must authenticate new connections and messages at the application level so that any security breaches have limited scope.
A larger target
Before these developments, IP-based traffic was restricted to IP-based networks, which meant Wi-Fi traffic originating on a ZigBee network stayed on ZigBee, and Bluetooth traffic remained within Bluetooth. By opening up all three standards to IP-based traffic, information can flow more broadly; protocol-based barriers between networks have been removed, and interoperability is improved. But these benefits come at a cost. The extended reach afforded by 6LoWPAN, ZigBee and Bluetooth also extends the reach for attackers, giving them potentially new access to networks that they would have had a harder time penetrating before.
This is where multi-layer security becomes particularly important. Different layers have security provisions that must be implemented in order to ensure that these newly accessible nodes don’t become ready targets. The most important layers to be secured are the data link, transport, and application layers. Layer 2, the data-link layer, resides below IP or any IP adaptation and so is different for each wireless protocol.
With Wi-Fi security via protocols like WPS ensures encrypted data within the network. The 802.15.4 radio protocol provides frame encryption at the data link level using AES-128. And Thread take advantage of this. Bluetooth’s data-link layer security provides both encryption and authentication.
The 802.15.4 security features are typically implemented in hardware, although they are not mandatory for ZigBee. With Wi-Fi and Bluetooth, however, the security features are not required, and it can be tempting to leave them out in order to simplify operation and minimize cost. The increased vulnerability created by network interoperability means that data-link security should no longer be viewed as optional.
Above IP, there are typically two options: UDP and TCP. Each of these transport protocols has an associated security protocol. For UDP, it’s DTLS; for TCP, it’s TLS. TCP and UDP, on their own, do not provide security. TLS (sometimes referred to as SSL, an earlier version of transport security) provides connection authentication and session key exchange as well as data encryption. DTLS is adapted to the datagram nature of UDP instead of the segment nature of TCP.
But traffic originating as IP can now go anywhere in a network, including nodes that don’t accept IP. So the native ZigBee and Bluetooth transport-layer security features must also be implemented. ZigBee PRO mandates encryption at the network and application levels. Transport-level encryption should be considered mandatory. Native Bluetooth implementations, by contrast, have security only in the data link layer, not in the transport layer.
The application layer
Finally there is the application layer, and for this, there are no real standards due to the variety of applications. These could be HTTP, email, or any of a variety of IoT applications communicating between nodes using messaging protocols like MQTT or CoAP. Depending on their sophistication, such protocols may or may not provide additional built-in security, so it becomes the responsibility of the designer or architect to build in application-level protection. And, it is this layer where IoT home standards like Apple’s HomeKit, OIC Iotivity, and Google Weave are evolving.
Advertisement
Learn more about Atmel
