Security Vulnerabilities in LPWANs—An Attack Vector Analysis for the IoT Ecosystem

: Due to its pervasive nature, the Internet of Things (IoT) is demanding for Low Power Wide Area Networks (LPWAN) since wirelessly connected devices need battery-efﬁcient and long-range communications. Due to its low-cost and high availability (regional/city level scale), this type of network has been widely used in several IoT applications, such as Smart Metering, Smart Grids, Smart Buildings, Intelligent Transportation Systems (ITS), SCADA Systems. By using LPWAN technologies, the IoT devices are less dependent on common and existing infrastructure, can operate using small, inexpensive, and long-lasting batteries (up to 10 years), and can be easily deployed within wide areas, typically above 2 km in urban zones. The starting point of this work was an overview of the security vulnerabilities that exist in LPWANs, followed by a literature review with the main goal of substantiating an attack vector analysis speciﬁcally designed for the IoT ecosystem. This methodological approach resulted in three main contributions: (i) a systematic review regarding cybersecurity in LPWANs with a focus on vulnerabilities, threats, and typical defense strategies; (ii) a state-of-the-art review on the most prominent results that have been found in the systematic review, with focus on the last three years; (iii) a security analysis on the recent attack vectors regarding IoT applications using LPWANs. Results have shown that LPWANs communication technologies contain security vulnerabilities that can lead to irreversible harm in critical and non-critical IoT application domains. Also, the conception and implementation of up-to-date defenses are relevant to protect systems, networks, and data.


Introduction
The Internet of Things (IoT) ecosystem, due to its pervasive nature, demands lowpower and wide-area communications, particularly in applications, where IoT devices do not require high speed nor high bandwidth, but still need extended coverage. Generally, an IoT device is typically composed of: a sensing/actuating element; a small-sized battery; a low-cost microprocessor (typically a microcontroller); limited memory; and a radio module that enables low-power wireless communications. When operating, the power budget of an IoT device is mostly affected by the computing and communications tasks. This means that to increase the autonomy of an IoT device, the reduction of the computational cost and the minimization of the communication load (mainly affected by the duration and duty-cycle of data transmission, and the available bandwidth) must be a priority.
Reducing the computational cost can be achieved by selecting state-of-the-art ultralow-power microprocessors and by using event-triggered programming techniques, such as Wake-on-Interrupt (WoI) [1] or Wake-Up-Radio (WUR) [2,3], and by forcing the microprocessor into an ultra-low-power "sleep" state, until a WoI or WUR event occurs. These When compared with other technologies, cf. Figure 2, LPWANs present higher costbenefit and higher power/bandwidth efficiency for long-range communications, which results in less infrastructure/hardware needs. By using LPWAN technologies, communications become less dependent on common existing infrastructures-for example, Wi-Fi, which is widely available but presents major drawbacks such as high power consumption and short-range communications-enabling IoT devices to operate on small and inexpensive batteries, and be easily deployed within a wide area, typically more than 2 km in urban zones [9]. agent interferes with the communications between the IoT devices and the Health Care centers, the user's health can be severely impacted. In other application domains, for example, in a bicycle sharing scenario, an attacker can compromise the location of a bicycle-by attacking the bicycle tracking system-to subtract/steal the bicycle from the system. Moreover, LPWAN technologies can lead to security issues that we aim to explore in this work. For instance, SigFox does not encrypt the transmitted frame (i.e., the encryption is done by the developer, in the application layer) [33]. In LoRaWAN, the join request is not encrypted in any way, which can lead to a possible eavesdropper that could gain information about the topology of the network [33]. Moreover, LPWAN technologies use, in general, symmetric-key cryptography in which, the end devices and the network, share the same secret key [28].
The main goal of this work is to provide a general overview of which LPWAN technologies are most used today, as well as, to address the core security gaps found in this type of technologies. After identifying its core vulnerabilities, defense strategies are put forward for each specific attack vector, to mitigate the risks that are directly related to each vector. Afterward, a general model for the IoT ecosystem is presented, making it possible to map the security vulnerabilities previously identified, and thus, making it easier to identify the critical attack vectors that can be exploited by malicious users.
This paper provides a security analysis to the attack vectors regarding generic IoT application, given by the evolution (in the last 10 years) of the security issues regarding LPWANs and explore the most relevant state-of-the-art works (from the last three years) that address this topic. To attain this goal, the research methodology was divided into these three steps: 1. Systematic review regarding security in LPWANs with focus on main vulnerabilities, common threats and typical responses, adopted since 2010. 2. State-of-the-art review that focuses on the most prominent results found in the systematic review. 3. Attack Vectors Analysis for a generic IoT application that can be explored in the context of IoT applications using LPWAN.
Based on the results obtained with the systematic review, it was observed that the LPWAN technologies that have been more used and studied, are LoRaWAN and NB-IoT, respectively. After researching LPWAN-related works, relevant vulnerabilities, threats, attack types, and possible defenses were identified and presented in detail. This research has been undertaken to discover strategies to protect, mitigate or even eliminate these security weaknesses. In addition, a set of six attack vectors were identified and related to the security flaws addressed in the state-of-the-art review. Each attack vector was analyzed according to its impact on different application scenarios, which are more likely to be affected by malicious interactions.
The remainder of this document is organized as follows-Section 2 introduces and describes the systematic review methodology and presents its results; Section 3 presents the state-of-the-art review as well as its results; Section 4 defines and presents the analysis on the attack vectors in LPWAN-based IoT applications; Section 5 puts forward a discussion regarding the security analysis; Lastly, in Section 6, the main conclusions are cited.

Systematic Review
To perform the systematic review, the PRISMA checklist [34] was used as a reference, where some parts have been adapted to the topic under study. Initially, the following set of Questions were defined and the systematic review is expected to answer each of these questions: -Q1-Given the technologies LoRa, Sigfox, LPWAN, and NB-IoT, what is the progress in the number of papers published? -Q2-In the specific range of technologies (LoRa, Sigfox, LPWAN, and NB-IoT), which security-related topics have been addressed by the researchers? -Q3-Given a set of security related topics, what are its relation to LPWAN, LoRa, Sigfox, and NB-IoT? -Q4-What is the progress of research papers using the range of technologies (LoRa, Sigfox, LPWAN, and NB-IoT) and the set of security-related topics? -Q5-What is the progress of research papers using the range of technologies (LoRa, Sigfox, LPWAN, and NB-IoT) and the set of security-related topics regarding the smart application's context (such as smart campus, smart environment, and smart monitoring)?
The systematic review follows a defined process, to structure and organize the entire research. A diagram of the systematic process is presented in Figure 3, which identifies all the phases, from the questions to the results.  After defining the questions, cf. Section 2, the selection of the search engine was performed. In this work, we opted for the IEEEXplore database, since, when compared to other types of search engines (Google Scholar, Scopus, Arxiv, MDPI, DOAJ), was the one that demonstrated greater capacity and being user-friendly when using relatively elaborated queries (with different types of fields). Specifically, it can use more than four types of keywords in one search query, and thus, all the queries defined could be easily implemented.
In the "Define keywords" step, a list of keywords was defined to be used in the construction of the queries. Defining the right keywords (e.g., attack, lora, LPWAN, exploit, security) according to the theme under study, are relevant to answer the questions. The keywords were divided into three main categories: Security-related "Security", Technology-related ("Tech"), and smart-based environments ("Smart"). In each category, the keywords were defined as presented in Table 1. The following step is to "Define Queries". To elaborate the queries, the keywords were arranged and combined. The queries accepted by IEEExplore search engine obey to the following format: ("Document Title":lora OR "Document Title":sigfox OR "Document Title": LPWAN OR "Document Title":nb-iot) AND ("All Metadata":attack)-this query returns articles where the document title includes "lora" or "sigfox" or "LPWAN" or "nb-iot" and in all metadata, the word "attack" exists.
The queries were defined and grouped in the same categories of the keywords and, in total, sixteen queries were performed as follows in Figure 4.  Figure 4. Queries defined for each category ("Security", "Tech" and "Smart").
In the "Data extraction & synthesis" step, all the publications obtained by the queries had their information collected regarding the following information: -Title and abstract of the articles; -Authors names; -Publication year; -Type of vulnerabilities/attacks/security mechanisms/defenses.
In the "Process Data" step, to select the relevant literature, inclusion and exclusion criteria were set. The adopted inclusion and exclusion criteria are presented in Table 2. After performing all the steps of the systematic process, the results were obtained and presented as a heatmap in Figure 5. These results are expressed in the same three categories defined in the keywords and the queries: Security, Tech, and Smart.
As final remarks, it can be highlighted that, since the queries in the "Security" and "Tech" categories depended on technologies launched around 2015 like LoRa [35] and NB-IoT [18], the results appear after 2015. In the "Security" category, the query obtaining a higher number of total papers was the more general query including the security word in the metadata, totaling 95 papers. In this general query, the results jump from 2 papers at the beginning of 2016 to 35 papers, in 2019. The second query with more papers in the "Security" category was the query using the exploit word, with a total of 57 papers. The queries related to defense, vulnerabilities, and privacy, obtained the least number of papers, totaling 9, 7, and 6 papers, respectively.
For the queries defined under the category "Tech", the query with lora counted 89 papers, more than the double of the query in second, that is, it is followed by the query with nb-iot, with 42 papers, the one using lpwan, with 24 papers, and finally sigfox with only 3 papers. Regarding the topic "Smart", the generic query smart obtained 86 papers, with a maximum in 2019. Within the specific queries including smart environment, smart campus, and smart monitoring, the one that ranked higher numbers was the last, with 25 related works. It was followed by the query including smart environment, with 16 works, and finally smart campus with only 2 papers. The results regarding these specific queries are diverse over the years, without a pattern or peak that could be indicative of any factor.
The results obtained are important to understand the dynamics around securityrelated topics and the selected technologies and are highly dependent on: the search engine, the keywords, the queries defined, and the inclusion and exclusion criteria. Given this, the questions initially defined can be answered as follows:

State-of-the-Art Review
IoT technologies have grown over the past years increasing the quality of human life in different application domains, namely, everyday applications (smart home, smart transportation, smart education, smart cities), economy applications (mining fields, oil and gas fields, productivity in factories), health care and security applications [36][37][38][39].
The existing IoT connectivity standards, for example, in IEEE 802.15.1 and IEEE 802.15.4 have been generally used, but their short communication range has been announced as the main drawback [40]. Alternatively, cellular networks that allow a wide connectivity range present cost and complexity as their main drawback. Thus, LPWAN has granted a viable option to the diversified shortcomings of these standards.
With LPWAN use cases growing [41], it is crucial to assess the security mechanisms of these technologies. Multiple LPWAN technologies are available using different frequencies and transmission mechanisms, however, all of these types of communications have their own set of resources and security mechanisms for authenticity, confidentiality, and data integrity [42]. Even with the valuable characteristics that LPWAN technologies present, security and privacy issues still the biggest challenge for their large-scale implementation [40]. Due to their heterogeneity, ubiquity, and easy accessibility to devices in the network, LPWANs vulnerabilities continue to increase, leading to new threats and types of intrusions [39]. Security is a major concern in the IoT ecosystem, where LPWAN communication technologies play a crucial role. These types of technologies increase the attackers' range of action due to their long-range connection and high transmission time. Each device connected to the network is a possible vulnerable point where each type of technology uses its security mechanisms to establish secure communications [43].
In this section, the main vulnerabilities, threats, attacks, and defense strategies to these gaps in LPWAN networks will be presented, through a state-of-the-art review.

Vulnerabilities
Vulnerabilities can be discovered in a diversity of fields in IoT systems. Specifically, they can be shortcomings in system software, hardware, weaknesses in policies and procedures used in the frameworks, and flaws of the system clients themselves [44].
IoT frameworks depend on system hardware equipment and system software, and both have design and configuration defects frequently [45]. Equipment vulnerabilities are exceptionally hard to identify, due to hardware compatibility and interoperability issues, that are difficult to fix [45]. Software weaknesses are present in operating systems, application software, and control software such as communication protocols and device drivers. There are derived circumstances that can lead to software design flaws, namely, human factors and software complexity [46]. Technical vulnerabilities normally occur due to human errors, failing to understand the application requirements can result in starting the project without a plan, weak communication between developers and users, lack of resources, skills, knowledge, and failure to manage and control the system [44].
LoRaWan [47] technology includes end-to-end security using network and application keys. Despite this, a malicious agent that obtains physical access to the devices can eventually compromise them; with physical access to the devices, it is possible to extract the keys. Typically, end-devices are characterized by a LoRa radio module and a host MicroController Unit (MCU). The radio module performs communications between the host microcontroller via Universal Asynchronous Receiver/Transmitter (UART) or Serial Peripheral Interface (SPI) interface. The data exchange and commands between the host and the radio module can be intercepted using external hardware to the device. An example of this type of intrusion is, for example, if a UART interface is used between two Integrated Circuits (ICs), the basic Future Technology Devices International (FTDI) interface can be used to extract all the key exchanges. Most present-day radio modules do not provide any built-in cryptography support to protect the interactions between the host microcontroller and the radio module. In this way, it is not possible to determine whether the commands issued to the radio module were sent by the MCU host or by an attacker. A malicious entity can also intercept all data exchanges between the host MCU and the radio module, and eventually use all of this information to create simulated devices with the same credentials or even shape data payload.
Chirp Spread Spectrum (CSS) modulation is known for its firmness facing interferences, despite this, LoRa devices suffer from coexistence issues [48]. Simultaneous LoRa transmissions at the same frequency and spreading factor can meddle with each other. This weakness in LoRa physical layer permits attackers or outsiders to utilize Commercial-Off-The-Shelf (COTS) LoRa devices to jam LoRa networks.
A critical factor in the NB-IoT protocol is the lack of computing power in the devices, which limits the use of cryptographic algorithms on the device, which limits the use of public and private keys when operating. If the Diffie Hellman [49] exchange update key is used, the overall exchange process cannot be authenticated and is vulnerable to Man-inthe-Middle (MitM) attacks. Moreover, the IoT device has limited storage resources, being only able to store small size group keys. If a specific key is not updated over time, using always the same key makes the communications vulnerable to ciphertext-only attacks [50].

Threats
Threats can be defined as actions intended to explore security flaws in a system [51]. Threats derive from essentially primary sources such as human and nature [52,53]. Natural threats are defined by earthquakes, energy flaws, hurricanes, floods, and fire. These types of threats can cause serious harm to computer systems. Security plans against natural threats can be implemented, but it is hard to prevent them from occurring. Human threats happen when people have malicious behaviors against systems, networks, or data. This threats can consist in internal [54] or external [55] sources. Internal threats are normally performed by someone with authorized access, and external threats are performed by groups or individuals outside the network, to sabotage and interfere with the system. Human threats are classified by Unstructured and Structured threats [45]. Unstructured threats are composed principally by inexpert individuals who use simply available hacking tools. Structured threats are composed of persons who recognize system vulnerabilities and can acknowledge, develop and exploit codes and scripts.

Security
Security is one of the main requirements in real-world IoT deployments [56]. Most of the IoT devices share a simple design that is based on the premise that they can be operated remotely and integrated with third-party applications through simple mechanisms [57]. The pressure of releasing a device quickly can, in some cases, lead to skipping non-visible aspects like security and reliability. It is obvious that security concerns are not always considered as part of the IoT device production life cycle, such as hardware and firmware in the bottom layers, but also in higher layers, such as frameworks and applications. Many IoT devices are not supported with the ability to update the firmware/software (i.e., typically cable-based or over-the-air updates), turning them extremely exposed and vulnerable to eventual exploits and attacks [58]. Security must protect services, devices, information, and data, not only during communication but also data storage [45].
To protect privacy, it must be ensured that communication and collected data met the following requirements, as defined in [59-61]: 1.
Confidentiality: transmitted data, communication between endpoints, sensors, and readers are secured and encrypted; 2.
Integrity: transmitted data is accurate and cannot be modified or utilized, by unauthorized users and objects; 3.
Authenticity: transmitted data is genuine, and come from authorized sensors, endpoints, and readers; 4.
Availability: computing resources and information are available when requested by a service.

Attacks and Defense Strategies
In IoT applications such as smart campus, attacks need to be anticipated since this environment is serving the campus community, depending on a wide range of technologies and types of equipment. This normally includes several unsecured devices, systems and applications that communicate information via insecure media and use weak protocols such as HTTP, FTP, telnet [62]. Attacks are activities taken to harm a system or disturb ordinary tasks by exploiting vulnerabilities using different techniques and tools. Attackers launch attacks to accomplish objectives either for individual realization or rewards [45]. An attack could be presented in numerous structures, including network attacks to monitor unencrypted traffic in pursuit of sensitive data; passive attacks, for example, monitoring unprotected network communications to decrypt weakly encrypted traffic and getting authentication data; close-in attacks; exploitation by the users of the system [45]. The attackers can make use of these weaknesses to gain access to the systems, swipe sensitive data, and acquire confidential information for later manipulation [63]. Malicious entities can also harm the devices and stop the functionality of the services [62]. In this document, attacks will be classified into five distinct categories, cf. Table 3. Table 3. Types of possible attacks. Adapted from [62].

Attack Type Description
Physical Attacks targeting hardware components such as device theft or malicious node injection. Software Attacks exploiting systems by using malicious software such as worms, viruses. Encryption Attacks intended to crack ciphered data.

Data Privacy
Attacks where sensitive and protected data are modified, copied without permission or erased. Network Unauthorized access or mapping of the network to impact availability or obtain sensitive information.
The attacks presented in Table 3 could be performed in LPWANs. Regarding this defined set, some mitigation and defense strategies are presented focusing on the previously described attacks. Some of the countermeasures require short modifications on the firmware or the way some technologies, for example, LoRaWAN, transceivers are integrated into an IoT device. Others require modifications to the standard to mitigate the attack vector at the beginning of the problem.

Physical-Related Attacks
If an intended individual gets access to an IoT device or a gateway, without strong hardware security policies, the whole device or even the network may be assumed as compromised. The gateway in LoRaWAN is a single failure point for the network, and it could be manipulated to disconnect hundreds of end-devices [47]. Besides, physical access by malicious entities may compromise the security keys and other data [43]. The messages could be manipulated and sent as if they had been originated from the IoT device, every message passing through it could be intercepted or even the device could be destroyed. If security keys are stolen, the confidentiality and integrity of the message are compromised, because the attacker can intercept, decrypt or forge any messages sent within the LPWAN system [64]. Some types of attacks that can arise are: -Theft of devices: The theft of physical objects helps the intruder to obtain physical access to the systems to perform several attacks that breach people's privacy and disrupt the system's availability and confidentiality [65]. -Social Engineering: This attack aims to manipulate individuals to divulge confidential and sensitive data [66] about the network or the devices. -Sleep Deprivation Attack: This attack aims to increase the power consumption of the IoT device to decrease their lifetime by keeping the devices awake, resulting in more power consumption and forcing the IoT devices to shut down [67]. -Malicious Node Injection: A new malicious IoT device is physically inserted by the attacker between two or more devices to be used as a regular IoT device. It can be used to modify, capture, retrieve, process, and redirect incorrect information to other devices [68]. -Environment: Changing the air temperature (e.g., with a hairdryer). This could trigger an alarm because the values measured by the temperature sensor had dramatically been changed. Using a light cigarette next to a smoke sensor, that could trigger an alarm, c.f. Figure 6. Defense Strategies: End devices should be physically protected to prevent a malicious entity to perform a system reset. This is hard to achieve in different IoT deployment environments. Design changes such as non-volatile memory may preserve the counter value in between resets [69]. Hardware Security Module (HSM) should be implemented. It contains security keys and cryptography functions (e.g., encryption algorithms) and must be tamper-proof to guarantee that the keys are deleted when an attacker tries to extract them. If no HSM is used, the keys have to be preserved in unsafe storage conditions (e.g., simple non-volatile memory) and may be at risk of being extracted by malicious individuals [64].

Bit-Flipping Attack
Bit-Flipping is a common encryption attack, cf. Figure 7, which focuses on obtaining the cipher keys during communications. In LoRaWAN, different research studies have identified a security vulnerability that can lead to a bit flipping attack [70]. The goal of this attack is to demonstrate that the integrity between the network server and the application server is not protected. If the attacker captures traffic, the application server cannot detect if the message is from the attacker or the network server [71]. The network server in practice is usually fixed by a network operator, and because of the infrastructure, the network server is not able to eavesdrop on the application data. The application server in practice usually belongs to application owners. The application server and the network server work together in the process of join procedure and traffic control [72]. LoRaWAN messages are both encrypted and provided with a message integrity check. The cryptographic message integrity code on the payload data and header information is checked and terminated by the infrastructure provider, while the payload encryption using the AppSKey is undone by the application provider [69]. Uplink messages are encrypted and then signed. After the network server receives the messages, it uses the NwkSKey to control the signature. Encrypted messages are received on a network server and then processed on the application server. Between the network and the application server, the data may be transformed during manipulation because the integrity of the encrypted text is no longer controlled when the messages arrive at the application server [73]. This means that in between the infrastructure operator's network server and the IoT solution provider's application server, the data cannot be checked for integrity and authenticity [69]. If an attacker gains access to a network server, he can eavesdrop on the communication between the network and the application server, which can potentially result in a bit flipping attack [71]. Bit flipping attack can be performed in a simple method, but besides simple, it can cause tragic damage even though this attack is not specifically against the cipher itself [73]. In this security attack, it is possible to change specific fields without decryption of the ciphertext [74]. The bit flipping attack is workable in specific encryption modes where a plaintext has the same bit order with a ciphertext [75], cf. Figure 7. An attacker can modify specific fields, just by modulating bits in the same positions of the ciphertext [70]. With this, it is only necessary to change certain fields of the ciphertext, for later when deciphered, the plaintext will be manipulated, cf. Figure 7b).  Defense Strategies: A malicious bit flipping of the sensor values in between the infrastructure operator and application provider is achievable due to the too-early termination of the message integrity code in the system architecture [69]. A secure transmission method between the network server and the application server should be selected and utilized. Since the protocol allows providers to choose the transmission method between two servers, there are numerous decisions, for example, Ethernet, WiFi, 3G. For this situation, since LoRaWAN did not provide any insurance strategy between the two servers, the security between the network server and the application server relies upon the transmission method selected by the provider. Consequently, the application owner should be comfortable with the security of the transmission method and be aware of potential threats [72].
The straight solution to avoid an attack featuring a malicious change of the payload content is to run the integrity check value at the application server and not at the network server. Theoretically, a modern protocol design should implement authenticated encryption instead of simple encryption [69]. Considering the integrity protection, it is better if the protocol can provide end-to-end encryption. Therefore the security between the application server and the network server can be independent of the transmission method. Apart from that, if the transmission method is not secure, the LoRaWAN network is not secure any longer. One strategy to secure the integrity between the network server and the application server is to check the Message Integrity Code (MIC) again when the message arrives at the application server. In the LoRaWAN specification, the MIC is checked in the network server ensuring that the messages received are not modified. After verification, the message is transmitted to the application server, but it does not verify the MIC again. The author [72] suggests that it is necessary for the application server to also check the MIC with NwkSKey to ensure that the message is not modified during the communication between the two servers. NwkSKey is owned by the network server, which in practice, is operated by the network administrator. It would be better if the application server could also have NwkSKey, to be able to calculate the MIC to check the signature.

Jamming Attack
The jamming attack is one of the most serious problems for IoT security [76]. The communication bandwidth is small (100Hz for Sigfox, 125/250/500kHz for LoRaWAN, 180kHz for NB-IoT) and relies on low-power for data transmission [64]. The jammer does not need complex hardware as long as it transmits the jamming signal with enough power. Malicious entities can transmit powerful radio signals near the application devices and interrupt the radio communications, cf. Figure 8, because LoRa transmissions at the same frequency and spreading factor can interfere with each other [48]. This is possible by using commercial-off-the-self LoRa hardware [47].
A low-cost microcontroller-based platform equipped with a LoRa radio module can be used to perform jamming attacks. An attacker with malicious intentions can flood LoRa messages at a certain frequency to clean out all the transmissions in that frequency. According to [47], about 99% of LoRa transmissions are damaged by this jamming technique. Typically, this approach uses low-cost devices (Arduino Leonardo [77] board and a Semtech LoRa radio module [78] breakout board) with a total cost of around 30 euro. Jamming attacks could be pointed to different layers of the OSI model: (1) Physical layer jamming, where the malicious actor assign any wideband signal with a higher Signal-to-Noise Ratio (SNR) than the user; (2) MAC layer jamming, where the malicious actor just jams explicit pieces of the message (e.g., message signatures), guaranteeing that the packet is disposed of by the recipient [64]. Defense Strategies: Defending against jamming attacks is hard because this type of attack is always possible. Initially, the jamming of the entire network or frequency can be easily detected since all the devices that communicate in that frequency would abruptly start to drop out from the network. By recognizing such behavior, network administrators can take appropriate actions to prevent the impact of such attack [43]. Jamming detection mechanisms can also be useful, for example, changing the used frequency channels [64]. Some low-level techniques [80] that should be used are: -Create dense LoRa networks with overlapping coverage regions. By deploying Lo-RaWAN end-devices within the range of different gateways, increases the reliability of LoRa communication. This feature is critical in beating jamming attacks, as to ensure that a message is jammed, the jammer should guarantee it is heard at no gateway in the network. Since the jammer requires high Received Signal Strength Indicator (RSSI) compared with the end-device, the jammer is more effective when it is near the gateway. Subsequently, the jamming is more complex within the presence of various gateways [64], as the attacker must map the gateways in range of each target end-device to successfully jam the transmissions. -Maximize the utilization of channel hopping. LoRa devices hop between multiple channels when sending messages as dictated by LoRaWAN specification, to reduce the opportunity of collisions. The more channels utilized, the more complex the jammer must be, as it needs to listen on all of those channels. This forces a move from basic low-cost LoRa hardware to more expensive multi-channel LoRa receivers as found in gateways. -Move to a higher Spreading Factor (i.e., SF12) to beat the jammer RSSI. The higher Spreading Factors (SFs) require higher dB differentials between the jammer and target message. However higher spreading factor transmissions afford more time for the jammer to act and requires the jammer to be closer to the gateway. Note that numerous transmissions in higher SF rapidly exhaust the duty cycle allowance.
By performing traffic analysis and profiling (at the gateway or server level), it is possible to distinguish varieties in the pattern of incoming messages demonstrating the presence of a jammer and to trigger alerts or adaptations to the network. On the other hand, some application-level [80] techniques that should be addressed are: -When the transmission rate is known, the normal rate of traffic analysis is aware of the sending rate of the LoRa end-devices, it can easily recognize unplanned changes in traffic patterns and respond accordingly. -When the transmission rate is unknown, the typical rate of traffic should be established over time, or through past continuous profiling. Once the baseline rate is understood, it becomes possible to recognize deviations.

Replay Attack
A replay attack is an attack on security protocol, re-sending or repeating the legitimate data transmission by the malicious actor. The primary motivation behind this attack is tricking the device or module by utilizing handshake messages or old data from the network. To perform this attack in wireless networks, the malicious entity should know the communication frequencies and channels to sniff data from transmission between devices [47]. The attacker receives and transmits data exchange between two trusted parties as an authorized unit, which conducts the participants to accept that the transmission of information has been finished. The malicious actor can capture and store a duplicate genuine request to a service, from a specific device in the system. After that, it can be replayed to get services that are only available to authenticated users [62].
For example in replay attack for Activation by Personalization (ABP) activated devices in LoRaWAN, cf. Figure 9, the objective is to accomplish spoofing and Denial-of-Service (DoS). After the attack execution, the server gets a malicious repeat message from the malicious actor's end device, and the server accepts that the message comes from the working end associated device. For end-user devices, the objective is to perform a DoS attack. After the effectively executed attack, the server will not get a message from the enduser devices. The DoS period relies on selecting a rehashed message [71]. For development devices, which often use ABP activation to join networks, it is necessary to consider that this method has security flaws [47]. For ABP enabled terminal devices are utilized static keys, this way after a reset, the keys continue the same as before, they do not change and may be used in future sessions [81]. Afterward, the network server may receive a malicious message that agrees with: (1) the session keys are the same as one accepted end device; (2) DevAddr is the same as one accepted end device; (3) if the counter value is acceptable. As expressed beforehand, the keys are static and the counter values are not utilized securely. For this situation, an attacker can choose and resend messages before the reset, and the server cannot figure if these messages are from this session or the session before the recovery [71]. The LoRaWAN 1.0 protocol states [82] that after a JoinReq-JoinAccept message exchange or a reset for a personalized end-device, the frame counters on the end-device and the frame counters on the network server for that end-device are reset to zero [69]. For this situation, the attacker can use messages from the last session with the high values counters and repeat them in the current session. Whether or not the end device is activated by ABP or Over The Air Authentication (OTAA), it is possible to perform a replay attack [71]. In addition to manually resetting counters on the two sides, the counter overflow is another method of reset. When the counter value reaches its maximum value, the counter is reset and restarts from 0. With counter values from the last session and with the same session keys, the attacker can also repeat past messages to disconnect communications between the end device and the server [71]. This goes for both ABP and OTAA. However, attacking an ABP-activated end device will take less time as both reset and overflow work if the attacker has the ability and opportunity to reset end devices [69].  Figure 9. ABP device exploiting the Replay Attack. Adapted from [79].

Defense Strategies:
The replay attack depends on the perception that the NwkSKey and AppSKey are used as the long-term key material that stays unaltered after a counter reset, rather than being restricted to a single session [69]. To prevent this attack from occurring, the following measures could be taken: End devices should be physically secured to prevent a malicious entity to start a system reset [43]. While this is hard to achieve in an assortment of IoT deployment contexts, design changes, such as non-volatile memory may maintain the counter value in between resets. If the attacker cannot reset the counter by resetting the end devices, the only way to accomplish the attack is to wait for a counter overflow [72]. This change essentially decreases the exposure, however requires an adjustment in the LoRaWAN specification. The end device should change its session keys each time when the counter reaches its maximum value. If the device is utilizing OTAA method, it should experience the OTAA activation procedure again to acquire new session keys. If the end device is using a ABP method, it should be re-configured, and session keys should be changed. For this situation, however, the counter values are reused, session keys will prevent the server from accepting malicious messages. With that, this attack will not be possible. It is inconvenient to manually re-activate and configure an end device each time it overflows. Besides, for end devices situated in a remote area, this mitigation will cost an enormous amount of resources since it should be operated manually. According to LoRaWAN specification 1.0.2, after the device activation or the reset, the frame counters on the end-device and the frame counters on the network server for that end-device are reset to zero [69].
One approach to increase the security level is to remain the counter value in the server after resetting. Thereby, each time an ABP activated end device resets, its counter value will restart from zero while the relating counter value in the server will not be changed. At that point when the end device sends messages to the server, the server will not accept the messages until the counter value of the end device becomes larger than the counter value in the server. This strategy prevents all the messages with reused counter value. With that, resetting ABP activated end devices is pointless for an attacker in the replay attack. The attacker can just accomplish this attack by waiting for counter value overflowing [72].
Another technique is to add a function to end devices. Each time it resets or the counter value reaches its maximum value, the end device should be triggered and then be able to re-activate automatically. Regardless, if the end device is activated by OTAA or ABP in the last session, it should utilize OTAA to rejoin the network. This implies that the end device should experience the "Join request-Join accept" procedure again. This technique is conceivable to be passed automatically [72].
To protect against replay attacks in Sigfox communications, a 12-bit Sequence Number (SN) is used and transmitted with every uplink frame and protected by a specific Message Authentication Code (MAC). If the actual received Sigfox frame contains a lower SN than the latest received frame, the actual frame will be discarded by the Backend Server. The actual algorithm employed to compute the MAC is proprietary, but it applies Advanced Encryption Standard (AES) in Cipher-based Message Authentication Code (CMAC) mode like in the LoRaWAN protocol, with the secret not acknowledged and the 12-bit SN (for uplink messages), as some of its inputs. For downlink messages, there is no public information related to the SN size, which does not allow us to claim that the same security level is achieved when compared with uplink messages [64].

Wormhole Attack
A wormhole is an out-of-band connection between two IoT devices, cf. Figure 10, using wired or wireless links. Wormholes can be used to forward packets faster than via typical paths. A wormhole could not be breach security, for example, a wormhole can be used to forward critical messages where high throughput is fundamental, and the rest of the traffic follows the normal path. Although, a wormhole generated by an attacker and combined with other attacks, can lead to a serious security threat [56].
A classic wormhole attack requires two malicious devices in the network, that is, a sniffer and a jammer. End-devices in LoRaWan can be jammed by using off-the-shelf hardware [47]. Combining with replay attack, a wormhole attack [83] can be performed against the LoRaWAN network. In this kind of attack, one malicious device captures the packets from one device and sends them to another distantly located device to replay the captured packet. This can easily be initiated by malicious actors without previous knowledge of the network or cryptographic mechanism [43]. The sniffer device captures packets and signals to the jammer device, to notify that it captured the packet. The captured packet never reaches the gateway and the captured message stays valid. The captured message can be replayed at any time. As a result, critical alarm messages can be jammed, and regular messages that were previously captured and never reached the gateway can be sent to the gateway, and be forward to the application layer [80]. Since there is no time-related information in LoRaWAN messages [47], wormhole attacks can become a serious security breach and are very difficult to detect particularly when the wormhole is systematically switched on and off [56].  Defense Strategies: A possible solution is to beat jammer response time. Moving to low SF to beat jammer response time. Reducing SF decreases the airtime of messages, which in turn reduces the time the jammer has to reach. This has several expenses, however: (1) Lower SFs have lower reliability and lower range, and (2) Lower SFs require less power output from the jammer to be disrupted. Drop packet size to beat jammer reaction time. Packet size has a significant impact on message air time. Reducing the size of these messages could permit messages to beat the jammer's reaction time [80].
A general mechanism, called packet leashes could be used for detecting and defending against wormhole attacks [43]. Any data appended to the packet for limiting its maximum transmission distance is referred to as leash. These are designed to protect single wireless transmissions from wormholes. In this case, if the packets are transmitted over several hops, another new leash is required for each transmission [85]. A leash is any information that is added to a packet designed to limit the packet's maximum permitted transmission distance. There are two distinguish leashes, namely, geographical and temporal leashes. A geographical leash guarantees that the recipient of the packet is within a certain distance from the sender. A temporal leash guarantees that the packet has an upper bound on its lifetime, which restricts the maximum travel distance since the packet can travel at most at the speed of light. Each type of leash can prevent the wormhole attack since it allows the receiver of a packet to distinguish if the packet traveled further than the leash permits [83].

Denial of Service Attack
DoS is a popular cyber-attack in computer networks [86]. It consists on the deliberate interruption of network connectivity, making services inaccessible to applications and users. DoS attacks consist in flooding the specific target-a server or other computational entity-with superfluous requests, that prevent IoT devices from obtaining access to specific services [67], which are typically delivered by Software-oriented Architectures (SoA) or microservices architectures. When the attack is accomplished, the system's processing power gets compromised and is loaded with numerous spam requests that result in a system overload with a high likelihood of crashing. This attack can be achieved through distinct methods, being the most commonly known as botnets and buffer overflow attacks [87]. Although not so common, Distributed-Denial-of-Service (DDoS), cf. Figure 11, is considered as one of the most dangerous DoS attacks. In this type of attack, the malicious entities use thousands of Internet Protocol (IP) addresses to request IoT services, making it difficult for the server to distinguish legitimate DoS devices from attacks [88]. The most common victims of this type of attack are, typically, high-profile organizations such as banking and government, that rely on highly confidential information. DoS attacks can take a lot of time to resolve, result in high monetary losses, and, in the worst case, cause data loss for the organization [87]. Defense Strategies: This type of attack can be recognized with the use of signaturebased detection (known as rule-based or misuse-based Intrusion Detection System (IDS)). This technique consists of comparing known attack signatures-that is, patterns, malicious instruction sequences used by malware (such as specific byte sequences-with the monitored network traffic, where a match generates an alarm that signalizes a potential attack. The response is characterized by a fast detection time and high detection rate, and gener-ally, has a low false-positive rate. Signature detection is based on well-known DoS attack patterns, which are frequently detected as protocol attacks and malformed packets. Another technique is to use anomaly-based IDS (known as behavior-based detection). Operates by comparing the network traffic behavior against previous normal traffic. Any deviation in the comparison is an indication of an attack. The system acquires a normal traffic profile through training and monitoring the traffic against any differences with the normal profile. However, it generally produces higher false-positive rates than signaturebased systems [89].
In [90] the proposed DDoS attack prevention mechanism uses a cloud-based Softwaredefined Networking (SDN) framework, and machine learning for attack detection. A semisupervised machine learning algorithm is used for blacklisting malicious devices and filters the traffic using OpenFlow switches and an SDN controller.
Another solution is to use SDN-based honeypots. Honeypot is a computer security mechanism that is used to detect, deflect, or counteract attacks. It has positive effects in defending against DDoS attacks on the Internet [91]. The SDN controller is used to mimic IoT nodes in the network to attract the attackers. The SDN controller changes the address of the devices while mapping it to their original addresses, making it difficult for the attackers to find the active devices to attack [42].

Attack Vectors in the IoT Ecosystem
The Internet of Things ecosystem is presented as an integrative model in which plenty of the objects around us are expected to be networked and connected to the Internet to arrange new types of services and increase its efficiency [92,93]. This type of device can improve the execution of our daily tasks, but the increasing connectivity and computational power of such devices result in a natural increase of related vulnerabilities (hardware, firmware, communications), which can be exploited and therefore increase the probability of being attacked. Additionally, some Internet of Things devices can be classified as security-critical and their malfunction can lead to irreversible harm to the physical system being controlled and to the users who depend on it [94]. The main activities stage of an IoT application includes data acquisition, data processing, data storage, and data transmission [11].
Generally, the IoT ecosystem includes a physical environment where the device is deployed to perform some specific function (i.e., operate as a sensor or actuator), which communicate through a LPWAN up to the cloud, where data is then pre-processed and aggregated for analytics on the business side of the network. However, there are several constraints and challenges associated with the design, development, and deployment of IoT applications, which include limited resources, interoperability, device heterogeneity, and security. Additionally, many companies tend to accelerate the development of their products, often leaving security behind [95]. This may cause several security issues in the IoT ecosystem, such as backdoors that are inadvertently created in the design and development stages.
Therefore, due to the pervasiveness of IoT technologies, its designers and developers must reinforce security into applications and devices from scratch, rather than chasing the loss. Given this, it is crucial to have a specific and precise set of attack vectors to easily put forward a strategy to better respond to increasing threats that affect the overall IoT ecosystem. This approach will ensure that vulnerable points are identified in a general architecture and specific responses are used to prevent an attack or to mitigate its impact if it occurs. Thus, it is relevant to describe in detail all the attack vectors and provide, for each of them, a defense strategy. To systematize this environment, a set of attack vectors for LPWAN-based IoT applications is proposed in Figure 12, which includes three different communication networks, namely LPWAN, Backhaul Network, and Internet, of which, different types of malicious attacks can be put forward. In the attack vectors set, IoT devices are represented by a bicycle and a temperature sensor, that communicate using LPWAN technologies. These communications are carried out wirelessly to the LPWAN gateways, which are connected using a backhaul network with the LPWAN server. This architecture is common to those found in technologies like LoRaWAN [96][97][98][99][100][101], Sigfox [102][103][104] and NB-IoT [50,64,105]. The gateways form the bridge between IoT devices and the LPWAN server through a backhaul network. In turn, the LPWAN server uses an internet connection (typically over HTTPS) to the Cloud/Analytics Services to process the data transmitted by the IoT devices. After processing, information is transmitted using an internet connection (typically over HTTPS) to client applications on the business side.  As described in Figure 12, a malicious agent, typically, can explore six different attack vectors, which may represent, the physical environment, infrastructure elements (such as gateways), communication networks and protocols, and network servers. Table 4 compiles and maps the attacks identified in Section 3 to the attack vectors depicted in Figure 12, respectively, with focus on the physical environment, where IoT devices are deployed, and in the LPWAN and backhaul networks.

Discussion
In the systematic review, it is possible to verify that all the defined keywords and the approach used to compile the results, cf. Figure 5, make this analysis more simple and intuitive. From the results obtained, it is possible to observe that the LPWAN protocols with most related-works are LoRaWAN and NB-IoT.
The technology that ranked higher was LoRaWAN, due to its higher penetration in academia.
However, this does not guarantee that these are the most used protocols in LPWAN, but rather, the protocols that have been more used in research and development, due to their higher maturity and openness to researchers in academia. The major limitation of our approach is the fact that only the IEEEXplore database was used, which despite being the most suitable in terms of using elaborated queries to the research, ends up restricting this research. Furthermore, the application domains in which more results were also obtained, it was in the context of "smart monitoring" that resulted in 60% of the responses (among the contexts "smart campus", "smart environment", "smart monitoring"). This may reveal, for example, that the "smart campus" environment is still under the process of developing and implementation on new application contexts that make use of the type of LPWAN technologies. In our perspective, this may be because smart campus environments have a high number of users daily pending, and eventually, devices connected to the network, which may originate a wide spectrum of possible threats to this type of network.
In this research, it was possible to identify the most relevant types of attacks, vulnerabilities, threats, and possible defenses regarding LPWAN technologies. Some of the attacks were identified individually, giving a detailed description of how they can be exploited and carried out. After identifying the main focal points of the identified attacks, the research was carried out to find possible solutions to protect, mitigate or even eliminate these security weaknesses. Moreover, it was crucial to relate the attacks and vulnerabilities analyzed in the State-of-the-Art review, with these types of technologies, creating a connection in this document. Most of the described attacks are present in LoRa technology. In total, five different types of attacks were identified, which exploit certain vulnerabilities found in this sort of technology. Furthermore, some responses that could be adopted have also been identified to mitigate these threats. One of the main solutions is to update the LoRaWAN protocol to its latest version 1.1, which already has some security improvements compared to its older versions. LoRaWAN v1.1, officially released in October 2017, has been a big upgrade to the specification of the protocol. Concerning the entire network architecture, LoRaWAN v1.1 presents mechanisms such as handover roaming [106] of the end devices such that the Network Server can act according to different roles specified, and a new security architecture which includes the Join Server which allows the end devices to connect to the network [73].
Since Sigfox devices are not IP-addressable, the likelihood of being attacked is reduced, since there is no OTAA mechanism, such as in the LoRaWAN protocol. In Sigfox communications, a user can decide whether to encrypt the message using the encryption solutions provided by its proprietary infrastructure, or by using their encryption methods if necessary [43].
After conducting the research regarding security vulnerabilities in LPWAN, a set of attack vectors for a generic IoT application was introduced, which presents common security flaws that may arise in a general application case. In this work, the focus was on the LPWAN and Backhaul communication zones, although the Bit-Flipping attack can be performed between the network server and the application server. With the elaboration of each attack vector, it is possible to obtain a vision of the critical zones where a possible attacker can initiate a malicious action. These attack vectors are related to the state-ofthe-art review done previously, so it is possible to identify vulnerabilities as well as the respective defense strategies, to implement changes to mitigate or avoid these security breaches. One of the weaknesses of the current set of attack vectors can be the fact that the entire communication path between the IoT devices and the client application, has not been fully explored. Security flaws may exist on the application server-side, or even, in the client application. Six different scenarios of possible malicious interactions were presented and mapped with the identified attacks described in the state-of-the-art review. However, all the scenarios developed have a brief description, as well as possible attacks that can be carried out with a set of references that justify them. It is possible to create a link between the set of attack vectors analyzed and the state-of-the-art review.
The technology that obtained most of the attention from academia, regarding security, was the LoRaWAN protocol. This can be observed by the fact that the majority of the attacks identified and described during this study focus on the LoRaWAN technology, with fewer works related to other LPWAN technologies, such as NB-IoT and Sigfox. With the vulnerabilities described and the types of attacks identified, we found it pertinent to propose an attack vector analysis to systematize and map these security flaws to the IoT ecosystem, whose main goal was to depict the most vulnerable points that must be considered, when designing IoT applications that rely on LPWAN technologies.
With the development of the defined attack vectors, it is possible to obtain a visual notion that demonstrates in which part of the communications, the possible attackers will be able to perform their malicious intentions. This makes it easier to identify where some improvements and security suggestions may arise in LPWAN-based IoT applications. With this type of approach, it was possible to realize that the identified vulnerabilities, can be achieved in several application contexts where distinct users are involved in various tasks performed throughout their daily activities.

Conclusions
This work presents an overview of the evolution of LPWAN communication technologies over the past 10 years. It also identifies some types of security breaches arising from the use of these communication technologies, as well as defense mechanisms and techniques to mitigate them. Finally, a set of attack vectors are described and analyzed in the context of LPWAN-based IoT applications. The attacks are mapped in the security vulnerabilities identified in the previous state-of-the-art review.
Based on this research, it was possible to conclude that LPWANs technologies had a spontaneous growth over the past years, as well as discovered and exploited security flaws. It is also possible to verify that most of the results obtained were about LoRa and NB-IoT technologies. Then a state-of-the-art review that focused on the most prominent results that have been found in the systematic review was conducted on possible threats, vulnerabilities, attacks, and the designated responses to mitigate these weaknesses in this type of technology. Lastly, a set of attack vectors for a generic IoT application was elaborated and analyzed, presenting some possible security breaches that may arise. These security weaknesses were mapped with the security flaws that have been found during the state-of-the-art review. This analysis and results demonstrate that LPWANs contain security vulnerabilities that can be exploited by malicious entities. Funding: This work is a result of the project TECH-Technology, Environment, Creativity and Health, Norte-01-0145-FEDER-000043, supported by Norte Portugal Regional Operational Program (NORTE 2020), under the PORTUGAL 2020 Partnership Agreement, through the European Regional Development Fund (ERDF).
Institutional Review Board Statement: Not applicable.

Informed Consent Statement: Not applicable.
Data Availability Statement: Not applicable.

Conflicts of Interest:
The authors declare no conflict of interest.