The Safer Internet Day was established in 1999 in several European countries to raise users’ awareness of Internet safety (it takes place every year on the 2nd day of the 2nd week of the 2nd month). However, the topic of security has a very high relevance in almost any area of the Internet. The Internet of Things (IoT) and the Industrial Internet of Things (IIoT) are no exceptions.
This article is focused on security in the context of LoRaWAN. Some of this can also be transferred to other LPWAN technologies.
The Internet of Things phenomenon is marked by an increasing prevalence of objects and entities with automatic data transfer capabilities, each with unique identifiers. Increased IoT traffic is mainly caused by machine-to-machine (M2M) communication: sensor systems such as those found in smart homes and smart cities, industrial automation processes, portable mobile computing devices, vehicle-to-vehicle communication systems, etc.
In an analysis, a single device in the field should not be examined in isolation. Rather, all interfaces to gateways, applications and data storage systems, in which large amounts of data are processed and stored, must be taken into account.
Security challenges are present in all layers of the (I)IoT architectures. The effort required to harmonize data privacy and the requirements of companies and societies is significant.
A conglomeration of important industry leaders founded the Internet of Things Security Foundation (IoTSF). IoTSF is a collaborative, non-profit, international response to the complex challenges wrought by security in the expansive hyper-connected world. To this end, the foundation gathers IoT security professionals, IoT hardware and software product vendors, network providers, system integrators, distributors, retailers, insurers, local authorities, government agencies, among others who recognize security as a crucial issue for IoT.
IoTSF’s role is to raise awareness. It achieves this goal through companies’ collaboration and encouraging manufacturers to consider the security of connected devices at the most basic levels, including prototype phases in the research and development process. Some important IoTSF representatives include: Intel, Huawei, IBM, Thales, Secure-IC, BT, Vodafone, Imagination Technologies, Royal Holloway University of London, Glasgow Caledonian University, NMI, and PenTest Partners.
Security has not always been considered in the design of products. This is a big problem which deserves to be treated in the same manner as connectivity. Some IoT products are provided with deprecated operating systems in embedded form.
Installing system or security updates on IoT devices is a challenging procedure. Nodes are usually installed outdoors or at customer premises in order to cover geographical areas of interest. Because of this, there are sometimes a large number of devastated nodes which become very difficult to monitor and manage.
Accessing each and every node to individually change its settings or configurations – including security configurations – is not a representative technical solution. Having these nodes automatically initiated by manufacturers does not provide a significant level of confidence either. Proper and proven procedures must prevent updates from becoming security holes themselves.
Some security companies are currently sharing resources to provide IoT security solutions such as entire disk volume encryption or implementation of tamper-resistant components. These solutions enable both advanced digital security and life cycle management via encryption and access-control limitation to sensitive data.
The importance of security is recognized by most parties of the (I)IoT market. Therefore, the full benefits of new technologies should be achieved only in secure surroundings.
What are the security features of the LoRaWAN standard?
The LoRaWAN protocol stack is presented in Figure 1. It consists of an application layer, a MAC layer and a PHY layer. Data from the application layer is mapped into the MAC Payload. The MAC layer constructs the MAC frame using the MAC payload. The MAC payload contains a frame header (holding both the source and destination addresses plus a frame counter), a frame port, and the frame payload (holding application data). The frame port is used to determine if the frame contains MAC commands alone (when it is set to 0) or application specific data. Finally, the PHY layer uses the MAC frame as the PHY payload and constructs the PHY frame, after inserting the preamble, the PHY header and the CRC
Figure 1: LoRaWAN protocol stack
The RF parameters include frequencies, power levels, modulation, and the basic RF protocols. These are all encapsulated in the LoRaWAN RF or physical layer parameters.
Because it is extremely important for any wireless network to incorporate security, LoRaWAN utilizes two layers of security as can be seen in Figure 2: one for the network 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: LoRaWAN dual layer security
An End Device (Node) must be activated before it can communicate on the LoRaWAN network. In LoRaWAN networks, two activation methods are available: OTAA und ABP.
Over-the-Air Activation (OTAA)
This method is based on over-the-air Join Requests and Join Accept messages working hand in hand. Each End Device (Node) is deployed with a 64-bit DevEUI, a 64-bit AppEUI, and a 128-bit AppKey. The DevEUI is a globally unique identifier for the device which has a 64-bit address comparable with the MAC address for a TCP/IP device. The AppKey is used to cryptographically sign the Join Request. All three values are then made available to the application server to which the device is supposed to connect. The AppKey is used when the node sends a Join Request message as presented in Figure 3. The node sends the Join Request message, composed of its AppEUI and DevEUI. It additionally sends a DevNonce, which is a unique, randomly generated, two-byte value used for preventing replay attacks.
Figure 3: The OTAA method in LoRaWAN
These three values are signed with a 4-byte MIC (Message Integrity Code) using the device’s AppKey. The server accepts Join Requests only from devices with known DevEUI and AppEUI values while validating the MIC using the AppKey.
Figure 4: The elements of a LoRaWAN message
If the server accepts the Join Request, it responds to the device with a Join Accept message. The application and network servers calculate the node’s two 128-bit keys: the Application Session Key (AppSKey) and the Network Session Key (NwkSKey), respectively. These are calculated based on the values sent in the Join Request message from the node.
Additionally, the application server generates its own nonce value: AppNonce. This is another unique, randomly generated value.
The Join Accept reply includes the AppNonce, a NetID, and an end device address (DevAddr) along with configuration data for RF delays (RxDelay) and channels to use (CFList). The device address (DevAddr) in the Join Accept reply is a 32-bit identifier which is unique within the network.
It is possible to use the device address to differentiate between end devices which have already joined the network. This allows the network and application servers to use correct encryption keys and to properly interpret the data.
When receiving data back, the data is encrypted with the AppKey. The node then uses the AppKey to decrypt the data and derives the AppSKey and the NwkSKey using the AppNonce value received in the Join Accept reply.
Activation by Personalization (ABP) method
This method differs from OTAA as the nodes are shipped with the DevAddr and both session keys (NwkSKey and AppSKey), which should be unique to the node. Because the nodes already have the information and keys they need, they can begin communicating with the network server without the need for the join message exchange.
Once a node has joined a LoRaWAN network – either through OTAA or ABP – all future messages will be encrypted and signed using a combination of specific keys (see also Security in LoRaWAN):
- Network Session Key (NwkSKey) – This is a network layer security mechanism. This key is unique to each end device and shared between the end device and the network server. The network session key provides message integrity during communication and security for end device to network server communication.
- Application Session Key (AppSKey) – This key is responsible for end-to-end (application to application) ciphering of the payload. This is also an AES 128-bit key, unique to each end device. It is shared between the end device and application server. The application session key encrypts and decrypts application data messages and provides security for application payloads.
These two session keys (NwkSKey and AppSKey) are unique to each device and to each session. If the device is dynamically activated (OTAA), these keys are regenerated which each activation. If the device is statically activated (ABP), these keys remain the same until they are changed manually.
Advanced Encryption Standard (AES)
AES encryption with the key exchange implemented in LoRaWAN, based on security for IEEE 802.15.4 wireless networks, is presented in Figure 5.
Figure 5: LoRaWAN secured application data transfer
LoRaWAN offers a simple process for end-to-end data confidentiality and integrity that should be interoperable among manufacturers and network providers. The implemented encryption mechanism ensures that the LoRaWAN network remains secure [LE].
The strengths of the security features in the LoRaWAN standard
System security in LoRaWAN networks is provided by a combination of technical and operational measures. It is important to note that LoRaWAN was initially designed for hardware-constrained devices and most applications on the LoRaWAN network receive data from distributed sensors. For typical applications, LoRaWAN is an easy-to-use, cost-effective, and secure solution.
The strengths of security features in LoRaWAN are comprised of a number of good practices. Representative examples of this include:
- OTAA-provisioning: This occurs when the keys and certificates are dynamically negotiated between a device and the network and application servers for each session. It is very a useful practice. Starting network re-join procedures in devices periodically changes session keys. These capabilities are important for prevention against potential risks such as spoofing, tempering, etc.
- Dynamically activated devices (OTAA) use the application key (AppKey) to derive the two session keys during the activation procedure. In the network, their value is set to the default AppKey which will then be used to activate all devices. It is recommended to implement a customized AppKey value for each device. Importantly, at no point in the whole security process are keys sent over the air. Only the missing parts of a calculation from both sides are exchanged. This makes it extremely complex to generate any key by intercepting over- the-air traffic.
- Having a secure hardware element in a device to store security credentials is advantageous. This makes it very hard to extract keys through reverse engineering or by scanning device memories. Additionally, secure boot usage should ensure integrity of the device firmware.
- Having an additional layer of encryption and authentication at the application layer is always recommended if possible. Some asymmetric keys solutions can also be very effective.
- To prevent replay attacks, it is important to enable uplink/downlink message/frame counter checks in the network server. Due to wireless network connectivity, the possibility of malicious capturing and storing of messages still exists. However, due to the encryption of messages, it is not possible to read them without the AppSKey. Nor is it possible to exchange messages on network layer without the NwkSKey, because this will cause the MIC check to fail. It is possible to re-transmit messages. These so-called “replay attacks” can be detected and blocked using frame counters. When a device is activated, the frame counters (FCntUp and FCntDown) are both set to 0. Every time the device transmits an uplink message, the FCntUp is incremented. Every time the network sends a downlink message, the FCntDown is incremented. If the device or the network receives a message with a frame counter that is lower than the last recorded one, then the message is ignored.
- Unlike TCP, the acknowledgement of LoRaWAN data frames is optional. Only if an acknowledgement is required would one use the confirmed data message type. The receiving party would then confirm this frame by responding with a data-frame with the ACK bit set to 1. This optional frame acknowledgement is ideal for LoRaWAN since the airtime of devices is limited. Therefore, a certain amount of packet loss may be unimportant. A MIC is added to each frame for validation purposes. It is essentially a signature calculated over the frame using a network session key. This means that even if the same payload is transmitted multiple times, each frame will have a unique signature as the frame-counter is incremented for every transmission.
The weaknesses of the security features in the LoRaWAN standard
It should be clear to all developers of LoRaWAN solutions that using LoRaWAN does not guarantee 100% protection in any security domain. This fact is also applicable to all other wireless technology systems. Instead, LoRaWAN solutions should be built with an awareness of possible security threats.
Given that LoRaWAN solutions are being used in a wide range of systems – from home security to the remote control and monitoring of infrastructure resources – attacks and unauthorized usages are quite possible.
Some of the most important weaknesses of the security features in LoRaWAN would be:
- Encrypted messages have the same length as the key.
- Once the session keys are compromised, security would be rendered ineffective as it would be too complex to change the AES keys on all nodes and devices.
- LoRaWAN key storage (AppKey, NwkSKey, and AppSKey) is a fundamental area of concern. Solutions should be developed by considering cybersecurity at every stage of development and exploitation. There are several vulnerable points in relation to key life cycle management, session key generation, storage, and transport that need careful design and implementation. Users having access to device keys is not good for marketing. Well-known side channel attacks can be used to recover keys from device memory. All device keys should be protected in proper ways, such as encryption under master keys, to mitigate threats of exposure. LoRaWAN network server key storage is a point of failure which requires an entire system solution. Once this server or set of servers is compromised, the entire security around LoRaWAN will be affected, leaving attackers free to intercept or spoof any message they wish.
- Another weakness lies in the identification and connection processes. Every gateway periodically sends beacons (its personal ID) to the server. This ID is a piece of information that is not difficult for attackers to obtain. If the ID is known, the gateway can be “overruled.” An example of this is a malicious gateway that simply sends their ID at a higher rate than the real one.
Some manufacturers have different approach: retro-fitting security elements. This process is not optimal when a system has many disperse components. Completing this operation is sensitive, complex, demanding, and often not suitable to be realized in a secure, timely and cost-effective manner.
Conclusion and outlook
The current LoRaWAN standard 1.0.x already contains a comparatively high degree of security. The risks and attack scenarios listed here are legitimate and should be assessed individually for each use case. Solutions have already been discussed above.
In order to meet the increased security requirements in IoT networks, the LoRa Alliance is constantly working on improving the standard. The LoRa Alliance is a non-profit association of organizations that work together to standardize LPWAN networks.
The new LoRaWAN 1.1 specification was published 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 not expected before 2018 at the earliest. LoRaWAN 1.1 standard devices are backward compatible with LoRaWAN 1.0.x devices and can also work with 1.0.2 network servers.
The changes to 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 the current specification 1.0.2. join replay attacks and downlink ACK attacks are taken into account.
For this purpose, for example, the uplink frame counter (FCntUp) was encrypted and included in confirmation messages (ACK downlinks). This new feature enables the end device to recognize which of its messages has been confirmed by the network server.
Other security enhancements include the clear separation between the 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 makes it possible to actively forward messages from end devices across foreign LoRaWAN networks to the home network of the end device.
Special attention was also paid to the “third party join servers” in accordance with specification 1.1. These join servers are no longer managed by the network server operators, but by a trusted third party. All security-relevant keys of the end devices are managed on the join servers and either the network server responsible for transporting the messages or the application server responsible for processing the messages is provided. A clear separation of these responsibilities prevents the network operator (operator) from being able to read the content (payload) of the LoRaWAN messages.