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.

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.com
Abstract—The way people do the business and transactions institution). An additional party called Payment Gateway
are changing drastically with the advent of Information which acts an interface between the mobile payment world
Technology. The customer wants to access information, goods and existing payment infrastructure. Payment Gateway plays
and services any time and in any place on his mobile device. a major role between Issuer and Acquirer for the settlement
Receiving financial data, trade on stock exchanges, accessing
of the transaction. The complete payment system is operated
balances, paying bills and transfer funds using SMS are done
by payment system provider who maintains a relationship
through mobile phones. Due to involvement of valuable
financial 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 is
in M-Commerce is the payment to the merchant using a mobile represented below [13]
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.
IndexTerms—Electronic commerce protocol, Mobile payment,
Wireless payment, Credit card payment, Cryptographic
Protocol, Account–Based protocol
I. INTRODUCTION
Mobile commerce is a powerful technology which is a
result of combining two strongly emerging trends: electronic
commerce and wireless computing. Internet + Wireless + E-
Figure 1. Depicts online transaction
Business = M-Commerce. M-Commerce represents extended
application of e-commerce in which user uses a mobile phone B. Public Key and Cryptography in Mobile Networks
or PDA to do business. Mobile phones are most common Mobile networks have limitations [4 7 10] such as Low
devices 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 cryptography
data transferring (PIN, Band Account no). The rapid use of infeasible for them.In 2009, a new standard was proposed for
M-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 than
networks more challenging.In this paper, we present an RSA, the key size is one quarter than RSA with similar security
account-based payment protocol for wireless networks based level as RSA and key generation time is 200 times faster than
on 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 when
non-repudiation. compared the data throughput (Hermans et al).The NTRU
algorithm was approved by the IEEE in February 2009 as
A. 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 is
parties. 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 key
financial institution), Acquirer(Bank or Seller financial cryptography algorithm for mobile networks.
© 2012 ACEEE 5
DOI: 01.IJNS.03.01. 62

2. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012
C. Scope of Public Key Cryptography in the Proposed originated. In financial transactions non repudiation is a most
Protocol 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 key
payment 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 thus
can generate digital signatures.In public key cryptography,
III. ORGANIZATION OF THE PAPER
the public key must be certified. We assume a Certification
Authority, 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 Mobile
key 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 7
done through any efficient algorithm. analyses the security requirements met by the proposed
protocol. Section 8 discusses the comparison between our
D. 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-COMMERCE
of 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 system
such as Internet in a secure fashion. Cardholder, Seller, Issuer,
entities. Buyer(B), Seller(S), Issuer(I), Acquirer(A), Payment
Acquirer, 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 of
cryptography 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 must
set of payment protocols. Three parties are involved in IKP:
possess unforgeable proof that the owner of the credit card
Buyer, Seller, and Acquirer gateway. iKP is based on public
has authorized the payment. The Issuer also need to take
key cryptography .i value indicates the number of parties
care of replay attacks, the amount, currency, order description
possess the public key pairs and can generate digital
Impossibility of unauthorized payments: It must be
signatures. As i increases from 1 to 3, the security
impossible to for adversaries to get the Credit Card Number
requirements met by iKP increases [2].
and PIN from the payment transaction and use it later.
The major drawback of SET and iKP protocols is that
they can be successfully implemented for wired networks A. Our Assumptions
but 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 entities
must be transmitted in a secure manner to all the parties which use Authenticated Key Exchange protocol (AKE) for Wireless
increases 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 is
system slower. In our algorithm we use NTRU algorithm which easy to calculate x=h(y), but it is computationally infeasible
faster than RSA. to compute x, given y.
II. MY CONTRIBUTIONS 8) The Banks issues credit card (account) and receives
We present a protocol based on public key cryptography payment records from its customers. Every issuer (Bank) will
based on the work done in NTRU for mobile networks which have BIN (Bank Identification Number) assigned by payment
provides all the security requirements [1] in mobile payment system provider. Every credit card issued by bank to the
transactions. Till now public key cryptography is used only customer embodies BIN.BIN also identifies the Payment
for 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 a
Symmetric key is non repudiation.The non repudiation prop- bank and securely got the PIN. Similar to Buyer a Seller is
erty ensures that a party cannot deny the transaction she also associated with its bank (Acquirer) to accept deposits
© 2012 ACEEE 6
DOI: 01.IJNS.03.01.62

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 Buyer
them 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 the
The 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, SIDREQ
to 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 bank
represents 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 Protocol
protocol entities. 1) B->S: IDB, TIDREQ, SIDREQ
IDS: Seller identity, which identifies Seller to the payment Buyer sends her Id to initiate the flow with the seller and
protocol entities. requests Seller Id and the Id of the Transaction it completed
TID: 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. Seller
NONCE: 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 combination
The buyer address, Credit Card name, Issuing bank name etc. of NONCE and DATE is used to resolve ambiguities in cases
© 2012 ACEEE 7
DOI: 01.IJNS.03.01. 62

4. ACEEE Int. J. on Network Security , Vol. 03, No. 01, Jan 2012
of payments with common date. Seller computes the Issuer. The encryption by buyer public key assures that the
h(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 THE
h(Common)}} PROPOSED PROTOCOL AS DISCUSSED IN SECTION 2
Buyer forms a message by providing his Credit Card
Party authentication: All the messages in the proposed
Number, 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 receiver
information of CCN, PIN of the Buyer from the payment
can assure that the message comes from the Authenticated
message. The entire message is encrypted with the sharing
party only.
key between Buyer and Seller.
Transaction privacy: All the transactions are encrypted with
4) S->PG: EZ{EIPubKey{Price, CCN, PIN, EXPIRATION,
the sharing keys and the message contains CCN and PIN
h(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 concatenated
DATE, 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 message
called as value claim request encrypted with the shared secret
sent to Issuer contains public key of Buyer (BPubKey). The
key 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 message
request i.e., E IPubKey{Price, CCN, PIN, EXPIRATION,
is unaltered by any means. On decryption, the Issuer retrieves
h(Common), BPubKey} which is sent to Issuer to subtract
the public key of Buyer which confirms the Issuer that the
the 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 legitimate
5.1) PG->I: {EIPubKey{Price, CCN, PIN, EXPIRATION,
payment message to Issuer, the adversary must know the
h(Common),BPubKey},ID S, TID,ID B ,DATE,NONCE,
CCN, PIN, EXPIRATION, without knowing this he cannot
h(Common)}
create a fake request. The CCN, PIN, EXPIRATION are sent
PG sends the value–subtraction request to I.
in a secure format using the Public key of Issuer, to decrypt
5.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 by
replying Yes/No to the PG. It frames a message containing
VIII. PERFORMANCE ANALYSIS OF THE PROPOSED
Yes/No, h(Common) encrypting with the public key of Buyer
PROTOCOL
to inform the Buyer , the exact amount debited from the buyer
account, 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 table
that S is person whom the requested amount to be transferred. demonstrates the number of cryptographic operations
5.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, IKP
to the Seller by encrypting the appropriate response with the AND O UR PROTOCOL.
shared key this step prevents the PG forging the reply from
Acquirer.
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 shared
key Z.
On getting the reply from the PG, the seller decrypts the
message with shared key Z, It transfer the message intended
to Buyer and decrypts the message sent by Acquirer using
the shared key Y. If the response is Yes, then it compares the
price in message with the price it already have. If it is equal to
price 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 the
Buyer which is encrypted by the public key of Buyer by
© 2012 ACEEE 8
DOI: 01.IJNS.03.01. 62

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 Based
Encryption 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 GSM
can 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 Practical
to wireless networks. We have shown that the proposed
Framework for Mobile SET Payment, Proceedings of International
protocol 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, Accountability
public 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 Reasoning
proposed protocol the mobile users can have efficient and about Accountability in Electronic Commerce Protocols, LNCS
secure 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, Carnegie
1996. Mellon University, 1994.
[2] M. Bellare, J. A. Garay, R. Hauser, A. Herzberg, H.Krawczyk, [13] William Stallings “Cryptography and Network Security
M. 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 based
Payment 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 9
DOI: 01.IJNS.03.01. 62