LoRaWAN, a long-range wireless communications technology for low-powered devices such as sensors, has been gaining popularity worldwide in smart city, industrial internet of things (IioT) and smart home projects. Even though the protocol uses built-in encryption, implementation errors are common, and they enable attacks that are hard to detect.
In a new paper published today, researchers from security consultancy firm IOActive highlight the type of mistakes commonly made by device manufacturers, network operators and users when building and deploying LoRaWAN devices as well as the risks associated with those errors. To help combat the issues, the researchers developed and released an open-source framework that can be used to audit such networks.
What is LoRaWAN and how does it work?
LoRaWAN is a communications protocol that allows low-power devices to exchange data with Internet-enabled applications over long-range (LoRa) wireless connections that travel many miles and are not using the licensed wireless spectrum. This makes LoRaWAN a low-cost solution for IIoT networks when compared to cellular technologies that require more expensive components, such as cellular modems, and are regulated.
LoRaWAN has many applications from automating parking, lighting and traffic management in cities, to weather monitoring, automated electricity meter reading, asset tracking, climate control, alarm systems, home automation, smart agriculture and more. According to the LoRa Alliance, the non-profit technology association that oversees the protocol, there are currently LoRaWAN deployments in 143 countries, with 133 public network operators in 58 countries. In fact, some cellular carriers such as KPN in the Netherlands, Orange in France and Telekom in South Korea offer LoRa coverage as a service.
LoRaWAN traffic is sent over the LoRa physical wireless communications layer between end devices and gateways, and then from gateways to a network server using the Internet Protocol (IP). The network server routes incoming messages received from the various devices to the appropriate application servers developed by the customer depending on the intended purpose of the network.
There are two layers of encryption. The traffic between end devices and the network server is encrypted with a Network Session Key (NwkSKey), while the traffic between end devices and the application servers that ultimately receive the data is end-to-end encrypted with an Application Session Key (AppSKey). The protocol also uses message counters to prevent replay attacks, as well as unique device and network identifiers and message integrity codes in order to protect the integrity of communications.
Security depends on good key management
For deployments that use the LoRaWAN 1.0.x version of the protocol -- this is the case of the majority of devices deployed today -- the session keys are either hard-coded in the device firmware or are derived when first joining the network from a device-specific AppSKey, in the case of over-the-air activation.
Like in the case of all encrypted communications, the confidentiality of the keys that are used to derive session keys, or the session keys themselves, is paramount. However, in practice and often for usability reasons, device vendors and network operators make implementation choices that can compromise the security of those keys.
"Common problems that face LoRaWAN implementations are related to the keys and their management," the IOActive researchers said in their paper. "Once the keys are compromised, the LoRaWAN network becomes vulnerable, as the keys are the source of the network’s only security mechanism, encryption. After reviewing vendor documentation, one may quickly realize that it is not difficult to obtain credentials for devices that are physically accessible."
A new version of the protocol, LoRaWAN 1.1, has added security enhancements, including separating the session key from the network server and moving it to a separate joining server, adding a root key to the protocol, increasing the number of session keys for different purposes, and strengthening the message counters.
While this version of the protocol offers better security, it's still not impervious to implementation errors and poor key management practices, according to IOActive. Furthermore, its adoption will take time and many existing devices are unlikely to be upgraded to use it due to hardware limitations.
Attackers can obtain the keys they need to launch attacks against LoRaWAN devices and networks in several ways. For one, hard-coded keys can be extracted from devices or from publicly available firmware using reverse engineering methods, the researchers said.
Many devices also come with printed tags that have a QR code or text with the device’s DevEUI unique identifier, AppSKey and more. If those tags are not removed before deploying devices in the field, attackers could use the information they contain to generate valid session keys.
Vendor-owned open-source repositories and websites sometimes contain hard-coded device-specific keys or application and network session keys that are intended to be changed before deployment. Unfortunately, in many cases those keys are never replaced, but even when they are changed, the new keys often don't have sufficient randomness and are generated using guessable patterns from device information that is accessible to attackers.
"If an attacker obtains a single device’s AppSKey by guessing the logic used to generate AppSKeys or by brute-force, the attacker might gain access to the entire LoRaWAN network," the researchers warn.
Another common problem is that LoRaWAN network servers, which have access to keys by virtue of their role in the network, are using weak or default administrative credentials. Searchers on Shodan revealed LoRaWAN network servers that are connected directly to the internet, which is poor security practice, especially since the software running on those servers could have other vulnerabilities that enable unauthorized access.
Device manufacturers are often in charge of flashing the firmware on devices and setting the keys, so they can be an appealing target for hackers because their production systems could hold the keys for thousands of devices. Keys are also often shared with customers via email, USB sticks and other methods, exposing them to additional people, including infrastructure technicians who might be storing them on their computers.
Finally, service providers sometimes handle the operation of LoRaWAN gateways and network servers on behalf of customers and need access to device-specific keys to accept them on the network. Those keys are likely to also be stored in backups and databases for easier management and could be exposed if those infrastructure providers ever get breached.
It's also possible to crack keys by using offline brute-force dictionary attacks after capturing encrypted network packets. The IOActive researchers present several techniques for doing this in their paper. They've also found cases where the same AppSKey was shared my multiple devices, so cracking a key for a single device can be used to control, spoof and launch denial-of-service (DoS) attacks against a group of devices. To make things worse, the keys for some devices cannot be changed, so a compromise could last until those devices are physically replaced.
Read more on the next page...