# A Survey of LoRaWAN for IoT: From Technology to Application
## 6 MAC Layer Performance Evaluation
### Security  
For every IoT application, security is a fragile part. Thus, security issues for each newly IoT technology have to be investigated from the early stage of deployment. Even though LoRaWAN is rather new IoT technology, in the first standard release [9], basic security principles were founded. With the newest standard release [11], security is improved by introducing new method for security key generation for OTAA, and re-joining mechanisms. In Section 2.2.2, we give a detailed description \begin{table}
\begin{tabular}{c c c c c} \hline \hline
**Study** & **Model** & \multicolumn{3}{c}{**Traffic Type Considered**} \\ \hline  & & **Uplink Only** & **UL ACKed** & **Downlink** \\ \hline
[79] & Mathematical & Yes & Yes & No \\ \hline
[80] & Empirical & Yes & No & No \\ \hline
[82] & Simulation & Yes & Yes & No \\ \hline
[83] & Empirical & Yes & No & No \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Power consumption modeling for LoRaWAN. of security mechanism in LoRaWAN for both standards. Here, we describe the vulnerabilities in both standards as both are being used. Numerous research works showed the security vulnerabilities in LoRaWAN v1.0 [84; 85; 86; 87; 88; 89]. Considered security vulnerabilities include the replay attack of join-request packet for OTAA, data packet replay attack in case of ABP, eavesdropping of data packets in ABP case, bit flipping attack between network server and application server, ACK spoofing, etc. Replay attacks (join-requests packets in OTAA or data packets in ABP case) can end up in Denial of Service (DoS) for certain end nodes. In OTAA case, DoS attacks can happen if the network server will decide to exclude the device from the network due to wrong join-request packet. There are two cases: a join-request packet sent by a trusted node can be mistakenly categorized as a replay attack (due to system generation of DevNonce in LoRaWAN v1.0) or there will be a real replay attack. For LoRaWAN v1.1, the DevNonce is a counter number and no longer random. This will ensure that end node will not produce the same DevNonce for different join-request messages. LoraWAN v1.0 standard specifies that if the uplink or downlink frame counters differ from the last counter at the receiver side, and the difference is greater than a specific value MAX_FNCT_GAP, the subsequent data packets from that node will be discarded. As in ABP end node uses static NetSKey and AppSKey, a data packet replay attacks can lead to DoS due to this feature of the standard. What a malicious node can do is to intercept an uplink data packet and wait for end node reset or counter overflow. Once the counter is reset, the malicious node can replay a packet with higher counter that will lead to higher MAX_FNCT_GAP and thus to DoS for that node from the network server. The replayed packet is still valid as the NetSKey and AppSKey did not change after the node reset. This vulnerability exists only for LoRaWAN standard v1.0, as in LoRaWAN standard v1.1 the MAX_FNCT_GAP concept is removed and even in case of replay attack the DoS will not happen. Eavesdropping of two different packets with the same counter will lead to decryption of data packet payload by the malicious node. This can happen once the end nodes is reset, or the packet counter is overflowed. As data packets payload are encrypted using AES in counter mode, and, moreover, the packet counter value is used as input, decrypting the sniffed data packets using the same counter is trivial. This is shown in [87]. In the case of OTAA with the newest version of LoRaWAN v1.1 [11], counters are not allowed to be used during the same activation session. After every reset or before the counter overflow, end node must perform a re-joining process [11]. However, the vulnerability is still valid for ABP case. The network provider is separated from the application provider in LoRaWAN networks. Message integrity check (MIC) of the data payload and header information is done at the network server, while the payload decryption using AppSKey is terminated at application server.