COVID-19 Vehicle Based on an Efficient Mutual Authentication Scheme for 5G-Enabled Vehicular Fog Computing

The COVID-19 pandemic is currently having disastrous effects on every part of human life everywhere in the world. There have been terrible losses for the entire human race in all nations and areas. It is crucial to take good precautions and prevent COVID-19 because of its high infectiousness and fatality rate. One of the key spreading routes has been identified to be transportation systems. Therefore, improving infection tracking and healthcare monitoring for high-mobility transportation systems is impractical for pandemic control. In order to enhance driving enjoyment and road safety, 5G-enabled vehicular fog computing may gather and interpret pertinent vehicle data, which open the door to non-contact autonomous healthcare monitoring. Due to the urgent need to contain the automotive pandemic, this paper proposes a COVID-19 vehicle based on an efficient mutual authentication scheme for 5G-enabled vehicular fog computing. The proposed scheme consists of two different aspects of the special flag, SF = 0 and SF = 1, denoting normal and COVID-19 vehicles, respectively. The proposed scheme satisfies privacy and security requirements as well as achieves COVID-19 and healthcare solutions. Finally, the performance evaluation section shows that the proposed scheme is more efficient in terms of communication and computation costs as compared to most recent related works.


Introduction
A major worldwide health crisis unlike any other in history is currently affecting everyone on Earth, causing chaos in people's lives and spreading agony. The World Health Organization (WHO) has described the coronavirus disease COVID-19 as constituting fatal and highly contagious pandemic [1][2][3][4]. It has been responsible for thousands of deaths worldwide and is still wreaking havoc on communities [5][6][7]. The majority of countries have to date deployed tight detection and surveillance methods for public spaces such as airports and train stations, as well as means of public transit including airplanes, subways, and trains [8][9][10].
The special benefits of the fifth-generation 5G-enabled vehicular network could be taken into consideration with the pressing needs for pandemic control [11][12][13][14]. That is, the two key components of COVID-19-control-advanced healthcare monitoring and infection tracking-could be carried out by a 5G-enabled vehicular network without requiring direct human contact. As a result, the working staff is spared the perilous task of conducting surveillance at each inspection station. Instead, if required, each instance of fog computing might be given the role of the automatic checkpoint. In densely populated metropolitan cities and regions, the 5G-enabled vehicular network is regarded as a crucial element of the future vehicular ad hoc network (VANET) in order to deliver innovative vehicular data processing and traffic management analyses [15]. A major vehicular network infrastructure is composed of a 5G-base station, fog server, trusted authority (TA), and terminal vehicle equipped with the onboard unit (OBU) [16,17]. Vehicular networks provide for two different types of data transfer: vehicle-to-vehicle and vehicle-to-fog server through a 5G base station.
In order to address security challenges in the vehicular network, numerous studies using various safety procedures and cryptographic algorithms have recently been conducted. However, the criteria required for the 5G-enabled vehicular network's actual implementation have not yet been fully taken into account. Vehicular networks' prospective applications and useful uses should be investigated in light of the COVID-19 pandemic's urgent global predicament. Measurements for vehicular networks and their related extensions should be developed now that the transportation system has emerged as one of the most hazardous scenarios for viral surveillance and infection tracking.
Due to the urgent need to contain the automotive pandemic, this paper will propose a COVID-19 vehicle-based efficient mutual authentication scheme for 5G-enabled vehicular fog computing. The proposed scheme consists of two different aspects according to a special flag (SF) value that involves a mutual authentication process. Based on the SF value, we consider the type of vehicle with SF = 0 and SF = 1 as the normal and COVID-19 vehicles, respectively. The main contributions of this paper are listed as follows: • COVID-19 vehicle-based efficient mutual authentication scheme is proposed for 5Genabled vehicular fog computing. • A scheme does not only satisfy privacy and security requirements but also achieves COVID-19 and healthcare solutions. • Performance evaluation section shows that the proposed scheme is more efficient in terms of communication and computation costs as compared to most recent related works.
The remainder of this paper is organized as follows: In Section 2, we review some mutual authentication schemes for vehicular networks. Section 3 describes the system model and mathematical methods of our proposal. Section 4 proposes a COVID-19 vehiclebased scheme for 5G-enabled vehicular fog computing. Section 5 evaluates security analysis and the comparison of proposal. Section 6 analyses the communication and computation overhead. Lastly, we provide the conclusion of this paper in Section 7.

Related Work
In this section, we review some mutual authentication schemes for vehicular networks as follows. Wang et al. [18] designed a mutual authentication system based on local identity by assigning unique long-term certification from TA to RSU and a vehicle in the enrolment process. Ming et al. [19] designed certificateless cryptography to provide communication security in a vehicular network. This scheme can simultaneously verify a large number of received messages by RSU. Al-Shareeda et al. [20] designed a privacy-preserving communication scheme by injecting fake messages to achieve unobservability requirements. This scheme has massive overhead in terms of communication and computation costs. For V2V communication, Ali and Li [21] proposed a signature based on an identity scheme using a secure hash function in high-density areas with high traffic. Zhang et al. [22] constructed a fuzzy logic mathematical approach to share security data among vehicles in a group based on a 5G-enabled model. Li et al. [23] presented a provable authentication scheme to provide both the security and privacy required for vehicular networks. Cui et al. [24] designed a content-sharing scheme for reliable communications in 5G-enabled vehicular networks. This scheme picked sophisticated proxy vehicles and requested them for content services. Alshudukhi et al. [25] constructed combined schemes between RSUbased and OBU-based schemes by exchanging temporary keys to sign messages and verify signatures during a short period. Al-Shareeda et al. [26] proposed a data-sharing scheme to secure 5G-enabled vehicular networks without using roadside units (RSUs). This scheme preloaded a large number of pseudonym IDs and relevant private keys to the registered vehicle during the key generation phase. However, this scheme has a massive overhead in verifying the messages exchanged among vehicles in terms of single verification and batch verification.
However, these mutual authentication schemes have massive performance overheads in terms of communication and computation costs. Additionally, none of these schemes address the COVID-19 virus and healthcare solutions for vehicular networks to exchange messages with trusted parts. In order to cope with these issues, this paper will propose efficient mutual authentication to sign messages and verify the signature. Additionally, our proposal consists of two different aspects according to the special flag (SF) value that involves a mutual authentication process. Based on the SF value, we consider the type of vehicle to be a normal vehicle when SF = 0 and a COVID-19 vehicle when SF = 1.

Background
This section introduces the system model and mathematical method used in the proposed scheme as follows:

System Model
As shown in Figure 1, the system model of the proposed scheme consists of four main entities, namely the trusted authority (TA), fog server, 5G-base station (5G-BS), and onboard unit (OBU) that are equipped in each vehicle. The distribution of these entities is as follows. • Trusted Authority (TA): It is the sole authority that is a trustworthy third party and can decipher an OBU's identity from encryption. It is in charge of producing system parameters and has significant computing and storage capabilities. • Fog Server: The fog server is regarded as a completely reliable entity that will assist TA in disclosing the names of the signers in our endeavour. In order to generate the pseudonym IDs of the vehicles over mutual authentication via 5G-BS, the fog server has its master key preloaded by TA. Our work relies on the public key of the fog server for the verification process. • 5G-Base Station (5G-BS): The 5G-BS is a reliable infrastructure that has been placed beside roads. Without any storage or computing, it functions as a bridge between entities. • Onboard Unit (OBU): OBUs are installed in every car; they are secure and cannot be removed or interfered with. OBUs are wireless logical units that use the DRSC and 5G protocols to communicate with other OBUs and fog servers via 5G-BS, respectively. In this paper, there are two types of vehicles called normal vehicles and COVID-19 vehicles. In this paper, the terms of CVPS and NVPS will be used to refer to COVID-19 vehicles and normal vehicles, receptively.

Mathematical Methods Used
In this section, we describe the mathematical methods used in the proposed scheme as follows.

Elliptic Curve Cryptography (ECC)
Elliptic curve cryptography (ECC) was first conceived in 1958 by Miller [27]. Designing security procedures and digital signatures now frequently uses this kind of cryptographic technology. For more details about ECC, we recommend reading [20,28,29].

Hash Cryptographic Function
One of a number of hash functions created by the US national security agency (NSA), Secured Hash Function 512, is a component of the US Federal Information Processing Standard [30][31][32].

Proposed Scheme
In this section, we describe our proposed COVID-19 vehicle based on an efficient mutual authentication scheme for 5G-enabled vehicular fog computing in detail. In this paper, seven phases are included in our proposal, namely setup, enrolment, mutual authentication, updating private key, message signing, signature verification, and identity revocation phases. The seven phases in our proposal consist of two different aspects according to the special flag (SF) value that involves the mutual authentication process. Based on the SF value, we consider the type of vehicle to be a normal vehicle when SF = 0 and a COVID-19 vehicle when SF = 1.In the setup phase, the two types of SF values (e.g., 0 and 1) are used in this phase, in which TA is in charge of creating system parameters and broadcasting to all fog servers and vehicles. Furthermore, the two types of SF values are used in the setup phase. In the enrolment phase, TA is in charge of registering participating vehicles by applying both SF values to output two types of pseudonym IDs. Once the vehicle wishes to authenticate itself with the system, the vehicle will send its security parameters (e.g., password, public key, and SF value) to a nearby fog server through the wide communication range of 5G-BS. Based on the SF value, the vehicle then obtains a pseudonym ID to conceal its true identity. In the mutual authentication phase, the enroled vehicle will request the private key that is also based on the SF value. If the SF value equals 0, approval is granted for both fog servers and vehicles to broadcast messages, while if SF value equals 1, approval is allowed for only fog servers. In the message signing phase, the vehicle will start to create and sign a message to generate a signature tuple. Therefore, the verifier checks the validity and authenticity of the message based on the signature in the signature verification phase. In updating the private key phase, once the timestamp of the private key is close to being expired, the normal vehicle requests that its private key is renewed, while the COVID-19 vehicle skips this phase, which as a result, enhances performance and satisfies the security and privacy properties for all COVID-19 vehicles. Finally, in the identity revocation phase. Our proposal has the ability to trace and revoke any attacker (e.g., malicious normal or COVID-19 vehicles) that appears hostile to or pierced by the system. More precisely, our proposal expels and prevents the malicious vehicle from updating its private key in the previous phase. Figures 2 and 3 show normal vehicle and COVID-19 vehicle processes, respectively. These phases can be described in more detail as follows:

Setup Phase
The TA executes this phase to create the public parameters of the system. To maintain the security of the system in 5G-enabled vehicular fog computing, TA always frequently updates system parameters. The process of this phase is as follows: • TA defines the equation of the elliptic curve EC TA chooses the pairs of large primary numbers (e.g., p and q) based on an additive group G. • TA selects a random number s as the system's private key and computes the concerned system's public key Pub = s · P. • TA picks three hash cryptographic functions (e.g., TA securely saves the system's private key s to all fog servers. • Finally, TA broadcasts the system's parameters (p, q, Pub, P, h 1 , h 2 , h 3 ) to all fog servers through wire communication.

Enrolment Phase
Any new user who wishes to join 5G-enabled vehicular fog computing must first complete a number of legality-checking tasks before registering. This process is as follows: • The user submits a joining message including the vehicle's true identity VTID v i , password (e.g., PW), and an SF value to TA through a secured channel. Where values of SF = 0 and SF = 1 indicate the normal vehicle and COVID-19 vehicle, respectively. • In the case that a value of SF = 0, TA first verifies the vehicle's true identity VTID v i and then computes the normal vehicle's pseudonym ID NVPS = h 1 (VTID v i ||s).

Mutual Authentication Phase
Once vehicle v i wishes to authenticate itself with the system, the following process should be executed: • Vehicle v i picks random number r ∈ Z * q and calculates the two pseudonym IDs PID i (PID i,1 and PID i,2 (as Equations (1) and (2), respectively) based on the SF value to the normal vehicle and COVID-19 vehicle, respectively) in order to conceal the vehicle's true identity.
• Vehicle v i generates signature δ veh auth as Equations (3) and (4) according to the normal or COVID-19 vehicle, respectively.
• Vehicle v i transmits (PID i , T 1 , δ veh auth ) to the nearest fog server FS j through the widerange communication of 5G-BS. • Once the fog server FS j receives (PID i , T 1 , δ veh auth ) from the vehicle v i , the FS j first checks the freshness of the timestamp as Equation (5). Where T is the predefined delay time and T r is the received time of (PID i , T 1 , δ veh auth ), to check the validity of signatures as Equation (6) or Equation (7).
• If the above equation is false, the fog server FS j discards the message; otherwise, it sends (NVPS, T 2 ) or (CVPS, T 2 ) to TA based on the value of SF. • Once TA receives the security parameters from fog server FS j , TA checks the newness of timestamp T 2 and then verifies the match stored values NVPS or CVPS into the normal vehicle registration list and COVID-19 vehicle registration list, respectively. • TA sends valid or not valid to fog server FS j according to the above verification.
• If the message is verified, fog server FS j will generate the private key SK N (as Equation (8)) for the normal vehicle that has SF = 0 or SK C (as Equation (9)) for the COVID-19 vehicle that has SF = 1, where T SK is a lifetime of the private key.
• The fog server FS j encrypts the private key as Equation (10) or Equation (11) based on the type of vehicle.  (12) and (13).
• In case of the normal vehicle (e.g., SF = 0), the vehicle v i decrypts the private key and checks the signature δ f og auth In the case of the COVID-19 vehicle (e.g., SF = 1), the vehicle v i decrypts the private key SK C = SK Enc C ⊕ h 2 (r · Pub) and checks signature δ f og auth Note that the normal vehicle that has an SF = 0 will exchange data among the vehicles using its private key SK N , while not required to broadcast messages (e.g., the velocity, location, speed, direction) to others for COVID-19 vehicles. Thus, the COVID-19 vehicle only sends a message (e.g., healthcare information) to the nearest fog server through the communication range of 5G-BS using its private key SK C .

Updating Private Key Phase
In this section, when lifetime T SK is close to expiring, the normal vehicle only executes this phase to update its private key SK N , while the COVID-19 vehicle skips this phase. The normal vehicle will update the private key with the nearest fog server through wide-range communication by 5G-BS without being required to touch TA. This process is as follows: • Vehicle v i selects random number r new ∈ Z * q and calculates the two pseudonym IDs PID new i (PID new i,1 and PID new i,2 ) with Equation (14) in order to conceal the vehicle's true identity.
• Vehicle v i sends (PID i , PID new i , T SK , T 4 , δ new ) to nearest the fog server FS j , where δ new is calculated as Equation (15).
• Once receiving (PID i , PID new i , T SK , T 4 , δ new ) from the normal vehicle v i , the fog server FS j firstly checks the newness of the timestamp T 4 as Equation (5). Additionally, the fog server FS j checks the expiration time of T SK .

•
The fog server FS j checks the authenticity and validity of signature δ new as Equation (16).
• If Equation (16) holds, the fog server FS j prepares a new private key SK new N as Equation (17)  .
• The fog server FS j encrypts new private key SK new N as SK new i,1 ) and computes δ new f og as Equation (18). Note that the normal vehicle in our proposed travels from fog servers to others via different 5G-BS within the VANET system. This means that a vehicle has the ability to renew its pseudonym ID and private key without communicating with TA. As a result, our proposal avoids the single point of failure.

Message Signing Phase
Once vehicle v i wishes to broadcast the message in an open channel environment of 5G-enabled vehicular fog computing, the vehicle must run this phase as follows: • Vehicle v i generates message M i regarding its road status and current freshness timestamp T i . • Vehicle v i prepares two pseudonym IDs PID i (PID i,1 and PID i,2 ) and concerned private key Sk N which was obtained from fog sever. • Vehicle v i computes a message signature δ i as Equations (19) and (20) for normal vehicle and COVID-19 vehicle, respectively.
• Vehicle v i then computes σ i = δ i · P, which is applied to reduce the number of multiplication operations of ECC. As a result, reducing the overhead of the system from the verifier side in our proposal. • Normal vehicle v i broadcasts message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ) to other normal vehicles or nearby fog servers.
Note that only a normal vehicle executes this phase to sign message and sends it to other vehicles or fog servers, while a COVID-19 vehicle only sends the security parameters with the message to nearby a fog sever through wide-range communication of 5G-BS.

Signature Verification Phase
Once the recipient (fog server or vehicle) receives message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ) from vehicle v i , the verifier recipients should authenticate and validate the sent message before accepting message M i as follows: • Checker tests the freshness of timestamp T i of message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ) as shown in Equation (5) in order to detect replay attacks. • Checker uses one of the following processes (single-signature verification or batch signature verification) in order to detect modification, forgery, or MITM attacks. • Single signature verification process: checker tests whether Equation (21) holds or not.
• Batch signature verification process: checker tests whether Equation (22) holds or not.

Identity Revocation Phase
In this phase, TA does not only trace the attacker (normal malicious vehicle or malicious COVID-19 vehicle), but also revokes the identity of the malicious vehicle from obtaining the VANET service. This process is as follows: • Once reporting the forge message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ), the fog server computes NVPS for the normal vehicle or CVPS for COVID-19 vehicle as Equation (23) or Equation (24), respectively. Note that when the timestamp T SK of private key SK N is close to expiring, the vehicle should request a nearby fog server to update the parameters. In the case that a normal vehicle is revoked, the fog server will discard the process since it was revoked and identified on the vehicle revocation list. At the same time, the fog server will discard the message that was sent from the revoked COVID-19 vehicle before is accepted.

Security Analysis and Comparison
This section proves the security analysis and comparison of the proposed scheme as follows.

Security Analysis
Our proposed scheme should be satisfying security and privacy requirements in the following steps: • Authentication and integrity: Before accepting a message, our proposal checks the signature that was attached to a message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ). It then only accepts messages that calculate by evaluating Equations (21) and (22). Accordingly, the requirements of a authentication and integrity are applied in our proposal. • Privacy-preserving: The proposed scheme generates two random numbers s and r as Pub and PID i,1 = r · P, respectively. Hence, any attacker attempting to obtain NVPS/CVPS from a message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ) will not be capable of doing so without these two numbers. Since PID i,2 = NVPS ⊕ h 1 (r · Pub) and PID i,2 = CVPS ⊕ h 1 (r · Pub), it becomes a difficult problems. Accordingly, the requirement of privacy-preserving is applied in our proposal.
• Traceability and revocation: Any attacker that attempts to send forged messages or interfere with the operation of the system can be blocked and have their registration revoked by the TA by tracing the message's source. The vehicle that receives the forged message transmits it to the TA, which performs the steps in Section 4.7. Accordingly, the requirements of traceability and revocation are applied in our proposal. • Replay attack: Since the timestamp T i is included in a message-tuple (M i , PID i,1 , PID i,2 , T i , T SK , σ i ), the proposed scheme can avoid replay attacks using Equation (5). Accordingly, a replay attack is resisted in our proposal. • Forgery attacks: Since the signature tuple is validated by the TA using Equations (21) and (22), no attacker may falsify the identity of a legitimate vehicle sending a message. Accordingly, the forgery attack is resisted in our proposal. • Modify Attacks: Similar to the forgery attack, it needs an attacker to forge a signature tuple that is validated by computing (21) and (22). This is impossible to fake computationally. Hence, our technique is protected against this attack. • Man-in-the-middle attack: Because the vehicles communicate directly with one another and are shielded from interference, these types of attacks are not viable.

Security Comparison
This section evaluates and compares the proposed scheme and other related schemes in terms of privacy and security requirements. Table 1 lists the privacy and security comparison. As shown in Table 1, none of these schemes address the COVID-19 virus and solutions for vehicular networks to exchange messages with trusted parts. In order to cope with these issues, this paper proposes efficient mutual authentication that consists of two different aspects according to the special flag (SF) value that involves the mutual authentication process. Based on the SF value, we consider the type of vehicle to be a normal vehicle when SF = 0 and a COVID-19 vehicle when SF = 1. This section presents the test-bed experiments to estimate the running time needed for various cryptographic operations used in the proposed scheme and existing related schemes utilizing the well-known "MIRACL Crypto SDK [33]" which is a C/C++ based library of programming software. For simplicity, the following notations used in this paper are: • T mul denotes the estimated running time needed for ECC scalar multiplication operation; • T add denotes the estimated running time needed for the ECC point addition operation P + Q; • T h denotes the estimated running time needed for the secure cryptographic hash function.
Under this scenario, we have presented the computer setting as follows: "Model: Desktop, Processor: AMD Ryzen 7 5800H with Radeon Graphics, CPU Architecture: 64 bits, OS: Windows 11 Home Single Language with 16 GB memory". There have been 1000 runs of each primitive. For each primitive, the average times in milliseconds are noted. The experiment's results based on MIRACL are displayed in Table 2.

Notation
Running Time T mul 0.6718 ms T add 0.0031 ms T h 0.0001 ms

Computational Cost and Comparison
In this section, we estimate the computation cost of the operations used in singlemessage signing, single-message verification, and batch messages verification for our proposed and existing ECC-based related schemes. Table 3 lists a comparison of the computational costs.
The entity in the scheme of Li et al. [23] requires two general hash functions and one operation of scalar multiplication for single-message signing. Accordingly, the whole computation overhead is 2T h + 2T mul ≈ 2 * 0.0001 + 1 * 0.6718 ≈ 0.6729 ms, while the entity needs one operation of point additions, two general hash functions, and four operations of scalar multiplication for single-message verification. Accordingly, the whole computation overhead is 1T add + 2T h + 4T mul ≈ 1 * 0.0031 + 2 * 0.0001 + 3 * 0.6718 ≈ 2.0236 ms. Additionally, the entity needs (n) operations of point addition, 2n general hash functions, and (n + 2) operations of scalar multiplication for batch message verification. Accordingly, the whole computation overhead is nT add + 2nT h + (n + 2)T mul ≈ 1.3436 + 1.3487nn ms.
The entity in the scheme of Cui et al. [24] requires three general hash functions and three operations of scalar multiplication for a single-message signing. Accordingly, the whole computation overhead is 3T h + 3T mul ≈ 3 * 0.0001 + 3 * 0.6718 ≈ 2.0157 ms, while the entity needs one operation of point addition, two general hash functions, and three operations of scalar multiplication for single-message verification. Accordingly, the whole computation overhead is 1T add + 2T h + 4T mul ≈ 0.0031 + 2 * 0.0001 + 3 * 0.6718 ≈ 2.0187 ms. Additionally, the entity needs (n − 1) operations of point addition, 2n general hash functions, and (n + 2) operations of scalar multiplication for batch message verification. Accordingly, the whole computation overhead is n − 1T add + 2nT h + (n + 2)T mul ≈ 1.3405 + 0.6782n ms.
The entity in the scheme of Alshudukhi et al. [25] requires two general hash functions and two operations of scalar multiplication for single-message signing. Accordingly, the whole computation overhead is 2T h + 2T mul ≈ 2 * 0.0001 + 2 * 0.6718 ≈ 1.3438 ms, while the entity needs one operation of point addition, two general hash functions, and three operations of scalar multiplication for single-message verification. Accordingly, the whole computation overhead is 1T add + 2T h + 4T mul ≈ 0.0031 + 2 * 0.0001 + 3 * 0.6718 ≈ 2.0187 ms. Additionally, the entity needs (n) operations of point addition, 2n general hash functions, and (n + 2) operations of scalar multiplication for the batch message verification. Accordingly, the whole computation overhead is nT add + 2nT h + (n + 2)T mul ≈ 1.3436 + 0.6782n ms.
The entity in the scheme of Al-Shareeda et al. [26] requires two general hash functions and one operation of scalar multiplication for a single-message signing. Accordingly, the whole computation overhead is 2T h + 1T mul ≈ 2 * 0.0001 + 0.6718 ≈ 0.672 ms, while the entity needs one operation of point addition, two general hash functions, and four operations of scalar multiplication for single-message verification. Accordingly, the whole computation overhead is 1T add + 2T h + 4T mul ≈ 0.0031 + 2 * 0.0001 + 4 * 0.6718 ≈ 2.6905 ms. Additionally, the entity needs (n) operations of point addition, 2n general hash functions, and (2n + 2) operations of scalar multiplication for batch message verification. Accordingly, the whole computation overhead is nT add + 2nT h + (2n + 2)T mul ≈ 1.3436 + 1.3469n ms.
The entity in our proposed scheme requires one operation of point addition, one general hash function, and one operation of scalar multiplication for a single-message signing. Accordingly, the whole computation overhead is 1T add + 1T h + 1T mul ≈ 0.0031 + 0.0001 + 0.6718 ≈ 0.675 ms, while the entity needs one operation of point addition, two general hash functions, and two operations of scalar multiplication for single-message verification. Accordingly, the whole computation overhead is 1T add + 2T h + 2T mul ≈ 0.0031 + 2 * 0.0001 + 2 * 0.6718 ≈ 1.3469 ms. Additionally, the entity needs (n + 1) operations of point addition, n general hash functions, and two operations of scalar multiplication for batch message verification. Accordingly, the whole computation overhead is (n + 1)T add + nT h + 2T mul ≈ 1.3467 + 0.0032n ms.

Communication Cost and Comparison
In this section, we estimate the communication costs of the item size used as the final exchanged message among entities for our proposed and existing ECC-based related schemes. The major concentration is the communication overhead consisting of the pseudonym IDs, signatures, and timestamps for the message-signature tuples. Referring to [13,17,34], we suppose that the bit lengths for the timestamp, hash function, element in Z * q , and element in G are 32, 160, 160, 320 bits, respectively. Table 4 lists a comparison of communication costs of the proposed scheme and related works.
Hence, according to the above analysis, this paper proves that the communication costs of each element (as can be seen in Section 4.5) in message-tuple is lower compared with recent studies.

Simulation Environment
This section implements the proposed scheme in a simulation environment in order to evaluate the performance.
As listed in Figure 4, the proposed scheme generates the traffic simulator and network simulator using SUMO [35] and OMNeT++ [36], receptively. Additionally, the proposed scheme applies tools and frameworks such as OpenStreetMap [37], GatcomSUMO [38], VEINS [39], FogNetSim++ [40], Simu5G [41], and MIRACL [33] to implement a simulation environment in an urban area for 5G-enabled vehicular fog computing. The simulation environment's settings are listed in Table 5. Each cryptographic operation has its own distinct runtime, and that is what is used to calculate the total time. The overhead cost is the amount of time that has passed since the exit and the entrance (see Equation (25)).
where T i in is the message entrance time i, M is the message number, and T i out is the message exit time i. Figure 5 depicts the average time to verify a single message between the proposed and existing schemes.

Conclusions
In this paper, the development of an efficient mutual authentication scheme for healthcare solutions in 5G-enabled vehicular fog computing places emphasis on controlling automotive pandemics in intelligent transportation systems. In the proposed scheme, there is no requirement to broadcast messages (e.g., velocity, location, speed, direction) to others for COVID-19 vehicles. Thus, the COVID-19 vehicle only sends a message (e.g., healthcare information) to the nearest fog server through the communication range of 5G-BS using its private key. Security analysis shows that the proposed scheme satisfies privacy and security requirements as well as achieves COVID-19 and healthcare solutions. The performance section evaluates whether the proposed scheme is more efficient in terms of communication and computation costs as compared to the most recent related works.

Conflicts of Interest:
The authors declare no conflict of interest.