PrivLocAuth: Enabling Location-Aware Cross-Domain UAV Authentication with Zero-Knowledge Location Privacy

Abstract

Secure cross-domain UAV authentication is challenging because identity verification alone is insufficient to guarantee safe operation. In many UAV applications, it is equally critical to verify that a UAV is currently located within an authorized geographic region. Existing approaches often expose precise GPS coordinates, rely on static identifiers that enable tracking, or fail to guarantee the freshness and authenticity of location evidence. These weaknesses allow replay, location spoofing, and trajectory inference attacks, especially in multi-domain environments. To address these limitations, we propose PrivLocAuth, a zero-knowledge-based cross-domain UAV authentication protocol that enforces geofence restrictions without revealing actual locations. In PrivLocAuth, UAVs encode their current coordinates into fresh Pedersen commitments, which are attested by the home Local Domain Server (LDS) using short-lived Schnorr signatures. Based on these attested commitments, UAVs generate Bulletproof range proofs to demonstrate compliance with cross-domain server-defined geofences. This design ensures that UAVs operate within authorized airspace while preserving strong location privacy. PrivLocAuth further incorporates a lightweight elliptic curve cryptography (ECC) and Schnorr signature-based credential framework that enables unlinkable authentication across-domains, preventing session correlation and identity tracking. Formal security analysis demonstrates resistance to impersonation, replay, geofence-bypass, and linkage attacks. Experimental evaluation shows low computational latency and minimal communication overhead, confirming the protocol’s suitability for resource-constrained UAV platforms operating in dynamic cross-domain environments.

1. Introduction

As UAVs increasingly become integral components of the Internet of Drones (IoD), their ability to operate across diverse administrative and geographic domains introduces significant security and privacy challenges [1,2]. In critical applications such as surveillance, disaster response, and smart logistics, UAVs must authenticate with foreign or cross-domain infrastructure while adhering to strict geofence policies. However, location-aware cross-domain authentication introduces vulnerabilities such as location inference and correlation risks, especially when protocols require explicit Global Positioning System (GPS) location coordinates disclosure or rely on home or local domain control centers [3,4,5].

The problem becomes more severe in heterogeneous trust environments, where domain servers may follow the protocol but can still misuse location data through metadata, location logs, or communication patterns [6,7]. Standard public key cryptographic solutions often focus on identity validation and mutual authentication, but neglect location privacy, assuming that positional data is either irrelevant or encrypted [8,9]. Yet, GPS coordinates even when protected can be correlated over time or extracted through side channel analysis, leading to mission compromise or physical UAV targeting [10,11].

To address these challenges, we propose PrivLocAuth, a zero-knowledge-based cross-domain UAV authentication protocol that enforces geofence compliance, location privacy, and session unlinkability without revealing UAV identities or exact coordinates. Each UAV is registered once with a trusted Registration Authority (RA), which establishes the cryptographic system parameters and issues an unlinkable Schnorr-based credential. This credential enables the UAV to demonstrate legitimate membership during authentication sessions without revealing its long-term identity. The RA is consulted on-demand during authentication to verify credentials and enforce revocation, while the Cross-Domain Server (CDS) enforces the RA’s decision without learning the UAV’s real identity.

During each authentication session, the UAV never transmits raw GPS coordinates to any cross-domain server. Instead, it locally encodes its current position into fresh Pedersen commitments using newly generated blinding factors, ensuring strong hiding properties and preventing cross-session linkage. These commitments are submitted to the home LDS, which verifies correctness and freshness according to domain policy and issues a short-lived Schnorr-signed attestation binding the location evidence to the current session. Using this LDS-attested evidence, the UAV constructs Bulletproof range proofs that allow the CDS to verify compliance with authorized geofences without learning exact coordinates or receiving unverified location data. Concurrently, the UAV proves ownership of its RA-issued credential to the CDS, ensuring authentication integrity while preserving unlinkability across sessions and administrative domains.

By combining per-session location commitments, LDS attestation, zero-knowledge range proofs, and unlinkable credential-based authentication, PrivLocAuth enables UAVs to prove compliance with location policies without revealing where they are, preventing trajectory inference and mission exposure. Unlike existing frameworks that require continuous connection to a home authority or trust in every domain, PrivLocAuth supports fully autonomous, privacy-preserving operations across untrusted domains while enabling real-time revocation and auditability.

Our key contributions are summarized as follows:

• We propose PrivLocAuth, a geofence-aware and privacy-preserving cross-domain authentication framework for UAVs. PrivLocAuth enables a UAV to prove its compliant presence within an authorized geographic region without revealing exact GPS coordinates. By integrating geofence-based authorization with zero-knowledge range proofs, the framework enforces fine-grained spatial access control while preventing trajectory inference, mission leakage, and location-based tracking across-domains.
• We propose a cross-domain UAV authentication framework in which the RA is involved only during enrollment and on-demand revocation checks. UAV legitimacy is established using RA-issued anonymous credentials, while geofence compliance is endorsed by the LDS through short-lived attestations on session-specific location commitments. The CDS enforces access decisions based on these verifiable LDS endorsements and zero-knowledge proofs, without learning UAV identities or precise locations, thereby enabling scalable and lightweight authentication across multiple administrative domains.
• The protocol integrates efficient elliptic-curve cryptography, Schnorr signatures, and zero-knowledge proofs. The resulting design achieves a favorable balance between security, privacy, and computational overhead, making it practical for deployment in resource-constrained UAVs and Internet-of-Drones environments. Formal security analysis confirms resistance to impersonation, replay, and forgery attacks, while experimental evaluation shows real-time feasibility, with the Registration Phase completing in approximately $0.842$ ms and the Authentication Phase in $72.749$ ms.

The rest of this paper is structured as follows: Section 2 provides an overview of related work. Section 3 introduces the cryptographic preliminaries. Section 4 and Section 5 describe the proposed PrivLocAuth model and the system protocol. Section 6 and Section 7 focus on the security analysis and experimental evaluation. Finally, Section 8 concludes the paper and highlights potential future research directions.

2. Related Work

Cross-domain UAV authentication has been extensively studied in civilian settings, primarily focusing on identity assurance, access control, and cryptographic robustness. These protocols often assume a centralized trust architecture or semi-trusted infrastructure [12], which may not be practical or secure in real-world deployments involving adversarial, disconnected, or bandwidth constrained domains. Early approaches largely relied on centralized Public Key Infrastructure (PKI) and Certificate Authorities (CAs) to manage inter- or local-domain trust relationships, requiring UAVs to maintain persistent connectivity with their home authorities or implicitly trust cross-domain infrastructure. Such assumptions are often infeasible in highly mobile, mission-critical scenarios where autonomy, resiliency, and privacy are essential.

To reduce dependency on centralized authorities, federated identity frameworks and token-based delegation schemes have been proposed to enable UAVs to carry cryptographic credentials across administrative domains [13,14]. Although these systems improve operational flexibility, they typically expose long-term identifiers or contextual metadata such as issuing domain, timestamps, or session tokens, which can be exploited by honest-but-curious servers or external adversaries to reconstruct UAV trajectories, correlate sessions, or infer mission objectives. Furthermore, these schemes generally lack explicit provisions for spatial privacy, making them vulnerable to geofence inference and trajectory profiling attacks. A different line of work has turned to blockchain-based cross-domain authentication. For example, a scheme combining consistent hashing with consortium blockchains was proposed to enhance lookup efficiency and scalability [15]. However, the reliance on blockchain consensus still introduces significant latency and overhead, unsuitable for UAVs with strict real-time requirements. Similarly, the AAMB protocol introduced a cross-domain authentication framework using dynamic accumulators and two-layer blockchains in IoMT [16]. While this improves revocation management and privacy, the multi-layer blockchain structure is resource-intensive and less practical for lightweight UAV platforms. Another recent study presented a blockchain and signature-based scheme leveraging Verifiable Credentials (VCs) [17]. Although this provides strong interoperability across-domains, it assumes stable connectivity for credential verification and does not address UAV-specific location privacy challenges.

To address privacy concerns, various location obfuscation techniques such as k-anonymity, dummy injection, and spatial cloaking have been introduced [18,19]. While effective against casual observers, these heuristics only offer probabilistic guarantees and are fragile under cumulative inference or traffic analysis. In contrast, cryptographic mechanisms grounded in ZKPs offer formal privacy guarantees and enable selective disclosure. Pedersen commitments, which are computationally binding and perfectly hiding, have been used to encode sensitive values such as geographic coordinates without revealing them, while supporting algebraic operations for proof composition.

Building on these primitives, Bulletproofs is a non-setup, non-interactive ZKP system [20] that avoids the need for a trusted setup, enabling efficient range proofs and geofence validation without leaking coordinate information. Their logarithmic proof size and fast verification make them particularly suitable for deployment in embedded systems like UAVs. However, prior ZKP-based UAV authentication schemes often depend on heavy weight zk-SNARK circuits or require centralized setup phases, limiting their applicability in dynamic, decentralized networks. Moreover, many fail to integrate privacy-preserving spatial validation with identity unlinkability, leaving location data exposed or binding it to persistent identifiers [21]. Complementary approaches based on Boneh–Boyen–Shacham (BBS) credentials [22], group signatures, or anonymous tokens provide unlinkable authentication and selective attribute disclosure, yet they do not natively incorporate geospatial constraints or allow UAVs to prove location compliance without compromising anonymity. The frameworks in [9,23] report an authentication latency of 68.92 ms, which is slightly lower than PrivLocAuth (72.749 ms), although PrivLocAuth provides a more lightweight design for UAV deployment. Unlike our prior ZAPS protocol [2], which uses zk-SNARKs for full flight path privacy in a single-domain setting, PrivLocAuth addresses cross-domain authentication and enables lightweight geofence compliance using Bulletproofs without trusted setup.

To the best of our knowledge, PrivLocAuth is the first lightweight cross-domain UAV authentication protocol that jointly achieves unlinkable identity validation and cryptographically sound location privacy without requiring continuous direct RA involvement for routine authentication. The RA remains online only for credential verification and revocation, while UAVs and CDSs operate efficiently across multiple domains. The protocol supports scalable authentication across mutually untrusted administrative domains and provides strong resistance against inference, correlation, and replay attacks. Unlike PKI-, token-, blockchain-, and existing zero-knowledge-only approaches, PrivLocAuth integrates elliptic curve cryptography with zero-knowledge range proofs to enable real-time operation in highly mobile IoD environments [24]. Its design ensures geofence compliance, session unlinkability, and decentralized trust enforcement through LDS-attested Bulletproof-based location commitments and credential-based authentication, without revealing UAV identities or exact coordinates. As summarized in

Table 1. Comparison of authentication approaches across selected references.

Metric	[2]	[8]	[12]	[13,14]	[15,16]	[9,23]	PrivLocAuth
Auth. Time (ms)	15.2	22,309	1325	250–1962	122–3241	68.92	72.749
Location Privacy	✓	✓	✗	✗	Partial	✓	✓
Unlinkability	✓	✓	✗	Partial	Partial	✓	✓
Non-Setup	✗	✗	✓	✓	✗	✓	✓
Lightweight	Moderate	✗	Moderate	Moderate	✗	Moderate	✓

Note: ✓ indicates that the feature is supported, while ✗ indicates that the feature is not supported.

, PrivLocAuth achieves a balanced trade-off between privacy, security, scalability, and computational efficiency, making it practical for deployment on resource-constrained UAV platforms.

3. Preliminaries

This section introduces the foundational cryptographic primitives and techniques that underpin the design and security analysis of our PrivLocAuth protocol [25]. We focus on ECC for efficient and lightweight public key operations, Pedersen Commitments for hiding and binding values, Schnorr Signatures for efficient and secure authentication, and Bulletproofs as a zero-knowledge proof system for proving range constraints without revealing underlying values. These tools collectively enable privacy-preserving authentication and data integrity within resource-constrained and trustless environments.

3.1. Elliptic Curve Cryptography (ECC)

ECC is a public-key cryptographic system that provides strong security using the algebraic structure of elliptic curves over finite fields, offering equivalent security to traditional methods like RSA but with significantly smaller key sizes, making it ideal for constrained environments such as IoT and UAV systems [26]. Mathematically, an elliptic curve E over a finite field ${\mathbb{F}}_p$ (with p as a prime) is defined by the Weierstrass equation

$$y^2\equiv x^3+ax+b(modp),$$

where constants a and $b\in {\mathbb{F}}_p$ must satisfy the condition

$$\Delta =-16(4a^3+27b^2)\not\equiv 0(modp)$$

to ensure the curve has no singularities. The set of points $(x,y)$ that satisfy this equation, along with a special point at infinity $\mathcal{O}$, forms an abelian group with a defined addition operation. Given two points $P=(x_1,y_1)$ and $Q=(x_2,y_2)$, their sum $R=P+Q=(x_3,y_3)$ is computed using slope $\lambda$, where

$$\lambda ={\displaystyle \frac{y_2-y_1}{x_2-x_1}}modp\mathrm{for}P\ne Q,$$

and

$$\lambda ={\displaystyle \frac{3x_1^2+a}{2y_1}}modp\mathrm{for}\mathrm{point}\mathrm{doubling}\mathrm{when}P=Q.$$

The resulting coordinates are

$$x_3={\lambda }^2-x_1-x_{2}modp,y_3=\lambda (x_1-x_3)-y_{1}modp.$$

ECC key generation involves choosing domain parameters $(p,a,b,G,n)$, selecting a private key $d\in [1,n-1]$, and computing the corresponding public key $Q=dG$. The security of ECC hinges on the Elliptic Curve Discrete Logarithm Problem (ECDLP), which is the challenge of determining d given $Q=dG$ for known Q and G, a problem for which no efficient algorithm is known, thereby forming the core of ECC’s cryptographic strength.

Elliptic Curve Discrete Logarithm Problem (ECDLP)

The security of ECC is based on the computational hardness of the ECDLP [27]. The problem is defined as follows:

Let $E\left({\mathbb{F}}_p\right)$ be an elliptic curve defined over a finite field ${\mathbb{F}}_p$, where p is a prime number. Let $G\in E\left({\mathbb{F}}_p\right)$ be a base point of prime order n, and let $d\in [1,n-1]$ be a scalar. Then compute: $Q=dG$. Given the elliptic curve $E\left({\mathbb{F}}_p\right)$, the base point G, and the public point Q, the Elliptic Curve Discrete Logarithm Problem is to determine the unknown scalar d such that $Q=dG$. The operation $dG$ refers to scalar multiplication, which consists of repeated point additions on the elliptic curve:

$$dG=\underset{d\mathrm{times}}{\underbrace{G+G+\cdots +G}}$$

This problem is believed to be computationally infeasible for sufficiently large d and properly chosen curve parameters. Unlike the discrete logarithm problem in finite fields (as used in traditional Diffie–Hellman), no sub-exponential-time algorithm is currently known for solving ECDLP on general elliptic curves.

Therefore, the intractability of solving the equation $Q=dG$ underpins the security of ECC. Even with key sizes as small as 256 bits, ECC provides a level of security comparable to 3072-bit RSA, making it especially suitable for resource-limited environments such as mobile devices, smart cards, and IoT.

3.2. Pedersen Commitments

The Pedersen commitment is a cryptographic commitment scheme that allows a sender to commit to a value while keeping it hidden (hiding) and ensuring that it cannot be changed later (binding) [28]. It is widely used in privacy-preserving protocols, such as zero-knowledge proofs, confidential transactions, and secure voting systems. Pedersen commitments are computationally binding under the Discrete Logarithm Assumption, perfectly hiding—meaning the commitment reveals no information about the committed value—and homomorphic, supporting operations on committed values without revealing them.

Let G be a cyclic group of prime order p (e.g., an elliptic curve group), and let $g,h\in G$ be two generators such that the discrete logarithm ${log}_g\left(h\right)$ is unknown. To commit to a secret value $m\in {\mathbb{Z}}_p^{*}$ using a random blinding factor $n\in {\mathbb{Z}}_p^{*}$, the Pedersen commitment C is defined as

$$C=g^m{h}^{n}modp$$

where m is the message (the value to commit to), n is the random nonce or blinding factor, g and h are fixed generators of the group G with unknown discrete log relationship, and C is the commitment. Since n is randomly chosen and $h^n$ masks $g^m$, the commitment does not leak any information about m.

Under the Discrete Logarithm Assumption, it is computationally infeasible to find distinct pairs $(m,n)\ne (m^{\prime },n^{\prime })$ such that

$$g^m{h}^n=g^{m^{\prime }}{h}^{n^{\prime }}modp$$

ensuring binding. Furthermore, Pedersen commitments are homomorphic: given two commitments $C_1=g^{m_1}{h}^{n_1}$ and $C_2=g^{m_2}{h}^{n_2}$ their product

$$C_1·C_2=g^{m_1+m_2}{h}^{n_1+n_2}$$

is a valid commitment to $m_1+m_2$ using randomness $n_1+n_2$.

3.3. Zero-Knowledge Proofs Systems

A ZKP [29,30] is a cryptographic protocol in which a prover convinces a verifier that a statement is true (e.g., “location x lies within the range $[x_{min},x_{max}]$”) without revealing any information beyond the validity of the statement itself. ZKPs ensure three core properties: completeness (honest provers can always convince verifiers of true statements), soundness (false statements cannot be convincingly faked by computationally bounded adversaries), and zero-knowledge (no private data such as x or its blinding factor $n_x$ is disclosed). While traditional ZKPs, like Schnorr identification, require interaction between prover and verifier, the proposed UAV protocol uses Bulletproofs to transform range proofs into non-interactive zero-knowledge proofs via the Fiat–Shamir heuristic. This allows UAVs to generate a single proof string ${\pi }_x$ that demonstrates the existence of values $(x,n_x)$ such that $C_x=x·G+n_x·H$ and $x\in [x_{min},x_{max}]$, without revealing x or $n_x$. The main advantage of Bulletproofs in this setting is their elimination of interaction delays and minimization of bandwidth—both of which are critical for UAVs operating in latency-sensitive environments such as disaster response scenarios.

Bulletproofs (Range Proofs)

Bulletproofs are non-interactive zero-knowledge (NIZK) protocols that allow short, $O(logn)$-sized proofs over arithmetic circuits without requiring a trusted setup [20]. They are primarily used for two purposes: (1) range proofs, which allow a prover to convince a verifier that a committed value v lies within a specified interval $[a,b]$ without revealing v; and (2) inner-product proofs, which verify algebraic relations over hidden vectors.

In the Bulletproof range-proof construction, the prover encodes the committed value using a binary vector representation. Let ${\overrightarrow{a}}_L\in {\mathbb{Z}}_p^n$ denote the binary encoding vector, and define ${\overrightarrow{a}}_R={\overrightarrow{a}}_L-\overrightarrow{1}$, where $\overrightarrow{1}$ is the all-ones vector. To enforce that each component is binary, the protocol applies the constraint ${\overrightarrow{a}}_L\circ {\overrightarrow{a}}_R=\overrightarrow{0},$ where ∘ denotes the Hadamard (element-wise) product defined by ${(\overrightarrow{x}\circ \overrightarrow{y})}_i=x_i{y}_i$. This constraint guarantees $a_{L,i}(a_{L,i}-1)=0$ for every index i, ensuring that each component lies in $\{0,1\}$. The prover next samples random blinding vectors ${\overrightarrow{s}}_L,{\overrightarrow{s}}_R\leftarrow {\mathbb{Z}}_p^n$ and a scalar $\alpha \leftarrow {\mathbb{Z}}_p$, and computes a vector Pedersen commitment

$$A=\langle {\overrightarrow{a}}_L,\overrightarrow{G}\rangle +\langle {\overrightarrow{a}}_R,\overrightarrow{H}\rangle +\alpha U,$$

where $\overrightarrow{G}$ and $\overrightarrow{H}$ are publicly fixed, independent generator vectors in the elliptic-curve group, and U is an additional public generator. These generators ensure binding and hiding properties of the commitment. To remove interaction, the protocol applies the Fiat–Shamir transform: public challenges are deterministically derived by hashing the protocol transcript. These challenges are used to form blinded vectors that encode the arithmetic constraints of the range proof. The proof is then reduced to an inner-product relation $t=\langle \overrightarrow{l},\overrightarrow{r}\rangle ,$ which is proven using a logarithmic inner-product argument.

The resulting proof transcript is

$${\pi }_{\mathrm{BP}}=\left({\{L_i,R_i\}}_{i=1}^{logn},a,b\right),$$

where $L_i$ and $R_i$ are commitment elements generated during recursive folding of the inner-product proof, and $a,b$ are final scalar values satisfying the inner-product constraint. The verifier recomputes the corresponding commitments using the same Fiat–Shamir challenges and accepts if consistency holds. The resulting proof is perfectly complete and honest-verifier zero-knowledge, and enjoys computational witness-extended emulation under the discrete logarithm assumption. Its size is only $2logn+9$ group elements and five scalars, making it a compact, trust-free primitive suitable for privacy-preserving computations on resource-constrained platforms such as UAVs.

3.4. Schnorr Signatures

Schnorr signatures [31] are a digital signature scheme known for their simplicity, efficiency, and security, relying on the hardness of the discrete logarithm problem in a finite cyclic group. Let G be a cyclic group of prime order p with generator g. The signer selects a secret key $x\in {\mathbb{Z}}_p^{*}$ and computes the public key $Y=g^{x}modp$. To sign a message m, the signer chooses a random nonce $k\in {\mathbb{Z}}_p^{*}$, computes the commitment $R=g^{k}modp$, and then computes the challenge $e=H(R\parallel m)$ using a cryptographic hash function H. The response is computed as $s=k+exmodp$, and the resulting signature is the pair $(e,s)$. To verify the signature, the verifier recomputes $R^{\prime }=g^s{Y}^{-e}modp$, calculates $e^{\prime }=H(R^{\prime }\parallel m)$, and accepts the signature if $e^{\prime }=e$. Schnorr signatures are compact, provably secure in the random oracle model, and support aggregation, making them suitable for applications like multi-signatures in blockchain protocols.

4. System Model of Proposed Protocol

This section presents the system architecture of the proposed cross-domain UAV authentication protocol, including the participating entities, their roles, trust assumptions, and communication model. It also provides a brief operational perspective to illustrate how these components interact during a multi-domain UAV mission under zero-knowledge-based location privacy.

4.1. Main Entities

As illustrated in Figure 1, the system consists of four core entities interacting in a decentralized yet privacy-preserving authentication architecture:

• Registration Authority (RA): A trusted, centralized authority responsible for registering UAVs and issuing credentials (${\mathrm{Cred}}_d$) using its secret key ${\mathit{V}}_r$. It defines the cryptographic system parameters, issues Schnorr-signed UAV credentials, and enables secure cross-domain authentication while preserving UAV anonymity.
• Local Domain Server (LDS): A domain-local authority that manages UAVs within its domain, verifies Pedersen commitments and zero-knowledge Bulletproof range proofs, and issues short-lived Schnorr-signed attestations confirming that UAV locations are valid and fresh without revealing exact coordinates.
• Cross-Domain Server (CDS): A domain visited by the UAV. It authenticates visiting UAVs using their RA-issued credentials and LDS-attested location proofs, without learning the UAV’s real identity or exact location. The CDS relies on RA online verification for credential legitimacy and revocation enforcement, and on LDS-issued attestations for geofence compliance.
• UAV (Drone): A mobile autonomous entity seeking authenticated access to resources or airspace in foreign domains. It holds a private ECC key $V_d$ and credential (${\mathrm{Cred}}_d$), and generates Pedersen commitments and Bulletproof range proofs to prove geofence compliance while preserving location and identity privacy.

Figure 1. Network model of the PrivLocAuth protocol.

Figure 1. Network model of the PrivLocAuth protocol.

4.2. Operational Context

To clarify the practical operation of the PrivLocAuth protocol, we describe a representative UAV mission spanning multiple administrative domains. A UAV $D_d$ is deployed for a long-range task and traverses several regions, each governed by a distinct CDS enforcing its own geofence policy. Prior to deployment, the UAV completes a one-time registration with the RA, during which it generates an ECC key pair and obtains a Schnorr-signed credential ${\mathsf{Cred}}_d$. This credential is securely stored on the UAV and reused throughout the mission for cross-domain authentication.

During cross-domain authentication, the UAV initiates contact with the corresponding CDS using its stored credential and freshly generated session nonces. The CDS may forward the received credential to the RA only when necessary, for instance, to validate the UAV’s credential or check its revocation status. The RA then performs these checks on-demand rather than being continuously involved, ensuring that UAVs remain operational even when the RA is temporarily unavailable. This approach allows compromised or misbehaving UAVs to be promptly denied access without requiring the RA to be online for every authentication session. Once legitimacy is confirmed through these on-demand checks, the CDS completes the authentication process and enforces its domain-specific geofence policy. It introduces an availability dependency on the RA. If the RA becomes temporarily unreachable, cross-domain authentication cannot be completed. As the UAV enters a foreign domain, it generates fresh Pedersen commitments to its current location and constructs Bulletproof range proofs with respect to the CDS-defined geofence constraints. These commitments and proofs are submitted to the UAV’s home LDS, which verifies their correctness and freshness and issues a short-lived Schnorr-signed attestation. Using these LDS-attested commitments, the UAV constructs Bulletproof range proofs demonstrating compliance with the CDS-defined geofence without revealing its exact location. The CDS then verifies the UAV’s credential together with the LDS-issued attestation over the Bulletproof-verified commitments, ensuring that the UAV is both legitimate and operating within the authorized area while preserving location privacy.

This process is repeated independently for each CDS encountered during flight. Each authentication session employs fresh nonces, session keys, and LDS-attested location commitments, ensuring unlinkability across domains and preventing cross-session correlation. Geofence compliance is enforced cryptographically, and precise location information is never disclosed. In summary, the RA participates only during registration and for on-demand revocation checks, rather than being continuously consulted. Meanwhile, the UAV remains fully operational under temporary network delays or bandwidth constraints, with location correctness and freshness ensured locally through the LDS. This design highlights that selective RA involvement enables strong security guarantees while maintaining practical and efficient cross-domain authentication under realistic network conditions.

4.3. Assumptions

The design of the PrivLocAuth protocol relies on a set of practical assumptions aligned with its security goals and deployment model.

The RA is assumed to be trusted for system setup, credential issuance, and UAV identity management. The RA remains online and reachable during both registration and authentication phases and is consulted for verifying the legitimacy of UAV credentials, checking revocation status, detecting misbehavior, and performing administrative auditing. This ensures that only authorized UAVs can participate in cross-domain authentication while enabling immediate revocation of compromised UAVs. Routine cryptographic operations, including session key establishment, Pedersen commitment generation, and zero-knowledge proof construction, do not require direct RA interaction, as the UAV and CDS rely on previously issued RA-signed credentials; however, credential validation and revocation checks are performed online by the RA during authentication.

CDSs are modeled as honest-but-curious entities. A CDS follows the protocol specification correctly, including credential verification, implicit authenticated ECDH-based key establishment, zero-knowledge proof validation via LDS attestations, and revocation enforcement, but may attempt to infer additional information from received messages or stored transcripts. The protocol is designed to limit such inference by ensuring that neither the UAV’s real identity nor its exact location is disclosed during authentication.

UAVs are assumed to execute the protocol correctly when uncompromised and to generate fresh Pedersen commitments and corresponding Bulletproof range proofs for their current location in each authentication session. Real-world GPS coordinates are treated as signed and bounded values represented in fixed-point format. Prior to cryptographic use, latitude and longitude values are scaled by a public precision factor and converted into signed integers, then injectively mapped into a non-negative domain using a public offset to ensure compatibility with finite-field arithmetic. Location values are never used directly in elliptic-curve group operations, but only within commitments and zero-knowledge range or geofence verification proofs. UAVs are not assumed to be tamper-resistant; physical capture, key extraction, and compromise of stored credentials are considered in the security analysis.

All UAV–CDS communications are protected using authenticated encryption with session keys established via implicitly authenticated ECDH key exchange and derived using a standard key derivation function. Session keys are bound to fresh nonces and timestamps to ensure session uniqueness, freshness, and replay protection. The authenticated ECDH exchange guarantees mutual authentication and resistance against man-in-the-middle attacks under the hardness assumption of the ECDLP. In the event of UAV device compromise, previously established session keys remain protected provided that the long-term private keys are not exposed; however, ongoing or future sessions may be affected until revocation is enforced by the RA.

Entities are assumed to maintain loosely synchronized clocks within an acceptable tolerance window to support timestamp-based freshness checks. The adversary is assumed to have full control over the communication channel, including the ability to eavesdrop, replay, delay, and modify messages.

Finally, the protocol assumes standard cryptographic hardness assumptions, including the intractability of the elliptic-curve discrete logarithm problem, the security of authenticated ECDH key exchange, and the collision resistance of the employed hash functions. Performance assumptions are based on software-based cryptographic libraries running on general-purpose processors rather than specialized UAV hardware accelerators.

4.4. Security Requirements

To ensure secure and privacy-preserving cross-domain authentication for UAVs, the proposed PrivLocAuth protocol must satisfy the following requirements:

• Robust UAV Authentication: Only UAVs possessing a valid RA-issued credential ${\mathit{Cred}}_d$ and the corresponding private key $V_d$ can successfully authenticate to a CDS. Each authentication session is bound to fresh nonces $(n_1,n_2)$ and a session key established via an implicit ECDH-based authenticated key agreement and derived using HKDF. The nonces ensure freshness and replay protection but do not serve as keying material.
• Location Privacy Preservation: Raw GPS coordinates are never transmitted. The UAV encodes its current location into fresh Pedersen commitments $(C_x,C_y)$ per session and generates zero-knowledge Bulletproof range proofs to demonstrate geofence compliance. These commitments and proofs are attested by the LDS via a short-lived Schnorr signature, ensuring that location data remains hidden even if adversaries access stored commitments, credentials, or protocol transcripts.
• Geofence Soundness Enforcement: Each UAV proves in zero-knowledge that its committed location lies within the authorized geofence $R=(X_{min},X_{max},Y_{min},Y_{max})$. The soundness of Bulletproofs ensures that out-of-range coordinates cannot be falsely verified. The LDS verifies the Bulletproof range proofs and commitment freshness and issues a signed attestation, while the CDS verifies the validity of the LDS-issued Schnorr attestation before granting access.
• Replay Attack Resistance: Each authentication session is protected using session-specific nonces $(n_1,n_2)$, timestamps $(T_d,T_c,T_l)$, and a server-side replay cache. The CDS rejects duplicated nonces and stale timestamps within the defined freshness window $\Delta T_f$, ensuring that replayed or delayed messages cannot be accepted. Even in the presence of temporary clock drift, GPS loss, or local resets, session replay remains infeasible.
• Unforgeability Under ECDLP: All credentials, signatures, and cryptographic commitments rely on the computational hardness of the Elliptic Curve Discrete Logarithm Problem (ECDLP). Forging RA-issued credentials or LDS attestations, or generating accepting Bulletproof proofs for out-of-range values without the corresponding witnesses, is infeasible under standard elliptic-curve hardness and zero-knowledge proof soundness assumptions.
• Session Unlinkability: Each UAV generates fresh Pedersen commitments and Bulletproof proofs for every authentication session, and the LDS issues short-lived attestations bound only to the current session. Public keys $P_d$ may be updated over time under RA control, while the RA internally maps them to the persistent identity $I{D}_d$. As a result, multiple protocol sessions cannot be linked to infer UAV movement patterns or operational behavior.
• Side-Channel Mitigations: The protocol employs randomized nonces and ephemeral elliptic-curve computations to introduce variability in cryptographic operations. While no formal side-channel model or constant-time implementation is assumed, timing analysis was performed using Python-based cryptographic libraries to evaluate computational overhead. This analysis provides an initial assessment of protocol performance and timing characteristics but does not claim full resistance against timing or power-analysis attacks on UAV hardware.
• Revocation Compliance: The CDS validates UAV credentials ${\mathit{Cred}}_d$ and checks the revocation status of the presented credential via the online RA, with optional temporary caching of recent revocation outcomes to improve efficiency. Location proofs are accepted only if attested by the LDS and valid for the current session. Any revoked or compromised UAV attempting to authenticate is rejected, and the corresponding credential or public-key reference may be temporarily recorded within replay or revocation caches without storing persistent identity or location information, thereby preserving unlinkability, location privacy, and geofence enforcement.

5. Proposed Protocol

The proposed PrivLocAuth protocol comprises four core phases: Setup, Registration, Cross-Domain Authentication, and Revocation. During the Setup and Registration phase, RA initializes the ECC system parameters and generates its signing key pair. Each UAV independently generates its own ECC private public key pair and submits its public key to the RA for enrollment. The RA issues a verifiable credential by digitally signing the UAV’s public key using a Schnorr signature, thereby enabling anonymous yet authenticated participation without revealing sensitive attributes.

In the Cross-Domain Authentication phase, a UAV seeking access to a foreign CDS initiates the protocol by transmitting its credential along with a freshness nonce and timestamp, encrypted under the CDS’s public key. The CDS forwards the received credential to the online RA for legitimacy and revocation verification, and performs replay protection through nonce and timestamp checks. Both parties then derive a shared session key using an elliptic-curve Diffie–Hellman shared secret expanded via HKDF with the exchanged nonces.

Subsequently, the UAV submits Pedersen commitments together with corresponding Bulletproof-based range proofs of its current geographic coordinates to its home LDS, which verifies the proofs and issues a short-lived Schnorr signature attesting to their correctness and freshness. The UAV then constructs Bulletproof-based zero-knowledge range proofs to demonstrate that its committed location lies within a CDS-defined geofenced region. These proofs are transmitted securely under the established session key, allowing the CDS to verify geofence compliance via validation of the LDS-issued Schnorr attestation, without learning the UAV’s exact location or private keys. Upon successful verification of the credential, session freshness, and range proofs, the CDS grants access.

In the revocation phase, the CDS checks the legitimacy and revocation status of the UAV’s credential by querying the online RA. The CDS also ensures that the LDS-attested commitments and Bulletproof range proofs are valid and current. If the credential is found to be revoked, expired, or tampered with, or if the LDS-issued location attestation or its associated range proofs fail verification, the session is immediately terminated and access is denied. Recent revocation outcomes for the presented credential may be cached locally by the CDS only within the replay protection window, without storing persistent identifiers or location-related information, thereby preventing repeated unauthorized interactions while preserving the privacy and unlinkability of compliant UAVs. The notations utilized in the PrivLocAuth protocol are defined in

Table 2. Notation used in this PrivLocAuth protocol.

Notation	Description
$CD{S}_c$	Cross-Domain Server
$LD{S}_l$	Local Domain Server
$D_d$	UAV (Drone)
$R{A}_r$	Registration Authority
G, H	Independent generator points
$P_i,V_i$	Public and Private key
$K_i$	Shared key
$S{k}_{i,j}$	Session key between entities i and j
${\pi }_x,{\pi }_y$	Bulletproofs for x and y range proof
$C_x,C_y$	Pedersen commitments to x and y
R	Geofence range $[X_{min},X_{max},Y_{min},Y_{max}]$
$n_x,n_y$	Random scalars used in Pedersen commitments
$Cre{d}_i$	Anonymous credential
${\mathbb{Z}}_p^{*}$	Multiplicative group of order $p-1$
${\mathbb{F}}_p$	Finite field
$E_p(a,b)$	Elliptic curve over ${\mathbb{F}}_p$
$\Delta T_f$, $\Delta T_{rp}$	Maximum transmission delay, Reply blocking window
$T_i$	Current timestamp
$\mathrm{Auth}$	Verification information
$n_i$	Nonces used for freshness
x, y	UAV’s real location coordinates
$\tilde{A}$	The adversary
$M_i$	Message
$Enc/Dec$	Encryption and Decryption

.

5.1. Setup Phase

In the initial step of the setup phase, the RA establishes the foundational cryptographic parameters for the protocol. The RA selects a secure, widely adopted elliptic curve defining a cyclic group $\mathbb{G}$ of prime order p, which underpins all subsequent cryptographic operations.

Two independent generator points are chosen on this curve: G, used for public key generation and digital signatures, and H, used exclusively for constructing Pedersen commitments. The independence of these generators ensures the security of the commitment scheme and prevents discrete-logarithm correlation attacks.

The RA then generates a single long-term asymmetric key pair consisting of a private key $V_{\mathrm{r}}\in {\mathbb{Z}}_p^{*}$, kept secret, and a public key $P_{\mathrm{r}}=V_{\mathrm{r}}·G$, which is made publicly available. This key pair is used to issue and verify UAV credentials via Schnorr signatures, without requiring per-UAV RA key material.

Finally, the RA publishes the global system parameters $(\mathrm{Curve},G,H,P_{\mathrm{r}})$ to all participating UAVs, LDSs, and CDSs. Each UAV possesses a long-term elliptic-curve key pair $(V_d,P_d)$ that is registered with the RA during enrollment and bound to the UAV’s real identity $I{D}_d$ only within the RA’s secure database. The identity $I{D}_d$ is never disclosed during authentication; instead, revocation and legitimacy are enforced through online RA verification of the presented credential. This design enables cross-session unlinkability, scalable revocation, and privacy-preserving cross-domain authentication.

5.2. UAV Registration with RA

As illustrated in Figure 2, the UAV registration phase establishes a long-term anonymous credential that enables future cross-domain authentication without disclosing the UAV’s real identity.

Initially, the UAV $D_d$ locally generates a random private key $V_d\in {\mathbb{Z}}_p^{*}$ and computes the corresponding elliptic-curve public key $P_d=V_d·G$, where G denotes the system-wide curve generator. The UAV then constructs a registration message $M_d=(I{D}_d \Vert P_d)$, where $I{D}_d$ represents the UAV’s real identity, known exclusively to the Registration Authority (RA), and transmits $M_d$ to the RA over a secure channel.

Upon receiving the registration request, the RA verifies the legitimacy of $I{D}_d$ using administrative or out-of-band mechanisms and checks the validity of the submitted public key $P_d$. The RA then stores the registration record, creating a persistent binding between the UAV’s real identity and its public key. This design allows the RA to associate multiple public keys with the same UAV identity over time, thereby supporting key updates, mobility, accountability, and auditability.

The RA maintains a long-term Schnorr signing key pair $(V_r,P_r)$, generated during the system setup phase. Using its private key $V_r$, the RA issues an anonymous registration credential by computing a Schnorr signature over the UAV’s public key ${\mathsf{Cred}}_d={\mathsf{SchnorrSign}}_{V_r}\left(P_d\right).$ The credential ${\mathsf{Cred}}_d$ enables the UAV to authenticate itself in future protocol sessions without revealing $I{D}_d$, while the RA retains the identity–public key mapping internally for accountability and revocation purposes.

The RA returns the issued credential to the UAV, which securely stores ${\mathsf{Cred}}_d$ for subsequent cross-domain authentication. No location information is disclosed during the registration phase; the RA only issues the long-term credential and maintains the identity binding. During cross-domain authentication, the RA remains online to validate presented credentials and enforce revocation in real time, ensuring secure and scalable operation across multiple administrative domains. The pseudocode is shown in Algorithm 1.

Algorithm 1: UAV Registration Phase.

Require:  UAV ${\mathcal{UAV}}_d$, Registration Authority $\mathcal{RA}$ Ensure:  Registration credential $Cre{d}_d$ securely stored at ${\mathcal{UAV}}_d$     1: procedure UAV_REGISTRATION(${\mathcal{UAV}}_d,\mathcal{RA}$)     2:     ${\mathcal{UAV}}_d$ selects $V_d\in {\mathbb{Z}}_p^{*}$                   ▹ UAV private key     3:     $P_d\leftarrow V_d·G$                          ▹ UAV public key     4:     $M_d\leftarrow (I{D}_d \Vert P_d)$                   ▹ Registration message     5:     ${\mathcal{UAV}}_d\to \mathcal{RA}:M_d$     6:     $\mathcal{RA}$ retrieves its long-term key pair $(V_r,P_r)$      ▹ Established during setup     7:     $\mathcal{RA}$ verifies the legitimacy of $I{D}_d$  ▹ Administrative or out-of-band verification     8:     $\mathcal{RA}$ verifies the validity of $P_d$               ▹ Curve and format check     9:     $\mathcal{RA}$ stores $M_d$            ▹ Persistent identity–public key mapping   10:     $Cre{d}_d\leftarrow {\mathsf{SchnorrSign}}_{V_r}\left(P_d\right)$          ▹ RA-issued anonymous credential   11:     $\mathcal{RA}\to {\mathcal{UAV}}_d:\left\{Cre{d}_d\right\}$   12:     ${\mathcal{UAV}}_d$ securely stores $Cre{d}_d$   13: end procedure

5.3. Cross-Domain Authentication and Revocation

As illustrated in Figure 3 and Algorithm 2, in the cross-domain authentication phase, a registered UAV $D_d$ authenticates to a cross-domain server $CD{S}_c$. During this process, it proves, in a privacy-preserving manner, that it is operating within an authorized geofence region. This phase integrates mutual authentication, location compliance verification, replay protection, and revocation enforcement into a single protocol flow.

The authentication begins with the UAV generating a fresh random nonce $n_1$ and a local timestamp $T_d$. The UAV retrieves its stored credential $Cre{d}_d$ and the public key $P_c$ of the cross-domain server, and constructs the authentication request $Aut{h}_d={\mathit{Enc}}_{P_c}(P_d \Vert n_1 \Vert Cre{d}_d \Vert T_d),$ which is transmitted to $CD{S}_c$. Upon receiving the message, the CDS decrypts it using its private key $V_c$, records its current timestamp $T_c$, and verifies freshness by checking $|T_c-T_d| \le \Delta T_f.$ The CDS then performs replay protection by checking whether the nonce $n_1$ already exists in its replay cache within the window $\Delta T_{rp}$. If a replay is detected, the request is immediately rejected; if the nonce is fresh, the CDS forwards the received credential $Cre{d}_d$ to the online RA for legitimacy verification. Using its registration database, the RA verifies the validity of $Cre{d}_d$, checks its revocation status, and confirms that it corresponds to a registered UAV. The authentication is rejected if the credential is invalid or revoked.

After receiving a positive validation response from the RA, the CDS generates a fresh nonce $n_2$, updates its timestamp $T_c$, and determines the authorized geofence $R=[X_{min},X_{max},Y_{min},Y_{max}]$ according to its access control policy, then sends a challenge message $Aut{h}_c={\mathit{Enc}}_{P_d}(P_c \Vert R \Vert n_2 \Vert T_c)$ to the UAV.

Algorithm 2: Cross-Domain UAV Authentication and Geofence Verification

Require:  Registered UAV ${\mathcal{UAV}}_d$, Cross-Domain Server ${\mathcal{CDS}}_c$, Home LDS Ensure:  Access Granted or Rejected     1: procedure CrossDomainAuth(${\mathcal{UAV}}_d,{\mathcal{CDS}}_c$) Phase 1: UAV → CDS Authentication Request     2:     ${\mathcal{UAV}}_d$ selects $n_1\in {\mathbb{Z}}_p^{*}$ and timestamp $T_d$     3:     Retrieve $Cre{d}_d$ and CDS public key $P_c$     4:     $Aut{h}_d\leftarrow {\mathsf{Enc}}_{P_c}(P_d \Vert n_1 \Vert Cre{d}_d \Vert T_d)$     5:     ${\mathcal{UAV}}_d\to {\mathcal{CDS}}_c:\left\{Aut{h}_d\right\}$ Phase 2: CDS Validation and Challenge     6:     $(P_d,n_1,Cre{d}_d,T_d)\leftarrow {\mathsf{Dec}}_{V_c}\left(Aut{h}_d\right)$     7:     $T_c\leftarrow \mathrm{CurrentTimestamp}\left(\right)$     8:     if $|T_c-T_d| >\Delta T_f$ then     9:         return Reject   10:     end if   11:     if $n_1$ exists in ReplayCache within $\Delta T_{rp}$ then   12:         return Reject                           ▹ Replay detected   13:         Verifies $Cre{d}_d$ through the RA   14:     end if   15:     Select $n_2\in {\mathbb{Z}}_p^{*}$   16:     Store $\{P_d,n_1,n_2,T_c\}$ in ReplayCache   17:     Generate geofence $R=[X_{min},X_{max},Y_{min},Y_{max}]$   18:     $Aut{h}_c\leftarrow {\mathsf{Enc}}_{P_d}(P_c \Vert R \Vert n_2 \Vert T_c)$   19:     ${\mathcal{CDS}}_c\to {\mathcal{UAV}}_d:\left\{Aut{h}_c\right\}$ Phase 3: UAV Proof Generation and LDS Attestation   20:     $(P_c,R,n_2,T_c)\leftarrow {\mathsf{Dec}}_{V_d}\left(Aut{h}_c\right)$   21:     $T_d^{\prime }\leftarrow \mathrm{CurrentTimestamp}\left(\right)$   22:     if $|T_d^{\prime }-T_c| > \Delta T_f$ then   23:         return Reject   24:     end if   25:     if $n_2$ exists for $P_c$ within $\Delta T_{rp}$ then   26:         return Reject                           ▹ Replay detected   27:     end if   28:     $K_d\leftarrow V_d·P_c$                              ▹ UAV Shared key   29:     Derive session key $S{K}_{d,c}\leftarrow \mathsf{HKDF}(K_d,n_1,n_2)$                ▹ UAV Session key   30:     Obtain current location $(x,y)$ and select blinds $(n_x,n_y)$   31:     $C_x\leftarrow x·G+n_x·H$   32:     $C_y\leftarrow y·G+n_y·H$   33:     ${\pi }_x\leftarrow \mathsf{BulletproofGen}(C_x,[X_{min},X_{max}])$   34:     ${\pi }_y\leftarrow \mathsf{BulletproofGen}(C_y,[Y_{min},Y_{max}])$   35:     Send $(K_d \Vert C_x \Vert C_y \Vert {\pi }_x \Vert {\pi }_y \Vert R)$ to LDS   36:     LDS verifies ${\pi }_x,{\pi }_y$, infers coarse location $(x_l,y_l)$, records $T_l$   37:     LDS generates ${\mathrm{Cred}}_l\leftarrow {\mathsf{SchnorrSign}}_l(K_d \Vert C_x \Vert C_y \Vert {\pi }_x \Vert {\pi }_y \Vert R \Vert T_l)$   38:     ${\mathcal{UAV}}_d$ receives LDS attestation $Cre{d}_l$   39:     $Aut{h}_{d,c}\leftarrow {\mathsf{Enc}}_{S{K}_{d,c}}({\mathrm{Cred}}_l \Vert T_d)$   40:     ${\mathcal{UAV}}_d\to {\mathcal{CDS}}_c:\left\{Aut{h}_{d,c}\right\}$ Phase 4: CDS Verification and Decision   41:     $K_c\leftarrow V_c·P_d$                            ▹ CDS Shared key   42:     Derive session key $S{K}_{c,d}\leftarrow \mathsf{HKDF}(K_c,n_1,n_2)$              ▹ CDS Session key   43:     $({\mathrm{Cred}}_l,T_d)\leftarrow {\mathsf{Dec}}_{S{K}_{c,d}}\left(Aut{h}_{d,c}\right)$   44:     if $|T_c^{\prime }-T_d| > \Delta T_f$ then   45:         return Reject   46:     end if   47:     Verify LDS Schnorr signature $Cre{d}_l$   48:     if signature invalid then   49:         return Reject   50:         $\mathsf{BulletproofVer}(C_x,{\pi }_x)$   51:         $\mathsf{BulletproofVer}(C_y,{\pi }_y)$   52:     end if   53:     return Grant Access   54: end procedure

Upon receiving the challenge, the UAV decrypts it using its private key $V_d$, verifies freshness by checking $|T_d^{\prime }-T_c| \le \Delta T_f,$ and ensures that the nonce $n_2$ has not been reused for the same server within the replay window. If the checks succeed, the UAV derives an elliptic-curve Diffie–Hellman shared secret $K_d=V_d·P_c,$ which is then expanded into the session key $S{K}_{d,c}=\mathsf{HKDF}(K_d,n_1,n_2).$ The exchanged nonces $n_1$ and $n_2$ are used as HKDF context inputs to bind the session key to the current protocol instance and ensure resistance against replay and key-compromise impersonation attacks.

To prove compliance with the issued geofence without revealing its exact location, the UAV determines its current coordinates $(x,y)$ and selects random blinding factors $n_x$ and $n_y$. It computes Pedersen commitments $C_x=x·G+n_x·H,C_y=y·G+n_y·H,$ where G is the elliptic-curve generator and H is an independent generator with no known discrete logarithm relationship to G. Using the geofence bounds R, the UAV constructs zero-knowledge Bulletproof range proofs ${\pi }_x=\mathsf{BulletproofGen}\left(C_x,[X_{min},X_{max}]\right),{\pi }_y=\mathsf{BulletproofGen}\left(C_y,[Y_{min},Y_{max}]\right),$ which demonstrate that the committed coordinates lie within the authorized region.

The UAV submits the tuple $(K_d \Vert C_x \Vert C_y \Vert {\pi }_x \Vert {\pi }_y \Vert R)$ to its local domain server $LD{S}_s$ for location attestation. The inclusion of the shared secret $K_d$ cryptographically binds the location evidence to the authenticated UAV–CDS session. The LDS verifies the correctness of the Bulletproof range proofs and infers a coarse-grained estimate of the UAV’s location $(x_l,y_l)$ using local observation mechanisms such as wireless channel characteristics. Without learning the exact committed coordinates, the LDS checks whether the inferred location is consistent with the geofence R. If the checks succeed, the LDS records the current timestamp $T_l$ and issues a short-lived location attestation $Cre{d}_l={\mathsf{SchnorrSign}}_l\left(K_d \Vert C_x \Vert C_y \Vert {\pi }_x \Vert {\pi }_y \Vert R \Vert T_l\right).$ Finally, the UAV encrypts the LDS-signed attestation together with its timestamp as $Aut{h}_{d,c}={\mathsf{Enc}}_{S{K}_{d,c}}\left(Cre{d}_l \Vert T_d\right)$ and transmits it to the CDS. Upon reception, the CDS derives the shared secret $K_c=V_c·P_d,$ and computes the corresponding session key $S{K}_{c,d}=\mathsf{HKDF}(K_c,n_1,n_2).$ Using this session key, the CDS decrypts the received ciphertext to recover $(Cre{d}_l,T_d)={\mathsf{Dec}}_{S{K}_{c,d}}\left(Aut{h}_{d,c}\right).$ The CDS then performs a freshness check by verifying that the timestamp difference satisfies $|T_c^{\prime }-T_d| \le \Delta T_f.$ If this condition fails, the authentication request is rejected to prevent replay attacks.

Next, the CDS validates the LDS Schnorr signature contained in $Cre{d}_l$ to confirm the integrity and origin of the geofence attestation. Upon successful signature verification, the CDS verifies the zero-knowledge range proofs by executing $\mathsf{BulletproofVer}(C_x,{\pi }_x)\mathrm{and}\mathsf{BulletproofVer}(C_y,{\pi }_y),$ thereby confirming that the UAV’s committed coordinates satisfy the authorized geofence constraints without revealing their exact values.

If all verification steps succeed, access is granted. The shared key $K_d$ is included in the LDS submission solely as a session-binding identifier that uniquely associates the attestation with the current UAV–CDS interaction. Its disclosure to the LDS does not compromise confidentiality, since $K_d$ is never used directly for encryption and the operational session key $S{K}_{d,c}$ remains known only to the UAV and CDS. All public-key encryptions ${\mathsf{Enc}}_{P_i}(·)$ are instantiated using an ECIES-style construction based on ephemeral elliptic-curve Diffie–Hellman key agreement, with session keys derived using HKDF and protected via AEAD primitives that ensure confidentiality and integrity. Freshness, replay resistance, and session binding are jointly enforced through timestamps, replay caches, nonces, and LDS-issued Schnorr attestations.

During the revocation phase, the RA processes requests to revoke UAV identities or public keys and updates its internal revocation list. This ensures that compromised or unauthorized UAVs are blocked from future protocol sessions, without involving the CDS or disclosing location information.

During authentication, the CDS verifies UAV legitimacy and the freshness of location evidence. It forwards the RA-issued credential ${\mathit{Cred}}_d$ to the RA, which checks the credential’s validity, confirms the binding between $I{D}_d$ and $P_d$, and verifies the revocation status in real time. The UAV’s identity remains hidden from the CDS.

If the credential is invalid or the UAV is revoked, the CDS immediately terminates the session. Additionally, the CDS verifies per-session Pedersen commitments and Bulletproof-based location proofs, ensuring timestamps are fresh and evidence is not replayed.

This combination of RA-managed revocation and CDS-enforced session validation prevents unauthorized UAVs from accessing cross-domain services while preserving location privacy, unlinkability, and protocol scalability.

6. Security Analysis

In this section, we thoroughly analyze the privacy and security properties of the proposed PrivLocAuth protocol and discuss the associated security considerations.

6.1. Adversary Model

In the proposed PrivLocAuth framework, the adversary $\mathcal{A}$ is modeled as a probabilistic polynomial-time (PPT) entity with full control over the public communication channels between UAVs, CDSs, and the RA. The adversary can intercept, modify, replay, or inject messages but is computationally bounded under the hardness assumptions of the ECDLP, the security of ephemeral ECDH key exchange authenticated via Schnorr-based credentials, the collision resistance of cryptographic hash functions, and the soundness and Bulletproof zero-knowledge proofs.

Several realistic adversarial scenarios are considered. In a passive setting, eavesdroppers on UAV–CDS or UAV–LDS communications may attempt to infer sensitive information, such as UAV identity, operational domain, or geographic coordinates, from intercepted ciphertexts, commitments, or proof transcripts. In an active setting, $\mathcal{A}$ may attempt to impersonate legitimate UAVs or CDSs, inject forged messages, replay previously transmitted authentication data, or mount man-in-the-middle attacks by manipulating protocol flows. The model also includes honest-but-curious CDSs that follow the protocol specification correctly but attempt to extract hidden information, such as the UAV’s location, by analyzing stored transcripts and commitments. Malicious CDS behavior, including protocol deviation or impersonation, is covered under the active adversary model.

The primary objectives of $\mathcal{A}$ are to impersonate legitimate entities, forge or replay authentication messages, compromise session keys, or infer UAV identity or location information. The proposed PrivLocAuth protocol mitigates these threats through authenticated ephemeral ECDH key exchange, Schnorr-based credential verification, Pedersen commitments, and Bulletproof range proofs. Each authentication session establishes a fresh session key derived from an ephemeral ECDH shared secret and bound to session-specific nonces and timestamps via a standard key derivation function. This design ensures message confidentiality, integrity, and unlinkability, even under active adversarial control of the communication channel.

The PrivLocAuth protocol relies on loose time synchronization between UAVs and CDSs to enforce session freshness and replay resistance, following the time-step validation principles defined in TOTP [32]. Each authentication exchange includes a timestamp that is validated upon receipt, and a session is accepted only if the observed time deviation remains within a predefined tolerance window $\Delta T$, set to approximately 30 s, consistent with standard time-based one-time password validation windows [32]. This threshold reflects a conservative upper bound that accounts for typical wireless transmission delays, GPS timing inaccuracies, and clock drift commonly observed in embedded UAV platforms. The confidentiality and integrity guarantees of PrivLocAuth for session data rely on the IND-CCA2 security of standard AEAD encryption primitives used in the implementation, rather than on any custom encryption constructions.

The security guarantees of the protocol are not critically affected by minor violations of the freshness bound: short-lived network latency variations or limited clock drift may lead to rejection of an individual authentication attempt but do not enable replay, impersonation, or session compromise. Freshness verification is reinforced through the combined use of authenticated ephemeral ECDH key material, session-specific nonces, and timestamps, ensuring that stale, duplicated, or delayed messages cannot be reused successfully, even under partial temporal desynchronization.

The protocol assumes a trusted RA responsible for credential issuance and real-time revocation enforcement, secure storage of cryptographic material on UAV platforms, and the computational hardness of the underlying elliptic-curve and zero-knowledge proof primitives. The RA functions as a logically centralized trust and availability component within the system. While it guarantees immediate revocation effectiveness and consistent credential validation across administrative domains, its temporary unavailability may suspend the initiation of new cross-domain authentication sessions, although previously established secure sessions remain unaffected.

Extreme adversarial scenarios, such as physical capture of a UAV or simultaneous compromise of both the RA and a CDS, may temporarily impact anonymity or trust assumptions until revocation mechanisms are enforced. However, such events do not undermine the correctness or cryptographic soundness of the authentication process itself. This architectural choice reflects a deliberate prioritization of strong revocation guarantees, accountability, and lightweight system design over fully distributed trust architectures. Within these clearly defined trust boundaries, the proposed PrivLocAuth protocol achieves strong resistance to impersonation, replay attacks, man-in-the-middle attacks, and privacy-compromising inference.

6.2. Formal Game-Based Security Proof

Security properties are formalized using standard game-based definitions. Let $\lambda$ denote the security parameter, $\mathrm{negl}\left(\lambda \right)$ a negligible function, and $q_{\mathcal{O}}$ the maximum number of queries to oracle $\mathcal{O}$. All probabilities are explicitly parameterized by $\lambda$.

Oracle Definitions

The adversary $\mathcal{A}$ is modeled as a PPT algorithm with access to the following oracles:

• ${\mathcal{O}}_{\mathrm{Register}}\left(\mathit{ID}\right)$: Registers UAV $\mathit{ID}$ and returns its public key $P_{\mathit{ID}}$ and associated credential.
• ${\mathcal{O}}_{\mathrm{Corrupt}}\left(\mathit{ID}\right)$: Returns the long-term private key $V_{\mathit{ID}}$ and credential ${\mathsf{Cred}}_{\mathit{ID}}$.
• ${\mathcal{O}}_{\mathrm{Send}}(\mathit{ID},\mathit{msg})$: Delivers message $\mathit{msg}$ to a protocol participant and returns the resulting response.
• ${\mathcal{O}}_{\mathrm{Reveal}}\left(\mathit{sid}\right)$: Reveals the session key for session identifier $\mathit{sid}$.
• ${\mathcal{O}}_{\mathrm{Authenticate}}(\mathit{ID},\mathit{CDS})$: Executes the authentication protocol between UAV $\mathit{ID}$ and cross-domain server $\mathit{CDS}$ and returns the transcript.

Trust Model

CDSs are honest-but-curious: they follow the protocol correctly but may attempt to infer UAV identities or locations from observed transcripts.

Hardness Assumptions

Security relies on the following standard cryptographic assumptions:

1.

ECDLP. The Elliptic Curve Discrete Logarithm Problem is hard; any PPT adversary running in time t has advantage ${\mathsf{Adv}}^{\mathrm{ECDLP}}\left(t\right)$.

2.

Schnorr EUF-CMA. Schnorr signatures are existentially unforgeable under chosen-message attacks; advantage denoted ${\mathsf{Adv}}^{\mathrm{EUF}-\mathrm{CMA}}(t,q_s,q_h)$.

3.

Bulletproof Soundness. The range proof system is computationally sound with error ${ϵ}_{\mathrm{BP}}\left(\lambda \right)$.

4.

Bulletproof Zero-Knowledge. The proofs reveal no additional information; simulation error ${ϵ}_{\mathrm{ZK}}\left(\lambda \right)$.

5.

DDH. The Decisional Diffie–Hellman problem is hard with advantage ${\mathsf{Adv}}^{\mathrm{DDH}}\left(t\right)$.

6.

ECIES IND-CCA. ECIES encryption resists adaptive chosen-ciphertext attacks with advantage ${\mathsf{Adv}}^{\mathrm{IND}-\mathrm{CCA}}(t,q_d)$.

7.

Pedersen Commitment Hiding. Commitments are computationally hiding under the discrete logarithm assumption.

6.2.1. Security Games and Theorems

Game 1: Authentication Unforgeability

This game models the adversary’s ability to forge a valid authentication transcript for an honest UAV.

• Setup: The challenger runs $\mathsf{Setup}\left(1^{\lambda }\right)$ to generate system parameters and simulates all oracles.
• Adversarial Goal: $\mathcal{A}$ outputs a transcript

  $${\mathcal{T}}^{\prime }=({\mathsf{Cred}}_{\ell }^{\prime },C_x^{\prime },C_y^{\prime },{\pi }_x^{\prime },{\pi }_y^{\prime },R^{\prime },T_{\ell }^{\prime }),$$

  representing a forged location-authentication message. $\mathcal{A}$ wins if:
  • $\mathsf{Verify}({\mathsf{Cred}}_{\ell }^{\prime },p{k}_{\mathrm{LDS}})=1$;
  • $\mathsf{BulletproofVer}(C_x^{\prime },{\pi }_x^{\prime })=1$ and $\mathsf{BulletproofVer}(C_y^{\prime },{\pi }_y^{\prime })=1$;
  • $\mathcal{A}$ did not query ${\mathcal{O}}_{\mathrm{Corrupt}}\left({\mathit{ID}}^{\prime }\right)$ for the UAV identity;
  • $\mathcal{A}$ did not obtain the same transcript via ${\mathcal{O}}_{\mathrm{Authenticate}}({\mathit{ID}}^{\prime },·)$.

The authentication advantage is defined as

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{auth}}\left(\lambda \right)=Pr\left[\mathcal{A}\mathrm{wins}\mathrm{Game}1\right].$$

Theorem 1 

(Authentication Security). For a PPT adversary $\mathcal{A}$ issuing at most $q_{\mathrm{reg}}$, $q_{\mathrm{auth}}$, $q_{\mathrm{corrupt}}$ queries and runtime t, there exist PPT algorithms ${\mathcal{B}}_1$ and ${\mathcal{B}}_2$ such that

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{auth}}\left(\lambda \right) \le q_{\mathrm{reg}}·{\mathsf{Adv}}_{{\mathcal{B}}_1}^{\mathrm{EUF}-\mathrm{CMA}}+{\mathsf{Adv}}_{{\mathcal{B}}_2}^{\mathrm{ECDLP}}+{\displaystyle \frac{q_{\mathrm{auth}}^2}{2^{\lambda +1}}}+\mathrm{negl}\left(\lambda \right),$$

where ${\mathcal{B}}_1$ breaks Schnorr security and ${\mathcal{B}}_2$ solves ECDLP.

Game 2: Geofence Soundness

The adversary attempts to generate a valid range proof for coordinates outside the authorized region R. Advantage is

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{geo}}\left(\lambda \right)=Pr\left[\mathcal{A}\mathrm{outputs}\mathrm{valid}\mathrm{proof}\mathrm{outside}R\right].$$

Theorem 2 

(Geofence Soundness). For at most $q_{\pi }$ proof attempts, there exist PPT reductions ${\mathcal{B}}_1$ and ${\mathcal{B}}_2$ such that

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{geo}}\left(\lambda \right) \le q_{\pi }·{ϵ}_{\mathrm{BP}}\left(\lambda \right)+{\mathsf{Adv}}_{{\mathcal{B}}_2}^{\mathrm{ECDLP}}\left(t^{\prime }\right)+\mathrm{negl}\left(\lambda \right).$$

Game 3: Location Privacy

Location privacy is defined via an indistinguishability game. The adversary submits two coordinate pairs $(x_0,y_0),(x_1,y_1)\in R$. The challenger randomly selects $b\in \{0,1\}$ and returns commitments and proofs for $(x_b,y_b)$. $\mathcal{A}$ outputs a guess $b^{\prime }$. The advantage is

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{loc}-\mathrm{priv}}\left(\lambda \right)=\left|Pr[b^{\prime }=b]-{\displaystyle \frac{1}{2}}\right| \le {\mathsf{Adv}}_{\mathrm{hide}}^{\mathrm{commit}}+q_{\mathrm{trans}}·{ϵ}_{\mathrm{ZK}}\left(\lambda \right)+\mathrm{negl}\left(\lambda \right),$$

where ${\mathsf{Adv}}_{\mathrm{hide}}^{\mathrm{commit}}$ is the commitment-hiding advantage.

6.2.2. Concrete Security Analysis

For a 256-bit elliptic curve (e.g., Curve25519):

• ${\mathsf{Adv}}^{\mathrm{ECDLP}}\left(t\right)\approx t/2^{125}$;
• ${\mathsf{Adv}}^{\mathrm{EUF}-\mathrm{CMA}}(t,q_s,q_h) \le q_h/2^{256}+{\mathsf{Adv}}^{\mathrm{ECDLP}}\left(t^{\prime }\right)$;
• ${ϵ}_{\mathrm{BP}}\left(\lambda \right) \le 2^{-128}$;
• ${ϵ}_{\mathrm{ZK}}\left(\lambda \right)$ is negligible.

For example, $t=2^{80}$, $q_{\mathrm{reg}}=2^{20}$, $q_{\mathrm{auth}}=2^{30}$ gives

$${\mathsf{Adv}}_{\mathcal{A}}^{\mathrm{auth}}\left(\lambda \right) \le 2^{-28}.$$

Increasing $\lambda$ to 384 (e.g., NIST P-384) reduces the advantage to below $2^{-72}$ for $t=2^{100}$. Hence, PrivLocAuth achieves authentication unforgeability, geofence soundness, and location privacy with provably bounded adversarial advantage.

6.3. Resistance to Common Attacks

Table 3. Resistance against common attacks in PrivLocAuth.

Attack Type	Countermeasure	Security Bound/Notes
Replay Attacks	Session-specific nonces $(n_1,n_2)$, timestamps $(T_d,T_c)$, server-side replay cache $\Delta T_{rp}$	Replay attempts rejected via freshness and state validation
Impersonation/Forgery	ECC-based Schnorr signatures, authenticated encryption, ZK binding of commitments to $P_d$	Computationally infeasible under ECDLP; $Pr\left[\mathrm{Forge}\right]\approx \mathrm{negl}\left(\lambda \right)$
Credential Theft	Secure storage of $V_d$ and $Cre{d}_d$, short credential lifetimes, RA-synchronized revocation	Compromise valid only until revocation; LDS attestation prevents use of revoked credentials
Location Reconstruction/ Trajectory Inference	Fresh Pedersen commitments $(C_x,C_y)$ per session, Bulletproofs, LDS-attested Schnorr signatures, fresh blinding factors $(n_x,n_y)$	Leakage negligible; unlinkable per session; trajectory inference prevented
Geofence Bypass	Bulletproof range proof soundness (128-bit), LDS/CDS verification	$Pr\left[\mathrm{Bypass}\right] \le 2^{-128}$; infeasible to prove out-of-range location
MITM/Tampering	ECDH-derived session key $S{K}_{d,c}$, authenticated encryption, integrity and signature verification	Modification or substitution detected; $Pr\left[\mathrm{Tamper}\mathrm{Success}\right]\approx \mathrm{negl}\left(\lambda \right)$

shows the analyses of PrivLocAuth resilience against common attacks based on its cryptographic design and operational assumptions. Each attack is evaluated in terms of countermeasures, effectiveness, and residual limitations.

Replay Attacks: PrivLocAuth defends against both message-level and location-level replay attacks through a combination of freshness enforcement, stateful replay detection, and cryptographic binding. During registration and authentication, RA-issued credentials ${\mathit{Cred}}_d$ and protocol messages are protected using fresh 256-bit nonces $(n_1,n_2)$, timestamps $(T_d,T_c)$, and a CDS-side replay cache that records previously accepted session identifiers and freshness parameters [22]. This cache prevents nonce reuse within a bounded retention window and provides rollback protection through monotonic timestamp checks and persistent state. During authentication, the UAV generates session-specific Pedersen commitments $(C_x,C_y)$ and corresponding Bulletproof range proofs for its current location. These commitments are cryptographically linked to the authenticated session key $K_d$ via a zero-knowledge range proof, ensuring that location evidence is tied to the current session without revealing precise coordinates. The LDS verifies the correctness of the submitted proofs and issues a short-lived signed attestation containing a timestamp $T_l$. The CDS validates this attestation together with credential authenticity, revocation status, and session freshness. By enforcing freshness at both the message and location layers, the protocol prevents reuse of stale credentials, protocol messages, or location proofs, even in the presence of network delay or partial desynchronization. This design ensures resistance to replay and location spoofing attacks while preserving geofence compliance, location privacy, and cross-session unlinkability.

Impersonation and Forgery: The protocol ensures that only a legitimate UAV can successfully authenticate and submit location proofs. ECC-based Schnorr signatures and authenticated encryption guarantee that forging credentials or authentication messages is computationally infeasible under the hardness of the ECDLP. The UAV generates fresh Pedersen commitments and Bulletproof range proofs for its current location, which are submitted along with its authenticated identity $K_d$ to the LDS. The LDS verifies the correctness of the proofs and the cryptographic binding to $K_d$ without learning the exact coordinates, issuing a short-lived signed attestation. The CDS accepts location compliance only after verifying the LDS signature and $Cre{d}_d$. This combination prevents impersonation and the submission of forged location commitments, while maintaining privacy and unlinkability across sessions.

Credential Theft: The UAV’s private key $V_d$ and RA-issued credential $Cre{d}_d$ are securely stored within the UAV and are never transmitted in plaintext. During authentication, $Cre{d}_d$ is verified by the CDS to confirm the UAV’s legitimacy, while all subsequent communications are protected using session-key encryption. Even in the event of partial device compromise, the protocol limits exposure by enforcing credential revocation through CDS-maintained revocation lists synchronized with the RA. Moreover, zero-knowledge Bulletproofs and LDS-attested fresh commitments ensure that revoked or unauthorized UAVs cannot produce valid, current location proofs, enabling real-time exclusion without revealing sensitive information.

Location Reconstruction and Trajectory Inference: The protocol prevents trajectory inference using fresh Pedersen commitments $(C_x,C_y)$ and Bulletproof range proofs in each authentication session. Commitments are cryptographically bound to the authenticated UAV identity $P_d$ within an authenticated session context using zero-knowledge range proofs and attested by the LDS with a short-lived Schnorr signature. Each session uses fresh blinding factors and never reuses commitments, preventing adversaries from linking multiple sessions or intersecting ranges to infer movement. No exact coordinates are revealed, and RA involvement is unnecessary after the RA confirms the UAV’s legitimacy, ensuring location privacy, unlinkability, and verifiable geofence compliance across sessions.

Geofence Bypass: The protocol prevents geofence bypass through the soundness of Bulletproof range proofs, which ensures that only coordinates lying within the authorized region can be proven valid. Since the UAV generates fresh Pedersen commitments and corresponding Bulletproofs for each authentication session, forging an out-of-range location that satisfies the verification conditions is computationally infeasible, with soundness error bounded by approximately $2^{-128}$. The LDS verifies these proofs and issues a signed attestation only if the committed location complies with the geofence, preventing malicious UAVs from bypassing spatial access control.

Man-in-the-Middle (MITM) and Tampering: PrivLocAuth resists man-in-the-middle and tampering attacks by establishing a session key derived from an ephemeral ECDH exchange authenticated via RA-issued credentials. The UAV and the CDS generate per-session ephemeral ECDH key pairs and authenticate the exchanged public keys using RA-issued credentials. The resulting shared secret is combined with fresh nonces $(n_1,n_2)$ through HKDF to derive the session key $S{K}_{d,c}$, binding the key to both authenticated identities and the current session. The CDS completes credential and key verification before accepting any location-related data. Location proofs are released by the LDS only as short-lived Schnorr-signed attestations and are encrypted under $S{K}_{d,c}$. Any message modification, replay, or key-substitution attempt is detected during signature verification or authenticated decryption. Under standard ECDH, HKDF, and AEAD assumptions, the probability of a successful MITM or tampering attack is negligible.

6.4. Session Unlinkability

The PrivLocAuth protocol ensures that each authentication session remains unlinkable to any previous session, even when multiple sessions are observed. All protocol messages ($Aut{h}_d$, $Aut{h}_c$, and $Aut{h}_{d,c}$) are encrypted and incorporate fresh nonces ($n_1,n_2$) and timestamps ($T_d,T_c$), ensuring that no plaintext information is exposed. Each session derives a new encryption key from these nonces, preventing external observers from linking sessions to the same UAV.

To further protect against correlation by an honest-but-curious CDS, session unlinkability is achieved through the use of fresh nonces, per-session key derivation, and session-specific location commitments. Although the RA-issued credential ${\mathit{Cred}}_d$ is long-term, it is never revealed in plaintext and is verified online by the RA without disclosing the UAV’s identity to the CDS. As a result, the CDS observes only encrypted protocol messages and session-specific public information, preventing linkage across authentication sessions. The CDS only observes the UAV’s ephemeral public key $P_d$ and encrypted messages; the long-term identity $I{D}_d$ is never revealed. This ensures that even if the UAV rotates or updates its keys across sessions, the CDS cannot correlate them.

Per-session location commitments ($C_x,C_y$) are generated by the UAV and attested by a trusted LDS before being sent to the CDS. Each LDS attestation is short-lived and includes a fresh timestamp $T_l$, ensuring that even if a CDS observes multiple sessions, the commitments cannot be correlated across sessions. This combination of ephemeral keys, pseudonymous credentials, encrypted messages, and LDS-signed location proofs preserves both session unlinkability and location privacy, while supporting RA-based verification and timely revocation of compromised UAVs.

6.5. Location Privacy

In the PrivLocAuth protocol, the RA issues a long-term credential $Cre{d}_d$ that binds the UAV’s identity to its public key, while explicitly excluding any location-dependent information. This design choice ensures that spatial data is never embedded in static credentials, thereby preventing long-term linkability and location inference attacks.

During the authentication phase, after successful mutual authentication and session key establishment with the CDS, the UAV locally computes session-specific Pedersen commitments to its current coordinates $C_x=x·G+n_x·H,C_y=y·G+n_y·H,$ where $(n_x,n_y)\in {\mathbb{Z}}_p^{*}$ are freshly generated blinding factors unique to the session. These commitments are submitted to the home LDS, which validates them and issues a short-lived Schnorr signature attesting to their correctness and freshness. The commitments and their attestation are then used to generate Bulletproof-based zero-knowledge range proofs. The RA never observes the UAV’s current coordinates, and the commitments are never reused.

To demonstrate compliance with an authorized geofence $R=[X_{min},X_{max}]\times [Y_{min},Y_{max}],$ the UAV generates Bulletproof-based zero-knowledge range proofs, ${\pi }_x={\mathrm{Bulletproof}}_{Gen}(C_x,[X_{min},X_{max}]),{\pi }_y={\mathrm{Bulletproof}}_{Gen}(C_y,[Y_{min},Y_{max}]),$ which are transmitted to the CDS under session-key encryption. These proofs enable the CDS to verify that the UAV operates within the permitted region without learning the actual coordinates $(x,y)$, the blinding randomness $(n_x,n_y)$, or the LDS-generated Schnorr signature contents.

Each Bulletproof range proof satisfies the zero-knowledge and soundness properties, ensuring that an authentication session reveals no information beyond the validity of the claimed geofence membership.

Under the hardness of the elliptic-curve discrete logarithm problem and the zero-knowledge and soundness properties of Bulletproof range proofs (with soundness error approximately $2^{-128}$), the adversary’s advantage in reconstructing the UAV’s precise location or flight trajectory remains negligible. Consequently, PrivLocAuth achieves strong location privacy, session unlinkability, and resistance to long-term spatial profiling, even under repeated geofence verifications across multiple domains.

7. Experimental Analysis

7.1. Computational Efficiency

The computational performance of the proposed PrivLocAuth protocol was evaluated using a Python-based benchmarking environment. The experimental evaluation was conducted on a consumer-grade laptop manufactured by HP Inc., Palo Alto, CA, USA, equipped with an AMD A8-7410 APU with Radeon R5 Graphics (Advanced Micro Devices, Sunnyvale, CA, USA) and 8 GB of RAM, running a Linux operating system and Python 3.13, employing explicitly defined cryptographic primitives and high-level data-processing libraries. The coincurve (https://github.com/ofek/coincurve (accessed on 23 November 2025)) library was used for elliptic-curve key generation and ECDH scalar multiplication operations. Schnorr signature generation and verification were implemented using the ecdsa (https://github.com/warner/python-ecdsa (accessed on 23 November 2025)) library, following the Schnorr-based authentication mechanism specified in the protocol design without reliance on hash-based constructions. Bulletproof range proof generation and verification were performed using pybulletproofs (https://github.com/initc3/pybulletproofs (accessed on 23 November 2025)), employing standard logarithmic-size range proofs. Session-key establishment and symmetric encryption were realized using primitives provided by the cryptography (https://github.com/pyca/cryptography (accessed on 23 November 2025)) library. Matplotlib 3.9.0 (https://matplotlib.org/ (accessed on 23 November 2025)) was used solely for visualization of experimental results.

Each cryptographic operation was executed 200 times, and its average execution time $T\left(O_i\right)={\displaystyle \frac{1}{200}}{\sum }_{j=1}^{200}{t}_j$ was recorded using Python’s high-resolution time.perf_counter(). The measured mean execution times are 0.227 ms for elliptic-curve scalar multiplication, 0.227 ms for elliptic-curve point addition, 0.553 ms for Pedersen commitment computation, 0.393 ms for Schnorr signing, 0.551 ms for Schnorr verification, 2.809 ms for ECDH-based asymmetric encapsulation and decapsulation, 0.709 ms for session-key encryption and decryption using AEAD primitives, 29.453 ms for Bulletproof range proof generation, and 4.243 ms for Bulletproof range proof verification. The session key $S{K}_{d,c}$ is derived via HKDF-SHA256 from $(n_1,n_2)$, whose computational cost is negligible compared to elliptic-curve and Bulletproof operations and is therefore omitted from the total cost.

The total computation time for each protocol phase was obtained by multiplying the mean execution time of each cryptographic operation by the number of times it appears in that phase and summing the results. In the Registration phase, two elliptic-curve scalar multiplications (performed by the UAV and the Registration Authority, respectively) and one Schnorr signing operation are executed, resulting in a total computation cost of 0.847 ms.

The Cross-Domain Authentication phase includes ECDH-based asymmetric encapsulation for the initial message exchanges, symmetric AEAD operations for session-protected messages, one elliptic-curve scalar multiplication, one Schnorr verification, two Pedersen commitment computations, and two Bulletproof range proof generations and verifications. The cumulative computation overhead of this phase is 72.794 ms across all participating entities.

Accordingly, the end-to-end computation time of the PrivLocAuth protocol, combining the Registration and Authentication phases, is 73.641 ms.

Figure 4 presents two visualizations: the first illustrates the average execution time of individual cryptographic operations, while the second depicts the aggregated computational overhead of each protocol phase. The results indicate that the Registration phase contributes minimally to the overall computational cost, whereas the Authentication phase is dominated by Bulletproof range proof generation and verification, providing a clear view of both per-operation costs and the cumulative protocol overhead.

7.2. Communication Overhead Analysis

The communication overhead of the proposed PrivLocAuth protocol is evaluated by accounting for all messages explicitly exchanged in Algorithms 1 and 2. The protocol is instantiated over the secp256r1 elliptic curve. A compressed elliptic-curve point occupies 33 bytes, a Schnorr signature occupies 64 bytes, nonces are 32 bytes, timestamps are 8 bytes, Pedersen commitments are 33 bytes, and each Bulletproof range proof occupies approximately 800 bytes for a 32-bit coordinate range.

As specified in Algorithm 2, asymmetric encryption is used only for the initial authentication messages exchanged between the UAV and the CDS. This encryption encapsulates an ephemeral elliptic-curve Diffie–Hellman exchange and introduces a fixed 64 byte overhead per ciphertext due to the transmitted ephemeral public key. After session key derivation using HKDF, subsequent messages are protected using symmetric authenticated-encryption (AEAD), whose ciphertext expansion is negligible and therefore not counted.

During registration (Algorithm 1), the UAV generates a key pair $(V_d,P_d)$ and sends the registration message $M_d=(I{D}_d \Vert P_d)$ to the RA. The identifier $I{D}_d$ is 32 bytes and the compressed public key $P_d$ is 33 bytes, yielding a message size of 65 bytes. The RA verifies the validity of $P_d$ and issues a registration credential $Cre{d}_d={\mathsf{SchnorrSign}}_r\left(P_d\right),$ which consists solely of a 64-byte Schnorr signature binding the UAV’s public key to the RA. The total communication overhead of the registration phase is therefore 129 bytes.

To initiate authentication (Algorithm 2, Phase 1), the UAV selects a fresh nonce $n_1$ and timestamp $T_d$ and sends $Aut{h}_d={\mathsf{Enc}}_{P_c}(P_d \Vert n_1 \Vert Cre{d}_d \Vert T_d)$ to the CDS. The plaintext includes the UAV public key (33 bytes), nonce (32 bytes), credential (64 bytes), and timestamp (8 bytes), totaling 137 bytes. Including the asymmetric encryption overhead, the transmitted message size is 201 bytes. Upon successful validation (Algorithm 2, Phase 2), the CDS generates a fresh nonce $n_2$, timestamp $T_c$, and a geofence $R=[X_{min},X_{max},Y_{min},Y_{max}]$, and responds with $Aut{h}_c={\mathsf{Enc}}_{P_d}(P_c \Vert R \Vert n_1 \Vert n_2 \Vert T_c).$ The plaintext contains the CDS public key (33 bytes), the geofence coordinates (16 bytes), two nonces (64 bytes), and a timestamp (8 bytes), for a total of 121 bytes. With asymmetric encryption overhead, this message occupies 185 bytes.

Following successful decryption (Algorithm 2, Phase 3), the UAV derives the session key $S{K}_{d,c}=\mathsf{HKDF}(K_d,n_1,n_2),$ constructs Pedersen commitments $C_x$ and $C_y$, and generates Bulletproof range proofs ${\pi }_x$ and ${\pi }_y$. The LDS verifies the proofs and issues an attestation $Cre{d}_{\ell }={\mathsf{SchnorrSign}}_{\ell }(K_d \Vert C_x \Vert C_y \Vert {\pi }_x \Vert {\pi }_y \Vert R \Vert T_{\ell }).$

Finally, the UAV sends $Aut{h}_{d,c}={\mathsf{Enc}}_{S{K}_{d,c}}(Cre{d}_{\ell } \Vert T_d)$ to the CDS. The attestation payload consists of the UAV public key (33 bytes), two Pedersen commitments (66 bytes), two Bulletproof proofs (1600 bytes), the LDS Schnorr signature (64 bytes), the geofence description (16 bytes), the LDS timestamp (8 bytes), and the UAV timestamp (8 bytes), totaling 1795 bytes.

Communication between the UAV and the LDS is confined to a local administrative domain and is therefore excluded from the cross-domain communication overhead (

Table 4. Communication overhead of the PrivLocAuth protocol.

Phase	Message Contents	Size (Bytes)
1. Registration (plaintext)
$M_d$ (UAV → RA)	$I{D}_d,P_d$	65
$Cre{d}_d$ (RA → UAV)	${\mathsf{SchnorrSign}}_r\left(P_d\right)$	64
Registration total: 129 B
2. Cross-Domain Authentication
$Aut{h}_d$ (UAV → CDS)	$P_d,n_1,Cre{d}_d,T_d$ + asym. OH	201
$Aut{h}_c$ (CDS → UAV)	$P_c,R,n_1,n_2,T_c$ + asym. OH	185
$Aut{h}_{d,c}$ (UAV → CDS)	$Cre{d}_{\ell }(K_d,C_x,C_y,{\pi }_x,{\pi }_y,R,T_{\ell }),T_d$	1795
Authentication total: 2181 B
Overall total: 2310 B (≈2.31 KB)

).

Accordingly, the total communication overhead of the cross-domain authentication phase is $201+185+1795=2181\mathrm{bytes}.$ Including the registration phase, the overall communication cost of the PrivLocAuth protocol is 2310 bytes (approximately 2.31 KB).

8. Conclusions

This paper presented PrivLocAuth, a privacy-preserving cross-domain UAV authentication protocol that enables cryptographically enforced geofence compliance without disclosing exact location information or long-term UAV identities. By combining Pedersen commitments, Bulletproof range proofs, and Schnorr-based credentials, the protocol achieves fine-grained spatial authorization together with strong privacy and unlinkability guarantees. PrivLocAuth adopts a role-separated architecture in which the RA is restricted to one-time enrollment and on-demand revocation, the LDS validates location correctness and freshness, and the CDS enforces access control using zero-knowledge evidence. This design eliminates continuous authority involvement and prevents centralized tracking or session correlation.

Formal security analysis demonstrates that PrivLocAuth provides resistance to impersonation, replay, and forgery attacks under the hardness of the Elliptic Curve Discrete Logarithm Problem, while geofence compliance is guaranteed by Bulletproof soundness bounded by approximately $2^{-128}$. Session unlinkability and protection against trajectory inference are ensured through per-session Pedersen commitments, fresh nonces, and short-lived LDS attestations. Experimental evaluation confirms that PrivLocAuth is practical for real-time UAV deployment. The total computation overhead is $73.641\mathrm{ms}$, dominated by Bulletproof generation and verification, while the overall communication overhead remains modest at 2310 bytes per UAV, despite the inclusion of zero-knowledge proofs. This demonstrates that the protocol is suitable for bandwidth- and energy-constrained UAV platforms, with minimal impact on mission performance.

Overall, PrivLocAuth demonstrates that strong location privacy, formal security guarantees, and efficient cross-domain authentication can be achieved simultaneously. It provides a robust foundation for secure and privacy-preserving UAV operations in dynamic multi-domain environments, supporting fine-grained spatial authorization without compromising operational efficiency or user privacy.