Conference PaperPDF Available

Securing Over-The-Air IoT Firmware Updates using Blockchain

Authors:

Abstract and Figures

Over-the-air (OTA) firmware updates are very common in IoT (Internet of Things) devices with wireless capabilities. Although they are convenient, they may also be open to attack since physical access may not be needed. In addition, most frameworks use a centralized architecture to update a potentially large number of devices increasing the threat landscape. An alternative solution, that relies on a blockchain framework with smart contracts, is proposed in this paper to protect the integrity of the firmware update process. The proposed system is suitable for use in smart cities or scenarios with a large number of devices and service providers where nodes are authenticated, communications protected, and update conditions specified and enforced through smart contracts. A proof--of--concept system was implemented and tested using an open--source blockchain framework and a WiFi--capabable ESP8266--based board. The system was evaluated for scalability and response to denial of service (DoS) and man--in--the--middle (MitM) attacks. Preliminary experimental results show that the approach is feasible and a viable substitute for a centralized solution.
Content may be subject to copyright.
Securing Over–The–Air IoT Firmware Updates using Blockchain
Xinchi He, Sarra Alqahtani, Rose Gamble, Mauricio Papa
Tandy School of Computer Science, The University of Tulsa
Tulsa, OK, USA
{xinchi-he,sarra-alqahtani,gamble,mauricio-papa}@utulsa.edu
ABSTRACT
Over–the–air (OTA) rmware updates are very common in IoT
(Internet of Things) devices with wireless capabilities. Although
they are convenient, they may also be open to attack since phys-
ical access may not be needed. In addition, most frameworks use
a centralized architecture to update a potentially large number of
devices increasing the threat landscape. An alternative solution,
that relies on a blockchain framework with smart contracts, is pro-
posed in this paper to protect the integrity of the rmware update
process. The proposed system is suitable for use in smart cities
or scenarios with a large number of devices and service providers
where nodes are authenticated, communications protected, and
update conditions specied and enforced through smart contracts.
A proof–of–concept system was implemented and tested using an
open–source blockchain framework and a WiFi–capable ESP8266–
based board. The system was evaluated for scalability and response
to denial of service (DoS) and man–in–the–middle (MitM) attacks.
Preliminary experimental results show that the approach is feasible
and a viable substitute for a centralized solution.
CCS CONCEPTS
Security and privacy Embedded systems security.
KEYWORDS
Firmware update, blockchain, Internet of Things, network security
ACM Reference Format:
Xinchi He, Sarra Alqahtani, Rose Gamble, Mauricio Papa. 2019. Secur-
ing Over–The–Air IoT Firmware Updates using Blockchain. In INTERNA-
TIONAL CONFERENCE ON OMNI-LAYER INTELLIGENT SYSTEMS (COINS),
May 5–7, 2019, Crete, Greece. ACM, New York, NY, USA, 8 pages. https:
//doi.org/10.1145/3312614.3312649
1 INTRODUCTION
IoT devices are controlled and monitored using network connec-
tions over the Internet with their behavior and functionality largely
determined by the underlying rmware. The rmware is the piece
of software that resides on the hardware to support the basic device
functions [
16
]. It is usually stored in EEPROM or ash memory [
9
].
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specic permission and/or a
fee. Request permissions from permissions@acm.org.
COINS, May 5–7, 2019, Crete, Greece
©2019 Association for Computing Machinery.
ACM ISBN 978-1-4503-6640-3/19/05. . . $15.00
https://doi.org/10.1145/3312614.3312649
Firmware updates occur periodically and are critical to IoT de-
vice operation as they often enhance security, add new features, x
existing bugs and support compliance for new protocols and stan-
dards [
9
]. The rmware update process, which needs to be secured,
can be performed either through a direct physical connection or a
remote wireless connection (OTA).
Some hardware manufacturers allow USB drives to plug in to the
device to update the rmware [
3
] or program the hardware from a
host through an onboard serial port, such as Arduino boards [
1
].
OTA rmware updates allow the device to download the update
through its wireless network interface and then update itself [
3
].
For most IoT devices, this process is the preferred mechanism to
apply a rmware update for several reasons: (i) it is possible to
update devices without physical contact, (ii) convenience and (iii)
cost-eectiveness [7].
Needless to say, the OTA rmware update process itself can still
be compromised, i.e., a potential attacker does not need physical
access to the device. For instance, an intruder could interfere with
the process through a MitM or DoS attack. Securing the process
is challenging because the limited hardware resources available
on IoT devices make it dicult to adopt traditional and mature
security protection mechanisms.
Most of the existing solutions for IoT OTA rmware updates
adopt a client-server model in which device manufacturers use
servers (possibly using cloud providers) to distribute rmware up-
dates to IoT client devices. This centralized approach exhibits a
single point of failure for both the availability and the integrity
of the rmware update [
4
]. Relying on a blockchain framework,
instead of a centralized approach, has the following advantages:
Easy to keep track of all events (stored in the immutable
ledger) associated with the rmware update
Manufacturers can use smart contracts to specify update
conditions in a exible manner
Distributed nature of the blockchain frameworks makes
them more resilient to network failures and cyber attacks
In order to eliminate the single point of failure and make the process
more robust, it is possible to replace the server side of the OTA
update with a blockchain [
4
,
12
,
13
,
18
]. The system proposed in
this paper demonstrates not only the feasibility of the approach but
also its resilience to cyber attacks. Blockchain is a widely popular,
emerging technology that utilizes distributed immutable ledgers,
consensus algorithms, and smart contracts to essentially provide an
incorruptible digital ledger that can be used to record and validate
any kind of transaction. For instance, Bitcoin uses blockchain to
record cryptocurrency transactions. Similarly, our proposed system
uses blockchain to protect rmware-related transactions.
In this paper, we propose a system that employs a permissioned
blockchain to secure OTA rmware updates for IoT devices that
could be deployed in smart cities or across dierent households. The
COINS, May 5–7, 2019, Crete, Greece He et al.
approach deploys smart contracts to blockchain networks to verify
the legitimacy of a rmware update and to handle failed verication
instances that may be the result of a device under attack (such as
DoS or MitM). Our proposed system eliminates the single point
of failure present in centralized rmware update architectures by
replacing it with a distributed blockchain solution.
The proposed system is validated using a prototype implemen-
tation that uses the Wemos D1 Mini board (ESP8266 chipset based)
and the Hyperledger Fabric open-source blockchain framework.
We evaluate the performance and scalability of our approach in a
blockchain network with programmed simulations, while also test-
ing resilience to dierent types of cyber attacks. Preliminary results
show that the approach is feasible without compromising perfor-
mance and can protect IoT devices against cyber attacks during the
rmware update process.
2 BLOCKCHAIN BASICS AND
JUSTIFICATION
Blockchain technologies have been used, researched, and validated
in a number of dierent domains, such as cryptocurrency, health-
care, supply chain, and Internet of Things. There are mainly two
types of blockchain architectures: public and permissioned [
17
].
Public blockchains, such as Bitcoin and Ethereum, allow any party
to join the network freely by utilizing PoW (Proof of Work) or
PoS (Proof of Stake) consensus algorithms for better security; an
approach that sacrices performance and exibility. Permissioned
blockchains, such as Hyperledger, use CAs (certicate authorities)
to authenticate participants that use security tokens to join the
network. In addition, most permissioned blockchains use Byzan-
tine Fault Tolerance-based (BFT) consensus algorithms for better
cost eciency and improved performance [
17
]. BFT is a consensus
protocol that ensures consistency and low latency even if some
participants are compromised or misbehaving.
Because blockchains can be used to safeguard transaction records
of any kind, its use has been explored in a number of domains that
include rmware updates. In particular, authors in [
4
,
12
,
13
,
18
]
have investigated the use of blockchain distributed ledgers and
consensus algorithms to improve availability and integrity during
rmware updates over traditional centralized architectures that
expose a single point of failure. Baza et al. [
4
] have worked in
the vehicular domain to secure rmware updates using blockchain.
Authors in [
12
,
13
,
18
] have proposed solutions applicable to generic
IoT devices using public blockchains.
3 RELATED WORK
A four-layered smart city architecture, called CitySense, that uses
blockchain technology is described and proposed by Ibba et al. [
8
].
Sensors and smart objects are identied as the physical layer of
the architecture and constitute the foundation of the approach.
The role of the blockchain can be used to ensure consistency of
sensor data collected across the city [
10
]. Missing from these two
architecture descriptions are (i) details regarding the management
of the blockchain layer, (ii) interactions between the layers and (iii)
a prototype implementation.
A few proposed solutions rely on a centralized client-server
model. The main disadvantage of this type of architecture (as op-
posed to the use of a distributed architecture like blockchain) is
that it oers a single point of failure. Choi et al. [
6
] have questioned
the myth that rmware is usually more secure than software. For
that reason, they promote the importance of validating and secur-
ing rmware updates in consumer device home networks. Their
approach partitions the rmware into a xed number of blocks
and then uses hash chaining. Their solution, however, relies on
consumer devices with more computational power than is usually
found in IoT devices. Thus, the approach may impact an IoT device’s
ability to calculate the hash due to more limited resources (both in
memory and computing capabilities). Kvarda et al. [
11
] propose a
rmware update mechanism that uses hashing and PKI (Public Key
Infrastructure) with functionality implemented both at the software
and hardware levels. With this mechanism, integrity, authentication,
and privacy are readily present to help secure rmware updates
for IoT devices. Prada-Delgado et al. [
15
] demonstrate a new proto-
col that relies on physical unclonable functions (PUF) to provide
a light-weight rmware update for IoT devices in a trustworthy
manner. There are several advantages of using PUF to support IoT
rmware updates: (i) no need to reveal information about shared
secrets, (ii) devices can generate their own fresh keys, (iii) all com-
munication goes over an encrypted channel to prevent sning,
MitM and replay attacks.
Others have proposed distributed solutions that eliminate the sin-
gle point of failure. Chandra et al. [
5
] introduce an OTA rmware
update solution for IoT devices based on the Lightweight Mesh
(LWMesh) network protocol. Similar to our proposed system, this
solution does not rely on a centralized management service, avoid-
ing a single point of failure. However, their approach is entirely
dependent on the IoT platform using LWMesh and cannot be easily
generalized for the entire domain.
Blockchain has been shown to be a systematic approach in elim-
inating single points of failure. For instance Lee and Lee [
12
] have
proposed an alternative version of the Bitcoin blockchain [
14
] to be
used for rmware updates. Nodes in their framework are assigned
dierent roles in the process of verifying rmware updates. This
solution, which assumes that PoW occurs at the device, has not
been implemented or evaluated in practice. The PoW assumption
imposes a heavy load on IoT devices (that already have very limited
resources) to perform this task. Lim et al. [
13
] expand on the above
approach by introducing a triangular trade protocol that increases
the functionality of the platform. Their customized blockchain has
been implemented from scratch using Python, as opposed to us-
ing available open-source solutions that can be easily adopted and
generalized.
However, using public blockchain and PoW consensus algo-
rithms may not be practical in a smart city domain or in scenar-
ios with a moderately large number of sensors because such an
approach is too resource intensive for IoT devices with limited
computational capabilities. Our solution resolves this issue by del-
egating this function to an open-source permissioned blockchain
framework.
4 APPROACH
Our solution centers around a modular, distributed, and layered
architecture that uses a blockchain framework to validate updates.
The architecture, the mechanism used to validate rmware updates,
Securing Over–The–Air IoT Firmware Updates using Blockchain COINS, May 5–7, 2019, Crete, Greece
and security properties describing the threat model and incident
handling are described in the following three sections.
4.1 Architecture
The architecture proposed in this paper to secure IoT rmware
updates consists of six layers: hardware layer, protocol layer, proxy
layer, blockchain layer, service layer, and application layer as shown
in Figure 1.
Figure 1: System architecture
The hardware and protocol layers together constitute the foun-
dation of the system. The hardware layer consists of heterogeneous
IoT devices, from dierent manufacturers that have been deployed
across a community. IoT devices then communicate with the various
elements of the architecture using protocols dened by the protocol
layers (with support for encryption). These devices may communi-
cate with their hosting services using WiFi, ZigBee or Bluetooth
protocols. In order to protect the communications between vendor
services or application services and IoT devices, we propose the use
of TLS (Transport Layer Security) or DTLS (Datagram Transport
Layer Security) whenever possible.
The proxy and blockchain layers act as the middle layer and are
used to exchange, authenticate, and verify information. Ideally, the
proxy layer is transparent [
19
] to interconnected IoT devices and
components. Transparent gateways are used to facilitate connection
of IoT devices to the Internet, translate trac to HTTP (for non
HTTP protocol based IoT devices, such as ZigBee and BLE) and
interface with external APIs. Wireless routers can be used in the
proxy layer to support IoT devices that can run HTTP/HTTPS
natively, while a smart gateway (such as [
2
]) can be deployed to
allow connection of BLE devices to the Internet.
The blockchain layer is the central piece of the approach. Two
sub-layers, infrastructure and smart contracts, help incorporate the
functionality needed to support a diverse number of providers, de-
vices, and services. Components supporting the basic functionality
of a permissioned blockchain network, that is CAs for authenti-
cation and peer nodes, form the infrastructure sublayer. Nodes in
this layer are part of a consortium of IoT device manufacturers and
application service providers that are jointly responsible for main-
taining and hosting the distributed immutable ledger. Consensus
protocols ensure the integrity of the transactions in the blockchain
network so that the distributed ledger holds consistent records. The
smart contract sublayer adds an extra level of functionality and
intelligence to the system. The sublayer is responsible for imple-
menting self-executable business logic (through smart contracts) to
verify rmware update authenticity and to handle abnormal (and
possibly malicious) incidents that may occur during the update
process.
Finally, the service and application layers complete the picture
by supporting a variety of use case scenarios. More specically, the
service layer supports vendor services that IoT device manufactur-
ers want to distribute by a rmware update. The application layer
deploys and supports end user applications such as a web-based
blockchain transaction monitor or a mobile phone app that checks
rmware update status.
4.2 Firmware Update Verication
The main goal of the proposed system is to enable verication of
rmware updates in a large distributed system consisting of IoT
devices, manufacturers, and vendors; a process that is particularly
challenging as an OTA process. A robust verication mechanism
is needed to ensure rmware legitimacy before any updates are
accepted.
There are three parties involved in the verication process: the
IoT device, the vendor service, and the blockchain:
(i)
The IoT device is the actual end device in the system, respon-
sible for collecting and relaying data (e.g., smart sensors) or
executing commands (e.g., smart switches).
(ii)
The vendor service provides the functionality needed to
deliver rmware updates.
(iii)
The blockchain is the permissioned blockchain network that
supports the verication process through smart contracts.
The verication process of deploying a new rmware update
being oered through a vendor service consists of the following six
steps (Figure 2):
(1)
Vendor service initiates a new blockchain transaction that
contains the target IoT device information and SHA1 hash
of the new rmware update. The result of this transaction
(uniquely identied by a
transaction_id
) is to add a new
block to the distributed ledger.
(2)
Vendor service pushes the rmware update binary to the
target IoT device along with the
transaction_id
from the
previous step.
COINS, May 5–7, 2019, Crete, Greece He et al.
Figure 2: Firmware update verication process
(3)
IoT device receives the OTA rmware update binary from
the vendor service and it computes the SHA1 hash of the
received binary.
(4)
IoT device queries the distributed ledger along with the cal-
culated SHA1 hash and the
transaction_id
to validate the
update.
(5)
If validation suceeeds, the IoT device applies the rmware
update and sends a status update to the blockchain that
registers the operation in the ledger. Otherwise, the OTA
rmware update process will be aborted and a failure notice
will be recorded in the ledger for such attempt (the device
continues to use the same rmware it had before the update
notication).
(6)
Vendor service queries the blockchain to collect update sta-
tistics to determine further actions (for instance in case a
portion of the devices fail to execute the update).
Each blockchain transaction in the distributed ledger is dened
by the following attributes:
transaction_id
: a unique ID to reference a rmware update
initiated by a vendor service
timestamp_send
: a time stamp recording the time a vendor
service pushes the update to the blockchain
timestamp_receive
: a time stamp recording the time when
the blockchain accepts and commits the transaction to the
ledger
device_type: the IoT device type (e.g. ESP8266)
rmware_version: the version of the rmware update
rmware_hash
: SHA1 hash of the rmware update binary
as provided by the vendor service
status
: to indicate whether the targeted IoT device suc-
ceeded in updating the rmware. Its initial value is "un-
veried"
failed_aempts
: a counter recording the number of failed
rmware update attempts.
The ledger is only used to keep a record of transactions, in this
case rmware update requests, but (by default) it cannot enforce
the verication process. This lack of enforcement is why smart
contracts are needed. They enforce execution of the verication
process within the blockchain network.
Smart contracts can perform three operations:
push()
,
verify()
and
query()
. A
push()
operation is used by a vendor service to
create the initial transaction for a new rmware update request. An
IoT device calls
verify()
to verify a rmware update legitimacy.
Moreover, a vendor service may monitor the rmware update status
by using
query()
operations anytime after the update request.
This operation would typically provide update status information
including information about devices that could not successfully
run the update, how many attempts were made, and other useful
diagnostic information.
status
and
failed_aempts
are "updated" by the smart con-
tracts to document success or failure. While any updates would add
immutable records to the ledger, these two attributes would support
queries that report the entire history associated with the rmware
update requests (i.e., a set of records that share the
transaction_id
but have dierent status and failed_aempts values).
4.3 Threat Model and Incident Handling
An important part of the process of validating rmware updates
is to consider the system’s ability to deal with cyber attacks. Per-
missioned blockchains already have built-in capabilities to protect
communications between external parties and the blockchain net-
work via CAs with encryption enabled.
Our solution assumes that vendor services credentials to au-
thenticate to the blockchain via a CA are not compromised. This
assumption is not unreasonable considering that a vendor service
would be backed by a large organization and expected to have
appropriate security controls. On the other hand, IoT devices are
considered more vulnerable to DoS and MitM attacks precisely
because of their limited hardware resources.
A DoS attack could temporarily disable the availability of IoT
devices. In this case, a vendor service would not be able to push
the rmware update binary to the IoT devices. As a result, the new
rmware update would not be delivered as scheduled. A MitM
attack to the IoT devices could alter the content of the binary asso-
ciated with the rmware by injecting malicious code.
The verication algorithm used by the proposed system (Algo-
rithm 1) helps mitigate the risk of both DoS and MitM attacks by
using two types of thresholds. A time-based threshold denes a
valid time window for the update verication to complete. Assum-
ing that the operation occurs within this time window, a count-
based threshold is used to impose an upper bound on the number
of consecutive failed attempts (to avoid a case where a device is
stuck in an update loop).
The algorithm then has four possible outcomes:
(i) time window has expired
(line 21) is returned when the
time window has been exceeded, perhaps the result of a DoS
attack. Note that a vendor service may learn about update
failures by simply using a
query()
operation (as dened in
the smart contract). In case an update fails for a particular
device, the vendor service is responsible for re-initiating the
operation.
(ii) too many failed aempts
(line 18) is returned to indicate
too many consecutive failures or attempts, as this could be
the result of a device under attack (perhaps by overloading
the verication interface).
(iii) hash code mismatch
(line 15) is returned when the hash
calculated by the IoT device does not match the associated
Securing Over–The–Air IoT Firmware Updates using Blockchain COINS, May 5–7, 2019, Crete, Greece
Algorithm 1: Firmware update verication with thresholds
1function verify() (tid,c f _hash);
Input : transaction ID tid, calculated rmware SHA1 hash
c f _hash
Output : code of indicating verication status
2tr ansact ion =r et rieve(tid );
3f_hash =transaction.f irmwar e_hash;
4t_receive=tr ansaction.timestamp_receive;
5f_counter =transaction.f ail ed_attempts ;
6if current_time t_receive<time_thr eshold then
7if f_counter <counter _threshold then
8if c f hash == f_hash then
9tr ansact ion.status == veri f ied ;
10 update(tid,tr ansact ion);
11 return success code;
12 else
13 tr ansact ion.f ailed_attempts++;
14 update(tid,tr ansact ion);
15 return hash code mismatch code;
16 end
17 else
18 return too many failed aempts code;
19 end
20 else
21 return time window has expired code;
22 end
record in the ledger. This event could be the result of a MitM
attack attempting to corrupt the integrity of the rmware
update.
(iv) success
(line 11) is returned as an indication that the veri-
cation process has completed correctly in a timely fashion.
5 IMPLEMENTATION
A proof-of-concept of the entire system (Figure 3) was implemented
using an ESP8266-based IoT board, Hyperledger Fabric (an open-
source permissioned blockchain framework) and a web-service
based vendor service.
5.1 IoT Chip (ESP8266)
A low-cost, quarter-sized (25.6mm x 34.2mm) IoT board Wemos
D1 Mini (Figure 4) was used as the IoT device. This popular board
was chosen because it is WiFi-capable and Arduino-compatible
(easily extensible with a ample selection of sensors and shields).
The Wemos D1 Mini runs at 80Mhz and has 4MB of non-volatile
ash memory.
5.1.1 OTA Update Library and Limitations. A special library allows
developers to perform OTA updates rather than using the on-board
USB port. This library exposes the ESP8266 chip as an HTTP server
that can accept rmware uploads via HTTP POST requests. Due
to very limited available memory (~50KB RAM), rmware updates
must be processed in fragments. Firmware update fragments are
written to a temporary buer in Flash memory (Figure 5) through
Figure 3: End-to-end implementation overview
Figure 4: Wemos D1 Mini (middle) and its accessories: re-
lay shield (left) and temperature/humidity sensors shield
(right)
the ESP8266 built-in
Updater
library. The device reboots once the
update is completed.
It is important to note that this library, as provided by the
ESP8266 community, has two signicant limitations:
Only local MD5 validation is supported. Firmware update
binaries and their associated MD5 checksums could be in-
tercepted and altered by an adversary and the target device
could then be compromised. Furthermore, local MD5 valida-
tion is not always enabled by default.
The default update process does not support verication by
an external party before committing to the new rmware
version.
For these reasons, the update library had to be modied as described
below.
Figure 5: Firmware in the Flash
COINS, May 5–7, 2019, Crete, Greece He et al.
Table 1: Vendor service APIs
Route Request Type Request Body
/put_update POST JSON
/push_binary POST transaction ID, rmware
/query_status GET transaction ID
5.1.2 Firmware SHA1 Hash. The OTA update library was modied
by intercepting the rmware update process to support blockchain–
based SHA1 hash verication before the update is nalized. SHA1
is chosen as the hash algorithm because it ensures better integrity
properties than MD5 and is more ecient than SHA256, given the
limited resources available on the Wemos board.
There are two methods to calculate the SHA1 hash: (i) merging
all the fragments and calculating it at once or (ii) aggregating partial
results from each fragment. Calculating it at once is simpler but not
feasible for the ESP8266 chip due to insucient memory. In addition,
the ESP8266
Hash
library is not capable of calculating the hash
using the second method (aggregating partial results). Therefore,
the library was modied and extended to enable calculation of the
SHA1 hash on–the–y using rmware fragments and the capability
to interface with blockchain RESTful APIs for verication.
5.2 Vendor Service
The vendor service was implemented using Golang and the
net /http
library. It is a simple web service capable of three operations (Table
1):
A JSON object of rmware update transaction attributes can
be posted to the blockchain ledger through a smart contract
Deliver a rmware update binary along with the blockchain
transaction ID
Monitor update status
5.3 Blockchain
Hyperledger Fabric 1.1.0 was used as the permissioned blockchain
for our proof-of-concept implementation. It is an open-source plat-
form that scales well and has rich functionality.
DockerCompose
templates are used to congure the structure of the blockchain
network and its participants.
Figure 6: Hyperledger Fabric Network
The topology of the implemented Hyperledger Fabric can be
seen in Figure 6. Four organizations are dened for IoT device
manufacturers, each holding two peer nodes for the ledger.
Peer
0
(the purple node) in each organization is the anchor node used to
bridge communications among organizations. Chaincode (a smart
contract implementation) is installed on all peer nodes. Since a PBFT
(Practical Byzantine Fault Tolerance) consensus algorithm has not
been implemented in Hyperledger Fabric 1.1.0, a Kafka ordering
service is launched using Apache Kafka and ZooKeeper ensembles
to coordinate distributed communications within the blockchain
network. Kafka ordering is a CFT-based (Crash Fault Tolerance)
consensus algorithm that provides robustness and scalability. Four
CAs work as the gateways to authenticate the parties joining the
blockchain network with security tokens.
The three smart-contract operations described in Section 4.2,
are exposed using an HTTP RESTful API (Table 2) through a Hy-
perledger Fabric Client (version 1.0.2 of the client was used). This
client uses a Node.js–based (version 8.12) library that allows the
blockchain network to expose its functionality (such as querying
and invoking the Chaincode). The vendor service can also use the
API to query the status of a rmware update associated with a
particular transaction ID. Fields
status
and
failed_aempts
are
used to indicate results.
The Wemos D1 Mini was programmed to use the API, using a
transaction ID and calculated rmware hash, to verify the rmware
update. The four possible outcomes are
time window has expired
,
too many failed aempts
,
hash code mismatch
and
success
(see Section 4.3).
In addition, Hyperledger Fabric Explorer 0.3.5 was deployed (as
a blockchain application) to help us (as blockchain consortium
administrators) visualize and monitor ongoing transactions and
blocks.
6 EXPERIMENTAL RESULTS AND
EVALUATION
Two types of attacks (DoS and MitM) were performed against the
Wemos D1 Mini to test system response and its ability to protect
the integrity of the OTA rmware update process. Recall that two
thresholds are dened in Algorithm 1 to control the impact of
these attacks. A time threshold of 60 seconds is set to complete
the rmware update request while the maximum number of failed
attempts was set to 3. The current rmware update version running
on the Wemos D1 Mini was set to 1.0 and the OTA rmware update
aims to bring it to version 2.0. Furthermore, to evaluate perfor-
mance and scalability, a simulation was programmed to measure
the response time of the RESTful APIs when there are 1 to 10000
transactions in the ledger.
6.1 Denial-of-service Attack
The current version of the OTA rmware update library for the
ESP8266 used by the Wemos D1 Mini is vulnerable to the following
exploit. If the uploaded rmware format is invalid, the board reboots
automatically. This vulnerability is used to conduct a DoS attack
on the IoT device. The goal of the attack is to verify that even if the
IoT device is under a DoS attack, the terms of the smart contract
will not be violated. A
bash
script was built to continuously upload
Securing Over–The–Air IoT Firmware Updates using Blockchain COINS, May 5–7, 2019, Crete, Greece
Table 2: RESTful APIs for smart contract
Smart Contract Request Type Parameters Response
push() POST transaction attributes as JSON object transaction ID
verify() POST transaction ID, rmware SHA1 hash verication results
query() GET transaction ID verication status
a small size le that contains random characters that would keep
the Wemos D1 Mini in a rebooting loop for as along as the script is
run.
The attack is then performed as follows:
Execute the script for two minutes to DoS the Wemos D1
Mini, eectively bringing it oine
While the Wemos D1 Mini is oine, use the vendor service
to push a new rmware update
Have the vendor push the rmware update at the end of the
two minutes when the Wemos D1 Mini is back online
The system behaved as expected and the nal rmware update
push was rejected because the time threshold of 60 seconds was
exceeded. Figure 7 displays the output from the Arduino serial
console for the ESP8266 board under attack. Line 20 shows that
the transaction has expired, thus the verication of the rmware
update fails and the update process is aborted. While the rmware
update is not performed, the system resisted the attack because the
terms of the smart contract with respect to the time threshold were
preserved.
Figure 7: Partial serial console output for DoS attack
6.2 Man-in-the-middle Attack
A MitM attack is conducted while the vendor service is pushing
the rmware update to the IoT device to evaluate system response.
Two tools,
mitmproxy
and
SwitchyOmeдa
, were used to conduct
the attack.
mitmproxy
is a command-line based MitM attack proxy
server with built-in functions to intercept trac with customized
lters.
SwitchyOmeдa
is a Chrome web browser extension that
helps route HTTP trac through a proxy server.
First,
mitmproxy
(using
~q & ~t “multipart/form-data”
as
a lter) is launched on port 8080 to intercept rmware upload
trac to the Wemos D1 Mini. A new prole is then congured with
SwitchyOmeдa
to use the
mitmproxy
proxy server already running
on port 8080. At this point, characters are randomly injected in
the body of the message using the in-app editor of
mitmproxy
to
simulate malicious code injection.
Figure 8: Partial serial console output for MitM attack
Figure 8 shows output from the Arduino serial console indicating
that it has failed to verify the rmware update because the calcu-
lated hash (Line 14) does not match the hash of the original rmware
update binary
457de643c3113667f18660bf12c999db721a3fc4
as
obtained from the Hyperledger Fabric.
We also conducted the same attack multiple times within the
preset time threshold of 60 seconds to evaluate response when the
count threshold (for update attempts) is exceeded. As expected, the
"too many failed attempts" error message was shown in the output
for the 4th attempt when using a preset quantity threshold of 3.
Once this error is detected, and even if the correct rmware update
was pushed, the update would still fail. Once again, this scenario
shows the proposed system preserves its integrity during a MitM
attack with respect to the terms specied in the smart contract.
6.3 Performance and Scalability
Since one of the goals is to design a system that can be used in
a smart city or a domain with a large number of devices, it is
important to evaluate scalability. A total of three dierent probes
COINS, May 5–7, 2019, Crete, Greece He et al.
are deployed, tasked with measuring response time for the RESTful
API
push()
,
verify()
, and
query()
operations from 1 to 10,000
transactions in the ledger. The Hyperledger Fabric keeps a cache
image of the entire state of the system to evaluate any single query
regardless of size. We expect the response time to converge and
stabilize even as the number of records increase. A Dell Precision
Tower workstation with dual Intel Xeon E5 processors (12 cores),
32G of RAM, 512G of SSD that runs Gentoo Linux with LTS kernel
4.14.83 was used as the testing platform.
After collecting raw data from the probes, the average response
times are computed for each API for 100, 200, 500, 1000, 2000, 5000
and 10000 transactions in the ledger. Figure 9 shows the average
response time in milliseconds for push(),verify() and query().
The average response time of
push()
is slightly larger than that of
verify()
because of the extra overhead associated with transaction
attributes. The results matched the expectations, showing that the
proposed system has good scalability properties.
Figure 9: API average response time
7 CONCLUSIONS AND FUTURE WORK
A system is proposed to preserve the integrity of IoT OTA rmware
updates using a permissioned blockchain rather than the more com-
monly used centralized solution. The approach is a viable alterna-
tive, capable of supporting a heterogeneous environment involving
a large number of IoT devices and a variety of vendor or service
providers. Authentication and security services help protect the
integrity of the system, while smart contracts are used to describe
enforceable terms associated with the rmware update.
A proof-of-concept system was built to demonstrate the feasi-
bility of the approach using the Hyperledger Fabric (blockchain),
Chaincode (smart contracts) and the Wemos D1 Mini board (ESP8266–
based IoT device). Preliminary results are encouraging, both from
an operational and cyber security point of view. The system scales
well and smart contracts oer the exibility needed to incorporate
logic and conditions. DoS and MitM attacks were used to show that
the terms and conditions established by the smart contracts were
preserved even when the system is under attack.
Future work will concentrate on (i) incorporating a diverse vari-
ety of IoT devices, (ii) adding a layer of intelligence that facilitates
the creation of smart contracts and (iii) improving monitoring ca-
pabilities of the entire system.
REFERENCES
[1] [n. d.]. Arduino–Home. https://www.arduino.cc/. Accessed: 2019-01-11.
[2]
[n. d.]. TIDC–BLE–TO–WIFI–IOT–GATEWAY Bluetooth to Wi–
Fi IoT Gateway Referece Design | Ti.com. http://www.ti.com/tool/
TIDC-BLE- TO- WIFI-IOT-GATEWAY. Accessed: 2019-01-11.
[3]
Carlos E. Andrade, Simon D. Byers, Vijay Gopalakrishnan, Emir Halepovic, Milap
Majmundar, David J. Poole, Lien K. Tran, and Christopher T. Volinsky. 2017.
Managing Massive Firmware-Over-The-Air Updates for Connected Cars in Cel-
lular Networks. In Proceedings of the 2Nd ACM International Workshop on Smart,
Autonomous, and Connected Vehicular Systems and Services (CarSys ’17). ACM,
New York, NY, USA, 65–72. https://doi.org/10.1145/3131944.3131953
[4]
Mohamed Baza, Mahmoud Nabil, Noureddine Lasla, Kemal Fidan, Mohamed
Mahmoud, and Mohamed Abdallah. 2018. Blockchain-based Firmware Update
Scheme Tailored for Autonomous Vehicles. arXiv:arXiv:1811.05905 https://arxiv.
org/pdf/1811.05905.pdf
[5]
Hans Chandra, Erwin Anggadjaja, Pranata Setya Wijaya, and Edy Gunawan.
2016. Internet of Things: Over-the-Air (OTA) rmware update in Lightweight
mesh network protocol for smart urban development. In 2016 22nd Asia-Pacic
Conference on Communications (APCC). 115–118. https://doi.org/10.1109/APCC.
2016.7581459
[6]
Byung-Chui Choi, Seoung-Hyeon Lee, Jung-Chan Na, and Jong-Hyouk Lee.
2016. Secure rmware validation and update for consumer devices in home
networking. IEEE Transactions on Consumer Electronics 62, 1 (February 2016),
39–44. https://doi.org/10.1109/TCE.2016.7448561
[7]
Giovani Gracioli and Antônio A. Fröhlich. 2008. An Operating System Infrastruc-
ture for Remote Code Update in Deeply Embedded Systems. In Proceedings of
the 1st International Workshop on Hot Topics in Software Upgrades (HotSWUp ’08).
ACM, New York, NY, USA, Article 3, 5 pages. https://doi.org/10.1145/1490283.
1490287
[8]
Simona Ibba, Andrea Pinna, Matteo Seu, and Filippo Eros Pani. 2017. City-
Sense: Blockchain-oriented Smart Cities. In Proceedings of the XP2017 Scientic
Workshops (XP ’17). ACM, New York, NY, USA, Article 12, 5 pages. https:
//doi.org/10.1145/3120459.3120472
[9] Jinsik Kim and Pai H. Chou. 2010. Energy-Ecient Progressive Remote Update
for Flash-Based Firmware of Networked Embedded Systems. ACM Trans. Des.
Autom. Electron. Syst. 16, 1, Article 7 (Nov. 2010), 26 pages. https://doi.org/10.
1145/1870109.1870116
[10]
Alexander Kuzmin. 2017. Blockchain-based structures for a secure and operate
IoT. In 2017 Internet of Things Business Models, Users, and Networks. 1–7. https:
//doi.org/10.1109/CTTE.2017.8260937
[11]
Lukas Kvarda, Pavel Hnyk, Lukas Vojtech, and M Neruda. 2017. Software Imple-
mentation of Secure Firmware Update in IoT Concept. Advances in Electrical and
Electronic Engineering 15 (11 2017). https://doi.org/10.15598/aeee.v15i4.2467
[12]
Boohyung Lee and Jong-Hyouk Lee. 2017. Blockchain-based Secure Firmware Up-
date for Embedded Devices in an Internet of Things Environment. J. Supercomput.
73, 3 (March 2017), 1152–1167. https://doi.org/10.1007/s11227- 016-1870-0
[13]
Jea-Min Lim, Youngpil Kim, and Chuck Yoo. 2018. ChainVeri: Blockchain-based
Firmware Verication System for IoT environment. In 2018 IEEE International
Conference on Blockchain (Blockchain-2018). 1050–1056. https://doi.org/10.1109/
Cybermatics_2018.2018.00194
[14]
Satoshi Nakamoto. 2008. Bitcoin: A peer-to-peer electronic cash system,
http://bitcoin.org/bitcoin.pdf.
[15]
M. A. Prada-Delgado, A. Vázquez-Reyes, and I. Baturone. 2017. Trustworthy
rmware update for Internet-of-Thing Devices using physical unclonable func-
tions. In 2017 Global Internet of Things Summit (GIoTS). 1–5. https://doi.org/10.
1109/GIOTS.2017.8016282
[16]
Chu Jay Tan, Junita Mohamad-Saleh, Khairu Anuar Mohamed Zain, and Zulqar
Ali Abd. Aziz. 2017. Review on Firmware. In Proceedings of the International
Conference on Imaging, Signal Processing and Communication (ICISPC 2017). ACM,
New York, NY, USA, 186–190. https://doi.org/10.1145/3132300.3132337
[17]
Xiwei Xu, Ingo Weber, Mark Staples, Liming Zhu, Jan Bosch, Len Bass, Cesare
Pautasso, and Paul Rimba. 2017. A Taxonomy of Blockchain-Based Systems for
Architecture Design. In 2017 IEEE International Conference on Software Architec-
ture (ICSA). 243–252. https://doi.org/10.1109/ICSA.2017.33
[18]
Alexander Yohan, Nai-Wei Lo, and Suttawee Achawapong. 2018. Blockchain-
based Firmware Update Framework for Internet-of-Things Environment. In
Proceedings of the 2018 International Conference on Information and Knowledge
Engineering (IKE ’18). 151–155. https://csce.ucmss.com/cr/books/2018/LFS/
CSREA2018/IKE9004.pdf
[19]
Kazım Rıfat Özyılmaz and Arda Yurdakul. 2017. Work-in-progress: integrating
low-power IoT devices to a blockchain-based infrastructure. In 2017 International
Conference on Embedded Software (EMSOFT). 1–2. https://doi.org/10.1145/3125503.
3125628
... In recent years there have been several proposals for secure software update systems that are designed for IoT [7], [10], [11] and embedded systems [12], [13]; however, there has not been much research (to our knowledge) aiming to broadly understand the IoT software/firmware update landscape. Does this device check for updates on a regular basis? ...
... A unique approach to IoT firmware update systems was designed by Boudguiga et al. in 2017, which is a conceptual design for better accountability and availability for IoT firmware updates by leveraging blockchain technology [10]. Later in 2019, He et al. presented a similar implementation that secures IoT firmware updates using blockchain smart contacts [11]. While using a blockchain is a novel approach, the large-scale feasibility of these designs is questionable due to the various scalability issues blockchain is facing [34]. ...
Preprint
Software update systems are critical for ensuring systems remain free of bugs and vulnerabilities while they are in service. While many Internet of Things (IoT) devices are capable of outlasting desktops and mobile phones, their software update practices are not yet well understood. This paper discusses efforts toward characterizing the IoT software update landscape through network analysis of IoT device traffic. Our results suggest that vendors do not currently follow security best practices, and that software update standards, while available, are not being deployed. We discuss our findings and give a research agenda for improving the overall security and transparency of software updates on IoT.
... [89], [90] [86], [91], [88], [92] Distributed • Blockchain: Uses distributed immutable ledgers, consensus algorithms and smart contracts to record and validate firmware update and related transactions. Permissioned blockchain uses six layered architecture to deliver firmware update. ...
... [89], [90] [93] ...
Preprint
Full-text available
Implantable Medical Devices (IMD) is a fast pace growing medical field and continues to grow in the foreseeable future. Advancement in science and technology has led to the IMD devices offering advanced medical treatments. Modern IMDs can automatically monitor and manage different patients' health conditions without any manual intervention from medical professionals. While IMDs are also becoming more connected to enhance the delivery of care remotely and provide the means for both patients and physicians to adjust therapy at the comfort of their homes, it also increases security related concerns. Adversaries could take advantage and exploit device vulnerabilities to manipulate device settings remotely from anywhere around the world. This manuscript reviews the current threats, security goals, and proposed solutions by comparing them with their strengths and limitations. We also highlight the emerging IMD technologies and innovative ideas for new designs and implementations to improve the security of IMDs. Finally, we conclude the article with future research directions toward securing IMD systems to light the way for researchers.
... Moreover, [26] presents an interesting analysis of the feasibility of partial and full OTA software updates for low-power wide-area network communication technologies in the internet of things (IoT). A blockchain-based framework is proposed in [16] to secure OTA firmware update process over IoT devices. Other techniques identify black-hole attacks in typical wireless scenarios, for instance, acknowledgmentbased [27], clustering-based [28], cross-layer collaboration, trust-based, and IDS based schemes [29]. ...
Preprint
Full-text available
With recent advancements in software-defined vehicles, over-the-air (OTA) software updates are crucial to roll out new software and patches for connected vehicles. Traditionally, outdated vehicles are recalled by the manufacturers, however, owners are notoriously difficult to reach with recall notices. Also, organizational and procedural challenges result in many outdated vehicles with insecure and unstable software. In this paper, we propose a dissemination framework for OTA updates using a federated fog environment. Pushing the update to all vehicles via the fog nodes may congest the network, leading up to a single-point failure for update dissemination, as well as, disruption to other installed services at the fog nodes.We propose a software-defined mechanism to select a pivot, which gets the update from the fog node and streams it to other vehicles. Moreover, a timer-barrier mechanism is proposed to identify any malicious vehicles that are barred from participating in pivot selection. The experimental evaluation demonstrates that the proposed scheme improves network convergence time by 40% with 95% node trustworthiness.
... A inclusão de um recurso para atualização remota OTA (HE et al., 2019) pode facilitar a vida do administrador do sistema, pois não será necessário se deslocar ao ponto de instalação do dispositivo para realizar sua manutenção, caso esta esteja restrita a mudanças ou adequações de código-fonte. Além disso, para fazer uma atualização manual pode ser necessário realizar outras tarefas trabalhosas como remover o dispositivo de um local alto, como uma torre, ou de perigo iminente, como uma caldeira. ...
Article
Full-text available
Resumo O recurso Over-The-Air (OTA) é uma solução para gerenciar as atualizações de software em dispositivos IoT instalados em locais de difícil acesso, como caldeiras, piscinas e torres. Essa facilidade pode gerar um problema: caso o dispositivo esteja programado para executar tarefas em segundo plano ou hibernar alternadamente, como saber em que momentos do dia ele fica ativo? O presente trabalho apresenta uma solução para os desenvolvedores que utilizam OTA em dispositivos IoT, permitindo-lhes monitorar a atividade do dispositivo em tempo real, além de poder ser empregado como ferramenta para monitoramento manual, facilitando a verificação de estado em locais remotos e de difícil acesso. Palavras-chave: ESP8266, IoT, Monitoramento, OTA
... Even if they are convenient, they are vulnerable to attacks because physical access is not required. Moreover, most frameworks use a centralized architecture to update a potentially large number of devices, which broadens the threat landscape [149]. Centralized servers are like sitting ducks waiting to be picked off. ...
Article
Full-text available
Blockchain has recently attracted significant academic attention in research fields beyond the financial industry. In the Internet of Things (IoT), blockchain can be used to create a decentralized, reliable, and secure environment. The use of blockchain in IoT applications is still in its early stages, particularly at the low end of the computing spectrum. As a result, the future roadmap is hazy, and several challenges and questions must be addressed. Several articles combining blockchain technology with IoT have recently been released, but they are limited to shallow technological potential discussions, with very few providing an in-depth examination of the complexities of implementing blockchain technology for IoT. Therefore, this paper aims to coherently and comprehensively provide current cutting-edge efforts in this direction. It provides a literature review of IoT and blockchain integration by examining current research issues and trends in the applications of blockchain-related approaches and technologies within the IoT security context. We have surveyed published articles from 2017 to 2021 on blockchain-based solutions for IoT security, taking into consideration different security areas and then, we have organized the available articles according to these areas. The surveyed articles have been chronologically organized in tables for better clarity. In this paper, we try to investigate the vital issues and challenges to the integration of IoT and blockchain, and then investigate the research efforts that have been conducted so far to overcome these challenges.
... Many researchers used the blockchain solution to ensure security in the FUOTA process. In [9] authors created a blockchain framework with smart contracts to accomplish it. A system was implemented and assessed using this approach. ...
Article
Full-text available
The remarkable evolution of the IoT raised the need for an efficient way to update the device’s firmware. Recently, a new process was released summarizing the steps for firmware updates over the air (FUOTA) on top of the LoRaWAN protocol. The FUOTA process needs to be completed quickly to reduce the systems’ interruption and, at the same time, to update the maximum number of devices with the lowest power consumption. However, as the literature showed, a single gateway cannot optimize the FUOTA procedure and offer the above mentioned goals since various trade-offs arise. In this paper, we conducted extensive experiments via simulation to investigate the impact of multiple gateways during the firmware update process. To achieve that, we extended the FUOTAsim simulation tool to support multiple gateways. The results revealed that several gateways could eliminate the trade-offs that appeared using a single gateway.
... Thus, firmware of IoT devices for smart homes need to be updated automatically in order to cope with novel security vulnerability, as there is lack of technical support [78]. Furthermore, in order to prevent tempering and to ensure the integrity and authenticity of updates, there is a need to implement a certificate based digital signature scheme [79]. ...
Article
Full-text available
Internet of things (IoT) is leading a new digital age. IoT is regarded as the significant frontier that can improve almost all aspect of our lives. Currently, the IoT technology faces several challenges to academic researchers and industry practitioners, mainly that related with security of data. The objective of this study is to develop a prioritization-based taxonomy of the challenging factors that could hinders the security of IoT. By conducting the literature review and questionnaire survey studies 21 challenging factors were identified that are reported in existing literature and in real-world practices. Moreover, the identified challenging factors are mapped in the core domain of IoT (i.e. smart city, smart home, smart wearable’s and smart health care); and apply the fuzzy- AHP approach to rank the identified challenging factors with respect to their criticality for security of IoT technology. The application of fuzzy-AHP is novel in this research area as it is successfully applied in other domains of information technology to address the multi-criterion decision making problems. This study is contributing by providing a prioritization-based taxonomy of the IoT security challenging factors that could help the practitioners and research community to revise and develop the new strategies for the secure IoT.
Article
Internet of Things (IoT) has come a long way since its inception. However, the standardization process in IoT systems for a secure IoT solution is still in its early days. Numerous quality review articles have been contributed by researchers on existing frameworks, architectures, as well as the threats to IoT on different layers. However, most of the existing work neglects the security aspects of firmware in the IoT ecosystem. As such, there is a lack of comprehensive survey on IoT firmware security that highlights critical reasons for firmware insecurity in IoT, lists vulnerabilities, and perform an in-depth review of the principal analysis techniques. This article aims to fill that gap by delivering, to the best of our knowledge, the first comprehensive review article of the firmware (in)security of IoT devices. Starting by highlighting the importance of firmware security, this research work recognizes critical reasons behind the insecurity of firmware by discussing technical, commercial, standardization, and researching aspects. In particular, the scope, evolution, and internals of IoT firmware along with their security implications are discussed. Furthermore, a taxonomic classification of IoT firmware vulnerabilities has been presented. We also discuss complications that hinder the detection of firmware vulnerabilities before doing a detailed analysis of existing vulnerability assessment tools and techniques. A comparative analysis of the principal analysis techniques is provided in terms of the vulnerabilities they discover, the methodology they employ, and the platform and/or architectures they support. Towards the end, some key research issues have been identified to encourage and facilitate research in the firmware security domain of IoT. Finally, some recommendations have been provided for the IoT device vendors, developers, and integrators.
Article
Implantable Medical Devices (IMD) is a fast pace growing medical field and continues to grow in the foreseeable future. Advancement in science and technology has led to the IMD devices offering advanced medical treatments. Modern IMDs can automatically monitor and manage different patients’ health conditions without any manual intervention from medical professionals. While IMDs are also becoming more connected to enhance the delivery of care remotely and provide the means for both patients and physicians to adjust therapy at the comfort of their homes, it also increases security-related concerns. Adversaries could take advantage and exploit device vulnerabilities to manipulate device settings remotely from any-where around the world. This manuscript reviews the current threats, security goals, and proposed solutions by comparing them with their strengths and limitations. We also highlight the emerging IMD technologies and innovative ideas for new designs and implementations to improve the security of IMDs. Finally, we conclude the article with future research directions toward securing IMD systems to light the way for researchers.
Chapter
An increasing reliance on smart and connected devices in our homes, workplaces, and in everyday life has led to the rapid growth of the Internet-of-Things (IoT) technology. While some IoT devices communicate without the involvement of their users, their functionalities must be protected against various attacks. The firmware update process is a fundamental security challenge in the world of embedded devices. Therefore, this research work proposes and implements a secure firmware update delivery mechanism for IoT devices. To assure a secure firmware update, the process should be conducted through a trusted network. The proposed solution is therefore deployed in a blockchain network. This mechanism ensures that the firmware version of the IoT device is verified while also validating the integrity of the file itself and then downloading the latest version of the firmware update. All these tasks are performed securely through a Hyperledger blockchain network. The main objective of this solution is to mitigate attacks on the firmware update process by ensuring that IoT firmware is up to date and that it has not been modified either during the transfer process or as it is installed on the IoT device.KeywordsBlockchainTrustIoTFirmwareEmbedded devices
Article
Full-text available
This paper focuses on a survey of secure firmware update in the Internet of Things, design and description of safe and secure bootloader implementation on RFID UHF reader, encryption with AES-CCM and versioning with use of external backup flash memory device. In the case of problems with HW compatibility or other unexpected errors with new FW version, it is possible to downgrade to previous FW image, including the factory image. Authentication is provided by the UHF RFID service tag used to extract unique initialization vector of the encryption algorithm for each update session. The results show slower update speed with this new upgrade method of approximately 27% compared to older one, using the only AES-CBC algorithm.
Conference Paper
Full-text available
Blockchain is an emerging technology for decentralised and transactional data sharing across a large network of untrusted participants. It enables new forms of distributed software architectures, where agreement on shared states can be established without trusting a central integration point. A major difficulty for architects designing applications based on blockchain is that the technology has many configurations and variants. Since blockchains are at an early stage, there is little product data or reliable technology evaluation available to compare different blockchains. In this paper, we propose how to classify and compare blockchains and blockchain-based systems to assist with the design and assessment of their impact on software architectures. Our taxonomy captures major architectural characteristics of blockchains and the impact of their principal design decisions. This taxonomy is intended to help with important architectural considerations about the performance and quality attributes of blockchain-based systems.
Article
Full-text available
Embedded devices are going to be used extremely in Internet of Things (IoT) environments. The small and tiny IoT devices will operate and communicate each other without involvement of users, while their operations must be correct and protected against various attacks. In this paper, we focus on a secure firmware update issue, which is a fundamental security challenge for the embedded devices in an IoT environment. A new firmware update scheme that utilizes a blockchain technology is proposed to securely check a firmware version, validate the correctness of firmware, and download the latest firmware for the embedded devices. In the proposed scheme, an embedded device requests its firmware update to nodes in a blockchain network and gets a response to determine whether its firmware is up-to-date or not. If not latest, the embedded device downloads the latest firmware from a peer-to-peer firmware sharing network of the nodes. Even in the case that the version of the firmware is up-to-date, its integrity, i.e., correctness of firmware, is checked. The proposed scheme guarantees that the embedded device’s firmware is up-to-date while not tampered. Attacks targeting known vulnerabilities on firmware of embedded devices are thus mitigated.
Conference Paper
We consider the problem of managing Firmware Over-The-Air (FOTA) updates for cars at a massive scale over a cellular network. This problem is constrained by factors like large number of cars, a need to perform updates quickly and securely, ability to do the update anywhere and any time, and delivering the often large update without harming the network. We present a scheduling approach for managing large FOTA downloads in a cellular network that combines historical network load with car usage and location analytics. The proposed approach uses a combination of heuristics and an optimized scheduler and applies them to schedule the admission of cars to download FOTA. Using real network data from a large cellular provider that includes a million cars and nearly a billion radio-level network connections, we show that our scheduling approach is feasible and practical. We also show that it is possible to manage FOTA even when device and network models use high levels of aggregation over time. Simulation results show that our method improves over random uncontrolled approaches by (i) reducing median download startup delay by 48%, (ii) reducing the number of cars that don't complete the update by 10% and most importantly, (iii) reducing the load in busy cells by up to 37%.
Conference Paper
The ever-increasing number of IoT devices necessitates a secure and scalable infrastructure to store and process generated data. Blockchain is an ideal choice with its decentralized, trustless ar- chitecture. However, low-power IoT end-devices do not possess enough horsepower to run a software client for intensive blockchain calculations. The purpose of this paper is to create a proof of con- cept to enable low-power, resource-constrained IoT end-devices accessing a blockchain-based infrastructure. To achieve this aim, an IoT gateway is con gured as a blockchain node and an event-based messaging mechanism for low-power IoT end-devices is proposed. A demonstration of such a system is realized using LoRa nodes and gateway in a private Ethereum network.
Conference Paper
A smart city is a connected system in which things produce a huge quantity of data. We focused the attention on monitoring the environment quality in urban area by means of a distributed network of small mobile sensors that are devices on the Internet of Things (IoT). Sensors produce digital measurements, useful for investigating and studying the life quality in every part of the city. In our vision, environmental data must be available by everyone and shared with citizens, but it must be unmodifiable. We propose to solve the problem of the sensors data storage and management using a disruptive technology called blockchain. The blockchain responds to the demand of availability and unchangeability and, thanks to the potentiality of smart contracts, makes us able to manage sensor information and implement a control logic. In order to develop the software based on blockchain we chose to apply the SCRUM methodology because of its capabilities of being a flexible, adaptive and iterative methodology.