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
All Rights Reserved
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:
Author:
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.
2 Background 5
2.2.1 Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.3 Mining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.5.1 IOTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.5.2 Ripple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 Approach 39
3.2.2.1 Blockchain Code . . . . . . . . . . . . . . . . . . . 47
3.2.2.3 Algorithm for Establishing Trust . . . . . . . . . . 48
3.2.2.4 Blockchain Structure . . . . . . . . . . . . . . . . . 51
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
2.4 Blockchain Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Compass Seed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4 IRI Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 JavaScript File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.1 New Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
vii
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.
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 Bitcoin 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.
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.
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 in the
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 cryptocurrency 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 cryptography 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 we got 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 Bitcoins. 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 not able to
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
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 Proof of Work, 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 agree to
create a consensus [67].
Hyperledger-Fabric is a system that uses a permissioned blockchain. It is a dis-
tributed ledger that uses a smart contract 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 used by
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 has a
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 Bitcoin network 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 cryptocurrencies/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 Scrypt. 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
artificial intelligence and big data for carrying autonomous transactions by using
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.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 of the
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 tip of the
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 of trans-
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 Solidity 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 a lot
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
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.
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 or pro-
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 user needs
to have the following:
• At least 8GB RAM
• 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
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, and it is
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 we had a
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
• 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 the top
to the bottom and defines who can read, create, update, and delete items in the
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 of users
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 test tab,
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) is entering
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.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.
p a r t i c i p an t Device i d e n t i f i e d by dev i c e Id {
o St r ing dev i c e Id
o St r ing deviceName
o Se r v i c e s [ ] s e rv i c eProv ided
o ProductionYear 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:
Gc = num transactions
num devices Gr =
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.
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.
Normalized Score = total score
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 a Private
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
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 tha