# A Fast VANET-Assisted Scheme for Event Data Recorders

Authors: Wei Liu; Weiqiang Shen; Lein Harn; Minjing Luo
Journal: Security and Communication Networks
 (2022)

---

## Abstract

An event data recorder (EDR) is a device installed in a vehicle to record information. Similar to a black box in an airplane, an EDR is used in the study of automobile accidents. Many schemes have been proposed that use vehicle network technology to help record EDR data, including schemes involving storing data on roadside units or nearby vehicles and schemes leveraging blockchain technology. However, these schemes do not take into account the vehicle company’s server; with the increased use of autonomous vehicles, the data related to these vehicles are always uploaded to the vehicle company’s server. In this scenario, we classify the situation into different cases, according to whether or not it is an emergency and whether the vehicle and the server are connected. For these cases, we propose a scheme whereby a vehicle uploads the EDR data to a cloud server and sends the evidence of storage to the nearby vehicle through a vehicular ad hoc network. Our scheme offers a fast response due to the use of symmetric cryptography algorithms while also considering security requirements.


---

## Body

## 1. Introduction

An event data recorder (EDR) is a device installed in automobiles to record information related to vehicle crashes or accidents [1]. It is similar to an accident data recorder and is sometimes referred to as an automotive black box. The IEEE Vehicular Technology Society has proposed standards for EDRs [2–4]. EDR data can be used for accident forensics and scientific purposes [5]. With EDR data, an accident scene can be reconstructed to determine the cause of an accident. There have been a number of trial cases worldwide involving EDRs, and drivers have been convicted, as well as exonerated, as a result of EDR evidence. Notable examples are presented in [1]. Researchers can collect EDR data for analysis, leading to improved safety, operational efficiency, and fuel consumption, as in [6]. EDR is considered to be tamper-proof, and its data can be retrieved after a crash. However, the late H. Clay Gabler III, a professor at Virginia Polytechnic Institute and State University who used black box data from cars to conduct crash research, once said that nearly 5% of black boxes cannot survive traffic accidents [7]. About 35% of black box data cannot be retrieved, and crash damage accounted for approximately 20% of all unsuccessful EDR downloads [8]. Therefore, it is important to be able to store EDR data safely.With the development of vehicle networks, many schemes have been proposed for enhancing the storage of EDR data. In [9], the authors suggested that black box technology can record data obtained by in-car sensors and send them to the next public-safety answering point and that by using vehicular communications, cars involved in an accident can send alerts and other important information about the accident to nearby vehicles and to the nearest wireless base station. In addition, there are other schemes for this purpose, including schemes storing data on roadside units (RSUs) or nearby vehicles and schemes leveraging blockchain technology.However, these schemes do not take the vehicle company’s server into account. The latest vehicle models, especially autonomous vehicles, collect data, including EDR data, and upload them to the vehicle company’s server. For example, Tesla Inc. states that it may collect certain telematics data regarding the performance, usage, operation, and condition of the vehicle to improve its vehicles and services for customers [10]. It is possible that a vehicle maker could tamper with or delete the data on the company server for its own interests.In this study, we classify the use of EDR data into four scenarios: whether or not it is an emergency and whether the vehicle and the server are connected. We propose a scheme in which the vehicle uploads the EDR data to the server and sends the evidence of stored data to the nearby vehicle in a vehicular ad hoc network (VANET). Because we use symmetric cryptography algorithms as much as possible, particularly in emergency cases, our scheme is very fast. It also takes into account security requirements.


## 2. Related Work

Many schemes for enhancing the storage of EDR data have been proposed. In [11], the vehicle reports crash data to a trusted authority (TA), such as the police, based on roadside access points. In [12], EDR data are backed up to RSUs. However, this scheme only works if there are enough RSUs. In [5], a distributed scheme was proposed that allows vehicles to periodically broadcast black box data to nodes nearby (other vehicles) as an extra backup. RSUs in [5, 12] can use a batch verification scheme [13] to simultaneously verify a number of signatures for authentication.To resolve difficult issues, blockchain technology has been widely applied in VANETs. In [14], the authors proposed a blockchain-inspired event recording system for autonomous vehicles. They designed a mechanism called “proof of event” to achieve indisputable accident forensics. In contrast with event recording systems [14] that mainly focus on forensic purposes, authors in [15] proposed a secure, real-time, and distributed data logging system with higher fault tolerance and scalability based on blockchain technology, which enables autonomous vehicles to log all the data they receive in real-time and ensures data integrity.


## 3. Statement of the Problem

### 3.1. System Model

As shown in Figure1, the vehicle uploads the EDR data to the server. The server stores the data in the form of a blockchain and gives back the evidence of data storage (similar to proof of storage, proof of retrievability, or proof of data possession). In conventional proof of storage schemes, such as [16], the author can prove that the data are stored with integrity by challenge-response interactions. However, evidence of data storage aims at generating confirmation that the server cannot deny the fact that it has stored the data. The vehicle distributes the evidence to the nearby vehicle. If the vehicle is not connected to the server, the EDR data can be stored on the nearby vehicle instead of the server. If an accident occurs, the TA updates the list of accidents, including the time and location of the accident. Any vehicle that possesses the evidence/EDR data for the accident will check the list and provide the data to the TA.Figure 1
System model of our scheme.


### 3.2. Four Scenarios

Depending on whether it is an emergency and whether the vehicle and the server are connected, we have four scenarios as follows. If there is no nearby vehicle, our scheme will simply skip the process of interacting with the nearby vehicle. Therefore, we will not classify the situation according to whether there is a nearby vehicle.


#### 3.2.1. Nonemergency Cases

(i)
Vehicle Connected to Server. The vehicle uploads the EDR data to the server and sends the evidence of data storage to the nearby vehicle.(ii)
Vehicle Not Connected to Server. The vehicle sends the nearby vehicle the evidence whose EDR data have been stored on the server. The vehicle sends the nearby vehicle new encrypted EDR data that have not been stored on the server in time. In the nonemergency cases, two nearby vehicles mutually help each other store evidence/EDR data.


#### 3.2.2. Emergency Cases

Emergency cases get special treatment. If a damaged vehicle catches fire, the driver and the EDR could be threatened by flames. In such cases, saving lives comes first. The information about the accident should be sent out first to seek help. Because in an emergency, confidentiality and privacy are less of a priority than in a nonemergency case, the use of the cryptography algorithm is reduced. The vehicle should try to distribute the EDR data as soon as possible:(i)
Vehicle Connected to Server. The vehicle sends the EDR data to the server and the nearby vehicle at the same time. If the situation permits, the vehicle sends the evidence to the nearby vehicle.(ii)
Vehicle Not Connected to Server. The vehicle directly sends EDR data without confidentiality to the nearby vehicle.In emergency cases, the crashed vehicle will not help the nearby vehicle store its evidence/EDR data.


### 3.3. Analysis of Functionality and Security Requirements

Each of the four parties in the model (the vehicle, the server, the nearby vehicle, and the TA) has its own interest. Therefore, we provide an analysis of the functionality and security requirements for each party.For the vehicle, the following are the requirements:(i)
The server that stores the EDR data should be authenticated.(ii)
The data stored on the server should have integrity.(iii)
The server should not delete the data. If it does so, this will be discovered from the evidence of data storage.(iv)
The vehicle should be anonymous to the nearby vehicle in the nonemergency cases.(v)
The vehicle’s EDR data should be confidential to the nearby vehicle in the nonemergency cases.For the server, the requirements are as follows:(i)
The vehicle connected to the server should be authenticated(ii)
EDR data are in the form of plaintext(iii)
It should be assured that EDR data come from the proper EDR(iv)
No one can forge the evidence of data storage that the server generatesFor the nearby vehicle, the requirements are as follows:(i)
Assistance for storing the evidence/EDR data can be mutual(ii)
The list of accidents publicized by the TA can be efficiently checked to make sure whether it has the related evidence/EDR data(iii)
There should be incentives or rewards for reporting the evidence/EDR data to the TA(iv)
The nearby vehicle should be anonymous to the focal vehicleFor the TA, the requirements are as follows:(i)
All parties connected to the TA should be authenticated(ii)
The TA can decrypt the encrypted EDR data(iii)
The TA can verify that the EDR data come from the proper EDR(iv)
The TA can verify that the evidence comes from the proper server(v)
The evidence/EDR data should have integrity


## 3.1. System Model

As shown in Figure1, the vehicle uploads the EDR data to the server. The server stores the data in the form of a blockchain and gives back the evidence of data storage (similar to proof of storage, proof of retrievability, or proof of data possession). In conventional proof of storage schemes, such as [16], the author can prove that the data are stored with integrity by challenge-response interactions. However, evidence of data storage aims at generating confirmation that the server cannot deny the fact that it has stored the data. The vehicle distributes the evidence to the nearby vehicle. If the vehicle is not connected to the server, the EDR data can be stored on the nearby vehicle instead of the server. If an accident occurs, the TA updates the list of accidents, including the time and location of the accident. Any vehicle that possesses the evidence/EDR data for the accident will check the list and provide the data to the TA.Figure 1
System model of our scheme.


## 3.2. Four Scenarios

Depending on whether it is an emergency and whether the vehicle and the server are connected, we have four scenarios as follows. If there is no nearby vehicle, our scheme will simply skip the process of interacting with the nearby vehicle. Therefore, we will not classify the situation according to whether there is a nearby vehicle.


### 3.2.1. Nonemergency Cases

(i)
Vehicle Connected to Server. The vehicle uploads the EDR data to the server and sends the evidence of data storage to the nearby vehicle.(ii)
Vehicle Not Connected to Server. The vehicle sends the nearby vehicle the evidence whose EDR data have been stored on the server. The vehicle sends the nearby vehicle new encrypted EDR data that have not been stored on the server in time. In the nonemergency cases, two nearby vehicles mutually help each other store evidence/EDR data.


### 3.2.2. Emergency Cases

Emergency cases get special treatment. If a damaged vehicle catches fire, the driver and the EDR could be threatened by flames. In such cases, saving lives comes first. The information about the accident should be sent out first to seek help. Because in an emergency, confidentiality and privacy are less of a priority than in a nonemergency case, the use of the cryptography algorithm is reduced. The vehicle should try to distribute the EDR data as soon as possible:(i)
Vehicle Connected to Server. The vehicle sends the EDR data to the server and the nearby vehicle at the same time. If the situation permits, the vehicle sends the evidence to the nearby vehicle.(ii)
Vehicle Not Connected to Server. The vehicle directly sends EDR data without confidentiality to the nearby vehicle.In emergency cases, the crashed vehicle will not help the nearby vehicle store its evidence/EDR data.


## 3.2.1. Nonemergency Cases

(i)
Vehicle Connected to Server. The vehicle uploads the EDR data to the server and sends the evidence of data storage to the nearby vehicle.(ii)
Vehicle Not Connected to Server. The vehicle sends the nearby vehicle the evidence whose EDR data have been stored on the server. The vehicle sends the nearby vehicle new encrypted EDR data that have not been stored on the server in time. In the nonemergency cases, two nearby vehicles mutually help each other store evidence/EDR data.


## 3.2.2. Emergency Cases

Emergency cases get special treatment. If a damaged vehicle catches fire, the driver and the EDR could be threatened by flames. In such cases, saving lives comes first. The information about the accident should be sent out first to seek help. Because in an emergency, confidentiality and privacy are less of a priority than in a nonemergency case, the use of the cryptography algorithm is reduced. The vehicle should try to distribute the EDR data as soon as possible:(i)
Vehicle Connected to Server. The vehicle sends the EDR data to the server and the nearby vehicle at the same time. If the situation permits, the vehicle sends the evidence to the nearby vehicle.(ii)
Vehicle Not Connected to Server. The vehicle directly sends EDR data without confidentiality to the nearby vehicle.In emergency cases, the crashed vehicle will not help the nearby vehicle store its evidence/EDR data.


## 3.3. Analysis of Functionality and Security Requirements

Each of the four parties in the model (the vehicle, the server, the nearby vehicle, and the TA) has its own interest. Therefore, we provide an analysis of the functionality and security requirements for each party.For the vehicle, the following are the requirements:(i)
The server that stores the EDR data should be authenticated.(ii)
The data stored on the server should have integrity.(iii)
The server should not delete the data. If it does so, this will be discovered from the evidence of data storage.(iv)
The vehicle should be anonymous to the nearby vehicle in the nonemergency cases.(v)
The vehicle’s EDR data should be confidential to the nearby vehicle in the nonemergency cases.For the server, the requirements are as follows:(i)
The vehicle connected to the server should be authenticated(ii)
EDR data are in the form of plaintext(iii)
It should be assured that EDR data come from the proper EDR(iv)
No one can forge the evidence of data storage that the server generatesFor the nearby vehicle, the requirements are as follows:(i)
Assistance for storing the evidence/EDR data can be mutual(ii)
The list of accidents publicized by the TA can be efficiently checked to make sure whether it has the related evidence/EDR data(iii)
There should be incentives or rewards for reporting the evidence/EDR data to the TA(iv)
The nearby vehicle should be anonymous to the focal vehicleFor the TA, the requirements are as follows:(i)
All parties connected to the TA should be authenticated(ii)
The TA can decrypt the encrypted EDR data(iii)
The TA can verify that the EDR data come from the proper EDR(iv)
The TA can verify that the evidence comes from the proper server(v)
The evidence/EDR data should have integrity


## 4. Our Scheme

### 4.1. Setup

The TA, the server, and vehicles (WLOG, including a vehicle V and its nearby vehicle V′) form a public key infrastructure (PKI). The TA is the certification authority. When we say that two parties communicate in a secure channel, it means that these two parties perform in the PKI manner. We use the notationsAS_ENCXm/AS_DECXm, S_ENCXm/S_DECXm, SIGXskm/VERXpkm, MACXm, and Hm to, respectively, denote asymmetric encryption algorithm, symmetric encryption algorithm, signature algorithm, message authentication code (MAC) algorithm, and hash algorithm for m using the key x. The server has a pair of keys (server_sign_pk, server_sign_sk) for signing. The TA generates random keys v_s_enc and v_mac and preloads them in the V’s EDR. The EDR is considered to be tamper-proof and these two keys cannot be retrieved from the EDR. The EDR’s data are m1,t1,l1,MACv_macm1||t1||l1, …, mk−1,tk−1,lk−1,MACv_macmk−1||tk−1||lk−1, mk,tk,lk,MACv_macmk||tk||lk, … where mk is the information related to the conditions of the vehicle such as its speed, brake use, and engine status, and tk, lk are the approximate time and location, respectively, when and where these data are generated. As shown in Figure 1, m1,t1,l1,MACv_macm1||t1||l1, …, mk−1,tk−1,lk−1,MACv_macmk−1||tk−1||lk−1 have been stored on the server in the form of blockchain b1, ..., bk−1, and bk is the next block. bk consists of hashk,mk,tk,lk,MACv_macmk||tk||lk, If k=1, hash1=0; If k>1, hashk=Hbk−1.


### 4.2. Schemes for Four Scenarios

#### 4.2.1. Nonemergency Cases

For the vehicle connected to server, the steps are shown in Figure2.Step 1. A secure channel is set up between V and the server.Step 2. V uploads mk,tk,lk,MACv_macmk||tk||lk to the server.Step 3. After receiving the data from V, the server generates the block bk as hashk,mk,tk,lk,MACv_macmk||tk||lk.Step 4. The server then generates the evidence evk. It computes hashk+1=Hbk, evk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk with the secret key server_sign_sk and sends evk back to V.Step 5. After receiving the evidence evk, V computes hashk+1=Hbk and verifies evk, including tk, lk, and the signature SIGNserver_sign_skhashk+1||tk||lk with the public key server_sign_pk. If the verification goes well, V goes ahead with the following steps; otherwise, V aborts the operation and synchronizes the blockchain with the server.Step 6. V connects to a nearby vehicle, V’. Two connected vehicles should help each other mutually store the evidence/EDR data.Step 7. V sends evk to V’.Step 8. After receiving the evidence evk, V′ verifies the signature SIGNserver_sign_skhashk+1||tk||lk with the public key server_sign_pk. If the verification goes well, V′ stores evk.Figure 2
Process in the nonemergency case of a vehicle connected to the server.Remarks 1.
If successive new blocks on the server have similar time and location data, the server can only provide evidence of the last block. V always stores the last evidence.
Vehicle not connected to server: the steps are shown in Figure3 as follows:Step 1. V connects to a nearby vehicle, V’. Two connected vehicles should help each other mutually store the evidence/EDR data.Step 2. V computes ck=S_ENCv_s_encmk with the key v_s_enc, MACv_macck||tk||lk then sends ck,tk,lk,MACv_macck||tk||lk to V’.Figure 3
Process in the nonemergency case of vehicle not connected to server.


#### 4.2.2. Emergency Cases

Unlike in a nonemergency case, two connected vehicles store evidence/EDR data mutually, and a crashed vehicle will not help a normal vehicle to store the evidence/EDR data.For the vehicle connected to server, the steps are as follows:Step 1. Simultaneously execute “Step 1–Step 4 in nonemergency vehicle-server connected case” and “Step 1 and Step 2 in noemergency vehicle-server connected case with the cyphertext ck replaced by plaintext mk.”Step 2. If the time, energy, and other conditions permit, execute “Step 5–Step 7 in nonemergency vehicle-server connected case.”For the vehicle not connected to server, the steps are as follows:Step 1. V connects to a nearby vehicle, V’.Step 2. V computes MACv_macmk||tk||lk, then sends mk,tk,lk,MACv_macmk||tk||lk to V’.How to Reveal EDR Data? The TA updates a list of accidents with the information about the approximate time and location, but without the identity of V (suppose V is involved in an accident). V′ communicates with the TA over a secure channel, then checks the list of accidents. If there is information that matches the data on V″s storage, V′ will upload that evidence/EDR data (V′ holds the evidence/EDR data for a period of time). The TA verifies the information about the time, location, and the MACv_mac⋅ using the key v_mac and decrypts S_ENCv_s_enc⋅ using the key v_s_enc. The TA will reward V′ for its proper evidence/EDR data. Then the TA executes the following steps:Step 1. TA checks V’s EDR first. If the EDR is damaged, go to Step 2.Step 2. TA checks the blockchain data on the server. If the last block’s time is later than the accident, go to Step 3; otherwise, go to Step 4.Step 3. TA verifies the MAC in the blocks corresponding to the accident using v_mac. If the verification is done, TA can use the block data for accident forensics; otherwise, go to Step 4.Step 4. TA checks evidence/EDR data from V′ using keys server_sign_pk/ v_mac and v_s_enc. The evidence will inform whether the server deleted blockchain data, and the decrypted EDR data can be used directly for accident forensics. If no, V′ uploads the evidence/EDR data and abort the operation.After these steps, if the operation is not aborted, the TA can obtain the proper EDR data with integrity and authentication or the TA can detect if the server modifies or deletes its data. Security is discussed in the next section.


## 4.1. Setup

The TA, the server, and vehicles (WLOG, including a vehicle V and its nearby vehicle V′) form a public key infrastructure (PKI). The TA is the certification authority. When we say that two parties communicate in a secure channel, it means that these two parties perform in the PKI manner. We use the notationsAS_ENCXm/AS_DECXm, S_ENCXm/S_DECXm, SIGXskm/VERXpkm, MACXm, and Hm to, respectively, denote asymmetric encryption algorithm, symmetric encryption algorithm, signature algorithm, message authentication code (MAC) algorithm, and hash algorithm for m using the key x. The server has a pair of keys (server_sign_pk, server_sign_sk) for signing. The TA generates random keys v_s_enc and v_mac and preloads them in the V’s EDR. The EDR is considered to be tamper-proof and these two keys cannot be retrieved from the EDR. The EDR’s data are m1,t1,l1,MACv_macm1||t1||l1, …, mk−1,tk−1,lk−1,MACv_macmk−1||tk−1||lk−1, mk,tk,lk,MACv_macmk||tk||lk, … where mk is the information related to the conditions of the vehicle such as its speed, brake use, and engine status, and tk, lk are the approximate time and location, respectively, when and where these data are generated. As shown in Figure 1, m1,t1,l1,MACv_macm1||t1||l1, …, mk−1,tk−1,lk−1,MACv_macmk−1||tk−1||lk−1 have been stored on the server in the form of blockchain b1, ..., bk−1, and bk is the next block. bk consists of hashk,mk,tk,lk,MACv_macmk||tk||lk, If k=1, hash1=0; If k>1, hashk=Hbk−1.


## 4.2. Schemes for Four Scenarios

### 4.2.1. Nonemergency Cases

For the vehicle connected to server, the steps are shown in Figure2.Step 1. A secure channel is set up between V and the server.Step 2. V uploads mk,tk,lk,MACv_macmk||tk||lk to the server.Step 3. After receiving the data from V, the server generates the block bk as hashk,mk,tk,lk,MACv_macmk||tk||lk.Step 4. The server then generates the evidence evk. It computes hashk+1=Hbk, evk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk with the secret key server_sign_sk and sends evk back to V.Step 5. After receiving the evidence evk, V computes hashk+1=Hbk and verifies evk, including tk, lk, and the signature SIGNserver_sign_skhashk+1||tk||lk with the public key server_sign_pk. If the verification goes well, V goes ahead with the following steps; otherwise, V aborts the operation and synchronizes the blockchain with the server.Step 6. V connects to a nearby vehicle, V’. Two connected vehicles should help each other mutually store the evidence/EDR data.Step 7. V sends evk to V’.Step 8. After receiving the evidence evk, V′ verifies the signature SIGNserver_sign_skhashk+1||tk||lk with the public key server_sign_pk. If the verification goes well, V′ stores evk.Figure 2
Process in the nonemergency case of a vehicle connected to the server.Remarks 1.
If successive new blocks on the server have similar time and location data, the server can only provide evidence of the last block. V always stores the last evidence.
Vehicle not connected to server: the steps are shown in Figure3 as follows:Step 1. V connects to a nearby vehicle, V’. Two connected vehicles should help each other mutually store the evidence/EDR data.Step 2. V computes ck=S_ENCv_s_encmk with the key v_s_enc, MACv_macck||tk||lk then sends ck,tk,lk,MACv_macck||tk||lk to V’.Figure 3
Process in the nonemergency case of vehicle not connected to server.


### 4.2.2. Emergency Cases

Unlike in a nonemergency case, two connected vehicles store evidence/EDR data mutually, and a crashed vehicle will not help a normal vehicle to store the evidence/EDR data.For the vehicle connected to server, the steps are as follows:Step 1. Simultaneously execute “Step 1–Step 4 in nonemergency vehicle-server connected case” and “Step 1 and Step 2 in noemergency vehicle-server connected case with the cyphertext ck replaced by plaintext mk.”Step 2. If the time, energy, and other conditions permit, execute “Step 5–Step 7 in nonemergency vehicle-server connected case.”For the vehicle not connected to server, the steps are as follows:Step 1. V connects to a nearby vehicle, V’.Step 2. V computes MACv_macmk||tk||lk, then sends mk,tk,lk,MACv_macmk||tk||lk to V’.How to Reveal EDR Data? The TA updates a list of accidents with the information about the approximate time and location, but without the identity of V (suppose V is involved in an accident). V′ communicates with the TA over a secure channel, then checks the list of accidents. If there is information that matches the data on V″s storage, V′ will upload that evidence/EDR data (V′ holds the evidence/EDR data for a period of time). The TA verifies the information about the time, location, and the MACv_mac⋅ using the key v_mac and decrypts S_ENCv_s_enc⋅ using the key v_s_enc. The TA will reward V′ for its proper evidence/EDR data. Then the TA executes the following steps:Step 1. TA checks V’s EDR first. If the EDR is damaged, go to Step 2.Step 2. TA checks the blockchain data on the server. If the last block’s time is later than the accident, go to Step 3; otherwise, go to Step 4.Step 3. TA verifies the MAC in the blocks corresponding to the accident using v_mac. If the verification is done, TA can use the block data for accident forensics; otherwise, go to Step 4.Step 4. TA checks evidence/EDR data from V′ using keys server_sign_pk/ v_mac and v_s_enc. The evidence will inform whether the server deleted blockchain data, and the decrypted EDR data can be used directly for accident forensics. If no, V′ uploads the evidence/EDR data and abort the operation.After these steps, if the operation is not aborted, the TA can obtain the proper EDR data with integrity and authentication or the TA can detect if the server modifies or deletes its data. Security is discussed in the next section.


## 4.2.1. Nonemergency Cases

For the vehicle connected to server, the steps are shown in Figure2.Step 1. A secure channel is set up between V and the server.Step 2. V uploads mk,tk,lk,MACv_macmk||tk||lk to the server.Step 3. After receiving the data from V, the server generates the block bk as hashk,mk,tk,lk,MACv_macmk||tk||lk.Step 4. The server then generates the evidence evk. It computes hashk+1=Hbk, evk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk with the secret key server_sign_sk and sends evk back to V.Step 5. After receiving the evidence evk, V computes hashk+1=Hbk and verifies evk, including tk, lk, and the signature SIGNserver_sign_skhashk+1||tk||lk with the public key server_sign_pk. If the verification goes well, V goes ahead with the following steps; otherwise, V aborts the operation and synchronizes the blockchain with the server.Step 6. V connects to a nearby vehicle, V’. Two connected vehicles should help each other mutually store the evidence/EDR data.Step 7. V sends evk to V’.Step 8. After receiving the evidence evk, V′ verifies the signature SIGNserver_sign_skhashk+1||tk||lk with the public key server_sign_pk. If the verification goes well, V′ stores evk.Figure 2
Process in the nonemergency case of a vehicle connected to the server.Remarks 1.
If successive new blocks on the server have similar time and location data, the server can only provide evidence of the last block. V always stores the last evidence.
Vehicle not connected to server: the steps are shown in Figure3 as follows:Step 1. V connects to a nearby vehicle, V’. Two connected vehicles should help each other mutually store the evidence/EDR data.Step 2. V computes ck=S_ENCv_s_encmk with the key v_s_enc, MACv_macck||tk||lk then sends ck,tk,lk,MACv_macck||tk||lk to V’.Figure 3
Process in the nonemergency case of vehicle not connected to server.


## 4.2.2. Emergency Cases

Unlike in a nonemergency case, two connected vehicles store evidence/EDR data mutually, and a crashed vehicle will not help a normal vehicle to store the evidence/EDR data.For the vehicle connected to server, the steps are as follows:Step 1. Simultaneously execute “Step 1–Step 4 in nonemergency vehicle-server connected case” and “Step 1 and Step 2 in noemergency vehicle-server connected case with the cyphertext ck replaced by plaintext mk.”Step 2. If the time, energy, and other conditions permit, execute “Step 5–Step 7 in nonemergency vehicle-server connected case.”For the vehicle not connected to server, the steps are as follows:Step 1. V connects to a nearby vehicle, V’.Step 2. V computes MACv_macmk||tk||lk, then sends mk,tk,lk,MACv_macmk||tk||lk to V’.How to Reveal EDR Data? The TA updates a list of accidents with the information about the approximate time and location, but without the identity of V (suppose V is involved in an accident). V′ communicates with the TA over a secure channel, then checks the list of accidents. If there is information that matches the data on V″s storage, V′ will upload that evidence/EDR data (V′ holds the evidence/EDR data for a period of time). The TA verifies the information about the time, location, and the MACv_mac⋅ using the key v_mac and decrypts S_ENCv_s_enc⋅ using the key v_s_enc. The TA will reward V′ for its proper evidence/EDR data. Then the TA executes the following steps:Step 1. TA checks V’s EDR first. If the EDR is damaged, go to Step 2.Step 2. TA checks the blockchain data on the server. If the last block’s time is later than the accident, go to Step 3; otherwise, go to Step 4.Step 3. TA verifies the MAC in the blocks corresponding to the accident using v_mac. If the verification is done, TA can use the block data for accident forensics; otherwise, go to Step 4.Step 4. TA checks evidence/EDR data from V′ using keys server_sign_pk/ v_mac and v_s_enc. The evidence will inform whether the server deleted blockchain data, and the decrypted EDR data can be used directly for accident forensics. If no, V′ uploads the evidence/EDR data and abort the operation.After these steps, if the operation is not aborted, the TA can obtain the proper EDR data with integrity and authentication or the TA can detect if the server modifies or deletes its data. Security is discussed in the next section.


## 5. Functionality and Security Analysis

In this section, we analyze the functionality and security of our scheme item by item according to the requirements in Section3.3.


### 5.1. For the Vehicle

The communication with the server should be authenticated and secure against the malicious PPT (Probabilistic Polynomial Time) adversary.Because the vehicle and the server communicate in a PKI manner, they will verify each other’s identity by checking the signature signed with a certified public key in PKI and set up an authenticated session key by the key agreement algorithm. This process guarantees the confidentiality, integrity, and authentication of the transmission against the malicious PPT adversary.The data stored on the server should have integrity.Every block of the data stored on the serverbk includes a data segment MACv_macmk||tk||lk. The key v_mac is only in possession of the tamper-proof EDR and the trusted party TA so that the server cannot generate any proper MACv_macmk||tk||lk. Meanwhile, bk is stored in the form of blockchain and the server feeds back the evidence of storage evk containing hashk+1, the hash of block bk. Once the server modifies any bit of the data, the vehicle or TA will find out that by comparing the segments, hashk+1 form the server and evk.The server should not delete the data. If it does so, this will be discovered from the evidence of data storage.Similar to the analysis above, the EDR data are stored on the server in the form of blockchain. In addition, the vehicle keeps the latest evidence of data storageevk and distributes it to the nearby vehicle. According to the property of blockchain, any modification, including deleting any block on the blockchain, will change the latest block bk and its evidence of data storage evk. It will be found out by the vehicle or the TA that obtains evk.The vehicle should be anonymous to the nearby vehicle in the nonemergency cases.This anonymity feature is maintained in two stages. The first is when the vehicle is transmitting the evidence/EDR data to the nearby vehicle in the nonemergency cases. The evidence/EDR data consist ofhashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk/ck,tk,lk,MACv_macck||tk||lk, which do not leak any information about the identity. The second stage is when the nearby vehicle is checking the list of accidents publicized by the TA. Every item in the list includes the time and location of the accident without the information about identity so that the nearby vehicle cannot obtain any information about the identity from the list.The vehicle’s EDR data should be confidential to the nearby vehicle in the nonemergency cases.The EDR data sent to the nearby vehicle consist ofck,tk,lk,MACv_macck||tk||lk, where ck=S_ENCv_s_encmk. mk is encrypted by a symmetric encryption algorithm with key v_s_enc, which is held by the EDR and TA. Therefore, the nearby vehicle cannot decrypt ck in order to obtain any information about mk.


### 5.2. For the Server

The communication with the vehicle/TA should be authenticated and secure against the malicious PPT adversary.This requirement is satisfied due to the same reason for the first requirement for the vehicle: that is, the server and the vehicle/TA communicate in a PKI manner.EDR data are in the form of plaintext.EDR data uploaded by the vehicle consist ofmk,tk,lk,MACv_macmk||tk||lk, where mk is in the form of plaintext that can be used by the vehicle manufacturer to improve its vehicles and services for customers.It can be assured that EDR data come from the proper EDR with the TA’s help.EDR data uploaded by the vehicle consist ofmk,tk,lk,MACv_macmk||tk||lk, where the data segment MACv_macmk||tk||lk is the result of a MAC algorithm. The key v_mac is only in possession of the tamper-proof EDR and the trusted party TA. If the server has doubts about the EDR data, it can ask for the TA’s help to confirm whether the EDR data came from the proper EDR.No one can forge the evidence of data storage that the server generates.Every evidenceevk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk includes the server’s signature SIGNserver_sign_skhashk+1||tk||lk. The private key server_sign_sk is only in possession of the server. Therefore, no one can forge the evidence of data storage.


### 5.3. For the Nearby Vehicle

Assistance for storing the evidence/EDR data can be mutual in the nonemergency cases.As stated in our scheme, in the nonemergency cases, when the server and the vehicle are connected (Step 6) and when the server and the vehicle are not connected (Step 1), V and V′ should help each other to store the evidence/EDR data.The list of accidents publicized by the TA can be checked to make sure that the nearby vehicle has the related evidence/EDR data.The list publicized by the TA will not be long. According to [17], there were 122,635 recorded accidents in the UK in 2018, which works out to 336 per day. This means that V′ can efficiently check the list of accidents using the information about time and location.There should be incentives or rewards for reporting the evidence/EDR data to the TA.We mention that the TA will reward V′ for its proper evidence/EDR data in the “How to Reveal EDR Data” section.The nearby vehicle should be anonymous to the vehicle.As the role of the nearby vehicle, V′ does not send any information about identity to V. Because two connected vehicles V and V′ should help each other mutually store the evidence/EDR data, the roles can be reversed. As the role of V, the feature of anonymity is maintained, as mentioned in the fourth requirement for the vehicle.The communication with the TA should be authenticated and secure against the malicious PPT adversary.This requirement is satisfied due to the same reason for the first requirement for the vehicle: that is, the nearby vehicle and the TA communicate in a PKI manner.


### 5.4. For the TA

The communication with the nearby vehicle/server should be authenticated and secure a malicious PPT adversary again.This requirement is satisfied due to the same reason for the first requirement for the vehicle: that is, the TA and the nearby vehicle/server communicate in a PKI manner.The TA can decrypt the encryption of the EDR data.In the nonemergency cases, the EDR data consist ofck,tk,lk,MACv_macck||tk||lk, where ck=S_ENCv_s_encmk. The TA can use the key v_s_enc to decrypt ck to obtain mk. In emergency cases, the EDR data consist of mk,tk,lk,MACv_macmk||tk||lk, where mk is in the form of plaintext directly.The TA can verify that the EDR data come from the proper EDR.The EDR data consist ofck,tk,lk,MACv_macck||tk||lk or mk,tk,lk,MACv_macmk||tk||lk, where the data segments MACv_macck||tk||lk and MACv_macmk||tk||lk are the result of a MAC algorithm. The key v_mac is only in possession of the tamper-proof EDR and the TA. Thus, the TA can confirm that the EDR data come from the proper EDR.The TA can verify that the evidence comes from the proper server:The evidenceevk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk includes the server’s signature SIGNserver_sign_skhashk+1||tk||lk. The TA can verify the signature with the server’s public key server_sign_pk to make sure that evk comes from the proper server.The evidence/EDR data should have integrity.As the analysis in the above two requirements shows, the signature/MAC algorithm can also guarantee the integrity of evidence/EDR.The server should not delete the data. If it does so, this will be discovered from the evidence of data storage.This requirement is satisfied due to the same reason for the third requirement for the vehicle.Remarks 2.
Why do V and V′ not verify each other’s identity for authentication? In [5, 12], the authors used pseudoidentity with the TA’s signature. This is because the EDR data are stored on the RSUs or other vehicles by broadcast. Verifying the identity can prevent spam EDR data. In addition, the TA can find the EDR data related to an accident through the pseudoidentity. However, in our scheme, the EDR data are mainly stored on the server. V′ stores evidence and some encrypted EDR data. V and V′ always help each other mutually in the nonemergency cases, so the storage for the other’s evidence/EDR data is, at most, as large as the local data. Moreover, the information about the time and location of the accident is enough for V′ to check whether it should upload the evidence/EDR data to the TA. Therefore, it is not necessary for V and V′ to authenticate to one other. Despite this, our scheme can work well with any pseudonym scheme for authentication in vehicle networks. This combination can not only guarantee anonymity but also provides more features.


## 5.1. For the Vehicle

The communication with the server should be authenticated and secure against the malicious PPT (Probabilistic Polynomial Time) adversary.Because the vehicle and the server communicate in a PKI manner, they will verify each other’s identity by checking the signature signed with a certified public key in PKI and set up an authenticated session key by the key agreement algorithm. This process guarantees the confidentiality, integrity, and authentication of the transmission against the malicious PPT adversary.The data stored on the server should have integrity.Every block of the data stored on the serverbk includes a data segment MACv_macmk||tk||lk. The key v_mac is only in possession of the tamper-proof EDR and the trusted party TA so that the server cannot generate any proper MACv_macmk||tk||lk. Meanwhile, bk is stored in the form of blockchain and the server feeds back the evidence of storage evk containing hashk+1, the hash of block bk. Once the server modifies any bit of the data, the vehicle or TA will find out that by comparing the segments, hashk+1 form the server and evk.The server should not delete the data. If it does so, this will be discovered from the evidence of data storage.Similar to the analysis above, the EDR data are stored on the server in the form of blockchain. In addition, the vehicle keeps the latest evidence of data storageevk and distributes it to the nearby vehicle. According to the property of blockchain, any modification, including deleting any block on the blockchain, will change the latest block bk and its evidence of data storage evk. It will be found out by the vehicle or the TA that obtains evk.The vehicle should be anonymous to the nearby vehicle in the nonemergency cases.This anonymity feature is maintained in two stages. The first is when the vehicle is transmitting the evidence/EDR data to the nearby vehicle in the nonemergency cases. The evidence/EDR data consist ofhashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk/ck,tk,lk,MACv_macck||tk||lk, which do not leak any information about the identity. The second stage is when the nearby vehicle is checking the list of accidents publicized by the TA. Every item in the list includes the time and location of the accident without the information about identity so that the nearby vehicle cannot obtain any information about the identity from the list.The vehicle’s EDR data should be confidential to the nearby vehicle in the nonemergency cases.The EDR data sent to the nearby vehicle consist ofck,tk,lk,MACv_macck||tk||lk, where ck=S_ENCv_s_encmk. mk is encrypted by a symmetric encryption algorithm with key v_s_enc, which is held by the EDR and TA. Therefore, the nearby vehicle cannot decrypt ck in order to obtain any information about mk.


## 5.2. For the Server

The communication with the vehicle/TA should be authenticated and secure against the malicious PPT adversary.This requirement is satisfied due to the same reason for the first requirement for the vehicle: that is, the server and the vehicle/TA communicate in a PKI manner.EDR data are in the form of plaintext.EDR data uploaded by the vehicle consist ofmk,tk,lk,MACv_macmk||tk||lk, where mk is in the form of plaintext that can be used by the vehicle manufacturer to improve its vehicles and services for customers.It can be assured that EDR data come from the proper EDR with the TA’s help.EDR data uploaded by the vehicle consist ofmk,tk,lk,MACv_macmk||tk||lk, where the data segment MACv_macmk||tk||lk is the result of a MAC algorithm. The key v_mac is only in possession of the tamper-proof EDR and the trusted party TA. If the server has doubts about the EDR data, it can ask for the TA’s help to confirm whether the EDR data came from the proper EDR.No one can forge the evidence of data storage that the server generates.Every evidenceevk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk includes the server’s signature SIGNserver_sign_skhashk+1||tk||lk. The private key server_sign_sk is only in possession of the server. Therefore, no one can forge the evidence of data storage.


## 5.3. For the Nearby Vehicle

Assistance for storing the evidence/EDR data can be mutual in the nonemergency cases.As stated in our scheme, in the nonemergency cases, when the server and the vehicle are connected (Step 6) and when the server and the vehicle are not connected (Step 1), V and V′ should help each other to store the evidence/EDR data.The list of accidents publicized by the TA can be checked to make sure that the nearby vehicle has the related evidence/EDR data.The list publicized by the TA will not be long. According to [17], there were 122,635 recorded accidents in the UK in 2018, which works out to 336 per day. This means that V′ can efficiently check the list of accidents using the information about time and location.There should be incentives or rewards for reporting the evidence/EDR data to the TA.We mention that the TA will reward V′ for its proper evidence/EDR data in the “How to Reveal EDR Data” section.The nearby vehicle should be anonymous to the vehicle.As the role of the nearby vehicle, V′ does not send any information about identity to V. Because two connected vehicles V and V′ should help each other mutually store the evidence/EDR data, the roles can be reversed. As the role of V, the feature of anonymity is maintained, as mentioned in the fourth requirement for the vehicle.The communication with the TA should be authenticated and secure against the malicious PPT adversary.This requirement is satisfied due to the same reason for the first requirement for the vehicle: that is, the nearby vehicle and the TA communicate in a PKI manner.


## 5.4. For the TA

The communication with the nearby vehicle/server should be authenticated and secure a malicious PPT adversary again.This requirement is satisfied due to the same reason for the first requirement for the vehicle: that is, the TA and the nearby vehicle/server communicate in a PKI manner.The TA can decrypt the encryption of the EDR data.In the nonemergency cases, the EDR data consist ofck,tk,lk,MACv_macck||tk||lk, where ck=S_ENCv_s_encmk. The TA can use the key v_s_enc to decrypt ck to obtain mk. In emergency cases, the EDR data consist of mk,tk,lk,MACv_macmk||tk||lk, where mk is in the form of plaintext directly.The TA can verify that the EDR data come from the proper EDR.The EDR data consist ofck,tk,lk,MACv_macck||tk||lk or mk,tk,lk,MACv_macmk||tk||lk, where the data segments MACv_macck||tk||lk and MACv_macmk||tk||lk are the result of a MAC algorithm. The key v_mac is only in possession of the tamper-proof EDR and the TA. Thus, the TA can confirm that the EDR data come from the proper EDR.The TA can verify that the evidence comes from the proper server:The evidenceevk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk includes the server’s signature SIGNserver_sign_skhashk+1||tk||lk. The TA can verify the signature with the server’s public key server_sign_pk to make sure that evk comes from the proper server.The evidence/EDR data should have integrity.As the analysis in the above two requirements shows, the signature/MAC algorithm can also guarantee the integrity of evidence/EDR.The server should not delete the data. If it does so, this will be discovered from the evidence of data storage.This requirement is satisfied due to the same reason for the third requirement for the vehicle.Remarks 2.
Why do V and V′ not verify each other’s identity for authentication? In [5, 12], the authors used pseudoidentity with the TA’s signature. This is because the EDR data are stored on the RSUs or other vehicles by broadcast. Verifying the identity can prevent spam EDR data. In addition, the TA can find the EDR data related to an accident through the pseudoidentity. However, in our scheme, the EDR data are mainly stored on the server. V′ stores evidence and some encrypted EDR data. V and V′ always help each other mutually in the nonemergency cases, so the storage for the other’s evidence/EDR data is, at most, as large as the local data. Moreover, the information about the time and location of the accident is enough for V′ to check whether it should upload the evidence/EDR data to the TA. Therefore, it is not necessary for V and V′ to authenticate to one other. Despite this, our scheme can work well with any pseudonym scheme for authentication in vehicle networks. This combination can not only guarantee anonymity but also provides more features.


## 6. Performance Analysis

In this section, we analyze the performance of our scheme and compare it with [5, 12]. Our scheme applies symmetric cryptography algorithms as much as possible. Symmetric cryptography algorithms are usually 1000 times faster than asymmetric cryptography algorithms [18]. The results of the experiment show that our scheme has little computational overhead.


### 6.1. Experiment Model

We focused on the cost of computation. There is a similar setup at the beginning of our scheme and [5, 12]. In our scheme, the vehicle sets up a secure channel with the server in a PKI manner. This secure channel will be kept open for much of the EDR data. In [5, 12], the vehicle also starts with a secure channel in a PKI manner to obtain the system master key s and a pool of pseudoidentities. Therefore, we limited the computational cost by having these operations at the beginning. We wanted to measure the computation from a chunk of EDR data that is generated to this chunk of EDR data, which is distributed to the proper destination.In our scheme, a chunk of EDR data goes through the following processes in four cases:(i)
In the nonemergency and connected to the server case, the vehicle generates a chunk of EDR datamk,tk,lk,MACv_macmk||tk||lk by computing a MACv_mac⋅ and then transmits it to the server in the secure channel by performing a symmetric encryption S_ENCPKI_v_s_enc⋅, where the key PKI_v_s_enc is from the key agreement algorithm in the PKI manner. When the server receives this encrypted chunk of EDR data, it decrypts it by computing a S_DECPKI_v_s_enc⋅, then generates the evidence evk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk by computing a H⋅ and a SIGNserver_sign_sk⋅. After receiving evk, the vehicle verifies hashk+1 by computing a H⋅ and the server’s signature by computing a VERserver_sign_pk⋅. When evk is distributed to the nearby vehicle, the nearby vehicle verifies the server’s signature by computing VERserver_sign_pk⋅.(ii)
In the nonemergency and not connected to the server case, we suppose that the old evidence has been distributed to the nearby vehicle. The vehicle generates a chunk of EDR datack,tk,lk,MACv_macck||tk||lk by computing a S_ENCv_s_enc⋅ and a MACv_mac⋅, then transmits it to the nearby vehicle.(iii)
Similarly, in the emergency and connected to the server case, the vehicle applies aMACv_mac⋅, a S_ENCPKI_v_s_enc⋅, a H⋅, and a VERserver_sign_pk⋅. The server applies a H⋅ and a SIGNserver_sign_sk⋅. The nearby vehicle applies a SIGNserver_sign_sk⋅.(iv)
In the emergency and not connected to the server case, the vehicle applies aMACv_mac⋅.References [5, 12] apply pairing-based cryptography algorithms. Let ECC_ADD⋅ denote the addition of two points in elliptic-curve cryptography (ECC), ECC_MUL⋅ denote the elliptic-curve scalar multiplication, and PAIRING⋅ denote the bilinear map. In [5, 12], there may be more than one RSU or nearby vehicle receiving a chunk of EDR data, but we only count one for a fair comparison.In [12], the vehicle generates a chunk of EDR data AS_ENCCPKRVPIDij,T,Ei,σi, where Ei=xP,K+xTRID,S_ENCKmi, σi=VSKi1+hT||EiVSKi2, by computing a AS_ENCCPKR⋅, two ECC_ADD⋅s, five ECC_MUL⋅s, a S_ENCKmi, and two H⋅s. The RSU verifies the received EDR data by computing a AS_DECCSKR⋅, three H⋅s, a ECC_ADD⋅, a ECC_MUL⋅, and four PAIRING⋅s.In [5], the vehicle generates a chunk of EDR data VPIDij,Ti,Ei,khσi,piσi by computing a S_ENCCPKR⋅, two ECC_ADD⋅s, five ECC_MUL⋅s, a MACs⋅, and a H⋅. Upon receiving the EDR data, both the nearby vehicle and RSU verify it by computing a MACs⋅; the RSU requires additional verification by computing two H⋅s, a ECC_ADD⋅, a ECC_MUL⋅, and four PAIRING⋅s. The nearby vehicle generates a receipt to acknowledge received EDR data by computing a MACs⋅, a ECC_ADD⋅, and a ECC_MUL⋅.We implemented our experiment in Java with the JPBC library [19]. The hardware used in the experiment was a laptop with an Intel Core i5-8300H CPU and 8 GB RAM. To achieve the same security level (≥112 bits) [20], we used RSA with 2048-bit key + AES-128/SHA-224 as an asymmetric algorithm, AES-128 as the symmetric encryption algorithm, ECC with 224-bit order, SHA-224 as the H⋅, and HmacSHA224 as MACX⋅. According to [5, 12], the size of mi in the EDR data was set to 18,560 bytes. The sizes of data segments tk/T and lk were set to 8 bytes and 16 bytes, respectively. We repeated each experiment 10,000 times and used the average running time as the computation. The experiment included all cryptography algorithms shown in Figure 4 with different sizes of message, ECC_ADD⋅, ECC_MUL⋅, and PAIRING⋅, and the entire process of dealing with a chunk of EDR data in our scheme and [5, 12].Figure 4
Computation of different cryptography algorithms.


### 6.2. Performance Results

Figure4 compares the computation between asymmetric cryptography algorithms and symmetric cryptography algorithms. The experiment showed that the ECC_ADD⋅, ECC_MUL⋅, and PAIRING⋅ used in the asymmetric cryptography algorithms had computation costs of 101.57 μs, 28,774.01 μs, and 29,460.14 μs, respectively. The results indicated that symmetric cryptography algorithms have a much smaller computation cost than asymmetric cryptography algorithms. The bar chart in Figure 5 shows that our scheme had computation costs of 23,463.32 μs, 313.27 μs, 23,453.71 μs, and 164.28 μs, respectively, for a chunk of EDR data in the four cases, compared with [5, 12], which took 407,058.33 μs and 394,832.16 μs, respectively. This implies that our scheme runs faster and can provide a quicker response.Figure 5
Computation for a chunk of data in schemes for [5, 12] and our scheme.


## 6.1. Experiment Model

We focused on the cost of computation. There is a similar setup at the beginning of our scheme and [5, 12]. In our scheme, the vehicle sets up a secure channel with the server in a PKI manner. This secure channel will be kept open for much of the EDR data. In [5, 12], the vehicle also starts with a secure channel in a PKI manner to obtain the system master key s and a pool of pseudoidentities. Therefore, we limited the computational cost by having these operations at the beginning. We wanted to measure the computation from a chunk of EDR data that is generated to this chunk of EDR data, which is distributed to the proper destination.In our scheme, a chunk of EDR data goes through the following processes in four cases:(i)
In the nonemergency and connected to the server case, the vehicle generates a chunk of EDR datamk,tk,lk,MACv_macmk||tk||lk by computing a MACv_mac⋅ and then transmits it to the server in the secure channel by performing a symmetric encryption S_ENCPKI_v_s_enc⋅, where the key PKI_v_s_enc is from the key agreement algorithm in the PKI manner. When the server receives this encrypted chunk of EDR data, it decrypts it by computing a S_DECPKI_v_s_enc⋅, then generates the evidence evk=hashk+1,tk,lk,SIGNserver_sign_skhashk+1||tk||lk by computing a H⋅ and a SIGNserver_sign_sk⋅. After receiving evk, the vehicle verifies hashk+1 by computing a H⋅ and the server’s signature by computing a VERserver_sign_pk⋅. When evk is distributed to the nearby vehicle, the nearby vehicle verifies the server’s signature by computing VERserver_sign_pk⋅.(ii)
In the nonemergency and not connected to the server case, we suppose that the old evidence has been distributed to the nearby vehicle. The vehicle generates a chunk of EDR datack,tk,lk,MACv_macck||tk||lk by computing a S_ENCv_s_enc⋅ and a MACv_mac⋅, then transmits it to the nearby vehicle.(iii)
Similarly, in the emergency and connected to the server case, the vehicle applies aMACv_mac⋅, a S_ENCPKI_v_s_enc⋅, a H⋅, and a VERserver_sign_pk⋅. The server applies a H⋅ and a SIGNserver_sign_sk⋅. The nearby vehicle applies a SIGNserver_sign_sk⋅.(iv)
In the emergency and not connected to the server case, the vehicle applies aMACv_mac⋅.References [5, 12] apply pairing-based cryptography algorithms. Let ECC_ADD⋅ denote the addition of two points in elliptic-curve cryptography (ECC), ECC_MUL⋅ denote the elliptic-curve scalar multiplication, and PAIRING⋅ denote the bilinear map. In [5, 12], there may be more than one RSU or nearby vehicle receiving a chunk of EDR data, but we only count one for a fair comparison.In [12], the vehicle generates a chunk of EDR data AS_ENCCPKRVPIDij,T,Ei,σi, where Ei=xP,K+xTRID,S_ENCKmi, σi=VSKi1+hT||EiVSKi2, by computing a AS_ENCCPKR⋅, two ECC_ADD⋅s, five ECC_MUL⋅s, a S_ENCKmi, and two H⋅s. The RSU verifies the received EDR data by computing a AS_DECCSKR⋅, three H⋅s, a ECC_ADD⋅, a ECC_MUL⋅, and four PAIRING⋅s.In [5], the vehicle generates a chunk of EDR data VPIDij,Ti,Ei,khσi,piσi by computing a S_ENCCPKR⋅, two ECC_ADD⋅s, five ECC_MUL⋅s, a MACs⋅, and a H⋅. Upon receiving the EDR data, both the nearby vehicle and RSU verify it by computing a MACs⋅; the RSU requires additional verification by computing two H⋅s, a ECC_ADD⋅, a ECC_MUL⋅, and four PAIRING⋅s. The nearby vehicle generates a receipt to acknowledge received EDR data by computing a MACs⋅, a ECC_ADD⋅, and a ECC_MUL⋅.We implemented our experiment in Java with the JPBC library [19]. The hardware used in the experiment was a laptop with an Intel Core i5-8300H CPU and 8 GB RAM. To achieve the same security level (≥112 bits) [20], we used RSA with 2048-bit key + AES-128/SHA-224 as an asymmetric algorithm, AES-128 as the symmetric encryption algorithm, ECC with 224-bit order, SHA-224 as the H⋅, and HmacSHA224 as MACX⋅. According to [5, 12], the size of mi in the EDR data was set to 18,560 bytes. The sizes of data segments tk/T and lk were set to 8 bytes and 16 bytes, respectively. We repeated each experiment 10,000 times and used the average running time as the computation. The experiment included all cryptography algorithms shown in Figure 4 with different sizes of message, ECC_ADD⋅, ECC_MUL⋅, and PAIRING⋅, and the entire process of dealing with a chunk of EDR data in our scheme and [5, 12].Figure 4
Computation of different cryptography algorithms.


## 6.2. Performance Results

Figure4 compares the computation between asymmetric cryptography algorithms and symmetric cryptography algorithms. The experiment showed that the ECC_ADD⋅, ECC_MUL⋅, and PAIRING⋅ used in the asymmetric cryptography algorithms had computation costs of 101.57 μs, 28,774.01 μs, and 29,460.14 μs, respectively. The results indicated that symmetric cryptography algorithms have a much smaller computation cost than asymmetric cryptography algorithms. The bar chart in Figure 5 shows that our scheme had computation costs of 23,463.32 μs, 313.27 μs, 23,453.71 μs, and 164.28 μs, respectively, for a chunk of EDR data in the four cases, compared with [5, 12], which took 407,058.33 μs and 394,832.16 μs, respectively. This implies that our scheme runs faster and can provide a quicker response.Figure 5
Computation for a chunk of data in schemes for [5, 12] and our scheme.


## 7. Conclusions

In this study, we propose a fast VANET-assisted scheme for event data recorders (EDRs). Our scheme is suitable for current scenarios in which vehicle data are updated to the server. The gist of our scheme is that the vehicle uploads the EDR data to the cloud server and sends the evidence of the storage data to the nearby vehicle through VANET. Our scheme has been adopted for four different cases. The use of cryptography algorithms, in particular symmetric algorithms, ensures that our scheme is secure and fast.



---

*Source: 7816483-2022-03-15.xml*