Blockchain-Based Whitelisting for Consumer IoT Devices and Home Networks

Abstract

Internet of Things (IoT) devices present different security challenges that have not been addressed yet and there is no clear commitment from stakeholders to do so. Such problems have become evident and IoT devices are targets of malicious actors that employ them as instruments to fulfill their nefarious purposes. Recent attacks to major Internet services have shown the real damage vulnerable devices can make when compromised. Many of the endangered devices sit in home-based environments with users that are not familiar with security or network best practices, which make them easy targets for bad actors. Therefore, there exists the need to find practical solutions using existing technologies that have been, so far, proven to be efficient, such as the blockchain. This paper implements a proof of concept to secure consumer/home-based IoT devices and the networks around them using blockchain technology powered by Ethereum. The results obtained support the idea of a whitelisting application based on the Ethereum protocol.

Full text

Blockchain-Based Whitelisting for Consumer IoT Devices and
Home Networks
Diego M. Mendez Mena∗
Purdue University
West Lafayette, Indiana
dmendezm@purdue.edu
Baijian Yang†
Purdue University
West Lafayette, Indiana
byang@purdue.edu
ABSTRACT
Internet of Things (IoT) devices present dierent security challenges
that have not been addressed yet and there is no clear commitment
from stakeholders to do so. Such problems have become evident
and IoT devices are targets of malicious actors that employ them
as instruments to fulll their nefarious purposes. Recent attacks
to major Internet services have shown the real damage vulnerable
devices can make when compromised. Many of the endangered
devices sit in home-based environments with users that are not
familiar with security or network best practices, which make them
easy targets for bad actors. Therefore, there exists the need to
nd practical solutions using existing technologies that have been,
so far, proven to be ecient, such as the blockchain. This paper
implements a proof of concept to secure consumer/home-based IoT
devices and the networks around them using blockchain technology
powered by Ethereum. The results obtained support the idea of a
whitelisting application based on the Ethereum protocol.
CCS CONCEPTS
•Security and privacy →Network security
;
•Computer sys-
tems organization →Embedded systems;
KEYWORDS
Home Network Security; Whitelisting; Blockchain; Ethereum
ACM Reference Format:
Diego M. Mendez Mena and Baijian Yang. 2018. Blockchain-Based Whitelist-
ing for Consumer IoT Devices and Home Networks. In The 19th Annual
Conference on Information Technology Education (SIGITE ’18), October 3–
6, 2018, Fort Lauderdale, FL, USA. ACM, New York, NY, USA, 6 pages.
https://doi.org/10.1145/3241815.3241853
1 INTRODUCTION
The Internet of Things (IoT) is intended for ubiquitous connectivity
among dierent entities or “things” [
15
]. While its purpose is to
provide eective and ecient communications between devices
∗
Center for Education and Research in Information Assurance and Security (CERIAS)
†Department of Computer and Information Technology
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specic permission and/or a
fee. Request permissions from permissions@acm.org.
SIGITE ’18, October 3–6, 2018, Fort Lauderdale, FL, USA
©2018 Association for Computing Machinery.
ACM ISBN 978-1-4503-5954-2/18/10. . . $15.00
https://doi.org/10.1145/3241815.3241853
and users or other devices, security of the IoT and its network
has become a challenging issue. The number of devices connected
along with the ad-hoc nature of the systems further exacerbates the
situation. In fact, by the end of 2020 it is estimated that there would
be around 20 billion connected IoT devices [
9
]. The data exchanged
over the network will be greater than 40 Zettabytes [ZB] for the
same period [
8
]. In October 2016, the massive Distributed Denial
of Service (DDoS) attack targeting Dyn - a company that controls
much of the Internet’s domain name system (DNS) infrastructure -
by a botnet army of IoT infected devices, has turned on the alarms
on the consequences that faulty IoT protections and poor standards
can motivate [
16
]. Such intrusions and attacks accentuate the need
for additional research in the IoT security domain.
Even though security researchers have expressed their concern
over the weaknesses of IoT systems, the intrinsic principle of energy
eciency as well as low computing power available on embedded
devices are in some way antagonistic to the existing cryptography
applications and securing algorithms. The paradox described before
produces increasingly challenging environment for the IoT and its
community [
15
]. Nevertheless, new technology has been disrupt-
ing the current Internet environment by providing new ways to
securely exchange digital assets by the use of strong cryptographic
principles and sound engineering protocols, called cryptocurrency
and the blockchain technology that supports it.
The purpose of this paper is to introduce a novel application of
the blockchain protocol to protect the edge of the home network
and, therefore, the IoT devices in it. The authors have tested the
novel solution and compared it to a similar whitelisting application
to verify its feasibility and appropriateness.
2 LITERATURE REVIEW
During recent years, the number of IoT devices and the data handled
by them has increased signicantly [
15
]. IoT devices and applica-
tions have found their way through dierent environments, even-
tually they have reached users’ homes and they have brought with
them their advantages as well as their deciencies. Bertino & Nay-
eem [
3
] compiled a list of the most common vulnerabilities found
in IoT devices that include: Insecure web interfaces, insucient au-
thentication, insecure network services (prone to Denial-of-Service
(DoS) attacks), privacy concerns, insucient security congura-
bility, insecure software and poor physical security. IoT devices’
intrinsic behavior of keeping a constant operation, besides the weak
protection and poor and/or non-existence maintenance, make them
“advantageous for creating botnets” [
12
, p. 83]. In fact, researchers
have scanned the Internet to nd publicly available embedded de-
vices that are vulnerable to basic security probes. Their results
Session 1A: Papers Applied
SIGITE’18, October 3-6, 2018, Fort Lauderdale, FL, USA
7

found over 540,000 devices that are accessible by using default cre-
dentials [
6
]. Costin et al. [
5
] also analyzed the rmware of 32,000
embedded devices and identied over 2,000 devices that presented
hard-coded telnet passwords and other type of backdoors. Home
routers are included on the list, and carry some other security aws
that make them extra vulnerable to common security attacks [11].
Moreover, the diculty and the cost of managing home-network de-
vices plus their proneness to failure creates a burden that is placed
on consumers, which increases the risk of network devices to be
compromised [22].
One of the consequences of the lack of security implementations
of embedded devices was the Mirai botnet attack in 2016. Mirai
is considered as “one of the most potent Distributed-Denial-of-
Service (DDoS) attacks in history” [
12
, p. 80]. Mirai compromised
over 400,000 devices that included webcams, DVRs, routers, etc.
and was able to deliver 1.1 Tbps of malicious requests to the French
provider OVH. The attack vector used by Mirai was quite simple, it
scanned for devices available over port 23 and 223 and bruteforced
default credentials (62 username-password hardcoded pairs). Once
compromised the command and control (C&C) center shot Gen-
eral Routing Encapsulation (GRE), Transfer Control Protocol (TCP)
and Hypertext Transfer Protocol (HTTP) ooding attacks on deter-
mined targets to get them oine. Mirai and other variations are
still on the wild despite the warnings and consequences of keeping
susceptible devices publicly available to the Internet [12].
The security community has come up with dierent solutions
to mitigate DDoS attacks and botnet implications. Sivaramon et al.
[
18
] proposes a cloud-based solution to protect awed IoT devices
by dynamically managing the rewall rules for accessing the home
network or the Internet Service Provider’s (ISP) edge devices. Whyte
et al. [
21
] introduced a Domain Name System (DNS)-based detection
of scanning worms, it relies on keeping DNS records and creating a
whitelist of authorized communications based on the premise that
worms usually do not request DNS information to spread through
the network. Yoon [
23
] tries to address the other side of the issue by
proposing a whitelisting solution in order to prevent unauthorized
access and lter incoming requests to only allow the ones sourcing
from important clients, which maintains services even after a harsh
attack scenario. Whitelisting is now seen as common basic security
best practice which has been normalized on education curriculums
for IT and Cybersecurity careers [20].
As part of this study, the authors plan to include a brief review of
cryptocurrencies, the technology that supports it, the blockchain,
and current implementations of the blockchain in IoT environments.
The idea of virtual currencies has been around for quite some time
before appearing in a tangible and practical way with the intro-
duction of Bitcoin in 2008. Bitcoin is the result of almost three
decades of research that combines in a feasible way all the concept
and theories that make Bitcoin and the blockchain, the underlying
technology, a reality [
19
]. Bitcoin appears as a decentralized virtual
currency system where all transactions are public and transmitted
on a peer to peer basis with no central authority based on strong
cryptographic fundamentals. The most visible problem faced by
decentralized virtual currencies, called the double spending prob-
lem, was addressed by the Bitcoin developer(s) with the proposal of
the blockchain and the consensus algorithm backed up by compen-
sated “provers” or miners [
4
]. The blockchain provides a distributed
Figure 1: Blockchain data outlook [14]
environment that can be trusted by all of the existing nodes with-
out the need of a central authority. Technically, a blockchain is
a back-ordered hash list that is publicly shared in a peer-to-peer
network, refer to Figure 1. Usually, each member in the blockchain
system is addressable by the hash value of its public key. When a
new transaction occurs, the owner of the transaction can prove the
authenticity of the record (i.e. block) by encrypting the hash value
of the record using its private key. The newly formed block is then
appended to the existing blockchain and points to the previous
block. Supported by the cryptographic properties of hash functions
and asymmetric encryptions, a blockchain can therefore ensure
each block is immutable and each transaction is veriable.
Given the secure properties of the chain, the IoT community has
started to provide more attention to it. Researchers and practitioners
believe blockchain is one of the key technologies that can securely
enable smart contracts among the “things” [
13
]. That is, smart
devices can interact and transact with each other autonomously
without human interventions. Though, it is possible to implement
blockchains in a public network, the computing overhead of provid-
ing proof of work (mining) may overwhelm the limited computing
resources in an IoT network. If on the other hand, participating
members in a blockchain network are not completely trustless, sim-
ple techniques, such as whitelisting, can be leveraged to reduce
the burden of mining and make blockchains much more desirable
in real world practice. It should be noted that, blockchains oer
only pseudo anonymity: it is possible for adversaries to make in-
ferences about who owns what public keys. If privacy is a major
concern in an IoT system, additional mechanism must be designed
and implemented to prevent the owners of the smart devices being
identied.
Shrier et al. [
17
] have identied in their report the current ap-
plications where blockchain solutions can be applied to, which
includes identity management and authentication requirements
for securing network infrastructure without the need of a central
authority. Azaria et al. [
2
] and Zyskind et al. [
24
] have even gone
further and applied the blockchain and smarts contracts to secure
sensitive data and to allow users to access it securely. Nevertheless,
Gramoli [
10
] averts some dangers of the use of private blockchains
that are susceptible to Byzantine and Sybil attacks that may un-
dermine the security of proven cryptographic principles and the
consensus protocol of the nodes.
3 PROPOSAL
The main goal of this work is to document the implementation of
a blockchain-based gateway that will be used as a“gatekeeper”, it
will be able to identify valid and invalid actors that try to access
resources from a home/private network. The gatekeeper will use
the information provided on a dened smart contract, that can
Session 1A: Papers Applied
SIGITE’18, October 3-6, 2018, Fort Lauderdale, FL, USA
8

Figure 2: Network and logical diagram
be only modied by pre-established users or computers, to dene
whether or not to allow trac through it, rewall-like. Once the
information provided has been parsed by the internal script it will
generate the whitelist that will feed the rewall application running
on the device.
3.1 Assumptions and Limitations
The current proof of concept has been simplied and it only pro-
vides the evidence the network implementation works and are
able to interact as expected. In the rst place, we assume that all
blockchain parties, that do not deal with network access, behave cor-
rectly under the rules and algorithms determined by the Ethereum
protocol. Second, the private Ethereum network security relies
on a limited number of nodes and miners who behave correctly,
during the proof of concept only the authors have access to the
Ethereum private network. Also, the smart contracts have not been
secured as they should be for simplicity, like limiting the access to
the contract or the ability to edit it. The current implementation of
the gatekeeper only permits or denies access based on layer three
information, which can be bypassed by other attacks that have not
been included in this work’s threat model. Moreover, no privacy
safeguards have been taken to protect the generated whitelist nor
its implications if compromised. However, the authors do plan to
address this problem in the future. Finally, the user interfaces have
not been modied nor improved by the authors which might bring
usability challenges if the nal user does not have been previously
exposed, in detail, to the software and its operation.
3.2 Functionality
A private Ethereum network was setup between three dierent
nodes installed in three dierent computers, one of them installed
in the gatekeeper. The dierent devices inside or outside the test
network have private Ethereum accounts that were used as the link
between the users, the gatekeeper, and other components of the
Ethereum blockchain. Each of the accounts are created through the
Ethereum console and are cryptographically protected by asymmet-
ric keys using the default Ethereum method for key management,
Elliptic Curve Cryptography (ECC). The gatekeeper maintains a
restricted OSI layer three policy for inbound access, for proof of con-
cept simplicity, that can only be modied by express authorization
provided by the interaction with the blockchain. A smart contract
has been in placed to determine access authorization (whitelisting)
to the internal network, the users interact with the contract via
web where the local network information is introduced as a string
variable and all the values are hashed for integrity. The contract
can be “closed” to only allow communication for whitelisted user
accounts and then pass over the information to the gatekeeper node
and account. The gatekeeper node reacts,via a Python script, and
allows access to the network after the transactions have been added
to the blockchain and by reading the elements posted in the last
transaction. The transactions and interactions with the blockchain
are mined by two dierent nodes in the network. The design has
been laid out in Figure 2.
The security of the method relies on the security that the blockchain
oers, all the transactions can be veried by all nodes and cannot
be changed or tempered, when the majority of the nodes are in
control of trusted parties. This document presents the following
security protections based on the IoT threat model presented by
[
1
], and specically related to the external adversary entity. The
authors of [
1
, p. 38] refer to the external adversary as: “An outside
entity that is not part of the system and has no authorized access to
it. An adversary would try to gain information about the user of the
system for malicious purposes such as causing nancial damage
and undermining the user’s credibility. Also, causing malfunction
to the system by manipulating the sensing data”. Finally, in order to
compromise the nodes and the accounts, the cryptographic features
must be bypassed or attacked, which means the computationally
diculty problem must be solved.
4 METHODS
In order to test the proposed solution the authors ran two instances
of the same network, the rst one utilized a basic whitelisting
application on the Raspberri Pi (Gatekeeper) by interacting with the
embedded rewall application: IPTables. The rst scenario does not
Session 1A: Papers Applied
SIGITE’18, October 3-6, 2018, Fort Lauderdale, FL, USA
9

Figure 3: Hardware used as Gatekeeper
interact with any of the blockchain instances. The second scenario
used the same hardware as the previous one but also interacts with
all blockchain instances and scripts mentioned in Section 3. The data
obtained based on the parameters listed on the following sections
were compared statistically to determine signicant dierences
between both testing scenarios.
4.1 Network Components: Hardware and
Software
4.1.1 Scenario One - Firewall-only Network.
•Home router - Netgear AC750 wireless router.
•
Gatekeeper - Raspberry Pi 3 model B embedded computer
running Raspian OS, Jessie 8.9. IPtables for rewall applica-
tion. The device has attached one USB-to-Ethernet adapter
for internet trac active forwarding.
•
IoT devices - Dahua PoE IP camera IPC-HDW4431C-A, Wemo
light switch F7C030fc, Wemo outlet switch F7C027fc, and
Amazon Echo Dot second generation.
•
Other Devices in Network (“Client” Computer) - Mac desktop
running OS High Sierra 10.13.1
4.1.2 Scenario Two - Blockchain-enabled Network.
•Home router - Netgear AC750 wireless router.
•
Gatekeeper - Raspberry Pi 3 model B embedded computer
running Raspian OS, Jessie 8.9. The device runs Ethereum
geth version 1.6.3, webpy version 1.6.3 and IPtables for re-
wall application, Figure 3. The device has attached one USB-
to-Ethernet adapter for internet trac forwarding.
•
Blockchain nodes (Scenario Two only) - All blockchain nodes
run a full version of Ethereum geth 1.6.3.
•
IoT devices - Dahua PoE IP camera IPC-HDW4431C-A, Wemo
light switch F7C030fc, Wemo outlet switch F7C027fc, and
Amazon Echo Dot second generation.
•
Other Devices in Network (“Client” Computer) - Mac desk-
top running OS High Sierra 10.13.1, serves as management
console for Raspberry Pi, blockchain mining and Smart Con-
tract interaction through Remix-Solidity web application.
4.2 Testing Parameters
The authors have considered the following parameters to measure
scenario eciency and to provide comparing points between both
implementations. There exists some parameters taken in Scenario
One that cannot be applied to the second implementation, those
were taken for information purposes only. The data was collected
every ve minutes over a twenty-four hour period for each imple-
mentation, which consists of actual network trac, not syntheti-
cally generated. The whitelisted IP addresses, for both scenarios,
have already been loaded for testing simplicity. The criteria to add IP
addresses to the whitelist is based on well-known and monitoring-
obtained source/destination information taken from IoT-device
manufacturers and common use respectively. The whitelist infor-
mation is the same for both scenarios. For sake of functionality
for the proof of concept, an illegitimate attempt, from an external
non-whitelisted IP address, was made every two hours during the
same testing period. The testing parameters are the following:
(1) Gatekeeper Central Processing Unit (CPU) load (%)
(2) Client CPU load (%)
(3) Gatekeeper Disk Usage (Gigabytes [GB])
(4) Client Disk Usage (GB)
(5) Gatekeeper Random Access Memory (RAM) usage (GB)
(6) Client RAM usage (GB)
(7)
Number of authorized packets at Gatekeeper [Informational]
(8) Number of dropped packets at Gatekeeper [Informational]
(9)
Number of active/passive connections at Gatekeeper [Infor-
mational]
(10)
Number of connection resets at Gatekeeper [Informational]
For Scenario Two only (between testing periods at Gatekeeper only)
[Informational]:
•
Time taken to add IP address to blockchain (time taken for
contract mining) in miliseconds (ms)
•
Time taken to apply whitelisting script at Gatekeeper after
blockchain entry acceptance (ms)
5 RESULTS AND DISCUSSION
5.1 Results
Two hundred and eighty eight equally distributed samples were
obtained over a twenty-four hour period for each one of the sce-
narios, except for informational blockchain and script data from
Scenario Two. Due to space limitations, the original data set won’t
be included in this publication and will be available upon request
only. Nevertheless, we have included average calculations for in-
formation purposes, Table 1.
5.1.1 Statistical Analysis. Given the independent nature of the
scenarios, a two-sample t-test has been performed to Scenario 1 and
Scenario 2 data sets to compare the performance between the two
implementations with a 95% condence level [
7
]. The parameters
used for comparison are CPU load, disk and RAM usage for the
client, and gatekeeper devices.
The disk usage on the Gatekeeper and the client computer did
not show signicant dierence between scenarios. Moreover, the
usage on both did not vary between any of the samples, therefore,
no statistical analysis was able to perform on this data. Nevertheless,
the CPU load (
p−value <
0
.
0001), gure 4(a), and the RAM usage
Session 1A: Papers Applied
SIGITE’18, October 3-6, 2018, Fort Lauderdale, FL, USA
10

Table 1: Mean and standard deviation for both testing scenarios
Parameter Scenario 1 σ1Scenario 2 σ2
Gatekeeper CPU load [%] 0.1286 0.1038 0.8167 0.2775
Client CPU load [%] 13.2633 10.6925 73.3718 6.8044
Gatekeeper Disk Usage [GB] 1.400 0 1.400 0
Client Disk Usage [GB] 548.600 0 548.600 0.0003
Gatekeeper RAM usage [GB] 0.3316 0.0039 0.4922 0.017
Client RAM usage [GB] 7.8915 0.1109 7.5314 0.5711
Number of authorized packets per sample at Gatekepeer 555,493 - 3,223,788 -
Number of dropped packets per sample at Gatekepeer 120 248 -
Number of active/passive connections per sample at Gatekepeer 2.75 - 38.75
Number of connection resets per sample at Gatekepeer 1.25 - 3.5 -
Time taken to add IP address to blockchain [ms] N/A - 49.463 -
Time taken to apply whitelisting script at Gatekeeper after blockchain entry acceptance [ms] N/A - 15,322.5 -
(
p−value <
0
.
0001), gure 4(b), on the Gatekeeper, as well as and
the CPU load (
p−value <
0
.
0001), gure 4(c), and the RAM usage
(
p−value <
0
.
0001), gure 4(d), for the client computer did show
statistical signicance between datasets, all of them with numerical
increase on scenario two, except for the client RAM usage.
(a) (b)
(c) (d)
Figure 4: Box Plot: (a) GK CPU load, (b) GK RAM usage, (c)
Client CPU load, and (d) Client RAM usage.
5.2 Discussion
The results obtained at the client computer level on the CPU load
was expected by the authors since scenario two carried more com-
plex tasks such as mining and node peering. However, the client’s
disk usage did not increment signicantly even though over 70,000
Ethereum blocks were processed and stored over the sampling pe-
riod. The RAM usage value presented a interesting behavior, the
value on the rst scenario surpassed the second one even though
greater vales were expected after the blockchain application was
started, which may mean that running an Ethereum node does
not take a toll on the device performance. On the Gatekeeper side,
the CPU load and RAM usage presented signicant dierences,
see Table 1. Even though the processing capacity of the Raspber-
ryPi is far more limited than the client computer used in the study,
numerically, it cannot be considered as a burden for the device.
The overall CPU usage never increased over 2%, gure 5(a), and
the RAM usage, gure 5(b), value did not surpass the 51% mark
when sampled, which means no memory scarcity was suered by
the embedded device and a heavier load can be applied on future
applications. The disk usage, as well, did not registered a change
within sampling periods, which did not go over 1.4GB from a 32
GB boundary given by the microSD card installed.
As expected, the number of packets managed by the blockchain-
enabled scenario was higher than the ones from the rst implemen-
tation, same with active/passive connections handled. It is quite
evident that the blockchain communication protocol on top of the
whitelisting tasks provokes an increase of IP trac to be managed
by the Gatekeeper. The drop packets and reset connections showed
the same behavior which is derived from the previous analysis.
However, the sparse controlled unauthorized attempts made from
non-whitelisted IP addresses from outside the network perimeter
may also have inuenced on the number of packets dropped and re-
set connections made by the rewall application of the Gatekeeper.
On broad terms, no overloading processes were perceived in any
of the scenarios nor memory scarcity perceived during testing. All
network components, including IoT devices, did not experience
lagging or functioning problems during the entire experiment.
During the implementation, the researchers experienced a rst-
hand IoT security problem involving the Dahua IP camera, which
was solved by the implementation of the whitelisting safeguards.
The device consistently required to connect to the chinese Alibaba’s
101.37.136.216 IP address (TCP port 8682) even though it was not
necessary for functionality. A dierent study may look to the infor-
mation exchanged in more detail to determine the true intent.
6 CONCLUSIONS AND FUTURE WORK
Basic whitelisting applications based on blockchain technology to
secure home-based networks and IoT devices is possible, at least
Session 1A: Papers Applied
SIGITE’18, October 3-6, 2018, Fort Lauderdale, FL, USA
11

(a)
(b)
Figure 5: Gatekeeper Sample Plot: (a) GK CPU load (%) over
time, and (b) Gatekeeper RAM usage (GB) over time.
under the circumstances and assumptions exposed in this work.
In addition, the security of the blockchain presents an additional
layer that prevents malicious actors to manipulate or introduce
bogus whitelist entries. The cryptographic features built in the
Ethereum protocol, such as asymmetric key encryption and digi-
tal signatures, strengthen the basic peer-to-peer communications
between network devices which makes intrusions less likely to
happen. Therefore, given the current implementation, with the
development of the planned improvements, might be the starting
point to a secure home-based network architecture model for IoT
devices. Moreover, the features oered by the distributed nature
of the blockchain plus the features introduced by the Ethereum
protocol open the door for future opportunities for decentralized
whitelisting based on information generated from dierent trusted
sources.
Nevertheless, for future work there are some improvement op-
portunities that need attention. For instance, additional threats
models should be taken into account before the solution can be de-
ployed in real scenarios. Additionally, further testing over a larger
network might be useful. Public Ethereum network deployment or
increase the number of private network nodes and accounts can de-
liver more conclusive results. Also, smart contract hardening needs
to be included in the future, code testing and best-practice auditing.
Privacy issues need to be considered to avoid user tracking and
data leaking.
Finally, new authentication methods can be introduced based
on the same whitelisting principle. Those may include a token
system or the exchange of “digital certicates” for secure session
initiation without a central authority. In addition, a decentralized
whitelisting/blacklisting service can be developed for a public net-
work of blockchain-enabled enforcers that share threat intelligence
information to prevent malicious trac from spreading.
ACKNOWLEDGMENTS
This work is partially supported by the Purdue Polytechnic Institute
HSS Seed Grant.
REFERENCES
[1]
Ahmad W Atamli and Andrew Martin. 2014. Threat-based security analysis
for the internet of things. In Secure Internet of Things (SIoT), 2014 International
Workshop on. IEEE, 35–43.
[2]
Asaph Azaria, Ariel Ekblaw, Thiago Vieira, and Andrew Lippman. 2016. Medrec:
Using blockchain for medical data access and permission management. In Open
and Big Data (OBD), International Conference on. IEEE, 25–30.
[3]
Elisa Bertino and Nayeem Islam. 2017. Botnets and internet of things security.
Computer 50, 2 (2017), 76–79.
[4]
Konstantinos Christidis and Michael Devetsikiotis. 2016. Blockchains and Smart
Contracts for the Internet of Things. IEEE Access 4 (2016), 2292–2303.
[5]
Andrei Costin, Jonas Zaddach, Aurélien Francillon, Davide Balzarotti, and Sophia
Antipolis. 2014. A Large-Scale Analysis of the Security of Embedded Firmwares..
In USENIX Security Symposium. 95–110.
[6]
Ang Cui and Salvatore J Stolfo. 2010. A quantitative analysis of the insecurity
of embedded network devices: results of a wide-area scan. In Proceedings of the
26th Annual Computer Security Applications Conference. ACM, 97–106.
[7]
Jay L Devore. 2011. Probability and Statistics for Engineering and the Sciences.
Cengage learning.
[8]
Forbes. [n. d.]. 152,000 Smart Devices Every Minute In 2025: IDC Outlines The
Future of Smart Things. https://bit.ly/2FNzLpt. [Online; accessed 06-December-
2016].
[9]
Gartner. [n. d.]. Gartner Says 6.4 Billion Connected "Things" Will Be in Use in
2016, Up 30 Percent From 2015. http://www.gartner.com/newsroom/id/3165317.
[Online; accessed 06-December-2016].
[10]
Vincent Gramoli. 2016. On the danger of private blockchains. In Workshop on
Distributed Cryptocurrencies and Consensus Ledgers (DCCLâĂŹ16).
[11] Emmanouil Karamanos. 2010. Investigation of home router security.
[12]
Constantinos Kolias, Georgios Kambourakis, Angelos Stavrou, and Jerey Voas.
2017. DDoS in the IoT: Mirai and other botnets. Computer 50, 7 (2017), 80–84.
[13]
Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor.
2016. Making smart contracts smarter. In Proceedings of the 2016 ACM SIGSAC
Conference on Computer and Communications Security. ACM, 254–269.
[14]
Medium. [n. d.]. A blockchain in 200 lines of code. https://medium.com/
@lhartikk/a-blockchain- in-200-lines-of-code- 963cc1cc0e54. [Online; accessed
14-November-2017].
[15] Diego Mendez Mena, Ioannis Papapanagiotou, and Baijian Yang. 2018. Internet
of things: Survey on security. Information Security Journal: A Global Perspective
(2018), 1–21.
[16]
Krebs on Security. 2016. DDoS on Dyn Impacts Twitter, Spotify, Reddit. https:
//krebsonsecurity.com/2016/10/ddos-on-dyn- impacts-twitter-spotify
[17]
David Shrier, Weige Wu, and Alex Pentland. 2016. Blockchain
& infrastructure (identity, data security). Technical Report. Re-
trieved 27-11-16, from http://cdn. resources. getsmarter. ac/wp-
content/uploads/2016/06/MIT_Blockain_Whitepaper_PartThree. pdf.
[18]
Vijay Sivaraman, Hassan Habibi Gharakheili, Arun Vishwanath, Roksana Boreli,
and Olivier Mehani. 2015. Network-level security and privacy control for smart-
home IoT devices. In Wireless and Mobile Computing, Networking and Communi-
cations (WiMob), 2015 IEEE 11th International Conference on. IEEE, 163–167.
[19]
Florian Tschorsch and Björn Scheuermann. 2016. Bitcoin and beyond: A technical
survey on decentralized digital currencies. IEEE Communications Surveys &
Tutorials 18, 3 (2016), 2084–2123.
[20]
James Walden. 2008. Integrating web application security into the I T curricu-
lum. In Proceedings of the 9th ACM SIGITE conference on Information technology
education. ACM, 187–192.
[21]
David Whyte, Evangelos Kranakis, and Paul C Van Oorschot. 2005. DNS-based
Detection of Scanning Worms in an Enterprise Network.. In NDSS.
[22]
Yiannis Yiakoumis, Kok-Kiong Yap, Sachin Katti, Guru Parulkar, and Nick McK-
eown. 2011. Slicing home networks. In Proceedings of the 2nd ACM SIGCOMM
workshop on Home networks. ACM, 1–6.
[23]
MyungKeun Yoon. 2010. Using whitelisting to mitigate DDoS attacks on critical
internet sites. IEEE Communications Magazine 48, 7 (2010).
[24]
Guy Zyskind, Oz Nathan, et al
.
2015. Decentralizing privacy: Using blockchain to
protect personal data. In Security and Privacy Workshops (SPW), 2015 IEEE. IEEE,
180–184.
Session 1A: Papers Applied
SIGITE’18, October 3-6, 2018, Fort Lauderdale, FL, USA
12