# A Multiple End-Devices Authentication Scheme for LoRaWAN

^{*}

## Abstract

**:**

## 1. Introduction

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

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

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

#### 1.2. Organization

## 2. Preliminaries

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

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

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

#### 2.2.1. End-Device Activation

#### 2.2.2. Join Procedure

## 3. The Proposed Scheme

#### 3.1. Setup

#### 3.2. Personalization

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

- 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})$$
- -
- 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$$\phantom{\rule{-28.45274pt}{0ex}}\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})$$
- -
- 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}$$$$\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}$$$$\begin{array}{ccc}\hfill CK& =& H\left(AppEUI\right|\left|c\right)\hfill \end{array}$$
- -
- Finally, the network server sends the corresponding $AppSKe{y}_{i}$ and $CK$ to the application server for each end-device${}_{i}$.

## 4. Security Assurance

#### 4.1. Security Model

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

**Proof**.

**Lemma**

**1.**

**Proof**.

**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}$$$$\begin{array}{ccc}\hfill {C}_{2}& =& {E}_{SK}(DevNonc{e}_{i}\left|\right|c\left|\right|{r}_{i})\hfill \end{array}$$$$\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}$$$$\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}$$

**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}$$**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.

**Lemma**

**2.**

**Proof.**

**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}$$$$\begin{array}{ccc}\hfill {C}_{2}& =& {E}_{SK}(DevNonc{e}_{i}\left|\right|c\left|\right|{r}_{i})\hfill \end{array}$$$$\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}$$$$\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}$$

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

**Lemma**

**3.**

**Proof.**

**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}$$$$\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}$$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.

## 5. Comparison

#### 5.1. Security Properties

#### 5.2. Computation Cost

#### 5.3. Performance

## 6. Conclusions

## Author Contributions

## Funding

## Institutional Review Board Statement

## Informed Consent Statement

## Data Availability Statement

## Acknowledgments

## Conflicts of Interest

## References

- Basford, P.J.; Bulot, F.M.; Apetroaie-Cristea, M.; Cox, S.J.; Ossont, S.J. LoRaWAN for smart city IoT deployments: A long term evaluation. Sensors
**2020**, 20, 648. [Google Scholar] [CrossRef] [PubMed] [Green Version] - Lima, E.; Moraes, J.; Oliveira, H.; Cerqueira, E.; Zeadally, S.; Rosário, D. Adaptive priority-aware LoRaWAN resource allocation for Internet of Things applications. Ad Hoc Netw.
**2021**, 122, 102598. [Google Scholar] [CrossRef] - Ericsson, S. Internet of Things to Overtake Mobile Phones by 2018. Available online: http://www.satellitemarkets.com/market-trends/internet-things-overtake-mobile-phones-2018 (accessed on 2 March 2022).
- Statista, I. Internet of Things (IoT) Connected Devices Installed Base Worldwide from 2015 to 2025 (In Billions). Available online: https://statinvestor.com/data/33967/iot-number-of-connected-devices-worldwide/ (accessed on 2 March 2022).
- Alliance, L. LPWA Technologies Unlock New IoT Market Potential; White Paper; LoRa Alliance: Fremont, CA, USA, 2015; Available online: https://lora-alliance.org/resource_hub/lorawan-security-whitepaper/ (accessed on 2 March 2022).
- Sinha, R.S.; Wei, Y.; Hwang, S.H. A survey on LPWA technology: LoRa and NB-IoT. ICT Express
**2017**, 3, 14–21. [Google Scholar] [CrossRef] - Navarro-Ortiz, J.; Sendra, S.; Ameigeiras, P.; Lopez-Soler, J.M. Integration of LoRaWAN and 4G/5G for the Industrial Internet of Things. IEEE Commun. Mag.
**2018**, 56, 60–67. [Google Scholar] [CrossRef] - Noura, H.; Hatoum, T.; Salman, O.; Yaacoub, J.P.; Chehab, A. LoRaWAN security survey: Issues, threats and possible mitigation techniques. Internet Things
**2020**, 12, 100303. [Google Scholar] [CrossRef] - Adelantado, F.; Vilajosana, X.; Tuset-Peiro, P.; Martinez, B.; Melia-Segui, J.; Watteyne, T. Understanding the limits of LoRaWAN. IEEE Commun. Mag.
**2017**, 55, 34–40. [Google Scholar] [CrossRef] [Green Version] - Semtech. Why Lora
^{®}? Available online: https://www.semtech.com/lora/why-lora (accessed on 2 March 2022). - Bocker, S.; Arendt, C.; Jorke, P.; Wietfeld, C. LPWAN in the Context of 5G: Capability of LoRaWAN to Contribute to mMTC. In Proceedings of the 2019 IEEE 5th World Forum on Internet of Things (WF-IoT), Limerick, Ireland, 15–18 April 2019; pp. 737–742. [Google Scholar]
- Cisco. Cisco Solution for LoRaWAN. Available online: https://www.cisco.com/c/en/us/solutions/internet-of-things/lorawan-solution.html (accessed on 2 March 2022).
- LoRa Alliance. A Technical Overview of LoRa and LoRaWAN; LoRa Alliance: Fremont, CA, USA, 2015; Available online: https://www.everythingrf.com/whitepapers/details/2682-a-technical-overview-of-lora-and-lorawan (accessed on 2 March 2022).
- Butun, I.; Pereira, N.; Gidlund, M. Security risk analysis of LoRaWAN and future directions. Future Internet
**2019**, 11, 3. [Google Scholar] [CrossRef] [Green Version] - Lombardo, A.; Parrino, S.; Peruzzi, G.; Pozzebon, A. LoRaWAN vs NB-IoT: Transmission Performance Analysis within Critical Environments. IEEE Internet Things J.
**2021**, 9, 1068–1081. [Google Scholar] [CrossRef] - Chen, X.; Wang, J.; Wang, L. A fast session key generation scheme for LoRaWAN. In Proceedings of the 2019 Australian & New Zealand Control Conference (ANZCC), Auckland, New Zealand, 27–29 November 2019; pp. 63–66. [Google Scholar]
- Danish, S.M.; Lestas, M.; Asif, W.; Qureshi, H.K.; Rajarajan, M. A lightweight blockchain based two factor authentication mechanism for LoRaWAN join procedure. In Proceedings of the 2019 IEEE International Conference on Communications Workshops (ICC Workshops), Shanghai, China, 20–24 May 2019; pp. 1–6. [Google Scholar]
- Tsai, K.L.; Leu, F.Y.; Hung, L.L.; Ko, C.Y. Secure session key generation method for LoRaWAN servers. IEEE Access
**2020**, 8, 54631–54640. [Google Scholar] [CrossRef] - Jabbari, A.; Mohasefi, J.B. A Secure and LoRaWAN Compatible User Authentication Protocol for Critical Applications in the IoT Environment. IEEE Trans. Ind. Inform.
**2021**, 18, 56–65. [Google Scholar] [CrossRef] - Kaven, S.; Bornholdt, L.; Skwarek, V. Authentication by rssi-position based localization in a lora lpwan. In Proceedings of the 2020 6th IEEE Congress on Information Science and Technology (CiSt), Agadir, Morocco, 5–12 June 2021; pp. 448–454. [Google Scholar]
- Gu, C.; Jiang, L.; Tan, R.; Li, M.; Huang, J. Attack-aware synchronization-free data timestamping in lorawan. ACM Trans. Sens. Netw. (TOSN)
**2021**, 18, 1–31. [Google Scholar] [CrossRef] - Ertürk, M.A.; Aydın, M.A.; Büyükakkaşlar, M.T.; Evirgen, H. A survey on LoRaWAN architecture, protocol and technologies. Future Internet
**2019**, 11, 216. [Google Scholar] [CrossRef] [Green Version] - Sornin, N.; Luis, M.; Eirich, T.; Kramp, T.; Hersent, O. Lorawan Specification; LoRa Alliance: Fremont, CA, USA, 2015; Available online: https://lora-alliance.org/resource_hub/lorawan-specification-v1-1/ (accessed on 2 March 2022).
- Eldefrawy, M.; Butun, I.; Pereira, N.; Gidlund, M. Formal security analysis of LoRaWAN. Comput. Netw.
**2019**, 148, 328–339. [Google Scholar] [CrossRef] [Green Version] - Draft, F. Advanced Encryption Standard (AES); National Institute of Standards and Technology: Gaithersburg, MD, USA, 2001. [Google Scholar]
- Lavric, A.; Popa, V. Performance evaluation of LoRaWAN communication scalability in large-scale wireless sensor networks. Wirel. Commun. Mob. Comput.
**2018**, 2018, 1–10. [Google Scholar] [CrossRef] [Green Version]

**Figure 7.**The game among $\mathcal{A}$, who impersonates the network server; $\mathcal{S}$; and PRP oracles.

**Figure 8.**The game among $\mathcal{A}$, impersonating the network server; $\mathcal{S}$; and IND-CCA oracles.

**Figure 9.**The security game among $\mathcal{A}$, who can obtain the session key; $\mathcal{S}$; and IND-CCA oracles.

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 |

Security Properties | LoRaWAN Spec. | The Proposed Scheme |
---|---|---|

Mutual Authentication | Yes | Yes |

Data Integrity Protection | Yes | Yes |

Authentication of Multiple End-Devices | No | Yes |

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

Entity | LoRaWAN Specification | The Proposed Scheme |
---|---|---|

Each End-device | $3{T}_{AES}\approx 0.06294\phantom{\rule{3.33333pt}{0ex}}s$ | $4{T}_{AES}\approx 0.08392\phantom{\rule{3.33333pt}{0ex}}s$ |

Gateway | — | $n{T}_{xor}\approx 0.00095n\phantom{\rule{3.33333pt}{0ex}}s$ |

Network Server | $3n{T}_{AES}\approx 0.06294n\phantom{\rule{3.33333pt}{0ex}}s$ | $4n{T}_{AES}+n{T}_{xor}\approx 0.08487n\phantom{\rule{3.33333pt}{0ex}}s$ |

Number of Devices | Overhead | Efficacy | |
---|---|---|---|

LoRaWAN Spec. | The Proposed Scheme | ||

50 | $\approx 06.294\phantom{\rule{3.33333pt}{0ex}}s$ | $\approx 04.327\phantom{\rule{3.33333pt}{0ex}}s$ | 31% |

100 | $\approx 12.588\phantom{\rule{3.33333pt}{0ex}}s$ | $\approx 08.571\phantom{\rule{3.33333pt}{0ex}}s$ | 32% |

1000 | $\approx 125.880\phantom{\rule{3.33333pt}{0ex}}s$ | $\approx 84.954\phantom{\rule{3.33333pt}{0ex}}s$ | 33% |

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |

© 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Fan, C.-I.; Zhuang, E.-S.; Karati, A.; Su, C.-H.
A Multiple End-Devices Authentication Scheme for LoRaWAN. *Electronics* **2022**, *11*, 797.
https://doi.org/10.3390/electronics11050797

**AMA Style**

Fan C-I, Zhuang E-S, Karati A, Su C-H.
A Multiple End-Devices Authentication Scheme for LoRaWAN. *Electronics*. 2022; 11(5):797.
https://doi.org/10.3390/electronics11050797

**Chicago/Turabian Style**

Fan, Chun-I, Er-Shuo Zhuang, Arijit Karati, and Chun-Hui Su.
2022. "A Multiple End-Devices Authentication Scheme for LoRaWAN" *Electronics* 11, no. 5: 797.
https://doi.org/10.3390/electronics11050797