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

Abstract

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.

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

2. Related Work

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

2.1. 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. VANETs using Cloud was introduced in [26] by Olariu et al. for the first time. Olariu et al. suggested an autonomous vehicular cloud (AVC) architecture as a special case of VANETs using Cloud. In [27], Hussain et al. presented additional services by combining cloud computing and VANETs: Computing as a Service (CompaaS), Storage as a Service (STaaS), Network as a Service (NaaS), Cooperation as a Serivce (CaaS), Entertainment as a Service (ENaaS), Information as a Service (INaaS) and Traffic-Information as a Service (TIaaS). Hussain et al. pointed 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.

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

3. Preliminary

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

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

3.1.1. ABE.Setup

For the universe of attributes $U=\{1,2,\dots ,n\}$; let $G_1$ be an additive group with a prime order q and $P\in 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\in Z_q^{*}$ as the attribute master secret key, output the corresponding public key $PK=s·P$.
• For each $i\in U$, choose an attribute secret $l_i\in Z_q^{*}$ to generate the attribute public key $P_i=l_i·P$.
• Set $ABEmk=\{s,l_1,\dots ,l_{\left|U\right|}\}$ and $ABE.params=\{PK,P_1,\dots ,P_{\left|U\right|}\}$.
• Returns $〈ABEmk,ABE.params〉$.

3.1.2. ABE.ENC

For a message m, $\omega$ as attribute set, and $ABE.params$, ABE.ENC(m, $\omega$, $ABE.params$) returns the ciphertext $CM$ as follows:

• On input of $k\in Z_q^{*}$, then output the key $K=k·PK$.
• Compute $C=En{c}_K\left(m\right)$.
• For $i\in \omega$, compute $W_i=k·P_i$, respectively.
• Output the ciphertext $CM=〈\omega ,C,\left\{W_i\right|i\in \omega \}〉$.

3.1.3. ABE.KGN

ABE.KGN($ABEmk$, $\mathrm{\Gamma }$) algorithm outputs the shared secret for the decryption keys under the attribute set $\omega$, which consists of a master secret $ABEmk$ and the access tree $\mathrm{\Gamma }$.

• Based on access tree $\mathrm{\Gamma }$, allocate index to every node other than root.
• A polynomial $q_{node}\left(x\right)$ 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}\left(0\right)=s$ for the root node.

  −

  Set $q_{node}\left(0\right)=q_{parent}\left(index\left(node\right)\right)$ for every node with a leaf, where $index\left(node\right)$ represents the node’s index value.

• Suppose $\mathrm{\Gamma }$ contains n leaves, for every leaf node $lea{f}_f$ ($1\le f\le n$), a secret share for the decryption key is generated as $D_{lea{f}_f}=q_{lea{f}_f}\left(0\right)·t_i^{-1}$ where i represents the attribute linked to $lea{f}_f$ and $l_i$ a random number for i taken in ABE.Setup.
• Output $D=\{D_{lea{f}_f}|lea{f}_f\in \mathrm{\Gamma }\}$.

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 $\omega$ fulfills the access tree $\mathrm{\Gamma }$, 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.
  • In case the associated attribute i to $lea{f}_f$ is not comprised in $\omega$, then NodeKey($CM$, D, $lea{f}_l$) = ⊥.
  • else,

    $$\begin{array}{ccc}\hfill {\mathrm{N}}_1& =& D_{lea{f}_f}·W_i\hfill \\ & =& q_{lea{f}_f}\left(0\right)·t_i^{-1}·k·P_i\hfill \\ & =& q_{lea{f}_f}\left(0\right)·t_i^{-1}·k·l_i·P\hfill \\ & =& q_{lea{f}_f}\left(0\right)·k·P\hfill \end{array}$$
• 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.
  • Suppose that ${\omega }_u$ is an arbitrary $d_u$ set of children nodes satisfying NodeKey($CM$, D, z) $\ne$ ⊥. 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.
  • Else, let ${\Delta }_{index\left(z\right),{\omega }_u^{\prime }}={\prod }_{j\in {\omega }_u^{\prime },j\ne index\left(z\right)}\frac{x-j}{i-j}$ represent the Lagrange coefficient with ${\omega }_u^{\prime }=\left\{index\left(z\right)\right|z\in {\omega }_u\}$,

    $$\begin{array}{ccc}\hfill \mathrm{N}& =& \sum _{z\in {\omega }_u}{\Delta }_{index\left(z\right),{\omega }_u^{\prime }}\left(0\right)·\mathrm{NodeKey}(CM,D,z)\hfill \\ & =& \sum _{z\in {\omega }_u}{\Delta }_{index\left(z\right),{\omega }_u^{\prime }}\left(0\right)·q_z\left(0\right)·k·P\hfill \\ & =& \sum _{z\in {\omega }_u}{\Delta }_{index\left(z\right),{\omega }_u^{\prime }}\left(0\right)·q_{parent}\left(index\left(z\right)\right)·k·P\hfill \\ & =& \sum _{z\in {\omega }_u}{\Delta }_{index\left(z\right),{\omega }_u^{\prime }}\left(0\right)·q_u\left(index\left(z\right)\right)·k·P\hfill \\ & =& q_u\left(0\right)·k·P\hfill \end{array}$$
• Compute the decryption key K = NodeKey($CM$, D, $root$) = $q_{root}\left(0\right)·k·P=s·k·P$.
• Output the decrypted message $m=De{c}_K\left(C\right)$.

3.2. Certificateless Signature Scheme

Certificateless signature scheme (CertS) [47] consists of the following procedures.

• 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\in G$ be a generator based on an elliptic curve.

  −

  Choose $s\in Z_q^{*}$ as master secret key and generates the master public key $P_{pub}=s·P$.

  −

  Let $H_1:{\{0,1\}}^{*}\times G\to Z_q^{*}$ and $H_2:{\{0,1\}}^{*}\times G\to Z_q^{*}$ be two cryptographic hash functions.

  −

  Output the public parameters $CertS.params=\{G,q,P,P_{pub},H_1,H_2\}$.

  −

  Output $〈s,CertS.params〉$

• CertS.Secret($id$) returns a secret value for every identity $id$ as follows:

  −

  Choose $x_{id}\in Z_q^{*}$ as a secret value, then compute $P_{id}=x_{id}·P$.

  −

  Return $Se{c}_1=〈x_{id},P_{id}〉$

• CertS.PartialK(s, $id$, $P_{id}$) computes a partial private/public key for the given $id$ as follows:

  −

  Select a random $r_{id}\in Z_q^{*}$ and generate $R_{id}=r_{id}·P$.

  −

  Compute $s_{id}=r_{id}+s·H_1(id,R_{id},P_{id})$ (mod q).

  −

  Output $Se{c}_2=〈s_{id},R_{id}〉$ as the corresponding partial private key.

• CertS.SKey($Se{c}_1$, $Se{c}_2$) sets $s{k}_{id}=〈x_{id},s_{id}〉$ and $p{k}_{id}=〈P_{id},R_{id}〉$ representing the private key and public key for $id$, respectively.
• CertS.Sign(m, $s{k}_{id}$) computes the signature for a given message m as follows:

  −

  Select a random $l\in Z_q^{*}$ such that gcd($l+h$, q) = 1, where $h=H_2(m,R,P_{id},R_{id})$ and $R=l·P$.

  −

  Generates $r={(l+h)}^{-1}(x_{id}+s_{id})$ (mod q).

  −

  Output the signature $\sigma =〈r,R〉$.

• CertS.Verify(m, $id$, $p{k}_{id}$, $\sigma$) provides the signature verification $\sigma$ for the message m for the identity $id$ as follows:

  −

  Generate $h_1=H_1(id,R_{id},P_{id})$ and $h_2=H_2(m,R,id,P_{id},R_{id})$.

  −

  Check whether $r·(R+h_2·P)\stackrel{?}{=}{P}_{id}+R_{id}+(h_1·P_{pub})$.

4. Overview of Proposed Protocol

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

4.1. 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.
• D2D Communications: D2D communication enables devices to communicate with each other within the licensed cellular bandwidth without involving the BS. In the 5G-Enabled vehicular networks, the vehicles can communicate through D2D communication or by direct link under the mmWare technology.

We describe the communication entities in the proposed protocol: TA, DV, DMV, RSC and vehicles that communicate through the on board unit (OBU) as shown in Figure 1.

• Trusted Authority (TA): It is in charge of the registration of all entities (DMV, DV, RSC and vehicles) inside our system and issues cryptographic materials during the system initialization.
• Department of Motor Vehicles (DMV): All the vehicles are assumed to register with the DMV periodically. Beside the conventional techniques for vehicle’s identification including the Electronic License Plate (ELP) or the Electronic Chassis Number (ECN), each vehicle is registered with a 5G identifier (5GID) with the same functionalities as the subscriber identification module (SIM) chip.
• Road Side cloud (RSC): RSCs are servers located along the roads and accessible by the vehicles. RSCs stores the videos files (VFs) sent by the vehicles. In that case, the designated vehicles (DV) such as police or ambulance can download the files through the RSCs using mmWare communications. Due to the advancements of technology, we assume that RSCs are connected to an electricity power generator with enough computational capability.
• Designated Vehicles: The designated vehicles can be public or private vehicles registered by the government through the DMV that offers public services.
• Vehicles: Vehicles are equipped with OBUs which allow them to communicate with RSCs in order to send the recorded video files.

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

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

5. 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. Terminology.

Term	Notation
$5G_{ID}$	Unique 5G identity for each OBU’s vehicle
$TA$	Trusted Authority
$DM{V}_k$	Department of Motor vehicle’s server
$RS{C}_j$	Roadside cloud’s server
$D{V}_j$	Identity of designated vehicle’s OBU
R-$cred$	$v_i$’s credential issued by $DM{V}_k$
$KN$	Key word within a vehicle’s credential
$Lis{t}_{KN}$	List of generated $KNs$ periodically
$To{k}_{DV}$	A duty token for $D{V}_j$ generated by $DM{V}_j$
$alia{s}_i$	$v_i$’s pseudo identity
$ts$	time stamp
${\delta }_i$	certificateless signature of entity i
$\mathbb{G}$	Elliptic curve group with the same order q
$P\in {\mathbb{G}}_1$	A generator of ${\mathbb{G}}_1$
$s{k}_{id},p{k}_{id}$	private, public key pair of an entity X
$t_i$	Master secret for each attribute i
$ABE.amk$	Attribute master key
$T_i$	Public key for each attribute $i\in U$
$alia{s}_{v_i}$	$v_i$’s pseudonym
U	Universe of attribute
$\mathrm{\Gamma }$	Access tree
$\omega$	Attribute set
$A{S}_j$	Access Structure corresponding to entity j
D	Set of secret share $D_{lea{f}_l}$ in $\mathrm{\Gamma }$
$En{c}_k(.)$	Symmetric encryption under key k

, we summarize the notations used for the proposed protocol and the overall operations of the protocol are depicted in Figure 2.

5.1. System Setup

In setup phase, TA generates global system parameters and all the entities register to the TA as follows:

• TA selects an elliptic curve group ${\mathbb{G}}_1$ of order q with $P\in {\mathbb{G}}_1$ as a generator.
• In order to get the master secret $s{k}_{TA}$ and public key $p{k}_{TA}$, TA executes CertS.Setup() and sets $〈s{k}_{TA},CertS.params〉\leftarrow$ CLS.Setup(), then output $CertS.params$.
• In order to keep a record of each vehicle $v_i$, TA set a pseudonym $alia{s}_{v_i}$ to every $v_i$ based on its real identity $5GI{D}_{v_i}$.
• Each $RS{C}_j$, $D{V}_j$ and $DM{V}_k$ registers to TA, then computes CertS private keys as follows:
  • $RS{C}_j$, $D{V}_j$ and $DM{V}_k$ computes $Se{c}_{1,RS{C}_j}\leftarrow$ CertS.Secret($RS{C}_j$), $Se{c}_{1,D{V}_j}\leftarrow$ CertS.Secret($D{V}_j$) and $Se{c}_{1,DM{V}_k}\leftarrow$ CertS.Secret($DM{V}_k$), and makes a request for partial private key to the TA, respectively.
  • TA provides $Se{c}_{2,RS{C}_j}\leftarrow$ CertS.PartialK($s{k}_{TA}$, $RS{C}_j$, $P_{RS{C}_j}$); $Se{c}_{2,D{V}_j}\leftarrow$ CertS.PartialK($s{k}_{TA}$, $D{V}_j$, $P_{D{V}_j}$) and $Se{c}_{2,DM{V}_k}\leftarrow$ CertS.PartiaK($s{k}_{TA}$, $DM{V}_k$, $P_{DM{V}_k}$) to each entity securely.
  • $RS{C}_j$, $D{V}_j$ and $DM{V}_k$ set $〈s{k}_{RS{C}_j},p{k}_{RS{C}_j}〉\leftarrow$ CertS.SKey($Se{c}_{1,RS{C}_j}$, $Se{c}_{2,RS{C}_j}$); $〈s{k}_{D{V}_j},p{k}_{D{V}_j}〉\leftarrow$ CertS.SKey($Se{c}_{1,D{V}_j}$, $Se{c}_{2,D{V}_j}$) and $〈s{k}_{DM{V}_k},p{k}_{DM{V}_k}〉\leftarrow$ CertS.SKey($Se{c}_{1,DM{V}_k}$, $Se{c}_{2,DM{V}_k}$), respectively.
• Likewise, every $v_i$ computes $Se{c}_{1,v_i}\leftarrow$ CertS.Secret($alia{s}_i$), TA provides $Se{c}_{2,v_i}\leftarrow$ CertS.PartialK($s{k}_{TA}$, $alia{s}_i$, $P_{v_i}$), then $v_i$ sets $〈s{k}_{v_i},p{k}_{v_i}〉\leftarrow$ CertS.SKey($Se{c}_{1,v_i}$, $Se{c}_{2,v_i}$).
• $DM{V}_k$ selects a given universe of attributes $U=\{1,\dots ,N\}$, computes ABE parameters as $〈ABE.amk,labe.params〉\leftarrow$ ABE.Setup(), then avails $labe.params$ to the whole system. Note that $DMVs$ will later send $ABE.amk$ to TA in non busy hours.

5.2. 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 $DM{V}_k$, $v_i$ performs the following:

• $v_i$ composes a credential request message $RReq=\{alia{s}_i,K,ts\}$ where $ts$ is the time stamp and K is a secret key to be used later.
• $v_i$ sends $C_1=En{c}_{P{K}_{DM{V}_k}}\{RReq,p{k}_{v_i},{\delta }_i\}$ to the $DM{V}_k$, where $\delta$ is the signature for the $RReq$ set as ${\delta }_i$ = CertS.Sign($RReq$, $s{k}_{v_i}$).
• Upon receiving the message $C_1$, $DM{V}_k$ first decrypts $C_1$ using its private key, then verifies the signature as CertS.Verify($RReq$, $alia{s}_i$, $p{k}_{v_i}$, $\delta$).

If it holds, $DM{V}_k$ generates reporting credential (R-$cred$) as follows:

• Generate R-$cred=〈alia{s}_i,exp,KN,{\omega }_{v_i}〉$ where $exp$ is the expiration date, ${\omega }_{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.
• $DM{V}_k$ sends $C_1=En{c}_K(R$-$cred)$ to $v_i$. Then, $v_i$ can recover R-$cred$ by decrypting the $C_1$ under the shared secret key K.
• $DM{V}_k$ sends periodically a list $Lis{t}_{KN}$ of all the keywords enclosed in the credentials to $RSCs$.

5.3. On-Duty Token Generation

In the same way, $DM{V}_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.

• $D{V}_i$ composes an on-duty token request $DTRq=\{D{V}_j,K_1,ts\}$ where $ts$ is the time stamp and $K_1$ is a secret key to be used later.
• $D{V}_i$ sends $C_2=En{c}_{P{K}_{DM{V}_k}}\{DTReq,p{k}_{v_i},{\delta }_{DV}\}$ to the $DM{V}_k$, where ${\delta }_{DV}$ is the signature for the $DTRq$ set as ${\delta }_{DV}$ = CertS.Sign($DTRq$, $s{k}_{DV}$).
• Upon receiving the message $C_2$, $DM{V}_k$ first decrypts $C_2$ using its private key, then verifies the signature as CertS.Verify($DTRq$, $D{V}_j$, $p{k}_{D{V}_j}$, ${\delta }_{DV}$).
• $DM{V}_j$ set $\overline{D}\leftarrow$ ABE.KGN($ABE.amk$, $A{S}_{D{V}_j}$) where $A{S}_{D{V}_j}$ is the access structure corresponding to the designated vehicle’s type (police or ambulance).
• $DM{V}_j$ composes a token message $To{k}_{DV}=\{\overline{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). $DM{V}_j$ send it to $D{V}_j$ encrypted under the shared symmetric key $K_1$ as $C_3=En{c}_{K_1}\left(To{k}_{DV}\right)$.

5.4. 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:

• After recording a video file, $v_i$ composes a message $V=\{Vfil{e}_j,KN\}$; uses the access policy ${\omega }_{v_i}$ retrieved in the credential R-$cred$ and encrypts the file under the given attribute set ${\omega }_{v_i}$ as $S{F}_j\leftarrow$ ABE.Encrypt($Vfil{e}_j$, ${\omega }_j$, $labe.params$).
• $v_i$ sends $C_4=En{c}_{P{K}_{RS{C}_j}}\{alia{s}_i,KN,S{F}_j\}$ to $RS{C}_j$.
• $RS{C}_j$ decrypts $C_4$ and check if {$KN\in Lis{t}_{KN}$}.
• 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 $\omega$. As mentioned before, $DM{V}_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.
• Otherwise, $RS{C}_j$ forwards the file securely to neighboring $RSCs$.
• $RS{C}_j$ generates $C_5^{{}^{\prime }}={\delta }_{RS{C}_j}$ = CertS.Sign($S{F}_j$, $s{k}_{RS{C}_j}$) and broadcast $C_5=En{c}_{RK}\left(C_5^{{}^{\prime }}\right)$ within its coverage area.

After receiving the beacons, $DVs$ performs the following:

• $D{V}_j$ decrypts $C_5=En{c}_{RK}\left(C_5^{{}^{\prime }}\right)$ using the area shared key of $RK$. Note that only $DVs$ assigned to work within $RS{C}_j$ coverage can decrypt the $C_5$.
• $D{V}_j$ runs CertS.Verify($S{F}_j$, $RS{C}_j$, $p{k}_{RS{C}_j}$, ${\delta }_{RS{C}_j}$).
• $D{V}_j$ runs ABE.Decrypt($S{F}_j$, $\overline{D}$, $labe.params$) to get the original file of $Vfil{e}_j$.

6. Performance Evaluation

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

6.1. 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=\{alia{s}_i,K,ts\}$ with $C_1=En{c}_{P{K}_{DM{V}_k}}\{RReq,p{k}_{v_i},{\delta }_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$, $p{k}_{id}$, $\sigma$) to check if $r·(R+h_2·P)\stackrel{?}{=}{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=En{c}_{P{K}_{DM{V}_k}}\{RReq,p{k}_{v_i},{\delta }_i\}$ to the $DM{V}_k$ to request a credential. After a valid verification, $DM{V}_k$ sends $C_1=En{c}_K(R-cred)$ where $R-cred=〈alia{s}_i,exp,KN,{\omega }_{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 $alia{s}_{v_i}$. Though the malicious user would get the credential request message $RReq=\{alia{s}_i,K,ts\}$ , the single plain identity of $v_i$ which is available is its pseudo-identity $alia{s}_{v_i}$. In the rest of the protocol, the remaining available information concerning $v_i$ is its pseudo-identity $alia{s}_{v_i}$. We confirm that our protocol achieves identity privacy preservation.
• Fine-grained access control: In the proposed protocol, the video file $Vfile$ sent to $v_i$ is encrypted under a set of attributes as $S{F}_j\leftarrow$ ABE.Encrypt($Vfil{e}_j$, ${\omega }_j$, $labe.params$). The file is sent encrypted under the public key of $RS{C}_j$.$RS{C}_j$ only checks if $KN\in Lis{t}_{KN}$; this will save the $RSCs$ from availing bogus files to $DVs$. $RS{C}_j$ can not recover the file. Even for $DVs$, unless a $D{V}_j$ possesses the required secret shares $D_{lea{f}_l}=q_{lea{f}_l}\left(0\right)·t_i^{-1}$ , it cannot reconstruct the root node R to be able to get the secret $q_{root}\left(0\right)·k·P=s·k·P$. Throughout the decryption stage based on the root or child node, except $D{V}_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 $RS{C}_j$ keeps $v_i$’s pseudo identity and its anonymous keyword $KN$ contained in the credential $R-cred=〈alia{s}_i,exp,KN,{\omega }_{v_i}〉$.
• 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 $alia{s}_{v_i}$. We conclude that the proposed protocol satisfies the traceability property.

6.2. Cost Comparison

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

6.2.1. 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, $\{\mathbb{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. Measurement of cryptographic operations.

Notation	Operations	Time (ms)
$T_{pair}$	Bilinear pairing	4.5
$T_{mul}$	Point scalar multiplication	0.6
$T_{as-enc}$	Asymmetric encryption	1.17
$T_{as-dec}$	Asymmetric decryption	0.61
$T_{s-enc}$	Symmetric encryption	0.51
$T_{s-dec}$	Symmetric decryption	0.55
$T_h$	hash function	0.0001

.

6.2.2. Overall Cost Including Communication Cost

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. Computational costs of the Eiza-Ni-Shi protocol [18] and the proposed protocol.

Scheme Phase	Eiza et al. [18]	Proposed
Signing/video	$(d+2)T_{mul}+(d+2)T_{pair}$	$(d+1)T_{mul}$
Verification/video	$7T_{pair}+4T_{mul}$	$(d+3)T_{mul}$
Total cost/ms	64	$7.2$

(d=number of leaf node).

. As being described in Section 5.4, $v_i$ computes $W_i=k·P_i$ and $q_{lea{f}_l}\left(0\right)·t_i^{-1}$ ; 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 $RS{C}_j$ which equals to $T_{as-enc}$. $RS{C}_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, $D{V}_i$ decrypts the file in $T_{as-dec}$ and checks if $r·(R+h_2·P)\stackrel{?}{=}$$P_{id}+R_{id}+(h_1·P_{pub})$ for signature verification in $2T_{mul}$. $D{V}_j$ computes $q_{lea{f}_l}\left(0\right)·k·P$ in $d{T}_{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.

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