Inglês (pdf)
Artigo em XML
Referências do artigo
Tradução automática
Enviar este artigo por email
Citado por SciELO 
Citado por Google 
Similares em
SciELO 
Similares em Google 
Permalink
1. INTRODUCTION
The concept of Internet of Things (IoT) is relatively new; it first appeared between 2008 and 2009. It was defined by CISCO Internet Business Solutions Group (IBSG) as the time when more inanimate objects were connected to the Internet than people [1]. Today, the IoT has a great impact on people’s daily life. New devices with Internet connection are constantly being created, so not only people but also objects use the network in order to operate properly or perform the tasks for which they were created.
The IoT has environmental, industrial, urban, familiar, and personal applications. These new technologies offer great possibilities due to IoT’s ability to capture processes and transmit information [2].
Although there are many advantages to IoT technologies, device security is a particularly important aspect, especially for wireless networks [3]. The lack of a clear and well-defined information security policy inevitably leads to unauthorized access to a network or its devices, which can cause serious problems in most cases [4].
Due to the great number of possibilities offered by the IoT, many companies have introduced innovative solutions to the market and, as a result, different infrastructures have been created for IoT management and control. Some of the solutions include SigFox, a telecommunications network with wide coverage focused on low-power devices [5]; Symphony, specialized in overcoming difficulties in LoPoWANs (Low-Power Wide Area Networks) [6]; networks, Zigbee, used in many applications due to its short range, low power consumption, low data transmission, and high security [7]; and LoRaWANs, a scheme for addressing long-range links also known as LoRa [8]. This set of standards includes new technological approaches to data transmission security [9]. In addition to the development of infrastructure for IoT management, several technologies are widely used in the deployment and success of IoT-based products and services: radio frequency identification (RFID), wireless sensor networks (WSN), middleware, cloud computing, and IoT software applications [10]. Wireless technologies change very rapidly; new products and features are continuously introduced. However, their new capabilities can produce new threats or vulnerabilities to equipment and data security.
Networking with LoRa devices can be divided into two fundamental parts: one section from the end nodes to the gateway, and another section from the gateway to the servers. On the one hand, the second section includes several available security solutions, as this is not unique to LoRa devices. On the other hand, the first section may be susceptible to security attacks, so this part of the network cannot be considered a trusted network entity [11].
When analyzing the vulnerabilities in the first section of the network, the possibility of making attacks to the network by using sniffing and/or relay techniques was found. From these possible attacks, it is clear that LoRa has inherent weaknesses caused by the compromises made in its design [11].
As mentioned above, the main risk of these security failures is the theft of sensitive and/or confidential information; therefore, new methods are necessary to eliminate or minimize these failures [12].
For this purpose, one of the most practical tools in network security is a sniffer. This tool is usually employed by hackers but also network managers to maintain the security level of their networks (identifying the vulnerabilities it may present, such as device A cannot establish communication with device B) and even to efficiently manage the network, since it can identify the stability of a network with tremendous ease and perform audits in a very short time.
A sniffer records all the information that is sent in a wireless network, as well as any activity carried out. That is, it has the ability to capture and record any transfer of information, through which it is possible to discover bottlenecks in the network [13].
This article is organized as follows: Section 2 describes the configuration and hardware used for testing. Section 3 reports the test results of network attacks and the discussion. Finally, Section 4 presents the conclusions and future research.
2. METHODOLOGY
LoRaWAN defines two node activation procedures: 1) Over The Air Activation (OTAA), in which the final device sends a join request to the gateway and the gateway returns the data from the network server; and 2) Activation by Personalization (ABP), in which the required information is stored in the memory of the nodes, so communication is not necessary to join the network.
In addition, LoRaWAN networks have two security layers: the “Network Session Key”, which ensures the authenticity of the node; and the “Application Session Key”, used for data reliability [14]. However, in order to test the security provided by the protocol, some attacks were carried out on an A-class network. The measurements were taken with the hardware listed below:
-MultiTech mDot nodes
-LM35 temperature sensors
-Pressure and temperature sensor BMP280
-RTL2832U
-HackRF One analyzer
-Wireshark software
-GNU-Radio
-MultiTech gateway
The network was implemented with the previous hardware plus a network server that was also a LoRa server.
2.1 Eavesdropping
This kind of attack requires a sniffer to capture data passively; in this work packets sent from nodes to the gateway are captured by using GNU-Radio, Wireshark, and RLT2832U. Fig. 1, shows the configuration used to implement the eavesdropping test. The four A-class nodes are configured in a star topology, in which the gateway and the sniffer receive the sent data.
A simple configuration in GNU-Radio is used to capture and send the data received by the sniffer. Fig. 2, shows this arrangement with a Spread Factor (SF) of about only 12.
LoRa Receiver blocks were obtained using the gr-lora repository [15]. The RTL-SDR Source block enables the configuration of the hardware parameters of the RTL2832U sniffer (sample rate, center capture rate, and gain, among others). WX GUI blocks are employed to display the captured signal (Fast Fourier Transform and the signal spectrogram). LoRa Receiver blocks capture the frames received by the sniffer in a specific channel; in these blocks, it is possible to configure the central frequency, the reception channel, the signal bandwidth, and the propagation factor. Three blocks are used to capture the three possible channels in a transmission and, finally, the Message Socket Sink blocks allow GNU-Radio to communicate with Wireshark software and send the data captured to the port and IP address specified in the block as well as the LoRaWAN frame counter.
2.2 Replay
This attack, which consists in copying the transmitted signal to supplant the node, was implemented with a Software-Defined Radio (SDR) device. The device, a HackRF One, was configured through GNU-Radio, allowing it to make copies (Fig. 3) of the signals transmitted by the nodes to send them later (Fig. 4).
The replay tests were performed with three configurations. The first one verified if the server accepted the data copied from the node. The second one copied the data without the join request. The third one used the frame counter.
2.2.1 Configuration 1
For this scenario, a malicious node was used to access the network by copying authentication data and some data messages collected by sensors in order to verify if the server accepted the copied messages. After copying the signals with the HackRF One, the authentic node was disconnected from the network and the signal replicas of the malicious node continued to be sent.
2.2.2 Configuration 2
In this test, the data was copied without the join-request, keeping the node connected in order to falsify the data.
2.2.3 Configuration 3
This configuration consisted in waiting until the sequential number of the frame-counter inside the message was restarted
The test was performed while waiting for the counter to be reset to zero in order to send the copied data at the time the counter matches the counter of previously copied messages.
3. RESULTS AND DISCUSSION
The following are the results obtained after carrying out the attacks described above and a discussion about the possible causes that enabled them.
3.1 Eavesdropping
Fig. 5 shows the data captured in Wireshark, in which the received data that belongs to a specific node is discriminated. The captured data can be seen in hexadecimal format (but they are encrypted), and the data organized in the blocks sent by a UDP frame are located at the bottom.
Evidently, the attack was successful. However, the implemented sniffer did not inform Wireshark of the response messages from the server to the nodes. In addition, the counter was not encrypted.
3.2 Replay
The results obtained with the different configurations described above are the following.
3.2.1 Configuration 1
In order to verify whether the attack was successful, the application response of a message sent by a genuine node was compared to the application response of a message sent by the malicious node. Fig. 6 and Fig. 7 show the application responses to the messages.
Request messages in the node and answer messages in the server are necessary. They are captured by the malicious device that copies the signals. However, the answer messages are not relevant to the proposed test since, when the attack is continuously performed, the request and answer messages are sent again by the malicious node, so the attack fails. Although the response messages from the server could be removed from the copied file, the attack would still fail because the malicious device is unable to obtain the authentication keys sent in response to the forged join request.
3.2.2 Configuration 2
Although the data sent by the malicious node is received at the gateway and its identifier suggests that it was sent by the original node, the server rejects the data and they are not considered due to a synchronism failure in the message counter field. Whether the authentic node continues to send messages or not, the counter in the malicious node will not match the number stored in the counter that controls the server.
3.2.3 Configuration 3
The success or failure of the attack is verified by comparing the responses of the application to the different messages that were sent. Fig. 8, shows the synchronism of both the malicious node and the authentic node with the counter. In addition, the malicious node sends the message before the authentic node does.
Fig. 9, shows that the server only accepts messages from the authentic node. Activation by ABP has a critical vulnerability because the keys are invariable and do not need constant authentication in the network. Therefore, a malicious message, as long as it meets the following requirements, can be accepted by the LoRaWAN network server: -Session keys are the same as those of an accepted end device.
DevAddr field is the same as that of an accepted end device.
Frame counter value is acceptable [16].
Session keys are the same as those of an accepted end device.
DevAddr field is the same as that of an accepted end device.
Frame counter value is acceptable [16].
Although the previous conditions were met, the attack was not successful because the initialization of the nodes was carried out by OTAA. This created new coding keys each time a new session was completed. In addition, the malicious device (HackRF One) could not accurately copy the signal due to interference factors, sampling rate, or message transmission power. As a result, the message format was not valid for the application and rejected despite the fact that it was synchronous, i.e., it matched the value of the counter.
4. CONCLUSIONS
The main problem in carrying out an eavesdropping attack in a LoRaWAN configuration is obtaining the required hardware because GNU-Radio configures the hardware and manipulates the signals with relatively effortless simplicity.
A sequence of frames was captured, visualized, and analyzed during the eavesdropping attack.
The implemented sniffer captures messages sent from the node to the server, but not the responses from the server to the node when performing replay attacks. As noted, the HackRF One successfully copied all the messages. By capturing the response message from the server to the node, it will therefore decode the subsequent messages sent by the node.
Said sniffer only takes the message if it is configured with the same SF as the message sent, which hinders the attack on the node if this parameter is set in the message sent.
Frame counters are a measure proposed by the LoRaWAN specification to avoid replay attacks. However, given the right conditions, this measure could be violated. Even if the malicious node manages to keep sending frames for enough time, a denial of service to the node by the server could occur.
It was determined that a LoRaWAN implements has implements good measures to avoid replay attacks in OTAA activation. ABP activation countermeasures were not tested since that type of activation was not used.
