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

, STOCKHOLM SWEDEN 2018

Security analysis for MQTT in Internet of Things

DIEGO SALAS UGALDE

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Security analysis for MQTT inInternet of Things

DIEGO SALAS UGALDE

Master in Network Services and SystemsDate: November 22, 2018Supervisor: Johan Gustafsson (Zyax AB)Examiner: Panos Papadimitratos (KTH)Swedish title: Säkerhet analys för MQTT i IoTSchool 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 severaldifferent scenarios and implementations where IoT is involved. Eachof them has its requirements. In these type IoT networks new com-munication protocols which are meant to be lightweight are includedsuch as MQTT.

In this thesis there are two key aspects which are under study: secu-rity and achieving a lightweight communication. We want to proposea secure and lightweight solution in an IoT scenario using MQTT asthe communication protocol.

We perform different experiments with different implementationsover MQTT which we evaluate, compare and analyze.

The results obtained help to answer our research questions andshow that the proposed solution fulfills the goals we proposed in thebeginning of this work.

iv

Sammanfattning

"Internet of Things", dvs IoT, har blivit ett mycket trenderande ämneinom forskning och har undersökts de senaste åren. Det kan finnasflera olika scenarier och implementeringar där IoT är involverad. Varoch en av dem har sina krav. I dessa typer av IoT-nätverk ingår nyakommunikationsprotokoll som är lightweight, såsom MQTT.

I detta arbete finns två viktiga aspekter som studeras: säkerhet ochuppnå en lightweight kommunikation. Vi vill föreslå en säker och lightweight lösning i ett IoT-scenario med MQTT som kommunikations-protokoll.

Vi utför olika experiment med olika implementeringar över MQTTsom vi utvärderar, jämför och analyserar.

De erhållna resultaten bidrar till att svara på våra forskningsfrågoroch visar att den föreslagna lösningen uppfyller de mål vi föreslog ibörjan av detta arbete.

Contents

1 Introduction 11.1 Context and motivation . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement and Research Question . . . . . . . . 21.3 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Main contributions . . . . . . . . . . . . . . . . . . . . . . 41.5 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Background 62.1 MQTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 The protocol . . . . . . . . . . . . . . . . . . . . . . 62.1.2 MQTT broker . . . . . . . . . . . . . . . . . . . . . 82.1.3 Topics . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Quality of Service . . . . . . . . . . . . . . . . . . . 92.1.5 Session and Messages . . . . . . . . . . . . . . . . 12

2.2 Security in MQTT . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Security breaches and attacks against MQTT . . . 142.2.2 Security possibilities in MQTT . . . . . . . . . . . 15

2.3 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.1 Asymmetric key . . . . . . . . . . . . . . . . . . . 172.3.2 Symmetric key . . . . . . . . . . . . . . . . . . . . 182.3.3 AES encryption modes . . . . . . . . . . . . . . . . 192.3.4 TLS/SSL . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . 252.5 Aim of the thesis . . . . . . . . . . . . . . . . . . . . . . . 28

3 Methodology 293.1 Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Action Research . . . . . . . . . . . . . . . . . . . . . . . . 293.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . 30

v

vi CONTENTS

3.4 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Implementation 314.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Solution Architecture 335.1 Design Overview . . . . . . . . . . . . . . . . . . . . . . . 33

6 Results 386.1 Bandwidth Overhead . . . . . . . . . . . . . . . . . . . . . 38

7 Evaluation 457.1 Research questions . . . . . . . . . . . . . . . . . . . . . . 457.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Conclusion and Future Work 488.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . 488.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliography 51

List of Figures

2.1 MQTT in the TCP/IP stack. Based on [5]. . . . . . . . . . 72.2 Basic architecture of MQTT. Based on [5]. . . . . . . . . . 72.3 Basic architecture of MQTT. Based on [7]. . . . . . . . . . 82.4 QoS 0 of MQTT. Based on [8] . . . . . . . . . . . . . . . . 102.5 QoS 1 of MQTT. Based on [8] . . . . . . . . . . . . . . . . 112.6 QoS 2 of MQTT. Based on [8] . . . . . . . . . . . . . . . . 112.7 MQTT packet format. Based on [9]. . . . . . . . . . . . . 122.8 MQTT connect message. Based on [9]. . . . . . . . . . . . 132.9 MQTT Publish message. Based on [9]. . . . . . . . . . . . 132.10 Comparison between ECC and RSA key sizes. Based on

[12]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.11 AES-GCM encryption mode. Based on the one present

in the work [16] . . . . . . . . . . . . . . . . . . . . . . . . 222.12 Previous research work in MQTT and security . . . . . . 27

5.1 Built Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 Size in bytes of the MQTT connect packet . . . . . . . . . 396.2 Size of the packets experiments 2 and 3 . . . . . . . . . . 406.3 MQTT publish packet in experiments 1 and 4 . . . . . . . 416.4 Bytes in the communication link for all the options studied 416.5 Bandwidth overhead with the different security alterna-

tives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426.6 MQTT overhead over the rest of the data in the MQTT

publish . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.7 MQTT protocol overhead MQTT publish . . . . . . . . . 446.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 broughta 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 calledinter-machine communication over the internet or machine to machinecommunication , i.e. M2M, is a concept that implies the ability of phys-ical devices measuring and sensing data from the real world for thensending that data over the Internet.

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

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

A huge variety of protocols have been implemented and are alreadystandardized in the Internet of Things. Two examples of them areMQTT, 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 theseIoT protocols are suitable depending the context and the specific re-quirements needed being each of them the best option depending onthe scenario wanted [3]. These IoT protocols are meant to be lightweightsince devices such as a watch or a sensor measuring temperature wouldnot be able to handle heavy communications.

In this thesis, we have chosen to use MQTT as the IoT communicationprotocol 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 inmind but wanting to achieve a very simple and light protocol to mini-mize bandwidth and energy usage. Thus, security in MQTT is a majorproblem in terms of authentication, authorization, confidentiality andintegrity. Regarding the lack of confidentiality present in MQTT wecan say that packets in MQTT can be spied by an attacker because noencryption is applied. Thus a secure mechanism is needed over thetransport protocol,such as TLS [4]. Some works have been done in thisarea and more research is ongoing to achieve a secure communicationusing 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, inStockholm. They expressed the need of a solution to provide a securecommunication 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 overthe MQTT protocol to provide a secure communication betweena 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 secureIoT system in which a constrained device sends data to a cloud usingMQTT as the IoT protocol for communication. The main problem isthat this has to be achieved in the most lightweight manner, i.e. arelatively small overhead. Thus, how the establishment of a secureIoT system between an IoT device and the cloud using MQTT as theIoT 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 detailedin the following chapters. When we mention secure system we arereferring to avoid different types of attacks to the MQTT broker as it isdescribed in Chapter 2. The main goals of the thesis are detailed here:

• Provide a secure system between the blasting sensor and thecloud 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 providea secure communication using MQTT protocol between a sensor andthe cloud.

In this work a secure architecture using MQTT as the IoT protocol withAES-GCM payload encryption has been provided. This solution hasbeen compared along with other implementations over MQTT whichwill 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-secureMQTT, MQTT over TLS with RSA certificates and ECC certificates andour proposed solution, MQTT with AES-GCM encryption are studiedin this thesis.

1.5 Structure

This thesis is organized in seven different chapters.

• Chapter 2 is a background of the different contents the readersshould know is introduced and explained as well as previouswork and a restatement of the aim of this thesis.

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

• In chapter 4 the solution architecture proposed is explained indetail including the different phases of work done during thisthesis.

• 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 securityin MQTT and the concepts under study in this work. We also discussthe 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 DrAndy Stanford-Clark of IBM, and Arlen Nipper of Arcom (now Eu-rotech), in 1999 and now it is an open standard. Since then it hasbecome one of the standard protocols in the Internet of Things andit 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 footprintand 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 simpleand lightweight. It is an application layer protocol that works on topof the TCP/IP stack, as it is shown in figure 2.1. The main ideas of itsdesign are to reduce the network bandwidth as well as device resourcerequirements, attempting at the same time to provide reliability andsome 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 clientwhich 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 subscribedto that topic. This will be further explained in section 2.1.5. A simpleexample of this architecture can be seen in figure 2.2. In that figure,two clients, i.e. Laptop and Mobile Device, are subscribed to differenttopics. A client, i.e. IoT device, is publishing the message "Hi" to thetopic "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, managesall messages being published from the clients. In other words, it is theresponsible to deliver messages to the subscribers [6]. The broker inMQTT 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 differentlevels separated by a slash. This hierarchy-like structure is representedin 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 brokerhas a retained or last will messages stored for that topic. This will beexplained further in the following section 2.1.4. When creating a newtopic, a client is practically free in choosing that name although thereare some exceptions as explained in the following section.

Special Topics

There is one special topic in MQTT called $SYS topic. This is created bydefault by the MQTT broker and it is a reserved topic used by most ofthe MQTT brokers to provide information about the broker. These areread-only topics for the MQTT clients [7]. This is why when creating atopic, 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 asingle level wildcard. This can be easily understood with the followingexample:

• /blastingsensor/iot1/#/

• /blastingsensor/+/movement

In the first case, all the features from the iot1 would be given whereasin the second case only the feature movement would be given but fromevery single device, i.e. iotx. It needs to be mentioned that wildcard isonly 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 talksabout 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 servicecan 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 thisentity will not know if the message arrived to the broker. This qualityof 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 keepwaiting for an acknowledgement from the MQTT broker. If this doesnot happen after an interval of time the client will retry to publish themessage again. When it receives the ack, i.e. acknowledgement, itwill 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 flowarchitecture of this quality of service can be seen in 2.5.

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

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

2.1.5 Session and Messages

In this subsection specific characteristics of the Message format andsession 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 orseveral topics in order to receive messages. An important aspect thatneeds 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 canbe stored or better said, retained, in the broker. This is because of theso-called "Retained messages". When a client publishes a message toa topic different types of flags and options can also be sent along withas 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 untila new one is sent.

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

This means that whenever a subscriber connects, it will receive the lastmessage 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 thesecurity problems in MQTT and the different possibilities that can beimplemented on top of this protocol.

2.2.1 Security breaches and attacks against MQTT

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

Subscriber to all topics

An attacker can subscribe to the wildcard topic explained in previoussections, i.e. #. This would allow the attacker to be subscribed to alltopics 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 brokerand thus perform a denial of service attack to the MQTT broker.Theaim is these types of denial of service, i.e. DoS attacks is to exhaustresources 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 differentscenarios. It does not matter if the broker uses authentication mech-anism or not because the data in transit can easily be sniffed by anattacker. This issue is again a confidentiality one meaning that datacan be seen by anyone with basic networking skills.

CHAPTER 2. BACKGROUND 15

Authentication

As stated in the previous section, MQTT offers some security featuresin the application layer. If the broker for instance uses client authenti-cation mechanism by only allowing users by username and passwordthe 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 inthe CONNECT command. The same problem arises here, an attackercan sniff the data and take those credentials and use them against thebroker to publish data or receive it.

Data Integrity

It is clear now that an attacker can sniff the data without too muchtrouble. It does not really matter that username and password are usedas an authorization mechanism to connect to the MQTT broker. A big-ger problem comes here regarding data integrity. An attacker, havingeavesdropped the conversation can capture the packets and modifythem to later send them to the MQTT broker. This may cause a seri-ous problem to different IoT devices that are subscribed to those topicswhere the message is being altered. Behavior of those IoT devices canbe 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 tobe explained here.

2.2.2 Security possibilities in MQTT

As already implied, the MQTT protocol itself was not designed withsecurity 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 TCPas its transport protocol so no encrypted communication is used.

16 CHAPTER 2. BACKGROUND

In each layer of the TCP/IP protocol stack, resistance against differenttypes 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 notransport encryption is used.

Transport Level

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

Application Level

It is in this level where MQTT security properties are optional to beimplemented. In the MQTT connect packet shown in 2.8 there are twooptional fields that can be used for MQTT client authentication to thebroker. Those fields can be seen in figure 2.8 which are part of theoptional 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 thetechnology used to implement that. One of this implementations isregarding access control.

CHAPTER 2. BACKGROUND 17

This access control to the broker is based on some lists called AccessControl 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 ofpublic-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 aprivate key and a public key. The public key is as its name suggestspublic so it is freely distributed while the private has to be kept as asecret.Public key cryptography is a costly operation and that is why itis known to be slower than symmetric key cryptography.

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

RSA

RSA, i.e. Rivest-Shamir-Adleman is a cryptographic algorithm, one ofthe first asymmetric key cryptosystems. In this algorithm, two largeprimer numbers are needed to be computed to later save that compu-tation as a secret key. RSA is embedded in the TLS/SSL protocol whichis used to establish secure communication.

18 CHAPTER 2. BACKGROUND

The sender can encrypt a message with the receiver’s public key andthe 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 cryptographyis much faster than RSA and it requires thus less computational power.This is mainly because the smaller key-sizes needed in ECC to achievesimilar 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 anew type of encryption was released as it will be explained in the fol-lowing section. Cryptosystems which use symmetric key refer to thoseencryption methods in which the same key is shared between both thesender and the receiver. That is why it is also called secret-key cryp-tosystems. These keys are normally distributed between the partiesusing a secure channel.

Symmetric key ciphers are implemented as either block ciphers orstream 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 thefollowing section.

Stream Ciphers

Stream ciphers are symmetric key ciphers in which a pseudorandomcipher digit stream is combined with plaintext digits. They work witha time-varying transformation on individual plaintext digits. This is,plaintext digits are encrypted one at a time with the keystream to thengive a digit of the ciphertext stream. The encryption is then dependenton the current state of the cipher, so this stream ciphers are also knownas state ciphers.

Block Ciphers

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

2.3.3 AES encryption modes

This block cipher, i.e. AES, has several different operation modes as itwas explained above that block ciphers do. In this section of the reporttwo of the encryption modes of AES will be explained, the ones usedin this work.

Advanced Encryption Standard, i.e. AES is a block cipher developedby Joan Daemen and Vincent Rijmen. AES can work with diffent keysizes, i.e. 128-bit, 256-bit and 512-bit, and it has from 10 to 14 roundsof 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 ablock cipher into a stream cipher. The next keystream is generated byencrypting successive values of a ’counter’. This mode was also intro-duced in at the same time as public key encryption, 1979 by WhitfieldDiffie and Martin Hellman. This encryption mode is shown in figure

AES-GCM

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

Security in AES-GCM

AES-GCM encryption mode, has been proven to be secure when it isused 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 importantaspect to ensure security with AES-GCM is choosing a unique initial-ization vector for every encryption which is performed with the samekey. GCM is a useful secure mode to communicate in a secure mannerwith small embedded devices [15].

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

CHAPTER 2. BACKGROUND 21

authenticity for the additional authenticated data (AAD). The AAD isnot encrypted. GCM mode requires that the IV is a nonce, i.e., the IVmust 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 thefollowing:

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 paddingstring 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 isa 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 isapplied to the resulting string to form the pre-counter block.

3. The 32-bit incrementing function is applied to the pre-counterblock to produce the initial counter block for an invocation of theGCTR function on the plaintext. The output of this invocation ofthe 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 lengthsof 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 produceblock u.

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

6. This output block is encrypted using the GCTR function with thepre-counter block that was generated in Step 2, and the result istruncated to the specified tag length to form the authenticationtag.

22 CHAPTER 2. BACKGROUND

Figure 2.11: AES-GCM encryption mode. Based on the one present inthe 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 128bits. 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 thesame process as in the encryption and the compare those tags. If theymatch, the decryption will proceed since it has been proven that datahas not been tampered with.

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

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 providesecure communication over the Internet, mainly privacy and data in-tegrity.

TLS/SSL relies on digital certificates to be able to certify the ownershipof a public key by an entity, which has to be specified on the subject ofthe certificate. These certificates are issued by the so-called Certificateauthorities. The whole system is called public key infrastructure. Thepublic keys need to be binded to the identity of the entities and this isable 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 networkconnection. Every cipher suites contains a set of algorithms, these are:

• Key Exchange algorithm.

• Bulk encryption algorithm.

• Message authentication code, i.e. MAC algorithm.

The key exchange algorithm is used to exchange a key between twoparties, a key which will later be used to encrypt and decrypt the mes-sages with. The bulk encryption algorithm is used to encrypt the datathat is going to be sent. And the message authentication code or MACalgorithm provides data integrity checks to be able to ensure that datahas 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 compromisedif one of the private keys is compromised in the future. The lack offorward secrecy could be fatal to a system since past sessions couldalso be decrypted.

2.4 Related work

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

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

Other work by Fysarakis et al. provided a survey explaining the prosand 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 publishsubscribe messaging patterns for the IoT, as MQTT. They contributedwith a new approach on how to apply ABE in combination with MQTTand 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]. Theirmotivation and main goal was to provide MQTT with security andargued that the solution recommended of MQTT using SSL/TLS addsignificant 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 certificaterevocation checks are needed.

26 CHAPTER 2. BACKGROUND

Niruntasukrat et al. suggested in their work that there is a need forthe implementation of a mechanism on top of MQTT authenticationto be able to provide federated identity management and fine-graineddevice 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 whichwas proven to protect against several attacks like data breach, Denialof 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 differentscenarios 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 onlyon 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 compressionand encoding schemes for their profiled certificate. An important fea-ture is the compatibility with the X.509 standard, meaning that theirlightweight 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]. Theyporposed 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 alightweight protocol and its suitability for industrial purposes. Theyevaluated different security options for MQTT nodes, namely payloadencryption with AES, payload encryption with AES-CBC, payload au-thenticated encryption with AES-OCB and link layer 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 areattractive 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 claimthat 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 workit 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 isto achieve low overhead in the communication link between the blast-ing sensor and the MQTT broker which is the first entity in the cloudreceiving packets from the IoT device.

This second goal goes in relation with the first one. It is key to findthe 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. Duringthe first phase of the thesis research was conducted. As stated abovein section 1.3 the project wanted to be done was to provide a solutionwhich would satisfy a secure and lightweight communication betweensensors and the cloud. Therefore research in the different types of IoTprotocols 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 thiswork the two key aspects of this thesis came in to place, i.e. securityand 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 possiblebut providing at the same time a secure communication between thesensor and the cloud using MQTT but not adding much more over-head which would make this protocol not as light-weighted. It is herewhere the research questions also mentioned above in 1.4 first appear.

3.3 Data collection

Several experiments were performed during this thesis work whichwill be further explained in chapter 5. We build a simple scenario andperform different experiments implementing different alternatives ontop of MQTT.

3.4 Data analysis

After having performed the different experiments in this thesis andgathered all the date we are able to draw conclusions and evaluate ifour 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 implementationof our system is explained. Firstly it needs to be said that the architec-ture and the implementation have been done in the same Local AreaNetwork, i.e. LAN.

4.1 Hardware

Regardless the phase of work, same equipment was used. A RaspberryPi Zero was used to act as the IoT device. The rest of the systemspresented in the architecture shown in figure 5.1 are virtual machinesdeveloped in Virtual Box [29]. A mobile phone was used to act as thedevice used connecting to the webpage where the data sent from theIoT 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 isa JavaScript runtime, event-driven and non-blocking I/o model.It was selected mainly because these features mentioned makeNode.js lightweight and efficient [30]. Node.js has a module forMQTT and also other one for cryptography which were the onesmainly used in our code.

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

• MongoDB was used as the database. Mainly because it is a NoSQLdatabase 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 message broker was used for theMQTT brokers’ implementation. It is a lightweight and suitablefor 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 areexplained 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 ourexperiments from which we were able to collect all the data needed todraw conclusions. We conducted different experiments which analysiswill be explained in chapter 5.

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

IoT device

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

MQTT broker

Is the key element for this scheme to work. It is responsible entityto 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 needto decrypt and authenticate the data originally sent from the IoTdevice. The data arrives to this system already encrypted withTLS and using the cipher suite mentioned above since it is theMQTT broker 2 from which this database receives the sensor datafrom. When this data is decrypted at the database it publishes itto 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 thiscommunication link is not the focus of this thesis.

User

It connects to the webserver via HTTP and is able to see all thedata 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 werealso implemented. These entities were needed for the case werethe MQTT broker listen in port 8883.

The different experiments can be summarized as follows:

1. IoT device publishing different amounts of payload using MQTTover TCP

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

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

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

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

• MQTT broker listening in port 1883

And for the experiments where MQTT is over TLS, i.e. experiments 2and 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 keyand with a ECC 224 bits in experiment 4. As shown in the backgroundchapter 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 ofbits needed. For this two experiments, the corresponding certificateswere 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 authorizationwere used. These are:

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

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

These fields in the MQTT connect packet namely username and pass-word, provide a way of authorization against the MQTT broker. Thisis, 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 mentionedfor experiment 4. As said in section 2.3.3 three inputs were needed forthis implementation. These are:

• An AES key

• An initialization vector (IV)

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

An important aspect in AES-GCM is that an IV is not used twice withthe same key. In out experiment the same key was used but the IV waschanged every single time. For implementing that, we used an MQTTtopic to which the IoT would be subscribed. The IoT device wouldreceive the IV and then be able to perform the encryption with the cor-responding plaintext an AES key. The same applies for the databasewhich is the subscriber of the topic the IoT device is publishing. Thisentity needs also to be subscribed to the topic in which the IV is beingpublished. 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 thatdata has not been tampered with.

Chapter 6

Results

In this chapter the results obtained are displayed and commented. Asexplained in chapter 5 we have conducted different experiments andgathered the data needed. Having all the data collected we were ableto proceed with the corresponding data analysis mentioned in chapter3.

6.1 Bandwidth Overhead

In this section the bandwidth of the communication link between theIoT 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 otherwords, we used MQTT over TCP. As mentioned above we configuredtwo options for this and all the experiments:

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

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

38

CHAPTER 6. RESULTS 39

Figure 6.1 show the number of bytes of that packet which sent to theMQTT broker. In this example a username of 5 bytes of length and apassword 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. Theother 4 bytes are added in the MQTT connect to specify the lenght ofthe 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 theMQTT broker, i.e. 95, and the same in the case that credentials areused, i.e. 113.

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

Figure 6.2 shows the total size of the packets exchanged between theIoT device and the MQTT broker of these two experiments. The caseshown in the graph is the one when the IoT device send a payload of1 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 MQTTbroker is configured as in experiment 1, listening on port 1883.

The authentication tag size is 128 bits, i.e. 16 bytes. This way whenpublishing the data in the MQTT publish packet, 16 bytes will be addedto the payload sent by the IoT device. This authentication tag can beused to check the integrity of the message. This is done by the databasein this work, which is the subscriber to the topic that the IoT devicepublishes 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 aresent only in the MQTT connect packet and not in the MQTT publishwhich is the one shown in the mentioned figure. We can see that inexperiment 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 linkbetween 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 tothe case in which the IoT device publishes 1 byte as payload. It canbe seen that the cases where TLS is used represent the cases in whichmore bytes are exchanged between the IoT device and the MQTT bro-ker. This is mainly because the need of sending the certificate from thebroker to the IoT device and the computation of common secret andsession keys generation [4].

In the four experiments that we performed, different payloads werepublished 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 inbytes:

• 1000, 5000, 10000, 20000, 30000

We show in figure 6.5 the overhead expressed in percentage that otherdata sent in the communication between the IoT device and the MQTTbroker imposes over the actual MQTT payload sent by the IoT device.From this figure we can see that it is experiment in which less overheadover the MQTT payload experienced. This is the case where standardMQTT was used, in other words the most lightweight case. We can seethat 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-GCMpayload encryption is used.

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

In the previous figure a graph in which big payload was sent in allof the experiments was shown. In figure 6.6 the case in which smallpayload are sent from the IoT device can be seen. In this graph theprotocol overhead of MQTT in the MQTT publish packet is shown. Inother words, the overhead that the protocol MQTT imposes to the restof the data in the publish packet. A similar conclusion to the one didwith previous figure can be drawn here. Data from experiment 4 ismore similar to experiment 1, implying that experiment 4 is providingsecurity to MQTT and not adding too much overhead than in the caseof 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 casesbigger 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-GCMencryption 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 thesame 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 goalsare met.

7.1 Research questions

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

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

The main goals of the thesis are:

• Provide a secure system between the blasting sensor and thecloud 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 overthe MQTT protocol to provide a secure communication betweena sensor and the cloud? Why or why not?

As we can see from our results traditional security protocols theuse of them implies more bytes exchanged in the communicationlink between the IoT device and the cloud. One of our goals inthis thesis was to have low overhead in the communication, asthe MQTT with no secure implementation guarantees. Takingthis into account it could be said that this lightweight communi-cation is not achieved with traditional security protocols as it canbe 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 theblasting 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 encryptionin MQTT which is an authenticated encryption. This guaranteesthe integrity of the message. Even if an attack wrote a message tothe broker, this would be accepted but later rejected because theparty 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 solutionfor securing AES-GCM is an authorized encryptions which guaran-tees data integrity and confidentiality. This means that basically everyentity would be able to publish messages to the MQTT broker if nocredentials are asked by the MQTT broker in the MQTT connect.

This system presented in this thesis answers to the need of having asecure system in IoT using a very lightweight protocol such as MQTTadding 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 thecontinuation 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 weconcluded that MQTT was the best option to have as the IoT proto-col. The other goal to keep the lightweight communication which isachieved with the MQTT protocol itself.

We performed different experiments to analyze different options to beimplemented and would make the communication between the IoTdevice and the cloud secure but also lightweight. The results showthat TLS although being a good secure option implies the exchange ofmuch more number of bytes that in the case when payload encryptionis used. In this thesis AES-GCM encryption is proposed to be a goodsolution. As it is shown in chapter 6 this is the case where the numberof bytes exchanged in the communication link is more similar to thecase 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 aspectand 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 inthe MQTT connect packet is considered. Thus, it is in this matter thusthat more work could be done in order to have authorization againstthe MQTT broker on top of the payload encryption AES-GCM used.

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

The link between the database and the webserver should be protectedwith TLS connection. This link was not a matter for this thesis workand that is why this was not studied. The website where the data col-lected from the IoT device should also require a type of authorizationon 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 havingthe IoT device in a cellular network.

Bibliography

[1] L. Atzori, A. Iera, and G. Morabito. “The Internet of Things: Asurvey”. In: Computer Networks 54 (2010), pp. 2787–2805.

[2] A. Botta et al. “Integration of Cloud computing and Internetof 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: IEEEGlobal Communications Conference (2016), pp. 1–7.

[4] “RFC The Transport Layer Security (TLS) Protocol Version 1.2”.In: (). URL: https://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, aprotocol 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 andSecurity 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 ofOperation: 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 ServicesICSF 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: Asurvey 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 onPublish Subscribe Messaging Patterns for the Internet of Things”.In: IEEE International Conference on Data Science and Data IntensiveSystems (2015).

[19] S. Almuhammadi and I. Al-Hejri. “A comparative Analysis ofAES 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 communicationarchitecture 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. “ALightweight Authentication Mechanism for M2M Communica-tions in Industrial IoT Environment”. In: IEEE Internet of ThingsJournal (2017).

[25] Filip Forsby et al. “Lightweight X.509 Digital Certificates for theInternet of Things”. In: (2018). Ed. by Giancarlo Fortino et al.,pp. 123–133.

[26] A Bhawiyuga, M. Data, and A. Warda. “Architectural Design ofToken based Authentication of MQTT Protocol in ConstrainedIoT Device”. In: 11th Internation Conference on TelecommunicationSystems 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: ANovel 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 theTransport Layer Security (TLS) and Secure Sockets Layer (SSL)protocols.” In: (). URL: https://www.openssl.org/.

[34] “Official website of Mosquitto, an open source message brokerthat implements the MQTT protocol”. In: https://mosquitto.org/ ().

www.kth.seTRITA-EECS-EX-2018:757