LoRaWAN Security 101 (Non-5G IoT Connectivity Options)

I get accused of focusing too much on 5G as the only future IoT connectivity option. I do write a lot about how 5G will revolutionize our society, become the most critical of critical infrastructures and about security threats with 5G. I see 5G, with its low latency, high bandwidth, network slicing and ubiquitous coverage becoming the foundational capability for mission critical industrial, agricultural, financial, medical, education, energy and transportation, even military and emergency services IoT communication needs.

That’s not to say that 5G is the only IoT connectivity option. There are plenty of others.

IoT applications have some common requirements such as low energy consumption and cost effectiveness, but they also differ in their data rate, latency, range, reliability and other requirements. And, what I care most about, they vary in how they address security.

In the next few articles I will explore security features of some key IoT wireless technologies besides 5G.

Why LoRaWAN?

The most commonly used short-range radio technologies that operate at a personal or smart home range are Zigbee and Bluetooth.

Prior to 5G, long-range solutions based on cellular communications (2G, 3G, 4G) provided larger coverage, but they consumed excessive device energy and had too high latency for many use cases.

Therefore, IoT applications’ requirements have driven the emergence of a new wireless communication technologies termed Low Power Wide Area Network (LPWAN) designed to connect IoT devices with low power requirements, long range and low cost.

Some LPWAN technologies, such as e.g. NB-IoT, are cellular technologies operating in the licensed spectrum.

The Long-Range Wide-Area Network (LoRaWAN) and Sigfox are the two leading non-cellular LPWAN technologies that compete for large-scale IoT deployments.

There are specific use cases for which non-cellular LPWAN technologies will remain more suitable than 5G. For example, devices for which the battery lifetime of over ten years is important, might want to consider these non-5G communication technologies. In areas where 5G is not deployed or can’t reach (e.g. underground) LoRaWAN might be more suitable. In Smart Cities where density requirement might be even higher than the planned 5G one million devices per square km, LoRaWAN could provide a solution – addition of one gateway could support additional ten million devices. For private networks, 5G is not an easy deployment option. For mMTC applications in large-scale deployments, especially for non-time-critical sensor use cases without, or with low Quality of Service requirements, LoRaWAN will probably continue complementing 5G even after 5G is widely deployed.

While I expect 5G to become the catalyst for massive IoT (mIoT) development, pragmatic implementation approaches will have to combine 5G, NB-IoT, LoRaWAN and other technologies based on their strengths. Indeed, with many of my network operator clients we are working on securing a mix of cellular and non-cellular technologies planned to continue even after the arrival of 5G.

LoRaWAN Introduction

LoRaWAN provides long distance connectivity to IoT devices. It is designed for wireless battery-operated network, and it fills the gap between short-range low-power-consumption networks and long-range high-power-consumption networks. LoRaWAN is one of the dominant public specifications worldwide, with more than 500 vendors and 100+ LoRaWAN network operators having deployed LoRaWAN in more than 100 countries.

LoRa is the protocol at the physical and data link layer (LoRa PHY) – a proprietary radio modulation technology for wireless LAN. LoRa is a patented technology owned by Semtech.

LoRaWAN is developed on top of LoRa PHY as an open standard. It provides network, transport, session and presentation layer mechanisms and is managed and promoted by the LoRa Alliance.

LoRa physical layer RF modulation is based on a chirp spread spectrum modulation. It is the first low cost commercial implementation of this modulation which was previously used in military and space communication due to the long range that can be achieved. Chirp maintains the same low power characteristics as the frequency shifting keying (FSK) modulation used by many legacy wireless systems in the past, but significantly increases the range.

While the LoRa physical layer enables the long-range communication, it is the LoRaWAN communication protocol and network architecture that most influences the security, quality of service, battery lifetime and network capacity.

The lower frequencies which LoRaWAN uses are known as the unlicensed spectrum, more specifically the unlicensed radio spectrum in the Industrial, Scientific and Medical (ISM) bands. In Europe LoRaWAN uses the 867-869 MHz band, in the U.S. 902-928 MHz, while in China the 470-510 MHz band.

Different from Bluetooth, GSM, 3G, LTE or some other well-known wireless communication technologies, LoRaWAN provides the range of cellular networks and has the flexibility of Bluetooth or WiFi with the specifically designed devices to support very long battery life. Thinking about cybersecurity, design choices focused on energy consumption are already raising cybersecurity red flags for me. Complex encryption algorithms cannot be easily used in energy-constrained IoT devices. Advanced cryptography algorithms are not suited to IoT devices with limited energy and memory space because these algorithms often require a large storage space and strong computing capability. Every attempt to improve IoT security usually negatively impacts the energy management. Let’s see how LoRaWAN deals with this.

Typical LoRaWAN applications can be found in the IoT domain, with small sensors/devices that exchange information on a limited time interval and that are power supplied by batteries.

The most important LoRaWAN characteristics are:

• long range (several miles in urban environments, dozens of miles in rural environments);
• deep penetration (especially compared to 5G);
• very long battery life (10+ years);
• low cost modules;
• low data rate (0.3 bps – 50 kbps);
• unlicensed radio frequency spectrum;
• native geolocation;
• bidirectional communication; and
• open standard.

LoRaWAN has some limitations as well, such as low network efficiency – i.e. large packet loss; or limited ability to control devices. So ideal use cases are simple sensors that don’t have to transmit frequently and in which occasional packet loss would not cause adverse impact. For example, smart meter readings that are updated every hour or so are an ideal example. With them it doesn’t matter if an occasional reading is missed, as long as some make it through.

Some other interesting LoRaWAN use cases are:

• smart transit tracking and scheduling (e.g. smart bus signage in Montreal);
• nationwide smart metering;
• flood-monitoring;
• IoTracker solution locating devices that can be lost or stolen (bicycle, wallet, etc.);
• GeoWAN Cattle Tracking is used by Australian farmers;
• xignal Mousetrap is a LoRaWan-connected mouse trap;
• tracking pace of play on a golf course;
• acoustic monitoring for proactive management of noise pollution;
• lighting and humidity management for indoor botanical garden;
• parking place occupancy sensor.

Instead of the more common IoT mesh topology (e.g. ZigBee), LoRaWAN uses a star-on-star topology illustrated in Figure 1. Gateways relay messages between network server and end-devices. LoRa RF modulation is used between end-devices and gateways. Between gateways and servers a standard IP connection is used. While the mesh architecture could increase the range and reliability, it also reduces battery lifetime as nodes receive and forward information from other nodes that is likely irrelevant for them. LoRaWAN long-range star-on-star architecture and three communication modes that can help further lower the power consumption comprise the best compromise to preserve battery lifetime while providing long-range connectivity.

Figure 1. Illustration of LoRaWAN architecture

A LoRaWAN network is based on following entities:

1. Wireless LoRaWAN end-nodes (end-devices or client devices). Nodes are used to measure or to remotely control external physical systems and processes. They are typically low powered and communicate wirelessly with one or many gateways. The nodes are asynchronous and communicate only when they have data to send whether event-driven or scheduled. A Node is normally formed of a LoRa transceiver which is managed by a microcontroller. Nodes are separated in classes according to predefined characteristic behavior (A, B and C class) based on the trade-off between communication latency and battery lifetime.
2. Gateways which relay messages between end-devices and network server. In this architecture, the key attribute for LoRaWAN gateways required to achieve long-range and low-cost is the high capacity. Millions of devices should be able to connect to a single gateway. This is achieved by utilizing adaptive data rate and by using a multichannel multi-modem transceiver in the gateway so that simultaneous messages on multiple channels can be received.
3. Network server as a center of a star topology. Necessary intelligence is all centralized at the network server. It manages the network, manages the security, manages adaptive data rate, etc. (In the latest specification this architecture is expanded to support global roaming. It adds few roles for network servers and a join server complicating the above architecture somewhat and complicating the security analysis.)
4. One or more application servers.

LoRaWAN Security Overview

Security considerations have been built into the LoRaWAN from the first version of the specification released in June 2015.

LoRaWAN utilizes two layers of security: one for the network and one for the application. The network security ensures authenticity of the node in the network while the application layer of security ensures the network operator does not have access to the end user’s application data.

Figure 2: LoRaWAN two-layers security

LoRaWAN uses symmetric-key cryptography to provide secure wireless communication. This means that a root key that is stored in a node must also be made available to the network in order to generate session keys. LoRaWAN utilizes two layers of security – one for the network and one for the application layer, as presented in Figure 2.

The security mechanisms are based on a symmetric root key shared between an end-device and the Network Server. From this key, two distinct per end-device session keys are computed: the application session key guarantees the data confidentiality between the end-device and the Application Server; and the network session key that guarantees the data integrity between the end-device and the Network Server.

Standardized AES encryption is used with the key exchange utilizing an IEEE EUI64 identifier. It combines the original AES encryption/decryption algorithm with several modes of operation, including a Cipher-based Message Authentication Code (CMAC) and a Counter Mode (CTR). The former is used to protect the integrity of messages, while the latter is employed for data encryption.

Before a node can exchange messages in the LoRaWAN network, activation procedure has to be finished. Two activation methods are available in LoRaWAN networks:

a) Over-the-Air Activation (OTAA) method – based on over the air Join Request and Join Accept messages handshake. Join Request messages are generated by the nodes where every node is deployed with a 64-bit DevEUI, a 64-bit AppEUI, and a 128-bit AppKey used for their identification to network server and cryptographical signature of the Join Request. 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 unique randomly generated nonce value – AppNonce. The Join Accept reply includes the AppNonce, a NetID, end device address (DevAddr) along with configuration data for radio communication link, like RF delays (RxDelay) and determined channels (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 nodes are receiving messages back from the network, 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.

b) Activation by Personalization (ABP) method – differs from OTAA, as the unique DevAddr and both session keys (NwkSKey and AppSKey) are already deployed in the nodes. Since the nodes already have the information and keys they need, they can begin communicating with the network server without the join messages exchange.

Once a Node has joined a LoRaWAN network, either through OTAA or ABP activation method, in compliance with LoRaWAN Specification 1.1 all future messages will be encrypted and signed by using a combination of specific keys – NwkSKey and AppSKey:

• Network Session Key (NwkSKey) – is network layer security mechanism. This unique end-device key is shared between node and the network server. Main tasks of Network Session Key are to provide message integrity for the communication and security for end-device to Network Server communication.
• Application Session Key (AppSKey) – is responsible for end-to-end (application to application) ciphering of the payload. This is also an AES 128-bit key, unique per end-device. It is shared between End-device and Application Server. The Application Session Key’s role is to encrypt / decrypt application data messages and to provide security for application payloads.

These two session keys (NwkSKey and AppSKey) are unique per device. If the device is dynamically activated (OTAA), these keys are re-generated on every activation. If the device is statically activated (ABP), these keys stay the same, until they are changed manually.

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.

LoRaWAN Security Strengths

Security best practices refers to the roles and responsibilities of the entities in the LoRaWAN ecosystem and the security controls that are in place through the lifecycle of sensors, attempting to join LoRaWAN networks. Some representative examples of LoRaWAN security:

• OTAA provisioning – for each session, keys/certificates are dynamically negotiated between a node and the Network and Application Servers. Some additional security improvements in devices are provided by periodical starting of network re-join procedure that would change session keys. Successful security attacks like spoofing, tampering etc. become complex in such an environment.
• Dynamically activated devices (OTAA) use the application key (AppKey) to derive two session keys during the activation procedure. In the network, their value is set to default AppKey, which will be used to activate all devices. Recommendation is to have specific and customized AppKey value per each device. Another important fact is that, in complete security process, no keys are exchanged over the air, but only the missing parts of a calculation, from both sides. These capabilities are important as prevention against compromising the keys by intercepting traffic over the air.
• With all the SIM card related vulnerabilities, such as e.g. recent SimJacker, it is a security strength that LoRaWAN is non-cellular and doesn’t require a SIM card.
• Physical security of end-devices is an important task. In order to protect the network from physical attacks, especially from device capture attacks, tamper-resistant hardware should be used.
• Secure element or secure hardware component built in a device that stores and keeps safe security credentials supports the overall security. This will make it more complex to extract the keys by reverse-engineering or scanning device memory.
• If possible, it is very useful to have additional layer of encryption and authentication at the application layer.
• Possibility of malicious capturing and storing messages exists in wireless networks. By security mechanism implementations in LoRaWAN network, it’s becoming complex to read messages because they’re encrypted by the AppSKey. In the Network layer, it is not possible to exchange messages without the NwkSKey, because of MIC (Message Integrity Code) check deployment. However, it is possible to retransmit messages. These so-called replay attacks can be detected and blocked by using frame counters. By node activation, frame counters (FCntUp and FCntDown) are both set to 0 value. Every time the device transmits an uplink message, the FCntUp is incremented and every time the network sends a downlink message, the FCntDown is incremented. The message exchanged between node and network is ignored if either the device or the network receives a message with a frame counter that is lower than the previous one. It is very important to save frame counters parameters to the permanent memory in a timely manner.
• The acknowledgement of LoRaWAN data frames is optional, since it is wireless communication and some standard protocols like TCP are just not applicable. This means that message confirmation is performed only in case of acknowledgement requirement. An optional frame acknowledgement is ideal for LoRaWAN, since the over the air time (radio transmission time) for devices is limited and a certain amount of packet-loss might not influence overall information transfer. In order of validation, a MIC is added to each data frame. It is basically a signature calculated over the frame, using a Network Session-key. This means that each frame has a unique signature, even the same payload is transmitted multiple times because of the frame-counter increment for every transmission.
• HTTPS and VPN technologies have been built-in to secure backend communication. The backend interfaces involve data control and signalization among network and application servers.
• There are available LoRaWAN cloud services (like Simfony) that connect gateways to LoRaWan cloud infrastructure, using secure mobile data connections or the existing internet provider resources.
• AppKey and AppSKey are not available for the network operator, so it is unable to decrypt the application payloads.
• In Oct 2018 LoRa Alliance released three new specifications with significant security implications. Specifications are: LoRaWAN Application Layer Clock Synchronization Specification v1.0.0; LoRaWAN Remote Multicast Setup Specification v1.0.0; and LoRaWAN Fragmented Data Block Transport Specification v1.0.0.
• Together, these new specifications support and standardize firmware updates over the air (FUOTA), a capability unique to LoRaWAN among low power wide area networks (LPWANs). The ability to update devices remotely is critical for the IoT, where many sensors are in remote or difficult locations to reach but may require updating.
• Together, the new specifications enable FUOTA, however, three separate specifications have been issued because each can be used independently. For example, remote multicast setup protocol can be used standalone to send messages to a group of end-devices; fragmentation can be used on its own to send a large file to a single end-device (unicast); and time synchronization also can be used as a standalone capability.
• The multicast, the protocol has a means to securely deliver a cryptographic key to the group of end devices.

LoRaWAN Security Concerns

Like other wireless technologies, LoRaWAN has some security vulnerabilities. LoRaWAN networks deployment should be architected with an awareness of possible security threats.

LoRaWAN guarantees security for LoRa devices through symmetric-key cryptography. Despite the security features we just discussed, LoRa devices are susceptible to security attacks. For instance, LoRa modulation requires between 900 milliseconds and 1.2 seconds for each LoRa transmission.

This wide transmission window provides ample opportunities for attackers.

The secret key distribution is considered as a critical issue of AES like other symmetric encryption algorithm

Some of the most important security issues in LoRaWAN would be:

• Encrypted messages have the same length as the key.
• The session keys are derived from the long-term secret key – AppKey, as presented in Figure 5. Therefore, if AppKey is compromised, the past session keys can be recovered while the encrypted traffic can be decrypted.

Figure 3: AppKey and session keys derivation

• Besides, once the session keys are compromised, security will be threatened, because it would be too complex to change the AES keys on all nodes – devices.
• Because of available roaming according to LoRaWAN specification 1.1, several network servers support this feature – home, serving and forwarding network server. In addition, one join server and one application server are also required, which brings the following challenges:
• Network management and orchestration becomes complex for the service provider.
• There is a lack of session definition (e.g. an OTAA session). There is no unambiguous value of the session period for the higher protocol layers like it is defined in Physical Layer specification.
• Susceptibility to bit-flipping attacks between network and application servers and to other kind of MITM attacks, as the unprotected frame payloads, are first transported from the serving network server to the home network server and then to the application server.
• Handover-roaming can cause a fall-back of network server when the serving network server runs an older version of LoRaWAN (v1.0).
• LoRaWAN Key Storage (AppKey, NwkSKey and AppSKey) is of crucial importance for security. There are several vulnerability points related to key life cycle management, session key generation, key storage and transport that need careful design and implementation. All device keys should be protected in proper way to mitigate threats of exposure. LoRaWAN Network Server Key Storage is a single point of failure for an entire system. Once this server or set of servers is/are compromised, the entire LoRaWAN system security is affected and attackers are free to intercept or spoof any message.
• It is very important to implement properly the Exit procedure that is responsible for decommissioning of the nodes (end-devices) after their license ends or if they are compromised and wanted to be excluded from the network. Application-layer programming is responsible for the Exit procedure determination and implementation. It is apparent that mistakes connected to the Exit procedure might cause complications. For example, an exit procedure of an end-device should result with the permanent termination of all IDs, passwords, counters, and other parameters related to the specific end-device. Application-layer programmers are strongly advised to be very careful in the implementation of Exit procedures for decommissioning purposes.
• Any kind of capture or physical attack on gateways or its failure would affect the communication between the nodes and the rest of the network.
• Another gateways weakness lies in the identification and connection process. Every gateway sends beacons (it’s ID) to the server periodically. If the ID is opened and someone without authorization read it, the gateway can be “overruled” by a malicious gateway that simply sends this ID at a higher rate than the real one.
• Furthermore, a beacon synchronization DoS attack is typical rouge gateway attack. In LoRaWAN, Class B beacons are not secured by any means, indicating that an attacker can set up a rouge gateway to send fake beacons. This could result in class B nodes to receive messages in windows out-of-sync with the rouge gateway and also increased collisions on transmitted packets.
• Nodes or end user devices that are not under surveillance (for example at the customer premises) are more vulnerable to security threats. If unprotected, nodes can be exposed to device cloning, firmware replacement or parameter extraction and then lead to rogue end-device attacks. Rogue end-devices can be used to perform replay attacks. Packets being transmitted by the neighbors can be captured and replayed more frequently later on – network flooding attack. This might cause waste of network resources and decrease the availability of the gateway for the legitimate end-devices.
• End-devices can also be exploited by the attackers. They can be used as jammers in the network to perform DoS attacks. This might cause the LoRaWAN network, to be unavailable for legitimate end-devices in certain area, while the rest of the network continues regular behavior and operation.
• Some manufacturers have different approach – they retro-fit security elements. When a system has many dispersed components, this process is not optimal since it is sensitive, complex, demanding and often not suitable to be realized in secure, timely and cost-effective manner.

Quantum Weakness

LoRaWAN uses AES-128. It is one of the strongest and and most efficient algorithms in existence today. While some AES weaknesses have been uncovered by researchers, exploiting them is not practical. Yet. NIST claims that AES-128 should be secure at least up to 2030. ECRYPT-CSA sees it as secure until 2028 (See https://www.keylength.com).

However, AES-128 is not secure against quantum attacks. The best-known theoretical attack is Grover’s quantum search algorithm. In a post-quantum world only AES-256 is seen as being medium-term secure, while AES-128 is insecure.

This is more than just a theoretical discussion. One of the key selling points for LoRaWAN is the 10+ battery life for devices. Which means that many of today’s implementations are supposed to have operational life longer than the predicted commercial appearance of quantum computing. We have to think today about how quantum resilient our cryptographic choices are. Or at least how easy they are to upgrade.

Conclusion

Security challenges affect LoRaWAN like all other IoT technologies. In order to meet the increased security requirements in IoT networks, the LoRa Alliance is permanently engaged in standard development. In the same time, the overall security of the LoRaWAN network depends on the implementation of specific security solutions and deployment that need to be considered by the manufacturers, the carriers – network operators and their best practices. These two types of security issues are not specific exclusively to the LoRaWAN, but are equally applicable to any other wireless technology. LoRaWAN security issues must be analyzed from the very beginning of network design and should be assessed individually for each use case.

(Disclaimer: Postings on this site are my own and don't necessarily represent PwC positions, strategies or opinions.)

(Originally published at https://5G.Security)