LoRaWAN for IoT: Beware Encryption Misconfigurations and Security Pitfalls

lorawan encryption security

Researchers warn users not to “blindly” trust the encryption implementations of their LoRaWAN networks.

UPDATE

The LoRaWAN protocol, which efficiently supports low-power wireless devices over wide area networks, has become standard in the world of the industrial internet of things (IoT). One of its benefits is its support for end-to-end encryption. However, researchers are warning that while LoRaWAN itself is perfectly secure, poor device security and user mistakes in configuration and implementation can still lead to hacks and widespread operational disruption.

LoRaWAN, or Long Range Wide Area Networking protocol, has been a boon to users and developers of IoT devices in smart cities, industrial IoT, smart homes, smart utilities, vehicle tracking and healthcare. However, those implementing it (both equipment vendors and admins/end users) should take care to avoid certain security pitfalls and not be lulled into a false sense of security stemming from the end-to-end encryption, according to IOActive research, released Tuesday.

“The LoRaWAN protocol is advertised as having ‘built-in encryption’ making it ‘secure by default,” Cesar Cerrudo, CTO at IOActive, wrote in the report. “As a result, users are blindly trusting LoRaWAN networks and not paying attention to cybersecurity; however, implementation issues and weaknesses can make these networks easy to hack.”

 

In version 1.0. of the protocol, there are four key elements that shape a LoRaWAN implementation.

The LoRaWAN protocol defines two layers of security: One at the network level and another at the application level, researchers described in the report.

The network-level security ensures the authenticity of the device in the network, providing integrity between the device and the network server, they wrote. The application-layer security is responsible for confidentiality, with end-to-end encryption between the device and the application server, preventing third parties from accessing the application data being transmitted.

Each layer of protection depends on the security of two encryption keys–the Network Session Key (NwkSKey) and the Application Session Key (AppSKey), both of which are 128 bits long.

However, if people who aren’t supposed to have access to the network or devices are able to obtain the keys, they  have an open invitation to the devices and networks being protected by them, researchers noted.

Specifically, once bad actors obtain the encryption keys for a LoRaWAN network, they have a number of attack options available “to compromise the confidentiality and integrity of the data flowing to and from connected devices,” IOActive researchers wrote.

Session Keys and Functions in LoRaWAN v1.0.3

These include conducting DDoS attacks that can disrupt communications between connected devices and the network server so companies can’t receive any data.Mistakes could allow attackers to conduct DDoS attacks and send false data to networks, among other malicious activities.

Attackers also can use the keys to intercept communications and replace these with false data, such as fake sensor and meter readings. In this way, bad actors can hide malicious activity or cause industrial equipment to damage itself, which could not just cause company disruption but potentially destruction of infrastructure or facilities if this occurs at a power plant or in the location of other critical infrastructure, researchers said.

One of the biggest issues in IoT is a lack of security-by-design within the devices themselves. Similarly, insecure LoRaWAN devices could be open to reverse engineering that can “sniff” out keys; or, the source code for a device could be left publicly available from open-source repositories or vendor websites.

On the user side, administrators could forget to remove device tags with code before a device was placed in its final location; or they may not implement keys with sufficient randomness. And as always, using default or weak credentials is a prime concern.

Easy ways to securely implement LoRaWAN include replacing keys provided by vendors with random keys; using different keys for different devices; auditing the root keys used to detect weak keys; and making sure service providers follow security best practices and have a secure infrastructure, IOActive said.

IOActive also warned users, administrators and device vendors to remember their basic security-hygiene practices, since LoRaWAN networks can be penetrated by the same good, old-fashioned methods that any other network can be. These include compromising the system of the device manufacturer responsible for installing the firmware with device keys; hacking the devices or computers of technicians responsible for deploying devices where the keys might be stored; obtaining the keys from flash drives or emails of clients or device manufacturers where they were disclosed and shared; breaching a service provider who had keys stored in their backups or databases; or obtaining an AppKey in a dictionary or brute-force attack, researchers wrote.

This posting was updated at 10:15 ET on Jan. 29 to correct several misstatements. Threatpost apologizes for the errors. 

Suggested articles

Discussion

  • Daniel Evans on

    "stealing source code for a device from open-source repositories" stealing ? lolz
  • HG on

    This article was a complete waste of time. Here I was, actually thinking there may be some kind of new vulnerability in the LoRaWAN Network but no... This article can basically be summarized as "Hackers could compromise UNRELATED systems in order to obtain your encryption keys." That's like saying email is unsafe because you might have written your password down somewhere or WiFi is insecure because the default password is written on the back of the AP. There's barely anything about "key cracking" here at all. There's no new vulnerabilities, there's no security flaw, there's not really anything to worry about.
  • Cab on

    Worthless ad for IOActive
  • EncryptedCookie on

    At first I thought I had not had enough coffee, then I thought maybe I didnt have enough experience, then I realized this article is very poorly written with many invalid statements, misconceptions, and technical misunderstandings. Sad!
  • Ravi Kashi on

    Click bait headline. Nothing remotely connected to LoRaWAN.
  • Erik on

    The issues outlined in this article are common to every private network. LoRaWAN is secure so long as best practices are met for securing devices. Definitely this is a mis-leading and fear inducing article with no non-obvious security vulnerabilities listed. Title should be "how does loraWAN work, and the security vulnerabilities for any network 101".
  • Patrick Burns on

    We did a post on this news: The Conclusion of the Report The reported LoRaWAN vulnerability can allow DDoS (distributed denial of service) as well as falsified data transmission into your LoRaWAN network, so it can be very damaging. There’s no real way to stop LoRaWAN hacking other than to make physical ingress to the devices exceptionally difficult, AND to deploy traffic monitoring software on the application side, to try to infer when penetrations are occurring. The Main Elements of the Vulnerability are: 1. LoRaWAN endpoints contain multiple keys, but some of them are shared for an entire network 2. Most LoRaWAN endpoints are programmed with a set of keys that persist, unchanged, for the lifetime of the device. 3. Most LoRaWAN endpoints don’t interface with the network frequently, making physical (offline) hacks like differential power analysis very applicable. 4. The LoRaWAN protocol itself doesn’t apply MAC-layer encryption, making man-in-the-middle (online) hacks plausible to implement as well. 5. LoRaWAN doesn’t possess security or authentication mechanism beyond encryption, so by compromising the encryption of a single device, a great deal of damage can be done to the device’s network. What Exactly Does This Mean? 1. Decline of the “Secure Element” Any strategy that deploys persistent, cryptographic keys to an IoT device is a vulnerability. Secure Elements are such a poor choice for IoT networks because IoT endpoints are often physically accessible to malicious third parties — things like personal cellular phones generally are not. Secure Elements provide a mirage of security; here they are just a component in a system that is insecure with or without them. With luck, this report should be the nail in the coffin for careless usage of Secure Elements, but there is enough money in component market for Secure Elements that I suspect their mirage of security will persist for some time — potentially making IoT networks vulnerable for years to come. 2. Decline of uplink-limited LPWAN connectivity The research concludes that LoRaWAN 1.1 makes improvements to the security of the network vs. 1.0.2, but ultimately it’s a moot point as long as networks have limited ability to actively manage the keys used by the devices. In other words, it is important for a network to be able to rotate keys faster than a device can be hacked. LoRaWAN’s architecture makes this difficult, as it shares some of the keys across the entire network, so rotating keys must be a global activity. With downlink broadcast or multicast features, workarounds are possible. LoRaWAN’s network architecture prevents downlink multicasting, so protecting network keys is not feasible. Other LPWANs that lack downlink multicast features will have similar limitations. 3. Rise of Asymmetric Cryptography on the IoT Endpoint Also known as “Public Key Cryptography”, this is a technology by which two parties engage in a multi-stage dialog, with the end result of a secure channel being establish between them. Notably, it’s very good for negotiating cryptographic keys for subsequent usage. While Public Key Exchange does have some vulnerabilities, the state of the art now may be the Zero-Knowledge Proof and for LPWAN data flows it is thoroughly sufficient. LPWANs don’t communicate enough, or at great enough throughput, for known hacks to a public key exchange to become vulnerabilities in even a moderately well-construed LPWAN network using Asymmetric Cryptography. Technical Challenges, Moving Forward 1. Limitations of Asymmetric Cryptography in LPWAN IoT One limitation of asymmetric cryptography is that it is more computationally intensive than traditional, low-power embedded devices have had the resources to accomplish. Even with newer Cortex-M4 and M33 chips, it’s a lot of work. However, the STM32WL (which we are extremely excited about) contains a Public Key Accelerator co-processor to improve utility of asymmetric cryptography in the LPWAN use-case. So, it’s clearly a feature that some people have been thinking about. A second limitation asymmetric cryptography is that it requires an extended, two-way dialog. In practice, that’s not something LoRaWAN is capable of delivering. A Bluetooth side channel might be used to do key negotiation via such dialog, but — not considering the added cost and board space — Bluetooth has short range and its own litany of well-known vulnerabilities (BlueBorne). For some LPWAN use-cases, it might work: but not for most. 2. Towards a Side-Channel Mode of Operation for LoRa IoT devices Haystack has been working on the DASH7 protocol for many years. DASH7 offers a lot of LAN features that LoRaWAN doesn’t have, such that it has no trouble enacting a Public Key Exchange. DASH7 also has MAC layer cryptography and provides a lot of control over the session layer, so versus a more rigid technology like LoRaWAN, a network provider has a lot of flexibility for deploying security. DASH7 can run on the LoRa radio, and a LoRaWAN developer can add it to a LoRaWAN endpoint with only some additional firmware. We think DASH7 makes the ideal side channel for adding security to LoRaWAN networks. [external link removed]

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.