Securing Micropayment Transactions Over Session ...

Securing Micropayment Transactions Over Session Initiation Protocol Supakorn Kungpisdan* and Tanapat Thai-udom† *

Faculty of Information Science and Technology, Mahanakorn University of Technology, Bangkok, 10530, Thailand Tel: +66-2-9883655, Fax: +66-2-9884040 E-mail: [email protected] † Faculty of Information Science and Technology, Mahanakorn University of Technology, Bangkok, 10530, Thailand Tel: +66-2-9883655, Fax: +66-2-9884040 E-mail: [email protected] Abstract— Session Initiation Protocol (SIP) is gaining more acceptability as a standard for Voice over IP (VoIP). Several payment protocols were proposed for SIP. However, they lack necessary security properties and have poor performance due to cryptographic operations chosen. In this paper, we introduce SIPTOP, a SIP TOken-based micropayment Protocol that operates well in SIP environment. Moreover, we propose a new authentication protocol for SIP. SIPTOP was analyzed to guarantee its security properties and acceptable transaction performance.

I.

operations of this protocol arise. Firstly, the authors did not discuss about key generation and distribution which is important for symmetric-key cryptosystems. Secondly, the protocol is inspired by SET protocol [18]. However, the SET protocol is based on public-key operations. This is not suitable to be performed on low computational mobile devices. Moreover, the authors did not mention about authentication between user agent (UA) and its proxy server. Zhang et al. recommended HTTP Digest [14] as security enhancement for user authentication. However, the authentication using HTTP Digest is based on reusable information such as username and password. This is susceptible to attacks. Later, Hao et al. proposed a new payment protocol for SIP called SIPCoin [1], a prepaid micropayment protocol based on hash chains. Each electronic coin is hashed to generate another coin. Hao et al. argued that SIPCoin can fit well to standard SIP messages; only some extensions are required. SIPCoin seems to be suitable for low value transaction as it requires low computation. However, Hao et al. did not offer any security enhancement to SIPCoin, but only stated that the security of SIPCoin is based on existing security of SIP e.g. TLS and S/MIME. It can be easily seen that the communications over SIP protocol is delay-sensitive. The minimum delay is expected. Thus, the design of payment transactions over SIP has to be lightweight, and requires less number of message passes. The cryptographic algorithms have to be carefully chosen. In this paper, we introduce a new prepaid micropayment protocol that operates well in SIP environment called SIPTOP, a SIP TOken-based mobile Payment protocol. SIPTOP is based on symmetric cryptographic operations and keyed-hash functions. It works well under limited computing resources, thus making it suitable for low-value payment transactions. We demonstrate that SIPTOP satisfies necessary transaction security properties [6] including acceptable performance. Furthermore, we propose a secure authentication protocol between user agent (UA) and its proxy server in the same domain to solve the problem of HTTP Digest [14]. In this paper, section 2 presents related works. In section 3, we introduce our proposed protocols. Section 4 analyzes

INTRODUCTION

Nowadays, several payment protocols designed for wireless networks (aka. mobile payment protocol) have been proposed and discussed in [6, 12]. Mobile payment protocols can be classified into two main categories: account-based and tokenbased mobile payment. In an account-based mobile payment system, a client requires a payment approval from a bank in every transaction made to a merchant which results in high number of message passes. Moreover, most of them are based on strong public-key cryptographic operations. Hence, they are suitable for only high value payment transactions as they require high set up and operation cost. Token-based mobile payment, on the other hand, is suitable for low-value transactions, as each transaction is lightweight and incurs low operation cost. They are mostly based on symmetric-key operations and hash functions. Session Initiation Protocol (SIP) [10] is now widely accepted as a standard application layer signaling protocol for voice over IP (VoIP). SIP was designed for initiation, modification, and termination of VoIP sessions. SIP not only maintains sessions between two parties communicating with voice conversations, but also offers instant messaging (IM) capabilities [11]. This allows several kinds of message passes to perform over SIP, including making payments. A number of payment protocols were proposed for SIP [1, 3, 4, 15, 16, 17]. Zhang et al. [3] proposed a payment protocol based on SIP. The protocol deploys the combination of public-key and symmetric-key cryptography. The authors claimed that their protocol offers several security properties. However, a number of issues regarding the properties and

978-1-4244-4522-6/09/$25.00 ©2009 IEEE

187

ISCIT 2009

1) C Æ M: 2) M Æ P: 3) P Æ C: 4) C Æ P:

security and performance of the proposed protocols. In section 5, we conclude our works and discuss future works. II. A.

RELATED WORKS

Where Kup is P’s public key, Ks is a session key shared between C and M, DS = {h(h(OI), h(PI))}Krc, where Krc is C’s private key, Kuc is C’s public key, CR is confirmation request, and CA is confirmation acknowledgement. Zhang et al. claimed that the protocol offers several security properties including authentication, masquerading, confidentiality, and DoS prevention. However, a number of issues regarding the properties and operations arise: 1) Some mistakes occur in this protocol. After receiving the message 1, the merchant cannot infer the intention from the client to make a payment to him/her from DS. In order to do so, the merchant needs to know h(PI) sent from the client. However, h(PI) is not appeared in the message 1. Thus the merchant has no guarantee that the client wants to make payment to him/her. It is believed that this protocol was inspired by SET protocol. SET protocol can ensure party privacy from dual signature, whereas DS in Zhang et al.’s protocol does not. 2) The authors did not discuss about the key generation and distribution mechanism which is important for every symmetric-key cryptosystem. 3) The payment transactions are inspired by SET (Secure Electronic Transaction) protocol. However, the SET itself is a credit-card based payment protocols which is not lightweight. According to this protocol, several messages require public-key cryptographic operations which are not suitable to be performed on low computational devices. 4) Zhang et al. did not mention about the authentication between SIP client and registrar server. At the end of the paper, the author suggested HTTP Digest [14] as security enhancement for user authentication. However, the HTTP Digest is based only on username and password which are reusable credentials. This is susceptible to attacks.

Mobile Payment Overview

Payment is generally known as interactions among engaging parties regarding money transfer. A buyer purchases goods or services from a seller by exchanging a form of money with the goods or services with the seller. This form of payment has evolved from physical notes and coins to some other forms of payment e.g. check or credit-card payment. Nowadays, the payment process has been developed to be done over the Internet. Only payment-related information or electronic tokens representing physical money are sent from a payer to intended payee over the Internet. The recent development of mobile communication technology offering the ability to transmit data over wireless networks enables users to perform payment transactions over wireless networks. This kind of transaction is called “Mobile Payment”. B.

SIP Overview

Session Initiation Protocol (SIP) is an application layer signaling protocol designed to establish, maintain, and terminate sessions among parties. The SIP architecture is composed of user agents (UAs), who want to establish a SIP session between them and SIP proxies which include registrar server, proxy server, and redirect server. Users log in and check other users’ availability through a registrar server. A proxy server regulates routing SIP messages in the network, while a redirect server allows SIP proxy servers to forward SIP messages to others. From [11], Campbell, et al. proposed a SIP extension for IM processing by introducing MESSAGE method for SIP. In the SIP message with MESSAGE method, its body contains MIME type that allows the exchange of text or media content between two entities in near real time. The ability to deliver data among SIP users enable several applications to run over SIP protocol including making payments. However, in this paper, we focus on enabling token-based payment over SIP as it is more suitable for low computational capability SIP mobile devices than account-based payment. This is based on an assumption that most SIP devices are mobile devices e.g. mobile phones or PDAs. C.

{{PI, DS}Kup, OI}Ks {PI, DS}Kup, h(OI) {CR}Kuc {CA}Kup

SIPCOIN Hao et al. proposed a micropayment for SIP protocol called SIPCoin [1]. This protocol generates electronic coins based on hash chains. The authors claimed that the protocol is lightweight, thus suitable for making payments over SIP. The message passes in this protocol are enabled by the use of the MESSAGE method of SIP protocol which allows data to be transmitted in SIP. The concept of electronic coin generation is similar to ones proposed in [6, 19, 20]. The details of SIPCoin can be written as the following:

Existing Approaches

ZHANG ET AL.’S APPROACH Zhang et al. proposed a payment system based for SIP environment [3]. The protocol is based on the well-known SET protocol [18]. In SIP, data can be transmitted using MESSAGE method for IM service. The protocol combines the use of public-key and symmetric-key operations. The payment protocol is composed of customer C, merchant M, and payment gateway P. The client makes a payment by requesting the payment gateway to transfer the requested amount to the merchant. The payment transaction is performed as follows:

1) C Æ M: PurchaseRequest 2) M Æ C:PaymentOffer, ON, N, CI, CU, TCs, LPs, Expiry1 Where ON is order number, N is the amount, CI is initial cost, CU is unit-cost, TC is supported currencies, LPs is supported providers, and Expiry1 is expiry time and date. The client chooses TC from TCs, chooses Pi, the selected payment provider, from LPs, and send the following message to Pi:

188

3) C Æ Pi:WithdrawalRequest, ON, N, TC, IDM, Expiry1

Any payment transactions that satisfy the accountability also satisfy the non-repudiation property. Thus, we will borrow the technique proposed by Kungpisdan et al. [6] in our protocols. Moreover, it can be noticed that the communications between proxy servers in different domains can be secure using TLS. Thus, to ensure proxy server authentication, digital signature can be applied to the message passes between proxy servers as an additional security. Comparing with the El Sawda et al.’s approach [2], applying digital signature to the proxy server which is located in a fixed network does not introduce much computational load.

Where TC is selected currency and IDM is the identity of the merchant. Pi chooses HC according to TC, and chooses a random number WN as the root of hash chain. Then it calculates Wi = HC(Wi+1), where i = N-1, N-2, …, 0. W0 is called the anchor of the hash chain. 4) Pi Æ C:WithdrawalResponse, ON, N, HC, IDM, WN, W0, Expiry2 The client receiving the above message can calculate W0 from WN and HC. Then Pi notifies the merchant about the client requesting to make payment to the merchant.

III.

5) Pi Æ M: WithdrawalResponse, ON, N, HC, IDC, W0, Expiry2 6) C Æ M: InitialPayment, ON, IDPi, WI, I 7) M Æ Pi: RedemptionRequest, ON, IDC, WX, X

SIPTOP: THE SIP TOKEN-BASED PAYMENT PROTOCOL

A. Initial Settings ‐ ‐ ‐ ‐ ‐

Where {WI, I} represents SIPCoins, {WX, X} represents the SIPCoins that the merchant wants to redeem from Pi. After receiving the message 7, Pi transfers the requested amount to the merchant. According to [1], SIPCoin focuses on payment operations rather than security properties in that, the security of this protocol relies on the security of SIP itself (TLS and S/MIME). The authors also discussed about how their protocol satisfies security properties e.g. thievery payment, replay attack, and man-in-the-middle attacks. However, it lacks important security properties, e.g. non-repudiation [2] and accountability [6].

‐

‐

NON-REPUDIATION FOR SIP TRANSACTIONS Non-repudiation is considered as one of the most important security properties that should be guaranteed in any payment transactions. Non-repudiation in any payment transaction is defined as the property that any party should not be able to deny the transactions related to him/her. For example, the client should not be able to deny that he/she has requested to make a payment to the merchant, or the merchant cannot refuse to deliver goods or services to the client once he/she has received the payment from the merchant. An interesting research about non-repudiation in SIP protocol was conducted by El Sawda et al. [2]. The authors claimed that the non-repudiation is required for SIP transactions in order to prevent a number of attacks, e.g. manin-the-middle attacks and eavesdropping. Then they proposed a method to sign two header fields in INVITE message sent from a user agent (UA) to the proxy server in the same domain. Signing the message can be performed over TLS (Transport Layer Security) protocol. However, it can be seen that most SIP devices are considered as low-computational, battery-powered devices. They are still not suitable for performing public-key operations. Thus, a lightweight cryptographic operation with non-repudiation is required. Interestingly, Kungpisdan et al. introduced symmetric-key based cryptographic operations that can ensure accountability [6]. According to [6], accountability is the property that can ensure non-repudiation. The accountability states that each party must be able to prove any transactions related to him/her.

‐ ‐ ‐

IDX is identification information of a party X. {M}K is a message M symmetrically encrypted with a key K. h(M) is a hash value of the message M. n stands for a nonce used to prevent replay. The system is composed of a client C (and its proxy PC), a merchant M (and its proxy PM), and a bank B (and its proxy PB). Assume that all parties maintain their own SIP infrastructure. The client shares a long-term key KCM with the merchant. The generation and distribution of KCM can be performed offline. Then they create a set of session key SKCMj, where j = 1,…, m, by using a secure limited-use key generation scheme [5]. The client shares a long-term key KCB with the bank. Then they create a set of session key SKCBj, where j = 1, …, m, by using a secure limited-use key generation scheme. The merchant shares a long-term key KMB with the bank. They then create a set of session key SKMBj, where j = 1, …, m, by using a secure limited-use key generation scheme. The client shares KC with PC, the merchant shares KM with PM, and the bank shares KB with PB, respectively. As the communication is performed over a SIP-based instant messaging service, the size of each message should be minimized in order to ensure least delay. Moreover, symmetric cryptographic operations are chosen as they are lightweight, and thus suitable for performing on low computational devices such as mobile phones.

B. Details of SIPTOP SIPTOP is a pre-paid micropayment protocol that can operate well in wireless environment with limited computational resources. SIPTOP operates as follows: SETUP SIPTOP begins with the communications between the client and the bank as follows: C Æ B: IDC, IDM, CL, n1, h(n1, SKCMj), h(CL, h(n1, SKCMj), SKCBj) The client requests to purchase a coupon with the value CL from the bank. She may request the bank to deduct the amount CL from her account established with the bank. The

189

bank cannot generate this message by itself as it does not possess SKCMj used to create h(n1, SKCMj). This guarantees that this message is generated by the client. Also, the client cannot deny that she did not generate this message by himself/herself because only he/she knows both {SKCMj, SKCBj}. The bank then sends the coupon in return as shown below:

This leads to security enhancement to the system. The following processes are performed only at the first time using the system: 1) The client and PC creates a set of limited-use session keys SKCj, where j = 1, …, m, based on {KC, username, password, realm} by using a secure session key generation and distribution technique [5]. 2) The merchant and PM creates a set of limited-use session keys SKMj, where j = 1, …, m, based on {KM, username, password, realm} by using a secure session key generation and distribution technique. 3) The bank and PB creates a set of limited-use session keys SKBj, where j = 1, …, m, based on {KB, username, password, realm} by using a secure session key generation and distribution technique. Then the client performs the following process:

B Æ C: {IDC, cinit, CL, h(n2, SKMBj)}SKCBj The above message is considered as a coupon with the value CL generated by the bank for the client. It contains cinit what will be later used to generate electronic coins up to the amount CL requested by the client. Again, the client cannot generate this message by himself/herself as he/she does not have SKMBj shared between the merchant and the bank. GENERATING ELECTRONIC COINS Once receiving cinit, the client can generate a set of electronic coins ci, i = 0, …, CL, as follows:

C Æ PC: ConnectReq, n3, h(ConnectReq, IDC, password, n3, SKCj) Æ C:ConnectRes, h(ConnectRes, SKCj, n3) PC

cCL = {cinit, h(n2, SKMBj)} cCL-1 = h(cCL),…, ci = h(ci+1), where 0 = 1, …., CL-1

The similar processes are performed between other parties and their proxies. The first message is embedded in the payload part of the message sent from the client to PC. It can be seen that the above messages provide user authentication as well as proxy server authentication. This is because the client can ensure that the communicating party is its proxy PC because only PC can generate the session key SKCj. PC can also ensure that the party requesting the connection is the client because the client possesses SKCj shared only with PC.

It can be seen that the merchant cannot generate the set of coins as he/she does not have cinit used to generate cCL. MAKING PAYMENT The client can make a payment to the merchant by sending c0 as the starting value of coins for the merchant. C Æ M: {c0}SKCMj

IV. ANALYSIS AND DISCUSSIONS

Then for each payment, the client sends ci, where i is the amount of the goods or services that the client wants to purchase to the merchant. The merchant checks the received amount by calculating the number of hash operations applied from c0 to ci. C Æ M: ci,

A. Security Analysis TRANSACTION SECURITY PROPERTIES To demonstrate how the SIPTOP ensure necessary transaction security properties, consider the message sent from the bank to the client below:

where i = 0, …, CL

The merchant then maintains cmv, the maximum value of ci.

B Æ C: {IDC, cCL, CL, h(n2, SKMBj)}SKCBj

COIN REDEMPTION

From the above message, the transaction security properties for payment systems [21] are satisfied as follows. Party authentication is ensured by including h(n2, SKMBj) into the message in order to ensure that only the bank can generate this message. This is because only the bank possesses SKMBj and SKCBj. In SIPTOP, every protocol message provides party authentication. Transaction privacy is guaranteed by symmetric encryption using SKCBj. Transaction integrity is also guaranteed by symmetric encryption using SKCBj. Nonrepudiation of transactions is ensured by including both SKCBj and SKMBj in the message. This can ensure that only the bank can generate this message as only it knows both keys. Also, the bank cannot deny that it does not generate this message. This results in ensuring the non-repudiation property.

At the end of the specified period, the merchant redeems the money at the amount mv from the bank be sending the following message: M Æ B: cmv, h(cmv, SKMBj) B Æ M: Approve/Reject, n1, h(Approve/Reject, mv, h(n1, SKCMj), SKMBj+1) The bank receives cmv, calculates and transfers the amount mv to transfer to the merchant by comparing the value of cmv with cCL that it has. C. Client and Proxy Authentication Due to the weak authentication between the user agent and its proxy server based, we propose a new authentication protocol between the UA and its proxy server. The idea is to add limited-use session keys as a credential instead of using only reusable information such as username and password.

DISPUTE RESOLUTIONS/NON-REPUDIATION Referred to section 2.4 and the definition in [22], our proposed protocol can ensure accountability. That is, every

190

engaging party in SIPTOP can provide necessary evidence to show how he/she relates to the transaction. Moreover, such evidence is considered as un-deniable evidence that each party has to be responsible with what he/she has done. Consider the following message:

In this paper, we compare the computational load of our proposed protocol with Zhang et al.’s protocol and SIPCoin. However, SIPCoin does not explicitly state the computational load including cryptographic. Hao et al. mentioned that the security of SIPCoin relies on the security of SIP which is mainly based on TLS and S/MIME, public-key cryptographic protocols. We argue that our SIPTOP and Zhang et al.’s protocol can also deploy the security features provided by SIP. We compare the proposed SIPTOP with Zhang et al.’s protocol and SIPCoin in terms of the number of cryptographic operations used and the number of message passes in each protocol as shown in table 1 and 2, respectively.

B Æ M: Approve/Reject, n1, h(Approve/Reject, mv, h(n1, SKCMj), SKMBj+1) Not only the above message is an approval from the bank, but it is also considered as undeniable evidence that the bank cannot refuse to do so. Thus, messages in SIPTOP can ensure dispute resolution. PRIVATE INFORMATION

TABLE I THE NUMBER OF CRYPTOGRAPHIC OPERATIONS APPLIED TO SIPTOP, ZHANG ET AL.’S PROTOCOL AND SIPCOIN

In any payment system, the information that is known only by relevant parties such as secret keys, account information, price, or goods descriptions, is considered as private information. Revealing such information offers the opportunity to perform attacks or to trace client’s spending [6]. In SIPTOP, the payment related information c0 and cCL are transmitted in encrypted forms. Only cmv is sent from the merchant to the bank over the air interface. The bank can infer c0 from c0 = hCL(cCL), and can infer mv from c0 = hmv(cmv). Attackers cannot infer the amount mv without knowing c0. Thus, the secrecy of the requested amount is preserved.

Cryptographic Operations Signature generation Signature verification Public-key Encryption Public-key Decryption

REPLAY PREVENTION By using nonce and limited-use session key, SIP top can prevent replay attack. This is because the session keys used in this protocol are used only once. Referred to the technique presented in [5], the higher number of session keys are used, the greater security can be provided. More details can be found in [5].

Symmetric operations Hash operations Keyed-hash operations

COIN FORGERY In SIPTOP, the coin forgery is computationally infeasible. By using hash function, an attacker cannot infer ci+1 from detecting ci, the currently used coin. Generating each coin is based on a hash function of the coin that has not been used in the system. Thus, there is no way the attacker can know the input to the coin generation process.

Session-key generation

C M B C M B C M B C M B C M B C M B C M B C M B

SIPTOP 2 1 1 n n n 2 2 2 KH KH KH

Zhang et al.’s protocol 1 1 1 2 1 1 2 1 1 3 1 2 -

SIPCoin n n n -

From table 1, n represents the number of hash operations to create a set of electronic coins and KH stands for keyed-hash operations to create a set of limited-use session keys according to [5]. It can be seen that Zhang et al.’s protocol requires each engaging party to perform high computational public-key cryptographic operations, especially at client side. Generally, the SIP client is running on low computational mobile device. SIPCoin requires less computational load; only a number of hash functions are required. This is because the security of SIPCoin relies on the SIP itself, whereas the proposed SIPTOP and Zhang et al.’s protocol offer security enhancement to normal SIP protocol. Comparing with the other two protocols, our SIPTOP protocol requires fair number of cryptographic operations, particularly symmetrickey operations and keyed-hash function. This is not too heavy-loaded compared to several security properties guaranteed by SIPTOP such as non-repudiation, accountability, and party authentication.

MAN-IN-THE-MIDDLE ATTACK The attacker cannot impersonate as an engaging party from intercepting message passes in this protocol. Based on the use of limited-use session key and proper cryptographic operations, no confidential information is revealed and the reuse of authentication information is limited. B. Performance Analysis Our performance analysis follows the analysis of SIPCoin in [1] by focusing on several aspects related to transaction performance, e.g. the number of cryptographic operations applied to each protocol and the number of message passes in each protocol. Then we show that the proposed SIPTOP has greater performance than existing payment protocols for SIP [1, 3, 4].

191

IEEE/ACIS International Conference on Computer and Information Science 2008 (ICIS’2008), pp. 287-292. [5] S. Kungpisdan and S. Metheekul, A Secure Key Generation with Protection Against Key Compromise, To appear at the 13th World Multi-conference on Systematic, Cybernetics, and Informatics 2009 (WMSCI’2009), Florida, July 9-13, 2009. [6] S. Kungpisdan, Modelling, Design, and Analysis of Secure Mobile Payment Systems, PhD Thesis, Monash University, 2005. [7] B. Meng and Q. Xiong, SOCPT: A Secure Online Card Payment Protocol, Proceedings of the 8th International Conference on Computer Supported Cooperative Work in Design 2003, pp. 679-684. [8] B. Meng and H. Zhang, Research on Accountability in Electronic Transaction, Proceedings of the 9th International Conference on Computer Supported Cooperative Work in Design 2004, pp. 745-749. [9] S. Nambiar, C. T. Lu, and L. R. Liang, Analysis of Payment Transaction Security in Mobile Commerce, Proceedings of The 2nd IEEE Conference on Mobile Commerce and Services, 2005. [10] J. Rosenberg et al., SIP: Session Initiation Protocol, IETF RFC 3261, 2002. [11] B. Campbell et al., Session Initiation Protocol (SIP) Extension for Instant Messaging, IETF RFC 342, 2002. [12] T. Dahlberg, N. Mallat, J. Ondrus, and A. Zmijewska, Past, Present, and Future of Mobile Payments Research: A Literature Review, Electronic Commerce Research and Applications 2007. [13] Y. Xiao, Accountability for Wireless LANs, Ad Hoc Networks, and Wireless Mesh Networks, IEEE Communications Magazine, April 2008, pp. 116-126. [14] J. Franks et al., HTTP Authentication: Basic and Digest Access Authentication, IETF RFC 2617, 1999. [15] J. Fischl and H. Tschofenig, Making SIP Make Cents, ACM Queue, March 2007, pp. 43-49. [16] C. Jennings, J. Fischl, and H. Tschofenig, Payment for Services in Session Initial Protocol, draft-jennings-sipping-pay-06.txt, July 2007. [17] A. Ruiz-Martinez, J. A. Sanchez-Laguna, and A. F. GomezSkarmeta, SIP Extensions to Support (Micro)Payments, Proceedings of the 21st International Conference n Advanced Networking and Applications 2007 (AINA’2007), May 2007, pp. 289-296. [18] Mastercard and Visa, SET Protocol Specifications, 1997.

TABLE II THE NUMBER OF MESSAGE PASSES PER TRANSACTION OF SIPTOP, ZHANG ET AL.’S PROTOCOL, AND SIPCOIN Protocols Number of message passes

SIPTOP 6

Zhang ’s protocol 4

SIPCoin 7

According to table 2, the number of message passes in the proposed SIPTOP is not much different than the other two protocols. However, when considering repeated payments, SIPTOP and SIPCoin require less number of message passes than Zhang et al.’s protocol. This is because in SIPTOP, the client is not required to contact the bank in every transaction, whereas Zhang et al.’s protocol is. Moreover, in each transaction, SIPTOP has 6 message passes, whereas SIPCoin requires 7 messages. Thus, the proposed SIPTOP if much lightweight compared to others. V.

CONCLUSION

In this paper, we pointed out the weakness of SIP in terms of data security by selecting mobile payment as an example. We showed that existing mobile payment protocols for SIP cannot provide necessary security properties for payment transactions. Specifically, we analyzed two SIP-based mobile payment protocols: Zhang et al.’s protocol [3] and SIPCoin [1] and discussed their weaknesses in terms of transaction security and performance. Then we proposed a prepaid micropayment protocol what can operate well in SIP environment called SIPTOP. We showed that SIPTOP satisfies necessary transaction security properties especially non-repudiation and accountability. Furthermore, by applying limited-use session key generation technique from [5], this can enhance security of SIPTOP as session keys are used only once and it requires no keys to be distributed among engaging parties before performing payment a transaction. Moreover, SIPTOP was analyzed to ensure its acceptable transaction performance while comparing with the other two protocols. As our future works, we aim to implement SIPTOP to prove its performance as a real-world application. Also, we aim to optimize SIPTOP to achieve greater security and performance. We also expect to formalize payment transactions over SIP and integrate with existing formal model for mobile payment in [6].

http://www.setco.org/set_specifications.html

[19] R. L. Rivest and A. Shamir, PayWord and MicroMint: Two Simple Micropayment Schemes, Cryptobytes, Vol. 2 No. 1, May 1996, pp. 7-11. [20] S. M. Yen, PayFair: A Prepaid Internet Micropayment Scheme Ensuring Customer Fairness, Proceedings of. IEE Digital Technologies, Vol. 148, No. 6, Nov 2001. [21] D. G. Park, C. Boyd, and E. Dawson, Micropayments for Wireless Communications, Lecture Notes in Computer Science, Vol. 2015, pp. 192-205. [22] S. Kungpisdan, P. D. Le, and B. Srinivasan, Accountability Logic for Mobile Payment Protocols, Proceedings of ITCC’2004.

REFERENCES [1] J. Hao, J. Zou, and Y. Dai, A Real-Time Payment Scheme for SIP Service Based on Hash Chain, IEEE International Conference on e-Business Engineering 2008, pp. 279-286. [2] S. El Sawda, P. Urien, E. El Sawda, and I. Hajjeh, Non Repudiation for SIP Protocol, The 3rd International Conference on Information and Communications Technologies: From Theory to Application 2008 (ICTTA’2008), Damascus, April 711, 2008, pp. 1-5. [3] G. Zhang, F. Cheng, and C. Meinel, Towards Secure Mobile Payment Based on SIP, Proceedings of the 15th Annual IEEE International Conference and Workshop on the Engineering of Computer Based Systems 2008 (ECBS’2008), pp. 96-104. [4] G. Zhang, F. Cheng, and C. Meinel, SIMPA: A SIP-based Mobile Payment Architecture, Proceedings of the 7th

192