Efficient VANET safety message delivery and authenticity with privacy preservation

Symmetric key authentication schemes

Hu & Laberteaux (2006) proposed a Timed Efficient Synchronous Loss-Tolerant Authentication protocol (TESLA) that first broadcasts its MAC's encrypted message, then, after a specified period, the sending vehicle broadcasts the encryption key to all receiving vehicles. This process will help verify message authenticity and then decrypt the message. However, this scheme is not suitable for safety applications that have strict time constraints. Manvi & Tangade (2017) proposed a modified TESLA version called TESLA++ that is more secure and efficient. In TESLA++, the sender first broadcasts the MAC, then after a short period, the sending vehicle broadcasts the whole message and the authentication key.

Asymmetric key authentication schemes

Lin et al. (2007) integrated the identity-based signature with group signature techniques to provide security assurance with privacy preservation. Raya, Papadimitratos & Hubaux (2006) introduced a message authentication with privacy preservation protocol. In this protocol, each vehicle had a group of anonymous keys (public/private) and each key was used for a short time before being revoked. Zhu et al. (2014) proposed another efficient authentication scheme in which the whole area was divided into several regions (domains). Each region was managed by one RSU. The authors replaced the certificate revocation list (CRL) with a hash message authentication code (HMAC). This process minimized the total time required in the checking process.

Hybrid key authentication schemes

Studer et al. (2009) proposed a VANET authentication protocol (VAST) that combined the elliptic curve digital signature algorithm (ECDSA) with TESLA++. This combination resulted in both low communication and low computation, and achieved the non-repudiation requirement. Alfadhli et al. (2020) proposed a lightweight scheme called SD2PA that overcame the problem of non-safe driving in critical areas. This scheme provides a low computational and communication overhead. Manivannan, Moni & Zeadally (2020) provided a comprehensive survey on security issues that arise on VANET, including authentication, privacy, and secure message broadcasting and shed light on the open research security issues in VANET.

Lim & Manivannan (2016) proposed an efficient, secure, authenticated message delivery protocol. This protocol is dependent on the vehicle-to-infrastructure (V2I) communication model. They used the Diffie–Hellman (DH) protocol to generate and share the symmetric keys. This protocol uses both symmetric and asymmetric key cryptography algorithms. Liu et al. (2016) enhanced the message forwarding technique proposed by Lim & Manivannan (2016) using aggregate message authentication codes instead of the onion signature. Islam, Taha & Rowayda (2017) proposed a low computation overhead protocol that used a CRT-RSA cryptography algorithm instead of a traditional RSA. This protocol generated a shared symmetric key without using the well-known Diffie–Hellman protocol. The Diffie–Hellman protocol produces a large amount of computation overhead at each node.

We propose an efficient authentication protocol for message delivery. This protocol is considered to be an enhanced version of the low computation overhead protocol proposed by Islam, Taha & Rowayda (2017). This proposed protocol utilizes a combination of symmetric and asymmetric key cryptography algorithms. Moreover, we used a symmetric key generated and exchanged without using the Diffie–Hellman protocol (Diffie & Hellman, 1976). The group key is changed from an asymmetric key to a symmetric key instead of that presented by Islam, Taha & Rowayda (2017). The proposed change significantly reduces the overall computation overhead while preserving the overall security level.

The proposed protocol utilizes CRT-RSA (Kondracki, 1997) and (CRT-RSA algorithm, 2020) instead of using RSA (Mollin, 2002) to achieve the least encryption and decryption time as CRT-RSA is much faster than both RSA and Elliptic Curve (Dindayal & Dilip, 2018).

Proposed assumptions

We divided the whole VANET area into domains (groups), and each domain has one RSU that managed group communication. We used the V2I communication model and communication was performed only through the RSU. Each vehicle, within a group, was able to send or receive messages through the RSU using a suitable routing protocol. All RSUs could communicate with each other through wired or wireless communications and could communicate indirectly through the RTA. All RSUs, RTAs, and TA were trusted to be resistant to attacks. Moreover, the security parameters of each node (Vehicle or RSU) were changed periodically.

Objectives of the proposed protocol

Our protocol sought to achieve the following objectives:

• Low computation and communication overhead: The communication between vehicles and RSU remains intact for a few minutes. Hence, all required communication and computation processes should be performed quickly.

• Message integrity: Every message has to be delivered without any modifications and the message’s data integrity should be ensured.

• Message authenticity: The message source should be authenticated to prevent the impersonation attack.

• Privacy preservation: The real identity of vehicles should be protected during communication. However, the authorities should be able to find the real identity of any vehicle in exceptional cases, such as liability investigation.

Our notations are listed in Table 1.

A group registration phase

Each RSU broadcasts a beacon message contains its coordinates (x, y), timestamp (TS), and $I{D}_{RSU}$, as shown in Fig. 4. This message is broadcast periodically every 100 ms (IEEE Standards Association, 2006). A vehicle produces random 128 bits when it receives this message and the bits are utilized as a shared symmetric key with the RSU. The receiving vehicle then encrypts the generated key and its real identity using the public key of the RSU. This vehicle sends the encrypted data, through a registration message, to the RSU, as shown in Fig. 4. The digital signature of the message is generated using the generated shared symmetric key ( $K_{V_i-R_j}$) instead of the asymmetric key.

The group registration phase by Lim & Manivannan (2016) and Liu et al. (2016) uses the Diffie–Hellman (DH) protocol. DH is a public key cryptography algorithm that is used to produce and distribute a symmetric key between two entities (Diffie & Hellman, 1976). The key generation using DH protocol increases the computational overhead at the two entities. However, our symmetric key was generated and distributed similarly to Islam, Taha & Rowayda (2017), in which DH is not used and the vehicle generates random bits that will be used as a symmetric key. The vehicle then encrypts the generated key using the RSU’s public key before sending. Each vehicle, within the vehicle’s transmission range, can receive the encrypted message. However, only the RSU can decrypt the message because the RSU has the appropriate private key.

The RSU will extract the vehicle's real identity ( $I{D}_V$) and the generated symmetric key ( $K_{V_i-R_j}$) once the registration message is received. Next, the RSU will generate a random pseudo-identity ( $PI{D}_V$). This $PI{D}_V$ is used by the message sender (vehicle) for its incoming communications instead of its real identity. The RSU will then send a reply message, which is shown in Fig. 4. A vehicle will get its new $PI{D}_V$ and the shared group secret key $K_{G_i}$ when a vehicle receives a reply to its registration message. This secret key $K_{G_i}$ will be used in its group communications.

We changed the group key to a symmetric key rather than the asymmetric key found in the literature (Lim & Manivannan, 2016; Liu et al., 2016; Islam, Taha & Rowayda, 2017). The symmetric key algorithms provide integrity, confidentiality and authenticity. The main advantage of these algorithms is the low computation overhead and these algorithms are important in real-time applications. The symmetric key algorithms have the same security level as asymmetric key algorithms, which could be achieved with a smaller key size and lower computation overhead compared to asymmetric key algorithms (Luhach, 2016).

Send/receive messages phase

In this protocol, the transmitted data changed according to the application type. VANET applications can be classified as safety and non-safety applications. Safety applications have strict time constraints compared to non-safety applications. In safety applications, the message should be delivered within no more than 100 ms (Yousefi, Fathy & Bastani, 2012) and the computation delay should be minimal in safety applications.

A vehicle can send a one-to-one message after completing the registration phase (Unicast) or a group message (Broadcast). A vehicle sending a group message should first send the message to the RSU that manages the group. This message will be encrypted using the shared symmetric key between the vehicle and the RSU, as shown in Fig. 4. This message can be a safety message or a non-safety message. In case of a safety message, the RSU will broadcast the message as plaintext, as shown in Fig. 4. Otherwise, the message will be encrypted using the shared group secrete key $K_{G_i}$ as shown in Fig. 4.

The one-to-one message is sent from a vehicle to another group member (vehicle). This message contains the data to be sent in addition to the $PI{D}_V$ of the desired vehicle. The data and the destination’s $PI{D}_V$ will be encrypted using the shared symmetric key ( $K_{V_i-R_j}$). The message will then be sent to the RSU (Fig. 4), where it is received by the RSU and the message integrity and authenticity are verified. The RSU generates a message with the data that needs to be sent in addition to the $PI{D}_V$ of the original message sender (vehicle). This message, plus the source’s $PI{D}_V$, are encrypted using the shared symmetric key between the vehicle and the RSU. The RSU then sends the message as shown in Fig. 4.

Leave/join group phase

A vehicle outside the transmission range of the RSU (that controls its group) receives a beacon message from the neighboring RSU that controls the neighbor group. The vehicle will receive two beacon messages every 100 ms from two different RSUs. The vehicle compares the value of the received signal strength indicator (RSSI) of the two received signals. This process will determine the best RSU based on the RSSI values. If the new RSSI value is higher than the old one, this means that the vehicle is moving towards the new RSU. In this case, the vehicle should send a new registration message to leave its current group and join the new group that is controlled by the new RSU, as shown in Fig. 4. When the new RSU receives the registration message, it will send an informative message to the old RSU about vehicle departure as shown in Fig. 4. The RSSI value can be calculated as in Eq. (1) (Islam, Taha & Rowayda, 2017):

(1) $P_r={\displaystyle \frac{P_t\ast G_t\ast G_r\ast h_t^2\ast h_r^2}{d^{4}L}}$Where, $P_r$ is the power received at distance $d$, $P_t$ is the transmitted signal power, $G_t$ is the transmitter gain, $G_r$ is the receiver gain, $h_t$ is the transmitter antenna height, $h_r$ is the receiver antenna height, and L is the path loss.

Results of the group registration phase

We evaluated the computation overhead effect in the registration phase and compared the effects on the total time needed to complete this phase to the results from (Lim & Manivannan, 2016).

Our experiments were conducted using four different scenarios as follows:

• In the first scenario, we used the protocol described in Lim & Manivannan (2016). This model used DH to generate and distribute the symmetric key during the registration process. It also used the RSA algorithm.

• The second scenario was the same as the first scenario but used the CRT-RSA instead of the RSA algorithm.

• In the third scenario, the shared symmetric key was generated and distributed without using DH. This scenario used RSA as in the first scenario.

• In the fourth scenario, we use the proposed protocol and the shared symmetric key was generated and distributed without using DH as in the third scenario. In addition, this scenario used CRT-RSA algorithm as in the second scenario.

The computational time depended on many internal factors including memory access time, integer divisions, and multiplication time. Each scenario was simulated five times for greater accuracy, and the average, minimum, maximum, and the standard deviation (SD) values of the computational overhead were calculated from each scenario as illustrated in Table 3. Figure 5 shows the computational overhead of the registration phase in four different scenarios. The results show that the first scenario has the highest average computational delay, whereas, the fourth scenario had the lowest average computational delay. The average computational time of the second scenario was improved by 18% compared to the first scenario.

The third scenario’s average computational time improved by 82.5% compared to the second scenario. The fourth scenario’s average proposed computational time was enhanced by 91.7% compared to the third scenario. Our proposed protocol was the highest performing among the four scenarios studied.

Results of send/receive group non-safety message

Our experiments were performed to evaluate the average computational time of sending and receiving a non-safety group message. We examined the average computational time required to encrypt and decrypt the non-safety message and the symmetric key results from the proposed group were compared with the works introduced by Lim & Manivannan (2016) and Islam, Taha & Rowayda (2017).

We performed our experiment using two different scenarios: in the first scenario, we used the proposed group symmetric key protocol. In this case, the RSU encrypted the group message using the shared group symmetric key $\left({\mathrm{K}}_{{\mathrm{G}}_{\mathrm{i}}}\right)$ and the RSU broadcasted the message to its group. The vehicle decrypted the message using the shared group symmetric key $(K_{G_i})$ once it was received. In the second scenario, we used the group asymmetric key described by Lim & Manivannan (2016) and Islam, Taha & Rowayda (2017) where the RSU encrypted the message using the private group key $\left(\mathrm{S}{\mathrm{K}}_{{\mathrm{G}}_{\mathrm{i}}}\right)$. Then, the RSU broadcasted the message to its group members and the vehicle decrypted it using the shared public group key $\left(\mathrm{P}{\mathrm{K}}_{{\mathrm{G}}_{\mathrm{i}}}\right)$ once the message was received.

Occasionally, these two scenarios are examined in three different cases. In the first case, the message is broadcast to the current group only (zero-hop). In the second case, the message is broadcast to the current group and the adjacent group using only one-hop. In the third case, the message is broadcast to the current group and to the adjacent groups using only two-hop.

Table 4 and Fig. 6 show that sending and receiving a non-safety message encrypted with an asymmetric group key has the highest computational overhead. Interestingly, the computational overhead was enhanced when using the proposed group key (symmetric group key). The proposed protocol decreased the computational overhead by 41.2% in the zero-hop message. In the one-hop message, the overhead was decreased by 47.1% when using the proposed protocol. Finally, the overhead was decreased by 48.1% when using the proposed protocol with the two-hop message.

Results of send/receive a group safety message

We calculated the average computational time required to send and receive a safety group message. Similar to the non-safety experiments, three different cases were used in the non-safety experiment, which were to broadcast a safety message using zero-hop, one-hop, and two-hop. Fig. 7 shows that the safety message was sent and received within a time duration less than 100 ms in the zero-hop case as constrained in (Yousefi, Fathy & Bastani, 2012). The proposed protocol satisfies the time constraint described in (Yousefi, Fathy & Bastani, 2012).

Results of sending a one-to-one message

The proposed protocol allowed vehicles to send and receive a one-to-one message (unicast message). When a vehicle needed to unicast a message to another vehicle, that message was sent to the RSU. The RSU then checked that the destination vehicle was still a group member or if it had moved away. If the vehicle was still a member in the group, the RSU forwarded the message to the destination vehicle. If the vehicle had moved away, it forwarded the message to the RSU that managed its new group.

We calculated the average computational time required to send the message from a vehicle to another one in three different cases as follows: in the first case, the two vehicles were within the same group (zero-hop). In the second case, the destination vehicle was moved to the adjacent group (one-hop). In the third case, the destination vehicle was moved away by two-hop.

The experimental results are shown in Fig. 8. The average computational time required to send and receive a one-to-one message in the zero-hop, was 0.176 s, which is acceptable for non-safety applications (Hu & Laberteaux, 2006) and the proposed protocol satisfies the time recommended (Hu & Laberteaux, 2006).

Security and privacy features

The proposed protocol provides essential security requirements such as message authentication with privacy preservation, message confidentiality, message integrity, and non-repudiation.

Attack resistance

VANET and WSN both receive the same attack methods, including Sybil Attack, Message Fabrication and Modification Attack, and Eavesdropping Attack (Quyoom, Mir & Sarwar, 2020; Tchórzewski & Jakóbik, 2019). Our proposed work can resist many of these attacks. The main difference between WSN and VANET in security attacks is the battery drainage attacks which are a critical issue in WSN. An example of such attacks is the Denial-of-Sleep Attack.