# Transferable, Auditable and Anonymous Ticketing Protocol

Pascal Lafourcade, Dhekra Mahmoud, Gael Marcadet, Charles Olivier-Anclin

► To cite this version:

Pascal Lafourcade, Dhekra Mahmoud, Gael Marcadet, Charles Olivier-Anclin. Transferable, Auditable and Anonymous Ticketing Protocol. Asia Conference on Information, Computer and Communications Security, Jul 2024, Singapore, Singapore. http://dx.doi.org/10.14701/asia.2024.5493

HAL Id: hal-04615493

https://uca.hal.science/hal-04615493

Submitted on 18 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
# Transferable, Auditable and Anonymous Ticketing Protocol

Pascal Lafourcade, Dhekra Mahmoud, Gael Marcadet, Charles Olivier-Anclin

► To cite this version:

Pascal Lafourcade, Dhekra Mahmoud, Gael Marcadet, Charles Olivier-Anclin. Transferable, Auditable and Anonymous Ticketing Protocol. 2024 Asia Conference on Information, Computer and Communications Security, Jul 2024, Singapore, Singapore. hal-04615493

HAL Id: hal-04615493

https://uca.hal.science/hal-04615493v1

Submitted on 18 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Transferable, Auditable and Anonymous Ticketing Protocol

Pascal Lafourcade

Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS
Clermont-Ferrand, France

Gael Marcadet

Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS
Clermont-Ferrand, France

Dhekra Mahmoud

Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS
Clermont-Ferrand, France

Charles Olivier-Anclin

beys Pay and Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS and LIFO, Université
d'Orléans, INSA Centre Val de Loire
Clermont-Ferrand and Bourges, France

## ABSTRACT

Digital ticketing systems typically offer ticket purchase, refund, validation, and, optionally, anonymity of users. However, it would be interesting for users to transfer their tickets, as is currently done with physical tickets. We propose Applause, a ticketing system allowing the purchase, refund, validation, and transfer of tickets based on trusted authority, while guaranteeing the anonymity of users, as long as the used payment method provides anonymity. To study its security, we formalise the security of the transferable E-Ticket scheme in the game-based paradigm. We prove the security of Applause computationally in the standard model and symbolically using the protocol verifier ProVerif. Applause relies on standard cryptographic primitives, rendering our construction efficient and scalable, as shown by a proof-of-concept. In order to obtain Spotlight, an auditable version, proved to be secure, users will remain anonymous except for a trusted third party, which will be able to disclose their identity in the event of a disaster.

## CCS CONCEPTS

* Security and privacy → Privacy-preserving protocols.

## KEYWORDS

Ticketing System, Protocol, Auditability, Anonymity, Transfer

### ACM Reference Format:

Pascal Lafourcade, Dhekra Mahmoud, Gael Marcadet, and Charles Olivier-Anclin. 2018. Transferable, Auditable and Anonymous Ticketing Protocol. In *Proceedings of ACM Conference (Conference’17)*. ACM, New York, NY, USA, 17 pages. https://doi.org/XXXXXXX.XXXXXXX

## 1 INTRODUCTION

Electronic tickets (*E-Ticket*) have become the standard. The ratio-
nale behind the digitization of the ticket industry is both practical
and economical. More sales can be achieved by allowing users to

purchase tickets from anywhere. The practical aspect of ticket digi-
tization entails significant drawbacks, resulting in a negative impact
on the second-hand market and the protection of users' privacy.
In a world where privacy is a central concern, it is essential to
preserve the multiple facets of a paper ticket, such as the right to
trade them, and ensure full confidence in their validity. However,
the original property of non-replicable paper tickets is often lost
with the development of E-Tickets. A formal security model for
electronic ticketing is needed to ensure their security, and a system
that combines the best properties of both worlds is necessary.

The research has focused on multiple cryptographic technolo-
gies with properties similar to their physical counterparts. The
subject of e-cash [3, 4, 49], e-coupon [10, 32, 38] (e-coupon are
similar to e-cash with items chosen when redeeming an e-coupon
remains unknown to the service provider) or n-times anonymous
authentication [48, 7] appears to be closely associated with our
issue. Even though they have been studied in the literature, their
design makes them incompatible with being used as a ticketing
system. In numerous electronic cash systems [3, 4, 49], the practice
of double-spending, wherein a coin is spent twice, is mitigated by
a central bank that maintains a record of the spent coins. When
receiving a coin from a merchant, the bank checks to ensure that
it does not belong to the list of spent coins. Therefore, the bank is
able to detect if a coin has been double-spent, and can compensate
the scammed merchant. This mechanism, however, is not suitable
to construct a desirable ticketing system, since a scam would be
left undetected by a second merchant accepting the same coin until
they both reach the bank. This fraud can be generalised to transfer
of coins in transferable e-cash. Putting it in different terms, cheaters
could resell twice a ticket and this would be left undetected un-
til they try to access the event. On the other hand, in e-coupon
systems [10, 32, 38], the transfer may appear unfavorable or even
atypical, as a coupon has been issued by a merchant to a specific
customer with the intention of gaining their loyalty, whereas n-
times anonymous authentication [48], cannot be safely transferred.
With e-tickets, it is imperative to guarantee the validity of a ticket
at any time in order to avoid double-spent tickets. This primary
concern renders every electronic cash system that prevents double-
spending at coin deposit irrelevant to our issue. Additionally, a coin
is validated by the bank during the deposit process in e-cash [4]. In
the case of e-ticketing, a ticket can be validated by one of the many
terminals. All of these disparities substantiate the necessity for a
specific approach to electronic ticketing. E-ticketing systems have

<footnote>Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.</footnote>

<footnote>Conference'17, July 2017, Washington, DC, USA</footnote>
# Transferable, Editable and Anonymous Ticketing Protocol

Pascal Lafourcade

Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS
Clermont-Ferrand, France

Gael Marcadet

Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS
Clermont-Ferrand, France

Dhekra Mahmoud

Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS
Clermont-Ferrand, France

Charles Olivier-Anclin

beys Pay and Université Clermont-Auvergne, CNRS,
Clermont-Auvergne-INP, LIMOS and LIFO, Université
d'Orléans, INSA Centre Val de Loire
Clermont-Ferrand and Bourges, France

## ABSTRACT

Digital ticketing systems typically offer ticket purchase, refund, validation, and, optionally, anonymity of users. However, it would be interesting for users to transfer their tickets, as is currently done with physical tickets. We propose Applause, a ticketing system allowing the purchase, refund, validation, and transfer of tickets based on trusted authority, while guaranteeing the anonymity of users, as long as the used payment method provides anonymity. To study its security, we formalise the security of the transferable E-Ticket scheme in the game-based paradigm. We prove the security of Applause computationally in the standard model and symbolically using the protocol verifier ProVerif. Applause relies on standard cryptographic primitives, rendering our construction efficient and scalable, as shown by a proof-of-concept. In order to obtain Spotlight, an auditable version, proved to be secure, users will remain anonymous except for a trusted third party, which will be able to disclose their identity in the event of a disaster.

## CCS CONCEPTS

* Security and privacy → Privacy-preserving protocols.

## KEYWORDS

Ticketing System, Protocol, Auditability, Anonymity, Transfer

### ACM Reference Format:

Pascal Lafourcade, Dhekra Mahmoud, Gael Marcadet, and Charles Olivier-Anclin. 2018. Transferable, Editable and Anonymous Ticketing Protocol. In *Proceedings of ACM Conference (Conference’17)*. ACM, New York, NY, USA, 17 pages. https://doi.org/XXXXXXX.XXXXXXX

## 1 INTRODUCTION

Electronic tickets (*E-Ticket*) have become the standard. The ratio-
nale behind the digitization of the ticket industry is both practical
and economical. More sales can be achieved by allowing users to

purchase tickets from anywhere. The practical aspect of ticket digi-
tization entails significant drawbacks, resulting in a negative impact
on the second-hand market and the protection of users' privacy.
In a world where privacy is a central concern, it is essential to
preserve the multiple facets of a paper ticket, such as the right to
trade them, and ensure full confidence in their validity. However,
the original property of non-replicable paper tickets is often lost
with the development of E-Tickets. A formal security model for
electronic ticketing is needed to ensure their security, and a system
that combines the best properties of both worlds is necessary.

The research has focused on multiple cryptographic technolo-
gies with properties similar to their physical counterparts. The
subject of e-cash [3, 4, 49], e-coupon [10, 32, 38] (e-coupon are
similar to e-cash with items chosen when redeeming an e-coupon
remains unknown to the service provider) or n-times anonymous
authentication [48, 7] appears to be closely associated with our
issue. Even though they have been studied in the literature, their
design makes them incompatible with being used as a ticketing
system. In numerous electronic cash systems [3, 4, 49], the practice
of double-spending, wherein a coin is spent twice, is mitigated by
a central bank that maintains a record of the spent coins. When
receiving a coin from a merchant, the bank checks to ensure that
it does not belong to the list of spent coins. Therefore, the bank is
able to detect if a coin has been double-spent, and can compensate
the scammed merchant. This mechanism, however, is not suitable
to construct a desirable ticketing system, since a scam would be
left undetected by a second merchant accepting the same coin until
they both reach the bank. This fraud can be generalised to transfer
of coins in transferable e-cash. Putting it in different terms, cheaters
could resell twice a ticket and this would be left undetected un-
til they try to access the event. On the other hand, in e-coupon
systems [10, 32, 38], the transfer may appear unfavorable or even
atypical, as a coupon has been issued by a merchant to a specific
customer with the intention of gaining their loyalty, whereas n-
times anonymous authentication [48], cannot be safely transferred.
With e-tickets, it is imperative to guarantee the validity of a ticket
at any time in order to avoid double-spent tickets. This primary
concern renders every electronic cash system that prevents double-
spending at coin deposit irrelevant to our issue. Additionally, a coin
is validated by the bank during the deposit process in e-cash [4]. In
the case of e-ticketing, a ticket can be validated by one of the many
terminals. All of these disparities substantiate the necessity for a
specific approach to electronic ticketing. E-ticketing systems have

<footnote>Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than ACM
must be honored. Abstracting with credit is permitted. To copy otherwise, or republish,
to post on servers or to redistribute to lists, requires prior specific permission and/or a
fee. Request permissions from permissions@acm.org.</footnote>

<footnote>Conference'17, July 2017, Washington, DC, USA</footnote>
been studied both in the industry [2, 42] for practical purposes and
in academia for understanding social behaviors regarding ticket
resale and the incentives behind this process [29, 12]. The majority
of the present ticketing systems that have been developed by the
industry are centered on the “standard” functionality of electronic
tickets, which entails the provision and validation of tickets. These
systems are not designed to ensure secure ticket transfer. Hence, an
honest client has high chances of buying a duplicated ticket from a
malicious user. More advanced systems, attempting to address this
issue, provide authentication via a distributed architecture, such as
the blockchain [2, 42]. Even if ticket validity is now ensured dur-
ing a transfer (by checking if the ticket is valid in the blockchain),
it moves away from the current e-ticketing system organization
where the tickets are stored in a database. These methods however,
are in opposition to the currently centralized event organization
and implies a larger energy consumption [13, 46]. Users’ anonymity
in e-ticketing systems has not been considered in the latest pro-
tocols [2, 24, 37, 42]. Nevertheless, anonymity is guaranteed by
physical tickets, and it remains crucial to prevent the event or-
ganizers from collecting the identity of ticket purchasers unless
necessary. Blockchain-based solutions can serve this purpose [2,
42], but for the aforementioned argumentation, we exclude them
from our investigation.

**Contribution.** Considering the above problems and the lack of existing formalism, we design an e-ticket scheme with proven security. It features three central aspects as it is *centralised, transferable and anonymous*, with the latter property that can be mitigated by *auditable* feature at need. We discuss the requirements of such a protocol, its capabilities, and limitations, and encompass it in a model. We introduce the first security model for *E-Ticket Scheme* (ETS). The security is formalised through five experiments, modeling *unforgeability, ticket privacy, anonymity of users*, split in two experiments, and *no-double-spending*, preventing to execute a refund, transfer or validate twice with the same ticket.

Our *provably secure E-Ticket* scheme is called Applause. It allows users to purchase, refund, validate tickets, but also transfer their tickets to another user. During all the interactions, depicted in Fig. 1, users’ anonymity from the event organiser point-of-view is ensured. We propose a protocol addressing all the above-mentioned properties. Its security is proven based on computational proofs, both in the random oracle and standard model. Moreover, we have used the protocol verifier tool ProVerif [6] to provide more security guarantees, see Fig. 2 for a description of ensured properties.

Payments can be made during at least three steps of our process: the purchase, the refund, and the transfer of tickets. Traditional payment does not guarantee anonymity, therefore, using it in our construction would trivially break the anonymity of users. For instance, the most standard payment protocol EMV [17] does not protect privacy. In our protocol, the payment is modelled as a generic cryptographic building block, requiring anonymity, a mandatory assumption only required to ensure full anonymity. More precisely, our protocol is as anonymous as the payment method in use. We stress that it is not specific for our protocol but can be applied for every protocol ensuring anonymity and involving payment. Alternative payment protocols that guarantee anonymity of users exist,

ranging from simple anonymous payment method [40] to more ad-
vanced constructions [15, 33], can be used in our protocol. To reveal
the identity of users, reaching *auditability*, we present Spotlight,
an extended version of Applause, where the identity of *every* users
can be revealed *only* by a third-party called the judge, employing
certificates that can be randomised along with the certified keys.

**Related Work.** Most of the production-ready deployed systems guarantee the “standard” functionality of ticket payment and delivery. Our system provides users with the ability to transfer a ticket to another user, while maintaining anonymity, in addition to the standard functionalities. All existing systems that allow for additional functionalities that we identify rely on blockchains [2, 42]. Blockchain-based ticketing systems can easily achieve transfer of a ticket by checking if the ticket is still valid on the blockchain, and can achieve anonymity by the design of the blockchain. However, the blockchain requires the upkeep of a distributed ledger and numerous signatures, which means that numerous servers are needed to safeguard the validity of the network. Low-consumption and optimised computation has been a keystone of cryptography. As shown in [13, 46], blockchains are more computationally demanding than centralised design, but also require large-scale procedures. Our system is centralised to enhance efficiency and align with the existing topology of event organization.

Previous works, initiated by [30] in 2001 and followed up by a
number of papers, essentially evaluating either the practicality [26],
the interface design [50] or the security [47] of existing systems in
the public transport. Subsequent works have proposed a novel tick-
eting system. They can be divided into three categories. The first
category focuses on the design of a ticketing system [24, 37], ensur-
ing the validity of a ticket, without considering privacy. The second
category aims to guarantee the privacy of the user, however it does
not permit transfer or auditability. In [28], they study the possibility
of a ticketing system with privacy of users, including the billing
step. The authors of [22, 23] have studied the possibility of using
RFID and NFC while ensuring privacy of users, using unlinkable
certified tokens [35] for public transport ticketing or anonymous
credentials [25] for general purposes tickets. Furthermore, con-
struction of [25] takes a few seconds whereas a full execution of
our constructions requires at most 100 milliseconds and does not
directly scale with the number of emitted tickets. Unlike [25], we
include the payment process in the protocol as well. The third line
of research proposes ticketing systems based on a distributed ledger,
which are less efficient compared to a centralised setting, due to
the number of involved servers and communication time. The first
paper to propose such a system is presented in [31], which is based
on blockchain. Recently, a new ticketing system has been proposed
in [51] based on NFT. For practical and efficiency reasons depicted
above, our work moves away from the distributed approach.

This work is compared to publications in less specialized areas,
such as *E-cash* [3, 4, 49] and *e-coupon* [10, 32, 38], in which a trusted
authority generates tokens attached to a value. Due to double-
spending enforcement checked only by the bank, followed by a
compensation process, they miss the guarantees of ticket validity
upon transfer. On the other hand, *n-times anonymous authentica-
tion* [48, 7] allows a limited number of authentications before leaking
user's identity, limiting the ticket purchasing, as well as the interest
been studied both in the industry [2, 42] for practical purposes and
in academia for understanding social behaviors regarding ticket
resale and the incentives behind this process [29, 12]. The majority
of the present ticketing systems that have been developed by the
industry are centered on the “standard” functionality of electronic
tickets, which entails the provision and validation of tickets. These
systems are not designed to ensure secure ticket transfer. Hence, an
honest client has high chances of buying a duplicated ticket from a
malicious user. More advanced systems, attempting to address this
issue, provide authentication via a distributed architecture, such as
the blockchain [2, 42]. Even if ticket validity is now ensured dur-
ing a transfer (by checking if the ticket is valid in the blockchain),
it moves away from the current e-ticketing system organization
where the tickets are stored in a database. These methods however,
are in opposition to the currently centralized event organization
and implies a larger energy consumption [13, 46]. Users’ anonymity
in e-ticketing systems has not been considered in the latest pro-
tocols [2, 24, 37, 42]. Nevertheless, anonymity is guaranteed by
physical tickets, and it remains crucial to prevent the event or-
ganizers from collecting the identity of ticket purchasers unless
necessary. Blockchain-based solutions can serve this purpose [2,
42], but for the aforementioned argumentation, we exclude them
from our investigation.

**Contribution.** Considering the above problems and the lack of existing formalism, we design an e-ticket scheme with proven security. It features three central aspects as it is *centralised, transferable and anonymous*, with the latter property that can be mitigated by *auditable* feature at need. We discuss the requirements of such a protocol, its capabilities, and limitations, and encompass it in a model. We introduce the first security model for *E-Ticket Scheme* (ETS). The security is formalised through five experiments, modeling *unforgeability, ticket privacy, anonymity of users*, split in two experiments, and *no-double-spending*, preventing to execute a refund, transfer or validate twice with the same ticket.

Our *provably secure E-Ticket* scheme is called Applause. It allows users to purchase, refund, validate tickets, but also transfer their tickets to another user. During all the interactions, depicted in Fig. 1, users’ anonymity from the event organiser point-of-view is ensured. We propose a protocol addressing all the above-mentioned properties. Its security is proven based on computational proofs, both in the random oracle and standard model. Moreover, we have used the protocol verifier tool ProVerif [6] to provide more security guarantees, see Fig. 2 for a description of ensured properties.

Payments can be made during at least three steps of our process: the purchase, the refund, and the transfer of tickets. Traditional payment does not guarantee anonymity, therefore, using it in our construction would trivially break the anonymity of users. For instance, the most standard payment protocol EMV [17] does not protect privacy. In our protocol, the payment is modelled as a generic cryptographic building block, requiring anonymity, a mandatory assumption only required to ensure full anonymity. More precisely, our protocol is as anonymous as the payment method in use. We stress that it is not specific for our protocol but can be applied for every protocol ensuring anonymity and involving payment. Alternative payment protocols that guarantee anonymity of users exist,

ranging from simple anonymous payment method [40] to more ad-
vanced constructions [15, 33], can be used in our protocol. To reveal
the identity of users, reaching *auditability*, we present Spotlight,
an extended version of Applause, where the identity of *every* users
can be revealed *only* by a third-party called the judge, employing
certificates that can be randomised along with the certified keys.

**Related Work.** Most of the production-ready deployed systems guarantee the “standard” functionality of ticket payment and delivery. Our system provides users with the ability to transfer a ticket to another user, while maintaining anonymity, in addition to the standard functionalities. All existing systems that allow for additional functionalities that we identify rely on blockchains [2, 42]. Blockchain-based ticketing systems can easily achieve transfer of a ticket by checking if the ticket is still valid on the blockchain, and can achieve anonymity by the design of the blockchain. However, the blockchain requires the upkeep of a distributed ledger and numerous signatures, which means that numerous servers are needed to safeguard the validity of the network. Low-consumption and optimised computation has been a keystone of cryptography. As shown in [13, 46], blockchains are more computationally demanding than centralised design, but also require large-scale procedures. Our system is centralised to enhance efficiency and align with the existing topology of event organization.

Previous works, initiated by [30] in 2001 and followed up by a
number of papers, essentially evaluating either the practicality [26],
the interface design [50] or the security [47] of existing systems in
the public transport. Subsequent works have proposed a novel tick-
eting system. They can be divided into three categories. The first
category focuses on the design of a ticketing system [24, 37], ensur-
ing the validity of a ticket, without considering privacy. The second
category aims to guarantee the privacy of the user, however it does
not permit transfer or auditability. In [28], they study the possibility
of a ticketing system with privacy of users, including the billing
step. The authors of [22, 23] have studied the possibility of using
RFID and NFC while ensuring privacy of users, using unlinkable
certified tokens [35] for public transport ticketing or anonymous
credentials [25] for general purposes tickets. Furthermore, con-
struction of [25] takes a few seconds whereas a full execution of
our constructions requires at most 100 milliseconds and does not
directly scale with the number of emitted tickets. Unlike [25], we
include the payment process in the protocol as well. The third line
of research proposes ticketing systems based on a distributed ledger,
which are less efficient compared to a centralised setting, due to
the number of involved servers and communication time. The first
paper to propose such a system is presented in [31], which is based
on blockchain. Recently, a new ticketing system has been proposed
in [51] based on NFT. For practical and efficiency reasons depicted
above, our work moves away from the distributed approach.

This work is compared to publications in less specialized areas,
such as *E-cash* [3, 4, 49] and *e-coupon* [10, 32, 38], in which a trusted
authority generates tokens attached to a value. Due to double-
spending enforcement checked only by the bank, followed by a
compensation process, they miss the guarantees of ticket validity
upon transfer. On the other hand, *n-times anonymous authentica-
tion* [48, 7] allows a limited number of authentications before leaking
user's identity, limiting the ticket purchasing, as well as the interest
of this approach for ticketing. In [7], restrictions of the concept
are augmented by time frames that further limit the authentication
process, yet it falls short in ensuring transfer guarantees.

Considerations could also be given to *Anonymous Credentials* [9,
11, 36] or *Attribute-Based Signatures* [5, 34]. These mechanisms are
dedicated for authentication based on predicate matching, identify-
ing information about the signer. Yet again, transferability remains
unaddressed as a standalone aspect in this particular work.

## 2 ELECTRONIC TICKETS SYSTEMS

We move away from the decentralised approach used in previous
work to focus on the currently used and centralised architecture.
Our system divides the ticket handling into three phases and can
be increased with a judges for auditability.

**Architecture.** A user **U** willing to purchase a ticket for an event, contacts the ticket distributor **D**, which issues a ticket tk to **U** in exchange of a payment. Once **U** holds a ticket, it can authenticate itself to a **validator** terminal **V** in order to get access to the designated event. In some cases, an user **U**₁ holding a ticket might not be able to benefit from its purchase, in such cases our protocol offers two options: a refund, or a transfer of its ticket to another user e.g., to **U**₂. The refund is proceeded between user **U**₁ and the ticket distributor **D**. The transfer scenario encompasses both the cases where **U**₁ sells its ticket to another user **U**₂ or offers it. The latter consisting of the same transfer protocol without the payments. The ticket transfer is modeled as an interaction between **U**₁, **U**₂, and a transfer authority **T** acting as a guaranty of the exchange. **T** ensures the validity of the ticket to **U**₂, prevents **U**₁ to resell a ticket for profit by controlling the price, but also prevents **U**₂ to obtain a ticket without paying it. While ticket sale is a fairly straightforward process, its transfer can be achieved through multiple scenarios. It has been shown in [19] that a fair transfer between two users is impossible without a third party. Also see Appendix B for further considerations.

Note that the transfer authority $\mathcal{T}$ has been modeled as an in-
dependent entity but can be combined with the ticket distributor
into a single entity without any loss of security. To make the desig-
nation of the ticket receiver possible, we assume a communication
between $\mathcal{U}_1$ and $\mathcal{U}_2$ before the transfer of the ticket, allowing them
to exchange keys. Last, to attend to an event, $\mathcal{U}$ has to validate
a ticket against a validator $\mathcal{V}$ through an anonymous validation.
At any time during the process, the *Judge* $\mathcal{J}$ can open a tickets to
recover the associated user's identity.

**Anonymity and Auditability.** Anonymity of users is ensured during every interaction with the system (i.e., the ticket distributor $\mathcal{D}$, the transfer authority $\mathcal{T}$ and the validator $\mathcal{V}$) and all over the process. During the protocol, either authentication is not required or users authenticate themselves using randomised identities i.e., randomised keys. If desired, our protocol Applause can be turned into an auditable version called Spotlight, where an external authority refers as the *judge* denoted $\mathcal{J}$, recovers the identity of $\mathcal{U}$. The auditability setting remains consistent with the one presented for *Auditable Anonymous Credentials* in [11]. In a nutshell, $\mathcal{U}$ provides a certificate attesting the validity of its randomised key to $\mathcal{D}$, $\mathcal{T}$ or $\mathcal{V}$. Given such a certificate, kept on a record, $\mathcal{J}$ retrieves the

original key, hence the identity of $\mathcal{U}$. The anonymity still holds
against $\mathcal{D}$, $\mathcal{T}$ or $\mathcal{V}$ as the certificate is randomised with the keys. If
the judge is compromised, only the users' anonymity would be at
risk. The tickets remain valid, ensuring that honest individuals can
utilize their tickets without any issues. A compromised judge $\mathcal{J}$
would not have the capability to forge new tickets or alter the valid-
ity status of previously issued tickets. The purpose of auditability is
not to prevent double spending, but rather to fulfill legal mandates
concerning participant identity recovery. This aspect is crucial in
unforeseen circumstances such as force majeure or disasters.

**Validation Setting.** Large scale events often result in an over-
loaded network due to the number of attendees. Multiple terminals
are needed to validate the tickets simultaneously. Hence, commu-
nications coming to and from the validation terminals are limited
in size and number. One would like to assume that the validator is
offline after an initial setup. As a single ticket should be valid for
any terminal, and without communication between the terminals,
the same ticket could be accepted for each of them, constituting
a forgery for any ticketing system. Hence, the validators must be
online and communicate. In our case, only a single group element
needs to be sent between a terminal and the central server for each
approved verification. For efficiency, we rely on a central authority
instead of a distributed ledger to agree on valid tickets at time $t$.
A validation protocol has to ensure anonymity of users, and thus
cannot authenticate the user. However, an adversary able to relay
all communications between a legitimate user and a validator, can
easily perform what is called a *relay attack* [43], where the adver-
sary can have the access granted without paying a ticket, by simply
blocking and sending all messages sent by a legitimate user to the
validator, in its own name. As a result, the validator grants the
access to the adversary instead of the legitimate user. Badly, neither
the user or the validator can notice this attack. To prevent this
issue, we have chosen to construct a validation protocol based on
a physical channel (such as QRcode [27] scanned by the validator
or Bluetooth's password shared verbally [39]) during the last step
of the protocol to prevent relay attacks by an adversary. $\mathcal{U}$ gets a
token, compared through this channel to the token sent by $\mathcal{V}$.

3 E-TICKET SCHEME MODEL

Most ticketing systems are designed to allow the sale of a seat at an
event, with each seat being associated with a metadata such as the
seat number. This can be more general, and we consider a scenario
where tickets are characterised by an *event identifier* ide ∈ ID<sub>E</sub> ⊂ N
and by a *serial number* idp ∈ ID<sub>P</sub> ⊂ N. The set of identifiers and
the set of serial numbers referred to event and seat number, and
are assumed publicly known. Below we define an *E-Ticket Scheme*
based on a security parameter 1<sup>λ</sup>. Note that through this paper,
all algorithms are assumed to run in probabilistic polynomial-time
(PPT). By *A*<sup>O</sup>, we denote the adversary having access to a set of
oracles *O*. By P⟨E<sub>1</sub>(i<sub>1</sub>), ..., E<sub>n</sub>(i<sub>n</sub>)⟩ → E<sub>1</sub>(o<sub>1</sub>), ..., E<sub>n</sub>(o<sub>n</sub>); we denote
the protocol P played between parties E<sub>j</sub>, taking as input i<sub>j</sub> and
outputting o<sub>j</sub>. For simplicity, we may omit a party in the output
part of the notation if the party does not produce output..
of this approach for ticketing. In [7], restrictions of the concept
are augmented by time frames that further limit the authentication
process, yet it falls short in ensuring transfer guarantees.

Considerations could also be given to *Anonymous Credentials* [9,
11, 36] or *Attribute-Based Signatures* [5, 34]. These mechanisms are
dedicated for authentication based on predicate matching, identify-
ing information about the signer. Yet again, transferability remains
unaddressed as a standalone aspect in this particular work.

## 2 ELECTRONIC TICKETS SYSTEMS

We move away from the decentralised approach used in previous
work to focus on the currently used and centralised architecture.
Our system divides the ticket handling into three phases and can
be increased with a judges for auditability.

**Architecture.** A user **U** willing to purchase a ticket for an event, contacts the ticket distributor **D**, which issues a ticket tk to **U** in exchange of a payment. Once **U** holds a ticket, it can authenticate itself to a **validator** terminal **V** in order to get access to the designated event. In some cases, an user **U**₁ holding a ticket might not be able to benefit from its purchase, in such cases our protocol offers two options: a refund, or a transfer of its ticket to another user e.g., to **U**₂. The refund is proceeded between user **U**₁ and the ticket distributor **D**. The transfer scenario encompasses both the cases where **U**₁ sells its ticket to another user **U**₂ or offers it. The latter consisting of the same transfer protocol without the payments. The ticket transfer is modeled as an interaction between **U**₁, **U**₂, and a transfer authority **T** acting as a guaranty of the exchange. **T** ensures the validity of the ticket to **U**₂, prevents **U**₁ to resell a ticket for profit by controlling the price, but also prevents **U**₂ to obtain a ticket without paying it. While ticket sale is a fairly straightforward process, its transfer can be achieved through multiple scenarios. It has been shown in [19] that a fair transfer between two users is impossible without a third party. Also see Appendix B for further considerations.

Note that the transfer authority $\mathcal{T}$ has been modeled as an in-
dependent entity but can be combined with the ticket distributor
into a single entity without any loss of security. To make the desig-
nation of the ticket receiver possible, we assume a communication
between $\mathcal{U}_1$ and $\mathcal{U}_2$ before the transfer of the ticket, allowing them
to exchange keys. Last, to attend to an event, $\mathcal{U}$ has to validate
a ticket against a validator $\mathcal{V}$ through an anonymous validation.
At any time during the process, the *Judge* $\mathcal{J}$ can open a tickets to
recover the associated user's identity.

**Anonymity and Auditability.** Anonymity of users is ensured during every interaction with the system (i.e., the ticket distributor $\mathcal{D}$, the transfer authority $\mathcal{T}$ and the validator $\mathcal{V}$) and all over the process. During the protocol, either authentication is not required or users authenticate themselves using randomised identities i.e., randomised keys. If desired, our protocol Applause can be turned into an auditable version called Spotlight, where an external authority refers as the *judge* denoted $\mathcal{J}$, recovers the identity of $\mathcal{U}$. The auditability setting remains consistent with the one presented for *Auditable Anonymous Credentials* in [11]. In a nutshell, $\mathcal{U}$ provides a certificate attesting the validity of its randomised key to $\mathcal{D}$, $\mathcal{T}$ or $\mathcal{V}$. Given such a certificate, kept on a record, $\mathcal{J}$ retrieves the

original key, hence the identity of $\mathcal{U}$. The anonymity still holds
against $\mathcal{D}$, $\mathcal{T}$ or $\mathcal{V}$ as the certificate is randomised with the keys. If
the judge is compromised, only the users' anonymity would be at
risk. The tickets remain valid, ensuring that honest individuals can
utilize their tickets without any issues. A compromised judge $\mathcal{J}$
would not have the capability to forge new tickets or alter the valid-
ity status of previously issued tickets. The purpose of auditability is
not to prevent double spending, but rather to fulfill legal mandates
concerning participant identity recovery. This aspect is crucial in
unforeseen circumstances such as force majeure or disasters.

**Validation Setting.** Large scale events often result in an over-
loaded network due to the number of attendees. Multiple terminals
are needed to validate the tickets simultaneously. Hence, commu-
nications coming to and from the validation terminals are limited
in size and number. One would like to assume that the validator is
offline after an initial setup. As a single ticket should be valid for
any terminal, and without communication between the terminals,
the same ticket could be accepted for each of them, constituting
a forgery for any ticketing system. Hence, the validators must be
online and communicate. In our case, only a single group element
needs to be sent between a terminal and the central server for each
approved verification. For efficiency, we rely on a central authority
instead of a distributed ledger to agree on valid tickets at time *t*.
A validation protocol has to ensure anonymity of users, and thus
cannot authenticate the user. However, an adversary able to relay
all communications between a legitimate user and a validator, can
easily perform what is called a *relay attack* [43], where the adver-
sary can have the access granted without paying a ticket, by simply
blocking and sending all messages sent by a legitimate user to the
validator, in its own name. As a result, the validator grants the
access to the adversary instead of the legitimate user. Badly, neither
the user or the validator can notice this attack. To prevent this
issue, we have chosen to construct a validation protocol based on
a physical channel (such as QRcode [27] scanned by the validator
or Bluetooth's password shared verbally [39]) during the last step
of the protocol to prevent relay attacks by an adversary. $\mathcal{U}$ gets a
token, compared through this channel to the token sent by $\mathcal{V}$.

## 3 E-TICKET SCHEME MODEL

Most ticketing systems are designed to allow the sale of a seat at an
event, with each seat being associated with a metadata such as the
seat number. This can be more general, and we consider a scenario
where tickets are characterised by an *event identifier* ide ∈ ID<sub>E</sub> ⊂ N
and by a *serial number* idp ∈ ID<sub>P</sub> ⊂ N. The set of identifiers and
the set of serial numbers referred to event and seat number, and
are assumed publicly known. Below we define an *E-Ticket Scheme*
based on a security parameter 1<sup>λ</sup>. Note that through this paper,
all algorithms are assumed to run in probabilistic polynomial-time
(PPT). By *A*<sup>O</sup>, we denote the adversary having access to a set of
oracles *O*. By P⟨E<sub>1</sub>(i<sub>1</sub>), ..., E<sub>n</sub>(i<sub>n</sub>)⟩ → E<sub>1</sub>(o<sub>1</sub>), ..., E<sub>n</sub>(o<sub>n</sub>); we denote
the protocol P played between parties E<sub>j</sub>, taking as input i<sub>j</sub> and
outputting o<sub>j</sub>. For simplicity, we may omit a party in the output
part of the notation if the party does not produce output..
<figure><img src="image_1.png" /><figcaption>Figure 1: Representation of the ETS model.</figcaption></figure>

<table><caption>Figure 2: Security properties.</caption><thead><tr><th></th><th>Unforgeability</th><th>Secrecy</th><th>No-double-spending</th><th>Anonymity</th><th>Auditability</th></tr></thead><tbody><tr><th>Applause</th><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>X</td></tr><tr><th>Spotlight</th><td>✓</td><td>✓</td><td>✓</td><td>Partial</td><td>✓</td></tr></tbody></table>

**Definition 3.1 (ETS).** An E-Ticket Scheme $\Pi = (\text{DKeyGen}, \text{TKeyGen}, \text{VKeyGen}, \text{UKeyGen}, \text{Purchase}, \text{Refund}, \text{Transfer}, \text{Validate})$ is a tuple of PPT algorithms:

$\text{DKeyGen}/\text{TKeyGen}/\text{VKeyGen}/\text{UKeyGen}(1^{\lambda}) \to (\text{sk}, \text{pk})$ : Given a security parameter $1^{\lambda}$, outputs a key pair.

$\text{Purchase}(\mathcal{U}(\text{sk}_{\mathcal{U}}$, (ide, idp)), \mathcal{D}(\text{sk}_{\mathcal{D}}, \text{st})) \to \mathcal{U}(\text{tk}), \mathcal{D}(\text{b}, (\text{ide, idp}), \text{st})$ : User $\mathcal{U}$ purchases the ticket identified by (ide, idp), to the ticket distributor $\mathcal{D}$. The user obtains the ticket tk, and $\mathcal{D}$ updates st and returns a success bit b and (ide, idp).

$\text{Refund}(\mathcal{U}(\text{sk}_{\mathcal{U}}$, tk), $\mathcal{D}(\text{sk}_{\mathcal{D}}, \text{st})) \to \mathcal{U}(\text{b}), \mathcal{D}(\text{b}, tk, st)$ : Given a ticket tk and its key $\text{sk}_{\mathcal{U}}$, $\mathcal{U}$ asks the ticket distributor $\mathcal{D}$ for a refund. Both entities output a success bit b, while $\mathcal{D}$ additionally updates st and returns tk.

$\text{Transfer}(\mathcal{U}_1(\text{sk}_{\mathcal{U}_1}, \text{pk}_{\mathcal{U}_2}, \text{tk}_1), \mathcal{T}(\text{sk}_{\mathcal{T}}, \text{st}), \mathcal{U}_2(\text{sk}_{\mathcal{U}_2}, \text{pk}_{\mathcal{U}_1}, (\text{ide, idp}))) \to \mathcal{U}_1(\text{b}), \mathcal{T}(\text{b}, (\text{ide, idp}), \text{tk}_1, \text{st}), \mathcal{U}_2(\text{tk}_2)$ : The transfer protocol allows $\mathcal{U}_1$ owning a ticket tk$_1$, the public key of $\mathcal{U}_2$ and key $\text{sk}_{\mathcal{U}_1}$, to transfer it tk$_2$ holding the public key of $\mathcal{U}_1$ and a key $\text{sk}_{\mathcal{U}_2}$ relying on $\mathcal{T}$ inputting $\text{sk}_{\mathcal{T}}$ and st. As a result, $\mathcal{U}_1$ and $\mathcal{T}$ output a success bit b, while $\mathcal{T}$ also updates the shared state st and outputs (ide, idp) and tk$_1$. Finally $\mathcal{U}_2$ returns a ticket tk$_2$ for the identifier (ide, idp).

$\text{Validate}(\mathcal{U}(\text{sk}_{\mathcal{U}}$, tk), $\mathcal{V}(\text{sk}_{\mathcal{V}}, \text{st})) \to \mathcal{U}(\text{b}), \mathcal{V}(\text{b}, tk, st)$ : $\mathcal{U}$ inputs a ticket tk and its key $\text{sk}_{\mathcal{U}}$, and interacts with $\mathcal{V}$ inputting its key $\text{sk}_{\mathcal{V}}$ and a state st in order to validate the ticket tk. The protocol ends with $\mathcal{U}$ and $\mathcal{V}$ returning a validation bit b, a ticket tk and the state st from the validator $\mathcal{V}$.

**The Shared State.** The above model includes a state st, shared between the ticket distributor $\mathcal{D}$, the transfer authority $\mathcal{T}$ and the validator $\mathcal{V}$. The shared state allows to synchronize ticket status among the different entities. It prevents, for instance, a double validation or a validation after a refund. This shared state could be seen as a white-list or a blacklist, the latter being used in our protocol. In our model, this state is not kept secret: all adversaries have read-only access to the state at any time using an oracle called OLeakState. This state can be implemented as a dedicated server maintaining a database. Note that $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$ share a common state while being represented as distinct entities. This modeling choice aligns with the actual structure of the organization under

consideration, reflecting its physical reality. In an alternate scheme, these entities might be perceived as independent entities without shared state. Therefore, our model is more general this way and remain valid for our purpose.

**Security Model.** Our security experiments are depicted in Fig. 3 and the associated oracles in Fig. 4. In Fig. 2, we provide a concise overview of the key security properties required in our model.

The security model for an ETS emulates realistic behaviors expected from a ticket service. Users possessing a ticket must be able to attend events or claim a refund, this is referred to as protocol correctness. In other properties, formulated as security games, $\mathcal{U} = \{\mathcal{U}_k\}_k$ denote the set of initialized users, potentially empty at the beginning. Each user $\mathcal{U}_k$ is associated with a set $\text{TK}_k$ representing the tickets it owns. By st, we denote the shared state among $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$, initially empty and gradually populated with elements corresponding to revoked tickets. The system should withstand various attack scenarios across multiple executions. To simulate this, we consider a PPT adversary $\mathcal{A}$, allowed to call specific oracles. These oracles, including OCreateUser, OCorruptUser, OPurchase, OTransfer, OValidate, and ORefund, allow the adversary to execute actions. Depending on the expected security game, the adversary have access to specific oracles. Oracles in Fig. 4a allows the user to act as an arbitrary number of users and interact with the oracles simulating the system. At the opposite, oracles Fig. 4b, indexed with an additional bit b characterizing the execution for one user among a set of two, allows the adversary playing the roles of the system (and potentially other users), to interact with the one of two, of the two users simulated by the security game. For ticket un-forgeability, ticket privacy and double-spending, we claim security even if the shared state is leaked. To address security concerns, we have introduced the OLeakState oracle in Fig. 4a. This read-only access grants insights into the state shared among $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$. This section provides a high-level description of the computational model, further detailed in Fig. 3.

**Correctness.** Under honest execution of the algorithms, a ticket tk bought by a user $\mathcal{U}$ through Purchase, or Transfer, can be either refund or validated, i.e., Validate and Refund output a success bit b which equals 1.
<figure><img src="image_2.png" /><figcaption>Figure 1: Representation of the ETS model.</figcaption></figure>

<table><caption>Figure 2: Security properties.</caption><thead><tr><th></th><th>Unforgeability</th><th>Secrecy</th><th>No-double-spending</th><th>Anonymity</th><th>Auditability</th></tr></thead><tbody><tr><th>Applause</th><td>✓</td><td>✓</td><td>✓</td><td>✓</td><td>X</td></tr><tr><th>Spotlight</th><td>✓</td><td>✓</td><td>✓</td><td>Partial</td><td>✓</td></tr></tbody></table>

**Definition 3.1 (ETS).** An E-Ticket Scheme $\Pi = (\text{DKeyGen}, \text{TKeyGen}, \text{VKeyGen}, \text{UKeyGen}, \text{Purchase}, \text{Refund}, \text{Transfer}, \text{Validate})$ is a tuple of PPT algorithms:

DKeyGen/TKeyGen/VKeyGen/UKeyGen(1^λ) → (sk, pk) : Given a

security parameter 1^λ, outputs a key pair.

Purchase(U(sk_q_1, (ide, idp)), D(sk_D, st)) → U(tk), D(b, (ide, idp), st)

: User U purchases the ticket identified by (ide, idp), to the ticket distributor D. The user obtains the ticket tk, and D updates st and returns a success bit b and (ide, idp).

Refund(U(sk_q_1, tk), D(sk_D, st)) → U(b), D(b, tk, st) : Given a ticket

tk and its key sk_q_1, U asks the ticket distributor D for a refund. Both entities output a success bit b, while D additionally updates st and returns tk.

Transfer(U_1(sk_q_1, pk_q_2, tk_1), T(sk_T, st), U_2(sk_q_2, pk_q_1, (ide, idp)))

→ U_1(b), T(b, (ide, idp), tk_1, st), U_2: The transfer protocol allows U_1 owning a ticket tk_1, the public key of U_2 and key sk_q_1, to transfer it tk_2 holding the public key of U_1 and a key sk_q_2 relying on T inputting sk_T and st. As a result, U_1 and T output a success bit b, while T also updates the shared state st and outputs (ide, idp) and tk_1. Finally U_2 returns a ticket tk_2 for the identifier (ide, idp).

Validate(U(sk_q_1, tk), V(sk_V, st)) → U(b), V(b, tk, st) : U inputs a

ticket tk and its key sk_q_1, and interacts with V inputting its key sk_V and a state st in order to validate the ticket tk. The protocol ends with U and V returning a validation bit b, a ticket tk and the state st from the validator V.

**The Shared State.** The above model includes a state st, shared between the ticket distributor D, the transfer authority T and the validator V. The shared state allows to synchronize ticket status among the different entities. It prevents, for instance, a double validation or a validation after a refund. This shared state could be seen as a white-list or a blacklist, the latter being used in our protocol. In our model, this state is not kept secret: all adversaries have *read-only* access to the state at any time using an oracle called OLeakState. This state can be implemented as a dedicated server maintaining a database. Note that D, T, and V share a common state while being represented as distinct entities. This modeling choice aligns with the actual structure of the organization under

consideration, reflecting its physical reality. In an alternate scheme, these entities might be perceived as independent entities without shared state. Therefore, our model is more general this way and remain valid for our purpose.

**Security Model.** Our security experiments are depicted in Fig. 3 and the associated oracles in Fig. 4. In Fig. 2, we provide a concise overview of the key security properties required in our model.

The security model for an ETS emulates realistic behaviors expected from a ticket service. Users possessing a ticket must be able to attend events or claim a refund, this is referred to as protocol correctness. In other properties, formulated as security games, $U = \{U_k\}_k$ denote the set of initialized users, potentially empty at the beginning. Each user $U_k$ is associated with a set TK_k representing the tickets it owns. By st, we denote the shared state among D, T, and V, initially empty and gradually populated with elements corresponding to revoked tickets. The system should withstand various attack scenarios across multiple executions. To simulate this, we consider a PPT adversary A, allowed to call specific oracles. These oracles, including OCreateUser, OCorruptUser, OPurchase, OTransfer, OValidate, and ORefund, allow the adversary to execute actions. Depending on the expected security game, the adversary have access to specific oracles. Oracles in Fig. 4a allows the user to act as an arbitrary number of users and interact with the oracles simulating the system. At the opposite, oracles Fig. 4b, indexed with an additional bit b characterizing the execution for one user among a set of two, allows the adversary playing the roles of the system (and potentially other users), to interact with the one of two, of the two users simulated by the security game. For ticket un-forgeability, ticket privacy and double-spending, we claim security even if the shared state is leaked. To address security concerns, we have introduced the OLeakState oracle in Fig. 4a. This read-only access grants insights into the state shared among D, T, and V. This section provides a high-level description of the computational model, further detailed in Fig. 3.

**Correctness.** Under honest execution of the algorithms, a ticket tk bought by a user U through Purchase, or Transfer, can be either refund or validated, i.e., Validate and Refund output a success bit b which equals 1.
**Unforgeability.** The unforgeability of a ticket prevents an adversary $\mathcal{A}$ from creating a new valid ticket. This property is described in $\text{Exp}_{\mathcal{A}}^{\text{UF}}$. It requires $\mathcal{A}$ to produce a ticket such that (1) the ticket has not been produced by the system i.e., $\text{tk} \notin \text{TK}$, denoted as bit $b_0$ in the experiment and (2) make it accept either for a refund, a transfer, or a validation, this is denoted as bit $b_1$ in the experiment. This property must be ensured for any PPT adversary, with read-only access to the shared state and the oracles of Fig. 4a corresponding to possible actions of the users.

**Ticket privacy.** The ticket privacy prevents from an adversary $\mathcal{A}$, external to the system, stealing a ticket from a designated user. The adversary has the capability to generate, manipulate through oracles of Fig. 4a, and corrupt any user within the system. The ticket privacy is focused against entities that are external to the system. In the associated experiment, $\text{Exp}_{\mathcal{A}}^{\text{PRIV}}$, user $\mathcal{U}_1$ is the adversary's target. $\mathcal{U}_1$ purchases a ticket $\text{tk}$ and $\mathcal{A}$ wins if (1) the purchase went through, (2) $\mathcal{A}$ outputted a ticket $\text{tk}^*$ such that $\text{tk}^* = \text{tk}$ and (3) $\mathcal{A}$ did not corrupt $\mathcal{U}_1$. During this process, the adversary has *read-only* access to the shared state at any point during the experiment. The challenger simulates the user purchasing the ticket targeted for recovery by the adversary, but also $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$, otherwise making the ticket privacy trivially broken as the system requires the ticket for verification purposes.

**No-double-spending.** Once purchased, a ticket should be usable only once: the ticket can be refund once, transferred once or validated once. In other words, as done in our security model, none of Refund, Validate or Transfer executed by the challenger against a corrupted user would accept the same ticket twice. This notion differs from what has been formalised in e-cash [3]. Taking as example the protocol introduced by Baldimtsi et al. [3], their model allows execution of a function Spend twice for the same coin and postpone the double spending verification to a second algorithm call Deposit. Applied to ticketing, since the verification occurs after the ticket spent, the consequence for users is the possibility to buy already spent ticket, leading to a ticket rejection (during the second execution of Deposit of the same ticket). Following our notion, an honest client should not acquire a already transferred ticket.

The security notion preventing the adversary to double-transfer a ticket, and more generally to interact twice with the system using the same ticket is denoted as Double-Spending (DS), and is formally introduced in experiment $\text{Exp}_{\mathcal{A}}^{\text{DS}}$. The challenger simulates the system and allows $\mathcal{A}$ to invoke actions through oracles of Fig. 4a, thereby providing a view of the shared state. The adversary subsequently outputs a ticket $\text{tk}$ and two actions, $\text{Alg}_1$ and $\text{Alg}_2$, selected from $\{\text{Purchase, Refund, Transfer}\}$. Remark that the two specified algorithms $\text{Alg}_1$ and $\text{Alg}_2$ are not required to be the same, modelling every possible combination of attack. The adversary succeeds if (1) both algorithm executions are successful, (2) the tickets $\text{tk}_1$ and $\text{tk}_2$ presented to the validator match the committed ticket $\text{tk}$, and (3) the tickets share identical event identifiers ide and serial numbers idp. Both executions are dependent since the shared state $\text{st}$ is updated after the first execution and used the second time.

**Anonymity.** To model the properties of non-nominative physical tickets, an ETS should preserve the anonymity of a ticket holder $\mathcal{U}$ against the system. This is modelled by using two properties,

one ensuring the pseudonymity of $\mathcal{U}$ and, as a complementary, we ensure unlinkability of the tickets purchased by a single user. This respectively guarantees that a ticket could not be linked by the system as coming from the same holder nor be linked to a user. In both cases, the adversary controls the system i.e., $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$ and thus can generate and control other users. Experiment $\text{Exp}_{\mathcal{A}}^{\text{PSE}}$ models pseudonymity: the challenger generates two users, denoted as $\mathcal{U}_0$ and $\mathcal{U}_1$, represented by their respective public keys $\text{pk}_{\mathcal{U}_0}$ and $\text{pk}_{\mathcal{U}_1}$. $\mathcal{A}$ can invoke oracles $\text{OPurchase}_b$, $\text{ORefund}_b$, $\text{OTransfer}_b$, and $\text{OValidate}_b$ from Fig. 4b, for a given $b \in \{0, 1\}$. For $\mathcal{A}$ to succeed, it must produce a bit $b^*$ that matches the input bit $b$ provided in the oracles. Then determining which one of $\mathcal{U}_0$ and $\mathcal{U}_1$ responded to the oracle calls. Experiment $\text{Exp}_{\mathcal{A}}^{\text{UNL}}$ is designed to model Unlinkability. In this experiment, the challenger once again simulates the behaviors of two users, denoted as $\mathcal{U}_0$ and $\mathcal{U}_1$. Initially, the adversary interacts with both users by making calls to the oracles presented in Fig. 4b, denoted as $\text{OPurchase}_i$, $\text{ORefund}_i$, $\text{OTransfer}_i$ and $\text{OValidate}_i$, where $i \in \{0, 1\}$ is chosen by the adversary. Following this preliminary phase, the adversary provides three ticket identifiers $\{\text{id}_i, \text{id}_i\}_{i \in 0,1,2}$. Each of $\mathcal{U}_0$ and $\mathcal{U}_1$ performs a purchase and subsequently executes an action from the set $\{\text{Validate, Refund, Transfer}\}$ for one ticket. Then, a bit $b$ is sampled from $\{0, 1\}$, and $\mathcal{U}_b$ replicates the same pattern for the third ticket. The adversary succeeds in the experiment if it can correctly guess which user performed the last actions.

We mitigate anonymity by introducing *Auditable E-Ticket scheme* enabling user's identity recovery under the supervision of a judge.

**Definition 3.2 (Auditable ETS).** An *Auditable E-Ticket scheme* ETS is an E-Ticket scheme increased with an audit algorithm:

$$ \text{JKeyGen}(1^{\lambda}) \rightarrow (\text{sk}_{\mathcal{J}}, \text{pk}_{\mathcal{J}}) : \text{Given } 1^{\lambda}, \text{ outputs a key pair.} $$

$$ \text{Audit}(\text{sk}_{\mathcal{J}}, \text{tk}) \rightarrow \text{pk}_{\mathcal{U}} : \text{Given a secret key } \text{sk}_{\mathcal{J}} \text{ and a state } \text{st}, \text{ returns the public key associated to user } \mathcal{U}. $$

Auditable E-Ticket scheme achieves the previous properties but Audit requests for $\mathcal{U}_0$ and $\mathcal{U}_1$ are not allowed for the adversary during the pseudonymity and unlinkability experiments.

# 4 CRYPTOGRAPHIC TOOLS

Applause is built upon an asymmetric encryption, a signature scheme and an anonymous payment.

An asymmetric encryption scheme $E = (\text{KeyGen}, \text{Enc}, \text{Dec})$ ensures confidentiality of messages. $\text{KeyGen}(1^\lambda)$ generates the key pair $(\text{sk}, \text{pk})$. Given plaintext $\text{p}$, one computes the encryption of $\text{p}$ using $\text{Enc}_{\text{pk}}(\text{p})$ returning a ciphertext $\text{c}$. The ciphertext is decrypted using algorithm $\text{Dec}_{\text{sk}}(\text{c})$ returning a plaintext $\text{p}$. We require the encryption scheme to achieve Correctness ensuring correct recovery of the plaintext, and Indistinguishability under Chosen Plaintext Attack (IND-CPA) against any PPT algorithm $\mathcal{A}$. The probability of breaking IND-CPA for an adversary $\mathcal{A}$ is given by $\text{Adv}_{\mathcal{A}}^{\text{IND-CPA}}$ and must be negligible.

A signature scheme $S = (\text{KeyGen}, \text{Sign}, \text{Verif})$ authenticates messages. Again $\text{KeyGen}(1^\lambda)$ generates the key pair $(\text{sk}, \text{pk})$, sk being used to sign message $\text{m}$, producing an element $\text{Sign}_{\text{sk}}(\text{m}) = \sigma$ called the signature. A signature is verified using $\text{Verif}_{\text{pk}}(\text{m}, \sigma)$ out-putting 1 on success, 0 otherwise. We require the signature to
**Unforgeability.** The unforgeability of a ticket prevents an adversary $\mathcal{A}$ from creating a new valid ticket. This property is described in $\mathrm{Exp}_{\mathcal{A}}^{\mathrm{UF}}$. It requires $\mathcal{A}$ to produce a ticket such that (1) the ticket has not been produced by the system i.e., $\mathrm{tk} \notin \mathrm{TK}$, denoted as bit $b_0$ in the experiment and (2) make it accept either for a refund, a transfer, or a validation, this is denoted as bit $b_1$ in the experiment. This property must be ensured for any PPT adversary, with read-only access to the shared state and the oracles of Fig. 4a corresponding to possible actions of the users.

**Ticket privacy.** The ticket privacy prevents from an adversary $\mathcal{A}$, external to the system, stealing a ticket from a designated user. The adversary has the capability to generate, manipulate through oracles of Fig. 4a, and corrupt any user within the system. The ticket privacy is focused against entities that are external to the system. In the associated experiment, $\mathrm{Exp}_{\mathcal{A}}^{\mathrm{PRIV}}$, user $\mathcal{U}_1$ is the adversary's target. $\mathcal{U}_1$ purchases a ticket $\mathrm{tk}$ and $\mathcal{A}$ wins if (1) the purchase went through, (2) $\mathcal{A}$ outputted a ticket $\mathrm{tk}^*$ such that $\mathrm{tk}^* = \mathrm{tk}$ and (3) $\mathcal{A}$ did not corrupt $\mathcal{U}_1$. During this process, the adversary has *read-only* access to the shared state at any point during the experiment. The challenger simulates the user purchasing the ticket targeted for recovery by the adversary, but also $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$, otherwise making the ticket privacy trivially broken as the system requires the ticket for verification purposes.

**No-double-spending.** Once purchased, a ticket should be usable only once: the ticket can be refund once, transferred once or validated once. In other words, as done in our security model, none of Refund, Validate or Transfer executed by the challenger against a corrupted user would accept the same ticket twice. This notion differs from what has been formalised in e-cash [3]. Taking as example the protocol introduced by Baldimtsi et al. [3], their model allows execution of a function Spend twice for the same coin and postpone the double spending verification to a second algorithm call Deposit. Applied to ticketing, since the verification occurs after the ticket spent, the consequence for users is the possibility to buy already spent ticket, leading to a ticket rejection (during the second execution of Deposit of the same ticket). Following our notion, an honest client should not acquire a already transferred ticket.

The security notion preventing the adversary to double-transfer a ticket, and more generally to interact twice with the system using the same ticket is denoted as Double-Spending (DS), and is formally introduced in experiment $\mathrm{Exp}_{\mathcal{A}}^{\mathrm{DS}}$. The challenger simulates the system and allows $\mathcal{A}$ to invoke actions through oracles of Fig. 4a, thereby providing a view of the shared state. The adversary subsequently outputs a ticket $\mathrm{tk}$ and two actions, $\mathrm{Alg}_1$ and $\mathrm{Alg}_2$, selected from $\{\mathrm{Purchase}, \mathrm{Refund}, \mathrm{Transfer}\}$. Remark that the two specified algorithms $\mathrm{Alg}_1$ and $\mathrm{Alg}_2$ are not required to be the same, modelling every possible combination of attack. The adversary succeeds if (1) both algorithm executions are successful, (2) the tickets $\mathrm{tk}_1$ and $\mathrm{tk}_2$ presented to the validator match the committed ticket $\mathrm{tk}$, and (3) the tickets share identical event identifiers ide and serial numbers idp. Both executions are dependent since the shared state $\mathrm{st}$ is updated after the first execution and used the second time.

**Anonymity.** To model the properties of non-nominative physical tickets, an ETS should preserve the anonymity of a ticket holder $\mathcal{U}$ against the system. This is modelled by using two properties,

one ensuring the pseudonymity of $\mathcal{U}$ and, as a complementary, we ensure unlinkability of the tickets purchased by a single user. This respectively guarantees that a ticket could not be linked by the system as coming from the same holder nor be linked to a user. In both cases, the adversary controls the system i.e., $\mathcal{D}$, $\mathcal{T}$, and $\mathcal{V}$ and thus can generate and control other users. Experiment $\mathrm{Exp}_{\mathcal{A}}^{\mathrm{PSE}}$ models pseudonymity: the challenger generates two users, denoted as $\mathcal{U}_0$ and $\mathcal{U}_1$, represented by their respective public keys $\mathrm{pk}_{\mathcal{U}_0}$ and $\mathrm{pk}_{\mathcal{U}_1}$. $\mathcal{A}$ can invoke oracles $\mathrm{OPurchase}_b$, $\mathrm{ORefund}_b$, $\mathrm{OTransfer}_b$, and $\mathrm{OValidate}_b$ from Fig. 4b, for a given $b \in \{0, 1\}$. For $\mathcal{A}$ to succeed, it must produce a bit $b^*$ that matches the input bit $b$ provided in the oracles. Then determining which one of $\mathcal{U}_0$ and $\mathcal{U}_1$ responded to the oracle calls. Experiment $\mathrm{Exp}_{\mathcal{A}}^{\mathrm{UNL}}$ is designed to model Unlinkability. In this experiment, the challenger once again simulates the behaviors of two users, denoted as $\mathcal{U}_0$ and $\mathcal{U}_1$. Initially, the adversary interacts with both users by making calls to the oracles presented in Fig. 4b, denoted as $\mathrm{OPurchase}_i$, $\mathrm{ORefund}_i$, $\mathrm{OTransfer}_i$ and $\mathrm{OValidate}_i$, where $i \in \{0, 1\}$ is chosen by the adversary. Following this preliminary phase, the adversary provides three ticket identifiers $\{\mathrm{id}_i, \mathrm{id}_i\}_{i \in 0,1,2}$. Each of $\mathcal{U}_0$ and $\mathcal{U}_1$ performs a purchase and subsequently executes an action from the set $\{\mathrm{Validate}, \mathrm{Refund}, \mathrm{Transfer}\}$ for one ticket. Then, a bit $b$ is sampled from $\{0, 1\}$, and $\mathcal{U}_b$ replicates the same pattern for the third ticket. The adversary succeeds in the experiment if it can correctly guess which user performed the last actions.

We mitigate anonymity by introducing Auditable E-Ticket scheme enabling user's identity recovery under the supervision of a judge.

**Definition 3.2 (Auditable ETS).** An Auditable E-Ticket scheme ETS is an E-Ticket scheme increased with an audit algorithm:

$$ \mathsf{KeyGen}(1^{\lambda}) \rightarrow (\mathrm{sk}_{\mathcal{J}}, \mathrm{pk}_{\mathcal{J}}) : \text{Given } 1^{\lambda}, \text{ outputs a key pair.} $$

$$ \underline{\mathrm{Audit}}(\mathrm{sk}_{\mathcal{J}}, \mathrm{tk}) \rightarrow \mathrm{pk}_{\mathcal{U}} : \text{Given a secret key } \mathrm{sk}_{\mathcal{J}} \text{ and a state } \mathrm{st}, \text{ returns the public key associated to user } \mathcal{U}. $$

Auditable E-Ticket scheme achieves the previous properties but Audit requests for $\mathcal{U}_0$ and $\mathcal{U}_1$ are not allowed for the adversary during the pseudonymity and unlinkability experiments.

# 4 CRYPTOGRAPHIC TOOLS

Applause is built upon an asymmetric encryption, a signature scheme and an anonymous payment.

An asymmetric encryption scheme $E = (\mathrm{KeyGen}, \mathrm{Enc}, \mathrm{Dec})$ ensures confidentiality of messages. $\mathrm{KeyGen}(1^\lambda)$ generates the key pair $(\mathrm{sk}, \mathrm{pk})$. Given plaintext $\mathrm{p}$, one computes the encryption of $\mathrm{p}$ using $\mathrm{Enc}_{\mathrm{pk}}(\mathrm{p})$ returning a ciphertext $\mathrm{c}$. The ciphertext is decrypted using algorithm $\mathrm{Dec}_{\mathrm{sk}}(\mathrm{c})$ returning a plaintext $\mathrm{p}$. We require the encryption scheme to achieve Correctness ensuring correct recovery of the plaintext, and Indistinguishability under Chosen Plaintext Attack (IND-CPA) against any PPT algorithm $\mathcal{A}$. The probability of breaking IND-CPA for an adversary $\mathcal{A}$ is given by $\mathrm{Adv}_{\mathcal{A}}^{\mathrm{IND-CPA}}$ and must be negligible.

A signature scheme $S = (\mathrm{KeyGen}, \mathrm{Sign}, \mathrm{Verif})$ authenticates messages. Again $\mathrm{KeyGen}(1^\lambda)$ generates the key pair $(\mathrm{sk}, \mathrm{pk})$, sk being used to sign message $\mathrm{m}$, producing an element $\mathrm{Sign}_{\mathrm{sk}}(\mathrm{m}) = \sigma$ called the signature. A signature is verified using $\mathrm{Verif}_{\mathrm{pk}}(\mathrm{m}, \sigma)$ out-putting 1 on success, 0 otherwise. We require the signature to
<figure><img src="image_2.png" /></figure>

<figure><img src="image_3.png" /><figcaption>Figure 3: Experiments for Unforgeability $\text{Exp}_{\mathcal{A}}^{\text{UF}}$, Privacy of a ticket $\text{Exp}_{\mathcal{A}}^{\text{PRIV}}$ and Double-Spending $\text{Exp}_{\mathcal{A}}^{\text{DS}}$, Unlinkability $\text{Exp}_{\mathcal{A}}^{\text{UNL}}$ and Pseudonimity $\text{Exp}_{\mathcal{A}}^{\text{PSE}}$. $O$ equals $\{\text{OPurchase}, \text{ORefund}, \text{OTransfer}, \text{OValidate}, \text{OCreateUser}, \text{OCorruptUser}, \text{OLeakState}\}$ and $O_b$ equals $\{\text{OPurchase}_b, \text{ORefund}_b, \text{OTransfer}_b, \text{OValidate}_b\}$</figcaption></figure>
<figure><img src="image_3.png" /></figure>

<figure><img src="image_4.png" /><figcaption>**Figure 3: Experiments for Unforgeability Exp<sub>Ar</sub><sup>UF</sup>, Privacy of a ticket Exp<sub>Ar</sub><sup>PRIV</sup> and Double-Spending Exp<sub>Ar</sub><sup>DS</sup>, Unlinkability Exp<sub>Ar</sub><sup>UNL</sup> and Pseudonimity Exp<sub>Ar</sub><sup>PSE</sup>. O equals {OPurchase, ORefund, OTransfer, OValidate, OCreateUser, OCorruptUser, OLeakState} and O<sub>b</sub> equals {OPurchase<sub>b</sub>, ORefund<sub>b</sub>, OTransfer<sub>b</sub>, OValidate<sub>b</sub>}</figcaption></figure>
OPurchase($\mathcal{U}$, sk$_{\mathcal{D}}$; i, sk$_{\mathcal{A}_i}$, (ide, idp))

$$ \mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i) $$

if corr$_i$ = 1: // Corrupted user

Purchase($\mathcal{A}(\cdot, \cdot)$, C(sk$_{\mathcal{D}}$, st))

$$ \rightarrow \mathcal{A}(\cdot), C(b, (ide, idp), st) $$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\perp, (ide, idp), b)\}), \text{corr}_i $$

else : (ide, idp) $\stackrel{s}{\leftarrow}$ ID$_\epsilon$ $\times$ ID$_\phi$ // Honest user

Purchase($\mathcal{C}(\text{sk}\mathcal{U}_i, (ide, idp)), C(\text{sk}\mathcal{D}, st)$

$$ \rightarrow \mathcal{C}(\text{tk}), C(b, (ide, idp), st) $$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}, (ide, idp), b)\}), \text{corr}_i $$

OValidate($\mathcal{U}$, sk$_{\mathcal{A}_i}$; i, sk$_{\mathcal{A}_i}$, tk$_i$, (ide, idp))

$$ \mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i) $$

if corr$_i$ = 1: // Corrupted user

Validate($\mathcal{A}(\cdot, \cdot)$, C(sk$_{\mathcal{V}}$, st)) $\rightarrow$ $\mathcal{A}(\cdot)$, C(b, tk, st)

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}, (ide, idp), 1 - b)\}), \text{corr}_i $$

else : // Honest user

TK$_i$ $\leftarrow$ {tk', (ide, idp), b}

Validate($\mathcal{C}(\text{sk}\mathcal{U}_i, \text{tk}'), \mathcal{C}(\text{sk}\mathcal{V}, st)$) $\rightarrow$ $\mathcal{C}(b), \mathcal{C}(b, \text{tk}, st)$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}, (ide, idp), 1 - b)\}), \text{corr}_i $$

ORefund($\mathcal{U}$, sk$_{\mathcal{D}}$; i, sk$_{\mathcal{A}_i}$, tk, (ide, idp))

$$ \mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i) $$

if corr$_i$ = 1: // Corrupted user

Refund($\mathcal{A}(\cdot, \cdot)$, C(sk$_{\mathcal{D}}$, st)) $\rightarrow$ $\mathcal{A}(\cdot)$, C(b, tk, st)

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{\text{tk}, (\text{ide}, \text{idp}), 1 - b\}), \text{corr}_i $$

else : // Honest user

TK$_i$ $\xrightarrow{p}$ {tk', (ide, idp), b}

Refund($\mathcal{C}(\text{sk}\mathcal{U}_i, \text{tk}'), \mathcal{C}(\text{sk}\mathcal{D}, st)$) $\rightarrow$ $\mathcal{C}(b), \mathcal{C}(b, \text{tk}', st)$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{\text{tk}, (\text{ide}, \text{idp}), 1 - b\}), \text{corr}_i $$

OTransfer($\mathcal{U}$, sk$_{\mathcal{T}}$; i, j, sk$_{\mathcal{A}_i}$, sk$_{\mathcal{A}_j}$, tk$_i$, (ide, idp))

$$ \mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i), $$

$$ \mathcal{U}_j \xrightarrow{p} (\text{sk}q_j, \text{pk}q_j, \text{TK}_i, \text{corr}_i) $$

if corr$_i$ = 1 $\wedge$ corr$_j$ = 1: // Corrupted users

Transfer($\mathcal{A}(\cdot, \cdot)$, C(sk$_{\mathcal{T}}$, st), $\mathcal{A}(\cdot)$)

$$ \rightarrow \mathcal{A}(\cdot), C(b, (ide, idp), st), \mathcal{A}(\cdot) $$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\perp, (\text{ide}, \text{idp}), b)\}), \text{corr}_i $$

if corr$_i$ = 1: // Corrupted sender

Transfer($\mathcal{A}(\cdot, \cdot)$, C(sk$_{\mathcal{T}}$, st), C(sk$_{\mathcal{U}_j}$, (ide, idp)))

$$ \rightarrow \mathcal{A}(\cdot), C(b, (ide, idp), st), C(\text{tk}) $$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}', (\text{ide}, \text{idp}), b)\}), \text{corr}_i $$

if corr$_j$ = 1: // Corrupted receiver

TK$_i$ $\leftarrow$ {tk', (ide, idp), b}

Transfer($\mathcal{C}(\text{sk}\mathcal{U}_i, \text{tk}'), \mathcal{C}(\text{sk}_{\mathcal{T}}, st)$, $\mathcal{A}(\cdot)$)

$$ \rightarrow \mathcal{C}(b), C(b, (ide, idp), st), \mathcal{A}(\cdot) $$

$$ \mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\perp, (\text{ide}, \text{idp}), b)\}), \text{corr}_i $$

OCreateUser($\mathcal{U}$; pk)

$$ \text{if } pk \neq \perp: i \leftarrow |\mathcal{U}|, \mathcal{U} \leftarrow \mathcal{U} \cup \{\mathcal{U}_i = (\perp, \text{pk}, \perp, 1)\} $$

return $\perp$

else : $i \leftarrow |\mathcal{U}|$, (sk$_{\mathcal{U}_i}$, pk$_{\mathcal{U}_i}$) $\leftarrow$ UKeyGen(pp)

$$ \mathcal{U} \leftarrow \mathcal{U} \cup \{\mathcal{U}_i = (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \perp, 0)\} $$

return $\text{pk}\mathcal{U}$

OCorruptUser($\mathcal{U}$; i)

$$ \mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i, \text{corr}_i) $$

$$ \mathcal{U}_i \leftarrow \{(\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i, 1)\} $$

return (sk$_{\mathcal{U}_i}$, pk$_{\mathcal{U}_i}$, TK$_i$)

OLeakState(st)

return st

(a) Oracles for the experiments $\text{Exp}^{\text{UF}}_{\mathcal{A}}$, $\text{Exp}^{\text{DS}}_{\mathcal{A}}$, $\text{Exp}^{\text{UNL}}_{\mathcal{A}}$ and $\text{Exp}^{\text{PRIV}}_{\mathcal{A}}$.

OPurchase$_b(\mathcal{U}$, sk$_{\mathcal{U}_b}$; (ide, idp))

$$ \text{Purchase}(\mathcal{C}(\text{sk}\mathcal{U}_b, (\text{ide}, \text{idp})), \mathcal{A}(\cdot, \cdot)) \rightarrow C(\text{tk}|_{\text{TK}|}), \mathcal{A}(\cdot) \text{ if } i \geq |\mathcal{U}|: \text{ return } \perp $$

TK $\leftarrow$ TK $\cup$ {tk$_{|_{TK}|}$}

ORefund$_b(\mathcal{U}$, sk$_{\mathcal{U}_b}$; i)

if $i \geq |\mathcal{U}|: \text{ return } \perp$

TK $\xrightarrow{p}$ {tk$_j\}$}

Refund($\mathcal{C}(\text{sk}\mathcal{U}_b, \text{tk}_i)$, $\mathcal{A}(\cdot, \cdot)$) $\rightarrow$ $\mathcal{C}(b), \mathcal{A}(\cdot, \cdot)$

OValidate$_b(\mathcal{U}$, sk$_{\mathcal{U}_b}$; i)

if $i \geq |\mathcal{U}|: \text{ return } \perp$

TK $\xrightarrow{p}$ {tk$_j\}$}

Validate($\mathcal{C}(\text{sk}\mathcal{U}_b, \text{tk}_i)$, $\mathcal{A}(\cdot, \cdot)$) $\rightarrow$ $\mathcal{C}(b), \mathcal{A}(\cdot, \cdot)$

OTransfer$_b(\mathcal{U}$, sk$_{\mathcal{U}_b}$; i, role, pk'$_{\mathcal{U}_j}$, (ide, idp))

if $i \geq |\mathcal{U}|: \text{ return } \perp$

if role = sell: TK $\xrightarrow{p}$ {tk$_j\}$}

Transfer($\mathcal{C}(\text{sk}\mathcal{U}_i, \text{pk}'_{\mathcal{U}_j}, \text{tk}'), \mathcal{A}(\cdot, \cdot), \mathcal{A}(\cdot)$)

$$ \rightarrow \mathcal{C}(b), \mathcal{A}(\cdot, \cdot, \cdot), \mathcal{A}(\cdot) $$

if role = buy:

Transfer($\mathcal{A}(\cdot, \cdot), \mathcal{A}(\cdot, \cdot), \mathcal{C}(\text{sk}_{\mathcal{A}_j}, (\text{ide}, \text{idp})))$

$$ \rightarrow \mathcal{A}(\cdot), \mathcal{A}(\cdot, \cdot, \cdot), \mathcal{C}(\text{tk}|_{\text{TK}|}) $$

TK $\leftarrow$ TK $\cup$ {tk$_{|_{TK}|}$}

(b) Oracles for the experiment $\text{Exp}^{\text{PSE}}_{\mathcal{A}}$.

<caption>Figure 4: In each oracle, arguments provided by the challenger C appear before the ','; while arguments specified after are provided by A.</caption>
OPurchase($\mathcal{U}$, sk$_{\mathcal{D}}$; i, sk$_{\mathcal{A}_i}$, (ide, idp))

$$
\mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i)
$$

if corr<sub>i</sub> = 1: // Corrupted user

Purchase⟨A(·, ·), C(sk<sub>D</sub>, st)⟩

$$
\rightarrow \mathcal{A}(\cdot), C(b, (ide, idp), st)
$$

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\perp, (\text{ide, idp}), b)\}), \text{corr}_i
$$

else : (ide, idp) $\stackrel{s}{\leftarrow}$ ID<sub>E</sub> × ID<sub>ρ</sub> // Honest user

Purchase⟨C(sk<sub>U</sub><sub>i</sub>, (ide, idp)), C(sk<sub>D</sub>, st)⟩

$$
\rightarrow C(\text{tk}), C(b, (\text{ide, idp}), \text{st})
$$

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}, (\text{ide, idp}), b)\}), \text{corr}_i
$$

OValidate($\mathcal{U}$, sk$_{\mathcal{V}}$; i, sk$_{\mathcal{A}_i}$, tk$_i$, (ide, idp))

$$
\mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i)
$$

if corr<sub>i</sub> = 1: // Corrupted user

Validate⟨A(·, ·), C(sk<sub>V</sub>, st)⟩ → A(·), C(b, tk, st)

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}, (\text{ide, idp}), 1 - b)\}), \text{corr}_i
$$

else : // Honest user

TK$_i \rightarrow \{\text{tk}^\prime, (\text{ide, idp}), b\}$

Validate⟨C(sk$_{q}$$_{i}$, tk$^{\prime}$), C(sk$_{V}$, st)⟩ → C(b), C(b, tk, st)

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}, (\text{ide, idp}), 1 - b)\}), \text{corr}_i
$$

ORefund($\mathcal{U}$, sk$_{\mathcal{D}}$; i, sk$_{\mathcal{A}_i}$, tk, (ide, idp))

$$
\mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i)
$$

if corr<sub>i</sub> = 1: // Corrupted user

Refund⟨A(·, ·), C(sk<sub>D</sub>, st)⟩ → A(·), C(b, tk, st)

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{\text{tk}, (\text{ide, idp}), 1 - b\}), \text{corr}_i
$$

else : // Honest user

TK$_i \xrightarrow{p}$ {tk', (ide, idp), b}

Refund⟨C(sk<sub>U</sub><sub>i</sub>, tk'), C(sk<sub>D</sub>, st)⟩ → C(b), C(b, tk', st)

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{\text{tk}, (\text{ide, idp}), 1 - b\}), \text{corr}_i
$$

OTransfer($\mathcal{U}$, sk$_{\mathcal{T}}$; i, j, sk$_{\mathcal{A}_i}$, sk$_{\mathcal{A}_j}$, tk$_i$, (ide, idp))

$$
\mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i),
$$

$$
\mathcal{U}_j \xrightarrow{p} (\text{sk}q_j, \text{pk}q_j, \text{TK}_i, \text{corr}_i)
$$

if corr<sub>i</sub> = 1 ∧ corr<sub>j</sub> = 1: // Corrupted users

Transfer⟨A(·, ·), C(sk<sub>T</sub>, st), A(·)⟩

$$
\rightarrow \mathcal{A}(\cdot), C(b, (\text{ide, idp}), st), \mathcal{A}(\cdot)
$$

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\perp, (\text{ide, idp}), b)\}), \text{corr}_i
$$

if corr<sub>i</sub> = 1: // Corrupted sender

Transfer⟨A(·, ·), C(sk<sub>T</sub>, st), C(sk<sub>U</sub><sub>j</sub>, (ide, idp))⟩

$$
\rightarrow \mathcal{A}(\cdot), C(b, (\text{ide, idp}), st), C(\text{tk})
$$

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\text{tk}', (\text{ide, idp}), b)\}), \text{corr}_i
$$

if corr<sub>j</sub> = 1: // Corrupted receiver

TK<sub>i</sub> → {tk', (ide, idp), b'}

Transfer⟨C(sk<sub>q</sub><sub>i</sub>, tk'), C(sk<sub>T</sub>, st), A(·)⟩

$$
\rightarrow C(b), C(b, (\text{ide, idp}), st), \mathcal{A}(\cdot)
$$

$$
\mathcal{U}_i \leftarrow (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i \cup \{(\perp, (\text{ide, idp}), b)\}), \text{corr}_i
$$

OCreateUser($\mathcal{U}$; pk)

$$
\text{if } pk \neq \perp: i \leftarrow |\mathcal{U}|, \mathcal{U} \leftarrow \mathcal{U} \cup \{\mathcal{U}_i = (\perp, \text{pk}, \perp, 1)\}
$$

return $\perp$

else : i $\leftarrow |\mathcal{U}|$, (sk$\mathcal{U}_i$, pk$\mathcal{U}_i$) $\leftarrow$ UKeyGen(pp)

$$
\mathcal{U} \leftarrow \mathcal{U} \cup \{\mathcal{U}_i = (\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \perp, 0)\}
$$

return $\text{pkU}$

OCorruptUser($\mathcal{U}$; i)

$$
\mathcal{U} \xrightarrow{p} \{\mathcal{U}_k\}_k, \mathcal{U}_i \xrightarrow{p} (\text{sk}q_i, \text{pk}q_i, \text{TK}_i, \text{corr}_i)
$$

$$
\mathcal{U}_i \leftarrow \{(\text{sk}\mathcal{U}_i, \text{pk}\mathcal{U}_i, \text{TK}_i, 1)\}
$$

return (sk$_{q}$$_{i}$, pk$_{q}$$_{i}$, TK$_{i}$)

OLeakState(st)

return st

(a) Oracles for the experiments Exp<sub>U</sub><sup>UF</sup>, Exp<sub>A</sub><sup>DS</sup>, Exp<sub>A</sub><sup>UNL</sup> and Exp<sub>A</sub><sup>PRIV</sup>.

OPurchase<sub>b</sub>(U, sk<sub>U</sub><sub>b</sub>; (ide, idp))

$$
\text{Purchase}(C(\text{sk}q_b, (\text{ide, idp})), \mathcal{A}(\cdot, \cdot)) \rightarrow C(\text{tk}|_{\text{TK}|}), \mathcal{A}(\cdot) \text{ if } i \geq |\mathcal{U}|: \text{ return } \perp
$$

TK $\leftarrow$ TK $\cup$ $\{\text{tk}|_{\text{TK}|}\}$

ORefund<sub>b</sub>(U, sk<sub>U</sub><sub>b</sub>; i)

if $i \geq |\mathcal{U}|$: return $\perp$

TK $\xrightarrow{p}$ $\{\text{tk}_j\}_j$

Refund⟨C(sk<sub>U</sub><sub>b</sub>, tk<sub>i</sub>), A(·, ·)⟩ → C(b), A(·, ·)

OValidate<sub>b</sub>(U, sk<sub>U</sub><sub>b</sub>; i)

if $i \geq |\mathcal{U}|$: return $\perp$

TK $\xrightarrow{p}$ $\{\text{tk}_j\}_j$

Validate⟨C(sk<sub>U</sub><sub>b</sub>, tk<sub>i</sub>), A(·, ·)⟩ → C(b), A(·, ·)

OTransfer<sub>b</sub>(U, sk<sub>U</sub><sub>b</sub>; i, role, pk'<sub>U</sub><sub>j</sub>, (ide, idp))

if $i \geq |\mathcal{U}|$: return $\perp$

if role = sell: TK $\xrightarrow{p}$ $\{\text{tk}_j\}_j$

Transfer⟨C(sk<sub>U</sub><sub>i</sub>, pk'<sub>U</sub><sub>j</sub>, tk'), A(·, ·), A(·)⟩

$$
\rightarrow C(b), \mathcal{A}(\cdot, \cdot, \cdot), \mathcal{A}(\cdot)
$$

if role = buy:

Transfer⟨A(·, ·), A(·, ·), C(sk<sub>A</sub><sub>j</sub>, (ide, idp))⟩

$$
\rightarrow \mathcal{A}(\cdot), \mathcal{A}(\cdot, \cdot, \cdot), C(\text{tk}|_{\text{TK}|})
$$

TK $\leftarrow$ TK $\cup$ $\{\text{tk}|_{\text{TK}|}\}$

(b) Oracles for the experiment Exp<sub>A</sub><sup>PSE</sup>.

<caption>Figure 4: In each oracle, arguments provided by the challenger *C* appear before the ' ', while arguments specified after are provided by *A*.</caption>
achieve Correctness of the algorithms, and Existential Unforgeability under Chosen Message Attacks (EUF-CMA) against any PPT algorithm $\mathcal{A}$. The probability of breaking EUF-CMA for an adversary $\mathcal{A}$ is given by $\text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}$ and must be negligible. We stress that a signature does not provide access to the associated message. For both encryption and signature, we require the algorithm $\text{RandKey}(\text{sk}, \text{pk}) \to (\text{sk}^\prime, \text{pk}^\prime)$ allowing to randomise a key pair. Using discrete log based keys $\text{pk} \leftarrow g^{\text{sk}}$ for some prime order group generator $g$, the randomisable key mechanism can be seen as $\text{RandKey}(\text{sk}, \text{pk}) \to (\text{sk} \cdot r, \text{pk}^\prime)$ for a $r$ randomly sampled at uniform $(r \stackrel{\$}{\leftarrow} G$ denotes a uniform sample of $r$ from the set $G)$. In many cases this is the same as generating a new key.

Ticket purchasing, transferring, and refunding necessitate payments. However, conventional online payment methods (such as card payments based on the EMV protocol [17]) disclose the user's identity, posing a challenge to ensure user anonymity in a ETS setting. Therefore, the anonymity within a ETS protocol is contingent on the anonymity provided by the underlying payment protocol. Rather than omitting the payment process, as observed in [25], we've opted to incorporate the payment protocol. Specifically, to maintain user anonymity, the incorporated payment, termed Anonymous Payment and utilized as a foundational component, must enable participants to make payments without disclosing their identities. This building block is voluntary generic to let any anonymous payment method, to be plugged in our protocol. Our generic description for Payment Schemes PS comprises the PPT algorithms: $\text{KeyGen}(1^\lambda)$: Generate the key pair $(\text{sk}, \text{pk})$.

$\text{Pay}(\mathcal{U}_1(\text{sk}_{\mathcal{U}_1}), \mathcal{U}_2(\text{sk}_{\mathcal{U}_2})) \to \mathcal{U}_1(b), \mathcal{U}_2(b)$: User $\mathcal{U}_1$ performs a payment to $\mathcal{U}_2$. At the end, a success bit $b$ is returned.

For the sake of our demonstration and to facilitate our security reduction without mandating a specific payment method, we employ two generic definitions for Unlinkability, which ensures that two transactions from the same payee aren't linked, and Pseudonymity, which ensure that payee's identity remains undisclosed.

**Pseudonymity.** For any PPT adversary $\mathcal{A}$, it should not be possible to predict the user $\mathcal{U}_b$, for $b \in \{0, 1\}$, proceeding to a payment, with a probability significantly different from $1/2$. $\mathcal{A}$ has access to a $\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_b}, \cdot), \mathcal{A}(\cdot))$ oracle. Anonymous payment ensures pseudonymity if, for any $1^\lambda$,

$$ \left| \Pr \left[ \begin{array}{l} (\text{sk}_i, \text{pk}_i)_{i \in \{0,1\}} \stackrel{\$}{\leftarrow} \text{KeyGen}(1^\lambda) \\ b \stackrel{\$}{\leftarrow} \{0,1\} \qquad : b = b^* \\ b^* \leftarrow \mathcal{A}^{\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_b}), \mathcal{A})}(\text{pk}_{0}, \text{pk}_1) \end{array} \right] - \frac{1}{2} \right| \\ = \text{Adv}_{\mathcal{A}}^{\text{PayPse}} \le \text{negl}(\lambda). $$

**Unlinkability.** For any PPT adversary $\mathcal{A}$, it should not be possible to link payment to a user with a probability significantly different from $1/2$. $\mathcal{A}$ has access to $\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_i}, \cdot), \mathcal{A}(\cdot))$ oracle for $i \in \{0, 1\}$. An anonymous payment scheme ensures Unlinkability if, for any $1^\lambda$,

$$ \left| \Pr \left[ \begin{array}{l} (\text{sk}_i, \text{pk}_i)_{i \in \{0,1\}} \stackrel{\$}{\leftarrow} \text{KeyGen}(1^\lambda) \\ \mathcal{A}^{\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_i}), \mathcal{A})}_{i \in \{0,1\}}(\text{pk}_0, \text{pk}_1) \\ b \stackrel{\$}{\leftarrow} \{0,1\} \qquad : b = b^* \\ \text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_b}), \mathcal{A}(\cdot)) \\ b^* \leftarrow \mathcal{A}(\cdot) \end{array} \right] - \frac{1}{2} \right| \\ = \text{Adv}_{\mathcal{A}}^{\text{PayUnl}} \le \text{negl}(\lambda). $$

In this paper, we do not cover how to plug anonymous payment formally, since deciding which payment protocol to use is highly dependent of the context where our ticketing system is deployed. One straightforward yet inefficient payment method that maintains user anonymity is through a one-time payment card like PaySafeCard [40], purchasable locally with physical currency. Blockchain based methods such as Monero [44] provides payment unlinkability and pseudonymity using one-time payment identity in a sense that may differ slightly from our definitions. Another example uses cash or its digital counterpart like CashApp [8], where payments are executed using randomly generated identifiers. Anonymous transferable e-cash [3] also matches our requirements, providing a solution to exchange anonymously coins between users. EMV specification for Tokenization [18] provides pseudonymity, but falls short in providing unlinkability. It is uncertain if the current card system would allow anonymity. Our protocol, which are fully described later, benefits from reductions from their anonymity to the anonymity of the payment scheme. Therefore, they are as anonymous as the payment method used when they are deployed.

# 5 DESCRIPTION OF APPLAUSE

In the protocol, the participants interact using personal encryption keys $(\text{sk}^E, \text{pk}^E)$ and signature keys $(\text{sk}^S, \text{pk}^S)$ and proceed to payment using dedicated keys. A shared state $\text{st}$ is updated by the ticket distributor $\mathcal{D}$, the transfer authority $\mathcal{T}$ and the validator $\mathcal{V}$, acting as a blacklist. To purchase a ticket through Purchase, the user first selects an event and a free seat (ide, idp), and it also draws a nonce $r_c$. It obtains a signature $\sigma_c$ on the hash of the triple (ide, idp, $r_c$). The nonce $r_c$ and the signature $\sigma_c$ represent the ticket of the client. The ticket validation process involves the showing of these two values to the validator and the agreement on a challenge value through a physical channel to authenticate the ticket owner. The first showing is similar to the Refund process before the client is given back its funds or during the Transfer, as the transfer authority $\mathcal{T}$ refunds the owner of the ticket, and performs the ticket purchase protocol with the new owner of the ticket.

**Our E-Ticket Scheme.** In Fig. 5b, we present the diagram for the Refund protocol. In Fig. 5c, we present the diagram for the Validate protocol. Finally, in Fig. 6, we present the diagram for the Transfer protocol. The diagrams present the non-auditable version of Applause. We first introduce a KeyGen algorithm:

$\text{KeyGen}(1^\lambda)$: Generates signature keys $(\text{sk}^S, \text{pk}^S) \leftarrow \text{S.KeyGen}(1^\lambda)$, encryption keys $(\text{sk}^E, \text{pk}^E) \leftarrow \text{E.KeyGen}(1^\lambda)$, payment keys $(\text{sk}^P, \text{pk}^P) \leftarrow \text{P.KeyGen}(1^\lambda)$, and return $(\text{sk} \leftarrow (\text{sk}^S, \text{sk}^E, \text{sk}^P), \text{pk} \leftarrow (\text{pk}^S, \text{pk}^E, \text{pk}^P))$.

We are now ready to introduce the different key generation algorithms for the parties involved in our protocol:

$\text{DKeyGen}(1^\lambda)$: Outputs $(\text{sk}_\mathcal{D}, \text{pk}_\mathcal{D}) \leftarrow \text{KeyGen}(1^\lambda)$.

$\text{TKeyGen}(1^\lambda)$: Outputs $(\text{sk}_\mathcal{T}, \text{pk}_\mathcal{T}) \leftarrow \text{KeyGen}(1^\lambda)$.

$\text{UKeyGen}(1^\lambda)$: Outputs $(\text{sk}_U, \text{pk}_U) \leftarrow \text{KeyGen}(1^\lambda)$.

$\text{VKeyGen}(1^\lambda)$: Generates the key pair $(\text{sk}_V^S, \text{pk}_V^S) \leftarrow \text{S.KeyGen}(1^\lambda)$, and an encryption key pair $(\text{sk}_V^E, \text{pk}_V^E) \leftarrow \text{E.KeyGen}(1^\lambda)$. Queries the signature $\text{Sign}_{\text{sk}_V^S}(\text{pk}_V^S, \text{pk}_V^E) \to \text{cert}_V$ to $\mathcal{D}$
achieve Correctness of the algorithms, and Existential Unforgeability under Chosen Message Attacks (EUF-CMA) against any PPT algorithm $\mathcal{A}$. The probability of breaking EUF-CMA for an adversary $\mathcal{A}$ is given by $\text{Adv}_{\mathcal{EUF-CMA}}^\mathcal{A}$ and must be negligible. We stress that a signature does not provide access to the associated message. For both encryption and signature, we require the algorithm $\text{RandKey}(\text{sk}, \text{pk}) \to (\text{sk}^\prime, \text{pk}^\prime)$ allowing to randomise a key pair. Using discrete log based keys $\text{pk} \leftarrow g^{\text{sk}}$ for some prime order group generator $g$, the randomisable key mechanism can be seen as $\text{RandKey}(\text{sk}, \text{pk}) \to (\text{sk} \cdot r, \text{pk}^\prime)$ for a $r$ randomly sampled at uniform $(r \stackrel{\$}{\leftarrow} G$ denotes a uniform sample of $r$ from the set $G)$. In many cases this is the same as generating a new key.

Ticket purchasing, transferring, and refunding necessitate payments. However, conventional online payment methods (such as card payments based on the EMV protocol [17]) disclose the user's identity, posing a challenge to ensure user anonymity in a ETS setting. Therefore, the anonymity within a ETS protocol is contingent on the anonymity provided by the underlying payment protocol. Rather than omitting the payment process, as observed in [25], we've opted to incorporate the payment protocol. Specifically, to maintain user anonymity, the incorporated payment, termed Anonymous Payment and utilized as a foundational component, must enable participants to make payments without disclosing their identities. This building block is voluntary generic to let any anonymous payment method, to be plugged in our protocol. Our generic description for Payment Schemes PS comprises the PPT algorithms: $\text{KeyGen}(1^\lambda)$: Generate the key pair $(\text{sk}, \text{pk})$.

$\text{Pay}(\mathcal{U}_1(\text{sk}_{\mathcal{U}_1}), \mathcal{U}_2(\text{sk}_{\mathcal{U}_2})) \to \mathcal{U}_1(b), \mathcal{U}_2(b)$: User $\mathcal{U}_1$ performs a payment to $\mathcal{U}_2$. At the end, a success bit $b$ is returned.

For the sake of our demonstration and to facilitate our security reduction without mandating a specific payment method, we employ two generic definitions for Unlinkability, which ensures that two transactions from the same payee aren't linked, and Pseudonymity, which ensure that payee's identity remains undisclosed.

**Pseudonymity.** For any PPT adversary $\mathcal{A}$, it should not be possible to predict the user $\mathcal{U}_b$, for $b \in \{0, 1\}$, proceeding to a payment, with a probability significantly different from $1/2$. $\mathcal{A}$ has access to a $\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_b}, \cdot), \mathcal{A}(\cdot))$ oracle. Anonymous payment ensures pseudonymity if, for any $1^\lambda$,

$$ \left| \Pr \left[ \begin{array}{l} (\text{sk}_i, \text{pk}_i)_{i \in \{0,1\}} \stackrel{\$}{\leftarrow} \text{KeyGen}(1^\lambda) \\ b \stackrel{\$}{\leftarrow} \{0,1\} \qquad : b = b^* \\ b^* \leftarrow \mathcal{A}^{\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_b}), \mathcal{A})}(\text{pk}_{0}, \text{pk}_1) \end{array} \right] - \frac{1}{2} \right| \\ = \text{Adv}_{\mathcal{A}}^{\text{PayPse}} \le \text{negl}(\lambda). $$

**Unlinkability.** For any PPT adversary $\mathcal{A}$, it should not be possible to link payment to a user with a probability significantly different from $1/2$. $\mathcal{A}$ has access to $\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_i}, \cdot), \mathcal{A}(\cdot))$ oracle for $i \in \{0, 1\}$. An anonymous payment scheme ensures Unlinkability if, for any $1^\lambda$,

$$ \left| \Pr \left[ \begin{array}{l} (\text{sk}_i, \text{pk}_i)_{i \in \{0,1\}} \stackrel{\$}{\leftarrow} \text{KeyGen}(1^\lambda) \\ \mathcal{A}^{\text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_i}), \mathcal{A})}_{i \in \{0,1\}}(\text{pk}_0, \text{pk}_1) \\ b \stackrel{\$}{\leftarrow} \{0,1\} \qquad : b = b^* \\ \text{Pay}(\mathcal{C}(\text{sk}_{\mathcal{U}_b}), \mathcal{A}(\cdot)) \\ b^* \leftarrow \mathcal{A}(\cdot) \end{array} \right] - \frac{1}{2} \right| \\ = \text{Adv}_{\mathcal{A}}^{\text{PayUnl}} \le \text{negl}(\lambda). $$

In this paper, we do not cover how to plug anonymous payment formally, since deciding which payment protocol to use is highly dependent of the context where our ticketing system is deployed. One straightforward yet inefficient payment method that maintains user anonymity is through a one-time payment card like PaySafeCard [40], purchasable locally with physical currency. Blockchain based methods such as Monero [44] provides payment unlinkability and pseudonymity using one-time payment identity in a sense that may differ slightly from our definitions. Another example uses cash or its digital counterpart like CashApp [8], where payments are executed using randomly generated identifiers. Anonymous transferable e-cash [3] also matches our requirements, providing a solution to exchange anonymously coins between users. EMV specification for Tokenization [18] provides pseudonymity, but falls short in providing unlinkability. It is uncertain if the current card system would allow anonymity. Our protocol, which are fully described later, benefits from reductions from their anonymity to the anonymity of the payment scheme. Therefore, they are as anonymous as the payment method used when they are deployed.

# 5 DESCRIPTION OF APPLAUSE

In the protocol, the participants interact using personal encryption keys $(\text{sk}^E, \text{pk}^E)$ and signature keys $(\text{sk}^S, \text{pk}^S)$ and proceed to payment using dedicated keys. A shared state $\text{st}$ is updated by the ticket distributor $\mathcal{D}$, the transfer authority $\mathcal{T}$ and the validator $\mathcal{V}$, acting as a blacklist. To purchase a ticket through Purchase, the user first selects an event and a free seat (ide, idp), and it also draws a nonce $r_c$. It obtains a signature $\sigma_c$ on the hash of the triple (ide, idp, $r_c$). The nonce $r_c$ and the signature $\sigma_c$ represent the ticket of the client. The ticket validation process involves the showing of these two values to the validator and the agreement on a challenge value through a physical channel to authenticate the ticket owner. The first showing is similar to the Refund process before the client is given back its funds or during the Transfer, as the transfer authority $\mathcal{T}$ refunds the owner of the ticket, and performs the ticket purchase protocol with the new owner of the ticket.

**Our E-Ticket Scheme.** In Fig. 5b, we present the diagram for the Refund protocol. In Fig. 5c, we present the diagram for the Validate protocol. Finally, in Fig. 6, we present the diagram for the Transfer protocol. The diagrams present the non-auditable version of Applause. We first introduce a KeyGen algorithm:

$\text{KeyGen}(1^\lambda)$: Generates signature keys $(\text{sk}^S, \text{pk}^S) \leftarrow \text{S.KeyGen}(1^\lambda)$, encryption keys $(\text{sk}^E, \text{pk}^E) \leftarrow \text{E.KeyGen}(1^\lambda)$, payment keys $(\text{sk}^P, \text{pk}^P) \leftarrow \text{P.KeyGen}(1^\lambda)$, and return $(\text{sk} \leftarrow (\text{sk}^S, \text{sk}^E, \text{sk}^P), \text{pk} \leftarrow (\text{pk}^S, \text{pk}^E, \text{pk}^P))$.

We are now ready to introduce the different key generation algorithms for the parties involved in our protocol:

$\text{DKeyGen}(1^\lambda)$: Outputs $(\text{sk}_\mathcal{D}, \text{pk}_\mathcal{D}) \leftarrow \text{KeyGen}(1^\lambda)$.

$\text{TKeyGen}(1^\lambda)$: Outputs $(\text{sk}_\mathcal{T}, \text{pk}_\mathcal{T}) \leftarrow \text{KeyGen}(1^\lambda)$.

$\text{UKeyGen}(1^\lambda)$: Outputs $(\text{sk}_U, \text{pk}_U) \leftarrow \text{KeyGen}(1^\lambda)$.

$\text{VKeyGen}(1^\lambda)$: Generates the key pair $(\text{sk}_V^S, \text{pk}_V^S) \leftarrow \text{S.KeyGen}(1^\lambda)$, and an encryption key pair $(\text{sk}_V^E, \text{pk}_V^E) \leftarrow \text{E.KeyGen}(1^\lambda)$. Queries the signature $\text{Sign}_{\text{sk}_V^S}(\text{pk}_V^S, \text{pk}_V^E) \to \text{cert}_V$ to $\mathcal{D}$
<figure><img src="image_4.png" /><figcaption>Figure 5: Diagram of sequences for Purchase, Refund and Validate protocols.</figcaption></figure>

<figure><img src="image_5.png" /><figcaption>Figure 6: Diagram of sequences for the Transfer protocol.</figcaption></figure>

on $pk_{\mathcal{V}}^E$. Set and return $sk_{\mathcal{V}} \leftarrow (sk_{\mathcal{V}}^S, sk_{\mathcal{V}}^E)$, $pk_{\mathcal{V}} \leftarrow (pk_{\mathcal{V}}^S, pk_{\mathcal{V}}^E, cert_{\mathcal{V}})$.

Before purchasing a ticket, a user chooses the event of the ticket denoted by ide $\leftarrow$ ID<sub>E</sub>, and a serial or seat number idp $\leftarrow$ ID<sub>P</sub>.

Purchase($\mathcal{U}(sk_q, (ide, idp)), \mathcal{D}(sk_D, st)$): $\mathcal{U}$ samples $r_c \stackrel{s}{\leftarrow} \{0, 1\}^\lambda$.

Then it sends $\text{Enc}_{pk_{\mathcal{D}}^{E}}(ide, idp, r_c)$ to the ticket distributor $\mathcal{D}$, which decrypts the message. After checking that the pair $(idp, ide)$ has not been purchased before, $\mathcal{D}$ computes $c \leftarrow H(ide, idp, r_c)$, then sets $st \leftarrow st \cup \{c\}$ and signs $\sigma_c \leftarrow \text{Sign}_{sk_{\mathcal{D}}^{S}}(c)$, before sending $\sigma_c$ to $\mathcal{U}$. Once $\mathcal{U}$ verified the signature, $\mathcal{U}$ pays with $\text{Pay}(\mathcal{U}(sk_q^P), \mathcal{D}(sk_D^P)) \to \mathcal{U}(b), \mathcal{D}(b)$. If the payment works (i.e., $b$ equals 1) then $\mathcal{U}$ returns $b$ and $tk = ((ide, idp, r_c), \sigma_c)$. Finally, $\mathcal{D}$ updates the shared state $st$: if $b=1$, $st \leftarrow st \setminus \{c\}$ and returns $b$ and $st$.

For clarity, we describe the CheckTk subroutine:

CheckTk(tk, st): Parses tk $\xrightarrow{p}$ ((ide, idp, $r_c$), $\sigma_c$) ($\xrightarrow{p}$ denotes the parsing), gets $c \leftarrow H(ide, idp, $r_c$) and verifies $\text{Verif}_{pk_{\mathcal{D}}^S}(c, \sigma_c)$ or $\text{Verif}_{pk_{\mathcal{D}}^S}(c, \sigma_c)$. Checks that $c$ is not a blacklisted ticket (i.e., $c \notin st$). If all pass, it sets $st \leftarrow st \cup \{c\}$ and returns $st$.

Refund($\mathcal{U}(sk_q, tk), \mathcal{D}(sk_D, st)$): $\mathcal{U}$ starts by sending $\text{Enc}_{pk_{\mathcal{D}}^{E}}(tk)$ to $\mathcal{D}$. After the decryption, $\mathcal{D}$ checks the validity of the received ticket by executing CheckTk(tk, $st$) $\to$ $st$. Both participants start a refund (i.e., a payment with a negative amount) using $\text{Pay}(\mathcal{U}(sk_q^P), \mathcal{D}(sk_D^P)) \to \mathcal{U}(b), \mathcal{D}(b)$. If $b=0$, $\mathcal{D}$ reverts its state to $st \leftarrow st \setminus \{c\}$. Both parties return $b$, and $\mathcal{D}$ additionally returns $st$ along tk.

The Transfer protocol assumes that user $\mathcal{U}_1$ holds the randomised public key $pk'_{\mathcal{U}_2}$ of user $\mathcal{U}_2$ and conversely.

Transfer($\mathcal{U}_1(sk'_{\mathcal{U}_1}, pk'_{\mathcal{U}_2}, tk_1), \mathcal{T}(sk_{\mathcal{T}}, st), \mathcal{U}_2(sk'_{\mathcal{U}_2}, pk'_{\mathcal{U}_1}, (ide, idp)))$:

$\mathcal{U}_1$ computes a signature $\text{Sign}_{sk_{\mathcal{U}_1}^S}(pk'_{\mathcal{U}_2}, r_c) \to \sigma_{T,1}$ and sends $(pk'_{\mathcal{U}_1}, \sigma_{T,1}, \text{Enc}_{pk_{\mathcal{T}}^S}(c, tk))$ to $\mathcal{T}$. In the meantime, $\mathcal{U}_2$ signs $\text{Sign}_{sk_{\mathcal{U}_2}^S}(pk'_{\mathcal{U}_1}) \to \sigma_{T,2}$ and sends $(pk'_{\mathcal{U}_2}, \sigma_{T,2})$ to $\mathcal{T}$. Once $\sigma_{T,1}$ and $\sigma_{T,2}$ received, $\mathcal{T}$ checks $\text{Verif}_{pk'_{\mathcal{U}_1}}((pk'_{\mathcal{U}_2}, r_c), \sigma_{T,1})$ and $\text{Verif}_{pk'_{\mathcal{U}_2}}(pk'_{\mathcal{U}_1}, \sigma_{T,2})$, and halts if it fails. Then, $\mathcal{T}$ checks the validity of the received ticket by executing the algorithm CheckTk(tk, $st$) $\to$ $st$. If $st$ is updated, $\mathcal{T}$ signs and sends the signature $\sigma_p \leftarrow \text{Sign}_{sk_{\mathcal{T}}^S}(ide, idp, pk'_{\mathcal{U}_2}, pk'_{\mathcal{U}_1})$ to $\mathcal{U}_2$. Once $\sigma_p$ is verified, $\mathcal{U}_2$ initiates the purchase of place $(ide, idp)$ with Purchase($\mathcal{U}_2(sk_{\mathcal{U}_2}, (ide, idp)), \mathcal{T}(sk_{\mathcal{T}}, st)) \to (\mathcal{U}_2(b_p, tk_2), \mathcal{T}(b_p, st))$ where $\mathcal{T}$ does not check that $(ide,idp)$ where already attributed. If $b_p$ equals 0, then $\mathcal{T}$ sets $st \leftarrow st \setminus \{c\}$ (previously added in $st$ during the CheckTk execution) and halts. Otherwise, on success, $\sigma'_p \leftarrow \text{Sign}_{sk_{\mathcal{T}}^S}(ide, idp, pk'_{\mathcal{U}_1}, pk'_{\mathcal{U}_2})$ is sent and verified by $\mathcal{U}_1$. Then $\mathcal{U}_1$ is refund by executing Refund($\mathcal{U}_1(sk_{\mathcal{U}_1}, tk_1), \mathcal{T}(sk_{\mathcal{T}}, st \setminus \{c\})) \to \mathcal{U}_1(b_r), \mathcal{T}(b_r)$ with $\mathcal{T}$. Last $\mathcal{U}_1$ returns $b_r$, $\mathcal{T}$ updates $st$ and returns $b_r$, while $\mathcal{U}_2$ returns $tk_2$. Note that between two honest users $\mathcal{U}_1$ and $\mathcal{U}_2$, the secret knowledge $tk_1$ could be simply transferred without the help of $\mathcal{T}$ [1].
<figure><img src="image_5.png" /><figcaption>Figure 5: Diagram of sequences for Purchase, Refund and Validate protocols.</figcaption></figure>

<figure><img src="image_6.png" /><figcaption>Figure 6: Diagram of sequences for the Transfer protocol.</figcaption></figure>

on $pk_{\mathcal{V}}^E$. Set and return $sk_{\mathcal{V}} \leftarrow (sk_{\mathcal{V}}^S, sk_{\mathcal{V}}^E)$, $pk_{\mathcal{V}} \leftarrow (pk_{\mathcal{V}}^S, pk_{\mathcal{V}}^E, cert_{\mathcal{V}})$.

Before purchasing a ticket, a user chooses the event of the ticket denoted by ide $\leftarrow$ ID<sub>E</sub>, and a serial or seat number idp $\leftarrow$ ID<sub>P</sub>.

Purchase($\mathcal{U}(sk_q, (ide, idp)), \mathcal{D}(sk_D, st)$): $\mathcal{U}$ samples $r_c \xleftarrow{\$} \{0, 1\}^{\lambda}$.

Then it sends $\text{Enc}_{pk_{\mathcal{D}}^{E}}(ide, idp, r_c)$ to the ticket distributor $\mathcal{D}$, which decrypts the message. After checking that the pair $(idp, ide)$ has not been purchased before, $\mathcal{D}$ computes $c \leftarrow H(ide, idp, r_c)$, then sets $st \leftarrow st \cup \{c\}$ and signs $\sigma_c \leftarrow \text{Sign}_{sk_{\mathcal{D}}^{S}}(c)$, before sending $\sigma_c$ to $\mathcal{U}$. Once $\mathcal{U}$ verified the signature, $\mathcal{U}$ pays with $\text{Pay}(\mathcal{U}(sk_q^P), \mathcal{D}(sk_D^P)) \to \mathcal{U}(b), \mathcal{D}(b)$. If the payment works (i.e., $b$ equals 1) then $\mathcal{U}$ returns $b$ and $tk = ((ide, idp, r_c), \sigma_c)$. Finally, $\mathcal{D}$ updates the shared state $st$; if $b = 1$, $st \leftarrow st \setminus \{c\}$ and returns $b$ and $st$.

For clarity, we describe the CheckTk subroutine:

$\text{CheckTk}(tk, st):$ Parses $tk \xrightarrow{p} ((ide, idp, r_c), \sigma_c)$ ($p \mapsto$ denotes the parsing), gets $c \leftarrow H(ide, idp, r_c)$ and verifies $\text{Verif}_{pk_{\mathcal{D}}^S}(c, \sigma_c)$ or $\text{Verif}_{pk_{\mathcal{D}}^S}(c, \sigma_c)$. Checks that $c$ is not a blacklisted ticket (i.e., $c \notin st$). If all pass, it sets $st \leftarrow st \cup \{c\}$ and returns $st$.

Refund($\mathcal{U}(sk_q, tk), \mathcal{D}(sk_D, st)$): $\mathcal{U}$ starts by sending $\text{Enc}_{pk_{\mathcal{D}}^{E}}(tk)$ to $\mathcal{D}$. After the decryption, $\mathcal{D}$ checks the validity of the received ticket by executing CheckTk $(tk, st) \to st$. Both participants start a refund (i.e., a payment with a negative amount) using $\text{Pay}(\mathcal{U}(sk_q^P), \mathcal{D}(sk_D^P)) \to \mathcal{U}(b), \mathcal{D}(b)$. If $b = 0$, $\mathcal{D}$ reverts its state to $st \leftarrow st \setminus \{c\}$. Both parties return $b$, and $\mathcal{D}$ additionally returns $st$ along $tk$.

The Transfer protocol assumes that user $\mathcal{U}_1$ holds the randomised public key $pk'_{\mathcal{U}_2}$ of user $\mathcal{U}_2$ and conversely.

Transfer($\mathcal{U}_1(sk'_{\mathcal{U}_1}, pk'_{\mathcal{U}_2}, tk_1), \mathcal{T}(sk_{\mathcal{T}}, st), \mathcal{U}_2(sk'_{\mathcal{U}_2}, pk'_{\mathcal{U}_1}, (ide, idp)))$:

$\mathcal{U}_1$ computes a signature $\text{Sign}_{sk_{\mathcal{U}_1}^S}(pk'_{\mathcal{U}_2}, r_c) \to \sigma_{T,1}$ and sends $(pk'_{\mathcal{U}_1}, \sigma_{T,1}, \text{Enc}_{pk_{\mathcal{T}}^S}(c, tk))$ to $\mathcal{T}$. In the meantime, $\mathcal{U}_2$ signs $\text{Sign}_{sk_{\mathcal{U}_2}^S}(pk'_{\mathcal{U}_1}) \to \sigma_{T,2}$ and sends $(pk'_{\mathcal{U}_2}, \sigma_{T,2})$ to $\mathcal{T}$. Once $\sigma_{T,1}$ and $\sigma_{T,2}$ received, $\mathcal{T}$ checks $\text{Verif}_{pk'_{\mathcal{U}_1}}((pk'_{\mathcal{U}_2}, r_c), \sigma_{T,1})$ and $\text{Verif}_{pk'_{\mathcal{U}_2}}(pk'_{\mathcal{U}_1}, \sigma_{T,2})$, and halts if it fails. Then, $\mathcal{T}$ checks the validity of the received ticket by executing the algorithm CheckTk $(tk, st) \to st$. If $st$ is updated, $\mathcal{T}$ signs and sends the signature $\sigma_p \leftarrow \text{Sign}_{sk_{\mathcal{T}}^S}(ide, idp, pk'_{\mathcal{U}_2}, pk'_{\mathcal{U}_1})$ to $\mathcal{U}_2$. Once $\sigma_p$ is verified, $\mathcal{U}_2$ initiates the purchase of place $(ide, idp)$ with Purchase($\mathcal{U}_2(sk_{\mathcal{U}_2}, (ide, idp)), \mathcal{T}(sk_{\mathcal{T}}, st)) \to (\mathcal{U}_2(b_p, tk_2), \mathcal{T}(b_p, st))$ where $\mathcal{T}$ does not check that $(ide,idp)$ where already attributed. If $b_p$ equals 0, then $\mathcal{T}$ sets $st \leftarrow st \setminus \{c\}$ (previously added in $st$ during the CheckTk execution) and halts. Otherwise, on success, $\sigma'_p \leftarrow \text{Sign}_{sk_{\mathcal{T}}^S}(ide, idp, pk'_{\mathcal{U}_1}, pk'_{\mathcal{U}_2})$ is sent and verified by $\mathcal{U}_1$. Then $\mathcal{U}_1$ is refund by executing Refund($\mathcal{U}_1(sk_{\mathcal{U}_1}, tk_1), \mathcal{T}(sk_{\mathcal{T}}, st \setminus \{c\})) \to \mathcal{U}_1(b_r), \mathcal{T}(b_r)$ with $\mathcal{T}$. Last $\mathcal{U}_1$ returns $b_r$, $\mathcal{T}$ updates $st$ and returns $b_r$, while $\mathcal{U}_2$ returns $tk_2$. Note that between two honest users $\mathcal{U}_1$ and $\mathcal{U}_2$, the secret knowledge $tk_1$ could be simply transferred without the help of $\mathcal{T}$ [1].
The validation protocol requires for its last interaction, a physical channel, to prevent relay attacks, where an active external adversary blocks the ticket in the network, and play it in the validation process. Validate($\mathcal{U}(sk_{\mathcal{V}}, \text{tk}), \mathcal{V}(sk_{\mathcal{V}}, \text{st})$: $\mathcal{V}$ starts by providing $pk_{\mathcal{V}}$ to $\mathcal{U}$, which parses the key and runs Verif$_{pk_{\mathcal{D}}^S}$($pk_{\mathcal{V}}^S, pk_{\mathcal{V}}^E$), $cert_{\mathcal{V}}$ $\rightarrow$ $b$. We abort when $b$ equals 0. Otherwise, $\mathcal{U}$ executes RandKey($sk_{\mathcal{V}}, pk_{\mathcal{U}}$) $\rightarrow$ ($sk'_{\mathcal{U}}$ $pk'_{\mathcal{U}}$) and sends the ciphertext Enc$_{pk_{\mathcal{V}}^E}$(pk'$_{\mathcal{U}}$, tk) to $\mathcal{V}$. After decryption, it executes the ticket verification CheckTk, $\text{st}$. If checks pass, $\mathcal{V}$ creates a challenge by sampling $s \stackrel{s}{\leftarrow} \{0, 1\}^{\lambda}$ and sending $\epsilon \leftarrow$ Enc$_{pk_{\mathcal{U}}^{\epsilon}}(s)$ and a signature $\sigma_s \leftarrow$ Sign$_{sk_{\mathcal{V}}^S}$($\epsilon$) to $\mathcal{U}$, who obtains $s'$ after decryption and verifying Verif$_{pk_{\mathcal{V}}^S}$($\epsilon, \sigma_s$). Then, values $s$ and $s'$ are compared through a physical channel (see validation setting in Section 2). If the verification fails, then $\mathcal{V}$ removes $c$ from $\text{st}$ i.e., $\text{st} \leftarrow \text{st} \setminus \{c\}$ and halts. Otherwise, both parties commonly return $s = s'$.

# 6 SECURITY ANALYSIS OF Applause

## Security Analysis of Applause in the Computational Model

Six properties are provided through computational arguments: correctness, unforgeability, ticket privacy, no-double-spending and anonymity, the latter being divided into pseudonymity and unlinkability. The associated games are sketched in Section 3. Below we summarise our hypothesis and arguments showing that these properties hold for Applause. We present the sketch of our proofs in this section. The full security proofs are presented in Appendix C.

**THEOREM 5.1.** Applause is correct under honest execution.

**THEOREM 5.2.** Instantiated with an EUF-CMA signature, then for every PPT $\mathcal{A}$, Applause provides unforgeability and $\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{UF}}(1^{\lambda}) \rightarrow 1] \le 2 \cdot \text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}(1^{\lambda})$.

Recall that a ticket tk is defined by ide, idp, $r_c$, $\sigma_c$ where c is the hash of ide, idp, $r_c$, and $\sigma_c$ is the signature of c under $sk_{\mathcal{D}}^S$ or $sk_{\mathcal{T}}^S$. Unforgeability of a ticket is ensured by the EUF-CMA property of the signature and the shared state st composed of invalidate tickets.

**THEOREM 5.3.** Instantiated with statistically indistinguishable randomisable keys, and an anonymous payment scheme, Applause provides pseudonymity under the following probability $|\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{PSE}}(1^{\lambda}) \rightarrow 1] - \frac{1}{2}| \le \text{Adv}_{\mathcal{A}}^{\text{PayPse}}(1^{\lambda})$ for every PPT $\mathcal{A}$.

The identity of a user $\mathcal{U}$ is represented by its public key. It is involved in the computations through its randomised key $pk'_{\mathcal{U}}$. Anonymity is ensured using the statistical indistinguishability of randomisable keys and an anonymous payment. Moreover, the numerous messages sent by $\mathcal{U}$ are unrelated to its public keys, hence unrelated to its identity. Our argument for the anonymity of $\mathcal{U}$ relies on all these facts.

**THEOREM 5.4.** Instantiated with an IND-CPA encryption scheme, for any PPT $\mathcal{A}$, Applause provides privacy under the random oracle model and the upper bound $\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{PRIV}}(1^{\lambda}) \rightarrow 1] \le 2^{-\lambda+4} \cdot \text{Adv}_{\mathcal{A}}^{\text{IND-CPA}}(1^{\lambda})$.

The privacy experiment for a ticket tk states that it is hard for an external adversary to recover tk from the transcript. In our protocol, we ensure the confidentiality of tk using an IND-CPA encryption scheme E. Recall that the adversary $\mathcal{A}$ has a read-only access to the state st using OLeakState. Then, at any time, $\mathcal{A}$ has every $c \leftarrow H(\text{ide}, \text{idp}, r_c)$ associated to each ticket. This property holds under the Random Oracle Model (ROM) assumption. Under this assumption the hash $c$ is unrelated to (ide, idp, $r_c$), meaning that $\mathcal{A}$ cannot learn any of ide, idp or $r_c$ from $c$. To prove the privacy of tk, we rely on the secrecy of $r_c$ the other values are accessible to the adversary but under the privacy of $r_c$ a full ticket cannot be recover nor used. The nonce $r_c$ is chosen uniformly at random in $\{0, 1\}^{\lambda}$, the adversary can only be guessed $r_c$ with probability $2^{-\lambda}$. Hence, $r_c$ cannot be recovered by an adversary or with a negligible probability, hence the same apply to tk.

**THEOREM 5.5.** Applause provides no-double-spending unconditionally.

The shared state st contains the hash of all tickets that have been refunded, transferred or validated, and tickets from other invalid runs. It is used to prevent a user from running the same algorithm successfully twice with the same input. The no-double-spending property is ensured by this state element. For each action, st has to be updated accordingly to serve as a blacklist. Based on the latter, the CheckTk function is used to ensure the validity of the provided ticket tk, it returns 1 under the condition that tk is not in st.

**THEOREM 5.6.** Instantiated with an anonymous payment having the property of randomisable keys, then for any PPT $\mathcal{A}$, Applause provides unlinkability under the probability $|\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{UNL}}(1^{\lambda}) \rightarrow 1] - \frac{1}{2}| \le \frac{3}{2} \cdot \text{Adv}_{\mathcal{A}}^{\text{PayUnl}}(1^{\lambda})$.

The unlinkability ensures that a transaction performed with a ticket cannot be linked to another transaction, otherwise allowing an adversary to trace actions performed by a user. In our construction, a ticket is defined by random elements and signature of either $\mathcal{D}$ or $\mathcal{T}$, that are both unlinkable to the user. The usage of randomisable keys for signature and encryption schemes in Transfer constitute an argument for the unlinkability since a randomised key cannot be related to the original one. In the proof, we show that an adversary $\mathcal{A}$ cannot distinguish between playing at experiment $\text{Exp}_{\mathcal{A}}^{\text{UNL}}$ for a given $b$ and playing at experiment $\text{Exp}_{\mathcal{A}}^{\text{UNL}}$ with $\tilde{b}$. We obtain our result by replacing key of user $\mathcal{U}_b$ with key of user $\mathcal{U}_{\tilde{b}}$. The last argument used in the proof is the unlinkability property of the anonymous payment. Without such a property, an attacker could link a transaction with the payment, breaking our definition of unlinkability. Hence, we require an unlinkable anonymous payment to ensure unlinkability.

**Standard Instantiation of our Protocol.** The security proofs, given in Appendix C.2, relies on the ROM, due to the usage of a hash function $H$ to produce the digest $c \leftarrow H(\text{ide}, \text{idp}, r_c)$. The hash function is used to link the pair (ide, idp) identifying the ticket to the user knowing $r_c$. The user being the only one able to open this commitment under the pre-image resistance of the hash function, hence the only one to identify himself as the owner of the ticket. One may prefer a protocol proven secure in the standard model.
The validation protocol requires for its last interaction, a physical channel, to prevent relay attacks, where an active external adversary blocks the ticket in the network, and play it in the validation process. Validate($\mathcal{U}(sk_{\mathcal{V}}, \text{tk}), \mathcal{V}(sk_{\mathcal{V}}, \text{st})$: $\mathcal{V}$ starts by providing $pk_{\mathcal{V}}$ to $\mathcal{U}$, which parses the key and runs Verif$_{pk_{\mathcal{V}}^S}$($pk_{\mathcal{V}}^S, pk_{\mathcal{V}}^E$), $cert_{\mathcal{V}}$ $\rightarrow$ $b$. We abort when $b$ equals 0. Otherwise, $\mathcal{U}$ executes RandKey($sk_{\mathcal{V}}, pk_{\mathcal{U}}$) $\rightarrow$ ($sk'_{\mathcal{U}}$ $pk'_{\mathcal{U}}$) and sends the ciphertext Enc$_{pk_{\mathcal{V}}^E}$(pk'$_{\mathcal{U}}$, tk) to $\mathcal{V}$. After decryption, it executes the ticket verification CheckTk, $\text{st}$. If checks pass, $\mathcal{V}$ creates a challenge by sampling $s \stackrel{s}{\leftarrow} \{0, 1\}^{\lambda}$ and sending $\epsilon \leftarrow$ Enc$_{pk_{\mathcal{U}}^{\epsilon}}(s)$ and a signature $\sigma_s \leftarrow$ Sign$_{sk_{\mathcal{V}}^S}$($\epsilon$) to $\mathcal{U}$, who obtains $s'$ after decryption and verifying Verif$_{pk_{\mathcal{V}}^S}$($\epsilon, \sigma_s$). Then, values $s$ and $s'$ are compared through a physical channel (see validation setting in Section 2). If the verification fails, then $\mathcal{V}$ removes $c$ from $\text{st}$ i.e., $\text{st} \leftarrow \text{st} \setminus \{c\}$ and halts. Otherwise, both parties commonly return $s = s'$.

# 6 SECURITY ANALYSIS OF Applause

## Security Analysis of Applause in the Computational Model

Six properties are provided through computational arguments: correctness, unforgeability, ticket privacy, no-double-spending and anonymity, the latter being divided into pseudonymity and unlinkability. The associated games are sketched in Section 3. Below we summarise our hypothesis and arguments showing that these properties hold for Applause. We present the sketch of our proofs in this section. The full security proofs are presented in Appendix C.

**THEOREM 5.1.** Applause is correct under honest execution.

**THEOREM 5.2.** Instantiated with an EUF-CMA signature, then for every PPT $\mathcal{A}$, Applause provides unforgeability and $\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{UF}}(1^{\lambda}) \rightarrow 1] \le 2 \cdot \text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}(1^{\lambda})$.

Recall that a ticket tk is defined by ide, idp, $r_c$, $\sigma_c$ where c is the hash of ide, idp, $r_c$, and $\sigma_c$ is the signature of c under $sk_{\mathcal{D}}^S$ or $sk_{\mathcal{T}}^S$. Unforgeability of a ticket is ensured by the EUF-CMA property of the signature and the shared state st composed of invalidate tickets.

**THEOREM 5.3.** Instantiated with statistically indistinguishable randomisable keys, and an anonymous payment scheme, Applause provides pseudonymity under the following probability $|\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{PSE}}(1^{\lambda}) \rightarrow 1] - \frac{1}{2}| \le \text{Adv}_{\mathcal{A}}^{\text{PayPSE}}(1^{\lambda})$ for every PPT $\mathcal{A}$.

The identity of a user $\mathcal{U}$ is represented by its public key. It is involved in the computations through its randomised key $pk'_{\mathcal{U}}$. Anonymity is ensured using the statistical indistinguishability of randomisable keys and an anonymous payment. Moreover, the numerous messages sent by $\mathcal{U}$ are unrelated to its public keys, hence unrelated to its identity. Our argument for the anonymity of $\mathcal{U}$ relies on all these facts.

**THEOREM 5.4.** Instantiated with an IND-CPA encryption scheme, for any PPT $\mathcal{A}$, Applause provides privacy under the random oracle model and the upper bound $\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{PRIV}}(1^{\lambda}) \rightarrow 1] \le 2^{-\lambda+4} \cdot \text{Adv}_{\mathcal{A}}^{\text{IND-CPA}}(1^{\lambda})$.

The privacy experiment for a ticket tk states that it is hard for an external adversary to recover tk from the transcript. In our protocol, we ensure the confidentiality of tk using an IND-CPA encryption scheme E. Recall that the adversary $\mathcal{A}$ has a read-only access to the state st using OLeakState. Then, at any time, $\mathcal{A}$ has every $c \leftarrow H(\text{ide}, \text{idp}, r_c)$ associated to each ticket. This property holds under the Random Oracle Model (ROM) assumption. Under this assumption the hash $c$ is unrelated to (ide, idp, $r_c$), meaning that $\mathcal{A}$ cannot learn any of ide, idp or $r_c$ from $c$. To prove the privacy of tk, we rely on the secrecy of $r_c$ the other values are accessible to the adversary but under the privacy of $r_c$ a full ticket cannot be recover nor used. The nonce $r_c$ is chosen uniformly at random in $\{0, 1\}^{\lambda}$, the adversary can only be guessed $r_c$ with probability $2^{-\lambda}$. Hence, $r_c$ cannot be recovered by an adversary or with a negligible probability, hence the same apply to tk.

**THEOREM 5.5.** Applause provides no-double-spending unconditionally.

The shared state st contains the hash of all tickets that have been refunded, transferred or validated, and tickets from other invalid runs. It is used to prevent a user from running the same algorithm successfully twice with the same input. The no-double-spending property is ensured by this state element. For each action, st has to be updated accordingly to serve as a blacklist. Based on the latter, the CheckTk function is used to ensure the validity of the provided ticket tk, it returns 1 under the condition that tk is not in st.

**THEOREM 5.6.** Instantiated with an anonymous payment having the property of randomisable keys, then for any PPT $\mathcal{A}$, Applause provides unlinkability under the probability $|\text{Pr}[\text{Exp}_{\mathcal{A}}^{\text{UNL}}(1^{\lambda}) \rightarrow 1] - \frac{1}{2}| \le \frac{3}{2} \cdot \text{Adv}_{\mathcal{A}}^{\text{PayUnl}}(1^{\lambda})$.

The unlinkability ensures that a transaction performed with a ticket cannot be linked to another transaction, otherwise allowing an adversary to trace actions performed by a user. In our construction, a ticket is defined by random elements and signature of either $\mathcal{D}$ or $\mathcal{T}$, that are both unlinkable to the user. The usage of randomisable keys for signature and encryption schemes in Transfer constitute an argument for the unlinkability since a randomised key cannot be related to the original one. In the proof, we show that an adversary $\mathcal{A}$ cannot distinguish between playing at experiment $\text{Exp}_{\mathcal{A}}^{\text{UNL}}$ for a given $b$ and playing at experiment $\text{Exp}_{\mathcal{A}}^{\text{UNL}}$ with $\tilde{b}$. We obtain our result by replacing key of user $\mathcal{U}_b$ with key of user $\mathcal{U}_{\tilde{b}}$. The last argument used in the proof is the unlinkability property of the anonymous payment. Without such a property, an attacker could link a transaction with the payment, breaking our definition of unlinkability. Hence, we require an unlinkable anonymous payment to ensure unlinkability.

**Standard Instantiation of our Protocol.** The security proofs, given in Appendix C.2, relies on the ROM, due to the usage of a hash function $H$ to produce the digest $c \leftarrow H(\text{ide}, \text{idp}, r_c)$. The hash function is used to link the pair (ide, idp) identifying the ticket to the user knowing $r_c$. The user being the only one able to open this commitment under the pre-image resistance of the hash function, hence the only one to identify himself as the owner of the ticket. One may prefer a protocol proven secure in the standard model.
This can be easily achieved based on the Pedersen commitment [41]: consider three generators $h, g_1, g_2$ of a group $G$ of prime order $p$ where the discrete logarithm problem is assumed to be hard. Instead of computing $c \leftarrow H(\text{id}, \text{idp}, r_c)$, commit to $c \leftarrow h^{r_c} \cdot g_1^{\text{id}_1} \cdot g_2^{\text{id}_2}$. This commitment is perfectly hiding and computationally binding. In our case, since the committed values $\text{id}_1$ and $\text{id}_2$ are already revealed, this process is computationally hiding and perfectly binding for $r_c$ under the discrete logarithm problem. Proofs for this version of Applause can be found in Appendix C.2.

### Formal Verification of Applause in Symbolic Model

ProVerif [6] version 2.04 has been used to formally verify the proposed protocol. This tool uses a process description based on the applied Π-calculus, a process calculus designed for the verification of cryptographic protocols. It has syntactical extension and is enriched with the notion of events, annotations that do not change the behavior of the protocol and which are inserted at precise locations to allow reasoning about the protocol's execution. Events allow checking reachability and correspondence properties. Reachability allows the investigation of which terms are available to the attacker and thus to check their secrecy. Correspondence properties have the following structure: "on every execution trace, the event $e_1$ is preceded by the event $e_2$". Authentication is formalised as correspondence properties. To check our authentication, for each sub-protocol and every entity $\mathcal{E}$, an event is inserted into the process to record the belief that $\mathcal{E}$ has accepted to run the protocol with another entity $\mathcal{E}'$, and another event to record the belief that $\mathcal{E}'$ has terminated a protocol run. We refer to the authentication of $\mathcal{E}'$ to $\mathcal{E}$ by $\mathcal{E}' \to \mathcal{E}$ whenever $\mathcal{E}$ believes to complete the protocol with $\mathcal{E}'$. We then refer to the mutual authentication by $\mathcal{E} \leftrightarrow \mathcal{E}'$ when $\mathcal{E}' \to \mathcal{E}$ and $\mathcal{E} \to \mathcal{E}'$. In addition to that, ProVerif can check equivalence properties. We model privacy properties as equivalence properties. All along our analysis, we consider the Dolev-Yao attacker [14] which has a complete control of the network: the attacker eavesdrops, removes, substitutes, duplicates and delays any messages. ProVerif achieves a proof for anonymity of $U_1$ and $U_2$ takes less than a minute, while ticket secrecy and mutual authentication are achieved after only one second. Our ProVerif formal verification files are available in [21].

## 7 AUDITABILITY WITH Spotlight

Applause ensures full anonymity for users. We show how to convert it into an *auditable E-ticket scheme* called Spotlight, using *auditable certificates on randomisable keys*, whose the construction of [11] is based on *Structure-preserving signatures on equivalence classes* [20]. We introduce a generic description of the algorithms for auditable certificates on randomisable keys:

* OKeyGen(1^λ): Outputs certification keys (skc, pkc).

* Certify(U(sk, pk), J(skc)). Outputs a certificate cert for pk.

* CheckCert(pkc, cert). Outputs a bit $b \in \{0, 1\}$.

* RandID(sk, pk, cert). Outputs a randomised triple (sk', pk', cert').

* Audit(skc, cert). Opens cert based on skc and recovers pk.

Spotlight relaxes user anonymity achieved in Applause. We require the possibility to randomise certificates with the keys related to this certificate, as suggested by the algorithm RandID. The main modification is to append a certificate with the previous elements

of the shared state, it is now composed of a triples $(c, cert, b)$, where $c$ is a hash, cert a certificate and $b \in \{0, 1\}$ is a bit describing the validity of the related ticket.

### 7.1 Overview of Spotlight

We start by given an highlight on the necessary modifications to apply on Applause to obtain an auditable version, giving the overall intuitions of Spotlight. The security analysis in Appendix D.

* JKeyGen(1^λ): Runs and outputs OKeyGen(1^λ) → (sk_J, pk_J).

* OKeyGen: Additionally obtains the certificate $cert_U$ from the certification algorithm Certify(U(sk_U^S, pk_U^S), J(sk_J)). It returns it as part of $pk_U$.

* Purchase: $U$ updates its signature's keys using the randomisation algorithm RandID(sk_U^S, pk_U^S, cert_U) → (sk_U^{S'}, pk_U^{S'}, cert_U'), and sends $pk_U' = (pk_U^{S'}, pk_U^{E'})$, $cert_U' = \psi = \text{Enc}_{pk_U^{E'}}(\text{id}, \text{idp}, r_c, c)$ and $\sigma_\psi = \text{Sign}_{sk_U^{S'}}(\psi)$. $\mathcal{D}$ executes the certification verification function CheckCert(pk_J, $cert_U'$) and executes Verif_{pk_U^S}(\psi, \sigma_\psi). $\mathcal{D}$ updates $st$ as $st \leftarrow st \cup \{c, cert_U', 0\}$ and inverts the bit to obtain $\{c, cert_U', 1\}$ when the ticket is paid.

* CheckTk: Additionally takes as input a certificate $cert$, executes CheckCert(pk_J, $cert$) and checks the state $(c, \cdot, 1) \in st$ instead of $c \in st$. If all verification success, then we update $(c, \cdot, 1)$ to $(c, cert, 0)$.

* Refund: $U$ updates its keys as described in Purchase and sends $pk_U', cert_U'$, $\psi = \text{Enc}_{pk_U^{E'}}(\text{tk})$, $\text{Sign}_{sk_U^S}(\psi)$ to $\mathcal{D}$ as its first message. The signature is verified and then CheckTk executed with $cert_U'$ as its additional input. In case of a payment failure, $\mathcal{D}$ reverts $(c, \cdot, 0)$ to $(c, cert_U', 1)$.

* Transfer: Both $U_1$ and $U_2$ respectively send $cert_U'_1$ and $cert_U'_2$ to $\mathcal{T}$, and verify $cert_U'_1$ and $cert_U'_2$ using CheckCert. Eventually, if Purchase failed, $\mathcal{T}$ reverts $(c, \cdot, 0)$ to $(c, cert_U', 1)$.

* Validate: $U$ updates its keys and sends $\text{Enc}_{pk_U^{E'}}(pk_U', cert_U')$, $\text{tk}$ as its first message. $\mathcal{V}$ inputs $cert_U'$ into CheckCert.

* Audit(sk_J, (\cdot, \cdot, cert)) Returns Audit(sk_J, cert) → $pk_U$.

**THEOREM 5.7.** *Based on anonymous payment, an EUF-CMA signature with randomisable keys and an IND-CPA encryption scheme, auditable certificates on randomisable keys, Spotlight ensures anonymity, unlinkability, no-double-spending, unforgeability and ticket privacy.*

### 7.2 Formal Description of Spotlight

We have chosen to present Applause based on the Random Oracle Model, we stress that the modification to push Applause from the ROM into the standard model, can be apply in Spotlight in the standard model as well. To obtain auditability, we have to modify algorithms OKeyGen, Purchase, Transfer, Refund and Validate. In order to facilitate the readability, we repeat the definition of all the algorithm.

* KeyGen(1^λ): Generates a signature keys S.KeyGen(1^λ) → (sk^S, pk^S), an encryption keys E.KeyGen(1^λ) → (sk^E, pk^E), an payment keys P.KeyGen(1^λ) → (sk^P, pk^P), outputs (sk, pk ← (sk^S, sk^E, sk^P), pk ← (pk^S, pk^E, pk^P)).
This can be easily achieved based on the Pedersen commitment [41]: consider three generators $h, g_1, g_2$ of a group $\mathbb{G}$ of prime order $p$ where the discrete logarithm problem is assumed to be hard. Instead of computing $c \leftarrow H(\text{id}, \text{idp}, r_c)$, commit to $c \leftarrow h^{r_c} \cdot g_1^{\text{id}_1} \cdot g_2^{\text{id}_2}$. This commitment is perfectly hiding and computationally binding. In our case, since the committed values $\text{id}_1$ and $\text{id}_2$ are already revealed, this process is computationally hiding and perfectly binding for $r_c$ under the discrete logarithm problem. Proofs for this version of Applause can be found in Appendix C.2.

**Formal Verification of Applause in Symbolic Model**

ProVerif [6] version 2.04 has been used to formally verify the proposed protocol. This tool uses a process description based on the applied Π-calculus, a process calculus designed for the verification of cryptographic protocols. It has syntactical extension and is enriched with the notion of events, annotations that do not change the behavior of the protocol and which are inserted at precise locations to allow reasoning about the protocol's execution. Events allow checking reachability and correspondence properties. Reachability allows the investigation of which terms are available to the attacker and thus to check their secrecy. Correspondence properties have the following structure: "on every execution trace, the event $e_1$ is preceded by the event $e_2$". Authentication is formalised as correspondence properties. To check our authentication, for each sub-protocol and every entity $\mathcal{E}$, an event is inserted into the process to record the belief that $\mathcal{E}$ has accepted to run the protocol with another entity $\mathcal{E}'$, and another event to record the belief that $\mathcal{E}'$ has terminated a protocol run. We refer to the authentication of $\mathcal{E}'$ to $\mathcal{E}$ by $\mathcal{E}' \to \mathcal{E}$ whenever $\mathcal{E}$ believes to complete the protocol with $\mathcal{E}'$. We then refer to the mutual authentication by $\mathcal{E} \leftrightarrow \mathcal{E}'$ when $\mathcal{E}' \to \mathcal{E}$ and $\mathcal{E} \to \mathcal{E}'$. In addition to that, ProVerif can check equivalence properties. We model privacy properties as equivalence properties. All along our analysis, we consider the Dolev-Yao attacker [14] which has a complete control of the network: the attacker eavesdrops, removes, substitutes, duplicates and delays any messages. ProVerif achieves a proof for anonymity of $U_1$ and $U_2$ takes less than a minute, while ticket secrecy and mutual authentication are achieved after only one second. Our ProVerif formal verification files are available in [21].

# 7 AUDITABILITY WITH Spotlight

Applause ensures full anonymity for users. We show how to convert it into an *auditable E-ticket scheme* called Spotlight, using *auditable certificates on randomisable keys*, whose the construction of [11] is based on *Structure-preserving signatures on equivalence classes* [20]. We introduce a generic description of the algorithms for auditable certificates on randomisable keys:

OKeyGen(1^λ): Outputs certification keys (skc, pkc).

Certify(U(sk, pk), J(skc)). Outputs a certificate *cert* for pk.

CheckCert(pkc, cert). Outputs a bit $b \in \{0, 1\}$.

RandID(sk, pk, cert). Outputs a randomised triple $(\text{sk}', \text{pk}', \text{cert}')$.

Audit(skc, cert). Opens *cert* based on skc and recovers pk.

Spotlight relaxes user anonymity achieved in Applause. We require the possibility to randomise certificates with the keys related to this certificate, as suggested by the algorithm RandID. The main modification is to append a certificate with the previous elements

of the shared state, it is now composed of a triples $(c, cert, b)$, where $c$ is a hash, *cert* a certificate and $b \in \{0, 1\}$ is a bit describing the validity of the related ticket.

## 7.1 Overview of Spotlight

We start by given an highlight on the necessary modifications to apply on Applause to obtain an auditable version, giving the overall intuitions of Spotlight. The security analysis in Appendix D.

JKeyGen(1^λ): Runs and outputs OKeyGen(1^λ) → (sk_J, pk_J).

UKeyGen: Additionally obtains the certificate $cert_U$ from the certification algorithm Certify($\mathcal{U}(\text{sk}_U^S, \text{pk}_U^S), \mathcal{J}(\text{sk}_J)$). It returns it as part of $\text{pk}_U$.

Purchase: $\mathcal{U}$ updates its signature's keys using the randomisation algorithm RandID($\text{sk}_U^S, \text{pk}_U^S, \text{cert}_U$) → ($\text{sk}_U^{S'}, \text{pk}_U^{S'}, \text{cert}_U'$), and sends $\text{pk}'_U = (\text{pk}_U^{S'}, \text{pk}_U^{E'})$, $\text{cert}'_U, \psi = \text{Enc}_{\text{pk}_J^E}(\text{id}, \text{idp}, r_c, c)$ and $\sigma_\psi = \text{Sign}_{\text{sk}_U^{S'}}(\psi)$. $\mathcal{D}$ executes the certification verification function CheckCert($\text{pk}_J, \text{cert}'_U$) and executes Verif$_{\text{pk}_U^S}$($\psi, \sigma_\psi$). $\mathcal{D}$ updates $st$ as $st \leftarrow st \cup \{c, \text{cert}'_U, 0\}$ and inverts the bit to obtain $\{c, \text{cert}'_U, 1\}$ when the ticket is paid.

CheckTk: Additionally takes as input a certificate *cert*, executes CheckCert($\text{pk}_J, \text{cert}$) and checks the state $(c, \cdot, 1) \in st$ instead of $c \in st$. If all verification success, then we update $(c, \cdot, 1)$ to $(c, \text{cert}, 0)$.

Refund: $\mathcal{U}$ updates its keys as described in Purchase and sends $\text{pk}'_U, \text{cert}'_U, \psi = \text{Enc}_{\text{pk}_J^E}(\text{tk}), \text{Sign}_{\text{sk}_U^S}(\psi)$ to $\mathcal{D}$ as its first message. The signature is verified and then CheckTk executed with $\text{cert}'_U$ as its additional input. In case of a payment failure, $\mathcal{D}$ reverts $(c, \cdot, 0)$ to $(c, \text{cert}'_U, 1)$.

Transfer: Both $U_1$ and $U_2$ respectively send $\text{cert}'_U_1$ and $\text{cert}'_U_2$ to $\mathcal{T}$, and verify $\text{cert}'_U_1$ and $\text{cert}'_U_2$ using CheckCert. Eventually, if Purchase failed, $\mathcal{T}$ reverts $(c, \cdot, 0)$ to $(c, \text{cert}'_U_1, 1)$.

Validate: $\mathcal{U}$ updates its keys and sends $\text{Enc}_{\text{pk}_J^E}(\text{pk}'_U, \text{cert}'_U, \text{tk})$ as its first message. $\mathcal{V}$ inputs $\text{cert}'_U$ into CheckCert.

Audit(sk_J, (\cdot, \cdot, cert)) Returns Audit(sk_J, cert) → $\text{pk}_U$.

**THEOREM 5.7.** *Based on anonymous payment, an EUF-CMA signature with randomisable keys and an IND-CPA encryption scheme, auditable certificates on randomisable keys, Spotlight ensures anonymity, unlinkability, no-double-spending, unforgeability and ticket privacy.*

## 7.2 Formal Description of Spotlight

We have chosen to present Applause based on the Random Oracle Model, we stress that the modification to push Applause from the ROM into the standard model, can be apply in Spotlight in the standard model as well. To obtain auditability, we have to modify algorithms OKeyGen, Purchase, Transfer, Refund and Validate. In order to facilitate the readability, we repeat the definition of all the algorithm.

KeyGen(1^λ): Generates a signature keys S.KeyGen(1^λ) → (sk^S, pk^S), an encryption keys E.KeyGen(1^λ) → (sk^E, pk^E), an payment keys P.KeyGen(1^λ) → (sk^P, pk^P), outputs (sk, pk, sk^S, sk^E, sk^P), pk ← (pk^S, pk^E, pk^P)).
JKeyGen(1$^{\lambda}$): Returns OKeyGen(1$^{\lambda}$) → (sk$_{J}$, pk$_{J}$).

DKeyGen(1$^{\lambda}$): Returns (sk$_{D}$, pk$_{D}$) ← KeyGen(1$^{\lambda}$).

TKeyGen(1$^{\lambda}$): Returns (sk$_{T}$, pk$_{T}$) ← KeyGen(1$^{\lambda}$).

UKeyGen(1$^{\lambda}$): computes ((sk'_{U}, sk'_{U}'), (pk'_{U}, pk'_{U}')) ← KeyGen(1$^{\lambda}$), and then obtains a certificate *cert*<sub>U</sub> from the certification
Certify(U(sk'_{U}, pk'_{U}), J(sk<sub>J</sub>)) the certification algorithm
and returns (sk = (sk'_{U}, sk'_{U}), pk<sub>U</sub> = (pk'_{U}, pk'_{U}, cert<sub>U</sub>)).

VKeyGen(1$^{\lambda}$): Generates S.KeyGen(1$^{\lambda}$) → (sk_S^U, pk_S^U) a signature
key pair, and E.KeyGen(1$^{\lambda}$) → (sk_E^U, pk_E^U) an encryption
key pair. It obtains the signature Sign_{sk_S^U}(pk_S^U, pk_E^U) →
cert_V querying D to produce a certificate on its key. Re-
turns sk_V ← (sk_S^U, sk_E^U), pk_V ← (pk_S^U, pk_E^U, cert_V).

Purchase(U(sk<sub>U</sub>, (ide, idp)), D(sk<sub>D</sub>, st)): U updates its signature's keys using the randomization algorithm RandID(sk<sub>U</sub><sup>S</sup>, pk<sub>U</sub><sup>S</sup>, cert<sub>U</sub>) → (sk<sub>U</sub><sup>S'</sup>, pk<sub>U</sub><sup>S'</sup>, cert<sub>U</sub><sup>'</sup>). It samples r<sub>c</sub> ← {0, 1}<sup>λ</sup>. Then it sends pk'<sub>U</sub> = (pk<sub>U</sub><sup>S'</sup>, pk<sub>U</sub><sup>E'</sup>), cert'<sub>U</sub>, ψ = Enc<sub>pk<sub>S</sub><sup>E</sup><sub>D</sub></sub> (ide, idp, r<sub>c</sub>) and σ<sub>ψ</sub> = Sign<sub>sk<sub>S</sub><sup>S'</sup><sub>U</sub></sub>(ψ). D starts by checking that the pair (ide, ide) has no been purchased. Then, D computes c ← H(ide, idp, r<sub>c</sub>) and executes the certification verification algorithm CheckCert(pkc, cert'<sub>U</sub>) and also verifies Verif<sub>pk<sub>S</sub><sup>S</sup><sub>U</sub></sub>(ψ, σ<sub>ψ</sub>). D updates its state st ← st ∪ {c, cert'<sub>U</sub> 0} signs σ<sub>c</sub> ← Sign<sub>sk<sub>S</sub><sup>S</sup><sub>D</sub></sub>(c), before sending σ<sub>c</sub> to U. Once the signature verified, U pays with Pay(U(sk<sub>U</sub><sup>P</sup>, D(sk<sub>D</sub><sup>P</sup>))) → U(b), D(b). If the payment successful (i.e., b equals 1) then U returns b and the ticket tk ← ((ide, idp, r<sub>c</sub>), σ<sub>c</sub>), D returns b and an updated state st ← st ∪ {c, cert'<sub>U</sub> 1}.

CheckTk(tk, st, cert): P解析 tk $\xrightarrow{p}$ ((ide, idp, r_c), σ_c), 计算 c $\leftarrow$
H(ide, idp, r_c) 并验证如果该 signature 是 valid 由 execut-
ing Verif<sub>pk<sub>S</sub><sup>S</sup><sub>D</sub></sub>(c, σ_c) 或 Verif<sub>pk<sub>S</sub><sup>S</sup><sub>D</sub></sub>(c, σ_c) 验证。Also verify the
certificate by executing CheckCert(pk<sub>J</sub>, cert) Then, checks
that c 是 not a blacklisted ticket i.e., (c, ·, 1) ∈ st. If all passes,
it updates (c, ·, 1) to (c, cert, 0) and returns st.

Refund(U(sk<sub>U</sub>, tk), D(sk<sub>D</sub>, st)): U executes RandID(sk<sub>U</sub><sup>S</sup>, pk<sub>U</sub><sup>S</sup>, cert<sub>U</sub>) → (sk<sub>U</sub><sup>S'</sup>, pk<sub>U</sub><sup>S'</sup>, cert<sub>U</sub>) and sends pk'<sub>U</sub>, cert'<sub>U</sub>, ψ = Enc<sub>pk<sub>S</sub><sup>E</sup><sub>D</sub></sub>(tk), Sign<sub>sk<sub>S</sub><sup>S'</sup><sub>U</sub></sub>(ψ) to D as its first message. After the decryption and verification of the signature D checks the received ticket using CheckTk(tk, st, cert'<sub>U</sub>) → st.

Both participants starts a refund (i.e., a payment with a negative amount) using Pay(U(sk<sub>U</sub><sup>P</sup>, D(sk<sub>D</sub><sup>P</sup>))) → U(b), D(b).

If b = 0, D reverts its state by updating (c, ·, 0) to (c, cert'<sub>U</sub> 1).

Both parties return b, and D additionally returns st and tk.

Transfer(U₁(sk'U₁, tk₁, pk'U₂), T(skT, st), U₂(sk'U₂, pk'U₁, (ide, idp)))
U₁ computes the signature Sign<sub>sk<sub>S</sub><sup>S'</sup><sub>U</sub></sub>(pk'U₂, r<sub>c</sub>) → σ<sub>T,1</sub> and
sends (pk'U₁, cert'U₁, σ<sub>T,1</sub>, Enc<sub>pk<sub>S</sub><sup>E</sup><sub>D</sub></sub>(c, tk)) to T. In the mean-
time, U₂ signs Sign<sub>sk<sub>S</sub><sup>S'</sup><sub>U</sub></sub>(pk'U₁) → σ<sub>T,2</sub> and sends the mes-
sage (pk'U₂, cert'U₂, σ<sub>T,2</sub>) to T. Once it received σ<sub>T,1</sub> and σ<sub>T,2</sub>,
T checks Verif<sub>pk<sub>S</sub><sup>S</sup><sub>U</sub></sub>((pk'U₂, r<sub>c</sub>), σ<sub>T,1</sub>) and Verif<sub>pk<sub>S</sub><sup>S'</sup><sub>U</sub></sub>(pk'U₁, σ<sub>T,2</sub>),

and halts any fails. Then $\mathcal{T}$ executes the certificate verification CheckCert(pk$_{J}$, cert'$_{U_2}$) and checks the validity of the received ticket with CheckTk(tk, st, cert'$_{U_1}$) → st the ticket verification algorithm. If st was updated, $\mathcal{T}$ signs $\sigma_p \leftarrow \text{Sign}_{\text{sk}_T^S}$ (ide, idp, pk'$_{U_2}$, pk'$_{U_1}$). $\sigma_p$ is transmitted to $U_2$ and verified. $U_2$ initiates the purchase for the place (ide, idp) with Purchase(U$_2$(sk$_{U_2}$, (ide, idp)), T(sk$_T$, st)) resulting to (U$_2$(b$_p$, tk$_2$), T(b$_r$, st)) where T does not check that (ide,idp) where already attributed. If b$_p$ equals 0, then T revert the state of c from (c, ·, 0) to (c, cert'$_{U_1}$, 1) (previously added in st during the CheckTk execution) and halts. Otherwise, on success, $\sigma'_p = \text{Sign}_{\text{sk}_T^S}$ (ide, idp, pk'$_{U_1}$, pk'$_{U_2}$) is sent to $U_1$, verified by $U_1$. Refund(U$_1$(sk$_{U_1}$, tk$_1$), T(sk$_T$, st \ {c})) → $U_1$(b$_r$), T(b$_r$) is executed between $U_1$ and T. Last $U_1$ returns b$_r$, T update the shared state st and returns b$_r$ along st, and $U_2$ returns tk$_2$.

Validate(U(sk<sub>U</sub>, tk), V(sk<sub>V</sub>, st)): V starts by providing pk<sub>V</sub> to U. The latter parses it and runs Verif<sub>pk<sub>S</sub><sup>S</sup><sub>D</sub></sub>(pk<sub>V</sub>, cert<sub>V</sub>) → b. On b equals 0, the protocol is aborted. Otherwise, U executes RandID(sk<sub>U</sub><sup>S</sup>, pk<sub>U</sub><sup>S</sup>, cert<sub>U</sub>) → (sk<sub>U</sub><sup>S'</sup>, pk<sub>U</sub><sup>S'</sup>, cert'<sub>U</sub>) and sends cert'<sub>U</sub>. Enc<sub>pk<sub>S</sub><sup>E</sup><sub>D</sub></sub>(pk'<sub>U</sub>, tk) to V. It decrypts the message and executes CheckTk(tk, st, cert'<sub>U</sub>). If both checks passes, V sample a challenge value s $\stackrel{s}{\leftarrow}$ {0, 1}$^{\lambda}$ and sends $\epsilon = \text{Enc}_{\text{pk}'_{\text{U}}}(s)$ and a signature $\sigma_s = \text{Sign}_{\text{sk}'_{\text{U}}}(\epsilon)$ to U who obtain s' after decryption and verifying Verif<sub>pk<sub>S</sub><sup>S</sup><sub>V</sub></sub>($\epsilon, \sigma_s$). The values s and s' are compared through a physical channel (as explained in Section 2). Both parties commonly return s = s'. If the verification has fail the V also removes c from st i.e., st $\leftarrow$ st \ {c}.

Audit(sk<sub>J</sub>, (·, ·, cert)): Returns Audit(sk<sub>J</sub>, cert) → pk<sub>J</sub>.

8 CONCLUSION

We presented Applause, a ticketing system that preserves the phys-
ical aspects of paper tickets while ensuring that any user can buy,
refund, validate, or transfer a ticket. The system additionally safe-
guards the privacy of users. Applause achieves unforgeability, no-
double-spending, privacy of the tickets, and anonymity of users. In
particular, anonymity ensured by Applause highly depends on the
anonymity property of the used payment method, that we chosen
to include in a generic fashion. We have also formally verified the
security properties of Applause using ProVerif, proving its security
in the symbolic model for an unbounded number of sessions. We
have additionally extended Applause to obtain an auditable version
called Spotlight, whereby the judge can reveal the identity of all
users, whereas other entities are unable to discern whether a user
has purchased a ticket and for which event.

ACKNOWLEDGMENTS

The authors would like to thank the anonymous reviewers for their constructive comments. This work has been partially the French BPI project D4N and by the SEVERITAS project ANR-20-CE39-0009.
JKeyGen(1$^{\lambda}$): Returns OKeyGen(1$^{\lambda}$) → (sk$_{J}$, pk$_{J}$).

DKeyGen(1$^{\lambda}$): Returns (sk$_{D}$, pk$_{D}$) ← KeyGen(1$^{\lambda}$).

TKeyGen(1$^{\lambda}$): Returns (sk$_{T}$, pk$_{T}$) ← KeyGen(1$^{\lambda}$).

UKeyGen(1$^{\lambda}$): computes ((sk'_{U}, sk'_{U}'), (pk'_{U}, pk'_{U}')) ← KeyGen(1$^{\lambda}$), and then obtains a certificate *certU* from the certification
Certify(U(sk'_{U}, pk'_{U}), J(sk_{J})) the certification algorithm
and returns (sk = (sk'_{U}, sk'_{U}), pkU = (pk'_{U}, pk'_{U}, certU)).

VKeyGen(1$^{\lambda}$): Generates S.KeyGen(1$^{\lambda}$) → (sk_S^U, pk_S^U) a signature
key pair, and E.KeyGen(1$^{\lambda}$) → (sk_E^U, pk_E^U) an encryption
key pair. It obtains the signature Sign_{sk_S^U}(pk_S^U, pk_E^U) →
cert_V querying D to produce a certificate on its key. Re-
turns sk_V ← (sk_S^U, sk_E^U), pk_V ← (pk_S^U, pk_E^U, cert_V).

Purchase(U(sk_q, (ide, idp)), D(sk_D, st)): U updates its signature's keys using the randomization algorithm RandID(sk_S^U, pk_S^U, cert_U) → (sk_S^U, pk_S^U, cert'_U). It samples r_c ← {0, 1}^λ. Then it sends pk'_U = (pk_S^U, pk'_U), cert'_U, ψ = Enc_{pk_S^U}(ide, idp, r_c) and σ_ψ = Sign_{sk_S^U}(ψ). D starts by checking that the pair (ide, idp) has no been purchased. Then, D computes c ← H(ide, idp, r_c) and executes the certification verification algorithm CheckCert(pk_c, cert'_U) and also verifies Verif_{pk'_U}(ψ, σ_ψ). D updates its state st ← st ∪ {c, cert'_U} signs σ_c ← Sign_{sk_S^D}(c), before sending σ_c to U. Once the signature verified, U pays with Pay(U(sk_P^U), D(sk_P^D)) → U(b), D(b). If the payment successful (i.e., b equals 1) then U returns b and the ticket tk ← ((ide, idp, r_c), σ_c), D returns b and an updated state st ← st ∪ {c, cert'_U, 1}.

CheckTk(tk, st, cert): Parses tk $\xrightarrow{p}$ ((ide, idp, r_c), σ_c), computes c $\leftarrow$
H(ide, idp, r_c) and verifies if the signature is valid by execut-
ing Verif$_{pk_S^D}$(c, σ_c) or Verif$_{pk_S^D}$(c, σ_c) validate. Also verify the
certificate by executing CheckCert(pk$_J$, cert) Then, checks
that c is not a blacklisted ticket i.e., (c, ·, 1) ∈ st. If all passes,
it updates (c, ·, 1) to (c, cert, 0) and returns st.

Refund(U(sk_q, tk), D(sk_D, st)): U executes RandID(sk_S^U, pk_S^U, cert_U) → (sk_S^U, pk_S^U, cert'_U) and sends pk'_U, cert'_U, ψ = Enc_{pk_S^U}(tk), Sign_{sk_S^U}(ψ) to D as its first message. After the decryption and verification of the signature D checks the received ticket using CheckTk(tk, st, cert'_U) → st.

Both participants starts a refund (i.e., a payment with a negative amount) using Pay(U(sk_P^U), D(sk_P^D)) → U(b), D(b). If b = 0, D reverts its state by updating (c, ·, 0) to (c, cert'_U, 1). Both parties return b, and D additionally returns st and tk.

Transfer(U₁(sk'U₁, tk₁, pk'U₂), T(skT, st), U₂(sk'U₂, pk'U₁, (ide, idp)))

U₁ computes the signature Sign_{sk_S^U}(pk'_{U_2}, r_c) → σ_{T,1} and sends (pk'_{U_1}, cert'_{U_1}, σ_{T,1}, Enc_{pk_S^U}(c, tk)) to T. In the meantime, U₂ signs Sign_{sk_S^U}(pk'_{U_1}) → σ_{T,2} and sends the message (pk'_{U_2}, cert'_{U_2}, σ_{T,2}) to T. Once it received σ_{T,1} and σ_{T,2}, T checks Verif_{pk_S^U}(pk'_{U_2}, r_c), σ_{T,1}) and Verif_{pk_S^U}(pk'_{U_2}, σ_{T,2}),

and halts any fails. Then $\mathcal{T}$ executes the certificate verification CheckCert(pk$_J$, cert'$_{U_2}$) and checks the validity of the received ticket with CheckTk(tk, st, cert'$_{U_1}$) → st the ticket verification algorithm. If st was updated, $\mathcal{T}$ signs $\sigma_p \leftarrow \text{Sign}_{\text{sk}_T^S}$ (ide, idp, pk'$_{U_2}$, pk'$_{U_1}$). $\sigma_p$ is transmitted to $\mathcal{U}_2$ and verified. $\mathcal{U}_2$ initiates the purchase for the place (ide, idp) with Purchase($\mathcal{U}_2(\text{sk}_{U_2}, (\text{ide}, \text{idp})), \mathcal{T}(\text{sk}_T, \text{st})$) resulting to $(\mathcal{U}_2(b_p, tk_2), \mathcal{T}(b_p, st))$ where $\mathcal{T}$ does not check that (ide,idp) where already attributed. If $b_p$ equals 0, then $\mathcal{T}$ revert the state of $c$ from $(c, \cdot, 0)$ to $(c, \text{cert}'_{\mathcal{U}_1}, 1)$ (previously added in st during the CheckTk execution) and halts. Otherwise, on success, $\sigma'_p = \text{Sign}_{\text{sk}_T^S}$ (ide, idp, pk'$_{U_1}$, pk'$_{U_2}$) is sent to $\mathcal{U}_1$, verified by $\mathcal{U}_1$. Refund$(\mathcal{U}_1(\text{sk}_{U_1}, tk_1), \mathcal{T}(\text{sk}_T, \text{st} \setminus \{c\})) \to \mathcal{U}_1(b_r), \mathcal{T}(b_r)$ is executed between $\mathcal{U}_1$ and $\mathcal{T}$. Last $\mathcal{U}_1$ returns $b_r$, $\mathcal{T}$ update the shared state st and returns $b_r$ along st, and $\mathcal{U}_2$ returns $tk_2$.

Validate(U(sk_q, tk), V(sk_V, st)): V starts by providing pk_V to U. The latter parses it and runs Verif_{pk_S^D}(pk_V, cert_V) → b. On b equals 0, the protocol is aborted. Otherwise, U executes RandID(sk_S^U, pk_S^U, cert_U) → (sk_S^U, pk_S^U, cert'_U) and sends cert'_U. Enc_{pk_V}(pk'_U, tk) to V. It decrypts the message and executes CheckTk(tk, st, cert'_U). If both checks passes, V sample a challenge value s $\stackrel{s}{\leftarrow}$ {0, 1}$^{\lambda}$ and sends $\epsilon = \text{Enc}_{\text{pk}_U^{\epsilon}}(s)$ and a signature $\sigma_s = \text{Sign}_{\text{sk}_V^s}(\epsilon)$ to U who obtain s' after decryption and verifying Verif_{pk_S^U}(\epsilon, \sigma_s). The values s and s' are compared through a physical channel (as explained in Section 2). Both parties commonly return s = s'. If the verification has fail the V also removes c from st i.e., st $\leftarrow$ st $\setminus$ \{c\}.

Audit(sk_J, (\cdot, \cdot, \text{cert})) : Returns Audit(sk_J, cert) → pk_U.

8 CONCLUSION

We presented Applause, a ticketing system that preserves the phys-
ical aspects of paper tickets while ensuring that any user can buy,
refund, validate, or transfer a ticket. The system additionally safe-
guards the privacy of users. Applause achieves unforgeability, no-
double-spending, privacy of the tickets, and anonymity of users. In
particular, anonymity ensured by Applause highly depends on the
anonymity property of the used payment method, that we chosen
to include in a generic fashion. We have also formally verified the
security properties of Applause using ProVerif, proving its security
in the symbolic model for an unbounded number of sessions. We
have additionally extended Applause to obtain an auditable version
called Spotlight, whereby the judge can reveal the identity of all
users, whereas other entities are unable to discern whether a user
has purchased a ticket and for which event.

ACKNOWLEDGMENTS

The authors would like to thank the anonymous reviewers for their constructive comments. This work has been partially the French BPI project D4N and by the SEVERITAS project ANR-20-CE39-0009.
REFERENCES

[1] N. Asokan, Victor Shoup, and Michael Waidner. 1998. Asynchronous protocols for optimistic fair exchange. English (US). Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, 86-99. Proceedings of the 1998 IEEE Symposium on Security and Privacy ; Conference date: 03-05-1998 Through 06-05-1998.

[2] Aventus. 2016. https://aventus.io/. (2016).

[3] Foteini Baldimtsi, Melissa Chase, Georg Fuchsbauer, and Markulf Kohlweiss. 2015. Anonymous transferable e-cash. In International Workshop on Public Key Cryptography. Springer.

[4] Balthazar Bauer, Georg Fuchsbauer, and Chen Qian. 2021. Transferable e-cash: a cleaner model and the first practical instantiation. In IACR International Conference on Public-Key Cryptography. Springer, 559-590.

[5] Osman Bicer and Alptekin Kupcu. 2019. Versatile abs: usage limited, revocable, threshold traceable, authority hiding, decentralized attribute based signatures. Cryptology ePrint Archive, Paper 2019/203. https://eprint.iacr.org/2019/203. (2019). https://eprint.iacr.org/2019/203.

[6] Bruno Blanchet. 2014. Automatic Verification of Security Protocols in the Symbolic Model: The Verifier ProVerif. In Foundations of Security Analysis and Design VII. Springer. DOI: 10.1007/978-3-319-10082-1_3

[7] Jan Camenisch, Susan Hohenberger, Markulf Kohlweiss, Anna Lysyanskaya, and Mira Meyerovich. 2006. How to win the clonewars: efficient periodic n-times anonymous authentication. In Proceedings of the 13th ACM Conference on Computer and Communications Security (CCS '06). Association for Computing Machinery, Alexandria, Virginia, USA. DOI: 10.1145/1180405.1180431.

[8] CashApp. 2018. CashApp. https://www.cash.app/. (2018).

[9] David Chaum. 1985. Security without identification: transaction systems to make big brother obsolete. Communications of the ACM, 28, 10, 1030-1044.

[10] Liqun Chen, Matthias Enzmann, Ahmad-Reza Sadeghi, Markus Schneider, and Michael Steiner. 2005. A privacy-protecting coupon system. In Financial Cryptography and Data Security: 9th International Conference, FC 2005, Roseau, The Commonwealth Of Dominica, February 28-March 3, 2005. Revised Papers 9. Springer, 93-108.

[11] Aisling Connolly, Jérôme Deschamps, Pascal Lafourcade, and Octavio Perez Kempner. 2022. Protego: efficient, revocable and auditable anonymous credentials with applications to hyperledger fabric. In International Conference on Cryptology in India. Springer, 249-271.

[12] Yao Cui, Izak Duenyas, and Özge Şahin. 2014. Should event organizers prevent resale of tickets? Management Science, 60, 9, 2160-2179.

[13] Alex de Vries. 2018. Bitcoin's growing energy problem. 2, (May 2018), 801-805. DOI: 10.1016/j.joule.2018.04.016.

[14] D. Dolev and A. Yao. 1983. On the security of public key protocols. IEEE Transactions on Information Theory. DOI: 10.1109/TIT.1983.1056650.

[15] Yuhao Dong, Ian Goldberg, Sergey Gorbunov, and Raouf Boutaba. 2022. Astrape: anonymous payment channels with boring cryptography. In International Conference on Applied Cryptography and Network Security. Springer.

[16] Taher ElGamal. 1985. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE transactions on information theory.

[17] EMVCo. 2011. Book 1: application independent icc to terminal interface requirements.

[18] LLC EMVCo. 2022. Emv payment tokenisation specification technical framework v2.3. EMVCo: Foster City, CA, USA.

[19] Shimon Even. 1983. A protocol for signing contracts. SIGACT News, 15, 1, (Jan. 1983), 34-39. DOI: 10.1145/1008908.1008913.

[20] Georg Fuchsbauer, Christian Hanser, and Daniel Slamanig. 2019. Structure-preserving signatures on equivalence classes and constant-size anonymous credentials. Journal of Cryptology.

[21] [n. d.] Git for transferable, auditable and anonymous ticketing protocol. https://gitlab.limos.fr/palafour/asiaccs-24-applause/.

[22] Ivan Gudymenko. 2013. On protection of the user's privacy in ubiquitous e-ticketing systems based on RFID and NFC technologies. In PECCS 2013 - Proceedings of the 3rd International Conference on Pervasive Embedded Computing and Communication Systems. SciTePress.

[23] Ivan Gudymenko, Felipe Sousa, and Stefan Kopsell. 2014. A simple and secure e-ticketing system for intelligent public transportation based on NFC. In The First International Conference on IoT in Urban Space, Urb-IoT. ICST. https://xxdo.i.org/10.4108/icst.urb-iot.2014.257244.

[24] N. Abdul Hamid, M. F. Al A'zhim, and M. L. Yap. 2012. E-ticketing system for football events in malaysia. In 7th International Conference for Internet Technology and Secured Transactions, ICITST. IEEE. https://ieeexplore.ieee.org/document/6470872/.

[25] Jinguang Han, Liqun Chen, Steve Schneider, Helen Treharne, and Stephan Wesemeyer. 2021. Privacy-preserving electronic ticket scheme with attribute-based credentials. IEEE Trans. Dependable Secur. Comput. https://xxdoi.org/10.1109/TDSC.2019.2940946.

[26] Wan Huzaini Wan Hussin, Paul Coulton, and Reuben Edwards. 2005. Mobile ticketing system employing trustzone technology. In International Conference

on Mobile Business. IEEE Computer Society. https://xxdoi.org/10.1109/ICMB.20 05.71.

[27] International Organization for Standardization. 2006. Information technology — automatic identification and data capture techniques — qr code 2005 bar code symbology specification. ISO/IEC 18004:2006. (2006).

[28] Florian Kerschbaum, Hoon Wei Lim, and Ivan Gudymenko. 2013. Privacy-preserving billing for e-ticketing systems in public transportation. In Proceedings of the 12th annual ACM Workshop on Privacy in the Electronic Society, WPES 2013. ACM. https://xxdoi.org/10.1145/2517840.2517848.

[29] Phillip Leslie and Alan Sorensen. 2014. Resale and rent-seeking: an application to ticket markets. Review of Economic Studies, 81, 1, 266-300.

[30] Xiaoshan Li, Zhiming Liu, and Zhensheng Guo. 2001. Formal object-oriented analysis and design of an online ticketing system. In 8th Asia-Pacific Software Engineering Conference (APSEC 2001). IEEE Computer Society. https://xxdoi.org/10.1109/APSEC.2001.991486.

[31] Xuelian Li, Jie Niu, Juntao Gao, and Yue Han. 2019. Secure electronic ticketing system based on consortium blockchain. KSII Trans. Internet Inf. Syst. https://xxdoi.org/10.3837/tiis.2019.10.022.

[32] Weiwei Liu, Yi Mu, and Guomin Yang. 2014. An efficient privacy-preserving e-coupon system. In International Conference on Information Security and Cryptology. Springer.

[33] Akash Madhusudan, Mahdi Sedaghat, Philipp Jovanovic, and Bart Preneel. 2022. Nirvana: instant and anonymous payment-guarantees. IACR Cryptol. ePrint Arch., 872.

[34] Hemanta K Maji, Manoj Prabhakaran, and Mike Rosulek. 2011. Attribute-based signatures. In Cryptographers' track at the RSA conference. Springer, 376-392.

[35] Milica Milutinovic, Koen Decroix, Vincent Naessens, and Bart De Decker. 2015. Privacy-preserving public transport ticketing system. In Data and Applications Security and Privacy- 29th Annual IFIP WG 11.3 Working Conference, DBSec. Springer. https://xxdoi.org/10.1007/978-3-319-20810-7%5C_9.

[36] Omid Mir, Daniel Slamanig, and René Mayrhofer. 2023. Threshold delegatable anonymous credentials with controlled and fine-grained delegation. IEEE Transactions on Dependable and Secure Computing.

[37] Lekshmi S. Nair, V. S. Arun, and Sijo Joseph. 2015. Secure e-ticketing system based on mutual authentication using RFID. In Proceedings of the Third International Symposium on Women in Computing and Informatics, WCI 2015. ACM. https://xxdoi.org/10.1145/2791405.2791573.

[38] Lan Nguyen. 2006. Privacy-protecting coupon system revisited. In Financial Cryptography and Data Security: 10th International Conference, FC 2006 Anguilla, British West Indies, February 27-March 2, 2006 Revised Selected Papers 10. Springer, 266-280.

[39] Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, and Carles Gomez. 2015. IPv6 over BLUETOOTH(R) Low Energy. RFC 7668. (Oct. 2015). DOI: 10.17487/RFC7668.

[40] PaySafeCard. 2018. Paysafecard. https://www.paysafecard.com/fr/. (2018).

[41] Torben Pryds Pedersen. 2001. Non-interactive and information-theoretic secure verifiable secret sharing. In Advances in Cryptology—CRYPTO'91: Proceedings. Springer, 129-140.

[42] GET Protocol. 2016. GUTS Ticketing. https://guts.tickets/. (2016).

[43] Jason Reid, Juan M Gonzalez Nieto, Tee Tang, and Bouchra Senadji. 2007. Detecting relay attacks with timing-based protocols. In Proceedings of the 2nd ACM symposium on Information, computer and communications security, 204-213.

[44] Nicolas Van Saberhagen. 2013. Monero Research Paper. (2013). https://github.c om/monero-project/research-lab/blob/master/whitepaper/whitepaper.pdf.

[45] Claus-Peter Schnorr. 1991. Efficient signature generation by smart cards. Journal of Cryptology.

[46] Johannes Sedlmeir, Hans Buhl, Gilbert Fridgen, and Robert Keller. 2020. The energy consumption of blockchain technology: beyond myth. Business & Information Systems Engineering, 62, (Dec. 2020). DOI: 10.1007/s12599-020-00656-x. Marc Sel, Stefaan Seys, and Eric R. Verheul. 2008. The security of mass transport ticketing systems. In ISSE 2008 - Securing Electronic Business Processes, Highlights of the Information Security Solutions Europe 2008 Conference. https://xxdoi.org/10.1007/978-3-8348-9283-6%5C_37.

[47] Isamu Teranishi, Jun Furukawa, and Kazue Sako. 2004. K-times anonymous authentication (extended abstract). In Advances in Cryptology - ASIACRYPT 2004. Springer.

[48] Hitesh Tewari and Arthur Hughes. 2016. Fully anonymous transferable ecash. Cryptology ePrint Archive.

[49] Minhui Xie, Mark Tomlinson, and Bobby Bodenheimer. 2004. Interface design for a modern software ticketing system. In Proceedings of Annual Southeast Regional Conference. ACM, Huntsville, Alabama. https://xxdoi.org/10.1145/986 537.986566.

[50] Yuan YuanJiang and Ji Ting Zhou. 2022. Ticketing system based on NFT. In 24th IEEE International Workshop on Multimedia Signal Processing, MMSP 2022. IEEE. https://xxdoi.org/10.1109/MMSP5362.2022.9948706.
REFERENCES

[1] N. Asokan, Victor Shoup, and Michael Waidner. 1998. Asynchronous protocols for optimistic fair exchange. English (US). Proceedings of the IEEE Computer Society Symposium on Research in Security and Privacy, 86-99. Proceedings of the 1998 IEEE Symposium on Security and Privacy ; Conference date: 03-05-1998 Through 06-05-1998.

[2] Aventus. 2016. https://aventus.io/. (2016).

[3] Foteini Baldimtsi, Melissa Chase, Georg Fuchsbauer, and Markulf Kohlweiss. 2015. Anonymous transferable e-cash. In International Workshop on Public Key Cryptography. Springer.

[4] Balthazar Bauer, Georg Fuchsbauer, and Chen Qian. 2021. Transferable e-cash: a cleaner model and the first practical instantiation. In IACR International Conference on Public-Key Cryptography. Springer, 559-590.

[5] Osman Bicer and Alptekin Kupcu. 2019. Versatile abs: usage limited, revocable, threshold traceable, authority hiding, decentralized attribute based signatures. Cryptology ePrint Archive, Paper 2019/203. https://eprint.iacr.org/2019/203. (2019). https://eprint.iacr.org/2019/203.

[6] Bruno Blanchet. 2014. Automatic Verification of Security Protocols in the Symbolic Model: The Verifier ProVerif. In Foundations of Security Analysis and Design VII. Springer. DOI: 10.1007/978-3-319-10082-1_3

[7] Jan Camenisch, Susan Hohenberger, Markulf Kohlweiss, Anna Lysyanskaya, and Mira Meyerovich. 2006. How to win the clonewars: efficient periodic n-times anonymous authentication. In Proceedings of the 13th ACM Conference on Computer and Communications Security (CCS '06). Association for Computing Machinery, Alexandria, Virginia, USA. DOI: 10.1145/1180405.1180431.

[8] CashApp. 2018. CashApp. https://www.cash.app/. (2018).

[9] David Chaum. 1985. Security without identification: transaction systems to make big brother obsolete. Communications of the ACM, 28, 10, 1030-1044.

[10] Liqun Chen, Matthias Enzmann, Ahmad-Reza Sadeghi, Markus Schneider, and Michael Steiner. 2005. A privacy-protecting coupon system. In Financial Cryptography and Data Security: 9th International Conference, FC 2005, Roseau, The Commonwealth Of Dominica, February 28-March 3, 2005. Revised Papers 9. Springer, 93-108.

[11] Aisling Connolly, Jérôme Deschamps, Pascal Lafourcade, and Octavio Perez Kempner. 2022. Protego: efficient, revocable and auditable anonymous credentials with applications to hyperledger fabric. In International Conference on Cryptology in India. Springer, 249-271.

[12] Yao Cui, Izak Duenyas, and Özge Şahin. 2014. Should event organizers prevent resale of tickets? Management Science, 60, 9, 2160-2179.

[13] Alex de Vries. 2018. Bitcoin's growing energy problem. 2, (May 2018), 801-805. DOI: 10.1016/j.joule.2018.04.016.

[14] D. Dolev and A. Yao. 1983. On the security of public key protocols. IEEE Transactions on Information Theory. DOI: 10.1109/TIT.1983.1056650.

[15] Yuhao Dong, Ian Goldberg, Sergey Gorbunov, and Raouf Boutaba. 2022. Astrape: anonymous payment channels with boring cryptography. In International Conference on Applied Cryptography and Network Security. Springer.

[16] Taher ElGamal. 1985. A public key cryptosystem and a signature scheme based on discrete logarithms. IEEE transactions on information theory.

[17] EMVCo. 2011. Book 1: application independent icc to terminal interface requirements.

[18] LLC EMVCo. 2022. Emv payment tokenisation specification technical framework v2.3. EMVCo: Foster City, CA, USA.

[19] Shimon Even. 1983. A protocol for signing contracts. SIGACT News, 15, 1, (Jan. 1983), 34-39. DOI: 10.1145/1008908.1008913.

[20] Georg Fuchsbauer, Christian Hanser, and Daniel Slamanig. 2019. Structure-preserving signatures on equivalence classes and constant-size anonymous credentials. Journal of Cryptology.

[21] [n. d.] Git for transferable, auditable and anonymous ticketing protocol. https://gitlab.limos.fr/palafour/asiaccs-24-applause/.

[22] Ivan Gudymenko. 2013. On protection of the user's privacy in ubiquitous e-ticketing systems based on RFID and NFC technologies. In PECCS 2013 - Proceedings of the 3rd International Conference on Pervasive Embedded Computing and Communication Systems. SciTePress.

[23] Ivan Gudymenko, Felipe Sousa, and Stefan Kopsell. 2014. A simple and secure e-ticketing system for intelligent public transportation based on NFC. In The First International Conference on IoT in Urban Space, Urb-IoT. ICST. https://xxdo i.org/10.4108/icst.urb-iot.2014.257244.

[24] N. Abdul Hamid, M. F. Al A'zhim, and M. L. Yap. 2012. E-ticketing system for football events in malaysia. In 7th International Conference for Internet Technology and Secured Transactions, ICITST. IEEE. https://ieeexplore.ieee.org/document/6470872/.

[25] Jinguang Han, Liqun Chen, Steve Schneider, Helen Treharne, and Stephan Wesemeyer. 2021. Privacy-preserving electronic ticket scheme with attribute-based credentials. IEEE Trans. Dependable Secur. Comput. https://xxdoi.org/10.1 109/TDSC.2019.2940946.

[26] Wan Huzaini Wan Hussin, Paul Coulton, and Reuben Edwards. 2005. Mobile ticketing system employing trustzone technology. In International Conference

on Mobile Business. IEEE Computer Society. https://xxdoi.org/10.1109/ICMB.20 05.71.

[27] International Organization for Standardization. 2006. Information technology — automatic identification and data capture techniques — qr code 2005 bar code symbology specification. ISO/IEC 18004:2006. (2006).

[28] Florian Kerschbaum, Hoon Wei Lim, and Ivan Gudymenko. 2013. Privacy-preserving billing for e-ticketing systems in public transportation. In Proceedings of the 12th annual ACM Workshop on Privacy in the Electronic Society, WPES 2013. ACM. https://xxdoi.org/10.1145/2517840.2517848.

[29] Phillip Leslie and Alan Sorensen. 2014. Resale and rent-seeking: an application to ticket markets. Review of Economic Studies, 81, 1, 266-300.

[30] Xiaoshan Li, Zhiming Liu, and Zhensheng Guo. 2001. Formal object-oriented analysis and design of an online ticketing system. In 8th Asia-Pacific Software Engineering Conference (APSEC 2001). IEEE Computer Society. https://xxdoi.or g/10.1109/APSEC.2001.991486.

[31] Xuelian Li, Jie Niu, Juntao Gao, and Yue Han. 2019. Secure electronic ticketing system based on consortium blockchain. KSII Trans. Internet Inf. Syst. https://x doi.org/10.3837/tiis.2019.10.022.

[32] Weiwei Liu, Yi Mu, and Guomin Yang. 2014. An efficient privacy-preserving e-coupon system. In International Conference on Information Security and Cryptology. Springer.

[33] Akash Madhusudan, Mahdi Sedaghat, Philipp Jovanovic, and Bart Preneel. 2022. Nirvana: instant and anonymous payment-guarantees. IACR Cryptol. ePrint Arch., 872.

[34] Hemanta K Maji, Manoj Prabhakaran, and Mike Rosulek. 2011. Attribute-based signatures. In Cryptographers' track at the RSA conference. Springer, 376-392.

[35] Milica Milutinovic, Koen Decroix, Vincent Naessens, and Bart De Decker. 2015. Privacy-preserving public transport ticketing system. In Data and Applications Security and Privacy- 29th Annual IFIP WG 11.3 Working Conference, DBSec. Springer. https://xxdoi.org/10.1007/978-3-319-20810-7%5C_9.

[36] Omid Mir, Daniel Slamanig, and René Mayrhofer. 2023. Threshold delegatable anonymous credentials with controlled and fine-grained delegation. IEEE Transactions on Dependable and Secure Computing.

[37] Lekshmi S. Nair, V. S. Arun, and Sijo Joseph. 2015. Secure e-ticketing system based on mutual authentication using RFID. In Proceedings of the Third International Symposium on Women in Computing and Informatics, WCI 2015. ACM. https://xxdoi.org/10.1145/2791405.2791573.

[38] Lan Nguyen. 2006. Privacy-protecting coupon system revisited. In Financial Cryptography and Data Security: 10th International Conference, FC 2006 Anguilla, British West Indies, February 27-March 2, 2006 Revised Selected Papers 10. Springer, 266-280.

[39] Johanna Nieminen, Teemu Savolainen, Markus Isomaki, Basavaraj Patil, Zach Shelby, and Carles Gomez. 2015. IPv6 over BLUETOOTH(R) Low Energy. RFC 7668. (Oct. 2015). DOI: 10.17487/RFC7668.

[40] PaySafeCard. 2018. Paysafecard. https://www.paysafecard.com/fr/. (2018).

[41] Torben Pryds Pedersen. 2001. Non-interactive and information-theoretic secure verifiable secret sharing. In Advances in Cryptology—CRYPTO'91: Proceedings. Springer, 129-140.

[42] GET Protocol. 2016. GUTS Ticketing. https://guts.tickets/. (2016).

[43] Jason Reid, Juan M Gonzalez Nieto, Tee Tang, and Bouchra Senadji. 2007. Detecting relay attacks with timing-based protocols. In Proceedings of the 2nd ACM symposium on Information, computer and communications security, 204-213.

[44] Nicolas Van Saberhagen. 2013. Monero Research Paper. (2013). https://github.c om/monero-project/research-lab/blob/master/whitepaper/whitepaper.pdf.

[45] Claus-Peter Schnorr. 1991. Efficient signature generation by smart cards. Journal of Cryptology.

[46] Johannes Sedlmeir, Hans Buhl, Gilbert Fridgen, and Robert Keller. 2020. The energy consumption of blockchain technology: beyond myth. Business & Information Systems Engineering, 62, (Dec. 2020). DOI: 10.1007/s12599-020-00656-x. Marc Sel, Stefaan Seys, and Eric R. Verheul. 2008. The security of mass transport ticketing systems. In ISSE 2008 - Securing Electronic Business Processes, Highlights of the Information Security Solutions Europe 2008 Conference. https://xxdoi.org/10.1007/978-3-8348-9283-6%5C_37.

[47] Isamu Teranishi, Jun Furukawa, and Kazue Sako. 2004. K-times anonymous authentication (extended abstract). In Advances in Cryptology - ASIACRYPT 2004. Springer.

[48] Hitesh Tewari and Arthur Hughes. 2016. Fully anonymous transferable ecash. Cryptology ePrint Archive.

[49] Minhui Xie, Mark Tomlinson, and Bobby Bodenheimer. 2004. Interface design for a modern software ticketing system. In Proceedings of Annual Southeast Regional Conference. ACM, Huntsville, Alabama. https://xxdoi.org/10.1145/986 537.986566.

[50] Yuan YuanJiang and Ji Ting Zhou. 2022. Ticketing system based on NFT. In 24th IEEE International Workshop on Multimedia Signal Processing, MMSP 2022. IEEE. https://xxdoi.org/10.1109/MMSP5362.2022.9948706.
A IMPLEMENTATION OF Applause

A proof-of-concept implementation of Applause in Rust is available in [21]. This implementation showcases the protocol’s completeness and highlights the anticipated low computational cost of the cryptographic operations within our proposal. In our implementation, we have measure the impact of up to a thousand participants event purchasing a ticket. After the purchase, all acquired tickets are transferred to load the shared state while generating the new (transferred) tickets. Subsequently, the refund and validation processes are executed with these tickets.

Our analysis specifically focuses on cryptographic operations,
excluding communication time and payment processes. Commu-
nication time is highly dependent on the network infrastructure,
and our protocol allows for multiple anonymous payment meth-
ods to be integrated. These presented execution times should be
considered as a baseline.

We rely on standard cryptographic primitives: we used the
curve25519 curve for ElGamal [16] and Schnorr signatures [45].
To achieve key randomisation for Schnorr scheme, we rely on the
generic algorithm generating a new key pair. Benchmarks over 200
iterations from 1 ticket in the database up to 1000 tickets in it have
highlight the constant time execution of all process. On an Ubuntu
laptop equipped with an Intel i7-12800H processor and 32 GB of
RAM give average execution times of 10 ms for a purchase, 40 ms
for a transfer, 15 ms for a refund and 30 ms for a validation, hence
emphasizing the high efficiency of all cryptographic operations.
Hence, the overhead brought by securing the protocol is acceptable.
Moreover, these timings are within the same order of magnitude
as 1 *Round-Trip Time*. The overhead introduced by securing the
protocol appears acceptable at any step of the process. Finally, the
measurement of the shared state update shows that it is negligible,
always lower than 1 millisecond. Therefore, our instantiation is
efficient and scalable.

<figure><img src="image_6.png" /><figcaption>Figure 7: Mean execution times (in milliseconds) of the cryptographic operations in the protocol over 200 iterations, depending on the number of handled tickets.</figcaption></figure>

<figure><img src="image_7.png" /><figcaption>Figure 8: Exchange without trust and based on central transfer authority.</figcaption></figure>

B TRANSFER SETTINGS

While the sale of a ticket is relatively straightforward, ticket transfer
can be realized under multiple scenarios. In e-cash system, only two
entities are typically involved in the transfer, but the verification
is not strong enough to guarantee that, at any time, two entities
does not hold the same coin. This is required in e-ticket. It was
demonstrated in [19] that achieving a fair transfer in the setting
depicted in Fig. 8, between two users without a trusted third party
is impossible. Another way to come to this result, in our context, is
described below.

**Property 1.** Consider two users $U_1$ and $U_2$. Assume that $U_1$ holds a honestly generated ticket and that $U_2$ tries to acquire it via a transfer protocol where it trades it against a payment. Assuming that no external interaction is executed during the protocol. Their exist no protocol leading to a secure exchange between $U_1$ and $U_2$ ending with $U_2$ being the only holder of the exchanged ticket.

PROOF. Considering $\mathcal{U}_1$ selling its ticket to $\mathcal{U}_2$, without any of the two users interacting with any third party. As $\mathcal{U}_1$ holds at least the same data as it did before interacting with $\mathcal{U}_2$, if it had probability $p$ to execute the exchange protocol with $\mathcal{U}_2$, in general, the same success probability holds for a second execution of the transfer protocol with another user $\mathcal{U}_3$ with inputs distributed similarly to $\mathcal{U}_2$'s inputs. If we assume that $p$ is non-negligible, then, $\mathcal{U}_1$ has probability $p^2$ to sell twice its ticket, which is not negligible and contradicts the security of the exchange regarding $\mathcal{U}_2$'s perspective. $\square$

To ensure a secure transfer between the two users, we rely on
a transfer authority $\mathcal{T}$. The considered communication setup
is depicted in Fig. 8. In our case the ticket transfer can be viewed as a
purchase of the same ticket for $\mathcal{U}_2$, followed by the refund of $\mathcal{U}_1$.

Other architectures based on a trusted third party could be con-
sidered. For example, the above analysis does not prevent only one
of the two users $U_1$ from contacting the transfer authority, while
$U_2$ contacts only $U_1$. Indeed, the security analysis of our protocol
would ensure that such a process can be practically achieved: mes-
sages replayed by $U_1$ from $U_2$ and then received by $\mathcal{T}$ would be
well-formed, and our security proofs guarantee that $U_2$ does not
need to contact the transfer authority. security proofs guarantee
that $U_2$'s identity cannot be usurped by another entity in another
execution.
A IMPLEMENTATION OF Applause

A proof-of-concept implementation of Applause in Rust is available in [21]. This implementation showcases the protocol’s completeness and highlights the anticipated low computational cost of the cryptographic operations within our proposal. In our implementation, we have measure the impact of up to a thousand participants event purchasing a ticket. After the purchase, all acquired tickets are transferred to load the shared state while generating the new (transferred) tickets. Subsequently, the refund and validation processes are executed with these tickets.

Our analysis specifically focuses on cryptographic operations,
excluding communication time and payment processes. Commu-
nication time is highly dependent on the network infrastructure,
and our protocol allows for multiple anonymous payment meth-
ods to be integrated. These presented execution times should be
considered as a baseline.

We rely on standard cryptographic primitives: we used the
curve25519 curve for ElGamal [16] and Schnorr signatures [45].
To achieve key randomisation for Schnorr scheme, we rely on the
generic algorithm generating a new key pair. Benchmarks over 200
iterations from 1 ticket in the database up to 1000 tickets in it have
highlight the constant time execution of all process. On an Ubuntu
laptop equipped with an Intel i7-12800H processor and 32 GB of
RAM give average execution times of 10 ms for a purchase, 40 ms
for a transfer, 15 ms for a refund and 30 ms for a validation, hence
emphasizing the high efficiency of all cryptographic operations.
Hence, the overhead brought by securing the protocol is acceptable.
Moreover, these timings are within the same order of magnitude
as 1 *Round-Trip Time*. The overhead introduced by securing the
protocol appears acceptable at any step of the process. Finally, the
measurement of the shared state update shows that it is negligible,
always lower than 1 millisecond. Therefore, our instantiation is
efficient and scalable.

<figure><img src="image_7.png" /><figcaption>Figure 7: Mean execution times (in milliseconds) of the cryptographic operations in the protocol over 200 iterations, depending on the number of handled tickets.</figcaption></figure>

<figure><img src="image_8.png" /><figcaption>Figure 8: Exchange without trust and based on central transfer authority.</figcaption></figure>

B TRANSFER SETTINGS

While the sale of a ticket is relatively straightforward, ticket transfer
can be realized under multiple scenarios. In e-cash system, only two
entities are typically involved in the transfer, but the verification
is not strong enough to guarantee that, at any time, two entities
does not hold the same coin. This is required in e-ticket. It was
demonstrated in [19] that achieving a fair transfer in the setting
depicted in Fig. 8, between two users without a trusted third party
is impossible. Another way to come to this result, in our context, is
described below.

**Property 1.** Consider two users $U_1$ and $U_2$. Assume that $U_1$ holds a honestly generated ticket and that $U_2$ tries to acquire it via a transfer protocol where it trades it against a payment. Assuming that no external interaction is executed during the protocol. Their exist no protocol leading to a secure exchange between $U_1$ and $U_2$ ending with $U_2$ being the only holder of the exchanged ticket.

PROOF. Considering $\mathcal{U}_1$ selling its ticket to $\mathcal{U}_2$, without any of the two users interacting with any third party. As $\mathcal{U}_1$ holds at least the same data as it did before interacting with $\mathcal{U}_2$, if it had probability $p$ to execute the exchange protocol with $\mathcal{U}_2$, in general, the same success probability holds for a second execution of the transfer protocol with another user $\mathcal{U}_3$ with inputs distributed similarly to $\mathcal{U}_2$'s inputs. If we assume that $p$ is non-negligible, then, $\mathcal{U}_1$ has probability $p^2$ to sell twice its ticket, which is not negligible and contradicts the security of the exchange regarding $\mathcal{U}_2$'s perspective. $\square$

To ensure a secure transfer between the two users, we rely on
a transfer authority $\mathcal{T}$. The considered communication setup
is depicted in Fig. 8. In our case the ticket transfer can be viewed as a
purchase of the same ticket for $\mathcal{U}_2$, followed by the refund of $\mathcal{U}_1$.

Other architectures based on a trusted third party could be con-
sidered. For example, the above analysis does not prevent only one
of the two users $U_1$ from contacting the transfer authority, while
$U_2$ contacts only $U_1$. Indeed, the security analysis of our protocol
would ensure that such a process can be practically achieved: mes-
sages replayed by $U_1$ from $U_2$ and then received by $\mathcal{T}$ would be
well-formed, and our security proofs guarantee that $U_2$ does not
need to contact the transfer authority. security proofs guarantee
that $U_2$'s identity cannot be usurped by another entity in another
execution.
## C SECURITY PROOFS OF Applause

We present the security proofs for Applause, with respect to the security model presented in Section 3. Through this section, we operate proofs divided into sequences of games. We refer to this games as $G_{\mathcal{A}}^i(1^{\lambda})$ for a given PPT algorithm $\mathcal{A}$ and a security parameter $1^{\lambda}$. Moreover, we characterise by $w_i$ the winning event where a PPT algorithm $\mathcal{A}$ makes $G_{\mathcal{A}}^i(1^{\lambda})$ outputs 1. At first we present the security proofs of the version of Applause presented in Section 5, which relies on the *Random Oracle Model* (ROM). Then we present the security proofs for the version of Applause in the standard model. Recall that both versions of Applause differ only in few points, as explained in Section 6.

### C.1 Security Proofs of Applause in Random Oracle Model

*PROOF OF UNFORGEABILITY.* Let $\mathcal{A}$ be a PPT adversary and assume for contradiction that the following probability $\Pr[\text{Exp}_{\mathcal{A}}^{\text{UF}}(1^{\lambda}) \to 1]$ is non-negligible. This proof relies on the ROM, meaning that $\mathcal{A}$ has access to an oracle Ohash replacing the function $H$ and programmed by the challenger $C$, which on call on a message $m$, samples at random a value $h$ representing the hash associated to $m$. This process is repeated if the value is already associated to another message $m'$. Then the sampled value $h$ is returned to $\mathcal{A}$.

*Game* $G^0$. The initial game represents $\text{Exp}_{\mathcal{A}}^{\text{UF}}$ defined in Fig. 3, we observe that $\Pr[W_0] = \Pr[\text{Exp}_{\mathcal{A}}^{\text{UF}}(1^{\lambda}) \to 1]$.

*Game* $G^1$. In this game, we now reject tickets with valid signatures from $\mathcal{D}$ that where not produced by the challenger. To distinguish such signature from the originally produced ones, $C$ keeps updated a set $S_{\mathcal{D}} = \{m_i, \sigma_i\}$ containing all the signature produced by $\mathcal{D}$ during the protocol. A signature is deemed valid if the message-signature pair is contained in this set, otherwise invalid. This prevents $\mathcal{A}$ from forging a signature, which was previously possible with probability $\text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}$. Therefore, we obtain the following bound $|\Pr[W_0] - \Pr[W_1]| \le \text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}(1^{\lambda})$.

*Game* $G^2$. The same action as in $G^1$ is performed on the signature produced by $\mathcal{T}$. Hence $|\Pr[W_1] - \Pr[W_2]| \le \text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}(1^{\lambda})$.

In $G^2$, the adversary $\mathcal{A}$ is not able to produce a ticket containing a forged signature from $\mathcal{D}$ or $\mathcal{T}$. A valid ticket is requires to contain a signature either by $\mathcal{D}$ or $\mathcal{T}$ as prescribed by the CheckTk algorithm executed in Validate, Refund or Transfer. $\mathcal{A}$ can still reuse a signature produced by the Challenger. Under the ROM, this implies using the hash $c \leftarrow \text{Ohash}(\text{ide}, \text{idp}, r_c)$ corresponding to a random value, already signed by $C$. Either $\text{tk} \notin \text{TK}$ and $\mathcal{A}$ loses the game, otherwise $\text{tk} \in \text{TK}$ and in such case, $c$ appears in the state $\text{st}$ of the Challenger $C$ and the ticket will fail to verify in the last verification of the CheckTk algorithm. This can been seen by analyzing the inclusion of $c$ in $\text{st}$ through the processes. In both cases, a condition of CheckTk is not achieved and the protocol aborts for $C$. This shows that $\Pr[W_2] = 0$, and then, we obtain $\Pr[\text{Exp}_{\mathcal{A}}^{\text{UF}}(1^{\lambda}) \to 1] \le 2 \cdot \text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}(1^{\lambda})$.

By hypothesis on the EUF-CMA property of the signature $S$, we know that $\text{Adv}_{\mathcal{A}}^{\text{EUF-CMA}}$ is negligible, leading to a negligible quantity on the right hand side of the inequation, giving a direct contraction

with the initial hypothesis. Hence, $\Pr[\text{Exp}_{\mathcal{A}}^{\text{UF}}(1^{\lambda}) \to 1]$ is negligible and Applause has Unforgeability. $\square$

*PROOF OF PSEUDONYMITY.* Assume a PPT algorithm $\mathcal{A}$, we show that it breaks at least one of the assumed properties of the used primitives, and that such an algorithm cannot exist under the given hypothesis. We start by considering an initial game $G^0$.

*Game* $G^0$. The initial game corresponds to experiment $\text{Exp}_{\mathcal{A}}^{\text{PSE}}$. Observe that $\Pr[W_0] = \Pr[\text{Exp}_{\mathcal{A}}^{\text{PSE}}(1^{\lambda}) \to 1]$.

*Game* $G^1$. We focus on the anonymous payment. At the beginning, the challenger generates a new key pair and uses this key $\text{sk}_{\text{new}}^{\text{P}}$ instead of using $\text{sk}_{\text{U}_b}^{\text{Pay}}$ in all payments of the experiment. By hypothesis, an adversary has a negligible advantage $\text{Adv}_{\mathcal{A}}^{\text{PayPse}}(1^{\lambda})$ of distinguishing between which one among the two key pairs used in a payment. This property is directly transferred into our case and leaves the two key pairs of $\text{sk}_{\text{U}_0}^{\text{Pay}}$ and $\text{sk}_{\text{U}_1}^{\text{Pay}}$ unused. Hence, we obtain the following bound $|\Pr[W_0] - \Pr[W_1]| \le \text{Adv}_{\mathcal{A}}^{\text{PayPse}}(1^{\lambda})$.

Now, we notice that the user's key is not used in Purchase and Refund. Only Transfer and Validate involve the user's key, excluding the payment key. Hence, a call to oracles $\text{OPurchase}_b$, $\text{ORefund}_b$ does not reveal any information on the key pair $(\text{sk}_{\text{U}_b}, \text{pk}_{\text{U}_b})$ in use, ignoring the payment key that we already modified we apply the following:

*Game* $G^2$. Instead of randomizing the key pair in Validate, when $\mathcal{A}$ calls $\text{OValidate}_b$, we generate a new signature and encryption key pairs. The resulting keys are unrelated to the key pair of the user. Provided with statistically randomizable key pairs, they where already unrelated after randomization, resulting in $\Pr[W_2] = \Pr[W_1]$.

*Game* $G^3$. On each call of $\mathcal{A}$ to $\text{OTransfer}_b$, the same modification is put in place in Transfer. As for the previous modification, games are therefore statistically indistinguishable. This is again a bridging step with $\Pr[W_3] = \Pr[W_2]$.

In this game $G^3$, none of $(\text{sk}_{\text{U}_0}, \text{pk}_{\text{U}_0})$ or $(\text{sk}_{\text{U}_1}, \text{pk}_{\text{U}_1})$ are used by the challenger during the experiment. Hence, the adversary has no mean to recover $b$ and then no advantage in breaking the pseudonymity. Hence, we obtain $\Pr[W_3] = \frac{1}{2}$. Summing up, $\mathcal{A}$ is a PPT algorithm with non-negligible advantage of winning against $G^0$ i.e., a non-negligible advantage in breaking the anonymity of $\text{U}_b$. Hence, we observe that $|\Pr[\text{Exp}_{\mathcal{A}}^{\text{PSE}}(1^{\lambda}) \to 1] - \frac{1}{2}| \le \text{Adv}_{\mathcal{A}}^{\text{PayPse}}(1^{\lambda})$.

By hypothesis on the anonymity property of considered anonymous payment, we know that $\text{Adv}_{\mathcal{A}}^{\text{Pay}}$ is negligible, implying that no such $\mathcal{A}$ could exist. Therefore, pseudonymity holds for our ETS protocol Applause. $\square$

*PROOF OF PRIVACY.* We prove secrecy of $r_c$ through this proof. Assume $\mathcal{A}$ has a PPT algorithm. If an adversary $\mathcal{A}$ is unable to recover $r_c$, then it is unable to win against $\text{Exp}_{\mathcal{A}}^{\text{PRIV}}(1^{\lambda})$, or at least with a negligible probability. Notice that $\mathcal{U}$, the user simulated by $C$ which has generated $\text{tk}$, cannot be corrupted, otherwise $\mathcal{A}$ would fail to the experiment under $\text{corr}_1 = 0$. The following modification applied to the oracles are assumed to append only when the ticket $\text{tk}$ is involved during the execution of the oracle.

*Game* $G^0$. The initial game corresponds to the experiment $\text{Exp}_{\mathcal{A}}^{\text{PRIV}}$, hence $\Pr[W_0] = \Pr[\text{Exp}_{\mathcal{A}}^{\text{PRIV}}(1^{\lambda}) \to 1]$.