DEGREE PROJECT, IN PROGRAMME, SECOND LEVEL

STOCKHOLM, SWEDEN 2017

Key management with a trusted

third party using LoRaWAN
protocol
A study case for E2E security
RALAMBOTIANA Miora

i
Acknowledgements

I would like to thank Fredrik Kilander and Markus Hidell for taking the time to
correct and guide me during the writing of this thesis.

I would also like to thank Jérôme d’Annoville, my supervisor at Gemalto for his
advice along with the whole R&D team for their kindness and their
professionalism.

I would like to thank my fellow students and my professors at KTH for sparkling
my enthusiasm and curiosity for technology.

Finally, a special thanks to my family and friends, who supported me in Sweden

and in France.

iii
Abstract (English)

Nowadays, Internet of Things (IoT) applications are gaining more importance

in people’s everyday life. Depending of their usage (for long or short distance
communications, using low or high power devices, etc.), several standards exist.

In this study, the focus is on Low Power Wide Area Networks (LPWAN) and
particularly a protocol which is raising in popularity for long-range low-power
communications in IoT: LoRaWAN.

LoRaWAN is still at an early stage and has been mainly used in use cases where
the network server was managing the keys ensuring confidentiality and
integrity of the data. Gemalto has raised the issue of interest conflicts in the
case where the network operator and the application provider are two distinct
entities: if the end-device and the application server are exchanging sensitive
data, the network server should not be able to read them.

In order to solve this problem, an architecture using a trusted third party to

generate and manage the keys has been implemented during this project. The
following research aims at finding security threats and weaknesses on the
confidentiality and integrity of the data and devices’ authentication in this study
case.

The LoRaWAN protocol and key management in general were studied first
before describing the studied system and finding the possible attacks exploring
its vulnerabilities on the mentioned points via an attack tree. These attacks were
simulated in order to define their consequences on the system and according to
them, security improvements on the architecture was proposed based on
previous work on the topic and exploration on potential countermeasures.

Keywords
IoT, LoRaWAN, key management, E2E security

v
Sammanfattning (Svenska)

Idag blir Internet av saker (IoT) applikationer allt viktigare i människors

vardag. Beroende på användningen (för lång- eller kortdistanskommunikation,
med låga eller höga effektenheter etc.) finns flera standarder.

I denna studie ligger fokus på Low Power Wide Area Networks (LPWAN) och i
synnerhet ett protokoll som ökar i popularitet för långsiktig
lågkapacitetskommunikation i IoT: LoRaWAN.

LoRaWAN är fortfarande på ett tidigt stadium och har i huvudsak använts i

användarfall där nätverksservern hanterade nycklarna som säkerställer
konfidentialitet och integritet av data. Gemalto har tagit upp frågan om
intressekonflikter i det fall nätverksoperatören och programleverantören är två
separata enheter: Om slutanordningen och applikationsservern utbyter känslig
data, ska nätverksservern inte kunna läsa dem.

För att lösa detta problem har en arkitektur som använder en betrodd tredje
part för att generera och hantera nycklarna implementerats under det här
projektet. Följande forskning syftar till att hitta säkerhetshot och svagheter om
konfidentialiteten och integriteten hos data och enheternas autentisering i
detta studiefall.

LoRaWAN-protokollet och nyckelhanteringen i allmänhet kommer att studeras

först innan författaren beskriver det studerade systemet och upptäcker de
eventuella attacker som undersöker sårbarheten på de nämnda punkterna via
ett angreppsträd. Dessa attacker kommer att simuleras för att definiera deras
konsekvenser på systemet och enligt dem kommer säkerhetsförbättringar på
arkitekturen att föreslås utifrån tidigare arbete med ämnet och undersökning
av potentiella motåtgärder.

Nyckelord
IoT, LoRaWAN, nyckelhantering, end-to-end-säkerhet

vii
Contents

Acknowledgements ..................................................................................................... iii

Abstract (English) .......................................................................................................... v
Sammanfattning (Svenska) ................................................................................... vii
List of Figures .................................................................................................................. xi
List of Tables ................................................................................................................. xiii
List of Acronyms and Abbreviations ................................................................. xv
1 Introduction ............................................................................................................. 1
1.1 Background .................................................................................................................. 1
1.1.1 Introducing Internet of things and LoRaWAN....................................................... 1
1.1.2 Introducing the context of the use case...................................................................... 2
1.2 Problem .......................................................................................................................... 3
1.3 Goals and Purpose .................................................................................................... 3
1.3.1 Benefits and Ethics............................................................................................................... 3
1.3.2 Sustainability .......................................................................................................................... 3
1.4 Methodology / Methods......................................................................................... 4
1.4.1 Analysis Phase ........................................................................................................................ 4
1.4.2 Evaluation Phase ................................................................................................................... 4
1.5 Delimitations ............................................................................................................... 4
1.6 Outline ............................................................................................................................. 4
2 Theoretical Background .................................................................................... 7
2.1 LoRaWAN ...................................................................................................................... 7
2.1.1 Join Procedure ....................................................................................................................... 8
2.1.2 Sending an uplink message ............................................................................................11
2.2 Key management .....................................................................................................13
2.2.1 Key management in a wireless mobile environment .........................................14
2.2.2 Key management with LoRaWAN ..............................................................................15
3 Use case .................................................................................................................... 17
3.1 Methodology ..............................................................................................................17
3.1.1 Attack Tree: a description ...............................................................................................18
3.1.2 Analysis method ..................................................................................................................19
3.2 Architecture ...............................................................................................................19
3.2.1 End-device ..............................................................................................................................20
3.2.2 Gateway ...................................................................................................................................20
3.2.3 Network server .....................................................................................................................20
3.2.4 IoT Middleware....................................................................................................................20
3.2.5 Application server ...............................................................................................................21
3.2.6 Trusted Key Manager ........................................................................................................22
3.3 Procedures ..................................................................................................................23
3.3.1 Join the network..................................................................................................................24
3.3.2 Send an uplink message...................................................................................................25
3.3.3 Claim a device .......................................................................................................................28
4 Building of the Attack Tree ........................................................................... 31
ix
 4.1 The attack goals ........................................................................................................31
4.2 Known Threats .........................................................................................................32
4.3 Hypotheses..................................................................................................................33
4.4 The attack tree ..........................................................................................................34
5 Evaluation of the use case’s key management ................................... 37
5.1 Compromising Confidentiality .......................................................................37
5.1.1 Eavesdropping after a claim by a malicious application server ...................37
5.1.2 Eavesdropping by compromising LoRaWAN cipher block mode ...............38
5.1.3 Compromising AppSKey .................................................................................................39
5.2 Compromising Integrity .....................................................................................39
5.2.1 Man in the Middle attack by compromising NwkSKey ....................................39
5.2.2 Bit-flipping attack between device and network server ...................................41
5.2.3 Bit-flipping attack between network server and application server...........42
5.3 Compromising Device’s authentication.....................................................42
5.3.1 Malicious join........................................................................................................................42
5.3.2 Sending malicious data messages ...............................................................................45
6 Discussion and Security suggestions ...................................................... 47
6.1 Preventing the compromising of AppKey .................................................47
6.1.1 Hardware protection: Embedded Secure Elements...........................................47
6.1.2 Software: Management of AppKey .............................................................................47
6.2 Managing Join requests ......................................................................................48
6.3 Preventing brute force attacks on MIC ......................................................50
6.3.1 In Join Request messages ...............................................................................................50
6.3.2 In Data messages.................................................................................................................51
6.4 Securing LoRaWAN cipher mode encryption ........................................51
6.5 Securing host mobility .........................................................................................53
6.5.1 Claim procedure ..................................................................................................................53
7 Summary and Conclusion.............................................................................. 55
7.1 Future work ................................................................................................................56
References ....................................................................................................................... 59
Appendix A: Frame Payload Shuffling method algorithms ................ 61

x
List of Figures

Figure 1. An overview of the architecture and the solutions provided by

Gemalto. .............................................................................................................. 2
Figure 2. An overview of a LoRaWAN architecture with an application server. 7
Figure 3. An overview of LoRaWAN Join Procedure. ...................................... 10
Figure 4. An overview of LoRaWAN Join Procedure with independent network
operator and application provider. ................................................................... 11
Figure 5. Structure of a LoRaWAN uplink message. ........................................12
Figure 6. The set up of a bit flipping attack. ...................................................... 15
Figure 7. An example of Attack......................................................................... 18
Figure 8. An overview of the study’s LoRa architecture. ................................. 20
Figure 9. An Overview of AWS IoT.................................................................... 21
Figure 10. An example for the application UI. ................................................. 22
Figure 11. Gemalto TKM online form. .............................................................. 22
Figure 12. TKM webpage to register a device. .................................................. 23
Figure 13. An overview of the TLS Handshake protocol. ................................. 24
Figure 14. Join Procedure in the use case. ....................................................... 25
Figure 15. IoT middleware processing an uplink message. ............................. 27
Figure 16. An overview of the Claiming procedure. ......................................... 29
Figure 17. The attack tree for the thesis' use case. ........................................... 34
Figure 18. Subtree 1 - Compromising of Confidentiality. ................................ 34
Figure 19. Subtree 2 - Compromising of Integrity. .......................................... 35
Figure 20. Subtree 3 - Compromising of Devices' authentication. .................. 35
Figure 21. MitM attack between device and gateway with a compromised
NwkSKey. .......................................................................................................... 40
Figure 22. Internet-facing gateway and network server. ..................................41
Figure 23. The time T a malicious node has to wait in order to perform a replay
attack as a function of f the number of valid join procedures for one device per
day and N the number of previously used values of DevNonce stored by the
network server. ................................................................................................. 44
Figure 24. An example of XOR masking. ......................................................... 50
Figure 25. Process of Frame Payload Shuffling. .............................................. 52

xi
List of Tables

Table 1. A sample of capacity scenario [7]. ......................................................... 8

Table 2. Encryption block of an uplink data message with the LoRaWAN
protocol [8]. .......................................................................................................12
Table 3. IoT middleware processing an uplink message. ................................ 26
Table 4. Assets in this thesis' use case. .............................................................. 31
Table 5. Known threats in IoT applicable to the use case [24]. ....................... 32
Table 6. Known threats in LoRaWAN applicable to the use case [4]. ............. 33
Table 7. MitM attack between device and gateway with a compromised
NwkSKey. .......................................................................................................... 40
Table 8. Number of brute-force attack attempts to succeed with N the length of
the target. .......................................................................................................... 42
Table 9. Processing time to search a correct MIC [27]. ................................... 42
Table 10. An example of bit-flipping attack on the frame payload [27]. ......... 42

xiii
List of Acronyms and Abbreviations
Most of these acronyms and abbreviations are explained in this document when
first used. However, for clarity, these terms are listed below.

ACK Acknowledgment/Acknowledged

AES Advanced Encryption Standard

APB Activation by Personalization

ASCII American Standard Code for Information Interchange

AWS Amazon Web Services

CA Certificate Authority

CLI Command-Line Interface

eSE embedded Secure Element

FHDR Frame header

HTTP(S) Hypertext Transfer Protocol (Secure)

ICT Information and Communication Technology

IEEE Institute of Electrical and Electronics Engineers

IoT Internet of Things

KVC Key-Value Coding

LPWAN Low-Power Wide Area Network

MAC Media Access Control

MCU Microcontroller unit

MIC Message Integrity Code

MitM Man in the Middle

MQTT Message Queue Telemetry Transport

NoSQL Not only Structured Query Language

OTAA Over-the-Air Activation

xv
PoC Proof of Concept

RX Receiver Signal

SDK Software Development Kit

SF Spreading Factor

SSL Secure Socket Layer

TKM Trusted Key Manager

TLS Transport Layer Security

TX Transceiver Signal

xvi
1 Introduction
Nowadays, Internet of Things (IoT) has become a hot topic in the Information
and Communication Technology (ICT) industry. On the one hand, this
technology opens a whole new world of possibilities to interact with interfaces
and to collect data. On the other hand, this area clearly suffers from a lack of
standards, whether it is for the question of security or for application
integration, these two issues being linked.

This chapter provides an overview of aspects covered within the project.

1.1 Background
First, it is important to define the scope of this thesis by giving some
background on IoT and LoRaWAN, the main technologies used for this work,
and on the context of this thesis.

1.1.1 Introducing Internet of things and LoRaWAN

As technology is increasingly merging in one’s everyday environment, the
Internet of Things (IoT) becomes an accordingly more debated topic as it is the
fundamental concept for a connected world. Indeed, IoT is a concept in which
physical objects and the virtual networked world can connect and exchange
information and commands [1].

This study is focusing on Low Power Wide Networks (LPWAN). LPWAN

consists in a wireless telecommunication network allowing long range
communications at a low bit rate among connected objects [2]. The main
advantages of LPWAN are that they allow low-power, long-range and low-cost
communication characteristics [3]. It is interesting to note that there is no clear
leading standard for LPWAN as for now. In the scope of this thesis, the LoRa
technology and the LoRaWAN protocol is used. LoRa is a modulation format
patented by Semtech and licenced to other device manufacturers [4].
LoRaWAN is an open LPWAN standard and is currently being developed by
LoRa Alliance. It includes several layers of encryption for communication
between the end-device, the network server and the application server [5].

The LoRa technology also includes some quite strong limitations regarding
packet size and data rate which depend on the distance to the nearest gateway,
the type of data to be sent and the region’s specification - e.g. for the European
863-870MHz band, the application packet size varies between 51 bytes for the
slowest data rate, and 222 bytes for faster rates [8]; furthermore, the LoRaWAN
protocol adds at least 13 bytes to the application payload.

Another limitation is due to the duty-cycle i.e. the maximum percentage of time
during which an end-device can occupy a channel [9] to avoid network
congestion. It depends on many factors including the region and the type of
operation (like sending data, or broadcasting a request to join a network). For

1
European 863-870MHz band, the duty-cycle is limited to 1%, meaning that on
a sub-band, the signal is on 1% of the time but off 99% of the time.

1.1.2 Introducing the context of the use case

This thesis project is carried out in collaboration with the Gemalto company.
The system deployed and studied in this project is called the Gemalto Trusted
Key Manager (TKM) and provides chip and module markers, device makers,
network operators and service providers with advanced solutions ensuring the
end-to-end security of IoT devices connecting over LoRa networks [6]. Indeed,
traditionally, confidentiality and integrity are assured by the network operator.
However, Gemalto’s solution introduces the TKM as a trusted third party
handling these properties.

In the presented use case, a Software Development Kit (SDK) for the end-
device, a TKM server which generates and stores the keys and a command line
interface (CLI) which allows the user to deploy the company’s solution in the
cloud are provided. The company does not own the application server, the IoT
middleware nor the network server which are also part of the global
architecture. They are considered to have different owners. Figure 1 represents
an overview of the final architecture and which components are provided by
Gemalto.

Figure 1. An overview of the architecture and the solutions provided by Gemalto.

It has consequences on the confidentiality of the data e.g. the data from the
device to the application server and back should not be read in clear on the
network server.

2
1.2 Problem
As said above, Gemalto introduces the use of a trusted third party to
communicate with the other business actors in IoT. However, nowadays, there
is no standardized security evaluation in IoT. A method must then be defined
to evaluate the security of Gemalto’s installation.

Thus, the problem addressed by the thesis project can be decomposed into two
main research questions:
• What are the known threats and flaws key management via a trusted
third party can encounter with LoRaWAN protocol?
• How does Gemalto’s installation in particular deal properly with these
threats?
• What security improvements could be made?

1.3 Goals and Purpose

With this project, the author aims at evaluating Gemalto’s system’s key
management by inventorying known threats and weaknesses for similar
architectures and checking if they apply.

This study’s goals can then be summed up in two objectives:

• Defining a clear method in order to find the most exhaustive list possible
of known threats for Gemalto’s system.
• Specifying adequate countermeasures for Gemalto’s system to mitigate
these threats.

1.3.1 Benefits and Ethics

On the whole, this project might contribute to more secure IoT products
proposed by companies to users. However, there are two main risks in this
work. First, by focusing on specific security points – here, exclusively regarding
key management – on IoT, the author might unwillingly diminish the
importance of the unmentioned security threats, and therefore make future
readers more vulnerable to the latter. Furthermore, this work might hand more
information to hackers about possible security checks, allowing them to try to
find other turnarounds to alter or listen to IoT communications without being
detected.

1.3.2 Sustainability
The main sustainable issue here regards the energy consumption of the
installation. It is a very real challenge for networks of connected devices.
According to Johanna Nordlöf and Petter Lagusson’s master thesis [7], the
energy consumption for a LoRa node varies as a function of the Spreading
Factor (SF) of the issued signal which defines the different TX and RX windows.
LoRaWAN supports six SF (from SF=7 to SF=12) and the higher the SF, the
slower the transmission and the lower the data rate. As an example, a node
using a SF of 7 with a 2600 mAh battery, a heartbeat every sixth second would
in theory drain the battery in 48 days if sleep-, leak- or computing currents are
not taken in account.
3
This study does not take this aspect in account as it focuses more on the Proof-
of-Concept (PoC) than on the production in great scale but it must be
considered before further deployment.

1.4 Methodology / Methods

For this project, two research methods are used for two different phases: the
Analysis and the Evaluation Phase.

1.4.1 Analysis Phase

The analysis includes several steps, all aiming at building a relevant and reliable
security evaluation for the key management of the studied LoRa architecture.
Indeed, from literature, there is no widely accepted, industry-standard method
of evaluation to assess the threats of a system. Consequently, an adequate threat
analysis method was chosen and applied. In order to do this, the studied
installation was described before executing a threat analysis with a method
which was shown as adequate. It is important to notice that according to
Gemalto itself, the solution and its analysis in this thesis are focused on its
ability to ensure authentication of the devices and the integrity and
confidentiality of data transferred over LoRa networks [6]. After extensively
describing the studied system, the scope of threats was narrowed to those
applicable in this use cases.

1.4.2 Evaluation Phase

During this phase, the author synthesizes the system’s weaknesses and, for each
of them, checks if the key management of this system offers an efficient
protection. If this is the case, the author was able to conclude that the system
reaches a sufficient security level regarding key management and what its weak
points are. Either way, a discussion on these results and suggestions of
improvements of the system were then made.

1.5 Delimitations
This thesis is made in collaboration with Gemalto, therefore limitations are
made based on topics and use cases considered as relevant for the customers of
Gemalto. In other words, the main focus is, as said in 1.4.1, on threats on
authentication, integrity and confidentiality of communicated data and the
security levels to achieve are only in the scope of known threats. The purpose is
not to highlight new threats in this area but to consolidate the identified flaws
of a system.

1.6 Outline
The first chapter consists on an introduction of the present thesis.

The LoRaWAN protocol and key management’s issues in IoT are presented in
chapter 2.

4
The studied system, its architecture and its procedures are described in chapter
3.

A threat analysis method is then discussed, chosen and used to list and describe
known threats the studied architecture and protocols may encounter in chapter
4. This list is then narrowed down by arguing which ones are relevant in the
author’s use case to constitute a battery of tests.

Once a set of threats is defined, the architecture is confronted to these threats

in order to see if its design can prevent them or not in chapter 5.

Finally, in chapters 6 and 7, this analysis is interpreted to suggest security

improvements for the system and conclude on the relevance of a trusted third
party for key management with the LoRaWAN protocol.

5
2 Theoretical Background
This chapter first gives an introduction to the LoRaWAN protocol. It then looks
more into the issues of key management.

2.1 LoRaWAN
As previously said, the LoRaWAN network protocol is a protocol used over
LoRa technology, optimized for battery-powered mobile or mounted end-
devices [8].

A LoRaWAN network is usually laid out in a star-of-stars topology: end-devices

can communicate bi-directionally to a central network server via one or several
gateways which only relay messages. An overview of this topology is
represented in Figure 2. For basic LoRaWAN (Class A devices), end-devices
only accept downlink communication from the server shortly after they have
sent an uplink message. The network server can be connected to a websocket or
an application server via MQTT or HTTP. In the author’s use case, the network
server is considered as linked to an application server via MQTT. Each device is
personalized by three attributes:
• DevEUI: a globally unique end-device identifier in the network. It is
comparable with a MAC address for a TCP/IP device.
• AppEUI: the application identifier.
• AppKey: an AES-128 application key.

Figure 2. An overview of a LoRaWAN architecture with an application server.

It must be said that, due to duty-cycle mentioned in subsection 1.1.1, a gateway

which handles downlink communication with a lot of end-devices is able to
send less downlink messages than a gateway connected to fewer end-devices.

7
The capacity of a LoRa gateway is defined by the maximum number of LoRa
devices it can handle. The capacity of a LoRa gateway can be increased by using
multiple channels or different bit rates on a same channel to receive multiple
packets simultaneously. In their study, Johanna Nordlöf and Petter Lagusson
[7] report the results of packet delaying as a function of capacity in a real life
scenario, presented here in Table 1.

Table 1. A sample of capacity scenario [7].

Time between Payload size [B] Number of end-
packets devices
30 s 1 739
60 s 1 1506
10 min 20 9670
30 min 24 26150
24 h 8 1788309

This table shows that the more end-devices a LoRa gateway handles, the slower
the communication is since the time between packets increases.

2.1.1 Join Procedure

With LoRaWAN, there are two possible activations: either by Activation-By-
Personalization (ABP) or by Over-The-Air-Activation (OTAA). In this study,
only the latter is considered, according to Gemalto’s customers’ requests.

For a device to join a LoRaWAN network via OTAA, the procedure consists in
two MAC messages exchanged with the server [8]. A MAC message is simply a
message whose format is conformed to a Media Access Control (MAC) protocol,
i.e. with an addressing mechanism and a channel access which allows available
nodes on a network to communicate, such as LoRaWAN.

The end-device initiates a join procedure by sending a join-request message

containing the AppEUI (8 octets), DevEUI (8 octets) of the device followed by
a 2-octet-long random value named DevNonce and a Message Integrity Code
(MIC) calculated with the AppKey as follows:

cmac = aes128_cmac(AppKey, MHDR|AppEUI|DevEUI|DevNonce)

MIC = cmac[0..3]
where MHDR is the MAC header [5].

The network server keeps track of DevNonce to avoid replay attacks. Indeed, if
a malicious device sends a previously recorded join-request message in order
to join the network instead of the device it is emulating, the network server is
able to check if the DevNonce has already been used or not and reject the
request if it has.

If the end-device is registered as permitted to join the network, the network

server has its AppKey in its database and uses it in order to calculate the MIC
of the join-request message to check its integrity.

8
 • If the integrity is verified, the network server sends a join-accept
message to the end-device.
• If the device is not registered as permitted to join the network or if the
integrity of the message is not verified, no response is given.

The join-accept message contains a 3-octet-long random value called

AppNonce, a network identifier named NetID (3 octets), an end-device address
DevAddr (4 octets) and a MIC calculated by all these components as follows:

cmac = aes128_cmac(AppKey, MHDR|AppNonce|NetID|DevAddr|DLSettings|RxDelay|CFList)

MIC = cmac[0..3]
where DLSettings constitutes the downlink configuration, RxDelay represents
the setting delay between the first uplink message and the opening of the first
reception slot and CFList is an optional list of channel frequencies for the
network the end device is joining [5].

DevAddr is then to be used by the network server to identify the device. An

uplink data message from an unknown DevAddr is systematically discarded.

The join-accept message is not only signed but also encrypted with the AppKey
as follows:

aes128_decrypt(AppKey, AppNonce|NetID|DevAddr|DLSettings|RxDelay|CFList|MIC) [5]

AppNonce, NetID and DevNonce are also used to derive an application session
key (AppSKey) and a network session key (NwkSKey) from the AppKey by the
network server and the end-device independently. They are calculated as
follows:

NwkSKey = aes128_encrypt(AppKey, 0x01|AppNonce|NetID|DevNonce|pad16)

AppSKey = aes128_encrypt(AppKey, 0x02|AppNonce|NetID|DevNonce|pad16)
where the pad16 function appends zero octets in order for the length of the data
to be a multiple of 16 [5].

NwkSKey is used to ensure integrity while AppSKey is used to ensure

confidentiality. Figure 3 represents the conduct of a Join Procedure.

9
 Figure 3. An overview of LoRaWAN Join Procedure.

Having two session keys allows us to prevent eavesdropping from the network
server if the network server and the application server have different owners.
In this case, AppKey is only known by the application server and the end-device.
When receiving a Join Request, the network server sends it to the application
server which checks that the device is allowed to join and generates the session
keys before sending NwkSKey to the network server. The application server is

10
then responsible for encryption and decryption of the messages as illustrated in
Figure 4.

Figure 4. An overview of LoRaWAN Join Procedure with independent network

operator and application provider.

2.1.2 Sending an uplink message

After an end-device has joined the network, it is able to receive downlink
message from the network server and send it uplink messages. Only uplink
messages are studied here.

11
As shown on Figure 5, an uplink message contains DevAddr, assigned and
registered by the network server during the join procedure, a frame counter for
uplink messages (FCntUp), the frame payload and the MIC calculated by
NwkSKey. The entire MAC payload is encrypted by AppSKey using Advanced
Encryption Standard (AES) encryption.

Figure 5. Structure of a LoRaWAN uplink message.

The MIC for the MAC payload is calculated as follows:

msg = MAC_header | FHDR | port_field | frame_payload
B0 = (0x49|4*0x00|Dir|DevAddr|FCntUp|0x00|len(msg))
mac = aes128_cmac(NwkSKey, B0|msg)
MIC = mac[0..3]
where FHDR is the frame header containing DevAddr, the frame control octet,
FCntUp and the frame options.

Uplink messages can be configured as confirmed message. In this case, they

require an acknowledgement (ACK) from the network server when the latter
receives it. In that case, the end-device checks that it has received the ACK to
its latest message before sending a new one.

Data message encryption and decryption

The first thing to do in order to send an uplink message is to encrypt the MAC
payload. The encryption operation is based on the generic algorithm described
in the IEEE Standard for Local and Metropolitan Area Networks [10] using AES
with a 128-bits key. If the frame payload only contains MAC commands,
NwkSKey is used. Otherwise, AppSKey is used.

For each data message:

• A sequence of blocks Ai for i=1..k, where
k=ceil(len(frame_payload)/16) is defined.

Table 2. Encryption block of an uplink data message with the LoRaWAN protocol
[8].
Size
1 4 1 4 4 1 1
(bytes)

Ai 0x01 4 x 0x00 0 DevAddr FCntUp 0x00 i

12
 • The blocks Ai are encrypted to get a sequence of blocks Si such as
Si=aes128_encrypt(K, Ai) for i=1..k where K=NwkSKey or K=AppSKey.
• S = S1 | S2 | .. | Sk is defined.
• (frame_payload|pad16)⊕S is truncated to the first
len(frame_payload) octets.

The uplink frame counter (FCntUp) starts from 0 after a successful Join
Procedure and is incremented by the end-device at each uplink message to keep
track of the uplink messages sent, lost or received. The same FCntUp value
should not be reused by an end-device during one session, except for
retransmission. Any message, retransmissions excepted, sent with the same
FCntUp from one device during one session is discarded by the network server.

2.2 Key management

As explained in the previous subsection, the LoRaWAN protocol is using
different keys (AppKey, AppSKey and NwkSKey) during its procedure to join a
network or send a message. More precisely, the common shared key between
the device and the network server is AppKey since the other two are derived
from it. The issue of key management in group communications is then relevant
in an architecture using the LoRaWAN protocol or a protocol inspired by this
one.

First, a higher view of group key management is needed. There are three main
approaches regarding key management in a group [12]:
• Centralized group key management:
One entity is responsible for the generation, distribution and update of the
group keys.
• Distributed (contributory) group key management:
Group members themselves do the key generation. It can be contributory:
all members contribute some information to generate the group keys.
• Decentralized group key management:
The management of a large group is divided among smaller subgroup
managers.

With the LoRaWAN protocol, since the session keys (NwkSKey and AppSKey)
are generated by the network server using the DevNonce (provided by the end-
device) and AppNonce (provided by the server), this covers the definition of a
contributory group key management.

Besides, there are five important requirements to ensure security for group key
agreement [13, 14]:

• Group Key Secrecy:

An adversary passively listening to all communications should not be able
to deduce group keys.
• Forward Secrecy:

13
 An adversary who have access to previous group keys or a former user
should not be able to deduce current group keys.
• Backward Secrecy:
An adversary who has access to current group keys or a current user should
not be able to deduce previous group keys.
• Key Independence:
An adversary who knows a subset of group keys should not be able to deduce
any other group keys. In other words, the disclosure of one key should not
compromise other keys employed in the group.
• Resistance to collusion :
Any set of fraudulent users should not be able to collude and deduce other
group keys.

2.2.1 Key management in a wireless mobile environment

Now that the security for key management in general has been looked into, it is
important to notice that there are additional specific security requirements in
IoT. In order to define them, the author has to consider the design challenges
linked to group key management in wireless mobile environments [14]. In the
scope of this thesis however, some restrictions are made in the analysis and
thus, the focus is put on the protocol, physical constraints or threats are not
considered:

• Mobility protocol
If there are different key managers attached to areas, they are required to be
informed if a member is going to leave or join. Each area must then ensure
backward and forward secrecy, independently to each other. In this thesis’s
case, this aspect is not taken into account however, as only one global key
manager for every area is considered.

• Host mobility
Mobility implies that when a node leaves a network and enters a new one, a
generation of new keying materials must be provided for the new host. With the
LoRa technology, the network and/or application servers are the hosts and the
end-devices are the nodes. In previous works [14], this host mobility was mainly
seen as a consequence of geographic mobility but in the thesis’s case, networks
are considered as the properties of various actors in the business model of
mobile business [15]. Indeed, the network server is furnished by a network
operator while the middleware and application server are provided by a
possibly independent application provider. Network operators and application
providers usually work as business partners but these partnerships can vary,
making connected devices migrating to another network server or another
application server.

• Additional key management

In order to ensure backward and forward secrecy, it must be ensured that
mobile members do not keep valid keys when leaving a group communication,
i.e. when changing of network server or application server, to avoid
compromise.
14
 • Tracking key material during movement event
In order to prevent malicious mobile members to move from server to server,
accumulating security information, mobile members’ moves must be
supervised by an entity which, at the least, controls if their moves are justified
and keeps track of the key material they possess.

In summary, the main design challenge is focused on how to control the

mobility of the end-devices and how to keep track of their keys and movements.

2.2.2 Key management with LoRaWAN

The author should now examine if and how the LoRaWAN protocol deals with
this issue.

Regarding requirements for key management in general, the LoRaWAN

protocol ensures key independence and resistance to collusion by generating
new session keys for an end-device at each join procedure. Group key secrecy is
also guaranteed as keys are never passed through the network: they are only
generated locally by the end-device and the network server.

However, regarding backward and forward secrecy, matters are a bit

complicated by the specificities of a wireless mobile environment. For example,
if an end-device share its AppKey with a malicious application server and then
moves to another application server without changing it, the malicious server
still detains a key (AppKey) which is still used by the device and which has been
used by the device with other application servers in the past, compromising
backward and forward secrecy. Additional key management and tracking of the
keys are not handled at all and must be thought of in an end-to-end LoRaWAN
architecture.

Host mobility also raises another problem regarding the bit flipping attack
described in Xeuying Yang’s work [11]: multiplying application and network
servers increases the attack surface since a bit-flipping attack must take place
between the network server and the application server as it can be seen on
Figure 6. Thus, host mobility makes bit-flipping attacks more difficult to detect.

Figure 6. The set up of a bit flipping attack.

In her work, Xeuying Yang [11] also found another weakness in the LoRaWAN
protocol: it is possible to compromise confidentiality by eavesdropping. Indeed,
with a same AppSKey for a sufficient long time, an attacker listening to wireless
15
packets might be able to decrypt them if they wait long enough for the frame
counter to be reset to 0 (it happens when it reaches its maximum or if the device
is manually reset). The attack works as it follows: when FCntUp is reset, if the
AppSKey is the same, the keystream, i.e. the block cipher encryption described
in 2.1.2, is the same for two messages with the same FCntUp. And in this case:

Plaintext1⊕Keystream = Ciphertext1
Plaintext2⊕Keystream = Ciphertext2

So:

Plaintext1⊕Plaintext2 = Ciphertext1⊕Ciphertext2

If an attacker can guess a part of Plaintext1, they are therefore able to derive a
part of Plaintext2. A robust key management should take this weakness into
account, finding a system in order never to have the same keystream for two
distinct messages.

16
3 Use case
This chapter explains the method the author intends to use to conduct the
evaluation of the security of its key management and describes the study’s
architecture in more details.

This use case consists in an end-device communicating securely with an

application server. Gemalto’s solution is in charge to generate and distribute
the keys while the network and application servers are owned by customers,
respectively a network operator and an application provider. The application
provider is also using an IoT middleware in order to facilitate the integration
within the network.

3.1 Methodology
A source of inspiration in order to evaluate the security level of a system might
be found in threat analysis methods. During the literature review, the author
considered some of them such as attack trees [16], Meadows’ formal models
[17] or ProVerif [18], used in scientific papers – searched on KTH library
database - to rate the security of the key management of a system – which was
the issue for this thesis.

In order to choose amongst them which one was the most appropriate,
Gemalto’s requirements, communicated via the author’s company supervisor,
allowed to set two criteria for the methodology:
• Realization and Qualitative analysis
The system was studied as a Proof of Concept: the main point was to
show the feasibility of the architecture. Therefore, the most significant
challenges were the realization of the architecture and to expose its
theoretical and observable flaws.
• Focus on confidentiality, integrity and device’s authentication
Gemalto particularly aimed at ensuring these three conditions, as stated
in the introduction. The chosen threat analysis method then had to focus
on them and to categorize found threats to determine which condition
they endangered.

It was important to have Gemalto’s validation for the methodology since the
master project was done in the scope of an internship in their company.

Building an attack tree after implementing the architecture was finally chosen
as the basis of the evaluation since, according to the given criteria, it was the
most relevant method. Indeed, it is based on the observation of a system and
the listing of all the known threats applicable to it and allows to categorize them
by the security property they threaten (here: confidentiality, integrity or
device’s authentication) in a convenient and visual way.

17
3.1.1 Attack Tree: a description
The name of “Attack Tree” is self-explicit: it represents attacks against a system
in a tree structure with the goal as the root node and different ways of achieving
that goal as leaf nodes. This method is entirely qualitative.

In order to create an attack tree, the attack goals, i.e. the sensitive points an
adversary might want to attack, must be identified. The various ways to attack
them must then be listed to build the tree.

The main risk with this method is to forget possible threats. However, the goal
here is not to discover every weakness of the system but to determine if the level
of security achieved is sufficient. In this thesis, a key management with
sufficient of suitable security is defined as a key management which is
invulnerable to every known threats on the confidentiality, integrity and
device’s authentication in an IoT system.

Figure 7. An example of Attack.

For instance, Figure 7 is an attack tree representing possible actions to

compromise a house. The house would be compromised if an attacker can break
into it. Hence, it is the main goal and constitute the first node. Its children nodes
are ways to achieve that goal and become themselves sub-goals which have their
own children nodes and so on.

There are two possible different strategies to break into the house: stealing the
key or forcing the door. These are the possible attacks.

It must be noted that there are AND and OR nodes, every unspecified node
being an OR node. OR nodes are alternatives while AND nodes represent
different necessary steps to achieve one goal. For example, here to force the
door, an intruder must learn how to pick locks AND have adequate tools to do
it.

Of course, this sample tree is incomplete. Other attacks can be thought of too.

18
3.1.2 Analysis method
An attack tree is built according to the known threats in the IoT domain in
general and for the LoRaWAN protocol in particular. In order to do this, the
architecture and procedures of this use case are first described and analyzed in
order to construct the attack tree. Scenario of these attacks are then presented
alongside with the potential countermeasures the system proposes and their
consequences on its global security.

3.2 Architecture
In order to generate and distribute the keys, a Trusted Key Manager (TKM) is
used. It is a third party component which must ensure end-to-end security
encryption by acting as a bridge between the different parts of the system. It is
integrated in the LoRa architecture as represented in Figure 8. According to
Gemalto [6], the TKM aims at simplifying security managements and providing
advantages to IoT business actors:

• For the device makers

o Furnishing reliable security provisioning
o Simplifying the integration within the network
o Simplifying the management of the device lifecycle

• For the network operators

o Simplifying the integration and migration of the device with the
networks

• For the application providers

o Ensuring confidentiality and integrity of the exchanged data

Its specific role and features in this thesis’ use case are described further down.

19
 Figure 8. An overview of the study’s LoRa architecture.

This setup has been done as a Proof of Concept (PoC) by the author in the scope
of the master project. This PoC consisted in a physical public connected locked
box. The main scenario is as it follows: the postman first puts an item for a user
to retrieve in a box and locked the latter. As he does so, a new password is
generated by the server to unlock the box and the user can check it on a web
application if the item has been put in the box and what the password is. The
password is renewed with every new item.

The focus in the following parts is on the different technologies this architecture
is composed of.

3.2.1 End-device
The end-device consists in a Nucleo-64 development board with STM32
microcontroller (MCU), compatible with the ARM mbedTM librairies. It
includes GPIO ports for sensors in order to collect data. Binaries are generated
from a program using a software development kit (SDK) specific to Gemalto,
implementing the LoRaWAN protocol among other things. The board is
completed by a LoRa shield. This device is integrated in the box and linked to
the keypad and the lock.

3.2.2 Gateway
The gateway is configured as a packet forwarder, carrying LoRa packets it
receives from the device to the network server over Ethernet or WiFi, using
HTTP or HTTPS protocol.

3.2.3 Network server

For this PoC, the network server is based on an open-source compact server for
private LoRa networks [19]. From this code source, it was slightly modified to
communicate with the TKM.

Devices are characterized by a DevEUI, the region – which has consequences

on LoRa radio frequencies -, the type of application (here, it is an external
server) and the AppEUI. A name of devices’ group can also be specified and is
necessary in order to connect with the IoT middleware.

Indeed, the name of the group is linked to a handler which determines the
format of the uplink messages (e.g. in the presented use case, JSON is utilized)
and a connector which defines the publication topic and allows to store the
credentials necessary to create a MQTT connection over SSL with the IoT
middleware.

3.2.4 IoT Middleware

Between the application server and the network server, an IoT platform is used.
It acts as a middleware, able to store and process the data sent by the end-device
through the network server and trigger the adequate events.

20
For this use case, AWS IoT [20], a platform to integrate Amazon Web Services
for IoT applications, is used. An overview of this platform is represented on
Figure 9.

Figure 9. An Overview of AWS IoT.

In AWS IoT, each connected device is represented by an AWS object called a

Thing [21]. A Thing is identified by its name and can have name-value
attributes. It is associated to a Thing Shadow [22], a JSON document used to
store and retrieve current state information for a Thing.

Regarding Amazon Web Services, AWS Lambda, Amazon S3 and Amazon

DynamoDB are used.
• AWS Lambda consists in functions called Lambda functions which are
triggered by a particular event (here a message in AWS IoT).
• Amazon S3 (Simple Storage Service) provides cloud object storage,
meaning it manages any form data as objects, each one of them including
the data itself and a unique identifier.
• Amazon DynamoDB is a NoSQL database, meaning it is a non-relational
database using a variety of data models such as document, key-value,
graph and so on.

Besides, AWS Identity and Access Management (IAM) is also being used to
allow secure and controlled access to AWS services.

3.2.5 Application server

It consists in a web application using the Google Maps API where the user can
see the location and status (empty or locked) of the connected boxes. It needs
credentials to connect to the IoT middleware via TLS over HTTP. Its main
purpose is to provide a user interface with a comprehensive representation of
the connected boxes and their past and current passwords. A screenshot of the
application UI is displayed on Figure 10.

21
 Figure 10. An example for the application UI.

3.2.6 Trusted Key Manager

The Gemalto Trusted Key Manager (TKM) is an architecture implemented by
Gemalto in order to authenticate IoT devices and secure data exchanges on the
network [6]. In other words, it is responsible for keeping track of the registered
devices on the network, their status i.e. if they have joined the network or not,
and the associated active keys (AppKey and NwkSKey and AppSKey if the
device has joined). It also handles the generation and distribution of the keys.

In order to use it, the different business actors (here namely the network
operator and the application provider) must enroll via an online form such as
the one on Figure 11.

Figure 11. Gemalto TKM online form.

22
The devices are registered on the TKM by the application provider via a website
as it can be seen on Figure 12. The DevEUI, the AppKey of the device and the
name of the device’s group on its network server – the latter also indirectly
specifies the name of the network server it is attached to, given that the network
operator has already enrolled on the TKM - are required. The AppKey must be
encrypted with a transport key TK provided offline beforehand and given
alongside with a check value (AppKCV). AppKVC is calculated by truncating the
three first bytes of the encryption with the AppKey of 0x555555.

Figure 12. TKM webpage to register a device.

3.3 Procedures
Before describing the different procedures to join the network, send an uplink
message and claim a device in this architecture, it must be pointed out that this
architecture is provided by Gemalto with a command line interface (CLI) in
order to easily deploy the solution in the cloud, and particularly to build quickly
the cloud middleware on the IoT platform. The main setups done via the CLI
are:

• Building the Lambda functions which process the data messages.

• Provisioning the TKM credentials for connections and the TKM
transport key to the IoT middleware (in Amazon S3).
• Downloading the IoT middleware’s credentials - the client certificate, the
client key and the certificate authority (CA) certificate – for the end-user
in order to connect the IoT middleware to the application server (cf.
3.1.5). These credentials are associated to a Thing representing the
application server.
• Connecting the network server to the IoT middleware via the MQTT
protocol by defining the subscription and publication topics.

23
3.3.1 Join the network
For a connected device to join a network, the sending of the join request is the
same from the point of view of the end-device as described in section 2.1.1.
However, in the implemented architecture, instead of answering directly, the
network server first connects to the TKM.

In order to do so, the network server uses the Transport Layer Security (TLS)
Handshake protocol [23] over HTTP: the network server and the TKM start by
exchanging hello messages to agree on algorithms. These algorithms include a
key exchange method which determines how the shared master key will be
exchanged, a bulk encryption method which determines how application data
will be encrypted and a MAC which determines how application data will be
hashed and signed to prove integrity. They then exchange certificates and
cryptographic information to authenticate themselves. While doing so, the
network server also generates a random pre-master secret and transmits it
securely to the TKM. This pre-master secret is used to create a shared master
secret. The latter contributes to generate four keys shared by the network server
and the TKM: two encryption keys respectively for the network server’s
messages and for the TKM’s messages and two keys to hash respectively the
network server’s messages and the TKM’s messages, allowing them to
authenticate themselves. This protocol is described on Figure 13.

Figure 13. An overview of the TLS Handshake protocol.

Using the four resulting keys, the network server forwards the join request to
the TKM. The TKM checks if the device is registered as allowed to join the
network i.e. allowed to connect to the application server identified by the
AppEUI sent in the join request. If the device is allowed to join the network, the
TKM generates an AppNonce to derive NwkSKey and AppSKey from the
24
device’s AppKey and sends back a join response which has been described in
section 2.1.1. This join response is then relayed to the end-device which is then
also able to generate NwkSKey and AppSKey. Furthermore, the TKM sends the
NwkSKey to the network server.

This new procedure is represented on Figure 14.

Figure 14. Join Procedure in the use case.

3.3.2 Send an uplink message

In order to send an uplink message, the structure and encryption message
remains the same as with the basic LoRaWAN protocol (cf. 2.1.2.). All the
messages are configured as confirmed messages.

If an ACK is not sent by the network server to the end-device, the latter will start
the join procedure over again. Otherwise, the message is then sent by the end-
device to the network server which checks the message’s integrity with
NwkSKey and forwarded to the IoT middleware via the TLS protocol using
MQTT.

If this is the first message sent by this device during the current session, AWS
IoT retrieves the TKM credentials from Amazon S3 to connect to the TKM via
TLS over HTTP and sends a demand to get AppSKey to the TKM to decrypt the
message. This demand sends the DevEUI and an identifier of the session
(SessionKeyID) as parameters. The TKM sends back the AppSKey encrypted by
TK and a key checksum value (KCV) calculated from AppSKey. AWS IoT uses
TK stored in Amazon S3 to decrypt AppSKey and the resulting AppSkey to verify
KCV. AppSKey and SessionKeyID are stored on the Thing Shadow associated
with the device. Consequently, sending a demand to the TKM will not be
necessary for future uplink messages in this session. AppSKey is then used to
decrypt the uplink message. The obtained decrypted message is stored in
25
Amazon DynamoDB and published on the subscription topic of the application
server. If the latter is connected to the IoT middleware (via TLS over MQTT), it
can read finally the decrypted message.

This process is detailed by the Figure 15 and the Table 3.

Table 3. IoT middleware processing an uplink message.

Step Description Lambda
function
1 Receives an uplink message via MQTT, Data-controller
triggering AWS IoT Rules
2 Checks if AppSKey is already cached on the Data-controller
Thing Shadow using DevEUI and SessionKeyID
3 If not, connect to TKM to retrieve AppSKey Tkm-connector
4 Gets TKM credentials and TK from Amazon S3 Tkm-connector
5 Connects to TKM, sends a demand to retrieve Tkm-connector
AppSKey, decrypts it with TK and checks KCV
6 Updates AppSKey and SessionKeyID on the Data-controller
Thing Shadow
7 Decrypts the uplink message Aes-lora-crypto
8 Stores the decrypted uplink message in Amazon Data-controller
DynamoDB
9 Publishes the decrypted uplink message on the Data-controller
MQTT subscription topic of the application
server

26
Figure 15. IoT middleware processing an uplink message.

27
Here, the uplink messages include the current password (regenerated by an
algorithm on the device when a new item is put in the box) and the status of the
box (empty, filled, etc.) to the application server.

3.3.3 Claim a device

In the scope of this master project, there may be several distinct application
servers but only one network server.

Claiming a device can be done by an application provider. It is a change of

ownership of an end-device. In other words, this end-device stops
communicating with an application server and start communicating exclusively
with another one as represented on Figure 16.

Claiming a device is done via the Gemalto CLI mentioned previously (cf 3.2).
The needed parameters are the DevEUI and the name of the group the device
is a member of on the network server and on the TKM. An activation code
(ActivationCode), generated by the TKM either during a previous claim or
during the registration of the device and readable by the user on a QR code on
the device, is also required. Indeed, when a claim is done on a device, the TKM
deactivates it, hence avoiding an exchange of inaccurate messages and the
activation code is needed for the new owner (application provider) to activate it
again.

This procedure follows four steps:

1. The administrator of the new application identifies themselves by their
AWS identifier and password for remote access.
2. It identifies the device by the DevEUI.
3. It changes the ownership of the specified device i.e. it deletes the device
from the previous application provider’s account to the new one’s.
4. It generates a new activation code to be used in case of any future claim.
5. Moves the device from the new owner’s devices’ group.

It is important to indicate that the changes are done on the TKM and on the
network server.

28
Figure 16. An overview of the Claiming procedure.

29
4 Building of the Attack Tree
In this part, the attack goals, i.e. the root reasons to attack, of the presented use
case must be found and justified in order to build an attack tree.

4.1 The attack goals

The attack goals can be set in two categories: compromising of security
properties and compromising of security assets.

Regarding security properties, it has already been said that only three are
considered: confidentiality, integrity and device’s authentication. The system is
considered as compromised if its key management is unable to prevent
compromising of one these three properties.

Security assets on the other hand consist in the most significant security
parameters of our system. Compromising would mean compromising one of the
security properties mentioned above and hence, compromising the whole
system. There are two sorts of assets: primary and secondary. Compromising
the primary assets can directly lead to compromising the system while if one
secondary asset is compromised, more assets are necessary to compromise it.

Table 4. Assets in this thesis' use case.

Asset Primary/Secondary Confidentiality Integrity
AppKey Primary Yes Yes
AppSKey Primary Yes Yes
NwkSKey Primary Yes Yes
FcntUp Secondary No Yes
FrmPayload Primary Yes Yes
DevNonce Secondary No Yes
AppNonce Secondary Yes Yes
AWS accessKeyID Secondary No Yes
AWS Secondary Yes Yes
secretAccessKey
ActivationCode Secondary Yes Yes
AWS credentials Primary Yes Yes
(client certificate,
CA certificate,
client key)
TK Secondary Yes Yes

In Table 4, the assets are presented. Some are confidential while others are not.
However, the integrity of all the assets is assured by the LoRaWAN protocol,
the TLS protocol or simply because they are not communicated online.

The roles of all these assets are described in the previous sections.

31
All the presented assets can be targeted by attackers in theory. However, since
this study focuses on weaknesses during the protocol message exchange, assets
that are only shared offline (such as AWS credentials) and can only be
compromised by attacks like social engineering will not be considered as viable
targets for attackers.

4.2 Known Threats

In order to build the attack tree, now that the attack goals are specified, an
overview of known IoT threats and LoRaWAN threats regarding strictly the
protocol has to be done. This overview is based on the works of Li et al. [24] and
Robert Miller [4].
Table 5. Known threats in IoT applicable to the use case [24].
Layer Threat Description
Sensing Layer Spoofing attack With malware node, the
attacker successfully
masquerades as IoT end-device,
end-node, or end-gateway by
falsifying data
Transmission Threats in transmission, such as
threats interrupting, blocking, data
manipulation,
forgery, etc.
Routing attack Attacks on a routing path
Network Layer Data breach Information release of secure
information to an untrusted
environment
Transmission Threats in transmission, such as
threats interrupting, blocking, data
manipulation,
forgery, etc.
Public key and The compromise of keys
private key
Routing attack Attacks on a routing path
Service Layer Services abuse Unauthorized uses access
services or the authorized users
access unsubscribed services
Identity The IoT end-device, node or
masquerade gateway are masqueraded by
attacker
Replay attack The attacker resends the
information to spoof the
receiver
Routing attack Attacks on a routing path
Application-Interface Security Log and keys leakage
Layer management
Between layers in the IoT Identity spoofing The identities in different layers
architecture have different priorities
32
 Table 6. Known threats in LoRaWAN applicable to the use case [4].
Protocol procedure Risk Threat
Messaging Counters can be Compromising of cipher
manipulated block mode by using
XOR attack
AppSKey/NwkSKey are If wireless message
not unique capture is possible, the
traffic can be spoofed
Join via OTAA AppKey is Replay attack
compromised MitM attack
Internet facing The network server is Malicious data can be
components Internet facing sent by anyone
MIC brute force

4.3 Hypotheses
Several hypotheses need to be explicitly stated in order to justify some choices
in the built attack tree:

• Each component (device, gateway, network server, IoT middleware and

application server) of the architecture is trusted. In other words, an
adversary can act between components or uses its own components to
attack the network but cannot have direct access to the components.
• Only one global network server is considered and since it is trusted (as
stated in the previous hypothesis), an adversary can only own end-
devices, IoT middleware or application servers.
• An adversary is considered as having powerful capability of computation
(they can for example use brute force attacks).
• An adversary can have access to Gemalto resources i.e. a TKM account
and a Gemalto CLI.
• The random generator for DevNonce and AppNonce is considered as
perfect. In other words, DevNonce and AppNonce have discrete uniform
distribution in their respective sets of possibilities.
• There is no availability issues i.e. Denial-of-service (DoS) attacks are not
considered as an issue.
• Social engineering and physical attacks are not considered in this study.
Only threats aiming at protocol’s flaws are studied.
• However, an adversary is considered as able to capture and send
LoRaWAN wireless messages.
• Furthermore, two cases will be studied: if the AppKey (stored on the
device so potentially vulnerable to physical attacks) can be compromised
and if it cannot.

33
4.4 The attack tree
Figure 17, 18, 19 and 20 represent the attack trees used in the analysis of the key
management in this thesis’ use case. As two cases regarding the compromising
of AppKey are considered, the attacks where it intervenes are in grey.

Figure 17. The attack tree for the thesis' use case.

Figure 18. Subtree 1 - Compromising of Confidentiality.

34
 Figure 19. Subtree 2 - Compromising of Integrity.

Figure 20. Subtree 3 - Compromising of Devices' authentication.

35
5 Evaluation of the use case’s key management
This chapter presents scenarios for the different attacks represented in the
attack tree built in the previous section and restitutes this thesis’ system
responses and their consequences on the global security of the used key
management.

5.1 Compromising Confidentiality

In this section, the considered attacks are designed to compromise
confidentiality i.e. to allow an adversary to capture and read messages that are
not intended for them. In this case, it means capturing uplink messages from
the device to the application server.

5.1.1 Eavesdropping after a claim by a malicious application server

For this attack, the adversary is an application provider i.e. they own an
application server and an IoT middleware – which means in this use case, an
AWS account. It is assumed that they have access to the DevEUI, the
ActivationCode and the name of the device’s group in the network server and
the TKM (DeviceGroupName). This information is accessible on the physical
device (e.g. the ActivationCode is stored on a QR code on the device) or by
capturing messages (e.g. the DevEUI can be known by capturing join request
where the DevEUI is sent unencrypted). They also have a TKM account and
access to the Gemalto CLI.

The conduct of the attack is as follows:

• The attacker executes the command to claim a device, entering their

AWS identifier and password for remote access, the DevEUI, the
ActivationCode and DeviceGroupName.
• The network server and TKM are now connected to the attacker’s AWS
account.
• The device’s messages are now forwarded to the application server.

The claim procedure does not require a new AppKey. The device keeps the same
AppKey from which new NwkSKey and AppSKey are derived. AWS IoT can then
retrieve AppSKey from the TKM, even if the attacker does not know AppKey or
AppSKey.

This attack explores two flaws in the system: the lack of supervision regarding
the claiming of devices (its justification for example) and no additional key
management: several application servers can successfully own a device with the
same AppKey. In other words, this thesis’ system does not take into account the
tracking of key material during movement events a measure mentioned as a
requirement for key management in wireless environments in chapter 2.

On a side note, it is relevant to add that it is not explicitly mentioned that the
keys ensuring confidentiality and integrity (namely AppSKey and NwkSKey)
37
are renewed by the sending of a join request message. Not making this measure
systematic can create conflicts and compromise backward and forward secrecy.
As explained in chapter 2, using additional key management is imperative
during movement events.

5.1.2 Eavesdropping by compromising LoRaWAN cipher block mode

This attack requires the attacker to be able to capture LoRaWAN wireless
messages. It explores the flaw of LoRaWAN cipher block mode seen in chapter
2. Indeed, from the data encryption method, a same keystream can be obtained
after a FCntUp reset. This reset can be done manually or when the counter
attains its maximum.

The conduct of the attack is as follows:

• The attacker captures all the uplink messages issued from a device before
and after a FCntUp reset.
• The attacker pair the packets with the same counter value. It is quite easy
as FCntUp is always reset to 0 and is incremented by 1 at each uplink
message.
• The attacker obtains several pairs of ciphertexts resulting from a XOR
with the same keystream.

Plaintext1⊕Keystream = Ciphertext1
Plaintext2⊕Keystream = Ciphertext2
So:
Plaintext1⊕Plaintext2 = Ciphertext1⊕Ciphertext2

• The attacker takes a guess of what Plaintext1 or a part of Plaintext1 is

and derives what Plaintext2 correspondingly is. If the resulting
Plaintext2 makes sense, then the guess is possibly right.

Travis Dazell [25] proposes us an example of this form of guesswork. In this

example, two ciphertexts are considered:

Ciphertext1 = 3b101c091d53320c000910
Ciphertext2 = 071d154502010a04000419
So:
Ciphertext1⊕Ciphertext2 = 3c0d094c1f523808000d09

One assumption can be that the word “the” is in one of these messages, which
translates in “746865” in hexadecimal. A XOR operation on the first six
characters (i.e. the length of “746865”) is executed:

3c0d09⊕746865 = 48656c

In ASCII, “48656c” renders “Hel”. Since it is intelligible, that can be assumed

to be the right message. It can be noted that if the result of the XOR operation
makes no sense, it can be moved to one character to the right to check if the
word “the” is present at least at one position of one of the messages.

38
Here, from “Hel”, “Help” or “Hello” can be guessed to be the first word of one
of the messages. “Help” encoded in hexadecimal becomes “48656c70” while
“Hello” becomes “48656c6c6f”.
The results are:

3c0d094c⊕ 48656c70 = 7468653c

which translates in “the<” in ASCII. And:

3c0d094c1f⊕ 48656c6c6f = 7468652070

which translates in “the p”.

“the p” seems like the more probable option so the process is repeated by trying
to guess different words “the p” might be referring to.

After reiterations, the plain messages can be found: “Hello World” and “the
program”. Such a method is called “crib dragging”. With this method, the more
the attacker witnesses resets, the more likely they are to recover messages.

The studied system is vulnerable to this attack: there is no explicit, specific

protocol procedure to follow in case of reset.

5.1.3 Compromising AppSKey

For this attack, the attacker is assumed to know the AppKey. It might be the
case if the physical device can be compromised. As it has been seen, AppSkey is
derived from it as follows:

AppSKey = aes128_encrypt(AppKey, 0x02|AppNonce|NetID|DevNonce|pad16)

All these parameters are communicated through join-request messages which

are not encrypted and join-accept messages which are encrypted by AppKey.
Thus, an attacker knowing AppKey is able to compromise AppSKey as well.

5.2 Compromising Integrity

In this section, the considered attacks are designed to compromise integrity i.e.
to allow an adversary to modify messages’ content when the latter is in transit.
In this case, it means modifying the device’s messages before they reach the
application server.

5.2.1 Man in the Middle attack by compromising NwkSKey

The approach for this attack starts as the same as compromising AppSKey; the
attacker is assumed to know the AppKey and can then calculate NwkSKey after
capturing the join-request and join-accept messages associated as follows:

NwkSKey = aes128_encrypt(AppKey, 0x01|AppNonce|NetID|DevNonce|pad16)

Knowing the NwkSKey enables the attacker to execute a Man-in-the-Middle

(MitM) attack [26]: it consists of an attacker intercepting messages between
two end points (here, the device and the application server) and replacing the
sent messages with their own.
39
The point of this attack is to intercept and modify the message before the
integrity is checked. NwkSKey is used to create a new valid MIC for the modified
message. This attack can be operated between the device and the gateway or
between the gateway and the network: the only difference is that one point is
internet-faced when the other is not. For the sake of an example, a MitM attack
between the device and the gateway is considered, assuming then that the
attacker can capture wireless messages, and detailed by Figure 21 and Table 7.

Figure 21. MitM attack between device and gateway with a compromised
NwkSKey.

Table 7. MitM attack between device and gateway with a compromised NwkSKey.
Step Action
1 The device is sending a message.
2 The attacker intercepts it.
3 The attacker changes the payload.
4 With the help of the compromised
NwkSKey, the attacker signs the
message with a valid MIC.
5 The attacker sends the modified
message to the gateway.
6 The network server checks the
message’s MIC with NwkSKey and
validates it before forwarding it to the
IoT platform.
7 The application server receives the
modified message.

40
5.2.2 Bit-flipping attack between device and network server
This attack is also a derivative of the MitM attack but does not require the
attacker to know the AppKey. The specification resides in the method to modify
the payload: indeed, the bit-flipping attack aims at changing specific fields on
ciphertext without decryption of the ciphertext when the plaintext and the
associated ciphertext have the same bit order [27]. In the studied system, the
encryption method (cf. 2.1.2) does not shuffle the order of the plaintext’s bits.
This attack seems then applicable.

The principle of this attack is to modify a message by modulating specific bits

of the ciphertext in the same position of the bits in the field of the plaintext the
attacker wants to change. Here, we are considering the bits in the field
corresponding to the message’s payload.

The attack proceeds as follows:

• The attacker captures wireless data messages sent by the end-device to

the network server.
• Knowing the structure of a data message (cf. Figure 5), the attacker
locates the bits corresponding to the frame payload.
• The attacker modulates some of these bits.
• The attacker executes a MIC brute force attack: they send sequentially a
great number of messages with different combinations of possible MIC
until the message is accepted by the network server. A correct MIC is
necessary for the message to be forwarded to the application server.

This last step is possible for two reasons:

• The network server is internet-facing as represented on Figure 22,

allowing to send a great number of messages in a short time.

Figure 22. Internet-facing gateway and network server.

• The MIC’s length is four octets. This means 232 possibilities for a brute
force attack. According to Table 8, the attacker will then make 2, 147,
483, 648 attempts on average to find out the correct MIC for a modified
message. Table 9 presents the processing time of the simulator of Jung
41
 Wong Lee et al. [27] to search a correct MIC according to the used
system. It can be noted that only a few seconds seem necessary.

Table 8. Number of brute-force attack attempts to succeed with N the length of

the target.
Best case Worst case Average
1 N N/2

Table 9. Processing time to search a correct MIC [27].

Core Single Dual Quad
Average 9287.2 3868.4 1516.5
processing Time
[ms]

Regarding the bit-flipping part itself, the concept is simple but it can make the
application server register false data. Table 10 shows an example.

Table 10. An example of bit-flipping attack on the frame payload [27].

Before Plaintext : {ID: 0001, humidity: 13}
attack Ciphertext : 47A8F8859D40C0AB669D6ABFE4A89E54588E2925F3B039
After attack Plaintext : {ID: 0001, humidity: 43}
Ciphertext : 47A8F8859D40C0AB669D6ABFE4A89E54588E2925F6B039

5.2.3 Bit-flipping attack between network server and application server

In theory, the second attack point for bit-flipping would be between the network
server and the application server. In the studied architecture, it means between
the network server and the IoT middleware or between the IoT middleware and
the application server.

In this case, searching a correct MIC is not necessary: the integrity is not
checked passed the network server.

However, in this thesis’ system, the communication between the network server
and the IoT middleware and between the IoT middleware and the application
server is protected by the TLS protocol which is described in 3.3.1. It provides
the privacy and data integrity of these communications respectively by
encryption keys and methods and hash functions [23].

5.3 Compromising Device’s authentication

In this section, the considered attacks are designed to compromise a device’s
authentication i.e. to allow an adversary to do “spoofing” attacks. In this case,
it means allowing a device to join the network or send an uplink message to the
network while pretending to be another trusted device.

5.3.1 Malicious join

A malicious device succeeding to join the network might do a lot of damages. It
can send malicious data to the application server and prevent the original
device to connect to the network. There are several possible types of attacks in
order to join the network while masquerading as a trusted device.
42
Replay attack
Before presenting this attack, there are two hypotheses to consider in the
studied system:
• A network server receiving a join request message with a DevNonce
registered as already used previously simply drops the join request
message.
• The number of DevNonce registered as already used by the network
server is limited and inferior to the number of all possibilities (exactly
216 possibilities since DevNonce is 2-octet-long).

This attack is pretty simple and based on the work of Seung Jae Na et al. [28].
It proceeds as follows:
• The attacker collects as many join request messages from the devices as
possible.
• They analyze these join requests in order to obtain two pieces of
information:
Which devices send join request messages periodically and
frequently: one of these devices will be the targeted device D.
For one device, how much time there is in average between two
join requests using the same DevNonce; indeed, DevNonce is
used as an indicator to prevent replay attacks. However, since it
is chosen randomly and that there is limited possibilities,
DevNonce is bound to be repeated over time. The network server
takes this into account and has only a number of previous
DevNonce registered and not all of them.
• Once they have determined both of these points, the attacker can fix a
time T when a replay attack towards the device D is most likely to
succeed.
• At the time T, the attacker sends back the collected join request messages
from de device D to the network server. It will have two effects:
The malicious device will join the network.
Since a lot of join request messages have been sent, several
possible DevNonce will be registered by the network server,
preventing the trusted device to reconnect with them: this can
delay the user’s actions on the attack.

In order to find T, Simone Zulian [29] proposes this formula:

!+1
=
#$
where ND is the number of previously used values of DevNonce stored by the
network server and fJ the number of valid join procedures per day for the device
D.

On Figure 23, the evolution of T as a function fJ is represented as a graph for

different ND.

43
This attack explores the fact the AppKey of the device never changes. However,
the harmfulness of this attack is relative as T can be very long (in his work,
Simone Zulian [29], with ND = 7300 and fJ = 1 valid join procedure/day, T = 20
years), it all depends on the frequency of join requests.

120

100

80
T (days)

60

40

20

0
0 2 4 6 8 10 12 14 16 18
f (Valid join requests/day)

N=10 N=40 N=100 N=200

Figure 23. The time T a malicious node has to wait in order to perform a replay
attack as a function of f the number of valid join procedures for one device per
day and N the number of previously used values of DevNonce stored by the
network server.

Compromised AppKey
For this attack, the attacker is considered as knowing AppKey. In this case,
nothing prevents them to send a valid join request message.

The attacker only needs to capture registered devices’ join request messages: it
allows them to know registered DevEUIs and AppEUI (since the message is sent
unencrypted). It also lets the attacker know previously used DevNonce in order
to avoid their join request message to be dropped.

With this information, they can sign their join request message by creating a
MIC with AppKey.

MIC brute force

The last presented attack to join the network by spoofing also uses a MIC brute
force attack. As seen previously (cf. 5.2.2), according to Jung Wong Lee et al.’s
work, a correct MIC can be found in a matter of seconds.

Then, the attack proceeds as follows:

44
 • The attacker captures wireless join request messages and notes the
parameters of a target they are going to imitate (DevEUI, AppEUI and
previously used DevNonce).
• The attacker creates an unsigned join request message with a DevNonce
that has not been used. It must be noted that, since DevNonce are
random and the number of used DevNonce stored in the network server
%&'&() * %+&',-.
is limited, there is a probability of to get a DevNonce that
%&'&() – 0
will be accepted with Ntotal the number of possible combinations for
DevNonce (here, it is 216), Nstored the number of used DevNonce stored in
the network server and Nobserved the number of used DevNonce observed
by the attacker and where α= Nobserved if Nobserved≤ Nstored, else α= Nstored.
• The attacker sends in brute force join request messages with different
MIC until the network accepts one, which means the MIC was correct.

5.3.2 Sending malicious data messages

Spoofing does not only consist in joining the network by emulating another
registered device. It also includes aiming at sending data messages while
masquerading a registered devices. This can be done with the replay attack i.e.
resending captured messages.

However, if an adversary resends a captured message without modification, the

network server will discard it. Indeed, when the network server receives a
message, it checks that FCntUp is incremented by one relative to the last
received uplink message from the sending device.

It is then necessary for the attacker before resending the message to have
captured the last message of the target device and to adequately change
FCntUp. This provokes a change of MAC payload and consequently needs a new
MIC. A brute force attack, as described in 5.2.2, can be performed to generate a
correct MIC for this new message.

This attack explores the fact that the network server is internet-facing, allowing
large amounts of messages to be sent, and results in the application server
receiving and acting upon false data.

45
6 Discussion and Security suggestions
This chapter discusses possible countermeasures for the attacks and threats
described in the previous chapter and concludes on the level of security of the
studied system’s key management.

This system’s main flaws, identified from the description of the possible threats
on the key management, are:
• the possible compromising of AppKey and its consequences
• an absence of specification in case of counter reset
• the possibility to use successful brute force attacks on messages’ MIC
• the possible compromising of LoRaWAN cipher mode encryption
• an absence of explicit control for claiming (or more generally, for host
mobility)

6.1 Preventing the compromising of AppKey

As seen in the previous chapter, the compromising of AppKey has particularly
heavy consequences on the confidentiality, integrity and device’s
authentication properties of the key management of the studied system. Indeed,
with a compromised AppKey, an attacker is able to compromise AppSKey and
NwkSKey and to operate a spoofing attack.

Several solutions exist, on the hardware and software sides, to prevent the
compromising of AppKey or at least, to limit the exploitation damages.

6.1.1 Hardware protection: Embedded Secure Elements

The first security improvement is to make the hardware end-device more secure
and then to protect the data handled by the device such as the AppKey.
Embedded Secure Elements (eSEs), such as the one proposed by Gemalto,
would provide an adequate protection.

According to Gemalto’s documentation [30], the eSE is a tamper-proof chip

which can be embedded in any mobile device and ensures the data is stored in
a safe place and information is given to only authorized application and people.
Each unit of eSE is loaded with uniquely diversified keys, identifiers and data
files.

If the security of such elements is ensured, so will be AppKey’s privacy if one

eSE is integrated with the end-device.

6.1.2 Software: Management of AppKey

However, the physical attacks are not being addressed in this thesis. Another
option is to try to improve AppKey’s privacy, simply by modifying or specifying
its management.

For now, the only specification of the provisioning of AppKey is that it is defined
and shared offline with the TKM before the end-device is even activated.
47
According to LoRaWAN specification [7], each AppKey has to be specific to each
end-device to preserve Key Independence: compromising one AppKey from an
end-device only compromises this end-device. These AppKeys being completely
independent, it also ensures Resistance to Collusion: knowing several AppKey
does not allow to deduce the others.

However, a device’s AppKey is never changed. Since moving from one

application server to another is a possibility, it can threaten Backward and
Forward Secrecy. Indeed, compromising one AppKey of one end-device during
one specific session means compromising it for each future and previous
sessions with this device, even when shared with different TKM users i.e. in a
new group of users.

Changing AppKey might then seem a good idea but the difficulty here is for the
end-device and the TKM to agree on a new AppKey securely. The only secure
option would require another key to administrate or rotate the AppKey. It
would avoid compromising due to social engineering for example. However,
assuming the end-device is compromised, there is no obvious way to agree on a
new AppKey without the attacker being aware of the update. It might be better
to implement a mechanism to detect if the device has been tampered with: when
the end-device would be detected as compromised, the TKM will considered it
as not allowed to join the network.

The problem is then to define an efficient way to detect if a device has been
compromised or not. This issue is still studied in the industry and there is no
definitive answer. Of course, a device can, when sending a message and being
repeatedly denied, detect that somebody has joined the network under its name
and consequently send a new join request message to disconnect the attacker,
but this method is not really efficient. Indeed, if an emulated device does not
try to send a message for a long time, the attacker would use that time to send
compromised information. Furthermore, for some attacks such as MIC brute
force, emulating a device does not take a lot of time – as seen in section 5.2.2 –
and the attacker might then just perform the attack again.

However, it is possible to improve the detection of compromised devices by

studying malicious behavior and at least partial security measures can be
provided to detect malware. For example, Guillermo Suarez-Tangil et al. [31]
propose a concept of “cooperative security” for network of smart devices: each
device monitors the behavior of others to detect compromising.

Machine learning can be useful to conduct a study on compromised devices’

behavior in order to detect malicious behavior. After a phase of observation and
analysis, end-devices’ behavior could be determined as suspicious or not. A
suspicious end-device could then be turned down remotely or its messages
could be refused by the system.

6.2 Managing Join requests

In the previous chapter, two main risks are related to join requests:
48
 • On the one hand, it is necessary to change session keys, i.e. to send a new
join request message, when there is a reset of FCntUp in order to prevent
eavesdropping.
• On the other hand, increasing the frequency of join requests
exponentially decreases the time an attacker has to wait to execute a
replay attack in order to join the network.

For the first issue, it seems that the device has to keep track of the FCntUp and
sends a new join request message and consequently generates new session keys
at each counter reset, manually forced or not, to prevent compromising of the
cipher block mode and eavesdropping.

Regarding the second point, the root of the problem has first to be identified.
In this case, the vulnerability resides in the DevNonce and the probability of its
reusability in a replay attack. Indeed, a replay attack uses two weaknesses of the
system: the limit of storage of used DevNonce by the network server and the
probability of generating an already used DevNonce. If the network server could
memorize all of the used DevNonce and that every join request message could
be sure to have a unique DevNonce for the device, then a replay attack would
not be possible.

One solution, proposed by Simone Zulian [29], is to make DevNonce a

sequential number and not a random one. Indeed, according to him, the
randomness of DevNonce is less relevant than its unicity regarding the security
of the standard. In this solution, the network server would just keep track of the
last sent DevNonce which would be incremented at each join request message
from the device. A join request message whose DevNonce was not coherent with
the Last DevNonce (LDN) received by the network server would be dropped.
Ensuring the synchronization of the end-device and the network server could
be done by sending a LDN request from the end-device if it detects that its join
request messages are all discarded. In response, the network server would send
it, encrypted by the AppKey in order not to be intercepted by listeners.

Such a solution would significantly reduce the risk of a successful replay attack
on a join request. It could only be performed if all 216 possibilities of DevNonce
were used, which would take approximatively twenty years if the device
operated ten valid join operations a day. When reaching this DevNonceMAX, the
end-device would just turn off.
1
Furthermore, in term of probability, there is always a probability of to get
%23245
%&'&() * %+&',-.
the correct DevNonce, instead of with Ntotal the number of
%&'&() – 0
possible combinations, Nstored the number of used DevNonce stored in the
network server and Nobserved the number of used DevNonce observed by the
attacker and where α= Nobserved if Nobserved≤ Nstored, else α= Nstored.

However, regarding device’s authentication, an attacker could send a

fraudulent join request by listening to the network’s messages and simply
49
resending the last join request message with an incremented DevNonce and
combining it with a MIC brute force attack.

In the next section, the author tries to improve this solution by focusing on the
prevention of brute force attacks.

6.3 Preventing brute force attacks on MIC

As previously written in this thesis, one of the hypotheses is that the attacker
has sufficient computation power in order to execute, for example, brute force
attacks.

In the presented possible attacks, the MIC has been presented various times as
a potential target for brute forcing. In this section, suggestions are given to
increase the necessary time for brute force

MIC being generated and used differently in join request messages and data
messages, they are considered as two distinct cases.

6.3.1 In Join Request messages

Seung Jae Na et al. [28] propose a solution which, incidentally, also handles the
privacy of DevNonce, an issue mentioned in the previous section.

Their solution consists in producing a token and performing a XOR operation

between this token and the fields of DevNonce and MIC, as represented on
Figure 24.

Figure 24. An example of XOR masking.

Seung Jae Na et al. [28] suggest to use the six first octets of the previous
NwkSKey to create this token (the six first octets of AppKey for the first join
request message). This would have two effects:
• A token would be unique and independent for each message, preventing
listening attackers to predict the token.

50
 • The network server would be able to create the token as well without
implementing more operations and performing a XOR operation again
to get the DevNonce and the MIC of the message.

Using this technique would prevent brute force on MIC. Indeed, there would
then be 248 possibilities: it would then take more than one year in average to
find a correct combination assuming one thousand attempts can be done in a
second. This result is based on the calculation explained in the previous chapter
(cf. Table 8).

Moreover, it would preserve the confidentiality of a sequential DevNonce.

6.3.2 In Data messages

Brute force attacks on MIC should be limited in data messages. Otherwise, it
would facilitate bit-flipping attacks.

The easiest solution would be to lengthen the MIC: the probability of

successfully brute force it is halved at every added bit. However, there are two
drawbacks:
• This solution requires incrementing the size of data message which may
be costly or reducing the size of frame payload. However, if in an
application, the data messages do not require the maximum, this
modification may then not be that troublesome.
• Even if the probability of a successful brute force attack is lowered i.e.
the average time to find a correct MIC is increased, it does not totally
prevent the risk of brute force attack, particularly with increasingly
powerful computers.

However, there may be a less costly solution to counter bit-flipping attacks

rather than limiting brute-force attacks on MIC. A modification of the cipher
mode encryption combined with a verification on the IoT platform that the
format of the frame payload is respected might be enough. This solution is
discussed in following sections.

6.4 Securing LoRaWAN cipher mode encryption

As seen in the last chapter, the cipher mode used with LoRaWAN protocol has
two acknowledged weaknesses:
• There is no modification of the bits’ place before and after encryption.
Consequently, knowing the structure of a message can allow an attacker
to target specific bits corresponding to crucial values in the encrypted
message for a bit-flipping attack.
• With a same keystream, it may be possible to guess the contents of
several messages.

It has been decided in this chapter that the second threat can be prevented by
ensuring that two messages are never sent with the same keystream, ideally by
triggering a new join procedure when FCntUp is reset.

51
For the first threat, Jong Woon Lee et al. [27] propose a solution: shuffling bits
of the frame payload of the resulting encrypted message.

This shuffling method has two steps:

• The first step, called the “shift phase”, consists in shifting circularly the
bits to the left. To determine how many octets the frame payload has to
shift, the first octet of NwkSKey which is different from the length of the
frame payload MaxSize is used (modulo MaxSize).

• The second step is named the “swap phase” and unfolds as follows:
1. For each octet in position p of the frame payload, the octet i in
corresponding position (modulo the length of NwkSKey) in
NwkSKey is considered.
2. k is defined as i modulo MaxSize. If they are not already swapped,
the octet at the position k of the frame payload and the octet at
the position p are swapped.

Both of these algorithms are described in further details in the appendix A and
example of the execution is represented on Figure 25.

Figure 25. Process of Frame Payload Shuffling.

Once this solution is implemented, attackers would have no way to tell which
fields they have modified. Consequently, the probability for the message to have
an invalid format, hence being ignored by the application server, is greatly
increased.

The main disadvantage for this method is that it is not suitable for devices with
low power and low resource.

A complementary or replacement measure could be for the network server to

keep track of unreadable or invalid messages from the end-device. Indeed,
when a bit-flipping attack is performed, the attacker has no way to predict what
the decryption of the resulted message would be. Consequently, there are often
messages with invalid characters received by the application server in this case
52
which should incite the TKM to ban the end-device from the network or at least,
to put it in probation for further verification (which would be conducted by
sending technicians onsite for example).

In parallel, since bit-flipping attack is conjugated with a brute force attack on

the MIC, the network server would probably have acknowledged receipts of
messages with invalid MIC. This also must be seen as a warning sign of a
probable attack.

This detection mechanism echoes to the suggestion made on section 6.1.2.

6.5 Securing host mobility

One of the most blatant flaw of the studied system regards the claim procedure
where a device switches from one application server to another. As said in
chapter 5, this procedure does not implement the tracking of key material
during movement events nor ensure additional key management (detailed in
chapter 2), which are requirements for key management in wireless
environments. Solutions are proposed below for the TKM to gain more control
on movement events and preventing a conflict of keys.

6.5.1 Claim procedure

The fact which mainly hampers overall control on movement events is that only
public or accessible information are necessary in order to claim a device.
ActivationCode and DeviceGroupName are a priori accessible via a QR code on
the device, meaning an attacker who has physical access to a device can claim it
and DevEUI can be captured in wireless join request messages which are not
encrypted. Hence, there is no control on who can claim a device.

A private parameter, passed through by an administrator (in real life, probably

the network operator or the company itself), could be used in order to prevent
unrequired claim requests. In this work, the TKM is considered as this
administrator, as it is responsible for key material. It would then make sense to
keep track of the claim requests and movements of the devices. Therefore,
application servers which are allowed to connect to the network server should
be registered as allowed to connect in the TKM beforehand, in the same fashion
as the devices. In this use case, registered application servers are from then on
considered as trusted.

This private parameter could for example be DeviceGroupName since it is

supposed to be entered in the network server and the TKM. Instead of storing
it in the QR code, it might be retrieved as follows:
• The application server sends a claim pre-request to the TKM. This
request includes DevEUI and AppEUI.
• The TKM checks that the application server is registered as allowed to
connect to the network server. If it is not, there is no answer. If it is, the
TKM sends the DeviceGroupName corresponding to the group where
the device with the received DevEUI belongs, encrypted with TK, the
TKM transport key.
53
 • The application can then do a standard claim request.
• When the claim procedure is successfully done, the DeviceGroupName
of the device changes.

In this case, DeviceGroupName might be a random tag attached to each

application server.

Furthermore, in the system as studied, the TKM only keeps the current
application server for the device. In an upgraded system, the TKM could keep
track of a list of the previous application server the device was attached to as
well. It would be easier to detect suspicious behavior such a chaotic pattern of
claim procedures.

Finally, it may seem obvious, but it is important to automatize the sending of a

new join request message when a claim procedure is achieved successfully. It
guarantees the renewal of AppSKey and NwkSKey to avoid conflicts and
eavesdropping by previous or future application providers.

54
7 Summary and Conclusion
The LoRaWAN protocol has gained in popularity with the spreading of IoT with
low power and low resource devices for long distance communications. Indeed,
LoRaWAN consists in a MAC layer protocol for the LoRa technology, a format
modulation for LPWAN (Low Power Wide Area Networks).

With this technology, the issue of key management in wireless environments

has risen. The system must control who has the keys, avoid conflicts and
unwanted shared keys and ensure they are secure enough not to be guessed at
their generation.

With the LoRaWAN protocol, confidentiality and integrity keys are traditionally
kept in the network server. It guarantees unique keys for each device in a
session but on the other hand, it allows the network server to read every
message from the end-device to the application server.

However, Gemalto has argued that such a solution could lead to conflict of
interests as a network operator (owner of the network server) and an
application provider (owner of the application server and, optionally, of an IoT
middleware) could be separate entities. In this case, the network server should
not be able to decrypt the data messages between the application server and the
end-device. Yet, since these keys are sensitive information, it makes sense not
to be stored directly by the final client (application provider).

In order to solve this problem, Gemalto proposes a solution with a trusted third
party which manages the generation and distribution of confidentiality and
integrity keys. Nevertheless, some questions must be addressed:

• What are the known threats and weaknesses key management via a
trusted third party can encounter with LoRaWAN protocol?
• How does Gemalto’s installation in particular deal properly with these
threats?
• What security improvements could be made?

In order to answer to these questions, an experimental architecture including a

Trusted Key Manager was implemented by the author and an attack tree was
built: this threat analysis method is appropriate since it allows to regroup the
possible threatening attacks by the fundamental properties they are trying to
compromise which are here the confidentiality and integrity of the data
messages and the guarantee of device’s authentication.

After simulating these attacks on Gemalto’s system and observing its answers,
five vulnerabilities of the system were drawn out:

• the possible compromising of AppKey and its consequences

• an absence of specification in case of counter reset
55
 • the possibility to use successful brute force attacks on messages’ MIC
• the possible compromising of LoRaWAN cipher mode encryption
• an absence of explicit control for claiming (or more generally, for host
mobility)

Consequently, the solutions proposed by this thesis to improve the security of

this system are:

• Using embedded Secure Elements in order to protect AppKey on the

device and prevent all the attacks resulting from a compromised
AppKey.
• Using a system detecting probable malicious behavior from the end-
device, possibly by using machine-learning. This system will take into
account amongst other parameters the frequency of join procedures, the
frequency of sent invalid or unreadable messages and the frequency of
sent messages with invalid MIC. A detected anomaly could lead to
further verification on the material e.g. by sending technicians onsite or
if crucial information is concerned, the immediate ban of the end-device
from the network.
• Systematically sending a new join request message when FCntUp is reset
in order to prevent compromising of the cipher mode encryption.
• Replacing the random generation of DevNonce by an incremental
DevNonce in order to reduce the probability of success of a brute force
attack on DevNonce. However, a solution is then necessary to protect the
confidentiality of DevNonce.
• Using a token generated from NwkSKey for a XOR operation between
the fields including DevNonce and the MIC in a join request message and
the token in order to reduce the probability of success of a brute force
attack on DevNonce or on the MIC of the join request message and not
to compromise DevNonce.
• For devices with sufficient power and resource, shuffling the octets of the
frame payload message to make a bit-flipping attack more difficult.
• Making DeviceGroupName a private parameter, only accessible,
encrypted by a shared transport key, by the application server via the
TKM which is responsible for tracking the devices’ movements and the
authorizations for application servers to claim them.
• Ensuring that a new join request message is sent when a successful claim
procedure is achieved.

7.1 Future work

This thesis is the first step to analyze an architecture using the LoRaWAN
protocol and a trusted third party for key management.

In future work, in order to reinforce the security of the system even more, more
research into physical attacks should be conducted, for example regarding side-
channel attacks. These attacks should be studied and evaluated to limit their

56
consequences. The proposed solutions, such as eSE, must also be studied in
more details: what can be done with them, what are their limits?

Furthermore, only a few criteria were considered here to evaluate the security
of the system: confidentiality, integrity and device’s authentication. Yet, there
are other criteria which must be studied such as availability, privacy of the
device’s location, and so on, in order to design more secure systems.

Besides, this study is focused on Class A devices which are using the basic
LoRaWAN protocol. However, Class B and Class C devices should also be
studied, with their particularities regarding the LoRaWAN protocol. Regarding
the LoRaWAN protocol, the APB activation should be studied in this
architecture too.

It is also important to stress the fact that the study case here is mainly a Proof
of Concept. Issues that can be encountered after a production start, such as the
management of collusions between a large number of devices or gateways.

The protocol for downlink messages (from the application server to the end-
device) are also not mentioned and would need some reflections too, as there
may be some specific attacks for this feature.

A study with several network servers and the possibility for an end-device to
move from one network server to another should also be conducted since it may
reveal other weaknesses points than those mentioned in this thesis.

Finally, future work on a detection system for malicious behavior from end-
devices must be done: the parameters to monitor and security thresholds have
to be defined in order to determine if a device can be seen as uncompromised,
suspected or compromised.

57
References
[1] L. Srivastava, P. Biggs et al., The Internet of Things, International
Telecommunication Union, 2005.
[2] U. Raza, P. Kulkarni and M. Sooriyabandara, “Low power wide area
networks: An overview”, IEEE Communications Surveys Tutorials, vol.
PP, no. 99, pp. 1-1, 2017.
[3] D. Patel and M. Won, “Experimental Study on Low Power Wide Area
Networks (LPWAN) for Mobile Internet of Things”, IEEE 85th Vehicular
Technology Conference, 2017.
[4] R. Miller, “LoRa The Explorer – Attacking and Defending LoRa Systems”,
Proceedings of SyScan 360, MWR Labs, 2016.
[5] LoRa-Alliance | Technology, Available on: lora-alliance.org/technology.
Last consulted: 2017-09-26.
[6] Gemalto Trusted Key Manager, Available on:
gemalto.com/m2m/solutions/trusted-key-manager-for-lora. Last
consulted: 2017-09-26.
[7] J. Nordlöf and P. Lagusson, “A Study of Low-Power Wide-Area Networks
and an In-Depth Study of the LoRaWAN Standard”, Royal Institute of
Technology of Stockholm (KTH), Master thesis, 2017.
[8] N. Sornin, X. Vilajosana et al., LoRaWAN™ Specification, version 1.0.2,
2016.
[9] F. Adelantado, M. Luis et al., “Understanding the Limits of LoRaWAN”,
IEEE Communications Magazine, 2017.
[10] IEEE 802 Working Group, IEEE Standard for Local and Metropolitan
Area Networks – Part 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs), IEEE Std 802.15.4TM-2011 (Revision of IEEE
Std 802.15.4-2006), Annex B, 2011.
[11] X. Yang, “LoRaWAN: Vulnerability Analysis and Practical Exploitation”,
Delft University of Technology, Master thesis, 2003.
[12] S. Rafaeli and D. Hutchison, “A Survey of Key Management for Secure
Group Communication”, ACM Computing Surveys (CSUR), vol. 35, no.
3, pp. 309-329, 2003.
[13] Y. Kim, A. Perrig and G. Tsudik, “Simple and Fault-Tolerant Key
Agreement for Dynamic Collaborative Groups”, Proceedings of the 7th
ACM conference on computer and communications security, pp. 235-
244, 2000.
[14] B. Daghighi, M. L. M. Kiah et al., “Key management paradigm for mobile
secure group communications: Issues, solutions, and challenges”,
Computer Communications, vol. 72, pp. 1-16, 2015.
[15] G. Camponovo and Y. Pigneur, “Business model analysis applied to mobile
business”, Proceedings of the 5th International Conference on
Enterprise Information Systems, pp. 1-10, 2003.
[16] B. Schneier, “Attack trees”, Dr. Dobb’s journal, vol. 24, no. 12, pp. 21-29,
1999.

59
[17] C. A. Meadows, “Applying Formal Methods to the Analysis of a Key
Management Protocol”, Journal of Computer Security, vol. 1, no. 1, pp.
5-36, 1992.
[18] R. Küsters and T. Truderung, “Using proverif to analyze protocols with
diffie-hellman exponentiation”, Computer Security Foundations
Symposium, 2009. CSF’09.22nd IEEE, pp. 157-171, 2009.
[19] Compact server for private LoRa networks. Available on:
github.com/gotthardp/lorawan-server. Last consulted: 2017-10-05.
[20] How AWS IoT Works – Amazon Web Services. Available on:
docs.aws.amazon.com/iot/latest/developerguide/aws-iot-how-it-
works.html. Last consulted: 2017-10-05.
[21] Managing Things with AWS IoT – AWS IoT. Available on:
docs.aws.amazon.com/iot/latest/developerguide/iot-thing-
management.html. Last consulted: 2017-10-10.
[22] Device Shadows for AWS IoT – AWS IoT. Available on:
docs.aws.amazon.com/iot/latest/developerguide/iot-thing-
shadows.html. Last consulted: 2017-10-10.
[23] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol
Version 1.2”, RFC 5246, 2008.
[24] S. Li, T. Tryfonas and H. Li, “The Internet of Things: a security point of
view”, Internet Research, vol. 26, no. 2, pp. 337-359, 2016.
[25] Travis Dazell: Many Time Pad Attack – Crib Drag. Available on:
travisdazell.blogspot.fr/2012/11/many-time-pad-attack-crib-
drag.html. Last consulted: 2017-10-13.
[26] Y. Desmedt, “Man-in-the Middle Attack”, Encyclopedia of Cryptography
and Security, pp. 759, 2011.
[27] J.W. Lee, D. Y. Hwang et al., “Risk Analysis and Countermeasure for Bit-
Flipping Attack in LoRaWAN”, Information Networking (ICOIN), 2017
International Conference, pp. 549-551, 2017.
[28] S. J. Na, D. Y. Hwang et al., “Scenario and Countermeasure for Replay
Attack Using Join Request Messages in LoRaWAN”, Information
Networking (ICOIN), 2017 International Conference, pp. 718-720,
2017.
[29] S. Zulian, “Security threat analysis and countermeasures for LoRaWANTM
join procedure”, Università degli Studi di Padova, Thesis, 2016.
[30] Embedded SIM, eSE for consumer electronics: IoT applications for a wide
range of devices, Available on: gemalto.com/iot/consumer-
electronics/embedded-secure-element. Last consulted: 2017-10-19.“
[31] G. Suarez-Tangil, J. E. Tapiador et al., “Evolution, Detection and Analysis
of Malware for Smart Devices”, IEEE Communications Surveys &
Tutorials, vol. 16, no. 2, pp. 961-987, 2014.

60
Appendix A: Frame Payload Shuffling method algorithms

Algorithm 1 Circular Shift To The Left

1: MaxSize ← The length of FramePayload
2: if nwkSKey[0] != MaxSize then
3: c ← nwkSKey[0] mod (MaxSize)
4: else
5: while nwkSKey[0] == nwkSKey[i] do
6: i←i+1
7: end while
8: c ← nwkSKey[0] mod (nwkSKey[i])
9: end if
10: Circular c shift to the left

Algorithm 2 Swap : One-to-one exchanges

1: MaxSize ← The length of FramePayload
2: j ← 0
3: for i = [0..MaxSize] do
4: k ← nwkSKey[j] mod MaxSize
5: j ← j + 1
6: if j > length of nwkSKey then
7 j←1
8: end if
9: if swapTable[i,k] == false
10: swapTable[i,k] ← true
11: swap(FRMPayload[k],FRMPayload[i])
12: end if
13: end for

61