# Security Risk Analysis of LoRaWAN and Future Directions
## 3 Introduction to LoRaWAN v1.1  
Figure 1 shows the network architecture of LoRaWAN v1.1, which is in line with the specifications. Here, as might be seen, a new server called \"Join Server\" is introduced to orchestrate the OTA procedure in a more secure way. Besides, with this latest version, instead of single NS, there are three  
NS's introduced: \"home\", \"forwarding\" and \"serving\". The rationale behind this inclusion is to enable roaming of the devices citywide, countrywide or from a higher perspective worldwide.  
As in the case of LoRaWAN 1.0, the end-nodes and GW's are connected with \"star\" topology, and the rest of the network including GW's and servers are connected to each other via \"fully-connected mesh\" or \"partially-connected mesh\" topologies (most preferably connected via fiber optics), which is beyond the scope of this manuscript.  
Readers who are more interested in the details of how LoRaWAN v1.1 refers from v1.0, may refer to [35]. There, a comprehensive comparison table is provided to enlighten readers about what changes are introduced with the new version, especially from the security point of view (new keys, nounces, frame counters, etc.).  
To participate in a LoRaWAN network, each end-device has to be personalized and activated. Activation of an end-device can be achieved in two ways, either via Over-The-Air Activation (OTAA) or via Activation By Personalization (ABP).  
_JoinEUI_ (new) is the unique identifier of the Join Server and it is embedded into the end-devices during fabrication. This identifier is used during Join procedure. _JoinEUI_ is required by only OTAA. _DevEUI_ (new) is the unique identifier of the end-devices, and will be labeled (this label should be kept with the device, or otherwise the DevEUI number on it should be saved) on the end-devices during fabrication. In OTAA _DevEUI_ is required but for ABP _DevEUI_ is recommended.  
_AppKey_ and _NukKey_ (new) are the AES-128 bit root keys from which the session keys are generated. These root keys are specific to each end-device and therefore they are embedded into the end-devices during fabrication too. The root keys are required during OTAA, and not for ABP.  
According to specifications, these root keys (_AppKey_ and _NukKey_) need to be stored in a hardware-secure way, e.g., by using tamper-proof/resistant memory elements such as Secure Elements (SE) or Hardware Security Modules (HSM).  
AppSKey (see Figure 2) is the session key used between an end-device and the Application server, generated from the root key of _AppKey_. This key is used to encrypt/decrypt Application layer payloads. _AppSKey_ is specific to each end-device. NS's are considered as trusted parties to honestly transmit these encrypted messages to each end. _AppSKey_ should be kept secret from outsiders by storing it in a secure way.  
From root key of _NukKey_, several session and lifetime keys are generated (see Figure 2) as described in detail below. Besides, several new counters and parameters are used in v1.1, therefore following subsections are dedicated to an explanation of those.  
Figure 1: LoRaWAN v1.1 network architecture layout.