An efficient and secure mobile payment protocol ... - Semantic Scholar

Computer Communications 35 (2012) 188–195

Contents lists available at SciVerse ScienceDirect

Computer Communications journal homepage: www.elsevier.com/locate/comcom

An efficient and secure mobile payment protocol for restricted connectivity scenarios in vehicular ad hoc network Wenmin Li ⇑, Qiaoyan Wen, Qi Su, Zhengping Jin State Key Laboratory of Networking and Switching Technology, Beijing University of Posts and Telecommunications, Beijing 100876, China

a r t i c l e

i n f o

Article history: Received 12 November 2010 Received in revised form 3 September 2011 Accepted 5 September 2011 Available online 10 September 2011 Keywords: Vehicular ad hoc network Wireless communication Security Payment Data volume transferred

a b s t r a c t Value-added applications in vehicular ad hoc network (VANET) come with the emergence of electronic trading. The restricted connectivity scenario in VANET, where the vehicle cannot communicate directly with the bank for authentication due to the lack of internet access, opens up new security challenges. Hence a secure payment protocol, which meets the additional requirements associated with VANET, is a must. In this paper, we propose an efficient and secure payment protocol that aims at the restricted connectivity scenario in VANET. The protocol applies self-certified key agreement to establish symmetric keys, which can be integrated with the payment phase. Thus both the computational cost and communication cost can be reduced. Moreover, the protocol can achieve fair exchange, user anonymity and payment security. Ó 2011 Elsevier B.V. All rights reserved.

1. Introduction Vehicular ad-hoc network (VANET), in which vehicles and roadside infrastructure constitute the nodes, aims to provide safety and comfort for drivers and passengers. Value-added applications in VANET, which improve passenger comfort and offer great business opportunities, attract more and more attention in our daily life. Most of such applications come with the emergence of electronic trading. Hence an efficient and secure payment protocol associated with the application scenario is a must. Normally, how to design a mobile payment protocol depends on its associated scenarios which arise from vehicle-to-vehicle and vehicle-to-roadside communications in VANET. In [1], the authors demonstrated a restricted connectivity scenario (as shown in Fig. 1) for value-added applications, where the vehicle cannot communicate directly with the bank for authentication during a payment transaction due to the lack of internet access. In the described scenario, concrete applications divided into event-based applications and session-based applications. In event-based applications, vehicle’s payment is reflected by one-time events, e.g. sending a message, querying traffic information, purchasing gas. In session-based applications, vehicle is charged based on data volume transferred, such as media downloading, map downloads and updates or on-line movies [2–4]. Therefore, the characteristics of different applications open up new challenges that must be considered by payment protocol ⇑ Corresponding author. Tel.: +86 10 62283240. E-mail address: [email protected] (W. Li). 0140-3664/$ - see front matter Ó 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.comcom.2011.09.003

designers to achieve a secure and efficient payment. To summarize, the following requirements should be addressed when designing a suitable payment protocol in VANETs [1,3,5,6]. First, the designed payment protocol should conform to the real communication scenario. Second, a payment protocol should be light-weight, that is, with low computational complexity and low communication overhead, so it can be easily performed. Third, fair exchange and user anonymity should be achieved. Finally, payment security, such as confidentiality, non-repudiation of origin, resistance to conventional attacks, and the avoidance of overspending and double spending, should be satisfied. In this paper, we design a mobile payment protocol for applications in the restricted connectivity scenario of VANET, which attempts to meet these requirements. We apply the self-certified key agreement to generating the symmetric encryption keys, which combines the advantages of both public-key cryptography and symmetric-key cryptography. Our design guarantees that the session key is fresh in every payment of a payment transaction, which provides more robust security protection. The key agreement phase can be integrated with the payment phase which is far less complex. At the same time, due to using self-certified public keys (SCPKs) on elliptic curve, the protocol not only avoids the requirement of a large public key infrastructure (PKI) but also achieves efficient performance in contrast to other public key cryptosystems. Moreover, our protocol supports not only data volume transferred based application but also one-time event application. The remainder of this paper is structured as follows. In Section 2, we introduce the related works. In Section 3, we present the preliminaries and notations used in the rest of the paper. In Section 4, we

W. Li et al. / Computer Communications 35 (2012) 188–195

189

Table 1 Notations. IDp Pkp Rp sp [M]k OI Hi,f SN InitRequest InitResponse AuthRequest AuthResponse PRequest PResponse DRequest DResponse

The identity of participant P The public key of participant P A witness for participant P The secret key of participant P Message M encrypted by symmetric key k Order information containing the price and order descriptions The one-way hash function Serial number of the payment A request (response) for initiating conversation A request (response) for authentication A request (response) for payment A request (response) for redeeming tokens

3.1. Diffie–Hellman assumption

Fig. 1. The restricted connectivity scenario.

propose our mobile payment protocol for restricted connectivity scenarios in VANET. The security and performance analysis of the proposed protocol will be found in Section 5. Finally, conclusions are given in Section 6. 2. Related works Over the past years, many academic papers are published to describe the mobile payment protocol. Among these protocols, [7] dedicated to unify many proposed m-commerce usage scenarios into a single framework, and then use this framework to analyze security issues. Later, as far as security concerned, several payment protocols [3,8,9] based upon PKI were proposed for wireless mobile networks. However,[10] pointed out that such protocols are not suitable for wireless mobile networks due to time consuming. To reduce the computation loads, they also presented an efficient and practical payment protocol for mobile commerce. However, all these protocols are only suitable for full connectivity scenario where all the entities are directly connected one to another (as described in [7]). Designing mobile payment protocol suitable for restricted connectivity scenarios, achieving the same security and performance levels as the full connectivity scenario, is a challenge. Excellent protocols [1,11–13] constitute examples of mobile payment protocols suitable for scenarios with communication restrictions. However, such proposals do not satisfy requirements of applications based on either time spent or data volume transferred. The reason is that such applications require multiple payments in a payment transaction while the proposed protocols allow only one. Hence, these protocols are not suitable for session-based applications in the restricted connectivity scenario of VANET, which opens a new challenge to design protocol with multiple payments in one transaction. 3. Preliminaries In this section, we briefly review the basic concepts on self-certified public keys (SCPKs) and some related mathematical problems. Besides, the symbols used in the rest of this paper are illustrated in Table 1.

Choose elliptic curve E defined over a finite field Fq of characteristic p, and a base point P 2 E(Fq). The public elliptic curve domain parameters over Fq should be chosen appropriately to prevent the employment of any efficient algorithm from solving the Elliptic Curve Discrete Logarithm Problem (ECDLP) or ECCDH in the cyclic subgroup (p). Let G be a cyclic additive group generated by P, whose order is a prime n. We consider the following problems in the additive group (G, +) [14]: Elliptic Curve Discrete Logarithm Problem: Given two group elements P and Q, find an integer x 2 Z n , such that Q = xP whenever such an integer exists. Elliptic Curve Decision Diffie–Hellman Problem: For a; b; c 2 Z n , given P, aP, bP, cP decide whether c ab modq. Elliptic Curve Computational Diffie–Hellman Problem: For a; b 2 Z n , given P, aP, bP, compute abP. Up to now, there is no efficient algorithm to be able to solve any of the above problems [15].

3.2. Self-certified public keys A self-certified public keys combines the advantages of certificate-based and identity-based public key cryptosystems, and also provides a mechanism for authenticating a user’s public key [16– 18]. The public key of user is computed directly from the signature of the system authority (SA) on the user’s identity. A simple selfcertified scheme is presented below. Set up: SA chooses a non-singular high elliptic curve E defined over a finite field Fq which is used with a based point generator P of prime order n. SA chooses a key pair (ss, Pks), where Pks = ssP. The related parameters E, P, n, Pks are public while ss is kept secret. Private key generation: User U chooses a random number ku, computes Ku = H1(IDu, ku)P, and sends IDu, Ku to SA over secure channel. Upon receiving the message, SA generates a random number ru, calculates Ru = Ku + ruP as a witness for user U, and then computes partial private key as follow xu = H2(IDu, Ru)ss + ru. Then, SA returns Ru,xu to user U, who obtains his secret key as follows: su = xu + H1(IDu, ku). Public key extraction: Based on the pre-deployment, everyone who receives the witness Ru can compute the corresponding public key Pku as follows: Pku = H2(IDu, Ru)Pks + Ru. Correctness: The public key can be computed correctly due to: PKu = suP = xuP + H1(IDu, ku)P = H2(IDu, Ru)ssP + ruP + H1(IDu, ku) P = H2(IDu, Ru)Pks + Ru.

190


4. Our proposed mobile payment protocol for restricted connectivity scenarios in VANET 4.1. The payment architecture in VANET In our protocol the players are vehicle, merchant, and bank as defined in [4,19,20], which are described as follows. Vehicle: a participant who wants to pay for data volume, physical goods or services from merchant. In our protocol, we refer to a vehicle equipped with an on-board unit (OBU) and one or more application units (AUs). The OBU is responsible for vehicle to infrastructure communications. AU is an in-vehicle entity (embedded or pluggable) and runs applications that can utilize the OBU’s communication capabilities. Merchant: a participant that has data content, physical products or services to offer or sell. This entity could be a normal web server, a roadside computing station, an intelligent vending machine or other application providers. Bank: a financial entity responsible for the payment process, provides and warrants the electronic money. This participant can also be different types of financial institutions such as credit card company. Usually, the bank is reliable and responsible for authentication. Before the payment, the vehicle and the merchant may be required to register with a bank, that is, they hold the public key and witness of the bank in their AU and open a pre-paid or credit/debit account with the bank. Besides, the connection between the vehicle and the merchant is set up through a wireless channel. In the meanwhile, the connection between the merchant and the bank can be established by the internet.

Algorithm 1 (Generate Parameters). 1. Choose a finite field Fq over a large odd prime q > 2160. 2. Define an elliptic curve equation E : y2 x3 + ax + b(modq) with the order n over Fq, where a, b 2 Fq, q > 3, 4a3 + 27b2 – 0modq. 3. Choose a public point P with the order n over E. 4. Generate a cyclic additive group G of order n over E by point P. 5. Choose four hash functions H1,2,3, f : {0, 1}⁄ ? {0, 1}n. 6. Choose a key-pair {ss, Pks}, where Pks = ssP. 7. Return {G, P, H1, H2, H3, f, ss, Pks}. 4.3. The key agreement phase In our design, the messages exchanged among the vehicle V, the merchant M and the bank B are encrypted by symmetric encryption algorithm. The symmetric keys are generated by self-certified key agreement protocol. After registration, V, M and B each owns a pair of public/private key, by which they associate the symmetric key pairwise. The three symmetric keys are updated at the beginning of every payment transaction. Moreover, the symmetric key between V and M is updated during every payment of a payment transaction to ensure freshness of the keys. Take the symmetric key between V and M for example, we introduce the key agreement phase in this section. Step K1: M chooses a random number rmv, computes kmv = smrmv[H2(IDv, Rv)Pks + Rv] and rmvPkm, and then sends rmvPkm to V. Step K2: Upon receiving the message, V computes the corresponding symmetric key kvm = svrmvPkm, where sv is his secret key.

4.2. System setup and user registration In the proposed protocol, we use some cryptographic techniques and basic tools to permit payment security and enhance efficiency. According to the setup requirements of SCPKs mentioned above, we assume that SA is responsible for generating system parameters and authenticating the user’s public key. To achieve this, SA executes Algorithm 1 to obtain parameters {G, P, H1, H2, H3, f, Pks, ss}, where ss is kept secret while the others are public. Whenever a user U with his identity IDu wants to join the system, U chooses ku randomly, computes Ku = H1(IDu, ku)P, and sends IDu, Ku to SA over secure channel. Once receiving the message, SA selects a random number ru, and computes Ru and xu, where Ru = Ku + ruP and xu = H2(IDu, Ru)ss + ru. After that, SA sends Ru, xu to U over a secure channel. Thus, U computes su = xu + H1(IDu, ku) as her/his long-term private key and Pku = suP as her/his public key. Moreover, when the vehicle registers as a user, a nickname is used instead of the real identity in order to protect his privacy. The registration process is also illustrated in Fig. 2.

Correctness: kmv = smrmv[H2(IDv, Rv)Pks + Rv] = smrmvPkv = rmvsmsvP = svrmv Pkm = kvm that is, kmv = kvm. The result above ensures that kmv = kvm. Accordingly, we can obtain similar results for other participants. 4.4. The proposed mobile payment protocol In this section, we describe the execution of the proposed electronic payment protocol using self-certified public key by which V purchases services from M. During the payment transaction, V cannot communicate directly with B due to lack of internet access. Thus, M plays the role of proxy to transmit authentication messages from V to B. The messages transmitted in each phase are detailed as follows. Algorithm 2 (Generate tokens). 1. for i N 1 downto 0 do 2. Wi H3(Wi+1) 3. return {WN, WN1, . . . , W0} (1) V ! M : InitRequest ¼ fIDv ; Rv ; MIDReq; SNReqg M ! V : InitResponse ¼ f½IDm ; Rm ; r mv ; SN; pricekmv ; r mv Pkm g (2) V ! M : AuthRequest; 1stPRequest M ! B : f½SN; IDv ; IDm ; Rm ; r mb ; OI; t 2 ; AuthRequestkmb ; r mb Pkm g AuthRequest ¼ f½SN; IDv ; Rv ; r v b ; IDm ; hðOIÞ; N; W N ; W 0 ; t 1 kv b ; r v b Pkv g 1stPRequest ¼ f½SN; IDv ; W J1 ; J 1 kv m g

Fig. 2. Registration of a user.

(3) B ! M : (4) M ! V : V!M: M!V:

AuthResponse ¼ f½SN; IDv ; IDm ; N; W 0 ; t 3 kbm g 1stPResponse ¼ f½J 1 datakmv g 2ndPRequest ¼ fSN; ½IDv ; W J1 þJ2 ; J 1 þ J 2 kv m g 2ndPResponse ¼ f½J 2 datakmv g

191


.. . V ! M : jthPRequest ¼ fSN; ½IDv ; W J1 þJ2 þ...þJj ; J 1 þ J 2 þ . . . þ J j kv m g M ! V : jthPResponse ¼ f½J j datakmv g (5) M ! B : DRequest ¼ fSN; ½IDv ; IDm ; W J ; Jkmb gðJ 6 NÞ B ! M : DResponse Step 1: V and M exchange the information necessary to start the protocol in the following way. 1–1: V sends an InitRequest to M, which consists of V’s ID, IDv, the witness Rv, the request for M’s ID and public key, the unit price of the data and the request for an unique serial number, SN. 1–2: At V’s request, M chooses a random number rmv, computes kmv = rmvsm[H2(IDv, Rv)Pks + Rv] and rmvPkm, and sends InitResponse {[IDm, Rm, r mv ; SN; pricekmv ; r mv Pkm g to V. Step 2: In this step, V generates the electronic token chain which will be authenticated by B, and initiates the payment transaction. 2–1: Upon receipt of the InitResponse, V utilizes the second parameter rmvPkm and V’s private key sv to generate the symmetric key kvm = svrmvPkm, and decrypts the first parameter to obtain the information {IDm, Rm,rmv, SN, price} by the key. To authenticate the sender of the message, V verifies whether rmv[H2(IDm, Rm)Pks + Rm] is equal to the second parameter rmvPkm. If they are not equal, the sender is illegal, and the phase quits without sending extra messages. Otherwise, the following steps are executed. 2–2: V selects a random number as the token root WN, and then executes Algorithm 2 to obtain the electronic token chain WN1, WN2, . . . , W1 and a token verifier W0. W0 will be used by M to ensure that the tokens are sent from V in the first payment transaction. In addition, each token indicates the unit price of the data. 2–3: V chooses a random number rvb, and computes kvb = rvbsv[H2(IDb, Rb)Pks + Rb] and rvbPkv. Then, V sends an AuthRequest f½SN; IDv ; Rv ; r v b ; IDm ; hðOIÞ; N; W N ; W 0 ; t1 kv b ; r v b Pkv g and the first PRequest f½SN; IDv ; W J1 ; J 1 kv m g to M, where t1 is the current system time and J1 is the amount of data units which is V wants to purchase first. 2–4: When M receives the message, it has no responsibility for authentication. Hence M computes rmbPkm and submits f½SN; IDv ; IDm ; Rm ; rmb ; OI; t 2 ; AuthRequestkmb ; r mb Pkm g to B, where rmb is a random number selected by M, t2 is the current system time and kmb = smrmb[H2(IDb, Rb)Pks + Rb]. Besides, M decrypts the first PRequest by kvm and stores fIDv ; W J1 ; J 1 ; kmv g using SN as the index. Step 3: In this step, B authenticates the validity of the electronic token chain generated by V as follows. 3–1: Upon receiving the message, B derives the symmetric key kbm from kbm = sbrmbPkm, and reveals {SN, IDv, IDm, Rm, rmb, OI, t2, AuthRequest} by the key. Similar to Step 2–1, B calculates rmb[H2(IDm, Rm)Pks + Rm] to authenticate the sender of the message. If it is not equal to the second parameter, the sender is illegal, and the phase quits. Otherwise, B verifies the timeliness of the message by checking the difference between t2 and the local clock time which is used to prevent message replay and impersonation attacks. If the check is not successful, a failure response is sent to M. Otherwise, the following steps are executed. 3–2: B employs the second parameter of AuthRequest to obtain kbv by kbv = sbrvbPkv and decrypts the first parameter of AuthRequest to retrieve {SN, IDv, Rv, rvb, IDm, SN, IDv, Rv, rvb, IDm, h(OI), N, WN, W0, t1}. Similar to step 3–1, B first checks the validity of V by checking whether rvb[H2(IDv, Rv)Pks + Rv] is equal to the received rvbPkv. Then B

verifies the timeliness of AuthRequest by t1 which is used to prevent message replay and impersonation attacks, compares the merchant’s OI with the h(OI) included in AuthRequest, and checks whether the total value N⁄price is smaller than the balance of account. At last, B executes Algorithm 2 with arguments WN and N to check whether V generates the tokens legally. 3–3: If all the checks are successful, B deducts the cost for N tokens from V’s account, stores {SN, IDv, IDm, N, WN, kbm} required in the deposit phase, and sends AuthResponse f½SN; IDv ; IDm ; N; W 0 ; t 3 kbm g to M. Otherwise, a failure message is sent to M.

Step 4: In this step, V uses the tokens to purchase data from M. This phase may consist of one or more payments. We assume that V pays Ji tokens in ith payment. 4–1: M decrypts the AuthResponse to extract {SN, IDv, IDm, N, W0, t3} by kmb, and then verifies the timeless of AuthResponse by t3. Using SN as the index, M queries its database to obtain fIDv ; W J1 ; J 1 ; kmv g. 4–2: M verifies token W J1 by computing H3 ðH3 . . . ðH3 ðW J1 ÞÞÞ. |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} J1

If it is equal to W0, M accepts it, encrypts J1 data units by kmv, and then deliveries the data as the first PResponse to V. Otherwise, a failure response is sent to V. Additionally, M stores W J1 instead of W0 to verify the tokens in the following payment. 4–3: V uses kvm to decrypt the received PResponse and obtains the J1 data units. Then, V purchases the next J2 data units by sending the second PRequest fSN; ½IDv ; W J1 þJ2 ; J 1 þ J 2 kv m g to M. 4–4: M acquires W J1 þJ2 and J1 + J2 by decrypting the second PRequest with kmv. M gets J2 by computing J1 + J2 J1. Then, M checks whether the equation H3 ðH3 . . . ðH3 ðW J1 þJ2 ÞÞÞ ¼ W J1 |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} J2

holds. If it holds, M will recognize the token W J1 þJ2 and store it instead of W J1 . Then M encrypts J2 data units by kmv, and deliveries it as the second PResponse to V. Otherwise, a failure response is sent to V. Repeating steps 4–3 and 4–4, V can purchase data units from M consecutively. The phase may be terminated if V stops paying tokens or M stops delivering services. In the meanwhile, V updates the session key kvm for the last payment to 0 kv m ¼ f ðkv m ; sv ½H2 ðIDm ; Rm ÞPks þ Rm Þ for the current payment. Accordingly, M updates the session key kmv for the last payment 0 to kmv ¼ f ðkmv ; sm ½H2 ðIDv ; Rv ÞPks þ Rv Þ for the current payment. Step 5: In this step, M redeems the received tokens from B, that is, the step is the deposit phase. 5–1: M submits DRequest fSN; ½IDv ; IDm ; W J ; Jkmb g ðJ 6 NÞ to B. 5–2: Upon receiving the DRequest, B uses SN as index to query its database for {IDv, IDm, N, WN, kbm}. Then, B decrypts the second parameter of the DRequest by kbm to obtain {IDv, IDm, WJ, J}, and checks whether H3 ðH3 . . . ðH3 ðW N ÞÞÞ ¼ W J holds to verify the valid of the |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} NJ

token WJ. If the check passes, B performs Substep5–3(a), otherwise B performs Substep5–3(b). 5–3(a): B deposits the credit for J tokens into M’s account and returns the rest value to V’s account. The payment transaction is completed. 5–3(b): B sends a message DResponse to M to notify it of the response failure. M then starts a recovery procedure or resends the message.

192


Remark 1. If M does not perform step 5–1 after the payment in a predefined time period, the payment transaction is considered incomplete, and B gives the value of all tokens into V’s account, and terminates the payment transaction. Remark 2. Once V finished all purchases with M, M’s information will be removed to release the memory space. Fig. 3 shows the transmitted messages flow among the participants during the execution of the proposed electronic payment protocol. 5. Features and performance analysis 5.1. Features of proposed protocol In this section, we discuss the features of the proposed payment protocol from three aspects: fair exchange, user anonymity and payment security, and we also compare our protocol with [1,13] in Table 2. 5.1.1. Fair exchange Fair exchange [21] is one of the most important properties to protect the participants’ benefits. In the proposed protocol, B is an honest participant. Therefore, V and M are possible participants engaging in misbehavior. During the execution of payment transaction, V pays the tokens before M provides data content. Thus, there is no risk for M to execute the protocol. In addition, V can terminate the token payment immediately once not received the requested data units. In this case, at most one token is lost, which is of no significance. It is just one of the main goals to employ the token chain. From the above, the fair exchange can be accommodated in the proposed protocol. 5.1.2. User anonymity User anonymity ensures that the real identity of any vehicle is not revealed during transactions. During the payment process of the proposed protocol, neither M nor B needs to know V’s real identity. In the registration phase of the proposed protocol, V uses a nickname which is only known to the SA instead of the real identity. Therefore, neither M nor B could map the nickname to the V’s true identity. Besides, the real identity can be revealed by SA if necessary. That is, this anonymity protects

Table 2 Comparison of the mobile payment protocol. Properties

Our protocol

[1]

[13]

Resistance to the replay attack Resistance to impersonation attack Resistance to man-in-the-middle attack Fair exchange User anonymity Confidentiality Non-repudiation of origin Avoidance of double spending Avoidance of overspending No public key decryption Symmetric key encryption One-time event Data-volume transferred No pre-shared key

Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

Yes Yes Yes NR Yes Yes Yes NR NR No No Yes No Yes

Yes Yes Yes NR Yes Yes Yes NR NR Yes Yes Yes No No

Note: ‘NR’ denotes the feature is not refereed.

relevant information from third parties but not unrestrained anonymity [22]. 5.1.3. Payment security In this subsection, we analyze the payment security of the proposed protocol with respect to attacks, confidentiality, non-repudiation of origin, and the avoidance of overspending and double spending. Resistance to replay attack: Replay attack means an active adversary interferes with a protocol run by insertion of a message, or part of a message sent previously in any protocol run. That is, the adversary can not obtain the parties’ private key but the transcripts transmitted in the protocol. In our design, timestamps are applied to forbid replay attack in the authentication phase. In order to pass the authentication, the adversary must change t1, t2, t3 into new time which are in accordance with the receiver’s local clock time. Once t1, t2, t3 has changed, the corresponding AuthRequest and AuthResponse would be changed as well. However, kvb is computed by rvbsv[H2(IDb, Rb)Pks + Rb], where sv is unknown for the adversary. Similarly, kmb is computed by smrmb[H2(IDb, Rb)Pks + Rb], where sm is unknown for the adversary. Therefore, the adversary cannot derive valid AuthRequest and AuthResponse. In addition, in payment phase, a token is stored by M to check the replay attack. If the adversary replays W J1 þJ2 þ...þJi in i + 1th payment, the equation H3 ðH3 . . . ðH3 ðW J1 þJ2 þ...þJi ÞÞÞ ¼ W Ji will not hold. The reason |fflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl{zfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflfflffl} Jiþ1

Fig. 3. The proposed payment protocol messages flow.

is that the token is updated during every payment. Therefore, the protocol is secure against the replay attack. Resistance to impersonation attack: Assume that an adversary wants to impersonate a legal user V to cheat B. The adversary generates an electronic token WN1, . . . , W1, W0, and submits AuthRequest on behalf of V. Unfortunately, the adversary could not pass the verification in step 3–1 and 3–2 due to the timestamps and lack of private key sv. Similarly, the adversary could not forge a valid PRequest in the payment phase and masquerade as a legal M in the deposit phase without generating a valid kvm or kmb. Therefore, our protocol can avoid the impersonation attack. Resistance to man-in-the-middle attack: An man-in-the-middle attack is that an adversary places himself between two legitimate parties and can impersonate one or both of them. As described above, the protocol is secure against impersonation attack. That is, the adversary can impersonate neither of the parties. Therefore, the protocol can prevent man-in-the-middle attack. Confidentiality: Confidentiality means that the information exchanged among the participants cannot be revealed, by which the privacy of the participants can be protected. In our proposal, the transmitted messages are encrypted by an authentication encryp-

193


tion algorithm, which enables only the specified receiver to verify and to decrypt the messages. Hence the encryption of our method permits the maintenance of confidentiality, that is, the confidentiality is well realized in the proposed protocol. Non-repudiation of origin: The object of non-repudiation of origin is to prevent participants from claiming that the performance on their behalf was made without their knowledge. As described above, only V and M are possible participants engaged in misbehavior in the proposed protocol. The messages transmitted from V to B is encrypted by the symmetric key kvb generated by V and B. It is similar for the case of of communication between M and B. Moreover, verification is designed to resolve the dispute that may occurred between V and M. Thus, M prevents the possibility that V denies to have sent tokens. At the same time, any possible forgery is avoided. Avoidance of overspending and double spending: Overspending means that V’s account balance is not enough for purchasing. In the proposed protocol, we adopt the ‘prepaid’ method, which means that V’s account is deducted before purchasing data volume. Hence overspending can be avoided. The double spending, which occurs whenever V or M attempts to use a token more than once, can be avoided as follows. First, in the authentication phase of the proposed protocol, B ensures that the token chain is generated for the specified M, and then sends the token verifier to the M. Second, during the payment phase, M can verify whether a token has been sent to him more than once by step 4. Third, in the deposit phase, B can detect in step 5, if M attempts to deposit two or more times the same tokens received from an honest V. Moreover, the proposed protocol uses a timestamp and a symmetric key to encrypt the payment details, which cannot be reused. 5.2. Performance analysis In this subsection, we evaluate the proposed protocol from the following important properties: computation cost, storage cost and communication cost. 5.2.1. Computation cost To measure the computation cost, some notations and approximate relationships between different operations are recalled as follows [24]: TH denotes the time for executing the hash function

H; TSym denotes the time for the symmetric encryption/decryption operation; TMul denotes the time of the modular multiplication; TM denotes the time for multiplication without modulo N; T EC Mul denotes the time of the multiplication on an elliptic curve E; 1T EC Mul ’ 29T Mul ; TExp denotes the time of the modular exponentiation, 1TExp ’ 240TMul. The computation cost of the proposed protocol can be evaluated in three aspects. Following are the details, which is also illustrated in Table 3. Token generation and verification: The ‘token’, which is used for payment in the proposed protocol, is generated and verified by a hash chain. Thus the incremental cost of a payment is one hash function computation per party. Assume that V generates N tokens and pays J(J 6 N) to B for digital content. First, V generates the N tokens in step 2–2 by Algorithm 2, where the hash function has been executed N times with computation cost NTH. Second, in the authentication phase, B verifies the token chain in step 3–2 by Algorithm 2 as V did. Therefore, the computation cost is also NTH in this phase. Third, in the payment phase, M verifies the validity of J tokens by executing hash function J times, where the computation cost is JTH. At last, in the deposit phase, M sends the last token of the received tokens in the payment phase to B, then B verifies the tokens by executing hash function N J times, that is, the computation cost in this phase is (N J)TH. So, to sum up, the total computation cost for token generation and verification is 3NTH. As mentioned in [23], hash function H is about 100 times faster than RSA signature verification, and about 10,000 times faster than RSA signature generation: on a typical workstation, one can sign two messages per second, verify 200 signatures per second, and compute 20,000 hash function values per second. Conventionally, the number N of tokens required in a payment transaction is 50 to 50,000, and the corresponding computation cost is 150TH to 150,000TH, which is considered to be reasonably smaller than what RSA needs. Message Encryption and Decryption: The proposed protocol utilizes the symmetric encryption algorithm such as AES. Assume that there are J(1 6 J 6 N) payments processed in the execution of the protocol, there are J + 1 messages need to be encrypted by V, J + 2 messages need to be encrypted by M, and 1 message need to be encrypted by B, respectively. In addition, each encrypted message requires corresponding decryption. Therefore the total computation cost for message encryption and decryption are 2(2J + 4)Tsym. A symmetric encryption/decryption is at least 100 times faster than an asymmetric encryption/decryption in software, which are conformed in [23]. Hence the proposed protocol has the lower computational cost than which employs traditional public-key cryptography. Symmetric key update: To continue with the performance evaluation, the computation cost for symmetric key update need to be considered. During the execution of the proposed protocol, three symmetric keys, kmv(kvm) in step 1–2(2–1), kvb(kbv) in step 2–3(3–2), and kmb(kbm) in step 2–4(3–1) require update. The cost for updating each key is only 2T EC Mul for each participant, which is reasonable and suitable for VANET. Moreover, kmv, kvm are also

Table 3 Computation cost of our protocol. Cost

V

M

B

Token generation Token verification Key generation Key update Symmetric encryption Symmetric decryption

NTH 0 4T EC Mul (J 1)TH (J + 1)Tsym (J + 1)Tsym

0 JTH 6T EC Mul (J 1)TH (J + 2)Tsym (J + 1)Tsym

NTH (N J)TH 4T EC Mul 0 1Tsym 2Tsym

194

W. Li et al. / Computer Communications 35 (2012) 188–195 Table 4 Comparison of computation cost. V

M

B

[1]

14JTExp +10JTH +8JTMul +6JTM



[13]

(4J + 2)TSym +4JTH +2JTMac

(5J + 2)TSym +4JTH +JTMac

3JTSym +7JTH +JTMac

Ours

2(J + 1)TSym +(N + J 1)TH þ4T EC Mul

(2J + 3)TSym +(2J 1)TH þ6T EC Mul

3TSym +(2N J)TH þ4T EC Mul

updated by computing one time hash function for each participant in different payment of a payment transaction. Table 4 shows the comparison of computation cost between related works and our protocol in a payment transaction which contains J times payment. The computation cost consists of two parts, cost for generating session keys and payment cost. Obviously, protocol in [1] has higher computation cost than the rest since it utilizes time-consuming modular exponentiation. The computation cost of protocol in [13] is lower than our proposal for generating session key at the first time. However, in this phase, it depends on pre-shared keys among participants which limits the application of the protocol, while our proposal avoids these additional message exchanges at the expense of reasonable computation cost. Furthermore, once the connection established, the cost for updating session key in our protocol and protocol in [13] is the same while the payment cost of our proposal is lower than the other. Therefore, our proposal is more suitable for payment transactions which contain multiple payments in computation cost. 5.2.2. Storage and communication cost To measure the storage and communication cost, we assume that the length of the identity is 10 bytes, the length of a random number is 16 bytes, the timestamp is 4 bytes, the throughput of the one-way hash function is 16 bytes, the elliptic curve cryptosystem is 20 bytes, the RSA module is 90 bytes, the cipher text size using the symmetric encryption/decryption AES is 16 bytes. In the mobile payment protocol, V is the only participant using an AU, which could be a portable device with storage limitations. Therefore, we focus on the storage cost of V. The common storage information of three protocols are the identity and nickname of V, issue’s identity and hash function. Besides, protocol in [1] and our proposal need storage the public and private key of V, the public key of B, RSA or ECC module and corresponding generator while protocol in [13] need storage the pre-shared key and message authentication code. The total storage cost of the related works and our proposal are 384 bytes, 168 + 16t bytes and 236 bytes, respectively. Concrete comparison results can be found in Table 5, where t is the number of the merchants. When the number of the merchants is more than 5, the storage cost of our proposal is lowest. For the mobile environment of VANET, messages between V and M are transmitted through the wireless network. Hence it is mainly concerned with the message size between V and M in the proposed protocol. On the one hand, the largest message transmitted from V to M consists of a pseudonym (8 bytes), two cipher text message generated by AES (32 bytes) and a parameter (about 20 bytes). On the other hand, the largest message transmitted from M to V is made up of a cipher text (16 bytes) generated by AES and a parameter (about 20 bytes) for key agreement. Therefore the largest communication cost in our protocol is 60 bytes. Similarly, we can estimate that the largest communication cost of protocols in

Table 5 Comparison of storage cost. Parameter

[1]

[13]

Ours

Client’s identity Client’s nicknames Client’s secret key Client’s public key Pre-shared key Issuer’s identity Issuer’s public key RSA/ECC modules Generatorg(P) Hash function h() MAC (X,K) Total

10 100 20 20 0 10 28 90 90 16 0 384 bytes

10 100 0 0 16t + 16 10 0 0 0 16 16 168 + 16t bytes

10 100 20 20 0 10 20 20 20 16 0 236 bytes

[1,13] are 3jNj = 270 bytes and 48 bytes, respectively, which are all reasonable for VANET according to [3]. Moreover, the number of steps is another important character to measure the communication cost. Suppose that there are J(1 < J 6 N) payments processed in a payment phase, the number of steps for protocol in [1,13] are 6J and 6J + 2, respectively, while that of our proposal is 2J + 6, which is notably less than the previous. By the above comparisons, we can find that the more payments needed in a payment transaction, the more advantages our protocol has in terms of performance. Therefore, we can conclude that our mobile payment protocol is suitable for session-based applications in restricted connectivity scenarios of VANET.

6. Conclusion In this paper, we proposed an electronic payment protocol for data volume transaction in a restricted connectivity scenario of VANETs where the vehicle could not directly communicate with the bank. As a result, the authentication messages from vehicle to bank must be transmitted through merchant while keeping the messages private. The proposed protocol employs self-certified key agreement to establish the shared key between two participants without additional message exchanges which result in efficient symmetric encryption. Therefore, the communication and computation cost are reduced. The properties such as fair exchange, user anonymity and payment security are satisfied in the proposed protocol. Moreover, the protocol can be used in both data volume transferred based and one-time event based application. At last, we expect that our protocol can provide a viable trading architecture for the future value-added applications in vehicular ad hoc networks.


Acknowledgements This work is supported by National Natural Science Foundation of China (Grant Nos. 61170270, 61100203, 60873191, 60903152, 61003286, 60821001), the Fundamental Research Funds for the Central Universities (Grant Nos. BUPT2011YB01, BUPT2011RC0505). References [1] J.T. Isaac, J.S. Camara, S. Zeadally, J.T. Marquez, A secure vehicle-to-roadside communication payment protocol in vehicular ad hoc networks, Computer Communications 31 (10) (2008) 2478–2484. [2] Vehicle Safety Communications Consortium, Vehicle Safety Communications Project Task 3 Final Report, 2005. [3] P. Lin, H.Y. Chen, Y.G. Fang, J.Y. Jeng, F.S. Lu, A secure mobile electronic payment architecture platform for wireless mobile networks, IEEE Transactions on Wireless Communications 7 (7) (2008) 2705–2713. [4] A.K.K. Aboobaker, Performance analysis of authentication protocols in vehicular ad hoc networks, Information Security at Royal Holloway, University of London, 2010. [5] S. Lin, D. Liu, An incentive-based electronic payment scheme for digital content transactions over the Internet, Journal of Network and Computer Applications 32 (3) (2009) 589–598. [6] J. Claessens, B. Preneel, J. Vandewalle, Anonymity controlled electronic payment systems, in: Proceedings of the 20th Symposium on Information Theory in the Benelux, Haasrode, 1999, pp. 27–28. [7] S. Chari, P. Kermani, S. Smith, R. Tassiulas, Security issues in m-commerce: a usage-based taxonomy, E-Commerce Agents (2001) 264–282. [8] X. Dai, J. Grundy, NetPay: An off-line, decentralized micro-payment system for thin-client applications, Electronic Commerce Research and Applications 6 (1) (2007) 91–101. [9] M. Lee, G. Ahn, J. Kim, J. Park, B. Lee, K. Kim, H. Lee, Design and implementation of an efficient fair off-line e-cash system based on elliptic curve discrete logarithm problem, Journal of Communications and Networks 4 (2) (2002) 81– 89.

195

[10] J.H. Yang, C.C. Chang, A low computational-cost electronic payment scheme for mobile commerce with large-scale mobile users, Wireless Personal Communications (2010) 1–17. [11] J. Téllez, J. Sierra, A secure payment protocol for restricted connectivity scenarios in M-commerce, in: Proceedings of EC-Web’ 2007, 2007, pp. 1–10. [12] J. Téllez, J. Sierra, An anonymous account-based mobile payment protocol for a restricted connectivity scenario, in: 18th International Conference on Database and Expert Systems Applications, 2007, pp. 688–692. [13] J. Téllez, S. Zeadally, J. Sierra, Implementation and performance evaluation of a payment protocol for vehicular ad hoc networks, Electronic Commerce Research 10 (2) (2010) 209–233. [14] P.S.L.M. Barreto, H.Y. Kim, B. Lynn, M. Scott, Efficient algorithms for pairingbased cryptosystems, in: Proceedings of the 22nd Annual International Cryptology Conference on Advances in Cryptology, 2002, 354–368. [15] F.G. Li, X.J. Xin, Y.P. Hu, Identity-based broadcast signcryption, Computer Standards & Interfaces 30 (1–2) (2008) 89–94. [16] M. Girault, Self-certified public keys, in: Advances in Cryptology, Eurocrypt’91, 1991, pp. 491–497. [17] H. Petersen, P. Horster, D.P. Horster, Self-certified keys-concepts and applications, in: Proceeding Communications and Multimedia Security’97, 1997, pp. 102–116. [18] S. Saeednia, Identity-based and self-certified key-exchange protocols, Information Security and Privacy (1997) 303–313. [19] D. McKitterick, J. Dowling, State of the Art Review of Mobile Payment Technology (2003). [20] M. Hassinen, K. Hyppönen, E. Trichina, Utilizing national public-key infrastructure in mobile payment systems, Electronic Commerce Research & Applications 7 (2) (2008) 214–231. [21] H. Wang, H.Q. Guo, Fair payment protocols for e-commerce, IFIP International Federation for Information Processing (2004) 227–245. [22] G. Davida, Y. Frankel, Y. Tsiounis, M. Yung, Anonymity Control in E-Cash Systems, in: Proceedings of the First International Conference on Financial Cryptography, 1997, pp. 1–16. [23] R.L. Rivest, A. Shamir, PayWord and MicroMint: two simple micropayment schemes, in: Proceedings of the International Workshop on Security Protocols, 1997, pp. 69–87. [24] N. Koblitz, A. Menezes, S. Vanstone, The state of elliptic curve cryptography, Designs, Codes and Cryptography 19 (2–3) (2000) 173–193.