DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018

Security analysis for MQTT in of Things

DIEGO SALAS UGALDE

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Security analysis for MQTT in

DIEGO SALAS UGALDE

Master in Network Services and Systems Date: November 22, 2018 Supervisor: Johan Gustafsson (Zyax AB) Examiner: Panos Papadimitratos (KTH) Swedish title: Säkerhet analys för MQTT i IoT School of Electrical Engineering and Computer Science

iii

Abstract

Internet of Things, i.e. IoT, has become a very trending topic in re- search and has been investigated in recent years. There can be several different scenarios and implementations where IoT is involved. Each of them has its requirements. In these type IoT networks new com- munication protocols which are meant to be lightweight are included such as MQTT. In this thesis there are two aspects which are under study: secu- rity and achieving a lightweight communication. We want to propose a secure and lightweight solution in an IoT scenario using MQTT as the . We perform different experiments with different implementations over MQTT which we evaluate, compare and analyze. The results obtained help to answer our research questions and show that the proposed solution fulfills the goals we proposed in the beginning of this work. iv

Sammanfattning

"Internet of Things", dvs IoT, har blivit ett mycket trenderande ämne inom forskning och har undersökts de senaste åren. Det kan finnas flera olika scenarier och implementeringar där IoT är involverad. Var och en av dem har sina krav. I dessa typer av IoT-nätverk ingår nya kommunikationsprotokoll som är lightweight, såsom MQTT. I detta arbete finns två viktiga aspekter som studeras: säkerhet och uppnå en lightweight kommunikation. Vi vill föreslå en säker och light weight lösning i ett IoT-scenario med MQTT som kommunikations- protokoll. Vi utför olika experiment med olika implementeringar över MQTT som vi utvärderar, jämför och analyserar. De erhållna resultaten bidrar till att svara på våra forskningsfrågor och visar att den föreslagna lösningen uppfyller de mål vi föreslog i början av detta arbete. Contents

1 Introduction 1 1.1 Context and motivation ...... 1 1.2 Problem Statement and Research Question ...... 2 1.3 Approach ...... 3 1.4 Main contributions ...... 4 1.5 Structure ...... 4

2 Background 6 2.1 MQTT ...... 6 2.1.1 The protocol ...... 6 2.1.2 MQTT broker ...... 8 2.1.3 Topics ...... 8 2.1.4 ...... 9 2.1.5 Session and Messages ...... 12 2.2 Security in MQTT ...... 14 2.2.1 Security breaches and attacks against MQTT . . . 14 2.2.2 Security possibilities in MQTT ...... 15 2.3 ...... 17 2.3.1 Asymmetric key ...... 17 2.3.2 Symmetric key ...... 18 2.3.3 AES modes ...... 19 2.3.4 TLS/SSL ...... 24 2.4 Related work ...... 25 2.5 Aim of the thesis ...... 28

3 Methodology 29 3.1 Research ...... 29 3.2 Action Research ...... 29 3.3 Data collection ...... 30

v vi CONTENTS

3.4 Data analysis ...... 30

4 Implementation 31 4.1 Hardware ...... 31 4.2 Software ...... 31

5 Solution Architecture 33 5.1 Design Overview ...... 33

6 Results 38 6.1 Bandwidth Overhead ...... 38

7 Evaluation 45 7.1 Research questions ...... 45 7.2 Limitations ...... 47

8 Conclusion and Future Work 48 8.1 Conclusion ...... 48 8.2 Future Work ...... 50

Bibliography 51 List of Figures

2.1 MQTT in the TCP/IP stack. Based on [5]...... 7 2.2 Basic architecture of MQTT. Based on [5]...... 7 2.3 Basic architecture of MQTT. Based on [7]...... 8 2.4 QoS 0 of MQTT. Based on [8] ...... 10 2.5 QoS 1 of MQTT. Based on [8] ...... 11 2.6 QoS 2 of MQTT. Based on [8] ...... 11 2.7 MQTT packet format. Based on [9]...... 12 2.8 MQTT connect message. Based on [9]...... 13 2.9 MQTT Publish message. Based on [9]...... 13 2.10 Comparison between ECC and RSA key sizes. Based on [12]...... 18 2.11 AES-GCM encryption mode. Based on the one present in the work [16] ...... 22 2.12 Previous research work in MQTT and security ...... 27

5.1 Built Scenario ...... 34

6.1 Size in bytes of the MQTT connect packet ...... 39 6.2 Size of the packets experiments 2 and 3 ...... 40 6.3 MQTT publish packet in experiments 1 and 4 ...... 41 6.4 Bytes in the communication link for all the options studied 41 6.5 Bandwidth overhead with the different security alterna- tives ...... 42 6.6 MQTT overhead over the rest of the data in the MQTT publish ...... 43 6.7 MQTT protocol overhead MQTT publish ...... 44 6.8 MQTT protocol overhead MQTT publish ...... 44

vii

Chapter 1

Introduction

1.1 Context and motivation

The rapid research advancement in the field of networking has brought a new type of networks, the so-called Internet of Things namely IoT. This is a topic which is undoubtedly very trending in networking nowa- days and lots of research has been done [1]. IoT which is also called inter-machine communication over the internet or communication , i.e. M2M, is a concept that implies the ability of phys- ical devices measuring and sensing data from the real world for then sending that data over the Internet.

A couple of years ago, a new concept emerged taking two different networking technologies, namely, Cloud computing and Internet of Things. This is what we know as CloudIoT these days. Cloud comput- ing means that the group of networked elements providing services can be thought to be in a cloud and not in the end-users [2].

IoT typically involves the use of constrained devices which have not the same resources as the equipment in traditional networks.

A huge variety of protocols have been implemented and are already standardized in the Internet of Things. Two examples of them are MQTT, i.e. Message Queuing Telemetry Transport and CoAP i.e. Con-

1 2 CHAPTER 1. INTRODUCTION

strained Application Protocol. As it has been previously studied these IoT protocols are suitable depending the context and the specific re- quirements needed being each of them the best option depending on the scenario wanted [3]. These IoT protocols are meant to be lightweight since devices such as a watch or a sensor measuring temperature would not be able to handle heavy communications.

In this thesis, we have chosen to use MQTT as the IoT communication protocol because of four main reasons:

• It was designed specifically for constrained devices such as sen- sors • Its publish/subscribe pattern • It has extremely small overhead for message transmission • It provides Quality of Service, i.e. QoS

MQTT operates on top of TCP and was not designed with security in mind but wanting to achieve a very simple and light protocol to mini- mize bandwidth and energy usage. Thus, security in MQTT is a major problem in terms of authentication, authorization, confidentiality and integrity. Regarding the lack of confidentiality present in MQTT we can say that packets in MQTT can be spied by an attacker because no encryption is applied. Thus a secure mechanism is needed over the transport protocol,such as TLS [4]. Some works have been done in this area and more research is ongoing to achieve a secure communication using TLS/SSL on top of MQTT or adding extra layers of security.

1.2 Problem Statement and Research Ques- tion

This dissertation was carried out at Zyax AB, a startup company, in Stockholm. They expressed the need of a solution to provide a secure communication between a blasting sensor and the cloud.

The research questions in this work are the following: CHAPTER 1. INTRODUCTION 3

• Are traditional security protocols a good alternative to use over the MQTT protocol to provide a secure communication between a sensor and the cloud? Why or why not?

• Is payload encryption in MQTT enough to provide a secure com- munication between a blasting sensor and the cloud?

1.3 Approach

Motivated by the above, the aim of this work is to provide a secure IoT system in which a constrained device sends data to a cloud using MQTT as the IoT protocol for communication. The main problem is that this has to be achieved in the most lightweight manner, i.e. a relatively small overhead. Thus, how the establishment of a secure IoT system between an IoT device and the cloud using MQTT as the IoT protocol is the main purpose of this work.

Different alternatives in MQTT are evaluated to provide such a system. Thus a security framework for MQTT in IoT is explained in detailed in the following chapters. When we mention secure system we are referring to avoid different types of attacks to the MQTT broker as it is described in Chapter 2. The main goals of the thesis are detailed here:

• Provide a secure system between the blasting sensor and the cloud using MQTT as the IoT protocol.

• Low overhead in the communication, i.e. lightweight communi- cation, between the IoT device and the cloud. 4 CHAPTER 1. INTRODUCTION

1.4 Main contributions

As mentioned above, in this work we propose a solution to provide a secure communication using MQTT protocol between a sensor and the cloud.

In this work a secure architecture using MQTT as the IoT protocol with AES-GCM payload encryption has been provided. This solution has been compared along with other implementations over MQTT which will be further explained in chapter 4. With these different implemen- tations and experiments we have done a bandwidth overhead compar- ison and MQTT protocol overhead comparison. The use of non-secure MQTT, MQTT over TLS with RSA certificates and ECC certificates and our proposed solution, MQTT with AES-GCM encryption are studied in this thesis.

1.5 Structure

This thesis is organized in seven different chapters.

• Chapter 2 is a background of the different contents the readers should know is introduced and explained as well as previous work and a restatement of the aim of this thesis.

• In chapter 3, we present the methodology followed in this thesis work.

• In chapter 4 the solution architecture proposed is explained in detail including the different phases of work done during this thesis.

• Chapter 5 talks about the hardware and software used in the im- plementation.

• Chapter 6, the results obtained are given.

• Chapter 7 consists in an evaluation of the results obtained. CHAPTER 1. INTRODUCTION 5

• Chapter 8 provides a conclusion of the work and future direc- tions of work that could be taken for this master thesis. Chapter 2

Background

In this chapter, we describe the topics that provide necessary back- ground knowledge on the various concepts associated with security in MQTT and the concepts under study in this work. We also discuss the related research work which has been done in this area of study.

2.1 MQTT

This section presents the MQTT protocol which is the IoT communica- tion protocol decided to use in our solution.

2.1.1 The protocol

MQTT or Message Queuing Telemetry Transport, was invented by Dr Andy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eu- rotech), in 1999 and now it is an . Since then it has become one of the standard protocols in the Internet of Things and it is widely adopted by a variety of industries. As mentioned previ- ously, this IoT protocol was designed specifically for constrained de- vices such as sensors. Therefore, MQTT has extremely small footprint and minimal bandwidth, which makes it very convenient for IoT ap- plications.

6 CHAPTER 2. BACKGROUND 7

Figure 2.1: MQTT in the TCP/IP stack. Based on [5].

MQTT is a publish-subscribe based messaging protocol, very simple and lightweight. It is an protocol that works on top of the TCP/IP stack, as it is shown in figure 2.1. The main ideas of its design are to reduce the network bandwidth as well as device resource requirements, attempting at the same time to provide reliability and some level of delivery guarantee [6].

Figure 2.2: Basic architecture of MQTT. Based on [5].

MQTT has a client server model where every IoT device is a client which connects to a server,i.e. the MQTT broker. A client, i.e IoT de- 8 CHAPTER 2. BACKGROUND

vice, will connect to the broker and publish data to a topic. A sub- scriber will receive the message published by a client if it is subscribed to that topic. This will be further explained in section 2.1.5. A simple example of this architecture can be seen in figure 2.2. In that figure, two clients, i.e. Laptop and Mobile Device, are subscribed to different topics. A client, i.e. IoT device, is publishing the message "Hi" to the topic "Message". The broker will be the responsible to send the mes- sage "Hi" to the subscriber which is subscribed to the topic "Message".

2.1.2 MQTT broker

The MQTT broker can be seen thus as the server. This server, manages all messages being published from the clients. In other words, it is the responsible to deliver messages to the subscribers [6]. The broker in MQTT is therefore a key element for this messaging protocol to work.

2.1.3 Topics

A topic is an UTF-8 string which is used by the broker to handle mes- sages for each device connection. They normally consist of different levels separated by a slash. This hierarchy-like structure is represented in figure 2.3.

Figure 2.3: Basic architecture of MQTT. Based on [7]. CHAPTER 2. BACKGROUND 9

Topics are not permanent and are created by the clients or subscribers. A topic only exists if a subscriber has subscribed to it or the broker has a retained or last will messages stored for that topic. This will be explained further in the following section 2.1.4. When creating a new topic, a client is practically free in choosing that name although there are some exceptions as explained in the following section.

Special Topics

There is one special topic in MQTT called $SYS topic. This is created by default by the MQTT broker and it is a reserved topic used by most of the MQTT brokers to provide information about the broker. These are read-only topics for the MQTT clients [7]. This is why when creating a topic, if it starts with a $ symbol it will be treated specially.

Wildcards

As it has been mentioned above, a device can subscribe to one or mul- tiple topics. There is a special topic called wildcard represented by # or by +. The first symbol means a multi level wildcard and the latter a single level wildcard. This can be easily understood with the following example:

• /blastingsensor/iot1/#/ • /blastingsensor/+/movement

In the first case, all the features from the iot1 would be given whereas in the second case only the feature movement would be given but from every single device, i.e. iotx. It needs to be mentioned that wildcard is only possible for subscriptions and not in the publish from a client.

2.1.4 Quality of Service

Quality of Service is a common concept in networking which talks about the delivery of messages implying an agreement that has to be 10 CHAPTER 2. BACKGROUND

made between the sender and the receiver. MQTT supports three dif- ferent quality of service levels [8]. These are the following:

• 0. At most once delivery also called "fire and forget".

• 1. At least once delivery also called "acknowledged delivery".

• 2. Exactly once delivery also called "assured delivery".

The flow diagrams of these different possibilities of quality of service can be seen figure 2.4, figure 2.5 and 2.6 respectively.

Figure 2.4: QoS 0 of MQTT. Based on [8]

QoS 0 or ’at most once’ means that the client publishing, e.g. IoT de- vice, will send a message to the broker and it will delete it afterwards. No acknowledgement will be returned to the client meaning that this entity will not know if the message arrived to the broker. This quality of service level provides the same guarantee as the TCP protocol does. The flow architecture of this quality of service can be seen in 2.4.

QoS 1 or ’at least once’ means that the client after having sent or pub- lished to a topic, it will store the message just published and will keep waiting for an acknowledgement from the MQTT broker. If this does not happen after an interval of time the client will retry to publish the message again. When it receives the ack, i.e. acknowledgement, it will delete the message. So, in other words, there is a guarantee that CHAPTER 2. BACKGROUND 11

Figure 2.5: QoS 1 of MQTT. Based on [8]

Figure 2.6: QoS 2 of MQTT. Based on [8] 12 CHAPTER 2. BACKGROUND

the message will be delivered to the receiver at least once. The flow architecture of this quality of service can be seen in 2.5.

QoS 2 or ’exactly once’ means that the client will store the message to then publish it to the broker. This will also store it until a subscriber to that topic connects. After having published the message, the broker will send to the client a Publish received message, or PUBREC. The client will then reply with a published release, i.e. PUBREL. The bro- ker will then delete the message previously stored and send a Publish complete, PUBCOMP, to the client for it to know that the message has arrived and can be deleted. It is the slowest quality of service level that MQTT provides. The flow architecture of this quality of service can be seen in 2.6.

A last and very important thing that should be pointed out, is that the QoS is strictly selected between client and broker. This means that a client publishing to a broker could have selected a different QoS than the the client subscribing to that topic and the broker.

2.1.5 Session and Messages

In this subsection specific characteristics of the Message format and session will be covered [9].

The format of an MQTT packet can be seen in figure 2.7.

Figure 2.7: MQTT packet format. Based on [9].

When a client connects to a broker, it needs to subscribe to one or several topics in order to receive messages. An important aspect that needs to be reminded is that the client publishing and the client which CHAPTER 2. BACKGROUND 13

subscribes do not need to be connected at the same time. Messages can be stored or better said, retained, in the broker. This is because of the so-called "Retained messages". When a client publishes a message to a topic different types of flags and options can also be sent along with as it can be seen in figure 2.7. A very important one is called ’Retain’ which is the last bit of the first byte of the message. If that bit is set to ’1’ the message published by the client will be kept in the broker until a new one is sent.

Figure 2.8: MQTT connect message. Based on [9].

This means that whenever a subscriber connects, it will receive the last message that was published to the topic.

Figure 2.9: MQTT Publish message. Based on [9]. 14 CHAPTER 2. BACKGROUND

2.2 Security in MQTT

In this section, MQTT security aspects will be explained. These are the security problems in MQTT and the different possibilities that can be implemented on top of this protocol.

2.2.1 Security breaches and attacks against MQTT

In this section different security breaches and attacks against MQTT as it was designed, i.e. MQTT over TCP, are explained [10].

Subscriber to all topics

An attacker can subscribe to the wildcard topic explained in previous sections, i.e. #. This would allow the attacker to be subscribed to all topics and that way see all topics and data. It breaks against confiden- tiality.

Publish unauthorized data to the broker

If the broker does not have any type of authentication mechanism, ev- ery device, including an attacker, is able to publish data to the broker and thus perform a denial of service attack to the MQTT broker.The aim is these types of denial of service, i.e. DoS attacks is to exhaust resources of the server, in this case, the MQTT broker.

Privacy of data

MQTT data is not encrypted so it is indeed an issue in many different scenarios. It does not matter if the broker uses authentication mech- anism or not because the data in transit can easily be sniffed by an attacker. This issue is again a confidentiality one meaning that data can be seen by anyone with basic networking skills. CHAPTER 2. BACKGROUND 15

Authentication

As stated in the previous section, MQTT offers some security features in the application layer. If the broker for instance uses client authenti- cation mechanism by only allowing users by username and password the attacker would be blocked in any chance of publishing unautho- rized data. This is by supposing that the attacker does not know nei- ther the username nor the password to connect to the broker.

However username and password are sent in plaintext in MQTT in the CONNECT command. The same problem arises here, an attacker can sniff the data and take those credentials and use them against the broker to publish data or receive it.

Data Integrity

It is clear now that an attacker can sniff the data without too much trouble. It does not really matter that username and password are used as an authorization mechanism to connect to the MQTT broker. A big- ger problem comes here regarding data integrity. An attacker, having eavesdropped the conversation can capture the packets and modify them to later send them to the MQTT broker. This may cause a seri- ous problem to different IoT devices that are subscribed to those topics where the message is being altered. Behavior of those IoT devices can be changed due to those modified messages.

Having stated different types of attacks and breaches regarding secu- rity in MQTT some security possibilities to implemented are going to be explained here.

2.2.2 Security possibilities in MQTT

As already implied, the MQTT protocol itself was not designed with security in mind. MQTT is a really lightweight and very simple com- munication protocol and it only has a few security mechanisms spec- ified in it. Besides and as we mentioned before, MQTT relies on TCP as its transport protocol so no encrypted communication is used. 16 CHAPTER 2. BACKGROUND

In each layer of the TCP/IP protocol stack, resistance against different types of attacks can be provided.

Network Level

In the network level a secure solution would be to use payload en- cryption to make the published information be encrypted even if no transport encryption is used.

Transport Level

TLS/SSL protocol is known to be used nowadays in many different types of networks and over lots of different protocols. TLS protocols aims to provide not only privacy in the communication but data in- tegrity between the parties communicating. In MQTT port 8883 is standardized for MQTT over TLS/SSL. This implementation is strongly recommended by the OASIS standard [11]. Port 1883 is registered in IANA for non TLS-connection, i.e. unencrypted TCP.

Application Level

It is in this level where MQTT security properties are optional to be implemented. In the MQTT connect packet shown in 2.8 there are two optional fields that can be used for MQTT client authentication to the broker. Those fields can be seen in figure 2.8 which are part of the optional payload in the MQTT CONNECT packet. These fields are:

• A client identifier

• Username and password credentials

Apart from all the explained above, some additional security imple- mentations can be applied on the MQTT broker depending on the technology used to implement that. One of this implementations is regarding access control. CHAPTER 2. BACKGROUND 17

This access control to the broker is based on some lists called Access Control List, i.e. ACL, which basically allow the connection to the bro- ker from specific clients or even can specify restrictions to some topics.

2.3 Cryptography

Cryptography is thus a major aspect to consider to improve the secu- rity in applications which implement MQTT as protocol. In this sec- tion, different aspects of cryptography are explained.

Modern cryptography can be divided into two big fields: Symmetric- key cryptography and Asymmetric key cryptography.

2.3.1 Asymmetric key

In 1976, Whitfield Diffie and Martin Hellman proposed this notion of public-key cryptography where two different but mathematically re- lated keys are used. In these cryptography systems sender and re- ceiver use different keys. Each of them have a pair of keys namely a private key and a public key. The public key is as its name suggests public so it is freely distributed while the private has to be kept as a secret.Public key cryptography is a costly operation and that is why it is known to be slower than symmetric key cryptography.

The concept added in this public key cryptography is that every entity can be said to have its own identity and two different keys.

RSA

RSA, i.e. Rivest-Shamir-Adleman is a cryptographic algorithm, one of the first asymmetric key . In this algorithm, two large primer numbers are needed to be computed to later save that compu- tation as a secret key. RSA is embedded in the TLS/SSL protocol which is used to establish secure communication. 18 CHAPTER 2. BACKGROUND

The sender can encrypt a message with the receiver’s public key and the receiver will then decrypt it with the private key.

ECC

Elliptic-curve cryptography, i.e. ECC, is a newer asymmetric algo- rithm which uses elliptic curves over finite fields. It is one of the solu- tions which is said to be able to replace RSA.

Figure 2.10: Comparison between ECC and RSA key sizes. Based on [12].

Previous research have studied the behavior and have made a compar- ison between RSA and ECC showing that Elliptic-curve cryptography is much faster than RSA and it requires thus less computational power. This is mainly because the smaller key-sizes needed in ECC to achieve similar level of security than in RSA. This can be seen in table 2.10.

2.3.2 Symmetric key

This kind of encryption was the only known until June 1976 when a new type of encryption was released as it will be explained in the fol- lowing section. Cryptosystems which use symmetric key refer to those encryption methods in which the same key is shared between both the sender and the receiver. That is why it is also called secret-key cryp- tosystems. These keys are normally distributed between the parties using a .

Symmetric key ciphers are implemented as either block ciphers or stream ciphers. There are several examples of symmetric key cryp- tographic algorithms such as Data Encryption Standard, i.e. DES, Ad- CHAPTER 2. BACKGROUND 19

vanced Encryption Standard, i.e. AES or Blowfish. It needs to be men- tioned that symmetric cryptosystems are known to be faster in com- putation time than the asymmetric ones that will be explained in the following section.

Stream Ciphers

Stream ciphers are symmetric key ciphers in which a pseudorandom cipher digit stream is combined with plaintext digits. They work with a time-varying transformation on individual plaintext digits. This is, plaintext digits are encrypted one at a time with the keystream to then give a digit of the stream. The encryption is then dependent on the current state of the cipher, so this stream ciphers are also known as state ciphers.

Block Ciphers

Block ciphers are used to encrypt or decrypt data that are operated on units of bits called blocks. Examples of are DES, AES or Blowfish. AES will be explained later since it is a block cipher con- sidered under this work. These block cipher have several operational modes since everything depends on how the block input and output are chained with the following ones.

2.3.3 AES encryption modes

This block cipher, i.e. AES, has several different operation modes as it was explained above that block ciphers do. In this section of the report two of the encryption modes of AES will be explained, the ones used in this work.

Advanced Encryption Standard, i.e. AES is a block cipher developed by Joan Daemen and Vincent Rijmen. AES can work with diffent key sizes, i.e. 128-bit, 256-bit and 512-bit, and it has from 10 to 14 rounds of simple block ciphers. This block cipher is successful due to its sim- plicity in design. 20 CHAPTER 2. BACKGROUND

AES-CTR

Counter Mode is a popular symmetric encryption algorithm. It turns a block cipher into a . The next keystream is generated by encrypting successive values of a ’counter’. This mode was also intro- duced in at the same time as public key encryption, 1979 by Whitfield Diffie and Martin Hellman. This encryption mode is shown in figure

AES-GCM

Galois Counter Mode, i.e. GCM, is a mode of operation for symmetric key cryptographic block ciphers [13]. GCM is a mode of operation of the AES algorithm [14]. This mode, is convenient to protect packets of data since it has low latency and a minimum operation overhead. It is known and widely adopted due to its efficiency and performance. It provides assurance of the confidentiality of data by using a variation of the AES-CTR mode for encryption. It is an authentication encryption mode which achieves this due to the universal hash function provided. In other words, it provides both data authenticity, i.e. integrity, and confidentiality.

Security in AES-GCM

AES-GCM encryption mode, has been proven to be secure when it is used with a block cipher that it is not just a random permutation. Ga- lois Counter mode (GCM) is used in different cipher suites in TLS [13] as the encryption algorithm and that is the main reason why we de- cided to evaluate it with MQTT in this thesis. The most important aspect to ensure security with AES-GCM is choosing a unique initial- ization vector for every encryption which is performed with the same key. GCM is a useful secure mode to communicate in a secure manner with small embedded devices [15].

As mentioned previously, the initialization vector, i.e. IV, is one of the most important aspect to take care of in this encryption mode. AES- GCM is used for authenticated encryption with associated data. GCM provides confidentiality and authenticity for the encrypted data and CHAPTER 2. BACKGROUND 21

authenticity for the additional authenticated data (AAD). The AAD is not encrypted. GCM mode requires that the IV is a nonce, i.e., the IV must be unique for each execution of the if the same key is used [16].

The steps for GCM encryption can be seen in figure 2.11. Those are the following:

1. The hash subkey for the GHASH function is generated by apply- ing the block cipher to the “zero" block.

2. The pre-counter block called J0 is generated from the IV. In par- ticular, when the length of the IV is 96 bits, then the padding string 031||1 is appended to the IV to form the pre-counter block. Otherwise, the IV is padded with the minimum number of ‘0’ bits, possibly none, so that the length of the resulting string is a multiple of 128 bits (the block size); this string in turn is ap- pended with 64 additional ‘0’ bits, followed by the 64-bit rep- resentation of the length of the IV, and the GHASH function is applied to the resulting string to form the pre-counter block.

3. The 32-bit incrementing function is applied to the pre-counter block to produce the initial counter block for an invocation of the GCTR function on the plaintext. The output of this invocation of the GCTR function is the ciphertext.

4. The AAD and the ciphertext are each appended with the mini- mum number of null bits, possibly none, so that the bit lengths of the resulting strings are multiples of the block size. The con- catenation of these strings is appended with the 64-bit represen- tations of the lengths of the AAD and the ciphertext to produce block u.

5. The GHASH function is applied to block u to produce a single output block.

6. This output block is encrypted using the GCTR function with the pre-counter block that was generated in Step 2, and the result is truncated to the specified tag length to form the authentication tag. 22 CHAPTER 2. BACKGROUND

Figure 2.11: AES-GCM encryption mode. Based on the one present in the work [16] CHAPTER 2. BACKGROUND 23

AES-GCM has then four inputs: an AES key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). In this work we did not use the optional additional authenti- cated data so we had three inputs.

The outputs of the encryption are the following:

• The ciphertext which length is the same as the plaintext length

• An Authentication Tag which length can vary from 0 bits to 128 bits. In this thesis the size of this tag is 128 bits, i.e. 16 bytes.

During the decryption, the tag is an input parameter. The ICSF, i.e. integrated cryptographic service facility, calculates a tag following the same process as in the encryption and the compare those tags. If they match, the decryption will proceed since it has been proven that data has not been tampered with.

As it can be seen in figure 2.11, GCM combines the ciphertext with an authentication code in order to produce an authentication tag that can be used to verify the integrity of the data. The encrypted text then contains the IV, i.e. initialization vector, cipher text, and authentica- tion code. This can be said to have a similar security properties to an HMAC. 24 CHAPTER 2. BACKGROUND

2.3.4 TLS/SSL

Transport Layer Security and its predecessor, Secure Sockets Layer, i.e. TLS/SSL are application layer secure protocols which aim to provide secure communication over the Internet, mainly privacy and data in- tegrity.

TLS/SSL relies on digital certificates to be able to certify the ownership of a public key by an entity, which has to be specified on the subject of the certificate. These certificates are issued by the so-called Certificate authorities. The whole system is called public key infrastructure. The public keys need to be binded to the identity of the entities and this is able to be done thanks to PKI, i.e. public key infrastructure.

Cipher suites

They are a set of algorithms used in TSL or SSL to secure a network connection. Every cipher suites contains a set of algorithms, these are:

• algorithm.

• Bulk encryption algorithm.

• code, i.e. MAC algorithm.

The key exchange algorithm is used to exchange a key between two parties, a key which will later be used to encrypt and decrypt the mes- sages with. The bulk encryption algorithm is used to encrypt the data that is going to be sent. And the message authentication code or MAC algorithm provides data integrity checks to be able to ensure that data has not been changed in the way to the receiver.

Forward Secrecy

Forward secrecy is a property that some cryptographic systems, e.g. cipher suites, may have and which ensures that a session key derived CHAPTER 2. BACKGROUND 25

from a set of public and private keys is not going to be compromised if one of the private keys is compromised in the future. The lack of forward secrecy could be fatal to a system since past sessions could also be decrypted.

2.4 Related work

In this thesis we focus on MQTT and the possibilities to implement a secure system with this protocol. MQTT was chosen because of the reasons explained in 1.4.

Nevertheless, several works have proposed solutions with different IoT protocols. Ammar et al. recently published their work in which the provided a survey on the security of IoT frameworks [17].

Other work by Fysarakis et al. provided a survey explaining the pros and cons of the different IoT Protocols today [3] .

In 2015 Thatmann et al. focused on encryption for securing MQTT [18]. In their work they studied Atribute-based Encryption on publish subscribe messaging patterns for the IoT, as MQTT. They contributed with a new approach on how to apply ABE in combination with MQTT and compare it with different models previously studied.

In 2017, Almuhammadi et al. published their work in which they per- formed a comparative analysis of AES common modes of operation [19]. This comparison was done in terms of encryption time, decryp- tion time and throughput with variable data packet sizes. They con- cluded that ECB mode is the fastest among the other modes of opera- tion.

Later Shin et al. proposed a security framework for MQTT [20]. Their motivation and main goal was to provide MQTT with security and argued that the solution recommended of MQTT using SSL/TLS add significant communication and computation overhead due to the cer- tificates. They proposed a simple security framework for MQTT, i.e. AugMQTT, with which no certificate validation checks or certificate revocation checks are needed. 26 CHAPTER 2. BACKGROUND

Niruntasukrat et al. suggested in their work that there is a need for the implementation of a mechanism on top of MQTT authentication to be able to provide federated identity management and fine-grained device access control. Thus, they presented the design and implemen- tation of an authorization mechanism based on the OAuth framework [21].

In 2017 Mathur et al. studied a secure end-to-end IoT solution which was proven to protect against several attacks like data breach, Denial of Service, i.e. DoS, and unauthorized access [22].

Andy et al. provided a discussion of why in some IoT systems secu- rity is not implemented. They also performed an analysis of different scenarios in which MQTT could be attacked [10].

As mentioned before, in some work MQTT is not chosen as the com- munication protocol. An example the work of S. Raza et al. They pro- vided an end-to-end secure communication architecture for the cloud- connected Internet of Things [23] using CoAP over DTLS.

Later a lightweight authentication mechanism for M2M communica- tions in Industrial IoT environment was provided by Esfahani et al. Their proposal is a lightweight authentication mechanism based only on hash and XOR operations [24]

Later, Forbsy et.al studied a lightweight version of the X.509 certifi- cate for IoT. In their study they were able to provide compression and encoding schemes for their profiled certificate. An important fea- ture is the compatibility with the X.509 standard, meaning that their lightweight certificate could be used in any existing PKI solutions [25].

Bhawiyuga et al. proposed an architectural design of token-based au- thentication of MQTT protocol in constrained IoT devices [26]. They porposed a JSON Web token based authentication for MQTT Proto- col. Recently a new paper was proposed by Katsikeas et al. [27]. In their work they highlighted the suitable properties of MQTT as a lightweight protocol and its suitability for industrial purposes. They evaluated different security options for MQTT nodes, namely payload encryption with AES, payload encryption with AES-CBC, payload au- thenticated encryption with AES-OCB and encryption with CHAPTER 2. BACKGROUND 27

Figure 2.12: Previous research work in MQTT and security 28 CHAPTER 2. BACKGROUND

AES-CCM. They concluded in their evaluation that all the options are attractive depending on the purpose.

A very recent paper by Hernandez et al. investigated a new frame- work for MQTT which they call a novel fuzzing approach. They claim that their framework improves security of applications which imple- ment MQTT. In other words, they designed a tool which perform se- curity tests on MQTT [28]

These research is summarized in table 2.12 where also the main con- tribution of these works are stated.

2.5 Aim of the thesis

After having explained the background knowledge and related work it is mandatory to remind the goals of this thesis.

The first goal is to provide a secure system between the blasting sen- sor and the cloud using MQTT as the IoT protocol. The second one is to achieve low overhead in the communication link between the blast- ing sensor and the MQTT broker which is the first entity in the cloud receiving packets from the IoT device.

This second goal goes in relation with the first one. It is key to find the compromise between the two aspects to evaluate the possible so- lutions under study. Chapter 3

Methodology

The work of this project can be divided in several parts which are re- search, action research, data collection and data analysis .

3.1 Research

As mentioned before this work was conducted at Zyax AB. During the first phase of the thesis research was conducted. As stated above in section 1.3 the project wanted to be done was to provide a solution which would satisfy a secure and lightweight communication between sensors and the cloud. Therefore research in the different types of IoT protocols was done. Finally and due to the reasons explained in chap- ter 1, MQTT was selected.

3.2 Action Research

After having decided MQTT as the IoT protocol for the solution of this work the two key aspects of this thesis came in to place, i.e. security and lightweight communication. Research was done in this area to an- alyze and evaluate the related work which had been done in MQTT re- garding security. As stated before MQTT is a very lightweight protocol

29 30 CHAPTER 3. METHODOLOGY

and one of the aims of this thesis is to keep it as lightweight as possible but providing at the same time a secure communication between the sensor and the cloud using MQTT but not adding much more over- head which would make this protocol not as light-weighted. It is here where the research questions also mentioned above in 1.4 first appear.

3.3 Data collection

Several experiments were performed during this thesis work which will be further explained in chapter 5. We build a simple scenario and perform different experiments implementing different alternatives on top of MQTT.

3.4 Data analysis

After having performed the different experiments in this thesis and gathered all the date we are able to draw conclusions and evaluate if our research questions are answered as well as if the goals are met. Chapter 4

Implementation

In this chapter the software and hardware used for the implementation of our system is explained. Firstly it needs to be said that the architec- ture and the implementation have been done in the same Local Area Network, i.e. LAN.

4.1 Hardware

Regardless the phase of work, same equipment was used. A Raspberry Pi Zero was used to act as the IoT device. The rest of the systems presented in the architecture shown in figure 5.1 are virtual machines developed in Virtual Box [29]. A mobile phone was used to act as the device used connecting to the webpage where the data sent from the IoT device was originally stored.

4.2 Software

Regarding the software different systems were used.

• Node.js. This programming language was used in the IoT de- vice, the Middleware, the database and in the webserver. It is

31 32 CHAPTER 4. IMPLEMENTATION

thus the main programming language used in this thesis. It is a JavaScript runtime, event-driven and non-blocking I/o model. It was selected mainly because these features mentioned make Node.js lightweight and efficient [30]. Node.js has a module for MQTT and also other one for cryptography which were the ones mainly used in our code.

• Express.js was used in conjunction with Node.js to create the webserver [31].

• MongoDB was used as the database. Mainly because it is a NoSQL database meaning among other things that the storage and re- trieval of data is modeled in means and not in tabular relations [32].

• OpenSSL is used to create certificates and keys for the TLS im- plementation [33].

• Mosquitto. This open source was used for the MQTT brokers’ implementation. It is a lightweight and suitable for use on all devices regardless their features [34]. Chapter 5

Solution Architecture

In this chapter the implementation part of this thesis work is pre- sented. This is, the different experiments performed in our work are explained and introduced which correspond to the section data collec- tion introduced in chapter 3.

5.1 Design Overview

The scenario shown in figure 5.1 was built in order to perform our experiments from which we were able to collect all the data needed to draw conclusions. We conducted different experiments which analysis will be explained in chapter 5.

As it seen in picture 5.1 the system proposed in this phase consists of six entities. These are:

IoT device This device is the responsible of sending data to ’the cloud’. When it starts, it subscribes to a topic by sending payload.

MQTT broker Is the key element for this scheme to work. It is responsible entity to route all the messages.

33 34 CHAPTER 5. SOLUTION ARCHITECTURE

Figure 5.1: Built Scenario

Database It is the subscriber to the topic the IoT device is publishing. of IV number to receive that number which this system will need to decrypt and authenticate the data originally sent from the IoT device. The data arrives to this system already encrypted with TLS and using the cipher suite mentioned above since it is the MQTT broker 2 from which this database receives the sensor data from. When this data is decrypted at the database it publishes it to its database.

Webserver It connects to the database and takes all the information to pub- lish it on a website. This connection is done via HTTP since this communication link is not the focus of this thesis.

User It connects to the webserver via HTTP and is able to see all the data which was originally sent from the IoT device. CHAPTER 5. SOLUTION ARCHITECTURE 35

Intermediate and root CA As shown in picture 5.1 an intermediate CA and a root CA were also implemented. These entities were needed for the case were the MQTT broker listen in port 8883.

The different experiments can be summarized as follows:

1. IoT device publishing different amounts of payload using MQTT over TCP

2. IoT device publishing different amounts of payload using MQTT over TLS with RSA key exchange

3. IoT device publishing different amounts of payload using MQTT over TLS with ECC key exchange

4. IoT device publishing different amounts of payload using MQTT with AES-GCM encryption

For experiments number 1 and number 4 we need a common MQTT broker implementation. This is as follows:

• MQTT broker listening in port 1883

And for the experiments where MQTT is over TLS, i.e. experiments 2 and 3, the broker should have the following configuration:

• MQTT broker listening in port 8883, i.e. MQTT over TLS

In experiment 2 the certificate was signed with a RSA 2048 bits key and with a ECC 224 bits in experiment 4. As shown in the background chapter in figure 2.10 this two keys provide the same level of security, but in the case of ECC, overhead is reduced due to the less number of bits needed. For this two experiments, the corresponding certificates were installed in the MQTT broker, the database and the IoT device. 36 CHAPTER 5. SOLUTION ARCHITECTURE

In all of these four experiments two options regarding authorization were used. These are:

1. Adding a username and password in the MQTT connect packet to authorize against the MQTT broker for being able to send data to a topic.

2. No credentials used to connect and thus no authorization as in the previous case.

These fields in the MQTT connect packet namely username and pass- word, provide a way of authorization against the MQTT broker. This is, an IoT device could one publish or subscribe to a topic if it is au- thorized with a username and password to the MQTT broker. As pre- viously mentioned in chapter 2 these fields, username and password, are sent in plaintext.

At last, some specifications and configurations need to be mentioned for experiment 4. As said in section 2.3.3 three inputs were needed for this implementation. These are:

• An AES key

• An initialization vector (IV)

• A plaintext content, which is the payload we send from the IoT device

An important aspect in AES-GCM is that an IV is not used twice with the same key. In out experiment the same key was used but the IV was changed every single time. For implementing that, we used an MQTT topic to which the IoT would be subscribed. The IoT device would receive the IV and then be able to perform the encryption with the cor- responding plaintext an AES key. The same applies for the database which is the subscriber of the topic the IoT device is publishing. This entity needs also to be subscribed to the topic in which the IV is being published. As mentioned before, this is because during the decryp- tion, the tag is an input parameter. The receiver calculates a tag follow- ing the same process as in the encryption and the compare those tags. CHAPTER 5. SOLUTION ARCHITECTURE 37

If they match, the decryption will proceed since it has been proven that data has not been tampered with. Chapter 6

Results

In this chapter the results obtained are displayed and commented. As explained in chapter 5 we have conducted different experiments and gathered the data needed. Having all the data collected we were able to proceed with the corresponding data analysis mentioned in chapter 3.

6.1 Bandwidth Overhead

In this section the bandwidth of the communication link between the IoT device and the first MQTT broker is studied. Different graphs cor- responding to the different experiments are presented.

In the first experiment, the MQTT broker listens in port 1883. In other words, we used MQTT over TCP. As mentioned above we configured two options for this and all the experiments:

1. Adding a username and password in the MQTT connect packet to authorize against the MQTT broker for being able to send data to a topic.

2. No credentials are used to connect and thus no authorization as in the previous case.

38 CHAPTER 6. RESULTS 39

Figure 6.1 show the number of bytes of that packet which sent to the MQTT broker. In this example a username of 5 bytes of length and a password of 9 bytes were used which make a total of 14 bytes..

Figure 6.1: Size in bytes of the MQTT connect packet

As we can see from figure 6.1 there is a difference of 18 bytes. The other 4 bytes are added in the MQTT connect to specify the lenght of the username and password fields.

The number of bytes shown in figure 6.1 is the same in all the exper- iments in the cases where no credentials are used to connect to the MQTT broker, i.e. 95, and the same in the case that credentials are used, i.e. 113.

In experiments 2 and 3 MQTT over TLS was used. In experiment 2 RSA certificates were used and in experiment 3 ECC certificates were used.

Figure 6.2 shows the total size of the packets exchanged between the IoT device and the MQTT broker of these two experiments. The case shown in the graph is the one when the IoT device send a payload of 1 byte in a MQTT topic of 11 bytes of lenght.

When RSA is used , i.e. experiment 2, more bytes are exchanged com- paring to the case of ECC, i.e. experiment 3. This is because of the 40 CHAPTER 6. RESULTS

TLS handshake where certificates are exchanged and are bigger as ex- plained before in chapter 2 than in the case where ECC is used, i.e. experiment 3.

Figure 6.2: Size of the packets experiments 2 and 3

In experiment 4, i.e. MQTT using AES-GCM encryption, the MQTT broker is configured as in experiment 1, listening on port 1883.

The authentication tag size is 128 bits, i.e. 16 bytes. This way when publishing the data in the MQTT publish packet, 16 bytes will be added to the payload sent by the IoT device. This authentication tag can be used to check the integrity of the message. This is done by the database in this work, which is the subscriber to the topic that the IoT device publishes its message to.

In figure 6.3 knowing if the experiment regards to the case where cre- dentials are used or not is not relevant because those credentials are sent only in the MQTT connect packet and not in the MQTT publish which is the one shown in the mentioned figure. We can see that in experiment 4 the MQTT publish packet is 16 bytes bigger than in ex- periment 1.

The size in bytes of the packets exchanged in the communication link between the IoT device and the MQTT broker in all the experiments CHAPTER 6. RESULTS 41

Figure 6.3: MQTT publish packet in experiments 1 and 4

Figure 6.4: Bytes in the communication link for all the options studied 42 CHAPTER 6. RESULTS

are shown in figure 6.4. The data shown in the graph corresponds to the case in which the IoT device publishes 1 byte as payload. It can be seen that the cases where TLS is used represent the cases in which more bytes are exchanged between the IoT device and the MQTT bro- ker. This is mainly because the need of sending the certificate from the broker to the IoT device and the computation of common secret and session keys generation [4].

In the four experiments that we performed, different payloads were published by the IoT device.

Figure 6.5: Bandwidth overhead with the different security alterna- tives

Thus, we sent in all the four experiments these payloads expressed in bytes:

• 1000, 5000, 10000, 20000, 30000

We show in figure 6.5 the overhead expressed in percentage that other data sent in the communication between the IoT device and the MQTT broker imposes over the actual MQTT payload sent by the IoT device. From this figure we can see that it is experiment in which less overhead over the MQTT payload experienced. This is the case where standard MQTT was used, in other words the most lightweight case. We can see that the experiment which best approximates to the overhead values CHAPTER 6. RESULTS 43

of experiment 1 is experiment 4. This is the case where AES-GCM payload encryption is used.

Figure 6.6: MQTT overhead over the rest of the data in the MQTT publish

In the previous figure a graph in which big payload was sent in all of the experiments was shown. In figure 6.6 the case in which small payload are sent from the IoT device can be seen. In this graph the protocol overhead of MQTT in the MQTT publish packet is shown. In other words, the overhead that the protocol MQTT imposes to the rest of the data in the publish packet. A similar conclusion to the one did with previous figure can be drawn here. Data from experiment 4 is more similar to experiment 1, implying that experiment 4 is providing security to MQTT and not adding too much overhead than in the case of standard MQTT.

Just like the previous figure 6.6, figures 6.7 and 6.8 represent the over- head concerned only in the MQTT publish packet itself. In these cases bigger payloads were publish to the MQTT topic from the IoT device. From all these last three we can conclude that:

• If small payloads are wanted to be sent MQTT with AES-GCM encryption seems a better option to guarantee less MQTT over- head over the data in the MQTT publish packet • If big payloads are to be sent every option seems to impose the same overhead 44 CHAPTER 6. RESULTS

Figure 6.7: MQTT protocol overhead MQTT publish

Figure 6.8: MQTT protocol overhead MQTT publish Chapter 7

Evaluation

In this chapter we present an evaluation of the design goals. The pur- pose of this chapter is to evaluate to which extent these design goals are met.

7.1 Research questions

Recalling what was stated in chapter 1 it is needed to see if we have answered the research question.

The aim of this work was to provide a secure IoT system in which a constrained device sends data to a cloud using MQTT as the IoT pro- tocol for communication. The main problem was that this has to be achieved in the most lightweight manner, i.e. a relatively small over- head. Thus, how the establishment of a secure IoT system between an IoT device and the cloud using MQTT as the IoT protocol was the main purpose of this work. Different alternatives in MQTT were evaluated and compared.

The main goals of the thesis are:

• Provide a secure system between the blasting sensor and the cloud using MQTT as the IoT protocol.

45 46 CHAPTER 7. EVALUATION

• Low overhead in the communication, i.e. lightweight communi- cation, between the IoT device and the cloud.

The research questions in this work are the following:

• Are traditional security protocols a good alternative to use over the MQTT protocol to provide a secure communication between a sensor and the cloud? Why or why not? As we can see from our results traditional security protocols the use of them implies more bytes exchanged in the communication link between the IoT device and the cloud. One of our goals in this thesis was to have low overhead in the communication, as the MQTT with no secure implementation guarantees. Taking this into account it could be said that this lightweight communi- cation is not achieved with traditional security protocols as it can be concluded from the data extracted from experiments 2 and 3.

• Is payload encryption in MQTT enough to provide a secure com- munication between a blasting sensor and the cloud? In this thesis we wanted to provide a secure system between the blasting sensor and the cloud using MQTT as the IoT protocol. Applying only payload encryption in MQTT guarantees the con- fidentiality of the data considering that the keys are kept secret. In this work we have proposed AES-GCM payload encryption in MQTT which is an authenticated encryption. This guarantees the integrity of the message. Even if an attack wrote a message to the broker, this would be accepted but later rejected because the party receiving the message would know it is not authenticated. CHAPTER 7. EVALUATION 47

7.2 Limitations

In this section some limitations need to be pointed out.

In this thesis Authorization is not considered. The proposed solution for securing AES-GCM is an authorized which guaran- tees data integrity and confidentiality. This means that basically every entity would be able to publish messages to the MQTT broker if no credentials are asked by the MQTT broker in the MQTT connect.

This system presented in this thesis answers to the need of having a secure system in IoT using a very lightweight protocol such as MQTT adding small overhead to it. Chapter 8

Conclusion and Future Work

This chapter presents an overview of the work done during this thesis, highlights the contributions and also gives possible directions for the continuation of the work produced.

8.1 Conclusion

The aim of this thesis was to build a secure system architecture be- tween a blasting sensor and the cloud. After having done research we concluded that MQTT was the best option to have as the IoT proto- col. The other goal to keep the lightweight communication which is achieved with the MQTT protocol itself.

We performed different experiments to analyze different options to be implemented and would make the communication between the IoT device and the cloud secure but also lightweight. The results show that TLS although being a good secure option implies the exchange of much more number of bytes that in the case when payload encryption is used. In this thesis AES-GCM encryption is proposed to be a good solution. As it is shown in chapter 6 this is the case where the number of bytes exchanged in the communication link is more similar to the case where standard MQTT, i.e. MQTT over TCP, is used.

48 CHAPTER 8. CONCLUSION AND FUTURE WORK 49

We consider thus that the case where AES-GCM is used as MQTT pay- load encryption finds the right balance between the lightweight aspect and the secure aspect in which this solution guarantees data authen- ticity and confidentiality. 50 CHAPTER 8. CONCLUSION AND FUTURE WORK

8.2 Future Work

What could be done in the future regarding this project.

As mentioned above in section 7.2 authorization is not considered. Only the possibility of adding the fields of username and password in the MQTT connect packet is considered. Thus, it is in this matter thus that more work could be done in order to have authorization against the MQTT broker on top of the payload encryption AES-GCM used.

Firmware updates would be necessary also to be implemented. These would imply the renewal of the AES keys for the IoT devices which are necessary for the AES-GCM block cipher. Moreover, in this work we have focused and proposed a solution for MQTT which fulfills confi- dentiality issues but not authentication. This should be further studied and different implementations could be done in the broker.

The link between the database and the webserver should be protected with TLS connection. This link was not a matter for this thesis work and that is why this was not studied. The website where the data col- lected from the IoT device should also require a type of authorization on the application layer such as username and one time password.

All the experiments have been conducted having all the entities men- tioned in architecture 5.1 in the same wireless LAN. Therefore this ar- chitecture should be implemented in a more realistic manner having the IoT device in a cellular network. Bibliography

[1] L. Atzori, A. Iera, and G. Morabito. “The Internet of Things: A survey”. In: Computer Networks 54 (2010), pp. 2787–2805. [2] A. Botta et al. “Integration of Cloud computing and Internet of Things: A survey”. In: Future Generation Computer Systems 56 (2016), pp. 684–700. [3] K. Fysarakis et al. “Which IoT Protocol?: Comparing standard- ized approaches over a common M2M application”. In: IEEE Global Communications Conference (2016), pp. 1–7. [4] “RFC The Security (TLS) Protocol Version 1.2”. In: (). URL: ://tools.ietf.org/html/rfc5246. [5] “HiveMQ. Enterprise MQTT broker”. In: (). URL: https : / / www.hivemq.com/mqtt-essentials/. [6] “MQTT official website”. In: (). URL: http : / / mqtt . org / projects. [7] “Understanding MQTT topics, their structure and hierarchy”. In: (). URL: http://www.steves-internet-guide.com/ understanding-mqtt-topics/. [8] “MQTT Quality of Service”. In: (). URL: https://www.hivemq. com/blog/mqtt-essentials-part-6-mqtt-quality- of-service-levels. [9] “MQTT, MQ Telemetry Transport: An introduction to MQTT, a protocol for M2M and IoT applications”. In: (). URL: https : //www.slideshare.net/PeterREgli/mq-telemetry- transport.

51 52 BIBLIOGRAPHY

[10] B. Rahardjo S. Andy and B. Hanindhito. “Attack Scenarios and Security Analysis of MQTT Communication Protocol in IoT Sys- tem”. In: Proc. EECSI 2017, Indonesia, 19-21 September 2017 (2017). [11] “OASIS Standard MQTT version 5.0”. In: http://docs.oasis-open.org/mqtt/ mqtt/v5.0/mqtt-v5.0.pdf (2018). [12] “RSA and ECC comparison in embedded systems”. In: (). URL: http://ww1.microchip.com/downloads/en/DeviceDoc/ Atmel-8951-CryptoAuth-RSA-ECC-Comparison-Embedded- Systems-WhitePaper.pdf. [13] “RFC AES Galois Counter Mode (GCM) Cipher Suites for TLS”. In: (). URL: https://tools.ietf.org/html/rfc5288. [14] Morris Dworkin. “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode(GCM) and GMAC”. In: Com- puter Security (2007). [15] “Analysis of AES-GCM Cipher Suites in TLS”. In: (). URL: https: / / linkspringercom . focus . lib . kth . se / content / pdf/10.10072F978-3-319-68385-0.pdf. [16] “AGalois/Counter Mode (GCM)”. In: z/OS Cryptographic Services ICSF Application Programmer’s Guide SA22-7522-16 (). URL: https: //www.ibm.com/support/knowledgecenter/en/SSLTBW_ 2.1.0/com.ibm.zos.v2r1.csfb400/csfb4za2225.htm. [17] M. Ammar, G. Russello, and B. Crispo. “Internet of Things: A survey on the security of IoT frameworks”. In: Journal of Informa- tion Security and Applications 38 (2018), pp. 8–27. [18] D. Thatmann et al. “Applying Attribute-based Encryption on Publish Subscribe Messaging Patterns for the Internet of Things”. In: IEEE International Conference on Data Science and Data Intensive Systems (2015). [19] S. Almuhammadi and I. Al-Hejri. “A comparative Analysis of AES Common Modes of Operation”. In: IEEE 30th Canadian Con- ference on Electrical and Computer Engineering(CCECE) (2017). [20] Vern Paxson. “Introduction to Communication Networks”. In: https://www.openssl.org/ 17 (2011), pp. 4711–4721. [21] A. Niruntasukrat et al. “Authorization Mechanism for MQTT- based Internet of Things”. In: IEEE ICC2016-Workshops: W07 Work- shop on Convergent Internet of Things (2016). BIBLIOGRAPHY 53

[22] E. Walid R. Muzaffar D. Gerard M. Avijit N. Thomas and T. Daniel. “A secure end-to-end IoT solution”. In: Sensors and Actuators A: Physical 263 (2017), pp. 291–299. [23] S. Raza et al. “SecureSense: End-to-end secure communication architecture for the cloud connected Internet of Things”. In: Fu- ture Generation Computer Systems 77 (2017), pp. 40–51. [24] R. Matischek F. Saghezchi J. Rodriguez A. Bicaku S. Maksuti M. Tauber C. Schmittner A. Esfahani G. Mantas and J. Bastos. “A Lightweight Authentication Mechanism for M2M Communica- tions in Industrial IoT Environment”. In: IEEE Internet of Things Journal (2017). [25] Filip Forsby et al. “Lightweight X.509 Digital Certificates for the Internet of Things”. In: (2018). Ed. by Giancarlo Fortino et al., pp. 123–133. [26] A Bhawiyuga, M. Data, and A. Warda. “Architectural Design of Token based Authentication of MQTT Protocol in Constrained IoT Device”. In: 11th Internation Conference on Telecommunication Systems Services and Applications (October 2017). [27] S. Katsikeas et al. “Lightweight and secure Industrial IoT Com- munications via the MQ Telemetry Transport Protocol”. In: (2017). [28] M. Villalba S. Hernandez and R. Lacuesta. “MQTT Security: A Novel Fuzzing Approach”. In: Wireless Communications and Mo- bile Computing 2018 (2018). [29] “Virtual Box homepage”. In: (). URL: https://www.virtualbox. org/. [30] “Node.js official webpage, a javascript runtime.” In: (). URL: https: //nodejs.org/en/. [31] “Fast, unopinionated, minimalist web framework for Node.js”. In: (). URL: https://expressjs.com/. [32] “Mongodb a no-sql database”. In: (). URL: https : / / www . mongodb.com/. [33] “A robust, commercial-grade, and full-featured toolkit for the (TLS) and Secure Sockets Layer (SSL) protocols.” In: (). URL: https://www.openssl.org/. [34] “Official website of Mosquitto, an open source message broker that implements the MQTT protocol”. In: https://mosquitto.org/ (). TRITA-EECS-EX-2018:757 www.kth.se