SACRIFICE: A Secure Road Condition Monitoring Scheme over Fog-based VANETs

11/23/2021
by   Nishttha Sharma, et al.
Yahoo! Inc.
0

With the rapid growth of Vehicular Ad-Hoc Networks (VANETs), huge amounts of road condition data are constantly being generated and sent to the cloud for processing. However, this introduces a significant load on the network bandwidth causing delay in the network and for a time-critical application like VANET such delay may have severe impact on real-time traffic management. This delay maybe reduced by offloading some computational tasks to devices as close as possible to the vehicles. Further, security and privacy of vehicles is another important concern in such applications. Thus, this paper proposes a secure road condition monitoring scheme for fog-based vehicular networks. It considers Road-Side Units (RSUs) with computational capabilities, which act as intermediate fog nodes in between vehicles and cloud to reduce delay in decision making and thereby increases scalability. Apart from fulfilling basic security features, our scheme also supports advanced features like unlinkability and untraceability. A detailed security analysis proves that the proposed scheme can handle both internal and external adversaries. We also justify the efficiency of our scheme through theoretical overhead analysis. Finally, the scheme is simulated using an integrated SUMO and NS-3 platform to show its feasibility for practical implementations while not compromising on the network performance. The results show an average 80.96% and 37.5% improvement in execution time and end-to-end delay respectively while maintaining at par results for packet delivery ratio over a state-of-the-art scheme.

READ FULL TEXT VIEW PDF

Authors

page 1

04/02/2019

Blockchain-based Lightweight Authentication Mechanism for Vehicular Fog Infrastructure

With the increasing development of advanced communication technologies, ...
02/24/2020

A New Approach for Improvement Security against DoS Attacks in Vehicular Ad-hoc Network

Vehicular Ad-Hoc Networks (VANET) are a proper subset of mobile wireless...
04/18/2020

Honesty Based Democratic Scheme to Improve Community Cooperation for IoT Based Vehicular Delay Tolerant Networks

Many Internet of things (IoT) applications have been developed and imple...
05/14/2020

A Secure Fog Based Architecture for Industrial Internet of Things and Industry 4.0

The advent of Industrial IoT (IIoT) along with Cloud computing has broug...
08/23/2021

Enhancing Security in VANETs with Efficient Sybil Attack Detection using Fog Computing

Vehicular ad hoc networks (VANETs) facilitate vehicles to broadcast beac...
08/23/2021

A statistical approach for enhancing security in VANETs with efficient rogue node detection using fog computing

Rogue nodes broadcasting false information in beacon messages may lead t...
12/22/2020

CUDA-Accelerated Application Scheduling in Vehicular Clouds Under Advanced Multichannel Operations in WAVE

This paper presents a novel Advanced Activity-Aware (AAA) scheme to opti...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

With the growth of the modern society along with the rise of smart cities, the number of connected devices and vehicles have increased exponentially. This has prompted the development of Vehicular Ad-Hoc Networks (VANETs) which not only facilitates traffic management but also makes driving safer by exploiting the inter-vehicular communication feature [Lin_08]. As a result of this, huge amounts of data are being generated every second which needs to be processed in a time-sensitive manner. This has inspired the introduction of fog computing [SRD_TII'21] in VANETs to reduce transmission delay, network bandwidth and improve overall traffic management. By extending the cloud closer to the vehicles in the network, fog has been able to reduce delay in decision making thereby improving real-time road condition monitoring, real-time driving assistance etc [CHW_IoT'19]. However, introduction of fog in VANETs may incur additional security threats apart from the inherent ones, including misuse or leakage of sensitive data which needs to be handled with utmost care.

The existing literature have focused on introducing fog as a middleware in VANETs to utilise its benefits. The works [CSM'19, Dong_IoT'20] have introduced a layer of fog devices between vehicles and cloud to provide improved network throughput, reduced latency and increased scalability. However, even after introducing fog several security and privacy issues, data quality and scheduling related challenges still exists. To address these concerns, the existing works focus on managing various security aspects in VANETs. The works [BLS_IoT'17, MEW_IoT'19, ASS-TVT'18, CHW_IoT'19] propose different methods for mutual authentication by using securely agreed session keys and/or certificateless aggregate signcryption techniques to support privacy protection. But, it has high computation-communication overheads. On the contrary, the works [Access'18, LLO_Systems'20] have proposed an identity-based mutual authentication protocol with only hash functions and Ex-OR operations which reduces overheads significantly. Recently, the works [Islam_FGCS'18, CUI_VC'18] have proposed an authentication protocol for VANETs with password and group key agreement. However, most of these works only concentrate on securing the vehicle to RSU communication. Finally, the work [WDU_TIFS'19] has proposed a secure road condition monitoring scheme with authorized reporting, privacy-preserving monitoring, and source authentication. However, their scheme is cloud-based which causes increased latency for a system like VANET. It also does not take into consideration the privacy of the vehicle user and a few other security features like resistance to various attacks such as man-in-the-middle, replay etc.

From the above discussion it is clear that the state-of-the-art works rely largely on a cloud-based platform which results in a higher end-to-end delay. Further, despite the fact that these works focus on certain security features like user anonymity, mutual authentication, non-repudiation etc. various other important security features still remain less investigated in such VANET environments. This motivates us to design an improved architecture for VANETs and propose a Secure roAd Condition monitoRIng scheme over Fog-based vehICular nEtworks (SACRIFICE) keeping in mind the application’s time-sensitive nature. The SACRIFICE also targets to incorporate security features (e.g. unlinkability to prevent attackers from tracking the movement of vehicles) in addition to basic security while running the scheme. Therefore, the contributions put forth by our work are as follows:

  • [leftmargin=*]

  • We propose SACRIFICE having the following features:

    • reduce delay in decision making by considering Fog-based VANET while maintaining basic security features like mutual authentication, user anonymity etc.

    • introduce additional security features like non-repudiation, unlinkability and untraceability.

  • A detailed security analysis proves that SACRIFICE can handle both internal and external adversaries.

  • We validate SACRIFICE both theoretically and experimentally.

    • Establish SACRIFICE to be lightweight as well as having low overheads compared to state-of-the-art works.

    • Simulation results in an integrated real-time platform using SUMO and NS-3 establish the practicality of the scheme.

The rest of the paper is structured as follows. Section II discusses the system model. SACRIFICE is presented in Section III. Section IV briefly explains the security analysis of the scheme. Section V highlights the performance of the scheme. Finally, Section VI concludes the work.

Ii System Model

This section illustrates the system model in detail where the fog-based VANET architecture inspired from [WDU_TIFS'19, CHW_IoT'19] is used as the backbone of our work. Followed by that, we explain the security guarantees and the adversarial model.

Ii-a Architecture

The architecture shown in Fig. 1 comprises of four layers and has inculcated the advantageous features of [WDU_TIFS'19, CHW_IoT'19]. Each of these layers has entities like vehicles, RSUs etc. and can communicate with its immediate upper and lower layers. The activities of these four layers are described below:

Fig. 1: Fog-based VANET Architecture

Vehicular Network Layer: It consists of vehicles equipped with various sensors (camera, temperature, etc.) [BDB_WN'19] and On-Board Units (OBUs) which has communication capabilities. The vehicles are responsible for gathering the sensory data and sending this information along with the location and time to the fog layer. In turn the vehicles receive information from fog nodes in case of a service request.

Fog Layer: It consists of Road-Side Units (RSUs) enabled with computing capabilities. These are installed at important junctions of the roads maintaining specific distance from each other depending upon the communication range to provide maximum coverage while guaranteeing persistent links with the cloud. RSUs use Dedicated Short-Range Communication to interact with the vehicles. These nodes are more robust and are responsible for minimizing the delay in decision making by extending the cloud closer to the vehicular network layer [SRD_TII'21]. An RSU receives sensory data from various vehicles within its range, processes it and sends it to the cloud for further action.

Cloud Layer: It typically consists of different kind of storage or application servers which are responsible for communicating with the fog layer in order to receive data about the entire network. The cloud may process such data and forward certain reports to the Application Authority, if required.

Application Layer: It consists of the Trusted and the Application Authorities. The Trusted Authority is responsible for device registration (e.g. vehicles) and key distribution whereas Application Authority takes necessary actions based on processed data. For example, it can ask the vehicles to take a different route in case of congestion or accidents.

Ii-B Security Guarantees and Adversarial Model

The security features, adversarial model and assumptions considered in SACRIFICE are discussed here.

Security of the Scheme

The following are the security requirements of the scheme which are taken care of:

Mutual Authentication [MEW_IoT'19, CHW_IoT'19]: The validity of all participants (i.e. vehicles, RSUs) needs to be guaranteed. This requires that none of the malicious participants should be able to impersonate some other valid participant without being detected. Thus, vehicles and RSUs should authenticate each other to prevent forgery of tokens exchanged between them.

User Anonymity and Untraceability [MEW_IoT'19, CHW_IoT'19]: It requires protecting the vehicle users’ privacy during data transmission to hide its real identity and behavioural patterns from the network. This means that an attacker intercepting the messages cannot extract a user’s real identity or track its behaviour (e.g. route, driving patterns).

Non-Repudiation [CHW_IoT'19]: The scheme guarantees that vehicles shouldn’t be able to deny its involvement in case of any dispute (e.g. sending corrupted data). It implies that in case of denial from the vehicles, the RSUs will be able to prove the role of the vehicles to any third party.

Unlinkability [LLO_Systems'20]: This feature prevents an adversary from determining whether two messages (, ) have originated from the same vehicle or not. Thus, an adversary will be unable to link messages generated by the same vehicle and thereby fail to distinguish between vehicles.

Resistance to common attacks [MEW_IoT'19]: To ensure security of the scheme, it is important to prevent attacks like man-in-the-middle and replay attacks [Ghosal_ICCSA'10]. For example, an attacker neither can pretend to be a legitimate user to cheat other participants nor can it launch an attack on the scheme to continue sending old messages to overload the network.

Adversarial Model

Entity: An entity can either be honest, semi-honest or malicious. Semi-honest entities do not deviate from the protocol specifications but may intend to obtain intermediate results/information from the nearby entities. On the contrary, malicious entities may deviate from the protocol arbitrarily.

Adversary: An adversary is a polynomial-time algorithm that can compromise any party at any point of time, subject to some upper bound [arxiv_BNR'19]. Adversaries can be broadly categorized into two types: internal and external. External adversaries do not possess authentic keying material and hence they cannot participate as valid nodes [SRD_FICN'18]. They can only eavesdrop on radio transmissions and try to access information from the data transmitted through the channels. On the contrary, internal adversaries possess authentic keying material and have more effective and powerful resources in terms of energy and communication capabilities and are more vulnerable than external adversaries [SRD_FICN'18]

. When an internal adversary captures a device in the network, it means the adversary has gained control over the tokens (not stored in a tamper-proof box) in the device. It also gains control over the messages sent/received by the device. We assume an adversary can neither interfere with the message exchanges between honest parties nor can it break cryptographic primitives like hash functions, except with a negligible probability. In this work, we consider both external and internal adversaries, however they have bounded computational and storage capabilities.

Assumptions: The following assumptions are made while setting up the proposed scheme:

  • [leftmargin=*]

  • There is a secure channel between the Application Authority and the Trusted Authority as well as between the Trusted Authority and a device that is being registered.

  • The vehicles can be malicious, RSUs are semi honest and Cloud is an untrusted entity.

  • The Application Authority and the Trusted Authority are honest and trusted entities.

Iii Proposed Scheme

A detailed overview of our proposed Secure roAd Condition monitoRIng scheme over Fog-based vehICular nEtworks (SACRIFICE) along with its algorithmic constructs is discussed in this section. The scheme generates a road condition report through a distributed process running in the participating vehicles and the roadside units of the network with the RSUs performing the intensive computations.

Working Principle: Whenever a vehicle enters the scope of an RSU , both the devices have to mutually authenticate each other. After successful authentication, sends an initial road condition report to from which it generates the final road condition report. This final report is sent to the cloud for storage and further processing. The report can be extracted by the Application Authority to make important decisions in case of an emergency. To ensure honest behaviour of the participants, a hash-based lightweight mutual authentication algorithm has been implemented. Our proposed scheme consists of five different phases which are outlined below.

SACRIFICE [leftmargin=*] System Setup: The Application Authority (AA) chooses a order additive group with generator and does the following: Generates secret key , public key and alert threshold . Sends to the Trusted Authority (TA). Chooses cryptographic hash functions . Publishes the public parameters: . Device Registration: The vehicles and the RSUs registers themselves with the system via a secure channel. [leftmargin=*] and sends their identities and to TA. TA generates keys and // Procedure 1 TA sends and to and respectively. stores and stores . Mutual Authentication: When a vehicle enters the scope of a RSU , the mutual authentication step executes as below: computes . // Procedure 2 Sends to for authentication. on receiving from , executes // Procedure 3 calls on receiving as // Procedure 2 sets , on receiving as . Report Generation: When vehicle gathers some road condition information , it does the following: Generates report . // Procedure 2 Sends to . On receiving , executes // Procedure 3 Report Processing: When Cloud Server (CS) receives final report , it does the following: [leftmargin=*] Generates // Procedure 4 For a correct report, CS sends to Application Authority (AA). AA on receiving from CS calls // Procedure 5 accepts as valid and takes necessary actions when is .

Fig. 2: Detailed description of SACRIFICE for honest participants

Phase 1: System Setup

This phase is performed during the establishment of the network. In this phase, each of the parties involved in the communication converge on the security parameters .

Phase 2: Device Registration

All the devices, i.e. both vehicles and RSUs are registered prior to entering the network.

Phase 3: Mutual Authentication

The mutual authentication between the vehicles and the RSUs is inspired from [MEW_IoT'19, LLO_Systems'20], however we have modified their schemes to eliminate interactions with the Trusted Authority (TA) during this phase. This reduces the trust dependence on any third party entity during the execution of SACRIFICE.

When a vehicle enters the scope of an RSU , the sends out the required tokens as authentication request to the . On receiving the authentication request, RSU checks its validity. For a successful validation, generates the required tokens as authentication response and sends it to . In turn, checks the validity of the authentication response. On successful validation it is said that both the vehicle and the RSU have mutually authenticated each other and can proceed further. On failure, of any of the above steps, the protocol is terminated.

Function genKey (ID):
        Calculate
        return
Procedure 1 Executed by Trusted Authority (TA)
Function authreq (, , ):
       

Generate a random variable

        Calculate and store the following tokens:
       
       
        and
       
        return
Function authack (, , , ):
        if () then
               if () then
                      Calculate
                      return
              
       
Function initialReport (, , , , ):
        Calculate tokens and
        return ()
Procedure 2 Executed by Vehicle
Function authres (, , ):
        if () then
               Calculate
               if ( ) then
                      Generate a random variable
                      Calculate the following tokens:
                     
                     
                      and .
                      Store and send to return
              
       return .
Function finalReport (, , , , ):
        if () then
               Generate a random variable .
               Calculate the tokens and
               Calculate the final report where and
              
              
              
               and
              
               return
       
Procedure 3 Executed by RSU

Phase 4: Report Generation

We adopt report generation and processing method from [WDU_TIFS'19]. But unlike [WDU_TIFS'19], here we divide the report generation task between the RSUs and vehicles instead of getting it performed by the vehicles alone. This report generation is broken down into two sub-tasks: initial report and final report generations respectively. This substantially reduces the delay of the entire scheme and improvises faster decision making by the Application Authority (AA).

In this phase a vehicle may generate an initial road condition report and send it to its nearest RSU. The RSU in turn processes the report to extract necessary information. It then generates a final road condition report which is sent to the Cloud Server (CS).

Function processCS ():
        if ( and ) then
               if () then
                      for (each equivalence class in CS) do
                             Retrieve a report from
                             if () then
                                    Insert in equivalence class
                                    if () then
                                           return
                                   return
                            
                     if (no match was found) then
                             Create a new equivalence class to insert .
                             return
                     
              else
                      Invalid Report Received from RSU
                      Return
              
       return
Procedure 4 Executed by Cloud Server (CS)
Function processAA ():
        Calculate the following tokens:
        and
       
        if () then
               return
       else
               return
       
Procedure 5 Executed by Application Authority (AA)

Phase 5: Report Processing

When the Cloud Server receives a report from an RSU, it first checks the validity of the report and stores it in an appropriate equivalence class, if the report is valid. Here, equivalence class refers to a class consisting of a set of tuples which report the same road condition for the same location within a reasonable time period [WDU_TIFS'19]. If the targeted equivalence class reaches a predefined threshold , a report from that particular class is sent to the Application Authority (AA) for further processing. The AA in turn tests the validity of the report and based on it decides whether the report is to be accepted or not. If accepted, it extracts the road condition information from the report.

Fig. 2 gives a first level view of the entire scheme whereas the tasks performed by each of the entities mentioned in this figure are elaborated through the respective procedures provided next. Here, the functions executed by Trusted Authority (TA), Vehicle , RSU , Cloud Server (CS) and Application Authority (AA) are explained in detail in Procedures 1, 2, 3, 4 and 5 respectively. Referring to the figure and the procedures, at any instance of time many such pair can communicate. Hence, our scheme fits well to a multiple vehicle-RSU setting as well.

Iv Security Analysis

This section analyzes the security of SACRIFICE.

Iv-a Mutual Authentication

In SACRIFICE, when a malicious vehicle attempts to mutually authentication itself with a legitimate RSU , the following computations are performed:

Let select a random , a forged identity , and derive the current timestamp . It then calculates the following:
    
    
    
However, to calculate it must have the value of , which is only sent to vehicles during registration. Without the value of , cannot calculate . Let us assume that selects a random value and computes,
    
and sends as the authentication request to . On receiving , calculates:
     and
    
However, on checking finds that is not equal to the received in (since . Thus, rejects the authentication request. Hence, it is proved that SACRIFICE doesn’t allow any malicious vehicle to operate in the network.

Iv-B User Anonymity and Untraceability

Iv-B1 User Anonymity

An adversary (internal or external) may try to obtain the real identity of vehicle , where the following two cases may arise:

Case 1: Let us assume, an external adversary intercepts message and obtains the value of . It also obtains the value of where and . To extract the real identity of from , needs the value of which can be calculated either using or , both of which are unknown to and also cannot be evaluated by it in polynomial time. Similarly, also cannot extract from since it requires for the same, which is unknown to it.

Case 2: Let us now consider that is an internal adversary and it takes control over the RSU . It is already known that cannot acquire the keys and . It can however gain control over the messages sent/received by . Thus, when sends the authentication request message , intercepts and computes as below:
    
Since, cannot be accessed by , the value of cannot be calculated as well. Thus, assumes a random value in place of and calculates
    
Since controls , therefore sends
     to where,
    
On receiving from , calculates
    
However the calculated value mismatches the extracted from received (since and ). Therefore, terminates the authentication process thereby preserving user anonymity.

Iv-B2 Untraceability

An adversary attempting to know the behaviour of a participant is discussed here. The messages sent from are and . Here, is dependent on the random values and as well as timestamps and . is dependent on the session key and also on timestamps and . The value of these random variables and timestamps are different for each instance of the respective messages. Therefore, every time a message is sent, its contents change due to their dependency on these dynamic variables making it difficult to understand the behaviour of .
For example, two vehicles entering the range of at different timestamps attempt mutual authentication with it. then chooses two random values, for authentication with vehicles and . Thus, the contents of the message (say ) will be different for and not only because they are sent out at different timestamps but also because of the presence of different random values in them.

Iv-C Non-Repudiation

During mutual authentication, can calculate the real identity of vehicle from message as:
     ;
and also, from as:
    
This is useful to prove the involvement of a vehicle, if the vehicle denies participation in case of any malicious behavior.

Iv-D Unlinkability

When a vehicle first enters the range of an RSU and after sometime, in the range of another RSU , an authentication request is sent by to the respective RSUs. sends and to and respectively. We consider both these authentication requests have been fulfilled successfully. According to SACRIFICE, will choose a new random value for before sending out a new authentication request. Therefore, the tokens in dependent on these values will also change with every authentication request.
For example, if then , i.e., all the tokens of the authentication request message will change. So, when an attacker intercepting both the messages and from a public channel, cannot link the messages to the same vehicle as the contents of both the messages are different.

Iv-E Resistance to common attacks

In this section, we discuss resistance against two of the most common attacks: (a) Man-in-the-Middle (b) Replay Attacks.

Iv-E1 Man-in-the-Middle Attacks

Here, we assume that an adversary (internal or external) already knows the values of and and wishes to forge a message. The following two cases may arise:

Case 1: When an external adversary tries to forge message , it chooses some random value and calculates and . However, in order to calculate it requires the value of the master key which is unknown to . Moreover, cannot be calculated in polynomial time. Hence it assumes a random value in place of and computes as below:
    
On receiving , computes and finds out that the calculated is not equal to received in (since ) and thereby terminates the authentication process. Thus, it is proved that an external adversary cannot successfully forge message .

Case 2: We consider an internal adversary has gained control over RSU and tries to forge messgae . As per SACRIFICE, we already know that cannot acquire the keys and but can control all the messages sent/received by . chooses some random value and calculates and . It then assumes a random in place of and computes as follows:
    
Since controls the messages being sent out from , therefore sends to . on receiving calculates as below:
    
finds that the calculated is not equal to received in (since ) and terminates the authentication process. Therefore, cannot successfully forge message in this case as well.

Iv-E2 Replay Attacks

When an attacker repeats or delays a message (say ), it reaches the recipient (i.e., RSU ) at timestamp . After receiving the message, will first verify the validity of the message by checking the freshness of timestamp , i.e., whether
    
if not, then the session is terminated. This makes the protocol resistant to replay attack.

Features [WDU_TIFS'19] [MEW_IoT'19] [CHW_IoT'19] [LLO_Systems'20] SACRIFICE
Mutual Authentication
User Anonymity
Untraceability
Non-Repudiation
Unlinkability
Resistance to Man-in-
the Middle Attacks
Resistance to Replay Attacks
TABLE I: A Comparative Summary of Key Features

Table I shows a comparative summary of SACRIFICE with four state-of-the art papers [WDU_TIFS'19, MEW_IoT'19, CHW_IoT'19, LLO_Systems'20] on the basis of key security features achieved by these schemes. It is evident that SACRIFICE outperforms all the other schemes considerably.

V Performance Analysis

In this section, we evaluate the performance of SACRIFICE both theoretically and experimentally.

V-a Theoretical Analysis

This section evaluates SACRIFICE in terms of its various overheads. It also analyzes the robustness of the scheme in terms of cracking probability.

V-A1 Overhead Analysis

The computation, communication and storage overheads are measured in terms of execution time, number of transmitting and receiving bytes and number of bytes stored in the memory respectively. Table II summarizes the notations used. During analysis, we consider that the size of each element in and of the elliptic curve is and respectively. We consider the size of timestamp variables (denoted as ) are . The overheads are calculated for a single round of mutual authentication, report generation etc. We also compare SACRIFICE with one competitor scheme [WDU_TIFS'19].

Time taken for Notation
Scalar multiplication
Bilinear pairing
Exponentiation
Hash operation
TABLE II: Notations used for Theoretical Analysis

Computation Overhead: Table III shows the computation overhead of SACRIFICE and the competing scheme. It is evident from the Table that the overhead for SACRIFICE is less than its competitor [WDU_TIFS'19] for the first three phases. Additionally, SACRIFICE performs better than its competitor for the last two phases as well because of the absence of expensive operations like exponentiations, bilinear pairings etc.

Phase Entity SACRIFICE Competing Scheme [WDU_TIFS'19]
Device Registration
(Vehicle)
TA/SA
Vehicle
Device
Registration (RSU)
TA/SA
RSU
Mutual
Authentication
Vehicle
RSU
Report
Generation
Vehicle
RSU
Report
Processing
CS
AA/RA
TABLE III: Comparative Analysis of Computation Overhead

Communication Overhead: Table IV provides communication and storage overhead analysis. From the Table, we observe that the communication overhead for SACRIFICE is significantly less than the overheads of the competitor. This is because SACRIFICE uses lightweight cryptographic tools like hash functions which reduces the size of the tokens exchanged during communication.

Storage Overhead: We observe from Table IV that the storage overhead for SACRIFICE is also less than its competitor. Even though the RSU stores an additional during mutual authentication, the overall storage overhead of SACRIFICE is still less than the work [WDU_TIFS'19].

Phases Entity Communication Overhead (bytes) Storage Overhead (bytes)
SACRIFICE Competing Scheme [WDU_TIFS'19] SACRIFICE
Competing
Scheme [WDU_TIFS'19]
Transmitted Received Transmitted Received
Mutual
Authentication
Vehicle 280 152 556 540 20 384
RSU 152 280 540 556 20 384
Report
Generation
Vehicle 44 992 404 772
RSU 216 44 128
CS 216 992
Report
Processing
CS 216 992 216 772
AA/RA 216 992
TABLE IV: Comparative Analysis of Communication and Storage Overheads

Summarily, we observe from the entire overhead analysis that SACRIFICE is less intensive in terms of computation, communication and storage overheads than its competitor. This is because a less intensive mathematical approach is used in our proposed scheme. However, this approach maybe vulnerable to brute-force attacks, hence we explore the probability of breaking SACRIFICE by a brute-force attack in the following subsection.

V-A2 Cracking Probability

Cracking probability is defined as the probability of cracking a token while it is being transmitted or stored by an adversary [CDB_15]. Mutual Authentication is a crucial step in SACRIFICE. If an attacker breaks this step, it can gain control over the network and its confidential information. It can also send malicious data to other participants by compromising them. The following cases describe the probability of cracking the mutual authentication algorithm when an adversary launches a brute-force attack on the network.

Case 1: When an attacker attempts to generate message , by posing as an authentic vehicle in the network the following may happen:

The tokens , can be easily calculated by with any random number and some identity . However, for it does not have the value (since the vehicle is not registered). Therefore, has to select a value for .

The length of the token = bits (Say)
Total possible combinations of the bits =
Probability that the correct combination for this case is selected =
Therefore, the Cracking Probability (%)

For example, for = 64 bits, the Cracking Probability (%) = is very low.

Case 2: When an attacker attempts to generate message , by posing as an authentic RSU in the network, the following may occur:

The tokens can be easily calculated by with any random number . However, it does not have the necessary tokens to calculate the value of . Therefore, has to select a value for and similar to Case 1, the Cracking Probability (%) = .

Thus, it is clear from the above discussion that due to the very low cracking probability, an attacker cannot infiltrate the system by a brute-force attack within the short span of time that a particular vehicle stays in the range of an RSU.

V-B Experimental Evaluation via Simulation

Here, we implement a prototype of SACRIFICE and validate its performance with a state-of-the art competitor [WDU_TIFS'19].

V-B1 Simulation Environment

We implement SACRIFICE and its competitor with the help of two simulators: SUMO and NS3. For both the schemes, the pairing and group related operations are performed using the popular PBC Library [PBC] of NS-3, where we have used Type A pairings based on the elliptic curve, . Table V summarizes the simulation parameters used in our setup. The simulation scenario in SUMO consists of a single street, 1000 m long, with 2 lanes shown in Fig. 3. The RSUs are deployed at an equal distance of 200 m from each other to provide maximum coverage. Fig. 3 shows a snapshot of the simulation in NS3 taken at a particular time, seconds. It shows vehicles in the network (represented as red circles) which interact with the RSUs (represented as blue circles). It can be seen that some vehicles are interacting with the RSUs while a few have moved out of scope of all RSUs and others are still to enter the scope of any RSU. It is also observed that an RSU is sending a final road condition report to the CS which then forwards it to the Application Authority.

Parameters Value
Area (SUMO)
Duration (NS-3) 5 minutes
Range of Entities (NS-3) 300 meters
Wireless Protocols (NS-3) 802.11p for message transmission
802.11b for beacon broadcasting
TABLE V: Simulation Parameters
(a) SUMO
(b) NS-3
Fig. 3: Simulation Snapshots
Fig. 4: Performance Comparison of various sub-tasks
Fig. 5: Average End-to-End Delay
Fig. 6: Packet Delivery Ratio

V-B2 Simulation Metrics

We measure the performance of SACRIFICE primarily by evaluating the efficiency of it in terms of time taken both for each of the sub-tasks and entities involved in the scheme. Apart from this, we measure underlying network performance in implementing the scheme. The following two metrics are used in evaluating such network performance:

End-to-end Delay:

Delay is defined as the average time taken since the moment a vehicle starts transmitting the packet until its successful delivery

[Sensors'17]. In our work, we consider the end-to-end delay as the average delay of all the packets transmitted in the network within the simulation duration.

Packet Delivery Ratio (PDR): It is measured as the ratio of the total number of packets delivered to the destination to the total number of packets sent to the destination over a period of time [VSD_iSES'18, KSD_21].

V-B3 Results and Discussion

We conduct four sets of experiments to evaluate the performance of SACRIFICE and its competitor scheme [WDU_TIFS'19]. In the simulation, vehicles start to send their own authentication messages after they receive the beacon broadcast from the nearest RSU. Such broadcasts happen every 0.3 milliseconds. An average result of 10 independent runs is taken while plotting the simulation graphs.

In the first set of experiment, we plot (Fig. 6) the execution time of the various sub-tasks. We observe that the time taken by each sub-task in SACRIFICE is substantially less compared to its state-of-the-art competitor [WDU_TIFS'19]. SACRIFICE roughly takes around on average less execution time for each of the sub-tasks compared to its competitor scheme.

In the second set of experiment, we observe (Table VI) the time taken by each entity in SACRIFICE is less compared to that of its competitor. We also observe that the the time taken is of the order of a few nanoseconds and hence is feasible for time-critical VANET applications. As explained earlier, the reason that SACRIFICE performs better in both these set of experiments is because it uses less intensive mathematical operations as compared to its competitor.

Entity SACRIFICE (ns) Competing Scheme [WDU_TIFS'19] (ns)
Vehicle 3.552 34.176
RSU 9.31 28.13
CS 0.58 9.74
AA/RA 0.566 5.45
TABLE VI: Average Time taken by each Entity

In the third set of experiment, we plot (Fig. 6) the average end-to-end delay with increasing number of vehicles in the network. From the figure, it is evident that the average delay increases when the number of vehicles increases in the network. The increase in the number of vehicles results in increased number of packet transmission resulting in increased congestion. This network congestion, in turn, increases the end-to-end delay of each packet. On an average, the delay for SACRIFICE shows 37.5% better performance as compared to the work [WDU_TIFS'19].

In the fourth set of experiment, we plot (Fig. 6) the packet delivery ratio (%) with increasing number of vehicles in the network. We observe from the figure that for both the schemes there is a negative trend in the graph, i.e. PDR decreases with the increasing number of vehicles in the network, as expected. However, the ratio is stable and stays above 97% for both the schemes. We also observe that as the number of vehicles approaches 90, the PDR for the proposed scheme starts improving compared to its competitor. Thus, when the number of vehicles in the network is large, SACRIFICE scales well or performs better.

Vi Conclusion

We propose a secure road condition monitoring scheme SACRIFICE over fog-based VANET, which is low-overhead and scalable. In this scheme, whenever a vehicle encounters a bad road condition (e.g. accident) in the network, it sends a report to the closest RSU only after performing mutual authentication between vehicle and RSU. The RSU then generates the final report and sends it to the CS for further processing. Apart from maintaining the important security like mutual authentication, user anonymity, the scheme also ensures additional security features like non-repudiation, unlinkability and untraceability. The detailed analysis of the security features shows that our scheme is robust against both external and internal adversaries. Performance of the scheme is evaluated both through theoretical overhead analysis and simulation using SUMO and NS-3 platform to show its viability for practical implementation. The overhead analysis shows our scheme’s dominance over a state-of-the-art competitor. Simulation results also corroborate the theoretical analysis in terms of execution time while achieving better network performance in terms of end-to-end delay thereby establishing its applicability in time-sensitive VANET application. In future, the scheme may be extended by including vehicle-to-everything (V2X) communications and its associated security issues. Introducing the concept of scheduling to improve the overall latency further is another open research area.

References