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.
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 Figure 1, 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.
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 generates
For 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 vehicle
For 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 notations , , , , and to, respectively, denote asymmetric encryption algorithm, symmetric encryption algorithm, signature algorithm, message authentication code (MAC) algorithm, and hash algorithm for using the key . The server has a pair of keys (, ) for signing. The TA generates random keys and 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 , …, , , … where is the information related to the conditions of the vehicle such as its speed, brake use, and engine status, and , are the approximate time and location, respectively, when and where these data are generated. As shown in Figure 1, , …, have been stored on the server in the form of blockchain , ..., , and is the next block. consists of , If , ; If , .
4.2. Schemes for Four Scenarios
4.2.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 to the server. Step 3. After receiving the data from V, the server generates the block as . Step 4. The server then generates the evidence . It computes , with the secret key and sends back to V. Step 5. After receiving the evidence , V computes and verifies , including , , and the signature with the public key . 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 to V’. Step 8. After receiving the evidence , V′ verifies the signature with the public key . If the verification goes well, V′ stores .
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 with the key , then sends to V’.
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 , then sends 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 using the key and decrypts using the key . 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 / and . 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 Section 3.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 server includes a data segment . The key is only in possession of the tamper-proof EDR and the trusted party TA so that the server cannot generate any proper . Meanwhile, is stored in the form of blockchain and the server feeds back the evidence of storage containing , the hash of block . Once the server modifies any bit of the data, the vehicle or TA will find out that by comparing the segments, form the server and . 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 storage 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 and its evidence of data storage . It will be found out by the vehicle or the TA that obtains . 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 of /, 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 of , where . is encrypted by a symmetric encryption algorithm with key , which is held by the EDR and TA. Therefore, the nearby vehicle cannot decrypt in order to obtain any information about .
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 of , where 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 , where the data segment is the result of a MAC algorithm. The key 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 includes the server’s signature . The private key 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 of , where . The TA can use the key to decrypt to obtain . In emergency cases, the EDR data consist of , where is in the form of plaintext directly. The TA can verify that the EDR data come from the proper EDR. The EDR data consist of or , where the data segments and are the result of a MAC algorithm. The key 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 evidence includes the server’s signature . The TA can verify the signature with the server’s public key to make sure that 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 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 data by computing a and then transmits it to the server in the secure channel by performing a symmetric encryption , where the key 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 , then generates the evidence by computing a and a . After receiving , the vehicle verifies by computing a and the server’s signature by computing a . When is distributed to the nearby vehicle, the nearby vehicle verifies the server’s signature by computing .(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 data by computing a and a , then transmits it to the nearby vehicle.(iii)Similarly, in the emergency and connected to the server case, the vehicle applies a , a , a , and a . The server applies a and a . The nearby vehicle applies a .(iv)In the emergency and not connected to the server case, the vehicle applies a .
References [5, 12] apply pairing-based cryptography algorithms. Let denote the addition of two points in elliptic-curve cryptography (ECC), denote the elliptic-curve scalar multiplication, and 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 , where , , by computing a , two s, five s, a , and two s. The RSU verifies the received EDR data by computing a , three s, a , a , and four s.
In [5], the vehicle generates a chunk of EDR data by computing a , two s, five s, a , and a . Upon receiving the EDR data, both the nearby vehicle and RSU verify it by computing a ; the RSU requires additional verification by computing two s, a , a , and four s. The nearby vehicle generates a receipt to acknowledge received EDR data by computing a , a , and a .
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 ( 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 , and HmacSHA224 as . According to [5, 12], the size of in the EDR data was set to 18,560 bytes. The sizes of data segments and 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, , , , and the entire process of dealing with a chunk of EDR data in our scheme and [5, 12].
6.2. Performance Results
Figure 4 compares the computation between asymmetric cryptography algorithms and symmetric cryptography algorithms. The experiment showed that the , , 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.
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.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this article.
Acknowledgments
The work was supported by the National Key Research and Development Plan of China (2018YFB1003701 and 2020YFB1005600), the National Natural Science Foundation of China (61825203, U1736203, 61732021, 61902067, and 62102166), the Major Program of Guangdong Basic and Applied Research Project (2019B030302008 and 2020A1515111175), the Key-Area Research and Development Program of Guangdong Province (2020B0101360001 and 2020B0101090004), the National Joint Engineering Research Center for Network Security Detection and Protection Technology, the Guangdong Provincial Special Funds for Applied Technology Research and Development and Transformation of Important Scientific and Technological Achieve (2017B010124002), the Guangdong Provincial Science and Technology Project (2017B010111005), the Guangdong Basic and Applied Basic Research Foundation (2021A1515410005 and 2021A1515012627), and the Foundation for Young Innovative Talents in Ordinary Universities of Guangdong (2018KQNCX255).