# A Survey of LoRaWAN for IoT: From Technology to Application
## 6 MAC Layer Performance Evaluation
### Security
In between the network server and application server, there is no means of message integrity check. This will expose the data packets to bit flipping attacks, and they can go undetected. This vulnerability exists in both standards. In [90], security analysis of join procedure in LoRaWAN is studied. The current implementation of DevNonce random generation in the WiMOD SK-iM880A is done by performing 16 read operations of the least significant bit (LSB) of the register RegRssiWideBand. Under jamming conditions, this register might be overflowed, resulting in the same value all the time. Thus, in [90], authors evaluated the probability for the end node to generate the same DevNonce during an interval of generated join-requests. To avoid the DoS mistaken cases (for LoRaWAN v1.0), authors of [90] proposed using a sequential number as DevNonce, by keeping track of the last DevNonce used at both ends. This feature is already included in specifications for LoRaWAN v1.1 [11]. However, this approach might be vulnerable to attackers that can easily predict the next DevNonce. In [91], the join-request packets RSSI values are tracked by the network server in addition to previous DevNonce used. If a join-request packet with the same DevNonce is received, the RSSI value is checked to categorize if the join-request packet is replayed by an attacker or not. However, for mobile nodes such an approach does not work as the RSSI value will change by node position. In such a case, a packet send by a mobile node mistakenly will be categorized as a replay attack. In [92], a hybrid cryptosystem to enhance LoRaWAN v1.0 join procedure security is presented. An asynchronous cryptosystem is implemented in addition to current synchronous cryptosystem. This means that end node will request the network server public key before it sends the join-request packet. Then the end node will first transmit the AppKey encrypted join-request packet and NS public key encrypted of the AppKey information. The network server will decrypt the join-request and reply with the join-accept packet [92]. However, even though this method is secure and avoids replay attacks, it requires additional handshakes in the join procedure that will decrease the bandwidth for the end node. Bandwidth shortage will become even more severe for bands and regions where duty cycle is required. Another approach to prevent replay attacks is a token-based approach shown in [93]. The join-request packet is masked by a unique token using an XOR operation. Thus, even if join-request packets are intercepted by an attacker, they cannot be used as they are masked with different tokens. Tokens are generated from the previous NetSKey. However, such a method is still vulnerable in cases when end node forgets the previous NetSKey due to reset or any other action. To avoid such an issue, in [94], join-request packets are divided in initial ones and non-initial ones. An initial join request is sent in case when end device does not have any previous NetSKey saved. For non-initial join-request packets, MIC is generated using previous NetSKey. To alleviate the data packet replay attacks, in ABP the NetSKey and AppSKey should not be static. There should be a mechanism that changes the keys every time the node is reset [87]. Such an approach is now adopted in the newest standard where rejoin procedure is introduced every time the node is reset or before the overflow of counters. Table 7 collects all the research and their studied security aspects together with the offered solution.