UCC Library and UCC researchers have made this item openly available.

Please let us know how this has helped you. Thanks!

Title A blockchain solution for enhancing cybersecurity defence of IoT

Author(s) Giannoutakis, K. M.; Spathoulas, G.; Filelis-Papadopoulos, Christos K.;

Collen, A.; Anagnostopoulos, M.; Votis, K.; Nijdam, N. A.

Publication date 2020-12-11

Original citation Giannoutakis, K. M., Spathoulas, G., Filelis-Papadopoulos, C. K.,

Collen, A., Anagnostopoulos, M., Votis, K. and Nijdam, N. A. (2020) 'A
blockchain solution for enhancing cybersecurity defence of IoT',
Proceedings - 2020 IEEE International Conference on Blockchain,
Rhodes, Greece, 2-6 November, pp. 490-495. doi:
10.1109/Blockchain50366.2020.00071

Type of publication Conference item

Link to publisher's http://www.blockchain-ieee.org/

version http://dx.doi.org/10.1109/Blockchain50366.2020.00071
Access to the full text of the published version may require a
subscription.

Rights © 2020, IEEE. Personal use of this material is permitted. Permission

from IEEE must be obtained for all other uses, in any current or
future media, including reprinting/republishing this material for
advertising or promotional purposes, creating new collective works,
for resale or redistribution to servers or lists, or reuse of any
copyrighted component of this work in other works.

Item downloaded http://hdl.handle.net/10468/11302

from
Downloaded on 2022-07-06T08:30:27Z
A Blockchain Solution for Enhancing Cybersecurity
Defence of IoT
K. M. Giannoutakis1 , G. Spathoulas2 , C. K. Filelis-Papadopoulos3 , A. Collen4 ,
M. Anagnostopoulos5 , K. Votis6 , N. A. Nijdam7
16 Information Technologies Institute, Centre for Research and Technology Hellas, Thessaloniki, Greece
25 Dept. of Information Security and Communication Technology, Gjøvik, Norway

3 Department of Computer Science, University College Cork, Cork, Ireland

47 Centre Universitaire d’Informatique, University of Geneva, Geneva, Switzerland

16 {kgiannou, kvotis, }@iti.gr, 3 [email protected],

47 {georgios.spathoulas, marios.anagnostopoulos}@ntnu.no,

25 {anastasija.collen, niels.nijdam}@unige.ch

Abstract—The growth of IoT devices during the last decade of the proposed implementation on lightweight hardware
has led the development of smart ecosystems, such as smart (Gateways) that is used for managing the IoT devices.
homes, prone to cyberattacks. Traditional security methodologies The rest of the paper is organized as follows. Section II
support to some extend the requirement for preserving privacy
and security of such deployments, but their centralized nature in discusses the related work on the research field, whereas Sec-
conjunction with low computational capabilities of smart home tion III presents background information regarding its appli-
gateways make such approaches not efficient. Last achievements cability on a real deployment using the Ethereum Blockchain
on blockchain technologies allowed the use of such decentralized infrastructure. Section IV presents the proposed components
architectures to support cybersecurity defence mechanisms. In for enhancing the security of smart home installations, while
this work, a blockchain framework is presented to support the
cybersecurity mechanisms of smart homes installations, focusing Section V summarizes the conclusions of the study.
on the immutability of users and devices that constitute such
environments. The proposed methodology provides also the II. R ELATED W ORK
appropriate smart contracts support for ensuring the integrity of A 2016 literature review [4] identified various research pa-
the smart home gateway and IoT devices, as well as the dynamic pers that use the Blockchain technology in other areas beyond
and immutable management of blocked malicious IPs. The
framework has been deployed on a real smart home environment cryptocurrencies, including data storage management, identity
demonstrating its applicability and efficiency. management, rating systems, data and goods trading, with only
Index Terms—Blockchain, smart home, IoT, Cybersecurity four use cases being identified as applicable in the context of
IoT. Nevertheless, the IoT domain and its applicability for
I. I NTRODUCTION Blockchain solutions continued to raise attention in research
and industrial deployments [5], [6]. The main reason behind
Blockchain technology has been adopted during the last this trend is the structure of the IoT, currently evolving to the
years in many application domains in order to strengthen Internet of Everything, where Blockchain ensures reliability
security issues in a decentralized manner. Due to its nature, and security of the IoT systems through its traceability and
this technology has direct applicability to Internet of Things openness characteristics [7].
smart homes environments, as it can support security-related The use of the blockchain technology also recently gained
use cases. interest in the cyber security domain. In particular, the use
In this work, a blockchain security defence mechanism is of smart contracts was incorporated in the design and im-
proposed targeting IoT smart homes. The framework supports plementation of a DDoS defence mechanism in [8]. The use
smart contracts for implementing registration of users and of the existing public infrastructure of Ethereum to advertise
hardware elements that constitute a smart home, while real- blacklisted IPs suspected to be involved in ongoing DDoS
izing security related operations for ensuring the integrity of attacks is fully exploited in this work. The use of timeout
these elements and blacklisting of malicious IPs. The method- notions while creating white/black/grey lists of IP addresses
ology introduces a blockchain technology agnostic solution for firewall and corresponding nodes classification is discussed
that can be adopted easily for any installation with minimal in [9]. Another interesting approach of using blacklists is
requirements on the smart home gateways. discussed in [10], in the field of Vehicular Wireless Networks.
The solution proposed, developed under GHOST EU The use of Blockchain in a smart home installation of IoT
project, [1]–[3] and coupled with behavioral anomaly detection devices, discussed in [11], demonstrates the implementation
procedures, provides a novel defence mechanism for smart of the security in smart homes in terms of confidentiality,
homes. Towards this, a private Ethereum network has been integrity, and availability with a comparatively low overhead
established, for demonstrating the applicability and efficiency introduction. A secure communication platform in a smart
city was presented in [12] as part of a Blockchain based pipeline several key aspects were identified as critical to ensure
security framework. A cost-effective secure architecture for trust of the system. Blockchain technology has been used in
smarthomes with promising results on the resources con- the context of GHOST in various functions, namely integrity
sumption and not requiring any cloud storage is presented management of users and devices, firmware validation of
in [13]. The presented model utilises a hybrid version of the the gateway and IoT devices and enhanced decision making
Blockchain, consortium blockchain, where the user’s perfor- through collective IP blacklisting. The integration of the SCs
mance as a node has been eliminated. Singh et al. developed are part of the Blockchain Defence Infrastructure that interacts
an efficient and secure smarthome architecture [14], which with each of the aforementioned GHOST layers.
is based on the cloud computing and Blockchain technology. The GHOST Blockchain Defence Infrastructure consists of
This architecture provides a network attack detection and a deployed private Ethereum Blockchain on top of an inter-
response system, yet it lacks the validation through the real connected grid of smart home installations of IoT devices.
deployment in the smarthomes. Each smart home features a device that will act as the smart
Using the Blockchain technology, which mainly provides home gateway middleware and simultaneously as a Blockchain
trust between nodes, seems to be an effective approach to node. Due to their limited processing power, this type of
facilitate the future underlying infrastructure for IoT. Huckle devices act as light nodes, therefore additional, full nodes with
et al. presented IoT scenarios where Blockchain can be used adequate processing power are required to act as miners within
to enable sharing economies of different assets [15]. By using the network.
smart IoT devices it is possible to automatically restrict or
grant access to assets like vehicles or buildings according IV. B LOCKCHAIN SOLUTION FOR CYBERSECURITY OF I OT
to rules implied by smart contracts without the need for The component described herein is a blockchain based
any human intervention. Lee and Lee proposed to use the component that can be installed at a smart home gateway
Blockchain to certify IoT devices running on the latest and and provide enhanced cyber-security functionality for both
most secure firmware [16]. This is an interesting approach, the administrator of the installation and the smart home
that could also employ the creation of an open market between owner. The component can be applied in a context where
manufacturers, end-users, validators and penetration testers. there are one or more IoT service providers and multiple
However, there are limitations with respect to the application smart home installations. The component offers the following
of the proper rules in the devices to provide the initiative for functionalities :
all stakeholders to push for more secure firmware installed on
• Registration of Devices and Users and User Consent
deployed devices.
• Firmware validation
III. BACKGROUND • Collaborative IP blacklisting

GHOST - Safe-Guarding Home IoT Environments with 1) Registration of Devices and Users and User Consent:
Personalised Real-time Risk Control is an European Union The processes of registration of users and devices along with
Horizon 2020 Research and Innovation funded project [2], the management of the consent of users with respect to the
providing the deployment context for the herein presented SC service are tightly coupled and are implemented under the
use cases. The GHOST architecture, presented in [1], envisions scope of the same smart contract. Data stored in the contract
a singular solution, deployed on a home gateway device, are anonymized hashes that can be retrieved by the distributed
which is capable of monitoring all IoT devices in a smart ledger and cross-checked with local stored information. This
home environment. It enables endusers (home habitants) to separation enables for deployment in public Blockchain en-
become aware and understand the cybersecurity risks (threats vironments, since publicly available information on the chain
and vulnerabilities), and to take informative decisions affecting are stripped of description or other sensitive information. This
their cyber-physical security and privacy. The solution is built approach simplifies registration of gateways and devices as
up from several layers, including the Data Interception and well as permission handling.
Inspection layer responsible for aggregating and analysing The user access control is performed solely by the Smart
network traffic; the Contextual Profiling layer that further Contract (SC). Three types of users are allowed:
analyses on the output from the previous layer to establish • Owner: The Owner of the contract is the entity that
device behaviour and more specifically report on anomalies; deployed the SC on the Blockchain or gained the role by a
the Risk Assessment layer that gathers all the information transfer of ownership from a previous owner. The Owner
about anomalies and correlates them to current and potential is a superuser that can add or remove Administrators and
risks; finally the Control and Monitoring layer that presents a Users, add or remove Gateways and IoT devices and add
graphical interface to the end user. or remove certified software hashes. The Owner of the
As a cybersecurity solution it is imperative to be able to contract cannot be an owner of a Gateway. The user type
trust and rely on its execution. Meaning, the software itself for the Owner is 1.
and everything in its digital periphery are to be included • Administrators: The Administrator is an entity that has
in the integrity management to ensure a safe and trusted the same rights as the Owner, except that Administrators
environment. Based on this understanding, along its execution cannot add or remove other Administrators. The user
 type for the Administrators is 1, the same as the Owner. registering a Gateway to the smart contract. Since MAC
It should be noted that the Owner is also considered addresses are not considered as sensitive data, it can be
an Administrator. Administrators are not allowed to be used as Gateway IDs in plain text.
owners of a Gateways, since this would be controversial • IoT status: The status of the IoT is described by an
to their role. unsigned integer that can be assigned the values 0 or
• User: The User is an entity that can sign or unsign the 1 corresponding to deleted or active.
Consent related to the ownership of a Gateway. Users • Last modification: The last modification is the timestamp
have no other rights. The user type for the Users is 10. of the last action performed on the members or properties
The SC retains Gateways as an array of structures inside the of an IoT. In practice the timestamp coincides with the
contract. Each Gateway structure retains its corresponding IoT timestamp of the block that included the transaction that
devices. Each Gateway structure is composed of the following modified the IoT.
members: • IoT type: The IoT type is expressed by the value of a hex
string representing the type of an IoT device (i.e Motion
• Gateway ID: This can be any unique string or a hashed
Sensor, etc).
string derived from a string describing the Gateway
• IoT uuid: The IoT uuid are identified as the hashed value
uniquely, i.e: its MAC address (or the hash of the
of the universal unique identifier with which system Ad-
MAC address). Derivation is performed using the SHA3
ministrators add the device in the local Gateway database.
(Keccak256) hashing method. Uniqueness of the ID is
checked during addition of Gateways. The Gateway ID The uniqueness of a Gateway, before addition to the array
is a mandatory input for registering a Gateway to the of Gateways in the smart contract, is enforced by a map-
smart contract. Since MAC addresses are not considered ping (injection) G from Gateway ID to an unsigned integer
as sensitive data, it can be used as Gateway IDs in plain G : ID → J. This mapping is also used for random access
text. to the array. The default value of the integer corresponding to
• Gateway status: The status of the Gateway is described a registered gateway belongs to [1, NGW ] ⊂ N, with NGW
by an unsigned integer that can be assigned the values 0 denoting the total number of Gateways, while if a Gateway
or 1 corresponding to deleted or active. is not already registered the value J is zero. Random access
• Last modification: The last modification is the timestamp to the elements of the Gateways array can be performed as
of the last action performed on the members or properties Gateways[G(ID)−1] = Gateways[J −1], for matrices with
of a Gateway. In practice the timestamp coincides with zero based indexing. Thus, addition of a Gateway requires
the timestamp of the block that included the transaction G(ID) = J = 0. Each new Gateway is added in the end of
that modified the Gateway. the Gateways array in position NGW and its corresponding
• Owner (User): The address of the owner of the Gateway value in the mapping is set to NGW + 1. In order to remove
is retained in the Gateway structures. The address of the a Gateway with Gateway ID (ID) the mapping is set to
user owning the Gateway is required in order to link the G(ID) = 0 and the status of the Gateway is set to 0.
Gateway to the user, as well as allow for restricting the This removal procedure does not involve moving or copying
signing / unsigning of the consent corresponding to that structures, thus enabling reduced computational complexity as
Gateway to its owner. The address of the owner is a well as cost for public blockchain deployments. To further
mandatory input for registering a Gateway to the smart improve performance, a variable denoting the number of
contract. registered Gateways NGW r
(numOfGWs) is retained in the
• Consent: The consent is expressed by the value of an contract. This variable increases by 1 when a new Gateway is
unsigned integer. Consent can be 0 or 1. added and decreased by 1 on deletion. Retaining the number
• IoT devices list: The IoT devices are identified as unique of registered Gateways in the contract, results in avoiding
strings (IDs) describing these devices (i.e. MAC address searching operations required by get type functions, thus
or the hash of the MAC address). These hashes are stored reducing cost of deployment of the contract. It should be
in an array. noted that deletion of a Gateway results in deletion of all its
• Number of IoT devices: A variable retaining the number constituent IoT devices.
of registered IoT active / inactive devices.
In the case of IoT devices, their registration follows the
Following the same approach with the Gateways, the SC same procedure. Similarly, a mapping from IoT ID to an
retains an array of IoT structures. Each IoT structure is unsigned integer I : ID → J. This mapping is also used
composed of the following members: for random access to the array of IoT structures. Random
• IoT device: This can be any unique string or a hashed access to the elements of the IoT s array can be performed as
string derived from a string describing the IoT uniquely, IoT s[I(ID) − 1] = IoT s[J − 1]. Addition can be performed
i.e: its MAC address (or the hash of the MAC address). only if I(ID) = 0. The deletion of a device is performed by
Derivation is performed using the SHA3 (Keccak256) setting the status of the IoT device to 0 and I(ID) = J = 0.
hashing method. Uniqueness of the ID is checked during In order to improve performance, each Gateway retains the
r
addition of IoTs. The IoT ID is a mandatory input for number of registered IoT devices NIoT , avoiding search
operations during call of get type functions, thus reducing cost
of deployment of the contract.
The registration / deletion of Gateways and IoT devices can
be performed only by the Administrators.
The retrieval of information, concerning Gateways and IoT
devices, from the SC can be performed with get type functions.
These functions return info for all Gateways, info for a
Gateway with a specific UID or info for all IoT devices of
a Gateway with a specific UID.
The main functions that have been realised in the SC with
regards to this functionality are:
• Registration of Users and Administrators: The Ad-
ministrators are responsible for the registration of Users.
The Administrators can be registered by the Owner of
the SC. The Owner can also register Users. The contract
retains a common registry to ensure uniqueness of Users
and Administrators.
• Registration of Gateways: The Administrators, are able
to register the Gateways and each Gateway is assigned
to one registered User corresponding to its smart home.
Each Gateway is described by a unique identifier, that can
be derived, for example, by the MAC address or com-
bination of other characteristics of the Gateway device.
A User is identified by the Address on the blockchain.
Moreover, administrators or the Owner of the smart con-
tract can remove Gateways from the distributed ledger.
After the registration of a Gateway, the User should sign
the consent related to this Gateway. The contract retains
a common registry to ensure uniqueness of Gateways.
• Registration of IoT devices: The registration of IoT
devices is performed by the Administrators or the Owner
of the contract. Each IoT is characterised by a unique id
which can be derived its MAC address or combination of
characteristics. The contract retains a common registry to
ensure uniqueness of IoT devices across all Gateways. Fig. 1. An example flow of operations: (a) User registration, (b) Gateway
• Signing / Unsigning of consent form: A User that owns registration from Administrator and signing of consent by the owning user,
(c) Registration of constituent IoT devices, (d) Registration of hashes related
a Gateway is able to sign the consent corresponding to to firmware, (e) Periodic check of software integrity of the Gateway and IoT
its registered Gateway. The User side consent can be devices.
removed at any moment for a given Gateway.
• Change of ownership of the contract: The contract
enables for change of ownership. The current Onwer set of hashes of the valid firmware versions stores in the SC.
can pass ownership of the contract to another blockchain The component reports both the event of an invalid hash and
address. the event of an interruption of the execution of the service
A visual representation of the main flows is depicted in Fig. (which could potentially be part of an attack).
1. The contract allows for registering hashes of firmware (or
2) Firmware Integrity: The second main functionality of- software) allowed for installation on the registered devices of
fered by the system is the validation of firmware of gateways the IoT system. These hashes are computed using a hashing
and devices. The main concept is based on the fact that a sig- scheme such as: IM O, M D5, SHA224, SHA256, SHA384
nificant number of cyber-security attacks relate to modifying or SHA512 and are stored to the Blockchain through a
one or more of the existing files of a system. The integrity mapping H : (HASH) → B, with HASH denoting the
of the firmware/software of each Gateway (and potentially of computed hash after rehashing with the SHA3 method and
IoT devices that support that) is periodically checked against B a Boolean value denoting existence. The computed hashes
the SC. The administrator of the installation stores in the SC are rehashed in order to ensure constant size of the hash that
the hashes of all valid firmware/software versions released. A would be given as input to the mapping. The integrity of the
service that constantly runs in the Gateway calculates the hash installed firmware can be checked frequently by the Gateway
of a predefined part of the filesystem and checks it against the or other devices against hashes stored on the Blockchain.
The registration or removal of hashes can be performed by
the Administrators. Moreover, the data structure (mapping)
retaining all hashes is not iterable and can be accessed only
randomly with knowledge of the hashes.
3) Blocking Blacklisted IP Addresses: Due to the dis-
tributed structure of IoT systems it is common to have infor-
mation (through which knowledge can be produced) generated
in different nodes of a network. Combining such knowledge
can be beneficial for the whole system, given that the integrity
of the combined data can be preserved. The functionality
of the system proposed is related to the combination of the
information about problematic IP addresses between different
smart home installations. Two different types of IPs blacklist- Fig. 2. Reputation score for a specific IP
ing are envisaged public and private. The first one refers to the
functionality of a collaboratively maintained knowledge base
for public IPs reputation. Each smart home gateway report The formula that calculates a bad reputation score for each
IPs as malicious to a single smart contract while the same IP is depicted in Equation 2. The approach of dividing the time
contract can be queried for a reputation score for a specific in discrete time frames or steps has been applied to implement
IP. The reported reputation score is cumulatively calculated a scheme that takes into account more recent values with
upon the reports of all gateways. The second type refers to a higher weight. The score is calculated for a specific time
a private blacklisting / whitelisting functionality where each period, a specific length of time steps denoted as tp . If the
gateway has its own smart contract to which it backups to and current time step it tn , then the score is:
restores from its locally maintained black and white lists. This t=t
Xn
feature will enable gateways to double check the integrity of score = − ln (cf )srt (λ)tn −t (1)
their local lists. t=tn −tp
a) Public Blacklisting: For the public blacklisting func-
tionality, a shared and publicly available knowledge of po- The srt is equal to 1, if there is a record for the IP in
tentially malicious IP addresses is maintained in a smart time step t and equal to 0 otherwise. The summation does not
contract. The contract will contain a list of records, each accumulate values for the time steps at which no record exists
one corresponding to the event that an installation (of the for the specific IP.
component) has reported an IP as malicious. These records The λ factor is a decay parameter that takes values in the
cannot be maliciously altered or deleted, as such an action range (0, 1). The higher the value of λ is the strongest the
would need to alter data already stored in the blockchain, memory of the scheme is. Lower λ values mean that the
which is extremely hard. scoring scheme penalises old values in a more heavy way.
Finally, the cf ∈ [0, 1] parameter stands for the cardinality
The calculation of bad reputation score for each external IP,
factor and penalises the case where all records come from
is mainly based upon three factors:
the same submitting address. It is equal to the ratio of the
• the number recent reports related to the specific IP nember of distinct submitters to the total number of records
• the cardinality of distinct report submitters for those for the specific IP that have been reported in the time window
records [tn − tp , tn ].
• the time elapsed since each on of those reports
The main concept for the calculation approach is that, when submitters
cf = (2)
reports for a specific IP start appearing, then its bad reputation records
score starts increasing. The more such reports come by the This parameter practically protects the reputation of IP from
larger the score becomes. If those originate from the same spamming accounts, that would want to harm the owner of an
source then each subsequent reports has a reduced effect IP by repeatedly submitting blacklisting records for this IP.
to the final score. This practically protects the system from Figure 2 shows the calculated reputation score for a partic-
malicious users that would like to intentionally increase the ular malicious IP, given that the relevant reports for this IP are
bad reputation score for a specific IP (given that they control shown by the coloured dots. The colour of each dot represents
a single or a few identities in the system). Each reports effect the unique id of the submitter of the report. For instance, all
is gradually limited as time goes by. In order for the score of red dots are representing submissions of Submitter 1, all blue
an IP to remain high it is required to continuously have new dots come from Submitter 2 etc.
reports for the specific IP from varying sources. This feature It is evident in the graph that the scoring scheme values
enables the gradual restoration of the reputation of the IP of reports according to how recent they are. This is why the
a legitimate host, that a malicious user has temporarily taken score starts to decrease with time after a specific report, at
control of. least until a new report is submitted. The rate at which the
scheme phases out the past reports is dictated by the decay [2] A. Collen, N. A. Nijdam, J. Augusto-Gonzalez, S. K. Katsikas, K. M.
parameter λ. Giannoutakis, G. Spathoulas, E. Gelenbe, K. Votis, D. Tzovaras,
N. Ghavami, M. Volkamer, P. Haller, A. Sánchez, and M. Dimas, “Ghost
Additionally, not all reports contribute the same value to - safe-guarding home iot environments with personalised real-time risk
the total reputation score for a particular IP. If a submitter control,” in Security in Computer and Information Sciences, E. Gelenbe,
keeps sending reports for the same IP, then every new report P. Campegiani, T. Czachórski, S. K. Katsikas, I. Komnios, L. Romano,
and D. Tzovaras, Eds. Cham: Springer International Publishing, 2018,
is weighted less. This is evident in the case of the first two pp. 68–78.
reports by Submitter 3, i.e. the first two green dots, or in the [3] C. S. Kouzinopoulos, G. Spathoulas, K. M. Giannoutakis, K. Votis,
case of the first two submissions by Submitter 2, i.e. the first P. Pandey, D. Tzovaras, S. K. Katsikas, A. Collen, and N. A. Nijdam,
“Using blockchains to strengthen the security of internet of things,” in
two blue dots approximately at t = 200. In contrast, when Security in Computer and Information Sciences, E. Gelenbe, P. Campe-
Submitter 2 keeps quiet for a period of time, his records start giani, T. Czachórski, S. K. Katsikas, I. Komnios, L. Romano, and
again to be valued more, at t = 470. D. Tzovaras, Eds. Cham: Springer International Publishing, 2018, pp.
90–100.
b) Private Black/Whitelisting: The private blacklisting [4] M. Conoscenti, A. Vetrò, and J. C. D. Martin, “Blockchain for the
and whitelisting of the IP addresses is a variation of the internet of things: A systematic literature review,” in 2016 IEEE/ACS
13th International Conference of Computer Systems and Applications
public blacklisting, where the reports for IP addresses have (AICCSA), Nov 2016, pp. 1–6.
influence only on a per installation basis. Despite any public [5] M. A. Khan and K. Salah, “Iot security: Review, blockchain solutions,
recommendation (i.e. Public blacklisting), a user still can have and open challenges,” Future Generation Computer Systems, vol. 82,
pp. 395–411, 2018.
personalised settings and a set of rules. Each smart home [6] Q. Wang, X. Zhu, Y. Ni, L. Gu, and H. Zhu, “Blockchain for the iot and
gateway is associated with a smart contract where a private industrial iot: A review,” Internet of Things, vol. 10, p. 100081, 2020.
list of rules is recorded. Each rule in turn is encrypted together [7] L. Wei, J. Wu, C. Long, and Y. Lin, “The convergence of ioe and
blockchain: Security challenges,” IT Professional, vol. 21, no. 5, pp.
with a state indicating to which list it belongs (i.e. blacklist, 26–32, 2019.
whitelist or none for the purpose of resetting the state). [8] B. Rodrigues, T. Bocek, A. Lareida, D. Hausheer, S. Rafati, and
Practically the gateway can maintain a copy for each one B. Stiller, “A blockchain-based architecture for collaborative DDoS
mitigation with smart contracts,” in Lecture Notes in Computer Science
of the its private whitelist and blackclist into a smart contract. (including subseries Lecture Notes in Artificial Intelligence and Lecture
It can then either add an IP, remove an IP or check if it exists Notes in Bioinformatics), ser. Lecture Notes in Computer Science,
in the smart contract. Through this mechanism the gateway D. Tuncer, R. Koch, R. Badonnel, and B. Stiller, Eds., vol. 10356 LNCS.
Cham: Springer International Publishing, 2017, pp. 16–29.
can have an integrity guarantee for the IPs existing in its local [9] M. Steichen, S. Hommes, and R. State, “ChainGuard — A firewall for
lists. blockchain applications using SDN with OpenFlow,” in 2017 Principles,
Systems and Applications of IP Telecommunications (IPTComm). IEEE,
sep 2017, pp. 1–8.
V. D ISCUSSION AND C ONCLUSIONS [10] J. Tobin, C. Thorpe, and L. Murphy, “An Approach to Mitigate Black
Hole Attacks on Vehicular Wireless Networks,” in 2017 IEEE 85th
This paper proposed a decentralized approach for supporting Vehicular Technology Conference (VTC Spring), vol. 2017-June. IEEE,
jun 2017, pp. 1–7.
IoT security in smart homes through blockchain technology. [11] A. Dorri, S. S. Kanhere, R. Jurdak, and P. Gauravaram, “Blockchain for
The mechanisms developed support a variety of functions for iot security and privacy: The case study of a smart home,” in 2017 IEEE
registering users and functional elements of a smart home, International Conference on Pervasive Computing and Communications
Workshops (PerCom Workshops), March 2017, pp. 618–623.
and more security oriented tools for ensuring the integrity [12] K. Biswas and V. Muthukkumarasamy, “Securing smart cities using
of software and firmware installed, as well as dynamic and blockchain technology,” in 18th International Conference on High
immutable IP blacklisting procedures. Performance Computing and Communications; 14th International Con-
ference on Smart City; 2nd International Conference on Data Science
The whole framework has been deployed and evaluated in and Systems (HPCC/SmartCity/DSS). IEEE, 2016, pp. 1392–1393.
real smart homes, under the purposes of the GHOST EU [13] S. Arif, M. A. Khan, S. U. Rehman, M. A. Kabir, and M. Imran,
project, enhancing the cybersecurity defence mechanisms in “Investigating smart home security: Is blockchain the answer?” IEEE
Access, vol. 8, pp. 117 802–117 816, 2020.
a decentralized manner under a private blockchain network. [14] S. Singh, I.-H. Ra, W. Meng, M. Kaur, and G. H. Cho, “Sh-blockcc:
A secure and efficient internet of things smart home architecture based
on cloud computing and blockchain technology,” International Journal
ACKNOWLEDGMENT of Distributed Sensor Networks, vol. 15, no. 4, p. 1550147719844159,
2019.
This work is partially funded by the European Union’s [15] S. Huckle, R. Bhattacharya, M. White, and N. Beloff, “Internet of
Horizon 2020 Research and Innovation Programme through Things, Blockchain and Shared Economy Applications,” Procedia Com-
puter Science, vol. 98, pp. 461–466, jan 2016.
GHOST project (https://www.ghost-iot.eu/) under Grant [16] B. Lee and J. H. Lee, “Blockchain-based secure firmware update for
Agreement No. 740923. embedded devices in an Internet of Things environment,” Journal of
Supercomputing, vol. 73, no. 3, pp. 1152–1167, mar 2017.

R EFERENCES

[1] J. Augusto-Gonzalez, A. Collen, S. Evangelatos, M. Anagnostopoulos,

G. Spathoulas, K. M. Giannoutakis, K. Votis, D. Tzovaras, B. Genge,
E. Gelenbe, and N. A. Nijdam, “From internet of threats to internet of
things: A cyber security architecture for smart homes,” in 2019 IEEE
24th International Workshop on Computer Aided Modeling and Design
of Communication Links and Networks (CAMAD), Sep. 2019, pp. 1–6.