Overview of Proposed LoRaWAN Security Model: Comparison
View Latest Version
Please note this is a comparison between Version 2 by Camila Xu and Version 1 by Bassey Isong.

Long-Range Wide-Area Network (LoRaWAN) is a popular Medium Access Control (MAC) protocol that has several benefits such as wide-area coverage, long-range communication, low deployment cost, and low energy consumption. LoRaWAN is deployed on top of the Long-Range (LoRa) protocol, which is a physical layer protocol. Interoperability and cross-cooperation can be experienced by the communicating entities in IoT-based LoRaWAN applications with less complex implementations.

  • IoT
  • LoRa
  • LoRaWAN
  • attacks
  • key security

1. Introduction

The Internet of Things (IoT) is a promising wireless communication platform that allows several devices to autonomously share data and communicate over the Internet. This technology is widely applied in several areas such as in the production industries, agriculture, healthcare, transportation, and homes. However, IoT devices are resource constrained, which limits their applicability. Thus, to improve and extend IoT’s flexibility, the Long-Range Wide-Area Network (LoRaWAN) was introduced for IoT-based applications. LoRaWAN is a popular Medium Access Control (MAC) protocol that has several benefits such as wide-area coverage, long-range communication, low deployment cost, and low energy consumption [1,2,3,4,5,6,7,8,9,10,11,12][1][2][3][4][5][6][7][8][9][10][11][12]. LoRaWAN is deployed on top of the Long-Range (LoRa) protocol, which is a physical layer protocol. Interoperability and cross-cooperation can be experienced by the communicating entities in IoT-based LoRaWAN applications with less complex implementations; however, this implementation raises a lot of security and privacy concerns as part of the transmitted data can be sensitive information [1,2,3,4,5,6,7,8,9,10,11,12][1][2][3][4][5][6][7][8][9][10][11][12].
Security model design in LoRaWAN is dominated by cryptographic techniques such as Advanced Encryption Standard (AES) 128 bit symmetric encryption, which is used to generate encryption keys to secure the transmitted data between the entities. This is important to increase the strength of the security models being deployed in IoT-based LoRaWAN to ensure the whole network is not vulnerable to several attacks and intrusions [1,2,3,4,5,6,7,8,9,10,11,12][1][2][3][4][5][6][7][8][9][10][11][12]. Due to the resource-constrained LoRaWAN devices, heavy and complex cryptographic models are not practical solutions to improve the security level of the existing LoRaWAN [1,2,3,4,5,6,7,8,9,10,11,12][1][2][3][4][5][6][7][8][9][10][11][12]. Therefore, the LoRaWAN security model is fully implemented using the AES 128 bit symmetric encryption with different modes of security such as the Cipher-based Message Authentication Codes (CMAC) mode for data integrity, and the Counter (CTR) mode for data encryption and decryption [6]. Moreover, each security key is derived for its rightful purpose such as the Application Key (AppKey), which is pre-shared and only known between the end device and the Network Server (NwkS) when the device is manufactured. The AppKey is used to generate two session keys: AES 128 bit Application Session Key (AppSKey) and Network Session Key (NwkSKey). The AppSKey is shared between the end device and the Application Server for the encryption and decryption of the payload, while NwkSKey is shared between the end device and the network server for initiating the communication. NwkSKey is also used for message integrity using Message Integrity Check (MIC) [6]. Moreover, LoRaWAN devices are activated for communication using either Activation By Personalization (ABP) or Over The Air Activation (OTAA) [7]. In OTAA, the activation is initiated from the end devices side by sending a join request (JR) message to the NwkS, where the message is composed of the 64 bit hexadecimal Device EUI (DevEUI) device universal identifier, and the 64 bit hexadecimal Application EUI (AppEUI), AppS universal identifier and a 2 octets random number as Device Nonce (DevNonce) used for integrity [7]. The AES 128 bit AppKey is pre-programmed and pre-shared between the NwkS and the end devices, in place of the encryption of the JR message; the AppKey is responsible for computing the MIC of the transmitted message [6]. If the JR is approved, the NwkS responds with the join accept (JA) message composed of the 32 bit hexadecimal Device Address (DevAddr), Network Identifier (NetID), and the 3 octets Application Nonce (AppNonce). In ABP, the NwkS and the end-device share transmit the JR and JA the message as in OTAA, the only difference is the pre-programmed and pre-shared of the AppSKey, the NwkSKey, and the device address (DevAddr) between the servers and the end devices before communication to ensure that the entities are ready communication and equipped with relevant keys [6,7,9,11,12][6][7][9][11][12].

2. Overview of Proposed LoRaWAN Security Model

In practice, LoRaWAN’s security model proffers only a minimum-security level for the network as it deploys encryption keys to secure the communicating entities, shared data, and even the protection of the encryption keys as well against intruders. However, the network could be vulnerable to key and data attacks that can adversely affect it. Although several proposed models for improving the LoRaWAN key management security models exist such as in [2[2][4][6][7][10][11],4,6,7,10,11], it is important to consider the characteristics and the attack’ nature when designing and developing an improved LoRaWAN key security model. With several parameters involved when generating and securing both the communicating keys and the parameters, all are considered data and should be secured with encryption keys that are securely managed. With an intruder having sufficient knowledge about possible weaknesses and shortfalls of the LoRaWAN security model, several attacks can be launched to compromise the network. For instance, attacks such as replay attacks [7,10][7][10] and the man in the middle attack [25][13]. Moreover, the intruder may perform the bit-flipping attacks [26][14] by altering the bits of the transmitted causing the receiving entities not to decrypt the encrypted transmitted data. This preseaperrch addresses such security challenges in the LoRaWAN by designing and implementing two security models using the Scyther security verifying tool. The aim is to enhance the key server to efficiently generate and manage keys securely. However, the proposed models do not accommodate the communication between the end devices, but rather demonstrate the efficiency of key generation and distribution in the LoRaWAN network by securing the entities and the network before any communication may occur between the end devices. Moreover, the application server is excluded since it is only active during communication. However, if the end devices are to communicate, the AppKey shall be shared between the end devices and the application server. The key distribution of the proposed model between the entities is presented in Figure 1. The two TKMS algorithms are Algorithms A and B, where Algorithm B is an enhanced Algorithm A. The end device in both models is activated via OTAA rather than ABP due to security issues with pre-programmed keys. As shown in Figure 1, the three main entities and three keys being generated and distributed across the entities by the trusted key server in the proposed key distribution architecture are as follows:
Jsan 11 00052 g001 550
Figure 1. Key distribution architecture.
  • End-device: A LoRaWAN device that is being deployed in the network after manufacturing. This end device is pre-programmed with several parameters such as the AppKey, the device universal identifier used to identify itself in the network, and the AppKey that will be shared with the trusted key server during the request to join process.
  • Trusted key server: The trusted key server is employed as a trusted party to generate and manage the keys securely and efficiently in the network. It is used in our model to ease some of the complex operations that were performed by the network server alone such as key generation and update. This server upon receiving AppKey for the end device, generates two session keys, the AppSKey used for securing the communication between the end device and the application server, and the NwkSKey used for securing between the end device and the network server.
  • Network server: This is responsible for generating and distributing network parameters with the end device so that during transmission the end device is knowledgeable of the network to transmit on, and the unoccupied channels that can be used for the transmission.

References

  1. Choi, J.; Kim, Y. An Improved LEA Block Encryption Algorithm to Prevent Side-Channel Attack in the IoT System. In Proceedings of the 2016 Asia-Pacific Signal and Information Processing Association Annual Summit and Conference (APSIPA), Jeju, Korea, 13–16 December 2016; pp. 1–4.
  2. Han, J.; Wang, J. An enhanced key management scheme for LoRaWAN. Cryptography 2018, 2, 34.
  3. Hu, Z. Layered Network Protocols for Secure Communications in the Internet of Things; University of Oregon: Eugene, OR, USA, 2021.
  4. Kim, J.; Song, J. A dual key-based activation scheme for secure LoRaWAN. Wirel. Commun. Mob. Comput. 2017, 2017, 6590713.
  5. Mahmood, Z.; Ning, H.; Ghafoor, A. A polynomial subset-based efficient multi-party key management system for lightweight device networks. Sensors 2017, 17, 670.
  6. Na, S.; Hwang, D.; Shin, W.; Kim, K.-H. Scenario and Countermeasure for Replay Attack Using Join Request Messages in LoRaWAN. In Proceedings of the 2017 International Conference on Information Networking (ICOIN), Da Nang, Vietnam, 11–13 January 2017; pp. 718–720.
  7. Naoui, S.; Elhdhili, M.E.; Saidane, L.A. Trusted Third Party Based Key Management for Enhancing LoRaWAN security. In Proceedings of the 2017 IEEE/ACS 14th International Conference on Computer Systems and Applications (AICCSA), Hammamet, Tunisia, 30 October–3 November 2017; pp. 1306–1313.
  8. Roselin, A.G.; Nanda, P.; Nepal, S. Lightweight Authentication Protocol (LAUP) for 6LoWPAN Wireless Sensor Networks. In Proceedings of the 2017 IEEE Trustcom/BigDataSE/ICESS, Sydney, Australia, 1–4 August 2017; pp. 371–378.
  9. Ruotsalainen, H.; Zhang, J.; Grebeniuk, S. Experimental Investigation on Wireless Key Generation for Low-Power Wide-Area Networks. IEEE Internet Things J. 2019, 7, 1745–1755.
  10. Tsai, K.-L.; Huang, Y.-L.; Leu, F.-Y.; You, I. TTP based high-efficient multi-key exchange protocol. IEEE Access 2016, 4, 6261–6271.
  11. Tsai, K.-L.; Huang, Y.-L.; Leu, F.-Y.; You, I.; Huang, Y.-L.; Tsai, C.-H. AES-128 based secure low power communication for LoRaWAN IoT environments. IEEE Access 2018, 6, 45325–45334.
  12. Yang, X.; Karampatzakis, E.; Doerr, C.; Kuipers, F. Security vulnerabilities in LoRaWAN. In Proceedings of the 2018 IEEE/ACM Third International Conference on Internet-of-Things Design and Implementation (IoTDI), Orlando, FL, USA, 17–20 April 2018; pp. 129–140.
  13. Naoui, S.; Elhdhili, M.E.; Saidane, L.A. Enhancing the Security of the IoT LoraWAN Architecture. In Proceedings of the 2016 International Conference on Performance Evaluation and Modeling in Wired and Wireless Networks (PEMWN), Toulouse, France, 26–28 September 2016; pp. 1–7.
  14. Lee, J.; Hwang, D.; Park, J.; Kim, K.-H. Risk Analysis and Countermeasure for Bit-Flipping Attack in LoRaWAN. In Proceedings of the 2017 International conference on information networking (ICOIN), Da Nang, Vietnam, 11–13 January 2017; pp. 549–551.
More
© Text is available under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/)
Video Production Service
Feedback