A Approach for Negotiating Trust in IoT

by Skailer Knezevic

Bachelor of Science College of Engineering and Science Florida Institute of Technology 2017

A thesis submitted to the College of Engineering and Science at Florida Institute of Technology in partial fulfillment of the requirements for the degree of

Masters of Science in Information Assurance and Cybersecurity

Melbourne, Florida May, 2020 ⃝c Copyright 2020 Skailer Knezevic All Rights Reserved

The author grants permission to make single copies. We the undersigned committee hereby approve the attached thesis

A Blockchain Approach for Negotiating Trust in IoT by Skailer Knezevic

Heather Crawford, Ph.D. Assistant Professor Computer Engineering and Sciences Committee Chair

Andy Stanfield, Ph.D. Assistant Professor School of Arts and Communication Outside Committee Member

Bernard Parenteau, Ph.D. Assistant Professor Computer Engineering and Sciences Committee Member

Philip Bernhard, Ph.D. Associate Professor and Department Head Computer Engineering and Sciences ABSTRACT Title: A Blockchain Approach for Negotiating Trust in IoT Author: Skailer Knezevic Major Advisor: Heather Crawford, Ph.D.

“The internet is no longer a web that we connect to. Instead, its a computerized, networked, and interconnected world that we live in. This is the future, and what were calling the Internet of Things.”- Bruce Schneier, 2019

The Internet of Things is becoming a big part of our lives. Every year there are more devices with the capability to connect on the internet and communicate with each other. Today there are over 400 million IoT devices in the world, and this number is predicted to grow to 1.5 billion devices by 2022 [14]. It is becoming more difficult to manage all IoT devices and to know with which device to connect to request a service. In addition, a device can fail at some point or stop provid- ing a good service. There is a need to find a better way to store data about all transactions between devices to provide the basis for a way to establish the trust between devices. In this thesis, we propose a solution to use a blockchain in order to store transaction data and an algorithm that establishes trust between devices in the same network.

iii Table of Contents

Abstract iii

List of Figures vii

List of Tables ix

Acknowledgments x

1 Introduction 1 1.1 Problem Statement ...... 1 1.2 Proposed Solution ...... 2 1.3 Research Question ...... 3 1.4 Approach ...... 3 1.5 Organization of the Thesis ...... 4

2 Background 5 2.1 What is IoT? ...... 5 2.2 What is blockchain? ...... 7 2.2.1 Types ...... 11 2.2.2 Consensus ...... 13 2.2.3 Mining ...... 20

iv 2.3 Cryptographic Algorithms ...... 23 2.4 Use of Blockchain ...... 24 2.5 Some Existing ...... 25 2.5.1 IOTA ...... 25 2.5.2 Ripple ...... 27 2.5.3 Hyperledger Fabric ...... 28 2.5.4 ...... 31 2.5.5 Cosmos ...... 32 2.5.6 Characteristic Comparison ...... 34 2.6 IoT Blockchain Smart Homes ...... 34 2.7 Summary ...... 38

3 Approach 39 3.1 IOTA Tangle ...... 39 3.2 Hyperledger Fabric ...... 43 3.2.1 Scenarios ...... 45 3.2.1.1 Scenario 1 ...... 45 3.2.1.2 Scenario 2 ...... 46 3.2.2 Algorithm and Code ...... 47 3.2.2.1 Blockchain Code ...... 47 3.2.2.2 Connecting with Hyperledger ...... 48 3.2.2.3 Algorithm for Establishing Trust ...... 48 3.2.2.4 Blockchain Structure ...... 51 3.3 Summary ...... 53

v 4 Experiments 55 4.1 Experimental Design ...... 55 4.2 Scenario 1 ...... 57 4.3 Scenario 2 ...... 58 4.4 Experiments ...... 59 4.4.1 What devices can provide a specific service? ...... 59 4.4.2 Which device is the best? ...... 60 4.4.3 New devices wants to provide a service? ...... 61 4.4.4 Service is provided- show transaction ...... 61 4.5 Summary ...... 62

5 Conclusion 64 5.1 Findings ...... 64 5.2 Results ...... 65 5.3 Future Work ...... 65 5.4 Revisit ...... 66

References 68

Appendix Scoring Trust 79

vi List of Figures

2.1 Merkle Tree ...... 9 2.2 SHA256 Hashing ...... 10 2.3 Cryptographic Puzzle Target ...... 14 2.4 Blockchain Attack ...... 16 2.5 Mining Power Diagram ...... 22 2.6 Hyperledger Fabric Connections ...... 29 2.7 Hyperledger Fabric Trade ...... 30

3.1 IOTA Layer Calculator ...... 41 3.2 Compass Seed ...... 42 3.3 Tangle JSON configuration ...... 42 3.4 IRI Node ...... 43 3.5 JavaScript File ...... 48 3.6 Hyperledger Fabric Blockchain ...... 51 3.7 Hyperledger Fabric Block ...... 52

4.1 New Device ...... 56 4.2 Transaction ...... 57 4.3 Adding New Device ...... 58 4.4 Service Providers ...... 59 4.5 Service Providers 2 ...... 60

vii 4.6 Device Recommendation ...... 60 4.7 Transaction ...... 61

viii List of Tables

2.1 Comparison of blockchains ...... 34

3.1 Connection Points Distribution ...... 49 3.2 Last Connection Points ...... 50 3.3 Device Make Points ...... 50

4.1 Querying Speed ...... 62

ix Acknowledgements

I am extremely grateful to my advisor Dr. H. Crawford for guiding me through the whole process of writing this thesis. Her constructive criticism, insightful sug- gestions, and relentless support helped me to work hard to reach my goals. She motivated me to do better and never give up.

I would like to extend my sincere thanks to my committee members Dr. A. Stan- field and Dr. B. Parenteau for their time and insightful comments.

I would like to acknowledge the help of my colleague Ghassen Kilani for giving me valuable advice on doing academic research and suggesting a few research pa- pers that were referenced in this thesis.

I would like to thank my parents and my brother on encouraging me to pursue my graduate degree.

I would also like to extend my gratitude to my friend William Wilson for his profound belief in my abilities and keeping me motivated in moments when I was doubting myself.

x Chapter 1

Introduction

1.1 Problem Statement

There are around 400 million IoT devices today [9], and even smaller networks can have tens or hundreds of devices. Although the traditional database can store data about IoT devices and their transactions, designing a database to keep track of all transactions can be challenging with a large number of devices. In addition, tra- ditional databases are often susceptible to attacks such as SQL injection, denial of service (DOS), and privilege escalation, where an attacker can permanently change or delete data inside the database [32]. With the invention of blockchain in 2008 [54], the possibility of storing data differently than in the traditional database and making the data immutable emerged. By making the data immutable, Bitcoin has for a goal to preserve the integrity of data.

Another issue that emerged with a large number of IoT devices is that it is hard to know which device to trust in the network. It gets increasingly hard to know

1 from which device to request the service or exchange information. There is an assumption that devices that are connecting trust each other, and often when a new device joins the network and tries to request a service, a requester is presented with multiple options, but a little to no information about the device from which it is requesting a service. Usually, a requester can only see the names of other devices that network admin or owners of that device gave to it, and it can be changed. Another issue is when there are multiple devices that provide the same service, it is hard to pick which one to use. Therefore, there is a need for a solution that can store data about every transaction and allow devices to use that data in making a decision from which device to request a service, and the data needs to be resistant to cyber-attacks.

1.2 Proposed Solution

Often blockchains that are used for IoT devices have only functionality to record transactions between devices and store them in a blockchain. We propose using a blockchain for storing information about devices and transactions between devices and using the data for negotiation of the trust between devices. Our solution allows the requester to query data from a blockchain about another device such as which devices provide the service that device needs. What device among those devices is most trustworthy? This solution will help devices to decide which device they can trust the most. This will also allow devices to choose between multiple service providers.

2 1.3 Research Question

In this thesis, we answer to what degree we can store and retrieve information about IoT devices on a blockchain. Can this information be used to answer such as how frequently does one device provide the requested service? How often that device provides a service to the requester? Can a new device that is entering the IoT space provide or request a service?

1.4 Approach

We use a blockchain called Hyperledger Fabric to store device and transaction data on a blockchain. Our algorithm takes into account the number of times that device provided any service as well as how many times that device provided the requested service. The algorithm also checks for the number of times the device provided service to the requester. Furthermore, the last time the device provided this service as well as year when the device was made and hardware requirements checks. All devices are scored based on those parameters, and the device with the highest score is suggested as the recommended device. In case that there is more than one device with the same score, the device with a higher number of transactions is suggested. Thus, our approach provides a method by which devices can search for devices that provide the service that they need. In addition, our solution recommends a device that is the most trustworthy based on the number of times that device provided services to other devices and requester. Our solution also checks for a type of hardware that each device has and a year when that device was manufactured.

3 1.5 Organization of the Thesis

Chapter 2: This chapter provides brief background on Internet of Things and blockchain technology. It explains different types of blockchains and consensus protocols, what is mining, and how it works. There is also discussion about cryp- tography algorithms and how are they used in blockchain. The chapter covers some existing blockchains and how blockchain can be used in smart homes.

Chapter 3: This chapter covers the approach that we took to establish trust be- tween devices. It provides insight on using IOTA and issues that we faced and explains how to set up Hyperledger Fabrics and our approach in developing the algorithm for establishing the trust between IoT devices.

Chapter 4: This chapter explains and shows the results of experiments that were conduced using Hyperledger Fabrics.

Chapter 5: This chapter summarizes findings and talks about some of downsides of using the blockchain.

4 Chapter 2

Background

2.1 What is IoT?

The term “Internet of Things (IoT)” was coined in 1999 by Kevin Ashton for sup- ply chain management. He defined IoT as a network connecting objects inthe physical world to the Internet [34]. However, with technological advances, more definitions have been coined in the past few years to include more applications for IoT, definitions that include a variety of uses such as transportation and healthcare. Gubbi et al. define IoT as a network of objects that harvest information between the environment and physical world and also provides data transfer analytics and communication [34]. This is where objects are devices that use radio frequency identification (RFID), Wi-Fi, Bluetooth, or other communication technologies to exchange information between each other [34]. Another definition comes from the Cluster of European research projects; they define IoT as Things that are actively participating in information sharing, social processes, and business [74]. During this process, they can interact with the environment and other devices and ex-

5 change information between each other [74]. Utilities, appliances, and sensors for air-quality monitoring are some of examples of Things. While Forrester [19] de- fines IoT as a smart environment that is used for public services, healthcare, and transportation. IoT makes infrastructures that are aware of their environment and can interact with it, and the whole system is more efficient timewise [19].

Gubbi et al. categorize IoT in four main categories: Personal and Homes, En- terprise, Utilities, and Mobile devices [34]. Personal and Homes IoT information is only available to an individual or household members or in the healthcare ap- plications for caretakers. In an enterprise environment, the data is available to owners of the data and can be selectively released to third parties. When IoT is used for utilities, the information is usually used for service optimization and not for clients. Gubbi et al. refer to smart transportation and logistics as mobile IoT services [34]. Sensors can be used for predicting traffic delays and measuring air pollution. Another branching of IoT on different types was done by Atzori et al., they divide IoT in three different paradigms: Internet oriented in sense of middle- ware, things oriented as sensors, and semantic oriented as knowledge [17].

In this thesis, we will use term IoT as network/system of static and mobile devices with ability to communicate with each other as it was mentioned in Gubbi et al. [34]. However, we will use the term mobile devices for devices with ability to move from network to network, such as smart phones and laptops.

According to Gubbi et al., IoT become common in 2011 and by 2013 there were 9 billion devices with Internet connectivity; that number is expected to reach 24

6 billion by the end of 2020 [34]. With the number of IoT devices rising each year, the amount of data that needs to be processed, limited processing capabilities of the most IoT devices, and heterogeneity of devices in the same network become increasingly difficult. Often devices in the same network use different network protocols and communication methods. Even when there are set standards for communication, there is a possibility that one device will have multiple options for communication and data exchange with other devices. There is a need to find better ways to store and analyze data that is being exchanged to solve those prob- lems [75].

IoT is used for connecting people and computer devices, as well as objects. One example that Gubbi et al. [34] gave is where IoT can connect people in medical field professions with patient data , where a patient has a device that measures vital signs, and the data is sent to a doctor. Doctors are able to monitor the data in real time and react to the patient’s symptoms. This can reduce hospitalization costs by detecting symptoms early and intervening before a patient’s condition worsens [34]. Also, it can reduce the number of doctor visits needed and alert medical personnel in case of emergency so that a patient can get medical attention on the time.

2.2 What is blockchain?

There are a lot of different types of blockchain technologies. In this section we will discuss Bitcoin’s blockchain.IOTA will be explained in the section 2.5.1, Ripple in the section 2.5.2, Hyperledger Fabric in the section 2.5.3, Etherium in the section

7 2.5.4, and Cosmos in the section 2.5.5.

Blockchain is a technology that stores data inside blocks. Blocks are files that contain transaction data that is permanently stored there. This data includes a block-size, a block-header, a counter, as well as the list of transactions. Each block contains a cryptographic hash of the previous block. Bitcoin was the first implementation of a blockchain, and it was created by a person or persons using the pseudonym of Satoshi Nakamoto. In January 2008, a white paper [54] was published under that name. Nakamoto claimed to be a man from Japan; however, there are suspicions that the English in the paper [54] is too good and that who- ever wrote the paper is a native English speaker. There is also speculation that the system is built so well that it would not be possible for one person to build it. Also, some suggested that Samsung, Toshiba, Nakamichi, and Motorola built it together [44]. The name Satoshi Nakamoto might be the acronym for those four companies by taking a few letters of each name (Sa-Toshi Naka-Moto) [44]. Another theory is that the Australian computer scientist and entrepreneur, Craig Wright, used the alias Satoshi Nakamoto. As evidence, he provided the cryptographic key that was used in the first Bitcoin transactions between Satoshi and Hal Finney in 2009 [65].

Blockchain is used as a public ledger for Bitcoin transactions [54]. The digital ledger is used for storing transactions. In general, a transaction represents an event that was validated and stored inside a blockchain [54]. For instance, send- ing to another user can be considered as a transaction. When it comes to Bitcoin, each coin is represented as a chain of digital signatures; each owner adds their digital signature of the previous transaction and a public key

8 of the new owner on the end of the coin. Transferring cryptocurrency to other users represents a transaction in Bitcoin blockchain; the first transaction made in Bitcoin blockchain was a transaction between Satoshi and Hal Finney in 2009 [59]. However, a transaction can vary from blockchain to blockchain, depending on the purpose of the blockchain. Financial blockchains usually keep money/cryp- tocurrency transactions; in contrast, a blockchain that is used in health care may keep patient records. It uses public-key for transaction verification by confirming that the digital signature came from an owner’s private key.The data is stored on a distributed ledger, and each ledger contains a linked block that forms a blockchain [41].

Figure 2.1: Merkle Tree – This figure shows a Markle Tree structure for one block in the blockchain. In this graph, four different text inputs are hashes in four different hash values, and then values are appended and hashed into parent nodes until the root. The root contains the hash values of all children. Based on [1].

Each block holds hashed and encoded data inside a Merkle tree structure. A merkel tree strusture is shown in Figure 2.1. In a Merkle tree, every left node of the tree is labeled with hashes of the data block, and right nodes of the tree con- tain the labels of cryptographic hashes of its child nodes. A hash algorithm takes

9 the transaction data and converts it into an alphanumeric string of predetermined length (number of bits) [66]; the output is called a hash or message digest. The most commonly used hash algorithm is SHA-256 [29]. SHA-256 is an algorithm that was designed by the United States National Security Agency (NSA) [58], and Bitcoin protocol uses it for creation of private keys and for mining [54]. This hash- ing algorithm was chosen because of the randomness of the hash, meaning that by changing one character, the hash is going to completely change. The randomness of SHA-256 is shown in Figure 2.2. There are other hashing algorithms that are used in blockchains, for example, Darkcoin protocol uses X11 hashing algorithm that was developed by Evan Duffield in 2014 [27].

Figure 2.2: SHA–256 Hashing – The image shows that when we add one character to message/text, the hash output completely changes, and cannot be correlated with first hash. In the image we added only ‘A’ on the end, and hash that wegot as output cannot be correlated with previous hash output [4].

The Merkle tree is used for authentication and digital signatures with crypto- graphic functions. There are two main kinds of Merkle trees: Complete binary

10 trees and infinite trees of one-time signatures. In a complete binary tree, the value of the parent node is a one-way function of values of its children. In a tree that uses digital signatures with cryptographic functions, each node contains verifica- tion parameters that are used for signing messages and for the verification of the children of that node [78].

2.2.1 Types

There are two types of blockchain networks: Permissionless and permissioned. Permissionless blockchains, also called public, allow all nodes in a network to participate, while permissioned blockchains allow only a certain set of nodes to participate as validators/miners. Permissionless blockchain allows everyone to par- ticipate, which helps with preserving the anonymity of participants. Anonymity is often preserved by using a public address, public and private keys that are not directly linked to the user’s identity [54]. Bitcoin is an example of a permissionless blockchain where anyone can become a miner or exchange . Permissioned blockchain offers decentralization, but it also limits who can participate. Some permissioned blockchains allow anyone who registers to participate such as Ripple [67], while others allow only approved members, often only members inside an orga- nization. Permissioned blockchains are sometimes referred as private blockchains. Ripple is considered as hybrid premissioned blockchain because anyone can par- ticipate. However, some validators act as a central authority. Validators are often selected by the network as trusted nodes, and not everyone can become a validator. Also, there are public blockchains such as Ethereum, that allow users to make their own private blockchain. Private blockchains are used mostly inside corporations and households where the data is not publicly shared.

11 Most blockchain technologies have immutable records, anonymity, and real-time record updates [68]. In contrast to the traditional database storage that requires a central authority, an administrator for “quality” control, blockchain does not require a central authority and can be completely decentralized. Even in the case of disagreement, blockchains have algorithms that resolve disagreements without the need for an authority to step in. These resolution protocols are often in- cluded inside consensus protocol, and they often resolve two types of disagree- ments: disagreement about the data inside a block and disagreement about blocks in a blockchain. Decentralization eliminates having a single point of failure, which affects availability of the data. When availability is affected, users are notableto access the data when needed.

Another security improvement that blockchain adds is that data cannot be easily changed, which protects the integrity of that data [68]. The blockchain is also designed to prevent double-spending. Double-spending is a flaw in the system that allows users to spend the same digital cash more than once. Each coin in a blockchain is represented as a chain of digital signatures. Each owner trans- fers a coin by digitally signing a hash. A receiver can only verify ownership of coins using their digital signature; however, they cannot check if coins are double- spent. The typical solution involves having a central authority that checks for double-spending. This solution gives full trust to a single entity. To achieve this without a trusted party, Nakamoto [54] proposed the idea of a system where all transactions are publicly announced, and participants need to agree on a order in which transactions are received. All transactions are timestamped by the server,

12 and server broadcasts transactions to all participants in the blockchain [54]. By having participants to agree on the order of transactions, Bitcoin tries to eliminate double-spending. This agreement is also called consensus.

2.2.2 Consensus

A consensus protocol represents agreement between devices/nodes/users across a distributed network. In public blockchain, everyone can submit information; it is important that information submitted is confirmed by the network, and after that added to the agreed block. The data needs to be confirmed because blockchain uses an immutable ledger, and data added there cannot be edited later, meaning errors are permanent. Nodes in the network need to come to an agreement on the same state of a blockchain called consensus, creating a self-auditing system. If agreement is not reached, that block will be rejected and will not be added to the chain. This process requires that every entity has two cryptographic key functions: a private key used for signatures and a public key used for verification. Consensus takes care of integrity of the blockchain, as well as making sure that no single entity can control the blockchain [54].

Before a new block is added to the blockchain, there are a series of checks that are done to make sure that a new block is valid. Each new block needs to contain a hash value of the previous block. Another criteria for a block to be valid is that the hash value of that block needs to be an under-targeted hexadecimal value. The targeted hexadecimal value is a predetermined value, and any hexadecimal number that is lower or equals to the targeted number is considered under the target. That is achieved by changing a nonce, which is further discussed in section

13 Figure 2.3: Cryptographic Puzzle Target – This diagram shows an example of cryptographic puzzle, where miners need to calculate a hash value that is below the target line in order to solve a puzzle [23]. The number next to the target line would be considered as one of the correct solutions. Additionally, the value of the hash number of X above word smallest is also considered as a solution to the puzzle.

2.2.3. There is a possibility that two different blocks are added at the same time to the different parts of the network on the same blockchain. This occurrence is called competing chains (forking), and resolution is done by continuing until one part of the network adds the next block before others. When that block is added, the whole network will be updated according to a part of network that has the longest blockchain. This is the same branch to which a new block is added. In addition to making sure that blocks that are added are valid, digital signatures are used to validate users and prevent double-spending in case of blockchains that use crypto-currencies. Double-spending is prevented by time-stamping transactions, broadcasting them to all nodes, which makes transactions irreversible. [54].

In , miners try to calculate a hash value of the header to validate data. PoW is mostly associated with public blockchains where everyone can par-

14 ticipate. The PoW in Bitcoin involves scanning values whose hash begins with a set number of zero bits. Figure 2.3 shows hashes with a targeted number of leading zeros. The work gets exponentially more CPU demanding, which is explained in section 2.2.3. Also, in order for the attacker to change something inside one block, the attacker must recompute the hashes of that block and all blocks after it. The reason why an attacker needs to change all blocks after the block that they are attacking is that each new block contains the hash value of the previous one, and in order for the blockchain to not be broken, all blocks need to have correct hash values [54]. Figure 2.4 (a) and Figure 2.4 (b) show how a blockchain becomes broken when an attacker tries to change the data inside one of the blocks. An alternative to PoW is Proof-of-Burn (PoB) in which miners burn some cryptocur- rency through an unspendable address [29]. The unspendable address is an address that is randomly generated and does not contain a private key. Without a private key, coins sent to that address cannot be accessed or spent. Proof-of-Personhood (PoP) and Proof-of-Individuality (PoI) are consensus methods that have a goal to preserve anonymity. Anonymity is preserved by binding these two identities to create PoP-tokens, which are used as anonymous credentials [46]. PoP is a consensus method that uses ring signatures and collective signing to bind physical and virtual identities. PoI is very similar to PoP, and it is being developed by Ethereum [29].

In Proof-of-Stake (PoS), the blockchain assumes that participants with more stake are less likely to attack the network [29]. It requires participants to prove peri- odically that they own a certain amount of wealth, which is usually measured in number of coins. Because it gives more power to the wealthiest users, this method

15 (a) Blockchain during an attack

(b) Blockchain after the attack Figure 2.4: (a) An attacker changes the data in one of the existing blocks in the blockchain. (b) After changing data in desired block, that block and all succeeding blocks are going to have invalid hashes [23]. is considered unfair by some [29]. There are variations where participants with older accounts have the most power. Sometimes wealth and account age are com- bined together to decide which users have the most power. Another variation of PoS is called Transaction as Proof-of-Stake (TPoS) where all nodes that generate transactions participate in the consensus. PoS does not involve a mining process where miners compete for a reward; instead, the block is chosen from a pool of users that staked a certain amount of cryptocurrency; because of that PoS is con- sidered as energy saving compared to PoW [80]. Miners who stake an amount and do not win will not lose their stake. However, miners who act maliciously will lose their stakes, and that network will trust them less. Staking is similar to putting money in a safe. After staking, users are picked randomly to avoid the richest one always winning; however, those who do not get picked will not lose their coins.

Delegated Proof-of-Stake (DPoS) is similar to PoS; the biggest difference is that instead of all participants with highest stake participating in voting, they pick del-

16 egates who can vote, which makes the voting process faster. In addition, delegates can adjust the size of blocks and intervals. If it is found that some delegates are dishonest, they can be replaced. Usually replacement is done once a day or week, depending on the blockchain. Before dishonest delegates are replaced, they are skipped during voting [29].

Proof-of-Activity (PoA) takes the idea of PoS based on the age, and in addition takes into account how active is each user, making stakeholders that are inac- tive less powerful. The age is based on the date when account is created. The idea is based on Proof-of-Stake-Velocity of Reddcoin, where members with most exchanges/money flows have more power [29]. Proof-of-Activity (PoA) was pro- posed to eliminate the unfairness of PoS, which in some cases gives more power to passive users who happen to have more stake. PoA takes in account both owner- ship and activity in the blockchain [20]. Reddcoin uses a similar approach to PoA, which uses velocity of currency, meaning how many times currency flows through an economy and a number of times it is used by members. This algorithm is called Proof-of-Stake-Velocity (PoSV) [63]. This is similar to a churn rate in the peer-to- peer network, where churn rate measures participant turnover [72].

Reaching agreement in the blockchain can be dealt with using different algorithms. One of most commonly used algorithms for agreement in the blockchain is Practi- cal Byzantine Fault Tolerance (PBFT). PBFT is based on the Byzantine General Problem (BGP). The BGP deals with the failures in the system, where some com- ponents may send conflicting information. This problem is based on a fictional story of the Byzantine army that needs to decide if they want to attack enemy or

17 retreat. The army is split in divisions, and each division is led by a general. The generals can communicate with each other through a person who is a messenger. The issue is that some generals can be traitors. The loyal generals are always going to send correct information, while traitors send conflicting information. This al- gorithm tries to ensure that a small number of traitors cannot cause loyal generals to make a bad decision [43].

Bitcoin protocol uses Byzantines Fault Tolerance where it is assumed that at least 2/3 of all nodes are good nodes and that only one third can be malicious. Before a new block is added to the blockchain, the leader is assigned to be in charge of the transaction. Where nodes are generals in the Byzantine General Problem story, malicious nodes are traitors, and the network is a messenger. If over 2/3 of nodes that are known by the network agree (vote for), that block is added to the blockchain. Similar to DPoS, there is Delegate Byzantine Fault Tolerance (DBFT) where some nodes are voted to generate and validate blocks. Tendermint Consensus Protocol also uses Byzantine’s fault tolerance [21] where each node has a non-negative weight that represents the voting power. The nodes with the highest voting power are called validators, and they participate in consensus protocol by broadcasting the cryptographic signatures or votes. Federated Byzantine Agree- ment (FBA) is very similar to PBFT. However, the network is aware of nodes that are considered trusted, and rather than waiting for all trusted and untasted nodes to vote, the transaction gets accepted after majority of trusted nodes voted and reached the consensus [47]. It is used by Stellar Consensus Protocol (SCP), which is used in environments with low computing power.

18 Ripple developed an algorithm called Ripple Protocol Consensus Algorithm (RPCA), and it is applied every few seconds in order to maintain the correctness of the blockchain [67]. Initially, each server takes valid transactions that have not been applied and makes them public. Then during the voting process where servers vote about the validity of transactions. If there are multiple rounds, transactions that get the minimum number of required “yes” responses are going to be passed to the next round. Transactions that did not meet the required percentage of “yes” votes will be either discarded or put for consideration when transactions are being added to the ledger. In the final round, at least 80% of nodes need to agreeto create a consensus [67].

Hyperledger-Fabric is a system that uses a permissioned blockchain. It is a dis- tributed ledger that uses a to distribute trust between parties. A smart contract is used to enforce trust between the parties by having an immutable ledger and allowing users to retrieve all their records. In addition, Hyperledger- Fabric is resilient to the 51% attack because there is no mining involved. A 51% attack is an attack where an attacker is able to gain a majority of power in the blockchain [77]. The attacker that gains 51% of power or more can control trans- actions and even be able to reverse some transactions. Hyperledger-Fabric has two types of nodes, peer nodes that execute and verify transactions, and ordering nodes that order and propagate transactions. Consensus protocol works similarly to BFT. However, it allows network owners to chose a consensus mechanism based on their needs [29, 70].

19 2.2.3 Mining

Mining is the process by which a new transaction record is added to the blockchain. This process is done by nodes that are known as miners, where nodes are actual computers used to solve tasks associated with mining such as finding an integer that combined with data in a block gives a hash value below predetermined thresh- old. Hash values with leading zero bits were explained in section 2.2. Miners try to solve a complex problem that usually requires high computing power. A com- plex problem often involves guessing a nonce, numbers that combined with the new block’s data give a hash value with a predetermined number of leading zeros. Leading zeroes are the number of zeros in front of a hexadecimal number with a certain number of characters/bytes. The miner who first solves the problem gets a reward, usually in the form of cryptocurrency coins or tokens. There is a transac- tion fee that users pay to transfer coins; that fee is given as a reward to the miner who solves the puzzle first.

With time, mining puzzles become exponentially more complex, and they require more computational resources in order to be solved in the same amount of time. This is done by making targeted hash values smaller, which makes mining for the nonce that will produce a hash value in that range harder. Bitcoin went through four generations of the hardware [35]. Early on, the miners were able to mine with their personal computers using the Central Processing Unit (CPU). In 2010, miners started using the Graphics Processing Unit (GPU). The GPU can solve complex graphics calculations with lots of parallelism, offering higher hash rates and bet- ter energy efficiency than CPU [35]. When the GPU became commonly usedby miners, some miners started using Field Programmable Gate Arrays (FPGAs) in

20 2011. The FPGA allows the users to configurate and program circuits, which al- lows them to modify them for mining purposes. By changing the configuration of FPGA, users can lower power consumption and increase the number of attempts per second to solve a puzzle [35]. The fourth generation is called Application- Specific Integrated Circuits (ASICs), which appeared in 2013. The ASIC hasa dedicated circuit optimized for performing hashing computations more efficiently. When it comes to the energy cost of a mining process, it is hard to tell exact num- bers, and opinion is split [35]. It ranges from electricity produced by a small power plant to the electricity consumption of a small country [45, 48, 56]. According to MIT Center for Energy and Environmental Policy Research (CEEPR), the annual energy consumption of Bitcoin mining is between 35.0 TW-h (terawatt-hours) and 72.7 TWh [71]. Stoll et al. estimated that between November 2017 and November 2018, electricity consumption was around 48.2TWh for Bitcoin mining [71]. This equates to the energy consumption of the Czech Republic, a country with a pop- ulation of 10.6 million [36].

Figure 2.5 shows how power usage of the in watts changed from 2011 through 2016 for all four generations of hardware. As shown on the graph, there is exponential growth for each type of hardware, where newer generations of hardware consume less electricity. Although the amount of power that a newer generation of hardware consumes is lower comparing to older generations, ASIC still consumes a lot of electric power.

21 Figure 2.5: Mining Power Diagram – Estimated power usage of bitcoin network for different hardware between 2011 and 2017 [35].

There is criticism that Proof-of-Work (PoW) when applied to Bitcoin wastes energy without doing any useful tasks. However, some crypto-currencies created more meaningful tasks. One of the examples is Primecoin that uses computation of long chains of prime numbers, also known as Cunningham chains, as the task for miners [39]. Because cryptography is often dependent on prime numbers, Cunningham chains can be used in public key cryptography as it was proposed by Young at al. [79]. Another more meaningful PoW was proposed by NooShare, where PoW is used for Monte-Carlo simulations [35]. This type of mining has a real world application, and in a case of Monte-Carlo simulation, it is used as an important tool for Bayesian reasoning [69]. When it comes to mining, the main concern is how raised electricity consumption is going to affect our environment and is it going to have an impact on the climate change. The time that takes for adding a new block in Bitcoin to the blockchain can be between 10 minutes and 1 hour. This delay

22 makes Bitcoin’s technology use limited and not suitable for real time transactions. It is estimated that energy consumed for adding one block to Bitcoin’s blockchain is equivalent to the energy that the average household consumes in a week [36].

2.3 Cryptographic Algorithms

Public–key cryptography is an important component of any blockchain [29]. Public- keys are used in blockchain to create digital signatures of users. They are often a 27 to 32 characters strings that are used to send /data without re- vealing the user’s true identity. The most common cryptographic algorithms used are (Rivest-Shamir-Adleman) RSA and Elliptic Curve Diffie-Hellman Exchange (ECDHE), which are recommended by National Institute of Standards and Tech- nology (NIST) [29, 73]. However, taking into consideration that the minimum recommended RSA [73] key size is 2048-bits and the limited computing power of IoT devices, using RSA is not the best option. Smaller RSA key sizes such as 512 and 768 bits are considered less secure and can be broken with current classical computers. While RSA 1028-bits remains unbroken currently, it is considered less secure than RSA 2048-bits and 4096-bits for applications that use digital signa- tures. During performance measurement for IoT devices public-key cryptography, Elliptic Curve Cryptography (ECC) gave better results, outperforming RSA based on time that is needed for encryption and decryption [29, 50]. One of the advan- tages of ECC is that when used with a key of 256 bits, it is as secure as RSA with a 3072 bit key [50].

In addition to encryption, hash functions are often included in a blockchain sys-

23 tem. Commonly used hash functions are SHA-256, SHA-256d, and . When it comes to the IoT devices, researchers are always trying to find less power in- tensive methods. One recommendation is to use Advanced Encryption Standard (AES), which consumes very little power [28]. The reason why AES consumes less power is that it only needs 10 rounds for 128-bit keys and 14 rounds for 256- bit keys, while SHA-1 needs to perform 80 rounds, and SHA-256 needs 64 or 80 rounds [37, 64]. Each round consists of operations/ steps such as substitution, transposition, mixing and XORing.

2.4 Use of Blockchain

Blockchain is often used for cryptocurrencies; however, that is not the sole pur- pose of blockchain. Blockchain can be used in banking, by government, security, for medical records, smart homes and IoT devices. Tracking high value items in supply chains can be done using blockchain [41]. Kshetri [41] mentions IBMs Watson platform with the capability of using blockchain for IoT devices. The author[41] also puts importance on the immutability of the data because it can prevent manipulation with the data and preserve its integrity. One of the exam- ples that the author [41] gave is water in Flint, Michigan, where if data from water quality sensors were stored on a blockchain, it would be impossible to manipulate with it, and the public would be aware from beginning about the poor quality of water. In the cases like this one, it is important that the original information is correct. Blockchain might be able to make IoT more secure. In case of combining and big data for carrying autonomous transactions byusing smart contracts, it might have a great impact on security by making data im-

24 mutable and always available without a single point of failure. Another benefit of using decentralized technology is that instead of communicating with the central unit that might be further away from IoT devices, devices can communicate with nearby devices [41].

2.5 Some Existing Blockchains

2.5.1 IOTA

The IOTA protocol is a commonly used blockchain protocol for IoT devices. It has a different approach than most distributed ledger technologies. Instead ofthe blockchain it uses Directed Acyclic Graphs (DAG), also called the Tangle [61]. The DAG is a type of a graph whose links have direction, and they are called acyclic because there are no loops inside the structure, meaning that links cannot be bidirectional. The nodes that hold transactions are called sites, and links are called edges. The rule is that a site is connected to at least two other sites by in- coming edges, and sites that do not have more than two incoming edges are called unconfirmed and are usually positioned on the end, which is called the tipofthe tangle [61]. An incoming edge is an edge through which one site sends information to another site. A new transaction is attached to two sites that are valid. The selection of sites is done by using a Markov Chain Monte Carlo algorithm to avoid favoring sites of one user. Each site has two values that are used to measure its trust levels. The first one is very similar to the PoA, and it is a number oftrans- actions performed by the site. The second one is the total sum of transactions performed by that site and sums of sites that are connected with that site with incoming edges [61].

25 One of issues with IOTA is that when the Tangle does not have enough sites, it requires a bootstrap process called the coordinator to approve initial transac- tions. When the ledger gets large enough the coordinator is no longer used because there are enough sites and edges to evaluate trust [61]. In the contrast to the most ledger technologies, IOTA becomes faster as it grows faster. Pros of using IOTA for negotiating trust in IoT Networks are as follows:

1. It is designed for IoT, taking into account that most IoT devices do not have high speed processors and might have limited power life.

2. There is no need for transaction fees and miners. Miners are replaced by nodes in DAG which are in charge of confirming new transactions. IOTA was created to try to solve issues that Bitcoin and Ethereum have, which are high fees for small tasks.

3. IOTA can process more transaction than most other technologies. IOTA does not have miners, instead users participate in confirming each others transac- tions. With more users, IOTA network becomes more scalable, allowing it to process more transactions each second.

Cons of using IOTA for negotiating trust in IoT Networks are as follows:

1. IOTA requires Coordinator at the beginning, which makes it centralized dur- ing that time.

2. It is still slow because there are only around 10 transactions requests per second, which makes waiting time for processing transaction a few minutes.

26 If it grows to have 10,000 transactions per second, it will take only a few seconds to process all transactions.

2.5.2 Ripple

Ripple is a technology that is designed for banks. In contrast to standard blockchain technology where the data is stored in blocks, Ripple stores the data in a large list (Ripple runs on a network server and uses the ledger to share the data between servers) [67]. Every node maintains the copy of that list. It uses an algorithm based on Federated Byzantine Fault Tolerance where only validator nodes can vote; however, it requires 80% of nodes to agree. XRP crypto currency used by Ripple is burned after it is used and it cannot be reused, meaning that after each transaction there is less and less XRPs. It takes only 3-5 seconds to send XRP, which compared to Bitcoin cryptocurrencies is very fast. Ripple has gateways, businesses that act like exchanges, allowing money and other forms of value to move in and out of the XRP ledger. Ripple has the power to freeze the balances of account holders; this is considered controversial for a decentralized system [67]. Even though freezing accounts of malicious account holders help with the security of the blockchain, some people think that all cryptocurrencies should be decentral- ized and that everyone should be able to participate.

Beside XRP, a native currency in the Ripple network, there are IOU tokens that can be issued by anyone, but only if the user trusts the person/organization who issued them can actually redeem the IOU (IOU is non-volatile) [67]. Pros of using Ripple for negotiating trust in IoT Networks are as follows:

1. Ripple has fast transactions (3-5 seconds).

27 2. Freezing balances can be reimplemented for freezing users access in case that user acts maliciously.

3. Mining is eliminated.

4. It uses tokens that can be implemented similar to Kerberos Authentication Protocol.

Cons of using Ripple for negotiating trust in IoT Networks are as follows:

1. Ripple does not use blockchain, it uses the list type of structure. Even though Ripple’s structure is more list-based, it has digital signatures.

2. It is more bank and money oriented, not suitable for IoT.

2.5.3 Hyperledger Fabric

Hyperledger Fabric was developed by IBM and later transferred to Linux Foun- dation to continue with the development as an open source project. Because per- missioned blockchains have issues with scalability because they require every peer to execute transaction which causes a lot of issues with privacy [16]. Hyperledger Fabric tries to solve this problem with peers by splitting them in the three groups [endorser, committer],[consenter]. When a peer is in charge of committing trans- actions, that peer is called committer. Some peers are also in charge of executing the smart contract and they are called endorsers. One peer can have both roles, committing some types of transactions while endorsing others. The consenters are in charge of verifying the exchange of assets between two or more parties. Fabric V1 is a private blockchain: it handles transactions in a way where only entities that are part of the deal can see that transaction. No one else should be able to

28 see the private transaction. Both peers need to render the same result. In the validations where there are more than two parties, other rules may apply. There are multiple entities involved, but details do not need to be disclosed to everyone. Assets are represented as a collection of key-value pairs, and if the state changes, it gets recorded as transaction [16]. This is shown and futher explained in Figures 2.6 and 2.7.

Figure 2.6: Hyperledger Fabric Connections – This image shows an example of Hyperledger Fabric where one user (Market) has an organic market and another user (Radish farm) has a farm where they grow radishes. They are in a blockchain that supports transactions between multiple different market participants: growers, shippers, banks, markets etc. The radish farm can sell their radishes to the Market at a lower price without rest of their buyers knowing about this deal. That is possible because Hyperledger Fabric does not allow parties that are not a part of the deal to execute someone’s else agreement [62].

Pros of using Hyperledger Fabric for negotiating trust in IoT Networks are as follows:

1. Hyperledger Fabric has a modular design; it can be suited for different needs.

2. It is designed to enforce trust between entities that do not trust each other.

29 3. It allows sharing information with multiple entities without disclosing sensi- tive information to everyone.

4. Hyperledger Fabric does not use cryptocurrency.

5. Even the network is permissioned, a transaction can still be private (but participants are not anonymous).

Figure 2.7: Hyperledger Fabric Trade – The application that the Market uses looks for identity of the Radish Farm, and sends transactions only to their peers. Then their peers generate results. This image shows two party agreement, and in this case both parties need to render the same result. After which both parties send the validated transaction to the application, and the application sends it to consensus cloud. From there that transaction is sent to the peers and committed to the ledger. In the case that there are more than two parties, rules may vary [62].

Cons of using Hyperledger Fabric for negotiating trust in IoT Networks are as follows:

1. It is a permissioned network where all participants have known identities. In systems where anonymity is one of the requirements this can be considered as a downside. On the other hand, in blockchains where we want to know all parties that are participating, knowing the identities of participating parties can be considered as a good feature.

30 2. It is still a young project, released in July 2017. This can be an issue because newer projects often are less tested and more prone to bugs. In addition, younger projects have less online resources that can help developers when they try to modify/use that technology.

3. It needs to be deployed somewhere (requires machine/server).

2.5.4 Ethereum

Founded in 2014 by Vitalik Buterin [22]. Ethereum is a decentralized platform (Dapps) that runs smart contracts [22]. No one controls the platform, not even the person who wrote it. It is a single blockchain where everyone can write their own applications. Ethereum started as PoW but is transferring to the PoS. The reason why they want to switch to PoS is that they want to make the value of the Ethereum coins more stable by giving more power to users who stake their coins [12]. Ethereum uses the programming language to write smart contracts. Smart contracts deal with enforcement, management and payments. Ethereum’s block processing time is only 15 seconds, and Ethereum uses the Ethereum Virtual Machine for processing transactions which is around 40 times faster than Bitcoin [22].

Pros of using Ethereum for negotiating trust in IoT Networks are as follows:

1. Ethereum outnumbers other cryptocurrencies like Bitcoin and Ripple in re- gards to the number of nodes around the globe. The higher number of Ethereum nodes represents true decentralization.

2. Faster block time than a lot of mining blockchains.

31 Cons of using Ethereum for negotiating trust in IoT Networks are as follows:

1. PoW is not as fast as PoS, and they are still working on switching to PoS.

2. There were security issues in the past. One of them is the DAO (decentralized autonomous organization) hack in 2016 [49]. DAO is an autonomous entity that operates through smart contract and is in the charge of transactions, which removes the need for a central authority. However, one attacker found a bug that allowed him to drain 3.6 million ETH (equivalent to $70 million). The attacker was able to request the Ether back multiple times from DAO before the smart contract could update the balance.

3. Modifications can be hard because Solidity is a young language without alot of support.

2.5.5 Cosmos

Cosmos allows different blockchains to communicate with each other, creating an ecosystem of blockchains [42]. This allows permissioned and permissionless blockchains to communicate between each other. The purpose of being able to communicate between different blockchains is the idea to use more specialized blockchains and then be able to process data in one place. Cosmos as a product can be divided in two parts:

• Tendermint - the software, it uses Byzantine Fault Tolerance (BFT).

• Cosmos - (the blockchain/ a hub for blockchains) decentralized network of independent parallel blockchains, each powered by Tendermint.

32 There are four main elements in Cosmos

1) Atoms - a license for holders to stake and vote

2) Validators - responsible for committing new blocks (act like miners)

3) Zones - each type of blockchain has a zone and can exchange information with other types of blockchains.

4) Hub - intermediate between zones (blockchain)

Pros of using Cosmos for negotiating trust in IoT Networks are as follows:

1. It uses BFT as decentralized organized systems.

2. It can process up to 10,000 transactions per second.

3. It allows simulation of multiple blockchains (Ethereum, Bitcoin etc.).

4. It can be useful for establishing trust between IoT devices in a multi-blockchain system.

Cons of using Cosmos for negotiating trust in IoT Networks are as follows:

1. It is useful for merging blockchains and not for building a blockchain itself. Not useful for individual blockchains.

2. Cosmos requires use of other blockchains.

3. Cosmos Hub launched on March 13th, 2019 (Very young project).

33 2.5.6 Characteristic Comparison

Table 2.1 compares characteristics of blockchains that are discussed in the Section 2.5. It shows if those blockchains can be run as permissionless and permissioned, do they require a server to run or not. The table also shows the consensus type that they are using, time that takes for adding a block or number of transactions that can be done in 1 second, and their scalability.

Table 2.1: Comparison of blockchains

Characteristic IOTA Ripple Hyperledger Ethereum Cosmos permissionless yes no no yes yes permissioned yes yes yes yes yes requires server only yes yes only only permissioned permissioned permissioned consensus type modified PoA RPCA modified BFT PoW BFT PoS time for less than 3,000–20,000 10,000 adding 1 min 3–5 ses transactions 10–20 sec transactions a block per second per second scalability exponential yes yes no yes

2.6 IoT Blockchain Smart Homes

In the paper [26] by Dorri, Kanhere, Jurdak and Gauravaram, the authors discuss the use of blockchain for smart homes. Their design consists of three main layers: smart home, cloud storage, and overlay. Smart home contains smart devices that are managed by miners. A smart home comprises an overlay network with smart phones, computers, cloud storage, and Service Providers (SP). Their proposed solution groups nodes in clusters with one main node called cluster head (CH), reducing overhead. A public blockchain is maintained by using two key lists. Request key list is a list of users who are allowed to access data. Requestee key list

34 is a list of smart homes that are connected to the cluster. Beside using blockchain, the authors suggest two design security principles in order to improve security [26], as follows:

1. Indirect accessible devices - the data on devices cannot be directly accessed and it is often sent to the server where only users with permission to access the data can access it.

2. Different transaction structures - this is usually achieved by making a network where devices can send the data to each other, and where there is no a single point of failure.

The authors split the components of smart home in four main groups. The first component is transactions that are defined as communication with devices or nodes. In this category, they explain different types of transactions, where store transac- tion represents transactions generated by devices. Access and monitor transactions are generated by a home owner or SP, where access transactions access the cloud, and monitor is used for checking devices information. The authors use genesis transaction to add a new device to the network [26]. The genesis transaction is the first transaction in a blockchain. The authors [26], use genesis transaction of all devices in the blockchain and chain it to a smart home genesis of transaction.

Local blockchain has an immutable ledger, block header and policy header, and number of transactions. Each home has a local private BC for keeping track of devices, and each time a new device is added, genesis transaction chains that trans- action in an immutable ledger. Each block contains a block header and a policy header. The policy header has four parameters: requester (device ID for local de-

35 vices), storing or accessing location (locally or cloud), devices ID and action that should be performed.

Home miner is a device used for processing incoming and outgoing traffic. The miner can authenticate, authorize, and audit transactions. Audit transactions are local storage that is used as a backup drive for storing data locally (FIFO - queue). The authors explain how initialization and transaction handling is done and how shared overlay is used. Initialization is a process of adding new devices and policy header to the blockchain [26]. It is done by genesis transaction by sharing a key with a device using generalized Diffie-Hellman key exchange. The key is shared between the miner and the device [24], while the policy header is created by the owner and added to the first block. For transaction handling the authors proposed a method where the miner generates a shared key for devices that want to com- municate between each other, example: light bulb and motion sensor. The miner should always check the header policy or ask the owner before sharing keys. Data can be stored either on local storage or on the cloud. In the case of storing on the cloud, a store transaction is used, and the data is stored anonymously [25]. The home owner or service provider can access and monitor transactions. For accessing transactions, the data is sent to requester through miner either from a local stor- age or a cloud. There are two ways to send the data from a cloud; one way is by sending the data to the requester, and the second way is by sending the last block number and hash. However, the second method might affect the confidentiality of the data and allow the requester to read the entire data. It allows the user to read all data in blocks that contain some data that the user is allowed to read. To prevent this, each block should contain only data from one device. When it

36 comes to a monitor transaction, the data is sent in intervals until a close request is sent. In the case that the user has more than one smart home, the authors suggest using a shared overlay [25]. Homes are managed centrally similarly to a single home; however, in a shared overlay, each home has its own genesis transaction of all devices in that house.

For evaluation of systems security, the authors [25] first looked at three main requirements: Confidentiality, Integrity, and Availability (CIA). The employed method addresses confidentiality and integrity. In order to protect availability, the authors suggest limiting transaction to those with a shared key. They analyzed DDoS attacks and Linking [40]. Linking affect privacy and is done by establishing a connection between multiple data ledger or transactions [26]. One of the ways that a user’s identity can be revealed is if they need to combine coins from multiple addresses in order to send to someone payment. If this happens multiple times, an adversary can make a link between all addresses that belong to one user [55]. To prevent DDoS attacks, the authors created a hierarchical four-level defense. The first level defense prevents the direct installation of malware on IoT devices, because they are not directly accessible. The second level controls outgoing traffic, making sure that only authorized users/devices get access using the header policy. Last two layers are working with the Cluster Head (CH) key list and changing public keys in CH lists. The authors also did a performance evaluation where they simulated two different traffic flow patterns, periodic and query-based. They evaluated packed overhead, time overhead and energy consumption.

37 2.7 Summary

Blockchain stores data inside blocks. The first blockchain was invented by a person under the name Satoshi Nakamoto. Bitcoins blockchain uses a public ledger for transactions; however, there are blockchains that use private ledger to store data. Bitcoin’s blockchain has an immutable ledger and tries to preserve anonymity. To validate data that is stored, a blockchain uses consensus protocol; there are different types of consensus protocols such as Proof-of-Work, Proof-of-Stake, and Proof-of-Activity. In addition, to prevent attacks, blockchains often use the Byzan- tine Fault Tolerance algorithm where 2/3 of all nodes need to agree on the validity of the data. Blockchains such as Bitcoin have miners that are in charge of pro- cessing transactions by using their computational power and in return they get bitcoins. Blockchains can also be used in smart homes for recording transactions between devices.

38 Chapter 3

Approach

3.1 IOTA Tangle

Our first choice was IOTA because it was specifically built with IoT devices in the mind. IOTA does not have transaction fees or miners, and because it is was specifically built for IoT devices, it does not require too much electric power orpro- cessing power to execute transactions. We specifically wanted to avoid blockchains that require the use of PoW because they often require a lot of electric power and powerfull processors that most IoT devices do not have. IOTA eliminated PoW by using a modified version of PoA consensus protocol, making users with more transactions are more trustworthy [61]. We also wanted a blockchain that can be run privately so that our records are not accessible by all other blockchain nodes. Although IOTA is a public blockchain, it allows developers to create, modify and run private instances of Tangle. Another requirement that we had was that trans- actions will not take more than one minute. IOTA was explained in more detail in Section 2.5.1.

39 According to IOTA’s official website [13], to run private Tangle the userneeds to have the following:

• Ubuntu 18.04 Server / Virtual Machine

• At least 8GB RAM

• 4 or more CPU cores

• At least a 10GB of SSD

Also, IOTA requires installation of Bazel and Docker. Bazel is a software tool developed by Google that automates processes of building and testing software [13]. Bazel has multi-language and has extensions to support more programming languages. Bazel supports Java, C/C++, Objective-C, Python, Android, Shell, and general-purpose programming language, and it also supports multi-platform builds, and it can handle large builds [2]. Docker is a tool that uses containers for creating, deploying, and running applications. Containers allow developers to bundle the application with all required libraries and dependencies and export it as one package [3].

In addition, it requires having programming languages Java and Python installed. First step is to install dependencies for Bazel, and then install Bazel from its Github repository 1. The instruction on the official website instructs developers to download and install Bazel 0.18.0. After that developers should install Docker and

1https://github.com/bazelbuild/bazel

40 jq which is a tool for formatting JSON data. After installation users should clone Compass from Github. Compass is an open-source implementation of the boot- strap method, called the Coordinator in IOTA. In the private Tangle, Compass is required to work in order for transactions to be added to the blockchain. If Com- pass stops running, nodes/users would not be able to add any new transaction [11].

After that user should run docker:layers calculator that is used to compute the Merkle tree. However, Bazel 0.18.0 version is not compatible with Compass from Github, and it requires at least version 0.23.0. Another problem that we ran into is that older versions of Bazel do not work with newer version of Java (Java 11 and Java 12) and only work with Java 8 and Java 9 which are deprecated in Ubuntu, and Java 8 is no longer supported for personal use by Oracle after December 2020, while Java 9 reached the end of its life in March 2018 [10]. We decided to use Bazel 0.29.0, which was released on August 28, 2019 [2].

Figure 3.1: IOTA Layer Calculator – This figure shows the process of building the Merkle tree using layer calculator.

The Layer Calculator computes the Merkle tree, which is shown in Figure 3.1. Then we need to create a seed which is required by Compass in order to derive public/private keys for digital signatures [13]. After that, we need to go to the pri- vate tangle directory and create a configuration JSON file that contains the seed

41 that we created. That was shown in Figure 3.2, and we need to set the depth of the tree. On the IOTA’s website, it is recommended to set the depth to 16. The depth affects how many private key/address pairs Compass will have, anditis calculated using the formula: 2depth. Greater depth requires more processing time to create the Merkle tree [13].

Figure 3.2: Compass Seed – This figure shows the process of creating the seed that is used by Compass to derive public/private key.

Figure 3.3: Tangle JSON configuration – This figure shows conifg.json – configu- ration file that was used for computing Merkle tree.

Then we ran script 01 calculate layers.sh that computes the Merkle tree with spec- ifications that we provided in the config.json file (Figure 3.3). This process takes around 15 minutes, and it will calculate 2depth addresses and nodes for each level of depth. The next step is to run a script for creating an IOTA Reference Implemen- tation (IRI) node. The IRI node is important, and if it gets compromised, it has potential to allow attackers to get favorable treatment and make their transactions priority over other transactions. Furthermore, that can allow an attacker to double spend cryptocurrency and perform a Denial of Service (DoS) attack. However, this step failed because the script for IRI node could not find a dependent library for IRI node (Figure 3.4).

42 Figure 3.4: IRI Node – This figure shows failed try to run IRI node.

The next step in the Private Tangle would be to run Compass and after that to connect to the network. After that developers can add new nodes and subscribe to get notification about events on nodes that they own [13]. Because wehada lot of issues with setting Tangle, we decided to use Hyperledger Fabric, which is discussed in Section 3.2 [13].

3.2 Hyperledger Fabric

Our second choice was Hyperledger Fabric because it meet our requirements of low electric power consumption, no mining and no PoW, permissioned chain, and fast transaction. According to the Hyperledger Fabric website, it can process between 3,000 and 20,000 transactions per second [7]. Hyperledger uses a modified version of BFT, which does not require a lot of electric power or CPU power and elimi- nates the need for miners. It is also a private blockchain and does not have any public instance. It requires a server to be able to run constantly. Hyperledger was discussed in more details in Section 2.5.3.

We decided to use a Virtual Machine (VM) with Ubuntu for setting up and testing Hyperledger. Running Hyperledger Fabrics requires the following:

43 • Go Programming Language

• Node JS

• Node Package Manager (npm)

• Python

• Docker

Go programming language is a procedural language developed by Google [5]. Node Java Script is used in Hyperledger for writing script files for processing transac- tions. Node Package Manager (npm) is used in Hyperldeger for package manage- ment. Docker is a virtualization tool that was explained in Section 3.1.

We also decided to use Hyperledger Composer, which is a development environ- ment for Hyperledger Fabric that makes it easier to edit and modify Hyperledger. Hyperledger Composer is a tool that provides a user interface for building a Hy- perledger Fabric application [8]. Developers can install and run Composer on their machines or use Composer Playground online. It consists of a Define tab where developers can modify blockchain and Test tab where developers can add new participants and assets, and perform transactions. The Define tab contains four files that can be modified: sample.cto is a file that uses CTO modeling language to define types of participants, assets and transactions in the blockchain, while JavaScript file is used before transactions are processed to check if all conditions are met that developers defined and it is used to change values inside assets after exchange. The third file is Access Control file, which is compiled from thetop to the bottom and defines who can read, create, update, and delete items inthe

44 network. In addition, by adding conditions, developers can specify under which circumstances those actions can be done. For example, a user can only delete his assets. The last file that is optional is a Query File that can query lists ofusers and assets or make filtered lists based on the condition that was provided. When developers edit all files, they can deploy changes locally, and test in the testtab, and download business network archive file (bna) that can be deployed on a private ledger [8].

One of the issues with using Hyperledger Composer is that it was deprecated on August 29th, 2019, and is not supported by IBM anymore [8]. In addition, the commands that were used before for deployment of Hyperledger network such as deploy and update are no longer valid and were replaced with commands start and upgrade. New changes like this can create an issue because instruction manuals developed before this change occurred cannot be used anymore.

3.2.1 Scenarios

3.2.1.1 Scenario 1

We have two IoT devices, one exists on the network (device A), and another device is entering the IoT network for the first time (device B). A new device never con- nected with the device that is already on the network and does not know if device A provides a service that device B needs. Also, device A does not have any knowl- edge about what services device B provides. When a new device is entering the network, a person who is connecting the device will need to provide basic informa- tion about that device such as the name of the device, a year of manufacture, and

45 services provided by this device. Ideally, all devices would have this information inside them and be able to send them to the blockchain when they are connecting for the first time.

The first problem that we try to solve is when a new device (device B) isentering the IoT space and trying to do following actions:

1. To provide a service to another devices (device A)

2. To use service from an existing device (device A)

In the second part, we are trying to filter devices that provide a specific service.

3.2.1.2 Scenario 2

This scenario covers cases where multiple devices can provide a single service. In this case, it is hard to pick the device to connect with. Our algorithm takes in account the following information in order to recommend devices to connect with:

• How frequently does this device provide any service?

• How frequently does this device provide requested service?

• How recently did this device last provide requested service?

• Has given device provided any service to me before?

• Has given device provided this service to me before?

• Does this device have the right hardware to provide my requested service?

• When was this device manufactured?

46 3.2.2 Algorithm and Code

3.2.2.1 Blockchain Code

We declare each device in Hyperledger as a participant, and each participant has a unique ID, device name, a list of services that device provides, year of production which contains a month and year when that device was produced, and hardware specifications. For this experiment, we decided to use a four dash separated four digit numbers.

participant Device identified by deviceId { o String deviceId o String deviceName o Services[] serviceProvided o ProductionYear year o String hardwareSpect } concept ProductionYear { o Integer month o Integer year }

Devices can provide different services such as unlocking a door, taking a picture, making a video, printing, detection motion, or not provide any service at all and just request services from others.

JavaScript code in blockchain is in charge of checking if a device that provides

47 service actually can provide the service that was requested. In case that a provider does not provide that service, a transaction would not be allowed (Figure 3.5).

Figure 3.5: JavaScript File – for processing transactions. It checks if a provider has the requested service, and then processes the transaction.

3.2.2.2 Connecting with Hyperledger

For connection with Hyperledger Fabric, we used Composer’s REST API server that runs on the port 3000 of virtual machine. Then we developed a Java program that can query transactions and list of devices using GET request. For adding a new device to the ledger and processing transactions, we used POST request.

3.2.2.3 Algorithm for Establishing Trust

The algorithm that recommends to request the best possible provider to connect with scores devices from 0-35 and then converts that score on the 0-100 scale. Points are evenly distributed on four different categories, and each category can get between 0 and 5 points. The first category is the number of times that device

48 provided the service to other devices. The second category is how many times that device provided the particular service that requester need to other devices. The third and forth categories are same as first and second, but they only look at number of connections between requester and provider. The rating is shown in Table 3.1. For rating the number of connections, we used the formula where good amount of connections (Gc) and for rating a good amount of connections with requester (Gr), where Gc and Gr are:

num transactions num transactions Gc = Gr = √ num devices num devices · num devices

Table 3.1: Connection Points Distribution – This table shows how points are distributed for four different categories. C1 – category is based on the number of time that device provided any service. C2 – category is based on the number of time that device provided the service that is being requested. C3 – category is based on the number of time that device provided any service to the requester. C4 – category is based on the number of time that device provided the service that is being requested to the requester.

category 0 points 1 point 2 points 3 points 4 points 5 points C1 0 ≤ 0.1 · Gc ≤ 0.25 · Gc ≤ 0.5 · Gc ≤ 0.75 · Gc > 0.75 · Gc C2 0 ≤ 0.05 · Gc ≤ 0.125 · Gc ≤ 0.25 · Gc ≤ 0.375 · Gc > 0.375 · Gc C3 0 ≤ 0.1 · Gr ≤ 0.25 · Gr ≤ 0.5 · Gr ≤ 0.75 · Gr > 0.75 · Gr C4 0 ≤ 0.05 · Gr ≤ 0.125 · Gr ≤ 0.25 · Gr ≤ 0.375 · Gr > 0.375 · Gr

Category five looks at when was the last time the provider provided this service to someone and based on that gives points between 0 and 5 (Table 3.2). By checking the last time that service was provided, other device can often tell how reliable that device is. If the device did not provide the service in last 6 months, it might be because it is broken or service is not good anymore.

49 Table 3.2: Last Connection Points – This table shows how points are distributed based on last time that device provided the service that was requested. If the device is not being used for longer time periods, it could mean that device is broken or service that it was providing was not good enough, so other device stopped using it.

0 points 1 point 2 points 3 points 4 points 5 points longer than 3–6 months 1–3 months 15–30 days 7–15 days 0–7 days 6 months ago

The last two categories are year when the device was made and hardware that it has. Ideally, there should be the list of all hardware and ratings for each of them. For the purpose of this work, hardware information are stored as a four pairs of four digit number, and then all four numbers are summed together, and divided with maximum sum, and multiplied by five in order to get a double value between 0 and 5. The year when device was made is score based on a table that is shown in Table 3.3.

5 · sum numbers hardware score = 4 · 9999

Table 3.3: Device Make Points – This table shows points distribution based on year of device make. Older devices are often more likely to fail or provide lower quality services due to often having older hardware, where cy stands for a current year 0 points 1 point 2 points 3 points 4 points 5 points before cy - 14yrs cy - 11yrs cy - 8yrs cy - 5yrs cy - 2yrs cy - 15yrs to to to to to cy - 12yrs cy - 9yrs cy - 6yrs cy - 3yrs cy

50 The total amount of points (35 points) is normalized on the 100 point scale of double values. Scores are compared and based on this score, and the device with highest score is suggested to requester. However, the requester can look through other devices and make a decision based on information that is provided.

total score Normalized Score = · 100 35

3.2.2.4 Blockchain Structure

A blockchain consists of multiple blocks linked to each other as shown in Figure 3.6 [6, 7]. The first block is called the genesis block and contains the configuration of the network information, and it does not contain any transactions. Other blocks can have one or multiple transactions, header, and metadata. The number of transactions deepens on how many transactions are waiting to be submitted, and the number of transactions cannot exceed the predetermined limit that is based on the maximum number of transactions per block and the maximum number of bytes permitted [6, 7]. Each block is linked to the preceding block by containing a hash value of the previous block inside the header.

Figure 3.6: Hyperledger Fabric Blockchain – This figure shows a blockchain con- taining genesis block and two succeeding blocks. Each block is linked to the pre- vious block by having a hash value of a preceding block in the header. Based on [6].

51 Each block has three parts: block header, block data, and block metadata (Figure 3.7). A header contains a block number, hash value of current block, and hash of the previous block [6, 7]. Block numbers start with 0 for genesis block and increased by 1 for each new block. A current block hash is calculated based on all transactions in that block. Previous Block Hash is hash of the previous block that links a new block to its neighbor and makes the blockchain immutable. Block Data has a list of transactions in order that they were received, while metadata contains the time when the block was created, certificate, and signature if the peer who is creating the block. Metadata is created when a block is created, before putting transactions in the data of the block, and it is not included in the hash.

Figure 3.7: Hyperledger Fabric Block – This figure shows a content of each part of a block. Based on [6].

A block data contains multiple transactions, and each transaction has header, sig- nature, proposal, response, and endorsements. A header contains essential meta- data information about the transaction such as chaincode name and version [6, 7].

52 A signature is a cryptographic signature of the client using the client’s private key and can be confirmed by using the client’s public key. A proposal contains input parameters that are provided to the smart contract. Response captures values before and after the transaction. In case that transaction is validated successfully, the proposal will be applied to the ledger. An endorsement is a list of all required signatures from the participant.

There are two types of transactions in our Hyperledger Fabric blockchain: a trans- action for adding new devices and a transaction for a provided service. The re- sponse of each transaction in case of adding a new device contains information about that device, transaction ID, and time stamp. The response for a trans- action for a provided service contains IDs of provider and receiver, service type, transaction id and time stamp. This is explained in more detail in Chapter 4.

3.3 Summary

When trying to use IOTA’s blockchain, we encountered a lot of issues with compat- ibility between different tools that are necessary for creating and using aPrivate Tangle, which is often the case with a blockchains that are dependant on third party tools. Although Hyperledger’s tool Composer is deprecated and will no longer be in use, it was fairly easy to set up and start running the ledger. The Composer allows testing the program without deploying it previously, which makes development on Hyperledger Fabric much faster and easier.

The goal of using Hyperledger was to test if it is possible to query information

53 about other devices in the network and be able to add new devices that are going to provide a service to devices that are already in the network. The results are shown in the Chapter 4. Another goal was to find the way to establish trust be- tween different devices. The algorithm that we developed tries to establish trust between IoT devices. It helps a device to make the decision with which device it should connect to get requested service. The following categories are scored and the score was later normalized on 100 point scale:

1. Number of times the device provided a service to any other devices – 5 points

2. Number of times the device provided the requested service to any other devices – 5 points

3. Number of times the device provided a service to the requester – 5 points

4. Number of times the device provided the requested service to the requester – 5 points

5. Last time the device provide the requested service – 5 points

6. Year of device production – 5 points

7. Hardware required – 5 points

The results of two scenarios mentioned in this chapter and additional experiments with queering data about devices, making decision with which device to connect, adding new device and executing transactions, are discussed in Chapter 4.

54 Chapter 4

Experiments

4.1 Experimental Design

To evaluate the use of Hyperledger’s blockchain for establishing trust between IoT devices we used two scenarios that were explained in Chapter 3: scenario 1 where a new device enters the IoT network and scenario 2 where the algorithm that we developed suggests to requester the device from which it should request a service. Furthermore, we performed experiments with querying devices that can provide the requested service. This helps devices find who can provide service that they need such as taking pictures, making videos, printing, and detecting motion. We initially started with 10 virtual devices, which is considered a medium test sample [31]. Two devices that do not provide any service, four devices that provide a single service and four devices that provide multiple services. During development and testing, we added 6 more devices to make sure that function for adding services work correctly. Also, 100 initial transactions were made as 100 is often considered a minimal sample size for testing [53], and during testing over 500 more transactions

55 were added in order to make sure that function for adding transactions works, and also see how more transactions are going to affect the querying speed. Java code that we wrote allows a user to add new devices to the network and provide service or request service. Upon service was provided, the transaction would be saved for the ledger. Figure 4.1 shows adding a new device transaction, while Figure 4.2 shows a transaction between two devices.

Figure 4.1: New Device – This figure shows how transaction for registering a new device looks like in our Hyperledger blockchain. Besides information about device that device/device’s owner provides, there is information about the target registry, transaction ID and timestamp. Note: The data shown here is the data from response part of transactions, and it does not show digital signature. This screenshot was taken from Composer Online Playground.

In this section, we also present findings from testing the algorithm for rating the trust that was explained in Section 3.2.2.3. This algorithm helps devices to make a decision with which device should they connect when requesting the service. In experiments, users can run Java code for different scenarios and then input infor- mation that they are prompted from standard input/keyboard.

56 Figure 4.2: Transaction – This figure shows how a response part of a transaction between two devices looks like. Note: The data shown here is the data from re- sponse part of transactions, and it does not show digital signature. This screenshot was taken from Composer Online Playground.

4.2 Scenario 1

This scenario was explained in section 3.2.1.1. When a new device wants to enter the network, that device gets the unique identification number (ID). Then the owner is asked to provide a name of device, services that device can provide, and year and month when the device was made and hardware specifications. After that, the owner is prompted to add the device to the network. When the device is added, blockchain is searched to find that device.

As long as there is the Internet connection, we were able to add new devices to the Hyperledger Fabric blockchain (Figure 4.3). Ideally, devices would have this information, and they would be able to send the request to enter the network. However, even in the case that the owner or network admin needs to add devices to the network, this should be a very simple process.

57 Figure 4.3: Adding New Devices – This figure shows the output from running the code for adding a new device on the blockchain. Black text represent what program prints, while green text is the user input.

4.3 Scenario 2

This scenario was explained in section 3.2.1.2. In this scenario, we tried to answer the question about devices that provide the requested service. This process re- quired querying transactions that provided requested service, and how many times that provider provided any service, how many times that provider provided the requested service, and also checking how many times that service was provided to the requester. The last information that was extracted from transactions was the last time that device provided the requested service. We were able to obtain all of this information from the ledger. In addition, the requester was able to obtain information about how old is the hardware that the provider has, as well as the hardware type. This information was obtained from the part of the ledger where participants are stored.

58 4.4 Experiments

4.4.1 What devices can provide a specific service?

In this experiment, we wanted to test if we can find all devices that can provide a certain service such as take pictures, record videos, print documents, and detect motion. In a normal network, it is hard to know which device provides the service that a requester needs. Often names given to devices are non-descriptive, and it is hard to tell which service they provide. In this experiment, we were able to find all devices that provide service that the requester needed. As shown in Figure 4.4 and Figure 4.5, the requester is prompted to pick a number between 1 and 5, denoting five different services that are provided by different devices in the network. After a user enters a number that corresponds to the service, all devices that provide that service are printed on the console.

Figure 4.4: Service Providers – This figure shows the list of devices that provide a service of taking a picture.

59 Figure 4.5: Service Providers – This figure shows the devices that can make a video (on the left), access a printer (in the middle) and detect the motion (on the right). Note: the data has been retrieved from the blockchain.

4.4.2 Which device is the best?

Figure 4.6: Device Recommendation – This figure shows the recommendation with which device requester should connect. Note: the data has been retrieved from the blockchain.

For deciding which device is the best, we need to know the requester’s ID and service that they are requesting. After we run through the algorithm that is based

60 on questions from scenario 2 and also explained in Chapter 3, we output the device with the highest score. In the case that two devices have the same score, the device with a higher number of transactions is considered as the better device. This device is printed as the recommended devices, while other devices are sorted based on the score and printed in case that the requester decide to connect with another device.

4.4.3 New devices wants to provide a service?

When a new device is added to the ledger, it is able to provide services that it offers. Other devices are able to find that device and request a service fromthat device. Adding a new device to the network was explained in Section 4.4 of this chapter.

4.4.4 Service is provided- show transaction

Figure 4.7: Transaction – This figure shows service exchange between two devices.

61 When service is provided, then transaction is submitted to the ledger. Our transac- tion contains the unique transaction ID, time stamp, IDs of requester and provider, and service type. In Figure 4.7. the requester with ID 0001 requested UN- LOCK DOOR service from device with ID 0003. After virtual service was pro- vided, the transaction is printed as conformation that the transaction is submitted to the ledger.

4.5 Summary

Setting up Hyperledger Fabric blockchain greatly depends on the environment that is being used and what operating system it has as well, as what it is already in- stalled there. We used Ubuntu Operating System on a Virtual Machine. It took around one hour and a half to install all dependencies and start running the Hyper- ledger, and an additional hour to set up everything for Composer Playground. In experiments, we were able to retrieve data about each device and all transactions. Also, our algorithm was able to recommend devices that provide service requested by another device.

Table 4.1: Querying Speed – The table shows average speed. minimum and max- imum speed for querying data for all devices, 100 transactions, 200 transactions and 500 transactions.

Querying Test Average Time (s) Min Time (s) Max Time(s) All Devices (16) 0.586625260 0.501935781 0.738233733 Transactions (100) 2.717833221 2.456113717 3.371472386 Transactions (200) 3.009682226 2.699521539 3.415725100 Transactions (500) 3.069854637 2.501043021 3.350280487

62 We did querying tests to see how much is the speed of querying data going to be affected by the number of transactions and the number of devices (Table 4.1). We repeated each test 10 times and calculated average, minimum, and maximum speed for each test. Because there are only 16 devices in the network, querying data for devices is relatively fast with an average of 0.59 seconds. Querying 100 transactions took on average 2.72 seconds, while querying 500 transactions took on average 3.07 seconds. One thing that can affect speed is other processes on the same machine/server. When we were measuring speed for querying 400 trans- actions, the average was 5.81 seconds with a minimum time of 3.30 seconds and a maximum time of 7.70 seconds. This discrepancy could be due to the laptop or Virtual Machine (VM) on which we were running Hyperledger running some other processes. Adding processes is eventually going to slow down the querying speed. In our example with every 100 transactions, the time needed to query them increased by around 0.14 seconds. However, we will need to do more extensive measurements in the environment that is more stable than a VM.

63 Chapter 5

Conclusion

5.1 Findings

Blockchain as technology can be used for storing data about IoT devices. Its immutable ledger and requirements of digital signatures provides integrity to the data. There is a lot of different blockchains with different functionalities today. Al- though some of most well known blockchains such as Bitcoin and Ethereum are not suitable for IoT devices due to their high electricity consumption and requirement of powerful hardware, there are other solutions such as IOTA and Hyperledger Fabric that are not CPU demanding and are more suitable for IoT devices.

One of downsides of using an existing blockchain is that because they are fairly new as a concept, they can be very unstable and hard to deploy; where the first blockchain, Bitcoin, was relisted in 2008 [54]. Often instability is caused by a blockchain depending on a third party libraries. We encountered this problem when we were trying to use IOTA’s private Tangle. Another issue with some

64 blockchains is that technologies such as Hyperledger Composer get deprecated quickly, forcing developers that use that block chain to learn new technologies ev- ery few months. However, granted the stability and control over technologies that can be used, blockchain can be a great solution for storing transaction data and information about IoT devices, and establishing trust between different devices in the network.

5.2 Results

In our experiments, we were able to retrieve transaction data and list of devices from Hyperledger Fabric. In addition, we were able to query data about devices that provide certain services and rate them based on the algorithm for establishing the trust that we developed. We were also able to add new devices to the ledger and those devices were able to provide the service to other devices in the network. We measured that querying 500 transactions took on the average 3.07 seconds, and querying all 16 devices took around 0.59 seconds. We calculate that by adding 100 new transactions, querying time increases for around 0.14 seconds. We also discovered some discrepancies when we measured querying of 400 transactions, which on average took 5.81 seconds. Since we used a Virtual Machine this could be caused by some processes running on the laptop.

5.3 Future Work

Using Blockchain to establish trust between IoT devices showed promising results. We were able to query data, make transactions between virtual devices, and con- nect new virtual devices on the network. We are planning to do experiments with

65 physical devices, connect them to the network, and make them request transac- tions from each other. Devices should be able to request a service and in return get a device that provides the requested service, and it is also the most trusted device based on the algorithm that we developed. Additionally, it would be useful to do experiments on a much larger scale and see how much Blockchain can scale up, the number of transactions that is going to cause significant delays in a blockchain, and what are limitations that a blockchain has for IoT application.

5.4 Revisit

To what degree we can store and retrieve information about IoT devices on a blockchain? In our experiments, we were able to query all transactions and query transactions where the provider was a device with a certain ID. We were also able to query all devices and devices that provide the requested service.

Can this information be used to answer such as how frequently does one device provides the requested service? We were able to find how many times one device provided the requested service and how many times that device provided any service. In the case that the de- vice provides more than one service, those two numbers are going to be different. Because all transactions are ordered based on the time in the blockchain, we were also able to tell what is the last time that the device provided the requested service without the need to sort transactions based on the time.

66 How often does the device provide service to the device that is re- questing a service? It is also possible to tell how often one device provides requested service to another device, and also how many times that device provided any service to that device.

Can a new device that is entering the IoT space provide or request a service? A new device that is just entering IoT space is going to be able to provide and request services when a transaction with information about that device is submit- ted to the blockchain which in Hyperledger depends on the number of transactions that are waiting to be submitted, but in our case, it took around 1 second.

67 Bibliography

[1] Achieving blockchain scalability with sparse merkle trees and bloom filters.

[2] Bazel: Build and test software of any size, quickly and reliably. https://www. bazel.build. Accessed 10-October-2019.

[3] Enterprise container platform. https://www.docker.com. Accessed 10- October-2019.

[4] Free online sha-256 generator tool. https://www.freeformatter.com/ sha256-generator.html.

[5] Go lang. https://www.hyperledger.org/projects/fabric.

[6] Hyperledger - hyperledger fabric.

[7] Hyperledger fabric. https://www.hyperledger.org/projects/fabric.

[8] Hyperledger fabric composer. https://hyperledger.github.io/composer/ v0.19/business-network/bnd-deploy.

[9] Mobility report - internet of things forecast. https://www.ericsson.com/en/ mobility-report/internet-of-things-forecast.

68 [10] Oracle java se support roadmap. https://www.oracle.com/technetwork/ java/java-se-support-roadmap.html. Accessed 20-October-2019.

[11] Overview: Introduction: Private tangle: Iota documentation. https:// docs.iota.org/docs/compass/0.1/introduction/overview. Accessed 10- October-2019.

[12] Why is ethereum switching to pos? https://medium.com/@ricardocielak/ why-is-ethereum-switching-to-pos-5af8a592b179, May 2018.

[13] Set up a private Tangle how-to guides: Private tangle: Iota documen-

tation, 2019. https://docs.iota.org/docs/compass/0.1/how-to-guides/ set-up-a-private-tangle.

[14] Godfrey Anuga Akpakwu, Bruno J Silva, Gerhard P Hancke, and Adnan M Abu-Mahfouz. A survey on 5g networks for the internet of things: Communi- cation technologies and challenges. IEEE Access, 6:3619–3647, 2017.

[15] Muneeb Ali, Jude Nelson, Ryan Shea, and Michael J Freedman. Blockstack: A global naming and storage system secured by blockchains. In 2016 {USENIX} Annual Technical Conference ({USENIX}{ATC} 16), pages 181–194, 2016.

[16] Elli Androulaki, Artem Barger, Vita Bortnikov, Christian Cachin, Konstanti- nos Christidis, Angelo De Caro, David Enyeart, Christopher Ferris, Gennady Laventman, Yacov Manevich, et al. Hyperledger fabric: a distributed operating system for permissioned blockchains. In Proceedings of the Thirteenth EuroSys Conference, page 30. ACM, 2018.

[17] Luigi Atzori, Antonio Iera, and Giacomo Morabito. The internet of things: A survey. Computer networks, 54(15):2787–2805, 2010.

69 [18] Roman Beck, Jacob Stenum Czepluch, Nikolaj Lollike, and Simon Malone. Blockchain-the gateway to trust-free cryptographic transactions. In ECIS, page ResearchPaper153, 2016.

[19] Jennifer B´elissent et al. Getting clever about smart cities: New opportunities require new business models. Cambridge, Massachusetts, USA, 2010.

[20] Iddo Bentov, Charles Lee, Alex Mizrahi, and Meni Rosenfeld. Proof of ac- tivity: Extending bitcoin’s proof of work via . IACR Cryptology ePrint Archive, 2014:452, 2014.

[21] Ethan Buchman. Tendermint: Byzantine fault tolerance in the age of blockchains. PhD thesis, 2016.

[22] Vitalik Buterin et al. Ethereum: A next-generation smart contract and de-

centralized application platform. https: // github. com/ ethereum/ wiki/ wiki/ %5BEnglish% 5D-White-Paper , 7, 2014.

[23] Hadelin de Ponteves and Kirill Eremenko. Udemy: Blockchain a-z:

Learn how to build your first blockchain. https://www.udemy.com/course/ build-your-blockchain-az/learn/lecture/9657368#overview.

[24] H Delfs and H Knebl. Introduction to cryptography vol. 2 berlin etc. Springer, (0.004):0–008, 2002.

[25] Ali Dorri, Salil S Kanhere, and Raja Jurdak. Blockchain in internet of things: challenges and solutions. arXiv preprint arXiv:1608.05187, 2016.

70 [26] Ali Dorri, Salil S Kanhere, Raja Jurdak, and Praveen Gauravaram. Blockchain for iot security and privacy: The case study of a smart home. In 2017 IEEE International Conference on Pervasive Computing and Communications Work- shops (PerCom Workshops), pages 618–623. IEEE, 2017.

[27] Evan Duffield and Kyle Hagan. Darkcoin: Peertopeer cryptocurrency with anonymous blockchain transactions and an improved proofofwork system. bit- paper. info, 2014.

[28] Martin Feldhofer and Christian Rechberger. A case against currently used hash functions in rfid protocols. In OTM Confederated International Confer- ences” On the Move to Meaningful Internet Systems”, pages 372–381. Springer, 2006.

[29] Tiago M Fern´andez-Caram´esand Paula Fraga-Lamas. A review on the use of blockchain for the internet of things. IEEE Access, 6:32979–33001, 2018.

[30] Nikos Fotiou and George C Polyzos. Decentralized name-based security for content distribution using blockchains. In 2016 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), pages 415–420. IEEE, 2016.

[31] E Francik. Five, ten, or twenty-five–how many test participants. Hu-

man Factors International Newsletter. http: // www. humanfactors. com/ newsletters/ how_ many_ test_ participants. asp , 2015.

[32] Edoardo Gaetani, Leonardo Aniello, Roberto Baldoni, Federico Lombardi, Andrea Margheri, and Vladimiro Sassone. Blockchain-based database to ensure data integrity in cloud computing environments. 2017.

71 [33] Arthur Gervais, Ghassan O Karame, Karl W¨ust,Vasileios Glykantzis, Hubert Ritzdorf, and Srdjan Capkun. On the security and performance of proof of work blockchains. In Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, pages 3–16. ACM, 2016.

[34] Jayavardhana Gubbi, Rajkumar Buyya, Slaven Marusic, and Marimuthu Palaniswami. Internet of things (iot): A vision, architectural elements, and future directions. Future generation computer systems, 29(7):1645–1660, 2013.

[35] Dave Huitema. Sustainability of bitcoin and blockchains harald vranken.

[36] Bitcoin Energy Consumption Index. Digiconomist.

[37] Jens-Peter Kaps and Berk Sunar. Energy comparison of aes and sha-1 for ubiquitous computing. In International Conference on Embedded and Ubiqui- tous Computing, pages 372–381. Springer, 2006.

[38] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov. Ouroboros: A provably secure proof-of-stake blockchain protocol. In Annual International Cryptology Conference, pages 357–388. Springer, 2017.

[39] Sunny King. Primecoin: Cryptocurrency with prime number proof-of-work. July 7th, 1:6, 2013.

[40] Nikos Komninos, Eleni Philippou, and Andreas Pitsillides. Survey in smart grid and smart home security: Issues, challenges and countermeasures. IEEE Communications Surveys & Tutorials, 16(4):1933–1954, 2014.

[41] Nir Kshetri. Can blockchain strengthen the internet of things? IT profes- sional, 19(4):68–72, 2017.

72 [42] Jae Kwon and Ethan Buchman. Cosmos: A network of distributed ledgers.

https: // cosmos. network/ whitepaper , 2016.

[43] Leslie Lamport, Robert Shostak, and Marshall Pease. The byzantine gen- erals problem. ACM Transactions on Programming Languages and Systems (TOPLAS), 4(3):382–401, 1982.

[44] Andriy Luntovskyy and Dietbert Guetter. Cryptographic technology blockchain and its applications. In The International Conference on Informa- tion and Telecommunication Technologies and Radio Electronics, pages 14–33. Springer, 2018.

[45] Ikuo Magaki, Moein Khazraee, Luis Vega Gutierrez, and Michael Bedford Tay- lor. Asic clouds: Specializing the datacenter. In 2016 ACM/IEEE 43rd Annual International Symposium on Computer Architecture (ISCA), pages 178–190. IEEE, 2016.

[46] Eleftherios Kokoris-Kogias MariaBorge. Proof-of-personhood: Redemocratiz- ing permissionless cryptocurrencies.

[47] David Mazieres. The stellar consensus protocol: A federated model for internet-level consensus. Stellar Development Foundation, page 32, 2015.

[48] Hass McCook. An order-of-magnitude estimate of the relative sustainability

of the bitcoin network. https: // bitcoin. fr/ public/ divers/ docs/ Estimation_ de_ la_ durabilite_ et_ du_ cout_ du_ reseau_ Bitcoin. pdf , 2014.

73 [49] Muhammad Izhar Mehar, Charles Louis Shier, Alana Giambattista, Elgar Gong, Gabrielle Fletcher, Ryan Sanayhie, Henry M Kim, and Marek Laskowski. Understanding a revolutionary and flawed grand experiment in blockchain: the dao attack. Journal of Cases on Information Technology (JCIT), 21(1):19–32, 2019.

[50] HX Mel and Doris M Baker. Cryptography decrypted. Addison-Wesley, 2001.

[51] J.W. Michael, Alan Cohn, and Jared R. Butche. Blockchain technology and regulatory investigations. The Journal, 2018.

[52] Axel Moinet, Benoˆıt Darties, and Jean-Luc Baril. Blockchain based trust & authentication for decentralized sensor networks. arXiv preprint arXiv:1706.01730, 2017.

[53] Daniel J Mundfrom, Dale G Shaw, and Tian Lu Ke. Minimum sample size rec- ommendations for conducting factor analyses. International Journal of Testing, 5(2):159–168, 2005.

[54] Satoshi Nakamoto. Bitcoin white paper, 2008.

[55] Arvind Narayanan, Joseph Bonneau, Edward Felten, Andrew Miller, and Steven Goldfeder. Bitcoin and cryptocurrency technologies: a comprehensive introduction. Princeton University Press, 2016.

[56] Karl J O’Dwyer and David Malone. Bitcoin mining and its energy footprint. 2014.

74 [57] Aafaf Ouaddah, Anas Abou Elkalam, and Abdellah Ait Ouahman. Fairaccess: a new blockchain-based access control framework for the internet of things. Security and Communication Networks, 9(18):5943–5964, 2016.

[58] W Penard and T van Werkhoven. On the secure hash algorithm family. na- tional security agency. Technical report, Technical Report, 2008.

[59] Andrea Peterson. Hal finney received the first bitcoin transaction. here’s how he describes it. Washington Post, 3, 2014.

[60] Otto Julio Ahlert Pinno, Andr´eRicardo Abed Gr´egio,and Luis CE De Bona. Controlchain: Blockchain as a central enabler for access control authorizations in the iot. In GLOBECOM 2017-2017 IEEE Global Communications Confer- ence, pages 1–6. IEEE, 2017.

[61] Serguei Popov. The tangle. cit. on, page 131, 2018.

[62] Calvin Powers. A blockchain platform for the enterprise. https:// hyperledger-fabric.readthedocs.io/en/release-1.4.

[63] Larry Ren. Proof of stake velocity: Building the social currency of the digital age. Self-published white paper, 2014.

[64] Margaret Rouse, Michael Cobb, Margaret Rouse, and Margaret Rouse.

What is advanced encryption standard (aes)? https://searchsecurity. techtarget.com/definition/Advanced-Encryption-Standard.

[65] Michael Safi. Australian craig wright claims he is bitcoin founder

satoshi nakamoto. https://www.theguardian.com/technology/2016/may/ 02/craig-wright-bitcoin-founder-satoshi-nakamoto-claim, May 2016.

75 [66] Patrick Schueffel, Nikolaj Groeneweg, and Rico Baldegger. The crypto ency- clopedia. Technical report, Growth publisher, 2019.

[67] David Schwartz, Noah Youngs, Arthur Britto, et al. The ripple protocol consensus algorithm. Ripple Labs Inc White Paper, 5:8, 2014.

[68] Hossein Shafagh, Lukas Burkhalter, Anwar Hithnawi, and Simon Duquen- noy. Towards blockchain-based auditable storage and sharing of iot data. In Proceedings of the 2017 on Cloud Computing Security Workshop, pages 45–50. ACM, 2017.

[69] Sanjib Sharma. Markov chain monte carlo methods for bayesian data analysis in astronomy. Annual Review of Astronomy and Astrophysics, 55:213–259, 2017.

[70] Joao Sousa, Alysson Bessani, and Marko Vukolic. A byzantine fault-tolerant ordering service for the hyperledger fabric blockchain platform. In 2018 48th Annual IEEE/IFIP International Conference on Dependable Systems and Net- works (DSN), pages 51–58. IEEE, 2018.

[71] Christian Stoll, Lena Klaaßen, and Ulrich Gallersd¨orfer.The carbon footprint of bitcoin. Joule, 2019.

[72] Daniel Stutzbach and Reza Rejaie. Understanding churn in peer-to-peer net- works. In Proceedings of the 6th ACM SIGCOMM conference on Internet mea- surement, pages 189–202. ACM, 2006.

[73] Manuel Su´arez-Albela, Tiago Fern´andez-Caram´es,Paula Fraga-Lamas, and Luis Castedo. A practical evaluation of a high-security energy-efficient gateway for iot fog computing applications. Sensors, 17(9):1978, 2017.

76 [74] Harald Sundmaeker, Patrick Guillemin, Peter Friess, and Sylvie Woelffl´e.Vi- sion and challenges for realising the internet of things. Cluster of European Research Projects on the Internet of Things, European Commision, 3(3):34–36, 2010.

[75] Floris Van den Abeele, Jeroen Hoebeke, Ingrid Moerman, and Piet Demeester. Integration of heterogeneous devices and communication models via the cloud in the constrained internet of things. International Journal of Distributed Sen- sor Networks, 11(10):683425, 2015.

[76] Shu-Ching Wang, Kuo-Qin Yan, Chin-Ling Ho, and Shun-Sheng Wang. The optimal generalized byzantine agreement in cluster-based wireless sensor net- works. Computer Standards & Interfaces, 36(5):821–830, 2014.

[77] Hiroki Watanabe, Shigeru Fujimura, Atsushi Nakadaira, Yasuhiko Miyazaki, Akihito Akutsu, and Jay Kishigami. Blockchain contract: Securing a blockchain applied to smart contracts. In 2016 IEEE international conference on consumer electronics (ICCE), pages 467–468. IEEE, 2016.

[78] Wang Xiaofei, Hong Fan, Tang Xueming, and Cui Guohua. Merkle tree dig- ital signature and trusted computing platform. Wuhan University Journal of Natural Sciences, 11(6):1467–1472, 2006.

[79] Adam Young and Moti Yung. Finding length-3 positive cunningham chains and their cryptographic significance. In International Algorithmic Number The- ory Symposium, pages 289–298. Springer, 1998.

77 [80] Zibin Zheng, Shaoan Xie, Hongning , Xiangping Chen, and Huaimin Wang. An overview of blockchain technology: Architecture, consensus, and future trends. In 2017 IEEE international congress on big data (BigData congress), pages 557–564. IEEE, 2017.

[81] Guy Zyskind, Oz Nathan, et al. Decentralizing privacy: Using blockchain to protect personal data. In 2015 IEEE Security and Privacy Workshops, pages 180–184. IEEE, 2015.

78 Appendix

Scoring Trust

1. Number of times the device provided a service to any other devices – 5 points

2. Number of times the device provided the requested service to any other devices – 5 points

3. Number of times the device provided a service to the requester – 5 points

4. Number of times the device provided the requested service to the requester – 5 points

5. Last time the device provide the requested service – 5 points

6. Year of device production – 5 points

7. Hardware required – 5 points

79