TY - JOUR
AU - Huguet-Rotger,, Llorenç
AB - Abstract Touristic City Cards are managed by some city councils in order to make a step toward the SmartCity concept. Touristic City Cards enable the integration of different touristic services so as to facilitate the access to transport, cultural sites and touristic attractions to visitors. In this paper, we introduce a secure mobile system called mCityPASS that allows the smart management and secure access to this kind of service. We have implemented the system in a smartphone platform in such a way that the mobile device contains the purchased access element that holds a set of e-tickets that enables the visitors of a city to make use of the specified touristic services. The paper presents the details of the whole implementation of the system and an evaluation of the performance and the effectiveness of it. Also, an analysis of the privacy and the security properties of the presented scheme has been conducted. As a result, we can assure that the system preserves the privacy of the tourists and fulfills the more challenging security properties: fairness, non-overspending, exculpability, unsplittability and selective reusability. 1. Introduction Tourism is an important economic area in many destinations in the world and has been influenced and transformed by the use of communication technologies and e-commerce protocols. Information systems are incorporating an integrative technology both in tourism and in many other areas of daily life. As a consequence, it also affects urban transport and touristic attractions. Smart cities are trying to deliver new services to citizens and visitors. Clearly, smart tourism is an opportunity for such smart cities that have an important legacy or many tourist attractions. Tourism can be difficult to manage in touristic cities, especially in busy season when usually long queues are formed in order to visit buildings or attractions. The integration of mobile devices and secure communication protocols can help to manage tourism in an efficient way. For instance, nowadays, many touristic destinations and the majority of the main touristic cities have developed new systems using electronic tickets to substitute the old systems, that is, paper-based tickets to access touristic sites. Now the access of the tourists to touristic places, such as monuments, sights, exhibitions, attractions or museums, and public transport can be done using integrated services based on information technologies with the aim of promoting the digital access. Smart touristic services connected to any device can exchange information with many other smart devices through a network connection in order to offer smart touristic services. Touristic City Cards allow the integration of different touristic services offered in a city or touristic destination in a unique e-commerce platform, being the most usual services attractions and public transport system. The most significant advantages are the access to the main touristic attractions, priority access, discounts and offers, cards for different periods, guides, city or destination maps and access to public transport (with limitation or not). The integration of public transport services can help to convince users of the benefits of this kind of service. With the incorporation of entertainment and touristic attractions, the integrated platform allows visitors to have an easier and more convenient access to all the services. The main problem in the development of this kind of system is the agreement between all the involved parties: public transport operators, touristic attractions managers and other services administrators, such as museums directors. This agreement allows the required interoperability for the user to perceive a real benefit in the usage of the system. Usually these systems have been implemented using ad-hoc solutions. That is the case of the smart ticketing proposals [1–6]. However, a general-purpose smart ticketing protocol is not well suited for the specific requirements of a touristic city card system because it does not take into account the particularities of a touristic city card system. For example, general-purpose e-ticketing systems do not manage the lifetime of the ticket and usually the time management is reduced to the inclusion of an expiration date, and for this reason these systems do not offer activation protocols. Another reason is the lack of flexibility to accommodate reusable together with non-reusable services in the same touristic city card. Finally, the ideal features related to privacy and security of a general-purpose e-ticketing system are not well suited for a touristic city card system. For example, transferability can be considered an ideal feature in e-ticketing systems [5] but is not desired in touristic city card while unsplittability, exculpability and fairness are not common in e-ticketing systems and almost all the proposals fail to provide them. Related to its implementation, touristic city cards are usually put into practice using smart cards (these cards have to be activated as a first step before they are first used) or booklets with bar codes in paper support. We can find representative cases of cards in ‘We love city cards’ [7], leading to touristic city card schemes for 36 European cities and CityPASS [8] that includes 12 American cities. We present a system that puts together e-tickets from different services of a city inside a smartphone application that we have called mCityPASS (Mobile CityPASS). Thus, as a novelty, we have specified and made a new application for touristic city card specific for its use with smartphones or other portable devices. These devices are able to interconnect different services in order to create a new smart touristic service following the smart city paradigm. The presented system stores a booklet containing a set of electronic tickets on the portable devices. The main advantage of the method in front of the systems using smart cards is that the user can buy online, using the systems, a set of e-tickets, called PASS, beforehand, and store the electronic tickets on the device (avoiding queues at the point of sale). No extra appliances are required (users are expected to have portable devices such as smartphones). In addition to that, the mobile device approach avoids the need of a reader–recorder for smart cards and reduces the cost of management of expenditures on online counters. The emerging technologies used in our protocol provide security features to the scheme, incorporate an electronic payment system and help users (i.e. visitors) to make use of city services and visit the main attractions. In [9], we first introduced a basic algorithm for touristic e-tickets called mCityPASS allowing the acquisition and validation of a set of tickets for multiple access to any kind of attractions, public transport and touristic sites. The incorporation of e-tickets booklet in one application enables an efficient, cost-effective and secure access to the resources of any smart city. The mCityPASS protocol has been configured for portable devices (tablets, smartphones, etc.), lowering the requirements on the client’s side, especially computation and, at the same time, fulfilling the essential security properties (integrity, authenticity and non-repudiation). Moreover, some more specific security requirements are also achieved, such as reusability, unsplittability, expiration and activation date, anonymity and exculpability (see Section 8). Each service offered in the booklet can be included using non-reusable e-tickets, |$m$|-times reusable tickets or infinitely reusable tickets. The first ones (i.e. non-reusable) are normally associated with attractions, sights and museums, while the reusable tickets are more commonly connected to transport; however, its specific application can be decided at the destination. For instance, the CityPass of Granada (lovegranada.com) proposes a 3-day pass including entrances to The Alhambra and the Generalife together with five journeys of urban buses and another authorization for 5 days that includes the entrances to the Generalife and The Alhambra, together with one train journey and nine bus journeys. Our mCityPASS protocol [9] was the first protocol designed specifically for touristic city cards fulfilling the previously mentioned privacy and security properties. However, the proposed protocol was far away from being a complete system. The paper lacked a discussion about of the privacy and security of the system, and some statements related with the fulfillment of desired properties were not proved. Furthermore, [9] it was a theoretical proposal and it was not clear how the system should be implemented and whether its implementation would be good enough to allow the viability of the scheme. Now, after the implementation of the system, we present a complete solution, and the paper includes a detailed security and privacy analysis, a description of its implementation and a performance analysis. Security is one of the challenges of electronic commerce; thus, the protocol presented in this paper pays special attention to the security properties that an e-ticketing application should have. The implementation and analysis of the system has provided enough information to prove that mCityPASS is a secure, robust and powerful tool. In addition to that, to complete our scheme, we have also attached to the protocol an electronic payment system to buy the e-tickets. 1.1. Paper structure The manuscript has been structured as follows. After an introduction to touristic city card in Section 1, the state of the art of the subject is exposed in Section 2. Then the proposal, based on the initial design presented in [9], has been improved, implemented and evaluated. A summary of the proposed protocol is included in Section 4 (the full description of the protocol is included in Appendix A). The integration of the payment phase is included in Section 5 while the adaptations performed to face the implementation are described in Section 6. Section 7 describes the process of implementation, including the server development, the Mobile client development and a description of the app. In order to evaluate the system, two analysis are performed. First, the analysis of the privacy and security properties of the system is included in Section 8, and then the analysis of the viability and performance analysis is disclosed in Section 9. Finally, some conclusions are described in Section 10. 2. Related Proposals There are some current real scenarios using smart cards as touristic city cards. They will be described in this section together with a state of the art of the most significant theoretical proposals related to touristic city cards. 2.1. Real scenarios In this section some real cases of smart card-based Tourist City Cards are described and discussed. 2.1.1. Oyster Card and London Pass, London London is one of the largest European cities and one of the main economical places in the world. It is one of the touristic destinations that receives more tourists, over 65 million people per year [10]. In order to be able to manage such great demand, some attempts have been done to develop smart card systems since the Nineties. Although these systems did not succeed, they were useful as they provided valuable information over the features that a system would present to be viable. From this experience it was derived that all the stakeholders must cooperate and that the specifications have to be well defined [6]. With these objectives, in 2003 Oyster Card was introduced with great success. This card can be used in the bus and metro systems, together with some boats and trains. The system offers different kinds of billing depending on the user’s needs, as single tickets or temporal passes. London also offers a specific scheme for the touristic service, which is called London Pass, and allows access to more than 50 attractions and in some cases allows the user to skip the queue. The card also offers discounts to many restaurants and other entertainment options. However, this card does not include transport tickets. For this reason, the tourists have to choose between the purchase of a paper ticket valid for 24 hours or 7 days or achieve a Visitor Oyster Card. This card offers a pay-as-you-go service but with lower rates. 2.1.2. Octopus Card, Hong Kong One of the cities of the world with more dense population requires an efficient public transport system. The five companies that manage the public transport in Hong Kong have offered the Octopus Card since 1994 [6]. It was well accepted by the citizens and soon other services, such as payments in shops or parking meters, were added to the system. These additional services mean the greatest part of the transactions using the Octopus Card. The city offers a special card for tourists (Sold Tourist Octopus Card). This card can be used to access almost all Hong Kong attractions and public transport. 2.1.3. Saint Petersburg City Card, Saint Petersburg Saint Petersburg is an emblematic European city and its historic center is a World Heritage Site of UNESCO (United Nations Educational, Scientific and Cultural Organization). The number of visitors of the city has raised during the past years but it presents two drawbacks: the bad quality of the public transport and it’s high prices [6]. To face these problems, the city has offered, from 2013, a visitor’s card that includes free access to almost all the museums and attractions of the city, free tours, discounts in shops, restaurants and hotels and access to public transport. Although it includes a lot of services, there are two elements that are not integrated in the implementation of this card. The entrance to the museums is managed with a booklet that is stamped when the tourist reaches the service and when she accesses the public transport she is required to have an additional electronic card. 2.1.4. EZ-Link, Singapore The EZ-link system was introduced in 2002 to facilitate the access to public transport and to obtain real-time information about travel profiles. In 2009, the system was upgraded to the protocol CEPAS (Contactless ePurse application standard). This protocol aims to use a single transport card with the possibility of including third party applications. Moreover, the system has been improved and now it is possible to use mobile devices with Near Field Communication (NFC) [6]. 2.2. Theoretical proposals related with Touristic City Cards In the literature, we can find several works that investigate the design and implementation of electronic ticketing systems both for touristic sites and cities. They combine different touristic tickets (as attractions vouchers, transport tickets, leisure activities passes and so on) in the same element. The resulting approaches are integrated ticket systems that have the benefit of having a lower fare than the price of buying separately the tickets of the different services. These schemes are an objective of the European Union in relation with the cities’ transports systems [11]. For this reason, e-ticketing protocols have to assure security by introducing elements to avoid illegal copies and, at the same time, maintain the privacy of the user. The authors of [12] expose the advantages of operating with portable devices, reducing the cost of the infrastructure of the whole system. Several big cities use multimodal electronic ticketing schemes in transport [7, 8]. Each city uses its own chosen technology (e.g. contactless cards or smartcards). Nowadays, portable devices, such as smartphones, are not used in the majority of the proposals. In Finland, the public transport users dispose of a system to pay for the tickets with their smartphones as from the year 2001 [13], for example. In other cities, such as in New York, CityPASS, the pass has to be set in print and then swapped for the user’s CityPASS when they visit the point of interest or attraction. Other papers, such as [1, 3, 14, 15], describe the advantages of the use of electronic ticketing systems in touristic sites and public transport networks. However, almost none of them present the specifications or instructions about how to implement the schemes. In another paper, Basili et al. [2] describe an Android app for portable devices that offers, among other things, ticketing services. Nevertheless, these authors describe just a generic framework and do not include any electronic ticketing implementation. Only one of them, [5], presents a protocol that also provides the property of transferability. In other works, portable devices contain electronic tickets for public transport, virtual vouchers or loyalty cards, as [16, 17]. The authors of [16] present a system based on NFC for small providers useful for touristic apps. Nevertheless, this system cannot use the mobile device to contain the ticket; they use the smartphone just to identify the person, and for this reason it can be said that the anonymity of the user is not achieved. The author of [17] proposes a system called |$mCoupons$| where the elements are stored in the smartphone. The system described by this author is applied uniquely to single tickets and the system manages the double-spending problem, the manipulation and generation of unauthorized elements and the copy of tickets. The author of [18] proposes another scheme with the same properties than [17] but with a more efficient implementation. Another approach, including multiple tickets, was presented to improve the efficiency of a set of separated tickets [19]. The authors of [20] presented a system for multi-ticketing, providing protection of the privacy of the users and also unsplittability. Nevertheless, each ticket-forming part of the same multi-ticket could be redeemed only in the same fixed order when the ticket was issued. Liu and Xu [19] resolve the inefficiency of the former protocol. But, even in this case, the system considers only a single merchant. Finally, when a set of providers is federated, a multi-ticketing system can be designed, as it is the case of [21] that allows one to store in the smartphone a multi-ticket element that includes single tickets from the vendors of the federation (the federated providers can be a corporation of providers of the same city that manages different touristic attractions). This paper achieves the property of unsplittability, but on the other hand, properties such as exculpability, activation, reusability and fairness are not considered. 3. Contributions This work presents a new secure and complete solution for the access to touristic city cards using mobile devices. The proposal integrates all kind of e-tickets for tourists in a single e-booklet that we have called PASS. Our solution allows the users have a secure and privacy-preserving access to the transportation systems and, at the same time, it integrates other touristic services as sights, attractions or museums. Also, the PASS includes several kinds of electronic tickets. Some of them can be defined as reusable and they can be accessed multiple times or even infinitely while others, called non-reusable, can be used only once. The resulting PASS can be designed for different lifetimes and user categories, with different prices. The basic protocol was presented in [9]. Now the generic description of the protocol has been improved due to the requirements of the implementation process, resulting in several small changes and new specifications in the protocol. Moreover, a new phase, the payment phase, has been integrated in the system. We include a summary of the main operations of the protocol incorporating these changes (see Section 6). Additionally, the proposed solution is secure enough to avoid the typical fraud cases and fulfills the ideal features of an e-ticketing system listed in the survey [4]. In this paper, we also introduce a security analysis to show how the protocol provides authenticity, integrity, non-repudiation, unforgeability, non-overspending, expiration date and lifetime and the more challenging ones, fairness, exculpability, unsplittability and selective reusability. As it is analyzed in Section 8, it also provides privacy to the user who can use the designed system anonymously and her identity is not revealed in any step of the protocol avoiding the generation of identified user profiles. Trust, fairness and exculpability are important features. Taking this into account, the application has been designed as a fair scenario for all the actors involved in the system. Thus, they are protected against attacks coming from other actors. As we have already said, the paper includes a detailed security discussion proving the achievement of all of these properties. The security and privacy analysis is organized in 6 propositions and 19 claims in order to support each premise described in the proposition. Solutions as the current ones, based on physical tokens as smart cards, rely on physical security aspects and besides they need a framework for the management of the physical tokens. As it is shown in this paper, an implementation on smartphones would make the system more flexible and with an easier access for users. The mCityPASS system has been implemented using smartphones as an application of mobile commerce that enables the electronic payment of the e-tickets. The details of this implementation are included in the paper together with a performance analysis to prove that the system is viable and efficient. 4. mCityPASS scheme As it has been said before, some basic aspects of the application that we present in this paper were mentioned in a protocol initially published in [9]. In this section we include a summary of it, but we address to the Appendix A for a complementary explanation. The summary describes the protocol in a way that is enough to understand the implementation of the application, the security and privacy analysis and the performance analysis that are presented in this paper. A dispute resolution protocol suitable for the protocol can be found in [9]. Figures 1 and 2 include the notation that will be used in the descriptions included in this section. FIGURE 1. Open in new tabDownload slide Cryptography: notation and description. FIGURE 1. Open in new tabDownload slide Cryptography: notation and description. FIGURE 2. Open in new tabDownload slide Information items: notation and description. FIGURE 2. Open in new tabDownload slide Information items: notation and description. 4.1. Actors The protocol involves four actors. The user |$\mathcal{U}$| is the tourist who wants to access the services; the ticket issuer |$\mathcal{I}$| is the actor who delivers a valid ticket to |$\mathcal{U}$|⁠; then there are several providers |$P_{i}$| that offer access to a service and are in charge of verifying the electronic tickets included in the PASS and provide access to the corresponding service; and, as a last actor, the system also has a trusted third party (TTP) |$\mathcal{T}$|⁠. The main purpose of this TTP is the preservation of |$\mathcal{U}$|’s privacy. To do it, the TTP generates a valid pseudonym, not based on the identity, to |$\mathcal{U}$|⁠. 4.2. Phases The system is formed by five phases. Figure 3 shows the phases flow. The first phase is the Provider’s Affiliation, used to enroll the Providers and a function that generates the parameters of the system. The second phase is called Pseudonym, and it allows |$\mathcal{U}$| to obtain a new pseudonym not linked to its identity. This pseudonym allows |$\mathcal{U}$| to access the application in an anonymous way (if |$\mathcal{U}$| behaves correctly). As a third step, we find the PASS Purchase, containing the purchase and delivery of the PASS. Before using the PASS, the user has to execute the PASS Activation phase. Then |$\mathcal{U}$| presents a ticket from the PASS to a provider to access the service. The ticket will be checked and validated in PASS Verification. FIGURE 3. Open in new tabDownload slide Phases flow. FIGURE 3. Open in new tabDownload slide Phases flow. 4.2.1. PHASE 1: Provider’s affiliation In the Provider’s affiliation phase, the users contact |$\mathcal{I}$| to be included as providers of a specific service of the ecosystem of the mCityPASS. A PASS can include an arbitrary number of services, |$J$|⁠, so |$J$| providers will be enrolled. Then |$\mathcal{I}$| will arrange an array of public key certificates of the providers. Each |$P_{i}$| offers a specific service, which can be either a non-reusable service (⁠|$\gamma _i$|⁠), or an |$m$|-times reusable service (⁠|$\lambda _i$|⁠) (each reusable service |$\lambda _i$| can be used |$m$| times) or an infinitely reusable service (⁠|$\xi _i$|⁠). When this phase finishes, the issuer can create the structure of the |$\mathsf{PASS}$|⁠. 4.2.2. PHASE 2: Pseudonym |$\mathcal{U}$| executes this phase contacting the pseudonym manager |$\mathcal{T}$| to request and obtain a pseudonym. |$\mathsf{Cert_{\mathcal{U}}}$| is a certificate that identifies |$\mathcal{U}$|⁠. The cryptographic public parameters [22] of the system have been published. They are |$(\alpha ,p,q)$|⁠, being |$\alpha $| the generator of a group |$G$| with order |$p$|⁠, |$p$| and |$q$| large primes with |$p = 2q + 1$|⁠. This phase has three operations called authenticateuser, generatepseudonym and verufy pseudonym. At the end of the phase, the user achieves a pseudonym |$\mathsf{Pseu_{\mathcal{U}}} = (\mathsf{y}_{\mathcal{U}},\mathsf{sk_{\mathcal{T}}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}}))$|⁠, where |$\mathsf{y}_{\mathcal{U}} = {\alpha }^{\mathsf{x}_{\mathcal{U}}} \pmod p$|⁠, |$\mathsf{x}_{\mathcal{U}}$| is randomly generated and |$\mathsf{h}_{\mathsf{y}_{\mathcal{U}}} = hash(\mathsf{y}_{\mathcal{U}})$|⁠. 4.2.3. PHASE 3: PASS Purchase |$\mathcal{U}$| creates a connection with the issuer |$\mathcal{I}$| to purchase the PASS. It can be an anonymous channel like TOR [23], which preserves the user’s privacy. Figures in Appendix A show an itemized description of the protocol phases. The first operation of the purchase of a ticket is the getService where |$\mathcal{U}$| chooses the Type of the PASS, corresponding to the variable |$\mathsf{Type}$|(⁠|$\mathsf{Lifetime}$|⁠, |$\mathsf{Category}$|⁠), then generates a of random number |$\mathsf{RU} \stackrel{R}{\leftarrow } \mathsf{Z}_q$|⁠, calculates |$\mathsf{H}_{\mathcal{U}} = {\alpha }^{\mathsf{RU}} \pmod p$|⁠, generates two additional random numbers |$a_{1},a_{2} \stackrel{R}{\leftarrow } \mathsf{Z}_q$| that will be used for the Schnorr proof, calculates |$A_{1} = {\alpha }^{a_{1}}\pmod p$| and |$A_{2} = {\alpha }^{a_{2}}\pmod p$| and, finally, sends the elements |$(\mathsf{Pseu_{\mathcal{U}}}, \mathsf{H}_{\mathcal{U}}, A_{1}, A_{2}, \mathsf{Type})$| to |$\mathcal{I}$|⁠. In the second operation, the so-called getChallenge operation, |$\mathcal{I}$| generates a challenge |$\mathsf{c} \stackrel{R}{\leftarrow } \mathsf{Z}_q$| and sends it to |$\mathcal{U}$| while asynchronously, for optimization, pre-computes |${\mathsf{y}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$| and |${\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠. To respond this challenge, |$\mathcal{U}$| calculates the elements |$\mathsf{w}_{1} = a_{1} + \mathsf{c} \cdot \mathsf{x}_{\mathcal{U}} \pmod q$| and |$\mathsf{w}_{2} = a_{2} + \mathsf{c} \cdot \mathsf{RU} \pmod q$|⁠, a session key: |$\mathsf{K} = hash(\mathsf{w}_{2})$|⁠, a set of |$J$| randoms, |$\psi _{1,0},...,\psi _{J,0} \stackrel{R}{\leftarrow } \mathsf{Z}_q$|⁠. For the services that can be used only once |$\gamma _i$|⁠, she computes |$\psi _{\gamma _{i},1} =hash(\psi _{\gamma _{i},0})$|⁠, and for each m-reusable service |$\lambda _i$|⁠, computes |$\psi _{\lambda _i,m} =hash^m(\psi _{\lambda _i,0})$|⁠. Finally, she stores |$\psi _{1,0},...,\psi _{J,0}$| in the database TicketsPASS. The information is encrypted and sent to |$\mathcal{I}$|⁠: |$\mathsf{pk_{\mathcal{I}}}((\mathsf{w}_{1},\mathsf{w}_{2}),(\{\psi _{\gamma _{i},1},\psi _{\lambda _i,m}\} \forall \gamma _i,\lambda _i))$| and |$\mathcal{U}$| pays for the |$\mathsf{PASS}$|⁠. To get the PASS, |$\mathcal{I}$| decrypts |$\mathsf{sk_{\mathcal{I}}}(\mathsf{pk_{\mathcal{I}}}(\mathsf{w}_{1},\mathsf{w}_{2}))\leftarrow (\mathsf{w}_{1},\mathsf{w}_{2})$|⁠, calculates |${\alpha }^{\mathsf{w}_{1}} \pmod p$| and |${\alpha }^{\mathsf{w}_{2}} \pmod p$|⁠. Then |$\mathcal{I}$| verifies |${\alpha }^{\mathsf{w}_{1}} \stackrel{?}{=} A_{1} \cdot{\mathsf{y}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$| and |${\alpha }^{\mathsf{w}_{2}} \stackrel{?}{=} A_{2} \cdot{\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠. If both verifications hold, |$\mathcal{U}$| is authorized. Then |$\mathcal{I}$| uses the session key: |$\mathsf{K} = hash(\mathsf{w}_{2})$|⁠, generates a unique serial number |$\mathsf{Sn}$|⁠, and a set of random numbers |$\mathsf{RI_{i}} \stackrel{R}{\leftarrow } \mathsf{Z}_p$|⁠, for |$i= 0,,J$|⁠, computes the set |$\mathsf{h}_{\mathsf{RI}_{i}}=hash(\mathsf{RI_{i}})$| for |$i= 1,,J$|⁠, composes the set |$\kappa _{i} = (\mathsf{K},\mathsf{RI_{i}})$| and signs it |$\kappa _{i}^{*} = (\kappa _{i}, \mathsf{Sign_{\mathcal{I}}}(\kappa _{i})) \forall i=1,...,J$|⁠. Then |$\mathcal{I}$| encrypts each |$\kappa _{i}^{*}$| with a digital envelope that can be decrypted by |$\mathcal{T}$| and |$\mathcal{P}$|⁠: |$\delta _{\mathcal{T},\mathcal{P}}=\mathsf{pk_{\mathcal{T},\mathcal{P}}}_i(\kappa _{i}^{*})$|⁠. After that, |$\mathcal{I}$| fills out the information of the |$\mathsf{PASS}$| = (⁠|$\mathsf{Sn}$|⁠, |$\mathsf{Type}$|⁠, |$\mathsf{Pseu_{\mathcal{U}}}$|⁠, |$\mathsf{Lifetime}$|⁠, |$\mathsf{PURdate}$|⁠, |$\mathsf{EXPdate}$|⁠, |$\mathsf{h}_{\mathsf{RI}}$|[ ],|$H_{\mathcal{U}}$||$\delta _{\mathcal{T},\mathcal{P}}$|[ ], |$\psi _{\lambda , m}$|[ ], |$\psi _{\gamma , 1}$|[ ], Terms and Conditions) and digitally signs the |$\mathsf{PASS}$|⁠, |$\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})} = \mathsf{sk_{\mathcal{I}}}(hash(\mathsf{PASS}))$|⁠, generates |$\mathsf{PASS^*} = (\mathsf{PASS},\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})})$| and stores in the database CityPASS the following information: |$(\mathsf{PASS^*}, \kappa _{i} \quad \forall i=1,...,J)$|⁠. Finally, |$\mathcal{I}$| sends |$\mathsf{PASS^*}$| to |$\mathcal{U}$|⁠. The last step of this phase is receivePASS where |$\mathcal{U}$| verifies the digital signature |$\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})}$| of the |$\mathsf{PASS}$| with the certificate of |$\mathcal{I}$|⁠, verifies the data included in |$\mathsf{PASS}$| and its validity |$(\mathsf{PASS}.\mathsf{PURdate},\mathsf{PASS}.\mathsf{EXPdate})$| and the |$\mathsf{PASS}.\mathsf{Pseu_{\mathcal{U}}}$| and finally stores TicketsPASS|$(\mathsf{PASS^*},\mathsf{RU})$| in the database with the information generated during the challenge response. The issuer |$\mathcal{I}$| has a public key certificate and its corresponding key pair (⁠|$\mathsf{Cert_{\mathcal{I}}}$|⁠). For privacy reasons, the users will not use their personal keys. Instead, they will use a temporal pseudonym and will use the Schnorr’s Zero-Knowledge Proof (ZKP) [24] in order to authenticate themselves. |$\mathcal{U}$| selects a |$\mathsf{Type}$| of PASS that specifies the timelife of the |$\mathsf{PASS}$|⁠, |$\mathsf{Lifetime}$|⁠, and also the |$\mathsf{Category}$| of |$\mathcal{U}$| (child, young, adult,..): |$\mathsf{Type}(\mathsf{Lifetime}, \mathsf{Category})$|⁠. The issuer generates the |$\mathsf{PASS}$| containing all its elements and its digital signature and including the array of |$J$| secret values |$\mathsf{RI}_{i}$| and the set of secret shared keys (that can be deciphered only by the corresponding provider |$P_{i}$| and |$\mathcal{T}$|⁠) to let each provider show the secret value |$\mathsf{RI}_{i}$|⁠. 4.2.4. PHASE 4: PASS Activation While a standard ticket includes an expiration date and can be used anytime before this date, an mCityPASS has a more complex data management. A |$\mathsf{PASS}$| has a |$\mathsf{Lifetime}$| and an expiration date, |$\mathsf{EXPdate}$| (see Fig. 4). For this reason the |$\mathsf{PASS}$| has to be used before this expiration date but will only be valid during a specific |$\mathsf{Lifetime}$| period. The |$\mathsf{Lifetime}$| period is specified during Phase 2 and starts when |$\mathcal{U}$| activates the |$\mathsf{PASS}$|⁠. FIGURE 4. Open in new tabDownload slide PASS’ Life Cycle. FIGURE 4. Open in new tabDownload slide PASS’ Life Cycle. The activation phase sets |$\mathsf{ACTdate}$|⁠. Then |$\mathsf{LIMdate}$| can be computed adding the |$\mathsf{Lifetime}$| to |$\mathsf{ACTdate}$|⁠. To verify the PASS |$\mathcal{I}$| sends |$\mathsf{\mathsf{ACT}^*}$| to the user |$\mathcal{U}$|⁠, where |$\mathsf{ACT}= (\mathsf{PASS}.\mathsf{Sn}, \mathsf{ACTdate},$| “Activated”) and |$\mathsf{\mathsf{ACT}^*} =(\mathsf{ACT}, \mathsf{Sign_{\mathcal{I}}(\mathsf{ACT})})$|⁠; 4.2.5. PHASE 5: PASS Verification The protocol presents three algorithms for the verification of tickets: one for non-reusable services, one for m-times reusable services and one for infinitely reusable services (figures in Appendix A describe in detail these protocols). In this section only the most complex algorithm (m-times reusable service) is described. The other algorithms can be interpreted as a simplification of this one. For the verification of an |$m$|-times reusable service, |$\mathcal{U}$| sends the |$\mathsf{PASS^*}$| to |$\mathcal{P}$|⁠, who checks it. If it is valid, the provider |$\mathcal{P}$| will send the commitment so that the corresponding |$\mathsf{RI}$| will be disclosed if |$\mathcal{U}$| behaves correctly. Once |$\mathcal{U}$| proves the knowledge of the value |$\mathsf{RU}$| of that PASS using a ZKP and reveals the secret value for that specific service, then she receives the secret element |$\mathsf{RI}$| together with the receipt |$\mathsf{R^*}$| from |$\mathcal{P}$|⁠. For the verification of an |$m$|-times reusable service, |$\mathcal{P}$| and |$\mathcal{U}$| began the phase executing the showPASS operation. |$\mathcal{U}$| generates a random value |$a_{3}, \stackrel{R}{\leftarrow } \mathsf{Z}_q$| to be used in a Schnorr proof and computes |$A_{3} = {\alpha }^{a_{3}}\pmod p$|⁠. If it is the first-time use of an |$m$|-times reusable service |$\mathcal{U}$| computes |$\psi _{\lambda _i,m-1} =hash^{m-1}(\psi _{\lambda _i,0})$|⁠. Then |$\mathcal{U}$| creates a counter |$k_{\lambda _i}=m-1$| to keep track of the number of times that the ticket can be used. The counter is stored in her CityPASS database. If it is a subsequent use of an |$m$|-times reusable service |$\mathcal{U}$| retrieves |$k_{\lambda _i}$| from her TicketsPASS database and calculates |$\psi _{\lambda _i,(k_{\lambda _i}-1)} =hash^{(k_{\lambda _i}-1)}(\psi _{\lambda _i,0})$|⁠. Then |$\mathcal{U}$| composes the information ticket message |$\mathsf{m}_{1}=(\mathsf{PASS^*}$|⁠, |$\mathsf{\mathsf{ACT}^*}$|⁠, |$A_{3}$|⁠, |$(k_{\lambda _i})$|⁠), signs and sends it to |$\mathcal{P}$|⁠: |${\mathsf{m}_{1}}^{*} = (\mathsf{m}_{1},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{m}_{1})))$|⁠. The second operation is verifyPASS where |$\mathcal{P}$| verifies the PASS signature, |$\mathsf{PASS}.\mathsf{PURdate}$|⁠, |$\mathsf{PASS}.\mathsf{EXPdate}$|⁠, |$\mathsf{\mathsf{ACT}^*}$|⁠, |$\mathsf{PASS}.\mathsf{ACTdate}$|⁠. If the verifications stand, |$\mathcal{P}$| looks for the |$\mathsf{PASS^*}$| in its SpentCityPASSES database using |$\mathsf{PASS}.\mathsf{Sn}$|⁠. If (⁠|$\not \exists \psi _{\lambda , k_{\lambda _i}}$| linked to |$\mathsf{PASS^*}$|⁠) or [(⁠|$\exists \psi _{\lambda , k_{\lambda _i}}$|⁠) and (⁠|$k_{\lambda _i} \geq 1 $|⁠) and (⁠|$k_{\lambda _i}$| stored in the |$\mathcal{P}$|’s database has the same value than the one sent by |$\mathcal{U}$|⁠)] then |$\mathcal{P}$| generates a challenge |$\mathsf{c} \stackrel{R}{\leftarrow } \mathsf{Z}_q$|⁠, assigns |$Challenge = (\mathsf{PASS}.\mathsf{Sn},\mathsf{c},\tau _1)$|⁠, |${Challenge}^{*} = (Challenge,\mathsf{sk_{\mathcal{P}}}_i(hash(Challenge)))$| and sends this signature to |$\mathcal{U}$|⁠. Asynchronously he pre-computes |${\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠. |$\mathcal{U}$| computes |$\mathsf{w}_{3} = a_{3} + \mathsf{c} \cdot \mathsf{RU} \pmod q$|⁠, encrypts and signs |$\mathsf{w}_{3}$|⁠, sends it to |$\mathcal{P}$|⁠: |$\mathsf{sk}_{\mathcal{U}}(\mathsf{pk_{\mathcal{P}}}_{i}(\mathsf{PASS}.\mathsf{Sn}, \mathsf{w}_{3}, \tau _1))$|⁠. |$\mathcal{P}$| computes |${\alpha }^{\mathsf{w}_{3}} \pmod p$|⁠, verifies |${\alpha }^{\mathsf{w}_{3}} \stackrel{?}{=} A_{3} \cdot{\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠. Then he computes |$\mathsf{A}_{\mathcal{P}} = PRNG(\mathsf{h}_{\mathsf{K}}) \oplus \mathsf{RI}_{\lambda _i}$|⁠, |$PRNG(\mathsf{h}_{\mathsf{K}})$| is a secure pseudorandom number generator and, |$\mathsf{h}_{\mathsf{K}} = hash(\mathsf{K})$| is the seed. |$\mathsf{K}$| and |$\mathsf{RI}_{\lambda _i}$| are obtained from |$\delta _{\mathcal{T},\mathcal{P}}$|⁠. He encrypts |$\mathsf{A}_{\mathcal{P}}$| with the public key of the TTP |$\mathcal{T}$|⁠: |$\mathsf{pk_{\mathcal{T}}}({\mathsf{A}_{\mathcal{P}}})$|⁠, assigns |$\mathsf{V_{succ}} = (\lambda _i,\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{10},\tau _1,\mathsf{pk_{\mathcal{T}}}(\mathsf{A}_{\mathcal{P}}), k_{\lambda _i}, \psi _{(\lambda , k_{\lambda _i})})$|⁠. The signature is noted: |${\mathsf{V_{succ}}}^{*} = (\mathsf{V_{succ}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{succ}})))$|⁠. Finally, he sends |$\mathsf{m}_{2}={\mathsf{V_{succ}}}^{*}$| to |$\mathcal{U}$|⁠; In showProof|$\mathcal{U}$| verifies |$\mathcal{P}$|’s signature and calculates |$\mathsf{A}_{\mathcal{U}} = PRNG(\mathsf{K}) \oplus \psi _{\lambda , (k_{\lambda _i}-1)}$|⁠, using the shared value |$\mathsf{K}$| as seed. He composes the message |$\mathsf{m}_{3}=(\mathsf{PASS}.\mathsf{Sn},\mathsf{A}_{\mathcal{U}})$|⁠, signs and sends it to |$P_{i}$|⁠: |${\mathsf{m}_{3}}^{*} = (\mathsf{m}_{3},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{m}_{3})))$|⁠. To verifyProof|$\mathcal{P}$| obtains |$\mathsf{PASS}.\mathsf{Sn}$| and computes |$\psi _{\lambda , (k_{\lambda _i}-1)} = \mathsf{A}_{\mathcal{U}} \oplus PRNG(\mathsf{K})$|⁠. He checks |$\psi _{\lambda , (k_{\lambda _i})} \stackrel{?}{=} hash(\psi _{\lambda , (k_{\lambda _i}-1)})$|⁠, generates |$\tau _2$|⁠, verifies it using PASS expiry date |$(\mathsf{PASS}.\mathsf{PURdate},$||$\mathsf{PASS}.\mathsf{EXPdate})$| and timestamp |$\tau _1$|⁠. He signs |$\mathsf{A}_{\mathcal{P}}$| approving the validation with timestamp |$\tau _2$|⁠: |$\mathsf{R}_{\lambda _i} = (\mathsf{A}_{\mathcal{P}},\mathsf{PASS}.\mathsf{Sn},\tau _2)$|⁠, |$\mathsf{R^*}_{\lambda _i} = (\mathsf{R}_{\lambda _i},\mathsf{sk_{\mathcal{P}}}(hash(\mathsf{R}_{\lambda _i})))$|⁠, stores in the SpentCityPASSES database: (⁠|$\mathsf{PASS^*},\psi _{\lambda ,(k_{\lambda _i}-1)}$|⁠), updates the value of |$k_{\lambda _i}=(k_{\lambda _i}-1)$|⁠, stores it with the ticket information and sends |$\mathsf{m}_{4}=\mathsf{R^*}_{\lambda _i}$| to |$\mathcal{U}$|⁠. In the last operation, getValidationConfirmation|$\mathcal{U}$| checks the signature of |$\mathsf{R^*}_{\lambda _i}$|⁠, computes |$\mathsf{RI}_{\lambda _i} = \mathsf{A}_{\mathcal{P}} \oplus PRNG(\mathsf{h}_{\mathsf{K}})$|⁠, verifies |$\mathsf{h}_{\mathsf{RI}_{\lambda _i}} \stackrel{?}{=} hash(\mathsf{RI}_{\lambda _i})$| and stores in her TicketsPASS database |$(\mathsf{R^*}_{\lambda _i},\mathsf{RI}_{\lambda _i})$| together with |$\mathsf{PASS^*}$| and |$k_{\lambda _i}=(k_{\lambda _i}-1)$|⁠. 5. Integration of an Anonymous Payment System The protocol presented in the previous section preserves the user privacy allowing the user to remain anonymous when using the services and even during the whole process. We consider the payment phase as out of scope of the protocol because the proposed scheme is independent of the used payment system but, in fact, payment could be a way to void anonymity. We have analyzed some alternatives that can be used to integrate the payment of a CityPASS in the protocol maintaining the anonymity of the system and have implemented one of them. As a tool for broad public, mCityPASS should support general payment methods, such as credit cards. For this reason, we briefly describe several solutions for paying anonymously for the purchase of an mCityPASS: Prepaid credit cards. A prepaid credit card can be bought using cash and does not have a name on it. This is the least sophisticated way to pay anonymously, and it is only truly anonymous if cash is used to buy the prepaid card. Masked or virtual credit cards. They are similar to prepaid credit cards but they can be bought online, i.e. EntroPay1 or Abine Blur2 . These systems allow the creation of disposable cards on the fly, protecting the users from fraud and keeping the user’s personal information and spending habits private. Cryptocurrencies. This payment method has been growing steadily in popularity in the past few years. More and more sites are accepting it for payment, as the included in this list.3 Bitcoin [25] can be used to make anonymous payments, but in fact there are other cryptocurrencies that offer more privacy, such as Monero (XMR), Zcash (ZEC) or Dash. The user would use a cryptocurrency wallet to make the payment. Intermediaries, such as PayPal or Shopify Pay. Using an intermediary to make the payment hides the payment information to the merchant. If a user buys an mCityPASS using an intermediary, the payment information can not be used to link the pass to the payers identity and, since the mcitypass purchase protocol is anonymous, the user will remain anonymous. We have integrated a Bitcoin wallet to our app as an illustration case of anonymous payment system to be used with mCityPASS. This way, any user can buy a ticket, and then she can proceed to automatically pay for it to a given bitcoin address (Fig. 5). FIGURE 5. Open in new tabDownload slide MCPA with the Wallet tab selected,and six transactions are displayed in it. FIGURE 5. Open in new tabDownload slide MCPA with the Wallet tab selected,and six transactions are displayed in it. In order to do that, the mCityPASS gateway that processes a ticket purchase will generate a new bitcoin address to receive the payment. Then, on the client’s side, we have incorporated the bitcoin wallet to deal with the bitcoin transaction and broadcasts it to the bitcoin network. Next the issuer |$\mathcal{I}$| will check whether the transaction is confirmed or not at the bitcoin network. The issuer of the ticket, at the PASS Purchase phase of the protocol, generates a bitcoin address at the new Step 3 of the getChallenge operation (see Section A.3). Then, at Step 8 of the solveChallenge operation the user has to use the integrated bitcoin wallet of the appMCPA to pay for the ticket purchase (Fig. 6). Depending on the internal policy, |$\mathcal{I}$| can wait for the payment confirmation at the bitcoin network before issuing the new |$PASS{^*}$| or he can immediately send the |$PASS{^*}$| to the user. FIGURE 6. Open in new tabDownload slide A current ticket purchase with the corresponding confirmation pop-up message. FIGURE 6. Open in new tabDownload slide A current ticket purchase with the corresponding confirmation pop-up message. The fairness of the payment is assured in both sides of the communication, because, on the one hand, the user has the signed bitcoin address from |$\mathcal{I}$| together with the transaction registered at the blockchain that works as evidence that she has made the payment. Thus, |$\mathcal{U}$| can rise a claim to solve any unfair situation if she does not receive the |$PASS{^*}$| as it is specified in the Preposition 3 of this paper (see Section 8). On the other hand, the issuer can wait for the payment confirmation at the blockchian until the ticket issuing in order to guarantee fairness. We have chosen Bitcoin as an example of payment wallet, but |$\mathcal{I}$| can select other payment methods or cyptocurrencies to achieve additional features. For example, Monero4 has a higher level of privacy or Dash 5 has a feature called instantsend that provides a faster transaction confirmation. 6. Adaptations of the Protocol during the Implementation Phase In this section we will highlight the decisions that have caused modifications or adaptations of the original protocol during the implementation of the e-commerce application, at different layers. Communication layerIn the implementation we have adjusted all the communications over the entities related in the protocol. They have been set up using a secure channel with the HTTPS protocol. In order to establish a secure channel several certificates have been issued by a predefined certificate authority. Database layerDepending on each entity, the data mapping structures have to be different to support the specific attributes to be stored in an isolated way. Thus, we have adapted the data structures and defined the database of each entity. At the same moment, all critical data have been encrypted using a generated AES256 key. Storage layerAs the mobile application is more sensible to be tampered or it has a higher risk of a data leak, all the private and confidential data as keys and passwords have to be secured against unauthorized users. For this reason all of the data specified in the original protocol have been redesigned in order to be securely stored inside the Android Keystore. Application layerDuring the implementation, several actions have been performed to adapt the protocol, such as adding padding to the cryptographic operations, several castings with data types to do the comparisons of the XOR operations, use of timestamps, removal of the escape characters over the strings, some operations at bit level and use of secure functions to copy data structures. Also, the data codification was made adopting the Android Base64 implementation in all nodes of the system. Cryptographic layerThe cryptographic background introduced during the development of the protocol aims to support the implementation issues of the RSA algorithm as the public-key cryptosystem and the Schnorr algorithm to provide the ZKP. All the hashes have been made with a secure hash algorithm, such as SHA256. External librariesOur solution was developed using the java.security package and the Bouncy Castle library6 for the server nodes implementation. Also, the mobile proposal was made using the Spongy Castle library7 for Android. These libraries provide a secure implementation of the primitive cryptographic algorithms. 7. Implementation The demonstrator of the protocol proposal is implemented as an mCityPASS framework which involves three parts: the server’s infrastructure, an IoT device as Point of Service (PoS) and an application on the mobile device. Figure 7 shows the landscape framework and their relation between all the components. FIGURE 7. Open in new tabDownload slide mCityPASS framework scenario. FIGURE 7. Open in new tabDownload slide mCityPASS framework scenario. The server’s infrastructure is based on a distributed architecture composed of the following components: mCITYPASSserver (MCPS), which contains |$\mathcal{I}$| and |$\mathcal{P}$| entities and mCITYPASSttp (MCPT), which defines |$\mathcal{T}$|⁠. The client’s infrastructure mCITYPASSapp (MCPA) is in charge of storing the pseudonym and making use of the services provided in the PASS. Both components make use of the mCITYPASSpos (MCPP), which serves as a physical PoS to handle the communications, allowing different communications technologies. 7.1. Server development We set-up two servers (MCPS and MCPT) over the Java SDK 8.0,8 using a Spring framework.9 Our proposal uses the spring-boot-starter-web configuration, which is used to build RESTful [26] web services using Spring MVC,10 which separates data and business logic from a user interface (UI) application, and a self-container web server, such as Tomcat.11 This layer offers the application’s UI, which exposes the data view of the application, making use of Angular12 and Thymeleaf13 libraries. Also, it is in charge of handling the input requests via controllers to interact with the models The RESTful web services exposed provides the Application Programming Interface (API) over a secure channel. The domain layer (back-end) implements the logic and stores the data of the protocol using a Domain-Driven Design (DDD) [27]. This layer is divided in two main sublayers: core and persistance. The core represents the implementation of the logic using a pattern design that divides the implementation in several classes and uses a Facade-Service-Model pattern [28]. Figure 8 shows this pattern over the main entity MCityPass. FIGURE 8. Open in new tabDownload slide Server components stack. FIGURE 8. Open in new tabDownload slide Server components stack. We defined an MCityPassFacade to provide a simplified interface to interact with the MCityPassService, which uses the MCityPass model. The persistence layer communication can be done through the MCityPassRepository. Then several components are modeled to represent the necessary entities over the protocol. In order to store the information, we use a persistent database14 (HSQLDB) as storage that offers a single and fast search engine made in Java. All the database requests are made using an Object-Relational Mapping15 (ORM) technology. 7.2. Mobile client development Hybrid mobile development, which is considered the most portable solution, combines native and web elements for cross-platform mobile development. We used Ionic,16 an open-source hybrid development framework based in Cordova17 library. Our prototype uses this kind of interface to communicate with the native code provided by Android.18 In order to store the local information, we use a SQLite19 persistent database as storage. The main difference between the server relational database scheme is the adoption of the model SECRETVALUE as a local table to store the secret values to interact between the MCPT and MCPS nodes. 7.3. mCityPASS app In our model the interaction between |$\mathcal{I}$| and |$\mathcal{P}$|⁠, which are allocated on the MCPS, occurs at the beginning of the affiliation service phase of the protocol. During this phase, |$\mathcal{P}$| has to communicate with |$\mathcal{I}$| to enroll a service, such communication can be done using the API using a secure channel. After this communication, |$\mathcal{I}$| is able to set all the parameters to add the service. As the first prototype, we only cover the scenario of one |$\mathcal{P}$| enrolled in |$\mathcal{I}$|⁠. The component described below is the central component of our prototype. We divided its logical sequence of actions in four steps for the mCityPASS scenario. As a first step, |$\mathcal{U}$| downloads the MCPA on her Android device, she will be asked to communicate with the MCPT to obtain a pseudonym. After the pseudonym is generated and recorded to the local mobile database, |$\mathcal{U}$| will be able to request an mCityPASS. Then |$\mathcal{U}$| requests a new mCityPASS, and the app asks to choose the |$\mathsf{Lifetime}$| and the |$\mathsf{Category}$| of the PASS displaying detailed information about the available services (see Fig. 9). At this moment, |$\mathcal{U}$| is able to purchase the PASS, and the app is in charge of contacting with |$\mathcal{I}$| to generate the PASS with the provided data. Our solution has implemented a gateway payment based on Bitcoin to maintain the anonymity of the proposed protocol. However, other solutions could be used. FIGURE 9. Open in new tabDownload slide Activity PASS Verification. FIGURE 9. Open in new tabDownload slide Activity PASS Verification. When the PASS has been purchased, the next action is to activate it. From the main screen, a list of purchased passes is then presented, |$\mathcal{U}$| chooses one and this view is updated to allow the activation of the PASS (see Fig. 10). The app is in charge to contact with |$\mathcal{I}$| to activate the PASS. If |$\mathcal{I}$| confirms the correct activation, a pop-up will inform the success to |$\mathcal{U}$|⁠. FIGURE 10. Open in new tabDownload slide Activity PASS Activation. FIGURE 10. Open in new tabDownload slide Activity PASS Activation. Finally, the next screen gives details about the services that |$\mathcal{U}$| has to select. In this case, the mCityPASS offers three services to use depending of the type: infinite, one-time reusable and m-times reusable. At this moment, |$\mathcal{U}$| is able to press which kind of service she will use, and the app is in charge of contacting |$\mathcal{P}$| to validate the ticket. If |$\mathcal{P}$| confirms the correct use of the PASS, a pop-up will inform the success of the operation to |$\mathcal{U}$|⁠. 8. Analysis of Privacy and Security Properties n this section, we examine the accomplishment of the requirements of the system regarding the security and privacy properties. The basis of this rationale about the security properties is the correct use of the cryptographic primitives. Our proposal makes use of the following primitives: Random Bit Generation Digital Signatures Key Wrapping and Public Key Encryption Hash Functions. Thus, in order to make a secure implementation, any application has to take into consideration the official documents that address the use of cryptographic algorithms and which key lengths are specified. The last issue of the NIST document [33] includes the explanation of the projected maximum-security strength of key lengths associated with the cryptographic algorithms. Also, the document has prediction of the period of time throughout the algorithms and the proposed key lengths are expected to provide probable security. That is to say, in order to break the security, any attacker must solve the underlying discrete-logarithm problem of the implemented cryptographic operations. Thus, the protocol provides suitable and practice-oriented provable security as far as implementors chose sufficiently large values of the security parameters and key lengths according to the international standards [33]. Regarding the specific cryptographic operations used in our protocol, there are some deterministic random bit generation procedures that have been described and determined as probably secure in [34]. The digital signature algorithms [35] and key wrapping and public key encryption operations are based on the length and the proper generation of the domain parameters used. In order to provide acceptable security (i.e. no security risk is currently known when used in accordance with any associated guidance), the DSA domain parameter lengths has to be (2048, 224) or (2048, 256), which provide a security strength of 112 bits or (3072, 256), which provides a security strength of 128 bits [33]. Finally, hash function family SHA-2 specified in [36] provides acceptable security for all hash function applications. The system we propose, the mCityPASS scheme, has been planned to fulfill and agreed with the security properties of the electronic tickets that have been listed in [4, 29, 30]. Also, we took into account some special features of the touristic City Cards and for this reason we have included in the list the property of unsplittability. Moreover, reusability and double spending avoidance have been considered together, to provide selective reusablity: Anonymity: any user is not identified while using the proposed system. The scheme does not need to provide revocable anonymity because the fraud is avoided in any case (the service provider checks the correctness of the situation prior allowance of use the service). Authenticity: any user can check whether the PASS booklet has been supplied by an approved issuer. Exculpability: any user of system cannot be falsely accused of overspending by the service. Moreover, this client can prove that the ticket has been validated before making use of the facility or service. Fairness: the exchanges carried out through any protocol run by the involved parties cannot cause any unfair state [31]. Integrity: parties involved in the protocol can check whether a PASS booklet has been modified with respect to the PASS released by the official service provider or issuer. Lifetime and date of expiration: a period of time is established as the only valid period to use a particular PASS booklet. Non-repudiation: the issuer of PASS booklet cannot deny being the author of this specific booklet. Reusability and non-overspending: each PASS booklet contains some reusable and non-reusable tickets. No matter the kind of ticket, the system has to disallow any overspending case. The system also has to assure that the condition of use (approved between user and issuer of the ticket) will always be respected. For this reason, it has to be controlled that the reusable tickets included in the PASS are capable of being used just the established number of times and the non-reusable tickets will not be employed again after they have been used once. Unforgeability: any authorized PASS booklet can only be issued by the official issuers. Unsplittability: different users cannot share and make use of the tickets from the same PASS booklet [20]. We have organized the debate about security issued in six different propositions. In each one there are some claims in order to sustain the accomplishment of the different security properties. Proposition 1. In the proposed scheme any PASS cannot be falsified, and the system assures the properties of integrity authenticity and non-repudiation. Claim 1. Non-authorized users cannot gain access to the service. In order to use any service included in the PASS, |$\mathcal{U}$| has to prove that she knows the secret number |$\mathsf{RU}$| associated with the PASS. This number has been generated by the owner of the ticket and is never revealed. Only the authentic |$\mathcal{U}$| can prove its knowledge by means of the ZKP proof specified in the PASS Verification phase. The |$\mathsf{RU}$|’s values correspondent to the tickets are stored in the SECRETVALUE entity. In case of brute force attack trying to guess the value of RU, the benefit that the attacker can achieve is the access to a single PASS, since each PASS has its own SECRETVALUE. For this reason, the benefit that an attacker can achieve is not worth the effort. Claim 2. Any user of the mCityPASS scheme can verify the authenticity and the integrity of a PASS. A PASS has the following structure: |$\mathsf{PASS^*} = (\mathsf{PASS},\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})})$|⁠, where |$\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})}$| is the issuer’s digital signature on the PASS using a provably secure signature scheme. Thus, anyone cannot counterfeit or forge the ticket and, besides, the authenticity of the document can be verified by using issuer’s public key. Claim 3. Users have a non-repudiation evidence of the right to use the service. At the verification phase, after checking the correctness of the PASS, |$P_{i}$| discloses the correspondent |$\mathsf{RI_{i}}$| to |$\mathcal{U}$|⁠. Next |$P_{i}$| forwards (⁠|$\mathsf{R^*}_{i}, \mathsf{RI_{i}}$|⁠) to |$\mathcal{U}$|⁠. Thus, |$\mathcal{U}$| has a non-repudiation evidence with the provider’s signature on |$\mathsf{R^*}_{i}$|⁠. This evidence gives the right to |$\mathcal{U}$| if she wants to use the service. Moreover, a timestamp (⁠|$\tau _i$|⁠) is included in the signature. Hence, if |$\mathcal{U}$| cannot get access to the service, the gathered evidence can be used in the Authorization Failure CLAIM included in the dispute resolution protocol to bring back the fairness. This is possible because the exchange protocols of our scheme have been planned as fair exchanges in such a way that |$\mathcal{U}$| reveals the seed of hash function in exchange of the right of using a service.20 Result 1. Users have to successfully perform a ZKP proof in order to authenticate before gaining access to the service. Additionally, they receive a non-repudiation evidence from |$P_{i}$|⁠, which they can use to prove that they have the right to access the service. Also, the integrity and authenticity of the PASS can be checked thanks to issuer signature on it. Proposition 2. The mCityPASS scheme protects the user privacy and preserves the anonymity of them. Furthermore, the system can prevent the linkability of different PASSes of the same user. Claim 4. Honest users can preserve their anonymity in the mCityPASS scheme. Any |$\mathcal{U}$| only needs to disclose her identity in front of |$\mathcal{T}$| when she applies for a new pseudonym. Then |$\mathcal{U}$| can use the system by using her |$\mathsf{Pseu_{\mathcal{U}}} = (\mathsf{y}_{\mathcal{U}},\mathsf{sk_{\mathcal{T}}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}}))$| obtained during PHASE 2 of the protocol and no further identification is needed. In fact, |$\mathsf{Pseu_{\mathcal{U}}}$| is embedded in the PASS and there is only one signature performed by |$\mathcal{U}$| in the verification phase (⁠|$\mathsf{sk}_{\mathcal{U}}(\mathsf{pk_{\mathcal{P}}}_{i}(\mathsf{PASS}.\mathsf{Sn}, \mathsf{w}_{3}, \tau _1))$| at the verifyPASS; see A.5) to prove that the secret number |$\mathsf{RU}$| associated with the ticket comes from the authentic owner. However, any actor of the system cannot disclose users identity, since |$\mathcal{T}$| is a trusted party that will never reveal the identity of any honest |$\mathcal{U}$|⁠. Claim 5 Users are able to unlink their PASSes. Pseudonyms are used by the mCityPASS scheme so as to preserve their anonymity. Thus, inside the ticket booklet is not possible to find the genuine identity of the user. Therefore, users can easily unlink their PASSes if they change the pseudonym regularly. In fact, they can renew the pseudonym each time before buying a new PASS. Claim 6. The mCityPASS does not need to make use of the revocable anonymity of users. In our protocol, users have to receive a special token from |$P_{i}$| prior to use any service. In addition to that, the protocol has been designed in such a way that |$P_{i}$|⁠, before sending the token, always checks whether |$\mathcal{U}$| has the right to use the service or not. Thus, if any |$\mathcal{U}$| (a dishonest one) tries to use the service without having the right PASS, then |$P_{i}$| will be able to detect him. However, if any illegal action has been committed by any |$\mathcal{U}$|⁠, the revocation of the anonymity could be possible since |$\mathsf{Pseu_{\mathcal{U}}}$| can disclose the identity of |$\mathcal{U}$| if it receives a requirement from a law enforcement agency (e.g. a court of law). Result 2 Users can anonymously use the service and they are able to unlink their PASSes. Thus, their privacy is assured. Proposition 3. The mCityPASS protocol meets the security requirement of fairness and exculpability. Claim 7. An honest user that fulfills the protocol will receive the appropriate response from the system. If |$\mathcal{U}$| does not agree with the provider’s response when she tries to get access to the service, she can contact with |$\mathcal{T}$| and rise a claim. The protocol provides a non-repudiation evidence of the provider’s response to the users. Therefore, |$\mathcal{U}$| can submit this evidence |$\mathcal{T}$|⁠. Next |$\mathcal{T}$| can analyze the submitted evidence and, depending on the result of the evaluation, it can side by |$\mathcal{U}$| or |$P_{i}$| or not. In Section 4 of [9], each exception case is described, i.e. when |$\mathcal{U}$| receives a message from |$P_{i}$| with an error flag (there is summary of the different flags in Fig. 2). At this point, in case of not accepting the received message, the |$\mathcal{U}$| can collect the appropriate evidence. The collected evidence, in each case, allows |$\mathcal{T}$| to check which actor of the protocol has followed the protocol specification. Since |$\mathcal{T}$| acts as a neutral judge, it will side by the right party and, as a result, its actions will have the purpose to correct the unfair situation (i.e. |$\mathcal{U}$| will receive the appropriate response from the system according to the submitted evidence). Claim 8. The service provider |$P_{i}$| does not need to contact the TTP to correct any unfair situation. The mCityPASS system is designed in such a way that |$P_{i}$| can detect any inaccurate item sent by |$\mathcal{U}$|⁠. In this case, it can correct the situation by sending the appropriate error message with the corresponding flag, so there is no need to contact |$\mathcal{T}$|⁠. Claim 9. Any |$P_{i}$| cannot dishonestly inculpate any user of overspending the tickets. The system fulfills the exculpability property and any mischievous provider cannot deny the access to a non-reusable service nor decrease the number of times that any reusable service associated with a ticket can be employed. The exculpability is an advantageous property for our scheme, because the system has to guarantee that both parties (users and providers) receive the expected data items.21 The mCityPASS system provides |$\mathcal{U}$| with non-repudiation of origin messages (⁠|$\mathsf{m}_{2}={\mathsf{V_{succ}}}^{*}$| and |$\mathsf{m}_{4}=\mathsf{R^*}_{\lambda _i}$|⁠) that prove that she has correctly validated the PASS before using the service. Thus, |$P_{i}$| cannot misbehave and falsely refer to |$\mathcal{U}$| as a dishonest user who tries to use the service without permission, since |$\mathcal{U}$| has the appropriate evidence to prove that she is honest (see Claim 3). If |$\mathcal{U}$| had not received the pertinent evidence during the protocol run, then she would have been able to rise a claim by contacting |$\mathcal{T}$| so as to keep the fairness property. Result 3. The system assures the fairness of the protocol between users and |$P_{i}$|⁠. In addition, the exculpability property is assured because the tickets are validated before the users employ the service and they can prove this validation. Proposition 4. The system allows the configuration of the reusability property for each service. Each PASS booklet can contain non-reusable services, m-times reusable services and infinitely reusable services. However, the tickets of the |$\mathsf{PASS}$| cannot be shared among several users. Claim 10. The providers |$P_{i}$| can select if the services offered must be reused or not. During the providers’ affiliation (PHASE 1), each provider indicates if the offered service must be marked as non-reusable service (⁠|$\gamma _i$|⁠), an |$m$|-times reusable service (⁠|$\lambda _i$|⁠) or a infinitely reusable service (⁠|$\xi _i$|⁠). |$\mathcal{P}$| sends this information on the Authenticate provider operation (Step 2). This information will be used later in the PASS Purchase (PHASE 3), in the Solve Challenge operation. Claim 11. Users must use the services according to the reusability defined in the PASS booklet. When a |$\mathcal{U}$| wants to use a service, she executes the PASS Verification phase. The system provides three verification algorithms, depending on the reusability of the service, included in the PASS booklet. Claim 12. The reusability can be limited to a specific predefined number. When a service can be used a limited number of times, it is marked as |$m$|-times reusable service. During the PASS Purchase phase, in the SolveChallenge operation (Step 6), for each m-times reusable service |$\lambda _i$|⁠, |$\mathcal{U}$| computes |$\psi _{\lambda _i,m} =hash^m(\psi _{\lambda _i,0})$| so |$\mathcal{U}$| will have |$m$| tickets to access the service. Claim 13. Some of the services included in the PASS booklet can be used indefinitely during the lifetime of the |$\mathsf{PASS}$|⁠. For an infinitely reusable service |$\xi _i$|⁠, |$P_{i}$| verifies that |$\mathsf{PASS}$| is a valid PASS booklet. In this case, whenever |$\mathcal{U}$| presents a valid |$\mathsf{R^*}_{\xi }$| and the current date is lower than |$\mathsf{LIMdate}$|⁠, the service can be used again. Claim 14. Users cannot detach and share a single ticket with another user. If |$\mathcal{U}$| wants to give a single ticket to another |$\mathcal{U}$|⁠, she cannot do it without sharing the secret information related to the involved |$\mathsf{PASS}$|⁠. That is, the owner of the |$\mathsf{PASS}$| has to give to the receiver not only the ticket, |$\gamma _i$| or |$\lambda _i$|⁠, but also the whole signed |$\mathsf{PASS}$| (show |$\mathsf{PASS}$| operation of the verification phase). Moreover, |$\mathcal{U}$| has to share the secret value |$\mathsf{RU}$|⁠, which is required for the verification of all the tickets of the |$\mathsf{PASS}$|⁠. So, any |$\mathcal{U}$| cannot partially share the |$\mathsf{PASS}$|⁠, it is an all or nothing sharing. Hence, the protocol achieves the property of unsplittability that discourages sharing. Result 4. PASS booklet allows the coexistence of different kinds of services with different reusability requirements. Proposition 5. Users cannot use a service more times than the specified for that service in the mCityPASS. Claim 15. Users cannot double spend a non-reusable ticket. In the verification stage of a non-reusable service, during the VerifyPASS operation (Step 3), |$P_{i}$| looks for the PASS in its SpentCityPASSES database using |$\mathsf{PASS}.\mathsf{Sn}$|⁠. If |$\exists \psi _{\gamma _i, 0}$| linked to |$\mathsf{PASS^*}$| in the database, |$P_{i}$| assigns |$\mathsf{V_{fail}} = (\mathsf{PASS}.\mathsf{Sn},\psi _{ \gamma _i, 0},\mathsf{flag}_{02},\tau _1, \gamma _i)$| and sends |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$|to |$\mathcal{U}$| indicating that this non-reusable ticket of the PASS had already been used. The verification is stopped and |$\mathcal{U}$| cannot use the ticket again. Claim 16. Users cannot use (⁠|$m$|+1)-times an |$m$|-times reusable ticket. In the verification stage of an |$m$|-times reusable service, during the Verify PASS operation (Step 3), |$P_{i}$| looks for the PASS |$\mathsf{PASS^*}$| in its SpentCityPASSES database using |$\mathsf{PASS}.\mathsf{Sn}$| and verifies that the ticket has not already been spent m-times. If |$\exists \psi _{\lambda _i, 0}$| linked to |$\mathsf{PASS^*}$| in the database, |$P_{i}$| assigns |$\mathsf{V_{fail}} = (\lambda _i, \mathsf{PASS}.\mathsf{Sn},\psi _{ \lambda _i, 0},\mathsf{flag}_{04},\tau _1,)$| and sends |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$|to |$\mathcal{U}$| indicating that this reusable ticket of the PASS had already been used m-times. The verification is stopped and |$\mathcal{U}$| cannot use the ticket again. Result 5. Although the mCityPASS includes services with different reusability requirements, any service can be used more than the intended number of uses. Proposition 6. A PASS booklet can only be used during its lifetime, with the duration established in the issue. Claim 17. A PASS booklet cannot be used after its expiration date. In Step 12 of the getPASS operation of PHASE 3: PASS Purchase, |$\mathcal{I}$| includes an expiration date in the PASS. Since the PASS is signed by |$\mathcal{U}$|⁠, the date cannot be modified (see Proposition 1). Later, in Step 1 of verifyPASS operation of PHASE 5: PASS Verification, |$\mathcal{P}$| verifies this date and compares it with the current date, so a PASS cannot be used after its expiration date. TABLE 1. Mobile specifications. Device CPU RAM OS LeMobile Le X820 Kryo 2x2.15 GHz 4 GiB Android 6.0 Sony Xperia Z5 Compact Cortex-A53 4x1.5 GHz 2 GiB Android 5.1.1 Xiaomi Mi-4c Cortex-A53 4x1.4 GHz 2 GiB Android 5.1.1 Samsung Galaxy Note 2 Cortex-A9 4x1.6 GHz 2 GiB Android 4.1.1 Sony Xperia P U8500 2x1 GHz 1 GiB Android 2.3 Device CPU RAM OS LeMobile Le X820 Kryo 2x2.15 GHz 4 GiB Android 6.0 Sony Xperia Z5 Compact Cortex-A53 4x1.5 GHz 2 GiB Android 5.1.1 Xiaomi Mi-4c Cortex-A53 4x1.4 GHz 2 GiB Android 5.1.1 Samsung Galaxy Note 2 Cortex-A9 4x1.6 GHz 2 GiB Android 4.1.1 Sony Xperia P U8500 2x1 GHz 1 GiB Android 2.3 Open in new tab TABLE 1. Mobile specifications. Device CPU RAM OS LeMobile Le X820 Kryo 2x2.15 GHz 4 GiB Android 6.0 Sony Xperia Z5 Compact Cortex-A53 4x1.5 GHz 2 GiB Android 5.1.1 Xiaomi Mi-4c Cortex-A53 4x1.4 GHz 2 GiB Android 5.1.1 Samsung Galaxy Note 2 Cortex-A9 4x1.6 GHz 2 GiB Android 4.1.1 Sony Xperia P U8500 2x1 GHz 1 GiB Android 2.3 Device CPU RAM OS LeMobile Le X820 Kryo 2x2.15 GHz 4 GiB Android 6.0 Sony Xperia Z5 Compact Cortex-A53 4x1.5 GHz 2 GiB Android 5.1.1 Xiaomi Mi-4c Cortex-A53 4x1.4 GHz 2 GiB Android 5.1.1 Samsung Galaxy Note 2 Cortex-A9 4x1.6 GHz 2 GiB Android 4.1.1 Sony Xperia P U8500 2x1 GHz 1 GiB Android 2.3 Open in new tab Claim 18. A PASS booklet cannot be used before its activation. The user |$\mathcal{U}$| must send |$\mathsf{\mathsf{ACT}^*}$| to |$\mathcal{P}$| together with the signed PASS in Step 3 of showPASS operation in PHASE 5: PASS Verification. In Step 2 of the verifyPASS operation of the same phase, |$\mathcal{P}$| verifies |$\mathsf{\mathsf{ACT}^*}$| and |$\mathsf{PASS}.\mathsf{ACTdate}$|⁠. If the PASS has not been activated before, |$\mathcal{U}$| will not have this element because it is obtained in the last step of the verifyPASS operation of PHASE 4: PASS Activation. Claim 19. A PASS booklet cannot be used after its limit date. |$\mathsf{LIMdate}$| is calculated adding the |$\mathsf{Lifetime}$| to |$\mathsf{ACTdate}$|⁠. |$\mathsf{Lifetime}$| is included in the PASS during PHASE 3: PASS Purchase and |$\mathsf{ACTdate}$| is included in |$\mathsf{\mathsf{ACT}^*}$| in PHASE 4: PASS Activation. During the operation verifyPASS of PHASE 5: PASS Verification |$\mathcal{P}$| verifies that the present date is no greater than |$\mathsf{LIMdate}$|⁠, in Step 4. Result 6 A PASS booklet can only be used from the activation date to a limit date (activation date + lifetime), provided that the limit date is lower than the expiration date. 9. Experimental results In this section, we describe the operation and performance of the model prototype developed in a local environment making use of different mobile devices. The measured times are presented in two main analyses: asynchronous phase and synchronous phase. Both analyses show the end-to-end execution times. The asynchronous phase involves the operations related with the Pseudonym, Purchase and Activation, which are executed only once for each mCityPASS and are not real time operations. On the other hand, the Verification phase has strong real-time requirements since it is related with the access to the service and could be the cause of congestion at the access point. The measures have been performed one hundred times for each device (see Table 1), making the average of these to mitigate the effect of background processes running on the mobile device. We do not consider the time for the payment validation. We have created a testbed to test the performance of the new protocol in a non-intrusive environment. To obtain the results, a WLAN network has been created without access to Internet using a Raspberry PI as an Access Point (AP). Mobile devices have been connected using the Wi-Fi network. The server’s role has been performed by a laptop, connected to the network using one of the wired Raspberry PI network ports with a Fast Ethernet connection. The testbed configuration and parameters are the following. The laptop running the vendor application is a ‘Thinkpad X250’ with Intel core i7-5600U, 16 GiB and Debian 9. Each entity has been installed in a virtual machine with 4 GiB RAM and Debian 9. The PoS is a Raspberry PI 2 Model B with Broadcom BCM2837 900 MHz, 1 GiB and Raspbian. We generated a RSA key pair of 2048 bits for each entity. To evaluate the scenario, we need to establish a realistic number for the m-times reusable service to compute a hash chain, such as |$\lambda $| = 10. The first analysis includes the Pseudonym, PASS Purchase and PASS Activation. These actions are done in asynchronous mode and are less critical in terms of use, since they can be done before the verification process. Also, it is only necessary to do these steps just once to use the services inside the PASS. Figure 11 shows the execution time for the whole set of mobile devices. The measured execution average Pseudonym is 348.30 ms, PASS Purchase is 299.48 ms and PASS Activation is 58.22 ms. Although the asynchronous operations are not critical, these values are very satisfactory. FIGURE 11. Open in new tabDownload slide Asynchronous execution time. FIGURE 11. Open in new tabDownload slide Asynchronous execution time. The second analysis includes the PASS Verification, either a non-reusable ticket, an m-times reusable ticket, or an infinitely reusable ticket. These actions are performed in synchronous mode and are critical in terms of use, since they are part of the verification process in situ. Figure 12 shows the execution time for the verification operation phase of a non-reusable service. The measured execution average time for the whole set of devices to verify the validity of a ticket is 462.36 ms, being 317.4 ms the result for the fastest device. We have also analyzed the dispersion of the values of the measures in a statistical analysis. This way, the effects of the background processes running in the mobile device can be evaluated. The confidence interval for a confidence level of 95% is quite small, so the majority of the values are very close to the mean. FIGURE 12. Open in new tabDownload slide Synchronous non-reusable service execution time. FIGURE 12. Open in new tabDownload slide Synchronous non-reusable service execution time. Figure 13 shows the execution time for the first verification and the second verification of an m-times reusable service. The measured execution average time for the whole set of devices to verify the validity of the first use of the ticket is 514.80 ms and 437.12 ms for the second validation. This difference is due to the different steps in showPASS and verifyPASS over the m-times reusable service between the first verification and the second verification, being 274,3 ms the result for the fastest device. FIGURE 13. Open in new tabDownload slide Synchronous m-times reusable service execution time. FIGURE 13. Open in new tabDownload slide Synchronous m-times reusable service execution time. Figure 14 shows the execution time for the first verification and the second verification of an infinitely reusable service. The measured execution average time for the whole set of devices to verify the validity of the first use of the ticket is 462.91 ms and 405.52 ms for the second validation. This difference is due to the pre-computed showPASS values over the infinitely reusable service of the first use of the ticket, being 257.6 ms the result for the fastest device. FIGURE 14. Open in new tabDownload slide Synchronous infinitely reusable service execution time. FIGURE 14. Open in new tabDownload slide Synchronous infinitely reusable service execution time. Figure 15 shows the comparison of the first time verification between all the services, being 334.67 ms the result for the fastest device of the average time between a non-reusable service and an infinitely reusable service, as they share the same approximate results over the first time verification. FIGURE 15. Open in new tabDownload slide Comparison first time verification. FIGURE 15. Open in new tabDownload slide Comparison first time verification. Figure 16 shows the comparison of the second time verification between all the services. In this case, the non-reusable service is composed by ‘first time non-reusable + purchase time execution + activation execution time’. It is necessary to purchase and active another PASS, being 257.6 ms the result for the fastest device using an infinitely reusable service. FIGURE 16. Open in new tabDownload slide Comparison second time verification. FIGURE 16. Open in new tabDownload slide Comparison second time verification. FIGURE 17. Open in new tabDownload slide Network overhead. FIGURE 17. Open in new tabDownload slide Network overhead. To determine if these numbers are valid or critical, we have studied the temporal requirements in some real touristic attractions, where queue management is a crucial operation. In the most visited attractions, tourists form queues and can wait for several hours. The access mechanism can be a bottleneck if tickets have to be checked manually or using a slow mechanism. Our protocol manages the automatic access to the attractions and the operations performed to validate the ticket in a secure way involve, among others, cryptographic operations that require computational power. Since these operations are performed in a mobile device we have to be sure that the protocol would be fast enough to avoid the creation of queues at the access point. We have searched information about the queues in the world’s most visited touristic attractions. According to TrypAdvisor,22 the attraction with longest queues in the world is the London Eye, where tourists have to wait in queue for as long as 2.5 hours, followed by the Vatican Museums and the Colosseum in Rome. We have taken as a reference the London Eye to determine a barrier in the evaluation of the delay. The London Eye is visited by 3.5 million tourists per year. With an average of 9 hours of operation per day, we have an average of 1065 visitors per hour. Since the attraction has two entrances, that means a visitor arrives to the attraction every 6.6 seconds in average. Moreover, we have calculated the maximum capacity of the attraction (32 capsules with capacity for 25 passengers every 30 minutes.) This sets a limit of a passenger every 2.25 seconds. Since the delay of the validation subprotocol of the proposed protocol is around 400 ms, it is low enough to overcome both barriers, not only the barrier calculated from the current amount of visitors but even the barrier derived of the maximum capacity of the attraction. Moreover, observing the confidence intervals for a confidence level, we can state that the calculated average values are representative of the whole set of executions, since the confidence intervals are small in all cases for a confidence level of 95%. The maximum values are caused by the background processes executed in the device, but they represent very rare cases as it can be derived from the statistical analysis. However, even these exceptional cases do not represent a significant delay and can be assumed by the system. 9.1. Remote test As a last step, we have tested the server’s infrastructure in a dedicated remote server. During our analysis we observed that the proposed solution is feasible scalable in terms of resources. Moreover, we have analyzed some network overhead observing different requests. Figure 17 shows the network overhead, being 1250.17 ms the average result over the network. These measures will be expanded and detailed in our future work in a complete cloud infrastructure over different real scenarios. In addition to that, and taking into account that the emergent 5G technology claims to end network latency, it is expected better measures in the future results developments. 10. Conclusions In this paper, we have presented a protocol and its implementation with some additional improvements of a complete e-commerce application for secure and private access to touristic services, mCityPASS, including a specific security and privacy analysis. The scheme described in the document enables the users to securely employ touristic services such as monuments, historical places, museums, etc., as well as transportation systems. mCityPASS integrates any category of e-tickets in a single e-booklet. This e-booklet can be formed by any number of reusable and non-reusable e-tickets. As it has been commented in this paper, the implementation of the scheme on smartphones makes the protocol more flexible, versatile, suitable and it helps the user to make use of the touristic attractions and services. The security analysis, including 6 propositions and 19 claims, proves that the system meets the security properties of authenticity, integrity, non-repudiation, unforgeability, non-overspending, anonymity, expiration date and lifetime, fairness, exculpability, unsplittability and selective reusability. Moreover, the system also preserves the privacy of its honest users. The designed implementation follows the main principles of software quality such as maintainability, dependability, efficiency and usability. All the main features are divided in modules, implemented as microservices. The business logic has been built on top of the core Spring framework, providing flexibility and robustness. The cryptography has been implemented using the cryptographic libraries provided in the Java security package, offering dependability and efficiency in terms of security. Finally, a hybrid mobile application has been built to offer an elegant and user-friendly interface. The performance analysis of the mCityPASS system proves that the system is robust, efficient and suitable to be accepted as an e-ticket solution. The execution times show two main analyses: asynchronous phase, which it has on average an execution time of 706.15 ms for the whole set of mobile devices, being 483.08 ms for the fastest device. This phase is only executed one time per issued PASS. For the synchronous phase, the measured execution average time for the whole set of devices to verify the validity of the ticket over all the services is less than 500 ms. Also, the use of m-times and infinitely reusable services have a better performance for the verifications after the first use with respect to the issuance of multiple non-reusable services. As a result, all execution times provide a feasible solution in terms of viability and usability. 11. Future Work Since mobile technologies help to promote the integration of different e-commerce services in a smart city context, our future work goes in the direction to include more services inside our system. Thus, we are currently working on the integration of services such as maps, waiting queue management, payment systems and others inside the mCityPASS application to offer a more comprehensive solution to users and service providers. Once the security and privacy requirements of the system have been proved and the performance of the prototype has been evaluated, the final step of the application will be to test it in a real scenario in order to achieve a new e-business solution. Our performance evaluation has been focused on the results on the client’s side. Since the system cannot control the computational power of the devices used by the users accessing the system, we have tested several devices, both old, with reduced computational power, and new to be sure that any device is useful to access the system with delays small enough to avoid creating uncomfortable waits. Taking into account that each verification to access a service represents a physical access of a person (e.g. crossing an access door or accessing a bus or train), the obtained results, always below 300 ms for the newest device and in any case higher than a second, are well suited to avoid queues. The server’s side of the system can be considered scalable and can be controlled by the system developers. So as to test the scheme in a real scenario, our future work will be centered in the test of the prototype in different contexts. In the first place, we will test the system in a stand-alone scenario. This will be the case of a particular service provider offering a local and single service, as a museum. The second scenario will replace the local server by a remote server. This scenario will be used by decentralized service providers, as some transport systems. Finally, the last step of the test will be a scenario where the server part of the system would be placed in the cloud. This scenario will be useful to test the system in real situations, with different levels of congestion on the network. ACKNOWLEDGMENTS We acknowledge the Ministerio de Economia, Industria y Competitividad (MINECO), the Agencia Estatal de Investigacion (AEI) and the European Regional Development Funds (ERDF) for its support to the projects AccessTUR TIN2014-54945-R, FeltiCHAIN RTI2018-097763-B-I00 (MINECO/AEI/ERDF, EU) and CONSENT RTI2018-095094-B-C21 (MINECO/AEI/ERDF, EU). Footnotes 1 entropay.com 2 abine.com 3 https://99bitcoins.com/who-accepts-bitcoins-payment-companies-stores-take-bitcoins/ 4 http://monero.org 5 https://www.dash.org 6 https://www.bouncycastle.org/ 7 https://rtyley.github.io/spongycastle/ 8 https://docs.oracle.com/javase/8/ 9 https://spring.io 10 https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html 11 http://tomcat.apache.org/ 12 https://angularjs.org/ 13 http://www.thymeleaf.org/ 14 http://hsqldb.org/ 15 http://hibernate.org/orm/what-is-an-orm/ 16 https://ionicframework.com/ 17 https://cordova.apache.org/ 18 https://www.android.com/ 19 https://www.sqlite.org/ 20 Fair exchange protocols: the users involved in a protocol run that follow its specification receive all required items or none of them can get any the expected item, in this case the exchange of [32]. 21 A secret value that proves that |$\mathcal{U}$| can employ the service is exchanged by the item sent by |$P_{i}$| (a secret value received by |$\mathcal{U}$| that allows her to use the service, that is a fair exchange 22 https://www.news.com.au/travel/world-travel/europe/tripadvisor-reveals-worlds-10-worst-tourist-attractions-for-queues/news-story/8c08159e8366cb2fcfa83aeaedbafce3 References 1 Angeloni , S. ( 2016 ) A tourist kit made in Italy: An intelligent system for implementing new generation destination cards . Tour. Manag. , 52 , 187 – 209 . Google Scholar Crossref Search ADS WorldCat 2 Basili , A. , Liguori , W. and Palumbo , F. ( 2014 ) NFC smart tourist card: Combining mobile and contactless technologies towards a smart tourist experience . In 23rd Int. WETICE IEEE Conf. , pp. 249 – 254 , Parma . IEEE. doi: 10.1109/WETICE.2014.61 Google Preview WorldCat COPAC Crossref 3 Kos-Labedowicz , J. ( 2014 ) Integrated e-ticketing system . In Possibilities of Introduction in EU , pp. 376 – 385 . Springer Berlin Heidelberg . Google Preview WorldCat COPAC 4 Mut-Puigserver , M. , Payeras-Capella , M. , Ferrer-Gomila , J. , Vives-Guasch , A. and Castella-Roca , J. ( 2012 ) A survey of electronic ticketing applied to transport . Comput. Secur. , 31 , 925 – 939 . Google Scholar Crossref Search ADS WorldCat 5 Payeras-Capella , M. , Mut-Puigserver , M. , Castella-Roca , J. and Bondia-Barcelo , J. ( 2016 ) Design and performance evaluation of two approaches to obtain anonymity in transferable electronic ticketing schemes . Mobile. Netw. Appl. , 22 , 1137 – 1156 . Google Scholar Crossref Search ADS WorldCat 6 Puhe , M. , Edelmann , M. and Reichenbach , M. ( 2014 ) Integrated Urban E-ticketing for Public Transport and Touristic Sites . European Parliamentary Research Service . Google Preview WorldCat COPAC 7 City Cards We love city cards . http://welovecitycards.com (accessed February 2019) . 8 Inc. City Pass. http://citypass.com (accessed February 2019) . 9 Mut-Puigserver , M. , Payeras-Capella , M. , Castella-Roca , J. and Huguet-Rotger , L. ( 2018 ) mCITYPASS: Privacy-Preserving Secure Access to Federated Touristic Services with Mobile Devices, Studies in Computational Intelligence Book Series (SCI) , Vol. 727, pp. 135 – 160 . Springer International Publishing . Google Preview WorldCat COPAC 10 London and Partners Over 65 million visits to London attractions in 2015 . http://www.londonandpartners.com/media-centre/press-releases/2016/070316-over-65-million-visits-to-london-attractions-in-2015 (accessed January 2019) . 11 European Union Cleaner and better transport in cities, Civitas 2020 . http://www.civitas.eu/content/integrated-e-ticketing-system (accessed February 2019) . 12 Wermuth , S. and Bohm , C. ( 2005 ) Location-based ticketing in public transport . In Proc. 8th Int. IEEE Conf. Intelligent Transportation Systems (Vol. 12 ), pp. 837 – 840 , Funchal, Portugal . IEEE. doi: 10.1109/ITSC.2005.1520158 Google Preview WorldCat COPAC Crossref 13 Mallat , N. , Rossi , M. and Kristiina Tuunainen , V. ( 2008 ) An empirical investigation of mobile ticketing service adoption in public transportation . Personal Ubiquitous Comput. , 12 , 57 – 65 . Google Scholar Crossref Search ADS WorldCat 14 Chow , J. ( 2014 ) Policy analysis of third party electronic coupons for public transit fares . Transp. Res. A: Policy Pract. , 66 , 238 – 250 . Google Scholar Crossref Search ADS WorldCat 15 Vives-Guasch , A. , Payeras-Capella , M. , Mut Puigserver , M. , Castella-Roca , J. and Ferrer-Gomila , J. ( 2012 ) A secure e-ticketing scheme for mobile devices with near field communication (NFC) that includes exculpability and reusability . IEICE Trans. , 95 , 78 – 93 . Google Scholar Crossref Search ADS WorldCat 16 Bang , S. , Park , K. , Kim , W. , Park , G. and Im , D. ( 2013 ) Design and implementation of nfc-based mobile coupon for small traders and enterprisers . In 2013 Int. Conf. IT Convergence and Security (ICITCS) , pp. 1 – 2 , Macao . IEEE. doi: 10.1109/ICITCS.2013.6717763 Google Preview WorldCat COPAC Crossref 17 Dominikus , S. and Aigner , M. ( 2007 ) mcoupons: An application for near field communication (nfc) . In Advanced Information Networking and Applications Workshops, AINAW’07 (Vol. 2 ), pp. 421 – 428 , Niagara Falls, Canada . Google Preview WorldCat COPAC 18 Hsiang , H. ( 2014 ) A secure and efficient authentication scheme for m-coupon systems . In 2014 8th Int. Conf. Future Generation Communication and Networking , pp. 17 – 20 , Hainan Island . Google Preview WorldCat COPAC 19 Liu , X. and Xu , Q. ( 2009 ) Practical compact multi-coupon systems . In 2009 IEEE Int. Conf. Intelligent Computing and Intelligent Systems (Vol. 3 ), pp. 211 – 216 , Shanghai, China . IEEE. doi: 10.1109/ICICISYS.2009.5357948 Google Preview WorldCat COPAC Crossref 20 Chen , L. , Escalante , A. , Lohr , H. , Manulis , M. and Sadeghi , A. ( 2007 ) A privacy-protecting multi-coupon scheme with stronger protection against splitting . In Int. Conf. Financial Cryptography and Data Security, Scarborough, Trinidad/Tobago , pp. 29 – 44 . Springer Berlin Heidelberg , Berlin, Heidelberg . Google Scholar Crossref Search ADS Google Preview WorldCat COPAC 21 Armknecht , F. , Escalante , A. , Lohr , H. , Manulis , M. and Sadeghi , A. ( 2008 ) Secure Multi-Coupons for Federated Environments: Privacy-Preserving and Customer-Friendly . In Lecture Notes in Computer Science book series (LNCS 4991) , pp. 29 – 44 . Springer , Berlin Heidelberg, Berlin . Google Scholar Crossref Search ADS Google Preview WorldCat COPAC 22 Stallings , W. ( 2017 , 2017 ) Cryptography and Network Security: Principles and Practice (7th edn). Pearson Education Ltd ISBN 13:978–0134444284 . Google Preview WorldCat COPAC 23 Dingledine , R. , Mathewson , N. and Syverson , P. ( 2004 ) Tor: The second-generation onion router . In 13th USENIX Security Symposium (Vol. 13 ), pp. 21 – 21 , USENIX Association Berkeley , San Diego, CA, USA . Google Preview WorldCat COPAC 24 Schnorr , C. ( 1991 ) Efficient signature generation by smart cards . J. Cryptology , 4 , 161 – 174 . Google Scholar Crossref Search ADS WorldCat 25 Nakamoto Bitcoin: A peer-to-peer electronic cash system . https://bitcoin.org/en/ (accessed February 2019) . 26 Thomas , R. Architectural styles and the design of network-based software architectures . https://www.ics.uci.edu/fielding/pubs/dissertation/top.htm (accessed February 2019) . 27 Evans , E. ( 2004 ) Domain-Driven Design: Tackling Complexity in the Heart of Software , Addison-Wesley ISBN 978-032-112521-7 . Google Preview WorldCat COPAC 28 Gamma , E. , Helm , R. , Johnson , R. and Vlissides , J. ( 1994 ) Design Patterns: Elements of Reusable Object-Oriented Software , p. 185ff . Addison-Wesley ISBN 0-201-63361-2 . Google Preview WorldCat COPAC 29 Arfaoui , G. , Dabosville , G. , Gambs , S. , Lacharme , P. and Lalande , J. ( 2014 , 2014 ) A privacy-preserving NFC mobile pass for transport systems . EAI Endorsed Trans. Mobile Commun. Appl. , 2 , e4 . Google Scholar Crossref Search ADS WorldCat 30 Han , J. , Chen , L. , Schneider , S. , Treharne , H. and Wesemeyer , S. ( 2017 ) Privacy-preserving electronic ticket scheme with fine-grained pricing . CoRR . http://arxiv.org/abs/1706.03016 . 31 Asokan , N. ( 1998 ) Fairness in electronic commerce . Ph. D. Thesis, University of Waterloo , Canada . Google Preview WorldCat COPAC 32 Asokan , N. , Schunter , M. and Waidner , M. ( 1997 ) Optimistic protocols for fair exchange . In Proc. 4th ACM Conf. Computer and Communications Security, CCS’97 , pp. 7 – 17 , ACM , New York, NY, USA . doi: 10.1109/ICICISYS.2009.5357948 . Google Preview WorldCat COPAC Crossref 33 National Institute of Standards and Technology (NIST) , Barker , E.B. and Kelsey , J.M. ( March 2019 ) Transitions: Recommendation for the transitioning of the use of cryptographic algorithms and key lengths . In DRAFT NIST Special Publication 800-131A . https://doi.org/10.6028/NIST.SP.800-131Ar2 . 34 Barker , E.B. and Kelsey , J.M. Recommendation for Random Number Generation Using Deterministic Random Bit Generators . National Institute of Standards and Technology, Gaithersburg, Maryland, NIST Special Publication (SP) 800-90A, Rev. 1, June 2015. https://doi.org/10.6028/NIST.SP.800-90Ar1 . 35 National Institute of Standards and Technology (NIST) Digital Signature Standard (DSS) . U.S. Department of Commerce, Washington, D.C., Federal Information Processing Standards Publication (FIPS) 186-4, July 2013 . https://doi.org/10.6028/NIST.FIPS.186-4 . 36 National Institute of Standards and Technology ( 2015 ) Secure Hash Standard (SHS) . U.S. Department of Commerce, Washington, D.C., Federal Information Processing Standards Publication (FIPS) 180-4 . https://doi.org/10.6028/NIST.FIPS.180-4 . APPENDIX A: Detailed Description of the Protocol A.1. PHASE 1: Provider’s affiliation |$\mathcal{I}$| choose a certain public key algorithm (e.g. RSA, DSA) for the creation of |$P_{i}$|’s public-key pairs. authenticateProvider Provider |$P_{i}$| follows the next steps: generates a public-key pair for a the chosen public key algorithm and the appropriate parameters; sends this cryptographic public information and the information of its service (either |$\gamma _i$|⁠, |$\lambda _i$| or |$\xi _i$| depending on the reusability of the service) to |$\mathcal{I}$| via a secure and authenticated channel. generateCertificate Issuer |$\mathcal{I}$| executes: verify that the information is correct; generate a public key certificate for the |$P_{i}$| (i.e. linked to the service |$\gamma _i$| or |$\lambda _i$|⁠). A.2. PHASE 2: Pseudonym authenticateUser User |$\mathcal{U}$| follows the next steps: generates |$\mathsf{x}_{\mathcal{U}} \stackrel{R}{\rightarrow } \mathsf{Z}_q$|⁠, and computes |$\mathsf{y}_{\mathcal{U}} = {\alpha }^{\mathsf{x}_{\mathcal{U}}} \pmod p$|⁠; computes the signature |$\mathsf{sk}_{\mathcal{U}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}})$| where |$\mathsf{h}_{\mathsf{y}_{\mathcal{U}}} = hash(\mathsf{y}_{\mathcal{U}})$|⁠; encrypts |$\mathsf{y}_{\mathcal{U}}$| with the |$\mathcal{T}$|’s public key: |$\mathsf{pk_{\mathcal{T}}}(\mathsf{y}_{\mathcal{U}})$|⁠; sends |$(\mathsf{sk}_{\mathcal{U}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}}), \mathsf{Cert_{\mathcal{U}}}, \mathsf{pk_{\mathcal{T}}}(\mathsf{y}_{\mathcal{U}}))$| to |$\mathcal{T}$|⁠. generatePseudonym Pseudonym Manager |$\mathcal{T}$| executes: decrypts |$\mathsf{sk_{\mathcal{T}}}(\mathsf{pk_{\mathcal{T}}}(\mathsf{y}_{\mathcal{U}}))\rightarrow (\mathsf{y}_{\mathcal{U}})$|⁠; verifies |$\mathsf{y}_{\mathcal{U}}$|⁠: |$\mathsf{pk}_{\mathcal{U}}(\mathsf{sk}_{\mathcal{U}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}}))\rightarrow (\mathsf{h}_{\mathsf{y}_{\mathcal{U}}})\stackrel{?}{=} hash(\mathsf{y}_{\mathcal{U}})$|⁠; if correct, then computes the signature of |$\mathsf{sk_{\mathcal{T}}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}})$|⁠; and sends |$\mathsf{Pseu_{\mathcal{U}}} = (\mathsf{y}_{\mathcal{U}},\mathsf{sk_{\mathcal{T}}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}}))$| to |$\mathcal{U}$|⁠. verifyPseudonym|$\mathcal{U}$| computes: verifies |$\mathsf{y}_{\mathcal{U}}$|⁠: |$\mathsf{pk_{\mathcal{T}}}(\mathsf{sk_{\mathcal{T}}}(\mathsf{h}_{\mathsf{y}_{\mathcal{U}}}))\rightarrow (\mathsf{h}_{\mathsf{y}_{\mathcal{U}}})\stackrel{?}{=} hash(\mathsf{y}_{\mathcal{U}})$|⁠; A.3. PHASE 3: PASS Purchase getService|$\mathcal{U}$| executes: selects the desired Type of PASS |$\mathsf{Type}$|(⁠|$\mathsf{Lifetime}$|⁠, |$\mathsf{Category}$|⁠); generates a random value |$\mathsf{RU} \stackrel{R}{\rightarrow } \mathsf{Z}_q$| computes |$\mathsf{H}_{\mathcal{U}} = {\alpha }^{\mathsf{RU}} \pmod p$|⁠; generates two more random values |$a_{1},a_{2} \stackrel{R}{\rightarrow } \mathsf{Z}_q$| to be used in the Schnorr proof; computes |$A_{1} = {\alpha }^{a_{1}}\pmod p$|⁠; computes |$A_{2} = {\alpha }^{a_{2}}\pmod p$|⁠; sends |$(\mathsf{Pseu_{\mathcal{U}}}, \mathsf{H}_{\mathcal{U}}, A_{1}, A_{2}, \mathsf{Type})$| to the ticket issuer |$\mathcal{I}$|⁠. getChallenge|$\mathcal{I}$| follows the next steps: generates and sends a challenge |$\mathsf{c} \stackrel{R}{\rightarrow } \mathsf{Z}_q$| for |$\mathcal{U}$|⁠; asynchronously, for optimization, pre-computes |${\mathsf{y}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$| and |${\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠. solveChallenge|$\mathcal{U}$| computes: computes |$\mathsf{w}_{1} = a_{1} + \mathsf{c} \cdot \mathsf{x}_{\mathcal{U}} \pmod q$|⁠; computes |$\mathsf{w}_{2} = a_{2} + \mathsf{c} \cdot \mathsf{RU} \pmod q$|⁠; pre-computes the shared session key used in the ticket verification: |$\mathsf{K} = hash(\mathsf{w}_{2})$|⁠; generates a set of |$J$| randoms, (⁠|$J$| is the number of providers) , |$\psi _{1,0},...,\psi _{J,0} \stackrel{R}{\rightarrow } \mathsf{Z}_q$|⁠; for each non-reusable service |$\gamma _i$|⁠, calculates |$\psi _{\gamma _{i},1} =hash(\psi _{\gamma _{i},0})$|⁠; for each m-reusable service |$\lambda _i$|⁠, computes |$\psi _{\lambda _i,m} =hash^m(\psi _{\lambda _i,0});$| stores |$\psi _{1,0},...,\psi _{J,0}$| values in her TicketsPASS database; encrypts and sends the generated information to |$\mathcal{I}$|⁠: |$\mathsf{pk_{\mathcal{I}}}((\mathsf{w}_{1},\mathsf{w}_{2}),(\{\psi _{\gamma _{i},1},\psi _{\lambda _i,m}\} \forall \gamma _i,\lambda _i))$| and pays for the |$\mathsf{PASS}$|⁠. getPASS|$\mathcal{I}$| follows the next steps: decrypts |$\mathsf{sk_{\mathcal{I}}}(\mathsf{pk_{\mathcal{I}}}(\mathsf{w}_{1},\mathsf{w}_{2}))\rightarrow (\mathsf{w}_{1},\mathsf{w}_{2})$|⁠; computes |${\alpha }^{\mathsf{w}_{1}} \pmod p$|⁠; computes |${\alpha }^{\mathsf{w}_{2}} \pmod p$|⁠; verifies |${\alpha }^{\mathsf{w}_{1}} \stackrel{?}{=} A_{1} \cdot{\mathsf{y}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠; verifies |${\alpha }^{\mathsf{w}_{2}} \stackrel{?}{=} A_{2} \cdot{\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠; if both verifications hold, |$\mathcal{U}$| is an authorized user. Otherwise, |$\mathcal{I}$| stops the protocol; computes the shared session key: |$\mathsf{K} = hash(\mathsf{w}_{2})$|⁠; obtains a unique serial number |$\mathsf{Sn}$|⁠, and a set of random values |$\mathsf{RI_{i}} \stackrel{R}{\rightarrow } \mathsf{Z}_p$|⁠, for |$i= 0,,J$|⁠; computes the set |$\mathsf{h}_{\mathsf{RI}_{i}}=hash(\mathsf{RI_{i}})$| for |$i= 1,,J$|⁠; composes the set |$\kappa _{i} = (\mathsf{K},\mathsf{RI_{i}})$| and signs it |$\kappa _{i}^{*} = (\kappa _{i}, \mathsf{Sign_{\mathcal{I}}}(\kappa _{i})) \forall i=1,...,J$|⁠; encrypts each |$\kappa _{i}^{*}$| with a digital envelope decryptable by |$\mathcal{T}$| and |$\mathcal{P}$||$\delta _{\mathcal{T},\mathcal{P}}=\mathsf{pk_{\mathcal{T},\mathcal{P}}}_i(\kappa _{i}^{*})$|⁠. fills out the PASS information |$\mathsf{PASS}$| = (⁠|$\mathsf{Sn}$|⁠, |$\mathsf{Type}$|⁠, |$\mathsf{Pseu_{\mathcal{U}}}$|⁠, |$\mathsf{Lifetime}$|⁠, |$\mathsf{PURdate}$|⁠, |$\mathsf{EXPdate}$|⁠, |$\mathsf{h}_{\mathsf{RI}}$|[ ],|$H_{\mathcal{U}}$||$\delta _{\mathcal{T},\mathcal{P}}$|[ ], |$\psi _{\lambda , m}$|[ ], |$\psi _{\gamma , 1}$|[ ], Terms and Conditions); digitally signs the |$\mathsf{PASS}$|⁠, |$\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})} = \mathsf{sk_{\mathcal{I}}}(hash (\mathsf{PASS}))$|⁠, generates |$\mathsf{PASS^*} = (\mathsf{PASS},\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})})$|⁠; stores in its CityPASS database the information related to this ticket: |$(\mathsf{PASS^*}, \kappa _{i} \quad \forall i=1,...,J);$| sends |$\mathsf{PASS^*}$| to |$\mathcal{U}$|⁠. receivePASS|$\mathcal{U}$| executes: verifies the digital signature |$\mathsf{Sign_{\mathcal{I}}(\mathsf{PASS})}$| of the |$\mathsf{PASS}$| using the issuer’s certificate; verifies |$\mathsf{PASS}$| data and if the performed request match; verifies the PASS validity |$(\mathsf{PASS}.\mathsf{PURdate},\mathsf{PASS}. \mathsf{EXPdate})$|⁠; verifies |$\mathsf{PASS}.\mathsf{Pseu_{\mathcal{U}}}$|⁠; stores in her TicketsPASS database |$(\mathsf{PASS^*},\mathsf{RU})$| together with the associated information stored in the step solveChallenge.7 of this phase. A.4. PHASE 4: PASS Activation showPass|$\mathcal{U}$| computes: sends |$\mathsf{PASS^*}$| to |$\mathcal{I}$|⁠. verifyTicket|$\mathcal{I}$| executes: verifies the |$\mathsf{PASS}$| signature, |$\mathsf{PASS}.\mathsf{PURdate}$| and |$\mathsf{PASS}.\mathsf{EXPdate}$|⁠; if the verifications fail, |$\mathcal{I}$| aborts the ticket activation; else |$\mathcal{I}$| looks for the |$\mathsf{PASS^*}$| in the database using |$\mathsf{PASS}.\mathsf{Sn}$|⁠; (a) if |$\not \exists \mathsf{ACT}$| linked to |$\mathsf{PASS^*}$|⁠: generates |$\mathsf{ACT}= (\mathsf{PASS}.\mathsf{Sn}, \mathsf{ACTdate}, "Activated")$|⁠, signs |$\mathsf{ACT}$|⁠, obtains the signed activation proof, |$\mathsf{Sign_{\mathcal{I}}(\mathsf{ACT})} = \mathsf{sk_{\mathcal{I}}}(hash(\mathsf{ACT}))$|⁠, and |$\mathsf{\mathsf{ACT}^*} = (\mathsf{ACT},\mathsf{Sign_{\mathcal{I}}(\mathsf{ACT})})$|⁠; sends |$\mathsf{\mathsf{ACT}^*}$| to the user |$\mathcal{U}$|⁠. A.5. PHASE 5: PASS Verification The service provider |$\mathcal{P}$| and user |$\mathcal{U}$| follow these steps: showPASS|$\mathcal{U}$| computes: generates a random value |$a_{3}, \stackrel{R}{\rightarrow } \mathsf{Z}_q$| to be used in a Schnorr proof; computes |$A_{3} = {\alpha }^{a_{3}}\pmod p$|⁠; composes the information ticket message |$\mathsf{m}_{1}=(\mathsf{PASS^*}$|⁠, |$\mathsf{\mathsf{ACT}^*}$|⁠, |$A_{3}$|⁠); signs and sends it to |$P_{i}$|⁠: |${\mathsf{m}_{1}}^{*} = (\mathsf{m}_{1},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{m}_{1})))$|⁠. verifyPASS|$P_{i}$| executes: verifies the PASS signature, |$\mathsf{PASS}.\mathsf{Sv}$|⁠, |$\mathsf{PASS}.\mathsf{PURdate}$| and |$\mathsf{PASS}.\mathsf{EXPdate}$|⁠; verifies |$\mathsf{\mathsf{ACT}^*}$|⁠, and |$\mathsf{PASS}.\mathsf{ACTdate}$| calculates |$\mathsf{LIMdate}=\mathsf{ACTdate}+\mathsf{Lifetime}$| verifies that the present date is not greater that |$\mathsf{LIMdate}$| |$\rightarrow $| if any verification fails: assigns |$\mathsf{V_{fail}} = (\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{00},\tau _1)$|⁠. signs |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$| and sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$| |$\rightarrow $| else: looks for |$\mathsf{PASS^*}$| in its SpentCityPASSES database using |$\mathsf{PASS}.\mathsf{Sn}$|⁠; and verifies that the ticket has not been spent: (a) if |$\not \exists \psi _{\gamma _i, 0}$| linked to |$\mathsf{PASS^*}$| in the database: |$P_{i}$| follows the next steps: generates a challenge |$\mathsf{c} \stackrel{R}{\rightarrow } \mathsf{Z}_q$|⁠; assigns |$Challenge = (\mathsf{PASS}.\mathsf{Sn},\mathsf{c},\tau _1)$|⁠; |${Challenge}^{*} = (Challenge,\mathsf{sk_{\mathcal{P}}}_i(hash(Challenge)))$| and sends this signature to |$\mathcal{U}$|⁠; asynchronously, for optimization, pre-computes |${\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠; |$\mathcal{U}$| computes: computes |$\mathsf{w}_{3} = a_{3} + \mathsf{c} \cdot \mathsf{RU} \pmod q$|⁠; encrypts and signs |$\mathsf{w}_{3}$| and, then, sends it to |$P_{i}$|⁠: |$\mathsf{sk}_{\mathcal{U}}(\mathsf{pk_{\mathcal{P}}}_{i}(\mathsf{PASS}.\mathsf{Sn}, \mathsf{w}_{3}, \tau _1))$|⁠; |$P_{i}$| follows the next steps: computes |${\alpha }^{\mathsf{w}_{3}} \pmod p$|⁠; verifies |${\alpha }^{\mathsf{w}_{3}} \stackrel{?}{=} A_{3} \cdot{\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠; |$\rightarrow $|if verification fails: assigns |$\mathsf{V_{fail}} = (\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{01},\tau _1)$|⁠. signs |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$| and sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$| |$\rightarrow $|else: computes |$\mathsf{A}_{\mathcal{P}}= PRNG(\mathsf{h}_{\mathsf{K}}) \oplus \mathsf{RI}_{\gamma _i}$|⁠, where |$PRNG(\mathsf{h}_{\mathsf{K}})$| is a secure pseudorandom number generator and, |$\mathsf{h}_{\mathsf{K}} = hash(\mathsf{K})$| is the seed. Note that |$\mathsf{K}$| and |$\mathsf{RI}_{\gamma _i}$| are obtained from |$\delta _{\mathcal{T},\mathcal{P}_i}$|⁠; encrypts |$\mathsf{A}_{\mathcal{P}}$| with the public key of the TTP |$\mathcal{T}$|⁠: |$\mathsf{pk_{\mathcal{T}}}({\mathsf{A}_{\mathcal{P}}})$|⁠; assigns |$\mathsf{V_{succ}} = (\gamma _i,\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{10},\tau _1,\mathsf{pk_{\mathcal{T}}}(\mathsf{A}_{\mathcal{P}}))$|⁠, (⁠|$\tau _1$| is the verification timestamp). The signature is noted: |${\mathsf{V_{succ}}}^{*} = (\mathsf{V_{succ}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{succ}})))$|⁠; sends |$\mathsf{m}_{2}={\mathsf{V_{succ}}}^{*}$| to |$\mathcal{U}$|⁠; (b) if |$\exists \psi _{\gamma _i, 0}$| linked to |$\mathsf{PASS^*}$| in the database: assigns |$\mathsf{V_{fail}} = (\mathsf{PASS}.\mathsf{Sn},\psi _{ \gamma _i, 0},\mathsf{flag}_{02},\tau _1, \gamma _i)$|⁠.The signature is noted: |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$|⁠; sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$|⁠; indicating that this non-reusable ticket of the PASS had been already used. showProof|$\mathcal{U}$| executes: verifies |$P_{i}$|’s signature; |$\rightarrow $| if |${\mathsf{V_{fail}}}^{*}$| is received or |${\mathsf{V_{succ}}}^{*}$| is not correct: 2.. |$\mathcal{U}$| checks the appropriate |$\mathsf{flag}_{}$| to know the details of the error. If he does not agree then he can rise a CLAIM by contacting with |$\mathcal{T}$|⁠; |$\rightarrow $| else: calculates |$\mathsf{A}_{\mathcal{U}} = PRNG(\mathsf{K}) \oplus \psi _{\gamma _i, 0}$|⁠, using the shared value |$\mathsf{K}$| as seed; composes the message |$\mathsf{m}_{3}=(\mathsf{PASS}.\mathsf{Sn},\mathsf{A}_{\mathcal{U}})$|⁠; signs and sends it to |$P_{i}$|⁠: |${\mathsf{m}_{3}}^{*} = (\mathsf{m}_{3},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{m}_{3})))$|⁠. verifyProof|$P_{i}$| follows the next steps: obtains |$\mathsf{PASS}.\mathsf{Sn}$|⁠, and computes |$\psi _{\gamma _i,0} = \mathsf{A}_{\mathcal{U}} \oplus PRNG(\mathsf{K})$|⁠; verifies |$\psi _{\gamma _i,1} \stackrel{?}{=} hash(\psi _{\gamma _i,0})$|⁠; generates |$\tau _2$| and verifies it using the PASS expiry date |$(\mathsf{PASS}.\mathsf{PURdate},\mathsf{PASS}.\mathsf{EXPdate})$| and the timestamp |$\tau _1$|⁠, the value of |$\mathsf{ACTdate}$| of the element |$\mathsf{ACT}$| and |$\mathsf{LIMdate}$|⁠, being |$\mathsf{LIMdate}=\mathsf{ACTdate}+\mathsf{Lifetime}$|⁠; |$\rightarrow $| if any verification fails: assigns |$\mathsf{V_{fail}} = (\gamma _i,\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{03},\tau _2,\psi _{ \gamma _i, 0})$|⁠. signs |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$|⁠, sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$| |$\rightarrow $| else: 4 signs |$\mathsf{A}_{\mathcal{P}}$| approving then the validation with timestamp |$\tau _2$|⁠: |$\mathsf{R}_{\gamma _i} = (\mathsf{A}_{\mathcal{P}},\mathsf{PASS}.\mathsf{Sn},\tau _2)$|⁠, and |$\mathsf{R^*}_{\gamma _i} = (\mathsf{R}_{\gamma _i},\mathsf{sk_{\mathcal{P}}}(hash(\mathsf{R}_{\gamma _i})))$|⁠; 5 stores in its SpentCityPASSES database: (⁠|$\mathsf{PASS^*},\psi _{\gamma _i,0}$|⁠) and sends |$\mathsf{m}_{4}=\mathsf{R^*}_{\gamma _i}$| to |$\mathcal{U}$|⁠. getValidationConfirmation|$\mathcal{U}$| follows the next steps: |$\rightarrow $| if |${\mathsf{V_{fail}}}^{*}$| is received: |$\mathcal{U}$| checks |$\mathsf{flag}_{03}$| to know the details of the error. If he does not agree then he can rise a CLAIM by contacting with the |$\mathcal{T}$|⁠; |$\rightarrow $| else: checks the signature of |$\mathsf{R^*}_{\gamma _i}$|⁠; computes |$\mathsf{RI}_{\gamma _i} = \mathsf{A}_{\mathcal{P}} \oplus PRNG(\mathsf{h}_{\mathsf{K}})$|⁠; verifies |$\mathsf{h}_{\mathsf{RI}_{\gamma _i}} \stackrel{?}{=} hash(\mathsf{RI}_{\gamma _i})$|⁠; |$\rightarrow $| if any verification fails: |$\mathcal{U}$| collects all evidence and he can rise a CLAIM by contacting with the |$\mathcal{T}$|⁠, he can argue that there is an error in getting the authorization to use the service (Authorization Failure); |$\rightarrow $| else: stores in his TicketsPASS database |$(\mathsf{R^*}_{\gamma _i},\mathsf{RI}_{\gamma _i})$| together with |$\mathsf{PASS^*}$|⁠. The service provider |$\mathcal{P}$| and user |$\mathcal{U}$| follow these steps: showPASS|$\mathcal{U}$| computes: generates a random value |$a_{3}, \stackrel{R}{\rightarrow } \mathsf{Z}_q$| to be used in a Schnorr proof; computes |$A_{3} = {\alpha }^{a_{3}}\pmod p$|⁠; Case 1-First time use of a |$m$|-times reusable service:|$\mathcal{U}$| computes |$\psi _{\lambda _i,m-1} =hash^{m-1}(\psi _{\lambda _i,0})$|⁠. Then |$\mathcal{U}$| creates a counter |$k_{\lambda _i}=m-1$| to keep track of the number of times that the ticket can be used. The counter is stored in her CityPASS database; Case 2-Subsequent use of a |$m$|-times reusable service:|$\mathcal{U}$| retrieves |$k_{\lambda _i}$| from her TicketsPASS database and computes |$\psi _{\lambda _i,(k_{\lambda _i}-1)} =hash^{(k_{\lambda _i}-1)}(\psi _{\lambda _i,0})$|⁠. composes the information ticket message |$\mathsf{m}_{1}=(\mathsf{PASS^*}$|⁠, |$\mathsf{\mathsf{ACT}^*}$|⁠, |$A_{3}$|⁠, |$(k_{\lambda _i})$|⁠); signs and sends it to |$\mathcal{P}$|⁠: |${\mathsf{m}_{1}}^{*} = (\mathsf{m}_{1},\mathsf{sk_{\mathcal{P}}}_i(hash (\mathsf{m}_{1})))$|⁠. verifyPASS|$\mathcal{P}$| executes: verifies the PASS signature, |$\mathsf{PASS}.\mathsf{PURdate}$| and |$\mathsf{PASS}.\mathsf{EXPdate}$|⁠; verifies |$\mathsf{\mathsf{ACT}^*}$|⁠, and |$\mathsf{PASS}.\mathsf{ACTdate}$|⁠; |$\rightarrow $| if any verification fails: assigns |$\mathsf{V_{fail}} = (\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{00},\tau _1)$|⁠. signs |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$| and sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$| |$\rightarrow $| else: |$\mathcal{P}$| looks for the |$\mathsf{PASS^*}$| in its SpentCityPASSES database using |$\mathsf{PASS}.\mathsf{Sn}$|⁠; (a) if (⁠|$\not \exists \psi _{\lambda , k_{\lambda _i}}$| linked to |$\mathsf{PASS^*}$|⁠) or [(⁠|$\exists \psi _{\lambda , k_{\lambda _i}}$|⁠) and (⁠|$k_{\lambda _i} \geq 1 $|⁠) and (⁠|$k_{\lambda _i}$| stored in the |$\mathcal{P}$| database has the same value than the one sent by |$\mathcal{U}$|⁠)]: |$\mathcal{P}$| follows the next steps: generates a challenge |$\mathsf{c} \stackrel{R}{\rightarrow } \mathsf{Z}_q$|⁠; assigns |$Challenge = (\mathsf{PASS}.\mathsf{Sn},\mathsf{c},\tau _1)$|⁠; |${Challenge}^{*} = (Challenge,\mathsf{sk_{\mathcal{P}}}_i(hash(Challenge)))$|⁠, sends this signature to |$\mathcal{U}$|⁠; asynchronously pre-computes |${\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠. |$\mathcal{U}$| computes: computes |$\mathsf{w}_{3} = a_{3} + \mathsf{c} \cdot \mathsf{RU} \pmod q$|⁠; encrypts and signs |$\mathsf{w}_{3}$|⁠, sends it to |$\mathcal{P}$|⁠: |$\mathsf{sk}_{\mathcal{U}}(\mathsf{pk_{\mathcal{P}}}_{i}(\mathsf{PASS}.\mathsf{Sn}, \mathsf{w}_{3}, \tau _1))$|⁠. |$\mathcal{P}$| follows the next steps: computes |${\alpha }^{\mathsf{w}_{3}} \pmod p$|⁠; verifies |${\alpha }^{\mathsf{w}_{3}} \stackrel{?}{=} A_{3} \cdot{\mathsf{H}_{\mathcal{U}}}^{\mathsf{c}} \pmod p$|⁠; |$\rightarrow $|if verification fails: assigns |$\mathsf{V_{fail}} = (\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{01},\tau _1)$|⁠. signs |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$| and sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$| |$\rightarrow $|else: computes |$\mathsf{A}_{\mathcal{P}} = PRNG(\mathsf{h}_{\mathsf{K}}) \oplus \mathsf{RI}_{\lambda _i}$|⁠, |$PRNG(\mathsf{h}_{\mathsf{K}})$| is a secure pseudorandom number generator and, |$\mathsf{h}_{\mathsf{K}} = hash(\mathsf{K})$| is the seed. |$\mathsf{K}$| and |$\mathsf{RI}_{\lambda _i}$| are obtained from |$\delta _{\mathcal{T},\mathcal{P}}$|⁠; encrypts |$\mathsf{A}_{\mathcal{P}}$| with the public key of the TTP |$\mathcal{T}$|⁠: |$\mathsf{pk_{\mathcal{T}}}({\mathsf{A}_{\mathcal{P}}})$|⁠; assigns |$\mathsf{V_{succ}} = (\lambda _i,\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{10},\tau _1,\mathsf{pk_{\mathcal{T}}}(\mathsf{A}_{\mathcal{P}}), k_{\lambda _i}, \psi _{(\lambda , k_{\lambda _i})})$|⁠. The signature is noted: |${\mathsf{V_{succ}}}^{*} = (\mathsf{V_{succ}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{succ}})))$|⁠; sends |$\mathsf{m}_{2}={\mathsf{V_{succ}}}^{*}$| to |$\mathcal{U}$|⁠; assigns |$\mathsf{V_{fail}} = (\lambda _i, \mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{04},\tau _1,k_{\lambda _i},\psi _{(\lambda , k_{\lambda _i})})$|⁠. The signature is noted: |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}(hash(\mathsf{V_{fail}})))$|⁠; sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$|⁠. showProof|$\mathcal{U}$| executes: verifies |$\mathcal{P}$|’s signature; |$\rightarrow $| if |${\mathsf{V_{fail}}}^{*}$| is received or |${\mathsf{V_{succ}}}^{*}$| is not correct: |$\mathcal{U}$| checks the appropriate |$\mathsf{flag}_{}$| to know the details of the error. If she does not agree then she can rise a CLAIM by contacting with |$\mathcal{T}$|⁠; |$\rightarrow $| else: calculates |$\mathsf{A}_{\mathcal{U}} = PRNG(\mathsf{K}) \oplus \psi _{\lambda , (k_{\lambda _i}-1)}$|⁠, using the shared value |$\mathsf{K}$| as seed; compose the message |$\mathsf{m}_{3}=(\mathsf{PASS}.\mathsf{Sn},\mathsf{A}_{\mathcal{U}})$|⁠; signs and sends it to |$P_{i}$|⁠: |${\mathsf{m}_{3}}^{*} = (\mathsf{m}_{3},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{m}_{3})))$|⁠. verifyProof|$\mathcal{P}$| follows the next steps: obtains |$\mathsf{PASS}.\mathsf{Sn}$| and computes |$\psi _{\lambda , (k_{\lambda _i}-1)} = \mathsf{A}_{\mathcal{U}} \oplus PRNG(\mathsf{K})$|⁠; checks |$\psi _{\lambda , (k_{\lambda _i})} \stackrel{?}{=} hash(\psi _{\lambda , (k_{\lambda _i}-1)})$|⁠; generates |$\tau _2$|⁠, verifies it using PASS expiry date |$(\mathsf{PASS}.\mathsf{PURdate},$||$\mathsf{PASS}.\mathsf{EXPdate})$| and timestamp |$\tau _1$|⁠; |$\rightarrow $| if any verification fails: assigns |$\mathsf{V_{fail}} = (\lambda _i,\mathsf{PASS}.\mathsf{Sn},\mathsf{flag}_{05},\tau _2,\psi _{\lambda , (k_{\lambda _i}-1)}, (k_{\lambda _i}-1))$|⁠; signs |${\mathsf{V_{fail}}}^{*} = (\mathsf{V_{fail}},\mathsf{sk_{\mathcal{P}}}_i(hash(\mathsf{V_{fail}})))$|⁠, sends |${\mathsf{m}_{2}}={\mathsf{V_{fail}}}^{*}$| to |$\mathcal{U}$| |$\rightarrow $| else: signs |$\mathsf{A}_{\mathcal{P}}$| approving the validation with timestamp |$\tau _2$|⁠: |$\mathsf{R}_{\lambda _i} = (\mathsf{A}_{\mathcal{P}},\mathsf{PASS}.\mathsf{Sn},\tau _2)$|⁠, |$\mathsf{R^*}_{\lambda _i} = (\mathsf{R}_{\lambda _i},\mathsf{sk_{\mathcal{P}}}(hash(\mathsf{R}_{\lambda _i})))$|⁠; stores in the SpentCityPASSES database: (⁠|$\mathsf{PASS^*},\psi _{\lambda ,(k_{\lambda _i}-1)}$|⁠); updates the value of |$k_{\lambda _i}=(k_{\lambda _i}-1)$| and stored it with the ticket information; sends |$\mathsf{m}_{4}=\mathsf{R^*}_{\lambda _i}$| to |$\mathcal{U}$|⁠. getValidationConfirmation|$\mathcal{U}$| follows the next steps: |$\rightarrow $| if |${\mathsf{V_{fail}}}^{*}$| is received: |$\mathcal{U}$| checks |$\mathsf{flag}_{}$| to know the details the error. If she does not agree then she can rise a CLAIM by contacting with the |$\mathcal{T}$|⁠; |$\rightarrow $| else: checks the signature of |$\mathsf{R^*}_{\lambda _i}$|⁠; computes |$\mathsf{RI}_{\lambda _i} = \mathsf{A}_{\mathcal{P}} \oplus PRNG(\mathsf{h}_{\mathsf{K}})$|⁠; verifies |$\mathsf{h}_{\mathsf{RI}_{\lambda _i}} \stackrel{?}{=} hash(\mathsf{RI}_{\lambda _i})$|⁠; |$\rightarrow $| if any verification fails: |$\mathcal{U}$| collects evidence and she can rise a CLAIM contacting with |$\mathcal{T}$|⁠; |$\rightarrow $| else: stores in her TicketsPASS database |$(\mathsf{R^*}_{\lambda _i},\mathsf{RI}_{\lambda _i})$| together with |$\mathsf{PASS^*}$| and |$k_{\lambda _i}=(k_{\lambda _i}-1)$|⁠. Verification of an infinitely reusable service |$\xi _i$|: service provider |$P_{i}$| and user |$\mathcal{U}$| follow a verification phase similar to the verification of a non-reusable service. In this case, however, if the user presents a valid |$\mathsf{R^*}_{\xi }$| and the current date is lower than |$\mathsf{LIMdate}$|⁠, the service can be used again. APPENDIX B: Statistical Analysis of Results Open in new tab Open in new tab Open in new tab Open in new tab © The British Computer Society 2019. All rights reserved. For permissions, please e-mail: journals.permissions@oup.com This article is published and distributed under the terms of the Oxford University Press, Standard Journals Publication Model (https://academic.oup.com/journals/pages/open_access/funder_policies/chorus/standard_publication_model)
TI - Implementation And Evaluation Of The mCityPASS Protocol For Secure And Private Access To Associated Touristic Services
JO - The Computer Journal
DO - 10.1093/comjnl/bxz126
DA - 2010-05-01
UR - https://www.deepdyve.com/lp/oxford-university-press/implementation-and-evaluation-of-the-mcitypass-protocol-for-secure-and-K0bkqNOCqT
SP - 1
VL - Advance Article
IS - 
DP - DeepDyve
ER -