A secure e-ticketing scheme for mobile devices with Near Field

IEICE TRANS. FUNDAMENTALS, VOL.E93–A, NO.1 JANUARY 20101

PAPER Special Issue on Trust, Security and Privacy in Computing and Communication Systems

A secure e-ticketing scheme for mobile devices with Near FieldCommunication (NFC) that includes exculpability and reusability

Arnau VIVES-GUASCH †a), Student Member, Magdalena PAYERAS-CAPELLA††b),Macia MUT-PUIGSERVER ††c), Jordi CASTELL A-ROCA †d),

and Josep LLUIS FERRER-GOMILA ††e), Nonmembers

SUMMARY An electronic ticket is a contract, in digital format, be-tween the user and the service provider, and reduces both economic costsand time in many services such as air travel industries or public transport.However, the security of the electronic ticket has to be strongly guaranteed,as well as the privacy of their users. We present an electronic ticketing sys-tem that considers these security requirements and includes the exculpabil-ity as a security requirement for these systems, i.e. users and the serviceprovider can not falsely accuse each other of misbehavior. The system en-sures that either both parties receive their desired data from other or neitherdoes (fair exchange). Another interesting property is reusability. Thanks toreusability the tickets can be used a predefined number of times with thesame security as single tickets. Furthermore, this scheme takes special careof the computational requirements on the users side by usinglight-weightcryptography. We show that the scheme is usable in practice by means ofits implementation using mobile phones with Near Field Communication(NFC) capabilities.

key words: security, privacy, electronic commerce, e-commerce, electronicticketing, e-ticketing

1. Introduction

Information technologies (IT) are becoming usual in oursociety as they progressively replace the use of paper inmany of our common operations. An example of paperticket could be the air flight boarding pass. Vodafone andSpanair [1] conducted an e-ticketing test in Spain (May2007). The passengers received the electronic boarding passin their mobile phone, and they were able to go directly tothe security control area, and later board. The InternationalAir Transport Association (IATA) started in 2004 a programto introduce the use of electronic tickets. IATA estimatesthat the no-use of paper tickets will reduce the costs by US$3000M [2] boosting disintermediation by using electronictickets. The electronic tickets have not been used only as aboarding pass. They can also be used in multiple transportservices. The AMSBUS [3] booking system from the Czech

†Dpt. d’Enginyeria Informatica i Matematiques, UNESCOChair in Data Privacy, Universitat Rovira i Virgili, Av. Pa¨ısos Cata-lans 26, E-43007 Tarragona, Spain††Dpt. de Ciencies Matematiques i Informatica, Universitat de

les Illes Balears, Ctra. de Valldemossa, km 7,5. 07120 PalmadeMallorca, Spain

a) E-mail: [email protected]) E-mail: [email protected]) E-mail: [email protected]) E-mail: [email protected]) E-mail: [email protected]

DOI: 10.1587/transfun.E93.A.1

Republic allows the purchase of SMS tickets. The passengerreceives the ticket in her mobile phone; then, the user showsthe message to the ticket inspector when needed. LeedsUnited [4] supporters can book one of their sport events andlater receive an SMS with the booking confirmation togetherwith some added information such as the assigned seat.These examples show the progressive introduction of elec-tronic tickets on different kinds of services and the increas-ing use of mobile phones in all of them as the most suitablee-ticket storage device. In addition to that, the real applica-tion of these electronic ticketing systems depends on theirsecurity, due to the ease of copy of electronic data. Elec-tronic tickets have to keep the same security that is offeredin paper tickets.

The main focus area of the present paper is the devel-opment of a secure e-ticketing scheme for mobile devices.Our protocol presents a fair-trading mechanism during theticket verification in such a way the user pays in exchangeof the right to use the agreed service. As in our previouswork [5], the protocol is designed to meet the set of securityrequirements for such schemes described in Section 2.1. Wewould like to highlight the exculpability property, which is anew property that we have first introduced in the e-ticketingschemes (i.e. the service provider can not falsely accuse theuser of ticket overspending, and the user is able to demon-strate that she has already validated the ticket before usingit). In addition to that, now the protocol has been enhancedwith the property of reusability (i.e the tickets can be usedapredefined number of times with the same security as singletickets). The final contribution of our paper is the imple-mentation of the proposed e-ticketing protocol using light-weighted mechanisms by means of low computational com-plexity cryptography and low communicational overhead.

1.1 Organization

An analysis of the previous works related to our proposalis presented in Section 2. Later, in Section 3, our schemeis accurately defined. The security and privacy analysis ofthe scheme is detailed in Section 4. Implementation detailsand performance results is given in Section 5. Finally, theconclusions and future work are described in Section 6.

Copyright c© 2010 The Institute of Electronics, Information and Communication Engineers

2IEICE TRANS. FUNDAMENTALS, VOL.E93–A, NO.1 JANUARY 2010

2. Previous work

First of all, in Section 2.1, we start presenting the secu-rity requirements that have to be achieved in these systems,as well as we introduce a new security requirement thatis not achieved in the previous works and which could betaken into account in the future:exculpabilitytogether witha property that we have recently achieved:reusability. Sec-tion 2.2 lists other relevant properties of e-ticketing systems.Once the requirements are described, the e-ticketing propos-als have been classified in Section 2.3.

2.1 Security requirements

E-ticketing systems have to consider and guarantee the fol-lowing security requirements:

• Authenticity : A user has to be able to verify if an e-ticket has been issued by an authorized issuer.

• Integrity: A user has to be able to verify if his e-tickethas been altered as regards the one issued by the corre-spondent authorized issuer.

• Non-repudiation: Once a valid e-ticket has been issued,the issuer cannot deny that he has issued that ticketwith its contents. Observe that, in fact, this propertycomprehends the two previous properties: if the issuercan not deny having issued an e-ticket it means that in-tegrity and authenticity properties have been achieved.

• Unforgeability: Only authorized issuers can issue valide-tickets.

• Non-Overspending: E-tickets can only be used asagreed between the issuer and the user. Non-reusablee-tickets can not be reused after they have been spent(by the same or other users). Reusable e-tickets can beused exactly the number of times agreed in the momentof issue. Finally, some e-tickets can not be used aftertheir valid period of time. Mechanisms to control over-spending can affect the following property: anonymity.Overspending can be prevented or detected. If over-spending is detected in the verification phase over-spending will not be allowed. If it is detected after-wards, some way to identify the overspender or possi-ble overspenders will be necessary. Some authors [6]call duplication to this property.

• Anonymity: Not all the paper-tickets present the samerequirements related to anonymity, so we have to dis-tinguish some possible scenarios for e-tickets. Thereare two anonymity degrees: non-anonymous (the ser-vice requires user identification and authentication) andrevocable anonymous (the service is anonymous, but itcan be revoked if the user misbehaves).

– Non-anonymous e-tickets: Some e-tickets willhave to be non-anonymous; it means that useridentity has to be embedded in the e-ticket in someway, in order that the service provider could ver-ify that the user is authorized to spend the e-ticket.

This is the case of plane e-tickets. In the boardingphase the auxiliary staff of the Air Company haveto be able to verify that the flyer identity is thesame as the identity contained in the e-ticket.

– Anonymous e-ticket: Some paper tickets allowusers to remain anonymous in front of the issuerand/or the verifier. Therefore e-tickets will have tomaintain the property. Perhaps in the issue phasethe user is identified (it depends on the kind ofpayment used), but that payment has not to belinked to the issued e-ticket. In any case, it has tobe able to spend the e-ticket without any kind ofidentification. Even colluded issuers and serviceproviders should not be able to break anonymityof honest consumers.

– Revocable anonymity: If overspending is detectedafter the verification process, it means that thesame e-ticket could be used more times than de-sired (by issuer and/or service provider). For non-anonymous e-ticket this is not a problem: weknow overspender user and so actions can be un-dertaken. For anonymous e-tickets, anonymityhas to be revocable in order to identify over-spenders. Obviously, fair users would have toremain anonymous or, at least, they would haveto be able to prove they are fair users. Some e-ticketing schemes allow also the revocation of theanonymity of the user if he misbehaves using theservice.

• Expiry date: A ticket could be only valid during a timeinterval.

• Online/Offline: Ticket verification can require a persis-tent connection with a trusted centralized system (on-line); otherwise, that connection is never necessary (of-fline).

• Fairness: During the execution of an e-ticketing proto-col the parties execute several exchanges of elements.One of these exchanges is produced during the issuephase. Many times an e-ticket is exchanged for a pay-ment or some other element. We can think of some ex-ceptions: donations (between users), free e-ticket (forsome events), etc. But in the general case user willhave to pay for an e-ticket. During the validation phaseanother exchange is produced between the user and theprovider: the ticket and the service (for that reason theycan exchange exculpability proofs). Therefore a pro-tocol for that exchange will have to be designed, andsome properties achieved. We are in front of a kind offair exchange of values (an e-ticket for a payment, aserveice for an e-ticket), and so, some of the followingproperties will be necessary: fairness, abuse-freeness,timeliness, verifiability of the TTP, etc. It is out of thescope of this paper to explain these properties that canbe found, for instance, in [7].

• Transferability: Some paper tickets can be transferredto other people (spectacle tickets, bus tickets, etc.). Ob-

VIVES-GUASCH et al.: A SECURE E-TICKETING SCHEME FOR MOBILEDEVICES WITH NEAR FIELD COMMUNICATION (NFC)3

viously it is not the case of identified e-tickets (planee-tickets, etc.). People receiving an e-ticket in a trans-fer (not directly from an authorized issuer) has to beable to verify that this e-ticket is valid (it will be easyif non-repudiation, integrity and authenticity are met)and not spent by the transferring entity. When we arein front of gifts or donations between confident people(a friend, familiar, etc.) no special measures have tobe taken, it’s a personal matter if afterwards an over-spending occurs. But perhaps e-tickets can be resold,or e-tickets (spectacle entrances) can be a present froma third company (in exchange of buying some productfrom this company). The receiving entity has to be surethat the e-ticket is valid and not spent. But its possiblethat the user will try to overspend the e-ticket, and thetransferring entity has to be able to prove he has notre-used the e-ticket. This problem should be speciallyhandled when anonymity is revocable. Transferabilitywill make necessary the fairness property.

2.1.1 Exculpability

None of the analyzed proposals deals with exculpability;that is, the service provider can not falsely accuse the userof ticket overspending, and the user is able to demonstratethat she has already validated the ticket before using it. Theexculpability is an interesting issue in our case, becausethe e-ticketing scheme should ensure that either both par-ties (users and provider) receive their desired data (e-ticketand the validated e-ticket) from other or neither does (fairexchange). The parties agree to reveal its data only if theother part also agrees. If any party deviates from the schemethen it can be identified as the culprit by the Trusted ThirdParty (TTP). Our scheme defined in Section 3 takes excul-pability as a security requirement for an e-ticketing system,as the first step to include this security requirement in futureworks.

2.1.2 Reusability

A ticket could be used once (non-reusable) or many times(reusable). In both cases, ticket overspending has to be pre-vented. Tickets can be used more than once as is the case ofsome urban transport, where a transport pass can be used forseveral travels (and a counter is decreased in every travel)orit can be used over a period of time. Even, sometimes, thesame ticket can be used in different places (for instance, busand underground in the same city). E-tickets have to incor-porate security measures that allow using the ticket in thevalid period of time or for the number of uses agreed (or acombination of both, time and uses). Some authors namedivisibility to this property (probably influenced by the sim-ilarities between e-ticket and e-money).

2.2 Other requirements

There are some other requirements that they are not so di-

rectly related to security, but they can be so important thanthose explained previously.

• Portability: E-tickets, as paper tickets, have to beportable by users. So, it has not to be necessary a lap-top or a personal computer to handle e-tickets. Mobilephones, smart cards, etc. will have to be able to storeand process e-tickets.

• Reduced size: Typically, e-tickets will be stored inmobile devices (a mobile terminal as a mobile phone,a smart card, etc.), and sometimes these devices willhave a limited memory. Therefore, e-tickets have to bereduced in size as possible.

• Flexibility: We can think of a lot of different tick-ets (plane tickets, bus tickets, concert tickets, museumtickets, etc.). We can design a specific e-ticket for eachapplication, or we can adapt a general e-ticket for eachapplication. Obviously the later solution is preferredin order to economize the solution, and it will allow abetter security analysis.

• Ease of use: We are thinking e-ticketing as a solu-tion for general public (using paper tickets nowadays,and not necessary especially confident in electronicmeans). E-tickets have to be as easy to use as papertickets, and without new problems for users.

• Efficiency: We can think efficiency from two points ofview. First, mobile terminals can be limited in terms ofcomputational power, and so protocol operations andespecially cryptographic operations have to be reducedonly to necessary ones. Second, communication ca-pacity can also be limited, and so the protocol has tobe designed with this constrain in mind. Whatever, thedelay due to verification of validity of e-ticket has to bereasonable to be a valid solution for ticketing by elec-tronic means.

• Payment system: The design of an e-ticketing systemhas to bear in mind that sometimes it will be necessarya payment system to obtain the e-ticket. So, e-ticketingsystem has to allow different payment systems to beused in order to pay for the e-ticket (if necessary).

• Globally-spendable: Costumer should be able to spendtheir e-tickets at any appropriate service provider.

• Offline verification: In some scenarios it will not bepossible to contact with external databases or TrustedThird Parties, to verify if e-ticket is valid or not. Per-haps it will not be the general case, but a solution forthis case has to be thought. This property is much re-lated to the security mechanisms adopted. If an onlinesolution is preferred, efficiency has to be especially re-membered.

• Availability: This property can be seen as a securityproperty, but it is quite difficult to address this problemonly as a security one. We are thinking in denial of ser-vice attacks (difficult to handle), disaster events (moredifficult to handle) or temporal malfunction of infras-tructure (for instance, a power failure). This can meanthat e-tickets can not be verified, and sometimes the


event can not be delayed (a concert, a plane, etc.). Aprocedure to handle these situations has to be designed.

2.3 Classification of proposals

In this section, the proposals have been differentiated bythe devices used in the systems: thesmart-card-based, andthenon-smart-card-basedones, with a deeper analysis per-formed in the non-smart-card-based proposals, taking intoaccount their anonymity compliance.

2.3.1 Smart-card-based

Smart-card-based proposals [6], [8]–[13] establish a com-munication channel with the verification system. Thus, themost sensitive operations are sent to the smart-card throughthis channel. The smart-card verifies each operation, so thatusers can not perform any non-allowed action. Security ofsmart-card-based systems rely on the smart-card security.Ifthe smart-card security is compromised, the security of theentire system is also compromised. One recent example isthe case of the Mifare cards, where in [14] the authors suc-ceeded to compromise them. As a result, all the entire pub-lic transport system that used exclusively Mifare cards wascompromised.

2.3.2 Non-smart-card-based

Non-smart-card-based systems [15]–[21] allow to performapplications with higher computation requirements whiletaking advantage of their high storage capacity and also theirwireless short-range communication resources; this is thecase of the mobile phones, smart phones or PDA’s. How-ever, as these devices are not considered tamper-proof de-vices, e-ticketing systems require then high-level crypto-graphic protection in order to assure that users follow thee-ticketing protocol correctly. We classify the non-smart-card-based systems depending onnon-anonymous, anony-mousandrevocable anonymouscompliance.

(1) Non-Anonymous proposals

Some proposals are oriented to services where anonymitycan not be provided to the user, or simply, these systemsare not conceived to achieve anonymity at all. Between theproposals that do not consider anonymity, digital signaturesare commonly used [16], [17].

In [17], either the user or the e-ticket should be identi-fied in order to prevent problems such as malicious attacks.There is a real relationship between anonymity and trans-ferability for user and e-ticket identification and reusabilityis also considered for other ticket information, such as itsdestination. Online mode is used in this scheme for secu-rity reasons, as they say offline systems show weaknesses tomalicious attacks.

(2) Anonymous proposals

Haneberg et al. [18] present an electronic onboard ticketing

scheme, by using a PDA connected to the system throughBluetooth and using Java for all applications. PDAs arechosen for their short-range wireless communications andthe display. Anonymity is achieved in this proposal as nopersonal data is needed, and anonymity then only dependson the payment method used.

In [19], Quercia and Hailes’ e-ticketing system proposalis based on Chaum’s e-cash blind signatures, providinganonymity to the user, but the communication cost couldbe high, and possibly slow down the system. Apart fromanonymity, non-repudiation, offline verification as well asportability are achieved in this proposed system.

The great majority of the described proposals that complywith anonymity are based on Chaum’s blind signatures [22].

(3) Revocable-Anonymous proposals

In the proposal of Patel and Crowcroft [15] the securityrequirements are defined, where revocable anonymity isachieved, as well as offline mode, although central authorityintervention is needed in order to prevent overspending.

Depending on the services, anonymity, transferability orreusability would be required in the Fujimura et al. pro-posal [23]. Pseudonyms are proposed if anonymity is re-quired, and overspending is controlled by a central database(online mode).

In [20], Heydt-Benjamin et al. made a proposal usinglatest advances in e-cash to improve privacy in electronicticketing systems for public transit. It uses pseudonyms inorder to achieve anonymity.Chen et al. [21] propose the use of mobile devices (mobilephones, smart phones or PDAs) in e-ticketing systems, bytaking advantage of their wireless communications. Theyfocus on the compliance of several security requirements,as (revocable) anonymity, non-repudiation, as well as effi-cient verification. The ticket process is defined in 3 phasesin the paper: request, issue and verification. Anonymity isachieved by the use of pseudonyms.

The majority of the studied proposals use pseudonyms inorder to achieve revocable anonymity. If pseudonyms areused, real identity information is not put into the ticket, onlyits pseudonym. But if the issuer could link every pseudonymto its real identity, then anonymity could be compromised.For that reason, only revocable anonymity for the user couldbe achieved. In this scenario, user traceability could be eas-ily performed if user does not change its pseudonym regu-larly because the same pseudonym would be used for dif-ferent tickets. Certain volume of data could allow all theinvolved participants to make user profiles if there were nopseudonym controls.

According to reusability there is a diversity of con-siderations; Patel and Crowcroft [15] believe that ticketscan be reusable; Haneberg et al. [18], Heydt-Benjamin et


al. [20] and Chen et al. [21] do not consider ticket reusabil-ity; finally, Quercia and Hailes [19] consider that reusabilitymainly depends on the service.

There is a remarkable equality between the proposalsthat use online verification [15], [20] and the ones whichuse offline verification [18], [19], [21]. Otherwise, tickettransferability is unanimously not considered in the propos-als [15], [18]–[21].

3. E-ticketing scheme

The e-ticketing scheme has been designed for mobiledevices, reducing the computation requirements in the userside, and providing the basic security requirements (au-thenticity, non-repudiation and integrity) together withex-piry date, revocable anonymity, exculpability and reusabil-ity. The ticket verification is performed offline when thereis only one provider for each service, although the schemecould be extended with multiple providers that offer thesame service. In that extended case, the scheme wouldprevent overspending through online verification, requiringthen the interconnection of the service providers which of-fer the same service. In any case, the connection with theissuer is never necessary. In Table 1, we define the detailsof our proposal, as well as some notation that is used in thescheme.

3.1 Phases

The scheme has the following actors: the userU, the ticketissuerI, the service providerP, and the TTPT . The phasesof our system consist of the traditional phases (ticket pur-chase and verification), and we add another phase in orderto register and obtain temporal pseudonyms without link-age to user’s identity (if user behaves correctly), in orderto

Table 1 Details of the proposal: security requirements, actors, ticketinformation and receipt information

Security RequirementsAuthenticity Non-repudiation

Integrity Revocable anonymityNon-overspending Offline verification

Expiry date ExculpabilityReusability

ActorsUser U Service Provider P

Ticket Issuer I Trusted Third Party T

Ticket Information (T)Serial number Sn Issuer Is

Service Sv Terms and conditions TcUser pseudonym PseuU Attributes At

Type of ticket Ty Verification data δT ,P

Validity time Tv Date of issue TiExculpability (U) h(rU ,n) Exculpability (P) h(rI ,n)

Digital signature ofI SignI(T)

Receipt Information (R)Exculpability (P) AP Timestamp τi

Ticket serial number T.Sn Digital signature ofP SignP(R)

achieve anonymity. We can see in Figure 1 the diagram ofthe entire protocol, with all its actors and phases. Then, theresulting phases are:Pseudonym Renewal, where the userobtains a new temporal pseudonym to be used in the system;Ticket Purchase, that consists on the payment of the serviceand reception of the ticket; andTicket Verification, wherethe user shows the ticket to the service provider in order tobe checked and validated. Other phases considered in thesystem are claims. These claims should only be executed incase of controversial situations during theTicket Verificationphase:Claimm2 Not Received(whenU sends the first stepof the verificationm1 but does not receivem2 by P, or theinformation is not correct);Claimm3 Not Received(whenPsends the second step of the verificationm2 but does not re-ceivem3 byU, or the information is not correct); andClaimm4 Not Received(whenU sends the third step of the verifi-cationm3 but does not receivem4 by P, or the informationis not correct). Users have a digital credential (CertU) forauthentication to the TTP only, as the system is anonymous,and all further movements in the system are tracked onlywith the assigned temporal pseudonym (PseuU).

Fig. 1 Diagram of the entire protocol

3.1.1 Pseudonym Renewal

The userU contacts the pseudonym managerT in orderto renew the assigned pseudonym. The certificateCertUidentifiesU through a secure connection established be-tween the two parties. The system has the public param-eters (α, p, q), whereα is a generator of the groupG withorderp, beingp andq large primes achievingp = 2q+ 1.

U generates a random valuexUR← Zq and computesyU =

αxU (mod p) in order to receive a valid signed pseudonymPseuU fromT . U andT have their own pair of keys usedfor signature and encryption of the transmitted data betweenthem.

authenticateUser UserU follows the next steps:


1. generatesxUR← Zq, and computesyU = αxU (mod p);

2. computes the signatureSignU(yU) = skU(hyU ) † wherehyU = hash(yU) ††;

3. encrypts the information to be sent (yU ,SignU(yU),CertU)with the T ’s public key as a digital envelope:pkT (yU ,SignU (yU),CertU) †;

4. sendspkT (yU ,SignU(yU),CertU) toT ;

generatePseudonymPseudonym ManagerT executes:

1. decryptsskT (pkT (yU , SignU(yU),CertU))→ (yU ,SignU(yU),CertU);

2. verifiesyU: pkU(skU(hyU ))→ (hyU )?= hash(yU );

3. if correct, then computes the signature ofSignT (yU) =skT (hyU );

4. encrypts the signature with theU’s public key:pkU(SignT (yU));and

5. sendspkU(SignT (yU)) toU.

verifyPseudonym U computes:

1. decryptsskU(pkU(SignT (yU)))→ (SignT (yU));

2. verifies the TTP signature ofyU : pkT (skT (hyU )) → (hyU )?=

hash(yU );

3.1.2 Ticket Purchase

The user establishes a connection with the ticket issuerI

in order to receive the ticket. This connection could beestablished through an anonymous channel like TOR [24],guaranteeing then user’s privacy. There are current contri-butions†† that have implemented TOR for mobile deviceswith Android.I has a key pair and its public key certificate(CertI). Users do not use their personal keys (it would causeloss of anonymity); they use the temporal pseudonyms andauthenticate through the Schnorr’s Zero-Knowledge Proof(ZKP) [25]. The payment method is considered as out ofscope in this proposal as we focus on the privacy given touser when joining/exiting the system, and using the service.I generates the ticket with the information and its digitalsignature, together with the secret valuerI and the secretshared key (they are decryptable only byP andT ) in orderto let the provider show the secret valuerI later, in the ver-ification phase. The ticket issuerI and the userU followthis protocol:

getService U executes:

1. selects and pays for the desired serviceSv;

2. generates a random valuerUR← Zq, and computesh(rU ,n) =

hashn(rU), wheren is the predefined maximum number oftimes that the e-ticket can be spent;

†Note thatskE(content) means the decryption ofcontentor thegeneration of a signature with its contentcontentby using the pri-vate key of the entityE††Note that hash() is a public cryptographic one-way sum-

marizing function that achieves collision-resistance. The nota-tion hash(item)n is used to describe that the hash function isapplied n times over theitem (i.e. hash(item)n = hash( ......n

(hash(hash(item)))†Note thatpkE(content) means the encryption ofcontentor the

verification of a signaturecontentby using the public key of theentityE††http://sourceforge.net/apps/trac/silvertunnel/wiki /TorJavaOverview

!"#$%&'"()" #$%&'"*)" %&"

+,(,%-./("

Fig. 2 Hash Chain

3. computesHU = αrU (mod p);

4. generates two more random valuesa1,a2R← Zq to be used in

the Schnorr proof;5. computesA1 = α

a1 (mod p);6. computesA2 = α

a2 (mod p);7. sends (PseuU ,HU ,A1, A2, h(rU ,n),Sv) to the ticket issuerI.

getChallenge I follows the next steps:

1. generates and sends a challengecR← Zq forU;

2. asynchronously, for optimization, pre-computesyUc (mod p);3. asynchronously, for optimization, pre-computesHU

c (mod p);

solveChallengeU computes:

1. computesw1 = a1 + c · xU (mod q);2. computesw2 = a2 + c · rU (mod q);3. encrypts (w1,w2) and sends it toI: pkI((w1,w2));4. pre-computes the shared session key used in the ticket verifi-

cation:K = hash(w2);

getTicket I follows the next steps:

1. decryptsskI(pkI(w1,w2))→ (w1,w2);2. computesαw1 (mod p);3. computesαw2 (mod p);

4. verifiesαw1?= A1 · yUc (mod p);

5. verifiesαw2?= A2 · HU

c (mod p);6. computes the shared session key:K = hash(w2);

7. obtains a unique serial numberSn, and a random valuerIR←

Zp;8. computesh(rI,n) = hashn(rI);9. composesκ = (K, rI) and signs itκ∗ = (κ,SignI(κ));

10. encryptsκ∗ with a digital envelope which is decryptable by theTTPT and the providerP for possible future controversial sit-uations during the ticket verification:δT ,P = pkT ,P(κ∗). Thisa mechanism that preventsI from forging rI, becauseT cancheck that information and, demonstrate thatI is the culprit;

11. fills out the ticket informationT (Sn, Sv, PseuU, Tv, Ti,h(rI ,n), h(rU ,n), δT ,P, etc.);

12. digitally signs the ticketT, and obtains the signed ticket,SignI(T) = skI(hash(T)), andT∗ = (T,SignI(T));

13. sendsT∗ to the userU.

receiveTicket U executes:

1. verifies the digital signatureSignI(T) of the ticketT using theissuer’s certificate;

2. verifies that ticketT data and the performed request match;3. verifies the ticket validity (T.Ti,T.Tv);4. verifiesT.PseuU;5. stores (T∗, rU , j = 0) in the device. We set upj to 0 because

represents the occasions that the e-ticket has been used. Thee-ticket will be consumed whenj = n.

3.1.3 Ticket Verification

When the user wants to use the service, she must verify theticket in advance. For simplicity, we present the ticket ver-ification with only one provider, so the service providerP


never needs permanent communication with the ticket is-suer. Nonetheless, the protocol can be extended for multipleproviders. In that case, all the service providers should beconnected to a central repository of spent tickets in orderto control ticket overspending. In all these situations, whena ticket starts its verification process, the database has tolock its item (keyed with the unique serial number of theticket) in order to allow concurrent accesses to the databasefor different tickets; in this case, if another user tried to ver-ify the same ticket in another provider concurrently, it couldnot be possible. The user only interacts with the serviceprovider, but in controversial situations, she and/or the ser-vice provider could interact directly with the TTP througha resilient connection in order to preserve the security re-quirements of the protocol. If user misbehaved, her identitycould be revoked, enabling to take further actions.U sends the ticketT∗, andP checks it. If passed,P sendsthe commitment so thatrI will be disclosed ifU behavescorrectly. Once the user sends the secret valuerU encryptedthrough a shared key, then she receives the secretrI togetherwith the receiptR∗ fromP. The service providerP and theuserU do the following steps:

showTicket U computes:

1. sends ticketm1 = (T∗, i) to P. As a general case, we supposethat the service costss of the n times that the e-ticket can bespent. So, the valuei is computed asi = j + s;

verifyTicket P executes:

1. verifies the ticket signature,T.Sv, T.Ti, andT.Tv;2. if the verifications fail,P omitsm1, and aborts the ticket veri-

fication;3. elseP looks for the ticketT∗ in the database usingT.Sn

and locking this item; later, it verifies that the ticket has notbeen spent by retreiving the information related to the ticket( j, h(rU ,n− j)) in the provider’s database (if no information isfound, thenj is set to j = 0):

a. if (i > j) then:

i. computesAP,i = PRNG(hK) ⊕ h(rI ,n−i), wherePRNG(hK) is a secure pseudorandom numbergenerator and,hK = hash(K) is the seed. Note thatK andrI are obtained fromδT ,P, then the provideris able to computeh(rI,n−i) = hash(n−i)(rI);

ii. encryptsAP,i with the public key of the TTPT :pkT (AP,i );

iii. storesAP,i for future use;iv. assignsVsucc = (T.Sn, flag1, τ1, pkT (AP,i ), j), (τ1

is the verification timestamp). The flagflag1 in-dicates that the ticket is valid and has not beenspent yet. The signature is noted:Vsucc

∗ =

(Vsucc, skP(hash(Vsucc)));v. sendsm2 = Vsucc

∗ toU;

b. if (i ≤ j) then:

i. computesh(rU ,n−i) = hash( j−i)(h(rU ,n− j))ii. assignsVfail = (T.Sn, h(rU ,n−i), flag0, i, τ1). The

flag0 indicates that the ticket has been spent, i.e.is not valid. The signature is noted:Vfail

∗ =

(Vfail, skP(hash(Vfail)));iii. sendsm2 = Vfail

∗ toU;

showProof U executes:

1. verifiesP’s signature;

!"#$%&

'!()*#&

+&,-./0&12& ,-./0&1342& ,-./0&52& ./&,-./0&1362&

7189:&4&

*;<=&'<98&

7189:&6&

".9<91=98&

Fig. 3 Correct use

!"#$%&

'!()*#&

+&,-./0&12& ,-./0&1342& ,-./0&52& ./&,-./0&1362&

7189:&4&

".9;91<98&

7189:&6&

*=;<&';98&

42&

Fig. 4 Reutilization

2. if Vsucc∗ or eitherVfail

∗ are not received, theClaim m2 NotReceivedis called;

a. if Vfail∗ is received,U aborts the verification process.

If the response is not correct,U can contact with theTTP to reconsider the situation by callingClaim m2 NotReceived;

b. if m2 = Vsucc∗ is received,U has to verify the signature

and data. If verifications are correct she continues theprotocol. Otherwise,U can contact the TTP by callingClaim m2 Not Received;

3. calculatesAU,i = PRNG(K) ⊕ h(rU ,n−i), using the shared valueK as seed;

4. sendsm3 = (T.Sn,AU,i ) toP;

verifyProof P follows the next steps:

1. if h(rU ,n−i) is not received, theClaimm3 Not Receivedis called;2. obtainsT.Sn, and computesh(rU ,n−i) = AU,i ⊕ PRNG(K);

3. verifiesh(rU ,n− j)?= hash(i− j)(h(rU ,n−i));

4. if h(rU ,n−i) does not match, theClaim m3 Not Receivediscalled;

5. generatesτ2 and verifies it using the ticket expiry date(T.Ti,T.Tv) and the timestampτ1;

6. signsAP,i approving then the validation with timestampτ2:R = (AP,i ,T.Sn, τ2), andR∗ = (R, skP(hash(R)));

7. stores, updates its database, and unlocks theSn from thedatabase: [R∗, (h(rU ,n− j) J h(rU ,n−i)), ( j J i)] †;

8. sendsm4 = R∗ toU;

getValidationConfirmation U follows the next steps:

1. checks the signature ofR∗;2. computesh(rI,n−i) = AP,i ⊕ PRNG(hK);

3. verifiesh(rI,n− j)?= hash(i− j)(h(rI ,n−i));

4. if all verifications are correct, then stores and updates herdatabase [R∗, (h(rU ,n− j) J h(rU ,n−i)), ( j J i)]; or else callsClaim m4 Not Receivedto the TTP.

TheTicket Verificationprotocol is a fair exchange pro-tocol with the existence of an offline TTP [26] between theuser and the provider of the service (a valid e-ticket is givenin exchange for the permission to use the service). This en-ables dispute resolution protocols in case of incorrect be-haviour of the actors so as to preserve the security of the

†The notationa J b is used to describe a database update op-eration where the value represented bya is replaced byb


system. In case of dispute, they can contact the TTP follow-ing these protocols:

3.1.4 Claimm2 Not Received

This protocol can be executed ifU sendsm1 and says thatshe has not receivedm2 = Vsucc

∗ fromP.

Claim UserU executes:

1. sends the ticketm1 = (T∗, i) to the TTPT ;

ResponseTTPT follows the next steps:

1. checks the information, signature and timestamp;2. if the verification is correct, generates (T.Sn, τ3); then3. signs the informationm5 = ((T.Sn, τ3), skT (hash((T.Sn, τ3)));

and4. sendsm5 to bothU andP. This entails acceptance ofU’s

sent information and thenP has the responsibility to unblockand send a correctm2 to continue with the verification phase atsub-phaseverifyTicket. After that, if the service could not befinally guaranteed,U could demonstrate to a third party (byshowingm5) thatU behaved correctly andP was the respon-sible of the denial of service;

verifyTicketWithTTP Service providerP executes:

1. executesverifyTicketnormally;2. sendsm2 to bothT andU, and continues theTicket Verifica-

tion steps at pointshowProof. The TTP has to storem2 andm5 because the user can go to an external dispute resolutionsystem (ifm2 is still wrong) to solve the problem. In this case,the TTP will be able to provide these evidences;


This protocol can be executed ifP sendsm2 and says thathas not receivedm3 = AU,i (with a correcth(rU ,n−i) inside)fromU.

Claim ProviderP executes:

1. blocks the ticketT.Sn till the reception ofm3 fromU or m5byT ;

2. anotherT.Sn′ received from the same connection could not beaccepted andm2 = Vsucc

∗ would be repeatedly sent in order tounblock the ticket identified byT.Sn.


This protocol can be executed ifU sendsm3 and says thathas not receivedm4 = R∗ (with the containedh(rI ,n−i)) fromP.

Claim UserU follows the next steps:

1. sends to the TTPT : (m1,m2,m3) = (T∗,Vsucc∗, (T.Sn,AU,i ));

ResponseTTPT executes:

1. checks the entire information; if verification fails, aborts theclaim;

2. computesAP,i = PRNG(hK) ⊕ h(rI ,n−i) usingK andrI. Notethat K andrI can be obtained by decryptingδT ,P and thenPcan computesh(rI ,n−i) = hash(n−i)(rI);

3. checks thatAP,i (from the previous step)?= m2.Vsucc.AP,i ;

4. verifies that h(rI ,n−i) (computed at step 2) matches withT.h(rI,n);

5. checks thatm1.i > m2.Vsucc. j6. computesh(rU ,n−i) = AU,i ⊕ PRNG(K) and checks that

hashi (h(rU ,n−i))?= T.h(rU ,n)

7. if everything is successful, then generates (T.Sn,AP,i ,AU,i , τ4);otherwise, publishes which entity behaved corruptly in accor-dance with the above verifications;

8. signs the informationm6 = ((T.Sn,AP,i ,AU,i , τ4), skT(hash((T.Sn,AP,i ,AU,i , τ4)));

9. sendsm6 toU.

Outside the ambit of the telecommunications,m6 canbe used as an evidence in case of a user demand for the rightto use the service in an external dispute resolution system.

3.2 Multiple Providers

The described proposal considers that only one provideris able to give a certain service, enabling then offline ver-ification. Nevertheless, this scenario could be extended tothe existence of multiple providers that give a certain ser-vice and accept the same ticket in different places, but guar-anteeing the control of ticket overspending through onlineverification between all the providers. In this extended sce-nario,skP would be shared between the providers, enablingthe access toK and rI. There would be also special careto the distribution and control of used tickets (controlledbythe existence ofrU in the database for that ticket). Thereshould be a central database where all the providers couldstore all the used tickets, and then the verification wouldbe online by imperative. In this scenario, the central serverwould only control the database, as the providers could beable to verify signatures and make all the cryptographic op-erations in order to perform all the critical operations real-time. This central database can be in the cloud; nonetheless,this can cause a delay that should be studied in detail in fu-ture work. Another option is to have all the databases ac-tively connected one each other, and achieve Atomic Broad-cast as in [27] in order to perform atomic operations to thedatabases (i.e. avoiding concurrent verifications using thesame ticket in different providers). Expired tickets couldbe removed from the database for storage efficiency, and,moreover, only ticket serial number could be stored in thedatabase despite storing all the ticket information.

4. Security and privacy of the system

Proposition 1: The proposed e-ticketing system preservesauthenticity, non-repudiation, integrity and the expiry dateof the e-ticket.

Claim 1: It is computationally unfeasible to make a newfraudulent e-ticket.Security Argument.A valid e-ticket has the formT∗ =(T,SignI(T)). Then, the first step that the providerP doeswhen an e-ticket is received is the verification of the signa-ture. TheTicket Verificationprotocol will continue only ifthis verification ends correctly; otherwise,P refusesU’s re-quest. Thus, making a new fraudulent valid e-ticket would


be equivalent to break the signature scheme and that wouldbe computationally unfeasible as we have supposed that theissuerI uses a secure signature scheme.

Claim 2: The issuer can not deny the emission of a valide-ticket.Security Argument.A valid e-ticket hasI’s signature andthe signature scheme used is secure. Consequently, the iden-tity of the issuer is associated to the ticket; the signatureis anon-repudiation evidence of origin.

Claim 3: The content of the e-ticket can not be modified.Security Argument.Suppose that someone modifies the con-tent of the ticket, then a newI’s signature has to be gener-ated over the modified content; otherwise, the e-ticket willnot be valid. Again, if it is computationally unfeasible toforge theI’s signature, it is unfeasible to modify the con-tent of the e-ticket.

Claim 4: The e-ticket will not be longer valid after theticket validity timeT.Tv.Security Argument.The providerP receives the e-ticketfrom the user at theTicket Verificationprotocol before al-lowing access to the service. First of allP checks the cor-rectness of the e-ticket (obviously that includes the verifi-cation of T.Tv). If the verification is not correctP stopsthe protocol and the user will have no access to the service.Also, according theClaim 3, the user can not tamperT.Tv.

Result 1: According to the definitions given at Section 3and the Claims 1, 2, 3 and 4 we can assure that the protocolachieves the properties specified at Proposition 1.

Proposition 2: The e-ticketing system described in Sec-tion 3 is anonymous. The service offered is revocable anony-mous.

Claim 5: An e-ticket is anonymous.Security Argument.A valid e-ticket has the following in-formationT = (Sn, Sv, PseuU , Tv, Ti, h(rI ,n), h(rU ,n), δT ,P,

. . .). The information related to the user’s identity is solelyPseuU = (yU , skT (hash(yU))), whereyU = αxU (mod p).The user’s identity isxU, thus an enemy has to solve theproblem of computing the discrete logarithm to know theidentity of the user. Currently no efficient algorithms areknown to compute that.

Claim 6: The purchase of an e-ticket is anonymous.Security Argument.As the protocol in Section 3.1.2 spec-ifies, the channel betweenU andI of the ticket is anony-mous. The protocol uses a Schnorr’s ZKP to provide theuser identity to theI, so that the issuer can be sure thatthe connected user who wants to buy the ticket is the rightholder of the pseudonymPseuU without disclosing her realidentity. Thus, the user does not need to reveal her identityto buy an e-ticket.

Claim 7: A fake user cannot buy an e-ticket impersonatingother user.Security Argument.In order to buy a ticket, the user has to

perform a Schnorr’s ZKP to prove knowledge of the iden-tity to the issuer without revealing it. The user has to com-

putew1 such asαw1?= A1 · yUc (mod p). As far as any

user preserves the privacy of her identityxU (which links toCertU through the cooperation ofT ), anyone else will notbe able to compute suchw1. In this case, user can only beaccused throughxU of ticket overspending (supposing thatthe user keepsxU secretly), because she solely has the infor-mation to perform theTicket Verificationprotocol. Thus, thee-ticketing system also preserves the exculpability property.

Result 2: According to the definitions given at Section 3and the Claims 5, 6 and 7 we can assert the Proposition 2.The e-ticketing system is anonymous and this anonymitycould be revocable in case of a user’s fraudulent action. Thepseudonym managerT knows the correspondence betweenxU andyU (see Algorithm: ‘Pseudonym Renewal’). There-fore,T could reveal the association betweenxU andyU dueto law enforcement (e.g. a judge could request the user’sidentity toT ).

Proposition 3: The protocol satisfies the property of ex-culpability and a malicious service provider cannot reducethe times that a reusable ticket can be used.

Claim 8: The userU is able to prove that she has alreadyvalidated the ticket.Security Argument.If a userU executes successfully theTicket Verificationprotocol,U will obtain the exculpabil-ity proof rI. She can use this proof to demonstrate that theticket has been validated. If theTicket Verificationproto-col is stopped andU does not obtain the exculpability proofafter the revelation ofrU, she can executeClaim m4 NotReceived. This wayU would obtain an alternative exculpa-bility proof from the TTP.

Claim 9: The service provider can not falsely accuse theuser of ticket overspending.Security Argument.When the service providerP receivesthe messagem1 in step 1 of theTicket Verificationprotocol(showTicket), P looks for the ticket that matches with thereceived serial number in its database. If the ticket had beenalready spent, the service provider will find the overspend-ing proof rU together with the ticket. The service providerhas to show this element to accuse the user of overspend-ing. If the user had not validated the ticket before, then theservice provider does not have the element (U will send itin step 3:showProof), as thehashinvertible function is be-lieved to be computationally infeasible, and also there cannot exist collisions in thishashfunction, soP can not falselyaccuse the user of overspending. If the service provider,even not being able to prove the overspending, decides todeny the service to the user, the user can contact the TTP inorder to solve the situation throughClaimm2 Not Received.

Claim 10: The providerP cannot falsely accuse the userof spending a couponh(rU ,n−i), which has not already used.Security Argument. The providerP cannot deduce anyh(rU ,n−k)∀k < j. When the userU spends theith coupon


of her ticket, she sendsh(rU ,n−i) to the providerP (see stepshoowProofof the Ticket Verificationprotocol). Then theprovider stores this value in order to avoid overspending.According to the hash functions properties and, as it showsin Figures 1 and 2, fromh(rU ,n−i) it is only possible to deductan h(rU ,n−k)∀k > j. Because it is not possible to go in thedirection ofrU. So, the provider is not able to deduce anynon-spent value of the hash function chain.

Result 3: According to the definitions given at Section 3and the Claims 8, 9 and 10 we can assure that the proto-col achieves the property specified at the Proposition 3. Theticket verification process is a fair exchange: any part canobtain the exculpability proof of the other part without re-vealing its own proof.

Proposition 4: The tickets issued by the protocol de-scribed in Section 3.1 can be preset to be reusable tickets,both for a limited number of validations or a limited periodof time.

Claim 11: The protocol allows the creation ofN-usabletickets maintaining the security properties of the nonreusable tickets, including exculpability.

Security Argument.During the execution of theTicket ver-ification protocol,U uses the last element of the chain ofproofsh(rU ,n) and receives in exchange an element contain-ing the last element of the chain of issuer proofsh(rI ,n).Due to the properties of hash functions,U cannot gener-ateh(rI ,n−i) andP cannot generateh(rU ,n−i). The successivevalidations will use the remaining elements of the chain inreverse order.

Claim 12: The protocol allows the creation of period-usable tickets maintaining the security properties of the nonreusable tickets, including exculpability.

Security Argument.In this case the concept of overspend-ing is not applicable. The user will obtain a validation proofeach time he executes theTicket Verificationprotocol ob-taining an exculpability proof provided the time of the veri-fication attempt is less than the limit of the validity period.

Result 4: According to the Claims 10 and 11 we can as-sert the Proposition 4. The protocol is flexible enough tobe used with all kinds of services, with independence of itsreusability requirements.

Proposition 5: The protocol avoids overspending withminimum requirements of persistent connections with a cen-tralized system.

Claim 13: The protocol avoids overspending.Security Argument.If a user tries to overspend a ticket, andsends toP a spent hash value (ah(rU ,n−i) with i > j). The

provider will verify thath(rU ,n− j)?= hash(i− j)(h(rU ,n−i)). This

verification will always fail, because the hash chain goesin the opposite direction (see Figures 1 and 2). Then theprovider will block the ticket identified byT.Sn till the re-ception of a non-spent hash value.

Claim 14: If the ticket can only be validated by oneprovider then the verification is totally offline.Security Argument.The providerP maintains a databasewith the serial numbers of the e-tickets that have been al-ready validated (together with their exculpability proofs) un-til their expiry date. With the contents of this database theprovider has enough information to decide ifP accepts andvalidates a new ticket becauseP can check both the issuer’ssignature and the fact that the e-ticket has not been spent be-fore. So the provider does not need to contact to any partyduring the validation of an e-ticket.

Claim 15: If the ticket can be validated with severalproviders then the providers must be connected and sharea database of spent tickets.Security Argument.The set of providers maintains a shareddatabase with the serial numbers of the e-tickets that havebeen already validated (together with their exculpabilityproofs) until their expiry date. The contents of this databaseare used by the providers to decide if they accept and vali-date a new ticket. So the provider does not need connectionto the issuer during the verification of an e-ticket, but the setof providers must have a shared database instead.

Result 5: According to the definitions given at Section 3and the Claims 10, 11 and 12 we can assure that the protocolachieves Proposition 5. The issuer is offline during the ver-ification phase and the providers contact among them onlyin some kind of services. In all cases, the protocol preventsticket overspending.

5. Implementation details and experimental results

There are several important factors to consider when we de-sign an e-ticketing system that should be usable in practice.The response time is one of them. Thus, we have imple-mented our protocol and we present some results regardingits time performance.

In Section 5.1, we describe the developed components,the development environment and the hardware that we haveused. Next, the testing methodology is described in Sec-tion 5.2, i.e. the system can be configured using differentkey lengths. We can assume that we would obtain more se-curity with larger keys but the computational cost will behigher. We want to study how the key length influence thecomputational cost. Next, we present the obtained resultsdifferentiating the costs in the user side (Section 5.3) andthe server side (Section 5.4).

5.1 E-ticketing system development and configuration de-tails

As introduced in Section 3, our system comprises three mainphases: pseudonym renewal, ticket purchase and ticket ver-ification, and four actors: the user, the service provider,the ticket issuer and the pseudonym manager. So that, thesystem implementation requires four components: one for


each entity in the system. Nonetheless, we have groupedin one server the service provider, the ticket issuer and thepseudonym manager for practical reasons, see Figure 5. Theserver takes the role of different servers in a PC. The servercomponent has been developed with the Java programminglanguage (Java 2 Standard Edition), allowing portability ina great number of platforms.

Fig. 5 Architecture of the testing environment

The user interacts with the other actors (the serviceprovider, the ticket issuer and the pseudonym manager) bymeans of a mobile phone, so that the user component (client)should be executed in a mobile phone. The Figure 6 showsthe protocols implemented in the client component. Giventhat a great number of mobile phones can execute Java ap-plications, we have developed the client in Java 2 Micro Edi-tion (J2ME). The mobile phone used has been a Nokia 6212Classic with an embedded API for NFC communication.

Fig. 6 Protocols of the client component

The communication between server and client isperformed via Near Field Communication (NFCIP-1,ISO18092). Nowadays, there are few mobile phones withNFC technology. Nonetheless, in a near future the mainsmart-phones platforms will include the NFC technology.Nokia has announced that from next year (2011) everyNokia smartphone will have NFC [28]. Android Ginger-bread 2.3 will support near field communications to readRFID tags as well as communicate with other phones, pay-ment systems and other possible applications [29], and Ap-ple is testing an iPhone with NFC chips [30]. The serveruses an Arygon NFC Reader (ADRA-USB) in order to con-nect with the mobile phone. The equipment of the entirescheme is detailed in Table 2.

It should be taken into consideration that the mobilephone acts as the initiator of the transactions, and the server

is the target, i.e. the server is waiting forU’s requests.Finally, we have used the BouncyCastle crypto library†

for all the cryptographic operations in both J2SE and J2ME.

5.2 Testing methodology

The e-ticketing system can be configured with the key lengthparameterl. This parameterl refers to the key size (in bits)of the RSA cryptosystem used in the protocol, as well as thenumber of bits of the generated prime numbers for the gen-eration of theZq andZp. The larger the parameter is, theharder is the cryptosystem to be broken, i.e. we have a sys-tem more secure. On the other hand, the time consumptionis also increased, and has to be evaluated.

We have run the protocols with different key sizes of512, 1024 and 2048 bits, respectively. The results are stud-ied in Sections 5.3 and 5.4 evaluating the costs in the userside and the server side, respectively. Regarding the lengthof the keysl, at the present time a size ofl = 1024 bits isconsidered computationally safe [31]. According to that, wehave tested our scheme with a smaller length (l = 512 bits)and a larger one (l = 2048 bits). In this way, we can examinehow the key length influences the system’s performance.

We have executed several test for every key length andprotocol, so that the times shown in the following sectionsare the average of these times.

5.3 Cost results in the user side

We have studied the global times of the protocol in 5.3.1as well as the partial times of each protocol (pseudonymrenewal, ticket purchase and ticket verification, see Sec-tions 5.3.2, 5.3.3 and 5.3.4 respectively), in order to iden-tify the most costly parts of each protocol in the client (user)side.

5.3.1 Global time cost results

Figure 7 shows the average time (in ms) required to com-plete each transaction (Pseudonym Renewal, Ticket Pur-chaseandTicket Verificationphases) taking into account theinteraction with the other entities. These results are givendepending on the used key lengthl (in bits) with its values512, 1024 and 2048, respectively. We focus specially ontheTicket Verificationphase, where the delay time has to be

†http://www.bouncycastle.org/

Table 2 Equipment specification details

Computer(server) CPU AMD Athlon 64 X2Dual 5000+ (2.59GHz)

RAM 2 GBOS Windows XPJava version Java 6NFC reader Arygon ADRA-USB

Mobile phone(client) Model Nokia 6212 NFC classicJava version J2ME (Series 40 SDK 1.0

with JSR 257 extension)


strongly reduced if we assume a mass-transit scenario. Thisdelay varies from 1.1 to 2.5 seconds depending on the keylengthl parameter, what makes the proposal definitely prac-tical. In general, all the transactions are considered practicalin 1024 bits (cost lower than 2s), and they become increasedin 2048 bits. We detail the times of each phase by con-sidering the costs of all their subphases in Sections 5.3.2,5.3.3 and 5.3.4 in order to show the most costly operationsin terms of delay times.

1000

10000

Pseudonym renewal

Ticket purchase

Ticket verification

Tim

e in

ms

Protocols: time vs key length (client side)

512 bits1024 bits2048 bits

1356

10581158

1408 1395 1396

8127

3145

2486

Fig. 7 Computational cost of every protocol using several key lengths inthe client side

5.3.2 Detailed time cost of the pseudonym renewal

Figure 8 shows the partial time intervals of thePseudonymRenewalphase. As expected, the decryption of the signedpseudonym (t3) is the most costly operation in this phase,and increases obviously depending on the key lengthl pa-rameter. This operation is performed by the user in the mo-bile phone. There are not great remarks in the other opera-tions, as precomputation of the non-interactive values helpsto reduce the global transaction times.

0.1

1

10

100

1000

10000

t1 t2 t3 t4

Tim

e in

ms

Partial times

Pseudonym renewal (client side)


323

1

927

103

348

1

955

106

690

1

7052

382

Fig. 8 Partial times of the pseudonym renewal (see Table 3 forti details)

5.3.3 Detailed time cost of the ticket purchase

Figure 9 shows the partial time intervals of theTicket Pur-chasephase. The main costs remain on the computation andtransmission of the Schnorr’s ZKP (t3 andt4), as well as thecommunication cost of the first commitment (t1), speciallyall of them with 2048 bits. The verification of the ticket sig-nature (t7) varies from 100 to 400 ms. Once again, somevalues have been precomputed to reduce the protocol exe-cution.

0.1

1

10

100

1000

10000

t1 t2 t3 t4 t5 t6 t7

Tim

e in

ms

Partial times

Ticket purchase (client side)


302

1

106

500

7

28

110

468

1

162

617

7

29

112

691

1

551

1473

8

29

391

Fig. 9 Partial times of the ticket purchase (see Table 4 forti details)

5.3.4 Detailed time cost of the ticket verification

Figure 10 shows the partial time intervals of theTicket Ver-ification phase. The most remarkable costs remain on theconnection and sending of the ticket (t1), depending on theamount of data with its key length (parameters and signa-ture), followed by the signature verification of the response(t3), the sending of the symmetric encryption of the param-eter rU (t5), and finally the verification of the receipt (t7).

Table 3 Details of the pseudonym renewal partial times

Partial time Descriptiont1 Sending of the pseudonym requestt2 Reception of the pseudonym responset3 Decryption of the signed pseudonymt4 Pseudonym’s signature verification

Table 4 Details of the ticket purchase partial times

Partial time Descriptiont1 Sending of the commitmentt2 Reception of the challenget3 Computation of the Schnorr’s ZKP responset4 Sending of the Schnorr’s ZKP responset5 Computation of the shared symmetric keyt6 Reception of the tickett7 Verification of the ticket data


Other times such as the reception of the response (t2), thecomputation of the symmetric encryption ofrU (t4), the re-ception of the receipt (t6) and the computation of the sym-metric decryption ofrI (t8) have become not costly opera-tions.

0.1

1

10

100

1000

10000

t1 t2 t3 t4 t5 t6 t7 t8

Tim

e in

ms

Partial times

Ticket verification (client side)


618

1

102

5

249

66107

6

691

1

104

7

354

108 123

6

1109

1

378

15

404

179

390

8

Fig. 10 Partial times of the ticket verification (see Table 5 forti details)

Independently from the key lengthl parameter, thereis a variation in the communication times depending on thesteps of the protocol, as the server and the client have tosynchronize their protocol steps in order to exchange theirinformation.

5.4 Cost results in the server side

We have studied the global times of the protocol in 5.4.1as well as the partial times of each protocol (pseudonymrenewal, ticket purchase and ticket verification, see Sec-tions 5.4.2, 5.4.3 and 5.4.4 respectively), in order to identifythe most costly parts of each protocol in the server side.

5.4.1 Global time cost results

Figure 11 shows the average time (in ms) required to com-plete each transaction (Pseudonym Renewal, Ticket Pur-chaseand Ticket Verificationphases) taking into accountthe interaction with the user by each entity (Trusted ThirdParty, Issuer and Service Provider). These results are given

Table 5 Details of the ticket verification partial times

Partial time Descriptiont1 Sending of the tickett2 Reception of the responset3 Verification of the responset4 Computation of the symmetric encryption ofrUt5 Sending of the symmetric encryption ofrUt6 Reception of the receiptt7 Verification of the receipt datat8 Computation and verification of the symmetric

decryption ofrI

depending on the used key lengthl (in bits) with its values512, 1024 and 2048, respectively. We focus specially onthe Ticket Verificationphase, where the delay time has tobe strongly reduced if we assume a mass-transit scenario.This delay varies from 0.7 to 2 seconds depending on thekey lengthl parameter, what makes the proposal definitelypractical, specially until 1024 bits. We detail the times ofeach phase by considering the costs of all their subphasesin Sections 5.4.2, 5.4.3 and 5.4.4 in order to show the mostcostly operations in terms of delay times.

100

1000

10000

Pseudonym renewal

Ticket purchase

Ticket verification

Tim

e in

ms

Protocols: time vs key length (server side)


358

809721

390

1086856

719

2712

2052

Fig. 11 Computational cost of every protocol using several key lengthsin the server side

5.4.2 Detailed time cost of the pseudonym renewal

Figure 12 shows the partial time intervals of thePseudonymRenewalphase. In this part, the communication with theclient (reception of the request and sending of the signedpseudonym) is the major part of the protocol.

1

10

100

1000

t1 t2 t3 t4

Tim

e in

ms

Partial times

Pseudonym renewal (server side)


156

37

6

159172

40

16

162

313

7863

265

Fig. 12 Partial times of the pseudonym renewal (see Table 6 forti details)


5.4.3 Detailed time cost of the ticket purchase

Figure 13 shows the partial time intervals of theTicket Pur-chasephase. The main costs are, another time, for com-munication (and synchronization) with the client (t1, t4, t7),and only the verification of the Zero-Knowledge Proof is themost costly computation part (mainly for 2048 bits).

0.1

1

10

100

1000

t1 t2 t3 t4 t5 t6 t7

Tim

e in

ms

Partial times

Ticket purchase (server side)

512 bits 1024 bits 2048 bits

156

1

37

219

15 16

368249

6

53

306

53

19

406570

12

131

832

407

53

717

Fig. 13 Partial times of the ticket purchase (see Table 7 forti details)

5.4.4 Detailed time cost of the ticket verification

Figure 14 shows the partial time intervals of theTicket Veri-ficationphase. The main costs are related to communicationalso (t1 for sending of the ticket,t5 for sending the symmet-ric encryption ofrU), but there are also some computationcosts to be taken into account (t3 verification of the response,andt7 verification of the receipt data), specially at 2048 bits.

Table 6 Details of the pseudonym renewal partial times

Partial time Descriptiont1 Reception of the pseudonym requestt2 Pseudonym extarctiont3 Verification & signature of the pseudonymt4 Sending the signed pseudonym

Table 7 Details of the ticket purchase partial times

Partial time Descriptiont1 Reception of the commitmentt2 Signature verificationt3 Computation & sending of the challenget4 Reception of the ZKP responset5 Verification of the ZKP responset6 Generation of the tickett7 Sending of the ticket

1

10

100

1000

t1 t2 t3 t4 t5

Tim

e in

ms

Partial times

Ticket verification (server side)


315

178134

3

87

362

203156

15

131

795

467 492

59

237

Fig. 14 Partial times of the ticket verification (see Table 8 forti details)

5.5 Database size and other system requirements

We show in Table 9 the size of every register in the database.This size depends on the key length parameterl: 512, 1024or 2048 bits. In the table we detail also which are the at-tributes which are stored into the database, and also whichare their partial sizes.

We analyse the capacity requirements of this protocolfor a real mass-transport system. The Tokyo Subway is themetro system which has most annual passenger rides, wherein 2009 registered 3160 M rides, what makes an average of8.7M daily rides†. If we take our 1024-bit results (1533 Bper register), it would require a new daily capacity of 12.43GiB. According to what we suggested for the maintenanceof the database, the tickets have a validity time, and after thatperiod they could be removed. If we set, for example, a 60-day validity period, it would require a capacity of 750 GiB,

†http://geography.about.com/od/urbaneconomicgeography/a/Busiest-Subways.htm

Table 8 Details of the ticket verification partial times

Partial time Descriptiont1 Reception of the tickett2 Generation of the responset3 Reception of the symmetric encryption ofrUt4 Generation of the receiptt5 Sending of the receipt

Table 9 Details of the database register sizes (in bytes) dependingon thekey length parameterl

Parameter Key size512 bits 1024 bits 2048 bits

T∗ 870 B 995 B 1765 BR∗ 218 B 281 B 538 BrI 64 B 128 B 256 B

rU or h(rU ,use) 64 B 128 B 256 Buse 1 B 1 B 1 B

TOTAL 1217 B 1533 B 2816 B


what could be usable in this kind of mass-transport system.

6. Conclusions

We have proposed an e-ticketing scheme with revocableanonymity and exculpability as security requirements, andalso reusability, in order to allow multi-verifiable tickets.Moreover, we have used personal mobile devices in thesystem, lightening then the computational requirements onthe users’ side. We assume, for simplicity, that only oneprovider is able to give a certain service; then, the ticket ver-ification phase is totally offline from the ticket issuer.

An analysis of the security and privacy of the proposalhas been also performed, breaking down all the security re-quirements and evaluating the achievements.

The proposed system has been implemented and wegive the details and the experimental results in order to ver-ify that has a reasonable response time, i.e. it is usable inpractice. We have analyzed the global time results for allthe phases, and also the partial time results for each phaseof the protocol. The results obtained, specifically the verifi-cation time (1.4 seconds using a 1024-bit key length in theuser side, less than 1 second in the server side), allow to usethe system in practice for mass-transit systems.

Finally, as a future work, we want to extend this e-ticketing NFC system (for one provider giving one deter-mined service) by analysing its performance in a scenariowith multiple service providers giving the same service,evaluating delay differences between a central server (cloud,remote desktop) and an online scenario connecting all thedatabases of the service providers. This last scenario woulduse Atomic Broadcast in order to make atomic operations tothe databases as in [27]. Moreover, our intention is to con-tinue improving the delay response times and also to includenew security requirements such as transferability.

Disclaimer and Acknowledgements

Partial support by the Spanish MICINN(projects TSI2007-65406-C03-01, ARES-CONSOLIDER INGENIO 2010CSD2007-00004, TSI2007-62986, “RIPUP” TIN2009-11689 and AUDIT TRANSPARENCY IPT-430000-2010-0031), the Spanish Ministry of Industry, Commerce andTourism (projects eVerification TSI-020100-2009-720 andSECloud TSI-020302-2010-153), and the Government ofCatalonia (grant 2009 SGR1135) is acknowledged. The au-thors are solely responsible for the views expressed in thispaper, which do not necessarily reflect the position of UN-ESCO nor commit that organization.

References

[1] Spanair, “Spanair y vodafone espana presentan la tarjeta de em-barque movil,” 2007. http://www.spanair.com/web/es-es/Sobre-Spanair/Noticias-y-eventos/Spanair-y-Vodafone-Espana-presentan-la-tarjeta-de-embarque-movil/.

[2] IATA, “Industry bids farewell to paper ticket,” 2008. http://www.iata.org/-pressroom/pr/2008-31-05-01.htm.

[3] AMSBUS, 2008. http://www.svt.cz/en/amsbus/.[4] LeedsUnited, “Official leeds sms,” 2007. http://www.leedsunited.com.[5] A. Vives-Guasch, M. Payeras-Capella, M. Mut-Puigserver, and

J. Castella-Roca, “E-ticketing scheme for mobile deviceswith ex-culpability,” Data Privacy Management (DPM), Fifth InternationalWorkshop, Lecture Notes in Computer Science, vol.6514, p.(to ap-pear), 2010. ISSN 0302-9743.

[6] W. Siu and Z. Guo, “Application of electronic ticket to online trad-ing with smart card technology,” Proceedings of the 6th INFORMSConference on Information Systems and Technology (CIST-2001),pp.222–239, 2001. Miami Beach, Florida (US).

[7] J.L. Ferrer-Gomilla, J.A. Onieva, M. Payeras, and J. Lopez, “Certi-fied electronic mail: Properties revisited,” Computers andSecurity,Elsevier, vol.29, no.2, pp.167–179, 2010. ISSN 0167-4048.

[8] J. Elliot, “The one-card trick multi-application smartcard e-commerce prototypes,” Computing & Control Engineering Journal,vol.10, no.3, pp.121–128, 1999. IET.

[9] D. Haneberg, “Electronic ticketing: risks in e-commerce applica-tions,” Digital excellence, pp.55–66, 2008. Springer-Verlag, ISBN3540726209.

[10] K. Kuramitsu, T. Murakami, H. Matsuda, and K. Sakamura,“Ttp:Secure acid transfer protocol for electronic ticket between personaltamper-proof devices,” 24th Annual International Computer Soft-ware and Applications Conference (COMPSAC2000), Taipei, Tai-wan, pp.87–92, Oct 2000. vol. 24.

[11] K. Kuramitsu and K. Sakamura, “Electronic tickets on contactlesssmartcard database,” Proceedings of the 13th International Confer-ence on Database and Expert Systems Applications, pp.392–402,2002. LNCS 2453.

[12] S. Matsuo and W. Ogata, “Electronic ticket scheme for its,” IEICETransactions on Fundamentals of Electronics Communications andComputer Sciences, vol.E86A, no.1, pp.142–150, 2003.

[13] I. Siu and Z. Guo, “The secure communication protocol for elec-tronic ticket management system,” 8th Asia-Pacific Software Engi-neering Conference (APSEC2001), University of Macau, 2001.

[14] G. Koning Gans, J.H. Hoepman, and F.D. Garcia, “A practical attackon the mifare classic,” CARDIS ’08: Proceedings of the 8th IFIPWG 8.8/11.2 international conference on Smart Card Research andAdvanced Applications, Berlin, Heidelberg, pp.267–282, Springer-Verlag, 2008.

[15] B. Patel and J. Crowcroft, “Ticket based service accessfor themobile user,” Proceedings of the 3rd Annual ACM/IEEE Interna-tional Conference on Mobile Computing and Networking (MOBI-COM’97), pp.223–233, 1997. Budapest, Hungary.

[16] K. Fujimura, H. Kuno, M. Terada, K. Matsuyama, Y. Mizuno, andJ. Sekine, “Digital-ticket-controlled digital ticket circulation,” 8thUSENIX Security Symposium, pp.229–240, 1999. USENIX.

[17] F. Bao, “A scheme of digital ticket for personal trusteddevice,”15th IEEE International Symposium on Personal, Indoor and MobileRadio Communications (PIMRC04), vol.4, pp.3065–3069, 2004.IEEE.

[18] D. Haneberg, K. Stenzel, and W. Reif, “Electronic-onboard-ticketing: Software challenges of an state-of-the-art m-commerceapplication,” Workshop Mobile Commerce, ed. K.Pousttchi andK.Turowski, Lecture Notes in Informatics (LNI), vol.42, pp.103–113, Gesellschaft fur Informatik (GI), 2004.

[19] D. Quercia and S. Hailes, “Motet: Mobile transactions using elec-tronic tickets,” 1st International Conference on Securityand Pri-vacy for Emerging Areas in Communications Networks, Proceed-ings, Athens, Greece, pp.374–383, Sep 2005. vol. 24.

[20] T.S. Heydt-Benjamin, H.J. Chae, B. Defend, and K. Fu, “Privacy forpublic transportation,” 6th Workshop on Privacy EnhancingTech-nologies (PET 2006), pp.1–19, 2006. LNCS 4258.

[21] Y.Y. Chen, C.L. Chen, and J.K. Jan, “A mobile ticket system basedon personal trusted device,” Wireless Personal Communications: AnInternational Journal, vol.40, no.4, pp.569–578, 2007.

[22] D. Chaum, “Blind signatures for untraceable payments,” Advances


in Cryptology - CRYPTO’82, pp.199–203, 1983.[23] K. Fujimura and Y. Nakajima, “General-purpose digitalticket

framework,” 3rd USENIX Workshop on Electronic Commerce,pp.177–186, 1998. USENIX.

[24] R. Dingledine, N. Mathewson, and P. Syverson, “Tor: Thesecond-generation onion router,” Proceedings of the 13th USENIX SecuritySymposium, 2004.

[25] C.P. Schnorr, “Efficient signature generation by smart cards,” J.Cryptology, vol.4, no.3, pp.161–174, 1991.

[26] S. Kremer, O. Markowitch, and J. Zhou, “An intensive survey offair non-repudiation protocols,” Computer Communications, vol.25,pp.1606–1621, 2002.

[27] F. Pedone, “A two-phase highly-available protocol foronline vali-dation of e-tickets,” Hewlett-Packard Labs Technical Reports, 2000.HPL-2000-116 20000929.

[28] S. Clark, “All new nokia smartphones to come with nfc from 2011.”Near Field Communications World, 2010.

[29] C. Catacchio, “Google’s schmidt: Android gingerbreadtohave near-field-communication support.” The Next Web, 2010.http://thenextweb.com/google/2010/11/15/googles-schmidt-android-gingerbread-to-have-near-field-communication-support/.

[30] J. Evans, “All new nokia smartphones to come with nfc from 2011.”Computer World, 2010. http://blogs.computerworld.com/16749/-new applehire showsiphoneiwallet future.

[31] N.I. of Standards and Technology, “Special publication 800-57 part1,” 2007. Recommendation for Key Management.

Arnau Vives Guasch (Valls, Catalonia,1983) is a PhD student at the CRISES ResearchGroup (UNESCO Chair in Data Privacy) of theUniversitat Rovira i Virgili. He achieved his titleof Engineer in Computer Science from Univer-sitat Rovira i Virgili in 2006, and his Master de-gree in Computer Engineering and Security in2008 from the same University. His researchmotivation focuses on the fields of applied cryp-tography, privacy, secure e-commerce protocolsand mobile applications. He has published and

participated in several international and national conferences, and he is au-thor of a patent.

Maria Magdalena Payeras-Capella wasborn in Mallorca in 1973. She got her title asTelecommunication Engineer (1998) from thePolytechnic University of Catalonia (UPC) andher Ph. D. in Computer Science (2005) fromthe University of the Balearic Islands (UIB).She has held several posts in the Universityof the Balearic Islands since 1998 in the de-partment of mathematics and computer science.Her research is focused primarily in the secu-rity in communications networks, protocols for

electronic commerce and technical-legal aspects of electronic commerce.Within these lines of research she has had an active pace of publications ininternational journals and in international and national conferences. Authorof several articles published in international journals included in JournalCitation Reports (JCR). She has been a member of the scientific and orga-nizing committee in several international congresses. Shehas participated

in European-funded and Spanish-funded research projects.She has par-ticipated in the creation of an awarded spin-off. The company KEYRONdedicated to telemedicine, was formed in 2006. She won the award to thebest doctoral thesis in 2005 from the COIT, Engineers Spanish Association.

Macia Mut Puigserver was born in Mal-lorca in 1966. He achieved his graduate in Com-puter Science in 1990 at the Autonomous Uni-versity of Barcelona. He received his Ph. D. in2006 at the University of Balearic Islands (UIB).In 1996 he joined to the Department of Mathe-matic and Computer Science at the UIB as As-sociate Professor. He began teaching as a Vo-cational Training Professor specialized in Com-puter Science in 1990. He combines his job atthe University with the job at the College where

he has been the Computer Science Department Head for 10 yearsand theMobility Coordinator of Erasmus Programme. His current research inter-ests are: design of secure protocols, secure e-commerce, mobile applica-tions and applied cryptography. He is author of articles on these topics ininternational journals and in international and national conferences. He hasbeen a member of the scientific and organizing committee in several inter-national congresses. He has also participated in several transfer projects.

Jordi Castella Roca (Menarguens,Catalunya, 1975) is tenured assistant professorat Rovira i Virgili University, he is currently amember of the UNESCO Chair in Data Privacy.He got his title of Engineer in Computer Sys-tems from University of Lleida in 1998, the titleof Engineer in Computer Science from Rovirai Virgili University in 2000 and Ph.D. in Com-puter Science from the Autonomous Universityof Barcelona in 2005. His research focuses onthe fields of cryptography (cryptographic proto-

cols) and privacy. He has published over 35 works in international journals,book chapters, international and national congresses. Nowhe is part ofthe advisory board of an international magazine, and he has been a mem-ber of the scientific and organizing committee in several international con-gresses. He has participated in 23 Spanish-funded and Catalan-funded re-search projects. He has been the main researcher in two research projectsfunded by Rovira i Virgili University, one funded by the Ministry of Sci-ence and innovation and two funded by the Ministry of Industry, Tourismand Trade. He has also participated in several transfer projects, and he isthe author of six patents, five of them international and in operation. He isa founding partner of three technology companies that have been awarded.

Josep-Lluıs Ferrer-Gomila was born inPalma (Spain) in 1967. He got his BSc degreeas Telecommunication Engineer (1991) from thePolytechnic University of Catalonia (UPC) andPhD degree in Computer Science (1998) fromthe University of the Balearic Islands (UIB). Heis associate professor in the University of theBalearic Islands since 1995 in the department ofmathematics and computer science. His maintopic of research is security in electronic com-merce. He is author of publications in interna-

tional journals and in international and national conferences, some of thempublished in international journals included in Journal Citation Reports(JCR). He has been a member of the scientific and organizing committee in


several international conferences. He has participated inEuropean-fundedand Spanish-funded research projects, main researcher in four. He has par-ticipated in the creation of an awarded spin-off. The company KEYRONdedicated to telemedicine, was formed in 2006.

Documents

A secure e-ticketing scheme for mobile devices with Near Field