A Mobile Ticket System Based on Personal Trusted Device

Transcription

1 A Mobile Ticket System Based on Personal Trusted Device Yu-Yi Chen 1, Chin-Ling Chen 2,* Jinn-Ke Jan 3 1. Department of Management Information Systems, National Chung Hsing University, Taichung, Taiwan 402, ROC. E_mail:chenyuyi@nchu.edu.tw 2. Department of Computer Science and Information Engineering, Chaoyang University of Technology, Taichung, Taiwan 413, ROC. E_mail:clc@mail.cyut.edu.tw. 3. Institute of Computer Science, National Chung Hsing University, Taichung, Taiwan 402, ROC. E_mail:jkjan@cs.nchu.edu.tw * Coronding author: Assistant Professor Chin-Ling Chen Department of Computer Science and Information Engineering, Chaoyang University of Technology, Taichung, Taiwan 413, R.O.C. Telephone number: Ext clc@mail.cyut.edu.tw

2 A Mobile Ticket System Based on Personal Trusted Device Yu-Yi Chen 1, Chin-Ling Chen 2,*, Jinn-Ke Jan 3 1. Department of Management Information Systems, National Chung Hsing University, Taichung, Taiwan 402, ROC. E_mail:chenyuyi@nchu.edu.tw 2. Department of Computer Science and Information Engineering, Chaoyang University of Technology, Taichung, Taiwan 413, ROC. E_mail:clc@mail.cyut.edu.tw 3. Institute of Computer Science, National Chung Hsing University, Taichung, Taiwan 402, ROC. E_mail:jkjan@cs.nchu.edu.tw Abstract Advances in wireless network technology and the continuously increasing users of Personal Trusted Device (PTD) make the latter an ideal channel for offering personalized services to mobile users. In this paper, we apply some cryptology (such as public key infrastructure, hashing chain and digital signature) to propose a realistic mobile ticket system such that fairness, non-repudiation, anonymity, no forging, efficient verification, simplicity, practicability and obviate the embezzlement issues can be guaranteed. On the basis of PTD is more portable and personal than personal computer, we gradually perceived that the widely used PTD will present huge commerce profits for mobile ticket service provider and it is convenient to the PTD user. Keywords: Fairness, non repudiation, anonymity, hash chain, mobile ticket. * Coronding author. address: clc@mail.cyut.edu.tw (Chin-Ling Chen) 1

3 1. Introduction People use a convenient mobile device to conduct his or her business is becoming a universal phenomenon in modern society. Anybody can access various services via the Personal Trusted Device (PTD, such as mobile phone and personal digital assistant etc.) at anytime from anywhere. The PTD has contributed greatly to the rapid development of M-commerce. For example, people can use the PTD to access various services or buy some digital goods at anytime from anywhere. In Finland, people even can pay for their car wash by mobile phone calling. People use PTD as a payment tool has become a common practice in Helsinki, Finland the country with the highest per capita cell phone use. Up to now, many mobile commerce applications are closely linked our daily life. The ticket-based applications were widely accepted in current mobile environment. However, the PTD lack of computing power is an unalterable fact [1-4]. Any complex operations are not suitable for PTD. We review the current mobile transaction system [5-8], which is based on PTD, these applications almost neglect the important technology of digital signature. Thus, we are interesting to propose a mobile ticket system to meet the non-repudiation and fairness requirements. Base on our past research [9], we involved a coordinate role observer in this scheme to solve the similar problems such that the buyer and seller cannot deny the ticket transaction. The requirements of a mobile ticket-based system are similar to the micro payment system [10-14]. Most of the micro payment applications are designed into off-line model such that the server s bottleneck can be solved. Some articles focus on digital ticket issue [15-18] and propose the requirements for this kind of transaction. In 2

4 general and comprehensive viewpoint, we considered that a good mobile ticket-based system should meet the following requirements. (1) Fairness [19, 20]: A fair system must ensure that other parties will not gain any advantages over the correctly behaving player. (2) Non-repudiation [18, 21-23]: Non-repudiation services protect the transacting parties against any false denial that a particular event or action has taken place, in which evidence will be generated, collected and maintained to enable the settlement of disputes. (3) Anonymity [15, 18]: There is no private information of the subscriber is disclosed to the ticket issuer or verifier. (4) No forging [10, 16]: A mobile ticket cannot be forged. (5) Efficiency ticket verification [16]: Ticket verification must be fast. (6) Simplicity [10]: Because of the weak computing power of the PTD, the PTD operations should be designed as simple as possible. (7) Practicability [16]: A useful protocol of the mobile ticket should be easily applied to current mobile communication system. (8) Obviate the embezzlement: A mobile ticket cannot be illegally used. The rest of this paper is organized as follows. In Section 2, we present our scheme for mobile ticket protocol. In Section 3, we analyze the requirements of the proposed protocol. We make our conclusions in Section Our Scheme 2.1 The Participating Parties and Notation In this section, we will introduce our protocol how to work. We depict the participating parties and coordinate messages of the whole process shortly in Figure. 1. 3

5 Observer 4 Subscriber erifier Phase I : Ticket Request 1.The Subscriber establishes a communication channel with the, and proposes a mobile ticket request. 2. generates a unique transaction number, signs the ticket request, and then sends the request to the. Phase II : Ticket Issue 3. The verifies the s signature for this transaction, and generates a mobile ticket. 4. The Observer authenticates the Subscriber s request, verifies the and s signature, and then generates the onse signature for the. 5. The Observer generates the hidden mobile ticket for the Subscriber. It also forwards the hidden mobile ticket and the onse signature to the. 6. The verifies the Observer s signature and forwards the hidden mobile ticket to the Subscriber s PTD. The Subscriber reveals the hidden mobile ticket. Phase III: Ticket erification 7. The Subscriber carries the PTD, which stored the mobile ticket, to request the related service. The erifier verifies the mobile ticket. 8. The erifier uploads the used ticket to the in batch processing. Figure 1. The participating parties in a ticket transaction and coordinate messages of whole process There are five parties be involved in our scheme as follows. Subscriber (S): People who uses the personal trusted device to purchase a mobile ticket. Observer (OBS): A trusted web site, which is the agent of the Subscriber. Mobile Network Service Provider (): A mobile network service provider that provides a secure, stable wireless network and manages the transaction bill. Ticket Service Provider (): A mobile ticket service provider, which cooperates with the to provide the ticket-based service and issue a mobile ticket. 4

6 erifier (): A mobile ticket verifier, which is designated to play a s agent to verify the subscriber s qualification and provides related service. In our scheme, we involve a key role of Observer to coordinate the mobile transaction. This method integrates some cryptology such as public key infrastructure, hash chain and digital signature. Now we introduce the notation be used in our scheme as follows. : concatenate operation. + : additive operation. - : subtractive operation. : exclusive-or operation. H( ) : a one-way hash function. TK req : the ticket request. TK inf o : the ticket information, which is issued by the. It includes ticket title, serial number, issuing time, valid period, price and program. ID X : the identity of the X. SP i TN i S X ( ) X ( ) M x SG X : the subscriber-pseudonym that is coordinated by subscriber and observer. : the transaction number. : the signature function using the X s secret key to sign. : the verify function using the X s public key to verify. : the x intension message, such as M req, M, M tran etc. : the X s signature. 2.2 The Detailed Protocol Initially, the Subscriber and Observer pre-coordinate a set of hashing chain a 0, a 1,..., a n, where a 0 is a random seed, a 1 =H(a 0 ), a 2 =H(a 1 ),..., a n =H(a n-1 ). Afterward, 5

7 they can use these hashing values to authenticate message each other during the mobile ticket transaction. Phase I : Ticket Request Step 1: The Subscriber makes a ticket request Tk req, which is concatenated with the identities of ID and ID OBS. M = req ( TK req ID IDOBS i SP ) And the Subscriber uses the pre-coordinated hashing values a n and a n-1 to compute the following value X req. X = M a + a req req n n-1 The X, M ) message is then sent to the. ( req req Step 2: Suppose the Subscriber is authenticated, the generates a unique transaction number TN i for this request. M tran = ( M req TNi) The uses its secret key to sign M tran as follows. SG = S ( M tran ) Then the sends X, M, SG ) to the. ( req tran Phase II : Ticket Issue Step 3: The uses the s public key to verify the received signature. tran Then the records the signature for this request and generates a ticket information TK info for this transaction. 6

8 M = ( M tran TKinf o) Afterward, the uses its secret key to sign M as follows. SG = S M ( ) The coronding message M, SG, X, SG ) is sent to the ( req Observer. Step 4: The Observer gets the Subscriber s pseudonym SP i from M req. According to the SP i, the Observer applies the pre-coordinated hashing values a n and n 1 a to authenticate the Subscriber s request message M req. req n n 1 req ( M a + a ) = X The Observer also gets M tran from M to verify the following signatures for this transaction. tran Only all of the above equalities are held, the Observer can make sure this transaction is agreed by the Subscriber, the, and the. Then the Observer uses its secret key to sign M as follows. SG ( ) OBS = SOBS M The Observer sends back SG to the. OBS Step 5: Moreover, the Observer uses the next pair of hashing values a n 1 and an 2 to generate the onse message X for the Subscriber. 7

9 X + = ( SG ) an 1 an-2 The Observer sends X,M,SG ) to the. ( OBS Step 6: The uses the Observer s public key to verify the received signature. OBS OBS Afterward, the forwards M, X ) to the Subscriber s PTD, and ( records X, X M, SG, SG ) in the Subscriber s bill. ( req, OBS Later, the Subscriber can use the same next pair of hashing values a n 1 and an 2 to reveal the signature SG as follows. SG = n ( X an 2) a 1 Phase III: Ticket erification Step 7: The Subscriber carries the PTD, which stored the mobile ticket M, X ) ( to request the erifier to provide the related service. Afterward, the erifier uses the s public key to verify the ticket as follows. Only pass the above verification, the Subscriber s request would be accepted. Step 8: The erifier uploads the used tickets to the in batch processing periodically for the double-spending detection. 3. Analysis We have proposed a mobile ticket protocol based on the personal trusted device. Now we will examine if the aforesaid requirements are satisfied. 3.1 Fairness Issue 8

10 In traditional commercial behavior, the fairness means to achieve the aim of cash on delivery. However, this is a difficult goal for web transaction. To ensure that other parties will not gain any advantages over the correctly behaving party. It is always designed that the buyer and seller receive proof of each other during the transaction scenarios in E-commerce. Therefore, a digital signature is used to generate the verifiable proof of each related party. However, it is not suitable for mobile device transactions. For this reason, we involve a trusted Observer to coordinate the transaction such that a fair transaction platform can be established. First, the Subscriber makes ticket request M req to ask the to enable this transaction. The then signs a signature SG for fairness in the ticket request phase. M tran = ( M req TNi) SG = S ( M tran ) Since the receives and verifies the signature SG, the cannot deny the SG, and then enables this request. tran Second as we mentioned, we involve the Observer to coordinate the transaction for fairness. The Observer acts as an agent to determine if the Subscriber, the and the agree this transaction. The Observer can verify the following equalities. req n n 1 req ( M a + a ) = X tran After verifying the mobile ticket, the Observer acts as an agent to generate a 9

11 signature SG OBS. SG OBS = SOBS ( M ) Both of the and receive this proof; the Subscriber only got the mobile ticket. Finally, the Subscriber got a valid mobile ticket that including the signature SG. Thus the cannot refuse to provide the coronding ticket service. 3.2 Non-repudiation Issue Non-repudiation means that the request party provides related proof (such as a digital signature) for the other party to verify that each transaction will not suffer from any false denial. In E-commerce applications, the digital signature is often used to solve the non-repudiation issue. In this section, we will focus on illustrating the non-repudiation proof for the interested party during the transaction. With each party holding related proof issued by the opposite party, our scheme will not suffer from repudiation during the transaction. In Table 1, we illustrate the non-repudiation proofs during each phase. Table 1. The non-repudiation proofs of each phase Non-repudiation proof Proof issuer Proof holder erification ( M tran, SG ) tran ( OBS M, SG ) Observer, ( M, SG ) Observer, Subscriber OBS OBS 1. After the Subscriber makes a ticket request, the signs the signature SG for the request. Since the receives and verifies the s signature SG, 10

12 the cannot deny SG, and then enable this request. 2. Since the Observer verified the agreement and issued the signature SG OBS for the and. The Subscriber also cannot deny this transaction. 3. Since the mobile ticket M, ) is issued and signed by the, the ( SG cannot refuse to provide the coronding service. 3.3 Anonymity Issue In our scheme, the Subscriber s identity will not be revealed to the or erifier during the transaction. Our scheme will not suffer from anonymity issue. 3.4 No Forging Issue No one can generate the valid mobile ticket signature M, SG ) except the (. It is actually infeasible for anyone to forge the signature SG without knowing the s secret key. 3.5 Efficient Ticket erification Issue A practical mobile ticket system should be designed in off-line verification model. In our scheme, the erifier can independently verify the mobile ticket ( M, SG ) as follows. In regard to the double spending verification of the ticket, it is the s onsibility. 3.6 Simplicity Issue The trusted Observer is involved to coordinate the transaction such that the 11

13 traditional encryption, decryption and digital signature still can be applied in our system. The PTD only performs simple operation (such as additive operation, subtractive operation and exclusive-or operation); it can be easily implemented into current PTD hardware. 3.7 Practicability Issue We proposed scenarios that include the ticket request, issue and verification phase for a mobile ticket infrastructure. Our scheme meets important issues about the ticket system. It is easily applied to current mobile system and network without need of extra infrastructures. 3.8 Obviate the Embezzlement Issue As the mobile ticket is forwarded from the Observer to the Subscriber, the signature SG is hidden by the hashing chain values a n 1 and an 2, the mobile ticket cannot be embezzled by the. 4. Conclusions With the omnipresent availability of PTD, M-commerce has a promise future in B2C market particularly. The PTD is becoming extremely popular tool for people to conduct his or her business at anytime from anywhere. In fact, it provides more portable, personal, flexible and dynamic environment than personal computer. Such application has become an attractive business area. In this paper, we overcome the weakness of the PTD lacks of computing power and involve a trusted Observer to solve some practical problems such that fairness, non-repudiation, anonymity, no forging, efficient verification, simplicity, practicability and obviate the embezzlement issues can be guaranteed. 12

14 Acknowledgements This research was supported by National Science Council, Taiwan, R.O.C., under contract number NSC E References [1] S. S. Grosche and H. Knospe, Secure Mobile Commerce, Electronics & Communication Engineering Journal, ol. 14, No. 5, pp , [2] A. Tsalgatidou and E. Pitoura, Business Models and Transactions in Mobile Electronic Commerce: Requirements and Properties, Computer Networks 37(2), pp , [3] A. Tsalgatidou, J. eijalainen and E. Pitoura, Challenge in Mobile Electronic Commerce, Proceeding of IeC 2000, 3 rd Int. Conference On Innovation through E-Commerce, UK, Nov , [4] J. eijalainen,. Terziyan and H. Tirri, Transaction Management for M-Commerce at a Mobile Terminal, Proceedings of the 36 th Annual Hawaii International Conference on System Sciences, 6-9 Jan Page(s):10. [5] B. Ozen and O. Kilic, Highly Personalized Information Delivery to Mobile Clients, Wireless Networks 10(6), pp , [6] N. M. Sadeh, T. Chan, L. an, O. Kwon and K. Takizawa, A Semantic Web Environment for Context-Aware M-Commerce, Proceedings of the 4 th ACM conference on Electronic commerce, San Diego, CA, USA, 2003, pp [7] G. Shih and S. S.Y. Shim, A Service Management Framework for M-Commerce Applications, Mobile Networks and Applications 7(3), pp , [8] Z. Trabelsi, S. Cha, D. Desai, C. Tappert, A oice and Ink XML Multimodal Architecture for Mobile E-commerce Systems, International Conference on Mobile Computing and Networking, Proceedings of the 2nd international 13

15 workshop on Mobile commerce table of contents, Atlanta, Georgia, USA, 2002, pp [9] Yu-Yi Chen, Jinn-Ke Jan, and Chin-Ling Chen, A Fair and Secure Mobile Billing System, Computer Networks, ol. 48, No. 4, pp , [10] K. Fujimura and Y. Nakajima, General-purpose Digital Ticket Framework, 3 rd USENIX Workshop on Electronic Commerce, Boston, Massachusetts, Aug. 31-Sep. 3, 1998, pp [11] M. Lee and K. Kim, A Micro-payment System for Multiple-Shopping, The 2002 Symposium on Cryptography and Information Security (SCIS 2002), Shirahama, Japan, Jan. 29-Feb.1, [12] M. S. Manasse, The Millicent Protocol for Electronic Commerce, Proceedings of the 1st USENIX Workshop on Electronic Commerce, Jul , New York, NY, [13] T. P. Pedersen, Electronic Payments of Small Amounts, Proceedings of Cambridge Workshop on Security Protocols, LNCS 1189, pp.59-68, [14] R. L. Rivest and A. Shamir, PayWord and MicroMint: Two Simple Micropayment Schemes, CryptoBytes, 2(1), pp.7-11, [15] L. Buttyan and J. P. Hubaux, Accountable Anonymous Access to Services in Mobile Communication Systems, Proceedings of the 18 th IEEE Symposium on Reliable Distributed Systems (SRDS 99), Workshop on Electronic Commerce, 1999, pp [16] A. Mana, J. Martinez, S. Matamoros and J. M. Troya, GSM-Ticket: Generic Secure Mobile Ticket Service, GEMPLUS Developer Conference, Paris, France, 2001, pp.1-7. [17] B. Patel and J. Crowcroft, Ticket Based Service Access for the Mobile User, Proceedings of the Third Annual ACM/IEEE International Conference on Mobile 14

16 Computing and Networking, Budapest, Hungary, 1997, pp [18] H. Wang, J. Cao and Y. Zhang, Ticket-based Service Scheme for Mobile Users, the 25 th Australian Computer Science Conference (ACSC2002), Conference in Research and Practice in Information Technology, Melbourne, Australia, 2002, pp [19] N. Asokan,. Shoup and M. Waidner, Asynchronous Protocols for Optimistic Fair Exchange, Proceedings of the IEEE Symposium on Research in Security and Privacy, pp.86-99, [20] N. Asokan,. Shoup and M. Waidner, Optimistic Fair Exchange of Digital Signatures, IEEE Journal on Selected Areas in Communications, 18(4), pp , [21] T. Coffey, P. Saidha, Non-repudiation with Mandatory Proof Receipt, ACM SIGCOMM Computer Communication Review, 26(1), [22] B. Cox, J. D. Tygar and M. Sirbu, NetBill Security and Transaction Protocol, Proceedings of the First USENIX Workshop on Electronic Commerce, July 11 12, New York, NY, [23] J. Zhou and D. Gollmann, Observations on Non-repudiation, Lecture Notes in Computer Science 1163, Advances in Cryptology: Proceedings of Asiacrypt 96, Kyongju, Korea, pp ,

17 Author Biographies Yu-Yi Chen was born in Kaohsiung, Taiwan, in He received the B.S., M.S., and Ph.D. in Applied Mathematics from the National Chung Hsing University in 1991, 1993, and 1998, ectively. He is presently an assistant professor of the Department of Management Information Systems, National Chung Hsing University, Taiwan. His research interests include computer cryptography, network security, and e-commerce. Chin-Ling Chen was born in Taiwan in He received the B.S. degree in Computer Science and Engineering from the Feng Cha University in 1991; the M.S. degree and Ph.D. in Applied Mathematics at National Chung Hsing University, Taichung, Taiwan, in 1999 and 2005 ectively. He is a member of the Chinese Association for Information Security. From 1979 to 2005, he was a senior engineer at the Chunghwa Telecom Co., Ltd. He is currently an assistant professor of the Department of Computer Science and Information Engineering at Chaoyang University of Technology, Taiwan. His research interests include cryptography, network security and electronic commerce. Jinn-Ke Jan was born in Taiwan in He received the B.S. degree in physics from the Catholic Fu Jen University in 1974 and the M.S. degree in information and computer science from University of Tokyo in He studied Software Engineering and Human-Computer Interface in the University of Maryland, College Park, MD, during He is presently a professor in the institute of Computer Science at National Chung Hsing University. He is currently also an editor of Information and Education, an editor of Journal of Computers, and an executive member of the Chinese Association for Information Security. He is a member of IACR and member of IEEE. From 1995 to 1997, he was the Director of the Counseling Office for Overseas Chinese and Foreign Students. From 1997 to 2000, he was the Director of the Computer Center at National Chung Hsing University. His research interests include computer cryptography, human factors of designing software and information systems, ideograms I/O processing, data structures and coding theory. 16

18 Observer 4 Subscriber erifier Phase I : Ticket Request 1.The Subscriber establishes a communication channel with the, and proposes a mobile ticket request. 2. generates a unique transaction number, signs the ticket request, and then sends the request to the. Phase II : Ticket Issue 3. The verifies the s signature for this transaction, and generates a mobile ticket. 4. The Observer authenticates the Subscriber s request, verifies the and s signature, and then generates the onse signature for the. 5. The Observer generates the hidden mobile ticket for the Subscriber. It also forwards the hidden mobile ticket and the onse signature to the. 6. The verifies the Observer s signature and forwards the hidden mobile ticket to the Subscriber s PTD. The Subscriber reveals the hidden mobile ticket. Phase III: Ticket erification 7. The Subscriber carries the PTD, which stored the mobile ticket, to request the related service. The erifier verifies the mobile ticket. 8. The erifier uploads the used ticket to the in batch processing. Figure 1. The participating parties in a ticket transaction and coordinate messages of whole process Table 1. The non-repudiation proofs of each phase Non-repudiation proof Proof issuer Proof holder erification ( tran SG M, ) ( OBS M, SG ) Observer, OBS OBS tran ( SG M, ) Observer, Subscriber 17