Secure and Lightweight Cloud-Assisted Video Reporting Protocol over 5G-Enabled Vehicular Networks

In the vehicular networks, the real-time video reporting service is used to send the recorded videos in the vehicle to the cloud. However, when facilitating the real-time video reporting service in the vehicular networks, the usage of the fourth generation (4G) long term evolution (LTE) was proved to suffer from latency while the IEEE 802.11p standard does not offer sufficient scalability for a such congested environment. To overcome those drawbacks, the fifth-generation (5G)-enabled vehicular network is considered as a promising technology for empowering the real-time video reporting service. In this paper, we note that security and privacy related issues should also be carefully addressed to boost the early adoption of 5G-enabled vehicular networks. There exist a few research works for secure video reporting service in 5G-enabled vehicular networks. However, their usage is limited because of public key certificates and expensive pairing operations. Thus, we propose a secure and lightweight protocol for cloud-assisted video reporting service in 5G-enabled vehicular networks. Compared to the conventional public key certificates, the proposed protocol achieves entities’ authorization through anonymous credential. Also, by using lightweight security primitives instead of expensive bilinear pairing operations, the proposed protocol minimizes the computational overhead. From the evaluation results, we show that the proposed protocol takes the smaller computation and communication time for the cryptographic primitives than that of the well-known Eiza-Ni-Shi protocol.


Introduction
Due to the merits of the fifth-generation (5G) cellular networks such as higher mobility support, massive connectivity and reduced latency [1], the academia and industry have shown interest in the 5G technology as a shifting paradigm which overcomes the limitations of the fourth generation (4G) technology. For example, leading companies in IT such as Cisco has predicted that the 5G cellular networks could meet the global mobile data traffic projections for the next five years [2]. That is, it is expected that the 5G cellular networks through the massive connectivity property will enable the connection of millions of devices including vehicles.
Especially, 5G cellular networks were embraced as the ultimate framework which would help the implementation of vehicular related technologies [3][4][5]. For example, a driverless vehicle was tested over 5G cellular networks by Uber in the beginning of the year 2017 [6]. Let us note that vehicular network is still in its architectural stage regardless of considerable amount of research works available in the literature [7][8][9][10]. Also, security and privacy threats, lack of scalability and latency due to the high mobility of the vehicles are considered as the main reasons that delay the real deployment of vehicular networks. In practice, the researchers have proved that even IEEE 802.11p lacks of mobility support [7] and the Long Term Evolution (LTE) network does not support the effective latency for the vehicular networks [11][12][13]. Thus, the predicted performance of 5G cellular network in terms of latency, mobility and so on has been considered as a promising archetype for the practical implementation of the intelligent transportation system (ITS)-related services through the cloud assisted vehicular network.
Before the full deployment of the 5G cellular network in the year 2020 [14], security and privacy related issues should be carefully addressed to boost its adoption [15,16]. Furthermore, the ITS services based on the innovative 5G cellular network will require strong security because the data packets are relayed in the safety-critical vehicular environment [17]. That is, the design of secure protocols for the 5G-enabled ITS-related services is required.
To send the videos recorded by the vehicle's cameras into the cloud server, we propose a secure and lightweight cloud-assisted video reporting protocol for 5G-enabled vehicular networks. Recently, Eiza et al. [18] and Yoo [19] have proposed the secure cloud-assisted video reporting protocols in the 5G-enabled networks. By including handover and certificate revocation algorithms, Yoo enhanced the Eiza-Ni-Shi protocol that was designed by using public key certificates. In this paper, we focus on resolving the following drawbacks of the Eiza-Ni-Shi protocol: • The Eiza-Ni-Shi protocol relies on convectional public key certificates that should be renewed in the vehicle periodically, e.g., every year. However, such periodic renewal is proved to be burdensome over the vehicular networks [20][21][22].

•
The Eiza-Ni-Shi protocol is built on expensive pairing operations. Thus, the overall efficiency of the Eiza-Ni-Shi protocol can be decreased despite the merits of 5G cellular networks.

•
The Eiza-Ni-Shi protocol is designed by using an attribute-based encryption. When attribute-based encryption is used to achieve access control, the video sender should know the public key of the receiver. This preliminary makes the Eiza-Ni-Shi protocol to be only applicable in limited services.
Also, we note that the cloud-assisted video reporting protocol should be designed to fulfill security requirements such as privacy, authorization and fine-grained access control over the vehicles. For example, the sender's personal data should not be revealed to unauthorized entities or even the reporting vehicles should not be traced by any malicious users. Even under the huge computation capabilities of 5G-enabled vehicular network, the cloud entities should not waste much time and computation capabilities before they discard bogus, unauthenticated and unauthorized videos. In addition, for the proposed protocol to attain the non-repudiation property, the conditional traceability of all the vehicles should be achieved.
To fulfill the above-mentioned goals of 5G-enabled cloud-assisted video reporting protocol and to overcome the drawbacks of the Eiza-Ni-Shi protocol, we propose a new secure and lightweight video reporting protocol for 5G-enabled vehicular networks. We summarize the contributions of this work as follows: • We define an application model for a secure and lightweight cloud-assisted video reporting protocol over 5G-Enabled vehicular networks. The model highlights the security objectives that the protocol should satisfy within the 5G-Enabled vehicular networks architecture.

•
We develop a secure and lightweight cloud-assisted video reporting protocol for 5G-enabled vehicular networks. Without using the conventional public key certificates, the proposed protocol supports entities' authorization through anonymous credential. Since the reported videos are broadcasted by the fixed entities, the designated vehicles can recover the reported videos without making any time-consuming communication. Also, by using lightweight security primitives, the proposed protocol minimizes the computation overhead and meets the performance requirement for the real-time ITS-based services in 5G-Enabled vehicular networks.

•
We evaluate the performance of the proposed protocol in terms of security objectives, computation cost and communication overhead.
The rest of this paper consists of as follows. After we describe the related work in Section 2, cryptographic primitives for constructing the proposed protocol are overviewed in Section 3.
After describing the overall operation of the proposed protocol in Section 4, we show the detailed operations in Section 5. In Section 6, we show the performance analysis results of the proposed protocol. Finally, we conclude this paper in Section 7.

Related Work
In this section, we overview the evolution of vehicle communication architectures for supporting the video reporting service in 5G-enabled vehicular networks.

VANETs and 5G-Enabled Cloud-Assisted VANETs
As an extension of mobile ad-hoc networks (MANETs) [23], the main entities in vehicular ad hoc networks (VANETs) include the vehicles, the fixed infrastructures along the roads, called road side units (RSU), and an over-viewer third party, called Trusted Authority (TA), in charge of registration, certification and revocation of all the entities within the VANETs architecture. Commonly, VANETs architecture is classified into two main communication means namely vehicle-to-vehicle (V2V) and vehicle to infrastructure (V2I) [24]. The computational cost for the value-added applications in VANETs requires huge computation capabilities, which led to the mixture of VANETs and cloud computing, called VANETs using Cloud [25]. VANETs using Cloud is defined as vehicular networks equipped with smart devices which communicate with the cloud in the same way as our mobile phones connect to different servers located in the cloud. out the feasibility of VANETs using Cloud compared to convectional VANETs. Also, the feasibility of VANETs using Cloud was approved by several researchers [28][29][30][31][32]. Vehicular Cloud refers to the full utilization of vehicle devices as computers to form mobile servers. In this architecture, one could use the vehicle's OBU to make his/her personal cloud. As a combination of Vehicular cloud and VANETs using Cloud, Hybrid vehicle cloud was proposed. The proposed protocol is built on VANETs using Cloud framework, i.e., cloud-assisted vehicular networks. In the following sections, vehicular networks and cloud-assisted vehicular networks are used interchangeably.

Security and Video Reporting in 5G Enabled Vehicular Network
Security and privacy related topics in 5G cellular networks have mostly being dedicated to security threats of each of the distinct technology (SDN or NFV) [33,34]. Among relevant works on security concerns over 5G cellular network, Mantas et al. [35] surveyed probable threats and attacks against the core modules of 5G cellular networks. The authors also confirmed the four conventional attractive targets in the 4G cellular network: user equipment (UE); access network; the mobile operator's core network; and external Internet Protocol networks. Yang et al. [36] suggested that much effort should be paid on the physical layer of the 5G cellular network. The malicious users are likely to take advantage of the deficiencies of the wireless communication medium such as the poor signal reception quality. Some notable solutions proposed by the authors on the physical layer include artificial noise, confidential and antenna correlation. Alam et al. [37] proposed a framework that analyzes the security requirements of the three scenarios of device to device (D2D) communications in LTE Advanced (LTE-A) networks. The first one includes the network-covered D2D communication without user applications, in which all the nodes in the proximity are under an LTE-A network coverage and the user applications do not need D2D communications. The following scenario is the network-covered D2D communication, where all the devices including the users' devices are covered by an LTE-A network. The last scenario is the network-absent D2D communication. For all these three types of D2D scenarios, conventional security attacks such as eavesdropping, impersonation attack and the corresponding countermeasure solutions were introduced [37].
For vehicular environment, several researches have addressed potential security and privacy issues in VANETs [38][39][40][41]. ITS based services such as navigation services received much attention for the last decade [22,42]. Other protocols in the literature addressed multiple services in VANETs [43][44][45] for the VANETs integrated with cloud computing. However, all the afore-mentioned protocols are not based on HetNet architecture such as 5G-enabled vehicular network, where our protocol is built upon. Recently, researchers in [18,19] introduced secure and privacy aware cloud-assisted video reporting service in 5G-Enabled vehicular network. However, as noted in Section 1, their protocols have some limitations. This, the design of a new secure and lightweight cloud-assisted video reporting protocol over 5G-enabled vehicular networks is required.

Preliminary
We overview the preliminary security properties such as attribute-based encryption (ABE) and certificateless signature scheme.

Attribute-Based Encryption Scheme
The ABE scheme in [46] is designed for elliptic curve cryptography and is made of the following sub-protocols: Setup, Encryption, Key-Generation, and Decryption algorithms.

ABE.Setup
For the universe of attributes U = {1, 2, ..., n}; let G 1 be an additive group with a prime order q and P ∈ G 1 , where G 1 is made of points on an elliptic curve and P is a generator of G 1 . ABE.Setup() sub-protocol works as follows: • On input of a random s ∈ Z * q as the attribute master secret key, output the corresponding public key PK = s · P.

ABE.ENC
For a message m, ω as attribute set, and ABE.params, ABE.ENC(m, ω, ABE.params) returns the ciphertext CM as follows: • On input of k ∈ Z * q , then output the key K = k · PK.

ABE.KGN
ABE.KGN(ABEmk, Γ) algorithm outputs the shared secret for the decryption keys under the attribute set ω, which consists of a master secret ABEmk and the access tree Γ.

•
Based on access tree Γ, allocate index to every node other than root. • A polynomial q node (x) over Z * q is set in top-down manner for each node where each polynomial is of degree d node − 1 and d node is considered as the threshold value of the node.

-
Set q root (0) = s for the root node. -Set q node (0) = q parent (index(node)) for every node with a leaf, where index(node) represents the node's index value.
• Suppose Γ contains n leaves, for every leaf node lea f f (1 ≤ f ≤ n), a secret share for the decryption key is generated as D lea f f = q lea f f (0) · t −1 i where i represents the attribute linked to lea f f and l i a random number for i taken in ABE.Setup.
3.1.4. ABE.DEC ABE.DEC(CM, D, ABE.params) performs the decryption of the cipher text CM, as long as the attributes set ω fulfills the access tree Γ, by using NodeKey(CM, D, node) for every node within the access tree recursively. In this ABE scheme [46], secret sharing based on Lagrange interpolation is borrowed to recover the decryption key.

•
For every leaf node linked to an attribute i, NodeKey(CM, D, lea f f ) is computed as follows.
Note that we represent NodeKey(CM, D, lea f f ) into N 1 in the next paragraph for convenience.

1.
In case the associated attribute i to lea f f is not comprised in ω, then NodeKey(CM, D, lea f l ) = ⊥. 2. else, To proceed with a non-leaf node u, the algorithm calls NodeKey(CM, D, z) for all children z which are attached to the node u.

1.
Suppose that ω u is an arbitrary d u set of children nodes satisfying NodeKey(CM, D, z) = ⊥. In case no such set is existent, NodeKey(CM, D, u) output ⊥. We use N to denote NodeKey(CM, D, u) in the next paragraph for paper formatting.
• CertS.Setup() computes a master key along with a public system parameters as follows: -Let G be an additive group with a prime order q and P ∈ G be a generator based on an elliptic curve.
-Choose s ∈ Z * q as master secret key and generates the master public key P pub = s · P.
Output the public parameters CertS.params = {G, q, P, P pub , CertS.Secret(id) returns a secret value for every identity id as follows: -Choose x id ∈ Z * q as a secret value, then compute P id = x id · P.
CertS.PartialK(s, id, P id ) computes a partial private/public key for the given id as follows: -Select a random r id ∈ Z * q and generate R id = r id · P.
Output Sec 2 = s id , R id as the corresponding partial private key.
• CertS.SKey(Sec 1 , Sec 2 ) sets sk id = x id , s id and pk id = P id , R id representing the private key and public key for id, respectively. • CertS.Sign(m, sk id ) computes the signature for a given message m as follows: -Select a random l ∈ Z * q such that gcd(l + h, q) = 1, where h = H 2 (m, R, P id , R id ) and R = l · P.
Output the signature σ = r, R .
• CertS.Verify(m, id, pk id , σ) provides the signature verification σ for the message m for the identity id as follows: -Check whether r · (R + h 2 · P) ? = P id + R id + (h 1 · P pub ).

Overview of Proposed Protocol
After overviewing the system architecture and describing the security requirements, we explain the overall operation of the proposed protocol.

System Architecture
As a major difference from the convectional cloud assisted vehicular network architecture, the 5G-Enabled vehicular network is deployed on the following communication mediums:

•
Heterogeneous Networks: This network is originated from the ultimate desire to achieve high data rate and network capacity for the 5G-enabled network. Thus, two solutions may help to attain the aforementioned capacities by making the size of cells smaller and embracing the mmWave spectrum. Making the size of the cell much smaller would increase the spectral efficiency [48].
On the other side, the mmWave communications will offer high data rates because it operates in the range of 30-300 GHz and 1-10 mm for the spectrum and wavelength respectively. As mentioned in [38], the mmWave technology still suffers from considerable propagation loss that generates tremendous line of sight (LOS) connections.

Security Objectives
The proposed protocol is designed to satisfy the following security requirements.
• Authentication and Authorization: Any vehicle has to be authenticated before it can send (report) a video recorded by its camera. • Identity privacy preservation: The real identity of every vehicle should be protected from being known by other vehicles, RSC, DVs and DMV. • Fine-grained access control: ABE should guarantee a fine-grained access control by which a designated vehicle should strictly be capable to recover a video fitting to its possessed access structure. • Non-repudiation: A given vehicle should not deny its participation in video reporting. • Traceability: TA should be capable of disclosing the real identity of all the entities in the system.

Overall Operation
The overall operation of the proposed protocol consists of system setup, periodic credential generation, on-duty token generation and accident Reporting procedures.

•
System setup: TA sets up its master secret key and its corresponding public key. Each vehicle provides its real identity and TA generates the corresponding pseudo identity from which a partial private key is computed. DMVs and RSCs also provide their real identities and TA computes their partial private keys. Each vehicle registers with the TA through the DMV, the designated vehicles such as the police or ambulance also register with the TA through the DMV. • Periodic credential generation: Periodically, a vehicle request for credential in order report the recorded videos. DMV generates the periodic credential to vehicles along with the set of attributes corresponding to the type of request. We assume that based on some criteria such as accident record or reckless driving, DMV can decide to give different set of attributes to participating vehicles.

•
On-duty token generation: The designated vehicles also received on-duty tokens. These tokens will be used by the designated to retrieve reported videos from the RSCs. • Accident Reporting: Periodically, a vehicle registers for road reporting services. During the registration, the vehicle specifies the types of services to be reported such as accident or abnormal scene (we assume that the camera of a vehicle is not limited to report road's accidents only). An incentive technique based on point accumulation could be considered in order to motivate the vehicle users to participate in video reporting. Whenever an accident or abnormal scene occurs the camera records the scene and upload the files to the RSC using mmWare technology or D2D communication. The designated vehicles would later on acquire the report from the RSCs as long as they possess enough access structure to recover the secret.

Details of Proposed Protocol
In this section, we describe the secure and lightweight cloud assisted video reporting protocol over 5G-enabled vehicular networks in details. In Table 1, we summarize the notations used for the proposed protocol and the overall operations of the protocol are depicted in Figure 2.

System Setup
In setup phase, TA generates global system parameters and all the entities register to the TA as follows: 1.
TA selects an elliptic curve group G 1 of order q with P ∈ G 1 as a generator.

2.
In order to get the master secret sk TA and public key pk TA , TA executes CertS.Setup() and sets sk TA , CertS.params ← CLS.Setup(), then output CertS.params.

3.
In order to keep a record of each vehicle v i , TA set a pseudonym alias v i to every v i based on its real identity 5GID v i .

4.
Each RSC j , DV j and DMV k registers to TA, then computes CertS private keys as follows: • RSC j , DV j and DMV k computes Sec 1,RSC j ← CertS.Secret(RSC j ), Sec 1,DV j ← CertS.Secret(DV j ) and Sec 1,DMV k ← CertS.Secret(DMV k ), and makes a request for partial private key to the TA, respectively. • TA provides Sec 2,RSC j ← CertS.PartialK(sk TA , RSC j , P RSC j ); Sec 2,DV j ← CertS.PartialK(sk TA , DV j , P DV j ) and Sec 2,DMV k ← CertS.PartiaK(sk TA , DMV k , P DMV k ) to each entity securely.

5.
Likewise, every v i computes Sec 1,v i ← CertS.Secret(alias i ), TA provides Sec 2,v i ← CertS.PartialK(sk TA , alias i , P v i ), then v i sets sk v i , pk v i ← CertS.SKey(Sec 1,v i , Sec 2,v i ).

6.
DMV k selects a given universe of attributes U = {1, ..., N}, computes ABE parameters as ABE.amk, labe.params ← ABE.Setup(), then avails labe.params to the whole system. Note that DMVs will later send ABE.amk to TA in non busy hours.

Periodic Credential Generation
Periodically (on a daily basis), the vehicles request a road reporting credential (RReq) which permits the reporting of the abnormal scenes captured by the vehicle's camera. To acquire a RReq from DMV k , v i performs the following: • v i composes a credential request message RReq = {alias i , K, ts} where ts is the time stamp and K is a secret key to be used later.
where δ is the signature for the RReq set as δ i = CertS.Sign(RReq, sk v i ).
• Upon receiving the message C 1 , DMV k first decrypts C 1 using its private key, then verifies the signature as CertS.Verify(RReq, alias i , pk v i , δ).
If it holds, DMV k generates reporting credential (R-cred) as follows: 1.
Generate R-cred = alias i , exp, KN, ω v i where exp is the expiration date, ω v i the set of attributes and KN the keyword for the credential. Note that KN is not specific for each credential but is the same based on the access structure.

2.
DMV k sends C 1 = Enc K (R-cred) to v i . Then, v i can recover R-cred by decrypting the C 1 under the shared secret key K.

3.
DMV k sends periodically a list List KN of all the keywords enclosed in the credentials to RSCs.

On-Duty Token Generation
In the same way, DMV j generates on-duty token for the designated vehicles. These tokens authorize the DVs to recover the reported videos. For instance a police vehicle can get an on-duty token which extends its duty from police's duties to basic ambulance's duties. If an area A witnesses numerous accidents, several ambulances would go to the accident's scenes in area A which might cause a temporal non-availability of ambulances. In that case, some of the police agents which have basic medical skills can attend to accident's victims as they wait for the ambulances to arrive.

1.
DV i composes an on-duty token request DTRq = {DV j , K 1 , ts} where ts is the time stamp and K 1 is a secret key to be used later.

2.
DV i sends C 2 = Enc PK DMV k {DTReq, pk v i , δ DV } to the DMV k , where δ DV is the signature for the DTRq set as δ DV = CertS.Sign(DTRq, sk DV ).

3.
Upon receiving the message C 2 , DMV k first decrypts C 2 using its private key, then verifies the signature as CertS.Verify(DTRq, DV j , pk DV j , δ DV ).

4.
DMV j setD ← ABE.KGN(ABE.amk, AS DV j ) where AS DV j is the access structure corresponding to the designated vehicle's type (police or ambulance).

5.
DMV j composes a token message Tok DV = {D, exp, RK} where exp is the expiring date, RK a shared secret which is given to DVs that are supposed to work within a defined geographic zone. Note that in real word, one police vehicle can be assign to attend to all the requests from a defined geographic area (three or five consecutive streets). DMV j send it to DV j encrypted under the shared symmetric key K 1 as C 3 = Enc K 1 (Tok DV ).

Abnormal Video Recording
We assume that the in-built camera has the functionalities which can allow the driver to upload a given file or the camera's sensors can decide to upload a particular video after analyzing abnormal movements within the video [49]. The timing and circumstances techniques in which the video should be uploaded are not within the scope of this paper. The vehicles perform the following before uploading the video file captured by the camera:

1.
After recording a video file, v i composes a message V = {V f ile j , KN}; uses the access policy ω v i retrieved in the credential R-cred and encrypts the file under the given attribute set

4.
If not C 4 is discarded. Note that KN value are similar for all the vehicles which have a similar set of attribute such as ω. As mentioned before, DMV j can choose to give a type of attributes to a vehicle based on different criteria such accident record and reckless driving record. The choice of those criteria is beyond the scope of this paper.

5.
Otherwise, RSC j forwards the file securely to neighboring RSCs.
After receiving the beacons, DVs performs the following: • DV j decrypts C 5 = Enc RK (C 5 ) using the area shared key of RK. Note that only DVs assigned to work within RSC j coverage can decrypt the C 5 . • DV j runs CertS.Verify(SF j , RSC j , pk RSC j , δ RSC j ). • DV j runs ABE.Decrypt(SF j ,D, labe.params) to get the original file of V f ile j .

Performance Evaluation
In this section, we show the performance evaluation results of the proposed protocol based on security analysis, computational delay and communication overhead.

Security
The security achievements of the proposed protocol are as follows: • Authentication: The authentication for every v i requesting a service file is provided by the certificateless signature scheme on message RReq = {alias i , K, ts} with C 1 = Enc PK DMV k {RReq, pk v i , δ i } . No malicious user can falsify a valid signature based on the hardness of DL problem. Otherwise the verifier could check the validity of the message by running CLS.Verify(m, id, pk id , σ) to check if r · (R + h 2 · P) ? = P id + R id + (h 1 · P pub ). Thus, the authentication is guaranteed for the proposed protocol.
• Authorization: Every vehicle has to get a periodic credential before it can participate in video reporting. v i sends C 1 = Enc PK DMV k {RReq, pk v i , δ i } to the DMV k to request a credential. After a valid verification, DMV k sends C 1 = Enc K (R − cred) where R − cred = alias i , exp, KN, ω v i as v i 's credential which allows the v i to participate in video reporting.
• Identity privacy preservation: It is hard for an attacker to get a real identity of a vehicle within our proposed protocol. In the registration stage of the vehicle provided by TA, every vehicle v i is provided with a pseudo-identity alias v i . Though the malicious user would get the credential request message RReq = {alias i , K, ts} , the single plain identity of v i which is available is its pseudo-identity alias v i . In the rest of the protocol, the remaining available information concerning v i is its pseudo-identity alias v i . We confirm that our protocol achieves identity privacy preservation.

•
Fine-grained access control: In the proposed protocol, the video file V f ile sent to v i is encrypted under a set of attributes as SF j ← ABE.Encrypt(V f ile j , ω j , labe.params). The file is sent encrypted under the public key of RSC j .RSC j only checks if KN ∈ List KN ; this will save the RSCs from availing bogus files to DVs. RSC j can not recover the file. Even for DVs, unless a DV j possesses the required secret shares D lea f l = q lea f l (0) · t −1 i , it cannot reconstruct the root node R to be able to get the secret q root (0) · k · P = s · k · P. Throughout the decryption stage based on the root or child node, except DV j has the obligatory secret shares, the decryption procedure returns ⊥. Consequently, even the entities (vehicles)that share a certain number of attributes can not conspire (collude) together to recuperate the secret that will achieves the decryption of the video file.
• Non-repudiation: A vehicle can not deny of participating in video reporting because the receiving RSC j keeps v i 's pseudo identity and its anonymous keyword KN contained in the credential Traceability: Even though it is hard for an attacker to know the real identity of a vehicle, TA has the capability of revealing the vehicle's real identity in case of disputes. TA makes a search to find which real identity corresponds to any given or reported alias v i . We conclude that the proposed protocol satisfies the traceability property.

Cost Comparison
We show the analysis results of the computational and communication costs of the proposed protocol.

Computation Cost
When analyzing the computation cost of the proposed protocol, we deliberately omit the time complexity measurement of the setup phase since it is considered to be done offline and infrequently. We basically privilege the operations that dominate the speed of signature generation and verification. We adopt the implementation parameters in [50,51] with embedding degree 6, {G, q} represented by 161 bits and 160 bits respectively. The implementation was performed on a 3.5-GHz, core i-5, 16 GB RAM desktop computer with crypto + + library 5.6.5 [52]. The cost of respective security primitives are depicted in Table 2. Note that TA uses secure symmetric encryption/decryption algorithm. For fairness in comparison, we adopt AES/CBC (256-bit key) with a processing speed of 65 MB/s. We also consider the size of the video ranging from 2 to 8 Gigabytes. We use SHA-512 hash function with a processing speed of 231 MB/s. The connection speed for the 5G-enabled vehicular network is set to 1.2 Gb/s and vehicle's velocity to 100 km/h [53]. We also use CP-ABE toolkit [54] along with MIRACL [55] library to benchmark the performance of attribute-based encryption. We set the attribution number to 4 by following the reference [18]. The overall operation involved for signing and verifying is illustrated in Table 3. As being described in Section 5.4, v i computes W i = k · P i and q lea f l (0) · t −1 i ; which equals to (d + 1)T mul where d is the number of attributes based on the access structure. Furthermore, v i sends the file encrypted under the public of RSC j which equals to T as-enc . RSC j only decrypts the file and check the validity of the KN which was earlier provided within the vehicle credential. In Figure 3, we show the time overhead for encrypting and signing the files recorded by the vehicles' OBUs.
To recover the video file, DV i decrypts the file in T as-dec and checks if r · (R + h 2 · P) ? = P id + R id + (h 1 · P pub ) for signature verification in 2T mul . DV j computes q lea f l (0) · k · P in dT mul . On the other hand, the protocol in [18] requires T pair + T mul to perform public key encryption with key search [56]; (d + 1)T mul + (d + 1)T pair for attribute-based encryption and T mul for signature generation. In order to recover the video file, the designated vehicle requires 3T pair + 4T mul for certificate and signature verification and 4T pair for attribute-based decryption. The total overhead which comprises the required time to encrypt, sign, transmit, verify and decrypt the reported file is shown in Figure 4. It is predicated that the connection speed for the 5G-enabled vehicles will be higher than 1.2 GB/s up to 1 Tb/s which has been already achieved for stationary wireless connection [57]. In Figure 5, we show the overall time overhead with different 5G connection speeds for a 2 GB video file. As shown in Figure 4, the time for the vehicle's OBU to encrypt, sign and decrypt the recorded file in the proposed protocol is also less than the Eiza-Ni-Shi protocol [18] by 50%. These observations show that the proposed protocol offers the possibility to the vehicles that witnessed abnormal events such as road's accidents to report the scene to the designated entities for a timely response.

Conclusions
In this paper, we noted that although there exist a few research works for secure video reporting service in 5G-enabled vehicular networks, their usage is limited because of public key certificates and expensive pairing operations are required. To overcome the limitation, we proposed a new secure and lightweight protocol for cloud-assisted video reporting service in 5G-enabled vehicular networks. Based on a fined-grained access control, the proposed protocol allowed the designated vehicles to recover the recorded video files without any prior communication. By providing security and privacy for the participating entities, the proposed protocol prevents malicious users from tracking, revealing or impersonating the system entities. Also, by using a new certificateless signature scheme, the proposed protocol assured the authentication of legitimate vehicles. With anonymous credentials instead of public key certificates, the proposed protocol guaranteed the authorization of participating entities. From the security and performance analysis results, we showed that the proposed protocol took a lightweight overhead compared to the state-of-the-art works. From these analysis results, we believe that the proposed protocol will help to realize timely and secure cloud-assisted video reporting service over 5G-enabled vehicular networks.