# A Complete Key Management Scheme for LoRaWAN v1.1 +
## 4 LoRaWAN v1.1 Security Structure Analysis
### Operational Stage  
#### 4.2.1 Key Usage  
The LoRaWAN v1.1 supports the backward capacity, which makes LoRaWAN particularly vulnerable when the network operator is acting as the join server. It can happen when the join server is absent. The operator, in this case, has the knowledge of the NwkKey, which enables him to decipher the network session key and the application session key in v1.0 [16]. If the join server is absent, the network server only supports the version below LoRaWAN v1.1, the AppSKey derivation given as [16],  
\[AppSKey=aes_{128 encrypt}(NwkKey,0\times 02|JoinNonce|JoinEUI|DevNonce|pad_{16}) \tag{7}\]  
Therefore, the latest LoRaWAN protocol must be implemented to ensure the system that has maximum security. \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline
**Size (Bytes)** & **1** & **3** & **3** & **4** & **1** & **1** & **16** & **4** \\ \hline Join-Accept Message & \multirow{2}{*}{MHDR} & \multirow{2}{*}{JoinNonce} & \multirow{2}{*}{Home\_NetID} & \multirow{2}{*}{DevAddr} & \multirow{2}{*}{DLSettings} & \multirow{2}{*}{RxDelay} & \multirow{2}{*}{
\begin{tabular}{c} CFList \\ (Optional) \\ \end{tabular} } & \multirow{2}{*}{MIC} \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Join-Accept message. (a) Confidentiality  
The content of the data transmission is covered by the payload encryption. The MAC frame payload is encrypted using AES 128. The keystream(S) generation and the payload encryption/ decryption are detailed as follows [16]. For each data message, a sequence of Ai blocks is defined by the algorithm for i = 1,...,k, as,  
\[Ai=(0\times 001|0\times 004|Dir|DevAddr|FCntUp or NFCntDwn or AFCntDwn|0\times 00|i) \tag{8}\]  
where Dir in (8) is the direction field with 0 value indicating uplink frames and 1 for downlink frames. The k value is determined as,  
\[k=ceil(len(pld)/16) \tag{9}\]  
where  
\[pld=FRMPayload. \tag{10}\]  
The Frame Counter UP (FCntUp) is the counter for uplink from the device to the network server, and the Network Frame Counter Down (NFCntDown) is the counter for the downlink from the network server to the device. The Application Frame Counter Down (AFCntDown) is used for all other ports. Then, a sequence S=S1 1S2 1... 1 Sk of Si(i = 1..k) blocks is produced from the encrypted blocks Ai,  
\[Si=aes_{128}encrypt(K,Ai) \tag{11}\]  
where the key K is either NwkSEncKey or AppSKey depending on Port Field (FPort) setting. After that, the payload encryption (or decryption) is performed by truncating the sequence S xor (exclusive or) with the (pld! pad16), where pld is the frame payload. (b) Message Integrity  
The Message Integrity Code (MIC) is calculated to ensure data integrity by preventing the replay and bit-flipping attacks. It is checked by the network server and the end-device to make sure that the message is not altered by any third party. If the MIC value is incorrect, the relevant party discards the message. \(\bullet\) For Downlink Message [16]:  
\[cmac=aes_{128}cmac(SNwkSIntKey,B_{0}|msg),MIC=cmac[0..3] \tag{12}\]  
where \(aes_{128}cmac()\) in (12) is an authentication algorithm using Cipher-based Message Authentication Code (CMAC) with the 128-bit Advanced Encryption Standard (AES). \[B_{0}=(0\times 49,ConfFCnt,2\times 0\times 00,Dir=0\times 01,DevAddr, AFCntDwn or NFCntDwn,0\times 00,len(msg)) \tag{13}\]  
Confirmed Frame Counter (ConfFCnt) is the counter value modulo 216 of the confirmed uplink frame, apart from that the ConfFCnt = 0x0000. \(\bullet\) For Uplink Message [16]:  
\[B_{0}=(0\times 49,0\times 0000,2\times 0\times 00,Dir=0\times 00,DevAddr, FCntUp,0\times 00,len(msg)), \tag{14}\]  
\[B_{1}=(0\times 49,ConfFCnt,T\times Dr,T\times Ch,Dir=0\times 00,DevAddr, FCntUp,0\times 00,len(msg)) \tag{15}\]  
where TxDr is the uplink data rate, TxCh is the index of the transmission channel.