A Blockchain Approach for Negotiating Trust in IoT by
90
A Blockchain 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
A Blockchain Approach for Negotiating Trust in IoT by
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