This brief article highlights some key LoRaWAN Security vulnerabilities and potential exploits that malicious actors could launch against a LoRaWAN network.

We have outlined some of the potential mitigations which you should be using to improve the security of your LoRaWAN network.

LoRaWAN Denial of Service (DoS) in Activation by Personalisation (ABP) mode

In 2018, researchers from the Netherlands released a report “Security Vulnerabilities in LoRaWAN” outlining several possible attacks on a LoRaWAN network. One vulnerability in LoRaWAN 1.0.x arises because the frame counter in LoRaWAN Data messages is only 16 bits long, meaning that it was possible to replay a captured packet, wait until the counter overflows and replay this packet to implement a denial-of-service (DoS) attack.

Mitigations against this LoRaWAN DoS Security Vulnerability:

• Upgrade to LoRaWAN 1.1 or later
• Do not use ABP – use Over the Air Activation (OTAA)

Bit Flipping Security Vulnerability in a LoRaWAN network

In all LoRaWAN networks, messages are decrypted by the Network Server (NS) and thereafter, such as when sent to the Application Server (AS), whilst the Application payload is encrypted and integrity-protected, the messages are no longer protected against tampering, such as bit-flipping.

Mitigations against this LoRaWAN Security Vulnerability:

• Secure communications between your LoRaWAN servers by using architectures such as MQTT over SSL; or with IPSec VPNs; or SSL tunnels, preferably with a client SSL certificate.
• Future LoRaWAN versions might consider including another MIC field inside the MAC Layer Payload computed by the AppSKey.

Ack Spoofing Security Vulnerability

An LoRaWAN acknowledgment mechanism can be used to extend battery life in end-devices by reducing the time the radio needs to be powered up. However as Xueying Yang, Evgenios Karampatzakis, Christian Doerr, and Fernando Kuiper highlighted in their paper “Security Vulnerabilities in LoRaWAN“, the ACK message does not indicate which message it is confirming.

The researchers proposed that by selectively jamming the downlink when an end-device sends a confirmed message to the receiving gateway, the end-device will not receive the ACK, and will retransmit its message multiple times until it considers it lost or refused.

During the jamming session, however, the attacker could capture the downlink ACK message and replay it when the end-device sends a second confirmation message.

Attack on LoRaWAN Class B End Devices

Most LoRaWAN end-devices operate in LoRaWAN class A mode, which specifies that downlink traffic should follow an uplink. The LoRaWAN Class B mode of operation aims to conserve battery power by having end-devices wake up periodically to wait for any incoming messages during a receiving time window.

The durations of the receiving windows are specified by Beacon messages from Gateways, which comprise of a PHY layer header followed by a beacon payload:

Beacon frame structure for the EU 863- 870MHz ISM band

It was shown that an attacker could easily compute the different publicly-known fields with malicious parameters to:

• Find the location of a LoRaWAN gateway (since the GwSpecific field with an InfoDesc subfield contains GPS coordinates)
• Drain the battery by sending Beacons crafted with an extreme wake-up time value.

According to their paper (as well as the separate LoRaWAN security evaluation paper “ChirpOTLE: A Framework for Practical LoRaWAN Security Evaluation” by Frank Hessel, Lars Almon, Flor Álvarez) and the LoRaWAN v1.1 specifications, the integrity of Beacon frames is still an issue.

Mitigations against this LoRaWAN Class B Security Vulnerability:

LoRaWAN developers could re-code to use a Message integrity Check (MIC) in place of the LoRa PHY Cyclic Redundancy Check (CRC) to check the integrity of the Time field (and indeed the rest of the Beacon payload). Note that this is a non-trivial task.

LoRaWAN Root Key Management Security Vulnerability

The management of keys is critical to LoRaWAN security.

Root keys are used when OTAA devices derive Session keys (AppSKey and NwkSKey) during a Join procedure with the LoRaWAN network.

Because the backend Join Server (JS) may be exposed to the Internet, a malicious actor could exploit critical weaknesses and vulnerabilities (such as LFI, SQL injection, de-serialisation vulnerabilities, etc.) to access the secret Root keys and then read the frames exchanged during a Join procedure data. The attacker could then decrypt uplink and downlink transmissions; craft downlink packets; impersonate end-devices; and perform other illicit activities.

Mitigations against LoRaWAN Root Key Security Vulnerability:

• Use OTAA mode and LoRaWAN version 1.1
• Use unique and randomly-generated keys (including NwkKeys and AppKeys)
• Secure and protect key management servers and services
• Do not expose public management interfaces
• Use a client certificates for authentication
• Audit all management interfaces
• Use Hardware Security Modules (HSM) to hold Root keys

LoRaWAN Sensor and Gateway Security Vulnerabilities

LoRaWAN Transceiver and Controller (MCU) interface vulnerabilities

Many LoRaWAN sensors, transceivers and gateways have some common hardware vulnerabilities, including unsecured physical interfaces through which attackers can gain access to the LoRaWAN device, its code, storage, registers and more. These interfaces include:

• Universal Asynchronous Receiver-Transmitter (UART)
• Serial Peripheral Interface (SPI)
• JTAG port
• Inter-Integrated Circuit (I2C)
• In-Circuit Serial Programming (ICSP)
• and other access methods.

We can connect to these interfaces using hardware such as HydraBUS, BUS Pirate, BusVoodoo, J-Link and others, and interact directly with the LoRaWAN hardware.

We can then extract secrets from the LoRaWAN equipment if one of the above interfaces is enabled and has weak authentication mechanisms (or none – as is too often the case) applied to the interface.

External Flash Memory vulnerabilities

With controllers that use external flash memory, we can use serial interfaces or direct access to the chip pins to extract and copy firmware.

Mitigation against LoRaWAN Hardware Security Vulnerabilities

• Choose LoRaWAN equipment that is verified to be resistant to known physical attacks.
• Configure memory protections (fuse bits) to prevent attackers from dumping memory contents via programming interfaces.

Secure Element (SE) Vulnerabilities in LoRaWAN Equipment

Some superior LoRaWAN sensors, transceivers and gateways incorporate Secure Elements (SE) to make these types of attack more difficult. In the case of LoRaWAN, the Secure Element can be used to store the master / Root keys that are used to Join LoRaWAN networks, encrypt LoRaWAN communications and protect LoRaWAN message integrity.

Unfortunately, some LoRaWAN equipment developers have not used correctly the Secure Elements incorporated into their equiment to the extent that, using freely-available code, attackers can communicate via I2C using the Secure Element.

In other cases, developers have not used Secure Boot functionlity correctly, enabling the SE to be removed, used in attacker’s hardware, and all if the secrets to be extracted from it.

Using captured LoRaWAN security keys, attacker can also eavesdrop on communications by letting compromised devices
communicate with a network and then capturing the sensitive information exchanged between the end-device and the LoRaWAN network.

Securing your LoRaWAN Network

LEVER Technology Group provide bespoke consultancy and training in LoRaWAN network Planning, Design, Testing, Installation, Configuration, Management, Support and Security.

Our LoRaWAN Security Audit and Security Policy services ensure that your organisation’s security posture is properly set and maintained.

Our Understanding LoRaWAN IoT Solutions training course is just one example of the advanced, in-depth and hands-on practical training that we deliver to our LoRaWAN clients.

Contact Us to learn more about how we can help to ensure that your LoRaWAN project is a success.