Blockchain enabled IOT

Chaahat Jainu6398806

A report submitted for the courseCOMP3770 - Individual Research Project

Supervised by: Dr. Sid Chi-Kin ChauThe Australian National University

May 2019

Except where otherwise indicated, this report is my own original work.

Chaahat Jain28 May 2019

Acknowledgments

I would like to thank my supervisor Dr. Sid Chau for guiding me throughout theproject. I would also like to thank Professor Weifa Liang for conducting variousworkshops that were extremely beneficial during this project. Finally, I would like tothank my friends and family for ceaselessly supporting me in this endeavour.

iii

Abstract

We present a protocol allowing the User and their Internet Of Things(IoT) device tocoordinate in solving the proof of work. The central idea is to distribute the proofof work into two sections - data dependent, which is solved by the IoT, and dataindependent, which is solved by the user. Furthermore, this protocol leverages digitalsignatures to associate the user and their device on the blockchain, a platform whereanonymity is prioritized. It examines the cases where this protocol would be in effectand offers an alternative when the user is unable to contribute their share of the proofof work. We explore attacks on the communication between the IoT and the User;mainly Identity Theft, Denial of Service and Eavesdropping. The goal of this paperwas to demonstrate the plausibility of coordination between the user and their deviceover an anonymous network. It acts as a starting point to facilitate communicationbetween them via the blockchain. This would enable the IoT to push data onto theblockchain and therefore, its effects on feasibility can be studied. The work presentedhere constitutes a theoretical analysis and must be further developed for its real lifeapplications.

v

vi

Contents

Acknowledgments iii

Abstract v

1 Introduction 11.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Project Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Report Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Background and Related Work 32.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Proof of Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Internet Of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.4 Incorporating Blockchain into IoT . . . . . . . . . . . . . . . . . . 4

2.2 Related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 Design and Implementation 73.1 Digital Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Design Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.3 Key Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.3.1 Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.2 Transaction Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.3 User Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.3.4 Transaction Selection Algorithm . . . . . . . . . . . . . . . . . . . 9

3.4 Design Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.4.1 IoT and User submit proof of work . . . . . . . . . . . . . . . . . 93.4.2 User cannot submit proof of work . . . . . . . . . . . . . . . . . . 103.4.3 IoT has to urgently push data . . . . . . . . . . . . . . . . . . . . 103.4.4 User mines for money . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.5 Consensus Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

vii

viii Contents

4 Security Analysis 134.1 Identity Theft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.2 Denial Of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.3 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.4 Altercation and Fabrication . . . . . . . . . . . . . . . . . . . . . . . . . . 144.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Conclusion 175.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Bibliography 19

Appendix A 21

Appendix B 23

Appendix C 25

Appendix D 27

Chapter 1

Introduction

1.1 Problem Statement

This project attempts to find a scalable blockchain system to enable communicationbetween a user and an Internet of Things (IoT) device. It also explores some attackscenarios that may emerge when using the blockchain and argues as to how thesystem remains robust against it.

1.2 Motivations

Internet Of Things provides a strong means of monitoring various processes, thereby,creating greater visibility for improvement opportunities. These devices can be con-trolled extensively from the outside, which allows rapid action on these opportuni-ties. Currently, the communication between a user and the device is facilitated bythe Cloud. However, Cloud services can only be provided by large companies, thusgiving them a monopoly over these platforms. Moreover, This allows these compa-nies to constantly surveil the users using their devices and collect data to suit theirinterests. Subsequently, they can study the data collected and modify it for their ownbenefit. The Blockchain is an emerging technology which assists in decentralizingthe authority of these companies as the data is held by all nodes in the system ratherthan a particular server. This makes the system more trustworthy and secure as afew corrupt nodes cannot modify the data held by the entire chain. Additionally, theBlockchain resolves the problem of authentication as each message from the user iscryptographically signed and cannot be forged by malicious users. However, currentimplementations of the blockchain are slow and do not scale well having an upperbound of 10-20 transactions per second. This is an impediment to future functioningas it is predicted that there will be over 30 billion IOT devices online by 2020 (Statista[2019]). In order to manage these devices in real time, we need a new system whichoffers the security of the blockchain while also being extremely quick and responsiveto devices.

1

2 Introduction

1.3 Project Scope

Incorporating the Blockchain into Internet Of Things involves a multitude of actions,and this project specifically explores the communication between the IoT and theuser. When studying the interactions between the IoT and the Blockchain, the firststep is to make the IoT push data onto the ledger. Currently, this action requires atransaction fee to be paid. Yet, due to the frequency at which the IoT pushes data,directly connecting such a device to the Blockchain becomes unfeasible. As such, formicro transactions, the Tangle proposes that the node pushing data should solve forthe Proof of Work themselves. However, IoT cannot do so on its own due to lack ofcomputational power. As such, in this project we aimed to find a scalable and secureBlockchain system to enable coordination between a user and an Internet of Things(IoT) device.

1.4 Report Outline

Chapter 2 introduces some background knowledge on Internet of Things and theBlockchain. It details some relevant work done in the field to improve the scalabilityof the Blockchain. Chapter 3 provides an overview of the intended protocol followedby a detailed explanation of it. Finally, Chapter 4 explores how the proposed pro-tocol accounts for some common attack vulnerabilities which are often exploited byattackers.

Chapter 2

Background and Related Work

This chapter introduces the technologies being used for this project. Section 2.1explains the motivation behind using the Blockchain in this project. It also discussescurrent problems with IoT and the challenges encountered when incorporating itwith the Blockchain. Section 2.2 examines some attempts being made to addressthese challenges. It also introduces The Tangle, an IoT cryptocurrency, which act asthe basis for this project.

2.1 Background

2.1.1 Blockchain

A Blockchain utilizes distributed ledger technology to serve as an irreversible publicdata repository system. It allows unrelated participants to reach a consensus on thechronological sequence of transactions that have taken place without the aid of a cen-tral authority. It provides a multitude of benefits compared to a traditional databasesystem such as:(1) Distribution - The data is distributed among many nodes in order to make itextremely hard to tamper with the data on the chain. In order to modify data, anattacker would need to overwrite several blocks that build upon the data they aretampering with. This, however, is computationally expensive due to a concept calledProof of Work (See Section 2.1.2).(2) Decentralization - The Blockchain is a system without a central authority and thuslacks a single point of failure. This makes it more robust as the system functions evenif a node is offline. Desktop computers have advanced to a point where their potentialperformance exceeds requirements of most applications. As such these systems areidle most of the time. A decentralized system can make the most of these desktopsto maximize their efficiency.(3) Trustless-ness - It removes the necessity of a trusted third party to certify transac-tions. Therefore, it is possible for nodes to individually validate transactions occurringbetween parties that do not trust each other.

However, a shortcoming is that such a system does not scale extremely well as all

3

4 Background and Related Work

the nodes of the network have to verify every transaction on it. This replication ofcomputation network and storage requirement limits the transaction throughput.

2.1.2 Proof of Work

Proof of Work is a piece of data which is difficult to produce but easy to verify.Producing a proof of work is a random process with a low probability of success suchthat many trials are required in order to get a solution(Jakobsson and Juels [1999]). Itoriginated as a method to prevent spam emails (Dwork and Naor [1992]). An attackertrying to overwrite data on the Blockchain would need to compute the proof of workfor all the blocks that are built upon the data they are tampering with. This wouldrequire the attacker to control more computational power than all the honest nodesin the network making this a near impossible feat on a network with many nodes.Here, the cost of the attack would also outweigh the benefits gained.

2.1.3 Internet Of Things

Internet of Things are devices which monitor processes by collecting data on them.IoT allows a user to have an extremely high degree of control over it which enablescareful management of the processes being monitored. However, many such devicesare small and do not have access to a continuous power source which imposes severalconstraints on their ability to compute and communicate.

Studies (Hossain et al. [2015]) have shown that IoT devices are extremely insecureand can be compromised at each and every step of their functioning. This projectlends to the communication between an IoT and the User. As the IoT are only re-quired to record and push data, it is possible for a malicious entity to pretend to bean innocent device. To connect to the global network, the IoT network spans throughdifferent network infrastructures, thus making the IoT device network vulnerable.Additionally, an IoT can be prevented from communicating to a User by blocking thenetwork services to the Cloud. Moreover, due to low computational capabilities, theIoT uses weak encryption at best while transmitting data across a network. Anotherprivacy concern is that all communication between a User and the device go throughthe Cloud. Based on these vulnerabilities, it is possible to attack an IoT device byintercepting the communication between the device and another node and so, gainingunauthorized access to the data being sent. From here, an attacker can tamper withthe information being sent from the device as well as generate additional activity,which does not exist.

2.1.4 Incorporating Blockchain into IoT

Incorporating the Blockchain as a communication interface between the User and IoTdevice solves a multitude of these problems (Reyna et al. [2018]). An IoT device willneed to communicate with its immediate peers by using only a defined protocol thusmaking the network homogeneous. In cryptocurrency implementations, the nodes

§2.2 Related work 5

connected to each other are randomly decided, thus making the network topology ex-tremely unpredictable. As such, an attacker cannot block an IoT from communicatingwith the network by interrupting connections with its immediate peers. Furthermore,the Blockchain provides an immutable ledger making it near-impossible to tamperwith the data being sent by the IoT. Additionally, it will not be possible for an attackerto fabricate the data or behave as an IoT device due to the strong authentication guar-antees of the Blockchain.Nonetheless, incorporating the Blockchain and IoT comes with its challenges. Firstly,the Blockchain does not enforce privacy. Instead, a key feature of its design is trans-parency. In Blockchain, each transaction can be checked and traced from the veryfirst transaction of the system. Secondly, the Blockchain does not scale well. In thistechnology, the chain grows at a rate of 1MB per block every ten minutes. IntroducingIoT to the system would increase the number of nodes. This results in an increase inthe number of transactions that need to be processed, and so creating a lot of traffic.In such a situation, the time between when a transaction is issued and accepted isextremely long which is problematic for real-time systems.Current shortcomings in the literature highlight privacy on the Blockchain and Scala-bility of the network. Although there are research projects that aim to overcome theselimitations, so far, very little progress has been made.

2.2 Related work

Regarding privacy, several papers, such as Zerocash(Sasson et al. [2014]) and Zero-coin(Miers et al. [2013]), propose that Bitcoin extensions are anonymous. Data en-cryption has also been explored as an alternative solution, Hawk(Kosba et al. [2016])stores encrypted transactions, its compiler translating generic code into cryptographicprimitives.

On Scalability, the GHOST protocol(Sompolinsky and Zohar [2013]) intends toimprove the scalability of the Blockchain by changing its chain-selection rule. How-ever, in this protocol, it is difficult to decide on a proper temporal sequence of blocks.Furthermore, large mining companies are shown to have an extreme advantage in thisscenario. Here, the Inclusive protocol(Lewenberg et al. [2015])can be used to providea method for incentivising individual miners thereby decentralizing the mining au-thority slightly. The Tangle(Popov [2018]) is a cryptocurrency developed specificallyfor the Internet Of Things by Serguie Popov of the IOTA foundation to increase scal-ability. The Tangle utilizes a directed acyclic graph(DAG) structure instead of a chainto store transactions. A node proposing a transaction on this system is required toapprove of two previous transactions. In this manner, users who are issuing transac-tions contribute to the network security as well. As a transaction gets more approvals,it is accepted into the system with more confidence, thus making an attempt at adouble spend extremely hard. Additionally, an issuing node must find a proof ofwork for the transaction they are issuing. This proof of work is not as difficult as thatin Bitcoin but is still significantly hard. As such a user issuing a transaction does not

6 Background and Related Work

depend on a third party, such as a miner, consequently removing the transaction feeswhich are necessary in current cryptocurrencies.

However, the Tangle has its shortcomings as well. It uses a Central coordinatorthrough which the nodes decide which transactions are to be validated. This coordi-nator is closed source which raises concerns among Blockchain enthusiasts. Moreover,there is an assumption that the IoT will have special hardware installed to allow it tosolve proof of work on par with Desktop computers but there hasn’t been significantevidence to prove this assumption. Thus, this project motivates a transaction selectionmethod which does not require a centralized coordinator. It also eases the assumptionon hardware by providing a method for the IoT and user to work together to find aproof of work when issuing a transaction.

2.3 Summary

In this chapter, we have introduced the Blockchain technology as well as some prob-lems with IoT. We have shown that Internet of Things lack of computational poweris a serious demerit when incorporating it with the Blockchain and that some vul-nerabilities arise when it is connected to the Cloud. Furthermore, we have discussedthe Tangle as an attempt to solve the scalability problem and have also introducedsome implementations that aim to make the Blockchain slightly more private than itcurrently is.The next chapter explores the design of the system being proposed in detail anddiscusses the reason behind certain design choices.

Chapter 3

Design and Implementation

This chapter introduces the design of the proposed system and explores it in detail.Section 3.1 introduces digital signatures, a powerful cryptographic primitive, whichare used for authentication in this system. Then, Section 3.2 provides a generaloverview of the functionality of the system. Following this, Section 3.3 explains thekey components required for the implementation of this system and briefly justifiestheir use. Lastly, Section 3.4 explores the various scenarios this system will be usedin.

3.1 Digital Signatures

A digital signature is the digital analog to a handwritten signature. These signatureshave two critical properties(Diffie and Hellman [1976]). Firstly, only an entity canmake their own signature but anyone can verify that it is valid. Secondly, thissignature is created based on the data it is signing, thus making it impossible toforge the signature for other documents. In order to sign a transaction, a node musthave two keys - a secret key, and a public key. The secret key is kept privately andused to sign messages; whereas the public key is used for verification and distributedamong everybody. As such, a transaction which has been verified using a public keyguarantees that the transaction has not been tampered with while also authenticatingthat the proposing node is indeed in possession of the secret key(Paul [2017]).Additionally, digital signatures can be used by entities to describe their identity in asystem. This is done by using a public key to equate to the identity of an actor. Thus,we can show an association between multiple actors if they share the same publickey. This is important to describe a relation between the IoT and the User in a systemwhere the nodes are meant to be anonymous to each other.Furthermore, the user can generate multiple sets of public and private keys for theirencryption and will still be authenticated as the provider of the data if they send acorresponding public key to decrypt the message.

7

8 Design and Implementation

3.2 Design Overview

In the system being proposed, two different kind of entities are assumed to exist -Users and IoT devices. This system then leverages the notion of digital signatureswhich are used as a means of association between users and their devices as well asverification that the data has not been tampered with(See Section 3.1). Additionally,it allows a node to issue a transaction by solving the required proof of work forit, thus, reducing the latency between issuing a transaction and having it accepted.Conventionally, a transaction has to wait to be selected by a miner which causes thelatency problem. However, as discussed in Section 2.2 the IoT lacks the computationalpower to solve for proof of work on its own. As such, we propose that the proofof work needed for a transaction be a collaborative effort of the User and the IoT.This requires the proof of work to be separated into two parts; a data independentpart which is solved by the user requiring a lot of computational power and a data-dependent part solved by the IoT device and computationally feasible for such adevice. One such instance used in this project requires the user to validate multipletransactions on the chain, as described in the Tangle. In conjunction, the IoT willneed to find a nonce, which when concatenated to the data and hashed results in acertain number of zeroes at the start, as described in Bitcoin. It is to be noted that thework done by both entities is much less compared to that done on Bitcoin. Such aproposal results in there being two different transactions received by the node fromthe user and the IoT. Both these transactions have a common pointer which is thepublic key used to sign the transactions. It is assumed that the User and IoT sharethe same private key and sign their messages using it. The message for the IoT isdecoded using the Users public key in order to verify that the IoT is associated withthe User and only then are the transactions accepted by the network. Thus, the IoTcan push data onto the Blockchain without having to compute the entire proof ofwork by itself.Similar to Bitcoin, we allow all users to have an account with a certain amount ofmoney in it. When the User cannot solve the proof of work at a given time due to lackof computational resources or the IoT needs to send an urgent message money can bededucted from the account as a price for the proof of work. This is similar to paying atransaction fees in any other cryptocurrency. In order to earn money, users will haveto validate nodes on the network when the IoT device is offline, hence increasing thesecurity of the network.

3.3 Key Components

This section describes the key components of the project implementation and justifiesthe transaction selection algorithm being proposed.

§3.4 Design Details 9

3.3.1 Transactions

A transaction holds the data to be sent from the IoT device. It also holds the addressof the User who is the owner of the device. This transaction is hashed to guaranteethat the data in it has not been tampered with. These transactions are validated byuser nodes as proof of work.

3.3.2 Transaction Blocks

Transaction data is recorded on blocks; each block holds an issuing transaction andmultiple transactions that it is validating. The blocks are signed by the proposingnodes and have the public key attached for authentication (See Section 3.1).

3.3.3 User Accounts

Each user has an account to store the money associated with them. In order to utilizethe money in this account, the user would have to sign the transaction using a privatekey. This money is used by the User when they cannot perform their share of theproof of work. Additionally, The IoT holds the access details to the account as theuser has shared the private key with it. In case of emergencies, the IoT can use themoney in the account as well. In order to earn money, the account holder is requiredto validate transactions on the graph when the IoT device is offline.

3.3.4 Transaction Selection Algorithm

The nodes are allowed to choose any method they prefer in order to select the trans-actions to be validated. In this project it is assumed that the nodes use a randomizedselection process. This approach has been critiqued in the Tangle(Popov [2018]) aslazy nodes can repeatedly validate the same transactions. Taking inspiration from theInclusive protocol, nodes are rewarded with money based on the number of timesthat transaction has already been validated(Lewenberg et al. [2015]). After some time,it becomes unfeasible for a node to validate the same transaction repeatedly as thecost of calculating the nonce for the block would outweigh the reward received forthe transaction. Thus, the users are incentivised to keep track of the entire Blockchainin order to select transactions which could maximally benefit them.

3.4 Design Details

This section describes the details of the proposed design.

3.4.1 IoT and User submit proof of work

In this system, the IoT device reads the data and generates a transaction by hashingthe data and the Users address. Next, it creates a block using this transaction and adefault transaction. This default transaction is the validated transaction and is trivial

10 Design and Implementation

to validate. Now, the IoT hashes this block, containing the transactions and its publickey, and finds a nonce for this hash as proof of work. This hash is signed by the deviceusing its private key and sent to its immediate peers who propagate the block alongthe network. As the IoT pushes data periodically, the user knows when to submitthe proof of work from their part. When the IoT is pushing its readings, the usergenerates an empty transaction. Furthermore, this user finds a couple of transactionsto validate. Once these transactions are validated, the user creates a block with theempty and validated transactions. After attaching the public key to it, the block ishashed and a nonce is found for the hash. Using their private key, the user signs thehash and the block is sent for propagation throughout the network.On receiving a block, the node stores it in a queue of all pending blocks. When thenext block with the same pointer arrives, the node checks whether the two blocks areindeed associated with each other. This is done by using the public key of either blockon the other. If this works, then the blocks were signed using the same private keyand are associated with each other. After checking that the proof of work is solvedand that the validated transactions are not extremely old, the node appends the IoTdata on to the chain corresponding to Users address.

3.4.2 User cannot submit proof of work

In the event that the user cannot solve the proof of work, the User creates an emptyblock and signs its hash using their private key. When a node receives both blocksfrom the user and the IoT device, it checks whether the users account has enoughcredit in it. After confirming that their are sufficient funds, the IoT data is accepted.Thus, the nodes are incentivised to be as active and contribute to the networks securitywhenever possible so that they have extra funds in their account saved for later.

3.4.3 IoT has to urgently push data

In case of an emergency where the IoT needs to send a message as soon as possible,it will create two blocks. The first block will hold the data in one transaction andinitialize a lot of default transactions. The second block will be an empty block.Both these blocks will have their hash computed and signed by the IoT. When anode receives these two blocks, it will appear as if the user has sent the empty blockand the IoT has sent the other. From here, the node handles the situation just likeSection 3.4.2

3.4.4 User mines for money

When the IoT is not pushing data, the users desktop has some computational powerto spare. As such, the user has the option to mine for some money. Here, the userwill select a few transactions to validate. After validation, these transactions areadded to a block generated by the user. A default transaction is added as the issuingtransaction in this as well. Next, the user adds their public key into the block, hashesit and finds the nonce related to it. The hash of this block is signed by the users

§3.5 Consensus Protocol 11

private key.On receiving this block, the node confirms that all the transactions have been vali-dated. It calculates the amount the user would gain based on each of the validatedtransactions(See Section 3.3.4) and adds the money to their account.

3.5 Consensus Protocol

The model described above is extremely powerful as all nodes do not need to bein consensus on the transactions that are added to the ledger (Popov [2018]). It isassumed in such models that the nodes will only approve transactions that are non-conflicting with the transaction history. In the event that an attacker tries to performa double spend attack on the chain in an attempt to create a fork, it has been shownthat the chain eventually chooses a fork (Popov [2018]).

3.6 Summary

In this chapter we have explored the design of the system we propose. We exploredigital signatures, a primitive used for authentication and verification. Additionally,we have also described the key components of the system and motivated their utilityin it. Furthermore, we explore multiple use cases where the system is in effectand the roles of the IoT devices and Users in each of them. Now that the primaryunderstanding of the system has been formed, we will analyze it from the perspectiveof an attacker in the next chapter.

12 Design and Implementation

Chapter 4

Security Analysis

In this chapter we discuss certain plausible attack scenarios. Research on the stabilityof the network has already been done extensively (Popov [2018], Bramas [2018]) sowe explore attacks related to the communication between the IoT and the networkmainly. Section 4.1 explores Identity Theft, here an attacker can pretend to be an IoTdevice to access data or a user to control the device. Section 4.2 deals with Denial ofService Attacks while Section 4.3 makes it trivializes the necessity for an attacker toeavesdrop on the IoT device. Section 4.4 shows why data cannot be falsified by anattacker even if they gain access to a few communication channels between the IoTdevice and the network.

4.1 Identity Theft

During an Identity Theft attack, the attacker impersonates the User to send maliciouscommands to the device. It is also possible for them to impersonate a device to gainunauthorized access to a vulnerable IoT network.In the model proposed it will not be possible for this to happen. In order to issuean instruction, the attacker would need to get their transaction onto the chain of theuser. Despite solving for the proof of work required, the instruction would need tobe signed by the users private key, something that only the user and the IoT devicehave access to.An attacker can attempt to send two blocks to a node, impersonating the user andthe IoT. In the event that a block from the actual user is already waiting on the node,both of these blocks are rejected due to not being signed by the correct private key. Ifthe node does not have a block waiting, then both these blocks would be accepted onto the users chain, however, it would not be possible to exploit this for any benefitsbecause the attacker would still be lacking the private key.

4.2 Denial Of Service

The attacker can attempt to disrupt the communication between the IoT device andthe network this device is connected to, thus, leading it to a "dead state". This is

13

14 Security Analysis

mainly done by sending multiple requests to the server, hence, causing a Denial ofService (DoS) attack. While such an attack is possible on a Cloud server it is extremelyhard to pull off in a Blockchain network. Owing to the Blockchains decentralizednature, there is no single point of failure on the network. As such, the attackercannot attack it directly. In spite of this, they can attempt to block the communicationbetween the IoT device and its peers on the network. However, as all nodes on thenetwork are randomly assigned new connections periodically, it becomes impossibleto predict which peers the IoT device will connect to.Another possible way for the attacker to create a DoS attack is to send a single block,signed using their own private key, to all the nodes in the network when the userand the IoT device are offline. The node saves this as the Users block and waits foranother one with a corresponding public key to arrive. Later, the block from the Useror the IoT device will be rejected due to a mismatch of signatures resulting from thedifferent public keys used. It is not possible for a node to identify the proposer ofa block as the Blockchain prioritizes anonymity extensively. In order to resolve thissituation, nodes are required to keep track of all the blocks related to a particularaddress rather than the first one which arrives. Whenever a new block arrives, it ischecked with all the other blocks in the list to verify whether they match. Blocks thatmatch are added to the chain corresponding to the user’s address, if not, they areadded to the waiting queue of blocks on this address. Additionally, blocks can beremoved from the queue if their counter part does not arrive in a certain amount oftime in order to increase efficiency. Therefore, an attacker cannot prevent a user fromproposing their transaction onto the network.

4.3 Eavesdropping

During an eavesdropping attack, the attacker gains access to the communicationchannel between an IoT device and the user. From here, they can listen to privateinformation that can then be used maliciously. The User can generate a key inorder to prevent private information from being leaked. This is done by encryptingthe messages using a Symmetric key encryption which utilizes the key generated.Here, this key is used for both encryption and decryption of the messages sentbetween the user and the device. As such, both the required parties get the necessaryinformation while the attacker does not. Similarly, information being broadcast overthe Blockchain can be encrypted using this key. It is important to note that this key isdifferent from the private key used for signing transactions as data encrypted usingthat can be decrypted by the public key which is accessible to everyone.

4.4 Altercation and Fabrication

After gaining access to the communication channel between the IoT device and itspeers, an attacker can attempt to change the data being sent. However, on changingthe data they would change the signature of the transaction. As such, they will need

§4.5 Summary 15

to sign the transaction again which would not be possible due to them lacking theprivate key. This transaction would be transmitted throughout the network, however,it will not be approved due to the invalid signature. A similar deterrence is observedwhen the attacker attempts to fabricate data.

4.5 Summary

This chapter explored some major attack vulnerabilities that exist during the commu-nication between an IoT device and a User. Moreover, it analyzed the effectivenessof these attacks on the proposed protocol and the Cloud server. We surmise that theproposed protocol is robust and handles these attacks more effectively compared tothe Cloud.

16 Security Analysis

Chapter 5

Conclusion

In this report, we have proposed a protocol which allows a user and their IoT device tocoordinate to solve a proof of work problem together. This protocol leverages digitalsignatures, a powerful cryptographic primitive, to prove an association between theuser and the IoT device and to authenticate access to the funds of the user’s account.After the Proof Of Work from each part is solved individually, a node receivingboth of these solutions can add the transaction to the ledger. These transactions arearranged graphically rather than in a linear chain to improve scalability. Furthermore,nodes are incentivised to actively take part in security of the network by validatingtransactions. Additionally, we have explored the robustness of our system againstsome vulnerabilities that are exploited during communication between an IoT and aUser.

5.1 Future Work

Allowing the user and IoT to coordinate to solve proof of work is a crucial step forincorporating the Blockchain into IoT; this project shows that this is possible. Fur-thermore, this project builds on previous research into the Tangle (Popov [2018])by relaxing the assumption that IoT requires specialized hardware that enables itto compute Proof of Work if necessary. This allows for a more streamlined path toimplementing these concepts into a real-life scenario. From here, the feasibility ofconnecting to an IoT can be studied. Additionally, multiple algorithms for improvingthe scalability of the network can be introduced. Currently, an algorithm for validat-ing transactions has not been sufficiently described. We wish to find an algorithmwhich could be implemented in the context of IoT. Moreover, we wish to evaluate theproposed protocol on a real-world IoT network. Ultimately, we plan to evaluate thisprotocol in terms of transaction throughput, transaction latency and computationalload on the devices.

17

18 Conclusion

Bibliography

Bramas, Q., 2018. The Stability and the Security of the Tangle. https://hal.archives-ouvertes.fr/hal-01716111. Working paper or preprint. (cited on page 13)

Diffie, W. and Hellman, M., 1976. New directions in cryptography. IEEE Transactionson Information Theory, 22, 6 (1976), 644–654. doi:10.1109/tit.1976.1055638. (cited onpage 7)

Dwork, C. and Naor, M., 1992. Pricing via processing or combatting junkmail. Advances in Cryptology âAT CRYPTOâAZ 92, (1992), 139–147. doi:10.1007/3-540-48071-4_10. (cited on page 4)

Hossain, M. M.; Fotouhi, M.; and Hasan, R., 2015. Towards an analysis of securityissues, challenges, and open problems in the internet of things. 2015 IEEE WorldCongress on Services, (2015). doi:10.1109/services.2015.12. (cited on page 4)

Jakobsson, M. and Juels, A., 1999. Proofs of Work and Bread Pudding Protocols, 258–272.Springer US, Boston, MA. ISBN 978-0-387-35568-9. doi:10.1007/978-0-387-35568-9_18. (cited on page 4)

Kosba, A.; Miller, A.; Shi, E.; Wen, Z.; and Papamanthou, C., 2016. Hawk: Theblockchain model of cryptography and privacy-preserving smart contracts. 2016IEEE Symposium on Security and Privacy (SP), (2016). doi:10.1109/sp.2016.55. (citedon page 5)

Lewenberg, Y.; Sompolinsky, Y.; and Zohar, A., 2015. Inclusive block chain pro-tocols. Financial Cryptography and Data Security, (2015), 528–547. doi:10.1007/978-3-662-47854-7_33. (cited on pages 5 and 9)

Miers, I.; Garman, C.; Green, M.; and Rubin, A. D., 2013. Zerocoin: Anonymousdistributed e-cash from bitcoin. 2013 IEEE Symposium on Security and Privacy, (2013).doi:10.1109/sp.2013.34. (cited on page 5)

Paul, E., 2017. What is digital signature- how it works, benefits, objectives, concept.http://www.emptrust.com/blog/benefits-of-using-digital-signatures. (cited on page 7)

Popov, S., 2018. The Tangle. https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf. Pre-sented on IOTA foundation website. (cited on pages 5, 9, 11, 13, and 17)

Reyna, A.; Martin, C.; Chen, J.; Soler, E.; and Diaz, M., 2018. On blockchain andits integration with iot. challenges and opportunities. Future Generation ComputerSystems, 88 (2018), 173–190. doi:10.1016/j.future.2018.05.046. (cited on page 4)

19

20 Bibliography

Sasson, E. B.; Chiesa, A.; Garman, C.; Green, M.; Miers, I.; Tromer, E.; and Virza,M., 2014. Zerocash: Decentralized anonymous payments from bitcoin. 2014 IEEESymposium on Security and Privacy, (2014). doi:10.1109/sp.2014.36. (cited on page 5)

Sompolinsky, Y. and Zohar, A., 2013. Accelerating bitcoin’s transaction processing.fast money grows on trees, not chains. IACR Cryptology ePrint Archive, 2013 (2013),881. (cited on page 5)

Statista, 2019. Internet of Things (IoT) connected devices installed base world-wide from 2015 to 2025 (in billions). https://www.statista.com/statistics/471264/iot-number-of-connected-devices-worldwide/. (cited on page 1)

Appendix A - Project description

In this project, the student will aim to create a fast responsive blockchain. Further-more, there will be communication to an Intel Edison via this network.The blockchain needs to be fast enough to transmit messages between the user andtheir device as well as responsive enough to show modification on this chain as soonas possible. The student will aim to analyse current cryptographic schemes, identifytrade-offs between security and speed, in practice and try to find a solution to in-crease security without trading it for speed.The student will need to submit a report detailing the following:1. Introduction to the problem.2. Previous Implementations.3. Technologies used in current implementation.4. Descriotion of the implementation in the project.5. An analysis of the efficiency and security of this method,6. Discussion for possible future work.

In addition, there will be a working prototype of blockchain-enabled IoT with detaileddocumentation.

21

22 Bibliography

Appendix B - Marking breakdown

Report is assessed for 45% of the overall mark and is evaluated by Professor AlwenTiu.Artefact is assessed for 45% of the overall mark and is evaluated by Professor SidChau.Presentation is assed for 10% of the overall mark and is evaluated by Professor WeifaLiang.

23

24 Bibliography

Appendix C - Software description

The software was programmed in the Go programming language. There is a singlefile submitted as part of this project titled main.go. This file has been entirely imple-mented by me with exception of the function makeBasicHost. It also uses the librarygo-libp2p which contains the P2P functions used and is opensource.As this code observes a simulation of the network; it is tested by printing theblockchain for all the nodes. This chain is found to be the same for all the nodesdenoting that consensus has been achieved.

25

26 Bibliography

Appendix D - README file

This project has been written in the Go programming language. Go can be installedfrom the link : https://golang.org/dl/

After installation and configuration, install the spew package using ‘go get github.com/davecgh/go-spew/spew‘. This package is used to print the Blockchain struct while checking thesoftware for errors.

Next, download the go-libp2p library using ‘go get -d github.com/libp2p/go-libp2p/...‘. This library holds the P2P libraries that are used in this project.

Navigate to the cloned directory above and create a directory under examplescalled p2p by using ‘mkdir ./examples/p2p‘.

Navigate to the new p2p folder and add the main.go file to it.

In your 1st terminal ‘go run main.go -secio -l 10000‘

Follow the instructions in your 1st terminal and copy and paste the given com-mand into your 2nd terminal e.g. ‘go run main.go -l 10001 -d /ip4/127.0.0.1/tcp/10000/ipfs/QmZ8NayvdXc2U2A1cwh9qGaHK7uxXXVrZQEYwDqbfFydfj-secio‘

Follow the instructions in your 2nd terminal and copy and paste the given com-mand into your 3rd terminal e.g. ‘go run main.go -l 10002 -d /ip4/127.0.0.1/tcp/10001/ipfs/QmRAj9JJVKRJmWHbDKzvzKDVVFPWxuWYio3bPym4SgGPgF-secio‘

Continue doing this for multiple terminals. The even numbered terminals (2nd,4th ...) behave as the IoT devices while the odd numbered terminals (1st, 3rd ...) actas the corresponding users.

27