Introduction Summaries Blockchains are often thought
Blockchains are often thought to be synonymous with cryptocurrencies such as
Bitcoin and Ethereum. However, the applications for blockchains are much larger
than implementing currencies and other financial applications. Many companies are
currently using private blockchains for tracking their supply chains in a more
accurate and secure manner [1]. Others are using blockchain to track the
movements of employees in secure areas [1]. These use cases point to broader
applications of private blockchains for increasing transparency, resiliency, and
providing operational value difficult to achieve via traditional means. In this
analysis, we evaluate the feasibility
of a private blockchain communication network applied to physical security
systems.
This work explores the application of set of private blockchains built using the
MultiChain protocol to collect and distribute data in a security system. In current
physical security systems all digital data is collected at the edge and sent to a central
location requiring that the collection points and analyst of the data be trusted. As
more information generators are added at the edge of security systems it becomes
more difficult to trust every component. Blockchains offer a technological solution
that could change how we place trust in components, making it easier to work with
many sources of information while still being confident that the system is secure.
With these added benefits blockchain technology is paving the way for more
complex
security architectures.
MultiChain is a private blockchain built on the Bitcoin core using proof of work
consensus and round robin scheduler to ensure a diverse set of transactions and
blocks [2]. We use MultiChain to create a decentralized network of cameras and
sensors that are capable of communicating data with increased resiliency and
prioritization to the human in the loop of the security system. For example an
operator would be presented with two data streams for camera data; one with
objects in the scene detected by You Only Look Once (YOLO), a machine learning
algorithm and one without. The operator can therefore put more focus on the
images with an object
detected in them.
This approach for data communication uses smart filters, admin nodes, and
member nodes on multiple blockchains that are loosely connected with each other.
MultiChain implements smart filters which check if transactions meet certain
criteria before adding them to the block. These smart filters can facilitate novel
things like segmentation of the network based on data type without causing a large
overlap of different data types. They also allow the system to perform checks on
aspects of a transaction autonomously without human involvement, adding
additional resiliency without human interaction with the system. The admin nodes
add permissions to the network as well as make and approve changes to smart
filters to control the network through the admin consensus mechanism. The
member nodes act as validators for the system as well as being the nodes where
data is generated and added to the system. Both of these nodes are important;
admin nodes control the structure of the system and member nodes add more bulk
which we hypothesize will add resiliency. This allows us to strategically design the
distributed network where nodes with less privileges can be on the edge of the
system while admin nodes are in more secure
locations.
We measure the security and resiliency of the network using five security metric
tests: a Admin Resiliency Test, Member Resiliency Test, Tamper Detection Test,
Speed of Transaction Test, Bandwidth Comparison Test, ending with a Scalability
Analysis. The Admin and Member Resiliency Tests determine whether the network
could continue working if some nodes were taken offline. When admin nodes are
taken offline we specifically test if admin functionality such as adding smart filters
remains, and when member nodes are taken offline we test if the network is still
able to send security data via transactions to the blockchain. This was accomplished
by turning off nodes systematically and testing how the network performed based
on the above criteria. The Tamper Detection Test used the tamper value on
transactions (indicating that a camera was moved or something else about the node
was changed) and sent transactions flagged as tampered to the network. We then
measured if the network saw the fraudulent transaction. The Speed of Transaction
test measured the time it took to send a single transaction on the blockchain
network. The Bandwidth Comparison Test measured the time it took to send
multiple transactions through both the blockchain network and measured the
amount of time it took for
all transactions in the set to be added. For the scalability analysis we evaluated all of
these metrics using different network sizes to determine how each performance
metric scaled with respect to size. After extensive testing in a variety of
configurations, we found our network architecture is able to remain online even
when multiple nodes
are shut down.
The remainder of the thesis is organized as follows:
• Chapter 2 Evaluates other academic blockchain based approaches in different
fields, discuss the background of security systems and the MultiChain
protocol.
• Chapter 3 describes the architecture of our test network. We discuss other
blockchain architectures and motivate our use of MultiChain.
• Chapter 4 discusses the six resiliency and robustness tests of our system.
• Chapter 5 presents the experimental results. We find that our network is
relatively resilient to attack, especially in contrast to a centralized system.
• Chapter 6 We conclude with a discussion on future work in Chapter 6 where
we deal with the real world implications of our model and look toward
additional testing and comparisons. We find that our approach can be broadly
applied to topics outside of the specific application shown in this thesis.
5
Chapter 2
Background
While blockchain technology has been the technological backbone of
cryptocurrencies since 2009 [3]. The technologies that supported the creation of
blockchain have existed far longer. One of the foundations of blockchain is public
key cryptography created in 1976 [4]. Another important technology to the modern
blockchain is the proof-of-work consensus mechanism which was introduced in
Hash Cash in 1997 [5]. After the release of Bitcoin [3] many blockchains were
created such as Ethereum [6], Litecoin [7], Polkadot [8], etc.
Each type of blockchain utilizes different permissions and technologies to come
to consensus. Public permissionless blockchains such as Bitcoin allow anyone to
read the blockchain and write data to the blockchain. Public permissioned
blockchains allows anyone to read data on the blockchain but participants must
meet some sort of criteria to write data to the blockchain. Private permissionless
blockchains allow
anyone to write their own data but only nodes given permissions by other nodes
will be able to read data on a private permissionless blockchain. Lastly private
permissioned blockchains participants must be added by nodes that are currently
on the network to view the blockchain and be given permission to write data to the
blockchain. While these blockchains differ in who can participate in the network
each are still able to reach consensus. These different blockchains will usually use
different types of consensus mechanisms such as lottery based consensus (e.g.
proof-of-work, proof-of-stake) or voting based consensus (e.g. practical byzantine
Chapter 2. Background 6
fault tolerance, delegated byzantine fault tolerance) to reach consensus and a
common feature of blockchains is to have an immutable ledger of transactions
which cannot be altered. Blockchain also is generally tied to resiliency to node fault
in a system so nodes can go offline or behave with a byzantine fault and it will not
affect the performance of the system.
2.1 Applications of Blockchain Technology
With the development of different types of blockchains the application space has
expanded past cryptocurrency into a multitude of domains which can benefit from
the immutable features of blockchain technology. Applications currently being
researched include supply chain management[9], immutable audit logs[10],
production systems[11], as well as many others [1]. Each type of application can
give us inter-
esting insights as to proper use cases for blockchain in a system.
However, one major problem with the rise of blockchain applications is that
often a blockchain simply is not needed for the use case detailed by designers.
Wu¨st and Gervais created a model to decide if a blockchain is necessary for
different applications [12]. The model is built upon characteristics of the different
types of blockchains currently utilized for applications and characterizes the needs
that each type of blockchain could support. The main questions they suggest asking
before
using a blockchain are:
• Does state need to be stored?
• Are there multiple writers in the system?
Chapter 2. Background 7
• Can online Trusted Third Party always be used?
• Are all writers known and are they trusted?
Based on this framework, we will provide an overview of current research on
applying blockchains to different cyberphysical systems and discuss how this
problem fits the
criteria.
The application MedRec [13] uses an Ethereum blockchain to communicate data
ownership and viewership of medical records. The system uses regular databases to
store the data off chain. The writers of the blockchain do not necessarily need to be
trusted for the blockchain half of the system, but do need to be trusted for the
regular DB half (where the medical records are stored). With this need to trust
writers based on the framework we are following from Wu¨st and Gervais suggests
that MedRec should use a private permissioned blockchain.
Sikorski et al. [14] created a MultiChain blockchain to create a peer-to-peer
electricity market. This market application uses existing architectures to make a
crosscountry currency to exchange electricity. This application did have the correct
needs to use a blockchain as there were multiple untrusted actors where the state
needed to be saved, it would be difficult to use a trusted third party for this
application as there are multiple parties that would have difficulty communicating
through a third
party.
Zakhary et al. [15] propose a system that employs numerous permissionless
blockchains and a permissioned blockchain to facilitate global asset management.
The permissionless blockchain part of the system would be suitable to use a
blockchain as the writers are not known or trusted, there are multiple writers, and
Chapter 2. Background 8
state needs to be stored. The permissioned portion of this system, however, does
not necessitate a
blockchain because the permissioned blockchain is supposed to have trusted
writers.
Saberi et al. [9] discuss how blockchain could affect supply chain management.
The authors do not discuss a specific application of blockchain, rather, they specify
why a blockchain could be utilized. Based on the needs of the supply chain detailed
in their paper, a blockchain would be appropriately used. This is because their
system has multiple writers communicating internationally that cannot be trusted.
The system also needs to have a true record of what occurred as the item moved
through the chain.
Zyskind et al. [16] propose a system to manage personal privacy using
blockchain. This application used a blockchain appropriately as it needed to store
state and there
were multiple writers that were known but not all of which could be trusted.
Karafiloski [17] discusses many applications of blockchain to big data problems
The paper discusses proponents for each type of blockchain and why one would
utilize them for a big data application. The first type of application discussed is
decentralized protection of personal data, one solution to this problem discussed is
the Zyskind paper discussed earlier in this section. Another application discussed in
the decentralized protection of personal data is an application called Ushare, this
application uses blockchain to track transactions but uses a distributed hash table
to store the actual data. This is used because the space and time constraints on this
system means that a blockchain is not capable of storing all of the information. This
application removes the necessity of trusting a third party with your data in a social
networking situation as the user could evaluate the hashes and see where exactly a
post goes by following the transaction log in the blockchain.
Chapter 2. Background 9
A second topic of discussion in Karafiloski’s review [17] is blockchain applied to
the area of digital property. One project the author discusses is Ascribe, the goal of
Ascribe is to allow for artists online to be able to track their artwork throughout the
internet so that they can be properly compensated. Ascribe created its own protocol
called SPOOL, it was made specifically for documenting transactions about
ownership of digital property. Ascribe allows an artist to more easily track their
work using SPOOL as can any other party who knows the hash since this application
uses a public blockchain implementation.
Our interest in blockchain applications arises from the following problem:
current security systems are highly centralized and are not resilient to single points
of failure, we want to evaluate if a blockchain based approach could increase
resiliency without decreasing performance in a physical security system. Based on
past work and Wu¨st and Gervais’ [12] model for needing a blockchain, this work
needs to ask do we need a blockchain? We know that a physical security system
needs to store state to keep a log of past events, our particular type of security
system cannot use an always online trusted third party as the data cannot leave the
local system, there are multiple writers (i.e. sensors, imagers, human in the loop)
which are all known and can be added to the blockchain by a known entity but
cannot necessarily be trusted because of the possibility of malfunction for the
imagers and sensors. With this information about our system we know that a
blockchain could be useful for our needs. Based on Wu¨st and Gervais’ [12] model
the particular type of blockchain we should investigate is a private permissioned
blockchain. Since this system could benefit from a blockchain, it is valuable to test if
the blockchain architecture can support a security system and to determine how the
blockchain architecture scales with respect to size in the metrics important to
physical security systems.
Chapter 2. Background 10
2.2 Background of MultiChain
MultiChain is a private blockchain architecture based on the Bitcoin core version
0.10 and MultiChain 1.0 was created in 2016 [2]. This blockchain extends the
Bitcoin core and so has integration with the Bitcoin core APIs. MultiChain is written
in C++ and can be run on x86 64 architectures. The source code was a fork of the
source code of Bitcoin. MultiChain developers integrated updates to the Bitcoin core
which are necessary for private blockchain development. These updates include the
creation of two types of nodes (admin and member) with different capabilities
shown in Figure
Figure 2.1: Permissions of different nodes in MultiChain
2.1, adding a round robin schedule to the proof-of-work consensus algorithm,
enabling multiple blockchains to be configured at once on the same network,
setting targets
for the time it takes to mine a block, and other actions.
Admin
Actions
Membe
r
Action
s
Create new filters
Issue assets
Approve new filters
Approve new nodes
Send transactions
Receive transactions
Connect to blockchain
Chapter 2. Background 11
To support a private network with two types of nodes, this implementation
extends the cryptographic handshake used in Bitcoin to ensure that only permitted
nodes are able to make peer-to-peer connections. Each node will share their public
address that is on the permitted list; each node will verify all other nodes addresses
on their version of the permitted list. Each node will then send a challenge message
to every other node in the network. After the challenge message is sent each node
will send back a signature of the challenge message showing they own the private
key which corresponds to the public address. If at any of these steps a node fails, the
peer-to-peer (p2p) connection will be terminated. This allows the network to be
used or viewed by only contain nodes that are known to at least one administrator
while keeping nodes mostly unknown without allowing an arbitrary node onto the
network.
MultiChain uses a proof-of-work consensus like Bitcoin to regulate and
randomize the nodes rate of block production but enforces a round robin schedule
to promote mining diversity so that one miner cannot monopolize the mining
process. This is important in private blockchains because there are not as many
participants (nodes or miners) as found in public blockchains so it would be
difficult to prevent a node from taking over the network with more computing
power without this addition. To implement the round robin schedule MultiChain
has a set of steps the blockchain must take every time a block is mined first every
permission change in the block must be completed in order the related transactions
show up in the block. Second, the number of verified miners for this block is
calculated. Third, the number of miners is multiplied by the mining diversity factor
that was set when the blockchain was configured to calculate spacing. Lastly, we
check if the miner of the current block mined one of the previous spacing-1 blocks if
so the block will not be mined. With these rules for whether a block can be mined
MultiChain prevents a miner from
mining every block if mining diversity is set above 0.
Chapter 2. Background 12
MultiChain also allows the institution to configure the target time for adding a
block. This means that institutions are not bound by the 10 minute average time for
Bitcoin to add a block to the blockchain and can set their targets much lower.
MultiChain allows an institution to create multiple private blockchains on the same
machines meaning that there can be data flowing through different blockchains on
the same network allowing nodes to pass data between different blockchains. This
is useful in the case of having two blockchains where an input occurring on the first
affects the behavior of the second, or if an institution wanted to store some data on
one blockchain and related data on another. MultiChain supports multiple tokens on
the same blockchain unlike the Bitcoin blockchain and many others. An institution
could use this function to only allow transactions on the blockchain that meet the
value requirement for multiple tokens through smart filters.
Smart filters are a way to add code to the blockchain which can be used to
determine if a transaction is valid based on some criteria such as the amount of a
token or whether particular metadata is present in the transaction. For example a
smart filter could be created to ignore all transactions that did not have a certain
token’s value of 5 or more. Smart filters can be created and approved by admin
nodes which approve the smart filter through admin consensus. Smart filters can be
disapproved after use on the blockchain which is a key difference between smart
filters on MultiChain and Smart Contracts on Ethereum. This feature enables
operators and maintainers of the blockchain to disapprove smart filters if a bug is
found, and a new smart filter with a correction can be created and approved to take
its place on the blockchain.
Chapter 2. Background 13
2.3 Current Security Systems
As security systems are updated, more computing nodes and information
generators are added to the system in various places to enhance detection
capabilities and are generally added to a centralized communication architecture. In
current physical security systems this communication architecture takes data from
these devices at the edges of the system to a central location for processing. This
presents problems that impede the resiliency of a security system. This centralized
design also requires
that we trust all of the components and humans in our system to behave in the ex-
pected manner. Since these challenges arise due to architectural choices themselves,
a current area of research for physical security systems is investigating distributed
communication architectures.
There are three major needs in a physical security system, that a distributed
architecture needs to support. These are fast agreement; a security system needs
to have data added to the event log quickly so that it can be assessed in a timely
manner. Tamper resistant; a security system needs to have data stored in such a
way that it cannot be easily altered by an adversary. Flexibility; a security system
Data Protected
Availability
Integrity
Confidentiality
Chapter 2. Background 14
Figure 2.2: CIA triangle
has multiple data formats that need to be stored in a way such that they are easily
accessible at the same time. The proposed system based on the MultiChain protocol
will support fast agreement with a short target time for mining blocks, tamper
resistant with the immutable storage that is inherent in blockchain technology, and
flexibility through the ability to add multiple tokens and metadata to the
blockchain
and utilize multiple blockchains to store data.
Since we want to build a data communication architecture for a physical security
system it is important that we evaluate how a blockchain based system might
perform in the three areas of the data protection triad shown in Figure 2.2. The first
element, integrity, is satisfied by the immutable ledger used in blockchain that
does not allow for unauthorized alteration. Blockchain technology provides
confidentiality through encryption of the data on the blockchain and
private/permissioned blockchains require that a node be accepted by other nodes
on the blockchain to view or edit the information being added to the blockchain.
Availability will be supported by creating a more resilient system by distributing
the data across the system helping avoid issues such as denial of service attacks
from keeping the whole network offline. Based on the use of blockchains in other
applications and the needs of a security system it is clear that a blockchain based
approach to physical security architectures could increase resiliency while still
supporting the needs and goals of a physical security system.
15
Chapter 3
Methodology
Our background research has shown that our system could benefit from using a
private permissioned blockchain it has also shown that our system meets the
criteria set up by Wu¨st and Gervais’ paper [12] for using a private permissioned
blockchain. we discussed the needs of a security system in terms of data
communication and processing for analysis and how a blockchain implementation
could support those needs. With this information we can start to choose the correct
blockchain implementation,
network structure, data processing, and sorting techniques.
In this section we will describe our process for deciding on a blockchain
implementation for our test network, the network structure we used for our test
network in our chosen blockchain, how we processed the data that would be sent as
transactions on our blockchain network, how the data would be sorted for
assessment, and lastly we will describe how we took our original test network and
changed it to test our metrics from Chapter 4 at different sized networks to
determine how performance in those metrics scaled with respect to size.
Chapter 3. Methodology 16
3.1 Selecting a Blockchain Implementation
We chose to build out a large model for this system using MultiChain 2.0. The
process for choosing MultiChain as our basis for this project is detailed in this
section. In choosing a blockchain implementation with which one can build an
application, there are many options depending on system needs. As this work
requires that the blockchain not be viewed by the public we are limited to using
private permissioned blockchains. This work limits itself to blockchains mature
enough to build upon as of implementation time in early 2019. We also decided
against building our own blockchain from scratch, to leverage the existing extensive
testing done on blockchains. of the features that was needed for this system was the
ability to support
writing code to affect blockchain transactions.
These criteria limited the blockchains under consideration to private Ethereum
[18] and the Bitcoin core-based MultiChain [2]. Both of these blockchain
implementations are private blockchains and allow one to write code through the
use of smart contracts and smart filters, respectively. While there are other
blockchain implementations that meet the criteria we set forth at the original time
of implementation
they were not sophisticated enough to build on.
Since MultiChain and Ethereum have similar capabilities (i.e. permissioned
networks where privileged nodes allow new network connections, the ability to add
code to the blockchain, similar levels of maturity in early 2019) small test networks
were developed using both networks to determine which implementation would
work best
for this use case. Diagrams of each network are shown in Figure 3.1.
Chapter 3. Methodology 17
The implementation of Ethereum used in this test, is the private version of Go
based Ethereum. Go Ethereum uses a proof of authority consensus algorithm [18].
Proof of Authority attaches a nodes reputation to their identity which incentivizes
nodes to uphold the transaction process to not be negatively impacted.
Non-trusted Nodes
(a) Ethereum Network (b) MultiChain Network (Note all nodes in
this network are non-trusted)
Figure 3.1: Small Test Networks using Ethereum and MultiChain
The Ethereum Blockchain has four types of nodes that can be used geth, miner,
boot, and member.
• A geth node is the beginning node that sets up the blockchain with the
genesis block. This is where all of the parameters on the blockchain are
described such as the gas limit, the mining difficulty, and the nonce which is
what is used to distinguish this network as private. The nonce is a randomly
generated hex value so that an attacker would have difficulty guessing it to
connect to the
network.
• A miner node is a node that can mine Ethereum for the network.
Mine
r
Get
h
Boot
1
Boot
2
Membe
r
Membe
r
Trusted
Nodes
Admin Admin
Member Member
Chapter 3. Methodology 18
• A boot node is a node that is used to connect to the private network. This
adds decentralization to how nodes connect to the network as nodes do not
need to directly connect to the geth node and you can have any number of
boot nodes.
• A member node is node that is connected to the network and can send
transactions.
The test setup used to determine if Ethereum should be used contained a geth
node, a miner node, two boot nodes, and two member nodes. This design assumes
that the geth and miner node are trusted since this design does not have multiple
geth nodes. The miner nodes must be trusted in this setup since the miner will be
the source of Ethereum so it needs to be trusted to distribute it in the correct
manner. This design was chosen because it takes advantage of the native protection
of having boot nodes while still being small enough to easily run tests on the
implementation. The testing setup is shown in Figure 3.1(a).
The MultiChain setup in Figure 3.1(b) starts with a single admin node and the
network can be added on by that admin. MultiChain uses a proof of work consensus
algorithm paired with a round robin schedule described in Section 2.2. MultiChain
has two types of nodes that can be used:
• A member node can validate, send, and receive transactions. They can also
mine if given permission from an admin node.
• An admin node has all the abilities of a member node well as other abilities,
like adding new nodes to the network.
The MultiChain network for this initial test is configured to have two admin
nodes and two member nodes, as seen in Figure 3.1(b). This design allows the
Chapter 3. Methodology 19
network to have enough nodes to turn some nodes off and still have the network be
functional. Unlike the Ethereum-based network, the MultiChain network does not
assume that any nodes are trusted because every node has other nodes which can
perform its
functions.
In both networks, we test the functionality of the network by designing two
basic resiliency tests for our example networks. Both of these resiliency test are
similar to two of our final testing metrics described in Chapter 4. One resiliency test
disconnected the connection node (boot node for Ethereum and admin node for
MultiChain) and attempted to connect a new node to the network. Our second
resiliency test used for these examples sent transactions to the both networks that
should not have been accepted based on the criteria setup using smart contracts on
Ethereum and smart filters on MultiChain and measured the propagation of this
transaction. Both networks passed these simple tests. Based on these tests and the
creation of both networks, we find that they both could perform the tasks required
of the network. However, after using both networks, we found that the private
Ethereum network has two drawbacks:
1. It requires more resources to maintain than the MultiChain network
2. It requires a more complex network structure
3. It is more difficult to set up than the MultiChain network which would affect
its acceptance by the physical security community
The system that we design requires ease of use and minimal addition of resources
due to the embedded nature. With these restrictions in mind, we decided to build
out our MultiChain network further.
Chapter 3. Methodology 20
3.2 Network
The notional network based on MultiChain is shown in Figure 3.2. Our larger test
network uses 13 virtual machines running Ubuntu 16.04 created using MultiChain
2.0 community edition [19]. This network was set up with a target block time of 15
seconds and a mining diversity requirement of 0.3, meaning that the spacing is 4 for
the 13 node network. With a spacing of 4 we know that a node A can mine a new
block after 3 blocks have been mined since the last block node A mined. With larger
networks more blocks will need to be mined by others before node A would be able
to mine another block. With a higher mining diversity we could require more blocks
to be mined between sequential mines by a single block but with a higher mining
diversity the risk of the blockchain freezing up if nodes are inactive.
ImageNoClass
ImageClass
QRinvalid
QRvalid
Admin
ImageNoClass
Admin
ImageClass
Admin
QRinvalid
Admin QRvalid
Node 11
Node 12
Node 1
Node 3
Node 4
Node 5
Node 6
Node 8
Node 9
*
*
*
Node 7
Node 2
Node 0
Node 10 *
Chapter 3. Methodology 21
Figure 3.2: Network Diagram for 13 nodes with two types of data input
The MultiChain network in Figure 3.2 has two types of nodes; admin nodes and
member nodes. The nodes are defined by what permissions they have. Member
nodes have permissions to send, validate, and receive transactions; admin nodes
have those permissions as well as the ability to create and approve smart filters and
add new nodes to the chain. These smart filters check if transactions meet certain
criteria before adding them to the block. Our network has two types of data input;
microwave sensors and security cameras. The MultiChain network for this project
was setup to have five admin nodes and eight member nodes. Nodes 0, 2, 5, 8, and
11 are admin nodes, nodes 3 and 4 are member nodes which add in imager data to
the system, nodes 9 and 10 are member nodes which add in microwave data to the
system, and all other nodes are member nodes with no extra functionalities.
This network can be expanded upon either by adding more inputs for the
current types of data or by adding new types of data to be stored in the distributed
ledger e.g. one could add data about employee movements, movement of materials,
or data from other types of sensors. Adding either more types of data or more
inputs would make the system more complex, but could add more decentralization
therefore requiring more resources to shut the entire system down. These
implications will be further
explored in Chapter 4.
This setup was designed to take advantage of having a decentralized
architecture; new nodes (both admin and member) can still connect to the network
and new smart filters can still be approved as long as some subset of admin node(s)
are present. MultiChain has the advantage that no nodes in the system need to be
trusted for the network to continue operations. If necessary an admin node can also
Chapter 3. Methodology 22
create a new blockchain and allow known uncompromised nodes onto the new
blockchain if too many nodes are compromised in a system.
As we will demonstrate in Chapter 5, if an admin node is taken over, the other
admin or admins can start a stream or even a new chain with the non-compromised
nodes. This means that it would be difficult to perform an attack on this system by
shutting off nodes without spending a large amount of resources. Similarly if an
adversary only shut off a few member nodes the system would remain able to send
transactions.
With this network structure we are able to prioritize data that comes onto the
network by placing data that has detections on the image class chain and the
microwave detect chain. This supports the goal of flexibility for our security system
by making multiple types of data easily accessible. By setting our target time to 15
seconds and our mining diversity to 0.3 we support fast agreement by adding new
blocks quickly while maintaining security against one node taking over the entire
network. This network structure also changes how we trust the components in our
system compared to a centralized security system showing that in multiple areas
this network design supports the needs and goals of a future physical security
system.
3.3 Data Processing
Two types of sensing devices were used in this analysis: cameras and microwaves.
Each camera sensor takes images of the object related to the microwave sensor and
processes them using the You Only Look Once (YOLO) object detection algorithm to
detect classes of interest (e.g., people, vehicles, etc.). YOLO is a convolution neural
network object detector that applies a simple neural network to the whole image
Chapter 3. Methodology 23
and then divides the image in to regions to predict where bounding boxes should go
in
those regions.
YOLO was chosen because with this technique the image only needs to go
through the neural network once and so it can process images in real time while
providing regional data for where a target(s) are located within a scene associated
with the image file [20]. If no target is located, the image file is not associated with a
class
giving us the ability to sort image data based on that factor.
Microwaves are sensors which use switch closures to indicate that an object has
passed through their line of detection. When an object is detected the microwave
will have a low value and when it is in a secure state the value will be high. We use
this
value to determine which chain to place a transaction in the microwave sub-
network.
If YOLO detects an object in the scene or a microwave shows a low value for a
detection the transactions from that event will be added to the image class and
microwave detect chains. Otherwise the transactions will be placed on the
microwave and no image class chain. The process for how this is done will be
covered in section
3.4.
One of the reasons for utilizing blockchain technology to distribute the data in a
security system to multiple locations is to support the use of secure distributed
computing where multiple nodes can communicate and run algorithms to come to
decisions about data passed through the system and come to agreement
(consensus) on the decision between the nodes. Possible applications of this idea
will be further explored in Chapter 6.1.
Chapter 3. Methodology 24
3.4 Data Sorting
ImageClass
MicrowaveDetect
TranscamTrans MW
(a) Camera Sorter (b) Microwave Sorter
Figure 3.3: Diagram of how data is sorted in the system
Figure 3.3 shows how the data from the sensors is sorted in this network using
smart filters. A smart filter in MultiChain is code that is added to the chain by a
single admin node and approved by the admin nodes collectively. This code affects
which transactions will be accepted on a particular chain by evaluating the amount
of a token in a transaction or the metadata sent with the transaction. The
implementation of smart filters in our system allows the data to be sorted to the
appropriate channels depending on both the token in the transaction and the
metadata that is sent with the transaction in the form of a JSON object. The smart
filters also allow the system to ignore data that has been tampered with instead of
letting large amounts of faulty data propagate through the system. One of the smart
filters in this system is described in Section 3.4.2, and an example of a transaction is
given in Section 3.4.1.
3.4.1 Transactions
The transaction in listing 3.1 is sent to both blockchains in the camera sub-network.
The only difference between the transactions on the two networks will be the
Smart Filter ImageNoClass
OffChain
Smart Filter MicrowaveNoDetect
OffChain
Chapter 3. Methodology 25
address they are sent to as one will be sent to an address on the imageClass chain
and one will be sent to an address on the imageNoClass chain. For this example the
address is
1WfiQNZirYMwVqVgdKvaboupEpz3FWHzcAEzec. This transaction contains an image
with an object detected in it and the related percentage of confidence and regional
information outputted from YOLO. The transaction contains two assets which is
what a smart filter is attached to when it is added to the blockchain (i.e. you must
have any required assets in a transaction for it to not be rejected).
1sendwithdata 1WfiQNZirYMwVqVgdKvaboupEpz3FWHzcAEzec
2’{"tamperAsset":10, "classifyAsset":1}’
3’{"json":
4{
5"filename":"/media/210/image1.png",
6"classify":"person",
7"percent":0.5402294993400574,
8"center x":1024.7264404296875,
9"center y":180.95614624023438,
10 "width":16.506134033203125,
11 "height":33.79193878173828
12 }
13 }’
Listing 3.1: Transaction for camera with object detected
The assets being sent for this transaction are:
• the tamper asset which represents the value of whether the system has been
tampered with or not. A tamper in this situation describes a physical tamper
Chapter 3. Methodology 26
on a sensor. When a sensor is tampered with, a switch will change the value
being sent to the network. A transaction that has not been tampered with will
have a value of 10. If a transaction has been tampered with the value would be
outside of 10.
• the classify asset is the asset that transactions with images must be sent with
which is also why only one unit of the asset is sent with the transaction. This
allows the system to determine if the transaction could meet the
requirements of all smart filters on the blockchain. The smart filter on this
chain related to classify asset is the classify filter described in Section 3.2.
The data passed through in this transaction is represented by a JSON object.
This contains a link to the image (stored in a video management system) being
passed as well as the classification made by YOLO along with the percentage of
certainty and location values. This is useful information for a human operator to
have as it will allow them to find objects in the image being referenced more easily
making for a quicker assessment of the data. This transaction will be added to the
ImageClass sub-network because the JSON object contains a value for classification;
if it did not it would be sent to the ImageNoClass chain. JSON objects are an easy
way to send multiple types of data making them ideal for large complex systems
like the one described in this paper; examples of a JSON object being used for other
types of data is shown in Appendix A.
3.4.2 Smart Filters
Each transaction is added to a specific blockchain based on the code written in the
smart filters for that chain. Each smart filter affects transactions made on the
Chapter 3. Methodology 27
blockchain that has the smart filter approved. A transaction can be sent to multiple
blockchains which will sort the data accordingly. An example of a smart filter is
shown below; all other smart filters for this system are in Appendix B.
1classifyFilter function filtertransaction()
2{
3var meta=getfiltertransaction();
4s=String(meta.vout[1].data[0].json.classify);
5if (s.valueOf() == " ".valueOf())
6{
7return "Classify not found"
8}
9}
Listing 3.2: Smart filter to determine if an object is in an image
The Smart Filter in listing 3.2 checks to see if there is an object detected in an
image. This code is written in JavaScript and checks that the classify value in the
JSON object of the transaction contains a value from YOLO. This filter is placed on
the Image Class sub-network. If the transaction fails this code check, the image will
not be added to the Image Class chain and will need to go through another smart
filter
to be added on a different sub-network matching the data type and detection status.
With the smart filters and transactions set up the network ran with data being
placed on the chain correctly and securely supporting the goal of fast agreement
and flexibility for the security system. This shows that the network can support
thousands of transactions being placed on it at a rate that is fast enough that
humans in the loop wouldn’t be able to detect the difference in the time it takes for
the data
Chapter 3. Methodology 28
(a) 7 node (b) 26 node
(c) 39 node
Figure 3.4: Graph representations of other networks used for scaling analysis
to be uploaded. This will be shown in Chapter 5. Therefore it will be valuable to
make some initial measurements of the system for quantitative analysis. Doing so
will allow us to determine if there are actually added security measures from the
use of blockchain in the system.
Chapter 3. Methodology 29
3.5 Scalable System Design
Our small test structure can be used to perform some analysis but it is important to
note that a blockchain’s performance could change as the network size grows or
shrinks. To test how the network scales we created different test structures utilizing
VMWare. With VMWare we tested 3 other network sizes 7 nodes, 26 nodes, and 39
nodes shown in Figure 3.4.
The networks that we tested were similar to our test network but expanded or
reduced the number of nodes. For instance, our 7 node network had 3 admin nodes,
our 26 node network had 10 and our 39 node network had 15 while our original
sized network had 5 admin nodes. These test networks were still tested with
microwave and camera data. The smart filters utilized on our original network
structure were also used on these networks to sort data according to the criteria
described in Section 3.4
