Säkerhetsrisker och utmaningar med att använda kommunikationsteknologin LoRaWAN som kabelersättare i distribuerade datorsystem

(1)

M

ÄLARDALEN U

NIVERSITY

S

CHOOL

OF I

NNOVATION, D

ESIGN

AND E

NGINEERING

V

ÄSTERÅS

, S

WEDEN

Thesis for the Degree of Bachelor of Science in Engineering - Computer

Network Engineering 15.0 hp

L

O

R

A

WAN

AS

A

CABLE

REPLACEMENT

IN

REMOTE

SYSTEMS

-

SECURITY

RISKS

AND

CHALLENGES

Magnus Karlsson

mkn17019

_{@student.mdh.se}

Examiner:

Elisabeth Uhlemann

Mälardalen University, Västerås, Sweden

Supervisor: Maryam Vahabi

Mälardalen University, Västerås, Sweden

Company Supervisor: Ola Gustavsson

Ola.gustavsson@trafikverket.se

(2)

Magnus Karlsson LoRaWAN as a cable replacement in remote systems - security risks and challenges

2020-06-18

(3)

Abstract

The Internet of Things (IoT) is revolutionizing the IT sector and it is predicted that 20 billion IoT devices will be seamlessly connected to provide information to 3 billion Internet users by the end of 2020. This development has led to an increased use of resource-stripped devices with long-range wireless connectivity. Low Power Wide Area Networks (LPWAN) technologies are becoming very popular and are hitting a broad market. One of the most promising LPWAN technologies is Long range wide area networks (LoRaWAN). However, LoRaWAN suffers from several known vulnerabilities that should be considered before implementing a system using the technology. For example, The Swedish Transport Administration, as a use case provider, is interested in evaluating the possibility of an upgrade of their road weather information system from a wired infrastructure to a wireless implementation using LoRaWAN. A weather information system, with sensors measuring different weather related parameters, distributed over a wide area, is a perfect example of an application where LoRaWAN would be suitable in theory. The goal and purpose of this thesis is to evaluate how suitable LoRaWAN is to replace the wired infrastructure from a security point of view, and to find already known security vulnerabilities together with suggestions that should be known before implementing the system. To achieve this, information about well known security vulnerabilities and upgrades have been gathered from scientific databases such as IEEExplore, ScienceDirect and MDPI. The results indicates that there are some known vulnerabilities in the LoRaWAN join-procedure, roaming and device cloning. The results also show a few proposed solutions to the most prominent and well known of these vulnerabilities, such as an improved key management protocol and protection against device cloning. The thesis ends with a use case specific discussion about security vulnerabilities of LoRaWAN when implemented as in the suggested use case on road weather information.

(4)

1. Introduction

The Internet of Things (IoT) is revolutionizing the IT sector and it is predicted that 20 billion IoT devices will be seamlessly connected to provide information to 3 billion Internet users by the end of 2020 [1]. This development has led to an increased use of resource-stripped wireless devices [2]. Therefore, techniques to save energy have become a popular research trend. Low Power Wide Area Networks (LPWAN) technologies are increasing in popularity and hitting a broad market [2]. The purpose of a wide area network (WAN) is to enable communication over longer distances by covering a larger area, and wireless WANs are widely used to enable machine to machine communication in IoT-networks. One of the most promising LPWAN technologies that attracts high attention is long range wide area networks (LoRaWAN). LoRaWAN operates in the Industrial, scientific and medical (ISM) bands, which allows for LoRaWAN network without involvement of mobile operators [3]. LoRaWAN operates in specific bandwidths which allow for better time-on-air and battery life. While being a very popular protocol, there are several reports describing known vulnerabilities and risks of using LoRaWAN.

This thesis work aims to evaluate the severity of these known vulnerabilities using an example use case provided by The Swedish Transport Administration. The goal is to give security technicians a basic knowledge on safety precautions to be implemented before using LoRaWAN in a real system and to answer the following questions:

● What security vulnerabilities and challenges exist for LPWANs?

● How suitable is LoRaWAN as a replacement for current wired infrastructure? ● What precautions should be taken before implementing LoRaWAN in a live system? To answer these questions, this thesis first looks into the security vulnerabilities addressed in the literature, followed by presenting potential solutions for them. A risk assessment methodology is used to find the most severe vulnerabilities, and these are discussed in the result section.

While performing the literature review, several well known security vulnerabilities were found [4] [1]. LoRaWAN is a wireless protocol and is thus vulnerable to common wireless attacks such as jamming and eavesdropping. But there are also several protocol-specific vulnerabilities and shortcomings that should be considered when choosing to use LoRaWAN. Several well-known solutions and suggestions were also found and are discussed in this report.

2. Ethical and Societal Considerations

Since the goal of this report is to point out and discuss security vulnerabilities in the LoRaWAN technology, there is always a possibility that attackers might use this report to find information about what attacks are worth performing or might give them the biggest possible chance of success. While all the information in this report is readily available online, it has still gathered many known vulnerabilities in one place. All the information in this report could however have been found anyways so the author does not consider the ethical and societal effect considerable. If anything, this report could help companies to implement secure and robust systems using LoRaWAN, which might lead to economic and social advancements.

(7)

3. Problem Formulation

Security in IoT-networks is becoming an increasingly important factor. Switching from a wired solution to a wireless solution is bound to introduce new challenges to the system, both in the form of power management and interference but also in added security vulnerabilities and attack vectors. In the use-case suggested by The Swedish Transport administration, multiple LoRaWAN end devices will be connected to a gateway located in an already existing radio tower. The purpose of implementing LoRaWAN is to replace the wired infrastructure that is used today. The purpose and goal of this thesis work is to find known vulnerabilities in the LoRaWAN technology and present them to The Swedish Transport Administration to address vulnerabilities before deciding to deploy a system. This report aims to analyze the protocol and answer the following questions:

● What known vulnerabilities, challenges and solutions exist with the LoRaWAN when deployed as in the use case?

● How suitable is LoRaWAN to replace the wired infrastructure that exists today from a security standpoint?

● What precautions should be taken before implementing LoRaWAN?

(8)

4. Use case

The use case utilized in this thesis work was suggested by Trafikverket. In the Road weather information system, or Väg och väderinformationssystemet (VVIS), wired sensor infrastructure is being updated and switched to wireless using the LoRaWAN technology. Sensor devices are connected to LoRaWAN end devices in a radius around a radio tower, depending on the effective transmission range of the LoRaWAN wireless communication in that area which may differ depending on the surrounding environment. In the radio tower there will be a LoRaWAN gateway which connects via cellular network to a Network Server (NS). A simplified model of the example use case can be seen in Figure 1.

Figure 1 - simplified model of the example use case

Sensors will send recorded data to the LoRaWAN gateway using the LoRa physical protocol. Data is then sent via a NS to an Application Server (AS) where the data is processed and presented to users. This system does not require a high bit rate as the information sent is relatively small in size. Trafikverket wants to maximize battery life time since changing batteries of the devices will be tedious and costly.

5. Method

The information found in this thesis has been gathered in published scientific articles that contain valid information about the usefulness of LoRaWAN in the suggested use case. The search was conducted in well known databases like IEEEXplore and ScienceDirect. The key words in the searches were “LoRaWan, fundamentals, security and vulnerabilities”. To further narrow down the results of this search the focus has been on security vulnerabilities with high impact and likelihood, using the risk assessment methodology found in the background. Vulnerabilities requiring physical access to the device will be included and analyzed. However, no suggestions regarding the improvement of physical security will be explored.

(9)

6. Background

6.2 Low power wide area network (LPWAN) technologies

Network operators are starting to deploy larger scale IoT solutions to cover wider areas [3]. Some of these devices have to communicate over long ranges with minimal power consumption [5]. These requirements are hard to fulfill with traditional IoT technologies such as cellular or WPAN. LPWAN are designed to fill this gap in traditional technologies, combining low energy usage with long range communication at the cost of lower bit rate. With LPWAN technologies, battery lives up to ten years are to be expected.

6.3 LoRaWAN

LoRaWAN, a trademark of the LoRa Alliance, uses the LoRa wireless technology as the physical layer [5] and its networks can cover large areas with only limited amounts of infrastructure. The technology uses the ISM band, which favors the deployment of private LoRaWAN networks without the involvement of mobile operators [3]. LoRaWAN is seen as one of the most promising LPWAN technologies because of its strong community support, openness and low installation cost [1].

6.3.1 LoRa

LoRa stands for Long Range, and it operates on unlicensed bands (EU 868 MHz, US 433 MHz) [6]. LoRa is a low power long range wireless physical layer protocol that uses chirp-spread spectrum (CSS) modulation, a spread spectrum technique where the signal is modulated by chirp pulses to send low amounts of data over long range with minimal power consumption. [3][1]. CSS offers a range of data rates on different frequency ranges, and is known for its robustness against interferences. However, concurrent LoRa transmissions at the same frequency and spreading factor can interfere with each other [7]. LoRa features a low data rate of 27kb/s, but a long communication range of 2-5km in urban areas [1] and up to 20km with unobstructed LoS [1].

6.3.1 Topology

A LoRaWAN network is based on a “star of stars” topology consisting of three elements, namely end devices, gateways and a NS [8]. The end devices use the LoRa physical layer to communicate wirelessly with the gateway over a single hop [3] and the gateways are then connected to a NS through a non-LoRaWAN network, for instance cellular or ethernet.

6.3.2 device classes

LoRaWAN defines three types of devices: A, B, and C, with different capabilities [3].

● Class A devices only allow data being sent to the device (downlink) after it has sent a message to the gateway (uplink). After sending a frame, the device listens to a response during two downlink receive windows. Class A devices have the lowest power consumption of the three. Class A must be implemented in all end devices.

● Class B devices are designed for applications that require more downlink messages to be sent. Obviously, there is a tradeoff between downlink traffic and power consumption. Class B devices are time synchronized using periodic beacons sent by the gateway that allows

(10)

Magnus Karlsson LoRaWAN as a cable replacement in remote systems - security risks and challenges scheduling of additional receive windows for downlink traffic. This can happen without previous uplink traffic.

● Class C devices have the most power consumption of the tree. They are always listening to the channel except for when they are transmitting, and are to be used when the application requires a lot of downlink traffic.

Devices can switch from one class to another, but it is up to the application to inform the LoRaWAN gateway about the class of a device.

6.3.3 Join-procedure

LoRaWAN defines that the secrecy and integrity of data payloads transmitted in the network are secured by employing symmetric AES-128 for both encryption/decryption and MAC operations [4]. There are two ways for a device to obtain the necessary keys to take part in a loRaWAN network (called activation of the device), which are defined below:

● Activation by personalization (ABP)

This method requires manual configuration of keys into the device. A technician connects to the device, then keys and related data is transferred to secure storage in the device. Attacks to this procedure are limited, but the procedure introduces cumbersome administrative processes and therefore scales poorly.

● Over the air activation (OTAA)

Remote activation where the end device asks permission to connect to the LoRaWAN network [4]. Permission is given by successful transmission and verification of join-request and join-accept messages. The join-request message is not encrypted. When the NS receives a join-request, it checks if the DevNonce has already been used by the device [9] If a match is found, one of two policies are typically implemented:

1. The NS drops the request and awaits another request with a valid DevNonce 2. The NS permanently excludes the end device from the network

There are currently two different versions of LoRaWAN, namely V1.0 and V1.1, and the different versions offer different contents of the join-messages[4].

❏ LoRaWAN v1.0

In version 1.0 of the LoRaWAN technology, the end device receives an Application unique identifier (APPEUI) from the relevant network manager [4]. Then, once the end device is deployed, it communicates with the NS via a LoRaWAN gateway in order to initiate the OTAA join-procedure. The end device then sends a join-request to the NS, which checks the integrity of the message and forwards it to the AS which then checks for the end device in the supported devices list. After a successful match, the AS responds with a so-called Application Nonce (a random number that can only be used once in a cryptographic communication, AppNonce) to the NS. The NS forwards this message to the end device after adding certain configuration parameters along with a message integrity code. This message is known as the Join-accept message. The end device validates the message integrity code and decrypts the rest of the message to obtain the AppNonce, network identifier (NETID) and parameters. Finally, AppNonce and NETID are used to create session-long keys: Application specific key (AppSKey) and Network session key (NwkSKey), which are used for confidentiality and integrity of the messages exchanged afterwards.

❏ LoRaWAN v1.1

In version 1.1 of the LoRaWAN technology, the join-procedure was changed drastically due to known vulnerabilities [4]. One such change is the introduction of a join-server to handle the join-procedure.

(11)

The unique identifier of the join-server as well as the unique identifiers of the device, JoinEUI and DevEUI respectively, are both pre-configured within the end device during fabrication. The end device also needs to be configured with the network key (NwKKey) and the application key (AppKey), which can also happen during fabrication but not necessarily. When the end device is deployed, it communicates with the join-server which checks the entry for this specific end device to initiate the join-procedure. The session starts with the join_request message being sent from the end device. The receiving NS checks the message and forwards the request to the join-server which matches the DevEUI of the end device to its associated NwkKey and AppKey. After a successful match, the join-server responds with a JoinNonce. The NS appends a NETID and some configuration parameters, along with a message integrity code to send back to the end device in the join_accept message. The end device validates the Message Integrity Code, decrypts the message to obtain the JoinNonce, NETID and parameters. The JoinNonce, JoinEUI, DevNonce and NwkKey are then used to create network session-long keys: Network session encryptionk key (NwkSEncKEY), used for confidentiality and integrity of the messages, forwarding network session integrity key (FNwkSIntKey), used for the message integrity code of uplink data messages, service network session integrity key (SNwkSIntKey), used for the message integrity code of downlink data messages. Finally, JoinNonce, JoinEUI, DevNonce and AppKey are used to create application session-long key: AppSKey, which is shared between the end device and the AS to encrypt/decrypt application layer payloads.

(12)

7. Related Work

In [1], the authors analyze the security of LoRaWAN with the help of the ETSI standard for risk assessment. They discuss several vulnerabilities and their risk level, as well as different application domains of LPWAN technologies. They explain the technology and its security flaws thoroughly with the goal of “shedding light on the security vulnerabilities of LoRaWAN”.

The authors of the previously mentioned report follow up on their own work in [4], when they expand on the already known security vulnerabilities by performing their own security scan on the protocol with the Scyther scanning tool. In this report, they discuss the vulnerabilities of the Join-procedure and the results of their security scan. These reports offer a more general overview of the security of LoRaWAN and do not have a specific use case in mind when evaluating the security.

Authors of [10] take a similar approach as the one used in this thesis. They review existing papers in an attempt to present key features of LoRaWAN security in a more understandable manner. They thoroughly discuss the security measures implemented in the LoRaWAN protocol and the importance of utilizing them correctly. The authors also discuss some attack vectors and how they are countered by the security measures of LoRaWAN.

In [11], the authors emphasize the lack of adequate security measures implemented for secure end-to-end applications. They propose using lightweight access control technologies such as Iptables to only allow authorized devices access to the LoRaWAN network. They also point out that the LoRaWAN gateway is outside of the trusted network and therefore can’t be classed as a trusted device when communicating with the internal application network. The authors suggest using a VPN solution and giving each gateway a certificate to connect to the internal network, thus allowing for gateway identification and preventing gateway impersonation attacks. The authors also discuss security on a NS and AS-level and implementation of monitoring systems such as intrusion detection systems.

Authors of [12] focus entirely on physical security of LoRaWAN. They emphasize the difficulty of achieving adequate physical security in remote and rural areas. To counter this vulnerability they suggest the use of Universal Subscriber Identity Module (USIM) cards to protect the information stored on the device from being extracted by an adversary.

In the work in [13] discusses the security of LoRaWAN with a specific use case in mind, specifically that of a smart factory. The authors evaluate the use of LoRaWAN in such an implementation with a performance evaluation and a security analysis. This report contains a specific security analysis of the protocol. Furthermore they also suggest an improvement to the privacy of the protocol.

In this paper, [14] the authors explore security vulnerabilities when using wireless communication in an industrial use case by using the same ETSI guidelines used in this thesis. While they don’t mention LoRaWAN specifically they point out general security vulnerabilities when using wireless technologies and structure them in an organized manner.

In his master’s thesis [15], Zulian analyzes the join-procedure of LoRaWAN thoroughly. He analyzes the join procedure, discusses vulnerabilities in the request-message, accept-message and Nonces used during the procedure. Zulian also suggests solutions to increase the security of both messages. For example, changing the DevNonce from a random number to a sequential number and adding the last generated DevNonce to the join-accept message.

(13)

8. Wireless vulnerabilities

LoraWAN is a wireless protocol, and is therefore by nature susceptible to challenges such as inter-network interference, eavesdropping and jamming attacks, DoS attacks, MAC spoofing and much more [1] [16]. When used correctly, a jamming attack in the wireless medium can lead to DoS, although the threat for LoRa is not as serious as for other narrow-band wireless technologies due to the use of CSS which spreads the use of the channels to a wider band [17]. However, more sophisticated jamming attacks such as selective-jamming attacks would result in a decrease of the network performance while being hard to detect [17]. Jamming attacks are related to the insecure nature of the wireless physical layer.

9. Risk Assessment methodology

While looking for security vulnerabilities and risks one comes across multitudes of different attack vectors and information leaks. The following risk assessment methodology has been used to accurately pinpoint the more severe and thus more important security vulnerabilities [1]. The methodology uses two main points to determine the risk of an attack: Likelihood and impact.

9.1 Likelihood

The likelihood of an attack is based on the following two factors, the motivation of the attack and the technical difficulty of the attack [1].

1. Motivation

The motivation of the attack determines how much the attacker can benefit from performing an attack on the system [1]. For example, if the benefits of what the attack would accomplish benefits the attacker more than the cost of the attack, the motivation level will be higher than if the attack costs more than the benefits of performing the attack. Motivation for an attack is rated as: Low, medium or high.

2. Technical difficulty

This represents the technical difficulties, bounds and challenges related to performing an attack [1]. Some attacks are harder to perform than others and require more technical knowledge. For example, a replay attack is relatively simple to accomplish. Packets are captured using a packet sniffer and can then be sent at other times or to other devices. However, performing an impersonation attack by introducing a malicious end device with correct encryption keys to a system requires a lot of preparation and knowledge. Technical difficulty is described by three levels: none, solvable, strong. None represents an attack that’s very easy to perform while strong represents an attack that’s very tedious to perform.

The below [1, Table 1] shows the likelihood chart of an attack with the factors given above. An attack with a low technical difficulty and a high motivation is likely to happen, while an attack with a strong technical difficulty and a low motivation is unlikely to happen.

[1, Table 1] - Likelihood chart

Difficulty None Solvable Strong

Motivation

Low Unlikely Unlikely Unlikely

Medium Likely Possible Unlikely

High Likely Likely Unlikely

(14)

9.2 Impact

The impact of an attack means the level of impact the attack will have on the targeted system [1]. The risk assessment uses two factors to determine the impact of an attack: Scale and, detectability and recoverability.

1. Scale

If an attack is performed on the system, the scale of the affected area is of relevance [1]. An attack on a LoRaWAN network can affect a single end device, the entire LoRaWAN network in use or the entire LoRaWAN enterprise network. A larger scale attack will usually lead to a higher motivation and potential gain for the attacker.

2. Detectability and recoverability

This represents how detectable an attack is and how well the system can recover from the attack. [1]. It can be categorized as three levels: low, medium, high.

The below [1, Table 2] shows the impact chart with the factors given above. An attack with a low detectability that affects the entire LoRaWAN enterprise network has a significant impact, while an attack with high detectability that only affects an end device has a minimal impact.

[1, Table 2] - Impact chart

Detectability Low Medium High

Scale

End device Moderate Minimal Minimal

LoRaWAN Significant Significant Moderate

LoRaWAN-EN Significant Significant Moderate

2.5.3 Risk assessment chart

The combination of the likelihood and impact of an attack determine the risk of the attack as in [1, table 3]:

[1, Table 3] - Risk assessment chart

Likelihood Unlikely Possible Likely

Impact

Minimal Minor Minor Minor

Moderate Minor Major Major

Significant Minor Major Critical

(15)

10. Generalized security guidelines

For a protocol to gain wide use, the users have to trust its capabilities. LPWAN technologies are on the rise and LoRaWAN is one of the strongest contenders [3]. The first step in achieving trustworthiness is to properly and faithfully capture the security requirements [16]. Security requirements vary depending on the application and the environment, but a generalized outline of security requirements for wireless protocols contains the following:

● Message integrity - Integrity is preserved if the contents of the messages are not modified or altered during transmission.

● Access control - Only authorized people and devices should be granted access to specific services in the various network devices.

● Message confidentiality - This provides assurance that no information contained in the message should be able to be accessed by unauthorized people or devices.

● Availability - The services and protocols should remain functional even if faults occur. Therefore, this requirement guarantees secure and fault tolerant protocols capable of stabilizing themselves after an attack.

● Privacy - Wireless communication should protect the privacy of network users and devices.

(16)

11. Results

In the following section nine security vulnerabilities that were identified as important during the literature review, as well as short descriptions of what counter measures are available.

11.1 Version

As can be seen in several sources [1] [4], V1.0 suffers from several severe security vulnerabilities that can be used by adversaries to breach the network [1]. These vulnerabilities can be used to compromise message integrity, confidentiality and network availability without entailing physical access to the targeted equipment. The newer version of LoRaWAN, v1.1, introduces several fixes to know security vulnerabilities, including but not limited to several updates in the OTAA join-procedure. LoRaWAN is backwards-compatible by design, which can lead to problems in long term deployment applications, especially where most of the devices are of version v1.1. When possible, the newer version v1.1 should be used to prevent these known vulnerabilities from being a security risk in the system.

11.2 Join-procedure

One of the most common delimiters when analyzing the security of LoRaWAN has been the difficulties with the join-procedure, especially in the earlier version 1.0 [4] [8]. The study by Eldefrawy et al [4] shows that the join-procedure lacks synchronization between the communicating parties which leaves the network susceptible to a common family of attacks, namely replay attacks. In version 1.0, the NS is responsible for generating both the NwkSKey and AppSKey, which is vulnerable to attacks since NS possesses the AppSKey and therefore can read any message passing by. Version 1.1 of LoraWAN contains several improvements in the join-procedure, including separation of the NwkSKey and the AppSKey root keys, which makes the vulnerability less severe. The entire join-procedure is unencrypted. However, the NS keeping a list of used DevNonces automatically protects the network from bad ramifications of replay attacks. Version 1.1 further tackles this vulnerability by sending back the received DevNonce contained within the join-accept message. The root keys are necessary to replicate the session keys created within the devices, which further helps with securing this process [1]. However, if an attacker were to get a hold of the root keys they could gain access to large parts of the network. There are several scientific papers proposing alternative / supplementary solutions to increase the robustness and security of the join-procedure [17] [18] [19].

11.2.1 Enhancing key management

Authors in [18] stress the importance of incorporating a session key update mechanism into LoRaWAN to ensure proper protection of the information shared between the end device and the NS. They propose using protocols such as Internet key exchange version 2 (IKEv2), Tunneled Direct Link Setup (TDLS) or EDHOC to handle the keys exchanged between devices. The authors propose the use of EDHOC especially because of its compatibility with LPWAN technologies and LoRaWAN in particular. EDHOC is a lightweight key exchange protocol that allows the establishment of symmetric keys between two devices. EDHOC defines a three-message exchange which can be embedded into different protocols. The proposed use of EDHOC in LoRaWAN networks is to use it to update session keys once the device has already been activated, in order to improve flexibility of the key management.

11.2.2 Enhancing the security architecture

In the paper by Nooui et al [20], the authors propose the use of a session key between the end device and NS to replace the pre-shared key in devices., which allows for a more secure communication. The solution makes use of proxy nodes and a reputation system to improve the security architecture of LoRaWAN. Using trustworthy nodes as proxies increases the robustness and helps avoid attacks launched by malicious nodes in the network. The trust value used in this process is calculated by evaluating the nodes' behavior, using factors such as: relaying data packets, sending correct partial keys, normal leaving, normal joining, available power, and available bandwidth.

(17)

11.2.3 Countermeasure for replay attacks

In the study by SeungJae et al. [19] authors suggest implementing a XOR method to prevent recognition of join-request messages. The NS uses a DevNonce to distinguish duplicate join-request messages. If a DevNonce that has been used in the past would be exposed, it is impossible to reuse the sniffed join-request messages. Therefore, DevNonces should be made unique by adding continuity with the previous connection. This allows for the creation of a unique join-request message. End devices send the masked message to an NS, who undoes the masking using the same token. In this way, even if the message is intercepted, the message would not be valid to exploit because every message is masked with a different token.

11.3 Rogue devices

It is possible for an attacker to introduce rogue devices into the network. End devices, gateways and NSs are all susceptible to impersonation [1]. End devices require the proper keys to be able to participate in the network. However, end devices can be modified to be used as jammers or bases for replay attacks against a system. The impact of these attacks are usually pretty low, ranging from the device to possibly affecting the star network. Gateways on the other hand are always considered trusted and obedient relayers of data, and are therefore susceptible to impersonation attacks, and a more specific beacon desynchronization attack targeting the use of class B LoRaWAN devices to desynch them. This is marked as a critical security vulnerability even in LoRaWAN v1.1

11.4 No encryption NS-AS

Communication between the NS and AS is not encrypted by default in out-of-the-box versions of the software [17]. This can lead to a susceptibility to man in the middle (MITM)-attacks against servers. A MITM-attack implies a scenario where the attacker has access to the communication channel between two endpoints. The attacker can receive a message from one victim, alter it, and send it to the other victim. [21]. If an attacker can tap in to the communication between the NS and AS, some of the secret keys can be exposed. This vulnerability is valid for both v1.0 and v1.1 of the technology. The specification of v1.1 suggests using encrypted communication between servers. However, this recommendation is not always followed which leaves this attack vector open for exploitation.

11.5 End to end integrity

Related to the vulnerability stated above, in the specification of LoRaWAN, it is stated that the integrity of a message is maintained in a hop-by-hop fashion [1]. In reality, this means that a rogue NS could alter the contents of a message sent by an end device before forwarding it to the AS. End-to-end integrity and confidentiality is not guaranteed by LoRaWAN and it is therefore the responsibility of the application-developer to implement these features.

11.6 Roaming

V1.1 of LoRaWAN introduces support for roaming of devices [1]. Both versions of LoRaWAN are susceptible to bit-flipping attacks, an attack which changes specific fields on ciphertext without decryption [20], happening in between servers. The inclusion of handover-roaming in v1.1 makes the situation worse. Handover-roaming enables more possibilities for a MITM-attack, and can also cause a fall-back when the back-end NS that serves the roaming end device runs v1.0

(18)

11.7 Gateway tampering

In most implementation scenarios, there is a single gateway responsible for the connection between several end devices and the NS [1]. This presents a single point of failure for every star in the LoRaWAN network. Any kind of capture or tampering of a gateway would therefore influence that entire network segment.

11.8 Exit procedure

Developing a proper exit procedure for retiring devices is crucial to protect old keys and information from being reused, and is often overlooked during system development [1]. It is stated in the specification that LoRaWAN devices depend on the application to perform this procedure for decommissioned devices. There is currently a lack of standards regarding the exit-procedure of a device. The procedure should purge the device of any IDs, passwords, keys etc. before the device is retired and decommissioned. Otherwise, a retired device could be used to gain information and potentially even access to the LoRaWAN network.

11.9 Firmware replacement

In remote areas that are hard to monitor, the vulnerability to physical attacks increases [12]. An attacker with physical access to a LoRaWAN device can steal or replace the device. This opens up the opportunity for replay attacks, impersonation attacks, malicious devices and device tampering [1]. Even though the protocol offers some protection against this kind of scenario [22], this is still classed as a critical risk to the system in [1] because of the risk of unauthorized access to devices on the network by using stolen or cloned devices. In [12], authors suggest the use of Universal Subscriber Identity Module (USIM) cards to protect the information stored in the device and prevent the keys from being extracted.

(19)

12. Discussion

The following two sections, 12.1 and 12.2, contain the evaluation of the security vulnerabilities and solutions found in the results above. The vulnerabilities have been given a severity based on the ETSI guidelines. The discussion has been split into two parts, one with the scope of a general LoRaWAN network implementation and one with the scope of the specific LoRaWAN network implementation that is used in the suggested use case.

12.1 General discussion

This section contains the discussion of general security vulnerabilities for the LoRaWAN protocol. Section 12.2 will contain a more use case specific discussion

12.1.1 Wireless technologies

When switching from a wired to a wireless technology, several challenges are introduced to the system just by the nature of the susceptible wireless medium. However, this is often not because of the implementation of the technology or application. Wireless communication is broadcasted by nature, and can therefore be eavesdropped by anyone nearby or jammed. While weaknesses in the wireless physical layer should be accounted for, they cannot be perceived as weaknesses in the evaluated technology since the same would be true for any other protocol that uses the wireless medium. LoRaWAN even handles this better than similar protocols. Wireless protocols are only suitable replacements for a wired infrastructure in certain situations. Wired connections have much higher bit rates and reliability than wireless protocols.

12.1.2 Patching

Keeping your software up to date is a general security best practice and should always apply. Several sources have shown that v1.0 suffers from several well known vulnerabilities that have been fixed in the later v1.1. However, many v1.0 devices are still active in networks all over the world.

The different device classes also matter while discussing patching of the network. The most optimal class of device to be used in the example use case would be the class A device because of its minimal power consumption. Class A devices are also favorable because implementing class B devices into the network opens up the availability of beacon attacks as discussed above. However, class A devices only offer windows for downlink communication after a message has been sent uplink, which makes it difficult to push any kind of remote security update via the cloud.

12.1.3 Protecting the join-procedure

The most common security vulnerability found and discussed in LoRaWAN networks is that of the Join-procedure. There are several ways of improving this procedure and some of them have been presented in the results. Using EDHOC to routinely change the root keys used to make the required keys and using the XOR method to prevent replay attacks during the join-procedure would make the procedure more secure and therefore make the entire system more robust. The nodes are very far apart and physical security is hard to implement in such remote locations. A scenario where an attacker jams the wireless medium around the LoRaWAN devices is therefore very likely and implementing more security to protect the join-procedure would help increase security.

12.1.4 Encryption NS - AS

As discussed earlier, LoRaWAN itself does not offer encryption between the NS and the AS. It is stated in the protocol specification that application developers are recommended to implement methods to achieve privacy and integrity between those servers. MITM attacks performed against the communication between the NS and AS could otherwise reveal vital information about the network and the application and also be a strong base point to launch malicious code into the AS. Adding encryption and integrity checks between the NS and AS would improve the robustness of the system and should be implemented before bringing the system live.

(20)

12.1.5 Roaming

In the example use case, roaming will not be implemented and therefore will not be a problem. However, the fact that both versions of LoRaWAN are susceptible to bit-flipping attacks when devices roam between different NS should still be considered. Roaming of LoRaWAN devices might be used in other applications using the LoRaWAN technology, and if it is, it will introduce security challenges that are not present with a stationary topology.

12.1.6 Physical security risks

LoRaWAN devices placed in remote locations with little physical security will be susceptible to physical attacks. An attacker could with relative ease gain physical access to a device and tamper with it, clone it or replace it. While this attack will mostly target the affected LoRaWAN star, it could potentially affect the entire LoRaWAN network in use. While sufficient physical protection is near impossible to achieve in such remote locations if the motivation of the attacker is high enough. Added security to prevent replay attacks and impersonation attacks would greatly increase the robustness of the system.

12.2 Use case specific discussion

This section contains a use case specific discussion about security vulnerabilities of LoRaWAN when implemented as in the suggested use case.

12.2.1 Wireless vulnerabilities

The suggested use case will contain wireless communication both between end devices and the gateway, and as the backhaul network between the gateway and NS. This introduces the innate wireless security challenges to the system. The LoRaWAN communication will be susceptible to jamming attacks, eavesdropping and more attack vectors because of the wireless medium and is something that should be considered before implementing it. LoRaWAN even handles these attacks pretty well with the use of CSS. Most of these attacks have a very low impact and can only affect a single end device or possibly a network segment. It’s also difficult to find attacks with a sufficient motivation to warrant an attack against the system. Messages sent, excluding the messages exchanged during the join procedure, are encrypted and thus protected against eavesdropping.

12.2.2 Physical security risks

In the suggested use case, devices will be placed in remote locations and far from each other. In this scenario, it is difficult to provide adequate physical protection against tampering and an attacker could with very little technical difficulty gain access to the LoRaWAN devices. This opens up several attack vectors with varying impacts, motivations and technical difficulties. The devices that can cause the most damage by being tampered with are the LoRaWAN gateways. Gateways represent a single point of failure for an entire network segment and are considered trusted devices by the NS, and thus the possibility of a impersonation attack that could lead to malicious code being injected to the NS or information being revealed is definitely present. The end-devices can also be tampered with but result in a lower impact than a compromised gateway. If possible, device security should be enhanced by the use of secure storage units on the devices to further prevent critical data from being extracted.

12.2.3 Join-procedure

Exploitation of the join-procedure will be possible in the suggested use case. A device could be jammed for long enough to disconnect it from the network, and the join-procedure messages can be captured and exploited. The out-of-the-box protection against replay attacks with nonces is not adequate and some kind of extra security measure should be implemented. Three possible solutions have been presented in this report and should be considered to increase the technical difficulty of performing an attack against the join-procedure.

(21)

12.2.4 Patching difficulties

The devices in the given example use case are planned to last for at least a decade before having to be replaced, and are often placed in remote areas and are therefore tedious to patch manually. This introduces the question of how to best implement a patching cycle for the network, as even a single device running an older version of the software can imply a security risk to the entire system because of the backwards compatibility supported by all LoRaWAN devices. The need for long battery life time contradicts the need for constant patching and could introduce challenges to the maintenance of the network. At least a class B device will have to be used to allow for downlink communication to the device. However, using a class B device introduces additional security challenges such as the beacon desynchronization attack aimed specifically towards class B devices.

13. Conclusions

The goal of this thesis work was to find information about known vulnerabilities and improvements to LoRaWAN and evaluate whether or not it is a suitable replacement for an already existing wired infrastructure from a security point of view. Several known security vulnerabilities and solutions were found and have been discussed in this report. Most of the vulnerabilities found were related to the wireless nature of LoRaWAN, not to faults in the protocols itself. When it comes to protocol security, LoRaWAN is better protected from common attacks than other competing protocols. The most severe vulnerabilities found were that of the susceptible join-procedure, and bit-flipping attacks in between network servers while roaming. The latter is not applicable in the presented example use case since all devices will be stationary, and the former has several potential solutions, a few of which have been presented in this report.

The fact that LoRaWAN does not offer end-to-end integrity and encryption is also troublesome, and this should be implemented at the application level. This is suggested in the LoRaWAN specification and should be done before bringing the system live. The discussed solutions for key management and replay attack prevention should also be taken into consideration before bringing the system live to prevent unnecessary risks to the system.

To conclude, from a security standpoint LoRaWAN does seem to fulfill the requirements and guidelines of a secure wireless protocol, and is therefore currently a suitable choice to replace the wired infrastructure in VVIS. However, IoT-security is an ever changing field of study, and more versions of LoRaWAN are bound to appear, and with it many more security vulnerabilities and solutions to them. Evaluating the security of LoRaWAN in different applications and scenarios may lead to different conclusions and results. A more thorough security evaluation with scans and hands-on testing would also be beneficial to determine the robustness of the protocol.

(22)

14. References

[1] I. Butun, N. Pereira and M. Gidlund, "Security Risk Analysis of LoRaWAN and Future Directions", Future Internet, vol. 11, no. 1, p. 3, 2018.

[2] J. de Carvalho Silva, J. J. P. C. Rodrigues, A. M. Alberti, P. Solic and A. L. L. Aquino, "LoRaWAN — A low power WAN protocol for Internet of Things: A review and opportunities,"_{2017 2nd International Multidisciplinary Conference on Computer and Energy} Science (SpliTech), Split, 2017, pp. 1-6.

[3] F. Adelantado, X. Vilajosana, P. Tuset-Peiro, B. Martinez, J. Melia-Segui and T. Watteyne, "Understanding the Limits of LoRaWAN," in IEEE Communications Magazine, vol. 55, no. 9, pp. 34-40, Sept. 2017.

[4] M. Eldefrawy, I. Butun, N. Pereira, and M. Gidlund, “Formal security analysis of LoRaWAN,” _{Computer Networks, vol. 148, pp. 328–339, Jan. 2019.}

[5] F. Van den Abeele, J. Haxhibeqiri, I. Moerman and J. Hoebeke, "Scalability Analysis of Large-Scale LoRaWAN Networks in ns-3," in IEEE Internet of Things Journal, vol. 4, no. 6, pp. 2186-2198, Dec. 2017.

[6] M. T. Buyukakkaslar, M. A. Erturk, M. A. Aydin and L. Vollero, "LoRaWAN as an e-Health Communication Technology," 2017 IEEE 41st Annual Computer Software and

Applications Conference (COMPSAC), Turin, 2017, pp. 310-313

[7] E. Aras, G. S. Ramachandran, P. Lawrence and D. Hughes, "Exploring the Security Vulnerabilities of LoRa," 2017 3rd IEEE International Conference on Cybernetics (CYBCONF), Exeter, 2017, pp. 1-6.

[8] Casals, L.; Mir, B.; Vidal, R.; Gomez, C. Modeling the Energy Performance of LoRaWAN. Sensors 2017, 17, 2364.

[9] S. Tomasin, S. Zulian and L. Vangelista, "Security Analysis of LoRaWAN Join Procedure for Internet of Things Networks," 2017 IEEE Wireless Communications and Networking Conference Workshops (WCNCW), San Francisco, CA, 2017, pp. 1-6.

[10] A. Gladisch, S. Rietschel, T. Mundt, J. Bauer, J. Goltz and S. Wiedenmann, "Securely Connecting IoT Devices with LoRaWAN," 2018 Second World Conference on Smart Trends in Systems, Security and Sustainability (WorldS4), London, 2018, pp. 220-229.

[11] B. Oniga, V. Dadarlat, E. De Poorter and A. Munteanu, "A secure LoRaWAN sensor network architecture," 2017 IEEE SENSORS, Glasgow, 2017, pp. 1-3,

[12] J. Navarro-Ortiz, N. Chinchilla-Romero, J. J. Ramos-Munoz and P. Munoz-Luengo, "Improving Hardware Security for LoRaWAN," 2019 IEEE Conference on Standards for Communications and Networking (CSCN), GRANADA, Spain, 2019, pp. 1-6.

[13]I. You, S. Kwon, G. Choudhary, V. Sharma and J. Seo, "An Enhanced LoRaWAN Security Protocol for Privacy Preservation in IoT with a Case Study on a Smart Factory-Enabled Parking System", Sensors, vol. 18, no. 6, p. 1888, 2018.

(23)

[14] S. Plosz, A. Farshad, M. Tauber, C. Lesjak, T. Ruprechter and N. Pereira, "Security vulnerabilities and risks in industrial usage of wireless communication," Proceedings of the 2014 IEEE Emerging Technology and Factory Automation (ETFA), Barcelona, 2014, pp. 1-8. [15] S. Zulian, “Security Threat Analysis and Countermeasures for Lorawan Join Procedure.

Master’s Thesis”, Universit’a degli Studi di Padova, Padova, Italy, 2016.

[16] Ghosal A, Conti M. “Security Issues and Challenges in V2X: A Survey”, Computer Networks. 2020 Jan 3:107093

[17] I. Butun, N. Pereira, M. Gidlund, “Analysis of LoRaWAN v1.1 Security”, SMARTOBJECTS’18, 4th ACM, June 2018

[18] R. Sanchez-Iborra et al., "Enhancing LoRaWAN Security through a Lightweight and Authenticated Key Management Approach", Sensors, vol. 18, no. 6, p. 1833, 2018.

[19] SeungJae Na, DongYeop Hwang, WoonSeob Shin and Ki-Hyung Kim, "Scenario and countermeasure for replay attack using join request messages in LoRaWAN," 2017

International Conference on Information Networking (ICOIN), Da Nang, 2017, pp. 718-720

[20]S. Naoui, M. E. Elhdhili and L. A. Saidane, "Enhancing the security of the IoT LoraWAN architecture," 2016 International Conference on Performance Evaluation and Modeling in

Wired and Wireless Networks (PEMWN), Paris, 2016, pp. 1-7

[21] M. Conti, N. Dragoni and V. Lesyk, "A Survey of Man In The Middle Attacks," in IEEE

Communications Surveys & Tutorials, vol. 18, no. 3, pp. 2027-2051, thirdquarter 2016

[22] N. Sornin, M. Luis, T. Eirich, T. Kramp, and O. Hersent, “LoRaWAN Specifications”, LoRa Alliance, San Ramon, CA, USA, 2015.

Säkerhetsrisker och utmaningar med att använda kommunikationsteknologin LoRaWAN som kabelersättare i distribuerade datorsystem

M

​

​

S

​

​

​

​

​

​

V

​

, S

​

Thesis for the Degree of Bachelor of Science in Engineering - Computer

Network Engineering 15.0 hp

L

​

O

​

R

​

A

​

WAN

​

AS

​

​

A

​

​

CABLE

​

​

REPLACEMENT

​

​

IN

REMOTE

​

​

SYSTEMS

​

-

​

SECURITY

​

​

RISKS

​

​

AND

CHALLENGES

Magnus Karlsson

mkn17019

​@student.mdh.se

Examiner:

Elisabeth Uhlemann

Mälardalen University, Västerås, Sweden

Supervisor: Maryam Vahabi

Mälardalen University, Västerås, Sweden

Company Supervisor: Ola Gustavsson

Ola.gustavsson@trafikverket.se

Abstract

Table of Contents

1.

Introduction

2.

Ethical and Societal Considerations

3. Problem Formulation

4. Use case

5.

Method

6.

Background

6.2 Low power wide area network (LPWAN) technologies

6.3 LoRaWAN

7. Related Work

_{@student.mdh.se}