Lightweight Secure Authentication and Key Distribution Scheme for Vehicular Cloud Computing

3.1. Network Architecture

• Vehicle: In our network model, a vehicle has sensors to sense traffic congestion and status, Global Positioning System (GPS), On-Board Unit (OBU), and Event Data Recorder (EDR). The vehicle is the main component of the proposed network architecture.
• On-Board Unit (OBU): Each vehicle is equipped with an OBU to collect its information, such as the position, speed, and acceleration/deceleration, and transmits it to vehicles or RSUs within its transmission range through the wireless medium. As stated in Reference [24], “it uses the Wireless Access in Vehicular Environment (WAVE) standard, which is based on the emerging IEEE 802.11p specification”.
• Road Side Units (RSU): It is a fixed infrastructure deployed on the roadside to monitor the traffic or in the road intersections to manage the traffic lights. It acts as a gateway for the vehicles to access the Internet. The main use of RSUs in the proposed approach is to provide secret key and authentication key transmission in a secure manner.
• Vehicle-to-Vehicle (V2V) communication: Vehicles communicate with other vehicles within their transmission range through a direct wireless transmission of data without need of using fixed infrastructures. In GUARANTY algorithm, vehicles must be authenticated to establish a secure communication between them. The registration, Pseudo-ID formation, and authentication phases are used at the start of vehicles’ trip or when the vehicle’s secret key is threatened. In this case, the vehicle can re-register itself at the nearby RSU to have a new secret key.
• Vehicle-to-RSU (V2R) communication: This is the communication between vehicles and RSU, and it is usually done via wireless transmission. In our model, vehicles send a registration request for key generation and a signature request for its authentication.
• Vehicle-to-Internet (V2I) communication: It is a communication, between vehicles and the Internet, which can be established directly or indirectly using the RSU.
• Cloud Center: A virtual server, in a cloud computing platform, which offers many services, such as computing capabilities, storage, and communication resources on demand. The cloud generates the keys. All vehicles’ information is stored in the database and then used in vehicles’ private key generation.

3.2. Network Security Model

• The RSUs are connected via a wired connection, and the communication between them is carried out via a secure channel.
• Vehicles are in an area covered completely by RSUs.
• The cloud is trusted and secure.
• The communication between the cloud and the RSU is carried out via a secure channel.
• The vehicles contain OBUs that are equipped with processing and storage capabilities to carry out the encryption/decryption.
• Cloud-based Revocation Authorities (CRAs) are responsible for the revocation process.

3.3. Access Structures

3.4. Access Tree

3.5. Linear Secret Sharing Schemes (LSSSs)

3.6. Bilinear Maps

3.7. Ciphertext-Policy Attribute-Based Encryption (CP-ABE)

3.8. Identity-Based Signature (IBS)

4.1. Registration

• Step 1: The cloud assigns an identifier $I{D}_{RSU}$, a verification number $V{N}_{RSU}$, and an authentication key ‘AuK’ to each RSU. It also registers all vehicles’ ID with their chassis numbers (CN).
• Step 2: Each vehicle must register itself at the nearby RSU, when it enters or leaves the particular region, by broadcasting a Registration Request (RR) message encrypted with the public key of RSU $\left(P{K}_{RSU}\right)$. The registration request contains the vehicle’s attribute values (vehicle identifier, location, current speed, and the direction value, etc.). The RSU verifies location-related attributes using location proof methodologies [29]. At the end, the vehicle’s attribute values are transmitted to the cloud with the VN${}_{RSU}$, where VN${}_{RSU}$ ensures the legitimacy of the RSU. In the case where the RSU is malicious, it will be detected by the cloud by checking the VN${}_{RSU}$, and then it will be revoked.

  $$RR=(T,I{D}_z,S{p}_z,D_z,L_z,I{D}_{RSU})P{K}_{RSU}.$$
  T represents the current time, $I{D}_z$ represents vehicle’s identifier, $S{p}_z$ represents the speed of vehicle Z, $D_z$ represents the direction of vehicle Z, $L_z$ represents the position of vehicle Z, and $I{D}_{RSU}$ represents the identifier of the nearest RSU.
• Step 3: The cloud generates two keys, after receiving the vehicle’s attribute values, and sends them to the RSU: the attribute key ‘AK’ and the secret key ‘SK’. When RSU receives the two keys, it must encrypt the secret key ’SK’ using attribute key ‘AK’ of the corresponding vehicle.
  For the transmission of the secret key ‘SK’, we apply the CP-ABE algorithm, which has the following five parts:

  a

  Setup: When the cloud receives the attribute values of the vehicle, it runs the setup algorithm. It takes attributes set S as input in which the set of attributes contains the vehicle’s attributes transmitted by the vehicle and the corresponding chassis number (CN) registered in the cloud. The cloud then generates the public and the master key as output. For this, it chooses two groups G1 and G2 of prime order P, and two generators $g_1$ and $g_2$. It chooses also two random exponents b, $\alpha$$\in Z_p$. The public key is generated as:

  $$P{K}_c=g_1,g_2,e{(g_1,g_2)}^{\alpha },g_1^b,g_2^b.$$

  (1)

  The master key is set as:

  $$MK=g^{\alpha }.$$

  (2)

  b

  Key-generation: To generate the attribute key (AK), the cloud gets the master-key (MK) and a set of attributes S as input. It generates the attribute key AK corresponding to the set of attributes of the vehicle. The algorithm first generates a random number t $\in Z_p$ and then creates the attribute key as:

  $$AK=(K=g_2^{\alpha }{g}_2^{bt},L=g_2^t,\forall x\in S,K_x=h_x^t),$$

  (3)

  where $h_x$ is the attribute string of attribute x hashed to an element of G1. To generate the secret key, the cloud chooses a random number s $\in Z_p$ and computes the secret key:

  $$SK=e{(g_1,g_2)}^{\alpha s}.$$

  (4)

  c

  Encryption: The algorithm defines the access matrix (M, k) based on a given a LSSS. The matrix M is defined as (l*n ), where l is the number of rows, n is the number of columns, and k refers to the function that maps rows of M to the attributes. The algorithm selects a random vector v= (s, $y_2$, …, $y_n$)${}^T$$\in Z_p$, where the exponent s $\in Z_p$ is randomly chosen as the secret to be shared in secret key generation. The other values are used to share the encryption exponent s. It calculates ${\lambda }_i=M_{i}v$, where i takes value from 1 to l. The algorithm also chooses random $r_1$, …, $r_n$$\in Z_p$. The ciphertext is published as:

  $$CT=(C=g^s,C_i=g^{bsi}{h}_i^{-r_i},D_i=g_2^{r_i}).$$

  (5)

  So, the cloud generates keys, sends them to the RSU, and then it encrypts the secret key using the attribute key and sends the ciphertext to the corresponding vehicle.

  d

  Decryption: In this step, the vehicle takes as input a ciphertext (CT) and the attribute key for a set of attributes S. The Lagrange basis polynomials [30] evaluated at zero, $p_i\left(0\right)$, are computed for the indices involved in access policy by:

  $$p_i\left(0\right)=\prod _{j\in S,i\ne j}{\displaystyle \frac{X_j}{(X_j-X_i)}}.$$

  (6)

4.2. Pseudo-ID Formation

• Step 1: RSU will encrypt the secret key ‘SK’ using the attribute key ‘AK’ and broadcasts it on the network. Vehicles within the range of particular RSU will acquire the encrypted secret key. The vehicle that satisfies the attribute values will decrypt the message and recover the secret key for Pseudo-ID generations.
• Step 2: Pseudo-ID of the vehicle (z) is generated by encrypting the original ID of the vehicle (z) by its secret key and sends it to the RSU as:
  $PI{D}_z=<T,{\left(I{D}_z\right)}_{SK},I{D}_{RSU}>$, where $PI{D}_z$ is the generated Pseudo-ID of vehicle Z, T is the current time, ${\left(I{D}_z\right)}_{SK}$ is the encrypted value of the vehicle’s ID using the secret key, and $I{D}_{RSU}$ is the ID of the RSU.

4.3. Authentication

A-

V2I and I2V Authentication: Identifier-Based Signature (IBS) algorithm is used to ensure the authentication among vehicles and Infrastructures as illustrated in Algorithm 3. The V2I and I2V authentication are explained next:

• Step 1: Each RSU broadcasts its information periodically to all vehicles within its rang. This information is in this form:

  $$<I{D}_{RSU},T,P{K}_{RSU}>,$$

  where $I{D}_{RSU}$ is the ID of RSU, T is the current time, and $P{K}_{RSU}$ is the public key of RSU.
• Step 2: Vehicles acquire the information from RSU. Vehicles that need to generate their signature will send a signature request message to the RSU. The signature request has this form:

  $$<I{D}_{RSU},PI{D}_z,T,SI{G}_z(I{D}_z||T)>,$$

  where $I{D}_{RSU}$ is the ID of RSU, $PI{D}_z$ is the Pseudo-ID of the vehicle Z, T is the current time, and $SI{G}_z(I{D}_z||T)$ is the IBS generated by vehicle using its ID and the current time. The $I{D}_z$ and the current time values are concatenated, and the resulting value is encrypted using the secret key ($S{K}_Z$), which results in $SI{G}_z(I{D}_z||T)$.
• Step 3: After receiving the signature request from the vehicle, the RSU verifies whether the vehicle is legitimate(by decrypting the signature using the secret key of vehicle Z and verifying the identifier and the time). If it is a legitimate vehicle, the RSU encrypts the authentication key(AuK) using the secret key of vehicle Z and broadcasts it with an authentication message to indicate that $V_z$ is legitimate. The authentication signature message has this form:

  $$<I{D}_{RSU},T,PI{D}_z,SI{G}_z(PI{D}_z{||T),AuM,\left(AuK\right)}_{S{K}_z}>,$$

  where $I{D}_{RSU}$ is the ID of RSU, T is the current time, $PI{D}_z$ is Pseudo-ID of vehicle z, $SI{G}_z(I{D}_z||T)$ is the signature of vehicle Z, AuM is an authentication message to indicate that the vehicle which has the $PI{D}_z$ is legitimate, and ${\left(AuK\right)}_{S{K}_z}$ is an authentication key encrypted by the secret key of vehicle Z. Only the vehicle authenticated (vehicle Z) can access to this key. All vehicles within RSU’s transmission range save the Pseudo-ID of vehicle Z in their authentication table for V2V authentication.

B-

V2V Authentication: To establish secure communication between vehicles, V2V authentication is carried out (Figure 3 describes the sequence diagram of the V2V authentication process). Algorithm 4 presents the V2V authentication process. When a vehicle wants to communicate with other vehicles, it will generate an authentication signature $AuSI{G}_z$ and send a communication request message:

$$<PI{D}_z,T,CReq,SI{G}_z(I{D}_z||T)AuSI{G}_z(PI{D}_z||T),I{D}_{RSU}>,$$

where $PI{D}_z$ is the Pseudo-ID of vehicle Z, T is the current time, CReq is the communication request message, $SI{G}_z(I{D}_z||T)$ is the IBS (generated by vehicle Z using its ID, and the current time), and $AuSI{G}_z(PI{D}_z||T)$ is the authenticated signature of vehicle Z. The Pseudo-ID of vehicle Z (PIDz) and the current time value are concatenated, and the resulting value is encrypted using the secret key (AuK), which results in $AuSI{G}_z(PI{D}_z||T)$. $I{D}_{RSU}$ is the ID of the RSU which has authenticated the vehicle. Each vehicle that receives the communication request message of vehicle Z must verify $PI{D}_z$ in its authentication table, and it must verify also the authentication signature (by decrypting the signature using AuK and verifying the Pseudo-ID and the time).

4.4. Cryptography

A-

V2I Communication: After the distribution of SK in a secure manner, we use symmetric cryptography for the transmission of messages. Vehicles must encrypt the message using their secret key (SK) to ensure confidentiality and the security of information. The RSU then decrypts the message and transmits it to the cloud via a secure channel. When the cloud sends the answer, the RSU must also encrypt the message using the secret key SK of the vehicle. In this way, we ensure secure communication between cloud and vehicles. V2I communication process is described in Algorithm 5.

B-

V2V Communication: Each vehicle in an RSU’s transmission range must authenticate itself on the RSU, and, when the $RS{U}_1$ authenticates the vehicle, it will send an authentication message with authentication key ($Au{K}_1$). All vehicles authenticated on the same RSU will obtain the same authentication key ($Au{K}_1$). So, we can provide a secure communication session with vehicles authenticated by the same RSU. Vehicles authenticated by different RSU ($RS{U}_2$) can obtain the ($Au{K}_1$) from its nearby RSU ($RS{U}_2$) and provide a secure communication session with other vehicles. Algorithm 6 shows the V2V communication process.

Vehicles that want to communicate with other vehicles must encrypt the message using the authentication key (AuK), and only authenticated vehicles can decrypt the message.

5.1. Security Analysis

A

Take the RSU’s information and declare itself that it is the RSU: In this case, the malicious vehicle cannot decrypt the message (vehicles’ attributes) because it does not have the private key of RSU ($Pr{K}_{RSU}$). The vehicle waits for its $S{K}_i$ for $\Delta$ time; then, it will define the RSU as a malicious node after this time, and it will run a System Revocation.

B

Take the RSU’s identifier and generate its private and public keys: In this case, the malicious vehicle can access to the vehicles’ attributes but:

-

It cannot access to the cloud for keys generation because it does not have the $V{N}_{RSU}$ of RSU. If it tries to access the cloud, it will be detected as a malicious node, and then its access will be revoked.

-

When it generates false keys ($A{K}_i$, $S{K}_i$), $V_i$ can detect that $A{K}_i$ is wrong because the $A{K}_i$ does not include the real $C{N}_i$ due to cloud access failure of the malicious node to recover the $C{N}_i$ (RSU does not have a verification number). So, the malicious RSU cannot generate $A{K}_i$ and cannot use the vehicles’ attributes to access the $S{K}_i$ (RSU does not have the $C{N}_i$ ). When vehicles receive a wrong $A{K}_i$ from a node, they will define it as a malicious node and run the System Revocation.

-

Impersonate attack: is an attack that harms the authentication of vehicles. In this kind of attack, an attacker impersonates a good vehicle to receive its messages, and get privileges not granted to it. It can also do malicious things and declare that a legitimate vehicle did them. In our proposed scheme, malicious vehicles can use the Pseudo-ID ($PI{D}_i$) and the signature $SI{G}_i(PI{D}_i||T)$ of the legitimate vehicle to communicate with the other vehicles. So, it will send a communication request: <$PI{D}_i$, T, CReq, $SI{G}_i(PI{D}_i||T)$, $SIGA{u}_i(PI{D}_i||T)$, $I{D}_{RSU}>$ to vehicle z. Vehicle z must verify the $AuSI{G}_i(PI{D}_i||T)$ of vehicle ‘i’ to detect that its signature is not satisfied (it does not have the real AuK) and declares it as a malicious vehicle.

-

Man in the Middle (MiM) attack: Tt is an attack that harms the confidentiality and the integrity of vehicles. In this case, a malicious vehicle listens to the communication between two vehicles. GUARANTY algorithm ensures the confidentiality of:

-

Messages transmitted between vehicles, by the encryption of messages using the authentication key (AuK).

-

Messages transmitted between vehicles and RSU, by the encryption of messages using the vehicle’s secret key (SK).

-

Attributes transmitted during the registration step, by the encryption of attributes using the public key of RSU ($P{K}_{RSU}$).

-

Sybil attack: this attack harms the authentication of vehicles. In this case, an attacker generates multiple fake vehicles on the road with different identities and tries to authenticate them at the same time. Our approach can detect this attack:

-

If the malicious vehicle communicates with RSU to register and authenticate itself. The RSU detects that it is a malicious vehicle by verifying the location-related attributes using location proof methodologies [29].

-

If the malicious vehicle ‘mal’ generates its Pseudo-ID $\left(PI{D}_{mal}\right)$ and its signature $SI{G}_{mal}$ and establishes a communication directly with other vehicles by sending a communication request <$PI{D}_{mal}$, T, CReq, $SI{G}_{mal}$($PI{D}_{mal}||T$), $AuSI{G}_{mal}$($PI{D}_{mal}||T$),$I{D}_{RSU}$>. They can detect that it is a malicious vehicle by verifying the $PI{D}_{mal}$ and $SI{G}_{mal}(PI{D}_{mal}||T)$ in their authentication table.

-

Eavesdropping attack: The proposed algorithm authenticates the vehicle properly, which does not allow the intruder to access the information circulating in the network during the transmission process. Furthermore, the symmetric session keys (Sk, AuK) is used to encrypt the collected data. This approach keeps the data confidential and stops the attacker from accessing the message.

5.2. Specification of GUARANTY Scheme Using AVISPA Tool

5.3. Computational Complexity Analysis

5.4. Performance Evaluation