Proceedings of the International Conference on Computer and Communication Engineering 2008 May 13-15, 2008 Kuala Lumpur, Malaysia
A Lightweight and Private Mobile Payment Protocol by Using Mobile Network Operator Tan Soo Fun, Leau Yu Beng, Jonathan Likoh, Rozaini Roslan School of Informatics Science, Universiti Malaysia Sabah, Malaysia
[email protected] to wireless networks [14,7,8,2]. Some of them are keep information about the engaging parties’ credit card is either stored on their mobile devices or used in the transaction without protection, which makes it vulnerable to attack [9,7,8]. Furthermore, some mobile payment protocol design schemes are not concerned about the customer privacy issues [14,9,7,8]. The customer privacy such as customer identity and transaction details is revealed not only to merchant, but also to the payment gateway and the banks [3]. By addressing these problems, the research aim is to create a secure lightweight mobile payment protocol by using mobile network operator which employs symmetric key operations that enables protect payer’s privacy, ensures end-to-end security properties, provides accountability and satisfies engaging parties’ security requirements. The rest of this paper is organized as follows. Some existing mobile payment protocols are briefly explained in section II. Section III detail our new protocol for mobile payment and followed by its preliminary result in section IV. Finally, section V concludes this work and presents future work.
Abstract Mobile commerce is undoubtedly become an omnipresent and active area in electronic payments. It allows mobile user to purchase things, pay bills or make a bet via mobile phone when on the move, anywhere and at any time. Unfortunately, several challenges in accountability and privacy properties have emerged with the widespread of m-commerce in recent years. Consequently, many public-key cryptography based mobile payment protocol have been proposed. However, limited capabilities of mobile devices and wireless networks make these protocols are not suitable for mobile network. In this paper, we propose a secure mobile payment protocol which involves mobile network operators (MNO) by employing symmetric key operations. The symmetric cryptographic technique applied to our proposed protocol not only minimizes the computational operations and communication passes between the involved parties, but also has achieves a completely privacy protection for the payer and satisfies all the criteria of end-to-end security property and party’s requirement including non-repudiation. The future work will concentrate on improving the verification solution to support mobile user authentication and authorization for mobile payment transactions.
II. RELATEDWORK In this section, several existing payment protocols will be delved. In general, these payment protocols composed of four engaging parties, which including protocols composed of four engaging parties, which are including client (C), merchant (M), issuer (client’s financial institution) and acquire (merchant’s financial institution. Both issuer and acquire are presented by payment gateway (PG) which acts as medium between them and both client and merchant for clearing purpose. There are three primitive payment transactions occurred within these payment protocol, payment (which made by client about payment to merchant), value subtraction (which made by client in order to request issuers or payment gateway to deduct requested money amount from client’s account) and value claim (which made by merchant in order to request acquirer or payment gateway to transfer request money amount
I. INTRODUCTION Mobile payment is defined as any transaction that is carried out via mobile device, involves either direct or indirect exchange of monetary values between parties [5,13,6]. An interesting aspect about mobile payments is that mobile phone can be used as payment device for all types of payment situations. Optimists are of the opinion that the new world economy will witness the transition of mobile devices from a simple communication device to a payments mechanism [10]. Currently, several mobile payment protocols were proposed, however, most of them are based on public key infrastructure (PKI) which is not efficiently applied
978-1-4244-1692-9/08/$25.00 ©2008 IEEE
162
Xi. The client also shared secret Yi with issuer and secret Zj is shared between merchant and payment gateway.
into merchant’s account) [1]. Their high-level protocol steps are shown as below:C→M: Payment Request, Value Subtraction Request M→PG: Value Subtraction Request, Value Claim Request PG→M: Value Claim Response, Value Subtraction Response M→C: Payment Response, Value Subtraction Response
III. PROPOSED PROTOCOL The proposed mobile payment protocol is composed of four engaging parties, which also called as principals. They are payer, payee, payer’s MNO and payee’s MNO. The proposed protocol is working well with the assurance secret Xi, where i = 1,…,n is only shared between payer and payer’s MNO and secret Yj , where j = 1,…,n is only shared between payee and payee’s MNO. The following symbols are used in proposed mobile payment protocol:-
A. Secure Electronic Transaction (SET) protocol The SET protocol is the well-known credit card payment protocol, which consists of request/response message pairs. All parties engaging in SET payment protocol are required to obtain public key certificates. The SET protocol consists of five transaction steps, which is payment initialization, purchase order, authorization, capture payment and card inquiry phase [8,11,4].
TABLE 1: NOTATIONS
Symbol PNPayer PINPayer
B. Internet Key protocol (iKP) The iKP protocols are based on public key cryptography and differ from each other based on the number of parties those posses their own public key pairs. This number indicated by the name of the individual protocols: 1KP, 2KP and 3KP. The greater number of parties that hold public-key pairs, the greater the level of security provided. The engaging parties of iKP are including customer, merchant and payment gateway (acquirer) [8,11,2].
IDPayer
AIPayer
PNPayee PINPayee
C. Tellez J. et al.’s anonymous payment protocol Tellez J. et al. [14] proposed anonymous payment protocols based on client centric model, which employs a digital signature scheme with message recovery using self-certified public keys. It consists of five engaging parties, which including client, merchant, acquirer, issuer and payment gateway. This payment protocol also consists of two-sub protocols, which are merchant registration protocol and payment protocol.
IDPayee
AIPayee
D. Kungpisdan’s et al.’s mobile payment protocol
NONCE
Kungpisdan S. et al. [9] proposed a secure account based mobile payment protocol that employs symmetric key operations which require lower computation at all engaging parties. In general, there are five parties involved in this protocol, which are client, merchant, issuer, acquirer and payment gateway. Kungpisdan S. et al.’s protocol is composed of two-sub protocols, which is merchant registration protocol and payment protocol. Before starts making payment, client is required register with merchant by running merchant registration protocol. After completion of registration protocol, client and merchant share a set of secret key
RPayer
DATE AMOUNT DESC
163
Description Payer Phone Number Payer selected password identification number Payer ID, which identifies payer to mobile network operator(MNO); computed as IDPayer = PNPayer + H(PNPayer, PINPayer) Payer’s Account Information, which including credit limit for each transaction, type of account (post-paid or prepaid account) Payee Phone Number Payee selected password identification number Payee ID, which identifies payee to mobile network operator ; computed as IDPayee = PNPayee + H(PNPayee, PINPayee) Payee’s Account Information, which including credit limit for each transaction, type of account (post-paid or prepaid account) Random Number and timestamp generated to protect against replay attack, that is ensure old communication cannot reused in replay attack. Random Number Generated by Payer act as payer’s pseudo-ID, which uniquely identifies Payer to Payee Date of payment execution Payment Transaction Amount Payment Description, which may includes delivery address,
TIDReq PayeeIDReq {M}X Symbol H(X) i j KP-P Success/Failed Accept/Reject Received
Payer’s MNO decrypts message with shared session key, K1 to retrieve payer’s information. Payer’s MNO stores required information into their database. If registration process is successful, payer’s MNO sends confirmation message to inform payer. The confirmation message is encrypted with the session key K1. Payer’s MNO→Payer: {Success/ Failed}K1 After registration process, payer receives mobile wallet application through email or downloading from payer’s MNO site. The mobile wallet application contains symmetric key generation and payment software. After success installed, a set of symmetric key Xi {X1, X2,…, Xn } is generated and store into payer’s mobile devices. Meanwhile, the payer’s MNO also computes the symmetric key Xi {X1, X2,…, Xn} and store into their database. Similarly, payee must go through the similar registration process with his/her MNO that enable his/her to receive payment from payer. The payee generates a set of symmetric key Yj {Y1, Y2,…..Yn} with payee’s MNO and store into his/her terminal and MNO database. The payment protocol is based on Credit Push Model, which the transaction flow is completely controlled by the Payer. The payment protocol consists of seven phases as illustrates in Figure 1.
purchase order details and so on. Payer will include only the information that he/she wish to disclosure to Payee. The request for transaction ID The request for ID payee. The message M symmetrically encrypted with symmetric key X. Description The one way hash function of the message X Used to identify the current session key of Xi Used to identify the current session key of Yj The secret key shared between Payer’s MNO and Payee’s MNO. The registration status, whether the registration is success or failed The payment transaction request status, whether is accepted or rejected by MNO Payment receivable update status, which may includes the received payment amount
The proposed mobile payment protocol consists of two-sub protocols, which are registration protocol and payment protocol. Both payer and payee are required to register with their own mobile network operator (MNO) before any transaction could take place. Payer and payer’s MNO generate session key, K1 by running Diffie-Hellman Key Agreement protocol. Then payer sends registration details such as account information, payer identity and phone number, encrypted with session key K1 to payer’s MNO. Payer→Payer’s MNO: {PNPayer, IDPayer, AIpayer }K1 During the registration process, payer is required to set his/her password identification number, PINpayer, for later access to his/her mobile wallet application. This implementation uses of two-factor authentication, that is an important principle for physical and mobile devices access control [12]. The two-factor authentication applies two means to authenticate users to access the mobile wallet system, that is mobile device with mobile wallet application (something she/he has) and password (something she/he know only). Then the IDpayer, is computed by hashing the PNPayer and PINpayer . IDPayer = PNPayer + H (PNPayer, PINPayer )
Figure 1. Proposed mobile payment protocol
Phase 1 : Payment Initialization Payer→Payee: RPayer , TIDReq , PayeeIDReq Payee→Payer: {IDPayee, TID, IDMNO } K2 Phase 2 : Payment Subtraction Request Payer→Payer’s MNO: {IDPayee, IDMNO,RPayer, TID, AMOUNT, DATE, NONCE, H(IDPayee, IDMNO, RPayer, TID, AMOUNT, DATE, NONCE), {RPayer, DESC }K2 }Xi , i, IDpayer Payer’s MNO→TCS: H[{IDPayee, IDMNO, RPayer, TID, AMOUNT, DATE, NONCE, H(IDPayee, IDMNO,
164
IV. PRELIMINARY RESULT
RPayer, TID, AMOUNT, DATE, NONCE), {RPayer, DESC}K2 }Xi, i, IDpayer ] TCS→Payer’s MNO: TimeStamp1 Phase 3 : Payment Authorization Request Payer’s MNO→Payee’s MNO: RPayer, IDPayee, TID, AMOUNT, DATE, {RPayer, DESC}K2 Phase 4 : Payment Confirmation Request Payee’s MNO→Payee: {RPayer, TID, AMOUNT, DATE, {RPayer, DESC}K2, NONCE, H(RPayer, TID, AMOUNT, DATE {RPayer, DESC}K2, NONCE), H(KP-P )}Yj , j Phase 5 : Payment Confirmation Response Payee→Payee’s MNO: {Accept/Reject, NONCE, H(KP-P), H(RPayer, TID, AMOUNT, DATE, {RPayer, NONCE), {Accept/Reject, TID, DESC}K2, AMOUNT, DATE }K2}Yj +1 Phase 6 : Payment Authorization Response Payee’s MNO→TCS: H({Accept/Reject, NONCE, H(KP-P), H(RPayer, TID, AMOUNT, DATE, {RPayer, NONCE), {Accept/Reject, TID, DESC}K2, AMOUNT, DATE } K2}Yj +1) TCS→Payee’s MNO: TimeStamp2 Payee’s MNO→Payer’s MNO: Accept/Reject, TID, AMOUNT, DATE, {Accept/Reject, TID, AMOUNT, DATE} K2 Phase 7: Payment Subtraction Response /Payment Receivable Updates Payer’s MNO→Payer: {Accept/Reject, NONCE, H(KP-P), H(IDPayee, IDMNO, RPayer, TID, AMOUNT, DATE, NONCE), {Accept/Reject, TID, AMOUNT, DATE} K2}Xi+1 Payee’s MNO→Payee: {Received NONCE, H(KPP), H(RPayer, TID, AMOUNT, DATE, {RPayer, DESC}K2, NONCE) }Yj+1
In this section, the proposed mobile payment protocol is compared with three existing payment protocols. We are focusing on their performance in terms of the numbers of cryptographic operations at each party. The category of cryptographic operations is based on [9]. Table 2 demonstrates the numbers of cryptographic operations at involved parties of each protocol. TABLE 2: COMPARISON OF CRYPTOGRAPHIC OPERATIONS
Cryptographic Operations Public-Key SET Encryptions iKP Kungpisdan Proposed Public-Key SET Decryptions iKP Kungpisdan Proposed Signature SET Generations iKP Kungpisdan Proposed Signature SET Verifications iKP Kungpisdan Proposed Symmetric SET Key iKP encryptions/ Kungpisdan decryptions Proposed Hash SET Functions iKP Kungpisdan Proposed Keyed-hash SET Functions iKP Kungpisdan Proposed
If all the transaction processes are successfully completed, payee will release or deliver the purchased goods or services to payer. To prevent replay of the secret key from payer and payee, both payer’s MNO and payee’s MNO make sure that the symmetric key Xi and Yi have not been used before proceed the payment transaction. The MNO will maintain a list of generated secret key by discarding used or expired symmetric key Xi and Yi from the list. If symmetric key Xi and Yi were compromised, there must be revoked. Both payer and payee may receive an update notification from MNO when their key was expired. To update their secret key, they may connect to their MNO to generate a new session key, K1 by running Diffie-Hellman Agreement protocol. Then, offline generates a new set of secret key Xi and Yi with a new session key K1.
Payer
Payee
PG
1 1 1 1 2 3 2 4 5 3 2 2 2 2 -
1 1 3 1 2 2 5 6 2 4 1 1 2 -
1 2 1 1 1 1 2 1 2 1 1 -
The result of comparison on cryptographic operations revealed that the proposed mobile payment has reduced the number of cryptographic operations applied to the existing payment protocol. Both SET and iKP protocols employ the PKI infrastructure, their users are required to perform public key encryption and signature verification which are high computational task. Compared with Kungpisdan et al. protocol, the proposed mobile payment protocol did not apply
165
[3]
keyed-hash functions, but only employs the symmetric key encryption and hash function which further lower the computation works. Furthermore, both payer and payee are interacting directly with their own MNO without any trusted third party or payment gateway. It reduces the communication passes between engaging parties and ensures their confidential information is not compromised. In the nutshell, the proposed mobile payment protocol has improved the performance of existing payment protocol by reducing the number of cryptographic operations.
[4] [5]
[6] [7] [8] [9]
V. CONCLUSION AND FUTURE WORK Our aim is to propose a lightweight mobile payment protocol by using MNO. Due to the time constraint, our work only serves to demonstrate a preliminary result in comparing the proposed protocol operations with other existing mobile payment protocols. We will further conduct an evaluation and justification in order to analyze in detail the privacy of engaging parties for mobile payment transaction.
[10] [11] [12] [13]
REFERENCES [1] [2]
[14]
Abad-Peiro J. L., Asokan N., Steiner M. & Waidner M, “Designing a generic payment service”, IBM System Research Journal, Vol.37(1), 1998, Pp. 72-88. Bellare, M., Garay, J., Hauser, R., Herzberg, A., Steiner, M., Tsudik, G., Van Herreweghen, E., and Waidner, M, “Design,Implementation, and Deployment of the iKP Secure Electronic Payment system”, IEEE Journal of Selected Areas in Communications, 2000, pp. 611-627.
166
C. Wang & H-f. Leung, “A Private and Efficient Mobile Payment Protocol”, London: Springer-Verlag, LNAI, 2005, pp.1030-1035. http://www.setco.org/set_specifications.html Jun Liu, Jianxin Liao, Xiaomin Zhu, “A System Model and Protocol for Mobile Payment”, Proceedings of the IEEE International Conference on e-Business Engineering (ICEBE’05), 2005. Krueger, M, The future of M-Payments–business options and policy issues, Seville. Spain, 2001. Kungpisdan, S., Srinivasan, B., and Phu Dung, L, “Lightweight Mobile Credit-Card Payment Protocol”, Berlin Heidelberg: Springer –Verlag, 2003a, pp. 295-308. Kungpisdan, S., Srinivasan, B., and Phu Dung, L., “A Practical Framework for MobileSET Payment”, Proceedings of International E-Society Conference, 2003b, pp. 321-328. Kungpisdan S., Srinivasan B., and Phu Dung Le, “A Secure Account-based Mobile Payment Protocol”, Proceedings of the International Conference on Information Technology: Coding and Computing, Vol. 1, Las Vegas, USA, 2004a, pp. 35-39. M. Ding and C. Unnithan, Mobile Payments (mPayments) -An Exploratory Study of Emerging Issues and Future Trends, Deakin University, 2002. Mohony D.O., Peirce M. and Tewari Histesh, Electronic Payment Systems for E-Commerce, Artech House, United States of America, 2001. Panko R. R, Corporate Computer and Network Security, Prentice Hall, Upper Saddle River, New Jersey, 2004. Pousttchi, K, “Conditions for Acceptance and Usage of Mobile Payment Procedures”, Proceedings of the MBusiness Conference, 2003. Tellez J. & Sierra J, “Anonymous Payment in a Client Centric Model for Digital Ecosystem”, IEEE DEST, 2007, pp. 422-427.
