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

5.3.1 System Architecture

A system architecture of non-safety applications in VANETs is given in Figure 5.3.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 dierentiated 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 customer uses the travel guide service, the travel company automatically 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 oering various non-safety services in a distributed fashion. Thus, the access of non-safety services can be fullled locally.

Initially, each OBU must send a Register_Service_Request message to the SP to re-quest 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 au-thorized, then the neighboring RSU sends 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.

5.3.2 The Proposed Attachable Blind Signature

Generally, blind signatures could be implemented by dierent cryptosystems, such as RSA and ElGamal. We adopt RSA-based blind signature in the proposed blind signature scheme.

First, we briey introduce the conventional RSA-based blind signature. A user UA blinds a message m with a random blind factor r and computes the blind document

BD = r^em,

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

BD⁰ = BD^d= rm^d.

Then the signer sends BD⁰ back to UA. Upon receiving BD⁰, UA unblinds BD⁰ by the blind factor r to obtain the signer's signature

Finally, UA conrms the integrity of BD^” by checking

(BD^”)^e= m.

In a conventional blind signature, the signer does nothing but signs the blind document BD sent from the user. Such a conventional 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 conrms whether the requested access privileges 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,r2 and a, and then computes

BD₁= (r₁)^em^a(modN ) BD₂= (r₂)^em^(1−a)(modN ).

Then, UA sends BD1 and BD2 to the signer. Once receiving BD1 and BD2, the signer

rst attaches a message m⁰ into BD2 as

BD^#₂ = (r2)^em^(1−a)m⁰(modN ), and signs BD1, BD^#₂ by his/her own private key d as

BD⁰₁= (BD₁)^d= r₁(m^a)^d(modN )

BD⁰₂= (BD^#₂ )^d= r2(m^(1−a)m⁰)^d(modN ).

Then, the signer sends BD₁⁰,BD⁰₂ back to UA. Upon receiving BD⁰₁ and BD⁰₂, UA rst unblinds two messages as

BD^U₁ = BD₁⁰/r₁ = (m^a)^d(modN )

BD^U₂ = BD₂⁰/r₂ = (m^(1−a)m⁰)^d= (m^(1−a)d)(m^0d)(modN )

and generates the signer's signature by

BD^”= BD^U₁ · BD^U₂ = m^d· m^0d(modN ).

Note that the proposed attachable blind signature scheme attaches a message m⁰ into the signature and still keeps the privacy of user's message m. To withstand the privileges elevation attack, PAACP takes the advantage of m⁰ to ensure the validity of m.

5.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 regarded as an important property of VANETs [5, 6, 49], PAACP gets rid of the backend communication between roadside units and service providers. In PAACP, SPs do not involve in the access service phase. That is, the verication of vehicles and their access privileges can be accomplished in RSUs themselves. Thus, it is not required to take a long round trip of communication between RSUs and SPs for access request verications. In the access authorization phase of PAACP, the SP authorizes the access privileges for a legitimate vehicle, and stores a service right list in a portable authorized credential carried by the vehicle. The portable authorized credential is protected using the proposed attachable blind signature to withstand privilege elevation attacks.

Another merit of PAACP is the support of dierentiated access privileges for each service. A service may provide dierent access privileges to satisfy distinct requirements of the users. For this, the access privileges for the service i are represented by a bit string AR_i of ki bits. Each bit of ARi represents 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, ki distinct access privileges can be specied in ARi. Assume an SP provides n services with access privileges ARi, 1≤i≤n. Suppose a vehicle V is granted to access m services, 1≤m≤n, with

index {SV ID1, SV ID2,. . .,SV IDm}. Let AR⁰_j, 1≤j ≤m, be the granted value of ARj for V. Then, the service right list SRL for V can be represented by a bit string

SRL = (SV ID₁ k AR⁰₁)||(SV ID₂ k AR⁰₂)k . . . k(SV ID_m k AR_m⁰ )

with length P^m_i=1(logn + ki). For example, we assume an SP provides 16 services and the travel guide is the 12-th service with three dierent access privileges: viewing maps, downloading coupons, watching videos, then n=16 and k12=3 for AR12. If Vi applies for the travel guide service with the access privileges of viewing maps and downloading coupons, then V will set SRL=(1100k110) [53].

The proposed scheme consists of two phases: access authorization phase and access service phase, as illustrated in Figure 5.3.2 and 5.3.3. The notations of PAACP are sum-marized in Table 5.2.

According to the purchased services and granted access privileges, in the access autho-rization phase, a vehicle Vi creates a service right list SRL^V_iⁱ in AC^V_iⁱ and blinds AC^V_iⁱ into blind documents BD1i, BD2i. To obtain the corresponding portable authorized cre-dential for later use, Vi sends the blind documents with its certicate Certi to the service provider St. After checking the validity of Certi, St generates the service right list SRL^S_i^t based on the sold contract, stores SRL^S_i^t in AC^S_i^t and attaches AC^S_i^t into blind documents BD1_i, BD2i based on the proposed attachable blind signature. Then, Stdelivers the blind documents back to Vi. At the end of the access authorization phase, Vi will obtain the portable authorized credential AC^∗i , where AC^∗i consists of both AC^V_iⁱ and AC^S_i^t. AC^∗i

is stored in Vi's tamper-proof device [5, 48, 49]. In the access service phase, Vi sends an Access_Service_Request to its neighboring RSU Rj, and then Rj veries the authorized credential AC^∗_i by itself without further communication with St. According to the access privileges stored in the authorized credential AC^S_i^t, Rj could decide whether Vi's request is accepted or not. Furthermore, Rj could detect whether Viis launching a privilege elevation attack.

Table 5.2: Notations of the proposed scheme

Vi the i-th vehicle

VIDi The identication of the i-th vehicle Rj the j -th roadside unit

RIDj The identication of the j -th roadside unit St the t-th service provider

SIDt The identication of the t-th service provider SVIDi The identication of the i-th service

ARi The access privilege of SVIDi

(PKV_i, SKV_i) A public key and private key of vehicle Vi

(PKR_j, SKR_j) A public key and private key of roadside unit Rj

(PKSt, SKSt) A public key and private key of service provider St

Certi The certicate 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

AC^St, AC^Vi Authorized credential made by Stand Vi, respectively AC^∗i Portable authorized credential for vehicle Vi

SRL The service right list

SRL^St, SRL^Vi Service right list made by St, and Vi, respectively

BD1,BD2 The blind documents used in the proposed attachable blind signature EK_AB{·} The encryption function with shared key KAB

DK_AB{·} The decryption function with shared key KAB

MAC The message authentication code

h( ) A collision-free and public one-way hash function σi A signature signed by secret key SKV_i

q A large prime number

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

We explain the details of each phase as follows.

5.3.4 Access Authorization Phase

• Step 1: Vi→St: <VIDi, σi, BD1i, BD2i>

In the access authorization phase, according to the purchase receipt from the service provider St, a vehicle Vicreates its service right list SRL^V_iⁱ= {SVID1kAR1k....kSVIDkkARk}, where SVIDk denotes the index of the k-th service, and ARk represents the granted ac-cess privileges of SVIDk. The service right list will be signed by St as part of an au-thorized credential. First, Vi chooses random numbers RN1, RN2 and a, and then sets AC^V_iⁱ={SIDt kTexpiredkSRL^V_iⁱ}. These random numbers are used as blind factors. Then, Vi computes blind documents

BD1_i = (RN₁)^{P KSt} · (AC_i^Vi)^a(modN )

BD2_i = (RN₂)^{P KSt} · (AC_i^Vi)^1−a(modN ).

Finally, Vi sends its identity VIDi, signature σi={BD1i, BD2_i}^SKVi, and the blinded documents BD1i, BD2_i to St.

• Step 2: St→Vi:<BD1⁰_i, BD2⁰_i >

Upon receiving message <VIDi, σi, BD1i, BD2i> sent from Vi, St rst conrms whether the σi is valid by Vi's public key. If valid, Vi is successfully authenticated; otherwise, this session is dropped. Stthen generates the authorized credential AC^S_i^t={SIDtkTexpiredkSRL^S_i^t} according to the selling contract for Vi and attaches it into BD2^#_i as

BD2^#_i = BD2i· AC_i^St = (RN2P K_St · (AC_i^Vi)^1−a· AC^S_i^t)(modN ).

Then, St signs them as follows.

BD1⁰_i = BD1_i^SKSt = (RN₁)^{P KSt} · (AC_i^Vi)^aSKSt = (RN₁) · (AC_i^Vi)^aSKSt

BD2⁰_i = BD2^#_i ^SKSt = (RN2)^{P KSt} · (AC_i^Vi)^1−a· AC_i^StSKSt = (RN2)·(AC_i^Vi)^1−a· AC^S_i^tSKSt Next, BD1⁰_i, BD2⁰_i are sent back to Vi. After obtaining <BD1⁰_i, BD2⁰_i> from St, Vi

unblinds them as follows.

BD1^U_i = BD1⁰_i/RN₁ = (AC_i^Vi)^aSKSt

BD2^U_i = BD2⁰_i/RN2= (AC_i^Vi)^1−a· AC_i^StSKSt

In order to get the portable authorized credential AC^∗_i= {AC^V_iⁱ·AC^S_i^t}^SKSt, Vi computes

BD1^U_i · BD2^U_i = (AC_i^Vi)^aSKSt · (AC_i^Vi)^1−a· AC_i^StSKSt = AC_i^Vi · AC_i^StSKSt.

To conrm the AC^∗_i is certied, Vi could verify the correctness of AC^∗_i by checking whether {AC^∗i}^{P KSt} is equal to AC^V_iⁱ·AC^S_i^t.² If it holds, Vi keeps AC^∗i for the subsequent service requests; otherwise, Vi will stop this session. Note that, we assume Vi could protect AC^∗_i in secret by tamper-proof device after obtaining AC^∗_i.

5.3.5 Access Service Phase

• Step 1: Vi→Rj: <Access_Service_Request, {SVID, YV, AC^∗_i}^{P KRj}>

In the access service phase, when a vehicle Vi wants to access the desired services from its neighboring roadside unit Rj, Vi will transmit an Access_Service_Request with {SVID, Y_V, AC^∗_i}^{P KRj}, where SVID is the identication of the desired services, and YV = g^xmod q , where x is a random number in Z^∗q, to Rj.

• Step 2: Rj→Vi:<YR,ET SK⁰ {YV+1, Access_Permission}>

2Note that if both Vi and St are legal, AC^Viⁱ and AC^Si^t should be the same, which means Vi or Rj

could conrm whether AC^Viⁱ·AC^Si^t is expected or not.

1. Confirms Cert_i

2. Attaches to BD2_ias

3. Signs BD1_iand BD2_ias

Vehicle V_i Service Provider S_t

1. Chooses RN₁, RN₂, a

Figure 5.3.2: Access authorization phase of the proposed scheme

Upon receiving {SVID, YV, AC^∗_i}^{P KRj}, Rj decrypts it by his own private key SKRj to acquire (SVID, YV, AC^∗i). First, Rj calculates

AC_i^St = (AC_i^{∗P KSt})^1/2

to extract the access credential AC^S_i^t, which is authorized by St. Then, Rj examines whether SIDtas well as SVID is included in AC^S_i^t, and checks the validity of the authorized credential by Texpired. If the verication succeeds, AC^∗_i is legitimate and Vi is authorized;

otherwise, Rj terminates this session. After AC^∗_i is veried, Rj calculates

Y_R= g^ymod q,

where y is a random number in Z^∗q, and generates a temporary session key

T SK⁰= h(AC_i^∗, (YV)^ymod q, 0)

for protecting the subsequent communications. Finally, Rj delivers <YR, ET SK⁰{YV+1, Access_Permission}> to Vi.

• Step 3: Vi→Rj: <ET SK¹{Auth_Ack}, MAC>

After receiving <YR, ET SK⁰{YV+1, Access_Permission}> , Vi computes a temporary session key

T SK⁰ = h(AC_i^∗, (YR)^xmod q, 0)

and decrypts ET SK⁰{YV+1, Access_Permission} using TSK⁰ to check the validity of Y_V+1. If valid, Rj is successfully authenticated; otherwise, Vi ceases this connection.

Then, Vi generates an Auth_Ack encrypted by

T SK¹ = h(AC_i^∗, (YR)^xmod q, 1) and computes the message authentication code

M AC = (T SK⁰, E_{T SK}¹Auth−Ack).

Finally, Vi sends <ET SK¹{Auth_Ack}, MAC > to Rj.

Upon receiving the message, Rj veries the MAC to ensure the integrity, and calculates T SK¹= h(AC_i^∗, (YV)^ymod q, 1)

to decrypt ET SK¹{Auth_Ack}. If Rj could recognize Auth_Ack, it is implied that Vi

indeed holds the corresponding TSK¹. Finally, the subsequent communications can be encrypted by the session key TSK^k, where

T SK^k= h(AC_i^∗, (YV)^y mod q, k).