Peer-to-Peer Networking and Applications

https://doi.org/10.1007/s12083-020-00963-w

BIDAPSCA5G: Blockchain based Internet of Things (IoT) device

to device authentication protocol for smart city applications using
5G technology
Manojkumar Vivekanandan1,2 · Sastry V. N.1 · Srinivasulu Reddy U.2

Received: 30 April 2020 / Accepted: 3 July 2020

© Springer Science+Business Media, LLC, part of Springer Nature 2020

Abstract
Due to the advancement of wireless technology, the Internet of Things (IoT) Device to Device communication for exchanging
messages is feasible without human involvement. Authentication and identification of device location are highly essential
tasks to verify the originality of IoT Devices (IoTDs) during communication via open channel. In recent days, IoTD
registration is processed through the Registration Center Authority (RAC) and this may face single point of failure and
insider attack. To solve these problems, we propose a Blockchain based Internet of Things (IoT) Device to Device
Authentication Protocol for Smart City Applications using 5G Technology (BIDAPSCA5G). In the proposed protocol,
the IoT Devices registration process is performed through private blockchain. The Blockchain has the Distributed Ledger
(DL) for storing IoTD credential details, which is accessed only by authenticated entities. In the proposed protocol, mutual
authentication was performed without involvement of RAC/Gate-Way-Node (GWN) to reduce the computation cost. The
proposed protocol has the additional features such as location based authentication, blockchain based revocation phase
and registration of IoTDs, IoTD anonymity property at device level. The security analysis of the proposed protocol was
performed through formal security verification using Proverif tool, formal security analysis using Random Oracle Model
(RoM) and informal security analysis. The security analysis proved that the proposed protocol is secured against well-known
attacks and also it provides better performance as well as additional features when compared to existing protocols.

Keywords Authentication · IoT · Blockchain · Proverif tool · Security analysis

1 Introduction
Now-a-days, 5G technology which is advantageous than
other generations (1G, 2G, 3G, 4G) offers mobility sup-
port, low latency, high network speed (10 Gb/s) etc. 5G
technology is widely used in various applications such as
smart home, high definition visual communication, vehicle
communication, multimedia communication, medical sec-
tor, industrial sector and environmental monitoring [9]. The
This article belongs to the Topical Collection: Special Issue
on P2P Computing for Beyond 5G Network and Internet-of-
Everything
Guest Editors: Prakasam P, Ajayan John, Shohel Sayeed
 Srinivasulu Reddy U.
usreddy@nitt.edu
Extended author information available on the last page of the article.
objects (things like smart watch, smart phone) are connected
with the Internet through wireless technologies which is
popularly refered as loT [14]. The physical objects are con-
nected to each other to form a network for communication to
achieve common goals according to International Telecom-
munication Union (ITU) [28]. In IoT device communica-
tion, information exchange lacks security and privacy [36]
raising a need for authentication. To address the security
challenges, we propose blockchain based authentication
protocol for IoT devices using 5G.
In recent days, Blockchain network is emerging topic for
applying the smart city applications [40].
In 2008, Blockchain document was introduced. In 2009,
the bitcoin was introduced by Satoshi Nakamoto. Bitcoin
is the digital currency and bitcoin transaction is processed
by peer-to-peer mode using Bitcoin applications [27]. A
bitcoin transaction is processed by peer-to-peer, without
a central authority. The verification of a transaction is
performed by using Blockchain network. In recent days

many works are suggested based on peer-to-peer networks
[7], [25, 26]. Blockchain network consists of the growing
block as a chain, where each block consists of a transaction.
The new block is added, when completion of the consensus
algorithm by miners. The miners do the verification of
blocks based on the consensus algorithm such as Proof-
of-Work (PoW), Proof-of-State (PoS), Delegated-Proof-of-
Stake (DPoS), Practical-Byzantine-Fault-Tolerance (PBFT)
and Paxos/Raft etc. The Blockchain is classified into three
types, such as Public blockchain: the access rights (read,
send, write and recieve) are handled by any one, Private
blockchain: the access rights are handled by organization
and Consortium blockchain: The write permission is
controlled by set of nodes and read operation is taken
by all to open [41]. Blockchain network can be used for
several applications such as identity management (Data
Storage), bitcoin transaction and multi-party computation
for payments. It maintains DL available to all nodes,
based on network type. The transaction is performed by
miners, who mines the transaction and adds block into the
Blockchain network. Each block contains the transaction
and the same is recorded in DL after successful transaction.
The mining job is processed through network nodes which
has a higher capacity for computation resources and solving
the cryptographic puzzle problem. On solving puzzle
problem, miner gets incentives for the job. The DL has
set of properties, such as decentralization, immutability
and distributed. The identity management for IoT device is
the best use case for DL [43]. For example, IoT Devices
communication happens through a wireless network and
verification of identity for IoT Devices is processed
through authentication. After authentication, of IoT Devices
information exchange happens. In recent-days, deployment,
revocation and information management of IoT Devices
are maintained by RAC. However, RAC faces single
point of failure and insider attacks. Hence, we propose a
BIDAPSCA5G: Blockchain based Internet of Things (IoT)
Device to Device Authentication Protocol for Smart City
Applications using 5G Technology that can overcome the
limitation of RAC through private Blockchain.
1.1 System model
In this section, we discuss the following model for proposed
protocol.
1.1.1 Network model
We consider, the network model as mentioned in Fig. 1
for proposed protocol. IoT devices are deployed in the
secure “target field”. The GWN is also deployed in the
secure “target field”. The GWN sends information about
IoT Devices credential to private Blockchain for registration
Peer-to-Peer Netw. Appl.
process. After registration, IoT Devices are communicated
to each other without the involvement of GWN at the time
of authentication. The communications of IoT Devices was
processed by the wireless medium, therefore there is some
possibility for the attack through adversary(A). For secure
communication between IoT Devices in the authentications
process and secret key establishment between IoT Devices
“device access control” is needed.
1.1.2 Threat model
In this section, we consider threat model for proposed pro-
tocol. The “Dolve-Yao (DY)” threat model [12] is a broadly
accepted model. DY model assumes if the IoTDs are commu-
nicating each other through wireless medium, there is possibi-
lity of A and can do the following changes: 1. Intercepts the
communication 2. Modification of messages 3. Insertion of
malicious messages 4. Deletion of original messages. In
some applications, if the IoTDs are deployed in “unsecured
environment”, then there is a possibility to capture the phy-
sical IoT Devices by A and extracts the information from IoT
Devices using power analysis [11], [20, 23]. Therefore, in pro-
posed protocol we assume that IoTDs are deployed in secure
“target field”. RAC/GWN and Blockchain are trusted autho-
rity and these cannot be compromised by A as it can only
issues the secret credentials to IoT devices using Blockchain.
1.2 Motivation
– IoT Device to IoT Device communication is important
task for smart city applications.
– Most of the IoT Device authentication protocols
involves user in the authentication process. Therefore,
we need an authentication protocol for smart city
applications without human involvement.
– In many of the IoT Device authentication protocols,
RAC is the central authority for devices registration,
revocation and dynamic device addition phase.
– In the centralized authority there is possibility of single
point of failure and insider attack. Therefore, we need
decentralized authority known as Blockchain to avoid
attacks.
– Several IoT Device authentication protocols are pro-
cessed without considering the location of IoT devices
and IoT device anonymity property at device level.
Therefore, we need location based authentication pro-
tocol for IoT Devices and to provide IoT device
anonymity property at device level.
– To address the above mentioned problems, we propose
a Blockchain based Internet of Things (IoT) Device
to Device Authentication Protocol for Smart City
Applications using 5G Technology. The highlights of
the proposed protocol are mentioned in Appendix A.
Peer-to-Peer Netw. Appl.
Fig. 1 Generic Smart City Environment with IoT and Blockchain DL
1.3 Contributions
– In this article, we propose a Blockchain based Internet
of Things (IoT) Device to Device Authentication Pro-
tocol for Smart City Applications using 5G Technology
(BIDAPSCA5G).
– Proposed protocol performs authentication between IoT
Device to IoT Device without the involvement of
RAC/GWN.
– Proposed protocol registration process is performed
through private blockchain with the help of RACi .
– Proposed protocol authentication performed is based on
the location of the device, which was not considered in
the existing works.
– Proposed protocol performs better as well as provides
additional features such as location based authentica-
tion of IoT device, IoT device revocation phase and
registration using Blockchain network and provides IoT
device anonymity property at device level.
– Proposed protocol performs registration via decen-
tralized authority i.e., private blockchain. The private
blockchain has DL that stores full history of IoT
Devices (Deployment Details, information manage-
ment).
– Proposed protocol security verification is performed
through formal and informal analysis. Formal analysis
is performed through Proverif tool, informal analysis
through various security assumptions, and formal secu-
rity verification through Random Oracle Model (RoM).
1.3.1 Assumptions
– In proposed protocol, we assume that, the IoT Devices
are deployed in the secure “target field”.
1.4 Section details
The Sections are organized as follows: Section 2 contains
related works. Section 3 describes mathematical prelim-
inaries. Section 4, describes proposed protocol. Security
analysis are presented in the Section 5. Section 6 describes
performance analysis and Section 7 summarizes conclusory
remarks of the proposed protocol.
2 Related works
IoT Device to Device authentication is an important task
and also another important task is IoTD communicates
with neighbor IoTD for information exchange without
human intervention in the smart city environment. Stergiou,
C., et al. [34] designed architecture for the sustainable
cloud computing to improve security in the big data and
IoT communication. They addressed security issues for
integration of two technologies such as IoT & cloud
computing. Security issues are heterogeneity, performance,
reliability, big-data and monitoring. They also established
the security wall between internet and cloud computing to
eliminate the security issues. Li, D., et al. [21] designed

image watermarking technique with security guaranteed
for smart city applications using Convolutional Neural
Networks (CNN) algorithm. Their algorithm aims to detect
and extract the watermarking for image datasets. They got
93.75% accuracy for classification. The Psannis et al. [29]
suggested efficient algorithm for intelligent cloud systems
in media based smart big data. Their algorithm solves the
quality issues of the streaming video through cloud in the
big data environment. Recently, Kadhim, A.J. and Seno,
S.A.H., suggested [18] energy efficient multi-cast routing
protocol for vehicular networks based on fog and software
defined network (SDN) computing. Their architecture has
the four layers such as SDN, OpenFlow switches, fog
computing, vehicles as represented as top to bottom layer.
Their protocol presented scheduling and classification
algorithms. Their protocol is used to incoming multi-cast
requests classification and priority based scheduling for
multi-cast requests. Their protocol performed better for
multi-cast energy consumption.
In recent days many protocols are suggested for IoT envi-
ronments such as [24, 37] and [33], but these protocols
are based on the involvement of user in the authentication
process. In many of the authentication protocols such as [24,
37] and [10] suggested that, with the involvement of GWN
in the authentication process, it takes more computation
cost. The fog computing is used for transportation cyber-
physical systems (T-CPS) applications. The advantage of
fog computing in T-CPS are less communication latency,
save network bandwidth, reduce bandwidth cost, mobility
support etc., [2, 15, 16]. Aman, M.N., et al. [5] suggested
physical unclonable functions based mutual authentication
protocol in IoT environment. In these protocol, the mutual
authentication is performed between two IoT Devices with
the help of server and also mutual authentication is per-
formed between IoTD and server. In their protocol authen-
tication was performed using cryptographic primitives such
as hash function and encryption/decryption function. But,
these protocol takes high exchange rate for the authen-
tication, does not provides device anonymity property at
device level, does not provides user anonymity and untrace-
ability property in the authentication phase. This protocol
failed to provide secure data storage system property [17].
Li et al. [22] designed IoT mutual authentication protocol
based on public key encryption and decryption, but these
protocol takes high computation and communication over-
head (Wazid et al. [38]). Tewari A. and Gupta [35] designed
mutual authentication protocol for IoT Devices. They used
cryptography primitives such as hash function and Ellip-
tic Curve Cryptography (ECC) respectively for designing
the protocol. In their protocol the mutual authentication
was performed between IoT device and server. Their proto-
col security analysis was performed using informal security
analysis. Their protocol maintained IoT credential in server
Peer-to-Peer Netw. Appl.
hence, there is a chance of single point of failure. Their pro-
tocol does not address formal security analysis and formal
security verification.
Malani et al. [23] suggested mutual authentication
protocol for IoT environment. This authentication protocol
was developed based on the ECC and hash function. In their
protocol, the registration of IoT Devices was performed
using RAC. Therefore, there is some possibility of insider
attack in their protocol and also their protocol does not
provides device anonymity property at device level. It
takes high computation cost and communication cost. Adeel
et al. [1] designed IoTD to IoTD authentication protocol.
But, this protocol was based on involvement of server in
authentication phase and also registrations of IoT Devices
are performed through server. Therefore, there is some
possibility of insider attack and single point of failure in
their protocol. This protocol, does not address dynamic
device addition phase and does not address formal security
verification.
Das et al. [11] suggested device to device authentication
protocol for IoT environment. This protocol was developed
based on ECC and Hash function. In their protocol, RAC
issued certificates to the device at the deployment phase.
This protocol takes high computation and communication
cost. Their protocol does not provide device anonymity
and untraceability property and also does not provide
IoT Device anonymity property at device level. The
advantages and disadvantages of proposed protocol and
existing protocols are presented in Table 1.
3 Mathematical preliminaries
In this section, we discuss the notations and mathematical
background of the proposed protocol. The proposed
protocol notations and meanings are represented in Table 2.
The mathematical preliminaries are represented as follows,
Definition 1 - ECC [19]: y 2 = x 3 + ax + b is the elliptic
curve equation over zp∗ and (x, y)zp∗ × zp∗ is the set of
solutions to the congruence y 2 ≡ x 3 + ax + b(modp),
4a 3 + 27b2 ≡ 0(modp) is the equation, where a, b are
constants and along with a point at infinity. If P is a base
point of elliptic curve i.e., Ep∗ (a, b) over the finite field
Fp∗ and key exchange algorithm for Elliptic Curve Diffie-
Hellman (ECDH) is describes as follows:
Initially, Device Di selects base point (P) from elliptic curve
and choose private key ri and calculates public key ri .P
and shares to Device Dj . Dj also selects private key rj and
calculates Bj i = rj .(ri .P ). Finally, Dj shares rj to Di and
Di calculates Bij = rj .(ri .P ). Finally, Bj i and Bij are the
similar and it is used to generate of session keys between Di
and Dj for our protocol.
Peer-to-Peer Netw. Appl.

Table 1 Literature survey

Ref. [5] [22] [35] [23] [1] [11] Proposed protocol

Attri.

CP H, SE/SD, MAC PKE/D H, ECC H, ECC, DS H H, ECC H, ECC

MA NO YES NO YES NO YES YES
MAT YES NO YES NO YES NO NO
FSA YES NO NO YES NO YES YES
FSV YES NO NO YES YES YES YES
ISA YES YES YES YES YES YES YES
ComP High High High High Low High Low
ComC High High Low High Low High Low
DDAP NO NO NO YES NO NO YES
DDAPB NO NO NO NO NO NO YES
IOTDRB NO NO NO NO NO NO YES
IOTDrB NO NO NO NO NO NO YES
IOTDAL NO NO NO NO NO NO YES
R:C/D C C C C C C D
SDSS NO NO NO NO NO NO YES
DAU NO NO NO NO NO NO YES
SSPOF NO NO NO NO NO NO YES
IOTDAPDL NO NO YES NO YES NO YES

Note: Ref.- Reference, Atr. - Attributes, CP - Cryptography Primitives, H - Hash, SE/SD - Symmetric Encryption/Symmetric Decryption, MAC
- Message Authentication Code, PKE/D - Public Key Encryption/Decryption, ECC - Elliptic Curve Cryptography, DS - Digital Signature, MA -
Mutual Authentication performed with out GWN/RAC, MAT - Mutual Authentication performed with involvement of GWN/RAC, FSA - Formal
Security Analysis Processed, FSV - Formal Security Verification Processed, ISA - Informal Security Analysis Processed, ComP - Computation
Cost, ComC - Communication Cost, DDAP - Dynamic Device Addition Phase provided, DDAPB - Dynamic Device Addition Phase using
Blockchain provided, IOTDRB - IoT Device Registration phase using Blockchain provided, IoTDrB - IoT Device Revocation phase using
Blockchain provided, IOTDAL - IoT Device Authentication using Location provided, R:C/D - Registration using Centralized server/Decentralized
Server, SDSS - Secure Data Storage System provided, DAU - Device Anonymity and Untraceability property provided, SSPOF - Secure from
Single Point of Failure, IOTDAPDL- IoT device anonymity property at device level

4 Proposed protocol the help of secret credentials, which are preloaded

In this section, we discuss Blockchain based IoT Device to
Device authentication protocol for smart city applications.
The proposed protocol has four phases such as 1. Setup
2. RACi registration and Device registration 3. Device
authentication and 4. Addition of new IoT Device. These
phases are represented as follows,
– System setup: In this phase, the RACi is issues
the secret credentials to IoT Devices with the help
of blockchain. The blockchain ledger maintains the
identity information about IoT Devices.
– RACi registration and IoT Device registration: In pro-
posed protocol, RACi registration is performed through
Blockchain netowrk. Also, IoT Devices registration
process is performed through RACi using blockchain.
The IoT Devices secret credentials are loaded into the IoT
memory before deployment into real-time environment.
IoT Devices registration process is represented in Fig. 2.
– IoT Devices authentication: In this phase, the two
IoT Devices mutually authenticate each other with
informations in the IoT Devices. After successful
mutual authentication, the SK is generated between two
IoT Devices for secure communications. IoT Devices
authentication process is represented in Fig. 3.
– Addition of new IoT Devices: In some applications,
the IoT Devices are stolen/physically captured by A
or there is some possibility of IoT Devices failure due
to power drains. Therefore, there is need to deploy
new IoT Devices into the environment to continue IoT
services in the environment. The following subsections
are presented with detailed explanation of above
phases.
4.1 Setup phase
In the setup phase, one of the RACi performs the following
operations:
Step 1: The RACi chooses a ECC point, secret key and
computes public key QCA = xCA .P
Step 2: Then, RACi also chooses hash function, H (·)
 Peer-to-Peer Netw. Appl.

Table 2 Notations and meanings Step 1: RACi generates secret k, selects I Di each IoT
devices and RACi calculates as follows,
Notations Meanings
Step 2: A1 = k.P
IoTD IoT Device Step 3: A2 = H (I Di || I DGW N || QCA || A1 ) ⊕ QCA
RAC Registration Authority Center Step 4: A3 = A2 ⊕ A1
ECC Elliptic Curve Cryptography Step 5: The RACi stores (h(I Di ), h(I DGW N ), QCA ,
IoT Internet of Things A3 , Li , P ) into IoT devices
Blockchain Blockchain network Step 6: The RACi sends (I Di , I DGW N , QCA , A3 , Li )
blockchain blockchain ledger to Blockchain for storing the values to complete the
GWN Gate-Way-Node registration process.
R0M Random-Oracle-Model The above mentioned process is same for Dj registration
A Adversary in the proposed protocol.
xCA and k Secret keys of GW Ni
QCA public key of GW Ni 4.3 Login and Authentication phase (LA) through a
P ECC base point public channel
H (·), h(·) Hash functions
Di , Dj IoT devices In this phase, the two IoT Devices mutually authenticate
I Di Identity of device Di each other and generates session key for secure communi-
I DGW N Identity of Gate-Way-Node cation, the algorithms are represented in Fig. 4.
L i , Lj Location of IoT devices
ri , rj random numbers 4.4 Dynamic device addition phase
T1 , T2 , T3 , T4 Time stamps
T Threshold limit of time-stamp If environment need new IoT devices, RACi do the
L Threshold limit of location following computations,
I Dj Identity of device Dj Step 1: RACi generates secret k, selects I Di each IoT
SKj i , SKij Session keys devices and RACi calculates as
BC Blockchain Step 2: A1 = k.P
Step 3: A2 = H (I Di || I DGW N || QCA || A1 ) ⊕ QCA
Step 4: A3 = A2 ⊕ A1
Step 3: Finally, the RACi publish QCA , P , Ep∗ (a, b) and Step 5: The RACi stores (h(I Di ), h(I DGW N ), QCA ,
H (·) are public parameters. A3 , Li , P ) into IoT devices
Step 6: The RACi sends (I Di , I DGW N , QCA , A3 , Li ) to
4.2 Registration phase Blockchain for storing the values to complete the registration.

4.2.1 RACi registration

Initially, RACi is registered with the blockchain. After
registration, RACi uploads the identity information of IoT
devices into blockchain.
Step 1: RACi chooses own identity and selects random
numbers and RACi computes as follows,
Step 2: RACipub = h(ri .P || I Di )
Step 3: RACi stores RACipub and h(IDi ) into Blockchain
network
Step 4: RACi keeps ri and I Di as a secret
4.2.2 IoTD (Di ) registration phase
In this section, we discuss the IoTD registration process.
The IoT Devices are registered with the RACi through off-
line with the help of blockchain and registration of IoT
Device processes are represented as follows,
5 Security analysis
In this section, we discuss the security analysis of proposed
protocol. We analyzed proposed protocol using RoM, Proverif
tool and informal security analysis.
5.1 Formal analysis using RoM model
RoM is proposed by Mihir Bellare and Phillip Rogaway
[6]. It used to “proof of security” for cryptography based
protocols [3, 4, 24]. A RoM is a black box (oracle). The
oracle gives the random output based on the requested
query. If the query is repeated many times the same
random output was responded based on the requested
query.
Proofs of Theorem 1 and 2 shows, our protocol can with-
stands from well known attacks based on the RoM. By
Peer-to-Peer Netw. Appl.
Fig. 2 Registration phase
showing the sequence of
registration process
using RoM model A is not able to get the secret informa-
tions about devices (Di ) and (Dj ) such as I Di , I DGW N ,
xCA , A3 , Li , k for Di and I Dj , I DGW N , xCA , C3 , Lj , k
for Dj and also A is not able to generate the SK. The oracle
reveal definitions are represented in Definition 2 and 3 and
proof of theorems 1 and 2 are also represented as follows,
Definition 2 Reveal 1: The oracle provides, the hash
message t from the hash output y, where y=h(t).
Fig. 3 Sequence of activities showing the mutual authentication phase
Definition 3 Reveal 2: The oracle provides, the private key
s from the public key X= s × P ∈ Ep(a, b), Given P ∈ Ep(a, b)
Theorem 1 If the ECDH and hash function act as RoM and
A extracts the secret values from Di or Dj using power
analysis. However, A is not able to extracts I Di , k and
I DGW N from Di .
Proof If A gets information from Di such as h(I Di ),
h(I DGW N ), QCA , A3 , Li using power analysis and also if
A guess the device identities such as I Di , k and I DGW N .
Now A wants to verify the guessed Di information such as
I Di , k and I DGW N are correct or not with the help of exper-
h−ECDH
imental algorithm EXPA . Therefore, the function of
h−ECDH
Success probability is Success= |P r[EXPA = 1] −
h−ECDH
1|, where P r(·) is probability of success of EXPA .
Adv1 (t1, q1) = Max (Success1) is the advantage function
h−ECDH
for EXPA , where t1 is the running time, q1 is the
query depends on Max for random oracle model. The pro-
posed protocol is safe from A because of if Adv1 (t1, q1)
h−ECDH
≤  for any small value  > 0. If A runs the EXPA
algorithm and A can extracts the information from hash
function, then A gets guessed device identities such as I Di ,
k and I DGW N are correct. However, it is hard to get the
information from hash function and ECDH. Therefore, we
proved that A can not determine device identities such as
 Peer-to-Peer Netw. Appl.

I Di , k and I DGW N for proposed protocol. Algorithm 1 is

h−ECDH
represented as EXPA .

Theorem 2 In random oracle model, if hash function

and ECDH acts as input and if A gets information from
communicated message such as h(I Di ), B1 , B2 , T1 , L1
and h(I Dj ), B3 , B4 , T3 , L2 . However, A is not able to
calculates SKij and SKj i .

Proof If A gets information from communicated messages

such as h(I Di ), B1 , B2 , T1 , L1 and h(I Dj ), B3 , B4 , T3 , L2
and also if A knows the device identities such as I Di , k and
IDGWN for Di based on algorithm 1. Now A wants to
generate the SK with the help of algorithm 2 (EXPh−ECDH A ).
Therefore, the function of success probability is Success=
h−ECDH
|P r[EXPA = 1] − 1|, where P r(·) is probability of
h−ECDH
success of EXPA . Adv2 (t2, q2)= Max (Success2)
h−ECDH
is the advantage function for EXPA , where t2 is the
running time, q2 is the query depends on Max for random
oracle model. The proposed protocol is safe from A because
of if Adv2 (t2, q2) ≤  for any small value  > 0. If
h−ECDH
A runs the EXPA algorithm and A can extracts
the informations from hash function and ECDH, then A
generates the SK. However, it is hard to get the information
from hash function and ECDH. Therefore, we proved that
A can not determine SKij and SKj i for our protocol. The
h−ECDH
Algorithm 2, is represents the EXPA .

5.2 Formal verification using Proverif

Proverif is a cryptographic protocol verification tool pro-

posed by Blanchet, B., et al., [8]. The input language for
proverif tool is pi calculus. Proverif tool supported for cryp-
tography primitives such as hashing, symmetric/asymmetric
encryption and digital signature etc. Proverif is able to
demonstrate observation equivalence, reachable properties
and correspondence assertions. These properties are used for
the analysis of authentication and secrecy. Apart from these
properties, verifiability, privacy and traceability are also
Peer-to-Peer Netw. Appl.
Fig. 4 Login and Authentication
(LA)
considered. In proverif tool, the security protocol analysis
was performed in unbounded message space and unbounded
number of sessions. In recent years, formal security ver-
ification of authentication protocols [13, 31, 39, 42], are
verified using Proverif tool. The proposed protocol is rep-
resented in Section 5. The proposed protocol was simulated
through formal verification using proverif tool and Figures
are represented in Appendix B (Figs. 5, 6, 7, 8 and 9). The
formal verification proverif tool consists of declaration part
(Fig. 5), processes (Figs. 6 and 7) and execution of proto-
col (Fig. 8). The proposed protocol declaration part consists
of declarations, which are cryptographic operations, vari-
able declaration and functions declaration. Second part is
proposed protocol processes, which consists of two process,
such as Di and Dj process. Third part is protocol execu-
tion. Finally, we simulate with the queries, the queries are
represented in Fig. 8. The result of proposed protocol is
represented in Fig. 9. From the result we know that pro-
posed protocol is secure against known attacks and provides
authentication and secrecy property.
5.3 Informal analysis
In this section, we discuss the informal security analysis of
proposed protocol. We also prove that our proposed protocol
withstands from well-known attacks and the informal
security analysis is represents as follows,
5.3.1 Device impersonation attack
If A try to impersonate as the legitimate IoT Device (Di )
or (Dj ), then A need to construct the original messages
as a legitimate device Di or Dj . For construct legitimate
messages, A needs to generates a random number and time
stamp, then A construct the messages B1 = H (h(I Di ) ||
h(I DGW N ) || QCA || T1 ) ⊕ A3 , B2 = H (h(I DGW N ) ||
QCA || T1 || A3 ) ⊕ ri .P and L1 = H (h(I DGW N ) ||
ri .P || A3 ) ⊕ Li . It is a impossible task to computes
h(I Di ), B1 , B2 , T1 , L1 , because it needs permanent secret
credentials such as I Di , I DGW N , xCA , Li and k and also
similar way to construct the Dj messages. Therefore, A is
not able to impersonates the original legitimate devices such
as Di or Dj . Finally, our proposed protocol resists from
device impersonation attack.
5.3.2 Man-in-the-middle (MITM) attack
If A intercepts the communicated messages from authen-
tication phase, and if A captures the messages such as
h(I Di ), B1 , B2 , T1 , L1 and h(I Dj ), B3 , B4 , T3 , L2 . Now,

Fig. 5 Declaration of proposed protocol
A try to construct authenticated messages same like origi-
nal messages, such as A generates current time stamp and
random number, then A computes B1 = H (h(I Di ) ||
h(I DGW N ) || QCA || T1 ) ⊕ A3 , B2 = H (h(I DGW N ) ||
QCA || T1 || A3 ) ⊕ ri .P , L1 = H (h(I DGW N ) || ri .P ||
A3 )⊕Li and SKij = H (h(I Di ) || h(I Dj ) || h(I DGW N ) ||
QCA || Bij∗ || ri .P || T1 || T3 || Li || L∗j ). Finally, these
tasks are computationally infeasible due to the permanent
secrets such as I Di , I DGW N , xCA , Li , I Dj , Lj . Therefore,
our proposed protocol can resist with MITM attack.
5.3.3 Device anonymity and untraceability
In our proposed protocol, the communicated messages such
as h(I Di ), B1 , B2 , T1 , L1 and h(I Dj ), B3 , B4 , T3 , L2 does
not contain plain-text of the original identities of devices Di
or Dj respectively. Here, the values of B1 = H (h(I Di ) ||
h(I DGW N ) || QCA || T1 ) ⊕ A3 , B2 = H (h(I DGW N ) ||
QCA || T1 || A3 ) ⊕ ri .P , L1 = H (h(I DGW N ) || ri .P ||
A3 ) ⊕ Li , B3 = H (A3 || ri .P || QCA || H (I Dj ) ||
H (I DGW N ) || T3 ) ⊕ C3 , B4 = H (C3 || QCA || h(I Dj ) ||
Peer-to-Peer Netw. Appl.
(*********Registration******)
let UserDi=
let A1=E(ki,P) in
let A2= CONCAT(H(IDi, IDGWNi, Q, A1),Q) in
let A3= XOR (A2,A1) in
out (SCh , (h(IDi), h(IDGWNi), Q, A3, Li));
in (SCh , (IDi: bitstring, IDGWNi: bitstring));
(***in (SCh, (xPIDi : bitstring, xDi':bitstring, xFi:bitstring , xW':bitstring));*)
(**********Authentication (D_{i}*************)
event beginUserDi(IDi);
new ri: bitstring;
new ti: bitstring;
new li: bitstring;
new lj: bitstring;
let B1= XOR(H(h(IDi), h(IDGWNi), Q, ti), A3) in
let B2= XOR(H(h(IDGWNi), Q, ti, A3), ri) in
let L1= XOR(HHH(h(IDGWNi), ri, A3), li) in
out (PCh, (h(IDi), B1, B2, ti, L1));
in (Pch, (IDj: bitstring, B3: bitstring, B4: bitstring, tj: bitstring, L2: bitstring));
let c3= XOR(HH(A3, ri, Q, h(IDj), h(IDGWNi)), B3) in
let rj= XOR(HHH(c3,Q, h(IDj)), B4) in
let lj= XOR(HHH(h(IDGWN), rj, c3), L2) in
let bij=CONCAT(rj, ri) in
let skij=HHHHH(h(IDi), h(IDj), h(IDGWNi), Q, bij, ri, ti, tj, li, lj) in
event endUserDi ( IDi )
else
0.
Fig. 6 Di Registration and Authentication process
T3 ) ⊕ rj , L2 = H (h(I DGW N ) || rj || C3 ) ⊕ Lj , h(I Di )
and h(I Dj ) has the permanent secrets, which are unknown
to the A. Therefore our proposed protocol provides device
anonymity and untraceability.
5.3.4 Malicious device deployment attack
If A wants to deploy malicious devices in the environment,
then A generates the secret information and sends the authen-
tication request to other devices, which are located in the same
environment. In our proposed protocol, the authentication
request is rejected because of different values when com-
pared to the authenticated values. Therefore, our proposed
protocol withstands malicious device deployment attack.
5.3.5 Device physical capture attack
If A captures the deployed device from the “unsecured envi-
ronment”, then A may extracts the values from device using
Peer-to-Peer Netw. Appl.

(*********Registration******)
let UserDj=
new Pj: bitstring;
new Qj: bitstring;
let A1j=E(kj,Pj) in
let A2j= CONCAT(H(IDj, IDGWNj, Qj, Aj),Qj) in
let A3j= XOR (A2j,A1j) in
out (SCh , (h(IDj), h(IDGWNj), Qj, A3j, Lj));
in (SCh , (IDj: bitstring, IDGWNj: bitstring));
(**********Authentication (D_{j}*************)
event beginUserDj(IDj);
new rj: bitstring;
new tj: bitstring;
new li: bitstring;
new lj: bitstring;
let A3= XOR(H(h(IDi), h(IDGWNj), Qj, ti), B1) in
Fig. 8 Di and Dj queries
let ri= XOR(H(h(IDGWNj), Qj, ti, A3), B2) in
let li= XOR(HHH(h(IDGWNj), ri, A3), L1) in
let Bij= CONCAT(ri, rj) in 5.3.7 Ephemeral secret key leakage attack (ESKLA)
let B3=XOR(HH(A3j, ri, Qj, h(IDGWNj), tj),c3) in
In our protocol, at the time of authentication the session key
let B4=XOR(H(c3, Qj, h(IDj), tj),rj) in
is generated between devices Di and Dj . The session keys
let skji=HHHHH(h(IDj),h(IDj), h(IDGWNj), Qj, bij, ri, ti, tj, li, lj) in are SKij = H (h(I Di ) || h(I Dj ) || h(I DGW N ) || QCA ||
event endUserDj (IDj) Bij∗ || ri .P || T1 || T3 || Li || L∗j ) and SKj i = H (h(I Di ) ||
h(I Dj ) || h(I DGW N ) || QCA || Bj i || ri .P ∗ || T1 ||
else
T3 || L∗i || Lj ). These session keys are generated based on
0. temporary secrets and permanent secrets. We consider the
Fig. 7 Dj Registration and Authentication process following two cases for our protocol,
Case 1: If A only know the temporary secrets (ri , rj ),
then A cannot able to generate the session keys without
power analysis [11, 20, 23]. After extraction of values from permanent secrets (I Di , I DGW N , I Dj , Li , Lj , k, xCA ).
devices, A deploy malicious device into the same environ- Case 2: If A only know the permanent secrets (I Di ,
ment and sends the authentication request to neighbor device. I Dj , I DGW N , Li , Lj , k, xCA ), then A cannot generate the
This process will not happen in our protocol, as devices are session keys without temporary secrets (ri , rj ).
deployed in the “secure target field environment”. There- Therefore, if A know the temporary secrets and perma-
fore, our protocol withstands device physical capture attack. nent secrets, then ESKLA attack is possible. In our protocol,
the two devices secrets are different, each session the ses-
5.3.6 Replay attack sion keys are different from each other and also to know
the permanent secrets and temporary secrets are difficult by
In our protocol, the exchanged informations are h(I Di ), B1 , A. Finally, our protocol withstands ephemeral secret key
B2 , T1 , L1 and h(I Dj ), B3 , B4 , T3 , L2 . This information leakage attack.
contains the location of devices, time-stamp and random
numbers. If A captures this information and replay
messages to the authorize devices Di or Dj , then device
rejects the authentication request from A, because of
the time-stamp probability limit. Therefore, our proposed
protocol withstands from replay attack. Fig. 9 Proposed protocol queries result

5.3.8 Insider attack
In proposed protocol, the IoTDs registration are performed
through private Blockchain network. The IoTDs credentials
are maintained in the private Blockchain network DL. The
Blockchain network DL is accessed by only authenticated
entities. Therefore, the proposed protocol is secure from
insider attack.
5.3.9 Location based authentication
In our protocol, at deployment of IoT devices phase, the
devices are loaded with the location informations such as
(Li ) and (Lj ). After deployment, at the time of authenti-
cation phase devices mutually authenticate each other with
the use of location informations and also we used location
threshold limit (L) for devices to restrict the access.
5.3.10 Device revocation using blockchain
IoT Devices tend to fail due to physical capture by Adver-
sary or power drains, or there is a need for deployment
of new IoT Devices in the same environment. Hence we
proposed the utilization of RACi to generate the secret
credentials with the help of blockchain network to deploy
the IoT Devices in the same environment.
5.3.11 IoTD anonymity property at device level
In proposed protocol, the IoT Devices are deployed in
“secure target field” with the help of RACi using private
Blockchain network. After deployment, the IoT Devices
has the secret credentials such as (h(I Di ), h(I DGW N ),
QCA , A3 , Li , P ). In this secret credentials, IoT Device
identity and GWN identity are not present in plain-text
format. Therefore, in the proposed protocol IoT Device
anonymity property is preserved at device level.
6 Performance analysis
6.1 Comparison of security properties
Table 3, shows the comparison of security features for
our protocol with other existing protocols [1, 23], [11].
Adeel et al. [1] proposed a protocol that is based on
mutual authentication with the involvement of server. Their
protocol may suffers from insider attack. It does not have
formal security analysis, dynamic device addition phase and
does not provides additional features as mentioned in Table
3. Malani et al. [23] scheme may suffers from insider attack
and does not provides additional features as mentioned in
Table 3. Das et al. [11] scheme does not provide device
Peer-to-Peer Netw. Appl.
anonymity & untraceability property, does not provide
IoT Device anonymity property at device level and may
possible for insider attack, where as our protocol provides
these security features and additional features. Hence,
proposed protocol withstands from well-known attacks and
also proposed protocol provides additional features when
compared to other protocols (Table 3).
6.2 Comparison of communication cost
In this section, we discuss the comparison of communica-
tion cost for proposed protocol and other existing protocols
in the authentication phase. For communication cost of pro-
posed protocol and other existing protocols proposed by
Adeel et al. [1], Malani et al. [23] and Das et al. [11], it
is assumed that identity (I Di and I Dj ) is 160 bits, time
stamp (T1 , T2 , T3 , T4 ) is 32 bits, random numbers (ri and
rj ) is 160 bits, hash value is 160 bits (SHA-1 hash func-
tion - [30]) and ECC point (Point P = (Px , Py ), where Px
and Py is x and y co-ordinates of elliptic curve (P = 160
bits +160 bits = 320 bits)) is 320 bits are based on Das
et al. [11] and Malani et al. [23] schemes. Furthermore, it
is assumed that location value (Li , Lj ) is 32 bits. In the
proposed protocol, the devices Di and Dj exchanged mes-
sages are h(I Di ), B1 , B2 , T1 , L1 = [MSG1] and h(I Dj ),
B3 , B4 , T3 , L2 = [MSG2]. These messages communica-
tion cost are [MSG1] = 160 + 320 + 320 + 32 + 160 = 992
bits and [MSG2] = 160 + 320 + 320 + 32 + 160 = 992 bits
respectively. The total communication cost is 1984 bits and
communicated message length is 2 for proposed protocol
and 2560, 2144, 3296 are communication cost and 6, 2, 3
are communicated message length for other existing proto-
cols i.e., Adeel et al. [1], Malani et al. [23] and Das et al.
[11] respectively. Table 4 shows the our protocol is takes
less communication cost, when compared to other existing
protocols.
6.3 Comparison of storage cost
For storage cost of proposed protocol and other existing
protocols such as Adeel et al. [1], Malani et al. [23] and
Das et al. [11], it is assumed that identity (I Di and I Dj )
is 160 bits, time stamp (T1 , T2 , T3 , T4 ) is 32 bits, random
numbers (ri and rj ) is 160 bits, hash value is 160 bits (SHA-
1 hash function - [30]) and ECC point (Point P = (Px ,
Py ), where Px and Py is x and y co-ordinates of elliptic
curve (P = 160 bits +160 bits = 320 bits)) is 320 bits are
based on Das et al. [11] and Malani et al. [23] schemes.
Furthermore, it is assumed that location value (Li , Lj ) is
32 bits, secret key is 160 bits and prime number is 160
bits. The proposed protocol Di has the stored values such
as (h(I Di ), h(I DGW N ), QCA , A3 , Li , P ) = [MSG]. The
proposed protocol storage cost of Di is calculated as [MSG]
Peer-to-Peer Netw. Appl.
Table 3 Comparison of various security features
Notations
Note: - = not provides the facility, ✗= attacks possible, ✓= attacks not possible, R1= Malani, S., et al. [23], R2= Das et al. [11], R3= Adeel et al. [1]
= (h(I Di ), h(I DGW N ), QCA , A3 , Li , P ) = 160 + 160 +
320 + 320 + 32 + 320 = 1312. The proposed protocol storage
cost is 1312 bits and other existing protocols storage cost is
also calculated in similar manner. Other protocols such as
i.e., Adeel et al. [1], Malani et al. [23] and Das et al. [11]
protocols are 960, 1600 and 1760 respectively (Table 5).
Adeel et al. [1] storage cost is less when compared to
proposed protocol, but Adeel, A., et al. [1] protocol does not
provides some security properties as mentioned in Table 3.
6.4 Comparison of computation cost
Computation cost is the total cryptographic operation and
other operation used in proposed protocol and other existing
protocols. For computation cost, it is assume that, TH is
hash function, TP is ECC point multiplication and TP A
is ECC point addition. Proposed protocol takes 3TH +
TP for registration and 14TH + 3TP for authentication.
Table 4 Comparison of communication cost (in bits)
Schemes Communicated messages No of bits
Malani et al. [23] 2 2144
Das, et al. [11] 3 3296
Adeel et al. [1] 6 2560
Ours 2 1984
R1 R2 R3 Ours
Adeel et al. [1] protocol is taking 2TH for registration and
23TH for authentication. Malani et al. [23] is taking TP +TH
for registration and 16TH + 12TP + 4TP A for authenti-
cation whereas, Das A.K., et al. [11] is taking 2TP + TH for
registration and 12TH + 14TP + 6TP A for authentication.
Our proposed protocol provides less computation cost
(Table 6) when compared to Malani et al. [23] and Das et al.
[11] protocols and higher to Adeel, A., et al. [1] protocol,
but Adeel et al. [1] protocol does not provides some security
features (Table 3).
6.5 Comparison of protocols execution time
For proposed protocol and other existing protocols it is
calculated that the execution time for TH , TP and TP A
are ≈ 0.056, ≈ 13.405 and ≈ 0.081 ms respectively
as mentioned in Das, A.K., et al. [11]. This execution
time is rough estimation based on user device (mobile
Table 5 Comparison of storage cost (in bits)
Schemes Storage cost of secret values in smart card (bits)
Malani et al. [23] 1600
Das et al. [11] 1760
Adeel et al. [1] 960
Ours 1312

Table 6 Comparison of
computation cost Schemes RP LA
Di Dj
Malani et al. [23] – –
Das et al. [11] – –
Adeel et al. [1]
Ours – –
device) as mentioned in [32]. The computation cost for
proposed protocol is 14TH + 3TP for authentication.
The total execution time taken for proposed protocol for
authentication (14TH + 3TP = 14*0.056 + 3*13.405 =
40.999 ms) is ≈ 40.999 ms. The total execution time taken
authentication phase for other existing protocols such as
Malani et al. [23] is (16TH + 12TP + 4TP A = 16*0.056 +
12*13.405 + 4*0.081 = 162.08 ms) ≈ 162.08 ms, Das et al.
[11] is (12TH + 14TP + 6TP A = 12*0.056 + 14*13.405 +
6*0.081 = 188.828 ms) ≈ 188.828 ms and Adeel et al. [1]
is (23TH = 23*0.056 = 1.288 ms) is ≈ 1.288 ms (Table
7). The execution time for proposed protocol is less, when
compared to Malani et al. [23], Das et al. [11] protocols
and higher to Adeel et al. [1], but Adeel et al. [1] protocol
does not provides some security properties (as mentioned in
Table 3).
6.6 Results and discussion
In this article, we proposed a Blockchain based Internet of
Things (IoT) Device to Device Authentication Protocol for
Smart City Applications using 5G Technology. In the pro-
posed protocol, IoTDs registrations are performed using pri-
vate Blockchain network and IoTDs authentication are per-
formed without RAC/GWN. From the security analysis part,
the proposed protocol is secured from well-known attacks
and also proposed protocol provides additional features. The
performance of the proposed protocol shows that, proposed
protocol provides better performance as well as security.
Table 7 Comparison of execution times of proposed protocol (authen-
tication phase) with the existing methods (in ms)
Schemes Total rough execution time (milliseconds (ms))
Malani et al. [23] ≈ 162.08
Das, et al. [11] ≈ 188.828
Adeel et al. [1] ≈ 1.288
Ours ≈ 40.999
Peer-to-Peer Netw. Appl.
RAC Di Dj RAC
TP + TH 7TH + 6TP + 2TP A 8TH + 6TP + 2TP A –
2TP + TH 6TH + 7TP + 3TP A 6TH + 7TP + 3TP A –
2TH 9TH 6TH 8TH
3TH + TP 7TH + 2TP 7TH + TP –
7 Conclusion
In this paper, we presented a Blockchain based Internet
of Things (IoT) Device to Device Authentication Proto-
col for Smart City Applications using 5G Technology. The
BIDAPSCA5G protocol utilize the “SHA-1 and ECC func-
tion”. The mutual authentication of proposed protocol is
performed between two IoTDs based on secret credentials,
which are loaded at deployment phase. The detailed security
analysis of proposed protocol was performed using “formal
security analysis using RoM model”, “formal security veri-
fication using Proverif tool” and informal security analysis.
From the security analysis part, proposed protocol secured
from well-known attacks. The proposed protocol provides
additional features such as authentication using device loca-
tion, IoT Device anonymity property at device level, IoT
Device registration and revocation using blockchain. Also,
it provides better performance in terms of security prop-
erties, communication cost, computation cost, storage cost
and protocols execution time when compared with existing
protocols.
In future work, we consider to provide the security for
IoTDs deployed in unsecured environment, intend to con-
sider the blockchain network in IoT Devices authentication.
Congestion and energy related issues are to be considered
in IoTDs. The proposed protocol can be extended for smart
banking, smart industry and smart logistic applications.
Appendix A
Highlights of proposed protocol
– To propose a Blockchain based Internet of Things (IoT)
Device to Device Authentication Protocol for Smart
City Applications using 5G Technology
– Proposed protocol performs authentication between IoT
Device to IoT Device without the involvement of
RAC/GWN
– Proposed protocol registration process is perform
through private blockchain with the help of GWN
Peer-to-Peer Netw. Appl.
– Proposed protocol authentication perform based on the
location of the device, which is not proposed in the
existing works
– Proposed protocol performs better performance as
well as provides additional features such as location
based authentication of IoT Device, IoT Device
revocation phase using blockchain and blockchain
based registration of IoT Devices respectively
– Proposed protocol security verification is performs
through formal and informal analysis. Formal analysis
is perform through Proverif tool, informal analysis
is perform through various security assumptions, and
also formal security verification is perform through the
Random Oracle Model (RoM).
Appendix B
Formal verification of proposed protocol using Proverif
tool The formal security verification of proposed protocol
simulated in this section. The Fig. 5 represents declaration
of proposed protocol, Fig. 6 represents registration and
authentication process, Fig. 7 represents registration and
authentication process, Fig. 8 represents Di and Dj queries
and Fig. 9 represents proposed protocol queries result.
References
1. Adeel A, Ali M, Khan AN, Khalid T, Rehman F, Jararweh Y,
Shuja J (2019) A multi-attack resilient lightweight iot authen-
tication scheme. Transactions on Emerging Telecommunications
Technologies, pp e3676
2. Ahuja SP, Wheeler N (2020) Architecture of fog-enabled and
cloud-enhanced internet of things applications. Int J Cloud Appl
Comput (IJCAC) 10(1):1–10
3. Ali R, Pal AK (2018) An efficient three factor–based authentica-
tion scheme in multiserver environment using ecc. Int J Commun
Syst 31(4):e3484
4. Ali R, Pal AK, Kumari S, Karuppiah M, Conti M (2018) A secure
user authentication and key-agreement scheme using wireless
sensor networks for agriculture monitoring. Futur Gener Comput
Syst 84:200–215
5. Aman MN, Chua KC, Sikdar B (2017) Mutual authentication in
iot systems using physical unclonable functions. IEEE Internet
Things J 4(5):1327–1340
6. Bellare M, Rogaway P (1993) Random oracles are practical: A
paradigm for designing efficient protocols. In: Proceedings of the
1st ACM conference on Computer and communications security,
pp 62–73
7. Berenjian S, Hajizadeh S, Atani RE (2019) An incentive security
model to provide fairness for peer-to-peer networks. In: 2019
IEEE Conference on Application, Information and Network
Security (AINS). IEEE, pp 71–76
8. Blanchet B, Smyth B, Cheval V, Sylvestre M (2018) Proverif
2.00: automatic cryptographic protocol verifier, user manual and
tutorial. Version from 05–16
9. Cao J, Ma M, Li H, Ma R, Sun Y, Yu P, Xiong L (2019) A survey
on security aspects for 3gpp 5g networks. IEEE Communications
Surveys & Tutorials
10. Challa S, Wazid M, Das AK, Kumar N, Reddy AG, Yoon E-
J, Yoo K-Y (2017) Secure signature-based authenticated key
establishment scheme for future iot applications. IEEE Access
5:3028–3043
11. Das AK, Wazid M, Yannam AR, Rodrigues JJ, Park Y
(2019) Provably secure ecc-based device access control and key
agreement protocol for iot environment. IEEE Access 7:55382–
55397
12. Dolev D, Yao A (1983) On the security of public key protocols.
IEEE Trans Inf Theory 29(2):198–208
13. Ferrag MA, Maglaras LA, Janicke H, Jiang J, Shu L (2017)
Authentication protocols for internet of things: a comprehensive
survey. Security and Communication Networks 2017
14. Gubbi J, Buyya R, Marusic S, Palaniswami M (2013) Internet of
things (iot) A vision, architectural elements, and future directions.
Fut Gen Comput Syst 29(7):1645–1660
15. Gupta R (2019) Resource provisioning and scheduling techniques
of iot based applications in fog computing. Int J Fog Comput
(IJFC) 2(2):57–70
16. Hussain MM, Beg MS (2019) Using vehicles as fog infrastructures
for transportation cyber-physical systems (t-cps) Fog computing
for vehicular networks. Int J Softw Sci Comput Intell (IJSSCI)
11(1):47–69
17. Javaid U, Aman MN, Sikdar B (2018) Blockpro: Blockchain
based data provenance and integrity for secure iot environments.
In: Proceedings of the 1st Workshop on Blockchain-enabled
Networked Sensor Systems, pp 13–18
18. Kadhim AJ, Seno SAH (2019) Energy-efficient multicast routing
protocol based on sdn and fog computing for vehicular networks.
Ad Hoc Netw 84:68–81
19. Koblitz N (1987) Elliptic curve cryptosystems. Math Comput
48(177):203–209
20. Kocher P, Jaffe J, Jun B (1999) Differential power analy-
sis. In: Annual International Cryptology Conference. Springer,
pp 388–397
21. Li D, Deng L, Gupta B, Wang H, Choi C (2019) A novel cnn based
security guaranteed image watermarking generation scenario for
smart city applications. Inf Sci 479:432–447
22. Li N, Liu D, Nepal S (2017) Lightweight mutual authentication for
iot and its applications. IEEE Trans Sustain Comput 2(4):359–370
23. Malani S, Srinivas J, Das AK, Srinathan K, Jo M (2019)
Certificate-based anonymous device access control scheme for iot
environment. IEEE Internet Things J 6(6):9762–9773
24. Maurya AK, Sastry VN (2017) Fuzzy extractor and elliptic curve
based efficient user authentication protocol for wireless sensor
networks and internet of things. Information 8(4):136
25. Naghizadeh A, Berenjian S, Razeghi B, Shahanggar S, Pour NR
(2015) Preserving receiver’s anonymity for circular structured p2p
networks. In: 2015 12th Annual IEEE Consumer Communications
and Networking Conference (CCNC). IEEE, pp 71–76
26. Naghizadeh A, Berenjian S, Meamari E, Atani RE (2016)
Structural-based tunneling: preserving mutual anonymity for
circular p2p networks. Int J Commun Syst 29(3):602–619
27. Nakamoto S et al (2008) Bitcoin: A peer-to-peer electronic cash
system
28. Pena-lópez I et al (2005) Itu internet report 2005: the internet of
things
29. Psannis KE, Stergiou C, Gupta B (2018) Advanced media-based
smart big data on intelligent cloud systems. IEEE Trans Sustain
Comput 4(1):77–87
30. PUB F (1995) Secure hash standard. Public Law 100:235
 Peer-to-Peer Netw. Appl.

31. Roy S, Das AK, Chatterjee S, Kumar N, Chattopadhyay S, Sastry V. N. is currently

Rodrigues JJ (2018) Provably secure fine-grained data access working as Professor in the
control over multiple cloud servers in mobile cloud computing Institute for Development
based healthcare applications. IEEE Trans Ind Inf 15(1):457–468 and Research in Banking
32. Sethia D, Gupta D, Saran H (2018) Nfc secure element-based Technology (IDRBT), Hyder-
mutual authentication and attestation for iot access. IEEE Trans abad, India. He received
Consum Electron 64(4):470–479 his Ph.D. and M.Sc. from
33. Srinivas J, Das AK, Wazid M, Kumar N (2018) Anonymous Indian Institute of Technol-
lightweight chaotic map-based authenticated key agreement ogy, Kharagpur, India. His
protocol for industrial internet of things. IEEE Transactions on research and teaching interests
Dependable and Secure Computing include Operations Research,
34. Stergiou C, Psannis KE, Gupta B, Ishibashi Y (2018) Security, Multiple Objective Net-
privacy & efficiency of sustainable cloud computing for big data work Optimization, Security
& iot. Sustain Comput Inf Syst 19:174–184 Models, Mobile Computing,
35. Tewari A, Gupta B (2017) A lightweight mutual authentication Mobile Payments, Mobile
protocol based on elliptic curve cryptography for iot devices. Int J Governance, Fuzzy Opti-
Adv Intell Parad 9(2-3):111–121 mization and Fuzzy Control, Financial Engineering, Asset Liability
36. Tewari A, Gupta B (2020) Security, privacy and trust of different Management, Portfolio Optimization.
layers in internet-of-things (iots) framework. Fut Gen Comput
Syst 108:909–920
37. Wazid M, Das AK, Odelu V, Kumar N, Conti M, Jo M (2017)
Design of secure user authenticated key management protocol for
generic iot networks. IEEE Internet Things J 5(1):269–282
38. Wazid M, Das AK, Shetty S, Rodrigues JJPC, Park Y Srinivasulu Reddy U. received
(2019) Ldakm-eiot: Lightweight device authentication and key his Ph.D. from National Insti-
management mechanism for edge-based iot deployment. Sensors tute of Technology, Tiruchi-
19(24):5539 rappalli, India. M.Phil. &
39. Wu T-Y, Lee Z, Obaidat MS, Kumari S, Kumar S, Chen C-M MCA from Bharathidasan
(2020) An authenticated key exchange protocol for multi-server University, Tiruchirappalli,
architecture in 5g networks. IEEE Access 8:28096–28108 India. He is currently work-
40. Xie J, Tang H, Huang T, Yu FR, Xie R, Liu J, Liu Y (2019) A ing as Assistant Professor
survey of blockchain technology applied to smart cities Research in the Department of Com-
issues and challenges. IEEE Commun Surv Tutorial 21(3):2794– puter Applications, National
2830 Institute of Technology,
41. Zhang R, Xue R, Liu L (2019) Security and privacy on blockchain. Tiruchirappalli, India. He is a
ACM Comput Surv (CSUR) 52(3):1–34 life time member of the Com-
42. Zhou L, Li X, Yeh K-H, Su C, Chiu W (2019) Lightweight iot- puter Society of India (CSI).
based authentication scheme in cloud computing circumstance. His research interests include
Futur Gener Comput Syst 91:244–251 Big Data Analytics, Machine
43. Zhu Q, Loke SW, Trujillo-Rasua R, Jiang F, Xiang Y (2019) Learning and Bioinformatics.
Applications of distributed ledger technologies to the internet of
things A survey. ACM Comput Surv (CSUR) 52(6):1–34

Publisher’s note Springer Nature remains neutral with regard to

jurisdictional claims in published maps and institutional affiliations.

Manojkumar Vivekanan-
dan received the M.E degree
in Computer Science and
Engineering from Anna Uni-
versity, Chennai, India. He
is currently doing PhD at
National Institute of Technol-
ogy, Tiruchirappalli, India.
His research interest includes
Mobile Cloud Computing,
Internet of Things, Authen-
tication, Cryptography and
Blockchain.
Peer-to-Peer Netw. Appl.

Affiliations
Manojkumar Vivekanandan1,2 · Sastry V. N.1 · Srinivasulu Reddy U.2

Manojkumar Vivekanandan
vmanojk88@gmail.com
Sastry V. N.
vnsastry@idrbt.ac.in
1 Center for Mobile Banking (CMB), Institute for Development
and Research in Banking Technology (IDRBT), Hyderabad, India
2 Machine Learning and Data Analytics Lab, Department
of Computer Applications, National Institute of Technology,
Tiruchirappalli, India