The LoRaWAN® protocol is especially optimized for low power, wide area networks (LPWANs). It supports secure, bi-directional communication for IoT applications which scale to connect millions of potential devices. As security is a fundamental need in all IoT applications, the LoRaWAN protocol was designed with security in mind, with authentication and encryption built into the specification itself. However, a secure network protocol is only one half of the equation. Deploying a LoRaWAN-based application requires correct implementation of the protocol and a close adherence to recommended practices.
Semtech recently hosted “LoRaWAN: Providing Secure and Reliable Connectivity,” a webinar focused on what makes LoRa® devices and the LoRaWAN protocol a leading choice for securely connecting one’s Internet of Things (IoT) applications. The webinar was a joint effort, and featured speakers from Actility, the LoRa Alliance® and The Things Industries, prominent leaders within the LoRaWAN ecosystem.
This blog is a summary of the recent webinar and features a selection from some of the Q&A asked at the event. For further reading on the topic, we encourage you to learn more in the LoRa Alliance’s security white paper.
The webinar addresses many common security concerns and demonstrates that implementation and deployment matter. Taking a deep dive into the protocol specification, the speakers discuss three fundamental levels of LoRaWAN-based security: between the end device and Network Server, Application Server and Join Server.
Between end device and Network Server, a Message Integrity Check (MIC) provides integrity protection, data origin authentication and replay protection. End-to-end encryption between the end device and the Application Server is detailed. The messages exchanged during the Join Procedure ensure only authorized end devices can access the network. This process takes place during Over the Air Activation (OTAA). Additionally, we explain how a device is provisioned before it joins a network, and explain the specificity of Activation by Personalization (ABP).
To explore OTAA and ABP in depth, visit the Technology in Depth videos available on the LoRa Developer Portal.
The webinar then turns its focus to implementation. This involves following the LoRaWAN specifications and applying recommended practices to ensure backend security. Deployment is even more important, as this is where most common security flaws take place. The webinar concludes with the benefits of certifying one’s devices through the LoRa Alliance’s LoRaWAN CertifiedCM program, as well as benefits of LoRa Alliance membership for those interested organizations and ecosystem businesses.
Learn more about successfully deploying safe and secure LoRaWAN-based applications below, with a selection of the Q&A from the event.
With ABP, an end device keeps the same security session for its entire lifetime. It is recommended to use OTAA in end devices instead, as it can renew session, which is a security best practice. One should consider ABP for transmit-only devices.
The current version of LoRaWAN link layer specification is 1.0.3. Version 1.0.4 will be published in the near future, and from a security standpoint, it mandates recommended best practices from v1.0.3. These include 32bit frame counters, never resetting frame counters for ABP devices and making DevNonce a counter. Once published, v1.0.4 will be the recommended version. The LoRa Alliance Technical Committee will then work on Version 1.1.1, which is a bigger implementation step, and will be interoperable and backwards compatible with all prior LoRaWAN specification versions (e.g., v1.0.3, v1.0.4) at both the end device and network levels. On the security side, Version 1.1.1. derives one session key per security usage, which is another good practice in security, and all MAC commands are encrypted. Version 1.1.1 also adds one root key, one for the network (NwkKey) and one for the application server (AppKey), to further separate the network from the application and add a mechanism for periodic session renewal. The main addition of 1.1.1 will be active roaming, so that the visited network can established a new security session with the roaming end device.
The Join Request is addressed by the Join Server; it is received by a Network Server, then forwarded to be validated and actioned by the Join Server. If it was encrypted, since only one Join Server knows the root key for a given device, the Network Server would not be able to decrypt it, and therefore would not route the request.
The join request has a MIC which only the end device can compute, or the Join Server can verify, using the end device’s root key. It is not possible to spoof a join request frame or replay an old join request frame because the Join Server keeps track of the DevNonce, which increments at each new join request.
The LR1110 chip includes a hardware cryptographic engine dedicated to LoRaWAN security. It performs AES-128 computations, key derivation, MIC computation, Join Accept verification, and storage of secure root and session keys. Each chip comes with a EUI and a securely generated root key, which are also provisioned on Semtech’s Join Server. Of course, it is not mandatory to use this simplified provisioning, a manufacturer can provision a device on any other Join Server by utilizing a different EUI and root key during production.
To explore LoRaWAN security in depth and get a detailed explanation of how to implement applications resistant to today’s networking threats, watch the webinar on-demand now.
Semtech, the Semtech logo and LoRa are registered trademarks or service marks, and LoRa Edge is trademark or service mark, of Semtech Corporation or its affiliates.
