See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/325493576

Analysis of LoRaWAN v1.1 security: research paper

Conference Paper · June 2018

DOI: 10.1145/3213299.3213304

CITATIONS READS
6 2,425

3 authors:

Ismail Butun Nuno Pereira

Mid Sweden University Polytechnic Institute of Porto
41 PUBLICATIONS   665 CITATIONS    74 PUBLICATIONS   461 CITATIONS   

SEE PROFILE SEE PROFILE

Mikael Gidlund
Mid Sweden University
183 PUBLICATIONS   1,735 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Securing the Industrial Internet of Things View project

SENODS View project

All content following this page was uploaded by Ismail Butun on 06 September 2018.

The user has requested enhancement of the downloaded file.

 Analysis of LoRaWAN v1.1 Security∗
Research Paper†
Ismail Butun‡ Nuno Pereira
Mid Sweden University School of Engineering,
Sundvall, Sweden Polytechnic Institute of Porto
ismail.butun@miun.se Porto, Portugal
nap@isep.ipp.pt
ABSTRACT
LoRa and the LoRaWAN specification is a technology for Low
Power Wide Area Networks (LPWAN) designed to allow connectiv-
ity for connected objects, such as remote sensors. Several previous
works revealed various weaknesses regarding the security of Lo-
RaWAN v1.0 (the official 1st draft) and these led to improvements
included in LoRaWAN v1.1, released on Oct 11, 2017. In this work,
we provide the first look into the security of LoRaWAN v1.1. We
present an overview of the protocol and, importantly, present sev-
eral threats to this new version of the protocol. Besides, we propose
our own ramification strategies for the mentioned threats, to be
used in developing next version of LoRaWAN. The threats presented
were not previously discussed, they are possible even within the
security assumptions of the specification and are relevant for prac-
titioners implementing LoRa-based applications as well researchers
and the future evolution of the LoRaWAN specification.
CCS CONCEPTS
• Security and privacy → Mobile and wireless security; • Net-
works → Mobile and wireless security; Security protocols;
KEYWORDS
IoT, security, vulnerability, LoRa, LPWAN
ACM Reference Format:
Ismail Butun, Nuno Pereira, and Mikael Gidlund. 2018. Analysis of Lo-
RaWAN v1.1 Security: Research Paper. In SMARTOBJECTS’18: 4th ACM
MobiHoc Workshop on Experiences with the Design and Implementation of
Smart Objects, June 25, 2018, Los Angeles, CA, USA. ACM, New York, NY,
USA, 6 pages. https://doi.org/10.1145/3213299.3213304
∗ Although the title mentions about latest version, paper also provides plentiful infor-
mation about LoRaWAN v1.0.
† This work was supported by the SMART Project, EU Regional Fund [grant number
20201010].
‡ Dr. I. Butun is the corresponding author.
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.
SMARTOBJECTS’18, June 25, 2018, Los Angeles, CA, USA
© 2018 Association for Computing Machinery.
ACM ISBN 978-1-4503-5857-6/18/06. . . $15.00
https://doi.org/10.1145/3213299.3213304
Mikael Gidlund
Mid Sweden University
Sundvall, Sweden
mikael.gidlund@miun.se
1 INTRODUCTION
Internet of Things (IoT) is revolutionizing the IT sector. Due to tech-
nological predictions, by the end of 2020, 20 billion IoT devices are
expected to exist and seamlessly connect each other on the global
Internet, in order to sense and actuate according to surrounding
environmental stimulants [11].
There are many communication technologies suitable for IoT de-
vices. For example, short-range communications technologies such
as Bluetooth, ZigBee, and Z-Wave, have been utilized by resource-
constrained IoT networks because of their low-energy consumption.
However, these are handicapped by their short communication
range when applications require coverage of large areas, such as
smart cities. Low Power Wide Area Network (LPWAN) enable long-
range communications with low energy consumption such that
resource constrained sensors/actuators can transmit signals up to
10s of km (up to 5km in urban, 12 km in suburban) and continued
operation-using batteries for up to 10 years without external power
sources [7]. LPWAN will have an important role in this growth, and
these technologies have an increasing market share among other
IoT technologies, with a projected market worth of 24.5 Billion USD
by 2021 [18].
LoRa (by Semtech Inc. [19]) is an LPWAN technology with sev-
eral competitors, e.g: SigFox (SigFox Inc. [21]), Weightless (Weight-
less Special Interest Group - SIG [27]), WAVIoT (Waviot Inc. [26]),
Nwave (Nwave Technologies Inc. [16]), RPMA (Ingenu Inc. [9]),
UNB (Telensa Inc. [22]), and Qowisio (Qowisio Inc. [17]). LoRa is an
attractive option due to the open nature of the upper layers, with its
LoRaWAN open specification [25], the availability of off-the-shelf
and low-cost platforms (see, for example [8]) and significant user
support, for example from efforts such as the “The Things Network”,
a crowd-sourced community from 85 countries building a global,
public LoRa-based IoT data network [23].
LoRa is a proprietary physical layer protocol that facilitates
low-power and long-distance communication up to 20 km by using
Chirp Spread Spectrum (CSS) modulation technique [20]. LoRaWAN
is the upper layer protocol based on LoRa in which the structure
and operation of the entire system are defined. Our work focuses
on the LoRaWAN specification, and particularly, LoRaWAN v1.1
[2], which was released on Oct 11, 2017. LoRaWAN v1.1 was a
major overhaul of the protocol specification. In terms of the overall
architecture, LoRaWAN v1.1 introduces mechanisms for roaming
of end-devices (which results in the introduction of three new roles
for Network Servers), and a new security model based on yet a new
architecture element: the Join Server.
SMARTOBJECTS’18, June 25, 2018, Los Angeles, CA, USA
Figure 1: LoRaWAN v1.1 architecture layout.
Several discussions and analysis have been made in the literature
on the security of the previous version of LoRaWAN and these are
presented in Section II. Previous work has shown that v1.0 suffers
from several weaknesses that may lead to attacks to the network
availability, data integrity, and data confidentiality. These works
were taken as input to the latest version of LoRaWAN (v1.1) which
has addressed them. Being a recent specification the security of
LoRaWAN v1.1 still has a reduced amount of scrutiny and, to the
best of authors’ knowledge; this is the first paper in the literature
discussing the security vulnerabilities of LoRaWAN v1.1. It is also
the first technical paper with an overview of the features of Lo-
RaWAN v1.1. With the proliferation of IoT devices, LPWAN devices
and especially LoRaWAN networks are dependent on the public
acceptance of these devices as a part of a trusted system. Hence,
it is utmost important to prove that security of these systems is
sufficient to guarantee the privacy of the user data that is being
transferred (generally from the end-devices to the data sink). So,
enhancing the security level of these LoRaWAN devices is very
important to acquire public support and acceptance. Our analysis
of the security features of LoRaWAN v.1.1 and, more importantly,
the practical threats to this latest version of the protocol that we
bring to light are an important contribution to the improvement of
the LoRaWAN specification.
The structure of this article is as follows: Section II contains an
overview of LoRaWAN 1.1, focusing on its security aspects. Section
III overviews previous related work found in the literature, but
which addressed previous versions of LoRaWAN. This is followed
by a Section IV where we present and discuss several security
threats to LoRaWAN v.1.1. Finally, the article ends with Section V,
which is comprised of conclusions and future work.
2 OVERVIEW OF LORAWAN V1.1
LoRaWAN v1.1 was a major update of the LoRaWAN specification
introduced in October 2017 [2][16]. Figure 1 depicts the architec-
ture layout of LoRaWAN v1.1. Similar to previous versions, the
network is composed by end-devices that are connected with a sin-
gle hop to one or more Gateways which, in turn, forward packets
to the Network Server (N S) through a back-haul network using IP
protocols.
I. Butun et al.
The N S is a central element of the network architecture and is
responsible for: checking addresses of end-devices; checking re-
ceived frames authenticity and frame counters; acknowledgements;
handling MAC layer requests; forwarding application payloads to
and from the Application Servers (AS); forwarding requests to join
the network to Join Servers (JS). LoRaWAN v1.1 introduced a roam-
ing architecture where an NS can have different roles: Home (hN S),
Forwarding (f N S) and Serving (sN S), depending on the type of
roaming involved.
The JS handles requests to join the network from end devices
which are forwarded by one or more N S. The JS plays an important
role in the process of joining nodes to the network and we will
detail it next. Finally, the AS handles the application layer payloads
being forward to/from the N S.
2.1 Device Activation
To participate in a LoRaWAN network, each end-device has to be
personalized and activated. Activation of an end-device can be
achieved in two ways:
• Over-The-Air Activation (OTAA)
• Activation By Personalization (ABP).
In either case, before activation, nodes need to be configured with
some information (such as keys, device and network identifiers) and
this can happen at the manufacturer of the end-device, or during
commissioning.
An important enhancement in LoRaWAN v1.1 is the complete
separation between network and application trust by using two
separate keys. It is important to note the requirement that keys are
device-specific; that is, each device should have its own set of keys,
and disclosing these keys should affect only that end-device.
2.1.1 OTAA. This procedure provides a flexible and secure way
of establishing session keys with the servers and is the recom-
mended activation procedure. End-devices transmit a join_request
message that will be processed by the N S, which, with the help of
the JS (the Join Server is found using the JoinEU I , received by the
N S in the join_request and in the end-device) validates it and replies
with a join_accept message. Using the two device-specific root
keys (NwkKey and AppKey; also configured before deployment)
and information in the join_accept message, end-devices derive
Analysis of LoRaWAN v1.1 Security SMARTOBJECTS’18, June 25, 2018, Los Angeles, CA, USA

Figure 2: LoRaWAN v1.1 Over-The-Air Activation (OTAA) procedure.

Table 1: Summary of LoRaWAN v1.1 parameters and keys

SMARTOBJECTS’18, June 25, 2018, Los Angeles, CA, USA
their session keys (NwkKey is used to derive the F NwkSIntKey,
SNwkSIntKey and NwkSEncKey session keys, and AppKey is used
to derive the AppSKey). OTAA is an important feature of LoRaWAN
and Figure 2 illustrates this mechanism in detail considering a
join_request to an hN S (home N S). Table 1 complements this infor-
mation with a description of the relevant message fields, counters,
nonces, and keys, along with their storage requirements. Table 1
also includes information about how session keys are derived dur-
ing the OTAA procedure and these details will be useful in Section
IV. Here, the main difference from the earlier version is that now
the network session keys are derived from the root key of NwkKey,
whereas application session key is derived from the root key of
AppKey (here, note that aes128_encrypt stands for encryption with
128bits AES Algorithm).
2.1.2 ABP. In ABP procedure, either manufacturer puts the ses-
sion keys to the end-devices (to be tracked and matched by the
unique serial numbers such as the DevEU I ) from a pre-defined
pool key, or application manager creates these keys later on and
distributes it to both end-devices and servers manually. ABP can
be an easy way to simplify deployment, at the cost of reduced
security, as ABP devices will often use the same session keys for
their lifetimes (manual reconfiguration of the device is possible).
In this case, the end-device is simply configured with the needed
Network (NwkSEncKey, SNwkSIntKey, F NwkSIntKey) and Ap-
plication (AppSKey) session keys.
3 RELATED WORK
LoRaWAN was the subject of many previous work, which analyzed
its security and proposed enhancements to the specification. Due
to its recent release, no work dedicated to LoRaWAN v1.1 was
found. In this section, we review work on previous versions of
LoRaWAN, which might not be applicable to the latest version
due to the changes introduced and also because it considered and
addressed issues reported earlier. This previous work is, however,
useful to understand the evolution of the specification and has an
overview of enhancements previously proposed.
In [3], the authors focused on a problem with LoRaWAN’s key
provisioning method. In the LoRaWAN v1.0, the Network Server
(N S) generates both session keys: the network session key to be
used by N S and the application session key to be used by the AS
and this would violate the trust separation between N S and AS. As
a solution to this problem, the authors propose a new LoRaWAN
network structure with PKI participating as the trusted third party.
A related work [10] proposed a scheme using dual keys for end-
device activation to improve the separation of trust between in
the generation of application and network session keys. Actually,
this proposal somewhat is acquired by the newest version (v1.1),
hence the alliance introduced a new root key (NwkKey). With the
inclusion of new root key, and as described in Section II (and also in
Figure 2), now the session keys of application and network sessions
are generated separately (refer to equations in Table 1) during the
OTAA activation phase.
The DevNonce (LoRaWAN v1.0) is a random number generated
by the end-devices, used to prevent replay attacks during the session
key generation. In [29], it was shown mathematically that with the
DevNonce generation system of LoRaWAN v1.0, the end-devices
I. Butun et al.
can be unavailable with a certain probability, and increasing the
size of the DevNonce field to 24-32 bits would mitigate this problem.
The DevNonce was also the focus of [24], where authors concluded
that by making use of jamming techniques; the DevNonce number
pool can be diminished in a short period of time. As a result, after
then, all of the join_request messages from the end-device would
be rejected by the N S.
Naoui et al. [15] proposed a new security architecture for Lo-
RaWAN v1.0. The proposed scheme employs proxy nodes, which
perform several other functions, including the basic function of the
conventional LoRaWAN v1.0 gateway. However, the authors do not
provide details of how to incorporate these proxy nodes into the
existing LoRaWAN architecture.
Some LoRaWAN v1.0’s vulnerabilities and related countermea-
sures were discussed in [13]. This work reported several vulner-
abilities in the phases of key management, communications, and
network connection.
In [14], Na et al. have argued that the join request message sent
by the end-device to the N S during the OTAA procedure is not
encrypted and therefore vulnerable to replay attacks. They have
proposed a countermeasure to prevent this. However, authors have
missed the point that N S is keeping the list of used DevNonce’s
and automatically protects the network from bad ramifications of
the replay attacks.
Regardless of the version being used for LoRaWAN networks,
owing to wireless communications technology, these networks
might be susceptible to inter-network interference as well as the
jamming attacks. The imminent threat is not as serious as in the
other narrow-band wireless technologies. Hence, the CSS modula-
tion of the LoRa spreads the use of the channels to a wider band, the
ill effects of these wireless communications problems are somewhat
mitigated. However, as mentioned in [4], more elaborate jamming
attacks, such as a selective-jamming attack, can be hard to detect
and decrease network performance drastically.
In [28], the author has presented several vulnerabilities of Lo-
RaWAN v1.0. The Author refers to a “bit-flipping attack” which is
actually a “man-in-the-middle attack”, in which an attacker modifies
the messages in between the N S and the AS. Because the communi-
cations between these servers are not encrypted, LoRaWAN v1.0 is
susceptible to this kind of attack. Same vulnerability is still valid for
LoRaWAN v1.1, in which several servers exist in the architecture
and all of which communicate without encryption.
Interestingly, in [12] authors proposed the usage of block-chain
technology, in order to increase the trust value of LoRaWAN v1.0
technology. They argued that the block-chain could be used among
several N S to verify each data transaction. Although the idea of
block-chain technology might be interesting, it is too computation-
ally expensive for IoT implementations such as LoRaWAN. Here,
the main aim is to decrease the cost while maintaining some level
of security and trust. Besides, in LoRaWAN (in both versions), all
servers are assumed to be trusted, hence there is no verification
of the data transactions in between the servers is required. Al-
though this might be a weak point of the architecture, conventional
Secret-Key-Cryptography encryption algorithms might be used in
between the servers of LoRaWAN in order to make certain that
end-to-end security is provided.
Analysis of LoRaWAN v1.1 Security
4 SECURITY ANALYSIS OF LORAWAN V1.1
In this section, we provide a discussion of security threats to Lo-
RaWAN v1.1. These threats are based on an analysis of the protocol,
its variations from the previous version, and formerly known se-
curity issues. We restricted this analysis to only consider threats
within the assumptions stated in the specification [2] (see discussion
in Conclusions about a broader analysis). Importantly, we disclose
several attacks to LoRaWAN v1.1 that, to the best of our knowledge,
were not previously discussed. Threats are categorized using the
main attack categories for wireless communication from [28] in the
summary presented in Table 2. The remainder of this section details
the threats, which are valid for the latest version of the specification,
but only #2 “OTTA attack” is specific to LoRaWAN v1.1.
4.1 RF jamming attack
It is possible to jam reception at a gateway or a node, and this has
been shown possible in the past, using low cost, and commodity
hardware [4]. Jamming attacks in wireless network lead do Denial-
of-Service (DoS), which are generally easy to detect. However, se-
lective RF jamming attacks are hard to detect and very harmful for
wireless communications as it is not easy to avoid.
4.2 Replay attack
Attacks taking advantage of the join procedure of LoRaWAN v.1.1
is possible by using selective RF jamming technique. A persistent
attacker can jam selectively the signals (by using smart sensing
technology) that are intended for OTAA session. In a scenario of
this attack, the transmission of a Join-request (Join−request#1 with
DevNonce#1) from a legitimate ED is jammed while this request
(Join − request#1) is captured at the same time. After waiting for a
timeout to receive the Join-accept, the ED retries to join the net-
work and sends another Join-request (Join_request#2) with a new
DevNonce value (DevNonce#2) as required by the specification.
The attacker will jam this message too. After, the attacker replays
the previously saved Join_request (Join − request#1) message. By
checking the value of DevNonce (DevNonce#1), the N S would ac-
cept the join_request, as this value has not been used before. From
now on, the N S, JS and ED are de-synchronized in terms of the
DevNonce, meaning the session keys derived will not match as all
of them are independently generated (by the ED and JS) using the
DevNonce (see Figure 2 for details of the OTAA Join procedure;
Table 1 includes information about how session keys are generated).
This attack is especially valid for LoRaWAN since the communi-
cation is limited and under quota. For instance, each ED is allowed
to transmit at most 14 packets per day (maximum packet payload of
12 Bytes), including the acknowledgments for confirmed up-links
[1].
In order this attack to be successful, it requires that the attacker
can receive packets from the ED and, at the same time, jam their
reception. This can be achieved, for example, by having a device
receiving the packet from the ED outside the interference range of
the jamming device and have it signaling and forwarding the pack-
ets from the ED, which might not always be possible depending on
the transmission range and distance to the nearest GW . This attack
is made substantially more difficult with the existence of several
receive paths for the ED packets (that is, if the ED transmissions
SMARTOBJECTS’18, June 25, 2018, Los Angeles, CA, USA
can be received by multiple GW ’s), which should be common in a
LoRa network.
4.3 Beacon (Class B) Synchronization Attack
Class B beacons are not in any way secured, meaning that an at-
tacker can set up a GW to send fake beacons. This could result in
class B end-devices have received windows out-of-sync with the
GW and also increased collisions on transmitted packets. Address-
ing this issue would require issuing a key that GW ’s could use to
authenticate beacon transmissions.
4.4 Network Traffic Analysis
An attacker can set up a GW to receive packets and infer some
information. Without access to key material, the attacker will not
be able to decode the contents of the packets received and the
usefulness of this traffic analysis will be highly dependent on the
application. For example, a LoRa network deployed in a building to
detect occupancy patterns might leak information about the level of
activity in the building through the analysis of transmission rates.
4.5 Man-in-the-Middle Attack against Servers
As also mentioned earlier in Section 3, Yang [28] clearly stated the
vulnerability of the LoRaWAN v1.0 to man-in-the-middle (MITM)
attacks between the NS and AS. If an attacker can tap in the commu-
nications between these two servers, as being non-encrypted, some
of the secret keys can be exposed. The same vulnerability is still
valid for LoRaWAN v1.1, in which security of the communications
in between hN S, f N S, sN S, JS and AS are not specified very well
and in detail. The specification of v1.1 suggests using encrypted
communication in between servers, however, implementation er-
rors are always possible. According to our talk with real-world
users of LoRaWAN, the network administrators are not worried
about the MITM attacks at all and do not follow recommendations
about the use of encryption between the servers.
4.6 Security Analysis with Security Verification
Tool
According to our security analysis of LoRaWAN v1.1 with Scyther
security verification tool [6], nothing is determined as a weak point
in the protocol. This is not surprising to us. The previously men-
tioned problems in this text are due to implementation errors and
traffic analysis, jamming, or replay attacks; hence these vulnerabil-
ities cannot be determined by Scyther. The reason is, the scope of
the Scyther tool is related to Cryptographic security of the commu-
nication messages and their associated keys. Therefore, it can be
stated that LoRaWAN v1.1 is Cryptographically secure but still has
weak points as mentioned in previous sections of this text, where
attackers can leverage.
5 CONCLUSIONS AND FUTURE WORK
LoRa and the companion LoRaWAN is a widely adopted LPWAN
specification, which continues to rapidly grow over a number of IoT
application verticals such as smart meters and oil and gas operations.
The latest version of the LoRaWAN specification (v1.1, released in
October 2017) was a significant advance of the protocol features
 SMARTOBJECTS’18, June 25, 2018, Los Angeles, CA, USA
Table 2: Summary of LoRaWAN v1.1 Threats
# Threat Category
1 RF jamming attack DoS
2 Replay attack MR/DoS
3 Beacon (Class B) syn- DoS
chronization attack
4 Network traffic analysis TA
5 Man-In-The-Middle MITM
(MITM) attack
and addressed many security problems previously reported. This
work introduced the main features of LoRaWAN and provided the
first analysis of potential threats to the protocol security, which are
of relevance for practitioners putting together LoRa networks as
well as for and the future evolution of the LoRaWAN specification.
The security of LoRa-based systems will evidently also depend
on implementation aspects. In this regard, the specification has
a few critical mechanisms that developers should pay particular
attention during development and testing: (i) secure storage of keys
as mandated by the specification might not be always convenient
and easy to implement in embedded platforms; (ii) there are several
security-critical frame counters (see Table 1) and implementation
mistakes have led to security problems in the past [5]; (iii) main-
taining session state across resets (Table 1 also details this) can
also easily lead to deficiencies that can be exploited; (iv) while the
specification implements a separation of trust between the network
and the application, it is important to understand that applications
still have to trust the network infrastructure (GW, NS) as appli-
cation payloads are encrypted but not integrity protected; (v) the
LoRaWAN specification has provisions for backwards compatibility
and this is known to be a weak point that attackers often exploit.
We present several security threats, some of which are specific to
v1.1 of LoRaWAN and were not previously reported. Our analysis
considers only threats within assumptions stated in the specifica-
tion. An analysis of security implications within an extensive scope
is, however, a relevant future work. For example, while the specifi-
cation clearly states the requirement for key material to be stored
securely, as discussed above, implementation deficiencies could
lead to the disclosure and reuse of key material. Another example
is the adequate handling of frame counters: while there is no threat
that can be directly pointed out from reading the specification,
it is known that this is a source for many implementation issues
and such flaws were found in a LoRaWAN NS server [5]. A risk
assessment analysis considering such threats and their potential se-
curity repercussions, along with techniques and/or methodologies
to tackle these problems is a follow-up to this work which would
help developers of LoRa-based applications better understand their
security implications.
REFERENCES
[1] Ferran Adelantado, Xavier Vilajosana, Pere Tuset-Peiro, Borja Martinez, Joan
Melia-Segui, and Thomas Watteyne. 2017. Understanding the limits of LoRaWAN.
IEEE Communications Magazine 55, 9 (2017), 34–40.
View publication stats
I. Butun et al.
Summary
It is hard to protect wireless transmissions from jamming. Results
in Denial-of-Service (DoS).
Combining Message Replay (MR) and RF jamming results in a hard-
to-detect DoS.
Causes nodes to miss downlink reception windows and possibly
collided transmissions.
Even without the possibility of decrypting data, Traffic Analysis
(TA) can lead to information leakage.
In the case of insecure communications, exposure of secret keys
happen when the communication between the servers are tapped.
[2] Lora Alliance. 2017. LoRaWAN 1.1 Specification, Oct. 2017. http://lora-alliance.
org/lorawan-for-developers. (22 Oct. 2017).
[3] S. Antipolis and P. Girard. 2015. Low Power Wide Area Networks security. white
paper by Gemalto Inc. (2015).
[4] Emekcan Aras, Gowri Sankar Ramachandran, Piers Lawrence, and Danny Hughes.
2017. Exploring The Security Vulnerabilities of LoRa. In Cybernetics (CYBCONF),
2017 3rd IEEE International Conference on. IEEE, 1–6.
[5] O. Brocaar. 2017. Notes on LoRaWAN security - Medium. https://medium.com/
@brocaar/notes-on-lorawan-security-7e741a8ee4fa. (28 Nov. 2017).
[6] Casimier Joseph Franciscus Cremers. 2006. Scyther: Semantics and verification of
security protocols. Ph.D. thesis, Eindhoven University of Technology, Netherlands.
[7] Jonathan De Carvalho Silva, Joel JPC Rodrigues, Antonio M Alberti, Petar Solic,
and Andre LL Aquino. 2017. LoRaWAN-A low power WAN protocol for Internet
of Things: A review and opportunities. In Computer and Energy Science (SpliTech),
2017 2nd International Multidisciplinary Conference on. IEEE, 1–6.
[8] Gumstix. 2018. The New Gumstix Conduit Dev Boards. https://gumstix.com/
lorawan-family/. (23 Jan. 2018).
[9] Ingenu. 2018. Ingenu Inc. http://ingenu.com/technology/rpma/. (25 Jan. 2018).
[10] Jaehyu Kim and JooSeok Song. 2017. A Dual Key-Based Activation Scheme for
Secure LoRaWAN. Wireless Communications and Mobile Computing 2017 (2017).
[11] Mustafa Kocakulak and Ismail Butun. 2017. An overview of Wireless Sensor
Networks towards internet of things. In Computing and Communication Workshop
and Conference (CCWC), 2017 IEEE 7th Annual. IEEE, 1–6.
[12] Jun Lin, Zhiqi Shen, and Chunyan Miao. 2017. Using Blockchain Technology
to Build Trust in Sharing LoRaWAN IoT. In Proceedings of the 2nd International
Conference on Crowd Science and Engineering. ACM, 38–43.
[13] Robert Miller. 2016. Lora security: Building a secure lora solution. MWR Labs
Whitepaper (2016).
[14] SeungJae Na, DongYeop Hwang, WoonSeob Shin, and Ki-Hyung Kim. 2017.
Scenario and countermeasure for replay attack using join request messages in
LoRaWAN. In Information Networking (ICOIN), 2017 International Conference on.
IEEE, 718–720.
[15] Sarra Naoui, Mohamed Elhoucine Elhdhili, and Leila Azouz Saidane. 2016. En-
hancing the security of the IoT LoraWAN architecture. In Performance Evaluation
and Modeling in Wired and Wireless Networks (PEMWN), Int. Conf. on. IEEE, 1–7.
[16] Nwave. 2018. Nwave Technologies Inc. http://nwave.io. (25 Jan. 2018).
[17] Qowisio. 2018. Qowisio Inc. http://qowisio.com. (25 Jan. 2018).
[18] M. Rohan. 2018. Low Power Wide Area Network Market Worth. https://www.
bizjournals.com/prnewswire/press_releases. (22 Jan. 2018).
[19] Semtech. 2018. Semtech Inc. http://semtech.com/. (23 Jan. 2018).
[20] Semtech. 2018. What is LoRa? http://www.semtech.com/wireless-rf/
internet-of-things/what-is-lora/. (22 Jan. 2018).
[21] Sigfox. 2018. Sigfox Inc. https://sigfox.com. (23 Jan. 2018).
[22] Telensa. 2018. Telensa Inc. https://telensa.com/unb-wireless/. (25 Jan. 2018).
[23] Things. 2018. The Things Network. http://thethingsnetwork.org/. (23 Jan. 2018).
[24] Stefano Tomasin, Simone Zulian, and Lorenzo Vangelista. 2017. Security Anal-
ysis of LoRaWAN Join Procedure for Internet of Things Networks. In Wireless
Communications and Networking Conference Workshops (WCNCW). IEEE, 1–6.
[25] Lorenzo Vangelista, Andrea Zanella, and Michele Zorzi. 2015. Long-range IoT
technologies: The dawn of LoRaT M . In Future Access Enablers of Ubiquitous and
Intelligent Infrastructures. Springer, 51–58.
[26] Waviot. 2018. Waviot Inc. http://waviot.com/. (25 Jan. 2018).
[27] Weightless. 2018. Weightless SIG. http://weightless.org/. (24 Jan. 2018).
[28] Xueying Yang. 2017. LoRaWAN: Vulnerability Analysis and Practical Exploitation.
(2017).
[29] Simone Zulian. 2016. Security threat analysis and countermeasures for lorawan
join procedure. M.Sc. thesis, Universit‘a degli Studi di Padova (2016).