A Mobile Ticket System Based on Personal Trusted Device
Yu-Yi Chen1, Chin-Ling Chen2,* Jinn-Ke Jan3
1. Department of Management Information Systems, National Chung Hsing University,
Taichung, Taiwan 402, ROC. E_mail:[email protected]
2. Department of Computer Science and Information Engineering, Chaoyang
University of Technology, Taichung, Taiwan 413, ROC.
E_mail:[email protected].
3. Institute of Computer Science, National Chung Hsing University, Taichung, Taiwan
402, ROC. E_mail:[email protected]
* Corresponding 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: +886-4-23323000 Ext. 4761
E-mail:
[email protected]
A Mobile Ticket System Based on Personal Trusted Device
Yu-Yi Chen1, Chin-Ling Chen2,*, Jinn-Ke Jan3
1. Department of Management Information Systems, National Chung Hsing University, Taichung, Taiwan 402, ROC. E_mail:[email protected]
2. Department of Computer Science and Information Engineering, Chaoyang University of Technology, Taichung, Taiwan 413, ROC. E_mail:[email protected]
3. Institute of Computer Science, National Chung Hsing University, Taichung, Taiwan 402, ROC. E_mail:[email protected]
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.
*
Corresponding author.
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
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 4.
2. 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.
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 (MNSP): A mobile network service provider
that provides a secure, stable wireless network and manages the transaction bill.
Ticket Service Provider (TSP): A mobile ticket service provider, which
cooperates with the MNSP to provide the ticket-based service and issue a mobile ticket.
Figure 1. The participating parties in a ticket transaction and coordinate messages of whole process Subscriber
Verifier Phase I : Ticket Request
1.The Subscriber establishes a communication channel with the MNSP, and proposes a mobile ticket request. 2. MNSP generates a unique transaction number, signs the ticket request, and then sends the request to the TSP.
Phase II :Ticket Issue
3. The TSP verifies the MNSP’s signature for this transaction, and generates a mobile ticket.
4. The Observer authenticates the Subscriber’s request, verifies the MNSP and TSP’s signature, and then generates the response signature for the TSP.
5. The Observer generates the hidden mobile ticket for the Subscriber. It also forwards the hidden mobile ticket and the response signature to the MNSP.
6. The MNSP 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 Verification
7. The Subscriber carries the PTD, which stored the mobile ticket, to request the related service. The Verifier verifies the mobile ticket. 8. The Verifier uploads the used ticket to the TSP in batch processing. 1 6 2 3 4 5 7 MNSP TSP 8 Observer
Verifier (V): A mobile ticket verifier, which is designated to play a TSP’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.
req
TK : the ticket request.
o inf
TK : the ticket information, which is issued by the TSP. It includes ticket title, serial
number, issuing time, valid period, price and program.
IDX : the identity of the X.
SPi : the subscriber-pseudonym that is coordinated by subscriber and observer.
i
TN : the transaction number.
SX( ) : the signature function using the X’s secret key to sign. VX( ) : the verify function using the X’s public key to verify. Mx : the x intension message, such as Mreq, Mresp, Mtran etc. SGX : the X’s signature.
2.2 The Detailed Protocol
Initially, the Subscriber and Observer pre-coordinate a set of hashing chain a0, a1, . . . , an, where a0 is a random seed, a1=H(a0), a2=H(a1), . . . , an=H(an-1). Afterward,
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 Tkreq, which is concatenated with the
identities of IDTSP and IDOBS.
) ||
( req TSP OBS i
req TK ||ID ||ID SP
M =
And the Subscriber uses the pre-coordinated hashing values an and an-1 to
compute the following value Xreq.
1 n-n req req M a a X = ⊕ +
The (Xreq,Mreq) message is then sent to the MNSP.
Step 2: Suppose the Subscriber is authenticated, the MNSP generates a unique transaction number TNi for this request.
) ||
( req i
tran M TN
M =
The MNSP uses its secret key to sign Mtran as follows. )
( tran
MNSP MNSP S M
SG =
Thenthe MNSP sends (Xreq,Mtran,SGMNSP) to the TSP.
Phase II : Ticket Issue
Step 3: The TSP uses the MNSP’s public key to verify the received signature.
tran MNSP MNSP SG M V ? ) ( =
Then the TSP records the signature for this request and generates a ticket
) ||
( tran info
resp M TK
M =
Afterward, the TSP uses its secret key to sign Mresp as follows.
) ( resp
TSP
TSP S M
SG =
The corresponding message (Mresp,SGTSP,Xreq,SGMNSP) is sent to the Observer.
Step 4: The Observer gets the Subscriber’s pseudonym SPi from Mreq. According to the
SPi, the Observer applies the pre-coordinated hashing values an and an−1 to
authenticate the Subscriber’s request message Mreq.
) ( ? 1 req n n req a a X M ⊕ + − =
The Observer also gets Mtran from Mresp to verify the following signatures
for this transaction.
resp TSP TSP SG M V ? ) ( = tran MNSP MNSP SG M V ? ) ( =
Only all of the above equalities are held, the Observer can make sure this transaction is agreed by the Subscriber, the MNSP, and the TSP. Then the Observer uses its secret key to sign Mresp as follows.
) ( resp
OBS
OBS S M
SG =
The Observer sends backSGOBS to the TSP.
Step 5: Moreover, the Observer uses the next pair of hashing values an−1and an−2 to generate the response message Xresp for the Subscriber.
2 1 ) ( TSP n n-resp SG a a X = ⊕ − +
The Observer sends (Xresp,Mresp,SGOBS) to the MNSP.
Step 6: The MNSP uses the Observer’s public key to verify the received signature.
resp ? OBS OBS(SG ) M
V =
Afterward, the MNSP forwards (Mresp,Xresp) to the Subscriber’s PTD, and
records )(Xreq,Xresp,Mresp,SGMNSP,SGOBS in the Subscriber’s bill.
Later, the Subscriber can use the same next pair of hashing values
2 1and −
− n
n a
a to reveal the signature SGTSP as follows.
) ( − −2 ⊕ −1 = resp n n TSP X a a SG
Phase III: Ticket Verification
Step 7: The Subscriber carries the PTD, which stored the mobile ticket (Mresp,Xresp)
to request the Verifier to provide the related service. Afterward, the Verifier uses the TSP’s public key to verify the ticket as follows.
resp TSP TSP SG M V ? ) ( =
Only pass the above verification, the Subscriber’s request would be accepted.
Step 8: The Verifier uploads the used tickets to the TSP 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.
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 Mreq to ask the MNSP to enable this
transaction. The MNSP then signs a signature SGMNSP for fairness in the ticket request
phase. ) || ( req i tran M TN M = ) ( tran MNSP MNSP S M SG =
Since the TSP receives and verifies the signature SGMNSP, the MNSP cannot
deny theSGMNSP, and then enables this request.
VMNSP SGMNSP Mtran
? )
( =
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 MNSP and the TSP agree this transaction. The Observer can verify the following equalities.
) ( ? 1 req n n req a a X M ⊕ + − = resp TSP TSP SG M V ? ) ( = tran MNSP MNSP SG M V ? ) ( =
signature SGOBS. ) ( resp OBS OBS S M SG =
Both of the TSP and MNSP receive this proof; the Subscriber only got the
mobile ticket.
Finally, the Subscriber got a valid mobile ticket that including the signature
SGTSP. Thus the TSP cannot refuse to provide the corresponding 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 Verification
) , (Mtran SGMNSP MNSP TSP tran MNSP MNSP SG M V ? ) ( = ) ,
(Mresp SGOBS Observer MNSP, TSP
resp OBS OBS SG M V ? ) ( = ) , (Mresp SGTSP TSP Observer, Subscriber VTSP SGTSP Mresp ? ) ( =
1. After the Subscriber makes a ticket request, the MNSP signs the signature SGMNSP
the MNSP cannot deny SGMNSP,and then enable this request.
2. Since the Observer verified the agreement and issued the signature SGOBS for the
TSP and MNSP. The Subscriber also cannot deny this transaction.
3. Since the mobile ticket (Mresp,SGTSP)is issued and signed by the TSP, the TSP
cannot refuse to provide the corresponding service.
3.3 Anonymity Issue
In our scheme,the Subscriber’s identity will not be revealed to the TSP or Verifier 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 (Mresp,SGTSP)except the
TSP. It is actually infeasible for anyone to forge the signature SGTSP without knowing the TSP’s secret key.
3.5 Efficient Ticket Verification Issue
A practical mobile ticket system should be designed in off-line verification model. In our scheme, the Verifier can independently verify the mobile ticket
) , (Mresp SGTSP as follows. resp TSP TSP SG M V ? ) ( =
In regard to the double spending verification of the ticket, it is the TSP’s responsibility.
3.6 Simplicity Issue
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 SGTSP is hidden by the hashing chain values an−1and an−2, the mobile ticket
cannot be embezzled by the MNSP.
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.
Acknowledgements
This research was supported by National Science Council, Taiwan, R.O.C., under contract number NSC-94-2213-E-324-028.
References
[1] S. S. Grosche and H. Knospe, “Secure Mobile Commerce”, Electronics & Communication Engineering Journal, Vol. 14, No. 5, pp.228-238, 2002.
[2] A. Tsalgatidou and E. Pitoura, “Business Models and Transactions in Mobile Electronic Commerce: Requirements and Properties”, Computer Networks 37(2), pp.221-236, 2001.
[3] A. Tsalgatidou, J. Veijalainen and E. Pitoura, “Challenge in Mobile Electronic Commerce”, Proceeding of IeC 2000, 3rd Int. Conference On Innovation through E-Commerce, UK, Nov. 14-16, 2000.
[4] J. Veijalainen, V. Terziyan and H. Tirri, “Transaction Management for
M-Commerce at a Mobile Terminal”, Proceedings of the 36th Annual Hawaii
International Conference on System Sciences, 6-9 Jan. 2003 Page(s):10.
[5] B. Ozen and O. Kilic, “Highly Personalized Information Delivery to Mobile Clients”, Wireless Networks 10(6), pp.665 – 683, 2004.
[6] N. M. Sadeh, T. Chan, L. Van, O. Kwon and K. Takizawa, “A Semantic Web
Environment for Context-Aware M-Commerce”, Proceedings of the 4th ACM
conference on Electronic commerce, San Diego, CA, USA, 2003, pp.268 – 269. [7] G. Shih and S. S.Y. Shim, “A Service Management Framework for M-Commerce
Applications”, Mobile Networks and Applications 7(3), pp.199 – 212, 2002.
[8] Z. Trabelsi, S. Cha, D. Desai, C. Tappert, “A Voice and Ink XML Multimodal Architecture for Mobile E-commerce Systems”, International Conference on Mobile Computing and Networking, Proceedings of the 2nd international
workshop on Mobile commerce table of contents, Atlanta, Georgia, USA, 2002, pp.100-104.
[9] Yu-Yi Chen, Jinn-Ke Jan, and Chin-Ling Chen, “A Fair and Secure Mobile Billing System, Computer Networks”, Vol. 48, No. 4, pp.517-524, 2005.
[10] K. Fujimura and Y. Nakajima, “General-purpose Digital Ticket Framework”, 3rd USENIX Workshop on Electronic Commerce, Boston, Massachusetts, Aug. 31-Sep. 3, 1998, pp.177-186.
[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, 2002.
[12] M. S. Manasse, “The Millicent Protocol for Electronic Commerce”, Proceedings of the 1st USENIX Workshop on Electronic Commerce, Jul. 11–12, New York, NY, 1995.
[13] T. P. Pedersen, “Electronic Payments of Small Amounts”, Proceedings of Cambridge Workshop on Security Protocols, LNCS 1189, pp.59-68, 1996.
[14] R. L. Rivest and A. Shamir, “PayWord and MicroMint: Two Simple Micropayment Schemes”, CryptoBytes, 2(1), pp.7-11, 1996.
[15] L. Buttyan and J. P. Hubaux, “Accountable Anonymous Access to Services in
Mobile Communication Systems”, Proceedings of the 18th IEEE Symposium on
Reliable Distributed Systems (SRDS’99), Workshop on Electronic Commerce, 1999, pp.384-389.
[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
Computing and Networking, Budapest, Hungary, 1997, pp.223-233.
[18] H. Wang, J. Cao and Y. Zhang, “Ticket-based Service Scheme for Mobile Users”,
the 25th Australian Computer Science Conference (ACSC2002), Conference in
Research and Practice in Information Technology, Melbourne, Australia, 2002, pp.285-292.
[19] N. Asokan, V. Shoup and M. Waidner, “Asynchronous Protocols for Optimistic Fair Exchange”, Proceedings of the IEEE Symposium on Research in Security and Privacy, pp.86-99, 1998.
[20] N. Asokan, V. Shoup and M. Waidner, “Optimistic Fair Exchange of Digital Signatures”, IEEE Journal on Selected Areas in Communications, 18(4), pp.593-610, 2000.
[21] T. Coffey, P. Saidha, “Non-repudiation with Mandatory Proof Receipt”, ACM SIGCOMM Computer Communication Review, 26(1), 1996.
[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, 1995.
[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.133–144, 1996.
Author Biographies
Yu-Yi Chen was born in Kaohsiung, Taiwan, in 1969. He received the
B.S., M.S., and Ph.D. in Applied Mathematics from the National Chung Hsing University in 1991, 1993, and 1998, respectively. 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 1961. 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 respectively. 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 1951. 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 1980. He studied Software Engineering and Human-Computer Interface in the University of Maryland, College Park, MD, during 1984-1986. 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.
Table 1. The non-repudiation proofs of each phase
Non-repudiation proof Proof issuer Proof holder Verification
) , (Mtran SGMNSP MNSP TSP VMNSP SGMNSP Mtran ? ) ( = ) ,
(Mresp SGOBS Observer MNSP, TSP
resp OBS OBS SG M V ? ) ( = ) , (Mresp SGTSP TSP Observer, Subscriber VTSP SGTSP Mresp ? ) ( =
Figure 1. The participating parties in a ticket transaction and coordinate messages of whole process Subscriber
Verifier Phase I : Ticket Request
1.The Subscriber establishes a communication channel with the MNSP, and proposes a mobile ticket request. 2. MNSP generates a unique transaction number, signs the ticket request, and then sends the request to the TSP.
Phase II :Ticket Issue
3. The TSP verifies the MNSP’s signature for this transaction, and generates a mobile ticket.
4. The Observer authenticates the Subscriber’s request, verifies the MNSP and TSP’s signature, and then generates the response signature for the TSP.
5. The Observer generates the hidden mobile ticket for the Subscriber. It also forwards the hidden mobile ticket and the response signature to the MNSP.
6. The MNSP 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 Verification
7. The Subscriber carries the PTD, which stored the mobile ticket, to request the related service. The Verifier verifies the mobile ticket. 8. The Verifier uploads the used ticket to the TSP in batch processing. 1 6 2 3 4 5 7 MNSP TSP 8 Observer
