See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/344629764

Securing Internet of Things (IoT) devices using Hyperledger Fabric

(Blockchain technology)

Thesis · October 2020

CITATIONS READS

0 3,300

1 author:

Ebenezer Chinyati
University of Westminster
1 PUBLICATION   0 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Securing Internet of Things (IoT) devices using Hyperledger Fabric (Blockchain technology) View project

All content following this page was uploaded by Ebenezer Chinyati on 24 December 2020.

The user has requested enhancement of the downloaded file.

 Page |i

UNIVERSITY OF WESTMINSTER

MSc CYBER SECURITY AND FORENSICS THESIS

Securing Internet of Things (IoT) devices using

Hyperledger Fabric (Blockchain technology)

Author : Supervisor:
Eben-Ezer CHINYATI Chee YEUNG

This report is submitted in partial fulfilment of the requirements

for the degree in Cyber Security & Forensics MSc at the
University of Westminster.
in the

Cyber Security Research Group

Department of Computer Science

September 7, 2020
 P a g e | ii

Declaration
I Eben-Ezer Chinyati, declare that this Master of Cyber Security & Forensics thesis is my own
effort except where sources have been acknowledged. The research in full or part thereof has
never been submitted, nor will it ever be, to another university/institution for examination in the
awarding of a degree.
No part of this dissertation may be reproduced, stored in any retrieval system, or transmitted
in any form, or by any means without the prior express authorisation from me the author or
University of Westminster on my behalf. Thus, I, Eben-Ezer, grant University of Westminster
permission to store in full, reproduce or transmit this thesis in whole or in part which University
of Westminster may deem fit.

Eben-Ezer Chinyati

7TH of September 2020

 P a g e | iii

DEDICATION

I dedicate this thesis to Dr Tracy Kandeya, my mum, superhero, best friend, and top
supporter. Thank you for all the love and unwavering support.
 P a g e | iv

ACKNOWLEDGEMENTS

First and foremost, I would like to acknowledge that this thesis would not have been possible
without the abundant grace of God in my life. All my achievements are because of his grace
and mercy.
This thesis has come to fruition due to the support and encouragement I have received from
special people in my life.
• I would like to thank my supervisor Chee Yeung for providing guidance and feedback
throughout this project .
• My deepest appreciation goes to the University of Westminster and DCDI college for
giving me the full scholarship.
• I would like to express my gratitude to International Students House for providing me
with accommodation during my studies.
• To my friends and classmates, it has been an honour to go through this journey with
you all.
• Finally, I would like to thank my family for being supportive, encouraging and loving
throughout this process.
 Page |v

ABSTRACT

The eminence of IoT devices has been coupled with security vulnerabilities and exploitation.
Security concerns have brought up additional issues such as interoperability and
computational power of the IoT devices. Blockchain technologies have been embraced for
security solutions in IoT, due to their decentralisation and secure design. In this research
evaluation of Blockchain and Hyperledger Project frameworks is conducted, leading to an
implementation and evaluation of Hyperledger Fabric securing IoT devices.

Hyperledger Fabric an open source blockchain framework was implemented on AMD64 and
ARM64 architectures using docker swarm for multi host configuration. Raspberry Pi 4 was
used as the IoT device with ARM64 architecture, whilst a Kali Linux virtual machine was the
AMD64 powered host. With the latest stable v2.1.0 Hyperledger Fabric images were built for
IoT architecture ARM64 since it is not supported. The two host implementation outlined root
of trust models using Raft ordering service and access control through chaincode execution.
Successfully evaluated the Hyperledger Fabric blockchain implementation using Prometheus
and chaincode testing.
 P a g e | vi

CONTENTS
Dedication ............................................................................................................................................. iii

Acknowledgements ............................................................................................................................. iv

Abstract .................................................................................................................................................. v

1 Introduction ................................................................................................................................. 1

1.1 Introduction and Motivation ..................................................................................................... 1

1.2 Problem Definition ................................................................................................................... 3
1.3 Limitations ............................................................................................................................... 3
1.4 Thesis outline .......................................................................................................................... 4

2 Background & Related Work ..................................................................................................... 6

2.1 Blockchain ............................................................................................................................... 6

2.1.1 Types of Blockchains ...................................................................................................... 7
2.1.2 Blockchain is not cryptocurrency ..................................................................................... 8
2.2 Blockchain powered IoT solutions........................................................................................... 9
2.2.1 Root of trust in IoT ........................................................................................................... 9
2.2.2 Access control in IoT ..................................................................................................... 10
2.3 Proposed Solution ................................................................................................................. 12

3 Hyperledger Framework ........................................................................................................... 13

3.1 Introduction to Hyperledger Project ...................................................................................... 13

3.2 Hyperledger Fabric ................................................................................................................ 14
3.2.1 Fabric Network .............................................................................................................. 14
3.2.2 Ledger and World state ................................................................................................. 15
3.2.3 Chaincode/Smart Contracts .......................................................................................... 16
3.3 Identity management ............................................................................................................. 17
3.3.1 Public Key Infrastructure ............................................................................................... 17
3.3.2 Membership Service Provider ....................................................................................... 18
3.3.3 Cryptogen or Certificate Authority ................................................................................. 18
3.4 Consensus Mechanisms ....................................................................................................... 19
3.4.1 Byzantine Generals Problem ........................................................................................ 20
3.4.2 Raft Ordering Service .................................................................................................... 20
3.4.3 Transaction Flow ........................................................................................................... 21
3.5 Docker ................................................................................................................................... 22
3.5.1 Dockerfile ...................................................................................................................... 22
3.5.2 Docker images .............................................................................................................. 22
3.5.3 Docker compose ........................................................................................................... 23
3.5.4 Docker container ........................................................................................................... 23
 P a g e | vii

3.5.5 Docker swarm ............................................................................................................... 24

3.6 Conclusion............................................................................................................................. 25

4 Internet of Things Technology ................................................................................................ 27

4.1 Introduction to Internet of Things Solutions .......................................................................... 27

4.2 Internet of Things Platform .................................................................................................... 28
4.2.1 Edge Interface, Message Broker & Message Bus ........................................................ 29
4.2.2 Message Router and Communication Management..................................................... 29
4.2.3 Storage and data management ..................................................................................... 29
4.2.4 Rule Engine ................................................................................................................... 30
4.2.5 Device Manager ............................................................................................................ 30
4.2.6 REST API Interface ....................................................................................................... 30
4.2.7 Microservices ................................................................................................................ 30
4.2.8 Application and user management................................................................................ 30
4.3 Issues and Challenges in Internet of Things ......................................................................... 30
4.3.1 Security ......................................................................................................................... 31
4.3.2 Privacy ........................................................................................................................... 31
4.3.3 Data management ......................................................................................................... 31
4.4 Current access control mechanisms in Internet of Things .................................................... 31
4.5 A type of Internet of things device ......................................................................................... 32
4.5.1 Raspberry Pi device ...................................................................................................... 32
4.5.2 Raspbian OS ................................................................................................................. 33
4.5.3 Raspberry Pi’s General-Purpose Input/output .............................................................. 34

5 Architecture and design ........................................................................................................... 35

5.1 System design ....................................................................................................................... 35

5.2 Hyperledger Fabric images ................................................................................................... 36
5.3 Network setup ....................................................................................................................... 36
5.4 Identity and Crypto materials ................................................................................................ 37
5.5 Hyperledger Nodes ............................................................................................................... 37
5.6 Fabric chaincode design ....................................................................................................... 38
5.7 Issues and Concerns ............................................................................................................ 39

6 IMPLEMENTATION .................................................................................................................... 40

6.1 Hyperledger images and binaries ......................................................................................... 40

6.1.1 Installing Fabric images, samples, and binaries on Kali ............................................... 41
6.1.2 Building Hyperledger Images for Raspberry Pi 4 .......................................................... 42
6.2 Hyperledger fabric network design ....................................................................................... 43
6.2.1 Docker Swarm connection ............................................................................................ 43
6.3 Configuring Identity and Channel definitions ........................................................................ 44
6.3.1 Crypto materials ............................................................................................................ 44
 P a g e | viii

6.3.2 Channel artifacts and genesis block ............................................................................. 46

6.4 Starting the Hyperledger fabric network ................................................................................ 49
6.4.1 Docker containers for Hosts .......................................................................................... 49
6.4.2 Joining Peers to Channel .............................................................................................. 50
6.5 Access control Chaincode ..................................................................................................... 51
6.5.1 Imports .......................................................................................................................... 52
6.5.2 Struct ............................................................................................................................. 52
6.5.3 Functions ....................................................................................................................... 52
6.6 Deploy Chaincode ................................................................................................................. 53
6.6.1 Packaging Chaincode using cli container ..................................................................... 53
6.6.2 Installing Chaincode on peers ....................................................................................... 54
6.6.3 Approve Chaincode definition for Organization ............................................................ 55
6.6.4 Commit the chaincode to channel ................................................................................. 55
6.6.5 Access control operation ............................................................................................... 57
6.7 Summary of the Chapter ....................................................................................................... 58

7 Evaluation .................................................................................................................................. 60

7.1 Blockchain Info ...................................................................................................................... 60

7.2 Chaincode Testing ................................................................................................................ 61
7.3 Metrics generation with Prometheus ..................................................................................... 62
7.3.1 Ledger Blockchain height .............................................................................................. 64
7.3.2 Server unary requests ................................................................................................... 64
7.3.3 Process virtual memory ................................................................................................. 65

8 Conclusion ................................................................................................................................ 67

8.1 Summary ............................................................................................................................... 67

8.2 Contributions ......................................................................................................................... 68
8.3 Future Work........................................................................................................................... 68

BIBLIOGRAHPY ................................................................................................................................... 70

Appendix A: System specifications and configurations ................................................................ 78

Appendix B: Building Hyperledger v2.1 docker images and binaries for Raspberry Pi 4 for
ARM64/aarch64 ................................................................................................................................... 82

Appendix C: Setup Operations Service and Prometheus for metric benchmarking ................... 88

Appendix D: Access control Chaincode ........................................................................................... 89

Appendix E: Host yaml files to build up docker containers ........................................................... 91

 P a g e | ix

LIST OF FIGURES
Figure 1:1 - IoT Pyramid Structure .......................................................................................................... 1
Figure 2:1 - Illustration of Blockchain from the genesis block until there is a fork in the chain .............. 7
Figure 3:1 - Illustration of transactions within Hyperledger fabric network ........................................... 15
Figure 3:2 - Blockchain illustration with genesis block and preceding blocks containing block data
(Hyperledger-fabric, 2020b) ......................................................................................................... 16
Figure 3:3 - Public Key Infrastructure Illustration, showing the requesting/issuance and revocation of
certificates from (HyperledgerDocs, 2020) ................................................................................... 17
Figure 3:4 - Crypto materials generated through use of cryptogen binary tool in Hyperledger fabric
(KC Tam, 2020) ............................................................................................................................ 19
Figure 3:5 - Raft process of election of a follower to candidate when no communication is received,
then elected leader (Ongaro and Ousterhout, 2014) ................................................................... 21
Figure 3:6 - Illustration of docker container layers operating on top of docker images within Docker
environment .................................................................................................................................. 23
Figure 3:7 - Docker Swarm illustration with Manager node and Worker node ..................................... 25
Figure 4:1 - IoT illustration of devices connecting to gateways feeding into the IoT platform accessed
by Applications. ............................................................................................................................ 28
Figure 4:2 - Blocks found within an IoT platform, with external connections to IoT devices,
applications, and other systems ................................................................................................... 29
Figure 4:3 - Raspberry Pi 4 device (Raspberry Pi Foundation, 2020) .................................................. 33
Figure 5:1 - Setup of system with Raspberry Pi 4 connected to Windows 10 machine through an
ethernet cable. Accessing the Kali Linux Virtual machine using Virtual Box & with Remote
desktop have GUI access of the Pi device ................................................................................... 35
Figure 5:2 - Hyperledger Fabric network operating on two hosts being managed by a docker swarm
cluster with an overlay network managing the communication .................................................... 38
Figure 6:1 - Docker images on Kali Linux amd64 Virtual machine. ...................................................... 41
Figure 6:2 - Hyperledger fabric binaries for Kali Linux .......................................................................... 42
Figure 6:3 - Docker images for Raspberry Pi 4, with the different version tags ................................... 43
Figure 6:4 - Docker swarm output on both Kali and Raspberry Pi devices .......................................... 44
Figure 6:5 - Crypto material folder structure showing the generated components in both
ordererOrganizations and peer Organizations. ............................................................................ 46
Figure 6:6 - Directory structure of the generated channel artifacts ...................................................... 49
Figure 6:7 - Creating docker containers on Host1 (kali Linux VM), listed the docker containers to
show their status and names ........................................................................................................ 50
Figure 6:8 - Output from both Kali and Pi hosts showing the peers having joined the channel
"ebenezer". The Current Blockchain info showing height as 2 is outputted, height is 2 which
includes genesis block and channel file. ...................................................................................... 51
Figure 6:9 - Access.go chaincode imports ............................................................................................ 52
 Page |x

Figure 6:10 - Set function using the client identity library to provide access control against non Admin
accounts ....................................................................................................................................... 53
Figure 6:11 - Chaincode deployment process, going through the various stages from packaging to
invocation ..................................................................................................................................... 53
Figure 6:12 - Output of the packaged access.tar chaincode ................................................................ 54
Figure 6:13 - Chaincode installation using CLI container. Chaincode is installed on both Pi and Kali
VM with a package identifier being generated ............................................................................. 55
Figure 6:14 - Chaincode approval, checking if parameters are valid across the organization, used a
Certificate file to verify identities and now chaincode is being checked in "ebenezer" channel .. 55
Figure 6:15 - Checking chaincode commit-readiness. There is need to state parameter values and
channel name ............................................................................................................................... 56
Figure 6:16 - Committing the chaincode to both peer0.org1.example.com and
peer1.org1.example.com and also referencing the crypto materials ........................................... 56
Figure 6:17 - Invoking chaincode to view current value in block .......................................................... 57
Figure 6:18 - Querying the newly added name value. On both Kali and Pi using the cli container get
the same output ............................................................................................................................ 57
Figure 6:19 - Query on ledger using "User1" account to show access control for when 'set' function is
called and it is against endorsement policy. ................................................................................. 58
Figure 6:20 - Setting new name value using Admin account on chaincode ......................................... 58
Figure 7:1 - Blockchain info showing current and previous Block Hashes, each new block has a
connection to the previous height record ..................................................................................... 60
Figure 7:2 - Demonstration of chaincode testing using golang testing code with specific invocation of
functions ....................................................................................................................................... 61
Figure 7:3 - Health check on Raspberry Pi device ............................................................................... 62
Figure 7:4 - Targets listed in Prometheus, the targets include the containers on kali VM and
Raspberry Pi ................................................................................................................................. 63
Figure 7:5 - Ledger blockchain height query showing the changes occurring on both peers .............. 64
Figure 7:6 - Unary requests count on nodes within the two hosts ........................................................ 65
Figure 7:7 - Virtual memory consumed on both Raspberry Pi and Kali Linux ...................................... 66
 P a g e | xi

LIST OF TABLES
Table 2:1 - Blockchain types & characteristics ....................................................................................... 8
Table 4:1 - Comparison of ARM 64bit based Operating Systems ........................................................ 34
Table 5:1 - Hardware specifications of devices used in the implementation of this project ................. 36
Table 5:2 - Overview of VirtualBox Networking modes (VirtualBox, 2019) .......................................... 36
Table 5:3 - Host IP addresses for Kali and Pi device after network setup ............................................ 37
Table 6:1 - Hyperledger Fabric Prerequisites versions used on the AMD64 and ARM64 architectures
...................................................................................................................................................... 40
Table 6:2 - Versions for key docker image source code. ...................................................................... 40
 P a g e | xii

LIST OF LISTINGS
Listing 6:1 - Adding binaries path to environment ................................................................................. 42
Listing 6:2 - Crypto-config.yaml file ....................................................................................................... 45
Listing 6:3 - Generate crypto-material using the crypto-config.yaml file and place in folder ................ 45
Listing 6:4 - Orderer section within the crypto-config.yaml file ............................................................. 47
Listing 6:5 - Capabilities section within the crypto-config.yaml file ....................................................... 48
Listing 6:6 - Generating genesis block with a channel ID to be saved in the channel-artifacts directory
...................................................................................................................................................... 48
Listing 6:7 - Generating the channel.tx artifacts using a new channelID “ebenezer”, this will be the
channel name used in this implementation .................................................................................. 48
Listing 6:8 - Creating channel using the peer binary tool and pointing to the orderer on Host 1.
Channel name is "ebenezer" and it takes configurations from earlier created channel.tx file ..... 51
Listing 6:9 - Command to join the peer0.org1.example.com on host 1 to the channel......................... 51
Listing 6:10 - Joining peer1.org1.example.com to the channel, this peer is running on Host2 (Pi 4
device) hence the need to define some of the variables within the Kali VM cli container ............ 51
Listing 6:11 - Packaging access chaincode and providing a label. This execution is done in cli
container on Raspberry Pi device ................................................................................................ 54
Listing 6:12 - Querying the committed chaincode and producing chaincode definition parameters as
json output .................................................................................................................................... 56
 Page |1

1 INTRODUCTION

1.1 Introduction and Motivation

Internet of Things (IoT) refers to a wide range of smart objects that are networked together
and to the internet. These objects contain microcontrollers and sensors that collect data from
surroundings and provide an assigned function with software and data management controlled
by centralized systems (Ali, Dolui and Antonelli, 2017). IoT objects in industry and society
include smart home, wearables, smart city, smart grids, digital health, workstations etc. The
widespread adoption of IoT objects and their inter-connectedness presents security and
privacy concerns for users as data generated can be sensitive and private.

International data corporation (IDC) in its 2019 forecast predicts over 40 billion IoT devices
will be generating over 75 billion zettabytes (ZB) of data in 2025 (Framingham, 2019). IoT
objects are separated into a five layered pyramid as shown in Figure 1:1 - IoT Pyramid
Structure, using the IDC 40 billion estimate the fifth layer of IoT objects would contain over 30
billion objects by 2020. The devices in the fifth layer are the most constrained with less
memory, less computational power and hence more at risk of cyber-attacks and exploitation.

Figure 1:1 - IoT Pyramid Structure

In the IoT pyramid at the very top are cloud servers, these are centralized system controllers
owned by third parties (Amazon, Microsoft, IBM etc.). IoT solutions are mostly dependent on
a centralized cloud server architecture to store data storage, authentication, communication
and any required services (Cheruvu et al., 2020). Using centralized IoT solutions has
 Page |2

security and trust issues since users have to trust proper handling of data and no mass-
surveillance as discussed by the Guardian (Greenwald and Macaskill, 2013).

Security vulnerabilities from IoT objects when harnessed together can cause disruption as
shown in 2016 through an IoT botnet which caused a Distributed Denial of Service (DDoS)
attack against a critical internet provider bringing down Twitter, Reddit, and Spotify. These
types of attacks are becoming frequent and difficult to fix, since it’s hard to identify which one
system is faulty, in some instances it’s communication channels or default passwords that
are exploited by attackers (Gurunath et al., 2019).

Existing security concerns in IoT can be addressed through use of decentralized architectures
which have security and privacy inherent. Blockchain is a decentralized and distributed global
ledger that is tamper-proof allowing storage of any digital asset (Elrom, 2019). Blockchains
became popular around 2008/2009 due to the advent of Bitcoin and cryptocurrencies. In
modern Blockchain technologies like Ethereum they make use of smart contracts which are
programmable code that can execute without need of third parties. Blockchain has been
researched into, to see if it can offer any benefits to IoT, some of these benefits include:
• Fault tolerance - use of a decentralized architecture provides fault tolerance and
removes the risk of a single point of failure and any downtime as information is
distributed.
• Transparency - prevents third-party actors having access to IoT data without users
having knowledge on what data is being accessed, since records are logged, there is
facility for tracing.
• Anonymity – through use of digital certificates and cryptographic functions
participants are allocated addresses and private keys which they use to access
blockchain ensuring pseudo-anonymity.
• Secure - IoT objects can verify data being sent as well as the sender without having
to depend on centralized servers for the computation of the requests. This data when
added on the blockchain cannot be deleted or altered.
• Concurrency – using lightweight blockchain solutions multiple users can have access
to resource at the same time without worrying about device’s computational power.
• Immutability - through logs of activity for devices and any interactions amongst IoT
objects this guarantees auditability and trust between actors.
• Automation & Logic - smart contracts provide programmable logic to the distributed
system with the logic being executable. Solutions for access control and root of trust
can be accessed through smart contracts.
 Page |3

Existing access control solutions for IoT are centralized and based on models like role-based
access control model (RBAC), attribute-based access control model (ABAC). These model’s
use of a centralized entity brings challenges such as single point of failure. There is a need for
a distributed and trusted access control mechanisms for IoT since the old methods are not
sustainable. IoT objects in homes, industry do not have any trust of each other which makes
them all vulnerable to attacks, hence the need for a root of trust for a group of objects in the
same environment.

The research’s objective is to evaluate access control and root of trust models for IoT objects
powered by a permissioned blockchain in Hyperledger Fabric framework. Due to the
immutability of data in Blockchain and its use of cryptographic functionalities, implementation
of access control on IoT devices can be achieved. Root of trust models intend to address
security needs within IoT devices providing a set of security measures like key storage,
cryptographic functions, and secure communication between device to device and device to
human. Focus on implementation and evaluations was made on the performance of the
deployed system taking various use-cases into account.

1.2 Problem Definition

Based on the background and motivation section, research’s intention is to provide an access
control and root of trust solution for IoT devices built on Hyperledger Fabric framework. Using
Hyperledger Fabric, the following questions were investigated:
1. Blockchain when applied to IoT devices can achieve gains for Confidentiality and
Integrity compared to the current approaches?
2. Hyperledger Fabric smart contracts help in ensuring access control and root of trust
models for IoT objects?
3. Can Blockchains be integrated with existing IoT devices despite computational and
architectural limitations?

1.3 Limitations
Blockchains are not compatible with most IoT devices due to computational requirements and
bandwidth overheads. This research primarily focused on Hyperledger Fabric (HLF)
framework, specifically version 2.1.0. There are other permissioned blockchain solutions in
the industry that could be tested however, due to time and resources the research only
focused on one.
 Page |4

HLF is a growing framework with lots of open issues and bugs, during the development have
faced several challenges that have led to some compromises. Currently there are no docker
images for ARM64 architecture from HLF, this led to creation of Debian:buster ARM64 images.
Building these docker images without any documentation made it strenuous and time
consuming, to the best of my knowledge this research is the first to build docker images for
ARM64 using HLF v2.1. Chosen HLF version was selected due to it being on long term support
having been released in April 2020 (Fabric, 2020b).

Hyperledger project provides a testing framework in Hyperledger Caliper. In this research was
dependent on the testing metrics and benchmarking from this solution, however the tool only
supports HLV v1.X. This limited the evaluation to use of Hyperledger fabric operations service
and Prometheus which did not cover elements like transaction latency.

The proposed solution was developed on a limited hardware environment due to resource and
time constraints. Due to the Corona virus have been limited on the computational power that
could be used for performance tests and benchmarking since University is closed for access.
However, have tried to create an environment that can show the proposed solution
convincingly.

1.4 Thesis outline

The rest of this research is divided as below:
• Chapter 1 introduced the concept of IoT objects, challenges with the current systems
and how blockchain can be integrated to offer solutions.
• Chapter 2 discusses Blockchain background and related work in Blockchain solutions
for IoT.
• Chapter 3 focuses on the main tool used for the implementation of the solution in this
research namely Hyperledger Fabric.
• Chapter 4 discusses IoT terms, communication protocols and device used in the
research.
• Chapter 5 discusses the architecture and design of the system with the proposition to
solve problems.
• Chapter 6 discusses the implementation of HLF on AMD64 and ARM64 architecture
leading to chaincode execution.
• Chapter 7 evaluates the implemented solution, looking at chaincode testing,
Blockchain info and metrics.
 Page |5

• Chapter 8 summarizes the findings from the research, future work and concludes the
research.
 Page |6

2 BACKGROUND & RELATED WORK

This chapter reviews the background of Blockchain technologies, looking at the various
Blockchain types and the relationship between Blockchain and cryptocurrency. Blockchain
technologies have been at the forefront of offering advantages like decentralization,
cryptographic functions, secure by design and scalability. The chapter further discussed what
researchers have proposed to solve existing IoT issues through use of Blockchain
technologies and it was concluded by showing the gap in the available literature and how this
research’s proposed solution is novel.

2.1 Blockchain
Blockchain is defined as a decentralized distributed and transparent global ledger of recorded
data (Elrom, 2019). Blockchains record data and duplicate it across the distributed network,
new transaction entries are added to the end of the collection, each data entry is saved as a
block which is linked to the next data set coining the name blockchain. Blockchains are
maintained and validated by the participants in a network referred to as nodes.

Distribution of the blockchain ledger across nodes ensures transparency as the same
information chain across the network is shared. Participating nodes within a network perform
validity checks on added blocks within the network accepting and rejecting entries using set
validations methods known as consensus mechanisms (Cachin, Schubert and Vukolić, 2017).
Consensus mechanisms are cryptographic algorithms used to ensure correct ordering of
transactions within a blockchain.

Blockchain uses peer-to-peer (P2P) as its network architecture which satisfies the
decentralization goal of blockchains whilst also ensuring no single-point of failure. In P2P
network participants can share and communicate without the need of any central authority.
Participants on the blockchain are allocated keys that are generated cryptographically unlike
login credential systems in centralized architectures. The cryptography functionality provides
a blockchain address and private key code that are specific to that user alone, providing users
with anonymity since no key code is similar and it is difficult to link an address to participant.

Every block contains a block header in which a unique hash referred to as merkle root
identifies the current block, hash for previous block and a transaction list with new transactions
 Page |7

is also found in block. Blocks will contain the same number of transactions in the data
structure; however, different users will have different transactions. For ease of identification,
different blocks are issued a timestamp at creation which is usually different. A genesis block
is the first block in a Blockchain with all preceding blocks linking from those before them. In
some instances, there are blocks which can link to the same predecessor if created around
the same time and this is called forking.

Figure 2:1 - Illustration of Blockchain from the genesis block until there is a fork in the chain

2.1.1 Types of Blockchains

There are three types of blockchain implementations namely public, private and consortium.
These are used for applications and use cases that can store various digital assets, a digital
asset is anything that an owner places value on (Elrom, 2019).
• Public - accessible to anyone who needs to read and write transactions and it is not
owned by any single entity. To access this type of blockchain one needs a computer
and supporting software applications or creation of an account (Vemuri, 2018). Most
cryptocurrencies are operated on open/public blockchains providing the
decentralization and anonymity not provided by banks.
• Private – within private blockchain participants are chosen and granted read/write
access by an organisation or administrator who controls the ledger (Vemuri, 2018).
Consensus mechanisms in private blockchains differ according to need and design,
however, these all depend on an entity appointing nodes that are reliable within the
network to endorse and order transactions. Private blockchains are usually adopted
for enterprise use, an example of private blockchains is Hyperledger fabric which is
being adopted by industry and governments for different use cases like Supply chain,
voting etc.
• Consortium - this blockchain can allow or deny read/write to the public or limit it to a
group of participants. This is a combination of private and public blockchains.
 Page |8

Table 2:1 - Blockchain types & characteristics

Type Details Example of Characteristics

BC
Public Blockchain Participants can access Ethereum, Scalability challenges,
(Permissionless) and create transactions, Bitcoin Requires a lot of computational
Nodes can be executed by power for mining,
any valid participant Provides anonymity,
Performs slow due to speeds of
consensus algorithms.
Private Controlled by a few parties Hyperledger, Performs better and offers
Blockchain who add participants, Ripple scalability,
(Permissioned) Not available to any Faster consensus algorithms and
requesting participant does not require mining from
nodes,
Not as decentralized due to
controlling parties who oversee
participants.

2.1.2 Blockchain is not cryptocurrency

In 2009 after the economic depression a proof of concept was released for a disruptive
currency coined Bitcoin. This was the first real successful implementation of cryptocurrency
which has its origins back to the later 90s (Bitcoin.org, 2020). Bitcoin was successful mainly
because of its use of digital signature, not having centralized authority, being public and open
source. Cryptocurrencies have evolved over the years to become the use of cryptography
techniques that is encryption and decryption to transfer a digital asset (Elrom, 2019). A digital
asset refers to anything that holds value and sentimental value to the owner, this could be
money, documents, photos etc.

Cryptocurrencies like Bitcoin and 6000 more as per Coinmarkert.com are based on a type of
Blockchain. They are basically a single use case of blockchain technology which is a shared
digital decentralized database. Blockchain as discussed above can be applied to various
industries and solve many real life issues like healthcare, energy generation, supply chain,
voting etc (Houben and Snyers, 2018). Hyperledger Project offers different types of blockchain
technologies that do not offer any crypto coin/token but addresses enterprise problems. Below
are some of the use cases powered by Hyperledger Project frameworks:
 Page |9

1. National Bank of Cambodia - leveraging on Hyperledger Iroha to solve country’s

banking challenges which include creation of a modern digital payment system that is
fast and secure (Hyperledger.org, 2020)
2. Walmart – creating transparency within their supply chain through use of Hyperledger
Fabric, this project was undertaken through partnership with IBM (Biser Dimitrov,
2020).
3. British Columbia – British Columbia and Ontario governments looked at ways to help
minimise government red tape by using software stack to empower businesses to
establish trusted and enduring relationship. The blockchain framework used for this
project is Hyperledger Indy and system was announced in January 2019
(Hyperledger.org, 2019).

2.2 Blockchain powered IoT solutions

Blockchain is a distributed ledger technology (DLT) and El loini and Pahl (2018) had a survey
of DLTs showing the different advantages. Blockchain has become a leading DLT with various
types that have different implementations and advantages. Maple and Jackson (2019) discuss
the different types of Blockchains with focus on showing the most effective Blockchain
technologies to create applications. A number of blockchain based applications have been
proposed and researched, Casino, Dasaklis and Patsakis (2019) have a literature of the
applications highlighting any gaps and shortcomings of these applications.

The computational overheads that deter IoT solutions based on blockchains were tackled by
Dorri, Kanhere and Jurdak, (2017) through their optimized blockchain solution that is
lightweight. Their proposed blockchain did not require mining methods for consensus,
however, their proposed solution did not evaluate the security challenges brought by their new
architecture.

2.2.1 Root of trust in IoT

The core of security in any system are confidentiality, integrity, and availability. Ensuring the
security triad is met in IoT objects is a challenge due to the devices being resource constrained
and not being able to adopt some of the security techniques available. In this section the root
of trust research that has been done in relation to IoT devices has been covered.

In Mansour and Lauf, (2020) proposed an efficient and secure authentication architecture to
be used with IoT objects through eliminating key storage on centralized systems and device
memory. The solution is powered by use of lightweight cryptography and hardware hardening
 P a g e | 10

techniques. Traditional cryptography solutions require more computational energy which IoT
devices do not offer and these IoT objects have little storage and memory to be able to handle
keys on local storage.

Wrona and Jarosz, (2019) discuss proof of concept on how blockchains can be used to store
metadata from IoT objects in a military setup. It is hard to find root of trust in a scenario where
there are a lot of devices across multiple environments and organisations that are disjointed
but sharing information and data. In this proof of concept, they also discuss the trust
advantages given by HLF and how it would fit into their idea.

Ali, Dolui and Antonelli, (2017) propose an IoT data privacy solution using Ethereum
blockchain and a filesystem. The proposed architecture used software stack of blockchains
holding the hashes and the InterPlanetary File System (IPFS) filesystem for storage of data.
Using the Public Key Infrastructure (PKI) facility in blockchains, root of access can be attained
through use of smart contracts storing user keys (Ali, Dolui and Antonelli, 2017). Ali, Dolui and
Antonelli, (2017) intend to implement the proposed solution and test their architecture on
permissioned blockchains to see if they will offer better performance and any enhancements
to their architecture.

2.2.2 Access control in IoT

In a survey by Ouaddah et al., (2017) they asked questions regarding the current state of
centralized access control standards in IoT and whether there was a need to have new
mechanisms for IoT alone. The current access control systems were not designed for
constrained devices and most are centralized bringing scalability, interoperability, and end-to-
end security issues. Use of centralized access control is also argued against in this survey as
it is expensive and requires users to trust their data to third parties. Adoption of decentralized
access control approach has more advantages but also shows drawbacks like difficulty to
update the access control policies, however through use of smart contracts in a blockchain
like HLF updates can be easily pushed (Rocha and María Teresa Nieto, 2020).

Access control solutions based on blockchain solutions are mostly using Ethereum, these
implementations use proof of stack for consensus and this brings challenges like the no-stack
conundrum (Ouaddah, Elkalam and Ouahman, 2017). An implementation was discussed
using smart contracts on Ethereum, however, there was the cost limitation due to need of
miners for consensus protocols in Ethereum (Zhang et al., 2019). There are other access
control solutions that are not based on blockchain technologies, Hameed and Alomary, (2019)
 P a g e | 11

discussed the use of a software defined networking (SDN) solution. This solution will be
issuing certificates to IoT devices which they will use to communicate to a gateway before
authentication, this can be achieved by HLF, whilst adding scalability and decentralization.

Novo, (2018) discussed an architecture which would use blockchain to provide IoT access
control solutions. Proposed solution does not integrate the IoT devices directly instead uses a
hub to manage access requests, this has security issues as the hub can be spoofed, altered,
and compromised. The design requirements followed with the use of an Ethereum blockchain
requiring crypto fees increases processing time due to transfer of messages from IoT devices
to the managing hub linked to the Blockchain. Use of a Blockchain solution that provides digital
certificates to nodes could solve some of these concerns (Novo, 2018).

An authentication protocol PAuthKey was proposed which interacts with edge device
registering them and then performing authentication (Porambage et al., 2014). This solution
was for those devices that are resource constrained which encompasses much of the IoT
ecosystem. Sharaf-Dabbagh and Saad, (2016) in their research took the approach of using
device unique fingerprint to provide authentication. The conventional device fingerprinting
cannot be used for IoT object’s cause of their different architectures, in this research they
proposed a way to compute that fingerprint and authentication performance increased.

A survey of Hyperledger frameworks done by Ban et al., (2019) showed that HLF can handle
organization level and role based access control on channels using smart contracts. Rouhani,
Pourheidari and Deters, (2018) proposed a permissioned blockchain solution for access
control, however this solution was not for IoT objects and used role based access control
(RBAC) which does not fit well with IoT.

Smart contracts are programmable logic that is executed within a group of participants who
are non-trusting, the most used platform for smart contract execution is Ethereum blockchain.
Ethereum uses a high-level programming language for the creation of its smart contracts in
the form of Solidity, this implementation comes with errors due to lack of skill, lack of proper
documentation and unknown vulnerabilities (Atzei et al., 2017). Implementation of smart
contracts and the vulnerabilities they pose for blockchain powered solutions was researched
by Parizi et al. (2018) showing the challenges with Solidity for Ethereum and also generic
programming languages for platforms like Hyperledger fabric.
 P a g e | 12

2.3 Proposed Solution

In this thesis, a Hyperledger fabric blockchain framework was used to propose a solution to
secure access control and root of trust model for IoT objects. Hyperledger fabric is a private
(permissioned) blockchain which means there will be control mechanisms for which
participants can have permissions to the ledger. Hyperledger fabric by design makes use of
encryption protocols, access policies and cryptographic functions that make it secure from
malicious attacks. An attributed based access control (ABAC) method was implemented using
Hyperledger fabric components since ABAC applies to IoT devices as compared to role-based
access control (RBAC).

Membership Service Provider is the certificate authority in HLF, it manages X.509 certificates
for identity management of participants. Using this facility access control mechanisms can be
implemented, and user privacy can also be ensured since the certificate authority makes use
of public/private key protecting user identities. Leveraged on smart contracts for creation of
logic to enforce root of trust and data interactions across the blockchain implementation.

From the related work done by other researchers, most of their test beds were with computers
or cloud servers neglecting the largest component of the IoT pyramid. In this research
Hyperledger Fabric ARM64 architecture images were created, and Raspberry Pi 4 device
was then added to the HLF blockchain network. In May 2020 Raspberry Pi devices got a new
beta test 64 bit operating system (RaspberryPi, 2020), this is the operating system used on Pi
device.
 P a g e | 13

3 HYPERLEDGER FRAMEWORK

In this section the basics of Blockchain technology were discussed, highlighting the major
differences between blockchains and cryptocurrencies. A detailed discussion of the
Hyperledger project, the different frameworks, as well as the core components powering
Hyperledger fabric was given.

3.1 Introduction to Hyperledger Project

Hyperledger is an open source project hosted under the Linux Foundation which has provided
some great frameworks for the technology field. IBM and other companies support the
Hyperledger project, with their developers actively supporting it. Hyperledger has an umbrella
of six different distributed ledgers as of 2020, and of these six only three are currently active:
• Hyperledger Fabric (active) – enterprise grade distributed ledger technology with
privacy support.
• Hyperledger Besu (active) – Java based Ethereum client.
• Hyperledger Sawtooth (active) – main contributor is Intel working on customising
consensus protocols (The Linux Foundation, 2017).
• Hyperledger Burrow – permissionable smart contract machine.
• Hyperledger Indy – a tool and library for running independent identities on distributed
ledgers.
• Hyperledger Iroha – targeting mobile apps and has same code base as Fabric.

Hyperledger also provides a list of tools and libraries that can be used with the various
distributed ledger frameworks. The main tools in Hyperledger project which are of interest in
this research are:
• Hyperledger Cello – this tool helps with deployments of solutions on blockchain
ecosystems resulting in less work through provision of automated ways to create,
terminate and manage the blockchains (The Linux Foundation, 2017).
• Hyperledger Explorer – with this tool invocation, deployments and querying blocks
can be performed.
• Hyperledger Caliper – this tool helps provide a way to check the performance of a
deployed blockchain through a set of scenarios.
 P a g e | 14

3.2 Hyperledger Fabric

Hyperledger Fabric (HLF) is a distributed ledger technology framework that operates as a
permissioned blockchain using pluggable components to solve enterprise grade problem. HLF
is built on top of Golang using the gRPC framework for communication across the nodes and
can interact with client applications and software development kits (SDK) written in Java, Go
or Node.js (Androulaki et al., 2018). HLF use cases are multi-purpose and not limited with vast
possibilities, documentation and source code of the framework is available on GitHub and
online (Hyperledger-fabric, 2019c). In this section the researcher discussed in detail different
components of the HLF architecture.

3.2.1 Fabric Network

Hyperledger fabric blockchain combines a set of nodes into organizations which create a
network that interfaces with external applications. Organization (ORG) in HLF are treated as
members that form part of the blockchain network. Each organization is identified by its
Membership Service Provider (MSP) id which manages how new members can be issued
digital signatures and be verified. Just like in the real-world organizations can be as big as
required by the need. Collective of organizations form a Consortium, however these
organizations need to be non-orderer organizations in the blockchain network (Androulaki et
al., 2018).

Nodes within HLF network are managed by the membership service provider (MSP) which
acts as the identity manager, providing valid digital signatures (Hyperledger-fabric, 2020c).
The nodes within the HLF network as shown in Figure 3:1 - Illustration of transactions within
Hyperledger fabric network can be categorized into three groups:
• Clients – these can be web/mobile applications, command line (CLI), software
development kits that interface with the HLF network by submitting transaction
requests for execution and requesting the ordering of transactions. Chaincode
operates outside of the HLF network, however, interacting with the nodes as well as
the world state ledger.
 P a g e | 15

Figure 3:1 - Illustration of transactions within Hyperledger fabric network

• Peers – these maintain the ledger of the blockchain and executes chaincode. There
are two types of peers’ anchor and endorser peer, endorser peers handle the
approving of transactions as per the endorsement policy. Anchor peers are defined on
network creation and these handle the communication between different organisations
within the network sharing data across their respective organisations (Androulaki et
al., 2018).
• Ordering service/Orderer - this creates the logical order of transactions packaging
them into blocks and then sharing them to peers. Orderers are different from peers
and exist as a collective of nodes that order transactions using first-in-first-out principle.
Ordering service can be used with pluggable implementations like Apache Kafka or
Fabric’s Raft.

Nodes within the network can communicate with each other using Channels, this is private
and secure way that ensures nodes can send messages and blocks without outside
interference. A single network could have several channels between different organizations
and peers to increase confidentiality, addition to a channel is done through use of an MSP.

3.2.2 Ledger and World state

A ledger is chain of blocks containing transaction records that are immutable. Peer nodes
within HLF network agree on the ledger state and this ledger is distributed across the
participating nodes. In HLF the ledger has two variations which are similar these are world
state and blockchain (Hyperledger-fabric, 2020b).
 P a g e | 16

• World state – this contains the current value state of the ledger, this means the values
can change as often as the ledger is updated. World state makes it easy for
applications or nodes to quickly retrieve recent information without having to traverse
the ledger. World state is accessible as a database providing efficient storage and
retrieval methods that are efficient (Hyperledger-fabric, 2020b).
• Blockchain – this is a stricture sequence of transaction blocks chained together. These
transactions could either be a query or update to the world state database. As shown
in image below the first block in a blockchain is called the genesis block and is always
the starting point of the ledger containing configuration transactions (Hyperledger-
fabric, 2020b).

Figure 3:2 - Blockchain illustration with genesis block and preceding blocks containing block data (Hyperledger-
fabric, 2020b)

3.2.3 Chaincode/Smart Contracts

Smart contracts are decentralized programmable code containing business logic that
executes transactions with limited data (Bashir, 2017). The programmable logic only executes
when the set controls in the contract are satisfied. By design smart contracts do not need a
blockchain but through blockchain they get security and make use of the consensus
algorithms. Smart contracts can be executed simultaneously within the same network. They
can be instantiated by anyone if they have access right, upgrading them is also easy, however
the initial offering remains.

Hyperledger fabric makes use of smart contracts but usually refers to them as chaincode
which is a grouping of similar smart contracts. A chaincode containing smart contracts when
deployed on network, those contracts are made accessible as applications (HyperledgerDocs,
2018). Smart contracts are usually written in non-standard languages like Solidity due to the
 P a g e | 17

order-execute design which require the contracts to be deterministic to achieve consensus.

However, HLF can have smart contracts written in three languages, Java, Go and JavaScript.

3.3 Identity management

Hyperledger fabric contains several entities in its design as well as deployed networks. These
entities include organisations, peers, orderers and client applications that form part of the
blockchain network and to identify these entities HLF issues X.509 certificates (Hyperledger-
fabric, 2020c). Certificates issued to entities provide a mechanism to know who has
permissions to resource and provide access control in the network. HLF has its own certificate
authority “Fabric CA”, it facilitates the creation of certificate authorities and manages the
identities (HyperledgerDocs, 2020).

3.3.1 Public Key Infrastructure

Public key infrastructure (PKI) is a collection of protocols and standards that work together to
ensure secure communications in a network (Ali et al., 2019). Within the PKI there are
certificate authorities (CA) that perform the issuance of digital certificates complying with X.509
standard to entities so that they can access the resources. The CA keeps a revocation list
which has old certificates and denied certificates (HyperledgerDocs, 2020). HLF depends on
the PKI model to ensure communication between network actors is secured.

Figure 3:3 - Public Key Infrastructure Illustration, showing the requesting/issuance and revocation of certificates
from (HyperledgerDocs, 2020)

The functionality of certificate authorities within the Internet architecture allows them to have
root and intermediate options (HyperledgerDocs, 2020). This capability can be leveraged
within HLF network to provide root of trust within the various participants, despite which
 P a g e | 18

organisations they belong to. Fabric Certificate authority works in a similar way to the PKI
implementation which includes root and intermediate Cas.

3.3.2 Membership Service Provider

This is the managing authority for digital certificates, user access and provides authentication
for users of the network. Every access of HLF must be accounted for, because it is a private
blockchain and MSP helps through generating certificates using cryptogen (Hyperledger-
fabric, 2020c). Certificate authorities in HLF generate X.509 certificates containing private and
public keys which are allocated to the respective entities to form a keyset used to establish
identity (Hyperledger-fabric, 2020c). Verification of the allocated private keys is done by the
MSP through checking the private key against the saved public keys of participating peers
(Hyperledger-fabric, 2020c).

MSP can be owned by organisations as shown in Figure 3:1 - Illustration of transactions within
Hyperledger fabric network, with each organisation defining which participants are trusted. In
a single HLF network different organisations execution different MSPs can still verify
participants if they are within the same channel or through MSP communication (Hyperledger-
fabric, 2020c). Another implementation of an MSP is by having it on peers and orderers within
the HLF network, this way an entity verifies itself or an orderer takes the functions of an MSP
(Hyperledger-fabric, 2020c).

3.3.3 Cryptogen or Certificate Authority

Cryptogen is a binary tool that is built during the setup of HLF on host environment. This tool
is used for generating key cryptographic materials for entities within the HLF network. The
cryptographic materials generated by cryptogen include Identity management material as
well as TLS for communication between entities.
 P a g e | 19

Figure 3:4 - Crypto materials generated through use of cryptogen binary tool in Hyperledger fabric (KC Tam,
2020)

Certificate authority (CA) within HLF is tasked with overseeing the identities of all
participating entities within an organization in HLF. Through CA cryptographic material can
be generated for each entity, this material includes private key and digital certificates.
Security of these materials are ensured by the entity not publicising their details.

For this implementation chose to use cryptogen instead of the CA for generation of the
crypto material and handling identity systems. This is mainly because cryptogen is easy to
manage and encouraged for use in test purposes. However, for production a CA must be
used, during the implementation, and have also shown how to create the CA docker
container.

3.4 Consensus Mechanisms

Consensus is at the root of functionality within blockchain as it helps achieve the agreement
across the nodes. Consensus is when nodes within a blockchain that is trustless reach an
understanding through voting (Bashir, 2017). The different types of blockchains make use of
different consensus processes, e.g. Bitcoin makes use of Proof of Work which requires miners
and use of computational power. This form of consensus is being dropped by newer
blockchains due to its energy consumption adopting Proof of Stack (Buterin, 2016).
 P a g e | 20

In private (permissioned) blockchains, the requirement to verify every participating node

requires a new level of trust, hence the use of different consensus methods. The adopted
methods require less computational power, whilst also avoiding block forking within the
network due to no reliance on probabilistic consensus (Elrom, 2019). Hyperledger Fabric has
utilized Apache Kafka which is a consensus approach that is voting-based through use of
orderer service to manage transactions (Androulaki et al., 2018). From Hyperledger Fabric
v2.0 Kafka is being deprecated in favour of Raft consensus protocol, which is the choice of
ordering for this project.

3.4.1 Byzantine Generals Problem

Lamport et al. (1982) first discussed the Byzantine Generals’ Problem and issues that arise
by spreading of false information that is not coherent across different sections of a system.
The discussion was in focus of distributed systems which could be affected to the extent of
failure due to communication malfunction across the network. This consensus problem is
presented in this article as army generals ready to attack a fortified city, however, in their ranks
are traitors. Byzantine army can only win if the loyal generals and their troops decide to attack
the enemy city at the same time.

Blockchain technology, being a distributed technology is affected by the Byzantine Generals

Problem, many algorithms and consensus mechanisms have been developed to cater for this
issue. As per the Byzantine Generals Problem, an army represents a blockchain network,
general can be a node in a network using a messenger to relay messages to other
generals/nodes. To avoid misinformation all active generals should exchange the commands
they receive, and the generals would use deterministic probability as to the final decision to
take. However, this approach is faulty if the generals receive different commands or more
generals decide to lie about what they received, and if the army contains more generals the
vulnerability surface increases (Zhao, 2014). This problem leads to difficult choices when
choosing Blockchain technologies and consensus algorithms to use due to the possibility of
failure of the system when it grows and goes into production.

3.4.2 Raft Ordering Service

Since HLF v1.4.1 Raft was introduced, and it is a crash fault tolerant (CFT) ordering service
following the “leader and follower” model. Leaders are voted for in each channel and their
decisions are replicated to all the followers (Hyperledger-fabric, 2019d). Raft does not fail
when leader nodes crash so long as most ordering nodes remain a new leader will be
 P a g e | 21

elected. Compared to its predecessor, Raft is easier to setup and is supported by the Fabric
developers.

Kafka, which is also a CFT ordering service is a third-party service provided by Apache. In
this project generated the Kafka and Zookeeper images for Raspberry Pi 4, however, setting
up the components for implementation left lots of room for failure. Raft on the other end has
all its components within the ordering node hence I only needed to setup the orderer image.
Raft unlike Kafka is working towards creation of a byzantine fault tolerant BFT ordering
service. Using Raft ordering service can achieve root of trust models within HLF network.

Figure 3:5 - Raft process of election of a follower to candidate when no communication is received, then elected
leader (Ongaro and Ousterhout, 2014)

3.4.3 Transaction Flow

In the earlier parts of this section explained Blockchain and the design structure of Hyperledger
Fabric, this part summarizes the flow of transactions:
• Request – a client application creates a transaction request which is sent to endorsers
for endorsement. The endorser peers will simulate the transaction using smart
contracts and if valid endorse it with a response sent to client application (Hyperledger,
2019a).
• Ordering – The endorsed transactions are sent to the orderer which then packages
the transactions using an ordering service in this instance Raft.
• Validation – an ordering service sends ordered blocks to peers and individual peers
accept the blocks. Using endorsement policy peers will check if blocks are properly
signed, accepted blocks are added to the end of ledger (Androulaki et al., 2018).
This transaction flow can be seen in Figure 3:1 - Illustration of transactions within Hyperledger
fabric network.
 P a g e | 22

3.5 Docker
Docker was created to help with creation, deployment and execution of systems and
applications using containers. Containers provide the ability to create the required
environment prerequisites and dependencies allowing the application to be deployed as a
single package (Inc., 2020). Containers have become popular due to them being lightweight
depending on operating system’s kernel and consuming less memory as compared to virtual
machines (Docker Inc, 2020). Using docker multiple containers can be ran on a machine.

Hyperledger fabric is accessible through use of Docker images for different operating systems
and architectures. From the HLF documentation the supported operating systems currently
are Windows, Mac OS, and Linux amd64. To access HLF on this operating system there is a
need to install the software prerequisites and pull down the required docker images. For
supported operating systems these images are supplied by HLF through their GitHub
repository.

3.5.1 Dockerfile
After a developer/architect creates and tests their application and system with all the required
dependencies they can push this solution on docker hub. Dockerfile is used to point to the
solution whilst also stating all the required requirements, network definers, executing language
etc. which can be pulled from other docker images. During building HLF images for ARM64
architecture needed to make changes to Dockerfile for the different components.

3.5.2 Docker images

To provide security by design, Hyperledger fabric maintains releases of its source code
publicly available on GitHub as an open source project. This source code is used to build
docker images which need to be downloaded to access HLF on a system. Due to the
specifications of this project there is a need for two sets of images, one for AMD64 architecture
and another for ARM64 architecture which supports the Raspberry Pi device. However, HLF
does not provide images for ARM64 hence, there was a need to create these images from
build.

HLF images cannot be accessed for 32-bit operating system versions of ARM architecture,
due to components needed in the build process which are only available for 64-bit versions.
Raspberry Pi at the time of writing has just released a Beta Version of its 64-bit Raspbian OS
version. There are other 64-bit Linux variants available for Raspberry Pi, however, from my
experiments setting them up for docker image build is strenuous and difficult. The docker
 P a g e | 23

images for ARM64 architecture used for this project were built based on
arm64v8/debian:buster.

3.5.3 Docker compose

Docker offers a tool called “Docker compose” which allows the operating of multiple containers
application with a single YAML configuration file (Docker Inc., 2017). In production
orchestration solutions like Kubernetes or Docker swarm can be used to manage multiple
device deployments.

3.5.4 Docker container

When docker images have been downloaded and executed a container with the current
instance of the image is created. With every created container a new layer is also created on
top of the docker image layers, this allows for changes made within the container to now affect
or make any changes to the image. There could be multiple containers operating from the
same docker images, e.g. could deploy 3 peer containers operating from the same
Hyperledger/fabric-peer:2.1 image.

Figure 3:6 - Illustration of docker container layers operating on top of docker images within Docker environment
 P a g e | 24

In Figure 3:6 - Illustration of docker container layers operating on top of docker images within
Docker environment, the docker images and container layers are illustrated. Dependent on
the system requirements HLF can require at most the following docker images:
• Fabric base image – this image is built with the base-os and contains most of the HLF
source code and logic.
• Fabric certificate authority image – image for the certificate authority which will be
deployed on the participant handling issuance of certificates.
• Fabric peer image – image for peer nodes which are the participating and endorsing
nodes.
• Fabric orderer image – image for the orderer nodes that will manage orderers.
• Fabric CouchDB image – this is the image for the peer state database which is
externally accessed (Hyperledger-fabric, 2020a) .

3.5.5 Docker swarm

Docker swarm is the orchestration and cluster management service used by docker through
use of swarmkit in the docker engine (Docker Inc., 2019). Orchestration involves handling of
multiple docker hosts being handled by swarm mode which initiates actors as managers and
workers. Through this definition of roles if a participating worker goes offline their required jobs
are reassigned.
 P a g e | 25

Figure 3:7 - Docker Swarm illustration with Manager node and Worker node

Docker swarm provides added advantages for our implementation as it allows for multiple
hosts communication and networking. Through use of an orchestration service the
implementation is also ready for scaling and has security by default as swarm provides TLS
authentication and encryption between participating nodes (Docker Inc., 2019). Docker swarm
provides a private network route, in this implementation used the overlay network drivers.

Figure 3:7 - Docker Swarm illustration with Manager node and Worker above shows the
docker swarm orchestration method working in this project. The HLF network is deployed
using docker swarm and have the virtual machine connecting to the IoT device in this instance
a raspberry pi using docker swarm overlay network. The docker manager being the more
capable device has the most features like orderer nodes, certificate authority whilst the IoT
device is also a manager allowing interactions with network and execution in command line.

3.6 Conclusion
In this section have discussed Linux Foundation’s Hyperledger project showing the projects
under it. With detail talked about HLF network, architecture, and components. HLF network
has a blockchain network structure with interconnected components that belong to an
Organization and managed by an Identity manager in Membership Service provider.
Through use of this identity manager access control, confidentiality and root of trust are
 P a g e | 26

guaranteed across the Blockchain. HLF with v2.0+ has fully adopted Raft ordering service
for its consensus mechanisms which is advantageous.

Final section discuses about Docker technology which is used to provide HLF to different
architectures and operating systems. HLF is not operated as a native application due to the
number of pluggable components and requirement to have the same system running on
multiple devices which can be attained by use of docker containers. Using docker, any
exploitation and vulnerabilities that can occur can be prevented due to use of containers
operating on top of images which are not accessing the computer system.
 P a g e | 27

4 INTERNET OF THINGS TECHNOLOGY

Internet of Things (IoT) refers to a wide range of physical objects which have some logic and
media to allow networking together and to the internet. The IoT ecosystem contains several
protocols, components, standards, solutions, and applications. IoT solutions and applications
are usually confused for one thing, however, these are different with the solution being the
product or service containing devices, platforms etc. and an IoT application is the software or
mobile application used to access the solution (Tamboli, 2019).

4.1 Introduction to Internet of Things Solutions

IoT solutions contain four main blocks which are imperative for the functionality of the solution
and for it to be categorised as such.
• Devices (things) – these are physical objects that are on us, with us or in us e.g.
sensors and actuators. Sensors are placed in environment recording data and
parameter changes which is recorded for analysis and help provide a functionality.
Sensors can measure or detect light, heat, motion, or any other physical quantity.
Devices can have functionality to perform data analysis and encrypt recorded data on
internal storage (Cheruvu et al., 2020).
• Gateways – some IoT devices cannot directly connect to the Internet to transmit their
recorded data so they use gateways. The gateways are usually equipped with various
protocol technologies like Bluetooth, Wi-Fi, GSM, Zigbee etc. Mobile devices can act
as the gateways connecting the IoT devices to the internet. The gateway needs to be
secured as it can be targeted by attackers to get access to data since gateways
function as data segregators, and duplicators. To safeguard the gateway, there is a
need to be able to identify all the devices in the environment through use of string
access control (Gilchrist, 2017).
• IoT platform – the IoT solution is based on the platform which is usually hosted on a
cloud provider like Azure or AWS. The platform is the storage facility for all the
generated data by the devices, platform also performs the processing and analysis on
the data streams. The platform functions as the orchestrator of the IoT solution
providing authentication, analytics and encryption of stored data (Cheruvu et al., 2020).
• IoT application – this is the user interface to the IoT solution, user rarely get to interact
directly with sensors in the environment, but they interact through mobile applications,
web applications etc. IoT applications are usually linked to other systems that require
 P a g e | 28

the data and help aid in integration and aggregation of data. Design applications can
enrich the data from IoT platform (usually cloud) to present a format usable for the user
e.g. graphs (Tamboli, 2019).

Figure 4:1 - IoT illustration of devices connecting to gateways feeding into the IoT platform accessed by
Applications.

4.2 Internet of Things Platform

From the four building blocks of the IoT solution, of major interest in this research is the IoT
platform as this contains mechanics that the research investigated. Fundamentally, the IoT
platform should include a device interface and message broker, the message router and
communications module, data storage, device management and the rule engine (Tamboli,
2019). For other IoT platforms they have additional components in the IoT platform which are
microservices, Representational state transfer (REST) APIs and user management controls,
these helps with functionality and are not mandatory.

Figure 4:2 - Blocks found within an IoT platform, with external connections to IoT devices,
applications, and other systems, is an illustration of the IoT Platform showing all eight blocks
that can exist in an IoT platform. From each block data can flow in both directions as shown
by dual arrows and in some instances, data is sent from one block to another for processing
as shown by a single arrow. The IoT platform is connected to the devices, applications and
any other integrated systems which will be using blocks like REST API for execution.
 P a g e | 29

Figure 4:2 - Blocks found within an IoT platform, with external connections to IoT devices, applications, and other
systems

4.2.1 Edge Interface, Message Broker & Message Bus

This block connects the IoT things in the environment to the platform, i.e. sensors and
actuators. Communication is done using various networking protocols like Wi-Fi, LoRaWAN,
Bluetooth etc. The message broker contains plugins that cater for the various channels and
consolidates data which is sent to the message bus (Tamboli, 2019).

4.2.2 Message Router and Communication Management

This block receives data from message bus and updates data as necessary for the accessing
applications and per device types. Any data duplicates are removed in this block with message
broker receiving updates. Communication management module can convert data types like
CVS or JSON into required conversions (Tamboli, 2019).

4.2.3 Storage and data management

All generated data and messages are stored in this block in a sequential manner as received
from the message bus. Calls are made by other blocks to this section for when they need data
for their own needs. Most IoT solutions choose to have data stored in a third-party system for
processing and analytics making this block to handle temporary data.
 P a g e | 30

4.2.4 Rule Engine

Rules are set here and from here any activity taking place across the platform is monitored.
The Message bus and any trigger events have listeners and alerts generated when an
occurrence occur.

4.2.5 Device Manager

Having knowledge of devices on a platform is necessary cause if one is vulnerable, it could
risk the whole platform. The device manager records device status provides updates and can
be used by administrations. However, it has limitations of interoperability of devices (Tamboli,
2019).

4.2.6 REST API Interface

A restful API helps in providing insights to applications or utilities that do not have to always
be connected for updates. When an event occurs, or a set parameter is met, the API will
provide the information to the interface or application which can be viewed and accessed by
necessary parties.

4.2.7 Microservices
An IoT platform depends on services for notifications, authentication, payment gateways etc.
To access these services microservices are used and this block contains a bundle of the
required services.

4.2.8 Application and user management

This block manages users, access controls and permissions. Integrated systems and
applications that have access to platform are also managed in this block. The fact that it’s not
mandatory in all IoT platforms, shows the need to put security first in the design architecture
(Tamboli, 2019).

4.3 Issues and Challenges in Internet of Things

There are over 450 IoT platforms currently in the market following different standards e.g.
(IEEE, OneM2M, IETF etc.) and exacerbating the interoperability challenge in IoT due different
communication technologies and architectures (Ali et al., 2019). These different platforms
implement their solutions differently, some of the solutions are open source and others are
licensed so knowing the security designs in platform is not easy.
 P a g e | 31

Below will briefly explain security challenges and issues with IoT technology.

4.3.1 Security
Providing security for IoT devices is a major challenge for IoT technology which then hinders
its full adoption in industry and society. IoT devices have limited computational power and
some of them are isolated in the environment making it difficult to prove (Hameed and
Alomary, 2019). The interconnectedness of IoT devices when networked together and on the
internet makes a complex unit which is difficult to monitor and identify origins of threats.
Combating the IoT security risks needs IoT specific solutions that provide security-by-design
and ways to perform incident response at various levels of the system (Barki et al., 2016).

4.3.2 Privacy
IoT systems generate a massive amount of data which contains private and sensitive
information in respect to the users, organisations, or owners. This data is at risk of mass
surveillance from government entities and third parties having access to user data without
authorized consent (Greenwald and Macaskill, 2013). Privacy measures are already in place
in some IoT platforms, however, since they are managed by centralized systems users must
put their trust in these systems which have not always worked out (Zhou et al., 2017).

4.3.3 Data management

Estimates are that by 2025 there will be over 40 billion IoT devices generating a lot of data
stored in centralized cloud systems (Framingham, 2019). The use of different cloud systems
and vastness of data brings data management challenges in terms of storage and
communication. To combat this challenge, decentralized systems that are scalable would
handle the vast data without much challenges (Maple and Jackson, 2019).

4.4 Current access control mechanisms in Internet of Things

Identity management mechanisms available for the Internet have been incorporated into IoT
environments, these include OpenID (2006) and Security Assertion Mark-up Language
(SAML) (2005). OpenID and SAML require a third-party authority to be able to provide
authorization even though their solutions are decentralized. Use of third party authorities to
provide authentication services in these solutions makes users to place their trust in these
providers (Ali et al., 2019).
 P a g e | 32

Traditional access control methods that take usernames and passwords are difficult to use in
IoT since sometimes the authentication is machine-to-machine, which usually requires
certificates or security tokens. Using certificates in IoT requires some protocols to be in place
and the TCP/IP stacks has some limitations with IoT (Ali et al., 2019). IoT uses OAuth 2.0 as
the authorization framework issuing tokens for any requested access to Internet resource
(Fett, Küsters and Schmitz, 2016).

OAuth like the earlier traditional methods for authentication makes use of third-party sources
as authorization server for the issue tokens bringing up the trust issues. Current research has
proposed access control methods that use recent protocols; however, these solutions have
interoperability challenges. These challenges are due to use of different protocols, multiple
IoT platforms and variations of implementation which makes them hard to adopt.

4.5 A type of Internet of things device

IoT devices as shown in Figure 1:1 - IoT Pyramid Structure can be classified in 5 categories
with the biggest category containing the most constrained devices. These devices are not
meant to perform much computation, be placed in the environment, and perform other
functions. In this research a Raspberry Pi 4 device was used to mimic an IoT environment
due to the various possibilities a Raspberry Pi device can offer.

4.5.1 Raspberry Pi device

Raspberry Pi is a cheap device that has the same size as a credit-card and can be connected
to a monitor or display screen using keyboard and mouse as a general purpose computer
(Barkstrom and Barkstrom, 2019). This device can perform various tasks just like a normal
computer, however, with storage and computational limitations. From Raspberry Pi 3 and older
models they came with 2gb and less whilst running 32 bit operating systems. In recent years,
some Linux distributions like Ubuntu have developed 64 bit versions which others have argued
are not necessary.
 P a g e | 33

Figure 4:3 - Raspberry Pi 4 device (Raspberry Pi Foundation, 2020)

4.5.2 Raspbian OS
In 2019 a newer Raspberry Pi device was released with 4GB Ram and in 2020 a modified
iteration with 8Gb Ram was also released (Raspberry Pi Foundation, 2020). However, the 32-
bit kernel in the default operating system has a limitation that only one process can use a
maximum of 3GB of RAM, hence the need for a 64-bit variant. In May 2020 Raspberry Pi
Operating System (OS) (64 bit) beta test version was released marking an official supported
64-bit OS for Pi devices. Raspberry Pi devices are advised to be operated with a 32GB micro
SD card for the operating system and storage of files. This SD card can be exchanged with
another without any worry of boot files like in Windows allowing users to have multiple OSes
on different SD cards.

During this research, tried other Linux 64-bit operating systems that can be operated on a
Raspberry Pi device. In the table below, the reasons why Raspbian OS was the option chosen
for this implementation were highlighted. Scaled everything between 1-5, with 5 being the
highest score and better performance.
 P a g e | 34

Table 4:1 - Comparison of ARM 64bit based Operating Systems

Operating System Ease of Install Availability of Ease to generate

packages docker images
Raspbian OS 64bit 5 4 5
(RaspberryPi, 2020)
Manjaro 18 (Manjaro.org, 2020) 3 4 2
Ubuntu Mate (Ubuntu-Mate, 3 5 5
2020)
Ubuntu Server (Ubuntu, 2020) 5 5 3
OpenSUSE (Opensuse, 2020) 2 4 3

4.5.3 Raspberry Pi’s General-Purpose Input/output

Raspberry Pi’s are the industry standard for IoT deployments and exercises due to a powerful
feature they come with. On the top edge of the Pi device board there are 40 General Purpose
Input/output Pins (GPIO) (Foundation, 2019). These pins can be assigned as input or output
through use of software. Raspberry Pi has support for several programming languages
allowing controlling of these pins, some of these languages that can control GPIO pins are:
• Scratch 2
• Python
• C/C++ (Foundation, 2019)

Through use of these programming languages IoT sensors/actuators/devices can be

connected to the Pi device and be used to record data from their environments. Dependent
on the required voltage which is provided as 3V3 or 5V devices such as humidity sensor,
camera, RGB LED can be connected and used with a Raspberry Pi device. A Raspberry Pi
device can be used as a controller for IoT configurations like smart home, small weather
control etc.
 P a g e | 35

5 ARCHITECTURE AND DESIGN

In this chapter architecture and design of the main components of the proposed system which
include the smart contract (chaincode), IoT device setup and system configuration were
covered. The design includes building of HLF images for the ARM64 architecture, network
structure and chaincode definition.

5.1 System design

As already discussed in chapter 3, Hyperledger Fabric (HLF) is a permissioned blockchain
used to provide enterprise solutions. HLF in this research is used to ensure security of IoT
devices whilst ensuring access control and root of trust between devices. The IoT device used
in this project is a Raspberry Pi 4 device, as shown in Chapter 4 a Pi device can be used to
connect other devices through its 40 GPIO pins. This makes the device perfect for illustration
as it can be used in various use cases. The goal in this research is to show that HLF can be
accessed through constrained IoT ARM64 powered devices and provide security solution.

Figure 5:1 - Setup of system with Raspberry Pi 4 connected to Windows 10 machine through an ethernet cable.
Accessing the Kali Linux Virtual machine using Virtual Box & with Remote desktop have GUI access of the Pi
device
 P a g e | 36

Table 5:1 - Hardware specifications of devices used in the implementation of this project

Machine Operating System Processor RAM Storage

Lenovo Legion Windows 10 Intel Core i5-9300H 8GB 1TB HDD &
Laptop @2.40GHz CPU 256GB SSD
Virtual Machine Kali Linux Laptop Hardware 4GB 72GB HDD
Raspberry Pi 4 Raspbian OS Broadcom BCM2711, Quad 4GB 32GB SD
device (beta) core Cortex-A72 (ARM v8) card
64-bit SoC @ 1.5GHz

5.2 Hyperledger Fabric images

Hyperledger fabric has support for Windows, Linux, and Mac for desktop hardware. Software
dependencies and docker images for these environments can be easily downloaded using a
script from the Hyperledger fabric documentation (Hyperledger, 2019b).

For ARM64 architecture HLF does not provide any docker images or support for the
architecture. Due to the objectives of this research had to create HLF docker images for the
Raspberry Pi device. From the findings in Table 4:1 - Comparison of ARM 64bit based
Operating Systems decided to use Raspbian OS for the building of these images. Faced some
challenges in the build process due to the operating system being in beta (test) mode and
kernel differences.

5.3 Network setup

The virtual machine is running on top of an 8GB RAM Windows 10 computer using Oracle
VirtualBox. Raspberry Pi is connected to the Windows desktop through an ethernet cable
and accessed through remote desktop connection, whilst accessing internet through a WI-FI
connection. The Kali Linux Virtual Machine (VM) and Raspberry Pi device must be on the
same network to allow creation of HLF network and channels.

Using an Oracle VirtualBox, virtual machine provides a realistic environment, however, the
Kali VM has networking limitations which causes issues for connection between the VM and
the Raspberry Pi device. Virtual machines have the following networking modes:

Table 5:2 - Overview of VirtualBox Networking modes (VirtualBox, 2019)

Mode VM→Host VM←Host VM1↔VM2 VM→Net/LAN VM←Net/LAN

Host-only + + + – –
Internal – – + – –
 P a g e | 37

Bridged + + + + +
NAT + Port forward – + Port forward
NATservice + Port forward + + Port forward

From the available networking modes chose to create a bridged network solution on the
Windows machine and then connected the virtual machine to the new created network
interface card (NIC). After setting up the bridged connection and having two Ethernet
interfaces on the VM below is a table of the IP addresses the devices had.

Table 5:3 - Host IP addresses for Kali and Pi device after network setup

HOST IP address RAM

Host 1 (Kali VM) 192.168.56.108 4GB
Host 2 (Raspberry Pi 4) 192.168.56.106 4GB

5.4 Identity and Crypto materials

The objective of this research is to show implementation of access control through chaincode
within HLF network. HLF provides a way to define root of trust through the ordering service
Raft which is the one used to manage the nodes and other orderers in the network. As for the
identities (Admin & Users) as well as the other crypto material needed within the HLF network
used cryptogen for their generation. An alternative to use certificate authority is not pursued
in this research however, the docker images and scripts to create the containers are available.

5.5 Hyperledger Nodes

Proposed system is operating Hyperledger fabric v2.1.0, with docker swarm cluster of Kali VM
and a Raspberry Pi 4 device. Both nodes are operating a command line interface which is
being used to interact with the network through the created channel.

The HLF network implementation contains a single organisational unit (Org1) which contains
the following:
• Two peers, an endorsing and participating peer.
• Three Orderer nodes using Raft based ordering service.
• Certificate authority.
• Two Command line containers.
 P a g e | 38

The organisation is managed by its own Membership service provider that is managing the
identities of participants. The number of peers and orderers was selected based on the
machines used for the implementation and the requirement for Raft ordering service to ensure
crash fault tolerance.

Figure 5:2 - Hyperledger Fabric network operating on two hosts being managed by a docker swarm cluster with an
overlay network managing the communication

5.6 Fabric chaincode design

Chaincode referred to as smart contract is programmable logic. Chaincode will define access
control of user and admins depending on ABAC which makes use of existing crypto materials
for the users whilst verifying trust with the ordering service Raft. HLF chaincode is executed
in a secure docker containerized environment which is isolated from the participating nodes
(Hyperledger-fabric, 2019b).

During docker image built for Raspberry Pi faced challenges when generating Java and
NodeJS images. This limitation has limited this implementation to just having the chaincode
being written in Golang which is the first supported language by HLF. Developer faced
 P a g e | 39

challenge in the development of more sophisticated logic due to the limited knowledge in the
Golang programming language.

5.7 Issues and Concerns

During the design for this project’s implementation encountered some limitations and
concerns. Due to Raspberry Pi 4 executing Linux/arm64/v8 images it was difficult to execute
chaincode from the Kali Linux due to the differences in architecture. Building the chaincode
docker images would fail as the chaincode would install and require amd64 images. To
circumvent this challenge built the chaincode on Raspberry Pi and then deployed across the
blockchain network. This defeats the purpose of having the Kali VM as leader node and would
not be ideal in production setup.

Due to the Kali Linux VM operating a bridged network could not access internet on the bridged
connection, this brought untold problems from failing to download dependencies to just some
anomaly behaviours. Whenever there was need to transfer some files to server for raspberry
pi to access the docker swarm network could be affected. In production or on “Amazon ECS”
this is not a challenge as everything is on same network with internet access as well.
 P a g e | 40

6 IMPLEMENTATION

This chapter discusses the implementation of the Hyperledger Fabric backed solution for IoT
devices using two different architectures. In detail all the necessary steps needed for setting
up and deploying HLF on AMD64 architecture and ARM64 architecture was discussed.
Detailed discussion on how to build ARM64 docker images for HLF as they are not provided
by HLF was given. HLF does not have documentation onto how to deploy HLF networks on
Multi-Host configuration, illustration on how to achieve this using docker swarm was
conducted. Finally, deployment of chaincode on both Kali VM and Raspberry Pi device
achieving access control was shown.

6.1 Hyperledger images and binaries

For this project Hyperledger fabric is setup on two Debian environments, one for Kali VM
(AMD64 architecture) and another for ARM64 architecture powering a Raspberry Pi 4
device. In both environments there are prerequisites/dependencies needed and these are
shown in the table below. To install these prerequisites created a bash script which can be
found on GitHub repository (Chinyati, 2020a).

Table 6:1 - Hyperledger Fabric Prerequisites versions used on the AMD64 and ARM64 architectures

Architecture Docker Docker Compose Golang Node Git Pip

AMD64 & 19.03.12 1.25.0 1.14.4 12.18.3 2.27.0 20.0.2
ARM64

ARM64 architecture requires docker images to be manually created and the source code
versions used must align with the HLF release docker images on AMD64. HLF maintains a
source code repository for fabric core, fabric-ca and fabric-baseimage. These source code
repositories are the ones encouraged to use when building HLF docker images from scratch
for platforms not supported by HLF. Below is a table of the source code versions used to
build HLF images for the ARM64 architecture.

Table 6:2 - Versions for key docker image source code.

Docker Image Version Description

Fabric Core v2.1.0 Includes the orderer, peers and ccenv (Golang chaincode
build environment).
 P a g e | 41

Fabric Baseimage v0.4.20 This is the base image for HLF and contains the baseos.
Fabric Certificate v1.4.7 The certificate authority and any certificate clients.
Third party v0.4.20 Includes tools like kafka, couchdb and zookeeper

6.1.1 Installing Fabric images, samples, and binaries on Kali

Kali Linux, kernel 5.7.6 amd64 Debian is the operating system powering the Oracle Virtual
machine. Hyperledger fabric docker images, binaries and samples for Linux operating
systems can be accessed using a single command. In Appendix A: System specifications
and configurations, explained how to setup the images, fabric samples and binaries on Kali
VM. If configuration instructions are followed below would be the output of docker images on
Kali VM:

Figure 6:1 - Docker images on Kali Linux amd64 Virtual machine.

Downloaded with the images and fabric samples are binaries, these are placed in the
“/fabric-samples/bin” directory. Binaries are compiled source code that allows a set of logic
to be executed without having to install components, these binaries are architecture specific
for AMD64. HLF depends on these binaries for execution of chaincode, generating artifacts
etc.
 P a g e | 42

Figure 6:2 - Hyperledger fabric binaries for Kali Linux

The path with these binaries needs to be added to environment path to allow execution of
the binaries from anywhere. The command to add the path should be executed from the
fabric samples folder:

$ export PATH=${PWD}./bin:$PATH
Listing 6:1 - Adding binaries path to environment

6.1.2 Building Hyperledger Images for Raspberry Pi 4

Raspbian OS (64 bit), kernel 5.4.51-v8+ aarch64 Linux (beta test version) is the operating
system on the Raspberry Pi 4 device. Since HLF does not support the deployment on 32-bit
systems and on ARM architecture devices built images for the architecture. HLF v2.1.0
source code released in April 2020 is the repository used for core fabric images, this version
is the first major release by HLF since 1.0 (Hyperledger-fabric, 2020d). Building these
images had to be secure conscious to avoid creating exploits and vulnerabilities that can be
later exploited.

In Appendix B, explained in detail how to create the HLF images from the base-image,
certificate authority, third parties as well as binary executables for the ARM64 architecture. If
instructions from Appendix B are followed the output on the Raspberry Pi device after
executing $ docker images is as shown in Figure 6:3 - Docker images for Raspberry Pi 4,
with the different version tags.
 P a g e | 43

Figure 6:3 - Docker images for Raspberry Pi 4, with the different version tags

6.2 Hyperledger fabric network design

This implementation requires HLF fabric to be accessed through a multi-host network
configuration, this is achieved through use of docker swarm. The clusters are connected by
an overlay docker network which is managed by the docker swarm leader.

6.2.1 Docker Swarm connection

Kali VM and Raspberry Pi must be on the same network and able to ping and communicate.
In Appendix A explained in detail how to configure docker swarm and create the overlay
network. Checking the listed docker nodes and networks on both Kali VM and Raspberry Pi
device gives output as shown below.
 P a g e | 44

Figure 6:4 - Docker swarm output on both Kali and Raspberry Pi devices

6.3 Configuring Identity and Channel definitions

HLF requires crypto-material for identity and communication configurations. These crypto-
material also include Transport Layer Security (TLS) files, which are used during
communication within the network. Channel transaction files need to be generated as well to
allow creation of the channel. From the identity material created here users are defined with
their digital signatures which will be used for access control implementation.

To generate the channel artifacts and crypto material there is need to use two of the binaries
namely cryptogen and configtxgen on the Kali Linux VM. Cryptogen was used for crypto
generation over a certificate authority due to this being a test environment, in production
Fabric CA is the advised option. Crypto-material and channel artifacts are generated on Kali
Linux and copied to the Raspberry pi device ensuring same material across the hosts.

6.3.1 Crypto materials

The cryptogen binary tool found in the fabric-samples/bin directory generates the required
crypto materials using the crypto-config.yaml file (Hyperledger-fabric, 2019a). Yaml files
contain human friendly data serialized and standardized for any programming language
(Yaml.org, 2011). Crypto-config.yaml file contains the OrdererOrgs, PeerOrgs as well as any
 P a g e | 45

specifications for hostnames and domains which are used in generation of certificates,
private keys etc.

OrdererOrgs:
- Name: Orderer
Domain: example.com
Specs:
- Hostname: orderer
- Hostname: orderer2

PeerOrgs:
- Name: Org1
Domain: org1.example.com
EnableNodeOUs: true
Template:
Count: 2
Users:
Count: 1
Listing 6:2 - Crypto-config.yaml file

Executing the cryptogen binary tool with the above crypto-config.yaml file will create a
crypto-config directory which contains orderer and peer sub folders holding all the
cryptographic material needed in running the HLF network.

$ cryptogen generate --config=./crypto-config.yaml

Listing 6:3 - Generate crypto-material using the crypto-config.yaml file and place in folder
 P a g e | 46

Figure 6:5 - Crypto material folder structure showing the generated components in both ordererOrganizations and
peer Organizations.

6.3.2 Channel artifacts and genesis block

The configtxgen binary tool works with the configtx.yaml file which feeds data into the tool.
The yaml file is used to generate the genesis block and channel.tx artifact, within this file
there are sections which are tailored to our project implementation.
• Organizations – this specifies the organizations to be deployed in network with their
names and ID. A Membership service provider directory (MSPDir) is specified and it
points to the generated crypto material. Policies on access control are also defined
here with port numbers for peers and orderers defined. Anchor peer definition of host
and port is also stated in this section and its used in the genesis block creation.
• Orderer – orderer details and the ordering service used are stated here, for this
implementation used Raft ordering service. Batch Timeout which stipulates the time
of wait during batch creation is defined. Each batch creation differs with
configurations and no standard is given, inside orderer also configured the BatchSize
to control how many messages can be permitted into a batch (Hyperledger-fabric,
2019a). This project’s implementation has gone with the default values.
 P a g e | 47

Orderer: &OrdererDefaults

OrdererType: etcdraft
BatchTimeout: 2s
BatchSize:
MaxMessageCount: 10
AbsoluteMaxBytes: 99 MB
PreferredMaxBytes: 512 KB

Organizations:
Policies:
Readers:
Type: ImplicitMeta
Rule: "ANY Readers"
Writers:
Type: ImplicitMeta
Rule: "ANY Writers"
Admins:
Type: ImplicitMeta
Rule: "MAJORITY Admins"

BlockValidation:
Type: ImplicitMeta
Rule: "ANY Writers
Listing 6:4 - Orderer section within the crypto-config.yaml file

• Profiles – HLF has different profile options that support different ordering service,
these include Kafka or Rafta, in this implementation used Rafta hence specified the
orderer details under the profile pointing to be the ClientTLSCert and ServerTLSCert
are located in the crypto-config directory.
• Capabilities – in this section definition for HLF v2.0 are orderers and peers are
defined, limiting any participants using older versions of fabric from participating.
 P a g e | 48

Capabilities:
Channel: &ChannelCapabilities
V2_0: true
Orderer: &OrdererCapabilities
V2_0: true
Application: &ApplicationCapabilities
V2_0: true
Listing 6:5 - Capabilities section within the crypto-config.yaml file

• Channel & Application – these sections are also included in the yaml file and define
the access control policies for readers, writers, and admins.

$ configtxgen -profile SampleMultiNodeEtcdRaft -channelID byfn-sys-channel -outputBlock

./channel-artifacts/genesis.block
Listing 6:6 - Generating genesis block with a channel ID to be saved in the channel-artifacts directory

Generation of the channel.tx artifact requires the TwoOrgsChannel profile which uses the
already stated Raft ordering service in genesis block generation (Hyperledger-fabric, 2019a).
Channel.tx artifact has definitions that have been used in the creation of an HLF channel
(Hyperledger-fabric, 2019a).

$ configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -

channelID ebenezer
Listing 6:7 - Generating the channel.tx artifacts using a new channelID “ebenezer”, this will be the channel name
used in this implementation

Using the configtxgen binary can define the anchor peer for the single consortium
organisation. This peer is used for the gossip protocol ensuring that peers across different
organisations can communicate. However, since this implementation include peers within
one organisation this is not required.
 P a g e | 49

Figure 6:6 - Directory structure of the generated channel artifacts

6.4 Starting the Hyperledger fabric network

All generated crypto material and channel artifacts must be copied to the Raspberry Pi 4.
Copying of these files ensures that the network is using the same crypto material and
channel artifacts. Next step in bringing up the HLF network now involves starting up docker
containers using the already setup docker images.

6.4.1 Docker containers for Hosts

Docker containers are layers built on top of specific docker images as shown in Figure 3:6 -
Illustration of docker container layers operating on top of docker images within Docker
environment. For this implementation created docker containers for Kali Linux VM and
Raspberry Pi 4 device using single docker compose yaml files for the different containers.
Within the yaml files specified the various containers to be created as required by the
different Hosts. Network component used by these compose files was the external docker
swarm overlay network.

The yaml files used in this implementation can be found on this project’s working repository
on GitHub (Chinyati, 2020b) and also in Appendix E. Each docker-compose yaml file had
the following components:
• Container name – this is the identifying container name on host.
• Image – this points to the docker image on which the container layer is built on.
• Networks – used the docker swarm overlay-network and this was the same network
the containers were to use for communication and connecting to any external
resource.
 P a g e | 50

• Environment variables – each container depends on a set of environment variables

for its execution, these include the Gopath, MSP directory, TLS certificate file all
specific to the container.
• Volumes – these point to the crypto-config and channel-artifacts folders created
when generating channel and genesis block. Pointing to these volumes allows
containers like the orderer to perform their functions.

To bring up the docker containers created scripts which would be run feeding on the yaml
files discussed earlier. Below is an illustration of bringing up the containers on a Kali Linux
VM which is the leader host in this implementation.

Figure 6:7 - Creating docker containers on Host1 (kali Linux VM), listed the docker
containers to show their status and names

6.4.2 Joining Peers to Channel

The channel artifacts generated earlier were then used to create a channel that is controlling
tasks that are undertaken by the peers with privacy and deterministic approach to what data
is handled in the HLF network. After creating the containers on both Kali and Raspberry pi
host is executing channel creation commands on the Kali host. These commands are joining
both peers on Kali and Raspberry Pi to the newly created “ebenezer”.
 P a g e | 51

$ docker exec cli peer channel create -o orderer.example.com:7050 -c ebenezer -f ./channel-

artifacts/channel.tx --tls --cafile
/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/ordererOrganizations/example.com/o
rderers/orderer.example.com/msp/tlscacerts/tlsca.example.com-cert.pem
sleep 5
Listing 6:8 - Creating channel using the peer binary tool and pointing to the orderer on Host 1. Channel name is
"ebenezer" and it takes configurations from earlier created channel.tx file

$ docker exec cli peer channel join -b ebenezer.block

Listing 6:9 - Command to join the peer0.org1.example.com on host 1 to the channel

$ docker exec -e CORE_PEER_ADDRESS=peer1.org1.example.com:8051 -e

CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/cr
ypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.crt cli peer channel
join -b ebenezer.block
Listing 6:10 - Joining peer1.org1.example.com to the channel, this peer is running on Host2 (Pi 4 device) hence
the need to define some of the variables within the Kali VM cli container

After executing the above commands within the cli container on Host1 the next step is to
check if the peers have joined the channel. Below is an image showing the output of the
check.

Figure 6:8 - Output from both Kali and Pi hosts showing the peers having joined the channel "ebenezer". The
Current Blockchain info showing height as 2 is outputted, height is 2 which includes genesis block and channel
file.

6.5 Access control Chaincode

In this implementation, developed a simple chaincode from the fabric samples chaincode
provided by Hyperledger fabric using Golang. This chaincode will provide access control
 P a g e | 52

functionality, with Admin users having all rights and general users restricted to view only.
Chaincode used in this implementation is accessible in Appendix D.

Created a new directory named access, and from the sacc chaincode folder in fabric
samples copied all the components into this new directory. Created a new go file named
access.go in this directory, within this file defined the chaincode logic. As defined in
(Hyperledger, 2020a) chaincode API’s can be leveraged to provide access control
functionality. The next section explains in detail the various components of the chaincode.

6.5.1 Imports
Golang like many programming languages requires imports to execute certain components
within the chaincode. In this chaincode the most import was the Client Identity Chaincode
Library (cid) which allows chaincode to provide access control dependent on identity of
requester (Fabric, 2020a). This chaincode depends on Shim which provides functionality to
call on variables and create transactions within HLF chaincode.

Figure 6:9 - Access.go chaincode imports

6.5.2 Struct
Struct which is short for structure in golang is used to keep data in collections and provide a
specified structure to it. This could be used to store read data in arrays whilst also providing
pointers to objects. In this implementation have a simple struct which manages the created
assets in the blockchain network, this struct is the one initialized first by the chaincode.

6.5.3 Functions
The access.go chaincode has general functions, these functions include “set”, “get” and
“invoke” which are used during chaincode query/invocation. One function is important for the
implementation of access control through chaincode, this is the Init function. This is the
 P a g e | 53

initialization function and will be invoked during the chaincode build process to allow the
chaincode to define initial values during first invocation (Hyperledger, 2020a).

Figure 6:10 - Set function using the client identity library to provide access control against non Admin accounts

6.6 Deploy Chaincode

Chaincode in HLF v2.1 follows a defined lifecycle from installation to invocation which differs
to v1.4. The details on how to build the access control chaincode from the packaging to
invocation of the chaincode is given. Below is an image showing the chaincode lifecycle.

Figure 6:11 - Chaincode deployment process, going through the various stages from packaging to invocation

6.6.1 Packaging Chaincode using cli container

Packaging chaincode involves creation of a tar file from chaincode directory. This directory
includes all the dependencies and the programmable logic files written in golang. Chaincode
 P a g e | 54

can only be installed on peers after it has been packaged. Using the cli container on
Raspberry Pi packaged the chaincode and then installed it on peer operating on Kali VM. As
discussed in Fabric chaincode design there were architectural errors causing the chaincode
to fail installing on Raspberry Pi if executed from Kali Linux VM cli container.

$ docker exec cli peer lifecycle chaincode package access.tar.gz --path

github.com/chaincode/access/go --label access_1
Listing 6:11 - Packaging access chaincode and providing a label. This execution is done in cli container on
Raspberry Pi device

After executing the above command on the Pi device, the cli container volume was checked
to see whether the new tar file was created.

Figure 6:12 - Output of the packaged access.tar chaincode

6.6.2 Installing Chaincode on peers

After packaging the chaincode and having the access.tar.gz file in container volume, the
chaincode on both peers on Kali VM and Raspberry Pi was installed. The installation is done
by the default user which is Admin, and the installed package is the same. After chaincode
has been installed on both peers docker images are created, these docker images will have
the chaincode package identifier on their name. This package identifier is the one used in
the next phase of approving the chaincode.
 P a g e | 55

Figure 6:13 - Chaincode installation using CLI container. Chaincode is installed on both Pi and Kali VM with a
package identifier being generated

6.6.3 Approve Chaincode definition for Organization

In this implementation there is one organization which has two peers, these peers need to
approve the chaincode definition and it counts as organization approval. Chaincode
definition contains several parameters that need to be similar across the organization.
Chaincode approval used the chaincode package identifier as well as the --init-required flag
due to its use in the chaincode, using these values parameters were checked (Hyperledger,
2020b).

Figure 6:14 - Chaincode approval, checking if parameters are valid across the organization, used a Certificate file
to verify identities and now chaincode is being checked in "ebenezer" channel

6.6.4 Commit the chaincode to channel

With chaincode definition approved in channel the next step is to check the commit
readiness of the chaincode. This verifies whether the chaincode will be successfully
 P a g e | 56

committed dependent on which peers have approved the chaincode. These commands will
be done by the organization administrator which is the default.

Figure 6:15 - Checking chaincode commit-readiness. There is need to state parameter values and channel name

After checking the commit readiness of the chaincode on the existing channel had to go
ahead and commit the channel producing output shown below.

Figure 6:16 - Committing the chaincode to both peer0.org1.example.com and peer1.org1.example.com and also
referencing the crypto materials

The above output commits the chaincode using the cli container on Raspberry pi as all the
above commands. However, there is need to define the peer address for peer on Kali VM
and to point to its crypto materials as they are required in commission. With chaincode now
committed will query the committed chaincode to see the chaincode definition parameters.
The chaincode definition has shown the plugins used for endorsements and validation as
well as the init_required flag amongst other parameters (Hyperledger, 2020b).

Listing 6:12 - Querying the committed chaincode and producing chaincode definition parameters as json output
 P a g e | 57

6.6.5 Access control operation

With chaincode installed, approved, and committed it is time to now invoke the chaincode.
This invocation will require the use of the init flag due to it being defined in chaincode and
being part of the chaincode definition as shown in image above. The invocation will set a
new value which will be added to the blockchain increasing the current Block size on
blockchain.

Figure 6:17 - Invoking chaincode to view current value in block

The recently added block can be queried from either Kali Linux or Pi device and the output
will be shown. This query is done with default user which is the Admin.

Figure 6:18 - Querying the newly added name value. On both Kali and Pi using the cli container get the same
output

All the commands performed thus far on the chaincode have been using the default Admin
user. For demonstration of access control will set the user to User1@org1.example.com, this
is the user created during crypto material generation. Due to this chaincode restricting only
user Admin to setting values, request to set values using User1 will result in failure.
 P a g e | 58

Figure 6:19 - Query on ledger using "User1" account to show access control for when 'set' function is called and it
is against endorsement policy.

After failure to set value using User1 account tried setting new name value using the default
Admin account. In this illustration performed the command on Kali VM to show that the same
chaincode is being interacted with on same channel just through docker’s command line
interface containers.

Figure 6:20 - Setting new name value using Admin account on chaincode

6.7 Summary of the Chapter

During the implementation chapter covered key sections that help answer some of the
objectives and key goals of this project. The major takeaways from this chapter include:
1. Hyperledger Fabric images and binaries were set up on amd64 architecture in this
instance a Kali Linux Virtual machine.
2. Built Hyperledger fabric images and binaries for Arm64/v8 architecture which were
used on Raspberry Pi 4 device. The Pi device is the IoT device in this research and
is not supported by HLF hence the need to build these images.
3. HLF does not provide documentation on how to setup Multi Host network
connections, in this implementation went in detail as to how to configure the two host
to communicate within HLF using Docker swarm as the orchestration tool.
 P a g e | 59

4. Configured identity and cryptographic materials for both Hosts creating a root of trust
between the devices based on the Raft ordering based cluster.
5. Created docker containers for the two hosts following an architecture discussed in
Chapter 5.
6. Connected peers on the same channel despite the architectural challenges.
7. Deployed chaincode on the HLF channel and had both peers interact with the
chaincode whilst also showing proof of concept as to how access control can be
achieved using HLF and IoT devices.
 P a g e | 60

7 EVALUATION

This chapter evaluated the developed solution analysing the generated data and using tools
to analyse the performance and network. The Hyperledger Fabric (HLF) blockchain
framework has been benchmarked to see its performance on the two architectures it has
deployed on.

7.1 Blockchain Info

Every blockchain starts with a genesis block that is connected to other blocks, hence
creating a chain. As illustrated in Figure 2:1 - Illustration of Blockchain from the genesis
block until there is a fork in the chain, the implementation in this research created a block
with no forks. These blocks could be viewed from checking the channel information. The
height of the Blockchain would increase after creation of each new block, at the end of the
test on the chaincode, the Blockchain info had size of 6.

Figure 7:1 - Blockchain info showing current and previous Block Hashes, each new block has a connection to the
previous height record

Figure 7:1 - Blockchain info showing current and previous Block Hashes, each new block
has a connection to the previous height record, shows the changes that were occurring
whenever a new block was added to the chain. However, within these records each block is
connected to the previous through the previous block hash. When the solution was being
setup the first blocks that are recorded are the channel and genesis block files.
 P a g e | 61

7.2 Chaincode Testing

Chaincode implementation was written in Golang which is the programming language that
Hyperledger Fabric is based upon. Chaincode execution can be exploited by malicious users
to take control of the system. Hence security of chaincode throughout the software
development lifecycle is critical. This entails protecting against buffer overflows and
exception errors that can cause crashes and flaws. Chaincode in Blockchains needs to be
deterministic to avoid having the ledger with inconsistencies across nodes.

Tried evaluating the chaincode in this implementation using ChainSecurity (ChainSecurity,

2020). ChainSecurity is a proprietary tool that currently is the only static analysis tool for
Hyperledger Fabric chaincode. It provides a free version; however, this version does not
support chaincode developed using Hyperledger Fabric v2.1.0. The test from ChainSecurity
was unsuccessful with the go repository failing to be read due to version differences.

Hyperledger fabric provides testing functionality for go chaincode using the shim package
which allows for creation of testing functions on the existing chaincode functions. Created a
testing class which checks the various chaincode lifecycle calls like Init functions, Query and
Invoke as well as the set function which implements the access control logic. This testing
mechanisms worked and the chaincode did not have any errors and all tests were
successful.

Figure 7:2 - Demonstration of chaincode testing using golang testing code with specific invocation of functions
 P a g e | 62

7.3 Metrics generation with Prometheus

Prometheus is a toolkit built in 2012 by Soundcloud to provide system metrics and alerts
(Prometheus, 2019). Prometheus is an open source tool that has been incorporated into the
operations service for HLF. Choice to use Prometheus for the evaluation of this project and
generation of metrics was straightforward since the other available options Hyperledger
Caliper and StatsD do not support HLF v2.1.0 and had technical glitches, respectively.

Within the operations service of HLF the peer and orderer containers within the host can
consume a RESTful API. This API does not belong to the HLF network rather its only for use
by operators not the users belonging to the network (Fabric, 2020c). The API provides with a
functionality to check the health status of the HLF network at a particular time which is
imperative in cases of anomaly behaviours. Using this same API, metrics are generated in
raw text format showing various references that relate to peers in a host. The metrics
generated by the RESTful API are the ones consumed by Prometheus to provide a visual
console and graph output of the HLF network participants.

Figure 7:3 - Health check on Raspberry Pi device

 P a g e | 63

In Appendix C setup of the operations service and Prometheus toolkit is explained in detail.
Operations service and Prometheus provide some important metrics for Hyperledger fabric
network. Prometheus after setup can be accessed on Web view using https://localhost:9090.
Below is an image showing the set targets with their metric scrapped and already generate
into Prometheus.

Figure 7:4 - Targets listed in Prometheus, the targets include the containers on kali VM and Raspberry Pi

For the generated metrics decided to focus on three metric counters in over 20 generated
metrics. These metrics cover the ledger, transactions, and memory consumption:
• Ledger blockchain height – this metric is provided by both orderer and peer nodes
• Server stream requests – time taken to complete a transaction; this is given by the
orderer nodes.
• Process virtual memory – metric shows the virtual memory consumed by the nodes
when handling transactions.
 P a g e | 64

7.3.1 Ledger Blockchain height

In the section above Blockchain Info highlighted the different hashed values created when a
new block is added to the ledger. With prometheus the blockchain height can be checked to
see if it is the same across all peers within the channel. For implementations with more than
1 channel the height can differ since each channel definition gets blocks relating to it. Below
is an illustration of the blockchain height viewed in Prometheus.

Figure 7:5 - Ledger blockchain height query showing the changes occurring on both peers

7.3.2 Server unary requests

Hyperledger fabric makes use of the grpc protocol, this feature allows for remote connection,
health checking and authentication across the HLF network (GRPC, 2020). With HLF
operations service grpc-server-unary-requests are generated showing the time taken to
complete a unary request.
 P a g e | 65

Figure 7:6 - Unary requests count on nodes within the two hosts

These requests are sent to nodes where they are read, and confirmation is sent back to
grpc. In this implementation the peer and orderer on Kali VM performed faster and more
efficiently compared to the Raspberry Pi due to hardware differences. In Figure 7:6 - Unary
requests count on nodes within the two hosts, a counter graph showing the performance of
the nodes is shown with peer0.org1.example.com achieving faster times.

7.3.3 Process virtual memory

On the two hosts in this implementation they both had 4GB of RAM as shown in Table 5:1 -
Hardware specifications of devices used in the implementation of this project. The difference
in processor speeds has been shown to affect the speed of processing requests in the
above section, this section shows how the virtual memory allocated to each device was
consumed. Kali Linux VM consumed less virtual memory for both its peer and orderer nodes,
it had the leader orderer as well. Raspberry Pi device however, consumed more memory
due to the lack of computational power; the graph below shows that running HLF on a 2GB
Pi device could prove challenging since the peer node consumed more than 1.4GB of RAM.
 P a g e | 66

Figure 7:7 - Virtual memory consumed on both Raspberry Pi and Kali Linux

It can also be noted in the graph that the orderer2 which is on Raspberry Pi did not consume
any resource mainly because it did not need to order any transactions, the root of trust was
on the orderer on Kali VM as specified with Raft ordering service.
 P a g e | 67

8 CONCLUSION

This is the final chapter of the research project, the section summarises the findings,
contributions and gives recommendations of the future work.

8.1 Summary
This research discussed what Blockchain technologies are and what solutions they offer to
industry and specifically IoT devices. Discussed some of the solutions researched into for
IoT devices using Blockchain solutions whilst also highlighting their short comings. Chose
Hyperledger Fabric for a proposed solution to securing IoT devices.

AMD64 and ARM64 architecture devices were used to demonstrate a real world IoT
scenario, the ARM64 device was a Raspberry Pi device. This device, however, did not have
the required docker images for running HLF which led to building of these images for HLF
v2.1. Using these newly built images deployed Hyperledger Fabric across the AMD64 Kali
VM and the Pi device using Multi-Host configuration which was powered by an orchestration
tool in docker swarm. This illustration was done locally with networking and configurations
handled on device.

HLF was deployed using Raft ordering service which provided a root of trust mechanism
across the nodes. This ordering service managed what nodes and peers could perform
actions whilst also leveraging on membership service provider to restrict entry of new
parties. Concluded the implementation by developing chaincode that addressed access
control measures on read/write for different user levels.

Evaluated the implementation showing how the operations service in HLF can check the
health of peers and create logs to help with debugging. Using Prometheus managed to
generate the metrics and access them using web view and generate graphs showing
performance of the network across the two hosts. The Raspberry Pi 4 device managed to
execute HLF slightly less efficient than the Kali VM, however it concludes that blockchain
technology can be used on IoT devices.
 P a g e | 68

8.2 Contributions
This research project implemented a solution to provide IoT solutions through blockchain
technologies, using Hyperledger Fabric. Hyperledger Fabric does not officially support
development and deployment on ARM64 devices hence this was a novel research showing
improvements and uses that HLF build on. The problem statement for the research as
discussed in section 1.2, brought up three problems:
• Blockchain when applied to IoT devices can achieve gains for Confidentiality
and Integrity compared to the current approaches?
Hyperledger fabric being a permissioned blockchain inherently has confidentiality and
integrity built in by design. However, in our implementation cryptographic materials for
identity and TLS for confidential communication were generated ensuring
confidentiality of nodes and provisions for integrity.
• Hyperledger Fabric smart contracts help in ensuring access control and root of
trust models for IoT objects?
In this implementation developed a golang chaincode that had access control logic.
This chaincode could only be deployed from the IoT device in this instance a
Raspberry pi device, when deployed it did function well and provide access control
restrictions. However, in a production setup the chaincode would need to be
deployed from a host machine (AMD64 powered) to ARM64 device and this is still a
challenge when working with HLF. Root of trust models were attained through use of
the Raft based ordering service and the membership service providers within HLF.
• Can Blockchains be integrated with existing IoT devices despite computational
and architectural limitations?
Based on this research Hyperledger Fabric a blockchain technology could be
integrated with IoT device. However, there were architectural issues since HLF does
not provide docker images for ARM64 architecture. Had to build images for the
architecture and binaries to be able to access the framework. From the evaluation done
HLF does not require a lot of computational power to be able to run on the Raspberry
Pi 4 device however this is not a low end device.

8.3 Future Work

Considering the time spent on this thesis building Hyperledger fabric images for ARM64
architecture and debugging several bugs, time spent experimenting and evaluating the
solution was less. The lack of network resources, computational power and IoT devices
limited the possibilities of this research. Exploring benchmarking solutions that can work with
 P a g e | 69

Hyperledger Fabric v2.1.0 is a top priority since Hyperledger Caliper failed to measure this
setup.

For future work would like to explore the idea of running Hyperledger fabric multi host setup
on more than one ARM based device. The setup for this project had network challenges due
to the use of a VirtualBox virtual machine, would like to pursue setup using cloud based VMs
as these come with network configurations which make deployment easy.

Raspberry pi devices could not receive chaincode installations from a Kali Linux host due to
architectural difference. Would want to investigate and research solutions to help make
Hyperledger Fabric components compatible despite the architectural differences. Could not
pursue using real life sensors and actuators on the Pi device due to challenges integrating
the state database “CouchDB”, this is another area of future research dealing with real IoT
generated data.

Utilized docker swarm configuration in this project for the network setup, would like to pursue
use of docker deploy working with IoT devices to deploy chaincode containers across the
hosts. This could provide benefits for firmware update or security patches. Chaincode
execution can be improved and I desire to develop chaincode that implements more access
control measures whilst also leveraging on the root of trust provided by HLF. A user interface
that makes use of the APIs provided by HLF could make the overall solution become more
intuitive.
 P a g e | 70

BIBLIOGRAHPY

Ali, M.S., Dolui, K. and Antonelli, F. (2017). IoT data privacy via blockchains and IPFS. ACM
International Conference Proceeding Series. 22 October 2017. Association for
Computing Machinery, 1–2. Available from https://doi.org/10.1145/3131542.3131563.
Ali, M.S. et al. (2019). Applications of Blockchains in the Internet of Things: A
Comprehensive Survey. IEEE Communications Surveys and Tutorials, 21 (2), 1–34.
Available from https://doi.org/10.1109/COMST.2018.2886932.
Androulaki, E. et al. (2018). Hyperledger Fabric: A Distributed Operating System for
Permissioned Blockchains. Proceedings of the 13th EuroSys Conference, EuroSys
2018. 23 April 2018. Association for Computing Machinery, Inc, 1. Available from
https://doi.org/10.1145/3190508.3190538 [Accessed 23 June 2020].
Atzei, N. et al. (2017). A survey of attacks on Ethereum smart contracts (SoK). Lecture
Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence
and Lecture Notes in Bioinformatics). 2017. Springer Verlag, 164–186. Available from
https://doi.org/10.1007/978-3-662-54455-6_8 [Accessed 14 July 2020].
Ban, T.Q. et al. (2019). Survey of hyperledger blockchain frameworks: Case study in FPT
university’s cryptocurrency wallets. ACM International Conference Proceeding Series.
2019. Association for Computing Machinery, 2–4. Available from
https://doi.org/10.1145/3316615.3316671.
Barki, A. et al. (2016). M2M Security: Challenges and Solutions. IEEE Communications
Surveys and Tutorials, 18 (2), 2–3. Available from
https://doi.org/10.1109/COMST.2016.2515516.
Barkstrom, J. and Barkstrom, J. (2019). What is a Raspberry Pi? Introduction to the
Raspberry Pi. Available from https://doi.org/10.1007/978-1-4842-5571-1_1 [Accessed 6
August 2020].
Bashir, I. (2017). Mastering Blockchain. Available from
https://learning.oreilly.com/library/view/mastering-blockchain-/9781788839044/
[Accessed 26 June 2020].
Biser Dimitrov. (2020). How Walmart And Others Are Riding A Blockchain Wave To Supply
Chain Paradise. Forbes.org. Available from
https://www.forbes.com/sites/biserdimitrov/2019/12/05/how-walmart-and-others-are-
riding-a-blockchain-wave-to-supply-chain-paradise/ [Accessed 22 August 2020].
Bitcoin.org. (2020). FAQ - Bitcoin. Bitcoin.org. Available from https://bitcoin.org/en/faq#who-
created-bitcoin [Accessed 22 August 2020].
 P a g e | 71

Buterin, V. (2016). Ethereum Proof of Stake. Ethereum Wiki. Available from

https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/proof-of-stake/ [Accessed 26
June 2020].
Cachin, C., Schubert, S. and Vukolić, M. (2017). Non-determinism in Byzantine fault-tolerant
replication. Available from https://doi.org/10.4230/LIPIcs.OPODIS.2016.24 [Accessed
14 July 2020].
Casino, F., Dasaklis, T.K. and Patsakis, C. (2019). A systematic literature review of
blockchain-based applications: Current status, classification and open issues.
Telematics and Informatics, 36, 1–3. Available from
https://doi.org/10.1016/j.tele.2018.11.006.
ChainSecurity. (2020). ChainSecurity Chaincode Scanner ♦ Analyse Hyperledger Fabric
Chaincode for Vulnerabilities. https://chaincode.chainsecurity.com/. Available from
https://chaincode.chainsecurity.com/ [Accessed 3 September 2020].
Cheruvu, S. et al. (2020). Demystifying Internet of Things Security. Apress. Available from
https://doi.org/10.1007/978-1-4842-2896-8.
Chinyati, E. (2020a). chinyati/Hyperledger-Fabric-ARM64-images: These are Hyperledger
Fabric arm64 images and binaries for use on Raspberry Pi 4+ running Raspbian OS 64
Bit. Github. Available from https://github.com/chinyati/Hyperledger-Fabric-ARM64-
images [Accessed 13 August 2020].
Chinyati, E. (2020b). chinyati/Hyperledger-Fabric-IoT-Project. Github. Available from
https://github.com/chinyati/Hyperledger-Fabric-IoT-Project [Accessed 24 August 2020].
Docker Inc. (2017). Overview of Docker Compose | Docker Documentation. Docker Inc.
Available from
https://docs.docker.com/compose/%0Ahttps://docs.docker.com/compose/%0Ahttps://do
cs.docker.com/compose/overview/ [Accessed 27 June 2020].
Docker Inc. (2019). Swarm mode key concepts - Docker Documentation. Docker.Com.
Available from https://docs.docker.com/engine/swarm/key-concepts/ [Accessed 13
August 2020].
Docker Inc. (2020). What is a Container? | App Containerization | Docker. Docker.Com.
Available from https://www.docker.com/resources/what-container [Accessed 27 June
2020].
Dorri, A., Kanhere, S.S. and Jurdak, R. (2017). Towards an optimized blockchain for IoT.
Proceedings - 2017 IEEE/ACM 2nd International Conference on Internet-of-Things
Design and Implementation, IoTDI 2017 (part of CPS Week). 18 April 2017. Association
for Computing Machinery, Inc, 1–3. Available from
https://doi.org/10.1145/3054977.3055003.
El Ioini, N. and Pahl, C. (2018). A review of distributed ledger technologies. Lecture Notes in
 P a g e | 72

Computer Science (including subseries Lecture Notes in Artificial Intelligence and

Lecture Notes in Bioinformatics). 2018. Springer Verlag, 2–4. Available from
https://doi.org/10.1007/978-3-030-02671-4_16 [Accessed 2 July 2020].
Elrom, E. (2019). The Blockchain Developer: A Practical Guide for Designing,
Implementing, Publishing, Testing, and Securing Distributed Blockchain-based
Projects. The Blockchain Developer: A Practical Guide for Designing, Implementing,
Publishing, Testing, and Securing Distributed Blockchain-based Projects. Apress, 1–30.
Available from https://doi.org/10.1007/978-1-4842-4847-8_1.
Fabric, H. (2020a). fabric-chaincode-go/README.md at master · hyperledger/fabric-
chaincode-go. https://github.com. Available from https://github.com/hyperledger/fabric-
chaincode-go/blob/master/pkg/cid/README.md [Accessed 28 August 2020].
Fabric, H. (2020b). Release v2.1.0 · hyperledger/fabric. Github.com. Available from
https://github.com/hyperledger/fabric/releases/tag/v2.1.0 [Accessed 13 August 2020].
Fabric, H. (2020c). The Operations Service — hyperledger-fabricdocs master
documentation. https://hyperledger-fabric.readthedocs.io. Available from
https://hyperledger-fabric.readthedocs.io/en/release-2.0/operations_service.html
[Accessed 5 September 2020].
Fett, D., Küsters, R. and Schmitz, G. (2016). A comprehensive formal security analysis of
OAuth 2.0. Proceedings of the ACM Conference on Computer and Communications
Security. 24 October 2016. New York, NY, USA: Association for Computing Machinery,
1204–1215. Available from https://doi.org/10.1145/2976749.2978385 [Accessed 13 July
2020].
Foundation, R.P. (2019). GPIO - Raspberry Pi Documentation. Raspberry Pi. Available from
https://www.raspberrypi.org/documentation/usage/gpio/ [Accessed 7 August 2020].
Framingham, M. (2019). The Growth in Connected IoT Devices Is Expected to Generate
79.4ZB of Data in 2025, According to a New IDC Forecast. International Data
Corporation. Available from
https://www.idc.com/getdoc.jsp?containerId=prUS45213219 [Accessed 9 July 2020].
Gilchrist, A. (2017). IoT Security Issues. Berlin, Boston: De Gruyter. Available from
https://doi.org/10.1515/9781501505775 [Accessed 7 July 2020].
Greenwald, G. and Macaskill, E. (2013). NSA Prism program taps in to user data of Apple ,
Google and others. The Guardian. Available from
http://www.theguardian.com/world/2013/jun/06/us-tech-giants-nsa-data [Accessed 22
June 2020].
GRPC. (2020). gRPC – A high-performance, open source universal RPC framework.
https://grpc.io/. Available from https://grpc.io/ [Accessed 6 September 2020].
Gurunath, R. et al. (2019). An overview: Security issue in IoT network. Proceedings of the
 P a g e | 73

International Conference on I-SMAC (IoT in Social, Mobile, Analytics and Cloud), I-

SMAC 2018. 26 February 2019. Institute of Electrical and Electronics Engineers Inc., 2–
3. Available from https://doi.org/10.1109/I-SMAC.2018.8653728.
Hameed, A. and Alomary, A. (2019). Security issues in IoT: A survey. 2019 International
Conference on Innovation and Intelligence for Informatics, Computing, and
Technologies, 3ICT 2019. 1 September 2019. Institute of Electrical and Electronics
Engineers Inc., 2–3. Available from https://doi.org/10.1109/3ICT.2019.8910320.
Houben, R. and Snyers, A. (2018). Cryptocurrencies and blockchain Legal context and
implications for financial crime, money laundering and tax evasion STUDY Requested
by the TAX3 committee Policy Department for Economic, Scientific and Quality of Life
Policies.
Hyperledger-fabric. (2019a). Building Your First Network — hyperledger-fabricdocs master
documentation. https://hyperledger-fabric.readthedocs.io. Available from
https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html [Accessed 20
August 2020].
Hyperledger-fabric. (2019b). Chaincode for Operators — hyperledger-fabricdocs master
documentation. Hyperledger-Fabric.Readthedocs.Io. Available from https://hyperledger-
fabric.readthedocs.io/en/release-1.4/chaincode4noah.html [Accessed 21 July 2020].
Hyperledger-fabric. (2019c). Fabric CA User’s Guide — hyperledger-fabric-cadocs master
documentation. hyperledger-fabric-ca. Available from https://hyperledger-fabric-
ca.readthedocs.io/en/release-1.4/users-guide.html [Accessed 13 July 2020].
Hyperledger-fabric. (2019d). The Ordering Service — hyperledger-fabricdocs master
documentation. https://hyperledger-fabric.readthedocs.io. Available from
https://hyperledger-fabric.readthedocs.io/en/release-2.0/orderer/ordering_service.html
[Accessed 23 August 2020].
Hyperledger-fabric. (2020a). CouchDB as the State Database — hyperledger-fabricdocs
master documentation. Hyperledger-Fabric.Readthedocs.Io. Available from
https://hyperledger-fabric.readthedocs.io/en/release-
1.1/couchdb_as_state_database.html [Accessed 12 August 2020].
Hyperledger-fabric. (2020b). Ledger — hyperledger-fabricdocs master documentation.
Hyperledger-fabric.readthedocs.io. Available from https://hyperledger-
fabric.readthedocs.io/en/release-2.2/ledger/ledger.html?highlight=world state [Accessed
23 August 2020].
Hyperledger-fabric. (2020c). Membership Service Provider (MSP). Hyperledger-
Fabric.Readthedocs.Io. Available from https://hyperledger-
fabric.readthedocs.io/en/release-2.0/membership/membership.html [Accessed 13 July
2020].
 P a g e | 74

Hyperledger-fabric. (2020d). What’s new in Hyperledger Fabric v2.x — hyperledger-

fabricdocs master documentation. Hyperledger-Fabric.Readthedocs.Io. Available from
https://hyperledger-fabric.readthedocs.io/en/release-2.2/whatsnew.html [Accessed 19
August 2020].
Hyperledger.org. (2019). OrgBook Case Study – Hyperledger. Hyperledger.org. Available
from https://www.hyperledger.org/learn/publications/orgbook-case-study [Accessed 22
August 2020].
Hyperledger.org. (2020). Soramitsu Case Study – Hyperledger. Hyperledger.org. Available
from https://www.hyperledger.org/learn/publications/soramitsu-case-study [Accessed
22 August 2020].
Hyperledger. (2019a). About the Hyperledger Architecture Working Group. Available from
https://www.hyperledger.org/wp-
content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf [Accessed
2 July 2020].
Hyperledger. (2019b). Install Samples, Binaries and Docker Images — hyperledger-
fabricdocs master documentation. https://hyperledger-fabric.readthedocs.io. Available
from https://hyperledger-fabric.readthedocs.io/en/release-1.4/install.html [Accessed 28
August 2020].
Hyperledger. (2020a). Chaincode for Developers — hyperledger-fabricdocs master
documentation. https://hyperledger-fabric.readthedocs.io. Available from
https://hyperledger-
fabric.readthedocs.io/en/latest/chaincode4ade.html?highlight=chaincode. [Accessed 28
August 2020].
Hyperledger. (2020b). Fabric chaincode lifecycle — hyperledger-fabricdocs master
documentation. https://hyperledger-fabric.readthedocs.io. Available from
https://hyperledger-fabric.readthedocs.io/en/release-
2.1/chaincode_lifecycle.html?highlight=chaincode [Accessed 28 August 2020].
HyperledgerDocs. (2018). Introduction — hyperledger-fabricdocs master documentation.
Hyperledger-Fabric.Readthedocs.Io. Available from
https://doi.org/10.2320/matertrans.47.1898 [Accessed 26 June 2020].
HyperledgerDocs. (2020). Identity — hyperledger-fabricdocs master documentation.
Hyperledger-Fabric.Readthedocs.Io. Available from https://hyperledger-
fabric.readthedocs.io/en/release-2.2/identity/identity.html [Accessed 13 July 2020].
Inc., D. (2020). Glossary | Docker Documentation. Docker.Com. Available from
https://docs.docker.com/glossary/?term=Docker [Accessed 12 August 2020].
KC Tam. (2020). Two Ways to Generate Crypto Materials in Hyperledger Fabric: Cryptogen
and CA Server | by KC Tam | Medium. Medium. Available from
 P a g e | 75

https://medium.com/@kctheservant/two-ways-to-generate-crypto-materials-in-
hyperledger-fabric-cryptogen-and-ca-server-36d3c3e2daad [Accessed 24 August
2020].
Lamport, L., Shostak, R. and Pease, M. (1982). The Byzantine Generals Problem. ACM
Transactions on Programming Languages and Systems (TOPLAS), 4 (3), 382–401.
Available from https://doi.org/10.1145/357172.357176.
Lockhart, H., Thomas Wisniewski, B. and Prateek Mishra, E. (2005). Security Assertion
Markup Language (SAML) V2.0 Technical Overview Working Draft 08, 12 September
2005 Document identifier: sstc-saml-tech-overview-2.0-draft-08. Available from
http://www.oasis-open.org/committees/documents.php?wg_abbrev=security [Accessed
13 July 2020].
Manjaro.org. (2020). Manjaro - Downloads. Manjaro.org. Available from
https://manjaro.org/download/ [Accessed 15 August 2020].
Mansour, S. and Lauf, A. (2020). Hardware Root of Trust for IoT Security in Smart Home
Systems. 2020 IEEE 17th Annual Consumer Communications and Networking
Conference, CCNC 2020. 1 January 2020. Institute of Electrical and Electronics
Engineers Inc., 1–4. Available from https://doi.org/10.1109/CCNC46108.2020.9045412.
Maple, C. and Jackson, J. (2019). Selecting effective blockchain solutions. Lecture Notes in
Computer Science (including subseries Lecture Notes in Artificial Intelligence and
Lecture Notes in Bioinformatics). Springer Verlag, 2–4. Available from
https://doi.org/10.1007/978-3-030-10549-5_31 [Accessed 2 July 2020].
Novo, O. (2018). Blockchain Meets IoT: An Architecture for Scalable Access Management in
IoT. IEEE Internet of Things Journal, 5 (2), 1–3. Available from
https://doi.org/10.1109/JIOT.2018.2812239.
Ongaro, D. and Ousterhout, J. (2014). In search of an understandable consensus algorithm.
Proceedings of the 2014 USENIX Annual Technical Conference, USENIX ATC 2014.
2014. 305–319. Available from https://raft.github.io/raft.pdf [Accessed 23 August 2020].
Opensuse. (2020). HCL:Raspberry Pi4 - openSUSE Wiki. Opensuse.org. Available from
https://en.opensuse.org/HCL:Raspberry_Pi4 [Accessed 15 August 2020].
Ouaddah, A. et al. (2017). Access control in the Internet of Things: Big challenges and new
opportunities. Computer Networks, 112, 2–3. Available from
https://doi.org/10.1016/j.comnet.2016.11.007.
Ouaddah, A., Elkalam, A.A. and Ouahman, A.A. (2017). Harnessing the power of blockchain
technology to solve IoT security & privacy issues. Proceedings of the Second
International Conference on Internet of things, Data and Cloud Computing - ICC ’17.
2017. New York, New York, USA: Association for Computing Machinery (ACM), 1–6.
Available from https://doi.org/10.1145/3018896.3018901 [Accessed 29 June 2020].
 P a g e | 76

Parizi, R.M. et al. (2018). Empirical Vulnerability Analysis of Automated Smart Contracts
Security Testing on Blockchains. ACM, 1–10. Available from
https://doi.org/10.5555/3291291.3291303 [Accessed 14 July 2020].
Porambage, P. et al. (2014). PAuthKey: A Pervasive Authentication Protocol and Key
Establishment Scheme for Wireless Sensor Networks in Distributed IoT Applications.
International Journal of Distributed Sensor Networks, 2014, 1–3. Available from
https://doi.org/10.1155/2014/357430 [Accessed 29 June 2020].
Prometheus. (2019). Overview | Prometheus. https://prometheus.io/docs. Available from
https://prometheus.io/docs/introduction/overview/ [Accessed 4 September 2020].
Raspberry Pi Foundation. (2020). 8GB Raspberry Pi 4 on sale now at $75 - Raspberry Pi.
Raspberry Pi. Available from https://www.raspberrypi.org/blog/8gb-raspberry-pi-4-on-
sale-now-at-75/ [Accessed 6 August 2020].
RaspberryPi. (2020). Raspberry Pi OS (64 bit) beta test version - Raspberry Pi Forums.
Raspberrypi.org. Available from
https://www.raspberrypi.org/forums/viewtopic.php?t=275370 [Accessed 15 August
2020].
Recordon, D. and Reed, D. (2006). OpenID 2.0: A platform for user-centric identity
management. Proceedings of the Second ACM Workshop on Digital Identity
Management, DIM 2006. Co-located with the 13th ACM Conference on Computer and
Communications Security, CCS’06. 2006. New York, New York, USA: ACM Press, 11–
16. Available from https://doi.org/10.1145/1179529.1179532 [Accessed 13 July 2020].
Rocha, A. de la and María Teresa Nieto, T. (2020). TrustID: A New Approach to Fabric User
Identity Management – Hyperledger. Hyperledger.Org. Available from
https://www.hyperledger.org/blog/2020/04/21/trustid-a-new-approach-to-fabric-user-
identity-management [Accessed 29 June 2020].
Rouhani, S., Pourheidari, V. and Deters, R. (2018). Physical Access Control Management
System Based on Permissioned Blockchain. Proceedings - IEEE 2018 International
Congress on Cybermatics: 2018 IEEE Conferences on Internet of Things, Green
Computing and Communications, Cyber, Physical and Social Computing, Smart Data,
Blockchain, Computer and Information Technology, iThings/Gree. July 2018. 1–3.
Available from https://doi.org/10.1109/Cybermatics_2018.2018.00198.
Sharaf-Dabbagh, Y. and Saad, W. (2016). On the authentication of devices in the Internet of
things. WoWMoM 2016 - 17th International Symposium on a World of Wireless, Mobile
and Multimedia Networks. 26 July 2016. Institute of Electrical and Electronics
Engineers Inc., 1–2. Available from https://doi.org/10.1109/WoWMoM.2016.7523532.
Tamboli, A. (2019). Build Your Own IoT Platform. Apress. Available from
https://doi.org/10.1007/978-1-4842-4498-2.
 P a g e | 77

The Linux Foundation. (2017). Blockchain Technology Projects – Hyperledger.

Https://Www.Hyperledger.Org/. Available from https://www.hyperledger.org/projects
[Accessed 14 July 2020].
Ubuntu-Mate. (2020). Choose a release | Download. Ubuntu-Mate. Available from
https://ubuntu-mate.org/download/amd64/ [Accessed 15 August 2020].
Ubuntu. (2020). Install Ubuntu Server on a Raspberry Pi 2, 3 or 4 | Ubuntu. Ubuntu.com.
Available from https://ubuntu.com/download/raspberry-pi [Accessed 15 August 2020].
Vemuri, V.K. (2018). Blockchain: a practical guide to developing business, law, and
technology solutions. McGraw-Hill. Available from
https://doi.org/10.1080/15228053.2019.1588546 [Accessed 26 June 2020].
VirtualBox. (2019). Chapter 6. Virtual Networking. VirtualBox. Available from
https://www.virtualbox.org/manual/ch06.html [Accessed 19 August 2020].
Wrona, K. and Jarosz, M. (2019). Use of blockchains for secure binding of metadata in
military applications of IoT. IEEE 5th World Forum on Internet of Things, WF-IoT 2019 -
Conference Proceedings. 1 April 2019. Institute of Electrical and Electronics Engineers
Inc., 1–4. Available from https://doi.org/10.1109/WF-IoT.2019.8767315.
Yaml.org. (2011). The Official {YAML} Web Site. yaml.org. Available from https://yaml.org
[Accessed 20 August 2020].
Zhang, Y. et al. (2019). Smart contract-based access control for the internet of things. IEEE
Internet of Things Journal, 6 (2), 2–3. Available from
https://doi.org/10.1109/JIOT.2018.2847705.
Zhao, W. (2014). Building Dependable Distributed Systems. Somerset, UNITED STATES:
John Wiley & Sons, Incorporated. Available from
https://doi.org/10.1002/9781118912744.
Zhou, J. et al. (2017). Security and Privacy for Cloud-Based IoT: Challenges. IEEE
Communications Magazine, 55 (1), 1–6. Available from
https://doi.org/10.1109/MCOM.2017.1600363CM.
 P a g e | 78

APPENDIX A: SYSTEM SPECIFICATIONS AND

CONFIGURATIONS

In this research created a system based on a permissioned blockchain, namely Hyperledger

fabric. The implementation was on laptop hardware and on Raspberry pi 4 device. In this
section will explain in detail how to setup the two device architectures and configure them for
use.

Getting started
On both Virtual machine and Raspberry pi device installed operating system variants of
Debian Linux.
1. Virtual machine – Kali Linux 5.7.6-kali-amd64, x86_64
2. Raspberry Pi – Raspbian OS 5.4.51-v8+ (Beta Version), aarch64

On top on these operating systems installed the following dependencies:

• Git
• Node
• Java
• Docker and docker compose
• Golang
Wrote a script (HLF-Prerequisites) to install these dependencies which is available on my
GitHub repository (Chinyati, 2020a).

Download HLF images for Kali

For Kali Linux virtual machine after installing the dependencies and prerequisites needed to
operate HLF, execute the following command to allow download of the fabric samples, binaries
and the docker images for HLF.
$ curl -sSL https://bit.ly/2ysbOFE | bash -s -- 2.1.0 1.4.7 0.4.20

The above script defines the HLF version, fabric certificate authority version and the third party
version. After execution of this script execute $ docker images to see the list of all images that
have been pulled from the HLF repository.
 P a g e | 79

For this project’s files download the folder from the GitHub repository and paste into the fabric-
samples directory.
https://github.com/chinyati/Hyperledger-Fabric-IoT-Project/releases/tag/v2.1.0

Now the config and chaincode files are specific for this project.

HLF images for Raspberry Pi

Images for Raspberry Pi are not supplied by the Hyperledger foundation and must be built
manually. In Appendix B illustrated how to build these images for debian:buster environment
on the Raspberry Pi, these instructions can be tailored for your specific Operating system.

To use the Docker images built in this research created a bash script (Download-HLF-images)
(Chinyati, 2020a). Below are the command to be executed on command line.

#!/bin/bash
# Download the Hyperledger ARM64 images and tag them as the default hyperledger/fabric images

# fabric-baseimage
docker pull chinyati/fabric-baseimage:arm64-0.4.20
docker tag chinyati/fabric-baseimage:arm64-0.4.20 hyperledger/fabric-baseimage:2.1
docker tag chinyati/fabric-baseimage:arm64-0.4.20 hyperledger/fabric-baseimage:latest

# fabric-baseos
docker pull chinyati/fabric-baseos:arm64-0.4.20
docker tag chinyati/fabric-baseos:arm64-0.4.20 hyperledger/fabric-baseos:2.1
docker tag chinyati/fabric-baseos:arm64-0.4.20 hyperledger/fabric-baseos:latest

# fabric-tools
docker pull chinyati/fabric-tools:arm64-2.1.0
docker tag chinyati/fabric-tools:arm64-2.1.0 hyperledger/fabric-tools:2.1
docker tag chinyati/fabric-tools:arm64-2.1.0 hyperledger/fabric-tools:latest

# orderer
docker pull chinyati/fabric-orderer:arm64-2.1.0
docker tag chinyati/fabric-orderer:arm64-2.1.0 hyperledger/fabric-orderer:2.1
docker tag chinyati/fabric-orderer:arm64-2.1.0 hyperledger/fabric-orderer:latest
 P a g e | 80

# peer
docker pull chinyati/fabric-peer:arm64-2.1.0
docker tag chinyati/fabric-peer:arm64-2.1.0 hyperledger/fabric-peer:2.1
docker tag chinyati/fabric-peer:arm64-2.1.0 hyperledger/fabric-peer:latest

# fabric-ccenv
docker pull chinyati/fabric-ccenv:arm64-2.1.0
docker tag chinyati/fabric-ccenv:arm64-2.1.0 hyperledger/fabric-ccenv:2.1
docker tag chinyati/fabric-ccenv:arm64-2.1.0 hyperledger/fabric-ccenv:latest

The above commands will pull the docker images from docker hub repository for user chinyati
and tag them as hyperledger-fabric on the Pi device. This is necessary to avoid compilation
and runtime errors that occur when interacting with HLF network. After execution of the
commands execute $ docker images and it will show the downloaded docker images.

HLF works with fabric samples which contains chaincode, binaries and configuration material
used by the framework. For the ARM64 device download the fabric-samples for AMD64 in a
directory of your choice using the URL below.

https://github.com/chinyati/Hyperledger-Fabric-ARM64-images/releases/tag/v2.1.0

After setting up the fabric samples directory, download the zipped binaries folder from GitHub
(Chinyati, 2020a), and paste it in this directory. These binaries are specifically for ARM64 and
were built with the ARM64 docker images as shown in Appendix B.

Docker Swarm
After setting up the Kali Linux VM and the Raspberry Pi device with the HLF docker images
the next stage is connecting them together. This connection will allow the Kali VM to be a
docker manager and the Raspberry pi device to be a participating node, this can be achieved
through use of docker swarm.

Kali VM is operated on Oracle’s Virtual box, and from this platform there is need for network
settings to allow communication with outside hosts. By default, virtual machines operate using
NAT however for use with docker swarm there is need to setup Bridged network of the
available networks. The Raspberry pi 4 device is connected to the laptop hardware through
use of an ethernet cable.
 P a g e | 81

On the Kali VM which will be the leader manager node executed this command:
$ docker swarm init –advertise-addr 192.168.56.108

Whilst on that Kali machine execute this command to get the join token to add another
manager:
$ docker swarm join-token manager

The above command outputs a swarm join command which should be executed on the
Raspberry Pi device to join it into docker swarm as another manager. The executed command
will look as follows:
$ docker swarm join --token SWMTKN-1-23geszfw581oamuz5bhtbasfqx4gzbf256cmiwvd5m3c74nmsf-
8fcymnqlicthfjq628ll2c2i0 192.168.56.108:2377 –advertise-addr 192.168.56.106

From execution of above command, the Raspberry pi device will output that this node is now
a manager.
On Kali VM which is the leader created an overlay network which will be used by the network
components and the docker containers.
$ docker network create --attachable –driver overlay IoT-network

Setup Project Files

Project files are available on (Chinyati, 2020a), download a zip folder of this project and paste
it in the fabric samples directory. From within the project directory open command line and run
the required scripts.
1. Bring up the two host by running host specific scripts
$./HostnUp.sh
2. Bring up the channel, run on Kali VM (Host 1)
$./createChannel
3. To execute the Chaincode copy the existing accessChaincode.tar.gz file onto the cli
container.
docker cp accessChaincode.tar.gz cli:/opt/gopath/src/github.com/hyperledger/fabric/peer
4. Install, approve, and commit chaincode by running the deployChaincode.sh script.
5. With chaincode approved query the chaincode as shown in deployChaincode.sh script
and access control functionality will execute.
 P a g e | 82

APPENDIX B: BUILDING HYPERLEDGER V2.1 DOCKER

IMAGES AND BINARIES FOR RASPBERRY PI 4 FOR
ARM64/AARCH64

At development of these images "Raspbian OS 64 bit operating system" for Raspberry Pi

devices has just been released. Raspbian OS is a Debian distribution (debian:buster) and
this is the base operating system used in this exercise. Hyperledger fabric (HLF) does not
have any support for ARM64 images, however, the images can be created for the
architecture only for 64 bit OS. There are other repositories and images with lower versions
of HLF which did not work on my devices due to build issues and missing components
hence need to create these.

Prerequisites
Hyperledger fabric requires several dependencies for the Raspberry Pi device with kernel
5.4.51-v8+ ARM64 architecture, these can be installed using this script HLF-Prerequisites.sh
(Chinyati, 2020a).

To install the dependencies, download the HLF-Prerequisites.sh from GitHub repository and
execute it. Verify that all dependencies installed correctly by checking the final output of
script execution.

Go Workspace
The Hyperledger Fabric (HLF) images need to be built within a Go workspace which should
be created after installing dependencies.
To manually create workspace, do the following:

$ mkdir -p $HOME/pi/go
$ export GOPATH=$HOME/pi/go

Check whether path has been added by executing $ echo $PATH. If the GOPATH has not
been added open the $ ~/.profile or $ ~/.bashrc and add the GOPATH, then execute $
source ~/.bashrc to save the paths.

Verify Golang environment setup by checking $ go env and see if GOPATH and GOROOT
have been setup.
 P a g e | 83

Downloading Source Code repositories

From the command line navigate to the newly created Go workspace and make new
directories which will hold the fabric files.

$ mkdir -p $HOME/pi/go/src/github.com/hyperledger
$ cd $HOME/pi/go/src/github.com/hyperledger

.
├── bin
├── pkg
└── src
└── github.com/hyperledger

The src directory will hold the HLF source code for fabric, fabric-baseimage and fabric-ca.
These source code directories will be cloned using $ git clone into the created child directory
/github.com/hyperledger.

Hyperledger fabric has three GIT repositories that contain the source code needed to create
the ARM64 images.

1. Clone the fabric-baseimage repository by executing:

$ git clone https://github.com/hyperledger/fabric-baseimage.git

2. Clone the fabric repository by executing:

$ git clone https://github.com/hyperledger/fabric.git

3. Clone the fabric ca repository by executing:

$ git clone https://github.com/hyperledger/fabric-ca.git

Editing Baseimage files

The Fabric baseimage repository contains source code for the base docker images required
by the fabric repository. From the fabric-baseimage directory navigate to this path:
$ cd $HOME/pi/go/src/github.com/hyperledger/fabric-baseimage

Check the available tagged branches for the fabric-baseimage codebase by executing:
$ git tag
 P a g e | 84

The required version for fabric baseimage for this project is v0.4.20 hence checked out from
that branch by executing:
$ git checkout v0.4.20

Still in the fabric-baseimage codebase there are files that should be adjusted for successful
build.
1. Edit the file /config/baseimage/Dockerfile by commenting out
FROM adoptopenjdk:8u222-b10-jdk-openj9-0.15.1
and inserting this line:
FROM adoptopenjdk/openjdk8:aarch64-ubuntu-jdk8u222-b10

2. Edit the file config/baseos/Dockerfile by commenting out

FROM debian:buster-20190910-slim
and inserting this line:
FROM arm64v8/debian:buster

3. Edit the file /images/couchdb/Dockerfile by commenting out

FROM debian:stretch-20190910-slim
and inserting this line:
FROM arm64v8/debian:buster

Whilst in the same file replace the following line:

libicu57 \
with the following line:
libicu63 \

Finally, in the same file delete this line “libmozsf180 \” as it causes errors within
debain:buster due to the package not being available:

4. Edit the two docker files in /images/zookeeper/Dockerfile and

/images/kafka/Dockerfile by commenting out
FROM debian:buster-20190910-slim as download
and insert this line:
FROM arm64v8/debian:buster as download
still in the same file comment this line
FROM adoptopenjdk:8u222-b10-jdk-openj9-0.15.1
 P a g e | 85

and insert this line:

FROM adoptopenjdk/openjdk8:aarch64-ubuntu-jdk8u222-b10

5. Lastly edit the file /scripts/common/setup.sh and replace two instances of the
following line:
ARCH=`uname -m | sed 's|i686|386|' | sed 's|x86_64|amd64|'`
with this line:
ARCH=`uname -m | sed 's|i686|386|' | sed 's|x86_64|amd64|' | sed 's|aarch64|arm64|'`

Still in the same file, replace all instances of golang-1.6 with golang-1.11, this
instance of golang is used to build the dependencies needed by the build process
and will be removed after.

Building baseimage docker files

After setting up the Prerequisites and editing the files in the baseimage source code, go
ahead and make the images. First check if there are any available docker images and if any
remove them.
$ docker image rm $(docker images)

1. The following instructions should be done whilst in /fabric-baseimage directory within

GOPATH. To build docker images for the baseimage and baseos execute:
$ make docker

This build process takes 2 hours or more to complete. After execution of the
command run $docker images to list the successfully built images. If successful, the
list will show the hyperledger/fabric-baseimage and hyperledger/fabric-baseos
images.

2. To build docker image for couchdb execute:

$ make couchdb

3. To build docker image for kafka execute:

$ make kafka

4. To build docker image for zookeeper execute:

$ make zookeeper
 P a g e | 86

At this point execute $ docker images to see created images. If successful a list of
created docker images will show a more comprehensive list including couchdb, kafka
and zookeeper images.

Building Fabric core images

Navigate to /fabric directory and here execute this command to switch to branch v2.1.0.
$ git checkout v2.1.0

Within this directory execute this command:

$ make docker

If successful this process will create the peer, orderer, tools, ccenv images. These individual
components can also be built separately e.g. make peer peer-docker or make ccenv.
Execute docker images to list all created image.

Building certificate authority image

Still within the GOPATH workspace navigate to the created fabric-ca directory which has the
source code cloned from Hyperledger’s repository. Within this directory switch to the branch
v1.4.7 which is the version of fabric-ca which is being used in this research.
$ git checkout v1.4.7

Open the Makefile in fabric-ca and replace every instance of amd64 to arm64 for Linux
entries.
After changing the architecture entries now execute this command:
$ make docker

After this all required docker images for the Raspberry Pi 4 would have been built. To view
these images, execute docker images. These images can be retagged as per specification
and pushed to a storage repository like docker hub for ease of access and any future
updates. These built images can be accessed from https://hub.docker.com/u/chinyati.

Building binary executables

Binary executables which include peer, orderer, cryptogen and more need to be built for the
ARM64 architecture as well. These can be built from the source code in /fabric folder.
$ make native
 P a g e | 87

These built executables will be places in the bin folder within /bin and must be moved to the
/bin folder for the Hyperledger fabric samples or project.

Errors encountered
For errors that could come up when deploying test-network or your channels look for
core.yaml file in config and edit Memory value to:
Memory: 16777216

Install gcc to avoid runtime errors

sudo apt install -y gcc
 P a g e | 88

Appendix C: Setup Operations Service and Prometheus for

metric benchmarking

To configure Prometheus within Hyperledger Fabric first need to setup the Operations
Service. In these instructions detail how to setup both the operations service and
Prometheus in one set of instructions. Assumptions are taken that the project files available
on the GitHub repository are being used. Now navigate to the root folder of the fabric-
samples folder.
$ nano config/core.yaml

This open the core file used for our Hyperledger fabric project. Under the operations section
ensure this is the value for host and port of operations server:
ListenAddress: 127.0.0.1:9443
Under the metric sections, put prometheus as the provider.
provider: prometheus
$ nano config/orderer.yaml

This file is the type and configuration of orderer. Under the general section update these
values:
ListenAddress: 127.0.0.1:8443
ListenPort: 7050

After updating the core and orderer files, now add these commands for peers and orderers
in Host1.yaml and Host2.yaml files.

Peer environment variables Orderer environment variables

CORE_OPERATIONS_LISTENADDRESS ORDERER_METRICS_PROVIDER
CORE_METRICS_PROVIDER ORDERER_METRICS_PROVIDER

Bring up the Hosts using the scripts in the IoT-Project folder.

Execute the metricsPrometheus.sh script to bring up the prometheus container and if not
already downloaded to also download the prometheus image.
After successful execution, the Prometheus server is access through http://localhost:9090
 P a g e | 89

APPENDIX D: ACCESS CONTROL CHAINCODE

Access Control chaincode

1. package main
2.
3. import (
4. "fmt"
5.
6. "github.com/hyperledger/fabric-chaincode-go/pkg/cid"
7. "github.com/hyperledger/fabric-chaincode-go/shim"
8. "github.com/hyperledger/fabric-protos-go/peer"
9. )
10.
11. // SimpleAsset implements a simple chaincode to manage an asset
12. type SimpleAsset struct {
13. }
14.
15. // Init is called during chaincode instantiation to initialize any
16. // data. Note that chaincode upgrade also calls this function to reset
17. // or to migrate data.
18. func (t *SimpleAsset) Init(stub shim.ChaincodeStubInterface) peer.Response {
19. // Get the args from the transaction proposal
20. args := stub.GetStringArgs()
21. if len(args) != 2 {
22. return shim.Error("Incorrect arguments. Expecting a key and a value")
23. }
24.
25. // Set up any variables or assets here by calling stub.PutState()
26.
27. // We store the key and the value on the ledger
28. err := stub.PutState(args[0], []byte(args[1]))
29. if err != nil {
30. return shim.Error(fmt.Sprintf("Failed to create asset: %s", args[0]))
31. }
32. return shim.Success(nil)
33. }
34.
35. // Invoke is called per transaction on the chaincode. Each transaction is
36. // either a 'get' or a 'set' on the asset created by Init function. The Set
37. // method may create a new asset by specifying a new key-value pair.
38. func (t *SimpleAsset) Invoke(stub shim.ChaincodeStubInterface) peer.Response {
39. // Extract the function and args from the transaction proposal
40. fn, args := stub.GetFunctionAndParameters()
41.
42. var result string
43. var err error
44. if fn == "set" {
45. result, err = set(stub, args)
46. } else { // assume 'get' even if fn is nil
47. result, err = get(stub, args)
48. }
49. if err != nil {
50. return shim.Error(err.Error())
51. }
52.
53. // Return the result as success payload
54. return shim.Success([]byte(result))
55. }
56.
57. // Set stores the asset (both key and value) on the ledger. If the key exists,
58. // it will override the value with the new one
 P a g e | 90

59. func set(stub shim.ChaincodeStubInterface, args []string) (string, error) {

60. // only Admin can set value
61. x509, _ := cid.GetX509Certificate(stub)
62.
63. if x509.Subject.CommonName != "Admin@org1.example.com" {
64. return "", fmt.Errorf("Only Admin can set new value.")
65. }
66.
67. if len(args) != 2 {
68. return "", fmt.Errorf("Incorrect arguments. Expecting a key and a value")
69. }
70.
71. err := stub.PutState(args[0], []byte(args[1]))
72. if err != nil {
73. return "", fmt.Errorf("Failed to set asset: %s", args[0])
74. }
75. return args[1], nil
76. }
77.
78. // Get returns the value of the specified asset key
79. func get(stub shim.ChaincodeStubInterface, args []string) (string, error) {
80. if len(args) != 1 {
81. return "", fmt.Errorf("Incorrect arguments. Expecting a key")
82. }
83.
84. value, err := stub.GetState(args[0])
85. if err != nil {
86. return "", fmt.Errorf("Failed to get asset: %s with error: %s", args[0], er
r)
87. }
88. if value == nil {
89. return "", fmt.Errorf("Asset not found: %s", args[0])
90. }
91. return string(value), nil
92. }
93.
94. // main function starts up the chaincode in the container during instantiate
95. func main() {
96. if err := shim.Start(new(SimpleAsset)); err != nil {
97. fmt.Printf("Error starting SimpleAsset chaincode: %s", err)
98. }
99. }
 P a g e | 91

APPENDIX E: HOST YAML FILES TO BUILD UP DOCKER

CONTAINERS

Host yaml file for Host 1, Kali Linux VM.

1. version: '2'
2.
3. volumes:
4. orderer.example.com:
5. orderer5.example.com:
6. peer0.org1.example.com:
7.
8. networks:
9. byfn:
10. external:
11. name: IoT-network
12.
13. services:
14.
15. orderer.example.com:
16. extends:
17. file: docker-compose-base.yaml
18. service: orderer.example.com
19. container_name: orderer.example.com
20. networks:
21. - byfn
22.
23. orderer5.example.com:
24. extends:
25. file: peer-base.yaml
26. service: orderer-base
27. environment:
28. - ORDERER_GENERAL_LISTENPORT=11050
29. container_name: orderer5.example.com
30. networks:
31. - byfn
32. volumes:
33. - ../channel-
artifacts/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
34. - ../crypto-
config/ordererOrganizations/example.com/orderers/orderer5.example.com/msp:/var/hype
rledger/orderer/msp
35. - ../crypto-
config/ordererOrganizations/example.com/orderers/orderer5.example.com/tls/:/var/hyp
erledger/orderer/tls
36. - orderer5.example.com:/var/hyperledger/production/orderer
37. ports:
38. - 11050:11050
39.
40. peer0.org1.example.com:
41. container_name: peer0.org1.example.com
42. extends:
43. file: docker-compose-base.yaml
44. service: peer0.org1.example.com
45. networks:
46. - byfn
47.
48. cli:
49. container_name: cli
50. image: hyperledger/fabric-tools:latest
 P a g e | 92

51. tty: true

52. stdin_open: true
53. environment:
54. - SYS_CHANNEL=$SYS_CHANNEL
55. - GOPATH=/opt/gopath
56. - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
57. #- FABRIC_LOGGING_SPEC=DEBUG
58. - FABRIC_LOGGING_SPEC=INFO
59. - CORE_PEER_ID=cli
60. - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
61. - CORE_PEER_LOCALMSPID=Org1MSP
62. - CORE_PEER_TLS_ENABLED=true
63. - CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/
crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.c
rt
64. - CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/c
rypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/server.ke
y
65. - CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/p
eer/crypto/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/tls/ca.c
rt
66. - CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/
crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
67. working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
68. command: /bin/bash
69. volumes:
70. - /var/run/:/host/var/run/
71. - ../../chaincode/:/opt/gopath/src/github.com/chaincode
72. - ../crypto-
config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
73. - ../scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/
74. - ../channel-
artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
75. depends_on:
76. - orderer.example.com
77. - peer0.org1.example.com
78. networks:
79. - byfn

Host yaml file for Host 2, Raspberry Pi device.

1. version: '2'
2.
3. volumes:
4. orderer2.example.com:
5. peer1.org1.example.com:
6.
7. networks:
8. byfn:
9. external:
10. name: IoT-network
11.
12. services:
13.
14. orderer2.example.com:
15. extends:
16. file: peer-base.yaml
17. service: orderer-base
18. environment:
19. - ORDERER_GENERAL_LISTENPORT=8050
20. container_name: orderer2.example.com
21. networks:
 P a g e | 93

22. - byfn
23. volumes:
24. - ../channel-
artifacts/genesis.block:/var/hyperledger/orderer/orderer.genesis.block
25. - ../crypto-
config/ordererOrganizations/example.com/orderers/orderer2.example.com/msp:/var/hype
rledger/orderer/msp
26. - ../crypto-
config/ordererOrganizations/example.com/orderers/orderer2.example.com/tls/:/var/hyp
erledger/orderer/tls
27. - orderer2.example.com:/var/hyperledger/production/orderer
28. ports:
29. - 8050:8050
30.
31. peer1.org1.example.com:
32. container_name: peer1.org1.example.com
33. extends:
34. file: docker-compose-base.yaml
35. service: peer1.org1.example.com
36. networks:
37. - byfn
38.
39. cli:
40. container_name: cli
41. image: hyperledger/fabric-tools:latest
42. tty: true
43. stdin_open: true
44. environment:
45. - SYS_CHANNEL=$SYS_CHANNEL
46. - GOPATH=/opt/gopath
47. - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
48. #- FABRIC_LOGGING_SPEC=DEBUG
49. - FABRIC_LOGGING_SPEC=INFO
50. - CORE_PEER_ID=cli
51. - CORE_PEER_ADDRESS=peer1.org1.example.com:8051
52. - CORE_PEER_LOCALMSPID=Org1MSP
53. - CORE_PEER_TLS_ENABLED=true
54. - CORE_PEER_TLS_CERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/
crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/server.c
rt
55. - CORE_PEER_TLS_KEY_FILE=/opt/gopath/src/github.com/hyperledger/fabric/peer/c
rypto/peerOrganizations/org1.example.com/peers/peer.org1.example.com/tls/server.key

56. - CORE_PEER_TLS_ROOTCERT_FILE=/opt/gopath/src/github.com/hyperledger/fabric/p
eer/crypto/peerOrganizations/org1.example.com/peers/peer1.org1.example.com/tls/ca.c
rt
57. - CORE_PEER_MSPCONFIGPATH=/opt/gopath/src/github.com/hyperledger/fabric/peer/
crypto/peerOrganizations/org1.example.com/users/Admin@org1.example.com/msp
58. working_dir: /opt/gopath/src/github.com/hyperledger/fabric/peer
59. command: /bin/bash
60. volumes:
61. - /var/run/:/host/var/run/
62. - ../../chaincode/:/opt/gopath/src/github.com/chaincode
63. - ../crypto-
config:/opt/gopath/src/github.com/hyperledger/fabric/peer/crypto/
64. - ../scripts:/opt/gopath/src/github.com/hyperledger/fabric/peer/scripts/
65. - ../channel-
artifacts:/opt/gopath/src/github.com/hyperledger/fabric/peer/channel-artifacts
66. depends_on:
67. - orderer2.example.com
68. - peer1.org1.example.com
69. networks:
70. - byfn

View publication stats