By JP Norair Today (28 Jan 2020), IOActive released a . It has been scooped by many of the usual suspects ( , ). 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. vulnerability report for LoRaWAN ThreatPost EEWeb 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: LoRaWAN endpoints contain multiple keys, but some of them are shared for an entire network Most LoRaWAN endpoints are programmed with a set of keys that persist, unchanged, for the lifetime of the device. Most LoRaWAN endpoints don’t interface with the network frequently, making physical (offline) hacks like very applicable. differential power analysis The LoRaWAN protocol itself doesn’t apply MAC-layer encryption, making man-in-the-middle (online) hacks plausible to implement as well. 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. 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. Secure Elements 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 “ ”, 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. Public Key Cryptography While Public Key Exchange does have some vulnerabilities, the state of the art now may be the 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. Zero-Knowledge Proof 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 (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. STM32WL 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 ( ). For some LPWAN use-cases, it might work: but not for most. litany of well-known vulnerabilities BlueBorne 2. Towards a Side-Channel Mode of Operation for LoRa IoT devices Haystack has been working on the 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. DASH7 Previously published at https://medium.com/@patburns/where-you-can-go-in-the-aftermath-of-the-lorawan-hack-5cfa02820f6b
