Notes IoT provider. Activation and security in LoraWAN

Hello, dear lovers of the Internet of Things. Continuing the notes of the IoT provider.

Today it's time to talk about security in LoRaWAN. There are a lot of rumors and legends. We will try to figure out how it works and what the risks are.

In general, to move on to the topic of security, you will have to do a little introductory and tell about the initial initialization of the radio module in the network. This process in LoRaWAN is called activation.

For brevity, I give below a list of terms we need. If you get a little confused - you can come back here and check. For certain it is necessary to return, because abbreviations of many terms are very similar. In addition, in this description I will give an analogy, so that you can understand something about which one or another term can be compared. It is not always possible to choose exact analogies, therefore I ask you not to judge this column too strictly.

So, activation in LoRaWAN can be done by air (OTAA), or by presetting (ABP).

OTAA (Over-the-Air-Activation)

In the case of activation by air, we have to set three parameters on the radio module. Its unique identifier (DevEUI), server identifier (AppEUI) and server key (AppKey).

On the server side, the radio module ID, server ID, and key must also be registered. Those. the server must initially know the device that will try to join it. If we know the identifiers and keys of the server, but our DevEUI is not registered in its database, then the connection will fail.

When initially switched on, the radio module sends the join_request packet on one of the three pre-defined join frequencies. With this package, he asks if there is a network nearby that “recognizes” him. Below is the composition of the join_request package. As you can see, it contains the very DevEUI and AppEUI, as well as DevNonce.

DevNonce is a random variable. The server keeps it for some time in memory, and if join_request comes with the same DevNonce as one of the previous ones, the server will ignore this request. This is done to protect against replay attacks, when an attacker can record an activation request, and then repeat it from his device. By the way, not all IoT standards can boast protection against this attack.

The AppKey is not directly used in this message, but through it the MIC checksum at the end of the frame is considered.
We will need this key a little further, in the reply message of the join_accept server.

Join_request is transmitted in unencrypted form.

Join_accept will come in if the server knows AppEUI and DevEUI, and there is also no match in the DevNonce field and there are no problems with the MIC. Otherwise, no response will follow. If all checks are passed, the server generates a join_accept response message. Its composition is shown in the picture below.

In fact, two session keys are generated - a network server (NwkSKey) and an application server (AppSKey). These keys, along with other information, are encrypted by AppKey and sent to the radio module. Further, all message exchange occurs with double encryption of session keys (with the exception of packets with MAC commands, their application server key is not encrypted). NwkSKey does not take part in encrypting packets only with data (without commands), but through it checksum is considered.
NwkSkey and AppSKey are unique to each individual radio module.

Two keys are used to further protect information. Each time a packet from a radio module comes into our system, it will be partially encrypted for the network server and partially for the application server. Those. the network server will be able to decrypt only those messages that are addressed to it (various service messages). The application server will see only the useful component of the packets (the data itself being forwarded). It is necessary for the fact that the network server with a probability of 99 percent will be at the provider. But the application server may well be located at the client. Double encryption makes it difficult for the provider to know the contents of the packet.

In addition to the two keys, the join_accept for OTAA has another important thing - an extended list of frequencies (CFList). Let me remind you that initially the radio module knows only three frequencies at which it can operate. After activation, additional frequencies are assigned to it for contact.

This is very convenient if you do not know exactly which network the device will work on. It can be agreed that in all networks, 3 frequencies (+ RX2) will always coincide, and the other five will be at the discretion of the provider.

Also, for the future, to work with a large number of devices, CFList can be used for clustering.

This is when you divide the network into clusters and there is frequency planning within the clusters. Suppose our radio module knows three frequencies F1, F2 and F3. It activates at one of the frequencies and if it is in cluster1, then it receives an additional table of frequencies in the form of F4-1, F5-1 and F6-1. For cluster 2, it will receive completely different F4-2, F5-2, F6-2. At the same time, we can configure all the radio modules in the same way and don’t really think about which one will fit into which cluster. And in the neighboring clusters the probability of collisions will sharply decrease.

ABP (Activation by Personalization)

Simplified procedure when session keys are immediately sewn into the radio module and initially registered from the server side. Conveniently, it is not necessary to activate, the radio module is immediately ready for operation. No more convenient because security in this case is so-so. In addition, you can not pull up the frequency from the server. Cases of real use never met. We will not consider it and all of the below is about OTAA.

And what about security?

So, in fact, we have the main burden of encryption on the session keys of the network server and application server.

Consider them a little more carefully.

The main complaint of critics of the LoRaWAN standard is that when a device is activated on the network, we have two keys, which can then remain unchanged for months. More precisely, they may not change for years until the device is re-activated. Under normal conditions, we activated the radio module and forgot it, so that the key lifetime of three to four years is a very real prospect. Actually, from the installation to the care of the zero battery.
How reliable are our keys?

The specification states that they are consistent with the cryptic RFC4493.
What it is? This is an encryption algorithm, better known as AES-CMAC.

Let's not get into the wilds of cryptography and confine ourselves to a common understanding of the picture. It is presented in the figure below.

The principle of AES-CMAC is something like this: the message to be encrypted is broken into 128-bit blocks. Each block is encrypted separately with an AES key. Moreover, when encrypting the second block, in addition to the key, the result of the first encryption is used. And when encrypting the third - the result of the second and (indirectly) the first. Such a chain of complications.

How reliable is this principle?

Very reliable. The algorithm was released more than ten years ago. Since then, many different attacks have been conducted on him, and in the end, they proved in theory that it could be hacked. The problem is that a large sample of packages, several thousand, will be needed for hacking. Then there is a chance to understand what is inside the encrypted blocks.

Will an attacker with the necessary knowledge be able to get this sample if we are talking about intercepting LoRaWAN packets? Let's estimate. Let the packages go once an hour. In a month, 720 packages will go away from the radio module. Not much.

For a real threat, we will need a sooo patient patient who will write packages for months. And it’s not a fact that he can still break the algorithm and get the cherished keys. Do not forget that such patience must be shown in relation to each radio module separately. And remember that the transfer of packets once an hour - it is very often. In practice, the intervals are much longer - six hours, or even a day.

But even this ghostly possibility is now closed after the release of specification 1.1, where the re-activation and join server commands are implemented. About this specification some more talk. For now, I recall my thought from the previous article: when the standard is open and it has a community, all its holes are visible. During the upgrade, developers know exactly what to look at first.

As a result, we find that the security threat is rather illusory. Somewhere in the deep theory, hacking can be done, but in practice it is practically unreal. Now multiply by the value of the information received. Will our attacker for months to write packages to learn the meter readings? Unlikely.

LoRaWAN answers that reasonable price-performance ratio. We understand that protection can be enhanced. But this is the computing power of the end, it is an additional load on the battery, it is possible to increase the size of packets or reduce the payload.

For me, more than that for telemetry tasks.

In the comments, I will be glad to hear both my opponents and supporters. Remember that the topic of security always requires discussion and should never rest on the opinion of one person.