# 5G-VRSec: Secure Video Reporting Service in 5G Enabled Vehicular Networks

Authors: Sang Guun Yoo
Journal: Wireless Communications and Mobile Computing
 (2017)

---

## Abstract

Despite an imminent arrival of the 5G communication technology, there are only a few research works done using such technology in the field of vehicular networks. One of the pioneers in proposing a service for 5G enabled vehicular networks is the Eiza-Ni-Shi Scheme. In such scheme, the authors present an innovative system model for 5G vehicular networks that enables a secure real-time video reporting service with privacy awareness. Even though the proposed service is very important since it aims to improve the road safety, it cannot be considered secure enough. This work found that the scheme has serious security flaws and functionality limitations. First, it is vulnerable to Department of Motor Vehicles and Law Enforcement Agency impersonation attacks, it allows forged video upload, there is no separation of responsibilities between Law Enforcement Agency and trusted authority, and it is susceptible to privileged insider attack. In addition, it does not contemplate the management of multiple geographic/administrative regions (multiple trusted authorities) which is important in real implementations. In this situation, the present work proposes an extended scheme that eliminates the identified security flaws and implements new features that make the implementation across several geographic/administrative regions possible.


---

## Body

## 1. Introduction

The 5G communication technology has been one of the most important research fields in the academy over the last several years [1–3], and it also has received the interest of the telecommunication industry worldwide [4–6]. 5G technology is expected to transform the way users communicate by supporting traditional and novel applications that demand high-speed wireless connections with lower latency and promoting both spectrum and energy efficiency [5]. 5G will also give the foundational infrastructure for building a fully realized Internet of Things and Smart Cities and it will allow the implementation of new real-time services.Despite an imminent arrival of the 5G communication technology, there are only a few research works done using such technology in the field of vehicular networks. One of the pioneers in proposing a service for 5G enabled vehicular networks is [7] (called Eiza-Ni-Shi Scheme in this paper). In such work, the authors propose an innovative system model for 5G vehicular networks that enables a secure real-time video reporting service with privacy awareness, and they indicate that their approach is the first study that visualizes the architecture of 5G enabled vehicular network and solves the security and privacy issues of video reporting services. The Eiza-Ni-Shi Scheme utilizes several previous works to provide a novel scheme for a 5G enabled vehicular network that enables a secure and privacy-aware real-time video reporting service that allows registered vehicles to rapidly deliver the video of accidents to receive an opportune response from official vehicles (e.g., police vehicles or ambulance).Even though the proposed service is very important contribution since it aims to improve the road safety and therefore save more lives, it cannot be considered secure enough. This work found that the scheme has serious security flaws and functionality limitations. First, it is vulnerable to Department of Motor Vehicles and Law Enforcement Agency (LEA) impersonation attacks, it allows forged video upload, there is no separation of responsibilities between LEA and trusted authority, and privileged insider attack is possible in LEA. Additionally, it does not contemplate the management of multiple geographic/administrative regions (see Figure1) which is important in real implementations. In most of the cases, not all the motorized vehicles are controlled by a centralized entity, but they are delegated to regional entities (e.g., managed per states, cities, or districts). For this reason, the proposed scheme assumes a real world scenario with multiple trusted authorities (TA), Department of Motor Vehicles (DMV), LEAs connected to its own Cloud Platform (see Figure 2).Figure 1
System model of Eiza-Ni-Shi Scheme.Figure 2
Extended system model for secure video reporting service in 5G enabled vehicular network.The intention of this paper is to continue with the research made in [7] by eliminating its security flaws and extending its functionality, that is, making it possible to be implemented across several geographic/administrative regions. The new contributions of this paper are as follows. (1) First, this paper makes a cryptanalysis and functionally analysis of Eiza-Ni-Shi Scheme and demonstrates how it is vulnerable to DMV and LEA impersonation attacks, how it allows forged video upload, that there is no separation of responsibilities between LEA and TA, how privileged insider attack is possible in LEA, and how it does not contemplate the management of multiple geographic/administrative regions (multiple trusted authorities) which is very important in large scale implementations. (2) Secondly, this work develops an improved scheme that delivers a trusted and reliable real-time video reporting service in 5G enabled vehicular networks which solves the identified security flaws. (3) Finally, the proposed design extends the functionality of the service for multiple trusted authorities, Department of Motor Vehicles, Law Enforcement Agencies, and Cloud Platforms which was proposed as future works in [7].The rest of the paper is organized as follows. Section2 overviews the preliminary concepts used in both Eiza-Ni-Shi Scheme and the proposed solution. Section 3 then reviews the Eiza-Ni-Shi Scheme and executes its cryptanalysis and functionality analysis. Later, Section 4 presents the extended system model of 5G enabled vehicular network and details the proposed secure and privacy-aware scheme. Section 4 also analyzes the proposed protocol in terms of performance and security. Finally, Section 5 concludes the present paper.


## 2. Preliminaries

This section introduces the cryptographic meanings used in both Eiza-Ni-Shi Scheme and the proposed scheme.


### 2.1. Pseudonymous Authentication Scheme

Let(G1,+) and (G2,+) be two cyclic groups of prime order q and e:G1×G1→G2 be an efficient admissible bilinear map. The TA selects a random generator P∈G1, two hash functions h(·) and f(·):{0,1}∗→G1 and a random key S∈Z∗q. Then, the TA calculates its public key Ppub as Ppub=sP and distributes the parameters (G1,G2,q,P,e,Ppub,h·,f·,SEnc·,ΔT) where SEnc(·) is a symmetric encryption function and ΔT is the expiration threshold of a pseudonymous certificate. As well as the Eiza-Ni-Shi Scheme, the proposed solution also uses PASS (pseudonymous authentication scheme with strong privacy preservation) [8] to anonymously authenticate participating vehicles. Applying the concept proposed in [8], the trusted authority generates a private key SKTA and uses it to issue a set of pseudonymous certificates to those vehicles which expressed their willingness to participate in the video reporting service. The size of each pseudonymous certificate is 66 bytes: 21 bytes for the public key, 20 bytes for pseudo-identity, 4 bytes for the validity period, and 21 bytes for digital signature. Finally, the TA generates the private key set corresponding to the pseudonymous certificates and delivers it accompanied with the set of pseudonymous certificates to the participating vehicle and stores the mapping relationship between the real identity of participating vehicle and its pseudo-identities.


### 2.2. Public Key Encryption with Keyword Search

The Public Key Encryption with Keyword Search (PEKS) is an asymmetric cryptographic mechanism that allows an entity to delegate the storage of its encrypted data, while preserving the capability to search encrypted keywords related to the encrypted information [9, 10]. The entity uses the public key of a recipient R  PKR to calculate the searchable encryption SPEKS of a set of keywords kw=kw1,kw2,…,kwn by executing SPEKS=PEKSPKR,kw and uploads the calculated value attached to the encrypted data to the storage server. Later, when search of a keyword is required, the entity creates a trapdoor Tkwi by executing Tkwi=TrapdoorSKR,kwi, where SKR is the private key of the recipient R and kwi is the keyword used for search. Following this, the storage server uses Tkwi to execute the search process by executing TestSPEKS,Tkwi. The search process will return true if kwi∈kw. Finally, the encrypted data associated with kwi is returned for decryption.


### 2.3. Ciphertext-Policy Attribute Based Encryption

Ciphertext-Policy Attribute Based Encryption (CP-ABE or simply ABE) is an asymmetric cryptographic system for realizing complex access control on encrypted data [11]. The data to be protected is encrypted using a public key in association with a specific policy. The encrypted data is accessible only by those users who have the decryption key and have the attributes that satisfy the policy specified during the encryption process. Based on [7], it is possible to use as attributes the following values {“police vehicle”, “ambulance”, “traffic authority”, “traffic law enforcement”}. In the phase of system initialization, the TA generates a public key PKABE and a master key MKABE. The MKABE is utilized to generate a decryption key for a specific entity E that is associated with a set of attributes (AS) that describes E,for example, AS = {“police vehicle”, “traffic authority”, “traffic law enforcement”}. In order to give E an access to the encrypted data, it should be encrypted using a specific policy,Policy,for example, policy = {“police vehicle” OR “traffic authority”}, as ABEC=ABE.EncPKABE,data,Policy. Thus, E can access the encrypted data and decrypts it as follows: data=ABE.DecABEC,decryptionkey.


## 2.1. Pseudonymous Authentication Scheme

Let(G1,+) and (G2,+) be two cyclic groups of prime order q and e:G1×G1→G2 be an efficient admissible bilinear map. The TA selects a random generator P∈G1, two hash functions h(·) and f(·):{0,1}∗→G1 and a random key S∈Z∗q. Then, the TA calculates its public key Ppub as Ppub=sP and distributes the parameters (G1,G2,q,P,e,Ppub,h·,f·,SEnc·,ΔT) where SEnc(·) is a symmetric encryption function and ΔT is the expiration threshold of a pseudonymous certificate. As well as the Eiza-Ni-Shi Scheme, the proposed solution also uses PASS (pseudonymous authentication scheme with strong privacy preservation) [8] to anonymously authenticate participating vehicles. Applying the concept proposed in [8], the trusted authority generates a private key SKTA and uses it to issue a set of pseudonymous certificates to those vehicles which expressed their willingness to participate in the video reporting service. The size of each pseudonymous certificate is 66 bytes: 21 bytes for the public key, 20 bytes for pseudo-identity, 4 bytes for the validity period, and 21 bytes for digital signature. Finally, the TA generates the private key set corresponding to the pseudonymous certificates and delivers it accompanied with the set of pseudonymous certificates to the participating vehicle and stores the mapping relationship between the real identity of participating vehicle and its pseudo-identities.


## 2.2. Public Key Encryption with Keyword Search

The Public Key Encryption with Keyword Search (PEKS) is an asymmetric cryptographic mechanism that allows an entity to delegate the storage of its encrypted data, while preserving the capability to search encrypted keywords related to the encrypted information [9, 10]. The entity uses the public key of a recipient R  PKR to calculate the searchable encryption SPEKS of a set of keywords kw=kw1,kw2,…,kwn by executing SPEKS=PEKSPKR,kw and uploads the calculated value attached to the encrypted data to the storage server. Later, when search of a keyword is required, the entity creates a trapdoor Tkwi by executing Tkwi=TrapdoorSKR,kwi, where SKR is the private key of the recipient R and kwi is the keyword used for search. Following this, the storage server uses Tkwi to execute the search process by executing TestSPEKS,Tkwi. The search process will return true if kwi∈kw. Finally, the encrypted data associated with kwi is returned for decryption.


## 2.3. Ciphertext-Policy Attribute Based Encryption

Ciphertext-Policy Attribute Based Encryption (CP-ABE or simply ABE) is an asymmetric cryptographic system for realizing complex access control on encrypted data [11]. The data to be protected is encrypted using a public key in association with a specific policy. The encrypted data is accessible only by those users who have the decryption key and have the attributes that satisfy the policy specified during the encryption process. Based on [7], it is possible to use as attributes the following values {“police vehicle”, “ambulance”, “traffic authority”, “traffic law enforcement”}. In the phase of system initialization, the TA generates a public key PKABE and a master key MKABE. The MKABE is utilized to generate a decryption key for a specific entity E that is associated with a set of attributes (AS) that describes E,for example, AS = {“police vehicle”, “traffic authority”, “traffic law enforcement”}. In order to give E an access to the encrypted data, it should be encrypted using a specific policy,Policy,for example, policy = {“police vehicle” OR “traffic authority”}, as ABEC=ABE.EncPKABE,data,Policy. Thus, E can access the encrypted data and decrypts it as follows: data=ABE.DecABEC,decryptionkey.


## 3. Review and Cryptanalysis of Eiza-Ni-Shi Scheme

This section reviews the scheme proposed in [7]. This section also cryptanalyses its features to demonstrate how it is vulnerable to DMV and LEA impersonation attacks, how it allows forged video upload, that there is no separation of responsibilities between LEA and TA, how privileged insider attack is possible in LEA, and how it does not contemplate the management of multiple geographic/administrative regions (multiple trusted authorities) which is very important in large scale implementations.


### 3.1. Review of Eiza-Ni-Shi Scheme

Figure1 shows the system model proposed by the Eiza-Ni-Shi Scheme. The main entities are the Department of Motor Vehicles (DMV), trusted authority (TA), Law Enforcement Agency (LEA), Cloud Platform, and Vehicles (participating vehicles and official vehicles). In the following, there is the brief explanation of different entities that participate in the scheme.Cloud Platform. The Cloud Platform provides the functionality of data storage. Being more concrete, it stores the videos of traffic accidents generated by the reporting service. Obviously, since the Cloud Platform is connected to the Internet, it will be accessible anywhere. It is important to indicate that the reported videos are not delivered directly to the authorities since the communication route to the recipient may not be available; that is, the official vehicle is not reachable via multihop communication. The scheme assumes the availability of a reliable multipath routing algorithm (such as [12]) to find stable routes to the Cloud Platform. In addition, it is assumed that vehicles use the 5G communication technology to access the Cloud Platform.Trusted Authority (TA). This is the entity that manages the pseudonymous certificates, certificates and secret keys of participating vehicles and official vehicles. The Eiza-Ni-Shi Scheme assumes that TA is secure and it is trusted by all the other entities of the 5G enabled vehicular network system.Department of Motor Vehicles (DMV). All vehicles are registered periodically in the DMV. Besides the traditional identifier of the vehicle,that is, Electronic License Plate or Electronic Chassis Number, each vehicle is assumed to have a unique but not fixed 5G identifier. It means the 5G identified can be modified in each inspection of the vehicle by DMV.Law Enforcement Agency (LEA). LEA is integrated part of the system since the reported information, that is, coordinate of accident and video of the accident, is very sensitive information.Participant Vehicles. These are those vehicles that are participating in the cloud-assisted video reporting service. Special equipment (a small computer with video camera, sensors, and 5G communication) is installed in the participant vehicles. The vehicles will record the video and such video will be uploaded to the Cloud Platform when an accident is detected.Official Vehicles. Official Vehicles are those vehicles that are designated and authorized to respond to a traffic accident (e.g., police vehicle or ambulance). These vehicles are usually operated by designated agencies part of the government but also sometimes run by nongovernmental organizations and some private companies.The Eiza-Ni-Shi Scheme proposes a protocol composed of 4 phases called (1) system initialization, (2) participants and official vehicles registration, (3) video transmission, and (4) video receipt/retrieval. The notations used in Eiza-Ni-Shi Scheme are detailed in (i) in the Notations.


#### 3.1.1. System Initialization

The trusted authority (TA) manages a specific area that could be a state, province, or district. The TA chooses a validity period threshold of a pseudonymous certificateΔT and estimates the number of pseudonymous certificates that a vehicle needs to acquire. It is assumed that the issued pseudonymous certificates (stored in each vehicle) cannot be used to impersonate other vehicles because each certificate has a specific validity period and the number of certificates is relatively small.


#### 3.1.2. Participants and Official Vehicles Registration

The participant vehicles are registered executing the following steps.Step  1. During the vehicles’ annual inspection, the user indicates his/her disposition to use the service. Then, the vehicle registers its identity Cv, unique 5G identity 5G_ID, and PKEPpub,Sr with the Department of Motor Vehicles (DMV), where Sr is a random symmetric key sr∈Z∗q, Ppub is TA’s public key, and PKE(·) is an asymmetric encryption function.Step  2. The DMV registers the data of the participant vehicle in its database and forwards 5G_ID,PKEPpub,Sr to the TA requesting the issue of pseudonymous certificates for the vehicle.Step  3. Upon receiving the request from DMV, the TA creates a set of pseudonymous certificates PCertTA,5G_ID,j, a set of private keys SK5G_ID,j, a policy,Policy = {“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}, and a tag U∈Z∗q, and delivers them to the DMV by sending SEnc(Sr,(SK5G_ID,j,PCertTA,5G_ID,j, PKABE,Policy,U)), where SEnc· is an symmetric encryption function and PKABE is the public key used to encrypt a one-time random encryption key Skey underPolicy using CP-ABE [11]. The tag U is a preagreed value between the TA and the Cloud Platform; such value is used by Cv to tag the traffic accident video when uploaded and it is used by the Cloud Platform to recognize the space to store the received video and to notify the registered official vehicles.Step  4. The DMV forwards the received information to the vehicle. It is important to note that DMV only manages the mapping between the vehicle’s 5G_ID and its real identity Cv and it does not know the issued pseudonymous credentials. On the other hand, the TA manages the mapping between the 5G_ID identity and the corresponding pseudonyms without knowledge of vehicles real identity Cv. This separation of responsibilities creates a more secure environment. Upon receiving the data from DMV, the participating vehicle stores the received information into a tamper-proof device (TPD) that it is equipped with [13, 14].On the other side, designated official vehicles are registered to receive the notification of reported traffic accident videos. The official vehicles registration is executed with following steps.Steps  5 and 6. A designated official vehicle DVi sends a registration request to the TA via the Law Enforcement Agency (LEA).Steps  7 and 8. After verifying the request, the TA generates and delivers the certificate CertTA,DVi to DVi and uses the MKABE to create a decryption key dkAS associated with a set of attributes such as AS={“police vehicle”, “ambulance”, “traffic law enforcement”, “traffic authority”}. The attributes will change depending on the type of the official vehicle. The confidential information generated by TA is then delivered to the DVi’s tamper-proof device via LEA.Step  9. DVi uses the data received in previous step to register with the Cloud Platform.


#### 3.1.3. Video Transmission

This phase is executed when an accident occurs to the participant vehicle. This phase is executed as follows.Step  10. The participating vehicle Cv generates a random one-time symmetric key Skey and executes EncC=SEncSkey,TVr to encrypt the accident video report TVr.Step  11. Cv reads the public key of the recipient R (PKR) and executes SPEKS=PEKSPKR,kw to generate a searchable encryption of the keywords kw={“accident video report”, location, date and time}.Step  12. Cv encrypts Skey using the CP-ABE function under Policy as follows: ABEC=ABE.EncPKABE,Skey,Policy to allow only official vehicles having dkAS withPolicy to access ABEC and obtain Skey.Step  13. Using the selected pseudonymous certificate, Cv executes σ5G_ID,j=Sign(SK5G_ID,j,h(EncC∥SPEKS∥ABEC∥hU)), where Sign(·) is the signing function, SK5G_ID,j is the Cv’s private key associated with the selected pseudonymous certificate, and “∥” denotes data concatenation.Step  14. Cv uploads {EncC,SPEKS,ABEC,hU,σ5G_ID,j, PCertTA,5G_ID,j} to the Cloud Platform over the 5G network.


#### 3.1.4. Video Receipt/Retrieval

This phase is executed when the accident video is uploaded to the Cloud Platform. This phase is executed as follows.Step  15. First, the Cloud Platform verifies hU value and then notifies the accident to the nearest official vehicle DVi by sending EncC,SPEKS,ABEC,hU,σ5G_ID,j,PCertTA,5G_ID,j. The authors assume that the location information of the official vehicles is updated periodically in the cloud.Step  16. DVi verifies the received certificate PCertTA,5G_ID,j by executing VerifyPpub,PCertTA,5G_ID,j,σTA,5G_ID,j, where Verifiy· is a verification function. After verification of authenticity of PCertTA,5G_ID, DVi extracts the public key PK5G_ID,j from the pseudonymous certificate.Step  17. DVi verifies σ5G_ID,j by executing Verify(PK5G_ID,j,hEncC∥SPEKS∥ABEC∥hU,σ5G_ID,j).Step  18. After verification of authenticity of σ5G_ID,j, DVi executes Skey=ABE.DecABEC,dkAS to get the one-time symmetric encryption key, where ABE.Dec· is the CP-ABE decryption function.Step  19. DVi executes TVr=SDecSkey,EncC and gets the traffic accident video, where SDec· is a symmetric decryption function.In the Eiza-Ni-Shi Scheme, the encrypted videos are stored on the Cloud Platform to allow access whenever they are needed. In other words, LEA can search for the traffic accident videos on the cloud at any moment.Step  20. LEA generates the searchable trapdoor token Tkwi as follows: Tkwi=TrapdoorSKR,kwi, where keyword kwi can be a location, a date, or just “accident video report.”Step  21. LEA sends the generated Tkwi to the Cloud Platform. The authors assume that there is a secure channel between LEA and Cloud Platform.Step  22. The receipt of Tkwi authorizes the search process over the ciphertext at the cloud.Step  23. LEA receives the message EncC,SPEKS,ABEC,hU,σ5G_ID,j,PCertTA,5G_ID,j. Finally, LEA uses the same procedure to receive the video file TVr.


### 3.2. Cryptanalysis and Functionality Analysis of Eiza-Ni-Shi Scheme

This section makes an analysis of the Eiza-Ni-Shi Scheme and shows how it has several security vulnerabilities and a critical functionality limitation.No Management of Multiple Trusted Authorities. First of all, one of the main limitations of the Eiza-Ni-Shi Scheme is the lack of a mechanism that covers different geographic/administrative regions of vehicular networks. This limitation is mentioned also by the same authors of Eiza-Ni-Shi Scheme and it is left for future work. In most of countries in the world, the control of motorized vehicles is done per different geographic/administrative regions delegating those responsibilities to regional authorities (e.g., state authorities). For this reason, it is necessary to consider a real world scenario with multiples TAs, DMVs, and LEAs connected to its own Cloud Platforms.DMV Impersonation Attack. The adversary Ua can execute the DMV impersonation attack with the following steps. Since the 5G_ID is not a fixed value and it is not verified by the TA, Ua can generate any random value as 5G_ID. Once 5G_ID is generated, Ua will generate a random symmetric key Sr and will send a registration message request5G_ID,PKEPpub,Sr to the TA. Since the 5G_ID is not a fixed value and it is not verified, TA will process the request and it will return the SEncSr,SK5G_ID,j,PCertTA,5G_ID,j,PKABE,Policy,U message. Since Sr was generated by Ua, he/she will be able to obtain the tuple SK5G_ID,j,PCertTA,5G_ID,j,PKABE,Policy,U.Forged Video Upload. By executing the DMV impersonation attack, Ua can obtain the valid private keys SK5G_ID,j, pseudonymous certificates PCertTA,5G_ID,j, PKABE, Policy, and U. With these values, the adversary can simulate a traffic accident by uploading a false video.Nonseparation of Responsibilities between LEA and TA. Eiza-Ni-Shi Scheme separates the responsibilities between DMV and TA. However, it does not separate the responsibilities between LEA and TA. Following the same reasoning of separation of responsibilities between DMV and TA, the mapping between the official vehicle real identity DVi and its 5G_ID should be managed only by LEA and not by TA.Privileged Insider Attack in LEA. Since LEA receives CertTA,DVi and dkAS of each official vehicle in plaintext, the privileged insider of LEA could store such values. Therefore, privileged insider could access every traffic accident video impersonating official vehicles.LEA Impersonation Attack. Since the 5G_ID is not a fixed value and it is not verified by the TA, Ua can generate any random value as 5G_ID. Once 5G_ID is generated, Ua will generate a random symmetric key Sr and will send a registration request message requestDVi,5G_ID to the TA. Since the DVi,5G_ID tuple is not verified by TA, TA will process the request and it will return CertTA,DVi and dkAS message.Exposure of Location of Official Vehicles. The authors of Eiza-Ni-Shi Scheme assume that the location data of official vehicles are delivered periodically to the Cloud Platform in plaintext. The exposure of such data (e.g., localization of police vehicles) could be a critical problem since criminals could use such information to perform illegal activities. The authors of Eiza-Ni-Shi Scheme admit this limitation in their paper and propose a solution for it as a future work.


## 3.1. Review of Eiza-Ni-Shi Scheme

Figure1 shows the system model proposed by the Eiza-Ni-Shi Scheme. The main entities are the Department of Motor Vehicles (DMV), trusted authority (TA), Law Enforcement Agency (LEA), Cloud Platform, and Vehicles (participating vehicles and official vehicles). In the following, there is the brief explanation of different entities that participate in the scheme.Cloud Platform. The Cloud Platform provides the functionality of data storage. Being more concrete, it stores the videos of traffic accidents generated by the reporting service. Obviously, since the Cloud Platform is connected to the Internet, it will be accessible anywhere. It is important to indicate that the reported videos are not delivered directly to the authorities since the communication route to the recipient may not be available; that is, the official vehicle is not reachable via multihop communication. The scheme assumes the availability of a reliable multipath routing algorithm (such as [12]) to find stable routes to the Cloud Platform. In addition, it is assumed that vehicles use the 5G communication technology to access the Cloud Platform.Trusted Authority (TA). This is the entity that manages the pseudonymous certificates, certificates and secret keys of participating vehicles and official vehicles. The Eiza-Ni-Shi Scheme assumes that TA is secure and it is trusted by all the other entities of the 5G enabled vehicular network system.Department of Motor Vehicles (DMV). All vehicles are registered periodically in the DMV. Besides the traditional identifier of the vehicle,that is, Electronic License Plate or Electronic Chassis Number, each vehicle is assumed to have a unique but not fixed 5G identifier. It means the 5G identified can be modified in each inspection of the vehicle by DMV.Law Enforcement Agency (LEA). LEA is integrated part of the system since the reported information, that is, coordinate of accident and video of the accident, is very sensitive information.Participant Vehicles. These are those vehicles that are participating in the cloud-assisted video reporting service. Special equipment (a small computer with video camera, sensors, and 5G communication) is installed in the participant vehicles. The vehicles will record the video and such video will be uploaded to the Cloud Platform when an accident is detected.Official Vehicles. Official Vehicles are those vehicles that are designated and authorized to respond to a traffic accident (e.g., police vehicle or ambulance). These vehicles are usually operated by designated agencies part of the government but also sometimes run by nongovernmental organizations and some private companies.The Eiza-Ni-Shi Scheme proposes a protocol composed of 4 phases called (1) system initialization, (2) participants and official vehicles registration, (3) video transmission, and (4) video receipt/retrieval. The notations used in Eiza-Ni-Shi Scheme are detailed in (i) in the Notations.


### 3.1.1. System Initialization

The trusted authority (TA) manages a specific area that could be a state, province, or district. The TA chooses a validity period threshold of a pseudonymous certificateΔT and estimates the number of pseudonymous certificates that a vehicle needs to acquire. It is assumed that the issued pseudonymous certificates (stored in each vehicle) cannot be used to impersonate other vehicles because each certificate has a specific validity period and the number of certificates is relatively small.


### 3.1.2. Participants and Official Vehicles Registration

The participant vehicles are registered executing the following steps.Step  1. During the vehicles’ annual inspection, the user indicates his/her disposition to use the service. Then, the vehicle registers its identity Cv, unique 5G identity 5G_ID, and PKEPpub,Sr with the Department of Motor Vehicles (DMV), where Sr is a random symmetric key sr∈Z∗q, Ppub is TA’s public key, and PKE(·) is an asymmetric encryption function.Step  2. The DMV registers the data of the participant vehicle in its database and forwards 5G_ID,PKEPpub,Sr to the TA requesting the issue of pseudonymous certificates for the vehicle.Step  3. Upon receiving the request from DMV, the TA creates a set of pseudonymous certificates PCertTA,5G_ID,j, a set of private keys SK5G_ID,j, a policy,Policy = {“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}, and a tag U∈Z∗q, and delivers them to the DMV by sending SEnc(Sr,(SK5G_ID,j,PCertTA,5G_ID,j, PKABE,Policy,U)), where SEnc· is an symmetric encryption function and PKABE is the public key used to encrypt a one-time random encryption key Skey underPolicy using CP-ABE [11]. The tag U is a preagreed value between the TA and the Cloud Platform; such value is used by Cv to tag the traffic accident video when uploaded and it is used by the Cloud Platform to recognize the space to store the received video and to notify the registered official vehicles.Step  4. The DMV forwards the received information to the vehicle. It is important to note that DMV only manages the mapping between the vehicle’s 5G_ID and its real identity Cv and it does not know the issued pseudonymous credentials. On the other hand, the TA manages the mapping between the 5G_ID identity and the corresponding pseudonyms without knowledge of vehicles real identity Cv. This separation of responsibilities creates a more secure environment. Upon receiving the data from DMV, the participating vehicle stores the received information into a tamper-proof device (TPD) that it is equipped with [13, 14].On the other side, designated official vehicles are registered to receive the notification of reported traffic accident videos. The official vehicles registration is executed with following steps.Steps  5 and 6. A designated official vehicle DVi sends a registration request to the TA via the Law Enforcement Agency (LEA).Steps  7 and 8. After verifying the request, the TA generates and delivers the certificate CertTA,DVi to DVi and uses the MKABE to create a decryption key dkAS associated with a set of attributes such as AS={“police vehicle”, “ambulance”, “traffic law enforcement”, “traffic authority”}. The attributes will change depending on the type of the official vehicle. The confidential information generated by TA is then delivered to the DVi’s tamper-proof device via LEA.Step  9. DVi uses the data received in previous step to register with the Cloud Platform.


### 3.1.3. Video Transmission

This phase is executed when an accident occurs to the participant vehicle. This phase is executed as follows.Step  10. The participating vehicle Cv generates a random one-time symmetric key Skey and executes EncC=SEncSkey,TVr to encrypt the accident video report TVr.Step  11. Cv reads the public key of the recipient R (PKR) and executes SPEKS=PEKSPKR,kw to generate a searchable encryption of the keywords kw={“accident video report”, location, date and time}.Step  12. Cv encrypts Skey using the CP-ABE function under Policy as follows: ABEC=ABE.EncPKABE,Skey,Policy to allow only official vehicles having dkAS withPolicy to access ABEC and obtain Skey.Step  13. Using the selected pseudonymous certificate, Cv executes σ5G_ID,j=Sign(SK5G_ID,j,h(EncC∥SPEKS∥ABEC∥hU)), where Sign(·) is the signing function, SK5G_ID,j is the Cv’s private key associated with the selected pseudonymous certificate, and “∥” denotes data concatenation.Step  14. Cv uploads {EncC,SPEKS,ABEC,hU,σ5G_ID,j, PCertTA,5G_ID,j} to the Cloud Platform over the 5G network.


### 3.1.4. Video Receipt/Retrieval

This phase is executed when the accident video is uploaded to the Cloud Platform. This phase is executed as follows.Step  15. First, the Cloud Platform verifies hU value and then notifies the accident to the nearest official vehicle DVi by sending EncC,SPEKS,ABEC,hU,σ5G_ID,j,PCertTA,5G_ID,j. The authors assume that the location information of the official vehicles is updated periodically in the cloud.Step  16. DVi verifies the received certificate PCertTA,5G_ID,j by executing VerifyPpub,PCertTA,5G_ID,j,σTA,5G_ID,j, where Verifiy· is a verification function. After verification of authenticity of PCertTA,5G_ID, DVi extracts the public key PK5G_ID,j from the pseudonymous certificate.Step  17. DVi verifies σ5G_ID,j by executing Verify(PK5G_ID,j,hEncC∥SPEKS∥ABEC∥hU,σ5G_ID,j).Step  18. After verification of authenticity of σ5G_ID,j, DVi executes Skey=ABE.DecABEC,dkAS to get the one-time symmetric encryption key, where ABE.Dec· is the CP-ABE decryption function.Step  19. DVi executes TVr=SDecSkey,EncC and gets the traffic accident video, where SDec· is a symmetric decryption function.In the Eiza-Ni-Shi Scheme, the encrypted videos are stored on the Cloud Platform to allow access whenever they are needed. In other words, LEA can search for the traffic accident videos on the cloud at any moment.Step  20. LEA generates the searchable trapdoor token Tkwi as follows: Tkwi=TrapdoorSKR,kwi, where keyword kwi can be a location, a date, or just “accident video report.”Step  21. LEA sends the generated Tkwi to the Cloud Platform. The authors assume that there is a secure channel between LEA and Cloud Platform.Step  22. The receipt of Tkwi authorizes the search process over the ciphertext at the cloud.Step  23. LEA receives the message EncC,SPEKS,ABEC,hU,σ5G_ID,j,PCertTA,5G_ID,j. Finally, LEA uses the same procedure to receive the video file TVr.


## 3.1.1. System Initialization

The trusted authority (TA) manages a specific area that could be a state, province, or district. The TA chooses a validity period threshold of a pseudonymous certificateΔT and estimates the number of pseudonymous certificates that a vehicle needs to acquire. It is assumed that the issued pseudonymous certificates (stored in each vehicle) cannot be used to impersonate other vehicles because each certificate has a specific validity period and the number of certificates is relatively small.


## 3.1.2. Participants and Official Vehicles Registration

The participant vehicles are registered executing the following steps.Step  1. During the vehicles’ annual inspection, the user indicates his/her disposition to use the service. Then, the vehicle registers its identity Cv, unique 5G identity 5G_ID, and PKEPpub,Sr with the Department of Motor Vehicles (DMV), where Sr is a random symmetric key sr∈Z∗q, Ppub is TA’s public key, and PKE(·) is an asymmetric encryption function.Step  2. The DMV registers the data of the participant vehicle in its database and forwards 5G_ID,PKEPpub,Sr to the TA requesting the issue of pseudonymous certificates for the vehicle.Step  3. Upon receiving the request from DMV, the TA creates a set of pseudonymous certificates PCertTA,5G_ID,j, a set of private keys SK5G_ID,j, a policy,Policy = {“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}, and a tag U∈Z∗q, and delivers them to the DMV by sending SEnc(Sr,(SK5G_ID,j,PCertTA,5G_ID,j, PKABE,Policy,U)), where SEnc· is an symmetric encryption function and PKABE is the public key used to encrypt a one-time random encryption key Skey underPolicy using CP-ABE [11]. The tag U is a preagreed value between the TA and the Cloud Platform; such value is used by Cv to tag the traffic accident video when uploaded and it is used by the Cloud Platform to recognize the space to store the received video and to notify the registered official vehicles.Step  4. The DMV forwards the received information to the vehicle. It is important to note that DMV only manages the mapping between the vehicle’s 5G_ID and its real identity Cv and it does not know the issued pseudonymous credentials. On the other hand, the TA manages the mapping between the 5G_ID identity and the corresponding pseudonyms without knowledge of vehicles real identity Cv. This separation of responsibilities creates a more secure environment. Upon receiving the data from DMV, the participating vehicle stores the received information into a tamper-proof device (TPD) that it is equipped with [13, 14].On the other side, designated official vehicles are registered to receive the notification of reported traffic accident videos. The official vehicles registration is executed with following steps.Steps  5 and 6. A designated official vehicle DVi sends a registration request to the TA via the Law Enforcement Agency (LEA).Steps  7 and 8. After verifying the request, the TA generates and delivers the certificate CertTA,DVi to DVi and uses the MKABE to create a decryption key dkAS associated with a set of attributes such as AS={“police vehicle”, “ambulance”, “traffic law enforcement”, “traffic authority”}. The attributes will change depending on the type of the official vehicle. The confidential information generated by TA is then delivered to the DVi’s tamper-proof device via LEA.Step  9. DVi uses the data received in previous step to register with the Cloud Platform.


## 3.1.3. Video Transmission

This phase is executed when an accident occurs to the participant vehicle. This phase is executed as follows.Step  10. The participating vehicle Cv generates a random one-time symmetric key Skey and executes EncC=SEncSkey,TVr to encrypt the accident video report TVr.Step  11. Cv reads the public key of the recipient R (PKR) and executes SPEKS=PEKSPKR,kw to generate a searchable encryption of the keywords kw={“accident video report”, location, date and time}.Step  12. Cv encrypts Skey using the CP-ABE function under Policy as follows: ABEC=ABE.EncPKABE,Skey,Policy to allow only official vehicles having dkAS withPolicy to access ABEC and obtain Skey.Step  13. Using the selected pseudonymous certificate, Cv executes σ5G_ID,j=Sign(SK5G_ID,j,h(EncC∥SPEKS∥ABEC∥hU)), where Sign(·) is the signing function, SK5G_ID,j is the Cv’s private key associated with the selected pseudonymous certificate, and “∥” denotes data concatenation.Step  14. Cv uploads {EncC,SPEKS,ABEC,hU,σ5G_ID,j, PCertTA,5G_ID,j} to the Cloud Platform over the 5G network.


## 3.1.4. Video Receipt/Retrieval

This phase is executed when the accident video is uploaded to the Cloud Platform. This phase is executed as follows.Step  15. First, the Cloud Platform verifies hU value and then notifies the accident to the nearest official vehicle DVi by sending EncC,SPEKS,ABEC,hU,σ5G_ID,j,PCertTA,5G_ID,j. The authors assume that the location information of the official vehicles is updated periodically in the cloud.Step  16. DVi verifies the received certificate PCertTA,5G_ID,j by executing VerifyPpub,PCertTA,5G_ID,j,σTA,5G_ID,j, where Verifiy· is a verification function. After verification of authenticity of PCertTA,5G_ID, DVi extracts the public key PK5G_ID,j from the pseudonymous certificate.Step  17. DVi verifies σ5G_ID,j by executing Verify(PK5G_ID,j,hEncC∥SPEKS∥ABEC∥hU,σ5G_ID,j).Step  18. After verification of authenticity of σ5G_ID,j, DVi executes Skey=ABE.DecABEC,dkAS to get the one-time symmetric encryption key, where ABE.Dec· is the CP-ABE decryption function.Step  19. DVi executes TVr=SDecSkey,EncC and gets the traffic accident video, where SDec· is a symmetric decryption function.In the Eiza-Ni-Shi Scheme, the encrypted videos are stored on the Cloud Platform to allow access whenever they are needed. In other words, LEA can search for the traffic accident videos on the cloud at any moment.Step  20. LEA generates the searchable trapdoor token Tkwi as follows: Tkwi=TrapdoorSKR,kwi, where keyword kwi can be a location, a date, or just “accident video report.”Step  21. LEA sends the generated Tkwi to the Cloud Platform. The authors assume that there is a secure channel between LEA and Cloud Platform.Step  22. The receipt of Tkwi authorizes the search process over the ciphertext at the cloud.Step  23. LEA receives the message EncC,SPEKS,ABEC,hU,σ5G_ID,j,PCertTA,5G_ID,j. Finally, LEA uses the same procedure to receive the video file TVr.


## 3.2. Cryptanalysis and Functionality Analysis of Eiza-Ni-Shi Scheme

This section makes an analysis of the Eiza-Ni-Shi Scheme and shows how it has several security vulnerabilities and a critical functionality limitation.No Management of Multiple Trusted Authorities. First of all, one of the main limitations of the Eiza-Ni-Shi Scheme is the lack of a mechanism that covers different geographic/administrative regions of vehicular networks. This limitation is mentioned also by the same authors of Eiza-Ni-Shi Scheme and it is left for future work. In most of countries in the world, the control of motorized vehicles is done per different geographic/administrative regions delegating those responsibilities to regional authorities (e.g., state authorities). For this reason, it is necessary to consider a real world scenario with multiples TAs, DMVs, and LEAs connected to its own Cloud Platforms.DMV Impersonation Attack. The adversary Ua can execute the DMV impersonation attack with the following steps. Since the 5G_ID is not a fixed value and it is not verified by the TA, Ua can generate any random value as 5G_ID. Once 5G_ID is generated, Ua will generate a random symmetric key Sr and will send a registration message request5G_ID,PKEPpub,Sr to the TA. Since the 5G_ID is not a fixed value and it is not verified, TA will process the request and it will return the SEncSr,SK5G_ID,j,PCertTA,5G_ID,j,PKABE,Policy,U message. Since Sr was generated by Ua, he/she will be able to obtain the tuple SK5G_ID,j,PCertTA,5G_ID,j,PKABE,Policy,U.Forged Video Upload. By executing the DMV impersonation attack, Ua can obtain the valid private keys SK5G_ID,j, pseudonymous certificates PCertTA,5G_ID,j, PKABE, Policy, and U. With these values, the adversary can simulate a traffic accident by uploading a false video.Nonseparation of Responsibilities between LEA and TA. Eiza-Ni-Shi Scheme separates the responsibilities between DMV and TA. However, it does not separate the responsibilities between LEA and TA. Following the same reasoning of separation of responsibilities between DMV and TA, the mapping between the official vehicle real identity DVi and its 5G_ID should be managed only by LEA and not by TA.Privileged Insider Attack in LEA. Since LEA receives CertTA,DVi and dkAS of each official vehicle in plaintext, the privileged insider of LEA could store such values. Therefore, privileged insider could access every traffic accident video impersonating official vehicles.LEA Impersonation Attack. Since the 5G_ID is not a fixed value and it is not verified by the TA, Ua can generate any random value as 5G_ID. Once 5G_ID is generated, Ua will generate a random symmetric key Sr and will send a registration request message requestDVi,5G_ID to the TA. Since the DVi,5G_ID tuple is not verified by TA, TA will process the request and it will return CertTA,DVi and dkAS message.Exposure of Location of Official Vehicles. The authors of Eiza-Ni-Shi Scheme assume that the location data of official vehicles are delivered periodically to the Cloud Platform in plaintext. The exposure of such data (e.g., localization of police vehicles) could be a critical problem since criminals could use such information to perform illegal activities. The authors of Eiza-Ni-Shi Scheme admit this limitation in their paper and propose a solution for it as a future work.


## 4. 5G-VRSec: The Proposed Secure Video Reporting Service in 5G Enabled Vehicular Networks

This section describes the details of the proposed solution. The proposed scheme eliminates the security flaws shown in previous section and incorporates the concept of different geographic/administrative regions involving several TAs, DMVs, LEAs, and Cloud Platforms (see Figure2).


### 4.1. System Model

The proposed scheme uses the 5G mobile network as the foundational communication technology. 5G technology was selected for the vehicular network because of its high speed and capacity required to upload and download the traffic accident videos in real time.Figure2 shows the proposed multiregional and multitier 5G enabled vehicular network. The proposed scheme makes the management of different geographic/administrative regions responding to the real world needs possible. Since most of the countries in the world control the motorized vehicles through regional authorities (e.g., state authorities), the proposed scheme assumes a more realistic world scenario with multiple TAs, DMVs, and LEAs connected to its own Cloud Platform. In other words, the proposed scheme provides a solution to the limitation left as future work in [7].Each geographical or administrative region is composed of its own Department of Motor Vehicles (DMV), trusted authority (TA), Law Enforcement Agency (LEA), Cloud Platform, and vehicles (participating vehicles and official vehicles). Since the proposed solution allows multiple geographical or administrative regions, there are additional considerations to bear in mind: (1) The implementation of the Cloud Platform can be unique for the complete system (nationwide), or it can be independent for each geographic/administrative region; it will depend on local laws and regulations. Obviously, since the Cloud Platform is connected to the Internet, a Cloud Platform of a region will be accessible from other regions. And (2) the proposed scheme assumes that TA is secure and it is trusted by all the other entities of the 5G enabled vehicular network system of the same geographical/administrative region. Additionally, we assume that a TA of a region is trusted by other TAs located in other geographical/administrative regions.


### 4.2. Design Criteria: System Considerations and Assumptions

This section describes the security criteria and assumptions used in designing the proposed scheme.Confidentiality and Integrity. Messages containing secret data transmitted and received by entities must be protected from malicious users. Additionally, unauthorized alterations of confidential data must be identified by the proposed service.Protection against Untrusted Communications. The communication among TAs, DMVs, and LEAs (messages coming from the mentioned entities) is not fully trusted since privileged insider attack could be executed. Therefore, the protection of confidential messages using cryptographic algorithms is necessary.Insecure Channels. Most of communication channels are considered insecure. This means that sniffing and spoofing of messages can occur in such channels. The following communication channels are considered insecure.(i)
The communication channel betweenDVi and Cloud Platform is not secure.(ii)
The communication channel betweenDVi and LEA is not secure.(iii)
The communication channel betweenCv and TA is not secure.(iv)
The communication channel betweenCv and Cloud Platform is not secure.(v)
The communication channel between LEA and Cloud Platform is not secure.(vi)
The communication channel between TA and ATA is not secure.Secure Channel. Only one communication channel is considered secure, that is, communication between Cv and DMV. The mentioned communication channel is considered secure because the communication is executed face to face. It means that the owner of Cv must visit the DMV’s office to register his vehicle.Trusted Entities. The servers managed by different entities, that is, DMVs, LEAs, TAs, and Cloud Platforms, are managed by trusted service providers. Therefore, such infrastructures are considered secure, and their security is not considered as part of this paper.Authentication and Nonrepudiation. Each participating vehicle Cv must authenticate to the Cloud Platform to upload the reporting video, and it cannot repudiate later the execution of video uploading process.Cryptographic Keys. We assume that each entity, that is, TA, DMV, LEA, and Cloud Platform, has its own asymmetric key pair and they are administered securely using existing algorithms.Security against Common Attacks. The proposed solution must be strong against the most common attacks such as replay attack, privileged insider attack, impersonation attack, and message sniffing/spoofing.Secure Storage. The proposed scheme assumes that the participating vehicles Cv and designated official vehicles DVi have a tamper-proof device for storage and management of confidential data (e.g., keys and pseudonymous certificates). Security technologies such as TrustZone by ARM [13] and Secure RAM by Freescale [14] could be possible solutions for the mentioned tamper-proof devices.Separation of Responsibilities among DMV, LEA, and TA. Even though DMV, LEA, andTA are trusted entities, it is important to make a separation of responsibilities making each of the entities see and store information related to its jurisdiction. The separation of responsibilities increases the level of security and privacy of users.


### 4.3. Protocols

The proposed scheme includes eight different phases called (1) system initialization, (2) participant vehicles registration, (3) official vehicles registration, (4) participation vehicle handover, (5) video transmission, (6) video search, (7) Pseudo-Certificate Revocation, and (8) interregion certificate revocation. The notations used in the proposed protocol differ a little bit from the ones used in Eiza-Ni-Shi Scheme since the proposed scheme covers wider functionalities and requires new notations. The mentioned notations are detailed in (ii) in the Notations.


#### 4.3.1. System Initialization

In the proposed system, each trusted authority (TA) manages a certain geographic/administrative regional area (e.g., a state, province, or district). All the trusted authorities share the sameΔT, which indicates the validity period threshold of a pseudonymous certificate issued to a participating vehicle. It is important to notice that having the same ΔT in each trusted authority does not mean synchronization among those entities; it just means that all TAs must store the same value of ΔT as a constant when the service is implemented. Since the value of ΔT is defined as a governmental regulation for this service, the value of ΔT is not modified after implementation. If the governmental regulation for the services is modified, the TA’s administrator must modify manually the value of ΔT. On the other hand, it is important to remember that each pseudonymous certificate is usable only once and it has an expiration time which is equal to LastPCertTimeCv+ΔT, where LastPCertTimeCv is the last time where a pseudonymous certificate of a specific participating vehicle Cv was used.Since each pseudonymous certificate has an expiration time, the TA must estimate the number of certificates to be issued to eachCv. We also think it is a good idea to issue enough pseudonymous certificates for a year, until the next vehicle inspection. For example, if ΔT=1 hour, the number of pseudonymous certificates required for a Cv during a year will be 24×365=8760. Considering that the certificate size is 66 bytes (as indicated in Section 2), the total amount of space required will be approximately 565 KB, which is a reasonable overhead in terms of storage. As mentioned in Section 4.2., we assume that each Cv has a tamper-proof device for storage and management of confidential data (e.g., keys and pseudonymous certificates).


#### 4.3.2. Participant Vehicle Registration Protocol

This protocol is executed during the annual vehicle inspection or whenever a user expresses his/her willingness to participate in the video reporting service. This protocol is composed of the following steps (see Figure3).Figure 3
Participating and Official Vehicle Registrations.A participant vehicle generates a random symmetric keysr1∈Z∗q and sends {Cv,5G_IDCv,PKEPKTA,Sr1} to the Department of Motor Vehicles (DMV), where Cv is the unique identification of the participating vehicle, 5G_IDCv is the 5G identification of the vehicle, PKTA is the public key of the trusted authority (TA) of the region which the participant vehicle is part of, and PKEx,y is the public key encryption function of message y using key x.Once the message is received, DMV verifies physically the correctness of theCv, then gets its current timestamp TS′, and creates the message M1=5G_IDCv,TS′,PKEPKTA,Sr1. Upon generation of M1, DMV signs M1 using its private key SKDMV by executing σM1=SignSKDMV,M1. Finally, DMV sends M1 and σM1 to TA.Upon receiving the message, TA verifies the freshness of the message by checking the fulfillment ofTS′′-TS′≤ΔTS, where TS′′ is the current timestamp of TA and ΔTS is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature σM1 as follows: Verify(PKDMV,M1,σM1). After signature verification, TA obtains Sr1 by executing PKDSKTA,PKEPKTA,Sr1 and then generates the set of private keys SKTA,5G_IDCvj and a set of pseudonymous certificates PCertTA,5G_IDCvj corresponding to 5G_IDCv, where PKDx,y is the public key decryption function of message y using key x. After that, TA returns the message M2 = {TS′′′,SEnc(Sr1,({SKTA,5G_IDCvj},{PCertTA,5G_IDCvj}, PKR(TA),PKABE(TA),Policy,IPCloud(TA),UCloud(TA), RegTA,TS′′′))} to DMV, where PKR(TA) is the public key of TA for Public Key Encryption with Keyword Search, PKABE(TA) is the public key of TA for the Attributed Based Encryption,Policy is the access policy of traffic accident videos uploaded by Cv (e.g., Policy={“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), IPCloud(TA) is the IP address of the Cloud Platform of TA, UCloud(TA)∈Z∗q is the a tag preagreed upon between TA and the Cloud Platform of TA (CloudTA), RegTA is the coordinate representing the geographical region controlled by TA, and TS′′′ is the current timestamp of TA.R
e
g
T
A is used for the handover process when Cv crosses to another geographical region controlled by another trusted authority (e.g., different states, districts, or cities). This process is explained later in the handover protocol section.DMV, once the message is received from TA, forwards it to the participating vehicle. Finally,Cv verifies the validity of TS′′′, then decrypts the received message using Sr1, and stores the decrypted values into its tamper-proof device.It is important to note that the DMV only sends5G_IDCv to the TA. This means that the relation between Cv and 5G_IDCv is kept only at the DMV. This will offer the feature of role separation, and consequently, more protection for the real identity of the participating vehicle, since 5G_IDCv is not a fixed value changeable during the next inspection/registration event.


#### 4.3.3. Official Vehicle Registration Protocol

Figure3 illustrates both Participation Vehicles Registration and Official Vehicle Registration protocols, but the protocols are executed independently in different time.The official vehicles are also registered for this service to ensure that only authentic official vehicles will receive the notification of a traffic accident video (see Figure3). The official designated vehicle generates a random symmetric key Sr2∈Z∗q and sends {DVi,5G_IDDVi,PKEPKTA,Sr2} to the Law Enforcement Agency (LEA), where DVi is the unique identification of the official designated vehicle, 5G_IDDVi is the 5G identification corresponding to DVi, and PKTA is the public key of the trusted authority (TA) of the region which Cv and DVi are part of.Once the message is received, LEA verifies physically the correctness ofDVi, gets its attribute(s), AttributeDVi (e.g., “police vehicle,” “ambulance,” “traffic authority,” or “traffic law enforcement”), and generates the message M3=5G_IDDVi,TS2′,AttributeDVi,PKEPKTA,Sr2 and σM3=SignSKLEA,M3, where TS2′ is the current timestamp of LEA, SKLEA is the private key of LEA, and Signx,y is a digital signing of a message y using a private key x. Upon generating the messages, LEA sends M3 and σM3 to TA.After receiving the message, TA verifies the freshness of the message by checking the fulfillment ofTS2′′-TS2′≤DTS, where TS′′ is the current timestamp of TA and ΔTS is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature σM3 as follows: Verify(PKLEA,M3,σM3). After signature verification, TA obtains Sr2 by executing PKDSKTA,PKEPKTA,Sr2 and then generates the Attribute Based Encryption Private Key for DVi as follows: SKABE(TA,DVi)=ABE.DelegateMKTA,AttributeDVi. TA also generates a certificate CertTA,5G_IDDVi for DVi based on 5G_IDDVi and includes it into a message M4={T2′′′,SEnc(Sr2,CertTA,5G_IDDVi,SKABEDVi,T2′′′, IPCloud(TA))}, to finally send it to LEA. LEA receives M4 and forwards it to DVi.Upon receivingM4, DVi verifies the freshness of the message using ΔTS and decrypts M4 by executing SDecSr2,M4. Once decrypting M4, DVi compares the decrypted T2′′′ with the T2′′′ value received in plaintext to double verify the authenticity and freshness of the message. Finally, DVi stores the decrypted values into its tamper-proof device.Now, once registered with TA and LEA, it is time to execute the registration with the Cloud Platform. For this,DVi sends an registration request message to CloudTA. Once receiving the request, the Cloud Platform generates a random nonce N1 and transmits it to DVi. Upon receiving N1, DVi generates a random symmetric key Sr3 and a random nonce N2, calculates M5=PKEPKCloudTA,Sr3 and M6=SEncSr3,N1,N2,CertTA,5G_IDDVi, and sends {M5,M6} to CloudTA. The Cloud Platform then obtains Sr3 by executing PKDSKCloudTA,M5 and uses such value to obtain N1′,N2′,CertTA,5G_IDDVi=SDecSr3,M6. Once with N1′, CloudTA verifies the freshness of the message comparing the decrypted nonce N1′ with the one generated previously, N1, only if those values matching DVi are registered to the Cloud Platform. Closing the registration process, CloudTA registers CertTA,5G_IDDVi in its database and sends the decrypted N2′ to DVi to confirm its registration. Finally, DVi verifies the confirmation message by comparing the received N2′ with the previously generated N2.It is important to clarify that the communication betweenDVi and CloudTA uses random nonces to validate the freshness of messages instead of timestamps. This is because it is hard to maintain the clock of DVi and CloudTA synchronized. Timestamps are only used among LEA, DMV, and TA since they are trusted entities which can coordinate a reliable clock synchronization.


#### 4.3.4. Handover Protocol

The proposed scheme solves the limitation of Eiza-Ni-Shi Scheme regarding the lack of contemplation of different regional areas that are under the management of different trusted authorities. The proposed scheme contributes with a novel handover protocol executed when a participating vehicleCv goes to a different regional area with another trusted authority.In Participating Vehicle Registration Protocol,Cv received RegTA which contains the coordinate of the geographical region controlled by TA. Such value is used to verify when handover is required. For this, Cv checks periodically its GPS coordinate with RegTA; when CoordinateCv∉RegTA, it initiates the handover protocol composed of the following steps (see Figure 4).Figure 4
Proposed handover protocol.First,Cv sends a handover request to TA. The TA then generates a random nonce N3 and sends it to Cv. Upon receiving the random nonce, Cv generates its own random nonce N4 and a random symmetric key Sr4 and calculates M7={PKEPKTA,Sr4,SEnc(Sr4,(N3,N4,5G_IDCv, CoordinateCv))} and σM7=Sign(SK5G_IDCvj,M7). Once calculating such values, Cv sends (M7,σM7,PCertTA,5G_IDCvj) to its trusted authority (TA), where PCertTA,5G_IDCvj is the first not used pseudo-certificate valid at current time. Once receiving the message, TA verifies the authenticity of σM7 and origin of PCertTA,5G_IDCvj by executing VerifySignPKTA,PCertTA,5G_IDCvj,σM7. TA also verifies if σM7 corresponds to the digital signature of M7 by performing VerifyPKTA,5G_IDCvj,M7,σM7. Once the authenticity of messages is verified, TA gets Sr4 by PKDSKTA,PKEPKTA,Sr4 and uses it to obtain N3′,N4′,5G_IDCv,CoordinateCv = SDec(Sr4,SEnc(Sr4,(N3,N4,5G_IDCv, CoordinateCv))). Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted N3′ with the previously generated N3. The nonce comparison allows TA to eliminate all possibilities of replay attacks from adversaries. Once the validity of handover request is verified, TA searches the away trusted authority (ATA) that controls the region where Cv currently is located.Once the adequate ATA is detected, TA mediates the registration ofCv in ATA. For this, TA requests a temporal registration of Cv to ATA. Upon receiving the request, ATA generates a random nonce N5 and sends it to TA. Once the connection with ATA is realized, TA generates a random nonce N6 and a random symmetric key Sr5 and calculates M8=PKEPKATA,Sr5,SEncSr5,N5,N6,5G_IDCv and σM8=SignSKTA,M8. Once the messages are calculated, TA sends M8,σM8 to ATA.Once receiving the message, ATA verifies the authenticity of the received signatureσM8 as follows: Verify(PKTA,M8,σM8). Upon signature verification, ATA obtains Sr5 by executing PKDSKATA,PKEPKATA,Sr5 and uses such value to get N5′,N6′,5G_IDCv = SDecSr5,SEncSr5,N5,N6,5G_IDCv. Later, ATA verifies the freshness of the message comparing the decrypted nonce N5′ with the previously generated N5. Only if those values match, ATA proceeds to respond to the registration request. Closing the temporal registration process, ATA generates the set of private keys SKATA,5G_IDCvj and a set of pseudonymous certificates PCertATA,5G_IDCvj corresponding to 5G_IDCv of Cv. After that, ATA returns the message M9 = SEnc(Sr5,({SKATA,5G_IDCvj}, {PCertATA,5G_IDCvj},PKR(ATA),PKABE(ATA),PolicyATA, IPCloud(ATA),UCloud(ATA),RegATA,N6′)) to TA, where PKR(ATA) is the public key of ATA for Public Key Encryption with Keyword Search, PKABE(ATA) is the public key of ATA for the Attributed Based Encryption, PolicyATA is the access policy of traffic accident videos uploaded by Cv (e.g., PolicyATA={“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), IPCloud(ATA) is the IP address of the Cloud Platform of ATA, UCloud(ATA)∈Z∗q is the a tag preagreed upon between ATA and the Cloud Platform of ATA (CloudATA), and RegATA is the coordinate representing the geographical region controlled by ATA.Upon receiving the response from ATA, TA decryptsM9 using its random key Sr5. Once decrypting M9, TA verifies the authenticity of M9 by comparing N6′ with its own N6. This comparison allows TA to be sure that M9 came from the valid ATA. After verification, TA stores the decrypted values for historical data of Cv (only if required) and generates a new message M10 = SEnc(Sr4,({SKATA,5G_IDCvj},{PCertATA,5G_IDCvk}, PKR(ATA),PKABE(ATA),PolicyATA,IPCloud(ATA), UCloud(ATA),RegATA,N4′)) and sends it to Cv.Upon receiving the message,Cv decrypts M10 and verifies that the message came from the authentic TA freshly by comparing N4′ with N4. After verification Cv stores the decrypted values to its tamper-proof device.Note. Since the trusted authorities are in different regional areas and as it is hard to have clock synchronization, handshake using random nonces is used instead of timestamps to avoid replay attacks.


#### 4.3.5. Video Transmission Protocol

When an accident occurs,Cv obtains the recorded video file through its cameras and initiates the video transmission protocol, which is composed of the following steps (see Figure 5).Figure 5
Video transmission and video search protocols.First,Cv generates a random symmetric key Sr6 and uses it to encrypt the video file TVr and its current GPS coordinate CoordinateCv as follows: ETVr=SEnc(Sr6,(TVr,CoordinateCv)). Then, Cv generates the keywords related to the accident kw and encrypts it using the Public Key Encryption with Keyword Search function as Ekw=PEKSPKR(TA),kw and calculates ESr6=ABE.EncPKABE(TA),Sr6,Policy. Additionally, Cv encrypts Sr6 using the Attribute Based Encryption function using PKABE(TA) andPolicy and creates a digital signature σ5G_IDCvj of generated messages using its current private key SKTA,5G_IDCvj. Finally, Cv clusters the generated messages into M11={hUCloud(TA),ETVr,Ekw,ESr6,σ5G_IDCvj, PCertTA,5G_IDCvj} and sends it to CloudTA over the 5G enabled vehicular network.Upon receivingM11, CloudTA checks if PCertTA,5G_IDCvj is in the Pseudo-Certificate Revocation List, PCRLCloud(TA), or in the Used Pseudo-Certificate List, UPCLCloud(TA), which is the list of the already used pseudo-certificates. It is important to remember that a pseudo-certificate is usable only once. If such pseudo-certificate is in PCRLCloud(TA) or UPCLCloud(TA), the received M11 is discarded; otherwise, CloudTA verifies the authenticity of the message by executing VerifySign(PKTA,PCertTA,5G_IDCvj,σ5G_IDCvj). If the certificate is proved to be valid, CloudTA stores such message and notifies the nearest designated vehicle DVi about the accident sending M11. We assume that the location information of the official vehicles is updated periodically in the cloud. The location of official vehicles is protected since it is transmitted using the public key of CloudTA  PKCloudTA.Once an official vehicleDVi receives the notification, it verifies the received pseudonymous certificate PCertTA,5G_IDCvj by executing VerifySign(PKTA,PCertTA,5G_IDCvj,σ5G_IDCvj). If the certificate is proved to be valid, DVi extracts the public key PKTA,5G_IDCvj of the sender from the certificate PCertTA,5G_IDCvj. Upon certificate validation, DVi verifies the received signature σ5G_IDCvj by executing Verify(PKTA,5G_IDCvj, (h(UCloud(TA)),ETVr,Ekw,ESr6),σ5G_IDCvj) and obtains the Sr6 using its Attributed Based Encryption private key SKABE(TA,DVi) as follows: Sr6=ABE.DecESr6,SKABE(TA,DVi). Finally, DVi gets the decrypted video and the last coordinate of Cv by executing (TVr,CoordinateCv)=SDec(Sr6,ETVr). Now, the official vehicles are able to go to the location of the accident using CoordinateCv and they can check the video of the accident while going to the location.


#### 4.3.6. Video Search Protocol

Once the video transmission protocol is done and the video is uploaded to the Cloud Platform, it can be retrieved by LEA whenever it is needed. The video search protocol is executed as follows (see Figure5).First, LEA initiates a video search request toCloudTA. Then, CloudTA generates a random nonce N7 and sends it to LEA. Once receiving the response of CloudTA, LEA generates another random nonce N8 and a random symmetric key Sr7 and then generates the searchable trapdoor token as follows: Tkwi=TrapdoorSKR(TA),kwi, where kwi is a keyword (e.g., location, date, or “any video”) related to the video. Upon generation of the search token, LEA generates a message M12=PKEPKCloudTA,Sr7,SEncSr7,N7,N8,Tkwi and its digital signature σM12=SignSKLEA,M12 and sends them to the CloudTA.On the other side,CloudTA verifies the validity of the digital signature σM12 by performing VerifyPKLEA,M12,σM12 to be sure that the search request comes from the authentic LEA. Once validating the authenticity of the message, the Cloud Platform extracts Sr7 by PKDSKCloudTA,PKEPKCloudTA,Sr7 and uses it to get N7′,N8′,Tkwi=SDecSr7,SEncSt7,N7,N8,Tkwi. Once obtaining the data, CloudTA verifies the freshness of the message by comparing the decrypted nonce N7′ with the previously generated N7. If those values match, CloudTA authorizes Tkwi search process over the ciphertext at the cloud and executes TestPKR(TA),Ekw,Tkwi. Once the video is founded, a new message M12={h(UCloudTA),ETVr,Ekw,ESr6, σ5G_IDCvj,PCertTA,5G_IDCvj,SEnc(Sr7,N8)} is generated and it is sent to the LEA.Upon receivingM12, LEA extracts N8′ by executing SDec(SEncSr7,N8′ and compares it with the previously generated N8 to validate the authenticity and freshness of the message. The comparison of random nonces allows LEA to verify the freshness since the received nonce corresponds to the last one created by itself. The nonce comparison also allows the verification of authenticity of CloudTA since the sent nonce can only be decrypted by the authentic CloudTA having the private key SKCloudTA.


#### 4.3.7. Pseudo-Certificate Revocation

This protocol is executed when a participating vehicleCv needs to stop its participation in the video reporting services, either because the user expressed his/her willingness to stop the service, because the car was robbed, or because the pseudo-certificates stored in the car have been exposed. This protocol is composed of the following steps (see Figure 6).Figure 6
Pseudo-Certificates Revocation Protocol.First, the owner of the participating vehicleOwnerCv indicates his/her willingness to stop the video reporting services to the DMV by delivering his/her identification IDOwnerCv (e.g., driver’s license). Once the request is received, the DMV verifies the authenticity of IDOwnerCv and gets Cv and 5G_IDCv corresponding to OwnerCv. Then, the DMV gets its current timestamp TS3′, generates a random nonce N9, and calculates M13=5G_IDCv,TS3′,PKEPKTA,N9 and σM13=SignSKDMV,M13. Once such values are calculated, DMV sends (M13,σM13) to the TA. Once the message is received, TA verifies the freshness of the message using its timestamp TS3′′ and verifies the authenticity of σM13 by executing VerifyPKDMV,M13,σM13. Once the authenticity of the message is verified, TA gets N9 by PKDSKTA,PKEPKTA,N9 and adds the pseudo-certificates belonging to 5G_IDCv to Cv’s Peudo-Certificate Revocation List, PCRLCv. Once PCRLCv is updated, DMV returns the decrypted N9′ to DVM. Finally, the DMV verifies the correct execution of the request by comparing the received message with the N9 generated by itself and then informs the OwnerCv about the correct execution of the requested process.On the other hand, the TA executes the Pseudo-Certificates Revocation process with the Cloud Platform. For this, the TA sends a request message toCloudTA. CloudTA then generates a random nonce N10 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce N11 and a random symmetric key Sr8 and calculates M14=PKEPKCloudTA,Sr8,SEncSr8,N10,N11,PCRLCv and σM14=Sign(SKTA,M14). Once such values are calculated, TA sends (M14,σM14) to its Cloud Platform. Once the message is received, CloudTA verifies the authenticity of the message by executing VerifyPKTA,M14,σM14. Once the authenticity of the message is verified, CloudTA gets Sr8 by PKDSKCloudTA,PKEPKCloudTA,Sr8 and uses it to obtain N10′,N11′,PCRLCv=SDecSr4,SEncSr8,N10,N11,PCRLCv. Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted N10′ with the previously generated N10. Once the validity of Pseudo-Certificates Revocation request is verified, CloudTA adds PCRLCv to the Pseudo-Certificates Revocation List of the Cloud Platform, PCRLCloud(TA). Once PCRLCloud(TA) is updated, CloudTA returns the decrypted N11′ to TA. Finally, the TA verifies the correct execution of the request by comparing the received message with the N11 generated by itself.Note. The Pseudo-Certificates Revocation Protocol can also be executed by a designated authority (e.g., police officer) when detecting a misbehaving Cv. In this case, the designated authority requests the Pseudo-Certificates Revocation to LEA instead of DMV. The following steps will be the same; the only difference is that the participating entities will be LEA–TA–CloudTA instead of DMV–TA–CloudTA.


#### 4.3.8. Interregion Pseudo-Certificate Revocation

This stage is executed after the Pseudo-Certificate Revocation Protocol, only if the participating vehicleCv has been in another region and received pseudo-certificates from an ATA. TA can know if Cv has been in another region since it was the intermediary executing the handover protocol. This protocol is composed of the following steps (see Figure 7).Figure 7
Interregion Pseudo-Certificates Revocation Protocol.First, TA sends a Pseudo-Certificates Revocation request to ATA whereCv has received pseudo-certificates. The ATA then generates a random nonce N12 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce N13 and a random symmetric key Sr9 and calculates M15={PKE(PKTA,Sr9), SEnc(Sr9,(N12,N13,5G_IDCv,PCRLCv))}, and σM15=Sign(SKTA,M15). Once such values are calculated, TA sends (M15,σM15) to ATA. Once the message is received, ATA verifies the authenticity of the message by executing VerifyPKTA,M15,σM15. After verification, ATA gets Sr9 by PKDSKTA,PKEPKTA,Sr9 and uses it to obtain N12′,N13′,5G_IDCv,PCRLCv = SDecSr9,SEncSr9,N12,N13,5G_IDCv,PCRLCv. Upon decrypting the data, ATA verifies the freshness of the message by comparing the decrypted N12′ with the previously generated N12. Once the validity of the request is verified, ATA adds the pseudo-certificates belonging to 5G_IDCv to Cv’s Pseudo-Certificate Revocation List, PCRLCv.On the other hand, the ATA also executes the Pseudo-Certificates Revocation process with the Cloud Platform. For this, the ATA sends a request message toCloudATA. CloudATA then generates a random nonce N14 and sends it to ATA. Upon receiving the random nonce, ATA generates its own random nonce N15 and a random symmetric key Sr10 and calculates M16={PKE(PKCloudATA,Sr10), SEnc(Sr10,(N14,N15,PCRLCv))}, and σM16=Sign(SKATA,M16). Once such values are calculated, ATA sends (M16,σM16) to its Cloud Platform. Once the message is received, CloudATA verifies the authenticity of the message by executing VerifyPKATA,M16,σM16. Once the authenticity of the message is verified, CloudATA gets Sr10 by PKDSKCloudATA,PKEPKCloudATA,Sr10 and uses it to obtain N14′,N15′,PCRLCv = SDecSr10,SEncSr10,N14,N15,PCRLCv. Upon decrypting the data, CloudATA verifies the freshness of the message by comparing the decrypted N14′ with the previously generated N14. Once the validity of Pseudo-Certificates Revocation request is verified, CloudATA adds PCRLCv to the Pseudo-Certificates Revocation List of the Cloud Platform PCRLCloud(ATA). Once PCRLCloud(ATA) is updated, CloudATA returns the decrypted N15′ to ATA. Finally, the ATA verifies the correct execution of the request by comparing the received message with the N15 generated by itself.


### 4.4. Security Analysis of the Proposed Solution

This section analyzes the proposed scheme in terms of security. It shows how the enhanced solution is secure against different attacks and it is superior to the previous work (see Table1).Table 1
Comparison of security and functionality features.
Feature
Eiza-Ni-Shi Scheme
Proposed scheme
Authentication and nonrepudiation
Yes
Yes
Conditional anonymity and privacy
Yes
Yes
Traceability
Yes
Yes
Management of multiple trusted authorities
No
Yes
Protection against DMV impersonation attack
No
Yes
Protection against forged video upload
No
Yes
Separation of responsibilities between LEA and TA
No
Yes
Protection against privileged insider attack in LEA
No
Yes
Protection against LEA impersonation attack
No
Yes
Exposure of location of official vehicles
No
Yes
Management of multiple TAs
No
YesAuthentication and Nonrepudiation. The proposed solution provides authentication and nonrepudiation of videos by using the fundaments of public key cryptography. The Cloud Platform can be sure that the video is uploaded by an authentic participant vehicle since Cv delivers its pseudonymous certificate PCertTA,5G_IDCvj. Such certificate can be validated by using the public key of the trusted authority which issued such certificate.Conditional Anonymity and Privacy. As well as in the previous work, the proposed solution provides conditional anonymity and privacy by using the pseudonymous authentication technique. Since the video is authenticated with the pseudonymous certificate, even if the Cloud Platform is compromised, the adversary Ua will not be able to know the real identity of the participating vehicle. Additionally, since each pseudonymous certificate is usable once and has an expiration time, it will be infeasible for Ua to correlate Cv with PCertTA,5G_IDCvj.DMV Impersonation Attack. DMV impersonation attack is avoided using the principles of public key cryptography. The participant vehicle registration request message M1 is accompanied with its digital signature σM1 signed by the private key of DMV. The TA can verify the origin of the message since it can verify the authenticity of σM1 using the public key of DMV PKDMV.Forged Video Upload. Thanks to the protection against the DMV impersonation attack, the adversary Ua cannot obtain the valid private keys, pseudonymous certificates. Therefore, forged video upload is not possible.Replay Attack. Replay attacks are avoided using timestamps or handshaking using random nonces. Lightweight timestamps technique is used in communications among DMV, TA, and LEA, since they are trusted entities that can easily have a synchronized clock. On the other hand, a handshaking using random nonces is used in communication between Cv and TA (in handover protocol), TA and ATA (in handover protocol), CloudTA and LEA (in video search protocol), and DVi and CloudTA (in Official Vehicle Registration protocol) since it is hard to have a synchronized clock between those entities.Nonseparation of Responsibilities between LEA and TA. The proposed scheme provides a separation of responsibilities between LEA and TA. This security mechanism will allow only LEA to manage the mapping of the unique identity of DVi and 5G_IDDVi. On the other hand, by using Sr2 encrypted with PKTA the confidentiality of CertTA,5G_IDDVi, SKABE(TA,DVi) is maintained from LEA. This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle DVi.Privileged Insider Attack in LEA. Since LEA receives CertTA,5G_IDDVi, SKABE(TA,DVi) encrypted with Sr2 (only known as the official vehicle), LEA cannot obtain such values. This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle DVi.LEA Impersonation Attack. LEA impersonation attack is avoided using the principles of public key cryptography. The Official Vehicle Registration request message M3 is accompanied with its digital signature σM3 signed by the private key of LEA. The TA can verify the origin of the message since it can verify the authenticity of σM3 using the public key of LEA PKLEA.Sybil Attack. To execute this kind of attack, the attacker must have nonrevoked, nonused, nonexpired, and authentic pseudo-certificates since the Cloud Platform verifies the validity (pseudo-certificate must not be revoked and expired) and authenticity (issued by the valid TA) of the pseudo-certificate attached to the video upload message. First, the attacker can try to listen to the network to capture a valid pseudo-certificate to reuse it later. However, this scenario is not a problem since the Cloud Platform has UPCLCloud(TA) verification making the reuse of valid pseudo-certificates impossible. On the other hand, the attacker also can try to access the set of pseudo-certificates stored in Cv; since the pseudo-certificates are stored in secure storage devices this kind of attack is not also possible. Finally, the attacker can also try to guess a valid pseudo-certificate. This scenario is also not feasible since the video upload message includes a signature signed by a private key; this means that the attacker must guess not only a valid, not used, and not expired pseudo-certificate, but also its private key. We believe that such scenario is not feasible.Exposure of Location of Official Vehicles. The present scheme provides a simple solution for this issue. The exposure of location of official vehicles is avoided by encrypting them using the public key of the Cloud Platform. Since the location information can only be decrypted by the authentic cloud with the corresponding private key, the adversary cannot obtain such information.Management of Multiple Trusted Authorities. The proposed scheme includes a novel handover protocol which is executed when a participating vehicle Cv goes to a different regional area controlled by another trusted authority. This mechanism will help the real implementation of the proposed service, adapted to the common administrative structure of entities grouped in different geographical/administrative regions.


### 4.5. Performance Analysis of the Proposed Solution

Since the intention of this analysis is to compare the overhead generated by the new security and functionality features of the proposed scheme with the previous one, the present work has used the same benchmark environment as [7]. It means that all the benchmarks were executed on a computer with Intel Core i7-2600 3.4 GHz processor using Crypto++ library 5.6.2 [15].Two overheads are calculated in this section. (1) First, the time overhead in video transmission protocol is calculated and it is compared with the previous work. As well as [7], the overhead of vehicle registration protocols is not calculated since the generation and storage of pseudonymous certificates and signing keys are executed only once a year during the vehicles’ inspection or service registration and because it is not a critical overhead for the real-time video reporting service. (2) After that, we analyze the overhead generated in handover protocol. The overhead of handover protocol is calculated autonomously without comparison with the previous work since it is a novel feature included only in the proposed scheme.


#### 4.5.1. Overhead Generated in Video Transmission Protocol

Before making the overhead calculation, it is important to select the certificate scheme for authentication of reported videos. The proposed scheme suggests the usage of PASS [8] as the mechanism for authentication of videos uploaded to the Cloud Platform, not only because it has one of the lowest overheads in terms of time for signing, certificate validation, and signature verification (see Table 2), but also because it solves the limitation of BP [16]. However, other algorithms such as BP [16], ECPP [17], DCS [18], and hybrid one [19] can be considered. Table 2 shows the time required for generation and verification of signatures and certificate verification using different algorithms [8] (same for both Eiza-Ni-Shi Scheme and proposed scheme). The total overhead generated in video transmission protocol is composed of three elements: (a) video encryption, (b) video transmission, and (c) video decryption by official vehicles. It is important to mention that the overhead calculation of random number generation was omitted since it is a minimal value.Table 2
Overhead for signing, certificate verification, and signature verification for Eiza-Ni-Shi Scheme and proposed scheme.
Certificate scheme
Signing time (ms)
Certificate verification time (ms)
Signature verification time (ms)
Total (ms)
BP
0.6
1.2
1.2
3
ECPP
0.6
18.9
1.2
20.7
DCS
1.2
14.7
14.1
30
Hybrid
0.6
18.9 + 9Ncrl
1.2
20.7 + 9Ncrl
PASS
0.6
14.7
1.2
16.5
N
c
r
l: size of certificate revocation list.Video Encryption. The overhead calculation for video encryption was executed using the benchmark data delivered by [7]. Using such data, it is possible to deduce that the time required to perform the encryption operation Ekw=PEKSPKR(TA),kw is approximately 36.52 ms, the time required for the encryption process ESr6=ABE.EncPKABE(TA),Sr6,Policy is approximately 62 ms (withPolicy containing 4 attributes), and the time required for signature generation σ5G_IDCvj=Sign(SKTA,5G_IDCvj,hashValue) is approximately 0.6 ms using the PASS scheme where hashValue=hhUCloud(TA),ETVr,Ekw,ESr6 (see Table 2). Additionally, the time required in executing ETVr=SEncSr6,TVr,CoordinateCv is illustrated in Figure 8, where the overheads for encryption of the video file are 455 MB/s when using AES/CBC, 147 MB/s when using Twofish/CTR, and 65 MB/s when using Serpent/CTR; all algorithms use 256-bit keys.Figure 8
Symmetric encryption overhead using different algorithms.It is notorious that most of the overhead of this stage of the protocol is the symmetric encryption of the video file corresponding toETVr=SEncSr6,TVr,CoordinateCv calculation. Since most of the overhead of this stage is the symmetric encryption of the video, the proposed system recommends encrypting the traffic accident video file while capturing it to minimize the time required for encryption before transmission.Video Transmission. In the same way, the video transmission overhead calculation was based on data delivered by [7]. Such reference indicates that the estimated time required to upload/download the encrypted video file of 2 GB to/from the Cloud Platform using 5G communication is Tcomm = 13.3 s assuming that the vehicle speed is 100 km/h and 5G connection speed is 1.2 Gbps. Based on this data, the video transmission protocol will require a total of 13.3 s for uploading 2 GB-size encrypted video by the participant vehicle and 13.3 s for downloading the same video by the official vehicles.Video Decryption. The overhead calculation for video decryption was executed using the benchmark data delivered by [7]. Using such data, it is possible to deduce that the time required for VerifySign(PKTA,PCertTA,5G_IDCvj, σ5G_IDCvj) is 14.7 ms when using the PASS scheme. The time required to execute Verify(PKTA,5G_IDCvj,(h(UCloud(TA)), ETVr,Ekw,Esr6),σ5G_IDCvj) step is 1.2 ms and the time required for Sr6=ABE.DecESr6,SKABE(TA,DVi) is approximately 18 ms. Additionally, the time required in executing the decryption of the encrypted video ETVr is similar to the ones shown in Figure 8. As well as in video encryption, most of the overhead of this stage of the protocol is the symmetric decryption of the encrypted video file.Total Overhead of Video Transmission Protocol. As well as the previous work, the proposed scheme can report the traffic accident of the participant vehicle in less than a minute using AES/CBC cryptographic algorithm over a 2 GB video file assuming that the participating vehicle is encrypting the traffic accident video file while capturing it (the time required for encryption before transmission is reduced to a minimal value). As shown in Table 3, the additional overhead required by the proposed scheme compared to the Eiza-Ni-Shi Scheme is only the time required for one random number generation which is almost none in actual devices.Table 3
Total overhead of video transmission protocol when AEC/CBC is used and video size is 2 GB.
Eiza-Ni-Shi Scheme
Proposed scheme
Video encryption
4.5099 s
4.5099 s + time for random number generation
Video transmission
13.3 s
13.3 s
Video decryption
4.5033 s
4.5033 s
Total
22,3132 s
22,3132 s + time for random number generation


#### 4.5.2. Overhead Generated in Handover Protocol

As well as in video transmission protocol, the steps related to random number generation were omitted for overhead calculation since their overhead is small and it is insignificant to the total overhead. On the other hand, the overhead calculation of message transmission was also omitted since its value is minimal assuming that 5G communication link is used amongCv, TA, and ATA.For the calculation of overhead generated in handover protocol, we assume that TA and ATA communicate securely using the RSA algorithm (2048-bit key) whileCv authenticates with TA using the PASS [8] algorithm. The overhead calculation was based on Crypto++ 5.6.0 benchmarks [20, 21].The total overhead of the handover protocol is composed of three components: (1) Participating Vehicle Overhead, (2) TA Mediation Overhead, and (3) ATA Response Overhead.Participating Vehicle Overhead. This is the overhead generated by steps executed by Cv. In this part, Cv executes one public key encryption step, one symmetric key encryption step, one symmetric key decryption step, and one signing step using PASS. Assuming that random numbers, 5G_IDCV, CoordinateCv, and symmetric keys are 256 bits long, it is possible to deduce that the time required to perform M7 = {PKE(PKTA,Sr4), SEnc(Sr4,(N3,N4,5G_IDCv,CoordinateCv))} is approximately 0.16 ms, the time required to execute σM7=SignSK5G_IDCvj,M7 is 0.6 ms, and the time required to execute SDecSr4,M10 is approximately (N/10) ms, where N is the number of pseudonymous certificates issued by ATA. In summary, the total overhead of participating vehicle is ((N/100) + 0.76) ms. Table 4 shows the calculation of the overhead with different number of issued pseudonymous certificates.Table 4
Handover protocol overhead.
Number of pseudo-certificates
Participating Vehicle Overhead (seconds)
TA Mediation Overhead (seconds)
ATA Response Overhead (seconds)
Total overhead (seconds)
24 (for a day)
0.0032
0.0215
0.0753
0.1239
48 (for 2 days)
0.0056
0.0263
0.1433
0.2231
168 (for a week)
0.0176
0.0503
0.4834
0.7192
720 (for a month)
0.0728
0.1607
2.0477
3.0012
2160 (for 3 months)
0.2168
0.4487
6.1287
8.9541
4320 (for 6 months)
0.4328
0.8807
12.2501
17.8836
8760 (for a year)
0.8768
1.7687
24.8331
36.2385TA Mediation Overhead. This is the overhead generated by performing steps executed by TA. Here is the overhead calculation: the time required to perform VerifySignSKTA,PCertTA,5G_IDCvj,σM7 is approximately 1.2 ms, the time required to execute VerifyPKTA,5G_IDCvj,M7,σM7 is 1.2 ms, the time required to execute PKDSKTA,PKEPKTA,Sr4 is approximately 6.08 ms, the time required to execute SDecSr4,SEncSr4,N3,N4,5G_IDCv,CoordinateCv is less than 1 ms, the time required to execute M8 = PKEPKATA,Sr5,SEncSr5,N5,N6,5G_IDCv is approximately 1.16 ms, the time required to execute σM8=SignSKTA,M8 is 6.05 ms, the time required to decrypt M9 using Sr5 is approximately (N/10) ms, and the time required to perform M10 = SEnc(Sr4,({SKATA,5G_IDCvj}, {PCertATA,5G_IDCvj},PKR(ATA),PKABE(ATA),PolicyATA, IPCloud(ATA),UCloud(ATA),RegATA,N4′)) is approximately (N/10) ms. In summary, the total TA Mediation Overhead is ((2N/10)+16.69) ms. Table 4 and Figure 9 show the calculation of the overhead with different number of issued pseudonymous certificates.Figure 9
Total overhead of handover protocol according the number of issued pseudonymous certificates.ATA Response Overhead. This is the overhead generated by steps executed by ATA. Here is the overhead calculation: the time required to perform VerifyPKTA,M8,σM8 is approximately 0.16 ms, the time required to execute PKDSKATA,PKEPKATA,Sr5 is 6.08 ms, the time required to execute SDecSr5,SEncSr5,N5,N6,5G_IDCv is less than 1 ms, the time required to generate SKATA,5G_IDCvj, PCertATA,5G_IDCvj is approximately (2.734N) ms, and the time required to execute M9 = SEnc(Sr5,({SKATA,5G_IDCvj},{PCertATA,5G_IDCvj}, PKR(ATA),PKABE(ATA),PolicyATA,IPCloudA(TA), UCloud(ATA),RegATA,N6′)) is approximately (N/10) ms. In summary, the total ATA Response Overhead is (2.834N + 7.24) ms. Table 4 shows the calculation of the overhead with different number of issued pseudonymous certificates.It is important to calculate the overhead generated in the handover protocol because the distance of the intersection zone of two regions depends on the overhead of handover protocol and the maximum speed of the participating vehicle (see Figure10). In other words, the distance d is calculated as follows: d=Overhead×MaxSpeedCv, where d is the distance of the intersection zone, Overhead is the total time overhead of the handover protocol, and MaxSpeedCv is the maximum speed a participating vehicle can reach. The calculation of d is important for planning the coordinate of regions controlled by each trusted authority, since Cv needs to receive the pseudonymous certificates issued by ATA before exiting from its own region. If Cv has an accident in the intersection zone, the video is uploaded first in its own region and then it is uploaded to the region controlled by ATA (if the handover process is already finished). The minimum distance required for intersection zone of two regions when MaxSpeedVi=200km/h is indicated in Table 5 and Figure 11.Table 5
Distance of intersection zone.
Number of pseudo-certificates
Total overhead (seconds)
Distance (km)
24 (for a day)
0.1239
0.0069
48 (for 2 days)
0.2231
0.0124
168 (for a week)
0.7192
0.0400
720 (for a month)
3.0012
0.1667
2160 (for 3 months)
8.9541
0.4975
4320 (for 6 months)
17.8836
0.9935
8760 (for a year)
36.2385
2.0133
Corresponding data when MaxSpeedVi = 200 km/h.Figure 10
Relation between handover overhead and intersection zone.Figure 11
Minimum distance of intersection zone of two regions according to the number of issued pseudonymous certificates.Since the participating vehicles must renew the registration to the service annually, the number of pseudonymous certificates issued for handover should be much less than 8760 (for a year). We believe that certificates for 3 months should be enough for this purpose. If there is an extraordinary case when participating vehicle needs to stay in the region controlled by ATA for a long period of time, the participating vehicle can execute the handover protocol again when its pseudonymous certificate is running out. Assuming that the handover protocol is implemented with 2160 pseudonymous certificates the total overhead would be less than 9 seconds andd would be less than 0.5 km which would be very reasonable for real implementation.


#### 4.5.3. Analysis of Region Organization

The intention of this subsection is to analyze the size of a region and the overhead caused by the handover protocol when a vehicle visits different number of regions.Size of a Region. It is very hard to determinate the size of a region since it depends on the needs of each country. But we recommend following the regulation of each country in administering the vehicle registration and driver licensing. For example, in the United States, there is an institution called Department of Motor Vehicles (DMV) which is a state-level government that administer vehicle registration and driver licensing. Since each country has similar departments, we recommend that each region for the proposed service must incorporate the geographical area controlled by a DMV, for example, an individual state for United States of America.Overhead of Handover Protocol When Visiting Different Regions. For this analysis, we have taken the following assumptions: (1) the size of a region is determined by the geographical area controlled by a DMV, that is, an individual state, and (2) since we have recommended the usage of pseudo-certificate for three months (2160 pseudo-certificates) in handover protocol (in the previous subsection), we will use such values for this analysis.Statistical data such as [22, 23] indicates that most of drivers use their motorized vehicles for activities of daily life, which means that they drive inside the same town most of the time. It means that most of participating vehicles will not execute or will rarely execute the handover protocol. However, for this analysis, we will consider all kinds of possibilities, including three kinds of vehicles: (1) ordinary vehicle which rarely leaves its region/state, (2) vehicles of people living in the border of a region/state which will make them visit the neighbor region/state frequently, and (3) extraordinary vehicles traveling several states frequently (e.g., interstate buses or cargo trucks).For the first kind of vehicles (ordinary vehicles), the overhead caused by the handover protocol will be minimal since they will not execute or rarely execute such protocol. For the second kind of vehicles (living in a border), they will execute the handover protocol when visiting the neighbor region; however, the vehicle will not execute the handover protocol each time it crosses the border, but when all pseudo-certificates have been used or expired, that is, three months. In this second case, the overhead caused by the handover protocol will also be minimal since vehicles will execute the handover protocol (normally) every three months. Finally, Table6 shows the overhead caused for the third kind of vehicles. Such data indicates the overhead generated when visiting different number of external regions every three months. For example, if a vehicle visits 5 different regions/states, it will spend a total of 44,77 seconds. We believe that the overhead of 44,77 seconds in three months is not a problem in implementing the proposed service. It is important to mention that the process is not executed during 44,77 seconds; instead Cv executes the 8,95 seconds’ process each time it enters a new region.Table 6
Handover protocol overhead when visiting several regions with pseudo-certificates for 3 months.
Number of different external regions visited by Cv
Total overhead(seconds)
1
8.95
2
17.90
5
44.77
10
89.54
20
179.08This analysis has shown how the overhead caused in crossing different regions will not be a problem in implementing the proposed solution nationwide.


## 4.1. System Model

The proposed scheme uses the 5G mobile network as the foundational communication technology. 5G technology was selected for the vehicular network because of its high speed and capacity required to upload and download the traffic accident videos in real time.Figure2 shows the proposed multiregional and multitier 5G enabled vehicular network. The proposed scheme makes the management of different geographic/administrative regions responding to the real world needs possible. Since most of the countries in the world control the motorized vehicles through regional authorities (e.g., state authorities), the proposed scheme assumes a more realistic world scenario with multiple TAs, DMVs, and LEAs connected to its own Cloud Platform. In other words, the proposed scheme provides a solution to the limitation left as future work in [7].Each geographical or administrative region is composed of its own Department of Motor Vehicles (DMV), trusted authority (TA), Law Enforcement Agency (LEA), Cloud Platform, and vehicles (participating vehicles and official vehicles). Since the proposed solution allows multiple geographical or administrative regions, there are additional considerations to bear in mind: (1) The implementation of the Cloud Platform can be unique for the complete system (nationwide), or it can be independent for each geographic/administrative region; it will depend on local laws and regulations. Obviously, since the Cloud Platform is connected to the Internet, a Cloud Platform of a region will be accessible from other regions. And (2) the proposed scheme assumes that TA is secure and it is trusted by all the other entities of the 5G enabled vehicular network system of the same geographical/administrative region. Additionally, we assume that a TA of a region is trusted by other TAs located in other geographical/administrative regions.


## 4.2. Design Criteria: System Considerations and Assumptions

This section describes the security criteria and assumptions used in designing the proposed scheme.Confidentiality and Integrity. Messages containing secret data transmitted and received by entities must be protected from malicious users. Additionally, unauthorized alterations of confidential data must be identified by the proposed service.Protection against Untrusted Communications. The communication among TAs, DMVs, and LEAs (messages coming from the mentioned entities) is not fully trusted since privileged insider attack could be executed. Therefore, the protection of confidential messages using cryptographic algorithms is necessary.Insecure Channels. Most of communication channels are considered insecure. This means that sniffing and spoofing of messages can occur in such channels. The following communication channels are considered insecure.(i)
The communication channel betweenDVi and Cloud Platform is not secure.(ii)
The communication channel betweenDVi and LEA is not secure.(iii)
The communication channel betweenCv and TA is not secure.(iv)
The communication channel betweenCv and Cloud Platform is not secure.(v)
The communication channel between LEA and Cloud Platform is not secure.(vi)
The communication channel between TA and ATA is not secure.Secure Channel. Only one communication channel is considered secure, that is, communication between Cv and DMV. The mentioned communication channel is considered secure because the communication is executed face to face. It means that the owner of Cv must visit the DMV’s office to register his vehicle.Trusted Entities. The servers managed by different entities, that is, DMVs, LEAs, TAs, and Cloud Platforms, are managed by trusted service providers. Therefore, such infrastructures are considered secure, and their security is not considered as part of this paper.Authentication and Nonrepudiation. Each participating vehicle Cv must authenticate to the Cloud Platform to upload the reporting video, and it cannot repudiate later the execution of video uploading process.Cryptographic Keys. We assume that each entity, that is, TA, DMV, LEA, and Cloud Platform, has its own asymmetric key pair and they are administered securely using existing algorithms.Security against Common Attacks. The proposed solution must be strong against the most common attacks such as replay attack, privileged insider attack, impersonation attack, and message sniffing/spoofing.Secure Storage. The proposed scheme assumes that the participating vehicles Cv and designated official vehicles DVi have a tamper-proof device for storage and management of confidential data (e.g., keys and pseudonymous certificates). Security technologies such as TrustZone by ARM [13] and Secure RAM by Freescale [14] could be possible solutions for the mentioned tamper-proof devices.Separation of Responsibilities among DMV, LEA, and TA. Even though DMV, LEA, andTA are trusted entities, it is important to make a separation of responsibilities making each of the entities see and store information related to its jurisdiction. The separation of responsibilities increases the level of security and privacy of users.


## 4.3. Protocols

The proposed scheme includes eight different phases called (1) system initialization, (2) participant vehicles registration, (3) official vehicles registration, (4) participation vehicle handover, (5) video transmission, (6) video search, (7) Pseudo-Certificate Revocation, and (8) interregion certificate revocation. The notations used in the proposed protocol differ a little bit from the ones used in Eiza-Ni-Shi Scheme since the proposed scheme covers wider functionalities and requires new notations. The mentioned notations are detailed in (ii) in the Notations.


### 4.3.1. System Initialization

In the proposed system, each trusted authority (TA) manages a certain geographic/administrative regional area (e.g., a state, province, or district). All the trusted authorities share the sameΔT, which indicates the validity period threshold of a pseudonymous certificate issued to a participating vehicle. It is important to notice that having the same ΔT in each trusted authority does not mean synchronization among those entities; it just means that all TAs must store the same value of ΔT as a constant when the service is implemented. Since the value of ΔT is defined as a governmental regulation for this service, the value of ΔT is not modified after implementation. If the governmental regulation for the services is modified, the TA’s administrator must modify manually the value of ΔT. On the other hand, it is important to remember that each pseudonymous certificate is usable only once and it has an expiration time which is equal to LastPCertTimeCv+ΔT, where LastPCertTimeCv is the last time where a pseudonymous certificate of a specific participating vehicle Cv was used.Since each pseudonymous certificate has an expiration time, the TA must estimate the number of certificates to be issued to eachCv. We also think it is a good idea to issue enough pseudonymous certificates for a year, until the next vehicle inspection. For example, if ΔT=1 hour, the number of pseudonymous certificates required for a Cv during a year will be 24×365=8760. Considering that the certificate size is 66 bytes (as indicated in Section 2), the total amount of space required will be approximately 565 KB, which is a reasonable overhead in terms of storage. As mentioned in Section 4.2., we assume that each Cv has a tamper-proof device for storage and management of confidential data (e.g., keys and pseudonymous certificates).


### 4.3.2. Participant Vehicle Registration Protocol

This protocol is executed during the annual vehicle inspection or whenever a user expresses his/her willingness to participate in the video reporting service. This protocol is composed of the following steps (see Figure3).Figure 3
Participating and Official Vehicle Registrations.A participant vehicle generates a random symmetric keysr1∈Z∗q and sends {Cv,5G_IDCv,PKEPKTA,Sr1} to the Department of Motor Vehicles (DMV), where Cv is the unique identification of the participating vehicle, 5G_IDCv is the 5G identification of the vehicle, PKTA is the public key of the trusted authority (TA) of the region which the participant vehicle is part of, and PKEx,y is the public key encryption function of message y using key x.Once the message is received, DMV verifies physically the correctness of theCv, then gets its current timestamp TS′, and creates the message M1=5G_IDCv,TS′,PKEPKTA,Sr1. Upon generation of M1, DMV signs M1 using its private key SKDMV by executing σM1=SignSKDMV,M1. Finally, DMV sends M1 and σM1 to TA.Upon receiving the message, TA verifies the freshness of the message by checking the fulfillment ofTS′′-TS′≤ΔTS, where TS′′ is the current timestamp of TA and ΔTS is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature σM1 as follows: Verify(PKDMV,M1,σM1). After signature verification, TA obtains Sr1 by executing PKDSKTA,PKEPKTA,Sr1 and then generates the set of private keys SKTA,5G_IDCvj and a set of pseudonymous certificates PCertTA,5G_IDCvj corresponding to 5G_IDCv, where PKDx,y is the public key decryption function of message y using key x. After that, TA returns the message M2 = {TS′′′,SEnc(Sr1,({SKTA,5G_IDCvj},{PCertTA,5G_IDCvj}, PKR(TA),PKABE(TA),Policy,IPCloud(TA),UCloud(TA), RegTA,TS′′′))} to DMV, where PKR(TA) is the public key of TA for Public Key Encryption with Keyword Search, PKABE(TA) is the public key of TA for the Attributed Based Encryption,Policy is the access policy of traffic accident videos uploaded by Cv (e.g., Policy={“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), IPCloud(TA) is the IP address of the Cloud Platform of TA, UCloud(TA)∈Z∗q is the a tag preagreed upon between TA and the Cloud Platform of TA (CloudTA), RegTA is the coordinate representing the geographical region controlled by TA, and TS′′′ is the current timestamp of TA.R
e
g
T
A is used for the handover process when Cv crosses to another geographical region controlled by another trusted authority (e.g., different states, districts, or cities). This process is explained later in the handover protocol section.DMV, once the message is received from TA, forwards it to the participating vehicle. Finally,Cv verifies the validity of TS′′′, then decrypts the received message using Sr1, and stores the decrypted values into its tamper-proof device.It is important to note that the DMV only sends5G_IDCv to the TA. This means that the relation between Cv and 5G_IDCv is kept only at the DMV. This will offer the feature of role separation, and consequently, more protection for the real identity of the participating vehicle, since 5G_IDCv is not a fixed value changeable during the next inspection/registration event.


### 4.3.3. Official Vehicle Registration Protocol

Figure3 illustrates both Participation Vehicles Registration and Official Vehicle Registration protocols, but the protocols are executed independently in different time.The official vehicles are also registered for this service to ensure that only authentic official vehicles will receive the notification of a traffic accident video (see Figure3). The official designated vehicle generates a random symmetric key Sr2∈Z∗q and sends {DVi,5G_IDDVi,PKEPKTA,Sr2} to the Law Enforcement Agency (LEA), where DVi is the unique identification of the official designated vehicle, 5G_IDDVi is the 5G identification corresponding to DVi, and PKTA is the public key of the trusted authority (TA) of the region which Cv and DVi are part of.Once the message is received, LEA verifies physically the correctness ofDVi, gets its attribute(s), AttributeDVi (e.g., “police vehicle,” “ambulance,” “traffic authority,” or “traffic law enforcement”), and generates the message M3=5G_IDDVi,TS2′,AttributeDVi,PKEPKTA,Sr2 and σM3=SignSKLEA,M3, where TS2′ is the current timestamp of LEA, SKLEA is the private key of LEA, and Signx,y is a digital signing of a message y using a private key x. Upon generating the messages, LEA sends M3 and σM3 to TA.After receiving the message, TA verifies the freshness of the message by checking the fulfillment ofTS2′′-TS2′≤DTS, where TS′′ is the current timestamp of TA and ΔTS is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature σM3 as follows: Verify(PKLEA,M3,σM3). After signature verification, TA obtains Sr2 by executing PKDSKTA,PKEPKTA,Sr2 and then generates the Attribute Based Encryption Private Key for DVi as follows: SKABE(TA,DVi)=ABE.DelegateMKTA,AttributeDVi. TA also generates a certificate CertTA,5G_IDDVi for DVi based on 5G_IDDVi and includes it into a message M4={T2′′′,SEnc(Sr2,CertTA,5G_IDDVi,SKABEDVi,T2′′′, IPCloud(TA))}, to finally send it to LEA. LEA receives M4 and forwards it to DVi.Upon receivingM4, DVi verifies the freshness of the message using ΔTS and decrypts M4 by executing SDecSr2,M4. Once decrypting M4, DVi compares the decrypted T2′′′ with the T2′′′ value received in plaintext to double verify the authenticity and freshness of the message. Finally, DVi stores the decrypted values into its tamper-proof device.Now, once registered with TA and LEA, it is time to execute the registration with the Cloud Platform. For this,DVi sends an registration request message to CloudTA. Once receiving the request, the Cloud Platform generates a random nonce N1 and transmits it to DVi. Upon receiving N1, DVi generates a random symmetric key Sr3 and a random nonce N2, calculates M5=PKEPKCloudTA,Sr3 and M6=SEncSr3,N1,N2,CertTA,5G_IDDVi, and sends {M5,M6} to CloudTA. The Cloud Platform then obtains Sr3 by executing PKDSKCloudTA,M5 and uses such value to obtain N1′,N2′,CertTA,5G_IDDVi=SDecSr3,M6. Once with N1′, CloudTA verifies the freshness of the message comparing the decrypted nonce N1′ with the one generated previously, N1, only if those values matching DVi are registered to the Cloud Platform. Closing the registration process, CloudTA registers CertTA,5G_IDDVi in its database and sends the decrypted N2′ to DVi to confirm its registration. Finally, DVi verifies the confirmation message by comparing the received N2′ with the previously generated N2.It is important to clarify that the communication betweenDVi and CloudTA uses random nonces to validate the freshness of messages instead of timestamps. This is because it is hard to maintain the clock of DVi and CloudTA synchronized. Timestamps are only used among LEA, DMV, and TA since they are trusted entities which can coordinate a reliable clock synchronization.


### 4.3.4. Handover Protocol

The proposed scheme solves the limitation of Eiza-Ni-Shi Scheme regarding the lack of contemplation of different regional areas that are under the management of different trusted authorities. The proposed scheme contributes with a novel handover protocol executed when a participating vehicleCv goes to a different regional area with another trusted authority.In Participating Vehicle Registration Protocol,Cv received RegTA which contains the coordinate of the geographical region controlled by TA. Such value is used to verify when handover is required. For this, Cv checks periodically its GPS coordinate with RegTA; when CoordinateCv∉RegTA, it initiates the handover protocol composed of the following steps (see Figure 4).Figure 4
Proposed handover protocol.First,Cv sends a handover request to TA. The TA then generates a random nonce N3 and sends it to Cv. Upon receiving the random nonce, Cv generates its own random nonce N4 and a random symmetric key Sr4 and calculates M7={PKEPKTA,Sr4,SEnc(Sr4,(N3,N4,5G_IDCv, CoordinateCv))} and σM7=Sign(SK5G_IDCvj,M7). Once calculating such values, Cv sends (M7,σM7,PCertTA,5G_IDCvj) to its trusted authority (TA), where PCertTA,5G_IDCvj is the first not used pseudo-certificate valid at current time. Once receiving the message, TA verifies the authenticity of σM7 and origin of PCertTA,5G_IDCvj by executing VerifySignPKTA,PCertTA,5G_IDCvj,σM7. TA also verifies if σM7 corresponds to the digital signature of M7 by performing VerifyPKTA,5G_IDCvj,M7,σM7. Once the authenticity of messages is verified, TA gets Sr4 by PKDSKTA,PKEPKTA,Sr4 and uses it to obtain N3′,N4′,5G_IDCv,CoordinateCv = SDec(Sr4,SEnc(Sr4,(N3,N4,5G_IDCv, CoordinateCv))). Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted N3′ with the previously generated N3. The nonce comparison allows TA to eliminate all possibilities of replay attacks from adversaries. Once the validity of handover request is verified, TA searches the away trusted authority (ATA) that controls the region where Cv currently is located.Once the adequate ATA is detected, TA mediates the registration ofCv in ATA. For this, TA requests a temporal registration of Cv to ATA. Upon receiving the request, ATA generates a random nonce N5 and sends it to TA. Once the connection with ATA is realized, TA generates a random nonce N6 and a random symmetric key Sr5 and calculates M8=PKEPKATA,Sr5,SEncSr5,N5,N6,5G_IDCv and σM8=SignSKTA,M8. Once the messages are calculated, TA sends M8,σM8 to ATA.Once receiving the message, ATA verifies the authenticity of the received signatureσM8 as follows: Verify(PKTA,M8,σM8). Upon signature verification, ATA obtains Sr5 by executing PKDSKATA,PKEPKATA,Sr5 and uses such value to get N5′,N6′,5G_IDCv = SDecSr5,SEncSr5,N5,N6,5G_IDCv. Later, ATA verifies the freshness of the message comparing the decrypted nonce N5′ with the previously generated N5. Only if those values match, ATA proceeds to respond to the registration request. Closing the temporal registration process, ATA generates the set of private keys SKATA,5G_IDCvj and a set of pseudonymous certificates PCertATA,5G_IDCvj corresponding to 5G_IDCv of Cv. After that, ATA returns the message M9 = SEnc(Sr5,({SKATA,5G_IDCvj}, {PCertATA,5G_IDCvj},PKR(ATA),PKABE(ATA),PolicyATA, IPCloud(ATA),UCloud(ATA),RegATA,N6′)) to TA, where PKR(ATA) is the public key of ATA for Public Key Encryption with Keyword Search, PKABE(ATA) is the public key of ATA for the Attributed Based Encryption, PolicyATA is the access policy of traffic accident videos uploaded by Cv (e.g., PolicyATA={“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), IPCloud(ATA) is the IP address of the Cloud Platform of ATA, UCloud(ATA)∈Z∗q is the a tag preagreed upon between ATA and the Cloud Platform of ATA (CloudATA), and RegATA is the coordinate representing the geographical region controlled by ATA.Upon receiving the response from ATA, TA decryptsM9 using its random key Sr5. Once decrypting M9, TA verifies the authenticity of M9 by comparing N6′ with its own N6. This comparison allows TA to be sure that M9 came from the valid ATA. After verification, TA stores the decrypted values for historical data of Cv (only if required) and generates a new message M10 = SEnc(Sr4,({SKATA,5G_IDCvj},{PCertATA,5G_IDCvk}, PKR(ATA),PKABE(ATA),PolicyATA,IPCloud(ATA), UCloud(ATA),RegATA,N4′)) and sends it to Cv.Upon receiving the message,Cv decrypts M10 and verifies that the message came from the authentic TA freshly by comparing N4′ with N4. After verification Cv stores the decrypted values to its tamper-proof device.Note. Since the trusted authorities are in different regional areas and as it is hard to have clock synchronization, handshake using random nonces is used instead of timestamps to avoid replay attacks.


### 4.3.5. Video Transmission Protocol

When an accident occurs,Cv obtains the recorded video file through its cameras and initiates the video transmission protocol, which is composed of the following steps (see Figure 5).Figure 5
Video transmission and video search protocols.First,Cv generates a random symmetric key Sr6 and uses it to encrypt the video file TVr and its current GPS coordinate CoordinateCv as follows: ETVr=SEnc(Sr6,(TVr,CoordinateCv)). Then, Cv generates the keywords related to the accident kw and encrypts it using the Public Key Encryption with Keyword Search function as Ekw=PEKSPKR(TA),kw and calculates ESr6=ABE.EncPKABE(TA),Sr6,Policy. Additionally, Cv encrypts Sr6 using the Attribute Based Encryption function using PKABE(TA) andPolicy and creates a digital signature σ5G_IDCvj of generated messages using its current private key SKTA,5G_IDCvj. Finally, Cv clusters the generated messages into M11={hUCloud(TA),ETVr,Ekw,ESr6,σ5G_IDCvj, PCertTA,5G_IDCvj} and sends it to CloudTA over the 5G enabled vehicular network.Upon receivingM11, CloudTA checks if PCertTA,5G_IDCvj is in the Pseudo-Certificate Revocation List, PCRLCloud(TA), or in the Used Pseudo-Certificate List, UPCLCloud(TA), which is the list of the already used pseudo-certificates. It is important to remember that a pseudo-certificate is usable only once. If such pseudo-certificate is in PCRLCloud(TA) or UPCLCloud(TA), the received M11 is discarded; otherwise, CloudTA verifies the authenticity of the message by executing VerifySign(PKTA,PCertTA,5G_IDCvj,σ5G_IDCvj). If the certificate is proved to be valid, CloudTA stores such message and notifies the nearest designated vehicle DVi about the accident sending M11. We assume that the location information of the official vehicles is updated periodically in the cloud. The location of official vehicles is protected since it is transmitted using the public key of CloudTA  PKCloudTA.Once an official vehicleDVi receives the notification, it verifies the received pseudonymous certificate PCertTA,5G_IDCvj by executing VerifySign(PKTA,PCertTA,5G_IDCvj,σ5G_IDCvj). If the certificate is proved to be valid, DVi extracts the public key PKTA,5G_IDCvj of the sender from the certificate PCertTA,5G_IDCvj. Upon certificate validation, DVi verifies the received signature σ5G_IDCvj by executing Verify(PKTA,5G_IDCvj, (h(UCloud(TA)),ETVr,Ekw,ESr6),σ5G_IDCvj) and obtains the Sr6 using its Attributed Based Encryption private key SKABE(TA,DVi) as follows: Sr6=ABE.DecESr6,SKABE(TA,DVi). Finally, DVi gets the decrypted video and the last coordinate of Cv by executing (TVr,CoordinateCv)=SDec(Sr6,ETVr). Now, the official vehicles are able to go to the location of the accident using CoordinateCv and they can check the video of the accident while going to the location.


### 4.3.6. Video Search Protocol

Once the video transmission protocol is done and the video is uploaded to the Cloud Platform, it can be retrieved by LEA whenever it is needed. The video search protocol is executed as follows (see Figure5).First, LEA initiates a video search request toCloudTA. Then, CloudTA generates a random nonce N7 and sends it to LEA. Once receiving the response of CloudTA, LEA generates another random nonce N8 and a random symmetric key Sr7 and then generates the searchable trapdoor token as follows: Tkwi=TrapdoorSKR(TA),kwi, where kwi is a keyword (e.g., location, date, or “any video”) related to the video. Upon generation of the search token, LEA generates a message M12=PKEPKCloudTA,Sr7,SEncSr7,N7,N8,Tkwi and its digital signature σM12=SignSKLEA,M12 and sends them to the CloudTA.On the other side,CloudTA verifies the validity of the digital signature σM12 by performing VerifyPKLEA,M12,σM12 to be sure that the search request comes from the authentic LEA. Once validating the authenticity of the message, the Cloud Platform extracts Sr7 by PKDSKCloudTA,PKEPKCloudTA,Sr7 and uses it to get N7′,N8′,Tkwi=SDecSr7,SEncSt7,N7,N8,Tkwi. Once obtaining the data, CloudTA verifies the freshness of the message by comparing the decrypted nonce N7′ with the previously generated N7. If those values match, CloudTA authorizes Tkwi search process over the ciphertext at the cloud and executes TestPKR(TA),Ekw,Tkwi. Once the video is founded, a new message M12={h(UCloudTA),ETVr,Ekw,ESr6, σ5G_IDCvj,PCertTA,5G_IDCvj,SEnc(Sr7,N8)} is generated and it is sent to the LEA.Upon receivingM12, LEA extracts N8′ by executing SDec(SEncSr7,N8′ and compares it with the previously generated N8 to validate the authenticity and freshness of the message. The comparison of random nonces allows LEA to verify the freshness since the received nonce corresponds to the last one created by itself. The nonce comparison also allows the verification of authenticity of CloudTA since the sent nonce can only be decrypted by the authentic CloudTA having the private key SKCloudTA.


### 4.3.7. Pseudo-Certificate Revocation

This protocol is executed when a participating vehicleCv needs to stop its participation in the video reporting services, either because the user expressed his/her willingness to stop the service, because the car was robbed, or because the pseudo-certificates stored in the car have been exposed. This protocol is composed of the following steps (see Figure 6).Figure 6
Pseudo-Certificates Revocation Protocol.First, the owner of the participating vehicleOwnerCv indicates his/her willingness to stop the video reporting services to the DMV by delivering his/her identification IDOwnerCv (e.g., driver’s license). Once the request is received, the DMV verifies the authenticity of IDOwnerCv and gets Cv and 5G_IDCv corresponding to OwnerCv. Then, the DMV gets its current timestamp TS3′, generates a random nonce N9, and calculates M13=5G_IDCv,TS3′,PKEPKTA,N9 and σM13=SignSKDMV,M13. Once such values are calculated, DMV sends (M13,σM13) to the TA. Once the message is received, TA verifies the freshness of the message using its timestamp TS3′′ and verifies the authenticity of σM13 by executing VerifyPKDMV,M13,σM13. Once the authenticity of the message is verified, TA gets N9 by PKDSKTA,PKEPKTA,N9 and adds the pseudo-certificates belonging to 5G_IDCv to Cv’s Peudo-Certificate Revocation List, PCRLCv. Once PCRLCv is updated, DMV returns the decrypted N9′ to DVM. Finally, the DMV verifies the correct execution of the request by comparing the received message with the N9 generated by itself and then informs the OwnerCv about the correct execution of the requested process.On the other hand, the TA executes the Pseudo-Certificates Revocation process with the Cloud Platform. For this, the TA sends a request message toCloudTA. CloudTA then generates a random nonce N10 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce N11 and a random symmetric key Sr8 and calculates M14=PKEPKCloudTA,Sr8,SEncSr8,N10,N11,PCRLCv and σM14=Sign(SKTA,M14). Once such values are calculated, TA sends (M14,σM14) to its Cloud Platform. Once the message is received, CloudTA verifies the authenticity of the message by executing VerifyPKTA,M14,σM14. Once the authenticity of the message is verified, CloudTA gets Sr8 by PKDSKCloudTA,PKEPKCloudTA,Sr8 and uses it to obtain N10′,N11′,PCRLCv=SDecSr4,SEncSr8,N10,N11,PCRLCv. Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted N10′ with the previously generated N10. Once the validity of Pseudo-Certificates Revocation request is verified, CloudTA adds PCRLCv to the Pseudo-Certificates Revocation List of the Cloud Platform, PCRLCloud(TA). Once PCRLCloud(TA) is updated, CloudTA returns the decrypted N11′ to TA. Finally, the TA verifies the correct execution of the request by comparing the received message with the N11 generated by itself.Note. The Pseudo-Certificates Revocation Protocol can also be executed by a designated authority (e.g., police officer) when detecting a misbehaving Cv. In this case, the designated authority requests the Pseudo-Certificates Revocation to LEA instead of DMV. The following steps will be the same; the only difference is that the participating entities will be LEA–TA–CloudTA instead of DMV–TA–CloudTA.


### 4.3.8. Interregion Pseudo-Certificate Revocation

This stage is executed after the Pseudo-Certificate Revocation Protocol, only if the participating vehicleCv has been in another region and received pseudo-certificates from an ATA. TA can know if Cv has been in another region since it was the intermediary executing the handover protocol. This protocol is composed of the following steps (see Figure 7).Figure 7
Interregion Pseudo-Certificates Revocation Protocol.First, TA sends a Pseudo-Certificates Revocation request to ATA whereCv has received pseudo-certificates. The ATA then generates a random nonce N12 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce N13 and a random symmetric key Sr9 and calculates M15={PKE(PKTA,Sr9), SEnc(Sr9,(N12,N13,5G_IDCv,PCRLCv))}, and σM15=Sign(SKTA,M15). Once such values are calculated, TA sends (M15,σM15) to ATA. Once the message is received, ATA verifies the authenticity of the message by executing VerifyPKTA,M15,σM15. After verification, ATA gets Sr9 by PKDSKTA,PKEPKTA,Sr9 and uses it to obtain N12′,N13′,5G_IDCv,PCRLCv = SDecSr9,SEncSr9,N12,N13,5G_IDCv,PCRLCv. Upon decrypting the data, ATA verifies the freshness of the message by comparing the decrypted N12′ with the previously generated N12. Once the validity of the request is verified, ATA adds the pseudo-certificates belonging to 5G_IDCv to Cv’s Pseudo-Certificate Revocation List, PCRLCv.On the other hand, the ATA also executes the Pseudo-Certificates Revocation process with the Cloud Platform. For this, the ATA sends a request message toCloudATA. CloudATA then generates a random nonce N14 and sends it to ATA. Upon receiving the random nonce, ATA generates its own random nonce N15 and a random symmetric key Sr10 and calculates M16={PKE(PKCloudATA,Sr10), SEnc(Sr10,(N14,N15,PCRLCv))}, and σM16=Sign(SKATA,M16). Once such values are calculated, ATA sends (M16,σM16) to its Cloud Platform. Once the message is received, CloudATA verifies the authenticity of the message by executing VerifyPKATA,M16,σM16. Once the authenticity of the message is verified, CloudATA gets Sr10 by PKDSKCloudATA,PKEPKCloudATA,Sr10 and uses it to obtain N14′,N15′,PCRLCv = SDecSr10,SEncSr10,N14,N15,PCRLCv. Upon decrypting the data, CloudATA verifies the freshness of the message by comparing the decrypted N14′ with the previously generated N14. Once the validity of Pseudo-Certificates Revocation request is verified, CloudATA adds PCRLCv to the Pseudo-Certificates Revocation List of the Cloud Platform PCRLCloud(ATA). Once PCRLCloud(ATA) is updated, CloudATA returns the decrypted N15′ to ATA. Finally, the ATA verifies the correct execution of the request by comparing the received message with the N15 generated by itself.


## 4.3.1. System Initialization

In the proposed system, each trusted authority (TA) manages a certain geographic/administrative regional area (e.g., a state, province, or district). All the trusted authorities share the sameΔT, which indicates the validity period threshold of a pseudonymous certificate issued to a participating vehicle. It is important to notice that having the same ΔT in each trusted authority does not mean synchronization among those entities; it just means that all TAs must store the same value of ΔT as a constant when the service is implemented. Since the value of ΔT is defined as a governmental regulation for this service, the value of ΔT is not modified after implementation. If the governmental regulation for the services is modified, the TA’s administrator must modify manually the value of ΔT. On the other hand, it is important to remember that each pseudonymous certificate is usable only once and it has an expiration time which is equal to LastPCertTimeCv+ΔT, where LastPCertTimeCv is the last time where a pseudonymous certificate of a specific participating vehicle Cv was used.Since each pseudonymous certificate has an expiration time, the TA must estimate the number of certificates to be issued to eachCv. We also think it is a good idea to issue enough pseudonymous certificates for a year, until the next vehicle inspection. For example, if ΔT=1 hour, the number of pseudonymous certificates required for a Cv during a year will be 24×365=8760. Considering that the certificate size is 66 bytes (as indicated in Section 2), the total amount of space required will be approximately 565 KB, which is a reasonable overhead in terms of storage. As mentioned in Section 4.2., we assume that each Cv has a tamper-proof device for storage and management of confidential data (e.g., keys and pseudonymous certificates).


## 4.3.2. Participant Vehicle Registration Protocol

This protocol is executed during the annual vehicle inspection or whenever a user expresses his/her willingness to participate in the video reporting service. This protocol is composed of the following steps (see Figure3).Figure 3
Participating and Official Vehicle Registrations.A participant vehicle generates a random symmetric keysr1∈Z∗q and sends {Cv,5G_IDCv,PKEPKTA,Sr1} to the Department of Motor Vehicles (DMV), where Cv is the unique identification of the participating vehicle, 5G_IDCv is the 5G identification of the vehicle, PKTA is the public key of the trusted authority (TA) of the region which the participant vehicle is part of, and PKEx,y is the public key encryption function of message y using key x.Once the message is received, DMV verifies physically the correctness of theCv, then gets its current timestamp TS′, and creates the message M1=5G_IDCv,TS′,PKEPKTA,Sr1. Upon generation of M1, DMV signs M1 using its private key SKDMV by executing σM1=SignSKDMV,M1. Finally, DMV sends M1 and σM1 to TA.Upon receiving the message, TA verifies the freshness of the message by checking the fulfillment ofTS′′-TS′≤ΔTS, where TS′′ is the current timestamp of TA and ΔTS is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature σM1 as follows: Verify(PKDMV,M1,σM1). After signature verification, TA obtains Sr1 by executing PKDSKTA,PKEPKTA,Sr1 and then generates the set of private keys SKTA,5G_IDCvj and a set of pseudonymous certificates PCertTA,5G_IDCvj corresponding to 5G_IDCv, where PKDx,y is the public key decryption function of message y using key x. After that, TA returns the message M2 = {TS′′′,SEnc(Sr1,({SKTA,5G_IDCvj},{PCertTA,5G_IDCvj}, PKR(TA),PKABE(TA),Policy,IPCloud(TA),UCloud(TA), RegTA,TS′′′))} to DMV, where PKR(TA) is the public key of TA for Public Key Encryption with Keyword Search, PKABE(TA) is the public key of TA for the Attributed Based Encryption,Policy is the access policy of traffic accident videos uploaded by Cv (e.g., Policy={“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), IPCloud(TA) is the IP address of the Cloud Platform of TA, UCloud(TA)∈Z∗q is the a tag preagreed upon between TA and the Cloud Platform of TA (CloudTA), RegTA is the coordinate representing the geographical region controlled by TA, and TS′′′ is the current timestamp of TA.R
e
g
T
A is used for the handover process when Cv crosses to another geographical region controlled by another trusted authority (e.g., different states, districts, or cities). This process is explained later in the handover protocol section.DMV, once the message is received from TA, forwards it to the participating vehicle. Finally,Cv verifies the validity of TS′′′, then decrypts the received message using Sr1, and stores the decrypted values into its tamper-proof device.It is important to note that the DMV only sends5G_IDCv to the TA. This means that the relation between Cv and 5G_IDCv is kept only at the DMV. This will offer the feature of role separation, and consequently, more protection for the real identity of the participating vehicle, since 5G_IDCv is not a fixed value changeable during the next inspection/registration event.


## 4.3.3. Official Vehicle Registration Protocol

Figure3 illustrates both Participation Vehicles Registration and Official Vehicle Registration protocols, but the protocols are executed independently in different time.The official vehicles are also registered for this service to ensure that only authentic official vehicles will receive the notification of a traffic accident video (see Figure3). The official designated vehicle generates a random symmetric key Sr2∈Z∗q and sends {DVi,5G_IDDVi,PKEPKTA,Sr2} to the Law Enforcement Agency (LEA), where DVi is the unique identification of the official designated vehicle, 5G_IDDVi is the 5G identification corresponding to DVi, and PKTA is the public key of the trusted authority (TA) of the region which Cv and DVi are part of.Once the message is received, LEA verifies physically the correctness ofDVi, gets its attribute(s), AttributeDVi (e.g., “police vehicle,” “ambulance,” “traffic authority,” or “traffic law enforcement”), and generates the message M3=5G_IDDVi,TS2′,AttributeDVi,PKEPKTA,Sr2 and σM3=SignSKLEA,M3, where TS2′ is the current timestamp of LEA, SKLEA is the private key of LEA, and Signx,y is a digital signing of a message y using a private key x. Upon generating the messages, LEA sends M3 and σM3 to TA.After receiving the message, TA verifies the freshness of the message by checking the fulfillment ofTS2′′-TS2′≤DTS, where TS′′ is the current timestamp of TA and ΔTS is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature σM3 as follows: Verify(PKLEA,M3,σM3). After signature verification, TA obtains Sr2 by executing PKDSKTA,PKEPKTA,Sr2 and then generates the Attribute Based Encryption Private Key for DVi as follows: SKABE(TA,DVi)=ABE.DelegateMKTA,AttributeDVi. TA also generates a certificate CertTA,5G_IDDVi for DVi based on 5G_IDDVi and includes it into a message M4={T2′′′,SEnc(Sr2,CertTA,5G_IDDVi,SKABEDVi,T2′′′, IPCloud(TA))}, to finally send it to LEA. LEA receives M4 and forwards it to DVi.Upon receivingM4, DVi verifies the freshness of the message using ΔTS and decrypts M4 by executing SDecSr2,M4. Once decrypting M4, DVi compares the decrypted T2′′′ with the T2′′′ value received in plaintext to double verify the authenticity and freshness of the message. Finally, DVi stores the decrypted values into its tamper-proof device.Now, once registered with TA and LEA, it is time to execute the registration with the Cloud Platform. For this,DVi sends an registration request message to CloudTA. Once receiving the request, the Cloud Platform generates a random nonce N1 and transmits it to DVi. Upon receiving N1, DVi generates a random symmetric key Sr3 and a random nonce N2, calculates M5=PKEPKCloudTA,Sr3 and M6=SEncSr3,N1,N2,CertTA,5G_IDDVi, and sends {M5,M6} to CloudTA. The Cloud Platform then obtains Sr3 by executing PKDSKCloudTA,M5 and uses such value to obtain N1′,N2′,CertTA,5G_IDDVi=SDecSr3,M6. Once with N1′, CloudTA verifies the freshness of the message comparing the decrypted nonce N1′ with the one generated previously, N1, only if those values matching DVi are registered to the Cloud Platform. Closing the registration process, CloudTA registers CertTA,5G_IDDVi in its database and sends the decrypted N2′ to DVi to confirm its registration. Finally, DVi verifies the confirmation message by comparing the received N2′ with the previously generated N2.It is important to clarify that the communication betweenDVi and CloudTA uses random nonces to validate the freshness of messages instead of timestamps. This is because it is hard to maintain the clock of DVi and CloudTA synchronized. Timestamps are only used among LEA, DMV, and TA since they are trusted entities which can coordinate a reliable clock synchronization.


## 4.3.4. Handover Protocol

The proposed scheme solves the limitation of Eiza-Ni-Shi Scheme regarding the lack of contemplation of different regional areas that are under the management of different trusted authorities. The proposed scheme contributes with a novel handover protocol executed when a participating vehicleCv goes to a different regional area with another trusted authority.In Participating Vehicle Registration Protocol,Cv received RegTA which contains the coordinate of the geographical region controlled by TA. Such value is used to verify when handover is required. For this, Cv checks periodically its GPS coordinate with RegTA; when CoordinateCv∉RegTA, it initiates the handover protocol composed of the following steps (see Figure 4).Figure 4
Proposed handover protocol.First,Cv sends a handover request to TA. The TA then generates a random nonce N3 and sends it to Cv. Upon receiving the random nonce, Cv generates its own random nonce N4 and a random symmetric key Sr4 and calculates M7={PKEPKTA,Sr4,SEnc(Sr4,(N3,N4,5G_IDCv, CoordinateCv))} and σM7=Sign(SK5G_IDCvj,M7). Once calculating such values, Cv sends (M7,σM7,PCertTA,5G_IDCvj) to its trusted authority (TA), where PCertTA,5G_IDCvj is the first not used pseudo-certificate valid at current time. Once receiving the message, TA verifies the authenticity of σM7 and origin of PCertTA,5G_IDCvj by executing VerifySignPKTA,PCertTA,5G_IDCvj,σM7. TA also verifies if σM7 corresponds to the digital signature of M7 by performing VerifyPKTA,5G_IDCvj,M7,σM7. Once the authenticity of messages is verified, TA gets Sr4 by PKDSKTA,PKEPKTA,Sr4 and uses it to obtain N3′,N4′,5G_IDCv,CoordinateCv = SDec(Sr4,SEnc(Sr4,(N3,N4,5G_IDCv, CoordinateCv))). Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted N3′ with the previously generated N3. The nonce comparison allows TA to eliminate all possibilities of replay attacks from adversaries. Once the validity of handover request is verified, TA searches the away trusted authority (ATA) that controls the region where Cv currently is located.Once the adequate ATA is detected, TA mediates the registration ofCv in ATA. For this, TA requests a temporal registration of Cv to ATA. Upon receiving the request, ATA generates a random nonce N5 and sends it to TA. Once the connection with ATA is realized, TA generates a random nonce N6 and a random symmetric key Sr5 and calculates M8=PKEPKATA,Sr5,SEncSr5,N5,N6,5G_IDCv and σM8=SignSKTA,M8. Once the messages are calculated, TA sends M8,σM8 to ATA.Once receiving the message, ATA verifies the authenticity of the received signatureσM8 as follows: Verify(PKTA,M8,σM8). Upon signature verification, ATA obtains Sr5 by executing PKDSKATA,PKEPKATA,Sr5 and uses such value to get N5′,N6′,5G_IDCv = SDecSr5,SEncSr5,N5,N6,5G_IDCv. Later, ATA verifies the freshness of the message comparing the decrypted nonce N5′ with the previously generated N5. Only if those values match, ATA proceeds to respond to the registration request. Closing the temporal registration process, ATA generates the set of private keys SKATA,5G_IDCvj and a set of pseudonymous certificates PCertATA,5G_IDCvj corresponding to 5G_IDCv of Cv. After that, ATA returns the message M9 = SEnc(Sr5,({SKATA,5G_IDCvj}, {PCertATA,5G_IDCvj},PKR(ATA),PKABE(ATA),PolicyATA, IPCloud(ATA),UCloud(ATA),RegATA,N6′)) to TA, where PKR(ATA) is the public key of ATA for Public Key Encryption with Keyword Search, PKABE(ATA) is the public key of ATA for the Attributed Based Encryption, PolicyATA is the access policy of traffic accident videos uploaded by Cv (e.g., PolicyATA={“police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), IPCloud(ATA) is the IP address of the Cloud Platform of ATA, UCloud(ATA)∈Z∗q is the a tag preagreed upon between ATA and the Cloud Platform of ATA (CloudATA), and RegATA is the coordinate representing the geographical region controlled by ATA.Upon receiving the response from ATA, TA decryptsM9 using its random key Sr5. Once decrypting M9, TA verifies the authenticity of M9 by comparing N6′ with its own N6. This comparison allows TA to be sure that M9 came from the valid ATA. After verification, TA stores the decrypted values for historical data of Cv (only if required) and generates a new message M10 = SEnc(Sr4,({SKATA,5G_IDCvj},{PCertATA,5G_IDCvk}, PKR(ATA),PKABE(ATA),PolicyATA,IPCloud(ATA), UCloud(ATA),RegATA,N4′)) and sends it to Cv.Upon receiving the message,Cv decrypts M10 and verifies that the message came from the authentic TA freshly by comparing N4′ with N4. After verification Cv stores the decrypted values to its tamper-proof device.Note. Since the trusted authorities are in different regional areas and as it is hard to have clock synchronization, handshake using random nonces is used instead of timestamps to avoid replay attacks.


## 4.3.5. Video Transmission Protocol

When an accident occurs,Cv obtains the recorded video file through its cameras and initiates the video transmission protocol, which is composed of the following steps (see Figure 5).Figure 5
Video transmission and video search protocols.First,Cv generates a random symmetric key Sr6 and uses it to encrypt the video file TVr and its current GPS coordinate CoordinateCv as follows: ETVr=SEnc(Sr6,(TVr,CoordinateCv)). Then, Cv generates the keywords related to the accident kw and encrypts it using the Public Key Encryption with Keyword Search function as Ekw=PEKSPKR(TA),kw and calculates ESr6=ABE.EncPKABE(TA),Sr6,Policy. Additionally, Cv encrypts Sr6 using the Attribute Based Encryption function using PKABE(TA) andPolicy and creates a digital signature σ5G_IDCvj of generated messages using its current private key SKTA,5G_IDCvj. Finally, Cv clusters the generated messages into M11={hUCloud(TA),ETVr,Ekw,ESr6,σ5G_IDCvj, PCertTA,5G_IDCvj} and sends it to CloudTA over the 5G enabled vehicular network.Upon receivingM11, CloudTA checks if PCertTA,5G_IDCvj is in the Pseudo-Certificate Revocation List, PCRLCloud(TA), or in the Used Pseudo-Certificate List, UPCLCloud(TA), which is the list of the already used pseudo-certificates. It is important to remember that a pseudo-certificate is usable only once. If such pseudo-certificate is in PCRLCloud(TA) or UPCLCloud(TA), the received M11 is discarded; otherwise, CloudTA verifies the authenticity of the message by executing VerifySign(PKTA,PCertTA,5G_IDCvj,σ5G_IDCvj). If the certificate is proved to be valid, CloudTA stores such message and notifies the nearest designated vehicle DVi about the accident sending M11. We assume that the location information of the official vehicles is updated periodically in the cloud. The location of official vehicles is protected since it is transmitted using the public key of CloudTA  PKCloudTA.Once an official vehicleDVi receives the notification, it verifies the received pseudonymous certificate PCertTA,5G_IDCvj by executing VerifySign(PKTA,PCertTA,5G_IDCvj,σ5G_IDCvj). If the certificate is proved to be valid, DVi extracts the public key PKTA,5G_IDCvj of the sender from the certificate PCertTA,5G_IDCvj. Upon certificate validation, DVi verifies the received signature σ5G_IDCvj by executing Verify(PKTA,5G_IDCvj, (h(UCloud(TA)),ETVr,Ekw,ESr6),σ5G_IDCvj) and obtains the Sr6 using its Attributed Based Encryption private key SKABE(TA,DVi) as follows: Sr6=ABE.DecESr6,SKABE(TA,DVi). Finally, DVi gets the decrypted video and the last coordinate of Cv by executing (TVr,CoordinateCv)=SDec(Sr6,ETVr). Now, the official vehicles are able to go to the location of the accident using CoordinateCv and they can check the video of the accident while going to the location.


## 4.3.6. Video Search Protocol

Once the video transmission protocol is done and the video is uploaded to the Cloud Platform, it can be retrieved by LEA whenever it is needed. The video search protocol is executed as follows (see Figure5).First, LEA initiates a video search request toCloudTA. Then, CloudTA generates a random nonce N7 and sends it to LEA. Once receiving the response of CloudTA, LEA generates another random nonce N8 and a random symmetric key Sr7 and then generates the searchable trapdoor token as follows: Tkwi=TrapdoorSKR(TA),kwi, where kwi is a keyword (e.g., location, date, or “any video”) related to the video. Upon generation of the search token, LEA generates a message M12=PKEPKCloudTA,Sr7,SEncSr7,N7,N8,Tkwi and its digital signature σM12=SignSKLEA,M12 and sends them to the CloudTA.On the other side,CloudTA verifies the validity of the digital signature σM12 by performing VerifyPKLEA,M12,σM12 to be sure that the search request comes from the authentic LEA. Once validating the authenticity of the message, the Cloud Platform extracts Sr7 by PKDSKCloudTA,PKEPKCloudTA,Sr7 and uses it to get N7′,N8′,Tkwi=SDecSr7,SEncSt7,N7,N8,Tkwi. Once obtaining the data, CloudTA verifies the freshness of the message by comparing the decrypted nonce N7′ with the previously generated N7. If those values match, CloudTA authorizes Tkwi search process over the ciphertext at the cloud and executes TestPKR(TA),Ekw,Tkwi. Once the video is founded, a new message M12={h(UCloudTA),ETVr,Ekw,ESr6, σ5G_IDCvj,PCertTA,5G_IDCvj,SEnc(Sr7,N8)} is generated and it is sent to the LEA.Upon receivingM12, LEA extracts N8′ by executing SDec(SEncSr7,N8′ and compares it with the previously generated N8 to validate the authenticity and freshness of the message. The comparison of random nonces allows LEA to verify the freshness since the received nonce corresponds to the last one created by itself. The nonce comparison also allows the verification of authenticity of CloudTA since the sent nonce can only be decrypted by the authentic CloudTA having the private key SKCloudTA.


## 4.3.7. Pseudo-Certificate Revocation

This protocol is executed when a participating vehicleCv needs to stop its participation in the video reporting services, either because the user expressed his/her willingness to stop the service, because the car was robbed, or because the pseudo-certificates stored in the car have been exposed. This protocol is composed of the following steps (see Figure 6).Figure 6
Pseudo-Certificates Revocation Protocol.First, the owner of the participating vehicleOwnerCv indicates his/her willingness to stop the video reporting services to the DMV by delivering his/her identification IDOwnerCv (e.g., driver’s license). Once the request is received, the DMV verifies the authenticity of IDOwnerCv and gets Cv and 5G_IDCv corresponding to OwnerCv. Then, the DMV gets its current timestamp TS3′, generates a random nonce N9, and calculates M13=5G_IDCv,TS3′,PKEPKTA,N9 and σM13=SignSKDMV,M13. Once such values are calculated, DMV sends (M13,σM13) to the TA. Once the message is received, TA verifies the freshness of the message using its timestamp TS3′′ and verifies the authenticity of σM13 by executing VerifyPKDMV,M13,σM13. Once the authenticity of the message is verified, TA gets N9 by PKDSKTA,PKEPKTA,N9 and adds the pseudo-certificates belonging to 5G_IDCv to Cv’s Peudo-Certificate Revocation List, PCRLCv. Once PCRLCv is updated, DMV returns the decrypted N9′ to DVM. Finally, the DMV verifies the correct execution of the request by comparing the received message with the N9 generated by itself and then informs the OwnerCv about the correct execution of the requested process.On the other hand, the TA executes the Pseudo-Certificates Revocation process with the Cloud Platform. For this, the TA sends a request message toCloudTA. CloudTA then generates a random nonce N10 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce N11 and a random symmetric key Sr8 and calculates M14=PKEPKCloudTA,Sr8,SEncSr8,N10,N11,PCRLCv and σM14=Sign(SKTA,M14). Once such values are calculated, TA sends (M14,σM14) to its Cloud Platform. Once the message is received, CloudTA verifies the authenticity of the message by executing VerifyPKTA,M14,σM14. Once the authenticity of the message is verified, CloudTA gets Sr8 by PKDSKCloudTA,PKEPKCloudTA,Sr8 and uses it to obtain N10′,N11′,PCRLCv=SDecSr4,SEncSr8,N10,N11,PCRLCv. Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted N10′ with the previously generated N10. Once the validity of Pseudo-Certificates Revocation request is verified, CloudTA adds PCRLCv to the Pseudo-Certificates Revocation List of the Cloud Platform, PCRLCloud(TA). Once PCRLCloud(TA) is updated, CloudTA returns the decrypted N11′ to TA. Finally, the TA verifies the correct execution of the request by comparing the received message with the N11 generated by itself.Note. The Pseudo-Certificates Revocation Protocol can also be executed by a designated authority (e.g., police officer) when detecting a misbehaving Cv. In this case, the designated authority requests the Pseudo-Certificates Revocation to LEA instead of DMV. The following steps will be the same; the only difference is that the participating entities will be LEA–TA–CloudTA instead of DMV–TA–CloudTA.


## 4.3.8. Interregion Pseudo-Certificate Revocation

This stage is executed after the Pseudo-Certificate Revocation Protocol, only if the participating vehicleCv has been in another region and received pseudo-certificates from an ATA. TA can know if Cv has been in another region since it was the intermediary executing the handover protocol. This protocol is composed of the following steps (see Figure 7).Figure 7
Interregion Pseudo-Certificates Revocation Protocol.First, TA sends a Pseudo-Certificates Revocation request to ATA whereCv has received pseudo-certificates. The ATA then generates a random nonce N12 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce N13 and a random symmetric key Sr9 and calculates M15={PKE(PKTA,Sr9), SEnc(Sr9,(N12,N13,5G_IDCv,PCRLCv))}, and σM15=Sign(SKTA,M15). Once such values are calculated, TA sends (M15,σM15) to ATA. Once the message is received, ATA verifies the authenticity of the message by executing VerifyPKTA,M15,σM15. After verification, ATA gets Sr9 by PKDSKTA,PKEPKTA,Sr9 and uses it to obtain N12′,N13′,5G_IDCv,PCRLCv = SDecSr9,SEncSr9,N12,N13,5G_IDCv,PCRLCv. Upon decrypting the data, ATA verifies the freshness of the message by comparing the decrypted N12′ with the previously generated N12. Once the validity of the request is verified, ATA adds the pseudo-certificates belonging to 5G_IDCv to Cv’s Pseudo-Certificate Revocation List, PCRLCv.On the other hand, the ATA also executes the Pseudo-Certificates Revocation process with the Cloud Platform. For this, the ATA sends a request message toCloudATA. CloudATA then generates a random nonce N14 and sends it to ATA. Upon receiving the random nonce, ATA generates its own random nonce N15 and a random symmetric key Sr10 and calculates M16={PKE(PKCloudATA,Sr10), SEnc(Sr10,(N14,N15,PCRLCv))}, and σM16=Sign(SKATA,M16). Once such values are calculated, ATA sends (M16,σM16) to its Cloud Platform. Once the message is received, CloudATA verifies the authenticity of the message by executing VerifyPKATA,M16,σM16. Once the authenticity of the message is verified, CloudATA gets Sr10 by PKDSKCloudATA,PKEPKCloudATA,Sr10 and uses it to obtain N14′,N15′,PCRLCv = SDecSr10,SEncSr10,N14,N15,PCRLCv. Upon decrypting the data, CloudATA verifies the freshness of the message by comparing the decrypted N14′ with the previously generated N14. Once the validity of Pseudo-Certificates Revocation request is verified, CloudATA adds PCRLCv to the Pseudo-Certificates Revocation List of the Cloud Platform PCRLCloud(ATA). Once PCRLCloud(ATA) is updated, CloudATA returns the decrypted N15′ to ATA. Finally, the ATA verifies the correct execution of the request by comparing the received message with the N15 generated by itself.


## 4.4. Security Analysis of the Proposed Solution

This section analyzes the proposed scheme in terms of security. It shows how the enhanced solution is secure against different attacks and it is superior to the previous work (see Table1).Table 1
Comparison of security and functionality features.
Feature
Eiza-Ni-Shi Scheme
Proposed scheme
Authentication and nonrepudiation
Yes
Yes
Conditional anonymity and privacy
Yes
Yes
Traceability
Yes
Yes
Management of multiple trusted authorities
No
Yes
Protection against DMV impersonation attack
No
Yes
Protection against forged video upload
No
Yes
Separation of responsibilities between LEA and TA
No
Yes
Protection against privileged insider attack in LEA
No
Yes
Protection against LEA impersonation attack
No
Yes
Exposure of location of official vehicles
No
Yes
Management of multiple TAs
No
YesAuthentication and Nonrepudiation. The proposed solution provides authentication and nonrepudiation of videos by using the fundaments of public key cryptography. The Cloud Platform can be sure that the video is uploaded by an authentic participant vehicle since Cv delivers its pseudonymous certificate PCertTA,5G_IDCvj. Such certificate can be validated by using the public key of the trusted authority which issued such certificate.Conditional Anonymity and Privacy. As well as in the previous work, the proposed solution provides conditional anonymity and privacy by using the pseudonymous authentication technique. Since the video is authenticated with the pseudonymous certificate, even if the Cloud Platform is compromised, the adversary Ua will not be able to know the real identity of the participating vehicle. Additionally, since each pseudonymous certificate is usable once and has an expiration time, it will be infeasible for Ua to correlate Cv with PCertTA,5G_IDCvj.DMV Impersonation Attack. DMV impersonation attack is avoided using the principles of public key cryptography. The participant vehicle registration request message M1 is accompanied with its digital signature σM1 signed by the private key of DMV. The TA can verify the origin of the message since it can verify the authenticity of σM1 using the public key of DMV PKDMV.Forged Video Upload. Thanks to the protection against the DMV impersonation attack, the adversary Ua cannot obtain the valid private keys, pseudonymous certificates. Therefore, forged video upload is not possible.Replay Attack. Replay attacks are avoided using timestamps or handshaking using random nonces. Lightweight timestamps technique is used in communications among DMV, TA, and LEA, since they are trusted entities that can easily have a synchronized clock. On the other hand, a handshaking using random nonces is used in communication between Cv and TA (in handover protocol), TA and ATA (in handover protocol), CloudTA and LEA (in video search protocol), and DVi and CloudTA (in Official Vehicle Registration protocol) since it is hard to have a synchronized clock between those entities.Nonseparation of Responsibilities between LEA and TA. The proposed scheme provides a separation of responsibilities between LEA and TA. This security mechanism will allow only LEA to manage the mapping of the unique identity of DVi and 5G_IDDVi. On the other hand, by using Sr2 encrypted with PKTA the confidentiality of CertTA,5G_IDDVi, SKABE(TA,DVi) is maintained from LEA. This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle DVi.Privileged Insider Attack in LEA. Since LEA receives CertTA,5G_IDDVi, SKABE(TA,DVi) encrypted with Sr2 (only known as the official vehicle), LEA cannot obtain such values. This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle DVi.LEA Impersonation Attack. LEA impersonation attack is avoided using the principles of public key cryptography. The Official Vehicle Registration request message M3 is accompanied with its digital signature σM3 signed by the private key of LEA. The TA can verify the origin of the message since it can verify the authenticity of σM3 using the public key of LEA PKLEA.Sybil Attack. To execute this kind of attack, the attacker must have nonrevoked, nonused, nonexpired, and authentic pseudo-certificates since the Cloud Platform verifies the validity (pseudo-certificate must not be revoked and expired) and authenticity (issued by the valid TA) of the pseudo-certificate attached to the video upload message. First, the attacker can try to listen to the network to capture a valid pseudo-certificate to reuse it later. However, this scenario is not a problem since the Cloud Platform has UPCLCloud(TA) verification making the reuse of valid pseudo-certificates impossible. On the other hand, the attacker also can try to access the set of pseudo-certificates stored in Cv; since the pseudo-certificates are stored in secure storage devices this kind of attack is not also possible. Finally, the attacker can also try to guess a valid pseudo-certificate. This scenario is also not feasible since the video upload message includes a signature signed by a private key; this means that the attacker must guess not only a valid, not used, and not expired pseudo-certificate, but also its private key. We believe that such scenario is not feasible.Exposure of Location of Official Vehicles. The present scheme provides a simple solution for this issue. The exposure of location of official vehicles is avoided by encrypting them using the public key of the Cloud Platform. Since the location information can only be decrypted by the authentic cloud with the corresponding private key, the adversary cannot obtain such information.Management of Multiple Trusted Authorities. The proposed scheme includes a novel handover protocol which is executed when a participating vehicle Cv goes to a different regional area controlled by another trusted authority. This mechanism will help the real implementation of the proposed service, adapted to the common administrative structure of entities grouped in different geographical/administrative regions.


## 4.5. Performance Analysis of the Proposed Solution

Since the intention of this analysis is to compare the overhead generated by the new security and functionality features of the proposed scheme with the previous one, the present work has used the same benchmark environment as [7]. It means that all the benchmarks were executed on a computer with Intel Core i7-2600 3.4 GHz processor using Crypto++ library 5.6.2 [15].Two overheads are calculated in this section. (1) First, the time overhead in video transmission protocol is calculated and it is compared with the previous work. As well as [7], the overhead of vehicle registration protocols is not calculated since the generation and storage of pseudonymous certificates and signing keys are executed only once a year during the vehicles’ inspection or service registration and because it is not a critical overhead for the real-time video reporting service. (2) After that, we analyze the overhead generated in handover protocol. The overhead of handover protocol is calculated autonomously without comparison with the previous work since it is a novel feature included only in the proposed scheme.


### 4.5.1. Overhead Generated in Video Transmission Protocol

Before making the overhead calculation, it is important to select the certificate scheme for authentication of reported videos. The proposed scheme suggests the usage of PASS [8] as the mechanism for authentication of videos uploaded to the Cloud Platform, not only because it has one of the lowest overheads in terms of time for signing, certificate validation, and signature verification (see Table 2), but also because it solves the limitation of BP [16]. However, other algorithms such as BP [16], ECPP [17], DCS [18], and hybrid one [19] can be considered. Table 2 shows the time required for generation and verification of signatures and certificate verification using different algorithms [8] (same for both Eiza-Ni-Shi Scheme and proposed scheme). The total overhead generated in video transmission protocol is composed of three elements: (a) video encryption, (b) video transmission, and (c) video decryption by official vehicles. It is important to mention that the overhead calculation of random number generation was omitted since it is a minimal value.Table 2
Overhead for signing, certificate verification, and signature verification for Eiza-Ni-Shi Scheme and proposed scheme.
Certificate scheme
Signing time (ms)
Certificate verification time (ms)
Signature verification time (ms)
Total (ms)
BP
0.6
1.2
1.2
3
ECPP
0.6
18.9
1.2
20.7
DCS
1.2
14.7
14.1
30
Hybrid
0.6
18.9 + 9Ncrl
1.2
20.7 + 9Ncrl
PASS
0.6
14.7
1.2
16.5
N
c
r
l: size of certificate revocation list.Video Encryption. The overhead calculation for video encryption was executed using the benchmark data delivered by [7]. Using such data, it is possible to deduce that the time required to perform the encryption operation Ekw=PEKSPKR(TA),kw is approximately 36.52 ms, the time required for the encryption process ESr6=ABE.EncPKABE(TA),Sr6,Policy is approximately 62 ms (withPolicy containing 4 attributes), and the time required for signature generation σ5G_IDCvj=Sign(SKTA,5G_IDCvj,hashValue) is approximately 0.6 ms using the PASS scheme where hashValue=hhUCloud(TA),ETVr,Ekw,ESr6 (see Table 2). Additionally, the time required in executing ETVr=SEncSr6,TVr,CoordinateCv is illustrated in Figure 8, where the overheads for encryption of the video file are 455 MB/s when using AES/CBC, 147 MB/s when using Twofish/CTR, and 65 MB/s when using Serpent/CTR; all algorithms use 256-bit keys.Figure 8
Symmetric encryption overhead using different algorithms.It is notorious that most of the overhead of this stage of the protocol is the symmetric encryption of the video file corresponding toETVr=SEncSr6,TVr,CoordinateCv calculation. Since most of the overhead of this stage is the symmetric encryption of the video, the proposed system recommends encrypting the traffic accident video file while capturing it to minimize the time required for encryption before transmission.Video Transmission. In the same way, the video transmission overhead calculation was based on data delivered by [7]. Such reference indicates that the estimated time required to upload/download the encrypted video file of 2 GB to/from the Cloud Platform using 5G communication is Tcomm = 13.3 s assuming that the vehicle speed is 100 km/h and 5G connection speed is 1.2 Gbps. Based on this data, the video transmission protocol will require a total of 13.3 s for uploading 2 GB-size encrypted video by the participant vehicle and 13.3 s for downloading the same video by the official vehicles.Video Decryption. The overhead calculation for video decryption was executed using the benchmark data delivered by [7]. Using such data, it is possible to deduce that the time required for VerifySign(PKTA,PCertTA,5G_IDCvj, σ5G_IDCvj) is 14.7 ms when using the PASS scheme. The time required to execute Verify(PKTA,5G_IDCvj,(h(UCloud(TA)), ETVr,Ekw,Esr6),σ5G_IDCvj) step is 1.2 ms and the time required for Sr6=ABE.DecESr6,SKABE(TA,DVi) is approximately 18 ms. Additionally, the time required in executing the decryption of the encrypted video ETVr is similar to the ones shown in Figure 8. As well as in video encryption, most of the overhead of this stage of the protocol is the symmetric decryption of the encrypted video file.Total Overhead of Video Transmission Protocol. As well as the previous work, the proposed scheme can report the traffic accident of the participant vehicle in less than a minute using AES/CBC cryptographic algorithm over a 2 GB video file assuming that the participating vehicle is encrypting the traffic accident video file while capturing it (the time required for encryption before transmission is reduced to a minimal value). As shown in Table 3, the additional overhead required by the proposed scheme compared to the Eiza-Ni-Shi Scheme is only the time required for one random number generation which is almost none in actual devices.Table 3
Total overhead of video transmission protocol when AEC/CBC is used and video size is 2 GB.
Eiza-Ni-Shi Scheme
Proposed scheme
Video encryption
4.5099 s
4.5099 s + time for random number generation
Video transmission
13.3 s
13.3 s
Video decryption
4.5033 s
4.5033 s
Total
22,3132 s
22,3132 s + time for random number generation


### 4.5.2. Overhead Generated in Handover Protocol

As well as in video transmission protocol, the steps related to random number generation were omitted for overhead calculation since their overhead is small and it is insignificant to the total overhead. On the other hand, the overhead calculation of message transmission was also omitted since its value is minimal assuming that 5G communication link is used amongCv, TA, and ATA.For the calculation of overhead generated in handover protocol, we assume that TA and ATA communicate securely using the RSA algorithm (2048-bit key) whileCv authenticates with TA using the PASS [8] algorithm. The overhead calculation was based on Crypto++ 5.6.0 benchmarks [20, 21].The total overhead of the handover protocol is composed of three components: (1) Participating Vehicle Overhead, (2) TA Mediation Overhead, and (3) ATA Response Overhead.Participating Vehicle Overhead. This is the overhead generated by steps executed by Cv. In this part, Cv executes one public key encryption step, one symmetric key encryption step, one symmetric key decryption step, and one signing step using PASS. Assuming that random numbers, 5G_IDCV, CoordinateCv, and symmetric keys are 256 bits long, it is possible to deduce that the time required to perform M7 = {PKE(PKTA,Sr4), SEnc(Sr4,(N3,N4,5G_IDCv,CoordinateCv))} is approximately 0.16 ms, the time required to execute σM7=SignSK5G_IDCvj,M7 is 0.6 ms, and the time required to execute SDecSr4,M10 is approximately (N/10) ms, where N is the number of pseudonymous certificates issued by ATA. In summary, the total overhead of participating vehicle is ((N/100) + 0.76) ms. Table 4 shows the calculation of the overhead with different number of issued pseudonymous certificates.Table 4
Handover protocol overhead.
Number of pseudo-certificates
Participating Vehicle Overhead (seconds)
TA Mediation Overhead (seconds)
ATA Response Overhead (seconds)
Total overhead (seconds)
24 (for a day)
0.0032
0.0215
0.0753
0.1239
48 (for 2 days)
0.0056
0.0263
0.1433
0.2231
168 (for a week)
0.0176
0.0503
0.4834
0.7192
720 (for a month)
0.0728
0.1607
2.0477
3.0012
2160 (for 3 months)
0.2168
0.4487
6.1287
8.9541
4320 (for 6 months)
0.4328
0.8807
12.2501
17.8836
8760 (for a year)
0.8768
1.7687
24.8331
36.2385TA Mediation Overhead. This is the overhead generated by performing steps executed by TA. Here is the overhead calculation: the time required to perform VerifySignSKTA,PCertTA,5G_IDCvj,σM7 is approximately 1.2 ms, the time required to execute VerifyPKTA,5G_IDCvj,M7,σM7 is 1.2 ms, the time required to execute PKDSKTA,PKEPKTA,Sr4 is approximately 6.08 ms, the time required to execute SDecSr4,SEncSr4,N3,N4,5G_IDCv,CoordinateCv is less than 1 ms, the time required to execute M8 = PKEPKATA,Sr5,SEncSr5,N5,N6,5G_IDCv is approximately 1.16 ms, the time required to execute σM8=SignSKTA,M8 is 6.05 ms, the time required to decrypt M9 using Sr5 is approximately (N/10) ms, and the time required to perform M10 = SEnc(Sr4,({SKATA,5G_IDCvj}, {PCertATA,5G_IDCvj},PKR(ATA),PKABE(ATA),PolicyATA, IPCloud(ATA),UCloud(ATA),RegATA,N4′)) is approximately (N/10) ms. In summary, the total TA Mediation Overhead is ((2N/10)+16.69) ms. Table 4 and Figure 9 show the calculation of the overhead with different number of issued pseudonymous certificates.Figure 9
Total overhead of handover protocol according the number of issued pseudonymous certificates.ATA Response Overhead. This is the overhead generated by steps executed by ATA. Here is the overhead calculation: the time required to perform VerifyPKTA,M8,σM8 is approximately 0.16 ms, the time required to execute PKDSKATA,PKEPKATA,Sr5 is 6.08 ms, the time required to execute SDecSr5,SEncSr5,N5,N6,5G_IDCv is less than 1 ms, the time required to generate SKATA,5G_IDCvj, PCertATA,5G_IDCvj is approximately (2.734N) ms, and the time required to execute M9 = SEnc(Sr5,({SKATA,5G_IDCvj},{PCertATA,5G_IDCvj}, PKR(ATA),PKABE(ATA),PolicyATA,IPCloudA(TA), UCloud(ATA),RegATA,N6′)) is approximately (N/10) ms. In summary, the total ATA Response Overhead is (2.834N + 7.24) ms. Table 4 shows the calculation of the overhead with different number of issued pseudonymous certificates.It is important to calculate the overhead generated in the handover protocol because the distance of the intersection zone of two regions depends on the overhead of handover protocol and the maximum speed of the participating vehicle (see Figure10). In other words, the distance d is calculated as follows: d=Overhead×MaxSpeedCv, where d is the distance of the intersection zone, Overhead is the total time overhead of the handover protocol, and MaxSpeedCv is the maximum speed a participating vehicle can reach. The calculation of d is important for planning the coordinate of regions controlled by each trusted authority, since Cv needs to receive the pseudonymous certificates issued by ATA before exiting from its own region. If Cv has an accident in the intersection zone, the video is uploaded first in its own region and then it is uploaded to the region controlled by ATA (if the handover process is already finished). The minimum distance required for intersection zone of two regions when MaxSpeedVi=200km/h is indicated in Table 5 and Figure 11.Table 5
Distance of intersection zone.
Number of pseudo-certificates
Total overhead (seconds)
Distance (km)
24 (for a day)
0.1239
0.0069
48 (for 2 days)
0.2231
0.0124
168 (for a week)
0.7192
0.0400
720 (for a month)
3.0012
0.1667
2160 (for 3 months)
8.9541
0.4975
4320 (for 6 months)
17.8836
0.9935
8760 (for a year)
36.2385
2.0133
Corresponding data when MaxSpeedVi = 200 km/h.Figure 10
Relation between handover overhead and intersection zone.Figure 11
Minimum distance of intersection zone of two regions according to the number of issued pseudonymous certificates.Since the participating vehicles must renew the registration to the service annually, the number of pseudonymous certificates issued for handover should be much less than 8760 (for a year). We believe that certificates for 3 months should be enough for this purpose. If there is an extraordinary case when participating vehicle needs to stay in the region controlled by ATA for a long period of time, the participating vehicle can execute the handover protocol again when its pseudonymous certificate is running out. Assuming that the handover protocol is implemented with 2160 pseudonymous certificates the total overhead would be less than 9 seconds andd would be less than 0.5 km which would be very reasonable for real implementation.


### 4.5.3. Analysis of Region Organization

The intention of this subsection is to analyze the size of a region and the overhead caused by the handover protocol when a vehicle visits different number of regions.Size of a Region. It is very hard to determinate the size of a region since it depends on the needs of each country. But we recommend following the regulation of each country in administering the vehicle registration and driver licensing. For example, in the United States, there is an institution called Department of Motor Vehicles (DMV) which is a state-level government that administer vehicle registration and driver licensing. Since each country has similar departments, we recommend that each region for the proposed service must incorporate the geographical area controlled by a DMV, for example, an individual state for United States of America.Overhead of Handover Protocol When Visiting Different Regions. For this analysis, we have taken the following assumptions: (1) the size of a region is determined by the geographical area controlled by a DMV, that is, an individual state, and (2) since we have recommended the usage of pseudo-certificate for three months (2160 pseudo-certificates) in handover protocol (in the previous subsection), we will use such values for this analysis.Statistical data such as [22, 23] indicates that most of drivers use their motorized vehicles for activities of daily life, which means that they drive inside the same town most of the time. It means that most of participating vehicles will not execute or will rarely execute the handover protocol. However, for this analysis, we will consider all kinds of possibilities, including three kinds of vehicles: (1) ordinary vehicle which rarely leaves its region/state, (2) vehicles of people living in the border of a region/state which will make them visit the neighbor region/state frequently, and (3) extraordinary vehicles traveling several states frequently (e.g., interstate buses or cargo trucks).For the first kind of vehicles (ordinary vehicles), the overhead caused by the handover protocol will be minimal since they will not execute or rarely execute such protocol. For the second kind of vehicles (living in a border), they will execute the handover protocol when visiting the neighbor region; however, the vehicle will not execute the handover protocol each time it crosses the border, but when all pseudo-certificates have been used or expired, that is, three months. In this second case, the overhead caused by the handover protocol will also be minimal since vehicles will execute the handover protocol (normally) every three months. Finally, Table6 shows the overhead caused for the third kind of vehicles. Such data indicates the overhead generated when visiting different number of external regions every three months. For example, if a vehicle visits 5 different regions/states, it will spend a total of 44,77 seconds. We believe that the overhead of 44,77 seconds in three months is not a problem in implementing the proposed service. It is important to mention that the process is not executed during 44,77 seconds; instead Cv executes the 8,95 seconds’ process each time it enters a new region.Table 6
Handover protocol overhead when visiting several regions with pseudo-certificates for 3 months.
Number of different external regions visited by Cv
Total overhead(seconds)
1
8.95
2
17.90
5
44.77
10
89.54
20
179.08This analysis has shown how the overhead caused in crossing different regions will not be a problem in implementing the proposed solution nationwide.


## 4.5.1. Overhead Generated in Video Transmission Protocol

Before making the overhead calculation, it is important to select the certificate scheme for authentication of reported videos. The proposed scheme suggests the usage of PASS [8] as the mechanism for authentication of videos uploaded to the Cloud Platform, not only because it has one of the lowest overheads in terms of time for signing, certificate validation, and signature verification (see Table 2), but also because it solves the limitation of BP [16]. However, other algorithms such as BP [16], ECPP [17], DCS [18], and hybrid one [19] can be considered. Table 2 shows the time required for generation and verification of signatures and certificate verification using different algorithms [8] (same for both Eiza-Ni-Shi Scheme and proposed scheme). The total overhead generated in video transmission protocol is composed of three elements: (a) video encryption, (b) video transmission, and (c) video decryption by official vehicles. It is important to mention that the overhead calculation of random number generation was omitted since it is a minimal value.Table 2
Overhead for signing, certificate verification, and signature verification for Eiza-Ni-Shi Scheme and proposed scheme.
Certificate scheme
Signing time (ms)
Certificate verification time (ms)
Signature verification time (ms)
Total (ms)
BP
0.6
1.2
1.2
3
ECPP
0.6
18.9
1.2
20.7
DCS
1.2
14.7
14.1
30
Hybrid
0.6
18.9 + 9Ncrl
1.2
20.7 + 9Ncrl
PASS
0.6
14.7
1.2
16.5
N
c
r
l: size of certificate revocation list.Video Encryption. The overhead calculation for video encryption was executed using the benchmark data delivered by [7]. Using such data, it is possible to deduce that the time required to perform the encryption operation Ekw=PEKSPKR(TA),kw is approximately 36.52 ms, the time required for the encryption process ESr6=ABE.EncPKABE(TA),Sr6,Policy is approximately 62 ms (withPolicy containing 4 attributes), and the time required for signature generation σ5G_IDCvj=Sign(SKTA,5G_IDCvj,hashValue) is approximately 0.6 ms using the PASS scheme where hashValue=hhUCloud(TA),ETVr,Ekw,ESr6 (see Table 2). Additionally, the time required in executing ETVr=SEncSr6,TVr,CoordinateCv is illustrated in Figure 8, where the overheads for encryption of the video file are 455 MB/s when using AES/CBC, 147 MB/s when using Twofish/CTR, and 65 MB/s when using Serpent/CTR; all algorithms use 256-bit keys.Figure 8
Symmetric encryption overhead using different algorithms.It is notorious that most of the overhead of this stage of the protocol is the symmetric encryption of the video file corresponding toETVr=SEncSr6,TVr,CoordinateCv calculation. Since most of the overhead of this stage is the symmetric encryption of the video, the proposed system recommends encrypting the traffic accident video file while capturing it to minimize the time required for encryption before transmission.Video Transmission. In the same way, the video transmission overhead calculation was based on data delivered by [7]. Such reference indicates that the estimated time required to upload/download the encrypted video file of 2 GB to/from the Cloud Platform using 5G communication is Tcomm = 13.3 s assuming that the vehicle speed is 100 km/h and 5G connection speed is 1.2 Gbps. Based on this data, the video transmission protocol will require a total of 13.3 s for uploading 2 GB-size encrypted video by the participant vehicle and 13.3 s for downloading the same video by the official vehicles.Video Decryption. The overhead calculation for video decryption was executed using the benchmark data delivered by [7]. Using such data, it is possible to deduce that the time required for VerifySign(PKTA,PCertTA,5G_IDCvj, σ5G_IDCvj) is 14.7 ms when using the PASS scheme. The time required to execute Verify(PKTA,5G_IDCvj,(h(UCloud(TA)), ETVr,Ekw,Esr6),σ5G_IDCvj) step is 1.2 ms and the time required for Sr6=ABE.DecESr6,SKABE(TA,DVi) is approximately 18 ms. Additionally, the time required in executing the decryption of the encrypted video ETVr is similar to the ones shown in Figure 8. As well as in video encryption, most of the overhead of this stage of the protocol is the symmetric decryption of the encrypted video file.Total Overhead of Video Transmission Protocol. As well as the previous work, the proposed scheme can report the traffic accident of the participant vehicle in less than a minute using AES/CBC cryptographic algorithm over a 2 GB video file assuming that the participating vehicle is encrypting the traffic accident video file while capturing it (the time required for encryption before transmission is reduced to a minimal value). As shown in Table 3, the additional overhead required by the proposed scheme compared to the Eiza-Ni-Shi Scheme is only the time required for one random number generation which is almost none in actual devices.Table 3
Total overhead of video transmission protocol when AEC/CBC is used and video size is 2 GB.
Eiza-Ni-Shi Scheme
Proposed scheme
Video encryption
4.5099 s
4.5099 s + time for random number generation
Video transmission
13.3 s
13.3 s
Video decryption
4.5033 s
4.5033 s
Total
22,3132 s
22,3132 s + time for random number generation


## 4.5.2. Overhead Generated in Handover Protocol

As well as in video transmission protocol, the steps related to random number generation were omitted for overhead calculation since their overhead is small and it is insignificant to the total overhead. On the other hand, the overhead calculation of message transmission was also omitted since its value is minimal assuming that 5G communication link is used amongCv, TA, and ATA.For the calculation of overhead generated in handover protocol, we assume that TA and ATA communicate securely using the RSA algorithm (2048-bit key) whileCv authenticates with TA using the PASS [8] algorithm. The overhead calculation was based on Crypto++ 5.6.0 benchmarks [20, 21].The total overhead of the handover protocol is composed of three components: (1) Participating Vehicle Overhead, (2) TA Mediation Overhead, and (3) ATA Response Overhead.Participating Vehicle Overhead. This is the overhead generated by steps executed by Cv. In this part, Cv executes one public key encryption step, one symmetric key encryption step, one symmetric key decryption step, and one signing step using PASS. Assuming that random numbers, 5G_IDCV, CoordinateCv, and symmetric keys are 256 bits long, it is possible to deduce that the time required to perform M7 = {PKE(PKTA,Sr4), SEnc(Sr4,(N3,N4,5G_IDCv,CoordinateCv))} is approximately 0.16 ms, the time required to execute σM7=SignSK5G_IDCvj,M7 is 0.6 ms, and the time required to execute SDecSr4,M10 is approximately (N/10) ms, where N is the number of pseudonymous certificates issued by ATA. In summary, the total overhead of participating vehicle is ((N/100) + 0.76) ms. Table 4 shows the calculation of the overhead with different number of issued pseudonymous certificates.Table 4
Handover protocol overhead.
Number of pseudo-certificates
Participating Vehicle Overhead (seconds)
TA Mediation Overhead (seconds)
ATA Response Overhead (seconds)
Total overhead (seconds)
24 (for a day)
0.0032
0.0215
0.0753
0.1239
48 (for 2 days)
0.0056
0.0263
0.1433
0.2231
168 (for a week)
0.0176
0.0503
0.4834
0.7192
720 (for a month)
0.0728
0.1607
2.0477
3.0012
2160 (for 3 months)
0.2168
0.4487
6.1287
8.9541
4320 (for 6 months)
0.4328
0.8807
12.2501
17.8836
8760 (for a year)
0.8768
1.7687
24.8331
36.2385TA Mediation Overhead. This is the overhead generated by performing steps executed by TA. Here is the overhead calculation: the time required to perform VerifySignSKTA,PCertTA,5G_IDCvj,σM7 is approximately 1.2 ms, the time required to execute VerifyPKTA,5G_IDCvj,M7,σM7 is 1.2 ms, the time required to execute PKDSKTA,PKEPKTA,Sr4 is approximately 6.08 ms, the time required to execute SDecSr4,SEncSr4,N3,N4,5G_IDCv,CoordinateCv is less than 1 ms, the time required to execute M8 = PKEPKATA,Sr5,SEncSr5,N5,N6,5G_IDCv is approximately 1.16 ms, the time required to execute σM8=SignSKTA,M8 is 6.05 ms, the time required to decrypt M9 using Sr5 is approximately (N/10) ms, and the time required to perform M10 = SEnc(Sr4,({SKATA,5G_IDCvj}, {PCertATA,5G_IDCvj},PKR(ATA),PKABE(ATA),PolicyATA, IPCloud(ATA),UCloud(ATA),RegATA,N4′)) is approximately (N/10) ms. In summary, the total TA Mediation Overhead is ((2N/10)+16.69) ms. Table 4 and Figure 9 show the calculation of the overhead with different number of issued pseudonymous certificates.Figure 9
Total overhead of handover protocol according the number of issued pseudonymous certificates.ATA Response Overhead. This is the overhead generated by steps executed by ATA. Here is the overhead calculation: the time required to perform VerifyPKTA,M8,σM8 is approximately 0.16 ms, the time required to execute PKDSKATA,PKEPKATA,Sr5 is 6.08 ms, the time required to execute SDecSr5,SEncSr5,N5,N6,5G_IDCv is less than 1 ms, the time required to generate SKATA,5G_IDCvj, PCertATA,5G_IDCvj is approximately (2.734N) ms, and the time required to execute M9 = SEnc(Sr5,({SKATA,5G_IDCvj},{PCertATA,5G_IDCvj}, PKR(ATA),PKABE(ATA),PolicyATA,IPCloudA(TA), UCloud(ATA),RegATA,N6′)) is approximately (N/10) ms. In summary, the total ATA Response Overhead is (2.834N + 7.24) ms. Table 4 shows the calculation of the overhead with different number of issued pseudonymous certificates.It is important to calculate the overhead generated in the handover protocol because the distance of the intersection zone of two regions depends on the overhead of handover protocol and the maximum speed of the participating vehicle (see Figure10). In other words, the distance d is calculated as follows: d=Overhead×MaxSpeedCv, where d is the distance of the intersection zone, Overhead is the total time overhead of the handover protocol, and MaxSpeedCv is the maximum speed a participating vehicle can reach. The calculation of d is important for planning the coordinate of regions controlled by each trusted authority, since Cv needs to receive the pseudonymous certificates issued by ATA before exiting from its own region. If Cv has an accident in the intersection zone, the video is uploaded first in its own region and then it is uploaded to the region controlled by ATA (if the handover process is already finished). The minimum distance required for intersection zone of two regions when MaxSpeedVi=200km/h is indicated in Table 5 and Figure 11.Table 5
Distance of intersection zone.
Number of pseudo-certificates
Total overhead (seconds)
Distance (km)
24 (for a day)
0.1239
0.0069
48 (for 2 days)
0.2231
0.0124
168 (for a week)
0.7192
0.0400
720 (for a month)
3.0012
0.1667
2160 (for 3 months)
8.9541
0.4975
4320 (for 6 months)
17.8836
0.9935
8760 (for a year)
36.2385
2.0133
Corresponding data when MaxSpeedVi = 200 km/h.Figure 10
Relation between handover overhead and intersection zone.Figure 11
Minimum distance of intersection zone of two regions according to the number of issued pseudonymous certificates.Since the participating vehicles must renew the registration to the service annually, the number of pseudonymous certificates issued for handover should be much less than 8760 (for a year). We believe that certificates for 3 months should be enough for this purpose. If there is an extraordinary case when participating vehicle needs to stay in the region controlled by ATA for a long period of time, the participating vehicle can execute the handover protocol again when its pseudonymous certificate is running out. Assuming that the handover protocol is implemented with 2160 pseudonymous certificates the total overhead would be less than 9 seconds andd would be less than 0.5 km which would be very reasonable for real implementation.


## 4.5.3. Analysis of Region Organization

The intention of this subsection is to analyze the size of a region and the overhead caused by the handover protocol when a vehicle visits different number of regions.Size of a Region. It is very hard to determinate the size of a region since it depends on the needs of each country. But we recommend following the regulation of each country in administering the vehicle registration and driver licensing. For example, in the United States, there is an institution called Department of Motor Vehicles (DMV) which is a state-level government that administer vehicle registration and driver licensing. Since each country has similar departments, we recommend that each region for the proposed service must incorporate the geographical area controlled by a DMV, for example, an individual state for United States of America.Overhead of Handover Protocol When Visiting Different Regions. For this analysis, we have taken the following assumptions: (1) the size of a region is determined by the geographical area controlled by a DMV, that is, an individual state, and (2) since we have recommended the usage of pseudo-certificate for three months (2160 pseudo-certificates) in handover protocol (in the previous subsection), we will use such values for this analysis.Statistical data such as [22, 23] indicates that most of drivers use their motorized vehicles for activities of daily life, which means that they drive inside the same town most of the time. It means that most of participating vehicles will not execute or will rarely execute the handover protocol. However, for this analysis, we will consider all kinds of possibilities, including three kinds of vehicles: (1) ordinary vehicle which rarely leaves its region/state, (2) vehicles of people living in the border of a region/state which will make them visit the neighbor region/state frequently, and (3) extraordinary vehicles traveling several states frequently (e.g., interstate buses or cargo trucks).For the first kind of vehicles (ordinary vehicles), the overhead caused by the handover protocol will be minimal since they will not execute or rarely execute such protocol. For the second kind of vehicles (living in a border), they will execute the handover protocol when visiting the neighbor region; however, the vehicle will not execute the handover protocol each time it crosses the border, but when all pseudo-certificates have been used or expired, that is, three months. In this second case, the overhead caused by the handover protocol will also be minimal since vehicles will execute the handover protocol (normally) every three months. Finally, Table6 shows the overhead caused for the third kind of vehicles. Such data indicates the overhead generated when visiting different number of external regions every three months. For example, if a vehicle visits 5 different regions/states, it will spend a total of 44,77 seconds. We believe that the overhead of 44,77 seconds in three months is not a problem in implementing the proposed service. It is important to mention that the process is not executed during 44,77 seconds; instead Cv executes the 8,95 seconds’ process each time it enters a new region.Table 6
Handover protocol overhead when visiting several regions with pseudo-certificates for 3 months.
Number of different external regions visited by Cv
Total overhead(seconds)
1
8.95
2
17.90
5
44.77
10
89.54
20
179.08This analysis has shown how the overhead caused in crossing different regions will not be a problem in implementing the proposed solution nationwide.


## 5. Conclusions

This paper has analyzed a pioneer research work proposing a novel system model for a 5G enabled vehicular network that facilitates a secure and privacy-aware video reporting service and it has found several security flaws and functionality limitations. Additionally, the presented work has proposed an improved scheme that delivers a trusted and reliable real-time video reporting service in 5G enabled vehicular networks which solves the identified security flaws and extends the functionality of the service for multiple trusted authorities. The security and performance analysis indicates how the proposed solution excels in security features and has reasonable overhead making it feasible for real implementation.



---

*Source: 7256307-2017-07-25.xml*