Investigation on Security Risk of LoRaWAN: Compatibility Scenarios

The LoRaWAN standard comes from the low-power wide area network (LPWAN) technology suitable for developing Internet of Things (IoT) systems that are poised to disrupt the semiconductor industry. Even as a widespread technology used for diverse applications, security issues of long-range (LoRa) networks and devices remain a major challenge. Although the LoRa Alliance enhanced the security and the network architecture of LoRaWAN from version 1.0 to version 1.1, the last version still faces some drawbacks such as vulnerability to attacks. Some works have assessed LoRaWAN (v1.0 and v1.1) security risks and vulnerabilities. Moreover, all these specifications must coexist with each other, which makes compatibility an important factor in ensuring the sustainability of this technology. For this reason, we study the vulnerability of the LoRaWAN protocol in the context of compatibility. Hence, we consider four compatibility scenarios and possible cyber-attacks when connecting devices from the two mentioned versions. In this paper, we analyze the LoRaWAN architectures and then discuss the basic security concepts related to the compatibility scenarios between homogeneous or heterogeneous systems integrating the two LoRaWAN versions. After that, we investigate and identify the potential security risks and network vulnerabilities in LoRaWAN technology. We establish a catalog of vulnerabilities for LoRaWAN on a methodological framework. The catalog contains five vulnerabilities related to LoRaWAN v1.0.x and v1.1 and seven vulnerabilities related to LoRaWAN v1.0.x. Then, we check if these vulnerabilities could be applied to the compatibility scenarios. We observe that the majority of vulnerabilities mitigated in LoRaWAN v1.1 remain present in compatibility scenarios.

Moreover, the existence of several versions of LoRaWAN 113 has added new challenges to compatibility and inter-working 114 between devices and gateways (GWs) in the different ver-115 sions. In this context, our main motivation is to identify and 116 assess risks and network vulnerabilities related to several 117 LoRaWAN compatibility scenarios that could lead to a secu-118 rity breach.

119
The objectives of the paper are as follows:

120
(1) to discuss and analyze the security issues related 121 to compatibility between homogeneous or heterogeneous 122 equipments from the two LoRaWAN versions.

123
(2) to establish a catalog of vulnerabilities in LoRaWAN 124 v1.0.x and v1. 1. 125 (3) to discuss if the vulnerabilities listed in the catalog 126 above are still present in LoRaWAN compatibility scenarios. 127 Organization of Paper: The paper is organized as: 128 Section II presents an overview of the LoRaWAN communi-129 cation protocol. Section III explains the two different archi-130 tectures and the role of each component. Section IV, details 131 the basic security concepts related to LoRaWAN with a focus 132 on compatibility scenarios. Section V, lists vulnerabilities 133 related to the LoRaWAN v1.0.x and v1. 1 specifications. 134 Section VI assesses the vulnerabilities in this catalog on com-135 patibility scenarios. Section VII concludes the paper with 136 future scope.

139
LoRa Alliance is a non-profit organization bringing together 140 stakeholders in the field of IoT and LoRa technology. It is 141 an alliance among several organizations such as telecom-142 munications companies, equipment manufacturers, system 143 integrators, sensor manufacturers, entrepreneurial start-ups, 144 and individuals interested in new technologies. 145 The goal of the LoRaWAN Alliance is to develop, promote, 146 and standardize the LoRaWAN communication protocol. The 147 first version of the LoRaWAN protocol was developed in 148 2015, which was then followed by several versions. The 149 LoRaWAN Alliance also delivers certificates of compat-150 ibility to the end devices (EDs). This certificate guaran-151 tees that a particular device is reliable and compliant with 152 the LoRaWAN specification. The alliance also organizes 153 many events and webinars, which provide opportunities for 154 developers, manufacturers, and operators to collaborate and 155 share experiences to promote and drive the success of the 156 LoRaWAN standard as the most promising open global stantifying the ED in the network), frame counters (which must 202 be incremented for each message exchanged), and security 203 session keys (used to encrypt and sign messages). 204 The LoRaWAN protocol includes two ways to gener-205 ate a session context: activation by personalization (ABP) 206 is manual generation and over-the-air-activation (OTAA) is 207 automatic generation. OTAA is performed by exchanging 208 two messages: join-request sent by ED and join-accept as a 209 response from NS. Several security mechanisms have been 210 defined in the protocol, ensuring end-to-end security. The architecture mainly comprises the following compo-230 nents: EDs, GWs, NS, and application server (AS). These 231 components are organized in a star-shaped typology as 232 depicted in Figure 1. The communication between the various 233 ED and GW takes place using the LoRa technology [27], [28], 234 [29], [31]. 235 The ED has a sensor that provides data or an actuator that 236 can control some functions. It may be mobile or immobile. 237 Its primary function consists of capturing and disseminating 238 information from its sensors.

239
The GW is a link between the wireless and wired compo-240 nents of a LoRaWAN network. Its main function is forward-241 ing upLink and downLink communication.

242
The NS is responsible for managing multiple EDs using 243 MAC controls. It is also responsible for performing various 244 security services (authentication, encryption, and integrity). 245 The AS handles application data generated by the EDs 246 under its control. LoRaWAN v1.0.x has been rethought to obtain a new archi-249 tecture. As a result, the NS has been replaced with three 250 named servers: the home network server (HNS), the serving 251 network server (SNS), and the forward network server (FNS). 252 This provides secure roaming services between operators 253 (Figure 2).

254
Every ED is affiliated with one server, that server is called 255 the home network server (HNS). It is exclusively responsible 256 for forwarding data to the AS. It also controls ED's MAC 257 layer.

258
If an ED detects that it is under the coverage of a new server 259 other than its home server, then it has the choice of activating 260 VOLUME 10, 2022  handover roaming or passive roaming [32] (depending on 261 the established agreements between the different operators 262 holding these servers). Handover roaming means that the 263 server, in addition to forwarding data between ED and its AS, 264 controls the MAC layer of the ED. This server is called SNS.

265
While in passive roaming, the server can only transmit data 266 between ED and its application server. This server is called 267 FNS.

268
Another improvement brought by LoRaWAN v1.1 is to 269 add a new server, called join server (JS), which is in charge 270 of executing the activation process when an ED joins the 271 network. This server has the responsibility of deriving and 272 delivering all security session keys. and NetID values. These values will be used to derive two 317 security session keys (NwkSKey and AppSKey) from the 318 AppKey (a root key shared by ED and NS in an out-of-band 319 mechanism). The function used to derive these session keys 320 is AES128_Encrypt [33]. The AppSKey and the NwkSKey 321 are calculated as follows: 322 NwkSKey=AES128_Encrypt(AppKey,0 × 01|AppNonce|NetID|DevNonce) AppSKey=AES128_Encrypt(AppKey,0 × 02|AppNonce|NetID|DevNonce) According to LoRaWAN V1.0.x, NS must create a list 323 containing a number of the latest DevNonce values. All 324 join-request messages carrying a DevNonce in this list must 325 be ignored by the NS. Doing so prevents an old join-request 326 from being sent by malicious entities.

327
In the case of ABP, ED is personalized with a specific 328 AppSKey, NwkSKey, and DevAddr. Hence, the ED can 329 communicate with the appropriate NS without exchanging 330 join-request and join-accept messages.

331
The LoRaWAN V1.0.x sends its messages with an incre-332 mented counter. The ED uses an incremented counter called 333 FCntUp when sending these messages to the NS. The NS 334 must ensure that the message number is greater than the 335 last message received. Another counter is used in reverse 336 called FCntDown. The ED must always verify that the num-337 ber of messages received is greater than the last message. 338 These counters are initialized to zero each time the ED joins 339 its NS. In the case of OTAA, the ED generates a DevNonce value 349 and sends it in a join-request message along with DevEUI 350 and JoinEUI (a global JS identifier in IEEE EUI64 address 351 space). If the ED has permission to join a network, then 352 the NS requests the JS, identified by its JoinEUI, to gen-353 erate a JoinNonce. This nonce replaces AppNonce used in 354 LoRaWAN v1.0.x. DevNonce and JoinNonce are generated 355 in an incremental way.

356
LoRaWAN v1.1 uses two root keys AppKey and NwkKey, 357 which are used to derive security session keys along with 358 DevNonce, JoinNonce, and JoinEUI as follows:

361
In the case of ABP, the ED is personalized with a specific 362 AppSKey, NwkSEncKey, SNwkSIntKey FNwkSIntKey, and 363 DevAddr. Frame counters should be permanently saved and 364 never initialized to zero even after resetting the ED. Further-365 more, we note that JS is not required in the ABP activation 366 mode. Another thing to notice about the ABP activation mode 367 is the addition of the ResetInd MAC command. It must be sent 368 by ED in all its uplink messages until the NS replays by the 369 ResetConf MAC command. This exchange takes place when 370 the ED is powered up. This step is useful to let the NS know 371 that the MAC layer context is lost. LoRaWAN V1.0.x. As a result, two frame counters are used 375 instead of three, a single root key is used, and only two 376 security session keys are generated. Although ED V1.1 has 377 two root keys, only AppKey will be used when generating 378 security session keys.

379
For OTAA mode, the ED increments its DevNonce values 380 and sends them in a join-request message along with DevEUI 381 and JoinEUI. If the ED has permission to join a network, 382 then the NS must respond by sending a join-accept message 383 accordingly to LoRaWAN v1.0.x without using the JS. In this 384 scenario, the AppNonce is generated randomly by the NS.

385
On the ED side, the AppNonce is referred to as JoinNonce.

386
On the NS side, the security session keys and the two frame 387 counters are generated accordingly to LoRaWAN v1.0.x.

388
On the ED side, the security session keys are calculated as  For OTAA mode, it is the responsibility of the JS and the 401 ED to derive all session security keys using the same root 402 key (AppKey) as described in scenario 1.

403
We note that some improvements introduced by

420
In the case of ABP activation, the ED is personalized 421 with a specific AppSKey, NwkSKey, and DevAddr like in 422 scenario 1. Moreover, frame counters should be initialized 423 to zero after resetting the ED, and the NS must do the same 424 thing. All join-request messages are transmitted in plain text. The 428 NS prior to sending join-accept messages encrypts with 429 AppKey using the AES128_Decrypt function (AES in ECB 430 mode). The ED uses the AES128_encrypt function for 431 decrypting the message.

432
The FRMPayload is the only field sent in all data up/down 433 messages in cipher text. This field holds application data or 434 MAC commands based on the value of the FPort field. When 435 the FRMPayload contains the MAC command, encryption is 436 performed using the NwkSKey. AppSKey is used for encrypt-437 ing application data. Regardless of the key used, encryption 438 is performed using the AES Counter Mode (CTR) algorithm 439 ( Figure 3). The join-request and rejoin-request messages are sent without 442 being encrypted. The join-accept message is encrypted with 443 the root key NwkKey if it is triggered by a join-request mes-444 sage. while the JSEncKey is used if the trigger is the rejoin-445 request message. For data up/down messages, the FOpts and 446 FRMPayload are the encrypted fields. The FOpts field carries 447 MAC commands, which is why the NwkSEncKey is used 448 for its encryption. For the FRMPayload field, if it carries 449 application data, then the encryption is performed by using 450 AppSkey; otherwise, the NwkSEncKey is used. Field encryp-451 tion is performed in the same way as LoRaWAN V1.0.x 452 ( Figure 3). As in scenarios 1 and 2, all join-request messages are sent 455 in plain text. To cipher all join-accept messages, the NS 456 uses AppKey together with the AES128_Decrypt function. 457 ED uses AppKey with the AES128_Encrypt function.

458
The NwkSEncKey and NwkSKey derived from NwkKey 459 by the ED and the NS, respectively, during the activation 460 process have the same value. Thus, the encryption of data 461 up/down messages is performed with the NwkSEncKey on 462 the ED side and with the NwkSKey key on the NS side if 463 the FRMPayload carries MAC commands. Otherwise, the 464 AppSkey is used to encrypt the FRMPayload on both sides. 465 As ED implements LoRaWAN V1.1, the MAC commands 466 within the FOpts field are encrypted. When an NS implement-467 ing LoRaWAN V1.0.x receives such a message, it is unable 468 to decipher it because the FOpts field contains plain text 469 information. This situation raises a compatibility issue that 470 the LoRaWAN V1.1 specification has not addressed. Perhaps 471 All messages exchanged between the ED and NS are signed 484 by using the message integrity code (MIC). Its length is four 485 bytes. It is calculated using aes128_cmac function [34]. The

486
MIC is calculated over all the fields in the message.

487
The MIC of the join-request, join-accept, data up, and data 488 down is not calculated using the same security key. Suppose 489 X designates all the fields of the message to be sent.

506
NwkKey is used to sign a join-request messages. JSIntKey 507 is used to sign rejoin-request type 1 and join-accept messages. 508 SNwkSIntKey is used to sign rejoin-request type 0 or 2 509 messages and data down messages. Both SNwkSIntKey and 510 FNwkSIntKey are used to sign data up messages.

511
The MIC for data up is calculated in two halves using two 512 session keys (SNwkSIntKey for the first half and FNwkSIn-513 tKey for the second one) as described above:

541
The ConFCnt filed is located in the block B 1 , which is why 544 it is not used by the ED. The mechanism that prevents the 545 previously cached data acknowledgment message from being 546 replayed is not enabled in this scenario. to encrypt application data, while NwkKey will be used to 566 encrypt control data. This approach will guarantee that the 567 application data will pass through the NS without being read 568 or modified.

569
This improvement will not be used in scenarios 3 and 4.

570
In scenario 3, ED v1.1 must fall back to v1.0.x behavior to 571 encrypt the data by using one root key (NwkKey according 572 to the specification), which it must share with the NS v1.0.x.

573
The same step applies for scenario 4. Le NS v1. all DevNonce incrementally so that every join-request must 590 have a DevNonce greater than the last one.

591
In scenario 3, on the ED side (implementing LoRaWAN 592 v1.1), the DevNonce is generated incrementally and on 593 the NS side (implementing LoRaWAN v1.0.x), a list of 594 DevNonce will be used. We can say that the improvement 595 made by LoRaWAN v1.1 is maintained.

596
In scenario 4, on the ED side (implementing LoRaWAN 597 v1.0.x), the DevNonce is generated randomly and on the 598 NS side (implementing LoRaWAN v1.1), only join requests 599 with a DevNonce greater than the last one used will be 600 accepted. This poses a problem in the sense that a legitimate 601 ED generating a DevNonce lower than the last will be rejected 602 by the NS. The radio transmission between the ED and the gateway made 618 sniffing the exchanged messages easy [35]. In the LoRaWAN 619 protocol, some fields are sent in clear, such as DevEUI, 620 DevNonce, DevAddr, FCntUp, FCntDown, FPort, and FOpts 621 (MAC commands). Although this information is not confi-622 dential, it can be used to infer some information by ana-623 lyzing the network traffic (number of messages exchanged 624 between gateway and ED, the number of ED served by 625 a gateway) [36].

626
While the LoRaWAN protocol uses CSS modulation which 627 is known for its robustness against interference, the authors 628 in [37] showed that LoRa transmissions that use the same 629 frequency and spreading factor interfere with each other. 630 This vulnerability means that radio jamming can be per-631 formed at a specific frequency and spreading factor using 632 commercial off-the-shelf LoRa devices [35]. This type of 633 jamming can easily be detected by the administrator of the 634 network.

635
Selective radio frequency jamming is a jamming attack 636 targeting a specific ED [38]. In fact, the time a message takes 637 to reach its destination varies from 100 ms to 1.5 s. This time 638 is sufficient for a sniffer to demodulate the header part of 639 a message that contains DevAddr and if it corresponds to 640 the targeted device, then the sniffer can perform jamming 641 using the same frequency of the sniffed message. This type 642 of jamming is hard to detect. GWs are deployed in non-monitored areas. This situation 649 makes for a major challenge for LoRaWAN security [39]. The 650 root keys are the most important and if they are ever compro-651 mised, the confidentiality of communications between the ED 652 and NS will be affected. According to [19], this vulnerability nonces. The absence of this procedure will allow a decom-675 missioned ED to join the network again without the owner's 676 authorization. Moreover, the ED's address (DevAddr) will 677 always be reserved and the NS will not be able to assign it 678 to another ED. This vulnerability is stressed in [19].  to manipulate this database, it is possible that the downlink 694 traffic will be cut off. An attack using this vulnerability is 695 described in detail in [40]. Figure 4 illustrates an example of 696 performing a downlink routing attack.

698
As a solution, the authors, in [40], proposed to perform a 699 handshake between ED and NS before updating the downlink 700 routing path database.

701
The LoRaWAN v1.1 specification did not propose any 702 mitigation for this vulnerability. In LoRaWAN, integrity protection is ensured by the MIC 705 field. Unfortunately, this protection is made only between 706 the ED and the NS. Thus, integrity of the application data 707 is unprotected between the NS and the AS. The LoRaWAN 708 specification states, ''Application payloads are end-to-end 709 encrypted between the end-device and the application server, 710 but they are not integrity protected'' [30]. The specification 711 considers the NS a trusted party.

712
Moreover, LoRaWAN uses AES-128 in CTR mode to 713 encrypt data. The bit position is not changed by this mode 714 of encryption. Therefore, the premature termination of the 715 message integrity code and the use of AES in CTR mode 716 allows a bit-flipping attack to be carried out between the NS 717 and the AS [41]. During OTAA, the ED sends a request join message to the 722 NS containing a random number DevNonce (16-bits wide). 723 The NS must check if this number was not used previ-724 ously. This mechanism prevents a malicious ED from replay-725 ing a recorded join-request message. The specification of 726 the LoRaWAN protocol indicates that the NS must store a 727 list of DevNonce previously used. However, the number of 728 DevNonce to be recorded is not mentioned in this specifica-729 tion. According to Tomasin et al. [42],[43], the probability 730 (P) of randomly generating the same number a second time 731 depends on the number of recorded DevNonce (NB) and the 732 number of bits in DevNonce (N = 16) (see formula 1).
If the NB is too large, then the probability of having a 735 legitimate ED send a join message with a randomly generated 736 DevNonce and previously recorded by the NS, increases. 737 If NB is too little, then it allows a malicious ED to send 738 a recorded join-request message after sending a few join 739 requests. Also, N has an impact on this probability. The higher 740 N is, the lower P becomes. The authors in [42] and [43] 741 believe that the best choice for NB is to be greater than or 742 equal to the maximum number of join-request messages an 743 ED sends during its lifetime. Also, they estimate that the prob-744 ability of generating a DevNonce already used before within 745 is used by the ED in join-request and join-accept messages.

785
The NS has already checked the uniqueness of DevNonce; 786 thus, its use in join-accept message will guarantee the unique-787 ness of the latter and prevent it from being replayed. This 788 approach is costly as the length of join-accept will increase 789 by 2 bytes, which will reduce the efficiency.

790
The LoRaWAN v1.1 specification mitigates this vulnera-791 bility by generating JoinNonce (in v1.1, JoinNonce replaces 792 AppNonce) incrementally rather than randomly. Thus, the 793 ED can easily, by checking the current JoinNonce against the 794 last JoinNonce, detect whether the join-accept message was 795 previously used. In OTAA, AppNonce and DevNonce are used to generate 799 a session context on the ED side and NS side. LoRaWAN 800 v1.0.x does not specify any association between join-request 801 and join-accept. This approach allows an already recorded 802 join-accept message to be replayed as a response to a new 803 join-request sent from the OTAA-ED. Figure 6 shows how 804 jamming and replay attacks using this vulnerability cause 805 desynchronization in terms of security keys between ED 806 and NS.    prevent a replay of messages. For ABP or OTAA EDs, the 825 counters will overflow after a certain time. In this case and 826 according to LoRaWAN specification, the counters will be 827 set to zero. The security keys have remained the same, which 828 is why a malicious ED can replay a recorded uplink message 829 using the largest FcntUp it has. Unfortunately, this message 830 will be accepted by NS. This will lead to a case whereby 831 all messages received from legitimate EDs and having an 832 FCntUp less than the one it recorded from the malicious ED 833 would be rejected by the NS (Figure 7). Another method to 834 set counters to zero is to reset the ED. This issue does not 835 pose a problem for the OTAA-ED because it must perform 836 the join procedure to establish new security keys. However, 837 it causes a problem for ABP-activated ED because the same 838 security keys are used. This vulnerability was highlighted in 839 [19], [35], [39], [41], and [44].  the frame counters (FcntUp and FcntDn) as a nonce. There-866 fore, using the same security session keys with the same 867 frame counters leads to the same keystream. Hence, two 868 messages M 1 and M 2 encrypted using the same keystream 869 K leads to its elimination as shown below Miller, in [44], considers this a vulnerability; an attacker 874 knew the plain text of one message, he/she can decrypt all 875 other messages encrypted by the same keystream K. More-876 over, Yang et al. [41] showed that even if the malicious 877 actor does not know any plain text, he/she can guess the 878 content of the messages by using this vulnerability. Suppose 879 the two plain text messages (M1, M2) are unknown to the 880 attacker and their encrypted messages respectively (C1, C2) 881 are known to the attacker. The attacker builds a list containing 882 all the possible combinations of M1. For each combination, 883 it derives message M2 using formula 2. If M2 is readable, 884 then the guess is probably correct. The success of this attack 885 depends on the number of message combinations (must be 886 lower), knowing the message structure, and the number of 887 resetting ED without changing security session keys (bigger 888 will be better). For ABP-ED, this will happen after resetting 889 place if we have an overflow of frame counters. Thus, this attack is more plausible for ABP-ED than for OTAA-ED.  From this table, we note that among the 12 vulnerabil-977 ities already listed, eight of these affect the availability of 978 security service, five for the integrity of service, and only 979 two for the confidentiality of service. This allows us to say 980 that ensuring availability is the predominant challenge that 981 the LoRaWAN specification and future amendments must 982 overcome. We point out crucially that all identified attacks 983 in the cited literature have not considered compatibility 984 scenarios. In the next section, our main contribution is to 985 assess potential attacks related to LoRaWAN compatibility 986 scenarios. The LoRaWAN v1.1 specification does not indicate any par-1024 ticular behavior concerning the management of DevNonce 1025 in compatibility scenarios. Therefore, the two entities will 1026 behave normally while respecting the LoRaWAN version that 1027 it implements. In this scenario, the ED implements the LoRaWAN v1.1 pro-1030 tocol. Thus, the DevNonce is no longer generated randomly 1031 but sequentially. Meanwhile, the NS implements LoRaWAN 1032 v1.0.x, which must save a list of a certain number of 1033 DevNonce used in the last valid session. In this way, replay-1034 ing an old join-request message previously recorded by a 1035 malicious ED is made impossible because the NS can detect 1036 it easily by checking the list. Thus, we can say that for 1037 scenario 3, this vulnerability is no longer possible. In this case, the ED v1.0.x generates the DevNonce randomly 1040 and sends the join-request message. On the backend side, the 1041 NS v1.1 checks the receipt of the message if the DevNonce 1042 used in the received message is greater than the one saved 1043 in its memory. In this way, it is not possible to replay an 1044 old join-request message by a malicious ED but in return, 1045 several join-requests sent by a legitimate ED v1.0.x that do 1046 not respect the DevNonce increment will be rejected by the 1047 NS v1.1. This situation can lead to a denial of service for 1048 ED v1.0.x.   In this scenario, the ED implements the LoRaWAN v1.1 spec-1106 ification. Thus, resetting frame counters without changing 1107 the security key is impossible. Hence, the vulnerability is 1108 mitigated in scenario 3. The ED implements the LoRaWAN v1.1. Therefore, the vul-1119 nerability is mitigated for this scenario. This vulnerability is present in the LoRaWAN v1.0.x spec-1127 ification. However, the LoRaWAN v1.1 specification miti-1128 gated this vulnerability by including the frame counter of 1129 the confirmed message in the MIC calculation of the ACK 1130 message. The caveat is that the MIC calculation method can 1131 only be used when the NS and ED both implement LoRaWAN 1132 v1.1; otherwise, the MIC calculation method must com-1133 ply with the old version of LoRaWAN (v1.0.x). Therefore, 1134 we can conclude that this vulnerability remains valid for 1135 scenarios 3 and 4.

1138
This vulnerability is present in LoRaWAN v1.0.x specifica-1139 tion but mitigated in LoRaWAN v1.1 specification by using 1140 two MAC commands: RekeyInd and RekyConf. These two 1141 commands must be recognized at both the ED and NS. In this scenario, the NS implements v1.0.x. However, the 1144 vulnerability is still present as it is impossible to use the two 1145 MAC commands. Hence, the vulnerability is still valid. When the ED implements v1.0.x in scenario 4, the vulnera-1148 bility is still present as it is impossible to use the two MAC 1149 commands.  Using the previous catalog, we discussed the presence 1188 of the vulnerabilities in the two compatibility scenarios 1189 (scenarios 3 and 4).

1190
Our study on the security of LoRaWAN led us to conclude 1191 that it is a promising protocol in the field of IoT because it 1192 guarantees low power consumption, long range, low speed, 1193 and low deployment cost. Great efforts have been devoted 1194 to the security aspects. However, vulnerabilities remain. One 1195 major issue is that most of the vulnerabilities affect the secu-1196 rity service. The second major issue is that the majority of 1197 vulnerabilities mitigated in LoRaWAN v1.1 remain present 1198 in the two compatibility scenarios.

1199
The scope of this research is limited to the LoRaWAN 1200 specification for class devices without an in-depth study of 1201 MAC commands. In addition, roaming is outside the scope of 1202 this research. Therefore, this work can be further extended. 1203 In particular, class B and C devices in LoRaWAN can be 1204 studied. Further investigation is needed on MAC commands 1205 to see if they have any vulnerabilities. Moreover, roaming, 1206 which offers flexibility for mobile devices, can be studied 1207 to assess the security of data exchanged between different 1208 servers. 1209