Designing an Efficient and Secure Message Exchange Protocol for Internet of Vehicles

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. (erefore, 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. (e performance comparisons show that the SMEP-IoV is lightweight and completes the authentication process in just 0.198ms.


Introduction
e Internet of Vehicles (IoV) is a self-organized network of vehicles on the road and the road side units (RSUs). e 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. e 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. e 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. e 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]. erefore, the security and privacy of the entire IoV including the communicating entities have more importance than all other factors. e 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 keybased 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. e motivations and contributions of the study are explained in Subsection 1.2, while the Subsection 1.3 discusses the adopted adversarial model. e 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. e study is concluded finally in Section 7. 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. e 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.

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  (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) e security of the proposed scheme is proved using formal RoR. (iii) e comparative study with respect to efficiency and security among proposed and several existing studies is also provided in this study.

Attack Model.
We have taken into consideration the eCK adversary model [3], with strong adversary as compared with DY [4] and CK [5] models. e 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].

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][11][12][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. e 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] Here, K VS is the master secret key of the vehicle server. Now, using K VS , any dishonest vehicle of the system can launch any attack on any devices. For example, (i) e dishonest vehicle with extracted K VS can disclose any session key shared among two vehicles. Let V x initiates a login request by sending M i1 , M i2 , M AE , T 1 }. By just listening to the request, the dishonest vehicle using M i1 , M i2 , and T 1 can compute

Proposed SMEP-IoV
e 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:

SMEP-IoV : Initialization.
e vehicle server (VS) selects its secret key K vs , a one way hash function

SMEP-IoV : RSU Registration.
During this phase, VS registers all road side units by assigning a unique identity ID rj and a shared secret key K rj � h(ID rj ‖K VS ).
e VS stores ID rj in its database.

SMEP-IoV : Vehicle Registration. During this phase, VS registers all vehicles by assigning a unique identity ID
e VS stores ID vi , PID vi , A vi , and B vi in the memory of the vehicle V i . Furthermore, the VS stores ID vi in its own memory. Please note, except ID vi , the VS does not store any other parameter relating to a vehicle say V i . Specifically, PID vi , A vi , and B vi are not stored in the memory of VS.

SMEP-IoV : Message Authentication.
For message authentication, the vehicle V i initiates the following steps with RSU j and vehicle server VS, the in-sequence steps as shown in Figure 2: where V i initiates the message authentication process by generating fresh timestamp t i and a random number On receiving M vi � PID vi , M i1 , M i2 , t i , the RSU j checks the freshness of t i by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSU j terminates the process; otherwise, RSU j generates new timestamp t j and a random number r j . Moreover, RSU j computes M j1 � E K rj (r j , t j ) and sends M rj1 � ID rj , M vi , M j1 , t j to VS.

Security and Communication Networks
After receiving M rj1 � ID rj , M vi , M j1 , t j , the VS checks the freshness of t j by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the VS terminates the process; otherwise, VS computes K rj � h(ID rj ‖K VS ) and decrypts M j1 using K rj to obtain the pair (r j ′ , t j ′ ). e VS also verifies the sameness of received t j with decrypted t j ′ , and in case both are same, the VS using its secret key K vs decrypts PID vi and obtains (ID vi , r 0 ). Now, the VS computes A vi � h(K vs ‖ID vi ) and B vi � h(PID vi ‖K vs ) and gets r i � B vi ⊕ M i2 . After that, the VS After receiving M vs � RSK, VSK, RSV, t vs , the RSU j checks the freshness of t vs by comparing it with current timestamp; if the delay is not within a predefined tolerable range ΔT, the RSU j terminates the process; otherwise, RSU j Designing an efficient and secure Message Exchange protocol for Internet of Vehicles

Formal Security Analysis through BAN
e 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) L| ≡ w: L believes w (ii) L⊲w: L sees w (iii) L| ∼ w: L once said w, some time ago (iv) L|⇒w: L has got the entire jurisdiction over w (v) (#barw): the message w is fresh (vi) (L)w: L is used in formulae with w (vii) (w, w ′ ) k : w or w ′ is symmetrically encrypted with key K (viii) w, w ′ k : w or w ′ is hashed with key K (ix) L, w { } k : K is used in formula with w and L (x) LK↔L ′ : L communicates with the key K e following BAN logic rules are used to verify the security features: Rule 2. Nonce verification.
Corresponding with the above rules and assumptions, we accomplish the following goals in the BAN logic analysis. e symbols used here, i.e., (g, RSU j , V i , V s ), represent the goal, road side unit, vehicle, and vehicle server.
Security and Communication Networks Next, employing the above assumptions, we further analyze the idealized forms.
Taking the idealized version of M1 and M2: By applying seeing rule, we get According to D1, D2, P8, B9, and R1, we get Referring to X3, B1, R2, and R4, we get Referring to X5, B12, and R3, In accordance with X6, B14, and R3, we have Referring to X5, X7, and R6, we have Using X5, X7, B8, and R2, we get Taking the idealized version of M3, Using X11, B7, and R1, we have According to X12, B3, B13, R2, and R4, we have Next, considering M4 idealized form, Referring to X17, we apply R6 as According to X18, B2, we apply the R6 as e 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.

Informal Security Analysis
An informal security discussion on the security features of the proposed scheme is provided in following subsection:

Mutual Authentication.
e SMEP-IoV ensures mutual authenticity for all participating entities of the system. In particular, the RSU j authenticates both entities, VS and V i , by means of equality check comparing RSV against the computed h(SK‖t vs ) parameter. Since, RSU j is aware of the fact, the generated session key SK can only be constructed by a legitimate VS entity having access to master secret key K vs . Using K vs , VS can access r i , r j , A vi , and K rj factors to compute a valid SK. Likewise, V i authenticates RSU j on the basis of VSV equality check, after comparing it with the computed h(SK‖t jn ). Similarly, Vs authenticates V i by computing h(A vi ‖ID vi ‖t i ‖r i ) against M i1 . Realizing the fact that A vi is only held with a valid V i entity, it can validate the vehicle V i . If these equality checks fail, the mutual authentication cannot be assured in the protocol.

Stolen Verifier Attack.
In the proposed scheme, the vehicle server VS stores only public identities ( ID vi : i � 1, 2 . . . n ) 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. erefore, the possibility of stolen verifier attack on proposed SMEP-IoV is negligible.

Vehicle Anonymity.
e SMEP-IoV employs a pseudoidentity PID vi 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.

VS Impersonation Attack.
No adversary A can impersonate as Vs in the SMEP-IoV scheme. is is because, if an adversary attempts the same towards V i , the latter may discern the possibility of attack by comparing VSV against the computed factor h(SK‖t jn ). Similarly, if A attempts to impersonate as VS against RSU j , the RSU j may successfully thwart this attack on the basis of comparison of RSV and calculated h(SK‖t vs ). Hence, the SMEP-IoV is immune to VS impersonation attack.

RSU Impersonation Attack.
e SMEP-IoV is immune to RSU impersonation attack. Both entities V i and VS may easily prevent any attempt of impersonation as RSU on the part of adversary. is is due to the fact that VS shares a secret with RSU j . e use of fresh timestamps along with the shared secrets helps the VS entity in authenticating a legitimate RSU. Similarly, V i authenticates RSU j on account of the derived session key SK from the VSK message as submitted by a valid VS, which is further used in the later comparison of VSV. In this manner, both of the entities validate a legal RSU j on account of provided logical comparison of equality checks.

Man-in-the-Middle Attack (MiDM).
To launch a successful MiDM attack on SMEP-IoV, the adversary needs access to either the V i registration parameters such as A vi and B vi or access to secret key K rj or the master secret key K vs . On the other hand, as we see earlier, it is less likely for an adversary to initiate an impersonation attack on the protocol.

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.

Denial of Service.
Our scheme is resistant to denial of service attacks, since it engages fresh timestamps for the generation of M vi and M rj1 . 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.

Replay Attack.
In case an adversary attempts to initiate a replay attack towards any entity V i , RSU j , or VS, the SMEP-IoV may foil this attempt immediately after checking the freshness of timestamps t i , t j /t jn , and t vs , respectively. Hence our scheme is immune to this threat.

Performance and Security Comparisons
e performance and security comparisons of the proposed scheme with related existing scheme [22][23][24] are explained in the following subsections.

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. e 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 V i and RSU RSU j through the intermediate agent VS-Vehicle Server, V i executes 2C hs and 3C ed operations. Likewise, RSU j performs 2C hs + 2C ed operations while VS accomplishes 7C hs and 7C ed operations. Hence, total computational operations performed to complete a cycle of AKA are 11C hs + 12C ed . Using the experiment with computational times represented in Table 2, the performance comparisons are briefed in Table 3. e proposed scheme completes single AKA cycle in ≈0.198 ms. In contrast to the proposed scheme, the scheme of Yu et al. [23] completes single AKA cycle in ≈0.132 ms, the scheme of Vasudev et al. [22] and Mohit et al. [24] complete the one cycle of AKA in ≈0.082 ms and ≈0.108 ms, 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. e value of hash output is fixed at 160 bits. Moreover, the size of random numbers is also assumed as 160 bit of length. e communication cost of SMEP-IoV and related schemes of Yu et al. [23], Vasudev et al. [22], and Mohit et al. [24]

Security Features.
e security comparisons of the SMEP-IoV and related existing schemes [22][23][24] are provided in this subsection. Table 4 solicits the summary of the security comparisons. Due to disclosure of master secret key K VS , 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. e 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 manin-the-middle attack. e 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.

Conclusion
Initially, this study reviewed some of the recent authentication schemes for securing IoVs.
en, 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. e proposed secure message exchange protocol for IoV (SMEP-IoV) uses only lightweight symmetric encryption and hash functions. e 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
e data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest
e author declares that there are no conflicts of interest.