# Security Risk Analysis of LoRaWAN and Future Directions
## Security Challenges of LoRaWAN v1.1
### Implementation Related  
In this section, we discuss potential implementation related vulnerabilities. These vulnerabilities generally occur due to mistakes during application development or installation, when developers fail to follow the specification document closely, due to its complexity or difficulty to put into practice:  
(a) Exit procedure related  
This is an important procedure to be used for decommissioning of the end-devices after their license ends or they are thought to be compromised and wanted to be cut-off from the network. Here is what is stated in the specification document related to the exit procedure for the end-devices: \"The procedure used for deactivating the session is the Exit Procedure, which is the counterpart of the Join Procedure. There is no explicit and dedicated LoRaWAN signaling for performing the Exit Procedure. It is assumed that the End-Device and the backend rely on application-layer signaling to perform this procedure. Triggers and the details of application-layer signaling are outside the scope of this specification.\" The definition expects exit procedure to the handled by application-layer programming. It is apparent that there is a lack in the standard definition related to the exit-procedure and this might cause complications during the long-term operations. For example, an exit procedure of an end-device should result in with the termination of all IDs, passwords, counters, and nonces related to that specific end-device permanently. Application-layer programmers are strongly advised to be very careful not skipping the inclusion of exit procedures for decommissioning purposes.  
(b) DevEUI related  
_DevEUI_ must be stored in the end-device before the Join procedure is executed during OTAA. _NS_'s hold a list of _DevEUI_'s used throughout the lifetime of the network. Although there exists a procedure to renew the _DevAddr_, the procedure for revoking or renewing _DevEUI_'s is not provided in the specification document. This is somewhat related to the _Exit procedure_ described in the previous paragraph and should be included explicitly within the specification for the next release.  
(c) Frame counters related  
This is a particularly sensitive implementation area both for the end-device and servers. In the past (shown in the literature by [PERSON] et al. [27]), security flaws have risen from mishandling counters. In the specification of LoRaWAN v1.1, the following is stated: \"For OTAA devices, Frame counters must not be re-used for a given key, therefore new Session Context must be established well before saturation of a frame counter. It is recommended that session state is maintained across power cycling of an end-device. Failure to do so for OTAA devices means the activation procedure will need to be executed on each power cycling of a device\" [16]. The mentioned situation requires saving the frame counters to permanent memory in a timely manner.  
(d) JoinEUI related  
_JoinEUI_ must be stored at the end-devices before starting the OTAA procedure. This means that, any possible change of the Join Server which might required an _JoinEUI_ change, would affect all previously loaded end-devices. All of these devices would be useless hence, there is no JoinEUI renewal procedure is defined. In the current version, Join Server is assumed to continue using the same _JoinEUI_ for the whole lifetime of the network.  
(e) Secure Storage related  
In the specifications, it is mentioned that, besides root keys (_NwkKey_/_AppKey_ pair), all session keys need to be stored in a \"secure-way\", so that extraction and re-use of these keys by adversaries would be prevented. It is possible to secure non-volatile memory of the end-devices with the cost ofhardware supported tools such as SE or HSM; however, to our knowledge, the security of volatile memory is not hardware-supported and a challenging task from software implementer point of view.