# Security Vulnerabilities in LPWANs--An Attack Vector Analysis for the IoT Ecosystem
## 3 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 [PERSON] [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].