I am continuing with the fourth post in my series LoRaWAN vs 5G. As I am invited to speak about 5G at a LoRaWAN event (ThingsConference 22nd of September 2022), I found it appropriate to dig into the aspects of LoRaWAN vs the current 5G standards for LPWAN. In the last post, we compared coverage. This post will focus on security, an extensive area. The first three posts were about the LoRa Alliance infographic; funny enough, this topic was not in the comparison, even though I think it should be one of the most important.
Secure starts with the frequencies
5G is based on a licensed spectrum, so the only main problem with the wireless channel from a radio perspective for 5G is not other users but possible jamming of the band. LPWAN networks are characterised by covering a large area. You may have several base stations receiving the messages; in such a situation, jamming might prove difficult. However, the communication bandwidth is small for LPWAN. LoRaWAN uses 125/250/500kHz and NB-IoT 180 kHz. The jammer hardware need not be complicated and does not require much power to put the signal out. Let’s continue with the more problematic question, the free LoRaWAN frequencies.
LoRaWAN is based on six frequencies in Europe. These are in the 868.0-868.6 MHz range. They are intended as: “Radio transmitters for unspecified application area”. They allow a transmit cycle: < 1 % and 25 mW output power. The definition of transmit-cycle is the average transmission time over a given period of time (maximum one hour) expressed as a percentage of this period. Theoretically, if you set up a network of 100 transmitters sharing the time between them on a free channel, you have blocked the band. And this does not necessarily mean that you are dealing with another LoRaWAN transmitter. It could be any application put on the market tomorrow that wants to use the band. There are no guarantees, and there's no one you can call and file a complaint with if the channel is blocked. However LoRaWAN uses several bands so theoretically blocking all of the all the time is in theory possible, in practice, of course, hard. With LoRaWAN, you have a long-range; that's one of the points. The downside is that it can't be densified similarly to a mobile network, so it's harder to scale. Once the mobile network operators build coverage, you need to densify. This is done by using additional frequencybands that send the signal shorter distances. There is no plan B here with LoRaWAN. When the spectrum is full, with LoRaWAN or other solutions, it's full. As a defence to LoRaWAN, the transmit time is short and less frequent. And one of the strengths of LoRaWAN is frequency hopping. LoRaWAN is constantly changing the frequency. This makes the system somewhat robust to interference, but it is not using a licensed spectrum. If another user or standard decides to use the channel, it limits the possibility of transmitting the message. The traffic can't be moved to another frequency as plan B. A free frequency, free for all, can never be guaranteed for 10-20 years.
Decrypting the messages
So now, let us look at the security aspects. As pointed out in the article Security Issues in Internet of Things: Vulnerability analysis of LoRaWAN, Sigfox and NB-IoT by Florian Laurentiu Coman, Krzysztof Mateusz Malarski, Martin Nordal Petersen and Sarah Ruepp of the Technical University of Denmark it is possible to MIC Bruteforce LoRaWAN to “hack the system”. The team means that by taking advantage of a gateway’s ability to simultaneously demodulate data received on multiple channels, a hacker can spread an attack on multiple channels using the different spreading factors SF 7, 8, 9, 10, 11, 12 simultaneously. “If we assume the same sending rate of 10 packets per second (although different SFs will use different transmission speeds), 15 channels, 7 orthogonal modulation schemes (6 LoRa SFs and 1 FSK), and 5 gateways, the brute-forcing will take less than 10 days.” This scenario is highly unlikely but possible.
The team has a fascinating report, and I recommend it. Their conclusion is that “LoRaWAN and NB-IoT offer sufficient security guarantees, but they need to be properly enforced. For LoRaWAN, we show that packets could be forged in some situations[…]. Thus, LoRaWAN applications must be “garbage-proof” and […] disallow the communication from the devices sending invalid packets to prevent DoS. For NB-IoT, before deploying critical applications, the user should ensure that their operator enforces best security practices on the network.” One step is using a private APN to get the traffic off the public internet. Another suggestion is to use encryption between your server and the operator’s server.
Old LoRaWAN versions are more vulnerable
In the first version, LoRaWAN 1.0, there was a security issue. This has been corrected by the new version v1.1 introduced in 2017. But to what point v1.1 is used today, I do not know. In the report Demystifying Security of LoRaWAN v1.1 by Ismail Butun, KTH Royal Institute of Technology, Nuno Pereira, Polytechnic Institute of Porto and Mikael Gidlund, Mid Sweden University. The researchers conclude:
“In a nutshell, it has been shown that v1.0 suffers from several weaknesses, which may allow adversaries to exploit security breaches in the network. These security breaches impact the network availability, data integrity, and data confidentiality. These attacks do not lean on potential implementation or hardware bugs, being instead based on weaknesses of the protocol. ”
“Although it has improved security properties compared to the previous version, LoRaWAN v1.1 still has some security risks, some introduced by the new security framework, others by not being covered by the specification, which warrants attention from developers.”
OTA updates
All devices will sooner or later need to be updated. Devices that don’t have firmware validation when downloading new firmware or those that lack mechanisms for resetting to secure version security are what we would categorize as IoT devices to opt-out of. Only select devices that accept updates that are digitally signed. Choose devices that have mechanisms to update the firmware securely remotely. Choose only devices that do not lock up if the firmware update fails. If you are doing a large rollout, it is costly to update devices if they need to be updated for security reasons. Perhaps more expensive than replacing the battery.
One of the main things we think speaks in favour of CAT-M1 in front of NB-IoT is that it allows for faster OTA updates and firmware updates so you can continue to update your IoT solution for many years. Compared to LoRaWAN, 5G is far superior here; LoRaWAN can handle FOTA, but it can take weeks to get an update across to a device.
Conclusion
Deutsche Telekom IoT has made a comparison and analysis of Security Aspects of LoRaWAN and NB-IoT. They conclude that while both LPWA technologies provide robust security, NB-IoT outperforms LoRaWAN in a highly critical aspect: the secure storage of the cryptographic keys. Using devices without a secure element significantly reduces the effectiveness of end-to-end encryption.
NB-IoT devices have a SIM card, a secure element that LoRaWAN devices lack. The SIM card makes the extraction of cryptographic data much more difficult. A possible vulnerability of NB-IoT is that many devices have modules that can roam to 2G if no NB-IoT network is available. GSM is much more vulnerable to attacks. So it is always advisable to implement additional end-to-end encryption, especially when roaming on third-party networks.
So here is the thing. LoRaWAN has an edge regarding price, there are many devices on the market and an extensive ecosystem, but the devices are cheap. As a result, the most critical weakness of LoRaWAN is the end devices. In many cases, for cost reasons, they usually have no secure element, not a secure component in the devices that stores cryptographic information like the encryption keys in a secure way. An attacker could extract the secret keys or flash the device with compromised firmware.
In my next post we will focus on capacity and roaming.