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

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 systemmodel 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 themanagement 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.


Introduction
The 5G communication technology has been one of the most important research fields in the academy over the last several years [1][2][3], and it also has received the interest of the telecommunication industry worldwide [4][5][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 Figure 1) 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).
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.Section 2 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.

Preliminaries
This section introduces the cryptographic meanings used in both Eiza-Ni-Shi Scheme and the proposed scheme.2.1.Pseudonymous Authentication Scheme.Let ( 1 , +) and ( 2 , +) be two cyclic groups of prime order  and  :  1 × 1 →  2 be an efficient admissible bilinear map.The TA selects a random generator  ∈  1 , two hash functions ℎ(⋅) and (⋅) : {0, 1} * →  1 and a random key  ∈  *  .Then, the TA calculates its public key  pub as  pub =  and distributes the parameters ( 1 ,  2 , , , ,  pub , ℎ(⋅), (⋅), SEnc(⋅), Δ) where SEnc(⋅) is a symmetric encryption function and Δ 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 SK TA 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.

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  PK  to calculate the searchable encryption SPEKS of a set of keywords kw = {kw 1 , kw 2 , . . ., kw  } by executing SPEKS = PEKS(PK  , 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 Tkw  by executing Tkw  = Trapdoor(SK  , kw  ), where SK  is the private key of the recipient  and kw  is the keyword used for search.Following this, the storage server uses Tkw  to execute the search process by executing Test(SPEKS, Tkw  ).The search process will return true if kw  ∈ kw.Finally, the encrypted data associated with kw  is returned for decryption.

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 PK ABE and a master key MK ABE .The MK ABE is utilized to generate a decryption key for a specific entity  that is associated with a set of attributes (AS) that describes , for example, AS = {"police vehicle", "traffic authority", "traffic law enforcement"}.In order to give  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.Enc(PK ABE , data, Policy).Thus,  can access the encrypted data and decrypts it as follows: data = ABE.Dec(ABEC, decryption key).

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.

Review of Eiza-Ni-Shi Scheme.
Figure 1 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.

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 Δ 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.

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  V , unique 5G identity 5G_ID, and PKE( pub ,   ) with the Department of Motor Vehicles (DMV), where   is a random symmetric key   ∈  *  ,  pub 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, PKE( pub ,   )} 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 {PCert TA,5G_ID, }, a set of private keys {SK 5G_ID, }, a policy, Policy = {"police vehicle" OR "ambulance" OR "traffic law enforcement" OR "traffic authority"}, and a tag  ∈  *  , and delivers them to the DMV by sending SEnc(  , ({SK 5G_ID, }, {PCert TA,5G_ID, }, PK ABE , Policy, )), where SEnc(⋅) is an symmetric encryption function and PK ABE is the public key used to encrypt a onetime random encryption key  key under Policy using CP-ABE [11].The tag  is a preagreed value between the TA and the Cloud Platform; such value is used by  V 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  V 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  V .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 DV  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 Cert TA,DV to DV  and uses the MK ABE to create a decryption key dk AS 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 DV  's tamper-proof device via LEA.
Step 9. DV  uses the data received in previous step to register with the Cloud Platform.

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  V generates a random one-time symmetric key  key and executes Enc  = SEnc( key , TV  ) to encrypt the accident video report TV  .
Step 11.  V reads the public key of the recipient  (PK  ) and executes  PEKS = PEKS(PK  , kw) to generate a searchable encryption of the keywords kw = {"accident video report", location, date and time}.
Step 12.  V encrypts  key using the CP-ABE function under Policy as follows: ABE  = ABE.Enc(PK ABE ,  key , Policy) to allow only official vehicles having dk AS with Policy to access ABE  and obtain  key .
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 ℎ() value and then notifies the accident to the nearest official vehicle DV  by sending {Enc  ,  PEKS , ABE  , ℎ(),  5G_ID, , PCert TA,5G_ID, }.The authors assume that the location information of the official vehicles is updated periodically in the cloud.
Step 18.After verification of authenticity of  5G_ID, , DV  executes  key = ABE.Dec(ABE  , dk AS ) to get the one-time symmetric encryption key, where ABE.Dec(⋅) is the CP-ABE decryption function.
Step 19.DV  executes TV  = SDec( key , Enc  ) 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 Tkw  as follows: Tkw  = Trapdoor(SK  , kw  ), where keyword kw  can be a location, a date, or just "accident video report." Step 21.LEA sends the generated Tkw  to the Cloud Platform.The authors assume that there is a secure channel between LEA and Cloud Platform.
Step 22.The receipt of Tkw  authorizes the search process over the ciphertext at the cloud.

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   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,   can generate any random value as 5G_ID.Once 5G_ID is generated,   will generate a random symmetric key   and will send a registration message request(5G_ID, PKE( pub ,   )) 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 SEnc(  , ({SK 5G_ID, }, {PCert TA,5G_ID, }, PK ABE , Policy, )) message.Since   was generated by   , he/she will be able to obtain the tuple {{SK 5G_ID, }, {PCert TA,5G_ID, }, PK ABE , Policy, }.
Forged Video Upload.By executing the DMV impersonation attack,   can obtain the valid private keys {SK 5G_ID, }, pseudonymous certificates {PCert TA,5G_ID, }, PK ABE , Policy, and .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 DV  and its 5G_ID should be managed only by LEA and not by TA.
Privileged Insider Attack in LEA.Since LEA receives Cert TA,DV and dk AS 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,   can generate any random value as 5G_ID.Once 5G_ID is generated,   will generate a random symmetric key   and will send a registration request message request(DV  , 5G_ID) to the TA.Since the {DV  , 5G_ID} tuple is not verified by TA, TA will process the request and it will return Cert TA,DV and dk AS 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.

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 Figure 2).

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.
Figure 2 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.

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 between DV 𝑖 and Cloud
Platform is not secure.
(ii) The communication channel between DV  and LEA is not secure.
(iii) The communication channel between  V and TA is not secure.
(iv) The communication channel between  V 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  V and DMV.
The mentioned communication channel is considered secure because the communication is executed face to face.It means that the owner of  V 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  V 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  V and designated official vehicles DV  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, and TA 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.Since each pseudonymous certificate has an expiration time, the TA must estimate the number of certificates to be issued to each  V .We also think it is a good idea to issue enough pseudonymous certificates for a year, until the next vehicle inspection.For example, if Δ = 1 hour, the number of pseudonymous certificates required for a  V 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  V has a tamper-proof device for storage and management of confidential data (e.g., keys and pseudonymous certificates).

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 Figure 3).
A participant vehicle generates a random symmetric key  1 ∈  *  and sends { V , 5G_ID V , PKE(PK TA ,  1 )} to the Department of Motor Vehicles (DMV), where  V is the unique identification of the participating vehicle, 5G_ID V is the 5G identification of the vehicle, PK TA is the public key of the trusted authority (TA) of the region which the participant vehicle is part of, and PKE(, ) is the public key encryption function of message  using key .
Once the message is received, DMV verifies physically the correctness of the  V , then gets its current timestamp TS  , and creates the message 1 = {5G_ID V , TS  , PKE(PK TA ,  1 )}.Upon generation of 1, DMV signs 1 using its private key  Upon receiving the message, TA verifies the freshness of the message by checking the fulfillment of (TS  −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  1 as follows: Verif y(PK DMV , 1,  1 ).After signature verification, TA obtains  1 by executing PKD(SK TA , PKE(PK TA ,  1 )) and then generates the set of private keys {SK TA,5G_IDV } and a set of pseudonymous certificates {PCert TA,5G_IDV } corresponding to 5G_ID V , where PKD(, ) is the public key decryption function of message  using key .After that, TA returns the message 2 = {TS  , SEnc( 1 ,({SK TA,5G_IDV }, {PCert TA,5G_IDV }, PK (TA) , PK ABE(TA) , Policy, IP Cloud(TA) ,  Cloud(TA) , Reg TA , TS  ))} to DMV, where PK (TA) is the public key of TA for Public Key Encryption with Keyword Search, PK ABE(TA) is the public key of TA for the Attributed Based Encryption, Policy is the access policy of traffic accident videos uploaded by  V (e.g., Policy = {"police vehicle" OR "ambulance" OR "traffic law enforcement" OR "traffic authority"}), IP Cloud(TA) is the IP address of the Cloud Platform of TA,  Cloud(TA) ∈  *  is the a tag preagreed upon between TA and the Cloud Platform of TA (Cloud TA ), Reg TA is the coordinate representing the geographical region controlled by TA, and TS  is the current timestamp of TA.
Reg TA is used for the handover process when  V 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,  V verifies the validity of TS  , then decrypts the received message using  1 , and stores the decrypted values into its tamper-proof device.
It is important to note that the DMV only sends 5G_ID V to the TA.This means that the relation between  V and 5G_ID V 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_ID V is not a fixed value changeable during the next inspection/registration event.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 Figure 3).The official designated vehicle generates a random symmetric key  2 ∈  *  and sends {DV  , 5G_ID DV , PKE(PK TA ,  2 )} to the Law Enforcement Agency (LEA), where DV  is the unique identification of the official designated vehicle, 5G_ID DV is the 5G identification corresponding to DV  , and PK TA is the public key of the trusted authority (TA) of the region which  V and DV  are part of.

Official Vehicle Registration Protocol.
Once the message is received, LEA verifies physically the correctness of DV  , gets its attribute(s), Attribute DV (e.g., "police vehicle," "ambulance," "traffic authority," or "traffic law enforcement"), and generates the message 3 = {5G_ID DV , TS2  , Attribute DV , PKE(PK TA ,  2 )} and  3 = Sign(SK LEA , 3), where TS2  is the current timestamp of LEA, SK LEA is the private key of LEA, and Sign(, ) is a digital signing of a message  using a private key .Upon generating the messages, LEA sends 3 and  3 to TA.
After receiving the message, TA verifies the freshness of the message by checking the fulfillment of (TS2  − 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  3 as follows: Verif y(PK LEA , 3,  3 ).After signature verification, TA obtains  2 by executing PKD(SK TA , PKE(PK TA ,  2 )) and then generates the Attribute Based Encryption Private Key for DV  as follows: SK ABE(TA,DV) = ABE.Delegate(MK TA , Attribute DV ).TA also generates a certificate Cert TA,5G_IDDV for DV  based on 5G_ID DV and includes it into a message 4 = {2  , SEnc( 2 , Cert TA,5G_IDDV , SK ABE(DV) , 2  , IP Cloud(TA) )}, to finally send it to LEA.LEA receives 4 and forwards it to DV  .
Upon receiving 4, DV  verifies the freshness of the message using ΔTS and decrypts 4 by executing SDec( 2 , 4).Once decrypting 4, DV  compares the decrypted 2  with the 2  value received in plaintext to double verify the authenticity and freshness of the message.Finally, DV  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, DV  sends an registration request message to Cloud TA .Once receiving the request, the Cloud Platform generates a random nonce 1 and transmits it to DV  .Upon receiving 1, DV  generates a random symmetric key  3 and a random nonce 2, calculates 5 = PKE(PK CloudTA ,  3 ) and 6 = SEnc( 3 , (1, 2, Cert TA,5G_IDDV )), and sends {5, 6} to Cloud TA .The Cloud Platform then obtains  3 by executing PKD(SK CloudTA , 5) and uses such value to obtain {1  , 2  , Cert TA,5G_IDDV } = SDec( 3 , 6).Once with 1  , Cloud TA verifies the freshness of the message comparing the decrypted nonce 1  with the one generated previously, 1, only if those values matching DV  are registered to the Cloud Platform.Closing the registration process, Cloud TA registers Cert TA,5G_IDDV in its database and sends the decrypted 2  to DV  to confirm its registration.Finally, DV  verifies the confirmation message by comparing the received 2  with the previously generated 2.
It is important to clarify that the communication between DV  and Cloud TA uses random nonces to validate the freshness of messages instead of timestamps.This is because it is hard to maintain the clock of DV  and Cloud TA synchronized.Timestamps are only used among LEA, DMV, and TA since they are trusted entities which can coordinate a reliable clock synchronization.

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 vehicle  V goes to a different regional area with another trusted authority.
In Participating Vehicle Registration Protocol,  V received Reg TA which contains the coordinate of the geographical region controlled by TA.Such value is used to verify when handover is required.For this,  V checks periodically its GPS coordinate with Reg TA ; when Coordinate V ∉ Reg TA , it initiates the handover protocol composed of the following steps (see Figure 4).
First,  V sends a handover request to TA.The TA then generates a random nonce 3 and sends it to  V .Upon receiving the random nonce,  V generates its own random nonce 4 and a random symmetric key  4 and calculates 7 = {PKE(PK TA ,  4 ), SEnc( 4 , (3, 4, 5G_ID V , Coordinate V ))} and  7 = Sign(SK 5G_IDV , 7).Once calculating such values,  V sends (7,  7 , PCert TA,5G_IDV ) to its trusted authority (TA), where PCert TA,5G_IDV is the first not used pseudo-certificate valid at current time.decrypted 3  with the previously generated 3.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  V currently is located.
Once the adequate ATA is detected, TA mediates the registration of  V in ATA.For this, TA requests a temporal registration of  V to ATA.Upon receiving the request, ATA generates a random nonce 5 and sends it to TA.Once the connection with ATA is realized, TA generates a random nonce 6 and a random symmetric key  5 and calculates 8 = {PKE(PK ATA ,  5 ), SEnc( 5 , (5, 6, 5G_ID V ))} and  8 = Sign(SK TA , 8).Once the messages are calculated, TA sends (8,  8 ) to ATA.
Once receiving the message, ATA verifies the authenticity of the received signature  8 as follows: Verif y(PK TA , 8,  8 ).Upon signature verification, ATA obtains  5 by executing PKD(SK ATA , PKE(PK ATA ,  5 )) and uses such value to get {5  , 6  , 5G_ID V } = SDec( 5 , SEnc( 5 , (5, 6, 5G_ID V ))).Later, ATA verifies the freshness of the message comparing the decrypted nonce 5  with the previously generated 5.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 {SK ATA,5G_IDV } and a set of pseudonymous certificates {PCert ATA,5G_IDV } corresponding to 5G_ID V of  V .After that, ATA returns the message 9 = SEnc( 5 , ({SK ATA,5G_IDV }, {PCert ATA,5G_IDV }, PK (ATA) , PK ABE(ATA) , Policy ATA , IP Cloud(ATA) ,  Cloud(ATA) , Reg ATA , 6  )) to TA, where PK (ATA) is the public key of ATA for Public Key Encryption with Keyword Search, PK ABE(ATA) is the public key of ATA for the Attributed Based Encryption, Policy ATA is the access policy of traffic accident videos uploaded by  V (e.g., Policy ATA = {"police vehicle" OR "ambulance" OR "traffic law enforcement" OR "traffic authority"}), IP Cloud(ATA) is the IP address of the Cloud Platform of ATA,  Cloud(ATA) ∈  *  is the a tag preagreed upon between ATA and the Cloud Platform of ATA (Cloud ATA ), and Reg ATA is the coordinate representing the geographical region controlled by ATA.
Upon receiving the response from ATA, TA decrypts 9 using its random key  5 .Once decrypting 9, TA verifies the authenticity of 9 by comparing 6  with its own 6.This comparison allows TA to be sure that 9 came from the valid ATA.After verification, TA stores the decrypted values for historical data of  V (only if required) and generates a new message 10 = SEnc( 4 , ({SK ATA,5G_IDV }, {PCert ATA,5G_IDV }, PK (ATA) , PK ABE(ATA) , Policy ATA , IP Cloud(ATA) ,  Cloud(ATA) , Reg ATA , 4  )) and sends it to  V .
Upon receiving the message,  V decrypts 10 and verifies that the message came from the authentic TA freshly by comparing 4  with 4.After verification  V 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.

Video Transmission Protocol.
When an accident occurs,  V obtains the recorded video file through its cameras and initiates the video transmission protocol, which is composed of the following steps (see Figure 5).
First,  V generates a random symmetric key  6 and uses it to encrypt the video file TV  and its current GPS coordinate  V as follows: ETV  = SEnc( 6 , (TV  , Coordinate V )).Then,  V generates the keywords related to the accident kw and encrypts it using the Public Key Encryption with Keyword Search function as Ekw = PEKS(PK (TA) , kw) and calculates ES 6 = ABE.Enc(PK ABE(TA) ,  6 , Policy).Additionally,  V encrypts  6 using the Attribute Based Encryption function using PK ABE(TA) and Policy and creates a digital signature  5G_IDV of generated messages using its current private key SK TA,5G_IDV .Finally,  V clusters the generated messages into 11 = {ℎ( Cloud(TA) ), ETV  , Ekw, ES 6 ,  5G_IDV , PCert TA,5G_IDV } and sends it to Cloud TA over the 5G enabled vehicular network.
Upon receiving 11, Cloud TA checks if PCert TA,5G_IDV is in the Pseudo-Certificate Revocation List, PCRL Cloud(TA) , or in the Used Pseudo-Certificate List, UPCL Cloud(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 PCRL Cloud(TA) or UPCL Cloud(TA) , the received 11 is discarded; otherwise, Cloud TA verifies the authenticity of the message by executing Verif ySign(PK TA , PCert TA,5G_IDV ,  5G_IDV ).If the certificate is proved to be valid, Cloud TA stores such message and notifies the nearest designated vehicle DV  about the accident sending 11.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 Cloud TA PK CloudTA .
Once an official vehicle DV  receives the notification, it verifies the received pseudonymous certificate PCert TA,5G_IDV by executing Verif ySign(PK TA , PCert TA,5G_IDV ,  5G_IDV ).If the certificate is proved to be valid, DV  extracts the public key PK TA,5G_IDV of the sender from the certificate PCert TA,5G_IDV .Upon certificate validation, DV  verifies the received signature  5G_IDV by executing Verif y(PK TA,5G_IDV , (ℎ( Cloud(TA) ), ETV  , Ekw, ES 6 ),  5G_IDV ) and obtains the  6 using its Attributed Based Encryption private key SK ABE(TA,DV) as follows:  6 = ABE.Dec(ES 6 , SK ABE(TA,DV) ).Finally, DV  gets the decrypted video and the last coordinate of  V by executing (TV  , Coordinate V ) = SDec( 6 , ETV  ).Now, the official vehicles are able to go to the location of the accident using Coordinate V and they can check the video of the accident while going to the location.

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 Figure 5).to the last one created by itself.The nonce comparison also allows the verification of authenticity of Cloud TA since the sent nonce can only be decrypted by the authentic Cloud TA having the private key SK CloudTA .

Pseudo-Certificate
Revocation.This protocol is executed when a participating vehicle  V 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).
First, the owner of the participating vehicle Owner V indicates his/her willingness to stop the video reporting services to the DMV by delivering his/her identification ID OwnerV (e.g., driver's license).Once the request is received, the DMV verifies the authenticity of ID OwnerV and gets  V and 5G_ID V corresponding to Owner V .Then, the DMV gets its current timestamp TS3  , generates a random nonce 9, and calculates 13 = {5G_ID V , TS3  , PKE(PK TA , 9)} and  13 = Sign(SK DMV , 13).Once such values are calculated, DMV sends (13,  13 ) to the TA.Once the message is received, TA verifies the freshness of the message using its timestamp TS3  and verifies the authenticity of  13 by executing Verif y(PK DMV , 13,  13 ).
Once the authenticity of the message is verified, TA gets 9 by PKD(SK TA , PKE(PK TA , 9)) and adds the pseudocertificates belonging to 5G_ID V to  V 's Peudo-Certificate Revocation List, PCRL V .Once PCRL V is updated, DMV returns the decrypted 9  to DVM.Finally, the DMV verifies the correct execution of the request by comparing the received message with the 9 generated by itself and then informs the Owner V 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 to Cloud TA .Cloud TA then generates a random nonce 10 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce 11 and a random symmetric key  8 and calculates 14 = {PKE(PK CloudTA ,  8 ), SEnc( 8 , (10, 11, PCRL V ))} and  14 = Sign(SK TA , 14).Once such values are calculated, TA sends (14,  14 ) to its Cloud Platform.Once the message is received, Cloud TA verifies the authenticity of the message by executing Verif y(PK TA , 14,  14 ).Once the authenticity of the message is verified, Cloud TA gets  8 by PKD(SK CloudTA , PKE(PK CloudTA ,  8 )) and uses it to obtain (10  , 11  , PCRL V ) = SDec( 4 , SEnc( 8 , (10, 11, PCRL V ))).Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted 10  with the previously generated 10.Once the validity of Pseudo-Certificates Revocation request is verified, Cloud TA adds PCRL V to the Pseudo-Certificates Revocation List of the Cloud Platform, PCRL Cloud(TA) .Once PCRL Cloud(TA) is updated, Cloud TA returns the decrypted 11  to TA.Finally, the TA verifies the correct execution of the request by comparing the received message with the 11 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  V .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-Cloud TA instead of DMV-TA-Cloud TA .

Interregion Pseudo-Certificate
Revocation.This stage is executed after the Pseudo-Certificate Revocation Protocol, only if the participating vehicle  V has been in another region and received pseudo-certificates from an ATA.TA can know if  V 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).
First, TA sends a Pseudo-Certificates Revocation request to ATA where  V has received pseudo-certificates.The ATA then generates a random nonce 12 and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce 13 and a random symmetric key  9 and calculates 15 = {PKE(PK TA ,  9 ), SEnc( 9 , (12, 13, 5G_ID V , PCRL V ))}, and  15 = Sign(SK TA , 15).Once such values are calculated, TA sends (15,  15 ) to ATA.Once the message is received, ATA verifies the authenticity of the message by executing Verif y(PK TA , 15,  15 ).After verification, ATA gets  9 by PKD(SK TA , PKE(PK TA ,  9 )) and uses it to obtain {12  , 13  , 5G_ID V , PCRL V } = SDec( 9 , SEnc( 9 , (12, 13, 5G_ID V , PCRL V ))).Upon decrypting the data, ATA verifies the freshness of the message by comparing the decrypted 12  with the previously generated 12.Once the validity of the request is verified, ATA adds the pseudocertificates belonging to 5G_ID V to  V 's Pseudo-Certificate Revocation List, PCRL V .
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 to Cloud ATA .
Cloud ATA then generates a random nonce 14 and sends it to ATA.Upon receiving the random nonce, ATA generates its own random nonce 15 and a random symmetric key  10 and calculates 16 = {PKE(PK CloudATA ,  10 ), SEnc( 10 , (14, 15, PCRL V ))}, and  16 = Sign(SK ATA , 16).Once such values are calculated, ATA sends (16,  16 ) to its Cloud Platform.Once the message is received, Cloud ATA verifies the authenticity of the message by executing Verif y(PK ATA , 16,  16 ).Once the authenticity of the message is verified, Cloud ATA gets  10 by PKD(SK CloudATA , PKE(PK CloudATA ,  10 )) and uses it to obtain (14  , 15  , PCRL V ) = SDec( 10 , SEnc( 10 , (14, 15, PCRL V ))).Upon decrypting the data, Cloud ATA verifies the freshness of the message by comparing the decrypted 14  with the previously generated 14.Once the validity of Pseudo-Certificates Revocation request is verified, Cloud ATA adds PCRL V to the Pseudo-Certificates Revocation List of the Cloud Platform PCRL Cloud(ATA) .Once PCRL Cloud(ATA) is updated, Cloud ATA returns the decrypted 15  to ATA.Finally, the ATA verifies the correct execution of the request by comparing the received message with the 15 generated by itself.

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 Table 1).

Authentication 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  V delivers its pseudonymous certificate PCert TA,5G_IDV .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   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   to correlate  V with PCert TA,5G_IDV .
DMV Impersonation Attack.DMV impersonation attack is avoided using the principles of public key cryptography.The participant vehicle registration request message 1 is accompanied with its digital signature  1 signed by the private key of DMV.The TA can verify the origin of the message since it can verify the authenticity of  1 using the public key of DMV PK DMV .
Forged Video Upload.Thanks to the protection against the DMV impersonation attack, the adversary   cannot obtain Verify PK ATA , M16,  M16 (ii) Gets S r10 by PKD SK CloudATA , PKE PK CloudATA , S r10 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 pseudocertificate 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 UPCL Cloud(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  V ; 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  V 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.

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.

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.
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 = PEKS(PK (TA) , kw) is approximately 36.52 ms, the time required for the encryption process ES 6 = ABE.Enc(PK ABE(TA) ,  6 , Policy) is approximately 62 ms (with Policy containing 4 attributes), and the time required for signature generation  5G_IDV = Sign(SK TA,5G_IDV , hashValue) is approximately 0.6 ms using the PASS scheme where hashValue = ℎ((ℎ( Cloud(TA) ), ETV  , Ekw, ES 6 )) (see Table 2).Additionally, the time required in executing ETV  = SEnc( 6 , (TV  , Coordinate V )) 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.
It is notorious that most of the overhead of this stage of the protocol is the symmetric encryption of the video file corresponding to ETV  = SEnc( 6 , (TV  , Coordinate V )) 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  comm = 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 Verif ySign(PK TA , PCert TA,5G_IDV ,  5G_IDV ) is 14.7 ms when using the PASS scheme.The time required to execute Verif y(PK TA,5G_IDV , (ℎ( Cloud(TA) ), ETV  , Ekw, Es 6 ),  5G_IDV ) step is 1.2 ms and the time required for  6 = ABE.Dec(ES 6 , SK ABE(TA,DV) ) is approximately 18 ms.Additionally, the time required in executing the decryption of the encrypted video ETV  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.

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 among  V , 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) while  V 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  V .In this part,  V 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_ID  , Coordinate V , and symmetric keys are 256 bits long, it is possible to deduce that the time required to perform 7 = {PKE(PK TA ,  4 ), SEnc( 4 , (3, 4, 5G_ID V , Coordinate V ))} is approximately 0.16 ms, the time required to execute  7 = Sign(SK 5G_IDV , 7) is 0.6 ms, and the time required to execute SDec( 4 , 10) is approximately (N/10) ms, where  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.TA Mediation Overhead.This is the overhead generated by performing steps executed by TA.Here is the overhead calculation: the time required to perform Verif ySign(SK TA , PCert TA,5G_IDV ,  7 ) is approximately 1.2 ms, the time   9 show the calculation of the overhead with different number of issued pseudonymous certificates.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 pseudocertificates) 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, Table 6 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  V executes the 8,95 seconds' process each time it enters a new region.This analysis has shown how the overhead caused in crossing different regions will not be a problem in implementing the proposed solution nationwide.

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.

Notations (i) Notations Used in Eiza-Ni-Shi Scheme
5G_ID: Unique 5G identity for each vehicle : Arbitrary entity AS: Set of attributes Cert TA, : Public key certificate of entity  issued by TA dk AS : Decryption key associated with the set of attributes AS

Figure 2 :
Figure 2: Extended system model for secure video reporting service in 5G enabled vehicular network.

Figure 3 :
Figure 3: Participating and Official Vehicle Registrations.
Figure 3 illustrates both Participation Vehicles Registration and Official Vehicle Registration protocols, but the protocols are executed independently in different time.

Figure 9 :
Figure 9: Total overhead of handover protocol according the number of issued pseudonymous certificates.

Figure 11 :
Figure 11: Minimum distance of intersection zone of two regions according to the number of issued pseudonymous certificates.

Table 1 :
TA,5G_IDCj to PCRL C Cloud TA and LEA (in video search protocol), and DV  and Cloud TA (in Official Vehicle Registration protocol) This security mechanism will allow only LEA to manage the mapping of the unique identity of DV  and 5G_ID DV .On the other hand, by using  2 encrypted with PK TA the confidentiality of Cert TA,5G_IDDV , SK ABE(TA,DV) is maintained from LEA.This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle DV  .Comparison of security and functionality features.Since LEA receives Cert TA,5G_IDDV , SK ABE(TA,DV) encrypted with  2 (only known as the official vehicle), LEA cannot obtain such values.This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle DV  .LEA Impersonation Attack.LEA impersonation attack is avoided using the principles of public key cryptography.The Official Vehicle Registration request message 3 is accompanied with its digital signature  3 signed by the private key of LEA.The TA can verify the origin of the message since it can verify the authenticity of  3 using the public key of LEA PK LEA .

Table 2 :
Overhead for signing, certificate verification, and signature verification for Eiza-Ni-Shi Scheme and proposed scheme.

Table 3 :
Total overhead of video transmission protocol when AEC/CBC is used and video size is 2 GB.

Table 6 :
Handover protocol overhead when visiting several regions with pseudo-certificates for 3 months.Number of different external regions visited by  V