Security in LoRaWAN Applications

Today's Safer Internet Day was launched in 1999 in several European countries, to raise awareness about internet security. Security is highly relevant in almost all areas of the internet. The Internet of Things (IoT) is no exception. Internet of Things, IoT) is no exception. This article is dedicated to security in the area of LoRaWAN. Some of it can also be applied to other LPWAN technologies. The phenomenon of the Internet of Things is characterized by a growing dominance of objects and instances capable of automatic data transfer, each with unique identifiers. The increased density of IoT infrastructure is mainly due to Machine-to-Machine (M2M) communication, such as sensor systems found in smart homes or smart cities, industrial automation processes, wearable mobile computing devices, vehicle-to-vehicle communication, etc. In an analysis, a single device in the field should not be considered in isolation. Instead, it is important to systematically consider all interfaces to gateways, applications, and data storage where large amounts of data are processed and stored. Security challenges exist at all layers of IoT architectures. The effort to reconcile data protection with the requirements of businesses and societies is considerable. An important entity in this area is the coalition of key industry leaders, the Internet of Things Security Foundation (IoTSF). The IoTSF is a collaborative, non-commercial, international response to the complex challenges posed by the increasingly interconnected world. It achieves its goal by coordinating collaboration between companies and encouraging manufacturers to consider device and system security from the ground up. Some key representatives of the IoTSF include Intel, Huawei, IBM, Thales, Secure-IC, BT, Vodafone, Imagination Technologies, Royal Holloway University of London, Glasgow Caledonian University, NMI, and PenTest Partners.

The Challenge

A large part of the risks is mainly due to the fact that IoT devices are always on standby. This is regardless of whether they are always connected to the network or in standby mode. They only undergo an authentication process at the beginning of their lifecycle in the system. This makes them very vulnerable from a security perspective. During product development, security aspects are not always considered. This poses a major problem that should be addressed to the same extent as connectivity itself. Some IoT products have outdated embedded operating systems. Not only for this reason, installing system or security updates on IoT devices is a major challenge. Network nodes are usually installed outside or at the customer's site, leading to a large number of scattered network nodes that are very difficult to monitor and manage. Making settings or configurations – including security configurations – for each individual network node does not represent a viable technical solution. The automatic initiation of these network nodes by the manufacturer is also not a particularly reliable solution. Appropriate and tested procedures must prevent updates from becoming security vulnerabilities themselves. Some security companies offer specialized IoT security solutions, such as disk encryption or the implementation of tamper-proof components. These solutions enable both advanced digital security and lifecycle management through encryption and access restrictions to sensitive data. There is broad consensus in the IoT market about the high importance of security aspects. The full benefits of new technologies should only be realized in secure environments.

What security features does the LoRaWAN standard include?

The LoRaWAN protocol stack is shown in Figure 1. It consists of an application layer, a MAC layer, and a PHY layer. The data from the application layer is transferred into the MAC payload. The MAC layer creates the MAC frame from the MAC payload. The MAC payload contains a frame header (with source and destination addresses and a frame counter), a frame port, and the frame payload (with application data). The frame port is used to determine whether the frame contains only MAC commands (if set to 0) or application-specific data. Finally, the PHY layer uses the MAC frame as PHY payload and creates the PHY frame after inserting preamble, PHY header, and CRC.

Figure 1: LoRaWAN Protocol Stack

The RF parameters include frequencies, power levels, modulation, and the basic RF protocols. These are all contained in the LoRaWAN RF or physical layer. Since security integration is extremely important for any wireless network, LoRaWAN uses two security layers, as shown in Figure 2: one for the network layer and one for the application layer. Network layer security ensures the authenticity of the device in the network. Application layer security ensures that the network operator does not have access to the end user's application data.

Figure 2: The dual security layers of LoRaWAN

An end device (node) must be activated before it can communicate over the LoRaWAN network. Two activation methods are available in LoRaWAN networks: OTAA and ABP.

Over-the-Air Activation (OTAA)

This OTAA method is based on the collaboration between over-the-air messages for join requests and join accepts. For each end device (node), a 64-bit DevEUI, a 64-bit AppEUI, and a 128-bit AppKey are provided. The DevEUI is a unique global identifier for the device, comparable to the MAC address of a TCP/IP device. The AppKey is used for cryptographic signing of the join request. The AppKey is used when the node, as shown in Figure 3, sends a join request message. The node sends a join request message consisting of its AppEUI and DevEUI. It also sends a DevNonce – a unique, randomly generated 2-byte value used to prevent replay attacks.

Figure 3: The OTAA method in LoRaWAN

These three values are marked with a 4-byte long MIC (Message Integrity Code) using the device's AppKey. The server accepts join requests only from devices with known DevEUI and AppEUI values and verifies the MIC by matching it with the AppKey.

Figure 4: The elements of a LoRaWAN message

When the server accepts the join request, it responds to the device with a join accept message. The application and network servers calculate the two 128-bit keys of the node: the Application Session Key (AppSKey) and the Network Session Key (NwkSKey). These are calculated based on values sent by the node in the join request message. Additionally, the application server generates its own nonce value: AppNonce. This is another unique, randomly generated value. The join accept response contains the AppNonce, a NetID, and an end device address (DevAddr) along with configuration data for RF delays (RxDelay) and the channels to be used (CFList). The NetID is important for LoRaWAN devices of class B. It is a 3-byte value that allows nodes to identify that a message was sent from an internal network gateway. Therefore, it must have a unique identifier for the respective LoRaWAN. The end device address (DevAddr) in the join accept response is a 32-bit identifier that is unique within the network. The distinction of end devices that have already joined the network is possible via the device address. This allows the network and application servers to use the correct encryptions and interpret the data correctly. When receiving data, it is encrypted with the AppKey. The node then uses the AppKey to decrypt the data and derives the AppSKey and NwkSKey from the AppNonce value in the join accept message.

Activation by Personalization (ABP)

This ABP method differs from OTAA in that the nodes are sent along with the DevAddr and the two session keys unique to the node (NwkSKey and AppSKey). Since the nodes already have the necessary information and keys, they can begin communication with the network server without having to exchange join messages beforehand. Once a node has joined a LoRaWAN – either via OTAA or ABP – all future messages are encrypted with a combination of different keys (see also Security in LoRaWAN):

• Network Session Key (NwkSKey) – a security mechanism of the network layer. This key is unique for each end device and is shared between the end device and the network server. The Network Session Key ensures message integrity during communication and secures communication from end devices to the network server.
• Application Session Key (AppSKey) – This key is responsible for end-to-end (device-to-device) encryption of the payload. It is also an AES-128-bit key that is unique for each end device and is shared between the end device and the application server. The Application Session Key encrypts and decrypts application data messages and secures application payloads.

These two session keys (NwkSKey and AppSKey) are unique for each end device and each session. If the device is dynamically activated (OTAA), these keys are regenerated with each activation. If the device is statically activated (ABP), these keys remain until they are manually changed.

Advanced Encryption Standard (AES)

The AES encryption with the key exchange implemented in LoRaWAN according to the security measures for wireless networks under IEEE 802.15.4 (shown in Figure 5).

Figure 5: Secured application data transmission in LoRaWAN

The encryption mechanism implemented in the LoRaWAN standard, which is interoperable between manufacturers and network providers, thus ensures confidentiality and integrity in end-to-end data transmission.

The strengths of the security features of the LoRaWAN standard

System security in LoRaWANs is achieved through a combination of technical and operational measures. It should be noted that LoRaWAN was originally developed for devices with hardware constraints. Additionally, most applications in LoRaWAN receive data from distributed sensors. For typical applications, LoRaWAN is a simple, cost-effective, and secure solution. The strengths of the security features in LoRaWAN consist of some proven practices:

1. OTAA deployment: When keys and certificates are dynamically transferred for each session between a device and the network and application servers. By rejoining networks, the session keys of the devices are regularly changed. This is important for avoiding potential risks such as spoofing, tampering, etc.
2. Dynamically activated devices (OTAA) use the Application Key (AppKey) during the activation process to derive the two session keys. In the network, their value is set to the default AppKey, which is then used to activate all devices. Implementing an individual AppKey for each device is recommended. It is crucial that keys are never sent using the over-the-air method throughout the entire security process. Only the missing parts of a calculation are exchanged from both sides. Therefore, generating keys by intercepting over-the-air traffic is extremely complex.
3. The presence of a hardware element for storing security credentials in the device can be advantageous. Extracting keys through reverse engineering or scanning device memory is significantly more difficult. Additionally, secure boot usage should ensure the integrity of the device firmware.
4. An additional encryption layer at the application level is always recommended and should be implemented if necessary.
5. To prevent replay attacks, it is important to enable the verification of uplink/downlink message counters in the network. Due to the wireless network connection, the possibility of malicious interception and storage of messages still exists. However, due to the encryption of the messages, it is not possible to read them without the AppSKey. Also, exchanging messages at the network level is not possible without the NwkSKey, as the MIC verification would not be successful. The retransmission of messages is possible. These so-called "replay attacks" can be detected and blocked by frame counters. When a device is activated, both frame counters (FCntUp and FCntDown) are set to 0. Each time the device transmits an uplink message, the FCntUp is increased. Each time the network server transmits a downlink message, the FCntDown is increased. If the device or the network receives a message with a frame count lower than the last recorded one, the message is ignored.
6. Unlike TCP, the acknowledgment of LoRaWAN data frames is optional. The recipient would then confirm this frame with a data frame whose ACK bit is set to 1. This optional frame acknowledgment is ideal for LoRaWAN, as the transmission time of devices is limited. Therefore, a certain loss of data packets may be irrelevant. For verification, each frame is appended with a MIC. This is essentially a signature calculated over the frame using a Network Session Key. Even if the same payload is transmitted multiple times, each frame receives a unique signature because the frame counter is incremented for each transmission.

The weaknesses of the security features of the LoRaWAN standard

Developers of LoRaWAN solutions should be aware that using LoRaWAN does not guarantee 100% protection in all security areas. This fact can also be applied to all other wireless technology systems. Instead, LoRaWAN solutions should be developed with an awareness of potential security risks. Since LoRaWAN solutions are used in a wide range of systems – from home security solutions to resources for remote control and monitoring infrastructures – attacks and unauthorized use are quite possible. Some of the main weaknesses of the security features in LoRaWAN are:

1. Encrypted messages have the same length as the key.
2. The ABP method permanently sets both session keys, leading to vulnerabilities.
3. The storage of LoRaWAN keys (AppKey, NwkSKey, and AppSKey) poses a fundamental problem. In the development of solutions, network security must be considered at every stage of development and deployment. Several vulnerabilities exist regarding key lifecycle management, session key generation, storage, and transport, necessitating careful development and implementation. Granting customers access to device keys is not advantageous for distribution. Known side-channel attacks can recover keys from device memory. All device keys should be appropriately secured, for example, by encrypting them with master keys, to reduce the risk of their disclosure. The storage of LoRaWAN network server keys is a problem for which a complete system solution must be provided.
4. Another weakness lies in the identification and connection processes. Each gateway regularly sends beacons (its individual ID) to the server. This ID can be easily retrieved by attackers. If the ID is known, the gateway can be replaced, for example, with a malicious gateway that sends its ID more frequently than the real one.

Some manufacturers take a different approach: retrofitting existing security elements. This process is not optimal when a system has many distributed components. Implementation is sensitive, complex, demanding, and often cannot be carried out securely, timely, and cost-effectively.

Conclusion and Outlook

The current LoRaWAN standard 1.0.x already includes a relatively high level of security. The risks and attack scenarios listed above are certainly justified and should be individually assessed for each use case. Solutions have already been discussed above. To meet the increased security requirements in IoT networks, the LoRa Alliance is continuously working on improving the standard. The LoRa Alliance is a non-profit coalition of organizations working together on the standardization of LPWAN networks. The new LoRaWAN 1.1 specification was released on October 17, 2017. Since the new specification brings significant changes to the existing network protocols and LoRaWAN communication, the first end devices according to the new specification are expected no earlier than 2018. Devices according to the LoRaWAN 1.1 standard are backward compatible with LoRaWAN 1.0.x devices and can also work with 1.0.2 network servers. The changes in the LoRaWAN 1.1 specification affect both the end devices and the gateways and servers. The most important innovations are in the communication between the end device and gateways as well as in the communication between the servers. In particular, the join replay attacks and downlink ACK attacks still possible in the current specification 1.0.2 are addressed. For this purpose, for example, the uplink frame counter (FCntUp) was encrypted in acknowledgment messages (ACK downlinks). With this innovation, the end device can recognize which of its messages has been confirmed by the network server. Further security improvements concern the clear separation between network server, join server, and application server and the introduction of additional keys such as NwkKey, NwkSEncKey, SNwkSIntKey, FNwkSIntKey, and AppSKey. These new keys are particularly important for the new handover roaming, which allows messages from end devices to be actively forwarded across foreign LoRaWAN networks to the home network of the end device. Special attention was also paid to the "third party join server" possible according to specification 1.1. These join servers are no longer managed by the operators of the network servers but are provided by a trusted third party. All security-relevant keys of the end devices are managed on the join servers and are provided either to the network server responsible for transporting the messages or to the application server responsible for processing the messages. A clear separation of these responsibilities prevents the network operator (operator) from being able to read the content (payload) of the LoRaWAN messages.

For specific questions on this topic, you can always contact our Head of Delivery Unit, Reimo Schaupp.If you want to stay updated on the topic of security in LPWAN, simply subscribe to our mailing list.