Towards Securing LoRaWAN ABP Communication System

A large number of power-constrained devices will be connected to the Internet of Things (IoT). Deployed in large areas, the battery-powered IoT devices call for power efficient and long range communication technologies. Consequently, the Low Power Wide Area Networks(LPWAN) were devoted to being the key IoT enablers. In this context, LoRaWAN, an LPWAN technology, is one of the main IoT communication protocols candidates. However, LoRaWAN suffers from different security and privacy threats. These threats lead to several availability, authentication, and privacy attacks. In this paper, we present efficient countermeasures against two well-known ABP attacks (eavesdropping and replay). The proposed solution aims at making LoRa ABP end-devices safer, more secure and more reliable. In fact, the proposed solution is based on the dynamic key derivation scheme. We presented two variants of dynamic key derivation: counter-based and channel information-based. A set of security and performance tests shows that the proposed countermeasures present low overhead in terms of computation and communication resources with a high level of security. 1 GENERAL DESCRIPTION Recently, the LoRaWAN technology is presented as key enabler for the IoT applications that require the transmission and reception of a a small amount of data at a low date rate within a range of few Kilometers. LoRaWAN data rate varies between 0.3 to 50 kbps, depending on both range and interference. LoRaWAN uses a wide bandwidth which helps in resisting against interference and noise, and achieving high power efficiency. Besides, it uses specific frequencies which are 868MHZ and 900MHZ, with the transmission range being dependent on the environment. The LoRaWAN architecture is based on the star topology as shown in Figure 1. The IoT devices are connected to the LoRaWAN end-devices (EDs), which are directly connected to one (or more) gateway(s). Each gateway (GW) is connected to the network server(NS), which can be connected to one or more application servers(AS). In fact, the connection between LoRaWAN EDs and GWs is a LoRaWAN communication, whilst the connection between the GW and the AS is a traditional IP connection. Mainly, an ED can be connected to LoRaWAN by using one of two activation modes, that can be OverThe-Air-Activation (OTAA) or Activation by Personalization (ABP). After activation, the EDs communicate the messages, that are authenticated and encrypted, by using a network key NwSKey and application key AppSKey, respectively with the NS. The NS knows the NwSKey of all EDs, while the AS knows the AppSKey of all EDs. However, the difference between the ABP and the OTAA is that in ABP, all the secret keys and identifiers are static, and they are all allocated at the ED. In addition, with ABP, the EDs are connected to the NS directly without any request. However, in OTAA, a join procedure is mandatory for the ED to connect to the network. In addition, in OTAA, the session keys are updated for each new session. 1.1 Problem Formulation In LoRaWAN v1.1, new security enhancements are introduced. However, given that the root keys are static and the identifiers (e.g. JoinUI, DevNonce, etc.) used to generate the session keys are transmitted in plaintext, side channel and node capture attacks are still possible. Thus, both LoRaWAN v1.0 and v1.1 suffer from availability, integrity and confidentiality attacks in both ABP and OTAA activation modes (Eldefrawy et al., 2019). In this paper, we will focus on the ABP eavesdropping and replay attacks.