A Multiple End-Devices Authentication Scheme for LoRaWAN

Abstract

With the advancement of the Internet of Things, the LoRa Alliance produced the Long-Range Wide-Area Network (LoRaWAN) Specification, allowing end-devices to transit through a gateway and join the LoRa network after completing a join procedure. When an end-device joins the LoRaWAN network, it must send a join request message to the network server and wait for the network server to verify such request under the current LoRaWAN join protocol. However, as the number of end-devices grows exponentially, network server verification messages will grow linearly with the number of end-devices. This paper proposes an authentication system for multiple end-devices that complies with the LoRa Alliance’s specifications and decreases the joining latency imposed by the network server verifying messages. The proposed authentication system is formally secure against the server and end-device impersonation. In addition, we assess the authentication overhead and compare it to the standard approach.

1. Introduction

The IoT has enabled various applications in the past few years, including smart homes, smart cities, industrial automation, and smart healthcare [1,2]. According to Ericsson’s mobility report [3], the number of IoT devices exceeded the number of mobile devices in 2018. Furthermore, as illustrated in Figure 1, according to a Statistica report in 2018 [4], IoT devices will have over 75 billion connections by 2025. Furthermore, since technology advances and times change swiftly, consumers have exhibited a greater demand for automated IoT devices and consume less power. This means that previous wireless communication technologies such as Bluetooth Low Energy (BLE), Zigbee, and Wi-Fi are no longer capable of meeting the needs of IoT devices for long distances, low energy consumption, and a high density of nodes. Furthermore, according to the LoRa Alliance [5] and Sinha et al. [6], the Low-Power Wide-Area Network (LPWAN) industry is on the rise in the IoT market. In this scenario, low-power wide-area network (LPWAN) communication technology has recently become a prominent wireless communication technology [7,8].

LoRa [9] is a well-developed technology among these LPWAN technologies. The LoRa technology was developed by the French company Cycleo and bought by Semtech in 2012. Following the acquisition, Semtech commenced an aggressive increase in the use of the technology, including forming the LoRa Alliance to make it easier for other firms to join the LoRa ecosystem. LoRa technology [10] bridges the technical gap between Wi-Fi/BLE and cellular-based networks, such as the 5G network [11], and can provide long-distance data connections with minimal power consumption, as shown in Figure 2. Cisco, one of the LoRa Alliance’s pioneers, presented the following three LoRa application use cases [12]:

• Smart city management: Connecting all the assets of the city and providing better services by collecting data and analyzing data, including waste management, parking, street lighting, and public safety data.
• Asset tracking: Obtaining location information for people and private assets, including equipment, vehicles, pets, and cattle.
• Gas and water metering: Enabling utility customers to remotely read and control gas and water meters to reduce technical costs.

The LoRa Alliance released the first version of the LoRa communication standard specifications in 2015, designating the Long Range Wide-Area Network (LoRaWAN) to enable LoRa to be applied to the abovementioned areas. According to the LoRa Alliance’s introduction overview document issued in 2015 [13], LoRaWAN has the following benefits:

• Long range: Not only can LoRaWAN serve indoor applications in unlicensed bands such as Wi-Fi, but it can also support outdoor applications with the same security as a cellular network [14]. As a result, it can connect to a broader range of networks than Wi-Fi and cellular networks.
• Max lifetime: Asynchronous communication is the most extensively utilized mode for end-devices in the LoRaWAN network. End-devices only communicate over the network when sending event-driven or planned data. As a result, they can conserve the wake-up monitoring power. End-devices in other synchronous networks must wake up frequently in order to synchronize with the network and verify messages, which consumes more power.
• Multi-usage: Depending on the environment, the LoRaWAN network may handle public networks with a significant capacity of hundreds or even tens of thousands of nodes. As a result, it can meet the needs of large online communities or markets [15].
• Low cost: Low power consumption in LoRa end devices enhances battery life and lowers battery replacement expenses. Semtech has also made the hardware and software designs for the gateway and end-devices public. This can help to save money on infrastructure and terminal device development.
• Device classes: End-devices are used for a variety of purposes and have varying needs. LoRaWAN has created three end-device categories, dubbed class A, B, and C, to optimize diverse end-application profiles to balance network downlink communication delays and battery life.
• Security: To ensure end-to-end security, LoRaWAN employs Advanced Encryption Standards (AES) [13]. Mutual authentication and integrity protection also ensure the integrity of LoRa networks, devices, and data [14].

Chen et al. [16] developed a key generation strategy for LoRaWAN that meets the security key randomization criterion. Danish et al. [17] developed a lightweight two-factor authentication system for the LoRaWAN join procedure based on blockchain technology, ensuring confidence between network servers. Later, Tsai et al. [18] established a session key generation mechanism that allows two servers to interact with each other, considerably improving the LoRaWAN Specification’s undefined application-layer communication security securely. For LoRaWAN networks, Jabbari and Mohasefi [19] created a novel secure user-authenticated key establishment mechanism. It allows participants to verify each other’s identities. Furthermore, it enables users and end-devices to establish a secure session key between themselves without trusting the network server unconditionally. Further, Kaven et al. [20] proposed a scheme to combat additional Sybil and man-in-the-middle threats. However, most of the methods do not consider the authentication of multiple end-devices and thus suffer from high latency during real-life deployment.

1.1. Contributions

When an end-device wants to join a network, it must send a join request to the network server, which will execute the join verification process [21]. With the growing number of end-devices, the number of join verification tasks will rise linearly [13]. As a result, if many end-devices want to join the network, the network server will experience a delay when processing such large requests. We propose a multi-device authentication technique based on the LoRaWAN join mechanism to solve this challenge. Within the LoRaWAN framework, we make the following contributions:

• We offer a comprehensive authentication strategy based on the linked end-device(s) features that use exclusive-OR operations to achieve batch authentication.
• The suggested technique allows several end-devices of the same gateway to generate group keys. Supporting group key creation may be helpful for future applications because end-devices from the same gateway may have specific correlations. Furthermore, each end-device requires one additional hash operation.
• Under the formal model, the new technique is protected against major threats such as phoney end-devices, network servers, and the leakage of session keys.
• Considering multi-end-device authentication, the suggested technique saves overall execution time by around 33% compared to the LoRA Specification.

It may be noted that the security evaluation of the proposed scheme is based on the conventional IND-CCA symmetric encryption assumptions and pseudorandom permutation indistinguishability (PRP).

1.2. Organization

The rest of this manuscript is organized as follows: Section 2 mentions some background knowledge relevant to the proposed scheme, including the LoRaWAN standard. The proposed authentication scheme based on the LoRaWAN standard is described in Section 3. The security models and proofs of the proposed scheme are provided in Section 4. Comparisons and concluding remarks are presented in Section 5 and Section 6, respectively.

2. Preliminaries

This section provides background information for the proposed work, including the LoRaWAN architecture with its specifications, and the underlying security games.

2.1. The LoRaWAN Architecture

LoRaWAN is a wide-area network that offers a bi-directional communication protocol for end-devices with long-range, low-power, and low-cost requirements [22]. Figure 3 depicts an overview of the LoRaWAN architecture. The entities defined in the LoRaWAN architecture are described below [13]:

• End-Devices: These could be anything from water meters to smoke alarms to trash cans and pet trackers. LoRaWAN divides end-devices into classes A, B, and C. Each type of device fulfills various long-distance communication requirements.

  -

  Class A: This is the most basic communication mode, with minor power consumption. It transmits data in bursts. As a result, network servers and applications cannot predict the communication time. Class A refers to end-devices that only require upload link communications.

  -

  Class B: Class B end-devices will open additional receive windows at predetermined times in addition to the random receive windows of class A devices. The gateway will send a time synchronization signal to the end-devices in order for them to open the receive windows on a predetermined schedule. As a result, the network server knows when the end-devices are listening.

  -

  Class C: The receive windows on class C end-devices are almost always open and only close when transmitting. This end-device consumes the most power, while having the shortest delay because these receive windows remain open.

• Gateways: A device in the LoRaWAN network is not assigned to a specific gateway. Instead, data sent by a node are typically received by multiple gateways. Each gateway will route data packets from the end node to the cloud-based network server via backhaul cellular or Ethernet networks.
• Network Server: This is in charge of managing the entire network through specific functions. It deletes redundant packets and runs security checks when it receives them from gateways. Finally, it sends back an accept message via the best gateway.
• Application Servers: This is in charge of interpreting data from end-devices and solving problems with advanced technologies such as deep learning or artificial intelligence.

2.2. The LoRaWAN Specifications

When the end-device connects to the LoRaWAN network, the following data are stored in the end-device [23]:

• Device EUI (DevEUI): The DevEUI is a global unique end-device identification number that is assigned by the device manufacturer.
• Application EUI (AppEUI): The AppEUI is a global unique application identification number, which is stored in the device in advance by the device manufacturer.
• Application key (AppKey): The AppKey is an AES-128 secret key stored in the end-device and used to derive two keys, NwkSKey and AppSKey.
• Device address (DevAddr): The DevAddr is a 32-bit hexadecimal number, which can be divided into two parts: the network identifier and network address.

  -

  Network identifier (NwkID): The NwkID is a 7-bit network identifier used to distinguish between the addresses of overlapping networks operated by different network operators.

  -

  Network address (NwkAddr): The NwkAddr is a 25-bit network address assigned by the network manager.

• Network session key (NwkSKey): The NwkSKey is a network session key which is used for MAC layer message encryption and authentication.
• Application session key (AppSKey) The AppSKey is an application session key which is used for application-layer message encryption and authentication.

There are two ways for end-devices to join LoRaWAN, according to current LoRaWAN standards. The first is known as over-the-air activation (OTAA), and the second is known as activation by personalization (ABP). We will introduce them briefly.

2.2.1. End-Device Activation

When using OTAA, the end-device must complete the join procedure to connect to the LoRaWAN network. DevAddr, NwkSKey, and AppSKey, on the other hand, are stored directly in the end-device when using ABP to join LoRaWAN. Because the end-device stores the information required for activation, it can join a specific LoRa network when it boots up. The proposed scheme focuses on the join procedure in OTAA mode.

2.2.2. Join Procedure

The join procedure according to LoRaWAN Specification 1.0.3 is depicted in Figure 4. A join-request message and a join-accept message are sent during the join procedure. Before the end-device begins the join procedure, it must be personalized with the following data: DevEUI, AppEUI, and AppKey. The following is a description of the join procedure. First, the end-device sends a join-request message to the network server, including the DevEUI, AppEUI, device nonce (DevNonce), and message integrity code (MIC), which is computed using the AppKey. After verifying the join-request message, the network server derives the NwkSKey and AppSKey as follows:

$$\begin{array}{ccc}\hfill NwkSKey& =& E_{AppKey}\left(0\mathrm{x}01\right|\left|AppNonce\right|\left|NetID\right|\left|DevNonce\right||pa{d}_{16})\hfill \end{array}$$

(1)

$$\begin{array}{ccc}\hfill AppSKey& =& E_{AppKey}\left(0\mathrm{x}02\right|\left|AppNonce\right|\left|NetID\right|\left|DevNonce\right||pa{d}_{16})\hfill \end{array}$$

(2)

where $0\mathrm{x}01$ and $0\mathrm{x}02$ are the port fields for specific applications, AppNonce is an application nonce, NetID is a network identifier, and $pa{d}_{16}$ is a function adding zero octets to make the length of the data a multiple of sixteen. The network server then sends AppSKey to the application server over a secure channel and a join-accept message to the end-device. The join-accept message contains AppNonce, NetID, DevAddr, a delay (RxDelay) between TX and RX, a reserved-for-future-usage field (RFU), and an optional list of channel frequencies for the network (CFList). AppKey encrypts the join-accept message as follows:

$$\mathit{join}-\mathit{accept}=E_{AppKey}\left(AppNonce\right|\left|NetID\right|\left|DevAddr\right|\left|RFU\right|\left|RxDelay\right|\left|CFList\right|\left|MIC\right)$$

(3)

where MIC is computed using AppKey. On receiving the join-accept message, the end-device computes NwkSKey and AppSKey as follows:

$$\begin{array}{ccc}\hfill NwkSKey& =& E_{AppKey}\left(0\mathrm{x}01\right|\left|AppNonce\right|\left|NetID\right|\left|DevNonce\right||pa{d}_{16})\hfill \end{array}$$

(4)

$$\begin{array}{ccc}\hfill AppSKey& =& E_{AppKey}\left(0\mathrm{x}02\right|\left|AppNonce\right|\left|NetID\right|\left|DevNonce\right||pa{d}_{16})\hfill \end{array}$$

(5)

where AppNonce is an application nonce and NetID is a network identifier.

3. The Proposed Scheme

Table 1. A list of notations.

Notation	Meaning
$AppEUI$	Application global unique identifier
$DevEU{I}_i$	Global unique identifier of the end-device i
$AppKe{y}_i$	Secret key for the end-device i
$DevNonc{e}_i$	Nonce generated by the end-device i
$MIC$	Message integrity code
$aes128\_cmac(K,M)$	MAC function based on the AES-128 for secret key K and message M
$MHDR$	MAC header
$r_i$	Random number for the end-device i
c	Common random number
$NetID$	Network identifier
$RFU$	Reserved field for the future use
$RxDela{y}_i$	The delay field of the end-device i
$CFList$	Optional list of channel frequencies
$pa{d}_{16}$	Zero octets for padding such that data length is a multiple of 16
H	Hash function $H:{\{0,1\}}^{\ast }\to {\{0,1\}}^{\lambda }$
$AppSKe{y}_i$	Application session key for the end-device i
$NwkSKe{y}_i$	Network session key for the end-device i
$CK$	Common session key

displays the useful notations. This section describes an efficient authentication scheme for massive end-devices in the LoRaWAN join procedure. It is divided into three stages: setup, personalization, and authentication, as shown in Figure 5.

3.1. Setup

The network server sends an authentication slot to the gateway. Then, the manufacturer chooses a one-way hash function and embeds it to end-devices. For each end-device ${}_i$, it shares with each network server the identity $DevEU{I}_i$ of the end-device ${}_i$ and a secret key $AppKe{y}_i$ shared with the end-device ${}_i$. It then publishes the details of symmetric encryption and decryption, and one-way hash functions. Moreover, the device manufacturer sets the parameters according to the LoRaWAN Specifications of the LoRa Alliance.

3.2. Personalization

The device manufacturer must personalize an end-device with:

• $AppEUI$: an application global unique identifier
• $DevEU{I}_i$: a global unique identifier of the end-device${}_i$
• $AppKe{y}_i$: a secret key shared between the end-device ${}_i$ and the network server

3.3. Authentication

When this phase is completed successfully, end-devices connected to the same gateway share a group session key $CK$. The authentication phase consists of the following:

• Step 1: An end-device sends a join-request message to the network server to join the LoRaWAN network. The end-device${}_i$

  -

  chooses $DevNonc{e}_i$ at random and computes a message integrity code

  $$MIC{1}_i=aes128\_cmac(AppKe{y}_i,MHDR\left|\right|AppEUI\left|\right|DevEU{I}_i\left|\right|DevNonc{e}_i)$$

  (6)

  -

  sends Join-Request${}_i$, which contains $AppEUI,DevEU{I}_i,DevNonc{e}_i$, and $MIC{1}_i$, to the network server.

• Step 2: To confirm the join-request, the network server sends a join-confirm message to the end-device. The network server waits until the authentication slot expires. It

  -

  checks the correctness of $MIC{1}_i$ for each join-request received during the slot.

  • If $MIC{1}_i$ is invalid, then it aborts.
  • Otherwise, it selects a random $r_i$ and a common random c.

  -

  It computes $a_i=E_{AppKe{y}_i}(DevNonc{e}_i\left|\right|r_i\left|\right|c)$ and sends it to end-device${}_i$.

• Step 3: The end-device decrypts the join-confirm message and sends a response message to the gateway. The end-device${}_i$

  -

  uses $AppKe{y}_i$ to get $DevNonc{e}_i$, $r_i$ and c by decrypting $a_i$ and

  -

  verifies whether $DevNonc{e}_i$ is correct.

    If $DevNonc{e}_i$ is incorrect, it aborts; otherwise, it stores c and sends $r_i$ to the gateway.

• Step 4: The gateway collects all the response messages at the time slot and sends a group-response message to the network server for the verification.

  -

  The gateway, on receiving $r_1,\cdots ,r_n$ from end-devices at the time slot, sends the group-response message $g=r_1\oplus ...\oplus r_n$ to the network server.

  -

  The network server computes $g^{\prime }=r_1\oplus r_2\oplus ...\oplus r_n$ and verifies whether $g^{\prime }\stackrel{?}{=}g$. If it does not hold, the gateway will send $r_1,\cdots ,r_n$ to the network server and the network server will verify $r_i$ of each end-device${}_i$.

• Step 5: The network server sends a join-accept message to the end-devices and sends the session keys to the application server

  -

  The network server computes $MIC{2}_i=aes128\_cmac(AppKe{y}_i,MHDR\left|\right|$

  $NetID\left|\right|AppNonc{e}_i\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList)$ and

  $$\mathit{Join}-{\mathit{Accept}}_i=E_{AppKe{y}_i}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList\left|\right|MIC{2}_i)$$

  (7)

  and sends $Join$-$Accep{t}_i$ to the end-device${}_i$.

  -

  The end-device${}_i$ decrypts $Join$-$Accep{t}_i$ with the corresponding $AppKe{y}_i$. Then, the end-device${}_i$ verifies whether $MIC{2}_i$ is valid. After that, both the network server and end-device${}_i$ compute a shared session key as

  $$\begin{array}{ccc}\hfill NwkSKe{y}_i& =& E_{AppKe{y}_i}\left(0\mathrm{x}01\right||AppNonc{e}_i\left|\right|NetID\left|\right|DevNonc{e}_i\left|\right|pa{d}_{16})\hfill \end{array}$$

  (8)

  $$\begin{array}{ccc}\hfill AppSKe{y}_i& =& E_{AppKe{y}_i}\left(0\mathrm{x}02\right||AppNonc{e}_i\left|\right|NetID\left|\right|DevNonc{e}_i\left|\right|pa{d}_{16})\hfill \end{array}$$

  (9)

  $$\begin{array}{ccc}\hfill CK& =& H\left(AppEUI\right|\left|c\right)\hfill \end{array}$$

  (10)

  -

  Finally, the network server sends the corresponding $AppSKe{y}_i$ and $CK$ to the application server for each end-device${}_i$.

Although we use AES-128, one may use AES-256 to provide higher security. The authentication process is further discussed in Figure 6 in detail.

4. Security Assurance

The proposed scheme achieves certain security features, such as multi-device authentication, resistance against session key disclosure, and strong protection against fake end-devices and fraudulent servers. Before getting into security proofs, we provide formal security models.

4.1. Security Model

We provide security models for the authentication and session key agreement process. The model is a game [24] between a simulator $\mathcal{S}$ and a polynomial-time adversary $\mathcal{A}$.

1.

Secure Authentication:$\mathcal{A}$ outputs a target $DevEU{I}^{\ast }$ before the game starts.

• Setup:$\mathcal{S}$ sends $\mathcal{A}$ system public parameters and the symmetric functions $(E_{Key}$, $D_{Key})$ and sets the key and other public parameters as in the original scheme.
• Training:$\mathcal{A}$ queries the two oracles as follows:

  -

  Personalization:$\mathcal{A}$ inputs $DevEU{I}_i$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, then $\mathcal{S}$ sends data transmitted in the personalization phase to $\mathcal{A}$. Otherwise, $\mathcal{S}$ aborts.

  -

  Authentication:$\mathcal{A}$ inputs $DevEU{I}_i$ and $AppEUI$. $\mathcal{S}$ sends the packages transmitted in the authentication phase to $\mathcal{A}$.

• Challenge:$\mathcal{A}$ picks one of the following two cases and sends $DevEU{I}^{\ast }$ to $\mathcal{S}$.
  • $\mathcal{A}$ impersonates a network server in the authentication phase to pass the verification. The advantage of winning the game for $\mathcal{A}$ is $Ad{v}^{Ser}\left(\mathcal{A}\right)$.
  • $\mathcal{A}$ impersonates an end-device in the authentication phase to pass the verification. The advantage of winning the game for $\mathcal{A}$ is $Ad{v}^{Dev}\left(\mathcal{A}\right)$.

2.

Secure session key exchange: As like earlier, $\mathcal{A}$ first outputs a target $DevEU{I}^{\ast }$.

• Setup:$\mathcal{S}$ sends $\mathcal{A}$ system public parameters and the symmetric functions $(E_{Key}$, $D_{Key})$ and sets the key and other public parameters as in the original scheme.
• Training 1:$\mathcal{A}$ queries the two oracles as follows.

  -

  Personalization:$\mathcal{A}$ inputs $DevEU{I}_i$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, then $\mathcal{S}$ sends data transmitted in the personalization phase to $\mathcal{A}$. Otherwise, $\mathcal{S}$ aborts.

  -

  Authentication:$\mathcal{A}$ inputs $DevEU{I}_i$ and $AppEUI$ and $\mathcal{S}$ sends packages transmitted in the authentication phase to $\mathcal{A}$.

• Challenge:$\mathcal{A}$ sends $DevEU{I}^{\ast }$ and two random numbers $r_0$ and $r_1$. Then, $\mathcal{S}$ randomly chooses $b\in \{0,1\}$. $\mathcal{S}$ sends $E\left(DevNonc{e}^{\ast }\right|\left|c\right|\left|r_b\right)$ to $\mathcal{A}$, where c is a random number chosen by $\mathcal{S}$.
• Training 2:$\mathcal{A}$ queries the same queries in Training 1.
• Guess:$\mathcal{A}$ guesses whether $b=0$ or 1. The advantage of winning the game for $\mathcal{A}$ is defined as $Ad{v}^{IND-CCA-SK}\left(\mathcal{A}\right)=|Pr[b=b^{\prime }]-\frac{1}{2}|$.

4.2. Security Proof

Theorem 1.

The proposed technique ensures safe mutual authentication and key exchanges between an end-device and the network server.

Proof. 

Theorem 1 is established when Lemmas 1, 2, and 3 hold. □

Lemma 1.

The suggested approach is secure against an adversary impersonating the network server based on the indistinguishability of pseudorandom permutation (PRP).

Proof. 

Assume that a polynomial-time adversary $\mathcal{A}$ impersonates the network server with a non-negligible advantage $Ad{v}^{Ser}\left(\mathcal{A}\right)$. Then, we can build a probabilistic polynomial-time simulator $\mathcal{S}$ with a non-negligible advantage $Ad{v}^{PRP}\left(\mathcal{S}\right)$ to breach the indistinguishability between a random permutation and a pseudorandom permutation. Before the setup step, $\mathcal{A}$ generates a target identity $DevEU{I}^{\ast }$. Let $SK$ stand for the PRP game’s secret key.

• Setup: $\mathcal{S}$ sets the public parameters and the symmetric functions according to the pseudorandom permutation. After that, it sends the public parameters and the symmetric functions to $\mathcal{A}$.
• Training: $\mathcal{S}$ simulates the following oracles for $\mathcal{A}$

  -

  Personalization: $\mathcal{A}$ sends an end-device identity $DevEU{I}_i$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, then $\mathcal{S}$ returns $(AppEUI,AppKe{y}_i)$ as in the actual scheme. Otherwise, $\mathcal{S}$ aborts.

  -

  Authentication: $\mathcal{A}$ sends $DevEU{I}_i$ and $AppEUI$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, $\mathcal{S}$ executes the authentication phase of the proposed scheme. Otherwise, $\mathcal{S}$ selects $DevNonc{e}_i$, c, and $r_i$, and then queries the encryption oracle of PRP to receive ciphertext $C_1$ and $C_2$ as

  $$\begin{array}{ccc}\hfill C_1& =& E_{SK}\left(AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i)\hfill \end{array}$$

  (11)

  $$\begin{array}{ccc}\hfill C_2& =& E_{SK}(DevNonc{e}_i\left|\right|c\left|\right|r_i)\hfill \end{array}$$

  (12)

  Then, $\mathcal{S}$ selects $AppNonc{e}_i$ and queries the encryption oracle of PRP to encrypt $NetID$, $DevAdd{r}_i$, $RFU$, $RxDela{y}_i$, and $CFList$ as ciphertext $C_3$ and $C_4$, where

  $$\begin{array}{ccc}\hfill C_3=E_{SK}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList)& & \end{array}$$

  (13)

  $$\begin{array}{cc}\hfill C_4=E_{SK}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList\left|\right|C_3)& \end{array}$$

  (14)

  Finally, $\mathcal{A}$ receives $C_1$, $C_2$, $C_3$, and $C_4$ from the the simulator $\mathcal{S}$.

• Challenge: For $DevEU{I}_i=DevEU{I}^{\ast }$, $\mathcal{A}$ sends $f_1$ to $\mathcal{S}$, where

  $$f_1=E_{SK}\left(AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i\left)\right|\left|AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i$$

  (15)

  Then, $\mathcal{S}$ sends $E_{SK}\left(AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i)$ to the PRP and chooses case 2 for the challenge. After that, the PRP randomly chooses $b\in \{0,1\}$. If $b=0$, $ST$ is a random string acquired by performing the ${\Omega }^{-1}$ function. If $b=1$, $ST$ is a pseudorandom string acquired by performing the decryption function ${\mho }^{-1}$ on $E_{SK}\left(AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i)$. As a result, the PRP game returns $ST$ to $\mathcal{S}$.
• Guess: On receiving $ST$, $\mathcal{S}$ checks if $ST$ is equal to $AppEUI\left|\right|DevEU{I}_i\left|\right|DevNonc{e}_i$. If the condition is true, $\mathcal{S}$ knows that $ST$ is calculated by the decryption function ${\mho }^{-1}$, and thus sets $b^{{}^{\prime }}=1$; otherwise, $\mathcal{S}$ sets $b^{{}^{\prime }}=0$. Finally, $\mathcal{S}$ sends guess $b^{\prime }$ to the PRP.

Therefore, we have $Ad{v}^{PRP}\left(\mathcal{S}\right)=Ad{v}^{Ser}\left(\mathcal{A}\right)$, where $Ad{v}^{PRP}\left(\mathcal{S}\right)$ denotes the advantage of $\mathcal{S}$ to break the indistinguishability between a random permutation and a pseudorandom permutation. A security proof sketch is further mentioned in Figure 7. □

Lemma 2.

The suggested technique is secure against an attacker impersonating a legitimate end-device based on the IND-CCA security of the symmetric encryption.

Proof. 

Assume that there exists a polynomial-time adversary $\mathcal{A}$ who has the non-negligible advantage $Ad{v}^{Dev}\left(\mathcal{A}\right)$ to impersonate a legal end-device of the proposed scheme. Then, we can construct a probabilistic polynomial time simulator $\mathcal{S}$ that has the non-negligible advantage $Ad{v}^{IND-CCA}\left(\mathcal{S}\right)$ to break an IND-CCA symmetric encryption. The adversary $\mathcal{A}$ outputs a target identity $DevEU{I}^{\ast }$ before the setup phase. Let $SK$ denote the secret key of the underlying IND-CCA symmetric encryption.

• Setup: $\mathcal{S}$ sets the the public parameters and the symmetric functions according to the IND-CCA symmetric encryption process. Then, $\mathcal{S}$ sends the public parameters and the symmetric functions to $\mathcal{A}$.
• Training: $\mathcal{S}$ simulates the following oracles for $\mathcal{A}$ as follows.

  -

  Personalization: $\mathcal{A}$ inputs an end-device identity $DevEU{I}_i$ to $\mathcal{S}$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, then $\mathcal{S}$ returns $AppEUI$ and $AppKe{y}_i$ according to the proposed scheme. Otherwise, $\mathcal{S}$ aborts.

  -

  Authentication: $\mathcal{A}$ sends an end-device’s identity $DevEU{I}_i$ and $AppEUI$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, $\mathcal{S}$ executes the authentication phase of the proposed scheme. Otherwise, $\mathcal{S}$ selects $DevNonc{e}_i$, c, and $r_i$, and then queries the encryption oracle of the IND-CCA symmetric encryption to encrypt $AppEUI$, $DevEU{I}_i$, $DevNonc{e}_i$, c and $r_i$ into ciphertext $C_1$ and $C_2$ as

  $$\begin{array}{ccc}\hfill C_1& =& E_{SK}\left(AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i)\hfill \end{array}$$

  (16)

  $$\begin{array}{ccc}\hfill C_2& =& E_{SK}(DevNonc{e}_i\left|\right|c\left|\right|r_i)\hfill \end{array}$$

  (17)

  Then, $\mathcal{S}$ selects $AppNonc{e}_i$ and queries the encryption oracle of the IND-CCA symmetric encryption to encrypt system parameters: $NetID$, $DevAdd{r}_i$, $RFU$, $RxDela{y}_i$, and $CFList$ to ciphertext $C_3$ and $C_4$ as

  $$\begin{array}{ccc}\hfill C_3=E_{SK}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList)& & \end{array}$$

  (18)

  $$\begin{array}{cc}\hfill C_4=E_{SK}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList\left|\right|C_3)& \end{array}$$

  (19)

  Finally, $\mathcal{A}$ receives $C_1$, $C_2$, $C_3$, and $C_4$ from $\mathcal{S}$.

• Challenge: $\mathcal{A}$ sends identity $DevEU{I}_i$ to $\mathcal{S}$, where $DevEU{I}_i=DevEU{I}^{\ast }$. Then, $\mathcal{S}$ chooses $r_0$ and $r_1$ to compute $M_0=(DevNonc{e}_i\left|\right|c\left|\right|r_0)$ and $M_1=(DevNonc{e}_i\left|\right|c\left|\right|r_1)$. After that, $\mathcal{S}$ sends $(M_0,M_1)$ to the IND-CCA oracles to start the challenge phase of the IND-CCA game. Finally, $\mathcal{S}$ receives $C_b=E_{SK}\left(M_b\right)$ given from the encryption oracle and sends it to $\mathcal{A}$, where b, chosen by the encryption oracle, is unknown to $\mathcal{S}$.
• Guess: $\mathcal{A}$ outputs a bit $y_{b^{{}^{\prime }}}$ to $\mathcal{S}$. If $y_{b^{{}^{\prime }}}=0$, $\mathcal{S}$ sets $b^{{}^{\prime }}=0$; otherwise, $\mathcal{S}$ sets $b^{{}^{\prime }}=1$. Finally, $\mathcal{S}$ sends the guess $b^{{}^{\prime }}$ to the IND-CCA game.

Therefore, we have $Ad{v}^{IND-CCA}\left(\mathcal{S}\right)=Ad{v}^{Dev}\left(\mathcal{A}\right)$, where $Ad{v}^{IND-CCA}\left(\mathcal{S}\right)$ denotes the advantage of the simulator to break the IND-CCA symmetric encryption. A security proof sketch is further mentioned in Figure 8. □

Lemma 3.

The proposed method is resistant to an adversary who recovers the session key.

Proof. 

Assume that a polynomial-time external adversary $\mathcal{A}$ has a non-negligible advantage $Ad{v}^{\mathrm{IND}-\mathrm{CCA}-\mathrm{SK}}\left(\mathcal{A}\right)$ to reveal the session key. Then, we can construct a probabilistic polynomial time simulator $\mathcal{S}$ that has the non-negligible advantage $Ad{v}^{\mathrm{IND}-\mathrm{CCA}-\mathrm{SK}}\left(\mathcal{S}\right)$ to break a known symmetric encryption with IND-CCA security.

• Setup:$\mathcal{S}$ sets the the public parameters and the symmetric functions according to the IND-CCA symmetric encryption. Then, $\mathcal{S}$ sends the public parameters and the symmetric functions to $\mathcal{A}$.
• Training 1:$\mathcal{S}$ simulates the following oracles for $\mathcal{A}$ as follows.

  -

  Personalization:$\mathcal{A}$ sends an end-device identity $DevEU{I}_i$. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, then $\mathcal{S}$ returns $AppEUI$ and $AppKe{y}_i$, according to the proposed scheme. Otherwise, $\mathcal{S}$ aborts.

  -

  Authentication:$\mathcal{A}$ sends identity $DevEU{I}_i$ and $AppEUI$ to S. If $DevEU{I}_i\ne DevEU{I}^{\ast }$, $\mathcal{S}$ executes the authentication phase of the proposed scheme. Otherwise, $\mathcal{S}$ selects $DevNonc{e}_i$, c and $r_i$ and then queries the encryption oracle of the IND-CCA symmetric encryption to encrypt $AppEUI$, $DevEU{I}_i$ and $DevNonc{e}_i$ to ciphertext $C_1=E_{SK}\left(AppEUI\right||DevEU{I}_i\left|\right|DevNonc{e}_i)$ and encrypts c and $r_i$ to ciphertext $C_2=E_{SK}(DevNonc{e}_i\left|\right|c\left|\right|r_i)$. Once, $\mathcal{S}$ receives $(C_1,C_2)$, it selects $AppNonc{e}_i$ and queries encryption oracle of the IND-CCA symmetric encryption for $(NetID,DevAdd{r}_i,RFU,RxDela{y}_i,CFList)$, and gets ciphertext $(C_3,C_4)$ as

  $$\begin{array}{ccc}\hfill C_3=E_{SK}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList)& & \end{array}$$

  (20)

  $$\begin{array}{cc}\hfill C_4=E_{SK}(AppNonc{e}_i\left|\right|NetID\left|\right|DevAdd{r}_i\left|\right|RFU\left|\right|RxDela{y}_i\left|\right|CFList\left|\right|C_3)& \end{array}$$

  (21)

  Finally, $\mathcal{A}$ receives $C_1$, $C_2$, $C_3$, and $C_4$ from $\mathcal{S}$.

• Challenge:$\mathcal{A}$ sends $r_0$ and $r_1$ of equal-length and $DevEU{I}_i$, where $DevEU{I}_i=DevEU{I}^{\ast }$. Then, $\mathcal{S}$ computes $M_0=(DevNonc{e}_i\left|\right|c\left|\right|r_0)$ and $M_1=(DevNonc{e}_i\left|\right|c\left|\right|r_1)$ and sends $(M_0,M_1)$ to the IND-CCA oracles to start the challenge phase of the underlying IND-CCA game. After that, $\mathcal{S}$ receives $C_b=E_{SK}\left(M_b\right)$ given from the encryption oracle and sends it to $\mathcal{A}$, where $b{\in }_R\{0,1\}$ is unknown to $\mathcal{S}$.
• Training 2:$\mathcal{A}$ can query the same queries as those in Training 1.
• Guess: The adversary $\mathcal{A}$ outputs a bit $y_{b^{{}^{\prime }}}$ to $\mathcal{S}$. If $y_{b^{{}^{\prime }}}=0$, $\mathcal{S}$ sets $b^{{}^{\prime }}=0$; otherwise, $\mathcal{S}$ sets $b^{{}^{\prime }}=1$. Finally, $\mathcal{S}$ sends the guess $b^{{}^{\prime }}$ to the IND-CCA game.

Therefore, we have $Ad{v}^{\mathrm{IND}-\mathrm{CCA}-\mathrm{SK}}\left(\mathcal{S}\right)=Ad{v}^{\mathrm{IND}-\mathrm{CCA}-\mathrm{SK}}\left(\mathcal{A}\right)$, where $Ad{v}^{\mathrm{IND}-\mathrm{CCA}-\mathrm{SK}}\left(\mathcal{S}\right)$ denotes the advantage of the simulator to break the IND-CCA symmetric encryption. A security proof sketch is further mentioned in Figure 9. □

5. Comparison

This section demonstrates the proposed scheme’s characteristics, computation cost, and performance.

5.1. Security Properties

The proposed scheme’s characteristics are compared to the LoRaWAN specifications in

Table 2. Functionality comparison.

Security Properties	LoRaWAN Spec.	The Proposed Scheme
Mutual Authentication	Yes	Yes
Data Integrity Protection	Yes	Yes
Authentication of Multiple End-Devices	No	Yes

. The suggested scheme and the LoRaWAN specifications ensure mutual authentication and data integrity. LoRaWAN only checks one end-device per time slot, whereas the suggested scheme certifies several end-devices at the same time.

5.2. Computation Cost

The computation overhead considers the additional cost incurred due to rapid authentication for multiple end-devices in LoRaWAN. We list the hardware information and the computation cost of each operation in

Table 3. Device specification and operation overhead.

(a) The hardware information.
Specification	Windows 10 64-bit
CPU	Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz 1.80 GHz
RAM	8.00 GB
Motherboard	KBL Strongbow KL
(b) Benchmark time.
Operation	Time(s)
AES [25] encryption /decryption	0.0209808
XOR operation	0.0009536

.

In

Table 4. Computation cost.

Entity	LoRaWAN Specification	The Proposed Scheme
Each End-device	$3T_{AES}\approx 0.06294s$	$4T_{AES}\approx 0.08392s$
Gateway	—	$n{T}_{xor}\approx 0.00095ns$
Network Server	$3n{T}_{AES}\approx 0.06294ns$	$4n{T}_{AES}+n{T}_{xor}\approx 0.08487ns$

, the computation cost of the LoRaWAN specifications is compared to the overhead of the proposed method. Although the suggested system involves more computations in the gateway and network server than the LoRaWAN specifications, it has the batch authentication property that the LoRaWAN specifications do not have.

It is worth noting that the authentication computation cost does not include the cost of computing the shared session key.

5.3. Performance

Based on the work of Lavric and Popa [26] consideration, we set the maximum number of end-devices in the LoRaWAN network to be 1000. Furthermore, we chose these scenarios for comparison since 50 or 100 end-devices are commonly utilized in real-life.

Table 5. Performance comparison.

Number of Devices	Overhead		Efficacy
	LoRaWAN Spec.	The Proposed Scheme
50	$\approx 06.294s$	$\approx 04.327s$	31%
100	$\approx 12.588s$	$\approx 08.571s$	32%
1000	$\approx 125.880s$	$\approx 84.954s$	33%

shows the overall execution time of the proposed scheme and of the LoRaWAN specifications for validating 50, 100, and 1000 end-devices, respectively.

Because the LoRaWAN specifications check one device attempting to join the network at a time, the joining method must be repeated 50, 100, or 1000 times in order to verify all end-devices, correspondingly, as shown in Table 5. On the other hand, since the suggested scheme provides batch verification for multiple devices, it only has to be run once in each case to verify all end-devices.

6. Conclusions

Based on the LoRaWAN join procedure, we have presented a secure multi-device authentication scheme. The suggested system can fit the features of natural LoRaWAN environments to reduce join latency. Furthermore, the suggested technique employs the challenge-response and exclusive-OR operations in tandem to obtain batch authentication benefits. As a result, the suggested scheme may be readily integrated into the existing LoRaWAN join mechanism. Furthermore, we anticipate that the suggested approach can be utilized to create a secure and rapid LoRaWAN authentication system that meets the LoRa Alliance’s specifications. In the future, we will consider various real-world scenarios and design effective key management and device revocation processes in multi-device authentication settings.