A Wireless Payment System Jerry Gao, Ph.D., Jacky Cai, Kiran Patel, and Simon Shim, Ph.D. San Jose State University, Computer Engineering, San Jose, USA [email protected] Abstract The swift advance of wireless networking, communication, and mobile technology is making a big impact to daily life. The significant increase of mobile device users in the recent years causes a strong demand on secured wireless information services and reliable mobile commerce (m-commerce) applications. Since mobile payment (m-payment) is a critical part of most wireless information services and applications, how to generate secured m-payment systems has become a hot research topic. This paper proposes a peer-to-peer m-payment system, known as P2P-Paid to allow mobile users to conduct wireless payments over the Bluetooth communications and to perform related secured transactions with the server. This paper introduces backgrounds, related work, and the system communication protocol, and provides system overview, security solution as well as implementation report. Keywords: mobile payment, wireless commerce, electronic commerce, secured payment protocol, and m-payment system.

1. Introduction The swift advance of wireless networking, communication, and mobile technology is changing people’s life. As there is a significant increase of mobile device users, more wireless information services and m-commerce applications are needed [1][2][3]. M-payment is a critical component in mcommerce applications. According to the Wireless World Forum, m-payment on mobile devices will provide excellent business opportunities in the coming years. How to build secured wireless payment systems is an important research topic in m-commerce. Although there are a number of types of electronic payment solutions for Internet-based applications and commerce, we are still faced with new issues and challenges in wireless payment because of lack of study and experience. In the recent years, there are a

number of papers discussing businesses markets, payment process, payment methods and standards in m-payment [4][5][6][7]. However, very few published papers discuss how to wireless payment systems, including protocols, design issues, and security solutions [8][9][10][11][12]. This paper reports our effort in building an mpayment system, known as P2P-Paid. The system uses a 2-dimensional secured protocol to support the peerto-peer payment transactions between two mobile clients through Bluetooth communications, and provides secured transactions between the payment server and mobile clients. This type of m-payment system can be used in the scenarios such as: • M-payments between a passenger and taxi driver. • M-payments between merchants in flee market and their customers. • M-payments for parking fees and subways. The paper is structured as follows. The next section reviews the related work on m-payments. Section 3 introduces a 2-dimensional P2P payment protocol. Section 4 presents the system design, including architecture, functional components, as well as used technologies. The security solutions are described in section 5. Current implementation is reported in section 6. Finally, conclusions and future work are included in section 7.

2. Backgrounds and related work According to [19], mobile payment refers to wireless-based electronic payment for m-commerce to support point-of-sale/point-of-service (POS) payment transactions on user’s mobile devices such as cellular phones, smart phones, and personal digital assistants (PDAs), or mobile terminals. In general, m-payment systems can be used by wireless-based merchants, content vendors, and information and service providers to process and support payment transactions driven by wireless-based commerce applications. As discussed in [19], the existing m-payment systems can be classified into three major types.

The first type is known as account-based payment systems, in which each customer is associated with a specific account maintained by a Trusted Third Party. The payment transactions can be pre-paid or post-paid transactions. At this time, there are three subdivisions of account-based m-payment systems: a) mobile phone-based payment systems, which enable customers to purchase and pay for goods or services via mobile phones, b) smart card payment systems, and c) credit-card m-payment systems, which allow customers to make payments on mobile devices using their credit cards. More details about different account-based payment systems are discussed in [8][9][10][12].

3.1 P2P-Paid client-server protocol Figure 3.1 encapsulates the client-server communication sequences in the P2P-Paid payment system. A service selected in step 1.1 can be any service provided by the system. The key used for encrypting/decrypting data is an authentication key generated for each session. Section 5 will explain more on the key generation. Mobile Client

User

1.1 select a service

P2P-Paid Server

1.2 display GUI

1.3 input data

The second type of m-payment system refers to mobile POS payment systems that enable customers to purchase products on vending machines or at retail stores with their mobile devices. This type of payment system is designed to complement existing credit and debit card systems for mobile users. There are two types of POS payment systems: a) automated POS payments, which are frequently used in stationary terminals such as vending machines, parking meters, etc.; b) attended POS payments, which allow mobile users to make payments with the assistance from a service party such as a taxi driver, a counter clerk, etc. A typical example of mobile POS payment system is Ultra’s M-Pay (http://www.ultra.si/). The third type is known as mobile wallets, which is the most popular type for wireless transactions. One example is e-wallets, which allows a user to store billing and shipping information with one-click while shopping with a mobile device [11]. MasterCard’s server-based mobile e-wallets using SET technology are already being used to provide secure transactions for merchants and cardholders.

1.4 encrypt sensitive data 1.5 send encrypted data

2.1 decrypt data

2.2 perform requested service 2.3 encrypt response reseult 2.4 send encrypted response result 3.1 decrypt & display response result

Figure 3.1. Client-server communication Mobile Client

P2P-Paid Server

Mobile Client

1.1 enter Bluetooth

1.2 enter Bluetooth network as payee

Payer network as payer

3.1 select Search

3.4 select a payee

1.2 enter Bluetooth network as payer

3.2 search for payees

Bluetooth Network

2.2 publish payee P2PID

1.1 enter Bluetooth network as Payee payee 2.1 select Publish

3.3 return list of payee

4.1 select Make Payment 4.2 input amount 4.3 select Send

4.4 encrypt payment data

4.5 send encrypted payment data

5.1 decrypt payment data

5.2 check account & balance

3. P2P-Paid payment protocol The goal of designing the P2P-Paid payment protocol is to provide a convenient, secure and lightweight protocol built on top of HTTP and Bluetooth communication protocols for supporting monetary transactions. P2P-Paid provides various services for mobile users to make monetary transaction securely. Those services include: send instant money, schedule payment, payee management, transaction in PAN, etc. The payment protocol can be divided into two parts: mobile client to server communication protocol and mobile client to mobile client communication protocol.

5.3 make transaction 5.4 send confiramtion

5.4 send confiramtion

Figure 3.2. Mobile client-client communication

3.2 P2P-Paid client-client protocol Mobile client to mobile client within the Bluetooth network mainly involve five steps as shown on figure 3.2: 1) A mobile user chooses a role (payer/payee) before entering the Bluetooth network. 2) The payee publishes his/her information (P2PID) onto the network to become visible to payers. 3) The payer searches for payees within the network. Bluetooth’s Service Discovery Protocol (SDP) provides standard

• Data: the data section is the XML document wrapped inside the L2CAP packet. It is either request or response message type; and the elements in the request and response message are different as shown on the figure. Request

Payer

Body

Last-UPD

Expires

CONTType

Entity Header

Entity Body

SEHdr

Body

Server

2. getLocalDevice()

LOC

HTTVERS StatusCode REAPhrase

1. search

3. getDiscoveryAgent()

CONTLEN

Host

User-AG

From

Response Header

Connection (L2CAP)

Type

Remote Device

SES- ID

Connector

LastUPD

Service Record

Expires

Discovery Agent

CONTLEN CONTType

Local Device

SEHdr

Response Status-Line

Local MIDlet

Entity Body

Entity Header

SES-ID

Request Header

HTTPVERS

REQ-URI

Request-Line

Method

means for a Bluetooth device to query and discover services supported by a peer Bluetooth device. Figure 3.3 shows a JSR-82 capable MIDlet using the DiscoveryAgent to perform device/service discovery. 4) The payer selects to make a payment to the selected payee, and then inputs the amount and a simple description for the payment. The payer’s mobile client encrypts the payment data and sends it to the server. 5) The server decrypts the data, checks for validation of the payer and the payee’s accounts, checks for sufficiency of the payer’s balance, and then performs the transaction. The server then sends a receipt to both the payer and the payee to finish the transaction.

4. retrieveDevice() 5. startInquiry()

Note: SE-Hdr: Security Header; LOC: Location; CONT-Type: Content Type; SES-ID: Session ID; HTTP-VERS: HTTP-Version; REAS-Phrase: Reason-Phrase; CONT-LEN: Content Length; User-AG: User Agent; LastUPD: Last Updated.

6. deviceDiscovered() 7. searchServices() 8. servicesDiscovered() 9. getConnectionURL()

Figure 3.4. P2P-Paid client-server message format

10. connector.Open() 11. getRemoteDevice() 12. receive/send

Packet Boundary

Broadcast Flag

L2CAP Header

Figure 3.3. Using SDP API sequence

3.3. P2P-Paid message format

Data

SE-Hdr

RequestData sessionID

SendFrom

sendTo

sendAmt

sendDesc

ResponseData

P2P-Paid client-server message format: mobile and web clients communicate with the P2P-Paid server by using HTTP/HTTPS requests and responses to send or receive messages. The request and response message formats are shown in Figure 3.4. A security header is attached for each message sent across the Internet or the air. The security header is described separately in section 5, the security solution section. P2P-Paid Bluetooth message format: P2P-Paid Bluetooth protocol is used to establish a connection and send data between MIDlet clients, where these clients are considered as peers. This protocol carries small L2CAP packets and uses the HCI interface to organize the data. Figure 3.5 shows the P2P Bluetooth message format. • Packet boundary: it identifies whether the data carries the start of the L2CAP packet. The L2CAP packets are divided into small units as mentioned above. The first packet flag is set to START and the remaining packets are set to CONTINUE. • Broadcast flag: it distinguishes the data between point-to-point and broadcast communication. • L2CAP header: it contains two bytes of Channel Identifier (CID) and two bytes of the total length.

typeError

errorMessage

typeSuccess

successMessage

Figure 3.5. P2P-Paid Bluetooth message format

4. System overview P2P-Paid has been developed at San Jose State University as a research prototype system since 2004. It’s objective is to develop a wireless-based payment system to assist mobile users to perform mobile payment transactions over mobile phones. P2P-Paid not only allows mobile users to perform electronic payment transactions over WAN, but also supports them to conduct P2P mobile payment transactions on mobile phones over a Bluetooth network. The following functions on mobile client are provided: • P2P peer discovery: only valid payers can discover valid payees who have published their Ids within the Bluetooth network. • P2P session management: mobile client sessions are established and kept track of by the system. It allows a user to establish or drop a P2P payment session in the Bluetooth network.

• P2P payment management: this allows a user to conduct a payment transaction over the Bluetooth network. • Account management: users can perform basic account management such as checking account balance, displaying summary, etc. • Payment scheduling: it allows a user to set up, update, delete, and view payment schedules. • Payee management: it allows a user to perform payee management such as adding, editing, deleting, and viewing the payee information. To assist the mobile users, the P2P-Paid system also provides them with the following basic web-based functions through an online user interface: • User and service registration. • P2P-Paid account management such as balance checking and transaction history reporting. • Bank account management, which allows users to connect their P2P-Paid accounts to their bank and to transfer money from or to their bank accounts. • Mobile payment scheduling, which allows users to schedule their payments. • Payment management, which allows users to perform online payment transactions. • Mobile payee management, which allows the user to perform payee management online. Internet J2ME Mobile Client

Payer

Online User

P2P-Paid Server Components

Wide Area Network

P2P-Paid Communication Web/Wireless Server

Bluetooth Network

Session Management Payment Management

P2P-Paid

User Management P2P-Paid Acount Management

Payee

J2ME Mobile Client

Security Management Payee Management Schedule Management Bank Acount Management

DB Server

DB

Figure 4.1. P2P-Paid system architecture

4.1. P2P-Paid system architecture As shown in Figure 4.1, P2P-Paid system has a 4tier architecture, which includes client, middleware, P2P-Paid server, and database server. Client: it includes J2ME-based mobile client software for mobile phone users and HTML-based web client for Internet accesses. The mobile client includes the following functional parts: • User interface: it supports the interactions with a mobile user to accept and process user requests, and displays the system responses.

• P2P service module: it supports P2P interactions between two mobile users (payer and payee) for peer discovery based on the Bluetooth’s SDP. • Security module: it performs security functions with the support of the security management in the server, including mobile user authentication and voice verification. • Payment module: it supports m-payment communication between mobile clients and the server over a wireless Internet infrastructure. Middleware: it includes a Tomcat application server with the wireless Internet support and other middleware software such as JSPs and Servlets. Database server: the database server (MySQL Server) works with the database access programs to maintain necessary user and account information and payment transactions. P2P-Paid server: it works with middleware by communicating with clients to support payment functions. As shown in Figure 4.1, the P2P-Paid server contains the following functional components: • P2P-Paid communication: it implements the P2P 2D payment protocol to support all mobile payment communications between a mobile client and the server. • User management: it supports user registration and maintains two types of user information, including registered mobile users and administration users. • P2P-Paid account management: it supports user account creation and updates. • Bank account management: it supports bank account connection, update and money transfer. • Payment management: it manages and maintains all mobile payment transaction records. • Schedule management: it manages and maintains mobile payment schedules such as adding, updating a payment schedule, etc. Whenever a scheduled payment is due, a transaction is invoked. • Payee management: it manages and maintains payee records for mobile user, such as adding, updating, and deleting a payee. • Session management: it establishes and controls mobile payment sessions for payment transactions. • Security management: it supports security functions such as user authentication, access control, key management, data digest and encryption/decryption, voice verification, etc.

4.2. Implementation status and technologies

The current version of the P2P-Paid system has only implemented the P2P payment protocol with basic security support. The voice verification feature will be added in the later version. The server is deployed on Tomcat (Version 5.0.28). On the mobile client side, NetBeans 4.0 IED with the J2ME Wireless Toolkit Emulator integrated is used to develop and test the MIDP client. JSR-82 is used to test the Bluetooth communications. In addition, the kXML parser is used to parse xml data on MIDP client and Xercer parser is used on the P2P-Paid server.

5. The P2P-Paid security solution The basic security solution of the P2P-Paid payment system is an integration of the secured payment protocol, biometric verification, and optimized conventional security methods. It provides the following security features: service registration, access control, security code attachment, and speaker verification.

PaymentSystem

Web Client 1. request for registration

2. SSL connection with registration form, server certificate, PK 3.validate server certificate, generate pre-master key

User

4. encrypted pre-master key 5. decrypt premaster key, generate authentication key

6. encrypted authentication key 8. Input registration data

7. decrypt authentication key 9. encrypted form 10. create account

11. notification

Figure 5.1. Secured web registration sequence M o b ile C lie nt

User

1.1 se le ct reg is tra tio n

P 2 P -P a id S erv er

1 .2 d is play re g istra tion G U I

1 .3 inp u t ID , P IN

V o ice V e rifica tion E n gin e

2 .1 re q ue s t fo r h ttp s co n n e ction 2 .2 S S L h a n d sh a ke 2 .3 e n cryp te d ID , P IN

3 .1 v e rify u se r

3 .2 n o tifica tio n

Service registration: before using the P2P-Paid payment services, a user must first register with the system. Two types of registration a user must go through: online registration and mobile registration. On completion of online registration, a user account is created; and a key pair is associated with the web client and the system server (see figure 5.1). On completion of mobile registration, a voiceprint is created for the user for future mobile authentication; and a symmetric key is also associated with the mobile device and the system server. Symmetric key is chosen here due to its better performance. The symmetric key is protected with secure connection (https) when it is sent to the mobile client; and the key is stored on the device in an encoded form (see figure 5.2). Hence, only the P2P-Paid server recognizes the key; and the mobile device is also authenticated when it successfully communicates with the server. The sensitive data transmitted is encrypted using an authentication key that is generated based on the symmetric key for each communication session. Access control: authorization comes after authentication. In order to use the P2P-Paid payment service, a mobile user has to login the system first. Only valid user receives the access to the system. There are two types of login: online login and mobile login. Online login requires the user to enter the valid P2PID and password. Mobile login requires the user to enter P2PID, PIN and voiceprint. Figure 5.3 presents the mobile login procedures.

*4 .2 v oice in p uts

4.1 p ro m p t fo r vo ic e in pu ts 4 .4 de c ry pte d vo ic e in pu t

4 .3 en c ry p te d vo ic e in p ut

4 .5 c rea te v o ice p rint

4 .6 n o tifica tion 5.1 re trie v e s ec ret k ey K 5 .2 e n cry pted K 5 .3 s to re K 6 d isp la y co m p le tio n m e ss ag e

Figure 5.2. Secured mobile registration sequence Mobile Client

User 1.1 select login

P2P-Paid Server

1.2 display Login form

1.3 input P2PID, PIN

Voice Verification Engine 1.4 encrypted login form

1.5 verify user account

1.6 notification *2.2 voice input

2.1 prompt for voiceprint 2.3 encrypted voice input

2.4 decrypted voice input

2.7 notification

2.6 notification

2.5 verify voiceprint

Figure 5.3. Secured mobile login sequence Security code attachment: as mentioned above, any sensitive data is encrypted before transmitting over the network. A security header is attached on each piece of message sent across the Internet or the air. The security header carries the information about the secured protocol. Each element in the security header can be empty or contains value depends on

what type of information is sent. The format of the security header is shown on Figure 5.4. MAC

Key Used

Key Length

Encrypted Fields (e.g. userID, PIN, account No.)

Figure 5.4. Security Header format • MAC: MAC is the message authentication code. MAC is the digest of authentication key and the message. It allows data authentication that allows the receiver to verify the integrity of a message. • Key used: for the first time when two parties communicate with each other, they need to negotiate for which key is used for establishing a secure connection. • Key length: due to the ability of different devices for handling different key lengths, an appropriate key length must be negotiated before two devices starting encrypting the traffic between them. • Encrypted fields: it indicates what fields or which pieces on the message are encoded. In general, all sensitive data such as user ID, password, PIN, account number, etc. should be encrypted. Speaker verification: Speaker verification, as a subclass of voice recognition, is the process of automatically recognizing who is speaking on the basis of individual information included in speech waves. Its task is a hypothesis-testing problem where the system has to accept or reject a claimed identity associated with an utterance [13]. There are two types of speaker verification approaches: text-dependent and text-independent. Text-dependant approach is chosen as a part of user authentication in our system. Based on our research, there exist a number of voice verification systems [13][14][15][16], in which the feature vectors and trained model of a speech are based on a set of world models. To obtain an accurate model that represents better voice characteristics, a large set of world models is needed. This is expensive. Since most existing solutions are not designed to address mobile client limitations (such as dynamic environment and limited computing power), we are working on to develop a refined text-dependent speaker verification module to focus on optimizing feature extracting. With speaker verification, the system not only can authenticate the mobile device, but also can authenticate the user who is using it. The detailed implementation and experimental results of the module will be reported in the future papers.

a) P2P-Paid home page

b) P2P Account Summary

c) Bank Management

d) Payment History

e) Schedule Payment Management

Figure 6.1. P2P-Paid web examples

6. Application examples Some screenshots are presented in this section to demonstrate our prototype. Figure 6.1 shows some web interfaces as self-described by their captions. Figure 6.2 shows some mobile client interfaces for

mobile user to perform payment transactions and management. They are described as below: a) Main menu: after successfully login, mobile user JackyCai is presented with the main menu. b) View account summary: JackyCai chooses to view account summary. c) Send money now: JackyCai needs to input payee’s P2PID (kiranp), amount and payment description. d) Last payment summary: JackyCai chooses to view last payment summary from the main menu in a) and the summary of the payment just made in c) is presented. e) Last payment summary: the payee kiranp logins with her mobile device and view the summary of the payment made by JackyCai in c). f) Schedule payment menu: JackyCai selects schedule payment from the main menu in a); and he is presented with the schedule payment menu, from which he can choose to view scheduled payments and add schedule payment. g) Add schedule payment: JackyCai selects to add a schedule payment. He is presented with a form for inputting schedule payment data, which includes: schedule payment title, payee’s P2PID, amount, description and date. h) Payee management: user can select Payee Management from the main menu in a) to perform payee management. Payee Management has similar features as Schedule Payment. i) Select a role as payee: from i) to m) are the P2P interactions within Bluetooth network. After JackyCai selects Enter P2P’s Bluetooth Network from the main menu in a), he selects a role as payee to enter the Bluetooth network. j) Payee’s menu: payee is represented with a menu for publishing/removing his information (P2PID). Payee JackyCai selects to publish his information and his P2PID becomes visible in the network. k) Select a role as payer: another user kiranp selects a role as payer to enter into the Bluetooth network. l) Peer search result: kiranp performs a search to discover payees in the network. Payee JackyCai is found. Note that if multiple payees have published their information in the network, a payer is able to discover them and select one from the list to make payment. m) Make a payment: payer kiranp selects to make a payment. The payment form with the selected payee’s P2PID attached is presented. The payer only needs to enter the amount and a simple description to make a transaction. n) and o) Receipt: the payee and the payer view their receipt of the transaction made in m) respectively.

a)

b)

c)

d)

e)

f)

g)

h)

i)

j)

k)

l)

m)

n)

o)

Figure 6.2. Mobile payment scenarios

7. Conclusions and future work This paper reports our current research efforts on developing the P2P-Paid system to support mobile phone users to conduct peer-to-peer wireless payment transactions. The P2P-Paid system provides both online payment and mobile peer-to-peer payment

functions. It implements a 2D wireless payment protocol which not only supports mobile payment transactions over a wireless Internet, but also supports wireless payment transactions between two mobile phones over a Bluetooth network. This paper reports the system architecture, design, payment protocol, and security strategy. Moreover, application examples of the prototype are presented. The future work of this research is to develop and implement a lightweight speaker verification solution to support mobile user authentication and authorization for mobile payment transactions.

References [1] H.M. Yunos, J Gao, and S. Shim, “Wireless Advertising’s Challenges and Opportunities: IEEE Computer”, Vol. 36, No. 5, May 2003. [2] J. Ondrus, and Y. Pigneur, “A Disruption Analysis in the Mobile Payment Market”, Proceedings of the 38th Hawaii International Conference on System Sciences, 2005 (HICSS38’05). [3] N.M. Sadeh, M-Commerce: Technologies, Services, and Business Models: Wiley, John & Sons, Inc., March 2002. [4] L. Antovski, and M. Gusev, “M-Payments”, Proceedings of the 25th International Conference Information Technology Interfaces, 2003 (ITI’03). [5] K. Pousttchi, and M. Zhenker, “Current Mobile Payment Procedures on the German Market from the View of Customer Requirements”, Proceedings of the 14th International Workshop on Database and Expert Systems Application, 2003 (DEXA’03). [6] S. Nambiar, and T.L. Chang, “M-Payment Solutions and M-Commerce Fraud Management”, Retrieved September 9, 2004 from http://europa.nvc.cs.vt.edu/~ctlu/Publication/MPayment-Solutions.pdf [7] X. Zheng, and D. Chen, “Study of Mobile Payments System”, Proceedings of the IEEE International Conference on E-Commerce, 2003 (CEC’03). [8] S. Kungpisdan, B. Srivnivasan, and P.D. Le, “A Secure Account-Based Mobile Payment Protocol”, Proceedings of the International Conference on Information Technology: Coding and Computing, 2004 (ITCC’04). [9] Y. Lin, M. Chang, and H. Rao, “Mobile prepaid phone services”, IEEE Personal Communications, 7(3): 6-14, June 2000. [10] A. Fourati, H.K.B. Ayed, F. Kamoun, and A. Benzekri, “A SET Based Approach to Secure the Payment in Mobile Commerce”, In Proceedings of 27th Annual IEEE Conference on Local Computer Networks (LCN'02) November 06 - 08, 2002, Tampa, Florida. [11] D. Hennesy, “The Value of the Mobile Wallet”, Retrieved on 2/16/2005 at: http://www.valista.com/downloads/whitepaper/mobile_walle t.pdf

[12] Z. Huang, and K. Chen, “Electronic Payment in Mobile Environment”, In Proceedings of 13th International Workshop on Database and Expert Systems Applications (DEXA'02) September 02 - 06, 2002. Aix-en-Provence, France. [13] J. Olsson, “Text Dependent Speaker Verification with a Hybrid HMM/ANN System”, Retrieved Jan. 5, 2005 from http://www.speech.kth.se/ctt/publications/exjobb/exjobb_jol sson.pdf. [14] D.A. Reynolds, T.F. Quatieri, and R.B. Dunn, “Speaker Verification Using Adapted Gaussian Mixture Models”, Retrieved January 5, 2005 from http://www.cse.ohiostate.edu/~dwang/teaching/cis788/papers/Reynoldsdsp00.pdf. [15] T.B. Nordstrom, H. Melin, and J. Lindberg, “A Comparative Study of Speaker Verification Using the Polycost Database”, Retrieved January 11, 2005 from http://www.speech.kth.se/ctt/publications/papers/icslp98_13 59.pdf [16] S. Marinov, “Text Dependent and Text Independent Speaker Verification System: Technology and Application”, Retrieved January 19, 2005 from http://www.speech.kth.se/~rolf/gslt_papers/SvetoslavMarino v.pdf. [17] N. Potlapally, S. Ravi, A. Raghunathan, and G. Lakshminarayana, “Algorithm Exploration for Efficient Public-Key Security Processing in Wireless Handsets”, Design Automation and Test in Europe (DATE), March 2002. [18] N.R. Potlapally, S. Ravi, A. Raghunathan, and G. Lakshminarayan, “Optimizing Public-Key Encryption for Wireless Clients”, IEEE International Conference on Communications (ICC), May 2002. [19] Jerry Gao, Min Li, Sunitha Magadi Venkatesh and Jacky Cai, “Wireless Payment”, the 8th International Conference for Young Computer Scientists, September 20 – 22, Beijing, China.