Where You Can Go In The Aftermath Of The LoRaWAN Hack

By JP Norair

Today (28 Jan 2020), IOActive released a vulnerability report for LoRaWAN.  It has been scooped by many of the usual suspects (ThreatPost, EEWeb).  I don’t think these articles really give an idea about what the vulnerability is, exactly, or what can be done.  The report is very readable, and you should read it if you’re an engineer, but if you don’t know where to start with this security stuff, I’ll try to summarize here.

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.

Previously published at https://medium.com/@patburns/where-you-can-go-in-the-aftermath-of-the-lorawan-hack-5cfa02820f6b