A Cloud-Based Key Rolling Technique for Alleviating Join Procedure Replay Attacks in LoRaWAN-based Wireless Sensor Networks

Nowadays, numerous devices are utilizing the IoT world, connecting and providing access to data and sensor measurements in vast networks of interconnected objects and devices. Considering the great communication distances that need to be covered occasionally, the LoRaWAN network was proposed as it employs Low Power (LP) and Long Range (LoRa) protocols that reduce device energy consumption while maximizing communication range. A gateway to the cloud authenticates LoRaWAN IoT devices before data transmission. This procedure begins with an unencrypted Join Request. A Join Request includes, among others, a Message Integrity Code (MIC), which is the result of encrypting the unencrypted contents of the message using an AppKey that is securely stored both in the cloud and the IoT device. However, malicious actors acting as Man-In-the-Middle (MITM) can interfere in the communication channel, reverse engineer the MIC value, and derive the AppKey. They can then initiate a Join Request that is misinterpreted as coming from a legitimate device and gain access to the communication channel. This paper introduces a novel approach that focuses on the continuous regeneration of the AppKey, necessitating frequent re-joining and re-authentication of IoT devices within the network. The suggested method, which can be added as an extra layer of security in LoRaWAN networks, uses a key rolling technique similar to the one used in automobile central locking systems, and is developed as an optimised and scalable microservice for various LoRaWAN installations and versions. Through the evaluation process, significant findings emerged, demonstrating the effectiveness of the proposed security solution in mitigating replay attacks. The system successfully prevented the server from getting flooded by malicious packets, distinguishing it from a system lacking the proposed mechanism. Remarkably, this accomplishment was made without causing any noticeable delay to the communication process. In addition, the timeframe required by the proposed mechanism to generate the new AppKey is assumed to be too short for attackers to execute a replay attack, considering the computational resources currently accessible.