<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta>
      <issn pub-type="ppub">1613-0073</issn>
    </journal-meta>
    <article-meta>
      <title-group>
        <article-title>IoT using LoRaWAN: a security analysis⋆</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Anne-Carole Honfoga</string-name>
          <email>anne-carole.honfoga@umons.ac.be</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Michel Dossou</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
          <xref ref-type="aff" rid="aff2">2</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Véronique Moeyaert</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Electromagnetism and Telecommunications Department, Faculty of Engineering (FPMs), University of Mons</institution>
          ,
          <addr-line>Mons</addr-line>
          ,
          <country country="BE">Belgium</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>IoT</institution>
          ,
          <addr-line>LoRa, LoRaWAN, Network Security, Vulnerability, Attack</addr-line>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Research unit in photonics and wireless communications, LETIA/EPAC University of Abomey-Calavi</institution>
          ,
          <addr-line>Abomey-Calavi</addr-line>
          ,
          <country country="BJ">Benin</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Internet of Things (IoT) refers to the process of connecting cyber-physical objects to the Internet, enabling the exchange of data over wireless communication networks with limited human intervention. These communication networks use licensed spectrum or unlicensed spectrum. Instead of licenced spectrum used by Narrowband Internet of things (NB-IoT) and Long-Term Evolution for Machines (LTE-M), SigFox, MIoTy, and Long Range Wireless Area Network (LoRaWAN) employ unlicenced spectrum for communication between the network entities. Among wireless networks using unlicensed spectrum, LoRaWAN is the most used network in many applications (smart farming, smart building, smart metering) but its presents several vulnerabilities. This paper studies the LoRaWAN threats, malicious attacks and mitigation against attacks.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>1. Introduction</title>
      <p>
        Internet of Things (IoT) is an essential element that has
revolutionized the Information and Communication
Technology sector (ICT). Over the past decade, it has been the
focus of much academic and industrial interest, with the
purpose of making buildings, cities, agriculture and
environment smart. This technology refers to the process of
connecting cyberphysical objects (machines) to the
Internet, enabling the exchange (sending and receiving) of data
over wireless communication networks with limited human
intervention. These machines are embedded devices which
present characteristics such as a low energy consumption,
a low computing power, a small size, a small price and a
capacity to communicate within a wireless network. There
are many wireless communication networks classified in
terms of energy consumption and communication range. In
terms of energy consumption, they can be divided into low
power communication (NFC – Near Field Communication,
RFID – Radio Frequency Identifier, Z-Wave, Zigbee, BLE
– Bluetooth Low Energy, LTE-M – Long Term
EvolutionMachine, NB-IoT – Narrowband IoT, SigFox and LoRaWAN)
and high-power communication technologies (Bluetooth,
Wi-Fi – Wireless Fidelity, 3G, 4G and 5G). Regarding the
communication coverage, there are short range
communication networks (&lt; 1km) (e.g. NFC, RFID, Wi-Fi, Bluetooth,
BLE, Z-Wave and Zigbee) and long-range communication
networks (1-15 km) (3G, 4G, 5G, LTE-M, NB-IoT, Sigfox, and
LoRaWAN) [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
      </p>
      <p>
        LoRaWAN is a low cost, low power and long-range
communication network that is developed to fill a gap in IoT
communications. Using this technology belonging to Low
Power Wide Area Networks (LPWAN), sensors or actuators
can send signals over 5 km in urban areas and up to 15 km
in sub-urban areas. Instead of licenced spectrum used by
LoRaWAN’s main competitors (a.k.a other LPWANs) like
NB-IoT and LTE-M, LoRaWAN employs unlicenced
spectrum for communication between the network entities [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ].
et de la Communication de l’ANSALB, June 27–28, 2024, Cotonou, BENIN
⋆You can use this document as the template for preparing your
publication. We recommend using the latest version of the ceurart style.
∗Corresponding author.
†These authors contributed equally.
0000-0002-0550-2611 (A. Honfoga)
© 2024 Copyright for this paper by its authors. Use permitted under Creative Commons License
      </p>
      <p>
        These advantages allow LoRaWAN to be considered as the
technology that is improving the operations of many
industrial sectors (e.g. agriculture, environment) as a
largescale remote monitoring is then possible. However, like
any computer network, and particularly wireless network,
this technology sufers from many security problems that
can be defined following the three security criteria:
availability, integrity and confidentiality. Many specifications of
LoRaWAN have been published since its development by
Semtech Corporation [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]. The security of these technologies
has been improved with the specification version. Indeed,
the first version presents more vulnerabilities than the latest
version 1.1.
      </p>
      <p>This paper reviews LoRaWAN attacks, vulnerabilities and
security measures. It provides a short review and an
analysis of LoRaWAN robustness and gives perspectives about
the robustness improvement. The outline of the paper is
presented as follows: the theoretical background is described
(§II), the literature review is presented (§III), the paper is
ifnalized by the conclusion (§IV).</p>
    </sec>
    <sec id="sec-2">
      <title>2. Theoretical background</title>
      <sec id="sec-2-1">
        <title>2.1. Introduction to LoRaWAN</title>
        <p>Before explaining the behaviour of LoRaWAN protocol, let
us compare LoRaWAN to the LoRa (Long Range)
modulation. LoRa is the modulation type used between two LoRa
devices or between a LoRa device and a gateway (cf Fig.
1). The LoRaWAN term is employed when end-devices can
communicate with the LoRaWAN servers. LoRaWAN is the
extended version of LoRa technology which connects
enddevices to the network server. It includes LoRa modulation
that operates at the physical layer of the network. Fig. 1
shows the LoRaWAN topology.</p>
        <p>LoRaWAN network includes three sub networks. There
is the LoRa radio frequency network presenting a star
topology, the backhaul network connecting Gateways and
Network Servers using Mesh topology or partial Mesh topology
and the backhaul network connecting Network Servers with
Join and Application Servers. Beside the two servers
(Network Server and Application Server) used in LoRaWAN
v1.0, a new server called Join Server is added in LoRaWAN
v1.1 to manage the OTAA (Over the Air Activation)
procedure more securely. The Join Server has been added in
the network to orchestrate in a more secure way the
joinCEUR</p>
        <p>ceur-ws.org
ing procedure used by end-devices (LoRa devices) to join
the network. Also, LoRaWAN v1.1 integrated roaming and
mobility techniques for the end-devices by employing extra
servers called Join Server (JS), forwarding Network Server
(fNS), serving Network Server (sNS).</p>
        <sec id="sec-2-1-1">
          <title>2.1.1. End-devices joining procedures</title>
          <p>
            The joining procedure creates mutual authentication
between an end-device and the LoRaWAN network to which
it is linked. Two joining procedures are used to connect
the end-devices to the servers. There are Activation By
Personalization (ABP) and Over-The-Air Activation (OTAA).
Among them, OTAA procedure is the more secure. It
provides a more flexible and secure way to establish session
keys with the network servers. In OTAA, authentication
is required for devices using two diferent keys for each
device that are generated each time the device joins the
network: Network session Key (NwkSKey) and the
Application session Key (AppSKey). Using two diferent keys
makes it is more dificult to tamper with or read application
data, even if one of the keys has been compromised. These
keys are generated during the two root keys (NwkKey and
AppKey) design. The ABP procedure is not so secure as the
end-devices are directly connected to the network without
join request and join-accept procedures [
            <xref ref-type="bibr" rid="ref1">1</xref>
            ]. Indeed, instead
of key generation during each section, the Network section
Key and the App section Key are directly defined and stored
in the device. This ABP method presents vulnerabilities. By
modifying these keys, communications between the device,
the gateway and the network server can be seen or
intercepted by anyone if the device is connected to the gateway
and Network Server. Let us note that the Network section
Key and the Application section Key are generated using
the same root Key in LoRaWAN v1.0 whereas in LoRaWAN
v1.1 the application root key is diferent from the Network
root key. The AppKey and NwkKey are generated using
the AES-128-bit encryption method. These keys are
specific to each end-device and embedded into the end-device
during its fabrication. A Message Integrity Code (MIC) is
computed once the encryption is done and is calculated over
all the Message Authentication Code (MAC). It ensures the
integrity of the message. MAC is used to check the
messages and the authentication, ensuring that the integrity of
the data has not been altered during transmission. The
integrity is protected hop-by-hop. LoRaWAN exploits various
methods for generating the MIC depending on the direction
of the message, uplink, or downlink [
            <xref ref-type="bibr" rid="ref4">4</xref>
            ]. The MIC check
is performed on the data to avoid data tampering without
the Network section key (NwkSKey). Table 1 presents the
comparison of OTAA and ABP procedures.
Three kinds of operation for devices are defined in
LoRaWAN: class A, class B, and class C. All end-devices must
support class A operation. class A device can not receive
signal from the gateway if an uplink transmission has not
been yet transmitted. It represents the device class in which
the end-device spends more time in sleep mode. Only two
receive windows are scheduled for down-link messages
reception. Class B device can be regularly joined without a
previous uplink transmission. It ofers regularly-scheduled,
ifxed-time opportunities for an end-device to receive
downlink messages from the gateways, allowing class B
enddevices convenient for sensors and actuators monitoring.
Class C device can always be joined. It is always listening
for downlink messages, unless they are transmitting uplink
messages. Like class A device, class C device implements
the same two receive windows, but it does not close the
second reception window until it sends the next transmission
back to the network server. The class C device is a power
consuming device compared to the class B device which in
turn consumes more energy than the class A device [
            <xref ref-type="bibr" rid="ref1">1</xref>
            ] (cf
Fig. 2).
          </p>
        </sec>
      </sec>
      <sec id="sec-2-2">
        <title>2.2. Security Analysis</title>
        <p>LoRaWAN security challenges are related to diferent parts
of the network. The main parts are the network entities
(gateways, servers, and end-devices), the key distribution
methods, the network implementation, and the roaming
techniques integrated in LoRaWAN v1.1, and the backward
compatibility challenges. In this section, LoRaWAN
vulnerabilities and attacks are presented.</p>
        <sec id="sec-2-2-1">
          <title>2.2.1. LoRaWAN vulnerabilities</title>
          <p>Network security vulnerabilities are weaknesses within the
system’s software, hardware, or organizational processes.
Their can be either non-physical or physical. The main
vulnerabilities of LoRaWAN are: the long times
communication induced by Long Range transmission, the coexistence
problem of LoRa, and backward compatibility challenges.
• Long times communication induced by Long
Range transmission
Spreading Factor (SF) is a parameter used in spread
spectrum modulation techniques like Long Range
(LoRa) modulation, to control the spreading of a
signal over a wider bandwidth. The larger SF is, the
longer the distance the device can receive or
transmit. Eight Spreading Factor (SF5, SF6, SF7, SF8, SF9,
SF10, SF11 and SF12) are used in LoRa transmissions
whereas in LoRaWAN six SF are used (SF7 to SF12).
The elapsed time on air of a LoRaWAN messages
increases with the Spreading Factor (SF) and then
the transmission distance. Indeed, the time on air
increases with the symbol transmission time (  )
(1). The symbol transmission time is defined by
the formula (2). For a fixed bandwidth, the symbol
transmission time increases with the spreading
factor value (cf Fig. 3). In particular, symbol duration
increases by a factor of 2 from one SF to the next. As
shown on this figure, the start frequency (low
frequency) is the channel frequency (center frequency)
minus the channel bandwidth divided by two. The
ifnal frequency (high frequency) is the channel
frequency plus the channel bandwidth divided by two.
  −  −  = 
 
=
 ℎ

2
×  
(1)
(2)
As high SF (up to SF12) is required for the network
edge end-devices to communicate with the gateway,
a mock device can intercept messages or falsify
packets intended for the gateway. Furthermore, there is
no time-related information in LoRaWAN packet.
As LoRaWAN packet structure does not include any
time-based signature or data to validate the time of</p>
        </sec>
        <sec id="sec-2-2-2">
          <title>2.2.2. LoRaWAN attacks</title>
          <p>the message, this vulnerability is used to employ a
wormhole attack.
• Coexistence problem of LoRa</p>
          <p>
            LoRa transmission is sensible to interference issues
such as interference from Cellular Networks (Global
System for Mobile Communications (GSM),
Universal Mobile Telecommunications System (UMTS), and
Long Term Evolution (LTE)) (which can make less
sensitive LoRa receivers, making it hard to receive
weak signals) and In-Band and Out-of-Band
interference [
            <xref ref-type="bibr" rid="ref5">5</xref>
            ]. In-band interference occurs when other
devices operate on the same or adjacent channels,
while out-of-band interference comes from strong
signals outside the useful band. When LoRa
transmissions are performed at the same frequency using
the same spreading factor in the same area (In-Band
interference), they can interfere with each other.
This LoRa physical Layer vulnerability can be
exploited for jamming attack as this transmission is
performed using unlicensed spectrum.
• Backward compatibility challenges
          </p>
          <p>Backward compatibility problems occur when a
newer version of a software or hardware system is
not able to work with the data or functionality of an
older version. In LoRaWAN security case, LoRaWAN
v1.1 aims to improve security, but it may be dificult
to ensure backward compatibility with devices using
earlier versions (v1.0). In fact, the Network Server is
responsible for deciding which protocol version to
exploit and chooses the highest common version
between itself and the End-Device (ED). As LoRaWAN
v1.0 presents more security weaknesses than
LoRaWAN v1.1, the backward compatibility ofered by
the evolved version could constitute a vulnerability.
• Jamming attack</p>
          <p>Radio Jamming attack consists in disrupting the
LoRa radio transmission by transmitting a powerful
radio signal in the proximity of application devices.
It is possible to jam LoRa messages using well timed
malicious transmissions. This attack is usually
performed using a dedicated hardware (ie
Commercialof-the-shelf (COTS)) to jam LoRa devices. There are
no real countermeasures to prevent this attack. But
network administrators can easily detect jamming
when devices transmitting into the network start
to disappear. They may then decide to switch to
another frequency in the band to avoid the impact
of jamming.
• Selective jamming attack</p>
          <p>
            Selective jamming constitutes the most sophisticated
and eficient jamming technique which could be
effective using a COTS hardware by extending the
jammer with additional software to target a specific
device address [
            <xref ref-type="bibr" rid="ref2">2</xref>
            ]. Selective jamming only jams
selected devices or messages. As other devices or
messages on the network are not jammed, it can
be much more dificult for the network operator
or administrator to decide whether an ED is being
jammed, or whether some other technical problem
has occurred. Then, the countermeasures available
for the classical jamming attack are not possible in
the case of selective jamming attack.
• Replay attack
          </p>
          <p>Replay attack is performed on security protocol by
repeating the available data transmitted by malicious
entity Fig. 4). Replay attack is an attack on the
security protocol that consists in resending captured
messages from the end-devices. Its objective is in
the Denial of Service of an end-device This attack is
possible using the communication frequencies and
channels to snif data from transmission between
devices (end-devices and Gateways). Predator may
intercept and replay legitimate messages,
compromising the network’s security. The use of frame
counters process helps LoRaWAN network to know
if the message is sent by the gateway instead of a
malicious device. Indeed, once the end-device is
activated, both frame counters (from the end-device
and the gateway) are set to 0, and each message
coming from the gateway, or the device increments
the counters. By this way, if a message is received
with a lower frame counter than the last message,
it is ignored. But this process could be exploited by
attackers to produce a Denial of Service.
• Wormhole attacks</p>
          <p>
            A wormhole attack is an attack which can be
performed against a LoRaWAN network. This attack
consists in packet snifing and replaying them. One
malicious device captures the packets from one
device and transmits them to another distant located
device to replay the captured packet. The two
devices which participate to this attack are the snifer
and the jammer. The snifer captures packets and,
transmits signal to the jammer informing that it
apprehended the packet [
            <xref ref-type="bibr" rid="ref2">2</xref>
            ]. By this way, the packet
does not reach the gateway and is still active for
validation. This packet could be forwarded to the
gateway at any time as there is no time related
information in LoRaWAN messages.
• Eavesdropping
          </p>
          <p>
            As already presented, LoRaWAN implements
channel confidentiality through AES in counter mode,
where the block counter value is exploited as an
input. During a counter reset, the key will remain in
place, meaning that the block cipher will
reconstitute the same key material. An attacker can exploit
this comportment to decrypt messages.
• Bit-Flipping Attack (Man-in-the-Middle, MitM)
LoRaWAN messages are encrypted and carry a MIC.
But the encryption and the integrity check are
managed at diferent locations inside a message frame.
The payload encryption is handled by the
Application Server, while the MIC is checked and terminated
by the infrastructure provider (Network Server (NS))
[
            <xref ref-type="bibr" rid="ref6">6</xref>
            ]. Then, between the infrastructure provider’s
network server and the IoT solution provider’s
Application Server (AS), the content can not be checked for
integrity and authenticity. An attacker can attempt
to intercept anywhere between the NS and the AS.
This attack can be achieved through a variety of
approaches, ranging from routing-based approach,
such as Border Gateway Protocol (BGP) Route
hijacking or IP source routing, to physical and link
layer-based ones, such as a compromised device on
the path [
            <xref ref-type="bibr" rid="ref7">7</xref>
            ]. This attack consists in the illegitimate
takeover of groups of IP addresses by corrupting
Internet routing tables maintained using BGP
protocol.
• Rogue gateway attack
          </p>
          <p>LoRaWAN gateways are obeying relays and then
constitute the weakest link of the network. Any
kind of security problem on this node would
interrupt communication between the end-devices and
the servers. One of the attacks faced by LoRaWAN
gateways is the use of a rogue gateway that acts
like as a legitimate gateway. One can distinguish
two kind of attacks: LoRa class B attack (beacon
synchronization Denial of Service (DoS) attack) and
Impersonation attack.</p>
          <p>– Beacon synchronization DoS attack</p>
          <p>This attack is a typical malicious gateway
attack that use class B device vulnerability.
In LoRaWAN, class B beacons received in
downlink transmission are not secured by
any methods, indicating that an attacker can
deploy a malicious gateway to send
counterfeit beacons. The result is that class B
enddevices will receive messages in windows
outof-sync with the malicious gateway. By
sending out beacons randomly a malicious
gateway could desynchronize an end device from
receiving windows of another gateway. This
could cause a denial of service, as the
legitimate gateway sends messages when the end
device is not receiving. To deal with this
attack, a key should be exploited by gateways
to authenticate beacons communications.
– Impersonation attack</p>
          <p>Gateways can also be impersonated to create
attacks against end-devices. End-devices can
be listened to and their network address can
be determined. Furthermore, a triangulation
method (minimum 3 gateways are required in
this case to perform the intended capturing
attack the end-device).</p>
          <p>Besides the attacks previously presented, there are
also network spoofing attack, selective forwarding
attack, sinkhole or blackhole attack ... In the
following section, a short literature review of papers about
LoRaWAN security is presented.</p>
        </sec>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>3. Literature review</title>
      <p>Table 2 presents a literature review on papers related to
LoRaWAN security.</p>
      <p>Reactive jamming
using Channel
Activity Detection
(CAD) mechanism
detection, using
a combination of
channel hopping
and transmission,
and using CAD
detection, channel
hopping and
transmission</p>
    </sec>
    <sec id="sec-4">
      <title>4. Conclusion</title>
      <p>This paper presents a security analysis of LoRaWAN v1.1.
The main vulnerabilities and attacks are summarized. It
gives a review on papers that address this network security.
It is shown that the main physical layer security attacks are
jamming and attack replay while other attacks can afect
the network availability, integrity and confidentiality.</p>
    </sec>
    <sec id="sec-5">
      <title>5. Acknowledgments</title>
      <p>This work has been carried out under support from the
ARES within the frame of a post-doctoral mobility grant
in the Electromagnetism and Telecommunications Service
(UMONS/FPMs/Belgium).</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          [1]
          <string-name>
            <given-names>S.</given-names>
            <surname>Montagny</surname>
          </string-name>
          ,
          <article-title>LoRa-LoRaWAN and internet of things for beginners, Available: www. univ-smb. fr/lorawan (</article-title>
          <year>2021</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>E.</given-names>
            <surname>Aras</surname>
          </string-name>
          ,
          <string-name>
            <given-names>G. S.</given-names>
            <surname>Ramachandran</surname>
          </string-name>
          ,
          <string-name>
            <given-names>P.</given-names>
            <surname>Lawrence</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            <surname>Hughes</surname>
          </string-name>
          ,
          <article-title>Exploring the security vulnerabilities of LoRa, in: 2017 3rd IEEE international conference on cybernetics (CYBCONF)</article-title>
          , IEEE,
          <year>2017</year>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>6</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <given-names>I.</given-names>
            <surname>Butun</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.</given-names>
            <surname>Pereira</surname>
          </string-name>
          ,
          <string-name>
            <given-names>M.</given-names>
            <surname>Gidlund</surname>
          </string-name>
          ,
          <article-title>Security risk analysis of LoRaWAN and future directions</article-title>
          ,
          <source>Future Internet</source>
          <volume>11</volume>
          (
          <year>2018</year>
          )
          <article-title>3</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [4]
          <string-name>
            <given-names>H.</given-names>
            <surname>Noura</surname>
          </string-name>
          ,
          <string-name>
            <given-names>T.</given-names>
            <surname>Hatoum</surname>
          </string-name>
          ,
          <string-name>
            <given-names>O.</given-names>
            <surname>Salman</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.-P.</given-names>
            <surname>Yaacoub</surname>
          </string-name>
          ,
          <string-name>
            <surname>A</surname>
          </string-name>
          . Chehab,
          <article-title>LoRaWAN security survey: Issues, threats and possible mitigation techniques</article-title>
          ,
          <source>Internet of Things</source>
          <volume>12</volume>
          (
          <year>2020</year>
          )
          <fpage>100303</fpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [5]
          <string-name>
            <given-names>K.</given-names>
            <surname>Michel Gilbert</surname>
          </string-name>
          ,
          <article-title>LoRaWAN gateways: Radio coexistence issues and solutions</article-title>
          ,
          <source>LoRa Alliance</source>
          (
          <year>2021</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          [6]
          <string-name>
            <given-names>F.</given-names>
            <surname>Kuntke</surname>
          </string-name>
          ,
          <string-name>
            <given-names>V.</given-names>
            <surname>Romanenko</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Linsner</surname>
          </string-name>
          ,
          <string-name>
            <given-names>E.</given-names>
            <surname>Steinbrink</surname>
          </string-name>
          , C. Reuter,
          <article-title>LoRaWAN security issues and mitigation options by the example of agricultural iot scenarios</article-title>
          ,
          <source>Transactions on Emerging Telecommunications Technologies</source>
          <volume>33</volume>
          (
          <year>2022</year>
          )
          <article-title>e4452</article-title>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          [7]
          <string-name>
            <given-names>M.</given-names>
            <surname>Santamaria</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Marchiori</surname>
          </string-name>
          ,
          <article-title>Demystifying LoRaWAN security and capacity</article-title>
          ,
          <source>in: 2019 29th International Telecommunication Networks and Applications Conference (ITNAC)</source>
          , IEEE,
          <year>2019</year>
          , pp.
          <fpage>1</fpage>
          -
          <lpage>7</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          [8]
          <string-name>
            <given-names>S. J.</given-names>
            <surname>Philip</surname>
          </string-name>
          ,
          <string-name>
            <surname>J. M. McQuillan</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          <string-name>
            <surname>Adegbite</surname>
            ,
            <given-names>LoRaWAN</given-names>
          </string-name>
          <year>v1</year>
          .
          <article-title>1 security: Are we in the clear yet?</article-title>
          ,
          <source>in: 2020 IEEE 6th International Conference on Dependability in Sensor, Cloud and Big Data Systems and Application (DependSys)</source>
          , IEEE,
          <year>2020</year>
          , pp.
          <fpage>112</fpage>
          -
          <lpage>118</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          [9]
          <string-name>
            <given-names>T.</given-names>
            <surname>Perković</surname>
          </string-name>
          ,
          <string-name>
            <given-names>H.</given-names>
            <surname>Rudeš</surname>
          </string-name>
          ,
          <string-name>
            <given-names>S.</given-names>
            <surname>Damjanović</surname>
          </string-name>
          ,
          <string-name>
            <given-names>A.</given-names>
            <surname>Nakić</surname>
          </string-name>
          ,
          <article-title>Lowcost implementation of reactive jammer on LoRaWAN network</article-title>
          ,
          <source>Electronics</source>
          <volume>10</volume>
          (
          <year>2021</year>
          )
          <fpage>864</fpage>
          .
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>