Advertisement

The Journal of Supercomputing

, Volume 73, Issue 3, pp 1152–1167 | Cite as

Blockchain-based secure firmware update for embedded devices in an Internet of Things environment

  • Boohyung Lee
  • Jong-Hyouk LeeEmail author
Article

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 

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 limited 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. 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 authentication 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 repository, 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 embedded device adopts the client–server model that means excessive network traffic may occur when requesting the firmware update files from embedded devices simultaneously. 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 authenticity 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 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 latest 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.
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}\)

\(v_{new}\)

Latest firmware version of \(n_{i}\)

\(v'\)

Current firmware version of \(n_{j}\)

fv

Current firmware file of v

\(fv'\)

Current firmware file of \(v'\)

\(fv_{new}\)

Latest firmware file of \(v_{new}\)

H(fv)

Verifier generated with fv

\(H(fv')\)

Verifier generated with \(fv'\)

\(H(fv_{new})\)

Verifier generated with \(fv_{new}\)

\(Lv_{new}\)

Peer list shared with \(fv_{new}\)

\(Mv_{new}\)

Metadata file of \(fv_{new}\)

\(IDn_{i}\)

Identifier of \(n_{i}\)

\(IDv_{i}\)

Identifier of \(v_{i}\)

E

Elliptic curve

P

Base point of elliptic curve E

\(PUn_{i}\)

Public key of \(n_{i}\)

\(PRn_{i}\)

Private key of \(n_{i}\)

\(PUv_{i}\)

Public key of \(v_{i}\)

\(PRv_{i}\)

Private key of \(v_{i}\)

\(Sign_{i}\)

Signature of \(n_{i}\)

\(Sigv_{i}\)

Signature of \(v_{i}\)

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=\{ b_{1}, b_{2},\ldots , b_{n}\}\) and \(b_{i} \in 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},\ldots , n_{n}\}\), \(n_{i} \in N\), and \(N \subset 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 information 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=\{ v_{1}, v_{2},\ldots , v_{n}\}, v_{i} \in V\), and \(V \subset B\). A verification node’s public key is available to all nodes in the blockchain network.

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

Fig. 1

Overall architecture

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.
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 \(v_{i}\) 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.

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

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 \(v_{i}\) 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. 1.

    A request node \(n_{i}\) broadcasts a req_verchk message including \(PUn_{i}\), \(IDn_{i}\), D, v, and r to a blockchain network. Note that r is used for preventing a replay attack.

     
  2. 2.

    When a verification node \(v_{i}\) receives the message, it obtains the latest firmware version of \(n_{i}\) from its database based on \(IDn_{i}\), D, and v.

     
  3. 3.

    \(v_{i}\) responds by sending a res_verchk message including \(v_{new}\), \(r+1\), and \(IDv_{i}\) that has been encrypted with \(PUn_{i}\).

     
  4. 4.

    When \(n_{i}\) receives the message, it decrypts the message with \(PRn_{i}\) and checks \(r+1\). If v and \(v_{new}\) are equal, i.e., \(n_{i}\) has the latest firmware, \(n_{i}\) generates its verifier H(fv). Otherwise, the process is terminated with an error.

     
  5. 5.

    \(n_{i}\) first encrypts H(fv) and \(r+2\) with \(PUv_{i}\) and generates a digital signature \(Sign_{i}\) over a req_verification message containing the encrypted H(fv) and \(r+2\). Then, \(Sign_{i}\) is attached in the req_verification message, when \(n_{i}\) sends the message to \(v_{i}\).

     
  6. 6.

    When \(v_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sign_{i}\) and \(PUn_{i}\) obtained from the req_verchk message. Then, it decrypts the message with \(PRv_{i}\) and checks \(r+2\).

     
  7. 7.

    \(v_{i}\) first encrypts \(H(fv_{new})\) and \(r+3\) with \(PUn_{i}\) and generates a digital signature \(Sigv_{i}\) over a res_verification message containing the encrypted \(H(fv_{new})\) and \(r+3\). Then, \(Sigv_{i}\) is attached in the res_verification message, when \(v_{i}\) sends the message to \(n_{i}\).

     
  8. 8.

    When \(n_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sigv_{i}\) and \(PUv_{i}\) previously shared. Then, it decrypts the message with \(PRn_{i}\) and checks \(r+3\). Now, \(n_{i}\) compares H(fv) and \(H(fv_{new})\) 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.

     
Fig. 4

Procedure of C1-1: \(n_{i}\) has the latest firmware

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

    A request node \(n_{i}\) broadcasts a req_verchk message including \(PUn_{i}\), \(IDn_{i}\), D, v, and r to a blockchain network.

     
  2. 2.

    When a verification node \(v_{i}\) receives the message, it obtains the latest firmware version of \(n_{i}\) from its database based on \(IDn_{i}\), D, and v.

     
  3. 3.

    \(v_{i}\) responds by sending a res_verchk message including \(v_{new}\), \(Mv_{new}\), \(r+1\), and \(IDv_{i}\) that has been encrypted with \(PUn_{i}\).

     
  4. 4.

    When \(n_{i}\) receives the message, it decrypts the message with \(PRn_{i}\) and checks \(r+1\). \(n_{i}\) then obtains \(H(fv_{new})\) from \(Mv_{new}\).

     
  5. 5.

    \(n_{i}\) first encrypts \(IDn_{i}\), \(H(fv_{new})\) and \(r+2\) with \(PUv_{i}\) and generates a digital signature \(Sign_{i}\) over a req_download message containing the encrypted data such as \(IDn_{i}\), \(H(fv_{new})\), and \(r+2\), and \(v_{new}\). Then, \(Sign_{i}\) is attached in the req_download message, when \(n_{i}\) sends the message to \(v_{i}\).

     
  6. 6.

    When \(v_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sign_{i}\) and \(PUn_{i}\) obtained from the req_verchk message. Then, it decrypts the message with \(PRv_{i}\) and checks \(r+2\). Now, \(v_{i}\) prepares \(Lv_{new}\) based on \(H(fv_{new})\). Note that \(Lv_{new}\) is used by \(n_{i}\) to download the latest firmware file from a peer-to-peer firmware sharing network.

     
  7. 7.

    \(v_{i}\) first encrypts \(Lv_{new}\), \(IDv_{i}\), and \(r+3\) with \(PUn_{i}\) and generates a digital signature \(Sigv_{i}\) over a res_download message containing the encrypted data such as \(Lv_{new}\), \(IDv_{i}\), and \(r+3\), and \(v_{new}\). Then, \(Sigv_{i}\) is attached in the res_download message, when \(v_{i}\) sends the message to \(n_{i}\).

     
  8. 8.

    When \(n_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sigv_{i}\) and \(PUv_{i}\) previously shared. Then, it decrypts the message with \(PRn_{i}\) and checks \(r+3\). Now, \(n_{i}\) is able to download the latest firmware file \(fv_{new}\) from the peer-to-peer firmware sharing network and then installs the file.

     
Fig. 5

Procedure of C1-2: \(n_{i}\) does not have the latest firmware

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 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.
Fig. 6

Procedure of C2-1: \(n_{i}\)’s firmware version is higher than \(n_{j}\)’s one

  1. 1.

    A request node \(n_{i}\) broadcasts a req_verchk message including \(PUn_{i}\), \(IDn_{i}\), D, v, and r to a blockchain network.

     
  2. 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. 3.

    \(n_{j}\) responds by sending a res_verchk message containing the encrypted data such as \(v'\), \(r+1\), and \(IDn_{j}\). Note that \(PUn_{i}\) obtained from the req_verchk message is used for the encryption.

     
  4. 4.

    After decrypting the message with \(PRn_{i}\), \(n_{i}\) compares v and \(v'\). Then, it also confirms that its firmware version is higher than that of \(n_{j}\).

     
  5. 5.

    \(n_{i}\) generates a digital signature \(Sign_{i}\) over a notice_download message containing \(IDn_{i}\), \(v'\), and \(r+2\). Then, \(Sign_{i}\) is attached in the notice_download message, when \(n_{i}\) sends the message to \(n_{j}\).

     
  6. 6.

    When \(n_{j}\) receives the notice_download message, it verifies the message’s integrity and originator with \(Sign_{i}\) and \(PUn_{i}\) obtained from the req_verchk message.

     
  7. 7.

    Now \(n_{j}\) requests \(v_{i}\) a metadata by sending a req_metadata message. The message contains the encrypted data such as \(IDn_{j}\), \(v'\), D, and \(r+3\), and \(PUn_{j}\).

     
  8. 8.

    When \(v_{i}\) receives the req_metadata message, it decrypts the message. Based on the obtained data such as \(IDn_{j}\), \(v'\), and D, \(v_{i}\) finds \(Mv_{new}\) for \(n_{j}\).

     
  9. 9.

    \(v_{i}\) now provides \(Mv_{new}\) by sending a res_metadata message to \(n_{j}\). The message contains the encrypted \(Mv_{new}\) and \(r+4\) with \(PUn_{j}\).

     
  10. 10.

    \(n_{j}\) acquires \(H(fv_{new})\) from \(Mv_{new}\) after decrypting the res_metadata message with \(PRn_{j}\).

     
  11. 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 \(IDn_{j}\), \(H(fv_{new})\), and \(r+5\) with \(PUv_{i}\) 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 \(v_{i}\).

     
  12. 12.

    When \(v_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sign_{j}\) and \(PUn_{j}\) obtained from the req_metadata message. Then, it decrypts the message with \(PRv_{i}\) and checks \(r+5\). Now, \(v_{i}\) prepares \(Lv_{new}\) based on \(H(fv_{new})\). Note that \(Lv_{new}\) is used by \(n_{j}\) to download the latest firmware file from a peer-to-peer firmware sharing network.

     
  13. 13.

    \(v_{i}\) first encrypts \(Lv_{new}\), \(IDv_{i}\), and \(r+6\) with \(PUn_{j}\) and generates a digital signature \(Sigv_{i}\) over a res_download message containing the encrypted data. Then, \(Sigv_{i}\) is attached in the res_download message, when \(v_{i}\) sends the message to \(n_{j}\).

     
  14. 14.

    When \(n_{j}\) receives the message, it first verifies the message’s integrity and originator with \(Sigv_{i}\) and \(PUv_{i}\) previously shared. Then, it decrypts the message with \(PRn_{j}\) and checks \(r+6\). Now, \(n_{j}\) is able to download the latest firmware file \(fv_{new}\) 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.
Fig. 7

Procedure of C2-2: \(n_{i}\)’s firmware version is equal with \(n_{j}\)’s one

  1. 1.

    A request node \(n_{i}\) broadcasts a req_verchk message including \(PUn_{i}\), \(IDn_{i}\), D, v, and r to a blockchain network.

     
  2. 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(fv')\).

     
  3. 3.

    \(n_{j}\) broadcasts a join_verification message including \(IDn_{i}\), \(IDn_{j}\), D, and \(H(fv')\) 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 \(IDn_{i}\) as request node’s ID, \(IDn_{j}\) as response node’s ID, ts into the verification log and then broadcast the verification log into the blockchain network.

     
  4. 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\), \(IDn_{j}\), and \(PUn_{j}\) that has been encrypted with \(PUn_{i}\).

     
  5. 5.

    When \(n_{i}\) receives the message, it decrypts the message with \(PRn_{i}\) and check \(r+1\). If v and \(v'\) are equal, \(n_{i}\) generates verifier H(fv). Otherwise, the process is terminated with an error.

     
  6. 6.

    \(n_{i}\) first encrypts H(fv) and \(r+2\) with \(PUn_{j}\) and generates a digital signature \(Sign_{i}\) over a req_verification message containing the encrypted H(fv) and \(r+2\). Then, \(Sign_{i}\) is attached in the req_verification message, when \(n_{i}\) sends the message to \(n_{j}\).

     
  7. 7.

    When \(n_{j}\) receives the message, it first verifies the message’s integrity and originator with \(Sign_{i}\) and \(PUn_{j}\) obtained from the res_verchk message. Then, it decrypts the message with \(PRn_{j}\) and checks \(r+2\). As a result of checking the value, \(n_{j}\) prepares to send \(H(fv')\). Otherwise, the process is terminated with an error.

     
  8. 8.

    \(n_{j}\) first encrypts \(H(fv')\) and \(r+3\) with \(PUn_{i}\) and generates a digital signature \(Sign_{j}\) over a res_verification message containing the encrypted \(H(fv')\) and \(r+3\). Then, \(Sign_{j}\) is attached in the res_verification message, when \(n_{j}\) sends the message to \(n_{i}\).

     
  9. 9.

    When \(n_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sign_{j}\) and \(PUn_{j}\) previously shared. Then, it decrypts the message with \(PRn_{j}\) and checks \(r+3\). Now, \(n_{i}\) compares H(fv) and \(H(fv')\) 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.
Fig. 8

Procedure of C2-3: \(n_{i}\)’s firmware version is lower than \(n_{j}\)’s one

  1. 1.

    A request node \(n_{i}\) broadcasts a req_verchk message including \(PUn_{i}\), \(IDn_{i}\), D, v, and r to a blockchain network.

     
  2. 2.

    When receiving the message, \(n_{j}\) compares v obtained from message and \(v'\) and confirms that \(n_{j}\)’s firmware version is higher.

     
  3. 3.

    \(n_{j}\) responds by sending a res_verchk message containing the encrypted data such as \(v'\), \(r+1\), and \(IDn_{j}\). Note that \(PUn_{i}\) obtained from the req_verchk message is used for the encryption.

     
  4. 4.

    After decrypting the message with \(PRn_{i}\), \(n_{i}\) compares v and \(v'\). Then, it also confirms that its firmware version is lower than that of \(n_{j}\).

     
  5. 5.

    Now \(n_{i}\) requests \(v_{i}\) a metadata by sending a req_metadata message. The message contains the encrypted data such as \(IDn_{i}\), v, D, and \(r+2\), and \(PUn_{i}\).

     
  6. 6.

    When \(v_{i}\) receives the req_metadata message, it decrypts the message. Based on the obtained data such as \(IDn_{i}\), v, and D, \(v_{i}\) finds \(Mv_{new}\) for \(n_{i}\).

     
  7. 7.

    \(v_{i}\) now provides \(Mv_{new}\) by sending a res_metadata message to \(n_{i}\). The message contains the encrypted \(Mv_{new}\) and \(r+3\) with \(PUn_{i}\).

     
  8. 8.

    \(n_{i}\) acquires \(H(fv_{new})\) from \(Mv_{new}\) after decrypting the res_metadata message with \(PRn_{i}\).

     
  9. 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 \(IDn_{i}\), \(H(fv_{new})\), and \(r+4\) with \(PUv_{i}\) 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 \(v_{i}\).

     
  10. 10.

    When \(v_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sign_{i}\) and \(PUn_{i}\) obtained from the req_metadata message. Then, it decrypts the message with \(PRv_{i}\) and checks \(r+4\). Now, \(v_{i}\) prepares \(Lv_{new}\) based on \(H(fv_{new})\). Note that \(Lv_{new}\) is used by \(n_{i}\) to download the latest firmware file from a peer-to-peer firmware sharing network.

     
  11. 11.

    \(v_{i}\) first encrypts \(Lv_{new}\), \(IDv_{i}\), and \(r+5\) with \(PUn_{i}\) and generates a digital signature \(Sigv_{i}\) over a res_download message containing the encrypted data. Then, \(Sigv_{i}\) is attached in the res_download message, when \(v_{i}\) sends the message to \(n_{i}\).

     
  12. 12.

    When \(n_{i}\) receives the message, it first verifies the message’s integrity and originator with \(Sigv_{i}\) and \(PUv_{i}\) previously shared. Then, it decrypts the message with \(PRn_{i}\) and checks \(r+5\). Now, \(n_{i}\) is able to download the latest firmware file \(fv_{new}\) 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’ 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. 1.
    Gartner (2014) Gartner says 4.9 billion connected things will be in use in 2015, Gartner NewsroomGoogle Scholar
  2. 2.
  3. 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–44CrossRefGoogle Scholar
  4. 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 2016Google Scholar
  5. 5.
    Jurkovi G, Sruk V (May 2014) Remote firmware update for constrained embedded systems. In: Proceedings of the MIPRO 2014Google Scholar
  6. 6.
    Nakamoto S (2009) Bitcoin: a peer-to-peer electronic cash systemGoogle Scholar
  7. 7.
    Blockchain Bitcoin Wiki. https://en.bitcoin.it/wiki/Block_chain
  8. 8.
    Hu Y, Perrig A, Johnson DB (2003) Efficient security mechanisms for routing protocols. In: Proc. NDSS03Google Scholar
  9. 9.
    Badev A, Chen M (2013) Bitcoin: technical background and data analysis. Federal Reserve BoardGoogle Scholar
  10. 10.
    Bider D, Baushke M (2012) SHA-2 data integrity for the secure shell (SSH) transport layer protocol. IETF RFC 6668Google Scholar
  11. 11.
    Cohen B (2003) Incentives build robustness in bitorrent. In: Proceedings of the 1st Workshop on Economics of Peer-to-Peer SystemsGoogle Scholar
  12. 12.
    Wiki Theory—Bittorrent Protocol Specification v1.0. https://wiki.theory.org/BitTorrentSpecification
  13. 13.
    Antonopoulos, Andreas M (2014) Mastering Bitcoin: unlocking digital crypto-currencies. OReilly MediaGoogle Scholar
  14. 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–166CrossRefGoogle Scholar
  15. 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–132CrossRefGoogle Scholar

Copyright information

© Springer Science+Business Media New York 2016

Authors and Affiliations

  1. 1.Protocol Engineering Lab.Sangmyung UniversityCheonanRepublic of Korea

Personalised recommendations