# Security Risk Analysis of LoRaWAN and Future Directions
## 2 Related Work  
[PERSON] and [PERSON] of Gemalto stressed out a problem with LoRaWAN's key provisioning method [19]. In the LoRaWAN v1.0, the Network Server (_NS_) generates both session keys: the _networksession key_ to be used by \(NS\) and the _application session key_ to be used by the Application Server (\(AS\)). As the authors mentioned, this would cause a conflict of interest between the network server and the application server. As a solution to this problem, the authors proposed a new LoRaWAN network structure with a trusted third party such as Public Key Infrastructure (PKI). In [20], [PERSON] et al. describe security problems of LoRaWAN v1.0 regarding the _DevNonce_, used during the Over-The-Air-Activation (OTAA) procedure in which the end-device \"joins\" the network via \(NS\) (_join_request_ and _join_accept_ messages). To prevent replay-attacks during the _Join-Request_, a randomized number (_DevNonce_) is included in the message by the end-device so that the \(NS\) can control whether the _DevNonce_ appended to the message has been used by the same end-device already. However, these nonces are produced by using a random-number-generator with limited capabilities such as a limited pool of numbers (each time a number from this pool is selected randomly, the probability of selecting the same number increases as time advances), which might end up with repeating itself after some certain usage time. Accordingly, the authors deduce that, with some special kind of jamming techniques, these _DevNonce_ number pool can be diminished in a short period of time. As a result, after then, all of the _join_request_ messages from the end-device would be denied by the \(NS\). The _DevNonce_ of LoRaWAN v1.0 has been analyzed by also [PERSON] [21]. The author has shown mathematically that with the _DevNonce_ generation system of LoRaWAN v1.0, the end-devices can be unavailable with a certain probability. Author has proposed that increasing the size of the _DevNonce_ field to 24-32 bits would mitigate this problem. Luckily, _DevNonce_ generation is no longer needed in LoRAWAN v1.1, because the new mechanism issues counting numbers for the nonces, which are seriously tracked to prevent replay attacks [16]. In the proposed LoRaWAN v1.0 security architecture of [PERSON] et al. [22], proxy nodes are used, which perform several other functions, including the basic function of the conventional LoRaWAN v1.0 gateway. However, the authors do not provide details of how to incorporate these proxy nodes into the existing LoRaWAN v1.0 architecture without causing any problems in the nominal operation. [PERSON] [23] has presented LoRaWAN v1.0's possible vulnerabilities and related countermeasures. His findings revealed that the vulnerabilities can occur in the phases of key management, communications, and network connection. [PERSON] and [PERSON] [24] proposed a dual key-based activation scheme to tackle various security problems related to the root key of _AppKey_ in LoRaWAN v1.0. One of their proposals is the usage of a second root key, to separate the generations of application and network session keys from the same root key. This proposal is, to a certain extent, implemented in the latest version of LoRaWAN(v1.1). [PERSON] et al. [25] claimed that the join request message sent by the end-device to the NS during the OTAA procedure is not encrypted and vulnerable to replay attacks. They have proposed a remedy to prevent this kind of attack. However, in the LoRaWAN, NS is keeping the list of used DevNonce's and automatically protects the network from the bad implications of the replay attacks. Disregarding the version being used for LoRaWAN, the network might be vulnerable to intra-network interference [26] as well as the jamming attacks, due to the communications through open air. The potential risk is not as serious as in the other narrow-band wireless technologies. This is because the CSS modulation of the LoRa technology spreads the use of the channels to a wider band.