An IoT Simulator in NS3 and A Key-Based Authentication Architecture For IoT Devices Using Blockchain

An IoT simulator in NS3 and a
key-based authentication
architecture for IoT devices using
blockchain
A thesis submitted in partial fulfillment of the requirements
for the degree of Master of Technology
by
Saptarshi Gan
DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING
INDIAN INSTITUTE OF TECHNOLOGY KANPUR
July 2017
ii
Abstract
Name of the student: Saptarshi Gan Roll No: 12807624

Degree for which submitted: M.Tech. Department: Computer Science and
Engineering
Thesis title: An IoT simulator in NS3 and a key-based authentication
architecture for IoT devices using blockchain
Thesis supervisor: Dr. Sandeep Shukla
Month and year of thesis submission: July 2017
The Internet of Things or IoT is a rapidly growing phenomenon. Many of the devices
around us are getting connected to the internet, becoming ”smart” in the process.
However, increased connection to the internet opens up possible attacks from mul-
tiple dimensions. One of the fundamental problems of IoT devices is that they are
bought and deployed in batches. So majority of IoT devices deployed remain with
their default username password combination for the sake of authentication. Hence
it becomes very easy to brute force into these devices and take control of them.
The Mirai attack that took down the Dyn DNS and many other important sites
used a DDOS attack [1]. The attack formed its botnet by brute forcing into IoT
devices using default username password combinations. One way to protect against
this kind of brute force authentication is to use key-based authentication for all IoT
communication. This work describes an architecture for using key-based authentica-
tion for IoT devices with the help of blockchain. This work also describes a scalable
simulator in NS3 to test IoT specific networks and communication protocols.
Acknowledgements
I would extend my sincere gratitude to Dr. Sandeep Shukla for introducing me to
this field and guiding me through every aspect of this thesis.
I would also like to sincerely thank the lab members of RM505 and RM506 for
supporting me and keeping me motivated throughout the project. I would also like
to thank Abhay Kumar and Avik Dayal for helping me write my thesis. I am
grateful to my friends for being there for me all the time in IITK. I would also like
to thank my parents and sister for supporting me throughout. I would also like to
thank Pranjul Ahuja, Vineet Purswani, Ajay Singh, Saurabh Kumar, Debleena Das,
Neha Ajmani and others in the lab for helping me brace my 5th year.
Finally, I would like to thank the entire open-source community for making such
awesome products open-source.
vi
Contents
Abstract iv
Acknowledgements vi
Contents viii
List of Figures xii
List of Tables xiv
Abbreviations xvi
1 Introduction 1
1.1 Recent IoT Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Mirai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.2 Hajime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.3 IoTWorm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 A Possible Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 IoT Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contribution of this Thesis . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related work 5
2.1 IoT Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Cooja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 IoTSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.4 NS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.5 OPNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6 NetSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.7 CORE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
viii
Contents ix
2.2 IoT blockchain architecture . . . . . . . . . . . . . . . . . . . . . . . 7

2.2.1 Blockchain for IoT for a Smart Home . . . . . . . . . . . . . . 8
2.2.2 Smart Contracts for IoT . . . . . . . . . . . . . . . . . . . . . 9
2.2.3 Virtual IoT resources on Edge Hosts with Blockchain . . . . . 9
2.2.4 IoT Electric business model . . . . . . . . . . . . . . . . . . . 9
2.3 IoT Public key encryption . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1 WolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2 AvrCryptoLib . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3 WiseLib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.4 TinyECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.5 RelicToolKit . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Overall Architecture of Proposed Model 13

3.1 Blockchains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.2 Principle of Blockchain . . . . . . . . . . . . . . . . . . . . . . 14
3.1.3 Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.4 Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.4.1 Structure . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.5 Consensus Protocol . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.6 Challenges for using existing bitcoin solution in IoT . . . . . . 17
3.2 Proposed Architecture for using PKI in IoT . . . . . . . . . . . . . . 18
3.2.1 Private Permissioned Blockchain and Validators . . . . . . . . 18
3.2.1.1 Blockchain Structure and Protocol . . . . . . . . . . 19
3.2.1.2 Validator Addition Protocol . . . . . . . . . . . . . . 20
3.2.1.3 Node Addition Protocol . . . . . . . . . . . . . . . . 22
3.2.1.4 Validator Update Protocol . . . . . . . . . . . . . . . 22
3.2.1.5 Node Update Protocol . . . . . . . . . . . . . . . . . 23
3.2.1.6 Node Communication Protocol . . . . . . . . . . . . 24
3.2.1.7 Overall Threats . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Evolution of Internet 4.0 . . . . . . . . . . . . . . . . . . . . . 26
3.2.2.1 Paradox of Trust . . . . . . . . . . . . . . . . . . . . 26
3.2.2.2 Personal Area Network - PAN . . . . . . . . . . . . . 26
3.2.2.3 Global Area Network - GAN . . . . . . . . . . . . . 27
3.2.2.4 Block Addition Protocol . . . . . . . . . . . . . . . . 29
3.2.2.5 Node Addition Protocol . . . . . . . . . . . . . . . . 29
3.2.2.6 Gateway Addition Protocol . . . . . . . . . . . . . . 32
3.2.2.7 Cluster Merge Protocol . . . . . . . . . . . . . . . . 32
3.2.2.8 Node/Gateway Update Protocol . . . . . . . . . . . 34
3.2.2.9 Node Removal Protocol . . . . . . . . . . . . . . . . 34
3.2.2.10 Validator Removal Protocol . . . . . . . . . . . . . . 34
Contents x
3.2.2.12 Threat Models . . . . . . . . . . . . . . . . . . . . . 36

3.2.3 Final Model: PUF based Architecture . . . . . . . . . . . . . 36
3.2.3.1 Device Requirements . . . . . . . . . . . . . . . . . . 37
3.2.3.2 Global Unique Device Identifier . . . . . . . . . . . . 38
3.2.3.3 Design of the Layers . . . . . . . . . . . . . . . . . . 38
3.2.3.4 Block Structure . . . . . . . . . . . . . . . . . . . . . 39
3.2.3.5 Device Keys . . . . . . . . . . . . . . . . . . . . . . . 40
3.2.3.6 Node/Validator Addition Protocol . . . . . . . . . . 40
3.2.3.7 Node Update Protocol . . . . . . . . . . . . . . . . . 41
3.2.3.8 Node Deletion Protocol . . . . . . . . . . . . . . . . 42
3.2.3.9 Node Discovery . . . . . . . . . . . . . . . . . . . . . 42
3.2.3.11 Privacy and Anonymity . . . . . . . . . . . . . . . . 43
3.2.3.12 Some Threat Models . . . . . . . . . . . . . . . . . . 43
4 IoT Simulator in NS3 45

4.1 IoT Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 NS3 Simulator Classes . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5 Simulation Results 51
5.1 Private Permissioned Blockchain Model . . . . . . . . . . . . . . . . 51
5.1.1 Simple Experiment Model . . . . . . . . . . . . . . . . . . . . 51
5.1.1.1 Result . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Internet 4.0 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.1.1 Result . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3 PUF based Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3.1.1 Result . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.2 ID Exhaustion . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6 Conclusion 61
6.1 Attack Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.1 Mirai . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.1.2 Phillips bulb attack . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Other Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2.1 SmartHome Architecture . . . . . . . . . . . . . . . . . . . . . 62
6.2.2 Samsung Pay . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
6.3 Comparison of the Architectures . . . . . . . . . . . . . . . . . . . . . 65
6.4 Contributions of this thesis . . . . . . . . . . . . . . . . . . . . . . . . 65
7 Future Work 68
Contents xi
7.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.2 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
A Public Key Cryptography 71
B Simulator Class Codes and Explanation 75

B.1 IoT-Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B.1.1 Generator Header File . . . . . . . . . . . . . . . . . . . . . . 75
B.1.2 Validator Header File . . . . . . . . . . . . . . . . . . . . . . . 86
B.1.3 Main Window Header . . . . . . . . . . . . . . . . . . . . . . 89
B.2 NS3-Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B.2.1 Blockchain Header . . . . . . . . . . . . . . . . . . . . . . . . 93
B.2.2 Blockchain Node Header . . . . . . . . . . . . . . . . . . . . . 99
B.2.3 Blockchain Validator Header . . . . . . . . . . . . . . . . . . . 105
B.2.4 IoT Sensor Node Header . . . . . . . . . . . . . . . . . . . . . 109
B.2.5 IoT Layer Topology Helper Header . . . . . . . . . . . . . . . 114
B.2.6 IoT Flat Topology Helper Header . . . . . . . . . . . . . . . . 118
Bibliography 123
List of Figures
2.1 Discussed Blockchain based architecture for IoT [2] . . . . . . . . . . 8
3.1 Merkle Tree Example [3] . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 Central Chain Validator Network . . . . . . . . . . . . . . . . . . . . 19
3.3 Structure of Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Entire Network Structure . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 PAN Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Single Manufacturer cluster . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 Evolution of GAN network 1 . . . . . . . . . . . . . . . . . . . . . . . 30
3.8 Evolution of GAN network 2 . . . . . . . . . . . . . . . . . . . . . . . 31
3.9 Blockchain Merge Protocol . . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 PUF Computation in Trusted Zone . . . . . . . . . . . . . . . . . . . 37
3.11 Secure Memory Computation in Trusted Zone . . . . . . . . . . . . . 38
3.12 Entire Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.1 NS3 Generator example [4] . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2 IoT generator start page . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3 Sample IoT topology using IoT generator . . . . . . . . . . . . . . . . 48
4.4 Generate IoT simulation code . . . . . . . . . . . . . . . . . . . . . . 48
4.5 Simulation code generated . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1 Simple Experiment Network . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 Typical Smart-Home Architecture . . . . . . . . . . . . . . . . . . . . 62

6.2 Samsung Certificate Architecture . . . . . . . . . . . . . . . . . . . . 64
6.3 Samsung Pay payment flow . . . . . . . . . . . . . . . . . . . . . . . 64
A.1 Diffie-Hellman Key Exchange [5] . . . . . . . . . . . . . . . . . . . . . 72
xii
List of Tables
6.1 Comparison of current and proposed architecture . . . . . . . . . . . 63

6.2 Comparison of different architectures . . . . . . . . . . . . . . . . . . 65
xiv
Abbreviations
IoT Internet of Things

NS3 Network Simulator 3
DNS Domain Name System
IP Internet Protocol
OS Operating Systems
PAN Personal Area Network
GAN Global Area Network
DDoS Distributed Denial of Service
PKI Public Key Infrastructure
AES Advanced Encryption Standard
ZLL Zigbee Light Link
CCM Counter with CBC MAC
RSA Rivest Shamir Adleman
ECC Elliptic Curve Cryptography
CBC Cipher Block Chaining
MAC Message Authentication Code
CCA Central Certifying Authority
PUF Physical Unclonable Function
API Application Programming Interface
CnC Command And Control
MITM Man In The Middle
xvi
Dedicated to my parents, sister and F.R.I.E.N.D.S.
xviii
Chapter 1
Introduction
The Internet of Things (IoT) is defined as the network formed when physical de-
vices are connected to the internet or are connected to each other in some local
network [6]. Connecting the devices to each other allows them to share data among
themselves and take intelligent decisions based on the data. Any physical device
which is connected to some sort of network can be called an IoT device. Popular
examples of IoT devices are thermostats, refrigerators, smart-televisions, washing
machines, surveillance cameras, health monitoring devices, home automation sys-
tems etc. Even though earlier such devices were not networked, increasingly they
come with network interfaces.
The recent years have seen an exponential growth of IoT devices. From smart-
watches to smart-homes, companies and people are increasingly creating and buying
network enabled devices. According to Gartner, there will be 21 million IoT devices
by 2020 all over the world [7]. Whether getting regular health statistics or remotely
controlling the thermostat at home, IoT devices are definitely making lives of people
easier and better.
As more devices are connected to the internet, these devices are at increasingly
risk of being attacked. Typically, IoT devices are small sensors which send data or
actuators that perform some action based on feedback or command. So these devices
need some central device to send the data to or send commands to actuators. The
controlling devices need to authenticate themselves to these IoT devices or else
anyone can sense critical data or send commands to actuators and do damage to
1
Chapter 1. Introduction 2
infrastructure and even endanger lives of people. For authenticating to these IoT
devices, these controllers typically use username and password combination. Many
IoT devices are deployed by non-technical people who do not care to change the
factory default username and password combination for the devices. Each device
manufacturer sets some specific username-password when manufacturing the devices.
There have been a number of attacks in the recent years, which exploited this human
vulnerability of using default username-password [1].
1.1 Recent IoT Attacks
There have been a surge in the number of attacks on IoT devices in the recent years.
Most of these attacks aim to take control of IoT devices so that they can form their
own botnet. Botnets are a group of computers acting together to complete some
particular task. There are several botnets dedicated to launch only DDoS attacks
on specific services. A Distributed Denial of Service (DDoS) attack is an attempt
to make an online service unavailable by overwhelming it with traffic from multiple
sources [8]. So IoT devices that are not protected with proper username-password
combination can be easily compromised and formed into a botnet to launch attacks
on other services. Some of the recent malwares which exploited this IoT vulnerability
are described below.
1.1.1 Mirai
On September 20, 2016 there was a huge DDoS attack on KrebsOnSecurity which
came from multiple locations around the world. The malware responsible for this
attack was the Mirai malware whose source code was made open source by someone
by the pseudonym Anna Senpai [1]. On October 21, 2016, this same malware was
used to launch a large scale attack on the Dyn Domain Name Servers (DNS) which
resulted in large number of sites facing downtime. The working principle of Mirai
malware was as follows:
I. CnC Server : There’s a central Command and Control (CnC) server which controls
all the devices that were infected by Mirai and brought under its control. The
malware spreads like a worm and it mainly targets IoT devices. Once a device is
compromised it waits for commands from CnC server to launch its attack.
II. Loader : The loader server is responsible for delivering the malware to the device
once it finds some device with default username-password.
III. IoT devices: The main working principle of the malware is that it has a set of
default username-passwords which it tries on every possible IP. As many IoT devices
do not change their default username-password, they become very easy prey to the
malware and come easily under the control of the CnC server.
1.1.2 Hajime
?? Hajime is a derivative of Mirai which followed the same working principle as Mirai
with the exception that its CnC server was not a single server but a distributed set
of peer to peer servers which made it harder to take it down. It is still in active
development by hackers.
1.1.3 IoTWorm
Some researchers from Israel found out another novel attack that was capable of
starting a chain reaction of rendering smart lights unusable and can take down an
entire city’s smart light system [9]. These lights used an AES-CCM encryption
key to authenticate the firmware updates. So all the lights used the same AES-
CCM key. Through side channel analysis, the AES key was obtained [9]. Using a
vulnerability in the touchlink part of the ZLL protocol, the lights were removed from
their original controllers and then malicious firmware updates were sent by signing
it with the AES key. As the lights used the same AES key, so it was very easy to
exponentially escalate this attack and compromise all smart lights in a locality.
1.2 A Possible Solution
The solution to this problem is to use authenticated public-key infrastructure for all
communications among IoT devices and the authenticity of the public-keys can be
maintained using blockchains. Using a public key based authentication scheme with
a public key infrastructure (PKI) would have stopped both the Mirai and Hajime
attacks as guessing the private keys of so many IoT devices would be much harder.
Also the IoTWorm would not have spreaded exponentially as different IoT devices
would have individual private keys and not a single key across all devices. Each light
would have to be hacked manually to get the key and send the malicious updates.
1.3 IoT Simulator
Although the protocols used by most IoT devices are implemented in NS3, but there
is no proper scalable simulator in NS3 to test out different IoT architectures and
network issues. Hence we built a simulator in NS3 to test out IoT architectures and
communication schemes including the proposed PKI.
1.4 Contribution of this Thesis
The major contributions of this thesis are:
• We propose an architecture for using public-key infrastructure for communi-

cation among IoT devices enabled with blockchains to keep the public keys
secure and hard to manipulate.
• We develop an IoT simulator in NS3 to test our architecture for different threat
models and possible attacks.
• We demonstrate the utility of our simulator by simulating different attack

models on our architecture in our simulator.
Chapter 2
Related work
This chapter details the past works done in the area of simulators for IoT, Pub-
lic key encryption architecture using blockchains for IoT and optimized public key
algorithms designed for IoT devices
2.1 IoT Simulators
Simulators are very important component for any prototype development, architec-
ture exploration and testing of threat models. IoT projects usually have very high
density of sensor and actuator nodes. Hence it is not feasible to physically deploy an
entire network and test new ideas. A simulator is required which can both simulate
IoT functionality and the network properties of the network. Hacks can also be
simulated to discover threat models and to test out mitigation techniques.
2.1.1 Cooja
Cooja is an emulator built over the Contiki OS. Contiki OS is a tiny OS which
is optimized to be used with very little memory footprint and minimal processing
capabilities [10]. It is specially designed to be used for Internet of things. Cooja em-
ulates different functional properties of IoT devices such as emulating temperature
5
Chapter 2. Related work 6
sensing, pressure sensing etc. It can also emulate nearby peer to peer communi-
cation among the nodes and nearby broadcast of messages based on distance. It
emulates all the functionalities by building over the abstraction layer of contiki OS.
Since it emulates over a real OS it can do time based profiling of different functions.
However, as it is built over contiki OS, all the nodes in the network are simulated to
be running the same tiny OS. Therefore testing architectures which require commu-
nication between nodes running a heterogenity of operating systems is not possible.
In any blockchain architecture the validator or the miner nodes (the nodes to mine
the blocks and store the blockchain) can not be nodes with tiny OS as they need to
have sufficient memory and processing power.
2.1.2 IoTSim
IoTSim is another simulator for analyzing IoT applications [11]. It uses the cloudsim
simulation toolkit [12], which allows the simulation of cloud computing environ-
ments. It also simulates the map-reduce framework for the purpose of handling the
big data from the IoT applications on the cloud. However it only simulates the
end-user level IoT applications and its data processing in the cloud but it doesn’t
simulate the IoT nodes individually and the communications between different nodes
in the network.
2.1.3 OMNeT++
OMNeT++ is discrete event-based simulator which is written in C++ and is used for
simulation of communication networks, distributed systems and other multiprocessor
applications [13]. It is a generic simulator which allows the development of various
simulation models and frameworks on top of it. It was developed to fill the gap
between community supported, open-source, research oriented simulators such as
NS3 and expensive commercial simulators such as OPNET.
2.1.4 NS3
NS3 is the Network Simulator 3 which is the open-source, research-oriented, community-

supported simulator for testing networking protocols [14]. It has been developed over
the years and and it supports almost all communication protocols such as MQTT,
Zigbee, bluetooth etc. It also supports different modules which allows parallel sim-
ulation, distributed simulation etc. It can be extended easily to support and test
different applications.
2.1.5 OPNET
OPNET is the commercial network simulator which is maintained by Riverbed tech-

nologies and supports only windows platform [15].
2.1.6 NetSim
NetSim is another commercial simulator and emulator which is used to test IoT
networks and applications [16].
2.1.7 CORE
CORE is the Common Open Research Emulator which is used to emulate PCs and
networks on one or multiple PCs [17]. It uses FreeBSD’s kernel network stack for the
emulation. However it does not support many of the protocols and network stacks
used in IoT communication.
2.2 IoT blockchain architecture
Both blockchains and IoT are emerging and growing technologies and hence there
have been lots of efforts to put IoT over blockchains. Some of the notable works are
as follows
2.2.1 Blockchain for IoT for a Smart Home
This work proposes a method to adopt blockchain in the context of IoT and discusses
the framework in the context of a smart home [2]. In their work they propose the
instantiation of blockchain without the need for proof of work and any coins. Their
proposed framework consists of a hierarchical structure which mainly consists of
3 layers: smart home,cloud storage, and overlay. All the IoT devices are in the
smart home layer, which are managed by a miner. The overlay network consists
of the smart home layer along with Service Providers (SP), cloud storages, and
smartphones as shown in Figure 2.1. The overlay network is grouped into clusters to
minimize latency and each cluster elects its cluster head (CH). The miners maintain
all the transactions in an immutable ledger which is the private blockchain for each
smart home network. There are different kinds of transactions like store, access,
monitor, genesis and remove which handles different operations and data sharing in
the network.
Figure 2.1: Discussed Blockchain based architecture for IoT [2]
This work mostly focuses on data store and access use cases, by IoT devices. The
transactions in the blockchain are data storage and access transactions. The public
keys are fixed with the cluster heads and are immutable. Also the model gives weak
security guarantees for a distributed system. In their security analysis they analyze
their model for DDOS attack and linking attack. They also measure the overhead
for using their model over traditional message exchange.
2.2.2 Smart Contracts for IoT
The authors in this work describe the potential uses of blockchain with IoT devices
[18]. They describe scenarios for decentralized working of IoT devices with the
help of blockchains. Instead of a centralized deployment of firmware updates they
describe a smart contract based peer-to-peer mechanism for update of firmware. It
also uses the blockchains’ use of cryptocurrency to add a convenient business and
billing layer to the already existing network of devices. It describes the use of smart-
contracts and the Ethereum blockchain in the working of renting a smart lock for a
house [19]. It also describes the use of IoT and blockchain in the efficient use and
sharing of energy in the energy sector. It also describes a scenario for the use of IoT
and blockchain in supply chain management.
2.2.3 Virtual IoT resources on Edge Hosts with Blockchain
This work describes a method for hosting and distributing virtual resources and ap-
plications on IoT devices with the help of blockchains [20]. In this all the end device
applications and virtual resources are kept in a permissioned blockchain (multichain)
which are then deployed into the end devices. Code is pushed and updated on the
devices by using RESTful apis from blockchain.
2.2.4 IoT Electric business model
This work discusses a business model for IoT devices [21]. It proposes an architecture
to facilitate e-business with IoT devices with the help of blockchains and smart
contracts. It introduces the concept of IoTcoin, a parallel of bitcoin, for the purpose
of enabling e-business among IoT devices using smart-contracts.
2.3 IoT Public key encryption
As IoT devices have both memory and processing power constraint so normal public
key encryption algorithms will incur huge latency and is not a feasible solution. So
there have been lots of research for implementing optimized public key encryption
algorithms for IoT. All public key encryption discussed to be used in later chapters
are one form of the optimized Elliptic Curve Cryptography (ECC) encryption. There
are different libraries which implement different optimized cryptographic protocols
for IoT devices [22]. Some of them are as follows:
2.3.1 WolfSSL
This library is written in ANSI C and has very low memory footprint. It allows
generation of keys and certificates and supports lots of cryptography algorithms. Its
runtime memory usage is very low and it has very simple api to use.
2.3.2 AvrCryptoLib
This library has the implementation of algorithms optimized for AVR 8-bit micro-
controllers. Besides supporting a wide range of algorithms it also supports MAC
functions and Pseudo Random Number Generators. It optimizes the execution time
by performing modular exponentiation in 8-bit assembly language. It also allows
direct access to keys by storing them in flash memory.
2.3.3 WiseLib
It is written in C++ and is mainly written for connected devices (devices connected
to some network). It can be easily used in various platforms like Contiki, iSense,
Shawn etc. It implements elliptic curve over prime fields only and in order to make
platform independent loses over the assembly level performance optimization.
2.3.4 TinyECC
It is an Elliptic Curve Cryptography library which can be used to perform ECC-

based public key operations. It is mainly implemented for devices running TinyOS
however parts of its code can be altered to be used with other OSes as well.
2.3.5 RelicToolKit
It is a flexible and efficient toolkit which can be used for constructing custom crypto-
graphic toolkit. It also supports ECC-based algorithms. It supports customization
for inclusion of required components in desired platform and selecting desired math-
ematical optimization for optimum performance in the desired platform.
Chapter 3
Overall Architecture of Proposed

Model
We describe three different architectures which have different properties and func-
tionalities. Also the threats and possible attack vectors are different for each of
them. However the major component driving the architectures is the blockchain
technology which is the backbone for all the digital currencies like bitcoin, dogecoin,
namecoin etc [23].
3.1 Blockchains
Blockchain is a distributed database that maintains a continuously growing list of

records that is organized into entities called blocks. Blockchain, as the name sug-
gests, is a chain of these blocks with each block connected to its previous one by a
hash of the previous block.
3.1.1 History
The concept of blockchains dates back to the 90s which was just a variant of dis-
tributed database but the concept got traction in 2008 after the global financial
meltdown, when an anonymous person pseudo-named Satoshi Nakamoto published
13
Chapter 3. Overall Architecture of Proposed Model 14
a white paper for a type of digital currency from which bitcoin was born [23]. Orig-
inally in the paper, Nakamoto used the words block and chain separately but even-
tually on wider use the term became a single word blockchain [24]. The sole purpose
of blockchains is to facilitate secure online transactions which are publicly verifiable.
3.1.2 Principle of Blockchain
The main principle of a blockchain is that it maintains a distributed and decentral-

ized ledger of records across multiple computers so that a record can not be altered
without the alteration of all subsequent blocks or collusion of all nodes of the net-
work [25]. All the nodes maintaining the blockchain needs to reach a consensus on
the state of the blockchain. Blockchains can be classified into two types based on
the nature of the participants in the consensus protocol.
1. Public Blockchains : Public blockchains are open and permissionless, where

anybody can join the network and participate in the consensus protocol without
requiring the permission or trust of other nodes in the network. The consensus
protocols used in public blockchains are more complicated than those used in private
blockchains [24]. Some of the popular consensus protocols are Proof of Work (POW),
Proof of Stake (POS), Proof of Activity (POA), Proof of Burn (POB) etc [26].
2. Private Blockchains : Private blockchains are permissioned blockchains, where

each node knows and trusts every other node and any new node to be added to the
network needs to be allowed by majority nodes in the network. As every node is
added to the network, after validation the consensus protocols in the network are
relatively simpler [24].
3.1.3 Advantages
The prime advantages that a blockchain provides are as follows:
I. Public : The greatest advantage of blockchain is that it is public. Everyone can

see and verify its contents and also monitor the changes and updates made to it.
II. Decentralized : In blockchains there is no single authority to approve or dis-

approve new transactions. The nodes in the network must reach a consensus for
any transaction to be approved. Hence the trust of the network remains distributed
among the participating nodes.
III. Secure : The way the blocks are arranged in a blockchain makes it secure as it
becomes very hard computationally to modify multiple blocks in the blockchain.
3.1.4 Block
The principle component of a blockchain is a block. Each block contains records,

which can be transaction data or any other data to be stored in blockchains. The
transactions are normally stored in the form of a merkle tree [3]. Merkle tree is a
data structure which is such that if parent blocks match then all its child blocks are
guaranteed to match. Figure 3.1 shows a merkle tree example. As shown in the figure
3.1, the parent blocks contain the hash of the content of its child blocks and each
block is addressed by its hash. This data structure makes the network overhead for
checking of block contents easier. The parent node maintains the complete hash of
its children and only in the event of a mismatch the child nodes are further verified.
Figure 3.1: Merkle Tree Example [3]

The hash of previous parent block is included in the child block so that each block
is made cryptographically secure and it remains hard to modify the blocks in the
blockchain making them immutable.
3.1.4.1 Structure
The structure of a block varies and depends hugely on the use-case of the blockchain.
The generic structure is that a block starts with the hash of the parent block and
then there are contents. Each block in the chain is identified by its hash. Also
maintaining the hash of the parent block at the beginning of the block makes the
block immutable as in order to change any content of the blockchain one has to
change the entire chain as the hash of a block will change if any of its content
changes.
3.1.5 Consensus Protocol
The crux and the basic trust mechanism of any distributed system and hence the
blockchain also is its consensus protocol. Every participant of any distributed sys-
tem needs to agree on the same state of the whole system maintained by all the
peers. The process through which the participants in a distributed system comes
to an agreement for a common state of the system is called a consensus protocol.
For private blockchain, the protocol is simple as every participant is trusted and
hence they can come to a consensus through some gossip protocol or other simple
peer-to-peer messaging. However public blockchain needs some different consensus
protocols as anyone can join the network and as the nodes can be anonymous about
their identity, by joining with multiple anonymous identity anyone can influence the
network in favor of its own interests. A completely open network becomes prone to
the Sybil attack without a robust consensus protocol [27]. For public blockchain, the
consensus protocol decides which participant will add the new block to the chain.
Some of the popular consensus protocols are as follows:
• Proof of Work: Proof of Work asks for the computation power from the
participants. So the participating miner has to solve a computational problem
which is hard to solve but very easy to verify. This way the miner has to spend
some computational power in order to add a block.
• Proof of Stake: By this protocol a participant gets to add that much amount
of blocks to the network as much stake he holds in the network. For example
in a money network, a participant adds the percentage of transactions to the
network as much percentage of total value of the network he owns.
• Proof of Activity: It is an extension of the proof of work using the proof

of stake. After the computational problem is solved, some miners are chosen
based on an algorithm to sign the block and add it to the chain.
• Proof of Burn: In this protocol a miner gets the right to mine a block by
burning some assets (generally coins). By sacrificing his own assets he gets
the rights to add blocks to the blockchain.
3.1.6 Challenges for using existing bitcoin solution in IoT
Most of the adopted blockchain solutions are forks of the main bitcoin-core code-
base. However the major challenges of adopting the general bitcoin-core for the IoT
scenario are as follows:
• Computational Power: IoT devices are extremely small devices with limited
computational capability. Hence the computational power required for proof
of work is not feasible at all. Even the computation required for public key
encryption and decryption needs to be optimized in order to make it work for
IoT devices.
• Memory: IoT devices are also memory-constrained. So computations requir-

ing too much memory are not feasible.
• Storage: Blockchains require large amount of storage space to store the data.
IoT devices are tiny devices and do not have much storage space to store the
data.
3.2 Proposed Architecture for using PKI in IoT
There can be multiple models for using blockchains to store and deploy public keys
of IoT devices. We discuss three models of architectures of achieving it and discuss
their advantages and disadvantages. By discussing the different models we shift from
a completely centralized model to a completely decentralized model. Also in all the
models we use IPv6 for the sake of communication among various entities of the
network. IPv4 can’t be used as the address space of it is already getting exhausted
and the number of IoT devices would be too large for IPv4 to incorporate. Also
using the existing IPv6 allows the architectures to be integrated easily in to the
existing Internet infrastructure.
3.2.1 Private Permissioned Blockchain and Validators
This model works much like the current workflow for the use of public key in the
internet today. In this model there is a Central Certifying Authority (CCA) which is
considered to be fully secure. This model contains a central chain of validators who
are considered as miners. The blockchain is maintained only by these validators.
These validators will be the nodes maintained by different IoT device manufacturers
and are considered to have enough computational power and storage. These cen-
tral chain of validators are only added after proper verification by the CCA. Figure
3.2 shows the central validator network where each Device Manufacturer Validator
(DMV) are connected to each other and also connected to the CCA which is the
central authority. Figure 3.4 illustrates the entire network where the IoT nodes are
connected to the central validator network. In the Figure 3.4 each IoT node is con-
nected to the validator of its own manufacturer. In Figure 3.4 IoT Node X#Y means
the IoT device with id X manufactured by manufacturer with manufacturer id Y and
DMV#X means Device Manufacturer Validator of manufacture with manufacturer
id X. For sake of simplicity the central CCA is not shown in Figure 3.4.
Figure 3.2: Central Chain Validator Network
3.2.1.1 Blockchain Structure and Protocol
The genesis block contains only the public key and the IPv6 address of the CCA as
shown in Figure 3.3.
Each block contains the hash of the parent block and the latest transaction of all
the nodes in the network as shown in Figure 3.3. The latest transaction of a node
contains the latest public key, IPv6 addresses, id of the device manufacturer and a
signature to verify the authenticity of the transaction. There are 3 kinds of trans-
action that are allowed in the network: addition, removal and update. Transactions
are kept in a central pool of transactions and at regular intervals one of the validators
takes all the transactions, validates them, forms a new block, adds it to the chain
and then broadcasts it in the network. The newly formed block contains the content
of the previous block along with the newly added transactions in it as illustrated in
Figure 3.3.
Figure 3.3: Structure of Blockchain
If the transaction is for a validator node then it signed by the CCA and if the
transaction is that of a normal node then it is signed by the device manufacturer.
For a validator node if the sign doesn’t match the sign of CCA the transaction is
immediately rejected and for the normal nodes if the sign doesn’t match the sign
of the device manufacturer field then it is rejected. The entry for the manufacturer
id is immutable for a node; which means once the node is added to the blockchain,
in all subsequent request for the modification of its entry, its manufacturer id will
never change.
3.2.1.2 Validator Addition Protocol
1. New Manufacturer requests CCA for verification.

Figure 3.4: Entire Network Structure
2. CCA verifies the authenticity of the new manufacturer manually and then
forms a transaction of addition with the manufacturer’s public key, IPv6 ad-
dress of the validator and then signs the transaction with its own private key.
3. The new validator node is added to the network and the node receives the
blockchain from the network.
3.2.1.3 Node Addition Protocol
1. The manufacturer generates a public-private key-pair for the device and then
puts the private key in the device.
2. The manufacturer then forms a new transaction of addition with the device
id, the public key, the device IPv6 address, its own id as manufacturer id and
then signs the entire transaction using its private key. As the manufacturer
itself adds the manufacturer id in the transaction and signs it and once it is
added it can not be changed anytime, so the manufacturer id is not spoofable.
3. The node forming the block verifies the signature and then adds the block.
Threat Models
• Manufacturer Id Spoof: Someone tries to spoof the device manufacturer

id as somebody else. In this scenario the attacker would not have the private
key of the manufacturer he is spoofing and hence the sign would not match.
• Public Key Spoof: If the device manufacturer tries to put in a wrong public
key then other devices would not be able to communicate with this device and
it will hurt the reputation of the manufacturer.
• IPv6 Spoof: This scenario is the same as the above case and hence will not
occur.
3.2.1.4 Validator Update Protocol
1. In case of a compromised validator its public key is revoked by the CCA. The
CCA forms a new transaction of removal of the public key of the validator and
then signs the transaction.
2. The validator needs to go through the entire process of verification again in

order to update its public key.
3. On update of the public key of the validator, the manufacturer forms new
transactions to update the signature for all its devices.
There is no automated process for the CCA to detect a malicious validator. It is

done by manual reporting by other validators and manual verification by the CCA.
The CCA can also use an nomaly detector to detect malicious validators.
3.2.1.5 Node Update Protocol
1. In case a node requests to update its public key or IPv6 address then the node
requests the manufacturer with the update and the manufacturer then forms
a transaction of update and then signs it.
2. In case a node is compromised then the manufacturer revokes its key by forming
a transaction of removal and signs it.
3. When the access of the node is regained then the node asks for the public key
of its manufacturer from the blockchain. Then the node sends its new public
key and IPv6 address by encrypting them with the manufacturer’s public key
which the manufacturer forms as a transaction of update and then signs it.
4. Any update request can only have request for update of any 1 entry, either
public key or the IPv6. Request for update of both at once will be rejected by
the validator.
5. In case of public-key update, IP address can be spoofed. In order to remove

IP spoofing, a challenge-response system is used discussed later.
Threat Models
• Update Attack 1: Malicious Node A claims to be Node B and asks its

public-key to be updated to the manufacturer. However as it will come from
different IPv6 address than that is registered as its IPv6 address so the request
will be rejected.
• Update Attack 2: In the previous attack Node A can use IP spoofing and
make the update happen. IP spoofing can be mitigated by using a challenge-
response system. After the initial request, validator sends a challenge, which
needs to be encrypted using with the private key, to that IP address and only
on getting the correct response, the update is done. As malicious node A won’t
get the challenge (it’s IP address is different), the update won’t go through.
• Update Attack 3: Malicious Node A asks for the update of the IPv6 address
of Node B with its own IPv6 address. However as the message would not be
signed by the private key of original node B and thus it will be rejected.
• Update Attack 4: A man in the middle (MITM) intercepts the update

request and tries to change it but as the request is encrypted using the public
key of the manufacturer so he would not be able to change it.
The initial request for the public key of the manufacturer from the blockchain is
done using Diffie-Hellman Key exchange protocol as explained in Appendix A or
else it would be prone to man-in-the-middle attack.
The method for a manufacturer to detect malicious nodes can be by using some
anomaly detection techniques.
3.2.1.6 Node Communication Protocol
1. Node A requests the public key for the node B with which it wants to commu-
nicate from the validator. It encrypts the request with the validator’s public
key and signs it with its own private key.
2. The validator receives the request, checks its valiadity and checks the latest
block in the blockchain for the public key of node B. If the public key for the
node B is present in the block and it is valid then it sends the response by
signing it with its own private key and encrypting it with node A’s public key
which it can get from the blockchain. If the public key of node B is not present
or it marked invalid then it sends a null response to node A after signing and
encrypting it.
3. Node A receives the public key and IPv6 address for node B. Now it generates
a symmetric key which it signs with own private key and then encrypts with
node B’s public key and sends the message to node B.
4. Node B receives the message from node A and checks its validity. If it want’s
to communicate with node A then it sends message encrypted by encrypting
it with secret key established between these nodes.
5. The header of each message contains the type of encryption used in the mes-
sage.
Threat Models
• Man in the Middle Attack: As all the messages are sent in a encrypted way
so there can be no Man in the middle attack in the communication. However a
man-in-the-middle can intercept the messages and resend them later resulting
in a replay attack [28]. So in order to mitigate this attack, time-stamping is
used along with the messages.
• Denial of message: This model is vulnerable to a denial of message attack

where as the type of encryption is in the header so anyone in between can
intercept the message and change the type of encryption in the header field to
confuse the receiver to decrypt the message in a wrong way. This problem can
be avoided by trying the other method of encryption if one mode of decryption
fails to produce anything meaningful. The type of encryption in the header is
only to reduce double computation for every message.
3.2.1.7 Overall Threats
1. 51% Attack: As this model is a centralised model where there are verified
controllers so it is not vulnerable to the 51% attack threat as any malicious
validator will only affect the working of the manufacturer’s own devices and
not anybody else.
2. Man in the middle attacks: As all communications are encrypted so there

can be no man-in-the-middle attack. Also time-stamping is used to mitigate
replay attacks.
3. Single point of failure: Huge trust is placed on the CCA. Hence compromise
of the CCA would result in the failure of the entire protocol.
4. DDOS Attack: Just like most networks here also the nodes are vulnerable to
DDOS attacks but it can be prevented by using a normal rate limiting firewall.
5. Insider Attack: In case of insider attack in the CCA, the entire network is
compromised as it is the single point of failure of the network.
3.2.2 Evolution of Internet 4.0
This model is inspired from the early decentralized rise of the internet by linking
computers together with each other. It is a more decentralized approach and involves
formation of clusters and merging of clusters into bigger clusters. The entire idea
is born out of a way of finding trust in a completely trustless environment. The
problem is how to trust the public key of a completely unknown node.
3.2.2.1 Paradox of Trust
The paradox of trust is like a chicken-egg problem. Trusting someone needs to know
that person very well. But in order to know a person the person needs to trust him.
This problem is discussed and handled in the context of prisoner’s dilemma problem
previously [29]. In order to reach a trust based consensus, there needs to be some
root of trust and some way of spreading trust among the network.
This model of architecture consists mainly of two different layers in it: The Personal
Area Network (PAN) and the Global Area Network (GAN). The entire point of
trust in this model stays with the device manufacturer. Instead of a already existing
central chain of validators and CCA, in this model the trust network grows slowly
and eventually to a bigger clusters. In this model the manufacturer becomes the
CCA for its own network.
3.2.2.2 Personal Area Network - PAN
The PAN consists of all the user-level devices and a gateway to communicate with
the global network. All the IoT device endpoints connected to a single gateway
constitute of a PAN. The devices and the gateway must be manufactured by the
same manufacturer. Figure 3.5 shows a typical PAN network where different IoT
devices are connected to a single gateway.
Figure 3.5: PAN Architecture
The devices within a PAN can communicate with each other directly or through
the gateway. The contact point of the PAN devices to other networks and devices
not in the PAN is through the PAN gateway. The gateway maintains a private
blockchain in it which contains all the public keys of the IoT devices in the PAN.
All the gateway nodes of a same manufacturer is connected to the validator of the
manufacturer. Hence there are different small networks formed of manufacturer
validators and their corresponding gateway nodes and IoT devices. When a link
of trust is established between two manufacturers, the blockchains maintained by
these manufacturers are merged into one larger blockchain and the validators are
connected together. In this way as more links of trust are established the smaller
clusters grow into larger clusters and the network keeps evolving.
3.2.2.3 Global Area Network - GAN
The GAN consists of the global network which contains all the PAN networks and
all the validators of the different manufacturers. The global network consists of
multiple clusters of different manufacturers which gets merged when links of trust
are established between the manufacturers. Figure 3.6 illustrates a simple GAN
network constituting of a single manufacturer and two different PANs connected to

the manufacturer validator.
Figure 3.6: Single Manufacturer cluster
Here the manufacturer acts as the certifying authority. So when a new device is
added the manufacturer signs the public key of the newly added node and adds it
to its own blockchain or the collective blockchain if there are multiple validators
in the cluster. The genesis block consists of all the public keys of the validators
that are in the same cluster of the network. When a manufacturer trusts another
manufacturer and adds its public key to its own blockchain then the clusters of both
these manufacturers merge into a single cluster, their blockchains merge and the
devices of each manufacturer can establish communication among each other. It

is a more decentralized model than the previous model. Figure 3.7 and Figure 3.8
illustrates this idea of merging of the clusters. In both the figures validator#X refers
to the validator by manufacturer X. PAN gateway X#Y refers PAN gateway no X
manufactured by manufacturer Y. Figure 3.7 illustrates the merge of manufacturer
1 and manufacturer 2 into a single cluster (cluster 1) and manufacturer 3 and 4
remaining in there own clusters (cluster 3 and 2 respectively). In Figure 3.8 all four
manufacturers are merged into a single cluster and so their validators are linked
together in a single network.
3.2.2.4 Block Addition Protocol
1. There are 3 kinds of transactions: Addition, Removal and Update.
2. There is a central pool of all the transactions for each cluster.
3. At regular intervals one of the validators from the cluster forms a block from
all the transactions in the pool, signs it and then broadcasts it in the network.
The interval of block formation can be fixed by the network protocol as per
requirements of the network.
4. The validator to add the block to the blockchain is decided in a round-robin

fashion.
5. In case of a single manufacturer in the cluster it forms the block at regular

intervals.
3.2.2.5 Node Addition Protocol
1. The manufacturer generates the private-key and public-key of the node and
store the private key in the node.
2. The manufacturer then forms a transaction of addition, signs the transaction

and adds it to the pool to be later added to a block.
3. When the node is added to a PAN then the node requests for the public key
of the gateway from the validator using Diffie-Hellman protocol as explained
in Appendix A.
Figure 3.7: Evolution of GAN network 1

Figure 3.8: Evolution of GAN network 2
4. The node then requests the gateway to be added to the PAN using the gate-
way’s public key.
5. The gateway then fetches the node’s public key and adds it to its own private
blockchain of the PAN.
3.2.2.6 Gateway Addition Protocol
1. The manufacturer generates the private-key and public-key of the gateway and
stores the private key in the gateway.
2. The manufacturer then forms a transaction of addition, signs the transaction

and adds it to the pool to be later added to a block.
3. When the gateway is deployed it just needs to connect to the validator directly.
3.2.2.7 Cluster Merge Protocol
1. Manufacturer A establishes a link of trust with manufacturer B. They exchange

their public keys through some other trusted methods like exchanging mails
or manual exchange.
2. Validator of manufacturer A forms a link with validator of manufacturer B.

Validator A forms a new transaction of addition, adds validator B’s public
key to it, signs it and adds it to its blockchain. Similarly Validator B adds
validator A’s public key to its blockchain.
3. Now validator A requests latest block from validator B. The request is sent by
encrypting with validator B’s public key.
4. Now validator A forms a new block which contains the content of its latest
block and the latest block of validator B and adds it to the blockchain and
then broadcasts it in the network.
5. Now both validators maintain a single blockchain and new blocks are added
to this chain.
Figure 3.9 illustrates the merging procedure of two blockchains into a single blockchain.
As shown in the figure, before trust was established between the validators both val-
idators maintained their own separate blockchains. After the link of trust is estab-
lished, validator 1 adds validator 2’s public key to its own blockchain after signing
it properly and vice-versa as shown in Figure 3.9. After that a block is formed with
content of the latest block of both blockchains and so the blockchains merge into a
single blockchain as shown in Figure 3.9.
Figure 3.9: Blockchain Merge Protocol

3.2.2.8 Node/Gateway Update Protocol
1. The node/gateway requests the validator for the update of its IPv6 address/pub-
lic key. Changing of both the values at once is forbidden.
2. In case of public-key update the request has to be sent from the IPv6 address
of the node/gateway in the blockchain. IP address spoofing in this case can be
mitigated by using a challenge-response system as discussed in Section 3.2.1.5.
3. In case of a IPv6 update the request needs to be sent after signing with the
node’s private key.
4. The validator then forms a transaction of update and then signs it and adds
it to the pool.
5. In case the update is of node the updated record is sent to the gateway of the
PAN the node is in. The PAN gateway updates its own private blockchain
with the record.
6. In case the update is of a gateway, the validator sends the update to all the
nodes in the PAN of the gateway so that they can communicate with the
gateway.
3.2.2.9 Node Removal Protocol
1. In case a node/gateway needs to be removed the validator forms a transaction

of removal, signs it and adds it to the pool.
3.2.2.10 Validator Removal Protocol
1. In case a validator is compromised, one of the uncompromised validators forms

a transaction of removal for the validator and adds it to the blockchain.
2. The validator is removed from the central network. All public keys signed by
the validator after the last update of its own public key are revoked.
3. A new block is formed which consists of all these public keys and the validator’s
public key marked as invalid and the new block is broadcast in the network
and added to the blockchain.
The way a validator is deemed compromised is when majority of the validators find
a validator rogue (validator is adding malicious nodes in the network).
1. Node A requests for public key of node B with which it wishes to establish
communication from the gateway.
2. The gateway looks for the public key in its own private blockchain. If it finds
a valid key it means the other node is in the same PAN. If it couldn’t find the
key it means the device is in some other PAN. It requests for the public key
from the validator node.
3. It sends the public key by signing it to the node. If the other node is in the
same PAN then node A sends a symmetric key to node B after signing it and
encrypting it.
4. If node B wishes to communicate it asks for the public key of node A from the
gateway and checks the validity of the message and starts the communication
using the symmetric key.
5. If node B is in some other PAN the node A signs and encrypts the symmetric
key and sends it to its own gateway. The gateway asks for the public key of
the gateway of node B. It then establishes a communication channel with the
gateway of node B and forwards the packet of node A to the other gateway
after itself signing it and encrypting it. The other gateway then sends the
packet to node B and a communication channel is established between the
nodes. All further communications from node A to node B happen through
the gateways of the respective nodes.
3.2.2.12 Threat Models
1. 51% Attack It is vulnerable to compromise if 51% of the validators in a cluster

are compromised as the root of trust remains with the validators themselves.
2. Man in the middle attacks: As all communications are encrypted so there

can be no man-in-the-middle attack. Time-stamping is used in order to miti-
gate replay attacks.
3. Point of failure: Instead of single point of failure as in previous model, the

point of failure shifts to the validators and in case of compromise of a validator,
all devices of that manufacturer is compromised. Also as the rogue validator
can easily add rogue devices in the network, it can add the entries of the rogue
devices in the blockchain and as the other validators trust the rogue validator,
so the entire network is compromised.
4. Insider Attack: In case of insider attack in any manufacturer, the key of a

manufacturer can get compromised. So when the validator of the manufacturer
gets rogue, the entire network is compromised.
3.2.3 Final Model: PUF based Architecture
The final model is a fully decentralized model for the communication of IoT devices
using blockchains. It removes any central authority similar to namecoin [30] and
certcoin [31] and is based on identifying devices uniquely through their IDs. It
requires the devices to have Physical Unclonable Function (PUF) [32] capability
which may be hard to guarantee in all IoT devices. Although having a PUF may
guarantee tighter security benefits but this necessity can be relaxed by having a
secure memory location in all devices. The PUF is only required for the generation
of public key pair whose private key is not kept anywhere but it is calculated on the
fly in a trusted zone when required. This requirement can be relaxed if the devices
have a trusted memory location to store the generated secret key.
3.2.3.1 Device Requirements
In order to guarantee security requirements the devices need to have the following
properties:
1. The device has a PUF from which a public key pair can be generated when
required. The PUF generates the same key pair every time when invoked. All
the computations of the PUF is done in a trusted zone of the device as shown
in figure 3.10. This trusted zone environment is supported by both Intel [33]
and ARM [34]. The secret key is derived from the PUF in the trust zone and
used in the trust zone when required. The key is never stored anywhere nor is
it used outside the trust zone and hence is considered secure.
Figure 3.10: PUF Computation in Trusted Zone
2. If the device fails to guarantee the 1st requirement then it needs both a trusted
zone and a secure memory location only accessible to the trusted zone. Once
it generates the key pair, it stores the secret key in the secure memory location
and the trusted zone uses it from the secure memory when required as shown in
figure 3.11. The key never leaves the secure memory location and the trusted
computation zone and hence is considered secure.
3. In case a device is unable to guarantee any of the above 2 requirements, then

it can not be part of this architecture.
Figure 3.11: Secure Memory Computation in Trusted Zone
3.2.3.2 Global Unique Device Identifier
In this architecture each device (all end nodes and validators) have a Global Unique
Device Identifier (GUDI). This ID is unique for each device and is globally unique
and identifiable across the entire architecture. This ID is given to the devices on
a first-come-first-basis and can be implemented as a global increasing counter or
a uniquely generated random ID for each device. Once a device gets a unique ID
and registers it in the blockchain, no other device can claim that ID. Devices may
communicate with each other through their GUDI with each other.
3.2.3.3 Design of the Layers
Although the architecture can be either layered or flat, for the sake of simplicity
we will discuss only the flat architecture here. Having a multi-layer architecture as
discussed in section 3.2.2 would allow better organization and result in smaller sizes
of blockchains as the gateways can maintain their own private blockchain for the local
network. But for discussion purposes we will only consider a single network of devices
which has a central network of validators connected to each other and maintaining
the blockchain, and the end nodes connected through this central network.
The end nodes can be connected to multiple validator nodes for robustness and
better security as shown in figure 3.12. The validator nodes can be connected in the
form of a mesh network as shown in figure 3.12 and messages (new blocks formed)
can be communicated among the validators through broadcasting or peer to peer

message passing.
The network is completely open and decentralized in the sense that anyone can
join the validator network and start maintaining the blockchain. Also any device
may join the network by registering with a unique ID and its public key with the
blockchain. The exact protocols of initiation, addition, update and deletion are
discussed later. Although joining the validator network is voluntary and anyone can
join it, however the device manufacturers are expected to have some of their nodes
in the validator network maintaining the blockchain.
Figure 3.12: Entire Network
3.2.3.4 Block Structure
The simplest block structure would be to maintain all the transactions along with
the hash of the parent block at the beginning. The genesis block would contain
only the transaction of the initiation of the record of the node starting the network.
Each transaction would contain the following fields: the GUDI of the node, the
IPv6 address of the node, the public key of the node, the type of the transaction
and the signature of the transaction. Each transaction is self-signed by the device
generating the transaction. There is no involvement of the manufacturer in signing
the transactions in this architecture.
A more efficient storage method of the transactions would be to store all the trans-
actions in a merkle tree, discussed in section 3.1.4, at some central location and
then storing the state of the merkle tree in the new block. In this method there
can be some central storage, which contains the merkle tree, maintained by all the
validators thus saving space for all the validators. On addition of new transactions,
the transactions are added to the merkle tree and the updated state of the tree is
stored in the new block and added to the blockchain. This central storing of the
merkle tree is just an optimization technique that can be used by the validators to
reduce the space requirement. Multiple validators can have a single central storage
to maintain the merkle tree together and save space.
3.2.3.5 Device Keys
Each device in the network maintain 2 sets of keys. One set of keys is used for all
the communication with other devices which is the ”Use Key (UK)”. The other set
of keys is used for signing all the addition and update of the transactions in the
blockchain which is the ”Signing Key (SK)”. The Use Key can be stored in normal
memory, but the Signing Key needs to be formed either from the PUF or stored in
the secure memory location in the trust zone as discussed in section 3.2.3.1. The
Signing Key is the root of trust for the device and compromise of it would leave the
device useless.
3.2.3.6 Node/Validator Addition Protocol
1. The node gets a new GUDI for itself. In case of a increasing global counter,
the node checks the current state of the counter and gets its corresponding
GUDI. In case of random generated GUDI, the node generates a random ID,
checks for its existence in the current blockchain and if not present uses it, else
it keeps on generating new IDs until it finds one which is unused.
2. The Signing Key’s public key is retrieved from the PUF or a key pair is gen-
erated and the secret key is stored in the secure memory location, in case of
absence of PUF.
3. The node forms a new initiation transaction with its GUDI, IPv6 address and
the Signing Public Key (SPK) and then signs the transaction with its Signing
Secret Key (SSK) in the trust zone.
4. The validator adding the transaction to the blockchain verifies the signature
of the transaction and adds it to the new block if the signature is correct, else
it discards it.
5. After the initiation transaction is formed, the node generates the Use Key pair.
It then forms a transaction of addition with its GUDI, IPv6 address and the
Use Public Key (UPK) and then signs the transaction with its Signing Secret
Key.
6. The validator adding the transaction to the blockchain retrieves the Signing
Public Key of the node from the blockchain, verifies the signature of the trans-
action and if verified adds it to the blockchain, else it discards the transaction.
7. If the node is a validator, then it receives a copy of the blockchain from its
peers.
3.2.3.7 Node Update Protocol
1. The node can update both its IPv6 address and Use Public Key. In case
of compromise of the Use Secret Key (USK), the Use Public Key needs to be
updated. The GUDI and the SPK are fixed for a node and can not be updated.
2. The node forms a update transaction with the necessary changes and then
signs it with its SSK.
3. The validator adding the transaction to the blockchain will retrieve the SPK
of the node from the blockchain, verify the signature of the transaction and if
verified will add it to the blockchain, else will reject the transaction.
3.2.3.8 Node Deletion Protocol
1. The node who wants to revoke its UPK, due to its compromise or some reason,
forms a delete transaction and signs the transaction with its SSK.
2. The validator adding the transaction retrieves the SPK of the node, verifies
the signature of the transaction and if verified adds it to the blockchain. Else
it rejects the transaction.
3.2.3.9 Node Discovery
The previous models had implicit node discovery in them. In those architectures as
the addition of the nodes was done by the manufacturer, so each node was associated
with the manufacturer and the manufacturer can also add the type of the node in
the blockchain if required. If some node wanted to find some specific device of a
manufacturer, it could search the blockchain and get the corresponding record for
that device. However in this model nodes are only identified through their GUDI and
as nodes add themselves in the blockchain, there is no way to know the manufacturer
and type of the device correctly. So if a device wants to communicate with some
other device then it needs to get the GUDI of that device through some other method
like writing letters or exchanging mails.
Following is the workflow when device A wants to establish communication with

device B.
1. Device A gets the GUDI of the device B through some other method from
device B.
2. Device A asks for the record of device with GUDI of device B from one of the
validators maintaining the blockchain. The communication with the validator
is established using the Diffie-Hellman protocol as explained in Appendix A
to avoid MITM attacks.
3. The validator from which the record is asked fetches the record with cor-
responding GUDI from the blockchain. As the record was added in the
blockchain after verifying the signature, so verifying its content again is not
necessary. The validator sends the record to Device A.
4. Device A gets the public key and the IPv6 address of device B from the record
and sends a secret key, by encrypting it with the public key, to device B. If
device B wants to continue the communication, it responds with an acknowl-
edgement, else it does nothing.
3.2.3.11 Privacy and Anonymity
This model has the limitation of the absence of device discovery as discussed in Sec-
tion 3.2.3.9. However this limitation empowers it with the powerful tool of anonymity
and ensures privacy of the device. As the devices add themselves to the blockchain,
their privacy and anonymity is maintained in the network. As most IoT devices can
have critical information in it, privacy is an important part and this model provides
the required anonymity to the devices.
3.2.3.12 Some Threat Models
• 51% Attack This architecture is secure based on the honesty of the validator
nodes. The validator nodes need to verify the correctness of the new transac-
tions that are being added and reject them if the signature is not verified. So if
majority of nodes are honest, then only correct transactions will get added to
the blockchain. However if more than 51% of the validators are malicious and
they collude, then incorrect malicious transactions (transactions with wrong
public key and wrong signature) may get added to the blockchain resulting in
compromise of the whole network. Hence the network is vulnerable to 51%
collusion attack.
• Loss of Private Key In case the SK pair of a device is compromised, the

control of the device can not be regained without manual intervention.
• Point of Failure In the first model, the CCA was the single point of failure
and compromise of it would render the network compromised. In the second
model, the point of failure is the manufacturer validators. However in this
model, the point of failure is distributed among the devices, as authenticity of
each device is maintained entirely using its SK pair.
• Aging of PUF One of the problems with PUFs is that PUFs generally de-
teriorate with time. If a PUF deteriorates, then it won’t be able to produce
the same key pair and so it is equivalent to the loss of private key, and so the
device control is completely lost.
• Insider Attack: This model is not vulnerable to any insider attack as the
root of trust is with the devices itself.
Chapter 4
IoT Simulator in NS3
A simulator is an essential component for testing and validating new models and
architectures of any system. As testing new threat models is expensive to test on
real networks and devices, so NS3 simulator was formed. Network Simulator 3
(NS3) simulator was designed to be used for research purposes to test new protocols
and architecture [14]. NS3 has been actively developed by the community and
new modules are being actively developed and maintained by the community. NS3
simulator has support for most of the networking protocols and also supports most
types of networking devices. The different protocols generally used by IoT devices
like Bluetooth, LTE, Zigbee, 6LOWPAN are also supported in the simulator.
4.1 IoT Generator
IoT generator is extended from the NS3 topology generator [4]. It is visual inter-
face using QT4 to form a network topology of nodes/devices with applications and
connecting them using different protocols. Figure 4.1 shows an example topology of
devices formed using the generator. After the topology is formed it can then gener-
ate both C++ and python simulation source files for NS3 which can be run directly
in NS3 to get simulation results. The generator is built on the QT framework of
C++ and new types of nodes can be added to be generated by the generator. For
the IoT simulator we have added 3 kinds of devices namely IoT node, Blockchain
45
Chapter 4. IoT Simulator in NS3 46
and Gateway (Although gateway shouldn’t be specific node rather just a general
node but as we had a separate class for the gateway node hence the addition).
Figure 4.1: NS3 Generator example [4]
The IoT node is mapped to the IotSensorNode class, the gateway node is mapped to
the GatewayNode class and the blockchain node is mapped to the BlockchainNode
class of the NS3 simulator. When the simulation code is generated, the objects of
corresponding classes are instantiated in the source code. The generator is scalable
in terms of size of the topology and number of devices in the topology. Currently
only wireless and wired links are supported among the various kinds of nodes. The
different kinds of classes are explained later in this chapter. The nodes can be
added and arranged in the topology by using drag and drop. Currently the classes
are implemented as applications in NS3. However in future work, they are supposed
to be implemented as nodes in NS3. On these nodes, different IoT applications can
be deployed so that different sensor data of IoT devices can be simulated and the
simulator remains flexible. Similarly the blockchain class needs to be flexible so
that different blockchain protocols can be easily implemented through applications
over blockchain nodes. Also the links are currently connected through the Internet
stack protocol but flexibility can be added by including support for other protocols.
The resulting generated simulation file can be run directly in NS3 simulator to get
simulation results.
The workflow of the generator is described below.
1. The generator has options for multiple types of nodes, hubs, applications and
links in it as shown in Figure 4.2.
2. Various devices can be selected and connected using different links to form
the topology. An example topology using IoT devices and blockchain nodes is
3. After creating the topology, the C++ source code can be generated for the
topology as shown in Figure 4.4.
4. The C++ source file which can be run in NS3 for simulation is created as
Figure 4.2: IoT generator start page

Figure 4.3: Sample IoT topology using IoT generator
Figure 4.4: Generate IoT simulation code

Figure 4.5: Simulation code generated
4.2 NS3 Simulator Classes
The protocols and applications logic of the IotSensorNode, GatewayNode and the
BlockchainNode class are implemented as applications in NS3. The blockchain class
is inspired from the bitcoin simulator used to evaluate the security and performance
of proof of work [35] and the general NS3 applications.
The CryptoPP cryptographic library is used to provide different encryption func-

tionalities for the applications [36].
The brief functionality and implementation of each class is explained below. Detailed
implementation and explanation of the classes is given later in the appendix.
• Block Class: The Block class implements the basic structure and function-
alities of a block and exposes the functions to add, modify, query and delete a
block.
• Blockchain Class: The blockchain class implements the main blockchain

logic and consists of multiple blocks together and it also contains the metadata
for maintaining the blockchain.
• Blockchunk: The blockchunk class acts as a part of blockchain and contains

multiple blocks in it but it is not a blockchain as it doesn’t have the metadata
to maintain a blockchain. It is used when multiple blocks are required to be
added to the blockchain.
• BlockchainNode Class: The blockchainnode class consists of the application

to be used in a node to maintain the blockchain in it. It is used as a miner or
validator in the blockchain network.
• IoTSensorNode Class: The IotSensorNode class contains the application

logic to be used as an endpoint IoT device in the IoT network.
• GatewayNode Class: The gatewaynode class contains the application logic

for use in a gateway node. It is useful for simulating the architecture in the
2nd proposed model.
Chapter 5
Simulation Results
We ran the architecture models on the simulator platform and tested different attack
models in it. In different attack models there are different nodes which acted as
malicious nodes and we simulated message passing to figure feasibility of different
attack models. Establishment of trust, through other channels like manually or
through mail exchange, among manufacturer validators or among different nodes
can not be simulated in the simulator. Also the protection of the Signing Key
through PUF or secure memory also can not be simulated. Hence all threat models
corresponding to these are not addressed in the simulations.
5.1 Private Permissioned Blockchain Model
In all the following experiments, we assume the central certifying authority to be

secure and non-compromised at all conditions.
5.1.1 Simple Experiment Model
We design a simple network with some validators and a CCA with different IoT
nodes connected to the central validator network. In the network all the validators
are connected to each other and also to the CCA.
51
Chapter 5. Simulation Results 52
Figure 5.1: Simple Experiment Network
Figure 5.1 shows the topology of the simple experimental network. The result of
running the simulation is given below.
5.1.1.1 Result
Validator 1 is CCA
Validator 2 is of Manufacturer IBM
Validator 3 is of Manufacturer ERICSSON
Validator 4 is of Manufacturer QUALCOMM
Validator 5 is of Manufacturer SILICON
Building the topology !
Creating list of all nodes !
Forming the CCA and validator links !
Forming the validators links !
Forming validator and device links !
All links formed !
The nodes connections were created in 0.000144005 s .
Creating 15 nodes !
The nodes were created in 0.000437021 s .

Creating the links between the validator nodes !
Creating the links between rest of the nodes !
Created all the links !
The total number of links is 24 (0.0288 s ).
Installing the internet stack !
Internet stack installed in 0.00601697 s .
The IP addresses have been assigned in 0.00878096 s .
Validator 3: Adding Node 10 public key
Validator 2: Mining Block
Validator 3: Received Block from Validator 2
Node 10: Get public key of Node 7
Validator 3: Key request from Node 10
Node 10: Message from Validator 3
Node 10: Received public key of Node 7
Node 10: Sending message to Node 7
Validator 3: Received message from Node 10
Validator 2: Received message from Validator 3
Node 7: Received message from Validator 2
Node 7: Received message from Node 10
Node 7: Received secret key from Node 10
Validator 5: No key for Node 14
Node 13: No public key of Node 14

5.2 Internet 4.0 Model
As it is model in which clusters get merged, so a time based simulation in which

clusters are formed and they are merge into larger clusters, forming bigger networks
would be appropriate. However the link of trust that is established manually be-
tween the manufacturers is not possible to simulate. Hence for the purpose of the
experiments we test by forming small clusters.
We designed a simple network with two manufacturers, one having 2 PANs in it and
the other having a single PAN in it. The IoT end nodes are within the PAN. The
topology of the network is shown in Figure 5.2.
5.2.1.1 Result

Validator 2 is of Manufacturer IBM
Forming the gateway links !
All links formed !
Creating 11 nodes !

Validator 1: Adding Gateway 3 public key
Validator 1: Adding Validator 2 public key
Validator 2: Adding Validator 1 public key
Validator 2: Adding Validator 1 latest block
Validator 1: Adding Validator 2 latest block
Gateway 3: Adding Node 4 public key
Validator 1: Received message from Gateway 3
Validator 1: Received public key of Node 4

Gateway 3: Key request from Node 4
Gateway 3: Received message from Node 4
Node 6: Received message from Gateway 3
Gateway 9: Key request from Node 10
Gateway 9: Key not in store
Validator 2: Key request from Gateway 9
Gateway 9: Received message from Validator 2
Node 10: Message from Gateway 9

5.3 PUF based Architecture
Although we could not simulate the functioning of PUF, we form a simple network
with 4 validators in the central network and 8 IoT nodes. The topology of the
network is shown in Figure 5.3. The result of the simulation is given below.

5.3.1.1 Result

Forming validator and device links !
All links formed !
Creating 12 nodes !
Validator 3: Adding signing key with of Node with Id 100

5.3.2 ID Exhaustion
While simulating the network we came across a new possible threat model. The id
of the devices are maintained using a integer container in C++ with a incrementing
counter. As integer is a 32 bit container, so there can be maximum of 232 maximum
ids. Hence a malicious device can register as multiple ids and exhaust all ids so
that no other new device may register. This attack depends entirely on how the
management of id is done in the code and having a 256 bit id would make this
attack unfeasible in real life.
Chapter 6
Conclusion
In this thesis we presented 3 different architectures for using key-based message

communication among IoT devices. We also designed a scalable network simulator
to test IoT network simulations in NS3. Case studies for the architectures are as
follows:
6.1 Attack Case Studies
6.1.1 Mirai
The foundation of the Mirai attack was to expand its botnet by brute-forcing into
as many devices as possible and gain control over them. The nature of the brute-
forcing was to use default username password combinations of the devices. If all
the devices use key-based architecture for all the communications then although the
attacker may initiate a communication using the device’s public key but it would
not gain control over the device as the device will reject the communication if the
communicating device is not in its allowed list of devices. Hence the Mirai malware
would not spread and it would have failed. Hajime which is a variant of Mirai would
also fail as its spreading mechanism is the same as that of Mirai.
61
Chapter 6. Conclusion 62
6.1.2 Phillips bulb attack
The IoTworm attack described in Chapter 1 would also fail with our proposed ar-
chitecture as all the devices used the same key for the firmware updates and getting
the key once using side channel attack made all the devices vulnerable to malicious
updates. In our model the cost to get the keys using side channel attack would be
higher as each device would have different keys.
6.2 Other Case Studies
6.2.1 SmartHome Architecture
Most of the current smart-homes also follow a layered architecture in which all the
smart devices are connected to a single gateway router which in turn is connected
to the cloud for the sake of remote control and management [37].
Figure 6.1: Typical Smart-Home Architecture

For remote management the mobile device has normally an authentication method
which is generally a username password combination for access. The user remotely
controls the home gateway router and all communication to the devices is routed
through the gateway. On theft of the username password combination, an attacker
can gain easy access to the entire smart-home. With slight changes our architec-
ture can be easily integrated into the existing architecture making it more agile and
secure. Instead of the gateway being connected to a cloud interface it will be con-
nected to a central blockchain validator network and the mobile device for remote
control will also be connected to the same blockchain validator network. Now the
device can control the smart devices through normal node communication protocol
of the architecture. However in this model as anyone can communicate with the
gateway the gateway can maintain an access control list and respond back only to
specific devices (in this case only the mobile phone). This model gives certain ob-
vious advantages like instead of authentication being secured by a password which
can be easily hacked it secured by a private key which is longer that the password
and harder to hack. Also in the case of a compromise the architecture gives ease
of updating of the access through updating of public key. Also instead of sharing
password for allowing new devices to remote control it can easily allow new devices
by updating access control list of the gateway.
Existing Architecture New Architecture

Connected to cloud Connected to central validator network
Secured by plaintext password Secured with N bit private key
Grant access with new user creation Grant access through access list
Table 6.1: Comparison of current and proposed architecture
6.2.2 Samsung Pay
Samsung Pay, the mobile payment solution by Samsung for Near Field Communica-
tion (NFC) payments also needs certified communications from devices for security
[38]. Each device contains trusted zones for each payment provider and payment
providers need verification of messages originating from its own trusted zone. Each
communication to a payment provider is sent along with a certificate of the payment
provider’s trusted zone. Each payment provider’s certificate is signed by a Samsung

root certificate and the payment service provider.
Figure 6.2: Samsung Certificate Architecture
Figure 6.3: Samsung Pay payment flow

The Samsung root certificate is installed in a trusted environment while being man-
ufactured in the factory and is signed by the manufacturer. This method is similar
to our model of evolution where each manufacturer signs and adds the device pub-
lic key while manufacturing. However in this case if the device root certificate is
compromised then all communications are compromised. Also this solution is not
heterogeneous in nature as there would not be any cross manufacturer compatibility
and in case of update of payment service provider’s key, update of all device cer-
tificates is not easy. However if they adopt our model of evolution of the network
then in it, the device manufacturer (in this case Samsung) and the payment service
providers would form a cluster of their own and maintain a common blockchain. So
update of the device keys can be done easily and is easily auditable. Also update
of main manufacturer key is possible based on mutual consensus and is just the
addition of a new block to the blockchain and all protocols would work as it is.
6.3 Comparison of the Architectures
The features and weaknesses of the different architectures are as follows:

Permissioned Model Evolution Model Decentralized Model
Point of failure - CCA Points of failure - No single point of failure
Manufacturer
Centralized Hybrid Decentralized
Node discovery Node discovery No Node discovery
Table 6.2: Comparison of different architectures
6.4 Contributions of this thesis
The major contributions of this thesis are as follows:
1. Our proposed architectures for IoT device communications using blockchain

gives a robust and secure model for communication among the devices. The
architectures are scalable and secure for device communications. Although
there is a overhead for encryption & decryption in key-based communication

but this overhead would be minimal as normal username password based au-
thentication would also require a secure channel or else it would be vulnerable
to sniffing attack. Also this model gives flexibility as any device willing to
establish communication with some device can do so.
2. Our work also gives a IoT simulator in NS3. Now IoT network models with
IoT protocols can be easily designed and tested in NS3.
Chapter 7
Future Work
The possible improvements in the simulator and the architecture are as follows:
7.1 Architecture
• Quantum blockchains The authors in [39] describe a way for securing blockchain
using quantum computing. They define a consensus protocol for the blockchain
which is secure against even quantum computing and doesn’t need the com-
putationally intensive proof of work for the consensus. Their work uses the
quantum key distribution to guarantee authentication in the protocol and as
quantum key distribution is based on the laws of quantum physics so the mes-
sage can not be tampered without destroying it. As quantum computing is
the future so a protocol using quantum secured blockchain would be required.
• Formal method verification In order to properly verify the different threat

models and workings of a protocol, proper formal method verification of a
protocol needs to be done. Formal method verification of all 3 protocols need
to be done in order to find new vulnerabilities and test existing threat models
for the protocols.
• More Robust Decentralized Model Currently on compromise of the Sign-

ing Key would make the device useless. A more robust model would even allow
the update of the Signing Key on compromise.
68
Chapter 7. Future Work 69
7.2 Simulator
• Nodes Currently the different IoT nodes, validator and gateway nodes are
implemented as applications in NS3. However they need to be implemented
as node classes which can be extended easily.
• IoT Sensors After IoT nodes are implemented as node classes, different ap-
plication classes can be implemented which simulate functionalities of different
IoT sensors to send sensor data.
• Batch Deploy Currently the simulator allows the nodes to be deployed indi-
vidually. However batch deploy of multiple IoT nodes would be a good feature.
• Communication Protocols Functionality for different nodes communicate

over other protocols like LTE, Zigbee would be a nice feature.
Appendix A
Public Key Cryptography
Before the advent of public key cryptography there was only symmetric key cryp-
tography where both parties had a common key and all communications used to
happen by encrypting using the common key. However the common key needed
to be transferred using some physical channel or some trusted courier. Then came
the the public key cryptography which eliminated the need for this secure physical
channel.
Diffie-Hellman Key Exchange: Diffie-Hellman Key Exchange was the first of the
protocols for public-key cryptography [5]. It allowed establishing a secret key among
two parties even when both are initially communicating on a open, unencrypted
channel. The protocol uses mathematical functions in order to establish the secret
key. The working of the protocol is explained below.
General Explanation
Communicating parties A and B need to choose an arbitrary color which may not be
secret but needs to be different every time. Suppose the color is yellow. Now both
A and B selects some secret colors which they keep to themselves. Let the secret
colors be red and aqua. Now both parties mix their own chosen secret color with
the decided common color. So in this case A mixes red and yellow and forms orange
and B mixes aqua and yellow and forms blue. Now A and B exchange their mixed
colors with each other. Now each partner mixes his own chosen secret color with
the mixed color he received from his partner and forms the common secret among
71
Appendix 1. Public Key Cryptography 72
the partner. So in this case A receives blue from B and then mixes red with it to
form common color brown and B receives orange from A and mixes blue with it to
also come to the common color brown.
Figure A.1: Diffie-Hellman Key Exchange [5]
Cryptographic Explanation
The simplest implementation of this protocol uses multiplicative group of integers

modulo p, where p is prime and g is primitive root modulo p. The resulting shared
secret takes any value between 1 and p-1.
1. A and B agrees to use modulo = 7 and base g = 3 (which is primitive modulo

7)
Appendix 1. Public Key Cryptography 73
2. A chooses a secret integer say 11 and then sends B 311 mod 7 which is 5.
3. B chooses a secret integer say 51 and then sends A 351 mod 7 which is 6.
4. A now computes 611 mod 7 and get secret as 6.
5. B now computes 551 mod 7 and get secret as 6.
6. Now both A and B share the secret key of 6 among them.
RSA Algorithm: The RSA algorithm was discovered later by three people Rivest,
Shamir and Adleman on whose name the algorithm was named. This protocol also
uses the mathematical property of primes that it is hard to find the prime factors of
a number which is the product of two very large primes. In this protocol there are
2 distinct set of keys used for encryption and decryption. There are 2 keys called
public key and private key. The public key as the name suggests is public and known
to everyone and the private key is only known to the user. Now anyone can send a
message to the user by encrypting using the public key of the user and only the user
can decrypt the message as the message can only be decrypted using the private
key which is with the user. Now signing of a message works in the reverse order in
which the user signs the message with his private key (signing algorithm is same as
the encryption algorithm) and anyone can verify the signature using the public key
(verification algorithm is same as decryption algorithm).
Let there be 3 positive integers e,d and n. Let the message be m. Now the public
key consists of e and n. So a simple encryption algorithm would be c = me mod n
. Now e and d are chosen in a way such that (me )d = m mod n. Now decrypting
the encrypted message c would be cd mod n = (me )d mod n = m.
Elliptic Curve Cryptography Elliptic Curve Cryptography came after RSA and
it is based on the algebraic structure of elliptic curves over finite fields. ECC al-
gorithms use much smaller key sizes as compared to RSA algorithms and also re-
quires much less computational power to provide the same security. The mathemat-
ical problem behind this protocol is the ”elliptic curve discrete logarithm problem”
(ECDLP) which states that it is infeasible to find the discrete logarithm of a ran-
dom elliptic curve element with respect to a publicly known base point. Multiple
cryptographic schemes have been developed based on this elliptic curve problem.
Appendix B
Simulator Class Codes and

Explanation
The simulator contains 2 parts: the IoT-generator and the NS3 classes implementing
the IoT and blockchain logic.
B.1 IoT-Generator
B.1.1 Generator Header File

# ifndef GENERATOR_H
# define GENERATOR_H
# include " node . h "

# include " network - hardware . h "
# include " application . h "
# include < iostream >

# include < fstream >
# include < string >
# include < vector >
/**
* \ ingroup generator
* \ brief The main class of the Generator .
*
* The Generator class is the main class of the kern folder .
75
Appendix B. Simulator Class Codes and Explanation 76
* It is used for call all the classes you can found here .
*
* This class works around three vector which contain Nodes , Links and Applications .
*
* Usage example :
* - create an Generator object ,
* Generator * gen = new Generator ( std :: string (" Simulation Name "));
* - add nodes ,
* gen - > AddNode ( std :: string (" Pc "));// or router , wifi station , ...
* - add links ,
* gen - > A d d N e t w o r k H a r d w a r e ( std :: string (" Hub "));// or ap , bridge , ....
* - connect nodes to link ,
* gen - >( link ) - > Install ( Node name );
* - add applications ,
* gen - > A ddApplic ation ( std :: string (" Ping ") , senderNodeName , receiverNodeName , startTime , endT
*
* You can see all examples of all im plementa tion into kern / examples / folder .
*/
class Generator
{
public :
/**
* \ brief Constructor .
* \ param simulat ionName simulation name
*/
Generator ( const std :: string & si mulatio nName );
/**
* \ brief Destructor .
*/
~ Generator ();
/**
* \ brief Add a config line .
* \ param config new config to add to config list
*/
void AddConfig ( const std :: string & config );
/**
* \ brief Add an node .
*
* This used to add an node . It add the node to the
* vector listNode and increment the number of node .
*
* \ param type node type . ( pc , hub , switch ,...)
*/
void AddNode ( const std :: string & type );
/**
* \ brief Add an node group .
* \ param type node type
* \ param number number which will be added
*/
void AddNode ( const std :: string & type , const size_t number );
/**
* \ brief Remove an node element .
* \ param name node name to remove
*/
void RemoveNode ( const std :: string & name );
/**
* \ brief Remove an node element .
* \ param index node index to be removed
*/
void RemoveNode ( const size_t index );
/**
* \ brief Get node at specified index .
* \ param index index
* \ return node pointer
*/
Node * GetNode ( const size_t index );
/**
* \ brief Get number of nodes .
* \ return number of nodes .
*/
size_t GetNNodes () const ;
/**
* \ brief Add an appplication .
*
* This procedure is used to add an procedure . It add the application to the
* vector l is tA pp l ic at i on and increment the number of application .
*
* \ param type type of the application . ( ping , tcp - large - transfert , udp - echo ...)
* \ param senderNode sender node
* \ param receiverNode receiver node
* \ param startTime start time
* \ param endTime end time
* \ param port port
*/
void AddAppli cation ( const std :: string & type , const std :: string & senderNode , const std :: string
/**
* \ brief Add an application .
*
* This procedure is used to add an procedure . It add the application to the
* vector l is tA pp l ic at i on and increment the number of application .
*
* \ param type the type of the application . ( ping , tcp - large - transfert , udp - echo ...)
* \ param senderNode sender node
* \ param receiverNode receiver node
* \ param startTime start time

* \ param endTime end time
*/
void AddAppli cation ( const std :: string & type , const std :: string & senderNode , const std :: string
/**
* \ brief Remove an application element .
* \ param name application name to remove
*/
void R e m o v e A p p l i c a t i o n ( const std :: string & name );
/**
* \ brief Get application element at specified index .
* \ return application pointer
*/
Application * GetAp plicatio n ( const size_t index );
/**
* \ brief Get number of applications .
* \ return number of applications
*/
size_t G e t N A pp l i c a t i o n s () const ;
/**
* \ brief Add an link .
*
* This procedure is used to add an link . It add the link to the
* vector listLink and increment the number of link .
*
* \ param type type of the link . ( point - to - point , csma ,...)
*/
void A d d N e t w o r k H a r d w a r e ( const std :: string & type );
/**
* \ brief Add link and his linkNode .
*
* Example , an Ap , must have an ap node to be generated .
*
* \ param type link type
* \ param linkNode node name
*/
void A d d N e t w o r k H a r d w a r e ( const std :: string & type , const std :: string & linkNode );
/**
* \ brief Add link with her linkNode and ifaceName .
*
* \ param type link type
* \ param linkNode node name
* \ param ifaceName iface name
*/
void A d d N e t w o r k H a r d w a r e ( const std :: string & type , const std :: string & linkNode , const std :: strin
/**
* \ brief Remove an link element .
* \ param name link name to remove
*/
void R e m o v e N e t w o r k H a r d w a r e ( const std :: string & name );
/**
* \ brief Remove an link element .
* \ param index index of the link to remove
*/
void R e m o v e N e t w o r k H a r d w a r e ( const size_t index );
/**
* \ brief Get link at specified index .
* \ return link pointer
*/
N et wo rk H ar dw ar e * G e t N e t w o r k H a r d w a r e ( const size_t index );
/**
* \ brief Get number of links .
* \ return number of links
*/
size_t G e t N N e t w o r k H a r d w a r e s () const ;
/**
* \ brief Generate ns -3 C ++ code .
*
* This procedure is the main procedure to generate the code from the simulation .
* It also go to use all the procedure on the bottom like generate all headers , ...
*/
void G en er at e Co de Cp p ( std :: string fileName = "");
/**
* \ brief Generate ns -3 python code .
*
* This procedure is the main procedure to generate the code from the simulation .
* It also go to use all the procedure on the bottom like generate all headers , ...
*/
void G e n e r a t e C o d e P y t h o n ( std :: string fileName = "");
private :
/**
* \ brief Simulation name .
*/
std :: string m _ s i m u l a t i o n N a m e ;
/**
* \ brief Configuration list .
*/
std :: vector < std :: string > m _ l i s t C o n f i g u r a t i o n ;
/**
* \ brief Number attribute of term node created .
*/
size_t m_ind iceNodeP c ;
/**
*/
size_t m _i n di ce No d eI ot ;
/**
*/
size_t m _ i n d i c e N o d e B c n o d e ;
/**
*/
size_t m _ i n d i c e N o d e G a t e w a y ;
/**
* \ brief Number attribute of router node created .
*/
size_t m _ i n d i c e N o d e R o u t e r ;
/**
* \ brief Number attribute of ap node created .
*/
size_t m_ind iceNodeA p ;
/**
* \ brief Number attribute of station node created .
*/
size_t m _ i n d i c e N o d e S t a t i o n ;
/**
* \ brief Number attribute of bridge node created .
*/
size_t m _ i n d i c e N o d e B r i d g e ;
/**
* \ brief Number attribute of tap node created .
*/
size_t m _i n di ce No d eT ap ;
/**
* \ brief Number attribute of emu node created .
*/
size_t m _i n di ce No d eE mu ;
/**
* \ brief List of node created instance .

*
* This attribute is the list of the created instance of node .
*/
std :: vector < Node * > m_listNode ;
/**
* \ brief List of application created instance .
*
* This attribute is the list of the created instance of application .
*/
std :: vector < Application * > m _ l i s t A p p l i c a t i o n ;
/**
* \ brief List of link created instace .
*
* This attribute is the list of the created instance of link .
*/
std :: vector < N e tw or k Ha rd wa r e * > m _ l i s t N e t w o r k H a r d w a r e ;
/**
* \ brief Number attribute of ping application created .
*/
size_t m _ i n d i c e A p p l i c a t i o n P i n g ;
/**
* \ brief Number attribute of tcp large transfert application created .
*/
size_t m _ i n d i c e A p p l i c a t i o n T c p L a r g e T r a n s f e r ;
/**
* \ brief Number attribute of udp echo application created .
*/
size_t m _ i n d i c e A p p l i c a t i o n U d p E c h o ;
/**
* \ brief Number attribute of ap link created .
*/
size_t m _ i n d i c e N e t w o r k H a r d w a r e A p ;
/**
* \ brief Number attribute of emu link created .
*/
size_t m _ i n d i c e N e t w o r k H a r d w a r e E m u ;
/**
* \ brief Number attribute of point - to - point link created .
*/
size_t m _ i n d i c e N e t w o r k H a r d w a r e P o i n t T o P o i n t ;
/**
* \ brief Number attribute of sixlowpan links created .
*/
size_t m _ i n d i c e N e t w o r k S i x l o w p a n ;
/**
* \ brief Number attribute of tap link created .
*/
size_t m _ i n d i c e N e t w o r k H a r d w a r e T a p ;
/**
* \ brief Number attribute of hub link created .
*/
size_t m _ i n d i c e N e t w o r k H a r d w a r e H u b ;
/**
* \ brief Number attribute of bridge link created .
*/
size_t m _ i n d i c e N e t w o r k H a r d w a r e B r i d g e ;
//
// C ++ code generation operation part
//
/**
* \ brief Generate headers code .
*
* This function return a string wich contain all C ++ header without duplicate .
*
* \ return headers code
*/
std :: vector < std :: string > Gen erateHea der ();
/**
* \ brief Generate vars C ++ code .
*
* This function return a string wich contain all C ++ vars .
* \ return vars code
*/
std :: vector < std :: string > Ge ne ra t eV ar sC p p ();
/**
* \ brief Generate command line C ++ code .
* \ return commend line code
*/
std :: vector < std :: string > G e n e r a t e C m d L i n e C p p ();
/**
* \ brief Generate config C ++ code .
* \ return config code
*/
std :: vector < std :: string > G e n e r a t e C o n f i g C p p ();
/**
* \ brief Generate node declaration C ++ code .

* \ return declaration code
*/
std :: vector < std :: string > Ge ne ra t eN od eC p p ();
/**
* \ brief Generate link C ++ code .
* \ return link code
*/
std :: vector < std :: string > G e n e r a t e N e t w o r k H a r d w a r e C p p ();
/**
* \ brief Generate net device C ++ code .
* \ return net device code
*/
std :: vector < std :: string > G e n e r a t e N e t D e v i c e C p p ();
/**
* \ brief Generate ip stack declaration .
* \ return IP stack code
*/
std :: vector < std :: string > G e n e r a t e I p S t a c k C p p ();
/**
* \ brief Generate ip assign C ++ code .
* \ return IP assign code
*/
std :: vector < std :: string > G e n e r a t e I p A s s i g n C p p ();
/**
* \ brief Generate tap bridge C ++ code .
* \ return tab bridge code
*/
std :: vector < std :: string > G e n e r a t e T a p B r i d g e C p p ();
/**
* \ brief Generate route C ++ code .
* \ return route code
*/
std :: vector < std :: string > G e n e r a t e R o u t e Cp p ();
/**
* \ brief Generate application C ++ code .
* \ return application code
*/
std :: vector < std :: string > G e n e r a t e A p p l i c a t i o n C p p ();
/**
* \ brief Generate trace C ++ code .
* \ return trace code
*/
std :: vector < std :: string > G e n e r a t e T r a c e Cp p ();
//
// Python code generation operation part
//
/**
* \ brief Generate vars python code .
*
* This function return a string wich contain all python vars .
*
* \ return vars code
*/
std :: vector < std :: string > G e n e r a t e V a r s P y t h o n ();
/**
* \ brief Generate command line python code .
* \ return commend line code
*/
std :: vector < std :: string > G e n e r a t e C m d L i n e P y t h o n ();
/**
* \ brief Generate config python code .
* \ return config code
*/
std :: vector < std :: string > G e n e r a t e C o n f i g P y t h o n ();
/**
* \ brief Generate node declaration python code .
* \ return declaration code
*/
std :: vector < std :: string > G e n e r a t e N o d e P y t h o n ();
/**
* \ brief Generate link python code .
* \ return link code
*/
std :: vector < std :: string > G e n e r a t e N e t w o r k H a r d w a r e P y t h o n ();
/**
* \ brief Generate net device python code .
* \ return net device code
*/
std :: vector < std :: string > G e n e r a t e N e t D e v i c e P y t h o n ();
/**
* \ brief Generate ip stack declaration .
* \ return IP stack code
*/
std :: vector < std :: string > G e n e r a t e I p S t a c k P y t h o n ();
/**
* \ brief Generate ip assign python code .
* \ return IP assign code

*/
std :: vector < std :: string > G e n e r a t e I p A s s i g n P y t h o n ();
/**
* \ brief Generate tap bridge python code .
* \ return tab bridge code
*/
std :: vector < std :: string > G e n e r a t e T a p B r i d g e P y t h o n ();
/**
* \ brief Generate route python code .
* \ return route code
*/
std :: vector < std :: string > G e n e r a t e R o u t e P y t h o n ();
/**
* \ brief Generate application python code .
* \ return application code
*/
std :: vector < std :: string > G e n e r a t e A p p l i c a t i o n P y t h o n ();
/**
* \ brief Generate trace python code .
* \ return trace code
*/
std :: vector < std :: string > G e n e r a t e T r a c e P y t h o n ();
//
// C ++ generation operation part .
//
/**
* \ brief Name of the C ++ output file name .
*/
std :: ofstream m_cppFile ;
/**
* \ brief Write C ++ code into the attribute file name .
* \ param line the new line to add to the attribute file name
*/
void WriteCpp ( const std :: string & line );
//
// Python generation operation part .
//
/**
* \ brief Name of the python output file name .
*/
std :: ofstream m_pyFile ;
/**
* \ brief Write python code into the output file name .
* \ param line the line to be writted
*/
void WritePython ( const std :: string & line );
};
# endif /* GENERATOR_H */
B.1.2 Validator Header File

# ifndef VALIDATOR_H
# define VALIDATOR_H
# include < iostream >

# include < string >
class Validator
{
private :
/**
* \ brief Validator number .
*/
size_t m_indice ;
/**
* \ brief Validator name .
*/
std :: string m_ v al id at o rN am e ;
/**
* \ brief Ip interface name .
*/
std :: string m _ i p I n t e r f a c e N a m e ;
/**
* \ brief Nsc use .
*/
std :: string m_nsc ;
/**
* \ brief Number of machines .
*/
size_t m _ m a c hi n e s N u m b e r ;
/**
* \ brief Validator type .
*/
std :: string m_type ;
public :
/**
* \ param indice number of the validator
* \ param type type of the validator ( pc , router , ...)
* \ param namePrefix the prefix name of the validator
* \ param machine sNumber number of machine to create
*/
Validator ( const size_t & indice , const std :: string & type , const std :: string & namePrefix , const
/**
*/
~ Validator ();
/**
* \ brief Generate headers code .
* This function return a vector which contain the header lines from the specified object
* \ return headers code
*/
std :: vector < std :: string > Gen erateHea der ();
/**
* \ brief Generate validator C ++ code .
* This function return a vector which contain the declaration and instanciation of the valida
* \ return validator code
*/
std :: vector < std :: string > G e n e r a t e V a l i d a t o r C p p ();
/**
* \ brief Generate IP stack C ++ code .
* This function return a vector which contain the c ++ code from the Ipv4 stack declaration an
* \ return IP stack code .
*/
std :: vector < std :: string > G e n e r a t e I p S t a c k C p p ();
/**
* \ brief Generate validator python code .
* This function return a vector which contain the declaration and instanciation of the valida
* \ return validator code
*/
std :: vector < std :: string > G e n e r a t e V a l i d a t o r P y t h o n ();
/**
* \ brief Generate IP stack python code .
* This function return a vector which contain the c ++ code from the Ipv4 stack declaration an
* \ return IP stack code .
*/
std :: vector < std :: string > G e n e r a t e I p S t a c k P y t h o n ();
/**
* \ brief Set validator name .
* \ param validatorName validator name
*/
void S e t V a l i d a t o r N a m e ( const std :: string & validatorName );
/**
* \ brief Set ip interface name .
*
* This procedure is used to the the ip In t er fa ce N am e .
* Sometimes this var is used in application like as UdpEcho .
* \ param i pI nt er f ac eN a me ip interface name
*/
void S e t I p I n t e r f a c e N a m e ( const std :: string & ip In t er fa ce N am e );
/**
* \ brief Get validator name .
* \ return validator name
*/
std :: string G e t V a l i d a t o r N a m e ();
/**
* \ brief Get validator name .
* \ param number machine number
* \ return validator name
*/
std :: string G e t V a l i d a t o r N a m e ( const size_t & number );
/**
* \ brief Get ip interface name .
* \ return IP interface name
*/
std :: string G e t I p I n t e r f a c e N a m e ();
/**
* \ brief Get indice .
* \ return indice
*/
std :: string GetIndice ();
/**
* \ brief Set indice .
* \ param indice new indice
*/
void SetIndice ( const size_t & indice );
/**
* \ brief Get NSC ( Network Simulation Cradle ) code .
* \ return nsc code
*/
std :: string GetNsc ();
/**
* \ brief Set NSC ( Network Simulation Cradle ) code .
* \ param nsc new nsc code
*/
void SetNsc ( const std :: string & nsc );
/**
* \ brief Get machines number .
* \ return machines number
*/
size_t G e t M a c h i n e s N u m b e r ();
/**
* \ brief Set machines number .
* \ param machine sNumber new machines number
*/
void S e t M a c h i n e s N u m b e r ( const size_t machin esNumbe r );
/**
* \ brief Get validator type .
* \ return type the validator type
*/
std :: string G e t V a l i d a t o r T y p e ();
};
# endif /* VALIDATOR_H */
B.1.3 Main Window Header
# ifndef MAIN_WINDOW_H
# define MAIN_WINDOW_H
# include < QtGui >
# include " drag - widget . h "

# include " generator . h "
# include " application - dialog . h "
/**
* \ ingroup generator
* \ brief The main window .
*
* This class create the menu , tool bar and the drag ’n ’ drop zone .
*/
class MainWindow : public QMainWindow
{
Q_OBJECT
public :
/**
*/
MainWindow ( const std :: string & simulati onName );
/**
*/
~ MainWindow ();
/**
* \ brief Set generator object .
* \ param gen new generator object
*/
void SetGenerator ( Generator * gen );
/**
* \ brief Get generator object .
* \ return generator object
*/
Generator * GetGenerator ();
/**
* \ brief Procedure to erase the unused iface .
*/
void CleanIface ();
/**
* \ brief Action to delete object .
* Is attribute to setDisable ...
*/
QAction * m_delAction ;
/**
* \ brief Procedure to connect node to linkNumber .
* This procedure prevent mask overflow .
* \ param linkName the destination link name
* \ param nodeName the node name tu be added
*/
void ConnectNode ( const std :: string & linkName , const std :: string & nodeName );
/**
* \ brief Application dialog object
*/
A p p l i c a t i o n D i a l o g * m_appsDialog ;
private :
/**
* \ brief Generator .
*/
Generator * m_gen ;
/**
* \ brief The drag ’n ’ drop zone .
*/
DragWidget * m_dw ;
/**
* \ brief interface which are used .
*/
std :: vector < std :: string > m_listIface ;
private slots :
/**
* \ brief Create PC .
*/
void CreatePc ();
/**
*/
void CreateIoT ();
/**
*/
void CreateBCNode ();
/**
*/
void CreateGateway ();
/**
* \ brief Create group of PCs .
*/
void CreatePcGroup ();
/**
* \ brief Create an " Emu " link .
*/
void CreateEmu ();
/**
* \ brief Create a tap device .
*/
void CreateTap ();
/**
* \ brief Create an access point ( AP ).
*/
void CreateAp ();
/**
* \ brief Create a WI - FI station .
*/
void CreateStation ();
/**
* \ brief Create a hub ( csma link )
*/
void CreateHub ();
/**
* \ brief Create a switch ( bridge )
*/
void CreateSwitch ();
/**
* \ brief Create a router .
*/
void CreateRouter ();
/**
* \ brief Create a wired link from equipement to equipement .
*/
void C re at eW i re dL in k ();
/**
* \ brief Create a link from station to AP .
*/
void CreateWi fiLink ();
/**
* \ brief Procedure to create a p2p link from equipement to equipement .
*/
void CreateP2pLink ();
/**
* \ brief Create applications .
*/
void C r e a t e A p p l i c a t i o n ();
/**
* \ brief Generate the C ++ code .
*/
void GenerateCpp ();
/**
* \ brief Generate the Python code .
*/
void Generate Python ();
/**
* \ brief Procedure called by the tool bar to delete an object .
*/
void DeleteObject ();
/**
* \ brief Show about UI .
*/
void About ();
/**
* \ brief Save simulation as a picture .
*/
void SavePicture ();
/**
* \ brief Save Simulation into xml file .
*/
void SaveXml ();
/**
* \ brief Load xml simulation file .
*/
void LoadXml ();
};
# endif /* MAIN_WINDOW_H */
The entire code is available at Github
B.2 NS3-Simulator
B.2.1 Blockchain Header

/**
* This file contains all the necessary enumerations and structs used throughout the simulation fo
* It also defines 3 very important class ; the Block and Blockchain .
*/
# ifndef BLOCKCHAIN_H
# define BLOCKCHAIN_H

# include <map >
# include " ns3 / address . h "

# include < algorithm >
namespace ns3 {
/**
* The different blockchain message and node message types that have been implemented .
*/
enum Messages
{
INV , //0
GET_HEADERS , //1
HEADERS , //2
GET_BLOCKS , //3
BLOCK , //4
GET_DATA , //5
NO_MESSAGE , //6
SEND_PUBLIC_KEY , //7
RECEIVE_PUBLIC_KEY , //8
RECEIVE_MESSAGE , //9
CREATE_ENTRY , //10
UPDATE_ENTRY , //11
DELETE_ENTRY , //12
};
/**
* The blockchain miner types that have been implemented . The first one is the normal miner ( defau
*/
enum MinerType
{
NORMAL_MINER , // Default Miner to validate new gateways
GATEWAY_MINER // Maintains 2 different blockchains
};
/**
* The different block broadcast types that the node uses to adventize newly formed blocks .
*/
enum B l o c k B r o a d c a s t T y p e
{
STANDARD , // DEFAULT
UNSOLICITED ,
RELAY_NETWORK ,
UNSOLICITED_RELAY_NETWORK
};
/**
* The protocol that the nodes use to advertise new blocks . The S T A N D A R D _ P R O T O C O L ( default ) uses t
* whereas the SENDHEADERS uses HEADERS messages to advertise new blocks .
*/
enum ProtocolType
{
STANDARD_PROTOCOL , // DEFAULT
SENDHEADERS
};
/**
* The different IoT Manufacturers used for the simulation .
*/
enum Manufact urerID
{
SAMSUNG , //0
QUALCOMM , //1
CISCO , //2
ERICSSON , //3
IBM , //4
SILICON , //5
OTHER //6
};
typedef struct {
double downloadSpeed ;
double uploadSpeed ;
} nodeInternetSpeeds ;
typedef struct {
int nodeId ;
int manufac turerId ;
Ipv6Address ipv6Address ;
std :: string nodePublicKey ;
std :: string signature ;
} blockD ataTuple ;
/**
* Fuctions used to convert enumeration values to the corresponding strings .
*/
const char * getMes sageNam e ( enum Messages m );
const char * getMinerType ( enum MinerType m );
const char * g e t B l o c k B r o a d c a s t T y p e ( enum B l o c k B r o a d c a s t T y p e m );
const char * g et P ro to co l Ty pe ( enum ProtocolType m );
const char * g e t M a n u f a c t u r e r I D ( enum Manu facture rID m );
enum Manufact urerID g e t M a n u f a c t u r e r E n u m ( uint32_t n );
class Block
{
public :
// static bloc kDataTup le emptyBlo ckData = {0 , 0 , Ipv6Address ("0::0::0::0") , "" ,""};
Block ( int blockHeight , int minerId , int p a r e n t B l o c k M i n e r I d = 0 , int b lockSize Bytes = 0 ,
double timeCreated = 0 , std :: map < int , blockDataTuple > blockDataMap = std :: map < int ,
Block ();
Block ( const Block & blockSource ); // Copy constructor
virtual ~ Block ( void );
int GetBloc kHeight ( void ) const ;

void S etBlock Height ( int blockHeight );
int GetMinerId ( void ) const ;

void SetMinerId ( int minerId );
int G e t P a r e n t B l o c k M i n e r I d ( void ) const ;

void S e t P a r e n t B l o c k M i n e r I d ( int p a r e n t B l o c k M i n e r I d );
int G e t B l o c k S i z e B y t e s ( void ) const ;

void S e t B l o c k S i z e B y t e s ( int bloc kSizeByt es );
double GetTi meCreate d ( void ) const ;

double G et T im eR ec e iv ed ( void ) const ;
Ipv6Address G e t R e c e i v e d F r o m I p v 6 A d d r e s s ( void ) const ;

void S e t R e c e i v e d F r o m I p v 6 A d d r e s s ( Ipv6Address r e c e i v e d F r o m I p v 6 A d d r e s s );
bloc kDataTup le GetNodeData ( int nodeId );

void SetNodeData ( int nodeId , blockD ataTuple blockData );
/**
* Checks if the block provided as the argument is the parent of this block object
*/
bool IsParent ( const Block & block ) const ;
/**
* Checks if the block provided as the argument is a child of this block object
*/
bool IsChild ( const Block & block ) const ;
Block & operator = ( const Block & blockSource ); // Assignment Constructor
friend bool operator == ( const Block & block1 , const Block & block2 );
friend std :: ostream & operator < < ( std :: ostream & out , const Block & block );
protected :
int m_blockHeight ; // The height of the block
int m_minerId ; // The id of the miner which mined this block
int m _ p a r e n t B l o c k M i n e r I d ; // The id of the miner which mined the parent of thi
int m_ b l o c k S i z e B y t e s ; // The size of the block in bytes
double m_timeCreated ; // The time the block was created
double m_tim eReceive d ; // The time the block was received from the node
Ipv6Address m _ r e c e i v e d F r o m I p v 6 A d d r e s s ; // The Ipv6Address of the node which sent the
std :: map < int , blockDataTuple > m_bl ockData Map ; // Map containing all the data fo
};
class Blockchain
{
public :
Blockchain ( void );
virtual ~ Blockchain ( void );
int G e t N o S t a l e B l o c k s ( void ) const ;
int GetNoOrphans ( void ) const ;
int GetTota lBlocks ( void ) const ;
int G e t B l o c k c h a i n H e i g h t ( void ) const ;
/**
* Check if the block has been included in the blockchain .
*/
bool HasBlock ( const Block & newBlock ) const ;
bool HasBlock ( int height , int minerId ) const ;
/**
* Get the nodes ’ public key , its ’ signature and validate its ’ signature
**/
// std :: string GetPublickey ( int nodeId );
// Block G e t P u b l i c k e y B l o c k ( int nodeId );
// std :: string G e t N o d e P u b l i c K e y S i g n a t u r e ( int nodeId );
// bool C h e c k P u b l i c K e y S i g n a t u r e ( int nodeId );
/**
* Return the block with the specified height and minerId .
* Should be called after HasBlock () to make sure that the block exists .
* Returns the orphan blocks too .
*/
Block ReturnBlock ( int height , int minerId );
/**
* Check if the block is an orphan .
*/
bool IsOrphan ( const Block & newBlock ) const ;
bool IsOrphan ( int height , int minerId ) const ;
/**
* Gets a pointer to the block .
*/
const Block * G e tB lo ck P oi nt er ( const Block & newBlock ) const ;
/**
* Gets the children of a block that are not orphans .
*/
const std :: vector < const Block * > G e t C h i l d r e n P o i n t e r s ( const Block & block );
/**
* Gets the children of a newBlock that used to be orphans before receiving the newBlock .
*/
const std :: vector < const Block * > G e t O r p h a n C h i l d r e n P o i n t e r s ( const Block & newBlock );
/**
* Gets the parent of a block
*/
const Block * GetParent ( const Block & block ); // Get the parent of newBlock
/**
* Gets the current top block . If there are two block with the same height ( siblings ) , ret
*/
const Block * G e t C u r r e n t T o p B l o c k ( void ) const ;
/**
* Adds a new block in the blockchain .
*/
void AddBlock ( const Block & newBlock );
/**
* Adds a new orphan block in the blockchain .
*/
void AddOrphan ( const Block & newBlock );
/**
* Removes a new orphan block in the blockchain .
*/
void RemoveOrphan ( const Block & newBlock );
/**
* Prints all the currently orphan blocks .
*/
void PrintOrphans ( void );
/**
* Gets the total number of blocks in forks .
*/
int G e t B l o c k s I n F o r k s ( void );
/**
* Gets the longest fork size
*/
int G e t L o n g e s t F o r k S i z e ( void );
// void c ha ng eP u bl ic K ey ( Block & Block , std :: string newPublicKey );

// void c ha ng eP u bl ic K ey ( int nodeId , std :: string newPublicKey );
friend std :: ostream & operator < < ( std :: ostream & out , Blockchain & blockchain );
private :
int m _n oS t al eB lo c ks ; // total number of stale blocks
int m_totalBlocks ; // total number of blocks including the g

std :: vector < std :: vector < Block > > m_blocks ; //2 d vector containing all the blocks of
std :: vector < Block > m_orphans ; // vector containing the orphans
// std :: map < int , Block > m_block_map ; // map containing the nodeId to block mappi
// std :: map < int , std :: string > m _ p u b l i c _ k e y _ m a p ; // direct map containing mapping of node
};
} // Namespace ns3
# endif /* BLOCKCHAIN_H */
B.2.2 Blockchain Node Header

/**
* This file contains declares the simple Block chainNo de class .
*/
# ifndef B L O C K C H A I N _ N O D E _ H
# define B L O C K C H A I N _ N O D E _ H
# include < algorithm >

# include " ns3 / application . h "
# include " ns3 / event - id . h "
# include " ns3 / ptr . h "
# include " ns3 / traced - callback . h "
# include " blockchain . h "
# include " ns3 / boolean . h "
# include "../../ rapidjson / document . h "
# include "../../ rapidjson / writer . h "
# include "../../ rapidjson / stringbuffer . h "
namespace ns3 {
class Address ;
class Socket ;
class Packet ;
class Bl ockchain Node : public Application

{
public :
/**
* \ brief Get the type ID .
* \ return the object TypeId
*/
static TypeId GetTypeId ( void );
Bloc kchainNo de ( void );
virtual ~ B lockchai nNode ( void );
/**
* \ return pointer to listening socket
*/
Ptr < Socket > G e t L i s t e n i n g S o c k e t ( void ) const ;
/**
* \ return a vector containing the addresses of peers
*/
std :: vector < Ipv6Address > G e t P e e r s A d d r e s s e s ( void ) const ;
/**
* \ brief Set the addresses of peers
* \ param peers the reference of a vector containing the Ipv6 addresses of peers
*/
void S e t P e e r s A d d r e s s e s ( const std :: vector < Ipv6Address > & peers );
/**
* \ brief set the download speeds of peers
* \ param p e e r s D o w n l o a d S p e e d s the reference of a map containing the Ipv6 addresses of peers and
*/
void S e t P e e r s D o w n l o a d S p e e d s ( const std :: map < Ipv6Address , double > & p e e r s D o w n l o a d S p e e d s );
/**
* \ brief Set the upload speeds of peers
* \ param p e e r s U p l o a d S p e e d s the reference of a map containing the Ipv6 addresses of peers and th
*/
void S e t P e e r s U p l o a d S p e e d s ( const std :: map < Ipv6Address , double > & p e e r s U p l o a d S p e e d s );
/**
* \ brief Set the internet speeds of the node
* \ param interne tSpeeds a struct containing the download and upload speed of the node
*/
void S e t N o d e I n t e r n e t S p e e d s ( const n o d e I n t e r n e t S p e e d s & inter netSpee ds );
/**
* \ brief Set the node statistics
* \ param nodeStats a reference to a nodeS tatistic s struct
*/
void SetNodeStats ( nodeS tatistic s * nodeStats );
/**
* \ brief Set the protocol type ( default : S T A N D A R D _ P R O T O C O L )
* \ param protocolType the type of protocol used for advertising new blocks
*/
void S et Pr ot o co lT yp e ( enum ProtocolType protocolType );
protected :
virtual void DoDispose ( void ); // inherited from Application base class .
virtual void S t a r t A p p l i c a t i o n ( void ); // Called at time specified by Start

virtual void S to pA pp l ic at io n ( void ); // Called at time specified by Stop
/**
* \ brief Handle a packet received by the application
* \ param socket the receiving socket
*/
void HandleRead ( Ptr < Socket > socket );
/**
* \ brief Handle an incoming connection
* \ param socket the incoming connection socket
* \ param from the address the connection is from
*/
void HandleAccept ( Ptr < Socket > socket , const Address & from );
/**
* \ brief Handle an connection close
* \ param socket the connected socket
*/
void H an dl eP e er Cl os e ( Ptr < Socket > socket );
/**
* \ brief Handle an connection error
* \ param socket the connected socket
*/
void H an dl eP e er Er ro r ( Ptr < Socket > socket );
/**
* \ brief Handle an incoming BLOCK Message .
* \ param blockInfo the block message info
* \ param from the address the connection is from
*/
void R e c e i v e d B l o c k M e s s a g e ( std :: string & blockInfo , Address & from );
/**
* \ brief Called when a new block non - orphan block is received
* \ param newBlock the newly received block
*/
virtual void ReceiveBlock ( const Block & newBlock );
/**
* \ brief Sends a BLOCK message as a response to a GET_DATA message
* \ param packetInfo the info of the BLOCK message
* \ param from the address the GET_DATA was received from
*/
void SendBlock ( std :: string packetInfo , Address & from );
/**
* \ brief Called for blocks with higher score ( height )
* \ param newBlock the new block with higher score
*/
virtual void R e c e i v e d H i g h e r B l o c k ( const Block & newBlock );
/**
* \ brief Validates new Blocks by calculating the necessary time interval
* \ param newBlock the new block
*/
void ValidateBlock ( const Block & newBlock );
/**
* \ brief Adds the new block in to the blockchain , advertises it to the peers and validates any
*/
void A f t e r B l o c k V a l i d a t i o n ( const Block & newBlock );
/**
* \ brief Validates any ophan children of the newly received block
*/
void V a l i d a t e O r p h a n C h i l d r e n ( const Block & newBlock );
/**
* \ brief Advertises the newly validated block
*/
void A d v e r t i s e N e w B l o c k ( const Block & newBlock );
/**
* \ brief Advertises the newly validated block when blockTorrent is used
*/
void A d v e r t i s e F u l l B l o c k ( const Block & newBlock );
/**
* \ brief Sends a message to a peer
* \ param r ec ei ve d Me ss ag e the type of the received message
* \ param r es po ns e Me ss ag e the type of the response message
* \ param d the rapidjson document containing the info of the outgoing message
* \ param outgoing Socket the socket of the peer
*/
void SendMessage ( enum Messages receivedMessage , enum Messages responseMessage , rapidjson :: Docum
/**
* \ param d the rapidjson document containing the info of the outgoing message
* \ param o ut go in g Ad dr e ss the Address of the peer
*/
void SendMessage ( enum Messages receivedMessage , enum Messages responseMessage , rapidjson :: Docum
/**
* \ param packet a string containing the info of the outgoing message
* \ param o ut go in g Ad dr es s the Address of the peer
*/
void SendMessage ( enum Messages receivedMessage , enum Messages responseMessage , std :: string pack
/**
* \ brief Print m_queueInv to stdout
*/
void PrintQueueInv ();
/**
* \ brief Print m_invTimeouts to stdout
*/
void P r i n t I n v T i m e o u t s ();
/**
* \ brief Print m _ o n l y H e a d e r s R e c e i v e d to stdout
*/
void P r i n t O n l y H e a d e r s R e c e i v e d ();
/**
* \ brief Called when a timeout for a block expires
* \ param blockHash the block hash for which the timeout expired
*/
void I n v T i m e o u t E x p i r e d ( std :: string blockHash );
/**
* \ brief Checks if a block has been received but not been validated yet ( if it is included in m
* \ param blockHash the block hash
* \ return true if the block has been received but not validated yet , false otherwise
*/
bool R e c e i v e d B u t N o t V a l i d a t e d ( std :: string blockHash );
/**
* \ brief Removes a block from m _ r e c e i v e d N o t V a l i d a t e d
*/
void R e m o v e R e c e i v e d B u t N o t V a l i d a t e d ( std :: string blockHash );
/**
* \ brief Checks if the node has received only the headers of a particular block ( if it is inclu
* \ return true if only the block headers have been received , false otherwise
*/
bool O n l y H e a d e r s R e c e i v e d ( std :: string blockHash );
/**
* \ brief Removes the fist element from m_sendBlockTimes , when a block is sent
*/
void RemoveSe ndTime ();
/**
* \ brief Removes the fist element from m_sendCompressedBlockTimes , when a compressed - block is s
*/
void R e m o v e C o m p r e s s e d B l o c k S e n d T i m e ();
/**
* \ brief Removes the fist element from m_receiveBlockTimes , when a block is received
*/
void R e m o v e R e c e i v e T i m e ();
/**
* \ brief Removes the fist element from m_r ec eiv eCo mpr es sed Blo ckT ime s , when a compressed - block i
*/
void R e m o v e C o m p r e s s e d B l o c k R e c e i v e T i m e ();
// In the case of TCP , each socket accept returns a new socket , so the
// listening socket is stored separately from the accepted sockets
Ptr < Socket > m_socket ; //! < Listening socket
Address m_local ; //! < Local address to bind to
TypeId m_tid ; //! < Protocol TypeId
int m _n u mb er Of P ee rs ; //! < Number of node ’ s peers
double m_meanBlockReceiveTime ; //! < The mean time interval between
double m_previousBlockReceiveTime ; //! < The time that the node received
double m_meanBlockPropagationTime ; //! < The mean time that the node has
double m _m ea n Bl oc kS i ze ; //! < The mean block size
Blockchain m_blockchain ; //! < The node ’ s blockchain
Time m_invTimeoutMinutes ; //! < The block timeout in minutes
bool m_isMiner ; //! < True if the node is also a miner , False
double m _d ow nl o ad Sp ee d ; //! < The download speed of the node in Bytes
double m_uploadSpeed ; //! < The upload speed of the node in Bytes / s
double m_averageTransactionSize ; //! < The average transaction size . Needed fo
int m_transactionIndexSize ; //! < The transaction index size in bytes . Ne
bool m_b lockTor rent ; //! < True if the blockTorrent mechanism is u
uint32_t m_chunkSize ; //! < The size of the chunk in Bytes , when bl
bool m_spv ; //! < Simplified Payment Verification . Used o
std :: vector < Ipv6Address > m _ p e e r s A d dr e s s e s ; //! < The a

std :: map < Ipv6Address , double > m_peersDownloadSpeeds ; //! < The p
std :: map < Ipv6Address , double > m_peersUploadSpeeds ; //! < The p
std :: map < Ipv6Address , Ptr < Socket > > m_ peersSoc kets ; //! < The s
std :: map < std :: string , std :: vector < Address > > m_queueInv ; //! < map h
std :: map < std :: string , std :: vector < Address > > m_queueChunkPeers ; //! < map h
std :: map < std :: string , std :: vector < int > > m_queueChunks ; //! < map h
std :: map < std :: string , std :: vector < int > > m _ r e ce i v e d C h u n k s ; //! < map h
std :: map < std :: string , EventId > m_invTimeouts ; //! < map h
std :: map < std :: string , EventId > m _c hu nk T im eo ut s ; //! < map h
std :: map < Address , std :: string > m_buffer edData ; //! < map h
std :: map < std :: string , Block > m_receivedNotValidated ; //! < vecto
std :: map < std :: string , Block > m_onlyHeadersReceived ; //! < vecto
node Statisti cs * m_nodeStats ; //! < struc
std :: vector < double > m_sendBlockTimes ; //! < conta
std :: vector < double > m_sendCompressedBlockTimes ; //! < conta
std :: vector < double > m_receiveBlockTimes ; //! < conta
std :: vector < double > m_receiveCompressedBlockTimes ; //! < conta
enum ProtocolType m_p rotocolT ype ; //! < proto
const int m_blockchainPort ; //! < 5555

const int m _s ec on d sP er Mi n ; //! < 60
const int m_countBytes ; //! < The size of count variable in messages , 4 Byte
const int m_bitcoinMessageHeader ; //! < The size of the Message Header , 90 Bytes , incl
const int m_inventorySizeBytes ; //! < The size of inventories in INV messages , 36 By
const int m_getHeadersSizeBytes ; //! < The size of the GET_HEADERS message , 72 Bytes
const int m_headersSizeBytes ; //! < 81 Bytes
const int m_blockHeadersSizeBytes ; //! < 81 Bytes
/// Traced Callback : received packets , source address .

TracedCallback < Ptr < const Packet > , const Address & > m_rxTrace ;
};
} // namespace ns3
# endif /* B L O C K C H A I N _ N O D E _ H */
B.2.3 Blockchain Validator Header

# ifndef B L O C K C H A I N _ V A L I D A T O R _ H
# define B L O C K C H A I N _ V A L I D A T O R _ H
# include " blockchain - node . h "

# include < random >
namespace ns3 {
class Address ;
class Socket ;
class Packet ;
/**
* \ ingroup packetsink
* \ defgroup packetsink PacketSink
* \ brief Receive and consume traffic generated to an IP address and port

*
* This application was written to complement OnOffApplication , but it
* is more general so a PacketSink name was selected . Functionally it is
* important to use in multicast situations , so that reception of the layer -2
* multicast frames of interest are enabled , but it is also useful for
* unicast as an example of how you can write something simple to receive
* packets at the application layer . Also , if an IP stack generates
* ICMP Port Unreachable errors , receiving applications will be needed .
*
* The constructor specifies the Address ( IP address and port ) and the
* transport protocol to use . A virtual Receive () method is installed
* as a callback on the receiving socket . By default , when logging is
* enabled , it prints out the size of packets and their address .
* A tracing source to Receive () is also available .
*/
class B l o c k c h a i n V a l i d a t o r : public Bl ockchai nNode
{
public :
/**
*/
B l o c k c h a i n V a l i d a t o r ();
virtual ~ B l o c k c h a i n V a l i d a t o r ( void );
/**
* \ return fixed Block Time Generation
*/
double G e t F i x e d B l o c k T i m e G e n e r a t i o n ( void ) const ;
/**
* Set fixed Block Time Generation
*/
void S e t F i x e d B l o c k T i m e G e n e r a t i o n ( double f i x e d B l o c k T i m e G e n e r a t i o n );
/**
* \ return fixed Block Size
*/
uint32_t G e t F i x e d B l o c k S i z e ( void ) const ;
/**
* Set fixed Block Size
*/
void S e t F i x e d B l o c k S i z e ( uint32_t fix edBlockS ize );
/**
* \ return fixed Block Generation binSize
*/
double G e t B l o c k G e n B i n S i z e ( void ) const ;
/**
* Set fixed Block Generation binSize
*/
void S e t B l o c k G e n B i n S i z e ( double m _ b l o c k G e n B i n S i z e );
/**
* \ return fixed Block Generation binSize
*/
double G e t B l o c k G e n P a r a m e t e r ( void ) const ;
/**
* Set fixed Block Generation binSize
*/
void S e t B l o c k G e n P a r a m e t e r ( double b l o c k G e n P a r a m e t e r );
/**
* \ return fixed hash rate
*/
double GetHashRate ( void ) const ;
/**
* Set fixed hash rate
*/
void SetHashRate ( double b l o c k G e n P a r a m e t e r );
/**
* set the type of block broadcast
*/
void S e t B l o c k B r o a d c a s t T y p e ( enum B l o c k B r o a d c a s t T y p e b l o c k B r o a d c a s t T y p e );
protected :
// inherited from Application base class .
virtual void S t a r t A p p l i c a t i o n ( void ); // Called at time specified by Start
virtual void S to pA pp l ic at io n ( void ); // Called at time specified by Stop
virtual void DoDispose ( void );
/**
* \ brief Schedule the next mining event
*/
void S c h e d u l e N e x t M i n i n g E v e n t ( void );
/**
* \ brief Validates a new block and advertises it to its peers
*/
virtual void ValidateBlock ( void );
/**
* \ brief Called for blocks with better score ( height ). Removes m _ n e x t M i n i n g E v e n t and call Valida
* \ param newBlock the new block which was received
*/
virtual void R e c e i v e d H i g h e r B l o c k ( const Block & newBlock );
/**
* \ brief Sends a BLOCK message as a response to a GET_DATA message
* \ param packetInfo the info of the BLOCK message
* \ param to the socket of the receiving peer
*/
void SendBlock ( std :: string packetInfo , Ptr < Socket > to );
int m_noMiners ;
uint32_t m_fixedBlockSize ;
double m_fixedBlockTimeGeneration ; //! < Fixed Block Time Generation
EventId m_nextMiningEvent ; //! < Event to mine the next block
std :: d e f a u l t _ r a n d o m _ e n g i n e m_generator ;
/**
* The m _ b l o c k G e n B i n S i z e states binSize of the block generation time .
* In the paper " Misbehaviour In Bitcoin " is stated when the binSize is 2 mins the parameter is 0
* According to that we calculate the the new parameter as 0.183* m _ b l o c k G e n B i n S i z e /2 to achieve
*/
double m_blockGenBinSize ;
double m_blockGenParameter ; //! < The block generation distribu
double m _n ex tB l oc kT im e ;
double m_previousBlockGenerationTime ;
double m_minerAverageBlockGenInterval ;
int m_minerGeneratedBlocks ;
double m_hashRate ;
std :: geometric_distribution < int > m _ b l o c k G e n T i m e D i s t r i b u t i o n ;
int m _n ex t Bl oc kS i ze ;
int m_maxB lockSize ;
double m_minerAverageBlockSize ;
std :: p i e ce w i se _ c on s t a nt _ d is t ri bu t i on < double > m_blockSizeDistribution ;
const double m_realAverageBlockGenIntervalSeconds ; //! < in seconds , 10 mins

double m_averageBlockGenIntervalSeconds ; //! < the new m _ a v e r a g e B l o c k G e n I n t e r v a l we s
enum B l o c k B r o a d c a s t T y p e m_blockBroadcastType ; //! < the type of broadcast
// debug
double m_timeStart ;
double m_timeFinish ;
bool m_fistToMine ;
};
} // namespace ns3
# endif /* B L O C K C H A I N _ V A L I D A T O R _ H */
B.2.4 IoT Sensor Node Header

# ifndef I O T _ S E N S O R _ N O D E _ H
# define I O T _ S E N S O R _ N O D E _ H
# include " ns3 / application . h "

# include " ns3 / event - id . h "
# include " ns3 / ptr . h "
# include " ns3 / ipv6 - address . h "
# include " ns3 / core - module . h "
# include " ns3 / internet - module . h "
# include " ns3 / csma - module . h "
# include " ns3 / internet - apps - module . h "
# include " ns3 / ipv6 - static - routing - helper . h "
# include " ns3 / ipv6 - routing - table - entry . h "
# include " ns3 / sixlowpan - module . h "
# include " ns3 / blockchain . h "
# include "../../ rapidjson / document . h "
# include "../../ rapidjson / writer . h "
# include "../../ rapidjson / stringbuffer . h "
# include < crypto ++/ rsa .h >
# include < crypto ++/ aes .h >
# include < crypto ++/ osrng .h >
namespace ns3 {
class Address ;
class Socket ;
class Packet ;
class IotSensorNode : public Application

{
public :
/**
*/
IotSensorNode ();
IotSensorNode ( CryptoPP :: RSA :: Publi
virtual ~ IotSensorNode ();
/**
* \ return pointer to listening so

*/
Ptr < Socket > G e t L i s t e n i n g S o c k e t ( vo
/**
* \ return a vector containing the
*/
std :: vector < Ipv6Address > G e t P e e r s A
/**
* \ return the node ’ s public key
*/
CryptoPP :: RSA :: PublicKey GetPublic
/**
* \ return the node ’ s public key
*/
CryptoPP :: RSA :: PrivateKey GetPriva
/**
* \ return the node ’ s gateway publ
*/
CryptoPP :: RSA :: PublicKey G e t G a t e w a
/**
* \ brief Revoke and change the no
* \ param new private key and
*/
void SetNewKeys ( CryptoPP :: RSA :: Pr
/**
* \ brief Update the node ’ s gatewa
* \ param new public key of t
*/
void S e t G a t e w a y P u b l i c k e y ( CryptoP
/**
* \ brief Set the addresses of pee
* \ param peers the reference of a
*/
void S e t P e e r s A d d r e s s e s ( const std :
/**
* \ brief adds a peer to the set o
* \ param newPeer address of the p
**/
void AddPeer ( Ipv6Address newPeer )
/**
* \ brief set the download speeds
* \ param p e e r s D o w n l o a d S p e e d s the
*/
void S e t P e e r s D o w n l o a d S p e e d s ( const
/**
* \ brief Set the upload speeds of
* \ param p e e r s U p l o a d S p e e d s the re
*/
void S e t P e e r s U p l o a d S p e e d s ( const s
/**
* \ brief Set the internet speeds
* \ param internet Speeds a struct
*/
void S e t N o d e I n t e r n e t S p e e d s ( const
/**
* \ brief Set the node statistics
* \ param nodeStats a reference to
*/
void SetNodeStats ( nodeSt atistic s
/**
* \ brief Set the protocol type ( de
* \ param protocolType the type of
*/
void S et Pr ot o co lT yp e ( enum Protoco
/**
* \ brief Sends a message to a pee
* \ param r ec ei ve d Me ss ag e the type
* \ param r es po ns e Me ss ag e the type
* \ param d the rapidjson document
* \ param outgoing Socket the socke
*/
void SendMessage ( enum Messages rec
/**
* \ param d the rapidjson document
* \ param o ut go in g Ad dr es s the Addr
*/
/**
* \ param packet a string containi
* \ param o ut go in g Ad dr es s the Addr
*/
/**
* \ param o u t g o i n g I p v 6 A d d r e s s the
*/
/**
* \ param outgoing Socket the socke
*/
protected :
// inherited from Application base
virtual void S t a r t A p p l i c a t i o n ( voi
virtual void S to pA p pl ic at i on ( void
virtual void DoDispose ( void );
/**
* \ brief Handle a packet received
* \ param socket the receiving soc
*/
void HandleRead ( Ptr < Socket > socke
/**
* \ brief Handle an incoming conne
* \ param socket the incoming conn
* \ param from the address the con
*/
void HandleAccept ( Ptr < Socket > soc
/**
* \ brief Handle an connection clo
* \ param socket the connected soc
*/
void H an dl eP e er Cl os e ( Ptr < Socket >
/**
* \ brief Handle an connection err
* \ param socket the connected soc
*/
void H an dl eP e er Er ro r ( Ptr < Socket >
/**
* \ brief Check signature integrit
* \ param message message to check
* \ param sign signature of the me

**/
bool checkSign ( std :: string messag
/**
* \ brief Check signature integrit
* \ param message message to check
* \ param sign signature of the me
* \ param sender address of the me
**/
bool checkSign ( std :: string messag
/**
* \ brief decrypt a encrypted mess
* \ param message message to be de
**/
std :: string decrypt ( std :: string m
/**
* \ brief encrypt a message to be
* \ param message message to be en
* \ param PublicKey public key of
**/
std :: string encrypt ( std :: string m
/**
* \ param receiver receiver ’ s ip a
* \ param type of encryption - aes
**/
/**
* \ param aes_key AES session key
* \ param iv IV for the aes
**/
private :
// In the case of TCP , each socket

// listening socket is stored sepa
Ptr < Socket > m_socket ;
Address m_local ;
TypeId m_tid ;
int m _n um be r Of Pe e rs ;
int m _g at ew a yN od e Id ; /
Ipv6Address m _ g a t e w a y A d d r e s s ; //!
double m _ do wn lo a dS pe ed ;
double m_uploadSpeed ;
CryptoPP :: RSA :: PrivateKey m_privat
CryptoPP :: A u t o S e e d e d R a n d o m P o o l m_p
CryptoPP :: RSA :: PublicKey m_publicK

CryptoPP :: RSA :: PublicKey m _ g a t e w a y
std :: vector < Ipv6Address >

std :: map < Ipv6Address , double >
std :: map < Ipv6Address , Ptr < Socket >
std :: map < Address , std :: string >
std :: map < Ipv6Address , CryptoPP :: RS
std :: map < Ipv6Address , byte [16] > m _
std :: map < Ipv6Address , byte [16] > m _
std :: map < Ipv6Address , std :: vector <
nodeS tatisti cs
enum ProtocolType m_proto colType ;
const int m_commPort ;

const int m_ s ec on ds P er Mi n ;
/// Traced Callback : received pack

TracedCallback < Ptr < const Packet > ,
};
} // namespace ns3
# endif /* I O T _ S E N S O R _ N O D E _ H */
B.2.5 IoT Layer Topology Helper Header

/* -* - Mode : C ++; c - file - style :" gnu "; indent - tabs - mode : nil ; -* - */
/*
* This program is free software ; you can redistribute it and / or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation ;
*
* This program is distributed in the hope that it will be useful ,
* but WITHOUT ANY WARRANTY ; without even the implied warranty of
* M ER C HA NT AB I LI TY or FITNESS FOR A PARTICULAR PURPOSE . See the
* GNU General Public License for more details .
*
* You should have received a copy of the GNU General Public License
* along with this program ; if not , write to the Free Software
* Foundation , Inc . , 59 Temple Place , Suite 330 , Boston , MA 02111 -1307 USA
*
* Author : Saptarshi Gan < sapedu1 1@gmail . com >
*/
# ifndef I O T _ L A Y E R _ T O P O L O G Y _ H E L P E R _ H
# define I O T _ L A Y E R _ T O P O L O G Y _ H E L P E R _ H
# include " internet - stack - helper . h "

# include " point - to - point - helper . h "
# include " ipv4 - address - helper . h "
# include " ipv4 - interface - container . h "
# include " net - device - container . h "
# include " ipv6 - address - helper - custom . h "
namespace ns3 {
/**
* \ ingroup point - to - point - layout
*
* \ brief A helper to make it easier to create the discussed layer topology
* with p2p links
*/
class I o T L a y e r T o p o l o g y H e l p e r
{
public :
/**
* Create a I o T L a y e r T o p o l o g y H e l p e r in order to easily create
* discussed layer topology with p2p links
*
*/
I o T L a y e r T o p o l o g y H e l p e r ( uint32_t noCpus , uint32_t totalNoNodes , enum Manu facture rID * manufacture
int minConnectionsPerNode , int maxConnectionsPerNode ,
double latencyParetoShapeDivider , uint32_t systemId , std :: vector < uint32_t
~ I o T L a y e r T o p o l o g y H e l p e r ();
Ptr < Node > GetNode ( uint32_t id );
/**
* This returns an Ipv6 address at the node specified by
* the ( row , col ) address . Technically , a node will have
* multiple interfaces in the grid ; therefore , it also has
* multiple Ipv6 addresses . This method only returns one of
* the addresses . If you picture the grid , the address returned

* is the left row device of all the nodes , except the left - most
* grid nodes , which returns the right row device .
*
* \ param row the row address of the node desired
*
* \ param col the column address of the node desired
*
* \ returns Ipv6Address of one of the interfaces of the node
* specified by the ( row , col ) address
*/
Ipv6Address GetIpv6 Address ( uint32_t row , uint32_t col );
/**
* \ param stack an I n t e r n e t S t a c k H e l p e r which is used to install
* on every node in the grid
*/
void InstallStack ( I n t e r n e t S t a c k H e l p e r stack );
/**
* Assigns Ipv6 addresses to all the row and column interfaces
*
* \ param ip the I p v 6 A d d r e s s H e l p e r used to assign Ipv6 addresses
* to all of the row interfaces in the grid
*
*/
void A s s i g n I p v 6 A d d r e s s e s ( I p v 6 A d d r e s s H e l p e r C u s t o m ip );
/**
* Sets up the node canvas locations for every node in the grid .
* This is needed for use with the animation interface
*
* \ param ulx upper left x value
* \ param uly upper left y value
* \ param lrx lower right x value
* \ param lry lower right y value
*/
void BoundingBox ( double ulx , double uly , double lrx , double lry );
/**
* Get the interface container
*/
I p v 6 I n t e r f a c e C o n t a i n e r G e t I p v 6 I n t e r f a c e C o n t a i n e r ( void ) const ;
std :: map < uint32_t , std :: vector < Ipv6Address > > G e t N o d e s C o n n e c t i o n s I p s ( void ) const ;
std :: vector < uint32_t > GetValidators ( void ) const ;

uint32_t * G e t B l o c k c h a i n N o d e s R e g i o n s ( void );
std :: map < uint32_t , std :: map < Ipv6Address , double > > G e t P e e r s D o w n l o a d S p e e d s ( void ) const ;
std :: map < uint32_t , std :: map < Ipv6Address , double > > G e t P e e r s U p l o a d S p e e d s ( void ) const ;
std :: map < uint32_t , nodeInternetSpeeds > G e t N o d e s I n t e r n e t S p e e d s ( void ) const ;
private :
void AssignRegion ( uint32_t id );

void A s s i g n I n t e r n e t S p e e d s ( uint32_t id );
uint32_t m_tot alNoNod es ; //! < The total number of nodes

uint32_t m_noV alidato rs ; //! < The total number of validators
uint32_t m_noCpus ; //! < The number of the available cpus in the simul
double m_latencyParetoShapeDivider ; //! < The pareto shape for the latency of the poin
int m_minConnectionsPerNode ; //! < The minimum connections per node
int m_maxConnectionsPerNode ; //! < The maximum connections per node
int m_minConnectionsPerValidator ; //! < The minimum connections per node
int m_maxConnectionsPerValidator ; //! < The maximum connections per node
double m_validatorDownloadSpeed ; //! < The download speed of validators
double m_validatorUploadSpeed ; //! < The upload speed of validators
uint32_t m_tot alNoLin ks ; //! < Total number of links
uint32_t m_systemId ;
enum Manufact urerID * m _m an u fa ct ur e rs ;

std :: vector < uint32_t > m_validators ; //! < The ids of t
std :: map < uint32_t , std :: vector < uint32_t > > m_nodesConnections ; //! < key = nodeId
std :: map < uint32_t , std :: vector < Ipv6Address > > m_nodesConnectionsIps ; //! < key = nodeId
std :: map < uint32_t , std :: vector < uint32_t > > m_nodeGatewayMap ; //! < key = nodeId
std :: map < uint32_t , uint32_t > m_gatewayValidatorMap ; //! < key = nodeId
std :: map < uint32_t , std :: vector < uint32_t > > m_validatorLinkMap ; //! < key = nodeId
std :: vector < NodeContainer > m_nodes ; //! < all the nodes in
std :: vector < NetDeviceContainer > m_devices ; //! < NetDevices in th
std :: vector < Ipv6InterfaceContainer > m_interfaces ; //! < Ipv6 interfaces
uint32_t * m_blockchainNodesRegion ; //! < The region in
double m _ r e g i o n L a t e n c i e s [6][6]; //! < The inter - and i
double m _ r e g i o n D o w n l o a d S p e e d s [6];
double m _ r e g i o n U p l o a d S p e e d s [6];
std :: map < uint32_t , std :: map < Ipv6Address , double > > m_peersDownloadSpeeds ; //! < key1 = node
std :: map < uint32_t , std :: map < Ipv6Address , double > > m_peersUploadSpeeds ; //! < key1 = node
std :: map < uint32_t , nodeInternetSpeeds > m_nodesInternetSpeeds ; //! < key = nodeI
std :: map < uint32_t , int > m _ m i n C o n n e c t i on s ; //! < key = nodeI
std :: map < uint32_t , int > m _ m a x C o n n e c t i on s ; //! < key = nodeI
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_nodesDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_connectionsDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_europeDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_europeUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_northAmericaDownloadBandwidthDistribution ;

std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_northAmericaUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_asiaPacificDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_asiaPacificUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_africaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_africaUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_southAmericaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_southAmericaUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_australiaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_australiaUploadBandwidthDistribution ;
};
} // namespace ns3
# endif /* B L O C K C H A I N _ T O P O L O G Y _ H E L P E R _ H */
B.2.6 IoT Flat Topology Helper Header

/* -* - Mode : C ++; c - file - style :" gnu "; indent - tabs - mode : nil ; -* - */
/*
* This program is free software ; you can redistribute it and / or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation ;
*
* This program is distributed in the hope that it will be useful ,
* but WITHOUT ANY WARRANTY ; without even the implied warranty of
* M ER C HA NT AB I LI TY or FITNESS FOR A PARTICULAR PURPOSE . See the
* GNU General Public License for more details .
*
* You should have received a copy of the GNU General Public License
* along with this program ; if not , write to the Free Software
* Foundation , Inc . , 59 Temple Place , Suite 330 , Boston , MA 02111 -1307 USA
*
* Author : Saptarshi Gan < sapedu1 1@gmail . com >
*/
# ifndef I O T _ F L A T _ T O P O L O G Y _ H E L P E R _ H
# define I O T _ F L A T _ T O P O L O G Y _ H E L P E R _ H
# include " internet - stack - helper . h "

# include " point - to - point - helper . h "
# include " net - device - container . h "

# include " ipv6 - address - helper - custom . h "
namespace ns3 {
/**
* \ ingroup point - to - point - layout
*
* \ brief A helper to make it easier to create the discussed flat direct topology
* with p2p links
*/
class I o T F l a t T o p o l o g y H e l p e r
{
public :
/**
* Create a I o T F l a t T o p o l o g y H e l p e r in order to easily create
* discussed flat direct topology with p2p links
*
*/
I o T F l a t T o p o l o g y H e l p e r ( uint32_t noCpus , uint32_t totalNoNodes , enum Manu facture rID * manufacturer
int minConnectionsPerNode , int maxConnectionsPerNode ,
double latencyParetoShapeDivider , uint32_t systemId , std :: vector < uint32_t
~ I o T F l a t T o p o l o g y H e l p e r ();
Ptr < Node > GetNode ( uint32_t id );
/**
* This returns an Ipv6 address at the node specified by
* the ( row , col ) address . Technically , a node will have
* multiple interfaces in the grid ; therefore , it also has
* multiple Ipv6 addresses . This method only returns one of
* the addresses . If you picture the grid , the address returned
* is the left row device of all the nodes , except the left - most
* grid nodes , which returns the right row device .
*
* \ param row the row address of the node desired
*
* \ param col the column address of the node desired
*
* \ returns Ipv6Address of one of the interfaces of the node
* specified by the ( row , col ) address
*/
Ipv6Address GetIpv6 Address ( uint32_t row , uint32_t col );
/**
* \ param stack an I n t e r n e t S t a c k H e l p e r which is used to install
* on every node in the grid
*/
void InstallStack ( I n t e r n e t S t a c k H e l p e r stack );
/**
* Assigns Ipv6 addresses to all the row and column interfaces
*
*
*/
void A s s i g n I p v 6 A d d r e s s e s ( I p v 6 A d d r e s s H e l p e r C u s t o m ip );
/**
* Sets up the node canvas locations for every node in the grid .
* This is needed for use with the animation interface
*
* \ param ulx upper left x value
* \ param uly upper left y value
* \ param lrx lower right x value
* \ param lry lower right y value
*/
void BoundingBox ( double ulx , double uly , double lrx , double lry );
/**
* Get the interface container
*/
I p v 6 I n t e r f a c e C o n t a i n e r G e t I p v 6 I n t e r f a c e C o n t a i n e r ( void ) const ;
std :: map < uint32_t , std :: vector < Ipv6Address > > G e t N o d e s C o n n e c t i o n s I p s ( void ) const ;
std :: vector < uint32_t > GetValidators ( void ) const ;
uint32_t * G e t B l o c k c h a i n N o d e s R e g i o n s ( void );
std :: map < uint32_t , std :: map < Ipv6Address , double > > G e t P e e r s D o w n l o a d S p e e d s ( void ) const ;
std :: map < uint32_t , std :: map < Ipv6Address , double > > G e t P e e r s U p l o a d S p e e d s ( void ) const ;
std :: map < uint32_t , nodeInternetSpeeds > G e t N o d e s I n t e r n e t S p e e d s ( void ) const ;
private :
void AssignRegion ( uint32_t id );

void A s s i g n I n t e r n e t S p e e d s ( uint32_t id );
uint32_t m_to talNoNod es ; //! < The total number of nodes

uint32_t m_no Validato rs ; //! < The total number of validators
uint32_t m_noCpus ; //! < The number of the available cpus in the simul
double m_latencyParetoShapeDivider ; //! < The pareto shape for the latency of the poin
int m_minConnectionsPerNode ; //! < The minimum connections per node
int m_maxConnectionsPerNode ; //! < The maximum connections per node
int m_minConnectionsPerValidator ; //! < The minimum connections per node

int m_maxConnectionsPerValidator ; //! < The maximum connections per node
double m_validatorDownloadSpeed ; //! < The download speed of validators
double m_validatorUploadSpeed ; //! < The upload speed of validators
uint32_t m_to talNoLi nks ; //! < Total number of links
uint32_t m_systemId ;
enum Manufact urerID * m _m an u fa ct ur e rs ;

std :: vector < uint32_t > m_validators ; //! < The ids of t
std :: map < uint32_t , std :: vector < uint32_t > > m_nodesConnections ; //! < key = nodeId
std :: map < uint32_t , std :: vector < Ipv6Address > > m_nodesConnectionsIps ; //! < key = nodeId
std :: map < uint32_t , uint32_t > m_iotValidatorMap ; //! < key = nodeId
std :: map < uint32_t , std :: vector < uint32_t > > m_validatorLinkMap ; //! < key = nodeId
std :: vector < NodeContainer > m_nodes ; //! < all the nodes in
std :: vector < NetDeviceContainer > m_devices ; //! < NetDevices in th
std :: vector < Ipv6InterfaceContainer > m_interfaces ; //! < Ipv6 interfaces
uint32_t * m_blockchainNodesRegion ; //! < The region in
double m _ r e g i o n L a t e n c i e s [6][6]; //! < The inter - and i
double m _ r e g i o n D o w n l o a d S p e e d s [6];
double m _ r e g i o n U p l o a d S p e e d s [6];
std :: map < uint32_t , std :: map < Ipv6Address , double > > m_peersDownloadSpeeds ; //! < key1 = node
std :: map < uint32_t , std :: map < Ipv6Address , double > > m_peersUploadSpeeds ; //! < key1 = node
std :: map < uint32_t , nodeInternetSpeeds > m_nodesInternetSpeeds ; //! < key = nodeI
std :: map < uint32_t , int > m _ m i n C o n n e c t i on s ; //! < key = nodeI
std :: map < uint32_t , int > m _ m a x C o n n e c t i on s ; //! < key = nodeI
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_nodesDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_connectionsDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_europeDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_europeUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_northAmericaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_northAmericaUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_asiaPacificDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_asiaPacificUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_africaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_africaUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_southAmericaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_southAmericaUploadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_australiaDownloadBandwidthDistribution ;
std :: p i e ce w i se _ c on s t a nt _ d is t r i bu t i on < double > m_australiaUploadBandwidthDistribution ;
};
} // namespace ns3
# endif /* B L O C K C H A I N _ T O P O L O G Y _ H E L P E R _ H */
The entire code is available at Github

Bibliography
[1] Wikipedia. Mirai (malware). https://en.wikipedia.org/wiki/Mirai_

(malware), 2017.
[2] Ali Dorri, Salil S Kanhere, Raja Jurdak, and Praveen Gauravaram. Blockchain
for iot security and privacy: The case study of a smart home. In Pervasive
Computing and Communications Workshops (PerCom Workshops), 2017 IEEE
International Conference on, pages 618–623. IEEE, 2017.
[3] Andreas M. Antonopoulos. Mastering bitcoin. http://chimera.labs.

oreilly.com/books/1234000001802/ch07.html, 2014.
[4] NSNAM. Topology generator. https://www.nsnam.org/wiki/Topology_

Generator, 2017.
[5] Wikipedia. Diffie–hellman key exchange. https://en.wikipedia.org/wiki/

Diffie-Hellman_key_exchange, 2017.
[6] Wikipedia. Internet of things. https://en.wikipedia.org/wiki/Internet_

of_things, 2017.
[7] Nathan Eddy. Gartner: 21 billion iot devices to invade by 2020. Information-
Week, Nov, 10, 2015.
[8] Digital Attack Map. What is a ddos attack? http://www.digitalattackmap.

com/understanding-ddos/, 2017.
[9] Eyal Ronen, Colin O’Flynn, Adi Shamir, and Achi-Or Weingarten. Iot goes
nuclear: Creating a zigbee chain reaction. Weizmann Institute of Science,
Tech. Rep, 2016.
123
Bibliography 124
[10] Adam Dunkels, Oliver Schmidt, Niclas Finne, Joakim Eriksson, Fredrik
Österlind, Nicolas Tsiftes, and Mathilde Durvy. The contiki os: The oper-
ating system for the internet of things. Online], at http://www. contikios. org,
2011.
[11] Xuezhi Zeng, Saurabh Kumar Garg, Peter Strazdins, Prem Prakash Jayaraman,
Dimitrios Georgakopoulos, and Rajiv Ranjan. Iotsim: A simulator for analysing
iot applications. Journal of Systems Architecture, 72:93–107, 2017.
[12] Rodrigo N. Calheiros, Rajiv Ranjan, Anton Beloglazov, César A. F. De Rose,

and Rajkumar Buyya. Cloudsim: a toolkit for modeling and simulation of cloud
computing environments and evaluation of resource provisioning algorithms.
Software: Practice and Experience, 41(1):23–50, 2011.
[13] András Varga and Rudolf Hornig. An overview of the omnet++ simulation
environment. In Proceedings of the 1st international conference on Simula-
tion tools and techniques for communications, networks and systems & work-
shops, page 60. ICST (Institute for Computer Sciences, Social-Informatics and
Telecommunications Engineering), 2008.
[14] Thomas R Henderson, Mathieu Lacage, George F Riley, C Dowell, and

J Kopena. Network simulations with the ns-3 simulator. SIGCOMM demon-
stration, 14, 2008.
[15] Riverbed Technologies. Opnet simulator. https://www.riverbed.com/in/

products/steelcentral/opnet.html, 2017.
[16] Tetcos. Netsim emulator. http://tetcos.com/, 2017.
[17] Jeff Ahrenholz, Claudiu Danilov, Thomas R Henderson, and Jae H Kim. Core:
A real-time network emulator. In Military Communications Conference, 2008.
MILCOM 2008. IEEE, pages 1–7. IEEE, 2008.
[18] Konstantinos Christidis and Michael Devetsikiotis. Blockchains and smart con-
tracts for the internet of things. IEEE Access, 4:2292–2303, 2016.
[19] Slock.it. Slock.it—blockchain + iot. https://slock.it/faq.md, 2017.

Bibliography 125
[20] Mayra Samaniego and Ralph Deters. Hosting virtual iot resources on edge-hosts
with blockchain. In Computer and Information Technology (CIT), 2016 IEEE
International Conference on, pages 116–119. IEEE, 2016.
[21] Yu Zhang and Jiangtao Wen. The iot electric business model: Using blockchain
technology for the internet of things. Peer-to-Peer Networking and Applications,
10(4):983–994, 2017.
[22] Uday Kumar, Tuhin Borgohain, and Sugata Sanyal. Comparative analysis of
cryptography library in iot. arXiv preprint arXiv:1504.04306, 2015.
[23] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
[24] Wikipedia. Blockchain. https://en.wikipedia.org/wiki/Blockchain, 2017.
[25] Stephen Armstrong. Move over bitcoin, the blockchain is only just getting
started. http://www.wired.co.uk/article/unlock-the-blockchain, 2016.
[26] Ray Patterson. Alternatives for proof of work, part

1: Proof of stake. https://bytecoin.org/blog/
proof-of-activity-proof-of-burn-proof-of-capacity/, 2015.
[27] John R Douceur. The sybil attack. In International Workshop on Peer-to-Peer

Systems, pages 251–260. Springer, 2002.
[28] Wikipedia. Replay attack. https://en.wikipedia.org/wiki/Replay_

attack, 2017.
[29] Harvey S. James Jr. The trust paradox: a survey of economic inquiries into the
nature of trust and trustworthiness. Journal of Economic Behavior & Organi-
zation, 47(3):291 – 307, 2002.
[30] Namecoin. Namecoin. https://namecoin.org/, 2017.
[31] Conner Fromknecht, Dragos Velicanu, and Sophia Yakoubov. Certcoin: A

namecoin based decentralized authentication system 6.857 class project. 2014.
[32] Roel Maes. Physically unclonable functions: Constructions, properties and ap-
plications. Springer Science & Business Media, 2013.
Bibliography 126
[33] Intel. Intel

R trusted execution technol-
ogy. https://www.intel.com/content/www/us/en/
architecture-and-technology/trusted-execution-technology/
trusted-execution-technology-security-paper.html, 2017.
[34] ARM. Arm trustzone. https://www.arm.com/products/security-on-arm/

trustzone, 2017.
[35] Arthur Gervais, Ghassan Karame, Karl Wüst, Vasileios Glykantzis, Hubert
Ritzdorf, and Srdjan Capkun. On the security and performance of proof of
work blockchains. In Proceedings of the 23nd ACM SIGSAC Conference on
Computer and Communication Security (CCS). ACM, 2016.
[36] Wei Dai. Crypto++ library. https://www.cryptopp.com/, 2017.
[37] Gao Chong, Ling Zhihao, and Yuan Yifeng. The research and implement of
smart home system based on internet of things. In Electronics, Communications
and Control (ICECC), 2011 International Conference on, pages 2944–2947.
IEEE, 2011.
[38] Samsung. Secured communication with the payment net-

works. http://developer.samsung.com/tech-insights/pay/
secured-communication-with-the-payment-networks, 2017.
[39] EO Kiktenko, NO Pozhar, MN Anufriev, AS Trushechkin, RR Yunusov,

YV Kurochkin, AI Lvovsky, and AK Fedorov. Quantum-secured blockchain.
arXiv preprint arXiv:1705.09258, 2017.
[40] Yury Namestnikov Konstantin Zykov Jornt van der Wiel, Vicente Diaz.
Hajime, the mysterious evolving botnet. https://securelist.com/
hajime-the-mysterious-evolving-botnet/78160/, 2017.

An IoT Simulator in NS3 and A Key-Based Authentication Architecture For IoT Devices Using Blockchain

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

An IoT Simulator in NS3 and A Key-Based Authentication Architecture For IoT Devices Using Blockchain

Uploaded by

Copyright:

Available Formats

An IoT simulator in NS3 and a

A thesis submitted in partial fulfillment of the requirements

for the degree of Master of Technology

DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

INDIAN INSTITUTE OF TECHNOLOGY KANPUR

Name of the student: Saptarshi Gan Roll No: 12807624

List of Figures xii

List of Tables xiv

2.2 IoT blockchain architecture . . . . . . . . . . . . . . . . . . . . . . . 7

3 Overall Architecture of Proposed Model 13

3.2.2.12 Threat Models . . . . . . . . . . . . . . . . . . . . . 36

4 IoT Simulator in NS3 45

A Public Key Cryptography 71

B Simulator Class Codes and Explanation 75

2.1 Discussed Blockchain based architecture for IoT [2] . . . . . . . . . . 8

3.1 Merkle Tree Example [3] . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 NS3 Generator example [4] . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Simple Experiment Network . . . . . . . . . . . . . . . . . . . . . . . 52

6.1 Typical Smart-Home Architecture . . . . . . . . . . . . . . . . . . . . 62

A.1 Diffie-Hellman Key Exchange [5] . . . . . . . . . . . . . . . . . . . . . 72

6.1 Comparison of current and proposed architecture . . . . . . . . . . . 63

IoT Internet of Things

1.1 Recent IoT Attacks

1.2 A Possible Solution

1.3 IoT Simulator

1.4 Contribution of this Thesis

The major contributions of this thesis are:

• We propose an architecture for using public-key infrastructure for communi-

• We demonstrate the utility of our simulator by simulating different attack

2.1 IoT Simulators

NS3 is the Network Simulator 3 which is the open-source, research-oriented, community-

OPNET is the commercial network simulator which is maintained by Riverbed tech-

2.2 IoT blockchain architecture

2.2.1 Blockchain for IoT for a Smart Home

Figure 2.1: Discussed Blockchain based architecture for IoT [2]

2.2.2 Smart Contracts for IoT

2.2.3 Virtual IoT resources on Edge Hosts with Blockchain

2.2.4 IoT Electric business model

2.3 IoT Public key encryption

It is an Elliptic Curve Cryptography library which can be used to perform ECC-

Overall Architecture of Proposed

Blockchain is a distributed database that maintains a continuously growing list of

3.1.2 Principle of Blockchain

The main principle of a blockchain is that it maintains a distributed and decentral-

1. Public Blockchains : Public blockchains are open and permissionless, where

2. Private Blockchains : Private blockchains are permissioned blockchains, where

The prime advantages that a blockchain provides are as follows:

I. Public : The greatest advantage of blockchain is that it is public. Everyone can

II. Decentralized : In blockchains there is no single authority to approve or dis-

The principle component of a blockchain is a block. Each block contains records,

Figure 3.1: Merkle Tree Example [3]

3.1.5 Consensus Protocol

• Proof of Activity: It is an extension of the proof of work using the proof

3.1.6 Challenges for using existing bitcoin solution in IoT

• Memory: IoT devices are also memory-constrained. So computations requir-

3.2 Proposed Architecture for using PKI in IoT

3.2.1 Private Permissioned Blockchain and Validators

Figure 3.2: Central Chain Validator Network

3.2.1.1 Blockchain Structure and Protocol

Figure 3.3: Structure of Blockchain

3.2.1.2 Validator Addition Protocol

1. New Manufacturer requests CCA for verification.