PriTKT: A Blockchain-Enhanced Privacy-Preserving Electronic Ticket System for IoT Devices

Electronic tickets (e-tickets) are gradually being adopted as a substitute for paper-based tickets to bring convenience to customers, corporations, and governments. However, their adoption faces a number of practical challenges, such as flexibility, privacy, secure storage, and inability to deploy on IoT devices such as smartphones. These concerns motivate the current research on e-ticket systems, which seeks to ensure the unforgeability and authenticity of e-tickets while simultaneously protecting user privacy. Many existing schemes cannot fully satisfy all these requirements. To improve on the current state-of-the-art solutions, this paper constructs a blockchain-enhanced privacy-preserving e-ticket system for IoT devices, dubbed PriTKT, which is based on blockchain, structure-preserving signatures (SPS), unlinkable redactable signatures (URS), and zero-knowledge proofs (ZKP). It supports flexible policy-based ticket purchasing and ensures user unlinkability. According to the data minimization and revealing principle of GDPR, PriTKT empowers users to selectively disclose subsets of (necessary) attributes to sellers as long as the disclosed attributes satisfy ticket purchasing policies. In addition, benefiting from the decentralization and immutability of blockchain, effective detection and efficient tracing of double spending of e-tickets are supported in PriTKT. Considering the impracticality of existing e-tickets schemes with burdensome ZKPs, we replace them with URS/SPS or efficient ZKP to significantly improve the efficiency of ticket issuing and make it suitable for use on smartphones.


Introduction
E-ticketing has emerged as a popular method of ticket entry, processing, and marketing for companies in the airline [1], railway [2,3], and other transportation and entertainment industries.The integration of blockchain technology in e-ticketing has further enhanced the security and transparency of transactions.Blockchain [4][5][6][7] ensures that each transaction is recorded in a decentralized and tamper-proof ledger, reducing the risk of fraud and ensuring the authenticity of e-tickets.Unlike traditional paper-based tickets, e-tickets offer two major advantages.First, paper-based tickets are disposable and require significant resources for their production, leading to an increased negative impact on the environment.By contrast, e-tickets serve as an eco-friendly replacement by minimizing paper waste produced from ticketing activities, thereby aligning with the principles of the Paris Agreement [8].Second, e-tickets provide customers with the flexibility to reserve, issue, and refund their tickets online anytime and anywhere, eliminating the need for in-person lineups.This convenience and ease for customers is further heightened by the integration of IoT technology.Customers can easily access their e-tickets through dedicated mobile applications, making the entire ticketing process more streamlined and accessible.Seamless integration with IoT devices not only enhances the overall customer experience, it reflects the evolving nature of ticketing systems in the digital age.As a result, e-tickets, powered by blockchain and IoT technology, offer significant advantages in terms of convenience, environmental sustainability, and security.
Despite the increasing popularity of e-tickets, they face numerous practical challenges, particularly with regards to privacy.In e-ticket systems, user data such as name, identity number, purchase date, and other personal attributes may be collected and misused.Thus, it is crucial to minimize the collection of personal data in line with the recently introduced General Data Protection Regulations (GDPR) [9].In this regard, various privacy-protecting e-ticket systems have been proposed which use randomizable signatures with efficient proofs [10][11][12][13][14], pseudonyms [15,16], and anonymous credentials [13,17,18].However, some of these systems lack formal proof of security and cannot guarantee the integrity of the token [12,13,16], while others are inefficient in their invoicing operations, making them impossible to deploy on IoT devices [18].
An essential feature of any e-ticket system is the ability to issue tickets based on user attributes.Attribute-based e-ticket systems have potential in various real-world applications.For example, they can enable students, soldiers, and individuals with disabilities to purchase tickets at discounted rates without revealing sensitive information such as a student ID number, unit number, or health conditions.In an attribute-based e-ticketing system, a user credential used to purchase e-tickets is parameterized with a vector of the user's attributes, such as date of birth, affiliation, or occupation.During ticket purchase, users can prove that they possess a credential meeting a given attribute policy, such as age or disability, without revealing any additional information beyond the satisfaction of the attribute policy.Unfortunately, most existing e-ticketing systems [12][13][14]16] do not support attribute-based ticket issuance protocols.
Credentials issued by governmental bodies, schools, or companies typically include only the basic attributes of the user, such as name, gender, educational background, address, and position.However, in many cases additional attributes can be defined as well.For instance, in platform configuration-based access control services, attributes may refer not only to the user's personal data but to hardware platform and configuration information.Moreover, one user may hold several roles, each with unique credentials issued by a single entity.The Privacy by Design Foundation's Anonymous Credentials (IRMA) [19] offers a broad range of real-world attributes, such as diplomas, passports, cards, and even membership IDs for online services, which are relevant to governing bodies and various businesses.Such scenarios imply that a user may have hundreds or more potential attributes.Integrating IoT devices into the e-ticketing system allows for the inclusion of additional attributes related to the user while presenting an opportunity to streamline the issuance process.IoT devices capabilities, such as bio-metric authentication and secure storage, can enhance the security and efficiency of handling a wide array of attributes.This ensures that the eticketing system remains practical and user-friendly even in scenarios with a large number of potential attributes.While Han et al. [18] designed the first attribute-based e-ticketing system, their ticket issuance algorithm's computational cost and communication overhead increases linearly with the number of user attributes, making their scheme impractical to deploy on IoT devices when users have hundreds of attributes.
Paper-based tickets can be made unique, and are easily distinguishable from copies; however, distinguishing original e-tickets from their copied versions is challenging, making it necessary to prevent and detect double spending in e-ticketing systems.This challenge is particularly pertinent in the digital realm, where the ease of replication poses a unique set of security concerns.The integration of blockchain technology offers a promising solution to the issue of double spending in e-ticketing.By utilizing a decentralized and tamper-proof ledger, blockchain ensures the immutability and transparency of transaction records.Each e-ticket transaction can be securely recorded on the blockchain, creating a verifiable and unforgeable trail.This prevents unauthorized duplication of e-tickets while allowing for efficient tracking and identification of any double-spending attempts.Moreover, in the context of IoT technology, blockchain can be seamlessly integrated to enhance the security of e-tickets.IoT devices can serve as secure digital wallets, storing and managing e-tickets in a tamper-resistant environment.The combination of blockchain and IoT devices ensures that the integrity of e-tickets is maintained, reducing the risk of duplication and unauthorized use.In the event of a double-spending attempt, the decentralized nature of blockchain enables the identification and tracing of responsible users without compromising the anonymity of honest users.The transparency of the blockchain allows for swift and accurate resolution of security incidents, thereby bolstering the overall trust and reliability of the e-ticketing system.
Based on the above requirements and intuition, we propose PriTKT, a blockchainenhanced privacy-preserving e-ticketing system for IoT devices that supports ticket issuance based on user attributes.PriTKT significantly reduces the computational cost and communication overhead, making it suitable for use on IoT devices, and utilizes blockchain [4] to achieve effective malicious user tracking.

Our Contributions
This work makes the following contributions: • Attribute-based ticketing: We propose an e-ticket system that supports attributebased ticketing.This system securely and seamlessly integrates attribute-based anonymous credentials [20], unlinkable redactable signatures (URS) [20], structure-preserving signatures (SPS) [21], Pedersen commitment, and zero-knowledge signature of knowledge (ZKSoK) [22] in its design.In our e-ticket system, a trusted party generates a ticket purchasing policy set during system initialization.The ticket purchasing policy set regulates how tickets are issued.User privacy is preserved, as users may disclose a subset of their attributes as long as they satisfy a ticket purchasing policy in the ticket purchasing policy set for the tickets they purchase.
• Efficient ticketing for IoT devices: Our system improves the efficiency of the ticketing algorithm to ensure that it can be efficiently executed on an IoT device (such as smartphone) while presenting a privacy-preserving e-ticketing solution that does not require expensive Zero-Knowledge Proofs (ZKP) to validate user credentials during ticket purchase.Instead, we use the URS signature, which reduces the computational overhead in the ticket-issuing algorithm from O(N) to O(N − K) and the communication overhead from O(N) to O(K), where N and K represent the number of user attributes and exposed attributes, respectively.Compared to the closest scheme in [18], our method improves both computational and communication performance.We implemented PriTKT on a smartphone under AES-100-bit security and compared it with the state-of-the-art scheme from [18], finding that our issuing algorithm and showing algorithm were 250% and 240% more efficient, respectively.
• Blockchain-enhanced double-spending detection and efficient trace: We implement double-spending detection and efficient user tracking.The verifier uploads each valid token into the blockchain.The decentralization and immutability of the blockchain [4] ensures the correctness of the token storage.Every ticket must disclose its unique identity when it is shown, and ZKSoK is used to guarantee the correctness of its identity disclosure.With the ticket identity, the verifier can traverse the tokens stored in the blockchain and quickly detect any double-spending.Using the "Schnorr trick" [23], the verifier can quickly compute the public key of any double-spending user for efficient tracing.
• Unlinkability and framing resistance: Our solution ensures the unlinkability of tickets.Using the unlinkability of URS signatures, we prove that no tickets of the same user can be linked.Our solution ensures the framing resistance of tickets.Framing resistance ensures that corrupt sellers cannot falsely accuse any honest users of double-spending.
In addition, we offer formal security definitions for e-tickets that can be reduced to known complexity assumptions or the security of established cryptography primitives.The performance of PriTKT was measured on a smartphone.

Electronic Tickets on IoT Devices
Mut-Puigserver et al. [24] conducted a study on the functional and security requirements of electronic tickets.These requirements include offline verification, expiration dates, reduced size, portability, flexibility, unlinkability, unforgeability, and non-overspending.They explored various types of e-tickets, such as single-use, multi-use, transferable, and non-transferable.Our research specifically focuses on analyzing the unlinkability, unforgeability, and non-overspending features of single-use and non-transferable electronic tickets leveraging the capabilities of IoT devices and the security of blockchain technology.
Previous studies by Heydt-Benjamin et al. [12] employed electronic cash, anonymous credentials [25], and proxy re-encryption [26] to enhance privacy in public transit systems that use electronic tickets.The study proposed a theoretical framework to examine the security of payments and the privacy of information in transit systems.They asserted that their system was capable of safeguarding user privacy but was not compatible with attribute-based ticketing; however, the paper did not provide any formal proof to support the system's security.In contrast, the integration of IoT technology and blockchain in modern e-ticketing systems, such as PriTKT, can offer improved security measures, including attribute-based ticketing, while maintaining user privacy.Following Rupp et al. [14], Jager et al. [27] presented Black-Box Accumulation (BBA) to establish cryptography payment systems.Later, BBA was enhanced to BBA+ [28] by Hartung et al. and Black-Box Wallet (BBW) by Hoffmann et al. [29].Nonetheless, these payment schemes [27][28][29] differ from attribute-based e-ticketing systems, as they pertain to electronic payments.
Vives-Guasch et al. [16] introduced an e-ticketing system that considers user privacy requirements as well as security requirements that include exculpability and re-usability.Additionally, by utilizing lightweight cryptography and mobile phones equipped with Near-Field Communication (NFC) technology, their system accommodates the computational limitations of users.Regrettably, however, their system does not support attributebased ticketing.The integration of IoT devices (smartphones) in e-ticketing systems, as demonstrated by PriTKT, can contribute to enhanced features such as de-anonymization prevention and secure ticket non-transferability, while blockchain ensures the security and transparency of transactions.
The system of Milutinovic et al. [13] depends on certified tokens that are impossible to relate, and on different cryptographic primitives such as commitment schemes [30], partially blind signatures [31], and anonymous credentials [32] to tackle privacy concerns.However, their system does not provide de-anonymization capabilities after double spending or support ticket non-transferability in the way that PriTKT does.The integration of IoT devices capabilities in PriTKT enhances security measures and provides a practical solution for these challenges.
Han et al.
[18] introduced attribute-based credentials derived from the Boneh-Boyen signature (BBS) [33] and efficient set membership proof and range proofs [34] to issue attribute credentials and tickets.However, due to the use of a signature with the NIZK protocol, their system's NIZK proof computation increases linearly with the number of attributes in the ticket-issuing algorithm, limiting its practical use.The integration of lightweight and efficient IoT technology, along with the security of blockchains, can potentially address these computational constraints, making attribute-based e-ticketing more practical and user-friendly.
The most direct way to prevent double-spending is to bind each spending operation with a unique identifier that cannot be forged to ensure that that verifiers can detect double-spending based on the unique identifier.Rupp et al. [14] used a digital signature as the identifier.Sasson et al. [5] utilized hash-based commitments to compute identifiers.Androulaki et al. [6] utilized verifiable random functions to generate identifiers.Han et al. [18] and Sun et al. [7] used elements randomly mapped to elliptic curve groups as identifiers.Jager et al. [27] and Bobolz et al. [23] directly used a random number as the identifier.Although there are many ways to generate identifiers, these schemes all need to compute a zero-knowledge proof in the spending protocol to prove the correctness of the disclosed identifier.
Certain schemes [5][6][7]12,13,16,27] simply terminate the spending protocol when a double-spend is detected, while others [14,18,23,28,29] support further tracing and identification of malicious users.The method used by Han et al. [18] was to hide users' identity in ElGamal ciphertext, then use a verifier to recover their identities through the spending algorithms.The scheme in [14,23,28,29] achieved double-spending tracing through the "Schnorr trick", which is more efficient than scheme in [18].The integration of blockchains into these schemes can enhance the overall security and transparency of their double-spending prevention and tracing mechanisms.

Attribute-Based Credentials
Anonymized attribute-based credentials that enable selective disclosure of attributes can be obtained in a manner akin to the use of randomizable signatures.Every user receives a signature on (commitments to) a list of attributes from a centralized authority.When the credential is presented, the user randomizes the signature (ensuring that the resulting signature and the published signature cannot be linked) and proves the correspondence of this signature to the revealed and hidden attributes in zero-knowledge proofs [35][36][37][38][39][40][41].From a privacy perspective, this solution is perfectly satisfactory; however, it is not very efficient, as the user's unshared attributes impose more cost than the user's revealed attributes.
Fuchsbauer and Hanser [42,43] randomized both the signature and the signed message (which is a set commitment to the user's attributes) with a structure-preserving signature on equivalence classes (SPS-EQ), then used subset opening of the set commitments to selectively disclose attributes.In this way, they avoided the need to perform costly ZKP over the hidden attributes.Unfortunately, while attributes can be disclosed in this solution once they are signed, it cannot be proven that they are hidden while satisfying certain relations.
Camenisch et al. [44] presented a novel unlinkable redactable signature (URS) that allows part of the signed message to be redacted while proving that the signature is valid for the disclosed attributes.Unfortunately, their scheme can only be instantiated by Groth-Sahai proofs [45], and it is difficult to compete with the most effective solution in practice.Sanders followed the URS approach from [44] and constructed a flexible redactable signature scheme that achieves unlinkability at almost zero cost.Unlike the methods in [43,44], the URS presented by Sanders can prove complex relationships between attributes and does not rely on zero-knowledge proofs for partial verification.

Bilinear Pairing
Suppose that G 1 , G 2 , and G T are groups of prime-order p with generators g ∈ G 1 and g ∈ G 2 .A mapping e : G 1 × G 2 → G T is a bilinear map if it satisfies three requisite properties.(1) Bilinearity: for all g ∈ G 1 , g ∈ G 2 , and a, b ∈ Z p , we have e(g a , g b ) = e(g, g) ab ; (2) Nondegeneracy: e(g, g) ̸ = 1; and (3) Computability: e is an efficiently computable function.The PriTKT scheme is based on the Type III bilinear pairing [46], which by definition does not admit an efficiently computable homomorphism between G 1 and G 2 .

Computational Assumptions
Discrete Logarithm (DL) Assumption.Let G be a prime-order cyclic group and let g be a generator of G. Given (g, g x ) ∈ G 2 , the DL assumption holds in G if no efficient algorithm or adversary can practically compute x with non-negligible probability.
The DDH Assumption.Let G be a prime-order cyclic group and let g be a generator of G. Given (g, g x , g y , g z ) ∈ G 4 , the DDH assumption holds in G if no efficient adversary can distinguish the product z = x • y from a random element in G.

Unlinkable Redactable Signatures
The Unlinkable Redactable Signature (URS) [20] consists of a tuple (Setup, KeyGen, Sign, Derive, Verify) of probabilistic polynomial-time (PPT) algorithms.The URS is used to issue credentials for a user's attributes.
The URS [20] is a redactable signature scheme with forgeability and unlinkability in the generic group model.

Structure-Preserving Signatures
The Structure-Preserving Signatures (SPS) proposed by Groth [21] consist of a tuple (Setup, KeyGen, Sign, Verify) of PPT algorithms that sets messages in G 2 .This scheme is used to issue credentials for a seller's public key.

Zero-Knowledge Signature of Knowledge
The ZKSoK protocol [22] for an NP-relation R is composed of the following algorithms to ensure knowledge of the language L R = {y : ∃x, (x, y) ∈ R}.
• Gen(1 λ ), which returns a public parameter pp when provided a security parameter λ; • Sign(m, x, y), which returns a ZKSoK Π = ZKSoK{x : (x, y) ∈ R} when given a message m and a relation (x, y) ∈ R; • Verify(m, Π, y), which, when given a message m, ZKSoK Π, and statement y, returns 1 if Π is valid and 0 otherwise.

System and Security Model 4.1. System Model
Electronic ticketing systems involve five entities, as presented in Figure 1: the Central Authority (CA), Ticket Seller (S), User (U) with IoT device (such as smartphones), Blockchain (BC), and Ticket Verifier (V).This section describes each individual function in turn.• CA bears the responsibility of being the globally trusted entity that establishes the electronic ticketing system (step 1 ⃝).Here, the CA creates policy set for purchasing tickets.In addition, the CA must offer registration services to ticket sellers (step 2 ⃝) and users (step 3 ⃝).
• S is an independent ticket seller who is required to register with CA in order to participate in the ticketing system (step 2 ⃝).During the ticket purchasing process, S is responsible for verifying each user's credentials and issuing tickets based on the ticket purchasing policy set forth by CA (step 4 ⃝).• U has a designated set of attributes stored in their IoT device that must be registered with CA in order to participate in the ticketing system (step 3 ⃝).When purchasing a ticket from S, U is only required to disclose a subset of their attributes that satisfy the ticket purchasing policy selected by S (step 4 ⃝).Subsequently, U presents the ticket to V in an anonymous manner (step 5 ⃝).• The blockchain BC acts as an immutable database in the electronic ticket system; using the decentralized features of the blockchain, the verifier can upload all valid token information.Any participant can then query the presentation tokens.
• V offers ticket verification services to all users, and has the ability to detect instances of double-spending.Upon receiving verifiable data from users, V verifies the authenticity of their tickets (step 5 ⃝) and uploads the token to the blockchain while simultaneously detecting any attempts at double-spending.If a double-spending ticket is identified, V traces the corresponding user's public key (step 6 ⃝) and generates double-spending blaming information.
• Any participant can download the token information from the blockchain and verify the correctness of the double-spending tracing based on the double-spending blaming information generated by V (step 7 ⃝).

Formal Definition
The notations used in the system are listed in Table 1, and the algorithms are defined formally below.

Table 1. Summary of notation.
Notation Description • Setup(1 λ ) → (msk, pp, P): the algorithm is executed by CA, which takes a security parameter 1 λ as input and returns a secret key msk, system parameter pp, and set of ticket purchasing policies P.
• SKeyGen(pp) → (ssk, spk): the algorithm is executed by S, which takes a system parameter pp as input and returns a private key ssk and corresponding public key spk as output.
• UKeyGen(pp) → (usk, upk): the algorithm is executed by U, which takes a system parameter pp as input and returns a private key usk and corresponding public key upk as output.
• SReg(S(ssk, spk, pp) ↔ CA(msk, spk, pp)) → (cred s , ⊥): to obtain a credential for a given public key spk, S and CA engage in an interactive algorithm.S provides (ssk, spk) and pp as inputs, while CA provides msk, spk, and pp as inputs.If the algorithm executes successfully, a credential cred s is issued to S. If the algorithm fails to execute, ⊥ is returned as the output.
• UReg(U(usk, upk, A, pp) ↔ CA(msk, upk, pp)) → (cred u , ⊥): U and CA engage in an interactive algorithm to obtain a credential for the attribute set A = {a i } N i=1 .U provides (usk, upk), A, and pp as inputs, while CA provides msk, upk, and pp as inputs.If the algorithm executes successfully, a credential cred u is issued to U. If the algorithm fails to execute, ⊥ is returned as output.
• Issue(U(usk, cred u , D, A, pp) ↔ S(ssk, cred s , pp, P)) → ((tkt, VP tkt ), b): the algorithm for obtaining an anonymous ticket involves an interaction between U and S. To initiate this process, U provides usk, cred u , D, A, and pp as inputs, while S provides ssk, cred s , pp, and P as inputs.Here, we define D = {a i } i∈D , D ⊆ [N] for convenience.U must then provide proof that a subset D of their attributes A has been certified and that D ∈ P in accordance with the ticket purchasing policy selected by S. The final output of the algorithm consists of a bit b indicating the validity of cred u as well as an anonymous ticket tkt and its associated valid period VP tkt for U.
• Show(U(usk, tkt, VP tkt , spk, pp) ↔ V(spk, pp)) → ((dsid, dstrace), b): this algorithm relies on the interaction between U and V. U accepts usk, tkt, VP tkt , spk, and pp as inputs, while V only takes spk and pp.When the algorithm is completed, V uploades the token to BC and produces a bit b with a value of either 1 or 0 (1 indicates that tkt is valid and that VP tkt falls within the validity period, whereas 0 indicates the opposite) along with a double-spending identity dsid and double-spending trace information dstrace.
• DSTrace(dsid, dstrace, dsid, dstrace, spk, pp) → ((dsblame, upk ′ ), ⊥): V can execute this algorithm under the condition that the double-spending identity of two tickets is identical (dsid = dsid), which can be correctly verified by traversing the token information in BC.By taking two trace information dstrace and dstrace as input, V can deterministically generate two outputs: the unique public key upk ′ of the double-spending user, and the double-spending blaming information (dsblame if successful or ⊥ if unsuccessful).
• VerifyDS(dsblame, upk ′ ) → b: any party can operate this algorithm.With dsblame and upk ′ as inputs, it generates an output of b = 1 if dsblame proves that upk ′ has doublespending and b = 0 otherwise.
Note that instead of embedding the user ID as an attribute in the user credential, in our e-ticketing system we use each user's public key as that user's unique identifier.This is because in our system each user has a unique public key.When the DSTrace algorithm is executed, the user's ID can always be determined in the real world according to the public key issued by V and the credential information maintained by CA.Definition 1.The correctness of the e-ticket system depends on two conditions: (1) the tickets produced by the Issue algorithm must be verifiable by the Show algorithm, and (2) the DSTrace algorithm must be able to track users who attempt double-spending behavior.The formal definition of correctness can be found in Supplementary Material Section S4.

Security Model
We assume that the central authority in the system, CA, is fully trustworthy.The ticket seller, S, is honest enough to issue tickets to users according to a specific purchase policy but may attempt to obtain users' undisclosed attributes and real IDs.The user, U, may forge tickets, attempt to spend them twice, or transfer them illegally.The ticket verifier is honest in verifying tickets and detecting users who attempt to spend an electronic ticket more than once, but may attempt to obtain the undisclosed attributes and real IDs of honest users.
The e-ticket system should satisfy the following security requirements: unforgeability of user credentials and tickets, unlinkability of honest users, framing resistance of honest users, and non-transferability of tickets.The security model is defined following the works in [20,23,43,47], and we provide formal definitions of security requirements.
The following global variables and oracles are used in all security definitions.Global Variables.HU : the set of honest users' identities; CU : the set of corrupt users identities; (U P K, U SK): the list of users' public and secret keys; (CRE D U , AT T R U , CID U ): the list of user credentials, user attributes sets, and user identities; (T KT , V P tkt , T ID U , T ID S ): the list of tickets, valid period of tickets, user identities, and seller identities; HS: the set of honest sellers' identities; CS: the set of corrupt sellers' identities; (S P K, SSK): the list of sellers' public and secret keys; (CRE D S , CID S ): the list of sellers' credentials and identities. Oracles.
• O HU (i): an oracle that can be used to generate keys for an honest user i.If i ∈ HU or i ∈ CU , then it returns ⊥; otherwise, it creates honest user i by running (U SK[i], U P K[i]) ← UKeyGen(•).It adds i to HU and returns U P K[i].
• O HS (j): an oracle that can be used to generate keys for an honest seller j.If j ∈ HS or j ∈ CS, then it returns ⊥; otherwise, it creates honest seller j by running (SSK[j], SP K[j]) ← SKeyGen(•).It adds j to HS and returns SP K[j].
• O CU (i, upk): an oracle that can (optionally) be used to corrupt an honest user i with the public key upk.If i ∈ CU , then it returns ⊥.If i ∈ HU , then it removes i from HU and adds i to CU ; it searches u to fulfill the condition CID U [u] = i and returns (U ).Otherwise, it adds i to CU and sets U P K[i] ← upk.
• O CS (j, spk): an oracle that can (optionally) be used to corrupt an honest seller j with the public key spk.If j ∈ CS, then it returns ⊥.If j ∈ HS, then it removes j from HS, adds j to CS, and returns SSK[j].Otherwise, it adds j to CS and sets SP K[j] ← spk.
• O UReg (i, A): an oracle that can be used to issue a credential for an honest user i with the attribute set A. If i / ∈ HU , it returns ⊥.Otherwise, it issues a credential to i by running UReg(U(U SK[i], U P K • O SReg (j): an oracle that can be used to issue a credential for an honest seller j.If j / ∈ HS, it returns ⊥; otherwise, it issues a credential to j by running SReg(S(msk, SP K[j], SP K[j], pp) ↔ CA(S SK[j], pp)) → cred s and appends (cred s , j) to (CRE D S , CID S ).
• O Iss (i, j, D): an oracle that can be used to play an honest seller j issuing a ticket to an honest user i with the disclosed attributes set D = {a i } i∈D .If i / ∈ HU or j / ∈ HS, it returns ⊥; otherwise, it searches u and v to fulfill conditions CID U [u] = i and CID S [v] = j, then j issues a ticket to i by running Issue(U(U SK • O Iss U (i, j, D) : an oracle that can be used to play a curious seller j issuing a ticket to an honest user i with the disclosed attributes set D. If i / ∈ HU or j / ∈ CS, it returns ⊥; otherwise, it searches u to fulfill the condition CID U [u] = i and runs Issue(U(U SK , where the seller's side is executed by the adversary.If b = 0, it returns ⊥; otherwise, it appends (tkt, VP tkt , i, j) to (T KT , V P tkt , T ID U , T ID S ).
• O Iss S (j, i, D): an oracle that can be used to play an honest seller j issuing a ticket to a malicious user i with the disclosed attributes set D. If i / ∈ CU or j / ∈ HS, it returns ⊥; otherwise, it searches v to fulfill the condition CID S [v] = j and runs Issue(A(i, •) ↔ S(S SK[j], CRE D S [v], pp, P)) → ((tkt, VP tkt ), b), where the user's side is executed by the adversary.If b = 0, it returns ⊥; otherwise, it appends (tkt, VP tkt , i, j) to (T KT , V P tkt , T ID U , T ID S ).
• O Shw (i, j): an oracle that can be used to play a malicious verifier verifying a ticket for an honest seller user i.If i / ∈ HU , it returns ⊥; otherwise, it searches u to fulfill conditions T ID U [u] = i and T ID S [u] = j and runs Show(U(U SK , where the verifier's side is executed by the adversary.If b = 0, it returns ⊥; otherwise, it returns (dsid, dstrace).
We define the security model of the PriTKT system as follows.
Unforgeability.Unforgeability can protect honest sellers and verifiers from malicious users.It guarantees that users cannot forge credentials in the Issue algorithm or tickets in the Show algorithm.An adversary can interact with the CA and honest seller oracles as a corrupted user to model this property.The adversary wins when they can forge a credential or a ticket of either an honest or an unregistered user in the Issue or Show algorithm.Unforgeability is defined by dividing it into credential unforgeability and ticket unforgeability.Definition 2. Experiment Exp u f cred in Pse. 1 defines the unforgeability of credentials.The users' credentials are considered unforgeable if any PPT adversary A can access the oracle ∈ HS ), return 0; 5.Return 1.
Pseudocode 1. Unforgeability of Credentials Definition 3. The experiment Exp u f tkt in Pse. 2 defines the unforgeability of tickets.In order for users' tickets to be considered unforgeable, it must be the case that any PPT adversary, denoted as A, who has the oracle O that contains O HU (i), O CU (i), O HS (j), O UReg (i, A), O SReg (j), O Iss (i, j, D), O Iss S (j, i, D), and O Shw (i, j), will have a negligible function ϵ(λ) such that ∈ HS ), return 0; 5.Return 1.

Pseudocode 2. Unforgeability of Tickets
Unlinkability.Unlinkability is necessary to safeguard honest users from inquisitive sellers and verifiers.Its primary purpose is to prevent an adversary from controlling a corrupt seller (who also verifies) from associating a specific credential with a particular user in the Issue algorithm or from tying a specific ticket to a particular user in the Show algorithm.To formally define this property, we allow the adversary to interact with the CA and honest user oracles playing the part of the corrupted seller.In the subsequent challenge phase, the adversary can invoke extra interactions and attempt to determine which user they are interacting with.If they correctly guess the user, the adversary wins.To define this property, we divide unlinkability into unlinkability of credentials and unlinkability of tickets.Definition 4. The experiment Exp ano cred −b depicted in Pse. 3 defines the unlinkability of credentials.We consider users' credentials to be unlinkable if, for any PPT adversary, A with access to the oracle O = {O HU (i), O HS (j), O CS (j), O UReg (i, A), O SReg (j), O Iss (i, j, D), O Iss U (i, j, D), O Shw (i, j)} there exists a negligible function ϵ(λ) such that associate a specific ticket with a particular user.There exists a negligible function ϵ(λ) such that

Anonymity of Tickets
Framing Resistance.In defining framing resistance, we follow the idea of Bobolz et al. [23].Framing resistance ensures that corrupt sellers cannot falsely accuse honest users of double spending.To model this property, we allow the adversary to interact with the CA and the oracles of the honest users in the role of a corrupt seller.Honest users will not engage in double spending.The adversary outputs a double-spending blame information dsblame.If there is an honest user's public key upk ′ that verifies dablame and upk ′ with VerifyDS, then the adversary wins.Definition 6.The framing resistance property is defined by the experiment Exp f r in Pse. 5.The e-ticket system is framing-resistant if, for any PPT adversary A having access to the oracle verify Π 1 , verify e(B i , g)

Overflow of PriTKT
PriTKT's workflow, illustrated in Figure 1, operates in the following manner.The CA initializes the system by issuing a system parameter pp and a set of ticket purchase policies P (Setup, step 1 ⃝).Upon joining the system, the Seller (S) creates a private-public key pair (ssk, spk) by running SKeyGen, authenticates to the CA, and obtains their public key credentials cred s (SReg, step 2 ⃝).The User (U) generates the private-public key pair (usk, upk) using UKeyGen, authenticates to the CA, and obtains their attribute-based credentials cred u (UReg, step 3 ⃝).To obtain a ticket, U verifies their identity to S by providing a disclosure proof for selective attributes (including attributes D ⊂ A) and S generates a ticket tkt for U (Issue, step 4 ⃝).Upon presenting the ticket, U anonymously proves its validity to Verifier (V) and discloses its validity period VP tkt and double-spending identity dsid (Show, step 5 ⃝).V can traverse the token information in the blockchain and verify whether a double-spending event has occurred.In case of attempted double-spending, V can trace U's public key upk ′ using a ticket tkt and generate blame information (DSTrace, step 6 ⃝).Using this blame information, any entity involved can verify the accuracy of the double-spending trace (VerifyDS, step 7 ⃝).

High-Level Overview
In this section, we present a specific implementation of the e-ticket system defined in Section 4. The main challenge in developing the e-ticket system is creating efficient and unlinkable ticket issuance and show algorithms.The classical solution used in this regard consists of zero-knowledge proofs that prove the knowledge of hidden attributes, where those attributes are signed by a certification authority or a signer.Han et al. [18] have proposed an attribute-based e-ticketing system using this approach, and to date this remains the only such system.Han et al.'s system includes a privacy-preserving e-ticketing system with attribute-based credentials, BBS signatures, and NIZK.While this solution fulfills privacy requirements, the system is very costly, with the Issue algorithm's computational complexity being O(N), where N is the number of user attributes.This significantly limits its practical use.Another strategy is to use specific signatures to prove knowledge of a subset of user attributes.The URS signature [20,44] is a constant-size signature that proves K out of N attributes, and its computational complexity is O(N − K) for the prover and O(K) for the verifier.Sanders [20] has proposed an extremely efficient URS scheme that can easily unlink without cost.Therefore, we have chosen to use Sanders' URS scheme to create the attribute credentials cred u and tickets tkt.URS ensures that the displayed credentials cannot be linked and supports the proof of attribute disclosure.The most important advantage of URS is that it uses randomization proof technology, avoiding the need for complex zero-knowledge proofs.
Because the private key of S is used to issue tickets to U, S generates the public-private key pair of URS, and the CA must issue the credential for the public key of S. SPS [21] allows us to effectively implement credential issuance for URS public keys.
The tickets are designed as single-use tickets, with a need to prevent double-spending by users.Moreover, in the case of double-spending, a user's public key needs to quickly be traced.To meet these requirements, we use the "Schnorr trick" [23].When presenting tickets, a user discloses their double-spending identity dsid to the verifier; the verifier can instantly detect double-spending if a similar identity was used earlier.Specifically, every time a user shows a ticket, they create a challenge value c ′ and calculate s ′ = dsrnd + usk • c ′ , employing the "Schnorr trick".When double-spending occurs, the user is required to show s ′ = dsrnd + usk • c ′ in the first show and s ′ = dsrnd + usk • c ′ in the second show.The zeroknowledge proof of knowledge ensures that usk and dsrnd are the same for both shows, while (s ′ , s ′ , c ′ , c ′ ) enables the verifier to calculate usk.If a user does not double-spend, usk remains perfectly hidden in s ′ (because dsrnd is only used once) and each displayed dsid is simply a random identity.2: , T 1 ).24: store the ticket tkt = ( T 1 , T 2 ) Pseudocode 8. Issue Tickets Algorithm selects an attributes set D to disclose in order to satisfy a ticket purchasing policy selected by S from the policy set defined by CA.U then generates a new Pedersen commitment psu which commits a private key usk, double-spending identity dsid ′ , and double-spending random dsrnd.U constructs a ZKSoK (Π 3 ) to prove that U knows the knowledge of (usk, dsid ′ , dsrnd) and that psu and cred u have the same usk.If Π 3 is verified as valid, S can update the Pedersen commitment psu homomorphically without knowing the opening, then produces the ticket tkt, contributes to double-spending identity dsid ′′ of S, and clarifies the ticket's valid period VP tkt .S then sends tkt, dsid ′′ , and VP tkt to U, who uses them along with U's private key to verify the validity of the ticket.
Show(U(usk, tkt, VP tkt , spk, pp) ↔ V(spk, pp)) → ((dsid, dstrace), b): as shown in Pse. 9, U interacts with V to show the ticket tkt.To prevent replay attacks, V first chooses a random nonce to send to U. U anonymously proves the legitimacy of tkt to V and discloses dsid and VP tkt .Then, U computes the challenge c ′ and s ′ = dsrnd + usk • c ′ to enable V to reveal the user's public key in case of double-spending.Finally, U needs to compute Π 4 to ensure that the dsrnd in the tkt is the same as in s ′ .If Π 4 is verified, V checks all tickets in the history with the same dsid to detect whether the ticket has been double-spent.If not, V uploads (dsid, dstrace) to BC and outputs b 1; otherwise, b = 0.Then, V traverses the token information in the blockchain and verifies whether a double-spending event has occurred.In case of double-spending being detected, V outputs dsid to link double-spending tickets and uses dstrace to trace the double-spending user's public key.
DSTrace(dsid, dstrace, dsid, dstrace, spk, pp) → (dsblame, upk ′ ): if U spends the same ticket a second time, this algorithm can be operated by V.If U only spends their ticket once, then usk is perfectly hidden.However, in the case of double-spending V can detect whether the dsid of the current ticket is the same as the dsid of a ticket that was spent before.This allows V to compute the private key usk of a double-spending user based on the fact that double-spending of the same ticket involves the same dsid and two different challenges allowing V to extract usk with overwhelming probability by parsing {dsid, dstrace = (s ′ , c ′ )} and {dsid, dstrace = (s ′ , c ′ )}.If dsid = dsid, dsblame = s ′ −s ′ c ′ −c ′ is output and upk ′ = g dsblame ; otherwise, ⊥ is output.It should be noted that because the user generates c ′ by using a random nonce selected by V every time a ticket is shown, there is an overwhelming probability that generation of two different c ′ will be forced when a ticket is double-spent.
The details of the zero-knowledge signature of knowledge of the proposed system are shown in Supplemental Material Section S3.

Security Analysis
In Supplementary Material Section S1, we analyze the correctness of the proposed system.To formalize that our construction from Section 4.2 satisfies all the desired security guarantees defined in Section 3.2, we define the following theorems.Let Π 1 , Π 2 , Π 3 , Π 4 be ZKSoKs.See Supplementary Material Section S2 for the formal proofs.Theorem 1.In the PriTKT system, the user's credential is unforgeable if the DL assumption holds in G 2 and if the URS is unforgeable.Theorem 2. In the PriTKT system, the user's tickets are unforgeable if the DL assumption holds in G 2 and if the URS is unforgeable.Theorem 3. In the PriTKT system, the user's credential is unlinkable if the DDH assumption holds in G 2 .Theorem 4. In the PriTKT system, the user's tickets are unlinkable if the DDH assumption holds in G 2 .
Theorem 5.The PriTKT system is framing-resistant if the DL assumption holds in G 2 .

Performance Analysis 7.1. Theoretical Analysis and Comparison
Table 2 presents a detailed comparison of PriTKT and related works, including four e-ticket systems [12][13][14]16], one attribute-based issuance e-ticket system [18], and five attribute-based credential schemes [35,36,39,40,43].The comparison evaluates each system in terms of formal security proof, double-spending detection, double-spending trace, attribute-based issuance, and attribute disclosure.Formal proof refers to an e-ticketing system's security verification through formal methods.Double-spending detection ensures that an e-ticket cannot be reused after it has been spent, while double-spending trace allows for the identification of the responsible user when a ticket is spent twice.Attributebased issuance allows for the issuance of tickets or credentials based on user attributes.Finally, attribute disclosure refers to the method used by users to reveal a subset of their attributes in order to purchase or display tickets.Of the e-ticketing systems included in the study, all those listed in [12][13][14]16,18] feature double-spending detection, while the systems in [14,18] offer double-spending trace and formal security proof.Furthermore, Ref.
[18] employs complex zero-knowledge proofs (ZKP) to issue tickets based on attributes, while the attribute-based credential schemes discussed in [35,36,39,40] use ZKP to issue credentials.Lastly, the attribute-based credential schemes in [43] offer formal proof and attribute-based issuance, with the efficiency of attribute disclosure improved by replacing ZKP with SPS-EQ.However, this scheme fails to prove that the user's hidden attributes satisfy certain requirements.In comparison, PriTKT boasts formal proof, double-spending detection, double-spending trace, attribute-based issuance, and attribute disclosure.The URS signature used in PriTKT avoids the complexity associated with the use of ZKP in [18].
Tables 3-5 show that the system in [18] is inefficient; a ticket issued on an attributebased credential (Issue U ) requires at least O(N) operations in order for a user to disclose K attributes out of a total of N attributes.In addition, it is necessary to prove knowledge of all N attributes, which implies that at least O(N) elements must be sent in communications during the execution of the Issue algorithm.Our algorithm avoids this problem, significantly reducing the computational cost to O(N − K) operations and the communication cost to O(K) elements.
In PriTKT, the computational overhead of Setup and the storage overhead of pp are both O(N 2 ).Fortunately, system initialization only needs to be performed once, and the system parameters pp are stored on users' IoT devices (such as smartphones), which have more than enough storage space.In PriTKT, the user credential cred u , seller credential cred s , and ticket tkt all have constant sizes.While the operations on Issue U are related to the number of user attributes, they decrease with the number of disclosed attributes.The operations for Issue S depend only on the number of disclosed attributes.The computation and communication overhead of Show and DSTrace are constant in PriTKT.

Experimental Analysis of PriTKT
We further evaluated the performance of the PriTKT system through objective tests.We implemented the system and measured its performance on an Android 9.0 operating system running on a HUAWEI Honor 9i smartphone, which had a Hisilicon Kirin 659 (ARMv8-A) CPU with a clock speed of 2.36 GHz and 1.7 GHz and with 4 GB of RAM.
We performed experiments utilizing MIRACL [48] and Type-III pairing.We used SHA256 to implement the H : {0, 1} * → Z p hash functions required by PriTKT (see Pseudocodes 8 and 9).To accurately evaluate the computational and storage/communication overhead of each of PriTKT's algorithms, we used the Barreto-Naehrig curve (BN-256) [49].BN-256 was used to test the system's performance at the AES 100-bit security level, and we compared it to the performance of a scheme [18] using the Security Supersingular Elliptic Curve (SSP-1536) [50] at the same security level.
In practice, the total number of user attributes N can reach hundreds, and is usually much larger than the number of a user's disclosed attributes K.For example, a user may have name, id, student, phone, number, occupation, home, address, and many other attributes.If the user buys a student discount ticket, they only need to provide their student attribute.Therefore, we compared the computation and storage/communication costs with a larger number of N and a constant number of K = 5.
Tables 6-8 compare the computational and storage/communication overheads of all algorithms between PriTKT and [18] at N = 50, where each time result is averaged over 50 iterations.
As shown in Table 6, in PriTKT the Setup algorithm takes 44.2 s.For key generation, UKeyGen and SKeyGen cost 18.1 ms and 143.6 ms, respectively.For user registration, UReg U and UReg CA cost 642.8ms and 95.5 ms, respectively.For seller registration, SReg S and SReg CA cost 1024.3ms and 1543.2 ms, respectively.The DSTrace algorithm takes 18.5 ms.Most frequently used of e-tickets rely on two algorithms, namely, Issue and Show.When issuing a ticket, the computation overheads of the Issue U algorithm are 1971.4ms for PriTKT and 561,049 ms for the scheme in [18], while the computation overheads of the Issue S algorithm are 908.2ms for PriTKT and 201,506 ms for the scheme in [18].When showing a ticket, the computation overheads of the Show U algorithm are 320.4ms for PriTKT and 79,544 ms for the scheme in [18], while the computation overheads of the Show V algorithm are 804.3ms for PriTKT and 69,924 ms for the scheme in [18].
As shown in Table 7, the storage of public parameters pp in PriTKT is 348,816 bytes, which is significantly larger than the 2584 bytes required by the scheme in [18]; however, we note that public parameters can be stored in smartphones with sufficient storage space.The other size overheads are similar for both PriTKT and the scheme in [18].
As shown in Table 8, the communication overheads of the Issue U algorithm are 1856 bytes for PriTKT and 6640 bytes for the scheme in [18], while the communication overheads of the Show U algorithm are 1568 bytes for PriTKT and 1824 bytes for the scheme in [18].For both the Issue S and Show V algorithms, the communication overheads of both PriTKT and the scheme in [18] are less than 1000 bytes.Table 9 shows that the computational overhead of the Issue U algorithm in both PriTKT and the scheme of Han et al. [18] increases linearly with the number of user attributes.However, PriTKT performs over 250 times more efficiently than the scheme of Han et al.For the Issue S algorithm, the computational overhead of both schemes are independent of the number of user attributes.Nonetheless, PriTKT is around 200 times more efficient than the scheme of Han et al.In the case of the Show U and Show V algorithms, the computational overhead of both schemes are independent of the number of user attributes.However, PriTKT executes around 240 times and 80 times more efficiently in the Show U and Show V algorithms, respectively, compared to the scheme of Han et al.
As shown in Table 10, the communication overheads of PriTKT are constant for both the Issue and Show algorithms.The communication overheads of the Issue U , Issue S , Show U , and Show V algorithms in PriTKT are as low as 1856 bytes, 904 bytes, 1586 bytes and 120 bytes, respectively.In comparison, while the scheme in [18] achieves a constant communication overhead for the Show algorithm, for the Issue U algorithm its output size increases linearly with the number of user attributes.
Compared to the state-of-the-art described in Han et al. [18], the above analysis and comparison reveal that PriTKT incurs significantly less computational and communication overhead.

Conclusions
This paper presents a blockchain-enhanced privacy-preserving e-ticketing system for IoT devices.The proposed system permits users to purchase tickets anonymously by revealing some of their attributes while concealing others.The proposed system presents significantly reduced computational cost and communication overhead compared to state-of-the-art e-ticketing systems, making it suitable for use in IoT devices.Moreover, it utilizes blockchain technology to achieve effective malicious user tracking.The system possesses robust security properties such as unlinkability, unforgeability, non-double spending, nontransferability, and framing resistance.The security properties are formally defined, and we have reduced them to well-known complexity assumptions or the security of proven cryptography primitives.We implemented the algorithms of the e-ticketing system on a smartphone, demonstrating that the system generates significantly lower computational and communication overhead compared to the state-of-the-art.

5 .
pp, P); 5.Return b * .Pseudocode 3. Anonymity of Credentials Definition Experiment Exp ano tkt −b in Pse. 4 defines the unlinkability of tickets.Users' tickets are unlinkable if any PPT adversary A with the oracle O = {O HU

Table 9 .
Computation overhead of Issue and Show (ms).

Table 10 .
Communication overheads of Issue and Show (B).