LoRaWAN security vulnerabilities exposed

Certain documents from the LoRa Consortium show that LoRaWAN uses the AES 128 algorithm to encrypt messages. However, according to French IT security specialist Renaud Lifchitz, in reality the AES 128 algorithm is only used to generate a stream of keys, a so-called “keystream”, that is simply XOR-ed with the data. The result is non-optimal encryption that can be deciphered by someone willing enough.

XOR-ing data and keys creates encrypted messages with the same length as the key, a useful hint for hackers. Furthermore, the keystream is reinitialised at session start and may be identical to a previously used keystream and allows in that case resending old messages. XOR-ing two messages that were encrypted with the same keystream partly decodes the two messages. Finally, when the contents of a message are known, it is possible to discover the keystream, allowing deciphering future messages.

Another weakness lies in the identification and connection process. Every gateway sends his ID to the server periodically. If the ID is known, information which apparently is not too difficult to obtain, the gateway can be “overruled” by a malicious gateway that simply sends this ID at a higher rate than the real one.

The main weakness remains however the hardware that communicates over LoRa. Often these are simple systems with unprotected memory, debug ports and naïve AES implementations that can easily be compromised. As always a system is only as strong as its weakest link.

BTW, LoRa’s competitor Sigfox isn’t much more secure.

Add a rating to this article

★ ★ ★ ★ ★

Discussion (3 comments)

Tamas Holman 8 years ago

These are assumptions. All components of LoRaWAN are commercially available. Purchase a low cost LoRaWAN system and break their keys. Then share with us your experiences!

0 Comment(s)

Alper Yegin 8 years ago

Just to give a background on LoRaWAN: It is the MAC layer over LoRa radio defined by the LoRa Alliance, which provides mutual authentication and authorization between an end-device and the network before the end-device joins the network. Subsequently, over-the-air traffic including the MAC commands and the application payload are origin authenticated, integrity and replay protected, and encrypted. Furthermore, application payload is end-to-end encrypted between the end-device and the application server. All of these procedures rely on AES-128 cryptographic keys and algorithms.

Regarding the security threats mentioned in the article:

- Yes, LoRaWAN doesn't define padding at the LAC layer to avoid traffic analysis. It is unclear how one could effectively avoid traffic analysis for many of the applications that use IoT radios. Padding alone may not be sufficient and superfluous packets may also be needed. On the other hand, encrypted text being the same size as the plain text is a common feature of all CCM encryption schemes. Given the packet size constraints of the IoT networks, a mode of operation that avoids any additional byte overhead is provided as the default one by the MAC layer. Applications that require additional level of privacy and that can afford extra byte overhead are encouraged to use additional padding at the application layer to hide the length of plain text. After all, only the applications are aware of their real traffic pattern that needs to be hidden, hence they are at a better position than the MAC layer to know the best way to hide that pattern.

- The OTAA (Over-the-Air Activation), the mode recommended for higher security, ensures the same keystream is never used -- through rekeying and using unique counters. It leaves no room for XORing two messages that are encrypted using the same keystream.

- General issues regarding device hardware security and network deployment are well-recognized in the land of IoT. Note though these implementation and deployment issues are not stemming from the use of LoRaWAN technology, they would be equally applicable to any other radio technology being used on the same platforms. LoRaWAN is compatible with using security measures to address such issues, such as Secure Elements, Firewalls, VPNs, and makes such recommendations whenever possible. But at the end of the day, we (the technology designers, including LoRaWAN and others) are at the mercy of the manufacturers and network operators to do the right thing by not leaving security gaps in their "implementations" and "deployments."

Gabor Borjan 7 years ago

This is just the tip of the iceberg. Yes, the information in the article is correct, and yes, it is a serious vulnerability. The comment about breaking the keys is confusing, as you don't have to break the keys. You need much less skills to read any key: simply connect 3 wires (tx rx gnd) to the LoRa module and read the keys easily, using the standard commands, published in the documentation. You don't even need an undocumented feature of the module.

The commercial availability of a component as a 'proof of it's security'? Nonsense!

We compiled a short memo of the vulnerabilities that we've identified using these modules and it is really frightening. Basically a kid can compromise, replicate a LoRa node by simply connecting to it with a simple serial port connection, then using a simple 3 characters long command, it can be transformed into a dead node by simply erasing the current firmware and anybody can force down LoRa modules, as they will wait for a new, never arriving firmware forever...