PAACP: A portable privacy-preserving authentication and access control protocol in vehicular ad hoc networks

(1)

PAACP: A portable privacy-preserving authentication and access control protocol

in vehicular ad hoc networks

Lo-Yao Yeh

a

_{, Yen-Cheng Chen}

_b,*

_{, Jiun-Long Huang}

a

Department of Computer Science, National Chiao Tung University, Hsinchu 300, Taiwan

b

Department of Information Management, National Chi Nan University, Puli, Nantou 545, Taiwan

a r t i c l e

i n f o

Article history:

Available online 25 May 2010

Keywords: Access control Key establishment Mutual authentication Privacy

Vehicular ad hoc networks

a b s t r a c t

Recently, several studies addressed security and privacy issues in vehicular ad hoc networks (VANETs). Most of them focused on safety applications. As VANETs will be available widely, it is anticipated that Internet services could be accessed through VANETs in the near future. Thus, non-safety applications for VANETs would rise in popularity. This paper proposes a novel portable privacy-preserving authenti-cation and access control protocol, named PAACP, for non-safety appliauthenti-cations in VANETs. In addition to the essential support of authentication, key establishment, and privacy preservation, PAACP is developed to provide sophisticated differentiated service access control, which will facilitate the deployment of a variety of non-safety applications. Besides, the portability feature of PAACP can eliminate the backend communications with service providers. Therefore, better performance and scalability can be achieved in PAACP.

1. Introduction

With the rapid growth of wireless communication technology, each car with wireless communicating capability can be envisioned. A vehicle will be allowed to communicate with roadside infrastruc-ture or other vehicles. Vehicular ad hoc networks (VANETs) are emerging to improve road safety and trafﬁc management. Recently, several communities, industries and academic institutions[1–4], have embarked on investigating many aspects of VANETs. It is esti-mated that the market of VANETs will bring billions of dollars by 2012.

In VANETs, there are two components: onboard units (OBUs) and roadside units (RSUs). OBUs represent the wireless communication devices equipped in vehicles, and RSUs are wireless access devices located at critical points or intersections on the road. There are two kinds of communications: roadside-to-vehicle communications (RVCs) and inter-vehicle communications (IVCs). The birth of VA-NETs comes from improving the road safety. Therefore, safety-re-lated applications are developed over VANETs. In addition to safety-related applications, VANETs also provide non-safety appli-cations[5,6]to offer maps, advertisements, and entertainment infor-mation [7]. For example, Microsoft Corp.’s MSN TV and KVH industries Inc.[8,9], have introduced an automotive vehicle Internet access system, called TracNet, bringing Internet services to in-car vi-deo screen.

In the recent years, several researches on VANETs have been investigated by academic or industries, such as IEEE P1609.2 work-ing group[1], Car-2-Car.[2]consortium. Most studies were inter-ested in the performance of medium access control (MAC) layer or the routing issues inherent in VANETs. Recently, some works ad-dressed the security issues. As a special case of mobile ad hoc net-works (MANET), VANETs may suffer any malicious user’s behaviors, such as bogus information and replay attacks on the dis-seminated messages. Among various security threats, privacy pres-ervation in VANETs is one of the new challenges to protect users’ private information including the driver’s name, license plate, model, and traveling route. In 2005, Raya and Hubaux [10]ﬁrst proposed a solution to tackle both security and privacy issues for safety-related applications. However, their solution is not com-plete and sound[11]. In 2007, Lin et al. [12] proposed a secure and privacy-preserving protocol, called GSIS, for VANET communi-cations. GSIS adopted a group signature scheme in IVCs and ID-based cryptography (IBC) in RVCs to protect communication messages. All the above protocols were developed especially for safety-related applications. Similar to safety applications, non-safety applications in VANETs have to take both security and privacy issues into consideration [12–14]. In addition, designing a practical non-safety application for VANETs should take into con-sideration the following characteristics in VANETs[11,15,16].

1. Stringent time constraint in communication: The speed of a vehicle could be more than 140 km/h. The communication delay in IVCs or RVCs should be short enough to meet stringent time requirement[1,7,15].

* Corresponding author. Tel.: +886 49 2910960x4654; fax: +886 49 2915205. E-mail addresses:lyyeh@cs.nctu.edu.tw(L.-Y. Yeh),ycchen@ncnu.edu.tw(Y.-C. Chen),jlhuang@cs.nctu.edu.tw(J.-L. Huang).

Contents lists available atScienceDirect

Computer Communications

(2)

2. Large scale networks: In general, with an inter-vehicle distance of 70 m, there are some 70 vehicles within a radius of 1 km around a given car. During a trafﬁc jam, with an inter-vehicle instance of 5 m, there can be more than 1000 vehicles within the same region. Therefore, VANETs will be large scale networks

[15,16].

Both characteristics introduce performance and scalability is-sues in VANETs. In 2008, Zhang et al.[7,17]proposed two schemes to deal with the scalability problem in VANETs. Wang et al.[11]

proposed an enhanced communication protocol based on the infra-structure of Raya and Hubaux[10,14]to support non-safety appli-cations with conﬁdentiality and non-repudiation property. However, Wang et al.’s scheme did not address the scalability issue. Li et al.[15]also proposed a secure and efﬁcient communi-cation scheme with privacy preservation, called SECSPP, for non-safety applications in VANETs. Moreover, SECSPP discussed the security issue among service providers, roadside units and vehicles. In SECSPP, a vehicle needs to acquire a blind signature for privacy preservation before the vehicle accesses the desired services from its neighboring RSU. A service provider (SP) is responsible for signing and verifying the validity of signatures, and also involves in session key establishment between the RSUs and requesting vehicles. There are some drawbacks in SECSPP:

1. Deﬁcient in meeting stringent time requirement: When a vehi-cle tries to access a non-safety service via an RSU, the RSU must pass the signature sent from the requesting vehicle to the proper SP for veriﬁcation, whereas the SP may be located in a distant network. The speed of a vehicle may be extremely high. It is possible that the response sent from the SP has not arrived yet, but the requesting vehicle had passed the transmission range of the RSU.

2. Lack of scalability in SP: All requests of non-safety applications must be ﬁrst veriﬁed by the proper SP, which will become the bottleneck of SECSPP. The scalability issue rises in a popular SP if a large number of requests pours out.

3. Short of differentiated service access control: In SECSPP, when a vehicle sends the Access_Service_Request to an SP via an RSU, the SP only responds the accept/reject permission. However, in modern commerce model, an SP may provide several services with different access privileges for different users’ require-ments, named differentiated service access control[18]. The lack of scalability and access control in SECSPP will limit the development of non-safety applications. In this paper, we propose a Portable privacy-preserving Authentication and Access Control Protocol, named PAACP, with the support of differentiated service access control. In addition, considering stringent time requirement in transmission delay, PAACP eliminates the communications be-tween the roadside units (RSUs) and service providers (SPs). In a conventional access control scheme, SPs are usually responsible for determining the validity of the access requests. To get rid of the communication with SPs, we propose a novel portable access control method to store a portable service right list (SRL) into each vehicle, instead of keeping the SRLs in the SPs. In order to assure the validity and privacy of an SRL, we also propose a novel attach-able blind signature. Based on the attachattach-able blind signature, vehi-cles (OBUs) cannot tamper the SRL. Therefore, PAACP can prevent privilege elevation attacks[19]. As for privacy protection of users, the SP cannot trace the current location of the requesting vehicle, due to the attachable blind signature and the no need of any veri-ﬁcation by SP. In addition, PAACP is more efﬁcient than conven-tional access control schemes since RSUs can verify the correctness of an SRL without backend communications with SPs. As a result, PAACP is desirable for large scale VANETs. To the best

of our knowledge, PAACP is the ﬁrst study supporting sophisticated service access control without the scalability problem in VANETs. In summary, PAACP achieves the following properties: (1) mutual authentication between the requesting vehicle and RSU, (2) dy-namic session key establishment for the subsequent communica-tions, (3) privacy preservation of the vehicle’s information, (4) data conﬁdentiality and integrity, (5) differentiated service access control, and (6) better scalability.

The remainder of this paper is organized as follows. The related work is introduced in Section 2. The proposed PAACP scheme including system architecture and preliminary cryptography is presented in Section 3. Section 4 presents the security analysis and the correctness analysis proven by BAN logic model. The com-parison of security features and performance evaluation are given in Section5. Finally, we conclude this article in Section6. 2. Related work

2.1. Li et al.’s work

Recently, Li et al.[15]proposed a secure and efficient commu-nication scheme, named SECSPP, with authenticated key establish-ment for non-safety applications in VANETs. SECSPP is the first security scheme addressing non-safety applications with explicit authentication procedures[15]. In this section, we briefly intro-duce the procedures of SECSPP. The notations throughout Li et al.’s protocol are summarized inTable 1.

SECSPP consists of two phases: access authorization phase and access service phase. There are three participants: the vehicular node Vi, the service provider Si, and the roadside device Rj. In the

access authorization phase, Vigets an authorized credential ACi

from Si. Then, in the access service phase, Vipresents the

autho-rized credential ACi to access the desired services via Rjwithout

disclosing any sensitive information. 2.1.1. Access authorization phase

Step 1: Vi! Si:<VIDi;SIDi;TVi;C ðVIDikSIDikAC

0

ikMikTViÞ >

First, Viselects a random number a1and computes the

autho-rized credential ACi, where ACi= H(MikVIDika1). Next, Vichooses a

blind factor a2to blind ACi, and makes AC0i¼ a PK_Si

2 ACi. Finally, Vi

sends < VIDi;SIDi;TVi;C ðVIDikSIDikAC

0

ikMikTViÞ > to Si, where

C ¼ ðSID2 iÞ

HðT_ViÞVKi_{(mod N) and VK}

iis Vi’s secret key, which is based

on non-interactive ID-based public key cryptography[15]. Table 1

Notations of SECSPP.

VIDi The identity of vehicular node i

RIDj The identity of roadside device node j

Si The identity of service provider i

VKi The secret key of Vi, based on non-interactive ID-based public

key cryptography

RKj The secret key of Rj, based on non-interactive ID-based public

key cryptography

SPKi The secret key of Si, based on non-interactive ID-based public

key cryptography

ðPKSi;SKSiÞ The public key and private key of service provider Si

MAC The message authentication code MAC = H(K; m), where mdenotes message under the protection key of K. Mi The receipt of the service access sent from Sifor a user i to

register as a legal user

H() A collision-free and public one-way hash function Exclusive OR operation

Tx A timestamp, which node x attaches

ak b Concatenation of message a and b

EPK_Sifg The asymmetric encryption function with service provider’s PKSi

(3)

Step 2: Si! Vi:<C0 ðSIDikVIDikAC00ikTSiÞ >

After receiving < VIDi;SIDi;TVi;C ðVIDikSIDikAC

0

ikMikTViÞ >; Si

reveals ðVIDikSIDikAC0ikMikTViÞ by computing C ðVIDikSIDikAC

0 i

kMikTViÞ C

0 _{and veriﬁes the validity of M}

i, where C0¼

ðVID2iÞ HðT_{V i}ÞSPK_Si

(mod N),1 _{and SPK}

Si is the secret key of Si. If is Mi

valid, then Sirecords (VIDi;Mi;TVi) in its database and marks Mias

non-fresh. In addition, Sisigns AC0iwith its private key SKSiby

com-puting AC00i ¼ AC 0SK_Si

i ¼ a2 AC SK_Si

i . Finally, Si delivers < C0 SIDð ik

VIDikAC00ikTSiÞ > to Vi.

Once getting C0

SIDikVIDikAC00ikTSi

;Vi extracts ðSIDikVIDik

AC00 ikTSiÞ by calculating C 0_SID ikVIDikAC00ikTSi C. Then, AC00 i is

unblinded by computing AC00i ða2Þ1 and then Vi obtains ACi ¼

ACSKSi

i . Moreover, AC

i is conﬁrmed by checking whether ACi¼

ðAC iÞ

PK_Si

. If yes, Vibelieves ACi is the signature of ACi; otherwise,

Vidrops it and stops this session.

2.1.2. Access service phase

Step 1: Vi! Rj:<Access Ser

v

ice Request; EPK_SifAccess Ser

v

ice

Request; RIDj;ACi;ACi;TVi;a3g >

When a legal Viwants to access the pay-service from the

road-side unit Rj, Vi computes EPK_Si {Access_Service_Request, RIDj, ACi,

AC

i;TVi, a3}, where a3is a random number generated by Vi. Then,

Visends it with an Access_Service_Request request to Rj.

Step 2: Rj?Si: <RIDj, TRj, C (EPK_Si {Access_Service_Request, RIDj,

ACi, ACi;TVi, a3})>

Once receiving the Access_Service_Request request sent from Vi,

Rj computes C (EPK_Si{Access_Service_Request, RIDj, ACi, ACi;TVi,

a3}), where C ¼ ðSID2iÞ HðT_RjÞRKj

, and delivers (RIDj, TRj, C (EPKSi

{Access_Service_Request, RIDj, ACi, ACi;TVi, a3})) to its back-end

ser-vice provider Si.

Step 3: Si?Rj: <SID, C

0

(Access_Permission, a3, b1, ACi, Tsi)>

After receiving the message from Rj, Si ﬁrst extracts

EPK_Si{Access_Service_Request, RIDj, ACi, ACi, TVi, a3} by computing

C (EPK_Si {Access_Service_Request, RIDj, ACi, ACi;TVi, a3}) C

0_{, where}

C0_{¼ ðRID}2 jÞ

HðT_RjÞSPK_Si

(mod N), and computes DSK_SifEPK_SifAccess

Ser

v

ice Request; RIDj;ACi;ACi;TVi;a3gg. Next, Si will conﬁrm the

validity of the authorized credential AC

i by checking whether

ACi¼ ðACiÞ PK_Si

holds or not. If yes, Viis granted the access privilege

from Rjand then Sigenerates a random number b1and computes

the temporary service key TSKi= H(a3kb1kACik0); otherwise, this

access request is denied. Last, Sisends < SIDi, C

0

(Access_Permis-sion, a3, b1, ACi, Tsi)> to Rj.

Step 4: Rj?Vi:<b1, TSKi(RIDj, b2, TRj)>

Upon receiving the message from Si, Rjacquires

(Access_Permis-sion, a3, b1, ACi, Tsi) by computing C 0

(Access_Permission, a3, b1, ACi,

Tsi)C. Based on a3, b1, ACi, Rjcan compute TSKi= H(a3kb1kACik0)

for the subsequent data encryption for accessing pay-services be-tween Viand Rj. Next, Rjgenerates a random number b2for mutual

authentication and sends the message < b1, TSKi(RIDj, b2, TRj)> to Vi.

Step 5: Vi?Rj: <MAC>

After receiving the message from Rj, Vicalculates temporary

ser-vice key TSKi= H(a3kb1kACik0) by the received b1, his own a3and

ACi, and then reveals (RIDj, b2, TRj) by TSKi. Next, Visends back

MAC ¼ HðTSK00

i, b2+ 1), where TSK00i ¼ Hða3kb1kACik1Þ, for mutual

authentication.

Finally, Rjveriﬁes Viby checking whether MAC is correct or not.

If yes, Viis convinced; otherwise, this session is dropped. In the

end, both Rjand Vitake TSKi= H(a3kb1kACikk) for data encryption

of the kth session in the access service phase, where k = 2, 3, 4, . . . , and so on.

2.2. Comments on SECSPP

SECSPP gives a security solution for non-safety applications in VANETs. Both security and privacy issues were considered in the protocol design. However, the scalability issue is not addressed in SECSPP. As mentioned above, VANETs should be regarded as large scale networks. In SECSPP, only a single SP takes charge of checking the validity of authorized credential ACi. This may lead

to a bottleneck problem, or may introduce the threat of potential Distributed/Denial-of Service (D/DoS) attacks. In addition, SECSPP does not support differentiated service access control, which al-lows a variety of non-safety services with different privileges. It is believed that if non-safety applications try to achieve the success in VANETs, a sophisticated access control scheme[18]is required to meet a variety of users’ demands.

In SECSPP, each SPineeds two secret keys, SPKSi and SKSi. The

former is used for non-interactive ID-based public key, and the lat-ter is used for signing and decrypting the messages sent from vehi-cles or RSUs. This may cause inconvenience for SPs. In terms of security, SECSPP adopted a conventional blind signature to prevent the vehicle’s privacy from tracing by SPs. However, the conven-tional blind signature is not designed for access control. If SECSPP is adopted to provide the differentiated service access control, SECSPP could not withstand privilege elevation attacks[19], since SECSPP cannot examine whether the access privileges are valid or not. To deal with this weakness, we will ﬁrst devise a novel attachable blind signature, and then develop a portable access con-trol scheme based on the attachable blind signature. In addition, performance and scalability issues will be carefully examined in the design of our protocol.

3. The Portable privacy-preserving Authentication and Access Control Protocol (PAACP)

3.1. System architecture

A system architecture of non-safety applications in VANETs is given inFig. 1. In general, a non-safety application of VANETs is composed of three types of entities, (1) onboard units (OBUs), (2) roadside units (RSUs), and (3) service providers (SPs). The SPs are responsible for providing various non-safety services with the dif-ferentiated access privileges. For example, a travel company serves as the service provider to provide a travel guide service with two classes of customers, VIP and non-VIP customers. While a VIP cus-tomer uses the travel guide service, the travel company automati-cally pushes a bunch of coupons of local hotels or restaurants, which are only available for a VIP-exclusive service. In practice, an SP may deploy devices or databases in networks near RSUs for offering various non-safety services in a distributed fashion. Thus, the access of non-safety services can be fulﬁlled locally.

Initially, each OBU must send a Register_Service_Request mes-sage to the SP to request the authorization of the desired services in the access authorization phase. In the access service phase, when an OBU wants to access some services, the OBU delivers the Access_Service_Request message to its neighboring RSU. If the requesting OBU is authorized, then the neighboring RSU sends

1

Based on non-interactive ID-based public key cryptography, C ¼ ðSID2 iÞHðTViÞVKi¼

ðVID2

(4)

back the Access_Service_Accept message and allows the requesting OBU to access the desired services; otherwise, the OBU receives the Access_Service_Reject message without any access permission. 3.2. The proposed attachable blind signature

Generally, blind signatures could be implemented by different cryptosystems, such as RSA and ElGamal. We adopt RSA-based blind signature in the proposed blind signature scheme. First, we brieﬂy introduce the conventional RSA-based blind signature. A user UAblinds a message m with a random blind factor r and

com-putes the blind document BD ¼ re_m;

where e is the public key of the signer. The blind document is then sent to the signer. Once receiving BD, the signer signs BD by his/her private key d as

BD0

¼ BDd¼ rmd:

Then the signer sends BD0_{back to U}

A. Upon receiving BD0, UA

un-blinds BD0_{by the blind factor r to obtain the signer’s signature}

BD00_{¼ m}d_{¼ BD}0_=r:

Finally, UAconﬁrms the integrity of BD00by checking

ðBD00Þe¼ m:

In a conventional blind signature, the signer does nothing but signs the blind document BD sent from the user. Such a conven-tional blind signature is not designed for access control in origin. In terms of access control, the service provider (SP) plays the role of the signer and also conﬁrms whether the requested access priv-ileges for a user are legal. Since the blind document containing the requested access privileges is blinded by a random number r, it is infeasible for the SP to check whether the requested access privileges are legal. To ensure the genuineness of the requested access privileges, we propose an attachable blind signature as follows.

First, a user UA chooses random blind factors r1, r2and a, and

then computes BD1¼ ðr1ÞemaðmodNÞ: BD2¼ ðr2Þ

e

mð1aÞ_ðmodNÞ:

Then, UAsends BD1and BD2to the signer. Once receiving BD1

and BD2, the signer ﬁrst attaches a message m0into BD2as

BD#

2 ¼ ðr2Þemð1aÞm0ðmodNÞ

and signs BD1;BD#2 by his/her own private key d as

BD0 1¼ ðBD1Þd¼ r1ðmaÞdðmodNÞ; BD02¼ ðBD # 2Þ d ¼ r2ðmð1aÞm0ÞdðmodNÞ:

Then, the signer sends BD0 1;BD

0

2back to UA. Upon receiving BD01

and BD0

2, UAﬁrst unblinds two messages as

BDU 1¼ BD 0 1=r1¼ ðmaÞ d ðmodNÞ; BDU 2¼ BD 0

2=r2¼ ðmð1aÞm0Þd¼ ðmð1aÞdÞðm0dÞðmodNÞ

and generates the signer’s signature by BD00

¼ BDU1 BD U

2¼ md m0dðmodNÞ:

Note that the proposed attachable blind signature scheme at-taches a message m0_{into the signature and still keeps the privacy}

of user’s message m. To withstand the privileges elevation attack, PAACP takes the advantage of m0_{to ensure the validity of m.}

3.3. Portable privacy-preserving Authentication and Access Control Protocol (PAACP)

In this section, we propose a novel Portable privacy-preserving Authentication and Access Control Protocol (PAACP) for non-safety applications in VANETs. Since the stringent time requirement is re-garded as an important property of VANETs[7,11,17], PAACP gets rid of the backend communication between roadside units and ser-vice providers. In PAACP, SPs do not involve in the access serser-vice phase. That is, the veriﬁcation of vehicles and their access privi-leges can be accomplished in RSUs themselves. Thus, it is not re-quired to take a long round trip of communication between RSUs and SPs for access request veriﬁcations. In the access authorization phase of PAACP, the SP authorizes the access privileges for a legit-imate vehicle, and stores a service right list in a portable autho-rized credential carried by the vehicle. The portable authoautho-rized credential is protected using the proposed attachable blind signa-ture to withstand privilege elevation attacks.

Another merit of PAACP is the support of differentiated access privileges for each service. A service may provide different access Fig. 1. System architecture of a non-safety application.

(5)

privileges to satisfy distinct requirements of the users. For this, the access privileges for the service i are represented by a bit string ARi

of kibits. Each bit of ARirepresents a distinct access privilege of the

service i. In a travel guide service, for instance, we may use one bit to indicate the permission of viewing detailed maps, and one bit to indicate the permission of downloading coupons, and another bit to denote the capability of watching a particular video program. Therefore, kidistinct access privileges can be speciﬁed in ARi.

As-sume an SP provides n services with access privileges ARi, 1 6 i 6 n.

Suppose a vehicle V is granted to access m services, 1 6 m 6 n, with index {SVID1, SVID2, . . . , SVIDm}. Let AR0j, 1 6 j 6 m, be the granted

value of ARjfor V. Then, the service right list SRL for V can be

rep-resented by a bit string

SRL ¼ ðSVID1kAR01ÞkðSVID2kAR02Þk kðSVIDmkAR0mÞ

with lengthPmi¼1ðlogn þ kiÞ. For example, we assume an SP provides

16 services and the travel guide is the 12th service with three dif-ferent access privileges: viewing maps, downloading coupons, watching videos, then n = 16 and k12= 3 for AR12. If Viapplies for

the travel guide service with the access privileges of viewing maps and downloading coupons, then V will set SRL = (1100k110)[19].

The proposed scheme consists of two phases: access authoriza-tion phase and access service phase, as illustrated inFigs. 2 and 3. The notations of PAACP are summarized inTable 2.

According to the purchased services and granted access privi-leges, in the access authorization phase, a vehicle Vicreates a

ser-vice right list SRLVi

i in AC Vi

i and blinds AC Vi

i into blind documents

BD1i, BD2i. To obtain the corresponding portable authorized

cre-dential for later use, Visends the blind documents with its

certiﬁ-cate Certito the service provider St. After checking the validity of

Certi, Stgenerates the service right list SRLSitbased on the sold

con-tract, stores SRLSt

i in AC St

i and attaches AC St

i into blind documents

BD1i, BD2ibased on the proposed attachable blind signature. Then,

Stdelivers the blind documents back to Vi. At the end of the access

authorization phase, Viwill obtain the portable authorized

creden-tial AC i , where AC i consists of both AC Vi i and AC St i . AC i is stored in

Vi’s tamper-proof device[10,11,17]. In the access service phase, Vi

sends an Access_Service_Request to its neighboring RSU Rj, and then

Rjveriﬁes the authorized credential ACi by itself without further

communication with St. According to the access privileges stored

in the authorized credential ACSt

i , Rjcould decide whether Vi’s

re-quest is accepted or not. Furthermore, Rjcould detect whether Vi

is launching a privilege elevation attack.

We explain the details of each phase as follows. 3.4. Access authorization phase

Step 1: Vi?St: <VIDi,

r

i, BD1i, BD2i>

In the access authorization phase, according to the purchase re-ceipt from the service provider St, a vehicle Vicreates its service

right list SRLVi

i ¼ fSVID1kAR1k :kSVIDkkARkg, whereSVIDkdenotes

the index of the kth service, and ARkrepresents the granted access

privileges of SVIDk. The service right list will be signed byStas part

of an authorized credential. First, Vichooses random numbers RN1,

RN2and a, and then sets ACVii¼ fSIDtkTexpiredkSRLViig. These random

numbers are used as blind factors. Then, Vi computes blind

documents BD1i¼ ðRN1ÞPKSt ðACViiÞ a ðmodNÞ; BD2i¼ ðRN2ÞPKSt ðACViiÞ 1a_ðmodNÞ:

Finally, Visends its identity VIDi, signature

r

i¼ fBD1i;BD2igSKVi,

and the blinded documents BD1i, BD2ito St.

Step 2: St?Vi:<BD10i;BD2 0 i>

Upon receiving message < VIDi,

r

i, BD1i, BD2i> sent from Vi, St

ﬁrst conﬁrms whether the

r

iis valid by Vi’s public key. If valid, Viis

successfully authenticated; otherwise, this session is dropped. St

then generates the authorized credential ACSt

i ¼ fSIDtk Texpiredk

SRLSt

i g according to the selling contract for Viand attaches it into

BD2# i as

(6)

BD2# i ¼ BD2i ACSit¼ RN PK_St 2 ðAC Vi i Þ 1a_ACSt i ðmodNÞ: Then, Stsigns them as follows:

BD10 i¼ BD1 SK_St i ¼ ðRN1Þ PK_St ACVi i a SK_St ¼ ðRN1Þ ðACV_iiÞaSKSt; BD20 i¼ BD2 # i SK_St ¼ ðRN2Þ PK_St ACVi i 1a ACSt i SK_St ¼ ðRN2Þ ACVii 1a ACSt i SK_St : Next, BD10i;BD2 0

iare sent back to Vi. After obtaining < BD10i;BD2 0 i>

from St, Viunblinds them as follows:

BD1U i ¼ BD1 0 i=RN1¼ ðAC Vi i Þ aSKSt_{; ;} BD2Ui ¼ BD2 0 i=RN2¼ ðACViiÞ 1a_ACSt i SK_St :

In order to get the portable authorized credential AC i ¼ fACVi i AC St ig SK_St , Vicomputes BD1Ui BD2 U i ¼ AC Vi i aSKSt ACVi i 1a ACSt i SK_St ¼ ACVi i AC St i SK_St : To conﬁrm the AC

iis certiﬁed, Vicould verify the correctness of ACi

by checking whether fAC ig PK_St _{is equal to AC}Vi i AC St i. 2_{If it holds, V} i keeps AC

i for the subsequent service requests; otherwise, Viwill stop

this session. Note that, we assume Vicould protect ACi in secret by

tamper-proof device after obtaining AC i.

3.5. Access service phase

Step 1: Vi! Rj:<Access Ser

v

ice Request; fSVID; YV;ACig PK_Rj

> In the access service phase, when a vehicle Viwants to access

the desired services from its neighboring roadside unit Rj, Viwill

transmit an Access_Service_Request with fSVID; YV;ACig PK_Rj

, where SVID is the identiﬁcation of the desired services, and YV= gxmod q,

where x is a random number in Z q, to Rj.

Step 2: Rj?Vi:<YR, ETSK0{YV+1, Access_Permission}>

Upon receiving fSVID; YV;ACig PK_Rj

, Rjdecrypts it by his own

pri-vate key SKRjto acquire (SVID, YV, AC

i). First, Rjcalculates ACSt i ¼ AC i PK_St 1=2 Fig. 3. Access service phase of the proposed scheme.

Table 2

Notations of the proposed scheme. Vi The ith vehicle

VIDi The identiﬁcation of the ith vehicle

Rj the jth roadside unit

RIDj The identiﬁcation of the jth roadside unit

St the tth service provider

SIDt The identiﬁcation of the tth service provider

SVIDi The identiﬁcation of the ith service

ARi The access privilege of SVIDi

ðPKVi;SKViÞ A public key and private key of vehicle Vi

ðPKRj;SKRjÞ A public key and private key of roadside unit Rj

ðPKSt;SKStÞ A public key and private key of service provider St

Certi The certiﬁcate of vehicle Vi

TSK A temporary session key between the vehicle and roadside unit a,RNj Random numbers, where j = 1, 2.

ACi Authorized credential for vehicle Vi

ACSt_;ACVi Authorized credential made by Stand Vi, respectively

AC

i Portable authorized credential for vehicle Vi

SRL The service right list

SRLSt_;SRLVi Service right list made by St, and Vi, respectively

BD1,BD2 The blind documents used in the proposed attachable blind signature

EKABfg The encryption function with shared key KAB

DKABfg The decryption function with shared key KAB

MAC The message authentication code

h( ) A collision-free and public one-way hash function ri A signature signed by secret key SKVi

q A large prime number

g A generator of a ﬁnite cyclic group with order q.

2

Note that if both Viand Stare legal, ACV_ii and ACS_itshould be the same, which

(7)

to extract the access credential ACSt

i, which is authorized by St. Then,

Rjexamines whether SIDtas well as SVID is included in ACSit, and

checks the validity of the authorized credential by Texpired. If the

ver-iﬁcation succeeds, AC

i is legitimate and Viis authorized; otherwise,

Rjterminates this session. After ACi is veriﬁed, Rjcalculates

YR¼ gymod q;

where y is a random number in Z

q, and generates a temporary

ses-sion key

TSK0¼ hðACi;ðYVÞ y

mod q; 0Þ

for protecting the subsequent communications. Finally, Rj

deliv-ers < YR, ETSK0 {Y_V+1, Access_Permission}> to V_i.

Step 3: Vi?Rj: <ETSK1{Auth_Ack}, MAC>

After receiving < YR, ETSK0{YV+1, Access_Permission}>, Vicomputes

a temporary session key TSK0

¼ hðACi;ðYRÞxmod q; 0Þ

and decrypts E_TSK0{YV+1, Access_Permission} using TSK0to check the

validity of YV+ 1. If valid, Rjis successfully authenticated; otherwise,

Viceases this connection. Then, Vigenerates an Auth_Ack encrypted

by

TSK1¼ hðACi;ðYRÞxmod q; 1Þ

and computes the message authentication code MAC ¼ ðTSK0;ETSK1AuthAckÞ:

Finally, Visends <ETSK1{Auth_Ack}, MAC> to Rj.

Upon receiving the message, Rjveriﬁes the MAC to ensure the

integrity, and calculates TSK1

¼ hðACi;ðYVÞymod q; 1Þ

to decrypt E_TSK1{Auth_Ack}. If Rjcould recognize Auth_Ack, it is

im-plied that Viindeed holds the corresponding TSK1. Finally, the

sub-sequent communications can be encrypted by the session key TSKk, where

TSKk¼ hðACi;ðYVÞy mod q; kÞ:

4. Security and correctness analysis 4.1. Security properties

Based on the security of asymmetric and symmetric cryptosys-tems, PAACP preserves several security properties, as discussed below.

4.1.1. Mutual authentication

In PAACP, vehicle Viand roadside unit Rjare mutually

authenti-cated based on the secret authorized credential ACi and the public

key cryptosystem. Only an authorized Vicould own ACi, and only

legitimate Rjhas the capability of decrypting messages to extract

YV. Mutual authentication is an essential property to prevent

mali-cious attacks from outsiders. This property will be formally proven by BAN logic proof in Section4.2.

4.1.2. Context privacy

Based on the proposed attachable blind signature, no one could comprehend the access privileges in ACVi

i . Note that even if service

provider Stcould realize Vi’s access privileges in the access

autho-rization phase, the non-linkability discussed in next subsection is also guaranteed. In the access service phase, all messages are well

protected by asymmetric and symmetric cryptographic primitives without disclosing any information to outsiders. On the other hand, although the roadside unit Rjcan conﬁrm the validity of

the authorized credential AC

i and the desired services SVID, Rj

can-not realize who is accessing those services. 4.1.3. Non-linkability

In general, the non-linkability means both insiders and outsid-ers could neither realize any session to a particular user nor link any two different sessions to the same user. First, PAACP ensures that outsiders cannot attain any information in the communica-tions between Viand Rj. Therefore, the non-linkability for outsiders

is guaranteed under the security of asymmetric and symmetric cryptosystems. On the other hand, service provider Stcannot link

any sessions to a particular user since Stis not involved in the

ac-cess service phase. Moreover, even if Stobtains the authorized

cre-dential AC

i, the non-linkability is still ensured by the proposed

attachable blind signature since Stcannot link this ACi to the exact

vehicle, unless the service right list itself is distinct for a certain vehicle. It is possible that Rjcould link the authorized credential

AC

i to the same vehicle, but Rjcannot derive any additional

infor-mation about the vehicle. 4.1.4. Data trafﬁc protection

After the execution of PAACP, all messages between Viand Rjare

encrypted by the session key TSK. Under the security of symmetric cryptographic primitive such as AES, the data conﬁdentiality and integrity are guaranteed as well.

4.1.5. Differentiated service access control

Different from the previous work[18]adopting several public/ private key pairs to achieve the differentiated service access con-trol, PAACP only requires a single public/private key pair and uses an SRL[19]to encode the access privileges of each services. As a re-sult, PAACP also keeps the privacy of the service request in the ac-cess service phase.

4.1.6. Forward secrecy

Different from the previous works[15,18], PAACP applies the concept of Difﬁe-Hellman exchange protocol using YV= gxmod q

and YR= gymod q to establish the session key TSKi¼ hðACi;gxy¼

ðYVÞy¼ ðYRÞx;iÞ. This implies that PAACP preserves the forward

se-crecy property even though a long-term secret key is compromised.

4.2. Correctness veriﬁcation

We formally verify the correctness of PAACP based on well-known model BAN logic[20]. BAN logic is a famous logic model widely used to reason about beliefs, encryptions and protocols. Protocol correctness means both communication parties ascertain that they have shared a fresh session key and ensure that the same belief is held by the other party. Recently, several authentication schemes [18,21]have applied BAN logic to prove the validity of an authentication and key distribution protocol.

InTable 3, we briefly introduce some notations used in BAN logic. Following the beginning procedures of BAN logic, we first list the verification goals inTable 4. To reduce the expression complex-ity, we provide a generic type and then transform it to an idealized protocol, as shown in Table 5. We highlight the messages ex-changed between vehicle V and roadside unit R, and verify whether the two communicating parties could ascertain that they have shared a fresh session key TSK with each other.

According to BAN logic, some assumptions are made inTable 6. The ﬁrst two assumptions mean both V and R believe that R holds a public key Kb. Assumptions (A.3) and (A.4) tell that V and R,

(8)

respec-tively, generates YVand YRregarded as two fresh nonces, which are

to ensure the freshness property. Assumptions (A.5) to (A.8) are re-lated to the authorized credential AC* shared between R and V. In short, R believes that AC* is the secret shared between an autho-rized vehicle and itself since R can easily verify the validity of AC* based on the proposed attachable blind signature. Note that, although R cannot actually realize the exact identiﬁcation of V, R still believes that AC* is an authentic secret shared between them. This is the reason why we adopt blind signatures. In assumption (A.9), V believes that R has jurisdiction right over TSK, since R will generate YRand send it to V together with V’s challenge YV. In the

view of V, the TSK is determined by the YR. The assumption

(A.10) holds since R invents the fresh session key TSK with a shared secret AC*between V and R, and one fresh nonce, Y_R, is chosen by

itself. The details of veriﬁcation procedures are outlined inTable 7. PAACP achieves the veriﬁcation goals by equations (S.5), (S,6), (S.10) and (A.10). That is, the correctness of PAACP is guaranteed based on BAN logic.

5. Discussion 5.1. Comparsion

In this section, we compare PAACP with the related works

[15,11]in terms of security properties and performance evaluation. First, we compare the security features of PAACP with SECSPP and Wang et al.[11], which are typical authentication schemes for non-safety applications in VANETs. Table 8 lists important security properties in VANETs. The comparison shows that PAACP provides more merits, including differentiated service access control, privi-lege elevation attack resistance, and better scalability.

Table 3

Notations used in BAN logic.

Pj X Principal P believes X or P would be entitled to believe X. In other words, P may act as though X is true. The construct is central to the logic. P / X P sees formula X Some has sent a message containing X to P.

Pj X P once said X. P at some time sent a message including X.

P ) X P has jurisdiction over X. P is an authority on X and should be trusted on the matter. <X>Y Formula X combined with a secret parameter Y.

{X}Y Formula X encrypted by key Y.

P $KQ Principals P and Q may use the shared key K to communicate. Here K will never be discovered by any principals expect for P and Q. #KbR R has Kbas public key.

P AC

Q The formula AC*is a secret known only to P and Q, and possibly to principals trusted by them. #(X) The formula X is fresh. X has not been sent in a message at any time before.

TSK A temporary session key negotiated in each session.

Table 4

Goals of correctness veriﬁcation. Veriﬁcation goals:

G1:V j V $TSKR G2:V j Rj V $TSKR G3:Rj V $TSKR G4:Rj Vj V $TSKR

Table 5

Generic and idealized type of the access service phase. Protocol generic type

Message 1 V ! R : fSVID; YV;ACgPKR

Message 2 R ? V:YR,ETSK{YV+ 1, Access_Permission}

Message 3 V ? R:ETSK{YV+ 1,Auth_Ack},MAC

Idealized protocol type

Message 1 _{V ! R : fY} V;V $ TSK RgKR Message 2 R ! V : YR;ETSKfYV;V AC R; V $TSKRg Message 3 _{V ! R : E} TSKfV $ TSK Rg Session key TSK = h(AC*, (YV)y= (YR)x= gxy)

Table 6

The assumptions based on BAN logic. Assumptions

(A.l) Vj #Kb

R (A.2) Rj #Kb

R (A.3) Vj #(YV) (A.4) Vj #(YR)

(A.5) Vj V AC R (A.6) Rj V AC R (A.7) Vj Rj V AC R (A.8) Rj Vj V AC R (A.9) Vj Rj ) V $TSKR (A.10) Rj V $TSKR Table 7

Veriﬁcation procedures of access service phase. Veriﬁcation Message 1 V ! R : fYV;V ! TSK RgKR (S.1) R / ðYV;V AC RÞ By seeing rule Message 2 R ! V : YR;ETSKfYV;V AC R; V $TSKRg (S.2) V / ðYR;YV;V AC R; V $TSKRÞ By seeing rule (S.3) Vj Rj ðYR;YV;V AC

R; V $TSKRÞ By (A.5), (S.2), msg-meaning rule (S.4) Vj Rj ðYR;YV;V

AC

R; V $TSKRÞ By (A.3), (S.3), nonce-veriﬁcation, freshness rule

(S.5) Vj Rj V $TSKR By (S.4), belief rule

(S.6) Vj V $TSKR By (S.5), (A.9), jurisdication rule Message 3 V ! R : ETSKfV $TSKRg

(S.7) R / fV $TSKRg By seeing rule (S.8) Rj #ðV $TSKRÞ By (A.4), (A.9)

(S.9) Rj Vj V $TSKR By (S.7), (A. 10), msg-meaning rule (S.10) Rj Vj V $TSKR By (S.8), (S.9), nonce-veriﬁcation

rule

Table 8

The comparison of security features.

Ours SECSPP[15] Wang et al.[11]

Mutual authentication Yes Yes Yes

Context privacy Yes Yes Yes

Session key agreement Yes Partially yesa

Partially yesb Differentiated service access control Yes No No Privilege elevation attack resistance

Yes N/A N/A

Scalability Fully distributed Bottleneck at service provider N/A

Formal correctness proof Yes No No

a

In SECSPP, the session key TSK is determined by V and S, not V and R.

b_{In Wang et al.’s scheme, the session key TSK is built for inter-vehicle}

(9)

5.2. Performance evaluation

Next, we evaluate the performance of SECSPP and PAACP in

Table 9. For time complexity estimation, we deﬁne some computa-tional parameters as follows:

TAsym: the time for the asymmetric encryptions/decryptions.

Tsym: the time for the symmetric encryptions/decryptions.

TIDexp: the time for the modular exponentiation of the ID-based

cryptography.

Thash: the time for the one-way hash function operation.

Txor: the time for the XOR operation.

Based on the computation method in Li et al.[15]and Wang et al.[11], PAACP takes 2.0885 s to compute the necessary opera-tions and SECSPP spends 2.0895 s in the authorization phase. In the access service phase, the veriﬁcation time Tveriﬁcationof PAACP

is 1.5839 s/time and that of SECSPP is 2.613 s/time. Note that the time spent in the access service phase is the major concern in terms of performance, since the access service phase will be exe-cuted frequently, whereas the authorization phase is exeexe-cuted only once. In addition to the required computation time in the access service phase, the overall elapsed time can be evaluated by the communication rounds needed and the waiting time for each vehi-cle when there are a number of service requests simultaneously. In general, the service provider is far away from RSUs, but vehicles are in the neighborhood of RSUs. Let Ttransdelaybe the transmission

delay in seconds to deliver a message from a vehicle, forwarded by an RSU, to the SP. It is reasonable to assume 1 < Ttransdelay< 2. The

transmission delay in seconds to deliver a message from a vehicle to its neighboring RSU is less than 0.01 s [4], which can be ne-glected. Considering the scalability issue, we further assume that n vehicles in the VANET request the services of the same SP at the same time and the locations where these service requests are invoked are uniformly distributed within m RSUs[22]. In SECSPP, the average waiting time Twaitingfor a requesting vehicle can be

estimated as

TwaitingSECSPP¼ 2Ttransdelayþ ðn þ 1Þ=2 Tverification;

The waiting time consists of round-trip transmission delay and the time spent in the SP for verification. Since there are n requests pending for verification, the average time spent in SP will be (n + 1)/2 * Tverification. On the other hand, in PAACP, the average

waiting time Twaitingfor a requesting vehicle can be estimated as

TwaitingPAACP¼

ðn=m þ 1Þ=2 Tverification; if n > m Tverification; otherwise:

In a uniform distribution of locations, the avergae number of re-quests pending in each RSU will be n/m. Therefore, the average time spent for request veriﬁcation in a RSU is (n/m + 1)/2 * Tveriﬁcation.Fig. 4

Table 9

The comparison of efﬁciency.

Ours SECSPP[15]

Authorization phase

4TAsym+ 1Thash 2TAsymþ 2TIDexp þ 3Thashþ 4Txor

Access service phase

3TAsym+ 2Tsym+ 1Thash 3TAsym+ 2TIDexp+ 6Thash+ 5Txor

Computation time (s) Authorization phase 2.0885 (s) Authorization phase 2.0895 (s) Access service phase 1.5839 (s)

Access service phase 2.613 (s)

Communication rounds

2 + 3 2 + 5

(10)

shows the average waiting time for a service request as n increases with different values of m (10, 30, and 50). AsFig. 5a–c shows, when 100 vehicles are requesting the desired services, the average waiting time to finish the authentication in SECSPP is 134 seconds. As for PAACP, the waiting times for m = 10, 30, and 50 take about 10, 5, and 3 s, respectively. The waiting time for PAACP is short since the verifications of access requests can be performed locally because of the distributed nature of PAACP. Moreover, the more RSUs are in-stalled, the less waiting time in PAACP is required. In terms of com-munication rounds, PAACP eliminates the transmission overhead between RSUs and SPs. Hence, the total number of communication rounds required in PAACP is lower than that of SECSPP, as shown inFig. 5. Obviously, the number of communication rounds of PAACP is 60% fewer thant that of SECSPP. In summary, PAACP outperforms SECSPP significantly.

5.3. Implementation issue

In terms of implementation issue, the proposed scheme can be developed by the existing IEEE 1363 standard IEEE1363-2000-Std.

[23]for public key cryptography and NIST standards NIST-standard

[24]for AES cryptosystem, respectively. Only the proposed attach-able blind signature is required to be speciﬁcally implemented, and the details of attachable blind signature is introduced in Section

3.2. Moreover, the system parameters of the attachable blind sig-nature can be found in IEEE 1363 standard IEEE1363-2000-Std.

[23].

6. Conclusion

In the near future, it is anticipated that various services would be available in VANETs to bring more convenient services to driv-ers and passengdriv-ers. Therefore, access control will be an essential security issue in VANETs. In this paper, we have proposed a Porta-ble privacy-preserving Authentication and Access Control Protocol

(PAACP) for non-safety applications in VANETs. Considering the stringent time requirement in VANETs, we devised a portable ac-cess control protocol to get rid of the involvement of service pro-viders in the access service phase. Due to the portability of authorized service right lists, roadside units can verify the validity of access privileges without the aid of service providers. Moreover, we proposed an attachable blind signature to keep the privacy of the requested services and to withstand the privilege elevation at-tack. The performance evaluations also show that PAACP is efﬁ-cient and suitable for large scale VANETs.

References

[1] IEEE1609.2-Std., Ieee trial-use standard for wireless access in vehicular environments-security services for applications and management messages, 2006.

[2] Car-2-Car., [online]. available:<http://www.car-2-car.org>, 2007.

[3] European project react, [online]. available:<http://www.react-project.org>, 2006.

[4] DSRC., Dedicated short range communications, 2006. [Online]. Available: URL

<http://www.leearmstrong.com/dsrc/dsrchomeset.htm>.

[5] S. Youseﬁ, M. Mousavi, M. Fathy, Vehicular ad hoc networks (vanets): challenge and persepectives, in: International Conference on ITS Telecommunications, 2006.

[6] J.T. Isaac, J.S. Camara, S. Zeadally, J.T. Marquez, A secure vehicle-to-roadside communication payment protocol in vehicular ad hoc networks, Comput. Commun. 31 (2008) 2478–2484.

[7] C. Zhang, X. Lin, R. Lu, P.H. Ho, X. Shen, An efﬁcient message authentication scheme for vehicular communications, IEEE Trans. Vehicular Technol. 57 (6) (2008) 3357–3368.

[8] Kvh industries inc. [online]. available:<http://www.kvh.com/>, 2006. [9] Msntv. [online]. available:<http://www.msntv.com/>, 2006.

[10] M. Raya, J.-P. Hubaux, The security of vehicular ad hoc networks, in: SASN, 2005.

[11] N.-W. Wang, Y.-M. Huwang, W.-M. Chen, A novel sercure communication scheme in vehicular ad hoc networks, Comput. Commun. 31 (2008) 2827– 2837.

[12] X. Lin, X. Sun, P.-H. Ho, X. Shen, Gsis: a secure and privacy-preserving protocol for vehicular communications, IEEE Trans. Vehicular Technol. 56 (2007) 3442– 3456.

[13] X. Lin, R. Lu, C. Zhang, H. Zhu, P.-H. Ho, X. Shen, Security in vehicular ad hoc networks, IEEE Commun. Mag. 46 (4) (2008) 88–95.

[14] M. Raya, J.-P. Hubaux, Securing vehicular ad hoc networks, J. Comput. Security 15 (2007) 39–68.

[15] C.-T. Li, M.-S. Hwang, Y.-P. Chu, A secure and efﬁcient communication scheme with authenticated key establishment and privacy preserving for vehicular ad hoc networks, Comput. Commun. 31 (2008) 2803–2814.

[16] Y. Toor, P. Muhlethaler, A. Laouiti, Vehicle ad hoc networks: applications and related technical issues, IEEE Commun. Surveys Tutorials 10 (2008) 74–87. [17] C. Zhang, R. Lu, X. Lin, P.-H. Ho, X.S. Shen, An efﬁcient identity-based batch

veriﬁcation scheme for vehicular sensor networks, in: The 27th Conference on Computer Communications. IEEE INFOCOM, 2008.

[18] K. Ren, W. Lout, K. Kim, R. Deng, A novel privacy preserving authentication and access control scheme for pervasive computing environments, IEEE Trans. Vehicular Technol. 55 (4) (2006) 1373–1384.

[19] Y.-C. Chen, L.-Y. Yeh, An efﬁcient authentication and access control scheme using smart cards, in: Proceedings of International Conference on Parallel and Distributed Systems (ICPADS), 2005.

[20] M. Burrows, M. Abadi, R. Needham, A logic of authentication, ACM Trans. Comput. Syst. 8 (1) (1990) 18–36.

[21] C.-C. Chang, C.-Y. Lee, Y.-C. Chiu, Enhanced authentication scheme with anonymity for roaming service in global mobility networks, Comput. Commun. 32 (4) (2009) 611–618.

[22] X. Lin, X. Sun, X. Wang, C. Zhang, P.-H. Ho, X. Shen, Tsvc: timed efﬁcient and secure vehicular communications with privacy preserving, IEEE Trans. Wireless Commun. 7 (12) (2008) 4987–4998.

[23] IEEE1363-2000-Std., Standard speciﬁcations for public key cryptography, 2000.

[24] NIST-standard, Fips publication 197: The advanced encryption standard (aes), 2001.