Composable Anonymous Proof-of-Location With User-Controlled Offline Access

A proof-of-location (<inline-formula> <tex-math notation="LaTeX">$pol$ </tex-math></inline-formula>) is a digital credential issued to a user after proving their location to an issuer. The user can use the <inline-formula> <tex-math notation="LaTeX">$pol$ </tex-math></inline-formula> at a later time to prove to a verifier that they have been present at a claimed location. A secure Proof-of-Location (POL) system requires that <inline-formula> <tex-math notation="LaTeX">$pol\text{s}$ </tex-math></inline-formula> be unforgeable and non-transferable to other users. POL systems can be used to provide fine-grained authentication and authorization and must ensure the privacy of the <inline-formula> <tex-math notation="LaTeX">$pol$ </tex-math></inline-formula> owner against the issuer and the verifier while allowing efficient presentation of <inline-formula> <tex-math notation="LaTeX">$pol\text{s}$ </tex-math></inline-formula> combined with other credentials when needed. Efficiency is in terms of communication overhead in user-verifier POL sessions, which has particular significance in high-volume <inline-formula> <tex-math notation="LaTeX">$pol$ </tex-math></inline-formula> verification scenarios. We first propose a POL system that (i) is provably secure in a simulation-based framework, allowing a <inline-formula> <tex-math notation="LaTeX">$pol$ </tex-math></inline-formula> to be securely used with other credentials, and (ii) provides anonymity against the issuer and the verifier. We then extend the system to allow <inline-formula> <tex-math notation="LaTeX">$pol\text{s}$ </tex-math></inline-formula> to be stored on a public distributed ledger system and selectively be presented to the verifiers by the user. This is the first POL system that satisfies the above properties. We implement POL algorithms on a mobile phone and present our experimental results showing the practicality of the system. Our proposed scheme is highly scalable compared to existing systems, reducing the user-verifier POL communication overhead by up to a factor of 94.


I. INTRODUCTION
Proof-of-location (POL) systems [1], [2], [3], [4], [5], [6], [7], [8] offer a compelling solution for providing trustworthy evidence of user location in applications like gaming, supply chain, and workflow compliance. A POL system issues tokens, called proof-of-location or pol, to entities, indicating their presence at a particular geographic location. The token is tied to the entity's identity and can be verified by verifiers with access to the public parameters of the system. A pol can be presented as a credential to an authorization system to satisfy location-dependent access policies, such as securely counting the visits to a place, estimating the length of stay at a location, or granting access to area-specific resources like WiFi.
The associate editor coordinating the review of this manuscript and approving it for publication was Junggab Son .
Security and Privacy Requirements: There are three main security properties for POL, (i) unforgeability: a pol token can only be generated by a valid issuer, for a valid user, for a valid location, and (ii) non-transferability: a pol issued to user U 1 cannot be used by user U 2 . (iii) Anonymity: userprivacy is an essential requirement of a POL system. Ideally, the user's interactions with the issuers and the verifiers must remain anonymous and unlinkable, and this must hold even when issuers and verifiers collude. In cases where pols are stored on the cloud or trusted public storage, the user must control who can access and see the pols. This can be seen as a privacy-related property where the user controls access to their personal information, reminiscent of the self-sovereign identity [7], [9] approach.
pol Storage and Presentation: In a basic self-sovereign approach the user stores pol tokens in an (electronic) wallet, together with their other credentials, and presents them at will and as needed. This approach, however, has limitations: i) the number of pols needed to be stored on the user's device grows significantly over time as the user travels, ii) the inherent risk of data loss when the device is lost, and iii) the requirement of user and verifier be online and actively interacting each other at the time of pol verification.
We take a distributed ledger (DL) based approach for pol storage, as this enables -(a) pols to be robustly accessible to users at any time and from anywhere, (b) users can store their pols and manage access to them according to their own policies and requirements, and (c) the integrity of the stored data is ensured (security can be achieved by the user encrypting their stored data). Moreover, the pol storage must be such that it can be used by applications that require ordering of pol tokens based on the time of issuance, such as proving the travel path of a product in supply chain management, without relying on a global clock. While offline accessibility of pol has been considered before [2], [3], [10], none of the systems consider user-controlled access to their pol tokens, and achieve user anonymity with respect to the pol verifier.
Security Model and Proof: Existing POL systems [1], [2], [3], [4], [5], [6], [7], [8] either provide game-based security model or informal arguments to prove security for an instance of the POL protocol and so lose their guarantee when composed with other protocols. Our simulation-based security allows POL systems to be securely composed with other cryptographic protocols. This is important for POL systems that are often used as a component of a more complex security system such as an identity management system.

A. OUR CONTRIBUTION
We first propose a POL system where the user stores pol tokens on its device, and prove the security of pols against malicious (adversarial) users, and privacy of pols against the issuer and verifier, using ideal/real world paradigm. We then extend the system to store the pols on a distributed ledger system and provide user-controlled access to the stored pols. Storing on the ledger enables ''time relation'' between the subset of pols that is an essential requirement in many applications such as supply chain management, without using a global clock.

1) AN EXAMPLE APPLICATION
The essential use of mobile location data for contact tracing and enforcement of quarantines by the public and private sectors is worrisome to Human Rights Watch because this data typically includes revealing insights regarding the identities, locations, behaviors, associations, and activities of individuals [11].
In our example scenario, a POL system is used to enforce a quarantine period for international travelers. Once the traveler is registered to the system, they can periodically (e.g., once an hour) collect pol token from the issuer (e.g., cell tower), that would be later used by the authority (pol verifier) to make decisions on further quarantine requirement. The POL system should remain secure even when an attacker uses related inputs to run many protocol instances (composability). Also, the pol issuer or the verifier must not learn anything about the user other than the fact that a registered user followed the protocols correctly, and the verifier can only request the registration authority to reveal the identity of the user once the user fails to report location data according to the government policy (anonymity). This follows the international human rights law -''measures taken that limit people's rights and freedoms must be lawful, necessary, and proportionate.'' [12]. Moreover, the verifier may not want to verify the pols immediately, since the number of people required to go through quarantine may be high, and this will drastically degrade the network and system performance. Verifier wants the user to store the location data on a trusted storage other than their device and wants to receive only a token that is much smaller than the actual proof-of-location and can be used to access the actual pols at a later preferred time (user-controlled offline access).
The application above has the following requirements, (i) the protocol needs to be secure in a simulation-based framework and provides composability, (ii) it provides anonymity against the issuer and verifier, and (iii) usercontrolled offline access of pol, with small user-verifier communication overhead. POL systems are widely studied [2], [3], [4], [5], [6], [7], [8], [10], [13], but none of them satisfies these requirements. Below we give an overview of how we meet these requirements in the proposed POL scheme.
i. POL Systems With Simulation-Based Security: We define POL security in the simulation paradigm, define an ideal world description that specifies the interaction of the entities and guarantees unforgeability, non-transferability, and user anonymity. We consider a setting where the users register with a registration authority (RA), and receive signed certificates on their secret by the RA. Using a randomized version of the secret, the users can interact with a trusted issuer (location infrastructure) that verifies the registered users' locations and issues pol tokens to them. The token can be verified by any verifier with access to the public key of the issuer and the RA. A pol token can be seen as a credential that is issued to a user certifying their presence in an area that is determined by a (public) area segmentation map provided by the infrastructure provider. Unlike many other credentials, a user may receive many pols over time. A user may need to use pols individually, or as a sequence verifying their presence at consecutive designated locations over time. We assume the infrastructure provider has nodes that are distributed in the area of interest, and the location of the user is determined by their proximity to a close node. Location information will be verified in real-time at the request of the issuer and is embedded in the pol that is signed by the issuer.
For security proof, we use simulation-based security and follow the composability framework of Canetti [14] where security is by comparing the execution of the protocol with an ideal world execution, and requiring the two are not distinguishable from the viewpoint of the environment. To make our results more general, we abstract out the location VOLUME 11, 2023 50885 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. verification protocol by using an ''ideal functionality'' for location verification and so use a hybrid world to model real-life execution of the protocol, specifying the ideal functionalities for pol issuance and verification. Using an ideal functionality for location verification will also avoid the need to formally model the ''physical'' property of distance/proximity in the simulation paradigm. Modeling physical properties in this paradigm is an active research area with many subtleties [15]. Our work is the first in a long line of research on POL [2], [3], [4], [5], [6], [7], [8] that provides simulation-based security and allows composability. Following the work of [16] on anonymous credential systems, we only consider sequential composability that allows the composition of protocols one after the other, which appears sufficient in a wide range of applications, and prove the security of our proposed POL system in this framework.
ii. POL Anonymity With Respect to Issuer and Verifier: Our construction achieves full anonymity, which is defined by the inability of the pol issuer or the verifier to link multiple pol credentials that were issued to a particular user. Being built on cryptographic blocks such as zero-knowledge proof-ofknowledge and commitment scheme, the proposed scheme achieves this by (i) allowing the user to choose a different pseudonym in each protocol session with the pol issuer, and thus guaranteeing anonymous authentication with the issuer, and (ii) obtaining a pol credential that is independent of all previous pol credentials owned by the user, guaranteeing inability of the verifier to link multiple pols together.
iii. POL With User-Controlled Offline pol Accessibility: A user, who may collect many pols, needs to store the pols securely and reliably and be able to present them to verifiers individually, or a subset of them, possibly in the order of issuance. We extend the POL model and the construction to include a public ledger that is accessible by everyone and will be used to store the user's pols. To provide user control on the pols, that is allowing them to selectively make the pols available to verifiers, the pols will be stored in encrypted (symmetric key encryption) form on the ledger, and the user will provide access to them by issuing ''access tokens'' to the verifiers that include the index (to search for the pol) and the key (to decrypt the pol). This will allow verification of the pol token to be performed without having an interactive session between the user and the verifier. The new setting will require a new security model and will extend the hybrid world model to include a ledger functionality, that is an abstraction of a public permissioned ledger (i.e., can be read by everyone, and only selected entities can write onto it).
iv. Implementation and Experiments: To estimate the time complexity of cryptographic operations that are needed in our POL system, we give a proof-of-concept implementation of our proposed POL system. We used Idemix Java library 1 on an off-the-shelf android smartphone and a MacBook Pro 2016. The library is developed by IBM Security Research and is widely used for anonymous credentials. We use the 1 www.zurich.ibm.com/idemix library to implement the cryptographic components of the protocol including commitment, zero-knowledge proof, and CL-signatures (see Section II for a description on these primitives). The required time for the issuer and the user in the pol generation protocol are 202 and 185 milliseconds, respectively. The size of the pol stored in the user device is less than 2 kilobytes. We provide a comparison of user-verifier communication efficiency among our proposed POLs and Gambs et al. [8] and show that the proposed POL with offline pol accessibility reduces the overhead by a factor of 94. Details are in Section VII.

2) ORGANIZATION
Section II covers preliminaries, while Section III outlines the system description and the simulation-based security model for POL. Our construction and security analysis are presented in Section IV, and Section V introduces POL with offline pol accessibility and its security proofs. An implementation of the ideal functionality for user location verification is provided in Section VI, and our experiments are detailed in Section VII. The related work is discussed in Section VIII, and the paper concludes in Section IX.

II. PRELIMINARIES
We first recall cryptographic primitives used in this paper.

A. PUBLIC KEY ENCRYPTION
Three algorithms define public key encryption: a key generation KeyGen(1 λ ) → (pk e , sk e ) generating a publicprivate keypair, an encryption Enc(pk e , m) → C encrypting a message m with the public key pk e and a decryption Dec(sk e , C) → m decrypting a ciphertext using the private key sk e . The standard notion of indistinguishability under chosen-ciphertext (IND-CCA) attack [17] is considered for our work.

C. COMMITMENT SCHEME
In the Commitment stage of a commitment scheme, the committer, for a value x produces a commitment com, and in the Reveal stage, opens the commitment to a value x ′ . A commitment protocol is perfectly hiding if the receiver cannot learn anything about the committed value x after the Commitment stage. It is perfectly binding if in the Reveal stage, the committer can open the commitment only to the committed value x(x ′ = x). We use the commitment scheme from [19]. For security parameter λ, in KeyGen, a public key pk c = (n, g, h) is generated. n is a special RSA modulus, h ← QR n (QR n is the group of quadratic residues over n), g ← ⟨h⟩ (⟨h⟩ is the group generated by h). The commitment com = Commit(x, r) for a string x and a random string r ∈ Z n is computed as com = g x × h r mod n, and is sent to the receiver. In the reveal stage, the committer reveals the values x, r, for the receiver to verify that com = Commit(x, r). The commitment scheme is perfectly hiding and computationally binding if factoring is hard.

D. ZERO-KNOWLEDGE PROOF OF KNOWLEDGE
In zero-knowledge proof of knowledge protocol, a prover proves to a verifier that they know a value w satisfying some polynomial-time computable relation R, without exposing anything about w. We use Camenisch and Stadler's [20] representation of zero-knowledge proofs of knowledge, ZKPoK {(α, β, γ ) : y = g α h β ∧ỹ =g αhγ }. denoting a Zero-Knowledge Proof of Knowledge of integers α, β and γ s.t. y = g α h β andỹ =g αhγ are true, where y, g, h,ỹ,g andh are elements of some groups G = ⟨g⟩ = ⟨h⟩ andG = ⟨g⟩ = ⟨h⟩. Greek letters denote values the knowledge of which is being proved, and the rest of the parameters are known to the verifier.

E. DISTANCE BOUNDING PROTOCOLS
Distance bounding (DB) is a two-party protocol, prover and verifier, enabling the verifier to establish an upper bound on the distance from it to the prover. The technique uses the round trip time of radio signals. There are three phases in a DB protocol -initialization: prover and verifier agree upon a ''response table'', distance bounding: verifier sends random challenges which need to be answered by the prover using the response table, finalization: the verifier checks the correctness of the responses, and uses the round-trip time of messages in the distance bounding phase, to put an upper bound on the distance of the user from the verifier. Security of DB protocol is defined based on three main attacks: distance fraud (i.e., a dishonest prover attempts to shorten the distance computed by the verifier), mafia fraud (i.e., an external entity attempts to shorten the computed distance between an honest prover and the verifier) and terrorist fraud (i.e., a dishonest user far-away from verifier attempts to shorten the computed distance with the help of an external entity close-by the verifier). A description of these attacks can be found in Appendix A.
We also use AES symmetric key encryption in one of our constructions but skip the description for brevity.

III. POL SECURITY MODEL
We give formal definitions, requirements, and security model, provide a high-level description of the composability and show how to model a physical proximity checking functionality F LV . Next, we present the ideal functionality F POL for the proof-of-location scheme and discuss its security and privacy guarantees.

A. SIMULATION-BASED SECURITY MODEL FOR POL
We use the simulation paradigm to formalize the security definition for POL. In this framework, the security of a protocol is analyzed by comparing its real-world execution with its execution in an ideal world, where all the interactions are through an ideal functionality. Our model guarantees sequential composability, that is the protocol remains secure when many instances are executed sequentially, possibly on related inputs. Credential systems consist of a number of sub-protocols that are essentially called sequentially, making this framework a natural approach [16], [21], [22].
A basic proof-of-location system has users, issuers, and verifiers. Issuers check the location of the users and issue pol token. To ensure non-transferability, a trusted registration authority (RA) verifies that users carry an external public-private keypair while entering the system.
The ideal-world POL has an ideal functionality F POL , a set of ideal parties, the ideal-world adversary A I and the environment E. Environment E schedules periods, in each period it tells one honest player to initiate a protocol. The honest player tells functionality F POL which protocol to carry out and with whom; it also gives F POL required inputs for the protocol. F POL executes the trusted code for the protocol that may involve communicating with several other players. At the end of the period, the initiator player tells the environment E the outcome of the protocol. The adversary A I , who is controlled by the environment, can also send messages to and receive from F POL . The environment E has total control over all of the adversary's actions: the adversary A I forwards all the received messages to E, and then E tells the adversary A I which messages to send.
We construct our POL scheme in a hybrid world where an ideal functionality realizing a location verifying functionality F LV , an ideal functionality realizing a distributed ledger F LEDGER , and a random oracle RO, are available.
Functionality F LV : We define an ideal functionality that models secure location verification (Fig. 1). Users and verifiers are entities, each with a geo-location ℓoc = (x, y) ∈ R, where R is a well-defined coordinate system, and d(ℓoc 1 , ℓoc 2 ) is the planar Euclidean distance between two locations ℓoc 1 and ℓoc 2 . It is assumed that the functionality F LV maintains a continuously updated snapshot of the geo-locations of entities.
The functionality can be queried through the interfaces that it provides. An interface captures the location verification system that is used in a particular scenario. For this VOLUME 11, 2023  work, we introduce an interface named IsClose, that can be queried to verify the minimum (straight line) distance between two entities in the system. In the query to the interface, the input identity of entity P can either be a public identity (e.g., a public key), or a pseudonym of that party. For privacy requirements, in this paper, we use the latter.
Functionality F LEDGER : We follow the work of [23] to define a Functionality F LEDGER (see Fig. 2) that provides the abstraction of a public permissioned ledger. Intuitively, this ledger could be (read) accessed by all the protocol parties. Only listed parties can write on the ledger.
Random Oracle RO: Using [24]'s formalism, we model hash functions (H ) as random oracles. RO keeps a list L of pairs of bitstrings that is initially empty. If queried for a value q, it returns a random bitstring r and the pair (q, r) will be stored in L. Querying the same value twice will result in the same response from RO.

B. IDEAL FUNCTIONALITY FOR POL
We define the ideal POL functionality F POL supporting four protocols, Register, FormNym, IssuePol, and VerifyPol. In Register a login name U and a key K U are generated for the user. In FormNym a pseudonym N UI is established for the user U with the issuer I . In IssuePol a pol is generated for the user, after verifying its closeness to the issuer I . In VerifyPol protocol, a pol that is presented by the user, is checked by the verifier for its validity, which includes, (i) checking that U is a registered user who has a valid pseudonym registered with the issuer, and (ii) that the presented pol token was generated on this pseudonym by the issuer. F POL keeps three lists, L U , L N , L pol that record the list of users, their pseudonyms, and the pols. The description of F POL is given in Fig. 3.
Adversary: In both the ideal and real world, the adversary not only sees all the messages sent to the corrupted entities (users) but also upon corruption, the adversary gets hold of all the secret information and future actions of the corrupted entity. We only consider static adversaries, i.e., the adversary only gets to pick the entities it wishes to corrupt at the beginning of the system execution and is not allowed to dynamically corrupt new entities during the system run.
Security Properties: First, we define unforgeability, nontransferability of pol, and user anonymity w.r.t issuer and verifier, then give an informal discussion on how the ideal functionality F POL achieves these.
Definition 1 (POL Security): 1. Unforgeability: A pol that is verified by V , can only be generated by a valid issuer I for a valid user U who was within distance D of the issuer at the time of pol generation. 2. Non-transferability: A pol that was issued to user U , can be verified as the credential belonging to no one other than U by a verifier V . 3. Anonymity: Neither pol issuer nor pol verifier can link multiple pol credentials together that belong to a single user U .
pols cannot be tampered with as they are stored in L pol in functionality F POL , which also ensures that pol is issued to a valid user by a valid issuer, for a valid location, F POL achieves unforgeability. F POL authenticates the user using 50888 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply. the list L U and validates the pseudonym using the list L N in both issuing and verifying the pol, and ensures that the user U who presents a pol, is the one to whom the pol was issued. Thus, it achieves non-transferability. Since users are known to issuers only by pseudonyms, and a different pseudonym is used in each protocol session, F POL provides Anonymity w.r.t. the issuer. Similarly, the verifier cannot link two pols since each pol has a different pseudonym that is revealed to the verifier, and thus Anonymity w.r.t. the verifier is achieved. Linkability is also achieved, since U can prove ownership of multiple pols, by sending authentication information (U , K U ) to F pol , who can look up all the pols issued to U . POL Security Definition: Consider a protocol with access to the location verification functionality F LV , the ledger functionality F LEDGER , and the random oracle RO. The output of an environment E interacting with a protocol and an adversary A R on input 1 λ , is denoted as In the ideal world the parties do not interact with each other but only forward their inputs to an ideal functionality F POL . In this setting, we call the adversary a simulator Sim and denote the above output as IDEAL F LV F POL ,Sim,E (1 λ ). Definition 2 (Security of ): Let λ be a security parameter, be a protocol in the (F LV , F LEDGER , RO)-hybrid world.
realizes F POL in the (F LV , F LEDGER , RO)-hybrid world if for every ppt (probabilistic polynomial time) adversary A attacking , there exists a ppt algorithm Sim, such that where Sim has black-box access to the environment E. ''D 1 (1 λ ) ≈ c D 2 (1 λ )'' denotes computational indistinguishability of the distributions D 1 and D 2 .
Following the work of Lysyanskaya [16], we restrict the environment from scheduling multiple protocols (e.g., FormNym, IssuePol) to take place concurrently, making the notion of security less appealing than the universal composability (UC) definition. Nevertheless, our definition does ensure sequential composability by allowing the adversary to pass along its state between protocol executions, and in the next section we propose a scheme that achieves this for the first time in proof-of-location literature.

IV. POL CONSTRUCTION
The cryptographic POL construction uses a digital signature scheme, commitment scheme, and zero-knowledge proof of knowledge. The formal protocol description is given at the end of this section. First, we provide an outline of the scheme and a description of how the zero-knowledge proofof-knowledge is formed. We consider a security parameter λ, and assume that a list of pol issuers along with their locations are available to a fully trusted registration authority, RA. The POL system model is shown in figure 5.
The Registration authority registers users and issuers to the system. The verifiers can be anyone and are located anywhere in the world, and they do not need to be registered. In the case of issuers, RA generates the keypair for the digital signature scheme and attests the public key and role of the entity as pol issuer and publishes the certificate and public key on the public ledger using functionality F LEDGER . However, because of privacy, the user generates their own digital signature key pair and obtains a certificate from RA. Unlike traditional VOLUME 11, 2023 certificates which use a trusted authority's signature on a party's public key, the certificate provided by RA to the user is RA's signature on the user's private key (Cert U ← Sign(sk s RA , sk s U )). Signing the user's private key in this way has been done before in credential schemes [8], [16], [18]. The protocol is known as signing a committed value and is performed without RA knowing anything about the secret value that is being signed (sk s U ). Generating the user's certificate in this way helps us achieve POL anonymity, by allowing the user to authenticate themselves to an issuer/verifier, without revealing their identity.
A registered user forms a pseudonym with issuers (FormNym), which is actually a cryptographic commitment on the user's private key sk s U , which is sent to the issuer along with a zero-knowledge proof-of-knowledge (ZKPoK) stating that the pseudonym was correctly generated by a registered user. More specifically, on common inputs (p C , g C , h C ), N UI , pk s RA ) and user's private inputs (sk s U , r, Cert U ), the zero-knowledge proof of knowledge π can be written as: where (p C , g C , h C ) is the public parameters of the commitment scheme, N UI is the user's commitment on its secret sk s U , r is a random value used in this commitment, pk s RA is RA's signature verification key, and Cert U is RA's signature on user's secret sk s U . A protocol construction for this proof can be found in [18]. The proof is converted into a non-interactive proof (Non-interactive Zero-knowledge or NIZK) by applying the Fiat-Shamir heuristic [25] before sending it to the issuer. The issuer, upon validating the proof, sends an acknowledgment to the user. This pseudonym can later be used by the user to obtain pol from this issuer.
In IssuePol, the user first sends a pseudonym along with a non-interactive zero-knowledge proof of knowledge similar to that formed in FormNym. Once the pseudonym and the proof are verified, the issuer checks the proximity of the user by querying IsClose interface of the ideal functionality F LV . If the check is successful, the issuer generates proofof-location token pol. The pol token is a digital signature of the issuer on a message that includes the user's pseudonym, the issuer's location, and the issuer's public key. pol is then sent to the user.
In VerifyPol, the user U presents a pol together with a non-interactive ZKPoK to the verifier V , which enables them to verify that the pol is a valid pol for U without 50890 VOLUME 11, 2023 Authorized licensed use limited to the terms of the applicable license agreement with IEEE. Restrictions apply.
learning any information about the identity of U . Verifier validates the issuer's signature by looking up the issuer's information on the ledger using F LEDGER , and verifies the ZKPoK using the common inputs for the protocol. The use of a pseudonym and the ZKPoK to privately prove the possession of the pseudonym ensures the user remains anonymous to the verifier. Fig. 6 provides a detailed description of our proposed proof-of-location scheme .

A. POL SECURITY ANALYSIS
We assume the user does not share both the private key sk U and the certificate Cert U with other users since doing this will allow masquerading the user in all future pol issuance, which is generally undesirable for most users. Restriction on sharing the long-term secret is a standard assumption in proof-of-location schemes [2], [5], [6], [7], [8], [13]. Moreover, for user anonymity, it is required that the user does not share Cert U with the issuer or verifier, since doing so will trivially enable these parties to link multiple pol tokens to the user (since Cert U remains unchanged across all pol issuance/verification sessions), and thus breaking the anonymity definition.
To formally state the security of our proof-of-location scheme , we use the previously introduced simulationbased security notion. To prove Theorem 1 we describe a simulator Sim for our scheme.
Theorem 1: Assuming the zero-knowledge proof of knowledge protocol is sound and simulatable (zeroknowledge), and the digital signature scheme is secure against existential forgery, the proof-of-location scheme realizes (see Def. 2) the ideal proof-of-location functionality F POL in the (F LV , F LEDGER )-hybrid world.
Proof: We design a simulator Sim that has black box access to the real-world adversary. The simulator receives a list of corrupted users from the environment E. Fig. 4 illustrates the ideal world, the real world, and how the simulator translates a real-world adversary into an ideal-world one. The details of the simulator can be found in Fig. 7.
Let's consider an environment E that schedules v protocols. The i-th hybrid system, with i ∈ 0, 1, . . . , v, consists of the first i protocols simulated and the rest being real-world protocols. The zero-th hybrid represents the real-world system, while the v-th hybrid represents the fully simulated system. Assuming E can differentiate between simulated and real systems, it should be able to distinguish between (j−1)-th and (j-th)-th hybrids for some j ∈ 1, . . . , v. Only the j-th protocol separates the two hybrids, requiring E to distinguish between a simulated and a real-world j-th protocol. This distinction depends on the nature of the j-th protocol.
The simulator simulates the initialization (Init) phase and generates secret signing keys for the honest issuers.
1. Register User: Simulation is straightforward since F POL generates K U from the same distribution as the real world.
2. FormNym: If this is a FormNym protocol between a corrupted U and honest I , then the simulation is indistinguish-able because (i) the zero-knowledge proof is sound and Sim is able to extract sk s U . (ii) the number of users in the system is polynomially bounded and Sim can find the corresponding pk U s in polynomial time. If this is a FormNym protocol between a corrupted I and honest U , then the simulation is indistinguishable from the real world because the zero-knowledge proof is simulatable and provides zero-knowledge property.
3. IssuePol: If this is an IssuePol protocol between a corrupted U and honest I , then the simulation is correct since (i) zero-knowledge proof is sound and (ii) the signature scheme is unforgeable and (iii) F LV is a secure location verification protocol.
If this is an IssuePol between a corrupted I and honest U , the Zero-knowledge proof is simulatable (zero-knowledge) and hence Sim simulates π in an indistinguishable manner from the real π.
4. VerifyPol: If this is a VerifyPol for a corrupted U and an honest V , then the simulation is indistinguishable since the zero-knowledge proof is sound and Sim is able to extract sk s U from the corrupted user. If the corrupted user has not run the IssuePol before, then the corresponding proof is not in L pol , and 0 is returned to the verifier.
If this is a VerifyPol for a corrupted V and an honest U , then the simulation is straightforward for the passively corrupted verifier as it does not learn more information than an honest verifier from VerifyPol.

V. POL WITH OFFLINE pol ACCESSIBILITY
User-controlled offline access requires the pols to be stored on a distributed ledger such that the user can issue communication-efficient access tokens to the stored pols, and only reveals information of pols that the user wants to reveal.

A. IDEAL FUNCTIONALITY FOR POL WITH OFFLINE pol ACCESSIBILITY
We name the ideal functionality for POL with offline pol accessibility as F Off POL (Fig. 8). In addition to Register, FormNym, IssuePol and VerifyPol, this functionality supports IssueToken protocol where an access token is generated that can later be used to access a pol. In VerifyPol, the access token is used to access the pol and check its validity. By storing encrypted pol, and providing an access token to access its content, we can provide accessibility of pol by the verifier when the user is offline while letting them control who can access the pol.

B. CONSTRUCTION FOR POL WITH OFFLINE pol ACCESSIBILITY
The proposed cryptographic construction for POL with offline pol accessibility uses a digital signature scheme, a commitment scheme, a symmetric-key encryption scheme (AES), a one-way hash function, and zero-knowledge proof of knowledge. Figure 9 shows the POL system model.  certificate Cert U on their long-term secret sk s U . During their quarantine period, every time U requires to receive a pol from an issuer (e.g., cell tower), they form a new pseudonym N UI with the issuer. Then in IssuePol, once the user location is verified, they are issued a pol token by the issuer I , and an encryption (AES) of pol and a non-interactive zeroknowledge proof-of-knowledge π that claims user's ownership of pol, is stored on the ledger by I . The user knows the pol's index to search the pol and knows the key to decrypt it, which are later included in the access token that is generated by the user in IssueToken. Once the verifier receives the access token, they can obtain the encrypted pol and π from the ledger, decrypt the pol, and verify π to ensure it has been issued to the prover, as well as verify the issuer's signature in the pol. This allows the user to be offline at the time of verification, and the verifier who holds an access token, to proceed with pol verification at their will. The user is always in control of their pol tokens on the ledger.
Observe that in the proposed scheme, access to individual pol tokens is controlled by U , while the verifier is allowed to make their own schedule for accessing and verifying pols offline (Offline user-controlled access). Pseudonyms are used to authenticate users to both the issuer and the verifier, thus ensuring user anonymity. Our security model in the simulation paradigm and formal security proofs guarantee the sequential composability of POL, that is, even when multiple  . Once a pol is generated, I writes the encrypted pol on the ledger. The decryption key and an index (to search the pol on the ledger) are returned to U , who can use these to issue a pol access token to V . V , using index, retrieves the encrypted pol from the ledger, decrypts, and verifies.
executions of possibly different protocols are executed on related inputs, the POL remains secure.

C. SECURITY ANALYSIS
Formally proving security for the proposed POL (with offline pol accessibility) requires describing a simulator, and show- ing that the cryptographic construction π Off conforms to ideal world construction F Off POL and that the simulator translates any real world ppt adversary into an adversary in the ideal world.
Theorem 2: Assuming the zero-knowledge proof of knowledge protocol is sound and simulatable (zeroknowledge), the digital signature scheme is secure against existential forgery, the encryption scheme provides semantic security, and the hash function is collision-resistant, the proof-of-location scheme with offline pol accessibility Off realizes (see Def. 2) the ideal proof-of-location functionality F Off POL in the (F LV , F LEDGER )-hybrid world.
Proof: The simulator for the proof is given in Fig. 12. Proofs for Register and FormNym are similar to that presented in the proof of Theorem 1.
IssuePol: If this is an IssuePol protocol between a corrupted user and an honest issuer, then distinguishing between simulated protocol and real-world protocol will result from either (i) zero-knowledge proof protocol not being sound or correct, or (ii) the signature scheme is vulnerable to existential forgery, or (iii) F LV producing different output for same inputs, or (iv) E distinguishing an encrypted value from a random binary string, or (iv) Hash function not being collision resistant. All these cases give contradiction.
If this is an IssuePol protocol between a corrupted issuer and an honest user, then distinguishing between simulated protocol and real-world protocol will depend on distinguishing the proof π generated by the simulator of zero-knowledge proof-of-knowledge protocol from the proof that is generated by an actual user, which is a contradiction.
IssueToken: If this is an IssueToken protocol between a corrupted user and an honest verifier, it is straightforward to see that E cannot distinguish between the simulated protocol and the real-world protocol.
If this is a IssueToken protocol between a corrupted verifier and an ideal user, distinguishing the simulated protocol from the real protocol will depend on (i) distinguishing a hash value from a random binary string, or (ii) distinguishing the proof π generated by the simulator of zero-knowledge proof of knowledge protocol from the proof that is generated by the actual user. Both are contradictions.
VerifyPol: If this is a VerifyPol for a corrupted user and an honest verifier, then distinguishing between the simulated protocol and the real-world protocol will result from either (i) E being able to distinguish between a knowledge extractor and a verifier of the proof of knowledge protocol, (ii) F LEDGER producing incorrect output for READ query. Both cases generate contradictions.
If this is a VerifyPol for a corrupted verifier and an honest user, then distinguishing between the simulated protocol and the real-world protocol will result from (i) distinguishing a hash value from a random binary string, or (ii) distinguishing the proof π generated by the simulator of zero-knowledge proof-of-knowledge protocol from the proof that is generated by the actual user. Both are contradictions.

VI. ON REALIZING F LV
Implementing F LV requires measuring the physical properties of the entities: the IsClose interface requires determining the proximity of the user from the issuer. Unfortunately, there is no work on user location/proximity verification that proves the security of the protocol in the simulation-based model. In fact, the only known approach for user proximity verification that provides provable cryptographic security is a technique called Distance Bounding (DB) (see Section II for the background). However, security models for all existing DB protocols are game-based. Designing a simulation-based model for DB protocol is challenging due to the lack of work on simulation-based models that include physical properties. We provide an example implementation of the IsClose interface of F LV that is adapted from a DB protocol originally proposed in [1] that is secure in the game-based model. Proving the security of the DB protocol in a simulation-based model is out-of-scope for this paper.
As stated in the IssuePol protocol of the proposed POL scheme (Fig. 6), IsClose(I , N UI , D) query is sent to the functionality F LV only after the authentication of user U is complete, that is, U successfully established her ownership of N UI to issuer I through the non-interactive ZKPoK π. We assume that an honest user generates a new pseudonym FIGURE 11. Distance bounding protocol between user U and issuer I, adapted from [1].
N UI with the issuer by running FormNym protocol, before each new IssuePol protocol with this issuer. For a security parameter λ, the DB protocol in Fig. 11 uses N UI as a common input of size λ for U and I . The user's other inputs are sk s U , Cert U (private inputs), and pk e I (I 's public encryption key). I 's other inputs are sk e I (decryption key, private input), and the bound D that is to be put on the user's distance from the issuer.
There are three phases in the DB protocol: 1) Initialization Phase: U chooses a random string α of length λ, that will later be used for responding to the issuer's challenges. α is encrypted using I 's public key pk e I and the ciphertext C U is sent to I , who uses sk e I to decrypt C U to obtain α. I chooses a λ-bits random string β, and sends to U .
2) Distance Bounding Phase: In the i-th round of this phase of total λ rounds, I generates a random bit c i and sends as a challenge to U , who responds immediately with N UI i (if c i = 0) or α i ⊕ β i (if c i = 1), with index i representing the i-th bit of the binary string of length λ. I records the round trip time t i for the challenge-response.
3) Finalization Phase: In this phase, I checks U 's responses as well as the message round-trip times recorded in the distance bounding phase. I outputs 1 if the estimated round trip times are within the given distance bound D and responses are correct in all the rounds, otherwise 0.
In our application, we require the DB protocol to provide security against distance fraud, mafia fraud, and terrorist fraud [26], be privacy-preserving, and not reveal any information on the user's identity to the verifier. A brief description of these attacks and how the DB protocol presented here protects against these attacks can be found in Appendix A.

VII. PROOF-OF-CONCEPT IMPLEMENTATION
The aim of implementation is to determine the processing times for a user, issuer, RA, and verifier. For the user, we use a mobile phone (Samsung Galaxy S9) to represent its resource limitation and use a MacBook pro with 2.6 GHz Intel Core i7 and 16GB memory representing the issuer, RA, and the verifier. The Java implementation of Idemix v2.3.43 [27] is a cryptographic protocol suite, offering CL signatures, commitments, zero-knowledge proof of knowledge protocols, and hash functions. In Idemix, the commitment scheme and the CL-signature security rely on the hardness of the discrete logarithm (DL) and the factorization problems, respectively. The software uses a prime size of 1632 bits for the commitment scheme, the RSA modulus size of 2048 bits for the CLsignature, and employs SHA-256 for the hash function. These sizes are chosen such that the overall cryptographic security is equivalent to that of the RSA modulus size. More details on Idemix can be found in [28].
Experiment Outline: We consider the four phases of the POL system: (i) user registration: user receives a certificate from TA on their secret, (ii) FormNym: the user and the issuer engage in the FormNym protocol that generates a pseudonym for the user, (iii) IssuePol: the user and the issuer engage the IssuePol protocol where the issuer authenticates the user (who is registered through a pseudonym), verifies their proximity to the issuer, and if both are valid, issues a proof-oflocation token, and (iv) VerifyPol: the verifier (anonymously) authenticates the user, and checks the validity of the presented pol token.
Our implementation examines the computational and storage costs of running POL. Figure 13 shows the result of independent 10 runs of each test. The tests were conducted with no parallel background processes.
For the users, registration is the most expensive (time) phase, taking 185 milliseconds, and includes a commitment  on the secret key and a non-interactive zero-knowledge proof with the issuer. The proof generation process at the issuer requires 202 milliseconds and it includes the issuer signing user attributes (location) using CL-signature. In pol verification, it takes 41 milliseconds for the user to generate a proofof-knowledge and 92 milliseconds for the verifier to verify the proof and the signature of the issuer in pol. Table 1 shows the user's storage requirement. Each pol is 1940 bytes, which is a reasonable amount considering the capacity of today's mobile devices. Storage requirements for the identity credential from RA, the credential specifications, and zero-knowledge proofs are also reasonable.

A. COMPARISON WITH EXISTING SOLUTIONS 1) pol SIZE COMPARISON
We compare our results to the POL scheme implemented in Gambs et al. [8], who claims POL properties such as unforgeability, non-transferability, and anonymity. The size of pol in their work is 3444 bytes, which is much bigger than ours (1940 bytes).

2) COMMUNICATION OVERHEAD
In the POL without offline pol accessibility, the user sends the pol token (1940 bytes) and a zero-knowledge proof of knowledge (2590 bytes) to the verifier, which consumes 4530 bytes on the communication channel. In Gambs et al. [8], the communication overhead (including the 2590 bytes of ZKPoK), is 6034 bytes (see Table 2 for a comparison). For POL with offline pol accessibility, a pol access token is sent from the user to the verifier that includes an index idx and an AES key k pol . idx is the hash of C pol , and assuming SHA-256 hash function it is 256 bits (32 bytes). Assuming AES key size as 256 bits, the size of the pol access token is thus 64 bytes, which is smaller by a factor of 71 and 94, compared to our proposed POL without offline accessibility, and POL proposed in Gambs et al. [8], respectively. This is mainly due to the one-time storage of the pol and the non-interactive ZKPoK computed by the user on the blockchain at the time of pol generation, which can be referred to by the user multiple times. This makes a significant difference in the communication overhead when users increase their pol verification frequency, or the number of users grows in the system.

VIII. RELATED WORK
Among the anonymous credential schemes, [16] is close to our work in terms of cryptographic primitives used, such as protocol for signing a committed value (in Register User) and protocol for proving knowledge of signature on a committed value (in FormNym, IssuePol, and VerifyPol). Our construction however differs from [16]: (i) we enable and require the issuance of two types of credentials, the identity credential that is the signature of RA on the user private key (or issuer's public key), and the location credential that is the pol token generated by the pol issuer, while [16] allows only the identity credential. (ii) Unlike [16], the pol token is essentially an attribute-based credential, that is, the user's attributes such as location and pol issuance are also part of the credential. (iii) Our scheme is more complex in the sense that it facilitates a physical operation that is performed by the functionality F LV , while the scheme in [16] only requires the involvement of two parties (issuer and user) in generating a credential, making the construction and security analysis relatively simpler.
Offline accessibility in POL systems has been considered in [2], [3], and [10]. All these works use distributed ledgers for providing universal access to POL. However, these systems provide informal security arguments, and none of these enables the users to manage and control the access over the proof-of-location credentials.
User anonymity is considered in [5], [8], [29], [30], and [31]. [29], [30] only provide anonymity against the verifier, and do not have formal security models. As in our work, pseudonyms have been used to provide user anonymity in [5], [8], and [31]. Among these [8] and [31] considered anonymity with respect to both the issuer and the verifier. However, [8] use a distance bounding protocol that has been shown to be vulnerable to distance bounding attacks in [32]. Reference [31] only provides informal security arguments, and is vulnerable to relay attacks.
The user and their electronic device are considered as a single entity in our work. However, in real-life scenarios, users and their devices can be physically separated, which may introduce security vulnerabilities that are not accounted for in our analysis. It should be noted that this is a common approach taken in the analysis of similar protocols. To address such potential attacks, additional protection mechanisms can be employed depending on the specific protocol and its application. For instance, initiating the POL protocol might require the user to input a password or provide a scan of biometric data (e.g., face) to the device. Similar assumptions are commonly made in credential systems [18], [21], [22] and POL systems [2], [4], [29], [30]. In the work presented by Kounas et al. [31], a video challenge and response mechanism for verifying strong identity, along with a simple timeout-based device location verification, are proposed. However, the combination of these verifications is not secure, and the system is susceptible to relay attacks. Additionally, the system is vulnerable to attacks that exploit AI-generated faceswapping videos, commonly referred to as DeepFakes [33].

IX. CONCLUDING REMARKS
We proposed a proof of location scheme in the simulation paradigm, making it usable as a building block in a wide range of security protocols. For offline pol accessibility, we extend the POL scheme in a way that user can control their own credentials while preserving all the security properties. Our protocol also achieves user anonymity with respect to both the issuer and the verifier. Our implementation of the POL scheme on off-the-shelf mobile devices shows the feasibility and practicality of the scheme. A POL in the UC model is a future direction.

A. DISTANCE BOUNDING (DB)
Following the security definitions in [26], in this specific DB instantiation, transferring the secret key or pseudonym of a user to another user (a helper) does not compromise the security of the protocol. This is because such transfer would enable the helper to impersonate the user in all future DB protocols, satisfying the security requirements.
Distance Fraud (DF)-Resistance: In a DF attack, the dishonest user U * is located far-away (>D) from the issuer I , and attempts to convince I that she is close-by (≤ D). A successful attack implies U * successfully guessing the challenge c i before it arrives at U * , with more than 1/2 probability at each of the λ rounds. This is a contradiction since c i is chosen uniformly at random.
Mafia Fraud (MF)-Resistance: In a MF attack, an external entity A close-by I , tries to convince I that an honest far-away user U is close-by I . In the DB literature [26], MF-resistance assumes that A's response to i-th challenge is independent of the honest user's response to that particular challenge. An attacker can only win by i) successfully guessing the response bit-string α, which is chosen uniformly at random and thus giving a contradiction, or, ii) revealing α from the ciphertext C u by breaking IND-CCA property of the encryption scheme, again resulting in a contradiction.
Terrorist Fraud (TF)-Resistance: In a TF attack, a far away dishonest user U * uses the help of a close-by external entity A, and attempts to convince I that she is close-by. We follow the TF-resistance definition of [26] that requires that, if the prover wants A to help them successfully convince I that they are close-by, A can simply replay this information in future sessions to get authenticated as U * . In our DB protocol, the user must share N UI with A to allow A to successfully respond to the challenges of I . This will however enable A to correctly respond to all the challenges in any future distance bounding session. For providing correct zero-knowledge proof π to the issuer, A can simply store and replay the non-interactive zero-knowledge proof π that is sent before the DB protocol execution. These will guarantee TF-resistance by forcing a dishonest user to enable their accomplice in masquerading them in all future sessions -something they will avoid.
Anonymity: The only information that is required for user authentication that is revealed to the issuer is N UI = Commit(sk s U , r). Revealing any information on a user's identity is thus reduced to breaking the computational hiding property of the commitment scheme.