LoRa Security - Building a Secure LoRa Solution
The LoRaWAN protocol like many of its rivals offers encryption and secure methods of provisioning end devices (Nodes). However these features should not be blindly trusted by developers and users as they do not defend every possible attack against their solution, and their effectiveness will be governed by the developer’s implementation.
The external assets of solutions are made up of Nodes and Gateways which communicate with a Network Server. Nodes are used to measure and sometimes to remotely control external systems. They are typically low powered and communicate wirelessly with one or many gateways. A Node is normally formed of a transceiver which is managed by a microcontroller. The microcontroller can send management commands to the transceiver to configure network settings or to send and receive application data which the transceiver is responsible for delivering to the Network Server via the Gateways. Although Nodes can be listening at all times, it is standard for the Node to work in a “call then listen” configuration, whereby the Node will send data to the Network Server and then have short windows afterward where it listens for data coming back from the Network Server.
Gateways are fewer in number and transfer data from the Nodes back to the Network Server using standard IP connections. A solution, therefore, follows a “star of star” topology, where multiple Nodes talk to one or more gateways, which in turn talk back to a single Network Server. Gateways perform no security functionality themselves but merely act as a conduit to relay data between Nodes and Network Server.
The Network Server is not so well defined but represents the edge of the systems that would store and parse the data sent from the Nodes. In several systems already deployed, the Network Server is an Internet-facing web service which the Gateways can connect to using, for instance, cellular networks.
Network Stack
Radio PHY layer
All LoRaWAN messages have a PHY layer containing a preamble (8 bytes of 0x34 for EU863-870MHZ ISM Band), plus a header and payload, each with CRCs.
The starts with a MAC header followed by the MAC Payload and an integrity check value, which is covered in detail in Section 3 of this document. The MAC Header and Payload contain both the user’s data, plus header information (such as the type of message being sent) and version information.
MAC Payload
The MAC payload contains a Frame-Header (holding the source and destination addresses plus frame counter), a Frame Port and the Frame Payload which holds application data.
The Frame Port is used to determine if the message is containing only MAC commands (where it is set to 0), or application specific data (where it should be set to the number for the relevant application).
Security features offered by
The LoRaWAN protocol provides both signing and encryption for parts of LoRaWAN packets. These are performed using symmetric keys known both to the Node and to the Network Server (and potentially to Application Servers located behind the Network server depending on requirements) and are distributed in one of two ways depending on how a Node joins the network.
Joining a Node to a network
The first method by which Nodes are allowed to join a network is through Over-The-Air-Activation (OTAA). Here each Node is deployed with a unique 128-bit app key (AppKey) which is used when the Node sends a join request message. The message is not encrypted but is signed using this AppKey. The Node sends the join-request message including its unique AppEUI and DevEUI values plus a which should be a randomly generated two-byte value. The AppEUI should be unique to the owner of the device. The DevEUI should be a globally unique identifier for the device. The server should check the values and then re-calculate the MIC with the AppKey. If valid, the server may respond with a join-accept message within the receive windows of the Node. The Network server generates its own nonce value (AppNonce) and calculates the Node’s two new 128-bit keys: the app session key (AppSKey), and the network session key (NwkSKey). The join-accept reply includes an AppNonce, an end-device address (DevAddr) along with configuration data for RF delays (RxDelay) and channels to use (CFList). AMIC is generated, this data is sent back using the AppKey as an encryption key. In this way, the Node can use the AppKey to decrypt the data and then calculate AppSKey and NwkSKey key using the AppNonce.
Activation by Personalisation (ABP) differs from OTAA as the Nodes are shipped with the DevAddr and both session keys (NwkSKey and AppSKey), which should be unique to the Node. As the Nodes already have the information and keys they need, they can begin communicating with the Network Server without the need for join messages.
Protection of data sent over networks
Once a Node has joined a network, either through OTAA or ABP, all future messages will be encrypted and signed using a combination of NwkSKey and . As these keys are only known by the Network Server and specific Node, there should be no way for another Node, or a man in the middle attack to recover the clear-text data. Encryption of messages is performed using AES128 in Counter mode (CTR). If the packet’s FPort is set to 0 then the NwkSKey is used, otherwise, the AppSKey is used. An important feature of all messages in is that the counters for sent (FCntUp) and received (FCntDown) messages are maintained by the Node and Network Server and that these counters never repeat.
For encryption and decryption, a keystream is produced. The keystream includes the FCntUp or FCntDown values, which should mean that the keystream never repeats in the Node’s lifetime. The FRMPayload is then XOR’d with the keystream to encrypt or decrypt the data. Other data such as the FPort and FCNTUp are sent unencrypted.
The MAC Payload section of messages is signed to prevent manipulation of the cipher-text, or of other values such as the DevAddr, FCntUp or values.
Class B networks
Class B networks provide the functionality for Network Servers to send messages to Nodes without the need to receive a message from the Node first. Messages can be unicast (where a single Node is messaged), or multicast (where every Node is messaged with a single message). This functionality is achieved by having Nodes listen for messages in specific time windows.
For a Node to use class B functionality, it must synchronize its listening windows with the network. This is achieved through the Gateways producing a Beacon which includes its GPS coordinates and a time reference. These are produced simultaneously by all Gateways in the network.
Once a Node has received a Beacon, it can switch to class B and begin listening for incoming messages in specified listening windows. These windows are referred to as “ping slots”. The Node will send subsequent uplink messages with the Class B bit of the FCTRL field set to 1, letting the server see which Nodes are class B enabled.
The contents of the Beacon Payload sent by Gateways is shown below:
The NetID is a three-byte value used by the nodes to identify that it came from Gateways belonging to its network. It, therefore, needs to be unique to the particular network, otherwise, if two networks send beacons with the same NetID, there could be erroneous actions taken by the nodes.
Time is a four-byte value that represents the time in seconds since 00:00 1 January 1970.
The first CRC is either a one or two-byte value that is the CRC-16 of the NetID and Time values.
The GWSpecific value takes the following format:
This allows the Gateway to send a range of information. The following values are listed in the LoRaWAN specification:
For sending GPS coordinates (InfoDesc 0,1 and 2), the format is 6 bytes where the first three bytes is for latitude, and the latter three bytes for longitude. They are written as 24 bit signed values.
Class B Nodes may be expected to move and therefore require the Network Server to use different Gateways to contact them. This could be achieved through Nodes sending regular messages to uplink messages so that the Network Server can see through which Gateway these messages arrive and update its routing tables accordingly.
Alternatively, a more low power option is for the Node to listen for the regular Gateway Beacons and demodulate and inspect the beacon’s content. If the strongest beacon contains different coordinates, then the Node should update the Network Server by sending a message which the Network Server can inspect to see through which Gateway the message arrived.
Multicast messages allow the Network Server to send a single downlink message to multiple class B Nodes simultaneously. For this to be possible, all recipient Nodes must share the same encryption keys. For this reason, multicast messages are considered inherently less secure than unicast messages. They may therefore not include MAC commands.
The LoRaWAN specification does not describe the method for Nodes to attain these shared keys, but presumably, the application of each Node would be able to update the transceiver with the new NwkSkey and AppSkey keys. The specification does mention that shared key distribution could also be achieved during “node personalization”, but as the keys are normally based on nonces, and the keys themselves are never transferred, it is unclear how this would work in practice.
Attacks against systems
As can be seen, by the provisioning and messaging security, it should be possible to use solutions securely to protect against man in the middle attacks affecting the confidentiality and integrity of data. also provides ways for developers to securely add new Nodes of their choosing to their network. However other areas are left to the developers, which may lead to security vulnerabilities being introduced into particular Lora instances.
Weaknesses in Key Management
The use of symmetric encryption for security means that there must be at least two places where keys are stored. The Nodes and the Network Server.
For Nodes, they should only be storing keys that they require. It is likely given the range of hardware attacks available that an attacker could recover the AppKey, NwkSKey, and AppSKey from a Node using a side channel analysis. This attack uses the variations in power consumption or EM emissions from the transceiver during AES encryption to determine the key that must have been used. As an attacker with this key would be able to produce correctly signed and encrypted messages, the data coming from individual Nodes should, therefore, be assumed to be potentially untrustworthy.
The specification requires Nodes use keys that are unique to that particular device, and are random. If keys were to be shared cross-device, then it would be possible for an attacker to use a stolen key to intercept or spoof traffic from any other Node.
The Network Server and its supporting systems are ultimately responsible for the management of network and application keys. This means that the implementation of generating and storing keys could introduce vulnerabilities that undermine the security offered by .
Keys must be stored in a way that means although they are accessible to the Network Server for decrypting and verifying the signatures of messages, they are not open to being read or altered by unauthorized parties.
Another potential issue is how the Network Server performs its decryption and signature checking. Aside from introducing vulnerabilities in AES implementation, care should also be taken to perform checking the MIC signature before decryption of the message. If the FRMPayload is acted upon before the MIC is checked, then it would be possible for an attacker who had basic knowledge of the payload structure to manipulate the encrypted FRMPayload by flipping bits in the message. This could be performed without knowledge of the keys.
Weaknesses in Key Generation
The LoRaWAN specification explicitly warns developers about generating secure network and application keys:
Each device should have a unique set of NwkSKey and . Compromising the keys of one device shouldn‘t compromise the security of the communications of other devices.
The process to build those keys should be such that the keys cannot be derived in any way from publicly available information (like the Node address for example)
-LoRaWAN Specification V1.0
Key extraction from Node devices is probable given that they will likely be physically outside of controlled environments. It is important therefore that the theft of keys from one Node does not compromise other Nodes in the system.
One potential vulnerability is where Nodes use Activation-By-Personalisation (ABP) for joining, but use keys derived by the Node based on features such as the device address. If this could be worked out through reverse engineering of one Node, then all other communications to any Node would then be compromised.
Data handling
Devices that are produced by a company but used in remote locations are often considered as being trusted devices. In fact, their location puts them at risk of physical attack, ranging from theft through to tampering. Data received from any Node should not be considered safe, and therefore should be sanitized before use. An example of this may be where the Node is sending JSON data as shown in section 4.1.2. A mistake would be to assume that the JSON data is trustworthy as the encryption and signing was valid, and for example to place the results into a database, or use the data to form filenames without first sanitizing the data.
Node devices can be compromised in a number of ways. One example is if the Node used a Transceiver (such as the RN2483), which handles encoding, encrypting and transmitting the data. The microcontroller does not know the encryption keys used by the network. Instead, it would send data to the transceiver module which would encrypt, sign and transmit the data.
An attacker with physical access to one of these devices could, in theory, replace the microcontroller or use the UART pins of the transceiver to start sending their own messages on behalf of the Node. The attacks would be dependent on the particular system. For example, if the system is sending utility usage information then the attacker could falsify their usage data. Alternatively, if the data was being sent to include data that was being included in SQL statements by the server-side components, then SQL injection could be possible.
Gateway Compromise
Gateways are expected to have an IP connection to the network server. For many, this will be as simple as the gateway using a 3g dongle allowing Internet connectivity to the Network Server’s Internet-facing service. These devices may on the service provider, be directly accessible over the Internet. In this case, it is important that no services (such as management interfaces like SSH), are enabled, or are secured and can be updated when new security vulnerabilities are discovered.
For others, though it may be considered an advantage to route Gateway traffic through to a private network through, for example, a VPN tunnel. In this case, the physical security of the gateway should be considered as an attacker with physical access may well be able to compromise the device and gain network access using the gateway’s tunnel.
It would be important to harden the gateway so that tampering would lead to wiping of any access credentials and also to harden the network that the gateways connect to, to minimise risk following compromise.
Producing a Secure Solution
Prevention of attacks requires not only the proper implementation of the standards on all components but also the application of good security practices of all components that form the solution. For example, producing good random keys for Nodes could be undermined if they are to be stored on a server that can be accessed by hundreds of employees. A “ ” style attack emanating from an employee’s laptop that encrypts the App and Network keys used by the solution would render an entire system disabled.
Detailing security best practices for corporate IT networks is clearly a subject that is outside of the scope of this paper. However, it would be a mistake to think only about solutions in terms of their embedded and wireless components. Generally, the principle of least privilege should be applied. For example, if a Gateway does not need access to dozens of hosts through a VPN, then this should be reduced and then tested to prove that this is the case.
Another common mistake is to look at components in isolation. The customers may access their data through a web application which should be reviewed, but if other applications are running on the same host then their security would impact the solutions.
Prevention should also cover the reduction in damage from an attack. A good example of this is the standard’s own advice to make sure that NwkSKeys and AppSKeys are unique per device. Although this does not prevent the compromise of one device’s data, it does prevent the compromise affecting other Nodes.