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.
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 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.
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 and be two cyclic groups of prime order and be an efficient admissible bilinear map. The TA selects a random generator , two hash functions and and a random key . Then, the TA calculates its public key as and distributes the parameters where 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 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 to calculate the searchable encryption SPEKS of a set of keywords by executing 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 by executing , where is the private key of the recipient and is the keyword used for search. Following this, the storage server uses to execute the search process by executing . The search process will return true if . Finally, the encrypted data associated with 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 and a master key . The is utilized to generate a decryption key for a specific entity that is associated with a set of attributes (AS) that describes , for example, = “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 . Thus, can access the encrypted data and decrypts it as follows: .
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
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 () system initialization, () participants and official vehicles registration, () video transmission, and () 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 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 , unique 5G identity , and with the Department of Motor Vehicles (DMV), where is a random symmetric key , 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 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 , a set of private keys , 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 , , where is an symmetric encryption function and is the public key used to encrypt a one-time random encryption 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 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 and its real identity and it does not know the issued pseudonymous credentials. On the other hand, the TA manages the mapping between the identity and the corresponding pseudonyms without knowledge of vehicles real identity . 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 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 to and uses the to create a decryption key associated with a set of attributes such 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 ’s tamper-proof device via LEA.
Step 9. 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 generates a random one-time symmetric key and executes to encrypt the accident video report .
Step 11. reads the public key of the recipient () and executes to generate a searchable encryption of the keywords “accident video report”, location, date and time}.
Step 12. encrypts using the CP-ABE function under Policy as follows: to allow only official vehicles having with Policy to access and obtain .
Step 13. Using the selected pseudonymous certificate, executes , where Sign() is the signing function, is the ’s private key associated with the selected pseudonymous certificate, and “” denotes data concatenation.
Step 14. uploads , 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 value and then notifies the accident to the nearest official vehicle by sending . The authors assume that the location information of the official vehicles is updated periodically in the cloud.
Step 16. verifies the received certificate by executing , where is a verification function. After verification of authenticity of , extracts the public key from the pseudonymous certificate.
Step 17. verifies by executing .
Step 18. After verification of authenticity of , executes to get the one-time symmetric encryption key, where is the CP-ABE decryption function.
Step 19. executes and gets the traffic accident video, where 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 as follows: , where keyword can be a location, a date, or just “accident video report.”
Step 21. LEA sends the generated to the Cloud Platform. The authors assume that there is a secure channel between LEA and Cloud Platform.
Step 22. The receipt of authorizes the search process over the ciphertext at the cloud.
Step 23. LEA receives the message . Finally, LEA uses the same procedure to receive the video file .
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 can execute the DMV impersonation attack with the following steps. Since the is not a fixed value and it is not verified by the TA, can generate any random value as . Once is generated, will generate a random symmetric key and will send a registration message to the TA. Since the is not a fixed value and it is not verified, TA will process the request and it will return the message. Since was generated by , he/she will be able to obtain the tuple .
Forged Video Upload. By executing the DMV impersonation attack, can obtain the valid private keys , pseudonymous certificates , , 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 and its should be managed only by LEA and not by TA.
Privileged Insider Attack in LEA. Since LEA receives and 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 is not a fixed value and it is not verified by the TA, can generate any random value as . Once is generated, will generate a random symmetric key and will send a registration request message to the TA. Since the tuple is not verified by TA, TA will process the request and it will return and 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 Figure 2).
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.
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: () 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 () 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 between and Cloud Platform is not secure.(ii)The communication channel between and LEA is not secure.(iii)The communication channel between and TA is not secure.(iv)The communication channel between 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 and DMV. The mentioned communication channel is considered secure because the communication is executed face to face. It means that the owner of 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 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 and designated official vehicles 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.
4.3. Protocols
The proposed scheme includes eight different phases called () system initialization, () participant vehicles registration, () official vehicles registration, () participation vehicle handover, () video transmission, () video search, () 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 , which indicates the validity period threshold of a pseudonymous certificate issued to a participating vehicle. It is important to notice that having the same in each trusted authority does not mean synchronization among those entities; it just means that all TAs must store the same value of as a constant when the service is implemented. Since the value of is defined as a governmental regulation for this service, the value of is not modified after implementation. If the governmental regulation for the services is modified, the TA’s administrator must modify manually the value of . 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 , where is the last time where a pseudonymous certificate of a specific participating vehicle was used.
Since each pseudonymous certificate has an expiration time, the TA must estimate the number of certificates to be issued to each . We also think it is a good idea to issue enough pseudonymous certificates for a year, until the next vehicle inspection. For example, if hour, the number of pseudonymous certificates required for a during a year will be . 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 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 Figure 3).
A participant vehicle generates a random symmetric key and sends to the Department of Motor Vehicles (DMV), where is the unique identification of the participating vehicle, is the 5G identification of the vehicle, is the public key of the trusted authority (TA) of the region which the participant vehicle is part of, and is the public key encryption function of message using key .
Once the message is received, DMV verifies physically the correctness of the , then gets its current timestamp , and creates the message . Upon generation of , DMV signs using its private key by executing . Finally, DMV sends and to TA.
Upon receiving the message, TA verifies the freshness of the message by checking the fulfillment of , where is the current timestamp of TA and is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature as follows: . After signature verification, TA obtains by executing and then generates the set of private keys and a set of pseudonymous certificates corresponding to , where is the public key decryption function of message using key . After that, TA returns the message = , , to DMV, where is the public key of TA for Public Key Encryption with Keyword Search, is the public key of TA for the Attributed Based Encryption, Policy is the access policy of traffic accident videos uploaded by (e.g., “police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), is the IP address of the Cloud Platform of TA, is the a tag preagreed upon between TA and the Cloud Platform of TA (), is the coordinate representing the geographical region controlled by TA, and is the current timestamp of TA.
is used for the handover process when 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, verifies the validity of , then decrypts the received message using , and stores the decrypted values into its tamper-proof device.
It is important to note that the DMV only sends to the TA. This means that the relation between and 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 is not a fixed value changeable during the next inspection/registration event.
4.3.3. Official Vehicle Registration Protocol
Figure 3 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 Figure 3). The official designated vehicle generates a random symmetric key and sends to the Law Enforcement Agency (LEA), where is the unique identification of the official designated vehicle, is the 5G identification corresponding to , and is the public key of the trusted authority (TA) of the region which and are part of.
Once the message is received, LEA verifies physically the correctness of , gets its attribute(s), (e.g., “police vehicle,” “ambulance,” “traffic authority,” or “traffic law enforcement”), and generates the message and , where is the current timestamp of LEA, is the private key of LEA, and is a digital signing of a message using a private key . Upon generating the messages, LEA sends and to TA.
After receiving the message, TA verifies the freshness of the message by checking the fulfillment of , where is the current timestamp of TA and is the timestamp expiration threshold. Only if the message is fresh, the TA verifies the authenticity of the received signature as follows: . After signature verification, TA obtains by executing and then generates the Attribute Based Encryption Private Key for as follows: . TA also generates a certificate for based on and includes it into a message , , to finally send it to LEA. LEA receives and forwards it to .
Upon receiving , verifies the freshness of the message using and decrypts by executing . Once decrypting , compares the decrypted with the value received in plaintext to double verify the authenticity and freshness of the message. Finally, 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, sends an registration request message to . Once receiving the request, the Cloud Platform generates a random nonce and transmits it to . Upon receiving , generates a random symmetric key and a random nonce , calculates and , and sends to . The Cloud Platform then obtains by executing and uses such value to obtain . Once with , verifies the freshness of the message comparing the decrypted nonce with the one generated previously, , only if those values matching are registered to the Cloud Platform. Closing the registration process, registers in its database and sends the decrypted to to confirm its registration. Finally, verifies the confirmation message by comparing the received with the previously generated .
It is important to clarify that the communication between and uses random nonces to validate the freshness of messages instead of timestamps. This is because it is hard to maintain the clock of and 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 vehicle goes to a different regional area with another trusted authority.
In Participating Vehicle Registration Protocol, received which contains the coordinate of the geographical region controlled by TA. Such value is used to verify when handover is required. For this, checks periodically its GPS coordinate with ; when , it initiates the handover protocol composed of the following steps (see Figure 4).
First, sends a handover request to TA. The TA then generates a random nonce and sends it to . Upon receiving the random nonce, generates its own random nonce and a random symmetric key and calculates , and . Once calculating such values, sends to its trusted authority (TA), where is the first not used pseudo-certificate valid at current time. Once receiving the message, TA verifies the authenticity of and origin of by executing . TA also verifies if corresponds to the digital signature of by performing . Once the authenticity of messages is verified, TA gets by and uses it to obtain = , . Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted with the previously generated . 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 currently is located.
Once the adequate ATA is detected, TA mediates the registration of in ATA. For this, TA requests a temporal registration of to ATA. Upon receiving the request, ATA generates a random nonce and sends it to TA. Once the connection with ATA is realized, TA generates a random nonce and a random symmetric key and calculates and . Once the messages are calculated, TA sends to ATA.
Once receiving the message, ATA verifies the authenticity of the received signature as follows: . Upon signature verification, ATA obtains by executing and uses such value to get = . Later, ATA verifies the freshness of the message comparing the decrypted nonce with the previously generated . 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 and a set of pseudonymous certificates corresponding to of . After that, ATA returns the message = , , to TA, where is the public key of ATA for Public Key Encryption with Keyword Search, is the public key of ATA for the Attributed Based Encryption, is the access policy of traffic accident videos uploaded by (e.g., “police vehicle” OR “ambulance” OR “traffic law enforcement” OR “traffic authority”}), is the IP address of the Cloud Platform of ATA, is the a tag preagreed upon between ATA and the Cloud Platform of ATA (), and is the coordinate representing the geographical region controlled by ATA.
Upon receiving the response from ATA, TA decrypts using its random key . Once decrypting , TA verifies the authenticity of by comparing with its own . This comparison allows to be sure that came from the valid ATA. After verification, TA stores the decrypted values for historical data of (only if required) and generates a new message = , , and sends it to .
Upon receiving the message, decrypts and verifies that the message came from the authentic TA freshly by comparing with . After verification 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, 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, generates a random symmetric key and uses it to encrypt the video file and its current GPS coordinate as follows: . Then, generates the keywords related to the accident kw and encrypts it using the Public Key Encryption with Keyword Search function as and calculates . Additionally, encrypts using the Attribute Based Encryption function using and Policy and creates a digital signature of generated messages using its current private key . Finally, clusters the generated messages into , and sends it to over the 5G enabled vehicular network.
Upon receiving , checks if is in the Pseudo-Certificate Revocation List, , or in the Used Pseudo-Certificate List, , 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 or , the received is discarded; otherwise, verifies the authenticity of the message by executing . If the certificate is proved to be valid, stores such message and notifies the nearest designated vehicle about the accident sending . 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 .
Once an official vehicle receives the notification, it verifies the received pseudonymous certificate by executing . If the certificate is proved to be valid, extracts the public key of the sender from the certificate . Upon certificate validation, verifies the received signature by executing , and obtains the using its Attributed Based Encryption private key as follows: . Finally, gets the decrypted video and the last coordinate of by executing . Now, the official vehicles are able to go to the location of the accident using 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 Figure 5).
First, LEA initiates a video search request to . Then, generates a random nonce and sends it to LEA. Once receiving the response of , LEA generates another random nonce and a random symmetric key and then generates the searchable trapdoor token as follows: , where is a keyword (e.g., location, date, or “any video”) related to the video. Upon generation of the search token, LEA generates a message and its digital signature and sends them to the .
On the other side, verifies the validity of the digital signature by performing to be sure that the search request comes from the authentic LEA. Once validating the authenticity of the message, the Cloud Platform extracts by and uses it to get . Once obtaining the data, verifies the freshness of the message by comparing the decrypted nonce with the previously generated . If those values match, authorizes search process over the ciphertext at the cloud and executes . Once the video is founded, a new message , is generated and it is sent to the LEA.
Upon receiving , LEA extracts by executing and compares it with the previously generated 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 since the sent nonce can only be decrypted by the authentic having the private key .
4.3.7. Pseudo-Certificate Revocation
This protocol is executed when a participating vehicle 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 indicates his/her willingness to stop the video reporting services to the DMV by delivering his/her identification (e.g., driver’s license). Once the request is received, the DMV verifies the authenticity of and gets and corresponding to . Then, the DMV gets its current timestamp , generates a random nonce , and calculates and . Once such values are calculated, DMV sends to the TA. Once the message is received, TA verifies the freshness of the message using its timestamp and verifies the authenticity of by executing . Once the authenticity of the message is verified, TA gets by and adds the pseudo-certificates belonging to to ’s Peudo-Certificate Revocation List, . Once is updated, DMV returns the decrypted to DVM. Finally, the DMV verifies the correct execution of the request by comparing the received message with the generated by itself and then informs the 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 . then generates a random nonce and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce and a random symmetric key and calculates and . Once such values are calculated, TA sends to its Cloud Platform. Once the message is received, verifies the authenticity of the message by executing . Once the authenticity of the message is verified, gets by and uses it to obtain . Upon decrypting the data, TA verifies the freshness of the message by comparing the decrypted with the previously generated . Once the validity of Pseudo-Certificates Revocation request is verified, adds to the Pseudo-Certificates Revocation List of the Cloud Platform, . Once is updated, returns the decrypted to TA. Finally, the TA verifies the correct execution of the request by comparing the received message with the 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 . 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 –– instead of ––.
4.3.8. Interregion Pseudo-Certificate Revocation
This stage is executed after the Pseudo-Certificate Revocation Protocol, only if the participating vehicle has been in another region and received pseudo-certificates from an ATA. TA can know if 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 has received pseudo-certificates. The ATA then generates a random nonce and sends it to TA. Upon receiving the random nonce, TA generates its own random nonce and a random symmetric key and calculates , , and . Once such values are calculated, TA sends to ATA. Once the message is received, ATA verifies the authenticity of the message by executing . After verification, ATA gets by and uses it to obtain = . Upon decrypting the data, ATA verifies the freshness of the message by comparing the decrypted with the previously generated . Once the validity of the request is verified, ATA adds the pseudo-certificates belonging to to ’s Pseudo-Certificate Revocation List, .
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 . then generates a random nonce and sends it to ATA. Upon receiving the random nonce, ATA generates its own random nonce and a random symmetric key and calculates , , and . Once such values are calculated, ATA sends to its Cloud Platform. Once the message is received, verifies the authenticity of the message by executing . Once the authenticity of the message is verified, gets by and uses it to obtain = . Upon decrypting the data, verifies the freshness of the message by comparing the decrypted with the previously generated . Once the validity of Pseudo-Certificates Revocation request is verified, adds to the Pseudo-Certificates Revocation List of the Cloud Platform . Once is updated, returns the decrypted to ATA. Finally, the ATA verifies the correct execution of the request by comparing the received message with the 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 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 delivers its pseudonymous certificate . 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 with .
DMV Impersonation Attack. DMV impersonation attack is avoided using the principles of public key cryptography. The participant vehicle registration request message is accompanied with its digital signature signed by the private key of DMV. The TA can verify the origin of the message since it can verify the authenticity of using the public key of DMV .
Forged Video Upload. Thanks to the protection against the DMV impersonation attack, the adversary 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 and TA (in handover protocol), TA and ATA (in handover protocol), and LEA (in video search protocol), and and (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 and . On the other hand, by using encrypted with the confidentiality of , is maintained from LEA. This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle .
Privileged Insider Attack in LEA. Since LEA receives , encrypted with (only known as the official vehicle), LEA cannot obtain such values. This mechanism avoids any privileged insider inside LEA to impersonate an official vehicle .
LEA Impersonation Attack. LEA impersonation attack is avoided using the principles of public key cryptography. The Official Vehicle Registration request message is accompanied with its digital signature signed by the private key of LEA. The TA can verify the origin of the message since it can verify the authenticity of using the public key of LEA .
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 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 ; 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 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. () 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. () 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.
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 is approximately 36.52 ms, the time required for the encryption process is approximately 62 ms (with Policy containing 4 attributes), and the time required for signature generation is approximately 0.6 ms using the PASS scheme where (see Table 2). Additionally, the time required in executing 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 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 = 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 , is 14.7 ms when using the PASS scheme. The time required to execute , step is 1.2 ms and the time required for is approximately 18 ms. Additionally, the time required in executing the decryption of the encrypted video 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.
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 among , 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 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: () Participating Vehicle Overhead, () TA Mediation Overhead, and () ATA Response Overhead.
Participating Vehicle Overhead. This is the overhead generated by steps executed by . In this part, 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, , , and symmetric keys are 256 bits long, it is possible to deduce that the time required to perform = , is approximately 0.16 ms, the time required to execute is 0.6 ms, and the time required to execute 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 is approximately 1.2 ms, the time required to execute is 1.2 ms, the time required to execute is approximately 6.08 ms, the time required to execute is less than 1 ms, the time required to execute = is approximately 1.16 ms, the time required to execute is 6.05 ms, the time required to decrypt using is approximately (N/10) ms, and the time required to perform = , , is approximately (N/10) ms. In summary, the total TA Mediation Overhead is ms. Table 4 and Figure 9 show the calculation of the overhead with different 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 is approximately 0.16 ms, the time required to execute is 6.08 ms, the time required to execute is less than 1 ms, the time required to generate , is approximately (2.734N) ms, and the time required to execute = , , 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 Figure 10). In other words, the distance is calculated as follows: , where is the distance of the intersection zone, Overhead is the total time overhead of the handover protocol, and is the maximum speed a participating vehicle can reach. The calculation of is important for planning the coordinate of regions controlled by each trusted authority, since needs to receive the pseudonymous certificates issued by ATA before exiting from its own region. If 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 is indicated in Table 5 and Figure 11.
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 and 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: () the size of a region is determined by the geographical area controlled by a DMV, that is, an individual state, and () 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, 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 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.
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.
Notations
(i) Notations Used in Eiza-Ni-Shi Scheme| : | Unique 5G identity for each vehicle |
| : | Arbitrary entity |
| : | Set of attributes |
| : | Public key certificate of entity issued by TA |
| : | Decryption key associated with the set of attributes AS |
| : | Participating vehicle |
| : | Official designated vehicle |
| : | Reported traffic accident video |
| : | Encrypted data of |
| : | Set of multiple keywords |
| : | Public/private keys of the recipient |
| : | Pseudonymous certificate of a vehicle, which is associated with , issued by TA for a period |
| : | Pseudonymous certificate of a vehicle issued by TA for a period |
| Public/private keys of a vehicle, which is associated with , for a period | |
| : | Public/private keys of a vehicle for a period |
| : | Pseudo-identity of a vehicle for a period |
| : | Validity period of pseudonymous certificate of vehicle for a period |
| : | Digital signature of TA on the pseudonymous certificate of vehicle for a period |
| : | Private key of TA for the purpose of signing the issued pseudonymous certificates |
| : | Trapdoor token associated with keyword |
| : | Validity threshold of a pseudonymous certificate |
| : | Digital signature of a vehicle, which is associated with , for a period |
| : | Tag required to upload the video file to the cloud |
| : | Public/master keys for CP-ABE algorithm. |
| : | Participant vehicle |
| : | Official designated vehicle |
| : | Department of Motor Vehicles |
| : | Law Enforcement Agency |
| : | Trusted authority |
| : | Away trusted authority |
| : | Cloud Platform of . |
| : | Unique identification of ( is used as representation of ID and entity) |
| : | Unique 5G identification of |
| : | Unique identification of ( is used as representation of ID and entity) |
| : | Unique 5G identification of |
| : | Public/private keys of |
| : | Public/private keys of |
| : | Public/private keys of |
| : | Public/private keys of |
| : | Public/private keys of |
| : | Random symmetric keys |
| : | Timestamps |
| : | Timestamps expiration threshold |
| : | Keywords related to the reported video |
| : | Set of private keys issued by for |
| : | Set of public keys stored inside pseudonymous certificates issued by |
| : | Set of pseudonymous certificates issued by for with |
| : | Set of private keys issued by for |
| : | Set of public keys stored inside pseudonymous certificates issued by |
| : | Set of pseudonymous certificates issued by for with |
| : | Public key/private key of for Public Key Encryption with Keyword Search |
| : | Public key/private key of for Public Key Encryption with Keyword Search |
| : | Public key of for Attributed Based Encryption |
| : | Public key of for Attributed Based Encryption |
| : | Private key of issued by for Attributed Based Encryption |
| : | Private key of issued by for Attributed Based Encryption |
| : | Policy of videos uploaded by |
| : | Policy of videos uploaded in |
| : | IP address of |
| : | IP address of |
| : | Tag preagreed upon between and |
| : | Tag preagreed upon between and |
| : | Region (coordinates) controlled by |
| : | Region (coordinates) controlled by |
| : | Attribute(s) of |
| : | Certificate issued by for with |
| : | Random nonces |
| : | Current GPS coordinate of |
| : | Reported traffic accident video |
| : | Pseudo-Certificate Revocation List in an entity |
| : | Used Pseudo-Certificate List in an entity . |
| : | Public key encryption function |
| : | Public key decryption function |
| : | Symmetric key encryption function |
| : | Symmetric key decryption function |
| : | Digital signature of a message |
| : | Verifying a certificate |
| : | Verifying a digital signature using a certificate |
| : | Attribute Based Encryption function |
| : | Attribute Based Decryption function |
| : | Public Key Encryption with Keyword Search |
| : | Trapdoor generation algorithm |
| : | Test algorithm of Public Key Encryption with Keyword Search. |
Conflicts of Interest
The author declares that they have no conflicts of interest.