Collaborative Cyber Attack Defense in SDN Networks using Blockchain Technology

Full text

Collaborative Cyber Attack Defense in SDN
Networks using Blockchain Technology
Mehrdad Hajizadeh, Nima Afraz∗, Marco Ruffini∗, Thomas Bauschert
Technische Universität Chemnitz, Chair of Communication Networks, Chemnitz, Germany
∗CONNECT Center, Trinity College Dublin, Ireland
Email: {mehrdad.hajizadeh, thomas.bauschert}@etit.tu-chemnitz.de
∗Email: nafraz@tcd.ie | marco.ruffini@scss.tcd.ie
Abstract—The legacy security defense mechanisms cannot
resist where emerging sophisticated threats such as zero-day and
malware campaigns have profoundly changed the dimensions of
cyber-attacks. Recent studies indicate that cyber threat intel-
ligence plays a crucial role in implementing proactive defense
operations. It provides a knowledge-sharing platform that not
only increases security awareness and readiness but also enables
the collaborative defense to diminish the effectiveness of potential
attacks. In this paper, we propose a secure distributed model to
facilitate cyber threat intelligence sharing among diverse partici-
pants. The proposed model uses blockchain technology to assure
tamper-proof record-keeping and smart contracts to guarantee
immutable logic. We use an open-source permissioned blockchain
platform, Hyperledger Fabric, to implement the blockchain
application. We also utilize the flexibility and management
capabilities of Software-Defined Networking to be integrated with
the proposed sharing platform to enhance defense perspectives
against threats in the system. In the end, collaborative DDoS
attack mitigation is taken as a case study to demonstrate our
approach.
Index Terms—Cyber Threat Intelligence, Blockchain, SDN,
Proactive Defense, Collaborative DDoS Mitigation
I. INTRODUCTION
The continuous growth of IT infrastructures, along with
emerging technologies such as 5G, exposes a massive and
diverse number of devices connected to the Internet. This
leads to an increase in the complexity and vulnerability of
the Internet infrastructure especially concerning cyber security
attacks. Well-funded players have transformed simple hacking
activities to very advanced attack operations e.g., to gain
financial benefits or for political interests. Unauthorized access
through Zero-day attacks as well as Advanced Persistence
Threats (APTs) are two examples of dynamic, stealthy and
sophisticated threats to the system [1]. Despite huge annual
spending in cybersecurity, companies are still dealing with
significant security challenges which cannot be handled by
their legacy defense mechanisms.
Nowadays, organizations mostly use reactive defense meth-
ods that retain the defense team in a firefighting fashion [2].
However the key to proactive defense is acting rather than
reacting. The successful counter-strategy against advanced
threats comprises 1) collecting information about threats,
adversaries, their techniques, and 2) sharing with other parties.
Consequently, near-real-time (NRT) Cyber Threat Intelligence
Fig. 1: Cyber threat intelligence sharing for different scenarios
using blockchain technology.
(CTI) could ease the proactive defense of critical network
infrastructures [3].
Threat Intelligence (TI) is the collection of information
about a threat that might prevent an attack or reduce the
detection time [1]. Practically, cyber threat intelligence sharing
is utilized for distributing security knowledge and experiences
with other contributors on a sharing platform. Verizon [4]
indicates that the observation spread time is a vital factor.
Indeed, 75% of attacks are launched from target 0 to target
1 within only 24 hours. Surprisingly, more than 40% of them
invade the second target in less than an hour.
On the other hand, there are network operators that heavily
rely on third-parties (CTI providers) to feed intelligence into
their defense mechanisms. However, this reliance may hin-
der the implementation of Service Level Agreements (SLA)
between CTI customers (e.g., network operators) and CTI
providers. For example, an SLA violation may occur due to an
insufficient reaction of the CTI provider during a cyber attack
that might lead to massive compensation fees.
Recently, Software Defined Networking (SDN) is recog-
nized as a promising concept that facilitates network man-
agement as well as policy enforcement. SDN decouples the978-1-7281-5684-2/20/$31.00 ©2020 IEEE

control plane and the data plane of the network, enabling a
global view on the network and allowing network programma-
bility [5].
Our objective in this work is to overcome the common
issues of threat sharing. We outline a secure, scalable, im-
mutable, low-cost, and easy to deploy decentralized infrastruc-
ture where different parties can share cyber threat intelligence.
Fig.1 shows how various partners with common business
objectives can use a single blockchain platform. For example,
a network provider could be supported by either open-source
CTI communities or CTI-as-a-Service providers. Meanwhile,
it can cooperate with upper layer ISPs or with security incident
response teams for collaborative defense against adversaries.
In this work, we particularly address the following issues:
•A highly secure platform that allows various members
to share sensitive information through channeling and
authenticated access.
•A trustworthy platform where participants benefit from a
reliable business model. This is a necessary prerequisite
for a successful security collaboration based on smart
contracts for providing reliable SLAs.
•A SDN control plane that enables fast security policy
enforcement and thus reduces cyber attack mitigation
time.
This paper is organized as follows. Section II presents
related work. In section III, we outline the components of
our proposed platform. The case study is described in section
IV, and the results are presented in section V. Finally, section
VI concludes the paper.
II. BACKGROU ND A ND RE LATE D WORK
The lack of a secure and reliable platform for CTI sharing
hinders the collaboration between parties. As mentioned in
[1], [6], revealing sensitive information is one of the main
reasons that prevents knowledge-sharing - competitors might
misuse the exposed information. Also, sensitive intelligence
could reveal critical details about the network infrastructure
where adversaries can benefit from. Likewise, the disclosed
invasion techniques could encourage new malicious actors to
invade other insecure systems [7]. Additionally, the adversaries
may gain awareness on the detection of their attack if this
information is disclosed outside the trusted zone. By that
they will be able to perform necessary updates to continue
their malicious activities. Considering the above-mentioned
issues, organizations either avoid sharing or prefer to restrict
collaboration with only highly trusted community members
[6] [7].
Hence, the CTI sharing platform, as well as the participants,
should establish several levels of trust relationship to avoid
information disclosure and assure the reliability of intelligence
data provided by other partners [8].
The application of blockchain technology in the context of
security is an emerging trend in various research domains.
Authors in [9] suggest that storing the logs in ledgers can
improve the transparency due to the append-only feature
of a blockchain. Thus any misbehaving individual cannot
Fig. 2: High-Level architecture of a CTI sharing platform for
collaborative DDoS attack mitigation using STIX objects
tamper the logs. Moreover, CTI sharing through an immutable
database prohibits malicious players from manipulating the
intelligence for confusing the defense mechanisms. It also
provides traceability for forensic analysis e.g., for cyber-crime
investigations [10].
Another application use case for blockchain technology is
in the context of Distributed Denial of Service (DDoS) attacks.
Nowadays, DDoS attacks are recognized as one of the most
sophisticated attacks with large impact. The probability of
a successful [11] DDoS attack is quite high if only legacy
security mechanisms are applied. A large body of research
addressed DDoS attack mitigation. A coordinated protection
following a group-defense approach facilitates the prevention
of illegitimate DDoS traffic through collaboration among net-
work providers. This extends the defense horizon close to the
source of attack rather than to victim resources [12] [13]. The
IETF in [14] proposed a signaling protocol for collaborative
DDoS attack mitigation named DDoS Open Threat Signaling
(DOTS). However, the implementation complexity makes the
global development of DOTS challenging [15]. Furthermore,
a compromised DOTS server may lead to a defeat especially
when it is deployed as a single point of failure [16].
Although in [17] [15] a public blockchain is proposed
for DDoS signaling collaboration, in our opinion a private
blockchain should be used to provide security and privacy
of the CTI sharing environment. Public blockchains utilize
challenging consensus mechanisms such as proof of stake or
proof of work which diminishes the overall performance of
the collaboration system.
III. PROP OS ED ARCHITECTURE
Fig. 2 shows the proposed architecture of a CTI shar-
ing platform for conducting collaborative mitigation against
large scale DDoS attacks launched across multiple network
domains. This architecture combines SDN-based policy en-
forcement and blockchain-based CTI sharing which enables
an automated and agile DDoS defense framework. In the

following sections we outline some technical details of the
architecture
A. CTI Sharing Format
In conventional CTI sharing, unstructured threat information
is collected and exchanged using generic insecure tools such
as telephone and email. In contrast, a structured model uses
a standard format for the entire process [6]. For example, the
U.S. Department of Homeland Security utilizes the Structured
Threat Information eXpression (STIX) format, which is based
on JSON [18]. The STIX Domain Objects (SDOs) describe in-
formation associated with CTI, e.g. attack patterns, campaigns,
malware, indicators.
An SDO also includes the Course of Action object to
describe actions that could be performed to prevent or mitigate
an attack. In our architecture, SDOs are used to exchange
cyber threat intelligence between participants.
B. Blockchain Concept
A blockchain is a immutable distributed ledger for storing
information of transactions between various untrusted parties.
The Bitcoin cryptocurrency is the most well-known application
of a public (permissionless) blockchain. However, a public
blockchain is not suitable for enterprise environments as it
might threaten the data privacy of the parties. Therefore, in
order to share extremely sensitive information with groups of
partners, we propose to use a private blockchain for providing
interaction among known participants with common objectives
but without having a fully trusted relationship [19].
The Hyperledger Fabric (HLF) is an open-source permis-
sioned blockchain designed for enterprise environments which
has some distinctive features compared to other blockchain
technologies. In the beginning, each transaction is concurrently
executed by the endorsing blockchain peers and verified by
a group of them. Then, signed and verified transactions are
ordered through the consensus protocol. Finally, the blocks
are generated and written on the ledger. In the following sub-
section, we outline the key components of the HLF framework.
1) Smart Contract: The joint understanding of a business
logic between different parties can be deployed through a
smart contract (a chaincode in HLF terminology). It performs
pre-defined actions when particular circumstances are reached.
In comparison to manual methods, this reduces the time to
mitigate as well as facilitates business process automation.
2) Blockchain Network: Generally, an HLF network con-
sists of various components: peer node, channel, orderer node,
and client application. Each organization participating in the
blockchain maintains one or more peer nodes. An individual
peer node hosts chaincodes and ledgers in every blockchain
network. A ledger provides a tamper-resistant storage, which
is a principal element of each peer node to keep records of all
state transitions. In addition, an HLF network allows multiple
channeling where only participants authenticated by a channel
can collaborate.
The ordering service is responsible for ordering transactions
that will be stored in the ledgers. The order of transactions
should be established in a way that avoids inserting wrong
transactions into the ledger (caused by error or malicious
actors). This could be done through a consensus algorithm
that plays a significant role in the whole transaction flow [20].
The client application uses the Fabric Software Develop-
ment Kit (SDK) for interacting with the blockchain to either
submit a transaction or retrieve content from it. The APIs
provided by the SDK allow client applications to communi-
cate with the peer node and invoke the chaincode to create
transactions.
C. SDN Infrastructure
SDN enables the creation of customized applications which
interact with various SDN components through standard APIs.
In our architecture, a client application communicates with
the blockchain and the SDN controller. It can submit or
retrieve CTI from the blockchain using the Hyperledger Fabric
SDK. Simultaneously, the client application is also interacting
with the SDN controller through (RESTful) APIs to enforce
mitigation policies e.g. by implementing blacklists (containing
malicious IP addresses) on the SDN switches [5].
D. Collaborative DDoS Mitigation
Figure 2 shows a multi-domain SDN network setup, where
each network domain represents a different Autonomous Sys-
tems (AS). We aim to perform the DDoS mitigation as close
as possible to the sources of the attack. Each individual AS is
contributing CTI via the blockchain using smart contracts. In
the example scenario the victim located in AS2 submits the
incident to the blockchain in the form of STIX domain objects,
including a blacklist of illegitimate IPs. Then, according to the
smart contracts, the respective AS(s) receive the blacklist and
enforce corresponding mitigation rules (e.g. traffic blocking
or rate-limitation) to the SDN switches close to the malicious
clients.
IV. CAS E STU DY
For the case study we implemented the CTI sharing platform
based on a private HLF blockchain application and evaluate
the performance of the collaborative DDoS attack mitigation
in a multi-domain SDN environment.
As depicted in Fig. 3, we utilize Kathara [21] to emulate a
multi-domain SDN network with two SDN controllers. Within
Kathara, we use Ryu [22] as SDN controller and OpenVSwitch
[5] to realize the the OpenFlow-enabled SDN switches. The
BGP [23] [22] app in the Ryu controller enables the OpenFlow
SDN switches to act as a BGP speaker; thus, the two SDN
networks are able to communicate via the BGP protocol. We
use a Linux computer (Ubuntu 16.04. ) equipped with a Intel
i5 CPU with 2.40GHz clock rate and 8.0 GB RAM to run
both Kathara and the Hyperledger Fabric V1.1 in a single
VM instance (using 4 CPU cores and 4 GB RAM). As shown
in Fig. 3, there are two hosts attached to an OpenFlow SDN
switch in AS1.
In normal mode of operation, every host from either AS1
or AS2 can legitimately access the website located in AS1.

Fig. 3: Scenario: two SDN networks with two separated Ryu
controllers communicating via BGP.
In the attack scenario, two hosts in AS2 are generating TCP
SYN flood DDoS traffic towards the web server. The CTI app
has two main modules: 1) POST, to submit a transaction in
the blockchain, and 2) GET, to read from the blockchain. We
assume that a blacklist of these hosts, which have illegitimate
IP addresses, is stored in a log file. The CTI App 1 periodically
examines if the blacklist is updated. If so, the new blacklist
will be inserted into the HLF using the POST module in the
App. Meanwhile, in AS2, the CTI App 2 periodically checks
for new content in the HLF and retrieves the blacklist using
the GET module. Then, the corresponding flow rules will be
issued and loaded into the OpenFlow SDN switch to block the
malicious hosts in AS2.
Our blockchain architecture comprises two organizations,
each representing an AS. There is one orderer node for the
whole blockchain, together with two peer nodes for each
organization. The Certificate Authority (CA) in each orga-
nization registers and enrolls the CTI application through
various cryptographic schemes for authenticating the App to
the blockchain network. Then, the App submits a transaction
proposal to the endorsing peer nodes.
Every peer node executes the chaincode using the proposed
transaction to sign, generates a transaction response and sends
it to the CTI application. Once the application receives signed
transactions, it will submit all of them to be ordered.
The ordering service collects transactions into blocks to be
distributed to the corresponding peer nodes. Finally, each peer
validates the received signed transaction to fulfill the endorsing
policy. Successfully validated transactions are submitted to the
ledger while the invalid ones are discarded.
A. Scalability Evaluation
In our demonstration, the DDoS attack mitigation is accom-
plished instantaneously - once the blacklist is shared in HLF,
the incoming attack traffic from AS2 against the web server
is immediately terminated.
We use the Hyperledger Caliper [24] benchmark tool to
evaluate the performance of the Hyperledger blockchain im-
plementation. It can generate reports including various per-
Fig. 4: HLF benchmark architecture: three organizations with
one peer per organization
formance parameters such as the number of Transaction Per
Second (TPS), the transaction latency, and the computing
resource consumption.
Notwithstanding our implementation depicted in Fig. 3, for
performance evaluation we scaled up the blockchain network
towards three organizations, see Fig. 4. The setup uses the Solo
consensus protocol of Hyperledger Fabric with an Orderer
node through a single channel. The Solo implementation is
convenient for a proof of concept but it is not recommended for
real production environments due to the absence of fault toler-
ance. Each of the three organizations includes one peer node
that owns administration privilege over the entire network. A
variable number of clients are generating random-length STIX
objects as transactions through all three organizations. We use
the same hardware and virtual machine configuration as in
our previous demonstration for carrying out the benchmarking
experiments. The virtual machine hosts every node in the
blockchain network as Docker container [25].
V. RESULTS AND DISCUSSION
Figure 5 shows the total executed transactions per second,
the so-called real throughput in Transaction Per Second (TPS)
versus the number of input transactions. At each benchmark
iteration, we submit groups of 500, 1000, 1500, 2000, 2500
input transactions into the HLF varying also the send rates (i.e.,
50, 100, 150 TPS). For each bunch of inputs, every individual
transaction is submitted sequentially until the last one has
reached its destination. Fig. 5 shows no significant changes of
the real throughput for a send rate of 50 TPS across different
number of input transactions. Meanwhile, for the other two
send rates (100, 150) a slight reduction of the real throughput
is observed, when increasing the number of input transactions.
As expected, the performance of the blockchain network
highly depends on the underlying hardware. The Hyperledger
Fabric provides a three-stage revolutionary architecture known

Fig. 5: Real throughput vs. number of transactions and send
rates
Fig. 6: Min, Max and Avg latency vs. number of transactions
and send rate = 100 TPS
Fig. 7: Number of successful transactions vs. send rates with
sending time interval = 20 sec
Fig. 8: Real throughput vs. send rates and number of clients
as execute-order-validate [19] in which every stage depends
on previously executed transactions. Hence, a less powerful
computer is not able to provide a high transaction throughput,
leading to performance degradation. Our results show that a
send rate of 50 TPS is sustainable, as the actual throughput
is 49.7. However, increasing the send rate to 100 and 150
TPS, yields only to a marginal throughput increase of 59.7
and 61.1, respectively. This lead to the conclusion that our
setup can sustain a send rate of about 60 TPS.
We denote latency as the time interval between the time
a transaction is sent to the blockchain and the time that the
same transaction is confirmed. The maximum, minimum, and
average latency for a send rate of 100 TPS (as an example)
are shown in Fig. 6. The maximum latency grows to nearly 36
seconds as the number of input transactions increases. This is
due to resource restrictions of the containers allocated to the
peer nodes. The minimum latency remains almost constant
as there are no high loads imposed on the peer nodes at
the beginning. Also, the blockchain configuration (e.g., the
block size, the number of channels, ordering service, users,
endorsing nodes) influences the latency.
To measure the number of successful transactions assuming
a fixed sending time interval, e.g. 20 seconds, we ran the
benchmark with different send rates (i.e., 20, 40, 60, 80, 100)
- the results are shown in Fig. 7. It can be observed that in all
cases all transactions are successfully completed i.e. no loss
of transactions occur. However, the time until all transactions
are successfully completed is larger than 20 seconds. This
corresponds to the difference of the real throughput (e.g. 60
TPS) and the send rate (e.g. 100 TPS).
Despite security and privacy, latency and throughput are
important performance metrics when selecting an appropri-
ate blockchain platform for CTI applications. For instance,
the latency requirements for feeding security functions (e.g.,
for a firewall) in an attack mitigation scenario differs from
sharing CTI for increasing the awareness of a security team
during normal system operation. The resource allocation for
the blockchain network has to be done so that the latency
requirements are met (for a given input load) . As an example,
in our lab setup 2500 transactions with an input send rate of
100 TPS lead to an average latency of 17 seconds and an
average throughput of 53.3 TPS. A lightweight virtual machine
can be deployed to host several components of the blockchain
network on a low-cost cloud service or even on a tiny computer
like the Raspberry Pi [26]. For enterprise-scale deployment
with thousands of CTIs per day, the provisioning of sufficiently
large computation resources is essential.
Our previous experiments considered only an individual
client in the blockchain network to generate all transactions.
In Fig. 8, we compare the real throughput for 1000 input

transactions when the number of clients changes (C=1, 10,
20). It can be seen that an increase in the number of clients
leads to a reduction in throughput due to the consumption of
more resources.
VI. CONCLUSION
The main objective of this paper is to present a Cyber
Threat Intelligence (CTI) sharing platform based on a private
blockchain addressing common CTI collaboration issues. We
demonstrate the application of this platform to mitigate DDoS
attacks in a multi-domain SDN network. Upon receiving
CTI information (through various STIX 2.0 objects), the
corresponding security policies are issued and enforced on
the SDN network to prevent or reduce the risk of threat-
ening incidents. For our CTI sharing platform, we propose
to use the Hyperledger Fabric as open-source blockchain
framework to provide security, privacy, and B2B requirements.
We believe that our model could address various concerns
of the current CTI sharing platforms. It provides a secure
infrastructure where multiple members can preserve their
privacy and share sensitive intelligence information. Moreover,
SLA requirements could be formulated in the form of smart
contracts. Hence, when certain conditions are met, the system
would automatically enforce appropriate actions. Also, the
immutability nature of the blockchain guarantees the tamper-
resistance property of all logs and transactions submitted in
the ledger. Consequently, it provides transparency as well as
traceability, facilitating the implementation of SLAs.
ACK NOW LE DG EM EN T
This work has been performed in the framework of the
Celtic-Plus project SENDATE Secure-DCI, funded by the
German BMBF (ID 16KIS0481).
Financial support from Science Foundation Ireland grants
14/IA/252 (O’SHARE) and 13/RC/2077 is gratefully acknowl-
edged.
REFERENCES
[1] W. Tounsi and H. Rais, “A survey on technical threat intelligence in the
age of sophisticated cyber attacks,” Computers & security, vol. 72, pp.
212–233, 2018.
[2] Dr. Jamie Graves, “Reactive vs. proactive cybersecurity: 5 reasons why
traditional security no longer works,” 2019.
[3] Dave McMahon, Rafal Rohozinski,Bell Canada , “The dark space
project - defence research reports,” 2013.
[4] verizonenterprise.com , “2015 data breach investigations report,” 2015.
[5] D. Kreutz, F. Ramos et al., “Software-defined networking: A compre-
hensive survey,” arXiv preprint arXiv:1406.0440, 2014.
[6] A. Mohaisen, O. Al-Ibrahim et al., “Rethinking information sharing for
threat intelligence,” in Proceedings of the fifth ACM/IEEE Workshop on
Hot Topics in Web Systems and Technologies. ACM, 2017, p. 6.
[7] G. D. Webster, R. L. Harris et al., “Sharing is caring: Collaborative
analysis and real-time enquiry for security analytics,” in iThings. IEEE,
2018, pp. 1402–1409.
[8] E. U. A. for Network and I. S. (ENISA), “Exploring the opportunities
and limitations of current threat intelligence platforms,” Tech. Rep.,
2017.
[9] W. Pourmajidi and A. Miranskyy, “Logchain: Blockchain-assisted log
storage,” in 2018 IEEE 11th International Conference on Cloud Com-
puting (CLOUD). IEEE, 2018, pp. 978–982.
[10] S. Brotsis, N. Kolokotronis et al., “Blockchain solutions for foren-
sic evidence preservation in iot environments,” arXiv preprint
arXiv:1903.10770, 2019.
[11] M. Hajizadeh, T. V. Phan et al., “Probability analysis of successful
cyber attacks in sdn-based networks,” in 2018 IEEE Conference on
Network Function Virtualization and Software Defined Networks (NFV-
SDN). IEEE, 2018, pp. 1–6.
[12] B. Rodrigues, T. Bocek et al., “Enabling a cooperative, multi-domain
ddos defense by a blockchain signaling system (bloss),” Semantic
Scholar, 2017.
[13] S. Hameed and H. A. Khan, “Leveraging sdn for collaborative ddos
mitigation,” in 2017 International Conference on Networked Systems
(NetSys). IEEE, 2017, pp. 1–6.
[14] R. M. A. Mortensen, T. Reddy, “Ddos open threat signaling
(dots) requirements,” RFC 8612, May 2019. [Online]. Available:
https://www.rfc-editor.org/info/rfc8612
[15] Z. A. El Houda, A. S. Hafid et al., “Cochain-sc: An intra-and inter-
domain ddos mitigation scheme based on blockchain using sdn and smart
contract,” IEEE Access, vol. 7, pp. 98893–98 907, 2019.
[16] Z. Guangsen, M. Parashar et al., “Cooperative defence against ddos
attacks,” Journal of Research and Practice in Information Technology,
vol. 38, no. 1, p. 69, 2006.
[17] B. Rodrigues, T. Bocek et al., “A blockchain-based architecture for
collaborative ddos mitigation with smart contracts,” in IFIP International
Conference on Autonomous Infrastructure, Management and Security.
Springer, Cham, 2017, pp. 16–29.
[18] J. W. Bret Jordan, Rich Piazza, “Stix™ version 2.0. part 2: Stix objects,”
Tech. Rep. 8612, Jun 2017.
[19] E. Androulaki, A. Barger et al., “Hyperledger fabric: a distributed
operating system for permissioned blockchains,” in Proceedings of the
Thirteenth EuroSys Conference. ACM, 2018, p. 30.
[20] “A blockchain platform for the enterprise,” 2019. [Online]. Available:
https://hyperledger-fabric.readthedocs.io/en/latest/
[21] “Kathara,” [Online]. Available:http://www.kathara.org/.
[22] “Ryu,” [Online]. Available: https://osrg.github.io/ryu/.
[23] S. H. Y. Rekhter, T. Li, “A border gateway protocol
4 (bgp-4),” RFC 4271, January 2006. [Online]. Available:
https://tools.ietf.org/html/rfc4271
[24] “Hyperledger caliper,” [Online]. Avail-
able:https://www.hyperledger.org/projects/caliper.
[25] “Docker,” [Online]. https://www.docker.com/products/container-
runtime.
[26] “raspery pi,” [Online]. https://www.raspberrypi.org/.