# Insights into the Issue of Deploying a Private LoRaWAN
## 4 Experimental and Analytical Results
### Security Evaluation  
This section reports the comprehensive security analysis of LoRaWAN and names several benefits of private LoRaWAN deployments. We focus on the basics of security properties and vulnerabilities, and we also mention several improvements in related works. Notably, we analyze how LoRaWAN specification 1.1 (released in October 2017) and the most recent specification 1.0.4(2020) address the security issues present in the previous specification (1.0).  
The following LoRaWAN specifications are currently available: 1.0 (2015 [65]), 1.0.1 (2016 [66]), 1.0.2 (2016 [67]), 1.1 (2017 [10]), 1.0.3 (2018 [68]), and 1.0.4 (2020 [69]).  
Version 1.0.1 brings many corrections and clarifications to the definitions of the previous specification. Version 1.0.2 separates regional parameters from the link-layer specification. Subsequently, version 1.1 was released, which addresses additional roaming features and security improvements. Consequently, since the industry did not move to version 1.1 and is still building the 1.0 series of infrastructure and products, the LoRa Alliance has created version 1.0.4, which is currently the latest version of the 1.0 series, into which some features from 1.1 are imported. From a security perspective, versions 1.0.1, 1.0.2, and 1.0.3 are almost identical. This is worth noting that since the public networks have been (i) deployed earlier, and (ii) have to host the older sensors, they often base on the older versions of LoRaWAN specification.  
The LoRaWAN security design is mainly based on symmetric cryptography. The specifications 1.0 [65] to 1.0.3 [68] define the following main security procedures:  
Figure 14: Public network coverage and signal propagation on the first floor.  
**Key establishment:** The LoRaWAN specification 1.0 offers two approaches to establish keys. The first approach is the OTAA (join procedure). The end-device and the NS (or a JS) generate the AppSKey and NwkSKey keys from the same preshared AppKey. The second approach is the ABP activation. The device address (DevAddr), network session key (NwkSKey), and application session key (AppSKey) parameters are configured at production time. OTAA is considered more secure than ABP, but it still has several security issues.  
**Authentication:** Each node has a 64-bit globally unique identifier called device identifier (DevEUI) and a unique 128-bit AES key (called AppKey) that are set by vendors or application providers. The application identifier (AppEUI) uniquely identifies the application. The OTAA proves that both the end-device and the NS (or a JS) have the knowledge of the preshared AppKey key. The end-device sends the join request message with AppEUI, DevEUI, and DevNonce and adds the message integrity code (MIC) computed by AppKey. The NS checks the MIC and generates keys for data encryption and data integrity. The server responds to the end-device by the join accept message with the MIC. The mutual authentication is ensured by the knowledge of the AppKey on both sides.  
**Key update:** Session keys can be updated several times, but the preshared master key AppKey cannot be updated.  
**Encryption:** Data encryption is ensured by the 128-bit AES encryption in the CTR mode. Application payloads are encrypted by the end-to-end shared key AppSKey, which is known only to the end-device and the AS. Nevertheless, the NS also knows the AppSKey and can decrypt the messages. Therefore, the NS has to be trustworthy.  
**Data integrity:** Data integrity is ensured by the 32-bit message integrity code (MIC) produced by the CMAC function using the 128-bit AES encryption. The 4-byte MIC is calculated from a MAC payload and the NwkSKey key shared between the NS and the end-device. This code is added after the MAC payload. To avoid a packet replay attack, a frame counter is used (16 bits). However, the payload could be flipped due to the AES-CTR mode not providing data authentication.