2013 Seventh International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing
Using a stored-value card to provide an added-value service of payment protocol in VANET Chin-Ling Chen Chaoyang University of Technology Department of Computer Science and Information Engineering Taichung City, Taiwan (R.O.C.)
[email protected]
Wei-Chen Tsai Chaoyang University of Technology Department of Computer Science and Information Engineering Taichung City, Taiwan (R.O.C.)
[email protected] cryptography can provide message confidentiality, and provide the authentication of participants for e-payment scheme. Moreover, symmetric-key operations need not high computational cost nor do they require additional communication steps. In this paper, the Services Provider (SP) provides the added-value services for user. The user can use a stored-value card and select added-value services through On-Board Unit (OBU). And then, the Services Provider processes the transaction message and sends it to the Payment Gateway (PG). The Payment Gateway will forward the transaction message between the Services Provider and the Issuer. The proposed scheme must be able to achieve the following requirements [1], [5], [7], [8], [11] such that the proposed scheme can be applied in real world. (1) Double spending: The digital cash cannot be copied and reused. Then we have to minimize the risk of forgery and establish an authenticity system. (2) Unforgeability: Only authorized parties (i.e. the bank or the Issuer) can produce the stored-value card and added value. (3) Non-repudiation: Everyone should sign each transaction as proof of the integrity and origin of data. (4) Anonymity: The user must remain anonymous in each transaction. (5) Recoverable: If the user loses his or her stored-value card, he or she can recover his or her card. The remainder of this paper is organized as follows. Section 2 presents our proposed scheme. Sections 3 present the security analysis. Finally, the conclusion is offered in Section 4.
Abstract—With the rapid development of the Internet applications, added-value service is widely used in the Internet. The added-value service provides different kind of services for users. In this paper, we propose a stored-value card to provide an added-value service of payment protocol in VANET. When the user wants to use the added-value service, the service provider verifies the request and sends it to the payment gateway. And then, the payment gateway will forward the transaction message to the Issuer and Acquirer to process it. In our scheme, we use symmetric cryptography and digital signature to solve the security problem of payment scheme in VANET. Our scheme achieves protection against double-spending, unforgeability, non-repudiation, anonymity and the recovery issue. Keywords-added-value service; stored-value card; VANET; cryptanalysis; payment gateway
I. INTRODUCTION With the rapid development of the Internet applications, people can use the Internet to deal with transactions. The added-value service [13] is provided different kind of services for users. Added-value services is used to refer to options that complement but a core service offering from a services provider but are not as vital, necessary or important. Added-value applications in VANET, which improve user comfort and offer great business opportunities, attract more and more attention in daily life. Most of applications come with the emergence of electronic trading. The stored-value card [2], [4] is a kind of smartcard that can store monetary value. It is used in a wide range of applications in micropayment environment. It freely adds value into stored-value card. Now, it is usually applied to provide added-value service for micropayments [3], [10]. In the Vehicular ad hoc networks (VANET), VANET is envisioned to support the development of a wide range of attractive applications such as payment services [12]. To enable payments in VANETs, it is necessary to build payment systems that satisfy the additional requirements associated with VANET [6], [9]. Therefore, we design a using a stored-value card to provide an added-value service of payment protocol in VANET. In our scheme, we exploit symmetric cryptography to satisfy the security of the communication. In each transaction, sender must sign the transaction message, and receiver will verify if the signature is true. Symmetric 978-0-7695-4974-3/13 $26.00 © 2013 IEEE DOI 10.1109/IMIS.2013.119
II.
THE PROPSED SCHEME
There are five participants involved in the proposed scheme. (1) Services Provider (SP): The services provider is an organization that provides some kind of value-added services. (2) User (U): The user makes a request to services provider. (3) Vehicular (V): The vehicular denotes a car or transportation. (4) Issuer (I): The issuer is the user’s financial institution and issues stored-value card. (5) On-Board Unit (OBU): An OBU is a device which is installed into a seat in car. 660
9 1 2
User
Issuer AVM 5
6
4 3 8
Services Provider
7
OBU
1
Payment Gateway
Vehicular 7
: secure channel Acquier
: insecure channel
Fig. 1 Overview of the proposed architecture (6)
Added-Value Machine (AVM): The AVM is an intelligent equipment to provide self-served added value services. (7) Payment Gateway (PG): The payment gateway is an e-commerce application service provider between the acquirer and the issuer bank on the private network. (8) Acquirer (A): The acquirer is the services provider’s financial institution. Step 1: U ↔ I: The User registers a new stored-value card with the Issuer. The Issuer creates an account for the user and returns stored-value card to user. SP ↔ A: The Services Provider registers an account with the Acquirer. The Acquirer creates an account and returns a certificate to the services provider. Step 2: P ↔ I: When the User wants to add value into the stored-value card via the AVM, the AVM will forward the encrypted transaction message to the Issuer. The Issuer will decrypt the message and
Step 3:
Step 4:
Step 5:
Step 6:
Step 7:
661
verify the stored-value card is legal or not. Finally, the AVM adds value in the card. V→SP: When the User wants to use the addedvalue service, the User has to use OBU to select an added-value service. And, OBU sends the request to the Services Provider. SP→PG: Upon receiving the request message from OBU, the Services Provider will check the transaction information and forward the payment message to the Payment Gateway. PG→I: After receiving the payment message from Services Provider, the Payment Gateway will forward the payment message to the Issuer to authenticate through private network. I→PG: The Issuer checks the transaction information and deducts the price from the User’s account. And then, the Issuer sends the confirmation message to the Payment Gateway. PG→SP: When the Payment Gateway receiving the confirmation message from the Issuer, the
Step 8:
Step 9:
Payment Gateway will forward the confirmation message to the Services Provider. PG→A: The Payment gateway sends the transaction information to the Acquirer. Upon receiving the message, the Acquirer will store the price to the Services Provider's account. SP→V: After receiving the confirm message, the Services Provider supplies the added-value service to the User. U ↔ I: If the User lost his/her stored-value card, the User can send the recovering request to the Issuer. After receiving the request, the Issuer verifies if the User is legal. If the user is legal, the Issuer will send the new stored-value card to the user according to the User’s account.
secure channel. (2) After receiving the registration message, the Issuer computes (1) P = h(IDU ⊕ x ) and generates value C and SN . Then computes
v = h(P ⊕ SN ⊕ IDI ) (2) stores IDU , valueC and v in the database, and stores IDU , valueC in the stored-valued card. Finally, the I sends the stored-value card and SN to the User. 2) The Services Provider registers with the Acquirer In this phase, the Services Provider registers with Acquirer, and Acquirer will store each transaction data to Services Provider's account. The Acquirer creates an account for Services Provider and sends a registration certificate to Services Provider. The statements are described as follows: (1) The Services Provider chooses a random number n and sends (IDSP , n ) to Acquirer via a secure channel. (2) After receiving the registration message, the Acquirer computes (3) Cert A = S A (IDSP , n ) Finally, the Acquirer sends the registration certificate Cert A to the Services Provider and stores Cert A , IDSP in the database. (3) Once receiving the registration certificate, the Services Provider verifies the certificate using the Acquirer's public key (4) V A (Cert A ) ? (IDSP , n ) If Eq. (4) holds, the Services Provider stores it in the database.
The following notation is used in the proposed scheme: : the identity of x ID x : the serial number of the stored-value SN card generated by Issuer, it is unique and user can change it freely : the permanent secret parameter of Issuer x Cert x : the certificate generated by x : the nonce generated by x Nx : the timestamp generated by x Tx SK A_B : the session key between A and B value C : the current stored value of the stored-
value card value add : the amount which the passenger wants
to add to the stored-value card msg conf : the confirmation message
TN OI
[ ]
B. The added-value phase In this phase, when the User wants to add value to stored-value card, the User must store value into storedvalue card through AVM. The User sends the added-value message to the Issuer via AVM, and then the AVM forwards the encrypted message to the Issuer. After receiving the message, the Issuer verifies the User and stores the amount in the stored-value card. Finally, the Issuer returns the confirmation message to the User. The scenario is described as follows: (1) The User enters SN and valueadd , then encrypts the message (5) CU1 = ESKU _ I (SN , valueC )
: the transaction number : the order information (OI=(service, price, time)), where service is some of service from Service Provider, price is the fee of the service, and time is the current time
[ ] : using the symmetric key K to encrypt/ decrypt the message M
EK M / DK M
( )
( ) : using the X’s private/public key
S X M /VX M
h (⋅) ⊕ A? B
to sign/ verify the message M : determine A if equal to B : bitwise exclusive operation : determines if A is equal to B
and makes a signature Sig U 1
SigU 1 = SU (IDU , valueC , valueadd ) (6)
A. The registration phase
(
1) The User registers with the Issuer In this phase, the User registers a stored-value card from the Issuer. The Issuer creates an account for User. The steps are described as follows: (1) The User sends IDU to register with Issuer via a
Finally, the User sends IDU , CU1 , value add , Sig P1 , TU (2)
662
)
to the AVM. After receiving the transaction message, the AVM checks if the User's cash is valid or not and checks
(3)
d = h(OI , IDV , TV )
valueadd is correct. Finally, the AVM forwards this message to Issuer. Once receiving the message, the Issuer checks if the timestamp T U is in a valid time. Then, the Issuer decrypts CU1
(SN , valueC , valueadd ) = DSK
U _I
(CU ) (7)
(
(2)
If Eq. (9) holds, the User is a legal user. Next, the Issuer checks valueC , if valueC is right in the database, it proofs valueC is not tampered. And then,
)
If Eq. (10) holds, it computes (11) valueC = valueC + valueadd and makes a confirmation message msg conf and a
(
(5)
(12)
(18)
2
)
SP _ I
(
(20)
1
) (21)
and makes a signature Sig SP1
(
the AVM. Upon receiving the confirmation message, the AVM writes valueC into the stored-value card and forwards the message Sig I1 , valueC to the User.
Sig SP = S SP CV1 , OI
)
(3)
The User verifies if the signature Sig I 1 is valid or not VI ( Sig I1 ) ? (valueC )
(CV )
If Eq. (20) holds, the Service Provider encrypts C SP = E SK CV , IDV , d ,OI ,Cert A ,TN
Finally, the Issuer sends Sig I1 , valueC , msg conf to
(
U _I
VU SigV1 ?(IDV ,OI )
signature Sig I1
(4)
After receiving the message, the Services Provider checks if the timestamp T V is in a valid time. And then, it decrypts CV2 checks if OI is supported by the server. The Services Provider generates TN and computes (19) d = h(TN ⊕ OI ) verifies the signature SigV1
VU SigU1 ? (IDU ,valueC , value add ) (10)
)
(17)
)
(IDV , OI ) = DSK
the Issuer verifies the signature Sig U 1
(
(16)
Finally, the Vehicular sends the message CV1 , CV2 , Sig V1 , TV to the Services Provider.
(9)
Sig I1 = S I (valueC )
And then, the User encrypts CV1 = ESKV _ I (IDU , SN , valueC ) CV2 = E SKV _ SP (IDV , OI )
(8)
h(P ′ ⊕ SN ⊕ IDI ) ? v
(
(15)
1
and computes P′ = h(IDU ⊕ x )
(14)
makes a signature SigV1 = SU (IDV , OI )
(13)
If Eq. (13) does not hold, the User can request the Issuer to check and resend the message.
(4)
)
Finally, the SP sends the message (C SP , Sig SP ,TSP ) to the Payment Gateway. Upon receiving the message, the Payment Gateway checks if the timestamp T SP is in a valid time and forwards the transaction message (CSP , Sig SP ) to the Issuer via private network. Once receiving the message, the Issuer decrypts C SP1
(CV , IDV , d , OI , Cert A ,TN ) = DSK 1
C. The payment phase In this phase, when the User want to use added-value services at anywhere, the User can communicate with services provider through OBU and the Issuer will check the transaction in time. The User selects the added-value services and sends order information to the Services Provider. The Services Provider checks if the order information is supported or not and sends this transaction information to the Payment Gateway. The Payment Gateway forwards the data to the Issuer via private network. The Issuer verifies the transaction and sends the confirmation message to the Acquirer and Services Provider. Then, the Acquirer stores amount of added-value services to Service Provider's account. Finally, the User can obtain the services from the Services Provider. The scenario is described as follows: (1) The Vehicular enters SN and selects OI = (service, price, time) and computes
(22)
SP _ I
(CSP )
(23)
Next, the Issuer checks d, if d has the same parameter in the database, this transaction will be rejected because the User has double-spending; otherwise, it stores d and TN in the database. And then, it verifies the signature Sig SP (24) VSP (Sig SP ) ? CV1 , OI
(
)
If Eq. (24) holds, it decrypts CV1
(IDU , SN , valueC , d ) = DSK
V _I
checks valueC
? ≥
price
(CV ) 1
(25) (26)
And then, it computes (27) P′ = h(IDU ⊕ x ) ′ h(P ⊕ SN ⊕ IDI ) ? V (28) If Eq. (28) holds, the User is a legal user. Afterwards, it computes
663
valueC = valueC − price (29) and updates to database. The Issuer makes a signature Sig I 2 Sig I 2 = S I (valueC )
and encrypts C I1 and C I 2
Finally, the Issuer sends a new stored-value card and SNNEW to the User. III.
(30)
( ) (IDV , OI , CI )
C I1 = E SKV _ I valueC , Sig I 2 ,TN
(31)
C I 2 = E SK SP _ I
(32)
1
In this section, we will analyze the security issues and determine whether it conforms to the above mentioned security requirements. A. Resists replay attack In our scheme, we use a timestamp to prevent a replay attack in added-value and payment phase. If an attacker wants to replay the used message, it will fail because sender includes the timestamps Tx in the message. After receiving the replay message, the receiver checks the validity of the timestamp. If it does not hold, receiver will terminate this transaction. Therefore, our scheme can prevent the replay attack.
Finally, the Issuer sends the message C I 2 , price, msg conf , Cert A to the Payment Gateway.
(
(5)
)
After receiving the message, the Payment Gateway forwards the message C I 2 to the Services Provider
(
)
and sends price, msg conf , Cert A to the Acquirer. (6)
(7)
When receiving the confirmation message, the Acquirer checks the certificate Cert A is stored in the database whether or not. If it is valid, the Acquirer will store price to Services Provider's account. Upon receiving the message, the Services Provider decrypts C I 2
(CI , IDV ,OI ) = DSK (CI ) SP _ I
1
B. Resists Double spending In our scheme, we can detect double spending if the User sends the same request more than once through an online authentication. In the payment phase, Services Provider generates an unique transaction number TN in each transaction and computes d = h(TN ⊕ OI ) . After receiving the message, the Issuer will check if d exists in the database, if it is true, the Services Provider will reject this request; otherwise, the Services Provider stores d in the database to detect double spending.
(33)
2
and sends service and the message C I1 to the Vehicular. (8) The Vehicular decrypts C I1
(valueC , Sig I ,TN ) = DSK (CI ) 2
V _I
1
C. Unforgeability In our scheme, because the amount of stored-value card only be generated by the Issuer, our scheme completes the unforgeability. Each e-cash must be generated and signed by the Issuer. After receiving the stored-value card, the User verifies if the signature was signed by the Issuer. If it holds, this e-cash is valid. Therefore, ours scheme offers unforgeability
(34)
and verifies the signature Sig I 2
(
)
VI Sig I 2 ? (value C )
(35)
If Eq. (35) holds, it completes this transaction; otherwise, the User can request the Issuer to check and resend the message.
D. Non-repudiation In our proposed scheme, we use the signature to achieve the non-repudiation such that it can constitute evidence in the transaction. When issuing the stored-value card to the User, the Issuer must provide the User with a signature. The User can then verify whether the e-cash is valid. Therefore, our scheme offers non-repudiation. The verifiable proofs of non-repudiation are shown in Table. 1.
D. The recovering phase In this phase, when the user lost his or her stored-value card, he or she can send the recovering request to the Issuer. First, the Issuer verifies the User’s legality, and then the Issuer can recover a new stored-value card and SN to the User. The scenario is described as follows: (1) The User sends (IDU , SN ) to the Issuer. (2) After receiving the message, the Issuer computes P′ = h(IDU ⊕ x ) (36) (37) h(P ′ ⊕ SN ⊕ IDI ) ? v If Eq. (37) holds, the User is a legal user. And then, it generates SN NEW and computes
E. Anonymity In our scheme, when the User uses the added-value services, the User remains anonymous for each transaction. In the payment phase, when the User sends the transaction message to the Services Provider, the Services Provider only knows the Vehicle's Identity IDV. It does not know the User's real identity, only the Issuer can decrypt CV1 to
(38) v NEW = h(P′ ⊕ SN NEW ⊕ IDI ) updates the database IDU , valueC and v NEW , and
stores
(IDU , valueC )
S ECURITY ANALYSIS
obtain the User's Identity IDU. So, our scheme offers anonymity.
in the stored-valued card.
664
Evidence
(IDU , CU , valueadd , Sig P ,TU ) 1
(C
1
(Sig I , valueC ) 1
V1
, CV2 , Sig V1 , TV
(CSP , Sig SP ,TSP )
(C
I1
, service
)
)
Table 1. The verifiable proofs of non-repudiation Evidence Evidence Evidence Verification Issuer Holder User
Issuer
Issuer
User Services Provider
Vehicular
(
)
VU SigU1 ? (IDU ,valueC , value add ) VI ( Sig I1 ) ? (valueC )
(
)
VU SigV1 ?(IDV ,OI )
(
Services Provider
Issuer
VSP (Sig SP ) ? CV1 , OI
Issuer
Vehicular
VI Sig I 2 ? (value C )
F. Recovery issue When the User loses their stored-value card, or the stored-value card cannot be used, the User can initiate the recovering phase through the Issuer. In the recovering phase, the Issuer has to support the recovering service for the User. The User then sends IDU and SN to the Issuer via a secure channel. When receiving the request, the Issuer will verify if the User is legal ( h(P ′ ⊕ SN ⊕ IDI ) ? v ) because the serial number SN only known by the User which is a registration certificate for the User. If it holds, the Issuer recovers a new stored-value card and sends it to the User. Our scheme therefore satisfies the recovery issue.
(
)
)
REFERENCES [1]
[2]
[3]
[4]
IV. CONCLUSION In this paper, we propose a stored-value card to provide an added-value service of payment protocol in VANET. The user can exploit the stored-value card to use addedvalue service from the service provider. Our scheme proposes a recovering mechanism when the user has lost the stored-value card, the user can perform the recovering process through the Issuer. We use symmetric cryptography and digital signature to offer the security of payment scheme in VANET. Moreover, our scheme can defend against replay attack and complete some of security requirements as follows: (1) Double spending (2) Unforgeability (3) Non-repudiation (4) Anonymity (5) Recovery issue Finally, we expect that our scheme can provide a convenient trading architecture for the added -value service in VANET. ACKNOWLEDGEMENTS
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
This research was supported by National Science Council, Taiwan, R.O.C., under contract number NSC101-2622-E324 -003 -CC3 and NSC 101-2221-E-324 -005-MY2.
[13]
665
Y. Chen, J. S. Chou, H. M. Sun, and M. H. Cho, “A novel electronic cash system with trustee-based anonymity revocation from pairing, Electronic Commerce Research and Applications,” Vol. 10, Issue. 6, pp. 673-682, 2011. E. K. Clemons, D. C. Croson, and B. W. Weber, “Reengineering money: the mondex stored value card and beyond,” International Journal of Electronic Commerce,Vol. 1,Issue. 2, pp. 5-31, 1996. X. Dai and J. Grundy, “NetPay: An off-line, decentralized micropayment system for thin-client applications, ” Electronic Commerce Research and Applications,Vol. 6, Issue. 1, pp. 91-101, 2007. Easycard Corporation, http://www.easycard.com.tw/english/easycard/index.asp , Access available 1/22/2013 Z. Eslami, and M. Talebi, ”A new untraceable off-line electronic cash system, Electronic Commerce Research and Applications,” Vol. 10, Issue. 1, pp. 59-66, 2011. J. T. Isaac, S. Zeadally, and J. S. Cámara, “A lightweight secure mobile Payment protocol for vehicular ad-hoc networks (VANETs),” Electronic Commerce Research, Vol. 12, Issue. 1, pp. 97-123, 2012. W. S. Juang, “An efficient and practical recoverable pre-paid offline e-cash scheme using bilinear pairings,” Journal of Systems and Software, Vol. 83 ,Issue. 4, pp. 638-645, 2010. S. Kremer, O. Markowitch, and J. Zhou, “An intensive survey of fair non-repudiation protocols, Computer Communications,“ Vol. 17, Issue. 1, pp. 1606-1621, 2002. W. Li, Q. Wen, Q. Su, and Z. Jin, “An efficient and secure mobile payment protocol for restricted connectivity scenarios in vehicular ad hoc network,” Computer Communications, Vol. 35, Issue. 2, pp. 188-195,2012. Micropayment Wikipedia, Access available http://en.wikipedia.org/wiki/Micropayment, 11/21/2012 M. Raya and J.-P. Hubaux, “The security of vehicular ad hoc networks,” Proceedings of the 3rd ACM workshop on Security of ad hoc and sensor networks(SASN '05 ), pp.11-21, 2005 P. G. Schierz, O. Schilke, and B. W. Wirtz, “Understanding consumer acceptance of mobile payment services: An empirical analysis,” Electronic Commerce Research and Applications, Vol. 9, Issue. 3, pp.209-216, 2010. Value-added service Wikipedia, http://en.wikipedia.org/wiki/Value-added_service , Access available 1/22/2013
