Conceptio › Archive › arXiv CS

arXiv CSopen access

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

· arxiv_cs

arXiv CS · Papers · License: Open Access

Open Source ↗Direct PDF ↓

cryptography cybersecurity privacy security

cryptography, security, privacy, cybersecurity

arXiv:2609.07654v1 [cs.CR] 7 Sep 2026

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning Liza Ahmad∗

Quan Shi∗

Joshua Haworth†

University of Sheffield Sheffield, United Kingdom [email protected]

National University of Singapore Singapore, Singapore [email protected]

University of Sheffield Sheffield, United Kingdom [email protected]

Yilu Dong†

Prosanta GopeB

Behzad Abdolmaleki

Pennsylvania State University University Park, PA, United States [email protected]

University of Sheffield Sheffield, United Kingdom [email protected]

Syed Rafiul Hussain Pennsylvania State University University Park, PA, United States [email protected]

Abstract GSMA Remote SIM Provisioning (RSP) enables over-the-air delivery of eSIM profiles, but it exposes long-lived identifiers during profile ordering and download. In particular, stable device identifiers (e.g., EID), profile identifiers, and long-lived certificate material enable mobile operators and profile-delivery infrastructure to link provisioning events to the same eUICC and, when combined with account records, to the same subscriber. This undermines subscriber anonymity and enables cross-session tracking. We present ZK-eSIM, a privacy-preserving redesign that achieves subscriber anonymity and provisioning-session unlinkability while retaining accountable traceability by exception. ZK-eSIM (i) replaces direct disclosure of device identifiers with a zero-knowledge proof of device validity and eligibility; (ii) enforces session unlinkability through short-lived, one-time pseudonymous credentials and per-session identifiers to prevent cross-session tracking; and (iii) provides privacy-preserving accountable traceability through a jointly authorised escrow mechanism, so that no single entity can unilaterally deanonymise a user. We formalise a multi-entity, honest-but-curious threat model and prove subscriber anonymity and the unlinkability of provisioning sessions under standard cryptographic assumptions. We implement a Java Card applet on a test eUICC to evaluate performance on commodity hardware with a modified LPA and SM-DP+ server. Our experiments quantify end-to-end cryptographic overhead relative to conventional RSP, confirming that ZK-eSIM adds only practical ∗ Both authors contributed equally to this research. † Valuable contribution to the implementation of ZK-eSIM

B Corresponding author.

This work is licensed under a Creative Commons Attribution-NonCommercialNoDerivatives 4.0 International License. CCS ’26, The Hague, Netherlands © 2026 Copyright held by the owner/author(s). ACM ISBN 979-8-4007-2871-6/2026/11 https://doi.org/10.1145/3830454.3846617

overhead, closing a critical privacy gap while preserving deployability within existing GSMA roles and interfaces.

CCS Concepts • Security and privacy → Pseudonymity, anonymity and untraceability; Privacy-preserving protocols.

Keywords eSIM, privacy, zero-knowledge proofs (ZKP), unlinkability ACM Reference Format: Liza Ahmad, Quan Shi, Joshua Haworth, Yilu Dong, Prosanta GopeB , Behzad Abdolmaleki, and Syed Rafiul Hussain. 2026. ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning. In Proceedings of the 2026 ACM SIGSAC Conference on Computer and Communications Security (CCS ’26), November 15–19, 2026, The Hague, Netherlands. ACM, New York, NY, USA, 22 pages. https://doi.org/10.1145/3830454.3846617

Introduction

The embedded SIM (eSIM) is rapidly replacing removable SIM cards as the default method for devices to connect to mobile networks. Unlike physical SIMs, which require manual swapping, an eSIM profile is provisioned digitally and stored on the embedded Universal Integrated Circuit Card (eUICC), a secure chip built directly into smartphones, wearables, and IoT devices. In today’s consumer ecosystem, the profile download process follows a standard Remote SIM Provisioning (RSP) workflow defined by the GSM Association (GSMA) [18, 52]. At a high level, the workflow involves the user device, the mobile operator, a server that prepares and stores the eSIM profile (SM-DP+: the Subscription Manager–Data Preparation+), and the GSMA trust infrastructure (Fig. 1). eSIM adoption is now mainstream: GSMA reports that the number of eSIM-capable smartphones in active use increased from 144 million in 2022 to nearly 600 million in 2024 [20], and major vendors are moving toward eSIM-only devices [3]. At this scale, the privacy and security properties of the eSIM provisioning protocol become an urgent concern. In particular, the current provisioning protocol design

CCS ’26, November 15–19, 2026, The Hague, Netherlands

User

User device Certif y device

1. User intent/prof il e request: EI D 3. Downl oad initial isation: EI D in eUICC cert

Operator

2. Prof il e order: EI D, ICCI D

4. Prof il e downl oad GSMA trust inf rastructure

SM-DP+ Ser ver Certif y ser ver

Ahmad et al. - User action: - Protocol interaction: - Certif icate issuance: (authenticated & integrity?protected) - Persistent identif iers reveal ed: - EI D: eUICC Identif ier - ICCI D: prof il e identif ier

Figure 1: Identifier exposures in the GSMA Consumer Remote SIM Provisioning (RSP) workflow.

may enable tracking of the user’s device, location, and data over time, which is at odds with privacy-by-design expectations (e.g., GDPR [33] and GSMA’s RSP architectural principles [18]). Reported cases of user data leaks and resulting regulatory fines show that these concerns are not purely theoretical [34, 42]. To comprehend the source of the risk, it is essential to analyse the identification process of user devices during provisioning. Each eSIM-enabled device is equipped with specific, immutable information, including a permanent device identifier referred to as the EID (eUICC Identifier). This information serves as a basis for the provisioning infrastructure to authenticate the device and facilitate the delivery of new profiles. However, due to the reuse of this identifying information across multiple provisioning sessions, various stakeholders within the infrastructure can consistently recognise the same device during its interactions with the system. As a result, different profile downloads, which may be intended to be independent, can be linked back to the same device and associated with the subscriber’s identity. The root cause is architectural: conventional RSP operation interlinks stable identifiers and exposes them to infrastructure entities (Fig. 1). We identify three critical privacy risks in the conventional RSP protocol: •Identity–EID binding at subscription time. During profile ordering, the operator and SM-DP+ learn the device’s permanent identifier (EID) together with the subscriber’s account data, binding the device to a real person and linking future provisioning events for that EID to the same subscriber [19]. • Linking across multiple downloads. The current eSIM provisioning protocol reuses the same device identifier for each profile request or download, allowing the operator or profile server to link otherwise separate profiles to the same device, even when installed for different purposes. Over time, this enables a combined view of the user’s activity and, in shared backends serving multiple operators, can extend across operators [31]. • Persistent certificate identifiers. Even if the EID is hidden during provisioning, long-lived certificate data exchanged during authentication can act as a persistent fingerprint, allowing infrastructure parties to recognise the device across sessions [1, 19]. The above risks are amplified by contemporary provisioning practices, as profile switching is no longer a corner case. The most visible example is the rapid growth of travel eSIM usage (up by 85% in 2025) [41]. Travellers increasingly create short-lived, dataonly travel profiles rather than relying on carrier roaming, which remains significantly more expensive in many regions, such as China and India [47, 50]. While the plan is temporary, the device’s EID is not: it persists across all installations and profile switches. As a result, reseller platforms and SM-DP+ backends operating shared infrastructures can expose stable mappings between the device EID, the issued profile identifier, and the Integrated Circuit

Card Identifier (ICCID), across otherwise independent provisioning events [31]. GSMA standards and prior analyses [1, 18, 19] focus on delivery security, confidentiality, and the authenticity of profile downloads, rather than on privacy. The key challenge is therefore not secure transport, but privacy by default with accountability by exception. Our privacy goal is anonymity and unlinkability during provisioning: provisioning should not reveal a subscriber’s real-world identity or permanent device identifiers, and distinct provisioning sessions should not be linkable to the same device or subscriber. This gap directly motivates our three research questions: RQ1: Subscriber anonymity. Can a legitimate eUICC obtain a profile without disclosing any device identifiers (e.g., EID) to the SM-DP+ or the Mobile Network Operator (MNO) during provisioning? RQ2: Provisioning-session unlinkability. Can provisioning sessions remain unlinkable to each other, even across different operators and multi-tenant SM-DP+ platforms, and resist certificatechain tracking? RQ3: Accountable traceability. Can we provide accountable traceability alongside the anonymity and unlinkability guarantees of RQ1–RQ2, such that on-demand deanonymisation requires joint authorisation and no single entity can unilaterally compromise privacy? To answer RQ1–RQ3, we present ZK-eSIM, a privacy-preserving redesign of the RSP workflow that preserves the existing GSMA roles and interfaces while removing stable identifier exposure from provisioning transcripts (Fig. 2). Our contributions are: • Anonymous provisioning without persistent device identifiers. We design ZK-eSIM, an end-to-end provisioning workflow that uses fresh, per-session pseudonyms and zero-knowledge proofs of eUICC legitimacy. The MNO and SM-DP+ learn only sessionlocal handles, not persistent identifiers or long-lived identifying certificate-chain attributes (addressing RQ1). • Unlinkability across sessions, operators, and multi-tenant SM-DP+. ZK-eSIM makes protocol-visible credentials and tokens one-time and eliminates certificate-chain fingerprints by using short-lived, session-scoped authentication material. These mechanisms prevent both application-layer and certificate-based linkage across repeated provisioning events, including those handled by the same SM-DP+ (addressing RQ2). • Accountable traceability via joint deanonymisation. We design a trace mechanism in which identity recovery requires joint authorisation by the MNO and a designated Law Enforcement Authority (LEA), providing accountability by exception while routine provisioning remains anonymous and unlinkable (addressing RQ3). • Evidence for RQ1–RQ3: formalisation and implementation. We formalise the above privacy and traceability properties in a multi-entity threat model and prove ZK-eSIM’s anonymity, provisioning-session unlinkability, and joint-traceability guarantees under standard cryptographic assumptions (Sec. 8). We implement and evaluate a prototype on commodity smartphones (including a Java Card applet1 ) and a test eUICC alongside a GSMAcompliant SM-DP+ Server to demonstrate that ZK-eSIM is practical in real mobile environments (Sec. 9, addressing RQ1–RQ3). 1 Implementation overview: https://github.com/NaivEPoi/ZK-eSim

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

1. Per-session pseudonym + Zero-k nowl edge proof of val idity (prof il e request) repl aces EI D*

CCS ’26, November 15–19, 2026, The Hague, Netherlands

MNO

2. Pseudonymous prof il e order repl aces EI D, ICCI D* 3. Downl oad intial isation using short-l ived pseudonym certif icate repl aces EI D in eUICC certif icate* 4. Encr ypted prof il e downl oad bound to eUICC SM-DP+ 0.a. Approved device (eUICC) *Al l identif iers shown in grey were exposed in 0.b. short-l ived pseudonym certif icate conventional RSP but are removed in ZK-eSIM

Figure 2: ZK-eSIM provisioning overview. (0.a) An approved eUICC obtains (0.b) a short-lived pseudonym certificate, (1) authenticates to the MNO with a per-session pseudonym and ZK proof, (2) triggers a pseudonymous SM-DP+ order, (3) initialises profile download with the short-lived certificate, and (4) receives an eUICC-bound encrypted profile, without exposing persistent identifiers. Device A I MNO\ MNO\ UE/LPA MVNO 1 MVNO 2 eUICC Phase 0 (Pre-RSP): Intent / Contract Subscription

SM-DP+ (multi-tenant)

R1: Identity–EID binding at subscription time 1 GetEID 2 identity, billing, EIDA , profileType 3 identity, billing, EIDA , profileType)

Profile Provisioning Sessions R2: Cross-session / cross-operator linkability (SM-DP+ join point)

Session 1, MNO/MVNO 1 (4-16): 4

DownloadOrder(EIDA , profileType=X) Reserve ICCID1

5 6 7

ICCID1 , MatchingID

ConfirmOrder(ICCID1 ,EIDA ,releaseFlag=true)

Map ICCID1 ↔ EIDA

9 Deliver Activation Code (SM-DP+ address, AC Token)

GetEUICCInfo, GetEUICCChallenge 11

InitiateAuthentication(euiccChallenge, euiccInfo1, smdpAddress, ...)

transactionId1 , serverSigned1, serverSignature1, CERT.DPauth.SIG

AuthenticateServer(...) eUICC verifies SM-DP+

R3: Certificate-chain fingerprinting during authentication 14 AuthenticateClient(euiccSigned1, euiccSignature1, CERT.EUICC.SIG (contains EIDA ), CERT.EUM.SIG) 15 Verify eUICC cert chain; persist EIDA ↔ ICCID1 16 Profile download & install (ICCID1 )

Session 2, MNO/MVNO 2 (17-22): 17

DownloadOrder(EIDA , profileType=Y) 18

Reserve ICCID2

19 ICCID2 , MatchingID 20 ConfirmOrder(ICCID2 ,EIDA ,releaseFlag=true) 21

Map ICCID2 ↔ EIDA

22 Activation-code delivery, ES9+ mutual authentication (R3), and profile install proceed identically to steps 9–16; SM-DP+ persists EIDA ↔ ICCID2 .

Figure 3: Privacy Risks in Conventional RSP (§3 R1–R3)

Background and Related Work

GSMA Consumer RSP enables a subscriber device to download and install operator profiles on an eUICC, a tamper-resistant secure element integrated into the device. The eUICC stores one or more operator profiles and protects the long-term keys and subscription

material contained in those profiles. The MNO or mobile virtual network operator (MVNO) authorises profile issuance, while the SM-DP+ prepares, stores, and delivers the protected profile package to the target eUICC, which installs the profile [18, 19]. The RSP trust model is anchored in the GSMA public-key infrastructure: the eUICC presents a certificate chain rooted in the GSMA trust hierarchy, while the SM-DP+ authenticates as an authorised profiledelivery server. During profile download, these certificates enable the SM-DP+ to verify that it is interacting with an eligible eUICC, allow the device/eUICC to authenticate the delivery server, and bind the protected profile package to the intended target [18, 19]. Several identifiers are central to this workflow. The EID identifies the eUICC. The ICCID identifies an individual profile. The Matching ID provided to the device indicates how to retrieve a pending profile. Finally, the eUICC and SM-DP+ certificates support mutual authentication and profile-package protection under the GSMA trust infrastructure. Fig. 3 shows two consumer RSP provisioning sessions for the same device with different operators. The first session corresponds to a profile ordered from MNO/MVNO 1, while the second models a later, independent order from MNO/MVNO 2, for example, when the user purchases a travel eSIM while abroad. We first describe the functional flow; Sec. 3 then analyses the privacy risks from identifier reuse. The device obtains the eUICC identifier 1 and provides it during subscription or profile purchase together with the requested profile type 2 . The operator then requests profile preparation for the target eUICC 4 . The SM-DP+ reserves a profile identifier 5 , returns the corresponding profile handle and matching information 6 , and finalises the order after operator confirmation 7 – 8 . The operator then delivers activation material to the device 9 . Using the activation material, the device first obtains eUICC information and fresh challenge material from the eUICC 10 , then contacts the SM-DP+ to initiate authentication for the download session 11 , and verifies the SM-DP+ authentication response 12 – 13 . The eUICC then authenticates itself to the SM-DP+ using signed session data and its certificate chain 14 . Once the SM-DP+ verifies the eUICC and confirms that the pending profile matches the authorised order 15 , it delivers the protected profile package for installation on the eUICC 16 . The later provisioning session with MNO/MVNO 2 follows the same pattern ( 3 and 17 – 22 ), resulting in the provisioning of a new profile on the same eUICC. In practice, the SM-DP+ may be operated by the MNO itself (e.g., Vodafone Idea [22]) or outsourced to a multi-tenant provider serving multiple operators (e.g., Workz [37]). These deployment choices do not change the provisioning flow in Fig. 3, but they affect which domains observe provisioning state. Existing GSMA specifications [18, 19] focus on correctness, authentication, and secure profile transport, while leaving subscriber anonymity and unlinkability outside the main security goals. A formal analysis by Ahmed et al. [1] confirms this security–privacy split: RSP satisfies delivery guarantees, but does not provide anonymity or unlinkability for subscribers. Accountability-oriented proposals, such as the SIM Profile Transparency Protocol proposed by Ahmed et al. [2], help detect profile misissuance, but still depend on stable identifiers and therefore do not eliminate linkability at the provisioning layer. Moreover, the problem is not confined to provisioning. Rao et al. [40] show that higher-layer functionality built on top of RSP, including device authentication and network access procedures, inherits the same

CCS ’26, November 15–19, 2026, The Hague, Netherlands

identifiers and consequently propagates provisioning-time privacy deficits into the operational lifetime of the subscription. ZK-eSIM composes established cryptographic techniques. Anonymous credentials support unlinkable proofs of eligibility [9, 11], blind signatures enable privacy-preserving credential issuance [12], and pseudonym certificates and identity escrow provide sessionbased authentication and accountable anonymity [8, 10]. However, these frameworks typically address individual authentication tasks rather than privacy across the complete, stateful RSP workflow, and they do not consider integration with the GSMA trust and operational infrastructure. Existing cellular privacy work instead focuses mainly on protecting subscriber identifiers during 5G network authentication [4, 25], rather than profile provisioning. ZK-eSIM’s contribution is therefore the RSP-specific adaptation and end-toend composition of established techniques to provide privacy across the GSMA Consumer RSP workflow.

Privacy Risks in Conventional RSP

Fig. 3 highlights three privacy risks arising from the repeated exposure of stable identifiers throughout the conventional RSP workflow: identity–EID binding at subscription time (R1); cross-session and cross-operator linkability during provisioning (R2); and certificatechain fingerprinting during authentication (R3). We consider a multi-tenant SM-DP+ deployment, where the same SM-DP+ backend serves multiple MNO/MVNO tenants. The main privacy issue is not just that these identifiers exist, but that they can be reused to connect events that a user would reasonably expect to remain separate. • R1: The earliest risk occurs before profile download begins. During subscription, the operator receives an EID together with Know Your Customer (KYC), account, and billing data, allowing it to associate a real-world subscriber with a specific eUICC. In Phase 0, the Local Profile Assistant (LPA) retrieves the EID via GetEID 1 and forwards it during contract subscription with each operator 2 , 3 . MNO/MVNO 1 or MNO/MVNO 2 therefore learns that EIDA belongs to the subscriber purchasing the profile. This binding has standalone privacy implications. Once an EID is associated with an identity, it can be correlated with other operator-side identifiers and records, including IMEI, IMSI/SUPI, billing data, and account metadata. In multi-device settings, the same process can also reveal a subscriber’s device portfolio: for example, if a phone and a smartwatch are provisioned under the same account, their distinct EIDs may become linked to the same user. Such records also create an insider-abuse surface: an adversary with access to operator systems could enumerate the EIDs associated with a target and use this information to facilitate fraudulent profile replacement or SIM-swap-style account takeover [26]. •R2: The primary privacy risk arises when the same long-lived EID is reused across otherwise independent profile downloads. Each download creates a fresh ICCID, but the backend observes the same device identifier: the ICCID identifies the profile being issued, whereas the EID identifies the eUICC itself. In the first provisioning session, MNO/MVNO 1 sends DownloadOrder to the SM-DP+ 4 . The SM-DP+ reserves ICCID1 for that order 5 and returns ICCID1 together with a MatchingID 6 , which later acts as a handle for retrieving the reserved profile. After receiving ConfirmOrder 7 ,

Ahmad et al.

the SM-DP+ can persist the mapping ICCID1 ↔ EIDA 8 . The activation code delivered to the device 9 then tells the LPA which SM-DP+ to contact and which reserved profile to claim. The second session through MNO/MVNO 2 repeats this pattern with EIDA reappearing in 17 – 22 , allowing the SM-DP+ to persist a second mapping ICCID2 ↔ EIDA . The SM-DP+ can therefore infer that both profile downloads correspond to the same eUICC, even though they involve different profiles and different operators. This is already a privacy risk even without knowing the subscriber’s civil identity: the backend can link purchases, destinations, provisioning times, profile types, and operator choices to the same device. In a multitenant SM-DP+ deployment, the risk becomes cross-operator: a single backend may observe provisioning requests from multiple operators and join them using the EID. When combined with R1, the same mechanism becomes subscriber-level tracking by the operator, because the linked device activity can be associated with a real-world user. • R3: A natural mitigation would be to minimise or hide the EID in the profile-ordering flow. However, the authentication phase can reintroduce stable device-linked material. After the device receives the activation code in the first provisioning session, it obtains local eUICC information and a challenge 10 and invokes InitiateAuthentication with the SM-DP+ 11 . The SM-DP+ responds with transaction-specific authentication data and its certificate material 12 , and AuthenticateServer lets the eUICC verify that it is communicating with the legitimate SM-DP+ 13 . The reciprocal step is more privacy-sensitive. In AuthenticateClient, the eUICC proves itself to the SM-DP+ by presenting signed authentication data and its certificate chain 14 . This chain includes CERT.EUICC.SIG, containing stable eUICC identity material associated with EIDA . The SM-DP+ then verifies the chain and can persist the resulting association between the eUICC identity and the issued profile, here EIDA ↔ ICCID1 15 , before the profile is downloaded and installed 16 . In the second provisioning session, the same activation-code delivery, mutual authentication, certificate-chain exposure, and profile installation are compressed into 22 ; the privacy consequence is identical, because the SM-DP+ can again associate the same eUICC identity with ICCID2 . R3 is not redundant: it explains why R2 cannot be removed by application-layer identifier minimisation alone. If the SM-DP+ can still recognise the same eUICC during mutual authentication, then hiding the EID in DownloadOrder does not provide unlinkability. Because R1 may already have tied EIDA to a subscriber’s real identity, the certificate material in R3 can carry user-identifying meaning into every authenticated provisioning session [1, 19]. The severity of the privacy risks depends on who operates the SM-DP+. In a primary deployment, where the home MNO runs the SM-DP+ end-to-end, identifier reuse remains within the operator’s existing administrative boundary; compared with physical SIM issuance, the additional privacy exposure is mainly to insider misuse or data breaches. In a non-primary deployment, by contrast, the SM-DP+ is a third-party or multi-tenant service distinct from the home MNO, creating a new observation point that can correlate provisioning events across operators without user visibility. In our work, we focus on the non-primary deployment model where ZKeSIM is more valuable.

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

This non-primary setting is already common in practice. Motallebighomi et al. [31] conduct a large-scale empirical analysis of travel eSIM products and reseller platforms. They find that “travel eSIM” connectivity is frequently implemented via home-routed roaming, exporting user traffic and associated metadata to thirdcountry infrastructures, and further show that reseller dashboards can expose sensitive provisioning state, including device identifiers and EID-to-ICCID mappings on commercial SM-DP+ backends [31]. Current deployment practices amplify this risk. In practice, SMDP+ platforms are often multi-tenant services serving hundreds of operators; for example, Workz advertises a cloud platform used by over 100 operators worldwide [37]. This consolidation turns the SM-DP+ into a high-leverage observation point: a single backend can observe when the same device provisions profiles from multiple operators and at multiple times, enabling cross-operator linkage, coarse travel-history inference, and user association over time. This is a serious threat if provisioning logs are monetised, subpoenaed, or leaked [31]. The threat surface is especially misaligned with the user’s intent in adopting travel eSIMs. Users increasingly buy travel eSIMs to reduce dependence on home-carrier roaming arrangements and to obtain “local-like” connectivity on demand. Yet the provisioning layer reuses identifiers precisely where users expect ephemerality. The EU “Roam Like at Home” regime does not cover all countries (e.g., Switzerland), pushing subscribers into expensive day passes, and UK roaming passes (£2–£6/day) often exceed the cost of a travel eSIM (e.g., £7.21 for 5GB in Italy) [14, 48]. The market conditions that drive short-lived travel profile adoption also intensify repeated provisioning events, making R2 a practical and recurring privacy problem. Limitations of Strawman Solutions. We consider two alternatives that might appear to address these risks. One could attempt to address these risks at the hardware layer by rotating or randomising the EID itself (e.g., via virtual identifiers). However, the EID is a factory-programmed, device-lifetime identifier embedded in the eUICC; modifying it would require a hardware-rooted redesign that is difficult to deploy at ecosystem scale. A user might attempt to achieve unlinkability by provisioning multiple profiles in advance and rotating among them across sessions. This is infeasible: eUICCs support only a limited number of profiles, and each profile remains bound to the same EID during download, reintroducing linkability. ZK-eSIM therefore keeps the EID and profile-storage model intact and shifts privacy protection entirely to the protocol layer.

System Model, Threat Model, and Design Goals

We first define the system entities, followed by adversarial capabilities, and security and privacy goals of ZK-eSIM. • System Model: ZK-eSIM consists of five principal entities: UE, MNO, SM-DP+, Pseudonym Certificate Authority (PCA), and LEA. It additionally relies on the existing GSMA PKI as external trust infrastructure. Below, we describe the roles and capabilities of each entity. - User Equipment (UE): consists of the LPA and a tamper-resistant eUICC. The LPA mediates profile lifecycle operations, while the eUICC stores profiles and long-term secrets and executes securitysensitive cryptographic operations. We assume the standard GSMA

CCS ’26, November 15–19, 2026, The Hague, Netherlands

hardware protections and model the LPA–eUICC interface as a local authenticated channel preserving command integrity and response authenticity. - Mobile Network Operator (MNO): provides the subscription service, performs eligibility and subscriber-registration checks, and authorises profile orders with the SM-DP+. Our model also covers MVNO deployments, where the MVNO assumes the operator role while using a host MNO’s access infrastructure. End-to-end encryption keeps subscriber data inaccessible to the host MNO. - Subscription Manager–Data Preparation (SM-DP+) : prepares, stores, and delivers operator profiles to authorised eUICCs. It receives profile orders from the MNO and performs authenticated and confidential profile delivery. We consider both dedicated singletenant and shared multi-tenant SM-DP+ platforms. - Pseudonym Certificate Authority (PCA): is a new entity introduced to address R3 (Sec. 3). It issues short-lived, per-session pseudonym certificates to eligible eUICCs. The PCA operates as an independent Sub-CA under a GSMA Certificate Issuer (CI), allowing each pseudonym certificate to chain to a trust anchor already recognised by UEs and SM-DP+ servers. The certificates contain only the metadata required for validation, such as their validity period. - Law Enforcement Authority (LEA): is an external governance entity involved only in de-pseudonymisation under lawful process. It cannot unilaterally deanonymise a subscriber; de-pseudonymisation requires joint cooperation with an MNO under applicable legal policies, reflecting statutory lawful-interception obligations on service providers [23]. For clarity, we model the LEA as a single logical entity. Alternatively, this role may be instantiated by a threshold of independent authorities [13, 45]. - Communication and Setup Assumptions: All inter-entity communications use TLS: device-facing channels are server-authenticated, while the MNO–SM-DP+ channel is mutually authenticated. All entities additionally have read-only access to a public CRS generated either through an auditable multi-party setup with at least one honest contributor or through a trusted setup whose trapdoor is deleted [6, 29]. Deployment Models and Trust Assumptions. ZK-eSIM operates among mutually untrusted parties; each entity follows the protocol correctly but may exploit its view. Additionally, ZK-eSIM relies on noncollusion, a practical assumption driven by strict data protection regulations (e.g., GDPR [33]) across multi-operator architectures. This aligns with existing privacy-preserving cellular systems (e.g., PGPP [43], LOCA [28], PGUS [51], LPG [46]). In non-primary deployments (which we adopt in ZK-eSIM), the MNO and SM-DP+ are operated by different organisations, and the PCA may be operated independently, either by the GSMA or by a GSMA-authorised SubCA [17, 37]. Keeping these records separate reduces data-protection risk and supports GSMA requirements. In primary deployments where an MNO operates its own SM-DP+, we consider them as colluding. Appendix E provides an analysis of the privacy degradation in this case and in all the remaining pairwise and full-collusion cases. • Threat Model: Broadly, we consider two classes of adversaries. - A1 (Network-level adversary): We adopt the standard Dolev-Yao adversary [15], which fully controls the communication channels

CCS ’26, November 15–19, 2026, The Hague, Netherlands

between entities. The adversary can intercept, delay, replay, modify, or inject messages. The cryptographic keys and the GSMA trust anchors are assumed to remain uncompromised. eUICC-resident long-term keys remain hardware-protected; physical extraction and related hardware attacks are out of scope. This adversary captures risks such as: Man-in-the-middle attacks, passive surveillance, replay attacks, and rogue base stations. Certain threats are out of scope, such as denial-of-service attacks and global adversaries that can correlate cross-domain traffic. - A2 (Honest-but-curious infrastructure adversary): We model the MNO, SM-DP+, and PCA as honest-but-curious entities. Each executes its prescribed protocol operations correctly but may analyse its entire legitimate view to deanonymise a subscriber, link multiple provisioning sessions, or derive a stable device identifier. These entities act independently under the non-collusion assumption defined above. We next specify the legitimate view of each entity and the functions for which it is trusted: ◦ MNO: observes the subscriber identity, EID, and billing information obtained through the independent onboarding process, together with the provisioning requests, profile orders, and settlement records that it handles. It is trusted to perform eligibility and subscriber-registration checks, authorise profile orders, execute its prescribed provisioning operations, and participate correctly in authorised de-pseudonymisation. However, because of its honest but curious nature, an MNO may attempt to correlate its onboarding records with provisioning sessions or to link multiple sessions belonging to the same subscriber. ◦ SM-DP+: observes profile orders, session-specific authorisation and authentication material, and its profile-delivery and settlement records. It is trusted to prepare and deliver the correct profile, verify the MNO’s authorisation material, and enforce one-time token use, but not to refrain from attempting to correlate different provisioning sessions. While conforming to protocol behaviour, the SM-DP+ may attempt to track users or misreport transactions (e.g., inflate the number of provisioned profiles). Settlement integrity is enforced through signed, single-use provisioning tokens and cryptographically bound settlement records, preventing both over-billing and under-reporting. ◦ PCA: observes each pseudonym-certificate request, the accompanying eligibility proof, and the short-lived certificate it issues. It is trusted to validate requests, issue certificates only to eligible eUICCs, and protect its signing key, but not to refrain from attempting to link repeated certificate requests. Under the assumptions above, server-authenticated TLS neutralises A1 at the channel level; the privacy violations we study therefore arise under A2 and depend on endpoint-visible stable identifiers that enable linkability. • Design Goals of ZK-eSIM: ZK-eSIM preserves RSP’s delivery security while ensuring that stable device identifiers are not exposed during provisioning, sessions are unlinkable by default, and identity recovery is possible only via jointly authorised tracing. Our design goals (DG1–DG6) are derived from adversarial threats identified in Sec. 4. We categorise them into two groups: baseline security goals (DG1, DG3), which are retained from RSP, and novel privacy and accountability goals (DG2, DG4–DG6).

Ahmad et al.

Table 1: Design Goals: Conventional Consumer RSP vs. ZK-eSIM Design Goal

Conventional RSP

ZK-eSIM

✓ ✗ ✓ ✗ ✗ ✗

✓ ✓ ✓ ✓ ✓ ✓

DG1: Secure Communication DG2: Unlinkable Mutual Authentication DG3: Profile Confidentiality & Integrity DG4: Subscriber Anonymity (at Provisioning) DG5: Provisioning-Session Unlinkability DG6: Privacy-Centric Accountable Traceability (LEA-mediated)

- DG1: Secure Communication. For each communicating pair (e.g., UE and SM-DP+), the protocol ensures confidentiality, integrity, entity authentication, and replay protection against a Dolev–Yao adversary controlling the network. - DG2: Unlinkable Mutual Authentication. Mutual authentication must verify endpoints without revealing persistent device identifiers or enabling linkage across sessions. In ZK-eSIM, the UE proves eligibility in zero knowledge and authenticates using short-lived pseudonym certificates that chain to the GSMA CI. Thus, authentication remains verifiable under the GSMA PKI hierarchy while unlinkable to the subscriber’s long-term identity. - DG3: Profile Confidentiality and Integrity. The eSIM profile must be delivered unmodified and confidentially to the eUICC. ZK-eSIM maintains the guarantee by protecting against honest-but-curious infrastructure through authenticated key exchange, encryption, and end-to-end integrity checks. Each profile package is cryptographically bound to the target via an eUICC-held key, so installation on any other device is invalid. - DG4: Subscriber Anonymity (at provisioning). No party, internal (MNO, SM-DP+) or external (network adversary), should learn a subscriber’s real-world identity or permanent device identifiers during provisioning. ZK-eSIM achieves this by replacing stable identifiers with ephemeral pseudonyms and unlinkable proofs. - DG5: Provisioning-Session Unlinkability. Distinct provisioning sessions must not be linkable to the same subscriber, even when initiated on the same device or across different operators. This prevents tracking and behavioural profiling by MNOs or hosted SM-DP+ platforms. ZK-eSIM enforces unlinkability via Pseudorandom Function (PRF)-generated pseudonyms and ZKPs, across all phases from profile request to installation. - DG6: Accountable Traceability. Strong anonymity and unlinkability must coexist with lawful accountability. ZK-eSIM ensures that deanonymisation requires collaboration between the LEA and an MNO (holding the relevant provisioning record) under legally authorised conditions. No single entity has the unilateral power to deanonymise, ensuring both regulatory compliance and protection against unjustified surveillance. Table 1 illustrates that conventional GSMA Consumer RSP meets DG1 and DG3 but falls short on DG2 and DG4–DG6. This gap motivates our work, ZK-eSIM, which is designed to close these specific shortcomings.

High-level Overview of ZK-eSIM

This section provides a high-level overview of the ZK-eSIM workflow (Fig. 4). ZK-eSIM redesigns the GSMA Consumer RSP flow so that, during provisioning, no non-colluding provisioning party can link a provisioning session to both the subscriber record and the eUICC’s long-term identifier. The core idea is to replace cleartext

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning UE

MNO

PCA

SM-DP+

CCS ’26, November 15–19, 2026, The Hague, Netherlands

LEA

RegisterAndIssue, Sec. 7.2 Unlinkable eligibility credential Phase 0.a: Registration [Start provisioning session] loop [Get another profile? = Yes] Phase 0.b: Certificate initialisation Short-lived pseudonym certificate CertInit, Sec. 7.3 Phase 1: Pseudonymous profile request Privacy-preserving ZK request ZKRequest, Sec. 7.4.1 [ZK proof verified & replay-free = Yes] Phase 2: Order authorisation Order authorised & auth recorded OrderProfile, Sec. 7.4.2 Phases 3,4: Mutual auth & provision Unlinkable mutual auth & download MutualAuthAndProvision, Sec. 7.4.3 Settlement (per epoch) Verify deliveries, co-signed receipt Settle protocol, Sec. 7.5 Deanonymisation (by legal order) Identity recovery Deanonymise protocol, Sec. 7.5

tokens. The SM-DP+ proves that each redeemed token corresponds to a prior authorisation; both parties co-sign a settlement receipt. No persistent identifier appears in settlement. Supporting Procedure - Deanonymisation by Exception: Under a valid legal order, the LEA requests the in-scope escrow ciphertext from the MNO, decrypts it to recover the EID, and returns the result to the MNO for subscriber resolution. Thus, escrow decryption and subscriber resolution are separated, and subscriber deanonymisation requires joint LEA–MNO cooperation. Phase 0.a establishes eligibility once, decoupled from provisioning. For each new profile, Phases 0.b–4 use a fresh certificate, pseudonym, and one-time authorisation bundle. Under the paper’s threat model, this yields provisioning-session unlinkability for the MNO and SM-DP+ views while preserving operational settlement and lawful traceability by exception. Collectively, these phases realise design goals DG1–DG6 (Sec. 4).

Figure 4: High-level phase view of the ZK-eSIM protocol

6 stable identifiers with an unlinkable eligibility credential, a fresh per-session pseudonym certificate, a challenge-derived pseudonym and escrowed EID with a ZKP of correct formation, and one-time authorisation material bound to the session context. Lawful subscriber resolution remains possible, but requires joint LEA–MNO cooperation. The phases of ZK-eSIM are: Phase 0.a - Registration and Eligibility : The user enrols once with the MNO and obtains an unlinkable eligibility credential bound to the same eUICC that will later generate per-session keys. Phase 0.b – Certificate Initialisation: Before each provisioning session, the eUICC derives a fresh ephemeral key pair and obtains from the PCA a short-lived pseudonym certificate binding the corresponding public key to a bounded validity window. Phase 1 – Pseudonymous Profile Request: The UE sends to the MNO a privacy-preserving request containing a fresh challengederived per-session pseudonym, an escrow ciphertext EID, a pseudonym certificate, and a ZKP that the pseudonym, escrow, and previously issued eligibility credential are bound to the same eUICC and are well formed. The MNO verifies the proof, checks challenge freshness, and rejects replays without learning a stable identifier. Phases 2–4 - Order authorisation, mutual authentication, and provisioning : Upon successful verification, the MNO computes a hashed pseudonym and places an order at the SM-DP+ using only that hashed pseudonym. It also returns to the UE an authorisation bundle consisting of an MNO-issued authorisation credential and a single-use token, both bound to the authorised hashed pseudonym and to the hash of the presented pseudonym certificate. The UE then initiates a fresh provisioning session with the SM-DP+. The SM-DP+ verifies that the hashed pseudonym was authorised, recomputes the certificate hash, checks the authorisation credential and the one-time token, and enforces one-time token use. Only after these checks do the parties complete mutual authentication and an authenticated key exchange, after which the SM-DP+ delivers the encrypted profile for installation on the eUICC. If the user requests another profile, the loop repeats from Phase 0.b with fresh session credentials. Supporting Procedure - Settlement: Operational reconciliation runs per epoch between the MNO and the SM-DP+. Each side maintains a log: the MNO over issued tokens, the SM-DP+ over redeemed

Preliminaries for ZK-eSIM

To keep the paper self-contained, we recall the cryptographic primitives used in our construction. Let 𝜆 ∈ N denote the security parameter and 1𝜆 for its unary encoding. For a finite set 𝑆, 𝑥 ←$ 𝑆 denotes a uniform sample from 𝑆. For a (probabilistic) algorithm 𝐴, we write 𝑦 ←A(𝑥; 𝑟 ) for the result of running 𝐴 on input 𝑥 using randomness 𝑟 ; when 𝑟 is omitted, probabilities are taken over all internal randomness. We use {0, 1}∗ for bitstrings, and 𝑎 ← 𝑏 to denote assignment. All algorithms are probabilistic polynomial-time (PPT) unless stated otherwise. A function negl(𝜆) is negligible if for every 𝑘 ∈ N there exists 𝜆0 such that for all 𝜆 ≥ 𝜆0 , negl(𝜆) ≤ 𝜆 −𝑘 . All notation used in the paper and additional background are deferred to Appendix A.

6.1

Non-Interactive Zero-Knowledge

A non-interactive zero-knowledge argument (NIZK) allows a prover 𝑃 to convince a verifier 𝑉 of a statement 𝑥 without leaking anything beyond its validity, using a single message and CRS [7]. We consider an NP-relation 𝑅 ⊆ {0, 1}∗ × {0, 1}∗ where (𝑥, 𝑤) ∈ 𝑅 means witness 𝑤 proves statement 𝑥; the corresponding language is 𝐿𝑅 := { 𝑥 | ∃𝑤 : (𝑥, 𝑤) ∈ 𝑅 }. A NIZK for 𝑅 consists of PPT algorithms (Setup, Prove, Verify) and simulator 𝑆 = (𝑆 1, 𝑆 2 ) with the following interfaces: crs ← Setup(1𝜆 ) outputs a common reference string; 𝜋 ← Prove(crs, 𝑥, 𝑤) generates a proof for statement 𝑥 with witness 𝑤 (output ⊥ if (𝑥, 𝑤) ∉ 𝑅); 𝑏 ← Verify(crs, 𝑥, 𝜋) verifies proof 𝜋 for statement 𝑥, returning 𝑏 ∈ {0, 1}; (crs, td) ← 𝑆 1 (1𝜆 ) generates a simulated CRS (computationally indistinguishable from real setup) with trapdoor td; 𝜋 ← 𝑆 2 (td, 𝑥) generates a simulated proof using the trapdoor. The NIZK satisfies completeness, zeroknowledge, and knowledge soundness.

6.2

ZK-eSIM: Definitions

ZK-eSIM is a primitive that enables a user holding an eligible eUICC to be authorised by the MNO and obtain an eSIM profile from SM-DP+ such that the correctness of authorisation and provisioning is verifiable, while the issuance and use phases remain unlinkable and the user’s identifying information is hidden. We formalise ZK-eSIM as a privacy-preserving provisioning scheme that achieves anonymity at provisioning, multi-session unlinkability,

CCS ’26, November 15–19, 2026, The Hague, Netherlands

0.a. Registration. RegisterAndIssue, Sec. 7.2

0.b. Certif icate initial isation. CertInit, Sec. 7.3

User

User registration

0.b.i. PCert request

1,2,3,4. Unl ink abl e pseudonymous prof il e provisioning. ZKRequest , OrderProf il e, and Mutual AuthAndProvision , Sec. 7.4 User

1. ZK?based pseudonymous prof il e request ZKRequest protocol in Sec. 7.4.1

LPA LPA

4. Privacy-preser ving prof il e provisioning (unl ink abl e, anonymous) eUICC Mutual AuthAndProvision protocol in Sec. 7.4.3 UE

PCA 0.b.ii. Certif y eUICC using PCert

Certif y sub-CA

Deanonymisation (by exception). Deanonymise, Sec. 7.5 Legal order

MNO/MVNO

3. Unl ink abl e downl oad initial isation Mutual AuthAndProvision protocol in Sec. 7.4.3

eUICC MNO

Ahmad et al.

SM-DP+ ser ver

2. Prof il e order using ephemeral pseudo-identity OrderProf il e protocol in Sec. 7.4.2

Certif y ser ver GSMA CI

GSMA trust inf rastructure

MNO

LEA Decr yption of escrowed identif ier

User action Protocol interaction Certif icate issuance Legal order

Figure 5: System architecture and protocol phases of ZK-eSIM.

and accountable traceability. The system is executed by the entities defined in Sec. 4. Let pp denote the public parameters output by Setup in Alg. 1 and shared by all algorithms. Definition 1 (ZK-eSIM). A ZK-eSIM scheme is a tuple of PPT algorithms and protocols Π = Setup, RegisterAndIssue, CertInit, ZKRequest, OrderProfile, MutualAuthAndProvision, Settle, Deanonymise , with pp as implicit input. Correctness requires that, for any honest execution with fresh session randomness, 𝑈 obtains the intended profile, the corresponding one-time token is recorded exactly once, and the MNO and SM-DP+ obtain consistent logs and receipts. • (pp, 𝐿auth , 𝐿spent , 𝑠𝑘𝑏 ) ← Setup(1𝜆 ): the setup algorithm (Alg. 1) outputs pp, initialises empty per-entity logs 𝐿auth, 𝐿spent = ∅ (kept private by their respective owners MNO and SM-DP+), and samples a per-card binding secret 𝑠𝑘𝑏 kept on eUICC and never disclosed. • (𝜎EID, 𝐶 EID, 𝑟𝑏 ) ← RegisterAndIssue(pp; EID, 𝑠𝑘𝑏 ): the one-time registration protocol (Fig. 6, Alg. 2) between 𝑈 and MNO takes (EID, 𝑠𝑘𝑏 ), then returns to 𝑈 an unlinkable eligibility credential 𝜎EID , commitment 𝐶 EID and randomness 𝑟𝑏 . 𝑠𝑘𝑏 , 𝑟𝑏 are local to 𝑈 . • (PCert𝑈 , 𝑠𝑘𝑈 , 𝑟 seed ) ← CertInit(pp; 𝜎EID, EID, 𝑠𝑘𝑏 ): the certificate initialisation protocol (Fig. 7, Alg. 3) between 𝑈 and PCA samples a fresh session key pair (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ), issues to 𝑈 a short-lived pseudonym certificate PCert𝑈 on 𝑝𝑘𝑈 , and returns fresh session randomness 𝑟 seed . The values 𝑠𝑘𝑏 , 𝑠𝑘𝑈 , EID are used only locally. • (𝑥, PCert𝑈 , 𝜋req, nonceMNO ) ← ZKRequest(pp; 𝜎EID, 𝑠𝑘𝑏 , EID, 𝑟 seed, PCert𝑈 ): the request protocol (Fig. 8, Alg. 4) run between 𝑈 and MNO takes (𝜎EID, 𝑠𝑘𝑏 , EID, 𝑟 seed, PCert𝑈 ) as input (where 𝑈 uses 𝑠𝑘𝑏 , 𝑟 seed locally, never transmitted), then outputs the statement 𝑥 = (𝑝𝑘 MNO, 𝑝𝑘 LEA, 𝑝𝑘𝑈 , nonce, pid, EncEid), PCert𝑈 , 𝜋req , and nonceMNO (stored by MNO), attesting correctness in zero knowledge and same-eUICC binding without revealing EID. root ) ← OrderProfile(pp; • (𝑇𝑖 , 𝜎cred, Hpid, 𝜋 inc, rootauth, 𝜎MNO 𝑥, 𝜋 req, PCert𝑈 , nonceMNO, 𝐿auth ): the order-side algorithm (Fig. 8, Alg. 5) run by MNO takes 𝑥 as input, accepts if the certificate chain and the request proof verify and the nonce matches, then appends the hashed pseudonym Hpid to 𝐿auth (which is stored privately by MNO), places a DownloadOrder for Hpid at SM-DP+, and returns to 𝑈 the authorisation credential 𝜎cred , the one-time token 𝑇𝑖 , and the inclusion proof 𝜋inc together with the accumulator root rootauth root . and its MNO signature 𝜎MNO

• status ← MutualAuthAndProvision(pp; PCert𝑈 , 𝑠𝑘𝑈 , root ): the download-side protocol (Fig. Hpid,𝑇𝑖 , 𝜎cred, 𝜋inc, rootauth, 𝜎MNO 9, Alg. 6) between 𝑈 and SM-DP+ takes the MNO-issued artifacts together with (PCert𝑈 , 𝑠𝑘𝑈 ), performs mutual authentication, verifies Hpid ∈ 𝐿auth and the bindings of 𝜎cred and 𝑇𝑖 , enforces short-lived certificate use and no-double-spend by inserting 𝑇𝑖 into 𝐿spent on accept, delivers and installs the profile on the eUICC, and outputs a single acceptance flag 𝑠𝑡𝑎𝑡𝑢𝑠 ∈ {OK, ⊥}. • SR𝜏 ← Settle(pp; 𝜏, 𝐿spent, 𝐿auth, TokSet𝜏 ): the settlement protocol (Alg. 7) for epoch 𝜏 between MNO and SM-DP+ reconciles tokens in TokSet𝜏 against the spent ledger 𝐿spent [𝜏] and the authorisation ledger 𝐿auth [𝜏], computes a tariff-based settlement amount, and outputs a cross-signed settlement receipt SR𝜏 . • (EID′, 𝜋)/⊥ ← Deanonymise(EncEid, warrant, 𝑠𝑘 LEA ): the accountable de-anonymisation protocol (Alg. 8) is executed between LEA (holding 𝑠𝑘 LEA ) and MNO (holding EncEid). Given a valid warrant defining a lawful scope 𝑆, LEA decrypts the escrowed identity and returns (EID′, 𝜋) to MNO, where 𝜋 proves correct decryption. MNO verifies 𝜋 and resolves EID′ to the subscriber’s KYC record, or outputs ⊥ if any policy or verification check fails. ZK-eSIM achieves provisioning-session unlinkability and unforgeability; refer to Sec. 8 for formal security analysis.

ZK-eSIM Construction

We present the end-to-end construction (Fig. 5), using the cryptographic interfaces of Sec. 6.2 and the notation in Appendix A. The remainder of this section consists of: 1. System Setup, 2. Registration, 3. Certificate Initialisation, 4. Unlinkable Pseudonymous Profile Provisioning, and 5. Supporting Procedures. 1. System Setup: Setup(1𝜆 ) initialises the public parameters, cryptographic interfaces and operational anchors in Alg. 1. It also initialises per-entity logs, and seals a per-card binding secret 𝑠𝑘𝑏 inside each eUICC. The MNO creates an append-only authorisation log: 𝐿auth indexed by hashed subscriber pseudonyms Hpid. SM-DP+ initialises 𝐿spent , an append-only record of one-time tokens used during provisioning to prevent reuse. Both logs are commitmentbacked: each owner signs the current log digest, and short inclusion proofs can be verified against the signed root.

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

CCS ’26, November 15–19, 2026, The Hague, Netherlands

MNO/MVNO r

User (LPA + eUICC)

MNO setup: pp, (𝑠𝑘 MNO , 𝑝𝑘 MNO ) User setup: pp, EID, 𝑠𝑘𝑏 1 Eligibility attestation: EID+device

User (LPA + eUICC)

PCA S

User setup: pp, EID, 𝜎EID , 𝑠𝑘𝑏

PCA setup: pp, (𝑠𝑘 PCA , 𝑝𝑘 PCA ) , issuance policy / expiry rules

attestation (over a secure channel)[RSP*]

𝑟 seed ←$ {0, 1} 𝜆 ; (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ) ← 𝑓 ′ (𝑠𝑘𝑏 , 𝑓 (𝑟 seed ) ) 𝑥 = (𝑝𝑘𝑈 , 𝑝𝑘 MNO ); 𝑤 = (𝑠𝑘𝑏 , 𝑟 seed , EID, 𝜎EID ) 3 𝜋 bind ← ZK.Prove(𝑥; 𝑤 ) 4 𝑥, 𝜋 bind 1

Eligibility & KYC/device checks, abort on failure[RSP*] 3 Proceed

4 𝑟𝑏 ←$ {0, 1} 𝜆 ; 5 𝑟 blind ←$ {0, 1} 𝜆 , 6 𝑚 EID ← 𝐻 (EID ∥ 𝑠𝑘𝑏 ), 7 𝐶 EID ← Com.Commit𝑐𝑘 (𝑚 EID ; 𝑟𝑏 ), 8 (req, 𝛼 ) ← BSig.Blind(𝑝𝑘 MNO , 𝑚 EID ; 𝑟 blind ), 9 𝑥 = (EID, 𝐶 EID , req, 𝑝𝑘 MNO ); 𝑤 = (𝑠𝑘𝑏 , 𝑟𝑏 , 𝑟 blind , 𝛼 ), 10 𝜋 ← ZK.Prove( 𝑥; 𝑤 ) 11 𝑥, 𝜋 12 13 14 15 16

If ZK.Verify(𝑥, 𝜋 ) = 0, then abort 𝜎˜ ← BSig.Sign(𝑠𝑘 MNO , req)

5 If ZK.Verify(𝑥, 𝜋 bind ) = 1, then PCert𝑈 ← Sig.Sign𝑠𝑘PCA (𝑝𝑘𝑈 , expiry) 6 PCert𝑈

𝜎˜

𝜎EID ← BSig.Unblind(𝛼, 𝜎˜ ) Assert BSig.Verify(𝑝𝑘 MNO , 𝑚 EID , 𝜎EID ) = 1

Figure 6: RegisterAndIssue Protocol (Alg. 2): User registration with MNO/MVNO over a secure channel to obtain anonymous credential 𝜎EID . [RSP*] denotes steps that follow the RSP flow with modified semantics. Unmarked steps are new. 2. Registration (Phase 0.a): Eligibility and Accountability Setup (UE ↔ MNO) : The purpose of this phase (Fig. 6, Alg. 2) is not to hide the user’s identity from the issuer at registration; rather, it is to issue a blind, device-bound eligibility credential that can later be used pseudonymously. The flow proceeds as follows: over a secure channel, the user presents EID for eligibility/KYC and the MNO authorises continuation. Next, the eUICC samples fresh randomness 𝑟𝑏 and 𝑟 blind , derives a device-bound digest 𝑚 EID from (EID, 𝑠𝑘𝑏 ), computes the commitment 𝐶 EID using 𝑟𝑏 , and constructs a blinded signing request req and (locally) derives the unblinding factor 𝛼 for later use. Here 𝑠𝑘𝑏 is the device-sealed bootstrap secret (unique to and never leaving the secure element), used only to bind issuance to this eUICC via 𝑚 EID . The zero-knowledge step attests that the instance satisfies the relation R issue : the prover knows 𝑠𝑘𝑏 , 𝑟𝑏 , 𝑟 blind (and a corresponding 𝛼) such that (i) 𝑚 EID is correctly derived from EID and 𝑠𝑘𝑏 ; (ii) 𝐶 EID is a valid commitment to that 𝑚 EID under randomness 𝑟𝑏 ; and (iii) req is a well-formed blinded request under 𝑝𝑘 MNO for the same 𝑚 EID , while revealing none of these values. The statement 𝑥 and ZKP 𝜋 are then transmitted; the MNO verifies 𝜋 and, if valid, signs the blinded request and returns ˜ Unblinding with 𝛼 yields 𝜎EID (a blind-signed, device-bound 𝜎. token that can be instantiated as an anonymous credential [27] (e.g., BBS+)), which the eUICC verifies under 𝑝𝑘 MNO , completing issuance of (𝜎EID, 𝐶 EID ). 3. Certificate Initialisation (Phase 0.b): Pseudonymous Key Binding (UE ↔ PCA) : This phase (Fig. 7, Alg. 3) converts the eligibility credential into a fresh, certified pseudonymous certificate. The eUICC derives a fresh, hardware-bound public key and proves to the PCA, in zero knowledge, that this key belongs to the same eligibility-checked device. To preserve multi-session unlinkability, this phase is executed freshly for each provisioning session. The eUICC generates a seed 𝑟 seed , derives an ephemeral keypair (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ) from 𝑠𝑘𝑏 and 𝑟 seed , and produces a ZKP 𝜋bind for the relation R bind : the prover knows 𝑠𝑘𝑏 , 𝑟 seed, EID, 𝜎EID such that (i) 𝑝𝑘𝑈 is correctly derived within the same eUICC anchored by 𝑠𝑘𝑏 , (ii) a hash-based binding 𝑚 EID is consistent with (EID, 𝑠𝑘𝑏 ), and (iii) the eligibility credential 𝜎EID verifies under 𝑝𝑘 MNO , all without disclosing these values. The user then transmits 𝑥 and 𝜋 bind to the PCA; upon successful verification, the PCA issues and returns a time-bounded certificate PCert𝑈 over 𝑝𝑘𝑈 .

Figure 7: CertInit Protocol (Alg. 3): Pseudonym Certificate Initialisation.

4. Unlinkable Pseudonymous Profile Provisioning (Phases 1,2,3,4) : This section composes Phases 1–4 into an unlinkable provisioning workflow. Our goals are to: (i) prove eligibility in zero knowledge; (ii) let the operator place an order without disclosing the long-lived EID at order time; (iii) bind download authorisation to a fresh session and a one-time release token; and (iv) deliver and install the profile without introducing new cross-session linkers. We follow the GSMA Activation Code control flow with modified semantics: the operator-generated Matching ID / activation token is instantiated with the per-session pseudonym Hpid. This preserves the control-flow shape while replacing the long-lived device identifier with a fresh, session-scoped value. - Phase 1: ZK-based pseudonymous profile request (U ↔ MNO): This phase (Fig. 8, Alg. 4) turns an eligibility-certified, hardware-rooted device into a pseudonymous requester over server-authenticated TLS. The MNO samples a fresh challenge nonce and sends it, and stores it as nonceMNO . Inside the eUICC, the device derives a per-session pseudonym pid from 𝑠𝑘𝑏 and nonce, and in parallel creates an escrow ciphertext EncEid of the same EID using LEA 𝑝𝑘 LEA and fresh randomness 𝑟 . It then forms the statement 𝑥 and witness 𝑤 and produces a ZKP 𝜋 req for the relation R req , asserting knowledge of (EID, 𝑠𝑘𝑏 , 𝑟 seed, 𝜎EID, 𝑟 ) such that: (i) the certified key 𝑝𝑘𝑈 corresponds to the same eUICC; (ii) EID is bound to 𝑠𝑘𝑏 ; (iii) the eligibility credential 𝜎EID verifies under 𝑝𝑘 MNO ; (iv) pid is correctly derived from (𝑠𝑘𝑏 , nonce) and EID; and (v) EncEid encrypts that same EID under 𝑝𝑘 LEA , without revealing any of these values. The user sends (𝑥, PCert𝑈 , 𝜋req ) and submits it to the MNO over TLS. Here 𝑠𝑘𝑏 is the device-sealed bootstrap secret, never exported from the secure element. The MNO learns only a pseudonym and a verifiable proof of hardware continuity and eligibility: unlinkability across sessions follows from the fresh nonce, while accountability is preserved via the stored mapping Hpid/EncEid and escrow to 𝑝𝑘 LEA ; thus an eligible device can authenticate pseudonymously yet remain trace-ready. To keep the core protocol minimal, we treat profile selection and payment as a separate step carried over the same authenticated channel. Concretely, the client sends a context-bound, non-replayable, anonymous proof of payment attesting that the correct tariff was paid to the MNO while revealing nothing about the payer’s identity. A mature body of literature provides suitable instantiations of this primitive [5, 12, 32]. Upon verifying the proof of payment, the MNO treats the user’s request as an authorised order and proceeds with provisioning. This assumption is orthogonal to the ZK request proof and preserves privacy and accountability.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

- Phase 2: Pseudonymous profile order (UE ↔ MNO ↔ SM-DP+) In this phase (Fig. 8, Alg. 5), the MNO receives (𝑥, PCert𝑈 , 𝜋req ) from the user over server-authenticated TLS. It first binds the request to its own challenge and recovers the certified user key by checking nonce = nonceMNO , verifying the chain and expiry of PCert𝑈 under 𝑝𝑘 PCA , and parsing 𝑝𝑘𝑈 ; it aborts on failure. The MNO then verifies 𝜋req against 𝑥 using the 𝑝𝑘𝑈 recovered from PCert𝑈 , thereby attesting same-eUICC linkage, eligibility under the MNO’s policy, pseudonym correctness, and escrow well-formedness; invalid proofs are rejected. Next, it computes the hashed pseudonym Hpid and the certificate hash ℎ cert , aborts if Hpid ∈ 𝐿auth , and stores the mapping (Hpid ↦→ EncEid). The MNO then places a DownloadOrder with the SM-DP+ over an authenticated backend channel. The SM-DP+ reserves a fresh 𝐼𝐶𝐶𝐼𝐷 and returns it to the MNO, after which the MNO finalises the order with ConfirmOrder. The SM-DP+ then records the internal binding 𝐼𝐶𝐶𝐼𝐷 ↔ Hpid. After confirmation, the MNO commits the authorisation decision by updating the accumulator 𝐿auth , producing the inclusion proof 𝜋inc , root . It also iscomputing the digest rootauth , and signing it as 𝜎MNO sues credentials bound to (Hpid, ℎ cert, mnoId), namely 𝜎cred , and derives a one-time token 𝑇𝑖 with expiry. These values, together root ), are then returned to the user in with (Hpid, 𝜋inc, rootauth, 𝜎MNO the final response. ZKRequest and OrderProfile thus convert a ZKauthenticated, pseudonymous request into a minimally identifying yet enforceable authorisation: replay is prevented by checking Hpid ∉ 𝐿auth , the authorisation state is committed via the accumulator root and MNO signature, and subsequent steps can proceed using 𝑇𝑖 and 𝜎cred without revealing EID, while accountability and trace-readiness remain intact through the established escrow. - Phases 3 and 4: Unlinkable Download Initialisation and PrivacyPreserving Profile Provisioning (LPA/UE/eUICC ↔ SM-DP+) In these phases (Fig. 9, Alg. 6), Phase 3 covers server authentication, eligibility validation, and download preparation, while Phase 4 begins with the eUICC’s verification of the profile-signer material and continues with the authenticated key establishment and protected profile loading. The LPA first invokes GetEUICCChallenge, causing the eUICC to sample a fresh nonce 𝑁𝑈 and return it. The LPA then verifies certtls and establishes a server-authenticated TLS channel to the SM-DP+, before sending InitiateAuthentication. The SM-DP+ samples a fresh transcript identifier 𝐼𝑡 and server nonce 𝑁𝑆 , and returns Certauth together with a signature under 𝑠𝑘 auth . After the LPA verifies Certauth , it relays the server-authentication material to the eUICC through AuthenticateServer, thereby binding the session to the fresh challenge pair (𝑁𝑈 , 𝑁𝑆 ) and transcript 𝐼𝑡 . The eUICC then sends an eligibility message = (PCert𝑈 , 𝜎cred,𝑇𝑖 , Hpid, 𝜋 inc, rootauth root , Sig.sign , 𝜎MNO 𝑠𝑘𝑈 (𝐼𝑡 , 𝑁𝑆 , 𝑁𝑈 ,𝑇𝑖 , Hpid, PCert𝑈 , smdpAddress)) via the LPA, which relays it to the SM-DP+ using AuthenticateClient. The SM-DP+ verifies this eligibility message and atomically appends 𝑇𝑖 to the append-only set 𝐿spent , rejecting reuse. It next returns (Sig.sign𝑠𝑘pb (𝐼𝑡 ), 𝐶𝑒𝑟𝑡 pb ) through the LPA. At the start of Phase 4, the eUICC verifies 𝐶𝑒𝑟𝑡 pb and the signature on 𝐼𝑡 , thereby authenticating the profile-signing credential for the current transcript, and generates an ephemeral key pair (𝑥𝑈 , 𝑋𝑈 ). It then signs (𝐼𝑡 , 𝑋𝑈 ) under 𝑠𝑘𝑈 and returns this authenticated key-share contribution through PrepareDownload and GetBoundProfilePackage. The SMDP+ verifies the signature under 𝑝𝑘𝑈 , generates its own ephemeral

Ahmad et al.

User (LPA + eUICC)

MNO/MVNO r

User setup: pp, EID, 𝜎EID , 𝑠𝑘𝑏 , PCert𝑈 , 𝑟 seed

MNO setup: pp, 𝐿auth ,

SM-DP+ á SM-DP+ setup: pp

(𝑠𝑘 MNO , 𝑝𝑘 MNO )

Phase 1: User submits a zero-knowledge profile request server-authenticated TLS channel 1 nonce ← {0, 1} 𝜆

2 Store nonceMNO ← nonce 𝐾pid ← KDF(𝑠𝑘𝑏 , nonce);pid ← PRF𝐾pid (EID)

sample 𝑟 ←$ {0, 1} 𝜆 ;EncEid ← Enc𝑝𝑘LEA (EID; 𝑟 ) 𝑥 = (𝑝𝑘 MNO , 𝑝𝑘 LEA , 𝑝𝑘𝑈 , nonce, pid, EncEid); 𝑤 = (EID, 𝑠𝑘𝑏 , 𝑟 seed , 𝜎EID , 𝑟 ), 6 𝜋req ← ZK.Prove(𝑥; 𝑤 ) 7 𝑥, PCert𝑈 , 𝜋 req 4 5

Phase 2: Pseudonymous profile order 8 Check nonce = nonceMNO ; verify PCert𝑈 chain/expiry under 𝑝𝑘 PCA ; parse 𝑝𝑘𝑈 , abort on failure. 9 Perform ZK.Verify(𝑥, 𝜋req )with 𝑝𝑘𝑈 from PCert𝑈 , abort on failure. 10 Hpid ← 𝐻 ′ (pid); ℎ cert ← 𝐻 ′′ (PCert𝑈 ), 11 If Hpid ∈ 𝐿auth , abort. 12 Store mapping Hpid − EncEid 13 DownloadOrder(Hpid, mnoId, profileType)[RSP*] Reserve ICCID[RSP*] ICCID[RSP*]

14 15

16 ConfirmOrder(ICCID, Hpid, releaseFlag=true)[RSP*] 17

Map ICCID↔Hpid[RSP*]

𝐿auth ← Acc.add(𝐿auth , Hpid); 𝜋inc ← Acc.prove(𝐿auth , Hpid); rootauth ← Acc.digest(𝐿auth ); root 𝜎MNO ← Sig.sign𝑠𝑘MNO (rootauth ); 19 𝜎cred ← Sig.sign𝑠𝑘MNO (Hpid, ℎ cert , mnoId); 20 𝑇𝑖 ← Sig.sign𝑠𝑘MNO (Hpid, ℎ cert , mnoId, expiry). 18

21 𝑇𝑖 , 𝜎cred , Hpid, 𝜋 inc root , rootauth , 𝜎MNO

Figure 8: ZKRequest (Alg. 4) and OrderProfile (Alg. 5) Protocols: Profile Download Initiation. [RSP*] denotes steps that follow the RSP flow with modified semantics. Unmarked steps are new.

pair (𝑥𝑆 , 𝑋𝑆 ), computes 𝐾US , and derives (𝑘, 𝑘 ′ ). Finally, the SMDP+ sends the BoundProfilePackage=(𝐶, 𝑡𝑃 , mnoId, 𝑡 mno, iccid, 𝑡 iccid, 𝑋𝑆 , Sig.sign𝑠𝑘pb (𝐼𝑡 , 𝑋𝑆 , 𝑋𝑈 , smdpAddress)) via the LPA. Using 𝑋𝑆 carried in that package, the eUICC recomputes 𝐾US , derives the same (𝑘, 𝑘 ′ ), verifies the package, and decrypts and installs the profile. Together, these phases convert the Phase 2 pseudonymous authorisation into a one-time, session-bound profile download: the server is authenticated, client eligibility is validated and spent exactly once, the download keys are established with authenticated eUICC participation, and the resulting profile is delivered under confidentiality and integrity protection. Post-Provisioning: ZK-eSIM’s privacy claim is intentionally scoped to provisioning. Once a profile is installed, ordinary userinitiated lifecycle operations such as enable,disable, and delete remain unchanged and are executed locally between the LPA and the eUICC [19]. These operations use profile-local state (e.g., ICCID ) and therefore do not re-expose the device-global EID to the SMDP+ or require reconstruction of an EID–ICCID mapping. Backendtriggered post-installation management can likewise avoid re-exposing EID. The backend need only address the installed profile via an associated profile-scoped alias recorded at provisioning. Delivery can then proceed by device pull, in which the LPA periodically retrieves

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

SM-DP+ (S) á

LPA

eUICC >

SM-DP+ setup: 𝐿spent ,

LPA/User setup: pp

eUICC setup: PCert𝑈 , Hpid, 𝑇𝑖 , 𝜎cred , 𝜋 inc , root , 𝑟 rootauth , 𝜎MNO seed , 𝑠𝑘𝑏 ,

pp Phase 3: Unlinkable Download Initialisation 1 GetEUICCChallenge[RSP] LPA verifies certtls 2 𝑁𝑈 ←$ {0, 1} 𝜆 [RSP] and establishes server3 𝑁𝑈 [RSP] authenticated TLS channel 4 5

InitiateAuthentication(𝑁𝑈 , smdpAddress, ...)[RSP*]

𝐼𝑡 , 𝑁𝑆 ←$ {0, 1} 𝜆 [RSP] 6 Certauth , Sig.Sign𝑠𝑘 auth (𝐼𝑡 , 𝑁𝑆 , 𝑁𝑈 , smdpAddress)[RSP] 7

Verify Certauth [RSP] 8 AuthenticateServer(...) [RSP] 9 Eligibility Message[RSP*]

AuthenticateClient (Eligibility Message)[RSP*] 10

11 Verify Eligibility Message [RSP*]; append 𝑇𝑖 to 𝐿spent 12 Sig.Sign𝑠𝑘 (𝐼𝑡 ), PCertpb [RSP] pb

PrepareDownload (Sig.Sign𝑠𝑘pb (𝐼𝑡 ), PCertpb )[RSP]

Phase 4: Privacy-Preserving Profile Provisioning 14 Verify PCertpb ; verify Sig.Verify𝑝𝑘pb (𝐼𝑡 ) = 1; (𝑥𝑈 , 𝑋𝑈 ) ← KA.gen( ) [RSP] 16 GetBoundProfilePackage 15 PrepareDownload (Sig.Sign𝑠𝑘𝑈 (𝐼𝑡 , 𝑋𝑈 ))[RSP] (Sig.Sign𝑠𝑘𝑈 (𝐼𝑡 , 𝑋𝑈 ))[RSP] Sig.Verify𝑝𝑘𝑈 (𝐼𝑡 , 𝑋𝑈 ) = 1; (𝑥𝑆 , 𝑋𝑆 )← KA.gen(); 𝐾US ← KA.agree(𝑥𝑆 , 𝑋𝑈 ); (𝑘, 𝑘 ′ ) ← KDF(𝐾US , ...) [RSP] 18 Bound Profile Package 17

LoadBoundProfilePackage (Bound Profile Package) [RSP]

[RSP]

𝐾US ← KA.agree(𝑥𝑈 , 𝑋𝑆 ); derive (𝑘, 𝑘 ′ ); verify package; decrypt and install profile[RSP] 20

Figure 9: MutualAuthAndProvision Protocol (Alg. 6): Mutual Authentication and Profile Download. [RSP] denotes unmodified GSMA Consumer RSP steps; [RSP*] denotes steps that follow the same RSP flow with modified semantics. Unmarked steps are new. pending notifications indexed by that profile handle. ZK-eSIM operates at the provisioning layer: it privately installs the eSIM profile and credentials before 5G-AKA begins, after which the UE runs the standard 5G-AKA procedure unchanged, with no additional identifiers, messages, or modifications to 3GPP core functions. 5. Supporting Procedures: Settlement and Accountable Deanonymisation We defer full pseudocode to App. B (Algos. 7 and 8) and describe the two operational procedures that complete the design: settlement by one-time tokens and accountable deanonymisation. For settlement, the MNO issues each authorised profile order with a single-use token bound to the corresponding profile identifier and authenticated by the MNO. When the SMDP+ provisions the profile, it records the token as redeemed. At the end of each epoch, both parties commit to their respective views: the SM-DP+ commits to the set of redeemed tokens, while the MNO commits to the set of authorised profile identifiers. The SM-DP+ returns the redeemed-token set together with evidence that each token was included in its committed view. The MNO accepts a redeemed token only if it is validly authenticated by the MNO, appears in the SM-DP+’s committed redemption log, and corresponds to a profile identifier that the MNO had authorised for that epoch. The final settlement count therefore includes only

CCS ’26, November 15–19, 2026, The Hague, Netherlands

tokens that are both redeemed and authorised. The parties then cross-sign a settlement receipt binding the epoch, the accepted count, the payable amount, and the two committed views, yielding an auditable record without revealing any additional subscriber information. For accountable deanonymisation, the eUICC encrypts its EID to the LEA’s public key during the request protocol, and the resulting escrow ciphertext is stored by the MNO. Under a valid and lawfully scoped warrant, the LEA obtains the in-scope escrow from the MNO and decrypts it to recover the EID for the specific provisioning session. The MNO can then resolve that EID to the corresponding KYC record for the lawful process. This preserves compatibility with mandatory subscriber registration: the MNO learns the subscriber’s identity during Phase 0.a (KYC), which lies outside provisioning-layer anonymity. ZK-eSIM removes only protocol-level cross-session linkability, while requiring LEA cooperation under a scoped legal order to deanonymise a specific provisioning session.

Security Analysis

We show that ZK-eSIM satisfies two main security properties: provisioning-session unlinkability and unforgeability. Unlinkability means that infrastructure entities cannot distinguish whether two accepted provisioning sessions originate from the same eligible eUICC or from two different eligible eUICCs. Unforgeability means that an adversary cannot obtain accepted order-side or download-side provisioning state without legitimate credentials, fresh challenges, and MNO-issued authorisation material. Formal game-based definitions are given in Appendix C, and the proofs are given in Appendix D. Theorem 1 (Unlinkability). If the NIZK system satisfies zeroknowledge, commitments are hiding, KDF and PRF are secure, 𝐻 ′ and 𝐻 ′′ are modelled as random oracles, encryption provides IND-CPA security, and pseudonym certificates satisfy ephemeral indistinguishability, then ZK-eSIM achieves provisioning-session unlinkability for E ∈ {MNO, SMDP+, PCA}. For every PPT adversary A: AdvUNLINK-E (𝜆) ≤ AdvZK + AdvKDF + AdvPRF + AdvCert Π,A

2𝑞𝐻 , 2𝜆 where 𝑞𝐻 is the total number of random-oracle queries to 𝐻 ′ and 𝐻 ′′ . +AdvIND-CPA +

Theorem 2 (MNO-Side Unforgeability). Under NIZK knowledge soundness, anonymous credential unforgeability, collision resistance of 𝐻 and 𝐻 ′ , and freshness of MNO challenges, ZK-eSIM satisfies MNO-side unforgeability. For every PPT adversary A: 𝑞𝑁 CR CR AdvUF-MNO (𝜆) ≤ AdvSound-ZK + AdvUF-Cred + Adv𝐻 + Adv𝐻 , ′ + Π,A 2𝜆 where 𝑞 𝑁 denotes the number of MNO challenge queries. Theorem 3 (SM-DP+-Side Unforgeability). Under EUF-CMA security of the MNO-issued authorisation credential 𝜎cred and onetime token 𝑇𝑖 , collision resistance of 𝐻 ′ and 𝐻 ′′ , and correctness of the stateful spent-token check, ZK-eSIM satisfies SM-DP+-side unforgeability. For every PPT adversary A: +

AdvUF-SMDP (𝜆) ≤ Adv𝜎EUF-CMA + Adv𝑇EUF-CMA + Π,A 𝑖 cred

CCS ’26, November 15–19, 2026, The Hague, Netherlands

SM-DP+ Server

EUICC w/ LPA App

MNO/PCA Server

Test EUICC

EUICC w/ Card Reader

Figure 10: ZK-eSIM Implementation and Evaluation Testbed CR CR DS Adv𝐻 . ′ + Adv𝐻 ′′ + Adv Here AdvDS denotes the probability that the stateful spent-token mechanism accepts a token already recorded in 𝐿spent .

Implementation and Evaluation

We evaluate ZK-eSIM in two ways: first, by quantifying runtime costs relative to the commercial RSP; second, by conducting a deployment feasibility test on an open-source GSMA-compliant testbed. We provide a deployment feasibility evaluation demonstrating that our scheme can be deployed with minimal adjustments to current standards. To facilitate evaluation, we implement a custom Java Card applet packaged inside an eSIM profile that runs the cryptographic operations on a test eUICC (sysmoEUICC1-C2T [49]). Additionally, we modify a GSMA-compliant open-source SMDP+ server (osmo-smdpp [36]) and Local Profile Assistant (lpac [16]).

9.1

Testbed Setup and GSMA Integration

To evaluate the performance of the proposed ZK-eSIM protocol against the commercial RSP, we establish an experimental testbed illustrated in Fig. 10. To preserve compatibility with current RSP architectures, we extend GSMA-compliant network entities, i.e., the SM-DP+, and the LPA as discussed in §9.2. Cryptographic operations are performed with widely used libraries on each network entity, with the JCMathLib [30] as a mathematical library in the Java Card applet. On the eUICC, all operations are performed using the JavaCard and JavaCardX Security libraries [35] (with JCMathLib where applicable), and cryptographic operations on the SM-DP+ and MNO servers are performed using Python’s cryptographic hazmat library [39]. Server-side operations have been performed on a PC running Ubuntu 22.04, with the following specifications: RYZEN 7 8-core CPU, and 64GB RAM. To complete the ZK-eSIM implementation, we deploy an additional PCA server. In a real-world deployment, the PCA would operate as a sub-CA within the existing GSMA PKI and could be operated by a provider such as Cybertrust, DigiCert, or SEALSQ [21]. In our prototype, we instantiate this role using a dedicated server responsible for certificate issuance and authorisation. The primary role of the PCA in ZK-eSIM is to generate pseudonym certificates for users that can provide a valid proof of eligibility. The provided pseudonym certificate is valid only for a single session of the ZKeSIM protocol and expires upon completion of profile initialisation.

9.2

Implementation and Deployability

Implementing ZK-eSIM requires extending existing open-source implementations by updating the ASN.1 encodings to add six request messages and their corresponding response messages, introducing

Ahmad et al.

four supporting type definitions comprising 17 fields, and extending EuiccSigned1 to carry an eligibility bundle. The changes to the ASN.1 encodings have minimal impact on the GSMA message flow between network entities (SM-DP+, LPA, MNO, and eUICC). We add ZK-eSIM as an alternative message flow within the network entities, following the same messages with the modifications specified in §7. ASN.1 Modifications. We extend the standard GSMA RSP protocol by modifying the ASN.1 level definitions to include a new optional message type (EligibilityData) within the EuiccSigned1. The EligibilityData definition contains: the hashed pseudonym ID (Hpid), the MNO signed credential (𝜎cred ), the one-time authorisation token (𝑇𝑖 ), the accumulator root (rootauth ), the signature over the accumulator root (𝜎root ), and the serialised proof of accumulator inclusion MNO (𝜋inc ). This enables Phase 2 of ZK-eSIM (pseudonymous profile ordering) with minimal modifications to existing protocol messages. Additionally, due to the lack of a standardised defined communication interface between the eUICC and MNO/PCA servers, we introduce 6 new Request and Response message pairs to facilitate our privacy-preserving zero-knowledge proofs and certificate initialisations. Modifications to the open-source network entities required adding ∼628 LoC (Lines of Code) at the SM-DP+ to enable the alternative workflow using our proposed scheme for encoding and decoding ZK-eSIM messages, allowing ZK-eSIM to be built on top of the existing infrastructure and providing a secondary approach to RSP. Furthermore, ∼6.7K LoC are used for the implementation of our custom Java Card Applet (including the JCMathLib and cryptographic functions); however, it should be noted that commercial eSIM profiles may already contain functional applets, which can reduce the number of LoC in a real-world deployment. Backward Compatibility. To enable backward compatibility, we develop ZK-eSIM as an alternative privacy-enhanced RSP protocol, which can be implemented alongside current deployments. SM-DP+ providers and MNOs can offer ZK-eSIM as an optional workflow that provides improved privacy over the commercial methods for those who wish to remain anonymous during eSIM profile provisioning, while leaving the commercial offering for users less concerned with privacy. This is enabled by the fact that all encodingbased changes are introduced as optional values within the existing ASN.1 format and require only minimal modifications to existing functions to enable the correct processing of new information elements. The main point at which ZK-eSIM deviates from existing deployments is the pseudonym certificate, which requires changes at the PCA (or may require a separate service offering) to allow the ZK-eSIM deployment.

9.3

End-to-End Cost Comparison

End-to-End Cost. Table 2 presents the mean and standard deviation (denoted by ±) for the execution time of each phase in both the commercial and the proposed ZK-eSIM schemes. The reported values capture the full end-to-end computational and communication costs of cryptographic operations and message flows for each protocol phase. All operations are executed on their respective devices in the experimental setup. ECDSA and SHA256 have been used during

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

CCS ’26, November 15–19, 2026, The Hague, Netherlands

ZK-eSIM memory and CPU usage server load

Cost Runtime Cost (ms)

End-to-End Cost (ms)

Scheme

SM-DP+ 53660

1200 98199

Table 2: End-to-End cost of commercial RSP and the proposed ZK-eSIM averaged over 25 Runtimes

the certificate initialisation phase to align with the GSMA RSP specification [18]. Additionally, for this evaluation, we use an EC-based Schnorr proof [44] to allow the user to prove their identity without leaking their EID (simplified in implementation for a Javacard environment), SHA256-based commitments during the certificate initialisation phase, and ECDH [24] for key derivation and agreement. In terms of computational performance, ZK-eSIM exhibits an approximate increase in cryptographic processing time of 83% (from 53.660 seconds vs. 98.199 seconds). One contributing factor to this increase is the registration phase, which is not included in the cost of the commercial RSP because this step occurs prior to protocol initialisation. The cost is included in the ZK-eSIM calculation due to the introduced cryptographic primitives that demonstrate the overhead costs associated with improvements to user privacy when a user registers with a new MNO. Considering only the phases within the commercial RSP, the cost increases by ∼ 64%. This increase results from the integration of additional cryptographic primitives, which introduce additional communication overhead costs between the UE and SM-DP+ and MNO servers. The added overhead is accompanied by a significant enhancement in user privacy compared to the commercial RSP, achieved by anonymising user identifiers. Protocol phases containing zero-knowledge proofs contribute the most to the cost, increasing by 10.441 seconds and 17.359 seconds for certificate initialisation and profile ordering, respectively. Both of these phases involve ZKP generation and verification, which incur relatively high runtimes compared to the commercial method, which has no proof computations and offers little to no privacy guarantees. Overall, these results indicate that although ZK-eSIM incurs higher computational costs (as evidenced by the end-to-end execution time) than the commercial RSP, it considerably improves user privacy. This is achieved by integrating ZKPs with additional cryptographic primitives, mitigating inherent user-identifier leakage in RSP. Combined with the analysis in Table 1, we note that ZK-eSIM requires longer runtimes but provides greater privacy than the commercial RSP, justifying the additional cost for those who value privacy.

9.4

Server Scalability of ZK-eSIM

Figure 11 presents the peak memory usage (and standard deviation of memory usage across the session) and cumulative CPU-seconds consumed by each server as the total number of requests served scales towards 1,000,000 concurrent download requests. Peak memory usage remains reasonable for large scale and closely clustered across all three roles, converging to 998 ± 9 MB at the SM-DP+, 1006 ± 7 MB at the MNO, and 1008 ± 8 MB at the PCA. The small increase in memory usage indicates that the ZK-eSIM scheme incurs

peak usage (MB)

ZK-eSIM

N/A 7 (±1) 1073 52580 9964 (±918) 10448 (± 620) 18432 (± 764) 59355 (± 955)

MNO

PCA

Peak Memory Usage (mean ± 1 SD) MNO 1008 ± 8 MB (SD) PCA 1006 ± 7 MB (SD) SM-DP+ 998 ± 9 MB (SD)

1100 1000 900 0

6000

CPU seconds

Commercial RSP[18]

Registration Certificate Initialisation Order Profile Profile Download Registration Certificate Initialisation Order Profile Profile Download

200,000

400,000

600,000

800,000

total requests served

1,200,000

1,400,000

CPU Seconds Consumed

4000

MNO 2843.6 s SM-DP+ 234.8 s PCA 111.5 s

2000 0

1,000,000

200,000

400,000

600,000

800,000

total requests served

1,000,000

1,200,000

1,400,000

Figure 11: Server performance under load in range from 1 to 1,000,000 concurrent download requests

no significant per-request memory accumulation, since the zeroknowledge proof verification operates on fixed-size cryptographic material. The CPU-seconds consumed reveal the same asymmetry observed in the per-download timings, with the majority of the processing cost concentrated at the MNO. Serving 1,000,000 requests, the MNO consumes 2843.6 s in CPU time on average, an order of magnitude greater than the 234.8 s at the SM-DP+ and the 111.5 s at the PCA. This reflects the MNO’s role in performing the EC-based Schnorr identity proof verification, which incurs a higher computational load while ensuring that the network learns no permanent device or subscriber identifiers. Overall, the server load scales linearly with the number of requests served, with memory usage remaining bounded across all roles and CPU consumption remaining minimal at the SM-DP+ and PCA. As with the per-download analysis, the bulk of the cost is produced at the MNO, where the core identity privacy processing occurs, and this additional cost coincides with significant user privacy enhancements delivered through the anonymisation of user identifiers.

Discussion

ZK-eSIM primarily focuses on securing provisioning-layer privacy but does not address cross-protocol risks that persist once a profile is installed. Users may still face jurisdictional exposure when traffic is routed through unexpected foreign networks, when silent background communication initiated by embedded profile commands goes unnoticed, when fragile lifecycle operations silently fail, and when private 5G deployments shift control to administrators with weaker oversight [31]. Also, IP address deanonymisation is out of scope for this paper. Extending ZK-eSIM to support routing transparency, IP address anonymisation, constrained profile behaviour, and resilient lifecycle management remains future work.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Conclusion

ZK-eSIM replaces the persistent identifiers exposed during GSMA Consumer RSP with ZKPs, single-use pseudonym certificates, and per-session pseudonyms, achieving provable subscriber anonymity and provisioning-session unlinkability while retaining accountable traceability. A Java Card applet prototype on a test eUICC, integrated with a modified open-source SM-DP+ and LPA, shows that these guarantees are practical within the existing GSMA ecosystem.

References [1] Abu Shohel Ahmed, Aleksi Peltonen, Mohit Sethi, and Tuomas Aura. 2024. Security Analysis of the Consumer Remote SIM Provisioning Protocol. ACM Transactions on Privacy and Security 27, 3 (Aug. 2024), 1–36. doi:10.1145/3663761 [2] Abu Shohel Ahmed, Mukesh Thakur, Santeri Paavolainen, and Tuomas Aura. 2021. Transparency of SIM profiles for the consumer remote SIM provisioning protocol. Annals of Telecommunications 76, 3-4 (April 2021), 187–202. doi:10.1007/s12243020-00791-2 [3] Apple. 2025. Apple unveils iPhone 17 Pro and iPhone 17 Pro Max. https://www.apple.com/newsroom/2025/09/apple-unveils-iphone-17-proand-iphone-17-pro-max/ [4] David Basin, Jannik Dreier, Lucca Hirschi, Saša Radomirovic, Ralf Sasse, and Vincent Stettler. 2018. A Formal Analysis of 5G Authentication. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security. ACM, Toronto Canada, 1383–1396. doi:10.1145/3243734.3243846 [5] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized Anonymous Payments from Bitcoin. In 2014 IEEE Symposium on Security and Privacy. IEEE, San Jose, CA, 459–474. doi:10.1109/SP.2014.36 [6] Eli Ben-Sasson, Alessandro Chiesa, Matthew Green, Eran Tromer, and Madars Virza. 2015. Secure Sampling of Public Parameters for Succinct Zero Knowledge Proofs. In 2015 IEEE Symposium on Security and Privacy. IEEE, San Jose, CA, 287–304. doi:10.1109/SP.2015.25 [7] Manuel Blum, Paul Feldman, and Silvio Micali. 1988. Non-interactive zeroknowledge and its applications. In Proceedings of the twentieth annual ACM symposium on Theory of computing - STOC ’88. ACM Press, Chicago, Illinois, United States, 103–112. doi:10.1145/62212.62222 [8] Benedikt Brecht, Dean Therriault, André Weimerskirch, William Whyte, Virendra Kumar, Thorsten Hehn, and Roy Goudy. 2018. A Security Credential Management System for V2X Communications. doi:10.48550/ARXIV.1802.05323 [9] Jan Camenisch and Anna Lysyanskaya. 2001. An Efficient System for Nontransferable Anonymous Credentials with Optional Anonymity Revocation. In Advances in Cryptology — EUROCRYPT 2001, Gerhard Goos, Juris Hartmanis, Jan Van Leeuwen, and Birgit Pfitzmann (Eds.). Vol. 2045. Springer Berlin Heidelberg, Berlin, Heidelberg, 93–118. doi:10.1007/3-540-44987-6_7 [10] Jan Camenisch and Anna Lysyanskaya. 2001. An Identity Escrow Scheme with Appointed Verifiers. In Advances in Cryptology — CRYPTO 2001, Gerhard Goos, Juris Hartmanis, Jan Van Leeuwen, and Joe Kilian (Eds.). Vol. 2139. Springer Berlin Heidelberg, Berlin, Heidelberg, 388–407. doi:10.1007/3-540-44647-8_23 [11] Jan Camenisch and Anna Lysyanskaya. 2004. Signature Schemes and Anonymous Credentials from Bilinear Maps. In Advances in Cryptology – CRYPTO 2004, David Hutchison, Takeo Kanade, Josef Kittler, Jon M. Kleinberg, Friedemann Mattern, John C. Mitchell, Moni Naor, Oscar Nierstrasz, C. Pandu Rangan, Bernhard Steffen, Madhu Sudan, Demetri Terzopoulos, Dough Tygar, Moshe Y. Vardi, Gerhard Weikum, and Matt Franklin (Eds.). Vol. 3152. Springer Berlin Heidelberg, Berlin, Heidelberg, 56–72. doi:10.1007/978-3-540-28628-8_4 [12] David Chaum. 1983. Blind Signatures for Untraceable Payments. In Advances in Cryptology, David Chaum, Ronald L. Rivest, and Alan T. Sherman (Eds.). Springer US, Boston, MA, 199–203. doi:10.1007/978-1-4757-0602-4_18 [13] Yvo G. Desmedt. 1994. Threshold cryptography. European Transactions on Telecommunications 5, 4 (July 1994), 449–458. doi:10.1002/ett.4460050407 [14] Alex Deutsch. 2025. Is an eSIM Cheaper Than Roaming? Here’s the Breakdown. https://esim.planet.uk/news/is-an-esim-cheaper-than-roaming-heresthe-breakdown/ [15] D. Dolev and A. Yao. 1983. On the security of public key protocols. IEEE Transactions on Information Theory 29, 2 (March 1983), 198–208. doi:10.1109/TIT. 1983.1056650 [16] ESTKme Group. 2025. GitHub - estkme-group/lpac at d214738fa0bdb23faf5833d3d798963079a00468. https://github.com/estkmegroup/lpac/tree/d214738fa0bdb23faf5833d3d798963079a00468 [17] GSMA. 2019. Security Accreditation Scheme (SAS). https://www.gsma. com/solutions-and-impact/technologies/security/gsma_resources/securityaccreditation-scheme-for-uicc/ [18] GSMA. 2023. RSP Architecture SGP.21 V3.1. Technical Report. [19] GSMA. 2023. SGP.22 RSP Technical Specification v3.0. Technical Report.

Ahmad et al.

[20] GSMA. 2024. eSIM Market – China and Beyond. Technical Report. GSMA. https://www.gsma.com/solutions-and-impact/technologies/esim/wp-content/ uploads/2024/07/GSMA-Welcome-and-eSIM-Market-China-and-Beyond.pdf [21] GSMA. 2026. eSIM Certificates. https://www.gsma.com/solutions-and-impact/ technologies/esim/gsma-root-ci/ [22] GSMA. 2026. SAS Accredited Sites. https://www.gsmaservices.com/assuranceservices/security-accreditation-scheme-sas/sas-accredited-sites/ [23] Francesco Intoci, Julian Sturm, Daniel Fraunholz, Apostolos Pyrgelis, and Colin Barschel. 2023. P3LI5: Practical and confidEntial Lawful Interception on the 5G core. In 2023 IEEE Conference on Communications and Network Security (CNS). 1–9. doi:10.1109/CNS59707.2023.10288872 [24] Neal Koblitz. 1987. Elliptic curve cryptosystems. Math. Comp. 48, 177 (1987), 203–209. doi:10.1090/S0025-5718-1987-0866109-5 [25] Adrien Koutsos. 2019. The 5G-AKA Authentication Protocol Privacy. In 2019 IEEE European Symposium on Security and Privacy (EuroS&P). 464–479. doi:10. 1109/EuroSP.2019.00041 [26] Kevin Lee, Ben Kaiser, Jonathan Mayer, and Arvind Narayanan. 2020. An empirical study of wireless carrier authentication for SIM swaps. (2020). [27] Tobias Looker, Vasilis Kalos, Andrew Whitehead, and Mike Lodder. 2026. The BBS Signature Scheme. Internet Draft draft-irtf-cfrg-bbs-signatures-10. Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbssignatures/03/ [28] Zhihong Luo, Silvery Fu, Natacha Crooks, Shaddi Hasan, Christian Maciocco, Sylvia Ratnasamy, and Scott Shenker. 2023. LOCA: A Location-Oblivious Cellular Architecture. USENIX Association, Boston, MA, 1621–1646. [29] Mary Maller, Sean Bowe, Markulf Kohlweiss, and Sarah Meiklejohn. 2019. Sonic: Zero-Knowledge SNARKs from Linear-Size Universal and Updatable Structured Reference Strings. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security. ACM, London United Kingdom, 2111–2128. doi:10. 1145/3319535.3339817 [30] Vasilios Mavroudis and Petr Svenda. 2020. JCMathLib: Wrapper Cryptographic Library for Transparent and Certifiable JavaCard Applets. In 2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW). 89–96. doi:10.1109/ EuroSPW51379.2020.00022 [31] Maryam Motallebighomi, Jason Veara, Evangelos Bitsikas, and Aanjhan Ranganathan. 2025. eSIMplicity or eSIMplification? Privacy and Security Risks in the eSIM Ecosystem. In Proceedings of the 34th USENIX Security Symposium. [32] Matteo Nardelli, Francesco De Sclavis, and Michela Iezzi. 2025. A Hitchhiker’s Guide to Privacy-Preserving Digital Payment Systems: A Survey on Anonymity, Confidentiality, and Auditability. doi:10.48550/arXiv.2505.21008 arXiv:2505.21008. [33] European Parliament and Council of the European Union. 2016. Regulation (EU) 2016/679 (General Data Protection Regulation). https://eur-lex.europa.eu/eli/ reg/2016/679/oj/eng [34] Gigi Onag. 2025. Privacy watchdog hits SKT with record $97M fine over data breach. https://www.lightreading.com/regulatory-politics/privacy-watchdoghits-skt-with-record-97m-fine-over-data-breach [35] Oracle. 2015. javacardx.security (Java Card API, Classic Edition). https://docs. oracle.com/cd/E59935_01/api/javacardx/security/package-summary.html [36] Osmocom. 2026. osmocom/pysim. https://github.com/osmocom/pysim [37] Alex Passett. 2024. Workz and its Cloud eSIM Platform Surpass 100 Partner Telcos. https://www.iotevolutionworld.com/iot/articles/458797-workz-its-cloudesim-platform-surpass-100-partner.htm [38] Torben P. Pedersen. 1991. Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. In Advances in Cryptology—CRYPTO ’91 (Lecture Notes in Computer Science, Vol. 576). Springer, 129–140. doi:10.1007/3-540-46766-1_9 [39] Python Cryptographic Authority (pyca). 2026. Primitives — Cryptography 48.0.0.dev1 documentation. https://cryptography.io/en/latest/hazmat/primitives/ [40] Siddharth Prakash Rao and Alexandros Bakas. 2023. Authenticating Mobile Users to Public Internet Commodity Services Using SIM Technology. In Proceedings of the 16th ACM Conference on Security and Privacy in Wireless and Mobile Networks. ACM, Guildford United Kingdom, 151–162. doi:10.1145/3558482.3590181 [41] Juniper Research. 2025. Travel eSIMs Surge as Roaming Alternative - Up 85% in 2025 Mobile Operators Will Play Growing Role in the Market. https://www. juniperresearch.com/press/travel-esims-surge-as-roaming-alternative/ [42] Mike Robuck. 2024. FCC fines T-Mobile US for data breaches. https://www. mobileworldlive.com/t-mobile-us/fcc-fines-t-mobile-us-for-data-breaches/ [43] Paul Schmitt and Barath Raghavan. 2021. Pretty Good Phone Privacy. In 30th USENIX Security Symposium (USENIX Security 21). https://www.usenix.org/ conference/usenixsecurity21/presentation/schmitt [44] C. P. Schnorr. 1990. Efficient Identification and Signatures for Smart Cards. In Advances in Cryptology — CRYPTO’ 89 Proceedings, Gilles Brassard (Ed.). Vol. 435. Springer New York, New York, NY, 239–252. doi:10.1007/0-387-34805-0_22 [45] Adi Shamir. 1979. How to share a secret. Commun. ACM 22, 11 (Nov. 1979), 612–613. doi:10.1145/359168.359176 [46] Quan Shi, Liying Wang, Prosanta Gope, Qi Liang, Haowen Wang, Qirui Liu, Chenren Xu, Shangguang Wang, Qing Li, and Biplab Sikdar. 2026. LPG: Raise Your Location Privacy Game in Direct-to-Cell LEO Satellite Networks. In 35th USENIX Security Symposium (USENIX Security 26). https://www.usenix.org/

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

conference/usenixsecurity26/presentation/shi-quan [47] Stephen Treffinger. 2025. If you’re not using an eSIM when you travel, you’re getting ripped off. https://www.theguardian.com/lifeandstyle/2025/sep/26/howdoes-esim-work [48] verbraucherzentrale. 2026. International roaming: Avoid hidden costs with Wi-Fi and mobile networks. https://www.verbraucherzentrale.de/wissen/digitalewelt/mobilfunk-und-festnetz/internationales-roaming-bei-wlan-undmobilfunk-kostenfallen-vermeiden-27954 [49] Harald Welte. 2026. sysmocom - systems for mobile communications GmbH. Technical Report. sysmocom. https://www.sysmocom.de/manuals/sysmoeuiccmanual.pdf

CCS ’26, November 15–19, 2026, The Hague, Netherlands

[50] Travel and Tour World. 2025. New Travel ESIM Options Are Unlocking Affordable, Global Connectivity For Travelers In China, India, And Southeast Asia. https://www.travelandtourworld.com/news/article/new-travel-esimoptions-are-unlocking-affordable-global-connectivity-for-travelers-in-chinaindia-and-southeast-asia/ [51] Yang Yang, Quan Shi, Prosanta Gope, Behzad Abdolmaleki, and Biplab Sikdar. 2025. PGUS: Pretty Good User Security for Thick MVNOs with a Novel Sanitizable Blind Signature. In 2025 IEEE Symposium on Security and Privacy (SP). doi:10. 1109/SP61157.2025.00144 [52] Hang Yuan, Artiom Baloian, Jan Janak, and Henning Schulzrinne. 2024. eSIM Technology in IoT Architecture. doi:10.48550/ARXIV.2401.04302

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Table 3: Notation Symbol — meaning 𝑥 ∈ {MNO, PCA, SMDP, LEA, 𝑈 , LPA} — Principals: MNO, PCA, SMDP+, LEA, eUICC (U), LPA (𝑠𝑘𝑥 , 𝑝𝑘𝑥 ) - Entity 𝑥’s long-term keypair (𝑠𝑘 tls , 𝐶𝑒𝑟𝑡 tls ) - SM-DP+ TLS endpoint key/cert (𝑠𝑘 auth , 𝐶𝑒𝑟𝑡 auth ) - SM-DP+ server-auth key/cert (𝑠𝑘 pb , 𝐶𝑒𝑟𝑡 pb ) - SM-DP+ profile-signer/binder key/cert 𝑠𝑘𝑏 - eUICC-sealed binding secret PCert𝑈 - Pseudonym cert (PCA sig on (𝑝𝑘𝑈 , expiry)) 𝑚 EID - bound EID digest 𝐶 EID - commitment to bound EID digest 𝜎EID - MNO blind signature on 𝑚 EID EncEid - EID escrow 𝐾pid - pseudonym key pid - per-session pseudonym Hpid - hashed pseudonym ℎ cert - pseudonym cert hash 𝐿auth , 𝐿spent - MNO authorisation log/SM-DP+ spent-token log rootauth , rootspent - Accumulator digests of the above 𝜋inc - Inclusion proof for Hpid in 𝐿auth spent - Witness that token 𝑇𝑖 is in 𝐿spent 𝜔𝑖 𝑇𝑖 - One-time release/authorisation token 𝜎cred - MNO authorisation over (Hpid, ℎ cert , mnoId) 𝐼𝑡 - Transcript nonce (server-chosen) 𝑁𝑈 , 𝑁𝑆 - UE/server nonces nonce - Single-use server challenge smdpAddress - Server identifier (from 𝐶𝑒𝑟𝑡 tls ) serverOID - Server OID (from 𝐶𝑒𝑟𝑡 auth ,𝐶𝑒𝑟𝑡 pb ) (𝑥𝑈 , 𝑋𝑈 ), (𝑥𝑆 , 𝑋𝑆 ) - AKE secrets/publics for UE and SM-DP+; (𝑘, 𝑘 ′ ) - Session keys 𝑃 - Profile package; 𝑡𝑃 , 𝑡 mno , 𝑡 iccid are MACs under 𝑘 ′ TokSet𝜏 - Tokens redeemed in epoch 𝜏; 𝑐𝜏 = accepted count SR𝜏 - Dual-signed settlement receipt for epoch 𝜏

Additional Preliminaries

A.0.1 Pedersen Commitment. The Pedersen commitment scheme is constructed within a cyclic group 𝐺 = ⟨𝑔⟩ of prime order 𝑝, where the discrete logarithm problem is computationally hard. The scheme consists of the following algorithms [38]: • pp ← Ped.Setup(1𝜆 ): Sample a prime-order group 𝐺 = ⟨𝑔⟩ with |𝐺 | = 𝑝. Choose 𝛼 ← Z𝑝 uniformly, set 𝑢 ← 𝑔𝛼 , and erase 𝛼. Output public parameters pp = (𝐺, 𝑝, 𝑔, 𝑢). • 𝑐𝑚 ← Ped.Commit(𝑚; 𝑟 ): For 𝑚 ∈ Z𝑝 and 𝑟 ← Z𝑝 , output 𝑐𝑚 = 𝐶 (𝑚; 𝑟 ) = 𝑔𝑟 𝑢𝑚 ∈ 𝐺 . • {0, 1} ← Ped.Open(𝑐𝑚, 𝑚, 𝑟 ): Accept iff 𝑐𝑚 = 𝑔𝑟 𝑢𝑚 in 𝐺. The scheme must satisfy: • Perfect hiding. For any 𝑚 0, 𝑚 1 ∈ Z𝑝 , the distributions {𝐶 (𝑚 0 ; 𝑟 )}𝑟 ←Z𝑝 and {𝐶 (𝑚 1 ; 𝑟 )}𝑟 ←Z𝑝 are identical; the commitment leaks no information about 𝑚. • Computational binding (under DLP and unknown log𝑔 𝑢). If an ′ ′ adversary produces two valid openings 𝑐𝑚 = 𝑔𝑟 𝑢𝑚 = 𝑔𝑟 𝑢𝑚 ′ ′ with (𝑚, 𝑟 ) ≠ (𝑚 , 𝑟 ), then one can recover 𝛼 = log𝑔 𝑢 = (𝑟 − 𝑟 ′ ) · (𝑚 ′ −𝑚) −1 mod 𝑝, which breaks DLP. Thus forging two openings is infeasible.

Ahmad et al.

A.1

ZK-eSIM Construction: Notation and Interfaces

A.1.1 Table of Notations. We write ZK.Prove/ZK.Verify for noninteractive zero-knowledge proofs of knowledge, PRF𝑘 (·) for a pseudorandom function keyed by 𝑘, Enc/Dec for a public-key encryption scheme, Com(𝑚; 𝑟 ) for a statistically hiding, computationally binding commitment scheme with public parameters.

Algorithms

In this section, we list the following algorithms: Setup, RegisterAndIssue, CertInit, ZKRequest, OrderProfile, MutualAuthAndProvision, Settle, and Deanonymise. Algorithm 1: Setup Require: Security parameter 1𝜆 . MNO has (𝑠𝑘 MNO , 𝑝𝑘 MNO ); PCA has (𝑠𝑘 PCA , 𝑝𝑘 PCA ); LEA has (𝑠𝑘 LEA , 𝑝𝑘 LEA ), SM-DP+ sets long-term credentials: (sktls , Certtls ) (the key and certificate for TLS authentication), (skauth , Certauth ) (the key and certificate for server authentication), and (skpb , Certpb ) (the key and certificate for profile binding) 1: 𝐶𝑅𝑆 ← ZK.Setup(1𝜆 ); 𝑐𝑘 ← Com.Setup(1𝜆 ) 2: Fix a domain-separated hash family 𝐻, 𝐻 ′ , 𝐻 ′′ 3: Fix the functions 𝑓 , 𝑓 ′ where 𝑓 : {0, 1} ∗ × N → {0, 1} ∗ is deterministic with | 𝑓 (𝑥, ℓ ) | = ℓ. We fix a randomness-budget function 𝜌 : N → N in the public parameters and, when needed, set 𝑠 ← 𝑓 (𝑟 seed , 𝜌 (𝜆) ) with 𝑟 seed ←$ {0, 1} 𝜆 , and 𝑓 ′ : K𝑏 × {0, 1} 𝜌 (𝜆) → S K𝑈 × P K𝑈 is deterministic and outputs a valid keypair, and K𝑏 denote the space of sealed per-card binding secrets; S K𝑈 and P K𝑈 the secret/public key spaces of the user key type. We write {0, 1} ℓ for ℓ-bit strings and {0, 1} ∗ for arbitrary-length strings. 4: Fix algorithm families: PRF, KDF, Sig, PKE, BSig, SE, MAC, Acc, Com with interfaces: Sig = (Sig.sign, Sig.verify) - Digital signature, PKE = (PKE.enc, PKE.dec) - Public-key encryption, SE = (SE.E, SE.D) - Symmetric encryption, MAC = (MAC.tag, MAC.verify) - Message authentication code, BSig = (BSig.blind, BSig.sign, BSig.unblind, BSig.verify) - Blind signatures, KA = (KA.gen, KA.agree) - Key agreement, Acc = (Acc.init, Acc.add, Acc.digest, Acc.prove, Acc.verify) - Append-only accumulator, Com = (Com.Setup, Com.Commit, Com.Open, Com.Verify) - commitment. 5: Load GSMA CI roots and PCA chain; install required certs in the LPA (system anchor). 6: Fix an operator-identifier namespace and let mnoId denote the issuing MNO identifier. 7: Publish registry entries (𝑝𝑘 MNO , 𝑝𝑘 PCA , 𝑝𝑘 LEA ) under CI roots; record certificate policies. 8: Initialise local state: MNO sets 𝐿auth ← ∅; SM-DP+ sets 𝐿spent ← ∅; each eUICC samples and maintains sealed: 𝑠𝑘𝑏 ←$ K𝑏 9: pp ← 𝐶𝑅𝑆, 𝑐𝑘, 𝐻, 𝐻 ′ , 𝐻 ′′ , 𝜌, 𝑓 , 𝑓 ′ , PRF, KDF, Sig, PKE, BSig, KA, SE, MAC, Acc, Com,

CI roots, PCA chain, mnoId, 𝑝𝑘 MNO , 𝑝𝑘 PCA , 𝑝𝑘 LEA 10: return Public parameters pp, 𝐿auth , 𝐿spent , 𝑠𝑘𝑏

Algorithm 2: RegisterAndIssue Require: UE (eUICC) holds sealed 𝑠𝑘𝑏 and identifier EID; public parameters pp. ; any 𝑈 𝐸 ↔ message is relayed by the LPA. 1: Eligibility attestation over a secure channel: 𝑈 𝐸 → MNO: EID + device attestation.

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

CCS ’26, November 15–19, 2026, The Hague, Netherlands

1 (eligibility under MNO) ∧ pid = PRFKDF(𝑠𝑘𝑏 ,nonce) (EID) (pseudonym fail, abort. correctness) ∧ EncEid = PKE.Enc𝑝𝑘LEA (EID; 𝑟 ) (ciphertext binds to same 3: MNO → 𝑈 𝐸: Proceed. EID) 4: Local preparation (inside eUICC): UE: Sample 𝑟𝑏 ←$ {0, 1} 𝜆 and 8: Generate proof: 𝜋 req ← ZK.Prove(𝑥; 𝑤 ). 𝑟 blind ←$ {0, 1} 𝜆 , 𝑚 EID ← 𝐻 (EID ∥ 𝑠𝑘𝑏 ), 𝐶 EID ← Com.Commit𝑐𝑘 (𝑚 EID ; 𝑟𝑏 ), 9: return to MNO: 𝑥, PCert𝑈 , 𝜋𝑟𝑒𝑞 (req, 𝛼 ) ← BSig.blind(𝑝𝑘 MNO , 𝑚 EID ; 𝑟 blind ). 5: Relation R issue (predicate over (𝑥, 𝑤 )): 6: Statement 𝑥 = (EID, 𝐶 EID , req, 𝑝𝑘 MNO ); Witness 𝑤 = (𝑠𝑘𝑏 , 𝑟𝑏 , 𝑟 blind , 𝛼 ). Algorithm 5: OrderProfile 2: Eligibility & KYC/device checks: MNO verifies eligibility. If checks

Require: nonceMNO ; 𝜋req ; PCert𝑈 ; 𝐿auth ; 𝑥 = (𝑝𝑘 MNO , 𝑝𝑘 LEA , 𝑝𝑘𝑈 , nonce, pid, EncEid); Require: 𝑚 EID = 𝐻 (EID ∥ 𝑠𝑘𝑏 ) (binding) ∧ 𝐶 EID = Com.Commit𝑐𝑘 (𝑚 EID ; 𝑟𝑏 ) Public parameters pp. (commit correctness) ∧ ∃ 𝛼 : (req, 𝛼 ) = BSig.blind(𝑝𝑘 MNO , 𝑚 EID ; 𝑟 blind ) 1: Sanity & freshness (bind to server challenge): (well-formed blind request) 2: If nonce ≠ nonceMNO then abort. 8: Generate proof: 𝜋 ← ZK.Prove(𝑥; 𝑤 ). 3: Verification at MNO: Check PCert𝑈 chain and expiry under 𝑝𝑘 PCA ; 9: 𝑈 𝐸 → MNO: (𝑥, 𝜋 ). parse 𝑝𝑘𝑈 . If check fails then abort; Accept iff ZK.Verify(𝑥, 𝜋req ) = 1 10: MNO verifies and issues: with this 𝑝𝑘𝑈 and received (nonce, pid, EncEid); otherwise abort. 11: If ZK.Verify(𝑥, 𝜋 ) = 0 , then abort. 4: Attests same-eUICC linkage, eligibility under MNO, pseudonym cor˜ 12: 𝜎˜ ← BSig.sign(𝑠𝑘 MNO , req); MNO → 𝑈 𝐸: 𝜎. rectness, and well-formed EncEid. 13: Unblind and check (inside eUICC): 5: Compute identifiers and defend against replay: Hpid ← 𝐻 ′ (pid); 14: 𝜎EID ← BSig.unblind(𝛼, 𝜎˜ ). ℎ cert ← 𝐻 ′′ (PCert𝑈 ); If Hpid ∈ 𝐿auth , then abort. 15: Assert BSig.verify(𝑝𝑘 MNO , 𝑚 EID , 𝜎EID ) = 1. 6: MNO stores a mapping Hpid ↦→ EncEid. 7:

Algorithm 3: CertInit Require: 𝑈 𝐸 holds eligibility credential 𝜎EID , EID and sealed 𝑠𝑘𝑏 (local state, never transmitted); public parameters pp. 1: Ephemeral key (inside eUICC): Sample 𝑟 seed ←$ {0, 1} 𝜆 ; (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ) ← 𝑓 ′ (𝑠𝑘𝑏 , 𝑓 (𝑟 seed ) ). For example, in a pairing setting, we let 𝑒 : G1 ×G2 → G𝑇 be a bilinear map of prime order 𝑞 with generators 𝑔1 , 𝑔2 , and let 𝑎 = 𝑠𝑘𝑏 ∈ Z𝑞∗ . Set 𝛼 ← 𝐻 fld (𝑟 seed ) ∈ Z𝑞∗ . Then 𝑓 (𝑟 seed ) = 𝛼 and 𝑓 ′ (𝑎, 𝛼 ) = (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ) with 𝑠𝑘𝑈 = 𝑎𝛼 mod 𝑞 and 𝑝𝑘𝑈 = 𝑔1 𝑈 ; equivalently 𝑒 (𝑝𝑘𝑈 , 𝑔2 ) = 𝑒 (𝑔1𝛼 , 𝑔2𝑎 ). 2: Relation R bind (predicate over (𝑥, 𝑤 )): 3: Statement 𝑥 = (𝑝𝑘𝑈 , 𝑝𝑘 MNO ); Witness 𝑤 = (𝑠𝑘𝑏 , 𝑟 seed , EID, 𝜎EID ).

7: Place order with SM-DP+ (two-round exchange): 8: MNO → SM-DP+ : DownloadOrder(Hpid, mnoId, profileType). 9: SM-DP+ reserves a fresh 𝐼𝐶𝐶𝐼 𝐷. 10: SM-DP+ → MNO : 𝐼𝐶𝐶𝐼 𝐷. 11: MNO → SM-DP+ : ConfirmOrder(𝐼𝐶𝐶𝐼 𝐷, Hpid, releaseFlag =

true). 12: SM-DP+ maps 𝐼𝐶𝐶𝐼 𝐷 ↔ Hpid and acknowledges. 13: MNO authorises & publishes log root: 14: 𝐿auth ← Acc.add(𝐿auth , Hpid); 𝜋 inc ← Acc.prove(𝐿auth , Hpid);

𝑠𝑘

rootauth ← Acc.digest(𝐿auth ). root ← Sig.sign 𝜎MNO (root ). auth 𝑠𝑘 MNO 16: MNO issues single-use tokens/credentials (bound to (Hpid, ℎ cert )): 15:

17: 𝜎cred ← Sig.sign𝑠𝑘MNO (Hpid, ℎ cert , mnoId). Require: ∃ 𝑠𝑘𝑈 ∈ K : 𝑓 ′ (𝑠𝑘𝑏 , 𝑓 (𝑟 seed ) ) = (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ) (same18: 𝑇𝑖 ← Sig.sign𝑠𝑘MNO (Hpid, ℎ cert , mnoId, expiry). eUICC) ∧ 𝑚 EID = 𝐻 (EID ∥ 𝑠𝑘𝑏 ) (binding) ∧ BSig.verify(𝑝𝑘 MNO , 𝜎EID , 𝑚 EID ) = 19: Deliver to user securely on success: 1 (eligibility) root ). 20: MNO → 𝑈 𝐸 : (𝑇𝑖 , 𝜎cred , Hpid, 𝜋 inc , rootauth , 𝜎MNO 5: Generate proof: 𝜋 bind ← ZK.Prove(𝑥; 𝑤 ). root . 21: return to U: 𝑇𝑖 , 𝜎cred , Hpid, 𝜋 inc , rootauth , 𝜎MNO 6: Request & issuance: 7: 𝑈 𝐸 → PCA : (𝑥, 𝜋bind ). 8: if ZK.Verify(𝑥, 𝜋bind ) = 0, then abort Algorithm 6: MutualAuthAndProvision 9: PCA issues PCert𝑈 ← Sig.sign𝑠𝑘PCA (𝑝𝑘𝑈 , expiry). root ; Public Require: 𝑈 holds PCert𝑈 , 𝑠𝑘𝑈 , Hpid, 𝑇𝑖 , 𝜎cred , 𝜋inc , rootauth , 𝜎MNO 10: PCA → 𝑈 𝐸: PCert𝑈 parameters pp. 11: 𝑈 𝐸 retains 𝑠𝑘𝑈 and 𝑟 seed failed verification : status ←⊥, abort. 12: return to UE: PCert𝑈 . 1: Channel Setup (LPA↔Server) {Server-auth TLS}: 2: eUICC samples 𝑁𝑈 ←$ {0, 1} 𝜆 ; eUICC → LPA: 𝑁𝑈 . Algorithm 4: ZKRequest 3: LPA verifies cert_tls; on success obtain smdpAddress. LPA → SM-DP+: (𝑁𝑈 , smdpAddress). Require: 𝑈 holds PCert𝑈 on (𝑝𝑘𝑈 , expiry), eligibility credential 𝜎EID , 4: SM-DP+ samples transcript nonce 𝐼𝑡 ←$ {0, 1} 𝜆 and server nonce EID and sealed eUICC state including 𝑠𝑘𝑏 , 𝑟 seed ; public parameters pp. 𝑁𝑆 ←$ {0, 1} 𝜆 , then SM-DP+ → LPA: 1: Transport: Establish server-authenticated TLS. 5: Certauth , Sig.sign𝑠𝑘 (𝐼 , 𝑁𝑆 , 𝑁𝑈 , smdpAddress) ; 2: Challenge: MNO → 𝑈 : globally unique and single-use: nonce ←$ auth 𝑡 𝜆 {0, 1} , MNO stores nonceMNO ← nonce 6: LPA verifies. 3: Pseudonym (inside eUICC): 𝐾pid ← KDF(𝑠𝑘𝑏 , nonce); pid ← 7: LPA → 𝑈 : Certauth , Sig.sign𝑠𝑘 (𝐼 , 𝑁𝑆 , 𝑁𝑈 , smdpAddress) . 𝑈 verauth 𝑡 PRF𝐾pid (EID). ifies Certauth and obtains serverOID from Certauth . 8: Eligibility bundle (channel-bound, replay-protected): 4: Escrow encryption (inside eUICC): Sample 𝑟 ←$ {0, 1} 𝜆 ; EncEid ← 9: 𝑈 computes hcert := 𝐻 ′′ (PCert𝑈 ). PKE.Enc𝑝𝑘LEA (EID; 𝑟 ). 10: 𝑈 → LPA the eligibility bundle: 5: Relation R req (predicate over (𝑥, 𝑤 )): root 11: (PCert𝑈 , 𝜎cred ,𝑇𝑖 , Hpid, 𝜋 inc , rootauth , 𝜎MNO , 6: Statement 𝑥 = (𝑝𝑘 MNO , 𝑝𝑘 LEA , 𝑝𝑘𝑈 , nonce, pid, EncEid); Witness 𝑤 = (EID, 𝑠𝑘𝑏 , 𝑟 seed , 𝜎EID , 𝑟 ). Sig.sign𝑠𝑘𝑈 (𝐼𝑡 , 𝑁𝑆 , 𝑁𝑈 ,𝑇𝑖 , Hpid, PCert𝑈 , smdpAddress) ) 7: Require: ∃ 𝑠𝑘𝑈 ∈ K : 𝑓 ′ (𝑠𝑘𝑏 , 𝑓 (𝑟 seed ) ) = (𝑠𝑘𝑈 , 𝑝𝑘𝑈 ) (same12: LPA forwards to SM-DP+. eUICC) ∧ 𝑚 EID = 𝐻 (EID ∥ 𝑠𝑘𝑏 ) (binding) ∧ BSig.verify(𝑝𝑘 MNO , 𝜎EID , 𝑚 EID ) =13: Server-side verification and token spend: 4:

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Ahmad et al.

14: Parse 𝑝𝑘𝑈 from PCert𝑈 and verify the chain under 𝑝𝑘 PCA ; set ℎ cert ←

𝐻 ′′ (PCert𝑈 ). 15: Verify all of the following: 16: Sig.verify𝑝𝑘 (𝐼𝑡 , 𝑁𝑆 , 𝑁𝑈 ,𝑇𝑖 , Hpid, PCert𝑈 , smdpAddress) = 1 𝑈 MNO ∧ Sig.verify𝑝𝑘MNO (rootauth , 𝜎root ) =1

∧ Acc.verify(rootauth , Hpid, 𝜋 inc ) = 1 ∧ Sig.verify𝑝𝑘MNO ( (Hpid, ℎ cert , mnoId), 𝜎cred ) = 1. 17: Verify 𝑇𝑖 is a signature by 𝑝𝑘 MNO on (Hpid, ℎ cert , mnoId, expiry) and that now < expiry. 18: One-time use: if 𝑇𝑖 ∉ 𝐿spent then append 𝑇𝑖 to 𝐿spent , else abort. 19: Profile-signer introduction (bind signer to transcript): 20: SM-DP+ → LPA: Sig.sign𝑠𝑘 (𝐼𝑡 ), Certpb . pb 21: LPA → 𝑈 : same. 𝑈 verifies Certpb ; let serverOIDpb ← ServerOID(Certpb ); require serverOIDpb = serverOID; then verify Sig.verify𝑝𝑘pb (𝐼𝑡 ) = 1. 22: AKE with explicit authentication and context separation: 23: 𝑈 : (𝑥𝑈 , 𝑋𝑈 ) ← KA.gen( ). 24: 𝑈 𝐸 → LPA: Sig.sign𝑠𝑘 (𝐼𝑡 , 𝑋𝑈 ); LPA → SM-DP+: forward. 𝑈 25: SM-DP+ verifies Sig.verify𝑝𝑘 (𝐼𝑡 , 𝑋𝑈 ) = 1. 𝑈 26: (𝑥𝑆 , 𝑋𝑆 ) ← KA.gen( ); compute 𝐾𝑈 𝑆 ← KA.agree(𝑥𝑆 , 𝑋𝑈 ); derive ′ (𝑘, 𝑘 ) := KDF(𝐾𝑈 𝑆 , serverOID, 𝑈 ). 27: Profile delivery (confidentiality, and integrity): 28: SM-DP+ prepares profile package 𝑃 and associated metadata (mnoId, iccid). 29: Compute ciphertext and tags: 30: 𝐶 ← SE.E(𝑃 ; 𝑘 ), ′

𝑡 mno ← MAC(mnoId; 𝑘 ),

𝑡𝑃 ← MAC(𝐶; 𝑘 ′ ),

𝑡 iccid ← MAC(iccid; 𝑘 ′ ).

31: SM-DP+ → LPA: 32: (𝐶, 𝑡𝑃 , mnoId, 𝑡 mno , iccid, 𝑡 iccid , 𝑋𝑆 ,

Sig.sign𝑠𝑘pb (𝐼𝑡 , 𝑋𝑆 , 𝑋𝑈 , smdpAddress) ). 33: Client-side key derivation, verification, install: 34: 𝑈 verifies Sig.verify𝑝𝑘 (𝐼𝑡 , 𝑋𝑆 , 𝑋𝑈 , smdpAddress) = 1.

Parse payload to recover Hpid𝑖 ; if Hpid𝑖 ∉ 𝐿auth [𝜏 ] then continue 16: Mark 𝑇𝑖 as accepted. 17: end for 18: Pricing & tally 19: 𝑐𝜏 ← #{accepted 𝑇𝑖 }; amount ← TariffCalc(𝑐𝜏 ). 20: Mutual settlement receipt (cross-signing) 21: SR𝜏MNO ← Sig.sign𝑠𝑘 𝜏, 𝑐𝜏 , amount, root𝜏auth , MNO 𝜏 𝜏 𝜎MNO , root𝜏spent , 𝜎SMDP SMDP 𝜏 22: SR𝜏 ← Sig.sign𝑠𝑘SMDP 𝜏, 𝑐𝜏 , amount, rootauth , 𝜏 𝜏 𝜎MNO , root𝜏spent , 𝜎SMDP 23: SR𝜏 ← SR𝜏MNO ∥ SR𝜏SMDP . 24: return SR𝜏 . 15:

Algorithm 8: Deanonymise Require: Valid legal warrant specifying a lawful scope 𝑆; MNO retains EncEid; LEA stores secret tracing key 𝑠𝑘 LEA . 1: Lawful trigger & scope (Secure channel) 2: LEA registers the legal order and the lawful scope 𝑆 (e.g., a time window, case ID, target set). 3: LEA → MNO: request the unique escrow ciphertext satisfying 𝑆. 4: MNO evaluates 𝑆, and returns EncEid. 5: Policy-gated unsealing at LEA 6: EID′ ← PKE.Dec𝑠𝑘LEA (EncEid), 𝜋 ← PKE.𝑑𝑒𝑐𝑠𝑘LEA (EncEid) = EID′ 7: Scoped identity resolution at MNO 8: LEA → MNO: (EncEid, EID′ , 𝜋 ) 9: MNO verifies that EncEid is the escrow returned under 𝑆; resolve EID′ ↦→ KYC, else ⊥ 10: Return (EID′ , 𝜋 ) to the lawful process.

35: Decrypt and install: 𝑃 ← SE.D(𝐶; 𝑘 ); install 𝑃 on eUICC. 36: status ← OK iff all verifications passed ∧ 𝑃 installed . 37: return status ∈ {OK, ⊥}.

Algorithm 7: Settle Require: Epoch 𝜏 has ended; SM-DP+ maintains 𝐿spent [𝜏 ]; MNO maintains 𝐿auth [𝜏 ]; TokSet𝜏 ← { 𝑇𝑖 } redeemed during epoch 𝜏; pp. 1: Provider commitments (epoch-bound): 𝜏 2: root𝜏spent ← Acc.digest(𝐿spent [𝜏 ] ); 𝜎SMDP ← Sig.𝑠𝑖𝑔𝑛𝑠𝑘SMDP (𝜏 ∥root𝜏spent ). 3:

8: MNO-side verification & filtering: 𝜏 9: Verify Sig.verify𝑝𝑘 (𝜏 ∥root𝜏spent , 𝜎SMDP ) = 1. SMDP

𝜏 10: Compute (or verify) root𝜏auth and keep 𝜎MNO for the receipt. 11: for each 𝑇𝑖 ∈ TokSet𝜏 do 12: Signature check on token: if Sig.verify𝑝𝑘 (𝑇𝑖 ) = 0 then MNO

14:

continue {reject 𝑇𝑖 } spent Spent-membership: if Acc.verify(root𝜏spent ,𝑇𝑖 , 𝜔𝑖 ) = 0 then continue Authorisation linkage:

Game-based Definition

Definition 2 (Provisioning-Session Unlinkability). For a PPT adversary A and an entity E ∈ {MNO, SMDP+, PCA}, define

𝜏 root𝜏auth ← Acc.digest(𝐿auth [𝜏 ] ); 𝜎MNO ← Sig.sign𝑠𝑘MNO (𝜏 ∥root𝜏auth ).

4: Inclusion witnesses (from SM-DP+): spent 5: For each 𝑇𝑖 ∈ TokSet𝜏 : 𝜔𝑖 ← Acc.prove(𝐿spent [𝜏 ],𝑇𝑖 ). 6: Bundle from SM-DP+ to MNO: spent 𝜏 7: SM-DP+ → MNO: TokSet𝜏 , {𝜔𝑖 }𝑇𝑖 ∈TokSet𝜏 , root𝜏spent , 𝜎SMDP .

13:

We define the security of ZK-eSIM through two families of games: provisioning-session unlinkability and unforgeability. The former captures whether an infrastructure entity can link two accepted sessions to the same eUICC. The latter captures whether an adversary can make an honest MNO or SM-DP+ accept an unauthorised request.

E AdvUNLINK-E (𝜆) := Pr[UNLINKΠ,A (𝜆) = 1] − 12 . Π,A

We say that Π provides provisioning-session unlinkability if this advantage is negligible in 𝜆 for every PPT A and every E ∈ {MNO, SMDP+, PCA}. +

SMDP Definition 3 (Unforgeability). Let UFMNO Π,A (𝜆) and UFΠ,A (𝜆) denote the order-side and download-side unforgeability games in Fig. 13. Define

AdvUF-MNO (𝜆) := Pr[UFMNO Π,A Π,A (𝜆) = 1], and

AdvUF-SMDP (𝜆) := Pr[UFSMDP (𝜆) = 1]. Π,A Π,A We say that Π is unforgeable if both advantages are negligible in 𝜆 for every PPT adversary A.

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

E Game UNLINKΠ,A (𝜆) for E ∈ {MNO, SMDP+, PCA} pp ← Setup(1𝜆 ). Initialise 𝐿auth, 𝐿spent ← ∅. Let (𝑈 0, EID0 ) and (𝑈 1, EID1 ) be two eligible registered devices with EID0 ≠ EID1 . A chooses (𝑈 0, EID0 ) and (𝑈 1, EID1 ). The challenger samples $

b← − {0, 1} and defines ( idx𝑠 (b) :=

0 𝑠 −1

if b = 0, if b = 1,

𝑠 ∈ {1, 2}.

For each 𝑠 ∈ {1, 2}, the challenger runs an accepted provisioning session for (𝑈 idx𝑠 (b) , EIDidx𝑠 (b) ) and gives A the corresponding entity view View𝑠E . The views are defined as follows, where Hpid𝑠 := 𝐻 ′ (pid𝑠 ) and ℎ cert,𝑠 := 𝐻 ′′ (PCert𝑈 ,𝑠 ): View𝑠MNO := (pid𝑠 , EncEid𝑠 , 𝜋req,𝑠 , PCert𝑈 ,𝑠 , ℎ cert,𝑠 , Hpid𝑠 , 𝜎cred,𝑠 ,𝑇𝑖,𝑠 , 𝐿auth ). +

View𝑠SMDP := (PCert𝑈 ,𝑠 , ℎ cert,𝑠 , Hpid𝑠 ,𝑇𝑖,𝑠 , 𝜎cred,𝑠 , 𝜋inc,𝑠 , root rootauth,𝑠 , 𝜎MNO,𝑠 , 𝐼𝑡,𝑠 , 𝑁𝑆,𝑠 , 𝑁𝑈 ,𝑠 , 𝐿spent ). View𝑠PCA := (pk𝑈 ,𝑠 , 𝜋bind,𝑠 , PCert𝑈 ,𝑠 , expiry𝑠 ). A receives (View1E , View2E ) and outputs b′ ∈ {0, 1}. game outputs 1 iff b′ = b.

The

Figure 12: Provisioning-session unlinkability game for ZKeSIM.

E Game UFΠ,A (𝜆) for E ∈ {MNO, SMDP+ } pp ← Setup(1𝜆 ). Initialise Qreg, Qchal, Qauth ← ∅ and 𝐿spent ← ∅. All authorities are honest; A controls users and eUICCs. A may adaptively query:

ORegister,

OChallenge,

OAuthorize,

OProvision .

These oracles run the corresponding honest ZK-eSIM procedures and record registered EIDs, issued MNO nonces, issued authorisation tuples (Hpid,𝑇𝑖 , 𝜎cred, ℎ cert ), and spent tokens. ∗ ), where If E = MNO, A outputs (𝑥 ∗, PCert𝑈∗ , 𝜋req 𝑥 ∗ = (pk MNO, pk LEA, pk𝑈∗ , nonce∗, pid∗, EncEid∗ ). If E = SMDP+ , A outputs ∗ ∗ root∗ (PCert𝑈∗ , Hpid∗,𝑇𝑖∗, 𝜎cred , 𝜋inc , root∗auth, 𝜎MNO ).

Set ℎ ∗cert ← 𝐻 ′′ (PCert𝑈∗ ). A wins iff the honest verifier for role E accepts an unauthorised request: for E = MNO, an accepted request not backed by a fresh MNO challenge, a registered credential, and a valid same-eUICC binding; for E = SMDP+ , an accepted download not backed by valid MNO-issued authorisation material for (Hpid∗, ℎ ∗cert ), or using a token already in 𝐿spent . The game outputs 1 iff A wins.

CCS ’26, November 15–19, 2026, The Hague, Netherlands

eUICC or from two different registered eUICCs. The adversary observes only the selected infrastructure entity’s view. The protocol is unlinkable if no PPT adversary can distinguish these two cases with non-negligible advantage. Timing and packet-size metadata are excluded from the formal view, consistent with the threat model. Unforgeability (Fig. 13). The adversary may obtain honest registrations, MNO challenges, authorisations, and provisioning transcripts through the four learning oracles. For the MNO side, a successful forgery is an accepted request that is not backed by a registered eligibility credential, a fresh MNO challenge, and a valid proof binding the same eUICC to the credential, pseudonym, escrow ciphertext, and pseudonym certificate. For the SM-DP+ side, a successful forgery is an accepted download that is not backed by MNO-issued authorisation material bound to the same (Hpid, ℎ cert ) tuple, or that reuses a token already recorded in 𝐿spent . Therefore, a fresh Hpid generated by a legitimate registered device with a fresh MNO challenge is not a forgery.

D Security Proof D.1 Proof of Theorem 1 We prove the theorem by a standard hybrid argument. Let Game𝑖 denote the 𝑖-th hybrid, and let Win𝑖 be the event that A outputs the correct challenge bit b′ = b. We present the proof for E = MNO; the case E = SMDP+ follows by the same argument us+ ing View𝑠SMDP from Fig. 12, and the case E = PCA follows from the zero-knowledge of 𝜋 bind and ephemeral certificate indistinguishability. Game0 : Real game. This is the real unlinkability game UNLINKMNO Π,A $

(𝜆) in Fig. 12. The challenger samples b ← − {0, 1}, executes two accepted provisioning sessions for the devices determined by idx𝑠 (b), and returns View𝑠MNO = (pid𝑠 , EncEid𝑠 , 𝜋req,𝑠 , PCert𝑈 ,𝑠 , ℎ cert,𝑠 , Hpid𝑠 , 𝜎cred,𝑠 ,𝑇𝑖 𝑠 , 𝐿auth ). By definition, AdvUNLINK-MNO (𝜆) = Pr[Win0 ] − 21 . Π,A Game1 : Simulated zero-knowledge proofs. Replace each real proof 𝜋req,𝑠 ← ZK.Prove(𝑐𝑟𝑠, 𝑥𝑠 , 𝑤𝑠 ) with a simulated proof generated by the NIZK simulator. By zero-knowledge, Pr[Win1 ] − Pr[Win0 ] ≤ AdvZK BZK (𝜆). Game2 : Randomised key. Replace 𝐾pid,𝑠 ← KDF(sk𝑏 , nonce𝑠 ) $

with a uniform key 𝐾𝑠′ ← − {0, 1}𝜆 , and compute pid𝑠 ← PRF𝐾𝑠′ (EIDidx𝑠 (b) ). By the security of KDF, Pr[Win2 ] − Pr[Win1 ] ≤ AdvKDF BKDF (𝜆). Game3 : Random pseudonyms. Replace pid𝑠 ← PRF𝐾𝑠′ (EIDidx𝑠 (b) ) $

Figure 13: Unforgeability game for ZK-eSIM. Figures 12 and 13 formalise the game-based unlinkability and unforgeability properties used in Sec. 8, respectively. Unlinkability (Fig. 12). The challenge bit determines whether two accepted provisioning sessions come from the same registered

with an independently uniform pid𝑠 ← − {0, 1}𝜆 , except with negligible collision probability. By PRF security, Pr[Win3 ] − Pr[Win2 ] ≤ AdvPRF BPRF (𝜆). Game4 : Random hash outputs. Replace Hpid𝑠 ← 𝐻 ′ (pid𝑠 ) and ℎ cert,𝑠 ← 𝐻 ′′ (PCert𝑈 ,𝑠 ) with independent uniform values, unless

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Ahmad et al.

Case 3: Freshness violation. If the extracted witness is valid and the credential was registered, then the request can still be a forgery only if the MNO challenge is missing, reused, or not freshly issued. Since MNO challenges are sampled from {0, 1}𝜆 and consumed after successful use, the probability that A guesses an unissued fresh challenge is at most 𝑞𝑁 , 2𝜆 where 𝑞 𝑁 is the number of challenge queries. Reuse is rejected by the stateful freshness check. Case 4: Binding or hash inconsistency. It remains to consider the Cert Pr[Win5 ] − Pr[Win4 ] ≤ Adv BCert (𝜆). case where the credential is registered and the nonce is fresh, but the accepted request binds inconsistent values. If the proof verifies for Game6 : Simulated escrow ciphertexts. Replace EncEid𝑠 ← EncpkLEA (EID idx𝑠 (b) ) inconsistent values, this is already a soundness violation. Otherwise, 𝜆 with EncEid𝑠 ← EncpkLEA (0 ). Since the request proofs have already the only way to make two distinct pseudonyms or request bindings been simulated, the ciphertext plaintext is no longer used elsewhere map to the same accepted hashed pseudonym is to find a collision in in the visible transcript. By IND-CPA security, 𝐻 ′ . Likewise, if the credential binding through 𝑚 EID = 𝐻 (EID∥sk𝑏 ) Pr[Win6 ] − Pr[Win5 ] ≤ AdvIND-CPA (𝜆). is changed while preserving verification, this gives a collision in 𝐻 . BEnc Therefore this case is bounded by In Game6 , all fields that may depend on whether the two sessions CR CR Adv𝐻 (𝜆) + Adv𝐻 ′ (𝜆). use the same eUICC or different eUICCs have been simulated or randomised: the proofs, pseudonyms, hashed pseudonyms, certifiThe four cases cover every instance of accepting an unauthorised cate hashes, pseudonym certificates, and escrow ciphertexts. The MNO-side request. Thus, remaining fields, including 𝜎cred , 𝑇𝑖 , and 𝐿auth , are generated from UF-Cred CR AdvUF-MNO (𝜆) ≤ AdvSound-ZK Π,A BSound (𝜆) + Adv BCred (𝜆) + Adv𝐻 (𝜆) fresh session randomness and authorised session-local values, and 𝑞𝑁 therefore have the same distribution for b = 0 and b = 1. Hence CR +Adv𝐻 . ′ (𝜆) + 1 2𝜆 Pr[Win6 ] = . 2 D.3 Proof of Theorem 3 Applying the triangle inequality over the hybrids gives the bound in + We prove SM-DP+-side unforgeability for the game in Fig. 13. The Theorem 1. The SMDP view is handled identically, with Hpid, ℎ cert , adversary wins only if the honest SM-DP+ accepts adversarial 𝑇𝑖 , 𝜎cred , and 𝐿spent replacing the MNO-side state. For the PCA view, download material that is not backed by MNO-issued authorisation the only session-visible values are (pk𝑈 , 𝜋bind, PCert𝑈 , expiry); simmaterial for the same (Hpid, ℎ cert ) tuple, or if it accepts a token that ulated 𝜋bind , fresh pk𝑈 , and ephemeral certificate indistinguishabilhas already been spent. ity remove dependence on the underlying eUICC identity. Let ℎ ∗cert ← 𝐻 ′′ (PCert𝑈∗ ). D.2 Proof of Theorem 2 Case 1: Authorisation credential forgery. Suppose SM-DP+ We prove MNO-side unforgeability for the game in Fig. 13. The ad∗ , but there is no matching MNO-issued authorisation accepts 𝜎cred versary wins only if the honest MNO accepts an adversarial request ∗ ∗ ∗ tuple (𝑥 , PCert𝑈 , 𝜋req ) that is not supported by a registered credential, ∗ (Hpid∗,𝑇𝑖∗, 𝜎cred , ℎ ∗cert ) ∈ Qauth . a fresh MNO challenge, and a valid same-eUICC binding. ∗ ∗ Case 1: No valid witness. Suppose the MNO accepts 𝜋req , but If 𝜎cred verifies as an MNO authorisation on the required mesthere is no witness satisfying the request relation 𝑅req . Then an sage containing (Hpid∗, ℎ ∗cert ), then A yields an EUF-CMA forgery adversary BSound against NIZK knowledge soundness is obtained against the signature scheme used for 𝜎cred . This case is bounded directly: it runs the unforgeability game for A and, upon receivby ∗ ) as its soundness ing an accepting false proof, outputs (𝑥 ∗, 𝜋req Adv𝜎EUF-CMA (𝜆). cred violation. Hence this case is bounded by Case 2: Token forgery. Similarly, if 𝑇𝑖∗ verifies as a valid onetime token for the required message containing (Hpid∗, ℎ ∗cert ) but AdvSound-ZK BSound (𝜆). was not issued by the MNO authorisation oracle, then A gives an Case 2: Credential forgery. By knowledge soundness, from any EUF-CMA forgery against the token-signing scheme. This case is accepting proof with a valid witness one can extract, among other bounded by ∗ ∗ values, an eligibility credential 𝜎EID and an identifier EID . If Adv𝑇EUF-CMA (𝜆). 𝑖 EID∗ ∉ Qreg but 𝜎EID∗ verifies under pk MNO , then A has produced Case 3: Replay or double spending. If the tuple was honestly a credential that was never issued by the registration oracle. This issued, then acceptance is still unauthorised when𝑇𝑖∗ ∈ 𝐿spent before gives a credential-forgery adversary BCred by forwarding registhe adversarial attempt is processed. This is exactly a failure of the tration queries to the credential-issuance oracle and outputting stateful spent-token check, whose probability is (EID∗, 𝜎EID∗ ) when A succeeds. The probability of this case is bounded by AdvDS (𝜆). AdvUF-Cred (𝜆). BCred the adversary has queried the corresponding random-oracle inputs. Since pid1, pid2 are uniform and independent in Game3 , the probability of hitting either pseudonym input is at most 2𝑞𝐻 /2𝜆 . Thus, 2𝑞𝐻 Pr[Win4 ] − Pr[Win3 ] ≤ 𝜆 . 2 Game5 : Independent pseudonym certificates. Replace each PCert𝑈 ,𝑠 with a fresh pseudonym certificate whose public metadata is distributed identically but is independent of EIDidx𝑠 (b) . By ephemeral certificate indistinguishability,

ZK-eSIM: A Privacy-Centric Zero-Knowledge Approach for eSIM Provisioning

CCS ’26, November 15–19, 2026, The Hague, Netherlands

Table 4: Analysis of the erosion of privacy and the sustained security and privacy safeguards across different collusion scenarios. Case

Additional information revealed

Not Supported design goals (§4)

Supported design goals (§4)

No collusion

No additional information

None

DG1–DG6; provisioning correctness

MNO–SM-DP+

Subscriber identity and EID linked to profile-order and provisioning records

DG2, DG4–DG6

DG1, DG3; provisioning correctness

MNO–PCA

Subscriber identity and EID linked to pseudonymcertificate issuance and the corresponding profile request

DG2, DG4–DG6

DG1, DG3; provisioning correctness

SM-DP+–PCA

Pseudonym-certificate issuance linked to the corresponding provisioning session

None

DG1–DG6; provisioning correctness

Full collusion

Subscriber identity and EID linked to the complete infrastructure record of the provisioning session

DG2, DG4–DG6

DG1, DG3; provisioning correctness

Case 4: Hash rebinding. The remaining possibility is that A reuses honestly issued authorisation material but attaches it to different underlying values. If a different pseudonym pid ≠ pid∗ yields the same Hpid, then this is a collision in 𝐻 ′ . If a different certificate PCert𝑈 ≠ PCert𝑈∗ yields the same ℎ cert , then this is a collision in 𝐻 ′′ . Hence this case is bounded by CR CR Adv𝐻 ′ (𝜆) + Adv𝐻 ′′ (𝜆).

The above cases exhaust all ways in which SM-DP+ can accept an unauthorised or replayed download-side request. Therefore, +

AdvUF-SMDP (𝜆) ≤ Adv𝜎EUF-CMA (𝜆) + Adv𝑇EUF-CMA (𝜆) Π,A 𝑖 cred CR CR DS +Adv𝐻 (𝜆). ′ (𝜆) + Adv𝐻 ′′ (𝜆) + Adv

Collusion Analysis

We use an entity’s view to mean the protocol messages, records, logs, and local state available to that entity during normal operation. Two roles collude when they share these observations and analyse them together. This includes both explicit sharing between separate organisations and deployments in which one organisation operates multiple roles and can access the records of each. Colluding parties remain honest-but-curious: they follow ZK-eSIM as specified, but may combine all information available to them to infer subscriber identity or link provisioning sessions. As shown in Table 4, we compare no collusion, pairwise collusion, and full collusion among the MNO, SM-DP+, and PCA, and examine what additional information is exposed in each case and which design goals in §4 remain satisfied.

corresponding profile-order and provisioning records. The shared 𝐻𝑝𝑖𝑑 connects the MNO’s OrderProfile state to the SM-DP+ state, allowing the subscriber and EID to be associated with the corresponding ICCID and provisioning session. Since the same EID can identify repeated sessions, DG2, DG4, and DG5 no longer hold. The intended MNO–LEA separation in DG6 is also bypassed. DG1, DG3, and provisioning correctness remain. MNO–PCA collusion. The PCA observes 𝑃𝐶𝑒𝑟𝑡𝑈 when issuing the short-lived certificate, and the MNO observes the same certificate in ZKRequest. Combining these records associates the certificate issuance and profile request with the subscriber and EID shared by the MNO. Repeated sessions can then be associated through that EID, so DG2, DG4, and DG5 fail, and DG6 is bypassed. The SM-DP+’s ICCID and provisioning records remain outside this combined view. DG1, DG3, and provisioning correctness remain. SM-DP+–PCA collusion. The PCA records the issuance of PCert𝑈 , while the SM-DP+ observes this PCert𝑈 when it is used for provisioning. If SMDP+ and PCA collude, by sharing these records, the SM-DP+ and PCA can link a certificate issuance to the specific provisioning session. However, neither entity has the MNO’s subscriber–EID record, so this linkage does not reveal the subscriber or EID. Since a fresh PCert𝑈 , Hpid, and authorisation material are generated for each session, their combined records do not provide a persistent identifier for linking different provisioning sessions. DG1–DG6 and provisioning correctness therefore remain, while the privacy separation between certificate issuance and provisioning is lost.

Case 1: No collusion. This is the baseline honest-but-curious model of ZK-eSIM. The MNO knows the subscriber and EID from Phase 0.a, but subsequent provisioning uses fresh pid, 𝑃𝐶𝑒𝑟𝑡𝑈 , 𝐻𝑝𝑖𝑑, and one-time authorisation material instead of a persistent provisioning identifier. The SM-DP+ and PCA therefore receive no subscriber identity or EID through their normal protocol views, and separate provisioning sessions remain unlinkable under the analysis of Sec. 8. DG1–DG6 and provisioning correctness hold in this case.

Case 3: Full infrastructure collusion. When the MNO, SM-DP+, and PCA share their records, the common session values connect all provisioning stages. PCert𝑈 connects CertInit with ZKRequest and MutualAuthAndProvision, while Hpid connects the MNO’s OrderProfile state with the SM-DP+ provisioning state. Together with the subscriber and EID shared by the MNO, the parties can associate the subscriber with the pseudonym certificate, profile request, profile order, ICCID, and provisioning session. DG2, DG4, DG5, and DG6 therefore fail. DG1, DG3, and provisioning correctness remain.

Case 2: Pairwise collusion. The privacy degradation depends on which two parties share their records. MNO–SM-DP+ collusion. The MNO contributes the subscriber and EID associated with the session, while the SM-DP+ contributes the

Retained security and correctness. The collusion considered here changes the information available to the infrastructure parties, but not their protocol behaviour. The checks in ZKRequest, OrderProfile,

CCS ’26, November 15–19, 2026, The Hague, Netherlands

and MutualAuthAndProvision are still performed, including authorisation verification, one-time-token checking, authenticated key establishment, and profile confidentiality and integrity. Consequently, DG1 and DG3 remain satisfied in all cases. Provisioning correctness is also unchanged: an authorised profile is installed on the intended eUICC, the corresponding token is accepted only once, and the MNO and SM-DP+ maintain consistent records.

Open Science

In accordance with open science principles, we make our code available through the link: https://github.com/NaivEPoi/ZK-eSim. In this repository, we provide: (i) Our modified GSMA compliant SM-DP+ server - adapted from [36] to accommodate ZK-eSIM; (ii) A LPA implementation [16] extended to provide alternative RSP flows for our scheme; (iii) A Java Card applet that interfaces with the previous artefacts to complete the full RSP process flow. These artefacts enable the complete reproduction of our results and the extension of our work to further enhance privacy in the eSIM ecosystem.

Ahmad et al.

Ethical Considerations

ZK-eSIM addresses a concrete privacy risk in eSIM provisioning: persistent device identifiers and certificate material can enable cross-session and cross-operator tracking. The main benefit of our work is therefore defensive, namely reducing unnecessary identifier exposure while preserving profile-delivery security and accountable traceability. At the same time, stronger provisioning privacy could be misused if deployed without operational safeguards. We mitigate these risks by requiring valid operator-issued eligibility credentials, one-time tokens, replay checks, and short-lived pseudonym certificates, and by designing traceability so that no single party can deanonymise a user unilaterally; identity recovery requires a scoped legal process and joint LEA–MNO cooperation. Our evaluation uses a controlled test-bed with test eUICCs and modified open-source RSP components; we do not access production carrier infrastructure, disclose carrier secrets, collect subscriber telemetry, or use human-subject data. Any real deployment should undergo operator, standards-body, and jurisdiction-specific legal review.

Record · ID 667924 · SHA-256 802a89738cb2b040
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.