Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

Contents lists available at ScienceDirect

Journal of King Saud University –

Computer and Information Sciences
journal homepage: www.sciencedirect.com

Provably secure authentication for the internet of vehicles

E Haodudin Nurkifli a,b,⇑, Tzonelih Hwang a
a
Department of Computer Science and Information Engineering, National Cheng Kung University, Tainan, Taiwan
b
Faculty of Computer Science, Universitas Singaperbangsa Karawang, West Java, Indonesia

a r t i c l e i n f o a b s t r a c t

Article history: Rapid technological development has far-reaching implications for every aspect of life, including trans-
Received 20 March 2023 portation. The emerging Intelligent Transportation System (ITS) based on the Internet of Vehicles (IoV)
Revised 10 August 2023 requires robust security measures due to the public channels used to communicate between vehicles
Accepted 19 August 2023
and trusted authorities. These channels create opportunities for adversaries to intercept and exploit
Available online 24 August 2023
the transmitted data, leading to severe attacks. Moreover, cars are often parked in public areas, making
them vulnerable to physical attacks such as theft of smart cards/devices, cloning, and impersonation. In
Keywords:
this paper, we propose a new protocol for IoV that addresses these security concerns. Our protocol offers
Internet of Vehicle
Attacks
user authentication based on biometrics, using a biometric key to prevent revealing data from theft of
PUF smart cards/devices. Additionally, we use The Physical Unclonable Function (PUF) to resist cloning
Biometric attacks. We have conducted an informal analysis, which confirms that our protocol fulfills security fea-
Analysis Formally tures. Furthermore, we have conducted a formal analysis using the RoR model and the Scyther tool to ver-
ify that our protocol achieves security properties and withstands well-known attacks. We also
demonstrate the time complexity and show that our protocol has low computation time. Therefore,
our protocol is secure and has a low computation time.
Ó 2023 The Author(s). Published by Elsevier B.V. on behalf of King Saud University. This is an open access
article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).

1. Introduction
It is predicted that the number of vehicles on the road and in the
network will increase in the next 10–20 years (Jia et al., 2016).
Rapid technological development has enormous implications for
the Intelligent Transportation System (ITS), which provides toll
payment, insurance, traffic information, and logistics management
services. Additionally, ITS allows the use of Autonomous Vehicles
(AVs). Unfortunately, the World Health Organization (WHO)
reported that the number of road accidents every year is approxi-
mately 1.25 million. Hence, the primary purpose of implementing
a transportation system and network is to provide convenience
and safety for passengers (Nidhal et al., 2014). ITS also plays a crit-
⇑ Corresponding author.
E-mail addresses: P78067011@gs.ncku.edu.tw, dudi.nurkifli@staff.unsika.ac.id (E
Haodudin Nurkifli), hwangtl@csie.ncku.edu.tw, hwangtl@mail.csie.ncku.edu.tw (T.
Hwang).
Peer review under responsibility of King Saud University. Production and hosting by
Elsevier.
Production and hosting by Elsevier
ical role as the backbone of the smart city by integrating the Inter-
net of Things (IoT) and the Internet of Vehicles (IoV).
In 2023, it is expected that billions of vehicles will be connected
to VANET (Vehicle Ad Hoc Network) as part of the implementation
of the Internet of Vehicles (IoV) (Azees et al., 2016). However, one
of the crucial problems in IoV is ensuring privacy, data protection,
and trusted management (Javaid et al., 2020), (Elhalawany et al.,
2019). Furthermore, vehicles can share acceleration, position, and
speed information with other vehicles (V2V) or with roadside units
(V2R) to exchange important information, such as accidents in a
particular region. Roadside units (RSUs) located alongside roads
can communicate with passing vehicles through internet access.
Today, AVs have shown considerable success and promise to
significantly improve driving comfort while reducing traffic colli-
sions with proper control (In et al., 2020). The IoVs provide drivers
and authorities with a wide range of equipment. However,
medium- and long-range radios and networking features make
cars vulnerable to new exploits and attacks. An adversary, for
example, may spread misleading information about non-existent
unsafe road conditions, mislead drivers, create a traffic jam, and
so on. Furthermore, modern vehicles have a new internal commu-
nication bus system that connects multiple controllers that control
vehicle components, including airbags, engines, and brake control.
Since the internal network commonly utilizes non-encrypted pro-

https://doi.org/10.1016/j.jksuci.2023.101721
1319-1578/Ó 2023 The Author(s). Published by Elsevier B.V. on behalf of King Saud University.
This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/).
E Haodudin Nurkifli and T. Hwang
tocols, an intruder may obtain access to it using the vehicle’s exter-
nal wireless interface and inflict severe harm. In the next ten years,
the probability of cyberattacks will rise by 20.3 percent (Report,
2015). Since certain VANET implementations can have life-or-
death implications, security designers must consider protecting
these networks from the very beginning. Security flaws must be
resolved before AVs are widely deployed.
The communication model in V2R or V2V using public channels
opens the attacker to eavesdrop on all messages and then conduct
severe attacks such as Sybil, DoS, replay, man-in-the-middle, tim-
ing, impersonation attacks, and data tampering. In addition to
these threats, the adversary can steal the device and obtain access
to a vehicle’s storage memory. The Roadside Unit (RSU) makes IoV
and especially the defense of AVs much more difficult. Vehicles
must store credential secrets, such as secret keys, to create a stable
VANET. As a result, they are more likely to be the victim of physical
threats, with the adversary revealing the secret keys.
The RSU is generally more secure than a vehicle because a lock,
camera, or another physical protection method protects the RSU.
However, the RSU remains the target of the attacker. The majority
of researchers in VANET focus on using a public key algorithm;
however, it cannot resolve the physical attack problem. Therefore,
we proposed a new protocol using user authentication based on
biometrics and Physically Unclonable Function (PUF) to resist
physical attacks on IoV.
Since vehicles move at high speeds, the security protocol for
IoVs must have a communication burden slightly. Mutual authen-
tication is an essential aspect of IoV. When communicating
between a vehicle and an RSU, both parties must authenticate each
other to ensure that data transmission comes from a legitimate
source. On the other hand, Authentication in IoVs must be fool-
proof and effective. Another essential criterion for IoV is the pro-
tection of anonymity, which means that an adversary should not
track the origins of communications. Furthermore, anonymity
means the adversary cannot obtain a real identity and cannot link
every message from one vehicle.
A protocol design that can achieve comprehensive security
properties is needed for the system based on the Internet. In this
research, we design security protocols specifically for the Internet
of Vehicles (IoVs), which can generally be applied in the Internet of
Things (IoT) environment. The industry can adopt our design, or
the government can adopt our protocol authentication to deploy
the intelligent transportation system. Additionally, our authentica-
tion protocol can serve as a reference for researchers working on
system security and mutual authentication. Our authentication
protocol can achieve security features and withstand attacks as
mentioned in 7.4, indicating that our protocol is very important
in the security system field.
This article proposes a new authentication solution for resolv-
ing the Internet of Vehicle problem, with the following
contributions:
a. Designing the adversary model for PUF authentication (as
shown in 3.3). This adversary model is used for evaluating
previous protocols and our proposed protocol.
b. Showing a comprehensive study of Aman et al.’s protocol
and also denoting cryptanalysis of their protocol.
c. Designing a secure, lightweight mutual authentication pro-
tocol that is efficient and suitable for the IoV.
d. The protocol achieves the following security properties: pri-
vacy preservation, anonymity, mutual authentication, per-
fect forward and backward secrecy (PFBS), session key
security, and physical security. Additionally, the protocol
withstands various attacks, including protection against
cloning, impersonation, DoS, tracking, and replay attacks
2
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
e. Analyzing the proposed protocol informally and formally
using the RoR model and Scyther tool to validate it. In addi-
tion, comparing with previous related protocols in terms of
performance and security feature achievements.
The roadmap for this manuscript is as follows: Section 2 pre-
sents a literature review, and Section 3 discusses materials and
definitions. Section 4 reviews Aman et al.’s protocol, and the crypt-
analysis of their protocol is presented in Section 5. Section 6 outli-
nes the proposed protocol, and the discussion and results are
shown in Section 7. Finally, we conclude our paper in Section 8.
2. Literature review
Many existing authentication protocols use public-key cryptog-
raphy algorithms in VANET, such as those presented by (Fuentes &
González-tablas, 2010), (Adigun et al., 2013), (Whyte et al., 2021),
and (Salem et al., 2014). However, a public-key cryptography algo-
rithm can increase the computational burden; hence, it is not suit-
able for devices with limited memory, such as smart cards and
sensors. Additionally, (Sulaiman et al., 2013) proposed the
Hashed-chain-based Authentication Protocol (HAP) for VANET
authentication using symmetric-key cryptography hash-based.
Their protocol is based on the assumption that every vehicle is
equipped with a hardware security module (HSM) that stores cre-
dentials in its memory, making it vulnerable to physical attacks.
Other research presented by (Fuentes & González-tablas, 2010)
and (Committee, 2013) proposed authentication protocols using
Elliptic Curve Cryptography (ECC) to achieve nonrepudiation based
on digital signature. However, their protocol has the same assump-
tion as (Fuentes & González-tablas, 2010), (Adigun et al., 2013),
(Whyte et al., 2021), and (Sulaiman et al., 2013); hence, it has sim-
ilar issues.
The industrial automotive sector has attempted to solve key
management and physical attack problems. For example, PT
Escript is an automotive cybersecurity industry that develops
Secure Hardware Extension (HSE) for companies such as Bay-
erische Motoren Werke (BMW) and Audi (Soja, n.d.). Other pro-
jects, such as E-safety Vehicle Intrusion Protected Applications
(EVITA) proposed by the European Union (EU), manage security
keys to provide physical security (Seudié & Gmbh, 2009). The cur-
rent project is Preserve Project, which develops an HSM based on
ECC and one of the public-key cryptography algorithms (Twente,
2015). The National Institute of Standards and Technology (NIST)
proposed the Federal Information Processing Standard (FIPS),
which consists of four levels ranging from low to high security.
For example, Level 1 achieves low security, and Level 4 provides
high security, including tamper detection and protection against
physical attacks (Jr, 2002). Trusted Computing Group (TCG) pro-
posed a security key module for authentication and encryption,
called the Trusted Platform Module (TPM). TPM is an external
peripheral that stores a secret key in non-volatile memory.
Additionally, most protocols that rely on HSM to achieve secu-
rity properties based on secret credentials store them in internal
memory, making it so that only the HSM can access the private
data. However, this solution is vulnerable to side-channel attacks.
On the other hand, physical security based on tamper-resistant cir-
cuitry is very expensive. Therefore, many protocols use external
memory buses for data sharing.
In their proposal, (X. Zhang & Chen, 2019) suggested a block-
chain solution for securely sharing and storing data in VANET. Ini-
tially, mutual authentication between the vehicle and trusted
authority is required before the vehicle can securely share the data.
However, their scheme has a high computational burden and lacks
scalability. Later, (Yahiatene, 2018) proposed the Software Define
E Haodudin Nurkifli and T. Hwang
Vehicle Social Network (SDVSN) protocol, which uses certificates
and achieves data integrity through vehicle authentication.
Another proposed solution is PoolCoin by (Kaci, 2020), which is
based on a distributed model for managing users in the network.
Their scheme assumes that one regional RSU gateway encom-
passes several RSUs for data sharing. (Yang et al., 2019) proposed
a decentralized model for managing users in VANET. (Lei et al.,
2017) proposed a blockchain-based solution that discusses key
management. However, most existing protocols in VANET are vul-
nerable to physical attacks. In summary, while several blockchain-
based proposals exist for securing data in VANET, most of them
suffer from scalability and computational issues and are vulnerable
to physical attacks.
(Mcgrath et al., 2019), (Herder et al., 2014), (Babaei & Schiele,
2019) introduced PUFs as an alternative to resolving the physical
attack problem, based on the uniqueness of PUFs, which are
applied in sensors or smart cards with limited resources (see defi-
nition 2 in Subsection 3.2.2 for a more detailed discussion of secure
PUFs). Other researchers have applied protocol security PUF-based
for wireless sensor networks or the Internet of Things, including
(Javaid, 2019), (Aman, Basheer, & Sikdar, 2019), (Aman, Taneja,
et al., 2019), (Long et al., 2019), (Gope et al., 2019), (Chatterjee
et al., 2019), (Aman, Basheer, & Member, 2019), (Aman et al.,
2018), (Aman et al., 2020). However, Aman et al. pointed out that
the existing protocol is unsuitable for VANETs due to the high
mobility of vehicles. Additionally, the current PUF-based protocol
only highlights energy efficiency and not communication burden.
Recently, Aman et al. (Aman et al., 2021) proposed a security pro-
tocol PUF-based on VANETs. However, their protocol has a loop-
hole and fails to achieve several security properties; we present a
detailed discussion in Section 5.
Kaiping Xue et al.(Xue et al., 2022) proposed a Distributed
Authentication protocol using a smart contract for Roaming Service
in a vehicular mobile network. However, it employs weak anonym-
ity by encrypting the identity, and it can’t provide unlinkability and
untraceability. Additionally, the protocol does not incorporate an
unclonable device and also employs public cryptography, which
may increase the computational burden.
Wang Jing et al. (J. Wang et al., 2022) have researched protocol
security for multiserver authentication and key agreement in IoVs.
Their research utilizes a two-factor authentication involving iden-
tity and password. However, both identity and password are short
words and can be easily guessed. Hence, their protocol is vulnera-
ble to online and offline password-guessing attacks. Moreover,
their protocol may have weaknesses under the Dolev-Yao Model
Adversary, where the attacker can obtain the secret after guessing
the password and identity, potentially leading to various attacks,
including impersonation attacks.
Yazid Muhammad (Yazid et al., 2023) also proposed an Authen-
tication Method for Vehicle Monitoring IoT devices. However, their
protocol’s authentication does not provide security features,
including anonymity, untraceability, perfect forward security,
unlinkability, and perfect forward secrecy.
Zhang Han, Lai Yingxu, and Chen Ye (H. Zhang et al., 2023) have
researched protocol security methods. However, their protocol
shares a similar problem with Wang Jing et al.’s authentication
protocol; that is, their protocol is vulnerable to password-
guessing attacks, and it is fatalistic because their protocol fails to
maintain primary security after an attacker guesses the password.
The majority of current research does not provide an unclonable
device.
This article proposes a new security protocol for the Internet of
Vehicles. We consider the use of smart cards in intelligent vehicles.
Rapidly advancing technology makes it reasonable for intelligent
vehicles to be equipped with a smart card reader and biometric
input. On the other hand, the smart card is equipped with a phys-
3
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
ically unclonable function (PUF). User authentication can help
avoid stolen device/smart card attacks. Our protocol adopts the
network layer proposed by Aman et al. (Aman et al., 2021), which
includes a trusted authority, the RSU gateway, the RSU, and the
vehicle (as shown in Fig. 1).
3. Materials and methods
This section covers Preliminaries, and the Secure Definition of
Hash Function, PUF, and Adversary Model.
3.1. Preliminaries
This subsection briefly presents the preliminary background of
the Fuzzy Extractor (FE) and Physical Unclonable Function (PUF).
3.1.1. FE
FE has two functions: first, FE:GenðÞ is the function for generat-
ing the key and the helper data from the user’s biometric; the
equation is ðK u ; hdÞ ¼ FE:GenðBu Þ, where K u , Bu , and hd denote
Key, Biometric from the user, and helper data, respectively. Second,
FE:RecðÞ is the function for reconstructing the key from helper data
and the biometric; the equation is K u ¼ FE:Recðhd; B0u Þ. In realistic
conditions, the biometric input has noise; B0u is the noisy biometric
input. Bu denotes the biometric of a user. The approximation of the
Hamming distance between B0u and Bu must be lower than the
threshold (t); the equation is disðBu ; B0u Þ  t. Therefore,
ðK u ; hdÞ ¼ FE:GenðBu Þ ! K u ¼ FE:Recðhd; B0u Þ. The similarity of the
original and noisy biometric input is the foundation of a successful
FE. This article employs the fuzzy extractor to derive a key K u from
Biometric Bu , where the equation is ðK u ; hdÞ ¼ FE:GenðBu Þ. A fuzzy
extractor is also utilized to create a non-stable PUF to obtain stable
output; a key is produced from the response input using a fuzzy
0
extractor, where the equation is ðfkRSU ; hdRSU Þ ¼ FE:GenðRiRSu Þ. The
keys are reconstructed from the response and help data using
Fuzzy Extractor Reconstruction, where the equation is

0 
fkRSU ¼ FE:Rec RiRSu ; hdRSU (Dodis et al., 2004) and (Gope & Sikdar,
2019).
3.1.2. PUF
The PUF is a unique characteristic in the manufacturing process
in the fabrication of a chip to map Challenge C to a Response R (E.
Suh & Devadas, 2007); The equation formally is (R) = PUF(C). The
advantage of the PUF is that it is hard to clone (Bohm & Hofer,
2012). PUF has two types: Non-ideal PUF and ideal PUF. The non-
ideal PUF, where temperature can cause PUF to give a varied
response output even with the same input of Challenge C, can be
stabilized using a fuzzy extractor (Tuyls & Batina, 2006), (Dodis
et al., 2004).
While the stable PUF provides the same response when insert-
ing the same set of challenges, researchers have recently created an
ideal PUF that guarantees a 0% Bit-Error Rate even if a non-stable
temperature occurs (Jeon et al., 2015), (Chuang et al., 2019), (Lu
et al., 2018), (W. Wang et al., 2018). In this article, the smart card
is equipped with a stable PUF, and the RSU is fitted with both non-
ideal PUF and a fuzzy extractor.
Based on the types, PUFs are divided into Weak PUF and Strong
PUF. Weak PUF is utilized for generating keys, while Strong PUF is
used for authentication methods. The architecture of Strong PUF
includes Optical PUF and Arbiter PUF. On the other hand, the archi-
tecture of Weak PUF includes Ring-Oscillator PUF and SRAM PUF
(Herder et al., 2014). Additionally, several researchers have
extended the usage of PUFs to encryption and decryption processes
(Choi et al., 2010), (Kleber et al., 2015), and (Guo et al., 2018).
E Haodudin Nurkifli and T. Hwang
Fig. 1. System Architecture.
3.2. Secure definition of hash function and PUF
This subsection briefly presents the secure definition of Hash
Function and PUF.
3.2.1. Definition 1(The security of hash function)
The hash function is safe according to its formal specification.
Let h : f0; 1g ! f0; 1gn where the equation denotes an input bit
of any length resulting in an output bit of a fixed length. The prob-
ability of an adversary locating a collision of a hash function at a
specific time is Adv A ðtÞ ¼ Pr½ðx1 ; x2 Þ2R A : x1 –x2 ; hðx1 Þ ¼ hðx2 Þ,
Hash
where PrðXÞ is the probability of X being chosen randomly, and
x1 and x2 are strings that A will randomly pick. Additionally, the
maximum time an adversary can obtain a collision of the hash
function is Adv A
Hash
ðtÞ  / (Gope et al., 2019).
3.2.2. Definition 2(The security of PUF)
When PUF 1 generates output response R1 andR2 2 f0; 1gk with at
least d1 variance for two input challenges, a secure PUF is obtained.
If an input challenge C 1 results in different output responses
R1 andR2 2 f0; 1gk for any two different PUFs ðPUF 1 ; PUF 2 Þ, then
C 1 andC 2 2 f0; 1gk . Consequently, Pr½HDðPUF 1 ðC 1 Þ; PUF 1 ðC 2 ÞÞ >
d1  ¼ 1  e, and Pr½HDðPUF 1 ðC 1 Þ; PUF 2 ðC 1 ÞÞ > d2  ¼ 1  e. Here, d1
and d2 give the PUF’s error tolerance limits, and e, C 1 , and C 2 are
challenges that A randomly chooses. HD stands for Hamming Dis-
tance (Bian et al., 2020).
3.3. Adversary model definition
Our adversary model uses the Dolev-Yao (DY) adversary model
(Dolev & Yao, 1983) to evaluate Aman et al.’s protocol and our pro-
4
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
posal. In addition, we modified the DY model by adding the new
capabilities of adversaries C4, C5, and C6 to create a robust adver-
sary model. The proposed scheme remains secure under the attack
models. The powers of the adversary based on the DY model are as
follows:
a. C1: The adversary can intercept and eavesdrop on all the
transmitted messages via the public channel between the
vehicle, the RSU, the RSU gateway, and the Trusted
Authority.
b. C2: The adversary can modify and delete the data.
c. C3: The adversary can send and reply to a message as one
participating in the parties, e.g., one vehicle. This attack is
called an active attack.
Furthermore, we added the following capabilities to the DY
adversary model to create a robust adversary model:
d. C4: The adversary can steal Smart Card, vehicles, or the
RSU.
e. C5: The adversary can extract and compromise credentials
stored in their memory using a side-channel attack.
f. C6: The adversary can activate PUF by programming without
separating the PUF from the board unit (OBU).
4. The review of Aman et al.’s protocol
This section reviews the protocol of Aman et al., which includes
the system architecture, cryptography notation, registration phase,
authentication phase, update CRP phase, and weaknesses of the
protocol. A detailed discussion follows.
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

4.1. System architecture The third part is the registration between the RSU gateway and
the trusted authority. After the registration, the RSU gateway
This subsection denotes the system architecture. The system stores the shared key fkGS g, and the trusted authority stores the
architecture has four components: vehicle, RSU, RSU gateway, shared key and the identity of the RSU gateway fkGS ; IDG g. Every
and Trusted Authority, where the RSU gateway encompasses sev- registration phase occurs via a secure channel.‘‘
eral RSUs alongside the road. Before performing secure communi-
cation between the parties, the vehicle must initially register with
the Trusted Authorities, the RSU must register with the RSU gate- 4.4. Authentication phase
way, and the RSU gateway must register with the Trusted Author-
ity. Later, mutual authentication between the parties establishes a This subsection denotes the authentication phase as follows:
session key between the vehicle and the Trusted Authority (as Step 1: Several n Vehicles VC 1 ; VC 2 ;    ; VC n initiate communica-
shown in Fig. 1). Additionally, our authentication protocol adopts tion with the RSU, where the vehicles send
this system structure. M1 : fPIDV 1 ; a1 g; M 2 : fPIDV 2 ; a2 g;    ; M n : fPIDV n ; an g respectively
to the Roadside Unit (RSU).
Step 2: After receiving
4.2. Cryptography notations M 1 : fPIDV 1 ; a1 g; M 2 : fPIDV 2 ; a2 g;    ; M n : fPIDV n ; an g, the RSU
generates nonce N 2 , computes a response based on its stored chal-
This subsection presents the cryptography notation of Aman
lenge RiR ¼ PUFðC iR Þ, where i denotes the CRP’s index 1; 2;    ; n, that
et al.’s protocol, as shown in Table 1.


is ðC iR ; RiR Þ 2 C 1R ; R1R ; C 2R ; R2R ;    ; ðC nR ; RnR Þ. The RSU encrypts and

4.3. Registration phase aggregates M1 ;    ; Mn in one message M RG using RiR , namely

MRG ¼ EncRi fIDR ; M1 ; M 2 ;    ; M n ; N 2 g, computes the verification
R

The registration phases are divided into three parts: the first is
the registration between every vehicle and the trusted authority.
After the registration phase, every vehicle stores the pseudo-
identity and emergency pseudo-identity fPIDV , PIDemV g, and the
trusted authority stores the pseudo-identity of the vehicle, the
emergency pseudo-identity, challenge-response pairs, emergency
challenge-response pairs, and the identity for each vehicle
   
PIDV ; PIDemV ; ðC i ; Ri Þ; C emi ; Remi ; IDV .
The second part is the registration between the RSU and the
RSU gateway. After the registration, the RSU stores the challenge,
emergency challenge, pseudo-identity, and emergency pseudo-
n o
identity C iR ; C iemR ; PIDRSU ; PIDemRSU , and the RSU gateway stores
the challenge-response, emergency challenge-response, pseudo-
identity, emergency pseudo-identity, and the identity of the RSU
n

 o
C iR ; RiR ; C iemR ; RiemR ; PIDRSU ; PIDemRSU ; IDR .
code V RG ¼ HðIDR jjM RG kRiR kN 2 Þ, and then the RSU sends
PIDRSU ; M RG ; V RG to the RSU gateway.
Step 3: Upon receiving PIDRSU ; M RG ; V RG , the RSU gateway selects
CRP for the RSU’s identity IDR , verifies V RG , and decrypts
MRG ¼ DecRi fIDR ; M 1 ; M 2 ;    ; M n ; N 2 g to obtain M 1 ; M 2 ;    ; M n . Sub-
R
sequently, the RSU gateway generates a nonce N 3 , encrypts and
aggregates M1 ;    ; M n using secret key kGS in one message M GS ,
where MGS ¼ EnckGS fIDG ; M 1 ; M 2 ;    ; M n ; N 3 g, computes a verifica-
tion code V GS ¼ HðIDG kIDS jjM GS kkGS kN 3 Þ, and sends IDG ; MGS ; V GS
to the Trusted Authority.
Step 4: Upon receiving IDG ; M GS ; V GS , the Trusted Authority ver-
ifies V GS , decrypts M RG ¼ DeckGS fIDG ; M1 ; M 2 ;    ; M n ; N 3 g to obtain
M1 ; M 2 ;    ; M n . Subsequently, the Trusted Authority generates a


nonce N 4 , reads the CRPs C ij ; Rij based on the vehicle’s identity
respectively, generates Token T j ¼ fIDV j ; length; SK j ; P; N 4 g, com-

Table 1
Notations of Cryptographic Functions.

Notation Definition
PIDV j Pseudo identity each vehicles
PIDRSU Pseudo identity of RSU
IDR Identity of RSU
IDG Identity of the RSU gateway
IDS Identity of the Trusted Authority
IDV Identity of the vehicle
kAS The Shared key between vehicle and trusted authority
kGS The Shared-key between RSU Gateway and trusted authority
kRG Shared key between RSU and RSU gateway
ðC iA ; RiA Þ Challenge response pairs of vehicle
ðC iR ; RiR Þ Challenge response pairs of RSU
PUF Physical Unclonable Function
K V em The Shared-key emergency between vehicle and trusted authority used if occurs desynchronization, where
 
K V em ¼ kv 1 ; kv 2 ;    ; kv n
PIDV em The Pseudo-identity emergency between vehicle and trusted authority used if occurs desynchronization,
 
where PIDV em ¼ pidv 1 ; pidv 2 ;    ; pidv n
ðC V em ; RV em Þ The Challenge-Response Pairs emergency between vehicle and trusted authority used if occurs
   
desynchronization, where C V em ¼ cv 1 ; cv 2 ;    ; cv n and RV em ¼ r v 1 ; rv 2 ;    ; r v n
K GSem The Shared-key emergency between RSU gateway and trusted authority used if occurs desynchronization,
where K GSem ¼ fkGSem1 ; kGSem2 ;    ; kGSemn g
K RGem The Shared-key emergency between RSU and RSU gateway used if occurs desynchronization, where
K RGSyn ¼ fkRGSyn1 ; kRGSyn2 ;    ; kRGSynn g
PIDRSUem The Pseudo-identity synchronization between RSU and RSU gateway used if occurs desynchronization, where
PIDRSU em ¼ fpidrem ; pidrem ;    ; pidremn g
1 2

5
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

   
putes V SAj ¼ HðIDV j jT j kRij jaj kN 4 Þ, M SAj ¼ fC j ; EncRi T j ; V SAj g, Adversary Model in Subsection 3.3). The evaluation is discussed
j
below.
where j denotes the index of each vehicle 1; 2;    ; n. Additionally,
IDj ; length; SK j ; andP denote the identity of the vehicle, the length
5.1. The protocol fails to withstand stolen device/smart card attack
of the token, a session key for each vehicle, and the expiration of
the token, respectively. Finally, the Trusted Authority encrypts
The adversary steals the vehicle or smart card and obtains a
M SG ¼ EnckGS fT 1 ; T 2 ;    ; T n ; M SA1 ; M SA2 ;    ; M SAn ; N 4 g, computes the
pseudo-identity of the vehicle, known as PIDV. The adversary can
verification code V SG ¼ HðIDG jjIDS kM SG jjN 3 kN 4 Þ, and sends
then activate the physically unclonable function (PUF) by program-
M SG ; V SG to the RSU gateway. The Trusted Authority considers
  ming it without separating it from the on-board unit (OBU). Addi-
updating the pseudo-identity where PIDnew ¼ HðIDV kRi jaj Þ. j j j tionally, based on the DY model, the adversary can eavesdrop and
Step 5: Upon receiving M SG and V SG , the RSU gateway verifies obtain all data. The steps of the attack are as follows:
V SG , decrypts M SG ¼ DeckGS fT 1 ; T 2 ;    ; T n ; M SA1 ; M SA2 ;    ; M SAn ; N 4 g Step 1: The adversary obtains all messages, including M SA1 and
to obtain T 1 ; T 2 ;    ; T n ; M SA1 ; M SA2 ;    ; M SAn , and encrypts a1 , from the public channel. Here, M SA1 ¼ fC i1 ; EncRi fT 1 g; V SA1 g,
T 1 ; T 2 ;    ; T n ; M SA1 ; M SA2 ;    ; M SAn along with N 3 using RiR . Then the
1

T 1 ¼ fIDV 1 ; length; SK 1 ; P; N 4 g, and V SA1 ¼ HðIDV 1 jjT 1 kRi1 jja1 kN 4 Þ

RSU gateway computes the verification code
(Capability C1).
V GR ¼ HðIDG jjM GR kRiR jjN 2 kN 3 Þ, and considers updating the
 Step 2: The adversary steals the Smart Card/Vehicle/Device of

pseudo-identity of the RSU as PIDnew
RSU ¼ HðIDR jRiR kN 3 Þ. Finally, the the Vehicle (Capability C4).
RSU gateway sends IDG ; M GR , and V GR to the RSU in its area. Step 3: The adversary extracts the private data from the mem-
Step 6: Upon receiving IDG ; M GR , and V GR , the RSU verifies V GR , ory of the device/smart card using a side-channel attack. (Capabil-
decrypts MGR ¼ DecRi fT 1 ; T 2 ;    ; T n ; M SA1 ; M SA2 ;    ; M SAn ; N 3 g to ity C5).
R
Step 4: The adversary activates the PUF by programming, com-
obtain T 1 ; T 2 ;    ; T n ; M SA1 ; M SA2 ;    ; M SAn , and sends
MSA1 ; M SA2 ;    ; M SAn to each vehicle VC 1 ; VC 2 ;    ; VC n , respectively. puting Ri1 ¼ PUFðC i1 Þ, decrypting DecRi fT 1 g, and obtaining T 1 (Capa-
1

Step 7: In this step, we only describe one vehicle as an example. bility C6).
Upon receiving M SA1 , the vehicle generates Ri1 ¼ PUFðC i1 Þ, decrypts Step 5: After the adversary obtains T 1 ; Ri1 , and a1 , the adversary
DecR1 fT 1 g to obtain T 1 , and verifies V SA1 . Finally, the vehicle verifies V SA1 . If the adversary can verify V SA1 , it means that the
i

updates its pseudo identity as PIDnew ¼ HðIDV 1 kRi1 jja1 jÞ. Each vehi- adversary has obtained the correct T 1 and Ri1 .
1
Based on the evaluation aforesaid, it can be concluded that
cle runs similar steps.
Aman et al.’s protocol cannot withstand a stolen device/vehicle
attack.
4.5. CRP update phase
5.2. The protocol fails to withstand impersonation attack of smart card
This Subsection presents the CRP update phase as follows:
Step 1: The Trusted Authority generates a nonce N 1 and selects
After the adversary obtains T 1 ; SK 1 ; andRi1 , the adversary can
CRP for one vehicle, for example, IDV A ; ðC iA ; RiA Þ. The Trusted Author- impersonate the vehicles in the current session using current
i
ity then generates a new challenge C new
A , encrypts it with SK 1 . Additionally, the adversary can impersonate for the next ses-
EncRi fC new
i
; N 1 g, and calculates M 1 ¼ PIDiA ; C iA ; EncRi fC new ; N 1 g.
i
sion; the steps for impersonating the vehicles are as follows:
A A
A A
Step 1: The adversary can update the new pseudo-identity of
Finally, the Trusted Authority computes the verification code
vehicle PIDnew ¼ HðIDV 1 kRi1 jja1 jÞ, the adversary can use the new
V 1 ¼ HðIDV A jjM 1 kN 1 kRiA Þ and sends M 1 and V 1 to vehicle A. 1
pseudo-identity of vehicle for next session.
Step 2: Vehicle A receives M1 and V 1 . It then generates
i i
Step 2: the adversary generates a nonce b1 and sends
RiA ¼ PUFðC iA Þ, decrypts DecRi fC new ; N 1 g to obtain C new and N 1 , M1 ¼ fPIDnew
1 , b1 g to the RSU.
A A
A

and verifies V 1 . Vehicle A subsequently generates a nonce N 2 and Step 3: the RSU generates a nonce N 2 , encrypts and aggregates it
calculates Rnew
i
¼ PUFðC new
i
Þ. It encrypts M2 ¼ EncRi fRnew ; N 1 ; N 2 g,
i
in one message M RG ¼ EncRnew
R
fIDR ; M 1 ; N 2 g,
A A A A
V RG ¼ hðIDR jjM RG kRnew new
R kN 2 Þ, and sends PIDRSU ; M RG ; V RG to the RSU
calculates the verification code V 2 ¼ HðIDV A jjM 2 kN 1 kN 2 kRiA Þ, and
gateway.
sends M 2 and V 2 to the Trusted Authority.
Step 4: Until the final step of the authentication phase, the ser-
Step 3: Upon receiving M 2 and V 2 , the Trusted Authority
i i ver recognizes the party as the legitimate user. Therefore, Aman
decrypts M 2 ¼ DecRi fRnew
A ; N 1 ; N 2 g using RiA and obtains Rnew
A ; N1 , et al.’s protocol fails to withstand an impersonation attack.
A

and N 2 . The Trusted Authority then verifies V 2 , updates the

i
pseudo-identity of vehicle PIDnew
A ¼ HðIDV A jjN 2 kRnew
A Þ, generates a 5.3. The protocol fails to achieve secret session key
nonce N3 , computes the verification code
V 3 ¼ HðIDV A jjN 2 kN 3 kRnew
i
Þ, and sends V 3 to vehicle A. Finally, the The adversary decrypts DecRi fT 1 g using Ri1 and obtains T 1 ,
A 1

Trusted Authority stores a new pseudo-identity, a new challenge, where T 1 ¼ fIDV 1 ; length; SK 1 ; P; N 4 g, hence the adversary obtains
and a new response of vehicle PIDnew new
; Rnew
i i
current session key SK 1 . Additionally, the adversary has the ability
A ; CA A .
Step 4: Vehicle A receives V 3 and verifies it. Subsequently, the to impersonate the vehicle and obtain future session key SK new . For
vehicle A updates and stores a new pseudo-identity this reason, Aman et al.’s protocol fails to achieve session key
i security.
PIDnew
A ¼ HðIDV A jjN 2 kRnew
A Þ.
5.4. The protocol fails to achieve anonymity
5. The cryptanalysis of Aman et al.’s protocol
Anonymity must achieve three security properties; hiding the
This section demonstrates security weaknesses in Aman et al.’s actual identity, unlinkable and untraceable. Unfortunately, in
protocol when evaluated under the DY model (see Definition of Aman et al.’s protocol, after the attacker impersonates a legitimate
6
E Haodudin Nurkifli and T. Hwang
vehicle, the adversary also can obtain new challenges (as shown in
5.1 and 5.2). The proof that the protocol of Aman et al. fails to
achieve anonymity based on linkable and traceable messages is
as follows.
Step 1: the adversary eavesdrops on all messages M 1 ; V 1 ; M 2 ; V 2 ,
V 3 in a public channel.
Step 2: the adversary steals the vehicle and activates the PUF by
programming without separating PUF from OBU.
Step 3: the adversary computes RiA ¼ PUFðC iA Þ based on C iA in
i e. Physical Security: Even if an attacker carries out a dangerous
message M 1 ¼ PIDiA ; C iA ; EncRi fC new
A ; N 1 g. The adversary decrypts
A attack, such as stealing the device/smart card and conduct-
i i
DecRi fC new
A ; N 1 g and obtain new challenge C new
A .
A
Step 4: the attacker compares the new challenge with all mes-
sages in the new session. If the new challenge is equal to the new
challenge eavesdropped from the public channel, thus the adver-
sary knows that the new challenge is sent by the same vehicle.
The proof above shows that Aman et al.’s protocol cannot
achieve anonymity.
Furthermore, the protocol suffers from the insecurity of the
RSU. The evidence of the RSU’s insecurity is as follows:
5.5. The protocol is vulnerable to stolen RSU attacks
Step 1: The attacker obtains all data from the public channel,
including MRG ¼ EncRi fIDR ; M 1 ; M 2 ;    ; M n ; N 2 g.
R
Step 2: The attacker steals the RSU.
Step 3: The attacker extracts private data from the memory of
n o
the RSU, which is C iR ; C iemR ; PIDRSU ; PIDemRSU .
Step 4: The attacker activates the PUF and generates
RiR ¼ PUFðC iR Þ.
Step 5: The attacker decrypts M RG ,
MRG ¼ DecRi fIDR ; M 1 ; M 2 ;    ; M n ; N 2 g, to obtain M 1 ; M 2 ;    ; M n .
R
The attacker obtains all data, including the private data IDR and
RiR . Therefore, the protocol is vulnerable to a Stolen RSU attack.
5.6. The protocol cannot achieve anonymity of RSU
After the attacker generates RiR ¼ PUFðC iR Þ and decrypts
MRG ¼ DecRi fIDR ; M 1 ; M 2 ;    ; M n ; N 2 g, the attacker obtains the iden-
R
tity of the RSU. Therefore, the protocol fails to achieve anonymity
for the RSU.
6. Proposed authentication protocol
This section presents our proposed protocol, including The
security mechanism, the cryptographic notations, assumptions,
registration phase, mutual authentication, and CRP updates.
6.1. The security mechanism
We define the security mechanism, where our protocol must
fulfill security requirements to claim that it provides security in
the IoVs field. The security mechanism is as follows:
a. Anonymity, Untraceability, Unlinkability: The protocol must
ensure that external entities do not possess knowledge of
the actual identities of the parties involved. It must prevent
the tracing of the owner of transmitted messages in the
communication channel. Moreover, attackers should not be
able to link every message published in the public channel.
b. Mutual Authentication: The protocol must ensure that the
parties can ascertain that the communication is occurring
between the correct parties. Additionally, it must achieve
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
freshness to indicate that the message has not been used
before, ensuring secure mutual authentication.
c. Perfect Forward and Backward Secrecy (PFBS): The protocol
must guarantee that both old and future secrets are impos-
sible for attackers to obtain.
d. Session Key Security: The protocol must provide that the
session key remains confidential. Furthermore, the session
key must be updated for each session, and there should be
no relationship between past and future session keys.
ing a side-channel attack, they should be unable to access
secret data. This is due to the protocol’s protection of the
secret data. Additionally, the protocol’s authentication pro-
vides an unclonable device.
6.2. Notations of cryptography Function
This subsection presents the notations of the cryptography
functions throughout this paper. The cryptography functions are
shown in Table 2.
6.3. Registration phase via secure channel
There are three registrations that take place before the protocol
is deployed: one between the vehicle and the trusted authority,
another between the RSU gateway and the trusted authority, and
a third between the RSU and the RSU gateway. The registration
phases are as follows.
6.3.1. The registration between vehicle and Trusted Authority
where In this subsection, we describe the registration of the vehicle
and trusted authority as follows:
Step 1: Vehicle A sends its identity and registration request
M1 : fIDV ; RegistrationReq to the Trusted Authority.
Step 2: The Trusted Authority generates PIDV , kAS , C iA , computes
synchronization of key, pseudo-identity, and challenge, where
  n o
K V Syn ¼ kv 1 ; kv 2 ;    ; kv n , PIDV Syn ¼ pidv 1 ; pidv 2 ;    ; pidv n ,
 
C V Syn ¼ cv 1 ; cv 2 ;    ; cv n . The Trusted Authority issues the smart
card, the smart card stores PIDV ; kAS ; K V Syn ; PIDV Syn , then it sends
M2 : fSmart card;C iA ; C V Syn g to Vehicle A.
Step 3: The user inserts the smart card into the smart card
reader, and the vehicle generates the response and synchronization


of response RiA ¼ PUF C iA ; RV Syn ¼ PUFðC V Syn Þ. The user imprints his/
her biometricBIOuser , and the device computes:
ðK Bio ; hdv Þ ¼ FE:GenðBIOuser Þ, computes verification code for user
authentication V ¼ hðhdv kK Bio kIDV Þ, the vehicle encrypts every cre-
dential PIDV ¼ PIDV  hðK Bio Þ, PIDV Syn ¼ PIDV Syn  hðK Bio Þ,

K V Syn ¼ K V Syn  hðK Bio Þ, IDV =IDV  hðK Bio Þ, kAS =kAS  hðK Bio Þ. The smart

card stores ; hdv , IDV , PIDV , kAS , K V Syn ; PIDV Syn . Finally, the vehicle
sends M 3 : fRiA ; RV Syn g to the Trusted Authority.
Step 4: After receiving M 3 : fRiA ; RV Syn g, the Trusted Authority
stores PIDV ; kAS ; C iA ; RiA ; K V Syn ; PIDV Syn ; C V Syn ; RV Syn .
6.3.2. The registration between the RSU gateway and trusted authority
This subsection describes the registration of the RSU gateway
and Trusted Authority as follows:
Step 1: The RSU gateway sends its identity and registration
request M1 : fIDG ; RegistrationReq g to the Trusted Authority.
Step 2: The Trusted Authority generates the shared key, syn-
chronization of the shared-key kGS ,
K GSSyn ¼ fkGSSyn1 ; kGSSyn2 ;    ; kGSSynn g, the Trusted Authority copies
7
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

Table 2
Notations Of Cryptography Functions.

Notation Definition
PIDV j Pseudo identity each vehicles
PIDRSU Pseudo identity of RSU
IDR Identity of RSU
IDG Identity of the RSU gateway
IDS Identity of the Trusted Authority
IDV Identity of the vehicle
kAS The Shared key between vehicle and trusted authority
kGS The Shared-key between RSU Gateway and trusted authority
kRG Shared key between RSU and RSU gateway
ðC iA ; RiA Þ Challenge response pairs of device
PUF Physical Unclonable Function of device
PUF RSU Physical Unclonable Function of RSU
0
ðC iRSU ; RiRSu Þ Challenge-Response pairs of RSU
K V Syn The Shared-key synchronization between vehicle and trusted authority used if
 
occurs desynchronization, where K V Syn ¼ kv 1 ; kv 2 ;    ; kv n
PIDV Syn The Pseudo-identity synchronization between vehicle and trusted authority used
 
if occurs desynchronization, where PIDV Syn ¼ pidv 1 ; pidv 2 ;    ; pidv n
ðC V Syn ; RV Syn Þ The Challenge-Response Pairs synchronization between vehicle and trusted
 
authority used if occurs desynchronization, where C V Syn ¼ cv 1 ; cv 2 ;    ; cv n and
 
RV Syn ¼ r v 1 ; r v 2 ;    ; rv n ,
K GSSyn The Shared-key synchronization between RSU gateway and trusted authority
used if occurs desynchronization, where K GSSyn ¼ fkGSSyn1 ; kGSSyn2 ;    ; kGSSynn g
K RGSyn The Shared-key synchronization between RSU and RSU gateway used if occurs
desynchronization, where K RGSyn ¼ fkRGSyn1 ; kRGSyn2 ;    ; kRGSynn g
PIDRSUSyn The Pseudo-identity synchronization between RSU and RSU gateway used if
occurs desynchronization, where PIDRSU Syn ¼ fpidrSyn ; pidrSyn ;    ; pidrSyn g
1 2 n
0
ðC RSU Syn ; RiRSUSyn Þ The Challenge-Response Pairs synchronization between RSU and RSU gateway
 
used if occurs desynchronization, where C RSUSyn ¼ crsu1 ; crsu2 ;    ; crsun and
0
RiRSU Syn ¼ fr 0RSU1 ; r 0RSU 2 ;    ; r0RSUn g
BIOuser User’s biometric
FE Fuzzy extractor
FE:Gen FE:Gen generates the key from biometric input, where ðK Bio ; hdv Þ ¼ FE:GenðBIOuser Þ
FE:Rec FE:Rec reconstructs the key from Biometric and help data, where
K Bio ¼ FE:RecðBiouser ; hdv Þ
FERSU RSU is equipped Fuzzy extractor
FE:Gen generates the key from the response input, where
0
ðfkRSU ; hdRSU Þ ¼ FE:GenðRiRSu Þ, FE:Rec reconstructs the key from the response and

0 
help data, where fkRSU ¼ FE:Rec RiRSu ; hdRSU .

n o
and stores: IDG , kGS , K GSSyn , then sends M 2 : kGS ; K GSSyn to the RSU C enc
RSU Syn ¼ C RSU Syn  hðK RGSyn Þ. The RSU stores kRG , K RGSyn ; PIDRSU Syn ,
i 0 0
gateway. C enc enc i i
RSU ; C RSU Syn , and sends the responses RRSu ; RRSU Syn to the RSU
n o
Step 3: The RSU gateway receives M 2 : kGS ; K GSSyn from the gateway.
Step 4: After receiving the responses from the RSU, the RSU
Trusted Authority, and stores them.
i0 0
gateway stores IDR , kRG , K RGSyn ; PIDRSUSyn ; C iRSU ; RRSu ; C RSUSyn , and RiRSUSyn .
6.3.3. The registration between the RSU and the RSU gateway All registration phases go through a secure channel. Addition-
In this subsection, we describe the registration process between ally, to avoid desynchronization problems and DoS attacks, the
the RSU and the RSU gateway as follows: proposed protocol provides the synchronization of pseudo-
Step 1: The RSU sends M1 : fIDR ; RegistrationReq g to the RSU identity, shared keys for every participant, and synchronization
gateway. of challenge-response pairs between the vehicle and the trusted
authority.
Step 2: The RSU gateway generates kRG , PIDRSU , C iRSU ,
K RGSyn ¼ fkRGSyn1 ; kRGSyn2 ;    ; kRGSynn g,
PIDRSUSyn ¼ fpidrSyn ; pidrSyn ;    ; pidrSyn g, 6.4. Mutual authentication and session key establishment
 1
2 n

C RSUSyn ¼ crsu1 ; crsu2 ;    ; crsun . Then, it stores.

This subsection describes the authentication phase; every step
IDR , kRG , K RGSyn ; PIDRSUSyn , C iRSU , C RSUSyn , and sends
n o from the authentication phase is as follows.
i
M 2 : kRG ; K RGSyn ; PIDRSUSyn ; C RSU ; C RSUSyn to the RSU, Step 1: the user inserts the smart card into the smart card
0
Step 3: The RSU generates responses RiRSu ¼ PUF RSU ðC iRSU Þ, reader, then the user imprints his/her fingerprint Biouser , and the
0 device generates K Bio ¼ FE:GenðBiouser ; hdv Þ, computes
RiRSUSyn ¼ PUF RSU ðC RSUSyn Þ. It then encrypts the challenge and chal-
IDV ¼ IDV  hðhdv kK Bio Þ, computes verification code
lenge synchronization using the shared key and shared key syn- V  ¼ hðhdv jjK Bio kIDV Þ, checks V  ¼ ?V, if the verification V  is not
i
chronization, respectively. C enc i
RSU ¼ C RSU  hðkRG Þ, equal to V, the user authentication will be denied. Otherwise, the
8
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721


vehicle decrypts PIDV ¼ PIDV  hðK Bio Þ, kVS ¼ kVS  hðK Bio Þ; gener- shared key to PIDnew
V
new
¼ hðIDV A kRiA Þ and kVS ¼ hðkVS kRiA Þ respectively.
ates a nonce N 1 . The vehicle sends M 1 : fPIDV ; N 1 g to the RSU. It also encrypts PIDVnewenc
¼ PIDnew  hðK Biou Þ and
V
Step 2: The RSU generates a nonce N 2 , decrypts newenc new enc newenc
enci
kVS ¼  hðK Biou Þ, and stores
kVS PIDnew
and kVS . Additionally,
V
C iRSU ¼ C RSU  hðkRG Þ to obtain a challenge, generates the response the trusted authority also updates its pseudo-identity and shared
0
based on a challenge RiRSu ¼ PUF RSU ðC iRSU Þ, generates fixed-key key for future sessions to PIDnew ¼ hðIDV A kRiA Þ and kVS ¼ hðkVS kRiA Þ.
new
0
V

ðfkRSU ; hdRSU Þ ¼ FE:GenðRiRSu Þ, computes ¼ hdRSU  hðkRG Þ
hdRSU In the final session, each participant stores a new credential for
encrypts and aggregates in one message that is future sessions. We consider updating the credential to achieve
MRG ¼ ðIDR ; M 1 ; N 2 Þ  hðfkRSU Þ, computes verification code perfect forward and backward secrecy.

V RG ¼ hðIDR jjM RG kkRG jjN 2 kPIDRSU khdRSU Þ. The RSU sends
  
M2 : PIDRSU ; M RG ; hdRSU ; V RG to the RSU gateway. 6.5. The renewal CRP between vehicle and trusted authority

Step 3: The RSU gateway computes hdRSU ¼ hdRSU  hðkRG Þ to

0 
obtain help data and reconstructs fkRSU ¼ FE:Rec RiRSu ; hdRSU This subsection describes the updates of challenge-response
pairs (CRPs). The steps for updating CRPs are as follows:
using fuzzy-reconstruction to obtain a fixed key. Later, it decrypts
Step 1: The Trusted Authority generates a nonce N 1 and selects
ðIDR ; M 1 ; N 2 Þ ¼ M RG  hðfkRSU Þ and obtains IDR ; M 1 ; N 2 , verifies V RG

i
G. If the verification of V RG fails, the communication will be discon- C A ; RiA for vehicle A with IDA . The Trusted Authority selects PIDV A
tinued. Otherwise, the RSU gateway generates a nonce N 3 , encrypts and encrypts the challenge using the shared key
and aggregates it in one message that is C enc i
A ¼ C A  hðkVS kN 1 Þ. The Trusted Authority considers updating
MGS ¼ ðIDG ; M 1 ; N 3 Þ  hðkGS Þ, computes the verification code the challenge by generating a new challenge C new A . The Trusted
V GS ¼ hðIDG jjIDS kM GS kkGS kN 3 Þ, and sends M 3 : fIDG ; M GS ; V GS g to enc
Authority encrypts C new ¼ C new  hðRiA Þ, computes the verification
the Trusted Authority. A  A
 enc

Step 4: The Trusted Authority decrypts code V 1 ¼ hðIDV A jjN 1 kRiA jC iA kPIDV A kC new
A Þ, and sends PIDV A ; C enc
A ,

ðIDG ; M 1 ; N 3 Þ ¼ M GS  hðkGS Þ and obtains IDG ; M 1 ; N 3 , verifies V GS . If C new

enc
, N 1 , and V 1 to vehicle A.
A
the verification of V GS fails, the communication will be discontin- enc
Step 2: After receiving PIDV A ; C enc new
A , CA , N 1 , and V 1 , vehicle A
ued. Otherwise, the Trusted Authority generates a nonce N 4 and

 decrypts C iA ¼ C enc i
A  hðkVS kN 1 Þ and obtains C A . Vehicle A generates
reads CRP C iA ; RiA for PIDV . The Trusted Authority considers gener-
RiA ¼ PUFðC iA Þ and verifies V 1 . If the verification of V 1 fails, the com-
ating the Token, where TokenA ¼ fIDV A ; length; SK V A ; Tmexpire ; N 4 . The munication will be terminated. Otherwise, vehicle A decrypts
length and Tmexpire denote the length of the token and the expira- C new ¼ C new
enc
 hðRiA Þ and obtains the new challenge. Later, vehicle
A A
tion time of the token, respectively. The Trusted Authority com-
A generates a new response Rnew A ¼ PUFðC new
A Þ, encrypts the new
putes V SAA ¼ hðIDV A jjTokenA kRiA jjN 1 kN 4 Þ, C encrypt ¼ C iA  hðIDV A kkAS Þ,
encrypt
A
encrypt
response using RiA and kVS : N 2 ¼ Rnew
A  hðRiA kkVS Þ. Vehicle A updates
TokenA ¼ TokenA  hðRiA Þ, M SAA ¼ fC encrypt
A ; TokenA ; V SAA g, the pseudo-identity and shared key for future sessions, encrypts
MSG ¼ ðTokenA ; M SAA ; N 4 Þ  hðkGS Þ, and updates the new shared key enc newenc new
PIDnew
V ¼ PIDnew
V  hðK Biou Þ and kVS ¼ kVS  hðK Biou Þ, and stores
between the RSU gateway and the Trusted Authority by generating newenc newenc
new newenc new PIDV ; kVS . Vehicle A sends N 2 and V 2 to the Trusted Authority.
kGS w. It encrypts kGS ¼ kGS  hðkGS kN 3 Þ. The Trusted Authority
new Step 3: The trusted authority decrypts Rnew ¼ N 2  hðRiA kkVS Þ and
computes the verification code V SG ¼ hðIDG jjIDS kMSG jjN 3 kN 4 kkGS Þ new
A

newenc
obtains the new response RA . The trusted authority then verifies
and sends M4 : fM SG ; V SG ; kGS g to the RSU gateway. V 2 and updates the pseudo-identity and shared key between vehi-
Step 5: The RSU gateway decrypts cle A and the trusted authority. The updated values of
ðTokenA ; M SAA ; N 4 Þ ¼ M SG  hðkGS Þ and obtains TokenA ; M SAA ; N 4 , PIDnew
new
¼ hðIDV A kRiA Þ and kVS ¼ hðkVS kRiA Þ will be used for future ses-
V
new newenc
kGS ¼ kGS  hðkGS kN 3 Þ, verifies V SG . If the verification of V SG fails, sions. Finally, the trusted authority stores the new values of
new
the communication will be terminated. Otherwise, the RSU gate- C new new new
A ; RA ; PIDV , and kVS .
way encrypts and aggregates TokenA ; M SAA ; N 3 in one message, The renewal of CRPs is also performed between RSU and RSU
M GR ¼ ðTokenA ; MSAA ; N 3 Þ  hðfkRSU Þ. The RSU gateway updates the gateway in a similar way as mentioned above. Finally, the RSU
shared-key and pseudo-identity between RSU and the RSU gate- gateway stores the new {challenge-response pairs}, which will be
newenc new used for the next communication session.
way: kRG ¼ kRG  hðfkRSU kN 2 Þ and PIDnew
RSU ¼ hðIDR jjfkRSU kN 2 Þ. It
then computes the verification code,
newenc new
V GR ¼ hðIDG jjM GR kkRG jjIDR kN 2 kkRG Þ, and sends 7. Discussion and result
newenc
M 5 : fMGR ; kRG ; V GR g to all RSUs in its area. The RSU gateway
new new
stores kGS , kRG , and PIDnew This section discusses an informal analysis based on solid intu-
RSU for future sessions.
Step 6: The RSU decrypts ðTokenA ; M SAA ; N 3 Þ ¼ M GR  hðfkRSU Þ and itive reasoning to prove that our proposed protocol achieves secu-
new newenc rity features and withstands various attacks. In addition, we use a
obtains TokenA ; M SAA ; N 3 . It then decrypts kRG ¼ kRG  hðfkRSU kN 2 Þ
mathematical model, the Random Oracle Model (RoR model), and a
and verifies V GR . If the verification of V GR fails, the communication
programming model (Scyther tool) for formal analysis to
will be terminated. Otherwise, the RSU updates the pseudo-
strengthen the informal study and provide evidence that our pro-
identity between RSU and the RSU gateway:
new
tocol is secure. The analyses are as follows:
PIDnew new
RSU ¼ hðIDR jjfkRSU kN 2 Þ and stores the new PIDRSU and kRG for
future sessions. The RSU sends M 6 : fMSAA g to the vehicle.
7.1. Informal analysis
Step 7: Vehicle A computes C iA ¼ C encrypt
A  hðIDV A kkAS Þ, generates
encrypt
RiA ¼ PUFðC iA Þ, computes TokenA ¼  hðRiA Þ, verifies
TokenA This subsection presents the security feature analysis and pro-
V SAA . If the verification of V SAA fails, the communication will be ter- posed protocol competencies to withstand the type of attacks.
minated. Otherwise, the vehicle A updates its pseudo-identity and The details are as follows:

9
E Haodudin Nurkifli and T. Hwang
a. Achievement of Mutual Authentication
Mutual authentication between the vehicle and trusted author-
ity is achieved by possessing the shared key kVS and RiA ,
where the
trusted authority authenticates the identity of the vehicle IDV A and
response RiA , and the vehicle authenticates V SAA , while checking a
nonce to ensure message freshness. Additionally, mutual authenti-
cation between the RSU and RSU gateway can be achieved, where
the RSU authenticates the parameters kGR and fkRSU , and the RSU
gateway authenticates kGR and fkRSU . Later, mutual authentication
between the RSU gateway and the trusted authority can be
achieved by possessing the shared key kGA , where the trusted
authority authenticates V GS and the RSU gateway authenticates
V SG . Therefore, our protocol achieves mutual authentication.
b. The Achievement of Anonymity and untraceability
In our authentication protocol, the vehicles and RSU provide a
one-time pseudonym PIDV and PIDRSU , respectively, to interact with
the other parties; hence, the attacker cannot obtain the true iden-
tity even if the message is intercepted in a public channel. As a
result, our system is anonymous and untraceable. Furthermore,
every parameter is refreshed every session; hence, no message is
linked to another; thus, our protocol achieves unlinkability.
c. The Achievement of PFBS
In our protocol, the session key, challenge-response, and shared
key change every session, and also smart card stores non-plaintext
in its memory. Even if the attacker steals and reveals current data
from the memory of the smart card, the attacker cannot obtain past
secrets, including the session key, because the smart card stores

non-plaintext data fV; hdv , IDV , PIDV , kAS , K V Syn ; PIDV Syn } protected
by K Bio , where K Bio is generated from user’s biometric. In addition,
the attacker also cannot get the future secret data. Therefore, our
scheme achieves PFBS.
d. The Achievement of Session key security
The session key in our protocol differs for each session, and
there is no relationship between them. Even if the attacker
acquires one of the session keys, he or she will be unable to access
prior or future session keys. As a result, our authentication process
is secure using a session key.
e. The Achievement of Physical security
The smart card is equipped with PUF, based on the operation of
PUF where R ¼ PUF ðC Þ and using challenge-response to achieve
mutual authentication. Additionally, based on the uniqueness of
PUF, it cannot be cloned. Therefore, our scheme can withstand
cloning attacks. Furthermore, RSU is equipped with PUF and a
Fuzzy extractor. Rely on probability function at fuzzy extractor
generator; even if the adversary can fully control and obtains the
shared key, the adversary cannot obtain fixed-key simultaneously
in one operation. Therefore, our proposal, especially RSU, with-
stands a physical attack. In addition, to safeguard from side-
channel attacks, we can use the masking method (Kim et al.,
2019; Prouff & Rivain, 2013). Hence, the adversary cannot extract
the data from memory.
f. Resolve the desynchronization problem
When desynchronization occurs, the vehicle substitutes PIDV ,
kVS with pidv 1 , kv 1 , Then conduct the identical step with the authen-
10
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
tication phase. In addition, RSU changes PIDRSU ; kRG by
pidrSyn ; kRGSyn1 . Afterward, the RSU gateway replaces kGS with
1
kGSSyn1 , and the authentication phase is repeated. As a result, the
strategy can address the desynchronization problem.
g. Withstanding Impersonation Attack
The attacker cannot obtain the current secrets {response, ses-
sion key} and new secrets {response, session key} even if the
attacker stole the smart card and activated PUF; hence, the
attacker cannot impersonate the smart card as a legitimate user.
Therefore, our protocol authentication withstands an Imperson-
ation attack.
h. Withstanding Tracking Attack
In addition to achieving anonymity, the challenge C A in our
scheme is protected by a shared key kVS . Hence, the challenge is
private, making it impossible for the attacker to know the chal-
lenge owner based on the collected data in the wireless-based
public channel. Therefore, the scheme can withstand a tracking
attack.
i. Withstanding the DoS Attack
Even if the attacker spoofs communication traffic, gets all data
from the channel, and makes it seem like communication appears
to stop. Our protocol is designed primarily in the condition that
communication may suddenly stop. Then, one participant initiated
sending the synchronization {identity, challenge-response, key} to
ensure the protocol was still operating. Suppose one participant,
e.g., the server, does not receive the message at any specific time
from any participants. In that case, the protocol can operate by ini-
tiating the server sends {pseudo identity, key, challenge-response}
synchronization. Hence, Our protocol can still work under a DoS
attack. Therefore, our protocol withstands DoS attacks.
j. Withstanding replay attack
Even if an attacker intercepts a message M 1 fPIDV ; N 1 g and
resends it to the server, the server quickly detects that the message
has been modified or that it is still past data based on the new
pseudo-identity PIDnew
V and new nonce.
k. Withstanding a man-in-the-middle (MIM) attack.
Our protocol can withstand MIM attacks. For example, if the
attacker intercepts M 1 fPIDV ; N 1 g and modifies a message
M 1 fPIDxx ; N xx g, the server can quickly identify the message as inva-
lid based on the incorrect pseudo-identity PIDxx used by the
attacker.
l. Withstanding Cloning Attack
The smart card and RSU are equipped with PUF, which guaran-
tees that they are unclonable devices.
m. Withstanding Side-Channel Attack
Our protocol protects the secret stored in memory using a bio-
metric key. Even if the attacker gets or steals the smartcard and
attempts to collect data from memory, they cannot retrieve the
actual secret data due to the optimized usage of biometrics in
our protocol. Therefore, our protocol can withstand side-channel
attacks.
E Haodudin Nurkifli and T. Hwang
n. Withstanding Ephemeral Secret Leakage (ESL) attack
Our protocol closes the loophole to ESL attacks, where the
attacker cannot obtain every secret using biometrics and it is
impossible for the attacker to retrieve the biometric key. Addition-
ally, every secret is updated in every session, ensuring that past
and future secrets do not have a relationship.
7.2. Analysis formally using RoR model
Our RoR model has four participants: the vehicle (VC i ), the RSU
(Ri ), the RSU gateway (RGi ), and the trusted authority ðSÞ. The
model is as follows:
RGi , and pS are the oracle of v c; r; rg; s
1) Participants: pvVCc i , prRi , prg s
related with vehicle (VC i ), RSU (Ri ), RSU gateway (RGi ), the
trusted authority ðSÞ
2) Partnering: Partnering is only possible if, 1. Communication
between Vehicle pvVCc i and Trust Authority psS based on the
possession of the session id. 2. Updating each message sent
and received by Vehicle pvVCc i and Trust Authority psS in every
session.
3) Freshness: If the attacker cannot get the session key SK
between Vehicle pvVCc i and Trust Authority psS , the freshness
can be achieved.
4) Adversary: The capabilities of Adversary A in the ROR model
are identical to Dolev-Yao (DY) adversary model (Dolev &
Yao, 1983), and getting access to ROR model queries is as
follows:
a. Executeðpv c ; ps Þ: By executing this query, the Adversary can
intercept any messages sent across the public channel
between the vehicle and the trusted authority. This is called
an eavesdropping attack.
b. Sendðpv c ; mÞ: By performing this query, the attacker can
send and receive messages as one of the participants in the
communication session, such as one vehicle. This is referred
to as an active attack.
c. CorruptSmartCardðpv c Þ: The capability of the attacker is
where the attacker pilfers the smart card and gets the confi-
dential data stored in the memory of the smart card. This is
known as a stolen or lost smart-card attack.
d. CorruptRoadSideUnitðpRSU Þ: The adversary has complete con-
trol of the RSU and may reveal the credential stored in the
RSU’s memory. This is known as a stolen RSU attack.
e. Testðpv c ; ps Þ: The security is achieved if the session key
between vehicle pv c and trust authority ps is secure under
RoR model (Abdalla et al., 2005). The adversary guesses, by
repeatedly flipping the coin for a particular time, whether
the guessing c = 1, the session key is fresh. Otherwise, it is
a null or random key.
5) Semantic Security Of Session Key
In the RoR model, the adversary has the ability to differentiate
between the correct session key and the random key. Adversary
A will submit many TestðÞ queries to either pv c or ps , with the
results recorded in bit c. If c ¼ c0 , the opponent wins the game,
where c0 denotes a randomly chosen bit.
Adv P;A ðt Þ ¼ j2:Pr½SUCCESS  1j denotes Adversary A’s attempt to
AKE
break the semantic security of the protocol authentication in time
t, where SUCCESS represents the adversary winning the game.
6) Random Oracle
In this article, it is shown that all participants and adversary A
have access to the security of the collision-one-way hash function
11
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
hðÞ and the security of PUF ðÞ. They are both modeled under a ran-
dom oracle.
7) Security Proof
The security of the hash function and PUF is referred to as
semantic security, which we use to claim that our protocol is
secure. The security of the hash function and PUF is discussed in
Subsection 3.2.
By employing both of these definitions and acknowledging
Zipf0 s law (D. Wang et al., 2017), the proposed protocol0 s semantic
security can be determined by Theorem 1. Specifically, Theorem 1
determines the level of security provided by the protocol in terms
of semantic security.
Theorem 1. Suppose the adversary conducts an attack on protocol
P in polynomial time t under the RoR model. In our protocol, the
identity and biometric key are kept confidential. According to Zipf’s
law (D. Wang et al., 2017), l1 denotes the bit of the biometric key,
and l2 denotes the key fkRSU . The advantages of an attacker
breaking the semantic security for revealing the session key
between the vehicle and trust authority are as follows:
q2h q2 0 q q
Adv P;A ðtÞ  þ P þ 2maxfC 0 :qss ; ls ; ls g
AKE
jHashj jPUF j 21 22
The definitions of the notations are as follows: qh represents
a query of the hash function, qp represents a query of the PUF,
and qs represents a query of sending a message. jHashj repre-
sents the size of the range space of the hash function, and
jPUF j represents the size of the range space of the PUF. C 0 and
s0 are Zipf’s parameters (D. Wang et al., 2017) that determine
the distribution of the bits in the biometric key and the RSU
key, respectively.
Proof. We follow the same proof as offered (Gope et al., 2019),
(Roy et al., 2020), and (Roy et al., 2017), and in this work. Gj signi-
fies five-step games, j 2 ½0; 4 where j is between 0 and 4. In the
game Gj , The adversary achieves ‘‘SUCCESS” if the adversary
guesses the correct c. The game’s specifics are as follows.
Game G0 : G0 indicates the adversary starts the game to break
protocol security under the RoR model. The equation is:
Adv P;A ðtÞ ¼ j2:Pr½SUCCESS0   1j
AKE
ð1Þ
Game G1 : The adversary intercepts messages by operating
Executeðpv c ; ps Þ: M 1 : fPIDV ; N 1 g,

M 2 : fPIDRSU ; MRG ; hdRSU V RG g,
newenc newenc
M3 : fIDG ; MGS ; V GS g, M 4 : fMSG ; V SG ; kGS g, M 5 : fMGR ; kRG ; V GR g,
and M6 : fMSAA g. Afterwards, the adversary guesses the session
key. In our protocol, the session key is protected by RiA . If the
attacker wants to obtain the session key, they must disclose the
confidential data: RiA , IDV , and kAS . Unfortunately, only a legitimate
vehicle can compute RiA , and the trusted authority knows RiA . Only a
legitimate vehicle and the trusted authority can compute SK. As a
result, Adversary A’s chances of winning in G1 through eavesdrop-
ping are not increased. We have monitored the outcome
accordingly.
Pr½SUCCESS1  ¼ Pr½SUCCESS0  ð2Þ
Game G2 : The attacker simulates Sendðpv c ; mÞ; the adversary
accepts and edits the message. All messages
{MA1 ; M A2 ; M A3 ; M A4 ; MA5 ; M A6 } are protected by a key fkRSU and hash
function. According to 3.2.1-Definition 1, even if the adversary
operates the send queries, the adversary cannot locate a collision.
The equations based on the birthday paradox are as follows
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

q2h the smart card, and kRG , K RGSyn ; PIDRSUSyn ; C enc

i enc
jPr½SUCCESS2   Pr½SUCCESS1 j  ð3Þ RSU , and C RSU Syn from RSU.
2jHashj
The adversary cannot get the biometric key K Bio and the key fkRSU .
Game G3 : This game follows a similar rationale to G2 , but the According to (D. Wang et al., 2017), the probability of guessing
difference is that G3 simulates the Send and PUF requests, whereas both keys {K Bio as l1 and fkRSU as l2 ) are 21l1 and 21l2 , respectively.
G2 does not. We obtain the equation according to the definition of a Therefore, games G3 and G4 resist guessing attacks. Thus, the result
Secure PUF (as shown in 3.2.2-Definition 2): is:
q2P 0 qs qs
jPr½SUCCESS3   Pr½SUCCESS2 j  ð4Þ jPr½SUCCESS4   Pr½SUCCESS3 j  maxfC 0 :qss ; ; g ð5Þ
2jPUF j 2l1 2l2
Game G4 : In this final game, the adversary conducts The adversary must obtains c0 equal to c to win the game in
CorruptSmartCardðpv c Þ and CorruptRoadSideUnitðpRSU Þ, where the game G4 . As a result, we have

adversary A can extract V; hdv , IDV , PIDV , kAS , K V Syn ; and PIDV Syn from

Fig. 2. The result of the Scyther Tool.

12
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

1 rity properties, attack resistance, and computing complexity. The

Pr½SUCCESS4  ¼ ð6Þ
2 following table compares the two options:
Based on Eqs. (1), (2), and (6), we have Table 3 shows that P. Gope et al.’s (Gope et al., 2019), U. Chat-
  terjee et al.’s (Chatterjee et al., 2019), and M. N. Aman et al.’s pro-
1  1
Adv P;A ðt Þ ¼ Pr½SUCCESS0    tocol (Aman et al., 2021) achieves SP2, SP6, SP10 and SP12.
AKE
2 2 However, their protocols fail to achieve SP1, SP3-SP5, SP7-SP9,
  and SP11. J. Wang et al.’s protocol achieves SP3 and SP11, but it
 1 cannot achieve SP1, SP5, SP9, and SP12. Additionally, their protocol

¼ Pr½SUCCESS1   
2 does not provide SP2, SP4, SP6-SP8, and SP10. On the other hand, H.
Zhang et al.’s protocol only achieves SP3. Only our protocol can
¼ jPr½SUCCESS1   Pr½SUCCESS4 j ð7Þ achieve all security properties (SP1-SP12).
Our demonstration was performed on a virtual machine run-
We use the triangle inequality applied to formulas (3), (4), and
ning Linux Ubuntu 20.4.1, using the computing resources of an
(5).
RSU and an RSU gateway. The CPU of the RSU and the RSU gateway
jPr½SUCCESS1   Pr½SUCCESS4 j  jPr½SUCCESS1   Pr½SUCCESS3 j is an Intel Core i7 with a clock speed of 950 GHz, and the RAM is
10 GB. The Smart Card used in the demonstration has a CPU core
þ jPr½SUCCESS3   Pr½SUCCESS4 j
with a clock speed of 798 MHz and a RAM of 256 MB, which is con-
 jPr½SUCCESS1   Pr½SUCCESS2 j sistent with the specifications of an actual Smart Card (Technology,
þ jPr½SUCCESS2   Pr½SUCCESS3 j n.d.). The cryptographic operations used in our protocol include the
PUF protocol proposed by (Gope et al., 2019), (Chatterjee et al.,
þ jPr½SUCCESS3   Pr½SUCCESS4 j 2019), (Aman et al., 2021), and (Herder et al., 2014), FE.Gen and
q2h q2 FE.Rec (Dodis et al., 2004) and (Frikken et al., 2009), channel-
 þ P
jHashj jPUF j based key agreement, and the Advanced Encryption Standard
0 qs qs Cryptosystem (AES-CBC) from the Java Cryptography Architecture
þ 2maxfC 0 :qss ; ; g (JCA) library (Oracle, n.d.).
2l1 2l2
This demonstration focuses on the computational time result-
ð8Þ
ing from each algorithm used in every protocol, including our
The final result based on formulas (7) and (8): own. The purpose of this demonstration is to determine which pro-
tocol has the lowest computational burden. After obtaining the
q2h q2 0 q q
Adv P;A ðt Þ 
AKE
þ P þ 2maxfC0:qss ; ls ; ls g results, we will finally compare the computational burdens. The
jHashj jPUF j 2 22
1
results have been shown in Table 4 and Fig. 3.
The execution time for each cryptographic algorithm is as fol-
7.3. Analysis formally using Scyther tool lows: the execution time of T PUF in the vehicle/smart card is
0.304 s, and in the Roadside Unit/Gateway, it is 0.147 s. T FE:Gen in
Our protocol was also verified using the Scyther tool, a Python- the vehicle/smart card is 1.76 s, and in the Roadside Unit/Gateway,
based utility (Cremers, n.d.), (Zhu et al., 2019). The results of the it is 0.965 s. T FE:Rec in the vehicle/smart card is 3.28 s, T Bio in the
Scyther tool indicate that no attacks were found, as shown in vehicle/smart card is 4.95 s, T s in the vehicle/smart card is
Fig. 2. The code for our protocol is shown in the appendix. 0.759 s, and in the trusted authority, it is 0.248 s. T h in the vehi-
cle/smart card is 0.318 s, in the Roadside Unit/Gateway, it is
7.4. Comparison with related protocol 0.168 s, and in the Trusted Authority, it is 0.108 s. T ECC in Smart
Card/Vehicle is 7.48 s, in the Roadside Unit/Gateway, it is 5.76 s,
The subsection compares our proposed approach to previous and in the Trusted Authority, it is 4.06 s.
protocol authentication schemes presented by (Gope et al., 2019), The Table 4 shows that P. Gope et al.’s authentication protocol
(Chatterjee et al., 2019), and (Aman et al., 2021) in terms of secu- (Gope et al., 2019) gets the computational complexity of vehicle

Table 3
Comparison of Security Features.

Security Properties Authentication Protocol

(SP)
P. Gope et al. U. Chatterje at al. M. N. Aman et al. J. Wang et al. H. Zhang et al. Our scheme
SP1 No No No No No Yes
SP2 Yes Yes Yes N/A N/A Yes
SP3 No No No Yes Yes Yes
SP4 No No No N/A N/A Yes
SP5 No No No No No Yes
SP6 Yes Yes Yes N/A N/A Yes
SP7 No No No N/A N/A Yes
SP8 No No No N/A N/A Yes
SP9 No No No No N/A Yes
SP10 Yes Yes Yes N/A N/A Yes
SP11 No No No Yes N/A Yes
SP12 Yes Yes Yes No No Yes

Where SP: Security Features, SP1: Anonymity and untraceability of the vehicle, SP2: Protect against man-in-the-middle attack, SP3: Forward Secrecy, SP4: Session Key
security, SP5: Physical security of device/smart card, and SP6: resolve the loss of synchronization problem, SP7: withstanding impersonation attack, SP8: withstanding
tracking attack, SP9: withstand stolen device/smart card attack. SP10: withstand the DoS attack, SP11: withstanding reply attack, and SP12: withstanding cloning attack.
‘‘Yes” indicates that the protocol achieves the security features, ‘‘No” indicates that the protocol does not achieve the security features, and ‘‘N/A” indicates that the protocol is
not applicable for providing security features.

13
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

Table 4
Comparison of Computational Complexity.

Protocol Computation Total

(s)
Smart Card/Vehicle Roadside Unit/Gateway Trust Authority
P. Gope et al. T Bio þ 6T h þ 5T s þ 2T PUF 11.261 s 5T h 0.84 s 6T h þ 5T s 1. 888 s 13.989 s
U. Chatterje at al. 10T h þ 4T s þ T PUF +3T ECC 26.098 s 4T h þ 4T ECC 23,712 s 8T h þ 5T s þ 4T ECC 18.344 s 68.154 s
M. N. Aman et al. 2T h þ T s þ T PUF 1.426 s T PUF þ T S þ T h 0.563 s 4T h þ 3T s 1.176 s 3.165 s
J. Wang et al. 6T ECC þ 6T h 46.788 s 3T ECC þ T h 17.448 s 8T ECC þ 5T h 46.62 s 110.856 s
H. Zhang et al. 4T ECC þ T h 30.238 s 4T ECC þ T h 23.208 s 4T ECC þ 2T h 16.456 s 69.902 s
Our scheme T h þ T FE:Rec þ T PUF 3.426 s T PUF þ T FE:Gen þ T h 2,075 s 4T h 0.432 s 5.933 s

Where T FE:Gen : Time of Fuzzy Extractor Generation, T FE:Rec : Time of Fuzzy Extractor Reconstructions, T Bio : Time of Biometric operations, T h : Time of one-way hash function,
T PUF : Time of PUF process, T s : Time of symmetric encryption/decryption. T ECC : Time of the ECC operation (point multiplication/point addition).

only our proposed scheme fulfills security properties SP1-SP12

Fig. 3. Diagram of execution time comparison.
T Bio þ 6T h þ 5T s þ 2T PUF , Roadside Unit/Gateway 5T h , and the
trusted authority 6T h þ 5T s with a total of the execution time of
13.989 s. U. Chatterjee et al.’s scheme (Chatterjee et al., 2019)
has a computational complexity of vehicle/smart card
10T h þ 4T s þ T PUF +3TECC , Roadside Unit/Gateway 4T h þ 4T ECC and
the trusted authority 8T h þ 5T s þ 4T ECC with a total execution time
of 68.154 s. M. N. Aman et al.’s scheme (Aman et al., 2021) gets the
computational complexity of the vehicle/smart
2T h þ T s þ T PUF , Roadside Unit/Gateway T PUF þ T S þ T h and trusted
authority 4T h þ 3T s with a total execution time of 3.165 s. J. Wang
et al.’s authentication protocol has a total computational time of
110.856 s. H. Zhang et al. achieve a total computational time of
69.902 s. Our proposal has a computational complexity of vehicle
T h þ T FE:Rec þ T PUF , Roadside Unit/Gateway T PUF þ T FE:Gen þ T h and
trusted authority 4T h with a total execution time of 5.933 s. Based
on the diagram in Fig. 3, it is shown that our protocol has a lower
computational complexity and execution time than P. Gope et al.’s,
U. Chatterjee et al.’s,. J. Wang et al.’s, and H. Zhang et al.’s authen-
tication protocol, and our proposal has computational complexity
higher than M. N. Aman et al.’s scheme. However, only our protocol
fulfills the achievement of all security properties SP1-SP12 in
Table 3.
8. Conclusion
In this article, we initially introduce a robust adversary model
by modifying the DY structure. Then, we review and evaluate
Aman et al.’s protocol and identify the weaknesses of their proto-
col. We propose a new protocol to resolve the problems in their
protocol and provide a solution for generic IoV security issues.
We compare our protocol with Aman’s and several related proto-
cols regarding security features, the ability to withstand attacks,
and computational complexity. The comparison table shows that
and has lower computational complexity than Gope et al.’s, U.
Chatterjee et al.’s, J. Wang et al.’s, and H. Zhang et al.’s schemes.
Additionally, our article is supported by evidence from informal
and formal analyses. The results of the RoR model analysis show
that our protocol fulfills security features and protects against var-
ious attacks. Later, the Scyther Tool also confirms that our protocol
protects against attacks. Therefore, our proposed protocol is secure
and can withstand well-known attacks. The implementation of PUF
in the real world is rarely carried out, even though security features
related to cloning need to be addressed. Similarly, devices such as
smartphones and smart cards already extensively use biometrics
for security. From this, future research can explore how to apply
biometrics and PUFs in the real world. Another important aspect
is demonstrating how real-world machine-learning and side-
channel attacks can exploit PUF vulnerabilities, as well as the
necessity for countermeasures against them.
Declaration of Competing Interest
The authors declare that they have no known competing finan-
cial interests or personal relationships that could have appeared
to influence the work reported in this paper.
card
Appendix
The coding of our proposed protocol
/*
* Our proposal
*/
// The protocol description
usertype String;
hashfunction H;
const XOR:Function;
const CON:Function;
const PUF:Function;
macro TokenA = CON(CON(CON(CON(IDVA, length), SKVA),
Tmexpire), N4);
macro VSAA = H(CON(CON(CON(CON(IDVA,TokenA),RA),N1),
N4));
macro CAenc = XOR(CA,H(CON(IDVA,kVS)));
macro TokenAenc = XOR(TokenA,H(RA));
macro MSAA=(CAenc,TokenAenc,VSAA);
macro RA = PUF(CA);
protocol Internet-of-Vehicle(Vehicle,TrustedAuthority){
role Vehicle{
secret RA, CA, IDVA, kVS, TokenA, SKVA, length, Tmexpire;
fresh N1, N4, PIDVA;

14
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

var PIDVA; claim(RSUGateway,Niagree);

send_1(Vehicle,TrustedAuthority, PIDVA,N1); claim(RSUGateway,Nisynch);
recv_2(TrustedAuthority, Vehicle,MSAA); claim(RSUGateway,Alive);
claim(Vehicle,Secret,TokenA); claim(RSUGateway,Weakagree);
claim(Vehicle,Secret,SKVA); }
claim(Vehicle,Secret,CA); role TrustedAuthority{
claim(Vehicle,Secret,RA); secret RA, CA, IDVA, kVS, TokenA, SKVA, length, Tmexpire,
claim(Vehicle,Niagree); IDG, IDS, kGS,kGSnew;
claim(Vehicle,Nisynch); fresh N1, N4, N3, PIDVA;
claim(Vehicle,Alive); var PIDVA;
claim(Vehicle,Weakagree); recv_1(RSUGateway,TrustedAuthority, IDG, MSG, VGS);
} send_2(TrustedAuthority, RSUGateway,MSG,VSG,kGSne
role TrustedAuthority{ wenc);
secret RA, CA, IDVA, kVS, TokenA, SKVA, length, Tmexpire; claim(TrustedAuthority,Secret,kGS);
fresh N1, N4, PIDVA; claim(TrustedAuthority,Secret,kGSnew);
var PIDVA; claim(TrustedAuthority,Niagree);
recv_1(Vehicle,TrustedAuthority, PIDVA,N1); claim(TrustedAuthority,Nisynch);
send_2(TrustedAuthority, Vehicle,MSAA); claim(TrustedAuthority,Alive);
claim(TrustedAuthority,Secret,TokenA); claim(TrustedAuthority,Weakagree);
claim(TrustedAuthority,Secret,SKVA); }
claim(TrustedAuthority,Secret,CA); }
claim(TrustedAuthority,Secret,RA); /*
claim(TrustedAuthority,Niagree); * Our proposal
claim(TrustedAuthority,Nisynch); */
claim(TrustedAuthority,Alive); // The protocol description
claim(TrustedAuthority,Weakagree); usertype String;
} hashfunction H;
} const XOR:Function;
/* const CON:Function;
* Our proposal const PUF:Function;
*/ const FGen:Function;
// The protocol description macro M1 = CON(PIDVA,N1);
usertype String; macro fkrsu = FGen(RRSU);
hashfunction H; macro hdrsu = FGen(RRSU);
const XOR:Function; macro hdrsuenc = XOR(hdrsu,H(kRG));
const CON:Function; macro MRG = XOR(CON(CON(IDR,M1),N2),H(fkrsu));
const PUF:Function; macro VRG = H(CON(CON(CON(CON(CON(IDR,MRG),kRG),N2
macro M1 = CON(PIDVA,N1); ),PIDRSU),hdrsuenc));
macro MGS = XOR(CON(CON(IDG,M1),N3),H(kGS)); macro MGS = XOR(CON(CON(IDG,M1),N3),H(kGS));
macro VGS = H(CON(CON(CON(CON(IDG,IDS),MGS),kGS),N3) macro VGS = H(CON(CON(CON(CON(IDG,IDS),MGS),kGS),N3)
); );
macro TokenA = CON(CON(CON(CON(IDVA, length), SKVA), macro TokenA = CON(CON(CON(CON(IDVA, length), SKVA),
Tmexpire), N4); Tmexpire), N4);
macro VSAA = H(CON(CON(CON(CON(IDVA,TokenA),RA),N1), macro VSAA = H(CON(CON(CON(CON(IDVA,TokenA),RA),N1),
N4)); N4));
macro CAenc = XOR(CA,H(CON(IDVA,kVS))); macro CAenc = XOR(CA,H(CON(IDVA,kVS)));
macro TokenAenc = XOR(TokenA,H(RA)); macro TokenAenc = XOR(TokenA,H(RA));
macro MSAA=(CAenc,TokenAenc,VSAA); macro MSAA=(CAenc,TokenAenc,VSAA);
macro MSG = XOR(CON(CON(TokenA,MSAA),N4),H(kGS)); //
macro kGSnewenc = XOR(kGSnew,H(CON(kGS,N3))); macro MGR = XOR(CON(CON(TokenA,MSAA),N3),H(fkrsu));
macro VSG = H(CON(CON(CON(CON(CON(IDG,IDS),MSG),N3), macro kRGnewenc = XOR(kRGnew,H(CON(fkrsu,N2)));
N4),kGSnew)); macro VGR = H(CON(CON(CON(CON(CON(IDG,MGR),kRGne
macro RA = PUF(CA); wenc),IDR),N2),kRGnew));
protocol Internet-of-Vehicle(RSUGateway,TrustedAuthority){ macro MSG = XOR(CON(CON(TokenA,MSAA),N4),H(kGS));
role RSUGateway{ macro kGSnewenc = XOR(kGSnew,H(CON(kGS,N3)));
secret RA, CA, IDVA, kVS, TokenA, SKVA, length, Tmexpire, macro VSG = H(CON(CON(CON(CON(CON(IDG,IDS),MSG),N3),
IDG, IDS, kGS,kGSnew; N4),kGSnew));
fresh N1, N4, N3, PIDVA; macro RA = PUF(CA);
var PIDVA; protocol Internet-of-Vehicle(RSU,RSUGateway){
send_1(RSUGateway,TrustedAuthority, IDG, MSG, VGS); role RSU{
recv_2(TrustedAuthority, RSUGateway,MSG,VSG,kGSne secret fkrsu, hdrsu, RRSU, hdrsuenc, RA, CA, IDVA, kVS,
wenc); TokenA, SKVA, length, Tmexpire, IDG, IDS, kGS,kGSnew,
claim(RSUGateway,Secret,kGS); IDR,kRG,kRGnew;
claim(RSUGateway,Secret,kGSnew);
(continued on next page)

15
E Haodudin Nurkifli and T. Hwang Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721

fresh N1, N4, N3, N2, PIDVA, PIDRSU,kRGnewenc; Choi, W., Kim, S., Kim, Y., Park, Y., & Ahn, K. 2010. PUF-based Encryption Processor
for the RFID Systems. 2010 10th IEEE International Conference on Computer
var PIDVA,PIDRSU; and Information Technology, Cit, 2323–2328. https://doi.org/10.1109/
send_1(RSU,RSUGateway, PIDRSU,MRG,VGR); CIT.2010.400.
recv_2(RSUGateway,RSU, MGR,kRGnewenc,VGR); Chuang, K., Member, S., Bury, E., Degraeve, R., Kaczer, B., Linten, D., Member, S.,
Verbauwhede, I., 2019. A physically unclonable function using soft oxide
claim(RSU,Secret,kRG); breakdown featuring 0 % native. IEEE Journal of Solid-State Circuits 54 (10),
claim(RSU,Secret,fkrsu); 2765–2776. https://doi.org/10.1109/JSSC.2019.2920714.
claim(RSU,Secret,kRGnew); Committee, I.T.S., 2013. IEEE Guide for wireless access in vehicular environments
(WAVE). Architecture IEEE Vehicular Technology Society.
claim(RSU,Niagree); Cremers, C. n.d. The Scyther Tool : Verification , Falsification , and Analysis of
claim(RSU,Nisynch); Security Protocols. In Proc. Int. Conf. Comput. Aided VeriFcation, 1–4.
claim(RSU,Alive); De Fuentes, J.M., González-tablas, A.I., 2010. Overview of security issues in vehicular
Ad-hoc networks. Handbook of Research on Mobility and Computing.
claim(RSU,Weakagree); Dodis, Y., Reyzin, L., Smith, A., 2004. Fuzzy extractors : How to generate strong keys
} from biometrics and other noisy data. In: Advances in Cryptology—
role RSUGateway{ EUROCRYPT’2004 (Lecture Notes in Computer Science). Springer, Heidelberg,
German, pp. 523–540.
secret fkrsu, hdrsu, RRSU, hdrsuenc, RA, CA, IDVA, kVS,
Dolev, D., Yao, A., 1983. On the security of public key protocols. IEEE Trans. Inf.
TokenA, SKVA, length, Tmexpire,IDG, IDS, kGS,kGSnew,IDR, Theory, M, 198–208.
kRG,kRGnew; E. Suh, G., & Devadas, S. 2007. Physical unclonable functions for device
fresh N1, N4, N3, N2,PIDVA, PIDRSU,kRGnewenc; authentication and secret key generation. In: 2007 44th ACM/IEEE Design
Automation Conference, San Diego, 9–14.
var PIDVA,PIDRSU; Elhalawany, B. M., El-banna, A. A. A., & Wu, K. 2019. Physical-layer security and
recv_1(RSU,RSUGateway, PIDRSU,MRG,VGR); privacy for vehicle-to-everything. IEEE Communication Magazine, October, 84–
send_2(RSUGateway, RSU, MGR,kRGnewenc,VGR); 90.
Frikken, K. B., Blanton, M., & Atallah, M. J. 2009. Robust authentication using
claim(RSUGateway,Secret,kRG); physically unclonable functions. Lecture Notes in Computer Science (Including
claim(RSUGateway,Secret,fkrsu); Subseries Lecture Notes in Artificial Intelligence and Lecture Notes in
claim(RSUGateway,Secret,kRGnew); Bioinformatics), 5735 LNCS, 262–277. https://doi.org/10.1007/978-3-642-
04474-8_22.
claim(RSUGateway,Niagree); Gope, P., Das, A.K., Kumar, N., Cheng, Y., 2019. Lightweight and physically secure
claim(RSUGateway,Nisynch); anonymous mutual authentication protocol for real-time data access in
claim(RSUGateway,Alive); industrial wireless sensor networks. IEEE Transactions on Industrial
Informatics 15 (9), 4957–4968.
claim(RSUGateway,Weakagree); Gope, P., Sikdar, B., 2019. Lightweight and privacy-preserving two-factor
} authentication scheme for IoT devices. IEEE Internet of Things Journal 6 (1),
} 580–589. https://doi.org/10.1109/JIOT.2018.2846299.
Guo, Y., Dee, T., Tyagi, A., 2018. Barrel shifter physical unclonable function based
encryption. Cryptoraphy 2 (3), 1–20. https://doi.org/10.3390/
cryptography2030022.
Herder, C., Yu, M., Koushanfar, F., & Devadas, S. 2014. Physical Unclonable Functions
and Applications : A Tutorial. Proceedings of the IEEE, 102(8), 1126–1141.
References https://doi.org/10.1109/JPROC.2014.2320516.
In, Z. H. A. N. Q., Ieee, M., In, X. I. L., & Ieee, F. 2020. The Security of Autonomous
Abdalla, M., Fouque, P., Pointcheval, D., 2005. Password-based authenticated key Driving : Threats , Defenses , and Future Directions. Proceedings of the IEEE, 108
exchange in the three-party setting. IACR International Conference on Public- (2).
Key Cryptography 3386, 65–84. Javaid, U., Member, S., Aman, M.N., 2020. A scalable protocol for driving trust
Adigun, A., Bensaber, B.A., Biskri, I., 2013. Protocol of change pseudonyms for management in internet of vehicles with blockchain. IEEE Internet of Things
VANETs. IEEE International Workshop on Performance and Management of Journal 7 (12), 11815–11829.
Wireless and Mobile Networks, 162–167. Javaid, U. 2019. DrivMan : Dri ving Trust Man agement and Data Sharing in VANETs
Aman, M.N., Sikdar, B., Member, S., 2018. ATT-Auth : A hybrid protocol for industrial with Blockchain and Smart Contracts. IEEE 89th Vehicular Technology
IoT attestation with authentication. IEEE Internet of Things Journal 5 (6), 5119– Conference (VTC2019-Spring).
5131. Jeon, D., Baek, J. H., Kim, D. K., & Choi, B. 2015. Toward Zero Bit-Error-Rate Physical
Aman, M.N., Basheer, M.H., Member, S., 2019a. Data provenance for IoT with light Unclonable Function : Mismatch-Based vs . Physical-Based Approaches in
weight authentication and privacy preservation. IEEE Internet of Things Journal Standard CMOS Technology. 2015 Euromicro Conference on Digital System
6 (6), 10441–10457. Design, 407–414. https://doi.org/10.1109/DSD.2015.57.
Aman, M.N., Basheer, M.H., Sikdar, B., 2019b. Two-factor authentication for IoT with Jia, D., Lu, K., Member, S., Wang, J., Zhang, X., 2016. A survey on platoon-based
location information. IEEE Internet of Things Journal 6 (2), 3335–3351. vehicular cyber-physical systems. IEEE Communication Surveys and Tutorials
Aman, M.N., Taneja, S., Member, S., Sikdar, B., Member, S., Chua, K.C., Alioto, M., 18 (1), 263–284.
2019c. Token-based security for the internet of things with dynamic energy- Jr, B. L. A. 2002. Security requirements for cryptographic modules. National Institute
quality tradeoff. IEEE Internet of Things Journal 6 (2), 2843–2859. of Standards and Technology.
Aman, M.N., Basheer, M.H., Member, S., Dash, S., 2020. HAtt : Hybrid remote Kaci, A. 2020. PoolCoin: Toward a distributed trust model for miners ’ reputation
attestation for the internet of things with high availability. IEEE Internet of management in blockchain. IEEE 17th Annual Consumer Communications &
Things Journal 7 (8), 7220–7233. Networking Conference (CCNC).
Aman, M.N., Javaid, U., Member, S., 2021. A privacy-preserving and scalable Kim, H.B., Hong, S., Kim, H.S., 2019. Lightweight conversion from arithmetic to
authentication protocol for the internet of vehicles. IEEE Internet of Things Boolean masking for embedded IoT processor. Applied Sciences (Switzerland) 9
Journal 8 (2), 1123–1139. (7). https://doi.org/10.3390/app9071438.
Azees, M., Vijayakumar, P., Deborah, L.J., 2016. Comprehensive survey on security Kleber, S., Unterstein, F., Matousek, M., Kargl, F., Slomka, F., Hiller, M., 2015. Secure
services in vehicular ad-hoc networks. The Institution of Engineering and execution architecture based on puf-driven instruction level code encryption.
Technology 379–388. https://doi.org/10.1049/iet-its.2015.0072. IACR Cryptology EPrint Archive 2015, 651.
Babaei, A., Schiele, G., 2019. Physical unclonable functions in the internet of things : Lei, A., Cruickshank, H., Cao, Y., Asuquo, P., Ogah, C.P.A., Sun, Z., Member, S., 2017.
State of the art and open challenges. Sensors (Basel) 19 (14), 3208. https://doi. Blockchain-based dynamic key management for heterogeneous intelligent
org/10.3390/s19143208. transportation systems. IEEE Internet of Things Journal 4 (6), 1832–1843.
Bian, W., Gope, P., Cheng, Y., Li, Q., 2020. Bio-AKA : An efficient fingerprint based Long, J., Liang, W.E.I., Li, K., Member, S., 2019. PUF-based anonymous authentication
two factor user authentication and key agreement scheme Bio-AKA : An scheme for hardware devices and IPs in edge computing environment. IEEE
efficient fingerprint based two factor user authentication and key agreement Access 7, 124785–124796. https://doi.org/10.1109/ACCESS.2019.2925106.
scheme. Future Generation Computer Systems 109 (March), 45–55. https://doi. Lu, X., Member, S., Hong, L., Member, S., 2018. CMOS optical PUFs using noise-
org/10.1016/j.future.2020.03.034. immune process-sensitive photonic crystals incorporating passive variations
Bohm, C., Hofer, M., 2012. Physical unclonable functions in theory and practice. for robustness. IEEE Journal of Solid-State Circuits 53 (9), 2709–2721. https://
Springer, NY, USA. doi.org/10.1109/JSSC.2018.2850941.
Chatterjee, U., Govindan, V., Sadhukhan, R., Mukhopadhyay, D., 2019. Building PUF Mcgrath, T., Bagci, I.E., Wang, Z.M., Roedig, U., Young, R.J., Bagci, I.E., Wang, Z.M.,
based authentication and key exchange protocol for IoT without explicit CRPs in Roedig, U., 2019. A PUF taxonomy A PUF taxonomy. Applied Physics Reviews 6,.
verifier database. IEEE Transactions on Dependable and Secure Computing 16 https://doi.org/10.1063/1.5079407 011303.
(3), 424–437.

16
E Haodudin Nurkifli and T. Hwang
Nidhal, M., Ben-othman, J., Hamdi, M., 2014. Survey on VANET security challenges
and possible cryptographic solutions. Vehicular Communications 1 (2), 53–66.
https://doi.org/10.1016/j.vehcom.2014.05.001.
Oracle. n.d. Java Cryptography Architecture (JCA). Retrieved November 11, 2022,
from https://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/
CryptoSpec.html.
Prouff, E., & Rivain, M. 2013. Masking against side-channel attacks: A formal
security proof. Lecture Notes in Computer Science (Including Subseries Lecture
Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 7881 LNCS,
142–159. https://doi.org/10.1007/978-3-642-38348-9_9.
Report, I. 2015. Global Risks 2015 10th Edition.
Roy, S., Chatterjee, S., Das, A.K., Chattopadhyay, S., 2017. On the design of provably
secure lightweight remote user authentication scheme for mobile cloud
computing services. IEEE Access, October. https://doi.org/10.1109/
ACCESS.2017.2764913.
Roy, S., Das, A.K., Chatterjee, S., Kumar, N., Member, S., Chattopadhyay, S., Rodrigues,
J.J.P.C., Member, S., 2020. Provably secure fine-grained data access control over
multiple cloud servers in mobile cloud computing based healthcare
applications. IEEE Transactions on Industrial Informatics 15 (1), 457–468.
Salem, A.H., Abdel-hamid, A., El-nasr, M.A., 2014. The case for dynamic key
dsitribution for PKI-based VANETS. International Journal of Computer Networks
& Communications 6 (1), 61–78.
Seudié, H., & Gmbh, R. B. 2009. E-Safety Vehicle Intrusion Protected Applications
EVITA project objectives. Escar Embedded Security in Cars Conference.
Soja, R. n.d. Automotive Security : From Standards to Implementation. Automotive
Microcontrollers and Processors, NXP.
Sulaiman, A., Raja, S.V.K., Han, S., 2013. Improving scalability in vehicular
communication using one-way hash chain method. Ad Hoc Networks 11 (8),
2526–2540. https://doi.org/10.1016/j.adhoc.2013.05.017.
Technology, S. A. n.d. Smart Card Standards and Specifications. Retrieved June 10,
2021, from https://www.securetechalliance.org/smart-cards-intro-standards/
#::text=ISO%2FIEC 14443 compliant cards,the FIPS 201 PIV card.
Tuyls, P., Batina, L., 2006. RFID-Tags for Anti-counterfeiting. In: Topics in Cryptology
CT-RSA (LNCS 3860), Heidelberg. Springer, German, pp. 115–131.
Twente, U. 2015. Preparing Secure Vehicle-to-X Communication Systems. 1–3.
17
Journal of King Saud University – Computer and Information Sciences 35 (2023) 101721
Wang, D., Member, S., Cheng, H., Wang, P., Member, S., 2017. Zipf ’ s Law in
Passwords. IEEE Transactions on Information Forensics and Security 12 (11),
2776–2791.
Wang, J., Wu, L., Wang, H., Choo, K.K.R., Wang, L., He, D., 2022. A secure and efficient
multiserver authentication and key agreement protocol for internet of vehicles.
IEEE Internet of Things Journal 9 (23), 24398–24416. https://doi.org/10.1109/
JIOT.2022.3188731.
Wang, W., Yona, Y., Diggavi, S.N., Gupta, P., 2018. Design and analysis of stability-
guaranteed PUFs. IEEE Transactions on Information Forensics and Security 13
(4), 978–992.
Whyte, W., Weimerskirch, A., Kumar, V., Hehn, T., 2021. A security credential
management system for V2V communications. IEEE Vehicular Networking
Conference A, 1–8.
Xue, K., Luo, X., Ma, Y., Li, J., Liu, J., Wei, D.S.L., 2022. A distributed authentication
scheme based on smart contract for roaming service in mobile vehicular
networks. IEEE Transactions on Vehicular Technology 71 (5), 5284–5297.
https://doi.org/10.1109/TVT.2022.3148303.
Yahiatene, Y. 2018. Towards a Blockchain and Software-Defined Vehicular
Networks approaches to secure Vehicular Social Network. IEEE Conference on
Standards for Communications and Networking (CSCN).
Yang, Z., Yang, K., Lei, L., Member, S., Zheng, K., Member, S., Leung, V.C.M., 2019.
Blockchain-based decentralized trust management in vehicular networks. IEEE
Internet of Things Journal 6 (2), 1495–1505.
Yazid, M., Fahmi, F., Sutanto, E., Setiawan, R., Aripriharta, Aziz, M., 2023. Simple
authentication method for vehicle monitoring IoT device with verifiable data
integrity. IEEE Internet of Things Journal 10 (8), 7027–7037. https://doi.org/
10.1109/JIOT.2022.3228926.
Zhang, X., Chen, X., 2019. Data security sharing and storage based on a consortium
blockchain in a vehicular ad-hoc network. IEEE Access 7, 58241–58254. https://
doi.org/10.1109/ACCESS.2018.2890736.
Zhang, H., Lai, Y., Chen, Y., 2023. Authentication methods for internet of vehicles
based on trusted connection architecture. Simulation Modelling Practice and
Theory 122, (June 2022). https://doi.org/10.1016/j.simpat.2022.102681 102681.
Zhu, F., Li, P., & Xu, H. 2019. A Lightweight RFID Mutual Authentication Protocol
with PUF. Sensors (Basel, Switzerland), Id, 1–22.