Available via license: CC BY-NC-SA 4.0
Content may be subject to copyright.
SERENIoT: Collaborative Network Security Policy
Management and Enforcement for Smart Homes
Corentin Thomasset
Polytechnique Montreal
Montreal, Canada
corentin.thomasset@polymtl.ca
David Barrera
Carleton University
Ottawa, Canada
david.barrera@carleton.ca
Abstract
Network traffic whitelisting has emerged as a dominant ap-
proach for securing consumer IoT devices. However, deter-
mining what the whitelisted behavior of an IoT device should
be remains an open challenge. Proposals to date have relied
on manufacturers and trusted parties to provide whitelists, but
these proposals require manufacturer involvement or placing
trust in an additional stakeholder. Alternatively, locally moni-
toring devices can allow building whitelists ofobserved behav-
ior, but devices may not exhaust their functionality set during
the observation period, or the behavior may change follow-
ing a software update which requires re-training. This paper
proposes a blockchain-based system for determining whether
an IoT device is behaving like other devices of the same
type. Our system (SERENIoT) overcomes the challenge of
initially determining the correct behavior for a device. Nodes
in the SERENIoT public blockchain submit summaries of
the network behavior observed for connected IoT devices
and build whitelists of behavior observed by the majority of
nodes. Changes in behavior through software updates are au-
tomatically whitelisted once the update is broadly deployed.
Through a proof-of-concept implementation of SERENIoT
on a small Raspberry Pi IoT network and a large-scale Ama-
zon EC2 simulation, we evaluate the security, scalability, and
performance of our system.
1 Introduction
The rapid adoption of the Internet of Things (IoT) challenges
well-established computer security strategies. Because of their
deployment scale, IoT devices cannot be secured using tradi-
tional techniques such as anti-malware or network intrusion
detection systems (NIDS). The diversity in IoT hardware, soft-
ware, and network footprint, combined with the deployment
volume makes it difficult to design security systems that are
effective yet not overburdened with management complexity.
This is of particular importance in smart homes, where users
are typically not security experts.
IoT devices are pervasive [20] and always connected. They
are manufactured to be low-cost, so security is often not the
primary design goal. As expected, numerous papers [1,7,27,
29] studying the security of IoT devices have found a steady
stream of vulnerabilities (e.g., the Mirai botnet [2]) that pose
a threat to users, to their environments, and to the broader
global Internet infrastructure.
While IoT devices are diverse, one unifying characteristic
is that their feature-set is generally simple; a device may sense
its environment and submit readings to a cloud service (e.g., a
humidity sensor), listen for inbound requests to perform some
action (e.g., a WiFi light switch), or some combination of
both. IoT devices by definition are not general purpose com-
puters
1
, and as such they do not require the network privileges
of a general purpose system to perform their primary task.
However, IoT devices are often treated indifferently from mo-
bile phones, laptops, and other general purpose systems on
networks, allowing any network communication that origi-
nates from the device to reach any host on the Internet. This
over privilege allows compromised devices to directly attack
remote hosts and services, or to act as steppingstones in more
sophisticated attacks.
To prevent these attacks, existing NIDS systems could be
used, but these require the user to configure operating parame-
ters and tune the detection logic to avoid being overwhelmed
by false positives. A conceptually simpler approach is the idea
of allowing only a small set of network traffic to flow to/from
an IoT device as needed. By whitelisting types of network
activity that a device can generate or accept (which should
roughly match the functional requirements of the device’s pri-
mary task), the device can be constrained without requiring
the modification of its software. This is of particular interest
in IoT, where devices may have long lifespans sometimes
outlasting the manufacturer or software update support period.
Moreover, false positives (i.e., blocking legitimate outbound
connections) should be few and far between if the device can
be accurately profiled.
1
We note, however, that some IoT devices may be built on top of general
purpose operating systems such as Linux.
1
arXiv:2003.02892v1 [cs.CR] 5 Mar 2020
Manufacturer Usage Descriptions (MUD [21]) standardize
the policy language in which IoT whitelists can be written,
so that the device manufacturer or a trusted third party can
encode device behavior into a machine-readable policy. This
policy can be enforced at the network edge, protecting all
devices in the local network. The open question that remains
is: what network behavior should be included in the whitelist?
Asking manufacturers to provide whitelists may not scale;
there are too many unique IoT vendors, some of which simply
re-brand devices manufactured by another vendor. A trusted
third party could analyze devices and generate whitelists, but
the business incentives (including user willingness to pay for
such a service) aren’t clear. Users themselves could analyze
local device behavior and generate profiles, but this approach
may not scale to households with large number of IoT devices.
In this paper we propose a blockchain-based network secu-
rity policy management and enforcement system for home IoT
environments. Our system, SERENIoT (pronounced Seren-
ity), characterizes IoT device behavior locally and uses a de-
centralized ledger to determine whether the local behavior
matches that observed by other peers in the network. Policies
(whitelists of allowed behavior) are the result of a consen-
sus algorithm identifying network behavior observed by the
majority of nodes in the network. Network connections that
are unique to a device are blocked until they are observed by
most nodes, preventing the spread of Mirai-style botnets.
SERENIoT is designed to run on network appliances such
as home routers. The system analyses IP traffic between the
local IoT devices and their cloud APIs, making it compatible
with all IP IoT devices and hubs. As these appliances are
already present in home networks (e.g., ISP-provided home
routers), our system doesn’t require any drastic network topol-
ogy change and integrates directly into actual homes. It is
designed to extend the security features of home gateways by
adding network policy enforcement for IoT devices. SERE-
NIoT takes advantage of the IoT devices having limited sets of
actions and being widely spread. It leverages the blockchain
to build a decentralized ledger of trusted connections and
blocks all connections that are not explicitly in the whitelist.
Our contributions are:
1.
The design and implementation of a novel approach
to build a whitelist of behavior of an IoT device. The
approach is based on blockchain and requires no opt in
by manufacturers or trust in third parties. SERENIoT’s
public blockchain provides new data sources to audit
IoT device behaviors at scale and assists in the detection
of new threats.
2.
Evaluation of our system on large-scale simulations with
53 devices and 1000 Sentinels and on a small-scale test
bed with real world devices.
The remainder of the paper is structured as follows. Sec-
tion 2reviews IoT security background and related work and
gives a brief overview of relevant blockchain concepts. Sec-
tion 3presents the technical details of SERENIoT. Section 4
evaluates scalability, performance and security. Sections 5and
6present the limitations of our implementation and discuss
related deployment issues. We conclude in Section 7.
2 Related work and Blockchain Review
2.1 IoT security
One common solution to protect IoT networks is to de-
ploy a signature-based Network Intrusion Detection System
(NIDS) [11,19,23] on IoT networks. NIDS monitor network
traffic and look for known attack signatures. These solutions
are therefore only efficient if the attack is already known and
require constant updates to have the latest signature base. Al-
though these solutions might be workable for industrial IoT
networks with dedicated security teams, complex IDS solu-
tions are not suited for home environment where experts are
likely unavailable to monitor, maintain, and configure them.
IDSes can be augmented by using machine learning to detect
previously unseen attacks. However, this introduces uncer-
tainty as false positives can be exploited by attackers [32].
The accuracy issue is also present when identifying device
types [25]. The similarity in behavior of distinct devices
makes it difficult to determine which device generated the
traffic, or what policy to apply to a particular device.
An alternative approach is to whitelist device behavior
based on policies describing the devices’ expected behavior.
This approach is sometimes referred to as specification-based
intrusion detection, where the policy is a narrowly defined
list of allowed behavior. The policies can be provided by the
manufacturers or trusted parties as proposed by the IETF in
RFC8520 [21] or generated by local device observation [4].
Other approaches are to divide devices into controllers and
non-controllers, preventing non-controllers (e.g., lightbulbs)
connecting from other devices and limiting them to only con-
nect to their cloud endpoints [10].
Anomaly detection capabilities can also be embedded into
devices themselves [30]. The idea here is that the firmware
on the device is updated to include an anomaly detection
agent which monitors the system for malicious activity. Since
this approach requires changes to software running on every
IoT device, it is largely incompatible with devices that are
deployed and no longer maintained. Moreover, it requires
strong cooperation with manufacturers for adoption.
2.2 Blockchain review
We briefly review the key concepts of blockchain technology.
A deeper treatment can be found in [31]. Blockchain tech-
nology addresses use cases where multiple distrusting parties
want to jointly participate in a system. Blockchain provides
shared governance where participants collaboratively decide
2
what gets added to the chain and ensures that the protocol is
being followed correctly by all the participants. Participation
may be open (anyone can join, possibly without registration)
or closed (only authorized participants can contribute).
A major aspect of blockchains is their verifiable sate: the
data in a blockchain reflects the output of its consensus pro-
tocol which has been verified by all the participants. That
is, only data that has been agreed upon through consensus
can be added to the chain, leading the chain to contain only
verifiable data. Once data has been verified by participants in
the network, a new block containing this data is added to the
chain. This data includes a cryptographic link to the previous
block, allowing all parties to verify the continuity of the chain.
The consensus algorithm is thus a key aspect of every
blockchain. It ensures that the chain of blocks containing the
data is kept synchronized between participants so that they all
have an identical copy of it at any time. It also prevents the
blockchain to grow almost instantly by introducing a delay
between the creation of new blocks. Multiple consensus algo-
rithms exist [6]. The proof of work (PoW) [3,15] algorithm
is widely used by popular permisionless (open) blockchains
such as Bitcoin
2
and Ethereum
3
and requires block hashes
to be smaller than a defined target. The weight of each par-
ticipant in the validation process is thus determined by its
capacity to compute hashes and this mechanism ensures that
participants are randomly selected to create new blocks. How-
ever, this approach is very costly, energy and computationally
speaking. Indeed, all the effort has no other utility than ran-
domly delaying participants capacity to produce valid blocks.
Another approach is the proof of stake [17]. Proof of stake
doesn’t rely on computing hashes and thus, unlike proof of
work, doesn’t have massive energy requirements. With this
algorithm, the creator of a new block is chosen within a pool
of participants who have staked a certain amount of cryp-
tocurrencies. The penalty to harm the network is then the cost
of losing the staked amount of cryptocurrencies. For major
blockchains this can amount to tens of thousands of dollars.
A participant trying to take over the network would also need
to own 51% of the cryptocurrency supply on that blockchain.
That amount to billions of dollars for major cryptocurrencies.
It is thus less likely to happen than controlling half of the
network hash power for proof of work [22]. However, this
consensus mechanism requires a built-in cryptocurrency to
work. Both of these consensus algorithms are widely used
and provide a probabilistic way to verify blocks’ validity.
Finally, another feature of blockchains is data loss preven-
tion: Thanks to the decentralized nature of blockchains, the
data in the chain is replicated across participants which allows
recovery in case of data loss. At any time a participant can
ask for a copy of the full chain and verify its contents.
Through these properties, Blockchain provides a tamper-
proof decentralized ledger that can be used beyond crypto-
2https://bitcoin.org/
3https://ethereum.org/
currencies in applications requiring accountability, trans-
parency and trust in data [31]. Blockchain is also suited for
open network applications where untrusted participants need
to reach a consensus as is the case in collaborative charac-
terization systems. Collaborative characterization consists
of aggregating multiple observations of similar systems to
identify their shared traits. When working with a large set of
observations from different sources, it allows to identify the
intended behavior of the systems without any prior knowledge.
As this behavior is identified using observations on a large
population, it is highly resistant to outliers and only reflects
the true nature of the system. When applied to IoT, collab-
orative characterization enables us to identify the intended
behavior of a device model, represented by the set of packet
signatures that are common to the majority of observed IoT
devices.
2.3 IoT security and blockchain
Golomb et al. [8] propose CIOTA as a system monitoring
devices’ behavior at the firmware level to build a ledger of
legitimate actions. This is achieved by continuously gathering
data from devices using Extensive Markov Models (EMM)
and building a collaborative model of device behavior. The
Blockchain’s ledger is then used to inform a client-side in-
trusion detection system. While a preliminary security evalu-
ation of CIoTA appears promising, it requires modification
of the devices firmware to embed the software EMM agent.
SERENIoT learns device behavior at the network layer see
Section 3.3, and thus does not require any changes to the
firmware enabling greater compatibility with existing devices.
Mendez Mena et al. [24] have built and evaluated a proof of
concept based on the Ethereum blockchain to protect the edge
of home networks. Their "gatekeeper" enforces a whitelist
of allowed actions which is computed based on the informa-
tion stored in an Ethereum smart contract. The smart contract
provides a tamper proof ledger to report the local network in-
formation gathered by gatekeepers. This approach has several
shortcomings: Despite being based on blockchain, it does not
solve the problem of policy creation addressed herein. Their
approach is also centralized as gatekeepers interact with a
single smart contract which could be replaced by a database.
Moreover, this solution is not tailored for real world use as its
deployment on the Ethereum public blockchain would require
payment to push policy updates to the smart contract.
3SERENIoT Intrusion Detection System
3.1 Overview
SERENIoT is a collaborative specification-based intrusion
detection system for home IoT networks. It monitors the net-
work traffic to/from IoT devices to detect and block anoma-
lous packets and connections. It relies on a decentralized
3
ledger that characterizes devices’ behavior and hosts a list of
allowed packet signatures.
SERENIoT nodes (called Sentinels) are designed to be de-
ployed on network appliances or middleboxes such as routers.
A typical set-up would see one Sentinel deployed per smart
home (see Figure 1), collaborating with other remote Sentinels
to determine the correct network behavior of IoT devices. Sen-
tinels advertise a WiFi network to which IoT devices connect,
thus allowing mediation and filtering of all network connectiv-
ity between the devices and the Internet. The wireless network
operates as a network bridge to the home local area network
(LAN), so all traffic entering or leaving the Sentinel is moni-
tored. Through its use of a distributed ledger and peer-to-peer
communication, SERENIoT can operate with little-to-no user
input. Moreover, compared to other network security solu-
tions such as signature-based intrusion detection systems,
SERENIoT’s Sentinels are implicitly always up to date.
Figure 1: SERENIoT Network topology. Sentinels acts as
middleboxes between IoT devices and the network gateway,
enabling blocking of connections that are outside the device
specification.
Concretely, Sentinels only forward packets that are defined
in a whitelist. Any network connection that is not specified in
the whitelist is discarded by the Sentinel. The whitelist spec-
ifies network packet signatures characterizing the behavior
of a specific IoT device as observed by the majority of Sen-
tinels on the network. Whitelists for all IoT devices are stored
in SERENIoT’s blockchain. Through the use of blockchain,
SERENIoT is fully decentralized and can be bootstrapped
with a small number of Sentinels. It allows the system to be
fully independent from trusted third parties, device manufac-
turers, and to support a large set of diverse IoT devices. We
discuss why we use blockchain in Section 3.5.SERENIoT is
fully backward compatible with many existing IP-based IoT
devices, requiring no changes to their hardware, firmware, or
apps. The system is also designed to be forward compatible
with devices that don’t yet exist, as long as they use IP-based
communication and can connect to the local Sentinel.
We built SERENIoT with a focus on consumer IoT, noting
high accuracy and performance when working with feature-
limited devices such as smart bulbs, smart switches, smart
locks, smart thermostats, etc. (see Figure 2). These devices
typically only interact with a small set of cloud services
through well-defined APIs, thus their network footprint can be
accurately determined (see Section 4.2). According to a 2019
study [20], this should cover approximately 41% of devices
deployed in North American homes, and 28.4% of devices
in Western Europe
4
.SERENIoT cannot support systems with
variable (typically human-dependent) network behavior, since
each system may create a unique set of network connections.
Figure 2: Supported devices for SERENIoT. Devices toward
the left have simpler network behavior and tend to have a
similar network footprint shared across devices of the same
type. Devices toward the right have unique network footprints
determined by their users.
3.2 Threat model
SERENIoT protects devices against attackers trying to change
their behavior, as widely used by botnets [2,28]. SERENIoT
has been designed to counter the two following attack scenar-
ios:
•
An IoT device has been compromised locally by a mal-
ware trying to change its behavior to accomplish mali-
cious actions. The attack vector can vary; the IoT device
can be infected by another device on the local network
(for example by an infected computer or IoT device),
or the infection can be the result of a physical action
on the device (for example a memory card swap). In
this situation SERENIoT would protect the IoT device
from attacking targets on the internet by blocking all the
outgoing traffic deviating from the specification.
•
An IoT device is directly exposed on the internet. SERE-
NIoT would protect the IoT device from incoming at-
tacks by blocking all incoming traffic differing from the
specification. Most IoT devices don’t normally receive
incoming connections from the internet and SERENIoT
will then behave as a firewall blocking all incoming con-
nections.
Our prototype does not currently monitor local network traf-
fic and does not protect against malicious usage (for example
an attacker using the user credentials to view a smart camera
video feed) as this kind of attack meets the specifications of
allowed actions.
Once a whitelist has been populated for a device,an attacker
would need to change the behavior of more than 50% of the
IoT devices of the same type to change the specifications and
allow the attack to go through (see Section 4.5).
4
We include all IoT devices in the study by Kumar et al. [20] except media
boxes, game consoles, and file storage appliances which are functionally as
complex as general purpose computers
4
3.3 Sentinel architecture
Figure 3: Main components of a Sentinel. Description inline.
Sentinels use a modular architecture with 4 main compo-
nents (see Figure 3): The network filter component (1) is in
charge of enforcing the policy by dropping network packets
that are not allowed and forwarding acceptable traffic. The
network filter relies on the packet signature module (2) to
serialize the raw IP packet into a textual signature and on the
policy module (3) that lists all the allowed packet signatures.
Finally, the blockchain module (4) keeps the policy updated
by synchronizing the ledger with the other Sentinels and by
reporting the newly recorded packet signatures.
3.4 Computing packet signatures
Packet signatures allow Sentinels to characterize recorded
packets. An effective signature algorithm should be precise
enough to differentiate packets from different network connec-
tions but flexible enough to produce the same signature across
devices of the same model. Unlike general purpose comput-
ers whose behavior changes depending on their usage, IoT
devices of a same model behave similarly (often identically in
terms of traffic transmitted and destination) and produce sim-
ilar network traces. We have verified this hypothesis during
our evaluation in Section 4. Our proof of concept uses packet
signatures at the IP level and focuses on the fields that remain
constant across devices. While other packet signatures and
connection fingerprinting techniques exist, we use a NetFlow
5
like representation to provide a balance between uniqueness
and consistency across devices. SERENIoT’s packet signature
aggregates sequences of packets sharing the following values:
• Protocol of the IP payload
•
Endpoint (domain name or IP address if domain is un-
available)
5
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-
software/ios-netflow/prod_white_paper0900aecd80406232.html
• Service port
The Endpoint identifies the remote host with which the
IoT device is interacting. To resolve potential domains, we
perform reverse DNS lookups. The service port identifies the
well-known port number used by the connection
6
. Packets of
a same flow will share the same signature that will be used by
SERENIoT to identify anomalous flows and packets. Signa-
tures are computed by serializing and hashing the following
values:
Signature =H(protocol,end point,service port )
Packet signatures don’t include device-specific identifiers
such as Media Access Control Organizational Unique Identi-
fiers (OUI). Indeed, it is unclear whether all devices of a same
model will share a single OUI as many manufacturers are
allocated more than one. Two identical devices with different
OUIs would be assigned to different chains weakening the
security of both chains. Moreover, malicious code running
on an IoT device may be capable of manipulating the MAC
address. Our choice of packet signatures allows to differen-
tiate packets going to untrusted hosts from those going to
the manufacturer’s API. It also allows to differentiate packets
initiated by the monitored device from those initiated by a
remote entity in the case of IPv6 network or networks without
NAT where devices are directly exposed on the internet.
Note that SERENIoT doesn’t precisely identify devices.
Devices that produce the same set of packet signatures are
grouped and the system assumes they are of the same type.
Devices are characterized by their packets signatures and
device types are fingerprinted by hashing their sorted set of
packet signatures.
3.5 SERENIoT’s blockchain
The blockchain is the key behind SERENIoT’s collaborative
policy generation mechanism. It ensures that all the packet
signatures written to the whitelist are agreed upon through
a distributed consensus protocol. This provides robustness
and trust by making sure malicious signatures do not become
whitelisted as long as a majority of Sentinels participating in
the network observe legitimate behaviors on their local IoT
devices.
Our choice of building SERENIoT on blockchain stems
from 3 core design requirements: (1) It allows the system
to run without relying on trusted third parties such as manu-
facturers. It is indeed unlikely that a third party will provide
a system supporting all past, present and future IoT devices
from different brands without expecting the user to pay a
6
The service port generally refers to the remote endpoint’s port. However,
some IoT devices (e.g., cameras) host certain services locally, in which case
the service port refers to the local port hosting the service. To differentiate
between local and remote services, we append a direction identifier (L for
local or R for remote) to the service port.
5
subscription fee. (2) Deploying up a highly available infras-
tructure that provides real time security policy updates to
potentially millions of users would be costly, whereas the
use of blockchain distributes the system across nodes. (3)
The system should allow public open access and should not
be restricted to users of specific vendors. We evaluate the
scalability and robustness of our blockchain-based system in
Section 4.
To implement SERENIoT, we have designed a custom pub-
lic blockchain based on Bitcoin’s blockchain principles but
with no inherent cryptocurrency. We elected to build a cus-
tom blockchain because current blockchain frameworks are
either strongly tied to token economics (e.g., Ethereum
7
) or
designed to build permissioned blockchains (e.g., Hyperledger
fabric
8
). Designing our own chain gives us the flexibility to
include only features specific to our requirements while avoid-
ing compatibility challenges arising from trying to retrofit
another framework to our use case.
3.5.1 Ledger
SERENIoT’s ledger includes packet signatures reported by the
Sentinels. It is based on a distributed timestamp server chain-
ing data blocks together. The linked timestamping mechanism
ensures that blocks cannot be rearranged or modified without
invalidating subsequent blocks in the chain. As the blockchain
grows, Sentinels converge on the chain with the most blocks.
In our implementation, blocks store a list of packet signa-
tures reported by the Sentinels instead of a Merkle root of
transactions as in Bitcoin (see Figure 5). The complete list
of reported signatures is indeed necessary to build the policy
and there is thus no need for selective reveal.
Figure 4: Device chain: The Sentinels add packet signatures
into blocks. The chain grows and only signatures listed into
the longest chain are trusted.
To extend the chain and report new packet signatures to
the system, Sentinels only work on top of blocks that con-
tain signatures that they have previously observed. That is,
Sentinels avoid appending to chains that include unknown sig-
natures. These packet signatures may be malicious or reflect
previously unseen connections for a device. Thus, the fastest
7https://ethereum.org/
8https://www.hyperledger.org/projects/fabric
Figure 5: SERENIoT’s Block architecture. The Sentinel Ad-
dress is a unique identifier generated at Sentinels start up using
the same algorithm used to generate Bitcoin’s addresses.
growing chain always contains the most common packet sig-
natures that have been observed by a majority of Sentinels.
This mechanism is described in detail in Section 3.5.4
The whitelist is a cumulative set of allowed packet signa-
tures that have been included in confirmed blocks since the
chain genesis. Note that this whitelist may allow behavior that
is no longer necessary to the device to operate (e.g. a feature
that was removed through a software update). Future work
will explore removing outdated signatures.
3.5.2 Consensus
SERENIoT’s consensus algorithm ensures that the whitelist is
kept synchronized between Sentinels so that they all converge
to an identical copy of the blockchain. It is also responsible
for making sure that the fastest growing chain gathers the
most Sentinels. To facilitate the development of our proof
of concept, we implement a proof of work consensus algo-
rithm [26]. We discuss alternative consensus algorithms in
Section 6.1.
With proof of work, blocks are produced by nodes racing
to solve computational puzzles. The node that solves the
problem appends its block to the chain. Each additional block
increases the effort required to rewrite the longest chain, since
changing a past block would require every subsequent proof of
work to be recomputed. As long as the computational power
distribution remains balanced across Sentinels, the fastest
growing chain will gather the most Sentinels.
3.5.3 Supporting multiple devices
The logic described previously works well for one specific
IoT device. Indeed, every IoT device protected by SERE-
NIoT needs its own blockchain/whitelist as Sentinels can-
not adjudicate on blocks containing packet signatures for
unknown devices. SERENIoT uses a multichain solution al-
lowing Sentinels to subscribe to the whitelists concerning
the devices they protect. Thus, each device type uses a sepa-
rate blockchain to track its behavior. When a new device is
6
connected to a Sentinel, the Sentinel profiles it and assigns
it to a chain aggregating similar devices. To profile a de-
vice and subscribe to the right whitelist, Sentinels observe
the device behavior during a short profiling phase upon its
connection. Once the profiling phase is over, Sentinels com-
pute the whitelist identifier corresponding to the device. The
whitelist identifier is computed by hashing the sorted list of
packet signatures collected during the profiling phase. SERE-
NIoT doesn’t identify precisely devices. Devices that produce
the same set of packet signatures are grouped together and
the system assumes they are the same type. Thus, devices are
characterized by their packets signatures and device models
are fingerprinted by hashing their sorted set of packet signa-
tures.
To support multiple IoT devices, SERENIoT’s Blockchain
is composed of one control chain and multiple device-specific
chains (also referred to as whitelists), one for each device
model protected by the Sentinels. In our implementation, the
control chain stores the block headers of valid whitelist blocks
and uses the proof of work consensus mechanism. Device spe-
cific chains do not have an independent consensus mechanism,
they instead leverage the control chain’s proof of work.
Figure 6: Multichain support in SERENIoT. Block headers
of device specific blockchains are incorporated into a single
control chain.
The control chain improves robustness by requiring all Sen-
tinels (regardless of their locally monitored IoT devices) to
ultimately contribute to a single master chain while building
on device-specific blockchains. It makes it harder for a mali-
cious actor to target a specific unpopular whitelist to rewrite it.
Indeed, all blocks in device-specific whitelists are validated in
the control chain that gathers all the Sentinels of the network.
3.5.4 Sentinels workflow
Sentinels participate in maintaining and updating the
whitelists by serving as blockchain nodes. Sentinels only
subscribe to the whitelists corresponding to the devices they
locally monitor. A Sentinel’s blockchain node process can be
described as follows.
1.
The Sentinel monitors IoT devices that are connected to
it and collects new packet signatures into whitelist block
candidates. One whitelist block candidate is created per
subscribed whitelist. If a device is inactive or no new
packet signatures have been recorded, the Sentinel builds
an empty block.
2.
The Sentinel computes the hashes of the whitelist block
candidates’ headers and adds them to a control block
candidate.
3.
The Sentinel works on solving the proof of work for the
control block candidate.
4.
The first Sentinel to produce a control block is selected to
append its whitelist block candidates to the correspond-
ing whitelists. To do so, it broadcasts the control block
along with all the whitelist blocks listed within.
5.
Sentinels always accept broadcasted control blocks. Sen-
tinels only accept a broadcasted whitelist block if they
are registered to the corresponding whitelist and if they
recognize all its packet signatures. When accepting a
block, Sentinels work on extending the chain on top of
it. A whitelist block is only valid if its block header is
listed in a control block. Sentinels always converge on
the longest chain and forks are resolved when a branch
becomes longer than the others.
3.5.5 Adding incentive for open networks
SERENIoT’s blockchain has been designed to work with no in-
herent cryptocurrency. Thus, Sentinels contributing to the net-
work by providing computational power cannot be rewarded
with some cryptocurrency. To encourage Sentinels to stay
active and contribute to the blockchain, inactive Sentinels
are isolated by their neighbors and do not receive the latest
whitelists updates. To signal their activity and contribution to
the network, Sentinels use a mechanism inspired by mining
pools and broadcast partial solutions of the proof of work they
are trying to solve. This proves to their neighbors that they
are active and contributing to the system.
7
3.6 Detecting behavior changes
SERENIoT is designed to protect IoT devices with limited
functionalities such as smart bulbs, smart plugs or smart cam-
eras. These devices typically establish a small set of network
connections so we can characterize their expected behavior by
observing the network traffic of a large number of devices of
a specific model. Sentinels use the most common behavior ob-
served by nodes in the system to create a specification of what
the observed device should be allowed to do. Specification-
based intrusion detection systems raise alarms when behavior
deviates (even slightly) from a narrowly defined specification.
Network traffic is either permitted or blocked, with no no-
tion of confidence or likelihood of attack, as is the case with
anomaly-based IDS. Specification-based IDS is also different
from signature-based IDS, where experts define signatures of
all known attacks. SERENIoT seeks to define signatures of
known good behavior and block all other network traffic.
To do so, Sentinels use whitelists to file the packet sig-
natures characterizing devices’ intended behaviors. When a
packet from an IoT device is recorded by a Sentinel, the Sen-
tinel computes its signature and verifies whether the signature
exists in the whitelist associated with the device. If the sig-
nature is trusted, the packet is forwarded to its destination.
Otherwise the packet is blocked, and the Sentinel reports the
packet signature (i.e. adds it to current block candidate of the
whitelist). It will eventually be appended to the whitelist if
the majority of Sentinels also report it.
This mechanism allows Sentinel to detect and block anoma-
lous behaviors that are only observed on a small proportion
of the monitored devices.
3.6.1 Updating the policy
When a device’ behavior changes, other Sentinels on the net-
work report whether they also observed the change or not.
The behavioral change can be the result of a firmware update
or of an attack. To decide if the new behavior is legitimate,
Sentinels rely on the majority’s observation: If the change has
been observed by the majority of Sentinels, it is considered
as legitimate and will be added to the whitelist. Otherwise it
will be considered as anomalous and will be blocked. This
logic is based on the idea that if the majority of devices of
the same type share the same behavior, it should be their "in-
tended" behavior. Note that the "intended" behavior may be
anomalous, however in this case the device should be consid-
ered itself untrusted and actions should be taken against the
manufacturer. For example, in January 2020, Google revoked
Xiaomi’s access to the Google Home Hub ecosystem after
users were able to view strangers’ security cameras video
feed [5].
3.6.2 Transparency & auditing
In addition to Sentinels network filtering capabilities, the open
and public nature of SERENIoT’s blockchain introduces a new
data source for cyber security experts, allowing them to follow
and audit in real time the behavioral evolutions of IoT devices.
This can be used to monitor growing threats, updates adoption
rates, etc. For example, it is possible to watch the spread of a
growing botnet by watching the rejected forks. Transparency
and privacy concerns are discussed in Section 6.2.
3.7 Device onboarding
When a new device is connected, Sentinels first go through
a profiling phase to fingerprint the device before enforcing
network filtering. This process is detailed below:
Figure 7: Device onboarding flow-chart.
1. Onboarding:
The user buys a new device and connects
it to the Sentinel. To connect the device to the Sentinel,
the user uses the dedicated WiFi network broadcasted
by the Sentinel.
2. Profiling:
During the profiling phase, the Sentinel allows
all network traffic to and from the device and computes
packet signatures for all the network connections to char-
acterize the device. The connection signatures are used
to register the new device to the blockchain regrouping
all the devices with a similar network footprint. This pro-
filing phase usually requires about 1 minute for most IoT
devices tested during our evaluation (see Section 4.2). If
the corresponding blockchain doesn’t exist (i.e. it is the
first device with this network footprint to be connected
to a Sentinel), a new device specific chain is initialized.
3. Enforcement:
Once the device has been registered to
a blockchain, the Sentinel downloads the blockchain
to build the policy and begins blocking all the packets
whose signatures don’t match the policy. The Sentinel
also starts reporting newly recorded packet signatures to
the whitelist.
4. Behavior change / Policy update:
If the behavior of
the protected devices changes, the Sentinel will vote to
decide whether these changes need to be incorporated
into the policy based on the majority observations. If
only one Sentinel is registered to a blockchain, it can
decide which packet signature to add to the policy. This
can be problematic if the first Sentinel registered to a
8
blockchain is malicious as it may incorporate anomalous
packet signatures into the whitelist. This is discussed in
detail in the security evaluation Section 4.5
4 Evaluation
To evaluate our system, we have carried out small scale ex-
periments on real IoT devices to observe the system behavior
in real-world use cases. We have also tested the scalability
and robustness of SERENIoT during large scale simulations
on Amazon AWS.
4.1 Implementation
The proof of concept of the SERENIoT Sentinel is developed
in node.js
9
, a cross platform, open source javascript runtime
environment designed to build event-driven and asynchronous
web applications. The blockchain component has been imple-
mented from scratch. Sentinels communicate with peers using
WebRTC
10
and websockets
11
. In addition, we have developed
a Web UI using VueJs framework
12
to monitor Sentinels in
real time and help us run our experiments. Screenshots of the
Web UI can be seen in Appendix A.2.
4.2 Experiments on virtualized IoT devices
and sentinels
To evaluate the Sentinels’ behavior with different types of
IoT devices and verify that our system can reach consensus
and converge on a list of legitimate actions for the protected
devices, we have set-up a virtualized testbed with 1000 Sen-
tinels. Each Sentinel was run in a separated Docker container
and we used Docker Swarm to orchestrate our cluster and
deploy the Sentinels’ containers on AWS instances. We used
10 Amazon EC2 c5.2.xlarge instances hosting each 100 Sen-
tinels and connected through a Docker virtual network. For
the simulations, Sentinels were running a simulated proof
of work consensus algorithm in order to be able to simulate
multiple Sentinels on a same host. We also developed a cus-
tom web app to monitor the state of each Sentinel to obtain a
real time visualization of the Sentinel network, blockchains
and evolution of policies. Figure 8shows the Amazon AWS
architecture used for our evaluation.
Each Sentinel was simulating a set of devices from the
dataset of Alrawi et al. [1]. This dataset provides packet cap-
tures of an IoT network with 53 different devices for 9 contin-
uous days. Based on these captures, we extracted the devices’
behavior by isolating packets generating unique signatures to
get a set of packets representative of each device’s packet sig-
natures. Devices were simulated by replaying these packets
9https://nodejs.org/
10https://webrtc.org/
11https://developer.mozilla.org/docs/Web/API/WebSockets_API
12https://vuejs.org/
Figure 8: Simulation architecture of SERENIoT on Amazon
AWS.
in random order and at random intervals to imitate the un-
predictable aspect of user interactions (for a example a smart
light bulb might be powered off during a period of time and
the user can interact with it at any time).
As shown in Figure 9, we clearly denote two classes of
IoT devices: devices with a simple behavior characterized
by a small number of packet signatures as Lifx Smart Bulb,
TPLink WiFi plug or Nest Guard and other more complex
multipurpose devices such as iPads, smart TVs, etc.
We also observe on Figure 9that devices with a simple
functionality are characterized by a stable behavior overtime
that doesn’t change often. This validates our initial hypothesis
that IoT devices’ typical behavior only contains a small set of
actions which remain constant over time.
During the experiments, we monitored the system and the
devices’ specific blockchains for different time periods (from
1 hour to multiple days) and with different number of Sen-
tinels (from 20 to 1000); as expected, Sentinels were unable
to converge on a list of legitimate packet signatures for gen-
eral purpose devices as iPads, iPhones and Android tablets.
However, for simpler devices Sentinels were able to converge
and produced lists of trusted packet signatures.
We then subjected the lists of trusted packet signatures to
attack data from the IoT network intrusion dataset of Hyunjae
et al. [18]
13
. To do so, we first injected malicious packets
in a small number of Sentinels’ devices’ behavior. As ex-
pected, Sentinels monitoring "infected" devices successfully
identified and blocked the malicious packets while keeping
the device functional. Figure 11 shows the identification and
rejection of a fork with anomalous packet signatures.
We then attempted to determine the percentage of Sen-
tinels monitoring compromised devices required to incorpo-
rate a new packet signature into the whitelist. This number
characterises the breaking point where behavior changes are
13
Based on this attack data, we simulated Mirai-style flooding and scan
attacks. We manipulated the packets to reflect our IoT devices.
9
Figure 9: CDF of distinct packet signatures per device recorded over a 9-day period. Labeled lines identify general purpose
devices.
Figure 10: Total recorded packet signatures per device.
Figure 11: Rejected fork with anomalous packet signatures.
The whitelist contains only packet signatures listed in the
longest chain.
incorporated in the trusted list of packet signatures.
During our experiments we observed that this breaking
point occurs at around 51%, meaning that 51% of the Sen-
tinels need to record a same packet signature to be authorita-
tive on the longest chain and include the packet signature in
the whitelist for a given device. Thus, popular devices are less
likely to be attacked as more Sentinels need to be infected to
incorporate malicious packet signatures in the whitelist. How-
ever, they also require more time for updates to be deployed
as updates need to reach a greater number of devices before
being trusted.
4.3 Experiments on real IoT devices and sen-
tinels
We tested SERENIoT on real IoT devices to demonstrate
that Sentinels can be easily deployed on a IoT network with
minimal topology change and that our proof of concept also
fits to real use. To do so, we installed the Sentinel software
on 3 Raspberry PI 3 B+ configured as Wifi hotspots and
10
used netfilterqueue
14
to intercept, inspect and block network
packets forwarded by the Sentinels. We then connected 1
LIFX Mini Smart bulb to each Sentinel.
Figure 12: Physical devices used for our real experimental
set-up.
This experiment was carried during a one-hour period dur-
ing which we interacted with the devices through the manu-
facturers’ mobile app. The 3 Sentinels were successfully able
to record the packets from the bulbs and to converge on the
list of the resulting packet signatures showing that our proof
of concept also works with real life IoT devices and Sentinels.
Moreover, during this experiment, there was no perceptible
delay when interacting with the bulb through the LIFX mobile
app and using SERENIoT.
Recorded packet Pkt. Signature Desc.
UDP time1.google.com R123 0cca40...aed4d4 NTP
TCP 104.198.46.246 R56700 4e2b3d...2a4474 LIFX API
Table 1: Packet signatures recorded for the LIFX Smart Bulb
during our experiment. Signatures have been truncated.
4.4 Blockchain performance evaluation
We have evaluated Sentinel performance and blockchain
growth over a 24-hour experiment with 20 simulated Sen-
tinels. The measurements show that the block sizes for the
control and device chains tends to be constant over time. We
estimated the size of the blockchains after one year of continu-
ous operation of experimental proof of concept. Note that this
code has not yet been optimized for wide-scale deployment,
and many further improvements are possible, as discussed
below. The control chain size depends on the number of dis-
tinct IoT device types protected by the Sentinels. We estimate
the chain to grow to 511MB per year for 1 IoT device, and
511GB per year for 10,000 distinct IoT device types. We
14
netfilterqueue is a wrapper around libnetfilter_queue that gives ac-
cess to the packets matched by specific iptables rules. More information:
https://netfilter.org/projects/libnetfilter_queue/
also observed that per-device chain size is consistent across
all device types and should require around 474MB per year.
Sentinels only need to download and maintain device chains
corresponding to the device types they protect. Thus, a Sen-
tinel with 10 different IoT devices would need to maintain
a single copy of the control chain and 10 device chains. We
note that many blocks in device chains will be empty and old
blocks may contain signatures for packets that are no longer
seen. There is thus an opportunity to periodically truncate old
blocks containing no useful information and force Sentinels
to submit fresh observations. This feature would prevent the
blockchains to grow infinitely while allowing old policies to
be updated by deleting outdated behaviors no longer in use
by the majority of the devices.
Our Sentinel performance measurements show that Sen-
tinels use approximately 140MiB of RAM after running for
24 hours and that their network usage is correlated with
blockchain growth. Network utilization varies between two
Sentinels based on the number of distinct IoT devices they are
protecting. Finally, Sentinels were using a simulated proof
of work consensus algorithm to run the experiment. Their
CPU usage is thus not representative of the usage one would
observe if the Sentinels were using real proof of work instead.
In the case of real proof of work, we expect CPU usage to
be maxed out at 100% for all Sentinels. Full measurements
details can be found in Appendix A.1
4.5 Security evaluation
When a new IoT device is connected to a Sentinel, the Sen-
tinel determines the whitelist to register based on the device
behavior. Thus, devices behaving similarly will be grouped on
the same whitelist and already compromised devices behav-
ing differently will be assigned to a separate whitelist. Thanks
to this mechanism all devices assigned to a same whitelist ini-
tially behave similarly. Uncompromised devices are thereby
grouped together, and the corresponding whitelist will only
contain legitimate packet signatures reflecting the behavior of
these devices. In this section, we evaluate the different attacks
vectors leading to successful attacks incorporating malicious
packet signatures into the whitelists or exploiting devices to
change their behaviors.
Attacks against IoT during the profiling phase
During
the profiling phase (see Section 3.7), Sentinels allow all the
traffic and don’t enforce any network filtering for the newly
connected IoT device. Even if this phase only lasts a few
minutes, an attacker could benefit from this short period of
time to perform an attack. In this case, the attack will modify
the network footprint of the device which will likely cause it
to be registered to a different chain than other benign devices
of the same type. This chain will regroup all the devices of this
type that have produced the same network footprint during
the profiling phase (i.e. all the devices of the same type that
11
have been targeted by the same attack during the profiling
phase) and the Sentinels will not filter the resulting malicious
network connections.
Devices could also already be infected when connected
to Sentinels. In this case, if the infected devices’ behavior
is similar to benign devices of the same type, they will be
registered to the same device chain as other devices and their
malicious behavior will be filtered and blocked. However,
if the infected devices’ behavior is different, they will be
registered to a chain with all the similarly infected devices as
in the case of an attack during the profiling phase.
Attacks against the IoT devices
Once the Sentinel is in
the enforcement phase (see Section 3.7), we differentiate two
types of attacks against the IoT devices. Attacks from the
local network and attacks from the internet.
Attacks from the local network will eventually succeed
and compromise devices as Sentinels don’t enforce any net-
work filtering on the local network. However, Sentinels will
block any behavior deviating from the specification trying
to reach the internet. This protect against compromised lo-
cal IoT devices trying to attack targets on the internet and
restrict them to the strict behavior listed in the specifications.
Moreover, thanks to the open nature of its blockchain, SERE-
NIoT also provides a new kind of metrics allowing experts to
monitor in real time the behavior of a large number of IoT
devices. Thanks to this feature, SERENIoT provides trans-
parency and can help cybersecurity experts to take actions
and block threats as they grow.
Attacks originating from a remote attacker targeting a spe-
cific IoT model will be blocked by Sentinels as long as only a
minority of Sentinels observe the same attack pattern. Thus,
these attacks grow in difficulty with more Sentinels protecting
more devices of a specific model. For an attack to succeed, its
network footprint has to be similar on a majority of Sentinels
(meaning that Sentinels should record packets signatures with
the same IP address). The attacker also needs to target 51% of
all devices in less than one block-interval (the time interval be-
tween blocks). For popular IoT devices, attacker unlikely have
the resources to initiate an attack targeting simultaneously
a large number of devices from a single host. Commonly,
attackers rely botnets to carry massive attacks against IoT
devices. IoT botnets such as Mirai [2], Brickerbot [16] and
Hajime [12] share similar network footprints during the infec-
tion phase: they scan for listening telnet, ssh and http services
and try to bruteforce the credentials. However, the source IP
addresses of the attacker vary as botnets use infected devices
to spread and infect new hosts. The packet signatures of each
botnet attack will thus likely vary from one target to another
as the IP and port used by the attacking device will vary. By
design, SERENIoT should effectively block P2P botnets. Par-
ticularly those having multiple attackers. As these signatures
are not consistent across all Sentinels, they are unlikely to be
added to the whitelist and the attack will be blocked.
Attacks on the Sentinels
Sentinels act as both blockchain
nodes and network traffic enforcement points. Thus, if a Sen-
tinel is compromised, the attacker may insert or remove traffic
rules arbitrarily
15
. However, attacking a specific node does
not allow the inclusion of malicious packet signatures into
the blockchain, as these must still be validated and confirmed
by the majority of the nodes. SERENIoT’s blockchains are
vulnerable to two types of majority attacks.
•
Majority attacks against the control chain can succeed
if an attacker has the computational capacity of more
than half of all Sentinels. This adversary can win every
proof-of-work round, allowing the inclusion of arbitrary
packet signatures into any device blockchain/whitelist.
This type of attack is devastating to the network since the
whitelists are shared amongst all Sentinels. We discuss
alternative consensus protocols to lower the probability
of such an attack in Section 6.1.
•
Majority attacks against device chains can succeed if an
attacker controls more Sentinels than half of all Sentinels
registered on a specific device chain. This adversary will
be able to append blocks to these chains more often than
legitimate Sentinels which can result in incorporating
malicious blocks into the longest device chain. This
attack grows in difficulty with more Sentinels protecting
the same device of a specific model and contributing to
its chain. For popular IoT devices, with a large number of
Sentinels registered on their chain, this attack’s difficulty
is similar to a majority attack on the control chain.
5 Limitations
Our system currently only monitors LAN-to-WAN connec-
tions so it does not protect IoT devices from other infected
devices on the local network. While this limitation allows P2P
infection methods to succeed on the local network, infected
IoT devices will be unable to attack remote hosts; Sentinels
will block the outgoing traffic that does not match whitelisted
connections.
Our system is tailored to support IoT devices with a small
network footprint. It is unclear, however, how effective the
system can be in protecting IoT devices with richer network
behavior (i.e., requiring a larger whitelist). An open question
is whether any collaborative intrusion detection system (ours
included) can converge on a set of connections that should be
permitted. One strategy for complex devices is to make the
packet signature algorithm less specific, but this may have the
disadvantage of missing certain attacks.
In its current design, SERENIoT will block any user-defined
connection to remote servers (e.g., a cloud-based FTP server
15
This is not unlike the security of a firewall or router, which should
typically be better protected than internal hosts on the network.
12
for video stream backups). Connecting to user-defined end-
points will typically be blocked because connections to these
arbitrary servers will not be observed amongst the broader
population of Sentinels. One option to permit user-defined
servers to be allowed is to enable a manual override in the
user interface, allowing advanced users to allow specific con-
nections without impacting the collective whitelisting feature.
We will explore adding this feature in future work.
Finally, like any collaborative system, performance (both
accuracy and resilience to attack) improves with the deploy-
ment of each additional node. By deploying more Sentinels,
manipulating the whitelists (i.e., the blockchain) requires
more effort from an attacker. Similarly, in the case of a small
number of Sentinels, the likelihood of an attack influencing
the packet signatures that get added to the whitelist is higher.
6 Discussion
6.1 Consensus
In our proof of concept, we used Proof of Work for its im-
plementation simplicity and wide availability. However, we
expect that most Sentinels will be deployed on devices with
limited computational power such as routers. As proof of
work relies on computationally intensive problems to secure
the chain, an attacker with large computing resources can
easily overpower even a large number of routers. To miti-
gate this, an alternative consensus algorithm could be used.
In addition to the consensus algorithms mentioned in Sec-
tion 2.2, a promising alternative is the proof of elapsed time
(PoET) [13]. This algorithm leverages Intel’s Safe Guard Ex-
tension (SGX) [14] to execute the consensus algorithm in
a verifiable environment. SGX allows to produce a certifi-
cate to attest that it’s correctly running a given trusted code.
PoET has the same objective as proof of work: to randomly
delay block production so that it is evenly spread across the
network over time. This is done by requiring nodes to run
trusted code (certified through Intel’s SGX). Unlike PoW,
PoET doesn’t require heavy computational effort and thus
is less energy consumptive. However, this method also has
limitations: It is tied to a given chip vendor so it would and
relies entirely on a third party platform to work exposing it to
vulnerabilities [9,33,34].
6.2 Transparency and privacy
Blockchain systems, in particular those which are public tend
to elicit privacy concerns since the ledger is replicated across
all participants. By using SERENIoT, IoT device behaviour
is published into an immutable public data structure that can
help users understand the expected functionality of a device
before it is purchased. Auditors and regulators can use this in-
formation as well to inform regulation of future devices. The
disadvantage of this transparency is that directly connected
nodes can query each other for the availability of blocks cor-
responding to particular chain. This could allow an attacker
who knows the mapping between a device and a chain to
ask whether a Sentinel has that device. This attack could be
mitigated by throttling the number of requests allowed per
source IP address and by adding an exponentially increasing
delay for every subsequent request from the same source.
6.3 Usability
Despite its complexity, SERENIoT can fully operate without
any user interaction to protect the vast majority of simple
IoT devices. We expect that this zero-configuration will en-
courage adoption even by non-expert users. However, in the
event of software updates that change the behaviour of an
IoT device, the system will prevent new functionality from
working until more than majority of Sentinels observe the
same behaviour on their devices. The research community
has not yet measured the speed of deployment of software
updates on IoT. Lack of updating may leave early adopters
without the ability to use the new features. One might argue
that for security reasons, waiting for the majority of devices to
upgrade is safer, but some users may want the latest features
as soon as possible.
In future, we may add a manual override to allow expert
users to clear the currently learned behaviour of their device
and treat it as new after the update has been applied which
will likely force the device onto a different chain.
The system provides usability for common main stream
users. It doesn’t require any user interaction to work and will
protect devices once they are connected to it. For real world
deployment, SERENIoT could partner with ISPs to deploy the
Sentinel software on home gateways.
7 Conclusion
IoT devices in smart homes are often unnecessarily over-
privileged, increasing the risk of compromise and impact of
attacks. This paper explored leveraging blockchain technol-
ogy to assist in determining a strict specification of essential
network behavior of IoT devices. We presented SERENIoT
as a proof of concept network policy management and en-
forcement system that can operate with little to no user input.
Our evaluation shows that the system is able to converge on
small network security policies for many simple consumer
IoT devices without requiring changes to firmware, software,
or apps, and without requiring vendor buy-in. The consen-
sus algorithm forces attackers to execute majority attacks to
make changes to those policies. While implementation and
deployment questions remain, we hope that SERENIoT can
be viewed as a first step toward blockchain-based network
security policy enforcement systems.
13
Acknowledgments
We thank José Fernandez and Jeremy Clark for helping shape
initial versions of this work. We also thank Xavier de Carné
de Carnavalet and Paul van Oorschot for their insightful feed-
back. This research is partially supported by the Natural Sci-
ences and Engineering Research Council of Canada (NSERC
Discovery Grant RGPIN-2018-04468).
References
[1]
Omar Alrawi, Chaz Lever, Manos Antonakakis, and
Fabian Monrose. Sok: Security evaluation of home-
based IoT deployments. In 2019 IEEE Symposium on
Security and Privacy (S&P).
[2]
Manos Antonakakis, Tim April, Michael Bailey, Matt
Bernhard, Elie Bursztein, Jaime Cochran, Zakir Du-
rumeric, J Alex Halderman, Luca Invernizzi, Michalis
Kallitsis, et al. Understanding the Mirai botnet. In
USENIX Security, 2017.
[3]
Adam Back. A partial hash collision based postage
scheme. http://www.hashcash.org/papers/announce.txt,
1997.
[4]
David Barrera, Ian Molloy, and Heqing Huang. IDIoT:
Securing the internet of things like it’s 1994. arXiv
preprint arXiv:1712.03623, 2017.
[5]
BBC. Google denies Xiaomi access over security bug.
https://www.bbc.com/news/technology-50981993.
[6]
Christian Cachin and Marko Vukoli´
c. Blockchain con-
sensus protocols in the wild. In 31 International Sympo-
sium on Distributed Computing, 2017.
[7]
Earlence Fernandes, Jaeyeon Jung, and Atul Prakash. Se-
curity analysis of emerging smart home applications. In
2016 IEEE Symposium on Security and Privacy (S&P).
[8]
Tomer Golomb, Yisroel Mirsky, and Yuval Elovici.
Ciota: Collaborative IoT anomaly detection via
blockchain. arXiv preprint arXiv:1803.03807, 2018.
[9]
Johannes Götzfried, Moritz Eckert, Sebastian Schinzel,
and Tilo Müller. Cache attacks on Intel SGX. In 10th
European Workshop on Systems Security, 2017.
[10]
Sanket Goutam, William Enck, and Bradley Reaves.
Hestia: Simple least privilege network policies for smart
homes. In 12th Conference on Security and Privacy in
Wireless and Mobile Networks (WiSec), 2019.
[11]
Javid Habibi, Daniele Midi, Anand Mudgerikar, and
Elisa Bertino. Heimdall: Mitigating the internet of inse-
cure things. IEEE Internet of Things Journal, 4(4):968–
978, 2017.
[12]
Stephen Herwig, Katura Harvey, George Hughey,
Richard Roberts, and Dave Levin. Measurement and
analysis of Hajime, a peer-to-peer IoT botnet. In NDSS,
2019.
[13]
Hyperledger. PoET 1.0 specification.
https://sawtooth.hyperledger.org/docs/core/releases/latest/
architecture/poet.html.
[14]
Intel. Software Guard Extensions.
https://software.intel.com/en-us/sgx.
[15]
Ari Juels and John Brainard. Client puzzles: A crypto-
graphic defense against connection depletion attacks. In
NDSS, 1999.
[16]
Simon Kenin. BrickerBot mod_plaintext
Analysis. https://www.trustwave.com/en-
us/resources/blogs/spiderlabs-blog/ brickerbot-
mod_plaintext-analysis/.
[17]
Aggelos Kiayias, Alexander Russell, Bernardo David,
and Roman Oliynykov. Ouroboros: A provably secure
proof-of-stake blockchain protocol. In Springer Ad-
vances in Cryptology (CRYPTO), 2017.
[18]
Hyunjae Kang; Dong Hyun Ahn; Gyung Min Lee; Jeong
Do Yoo; Kyung Ho Park; Huy Kang Kim. Iot network
intrusion dataset, 2019.
[19]
Ayush Kumar and Teng Joon Lim. Early detection of
Mirai-like IoT bots in large-scale networks through sub-
sampled packet traffic analysis. In Future of Information
and Communication Conference, 2019.
[20]
Deepak Kumar, Kelly Shen, Benton Case, Deepali Garg,
Galina Alperovich, Dmitry Kuznetsov, Rajarshi Gupta,
and Zakir Durumeric. All things considered: an analysis
of IoT devices on home networks. In USENIX Security,
2019.
[21]
Eliot Lear, Dan Romascanu, and Ralph Droms.
Manufacturer Usage Description Specification.
https://tools.ietf.org/html/rfc8520.
[22]
Jon Matonis. The Bitcoin mining arms race: Ghash.io
and the 51% issue. https://www.coindesk.com/bitcoin-
mining-detente-ghash-io-51-issue.
[23]
Yair Meidan, Michael Bohadana, Yael Mathov, Yisroel
Mirsky, Asaf Shabtai, Dominik Breitenbacher, and Yuval
Elovici. N-BaIoT—Network-based detection of IoT
botnet attacks using deep autoencoders. IEEE Pervasive
Computing, 17(3):12–22, 2018.
[24]
Diego M Mendez Mena and Baijian Yang. Blockchain-
based whitelisting for consumer IoT devices and home
networks. In 19th Annual SIG Conference on Informa-
tion Technology Education. International World Wide
Web Conferences Steering Committee, 2018.
14
[25]
Markus Miettinen, Samuel Marchal, Ibbad Hafeez,
N Asokan, Ahmad-Reza Sadeghi, and Sasu Tarkoma.
IoT sentinel: Automated device-type identification for
security enforcement IoT. In 2017 IEEE 37th Interna-
tional Conference on Distributed Computing Systems
(ICDCS).
[26]
Satoshi Nakamoto et al. Bitcoin: A peer-to-peer elec-
tronic cash system. 2008.
[27]
Lily Hay Newman. An elaborate hack
shows how much damage IoT bugs can do.
https://www.wired.com/story/elaborate-hack-shows-
damage-iot-bugs-can-do/.
[28]
CBC News. Your smart fridge
could be mining bitcoins for criminals.
https://www.cbc.ca/news/technology/bitcoin-hacking-
smart-devices-1.4728222.
[29]
Ray and Michael Huebler. Moving from hacking IoT
gadgets to breaking into one of europe’s highest hotel
suites. Black Hat USA, 2019.
[30]
Shahid Raza, Linus Wallgren, and Thiemo Voigt. Svelte:
Real-time intrusion detection in the internet of things.
Ad hoc networks, 11(8):2661–2674, 2013.
[31]
Scott Ruoti, Ben Kaiser, Arkady Yerukhimovich, Jeremy
Clark, and Robert Cunningham. SoK: Blockchain tech-
nology and its potential use cases. arXiv preprint
arXiv:1909.12454, 2019.
[32]
Robin Sommer and Vern Paxson. Outside the closed
world: On using machine learning for network intrusion
detection. In 2010 IEEE Symposium on Security and
Privacy (S&P).
[33]
Jo Van Bulck, Marina Minkin, Ofir Weisse, Daniel
Genkin, Baris Kasikci, Frank Piessens, Mark Silberstein,
Thomas F Wenisch, Yuval Yarom, and Raoul Strackx.
Foreshadow: Extracting the keys to the Intel SGX king-
dom with transient out-of-order execution. In USENIX
Security, 2018.
[34]
Nico Weichbrodt, Anil Kurmus, Peter Pietzuch, and
Rüdiger Kapitza. Asyncshock: Exploiting synchronisa-
tion bugs in Intel SGX enclaves. In European Sympo-
sium on Research in Computer Security, 2016.
A Appendices
A.1 Blockchain evaluation
This section evaluates the capacity of our system to run on
the long term. During our experiments we have measured the
growth of the blockchains and monitored the runtime metrics
of the Docker containers running the Sentinels.
Blockchains size
Sentinels store blocks as JSON files. To
measure the blockchain growth we connected to different Sen-
tinels during a 24-hour experiment and recorded the number
of stored blocks as well as the size of the blocks directory af-
ter 1 hour, 5 hours and 24 hours. For this experiment we used
20 simulated Sentinels with one Belkin Netcam connected.
The number of Sentinels in the network does not influence
the blockchain size as the block production rate is fixed and
determined by the consensus algorithm. Sentinels also delete
rejected forks blocks as soon as they converge on a longest
chain.
Table 2shows that the control chain block size tends to
be constant overtime. The block size for the control chain is
determined by the number of different IoT devices types pro-
tected by the Sentinels. Indeed, each device type has is own
device chain and each device chain is indexed into the con-
trol chain. Control chain blocks list the block headers of the
latest produced blocks from the device chains, containing at
maximum the number of device chains, block headers. Block
headers are SHA256 hashes and have a fixed size of 32 bytes.
It is thus easy to compute the control chain block size for a
given number of IoT devices. Based on our measurements,
the control chain with 1 IoT device should be around 511MB
after one year running.
1.4MB ∗365days =511MB/year
If we consider 10K different IoT device types protected by
our Sentinels, the control chain should be around 511GB after
one year running.
4384blocks ∗10000 ∗32B+1.4MB =1.4GB/day
1.4GB ∗365days =511GB/year
Table 3shows that the device chain block size also tends
to be constant. Indeed, most of the blocks in device chains
are empty as blocks list packet signatures of newly observed
behaviors. In the long run, the majority of blocks will thus
be empty as new behaviors are rarely recorded. Based on our
measurements, device chains should be around 474MB after
one year running.
1.3MB ∗365days =474MB/year
Sentinels are required to maintain a copy of the control
chain. However, they only require to download and maintain
the devices chains corresponding to the device types they
protect. Thus, a Sentinel with 10 different IoT devices would
need to maintain a copy of the control chain and 10 device
chains.
Future work will explore a block expiration feature where
outdated blocks will be deleted. This feature would prevent
the blockchains to grow infinitely while allowing old policies
to be updated by deleting outdated behaviors no longer in use
by the majority of the devices.
15
Elaps. Time Nb. of blocks Size AVG block size
1 hour 205 64KB 312B
5 hours 918 291KB 316B
24 hours 4384 1.4MB 316B
Table 2: Block size measurements for the control chain with
1 IoT device
Elaps. Time Nb. of blocks Size AVG block size
1 hour 193 59KB 304B
5 hours 906 268KB 296B
24 hours 4367 1.3MB 295B
Table 3: Block size measurements for a device chain
Sentinels runtime metrics
To record Sentinels’ metrics,
we used the docker stats command
16
. We recorded the metrics
for 20 simulated Sentinels during a 24 hours experiment after
16
More information on the Docker runtime metrics can be found here:
https://docs.docker.com/config/containers/runmetrics/
1 hour, 5 hours and 24 hours. These metrics show the CPU,
memory and network usage. We observed that Sentinels use
approximately 140MiB of RAM after running for 24 hours
and that their network usage is correlated with the blockchains
growth. Sentinels only download blocks for the control chain
and for the device chains they are registered to. The network
usage varies between two Sentinels based on the number of
different IoT devices they are protecting. Finally, Sentinels
were using a simulated proof of work consensus algorithm to
run the experiment. Their CPU usage is thus not representative
of the usage one would observe if the Sentinels were using
real proof of work instead. In the case of real proof of work we
expect CPU usage to be maxed out at 100% for all Sentinels.
Sentinels’ metrics records can be found in Figure 13.
A.2 Web UI Screenshots
Figures 14,15 and 16 show screenshots of the Web UI during
a simulation with 100 Sentinels.
16
Figure 13: Screenshot of the Sentinels metrics.
17
Figure 14: Screenshot of the Network view of the Web UI.
Figure 15: Screenshot of the Sentinel view of the Web UI.
18
Figure 16: Screenshot of the Blockchain view of the Web UI.
19