The importance of cyber-security shielding in LoRaWAN networks: Part II

The IRIS Sentinel team shares the second article addressing the cybersecurity of IoT devices in LoRaWAN networks.

In the first article of this series we discussed what IoT ecosystems and digital transformation consist of, as well as the application of IoT in Smart Cities. Finally, we took a look at the characteristics and devices that make up one of the most popular LPWAN networks in the world, LoRaWAN.

In this second article we are going to dive into configuration and connection aspects of LoRaWAN devices. We will talk about what information is contained in the LoRaWAN messages that are exchanged between devices, the types of nodes according to their configuration, and we will explain how they register on the network to send data.

We’ll begin by defining the term ‘LoRaWAN frame’ as the set of data that LoRaWAN devices send and receive. The packets are made up of useful information from the sensors (temperature, pressure, etc.), as well as the data that is necessary to direct the information from a source to a destination (addresses, identifiers, etc.).

The following image represents a simple diagram of a LoRaWAN frame which shows how part of the data is related to pressure, another part to temperature, another to level and another to water level. This is what is known as payload or useful information.

When configuring the devices before operation, a connection mode must first be established. There are two modes: OTAA mode (Over-The-Air-Activation) where devices perform a network join procedure and negotiate security keys, and ABP mode (Activation By Personalization) where devices bypass the join procedure with the network because the session has been established ahead of time by setting the keys manually. In this article we are going to focus on devices with OTAA configuration.

OTAA nodes have to exchange a couple of messages with the Network Server to connect to the network. The nodes transmit their intention to connect to the network through a “JoinRequest” message. The Network Server will respond with another “JoinAccept” message.

During the exchange of these messages, the node and the Network Server take the opportunity to exchange a series of unique keys with the intention of establishing reliable communication. These keys are known as AppSKey and NwkSKey. In short, until the session is established, the nodes cannot transmit the information from their sensors.

These keys are generated from one of the main identifiers that travels within the frames, called APPKey. The greatest risk to these types of networks and devices is visibility or exposure of APPKeys, as the encryption lies in this identifier and can be used to recover the data that has been encrypted.

In the next article of this series we will look at the risks involved in the use of these keys. We will talk about a specific attack scenario in which nodes are added to the network by supplanting legitimate nodes, and we will reflect on the consequences that these attacks can have in Smart environments.