Acknowledgment
3.3 Location Certificate-Based Scheme
Our proposed approach for Sybil attack detection is based on a traditional public key certificate together with position verification. In this approach, the whole network is viewed as a tree-like structure rooted at the CA, which maintains information about all vehicles in the VANET. At the second level, or layer, from the root is the set of all RSUs, which effectively constitute a fixed infrastructure.
Unlike a normal tree structure, there are links between RSUs. The third (and last) level from the root contains the mobile nodes (vehicles). Each vehicle has a unique ID and certificate registered with the CA.
The main properties of the proposed design are as follows:
No dependence on specialized hardware: This scheme does not need any special type of hardware. It makes use of existing infrastructure for the detection of attacks.
The CA and RSUs both participate in detection: This approach avoids a central bottleneck in communication, and attack detection happens at both the CA and RSU levels. The support of other vehicles in the network is not needed.
Node authentication depends on geolocation information: The claimed location of nodes is verified using the strength of received signals and also the geographic location of nodes.
Support for high vehicular mobility: Our proposed approach supports a high mobility of vehicles between RSUs. The overhead associated with attack detection does not affect the performance of the VANET.
Sybil nodes are isolated from the network: The Sybil node will be auto- matically removed from the network and will be prevented from engaging in any further communication.
The fundamental assumptions for the proposed scheme are as follows: (i) Each RSU must know its geographical location. (ii) The RSUs are connected to adjacent RSUs and the CA with a high-speed back end. (iii) RSUs are considered as trusted entities. (iv) Each vehicle is registered with the CA with a unique ID and public key certificate. (v) Each vehicle has a GPS device to acquire its geolocation.
encrypt (M={Vid, position, timestamp, sign (M, PKVj–1)}, PKRSi)
Position verification RSUi
Vj
Figure 3.2: Communication from vehicle to RSU
3.3.1 Sybil node detection scheme
Our proposed scheme is founded on the concept of a location certificate issued by a RSU for communication with other vehicles under the same RSU. For each vehiclej, the CA stores the vehicle ID with the corresponding public key (PKVj).
Each RSU continuously broadcasts its public key (PKRS) using the beacon signal. Before we describe the major steps in this scheme, we first clarify the common notations used in this scheme in the table below.
Notation Meaning
(PKCA,PKCA−1) Public and private key of CA
(PKRSi,PKRSi−1) Public and private key ofith RSU unit (PKVj,PKV j−1) Public and private key of jth vehicle
1. Suppose the jth vehicle enters theith RSU’s range (Figure 3.2). This step is a one-time process for each session and occurs only if the vehicle does not have a valid location certificate. The vehicle creates a location certifi- cate request in the following format:{vehicle ID, position, timestamp}.
Here, position is taken from the GPS sensor. For communication secu- rity, a message is signed using the vehicle’s private key, PKVj −1, and encrypted by theith RSU’s public key.
2. When obtaining a location request from the jth vehicle, the RSU first ver- ifies the claimed position using the received signal strength (RSS), since it is possible to calculate the distance from a node using the RSS [9]. If it is valid, the RSU forwards the encrypted request to the CA using PKCA (Figure 3.3). If the claim of the vehicle is invalid, the RSU notifies the vehicle ID to adjacent RSUs.
3. The CA verifies the request using PKVj and checks if the jth vehicle is registered anywhere in the network. If it is not, it registers the vehicle loca- tion with the RSU and notifies the corresponding RSU using the vehicle’s PKVj(Figure 3.4). The CA knows the public key of all RSUs and hence can securely communicate with RSUs.
encrypt (M={Vid, position, timestamp, sign (M, PKVj–1}, PKCA)
RSUi
CA
Figure 3.3: Communication from RSU to CA
RSUi CA
encrypt (M={PKVj, Vid}, PKRSi)
Figure 3.4: Communication from CA to RSU
encrypt (M={rsu_id, Vid rsu_shared_key, expiry_time}, PKVj)
RSUi Vj
Figure 3.5: Communication from RSU to vehicle
4. After obtaining the confirmation from the CA, the RSU issues a location certificate with{rsu ID, rsu shared key, vehicle ID, expiry time}which is encrypted with the vehicle’s public key (Figure 3.5). If the CA detects a Sybil attack, it will inform the RSU concerned, which in turn will not issue a certificate to the vehicle.
5. A particular vehicle communicates with other vehicles using an rsu shared key. Each vehicle continuously checks theexpiry timeof the location certificate and sends a location certificate request before the expi- ration of the previously issued certificate. The valid location certificate acts as a key for vehicle-to-vehicle communication.
6. If a vehicle enters the range of the next RSU, it again sends a location cer- tificate request to the RSU, but it includes the position certificate from pre- vious RSU (Figure 3.6). When thekth RSU gets a request with a position certificate from theith RSU, it checks the validity of the certificate from theith RSU and acquires the public key of the corresponding vehicle. The kth RSU then issues the certificate and notifies the CA of the vehicle ID andrsu ID.Subsequently, theith RSU removes the corresponding vehicle from its storage.
encrypt (M={Vid, position, timestamp, loc cert, sign (M, PKVj–1)}, PKRSk)
Position verification RSUk
Vj
Figure 3.6: Communication from vehicle to RSU with previous location certificate Evaluation. In this scheme, the Sybil node detection happens at two lev- els. Each RSU can verify the node (vehicle) based on location information, and the CA can check whether the node registration occurred anywhere in the net- work using a unique ID. An attacker cannot send a legitimate request to the CA, since the CA can check the validity of the message using the vehicle’s public key. Each RSU requires less storage space because it stores information only of those vehicles that are within its range—an RSU erases a vehicle’s details after it moves to the next RSU. Without a location certificate, vehicles cannot com- municate with other vehicles and this prevents a Sybil node from taking part in further communication. If an RSU or the CA detects a Sybil attack, it informs nearby RSUs, which in turn can reject a vehicle request without going through the remaining process.