A Secure Account-Based Mobile Payment Protocol with Public Key Cryptography


Published on

The way people do the business and transactions
are changing drastically with the advent of Information
Technology. The customer wants to access information, goods
and services any time and in any place on his mobile device.
Receiving financial data, trade on stock exchanges, accessing
balances, paying bills and transfer funds using SMS are done
through mobile phones. Due to involvement of valuable
financial and personal information, the mobile phones are
vulnerable to numerous security threats. Most common activity
in M-Commerce is the payment to the merchant using a mobile
phone. In this paper we present a secure account–based
payment protocol which is suitable for M-commerce to transfer
the payment from wireless networks based on public key
cryptography. Based on author knowledge, this is a first kind
of protocol which applies public key cryptography to mobile
network and satisfies all the security requirements of the
properties provided by standard protocols for wired networks
such as SET and iKP.

Published in: Technology, Economy & Finance
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

A Secure Account-Based Mobile Payment Protocol with Public Key Cryptography

  1. 1. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012 A Secure Account-Based Mobile Payment Protocol with Public Key Cryptography Vorugunti Chandra Sekhar1, Mrudula Sarvabhatla2 1 Dhirubhai Ambani Institute of Information and Communication Technology, Gandhinagar, India Email: Vorugunti_Chandra_Sekhar@daiict.ac.in 2 Sri Venkateswara University, Tirupati, India Email: mrudula.s911@gmail.comAbstract—The way people do the business and transactions institution). An additional party called Payment Gatewayare changing drastically with the advent of Information which acts an interface between the mobile payment worldTechnology. The customer wants to access information, goods and existing payment infrastructure. Payment Gateway playsand services any time and in any place on his mobile device. a major role between Issuer and Acquirer for the settlementReceiving financial data, trade on stock exchanges, accessing of the transaction. The complete payment system is operatedbalances, paying bills and transfer funds using SMS are done by payment system provider who maintains a relationshipthrough mobile phones. Due to involvement of valuablefinancial and personal information, the mobile phones are with banks (Issuer, Acquirer).vulnerable to numerous security threats. Most common activity The graphical view of typical online payment system isin M-Commerce is the payment to the merchant using a mobile represented below [13]phone. In this paper we present a secure account–basedpayment protocol which is suitable for M-commerce to transferthe payment from wireless networks based on public keycryptography. Based on author knowledge, this is a first kindof protocol which applies public key cryptography to mobilenetwork and satisfies all the security requirements of theproperties provided by standard protocols for wired networkssuch as SET and iKP.IndexTerms—Electronic commerce protocol, Mobile payment,Wireless payment, Credit card payment, CryptographicProtocol, Account–Based protocol I. INTRODUCTION Mobile commerce is a powerful technology which is aresult of combining two strongly emerging trends: electroniccommerce and wireless computing. Internet + Wireless + E- Figure 1. Depicts online transactionBusiness = M-Commerce. M-Commerce represents extendedapplication of e-commerce in which user uses a mobile phone B. Public Key and Cryptography in Mobile Networksor PDA to do business. Mobile phones are most common Mobile networks have limitations [4 7 10] such as Lowdevices to do business and commerce today and the trend is power storage capacity, Computational capability, Resources,increasing due to involvement of huge financial and personal Battery Constraints, makes the public key cryptographydata transferring (PIN, Band Account no). The rapid use of infeasible for them.In 2009, a new standard was proposed forM-Commerce demands the means for secure mobile payments. public key cryptography by name NTRU cryptosystem [14].Lack of efficient protocols makes the security issue of mobile The results shows that NTRU algorithm is much faster thannetworks more challenging.In this paper, we present an RSA, the key size is one quarter than RSA with similar securityaccount-based payment protocol for wireless networks based level as RSA and key generation time is 200 times faster thanon public key cryptography. The public key cryptography RSA as presented in shen et al.can provide the Authentication, Confidentiality, Integrity and NTRU is 1133 times faster than 2048-bit RSA whennon-repudiation. compared the data throughput (Hermans et al).The NTRU algorithm was approved by the IEEE in February 2009 asA. General Model for Payment Transactions public key algorithm with standard 1363.1.The usage of NTRU A general account–based payment model [5] involves 4 provides the same level of security provided by RSA and it isparties. Buyer(who makes the actual payment through mobile having the ability to work in limited computing environments.phone), Seller(who receives payment), Issuer (Bank or Buyer These properties made NTRU are an efficient public keyfinancial institution), Acquirer(Bank or Seller financial cryptography algorithm for mobile networks.© 2012 ACEEE 5DOI: 01.IJNS.03.01. 62
  2. 2. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012C. Scope of Public Key Cryptography in the Proposed originated. In financial transactions non repudiation is a mostProtocol important factor. Symmetric key may suffer from MAC attacks. To the best of Authors knowledge it is the first protocol to be The issuer is the main source of financial transactions used for Mobile networks based on public key cryptography.from where the actual fund is transferred to Acquirer by the The non-repudiation cannot be proved from symmetric keypayment Gateway. In the proposed protocol, the issuer and cryptography as the key is shared between two parties.the Buyer possess the individual public key pairs and thuscan generate digital signatures.In public key cryptography, III. ORGANIZATION OF THE PAPERthe public key must be certified. We assume a CertificationAuthority, CA, authenticate the public key of Issuer and The remainder of the paper is organized as follows.Buyer.CA certifies the public key of Issuer using its private Section 4 discusses security requirements in Mobilekey CAPvtKey. The public key of CA is conveyed in an networks. Section 5 discusses the generic payment model.authenticated manner to all the entities involved. This can be Section 6 discusses the proposed protocol.Section 7done through any efficient algorithm. analyses the security requirements met by the proposed protocol. Section 8 discusses the comparison between ourD. Related Work protocol and standard wired mobile payment protocols. In this section several existing standard payment Section 9 provides conclusion of this research paper.protocols are analyzed briefly. Secure Electronic Transaction (SET) Protocol: SET is set IV. SECURITY REQUIREMENTS IN M-COMMERCEof security protocols enables users to employ the existing In this section we analyze the security requirements [1]private credit card payment infrastructure on an open network, for a Mobile Payment in view of the above mention systemsuch as Internet in a secure fashion. Cardholder, Seller, Issuer, entities. Buyer(B), Seller(S), Issuer(I), Acquirer(A), PaymentAcquirer, Payment Gateway, Certification Authority forms the Gateway (PG).major participants in the protocol. SET is public key Party authentication: The receiver must know the sender ofcryptography based protocol. The SET protocol supports the message is the intend and valid sender.three types of transaction steps which are Purchase request, Transaction privacy: All the transactions must be secure.Payment authorization, Payment capture [11, 13]. Proof of transaction authorization by user: When an Issuer iKP Protocol: The iKP(i-Key Protocols) where i=1,2,3 is a debits certain amount from certain credit card, the issuer mustset of payment protocols. Three parties are involved in IKP: possess unforgeable proof that the owner of the credit cardBuyer, Seller, and Acquirer gateway. iKP is based on public has authorized the payment. The Issuer also need to takekey cryptography .i value indicates the number of parties care of replay attacks, the amount, currency, order descriptionpossess the public key pairs and can generate digital Impossibility of unauthorized payments: It must besignatures. As i increases from 1 to 3, the security impossible to for adversaries to get the Credit Card Numberrequirements met by iKP increases [2]. and PIN from the payment transaction and use it later. The major drawback of SET and iKP protocols is thatthey can be successfully implemented for wired networks A. Our Assumptionsbut not for mobile networks in terms of computation and 1) A Buyer is an internet accessible mobile device.security. 2) The Issuer and Buyer are having the public keys pair SET and iKP are based on public key cryptography which generated using NTRU algorithm.involves high computational operations such as public key 3) Buyer and Seller shares a symmetric key X.encryptions and decryptions. A Certification Authority (CA) 4) Seller and PG shares a symmetric key Z.is needed to authenticate the public keys possessed by the 5) Seller and Acquirer shares a secret key Y.engaging parties. The public key of the Certification Authority 6) To distribute the secret key between them self in the entitiesmust be transmitted in a secure manner to all the parties which use Authenticated Key Exchange protocol (AKE) for Wirelessincreases the number of messages exchanged. The SET and networks found in [3, 6].iKP uses RSA algorithm for encryption which makes the 7) The reversal of a hash function is infeasible, means it issystem slower. In our algorithm we use NTRU algorithm which easy to calculate x=h(y), but it is computationally infeasiblefaster than RSA. to compute x, given y. II. MY CONTRIBUTIONS 8) The Banks issues credit card (account) and receivesWe present a protocol based on public key cryptography payment records from its customers. Every issuer (Bank) willbased on the work done in NTRU for mobile networks which have BIN (Bank Identification Number) assigned by paymentprovides all the security requirements [1] in mobile payment system provider. Every credit card issued by bank to thetransactions. Till now public key cryptography is used only customer embodies BIN.BIN also identifies the Paymentfor wired networks (Desktop). Similarly Symmetric key is used system provider.for wireless networks. The advantage of Asymmetric key over 9) We assume that the Buyer is having an account with aSymmetric key is non repudiation.The non repudiation prop- bank and securely got the PIN. Similar to Buyer a Seller iserty ensures that a party cannot deny the transaction she also associated with its bank (Acquirer) to accept deposits© 2012 ACEEE 6DOI: 01.IJNS.03.01.62
  3. 3. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012 buyer can use a modern computer. CCN: Credit Card Number issued by the Issuer to the buyer.10) The transferring and authorizing the users and clearing PIN: The PIN issues by Issuer to the buyer and the Buyerthem is done by payment gateway with the help of issuer uses CCN and PIN for her mobile transactions.(Buyer bank) and Acquirer (Seller bank). EXPIRATION: Expiration date associated with Buyers CCN. Common: Is a composite entity which contains the common V. GENERIC PAYMENT MODEL details about the transaction between Buyer and Seller, which includes: Price, IDS, TID, DATE, NONCE, IDB, and DESC. The generic model of a payment system as discussed in[2] is shown below. Common: Price, IDS, TID, DATE, NONCE, IDB, DESC Figure 3. The graphical view of our proposed protocol Figure 2. The generic model of payment system The steps 1 and 2 of the proposed protocol are registration The issuer is a bank which issues credit card to the buyer steps, in which the Buyer and Seller exchange their identities.and acquirer is a bank which acquires payment from the seller. Hence the graphical view started from step 3 from which theThe payment system provider(PSP) is an entity which payment transactions start.manages a business relationship with banks. PSP helps seller 1) B->S: IDB, TIDREQ, SIDREQto receive electronic payments of various methods like credit 2) S->B: EX{IDS, TID, DATE, NONCE, h(Common)}card, debit card etc. Paypal is an example for a PSP. It acts as 3) B->S:an intermediary between Issuer and Acquirer. PSP connects EX{EIPubKey{Price, CCN, PIN, EXPIRATION,to multiple banks, payment networks to clear the transactions BPubKey, h(Common)}}between buyer and seller. 4) S->PG: Buyer needs to pay the amount (payment) to the Seller. EZ{EIPubKey{Price, CCN, PIN, EXPIRATION,Seller contacts the Acquirer to acquire the amount. The h(Common), BPubKey}Acquirer contacts the Issuer for clearing. The clearing IDS, IDI, TID, DATE, NONCE, h(Common),between the Issuer and Acquirer will be done through the MAC[(IDS,TID, IDI,DATE,NONCE),Z]}existing banking networks. The generic payment model 5) The below steps will be done in existing private bankrepresents the macro level transactions involved. The network.operations involved at micro level among entities are 5.1) PG->I:described in the proposed protocol. {EIPubKey{Price, CCN, PIN, EXPIRATION, h(Common), BPubKey}, VI. PROPOSED PROTOCOL IDS, TID, IDB, DATE, NONCE, h(Common)} 5.2) I->PG:{Yes/no, EBPubKey{Yes/No, h(Common)}}A. Notations 5.3) PG->A: Price, IDS. B: Buyer 5.4) A->PG: S: Seller {Yes/no, EY{price, Yes/No}} I: Issuer (A bank in which the Buyer is having an Account) 6)PG->S:EZ{EBPubKey{Yes/No,h(Common)}, EY{h(Common),Yes/A: Acquirer (A bank in which the Seller is having an Account). No}}PG: Payment Gateway (Acts as an Interface between Issuer 7) S-> B: EX{ EBPubKey{Yes/No, h(Common)}}and Acquirer.IDB: Buyer identity, which identifies Buyer to the Payment B. Description of the Steps Involved in the Protocolprotocol entities. 1) B->S: IDB, TIDREQ, SIDREQIDS: Seller identity, which identifies Seller to the payment Buyer sends her Id to initiate the flow with the seller andprotocol entities. requests Seller Id and the Id of the Transaction it completedTID: Transaction ID. It includes date and time of transaction. on the seller server.Price: Total price, which the buyer needs to pay to the seller 2) S->B: EX{IDS, TID, DATE, NONCE, h(Common)}DATE: Seller’s date /time stamp helps in the replay attack. Seller gets IDB from the message sent by Buyer. SellerNONCE: Seller’s random number helps in the replay attack. knows the DATE of transaction and DESC of the transaction.DESC: Description of Goods, Books, Number of Quantity, Seller Generates a random number NONCE, The combinationThe buyer address, Credit Card name, Issuing bank name etc. of NONCE and DATE is used to resolve ambiguities in cases© 2012 ACEEE 7DOI: 01.IJNS.03.01. 62
  4. 4. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012of payments with common date. Seller computes the Issuer. The encryption by buyer public key assures that theh(NONCE) and transfers his ID, Transaction Id, Date, NONCE amount debited and status cannot be forged by any entities.and hash of NONCE to the buyer.3) B->S: EX{EIPubKey{Price, CCN, PIN, EXPIRATION, BPubKey, VII. SECURITY REQUIREMENTS MET BY THEh(Common)}} PROPOSED PROTOCOL AS DISCUSSED IN SECTION 2 Buyer forms a message by providing his Credit Card Party authentication: All the messages in the proposedNumber, PIN, and expiration date of CCN. It is encrypted with protocol are encrypted with the shared keys between entities.the public key of the Issuer. Hence no one can get the valuable As the key is shared between two entities only, the receiverinformation of CCN, PIN of the Buyer from the payment can assure that the message comes from the Authenticatedmessage. The entire message is encrypted with the sharing party only.key between Buyer and Seller. Transaction privacy: All the transactions are encrypted with4) S->PG: EZ{EIPubKey{Price, CCN, PIN, EXPIRATION, the sharing keys and the message contains CCN and PINh(Common), BPubKey} double encrypted, hence the privacy is guaranteed.IDS, IDI, TID, DATE, NONCE, h(Common), MAC[(IDS, TID, IDI, Transaction integrity: All the transactions are concatenatedDATE, NONCE),Z]} with the hash of the entities involved, which ensures integrity On receiving payment message from the Buyer, the Seller of the message to the receiver.transfers the above message to Payment Gateway which is Proof of transaction authorization by user: The messagecalled as value claim request encrypted with the shared secret sent to Issuer contains public key of Buyer (BPubKey). Thekey Z. message is encrypted with Public key of Issuer which can be The value claim requests contains Value–Subtraction decrypted only with Issuer private key. Hence the messagerequest i.e., E IPubKey{Price, CCN, PIN, EXPIRATION, is unaltered by any means. On decryption, the Issuer retrievesh(Common), BPubKey} which is sent to Issuer to subtract the public key of Buyer which confirms the Issuer that thethe prescribed price from the Buyer’s account. ID and ID are S I transaction is authorized.used to identify the Seller and Issuer. Impossibility of unauthorized payments: To send a legitimate5.1) PG->I: {EIPubKey{Price, CCN, PIN, EXPIRATION, payment message to Issuer, the adversary must know theh(Common),BPubKey},ID S, TID,ID B ,DATE,NONCE, CCN, PIN, EXPIRATION, without knowing this he cannoth(Common)} create a fake request. The CCN, PIN, EXPIRATION are sentPG sends the value–subtraction request to I. in a secure format using the Public key of Issuer, to decrypt5.2) I->PG: {Yes/no, EBPubKey{Yes/No, h(Common)}} the fraudulent must need the private key, which is not Based on the existence of the sufficient funds in the possible.Buyers account, the Issuers responds appropriately byreplying Yes/No to the PG. It frames a message containing VIII. PERFORMANCE ANALYSIS OF THE PROPOSEDYes/No, h(Common) encrypting with the public key of Buyer PROTOCOLto inform the Buyer , the exact amount debited from the buyeraccount, which should not be forgeable by either PG or Seller. In this section we compare our protocol with SET [11]5.3) PG->A: Price, IDS. and iKP [2] protocols which are standardized protocols for e- PG sends ID of Seller (IDS) and Price to notify an Acquirer commerce transactions in wired networks. The below tablethat S is person whom the requested amount to be transferred. demonstrates the number of cryptographic operations5.4) A->PG: {Yes/no, EY{Price, Yes/No}} involved at each party. The Acquirer informs the status of Value-Claim request TABLE I. COMPARISON O F C RYPTOGRAPHIC O PERATIONS O F SET, IKPto the Seller by encrypting the appropriate response with the AND O UR PROTOCOL.shared key this step prevents the PG forging the reply fromAcquirer.6)PG->S:EZ{EBPubKey{Yes/No,h(Common)}, EY{h(Common),Yes/No}} On receiving the response from the Issuer and Acquirer,PG transmits the message to Seller encrypting with the sharedkey Z. On getting the reply from the PG, the seller decrypts themessage with shared key Z, It transfer the message intendedto Buyer and decrypts the message sent by Acquirer usingthe shared key Y. If the response is Yes, then it compares theprice in message with the price it already have. If it is equal toprice it have then the transaction is fine or else it rejects it.7) S-> B: EX{ EBPubKey{Yes/No, h(Common)}} Seller sends the message received from the PG to theBuyer which is encrypted by the public key of Buyer by© 2012 ACEEE 8DOI: 01.IJNS.03.01. 62
  5. 5. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012 We can see that in our protocol only one public key [3] C. Boyd, P. Montague, and K. Nguyen, Elliptic Curve BasedEncryption and one decryption are done by Buyer. The key Password Authenticated Key Exchange Protocols,LNCS Vol. 2119,generation process is required to update the keys regularly. 2001, pp. 487-501.However, this would not cause the time consumption as this [4] S. Cimato, Design of an Authentication Protocol for GSMcan be done offline. Javacards, LNCS Vol. 2288, 2002, pp. 355-368. [5] E. V. Herreweghen, Non-Repudiation in SET: Open Issues, LNCS Vol. 1962, 2001, pp. 140-156. CONCLUSION [6] G. Horn and B. Preneel, Authentication and Payment in Future We have proposed first of its kind of account based Mobile Systems, Proceedings of 5th ESORICS’98, Belgium, 1998,protocol based on public key cryptography which is applicable pp. 277-293. [7] S. Kungpisdan, B. Srinivasan, and P. D. Le, A Practicalto wireless networks. We have shown that the proposed Framework for Mobile SET Payment, Proceedings of Internationalprotocol has advantages over SET [11] and iKP [2] protocols, E-Society Conference 2003, pp. 321-328.in that it has lower computation at each party since only two [8] S. Kungpisdan, B. Srinivasan, and P. D. Le, Accountabilitypublic key operations are required. In our protocol, Buyers Logic for Mobile Payment Protocols, To appear in ITCC’2004,can ensure that their account information will not be Las Vegas, 2004.compromised by any parties involved. As a result with our [9] S.Kungpisdan, and Y. Permpoontanalarp, Practical Reasoningproposed protocol the mobile users can have efficient and about Accountability in Electronic Commerce Protocols, LNCSsecure payments and it may gain more acceptability than Vol. 2288, 2002, pp. 268-284.existing protocols. [10] L.M. Marvel, Authentication for Low Power Systems, Proceedings of IEEE MILCOM 2001. [11] MasterCard and Visa, SET Protocol Specifications, 1997.http:/ REFERENCES /www.setco.org/set_specifications.html[1] V. Ahuja, Secure Commerce on the Internet, Academic Press, [12] B. S. Yee, Using Secure Coprocessor, PhD thesis, Carnegie1996. Mellon University, 1994.[2] M. Bellare, J. A. Garay, R. Hauser, A. Herzberg, H.Krawczyk, [13] William Stallings “Cryptography and Network SecurityM. Steiner, G. Tsudik, E. V. Herreweghen,and M.Waidner, Design, Principles and Practices” Fourth edition PHI.Implementation, and Deployment of the iKP Secure Electronic [14] J.Hoffstein, J.Pipher and J.Silverman. NTRU: A ring basedPayment System, IEEE Journal of Selected Areas in public key cryptosystem,Algorithmic Number Theory (ANTS III),Communications, 2000. Portland, OR, June 1998, Lecture Notes inComputer Science 1423, 267-288© 2012 ACEEE 9DOI: 01.IJNS.03.01. 62