Ensuring Device and Radio Security in Low-Power IoT Wireless Connections

By European Editors

Contributed By Digi-Key's European Editors

Long-range, low-power wireless

When connecting wireless IoT devices over distances beyond the range of links such as Wi-Fi® or ZigBee®, several options are available to designers. A high-speed 3G or 4G connection is more complex, expensive and power hungry than is desirable for typical IoT sensors or actuators. Although second generation (2G) GSM is economical and adequate, the future of some 2G networks is in doubt as smartphone users move to 4G and 5G services. The GSM Association (GSMA) has proposed Cat-0 LTE as a simplified, IoT-friendly way to connect devices to 4G networks. In the meantime, low-power wide area network (LPWAN) standards including LoRaWAN™, Sigfox, Ingenu and Weightless have emerged as affordable alternatives to the GSM standards.

LPWAN networks operate in unlicensed frequency bands. The organizations behind Sigfox and Ingenu are working to setup their own networks, while the LoRa® Alliance is taking a different approach by promoting the technology for independent network operators to use. Orange announced in 2015 that it would build a LoRa network as part of its strategy to serve markets for M2M and IoT connectivity.

Briefly, LoRaWAN networks operate in the 868 kHz frequency band in Europe, and 915 MHz in North America. The protocol is designed to use very low power and can support data rates from 0.3 kbit/s to 50 kbit/s. Support for adaptive data rate allows automatic optimization for range, battery life and network capacity. Communication range can be between 2 km up to 15 km, depending on factors such as the built environment and message size. LoRaWAN is gaining traction, and several products are already in the market that enable designers to add LoRaWAN connectivity to autonomous devices.

As the IoT has entered the public domain, the opportunity for cyber-attacks to compromise security and safety has become a high profile concern. Due to the nature of the IoT, such threats can apply to individuals or to large numbers of people simultaneously. Hackers may seek to take over devices and cause them to malfunction, steal device data, or use the devices to gain access to a hosting network where sensitive personal or financial information is kept. They may also use the devices as a means of distributing malware, or may simply try to steal intellectual property such as application code running on the device.

Securing LoRa data traffic

A security strategy for protecting IoT connections needs to be simple enough for resource constrained IoT endpoints to support, and should also be inexpensive and impose minimal additional demand on device power. Security mechanisms in LoRaWAN protect the communications based on mutual authentication between the network and endpoints. This allows the network to be sure that any device attempting to connect is properly registered and has not been compromised, and assures the connecting device of the authenticity of the network it is about to join. This relies on both the network and the joining device having knowledge of a security key, known as the AppKey, allowing each to encrypt messages for the other, and correctly decrypt messages received. After credentials have been authenticated and the end point is connected, LoRaWAN security works by using signing and encryption to protect message integrity.

The LoRa Alliance has designed the LoRaWAN protocol to support end-to-end encryption. The data traffic is not only encrypted over the air interface, it remains encrypted in the operator’s core network and is not transported as plain text. This saves additional security overheads, such as extra application layer encryption, hence saving cost, complexity and power.

LoRaWAN security is based on the security developed for IEEE 802.15.4 radio communication, and is extended by also using two session keys: a network session key (NwkSKey) and an application session key (AppSKey). In keeping with established IEEE 802 security practice, each LoRaWAN device is assigned a 64-bit globally unique identifier known as DevEUI, which is compliant with the IEEE’s Extended Unique Identifier (EUI-64). To be able to assign this identifier, the assigning organization must have its own 24-bit organizationally unique identifier (OUI) issued by the IEEE Registration Authority. Each LoRaWAN end device also has its own 128-bit AES key, known as the AppKey.

Each device must be activated before it can communicate on a LoRaWAN network. This can be done using either over the air activation (OTAA), or activation by personalization (ABP). In either case, both the network and the joining device must demonstrate that they have the correct security keys to establish the connection.

In OTAA, the end device transmits a join request containing its DevEUI, an application identifier (AppEUI), and the AppKey. The application server then sends an encrypted acceptance, which the end device decrypts using its AppKey to extract its assigned device address (DevAddr) for the network and to derive a network session key (NwkSKey) and application session key (AppSKey). These keys are unique to the device.

In ABP, the end device is programmed with the device address and session keys at manufacture. This is appropriate if the device is intended to be connected to a specific known network. It is ready to immediately communicate on the network with no over-the-air handshaking.

Image of LoRaWAN network topology

Figure 1: LoRaWAN network topology.

In a LoRaWAN network, end devices communicate with a network server via one or more gateways, as shown in Figure 1. The network server, in turn, directs data from each end device to the application server appropriate to the device, and manages transmitting data from the application server to the end device via the gateway. Security protection is provided at both the control and application data levels by the session keys, NwkSKey and AppSKey respectively. Each packet contains a MAC header, frame header and payload, and a message integrity code (MIC) generated using NWSKey.

Authentication is achieved by calculating the MIC using advanced encryption standard with the standard cipher-based message authentication code (AES-CMAC). The payload is encrypted using AppSKey. In this way, both the network server and application server can verify the authenticity of messages from end devices. As shown in Figure 2, the application payload is encrypted using AES in counter (CTR) mode (AES-CTR), with the frame counter also included as part of the LoRaWAN packet. This effectively prevents attackers gaining access by replaying messages. It is vital that the counter is managed correctly so that no sequences are repeated, or that the counter is not reset by forcing the node to reconnect to the network.

Image of encryption of LoRaWAN packets

Figure 2: Encryption of LoRaWAN packets to prevent interception and replay attacks.

Physical security of LoRa nodes

LoRaWAN security is designed to be simple, power-friendly, and to avoid complex or heavyweight cryptographic computations or multi-layer security. Although encryption is implemented at both the control and application layers using NwkSKey and AppSKey, both keys are derived from the same root key (AppKey). Hence a network operator in possession of the AppKey may be able to derive the AppSKey and decrypt the traffic. If protection against this type of vulnerability is needed, the server handling AppKey storage and associated services can be controlled by a trusted organization separate from the network operator. The LoRa Alliance has indicated that planned changes to LoRaWAN will derive the NwkSKey and AppSKey from separate keys in the future.

In practice, the encoding, encryption and transmission of data over a LoRaWAN wireless connection can be handled by a transceiver module such as the RN2483 from Microchip. This module implements the LoRaWAN protocol stack on-board in an integrated microcontroller, and integrates a LoRa technology radio and a UART for interfacing with a host microcontroller (Figure 3). The embedded microcontroller provides 14 GPIO pins for connecting user devices such as sensors, switches, or status LEDs. An alternative is the Seeeduino LoRaWAN module from Seeed Technology, to which the user is able to add a selection of sensors quickly and easily using expansion boards in the maker style.

Image of Microchip RN2483 LoRaWAN protocol

Figure 3: The Microchip RN2483 handles the entire LoRaWAN protocol including encryption.

Although the LoRaWAN standard implements several mechanisms to protect data in transit between the LoRa network and connected end devices, the nodes can still be vulnerable to physical attacks. If stored keys can be extracted, for example, then a device can be impersonated on the network. Physical attacks can be a significant threat to devices that are installed in remote or unsupervised areas, requiring additional security measures.

The CMWX1ZZABZ-078 LoRa module from Murata is available with an optional secure element for safe key storage (Figure 4). Embedding a secure element is recognized as an effective way to protect cryptographic keys and other sensitive data against physical attacks such as invasive probing or pin monitoring, and is used increasingly in IoT devices and equipment such as personal computers to establish a hardware root of trust that authenticates the machine, software, and user.

Diagram of Murata CMWX1ZZABZ-078

Figure 4: The Murata CMWX1ZZABZ-078 provides the option of an integrated secure element for extra protection against physical attack.

Conclusion

The LoRaWAN protocol has been developed with IoT applications in mind, and includes extensive security measures to protect data in transit. Device designers need to pay careful attention to the LoRa Alliance recommendations to ensure the best possible security for their applications. Additionally, extra security measures may be needed to protect unattended IoT devices against physical attack.

Disclaimer: The opinions, beliefs, and viewpoints expressed by the various authors and/or forum participants on this website do not necessarily reflect the opinions, beliefs, and viewpoints of Digi-Key Electronics or official policies of Digi-Key Electronics.

About this author

European Editors

About this publisher

Digi-Key's European Editors