The evolution of mobile technologies from 2G to 5G has greatly enhanced communication services, with Mobile Network Operators (MNOs) managing infrastructure and sensitive subscriber data, including personal details, location, and call histories. However, privacy breaches and unauthorized profiling due to unethical practices, employee misbehavior, or data leaks remain significant risks, as demonstrated by major fines levied on the four major US carriers for selling subscriber data to third parties [31]. The root issue lies in MNOs' reliance on long-term identifiers like phone numbers and the Subscription Permanent Identifier (SUPI, the permanent identifier used within 5G networks), to provide services, enabling tracking and profiling by default.
Anonymous mobile network access. To address these concerns, one emerging approach is to enable users to access the mobile network anonymously, i.e., accessing network service without exposing any long-term subscription identifier (e.g., phone number, SUPI) as seen in recent solutions [51], [48], [55], [13], [42], [54]. These methods empower users to access MNO's services without disclosing their true identities (i.e., anonymity), and prevent the untrusted MNOs from linking multiple anonymous access sessions together (i.e., unlinkability). For example, [51] allows subscribers to use an ephemeral International Mobile Subscriber Identity (IMSI, the equivalent of SUPI before 5G) while using services from untrusted MNOs. [48], [55], [13], [42], [54] leverage cryptographic methods such as blind signatures and anonymous credentials to enable users to authenticate themselves to the mobile network anonymously and have unlinkable pseudonyms across different access sessions, thereby protecting phone user's identity and location privacy against untrusted MNOs. MNOs can no longer track the current location of a specific phone number nor know the real person behind a pseudonym.
Supporting Essential Cellular Functions amid Anonymity. Despite these advancements, there are outstanding challenges that hinder the practicality of these privacy-preserving mechanisms due to the lack of support for essential functions that are native to the incumbent mobile networks. The anonymous mobile access mechanisms as introduced in [51], [48], [55], [54] are generally designed for user access control in standalone cases, e.g., obtaining a temporary network identifier after successful anonymous authentication. They are not readily applicable (or do not specify how) to support essential cellular functions that involve continuous interaction, represented by voice calls and user charging. For example, MNOs rely on users' identifiable information, e.g., the IP addresses (allocated within the mobile core), physical location (i.e., which cell tower the user connects to), and data usage of a particular phone number, to enable voice calls and message routing between users, and billing. However, the necessity to gather such data clashes with the goals of subscriber privacy and tracking prevention. While an anonymous mobile access scheme conceals all identifiable information from the untrusted MNOs, supporting the essential mobile network functions would again require user tracking and re-identification. These constraints significantly limit the practicality of applying privacy-preserving access technologies in mobile networks. This paper aims to address the dilemmas between subscriber privacy and essential mobile network functions. Specifically, we identify two key objectives that must be met by an anonymous mobile network access system: Obj-1 : Making Anonymous User Callable through Native Mobile Networks. When using an anonymous authentication technique, the MNO can only ascertain that an anonymous but legitimate User Equipment (UE) is connected to a particular cell tower and using a specific IP address, but it cannot know this anonymous UE's phone number or SUPI (or any other long-term identifier). Meanwhile, a caller knowing the user's phone number cannot make the call through, since the callee's home network does not know which cell tower and which IP address the phone number is associated with. Therefore, the key objective is to make an anonymously authenticated user reachable to its callers. A caller does not have to be an anonymous user.
To realize the above objective, one trivial path is to use third-party Voice over IP (VoIP) services (e.g., Skype) over non-mobile networks as suggested in [48]. This, however, would require a secondary (e.g., Internet) connection and also lead to under-utilization of the mobile network's native call bandwidth and be a disincentive for the MNOs to provide anonymous service. Therefore, it is important to enable anonymously authenticated users to use the native call functions, e.g., VoLTE and VoNR, of the same mobile network.
Obj-2 : Real-time Balance Management and Usage Charging. In mobile networks, charging falls into two categories: prepaid, which requires deduction from the account balance, and postpaid, which involves usage recording and aggregation. Existing anonymous mobile network access schemes [48], [55], [13] do not support charging based on the UE's data usage, as explicit balance deduction or usage aggregation requires the UE to be traceable across different sessions, directly contradicting the privacy goal of unlinkability. Prepaid services face the challenge of managing real-time balances, requiring MNOs to accurately track and deduct credits across multiple unlinkable sessions tied to a single UE. Likewise, postpaid services encounter difficulties in aggregating usage across different pseudonyms without compromising anonymity or linking sessions. A prepaid solution proposed in [48] for charging the anonymous UE uses anonymous tokens (via blind signatures [24], [25]), where tokens represent fixed usage (e.g., one token per minute). UEs receive untraceable tokens monthly from their Home Network (HN) based on their subscription plan. However, this mechanism is unsuitable for modern mobile networks as it lacks precise, real-time usage measurement and charging. MNOs must compel UEs to pay before a session begins and allocate fixed session lengths for calls, leaving UEs unable to reclaim unused tokens if the actual call durations are shorter than the paid session. In contrast, [42] proposes a token-based postpaid model that relies on an independent third-party broker, requiring users to claim their consumed anonymous tokens later to settle payments. This approach introduces additional operational costs for MNOs to manage anonymous token lists and significantly deviates from traditional cellular service models. Besides, PGUS [54] considers a Thick-MVNO environment where both the MNO and MVNO are modeled as semi-honest and non-colluding. It integrates an anonymous cellular access scheme with an interoperator billing verification mechanism using a sanitizable blind signature and a tracing technique to prevent MNO overbilling of the MVNO. While PGUS protects user anonymity and provides inter-operator accountability (i.e., MVNO-MNO billing reconciliation), it does not specify mechanisms for billing subscribers based on their individual usage. Despite these advances, existing schemes [48], [42], [54] still lack real-time, fine-grained balance management compatible with modern network operations. This gap limits the practicality of anonymous access and discourages MNO deployment. A privacy-preserving, real-time charging framework for both prepaid and postpaid services is essential for practical adoption of anonymous cellular access.
Our Design. We propose ANONYCALL, a privacy-preserving call management system to enable native phone calls and usage charging while supporting anonymous mobile network access. ANONYCALL achieves the two aforementioned objectives under the condition that an established anonymous mobile network access method [48], [55], [13], [42], [54] allows a UE to anonymously authenticate itself and register with a serving MNO without revealing its permanent identifiers (e.g., phone number, IMSI/SUPI). Upon successful authentication, a UE obtains temporary identifiers from the MNO for standard mobile network access, including a dynamically assigned IP address for IP-based services within the mobile network (e.g., messaging, internet access, and call sessions), and a Uniform Resource Identifier of the Session Initiation Protocol (i.e., SIP URI) for initiating calls. It is important to note that this IP address is used solely for routing packets within the operator's infrastructure and is not publicly discoverable. The assigned temporary IP and SIP URI maintain UE unlinkability, as the MNO cannot link them to the anonymous UE's previous pseudonyms or used IP addresses.
Caller Authentication and Anonymous Callee Discovery. To achieve Obj-1 , we introduce an out-of-band authentication and authorization method that allows an anonymous callee to authenticate the caller asynchronously and authorize the sharing of its temporary SIP URI with the caller. A SIP URI is a standardized identifier used in both cellular and non-cellular systems to uniquely identify and reach a phone user. Since the SIP URI is a standard option for dialing phone calls, the callee's home network can resolve and retrieve the callee's IP address from the SIP URI to facilitate native call routing. Integrating ANONYCALL to the existing anonymous access solution ensures that an anonymous UE remains reachable for any authenticated callers. See Sec III for details.
Privacy-preserving Usage Charging with Anonymous Accountable Credentials. To achieve Obj-2 , we incorporate a fine-grained, privacy-preserving usage charging method facilitated by an anonymous but accountable balance credential cred. It leverages cryptographic techniques, including an adaptable blind signature scheme (the Structure-Preserving Signature Scheme on Equivalence Classes, or SPS-EQ), homomorphic commitments, and zero-knowledge proofs (ZKP), to support accurate charging for anonymous sessions in both prepaid and postpaid modes without revealing UE identities. For each access, a UE can transform its cred to an unlinkable but verifiable format, proving its validity through SPS-EQ's adaptability. The MNO can homomorphically adjust (add or subtract) the balance attribute in cred using its signing keys without knowing the actual balance when a session ends.
Several hidden tracing parameters are also embedded in the cred, appearing uniformly random during each session to ensure benign users' access remains unlinkable. However, if a UE attempts to reuse an old credential with a higher balance or lower cumulative usage, its identity can be automatically revealed (i.e., computed) from the tracing parameters. This approach ensures accurate and real-time charging in two charging modes without compromising the anonymity and unlinkability of benign UEs. Sec. IV details the design.
Prototype Evaluation. We deployed the two core functionalities of ANONYCALL on the UE side using smartphones and evaluated the feasibility of establishing calls among anonymous UEs in a standard calling system. We measured the overhead introduced by each proposed method, and our results show that the total latency added by ANONYCALL to the conventional call establishment process is below 200 ms, demonstrating that it is a viable solution for providing subscriber privacy in mobile networks.
To summarize, ANONYCALL has the following contributions:
1) It enables anonymous phone users to receive calls without compromising their anonymity and unlinkability through an out-of-band authentication and temporary SIP URI sharing method.
2) It provides a fine-grained, privacy-preserving charging method that maintains the anonymity and unlinkability of benign users while de-anonymizing misbehaving UEs attempting to double-spend credentials.
3) It can be seamlessly integrated into standard calling systems native to modern mobile networks without requiring new entities or infrastructural modifications.
While the conventional circuit-switch-based methods (e.g., CDMA, UMTS, GSM) for facilitating voice communications have been widely phased out in many parts of the world, VoIP, as a broader technology applicable over various network types, is increasingly becoming the standard for voice communication. VoIP is network-agnostic, meaning it does not necessarily require any specific network infrastructure beyond IP connectivity. Besides, it can function not just over the I.
TABLE I. EXAMPLE -SUBSCRIBER John Doe'S PERMANENT AND TEMPORARY INFORMATION USED WITHIN THE 5G NETWORK. * FOR NON-ROAMING CASES, SN = HN. Information Example Format Assigned By Type 1 ⃝Phone Number +1-870-123-4567 HN Permanent 2 ⃝SUPI 999700000000001 HN Permanent 3 ⃝SIP URI john.doe@ims.verizon.net HN (IMS) Semi-Permanent 4 ⃝5G-GUTI 99970000ffffffff SN Temporary 5 ⃝IP Address (IMS) 192.0.2.1 HN (IMS) Temporary 6 ⃝IP Address (Internet) 198.0.11.4 HN/SN Temporary Internet but also as part of cellular networks through technologies like Voice over LTE (VoLTE), Voice over New Radio (VoNR), and Voice over WiFi (VoWiFi). VoLTE and VoNR are essentially two VoIP methods designed for delivering voice services over cellular networks. They are dependent on cellular infrastructures for functionalities like routing and connection control and require SIM-based user authentication (e.g., 5G-AKA). While VoLTE is tailored for 4G/LTE, VoNR is the 5G equivalent of VoLTE providing better bandwidth and lower latency enabled by the 5G New Radio (NR) technologies.
The IP Multimedia Subsystem (IMS) is crucial for enabling and managing IP-based multimedia services such as SMS, voice, and video calls within cellular networks. Fig. 1 illustrates the IMS core integration in both 4G and 5G architectures, with VoLTE and VoNR relying heavily on it for multimedia services over IP networks. Non-cellular VoIP providers often use simpler architectures containing some IMS elements. The Session Initiation Protocol (SIP) signaling protocol is integral for both cellular and non-cellular VoIP services, handling session management tasks such as establishing, modifying, and terminating multimedia sessions, no matter if they deploy the whole IMS core. On mobile devices, the IMS client for VoLTE and VoNR services is typically embedded in firmware by manufacturers or chipset vendors. The IMS stack includes the necessary components like the SIP for signaling, and the Real-time Transport Protocol (RTP) for media transmission, integrating with the operating system to deliver multimedia services over cellular networks.
This section outlines how a UE attaches to the 5G and IMS cores and initiates calls (Fig. 2), with corresponding subscriber identifiers and additional details provided in TABLE I.
1. AMF Registration and IP Assignment. To access any services on a mobile network, a UE must first register with the Access and Mobility Management Function (AMF) in the 5G Core (5GC) or the Mobility Management Entity (MME) in the Evolved Packet Core (EPC) for 4G. This registration occurs in the control plane, as depicted in Fig. 1, by initiating the authentication and key agreement process (i.e., the 5G-AKA protocol). This process relies on subscription credentials, including SUPI and the permanent keys pre-loaded into the subscriber's SIM card. The SIM acts as the root of trust in cellular networks, and the combination of the SUPI and permanent keys verifies the subscriber's identity to the MNO.
After successful authentication, the AMF assigns the UE a fresh 5G-Globally Unique Temporary Identifier (5G-GUTI), indicating successful registration and granting temporary access. The UE then establishes the necessary PDU sessions for service connectivity. A typical UE maintains at least two active IP addresses per registration, one for internet access and one for IMS services, with additional addresses possible for services such as VPNs. The Session Management Function (SMF) coordinates with the User Plane Function (UPF) to allocate these addresses:
•an Internet IP address from a general pool or obtained dynamically via the operator's DHCP server; •an IMS IP address from a dedicated IMS IP pool or via DHCP in the IMS domain.
The SMF also instructs the UPFs to establish user-plane paths to carry traffic associated with the UE's assigned IP addresses.
During Roaming. UE registers with the AMF of the serving network (SN), which authenticates the UE by contacting the UE's HN. The SN determines the 5G-GUTI for the roaming UE. In most deployments, the Internet IP address is allocated by the HN's UPF (home-routed roaming); in less common local breakout scenarios, it may be assigned by the SN. The IMS IP address, however, is always allocated by the HN, even when the UE is roaming, and the SIP traffic is routed to the P-CSCF in the HN. This ensures policy and charging control and support service continuity (e.g., seamless call handover).
AMF Re-registration and IP Re-assignment Interval. The Re-registration interval usually ranges from a few hours to a couple of days and is determined by different MNOs, besides, it will also be triggered by events such as device power-off, SIM removal, or airplane mode. This periodic update ensures that the UE remains connected and reachable via the 5GC. As noted in [38], [55], the 5G-GUTI should be refreshed frequently to enhance unlinkability, limiting the duration for which a UE retains the same identifier. In addition, a new IP address is generally assigned when the underlying PDU sessions are released or expire. The actual reassignment interval depends on operator-specific configurations and session management policies.
To enable VoLTE or VoNR services on the data plane, a UE must register with the IMS core by sending a SIP REGISTER request to the Proxy Call Session Control Function (P-CSCF) in its home IMS core. This request includes the UE's IMS Public User Identity (IMPU), typically a phone number and/or a SIP URI -an email-like address used for identifying callers and callees during call setup. A phone number maps to one or more SIP URIs in the IMS architecture. For example, a Verizon subscriber, John Doe, with the phone number +1-870-123-4567, can have SIP URIs like sip:18701234567@ims.verizon.net and sip:john.doe@ims.verizon.net. These SIP URIs, along with other UE information (e.g., IP, 5G-GUTI, Cell ID), are stored in the Unified Data Management (UDM) for 5G or the Home Subscriber Server (HSS) for 4G. The Serving Call Session Control Function (S-CSCF) authenticates the UE by interacting with the UDM through an AKA process (similar to 5G-AKA). After authentication, the UDM provides the S-CSCF with the user's subscription information, such as the subscribed plan and allowed usage. The S-CSCF finalizes registration by sending a SIP 200 OK response to the UE.
During Roaming. Unlike AMF registration, the UE registers only with its home IMS core, and as noted earlier, the IMS IP is always allocated by the HN, even when roaming. To access IMS-based services such as voice calls, the UE connects to the HN's IMS core through the SN's infrastructure.
IMS Re-registration Interval. This interval is determined by the expiration timer in the SIP REGISTER response. Common values are 10 or 60 minutes, but it can be adjusted based on the policies and requirements of individual MNOs.
3. Session Establishment. When the UE initiates a call, the IMS converts the callee's phone number into a SIP URI via ENUM or DNS lookup. A SIP INVITE request, containing the callee's and caller's SIP URIs along with the caller's current IP address, is sent to the callee's home IMS core. Upon a successful handshake-meaning the callee accepts the call and step 3 in Fig. 2 is completed-voice or video data packets are exchanged directly between the caller and callee using the RTP and Real-time Transport Control Protocol (RTCP) over the established IP connection.
During Roaming. To ensure authentication, billing, and policy enforcement, all call session establishments must traverse a user's home IMS core, even while roaming. For instance, consider caller A from carrier 1 and callee B from carrier 2. If caller A is not roaming but callee B is roaming on carrier 3, A's SIP INVITE is routed via 1's IMS core, then to B's home IMS core (carrier 2), and finally to the visited IMS of carrier 3. If B accepts the call, the media path is established directly between carriers 1 and 3.
Charging Methods. In 5G, the Charging Function (CHF) manages subscribers' charging records. The SMF tracks session data usage and reports it to the CHF. For prepaid accounts, the CHF authorizes service usage based on the subscriber's balance, authorizes usage based on predefined thresholds, and deducts credit in real-time, which is also known as real time online charging (OCS) in 5G's Converged Charging System (CCS). For postpaid accounts, the CHF collects usage data records per session. These records are then aggregated later for billing (i.e., batch-based offline charging).
During roaming. As all IMS-based services (e.g., voice calls) are home-routed, the HN maintains full visibility and control over each session, even during roaming. This allows the HN to accurately charge the user based on real-time session data. In contrast, for services utilizing local breakout, the HN does not share the UE's account balance with the SN. In prepaid scenarios, the SN monitors session activity and periodically requests authorization from the HN. In postpaid scenarios, the SN generates charging records and forwards them in batches to the HN. In some cases, the SN bills the HN based on wholesale agreements, without enforcing user-specific usage limits.
Our out-of-band authentication method establishes callercallee trust without new authorities. While ANONYCALL does not assume any specific PKI, it requires a minimal trust anchor that can be instantiated using existing frameworks already deployed in telecom and digital-identity ecosystems. For example, on the telecom side, systems such as STIR/SHAKEN [30], mandated across U.S. carriers and adopted in regions such as France, the U.K., and Canada, show how operator PKI is formed: each carrier maintains its own signing keys and obtains certificates from accredited CAs, enabling crossdomain verification without private-key sharing. Trust and revocation follow standard CA hierarchies (CRLs/OCSP), and the same model applies in roaming where operators validate identity information using their own certificates. In parallel, the W3C-standardized Decentralized Identifiers (DIDs) [2] and Verifiable Credentials (VCs) [12] provide portable identity credentials that can be verified globally. These standards underpin major national and industrial frameworks, including the EU's eIDAS regulation [3], and the EU Digital Identity Wallet (EUDI Wallet) [26], Australia's TDIF [1], Canada's PCTF [11], Microsoft Entra Verified ID [10], and the Linux Foundation's CREDEBL project [52]. In these systems, users hold digital wallets containing VCs issued by trusted authorities, and global interoperability arises because each VC is verified using the issuer's public keys and revocation data published in public DID registries, rather than any single national certificate hierarchy. The standards also support zeroknowledge proofs for selective disclosure, such as proving age eligibility without revealing a full birth date or address.
Together, these deployments show that cross-jurisdiction trust can be achieved without shared secrets or new authorities. ANONYCALL can therefore rely on these existing infrastructures for secure, standard-compatible trust establishment while remaining agnostic to any particular identity system.
Overview. This section introduces our first component, which enables native calling to anonymous callees. ANONYCALL assumes that a UE can anonymously register with the 5G and IMS cores via existing solutions [48], [55], [13], [42], [54] without revealing its phone number or SUPI. To make an anonymous callee reachable by callers, we incorporate an outof-band authentication method (Sec III-A) to help the anonymous callee establish secure channels and share its temporary SIP URI with trusted callers, serving as the preamble for call initiation. The caller can then initiate a private call with the callee using the obtained temporary SIP URI via the native SIP process within mobile networks (Sec III-B).
Threat Model. ANONYCALL assumes that MNOs are honest but curious. They operate cellular network functions as expected, adhering to protocols such as allocating dynamic IP addresses via DHCP for registered UEs, routing calls correctly between callers and callees, and accurately executing charging protocols and billing users based on actual usage. However, MNOs may attempt to compromise privacy by uncovering the permanent identities (e.g., phone numbers, SUPIs) of anonymous UEs or identifying participants in specific conversations.
High-level Workflow. As shown in Fig. 3, the caller first dials the callee's phone number (Step 1) and is directed to the callee's authentication agent URL (Step 2), for example via a prerecorded greeting, or a DID-based record. The caller then authenticates with the agent according to the callee's policy (Steps 3-4). Once authorized, the agent returns the callee's temporary SIP URI (Step 5). The caller then re-dials using this SIP URI, and the IMS completes the call through the standard SIP routing process without exposing any long-term identifiers (to describe in Sec. III-B).
a. MNO side -Temporary SIP URI Assignment during Anonymous UE Registration. The out-of-band authentication function requires minimal changes on the MNO side. Specifically, as introduced in Sec II-B, the home IMS core typically registers the UE's SIP URI every 10 or 60 minutes.
Our method slightly modifies this process by having the home IMS core assign and register a fresh SIP URI for an anonymous UE at this step (i.e., step 2 of Fig. 4), based on the UE's IP address (for IMS) assigned by the 5GC (SMF) during UE Registration (step 1). This is feasible because a UE can have multiple SIP URIs simultaneously in current cellular networks. A temporary SIP URI is unique within the operators' domain as long as it correctly binds to the UE's current IMS IP address, e.g., a UE with IP:192.0.2.1 allocated in step 1 of Fig. 4 can immediately obtain a SIP URI sip:192.0.2.1@ims.anonycall.xyz from its IMS core at step 2. This SIP URI becomes invalid once the IP address is released, e.g., indicated by a DHCP RELEASE message sent by the UE. This method ensures that an anonymous callee's SIP URI always maps to its real-time IMS IP address and there are no SIP URI collisions within the mobile network. As SIP URI natively supports appending optional and customizable headers and parameters for conveying extra details, we can define a privacy parameter to indicate the call mode, e.g.: Parameter: privacy = <level > Description: Define a privacy level for the call Example: sip:192.0.2.1@ims.anonycall.xyz; privacy=full
This parameter instructs the IMS core to resolve a SIP URI to its IMS IP address by using the content before the @ symbol.
While dialing through SIP URI is a standard method supported by many applications (discussed by Q1 in Sec V-B), this approach guarantees discoverability whenever someone dials an anonymous UE's temporary SIP URI.
b. UE side -A Caller Authentication Agent for Sharing the Temporary SIP URI. Figure 3 illustrates a high-level outof-band authentication flow between a callee and an unknown caller (i.e., the callee has no prior knowledge of the caller).
We consider both the digital wallet on the UE, which stores VCs or digital certificates, and the authentication agent on the UE to be trustworthy, as they are usually deployed as mobile apps and operate within the same security domain as the user. Scenarios involving collusion between the agent and an MNO are excluded from consideration. Specifically, when a UE acts as a caller, it retains full control over its digital wallet and voluntarily consents to disclose VCs or certificates for authentication when requested by the callee's agent. Conversely, when the UE is the callee, its authentication agent will only share sensitive information (i.e., a temporary SIP URI) with an authenticated caller. To facilitate the authentication of unknown callers and the controlled sharing of the temporary SIP URI, a UE can predefine an authentication policy via its authentication agent. This policy defines the conditions under which the agent will disclose the UE's current SIP URI to a caller. The authentication agent app on the UE periodically retrieves the current SIP URI by accessing the SIP information stored on the UE's IMS clientfoot_0 .
Authentication Policy and Methods. The policy can be as simple as automatically allowing any contact stored in the callee's contact book or any registered business number listed on Google to pass authentication. More flexible policies can be implemented by leveraging existing trust frameworks mentioned in Sec II-C. For instance, the callee (say, John) can configure the authentication agent to accept calls from authorities, healthcare providers, and classmates. The agent will then authorize sharing the SIP URI with a caller who presents a certificate or VC with valid digital signatures, demonstrating that they satisfy the specified criteria, such as being a verified doctor or graduating from the same college as John. Crucially, the authentication agent does not require John to operate manually or to be always online. It runs as a highly available web service on behalf of John-automatically authenticating and sharing John's current SIP URI with the callers when they satisfy the policies. An optional Online Agent (e.g., a cloud-based service) can be employed to periodically synchronize the SIP URI and handle authentication when John's device has limited network access. The secure storage of the SIP URI in a cloud-based agent depends on standard cloud security measures, which are beyond the scope of this paper. Besides, the temporary SIP URI can optionally be hidden from the authentication and online agents by using a common clientside encryption model (e.g., Apple's iCloud Keychain [8]), especially when the service is deployed by a semi-trusted party such as a dedicated Mobile Virtual Network Operator (MVNO). We further discuss this scenario in Q3, Sec. V-B.
After successful authentication, the caller can use the obtained SIP URI to call the anonymous callee, John. John's
A 5GC IMS Core B 3. Anonymous Session Establishment SIP MESSAGE (B's SIP URI) 202 Accepted SIP MESSAGE 200 OK SIP INVITE (B's SIP URI) 100 Trying Session Progress 180 Ringing 200 OK SIP INVITE(B's SIP URI) Session Progress 180 Ringing 200 OK 2.Anonymous IMS Core Registration SIP Register 401 Unauthorized SIP Register 200 OK (SIP URI assignment) Case II: Voice/Video Call Over IMS < 5G-GUTI, IP > 1.Anonymous UE Registration Case I: SMS Over IMS Private Voice/Video Conversation B also executes steps 1,2 with its home network (omitted in this figure) home IMS core can resolve the SIP URI to an IP once it notices the Privacy parameter in the SIP header, and route the call as usual. However, it cannot find out the callee's identity as John previously registered anonymously. Additionally, callers do not need to authenticate with John's agent before every call. Authentication can be performed once, after which John's agent grants the caller access rights to the SIP URI for an extended period (e.g., one year). This allows the caller to retrieve John's most recent SIP URI without repeating the authentication process for each call.
Q: How can a caller know the callee is in the anonymous mode and reach the callee's Authentication Agent? An anonymous UE can simply play a prerecorded greeting or voicemail indicating that it is operating in anonymous mode and directing the caller to its authentication agent. A more flexible option is to leverage the DID infrastructure: per W3C standards, each entity can publish a DID document in a public registry (e.g., a ledger). This JSON-formatted document includes a unique identifier, verification information (e.g., encryption algorithms and public keys), and a ServiceEndpoint field linking to specific services. In ANONYCALL, John's DID document can include the entry that links to its authentication agent, e.g., "ServiceEndpoint": "https://anonycall.xyz/ policy/18701234567". This URL embeds a phone number, allowing the caller to reach the authentication agent as described earlier (steps 1 and 2, Fig. 3).
Fig. 4 shows the full process of establishing an anonymous and private call within the mobile network. Although the example assumes both A and B are anonymous, ANONYCALL does not need a caller to be anonymous, i.e., A can register with the mobile network through standard method. Our primary focus is on how to direct calls to an anonymous callee B.
Anonymous Registration with 5GC and IMS core. A and B anonymously register with 5GC and IMS core, obtaining a dynamic IMS IP address (step 1) and a temporary SIP URI (step 2). The temporary SIP URI is assigned within the standard SIP message 200 OK, sent from the UE's home IMS core, indicating successful SIP registration with the IMS service. ANONYCALL does not introduce additional steps to the standard SIP process; steps 2 and 3 illustrate the usual SIP registration and session establishment protocol. The only change is that the SIP URI embedded in the header of the SIP messages 200 OK, SIP MESSAGE, and SIP INVITE is now a temporary SIP URI instead of a semi-permanent one.
Anonymous Session Establishment (SIP Signaling). In a standard SIP session establishment process, the header of a SIP MESSAGE (for SMS) or SIP INVITE (for voice/video calls) includes both the caller's and callee's SIP URIs. In ANONYCALL, the temporary SIP URI enables the IMS core to resolve the anonymous callee's IP address and route the SIP message accordingly without modifying the SIP signaling process. When A calls B, instead of dialing B's phone number, A dials the temporary SIP URI of B, obtained via the out-ofband authentication method (how to dial SIP URIs is explained in Q1, Sec V-B). After a successful handshake between A and B, communication is routed via the RTP protocol between their IP addresses. Besides, ANONYCALL remains effective during roaming, as discussed in Q3, Sec V-B.
This section introduces ANONYCALL's second core component -privacy-preserving charging for anonymous UEs. We begin with a high-level overview, introduce essential cryptographic preliminaries, and detail the charging process.
Threat Model. The honest-but-curious MNO assumption in Sec III applies here, consistent with [48], [55], [13], [42], [54]. Specifically, a curious MNO may try to identify the UE of a particular cred or link multiple credentials to the same UE. Additionally, we assume a dishonest UE may attempt double spending attacks by reusing previous credentials with a higher balance or lower cumulative usage.
The UE obtains a balance credential (cred) at the start of each month, typically following payment. During issuance, the UE is not anonymous, as the HN must verify its payment status and subscription plan. Users are thus expected to complete payment to receive or renew the cred, which then enables unlinkable charging and usage measurement.
Note that, unlike VCs, which are bootstrapped by existing W3C infrastructure and held in digital wallets, cred is issued by the UE's HN using standard cellular practices such as Overthe-Air (OTA) SIM provisioning.
To enable usage-based charging while preserving UE privacy, our cred design leverages a malleable and adaptable signature scheme (SPS-EQ) to construct a balance attribute. Specifically, cred includes an attribute indicating allowed usage (prepaid) or aggregated usage (postpaid), secret parameters (e.g., tracing index) for double-spending detection, and a signature over the (committed) attributes. Critically, SPS-EQ's properties allow the UE to adapt an original signature-message pair into a fresh, unlinkable but valid pair (cred ′ ), ensuring the HN cannot trace cred ′ to its original signed form.
During network access, an anonymous UE avoids revealing its actual account balance to prevent the HN from tracing its activity. Instead, it uses a commitment scheme to conceal the balance attribute and applies ZKP to demonstrate eligibility for services based on its plan type. This enables the HN to grant network access without creating linkability.
To be more specific, in prepaid mode, the UE can prove its hidden balance ≥ a threshold th predefined by the operator (e.g., th = 5 minutes) via ZKP (e.g., a range proof), allowing SMF to authorize a 5-minute slot. If the allocated usage time is running low during the session (e.g., if the UE has already consumed 4 minutes), the SMF can instruct the UE to prove again that its balance exceeds a larger amount (e.g., ≥ 10 minutes ). The SMF tracks call time and reports actual usage to the CHF, which deducts it from the hidden balance using the Pedersen Commitment scheme's homomorphic properties without accessing the UE's actual balance. The CHF then generates a new signature for the updated balance, enabling the UE to receive an updated credential. Note that such a predefined threshold th is common in carrier deployments and may vary with service requirements or MNO policy. To prevent link anonymous sessions (e.g., inference attacks via binary search), we assume th is fixed by prior agreement with the MNOs and applied uniformly to all users (e.g., 1-, 5-, or 10minute credit), ensuring that proof behavior does not reveal per-UE information.
In postpaid mode, the process is simpler, as the UE does not need to prove its balance before the session. Instead, the CHF adds the actual usage to the UE's hidden cumulative balance at the end of the session and updates its credential. This approach allows the CHF to manage prepaid deductions or postpaid usage for an anonymous UE while preserving anonymity and unlinkability.
Roaming. As discussed in Sec. II-B, IMS activity remains fully visible to the HN even during roaming, since all IMS traffic is home-routed through the HN's IMS core. In both prepay and postpay scenarios, the SN is only responsible for establishing the IMS PDU session with QoS parameters provided by the HN, and neither the SN nor the HN learns the UE's identity. Double Spending Detection. We incorporate a doublespending detection mechanism, commonly used in offline ecash systems, to prevent UEs from reusing credentials with higher balances or lower cumulative usage. ANONYCALL purposefully provides conditional unlinkability by embedding the UE's identity (specifically, the MSIN field from the SUPI, which uniquely identifies a subscriber within a carrier's database) into cred, along with two secret parameters that uniquely bind to each credential version. These parameters remain hidden and appear random as long as the UE uses each cred only once with the same balance. If double-spending occurs, the misbehaving UE's identity can be de-anonymized, discouraging the reuse of old credentials.
1) Zero-Knowledge Proof (ZKP): ZKP allows a prover to demonstrate knowledge of a secret without revealing it.
Schnorr's protocol [49] is a fundamental ZKP method where the prover shows knowledge of a secret x ∈ Z p such that h = g x mod p, relying on the hardness of the discrete logarithm problem (DLP). Schnorr's protocol is a specific instance of a three-round Σ-protocol [28], which can be converted into a non-interactive zero-knowledge proof (NIZK) using the Fiat-Shamir heuristic [32] under the Random Oracle Model (ROM) [50]. We use the Camenisch-Stadler notation [22] to represent the ZKP of discrete logarithms and concurrent statements throughout the paper. An illustrative notation is:
(1) The parameters preceding the colon are the secrets only known to the prover, while the rest are public and known to both the prover and verifier. This AND-composition example represents a ZKP of knowledge for the secrets α and β such that y = g α h β and α lies within a range [0, 2 n -1], where g and h are elements of a group G with prime order p, n is the number of bits used to represent the bounded range. This setup allows the prover to prove the correctness of the statement y = g α h β without disclosing α and β. A range proof (e.g., [21], [20]) that relies on commitment schemes and NIZK can be used to prove α is within a certain range without revealing any additional information about α. By convention, π outputs a boolean value indicating the validity of the proof.
2) Generalized Pedersen Commitment: Pedersen commitment [43] is a scheme that allows one to commit to a chosen value while keeping it hidden and revealing it later. Its homomorphic properties enable operations like addition directly on committed values, making it useful for privacy-preserving protocols. ANONYCALL uses the Generalized Pedersen Commitment, which allows committing to multiple messages or attributes simultaneously. Additionally, it can also integrate seamlessly with ZKP, enabling a prover to prove knowledge of committed values without revealing them.
Setup. Choose a large prime p and let G be a cyclic group of prime order p. Select n generators g 1 , g 2 , . . . , g n and h from the group G and publish them.
The commitment C has two properties: (1) Hiding. It conceals the vector ⃗ m due to the randomness introduced by r; (2) Binding. It is computationally infeasible to find another vector ⃗ m ′ and r ′ that produce the same commitment C.
Homomorphism. Pedersen commitment is additively homomorphic, enabling addition over committed messages m i without knowing the (m 1 , m 2 , . . . , m n , r). For example, given a new message m ′ 1 , an updated commitment can be computed as
This property allows efficient and secure updates to committed values, e.g., the balance attribute of a UE's cred.
3) Structure-Preserving Signature Scheme on Equivalence Classes (SPS-EQ): SPS-EQ is a malleable signature scheme that is existentially unforgeable under a chosen message attack (EUF-CMA) in bilinear group environments (Type-III pairings). It allows the same message to be represented in multiple ways while still being considered equivalent (explained in Appendix A-A2), making it ideal for constructing privacypreserving protocols [34], [19], [35], [27].
Adaptability. Given a signature σ on a message M , SPS-EQ enables a user to transform σ into a fresh signature σ ′ for another representation M ′ = M s , with a scalar s R ← Z * p without knowing the signing keys. The new σ ′ and M ′ are indistinguishable from the originals, ensuring the signer cannot link σ ′ to σ or M ′ to M . Besides, any party can verify that σ ′ is a valid signature of the new representative M ′ of the message M . Details of the SPS-EQ scheme and its adaptability are provided in Appendix A-A. For simplicity, we use abstract functions in the following discussions. Specifically, σ = Sign(sk HN , M ) denotes the signing process, where the signature σ is generated for M using the HN's secret key sk HN . Similarly, Verify(M ′ , σ ′ , pk HN ) represents the verification process, where any party can validate the adapted signature σ ′ for M ′ using the HN's public key pk HN .
We now explain the details of the charging method. The full protocol workflow is shown in Fig. 7 in the Appendix.
1) Setup and Key Generation. : This is a one-time process in which the HN generates the parameters required to issue cred for all its subscribers. The public parameters can be distributed to all UEs, for instance, via OTA SIM provisioning.
Setup(1 λ ). Given a security parameter λ, output a bilinear group BG. (Details on the bilinear group are not essential for understanding our scheme and are deferred to Appendix A-A1).
KeyGen(BG, ℓ). On input BG and a vector length ℓ = 2, this algorithm outputs a secret-public key pair (sk HN , pk HN ) for the HN, which is used for issuing the cred for the UE, i.e., generating the SPS-EQ signature on a certain message. Then it outputs the components for the generalized Pedersen commitments: select x i R ← Z * p , and set h i = g xi 1 for i = 0, . . . , 3. Only HN knows the secret trapdoors {x 0 , x 1 , x 2 , x 3 }, while g 1 and {h 0 , h 1 , h 2 , h 3 , h 4 } are public parameters known to UEs.
2) Balance Credential Issuance and Obtain: This process includes steps 1 2 3 . (The upper portion of Fig. 7 depicts the whole process.) To obtain a cred, the UE first prepares four parameters that will be embedded within the cred, where k, id, d are used for double-spending detection:
•M , an updatable balance attribute initialized by the UE as M 0 = 0, with its actual value determined later by the HN. In prepaid plans, M represents the allowed balance (e.g., M minutes of voice calls per month), and the HN blindly adds the allocated amount based on the UE's plan monthly. In postpaid plans, M tracks cumulative usage.
•k, a hidden identity attribute, also initialized as k 0 = 0, and later set by HN (i.e., MSIN). It can be used to de-anonymize the UE during double-spending. •id R ← Z p , a random number serving as the cred index.
1 UE commits to the initialized parameters. Commit(M 0 , k 0 , id, d, r). UE computes a Pedersen commitment of M 0 , k 0 , id, and d, where r is the blinding factor:
Next, UE forms (C, g 1 ), where g 1 is a public parameter. At this stage, the UE is not anonymous, as the HN must verify the subscribed plan to determine M and k for the credential.
To ensure anonymity and unlinkability in future credential use, the UE randomizes the message to be signed by transforming (C, g 1 ) into (C S0 , g S0 1 ) with a randomizer S 0 ∈ Z p . Additionally, since M 0 and k 0 must be initialized to 0 by the UE to allow the HN to set the correct values for M and k, the UE proves the correctness of C S0 by computing a ZKP π 0 , which implicitly proves M 0 = 0 and k 0 = 0:
and the proof π 0 to the HN. (Detailed proofs for all ZKPs, π 0 , π 1 , and π 2 are in Appendix A-B.)
2 cred Issuance by HN -Load the initial account balance M , add the secret identity k, and generate a signature σ. Issue((C S0 , g S0 1 ), π 0 , x 0 , x 1 , sk HN ). For a prepaid user, the HN needs to set the allowed usage M based on the user's plan and set the exponent k as the user's MSIN. With knowledge of the secrets x 0 , x 1 , HN can homomorphically add M and embed k without knowing the actual values of the exponents in C S0 . This is accomplished by computing:
For postpaid user, the M is initialized as 0, HN only needs to embed k by using the same method and outputs
, in which M = 0. Given the randomized commitment vector (C S0 0 , g S0 1 ), HN generates a SPS-EQ signature σ ← Sign(sk HN , (C S0 0 , g S0 1 )), then sends σ, (C S0 0 , g S0 1 ) to UE. 3 UE obtains the initial credential cred 0 , and prepares new secret parameters for its successor credential cred 1 . Obtain((C S0 0 , g S0 1 ), σ, 1 S0 , pk HN , x 1 ). The UE first unblinds the received (C S0 0 , g S0 1 ) to (C 0 , g 1 ) using its secret S 0 . It then adapts σ to σ 0 , obtaining an unlinkable message-signature pair by using SPS-EQ's adaptability through the algorithm Adapt((C S0 0 , g S0 1 ), σ, 1 S0 , pk HN ), and outputs ((C 0 , g 1 ), σ 0 ) (the algorithm Adapt(•) can be found in Appendix A-A2). The initial balance credential for a UE is cred 0 : ((C 0 , g 1 ), σ 0 ) It consists of the commitment (C 0 , g 1 ) and the signature σ 0 . A UE can use cred 0 without being linked to C S0 0 , the value originally signed by the HN.
To support double-spending detection, each updated cred must have a unique id and d. Therefore, the UE generates new secret parameters for its successor credential cred 1 to ensure uniqueness. Given the same M and k, the UE generates id ′ , d ′ R ← Z p , and a blinding factor r ′ , forming the commitment: 2), and stores (C S1 1 , g S1 1 ). In C 1 , the balance attribute M and the hidden identity attribute k must match those in C 0 of the current credential cred 0 . Thus UE must also generate a proof to prove their equality, which can be pre-computed offline immediately after a session ends, as the new cred with the updated M is issued at that time. This approach eliminates the overhead introduced to the call session setup phase.
3) Use cred during Session Establishment: UE's Tasks. During network access, a prepaid UE needs to: 1)Prove the cred 0 = ((C 0 , g 1 ), σ 0 ) has not been double-spent.
2)Prove ((C 0 , g 1 ), σ 0 ) is a valid message-signature pair.
3)Prove it has sufficient balance to start a session without revealing the actual balance M to the HN by showing proof that M ≥ th, where th is a constant pre-defined by the HN. 4)Send the pre-computed (C S1 1 , g S1 1 ) to the HN to form the successor credential cred 1 and provide proof that M and k in C S1 1 match the corresponding exponents in cred 0 . HN's Tasks. Accordingly, the HN needs to: 1)Check if cred 0 has been double-spent, 2)Verify the authenticity of the signature σ 0 within cred 0 .
3)Verify a range proof of M . 4)Verify that the M and k embedded in (C S1 1 , g S1 1 ) are consistent with those in cred 0 .
The authenticity of the signature (i.e., task 2) is verified using the Verify algorithm of SPS-EQ. Tasks 3,4 are combined into an AND-composition proof, proven via NIZK:
(3) HN can confirm that the UE has a valid cred 0 with sufficient balance after verifying the tasks 2-4. However, it remains essential to incorporate a method for double-spending detection and to check if cred 0 has already been spent (i.e., the task 1).
Enable Double-spending Detection. When a UE requests to establish a session, the HN first sends a random challenge γ to the UE. The UE then reveals the credential index id within its current cred 0 and proves that id matches the third exponent in C 0 . Recall that the id is a random number secretly chosen by the UE during the credential issuance (i.e., step 2 ), and its plaintext was unknown to the HN during issuance. If a cred is used only once (i.e., the HN has not encountered the same id before), id will appear as a dummy value, preserving UE's unlinkability (further explained in Sec V-A2). However, if a misbehaving UE spends it more than once, the HN can recover its identity k through the following method: During a service request, the UE needs to additionally compute and send c = k • γ + d to the HN, and prove it is well-formed using the k and d within cred 0 . If the HN finds a duplicate id in its database, it retrieves the previous record for the same id, c ′ = k • γ ′ + d. HN can then recover k (i.e., de-anonymize the UE) by solving the following equations involving the same k and d:
To ensure that the UE sends the authentic id and computes c = k • γ + d in accordance with the secret exponents in C 0 , the UE must add an additional statement in the proof π 1 :
This guarantees that a malicious UE cannot frame others by claiming a forged id, as it lacks the other secrets in cred 0 required to prove the id-cred 0 binding. Without a valid proof, any falsified id will be rejected.
Summary -Full Procedure Of Session Establishment. (Outlined in the lower portion of Fig. 7.) Spend(cred 0 , (C S1 1 , g S1 1 )). At the beginning of the session establishment process, the HN sends a random challenge γ to the UE. The UE computes c = kγ + d and the proof π 2 , then sends id, c, cred 0 , and π 2 to the HN.
, π 2 , pk HN ). HN checks its database for a duplicate id. If a duplicate is found, it de-anonymizes the double-spent UE through the aforementioned method. Otherwise, it validates cred 0 (i.e., authenticity of σ 0 ) using pk HN , verifies π 2 , and grants the UE access if all checks pass. At the end of the session, HN homomorphically subtracts the consumed usage m of the current session from the attribute M in C S1 1 by computing:
This results in a commitment randomized by S 1 , which commits to the latest cumulative usage (M -m), the hidden identity k, the two new secret parameters id ′ and d ′ , and the blinding factor r ′ . The HN then generates a new SPS-EQ signature σ 1 ← Sign(sk HN , (C ′S1 1 , g S1 1 )) and sends them to UE. Upon receiving σ 1 and (C ′S1 1 , g S1 1 ), the UE unblinds (C ′S1 1 , g S1 1 ) to (C ′ 1 , g 1 ), adapts σ 1 to σ ′ 1 using the Adapt(•) algorithm of SPS-EQ, and obtains a new unlinkable credential cred 1 : ((C ′ 1 , g 1 ), σ ′ 1 ) for future use (same as the Obtain(•) process in step 3 ).
We omit the detailed process of the postpaid mode as it is simpler and only slightly differs from the prepaid mode (as marked in Fig. 7). The only differences are: (1) UE does not need to prove the range proof M ≥ th in π 2 ; (2) In eq. 6, instead of subtraction, a homomorphic addition operation is used, i.e., compute
A. Security, Anonymity, and Unlinkability
Two factors drive ANONYCALL 's anonymity and unlinkability: the frequency of SIP URI reassignment and the computational indistinguishability of the charging procedure.
The callee discovery functionality inherits anonymity from existing anonymous mobile access schemes [51], [48], [55], [13], [42], such as the security properties of blind signatures or anonymous credentials. Therefore, for the callee discovery phase, we limit our discussion to the unlinkability problem. When an anonymous UE disconnects from the network, its previous IP address becomes invalid. Upon initiating a new registration request, the HN cannot determine if the UE previously owned a particular IP address. By default, SIP URI reassignment typically occurs every 10 to 60 minutes during IMS core registration. To enhance unlinkability, ANONYCALL encourages anonymous UEs to refresh their temporary SIP URIs as frequently as possible, ideally every 10 minutes or less. This frequent reassignment can be enforced through operator policies or by allowing UEs to toggle their network service on and off regularly. However, a curious HN may attempt to call or page a victim UE via its temporary SIP URI multiple times within this 10-minute window, potentially identifying linkages among multiple sessions. We acknowledge that there is always a tradeoff between privacy and registration frequency. Nonetheless, a 10-minute interval is deemed sufficiently granular to maintain the unlinkability of an anonymous UE.
Lemma 1. The cred is unforgeable if the SPS-EQ scheme is EUF-CMA secure within the bilinear group model with Type-III pairings, and the zero-knowledge proof meets the soundness property.
Lemma 2. If the Pedersen Commitment scheme is perfectly hiding, the SPS-EQ scheme is perfectly adaptable, and the ZKP scheme provides zero-knowledge property under ROM, then the charging protocol maintains anonymity and unlinkability for a benign UE across different sessions.
Proofs for Lemmas 1 and 2 are provided in Appendix A-A and A-B, respectively. This section provides an intuitive explanation of these proofs. The charging method offers both unlinkability and anonymity if, for all PPT adversaries A, there exists an efficient simulator Sim such that for all secrets (M, k, id, d, r, id ′ , d ′ , r ′ , S 0 , S 1 ) ∈ M with ϕ(M, k, id, d, r, id ′ , d ′ , r ′ , S 0 , S 1 ) = 1; for all (BG) ← Setup(1 λ ), (x 0 , . . . , x 3 , h 0 , . . . , h 3 , pk HN , sk HN ) ← KeyGen(BG, ℓ); for all Commit(•) such that Issue(•) outputs 1; and for all Spend(•) such that Verify(•) outputs 1. That is to say, an adversarial HN A's view, given the proof, can be simulated by Sim given only ϕ, the valid signing key sk HN , and the secret trapdoors x 0 , . . . , x 3 corresponding to the public verification parameters g 1 , h 0 , . . . , h 3 . If the secrets M embedded within a cred (including its successor cred ′ ) are hidden across different network accesses and appear uniformly randomly distributed, the protocol meets the criteria of unlinkability. These properties can be proved within the same game. The difficulty of de-anonymizing or distinguishing linkage among any two anonymous sessions is reduced to the hardness of DLP and the perfect adaptability of the SPS-EQ scheme. Essentially, the proofs π 0 and π 2 appear random and only reveal the validity of the statements, while an adapted SPS-EQ signature σ ′ cannot link back to its original form σ that HN has seen.
Identity-hiding. The cred enables anonymous and unlinkable charging for a UE by its HN. The same k value in different cred instances is effectively concealed, and any two sets of attributes (M, k) and (M ′ , k ′ ) in successive cred and cred ′ instances are unlinkable. These properties are ensured by the hiding property of the Pedersen commitment, the adaptability of SPS-EQ, and the zero-knowledge property (i.e., witness indistinguishability) of ZKPs under the ROM, through the use of uniformly random values, such as r, S 0 , id, and parameters from the NIZK process (Appendix A-B). Consequently, ANONYCALL ensures that the identity of a benign UE (i.e., k) and the actual balance M remain undisclosed to its HN. Therefore, as long as there is no double-spending, ANONYCALL guarantees that different session establishments, whether made by the same UE, cannot be correlated or identified, rendering it impossible for an HN to trace a particular UE.
Uniqueness of id and Collision Prevention. Since every UE needs to obtain a new cred at the beginning of each month, the HN can reset all the stored id that it has seen from its database by the end of each month. While two users may, in rare cases, choose the same secret id during the cred issuance, the possibility is negligible. For example, a 256bit prime p (id ∈ Z p ) provides 2 256 possible values for id, therefore, the message space would provide more than enough unique possibilities to allow each UE of the same HN to carry a unique id inside each month. We can further quantify this using the birthday paradox: assuming 1 million users, the probability of two users selecting the same secret id is:
. That said, we can incorporate a lightweight safeguard during the initial credential issuance to prevent id collision: the user can additionally provide h id 2 , where id remains secret due to the hardness of the discrete logarithm problem. The HN can maintain a temporary list of all issued h id 2 values for the current issuance period (e.g., per month). If a newly requested value h id 2 matches an existing one, the MNO can prompt the user to retry with a different set of secret parameters. This approach can ensure strong collision resistance without revealing id, S i or any other secrets associated with cred. It also does not introduce linkability, as the hardness of the Computational Diffie-Hellman (CDH) problem guarantees that, even given h 2 , h id 2 and h id•Si
, an adversary cannot infer either id or S i , nor determine whether two components share the same id.
Q1: How to dial a SIP URI instead of a Phone number? In cellular networks, subscribers often do not know their SIP URI by default. The IMS core translates both the caller's and callee's phone numbers into SIP URIs at the start of session establishment. Some providers support direct SIP URI dialing (e.g., Verizon, AT&T). On the UE side, most mobile devices support placing and receiving calls using registered SIP URIs through either native dialers or third-party apps (e.g., Linphone, Zoiper, Bria, Zoom). For instance, our experiments utilized the Linphone app (Fig. 9, Appendix).
Q2: If a caller can obtain the callee's SIP URI out-ofband, why not communicate directly through this channel? Callees may not always have Internet access or the ability to use an app. Phone calls should still be received regardless of Internet connectivity, for which the native voice service is still the de facto choice. On the other hand, the outof-band authentication channel is between the caller and the callee's authentication agent, not between the caller and the callee directly. The channel is also not required to provide the bandwidth requirement as with a voice call.
Q3: Will all MNOs need to make modifications in order to make ANONYCALL work, and what incentives do they have to accept and deploy ANONYCALL? Using a SIP URI is a common method for making phone calls. For anonymous callee discovery, the only change for an MNO is the SIP URI assignment during IMS core registration. Instead of using the semi-permanent SIP URI of the UE directly, the HN assigns a temporary SIP URI based on the UE's current IMS IP address, which becomes invalid when the IP address is no longer in use. This is feasible since a subscriber can have multiple SIP URIs simultaneously in current mobile networks. Thus no modifications are needed for existing call routing protocols, e.g., SIP signaling. For the charging method, because no new entities are created, the MNO only requires algorithm-level changes within the relevant network functions, such as CHF.
Furthermore, ANONYCALL only requires the anonymous UE's HN to deploy the changes for its two functionalities, and it does not require all MNOs to implement its functionalities to make it work. Since in a mobile network, a roaming UE's SIP URI and the IP address for IMS are always managed by its HN, which charges the UE based on observed usage. Therefore, ANONYCALL remains functional even when an anonymous UE roams to a foreign network that does not deploy it. A non-anonymous caller A from a conventional operator can always reach an anonymous callee B, since B's home IMS can resolve the current IMS IP address associated with B from B's temporary SIP URI, inform A's home IMS, and establish the call session through standard inter-IMS procedures.
We do not anticipate that all MNOs will adopt these methods to enhance subscriber privacy. Instead, ANONYCALL can be offered by a dedicated MVNO specializing in private and anonymous services for privacy-conscious mobile users.
To ensure the confidentiality of the temporary SIP URI from the service provider (e.g., an MVNO), a client-side encryption model similar to those used by popular password manager applications on iOS and Android devices can be adopted. In this model, the SIP URI is encrypted locally on the device using a device-resident cryptographic key, and only the resulting ciphertext is synchronized with the cloud agent. When sharing with an authorized caller is required, the device decrypts the SIP URI and re-encrypts it under the caller's public key, ensuring that the cloud agent remains unaware of the plaintext. Alternatively, other common cloud data protection mechanisms such as Attribute-Based Encryption (ABE) or Proxy Re-Encryption (PRE) can be employed to achieve confidentiality and flexible access control of the SIP URI. Q4: Why not just use a Tor-like network for anonymous communication? Anonymous communication methods like MixNets and Tor are designed to route untraceable data packets over the conventional Internet, without centralized service providers managing infrastructure or usage-based billing. In contrast, phone calls rely on cellular IP networks, which provide QoS guarantees and require billing mechanisms.
Q5: What if a malicious HN intercepts the call session? (Potentials to support end-to-end encryption (E2EE)) Due to space limits, we defer this question to the Appendix A-C.
Setup and Environment. (1) MNO. To model the voice call in mobile networks, we deploy a SIP signaling server by using a standard VoLTE/VoNR IMS core (Kamailio [6]), which includes the essential IMS functions such as P-CSCF, S-CSCF, and I-CSCF, and connects to the 5GC based on the standard 5G Wi-Fi open source project Open5GS [7]. The 5GC and IMS core are deployed on a desktop running Ubuntu 20.04, with an Intel Core i7-11700k, 3.6GHZ, 8-core, 64-bit CPU. (2) UE. The applications on the UE side are implemented on a Google Pixel 8a (8 GB RAM, Google Tensor G3, Titan M2 security co-processor). The VoIP application Linphone [9] is used to dial the temporary SIP URI on both an iPhone 13 Pro Max and a Google Pixel 8a. (3) Authentication Agent. The cloud-based authentication agent is deployed on an AWS Linux OS (AWS EC2, t2.micro instance, east US).
The evaluation for this functionality involves two parts: (1) an out-of-band authentication framework, the main building blocks are the authentication agent functions (phone-based and cloud-based). ( 2) the anonymous call establishment process between two phones through a standard IMS system. Authentication Agent. We deployed a prototype Android application to evaluate out-of-band caller authentication in two policy modes. a. Simple Mode: This mode utilizes PKI-based digital certificates and is useful when the caller and callee already know each other or when applying simple policies, such as verifying if the caller is a legitimate phone user rather than a spammer using an automatic dialer. b. Flexible Mode: This mode is based on DPKI and standardized VCs. It supports customized authentication policies and establishes trust between parties with no prior knowledge of each other.
To test the simple mode, we installed a standard X.509 digital certificate provided by the OpenSSL library on the caller's side. This enables the callee to authenticate the caller by verifying its digital certificate, ensuring essential caller authentication functionalities, and securing communications during the temporary SIP URI sharing process. Additionally, we deployed the callee's authentication agent on an AWS server. As shown in Fig. 5, we tested the complete process from the caller sending its request to the agent, bypassing authentication, and obtaining the temporary SIP URI. The entire process takes between 50 and 180 milliseconds, with the certificate utilizing RSA-2048 bit keys for encryption and the SHA256 algorithm for hashing. Since certificate verification is a lightweight process on modern processors (e.g., only a few milliseconds with RSA-2048), the overhead of this authentication process is influenced more by network conditions than by cryptographic computations. To test the flexible mode, we used the DPKI offered by the ION platform [4], which is part of the W3C DID standard-compliant Microsoft Entra project [10]. In addition, we used a demo onboarding platform provided by Entra to acquire the VCs for the digital wallet on UE. The caller can contact the callee's authentication agent and generate a presentation from its VC according to the callee's policy. Our test used the default VC provided by Entra, which is a digital driver's license containing eight attributes. The Fig. 8 of the Appendix shows an example of a UE obtaining the VC from Entra, reaching the callee's authentication agent, and deriving a presentation through VC for authentication. The verification (i.e., presentation) time for all attributes within VC in one shot takes around 650 to 780 milliseconds. The main latency is due to the cryptographic computation of VC and the communication latency between the cloud server and the UE.
Nevertheless, as discussed previously, a caller does not need to authenticate itself to a callee for each phone call. Once a caller has been authenticated, the authentication agent can provide them access rights to the SIP URI for a longer duration, e.g., one year. The caller can retrieve the callee's most recent SIP URI directly from the agent, eliminating the need for costly VC presentation before each call session. The overhead of the above process is then confined to network conditions and excludes cryptographic authentication. For example, our prototype UE takes ∼80 milliseconds to retrieve a SIP URI from the AWS-based agent under Wi-Fi settings.
Call Establishment. On the MNO side, we manually registered two prototype UEs with our IMS core, one anonymous (38.XX.XXX.33@domain.name) and one in standard mode (AnonyCall_UE1@domain.name), and mapped each UE's current SIP URI to an IP address in the subscriber database. After successful out-of-band authentication, the caller (AnonyCall_UE1) can directly dial the anonymous callee's SIP URI without relying on protocol-level modifications, thus introducing no overhead. The two UEs can successfully talk to each other, with the call data packets routed through UDP, as RTP runs over UDP in VoLTE/VoNR. We also captured and examined the SIP messages between them throughout the call session. Two SIP message examples are shown in Fig. 6, where all SIP message bodies contain only the temporary SIP URI, revealing no permanent information about the two anonymous UEs.
For the charging protocol, we assessed the computational overhead of the cryptographic protocols on both the UE and HN (desktop) using the cryptographic libraries Cryptimeleon [18] and mcl [5]. Our experiment employs the bn254 curve to generate the bilinear group, chosen for
TABLE II. TIME CONSUMPTION (IN MILLISECONDS) OF DIFFERENT STAGES IN THE CHARGING PROTOCOL (*AVERAGE OF 100 RUNS) Setup Postpaid Prepaid UE Commit + Obtain 8.01 Spend 26.72 27.35 HN Issue 4.65 Verify 47.88 49.14
its efficiency in computing pairing operations [39]. It operates over a 254-bit field and offers a security level of λ = 128 bits, i.e., the order p of the curve is a 254-bit prime, allowing the message space for the balance attribute M to be up to approximately 2 254 -1. This large message space is sufficient to represent the balance attribute M in fine-grained units, such as the total number of milliseconds in a month, thus enabling precise billing capabilities. In our experiment, M is implemented using Java Bigintegers. The time consumption of each stage (or algorithm) in the charging protocol is listed in Table II. On the HN side, a significant computational expense is incurred during the verification of the SPS-EQ signature within cred 0 , which requires computing four pairing operations. Additionally, the prepaid mode is more costly than the postpaid mode since the HN needs to verify an additional range proof to check if the UE has sufficient balance. Our evaluation implemented the classic range proof [21], but its efficiency can be further optimized using more advanced range proofs, such as Bulletproofs [20].
On the UE side, the computations for the successor credential and the first three statements in π 2 (i.e., π 1 ) under the Fiat-Shamir heuristic NIZK method do not depend on the fresh challenge γ sent from the HN. Therefore, these can be precomputed by UE to expedite the call establishment process. Specifically, at the end of each session, after the HN issues a new cred with the updated balance, the UE can store it and immediately prepare for its successor credential and π 1 . Consequently, these steps will not introduce latency to the call establishment time. The only computation required at the beginning of the session is the simple response including the HN's fresh challenge (c = kγ + d), used for double-spending detection, and the proofs of its correctness (explained in Appendix A-B2). Thus, we can further minimize the introduced latency by having the UE compute π 1 offline.
Summary -The overall introduced latency to the call establishment process by ANONYCALL. The out-of-band callee authentication scheme can be performed once and remain valid for an extended period. Additionally, the latency introduced by the anonymous charging method can be significantly minimized by having the UE pre-compute most computations in advance. Thus, the estimated latency introduced to the call establishment process by ANONYCALL can be well below 200 milliseconds. This estimate includes the time for the caller to retrieve the latest SIP URI from the cloud-based authentication agent (∼ 80 ms) and our measurements on the total time of spending and verifying cred in the pre-paid mode without precomputations (∼ 76 ms).
Anonymous Peer Discovery and Communication. Most existing anonymous peer discovery and communication applications and research that can protect users' identity and communication content privacy lie in building an ad-hoc network that does not rely on a pre-existing infrastructure or any centralized management. Examples include COVID-19 contact tracing, Apple's FindMy network, and various research projects focused on creating ad-hoc privacy-preserving networks over BLE, such as [41], [53], [45]. However, such mechanisms can not be applied to the calling system, as call services must rely on a cellular or non-cellular communications operator to operate the infrastructure and route the data packets between caller and callee. [14] proposed a private session establishment scheme for protecting communication content confidentiality from untrusted MNOs while allowing authorized parties to perform lawful interception on the communication content. However, their method requires the involved callers and callees are not anonymous.
Caller Authentication. The out-of-band caller authentication mechanism for ANONYCALL's anonymous callee discovery shares some similarities with prior methods. For example, AuthLoop [47], Authenticall [46], and the STIR/SHAKEN framework [30] implemented by US carriers provide caller ID authentication to combat caller ID spoofing and robocalls. However, these methods do not protect users' identity privacy from untrusted MNOs. UCBlocker [29] is a whitelist-based call-blocking application that relies on attribute-based credentials to authenticate callers. In contrast, our out-of-band caller authentication serves a different purpose. It aims to provide a secure channel to pass the anonymous callee's SIP URI to a valid caller, enabling the caller to initiate phone calls within the cellular network rather than focusing on call blocking.
Usage-based Charging. Traditional e-cash schemes [24], [25], [15], [23] enable anonymous payments but only support singleuse cases, lacking fine-grained charging and are suitable only for prepaid applications. More flexible systems, such as those in [40], [36], enable cumulative usage through homomorphic commitments and ZKP, but do not support partial spending and require users to explicitly reveal their balance, causing linkability issues. [37], [17] addressed this by incorporating blind signature schemes like CL-signatures [16] and PSsignatures [44], allowing users to hide their exact balance from the verifier. Building on [17], the scheme proposed in [19] eliminates the need for ZKPs during spending by leveraging SPS-EQ adaptability. Additionally, their scheme addresses backward unlinkability, preserving the anonymity of a double-spending user's prior transactions in multi-verifier applications. In contrast, ANONYCALL targets a single-verifier service model that prioritizes time sensitivity and low computational overhead during call setup. It intentionally supports conditional unlinkability, as protecting the anonymity of a double-spending UE's previous sessions is unnecessary.
ANONYCALL is a privacy-preserving call management system that supports native phone calls and user charging while enabling anonymous mobile network access. It is interoperable and compatible with standard cellular networks. Our evaluation shows that it introduces acceptable latency to call setup, paving the way for private and functional mobile communication. grant N00014-24-1-2730, and by the Virginia Commonwealth Cyber Initiative (CCI). demonstrates an IMS-compatible SIP architecture with out-ofband caller authentication and a privacy-preserving charging protocol. All source code, scripts, and documentation are publicly available via Zenodo at: https://zenodo.org/records/ 17851159. This appendix targets general readers. It provides a concise overview of the artifact and its reproducibility, while detailed setup instructions are deferred to the accompanying README.
The artifact supports reproducing the paper's core system functionality, including SIP call establishment with temporary identifiers, out-of-band authentication, and usage-based charging. The README was originally prepared for the Artifact Evaluation (AE) process and references an evaluation-specific deployment. For public use, readers are encouraged to follow the updated instructions to deploy a standard IMS core locally.
• Artifact bundle. The Zenodo archive contains this appendix, the updated README, screenshots, and the complete Anonycall_code/ tree. • IMS core. A Google Cloud Platform (GCP) VM was used during the AE process but may no longer be available. Reproducibility does not depend on this VM. Readers should deploy a standard IMS server locally using opensource components (e.g., Kamailio), as described in the README. • Code layout. The artifact includes components for authentication services, Android clients, charging logic, and orchestration scripts. Each directory contains its own documentation.
2) Hardware Dependencies:
• A commodity workstation with 8-16 GB RAM and sufficient disk space for Android tooling. • One or two SIP-capable endpoints (e.g., smartphones).
Readers should follow the README to (i) deploy a IMS core, (ii) configure SIP clients, and (iii) build and run the Android-based authentication and charging components. These steps mirror the setup used in the paper, except that the IMS core runs locally rather than on an evaluation-specific cloud VM.
• Part I -SIP call reproduction. Establish SIP sessions through the local IMS core and inspect signaling traces. • Part II -Out-of-band authentication and charging.
Execute the provided workflows to demonstrate caller authentication and usage-based charging.
• (C1) Temporary SIP URIs interoperate with a standard IMS core without SIP protocol changes. • (C2) Out-of-band caller authentication supports both PKI and DID/VC policies with sub-second latency. • (C3) The privacy-preserving charging protocol enforces usage-based billing with millisecond-level cryptographic overhead.
All experiments follow the same structure as used during the AE process, with the only difference being that the IMS core is deployed locally.
1) Experiment (E1) -SIP Call Reproduction: Goal: Validate that temporary SIP identifiers function correctly on a standard IMS core.
Execution. Register two SIP clients with the locally deployed IMS server and establish a call session. Inspect SIP traces to confirm correct call setup and teardown.
2) Experiment (E2) -Out-of-Band Authentication: Goal: Demonstrate PKI-based and DID/VC-based authentication workflows.
Execution. Run the Android demos using the local authentication services. Successful runs retrieve the callee's SIP URI and enable call establishment.
3) Experiment (E3) -Charging Protocol: Goal: Reproduce the cryptographic performance results reported in the paper.
Execution. Execute the charging workflows and record timing results for credential issuance and usage. 4) Experiment (E4) -Distributed Authentication (Optional): Goal: Evaluate authentication latency under realistic network conditions.
Execution. Optionally deploy the authentication service on a remote host and repeat Experiment E2.
Performance results may vary due to hardware and network conditions. All core functionality can be reproduced without access to private infrastructure or paid cloud services. The Zenodo archive serves as the long-term reference for the artifact.
For example, the TelephonyManager and SubscriptionManager classes in Android allow developers with proper permissions to access the UE's IMS profile, including the carrier-assigned SIP URI.