Abstract
In the advancements in computation and communication technologies and increasing number of vehicles, the concept of Internet of Vehicles (IoV) has emerged as an integral part of daily life, and it can be used to acquire vehicle related information including road congestion, road description, vehicle location, and speed. Such information is very vital and can benefit in a variety of ways, including route selection. However, without proper security measures, the information transmission among entities of IoV can be exposed and used for wicked intentions. Recently, many authentication schemes were proposed, but most of those authentication schemes are prone to insecurities or suffer from heavy communication and computation costs. Therefore, a secure message authentication protocol is proposed in this study for information exchange among entities of IoV (SMEP-IoV). Based on secure symmetric lightweight hash functions and encryption operations, the proposed SMEP-IoV meets IoV security and performance requirements. For formal security analysis of the proposed SMEP-IoV, BAN logic is used. The performance comparisons show that the SMEP-IoV is lightweight and completes the authentication process in just .
1. Introduction
The Internet of Vehicles (IoV) is a self-organized network of vehicles on the road and the road side units (RSUs). The IoV provides intervehicles (V2V) and vehicles to RSUs (V2R) communication infrastructure [1], which can benefit in many ways including the information relating to road congestion/traffic issues, parking information, alternative routes, and warnings of potential accidents. Using the information, the drivers can quickly make decisions relating to vehicles and/or road/s. It can further help the unmanned vehicles regarding the accuracy and safety through the use of more sophisticated information and artificial intelligence techniques. The information exchanged or the communication among entities of IoV is always through public wireless channel, which makes it prone to several attacks. An attacker can easily listen and extract the meaningful information from the exchanged messages. Such information can be very crucial for the accuracy and safety of the vehicles in an IoV. The attacker can replay an old message or can inject a message with total fake information, and it can cause some severe consequences on the vehicles and the riders including the accidents. Moreover, the listened information can be used by an attacker to trace/track a vehicle/rider, and such information can be used for criminal/terrorism purposes. The information can also be faked for marketing purposes to gain attraction of the riders, while they are attracted to a specific route through false information of traffic as well as to compete for the parking lots [2].
Therefore, the security and privacy of the entire IoV including the communicating entities have more importance than all other factors. The goal can be achieved through authentication of the entities including vehicles before initiation of the communication among the entities of IoV. In this study, we proposed a lightweight symmetric key-based authentication scheme to secure message exchange among the entities of the IoV. We organize rest of the study as follows: Table 1 provides the notation guide. In Subsection 1.1, the system model is described. The motivations and contributions of the study are explained in Subsection 1.2, while the Subsection 1.3 discusses the adopted adversarial model. The Section 2 summarizes the existing related literature; whereas, our proposed secure message exchange protocol for IoV (SMEP-IoV) scheme is explained in Section 3. Using BAN logic, the Section 4 formally proves the security of the SMEP-IoV. In Section 5, a discussion on functional security and attack resilience of the proposed SMEP-IoV is given. Security and performance comparisons of the proposed SMEP-IoV with related schemes are given in Section 6. The study is concluded finally in Section 7.
1.1. System Model
Figure 1 shows a typical IoV scenario. It consists of vehicles, each having installed a processing unit called on-board unit, which is responsible for communication and processing of exchanged data among the vehicle and other entities of an IoV. Along with vehicles, there are road side units (RSUs), which are the infrastructure deployed on the road. Typically, communication is performed among vehicles and nearby RSU. Moreover, intervehicle communication is also an important component of the IoV. The whole network is administered by a trusted authority called vehicle server (VS). All the vehicles and related entities (RSUs) join the IoV by registering with VS. After getting registered with VS, the two entities can communicate with each other, for which both have to authenticate each other, and the authentication ensures that both communicating entities are legitimate.
1.2. Motivation and Contributions
Recently, many authentication schemes are proposed to secure message exchange among the entities of an IoV. However, many authentication schemes for IoV lack the required security features and resistance to known attacks. In this connection, Yu et al. proved some of the weaknesses of the scheme of Vasudev et al. Yu et al. further claimed to propose a secure authentication scheme with all required security features. The arguments in preceding section of this study refute their claim and the proof relating to several insecurities of Yu et al.’s scheme calls for an authentication scheme with all required security features.
The contributions of this study are many folds:(i)Initially, we unveiled that the insecurities of the IoV authentication scheme proposed by Yu et al. We then proposed a robust authentication scheme using symmetric key-based encryption and hash functions.(ii)The security of the proposed scheme is proved using formal RoR.(iii)The comparative study with respect to efficiency and security among proposed and several existing studies is also provided in this study.
1.3. Attack Model
We have taken into consideration the eCK adversary model [3], with strong adversary as compared with DY [4] and CK [5] models. The eCK is an extension of the CK model with a more strong adversary having capabilities to launch a key compromise impersonation attack in addition to controlling the communication channel, launching the power analysis to extract secrets stored in the smart card and access to all public parameters [6,7].
2. Related Literature
In their survey, Contreras-Castillo et al. [8] pointed out some security requirements and suggested to address authentication, integrity, confidentiality, and related security requirement before the IoV gain popularity. Some future directions were also discussed in [8]. In addition to the mentioned security requirements in [8], Mokhtar and Azab [9] stressed vehicle privacy, untraceability, access control, and resistance against tempering/forgery and jamming attacks.
In recent times, some authentication schemes were proposed [10–13]. Two different schemes were proposed by Lin et al. [14] and Yin et al. [15] using hashchains. Both schemes provided efficient and rapid authentication but lacked vehicle/user anonymity. The absence of anonymity could lead towards the leakage of sensitive vehicle/user information, IoV. In 2015, the scheme of Li et al. [16] was proved to have weaknesses against disclosure of session key attack by Dua et al. [17]. Afterwards in 2016, Wang et al. also proposed a smartcard-based two-factor authentication scheme for IoV [18], which was proved as having weaknesses against many attacks including vehicle/user forgery and smart card stolen attacks, and the scheme was also lacking anonymity by Amin et al. [19]. A pairing-based scheme was also proposed by Liu et al. [20]. However, due to usage of expensive pairing operations, a considerable delay can happen, which is unsuitable for fast moving vehicles. Another lightweight scheme was proposed by Ying et al. [21]. However, Chen et al. [2] found critical weaknesses in the scheme of Ying et al. Due to usage of modular exponentiation, the scheme of Chen et al. entails inefficiencies against storage, communication cost, and computation time. Quite recently, in 2020, Vasudev et al. [22] presented another efficient authentication scheme. In 2020, Yu et al. [23] pointed out that the scheme of Vasudev et al. lacks mutual authentication and has weaknesses against some attacks including session key disclosure and vehicle/user forgery attacks. Yu et al. also proposed an improved scheme. However, the scheme of Yu et al. is prone to many attacks including disclosure of master secret key of the vehicle server. Due to leakage of , the scheme of Yu et al. cannot be deployed in any environment because if an attacker is able to get , it can generate secret parameters for any of the existing device to impersonate on behalf of that device; moreover, the attacker can register and deploy fake vehicles in the system. Any registered device can compute using the stored in the smartcard and its own password and identity related parameters, i.e., and . For this, a vehicle/user computes enters password (), identity (), and computes , and . The now computes . Here, is the master secret key of the vehicle server. Now, using , any dishonest vehicle of the system can launch any attack on any devices. For example,(i)The dishonest vehicle with extracted can disclose any session key shared among two vehicles. Let initiates a login request by sending . By just listening to the request, the dishonest vehicle using , , and can compute and , on the fly. Similarly, when the responding vehicle sends reply message , the dishonest vehicle using and can compute and the session key by just executing instep two hash functions on the public parameters.(ii)Likewise, the dishonest device can launch man in middle, impersonation, and all related attacks using . For example, when sends request message to , the dishonest vehicle can extract and then can generate another valid response message by using and current timestamp. Ultimately, the possession of enables a dishonest vehicle to generate a valid request and a response message, and it can act like a man in middle.
3. Proposed SMEP-IoV
The proposed secure message exchange protocol for IoV (SMEP-IoV) consists of four phases. Table 1 provides the notation guide to understand the technical details of the proposed SMEP-IoV, briefed in following subsections:
3.1. SMEP-IoV : Initialization
The vehicle server (VS) selects its secret key , a one way hash function and a symmetric encryption/decryption function .
3.2. SMEP-IoV : RSU Registration
During this phase, VS registers all road side units by assigning a unique identity and a shared secret key . The VS stores in its database.
3.3. SMEP-IoV : Vehicle Registration
During this phase, VS registers all vehicles by assigning a unique identity . Moreover, VS computes , , and . The VS stores , , , and in the memory of the vehicle . Furthermore, the VS stores in its own memory. Please note, except , the VS does not store any other parameter relating to a vehicle say . Specifically, , , and are not stored in the memory of VS.
3.4. SMEP-IoV : Message Authentication
For message authentication, the vehicle initiates the following steps with and vehicle server , the in-sequence steps as shown in Figure 2:
3.4.1. PMA 1
where initiates the message authentication process by generating fresh timestamp and a random number . further computes and . finalizes these steps by sending to .
3.4.2. PMA 2
On receiving , the checks the freshness of by comparing it with current timestamp; if the delay is not within a predefined tolerable range , the terminates the process; otherwise, generates new timestamp and a random number . Moreover, computes and sends to .
3.4.3. PMA 3
After receiving , the checks the freshness of by comparing it with current timestamp; if the delay is not within a predefined tolerable range , the terminates the process; otherwise, computes and decrypts using to obtain the pair . The also verifies the sameness of received with decrypted , and in case both are same, the using its secret key decrypts and obtains . Now, the computes and and gets . After that, the checks , and if verification is successful, the generates timestamp and a random number . The computes session key , , , and . In addition, the computes and . Now, the sends to .
3.4.4. PMA 4
After receiving , the checks the freshness of by comparing it with current timestamp; if the delay is not within a predefined tolerable range , the terminates the process; otherwise, computes session key . Now, checks the session key verifier , and if is verified successfully, the accepts the session key. Now, generates new timestamp and session key verifier for . After that, the sends to .
3.4.5. PMA 5
After receiving , the checks the freshness of by comparing it with current timestamp; if the delay is not within a predefined tolerable range , the terminates the process; otherwise, decrypts using and obtains . Now, checks the session key verifier , and if is verified successfully, the accepts the session key and updates and .
4. Formal Security Analysis through BAN
The Burrows–Abadi–Needham (BAN) logic analysis is performed to test the protocol from various security aspects with a focus on mutual key agreement, key sharing, and protection from exposure to session key. We used the following symbolic tokens to perform this analysis.(i) believes (ii) sees (iii) once said , some time ago(iv) has got the entire jurisdiction over (v)(): the message is fresh(vi)(): is used in formulae with (vii) or is symmetrically encrypted with key (viii) or is hashed with key (ix) is used in formula with and (x) communicates with the key
The following BAN logic rules are used to verify the security features:
Rule 1. Message meaning.
Rule 2. Nonce verification.
Rule 3. Jurisdiction.
Rule 4. Freshness conjunction.
Rule 5. Belief rule.
Rule 6. Session key.Corresponding with the above rules and assumptions, we accomplish the following goals in the BAN logic analysis. The symbols used here, i.e., , represent the goal, road side unit, vehicle, and vehicle server.(i)G1: (ii)G2: (iii)G3: (iv)G4: (v)G5: (vi)G6: Initially, the communication contents must be adapted into idealized form as shown in the following:(i)M1: (ii)M2: (iii)M3: (iv)M4: Furthermore, we take the following assumptions to support the security proof.(i)(ii)(iii)(iv)(v)(vi)(vii)(viii)(ix)(x)(xi)(xii)(xiii)(xiv)(xv)Next, employing the above assumptions, we further analyze the idealized forms.
Taking the idealized version of M1 and M2:(i)M1: (ii)M2: (iii)By applying seeing rule, we get(i)(ii)According to , and , we get(i)(ii)Referring to , and , we get(i)(ii)Referring to , and ,(i)In accordance with , and , we have(i)Referring to , and , we have(i) (goal 5)Using , and , we get(i) (goal 6)Taking the idealized version of ,(i)On the application of seeing rule for , we get(i)Using , and , we have(i)(ii) (goal 1)According to , and , we have(i)(ii) (goal 2)Next, considering idealized form,(i)M4: On the application of seeing rule for , we have(i)While , , and imply(i)Referring to , and , we have(i)From , and rule 3, we get(i)Referring to , we apply as(i) (goal 3)According to , we apply the as(i) (goal 3)The discussed cases for proving the protocol in BAN logic make obvious that the contributed scheme entirely supports mutual authentication and protects the established session key among the three participating members.
5. Informal Security Analysis
An informal security discussion on the security features of the proposed scheme is provided in following subsection:
5.1. Mutual Authentication
The SMEP-IoV ensures mutual authenticity for all participating entities of the system. In particular, the authenticates both entities, and , by means of equality check comparing against the computed parameter. Since, is aware of the fact, the generated session key can only be constructed by a legitimate entity having access to master secret key . Using , can access , , , and factors to compute a valid . Likewise, authenticates on the basis of equality check, after comparing it with the computed . Similarly, Vs authenticates by computing against . Realizing the fact that is only held with a valid entity, it can validate the vehicle . If these equality checks fail, the mutual authentication cannot be assured in the protocol.
5.2. Stolen Verifier Attack
In the proposed scheme, the vehicle server VS stores only public identities () of all the registered vehicles in its memory. VS does not store any other vehicle-related secret parameter in its own memory, and the verifier is with the vehicle. Therefore, the possibility of stolen verifier attack on proposed SMEP-IoV is negligible.
5.3. Vehicle Anonymity
The SMEP-IoV employs a pseudoidentity for each vehicle, which is renewed and replaced after the termination of each session. In this manner, the vehicle or user remains anonymous during the execution of the protocol. Moreover, there is no desynchronization possible in case an adversary holds or blocks the message on its way.
5.4. VS Impersonation Attack
No adversary A can impersonate as Vs in the SMEP-IoV scheme. This is because, if an adversary attempts the same towards , the latter may discern the possibility of attack by comparing against the computed factor . Similarly, if attempts to impersonate as against , the may successfully thwart this attack on the basis of comparison of and calculated . Hence, the SMEP-IoV is immune to impersonation attack.
5.5. RSU Impersonation Attack
The SMEP-IoV is immune to impersonation attack. Both entities and may easily prevent any attempt of impersonation as on the part of adversary. This is due to the fact that shares a secret with . The use of fresh timestamps along with the shared secrets helps the entity in authenticating a legitimate . Similarly, authenticates on account of the derived session key from the message as submitted by a valid , which is further used in the later comparison of . In this manner, both of the entities validate a legal on account of provided logical comparison of equality checks.
5.6. Man-in-the-Middle Attack (MiDM)
To launch a successful MiDM attack on SMEP-IoV, the adversary needs access to either the registration parameters such as and or access to secret key or the master secret key . On the other hand, as we see earlier, it is less likely for an adversary to initiate an impersonation attack on the protocol.
5.7. Session Key Security
As we see earlier, no adversary could engage in the mutual authentication process until it gains access to secure credentials of the system either held by the registration authority or registered entities. Since, the SMEP-IoV provides mutual authentication to all participants, the established session key is only known to the legitimate members involved in the protocol execution.
5.8. Denial of Service
Our scheme is resistant to denial of service attacks, since it engages fresh timestamps for the generation of and . Due to these timestamps, the receiving entity may check the freshness of the incoming message and discard the message immediately if the latency is beyond a certain preset threshold.
5.9. Replay Attack
In case an adversary attempts to initiate a replay attack towards any entity , , or , the SMEP-IoV may foil this attempt immediately after checking the freshness of timestamps , /, and , respectively. Hence our scheme is immune to this threat.
6. Performance and Security Comparisons
The performance and security comparisons of the proposed scheme with related existing scheme [22–24] are explained in the following subsections.
6.1. Performance Comparisons
For measuring the computation time and cost, Pi3 B+ is used with Cortex A53 (ARMv8) 64 bit SoC and with processing speed 1.4 GHz along with 1 GB LPDDR2 SDRAM RAM. The simulation results of basic operations executed over Pi3 are given in Table 2. For completion of authentication and a key agreement (AKA) among a vehicle and RSU through the intermediate agent -Vehicle Server, executes and operations. Likewise, performs operations while accomplishes and operations. Hence, total computational operations performed to complete a cycle of AKA are . Using the experiment with computational times represented in Table 2, the performance comparisons are briefed in Table 3. The proposed scheme completes single AKA cycle in . In contrast to the proposed scheme, the scheme of Yu et al. [23] completes single AKA cycle in , the scheme of Vasudev et al. [22] and Mohit et al. [24] complete the one cycle of AKA in and , respectively.
For communication cost comparisons, subsequent consideration is taken as per the sizes of different parameters. Timestamps and identity are taken as 32 and 64 bits, respectively; whereas, the sizes of the outputs of the symmetric key and asymmetric key operations are taken as 128 and 1024 bits. The value of hash output is fixed at 160 bits. Moreover, the size of random numbers is also assumed as 160 bit of length. The communication cost of SMEP-IoV and related schemes of Yu et al. [23], Vasudev et al. [22], and Mohit et al. [24] is computed as the bits exchanged among the IoV entities. The sends to , where the size of is . Subsequently, the sends , where the size of is . The replies with , where the size of is . The final message was sent from to , where the size of is . Therefore, total communication cost is 2848 bits. The communication cost of Yu et al.’s scheme is 864, while the communication costs of Vasudev et al. and Mohit et al. are 800 and 1760, respectively.
6.2. Security Features
The security comparisons of the SMEP-IoV and related existing schemes [22–24] are provided in this subsection. Table 4 solicits the summary of the security comparisons. Due to disclosure of master secret key , the Yu et al.’ scheme [23] is vulnerable to many attacks including impersonation of vehicle, RSU, and vehicle server, along with session key disclosure and vehicle/user anonymity violations attack. The scheme of Vasudev et al. [22] lacks mutual authentication and has insecurities against vehicle, RSU, and vehicle server impersonation attacks. Moreover, Vasudev et al.’s scheme is insecure against man-in-the-middle attack. The scheme of Mohit et al. [24] is also weak against man in middle attack. In contrast, proposed SMEP-IoV provides all security features and is robust against the known attacks.
7. Conclusion
Initially, this study reviewed some of the recent authentication schemes for securing IoVs. Then, we developed a symmetric key-based authentication scheme, through which a vehicle can share a secret key with corresponding RSU through the mediation of the vehicle server. The proposed secure message exchange protocol for IoV (SMEP-IoV) uses only lightweight symmetric encryption and hash functions. The comparisons of the SMEP-IoV show that proposed scheme compromises slight performance overhead and provides adequate security, which other competing schemes do not provide. Hence, due to performance and security provisions, SMEP-IoV best suits the security requirements of the fast moving vehicles in the IoV scenario.
Data Availability
The data used to support the findings of this study are available from the corresponding author upon request.
Conflicts of Interest
The author declares that there are no conflicts of interest.
Acknowledgments
The author would like to thank the the academic editor Dr. Prosanta Gope for valuable suggestions to improve the quality, correctness, presentation, and readability of the manuscript.