Key management with a trusted third party using …...i DEGREE PROJECT, IN PROGRAMME, SECOND LEVEL...

i

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

iii

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.

v

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

vii

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

ix

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

x

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

xi

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

xiii

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

xv

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

xvi

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

1

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

2

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.

3

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.

4

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.

5

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.

7

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.

8

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 packets

Payload size [B] Number of end-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.

9

• 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.

10

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

11

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.

12

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 (bytes)

1 4 1 4 4 1 1

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

13

• 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:

14

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.

15

• 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

16

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.

17

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.

18

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.

19

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.

20

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.

21

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.

22

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.

23

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.

24

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

25

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

26

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, triggering AWS IoT Rules

Data-controller

2 Checks if AppSKey is already cached on the Thing Shadow using DevEUI and SessionKeyID

Data-controller

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

AppSKey, decrypts it with TK and checks KCV Tkm-connector

6 Updates AppSKey and SessionKeyID on the Thing Shadow

Data-controller

7 Decrypts the uplink message Aes-lora-crypto 8 Stores the decrypted uplink message in Amazon

DynamoDB Data-controller

9 Publishes the decrypted uplink message on the MQTT subscription topic of the application server

Data-controller

27

Figure 15. IoT middleware processing an uplink message.

28

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.

29

Figure 16. An overview of the Claiming procedure.

31

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 secretAccessKey

Secondary Yes Yes

ActivationCode Secondary Yes Yes AWS credentials (client certificate, CA certificate, client key)

Primary Yes Yes

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.

32

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

Threats in transmission, such as 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

Threats in transmission, such as interrupting, blocking, data manipulation, forgery, etc.

Public key and private key

The compromise of keys

Routing attack Attacks on a routing path Service Layer Services abuse Unauthorized uses access

services or the authorized users access unsubscribed services

Identity masquerade

The IoT end-device, node or 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 Layer

Security management

Log and keys leakage

Between layers in the IoT architecture

Identity spoofing The identities in different layers have different priorities

33

Table 6. Known threats in LoRaWAN applicable to the use case [4].

Protocol procedure Risk Threat Messaging Counters can be

manipulated Compromising of cipher block mode by using XOR attack

AppSKey/NwkSKey are not unique

If wireless message capture is possible, the traffic can be spoofed

Join via OTAA AppKey is compromised

Replay attack MitM attack

Internet facing components

The network server is Internet facing

Malicious data can be 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.

34

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.

35

Figure 19. Subtree 2 - Compromising of Integrity.

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

37

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)

38

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.

39

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.

40

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.

41

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

42

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 processing Time [ms]

9287.2 3868.4 1516.5

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 attack

Plaintext : {ID: 0001, humidity: 13} 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.

43

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.

44

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.

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:

0

20

40

60

80

100

120

0 2 4 6 8 10 12 14 16 18

T (

da

ys)

f (Valid join requests/day)

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

45

• 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 %&'&() * %+&',-.

%&'&() – 0 to get a DevNonce that

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.

47

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.

48

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:

49

• 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.

Furthermore, in term of probability, there is always a probability of 1

%23245 to get

the correct DevNonce, instead of %&'&() * %+&',-.

%&'&() – 0 with Ntotal the number of

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

50

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.

51

• 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.

52

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

53

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.

54

• 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.

55

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

56

• 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

57

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.

59

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.

60

[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.

61

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

Key management with a trusted third party using …...i DEGREE PROJECT, IN PROGRAMME, SECOND LEVEL...

Documents

Transcript of Key management with a trusted third party using …...i DEGREE PROJECT, IN PROGRAMME, SECOND LEVEL...