A Fast VANET-Assisted Scheme for Event Data Recorders

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.


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. e IEEE Vehicular Technology Society has proposed standards for EDRs [2][3][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.
ere 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]. erefore, 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. e 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.

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. ey 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. Figure 1, the vehicle uploads the EDR data to the server. e 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. e 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.

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. erefore, we will not classify the situation according to whether there is a nearby vehicle.

Nonemergency Cases
(i) Vehicle Connected to Server. e 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. e vehicle sends the nearby vehicle the evidence whose EDR data have been stored on the server. e 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.

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. e 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. e vehicle should try to distribute the EDR data as soon as possible: (i) Vehicle Connected to Server. e 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. e 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.

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. erefore, we provide an analysis of the functionality and security requirements for each party.
For the vehicle, the following are the requirements: (i) e server that stores the EDR data should be authenticated. (ii) e data stored on the server should have integrity.
(iii) e server should not delete the data. If it does so, this will be discovered from the evidence of data storage. (iv) e vehicle should be anonymous to the nearby vehicle in the nonemergency cases. (v) e vehicle's EDR data should be confidential to the nearby vehicle in the nonemergency cases.

Security and Communication Networks
For the server, the requirements are as follows: (i) e 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 generates For the nearby vehicle, the requirements are as follows: (i) Assistance for storing the evidence/EDR data can be mutual (ii) e list of accidents publicized by the TA can be efficiently checked to make sure whether it has the related evidence/EDR data (iii) ere should be incentives or rewards for reporting the evidence/EDR data to the TA (iv) e nearby vehicle should be anonymous to the focal vehicle For the TA, the requirements are as follows: (i) All parties connected to the TA should be authenticated (ii) e TA can decrypt the encrypted EDR data (iii) e TA can verify that the EDR data come from the proper EDR (iv) e TA can verify that the evidence comes from the proper server (v) e evidence/EDR data should have integrity

Setup.
e TA, the server, and vehicles (WLOG, including a vehicle V and its nearby vehicle V′) form a public key infrastructure (PKI). e 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 notations AS , and H(m) 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. e server has a pair of keys (server sign pk, server sign sk) for signing. e TA generates random keys v s enc and v mac and preloads them in the V's EDR. e EDR is considered to be tamperproof and these two keys cannot be retrieved from the EDR. e EDR's data are (m 1 , t 1 , l 1 , MAC v mac (m 1 ||t 1 ||l 1 )), . . ., where m k is the information related to the conditions of the vehicle such as its speed, brake  Security and Communication Networks use, and engine status, and t k , l k are the approximate time and location, respectively, when and where these data are generated. As shown in Figure 1,

Nonemergency Cases.
For the vehicle connected to server, the steps are shown in Figure 2.
Step 1. A secure channel is set up between V and the server.
Step 2. V uploads (m k , t k , l k , MAC v mac (m k ||t k ||l k )) to the server.
Step 3. After receiving the data from V, the server generates the block b k as (hash k , m k , t k , l k , MAC v mac (m k ||t k ||l k )).
Step 4. e server then generates the evidence ev k . It computes hash k+1 � H(b k ), ev k � (hash k+1 , t k , l k , SIGN server sign sk (hash k+1 ||t k ||l k )) with the secret key server sign sk and sends ev k back to V.
Step 5. After receiving the evidence ev k , V computes hash k+1 � H(b k ) and verifies ev k , including t k , l k , and the signature SIGN server sign sk (hash k+1 ||t k ||l k ) 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 ev k to V'.
Step 8. After receiving the evidence ev k , V′ verifies the signature SIGN server sign sk (hash k+1 ||t k ||l k ) with the public key server sign pk. If the verification goes well, V′ stores ev k .

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 Figure 3 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 c k � S ENC v s enc (m k ) with the key v s enc, MAC v mac (c k ||t k ||l k ) then sends (c k , t k , l k , MAC v mac (c k ||t k ||l k )) to V'.

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 c k replaced by plaintext m k ." 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 MAC v mac (m k ||t k ||l k ), then sends (m k , t k , l k , MAC v mac (m k ||t k ||l k )) to V'.

How to Reveal EDR Data?
e 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). e TA verifies the information about the time, location, and the MAC v mac (·) using the key v mac and decrypts S ENC v s enc (·) using the key v s enc. e TA will reward V′ for its proper evidence/EDR data. en 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. e 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.

Functionality and Security Analysis
In this section, we analyze the functionality and security of our scheme item by item according to the requirements in Section 3.3.

For the Vehicle
e 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. is process guarantees the confidentiality, integrity, and authentication of the transmission against the malicious PPT adversary. e data stored on the server should have integrity. Every block of the data stored on the server b k includes a data segment MAC v mac (m k ||t k ||l k ). e 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 MAC v mac (m k ||t k ||l k ). Meanwhile, b k is stored in the form of blockchain and the server feeds back the evidence of storage ev k containing hash k+1 , the hash of block b k . Once the server modifies any bit of the data, the vehicle or TA will find out that by comparing the segments, hash k+1 form the server and ev k . e 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 storage ev k 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 b k and its evidence of data storage ev k . It  Security and Communication Networks 5 will be found out by the vehicle or the TA that obtains ev k . e vehicle should be anonymous to the nearby vehicle in the nonemergency cases.
is anonymity feature is maintained in two stages. e first is when the vehicle is transmitting the evidence/EDR data to the nearby vehicle in the nonemergency cases. e evidence/EDR data consist of (hash k+1 , t k , l k , SIGN server sign sk (hash k+1 ||t k ||l k ))/ (c k , t k , l k , MAC v mac (c k ||t k ||l k )), which do not leak any information about the identity. e 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. e vehicle's EDR data should be confidential to the nearby vehicle in the nonemergency cases. e EDR data sent to the nearby vehicle consist of (c k , t k , l k , MAC v mac (c k ||t k ||l k )), where c k � S ENC v s enc (m k ). m k is encrypted by a symmetric encryption algorithm with key v s enc, which is held by the EDR and TA. erefore, the nearby vehicle cannot decrypt c k in order to obtain any information about m k .

For the Server
e communication with the vehicle/TA should be authenticated and secure against the malicious PPT adversary.
is 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 of (m k , t k , l k , MAC v mac (m k ||t k ||l k )), where m k 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 of (m k , t k , l k , MAC v mac (m k ||t k ||l k )), where the data segment MAC v mac (m k ||t k ||l k ) is the result of a MAC algorithm.
e 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 evidence ev k � (hash k+1 , t k , l k , SIGN server sign sk (hash k+1 ||t k ||l k )) includes the server's signature SIGN server sign sk (hash k+1 ||t k ||l k ). e private key server sign sk is only in possession of the server. erefore, no one can forge the evidence of data storage.

For the Nearby Vehicle
Assistance for storing the evidence/EDR data can be mutual in the nonemergency cases.

MAC v_mac (c k || t k || l k )
Help store evidence/EDR data mutually c k t k l k Figure 3: Process in the nonemergency case of vehicle not connected to server.
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. e list of accidents publicized by the TA can be checked to make sure that the nearby vehicle has the related evidence/EDR data. e 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. is means that V′ can efficiently check the list of accidents using the information about time and location. ere 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.
e 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.
e communication with the TA should be authenticated and secure against the malicious PPT adversary.
is 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.

For the TA
e communication with the nearby vehicle/server should be authenticated and secure a malicious PPT adversary again.
is 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.
e TA can decrypt the encryption of the EDR data. In the nonemergency cases, the EDR data consist of (c k , t k , l k , MAC v mac (c k ||t k ||l k )), where c k � S ENC v s enc (m k ). e TA can use the key v s enc to decrypt c k to obtain m k . In emergency cases, the EDR data consist of (m k , t k , l k , MAC v mac (m k ||t k ||l k )), where m k is in the form of plaintext directly.
e TA can verify that the EDR data come from the proper EDR.
e EDR data consist of (c k , t k , l k , MAC v mac (c k ||t k ||l k )) or (m k , t k , l k , MAC v mac (m k ||t k ||l k )), where the data segments MAC v mac (c k ||t k ||l k ) and MAC v mac (m k ||t k ||l k ) are the result of a MAC algorithm. e key v mac is only in possession of the tamper-proof EDR and the TA. us, the TA can confirm that the EDR data come from the proper EDR.
e TA can verify that the evidence comes from the proper server: e evidence ev k � (hash k+1 , t k , l k , SIGN server sign sk (hash k+1 ||t k ||l k )) includes the server's signature SIGN server sign sk (hash k+1 ||t k ||l k ). e TA can verify the signature with the server's public key server sign pk to make sure that ev k comes from the proper server.
e 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. e server should not delete the data. If it does so, this will be discovered from the evidence of data storage.
is 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. is 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. erefore, 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.
is combination can not only guarantee anonymity but also provides more features.

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]. e results of the experiment show that our scheme has little computational overhead.

Experiment Model.
We focused on the cost of computation. ere 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. is 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. erefore, we limited the computational Security and Communication Networks 7 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 data (m k , t k , l k , MAC v mac (m k ||t k ||l k )) by computing a MAC v mac (·) and then transmits it to the server in the secure channel by performing a symmetric encryption S ENC PKI 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 DE C PKI v s enc (·), then generates the evidence ev k � (hash k+1 , t k , l k , SIGN server sign sk (hash k+1 ||t k ||l k )) by computing a H(·) and a SIGN server sign sk (·). After receiving ev k , the vehicle verifies hash k+1 by computing a H(·) and the server's signature by computing a VER server sign pk (·). When ev k is distributed to the nearby vehicle, the nearby vehicle verifies the server's signature by computing VER server 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. e vehicle generates a chunk of EDR data (c k , t k , l k , MAC v mac (c k ||t k ||l k )) by computing a S ENC v s enc (·) and a MAC v mac (·), then transmits it to the nearby vehicle.
(iii) Similarly, in the emergency and connected to the server case, the vehicle applies a MAC v mac (·), a S ENC PKI v s enc (·), a H(·), and a VER server sign pk (·). e server applies a H(·) and a SIGN server sign sk (·). e nearby vehicle applies a SIGN server sign sk (·). (iv) In the emergency and not connected to the server case, the vehicle applies a MAC v mac (·).
References [5,12] apply pairing-based cryptography algorithms. Let ECC A DD(·) 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 , by computing a AS ENC CPK R (·), two ECC A DD(·) s, five ECC MUL(·) s, a S ENC K (m i ), and two H(·) s. e RSU verifies the received EDR data by computing a AS DE C CSK R (·), three H(·) s, a ECC A DD(·), a ECC MUL(·), and four PAIRING(·) s.
In [5], the vehicle generates a chunk of EDR data (VPID ij , T i , E i , khσ i , piσ i ) by computing a S ENC CPK R (·), two ECC A DD(·) s, five ECC MUL(·) s, a MAC s (·), and a H(·). Upon receiving the EDR data, both the nearby vehicle and RSU verify it by computing a MAC s (·); the RSU requires additional verification by computing two H(·) s, a ECC A DD(·), a ECC MUL(·), and four PAIRING(·) s. e nearby vehicle generates a receipt to acknowledge received EDR data by computing a MAC s (·), a ECC A DD(·), and a ECC MUL(·).
We implemented our experiment in Java with the JPBC library [19]. e 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 MAC X (·). According to [5,12], the size of m i in the EDR data was set to 18,560 bytes. e sizes of data segments t k /T and l k 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. e experiment included all cryptography algorithms shown in Figure 4 with different sizes of message, ECC A DD(·), ECC MUL(·), and PAIRING(·), and the entire process of dealing with a chunk of EDR data in our scheme and [5,12]. Figure 4 compares the computation between asymmetric cryptography algorithms and symmetric cryptography algorithms. e experiment showed that the ECC A DD(·), 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. e results indicated that symmetric cryptography algorithms have a much smaller computation cost than asymmetric cryptography algorithms. e 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. is implies that our scheme runs faster and can provide a quicker response.

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. e 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. e use of cryptography algorithms, in particular symmetric algorithms, ensures that our scheme is secure and fast.

Data Availability
e data used to support the findings of this study are included within the article.  Figure 5: Computation for a chunk of data in schemes for [5,12] and our scheme.

Conflicts of Interest
Security and Communication Networks 9