# Insights into the Issue of Deploying a Private LoRaWAN
## 4 Experimental and Analytical Results
### Security Evaluation
#### 4.2.3 Security Improvements in LoRaWAN(tm) 1.1 Specification  
The specification 1.1 [10] released in 2017 and LoRaWAN(tm) Backend Interfaces 1.0 Specification [17] enhance the security in several ways and reflect many security issues discovered in the previous version of LoRaWAN standard. The security improvements and differences are as follows:  
**Key establishment:** The LoRaWAN specification 1.1 offers a preshared symmetric key approach and OTAA and ABP procedures to derive session keys. However, LoRaWAN 1.1 adds another AES-128 root key, called NwkKey, which is used to derive the FNwkSIntKey, SNwkSIntKey, and NwkSEncKey session keys. This key may be shared with a network operator in order to manage the join procedure and to derive network session keys. The other root key, AppKey, is used for the derivation of the AppSKey session key. The security improvement is that users do not need to share AppKey with the network operator. AppKey and the derived AppSKey can be used solely for end-to-end encryption. Nevertheless, the devices (defined by LoraWAN 1.1) that communicate with NS (defined by LoraWAN 1.0.x) must only use NwkKey to derive all keys in order to preserve backward compatibility. Using the security elements and HSM to store the shared keys is still not possible.  
**Authentication:** The version 1.1 improves OTAA (join procedure) by modifying JoinAccept MIC in order to prevent the replay attack. Further, all nonces are not random numbers but counters. Newly, OTAA is managed solely by the JS (not NS), which has to know both shared root keys. The mutual authentication is still based on the secrets shared between the devices and the JS. The knowledge of secrets is proved by computing and checking the CMAC functions (MIC).  
**Key update:** Devices supporting LoRaWAN 1.1 can update session keys and reset counters by the rejoin procedure. The size of counters is increased from 16 bits to 32 bits. Nevertheless, the root keys (AppKey, NwkKey) cannot be updated as in 1.0 to 1.0.3.  
**Encryption:** Data encryption is ensured by the 128-bit AES encryption in the counter with CBC-MAC (CCM) mode (not only CTR as in 1.0). Newly, the NS is not able to decrypt application data without AppSKey.  
**Data integrity:** The version 1.1 defines the CCM authenticated encryption mode that provides data integrity. The data integrity of uplink frames is newly ensured by two CMAC functions with two keys (SNwkSIntKey, FNwkSIntKey). MIC is composed of 2B-cmacS and 2B-cmacF, but the length remains the same (4 B).  
A comparison of the security aspects of both the LoRaWAN 1.0 standard and the new LoRaWAN 1.1 standard is displayed in Table 4.  
The main improvement of the version 1.1 is in defining another key solely for the network level. This enables an enhancement of security for users and developers in public networks. In this way, users who do not use the operator's JS can encrypt data at the application layer without being worried about the operator listening. Nevertheless, some security associations between servers are still outside the scope of the LoRaWAN specifications.