ICS OT
Protecting LoRaWAN Hardware from Attacks in the Wild
In the last article of our LoRaWAN series, we present dangerous hardware attacks that could affect organizations using this technology. These attacks are particularly worrying because many LoRaWAN devices are deployed in unsecured locations.
Save to Folio
Enterprises and smart cities have readily adopted LoRaWAN technology because of its versatility and affordability. However, as with most widely-used devices and software, there are concerns about how malicious actors can compromise or abuse this technology. We covered the state of LoRaWAN security in the first article of this series, and discussed the weak areas of LoRaWAN communications in our second article.
In this last article, we will detail the dangerous hardware attacks that could affect the organizations using this technology. These attacks are particularly worrying since many LoRaWAN devices are deployed out in the open, such as sensors deployed on vast tracts of agricultural land or across entire cities. This means that it is quite possible for malicious actors to attack unprotected LoRaWAN devices found in the wild.
LoRaWAN Hardware Attacks
In the sections below, we will introduce the different hardware hacking techniques that could compromise valuable internal data from organizations. We will also outline security procedures that could mitigate these types of attacks.
Data scraping LoRa transceivers
The LoRa transceiver communicates with the microcontroller through an SPI hardware interface. The microcontroller uses this SPI access for varied purposes, including getting uplink packets or send downlink packets to the gateway.
Using a HydraBus device (which is open-source and publicly available), we can also easily interface with this transceiver:
We can then adapt and read the SPI example script for HydraBus as follows:
And get the content as follows:
The transceiver does not handle sensitive information, but it has some registries that allow it to configure and work with different modes. Some user data can be taken from these registries. For example, access to radio data can be seen in the following page registries:
Abusing exposed interfaces on the microcontroller
All the keys and calculations that will encrypt and send packets or decrypt received packets from the transceiver are performed on the microcontroller. Unfortunately, some interfaces of these microcontrollers can be exposed, as seen with the UART interface in Figure 2. We can directly interact with it and dump secrets if the interface has no authentication mechanisms applied to the access portal:
An attacker could also use other vectors or access methods to gather data. For example, if JTAG or ICSP interfaces are enabled, it is possible to launch attacks even through certain security features. If memory protections are used, glitching attacks can be engaged to get partial or full access to the sensitive data inside the internal flash memory.
Accessing the external flash memory
If the microcontroller uses an external flash, it is possible for an attacker to interface with this memory through the exposed access ports, depending on the device’s Surface-Mount Technology (SMT) package. In certain cases, the attacker can actually chip-off or remove the flash memory from the printed circuit board (PCB) and dump the firmware (dumping is the process of copying or extracting the firmware image):
Attacks against Secure Elements
There are many different types of attacks that can be launched against microcontrollers, but the use of Secure Elements (SE) can derail attack attempts to some degree. In the case of LoRaWAN, the SE can safely store the master keys derived to encrypt communication and protect message’s integrity.
The LoRaWAN-node stack has examples of implementations containing a few integrated SEs. But, to study these Secure Elements, we have taken the approach documented by mbed in a blog post written by Jan Jongboom. In our experiments, we use the same components:
- 1 x ATSAMD21J1
- 1 x AT88CKSCKTUDFN-XPRO
- 1x SX1276MB1MAS
The Secure Element is a pre-provisioned ATECC608A-MAHTN-T placed inside the UDFN socket as follows:
The Github repository of mbed also has a good example of code to use the ATECC608A-MAHTN-T with the mbed-OS and libraries. Using the provided code, we can securely talk in I2C using the CryptoLib library with the UFDN socket:
Unfortunately for the developers, the Secure Boot is supported by the ATECC608A-MAHTN-T, but not implemented in the example. So, if a device uses this implementation with a Secure Element, it would be easy for an attacker to use the Secure Element in another microcontroller. This means that other MCUs can access data stored in the SE.
Note that this Secure Element is provided with a Secure Boot feature to authenticate the microcontroller, as shown in one of the Microchip presentations:
There are very few documented instances of Secure Elements being used in products. Unfortunately, this means that it is not easy for a developer to be aware of all the beneficial security features of these SEs.
Security Recommendations for LoRaWAN
This is the last part of our series on LoRaWAN security. To help users of this technology, we have compiled a broad list of best practices for defending devices against malicious actors. These suggestions encompass the attacks discussed in the first two parts of the series as well.
LoRaWAN is a growing and evolving technology that helps create affordable and convenient internet-of-things solutions for smart cities and critical industries. Devices are already being used to track delivery fleets, water levels in dams, secure assets, and even monitor building safety. It is essential to make cybersecurity a higher priority to protect these enterprises, employees, and critical operations.
This specific article points out the weak points of LoRaWAN hardware, and the steps organizations can take to mitigate attacks. To learn more about the security issues mentioned above, download our technical brief.
This is the last of a three-part series. The first article discussed the overall state of LoRaWAN security, while the second article analyzed the vulnerabilities in LoRaWAN radio communications. To understand the full scope of LoRaWAN security issues, read the complete series on the Trend Micro Research blog.