A secure billing protocol over attribute-based encryption in vehicular cloud computing

Abstract

The integration of cloud computing into vehicular ad hoc networks (VANETs) has allowed the possibility of offering multiple services to the vehicle owners ranging from safety to entertainment services. The ubiquitousness of cloud computing involves a multitude of service providers; thus, an efficient and secure access control mechanism is required. However, rigorous security features need to be addressed for such commercial-based services to be fully adopted. In this paper, we present a secure billing protocol over attribute-based encryption in vehicular cloud computing. We achieve the identity privacy of the vehicles and their requested services through pseudonym techniques. Certificateless signature scheme is used to assure the authentication of legitimate vehicles which can enjoy the provided services. We use attribute-based encryption to guarantee access control based on the purchased services. We make use of hash chain technique to provide authorization through electronic voucher (credits) which a vehicle has to possess in order to purchase a service. Unlike existing protocols in VANETS, the proposed protocol is not built on expensive bilinear pairing operations. We provide the efficiency of the proposed protocol through performance analysis and simulation.

1 Introduction

Combining cloud computing (CC) with vehicular ad hoc networks (VANETs) to form vehicular cloud computing (VCC) appeals the existing cloud service providers (CSPs) such as Amazon EC2, S3, Microsoft Azure to also extend their services to vehicle users. Taking advantage of the vehicle’s on-board unit (OBU), the vehicle users would have additional computing resources to enjoy various services from safety to infotainment-related services. In conventional cloud computing, CSPs usually offer a pay-per-use billing system in their pricing model which means that a user will only be charged for exactly the amount of services provided. A vehicle user can acquire the services on the move using the OBU’s visual and computational capabilities. As pointed out by Li et al., a key success of commercial applications over vehicular environment will inevitably be featured by entity authentication and billing while simultaneously embracing the vehicle mobility [1].

Basic security requirements in VCC have been addressed such as entity authentication, authorization, and privacy [2, 3]. Existing literature has more focused on access control mechanisms which allow a CPS to provide multiple services within a single package [4–6]. To enforce access control in different services, attribute-based encryption (ABE) has widely been adopted to offer a number of services embedded within a single package [4, 5]. Even though ABE ensures that a service is accessed by a legitimate user, bad-intentioned vehicle user might over use the services as long as the access structure permits it. Thus, secure billing feature is required in order the vehicle users to strictly access what they consent to pay for. Secure billing systems which provide evidence to the vehicle user when it comes to payment need to be considered for a full adoption of the commercial services in VCC.

Among the relevant works with secure billing feature in VANETs, Yeh et al. proposed a local and proxy-based authentication and billing protocol in order to reduce the communication overhead. Their protocol proposed an incentive-aware multi-hop forwarding technique for vehicles in the VANETs [7]. The protocol did not consider secure access control which is indispensable for CSPs within the VCC architecture. In another work, Yeh et al. proposed a portable authentication/authorization/accounting (AAA) framework for purchasing services from the road entities (RSUs). They used signature-based and key policy attribute-based encryption (KP-ABE) in their billing mechanism to achieve localized fine-grained access control [4]. However, in their protocol, the system master secret key must be distributed to every vehicle temper proof device. Therefore, in case the temper proof device is compromised, the system security features are affected [8]. Moreover, these protocols are built based on expensive pairing operations which will hinder the whole system efficiency since the CSPs would also provide voluminous files such as mp3 files or movies.

In this paper, we present a secure billing protocol over attribute-based encryption in vehicular cloud computing. The identity privacy of the vehicles and their requested services is achieved through pseudonym techniques. We make use of certificateless signature scheme to assure the authentication of legitimate vehicles which can enjoy the provided services [9]. ABE is adopted to guarantee rigorous access control based on the provided access structure [10]. Hash chain technique is to used to guarantee the authorization property through electronic voucher which a vehicle has to possess before enjoying any giving service [11].

1.1 Motivation and contribution

The vehicles on the move need also to enjoy a variety of services provided by the CSPs as individuals do through the smart phones. Additionally, the vehicles on the move are predicted to easily and efficiently enjoy the CSP’s services due to the technological features such as visual, computing, and networking in-built capabilities. However, the CSP owners have to make sure that the vehicle users pay for the provided services along with additional security properties which need to be met before the adoption of the commercial services in VCC. We describe our contributions as follows:

• We first present an application model for a secure billing protocol over attribute-based encryption in vehicular cloud computing which allows the vehicle users to enjoy a variety of service on the move. We define the security requirements to be met by the proposed protocol.

• We present a secure billing protocol over attribute-based encryption in vehicular cloud computing based on the techniques of attribute-based encryption, secret sharing scheme, certificateless signature scheme, and hash chain technique.

• We apply electronic voucher (credits) feature in the system to restrict the vehicles from over using the acquired access structure in order to enjoy the embedded services. Thus, a vehicle is not prompt to enjoy a given service in a limited time. The electronic coin boosts the confidence of the CSPs over non-repudiation of payment.

• We provide analysis of the proposed protocol in terms of security objectives. We further evaluate the performance of the proposed protocol through computational delay, transmission overhead, and simulation.

The remainder of the paper is organized as follows. We first present the related work and the preliminaries in Section 2 and Section 3, respectively. We present the system architecture of the proposed protocol in Section 4 and the design of our protocol in Section 5. We discuss the security analysis and performance of the proposed protocol in Section 6 and finally conclude in Section 7.

2 Related work

In this section, we present the related work which is subdivided into two sub-sections. We first present the evolution of vehicle communication architectures from the conventional VANET framework to vehicular cloud computing extensions along with related security mechanisms. Then, we present the existing work on billing schemes within the CC environment and VCC.

2.1 VANET architecture

VANET result as an extension of mobile ad hoc netwoks (MANETs) [12]. In VANETs, the main entities represent the vehicles, RSUs, and an over-viewer third party called Trusted Authority (TA) in charge of registration, certification, and revocation of all the entities within the VANET architecture [13]. Conventional VANETs avail two major communication means through the dedicated short-range communication (DSRC) as V2V and V2I communications [14]. A considerable number of applications were predicted to be achieved through the VANET architecture; however, the computational cost of the value-added applications in VANETs require huge computation capabilities which led to the mixture of VANETs and cloud computing [15].

Vehicular cloud was introduced by Olariu et al. for the first time [16]. An extension of their work suggested an autonomous vehicular cloud (AVC) architecture as a special case of VANET cloud [17]. Hussain et al. defined three types of architectures which originated from the combination of VANETs and cloud computing [18]. VANETs using cloud is defined as vehicles equipped with smart devices and communicating with the cloud the same way as our mobile phones connect to different servers located in the cloud. Vehicular cloud refers to the full utilization of vehicle devices as computers to form mobile servers. In this architecture, one could use the vehicle OBU’s to make his/her personal cloud. Hybrid vehicle cloud is a combination of the above architectures also referred as VCC. The feasibility of VCC was adopted by several researchers [19, 20], though security issues within the cloud computing are still an attractive on-going research whereby different secure protocols have been proposed [21]. In this work, we construct our protocol based on VANETs using cloud architecture.

2.2 Secure billing schemes

A billing transaction refers to the saving of the the movement logs in order to verify the billing operations. Billing transactions are part of electronic payment schemes. Time-based billing and content-based billing are the main billing approaches in cloud computing and depend on the type of required services. However, several CSPs seem to embrace content-based billing rather than time-based billing [22]. A considerable number of electronic payment schemes have been suggested in the literature. Among them are micro-payment-based schemes such as MiniPay and Netpay [23]. These e-payment systems allow the users of cloud-based applications to securely and efficiently perform payments. These schemes are built using one-way hash functions that generate chains of hash values. The cloud users will first release several hashes with the hash chain in order to perform billing transactions. On the basis of the micro-payment-based scheme, Pay-as-you-Browse [24] and XPay [22] fused the micro-payment concept into cloud-hosted services. Though those schemes have less billing latency, they do not support additional security features required for billing transactions in cloud-based services.

Within the vehicular environment, secure billing feature is core prerequisite for a full adoption of commercial-based services by the CSPs in VCC. Several billing mechanisms have been proposed for VANET applications [4, 7, 25, 26]. In [7], Yeh et al. proposed a local and proxy-based authentication and billing scheme to reduce the communication overhead. The protocol proposed an incentive-aware multi-hop forwarding for the vehicles within the VANET architecture. They adopted batch verification technique in their scheme to fulfill the security requirements and signature-based communications. However, the protocol does not satisfy access control property, thus cannot allow multiple services in a single package. In [4], Yeh et al. proposed a portable AAA framework which allow the vehicle users to enjoy CSP’s services from the RSUs. They used signature-based and KP-ABE in the billing protocol to attain localized fine-grained access control and also employed E-coin to provide service authorization. However, the proposed protocol is built based on expensive pairing operations which might not be efficient due to voluminous sizes of various files.

3 Preliminaries

In this section, we present the basic properties of lightweight attribute-based encryption (lABE) based on Elliptic Curve Integrated Encryption Scheme (ECIES) and certificateless signature scheme which form the basic cryptographic primitives of the proposed protocol.

3.1 Lightweight ABE scheme

The lABE scheme of [10] based on elliptic curve cryptography consists of Setup, Encryption, Key-Generation, and Decryption algorithms.

3.1.1 lABE.Setup

Suppose that the attribute space of the system is defined as the universe of attributes U={1,2,…,n}. Let G be an additive group with a prime order q and P∈G, where G consists of points on an elliptic curve and P is a generator of G. lABE.Setup() algorithm generates lABE parameters as follows:

• 1. Choose a random $s \in Z_{q}^{*}$ as the attribute master secret key and computes the corresponding public key PK=s·P.

• 2. For each attribute i∈U, choose an attribute secret $t_{i} \in Z_{q}^{*}$ and compute the attribute public key P _i =t _i ·P.

• 3. Set amk={s,t ₁,…,t _|U|} and labe.params={PK,P ₁,…,P _|U|}

• 4. Returns <amk,labe.params>

3.1.2 lABE.Encrypt

Given a message m, an attribute set ω, and labe.params, lABE.Encrypt(m, ω, labe.params) outputs the cipertext CM as follows:

• 1. Choose $k \in Z_{q}^{*}$ and compute the key K=k·PK.

• 2. Compute C=Enc _K (m).

• 3. For each i∈ω, compute W _i =k·P _i , respectively.

• 4. Return the cipertext CM=<ω,C,{W _i | i∈ω}>

3.1.3 lABE.KeyGen

For the given master secret amk and the access tree Γ, lABE.KeyGen(amk, Γ) algorithm generates secret shares of the decryption key for the encrypted message under the attribute set ω.

• 1. For the access tree Γ, assign index to each node other than root.

• 2. For each node, a polynomial q _node (x) over $Z_{q}^{*}$ is defined in top-down manner where each polynomial is of degree d _node −1 and d _node is the threshold value of the node.

  • for the root, set q _root (0)=s.

  • for other nodes including leafs, set q _node (0)=q _parent (index(node)) where index(node) is the index value of the node.

• 3. Let n be the number of leaves in Γ, for each leaf node leaf _l (1≤l≤n), a secret share of the decryption key is computed as $D_{leaf_{l}} = q_{leaf_{l}} (0) \cdot t_{i}^{-1}$ where i is the attribute associated to leaf _l and t _i is the random number for i chosen in lABE.Setup.

• 4. Return $D = \{ D_{leaf_{l}} ~|~ leaf_{l} \in \Gamma \}$

3.1.4 lABE.Decrypt

The decryption algorithm lABE.Decrypt(CM, D, labe.params) decrypts the cipertext CM, if and only if the attributes set ω satisfies the access tree Γ, by using NodeKey(CM, D, node) for a node in the access tree recursively. In the lABE scheme [10], secret sharing based on Lagrange interpolation [Shamir] is used to reconstruct the decryption key.

• 1. For each leaf node to which an attribute i is associated, NodeKey(CM, D, leaf _l ) is defined as follows:

  • if the associated attribute i to leaf _l is not included in ω, then NodeKey(CM, D, leaf _l ) = ⊥.

  • otherwise,

    $$\begin{array}{@{}rcl@{}} \text{NodeKey} (CM, D, leaf_{l}) &=& D_{leaf_{l}} \cdot W_{i} \\ &=& q_{leaf_{l}} (0) \cdot t_{i}^{-1} \cdot k \cdot P_{i} \\ &=& q_{leaf_{l}} (0) \cdot t_{i}^{-1} \cdot k \cdot t_{i} \cdot P \\ &=& q_{leaf_{l}} (0) \cdot k \cdot P \end{array} $$

• 2. For a non-leaf node u, it calls NodeKey(CM, D, z) for all children z of the node u.

  • Let ω _u be an arbitrary d _u sized set of children nodes such that NodeKey(CM, D, z) ≠⊥. If no such set exist NodeKey(CM, D, u) returns ⊥.

  • Otherwise, let $\Delta _{index(z), {\omega }'_{u}} = \prod _{j \in {\omega }'_{u}, j \ne index(z)} {x - j \over {i - j}}$ be the Lagrange coefficient where ωu′={index(z) | z∈ω _u },

    $$\begin{array}{@{}rcl@{}} \text{NodeKey} (CM, D, u) &=& \sum_{z \in \omega_{u}} \Delta_{index(z), {\omega}'_{u}} (0)\\ &&\times\text{NodeKey}(CM, D, z) \\ &=& \sum_{z \in \omega_{u}} \Delta_{index(z), {\omega}'_{u}} (0) \cdot q_{z} (0) \cdot k \cdot P \\ &=& \sum_{z \in \omega_{u}} \Delta_{index(z), {\omega}'_{u}} (0)\\ &&\times q_{parent} (index(z)) \cdot k \cdot P\\ &=& \sum_{z \in \omega_{u}} \Delta_{index(z), {\omega}'_{u}} (0)\\ &&\times q_{u} (index(z)) \cdot k \cdot P \\ &=& q_{u} (0) \cdot k \cdot P \end{array} $$

• 3. Calculate the decryption key K = NodeKey(CM, D, root) = q _root (0)·k·P=s·k·P.

• 4. Return the decrypted message m=Dec _K (C).

3.2 Certificateless signature scheme

The certificateless signature (CLS) scheme of [9] consists of the following algorithms.

• CLS.Setup() algorithm generates a master key and public system parameters as follows:

  • Choose an additive group G with a prime order q and a generator P∈G defined on an elliptic curve.

  • Select master secret key $s \in Z_{q}^{*}$ and computes the master public key P _pub =s·P.

  • Choose two cryptographic hash functions $H_{1} : \{0,1\}^{*} \times G^{2} \rightarrow Z_{q}^{*}$ and $H_{2} : \{0,1\}^{*} \times G^{3} \rightarrow Z_{q}^{*}$.

  • Set public system parameters cls.params={G,q,P,P _pub ,H ₁,H ₂}.

  • Return <s,cls.params>

• CLS.SetSecret(id) outputs a secret value for the given identity id as follows:

  • Select randomly $x_{id} \in Z_{q}^{*}$ as a secret value and compute P _id =x _id ·P.

  • Return S ₁=<x _id ,P _id >

• CLS.PartialKey(x, id, P _id ) generates a partial private and public key for the id as follows:

  • Choose a random $r_{id} \in Z_{q}^{*}$ and compute R _id =r _id ·P.

  • Compute s _id =r _id +s·H ₁(id,R _id ,P _id ) (mod q).

  • Return S ₂=<s _id ,R _id > as the partial private key.

• CLS.SetKey(S ₁, S ₂) sets sk _id =<x _id ,s _id > and pk _id =<P _id ,R _id > as the private key and public key for the entity of id, respectively.

• CLS.Sign(m, sk _id ) generates the signature for a message m as follows:

  • Choose a random $l \in Z_{q}^{*}$ such that gcd(l+h, q) = 1, where h=H ₂(m,R,P _id ,R _id ) and R=l·P.

  • Compute r=(l+h)⁻¹(x _id +s _id ) (mod q).

  • Return the signature σ=<r,R>.

• CLS.Verify(m, id, pk _id , σ) verifies the signature σ for the message m under the id as follows:

  • Compute h ₁=H ₁(id,R _id ,P _id ) and h ₂=H ₂(m,R,id,P _id ,R _id ).

  • Check if $r \cdot (R + h_{2} \cdot P) \overset {\mathrm {?}}{=} P_{id} + R_{id} + (h_{1} \ \cdot P_{pub})$.

4 Proposed protocol

In this section, we first present the system architecture of the proposed protocol. Secondly, we present the security requirements of the proposed protocol, and lastly, we outline the main phases of the proposed protocol.

4.1 Architecture

We describe the communication entities within our protocol which are made of Trusted Authority (TA), Service Providers (SPs), Road Side Cloud (RSC), and vehicles which communicate through the OBU as shown in Fig. 1:

• TA: It is in charge of the registration of all entities (RSC, SPs, and vehicles) inside our system and issues cryptographic materials during the system initialization.

  Fig. 1

  

  System architecture

• RSC: RSCs are databases located along the roads and accessible by the vehicles. The RSCs store the service files (SFs) provided by the SPs. In that case, the vehicles can acquire the files through the RSCs. The vehicles get the electronic voucher from SPs through the RSCs. Due to the advancements of technology, we assume that RSCs are connected to an electricity power generator with enough computational capability.

• SPs: It is a server located in the cloud belonging to a cloud-based commercial service providers (CSPs). SPs offer a range of services, and one service package can incorporate several services such as mp3 audio, a map, or a short video clip. SPs send their service files to RSCs so that the vehicles can easily download them. However, in order to convince the vehicles of the services they need to be charged for, TA provides an electronic voucher with a given value which a vehicle has to satisfy in order to get the services. Moreover, the electronic voucher logs are sent to TA in non-rushing hours for accountability and non-repudiation of payment.

• Vehicles: Vehicles are equipped with OBUs which allow them to communicate with RSCs in order to require files from the SPs.

4.2 Security objectives

Our protocol should satisfy the following security requirements:

• Authentication and authorization: Each vehicle should be authenticated before it can receive a service file from SPs through the RSCs. Additionally, only legitimate subscribers should get access to use SP’s services.

• Identity privacy preservation: The real identity of a vehicle should be kept secret from other vehicles, RSC, and SPs.

• Fine-grained access control: Through fine-grained access control based on ABE, a vehicle should strictly be able to open a service corresponding to its access structure.

• Double-spending resistance: A vehicle should not over use its purchased electronic voucher to open additional files.

• Non-repudiation of payment: A vehicle should not deny the electronic voucher which it has used to open a given file. This would help in case of disputes over billing issues.

• Traceability: TA should be able to reveal the real identity of SPs and vehicles.

The proposed protocol consists of the following sub-protocols:

• 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. SPs and RSCs also provide their real identities, and TA computes their partial private keys. Each SP generates the service files along with their access structures. SPs send securely the attribute master key of each file to TA. SPs also send the service files to RSC along with the corresponding secret keys which will be used for E-voucher generation through hash chain technique.

• E-voucher Generation: Periodically, a vehicle registers for SP’s services. During the registration, the vehicle specifies the service files it wishes to acquire. Then, TA generates an electronic voucher (EV) which contains the secret shares corresponding to the access structure which the vehicle registered for. E-voucher will work as a transaction evidence for the purchased services.

• Service Purchase: RSCs periodically advertise the SP’s services. v _i can request of any service among the advertised services. Depending on the E-voucher balance, RSC _j first computes a new value of EV based on the requested services and sends the services to v _i along with the secret shares corresponding to the access structure of the requested service.

5 Proposed description

In this section, we design a secure billing protocol over attribute-based encryption in vehicular cloud computing. Table 1 shows the notations used in describing the proposed protocol.

Table 1 Notations and descriptions

5.1 System setup

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

• 1. TA chooses an elliptic curve group $\mathbb {G}$ of order q and a generator $P \in \mathbb {G}$.

• 2. To generate master secret sk _TA and public key pk _TA , TA runs CLS.Setup() and sets <sk _TA ,cls.params>← CLS.Setup(), then publishes cls.params.

• 3. For registering each vehicle v _i , TA assigns a pseudonym $alias_{v_{i}}$ to each v _i .

• 4. Each RSC _j and SP _k registers to the TA and generate CLS private keys as follows:

  • RSC _j and SP _k generate $S_{1, RSC_{j}} \leftarrow$ CLS.SetSecret(RSC _j ) and $S_{1, SP_{k}} \leftarrow$ CLS.SetSecret(SP _k ), and requests partial private key to the TA, respectively.

  • TA issues $S_{2, RSC_{j}} \leftarrow$ CLS.PartialKey(sk _TA , RSC _j , $P_{RSC_{j}}$) and $S_{2, SP_{k}} \leftarrow$ CLS.PartiaKey(sk _TA , SP _k , $P_{SP_{k}}$) to each entity securely.

  • RSC _j and SP _k set $\left < sk_{RSC_{j}}, pk_{RSC_{j}} \right > \leftarrow$ CLS.SetKey($S_{1, RSC_{j}}$, $S_{2, RSC_{j}}$) and $\left < sk_{SP_{k}}, pk_{SP_{k}} \right > \leftarrow$ CLS.SetKey($S_{1, SP_{k}}$, $S_{2, SP_{k}}$), respectively.

• 5. Similarly, each v _i generates $S_{1, v_{i}} \leftarrow$ CLS.SetSecret(alias _i ), TA issues $S_{2, v_{i}} \leftarrow$ CLS.PartKeyExtract(sk _TA , alias _i , $P_{v_{i}}$), then v _i sets $\left < sk_{v_{i}}, pk_{v_{i}} \right > \leftarrow$ CLS.SetKey($S_{1, v_{i}}$, $S_{2, v_{i}}$).

In addition, each service provider SP prepares service files served under a given access structure as follows:

• 1. SP decides the universe of attributes U={1,…,N}, generates ABE parameters as <amk,labe.params>← lABE.Setup(), and publishes labe.params to the system.

• 2. Let l be the number of service files. SP decides access tree AT _j and prepares encrypted service file SF _j (1≤j≤l) under a given attribute set ω _j as SF _j ← lABE.Encrypt(file _j , ω _j , labe.params).

• 3. SP picks a secret key α to be shared with TA and RSCs and provides

  <amk,α,{SF _j | 1≤j≤l},{AT _j | 1≤j≤l}> to RSCs and α to the TA securely.

5.2 E-voucher generation

Periodically, the vehicles request an electronic voucher (EV) which permits to enjoy the services offered by any SPs through the RSCs. To acquire an EV from TA, v _i performs the following:

• 1. v _i composes an electronic voucher request message EVR={alias _i ,K,ts} where ts is the time stamp and K is a secret key to be used later.

• 2. v _i sends $\phantom {\dot {i}\!}C_{1} =Enc_{PK_{TA}}\{EVR, pk_{v_{i}}, \delta _{i}\}$ to the TA, where δ is the signature for the EVR set as δ _i = CLS.Sign(EVR, $sk_{v_{i}}$).

• 3. Upon receiving the message C ₁, TA first decrypts C ₁ using its private key, then verifies the signature as CLS.Verify(EVR, alias _i , $pk_{v_{i}}$, δ). If it holds, TA generates E-voucher (EV) as follows:

  • Let d be the maximum credits for v _i to purchase service files. Compute hk _d =hash ^d(α) where hash ^d() represents the d-th hash chain, i.e.,

    hk _d =hash(hash ^d−1(α))=hash(hash(…(hash(α))…)).

  • Generate $EV = \left < alias_{i}, exp, d, MAC_{hk_{d}} (alias_{i} | exp | d) \right >$ where exp is the expiration date.

• 4. TA sends C ₁=Enc _K (EV) to v _i . Then, v _i can recover EV by decrypting the C ₁ under the shared secret key K.

5.3 Service purchase

A vehicle after getting the EV can enjoy file services from any chosen RSC _j . RSC _j advertises periodically the services along with their denomination value $\hat {d}$.

• 1. From service file lists advertised, v _i chooses a list for $SF^{\prime }_{j}$ and composes a service request message $mf= \{ SF'_{j}, EV, alias_{i}, pk_{v_{i}}, K', ts\}\phantom {\dot {i}\!}$ where K ^′ is a secret key to be shared with RSC _j , and sets δ _j ← CLS.Sign(mf, $sk_{v_{i}}$). v _i sends $\phantom {\dot {i}\!}C_{2} = Enc_{PK_{RSC_{j}}} (mf, \delta _{i})$ to RSC _j .

• 2. RSC _j decrypts the C ₂ and verifies the signature δ _i as CLS.Verify(mf, alias _i , $pk_{v_{i}}$, δ _i ). If it holds and the balance $d \ge \hat {d}$,

  • Compute hk ^′=hash ^d(α) and check if $MAC_{hk'} (alias_{i} | exp | d) \overset {\mathrm {?}}{=} MAC_{hk_{d}} (alias_{i} | exp | d)$.

  • Generate a new E-voucher $EV = \left < alias_{i}, exp, d', MAC_{hk_{d'}} (alias_{i} | exp | d') \right >$ where $d' = d - \hat {d}$ and $h{k}_d^{\prime }= has{h^d}^{\prime}\left(\alpha \right)$.

  • Set $\bar {D} \leftarrow$ lABE.KeyGen(amk, AT _j ).

  • Generate $C_{3} = Enc_{K'} (EV | \bar {D})$.

• 3. RSC _j provides <SF _j ,C ₃> to v _i .

• 4. v _i decrypts C ₃ to recover EV and $\bar {D}$, and runs lABE.Decrypt(SF _j , $\bar {D}$, labe.params) to get the original file of SF _j .

6 Performance

In this section, we evaluate the performance of the proposed protocol based on the security analysis, the computation delay, the transmission cost, the communication overhead, and simulation.

6.1 Security

According to the aforementioned security objectives, we analyze and discuss the security of the proposed protocol.

• Authentication: The authentication of each v _i requesting a service file is guaranteed by the certificateless signature scheme on message EVR={alias _i ,K,ts} with $\phantom {\dot {i}\!}C_{1} =\text {Enc}_{PK_{\text {TA}}}\{\text {EVR}, pk_{v_{i}}, \delta _{i} \}$. No adversary can forge a valid signature due to the hardness of DL problem. Otherwise, the verifier could check the validity of the message EVR by running CLS.Verify(m, id, pk _id , σ) to check if $r \cdot (R + h_{2} \cdot P) \overset {\mathrm {?}}{=} P_{id} + R_{id} + (h_{1} \ \cdot P_{\text {pub}})$. Thus, the proposed protocol provides message authentication.

• Authorization: Any vehicle has to be acquire a electronic voucher before it can use SP’s service. v _i sends $\phantom {\dot {i}\!}C_{1} =\text {Enc}_{PK_{\text {TA}}}\{EVR, pk_{v_{i}}, \delta _{i} \}$ to the TA to request electronic voucher. After a successful verification, TA sends C ₁=Enc _K (EV) where $\text {EV} = \left < \text {alias}_{i}, \text {exp}, d, \text {MAC}_{hk_{d}} (\text {alias}_{i} |\mathrm { exp} | d) \right >$ as v _i ’s EV which allows the v _i to access SP’s services.

• Identity privacy preservation: An attacker cannot obtain a real identity of a vehicle throughout our proposed protocol. During the registration phase of the vehicle by TA, each vehicle v _i is given a pseudo-identity $\text {alias}_{v_{i}}$. Even though the attacker captures the EVR request message EVR={alias _i ,K,ts}, the only plain identity of v _i available is its pseudo-identity $\mathrm {\text {alias}}_{v_{i}}$. In the remaining protocol’s operations, the only available information of v _i is its pseudo-identity $\text {alias}_{v_{i}}$. We conclude that the proposed protocol guarantees identity privacy preservation.

• Fine-grained access control: In our protocol, the service file $C_{3} = \text {Enc}_{K'} (\text {EV} | \bar {D})$ which is sent to v _i is first encrypted under a shared symmetric key K ^′. Moreover, unless a vehicle possesses the required secret shares $D_{\text {leaf}_{l}} = q_{\text {leaf}_{l}} (0) \cdot t_{i}^{-1}$ from AT _j , the vehicle cannot reconstruct the root node R to be able to get the secret q _root(0)·k·P=s·k·P. During the decryption phase based on the root or child node, unless v _i possesses the required secret shares, the decryption process output ⊥. Thus, even the vehicles which share a number of attributes cannot collude together to recover the secret which allow the decryption of the service file.

• Double-spending resistance: A vehicle cannot over use its access structure to enjoy beyond what its electronic voucher can allow. Before RSC _j sends a service file to v _i , a new value of E-voucher $EV = \left < \mathrm {\text {alias}}_{i}, \text {exp}, d', \text {MAC}_{hk_{d'}} (\text {alias}_{i} | \text {exp} | d') \right >$ where $d' = d - \hat {d}$ and $h{k}_d^{\prime }={{\mathrm{hash}}^d}^{\prime}\left(\alpha \right)$ is generated. Thus, we confirm that the proposed protocol is resistant to double spending of E-voucher.

• Non-repudiation for payment: A vehicle cannot deny of using the services because a log message is attached to ensure that the vehicle transactions are saved. Moreover, though the RSC does not control the electronic spending of v _i , it keeps records of the number of turns E-voucher has been regenerated.

• 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 $\text {alias}_{v_{i}}$. We conclude that the proposed protocol satisfies the traceability property.

6.2 Computational delay

In this section, we evaluate the performance of our protocol in terms of computational delay. Note that we ignore the time complexity involved in setup because it is assumed to be done offline and occasionally. We mainly consider the operations that dominate the speed of signature generation and signature verification such as one point multiplication, one pairing operation over an elliptic curve, asymmetric encryption, asymmetric decryption, symmetric encryption, signature generation, and signature verification. We neglect all other small operations such as additions. We consider the implementation parameters in [27, 28] with embedding degree 6, with $\{\mathbb {G}, q\}$ represented by 161 and 160 bits, respectively. The implementation was executed on a 3.5-GHz, core i-5, 16GB RAM desktop computer. The obtained results are shown in Table 2.

Table 2 Measurement of cryptographic operations

As described in Section 3.2, v _i sends a request for SP’s file by computing h=H ₂(m,R,P _id ,R _id ), R=l·P, and r=(l+h)⁻¹(x _id +s _id ) (mod q) which equals to 2T _mul. RCS _j computes W _i =k·P _i and $q_{\text {leaf}_{l}} (0) \cdot t_{i}^{-1}$, which equals to (I+1)T _mul where I is the number of attributes for the requested files. During the service purchase phase in Section 5.3, to recover the main secret based on the secret shares, v _i computes $q_{\text {leaf}_{l}} (0) \cdot k \cdot P\phantom {\dot {i}\!}$ which equals to dT _mul where d is the number of nodes in the access structure. The E-voucher verification and regeneration is similar for both v _i and RSC _j which equals to T _h . If we set the number of attributes (I=5) and the number of leaf node (d=5), then the computational cost equals to 9.36 ms for the proposed protocol and 40.2 ms for PBS [4]. The overall computational cost is illustrated in Table 3.

Table 3 Computational cost [4] of and proposed protocol

6.3 Number of transmission RSCs

Taking into consideration the computational delay on v _i and RSC _j , we investigated the number of transmission RSCs that are needed to send a file (based on the size) which will influence the predictive handoff protocols to be adopted [29]. We consider the following settings to simulate a practical scenario [30]:

• The average velocity of a vehicle (denoted v) ranges from 10 to 40 m/s (36–144 km/hr).

• The valid coverage range of an RSC (denoted C _RSU) is 300 to 600 m.

• The data rate α of a service channel can be up to 54 Mbps,

• The vehicle density (denoted de) of an RSC on two-lane two-way streets varies from 50 to 150 vehicles.

• The service files size (denoted s) is assumed to weight from 0.5 to 20 Mbytes. The files may contain maps, mp3, mp4, or videos.

Let η be the probability that each vehicle issues a service request, and let X be a random variable representing the number of requesting vehicles among a total of de vehicles. As a result, X follows a binomial distribution $\mathbb {B}(de, \eta)$, and we have:

$$ P\{X=x\} =\left(\begin{array}{c}de \\ x \\ \end{array} \right) \eta^{x}(1-\eta)^{de-x}, x=0,1,2,\ldots.,de $$

and an expectation value of

$$ E(X) =\sum_{x=o}^{de} \Big(\begin{array}{c}de \\ x \\ \end{array} \Big) \eta^{x}(1-\eta)^{de-x}=de \cdot \eta $$

The RSC verifying the service requests will estimate how many RSCs are needed (denoted N _RSC ) to transmit the requested file. We measure how much time (denoted T _Req ) is required for a service file as $T_{\text {Req}} =\frac { s~\times ~1024~\times ~1024~\times ~8~\times ~ E(X)}{\alpha ~\times ~54~\times ~1024~\times ~1024}=\frac {s~\times ~de~\times ~\eta ~\times ~8}{\alpha ~\times ~54 }$.

We then compute $N_{\text {RSC}} =\frac {(T_{v_{i}}~+~T_{\text {RSC}})~\times ~v~\times ~T_{\text {Req}}}{C_{RSC}}$ where $T_{v_{i}}$ and T _RSC represent the computational overhead of v _i and RSC _j , respectively, as shown in Table 3.

We further compare our protocol with existing scheme [4] which considers privacy, access control, and billing features. As noted in [4], PBS protocol requires 10 RSCs to complete forwarding a service of 20 Mbytes. However, in the same circumstances, the proposed protocol requires only 2 RSCs as shown in Figs. 2 and 3, respectively.

Fig. 2

Required number of RSCs for PBS [4]

Fig. 3

Required number of RSCs for proposed protocol

6.4 Communication overhead

In this section, we analyze the communication overhead of the proposed scheme. The sizes of the elements are 64×2=128 bytes for pairing based operations and 20×2=40 bytes for ECC-based elements [31]. The sizes of the general hash function’s output and time stamp are 20 and 4 bytes, respectively. Compared to [4], the proposed protocol offers lower communication overhead since PBS [4] is build based on expensive pairing operations. The total message size is 70 bytes for the proposed protocol in which we consider that the access structure Γ contains 5 nodes (I = 5).

6.5 Simulation

Additionally, we evaluate the performance of the proposed protocol through simulation. We used VANET-SIM simulator for vehicle mobility coupled with ns-3 simulator for network simulation [32]. We further set our scenario based on the IEEE 802.11p VANET platform range which is 2.56 Mbps in highly populated street such as highways that use DSRC, to a maximum transmission range of 6 Mbps. We consider a city scenario with a map downloaded from OpenStreepMap database [33] with a random speed for the vehicles ranging from 10 to 40 m/s (36–144 km/hr). The details of the simulation are shown in Table 4. The average overall delay (denoted Av _D ) is defined as:

$$ Av_{D}= \frac{1}{N_{\text{Req}V}}\sum_{i=1}^{N_{\text{Req}V}} \frac{1}{N_{\text{RSC}}} \sum_{j=1}^{N_{\text{RSC}}} \left(T_{v_{i}}^{\text{Send}}-T_{v_{i}}^{\text{Rec}v}\right) $$

where N _ReqV is the number of vehicles requesting for SP’s services and N _RSC is the number of roadside clouds. $T_{v_{i}}^{\text {Send}}$ is the time at which v _i sends a request to RSC _j and $T_{v_{i}}^{\text {Rec}v}$ is the time at which v _i receives a response from RSC _j . The average loss ratio denoted as Av _Loss is defined as follows:

$$Av_{\text{Loss}}= \frac{1}{N_{\text{Req}V}}\sum_{i=1}^{N_{\text{Req}V}} \frac{1}{N_{\text{RSC}}} \sum_{j=1}^{N_{\text{RSC}}}\left(\frac{NS_{v_{i}}^{\text{Rec}v}+NR_{RSC_{j}}^{\text{Rec}v}} {NR_{v_{i}}^{\text{Send}}+NS_{\text{RSC}_{j}}^{\text{Send}}}\right) $$

where $NS_{v_{i}}^{\text {Rec}v}$ is the number of service files received by v _i from RSC _j , and $NR_{\text {RSC}_{j}}^{\text {Rec}v}$ is the number of requests received by RSC _j . $NR_{v_{i}}^{\text {Send}}$ is the number of requests sent by v _i to RSC _j and $NS_{\text {RSC}_{j}}^{\text {Send}}$ is the number of service files sent by RSC _j to v _i .

Table 4 Simulation settings

We investigate the effect of the number of vehicles on the average delay. As described in [4], we consider 100 vehicles with a probability of launching a SP’s service request equals to 0.5 (η=0.5). The number of attributes of each access structure AT _j is set to 5 (I = 5). The average delay based on the vehicle’s density is around 0.39 for 100 vehicles for PBS [4] whereas it is 0.21 for the proposed protocol as depicted in Fig. 4. This occurs due to the time which v _i has to wait before it receives an SP’s service which depends on the verification and regeneration of E-voucher as shown in Table 3. In Fig. 5, the proposed protocol performs better when we investigate the average delay based on the speed of vehicles. For a normal speed ranging from 10 to 35 m/s, the average delay is 0.35 for the PBS [4] and 0.11 for the proposed protocol.

Fig. 4

Impact of vehicle density on average delay

Fig. 5

Impact of vehicle speed on average delay

When we study the impact of vehicle’s density on the average loss ratio, the proposed protocol performs better with 0.18 for 100 vehicles compared to PBS [4] with 0.25 for the same settings as shown in Fig. 6. We further investigate the impact of vehicle’s moving speed on the average loss ratio. As shown in Fig. 7, the loss ratio is 0.19 for vehicles moving from 10 to 30 m/s in PBS protocol [4] whereas it is 0.09 for the proposed protocol in the same conditions.

Fig. 6

Impact of vehicle density on average loss ratio

Fig. 7

Impact of vehicle speed on average loss ratio

7 Conclusions

In this paper, we proposed a secure billing protocol over attribute-based encryption in vehicular cloud computing. We used pseudonym techniques to achieve the identity privacy of the vehicles and their requested services. Certificateless signature scheme is applied to assure the authentication of legitimate vehicles which can enjoy the provided services. We adopted ABE to guarantee rigorous access control based on the purchased access structure. We used hash chain technique to provide authorization property through electronic voucher which a vehicle has to possess before enjoying any giving service. Security analysis and experimental results based on transmission overhead, average delay, and average loss ratio are provided. Compared to relevant existing work under the same scenario, the proposed protocol achieves efficient billing features with less computational overhead for vehicular cloud computing.

In the future, we will continue to investigate on revocation technique based on the updating of the access structure rather than the vehicle’s identity-based revocation.