# Anonymous Access System with Limited Number of Uses in a Trustless Environment
## 1 Introduction  
Privacy is, nowadays, one of the biggest challenges in our digital life [1]. Anonymity seems to be a way to solve the challenge of maintaining privacy. Anonymous credentials [2], which assert an identity while maintaining privacy, are the most widely accepted. Anonymous credentials are commonly implemented as attribute-based credentials or ABC [3], and they guarantee the protection of user data and preserve privacy and anonymity. It is based on trusted entities, also known as the Attribute Provider \(\mathcal{AP}\), that generates irrefutable cryptographic evidence about the user's attributes. These proofs are called Verifiable Attributes (VA). Furthermore, users store these VAs and use them wherever and whenever they want. Users can subsequently use the VAs to demonstrate possession of the attributes to a third party without revealing their identity if the VA does not identify them, and the third party can verify those attributes if it trusts \(\mathcal{AP}\). For example, a user wants to purchase an age-restricted item on a website but wishes to remain anonymous, avoiding sharing their name, age, or date of birth. To do so, a VA can be obtained from the Civil Registry, which will act as \(\mathcal{AP}\). However, as stated in article [4], these credentials are of no use when repeated uses must be detected. The article proposes a method for detecting credential reuse using a unique, anonymous identifier that cannot be linked to the user's real identity. The main objective of this proposal is to extend the protocol presented in [4] in such a way that it allows the control of a maximum number of usages of a given credential. Such enforcement is carried out using blockchain technology through the implementation of Smart Contracts, a tool that provides the required robustness and transparency for authentication environments. It allows the user to have control over increments by forcing the need to provide a Zero Knowledge Proof (ZKP) that proves the possession of a privatekey and the agreement on the value to be incremented. This, at the same time, prevents replay attacks. This is achieved by agreeing on the counter's increment. The system involves three different entities: the User (\(\mathcal{U}\)), an Attribute Provider (\(\mathcal{AP}\)), accountable for proclaiming certain user attributes, and a Service Provider (\(\mathcal{SP}\)), granting access to a service. As detailed in the use case in Section 6, consider a user (\(\mathcal{U}\)) whose income is below the minimum wage, a requirement certified by \(\mathcal{AP}\). This user is then granted thirty free underground trips per month. The process involves \(\mathcal{U}\) obtaining credentials from \(\mathcal{AP}\), storing them locally, and presenting these blinded credentials along with proof of private key possession to \(\mathcal{SP}\). By use of a Smart Contract, \(\mathcal{SP}\) verifies \(\mathcal{U}\)'s data and initialises the counter on the blockchain. Subsequently, for each use, \(\mathcal{U}\) must provide a unique identifier and proof of access verification, which \(\mathcal{SP}\) will verify using the same Smart Contract. Ethereum [5], a well-known blockchain technology, offers a decentralised, Turing-complete computer. This platform enables reliable and publicly verifiable execution of Smart Contracts, making it particularly suitable for enforcing security checks. This research proposes a set of Smart Contracts designed to manage the entire life cycle of a counter on the Ethereum network. The rest of this article is structured as follows. Section 2 reviews the current state of the art in electronic ticketing proposals, focusing on privacy implementations and other key goals. Section 3 introduces the protocol to be enhanced with the improvements discussed above. Section 4 explains how to achieve the objectives and provides a detailed description of the protocol. Section 5 details the security evaluation of the proposed solution, and Section 6 explores, in detail, a use case of the proposed protocol.