A Multiple End-Devices Authentication Scheme for LoRaWAN

: With the advancement of the Internet of Things, the LoRa Alliance produced the Long-Range Wide-Area Network (LoRaWAN) Speciﬁcation, 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 veriﬁcation 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 speciﬁcations 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.


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.

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).

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 Sections 5 and 6, respectively.

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

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]: • 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.

The LoRaWAN Specifications
When the end-device connects to the LoRaWAN network, the following data are stored in the end-device [23]: 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 enddevice 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.

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.

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: where 0x01 and 0x02 are the port fields for specific applications, AppNonce is an application nonce, NetID is a network identifier, and pad 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: where MIC is computed using AppKey.On receiving the join-accept message, the end-device computes NwkSKey and AppSKey as follows: where AppNonce is an application nonce and NetID is a network identifier.

Application Server
Join

The Proposed Scheme
Table 1 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. Network session key for the end-device i CK Common session key

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 AppKey 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.

Personalization
The device manufacturer must personalize an end-device with: • AppEU I: an application global unique identifier • DevEU I i : a global unique identifier of the end-device i • AppKey i : a secret key shared between the end-device i and the network server

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 DevNonce i at random and computes a message integrity code sends Join-Request i , which contains AppEU I, DevEU I i , DevNonce i , and MIC1 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 MIC1 i for each join-request received during the slot.If MIC1 i is invalid, then it aborts.
Otherwise, it selects a random r i and a common random c.

-
It computes a i = E AppKey i (DevNonce i ||r i ||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 AppKey i to get DevNonce i , r i and c by decrypting a i and verifies whether DevNonce i is correct.If DevNonce 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 , • • • , r n from end-devices at the time slot, sends the group-response message g = r 1 ⊕ ... ⊕ r n to the network server.

-
The network server computes g = r 1 ⊕ r 2 ⊕ ... ⊕ r n and verifies whether g ?= g.If it does not hold, the gateway will send r 1 , • • • , r n to the network server and the network server will verify r i of each end-device i .

-
The end-device i decrypts Join-Accept i with the corresponding AppKey i .Then, the end-device i verifies whether MIC2 i is valid.After that, both the network server and end-device i compute a shared session key as -Finally, the network server sends the corresponding AppSKey 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.

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.

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

1.
Secure Authentication: A outputs a target DevEU I * before the game starts.
• Setup: S sends 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.A impersonates an end-device in the authentication phase to pass the verifi- cation.The advantage of winning the game for A is Adv Dev (A).

Security Proof
Theorem 1.The proposed technique ensures safe mutual authentication and key exchanges between an end-device and the network server.
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 A impersonates the network server with a non-negligible advantage Adv Ser (A).Then, we can build a probabilistic polynomial-time simulator S with a non-negligible advantage Adv PRP (S) to breach the indistinguishability between a random permutation and a pseudorandom permutation.Before the setup step, A generates a target identity DevEU I * .Let SK stand for the PRP game's secret key.
• Setup: 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 A.
Then, S selects AppNonce i and queries the encryption oracle of PRP to encrypt NetID, DevAddr i , RFU, RxDelay i , and CFList as ciphertext C 3 and C 4 , where Finally, A receives C 1 , C 2 , C 3 , and C 4 from the the simulator S.
• Challenge: For DevEU I i = DevEU I * , A sends f 1 to S, where Then, S sends E SK (AppEU I||DevEU I i ||DevNonce i ) to the PRP and chooses case 2 for the challenge.After that, the PRP randomly chooses b ∈ {0, 1}.If b = 0, ST is a random string acquired by performing the Ω −1 function.If b = 1, ST is a pseudorandom string acquired by performing the decryption function −1 on E SK (AppEU I||DevEU I i ||DevNonce i ).As a result, the PRP game returns ST to S.
Then, S selects AppNonce i and queries the encryption oracle of the IND-CCA symmetric encryption to encrypt system parameters: NetID, DevAddr i , RFU, RxDelay i , and CFList to ciphertext C 3 and C 4 as Lemma 3. The proposed method is resistant to an adversary who recovers the session key.
Proof.Assume that a polynomial-time external adversary A has a non-negligible advantage Adv IND-CCA-SK (A) to reveal the session key.Then, we can construct a probabilistic polynomial time simulator S that has the non-negligible advantage Adv IND-CCA-SK (S) to break a known symmetric encryption with IND-CCA security.
• Setup: S sets the the public parameters and the symmetric functions according to the IND-CCA symmetric encryption.Then, S sends the public parameters and the symmetric functions to A.

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

Security Properties
The proposed scheme's characteristics are compared to the LoRaWAN specifications in Table 2.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.

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.In Table 4, 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.

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 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.

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.

Figure 3 .
Figure 3.The LoRaWAN architecture.• 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.

Figure 4 .
Figure 4. Join procedure in the LoRaWAN specification.

Figure 5 .
Figure 5. Communication between various entities in the proposed scheme.

2 . 1 : 2 :
Secure session key exchange: As like earlier, A first outputs a target DevEU I * .• Setup: S sends 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 A queries the two oracles as follows.-Personalization: A inputs DevEU I i .If DevEU I i = DevEU I * , then S sends data transmitted in the personalization phase to A. Otherwise, S aborts.-Authentication: A inputs DevEU I i and AppEU I and S sends packages transmitted in the authentication phase to A. • Challenge: A sends DevEU I * and two random numbers r 0 and r 1 .Then, S randomly chooses b ∈ {0, 1}.S sends E(DevNonce * ||c||r b ) to A, where c is a random number chosen by S. • Training A queries the same queries in Training 1. • Guess: A guesses whether b = 0 or 1.The advantage of winning the game for A is defined as Adv I ND−CCA−SK (A) = |Pr[b = b ] − 1 2 |.

•
Training: S simulates the following oracles for A. -Personalization: A sends an end-device identity DevEU I i .If DevEU I i = DevEU I * , then S returns (AppEU I, AppKey i ) as in the actual scheme.Otherwise, S aborts.-Authentication: A sends DevEU I i and AppEU I.If DevEU I i = DevEU I * , S executes the authentication phase of the proposed scheme.Otherwise, S selects DevNonce i , c, and r i , and then queries the encryption oracle of PRP to receive ciphertext C 1 and C 2 as

Lemma 2 .
The suggested technique is secure against an attacker impersonating a legitimate enddevice based on the IND-CCA security of the symmetric encryption.Proof.Assume that there exists a polynomial-time adversary A who has the non-negligible advantage Adv Dev (A) to impersonate a legal end-device of the proposed scheme.Then, we can construct a probabilistic polynomial time simulator S that has the non-negligible advantage Adv I ND−CCA (S) to break an IND-CCA symmetric encryption.The adversary A outputs a target identity DevEU I * before the setup phase.Let SK denote the secret key of the underlying IND-CCA symmetric encryption.•Setup:S sets the the public parameters and the symmetric functions according to the IND-CCA symmetric encryption process.Then, S sends the public parameters and the symmetric functions to A. • Training: S simulates the following oracles for A as follows.-Personalization: A inputs an end-device identity DevEU I i to S. If DevEU I i = DevEU I * , then S returns AppEU I and AppKey i according to the proposed scheme.Otherwise, S aborts.-Authentication: A sends an end-device's identity DevEU I i and AppEU I.If DevEU I i = DevEU I * , S executes the authentication phase of the proposed scheme.Otherwise, S selects DevNonce i , c, and r i , and then queries the encryption oracle of the IND-CCA symmetric encryption to encrypt AppEU I, DevEU I i , DevNonce i , c and r i into ciphertext C 1 and C 2 as

Finally, A receives C 1 ,Figure 8 .
Figure 8.The game among A, impersonating the network server; S; and IND-CCA oracles.

2 : 1 SFigure 9 .
Figure 9.The security game among A, who can obtain the session key; S; and IND-CCA oracles.

Table 1 .
A list of notations.

•
Training: A queries the two oracles as follows: -Personalization: A inputs DevEU I i .If DevEU I i = DevEU I * , then S sends data transmitted in the personalization phase to A. Otherwise, S aborts.-Authentication: A inputs DevEU I i and AppEU I. S sends the packages transmitted in the authentication phase to A. • Challenge: A picks one of the following two cases and sends DevEU I * to S. -A impersonates a network server in the authentication phase to pass the verification.The advantage of winning the game for A is Adv Ser (A). -

:
S simulates the following oracles for A as follows.-Personalization: A sends an end-device identity DevEU I i .If DevEU I i = DevEU I * , then S returns AppEU I and AppKey i , according to the proposed scheme.Otherwise, S aborts.-Authentication: A sends identity DevEU I i and AppEU I to S. If DevEU I i = DevEU I * , S executes the authentication phase of the proposed scheme.Otherwise, S selects DevNonce i , c and r i and then queries the encryption oracle of the IND-CCA symmetric encryption to encrypt AppEU I, DevEU I i and DevNonce i to ciphertext C 1 = E SK (AppEU I||DevEU I i ||DevNonce i ) and encrypts c and r i to ciphertext C 2 = E SK (DevNonce i ||c||r i ).Once, S receives (C 1 , C 2 ), it selects AppNonce i and queries encryption oracle of the IND-CCA symmetric encryption for (NetID, DevAddr i , RFU, RxDelay i , CFList), and gets ciphertext (C 3 , C 4 ) as • Training 1

Table 3 .
Device specification and operation overhead.