Introduction
-
We propose a novel efficient and lightweight VANET scheme that overcomes a critical driving area problem found in existing group-based authentication schemes. A general hash function has been adapted during data transitions for the entire system without requiring heavy-weight bilinear pairings or Elliptic-curve cryptography (ECC).
-
We made a detailed security analysis and demonstrate that our scheme meets the security requirements for VANETs.
-
We have enhanced the vehicle authentication process so that it does not cause a bottleneck for the TA.
-
We have mitigated the communication and computation weights for the available schemes.
Related works
Preliminaries
Notation | Description |
---|---|
\( {\text{RID}} \) | Vehicle real identity |
\( {\text{h}} \)(.) | General hash function |
\( TA \) | Trusted authority |
\( RSU \) | Roadside unit |
\( OBU \) | On-board unit |
\( L_{TA - OBU} \) | List of OBUs information saved in the TA |
\( L_{RSU - OBU} \) | List of RSU–OBU authentication data saved in the RSU |
\( PWD_{1} \) | OBU login password |
\( PWD_{2} \) | \( OBU - TA \) verification password |
\( C_{1,} C_{2} \) | Critical areas between two \( RSUs \) |
\( V_{i} \) | The \( i \)th vehicle |
\( {\text{CR}}_{v} \) | \( V_{i} \)’s conventional public authentication key |
\( Tlist \) | A temporary list in the RSUs for saving vehicle information, which is in the critical area |
\( ID_{R} \) | The identity of the \( RSU \) |
\( ID_{R + 1} \) | The identity of the neighbouring RSU, which is next to the vehicle’s current \( RSU \) |
\( ID_{R - 1} \) | The identity of the neighbouring RSU, which is prior to the vehicle’s current \( RSU \) |
\( S_{R - V} \) | \( OBU - RSU \) authentication secret key |
\( {\text{SK}}_{{{\text{R}} - {\text{TA}}}} \) | \( RSU - TA \) authentication secret key |
\( T \) | The timestamp |
\( indx \) | The vehicle’s group index number in the \( L_{RSU - OBU} \) |
\( PID_{i} \) | \( V_{i} \)’s pseudonym |
∥ | Concatenation operation |
\( \oplus \) | Exclusive-OR operation |
\( int \) | Integer number |
\( M_{i} \) | \( V_{i} \)’s traffic-related message |
\( L \) | Hash signature calculated by the \( RSU \) during the authentication phase |
System model and components description
Security objectives
The one-way hash function
Cuckoo filter
Review of the critical driving area problem in the [21‐23] CCPA schemes
The proposed scheme
System initialization and setup phase
-
The TA selects the hash function h(.).
-
The TA shares the system hash function to all RSUs and OBUs during their registration to the VANET.
-
The TA assigns a unique identity of RSU \( ID_{\text{R}} \) and secrete key \( SK_{R - TA} \) for every RSU, as well as sending { \( {\text{ID}}_{{{\text{R}} - 1}} \),\( {\text{ID}}_{{{\text{R}} + 1}} \) }, where (\( {\text{ID}}_{{{\text{R}} - 1}} \),\( {\text{ID}}_{{{\text{R}} + 1}} \)) represent the identities of the previous and next neighbour for the current \( {\text{RSU}} \).
Authentication phase
-
The OBU generates a random number \( i \in Z \) and then computes \( I \) and \( PID_{i} \), where \( I = i \oplus PWD_{2} \) and \( PID_{i} = RID_{i} \oplus h\left( i \right) \).
-
The OBU computes \( \mu_{auth} = h\left( {T_{1} ID_{R} PID_{i} ICR_{i} RID_{i} S_{R - V} } \right) \), then sends \( \left\{ {T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} } \right\} \) to the current \( RSU \).
-
According to the receiving \( RSU \)’s \( ID_{R} \), the TA finds the corresponding \( SK_{R - TA} \) from its repository and examine the \( RSU \)’s signature \( {\text{SIG}}_{ = }^{?} {\text{h }}\left( {T_{2} \left\| {ID_{R} } \right\|SK_{R - TA} } \right) \). If invalid, it drops the message, otherwise, it performs the coming steps.
-
Based on the receiving OBU’s key, \( CR_{i} \), the TA extracts the corresponding secret key \( PWD_{2} \) from the registration list \( L_{TA - OBU} \) and calculates \( i '= I \oplus PWD_{2} \) and \( RID_{i}^{ '} = PID_{i} \oplus h\left( {i '} \right) \).
-
The TA matches \( RID_{i} ' \) with the supposed \( V_{i} \)’s \( RID_{i} \) that is already stored in \( L_{TA - OBU} \); if these match, then the TA extracts the \( V_{i} \)’s corresponding \( S_{R - V} \) and checks the equation \([{\mu _{auth}}_ = ^?h\left( {{T_1}\left\| {I{D_R}} \right\|PI{D_i}\left\| I \right\|C{R_i}\left\| {RI{D_i}} \right\|{S_{R - V}}} \right)]\). If this is valid and the \( V_{i} \) is not in the revocation list, the TA calculates \( \beta = {\text{h}}\left( {{\text{T}}_{3} \left\| {{\text{SK}}_{{{\text{R}} - {\text{TA}}}} } \right.} \right) \oplus S_{R - V} \) then sends the message \( \left\{ {T_{3} , T_{1} , \beta , PID_{i} , CR_{i} ,\uplambda} \right\} \) to the RSU, where \( \uplambda = {\text{h}}\left( {T_{1} \parallel T_{3} \parallel S_{R - V} \parallel PID_{i} \parallel CR_{i} \parallel {\text{SK}}_{{{\text{R}} - {\text{TA}}}} } \right) \).
Broadcasting phase
Verification phase
Result case | Positive filter | Negative filter | Validity of \( \gamma \) |
---|---|---|---|
1 | Yes | No | Valid |
2 | No | Yes | Invalid |
3 | No | No | Waiting mode |
4 | Yes | Yes | False query |
Critical area verification phase
New RSU joining phase
Vehicle revocation phase
Security analysis
Security discussion
The security goals | [21] | [22] | [23] | SD2PA |
---|---|---|---|---|
Message integrity and authentication | ✓ | ✓ | ✓ | |
Identity privacy preserving | ✓ | ✓ | ✓ | ✓ |
Traceability | ✓ | ✓ | ✓ | ✓ |
Revocability | ✓ | X | ✓ | ✓ |
Non-repudiation | ✓ | ✓ | ✓ | ✓ |
Unlinkability | ✓ | ✓ | ✓ | ✓ |
Resistance to modification attack | ✓ | ✓ | ✓ | ✓ |
Resistance to replay attack | ✓ | ✓ | ✓ | ✓ |
Resistance to impersonation attack | ✓ | ✓ | ✓ | ✓ |
Lightweight | x | X | X | ✓ |
-
Modification attack: In the SD2PA scheme, the beacon contains \( \left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\} \), where \( \gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right\|} \right) \). The adversary must, therefore, have the secret key \( S_{R - V} \), if he or she wants to modify the beacon, which means this scheme is able to resist this type of attack.
-
Replay attack: In the SD2PA scheme, the timestamp is attached to each beacon and is added to the hashed signature \( \gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right\|} \right) \). It is therefore impossible for an adversary to replay the beacon, making this scheme resistant to this type of attack.
-
Impersonation attack: In the SD2PA scheme, the beacon contains \( \left\{ {\gamma , T_{5} , M_{i} , ID_{R} , indx} \right\} \), where \( \gamma = h\left( {T_{5} \left\| {PID_{i} } \right\| S_{R - V} \left\| {M_{i} } \right\| ID_{R} \left\| {indx} \right.} \right) \). The adversary must have the secret key \( S_{R - V} \), if he or she wants to impersonate the vehicle, making this scheme resistant to this type of attack.
Mutual authentication proof
The notations | Meaning |
---|---|
\( \rho , \varrho \) | The main participants in the model |
\( X_{m} \) | Messages |
\( K \) | A secret key |
\( \rho | \equiv \varrho \) | \( \rho \) believes \( \varrho \) |
\( \rho \triangleleft X_{m} \) | \( \rho \) sees \( X_{m} \) |
\( \rho |\sim X_{m} \) | \( \rho \) sent \( X_{m} \) |
\( \# \left( {X_{m} } \right) \) | The message \( X_{m} \) is fresh |
\( \rho \mathop \leftrightarrow \limits^{K} \varrho \) | \( \rho \) and \( \varrho \) communicate by \( K \) |
\( \rho \Rightarrow \varrho \) | \( \rho \) is able to control \( \varrho \) |
\( \left( {X_{m} } \right)_{K} \) | The message \( X_{m} \) is hashed by \( K \) |
-
R1: Message meaning rule: \( \frac{{\rho | \equiv \rho \mathop \leftrightarrow \limits^{K} \varrho , \rho \triangleleft \left( {X_{m} } \right)_{K} }}{{\rho \left| { \equiv \varrho } \right|\sim X_{m} }} \)
-
R2: Freshness rule: \( \frac{{\rho | \equiv \# \left( {X_{m} } \right)}}{{\rho | \equiv \# \left( {X_{m} ,Y_{m} } \right)}} \)
-
R3: Nonce-verification rule: \( \frac{{\rho | \equiv \# \left( {X_{m} } \right),\rho \left| { \equiv \varrho } \right|\sim X_{m} }}{{\rho \left| { \equiv \varrho } \right| \equiv X_{m} }} \)
-
R4: Jurisdiction rule: \( \frac{{\rho \left| { \equiv \varrho } \right| \Rightarrow X_{m} , \rho \left| { \equiv \varrho } \right| \equiv X_{m} }}{{\rho | \equiv X_{m} }} \)
-
G1: \( TA\left| { \equiv OBU} \right| \equiv \left( {\mu_{auth} } \right) \)
-
G2: \( TA\left| { \equiv RSU} \right| \equiv \left( {SIG} \right) \)
-
G3: \( RSU| \equiv \left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right) \)
-
G4: \( OBU\left| { \equiv RSU} \right| \equiv \left( L \right) \)
-
PM1: \( {\text{OBU}} \to {\text{RSU}}:\left\{ {T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} } \right\} \).
-
PM2: \( RSU \to TA:\left\{ {T_{2} , T_{1} , ID_{R} , PID_{i} , I, CR_{i} , \mu_{auth} , SIG} \right\} \)
-
PM3: \( TA \to RSU:\left\{ {T_{3} , T_{1} , \beta , PID_{i} , CR_{i} , {\lambda }} \right\} \)
-
PM4: \( RSU \to OBU:\left\{ {T_{4} , L, index} \right\} \)
-
IM1: \( {\text{OBU}} \to {\text{TA}}:\left( {\mu_{auth} } \right)_{{h\left( {RID_{i} \parallel S_{R - V} } \right)}} \)
-
IM2: \( {\text{RSU}} \to {\text{TA}}:\left( {SIG} \right)_{{h\left( {SK_{R - TA} } \right)}} \)
-
IM3: \( TA \to RSU:\left( {RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU} \right)_{{h\left( {SK_{R - TA} } \right)}} \)
-
IM4: \( RSU \to OBU:\left( L \right)_{{h\left( {S_{R - V} } \right)}} \)
-
A1: \( {\text{RSU}}| \equiv \# \left( {{\text{T}}_{1} ,{\text{T}}_{3} } \right) \)
-
A2: \( {\text{TA}}| \equiv \# \left( {{\text{T}}_{2} } \right) \)
-
A3: \( {\text{OBU}}| \equiv \# \left( {{\text{T}}_{4} } \right) \)
-
A4: \( TA| \equiv OBU\mathop \leftrightarrow \limits^{{RID_{i} \parallel S_{R - V} }} TA \)
-
A5: \( RSU| \equiv RSU\mathop \leftrightarrow \limits^{{SK_{R - TA} }} TA \)
-
A6: \( TA| \equiv RSU\mathop \leftrightarrow \limits^{{SK_{R - TA} }} TA \)
-
A7: \( RSU| \equiv TA \Rightarrow RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU \)
-
A8: \( OBU| \equiv RSU\mathop \leftrightarrow \limits^{{S_{R - V} }} OBU \)
Performance analysis
Computational overhead
Operations | Descriptions | The execution time (ms) |
---|---|---|
\( T_{sm - e} \) | Execution time for calculating the elliptic curve point multiplication | 0.3476 |
\( T_{sm - e - s} \) | Execution time for small-scale scalar point multiplication operation based on elliptic curve | 0.0246 |
\( T_{pa - e} \) | Execution time for calculating the elliptic curve point addition | 0.002 |
\( T_{h} \) | Execution time for the general hash operation | 0.0012 |
\( T_{aes - e} \) | Execution time for the encryption in the AES algorithm | 0.183 |
\( T_{aes - d} \) | Execution time for the decryption in AES algorithm | 0.157 |
-
OBU–RSU authentication key verification, in case of SBV, this stage requires one scalar multiplication operation and one hash function operation. For NBV, it requires (n) scalar multiplication operation and (n) hash function operation.
-
Message signature validation requires two scalar multiplication operations, one point addition operation and one hash function operation for SBV. NBV consists of (n + 2) scalar multiplication operations, (2n) small-scale scalar point multiplications operations, (n + 1) point addition operations and (n) hash function operations.
Scheme | BG (ms) | SBV (ms) | NBV (ms) |
---|---|---|---|
[21] | 0.6988 | 1.0472 | \( 0.6972 + 0.3983n \) |
[22] | 0.1854 | 0.1618 | \( 0.0048 + 0.157n \) |
[23] | 0.6976 | 1.0472 | \( 0.6972 + 0.7488n \) |
SD2PA | 0.0048 | 0.036 | \( 0.036n \) |