Securing wireless protocols using LoRaWAN as an example
Hi, Habr.
I would like to once again talk about how the basic (read: minimally necessary) level of data security in the wireless networks used in IoT devices is provided, using the example of LoRaWAN.
Why choose LoRaWAN? First, because it is a well-described and well-developed standard, which should be guided as a reference if you are developing some kind of your own wireless protocol. Secondly, because it is a very native and typical solution for IoT; You can, of course, disassemble security in Wi-Fi or LTE, but for most developers it will be a useless analysis: it is unlikely that you will need to write your own implementation of Wi-Fi. Thirdly, it is low-power IoT-devices, in which developers save every byte, often turn out to be the most leaky - and here LoRaWAN gives a good idea, as well as saving bytes, and do not substitute attacks. Fourth, finally, because literally over the past few days, several of our clients have asked to tell them more about the data protection in LoRaWAN, and with this article I am killing two birds with one stone.
')
LoRaWAN message exchange between server and device
Although the message exchange scheme in LoRaWAN in the picture looks quite simple - this simplicity is deceptive: there is a lot of work behind it, and not a single pixel in it is superfluous. Now you understand why.
We will analyze with the example of LoRaWAN 1.0.2 and dance against possible threats - for a good developer should always think not about how his system is protected, but about how it can be broken. Otherwise, someone else will think about it.
So, what are the main threats to the wireless network - and how to protect against them?
The simplest threat is ordinary data interception: If radio waves propagate uncontrollably, then absolutely anyone can take a receiver tuned to the desired range and type of modulation, and listen to everything that you transmit.
The easiest way to protect against this is data encryption.
In LoRaWAN, user data is encrypted using the AES-128 algorithm with a key length of 128 bits (16 bytes, respectively). AES is a robust algorithm, while on minimally modern microcontrollers, even without a hardware encryption block, its use does not entail significant overhead: on a 48 MHz Cortex-M3, one 16-byte block is encrypted in about 100 µs from scratch.
In some cases, the attacker does not need to know what exactly you are transmitting there. For example, if you have a closed window sensor that transmits one thing, and an open window transmits something else, then you can write one thing without going into details of its content, stop the sensor, and so that the system does not suspect something is wrong from the sensor - to broadcast a previously recorded message.
In LoRaWAN, a counter is added to each packet . If a packet with a counter equal to or less than the previous one arrives on the network server, this packet is simply discarded. With two bytes per counter and typical for IoT-systems, the rate of message transmission will be enough for a very long time - for example, even a domestic weather station that transmits temperature every minute will overflow it only after a month and a half (LoRaWAN also allows a 4-byte counter).
There is, however, an obvious problem - after an overflow from the device, a packet with the number 0 will arrive, which, obviously, will be less than any other number, but at the same time, the network server must receive it correctly and start counting the packets again. In addition, the device can reset the counter by simply rebooting.
This is achieved in one of two ways:
In LoRaWAN, both schemes are used depending on how the device is activated — OTAA or ABP (we’ll talk about them below). For OTAA, the first option is used, and the device is also given new encryption keys - so that even an attacker who has spent a month and a half under your weather station will not be able to transfer a single previously recorded packet so that the system will accept it.
For ABP, in which there is no registration procedure in the network, the second option is used - however, if the counter overflow period noticeably exceeds the estimated service life of the device, and it can be disabled. In case of an accidental reboot after sending each packet, such an end device stores the value of the counter in non-volatile memory.
The second scheme, of course, is less secure, but in practice it is permissible - the attacker should not write any packet in it, but specifically zero. If you wish, you can make its contents different from all other packets — for example, transfer not data in it, but information about the type and settings of the device; then its interception and repetition will not give anything reasonable.
Counterfeit counter
However, the question immediately arises - what if the counter is forged? You can put it in the encrypted part of the packet, but then the actual amount of user data will be reduced by two bytes. You can encrypt not only user data, but then, firstly, you will have to adjust to the 16-byte block size, and secondly, the load on the network server will increase, which for any actions on the packet will have to be decrypted first (in the scheme, only user data is encrypted, if the packet is ignored for formal reasons, then you do not need to decrypt anything).
At the same time, it is obvious that it does not matter to us whether the attacker knows the package number or not — in the OTAA network, this knowledge will not help him at all, and in ABP he will wait for a very long time at the sea, i.e. the next arrival of the package with the number N-1.
Therefore, it is quite enough not to give him this number to change.
To do this, the entire package in LoRaWAN is signed by a cryptographic signature - AES-CMAC, this signature in the standard is called the MIC, Message Integrity Code. It checks that the entire package , including all the headers and data, has reached the server unchanged.
That is, by accepting another packet, we can quickly look at its counter (sender's address, etc), and if it’s ours and is correct, then check the signature (spending additional resources on it), and if the signature is also correct, decrypt the data and send them further.
Continuous data tracking
Unfortunately for us, it is not enough not to let the attacker understand the data or at least repeat it - in some cases it will be enough for him to understand that they do not change. A textbook example is home water meters: if you just want to know if the owners are at home, you don’t really care how many liters there are, it’s important for you to know if this value increases .
It is obvious that data encryption is a reversible procedure (they can be decrypted), which means that the same data encrypted with the same key always looks the same. Receiving packages from a water meter, whose readings do not change, you can, without decoding the package , understand that they do not change.
To combat this is quite simple - either the data or the key must change. So that the data can be changed, you can add salt to it - a few random bytes that are simply thrown away after decryption. Unfortunately, 16 bytes of a packet is so sparse, so in general we don’t want to spend 2-4 bytes of them on actual garbage.
LoRaWAN uses a trickier scheme . Remember that we have a package counter? So, it is this counter plus information about the device and the packet (the short address of the device in the LoRaWAN network, the direction of data transmission, the counter of 16-byte segments) are encrypted using the AES algorithm, and the XOR result with the user data packet.
As a result, the payload bytes are not wasted, and each message looks different, regardless of whether the load has changed or not.
PS There is another option, a little more simple: use the message counter as the last N bytes of the key. In this case, the key will be new every time, but because the server knows the value of the message counter (it is in the unencrypted part of the message), then it can recover it. Minus - if your package consists of several 16-byte blocks, and they contain the same data, then after encryption they will remain the same.
The attacker learned the encryption key
Quite a realistic situation - IoT is characterized by the use of a large number of devices, over which outsiders' access to which you generally may not have enough reliable control (and if you are also a network operator, then your customers are, by definition, for each other - outsiders).
Therefore, if all your devices have the same encryption key, the owner of any of them can listen to the traffic of any other device (generally speaking, if he has the ability to modify the firmware, for such an operation, you can not even explicitly know the key - let The new firmware takes it from the same place where the old one came from, and just gives us other people's data).
LoRaWAN implements two key usage schemes that are specific to each device:
In total, at least two keys are used — AppSKey, which encrypts user data, and NwkSKey, which signs the message.
Obviously, the scheme with OTAA is more convenient and reliable - the keys can change with the frequency with which they want, they are guaranteed to be unique and are not known to anyone except the network server. In ABP, the keys never change, the uniqueness depends on the integrity of the device manufacturer (for example, we generate these keys from the unique microcontroller ID, so the probability of their coincidence on two devices is insignificant), and they need to be stored somewhere explicitly so that when the device is connected to the network to register them on the server.
However, the procedure itself for obtaining keys in OTAA is a separate story, which, being carelessly implemented, can generate several types of attacks.
Obviously, when registering on the network each time new keys are generated, they must be synchronized between the device and the server, which means that the attacker can intercept them, thus bringing down all the protection.
Therefore , LoRaWAN devices have a third key - AppKey, tightly wired into the device and used in one single moment: when registering with the network. It uses the exchange of session keys between the device and the server.
Ideally, an AppKey should be unique for each device, but in many cases it is allowed to use the same AppKey - since it is needed only once, this can be considered valid.
AppKey before connecting the device is recorded in its settings on the network server.
So, the device generates a request for registration (JoinRequest), without encrypting it (it does not contain particularly sensitive information), but by signing it with the AppKey key. The network server, having received this packet and checking the sender's address (whether it is our device at all) and then the signature, responds with the JoinAccept packet, in which it transmits the network settings — well, it actually confirms the registration.
Where do the AppSKey and NwkSKey keys come from?
This is the result of AES-128 encryption with the AppKey key combination of the random AppNonce number sent by the server, the key number (1 or 2), the network ID, and another DevNonce random number:
Since both the device and the server know all these parameters after exchanging registration packets, they will generate the same keys. Thus, at no time will any keys be transmitted by radio on their own, but both the device and the server will receive unique encryption keys and packet signatures.
But that's not all!
Yes, a network registration event is usually infrequent, but imagine that the attacker was able to initiate and intercept it.
Then, if he simply sends the JoinRequest packet written by him, without changing anything in it, the server will respond to it with the JoinAccept package, generating new keys. After that, the attacked device will simply stop communicating with the server, because the JoinRequest has not initiated it and does not see any reason to update the keys. That is, the same repeat attack - but already on the registration procedure in the network.
The attacker will not be able to falsify the data, because for this you need to know the keys, and to get them you need to know AppKey, which he does not know. But knock the device out of the network - can.
To avoid this, when registering, the device sends a random number DevNonce to the server (see, it is higher in the packages). Besides the fact that keys are generated on its base, it serves another purpose - the LoRaWAN server stores the DevNonce archive . If from the device came a repeated registration request with DevNonce already used, the server will simply ignore it.
In turn, the device is obliged to generate a new DevNonce at each registration (that is, the scheme with retransmitting conventional packets - “did not receive an answer, spat out the same packet into the radio a second time” - does not work here, JoinRequest is created again every time).
Although the text came out a lot, and the pictures were few, even this is not a complete pattern of possible attacks on the radio alone (questions about why, for example, the device has to encrypt the stored settings, and with an individual key for each device, we left for brackets, this is not about the radio). For example, in LoRaWAN 1.1, protection schemes have become even more complicated.
Nevertheless, this is a gentleman's recruitment of any radio protocol claiming for minimally worthy information protection and at the same time designed to work on low-power devices in low-speed networks. Moreover, this is a very good example of the implementation of not just a secure protocol, but a protocol written for low-power devices and minimizing consumption of airtime and computing power wherever possible without significant damage to security.
And if you are designing your own protocol for IoT, then perfectly specified LoRaWAN in combination with an understanding of the basic methods of conducting attacks provides an excellent opportunity to learn how to organize this protection correctly.
I would like to once again talk about how the basic (read: minimally necessary) level of data security in the wireless networks used in IoT devices is provided, using the example of LoRaWAN.
Why choose LoRaWAN? First, because it is a well-described and well-developed standard, which should be guided as a reference if you are developing some kind of your own wireless protocol. Secondly, because it is a very native and typical solution for IoT; You can, of course, disassemble security in Wi-Fi or LTE, but for most developers it will be a useless analysis: it is unlikely that you will need to write your own implementation of Wi-Fi. Thirdly, it is low-power IoT-devices, in which developers save every byte, often turn out to be the most leaky - and here LoRaWAN gives a good idea, as well as saving bytes, and do not substitute attacks. Fourth, finally, because literally over the past few days, several of our clients have asked to tell them more about the data protection in LoRaWAN, and with this article I am killing two birds with one stone.
')
LoRaWAN message exchange between server and device
Although the message exchange scheme in LoRaWAN in the picture looks quite simple - this simplicity is deceptive: there is a lot of work behind it, and not a single pixel in it is superfluous. Now you understand why.
We will analyze with the example of LoRaWAN 1.0.2 and dance against possible threats - for a good developer should always think not about how his system is protected, but about how it can be broken. Otherwise, someone else will think about it.
So, what are the main threats to the wireless network - and how to protect against them?
Interception of user data
The simplest threat is ordinary data interception: If radio waves propagate uncontrollably, then absolutely anyone can take a receiver tuned to the desired range and type of modulation, and listen to everything that you transmit.
The easiest way to protect against this is data encryption.
In LoRaWAN, user data is encrypted using the AES-128 algorithm with a key length of 128 bits (16 bytes, respectively). AES is a robust algorithm, while on minimally modern microcontrollers, even without a hardware encryption block, its use does not entail significant overhead: on a 48 MHz Cortex-M3, one 16-byte block is encrypted in about 100 µs from scratch.
Repeat data
In some cases, the attacker does not need to know what exactly you are transmitting there. For example, if you have a closed window sensor that transmits one thing, and an open window transmits something else, then you can write one thing without going into details of its content, stop the sensor, and so that the system does not suspect something is wrong from the sensor - to broadcast a previously recorded message.
In LoRaWAN, a counter is added to each packet . If a packet with a counter equal to or less than the previous one arrives on the network server, this packet is simply discarded. With two bytes per counter and typical for IoT-systems, the rate of message transmission will be enough for a very long time - for example, even a domestic weather station that transmits temperature every minute will overflow it only after a month and a half (LoRaWAN also allows a 4-byte counter).
There is, however, an obvious problem - after an overflow from the device, a packet with the number 0 will arrive, which, obviously, will be less than any other number, but at the same time, the network server must receive it correctly and start counting the packets again. In addition, the device can reset the counter by simply rebooting.
This is achieved in one of two ways:
- before sending such a package, the device must go through the registration procedure in the network (in the LoRaWAN network, this procedure is called Join)
- the server allows the arrival of the next packet with the number 0, while the countdown begins anew
In LoRaWAN, both schemes are used depending on how the device is activated — OTAA or ABP (we’ll talk about them below). For OTAA, the first option is used, and the device is also given new encryption keys - so that even an attacker who has spent a month and a half under your weather station will not be able to transfer a single previously recorded packet so that the system will accept it.
For ABP, in which there is no registration procedure in the network, the second option is used - however, if the counter overflow period noticeably exceeds the estimated service life of the device, and it can be disabled. In case of an accidental reboot after sending each packet, such an end device stores the value of the counter in non-volatile memory.
The second scheme, of course, is less secure, but in practice it is permissible - the attacker should not write any packet in it, but specifically zero. If you wish, you can make its contents different from all other packets — for example, transfer not data in it, but information about the type and settings of the device; then its interception and repetition will not give anything reasonable.
Counterfeit counter
However, the question immediately arises - what if the counter is forged? You can put it in the encrypted part of the packet, but then the actual amount of user data will be reduced by two bytes. You can encrypt not only user data, but then, firstly, you will have to adjust to the 16-byte block size, and secondly, the load on the network server will increase, which for any actions on the packet will have to be decrypted first (in the scheme, only user data is encrypted, if the packet is ignored for formal reasons, then you do not need to decrypt anything).
At the same time, it is obvious that it does not matter to us whether the attacker knows the package number or not — in the OTAA network, this knowledge will not help him at all, and in ABP he will wait for a very long time at the sea, i.e. the next arrival of the package with the number N-1.
Therefore, it is quite enough not to give him this number to change.
To do this, the entire package in LoRaWAN is signed by a cryptographic signature - AES-CMAC, this signature in the standard is called the MIC, Message Integrity Code. It checks that the entire package , including all the headers and data, has reached the server unchanged.
That is, by accepting another packet, we can quickly look at its counter (sender's address, etc), and if it’s ours and is correct, then check the signature (spending additional resources on it), and if the signature is also correct, decrypt the data and send them further.
Continuous data tracking
Unfortunately for us, it is not enough not to let the attacker understand the data or at least repeat it - in some cases it will be enough for him to understand that they do not change. A textbook example is home water meters: if you just want to know if the owners are at home, you don’t really care how many liters there are, it’s important for you to know if this value increases .
It is obvious that data encryption is a reversible procedure (they can be decrypted), which means that the same data encrypted with the same key always looks the same. Receiving packages from a water meter, whose readings do not change, you can, without decoding the package , understand that they do not change.
To combat this is quite simple - either the data or the key must change. So that the data can be changed, you can add salt to it - a few random bytes that are simply thrown away after decryption. Unfortunately, 16 bytes of a packet is so sparse, so in general we don’t want to spend 2-4 bytes of them on actual garbage.
LoRaWAN uses a trickier scheme . Remember that we have a package counter? So, it is this counter plus information about the device and the packet (the short address of the device in the LoRaWAN network, the direction of data transmission, the counter of 16-byte segments) are encrypted using the AES algorithm, and the XOR result with the user data packet.
As a result, the payload bytes are not wasted, and each message looks different, regardless of whether the load has changed or not.
PS There is another option, a little more simple: use the message counter as the last N bytes of the key. In this case, the key will be new every time, but because the server knows the value of the message counter (it is in the unencrypted part of the message), then it can recover it. Minus - if your package consists of several 16-byte blocks, and they contain the same data, then after encryption they will remain the same.
The attacker learned the encryption key
Quite a realistic situation - IoT is characterized by the use of a large number of devices, over which outsiders' access to which you generally may not have enough reliable control (and if you are also a network operator, then your customers are, by definition, for each other - outsiders).
Therefore, if all your devices have the same encryption key, the owner of any of them can listen to the traffic of any other device (generally speaking, if he has the ability to modify the firmware, for such an operation, you can not even explicitly know the key - let The new firmware takes it from the same place where the old one came from, and just gives us other people's data).
LoRaWAN implements two key usage schemes that are specific to each device:
- Over The Air Activation, OTAA - the keys are generated by the network server every time the device is registered in it
- Activation By Personalization - the keys are set by the manufacturer and stored on the device, never changing
In total, at least two keys are used — AppSKey, which encrypts user data, and NwkSKey, which signs the message.
Obviously, the scheme with OTAA is more convenient and reliable - the keys can change with the frequency with which they want, they are guaranteed to be unique and are not known to anyone except the network server. In ABP, the keys never change, the uniqueness depends on the integrity of the device manufacturer (for example, we generate these keys from the unique microcontroller ID, so the probability of their coincidence on two devices is insignificant), and they need to be stored somewhere explicitly so that when the device is connected to the network to register them on the server.
However, the procedure itself for obtaining keys in OTAA is a separate story, which, being carelessly implemented, can generate several types of attacks.
Capturing generated keys
Obviously, when registering on the network each time new keys are generated, they must be synchronized between the device and the server, which means that the attacker can intercept them, thus bringing down all the protection.
Therefore , LoRaWAN devices have a third key - AppKey, tightly wired into the device and used in one single moment: when registering with the network. It uses the exchange of session keys between the device and the server.
Ideally, an AppKey should be unique for each device, but in many cases it is allowed to use the same AppKey - since it is needed only once, this can be considered valid.
AppKey before connecting the device is recorded in its settings on the network server.
So, the device generates a request for registration (JoinRequest), without encrypting it (it does not contain particularly sensitive information), but by signing it with the AppKey key. The network server, having received this packet and checking the sender's address (whether it is our device at all) and then the signature, responds with the JoinAccept packet, in which it transmits the network settings — well, it actually confirms the registration.
Where do the AppSKey and NwkSKey keys come from?
This is the result of AES-128 encryption with the AppKey key combination of the random AppNonce number sent by the server, the key number (1 or 2), the network ID, and another DevNonce random number:
NwkSKey = aes128_encrypt(AppKey, 0x01 | AppNonce | NetID | DevNonce) AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce) Since both the device and the server know all these parameters after exchanging registration packets, they will generate the same keys. Thus, at no time will any keys be transmitted by radio on their own, but both the device and the server will receive unique encryption keys and packet signatures.
Interception of data flow to itself
But that's not all!
Yes, a network registration event is usually infrequent, but imagine that the attacker was able to initiate and intercept it.
Then, if he simply sends the JoinRequest packet written by him, without changing anything in it, the server will respond to it with the JoinAccept package, generating new keys. After that, the attacked device will simply stop communicating with the server, because the JoinRequest has not initiated it and does not see any reason to update the keys. That is, the same repeat attack - but already on the registration procedure in the network.
The attacker will not be able to falsify the data, because for this you need to know the keys, and to get them you need to know AppKey, which he does not know. But knock the device out of the network - can.
To avoid this, when registering, the device sends a random number DevNonce to the server (see, it is higher in the packages). Besides the fact that keys are generated on its base, it serves another purpose - the LoRaWAN server stores the DevNonce archive . If from the device came a repeated registration request with DevNonce already used, the server will simply ignore it.
In turn, the device is obliged to generate a new DevNonce at each registration (that is, the scheme with retransmitting conventional packets - “did not receive an answer, spat out the same packet into the radio a second time” - does not work here, JoinRequest is created again every time).
Conclusion
Although the text came out a lot, and the pictures were few, even this is not a complete pattern of possible attacks on the radio alone (questions about why, for example, the device has to encrypt the stored settings, and with an individual key for each device, we left for brackets, this is not about the radio). For example, in LoRaWAN 1.1, protection schemes have become even more complicated.
Nevertheless, this is a gentleman's recruitment of any radio protocol claiming for minimally worthy information protection and at the same time designed to work on low-power devices in low-speed networks. Moreover, this is a very good example of the implementation of not just a secure protocol, but a protocol written for low-power devices and minimizing consumption of airtime and computing power wherever possible without significant damage to security.
And if you are designing your own protocol for IoT, then perfectly specified LoRaWAN in combination with an understanding of the basic methods of conducting attacks provides an excellent opportunity to learn how to organize this protection correctly.
Source: https://habr.com/ru/post/458394/
All Articles