Securing End-Node to Gateway Communication in LoRaWAN With a Lightweight Security Protocol

The arrival of IoT has brought constant innovation. This innovation has allowed many “things” (sensors, wearable devices, smart appliances, among others) to be connected to the Internet to deliver the information they collect. This need for connection has set the tone for the development of new protocols that adapt to the IoT environment, taking into consideration low energy consumption and low computational cost. These protocols are known as Low Power Wide Area Network (LPWAN). In this context, one of the most used is LoRaWAN. As many other IoT protocols, it is exposed to security threats. These threats aim to compromise security principles like confidentiality, integrity and availability (CIA Triad) of the information. This paper aims to analyze weaknesses related to gateways within LoRaWAN infrastructure to propose a lightweight security protocol to address gateway authentication vulnerabilities. This protocol uses lightweight cryptographic functions to achieve this goal as it is intended to be deployed over IoT devices which are very limited in terms of hardware and power resources. Likewise, this protocol has gone through a formal security analysis with the use of BAN-Logic and a tool called Scyther, to validate the security of the proposed protocol.

technologies are called Low Power Wide Area Network 31 The associate editor coordinating the review of this manuscript and approving it for publication was Eyuphan Bulut . (LPWAN).LPWAN protocols support long range commu-32 nications (kilometers); they are optimized for power con-33 sumption and they are not expensive to be implemented [9]. 34 LPWAN is able to reach up to 10-40 km in rural areas whilst 35 1-5 km in urban areas, providing long-range communication. 36 Moreover, a battery used in IoT devices with LPWAN has 37 an estimate lifetime of around 10 years. Finally, IoT devices 38 based on LPWAN are very affordable as their cost is no more 39 than $5 dollars in some cases [8]. 40 In terms of LPWAN protocols, there are multiple options 41 such as LTE-M, SigFox, NB-IoT, Long Range Wide Area 42 Network (LoRaWAN), Weightless-N, and EC-GSM. Among 43 them, the most used are Long Range Wide Area Network 44 (LoRaWAN), SigFox and Narrow Band -Internet of Things 45 (NB-IoT) [7], [8], [9], [10]. These protocols have similarities 46 in terms of architecture but differ in other parameters such 47 as frequency of operation, security, connection fees, among 48 others. 49 In comparison with other LPWAN protocols, LoRaWAN 50 possess some benefits. First of all, its level of openness allows 51 LoRaWAN operates over unlicensed Regional Industrial 107 Scientific Medical (ISM) bands. ISM bands are 868 MHz in 108 Europe, 915 MHz in North America, and 433 MHz in Asia. 109 LoRaWAN has three classes known as Class A, B and C as 110 shown in Figure 1. Class A is not optional and has to be imple-111 mented by all end-nodes. Devices that implement more than 112 the mandatory class are considered High-End devices [13]. 113 There are three classes of devices according to LoRaWAN 114 specification. First, class A devices are bi-directional end 115 nodes which are more energy efficient and have two short 116 defined reception windows after every uplink message. Class 117 B devices open additional receive windows on scheduled 118 times with the use of beacons sent by the gateway. On the 119 other hand, Class C devices are continuously listening and 120 they are the least energy efficient but offer the lowest latency 121 level [13]. 122

123
LoRaWAN is composed of three elements: end-nodes, gate-124 ways and back-end servers. On the other hand, back-end 125 servers are composed of: Network Server (NS), Join Server 126 (JS) and Application Server (AS). Any end-node that wants 127 to communicate with the back-end server infrastructure must 128 go through a gateway (Gw). The communication between 129 end-node (EN) and gateway is performed through LoRa pro-130 tocol which is based on Chirp Spread Spectrum [12]. Gw 131 to back-end servers communication is handled over TCP/IP 132 protocols [9], [10], [12]. The following Figure 2 shows the 133 architecture of LoRaWAN with all its actors. 134 2) LoRaWAN BACKEND INFRAESTRUCTURE 135 As described in LoRaWAN Backend Interfaces Specifi-136 cation [14], besides radio gateway, there are three types 137 of servers that are part of the backend architecture of 138 LoRaWAN. Those servers are: Network Server, Applica-139 tion Server (AS), and Join Server; each of them perform 140 specific tasks within the whole architecture. The Network 141 Server (NS) is in charge of handling LoRAWAN MAC layer 142 for end-nodes, forwarding messages to AS, forwarding Join 143 VOLUME 10, 2022 Interfaces Specification [14] describes three roles for the NS 146 which are home (hNS), serving(sNS) and forwarding(fNS). 147 hNS is responsible for persisting information related to Ser- Node. According to [14] JS manages End-Device activation NSs and JSs, and several AS may be connected to a single 166 NS. According to [14], there are several interfaces in place to 167 support several procedures within LoRaWAN network from 168 the perspective of the End-Device (home or roaming). These  LoRaWAN supports two activation processes (join proce-189 dures) for enabling end-nodes over a LoRaWAN network. 190 Those processes are: Activation By Personalization (ABP) 191 and Over the Air Activation (OTAA).

192
The OTAA procedure is started by the end-node. For this 193 purpose, each end-node has the following security parameters 194 DeviceEUI ENi , JoinEUI ENi , NwkKey EN i and AppKey EN i . The 195 last two parameters are 128-bit keys used to derive session 196 keys. These parameters are factory stored settings. This pro-197 cedure is considered more secure than ABP since other keys 198 are derived from known parameters stored in the device. 199 In ABP mode, it is required that all sessions keys have to be 200 preloaded in the end-node, application server, network server 201 and join server for executing the join procedure and then 202 sending uplink messages.

203
The Join-Procedure is a process for authenticating End-204 Nodes over a LoRaWAN network. This process is mandatory 205 before sending any uplink message. In order to proceed the 206 End-Node must first build a Join-Request message com-207 posed as follows by the JoinEUI, DevEUI and the DevNonce. 208 JoinEUI is an identifier of the JS, DevEUI is a unique iden-209 tifier of the Device and DevNonce is a sequential 2-byte 210 number generated by the EN. This message is sent in plain-211 text. These parameters are evaluated by the JS and NS as 212 follows. JS verifies that DevEUI is in the authorized list 213 whilst NS validates and keeps a track of every DevNonce 214 generated. If the procedure is successful, the Network Server 215 will respond with a Join-Accept message to the EN so that 216 it could derive session keys (Application Session, Network 217 Session and Join Session keys) [10], [13].

218
The Join-Accept message contains the following parame-219 ters JoinNonce, Home_NetID, DevAddr DLSettings, RxDelay 220 and CFList [13]. The following table describes the parame-221 ters that are part of the Join-Accept message see Table 1.

222
Once the EN receives the Join-Accept message, the fol-223 lowing session keys are derived according to the specifica-224 tion [13]. Every session key is used for a particular purpose. 225 FNwkSIntKey and SNwkSIntKey are used to calculate MIC 226 fields for preserving message integrity.NwkSEncKey is used 227 to cypher messages for NS.AppSKey is used to cypher Frm-228 Payload for AS [13]. The session keys are derived as follow 229 according to the specification:  239 After the Join-Accept, JS must record and keeps a track of 240 every JoinNonce generated every time a Join or a Rejoin is 241 performed. only a few propose some improvements. Table 2 shows some 287 of the reviewed works, their research focus and the version of 288 LoRaWAN used for the research [10].

289
As can be seen in the previous table, there is very few 290 research being carried out in terms of vulnerabilities associ-291 ated to gateways. In spite of recommendations that have been 292 made, there are no formal requirements in the specification 293 that focus on mitigating gateway vulnerabilities. In this situ-294 ation, this research will be oriented on securing the commu-295 nication between the Gw and the backend infrastructure.

296
For its part, the work presented by [20] discusses about 297 impersonating gateways. Although the author performs this 298 analysis over LoRaWAN 1.0, they are still aplicable as the 299 current specification does not address any security require-300 ments or improvements to the gateway. The author describes 301 that registering a gateway is not a mandatory requirement. 302 The proof of concept that he perfomed used the platform 303 The Things Network (TTN). This platform is able to accept 304 traffic from unregistered gateways and they mark traffic as 305 unstrusted to differentiate from traffic generated by regis-306 tered gateways. This attack takes place in four stages as 307 described by the author. First, a malicious user has to acquire 308 the gateway unique id. Then, the gateway gets disabled by 309 the attacker. Once the id has been obtained, the malicious 310 gateway is configured with the original id to communicate 311 with the valid Network Server. Finally, a malicious user is 312 able to perform an ACK spoofing. This attack is discussed and 313 tested by [16] where they showed that a gatewway can selec-314 tively decide which packets not being transmitted. Under the 315 described scenario, the attacker would have physical access to 316 the device or perform a jamming attack to completely disable 317 it. As the used platform does not perform any further vali-318 dations, once the malicious gateway ''assumes'' the identity 319 of the compromise gateway it will be able to push messages 320 through a malicious device. Finally, the author propose some 321 countermesaures to prevent this attack from happening. The 322 author suggests using IDS devices to detect a change of 323 the IP address, and putting gateways in a safe and secure 324 place. Moreover, the authors indicate that having gateway 325 redundancy is an alternative. Securing the channel between 326 gateway and the backend infrastructure is also a suggested 327 countermeasure. Last but no least, dereasing spread factor 328 would notably reduce the possibility of a jamming attack.

329
On the other side, the authors in [19] perform a review on 330 vulnerabilities over gateways and propose possible solutions.

331
That work reviews problems like: Radio Jamming Attack,     The authors in [30] performed a formal security verification 387 by using a tool known as Scyther to analyze the state of 388 security of the Join-Procedure in the LoRaWAN protocol for 389 both versions 1.0.3 and 1.1. In such work, they demonstrated 390 that LoRaWAN v1.1 is more secure. The authors considered 391 only the end-node and the Join Server, but they did not include 392 the gateway as it acts as packet translator to deliver uplink 393 messages to the back-end infrastructure; however, Gw plays 394 a crucial role as if it fails packets could not be delivered.

395
In our approach, we will use the same tool but considering 396 the role of the Gateway in the protocol and taking the same 397 assumptions as described in [30]. The following results were 398 obtained after running the Scyther tool (see Table 3). 399 The results show that the inclusion of this role produces 400 an affectation in the protocol. This inclusion has affected 401 the Weakagree principle, meaning that the partners might be 402 communicating with an intruder. The other claim affected is 403 Niagree, which means that the parties are not able to agree 404 on the value of variables after execution. Besides, the claim 405 Nisynch is also affected. It means that the protocol is not exe-406 cuted in order and that contents cannot be preserved during 407 communication. Failing the the claim of synchronicity Nys-408 inch implies that there is no mutual authentication between 409 gateway and server (Network Server). Therefore, the gateway 410 must be authenticated within the LoRaWAN infraestructure 411 as this claim fails also between End-Node and Gateway. The 412 table 3 shows that either the End-Node (Dev), Gateway (Gw), 413 or Join Server (JS) could be attacked. This attack can be 414 replicated not only during the Join-Procedure but also during 415 uplink and downlink messages.

416
Uplink messages contains information payloads generated 417 by the end-nodes that are intended to be delivered to an 418 application server for further data processing and analysis. 419 This process could be executed once an end-node has been 420 activated either through OTAA or ABP join-procedures. The 421 uplink message delivery protocol is shown in Figure 3.

423
For defining the threat model, the uplink message protocol 424 will be considered. The following assumptions are in place.

425
The device has already approved successfully the OTAA Join-     encrypted. The information that can be obtained by applying 453 a simple Base64 or Hex decoding is listed in the following 454 Table 4.

455
Although a malicious user would have a hard time trying to 456 decrypt FRMPaylod, it is important to denote that LoRaWAN 457 session keys live for a long a time and they are just renewed 458 with rejoin procedure or by sending a RekeyInd command that 459 is triggered by the device and shall be processed by the NS 460 to produce a new pair of keys [13]. With the aforementioned 461 before, a cryptoanalysis procedure is valid to infer the content 462 of the FRMPaylod considering that the minimum length is 463 7 bytes protected with an AES-128 bit key. In addition, 464 as a malicious user is able to capture packets he is also 465 able to resend this packets or craft malicious packets based 466 on previous informaiton and send them to the LoRaWAN 467 infrastructure since the gateway is assumed to be ''trusted''. 468 The exposed vulnerabilities require a mechanism that prevent 469 malicious users to easily sniff, divert or inject unathorized 470 traffic. LoRaWAN infrastructure, they are exposed to rogue gate-  produce a new session key that will be used between the EN 502 and the Gw. This key will be known as GwSKey and will be 503 generated during the Join Procedure. It will be shared to the 504 NS and later to the Gw or group of Gw tied to a particular NS. 505 Table 5 shows the notation used in the following protocols. This protocol registers a gateway within a LoRaWAN net-508 work. During this registration, the Gateway (Gw) will share 509 its symmetric key with the Network Server (NS). In this 510 scenario, it is assumed that the gateway symmetric key will 511 reside in secure place that cannot be tampered. the deployed network. This protocol aims to mitigate the 520 vulnerability described as Rogue Gateway attacks. This is a 521 formal protocol that must take place before any Gw wants to 522 be part of a LoRaWAN network. The process for registering 523 a gateway into the LoRaWAN network is executed as follows 524 (see Figure 7). For this scenario, it is assumed that the network 525 administrator has to configure the Gw i to connect to a fNS or 526 a set of them. 527 First, the user in charge of performing the configura-528 tion is a network administrator which provides his/her cre-529 dentials ID Ui , PW Ui into the gateway. Then, the gateway 530 Gw i generates a randmon nonce RN1, a random symmetric 531 key RSK, computes GwSKa=h(RSK || GwKey Gwi ), where 532 GwKey Gwi is a symmetric key that comes from factory and 533 is stored in a secure place in the gateway, and calculates 534 GwInf=SEnc(GwSka, RN1||GwEUI Gwi ) where GwEUI Gwi is 535 a 64-bit Unique Identifier of the gateway, and SEnc(x,y) is 536 a symmetric encryption function y using the key x, || is a 537 concatenation operation, and h(.) is a one-way hash function. 538 Then, it calculates the following: The gateway (Gw i ) communicates with the fNS and 542 asks for gateway registration by sending M1. After receiv-543 ing the request, fNS Obtains ID Ui from M1 and calcu-544 lates h(IDUi||h(PWUi)). It obtains GwSKa by executing 545 MReq ⊗ h(IDUi||h(PWUi)) . It extracts RN1||GwEUI Gwi 546 by performing SDec(GwSKa, GwInf) where SDec(x,y) 547 is a symmetric decryption function of message y using 548 key x. It generates two random nonces RN2 and RN3 549 and then computes the symmetric groupkey key for all 550 gateways associated to fNS by executing GrpKey GrpId = 551 h(GwKey Gw i ||GwKey Gw j ||GwKey Gw j+1 ||GwKey Gw j+n ||RN3), 552 where GwKey Gw n is a symmetric key that belongs to a partic-553 ular registered gateway n. This key is the group symmetrickey 554 that will be used by the fNS to share multicast messages 555 with its registered gateways. Then, it generates a sequential 556 integer GrpId to identify the group of gateways connected 557 to it. It stores (GwEUI Gwi ,h(GwEUI Gwi ),GrpKey GrpId ,GrpId) 558 in its LocalDB. For this scenario, every time a gateway is 559 registered, the GrpKey GrpId will be calculated and shared 560 (multicast) to all the gateways tied to a fNS. Finally, it calcu-561 lates M2=SEnc(GwSka,GrpKey GrpId ||RN1'||RN2) and sends 562 it back to Gw i .

563
Once Gw i receives M2, it obtains GrpKey GrpId || RN1'|| 564 RN2' by decrypting SDec (GwSKa,M2). Then, it validates 565 if the received random nonce RN1' matches the pre-566 viously generated one RN1, to guarantee the freshness 567 of the message. If previous validation was ok, it calcu-568 lates MICGw = aes_cmac(GrpKey GrpId , RN2'||GwEUI Gwi ), 569 where aes_cmac(x,y) is an AES Message Authentication 570 Code function that uses a key x to produce a code of a message 571 y. Then, it computes MA=SEnc(GrpKey GrpId , RN2'||MICGw) 572 Finally, it calculates M3 = MA||h(GwEUI Gw i ) and sends M3 573 to fNS. 574 Finally, upon reception of M3, fNS obtains h(GwEUI Gw i ) 575 and compares against its LocalDB to obtain the GrpKey GrpId 576 gateway, it will unauthorize Gw i in the fNS database by The process for deriving the Gateway Session Key 610 (GwSKey ENi ) in a LoRaWAN Home Scenario is executed as 611 follows (see Figure 8). The steps highlighted in green are part 612 of our contribution.

613
This procedure is executed during the Join-Procedure 614 OTAA described in the LoRaWAN 1.1 specification. Once 615 the EN has passed all validation procedures by NS and JS, 616 it starts the Session Key Derivation Process. According to the 617 specification, there are five keys that are derived and shared 618 with the Network Server and the Application Server. In this 619 scenario, a new symmetric key based on previous Network 620 Key and Application Key is calculated by using an XOR 621 function and then using it to calculate a sixth session key 622 known as GwSKey ENi   to obtain the session key used to send messages to a particular 662 Gateway. The GwSKey ENi is a 128-bit key. This key will 663 be renewed on every Re-Join procedure according to the 664 protocol described before. The key is assumed to be stored 665 in a secure place with tamper proof mechanisms. 666

667
In case the LoRaWAN infrastructure is working on Roaming 668 Scenario, the following considerations are in place, and the 669 protocol for such scenario is shown in Figure 9.

670
According to the LoRaWAN backend specification [14] 671 when an End-Node EN i works over roaming the following 672 additional steps are required once a Join Request has been 673 dispatched. First, the Join Request arrives to NS2 and it has 674 to determine if it is acting as the (hNS) for the ENi. It also has 675 to determine if it has been identified to work with JS which 676 is identified by JoinEUI, if such is not the case, the process 677 must terminate at this point. Otherwise, it has to perform a 678 DNS lookup to identify the IP address of JS. In case NS2 is 679 not able to identify the (hNS), it has to send a request that 680 contains DevEUI to JS to retrieve such information. JS has 681 to respond to such request either with a succesfull response  The process for sending uplink messages through a reg-719 istered gateway is described as follows. This procedure is 720 executed after the OTAA Join-Procedure has been success-721 fully acknowledge with a Join-Accept message. It applies 722 for Unconfirmed Data Up Messages and is divided in two 723 scenarios.

724
The first one applies when a end-node EN i has joined 725 (OTAA Activation) through a registered gateway Gw i which 726 has already been registered through the fNS. The second 727 scenario applies when an end-node EN i wants to send a mes-728 sage over a registered gateway but EN i is not registered over 729 that Gw i . In our proposal a Gw i must be registered over the 730 LoRaWAN infraestructure before forwarding any message. 731 First of all, EN i calculates all the following as part of the 732 construction of the uplink message according to LoRaWAN 733 1.

779
The purpose of this protocol is to deliver messages over 780 a Gw i that has already been registered within LoRaWAN 781 infrastructure by using an authenticated Eni. 782 it calculates DevAddr = SDec(GwDevId ENi , DevAddr ENi ), In this section we demonstrate the security of the Gateway 863 Registration Protocol by using BAN logic. 864

865
The following Table 6 presents the notations used for BAN 866 logic.

875
The following are the goals defined for the Gateway registra- Scyther is a tool that performs formal security analysis of pro-944 tocols considering the assumption of perfect cryptography.   The Scyther analysis of this protocol is shown in This new key is shared to the Gateway through the Network 1020 Server, which uses a pre calculated group key (GrpKey GrpId ) 1021 to multicast this session key (GwSkey EN i ) to other gateways 1022 that are connected to the same Network Server. Therefore, 1023 only the gateway or its group of gateways that belong to 1024 the same Network Server can decrypt messages sent by EN i 1025 and then forward payloads to the backend infrastructure. The 1026 results of Scyther execution are displayed in Table 7.

1028
According to the LoRaWAN 1.1 specification once the Join 1029 Procedure has performed and End-Node device would be able 1030 to send data to the Application Server. As stated before, the 1031 design was translated to a SPDL file to reflect all interactions 1032 between the involved roles. In this case the participants were: 1033 End-Node (Dev), Gateway, Network Server (NS) and Appli-1034 cation Server (AS).

1035
All the variables used in the protocol where declared as 1036 String for testing purposes. String was defined as a userType 1037 variable as it is not a common data type of Scyther.

1038
As shown in, Table 7 there are no potential vulnerabili-1039 ties in the proposed protocol. It means that as long as an 1040 End-Node uses a valid GwSkey, a message will be delivered 1041 to the Application Server, otherwise, it will be discarded by 1042 the Gateway before sending it to the backend infrastructure. 1043 The secrecy of session keys is preserved according to the 1044 results shown by Scyther as well as MIC and MIC_P EN i 1045 validation fields to protect the FRMPayload from bit-flipping 1046 attacks. 1047

1048
In our proposed scenario, we have identified that if an EN i 1049 has gone through a Join procedure using a different Gateway. 1050 The results displayed by Scyther (see Table 8) showed 1061 that the implementation does not have potential attacks 1062 and it could be considered as a secure protocol. All 1063 claims are marked with the OK word and the Ver-1064 ified Niagree, Nisynch, Alive, Weekagree and session 1065 keys.

1100
The attacker might try to decrypt the uplink message gener-1101 ated by an end-node. However, the message is protected by 1102 symmetric key of 128-bit length that could be changed on 1103 demand. 1104

1105
A gateway (Gw) will only handle a pre-calculated tem-1106 porary root key (GwSKa) and every end-node session 1107 key (GwSKey ENi ). A gateway will not be able to derive 1108 GwSKey ENi as it does not store parameters for such purpose. 1109

1110
In order to determine a potential performance affectation, 1111 it is important to analyze and identify the number of addi-1112 tional cryptographical operations that will take place with the 1113 current proposed solution. This cryptographical operations 1114 comprise hashing, simple XOR, symmetric encryption, sym-1115 metric decryption, asymmetric encryption, and asymmetric 1116 decryption.

1117
First of all, the current operation of the protocol already 1118 includes some cryptographic operations according to the 1119 specification [13] that are listed in the table below. The 1120 considered operations were taken from the Join-Procedure 1121 activation and the Uplink message delivery. Table 9 contains 1122 the operation name, the number of cryptographic operations, 1123    The proposed protocols do not aim to implement new 1160 symmetric algorithms or to increase their encryption level 1161 (i.e. changing to AES-256). The solution is tied to the spec-1162 ification and although it will perform more cryptographic 1163 operations, their complexity will remain which means that the 1164 current computational resources would be enough to process 1165 the new operations. The total overhead for the Gateway Registration Protocol is 1231 224*k this effect is shown in Figure 15. The total overhead for 1232 the Gateway Session Key Derivation Protocol is 288*k, this 1233 is shown in Figure 16. For UMOAEG protocol is 40*j+80*k 1234 (see Figure 17) and for UMOUAEF is 40*j + 689*k as 1235 described in Figure 18. Previous figures are estimates based 1236 on the effect of adding more nodes and gateways respectively 1237 for each of the designed protocols in this work. In all figures 1238 there is a directly proportional effect between the overhead 1239 generated and the number of devices added.   it will be deployed and the way the algorithm has been 1244 implemented as stated by [38].

1245
To provide an estimate of the solution that we are proposing 1246 in this work, we will refer to one of the most common   For estimating hashing power consumption, we will use 1257 the work described in [40]. The authors in their work use 1258 SHA-256 to validate crytographic hardware in IoT devices. 1259 The values obtained in their experiment will be used to 1260 establish an approximate value of consumption for hashing 1261 operations.

1262
Based on the aforementioned approaches, we will con-1263 sider the values obtained in their works and perform an 1264 estimation over the end-node because is the entity with 1265 the smallest amount of computational resources and power. 1266 The following Figure 19 shows the estimate power con-1267 sumption expressed in milliWatts (mW) of the current 1268 LoRaWAN v1.1 Join procedure and uplink message proco-1269 tol. The values taken to perform the estimation are shown 1270 in table 13.

1305
The results of the formal security validation probe that the 1306 proposed protocol is secure in terms of security properties as 1307 validated by the Scyther tool. Although the results are favor-1308 able it is important to consider that when implementing these 1309 enhancements secure robust encryption algorithms must be in 1310 place (AES-128 at least) as well as a proper hashing algorithm 1311 (SHA-1 at least). Likewise, it is crucial to preserve the length 1312 of keys as the encryption algorithm in place suggested by 1313 the specification is AES-128; therefore, keys are restricted to 1314 have no more than 16 bytes.

1315
Most of the reviewed works are focused on proposing 1316 new approaches for enhancing key management such as 1317 using blockchain which are the newest proposals. However, 1318 in terms of securing end-node to gateway communication 1319 there are no formal proposals although these issues are dis-1320 cussed in [10] and [19] in depth. The authors expose the need 1321 of mutual authentication protocols for securing communi-1322 cations between the aforementioned devices. To best of our 1323 knowledge those works are the only ones that point out the 1324 existence of this issue still in the new version of LoRaWAN. 1325 Although other works like [20] or [16] exploit weaknesses 1326 in gateways, they do not show designs for possible implemen-1327 tations or new protocols that allow the identified gaps to be 1328 adequately mitigated.

1329
Compared to other works our solution proposes a novel 1330 approach for authenticating a gateway within the back-end 1331 infrastructure as well as the interaction with the end-node by 1332 preserving the IoT premise of designing features that demand 1333 low energy consumption and low computational cost as well. 1334 The proposed approach does not include third-party services 1335 or infrastructure, on the contrary, it uses the elements defined 1336 in the specification and combines them to build protocols 1337 that allow ensuring the channel between the end-node and 1338 the gateway. Our proposed approach compared to the recent 1339 Basic Station [43] does not require the inclusion of a Cer-1340 tification Authority. In LoRa Basics Station, there are two 1341 scenarios that can be deployed one without authentication and 1342 the other which consists on using client and server authenti-1343 cation which involves configuring the service endpoint url, 1344   For future work, we have considered to modify a 1387 LoRaWAN library for including these new changes over IoT 1388 devices based on Arduino hardware architecture to deploy the 1389 following proposed protocols. Likewise, perform a penetra-1390 tion testing over the Gateway Registration Protocol to prove 1391 its effectiveness. In addition, design a protocol to authenticate 1392 Class B beacon messages.