# A Complete Key Management Scheme for LoRaWAN v1.1 +
## 4 LoRaWAN v1.1 Security Structure Analysis
### Pre-Operational Stage  
The generation and distribution of the secret keys of LoRaWAN v1.1 are closely related to its network join procedure. Before joining the network, the following items are pre-installed in the LoRa devices. * For OTAA devices: JoinEUI (it is a global unique join server identifier (I.D.) in Institute of Electrical and Electronics Engineers (IEEE) Extended Unique Identifier (EUI) 64 bits address space). DevEUI (it is a global unique end device I.D. in IEEE EUI 64 bits address space). Device's 128 bits AES root keys AppKey and NwkKey (both keys are essential to derive the group session keys). * For ABP devices: No join procedure is required due to the device with pre-stored the four session keys (FNwkSIntKey, SNwkSIntKey, NwkSEncKey and AppSKey). Hence, the key generation and distribution procedures are not needed. In addition, in the OTAA case, the LoRa device sends a Join-Request message to the network server, and then the join server handles the message. As shown in Table 2, the Join-Request message contains the 1 byte MAC Header (MHDR), 8 bytes JoinEUI, and 8 bytes DevEUI of the end device information followed by a 2 bytes Device Nonce (DevNonce) and a 4 bytes Message Integrity Code (MIC). The DevNonce is to ensure that the message is free from replay attacks. Since the DevNonce is a counter starting from zero and counting up at each Join-Request, it cannot be reused for the same JoinEUI. Hence, the network server can keep track of the last DevNonce value used by the end-device, and ignores the Join-Request message, if DevNonce is incorrect. Although the Join-Request message is not encrypted [16], the data integrity can be ensured by using the Message Integrity Code (MIC) value. The MIC is calculated in (1) as the first 4 bytes of the Cipher-based Message Authentication Code (CMAC) code [16],  
\[MIC=cmac[0..3] \tag{1}\]  
where the CMAC code is given as,  
\[cmac=aes128\_cmac(NwkKey,MHRR|JoinEUI|DevEUI|DevNonce) \tag{2}\]  
the aes128_cmac in (2) represents an authentication algorithm based on Cipher-based Message Authentication Code (CMAC) with the 128 bits AES. The network server confirms with the join server once it receives the Join-Request message. To check if the end-device is authentic, the join server examines the DevEUI and MIC to see if they are matched. Once the device is determined to be legitimate, the join server sends a JoinNonce. The JoinNonce is a device-specific counter value incremented with every Join-Accept message, so the value never repeats itself. It can be used to prevent \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Size (Byte)** & **1** & **8** & **8** & **2** & **4** \\ \hline Join-Request & MHDR & JoinEUI & DevEUI & DevNonce & MIC \\ \hline \hline \end{tabular}
\end{table} 
Table 2: Join-Request message. replay-attacks on the paired network server. After the JoinNonce, the network server sends a Join-Accept message. As shown in Table 3, the Join-Accept message consists of a 1 byte MHDR, a 3 bytes JoinNonce, a 3 bytes network identifier (NetID), a 4 bytes end device address (DevAddr), a 1 byte DLSSettings field (providing downlink settings), a 1 byte delay time between transmit and receive window (RxDelay) and finally, a 16 bytes optional list of network parameters (Channel Frequencies) that the end device is joining (CFList), as well as a 4 bytes MIC at the end of the message. The end device is able to derive the network session keys (FNwkSIntKey, SNwkSIntKey, and NwkSEncKey) and the application session key (AppSKey) once the JoinNonce is received. The root keys (NwkKey and AppKey) are only stored in two places, the end-device, and the join server. The root keys are only valid for the lifetime of the end device. Moreover, the root keys are never be sent or received over the air.