Key management concerns impact LoRaWAN IoT device security

Low-power wide-area networks (LPWANs) are helping drive the Internet of things (IoT) explosion. They connect millions of low-power IoT and  Industrial IoT (IIoT) devices into wireless networks over a range of distances, from short to really, really long, from indoor applications to those covering large fields or even cities. But device designers using the LoRaWAN standard may be lulled into thinking that just configuring its security keys is enough to prevent their devices from being hacked. A new report says it isn’t.

Four protocols give enterprises a choice in LPWAN connectivity: cellular NB-IoT, LTE-M, and Sigfox, and the non-cellular LoRaWAN standard. Among these, the open LoRaWAN overwhelmingly dominates. Omdia (formerly IHS Markit – Technology) projects a “quite high forecast” for LoRa, said Lee Ratliff, senior principal analyst, connectivity and IoT.


Omdia LPWAN shipments 2019 vs 2023.jpg (Source: Omdia)

According to the LoRa Alliance, LoRa is used for M2M communications in over 100 million IoT and IIoT devices in industries such as manufacturing, smart cities, smart utilities, vehicle tracking and healthcare.

But with all this wireless traffic, how secure are the nodes of these networks? Not very, concludes a new white paper from IOActive Research on LoRaWAN implementation. Devices are susceptible to hacking, especially those built with revision 1.0 of the standard, including 1.0.2 and 1.0.3, the majority of deployments so far.

LoRaWAN’s mechanisms are well-designed to transmit data securely and the protocol has frequent security revisions. Its vulnerabilities lie mainly in how encryption keys are implemented and managed for network-level and application-level communications among IoT/IIoT devices, gateways and servers. When these aren’t handled correctly, LoRaWAN deployments become easy targets for hackers and other threat actors. In some deployments  — such as process control, automated manufacturing or energy utilities — results could range from inserting false sensor data, to halting electrical service, to interrupting communications in industrial process equipment operations, with potentially harmful effects.

LoRaWAN Security Holes are Avoidable

The problems arise when certain key source code is not replaced before deployment, the same keys are used for a group of devices, or keys are not strong enough to prevent reverse engineering. If a hard-coded key is compromised, it can’t be changed.

IOActive’s researchers also found that tags containing certain information are not always removed before device deployment, that device firmware can be cloned if certain procedures aren’t followed, and that some internet-connected LoRaWAN servers use default or easy-to-guess credentials, and can be easily hacked to access the keys.

In more common cybersecurity faux pas, some of these servers were incorrectly configured or found to be running outdated or unpatched software. Because LPWAN is open, source code can also be easily be obtained online. Other problems the report discusses are not specific to LPWANs, such as data breaches or hacking of device manufacturer or service provider networks.

“Most nodes deployed today are not 1.1, and the first version of LoRa had no provision for over-the-air firmware updates,” said Ratliff. So these nodes probably won’t be updated because of their customized implementation, and the problem of downtime disrupting service.


LoRaWAN provides two layers of security for communication from end device to gateway and from gateway to network server: network-level and application-level. Each uses two 128-bit encryption keys. Data integrity between network server and application server is not defined by the protocol, but left to the service provider. (Source: IOActive)

There’s also no firmware over-the-air (FOTA) update mechanism in LoRaWAN 1.0. “Even if there was, the hardware has to be capable of [it]  — which adds cost because more flash memory is required to hold both firmware images until update is complete  — and there’s a real risk that FOTA could brick a percentage of the nodes or otherwise cause disruption,” he said. “With 1.1, if you’re deploying LoRa and need to do an OTA update, that would not be an issue. But the manufacturer using LoRa must enable that.”

Perhaps most alarming, these vulnerabilities aren’t well known, said Cesar Cerrudo, lead author of the white paper and IOActive’s CTO. Organizations are blindly trusting LoRaWAN because it uses encryption, but that encryption can be easily bypassed if hackers can access the keys, and that’s easy to do in several ways. There’s also not enough awareness of cybersecurity issues among users, who assume that just because the protocol has encryption, security keys are enough to protect communication. Some manufacturers might add encryption to their LoRaWAN devices, but it might not be good enough, since they’re not cybersecurity experts.

Also, no tools exist for testing networks or detecting cyberattacks, said Cerrudo. The company has released an open source set of tools, the LoRaWAN Auditing Framework, so users can audit and penetration test their infrastructure’s security. The report itself contains techniques for detecting possible cyber attacks with the help of these tools, as well as best practices and basic security hygiene for LoRaWAN implementation.

Tanner Johnson, Omdia’s senior analyst for cybersecurity technology, confirmed the lack of cybersecurity tools. “While there may be some private, custom implementations of security tools for monitoring, detecting and preventing cyber threats on LPWANs, there aren’t any such tools widely available that are customized for individual protocols,” he said. “In IoT cybersecurity the primarily objective is visibility.”

Problem probably not limited to LoRaWAN

Cerrudo said IOActive chose LoRaWAN to investigate because of its popularity and open technology, unlike the proprietary Sigfox, although Sigfox has security issues, too, including similar problems with handling keys. With LTE-M and NB-IoT, users generally rely on the wireless communications service provider for security.

Other LPWAN standards have probably not been examined as closely as the popular LoRaWAN, so it isn’t known yet if they’re easier or more difficult to implement securely, said Ratliff. “LTE-M borrows from the LTE standard that’s been scrutinized quite a bit. So a lot of people think it’s just as safe as LTE. NB-IoT is new and getting as much attention as LoRa. But it’s not as commonly deployed outside of China so it may not be in the same boat.” Most likely, vulnerabilities will eventually be discovered for NB-IoT, too.

It’s important to remember the security differences between wired versus wireless, said Ratliff. Wireless networks are more vulnerable than wired because in them, the attack surface is every node, not just a single gateway requiring physical access. With wireless protocols, hackers can access nodes remotely, so there’s little risk. That means even with a secure network, they’re always trying.

>> This article was originally published on our sister site, EE Times.

 

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.