New mobile payment protocol: Mobile Pay Center Protocol 2 (MPCP2) By using new Key agreement protocol: VAM Mohammad Vahid Alizadeh Dizaj Computer Department Payame Noor University Tehran Iran
[email protected]
Reza Askari Moghaddam
Samad Momenebellah
Computer Department
Deputy Secretary of
Payame Noor University
TCI
Tehran Iran
[email protected]
Keywords—Mobile Network Operator, Mobile Payment Protocol, Key Agreement Protocol, Repudiation, Privacy Protection, Replay Attack.
I. INTRODUCTION Mobile payment is any transaction that is executed via mobile devices, involves either direct or indirect exchange of fiscal values between parties. An interesting aspect about mobile
Vahid Alizadeh-Askari Momenebellah
[email protected]
payment is that mobile phone can be used as payment device for all types of payment situations. Optimists believe that the new world economy will witness the transition of mobile devices from a simple communication device to a payments mechanism [4, 9, 10, 12, and 17]. Nowadays, many mobile payment protocols were presented; however, most of them are based on PKI (Public Key Infrastructure) which are inefficiently applied to wireless networks. Some of them are keeping information about the engaging parties' credit card on their mobile devices or used in transaction without protection, which makes it vulnerable to attack. Most of these payment protocols were designed to preserve the traditional flow of payment data (Client - seller - seller’s Bank), transaction which is carried out between client and seller. Therefore, it is vulnerable to attacks like transaction or balance modification by seller. Also it increases the user's risk which their credit or debit cards can be captured and used for accessing to customer's account illegally. Besides that, there is no notification to the client from the client’s bank after the successful transfer. The user has to check his/her balance after logging on to his/her bank’s website again [2,6,9,10,11,13,14,15,18, 19,20]. Additionally, design schemes of some mobile payment protocols are not worried about customer's privacy. Customer's privacy such as customer identity and transaction details are revealed not only to seller, but also to the payment gateway and the banks [3, 9, 10, 11, 14, 19]. In addition, it needs heavy computation for generating a shared session key with DiffieHellman key agreement protocol. It is not good for a mobile device with limited resources to do such a heavy computation for generating a shared session key. Besides that, in Diffi-Hellman If each of the
Abstract—Growing of wireless networks and popularity of mobile devices represents an incredible opportunity to empower them as a payment device. Unfortunately, some problems hindering the widespread acceptance of mobile payment for example: accountability properties, privacy protection, limitation of wireless networks and mobile devices. Recently, many public-key cryptography protocols have been presented for mobile payment. However, limited capabilities of mobile devices and wireless networks make these protocols unsuitable for mobile network. Moreover, these protocols were designed to preserve traditional flow of payment data, which is vulnerable to attack and increase the user’s risk. In this paper, we propose a private mobile payment protocol which is based on client centric model and works by employing symmetric key operations. The proposed mobile payment protocol not only minimizes the computational operations and communications between the engaging parties, but also achieves a completely privacy protection for the payer, avoid repudiating transaction from each of them and decrease risk of replay attacks. In according to limitation of wireless networks and mobile devices, this paper recommends VAM 1 key agreement protocol for generating shared session key between two parties instead of Diffie-Hellman.
1
Tehran Iran
Moghaddam-
12
978-1-4577-0253-2/11/$26.00 ©2011 IEEE
iKP protocols are based on public key cryptography. They are different from each other with number of principals that posses their own public key pairs. This number is indicated by the name of the individual protocols for example: 1KP, 2KP and 3KP. The greater number of principals that hold public key pairs, the greater the level of security it provided. Principals of iKP are customer, merchant and payment gateway (acquirer) [2, 10, and 14].
parties selects its private key as (pí1)/2, then the public parameter for that party would be (p –1). Hence, if the public parameter is (p–1), an intruder can safely assume that the private key is (pí1)/2. The private key (pí1)/2, is a weak key in this protocol [22, 23, 24, 25, 26, 27, 28]. In according to these problems, first one of these paper's objectives is to create a private mobile payment protocol. It involves mobile network operator which is employing symmetric key operations. The second one is recommending a new key agreement protocol for generating a shared session key between two parties with less computation than Diffie-Hellman. This protocol should generate a shared session key and should have fewer problems than Diffie-Hellman. this paper is organized as follows. Section I is introduction. Some existing mobile payment protocols are briefly explained in section II. DiffieHellman key agreement protocol is briefly explained in section III. Section IV is about details of both proposed protocols. Section V presents comparison on privacy protection, repudiating by digital sign and using compatible key agreement protocol with mobile devices among several existing mobile payment protocol regarding to proposed protocol. Finally section VI concludes this research.
C. KSL Payment Protocol SET payment protocol and iKP payment protocols are good payment protocols, which are executed successfully for e-commerce in fixed network like Internet [2]. However, Tellez et al. and Kungpisdan et al. argued that both payment protocols are unsuitable for mobile payment transactions via wireless network because of theirs heavy computational operations and communications between them [10]. Kungpisdan et al. enhanced SET and iKP payment protocols by reducing the number of principals who posses own public key pairs. All principals exclude client are required to have their own certificates. Therefore, client side’s computation is reduced. KSL payment protocol consists of two subprotocols, which are merchant registration protocol and payment protocol. Both client and issuer share Yi before they starts making payment. Client is required to register with merchant and share symmetric key Xi with merchant [9, 11, and 19].
II. RELATED MOBILE PAYMENT PROTOCOLS In this section, existing payment protocols will be explored. These payment protocols composed of five principals, client (C), merchant (M), issuer (client’s financial institution), acquire (merchant’s financial institution) and payment gateway (PG) which are a medium between them and client and merchant. Three primitive payment transactions that have occurred within these payment protocols are as below: 1) Payment: Client makes a payment 2) Subtraction: Client requests issuers or payment gateway to debit his account. 3) Value Claim: Merchant requests acquirer or payment gateway to credit transaction amount into its account [1, 21].
D. Tellez et al. Anonymous Payment Protocol Tellez et al. proposed anonymous payment protocols is based on client centric model. It employs a digital signature scheme with message recovery which uses self-certified public keys. It consists of five principals, which are client, merchant, acquirer, issuer and payment gateway. This payment protocol also consists of two-sub protocols, which are merchant registration protocol and payment protocol [19]. E. Kungpisdan et al.'s Mobile Payment Protocol Kungpisdan et al. suggested another secure account based mobile payment protocol to improve his KSL protocol. This payment protocol is employing symmetric key operations which require lower computation at all engaging parties. There are five principals involved in this protocol, which are client, merchant, issuer, acquirer and payment gateway. Kungpisdan et al.'s protocol includes twosub protocols, which is merchant registration protocol and payment protocol. Before payment, client is required to register with merchant by running merchant registration protocol. After completion of registration protocol, client and merchant share a set of secret key Xi. The client also shared secret Yi with issuer and secret Zj is
A. Secure Electronic Transaction (SET) Protocol This protocol is the most famous credit card payment protocol, which consists of request/response message pairs. All principals in SET payment protocol are required to acquire public key certificates. SET protocol's transaction consists of five steps, payment initialization, purchase order, authorization, and capture payment at the end card inquiry phase [9, 10, and 14]. B. Internet Key Protocol (iKP)
13
IV.
TWO RECOMMENDED PROTOCOLS: (MPCP2 and VAM) The suggested mobile payment protocol is presented in order to protect payer's privacy, resolve the problem of traditional flow of payment data, resolve repudiating problem and resolve replay attacks problem. The protocol is based on client centric model, where the payee does not have a direct communications with payer’s MNO. In this protocol transaction flow is completely controlled by Payer. The proposed mobile payment protocol is composed of four principals, including payer, payee, payer’s MNO and payee’s MNO. The proposed protocol is working with set Xi, where i = 1,…,n and only is shared between payer and payer’s MNO. Also set Yi is only shared between payee and payee’s MNO. The following symbols are used in proposed mobile payment protocol:
shared between merchant and payment gateway [9, 11]. III.
DIFFIE-HELLMAN KEY AGREEMENT PROTOCOL This algorithm is based on mathematics. The fundamental math includes the algebra of exponents and modulus arithmetic. For this discussion we will use Alice and Bob. The goal of this process is agreeing a shared secret session key for Alice and Bob that an eavesdropper will not be able to determine. This shared secret key is used by Alice and Bob to independently generate keys for each side. These are symmetric encryption algorithms that will be used to encrypt the data stream between them. The key's important aspect is that neither the shared secret key nor the encryption key, do not travel over the network. These steps are shown in table I [22, 23, 24, 25 and 26]. Table I Diffie-Hellman's steps for generating a shared session key between two parties Action Description Alice and Bob agree on two p is a large prime number numbers p and g g is called the base or generator Alice picks a secret number a Alice’s secret number = a Bob picks a secret number b Bob’s secret number = b Alice computes her public Alice’s public number = x number x = ga mod p Bob computes his public Bob’s public number = y number y = gb mod p Alice and Bob exchange their Alice knows p, g, a, x, y public numbers Bob knows p, g, b, x, y Alice computes ka = ya mod p ka = (gb mod p)a mod p ka = (gb)a mod p ka = gba mod p b Bob computes kb = x mod p kb = (ga mod p)b mod p kb = (ga)b mod p kb = gab mod p Fortunately for Alice and Bob, Alice and Bob both know the by the laws of algebra, Alice’s secret value k ka is the same as Bob’s kb, or ka = kb = k
{payer, payee, payer’s MNO, payee’s MNO} Paycenter PNP PINP
There are requirements on the numbers that we pick. These requirements can be found in the references. This algorithm has been reviewed and discussed many times in a variety of papers. This algorithm has some problems that make it unsuitable for mobile devices [22, 23and 27]. Note that, some of the numbers that each side may pick, may be very large for example, if p is a 512 bit binary number, the minimum allowed in the standard, would be a number with up to 150 plus digits expressed in decimal notation. Implementation details are very important as typical mobile variables that cannot hold numbers as big as this for example a 512 bit (=64 byte) number will not fit into a 4 byte integer field. In addition, these computations are too heavy for a mobile device with limited resources [22, 28].
TID TIDReq PayeeIDReq {M}X H(M)
IDP
AIP
R1
R2 DATE AMOUNT DESC
i KP-P Success/Fail Yes/No Received
PrP PuP Ck
14
TABLE II NOTATIONS A set of engaging parties, which includes Payee, Payer, Payee’s MNO and Payer’s MNO Time Stamp and Digital Sign center Phone Number of Party P Party P selected this password identification number Identity of Party P, which identifies Party P to MNO, computed as IDP= PNP+ H(PNP, PINP) Account Information of Party P, which including credit limit for each transaction and type of account (postpaid or prepaid account) Random Number and timestamp generated by Payer act as Payer’s pseudo-ID, which uniquely identifies Payer to Payee Random Number and timestamp generated to protect against replay attack Date of payment execution Payment transaction amount and currency Payment Description, which may includes delivery address, purchase order details and so on. Payer will include only the information that he/she wish to exposure to Payee. The Identity of transaction The request for TID The request for payee identity. The message M encrypted with key X. The one way hash function of the message M Used to identify the current session key of Xi and Yi The secret key shared between Payer’s MNO and Payee’s MNO. The status of registration, whether success or failed The status of transaction, whether approved or rejected Payment receivable update status, which may includes the received payment amount Private key of party P Public key of party P client key: a key that is necessary for
t ckReq
decoding Xi and Yi sets on client side Current date and time Request for client key
and Bob, by the laws of algebra, Alice’s ka is the same as Bob’s kb, or ka = kb = k
Suggested mobile payment protocol consists of two-sub protocols, which are registration protocol and payment protocol. Both payer and payee must register with their own mobile network operator (MNO) before any transaction could take place. Payer and payee’s MNO generate session key, K1 by running VAM Key Agreement protocol. This protocol is suitable for mobile devices because, it has less computations and smaller numbers than Diffie-Hellman. Therefore, this protocol is suitable for using in mobile devices with limited resources.
value k
Then payer encrypts registration details such as account information, payer identity and phone number, and sends them to payer’s MNO. Payer -> Payer’s MNO: {PNPayer, IDPayer, AIpayer }K1 During the registration process, payer has to set his password identification number, PINpayer, for accessing his mobile wallet application. This implementation uses two factor authentication, that is an important principle for mobile devices access control. The two factor authentication is authenticating users in two steps to access mobile wallet system. First step is mobile device with mobile wallet application (something he has). Second step is password (something he knows only). Then the IDpayer, is computed by hashing the PNPayer and PINpayer [16] .
This algorithm is based on mathematics. The fundamental math includes the algebra of logarithms and modulus arithmetic. For this discussion we will use Alice and Bob. The goal of this process is agreeing a shared secret session key by using limited resources of mobile devices for Alice and Bob, that an eavesdropper will not be able to determine it. This shared secret key is used by Alice and Bob to independently generate keys for each side. These are symmetric encryption algorithms that will be used to encrypt the data stream between them. The key's important aspect is that neither the shared secret key nor the encryption key, do not travel over the network. This new key agreement protocol is described in table III.
IDPayer = PNPayer + H (PNPayer, PINPayer ) Payer’s MNO decodes message with shared session key, K1 to retrieve payer’s information. Payer’s MNO stores necessary information into their database. If registration process is successful, payer’s MNO sends confirmation message to inform payer. Confirmation message is encrypted with the session key K1.
Table III VAM's steps for generating a shared session key between two parties Action Description Alice and Bob agree on q is a large prime number three numbers a,p and q a = (p)n logpa = n p = {2,3,4,…,n} n,q,u,v = {1,2,3,…,n} Alice picks a secret Alice’s secret number = u number u u mod q is not zero Bob picks a secret Bob’s secret number = v number v V mod q is not zero Alice computes her Alice’s public number = A public number =(logpa(u mod q)) mod q A = ((u mod q)logpa) mod q Bob computes his public Bob’s public number = B number =(logpa(v mod q)) mod q B = ((v mod q)logpa) mod q Alice and Bob exchange Alice knows u,a,p,q,B their public numbers Bob knows v,a,p,q,A Alice computes ka = ((u mod q)xB) mod q ka = (u.B) mod q ka = ((u mod q)(logpa(v mod q))) mod q ka = (logpa(u mod q)x(v mod q)) mod q ka = (logpa((uxv) mod q)) mod q Kb = ((v mod q)xA) mod q Bob computes kb = (v.A) mod q Kb = ((v mod q)(logpa(u mod q))) mod q Kb = (logpa(v mod q)x(u mod q)) mod q Kb = (logpa((vxu) mod q)) mod q Fortunately for Alice Alice and Bob both know the secret
Payer’s MNO -> Payer: {Success/ Failed}K1 After registration, 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 successful installation, a set of symmetric key X = {X1, X2, …, Xn } is generated, store into payer’s mobile devices and send to payer’s MNO and payee must go through the similar registration process with his/her MNO. This enables his/her to receive payment from payer. The payee generates a set of symmetric key Y = {Y1, Y2,…..Yn} with payee’s MNO and store into his/her terminal and MNO's database. In this protocol if someone catch payment message, he or she can't use that message because all messages are encrypted and include timestamp generated numbers. If someone steals payment device, Stealer can access X or Y keys, therefore, stealer can decode the payment messages and use them for illegal payment. For solving this problem all X and Y keys are encrypted in client side with client key that is only available in P's MNO. Client for gaining client key does these steps:
15
Payee -> Payee's MNO: { Yes, Y No, R2, H ( KP-P ), H ( R1, TID, AMOUNT, DA ATE, { R1, DESC } K2, R2 ), { Yes/No, TID, AMOU UNT, DATE } K2, { { TID } PrPayer } PrPayee } Yi+1
P -> P's MNO: { PNP, t, ckReq } PuP''s MNO P's MNO -> P: { ck } PuP
Phase 6: Payment Authorizattion Response Payee's MNO -> paycenter: H ({ Yes, No, R2, H ( KP-P ), H ( R1, TID, AMO OUNT, DATE, { R1, DESC } K2, R2 ), { Yes//No, TID, AMOUNT, DATE } K2, { { TID } PrPayerr } PrPayee } Yi+1) Paycenter -> Payee's MNO: generates TimeStamp2 and verifies Payee's digital siign Payee's MNO -> Payer's MNO: Yes/No, TID, D } PrPayer } PrPayee, { AMOUNT, DATE, { { TID Yes/No, TID, AMOUNT, DA ATE } K2 Fig. 1 Proposed mobile payment protocol
Phase 7: Payment Subtractionn Response
The proposed payment protoocol consists of seven phases as illustrates in figure 1.
Payer's MNO -> Payer: { Yees/No, R2, H ( KP-P ), H ( IDPayee, IDMNO, R1, R2, TID D, AMOUNT, DATE ), { Yes/No, TID, AMOUNT, DATE } K2, { { TID } PrPayer } PrPayee } Xi+1
Phase 1: Payment Initialization Payer -> Payee: R1 , TIDReq , PayeeIIDReq
Payee's MNO -> Payee: { Received, R2, H ( KP-P ), ATE, { R1, DESC } K2, H ( R1, TID, AMOUNT, DA R2 ), { { TID } PrPayer } PrPayeee } Yi+1
Payee -> Payer: { IDPayee, TID, IDMNNO }K2 Phase 2: Payment Subtraction Requuest
If all the transaction processes completed successfully, payee will reelease or deliver the purchased goods or servicess to payer. To prevent replay of the secret key from m payer and payee, both payer’s MNO and payee’s MNO M make sure that the symmetric key Xi and Yi have not been used before processing the paym ment transaction. The MNO will keep a list of geenerated secret key by expiring used symmetric keey Xi and Yi from the list. If symmetric key Xi and Yi were compromised, there must bee revoked. Both payer and payee may receive an uppdate notification from MNO when their key was exxpired. To update their secret key, they connect to thheir MNO to generate a new session key, K1 by running VAM key Agreement protocol. Then, offline o generates a new set of secret key X and Y with w a new session key K 1.
I MNO, R1, TID, Payer -> Payer's MNO: { IDPayee, ID AMOUNT, DATE, R2, H (IDPayee, ID I MNO, R1, TID, AMOUNT, DATE, R2 ), { R2, DE ESC } K2, { TID } PrPayer } Xi, i, IDPayer Payer's MNO -> paycenter: H [ { IDPayee, IDMNO, R1, TID, AMOUNT, DATE, R2, H (IDPayee, IDMNO, R1, TID, AMOUNT, DATE, R2 ), { R2, DESC } K2, { TID } PrPayer } Xi, i, IDPayer] Paycenter -> Payer's MNO: generattes TimeStamp1 and verifies Payer's digital sign Phase 3: Payment Authorization Reqquest Payer's MNO -> Payee's MNO: R1, IDPayee, TID, AMOUNT, DATE, { R1, DESC } K2, { TID } PrPayer
VACY PROTECTION V. COMPARISON ON PRIV AND AVOID REPUDIAT TING BY DIGITAL SIGN AND USING COMP PATIBLE PROTOCOL WITH LIMITED RESOU URCES OF MOBILE DEVICES FOR GENE ERATING SHARED SESSION KEY
Phase 4: Payment Confirmation Reqquest Payee's MNO -> Payee: { R1,TIID, AMOUNT, DATE, { R1, DESC } K2, R2, H ( R,TID, AMOUNT, DATE, { R1, DESC } K2, R2 ), H ( KP-P ), { TID } PrPayer } Yi , i
In this section, the propposed mobile payment protocol is comparing with five existing payment protocols from some aspeects such as privacy
Phase 5: Payment Confirmation Ressponse
16
the transaction identity from payee. R1 represents one-time payer’s identity together with regarding transaction identity (TID) uniquely identifies payer to payee. This avoids revealing the real payer’s identity (IDPayer) to payee. Comparison results also show that only the proposed mobile payment protocol provides the transactions privacy from trusted third parties or related financial institution. Also only the proposed mobile payment protocol provides avoid repudiating from each one of them. The payment subtraction request that was sent from payer to payer’s MNO consist of transaction details, which is {R, DESC} K1. Note that, the transaction details for example which stock the payee interested in or delivery address is protected from both payer’s MNO and payee’s MNO. Also they are encrypted with payer and payee shared session key, K2. Hence, only the corresponding payee can decrypts and retrieves the transaction details. Besides that, both payment subtraction request message and payment confirmation response message are applied a hash function before sending it to paycenter. This prevents revealing of any payment transaction details to paycenter. Besides that, only the proposed key agreement protocol uses mobile compatible protocol for generating shared session key. In the nutshell, after comparing the proposed protocol with five existing payment protocols, it is revealed that only the proposed mobile payment protocol satisfies all privacy protection, avoids repudiating requirements and only VAM's computation is compatible with limited resources of mobile devices.
protection, avoids repudiating with digital sign and using compatible protocol with limited resources of mobile devices for generating shared session key. Privacy protection includes identity privacy protection and transaction privacy transaction. Table III presents comparison of privacy protections, avoid repudiating by digital sign and using VAM between proposed mobile payment protocol and five existing payment protocols. TABLE IV COMPARISON ON PRIVACY PROTECTION AND AVOID REPUDIATING BY DIGITAL SIGN AND USING COMPATIBLE PROTOCOL WITH LIMITED RESOURCES OF MOBILE DEVICES FOR GENERATING SHARED SESSION KEY
Identity Protection From Payee Identity Protection From Eavesdropp Transaction Privacy Protection From Eavesdropp Transaction Privacy Protection From TTP or Related Financial Institution Avoid repudiating transaction by Digital Sign Is Computation of generating shared session key compatible with limited resources of mobile devices ?
SET
IKP
KSL
Tellez et al.
KungPisdan et al.
MPCP2
No
No
No
yes
No
Yes
Yes
Yes
Yes
yes
Yes
Yes
Yes
Yes
Yes
yes
Yes
Yes
No
No
No
No
No
Yes
No
No
No
No
No
Yes
No
No
No
No
No
Yes
VI. CONCLUSION So far many mobile payment protocols have been presented, but none of them has taken dominant application as yet. This paper suggests a private mobile payment protocol that involves MNO of Payer and Payee and a new key agreement protocol that is compatible with limited resources of mobile devices. MPCP2 is based on client centric model. In MPCP2 one time Payer's identity, transaction details and digital sign of Payer and Payee can provide complete privacy protection for the payer and avoid repudiating transaction from each of them. Note that, in VAM key agreement protocol, shared session key is generating between two parties. The proposal method seems to improve 1-mobile payment's security 2-suggests a compatible shared key generator protocol which is proper for limited resources of mobile devices.
Attainment of payer’s privacy protection, avoid repudiating and using compatible protocol with limited resources of mobile devices for generating shared session key are three significant security issues of the proposed mobile payment. Note that, five existing mobile payment protocols and proposed mobile payment protocol are providing basic privacy protection for payer, that is protecting payer’s identity and transaction details from eavesdropper. However, only Tellez et al. protocol and proposed protocol achieve payer’s identity protection from payee. In Tellez et al. protocol, payer (client) only reveals temporary identity or called Client’s Nickname to Payee (merchant) when sending the request for the transaction identity. The proposed mobile payment protocol protects payer’s identity by sending a random generated number, R1, to payee when requesting
REFERENCES [1] 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
17
[2] 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.
[20] Tiwari, A., Sanyal, S., Abraham, A., Knapskog, J. S. & Sanyal, S., "A Multi-factor Security Protocol for Wireless Payment-Secure Web Authentication Using Mobile Devices", IADIS International Conference Applied Computing, pp.160167, 2007. [21] X. Zheng & D.Chen (2003). "Study of mobile payments systems". IEEE International Conference on E-Commerce, CEC 2003, June 2003 Page(s):24 – 27 Digital Object Identifier 10.1109/COEC.2003.1210227
[3] C. Wang & H-f. Leung, "A Private and Efficient Mobile Payment Protocol", London: Springer-Verlag, LNAI, 2005, pp.1030-1035. [4]E. Valcourt, J. Robert, & F. Beaulieu, (2005). "Investigating mobile payment: supporting technologies, methods, and use." IEEE International Conference on Wireless and Mobile Computing, Networking and Communications, (WiMob'2005), Aug. 2005 Page(s):29 - 36 Vol. 4 Digital Object Identifier 10.1109/WIMOB.2005.1512946
[22] Aniket P. Kate, Prajakta S. Kalekar, Deepti Agrawal, " Weak Keys in Diffie-Hellman Protocol", Indian Institute of Technology, Powai, Mumbai, November 15, 2004
[5]http://www.setco.org/set_specifications.html
[24] D. Boneh, R. Venkatesan, "Hardness of computing most significant bits in secret keys of Diffie-Hellman and related schemes", Proc. Of Crypto '96. PP. 129-142
[23] Dan Boneh, The Decision Diffie-Hellman Problem, Stanford University
[6] J. Rao, P. Rohatgi, H. Scherzer and S. Tinguely [2002]. "Partitioning Attacks: Or How to Rapidly Clone Some GSM Cards." Proceedings of the 2002 IEEE Symposium on Security and Privacy.
[25] D. Boneh, R. Lipton, "Black box fields and their application to cryptography", Proc. Of Crypto '96, PP. 283-297
[7] 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. [8] Krueger, M, "The future of M-Payments–business options and policy issues", Seville. Spain, 2001.
[26] W. Diffie, M. Hellman, "New directions in cryptography", IEEE Transactions on Information Theory, vol. 22, no. 6, PP. 644-654, 1976
[9] Kungpisdan, S., Srinivasan, B., and Phu Dung, L, "Lightweight Mobile Credit-Card Payment Protocol", Berlin Heidelberg: Springer –Verlag, 2003a, pp. 295-308.
[28] M. Steiner, G. Tsudik, M. Waidner, "Diffie-Hellman key distribution extended to group communication", Proc. 3rd ACM Conference on Communications Security, 1996, PP. 31-37
[27] O. Goldreich, L.A. Levin, "Hard core bits based on any one way function", Proc. STOC '89
[10] Kungpisdan, S., Srinivasan, B., and Phu Dung, L., "A Practical Framework for MobileSET Payment", Proceedings of International ESociety Conference, 2003b, pp. 321-328. [11] Kungpisdan S., Srinivasan B., and Phu Dung Le, "A Secure Accountbased Mobile Payment Protocol", Proceedings of the International Conference on Information Technology: Coding and Computing, Vol. 1, Las Vegas, USA, 2004a, pp. 35-39. [12] M. Ding and C. Unnithan, "Mobile Payments (mPayments) –An Exploratory Study of Emerging Issues and Future Trends", Deakin University, 2002. [13] Mobile Payment Forum of India http://www.mpf.org.in/ [14] Mohony D.O., Peirce M. and Tewari Histesh, "Electronic Payment Systems for E-Commerce", Artech House, United States of America, 2001. [15] M. Rieback and A. Tanenbaum [2006]. "Is your cat infected with a computer virus?" 4th Annual IEEE International conference on Pervasive Computing and Communications. [16] Panko R. R, Corporate "Computer and Network Security", Prentice Hall, Upper Saddle River, New Jersey, 2004. [17] Pousttchi, K, "Conditions for Acceptance and Usage of Mobile Payment Procedures", Proceedings of the M-Business Conference, 2003. [18] S. Karnouskos & F. Fokus (2004). "Mobile Payment: a journey through existing procedures and standardization initiatives", IEEE Communications Surveys and Tutorials. 6(4) 44-66. [19] Tellez J. & Sierra J, "Anonymous Payment in a Client Centric Model for Digital Ecosystem", IEEE DEST, 2007, pp. 422-427.
18
