Designing secure blockchain-based access control scheme in IoT-enabled Internet of Drones deployment

Journal Pre-proof Designing secure blockchain-based access control scheme in IoT-enabled Internet of Drones deployment Basudeb Bera, Durbadal Chattaraj, Ashok Kumar Das

PII: DOI: Reference:

S0140-3664(19)31837-7 https://doi.org/10.1016/j.comcom.2020.02.011 COMCOM 6211

To appear in:

Computer Communications

Received date : 30 November 2019 Revised date : 7 January 2020 Accepted date : 3 February 2020 Please cite this article as: B. Bera, D. Chattaraj and A.K. Das, Designing secure blockchain-based access control scheme in IoT-enabled Internet of Drones deployment, Computer Communications (2020), doi: https://doi.org/10.1016/j.comcom.2020.02.011. This is a PDF file of an article that has undergone enhancements after acceptance, such as the addition of a cover page and metadata, and formatting for readability, but it is not yet the definitive version of record. This version will undergo additional copyediting, typesetting and review before it is published in its final form, but we are providing this version to give early visibility of the article. Please note that, during the production process, errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. © 2020 Published by Elsevier B.V.

Journal Pre-proof

Designing secure blockchain-based access control scheme in IoT-enabled Internet of Drones deployment a

c

lP repro of

Basudeb Beraa , Durbadal Chattarajb , and Ashok Kumar Dasc,∗

Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad 500 032, India E-mail: [email protected] b Subir Chowdhury School of Quality and Reliability, Indian Institute of Technology, Kharagpur 721302, India E-mail: [email protected] Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad 500 032, India E-mail: [email protected], [email protected] ∗ Corresponding author: Ashok Kumar Das (E-mail: [email protected], [email protected])

Abstract

rna

In recent years, the Internet of Drones (IoD) has emerged as an important research topic in the academy and industry because it has several potential applications ranging from the civilian to military. In IoD environment, several drones, called Unmanned Aerial Vehicles (UAVs), are deployed in different flying zones that communicate each other to exchange crucial information, and then the information are collected by the Ground Station Server (GS S ). All the drones and the GS S are registered with a central trusted authority, Control Room (CR) prior to their deployment. Since the drones and the GS S communicate over open channel (e.g., wireless medium), there are security and privacy issues in the IoD environment. To handle such issues, in this paper we introduce a blockchain-based access control scheme in the IoD environment that allows secure communication among the drones, and also among the drones and the GS S . Secure data gathered by the GS S form transactions, and those transactions are made into the blocks. The blocks are finally added in the blockchain by the cloud servers connected with the GS S via the Ripple Protocol Consensus Algorithm (RPCA) in a peer-to-peer cloud server network. Once the blocks are added into the blockchain, the transactions containing in the blocks can not be altered, modified or even removed. We provide all sorts of security analysis including formal security under the random oracle model, informal security and simulation-based formal security verification to assure that the proposed scheme can resist various potential attacks with high probability needed in an IoD environment. In addition, a meticulous comparative analysis among the proposed scheme and other closely related existing schemes shows that our scheme offers more functionality attributes and better security, and also low communication and computation costs as compared to other schemes. Keywords: Internet of Drones (IoD), access control, blockchain, consensus, security, AVISPA. 1. Introduction

Jou

With the technological advancement of Internet of Things (IoT), it is easy to connect various objects (or things) through the Internet. In such a provision, these objects collaboratively collect a massive amount of data from different sources and then originate a meaningful insight (or information) from the collected data, and later the information are used for different real-time application-specific usage (e.g. civilian and military) [3], [19]. In IoT environment, these objects are broadly classified into two different categories: (i) physical objects such as drones, surveillance cameras, smartphones, vehicles and smarthome, and (ii) virtual object such as, e-ticket and e-wallet [24], [72]. One of the advantages to utilize such type of objects (or things) in IoT environment are that they are capable to take their own decisions without human interventions, and they can be easily integrated through the Web applications. A drone is an “unmanned aerial vehicle (UAV)” which is an aircraft controlled remotely or by an onboard computers. The drones can navigate autonomously without involvement of human control. A drone consists of several IoT smart dePreprint submitted to Computer Communications

vices, such as “light-pulse distance sensors (laser)”, “radio detection and ranging sensors”, “magnetic-field change sensor”, “sonar-pulse distance sensor (ultrasonic)”, “time of flight (ToF) sensors (range imaging)”, “thermal sensors”, “chemical sensors” and “orientation sensors” [21]. The task performed by each individual smart device inside the drone is provided in [21]. According to the current practice, the drones are effectively utilized in various commercial, military, and entertainment applications namely, product delivery, Line of Control (LoC) surveillance, aerial photography, traffic control and management and cinematography [47]. With the miniaturization of different devices (processors, micro-controllers, sensors and wireless transceivers) inside a drone implicitly maps IoT technology, IoD becomes as a part of IoT. A generalized IoT-enabled IoD architecture is shown in Figure 1. In this architecture, we have communications among the drones in a flying zone, among the drones and the GS S , and also among the GS S and the CR.

January 7, 2020

rna

lP repro of

Journal Pre-proof

Figure 1: A generalized IoT-enabled IoD architecture (adapted from [59])

Jou

1.1. Motivation Lin et al. [47] pointed out that security and privacy issues are essential in an IoD environment. They also discussed some solutions to address demanding issues including “data confidentiality protection”, “privacy leakage”, and “flexible accessibility”. To secure IoD environment, several cryptographic techniques such as key management, authentication, access control, intrusion detection and privacy preservation, are essential. Among all these, access control is an important security service that is essential to secure data in an IoD environment as in IoT environment [24]. Recently, it has been shown that combination of blockchain and cryptographic techniques has better security protection against passive as well as active adversaries in various applications where the communication takes place via public channel [2], [18], [19], [27], [35], [46], [48]. Access control mechanism primarily deals with the following two tasks:

in order to prove that they are genuine deployed drones or the GS S in the IoD environment for accessing the realtime information from other drones. • Key establishment: A newly added drone should be able to establish secure connection with its already existing neighbor drones or the GS S by creating shared secret keys with them. Furthermore, addition of a new drone is very much essential for access control in the IoD deployment. An access control method can be classified into two kinds based on their authentication type: a) certificate-less and b) certificate-based, as in the case of an IoT environment [24]. In this paper, to assure better security, we also combine the blockchain technology with the access control mechanism proposed in the IoD environment. 1.2. Research contributions The main contributions of this paper are listed below.

• Node authentication: This task should ensure that the newly placed drones in their respective flying zones authenticate themselves to their neighbor drones or the GS S

• We propose a new blockchain-based access control mechanism for the IoD environment using certificates issued 2

Journal Pre-proof

by the trusted CR. The proposed scheme allows mutual authentication and key establishment procedure in two ways: a) between two neighboring drones and b) between a drone and its associated GS S . The data securely accessed by the GS S are formed in various transactions. Next, the transactions are placed in a block and that block is verified and added in the blockchain maintained by the peer to peer (P2P) cloud server network with the help of the Ripple Protocol Consensus Algorithm (RPCA) [66].

point O, called zero point (or the point at infinity), and Zq = {0, 1, · · · , q−1}. The elliptic curve becomes non-singular if the condition 4m3 + 27n2 , 0 (mod q) is satisfied. Few properties of an elliptic curve are listed as follows [41].

lP repro of

• If P = (x1 , y1 ) and Q = (x2 , y2 ) are two points in Eq (m, n), then P + Q = O means x2 = x1 and y2 = −y1 .

• If P = (x1 , y1 ) is a point in Eq (m, n), then its additive inverse is represented as −P = (x1 , −y1 ) ∈ Eq (m, n). Here, x1 and y1 denote the x and y co-ordinates of the point P ∈ Eq (m, n), and −P is called the image of P.

• A rigorous formal security evaluation under the broadlyaccepted Real-Or-Random (ROR) random oracle model [1] has been conducted to show the proposed scheme achieves the session key (SK) security.

• Suppose P = (x1 , y1 ) be a point in Eq (m, n). Then P + O = O+ P = P, ∀P ∈ Eq (m, n). Eq (m, n) forms a abelian group (which is commutative in nature) under modulo q addition operation with the identity element O.

Jou

rna

• Next, the detailed informal (non-mathematical) security analysis also reveals that the proposed scheme can resist several other known attacks, such as replay, imperAn elliptic curve Eq (m, n) over Zq has almost q points on it. sonation, man-in-the-middle, Ephemeral Secret Leakage Hasse’s theorem asserts that the number of points on Eq (m, n), (ESL), privileged-insider and physical drones capture at- which is denoted by #E, satisfies the following inequality [61]: tacks. √ √ q + 1 − 2 q ≤ #E ≤ q + 1 + 2 q. • To strengthen security of the proposed scheme, a simulation-based formal security verification under Elliptic curve point addition: Let P = (xP , yP ) and Q = widely-used AVISPA tool [4] has been carried out to ev- (xQ , yQ ) ∈ Eq (m, n) are two points on an elliptic curve. Then, ident that the proposed scheme is also resilient against R = (xR , yR ) = P + Q is calculated as follows [42]: passive and active attacks. xR = (ξ2 − xP − xQ ) (mod q), • A detailed comparative analysis shows that the proyR = (ξ(xP − xR ) − yP ) (mod q),  yQ −yP posed scheme supports more functionality attributes and    xQ −xP (mod q), if P , −Q achieves better security, and also needs less communicawhere ξ =  2   3xP +m (mod q), if P = Q. tion and computational costs as compared to other rele2yP vant schemes in the domain of the IoD security. The special case P = Q is called as doubling the point and is presented as 2 · P. 1.3. Paper organization Elliptic curve point scalar multiplication: The scalar mulThe remainder of this paper is arranged as follows. In Sec- tiplication of an elliptic curve point under elliptic curve cryption 2, we discuss few mathematical concepts that are useful tography (ECC) is represented by s · P, where s is a scalar in understanding the proposed protocol. Section 3 highlights value. This multiplication task is achieved using repeated the related work in the IoD environment, which mainly focuses point doubling and addition operations. For example, supon access control and authentication protocols. The proposed pose P = (x , y ) ∈ E (m, n), then 17 · P is computed as P P q system’s models, specifically the network and threat models 17 · P = 2 · (2 · (2 · (2 · P))) + P using one point addition are discussed in Section 4. The detailed description of the pro- and four points doubling operations. posed scheme is then demonstrated in Section 5. A detailed security analysis is provided in Section 6. A formal security 2.2. Elliptic curve digital signature algorithm (ECDSA) verification of the proposed scheme under the AVISPA tool The “elliptic curve digital signature algorithm (ECDSA)” through the simulation study is presented in Section 7. The [36], [45] follows in a similar way to that for the “digital sigperformance analysis with the other state-of-art protocols are nature algorithm (DSA)” [37]. It has three phases: a) key genthoroughly studied in Section 8. Finally, the paper is concluded eration, b) signature generation and c ) signature verification, in Section 9. whose details are given below. 2. Mathematical preliminaries

2.2.1. Key generation The domain parameters for ECDSA involves elliptic curve In this section, we discuss the following preliminaries that E (m, n) over GF(q), and a base point G ∈ E (m, n) with order q q are essential to describe and understand the proposed scheme. n , that is, n · G = G + G + · · · + G (n times) = O. o o o Each entity A follows the following steps: 2.1. Elliptic curve and its properties • Pick a random number k in the interval [1, no − 1]. An elliptic curve y2 = x3 + mx + n over the finite field GF(q) is the set Eq (m, n) having the solutions (x, y) ∈ Zq × Zq to the congruence y2 ≡ x3 + mx + n (mod q), where q is a large prime and m, n ∈ Zq are two constant parameters, along with a unique

• Calculate the public Q = k · G. 3

• A’s public key and private key are respectively Q and k.

Journal Pre-proof

lP repro of

2.2.2. Signature generation The advantage of any 0/1-valued, probabilistic and For signing a message, say msg, a participant A with do- polynomial-time distinguisher ∆ in solving ECDLP on main parameters D = (q, no , Q, G, Eq (m, n), h(·)), where h(·) Eq (m, n) is presented as is a “collision-resistant one-way hash function” and the assoECDLP Adv∆,E = |Pr[(M, N, O) ← Dreal : q (m,n) ciated key pair (k, Q), does the following steps: ∆(M, N, O) = 1] • Step 1. Pick a random number lm with the criteria that −Pr[(M, N, O) ← Drandom : 1 ≤ lm ≤ no − 1. ∆(M, N, O) = 1]|, • Step 2. Calculate lm · G = (xm , ym ) and rm = xm (mod no ) where the probability Pr[·] is considered over the random seand check if rm = 0. If it is so, go to Step 1 again. lections of c and j. ∆ is said to be a (t, )-ECDLP distinguisher −1 ECDLP • Step 3. Calculate em = h(msg) and sm = lm (em + k ∗ rm ) for Eq (m, n) if ∆ runs at most time t with Adv∆,E (t) ≥ . q (m,n) (mod no ). If sm = 0, start again from Step 1. ECDLP assumption: There does not exist any (t, )-ECDLP • Step 4. Otherwise, A’s signature on msg is (rm , sm ). distinguisher for Eq (m, n). More precisely, for every 0/1valued, probabilistic and polynomial-time distinguisher ∆, it ECDLP 2.2.3. Signature verification has Adv∆,E (t) ≤ . q (m,n) A verifier B follows the following steps in order to check A’s signature (rm , sm ) on the received message msg with the Definition 2 (Elliptic curve discrete logarithm problem help of an authorized copy of A’s domain parameters D and (ECDLP)). Given an elliptic curve Eq (m, n) and two points R, S ∈ Eq (m, n), find an integer x such that S = x.R. the associated public key Q: • Check if both rm and sm are in the range [1, no − 1]. • Next, calculate em = h(msg).

• Calculate wm = s−1 m (mod no ), um1 = em ∗ wm (mod no ), um2 = rm ∗ wm (mod no ) and Xm = (xm1 , ym1 ) = um1 · G +um2 · Q. If Xm = O, discard the signature; otherwise, calculate vm = xm1 (mod no ). • Finally, accept the signature if and only if the criteria vm = rm is met.

rna

2.3. Computationally hard problems under ECC We discuss three well-known computationally hard problems under ECC below. Suppose Eq (m, n) be an elliptic curve over a finite field GF(q) and P ∈ Eq (m, n) be a point in it. The “elliptic curve discrete logarithm problem (ECDLP)” states that given two points P and Q ∈ Eq (m, n), where Q = c · P, to find the discrete logarithm c. Formally, the ECDLP can be defined as follows [22].

Note that the security of the ECC solely depends on the intractability of ECDLP. Although, there exist various algorithms to solve ECDLP, namely Pollard’s rho method [6], baby-step giant-step strategy [51], etc. But, these algorithms take exponential or sub-exponential execution time. Till date no algorithm exists in the literature to solve this problem in polynomial time. Beside ECDLP, there exist different computational hard problems, such as: a) “elliptic curve computational Diffie-Hellman problem (ECCDHP)” and b) “elliptic curve decisional Diffie-Hellman problem (ECDDHP)” related to ECC. Various authentication and key agreement protocols in the recent literature which are based on these two cryptographic hard problems. The formal definition of both ECCDHP and ECDDHP [62] are presented below. Definition 3 (Elliptic curve computational Diffie-Hellman problem (ECCDHP)). Let R is a point in Eq (m, n) and given two points i · R ∈ Eq (m, n) and j · R ∈ Eq (m, n) then compute (i · j) · R is computationally intractable, where i, j ∈ Zq∗ and Zq∗ = {1, 2, · · · , q − 1}.

Jou

Definition 1 (Elliptic curve discrete logarithm problem Definition 4 (Elliptic curve decisional Diffie-Hellman problem (ECDLP)). Let P ∈ Eq (m, n) and Q = c · P ∈ Eq (m, n) be (ECDDHP)). Let R is a point in Eq (m, n) and given a quadruple (R, i · R, j · R, k · R), decide whether k = (i · j) or a uniform two points, where c ∈R Zq . value, where i, j, k ∈ Zq∗ . Instance: (P, Q, j) for some c, j ∈R Zq . Remark 1. It is known that ECDLP, ECCDHP and ECDDHP are computationally intractable when q is large. More pre( cisely, the value of q should be selected at least 160-bit prime Yes, if Q = j · P, i.e., c = j Output: to ensure that ECDLP, ECCDHP and ECDDHP are computaNo, otherwise tionally infeasible. The notation i ∈R X is used to represent that i is randomly selected from the set X and Zq = {0, 1, 2, . . . , q − 1}. Now, take 2.4. One-way hash function two distributions as follows: A cryptographic one-way hash function h(·): X → Y is expressed as a deterministic mapping from a set X = {0, 1}∗ of Dreal = {c ∈R Zq , M = P, N = Q(= cP), variable length strings to another set Y = {0, 1}m of strings of O = c : (M, N, O)}, fixed length, say m bits. Here, a fixed length string of m bits Drandom = {c, j ∈R Zq , M = P, N = Q(= cP), is called message digest (or hash value). This one-way cryptoO = j : (M, N, O)}. graphic hash function has the following properties [53], [61]. 4

Journal Pre-proof

Jou

rna

lP repro of

• For any input a ∈ X, it is easy to compute h(a) in a polyGiven an element r ∈ Zq , we say that f (r, y) = Pt Pt Pt Pt u v u v nomial time. Due to the deterministic property of hash u=0 v=0 au,v r y (mod q) = u=0 v=0 (au,v r )y (mod q) is function, it is obvious that the function h(·) returns the a uni-variate polynomial in the variable y of the same degree t, same hash value for a distinct string. whose coefficients au,v ru ∈ Zq . If we apply the Horner’s rule [40], evaluation of the uni-variate polynomial f (r, y) at y = s 0 • For any change made in the input a, say a ∈ X would (that is, f (r, s)) requires t modular multiplications and t moduresult a separate uncorrelated random hash value (or mes- lar additions where s ∈ Z . q 0 sage digest) that means, h(a) , h(a ). 2.6. Blockchain consensus algorithms • It is computationally intractable to find the original string The blockchain is a series of blocks where each block conb, given the message digest h(b) of b ∈ X. This property is sists of a block header and block payload. In addition, each also termed as a one-way property or preimage resistance. block header contains block version, hash of the previous or • For any given input a ∈ X, it is computationally in- parent block, current block hash, Merkle tree root, timestamp, 00 00 tractable to find another a ∈ X such that h(a) = h(a ). and owner of the block, and each block payload also conThis property is termed as weak-collision resistant prop- tains a complete list of transactions [76]. The blockchain has been applied due to its decentralization, immutability, transerty or second preimage resistance. parency as well as persistence properties in the distributed peer • A collision in a one-way cryptographic hash function is to peer (P2P) network. There are three types of blockchain: 00 00 00 denoted as h(a) = h(a ) for any a, a ∈ X and a , a . a) public blockchain, b) private blockchain and c) consortium More precisely, the collision resistance property tells that blockchain. it is also computationally intractable to find any two input For addition of a block into the blockchain, a consensus 00 00 00 strings a, a ∈ X such that a , a with h(a) = h(a ). algorithm is needed. A consensus algorithm is a decision making algorithm in trust-less environment among untrustworthy In [53], the length of a message digest (say, n-bits) is pronodes in a distributed P2P network. Consensus represents the portional to the number of operations to compute the same distate in which nodes in the distributed network reach to an gest. Hence, for a fixed length n-bits message digest (or hash accurate agreement. For such an environment, it is very difoutput), it needs 2n operations to find a weak collision, and ficult task to reach a consensus. It is also a demanding job 2n/2 operations to pursue a strong collision with the help of the for blockchain technology as the blockchain network is disthird birthday attacks (or birthday paradox phenomenon). It is tributed. In the decentralization of blockchain, there is no also reported in [53], n ≥ 80 is beyond computational feasicentral node to ensure that all distributed nodes are trusted. bility for seeking weak collision by making brute-force attacks Thus, some consensus algorithms are essential to assure that with exhaustive search. In addition, n ≥ 160 is the necessary the ledgers in different nodes are consistent. There are several and sufficient size for strong collision resistance. consensus mechanisms in the blockchain, and some of them The formal definition of a one-way cryptographic hash are provided below for better understanding of the proposed function h(·) along with collision-resistant property [57] is scheme in the paper. given below. • Poof of Work (PoW): The PoW is a “compute-intensiveDefinition 5 (Collision-resistant one-way cryptographic hash based consensus algorithm” [34] that was used in Bitcoin function). Suppose an adversary A is running in time th in blockchain network proposed by Nakamoto et al. [56] finding the collision resistant of the hash function h(·) and in 2008. The main objective of the PoW is to prevent the HAS H AdvA (th ) corresponds to A’s advantage. It can be then cyber-attacks, such as “distributed denial of service attack expressed as (DDoS)”. In PoW, the mining process is very expensive HAS H for adding a new block in blockchain distributed ledger AdvA (th ) = Pr[(hs1 , hs2 ) ←R A : hs1 , hs2 , by making a consensus through solving difficult mathewith h(hs1 ) = h(hs2 )], matical (cryptographic) puzzles, known as proof of work problem. The new block will be added by the miner node where (hs1 , hs2 ) ←R A corresponds to the meaning that the to the blockchain only if the block is validated by the pair (hs1 , hs2 ) is randomly picked by A. An (ψ, th )-adversary other nodes in the P2P network after obtaining the conA attacking the “collision resistance of h(·)” means that A is HAS H sensus from them. In order to create and add a new block given at most time th so that AdvA (th ) ≤ ψ. in the blockchain, the miner needs to excessive computational resources for solving the puzzles. 2.5. Bivariate polynomial over finite field GF(q) • Proof of Stake (PoS): The PoS is an energy efficient “capability based consensus protocol”. In PoS, the miner does not require huge amount of computational resources in order to solve the difficult puzzles as compared to PoW [55]. In PoS, the miner will prove himself or herself as an owner in terms of currency. Under consideration, people having more currencies there is less probability to attack the P2P network. In PoS, the miner is called forger

A t-degree bi-variate polynomial defined over a finite field GF(q) in two variables x and y is of the form: f (x, y) = Pt Pt u v u=0 v=0 au,v x y (mod q), where the coefficients au,v are from the set Zq = {0, 1, · · · , q − 1}. Now, f (x, y) is said to be symmetric if f (x, y) = = f (y, x). For example, if we take a bivariate polynomial f (x, y) = 5x3 + 3xy + 6x2 y2 + 5y3 over the finite field GF(7), it is symmetric because f (x, y) = 5x3 + 3xy + 6x2 y2 + 5y3 = 5y3 + 3yx + 6y2 x2 + 5x3 = f (y, x). 5

Journal Pre-proof

and the process of mining is familiar with forging. At the initial stage of forging, every forger will deposit certain amount of owned currencies in the P2P network as a stake. After that a new forger will be select (“coin-age selection method” [39], [76]) for the next round based on the deposited currencies in the network. The highest values of the coin-age holder, called forger, will add the block in the blockchain. Coin-age is calculated for a particular forger by multiplying number of coins stakes by that forger and the number of holding days in the stake. Any malicious user may increase its chance of forging a block in the blockchain by possessing its coin for a long duration of time in the stake. To avoid this circumstance, stake-support period will be maximize by certain value by the algorithm. Once a new block is created and added to the blockchain by a particular forger, the staked coinvalue (i.e., coin-age of that forger) turns out to be zero.

nodes might be malicious or unreliable. This protocol provides liveness and safety with the condition that the number of faulty nodes in the network is n f < d−1 3 , that is, d > 3n f + 1, where d is the total participant nodes in the network. For adding a block in the blockchain, the following procedures are required:

lP repro of

– A leader acting as a miner will select by the leader selection algorithm for adding a block. – Leader receives a block with block adding request from any nodes (or client) into the blockchain. – Leader sends this block to every node in the network for verifying the transactions. – After successful verification of the transaction in the block, each received node sends a valid reply for adding that block. – Leader counts the received reply and checks the number of counts (say, RCount) if it is greater that the twice number of the faulty nodes, i.e., RCount > 2n f + 1 or the two-third nodes give the same reply. The 2n f + 1 non-faulty or valid replies provide the liveness of the system, that is, the message delay need to be bounded in due course. If this condition is satisfied, the leader will add the block into the blockchain and broadcasts a commit for adding the block into their respective blockchain for backup purposes.

rna

• Delegated Proof of Stake (DPoS): DPoS was introduced to overcome the situation in the PoS that becomes more richer than PoS [26]. In DPoS, the forger is selected by the election instead of possessed staked coin. Based on the election/voting, a group of nodes in the network (called witnesses or delegates) are chosen, whereas every node possesses some crypto-currency in the voting process. By a single vote for every witness, a node in the network can vote several witnesses. Instead of a single witness, N number of witnesses can be selected based on highest vote from forging all the blocks. The number of witnesses is selected if 50% of nodes in the network have voted for them. Every witness in the selected group of witnesses can mine a created new block in the blockchain in a “round-robin fashion” approach. The group of witnesses is changed after certain period of time. If any witness fails to construct a block in a particular time, the succeeding witness will be then selected from that group. Once all the witnesses in group are executed, the list is shuffled and then, the round robin process will continue. The aim of the shuffling is to avert vulnerability to attacks such that the succeeding miner is correctly proceed.

Jou

• Byzantine Fault Tolerance (BFT): BFT is a voting based consensus algorithm that applies a voting process to pick a miner for creating a block and also for adding the block in the blockchain. This protocol is used to remove the high energy utilization in the “compute-intensivebased protocols”. This protocol is designed in such a way that it can tolerate the Byzantine faults in the “Byzantine general problem” [43] over the untrusted distributed environment where some of the nodes can behave maliciously or they may be even unreliable. There are various protocols derived from BFT that include: (i) Practical Byzantine Fault Tolerance (PBFT), (ii) Delegated Byzantine Fault Tolerance (DBFT), and (iii) Federated Byzantine Agreement (FBA) [64], [76]. • Practical Byzantine Fault Tolerance (PBFT): PBFT was introduced in the year of 1999 by Castro et al. [11]. This is a voting-based consensus algorithm applied in asynchronous distributed network, where some of the

6

• Ripple Protocol Consensus Algorithm (RPCA): RPCA is a voting based consensus algorithm proposed in the literature in order to achieve high accuracy of a correct agreement for adding a block into a blockchain over unreliable distributed network [66]. RPCA achieves an agreement in the voting process. Every participant node in the voting process maintains a unique node list (UNL), where each node in the list is considered as trusted one. The protocol executes with the help of the following steps [66]: – In voting process, every participant node constantly receives the transaction. If the transaction is valid, the node integrates the transactions into a set or list, called a “candidate set”. – Every participant node dispatches its own candidate set to other participant node as a proposal. – The participant node receives the proposal from other nodes. The node will then check whether the sender node belongs to its UNL list or not. If it is there, the node will verify the transactions with its own local candidate set. If all are valid, the transactions will gain a vote. Only when the transaction gets more than 50% of vote, the transaction will enter into the next round. – Next, the participant node sends the transaction that it gains more than 50% of the votes than the others and if it increases to 60% of vote, it needs to wait until it reaches to the threshold of 80% of the votes. – Finally, the participant node records the transaction confirmed by the 80% UNL nodes to be added into its ledger data.

Journal Pre-proof

3. Related work

designed a secure device access control approach for IoT deployment. Their mechanism relies on both the concepts of certificates as well as signatures. Wazid et al. [68] discussed various security issues and related security attacks that can be mounted by an adversary in an IoD environment. They also provided a taxonomy of various security protocols needed for data security in IoD environment. Tian et al. [63] designed a privacy-preserving authentication mechanism in the IoD environment. Their method utilizes certificate-based signature approach. Their scheme permits four procedures: a) system initialization, b) IoD join, c) authenticated U2U communication, and d) pseudonym and key update. In the “IoD join” procedure, there are two types of join: level 1 join is executed by all the drones for receiving or sending messages in the network and level 2 join helps the drones which actively share their data in the network. The “authenticated U2U communication” procedure helps each “mobile edge computing (MEC)” device to maintain and also to broadcast the “public key broadcast list (PBL)” of that MEC device. However, their scheme is computationally heavy as it uses RSA-based digital signature approach. Wazid et al. [67] designed a lightweight user authentication mechanism in the IoD environment. Their approach permits a user to access the real-time data directly from a designated drone. Before permitting the data access, their scheme supports mutual authentication between user and drone. Srinivas et al. [60] also designed another “temporal credential based anonymous lightweight user authentication” scheme that can be easily deployed in the IoD environment. We also provide a summary of the existing related state-of-art access control protocols in IoD and related environments along with their cryptographic techniques used and their limitations/drawbacks in Table 1. It is worth noticing that none of the above designed schemes in the WSN, IoT and IoD environments support blockchain technology for providing superior security. To the best of our knowledge, this paper introduces a novel blockchain-based access control scheme in the IoD environment for the first time in the literature.

lP repro of

The transaction is accepted only if 80% of the votes in the UNL of a participant node agrees with it. Thus, 80% of the UNL is honest, that is, the percentage of the faulty nodes in the UNL is less that for the 20% of the UNL. When the UNL contains d number of nodes in the network, and the RPCA will maintain its correctness as long as n f ≤ d−1 5 , i.e., d ≥ 5n f + 1 where n f is the Byzantine failure persisted nodes in the network [14].

Jou

rna

In this section we review various security protocols proposed in the literature including the schemes for access control and authentication in the IoD environment. Access control and authentication are treated as primary security services in IoD environment as well as other networks, such as wireless sensor networks, IoT and smart grids [28], [29], [30]. A certificate-based access control method was designed by Zhou et al. [77] for wireless sensor network (WSN) environment. Their approaches utilizes the ECC technique and the certificates that are issued by a trusted authority. They applied the concept of the bootstrapping time to protect the malicious nodes to join later in the network after initial deployment of the nodes. Huang [32] independently designed an access control mechanism using the well-known Schnorr signature [58]. This scheme is also based on expiration time of sensing nodes. Unfortunately, Chatterjee et al. [17] showed that Huang’s approach was insecure against the “man-in-the-middle (MITM) attack”. By utilizing the one-way hash function and ECC technique, they also proposed an access control method in WSN that was able to resist several attacks including the MITM attack found in [32]. Later, a certificateless access control mechanism was suggested by Huang and Liu [33]. Their approach was based on both hash-chain as well as hash-chainless approaches. However, Kim and Lee [38] did cryptanalysis on Huang’s scheme [31] to show it fails to resist “replay attack”. Moreover, the scheme [31] can not support a mechanism for recreating the finished hash chain. To withstand those security pitfalls, Kim and Lee designed another access control method, called the “enhanced access control scheme (EACS)”. EACS provides the “hash chain renewal” process. Zeng et al. [73] further pointed out that Kim and Lee’s approach [38] suffers from two major drawbacks, namely: a) any newly added smart device can easily masquerade itself and b) an authorized registered smart device can also do “masquerading attack”. Li et al. [44] designed access control scheme for IoTenabled WSN environment using the concept of heterogeneous signcryption. However, due to involvement of identity-based cryptographic technique and bilinear pairings, their scheme is heavy from computation cost point of view. Luo et al. [49] also suggested an access control approach for WSN environment. Because their approach also relies on identity based cryptographic technique and bilinear pairings, this scheme is also computationally heavy as the scheme of Li et al. [44]. In addition, it is worth observing that all the access control approaches [9], [44], [49] involve the gateway node (base station) for achieving the access control process among any two neighboring IoT smart devices. Recently, Malani et al. [50]

4. System models In this section, we discuss the considered models required for the proposed scheme. 4.1. Network model A blockchain-based network model for IoT-enabled IoD environment provided in Figure 2 has been adapted in the design of the proposed scheme. According to the network model, the following entities exist: • Control Room (CR): The CR is a trusted authority who is responsible for registering all the deployed drones DR j and the ground station server (GS S ). • Ground Station Server (GSS): The GS S is responsible for controlling the drones in their respective flying zones. In addition, the GS S will collect the real-time data from

7

Journal Pre-proof

Table 1: Summary of limitations/drawbacks of the state-of-art existing access control schemes in IoT/IoD/sensor networking environments

Huang [31] Kim and Lee [38] Li et al. [44]

Luo et al. [49]

Tian et al. [63]

Wazid et al. [67] Srinivas et al. [60]

Description & Limitations/Drawbacks * Their access control mechanism is based using the well-known Schnorr signature [58] and expiration time of sensing nodes. * Their scheme is insecure against man-in-the-middle (MITM) attack. * This access control scheme is based on both hash-chain as well as hash-chainless approaches. * Their scheme does not support a mechanism for recreating the finished hash chain. * It also fails to resist replay attack. * Their scheme is enhancement over the scheme of Huang [31]. * In their scheme, any newly added smart device can easily masquerade itself, and also an authorized registered smart device can also do masquerading attack. * Their access control scheme is for IoT-enabled WSN environment that is based on heterogeneous signcryption. * Their scheme is expensive in computation due to involvement of identity-based cryptographic technique and bilinear pairing. * It involves the gateway node for achieving the access control process among any two neighboring IoT smart devices. * They proposed an access control scheme for WSN environment. * Their scheme is also expensive in computation due to involvement of identity-based cryptographic technique and bilinear pairing. * Furthermore, it involves the gateway node for achieving the access control process among any two neighboring IoT smart devices. * They designed a privacy-preserving authentication mechanism in the IoD environment that utilizes certificate-based signature approach. * Their scheme is computationally expensive due to RSA-based digital signature approach. * Their scheme does not support blockchain technology for providing superior security. * They proposed a lightweight user authentication mechanism in the IoD environment. * Their scheme does not support blockchain technology for providing superior security. * They designed a temporal credential based “anonymous lightweight user authentication” scheme in the IoD environment. * Their scheme does not support blockchain technology for providing superior security.

lP repro of

Scheme Huang [32]

Jou

rna

the drones DR j and form blocks containing the transac- goods in the intended destinations. For secure communications. The constructed blocks are then forwarded to the tion, we consider drone to drone (D2D) access control and also cloud server (CS l ). drone to GS S (D2GSS) access control methods. This will help to bring the data (information) securely at the GS S . • Cloud Server (CS l ): A cloud server CS l will act as leader among all the cloud servers in the P2P CS net- 4.2. Attack model work. Then, the leader is responsible for verifying and In this work, we consider two threat models that are briefly adding the blocks in the blockchain using the blockchain discussed below: consensus algorithm. • Dolev-Yao threat model: The broadly-applied “Dolev• Drone: A drone is an “unmanned aerial vehicle (UAV)” Yao (DY) threat model” [25] permits an adversary A which is an aircraft controlled remotely or by onboard not only can intercept the communicated messages in becomputers. The drones can navigate autonomously withtween communication, but also can modify and delete the out involvement of human control. A drone consists message contents, and even can push malicious contents of several IoT smart devices, such as “light-pulse disin the IoT-enabled IoD environment. In addition, under tance sensing (laser)”, “radio detection and ranging senthis model, the end-point communicating entities (in our sors”, “magnetic-field change sensing”, “sonar-pulse discase, drones) are not contemplated as trustworthy entities tance sensing (ultrasonic)”, “time of flight (ToF) sensors in the network. (range imaging)”, “thermal sensors”, “chemical sensors” • Canetti and Krawczyk (CK)-adversary model: The and “orientation sensors” [21]. The task performed by Canetti and Krawczyk’s model (CK-adversary model) each individual smart device is provided in [21]. [10] is one of the recently contemplated de facto modIn this model, the deployed area is partitioned into several disels that is applied in the proposed scheme. Under this joint clusters, called the flying zones. In each flying zone, say model, A not only can intercept, modify, delete or inFZi , there are drones that will fly in that zone only for servsert the messages as done in the DY model, but A can ing various purposes including monitoring and delivering the also compromise secret credentials, secret keys and also 8

Jou

rna

lP repro of

Journal Pre-proof

Figure 2: Blockchain-based network model for IoT-enabled IoD environment (adapted from [59])

session states in case these information are available in 5. The proposed blockchain-based access control scheme insecure memory of the drones during the access control This section provides a detailed treatment on the proposed phase [10]. blockchain-based access control scheme in IoT-enabled IoD deployment, called BACS-IoD. The system initialization phase In addition, it may not be always possible to monitor the de- of BACS-IoD provides the selection of all related system ployed drones in the 24 × 7 time. Hence, there is a possibility parameters like the elliptic curve and its base point, oneof physical capture of some drones. Using the extracted cre- way cryptographic hash function, consensus algorithm for dentials stored in the captured drones with the help of power blockchain, private and public keys of the trusted CR. In analysis attacks [54], A may attempt to mount other attacks, BACS-IoD, through the registration phase, the trusted CR ensuch as impersonation attacks. Furthermore, it is assumed that rols each drone in different flying zones FZi as shown in Figthe CR and GS S are fully trusted, whereas the cloud servers in ure 2. In addition, the CR also registers the GS S . During the the P2P CS network are semi-trusted. registration process, each drone and GS S are provided with 9

Journal Pre-proof

G k.G Q+R CR IDCR GS S IDGS S DRk IDDRk rCR PubCR CS rDRk PubDRk rGS S PubGS S f (x, y)

TC DRk TCGS S CertDRk CertGS S RT S DRk RT S GS S || TS x ∆T h(·) MKX E PubX FZi

a typical supposition applied in other kinds of networking environments too [12], [13], [23], [50], [69], [70]. For better understanding of the paper, we list the notations along with their significance in Table 2. Next, we describe the detailed description of each phase below. 5.1. System initialization phase In this phase, the CR picks the system parameters using the following steps:

lP repro of

Notation Eq (a, b)

Table 2: Notations and their significance Significance A non-singular elliptic curve of the form: “y2 = x3 + ax + b (mod q) with 4a3 + 27b2 , 0 (mod q)” A base point in Eq (a, b) whose order is no as big as q Elliptic curve point multiplication: k.G = G + G + · · · + G (k times) Elliptic curve point addition; Q, R ∈ Eq (a, b) Control Room (a trusted authority) Real identity of CR Ground Station Server Real identity of GS S kth drone Real identity of DRk Private key of CR Public key of CR, where PubCR = rCR · G Cloud Server Private key of DRk Public key of DRk , where PubDRk = rDRk · G Private key of GS S Public key of GS S , where PubGS S = rGS S · G A symmetric bivariate t-degree polynomial over the Galois field GF(q): P P f (x, y) = ti=0 tj=0 ai j xi y j , where ai j ∈ Zq = {0, 1, 2, · · · , q − 1} Temporal credentials of DRk Temporal credentials of GS S Certificates issued by the CR to DRk Certificates issued by the CR to GS S Registration timestamps issued by the CR to DRk Registration timestamps issued by the CR to GS S Concatenation operation “Current timestamp generated by an entity X” (i.e., DRk or GS S ) “Maximum transmission delay associated with a message” “Collision-resistant cryptographic one-way hash function” Master key issued by CR for an entity X Public key encryption/decryption by an entity X ith flying zone

• Step SI1. The CR first selects a “non-singular elliptic curve Eq (a, b) of the form: y2 = x3 + ax + b (mod q) over a finite field (Galois field) GF(q) with a point at infinity or zero point O and 4a3 + 27b2 , 0 (mod q), where q is a sufficiently large prime and a, b ∈ Zq = {0, 1, · · · , q − 1}”. Next, the CR picks a base point G ∈ Eq (a, b) whose order no is as big as q, that is, no · G = G + G + · · · + G (no times) = O, where k · G denotes the “elliptic curve point (scalar) multiplication of G added to itself k times”.

• Step SI2. The CR also picks a “collision-resistant oneway hash function” of the form: h : {0, 1}∗ → {0, 1}lh , which will take an “arbitrary length input string s ∈ {0, 1}∗ ” and produce the “fixed-length lh output string h(s) ∈ {0, 1}lh ”, known as “message digest or hash output”. For sufficient security, SHA-256 hashing function [52] is preferred in blockchain technology.

• Step SI3. The CR chooses a private key rCR ∈ Zq∗ and calculates its respective public key PubCR = rCR · G. Finally, the CR keeps its private key rCR and publishes the parameters {Eq (a, b), G, h(·), PubCR } as public. Further, the CR chooses its identity as IDCR .

Jou

rna

5.2. Registration phase Initially, a trusted authority (specifically, the Control Room (CR)) enrols all the drones (DRs) and their associated Ground Station Server (GS S ). The detail description of the enrollment the necessary pre-loaded information prior to their deployment phase for individual drone and GS S are discussed as follows. and they apply those information for mutual (node) authentication and key establishment of secret keys with the help of the 5.2.1. Drone registration access control phase. Sometimes, some drones could be physThe step-wise illustration of jth drone DR j registration proically compromised as discussed in our threat model in Section cess is given below. 4.2 or even they can fail due to malfunctioning. This necessitates addition of new drones in the existing IoD environment • Step DR1: CR chooses a master key MKDR j for each dethrough the dynamic drones addition phase. ployed DR j in a particular flying zone, say FZi . CR also selects a unique identity IDDR j , and computes a privateAfter collecting the data securely by the GS S , it proceeds public key pair as {rDR j ∈ Z∗q , PubDR j = rDR j · G}. for creating various transactions, and then it will form a block containing the encrypted transactions. The generated block is • Step DR2: CR computes DR j ’s temporal credential as then passed to one of the cloud severs in the P2P cloud server TC DR j = h(MKDR j ||IDDR j ||IDCR ||IDGS S ||RT S DR j ). CR network, who will be responsible for adding that block in the also creates a certificate on the private key rDR j of DR j as blockchain after applying the well-known consensus algorithm CertDR j = rDR j + h(PubDR j ||IDGS S ||PubCR ) ∗ rCR (mod q), using the block construction and addition by cloud servers where ∗ denotes the ordinary modular multiplication opphase. We have applied the “Ripple Protocol Consensus Alerator. gorithm (RPCA)” [75]. To protect the replay attacks, we utilized both the random • Step DR3: For each FZi , CR selects a distinct t-degree numbers as well as current system timetamps so that the old symmetric bivariate polynomial of the form fi (x, y) = Pt Pt u v replayed messages can be easily detected by the respective reu=0 v=0 au,v x y (mod q) over GF(q) = Zq such that cipients. To achieve this goal, it is assumed that all the involved t  number of drones deployed in FZi . Next, CR comentities in the network are synchronized with their clocks. It is putes the polynomial share fi (IDDR j , y) for DR j . 10

Journal Pre-proof

Thus, the registration of DR j has been accomplished. After successful registration of the drone DR j with the CR, the available credentials stored in DR j ’s memory are shown in Figure 3. IDDR j , IDGS S {PubDR j , PubGS S , PubCR } TC DR j , CertDR j fi (IDDR j , y)

• Step DDACS2: After receiving the message msgD2D1 0 0 from DR j1 at time T S j1 , the drone DR j2 verifies if |T S j1 − T S j1 | < ∆T or not. If the condition is true, the DR j2 proceeds with Step DDACS3; otherwise, it drops the message. • Step DDACS3: DR j2 verifies the certificate of DR j1 as

lP repro of

?

CertDR j1 ·G = PubDR j1 +h(PubDR j1 ||IDGS S || PubCR )·PubCR by utilizing the known domain parameters (i.e., public information). If the certificate is verified successfully, the DR j1 is believed to be legitimate principal and go to Step DDACS3; else, it rejects DR j1 ’s request.

Figure 3: Pre-loaded credentials in DR j

5.2.2. GSS registration The step-wise illustration of the GS S registration process is also given below.

• Step GR1: CR selects a private key rGS S ∈ Z∗q and computes its public key PubGS S = rGS S · G for the GS S . CR also chooses a unique identity IDGS S for GS S .

• Step GR2: Furthermore, CR creates a certificate on rGS S as CertGS S = rGS S + h(PubGS S ||IDGS S ||PubCR ) ∗ rCR (mod q). In addition, CR also computes a temporal credential of GS S as TCGS S = h(IDGS S ||IDCR ||rGS S ||RT S GS S ), and the polynomial share fi (IDGS S , y) for the GS S . After successful registration of the GS S with CR, the available credentials stored in the GS S are shown in Figure 4.

rna

(IDDR1 , · · · , IDDRnm ) IDGS S {PubDR j , PubGS S , PubCR } TCGS S , CertGS S fi (IDGS S , y) ∀i = 1, 2, · · · , m

Figure 4: Pre-loaded credentials in GS S

5.3. Access control phase

Jou

In this phase, we provide two kinds of access control mechanisms: a) access control between drones and b) access control between a drone and the GS S . At the end of access control, both the communicating entities will be able to establish secret key for secret communication. The following subsections provide the details. 5.3.1. Drone to drone (D2D) access control The session key establishment process followed by a mutual authentication task between two neighbor drones, say DR j1 and DR j2 , is summarized in Figure 5. The step-wise illustration of the same task is elaborated as follows. • Step DDACS1: DR j1 generates a random number r j1 ∈ Z∗q and picks current timestamp of the system as T S j1 . DR j1 also computes a j1 = h(IDDR j1 ||TC DR j1 ||r j1 ||T S j1 ) and A j1 = a j1 · G (a random point in Eq (a, b)). DR j1 constructs a message msgD2D1 = {IDDR j1 , A j1 , CertDR j1 , T S j1 }, and sends it to DR j via a public channel.

11

• Step DDACS4: DR j2 generates a random number r j2 ∈ Z∗q and picks the current timestamp T S j2 . Then, DR j2 computes four different parameters, namely b j2 = h(IDDR j2 ||TC DR j2 || r j2 ||T S j2 ), B j2 = b j2 · G (a random point in Eq (a, b)), DK j2 j1 = b j2 · A j1 and fi (IDDR j2 , IDDR j1 ), respectively. Further, DR j2 computes a session key and its respective session key verifier as S KDR j2 ,DR j1 = h(DK j2 j1 || fi (IDDR j2 , IDDR j1 )|| CertDR j1 ||CertDR j2 || T S j1 ||T S j2 ), and S KV j2 j1 = h(S KDR j2 ,DR j1 ||B j2 ||T S j2 ||IDDR j2 ), and goes to Step DDACS5. • Step DDACS5: DR j2 constructs a message msgD2D2 = {IDDR j2 , B j2 , S KV j2 j1 , T S j2 , CertDR j2 } and sends it to DR j1 via a public channel. • Step DDACS6: After getting the massage msgD2D2 at time 0 0 T S j2 , DR j1 checks if |T S j2 − T S j2 | < ∆T or not. If the condition is true, DR j2 proceeds with Step DDACS7; otherwise, it rejects the response message of DR j2 . • Step DDACS7: DR j1 verifies the certificate (CertDR j2 ) of DR j2 by checking the condition: CertDR j2 · G = PubDR j2 + h(PubDR j2 ||IDGS S ||PubCR ) ·PubCR . If the certificate is verified successfully, DR j2 is believed to be legitimate principal and go to Step DDACS8; else, DR j1 rejects DR j2 ’s response. • Step DDACS8: DR j1 computes two different parameters, namely DK j1 j2 = a j1 · B j2 and fi (IDDR j1 , IDDR j2 ). Further, DR j1 computes a session key S KDR j1 ,DR j2 = h(DK j1 j2 || fi (IDDR j1 , IDDR j2 )|| CertDR j1 ||CertDR j2 || T S j1 ||T S j2 ) and a session key verifier S KV j1 j2 = h(S KDR j1 ,DR j2 ||B j2 ||T S j2 ||IDDR j2 ), and goes to Step DDACS 9. • Step DDACS9: DR j1 verifies that if the generated session key verifier S KV j1 j2 and the received session key verifier S KV j2 j1 are equal or not. If both are equal, DR j2 is believed to be legitimate entity and DR j1 goes to Step DDACS10; otherwise, DR j1 rejects DR j2 ’s response. • Step DDACS10: DR j1 picks the current timestamp as T S ∗j1 , and computes ACK j1 j2 = h(S KDR j1 ,DR j2 ||T S ∗j1 ). Next, DR j1 constructs a message msgD2D3 = {ACK j1 j2 , T S ∗j1 }, and sends the same message to DR j2 via a public channel. • Step DDACS11: After getting the message msgD2D3 at ∗∗ time T S ∗∗ j1 , DR j2 verifies that if the condition |T S j1 − ∗ T S j1 | < ∆T is true or not. If the condition returns true,

Journal Pre-proof Drone DR j1 {IDDR j1 , TC DR j1 , CertDR j1 }

lP repro of

Generate a random number r j1 ∈ Z∗q Choose a current timestamp T S j1 Compute a j1 = h(IDDR j1 ||TC DR j1 ||r j1 ||T S j1 ) and A j1 = a j1 · G msgD2D1 = {IDDR j1 , A j1 , CertDR j1 , T S j1 } −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ (via a public channel)

Drone DR j2 {IDDR j2 , TC DR j2 , CertDR j2 }

0

Check if |T S j1 − T S j1 | < ∆T ? Accept/Reject Verify certificate CertDR j1 as ?

CertDR j1 · G = PubDR j1 + h(PubDR j1 ||IDGS S ||PubCR ) · PubCR Accept/Reject Generate a random number r j2 ∈ Z∗q Pick a current timestamp T S j2 Compute b j2 = h(IDDR j2 ||TC DR j2 ||r j2 ||T S j2 ), B j2 = b j2 · G, DK j2 j1 = b j2 · A j1 , fi (IDDR j2 , IDDR j1 ), session key S KDR j2 ,DR j1 = h(DK j2 j1 || fi (IDDR j2 , IDDR j1 ) ||CertDR j1 ||CertDR j2 ||T S j1 ||T S j2 ), session key verifier S KV j2 j1 = h(S KDR j2 ,DR j1 ||B j2 ||T S j2 ||IDDR j2 ) msgD2D2 = {IDDR j2 , B j2 , S KV j2 j1 , T S j2 , CertDR j2 } ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− (via a public channel)

0

Check if |T S j2 − T S j2 | < ∆T ? Accept/Reject Verify certificate CertDR j2 as ?

?

rna

CertDR j2 · G = PubDR j2 + h(PubDR j2 ||IDGS S ||PubCR ) · PubCR Accept/Reject Compute DK j1 j2 = a j1 · B j2 , fi (IDDR j1 , IDDR j2 ), session key S KDR j1 ,DR j2 = h(DK j1 j2 || fi (IDDR j1 , IDDR j2 ) ||CertDR j1 ||CertDR j2 ||T S j1 ||T S j2 ), session key verifier S KV j1 j2 = h(S KDR j1 ,DR j2 ||B j2 ||T S j2 ||IDDR j2 )

Jou

Verify S KV j1 j2 = S KV j2 j1 Accept/Reject Pick a current timestamp T S ∗j1 Compute ACK j1 j2 = h(S KDR j1 ,DR j2 ||T S ∗j1 ) msgD2D3 = {ACK j1 j2 , T S ∗j1 } −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ (via a public channel)

∗ Check if |T S ∗∗ j1 − T S j1 | < ∆T ? Accept/Reject Compute ACK j2 j1 = h(S KDR j2 ,DR j1 ||T S ∗j1 ) ?

Verify ACK j2 j1 = ACK j1 j2 Accept/Reject Store shared secret session key S KDR j1 ,DR j2 (= S KDR j2 ,DR j1 ) between drones DR j1 and DR j2 Figure 5: Summary of access control message exchanges between drones DR j1 and DR j1

DR j2 accepts DR j1 ’s request message; otherwise, it drops If the equality holds, DR j1 is believed to be legitimate the same message. Further, DR j2 computes ACK j2 j1 = principal to DR j2 ; otherwise, DR j2 rejects the request h(S KDR j2 ,DR j1 ||T S ∗j1 ) and checks if the computed acmessage of DR j1 . knowledgment parameter (i.e., ACK j2 j1 ) is equal to the reThus, the mutual authentication and session key agreement ceived acknowledgment parameter (i.e., ACK j1 j2 ) or not. process is accomplished between two drones DR j1 and DR j2 . 12

Journal Pre-proof

Meanwhile, both DR j1 and DR j2 establish a secure channel between themselves through a symmetric session key S KDR j1 ,DR j2 (= S KDR j2 ,DR j1 ).

• Step DGACS8: DRk picks the current timestamp T S ∗DRk , calculates ACKDRk ,GS S = h(S KDRk ,GS S ||T S ∗DRk ), constructs a message msgD2G3 = {ACKDRk ,GS S , T S ∗DRk } and sends the message msgD2G3 to GS S via open channel.

lP repro of

5.3.2. Drone to GSS (D2GSS) access control The proposed access control process between kth drone (DRk ) and the GS S is summarized in Figure 6. The step-wise discussion of this access control mechanism is elaborated as follows.

Next, DRk verifies if the computed session key verifier S KVDRk ,GS S and the received session key verifier S KVGS S ,DRk match or not. If both match each other, GS S is believed to be a legitimate entity; otherwise, GS S ’s response message is rejected.

• Step DGACS1: DRk generates a random number rDRk ∈ Z∗q and picks the current timestamp T S DRk . DRk computes aDRk = h(IDDRk ||TC DRk ||rDRk ||T S DRk ) and ADRk = aDRk · G (a random point in Eq (a, b)). DRk also constructs a message msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk }, and sends it to the GS S via open channel.

• Step DGACS9: After getting the message msgD2G3 at time ∗∗ ∗ T S ∗∗ DRk , GS S verifies the condition: |T S DRk − T S DRk | < ∆T . If the condition is valid, GS S accepts DRk ’s request message; otherwise, it drops the message. Further, GS S calculates ACKGS S ,DRk = h(S KGS S ,DRk || T S ∗DRk ) and verifies if the issued acknowledgment parameter (i.e., ACKGS S ,DRk ) is same as the received acknowledgment (i.e., ACKDRk ,GS S ) or not. If the equality holds, DRk is believed to be a legitimate principal to GS S ; otherwise, the session is terminated.

• Step DGACS2: After receiving the message msgD2G1 0 from DRk at time T S DRk , GS S verifies if the criteria 0 |T S DRk − T S DRk | < ∆T satisfies or not. If the condition holds, GS S proceeds to Step DGACS3; otherwise, At the end of this phase, both DRk and GS S create a secure it drops the message msgD2G1 . channel between themselves through the established symmet• Step DGACS3: GS S verifies the certificate of DR as ric session key S KDRk ,GS S (= S KGS S ,DRk ). ?

k

CertDRk · G = PubDRk + h(PubDRk ||IDGS S ||PubCR ) · PubCR by utilizing the known domain public parameters. If the certificate is verified successfully, DRk is believed to be legitimate principal to GS S , and GS S goes to Step DGACS4; else, GS S rejects DRk ’s request.

•

•

rna

•

Jou

•

5.4. Dynamic drones addition phase It is a noteworthy fact that for any accidental reasons (e.g., low battery and internal circuit failure) or physical capturing of drones by an adversary, if a drone of a particular flying zone fails to provide its intended services (or non operational), it is Step DGACS4: GS S selects a random number rGS S 1 ∈ Z∗q necessary to re-deploy another drone at the same flying zone. and picks the current timestamp T S GS S . Then, GS S com- In order achieve this, the proposed scheme has the capability putes the parameters: bGS S = h(IDGS S ||TCGS S ||rGS S 1 of dynamic drone addition phase. The step-wise description of ||T S GS S ), BGS S = bGS S · G, DKGS S ,DRk = bGS S · ADRk this phase is illustrated below. and fi (IDGS S , IDDRk ). Further, GS S computes a ses• Step DDA1: For a new unregistered drone DRnew to be sion key and its verifier as S KGS S ,DRk = h(DKGS S ,DRk deployed in a particular flying zone FZi , CR chooses a || fi (IDGS S , IDDRk ) ||CertDRk ||CertGS S ||T S DRk ||T S GS S ) master key MKDRnew and a unique identity IDDRnew and and S KVGS S ,DRk = h(S KGS S ,DRk ||BGS S ||T S GS S ||IDGS S ), computes the private-public key pair as {rDRnew ∈ Z∗q , and executes Step DGACS5. In addition, GS S conPubDRnew = rDRnew · G}. structs a message msgG2D2 = {BGS S , S KVGS S ,DRk , T S GS S , • Step DDA2: CR computes DRnew ’s temporal credenCertGS S } and sends it to DRk via open channel. tial as TC DRnew = h(MKDRnew ||IDDRnew || IDCR ||IDGS S || RT S DRnew ). CR also creates a certificate on the private Step DGACS5: After getting the message msgG2D2 at time 0 0 key rDRnew of DRnew as CertDRnew = rDRnew + h(PubDRnew || T S GS S , DRk verifies if the condition |T S GS S − T S GS S | < ||IDGS S ||PubCR ) ∗rCR (mod q). ∆T holds or not. If it holds, DRk proceeds with Step DGACS6; otherwise, it rejects the response message of • Step DDA3: CR also selects the already generated GS S . t degree symmetric bivariate polynomial fi (x, y) = Pt Pt u v u=0 v=0 au,v x y (mod q) over GF(q) corresponding Step DGACS6: DRk verifies the certificate (CertGS S ) of to FZi . Next, CR calculates the polynomial share GS S by checking the following condition: CertGS S · G = fi (IDDRnew , y) for DRnew . PubGS S + h(PubGS S || IDGS S ||PubCR ) · PubCR . If the certificate is valid, GS S is believed to be legitimate princi• Step DDA4: CR finally loads the credentials in DRnew as pal by DRk and Step DGACS7 is executed; else, GS S ’s shown in Figure 7. In addition, CR also sends the credenresponse is rejected. tials IDDRnew securely to the GS S so that the GS S will store the received information corresponding to the newly Step DGACS7: DRk calculates DKDRk ,GS S = aDRk · added drone DRnew . BGS S , fi (IDDRk , IDGS S ), a session key S KDRk ,GS S = h(DKDRk ,GS S || fi (IDDRk , IDGS S ) ||CertDRk ||CertGS S At the end, the CR declares PubDRnew as public. Furthermore, ||T S DRk ||T S GS S ) shared with GS S , and its verifier CR will broadcast all the existing drones in the flying zone FZi S KVDRk ,GS S = h(S KDRk ,GS S || BGS S ||T S GS S || IDGS S ). about the deployment of the new drone DRnew . 13

Journal Pre-proof Ground Station Server GS S {IDGS S , TCGS S , CertGS S }

lP repro of

Drone DRk {IDDRk , TC DRk , CertDRk } Generate a random number rDRk ∈ Z∗q Choose current timestamp T S DRk Compute aDRk = h(IDDRk ||TC DRk ||rDRk ||T S DRk ), ADRk = aDRk · G msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk } −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ (via a public channel)

0

Check if |T S DRk − T S DRk | < ∆T ? Accept/Reject Verify certificate CertDRk as ?

CertDRk · G = PubDRk + h(PubDRk ||IDGS S ||PubCR ) · PubCR Accept/Reject Generate a random number rGS S 1 ∈ Z∗q Pick current timestamp T S GS S Compute bGS S = h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ), BGS S = bGS S · G, DKGS S ,DRk = bGS S · ADRk , fi (IDGS S , IDDRk ), session key S KGS S ,DRk = h(DKGS S ,DRk || fi (IDGS S , IDDRk ) ||CertDRk ||CertGS S ||T S DRk ||T S GS S ), session key verifier S KVGS S ,DRk = h(S KGS S ,DRk ||BGS S ||T S GS S ||IDGS S ) msgG2D2 = {BGS S , S KVGS S ,DRk , T S GS S , CertGS S } ←−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− (via a public channel)

0

Check if |T S GS S − T S GS S | < ∆T ? Accept/Reject Verify certificate CertGS S as ?

?

rna

CertGS S · G = PubGS S + h(PubGS S ||IDGS S ||PubCR ) · PubCR Accept/Reject Compute DKDRk ,GS S = aDRk · BGS S , fi (IDDRk , IDGS S ), session key S KDRk ,GS S = h(DKDRk ,GS S || fi (IDDRk , IDGS S ) ||CertDRk ||CertGS S ||T S DRk ||T S GS S ), session key verifier S KVDRk ,GS S = h(S KDRk ,GS S ||BGS S ||T S GS S ||IDGS S ) Verify S KVDRk ,GS S = S KVGS S ,DRk Accept/Reject Pick current timestamp T S ∗DRk Compute ACKDRk ,GS S = h(S KDRk ,GS S ||T S ∗DRk ) msgD2G3 = {ACKDRk ,GS S , T S ∗DRk } −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−→ (via a public channel)

Jou

∗ Check |T S ∗∗ DRk − T S DRk | < ∆T ? Accept/Reject Compute ACKGS S ,DRk = h(S KGS S ,DRk ||T S ∗DRk ) ?

Verify ACKGS S ,DRk = ACKDRk ,GS S Accept/Reject Store shared secret session key S KDRk ,GS S (= S KGS S ,DRk ) between drone (DRk ) and GS S Figure 6: Summary of access control message exchanges between drone DRk and GS S

5.5. Block construction and addition in blockchain

5.5.1. Block construction by GS S

In this section, we provide the details of creating a block by the GS S and then verifying that block by the P2P CS network. After successful, consensus among the cloud servers in the P2P CS network, the block is added in the existing blockchain.

In our proposed scheme, the data are exchanged securely among the drones in each flying zone FZi using the established session keys S K j1 j2 during the D2D access control phase. Moreover, the information are also collected securely by the GS S using the established session key S KDRk ,GS S among a

14

Journal Pre-proof IDDRnew , IDGS S {PubDRnew , PubGS S , PubCR } TC DRnew , CertDRnew fi (IDDRnew , y)

the voting mechanism. We assume that each cloud server CS in the P2P CS network will have an ECC-based private-public key pair, say (rCS , PubCS ), where PubCS = rCS · G, and all the public keys of other cloud servers are also available to the CS . Algorithms 1 and 2 illustrate this process.

Figure 7: Loaded credentials in DRnew

6. Security analysis

lP repro of

Block Header Block Version BVer Previous Block Hash PBHash Merkle Tree Root MR Timestamp TR Owner of Block OB Public Key of Owner PubGS S Flying Zone Number FZi Block Payload (Encrypted Transactions) Encrypted Transaction #1 E PubGS S (T x1 ) Encrypted Transaction #2 E PubGS S (T x2 ) .. .. . .

In this section, we first give the correctness of the proposed scheme’s session key establishment between two drones, and also between a drone and the GS S . Based on the important observations by Wang et al. [65], it is important to include all kinds of security analysis while analyzing a security protocol. For this purpose, we provide the formal security analysis and then the informal (non-mathematical) security analysis to evident the proposed scheme can resistant various potential attacks against both passive and active adversaries.

6.1. Correctness proof Intuitively, for a particular session, the two communicating parties need to share the same session key between themselves. In Theorem 1, we show the correctness proof of the established Figure 8: Formation of a block Blocki on the transactions by GS S session key between two drones DR j1 and DR j2 in a particular flying zone FZi . Similarly, in Theorem 2, we also show the drone DRk and the GS S . After that the GS S forms the transac- correctness proof of the established session key between a DRk tions of the collected data. Let T x1 , T x2 , · · · , T xnt be the trans- and its associated GS S belonging to a flying zone FZi . actions formed during a session by the GS S . The formation of a block, say Blocki containing the transactions T x1 , T x2 , Theorem 1. The session keys generated by two drones DR j1 · · · , T xnt is shown in Figure 8. We have used the blockchain and DR j2 in a particular flying zone FZi are the same. as private due to confidential and secret information. The steps Proof. According to the proposed access control mechanism, involved in forming the block Blocki are given below: for a particular session, the drone DR j2 computes the session • All the transactions are encrypted using a public key en- key with its neighbor drone DR j1 as S KDR j2 ,DR j1 = h(DK j2 j1 || cryption E(·) with the help of the public key PubGS S (in fi (IDDR j2 , IDDR j1 )|| CertDR j1 || CertDR j2 || T S j1 || T S j2 ) and DR j1 also calculates the session key as S KDR j1 ,DR j2 = h(DK j1 j2 || our case, we use the ECC encryption). fi (IDDR j1 , IDDR j2 )|| CertDR j1 || CertDR j2 || T S j1 ||T S j2 ). To show, • Next, the encrypted transactions E PubGS S (T xi ), (i = S KDR j1 ,DR j2 = S KDR j2 ,DR j1 , it suffices to prove that DK j2 j1 = 1, 2, · · · , nt ), are used in calculating the Merkle tree root DK j1 j2 and fi (IDDR j2 , IDDR j1 ) = fi (IDDR j1 , IDDR j2 ). It is worth noticing the following: (MR) by constructing the Merkle tree. E PubGS S (T xnt ) CBHash BS ign

rna

Encrypted Transaction #nt Current Block Hash Signature on Block using ECDSA

Jou

• The hash of the information {BVer, PBHash, MR, T R, OB, PubGS S , FZi , block payload (encrypted transactions)} is calculated, which is called the current hash blcok (CBHash).

• Calculate the ECDSA signature, say BS ign = (rm , sm ) on the message msg = CBHash using the signature generation algorithm provided in Section 2.2.2.

DK j2 j1

= =

b j2 · A j1

(h(IDDR j2 ||TC DR j2 ||r j2 ||T S j2 ) ∗

h(IDDR j1 ||TC DR j1 ||r j1 ||T S j1 )) · G

= h(IDDR j1 ||TC DR j1 ||r j1 ||T S j1 ) ·

(1)

(h(IDDR j2 ||TC DR j2 ||r j2 ||T S j2 ) · G)

= a j1 · B j2

= DK j1 j2 . Once the block, Blocki is constructed by the GS S , the same Furthermore, since fi (x, y) is a bivariate symmetric polynoblock is forwarded to a cloud server (CS ) that exists in the mial over GF(q), it also follows that P2P CS network. fi (IDDR j2 , IDDR j1 ) = fi (IDDR j1 , IDDR j2 ). (2) 5.5.2. Block verification and addition using consensus algoUsing Eqs. (1) and (2), we have the following: rithm by P2P CS network Once a block Blocki is received by a cloud server CS from S KDR j2 ,DR j1 = h(DK j2 j1 || fi (IDDR j2 , IDDR j1 )||CertDR j1 || the GS S , the cloud server will select a leader, say L among CertDR j2 ||T S j1 ||T S j2 ) all the available cloud servers in the P2P CS network. For = h(DK j1 j2 || fi (IDDR j1 , IDDR j2 )||CertDR j1 || this purpose, we use the leader selection algorithm as provided CertDR j2 ||T S j1 ||T S j2 ) in [74]. Next, we apply the “Ripple Protocol Consensus Algorithm (RPCA)” [66] for block verification and addition through = S KDR j1 ,DR j2 . 15

Journal Pre-proof Algorithm 2 Consensus for block verification and addition in blockchain (Continued...) 26: for each received RMsgl from the responders CS l do 27: L computes (PZl0 , VS tatus) = DrL [E PubL (PZl∗ , VS tatus)]. 28: if ((PZl0 = PZl ) and (VS tatus = valid) and ( f lagCS l = 0)) then 29: L sets VTCount = VTCount + 1 and f lagCS l = 1. 30: end if 31: end for 32: if (VTCount is more than 50% of the votes) then 33: Transaction enters the next round. 34: if (VTCount less than the threshold value, that is, 80% of the votes) then 35: go to Step 26. 36: else 37: Send the commit response to all other followers CS l . Add block Blocki to the blockchain and terminate the consensus process. 38: end if 39: end if

Theorem 2. The session keys generated by a drone DRk and the GS S in a particular flying zone FZi are also the same.

Proof. For a particular session, DRk computes a session key as S KDRk ,GS S = h(DKDRk ,GS S || fi (IDDRk , IDGS S )|| CertDRk || CertGS S ||T S DRk || T S GS S ) and GS S also calculates the session key as S KGS S ,DRk = h(DKGS S ,DRk || fi (IDGS S , IDDRk )|| CertDRk || CertGS S ||T S DRk || T S GS S ). We need to prove that S KGS S ,DRk = S KDRk ,GS S . It follows that S KGS S ,DRk

= h(DKGS S ,DRk || fi (IDGS S , IDDRk )||

CertDRk ||CertGS S ||T S DRk ||T S GS S )

= h(bGS S · ADRk || fi (IDGS S , IDDRk )|| =

CertDRk ||CertGS S ||T S DRk ||T S GS S )

h(h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ·ADRk || fi (IDGS S , IDDRk )||CertDRk ||

Jou

rna

lP repro of

Algorithm 1 Consensus for block verification and addition in blockchain Input: Blocki = {BVer, PBHash, MR, T R, OB, PubGS S , FZi , {E PubGS S (T x s ) |s = 1, 2, · · · , nt }, CBHash, BS ign}; privatepublic key pairs (rCS l , PubCS l = rCS l · G) for all other cloud servers CS l in the P2P CS network. Output: Verification and addition of block in the blockchain 1: Leader (L) has a block Blocki = {BVer, PBHash, MR, T R, OB, PubGS S , FZi , {E PubGS S (T x s ) |s = 1, 2, · · · , nt }, CBHash, BS ign}. 2: L sets VTCount ← 0, where VTCount is the vote counter. L also sets f lagCS l = 0, ∀{l = 1, 2, · · · , ncs , L , CS l }, where ncs is the number of cloud servers in the P2P CS network. 3: L creates a mathematical puzzle PZl and a current timestamp T S l for each of the cloud server, say CS l . 4: L encrypts the puzzle PZl with the public key PubCS l of each CS l as E PubCS l (PZl , T S l ). 5: L sends the message S Msgl = {Blocki , E PubCS (PZl , T S l ), l T S l } to all other cloud servers CS l , (l = 1, 2, · · · , ncs , L , CS l ). 6: Let S Msgl be received from L by each CS l in the P2P CS network at time T S l∗ . 7: for each cloud server CS l do 8: if (|T S l − T S l∗ | < ∆T ) then 9: Compute the Merkle tree root, MR∗ on the encrypted transactions {E PubGS S (T x s ) |s = 1, 2, · · · , nt }. 10: if (MR∗ , MR) then 11: Terminate the consensus process. 12: else 13: Calculate block hash CBHash∗ on the received block Blocki as CBHash∗ = h(BVer|| PBHash|| MR∗ || T R|| OB|| PubGS S || FZi || E PubGS S (T x1 )|| E PubGS S (T x2 )|| · · · ||E PubGS S (T xnt )). 14: if (CBHash∗ = CBHash) then 15: Verify the signature BS ign = (rm , sm ) on Blocki using the message msg = CBHash∗ with the help of ECDSA signature verification stated in Section 2.2.3. 16: if signature is verified successfully then 17: Decrypt the encrypted puzzle using precalculated private key rCS l as (PZl∗ , T S l0 ) = DrCS l [E PubCS l (PZl , T S l )] by applying the ECC decryption algorithm. 18: if (T S l0 = T S l ) then 19: Send the block verification message containing verification status (VS tatus) and solved puzzle as RMsgl = {E PubL (PZl∗ , VS tatus)} to the leader L. 20: end if 21: end if 22: end if 23: end if 24: end if 25: end for

=

CertGS S ||T S DRk ||T S GS S )

h((h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ∗aDRk ) · G|| fi (IDGS S , IDDRk )||

=

CertDRk ||CertGS S ||T S DRk ||T S GS S )

h((h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ∗h(IDDRk ||TC DRk ||rDRk ||T S DRk )) · G || fi (IDGS S , IDDRk )||CertDRk

= =

||CertGS S ||T S DRk ||T S GS S )

h(DKDRk ,GS S || fi (IDDRk , IDGS S )

||CertDRk ||CertGS S ||T S DRk ||T S GS S )

S KDRk ,GS S ,

as fi (IDGS S , IDDRk ) = fi (IDDRk , IDGS S ) and DKDRk ,GS S = DKGS S ,DRk .

16

Journal Pre-proof

Table 3: Queries and their purposes

Query a2 1 Execute(ΦaDR , ΦGS S) 1 CorruptDrone(ΦaDR )

lP repro of

Reveal(Φa )

Purpose Applying this query, A can eavesdrop the messages exchanged between the drones DR and GS S Applying this query, A is allowed to extract “secret credentials stored in memory of a stolen or lost DR” Applying this query, A can reveal a session key (the session key S KGS S ,DRk (= S KDRk ,GS S ) between DRk and the GS S or the session key S KDR j1 ,DR j2 (= S K j2 j1 ) between drones DR j1 and DR j2 ) shared between Φa and its respective partner Applying this query, A is permitted to appeal Φa for checking the originality of a session key, and Φa can supply a “random outcome of a flipped unbiased coin, say c”

T est(Φa )

6.2. Formal security analysis under ROR model The wide-accepted “Real-Or-Random (ROR) oracle model” [1] has been applied to manifest that the proposed scheme is secure for deriving the session-key between a drone (DRk ) and a ground station server (GS S ), as well as the session key between two drones DR j1 and DR j2 against an adversary A. For achieve this target, we first explore the ROR model with the help of semantic security approach, and then the session key security (SK-security) of the proposed “blockchain-based access control scheme in IoT-enabled IoD deployment (BACS-IoD)” in Theorem 3. A will execute all the queries tabulated in Table 3. Moreover, as explained in [13], access to a “collision-resistant one-way cryptographic hash function h(·)” is also provided to all the participants including A, and consequently, h(·) can be modeled as a random oracle, say HO. The ROR model is correlated with the following elements:

Definition 6 (Semantic security). If we represent BACS −IoD AdvA (t p ) as A’s advantage who runs in polynomial time t p for breaking the semantic security of BACS-IoD in order to derive the session key S KGS S ,DRk (= S KDRk ,GS S ) between DRk and the GS S or the session key S KDR j1 ,DR j2 (= S K j2 j1 ) between drones DR j1 and DR j2 , BACS −IoD AdvA (t p ) = |2Pr[c0 = c] − 1|. Here, c and c0 present the “correct” and “guessed” bits, respectively.

Theorem 3. Suppose an adversary A tries to derive the session key S KGS S ,DRk (= S KDRk ,GS S ) between DRk and the GS S or the session key S KDR j1 ,DR j2 (= S K j2 j1 ) between drones DR j1 and DR j2 in polynomial time t p in the proposed BACS-IoD. If ECDDHP qh , |Hash|, and AdvA (t p ) represent “the number of HO queries”, “the range space of a one-way collision-resistant hash function h(·)”, and “the advantage of breaking the Elliptic Curve Decisional Diffe-Hellman Problem (ECDDHP)”, respectively,

rna

• Participants. At the time of the access control phase, the entities, namely the drones (DR) and the GS S are engaged apart from the CR that is only involved during the 1 registration and dynamic drone addition phases. ΦaDR and a2 ΦGS S are used to represent the a1 and a2 instances of DR and GS S , respectively. These instances are termed as the “random oracles”.

BACS −IoD AdvA (t p ) ≤

q2h ECDDHP + 2AdvA (t p ). |Hash|

Jou

Proof. The proof of this theorem is followed in similar way as that was provided in [13], [23], [50], [59], [70]. Three games, say GameA l for the adversary A are needed, l = 0, 1, 2. If S uccA indicates “an event that A can guess the random bit Gamel c in the game GameA • Accepted state. When the last valid protocol message is l correctly”, A’s advantage is winning A BACS −IoD a Game in BACS-IoD can be then expressed as AdvA,Game = accepted, the instance Φ will go to its “accepted state”. If l l A all the sent and received messages can be arranged in se- Pr[S uccGamel ]. In the following, we now elaborate each game. quentially, they together form the “session identification sid of Φa for the currently executed session”. • GameA : This game permits A to execute the “actual at0 tack” against BACS-IoD under the ROR model. A needs • Partnering. Two instances (Φa1 and Φa2 ) are said to be to pick a random bit c before GameA 0 begins. The semanpartners to each other, if the following three properties are tic security defined in Definition 3 produces the result as valid: given below: – Φa1 and Φa2 need to be in “accepted states”. a1

BACS −IoD BACS −IoD AdvA (t p ) = |2AdvA,Game − 1|. 0

a2

– Φ and Φ need to share the same sid. – Φa1 and Φa2 are “mutual partners of each other”. a2 1 • Freshness. An instance ΦaDR or ΦGS S is fresh, if A cannot determine the established session key shared between two participating entities using the Reveal(Φa ) query exhibited in Table 3.

The “semantic security” of the proposed scheme (BACSIoD) is provided in Definition 6 prior to prove Theorem 3. 17

(3)

• GameA : In this game, an eavesdropping attack is simu1 lated by A who can use the Execute query shown in Table 3 to intercept all the communicated messages during the access control phase. A will be then allowed to intercept all the transmitted messages msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk }, msgG2D2 = {BGS S , S KVGS S ,DRk , T S GS S , CertGS S }, and msgD2G3 = {ACKDRk ,GS S , T S ∗DRk } and try to construct the session key S KGS S ,DRk (= S KDRk ,GS S ).

Journal Pre-proof

In a similar way, A can also eavesdrop all the communicated messages between two drones DR j1 and DR j2 : msgD2D1 = {IDDR j1 , A j1 , CertDR j1 , T S j1 }, msgD2D2 = {IDDR j2 , B j2 , S KV j2 j1 , T S j2 , CertDR j2 } and msgD2D3 = {ACK j1 j2 , T S ∗j1 }.

BACS −IoD |AdvA,Game 1

− ≤

BACS −IoD AdvA,Game | 2

q2h ECDDHP + AdvA (t p ). 2|Hash|

lP repro of

Now, A needs to validate whether the derived session key is a correct one or just a random key with the help of Reveal and T est queries. Note that S KGS S ,DRk = h(DKGS S ,DRk || fi (IDGS S , IDDRk ) ||CertDRk ||CertGS S ||T S DRk ||T S GS S ) = h(DKDRk ,GS S || fi (IDDRk , IDGS S ) ||CertDRk ||CertGS S ||T S DRk ||T S GS S ) = S KDRk ,GS S , where DKGS S ,DRk = bGS S ·ADRk = h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ·ADRk = h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ·(aDRk ·G) = (h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ∗h(IDDRk ||TC DRk ||rDRk ||T S DRk )) ·G = (h(IDDRk ||TC DRk ||rDRk ||T S DRk ) ∗h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S )) ·G = h(IDDRk ||TC DRk ||rDRk ||T S DRk ) ·(h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ) ·G) = aDRk · BGS S = DKDRk ,GS S . In addition, S KDR j1 ,DR j2 = h(DK j1 j2 || fi (IDDR j1 , IDDR j2 )|| CertDR j1 ||CertDR j2 || T S j1 ||T S j2 ) = h(DK j2 j1 || fi (IDDR j2 , IDDR j1 )|| CertDR j1 ||CertDR j2 || T S j1 ||T S j2 ) = S KDR j2 ,DR j1 . Since all the temporal and long term secrets are protected by h(·), only interception of the messages msgD2G1 , msgG2D2 , and msgD2G3 , msgD2D1 , msgD2D2 and msgD2D3 will not at all contribute in increasing the success probability for calcuA lating session keys. GameA 0 and Game1 turn out to be indistinguishable in the presence of the eavesdropping attack. This leads to the following:

birthday paradox for finding the hash collision and the advantage of solving ECDDHP, the following relation is obtained:

BACS −IoD BACS −IoD AdvA,Game = AdvA,Game . 1 0

(4)

Jou

rna

• GameA : This game corresponds to an active at2 tack, where we include the simulations of HO and CorruptDrone queries, and ECDDHP. To derive the session key S KGS S ,DRk (= S KDRk ,GS S ) or S KDR j1 ,DR j2 (= S KDR j2 ,DR j1 ), A needs to derive DKGS S ,DRk (= DKDRk ,GS S ) and also DK j1 j2 (= DK j2 j1 ). Suppose A has already all the intercepted messages msgD2G1 , msgG2D2 , msgD2G3 , msgD2D1 , msgD2D2 and msgD2D3 . From the intercepted ADRk = h(IDDRk ||TC DRk ||rDRk ||T S DRk ).G and BGS S = h(IDGS S ||TCGS S ||rGS S 1 ||T S GS S ).G to derive DKGS S ,DRk (= DKDRk ,GS S ), A needs to solve the ECDDHP (see Definition 4) in time t p which has advantage probaECDDHP bility AdvA (t p ). Similarly, A’s advantage in solving the ECDDHP to derive DKDR j1 j2 (= DKDR j2 j1 ) from the inECDDHP tercepted A j1 and B j2 will be again AdvA (t p ). Furthermore, other secrets (TCGS S , TC DRk , TC DR j1 and TC DR j2 ) are embedded in h(·). Also, the hash values are random due to timestamps and random numbers used in each message during communication of a session.

(5)

Because all the queries are already made by A, and it is only remaining for A to correctly guess a bit for winning the game GameA 2 . Therefore, it is obvious that BACS −IoD AdvA,Game = 2

1 . 2

(6)

Eq. (3) gives

1 1 BACS −IoD BACS −IoD AdvA (t p ) = |AdvA,Game − |. 0 2 2

(7)

Eqs. (4), (5) and (6), and the triangular inequality will lead to the following derivation: 1 BACS −IoD AdvA (t p ) = 2 =

≤

BACS −IoD BACS −IoD |AdvA,Game − AdvA,Game | 0 2

BACS −IoD BACS −IoD |AdvA,Game − AdvA,Game | 1 2

q2h ECDDHP + AdvA (t p ). 2|Hash|

(8)

Finally, multiplying both sides of Eq. (8) by “a factor of 2”, the final result is arrived: BACS −IoD AdvA (t p ) ≤

q2h ECDDHP + 2AdvA (t p ). |Hash|

6.3. Informal security analysis This section presents the informal security analysis of the proposed scheme, BACS-IoD. In this connection, we informally (non-mathematically) show that BACS-IoD is resilient against various well-known attacks. Proposition 1. BACS-IoD is resilient against drone impersonation attack. Proof. Let an adversary A try to behave himself/herself as a legitimate drone DRk , and he/she wants to construct an autho0 0 0 rized message, say msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk }. In order to perform this operation, A needs to select a ran0 0 dom number rDRk and a timestamp T S DRk , and then to com0 0 0 pute ADRk = h(IDDRk || TC DRk || rDRk || T S DRk ) · G. To make the impersonation attack viable, A needs to calculate TC DRk = h(MKDRk || IDDRk || IDCR || IDGS S || RT S DRk ). However, without knowing the parameters, namely MKDRk and RT S DRk , it is computationally hard to compute TC DRk . Hence, BACS-IoD is resilient against drone impersonation attack.

In addition, using the CorruptDrone query, A will have the credentials that will be useful in deriving the session keys because it is also essential to have random secrets and temporal credentials of the GS S as well as other noncorrupted drones. It is worth noticing that both GameA 1 and GameA 2 are indistinguishable if we exclude the simulation of Hash and CorruptDrone queries, and solving Proposition 2. BACS-IoD is resilient against GS S impersonECDDHP becomes easy problem. Using the results of ation attack. 18

Journal Pre-proof

T S j1 ) · G. On the other hand, DR j1 also calculates the session key S KDR j1 ,DR j2 shared with DR j2 as S KDR j1 ,DR j2 = h(DK j1 j2 || fi (IDDR j1 , IDDR j2 )|| CertDR j1 || CertDR j2 || T S j1 || T S j2 ), where DK j1 j2 = h(IDDR j1 ||TC DR j1 ||r j1 ||T S j1 ) · B j2 and B j2 = h(IDDR j2 ||TC DR j2 ||r j2 ||T S j2 ) · G. From Theorem 2, it follows that S KDR j1 ,DR j2 (= S KDR j2 ,DR j1 ). Similarly, a distinct session key S KDRk ,GS S (= S KGS S ,DRk ) is shared between a drone DRk and the GS S . It can be easily observed from Section 5.3 that the “session key” is the combination of both session-specific (ephemeral) credentials (also called as “short term secrets”), such as random numbers and timestamps, and the “long-term secrets” (temporal credentials and master keys). The session key S KDR j1 ,DR j2 can only be revealed when an adversary A would compromise both the session-specific as well as long-term secrets. Moreover, usage of random numbers and timestamps in computation of session keys between DR j1 and DR j2 , and also between DRk s and GS S over different sessions make always unique session keys. Even if a session key is disclosed for a specific session, it will not result in computing the session keys over other sessions due to usage of both short and long term secrets. Therefore, BACS-IoD is secure against “sessiontemporary information attack” and it also preserves the “perfect forward and backward secrecy” property. Hence, BACSIoD is secure against “ESL attack”.

lP repro of

Proof. Suppose an adversary A tries to act himself/herself as a legitimate ground station server (GS S ), and he/she 0 wants to construct a valid message, say msgG2D2 = 0 {BGS S , S KVGS S ,DRk , T S GS S , CertGS S }. To do so, A can ini0 0 tially select a random number rGS S 1 and a timestamp T S GS S , and then try to compute BGS S = bGS S · G = h(IDGS S || 0 0 TCGS S || rGS S 1 || T S GS S ) · G and S KVGS S ,DRk = h(S KGS S ,DRk || 0 BGS S ||T S GS S ||IDGS S ). However, to make the impersonation attack feasible, A requires to calculate the temporal credential of the GS S as TCGS S = h(IDGS S ||IDCR ||rGS S ||RT S GS S ) first. However, without knowing the parameters rGS S and RT S GS S , it is computationally hard to calculate TCGS S , bGS S , and S KVGS S ,DRk . Hence, BACS-IoD is also resilient against GS S impersonation attack. Proposition 3. BACS-IoD is resilient against replay attack.

Proof. The messages msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk }, msgG2D2 = {BGS S , S KVGS S ,DRk , T S GS S , CertGS S }, msgD2G3 = {ACKDRk ,GS S , T S ∗DRk }, msgD2D1 = {IDDR j1 , A j1 , CertDR j1 , T S j1 }, msgD2D2 = {IDDR j2 , B j2 , S KV j2 j1 , T S j2 , CertDR j2 } and msgD2D3 = {ACK j1 j2 , T S ∗j1 } are transmitted over insecure channel during the “D2D access control phase” and “D2GSS access control phase” as described in Section 5.3. Note that, during each message construction, both the timestamps and random numbers (or nonces) are concatenated along with the messages. Also, these timestamps are checked by the receiver-end (or transmitter-end) for verifying the freshness of the messages. Since an adversary A cannot forge the actual timestamp, replaying the past valid messages is then eventually detected either by the sender (or receiver) side. Therefore, BACS-IoD is resilient against “replay attack”.

rna

Proposition 4. BACS-IoD is secure against man-in-the-middle attack.

Proof. During drone registration phase (Section 5.2.1) and GS S registration phase (Section 5.2.2), neither a drone nor the GS S sends registration information to the trusted CR. Instead the CR generates all the credentials for each drone and the GS S prior to their deployment in the IoD environment. This restricts a privileged-insider user of the CR, being an adversary, can not get any information that are pre-loaded in the memory of the drones as well as the GS S . Therefore, the question of privileged-insider attack does not arise in the proposed scheme, BACS-IoD. Proposition 7. BACS-IoD supports mutual authentication between any two neighbor drones, and also between a drone and its associated GS S .

Jou

Proof. Suppose an adversary A eavesdrops the drone access control request message msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk } from a public channel (see Section 5.3.1), and tries 0 to construct another valid message, say msgD2D1 on the fly so that the GS S sitting at the receiver-end can not detect it as a modified message. Since A does not have the pre-loaded secret credentials TC DR j1 and rDR j1 , so he/she cannot produce the valid message msg0D2D1 . Similarly, A also fails to create a 0 valid GS S request message msgD2G1 for the intercepted message msgD2G1 = {IDDRk , ADRk , CertDRk , T S DRk } without having the pre-stored secret credentials TC DRk and rDRk , and the shared session key S K ji . Moreover, A can not modify the “acknowledgment message” msgD2D3 = {ACK j1 j2 , T S ∗j1 } due to the construction of the authentic secret shared session key S K j1 j2 between two intended drones. Thus, BACS-IoD is secure resilient the “man-in-the-middle attack”.

Proposition 6. BACS-IoD is resilient against privilegedinsider attack.

Proof. During D2D access control phase as discussed in Section 5.3.1, a drone DR j2 verifies its neighbor drone DR j1 ’s legitimacy before establishment of a session key. In this connection, DR j2 first checks the freshness of DR j1 ’s messages by validating the timestamps received in the messages. Later, DR j2 verifies the certificate of DR j1 by the condition: CertDR j1 · G = PubDR j1 + h(PubDR j1 ||IDGS S ||PubCR ) · PubCR . If both the conditions are validated successfully, DR j2 forms a session key with DR j1 . In the similar way, DR j1 also estabProposition 5. BACS-IoD is resilient against Ephemeral Se- lishes a session key with DR j2 . Moreover, both DR j1 and DR j2 validate the session key verifiers. Once the session key verifier cret Leakage (ESL) attack. is checked successfully, both DR j1 and DR j2 ensure that they Proof. In D2D access control phase, a drone DR j2 computes share the same session key. Consequently, BACS-IoD supports the session key S KDR j2 ,DR j1 shared with its neighbor drone mutual authentication. DR j1 as S KDR j2 ,DR j1 = h(DK j2 j1 || fi (IDDR j2 , IDDR j1 )|| CertDR j1 || CertDR j2 || T S j1 || T S j2 ), where DK j2 j1 = b j2 · A j1 = h(IDDR j2 || Proposition 8. BACS-IoD is resilient against physical drone TC DR j2 || r j2 || T S j2 ) · A j1 and A j1 = h(IDDR j1 || TC DR j1 || r j1 || capture attack. 19

Journal Pre-proof

AVISPA [4] is treated as a “push-button tool for the automated validation of Internet security protocols as well as applications” that supports a “modular as well as expressive formal language for specifying protocols along with their security properties”. It also unites various back-ends that execute a heterogeneity of state-of-the-art automatic analysis methods. There are four back-ends which are implemented in AVISPA: “On-the-fly mode-checker (OFMC)”, “Constraintlogic-based Attack Searcher (CL-AtSe)”, “SAT-based Model Checker (SATMC)” and “Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP)”. The details of these back-ends can be found in [4]. The tested protocols need to be implemented using the “HighLevel Protocol Specification Language (HLPSL)”. The code written in HLPSL is then converted into the “Intermediate Format (IF)” using the HLPSL2IF translator, which is fed into one of the available four backends to get the “Output Format (OF)”. The OF has the following sections:

lP repro of

Proof. Due to hostile environment, there may be possibility to physical capture of some drones by an adversary A as described in our threat model (Section 4.2). Then, A can pull out all the stored data {IDDRk , IDGS S , {PubDRk , PubGS S , PubCR }, TC DRk , CertDRk , fi (IDDRk , y)} from the compromised drone DRk using the “power analysis attacks” [54]. The secret credentials {IDDRk , TC DRk , CertDRk , fi (IDDRk , y)} stored in DRk are distinct and unique from the credentials stored in other drones and the GS S . Again, each bivariate polynomial fi (x, y) is of degree t and t is chosen by the CR such that t  number of drones deployed in FZi . Therefore, if the adversary A can compromise less than t number of drones in a flying zone FZi , he/she can not construct the original polynomial fi (x, y) using the Lagrange’s interpolation. As a result, compromise of the secrets stored in DRk can not effect establishment of the session keys among other non-compromised drones, and also non-compromised drones and the GS S . In other words, non-compromised drones can still communicate with 100% securely. This phenomenon is known as “unconditionally secure and t-collusion resistant against drone capture attack”. Thus, BACS-IoD is also resilient against “physical drone capture attack”.

• SUMMARY section specifies that “whether the tested protocol is safe, unsafe, or whether the analysis is inconclusive”. • DETAILS section “either explains under what condition the tested protocol is declared safe, or what conditions have been used for finding an attack, or finally why the analysis was inconclusive”.

Proposition 9. Block verification is supported in BACS-IoD.

Jou

rna

Proof. In BACS-IoD, the block addition by the peers in the P2P CS network is based on the well-known “Ripple Protocol Consensus Algorithm (RPCA)”. Suppose a verifier, say V wants to verify a block Blocki = {BVer, PBHash, MR, T R, OB, PubGS S , FZi , {E PubGS S (T x s ) |s = 1, 2, · · · , nt }, CBHash, BS ign} in the blockchain. For this goal, V needs to compute the Merkle tree root, MR∗ on the encrypted transactions {T x s |s = 1, 2, · · · , nt }. If the computed MR∗ does not match with the stored MR, V rejects the Blocki . Otherwise, V needs to calculate block hash CBHash∗ on the received block Blocki as CBHash∗ = h(BVer|| PBHash|| MR∗ || T R|| OB|| PubGS S || FZi || E PubGS S (T x1 )|| E PubGS S (T x2 )|| · · · ||E PubGS S (T xnt )). If the computed CBHash∗ mismatches with the stored CBHash, V rejects the Blocki . Otherwise, V proceeds to verify the block signature BS ign = (rm , sm ) using the ECDSA signature verification algorithm discussed in Section 2.2.3. Thus, it is worth noticing that for verifying a block in the blockchain, three-level verification process is executed. In addition, it is not possible to update or modify information in a block, delete a block or even insert a fake block in the blockchain due to fact that the previous block hash is included in the next block hash value computation. 7. Formal security verification under AVISPA tool: simulation study In this section, we provide the formal security verification using the broadly-accepted automated software tool, known as “Automated Validation of Internet Security Protocols and Applications (AVISPA)” [4]. In recent years, formal security verification using automated software tools has gained a huge popularity among the researchers in the security domain. There are several formal security verification tools, such as: a) AVISPA [4], b) ProVerif [8], and c) Scyther [20].

• PROTOCOL, GOAL and BACKEND sections are “the name of the protocol, the goal of the analysis and the name of the back-end used”, respectively. • Finally, “trace of an attack (if any)” is also displayed in the standard Alice-Bob format after some comments along with statistics.

On the other sides, ProVerif [8] is an “automatic symbolic protocol verifier that supports a wide range of cryptographic primitives, defined by rewrite rules or by equations”. Various security attributes, such as authentication, secrecy and process equivalences can be proved through this tool for “an unbounded message space and an unbounded number of sessions”. Scyther [20] supports a “graphical user interface (GUI)” which accompaniments the “command-line” and “Python scripting interfaces”. This tool containing the “command-line” and “scripting interfaces” makes its utilization for “large-scale protocol verification tests”. The main feature provided in Scyther is that it assures termination whilst permitting to prove “correctness of protocols for an unbounded number of sessions”, and it alternatively produce the output as the proof tree with the help of its backend. In this paper, we consider AVISPA tool over other tools, such as ProVerif and Scyther as AVISPA is most widely-used formal security verification tool in the recent years [12], [15], [16], [23], [50], [59], [69], [70]. We have implemented the proposed scheme for three basic roles: the role for drone, the role for the GS S and the role for the CR. In addition, the mandatory roles for the session, goal & environment are also defined in the proposed scheme. In HLSPL implementation, the topmost role (environment) specifies the global constants along with a composition of one or more sessions. The intruder (i)

20

Journal Pre-proof

lP repro of

can also take participation as some roles as legitimate entities. 8. Comparative analysis Furthermore, the intruder takes part in the protocol execution In this section, we provide a meticulous comparative study as a “concrete session”. More detailed analysis on HLPSL can to show how the proposed scheme outperforms other closely be also found in [4]. related recent schemes in the IoD environment, such as the schemes of Li et al. [44], Luo et al. [49], Malani et al. [50] and Tian et al. [63]. For this goal, we consider communication and computation costs comparisons, and also security and functionality features comparison. Table 6: Comparison of computation costs

Protocol

Malani et al. [50]

Luo et al. [49]

Smart device/Drone cost 6T ecm + 7T h /8T h +2T eca ≈ 81.012 ms

GSS/Server cost −

T bp + T h

3T ecm + 3T bp + 3T h + T eca + T e ≈ 23.149 ms

≈ 32.769 ms

Li et al. [44]

Figure 9: Simulation results of the proposed scheme under OFMC and CLAtSe backends

T bp + T h

≈ 32.769 ms

Tian et al. [63]

Table 4: Comparison of communication costs

No. of messages 2 2 2 2 3 3

Total cost (in bits) 2240 3040 3488 384s + 11712 1888 1728

Proposed

8T e + 9T h ≈ 18.496 ms

−

5T h + 4T ecm + T eca +T poly ≈ (53.981 + 0.008t) ms

5T h + 4T ecm + T eca +T poly ≈ (8.708 + 0.001t) ms

Note: t: degree of a bivariate polynomial over finite field GF(q) in the proposed scheme (BACS-IoD)

rna

Protocol Malani et al. [50] Luo et al. [49] Li et al. [44] Tian et al. [63] Proposed (D2D access control) Proposed (D2GSS access control)

3T ecm + 4T bp + T h + 2T eca ≈ 28.236 ms

Jou

Note: s: number of pseudonyms of an UAV (drone) in Tian et 8.1. Communication cost comparison al.’s scheme [63] In the direction of communication cost computation, we consider all the access control messages between two drones DR j1 and DR j2 , and also between a drone DRk and the GS S . It Table 5: Execution costs (in milliseconds) for various cryptographic primitives is assumed that an identity, a random number (nonce), times[71] tamp, an elliptic curve point and hash value (if SHA-256 is apEntity T ecm T eca Th Tm T bp Te plied for blockchain technology) require 160 bits, 160 bits, 32 Drone (Mobile device) 13.405 0.081 0.056 0.008 32.713 2.249 GSS (Server) 2.165 0.013 0.007 0.001 5.427 0.339 bits, (160 + 160) = 320 bits and 256 bits, respectively. Moreover, it is assumed that a message size in the schemes of Luo Next, we have then simulated the proposed under the et al. [49] and Li et al. [44] is 1024 bits. In addition, it is “Security Protocol ANimator for AVISPA (SPAN)” tool [5]. assumed that 160-bit ECC will provide the same security level The detailed simulation results are illustrated in Figure 9. as compared to that for 1024-bit RSA public key cryptosystem Since AVISPA implements the “Dolev-Yao threat model (DY [7].

model)” [25], the intruder (i) not only can eavesdrop the communicated messages, but can also delete, modify or insert the illegal message contents in between the communication. Under OFMC backend, the simulation needed 4752 milliseconds (ms) with 3608 nodes and 9 plies of depth. Also, under CLAtSe backend, the simulation analyzed 1614 states and out of those states, 149 states were reachable, and it took the translation time of 0.05 seconds and computation time of 0.18 seconds. The simulation results clearly show that the proposed scheme is secure against both “replay” and “man-in-themiddle” attacks.

21

• Communication cost involved during D2D access control phase: The communication overhead required for msgD2D1 is (160 + 320 + 160 + 32) = 672 bits, msgD2D2 is (160 + 320 + 256 + 32 + 160) = 928 bits, and msgD2D3 is (256 + 32) = 288 bits, respectively. So, the total number of bits needed is 1888 bits. • Communication cost involved during D2GSS access control phase: The communication cost required for msgD2G1 is (160 + 320 + 160 + 32) = 672 bits, msgG2D2 is (320 + 256 + 32 + 160) = 768 bits, and msgD2G3 is

Journal Pre-proof

Table 7: Comparison of functionality & security attributes

Luo et al. [49] X X × X X X X × X × × × ×

Li et al. [44] X X × X X X X × X × × × ×

Malani et al. [50] X X X X X X X X X X X X ×

Tian et al. [63] X X × X X N/A X X × × × X ×

Proposed (BACS-IoD) X X X X X X X X X X X X X

lP repro of

Attribute (ATB) AT B1 AT B2 AT B3 AT B4 AT B5 AT B6 AT B7 AT B8 AT B9 AT B10 AT B11 AT B12 AT B13

AT B1 : replay attack; AT B2 : man-in-the-middle attack; AT B3 : mutual authentication; AT B4 : key agreement; AT B5 : device/drone impersonation attack; AT B6 : GSS/server impersonation attack; AT B7 : malicious device deployment attack; AT B8 : resilience against drone/device physical capture attack; AT B9 : formal security verification using AVISPA tool; AT B10 : formal security analysis; AT B11 : ESL attack under the CK-adversary model; AT B12 : support dynamic drone/device addition phase; AT B13 : support blockchain-based solution X: “a scheme is secure or it supports an attribute”; ×: “a scheme is insecure or it does not support an attribute”; N/A: not applicable in a scheme.

rna

(256+32) = 288 bits, respectively. Thus, the total number uni-variate polynomial requires t modular multiplications and of bits needed is 1728 bits. t modular additions (see Section 2.5), that is, T poly = tT m + tT a ≈ tT m ignoring modular addition operation. In Table 4, a comparative study on communication costs during access control process among the proposed scheme • Scenario 1 (D2D access control phase): It can easily be (BACS-IoD) and other existing schemes has been conducted. observed from Fig. 5 that a drone needs to invest a total In Tian et al. [63]’s scheme, we consider only the access conamount of 5T h + 4T ecm + T eca + T poly time which is aptrol phases for the IoD level 1 join and level 2 join. Among all proximately (53.981 + 0.008t) milliseconds. It is worth the compared schemes, it is worth observing that the scheme noticing that the degree t of a bivariate polynomial is choof Tian et al. [63] requires highest communication cost. Howsen in such a way that the number of deployed drones in a ever, the proposed BACS-IoD needs low communication cost flying zone is much lesser than t. For instance, if t = 100, during both D2D and D2GSS access control phases as comthe total computation cost required for a drone becomes pared to all other existing schemes. 54.781 milliseconds. 8.2. Computation cost comparison

Jou

In order to compute the computation cost for individual principal, we consider the following two scenarios. We denote the time needed for an ECC point addition, an ECC point multiplication, a t-degree polynomial evaluation, a cryptographic one-way hash function, a bilinear pairing operation, a modular multiplication operation and a modular exponentiation operation as T eca , T ecm , T poly , T h , T bp , T m and T e , respectively. We utilize the existing experimental results reported by Wu et al. [71]. As in [71], we also consider a “personal computer (Dell TM R with an Intel Core i5-4460S@ 2.90GHz processor, 4GB main memory and the Window 8 operating system)” as the server or the GS S , and a “personal mobile device (Samsung Galaxy S5 with a Quad-core 2.45G processor, 2GB memory and the Google Android 4.4.2 operating system)” as the drone or smart device. Based on the results in [71], Table 5 shows the execution time needed for various cryptographic primitives for both the server/GS S and drone/smart device sides. Note that based on the Horner’s rule [40], evaluation of a t-degree

• Scenario 2 (D2GSS access control phase): It can be viewed from Fig. 6 that a drone DRk needs to invest a total amount of 5T h + 4T ecm + T eca + T poly time which is approximately (53.981 + 0.008t) milliseconds, whereas the GS S needs the same execution time, that is, ≈ 5T h +4T ecm +T eca +T poly = (8.708+0.001t). If we again consider t = 100, the total computation cost required for a drone or the GS S becomes 8.808 milliseconds. We have done the comparative study on computation costs during the access control phase among BACS-IoD and other schemes in Table 6. It is noted that the proposed scheme makes a trade-off among the computation costs of drone and the GS S as compared to other existing schemes. Though BACS-IoD requires more computation time as compared to some existing schemes, it is justified because our scheme provided better security and more functionality attributes that are illustrated in Table 7.

22

Journal Pre-proof

9. Concluding remarks

lP repro of

8.3. Security and functional features comparison [6] E. Bach. Toward a theory of Pollard’s rho method. Information and Computation, 90(2):139–155, 1991. Finally, in Table 7 we perform a comparative study on “se- [7] E. Barker. Recommendation for Key Management, 2016. Special Pubcurity and functionality attributes” among the proposed BACSlication 800-57 Part 1 Rev. 4, NIST, 01/2016. Accessed on November 2019. IoD and other schemes. It is worth noting that none of the existing schemes provide blockchain-based secure solution us- [8] B. Blanchet. Modeling and Verifying Security Protocols with the Applied Pi Calculus and ProVerif. Foundations and Trends in Privacy and ing the access control mechanism, only BACS-IoD achieves Security, 1(1-2):1–135, 2016. blockchain-based solution. Moreover, formal security analysis [9] A. Braeken, P. Porambage, M. Stojmenovic, and L. Lambrinos. eDAAAS: Efficient distributed anonymous authentication and access in and formal security verification are also missing in most exsmart homes. International Journal of Distributed Sensor Networks, isting schemes compared in Table 7. In a nutshell, BACS-IoD 12(12):1–11, 2016. achieves better in terms of security and also it supports more [10] R. Canetti and H. Krawczyk. Universally Composable Notions of Key functionality attributes as compared to those for other existing Exchange and Secure Channels. In International Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT’02), schemes.

Acknowledgments

rna

In this paper, to the best of our knowledge it is our first attempt to design a blockchain-based access control mechanism in an IoT-enabled IoD environment (BACS-IoD). BACS-IoD supports two kinds of access control: one is between any two neighbor drones in a flying zone and other is between a drone and its associated GS S . The formed block by the GS S is verified and added through the RPCA consensus algorithm by the peer nodes in the P2P CS network. It is shown that BACS-IoD can resist various attacks using the formal and informal security analysis. Furthermore, through the simulation study using the formal security verification under the broadly-accepted AVISPA tool, it is also shown that BACS-IoD has potential to resist passive and active attacks. Comparative study also reveals that BACS-IoD achieves better trade-off among “security and functionality attributes”, “communication cost” and “computation cost”. In future, we would like to implement BACS-IoD using some consensus mechanisms. In addition, we would also like to enhance BACS-IoD in future by providing more functionality features, such as anonymity of the drones in the IoD environment.

Jou

This work was supported by the “Ripple Centre of Excellence Scheme, CoE in Blockchain (Sanction No. IIIT/R&D Office/Internal Projects/001/2019), IIIT Hyderabad, India”. References

[1] M. Abdalla, P. A. Fouque, and D. Pointcheval. Password-based authenticated key exchange in the three-party setting. In 8th International Workshop on Theory and Practice in Public Key Cryptography (PKC’05), Lecture Notes in Computer Science, volume 3386, pages 65–84, Les Diablerets, Switzerland, 2005. [2] S. Aggarwal, R. Chaudhary, G. S. Aujla, N. Kumar, K. K. R. Choo, and A. Y. Zomaya. Blockchain for smart communities: Applications, challenges and opportunities. Journal of Network and Computer Applications, 144:13–48, 2019. [3] S. Aggarwal and N. Kumar. Path planning techniques for unmanned aerial vehicles: A review, solutions, and challenges. Computer Communications, 149:270–299, 2019. [4] AVISPA. Automated Validation of Internet Security Protocols and Applications, 2019. http://www.avispa-project.org/. Accessed on October 2019. [5] AVISPA. SPAN, the Security Protocol ANimator for AVISPA, 2019. http://www.avispa-project.org/. Accessed on October 2019.

pages 337–351, Amsterdam, The Netherlands, 2002. [11] M. Castro and B. Liskov. Practical Byzantine fault tolerance and proactive recovery. ACM Transactions on Computer Systems, 20(4):398–461, 2002. [12] S. Challa, M. Wazid, A. K. Das, N. Kumar, A. G. Reddy, E. Yoon, and K. Yoo. Secure Signature-Based Authenticated Key Establishment Scheme for Future IoT Applications. IEEE Access, 5:3028–3043, 2017. [13] C. C. Chang and H. D. Le. A provably secure, efficient, and flexible authentication scheme for ad hoc wireless sensor networks. IEEE Transactions on Wireless Communications, 15(1):357–366, 2016. [14] B. Chase and E. MacBrough. Analysis of the XRP Ledger Consensus Protocol. CoRR, abs/1802.07242, 2018. [15] D. Chattaraj, M. Sarma, and A. K. Das. A new two-server authentication and key agreement protocol for accessing secure cloud services. Computer Networks, 131:144 – 164, 2018. [16] D. Chattaraj, M. Sarma, A. K. Das, N. Kumar, J. J. P. C. Rodrigues, and Y. Park. HEAP: An Efficient and Fault-Tolerant Authentication and Key Exchange Protocol for Hadoop-Assisted Big Data Platform. IEEE Access, 6:75342–75382, 2018. [17] S. Chatterjee, A. K. Das, and J. K. Sing. An Enhanced Access Control Scheme in Wireless Sensor Networks. Ad Hoc & Sensor Wireless Networks, 21(1-2):121–149, 2014. [18] R. Chaudhary, A. Jindal, G. S. Aujla, S. Aggarwal, N. Kumar, and K. K. R. Choo. BEST: Blockchain-based secure energy trading in SDN-enabled intelligent transportation system. Computers & Security, 85:288–299, 2019. [19] G. Choudhary, V. Sharma, and I. You. Sustainable and secure trajectories for the military Internet of Drones (IoD) through an efficient Medium Access Control (MAC) protocol. Computers & Electrical Engineering, 74:59 – 73, 2019. [20] Cas J. F. Cremers. The Scyther Tool: Verification, Falsification, and Analysis of Security Protocols. In Computer Aided Verification, pages 414–418, Berlin, Heidelberg, 2008. Springer Berlin Heidelberg. [21] B. Cuffari. Using Sensors in Drones, 2018. https://www.azosensors.com/article.aspx?ArticleID=1149. Accessed on November 2019. [22] A. K. Das, N. R. Paul, and L. Tripathy. Cryptanalysis and improvement of an access control in user hierarchy based on elliptic curve cryptosystem. Information Sciences, 209:80–92, 2012. [23] A. K. Das, M. Wazid, N. Kumar, A. V. Vasilakos, and J. J. P. C. Rodrigues. Biometrics-Based Privacy-Preserving User Authentication Scheme for Cloud-Based Industrial Internet of Things Deployment. IEEE Internet of Things Journal, 5(6):4900–4913, 2018. [24] A. K. Das, S. Zeadally, and D. He. Taxonomy and analysis of security protocols for Internet of Things. Future Generation Computer Systems, 89:110–125, 2018. [25] D. Dolev and A. Yao. On the security of public key protocols. IEEE Transactions on Information Theory, 29(2):198–208, 1983. [26] M. Du, X. Ma, Z. Zhang, X. Wang, and Q. Chen. A review on consensus algorithm of blockchain. In IEEE International Conference on Systems, Man, and Cybernetics (SMC’17), pages 2567–2572, Banff, AB, Canada, 2017. [27] Q. Feng, D. He, S. Zeadally, and K. Liang. BPAS: Blockchain-Assisted Privacy-Preserving Authentication System for Vehicular Ad-Hoc Networks. IEEE Transactions on Industrial Informatics, 2019. DOI: 10.1109/TII.2019.2948053. [28] P. Gope and T. Hwang. A Realistic Lightweight Anonymous Authentication Protocol for Securing Real-Time Application Data Access in Wireless Sensor Networks. IEEE Transactions on Industrial Electronics,

23

Journal Pre-proof

[55] [56] [57]

security under the threat of power analysis attacks. IEEE Transactions on Computers, 51(5):541–552, 2002. A. A. Monrat, O. Schel´en, and K. Andersson. A Survey of Blockchain From the Perspectives of Applications, Challenges, and Opportunities. IEEE Access, 7:117134–117151, 2019. S. Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. https://downloads.coindesk.com/research/whitepapers/bitcoin.pdf. P. Sarkar. A Simple and Generic Construction of Authenticated Encryption with Associated Data. ACM Transactions on Information and System Security, 13(4):33, 2010. C. P. Schnorr. Efficient signature generation by smart cards. Journal of Cryptology, 4(3):161–174, 1991. J. Srinivas, A. K. Das, N. Kumar, and J. J. P. C. Rodrigues. TCALAS: Temporal Credential-Based Anonymous Lightweight Authentication Scheme for Internet of Drones Environment. IEEE Transactions on Vehicular Technology, 68(7):6903–6916, 2019. J. Srinivas, A. K. Das, N. Kumar, and J. J. P. C. Rodrigues. Tcalas: Temporal credential-based anonymous lightweight authentication scheme for internet of drones environment. IEEE Transactions on Vehicular Technology, 68(7):6903–6916, 2019. W. Stallings. Cryptography and Network Security: Principles and Practice. Prentice Hall Press, Upper Saddle River, NJ, USA, 5th edition, 2010. A. K. Sutrala. Design and Analysis of Three-Factor User Authentication Schemes for Wireless Sensor Networks. PhD thesis, Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad, India, July 2018. Y. Tian, J. Yuan, and H. Song. Efficient privacy-preserving authentication framework for edge-assisted Internet of Drones. Journal of Information Security and Applications, 48:102354, 2019. G. S. Veronese, M. Correia, A. N. Bessani, L. C. Lung, and P. Verissimo. Efficient byzantine fault-tolerance. IEEE Transactions on Computers, 62(1):16–30, 2011. D. Wang, D. He, P. Wang, and C. Chu. Anonymous Two-Factor Authentication in Distributed Systems: Certain Goals Are Beyond Attainment. IEEE Transactions on Dependable and Secure Computing, 12(4):428– 442, 2015. X. Wang, P. Zeng, N. Patterson, F. Jiang, and R. Doss. An Improved Authentication Scheme for Internet of Vehicles Based on Blockchain Technology. IEEE access, 7:45061–45072, 2019. M. Wazid, A. K. Das, N. Kumar, A. V. Vasilakos, and J. J. P. C. Rodrigues. Design and Analysis of Secure Lightweight Remote User Authentication and Key Agreement Scheme in Internet of Drones Deployment. IEEE Internet of Things Journal, 6(2):3572–3584, 2019. M. Wazid, A. K. Das, and J. H. Lee. Authentication protocols for the internet of drones: taxonomy, analysis and future directions. Journal of Ambient Intelligence and Humanized Computing, 2018. M. Wazid, A. K. Das, V. Odelu, N. Kumar, M. Conti, and M. Jo. Design of Secure User Authenticated Key Management Protocol for Generic IoT Networks. IEEE Internet of Things Journal, 5(1):269–282, 2018. M. Wazid, A. K. Das, V. Odelu, N. Kumar, and W. Susilo. Secure Remote User Authenticated Key Establishment Protocol for Smart Home Environment. IEEE Transactions on Dependable and Secure Computing, 2017. doi: 10.1109/TDSC.2017.2764083. L. Wu, J. Wang, K. R. Choo, and D. He. Secure Key Agreement and Key Protection for Mobile Device User Authentication. IEEE Transactions on Information Forensics and Security, 14(2):319–330, 2019. S. Zeadally, A. K. Das, and N. Sklavos. Cryptographic technologies and protocol standards for Internet of Things. Internet of Things, page 100075, 2019. P. Zeng, K.-K.R. Choo, and D.-Z. Sun. On the Security of an Enhanced Novel Access Control Protocol for Wireless Sensor Networks. IEEE Transactions on Consumer Electronics, 56(2):566–569, 2010. H. Zhang, J. Wang, and Y. Ding. Blockchain-based decentralized and secure keyless signature scheme for smart grid. Energy, 180:955–967, 2019. S. Zhang and J. H. Lee. Analysis of the main consensus protocols of blockchain. ICT Express, 2019. http://www.sciencedirect.com/science/article/pii/S240595951930164X. Z. Zheng, S. Xie, H. N. Dai, X. Chen, and H. Wang. Blockchain challenges and opportunities: A survey. International Journal of Web and Grid Services, 14(4):352–375, 2018. Y. Zhou, Y. Zhang, and Y. Fang. Access control in wireless sensor networks. Ad Hoc Networks, 5:3–13, 2007.

Jou

rna

lP repro of

63(11):7124–7132, 2016. [29] P. Gope and B. Sikdar. Lightweight and Privacy-Friendly Spatial Data Aggregation for Secure Power Supply and Demand Management in Smart Grids. IEEE Transactions on Information Forensics and Security, 14(6):1554–1566, 2019. [30] P. Gope and B. Sikdar. Lightweight and Privacy-Preserving Two-Factor Authentication Scheme for IoT Devices. IEEE Internet of Things Journal, 6(1):580–589, 2019. [31] H. F. Huang. A novel access control protocol for secure sensor networks. Computer Standards & Interfaces, 31:272–276, 2009. [32] H. F. Huang. A New Design of Access Control in Wireless Sensor Networks. International Journal of Distributed Sensor Networks, 2011, 2011. Article ID 412146, 7 pages, DOI: 10.1155/2011/412146. [33] H. F. Huang and K. C. Liu. A New Dynamic Access Control in Wireless Sensor Networks. In IEEE Asia-Pacific Services Computing Conference (APSCC’08), pages 901–906, Yilan, Taiwan, 2008. [34] L. Ismail and H. Materwala. A Review of Blockchain Architecture and Consensus Protocols: Use Cases, Challenges, and Solutions. Symmetry, 11(10):1198, 2019. [35] A. Jindal, G. S. Aujla, and N. Kumar. SURVIVOR: A blockchain based edge-as-a-service framework for secure energy trading in SDN-enabled vehicle-to-grid environment. Computer Networks, 153:36–48, 2019. [36] D. Johnson, A. Menezes, and S. Vanstone. The Elliptic Curve Digital Signature Algorithm (ECDSA). International Journal of Information Security, 1(1):36–63, 2001. [37] C. F. Kerry and P. D. Gallagher. Digital Signature Standard (DSS), 2013. FIPS PUB 186-4, National Institute of Standards and Technology (NIST), U.S. Department of Commerce. Accessed on November 2019. [38] H. S. Kim and S. W. Lee. Enhanced novel access control protocol over wireless sensor networks. IEEE Transactions on Consumer Electronics, 55(2):492–498, 2009. [39] S. King and S. Nadal. PPCoin: peer-to-peer crypto-currency with proofof-stake, 2012. https://peercoin.net/assets/paper/peercoin-paper.pdf. [40] D. E. Knuth. The Art of Computer Programming: Seminumerical Algorithms, volume 2. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 3rd edition, 1997. [41] N. Koblitz. Elliptic curve cryptosystems. Mathematics of Computation, 48:203–209, 1987. [42] N. Koblitz, A. Menezes, and S. A. Vanstone. The state of elliptic curve cryptography. Designs, Codes and Cryptography, 19(2-3):173– 193, 2000. [43] L. Lamport, R. Shostak, and M. Pease. The Byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4(3):382– 401, 1982. [44] F. Li, Y. Han, and C. Jin. Practical access control for sensor networks in the context of the Internet of Things. Computer Communications, 89-90:154–164, 2016. [45] H. Z. Liao and Y. Y. Shen. On the Elliptic Curve Digital Signature Algorithm. Tunghai Science, 8:109–126, 2006. [46] C. Lin, D. He, X. Huang, X. Xie, and K. K. R. Choo. Blockchain-based system for secure outsourcing of bilinear pairings. Information Sciences, 2018. http://www.sciencedirect.com/science/article/pii/S0020025518310004. [47] C. Lin, D. He, N. Kumar, K. R. Choo, A. Vinel, and X. Huang. Security and Privacy for the Internet of Drones: Challenges and Solutions. IEEE Communications Magazine, 56(1):64–69, 2018. [48] C. Lin, D. He, N. Kumar, X. Huang, P. Vijaykumar, and K. R. Choo. HomeChain: A Blockchain-Based Secure Mutual Authentication System for Smart Homes. IEEE Internet of Things Journal, 2019. doi: 10.1109/JIOT.2019.2944400. [49] M. Luo, Y. Luo, Y. Wan, and Z. Wang. Secure and efficient access control scheme for wireless sensor networks in the cross-domain context of the IoT. Security and Communication Networks, 2018:1–10, 2018. [50] S. Malani, J. Srinivas, A. K. Das, K. Srinathan, and M. Jo. CertificateBased Anonymous Device Access Control Scheme for IoT Environment. IEEE Internet of Things Journal, 6(6):9762–9773, 2019. [51] K. Malek. Improvments to shanks baby-step giant-step algorithm. Journal of Applied Sciences, 6(1):76–79, 2006. [52] W. E. May. Secure Hash Standard, 2015. FIPS PUB 180-1, National Institute of Standards and Technology (NIST), U.S. Department of Commerce, April 1995. Accessed on August 2019. [53] A. J. Menezes, S. A. Vanstone, and P. C. V. Oorschot. Handbook of Applied Cryptography. CRC Press, Boca Raton, FL, USA, 1996. [54] T. S. Messerges, E. A. Dabbish, and R. H. Sloan. Examining smart-card

[58] [59]

[60]

[61] [62]

[63] [64] [65]

[66]

[67]

[68] [69] [70]

[71] [72] [73] [74] [75] [76] [77]

24

Journal Pre-proof Ashok Kumar Das received a Ph.D. degree in computer science and engineering, an M.Tech. degree in computer science and data processing, and an M.Sc. degree in mathematics from IIT Kharagpur, India. He is currently an Associate Professor with the Center for Security, Theory and Algorithmic Research, International Institute of Information Technology, Hyderabad, India. His current research interests include cryptography, network security, blockchain, security in Internet of Things (IoT), Internet of Vehicles (IoV), Internet of Drones (IoD), smart grids, smart city, cloud/fog computing and industrial wireless sensor networks, and intrusion detection. He has authored over 200 papers in international journals and conferences in the above areas, including over 175 reputed journal papers. Some of his research findings are published in top cited journals, such as the IEEE Transactions on Information Forensics and Security, IEEE Transactions on Dependable and Secure Computing, IEEE Transactions on Smart Grid, IEEE Internet of Things Journal, IEEE Transactions on Industrial Informatics, IEEE Transactions on Vehicular Technology, IEEE Transactions on Consumer Electronics, IEEE Journal of Biomedical and Health Informatics (formerly IEEE Transactions on Information Technology in Biomedicine), IEEE Consumer Electronics Magazine, IEEE Access, IEEE Communications Magazine, Future Generation Computer Systems, Computers & Electrical Engineering, Computer Methods and Programs in Biomedicine, Computer Standards & Interfaces, Computer Networks, Expert Systems with Applications, and Journal of Network and Computer Applications. He was a recipient of the Institute Silver Medal from IIT Kharagpur. He is on the editorial board of KSII Transactions on Internet and Information Systems, International Journal of Internet Technology and Secured Transactions (Inderscience), and IET Communications, is a Guest Editor for Computers & Electrical Engineering (Elsevier) for the special issue on Big data and IoT in ehealthcare and for ICT Express (Elsevier) for the special issue on Blockchain Technologies and Applications for 5G Enabled IoT, and has served as a Program Committee Member in many international conferences. He also severed as one of the Technical Program Committee Chairs of the International Congress on Blockchain and Applications (BLOCKCHAIN’19), Avila, Spain, June 2019.

lP repro of

Basudeb Bera received his M.Sc. degree in mathematics and computing in 2014 from IIT (ISM) Dhanbad, India, and M.Tech. degree in computer science and data processing in 2017 from IIT Kharagpur, India. He is currently pursuing his Ph.D. degree in computer science and engineering from the Center for Security, Theory and Algorithmic Research, IIIT Hyderabad, India. His research interests are cryptography, network security and blockchain technology.

Jou

rna

Durbadal Chattaraj is a research scholar (Ph.D.) at Subir Chowdhury School of Quality and Reliability, IIT Kharagpur, India, since December 2013, and he has submitted his Ph.D. thesis in 2019. He has received B.Tech (2006) and M.Tech (2010) degree in Computer Science and Engineering from Maulana Abul Kalam Azad University of Technology, West Bengal, India. He did his Post Graduate Diploma in Clinical Data Management (2008) from Institute Of Clinical Research India (ICRI), Bangalore Campus. He was a recipient of the University Silver Medal from Maulana Abul Kalam Azad University of Technology. He has worked for Narula Institute of Technology, Agarpara, Kolkata, India, as an Assistant Professor in the Department of Computer Science and Engineering (2011-2013). He has also worked for Boden Software Services Pvt. Ltd., Bangalore, India, as an Associate Software Engineer (2006-2008). His present research interests include cloud data security and reliability, cryptography, computer networks, cloud computing, Big Data analytics, information security, and dependable computing. He has authored 10 papers in various international journals and conferences in the above areas.

25

Journal Pre-proof Conflict of Interest

Jou

rna

lP repro of

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.