J Supercomput (2017) 73:1152–1167

DOI 10.1007/s11227-016-1870-0

Blockchain-based secure firmware update

for embedded devices in an Internet of Things
environment

Boohyung Lee1 · Jong-Hyouk Lee1

Published online: 13 September 2016

© Springer Science+Business Media New York 2016

Abstract 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.

Keywords Blockchain · Firmware verification and update · Embedded device

This work was supported by Basic Science Research Program through the National Research Foundation
of Korea (NRF) funded by the Ministry of Science, ICT and Future Planning (NRF-2014R1A1A1006770).

B Jong-Hyouk Lee
jonghyouk@pel.smuc.ac.kr; hurryon@gmail.com; jonghyouk@smu.ac.kr
Boohyung Lee
boohyung@pel.smuc.ac.kr

1 Protocol Engineering Lab., Sangmyung University, Cheonan, Republic of Korea

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1153

1 Introduction

According to the Gartner’s report [1], the Internet of Things (IoT) era will change our
lives with network connected IoT devices. The number of IoT devices is expected to
be 25 billion by 2020 and the number will continuously increase. The IoT devices
are tiny and small, while those are mostly embedded devices designed for specific
operations such as sensing and controlling.
Recent cyber attacks are targeting firmware, which is a software program on an
embedded device [2], rather than services built on well-turned servers [3]. Due to lim-
ited resources and capacities of embedded devices, strong security properties have not
been applied yet to the embedded devices. Many bugs and vulnerabilities of embedded
devices are reported every day and those are being used by attackers to break into the
embedded devices.
One of feasible ways to protect the embedded devices is to shorten the attack
window time by installing a latest firmware. In other words, updating the embedded
devices with the latest firmware helps to minimize effects of attacks targeting known
firmware vulnerabilities. A secure firmware update requires a correct firmware version
check, validation, and download, while supporting integrity. In addition, due to the
increasing number of the embedded devices in the IoT era, excessive network traffic
may occur when downloading the latest firmware simultaneously from a dedicated
firmware update server. The secure firmware update thus requires a means to avoid
such a current client–server model for firmware distribution in an IoT environment.
With this in mind, in this paper, we propose a new firmware update scheme that
utilizes a blockchain technology. In the proposed scheme, an embedded device requests
its firmware update to blockchain nodes on a peer-to-peer decentralised network. It
then receives a response from a blockchain node to determine whether its firmware
is up-to-date or not. When the firmware is not latest, the embedded device requests
a metadata file to download the latest firmware from a peer-to-peer firmware sharing
network consisting of the blockchain nodes. Even in the case that the version of the
firmware is up-to-date, the firmware integrity is checked via the blockchain nodes.
Accordingly, the proposed scheme guarantees the correctness and recentness of the
firmware on the embedded device in the IoT era.
This paper, which is an extended version of the paper published in Proc. of Qshine
2016 [4], is organized as follows. Section 2 provides related works. Section 3 presents
the proposed scheme with the overall architecture and operation procedures. In Sect. 4,
we discuss the proposed scheme’s strengths and weaknesses. Section 5 concludes this
paper.

2 Preliminaries

2.1 Remote firmware updates

The ability to securely update firmwares of deployed embedded devices over networks
is one of essential features nowadays. Vendors use the remote firmware update to
provide new functionalities and also to patch vulnerabilities on the embedded devices.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1154 B. Lee, J.-H. Lee

In general, a vendor maintains its own firmware repository that contains pre-compiled
binaries of the firmware for embedded devices [3,5]. When requested, the firmware
file is downloaded to the embedded device.
For securing the remote firmware update, asymmetric cryptographic algorithms
such as ECC or RSA are normally used. For instance, to provide integrity and authen-
tication of the firmware, the message digest over the original firmware file is calculated
with a hash function and then the message digest is digitally signed using a private key.
The generated digital signature is attached to the firmware file with the corresponding
public key of the private key. After downloading the firmware file from the repos-
itory, a security check process is performed before the actual firmware update, i.e.,
the digital signature is validated only with the attached public key. Once the security
check process is successfully done, the actual firmware update is started on the target
embedded device.
The current model for firmware distribution from the repository to the embed-
ded device adopts the client–server model that means excessive network traffic may
occur when requesting the firmware update files from embedded devices simultane-
ously. When we consider the IoT environment that tens of millions of the embedded
devices are possibly required to be updated simultaneously, this client–server model
is inappropriate. In addition, the asymmetric cryptographic algorithm, which is used
for message signing, requires a complex key management and protection, e.g., private
keys must be well securely used and maintained for each firmware version.

2.2 Blockchain

The blockchain was first introduced in 2009 by an anonymous person, Nakamoto

Satoshi [6]. It was first used as a public ledger to provide trust transactions without an
involvement of the third party for Bitcoin, which is a digital currency.
In the blockchain, a block is used to securely store information. Every block contains
a hash value of the previous block header that forms a type of chain [7]. It is then used
to authenticate the data and guarantee the block’s integrity. The structure of a block,
for instance in Bitcoin, consists of the block header and the block body. The block
header is composed of the block size, version, previous block header’s hash, merkle
tree root, etc. The block body is composed of the merkle tree and transaction. A merkle
tree is a tree in which the leaf nodes contain the hashes of blocks and the internal nodes
contain the hashes of their children so that it enables efficient and secure verification
of the blocks [8]. For instance, a blockchain node can quickly verify if the block it
receives from other blockchain nodes have not been tampered with or the block is
not corrupted during the transmission. In Bitcoin, a transaction is broadcasted to a
blockchain network and is collected into blocks.
The blockchain relies on mainly two cryptographic methods: digital signature and
cryptographic hash function. A digital signature is a way for demonstrating the authen-
ticity of a digital message. It can be used to provide integrity and authentication of
data as well as non-repudiation. A sender signs a message using the sender’s private
key. After a receiver receives this message, it verifies the message using the sender’s
public key. This message can be verified by anyone holding the valid public key of the

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1155

sender [9]. A cryptographic hash function is a mathematical operation that computes

a hash value over a given input. The function is deterministic, i.e., the same input will
always produce the same output, with the following properties: pre-image resistance,
second pre-image resistance, and collision resistance. In the blockchain for Bitcoin, a
SHA-256 hash function is used [10].

3 Proposed secure firmware update

The proposed secure firmware update scheme enables that an embedded device
requests its firmware update to blockchain nodes and receives a response from a
blockchain node to determine whether the device’s firmware is up-to-date or not. If
the firmware is not up-to-date, then a metadata file with a peer list to download the
latest firmware is provided to the device so that the embedded device can keep the lat-
est firmware by downloading the latest firmware from a peer-to-peer firmware sharing
network consists of the blockchain nodes. Note that the peer-to-peer firmware sharing
network can be implemented by BitTorrent [11]. If the firmware is up-to-date, then
the firmware integrity is checked via the blockchain nodes. Note that the embedded
device is a peer involved in the blockchain network and the firmware sharing network
as well. Notations used in this paper are shown in Table 1.

3.1 Overview

Figure 1 depicts the overall architecture of the proposed scheme. The following entities
are defined:

• Blockchain node A blockchain node is a node in a blockchain network of the

proposed scheme. A set of blockchain nodes is denoted as B = {b1 , b2 , . . . , bn }
and bi ∈ B.
• Normal node A normal node is an embedded device, which updates its firmware, in
a blockchain network. A set of normal nodes is denoted as N = {n 1 , n 2 , . . . , n n },
n i ∈ N , and N ⊂ B. It can be a request node or a response node. If a node requests
its firmware update, the node becomes a request node. When a request node sends
a request message to update its firmware, other normal nodes become response
nodes from the perspective of the request node. A normal node’s ID is a random
unique value, which is generated when it starts its firmware update request based
on its public key.
• Verification node A verification node is a node, which maintains firmware informa-
tion such as verifiers, files of firmwares per model in its database. The verification
node is operated by a vendor of firmwares so that relevant files for latest firmware
updates can be provided to the verification node from the vendor node via a
secure channel establish between them. A set of verification nodes is denoted
as V = {v1 , v2 , . . . , vn }, vi ∈ V , and V ⊂ B. A verification node’s public key is
available to all nodes in the blockchain network.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1156 B. Lee, J.-H. Lee

Table 1 Notations
Notation Definition

N A set of normal nodes

V A set of verification nodes
B A set of blockchain nodes
D A model name of n i
r Random number
ts Timestamp
v Current firmware version of n i
vnew Latest firmware version of n i
v Current firmware version of n j
fv Current firmware file of v
f v Current firmware file of v 
f vnew Latest firmware file of vnew
H ( f v) Verifier generated with f v
H ( f v ) Verifier generated with f v 
H ( f vnew ) Verifier generated with f vnew
Lvnew Peer list shared with f vnew
Mvnew Metadata file of f vnew
I Dn i Identifier of n i
I Dvi Identifier of vi
E Elliptic curve
P Base point of elliptic curve E
PU n i Public key of n i
P Rn i Private key of n i
PU vi Public key of vi
P Rvi Private key of vi
Sign i Signature of n i
Sigvi Signature of vi

• Vendor node A vendor node is outside of a blockchain network but keeps a secure
channel with a verification node to provide the relevant files for latest firmware
updates.
All blockchain nodes are either peers or trackers in a firmware sharing network, i.e.,
normal nodes are peers, whereas verification nodes are trackers. A verification node,
which is a BitTorrent tracker, keeps track of where firmware copies reside on peers,
which firmware copies are available, and helps coordinate efficient transmission and
reassembly of the copied firmware files [12]. When a normal node, more specifically a
request node, downloads the latest firmware file, it requires a metadata file and a peer
list that are provided from the verification node. Note that the metadata file contains the
filename, hash value of the file, piece length, tracker URL, etc., whereas the peer list
is composed of a hash value of the file and IP addresses of peers that have a complete
firmware file or an incomplete firmware file.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1157

Verification Node
n3
n4 v2
Response Node v1
n1 n5
Request Node n8
nj n2
Vendor Node n6 n7
ni

Fig. 1 Overall architecture

Firmware version check

request from ni

Verification Node ( vi ) Depending on the node Nomal Node ( nj )

receives the request

v and vnew equal?

(i.e., ni's firmware up-to- v and v' equal?
date?)

Yes (C1-1 ) No (C1-2 ) Yes (C2-2 ) No

No (C2-3 )
Download the latest Confirmation of nj's
Verify ni's firmware ni's firmware version higher Download the latest
firmware for ni verifier by PoW
than nj's firmware version? firmware for ni

Yes (C2-1 )

Download the latest

Verify ni's firmware
firmware for nj

Fig. 2 Overall procedure

Figure 2 shows the overall procedure of the proposed scheme. When an embedded
device, which is a normal node in a blockchain network, starts its firmware update
request by broadcasting a version-check request message, it becomes a request node
in the proposed scheme. Once the version-check request message is broadcasted in the
blockchain network, other normal nodes, i.e., response nodes, and verification nodes
respond to the version-check request message, respectively. Depending on the node
type, the response procedure is different as defined in the following cases:

– C1: Response from a verification node vi to a request node n i

– C2: Response from a response node n j to a request node n i

In C1, a verification node checks whether a request node has the latest version of
the firmware or not. If the request node has the latest version, the verification node
further checks the integrity of the request node’s firmware. Otherwise, the request
node’s firmware is needed to be updated via the firmware sharing network.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1158 B. Lee, J.-H. Lee

In C2, a response node compares its firmware version with the firmware version
of the request node. If the firmware version of the response node is same with that of
the request node, the response node demands other nodes in the blockchain network
to verify its firmware file’s hash value, which is called a verifier that will be explained
later. If the verifier of the response node is confirmed by other nodes that will be done
via a six confirmation, i.e., proof-of-work (PoW), of the blockchain, the response
node believes that its firmware is correct. Then, the response node can check whether
the request node’s firmware has been altered by comparing each other’s verifiers. If
the firmware version of the response node is different with that of the request node,
the response node further checks whether the firmware version of the request node
is higher than its firmware version. If the firmware version of the request node is
higher, the response node’s firmware is needed to be updated via the firmware sharing
network. Otherwise, the request node’s firmware is needed to be updated via the
firmware sharing network.

3.2 Block structure

The proposed scheme uses a different block structure compared with the blockchain
of Bitcoin. The block in the proposed scheme is made up of the block header and
verification field as shown in Fig. 3. The block header is composed of the block size,
version, previous block header hash, and merkle root. The verification field consists of
the verification counter, merkle tree, verification log, model name, firmware version,
and verifier.

Fig. 3 Block structure 0 15 31

Block size (4 bytes)

Block version (4 bytes)

Previous block header hash (32 bytes)

Merkle root (32 bytes)

Verification counter (4 bytes)

Merkle tree (variable)

Verification log (variable)

Model name (4 bytes)

Firmware version (4 bytes)

Verifier (32 bytes)

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1159

Details of the verification field are given below.

• Verification counter This is the number of successful verifications. It is a value
which is only considered in a normal node’s block. It is similar with the block
height in the blockchain of Bitcoin [13]. In a verification node, this value is fixed
at 0.
• Merkle tree It is a tree information for the calculation of the merkle root. It is used
for the verification of block data. It is also used as a feature for managing memory
of node efficiently [6].
• Verification log It is a verification log composed of the verification time (e.g.,
timestamp), request node’s ID, and response node’s ID. If a verification node
responses for the request message, the request node’s ID and verification node’s
ID are stored to this field. To provide integrity and authentication of the verification
log, the digital signature over the verification log is also included at the end of the
log.
• Model name It is a normal node’s model name.
• Firmware version It is a normal node’s current firmware version.
• Verifier It is a hash value of a firmware file. This value is used to verify the firmware
integrity without comparing genuine files. If the firmware file is composed of more
than one file, then those should be concatenated before generating the verifier.

3.3 Procedure

As mentioned, the proposed scheme has the two different operation cases: C1 and C2.
The case C1 is then divided into two sub-cases (C1-1 and C1-2), while the case C2
is also similarly separated into C2-1, C2-2, and C2-3. The cases depends on the type
of response node, which receives the version-check request message sent from the
request node.

3.3.1 C1: response from a verification node vi to a request node n i

When n i transmits a version-check request message to a blockchain network and a

verification node responds to the request, C1 starts. C1 has two different sub-cases.
• C1-1 It starts when n i has the latest firmware.
• C1-2 It starts when n i does not have the latest firmware.
The procedure of C1-1 shown in Fig. 4 is as follows.
1. A request node n i broadcasts a req_verchk message including PU n i , I Dn i , D, v,
and r to a blockchain network. Note that r is used for preventing a replay attack.
2. When a verification node vi receives the message, it obtains the latest firmware
version of n i from its database based on I Dn i , D, and v.
3. vi responds by sending a res_verchk message including vnew , r + 1, and I Dvi that
has been encrypted with PU n i .
4. When n i receives the message, it decrypts the message with P Rn i and checks
r + 1. If v and vnew are equal, i.e., n i has the latest firmware, n i generates its
verifier H ( f v). Otherwise, the process is terminated with an error.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1160 B. Lee, J.-H. Lee

ni vi

1. req_verchk[PUni||IDni||D||v||r]

2. Obtains vnew from its database

3. res_verchk[E(PUni, vnew||r+1||IDvi)]
4. Generates verifier H(fv) after
checking res_verchk message

5. req_verification[E(PUvi, H(fv)||r+2)||Signi]
6. Verifies and decrypts
req_verification message
and prepares to send H(fvnew)

7. res_verification[E(PUni, H(fvnew)||r+3)||Sigvi]
8. Verifies and decrypts
res_verification message,
and compares H(fv) and H(fvnew)

Fig. 4 Procedure of C1-1: n i has the latest firmware

5. n i first encrypts H ( f v) and r + 2 with PU vi and generates a digital signature

Sign i over a req_verification message containing the encrypted H ( f v) and r + 2.
Then, Sign i is attached in the req_verification message, when n i sends the message
to vi .
6. When vi receives the message, it first verifies the message’s integrity and originator
with Sign i and PU n i obtained from the req_verchk message. Then, it decrypts
the message with P Rvi and checks r + 2.
7. vi first encrypts H ( f vnew ) and r + 3 with PU n i and generates a digital signature
Sigvi over a res_verification message containing the encrypted H ( f vnew ) and
r + 3. Then, Sigvi is attached in the res_verification message, when vi sends the
message to n i .
8. When n i receives the message, it first verifies the message’s integrity and originator
with Sigvi and PU vi previously shared. Then, it decrypts the message with P Rn i
and checks r + 3. Now, n i compares H ( f v) and H ( f vnew ) to verify n i ’s firmware
integrity. If the verifiers are equal, the process is successfully finished. Otherwise,
n i needs to download the latest firmware via a peer-to-peer firmware sharing
network similar to C1-2.

The procedure of C1-2 shown in Fig. 5 is as follows.

1. A request node n i broadcasts a req_verchk message including PU n i , I Dn i , D,

v, and r to a blockchain network.
2. When a verification node vi receives the message, it obtains the latest firmware
version of n i from its database based on I Dn i , D, and v.
3. vi responds by sending a res_verchk message including vnew , Mvnew , r + 1, and
I Dvi that has been encrypted with PU n i .
4. When n i receives the message, it decrypts the message with P Rn i and checks
r + 1. n i then obtains H ( f vnew ) from Mvnew .

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1161

ni vi

1. req_verchk[PUni||IDni||D||v||r]

2. Obtains vnew and Mvnew from its database

3. res_verchk[E(PUni, vnew||Mvnew||r+1||IDvi)]
4. Decrypts res_verchk mesasge and
obtains H(fvnew) from Mvnew

5. req_download[E(PUvi, IDni||H(fvnew)||r+2)||vnew||Signi]

6. Verifies and decrypts req_download

message, and checks H(fvnew)

7. res_download[E(PUni, Lvnew||IDvi||r+3)||vnew||Sigvi]

8. Downloads and installs

the latest firmware file
after checking res_download message

Fig. 5 Procedure of C1-2: n i does not have the latest firmware

5. n i first encrypts I Dn i , H ( f vnew ) and r + 2 with PU vi and generates a digi-

tal signature Sign i over a req_download message containing the encrypted data
such as I Dn i , H ( f vnew ), and r + 2, and vnew . Then, Sign i is attached in the
req_download message, when n i sends the message to vi .
6. When vi receives the message, it first verifies the message’s integrity and originator
with Sign i and PU n i obtained from the req_verchk message. Then, it decrypts
the message with P Rvi and checks r + 2. Now, vi prepares Lvnew based on
H ( f vnew ). Note that Lvnew is used by n i to download the latest firmware file
from a peer-to-peer firmware sharing network.
7. vi first encrypts Lvnew , I Dvi , and r +3 with PU n i and generates a digital signature
Sigvi over a res_download message containing the encrypted data such as Lvnew ,
I Dvi , and r + 3, and vnew . Then, Sigvi is attached in the res_download message,
when vi sends the message to n i .
8. When n i receives the message, it first verifies the message’s integrity and originator
with Sigvi and PU vi previously shared. Then, it decrypts the message with P Rn i
and checks r + 3. Now, n i is able to download the latest firmware file f vnew from
the peer-to-peer firmware sharing network and then installs the file.

3.3.2 C2: response from a response node n j to a request node n i

In C2, a response for n i ’s req_verchk message is performed by other normal node n j ,

and as a result of comparison of n i ’s firmware version and n j ’s firmware version, C2
is divided into three different sub-cases.
Contrary to C1, a response node is a normal node so that the legitimacy of a verifier
must be proofed during the firmware update procedure. Note that in C1, the legitimacy
of a verifier is assumed because a verification node maintains the verifier provided from

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1162 B. Lee, J.-H. Lee

the vender node. In C2-2, the legitimacy of a verifier is confirmed via the PoW as like
in the blockchain of Bitcoin [6], whereas the legitimacy of a verifier does not need
to be considered in C2-1 and C2-3 because there is no requirement of checking the
verifier.
– C2-1 It starts when n i ’s firmware version is higher than n j ’s firmware version.
– C2-2 It starts when n i ’s firmware version and n j ’s firmware version are equal.
– C2-3 It starts when n i ’s firmware version is lower than n j ’s firmware version.
The procedure of C2-1 shown in Fig. 6 is as follows.
1. A request node n i broadcasts a req_verchk message including PU n i , I Dn i , D,
v, and r to a blockchain network.
2. When receiving the message, n j compares v obtained from message and v  and
confirms that n i ’s firmware version is higher.
3. n j responds by sending a res_verchk message containing the encrypted data such
as v  , r + 1, and I Dn j . Note that PU n i obtained from the req_verchk message
is used for the encryption.
4. After decrypting the message with P Rn i , n i compares v and v  . Then, it also
confirms that its firmware version is higher than that of n j .
5. n i generates a digital signature Sign i over a notice_download message containing
I Dn i , v  , and r + 2. Then, Sign i is attached in the notice_download message,
when n i sends the message to n j .

ni nj vi

1. req_verchk[PUni||IDni||D||v||r]
2. Compares v and v'

3. res_verchk[E(PUni, v'||r+1||IDnj)]
4. Decrypts res_verchk message
and compares v and v'

5. notice_download[IDni||v'||r+2||Signi]
6. Verifies notice_download
message

7. req_metadata[E(PUvi, IDnj||v'||D||r+3)||PUnj]

8. Obtains Mvnew from its database

9. res_metadata[E(PUnj, Mvnew||r+4)]
10. Decrypts res_metadata message
and obtains H(fvnew) from Mvnew

11. req_download[E(PUvi, IDnj||H(fvnew)||r+5)||Signj]

12. Verifies and decrypts req_download

message, and checks H(fvnew)

13. res_download[E(PUnj, Lvnew||IDvi||r+6)||Sigvi]

14. Downloads and installs

the latest firmware file after
checking res_download message

Fig. 6 Procedure of C2-1: n i ’s firmware version is higher than n j ’s one

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1163

6. When n j receives the notice_download message, it verifies the message’s

integrity and originator with Sign i and PU n i obtained from the req_verchk
message.
7. Now n j requests vi a metadata by sending a req_metadata message. The message
contains the encrypted data such as I Dn j , v  , D, and r + 3, and PU n j .
8. When vi receives the req_metadata message, it decrypts the message. Based on
the obtained data such as I Dn j , v  , and D, vi finds Mvnew for n j .
9. vi now provides Mvnew by sending a res_metadata message to n j . The message
contains the encrypted Mvnew and r + 4 with PU n j .
10. n j acquires H ( f vnew ) from Mvnew after decrypting the res_metadata message
with P Rn j .
11. n j sends a req_download message to request a peer list by sending a
req_download message. For sending the message, it first encrypts I Dn j ,
H ( f vnew ), and r + 5 with PU vi and generates a digital signature Sign j over
the req_download message containing the encrypted data. Sign j is attached in
the req_download message, when n j sends the message to vi .
12. When vi receives the message, it first verifies the message’s integrity and origi-
nator with Sign j and PU n j obtained from the req_metadata message. Then, it
decrypts the message with P Rvi and checks r +5. Now, vi prepares Lvnew based
on H ( f vnew ). Note that Lvnew is used by n j to download the latest firmware file
from a peer-to-peer firmware sharing network.
13. vi first encrypts Lvnew , I Dvi , and r + 6 with PU n j and generates a digital
signature Sigvi over a res_download message containing the encrypted data.
Then, Sigvi is attached in the res_download message, when vi sends the message
to n j .
14. When n j receives the message, it first verifies the message’s integrity and orig-
inator with Sigvi and PU vi previously shared. Then, it decrypts the message
with P Rn j and checks r + 6. Now, n j is able to download the latest firmware
file f vnew from the peer-to-peer firmware sharing network and then installs the
file.

The procedure of C2-2 shown in Fig. 7 is as follows.

1. A request node n i broadcasts a req_verchk message including PU n i , I Dn i , D,

v, and r to a blockchain network.
2. When a response node n j receives the message, it compares v and v  . If v and v 
are equal, n j generates its verifier H ( f v  ).
3. n j broadcasts a join_verification message including I Dn i , I Dn j , D, and H ( f v  )
to a blockchain network for asking other nodes to join the verification process,
and other nodes perform the PoW stage. After completing the PoW, they add
I Dn i as request node’s ID, I Dn j as response node’s ID, ts into the verification
log and then broadcast the verification log into the blockchain network.
4. If n j receives the verification log from more than six other nodes, n j responds
by sending a res_verchk message including v  , r + 1, I Dn j , and PU n j that has
been encrypted with PU n i .

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1164 B. Lee, J.-H. Lee

ni nj

1. req_verchk[PUni||IDni||D||v||r]
2. Generates verifier H(fv')
after comparing v and v'
3. join_verification[IDni||IDnj||D||H(fv')] blockchain network
4. res_verchk[E(PUni, v'||r+1||IDnj)||PUnj]
5. Generates verifier H(fv) after
checking res_verchk message

6. req_verification[E(PUnj, H(fv)||r+2)||Signi]
7. Verifies and decrypts
req_verification message
and prepares to send H(fv')
8. res_verification[E(PUni, H(fv')||r+3)||Signj]
9. Verifies and decrypts
res_verification message,
and compares H(fv) and H(fv')

Fig. 7 Procedure of C2-2: n i ’s firmware version is equal with n j ’s one

5. When n i receives the message, it decrypts the message with P Rn i and check
r + 1. If v and v  are equal, n i generates verifier H ( f v). Otherwise, the process
is terminated with an error.
6. n i first encrypts H ( f v) and r + 2 with PU n j and generates a digital signature
Sign i over a req_verification message containing the encrypted H ( f v) and r +
2. Then, Sign i is attached in the req_verification message, when n i sends the
message to n j .
7. When n j receives the message, it first verifies the message’s integrity and orig-
inator with Sign i and PU n j obtained from the res_verchk message. Then, it
decrypts the message with P Rn j and checks r + 2. As a result of checking the
value, n j prepares to send H ( f v  ). Otherwise, the process is terminated with an
error.
8. n j first encrypts H ( f v  ) and r + 3 with PU n i and generates a digital signature
Sign j over a res_verification message containing the encrypted H ( f v  ) and r +
3. Then, Sign j is attached in the res_verification message, when n j sends the
message to n i .
9. When n i receives the message, it first verifies the message’s integrity and origina-
tor with Sign j and PU n j previously shared. Then, it decrypts the message with
P Rn j and checks r + 3. Now, n i compares H ( f v) and H ( f v  ) to verify n i ’s
firmware integrity. If the verifiers are equal, the process is successfully finished.
Otherwise, n i needs to download the latest firmware via a peer-to-peer firmware
sharing network similar to C2-1 or C2-3.

The procedure of C2-3 shown in Fig. 8 is as follows.

1. A request node n i broadcasts a req_verchk message including PU n i , I Dn i , D,

v, and r to a blockchain network.
2. When receiving the message, n j compares v obtained from message and v  and
confirms that n j ’s firmware version is higher.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1165

vi ni nj

1. req_verchk[PUni||IDni||D||v||r]
2. Compares v and v'

3. res_verchk[E(PUni, v'||r+1||IDnj)]
4. Decrypts res_verchk message
and compares v and v'

5. req_metadata[E(PUvi, IDni||v||D||r+2)||PUni]

6. Obtains Mvnew from its database

7. res_metadata[E(PUni, Mvnew||r+3)]

8. Decrypts res_metadata message

and obtains H(fvnew) from Mvnew

9. req_download[E(PUvi, IDni||H(fvnew)||r+4)||Signi]
10. Verifies and decrypts req_download
message, and checks H(fvnew)

11. res_download[E(PUni, Lvnew||IDvi||r+5)||Sigvi]

12. Downloads and installs
the latest firmware file after
checking res_download message

Fig. 8 Procedure of C2-3: n i ’s firmware version is lower than n j ’s one

3. n j responds by sending a res_verchk message containing the encrypted data

such as v  , r + 1, and I Dn j . Note that PU n i obtained from the req_verchk
message is used for the encryption.
4. After decrypting the message with P Rn i , n i compares v and v  . Then, it also
confirms that its firmware version is lower than that of n j .
5. Now n i requests vi a metadata by sending a req_metadata message. The message
contains the encrypted data such as I Dn i , v, D, and r + 2, and PU n i .
6. When vi receives the req_metadata message, it decrypts the message. Based on
the obtained data such as I Dn i , v, and D, vi finds Mvnew for n i .
7. vi now provides Mvnew by sending a res_metadata message to n i . The message
contains the encrypted Mvnew and r + 3 with PU n i .
8. n i acquires H ( f vnew ) from Mvnew after decrypting the res_metadata message
with P Rn i .
9. n i sends a req_download message to request a peer list by sending a
req_download message. For sending the message, it first encrypts I Dn i ,
H ( f vnew ), and r + 4 with PU vi and generates a digital signature Sign i over
the req_download message containing the encrypted data. Sign i is attached in
the req_download message, when n i sends the message to vi .
10. When vi receives the message, it first verifies the message’s integrity and origi-
nator with Sign i and PU n i obtained from the req_metadata message. Then, it
decrypts the message with P Rvi and checks r +4. Now, vi prepares Lvnew based
on H ( f vnew ). Note that Lvnew is used by n i to download the latest firmware
file from a peer-to-peer firmware sharing network.

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 1166 B. Lee, J.-H. Lee

11. vi first encrypts Lvnew , I Dvi , and r + 5 with PU n i and generates a digital
signature Sigvi over a res_download message containing the encrypted data.
Then, Sigvi is attached in the res_download message, when vi sends the message
to n i .
12. When n i receives the message, it first verifies the message’s integrity and orig-
inator with Sigvi and PU vi previously shared. Then, it decrypts the message
with P Rn i and checks r + 5. Now, n i is able to download the latest firmware file
f vnew from the peer-to-peer firmware sharing network and then installs the file.
After the end of firmware verification, the request node makes its verification log
including request node’s ID, response node’s ID, timestamp, etc. The request node
then broadcasts it to the blockchain network. Consequentially, it enables to validate
the firmware integrity and decide whether the update firmware on the device requires
or not without a user’s control.

4 Discussion

The proposed scheme focuses on minimizing the attack window time by enabling
an embedded device can quickly check its firmware version and download the latest
firmware if needed. It thus helps to shorten effects of attacks targeting known firmware
vulnerabilities on the embedded device. As this scheme has been developed for the
IoT environment, all the procedures such as firmware validation and download to
update are based on distributed models. In other words, a blockchain technology has
been adopted for secure firmware version check and validation, while BitTorrent has
been used for a peer-to-peer firmware sharing network for downloading the latest
firmware. However, a verification node acts as a tracker in the peer-to-peer firmware
sharing network. The verification node is thus considered as a server assisting in
the communication between peers for firmware downloading. The proposed scheme
can be improved by adopting distributed hash tables, i.e., implementing a trackerless
BitTorrent system.
In the proposed scheme, a verification node’s public key is assumed to be pre-
shared to all normal nodes. As the number of the verification nodes increases, the key
distribution and management cost increases. However, in practice, the number of the
verification nodes would not be many.
The proposed scheme enables that an embedded device keeps its firmware up-to-
date while providing its integrity, i.e., correctness of firmware. However, it does not
mean that the provided firmware is not buggy nor vulnerable, e.g., stack overflow
[14]. In addition, the proposed scheme does not guarantee that involved nodes work
correctly. We have assumed that all nodes work as defined in the proposed scheme.
However, in practice, some nodes can be compromised by an attack’s physical access
and firmware modification attack.
In the proposed scheme, a request node starts its firmware update request by sending
the version-check request message, which is a broadcast message. Then, depending
on the node type receives the broadcast message, the proposed scheme has 2 different
operation cases such as C1 and C2. However, due to the nature of the broadcast
message, the proposed scheme may cause unnecessary network traffic and nodes’

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
 Blockchain-based secure firmware update for embedded devices. . . 1167

operations. For instance, even if the firmware verification is done by a verification

node (i.e., via C1-1), a response node may perform the confirmation of its verifier
through the PoW (i.e., via C2-2) that consumes network traffic and other normal
nodes’ computational power.
The proposed scheme’s security relies on the Blockchain technology and some
basic properties of asymmetric cryptography like message signature and encryption.
However, the proposed scheme’s security has been not formally verified in this paper
that can be done for instance through the BAN logic and Scyther tool [15].

5 Conclusion

In this paper, we presented a new firmware update scheme that securely checks a
firmware version, validates the correctness of firmware, and enables downloading
of the latest firmware for embedded devices in an IoT environment. The proposed
scheme relies on a blockchain technology for firmware checking and validation, while
BitTorrent can be used to implement a peer-to-peer firmware sharing network for
firmware downloading.
The architecture and detailed operation procedures of the proposed scheme have
been illustrated. In addition, we have discussed the proposed scheme’s strengths and
weaknesses. As mentioned, there are some considerations and limitations of the current
scheme so that we will improve the proposed scheme to eliminate the found limitations
and improve security and scalability.

References
1. Gartner (2014) Gartner says 4.9 billion connected things will be in use in 2015, Gartner Newsroom
2. Firmware—Wikipedia. https://en.wikipedia.org/wiki/Firmware
3. Choi B-C, Lee S-H, Na J-C, Lee J-H (2016) Secure firmware validation and update for consumer
devices in home networking. IEEE Trans Consum Electron 62(1):39–44
4. Lee B, Malik S, Wi S, Lee J-H (2016) Firmware verification of embedded devices based on a blockchain.
In: Proceedings of the Qshine 2016
5. Jurkovi G, Sruk V (May 2014) Remote firmware update for constrained embedded systems. In: Pro-
ceedings of the MIPRO 2014
6. Nakamoto S (2009) Bitcoin: a peer-to-peer electronic cash system
7. Blockchain Bitcoin Wiki. https://en.bitcoin.it/wiki/Block_chain
8. Hu Y, Perrig A, Johnson DB (2003) Efficient security mechanisms for routing protocols. In: Proc.
NDSS03
9. Badev A, Chen M (2013) Bitcoin: technical background and data analysis. Federal Reserve Board
10. Bider D, Baushke M (2012) SHA-2 data integrity for the secure shell (SSH) transport layer protocol.
IETF RFC 6668
11. Cohen B (2003) Incentives build robustness in bitorrent. In: Proceedings of the 1st Workshop on
Economics of Peer-to-Peer Systems
12. Wiki Theory—Bittorrent Protocol Specification v1.0. https://wiki.theory.org/BitTorrentSpecification
13. Antonopoulos, Andreas M (2014) Mastering Bitcoin: unlocking digital crypto-currencies. OReilly
Media
14. Alouneh S, Bsoul H, Kharbutli M (2016) A software tool to protect executable files from buffer overflow
attacks. Int J Internet Technol Secur Trans 6(2):133–166
15. Ahamad S, Al-Shourbaji I, Al-Janabi S (2016) A secure NFC mobile payment protocol based on
biometrics with formal verification. Int J Internet Technol Secur Trans 6(2):103–132

123
Content courtesy of Springer Nature, terms of use apply. Rights reserved.
Terms and Conditions
Springer Nature journal content, brought to you courtesy of Springer Nature Customer Service Center
GmbH (“Springer Nature”).
Springer Nature supports a reasonable amount of sharing of research papers by authors, subscribers
and authorised users (“Users”), for small-scale personal, non-commercial use provided that all
copyright, trade and service marks and other proprietary notices are maintained. By accessing,
sharing, receiving or otherwise using the Springer Nature journal content you agree to these terms of
use (“Terms”). For these purposes, Springer Nature considers academic use (by researchers and
students) to be non-commercial.
These Terms are supplementary and will apply in addition to any applicable website terms and
conditions, a relevant site licence or a personal subscription. These Terms will prevail over any
conflict or ambiguity with regards to the relevant terms, a site licence or a personal subscription (to
the extent of the conflict or ambiguity only). For Creative Commons-licensed articles, the terms of
the Creative Commons license used will apply.
We collect and use personal data to provide access to the Springer Nature journal content. We may
also use these personal data internally within ResearchGate and Springer Nature and as agreed share
it, in an anonymised way, for purposes of tracking, analysis and reporting. We will not otherwise
disclose your personal data outside the ResearchGate or the Springer Nature group of companies
unless we have your permission as detailed in the Privacy Policy.
While Users may use the Springer Nature journal content for small scale, personal non-commercial
use, it is important to note that Users may not:

1. use such content for the purpose of providing other users with access on a regular or large scale
basis or as a means to circumvent access control;
2. use such content where to do so would be considered a criminal or statutory offence in any
jurisdiction, or gives rise to civil liability, or is otherwise unlawful;
3. falsely or misleadingly imply or suggest endorsement, approval , sponsorship, or association
unless explicitly agreed to by Springer Nature in writing;
4. use bots or other automated methods to access the content or redirect messages
5. override any security feature or exclusionary protocol; or
6. share the content in order to create substitute for Springer Nature products or services or a
systematic database of Springer Nature journal content.
In line with the restriction against commercial use, Springer Nature does not permit the creation of a
product or service that creates revenue, royalties, rent or income from our content or its inclusion as
part of a paid for service or for other commercial gain. Springer Nature journal content cannot be
used for inter-library loans and librarians may not upload Springer Nature journal content on a large
scale into their, or any other, institutional repository.
These terms of use are reviewed regularly and may be amended at any time. Springer Nature is not
obligated to publish any information or content on this website and may remove it or features or
functionality at our sole discretion, at any time with or without notice. Springer Nature may revoke
this licence to you at any time and remove access to any copies of the Springer Nature journal content
which have been saved.
To the fullest extent permitted by law, Springer Nature makes no warranties, representations or
guarantees to Users, either express or implied with respect to the Springer nature journal content and
all parties disclaim and waive any implied warranties or warranties imposed by law, including
merchantability or fitness for any particular purpose.
Please note that these rights do not automatically extend to content, data or other material published
by Springer Nature that may be licensed from third parties.
If you would like to use or distribute our Springer Nature journal content to a wider audience or on a
regular basis or in any other manner not expressly permitted by these Terms, please contact Springer
Nature at

onlineservice@springernature.com