BCmECC: A Lightweight Blockchain-Based Authentication and Key Agreement Protocol for Internet of Things

Abstract

In this paper, targeting efficient authentication and key agreement in an IoT environment, we propose an Elliptic Curve Cryptography-(ECC) based lightweight authentication protocol called BCmECC which relies on a public blockchain to validate the users’ public key to provide desired security. We evaluate the security of the proposed protocol heuristically and validate it formally, which demonstratse the high level of the security. For the formal verification we used the widely accepted formal methods, i.e., BAN logic and the Scyther tool. In this paper we also analyse the security of recently proposed blockchain-based authentication protocols and show that this protocol does not provide the desired security against known session-specific temporary information attacks in which the adversary has access to the session’s ephemeral values and aims to retrieve the shared session key. In addition, the protocol lacks forward secrecy, in which an adversary with access to the server’s long-term secret key can retrieve the previous session keys, assuming that the adversary has already eavesdropped the transferred messages over a public channel in the target session. The proposed attacks are very efficient and their success probability is ‘1’, while the time complexity of each attack could be negligible. Besides, we show that BCmECC is secure against such attacks.

1. Introduction

The Internet of Things (IoT) will have an impact on every element of human life very soon. The existing networks and devices such as cellphones, laptop computers, cloud servers, and so on which have surrounded people in the twenty-first century could just be a part of IoT. There are many devices with the capability to connect this network already, including all smart home appliances. On the other hand, organized criminal gangs exist wherever there is a profit to be made from counterfeiting or pirate operations, usually by circumventing security barriers. Despite ongoing efforts to monitor this risk, the share of trade in counterfeit and pirated goods is steadily increasing, and fake or fraudulent products can be found in an increasing number of industries, including pharmaceuticals, food and beverage, and medical equipment, posing serious health and safety risks [1,2,3,4,5]. To counteract the increased threat of counterfeit products and drugs, government authorities such as the US Food and Drug Adminstration(FDA) and organizations (such as pharmaceutical suppliers) are looking into enforcement options, one of which is IoT solutions, which may assist with maintaining a secure supply chain, according to [6].

Although IoT provides many advantages, it also raises many concerns including unauthorized access and control of those devices for adversarial purposes. To address this concern, authentication and access control protocols could be an off-the-shelf solution. However, IoT is a heterogeneous network in which objects with varying capabilities and resources should connect to share information. Hence, the available off-the-shelf solution, authentication protocols, which are used in SSL, for instance, may not be appropriate for this network. As a result, throughout the previous decade, several customized protocols have been designed, analyzed, and broken [1,7,8,9,10,11].

Due to the limited resources of many items in an IoT network, they should rely on external resources for calculations and the storing of sensitive data, such as a trusted authority (TA). Apart from security concerns, such a centralized architecture of traditional protocols could be a bottleneck in the mass IoT network, causing service providers to be unable to adequately respond to system requirements like authentication, authorization, and access management as the number of devices and users grows. To address this concern, decentralized solutions could be a proper solution. Among different approaches, blockchain-based approaches could provide public trust in the network’s security. More precisely, the blockchain may be used to securely store information such as certificates or system parameters which can subsequently be accessed by IoT devices or servers to aid with authentication. A smart contract can also be utilized to establish the link between important data and to conduct revocation when necessary. As a result, the blockchain network enables verifiable, immutable, and undeniable data storage in the form of so-called transactions that comprise a blockchain [12]. Hence, several security and privacy solutions for IoT networks have been presented in this framework, e.g., [13,14,15,16,17,18,19,20,21,22]. An interesting study on the fusion of blockchain and the Internet of Things ( BIoT) has been provided in [21], where the authors identified nine categories in the intellectual core of BIoT, including data privacy and security for BIoT systems, system security theories for BIoT, and applied security strategies for using blockchain with the IoT. Another study, in which a unification of BIoT is provided, has been conducted by Bhushan et al.  [22], where they introduced requirements, a working model, challenges, and future directions of BIoT. While those studies are more concentrated on identifying the challenges, some other studieshave introduced concrete solutions in the field of BIoT. Among them, to accomplish an effective authentication procedure, recently Yang et al. [19] suggested a novel blockchain-based authentication system that combines the blockchain approach with the modular square root algorithm. The suggested protocol has some intriguing characteristics and is backed up by provable security, assuming that the adversary only has access to the messages sent via the public channel. On the other hand, any security protocol should be extensively analysed by the third parties prior to relaying the security of a real application on it [23]. In addition, the security of Yang et al.’s protocol in the face of a more powerful attacker, who may compromise long-term secret parameters or impact primitives’ functionality, such as random generators, is currently unexplained. It motivated us to shed light on those parts of the protocol in order to dig deeper into its security.

1.1. Our Contribution

The paper’s contribution is divided into two parts, as follows:

• We assess the security of Yang et al.’s recently proposed blockchain-based protocol and show that it is vulnerable to a known session-specific temporary information attack and does not provide forward secrecy.
• Given the merits of Yang et al.’s scheme, we go one step further and propose a new ECC-based scheme in this platform. The proposed protocol not only improves security but also lowers communication costs and requires fewer primitives, making it a better fit for constrained environments.

1.2. Paper Organization

The rest of the paper is organized as follows: in Section 2, we represent the required preliminaries, including the notations and also some required backgrounds. Next, in Section 3, we review Yang et al.’s scheme as a recent blockchain-based authentication protocol for IoT. In this section, we demonstrate this scheme’s limitations also. To overcome the presented weaknesses and also provide a lightweight authentication protocol for IoT systems, we propose BCmECC in Section 4. The security and efficiency merits of BCmECC are discussed in Section 5 and Section 6 respectively. Finally, the paper is concluded in Section 7.

2. Preliminaries

2.1. Notation

We use the list of notations represented in

Table 1. List of used notations.

Symbol	Description
E	Elliptic Curve Cryptography
$\mathbb{G}$	A finite prime group
P	Generator point of a large group G
q	A large prime number
$sk$	Secret key
$PK$	Public key
$TA$	A trusted authority with public key of $P{K}_{TA}=s{k}_{TA}·P$ and secret key of $s{k}_{TA}$
$D_i/S_j$	$i/j$-th IoT device/server
$SID$	The unique identifier
$a/b$	Random number
$H(·)$	One-way hash functions
$ts$	Timestamp
$x·P$	Multiplying a point P by scalar x
$A\stackrel{?}{=}B$	Comparison of $\mathcal{A}$ and B
$SK$	The shared session key
$EL{T}_i$	$D_i$’s expire life time that is bounded by its $SI{D}_i$

in this paper.

2.2. Blockchain

In 2008, Satoshi Nakamoto proposed Bitcoin as a blockchain-based decentralized digital currency [24]. As a result, blockchain drew a lot of attention and grew in popularity. As seen in Figure 1, a blockchain is made up of blocks that are linked together to form a chain. Each block contains the block number, the hash of the previous block, a nonce, and transaction data. Each block will include the hash of the previous block, which will be used to construct the ledger. Every network node has its own ledger. Consensus mechanisms are at the heart of the blockchain, used to verify transactions and update the whole ledger. When a new transaction is uploaded to the ledger, all nodes in the network double-check the data’s correctness before adding it to their ledger. Each user must register a pair of public and private keys in order to join the network. This is performed by utilizing a transaction. The keys of each user are kept in his or her wallet. The blocks had been mined previously. Miners are network nodes that are responsible for creating and validating blockchain blocks [20]. It is both costly and difficult to change an authorized block in the ledger. Blockchain is divided into two types: public and private. In a public blockchain, anybody may participate in the block generation and consensus process, while only pre-approved nodes can do so in a private blockchain. Public type blockchains include Bitcoin [24] and Ethereum  [25], whereas private type blockchains include Hyperledger [26].

2.3. Smart Contract

A smart contract is a piece of executable code linked to the necessary memories/tables that are stored as a transaction in the blockchain and are used to perform a predetermined function on a given input. Miners frequently carry out smart contracts for a fixed fee. By knowing the transaction address, it is possible to invoke the smart contract for network members. Smart contracts may provide a high level of assurance due to blockchain’s immutability. In our system, the smart contract function is necessary for mapping the public key to the transaction identity. Hence, we recommend using Ethereum [25] in our design. In the literature, Ethereum has been frequently utilized for creating decentralized applications’ (dApps) smart contracts. It is a well-known blockchain that supports smart contracts. A smart contract can be created and shared by any member of the Ethereum network.

2.4. Elliptic Curve Cryptography

Given a curve $y^2=x^3+ax+b$, along with a distinguished point at infinity $\mathcal{O}$ and a prime number q, the Elliptic Curve Cryptography (ECC) $E_{F_q}$ is defined as an additive group G over the finite field $F_q$ including the set of all $(x,y)\in F_q\times F_q$ such that ${\lambda }^2={\mu }^3+a\mu +b$, where $a,b\in F_q$ and $4a^3+27b^{2}modq\ne 0$, along with $\mathcal{O}$. It is possible to define subgroups of G including a desired $P=\left\{\right(\lambda ,\mu )\in G\}$ which is cyclic and includes all powers of P; P is the generator of this subgroup. The size of the subgroup has defined the order of P which is defined as the smallest positive number n such that $n·P=\mathcal{O}$. For large values of n, given any natural scalar $a\in F_q$, it is easy to calculate $y=a·P$ (point multiplication) but given y, $E_{F_q}$ and P, it is computationally infeasible to compute the multiplicand a. This problem is known as the Elliptic Curve Discrete Logarithm Problem (ECDLP) and is believed to be hard and its difficulty is determined by the size of the elliptic curve subgroup. There is another hard problem over ECC which is called the Elliptic Curve Computational Diffie-Hellman Problem (EC-CDHP) and its aim is to compute $a·b·P$ given $a.P$, $b·P$, $E_{F_q}$ and P where $a,b\in F_q$.

2.5. System Model

As shown in Figure 2, we consider a system that includes servers that are used to offer a service for various IoT devices, such as collecting data or providing updates, and so on. When the devices/servers are produced they are also configured and their security parameters are set. As a result, in our concept, the manufacturer also serves as a trusted authority (TA). Because the connection between the devices and the server must be secure, and the IoT devices must only communicate with authorized servers, and the server must also trust the data from trustworthy IoT devices, they must mutually authenticate each other. To ensure a high degree of security, we assume that the security primitives are supported by public keys. Because IoT devices have limited capacity in many applications, they cannot maintain all of the certified public keys, and it is also not practical to place all of the verification traffic on the TA. As a result, we presume that there is a public blockchain that is utilized to validate the public keys. The legitimate public keys are fed into the BC by the TA solely via a smart contract and can be confirmed by any BC member, and the ultimate consensus mechanism might be based on proof of stake, which is more energy-efficient than proof of work. The TA may update the smart contract in this system to add a new identity (which is the public key of an IoT device or a server) or revoke it.

3. Review of Yang et al.’s Scheme

In this section, Yang et al.’s protocol [19] is briefly introduced, followed by a description of the protocol’s weaknesses in terms of security and performance.

3.1. Yang et al.’s Scheme Description

Yang et al. recently proposed a blockchain-based authentication protocol that uses a public blockchain as the source of the public trust and also employs modular square roots as the main source of security in the primitive level [19]. The proposed protocol includes four phases: initialization, registration, authentication, and update and revocation phases.

In the initialization phase of the protocol, the public parameters are announces, i.e., $\left\{H\right(·),MAC(·),Enc(·)/Dec(·\left)\right\}$. In addition, the blockchain is also established, e.g., based on some existing blockchain systems such as Hyperledger Fabric or Ethereum.

During the registration phase, all devices should be registered to a pre-authenticated device manager (DM), which is assumed to be trusted. Each IoT device, when it is produced by DM, selects two random primes $p_i$ and $q_i$ such that $p_i=q_i=3\sim 4$ and computes $P{K}_i=p_i·q_i$. The device sends its identity $SI{D}_i$ along its public key $P{K}_i$ to DM and it also confirms the validity and updates $\{P{K}_i,E{T}_i,SI{D}_{dm}\}$ into the smart contract, through $\mathbf{updatePKIT}(P{K}_i,E{T}_i,SI{D}_{dm})$, where $E{T}_i$ denotes expiry time of the IoT device and $SI{D}_{dm}$ refers to the DM’s identity. The device can verify its validity by invoking $\mathbf{queryPKIT}\left(P{K}_i\right)$. The registration of the server is also similar, where the server’s public key is $P{K}_s=p_s·q_s$, its identity is $SI{D}_s$ and its expiry time is $E{T}_s$.

The authentication phase of the protocol between the i-th IoT device $D_i$ and the j-th server $S_j$ is initiated by the IoT device, where it first verifies the validity of $P{K}_j$ by invoking the query function $\mathbf{queryPKIT}\left(P{K}_j\right)$ into the blockchain. Assuming that $P{K}_j$ is confirmed by the blockchain, otherwise it should be authenticated with another server, $D_i$ obtains the timestamp $t_s$ and selects a random integer a such that $b^{\frac{p_{d_i}-1}{2}}mod{p}_{d_i}=b^{\frac{q_{d_i}-1}{2}}mod{q}_{d_i}=1$, where $b=H(a,P{K}_j,t_s)$. Then, given $q_{d_i}$ and $p_{d_i}$, $D_i$ calculates the square roots of $r^2=bmodP{K}_{d_i}$, i.e., $r_1$, $r_2$, $r_3$ and $r_4$, and sets $s_i=min\{r_1,r_2,r_3,r_4\}$. Next, it computes ${\alpha }_d=a^{2}modP{K}_j$, $k_i=H\left(a\right)$, ${\beta }_d=MA{C}_{k_i}\left({\alpha }_d\right)$ and ${\gamma }_d=En{c}_{k_i}(ts,s_i,P{K}_{d_i})$ and sends $M_1=\{{\alpha }_d,{\beta }_d,{\gamma }_d\}$ to $S_j$.

Once received $M_1$, $S_j$ verifies its correctness to authenticate $D_i$. More precisely, given $p_{s_j}$ and $q_{s_j}$, it computes the roots of $r^2=bmodP{K}_{d_i}$, i.e., $r_1$, $r_2$, $r_3$ and $r_4$, and computes $k_{1/2/3/4}=H\left(r_{1/2/3/4}\right)$ to identify the secret key $k_i$ as ${\beta }_d=MA{C}_{k_i}\left({\alpha }_d\right)$. Given $k_i$, it decrypts ${\gamma }_d$ and obtains $(ts,s_i,P{K}_{d_i})$. Afterward, the validity of $ts$ is verified. Next, $S_j$ verifies the validity of $P{K}_{d_i}$ by invoking the query function $\mathbf{queryPKIT}\left(P{K}_j\right)$ into the blockchain. Assuming that $P{K}_{d_i}$ is legitimate, it verifies whether $s_i^2=H(a_i,P{K}_j,ts)modP{K}_{d_i}$ to authenticate the device. To be authenticated by $D_i$, the server $S_j$ generates ${\delta }_s=MA{C}_{k_s}(ts,s_i)$ and sends it to the device as $M_2$.

$D_i$ verifies the received ${\delta }_s$ to authenticate $S_j$ and sets $k_i$ as the session key; otherwise, the authentication process fails.

3.2. On the Security of Yang et al.’s Scheme

Although the scheme proposed by Yang et al. has interesting features and ensures mutual authentication between IoT devices and the server, it is also secure against most attacks assuming the adversary only has access to messages transferred over the public channel. Other attacks, on the other hand, are based on more serious assumptions about the adversary. For example, the security of previous sessions, if the long-term secret key has been leaked, or the security of the session key if the adversary has obtained the ephemeral session-dependent values.

These types of attacks are important because IoT devices are distributed across the network and the adversary may be able to access them and read their memory, which includes long-term secrets, for example. A privileged insider adversary can also leak the server’s data at any time. In this case, the security of previous sessions should be compromised as a result of this damage. In this section, we highlight some critical flaws in Yang et al.’s protocol in this framework.

3.2.1. The Lack of Perfect Forward Secrecy

The protocol provides perfect forward secrecy if compromising the entities’ long-term secrets at time t does not affect the security of the shared session keys at any time $t^{\prime }<t$.

Let us assume that the adversary eavesdropped on the transferred messages over the public channel in a session, which are $M_1=\{{\alpha }_d,{\beta }_d,{\gamma }_d\}$ and $M_2={\delta }_s=MA{C}_{k_s}(ts,s_i)$ where ${\alpha }_d=a^{2}modP{K}_j$, $k_i=H\left(a\right)$, ${\beta }_d=MA{C}_{k_i}\left({\alpha }_d\right)$ and ${\gamma }_d=En{c}_{k_i}(ts,s_i,P{K}_{d_i})$. In addition, assume the adversary is given access to the long-term secrets of the server $S_j$ which are $p_{s_j}$ and $q_{s_j}$. It is clear that the adversary, given $p_{s_j}$ and $q_{s_j}$, can follow the used procedure by the server to retrieve the values. More precisely, she or he computes the roots of $r^2=bmodP{K}_{d_i}$, i.e. $r_1$, $r_2$, $r_3$ and $r_4$, and computes $k_{1/2/3/4}=H\left(r_{1/2/3/4}\right)$ to identify the secret key $k_i$ as ${\beta }_d=MA{C}_{k_i}\left({\alpha }_d\right)$. Given $k_i$, it decrypts ${\gamma }_d$ and obtains $(ts,s_i,P{K}_{d_i})$. Afterward, the adversary verifies whether $s_i^2\stackrel{?}{=}H(a_i,P{K}_j,ts)modP{K}_{d_i}$ to make sure whether he or she retrieved the values correctly. It shows this protocol does not provide perfect forward secrecy.

3.2.2. Known Session-Specific Temporary Information Attack

Let us assume that the adversary knows the session-specific temporary values. In a secure protocol, it should not affect the security of the shared session key. Hence, we evaluate the security of Yang et al.’s scheme against the Known Session-specific Temporary Information Attack (KSTIA). More precisely, if the session’s short-term secrets are accidentally exposed to an attacker, the security of the produced session key should be unaffected. However, in Yang et al.’s scheme, the session key is computed as $k_i=H\left(a\right)$, where a is a selected random integer by the device $D_i$. It is clear that exposing a leads to direct leakage of the session key $k_i$. Hence, this protocol is valuable to KSTIA.

3.3. On the Efficiency of Yang et al.’s Scheme

Following description of Yang et al.’s scheme, to verify $M_1$, $S_j$ computes the roots of $r^2=bmodP{K}_{d_i}$, i.e., $r_1$, $r_2$, $r_3$ and $r_4$, and computes $k_{1/2/3/4}=H\left(r_{1/2/3/4}\right)$ to identify the secret key $k_i$ as ${\beta }_d=MA{C}_{k_i}\left({\alpha }_d\right)$. However, it is possible to verify the correctness of the driven roots after decryption of ${\gamma }_d$, where $(ts,s_i,P{K}_{d_i})$ is obtained. Afterward, the validity of $ts$ and $s_i^2=H(a_i,P{K}_j,ts)modP{K}_{d_i}$ are verified. Next, $S_j$ verifies the validity of $P{K}_{d_i}$ by invoking the query function $\mathbf{queryPKIT}\left(P{K}_j\right)$ into the blockchain to authenticate the device. To be authenticated by $D_i$, the server $S_j$ generates ${\delta }_s=MA{C}_{k_s}(ts,s_i)$ and sends it to the device as $M_2$. In this way, it is not necessary to force the end device to also support MAC function and it also reduces the communication cost, because $M_1$ can be redesigned as $M_1=\{{\alpha }_d,{\gamma }_d\}$. Hence, it shows that Yang et al.’s scheme is not optimum in the term of the used primitives and communication cost.

4. BCmECC, a Blockchain Mounted ECC Based Scheme

In this section, we attempt to design a blockchain-mounted ECC-based protocol called BCmECC, which does not have the shortcomings of the previous protocol, i.e., Yang et al.’s, and performs better in terms of performance, communication, and computational costs.

4.1. Initialization Phase

The smart contract is initiated in this phase of the proposed blockchain mounted ECC-based authentication protocol, named BCmECC, and the $TA$ releases the system parameters, i.e., $\{E_q(c,d),q,P,h(·)\}$ and its public key $P{K}_{TA}=s{k}_{TA}·P$ while keeping $s{k}_{TA}$ secret. We also assume that each device has an embedded serial number $SI{D}_i$ and an expiring lifetime $EL{T}_i$ that is bounded by its $SI{D}_i$. The smart contract is adapted from [19] and depicted in Algorithm 1.

4.2. Registration Phase of the Protocol

In the registration phase of BCmECC, each IoT device $D_i$, when it is produced by DM, selects a private key $s{k}_i$ and computes its public key as $P{K}_i=s{k}_i·P$. The device sends its identity $SI{D}_i$ along its public key $P{K}_i$ to DM and it also confirms the validity and updates $\{P{K}_i,E{T}_i,SI{D}_{dm}\}$ into the smart contract, through $\mathbf{updatePKIT}(P{K}_i,E{T}_i,SI{D}_{dm})$. The device can verify its validity by invoking $\mathbf{queryPKIT}\left(P{K}_i\right)$. The registration of the server is also similar, where the server public key is $P{K}_j=s{k}_j·P$, its identity is $SI{D}_j$ and its expiry time is $E{T}_j$.

4.3. Mutual Authentication Phase of the Protocol

This phase of BCmECC is represented in Figure 3. As it is also depicted in this figure, to connect with a server $S_j$, assuming that the device knows its public key $P{K}_j$, the device sends $\mathbf{queryPKIT}\left(P{K}_j\right)$ to $\mathbf{BC}$, extracts $ts$, generates a random number a, computes $k_i=H(ts,a·s{k}_i·P{K}_j)$, ${\alpha }_d=a·P{K}_i$, ${\beta }_d=En{c}_{k_i}(ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts))$ and sends $M_1=(ts,{\alpha }_d,{\beta }_d)$ to the server $S_j$ over the public channel.

Once received $M_1$, the server verifies $ts$, computes $k_s=H(ts,s{k}_j·{\alpha }_d)$ and $(t{s}^{\prime },P{K}_i^{\prime },P{K}_j^{\prime },H{(a·s{k}_i·P{K}_j,ts)}^{\prime })=De{c}_{k_s}\left({\beta }_d\right)$, verifies $t{s}^{\prime }=ts$, $P{K}_j^{\prime }=P{K}_j$ and $H{(a·s{k}_i·P{K}_j,ts)}^{\prime }\stackrel{?}{=}H(s{k}_j·{\alpha }_d,ts)$ to accept the request and send $\mathbf{queryPKIT}\left(P{K}_i\right)$ to $\mathbf{BC}$. If $P{K}_i$ is valid, it generates a random number b, computes ${\lambda }_s=b·P{K}_j$ and ${\gamma }_s=H(b·H(ts,k_s)·s{k}_j·{\alpha }_d)$ and sends $M_2=({\lambda }_s,{\gamma }_s)$ to the device $D_i$ over the public channel. The device $D_i$ verifies the received ${\gamma }_s\stackrel{?}{=}H(a·H(ts,k_i)·s{k}_i·{\lambda }_s)$ to authenticate $S_j$. Assuming the authentication phase was successful, the session key is computed on the server and $D_i$ sides as $S{K}_{ts}=H(ts,b·s{k}_j{\alpha }_d)$ and $S{K}_{ts}=H(ts,a·s{k}_i{\lambda }_s)$, which are clearly the same.

Algorithm 1. A smart contract-based management of the entities’ public key information using Public Key Information Table (PKIT) which has been adapted from the used smart contract of [19].

Require: Function name and the invoked parameters and address of device manager (DM). Ensure: Setting up functions structure PKI //Define the structure of components in PKIT   1: byte20[2] $PK$;   2: int ET;                                                                 //  the expiry time   3: byte20 SID;

4: function$updatePKIT(PK,ET,SID)$   //Invoked by DM to update public key information       5: if$DM==msg.sender$then       6:     if $PKI\left[i\right].PK\in PKIT$ then       7:         $PKI\left[i\right]:PK\leftarrow PK$;       8:         $PKI\left[i\right]:ET\leftarrow ET$;       9:         $PKI\left[i\right]:SID\leftarrow SID$;       10:         return 1;       11:     else       12:         $\ell \leftarrow \ell +1$;       13:         $PKI\left[i\right]:PK\leftarrow PK$;       14:         $PKI\left[i\right]:ET\leftarrow ET$;       15:         $PKI\left[i\right]:SID\leftarrow SID$;       16:         return 1;       17: else       18:     return 0;       19: function$queryPKIT\left(PK\right)$      //Invoked by DM to update public key information       20: if$DM==msg.sender$then       21:     if $PKI\left[i\right].PK\in PKIT$ && $PKI\left[i\right].ET$ is fresh then       22:         return 1;       23:     else       24:         return 0;       25: else       26:     return 0;       27: function$revokePKIT(PK,SID)$        //Invoked by DM to revoke an IoT device or server       28: if$DM==msg.sender$then       29:     if $PKI\left[i\right].PK\in PKIT$ then       30:         $PKIT\leftarrow PKIT/PKI\left[i\right]$;       31:         $\ell \leftarrow \ell -1$;       32:         return 1;       33:     else       34:         return 0;       35: else       36:     return 0;

4.4. Update and Revocation Phase of the Protocol

Once in a while, it may be required to update the IoT device’s public key or revoke it before its expiration time. For the revocation, the TA can revoke the target device/server ($D_i/S_j$) from the smart contract by invoking the $\mathbf{revokePKIT}(P{K}_{i/j},SI{D}_{dm})$ query.

To update the public key of a device/server ($D_i/S_j$), it should be authenticated into the TA, and sends the new public key to the TA. Next, the TA revokes the previous record from the smart contract by $\mathbf{revokePKIT}(P{K}_{i/j}^{old},SI{D}_{dm})$ and then updates the smart contract by $\mathbf{updatePKIT}(P{K}_{i/j}^{new},E{T}_i,SI{D}_{dm})$. The authentication phase of $D_i/S_j$ to TA is depicted in Figure 4.

To start the authentication phase, $D_i/S_j$ selects a private key $s{k}_{i/j}^{new}$ and computes its public key as $P{K}_{i/j}^{new}=s{k}_{i/j}^{new}·P$. Then, it extracts $ts$, generates a random value a, computes $k_{i/j}=H(ts,a·s{k}_{i/j}·P{K}_{TA})$, ${\alpha }_d=a·P{K}_{i/j}$, ${\beta }_d=En{c}_{k_{i/j}}(a,P{K}_{i/j},P{K}_{TA},P{K}_{i/j}^{new},SI{D}_{i/j})$ and sends $M_1=(ts,{\alpha }_d,{\beta }_d)$ to TA over the public channel.

Once received $M_1$, the TA verifies $ts$, computes $k_s=H(ts,s{k}_{TA}j·{\alpha }_d)$ and $(a,P{K}_{i/j},P{K}_{TA},P{K}_{i/j}^{new},SI{D}_{i/j})=De{c}_{k_s}\left({\beta }_d\right)$, verifies $t{s}^{\prime }=ts$, $P{K}_{TA}^{\prime }=P{K}_{TA}$, $SI{D}_{i/j}$ corresponds to $P{K}_{i/j}$ and $k_s=H(ts,a·s{k}_{TA}·P{K}_{i/j})$ to proceed the request. Then, it sends $\mathbf{queryPKIT}\left(P{K}_{i/j}\right)$ to $\mathbf{BC}$. If $P{K}_{i/j}$ is valid then TA computes ${\gamma }_{TA}=H(t{s}_i,P{K}_{i/j},P{K}_{i/j}^{new},P{K}_{i/j}^{old},k_s)$ and sends $M_2=({\lambda }_s,{\gamma }_s)$ to $D_i/S_j$ over the public channel.

The device $D_i/S_j$ verifies the received ${\gamma }_{TA}=H(t{s}_i,P{K}_{i/j},P{K}_{i/j}^{new},P{K}_{i/j}^{old},k_s)$ to authenticate TA. Next, it sends ${\theta }_d={\gamma }_{TA}·(s{k}_{i/j}^{new}+s{k}_{i/j}^{old})·P{K}_{TA}$ to TA as $M_3$.

Once received $M_3$, TA verifies ${\theta }_d={\gamma }_{TA}·s{k}_{TA}·(P{K}_{i/j}^{new}+P{K}_{i/j}^{old})$ to accept the request and send $\mathbf{revokePKIT}(P{K}_{i/j}^{old},SI{D}_{dm})$ to $\mathbf{BC}$ and then updates the smart contract by $\mathbf{updatePKIT}(P{K}_{i/j}^{new},E{T}_i,SI{D}_{dm})$.

After a while, $D_i/S_j$ sends $\mathbf{queryPKIT}\left(P{K}_{i/j}\right)$ to $\mathbf{BC}$ to make sure it has been updated on the smart contract by TA and removes $\left(s{k}_{i/j}^{old}\right),\left(P{K}_{i/j}^{old}\right)$ from its memory. Otherwise, it means that the protocol’s run was not successful and should be re-launched.

5. Security Analysis of BCmECC

In general, there are two methods for analyzing and proving the security of security protocols. Methods can be formal or informal. Informal methods are those that use creativity, knowledge, and innovative methods to find a security flaw or prove the protocol’s security. To discover protocol security vulnerabilities or prove its security, manual formal methods such as BAN logic  [27] or automatic formal methods such as Scyther [28] are used.

In this section, we evaluate the security of BCmECC against various attacks and also verify its security both informally and formally using widely accepted formal methods, i.e. Scyther tool and BAN logic.

5.1. Formal Security Analysis

5.1.1. BAN Logic

Several phases are involved in the security evaluation of BCmECC employing BAN logic [27]. To begin, the messages of BCmECC are described in BAN logic form, see

Table 2. Expressing the messages of BCmECC in BAN logic.

No.	Description
$M1:$	$S_j⊲t_s,{\alpha }_d,{\beta }_d={\{ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts)\}}_{k_i}={\{ts,P{K}_i,H(a·s{k}_j·P{K}_i,ts)\}}_{k_i}={\{ts,P{K}_i,H(s{k}_j·{\alpha }_d,ts)\}}_{k_i}={\{ts,P{K}_i,{\alpha }_d\}}_{K_i}$
$M2:$	$D_i⊲{\lambda }_s,{\gamma }_s=H(b.H(ts,k_s).s{k}_j.{\alpha }_d)=H(b.H(ts,K_s).s{k}_j.a.P{K}_i)=H(b.H(ts,k_s).P{K}_j.a.s{k}_i)=H({\lambda }_s.H(ts,k_s).a.s{k}_i)={\{{\lambda }_s,ts,a\}}_{k_s}$

, where we use BAN logic notations depicted in

Table 3. Some of BAN logic notations and rules used in this paper.

Notations	Description
$♯\left(X\right)$	X is fresh
${\left\{X\right\}}_K$	The symmetric encryption of X with K as the key
$P⊲X$	P sees the message X
$P\stackrel{K}{⟷}Q$	K is secretly shared between P and Q
$F1:{\displaystyle \frac{P|\equiv X,P|\equiv Y}{P|\equiv (X,Y)}}$	If P believes the message X and also believes Y then it is entitled that P believes $(X,Y)$
$F2:{\displaystyle \frac{P|\equiv P\stackrel{K}{⟷}Q,P⊲{\left\{X\right\}}_K}{P|\equiv Q|\sim X}}$	If P believes the K is securely shared between itself and Q and also receives the ${\left\{X\right\}}_K$, then it is deduced that P believes Q conveys message X
$F3:{\displaystyle \frac{P|\equiv ♯X,P|\equiv Q|\sim X}{P|\equiv Q|\equiv X}}$	If P believes the X is fresh and also believes that the Q has sent X, then it is entitled that P believes Q believes X
$F4:{\displaystyle \frac{P|\equiv X}{P|\equiv H(X)}}$	If P believes the message X then it is entitled that P believes the hash value of X i.e., $H\left(X\right)$
$F5:{\displaystyle \frac{P|\equiv (X,Y)}{P|\equiv X,P|\equiv Y}}$	If P believes in a set of messages i.e., $(X,Y)$, then it is deduced P believes in each of them
$F6:{\displaystyle \frac{P|\equiv ♯(X)}{P|\equiv ♯(X,Y)}}$	If P believes freshness of X, then it is deduced P believes freshness of any combination of it

to show messages. Following that, the messages of BCmECC are idealized. Messages that are too simple or do not inspire confidence are removed at this stage.

Table 4. Idealization of the messages of BCmECC in BAN logic.

No.	Description
$IM1:$	$S_j⊲ts,{\alpha }_d,{\beta }_d={\{ts,P{K}_i,{\alpha }_d,s{k}_i,P{K}_j,H(a·s{k}_i·P{K}_j,ts)\}}_{k_i}={\{ts,P{K}_i,{\alpha }_d\}}_{K_i}$
$IM2:$	$D_i⊲{\lambda }_s,{\gamma }_s=H(b.H(ts,k_s).s{k}_j.{\alpha }_d)=H(b.H(ts,k_s).s{k}_j.a.P{K}_i)=H(b.H(ts,k_s).P{K}_j.a.s{k}_i)=H({\lambda }_s.H(ts,k_s).a.s{k}_i)=\{{\lambda }_s,ts,a\}{k}_s$

depicts the idealized form of protocol messages. Following that, BCmECC’s security assumptions and security goals are stated. The assumptions and security goals are shown in

Table 5. BCmECC’s assumptions and security goals.

A/G	Description	A/Goal	Description
$A1$	$D_i|\equiv ♯ts$	$A2$	$S_j|\equiv ♯ts$
$A3$	$D_i|\equiv ♯a$	$A4$	$S_j|\equiv ♯b$
$A5$	$S_j|\equiv s{k}_j$	$A6$	$D_i|\equiv s{k}_i$
$A7$	$D_i|\equiv D_i\stackrel{k_i,k_s}{⟷}{S}_j$	$A8$	$S_j|\equiv S_j\stackrel{k_i,k_s}{⟷}{D}_i$
$G1$	$D_i|\equiv SK$	$G2$	$S_j|\equiv SK$

. The security goals should then be deduced from an ideal form and assumptions using BAN logic rules. As shown in

Table 6. Deduction of BCmECC’s security goals.

Assumptions, Messages and Rules	Deduction
$A7,IM2$ based on $F2$	$D1:D_i|\equiv S_j|\sim \{{\lambda }_s,ts,a\}$
$A1,D1$ based on $F6$	$D2:D_i|\equiv ♯\{{\lambda }_s,ts,a\}$
$D1,D2$ based on $F3$	$D3:D_i|\equiv S_j|\equiv \{{\lambda }_s,ts,a\}$
$D3$ based on $F5$	$D4:D_i|\equiv {\lambda }_s$, $D5:D_i|\equiv ts$, $D6:D_i|\equiv a$
$A6,D4,D6$ based on $F1$	$D7:D_i|\equiv (a.s{k}_i.{\lambda }_s)$
$D7,D5$ based on $F1$	$D8:D_i|\equiv (ts,a.s{k}_i.{\lambda }_s)$
$D8$ based on $F4$	$D9:D_i|\equiv H(ts,a.s{k}_i.{\lambda }_s)=>D_i|\equiv SK$=$G1$
$A8,IM1$ based on $F2$	$D10:S_j|\equiv D_i|\sim \{t_s,P{K}_i,{\alpha }_d\}$
$A2$ based on $F6$	$D11:S_j|\equiv ♯\{t_s,P{K}_i,{\alpha }_d\}$
$D10,D11$ based on $F3$	$D12:S_j|\equiv D_i|\equiv \{t_s,P{K}_i,{\alpha }_d\}$
$D12$ based on $F5$	$D13:S_j|\equiv ts$, $D14:S_j|\equiv P{K}_i$, $D15:S_j|\equiv {\alpha }_d$
$A5$, $A4$, $D15$ based on $F1$	$D16:S_j|\equiv (b.s{k}_j.{\alpha }_d)$
$D13$,$D16$ based on $F1$	$D17:S_j|\equiv (ts,b.s{k}_j.{\alpha }_d)$
$D17$ based on $F4$	$D18:S_j|\equiv H(ts,b.s{k}_j.{\alpha }_d)=>S_j|\equiv SK$=$G2$

, utilizing $A7$ and $IM2$ based on the $F2$ rule of BAN logic, we deduce that $D1:D_i|\equiv S_j|\sim \{{\lambda }_s,t_s,a\}$. Given $D1$ and $A1$, and using the $F6$ rule of BAN logic, we can derive that $D2:D_i|\equiv ♯\{{\lambda }_s,t_s,a\}$. With $D1$ and $D2$ based on $F3$, we obtain $D3:D_i|\equiv S_j|\equiv \{{\lambda }_s,t_s,a\}$. Using $D3$ and $F5$, we get $D4:D_i|\equiv {\lambda }_s$, $D5:D_i|\equiv t_s$, and $D6:D_i|\equiv a$. We calculated $D7:D_i|\equiv (a.s{k}_i.{\lambda }_s)$ using $A6$, $D4:D_i|\equiv {\lambda }_s$, and $D6:D_i|\equiv a$ based on $F1$. We get $D8:D_i|\equiv (ts,a.s{k}_i.{\lambda }_s)$ from $D7$ and $D5$ based on $F1$. Using $F4$, we inferred that $D9:D_i|\equiv H(ts,a.s{k}_i.{\lambda }_s)$ is the same session secret key, i.e. $D9:D_i|\equiv SK$ as $G1$. It verifies the security goal $G1$, indicating that $D_i$ believes a session key has been created between itself and the server. We can conclude $D10:S_j|\equiv D_i|\sim \{t_s,P{K}_i,{\alpha }_d\}$ using $A8$ and $IM1$ based on the $F2$ rule of BAN logic. Given $A2$, we may derive from the $F6$ rule of BAN logic that $D11:S_j|\equiv ♯\{t_s,P{K}_i,{\alpha }_d\}$. Taking into account $D10$ and $D11$ based on $F3$, we obtain $D12:S_j|\equiv D_i|\equiv \{t_s,P{K}_i,{\alpha }_d\}$. We get $D13:S_j|\equiv t_s$, $D14:S_j|\equiv P{K}_i$, $D15:S_j|\equiv {\alpha }_d$ from $D12$ based on $F5$. Using $A5$, $D15:S_j|\equiv {\alpha }_d$, and $A4$ based on $F1$, we deduced $D16:S_j|\equiv (b.s{k}_j.{\alpha }_d)$. Given $D13$ and $D16$, we get $D17:S_j|\equiv (ts,b.s{k}_j.{\alpha }_d)$. Using $F4$, we inferred that $D18:S_j|\equiv H(ts,b.s{k}_j.{\alpha }_d)$ is the same session secret key as $G2$, i.e., $D18:S_j|\equiv SK$. It confirms the security goal $G2$, implying that $S_j$ believes a session key has been created between itself and $D_i$.

5.1.2. Scyther

In this section, we demonstrate that BCmECC meets all of the protocol’s security objectives using the Scyther tool [28]. Scyther evaluates all forms of security claims in the protocol and, if any type of attack is discovered, the attack situation is graphically displayed. To be more specific, the Scyther studies secrecy and authentication in security protocols. To that aim, BCmECC is described in the Security Protocol Description Language (SPDL), as seen in Figure 5, and examined using the Scyther tool. The security verification result of the mutual authentication phase of BCmECC is likewise presented in Figure 6.

5.2. Informal Security Analysis

It is common to argue the protocol’s security against various attacks in an informal manner to confirm its security. In this section, we argue BCmECC’s security against well-known attacks in order to demonstrate its security strengths.

5.2.1. Replay Attack

To do a replay attack, the adversary tries to impersonate a protocol’s party by eavesdropping on a session of the protocol between legitimate entities and later broadcasting the stored messages to be authenticated as a legitimate party. In the authentication phase of BCmECC, the transferred messages over the public channel are as follows:

$$\begin{array}{cc}\hfill {\alpha }_d& =a·P{K}_i\hfill \\ \hfill {\beta }_d& =En{c}_{k_i}(ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts))\hfill \\ \hfill {\lambda }_s& =b·P{K}_j\hfill \\ \hfill {\gamma }_s& =H(t{s}_i,P{K}_j,P{K}_i^{\prime },k_s)\hfill \end{array}$$

where $k_i=k_s=H(ts,a·s{k}_i·P{K}_j)$. Since the encryption/decryption key is a factor of the timestamp $ts$, the eavesdropped message at the time t cannot be used in any later time $t^{\prime }$ as it is. In addition, to generate a valid key $k_i=k_s=H(ts,a·s{k}_i·P{K}_j)$, the adversary should compute $a·s{k}_i·P{K}_j$ without the knowledge of $s{k}_{i/j}$ which is as hard as ECDLP. Hence, the proposed protocol is secure against a replay attack.

5.2.2. Impersonation Attack

To impersonate a target protocol entity, the adversary must either perform a replay attack or generate valid messages that can be accepted by a protocol party. However, in the case of BCmECC, we argued in Section 5.2.1 that a replay attack is not feasible. The adversary, on the other hand, is unable to generate valid messages because to compute valid ${\beta }_d=En{c}_{k_i}(ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts))$ or ${\lambda }_s=b·P{K}_j$ and ${\gamma }_s=H(b·H(ts,k_s)·s{k}_j·{\alpha }_d)$ the adversary should calculate $k_i=k_s=H(ts,a·s{k}_i·P{K}_j)$ successfully, which requires computing $s{k}_{i/j}·P{K}_{j/i}$, given $P{K}_i$ and $P{K}_j$. However, computing $s{k}_{i/j}·P{K}_{j/i}$ form $s{k}_i·P$ and $s{k}_j·P$ equals to solving ECDLP again. It means that BCmECC is secure against impersonation attacks.

5.2.3. Traceability and Anonymity

To trace a protocol party, the adversary should be able to link the transferred messages over different sessions, in which a specific entity has been involved, together or to the target entity. In the proposed protocol, the transferred messages are ${\alpha }_d=a·P{K}_i$, ${\beta }_d=En{c}_{k_i}(ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts))$, ${\lambda }_s=b·P{K}_j$ and ${\gamma }_s=H(b·H(ts,k_s)·s{k}_j·{\alpha }_d)$, where a is a random value which is generated in the session by $D_i$ and randomizes ${\alpha }_d$, and ${\beta }_d$ directly, because it is used in their computation. In addition, ${\gamma }_s=H(b·H(ts,k_s)·s{k}_j·{\alpha }_d)$ is also a factor of a, because $k_s=H(ts,a·s{k}_i·P{K}_j)$. Hence, all the transferred messages are randomized by a random value which is changed from a session to another session. It guarantees a protocol’s security against traceability attacks. It should be noted that, similar to most of the other blockchain-based protocols, it is possible to trace a node’s public key (not its real identity) assuming that the adversary can also control the queries toward the smart contract of blockchain.

5.2.4. Secret Disclosure Attack

The secret parameter in the IoT device is its secret key $s{k}_i$ and the secret of the server is $s{k}_j$. However, neither of them is transferred in the plain form over the channel. Hence, it is not feasible for the adversary to extract them from the eavesdropped values from the channel. The session key is also computed as $k_i=k_s=H(ts,a·s{k}_i·P{K}_j)$. However, again the adversary cannot compute it given $P{K}_i$, $P{K}_j$, ${\alpha }_d=a·P{K}_i$, ${\beta }_d=En{c}_{k_i}(ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts))$, ${\lambda }_s=b·P{K}_j$ and ${\gamma }_s=H(b·H(ts,k_s)·s{k}_j·{\alpha }_d)$ without contradicting ECDLP, which is not feasible in practice. Hence, BCmECC is secure against secret disclosure attacks.

5.2.5. Permanent de-Synchronization Attack

To permanently de-synchronize a protocol party, the adversary could force them to update their shared values differently, as seen in [29]. However, in the authentication phase of BCmECC, the protocol’s parties do not update the shared values, hence, it is not possible to de-synchronize them in this phase.

It may be possible to desynchronize a legitimate $D_i/S_j$ in the update phase of the protocol. However, the process of that phase is almost similar to the authentication phase, and the adversary should be able to impersonate the target $D_i/S_j$ to encourage TA to update its public key on the blockchain. However, in that case the adversary should generate a valid ${\theta }_d={\gamma }_{TA}·(s{k}_{i/j}^{new}+s{k}_{i/j}^{old})·P{K}_{TA}$ which requires the knowledge of $s{k}_{i/j}^{old}$, which is not available to the adversary and extracting it form $P{K}_{i/j}$ contradicting ECDLP, which is not feasible in practice. Hence, BCmECC is secure against de-synchronization attack.

5.2.6. Man-in-the-Middle Attack

Given that hash functions ensure the integrity of all messages and timestamps govern session time, any message tampering or unexpected delay by a man-in-the-middle adversary will have a high likelihood of being discovered. As a result, BCmECC is safe from man-in-the-middle attacks.

5.2.7. Insider Adversary

Let us assume a malicious server $S_j$, which has been contacted by $D_i$, aims to impersonate $D_i$ toward another server $S_{j^{\prime }}\ne S_j$ or toward TA. To impersonate $D_i$ toward $S_{j^{\prime }}$, the adversary should compute

$$\begin{array}{cc}\hfill {\alpha }_d& =a·P{K}_i\hfill \\ \hfill {\beta }_d& =En{c}_{k_i}(a,P{K}_i,P{K}_{j^{\prime }},H(a·s{k}_i·P{K}_j^{\prime },ts))\hfill \\ \hfill k_i& =H(ts,a·s{k}_i·P{K}_{j^{\prime }})\hfill \end{array}$$

Although ${\alpha }_d$ can be computed easily or even reused from the previous sessions, computing $k_i=H(ts,a·s{k}_i·P{K}_{j^{\prime }})$ is challenging because the adversary should compute $a·s{k}_i·P{K}_{j^{\prime }}$ given $a·s{k}_i·P{K}_j$, $P{K}_{j^{\prime }}$, $P{K}_j$ and $P{K}_i$ and requires to contradict ECDLP, which is not feasible in practice. However, if $S_j$ colludes with $S_{j^{\prime }}$ they can compute $a·s{k}_i·P{K}_{j^{\prime }}$ from the given information. However, in this case $S_j$ also learns $s{k}_{j^{\prime }}$ or vice versa which is not acceptable. To impersonate $D_i$ toward TA, the insider adversary should compute ${\alpha }_d=a·P{K}_{i/j}$, ${\beta }_d=En{c}_{k_{i/j}}(a,P{K}_{i/j},P{K}_j,H(a·s{k}_i·P{K}_j,ts))$ and ${\theta }_d={\gamma }_{TA}·(s{k}_{i/j}^{new}+s{k}_{i/j}^{old})·P{K}_{TA}$ from the above mentioned information and $P{K}_{TA}$ which again infeasible. Hence, BCmECC is secure against insider adversary. It should be noted we consider $TA$ completely honest. Otherwise it can mislead whole the network by injecting wrong information in the smart-contract.

5.2.8. Perfect Forward Secrecy

In the forward secrecy analysis, the adversary should not be able to release the ephemeral session key of the session t assuming that it has the long-term key of the protocol at time $t^{\prime }$. In BCmECC, the session key is computed as $S{K}_{ts}=H(ts,b·s{k}_j{\alpha }_d)=H(ts,a·s{k}_i{\lambda }_s)$ and the adversary has access to $P{K}_i$, $P{K}_j$, ${\alpha }_d=a·P{K}_i$, ${\beta }_d=En{c}_{k_i}(ts,P{K}_i,H(a·s{k}_i·P{K}_j,ts))$, ${\lambda }_s=b·P{K}_j$ and ${\gamma }_s=H(b·H(ts,k_s)·s{k}_j·{\alpha }_d)$ and also $s{k}_i$ and $s{k}_j$. In this case the adversary’s main challenge is to compute $a·b·s{k}_i·s{k}_j·P$. However, it could achieve $a·P$ and $b·P$ not $a·b·P$ from that information without contradicting ECDLP, which is not feasible in practice. Hence, BCmECC provides perfect forward secrecy.

5.2.9. Known Session-Specific Temporary Information Attack

Let us assume the adversary knows the session specific temporary values of BCmECC, i.e., a, b and $ts$, and tries to compute the shared session key. To extract the session key, the adversary should compute $S{K}_{ts}=H(ts,b·s{k}_j{\alpha }_d)=H(ts,a·s{k}_i{\lambda }_s)$. However, similar to the case of perfect forward secrecy, the main challenge is the computation of $a·b·s{k}_i·s{k}_j·P$ from the available messages over public channel and also a, b and $ts$. Given that the adversary cannot compute $s{k}_i·s{k}_j·P$ from $P{K}_i$ and $P{K}_j$, it also cannot compute $a·b·s{k}_i·s{k}_j·P$ without contradicting ECDLP, which is not feasible in practice. Hence, BCmECC provides perfect forward secrecy. Hence, this protocol is secure against KSTIA.

6. On the Efficiency of BCmECC

Given that BCmECC is inspired by the proposed scheme by Yang et al. [19], we discuss the advantages of the BCmECC over that scheme to ensure its efficiency, besides its better security.

In the term of the required primitives, the client and the server of Yang et al.’s scheme [19] should support modular square roots computation, symmetric encryption, one-way hash function, and also a message authentication code. BCmECC requires ECC, symmetric encryption and a one-way hash function.

In terms of the communication cost, thanks to the short length of the key in the ECC compared to modular square roots computation for the same security margin, we decreased the communication cost dramatically. More precisely, to achieve an 80/112/128-bit key in a symmetric algorithm, the parameter length should be 1024/2048/3072 in modular square roots computation, while 160/256/384-bit ECC provides the same security levels. Therefore, to provide a 128-bit level of security, we should use a 256-bit hash function such as SHA-256 [30], a 256-bit curve, and a 128-bit block cipher, e.g., AES-128 [31]. Hence, assuming that we use 64 bits to represent $ts$, the length of the transferred messages over mutual authentication phase of BCmECC are determined as $|M_1|=|(ts,{\alpha }_d,{\beta }_d)|=64+512+(64+512+256)=1408$ and $|M_2|=|({\lambda }_s,{\gamma }_s)|=512+256=768$ bits. While in Yang et al. for the same security level, if we assume it is secure, the length of the transferred messages over its mutual authentication phase are determined as $|M_1|=|({\alpha }_d,{\beta }_d,{\gamma }_d)|=3072+256+64+3072+3072=9536$ and $|M_2|=|{\delta }_s|=256$ bits.

7. Conclusions and Future Works

In this paper, we first describe the security and performance flaws of the authentication protocol proposed by Yang et al. based on the blockchain. Then, inspired by this protocol and utilizing elliptic curve cryptography (ECC) in the blockchain’s bed, the BCmECC protocol was proposed. Informal and formal security assessments of BCmECC by the BAN logic and the Scyther automatic security verifier tool show that it is more secure than its predecessors. In addition, the performance evaluation shows that, in addition to increasing security, the protocol has reduced communication and computational costs.

While using blockchain increases the public trust in the authentication process and also decreases the required resources in the devices because it does not require to keeping of the certificates of all parties assuming that there is no reliable connection to the TA, sending the public key of an entity to Blockchain leads to a sort of traceability. It should be noted that all public Bitcoin transactions are also traceable and archived indefinitely on the bitcoin network. Although Bitcoin addresses are the sole information utilized to identify where Bitcoin is allocated and where it is delivered, the utilized addresses reveal the history of all transactions in which they are engaged. Since everyone has access to the inventory and all transactions for each address, so the Bitcoin also does not provide full anonymity. Therefore, it remains open research to use the blockchain’s advantage while also providing full anonymity. Although in the proposed protocol it is possible to update the public key once in a while to break the traceability sequence, it needs a new approach to design such a protocol, which may be costly.