Process-Aware Selective Disclosure and Identity Unlinkability: A Tag-Based Interoperability-Enhancing Digital Identity Framework and Its Application to Logistics Transportation Workflows

Abstract

This paper proposes a process-aware, tag-based digital identity framework that enhances interoperability while enabling identity unlinkability and selective disclosure across multi-party workflows involving sensitive data. We realize this framework within the self-sovereign identity (SSI) paradigm, employing zk-SNARK–based zero-knowledge proofs to enable verifiable identity authentication without plaintext disclosure. The framework introduces a protocol-tagging mechanism to support multiple proof systems within a unified architecture, thereby enhancing SSI scalability and interoperability. Its core innovation lies in combining identity unlinkability and process-driven data disclosure: derived sub-identities mitigate identity-linkage attacks, while layered encryption enables selective, stepwise decryption of sensitive information (e.g., delivery addresses), ensuring participants access only the minimal information necessary for their tasks. In addition, zero-knowledge proof-based verification guarantees that the validation of derived sub-identities can be performed without sharing any plaintext attributes or identifying factors. We applied the framework to logistics, where sub-identities anonymize participants and layered encryption allows for delivery addresses to be decrypted progressively along the logistics chain, with only the final courier authorized to access complete information. During the parcel receipt process, users can complete verification using derived sub-identities and zero-knowledge proofs alone, without disclosing any real personal information or attributes that could be linked back to their identity. Trusted Execution Environments (TEEs) ensure the authenticity of decryption requests, while blockchain provides immutable audit trails. A demonstration system was implemented, formally verified using Scyther, and performance-tested across multiple platforms, including resource-constrained environments, showing high efficiency and strong practical potential. The core paradigms of identity unlinkability and process-driven data disclosure are generalizable and applicable to multi-party scenarios involving sensitive data flows.

1. Introduction

As digital society continues to evolve, users are becoming increasingly intertwined with the digital services they rely on. Yet, frequent data breaches have raised growing concerns over the security of personal information. Self-Sovereign Identity (SSI), a paradigm that returns control of data to the individual, has emerged as a promising direction. However, as existing SSI systems move from theoretical concepts toward large-scale real-world deployment, several critical shortcomings remain:

• Potential leakage of users’ plaintext data

Although SSI emphasizes user control over personal information, many existing implementations—outside of those using zero-knowledge proofs—still rely on encryption [1,2] and access-control mechanisms [3,4] applied directly to raw data. As a result, plaintext may continue to circulate within the system and often lacks fine-grained controls for selective disclosure. This “if accessible, then potentially exposable—with insufficient controls” pattern leaves sensitive user information vulnerable during storage, transmission, and processing.

2.

Limited cross-protocol interoperability

The current SSI ecosystem is fragmented, with numerous coexisting protocols and cryptographic schemes. Due to the absence of a unified interoperability framework, secure cross-domain data sharing and verification remain difficult. In practice, this often forces stakeholders to fall back on centralized, low-security data-exchange models—contradicting the very principles that SSI aims to advance.

3.

A mismatch between static privacy protections and dynamic business workflows

Many SSI solutions provide only static privacy protections and do not adapt data-disclosure controls to match the changing needs of real-world workflows. This mismatch often results in either too much information being disclosed or privacy being compromised to meet procedural requirements, revealing the absence of a process-aware, dynamically minimized disclosure system.

To address the challenges outlined above, this paper proposes an innovative and practical SSI framework that establishes a coordinated privacy-enhancing architecture that deeply integrates the principles of identity de-linkability and process-aware minimal data disclosure. Our key contributions are as follows:

• Global privacy-preserving data sharing via zero-knowledge proofs

We build the trust foundation of our system using zk-SNARKs [5,6], enabling privacy-sensitive data verification within a zero-knowledge environment. This approach shifts the security model from simply controlling the flow of plaintext to substantially reducing the circumstances under which plaintext must appear, thereby lowering the risk of exposure at its source.

2.

Improved interoperability enabled by protocol tagging

We introduce a novel protocol-tagging mechanism that transforms the framework into a pluggable “protocol hub.” This design enables dynamic integration of heterogeneous SSI schemes without compromising the unique features of each system. It effectively resolves the long-standing interoperability barrier in the SSI ecosystem and paves the way for large-scale, cross-system identity federation.

3.

An integrated “identity–data–process” privacy-preserving paradigm

For business scenarios that necessarily involve selective plaintext disclosure, we introduce a technical enhancement that tightly couples anonymous identities (via derived sub-identities), hierarchically encrypted data objects, and workflow states into a unified architecture. This design ensures that privacy protection is not an add-on feature but an inherent component of the core business logic.

This study contributes to advancing self-sovereign identity (SSI) by designing and proposing a data protection system based on SSI and layered encryption to address privacy breaches and identity-linkage attacks in multi-party collaborative business processes. The core idea of this system is to return control of data to users, enhancing privacy through two key technical mechanisms. First, identity anonymization and unlinkability: by using decentralized identifiers (DIDs) and their derived sub-identities in place of traditional personal identifiers such as names or phone numbers, participants in business processes are prevented from linking activities across different stages to the same individual. Second, selective and process-driven data disclosure: critical information, such as delivery addresses, is segmented and encrypted, and cryptographic mechanisms ensure that each participant along the workflow can only decrypt the minimal data necessary to complete their task, achieving gradual disclosure under a “need-to-know” principle.

This technical framework is highly generalizable. For example, in logistics and delivery scenarios, the system ensures that only the final courier can access the complete address, while intermediate nodes can only see information relevant to the next step. This paradigm can be applied broadly in other domains:

• Supply Chain Management and Traceability

In cross-border goods flows, sub-identities protect the commercial relationships among suppliers, logistics providers, and distributors, preventing leakage of core partner information. Product data (e.g., composition, origin, purchase price) can be encrypted in layers: customs can decrypt only the product category and value needed for clearance; quality inspection departments can access composition and origin layers; and end retailers receive only the description layer necessary for sales. This enables fine-grained management of commercially sensitive information.

2.

Healthcare Data Interoperability

Patients, as the owners of their health data, can use a primary DID to manage different sub-identities and electronic medical records across multiple healthcare institutions, safeguarding privacy. During cross-institution consultations, patients can authorize specialist hospitals to decrypt only the layers of reports relevant to their diagnosis and treatment, while personal identifiers and unrelated medical history remain encrypted. Similarly, insurance companies processing claims can access only the diagnostic results and cost layers directly relevant to the claim, without seeing the patient’s full medical record.

3.

Government Cross-Department “One-Stop Services”

When individuals or businesses apply for comprehensive services, redundant submission of materials and excessive data collection can be avoided. For example, when applying for government subsidies, identity data is accessible only to public security authorities for verification; financial data is open only to tax authorities for review; and qualification documents are accessible solely to the relevant administrative department. Departments can collaborate efficiently without direct data sharing, fundamentally eliminating “data silos” and privacy risks.

4.

Financial Services and Joint Risk Control

In scenarios requiring joint credit assessments or anti-money laundering checks across multiple institutions, users’ identity and transaction data can be encrypted and segmented. Each participating institution can decrypt and verify only the data dimensions relevant to its risk models (e.g., Institution A verifies income statements, Institution B verifies asset proofs) without accessing the full client profile, thereby enabling collaborative risk control while fully adhering to the principle of data minimization.

5.

IoT Data Element Circulation

In smart connected vehicles, industrial IoT, and other scenarios, massive operational data (e.g., location, performance, energy consumption) represents core value. Under this framework, data owners can encrypt their data and authorize different analytics service providers. Each provider can decrypt only the specific data dimensions they have purchased or are authorized to use, enabling secure and controlled market circulation of data elements while preserving data sovereignty.

These application examples demonstrate that the proposed technical architecture is not limited to addressing privacy challenges in the logistics industry. Rather, it provides a general technical blueprint for building a distributed data collaboration ecosystem that combines trust, efficiency, and privacy protection. Due to space constraints, this study focuses on exploring and discussing the application of this core approach in the logistics and transportation domain:

✓

Leveraging this paradigm, we design and implement a complete solution for a complex logistics delivery workflow. User identities are anonymized through dynamic sub-identities; the delivery address is encapsulated as a cryptographic envelope whose decryption authorization is bound to the parcel’s physical transit states, enabling on-demand, step-wise “peeling” decryption aligned with operational progress. This ensures that sensitive personal attributes such as the user’s real name and phone number never appear throughout the entire process, while the full address is visible only to the seller and the final delivery courier. All intermediate couriers can access only the minimal address fragment required for their task, achieving strict selective and minimized disclosure.

✓

All critical workflow operations (e.g., decryption authorization and state transitions) are immutably recorded on a blockchain, providing strong auditability and accountability while maintaining maximal privacy protection.

In current practice, complete address information, along with the recipient’s real name and phone number, is often stored and transmitted in plaintext across multiple systems. In large-scale logistics ecosystems, multiple independent participants are involved, such as collection points, sorting centers, outsourced courier companies, and IT service providers. Not all participants require access to the full delivery address or the recipient’s identity information to perform their tasks. Granting full user information indiscriminately to all participants significantly increases the risk of data leakage and misuse—risks that are frequently observed in real-world logistics operations. Such data may be recorded, copied, or aggregated beyond their original operational purpose, creating serious privacy threats. These include internal misuse or resale of names and phone numbers leading to telecom fraud, profiling and tracking based on delivery addresses or recipient identities, and phishing or cash-on-delivery scams exploiting leaked address information. Our proposed paradigm mitigates these risks effectively.

2. Theoretical Background

2.1. Trusted Execution Environment (TEE)

A Trusted Execution Environment (TEE) provides a hardware-based secure enclave within the processor that ensures the confidentiality and integrity of code and data, even if the host operating system is compromised [7,8]. Representative implementations include ARM TrustZone [9,10,11], Intel Software Guard Extensions (SGX) [12,13], and AMD Secure Encrypted Virtualization (SEV) [14]. TEEs have been widely adopted in security-critical applications such as mobile payments, digital rights management, and confidential cloud computing. By isolating sensitive operations—such as cryptographic key management, authentication, or secure data processing—from the untrusted host environment, TEEs reduce the attack surface and establish a foundation for trusted services. In our work, we leverage existing TEEs as the identifier and processor for SSI tags. Functioning analogously to an intelligent router, the TEE is responsible for recognizing SSI tags and determining the appropriate forwarding routes for associated SSI data, while deliberately avoiding any direct processing of SSI protocol data or storage of user information, thereby preserving the decentralized design principles of SSI architectures.

In this study, the relevant TEE is planned to be deployed in the cloud and will not be affiliated with any courier company. This neutral deployment leverages the cloud platform’s wide network accessibility and rapid scalability, ensuring reduced risk of single points of failure and effective interconnection across diverse network environments. At the same time, it helps prevent potential process disruptions or circumvention of protocols that might arise if the TEE were operated under a specific courier company. Through this design, the TEE serves as a trusted execution and enforcement component that assists users in securely performing decryption and selective disclosure under clearly defined conditions, while enhancing the interoperability of SSI protocols through a tag-based mechanism.

2.2. Selective Disclosure

Selective disclosure is a mechanism for protecting the privacy of individuals and organizations. It can be regarded as a privacy-by-design pattern that strengthens both privacy and security [15]. When implemented, it offers several key benefits [16]:

✓

Data minimization—by sharing only the minimum necessary information, it reduces the amount of data collected and lowers the risks of data breaches and privacy violations;

✓

Enhanced user trust—by allowing users to control their own data and decide what information to share, it fosters stronger trust relationships;

✓

Access control—by enabling users to determine who can access their data and under what conditions, it provides fine-grained control over resource access.

2.3. Self-Sovereign Identity (SSI)

Self-sovereign identity (SSI) marks a new phase in the development of user-centric identity management, placing the user firmly at the heart of the process. SSI guarantees that users’ identities can seamlessly operate across multiple platforms—with their explicit consent—while giving them precise control over their digital identities. This approach empowers users with true autonomy, allowing them to manage their identity data and decide when, how, and with whom to share it [17].

Under a self-sovereign identity (SSI) standards framework [18], a technically compliant system should include the following essential components:

Decentralized Identifier (DID): A DID is a globally unique identifier used to designate a subject (such as an individual, organization, or device). It is designed to be resolvable to a corresponding public key, service endpoints, and other metadata. DID resolution information is typically anchored on a blockchain or Distributed Ledger Technology (DLT) to ensure its immutability and verifiability.

DID Document: The DID Document contains metadata related to the DID, including public keys, verification methods, and service endpoints. It serves as the “instruction manual” for the DID, providing the foundational information necessary for identity authentication and credential exchange.

Verifiable Credential (VC): A VC is a digitally signed statement issued by a trusted Issuer to a Holder (the subject). It is used to attest to certain attributes or facts, such as educational degrees, age, or professional certifications. The credential itself can be cryptographically verified for both its authenticity and integrity.

Verifiable Presentation (VP): A VP is generated by the Holder to present one or more VCs to a Verifier. The VP supports selective disclosure, meaning the Holder can choose to only present the necessary information while still guaranteeing the verifiability of the underlying credentials, thereby enhancing user privacy.

Auxiliary Components: These include essential supporting elements such as Credential Revocation Registries, DID Resolvers, Identity Wallets (or “Wallets”), and cryptographic algorithms (e.g., digital signatures, Zero-Knowledge Proofs). These components collectively ensure the security, verifiability, and user control of the identity information.

Building on these foundational components, an SSI-compliant system should also adhere to key principles such as autonomy, user control, and minimal disclosure. These principles are commonly derived from Christopher Allen’s Ten Principles of Self-Sovereign Identity [19], with five widely emphasized principles highlighted below:

• Existence: Identity must belong to real individuals rather than systems or institutions.
• Control: Users must be able to control their own identity data, including creating, using, and revoking credentials.
• Access: Users must have continuous and unobstructed access to their own data; such access should not be locked or restricted by platforms or custodians.
• Minimization: Only the minimum necessary data should be disclosed (minimal disclosure/selective disclosure).
• Protection: The system must safeguard users’ rights, privacy, and freedoms, preventing identity misuse or surveillance; in other words, protection must operate at both technical and social levels.

At the end of the Methodology section, we will further examine how these principles are implemented in our design, thereby effectively demonstrating our ability to meet the requirements of SSI.

In terms of workflow, it must support the three core interactions of the SSI model: issuance (where an issuer provides a VC to a holder), holding (where the holder manages VCs and constructs VPs), and verification (where a verifier checks a VP or VC presented by the holder).

In this study, we rely on our previous work, NSSIM [20], to fulfill the technical requirements of SSI-related components and to move towards an SSI-aligned system architecture. Based on this framework, each individual is assigned a unique decentralized identifier (DID), from which multiple sub-identities can be automatically derived. These sub-identities serve as the user’s unique identifiers (UIDs) throughout the logistics process. This design inherently provides unlinkability: front-end entities (such as courier companies or logistics providers) cannot easily associate multiple UIDs with the same individual, while back-end regulatory attributes tied to a natural person remain preserved. In other words, government and authorized regulatory bodies can still identify the individual behind a UID—when legally required—by tracing it back to the corresponding DID, thereby enabling accountability.

From a procedural perspective, the seller acts as the issuer and performs the issuance process by providing the user with a one-time code, which serves as one of the receipt authentication elements. This one-time code can be viewed as a lightweight verifiable credential (VC) in the context of the logistics workflow. The user, acting as the holder, receives this code and, together with the UID, generates a zero-knowledge-proof–based delivery-confirmation credential. This credential functions as a verifiable presentation (VP) that is provided to the verifier. The courier, serving as the verifier, validates the VP by checking the corresponding zero-knowledge proof, thereby confirming the authenticity of both the VP and the underlying VC.

Through this workflow, the proposed design supports the three core SSI interactions—issuance, holding, and verification—while steadily progressing towards the foundational SSI principles of autonomy, user control, and minimal disclosure.

2.4. Interoperability

Interoperability refers to the ability of different systems, platforms, or applications to seamlessly and efficiently communicate, exchange, and utilize information.

To achieve interoperability, the design must address four distinct layers [21]:

System Layer: The most fundamental layer, system-level interoperability addresses incompatibilities between hardware and operating systems during the technical exchange of data over networks, computers, and applications, ensuring that relevant applications can interact smoothly within the same environment.

Syntactic Layer: This layer focuses on the uniformity of data structures and encoding formats, ensuring that systems can correctly parse and read exchanged data.

Structural Layer: This layer concerns the consistency of the internal organization and relationships of data, i.e., whether the information models are aligned. For example, whether fields, attributes, and data models correspond correctly across systems.

Semantic Layer: This layer addresses the consistency of the meaning and interpretation of data, i.e., whether different systems understand the same data in the same way. For instance, whether “apple” is interpreted as a fruit in one system but as a brand in another.

Given the diversity of existing SSI protocols and systems, the semantic, syntactic, and structural layers are often complex and difficult to unify. To achieve broad compatibility and interoperability, this study adopts an integration approach at the system layer, utilizing a Trusted Execution Environment (TEE) as the interaction medium. This allows various SSI protocols and systems to be integrated and executed within the framework of the proposed research.

3. Related Work

Current SSI systems in the industry include Sovrin [22,23,24] and ShoCard [25]. Sovrin focuses on standardizing Self-Sovereign Identity (SSI) and building the necessary infrastructure by leveraging blockchain to store decentralized identities. In theory, anyone can create or verify an identity. Sovrin’s SSI model does not depend on any specific distributed ledger and is compatible with any blockchain that meets the required attributes. All private data is stored off-chain by each SSI owner, who decides where to keep it. However, this setup also allows users who are not fully security-conscious to share plaintext information. Many users may not fully understand the implications of sharing unencrypted data or the importance of protecting their digital identity. This gap in understanding can lead to unintentional privacy leaks. Sovrin relies on legal frameworks like the GDPR to restrict the misuse of information, but this is not always effective. Due to the lack of fine-grained selective-disclosure controls for plaintext in certain scenarios, Sovrin may still face potential risks of insufficient data minimization or unintended information exposure in practical deployments—particularly in situations where different parties require access to different levels of information but the system does not provide a tiered authorization mechanism. Under the immense pressure of technical challenges and regulatory constraints, Sovrin’s operations became increasingly difficult, leading to its shutdown on 31 March 2025 [26].

ShoCard is a blockchain-based digital identity and authentication platform. Users’ identity information is stored on the blockchain as signed, encrypted hashes. Identity verification handshakes are initiated between users and third parties directly on the blockchain. The information is contained within secure data packets that only the intended recipient can decrypt. This approach enables users and third-party entities to securely and verifiably confirm each other’s identities and exchange additional data.

However, this method does not fully eliminate the risk of data leakage. Although shared data is transmitted in an encrypted form, third parties can ultimately decrypt it and access the plaintext information. Without appropriate selective-disclosure controls over such plaintext sharing, there may be an increased risk of privacy exposure. ShoCard has since been rebranded as PingOne [27] and is now operating commercially; nevertheless, the similar underlying design continues to raise related security concerns.

uPort is a decentralized identity system that enables users to establish their digital identities—known as uPortIDs—on the Ethereum blockchain [28]. The platform empowers users to manage the creation of their identities and to control when and how personal data is shared with third parties. Instead of storing information on a central server, uPort ensures that personal data resides on the user’s device and in off-chain locations chosen by the user, allowing for consistent access and control.

By design, uPort shifts both the authority and responsibility of identity management to the user [29,30]. However, uPort allows users to generate and use multiple DIDs (uPort IDs), which may complicate regulatory monitoring. Moreover, uPort does not incorporate privacy-by-design features tailored to specific real-world use cases, which limits its practical applicability in deployment scenarios.

Veramo is a new developmental iteration of uPort and remains under active development [31]. It offers an open-source library featuring modular APIs for Self-Sovereign Identity (SSI) and verifiable data [32,33]. However, due to the similarities in their underlying design, many of the same issues persist.

DT-SSIM provides a decentralized and trusted Self-Sovereign Identity (SSI) management framework tailored for the Internet of Things (IoT) environment [34]. The framework aims to enhance the security and decentralization of identity management in IoT systems by integrating secret sharing and blockchain technologies. By leveraging distributed storage of identity credentials, DT-SSIM improves the protection of these credentials and reduces the risks associated with centralized storage.

While decentralized storage helps mitigate issues related to data monopolies, DT-SSIM still lacks key control mechanisms to address common challenges in SSI systems—such as plaintext data exposure, the absence of real-world application scenarios, and insufficient oversight in data usage contexts.

PT-SSIM is an updated version of DT-SSIM that introduces a frequent identity-sharing update mechanism to strengthen the protection of users’ digital identities. This approach helps reduce the risk of data collection, linkage attacks, aggregation, and inference attacks [35]. However, it still falls short in addressing privacy leakage and lacks robust design considerations for real-world application scenarios.

SISSI is a network authentication and authorization system built on Self-Sovereign Identity (SSI) principles, designed to achieve semantic interoperability across diverse SSI implementations [36]. Its architecture demonstrates how web-based SSI technologies can effectively support access control while offering stronger end-to-end performance than many blockchain-based alternatives. While SISSI successfully enables cross-domain identity recognition and integrates well using web protocols, it gives limited attention to privacy concerns, raising the risk of data exposure due to potential plaintext data handling in real-world applications.

De Salve et al. proposed a privacy-preserving shipping verification system based on Self-Sovereign Identity [37]. By leveraging SSI and blockchain technologies, the system aims to ensure both transparency in supply chain management and protection of user privacy, allowing the tracking of goods without exposing sensitive information. In this approach, the marketplace acts as a trusted issuer, providing verifiable credentials to both couriers and customers. These credentials are used to confirm whether a courier is authorized to place a package into a designated locker and whether a customer is authorized to retrieve it. The verification process relies on blockchain transaction records, ensuring data integrity and transparency. However, the system has notable limitations: couriers can only deliver packages to lockers rather than directly to customers, using lockers as a means of preserving user privacy—this may compromise the overall user experience. In addition, the scheme appears to allow each user to register only a single DID with limited variability, which may increase the risk of identity linkability. Moreover, there is room for further improvement in supporting regulatory oversight.

Sun et al. proposed a privacy-preserving Self-Sovereign Identity (SSI) scheme based on one-time-use tokens and fuzzy identity-based encryption (Fuzzy-IBE), aiming to address privacy leaks in logistics caused by account reuse and direct linkage of digital identities [38]. The scheme has certain limitations in terms of regulatory design and could be further improved in its coordination with other SSI protocols.

4. Methodology

As a universal “identity–data–process” integrated privacy-preserving paradigm, our design draws partly on concepts from federated identity management [39,40,41] and the MPLS (Multiprotocol Label Switching) protocol [42,43,44,45]. By assigning each SSI protocol a unique protocol label, our approach enables broad system-level interoperability with diverse SSI frameworks. By default, the system adopts an SSI protocol with zk-SNARKs support to ensure strong protection of user privacy.

We further introduce a Trusted Execution Environment (TEE), which operates as a node responsible for reading and forwarding SSI protocol labels. The TEE functions similarly to a centralized access point in federated identity systems. However, unlike traditional centralized nodes, the TEE does not impose mandatory participation in digital identity verification or data-sharing validation. This design prevents the TEE from becoming a data monopolist and maintains alignment with SSI’s decentralization principles. Meanwhile, as a trusted execution mechanism, the TEE securely performs decryption and selective disclosure on behalf of the user under explicitly defined conditions, thereby enabling data selective disclosure driven by changes in business process states.

To clearly convey the proposed integrated and privacy-preserving general paradigm, Figure 1 illustrates its overall operational logic and execution flow. Different colored execution paths are used to distinguish the two aforementioned functions of the TEE and to demonstrate the auditability of the corresponding log traces.

Figure 2 further presents the logical component architecture of the proposed paradigm, providing a clearer illustration of the internal logic required to realize the above execution steps.

This paradigm’s component framework is highly versatile. In this paper, we focus on exploring its practical applicability in the logistics and transportation domain, detailing the corresponding procedures and implementation methods. Based on the business logic of logistics operations, we further incorporate the concept of link-by-link encryption into the above universal paradigm [46,47]. The delivery address is divided into multiple hierarchical components—such as country, city, district, and street—and each layer is encrypted independently. During parcel delivery, the address information is progressively decrypted according to the operational workflow and the requirements of each distribution stage. This ensures that every transit node learns only the next routing destination without accessing the recipient’s full address, thereby effectively preserving user privacy.

In addition, we introduce a mechanism that binds each courier to their respective device and places the address-decryption process under the supervision of a regulatory authority. This guarantees compliance throughout the delivery process while maximizing privacy protection. To provide a clearer and more detailed description of how the proposed paradigm can be applied in the logistics sector, we present the symbols and their meanings in

Table 1. Names and Descriptions of the Symbols Used in Section 4.

Symbol	Description
PubX	The public key of a particular entity. For example, PubU represents the User’s public key.
PriX	The private key of a particular entity. For example, PriCC represents the courier company’s private key.
SK	A temporary cryptographic key used to encrypt and decrypt messages within a single communication session.
UID	Stands for User Digital Identity ID. In our design, users can apply for or derive multiple digital identities (IDs) under their primary SSI, helping to resist tracking and profiling attacks.
SID	Stands for Seller ID. It is unique to each seller.
CSID	A unique identifier assigned to each courier employee. It is used to track delivery personnel, record operations, and ensure accountability throughout the delivery workflow.
CCID	A unique code that identifies each logistics service provider. This ID helps distinguish between different companies participating in the logistics network.
SDID	A unique identifier for each QR code scanner device used in the field. It ensures that all scanning activities can be traced back to a specific device for auditing and security purposes.
CID	Content Identifier. A hash-based, content-addressed ID generated by Interplanetary File System (IPFS) to uniquely reference stored data.
TN	Stands for Tracking Number, and each number is unique.
SA	The destination address where goods or packages are to be delivered.
PP	Stands for Public Parameters, which are globally shared values generated during the setup phase of a zero-knowledge proof system. These parameters are used by both the prover and the verifier to construct and verify proofs. Public parameters may include cryptographic constants, commitment keys, and circuit-related configuration values. They do not contain any secret information and can be safely published.
W	Represents the Witness, which refers to the private input(s) known only to the prover in a zero-knowledge proof. The witness satisfies the conditions defined by the computation or circuit and is used to generate a valid proof without revealing the underlying secret. It typically includes confidential data that the prover wants to prove knowledge of, such as passwords, credentials, or hidden values, while preserving privacy.
Ts	Timestamp.
ADFN	Refers to the sequence number assigned to each fragment when a complete address is divided into multiple parts. The ADFN uniquely identifies the position of each fragment, making it easier to track and manage the individual pieces of the address.
ADF	Refers to a single segment or portion of the full address after it has been split. Each ADF represents an actual fragment of the address data, and together they compose the complete address.
SVC	A one-time code provided to the recipient, which can serve as one of the delivery-verification factors to facilitate an efficient and reliable pickup process.
SSIPT	Represents different identifiers for each SSI protocol. In our design, TEE will decide how to forward the relevant SSI data request to the corresponding blockchain based on this identifier.
Proof	A proof is a cryptographic artifact generated to verify that a statement is true without revealing any extra information. In zero-knowledge proofs, it enables one party to prove knowledge of a secret without exposing the secret itself.
VRes	The outcome of a verification process.

and outline a 20-step workflow. The logical sequence of these steps is illustrated in Figure 3.

Step 1: The courier binds the CSID to the QR code scanner and associates it with a specific courier company.

Step 2: The courier company uploads the following information to the courier equipment registration chain: CSID, courier company ID(CCID), code scanning device ID(SDID), and device public key PubSD. When uploading, the PubSD, CCID and SDID are digitally signed using the courier company’s private key PriCC. The specific format is as follows:

{CCID, SDID, PriCC (SDID, CSID, PubSD)}

(1)

We can describe the process with the following symbolic description:

Courier → Courier Equipment Registration Chain:
{CCID, SDID, PriCC (SDID, CSID, PubSD)}

(2)

Step 3: The user derives or applies for a sub-identity under their unique SSI to serve as a UID, places an order online, and provides the seller with the UID and shipping address (SA). The related information is then encrypted and protected using a session key in the following format.

{SK (UID, SA)}

(3)

We can describe the process with the following symbolic description:

User → Seller: {SK (UID, SA)}

(4)

Step 4: The seller provides a new tracking number TN for this shipment, divides the user’s SA into levels such as country, city, district, street and road, assigns the split address fragments ADF to their ADFN values from small to large according to the level from high to low, and encrypts them, respectively, using the TEE public key. The specific format is as follows:

{SID, TN, ADFN, PriSeller(TN, ADFN, PubTEE(ADF))}

(5)

The last address fragment will additionally include a randomly generated Shipping Verification Code SVC, so that the last encrypted package format is as follows:

{SID, TN, ADFN, PriSeller(TN, ADFN, PubTEE(ADF, SVC))}

(6)

Finally, the seller uploads the relevant encrypted address information to the express address storage chain in the following format:

{SID, TN, ADFN1, PriSeller(TN, ADFN1, PubTEE(ADF1))},
    {SID, TN, ADFN2, PriSeller(TN, ADFN2, PubTEE(ADF2))},
……
{SID, TN, ADFNn, PriSeller(TN, ADFN, PubTEE(ADFn, SVC))}

(7)

We can describe the process with the following symbolic description:

Seller → Express Address Storage Chain:
{SID, TN, ADFN1, PriSeller(TN, ADFN1, PubTEE(ADF1))},
{SID, TN, ADFN2, PriSeller(TN, ADFN2, PubTEE(ADF2))},
……
{SID, TN, ADFNn, PriSeller(TN, ADFN, PubTEE(ADFn, SVC))}

(8)

In this process, to reduce the gas cost associated with on-chain storage, the relevant raw data are stored on Interplanetary File System (IPFS) [48,49], while the Express Address Storage Chain records only the Content Identifier (CID) generated by IPFS for the stored data.

Step 5: The seller sends the TN and the SVC to the user, with all data encrypted and protected using the session key in the following format. The SVC is received and stored in the user’s wallet for subsequent use. In addition, the seller provides the user with a timestamp–TN bundle encrypted with the seller’s private key, enabling the user to later prove its legitimacy when submitting the TN and the zero-knowledge-proof public parameter PP to the TEE.

{SK (TN, SVC, SID, PriSeller (TN, Ts))}

(9)

We can describe the process with the following symbolic description:

Seller → User: {SK (TN, SVC, SID, PriSeller (TN, Ts))}

(10)

Step 6: The seller prints the express delivery note, generates a QR code for the TN, and affixes it to the goods to be delivered to the courier.

Step 7: The user uses SVC and UID to generate the zero-knowledge proof public parameter PP and sends PP to TEE. In this step, the user will select and use the SSI protocol that supports the relevant algorithm based on the zero-knowledge proof algorithm used to generate PP, and use the corresponding SSIPT in the sent data packet. The specific data packet format is as follows. During this process, the user will send the TN signature data with a timestamp provided by the seller to TEE to prove the legitimacy of the data upload behavior.

{PubTEE (TN, PP, SSIPT, SID, PriSeller (TN, Ts))}

(11)

We can describe the process with the following symbolic description:

User → TEE: {PubTEE (TN, PP, SSIPT, SID, PriSeller (TN, Ts))}

(12)

Since our design supports multiple SSI protocols, the zero-knowledge proof algorithms used in this step will vary accordingly, resulting in different PP content. For example, in our default SSI protocol design, we use ZoKrates [50,51,52] to perform the zero-knowledge proof computations. In this process, the generated PP is the verification.key file, which is intended for use in the subsequent smart contract verification.

Step 8: The TEE decrypts the data and verifies the legitimacy of the seller’s signature and the freshness of the timestamp based on the SID. If the verification is legitimate, the relevant data is forwarded to the corresponding SSI protocol blockchain for storage and processing based on the SSI protocol type tag SSIPT.

Step 9: The courier uses a QR code scanner to scan the order. The scanner automatically identifies the order number and sends a request to TEE. The request contains the identified order number TN, the current scanner’s SDID, and the scanner’s digital signature. The relevant information is encrypted using the TEE public key. The specific format is as follows:

{PubTEE (TN, SDID, PriSD (TN, Ts))}

(13)

We can describe the process with the following symbolic description:

Courier → TEE: {PubTEE (TN, SDID, PriSD (TN, Ts))}

(14)

Step 10: TEE obtains the public key and courier ID from the courier equipment registration chain based on the SDID of the QR code scanner and uses the obtained device public key to verify the legitimacy of the signature and the freshness of the timestamp.

Step 11: If TEE verifies that the QR code scanning device is legitimate, TEE will go to the express address storage chain to find the address fragment according to the tracking number TN and decrypt the first fragment.

Step 12: TEE stores the information of this scanning behavior in the express behavior log chain. The uploaded information includes the courier’s CSID, the SDID of the device used, the scanned order number TN, the request time, and the ADFN decrypted this time. The relevant data is encrypted using the public key of the regulatory agency. The specific format is as follows:

{TN, ADFN, Ts, PubRA (PriTEE (TN, ADFN, CSID, SDID, Ts))}

(15)

We can describe the process with the following symbolic description:

TEE → Express Behavior Log Chain:
{TN, ADFN, Ts, PubRA (PriTEE (TN, ADFN, CSID, SDID, Ts))}

(16)

Step 13: TEE sends the decrypted fragment address information ADF back to the QR code scanner. The courier can determine the next transfer destination of the package based on the obtained address fragment information. The relevant data sending format is as follows.

{PubSD (TN, ADFN, ADF, PriTEE (TN, ADFN, Ts))}

(17)

We can describe the process with the following symbolic description:

TEE → Courier: {PubSD (TN, ADFN, ADF, PriTEE (TN, ADFN, Ts))}

(18)

During the transfer of the courier, the operation of Step 8–12 will be repeated. During this process, the ADF will be gradually decrypted until only the last ADF is left undecrypted. Currently, the courier is about to enter the delivery stage. All couriers before this have not obtained the complete address information of the courier. To prevent courier companies from attempting to collect or store decrypted address fragments during this process, all QR scanners with a valid SDID are configured in read-only mode and set to auto-delete related data after viewing. In addition, these scanners are reinforced to ensure that they can only send and receive data with specific trusted counterparts, such as the TEE, thereby preventing courier companies from once again becoming monopolists of private data. Throughout this process, the user retains continuous access to and control over their data. The user can at any time request that the TEE reveal the decrypted result of specific data or halt any further decryption of a given address. These actions can be carried out by the user generating the zero-knowledge proof described in Step 14 and submitting it, along with the corresponding TN, to the TEE. If the TEE receives a request directly from the user—rather than from a QR-code scanner—and the request includes both the TN and the zero-knowledge proof, the TEE will retrieve the corresponding SVC fragment from IPFS and decrypt it. Based on the SVC and the verification result of the zero-knowledge proof, the TEE confirms the user’s identity. Upon successful verification, the TEE grants the user data control and access rights. This process remains invisible and unknowable to the courier company and delivery personnel, thereby ensuring that the user’s SSI-based access and control rights are fully maintained.

Meanwhile, considering practical situations in logistics and transportation, this phase may also involve cases where the user requests to modify the delivery address midway, or the seller decides to terminate the transaction and recall the parcel. Such scenarios can be handled by the seller re-uploading newly encrypted delivery/return address fragments using the original TN in the data format described in Step 4. Once the corresponding TN is scanned again at a transit center, the transportation process can proceed according to the updated address. This mechanism ensures that our design effectively takes into account potential unforeseen circumstances in real-world applications.

Step 14: The last courier scans the code to obtain the plaintext information of the last address fragment ADF and the SVC. The courier enters the delivery stage. The user provides the courier with zero-knowledge Proof and SSIPT in QR code format. The relevant QR code contains the following format information:

{PubTEE (TN, Proof, SSIPT)}

(19)

We can describe the process with the following symbolic description:

User → Courier: {PubTEE (TN, Proof, SSIPT)}

(20)

In our default SSI protocol design, the ZoKrates code—illustrated in Figure 4—takes the user’s UID as a private input, and uses the SVC along with the hash of the UID and SVC as public inputs. This setup is used to verify the recipient’s legitimate identity during the parcel delivery process.

In this scenario, assuming the current user’s UID is 13812345678 and the SVC is 987654321, the Python code (tested on Python version 3.10.12) used to generate the public inputs expected_hash_0 and expected_hash_1 in the ZoKrates code is shown in Figure 5.

Once executed, the code produces the hash results displayed in Figure 6.

Based on the output above, the user can locally generate the witness W by running the zokrates compute-witness command with their private input UID and the public inputs SVC, expected_hash_0, and expected_hash_1. Using this witness, the user then executes the zokrates generate-proof command to produce the final zero-knowledge proof file, proof.json. This proof.json is stored in the user’s wallet and later presented to the courier as the Proof during the delivery verification process.

Step 15: The courier obtains the above data encrypted with the TEE public key by scanning the QR code with a QR code scanner. The courier enters SVC on the scanner and sends the relevant information to TEE as a whole. The specific sending format is as follows:

{PubTEE (TN, Proof, SSIPT), PubTEE(SVC, SDID, PriSD(TN, SVC, Ts))}

(21)

We can describe the process with the following symbolic description:

Courier → TEE:
{PubTEE (TN, Proof, SSIPT), PubTEE(SVC, SDID, PriSD(TN, SVC, Ts))}

(22)

The symbolic description in this step reflects our generalizable approach to supporting a variety of SSI protocols and their corresponding zero-knowledge proof schemes. In the default ZoKrates-based zero-knowledge proof implementation, this process is further simplified—couriers are not required to separately submit the SVC.

In this step, the courier receives the proof.json file from the user, which serves as the Proof. Based on the code example provided earlier, the contents of this file are illustrated in Figure 7. The red-boxed sections in the figure display the SVC and the hash of UID and SVC in hexadecimal format. The courier simply scans the QR code using the QR scanner, which automatically extracts the hexadecimal representation of the SVC from the file, converts it into a decimal value, and compares it with the SVC displayed on the device. If the two values match, the Proof can be considered associated with the rightful owner of the current package and is therefore valid for submission to the TEE for zero-knowledge verification. If they do not match, the Proof is deemed invalid and not tied to the current delivery.

In this example, the expected SVC is 987654321, which corresponds to the hexadecimal value 3ade68b1 found in the proof.json. Since the values match, the courier proceeds to submit the Proof to the TEE.

Step 16: TEE decrypts the relevant information, verifies the legitimacy of the QR code scanner signature, and forwards the relevant information to the smart contract of the corresponding blockchain for processing according to SSIPT. If the corresponding SSI protocol does not support smart contracts, or if there is a need to further reduce the economic overhead caused by gas consumption for on-chain verification, the TEE can perform zero-knowledge proof verification off-chain—provided that the user explicitly consents to delegate this verification authority to the TEE.

Step 17: The TEE sends the verification results of the relevant smart contracts, or the off-chain verification results of the zero-knowledge proof public parameters (PP), to the QR code scanner. The data is transmitted in the following format:

{PubSD (PriTEE(TN, VRes/PP, Ts))}

(23)

We can describe the process with the following symbolic description:

TEE → Courier: {PubSD (PriTEE(TN, VRes/PP, Ts))}

(24)

Step 18: The courier decides whether to deliver the goods to the user based on the verification result displayed by the QR code scanner.

Step 19: The TEE stores the delivery event and the corresponding SSI verification results on the Express Behavior Log Chain, serving as proof that the user successfully received the package using a legitimate SSI sub-identity UID and the associated zero-knowledge proof. In this context, the ADFN portion of the log recorded during the delivery process is replaced with a Null placeholder to indicate that this log represents the final delivery record. The sending data format is as follows:

{TN, Null, Ts, PubRA (PriTEE(TN, CSID, SDID, VRes/PP, Ts))}

(25)

We can describe the process with the following symbolic description:

TEE → Express Behavior Log Chain:
{TN, Null, Ts, PubRA (PriTEE (TN, CSID, SDID, VRes/PP, Ts))}

(26)

Compared with traditional processes where the courier directly verifies the user’s identity using the shipping verification code (SVC), incorporating SSI-based identity verification further strengthens the authenticity check of the recipient. This approach prevents impersonation issues that could arise if the SVC were leaked under unforeseen circumstances. Moreover, since the SSI verification relies on zero-knowledge proofs, the user does not need to worry about privacy leakage during the process, effectively safeguarding the confidentiality of the delivery.

By binding the delivery results to the SSI verification and storing the logs on-chain via the TEE, the legitimate rights of both couriers and users are further ensured. In the event of any future disputes regarding receipt, the logs can serve as verifiable evidence of prior actions, guaranteeing the integrity and non-repudiation of the operational process.

Step 20: Since each scan of the QR code scanner will be uploaded to the express behavior log chain by TEE, the regulatory authorities will be able to inspect the relevant scanning behaviors. If it is found that a courier in the non-delivery stage scans the code multiple times to decrypt the complete delivery address, or if other couriers scan the code multiple times to query the complete address after the current waybill has been delivered, it can be considered as malicious behavior. The relevant behaviors will be discovered and punished by the regulatory authorities to prevent user privacy leaks.

In this process, because the Express Behavior Log Chain does not contain any user-related information—nor any data that could be used to infer or link to a specific user—the regulatory authority, or even an attacker who manages to compromise the authority’s private key, cannot use the decrypted logs to trace or identify a user’s private activities.

Moreover, to prevent misuse or unauthorized access to the regulatory authority’s private key by a small subset of personnel, the key can be protected through secret sharing. For example, applying Shamir’s Secret Sharing Scheme ensures that only when a designated threshold of authorized regulators jointly participate can the private key be reconstructed for regulatory duties. This strengthens multi-party control over the key and reduces the risks of insider abuse or key theft.

Through the above design, we have elevated the security and privacy protection of user data in logistics applications to a new level. Under traditional approaches, user data in logistics scenarios faces multiple privacy risks, as illustrated in Figure 8:

➢

Users are required to provide their real names, phone numbers, and addresses to courier companies, which then store this information in a centralized manner, leading to data monopolization.

➢

For attackers, compromising such centralized storage systems is often highly rewarding and relatively straightforward, frequently resulting in security incidents.

➢

Since all user data is stored and transmitted in plaintext, any courier at any stage of the logistics process can access and use this information, significantly increasing the risk of data leakage, misuse, or resale.

➢

Commercial analytics companies can exploit users’ plaintext personal information from the logistics process to conduct business analyses, enabling identity linking and unauthorized marketing or promotional activities.

Based on the above approach, we have effectively mitigated and protected against the threats present in traditional logistics scenarios. The specific improvements are outlined below, with results illustrated in Figure 9:

➢

Users can register and obtain a unique self-sovereign identity (DID) and derive or apply for sub-identities as UIDs for logistics purposes. In this process, the self-sovereign identity replaces the user’s original real name and phone number, significantly reducing the exposure of these high-value plaintext data. Additionally, users’ address information is segmented, encrypted, and stored on a decentralized blockchain, preventing courier companies from directly reading or using it. This effectively eliminates centralized storage and data monopolization issues.

➢

For attackers, compromising such a decentralized, non-plaintext storage environment is both highly challenging and offers minimal benefit, making security incidents far less likely.

➢

Through the TEE-based progressive decryption of address fragments, couriers only receive address information in a stepwise and selectively disclosed manner. Compared with traditional approaches, this significantly reduces the exposure of plaintext address data. In theory, no transit courier other than the final delivery personnel can access the full plaintext address, thereby minimizing the risk of data leakage, misuse, or resale.

➢

By leveraging DIDs and their derived UIDs, commercial analytics companies find it extremely difficult to associate specific purchases or logistics activities with particular individuals. This prevents unauthorized identity linking and corresponding commercial marketing or promotional activities.

To more clearly illustrate how our approach enhances user data privacy compared with traditional logistics processes, we present

Table 2. Comparison of User Data Exposure and Usage Between the Proposed Design and the Original Logistics Process.

Comparison Item	Proposed Scheme	Original Logistics Process
User’s real name	Not required	Required
User’s phone number	Not required	Required
User’s address	Minimally and selectively disclosed	Fully visible to all handlers
Identity linkage & behavior tracking	Difficult to occur	Easy to occur
User data storage	Decentralized blockchain storage with encryption	Centralized black-box storage, often lacking encryption
Log storage	Decentralized blockchain storage with encryption	Centralized black-box storage, prone to loss or tampering

. This table provides a detailed comparison between the proposed design and the conventional logistics workflow in terms of user data exposure and usage. From this comparison, the improvements and innovations in privacy protection enabled by our scheme become evident.

At the same time, we also briefly examine how the proposed scheme adheres to fundamental SSI design principles. Our discussion draws on Christopher Allen’s Ten Principles of Self-Sovereign Identity, from which we highlight the following five widely recognized principles:

• Existence: Identity must belong to real individuals rather than to systems or institutions.

In our design, users exist independently without reliance on any centralized registration authority. Through our protocol-labeling mechanism, the system supports interoperability with a wide range of SSI protocols, and by default adopts our previous work, NSSIM. All identity-registration procedures in these protocols avoid centralized authorities, ensuring that identities belong to users—not institutions.

2.

Control: Users must be able to control their own identity data, including creating, using, and revoking credentials.

At first glance, allowing the seller to encrypt the address using the TEE’s public key and upload it to IPFS may seem to weaken user control. However, the key insight is that the cloud-based TEE—responsible for later processing and decrypting the IPFS-stored data—is not owned by the seller or the courier company. Instead, the TEE strengthens user control by enabling users to enforce fine-grained, stage-based disclosure of address information throughout the delivery process.

To clarify this, consider who should legitimately receive access to the user’s address within logistics workflows.

Unquestionably, the seller requires full access to the address to initiate shipment. Our design therefore provides the seller with complete address information.

For couriers, however, the required level of access varies:

• Intermediate couriers typically only need the next-hop destination.
• The final courier requires the full address to complete delivery.

The cloud-based TEE allows users to enforce precisely these stage-specific access rights, ensuring that each courier sees only the portion of the address necessary for their role.

From the buyer’s perspective, once an address is provided to the seller, the intended access-control semantics are implicitly:

• Seller: Full access.
• Couriers: Partial or full access depending on their stage in the workflow.

The seller’s actions—segmenting the address, encrypting the segments with the TEE’s public key, and storing them on IPFS—merely enable the TEE to enforce these user-defined access rules. Delegating these steps to the seller is both practical (avoiding user-side cryptographic complexity) and compatible with existing logistics practices (where sellers naturally handle address preparation and labeling).

Importantly, sellers have no incentive to tamper with the address (incorrect labels would prevent shipment and harm their own interests). Moreover, all decryption and disclosure events are immutably recorded on the blockchain, ensuring auditability and discouraging misconduct.

Thus, when the user provides the address to the seller, they implicitly authorize the seller to encrypt it using the TEE’s public key and authorize the cloud-based TEE to enforce selective disclosure. User control is preserved throughout, and the TEE merely executes the user’s predetermined disclosure policies. Therefore, the proposed design fully upholds the SSI principle of Control.

3.

Access: Users must have continuous and unobstructed access to their own data; such access must not be locked or restricted by platforms or custodians.

In our design, the user’s address is encrypted using the TEE’s public key and stored on IPFS. IPFS’s decentralized architecture ensures that data is not controlled by—and cannot be locked or withheld by—any single platform. The TEE, which is not owned by any party with vested interests, faithfully protects the user’s data and decrypts or releases specific portions solely according to the user’s intent. Users therefore retain full control and accessibility rights.

4.

Minimization: Only the minimum necessary data should be disclosed (minimal disclosure/selective disclosure).

Our workflow-driven selective-disclosure mechanism further strengthens SSI’s minimization principle. Through our design, disclosure becomes more granular, determining precisely who can see which data segments at which stage. The comparison in Table 2 illustrates how our approach significantly reduces unnecessary data exposure in logistics workflows, thereby demonstrating strong adherence to—and enhancement of—the minimization principle.

5.

Protection: The system must safeguard the user’s rights, privacy, and freedoms, preventing identity misuse or surveillance; in other words, protection must exist at both technical and social levels.

In our design, users leverage their SSI primary identities and derived sub-identities (UIDs) to achieve frontend unlinkability, preventing identity tracking or misuse at the social level. Technically, as shown in Table 2, unnecessary personal data (such as name or phone number) is eliminated entirely, and the remaining necessary data (address segments) is both encrypted and subject to selective-disclosure policies. These mechanisms together ensure strong technical protection. Therefore, the Protection principle remains fully satisfied.

5. Use Case, Experiments and Analysis

5.1. Use Case Analysis Based on Prototype Software Demonstration

During the experimentation and analysis phase, we developed a prototype demo using the Python Flask framework and implemented the core functionalities.

To better illustrate how our workflow-driven selective disclosure mechanism operates during the logistics transportation process, we developed a concrete end-to-end example accompanied by a step-by-step diagram (Figure 10). In this example, a seller located in Chaoyang District, Beijing ships a package to a buyer located in Xihu District, Hangzhou, Zhejiang Province. Following the standard logistics workflow, three types of logistics nodes participate in the transportation process: the Collection Point, the Sorting Center, and the Delivery Station.

As shown in Step 1 of Figure 10, after encrypting all address segments according to our design, the seller hands the package to the Collection Point in Chaoyang District for shipment. Since Collection Points do not care about the final destination—they simply collect parcels and forward them to the city-level Sorting Center—they do not need to decrypt any address segment at this stage. This ensures minimal and appropriate disclosure.

In Step 2, the Beijing Sorting Center needs to know the destination province to determine the next routing path. Therefore, the largest address segment (the province) is scanned via QR code and decrypted, allowing the center to learn that the parcel should be forwarded to the Zhejiang Provincial Sorting Center. During this stage, the Beijing Sorting Center learns only the province (“Zhejiang”) and nothing more specific, thereby maintaining strong privacy via selective disclosure.

Similarly, when the parcel arrives at the Zhejiang Provincial Sorting Center, the center must determine the specific city to which the parcel should be forwarded. In Step 3, it scans and decrypts the city-level address segment, learning that the destination city is Hangzhou. The center remains unaware of more detailed address information, again upholding selective disclosure and privacy protection.

Upon arrival at the Hangzhou Sorting Center, Step 4 requires the center to identify the destination district within the city. The district-level segment is therefore scanned and decrypted, allowing the center to route the parcel to the appropriate Delivery Station in Xihu District. At this stage, the Hangzhou Sorting Center learns only that the parcel belongs to Xihu District and nothing beyond that, demonstrating continued adherence to selective disclosure.

In Step 5, the Delivery Station in Xihu District receives the parcel and must determine the street information in order to assign the parcel to the correct courier. This step may be optional depending on operational scale—for smaller areas, such routing may not be necessary; for larger areas where couriers are assigned by street, it becomes essential. In this example, the street-level segment (“88 Tianmushan Road”) is decrypted, enabling the Delivery Station to pass the parcel to the courier responsible for that street. At this stage, the Delivery Station knows only the street-level information but not the unit or door number, maintaining effective privacy control.

Finally, in Step 6—the delivery stage—the courier scans the last remaining encrypted address segments (unit and door number) to complete the delivery. The buyer verifies receipt using an SSI sub-identity UID and the associated zero-knowledge proof. With assistance from the TEE, the courier verifies the ZKP-based shipping verification code (SVC) and determines whether the parcel can be handed over.

The courier is the only entity in the entire workflow who sees the full address, which demonstrates the precision and correctness of our selective disclosure design. Furthermore, every scan, decryption request, and disclosure event throughout all steps is logged immutably on the blockchain, ensuring accountability and preventing misconduct or data misuse.

In our demo, we simulated the operations described above. Figure 11a shows the SA encryption process executed by the seller, which generates the tracking number (TN) in both text and QR code formats. Figure 11b simulates the QR-code scanner reading the QR code to retrieve the TN and subsequently decrypting the corresponding address fragment (ADF) based on the current logistics workflow stage. Each scan triggers the partial decryption and display of a new ADF, thereby minimizing the risk of exposing the user’s full address during the logistics process and enhancing privacy protection, as illustrated in Figure 10 and its accompanying explanation.

5.2. Scyther-Based Formal Analysis and Theoretical Security Analysis of All Entities

5.2.1. Scyther-Based Automated Formal Analysis of the Proposed Protocol

For the security analysis, we employed Scyther, a formal verification tool developed by the CISPA Helmholtz Center for Information Security in Germany [53,54,55,56,57]. Scyther is widely used by researchers worldwide to identify potential attacks and vulnerabilities in security protocols through automated analysis.

Using Scyther, we formally verified our protocol against the following key security properties:

✓

Confidentiality, which ensures that sensitive information such as user identifiers or encrypted address fragments cannot be accessed by unauthorized entities during protocol execution.

✓

Aliveness, which confirms that each party involved in a session has actively participated, thereby preventing false claims of successful interaction.

✓

Weak Agreement, which verifies that if one participant completes a session believing it was with a specific peer, then that peer must also have been engaged in a related session.

✓

Non-injective Agreement (Niagree) can ensure that both parties in communication have a consistent understanding of identity and data, and can prevent replay attacks to a certain extent under the timestamp mechanism.

✓

Non-synchronization (Nisynch), which guarantees correct interaction ordering and message validity, without requiring strict time alignment—particularly important in asynchronous logistics networks.

✓

State Consistency, which ensures that all protocol participants transition through legitimate states without bypassing any critical verification step.

Specifically, the verification is conducted under the standard Dolev–Yao threat model, in which the adversary is assumed to have full control over the public communication network. In this model, the attacker can arbitrarily eavesdrop on, intercept, replay, modify, and inject protocol messages. However, the adversary is assumed to be computationally bounded and thus unable to break cryptographic primitives such as encryption schemes or hash functions.

The proposed protocol is formally specified using Scyther’s security protocol description language. Each participant in the logistics workflow is explicitly modeled as an independent protocol role, including the user, the seller, the courier, and the TEE, as well as three blockchain components: the Courier Equipment Registration Chain, the Express Address Storage Chain, and the Express Behavior Log Chain.

Security goals are expressed using Scyther’s claim constructs. For each relevant role, multiple categories of security properties are specified to verify the aforementioned key security requirements. Secrecy claims (Secret) are used to verify the confidentiality of sensitive identity-related data, ensuring that such information is not disclosed to an active network adversary. Based on the specific data elements involved in each entity’s interactions, we declare secrecy claims for different entities and protocol steps. The verified confidential elements include timestamps (Ts), user identifiers (UIDs), shipping verification codes (SVCs), Proofs, and address fragments (ADFs), as summarized in

Table 3. Security Claims and Verification Scope of the Proposed Scheme Using Scyther.

Entity	Scope of Secret Claims	Other Verified Claims
User	UID, SVC, Proof, SA, Ts	Alive, Weakagree, Niagree, Nisynch
Seller	UID, SVC, SA, Ts	Alive, Weakagree, Niagree, Nisynch
Courier	ADF, Proof, SVC, Ts	Alive, Weakagree, Niagree, Nisynch
TEE	ADF, Proof, SVC, Ts	Alive, Weakagree, Niagree, Nisynch
Courier Equipment Registration Chain	N/A (No confidential data involved)	Alive, Weakagree, Niagree, Nisynch
Express Address Storage Chain	ADF	Alive, Weakagree, Niagree, Nisynch
Express Behavior Log Chain	CSID, SDID	Alive, Weakagree, Niagree, Nisynch

.

In addition to secrecy claims, we specify liveness claims (Alive) and authentication and synchronization claims (Weakagree, Niagree, Nisynch) for all entities across their interactions. The Alive claim ensures that each protocol participant has actively engaged in the protocol execution. The authentication and synchronization claims (Weakagree, Niagree, and Nisynch) verify agreement and synchronization among interacting parties, ensuring consistency of session parameters and that exchanged messages correspond to the same protocol run. Together, these claims collectively establish the verification of the key security properties and ensure protocol state consistency.

Figure 12 shows the formal verification results of the proposed protocol using Scyther under the specified security claims. Within the analyzed model and the defined security scope, the tool did not identify any known attacks.

5.2.2. Theoretical Analysis of Security Requirements and Solutions for Each Entity

Building on the formal verification results, we further conducted supplementary theoretical analysis. We summarized the security requirements and concerns of all entities involved in this study—users, sellers, logistics companies, and couriers, and the regulatory authority—and provided a detailed explanation of how our proposed design satisfies these requirements and mitigates their corresponding concerns.

User-Side Security Requirements and Concerns

For users, the primary concern is whether their personal and sensitive information may be exposed or misused during logistics operations. They also worry about unintended identity linkage and unauthorized commercial profiling triggered by logistics activities. More specifically, users typically have the following security requirements and concerns:

• Will my real personal information—such as name and phone number—be leaked during the logistics process?
• Will my logistics and shopping behaviors be collected, analyzed, or used for unauthorized commercial profiling, potentially leading to unwanted advertising or marketing harassment?
• Are other personal data—beyond key identifiers like name and phone number—properly protected throughout the logistics workflow?

For these security requirements and concerns, our proposed design provides effective safeguards and demonstrable risk mitigation. The detailed analysis is as follows:

• Will my real personal information—such as name and phone number—be leaked during the logistics process?

As illustrated in Figure 8 and Figure 9 of Section 4, the system introduces a Self-Sovereign Identity (SSI)-based decentralized identifier (DID) and its derived subordinate identity, the UID. Under this design, users no longer need to disclose their real names or phone numbers during logistics operations; instead, a self-sovereign UID is used throughout the process. This eliminates the need to transmit or store real personal identifiers, thereby fundamentally reducing the risk of exposure.

Because such sensitive data are never collected or transmitted, they are not subject to third-party storage or processing, ensuring inherent protection. Additionally, this design aligns with legal and regulatory requirements—such as GDPR’s principle of data minimization [58,59]—and thus enhances compliance regarding personal data privacy.

2.

Will my logistics and shopping behaviors be collected, analyzed, or used for unauthorized commercial profiling, potentially leading to unwanted advertising or marketing harassment?

Since users perform logistics interactions using dynamic, multiple UIDs rather than a single static real-world identity, commercial analytics entities face substantial difficulty linking different e-commerce purchases or logistics activities back to a natural person. This significantly improves unlinkability and prevents behavioral aggregation and profiling.

Furthermore, as unauthorized identity correlation or targeted marketing becomes infeasible without user awareness, the solution better supports GDPR requirements for lawfulness, fairness, and transparency [60] in data processing.

3.

Are other personal data—beyond key identifiers like name and phone number—properly protected throughout the logistics workflow?

Beyond preventing the leakage of the user’s real name and phone number, the proposed system also provides strong protection for address information during transit. Through a layered, progressive decryption approach, each courier or sorting center can only access the minimal address fragment necessary for completing their specific delivery step. They cannot view any more detailed information beyond their operational scope.

Only the final delivery courier gains access to the full address, and even then, all such access is tightly controlled and audited through secure logging. This design enforces selective disclosure of address information throughout the logistics chain and strictly adheres to purpose limitation principles: data may only be used for explicit, legitimate purposes and cannot be repurposed arbitrarily [61,62].

Security Requirements and Concerns on the Seller Side

For sellers, their primary security concerns stem from reputation building and behavioral compliance. If a data security incident occurs while a user is shopping with a particular seller or during the logistics process, that seller’s reputation can be seriously damaged, and the resulting loss of buyer trust may directly reduce revenue. At the same time, ensuring compliant operations is essential for long-term business stability, making it another key area of focus. Specifically, the seller’s security needs and concerns include the following:

• How can user data be collected and used in a strictly minimal manner to prevent misuse?
• How can operational practices be standardized to reduce users’ distrust of the seller’s behavior and strengthen the seller’s compliance posture?

For these security requirements and concerns, our proposed design provides effective safeguards and demonstrable risk mitigation. The detailed analysis is as follows:

• How can user data be collected and used in a strictly minimal manner to prevent misuse?

With the design proposed in this study, sellers can more effectively demonstrate adherence to the principle of minimal data collection. Users only need to provide the seller with their self-sovereign identity (UID) and address, without revealing their real name or phone number. This reduces the risk of dishonest sellers misappropriating personal information. By implementing the principle of data minimization, sellers no longer need access to users’ real names or phone numbers, and the absence of such data transmission inherently lowers the risk of misuse from the source.

2.

How can operational practices be standardized to reduce users’ distrust of the seller’s behavior and strengthen the seller’s compliance posture?

Unlike traditional approaches where shipping operations are opaque to users, our design ensures that all sellers follow a standardized method for segmenting, encrypting, and recording addresses on the blockchain. The outcomes of these operations are fully visible on-chain. This standardized and transparent approach not only enhances users’ trust in sellers but also facilitates effective oversight and compliance checks with applicable regulations and laws.

Security Requirements and Concerns on the Logistics Companies and Couriers’ Side

For logistics companies and couriers, the primary concern is whether couriers fulfill their due diligence regarding user data security during their work, and whether any violations are properly monitored. According to the Collins English Dictionary, due diligence is defined as “The degree of care that is to be reasonably expected or that is legally required.” In other words, logistics companies need to conduct careful and necessary assessments of whether their employees’ operational practices meet data security standards and maintain continuous monitoring. At the same time, logistics companies themselves may also act maliciously, which necessitates reasonable oversight from regulatory authorities.

Specifically, the security needs and concerns on the logistics companies and the couriers’ side include the following:

• Do couriers have opportunities to access data beyond what is required for their duties?
• Is there a risk of unintended disclosure of users’ private data?
• Are necessary controls in place to enforce minimal data disclosure and monitor potential violations?
• Are these behaviors subject to regulatory oversight?

For these security requirements and concerns, our proposed design provides effective safeguards and demonstrable risk mitigation. The detailed analysis is as follows:

• Do couriers have opportunities to access data beyond what is required for their duties?

In our study design, as previously described, the data required from users during the logistics process has been significantly optimized. Users are not required to provide their real names or phone numbers. Furthermore, address information is selectively disclosed to different couriers, providing only the minimal data necessary for their specific tasks. This mechanism effectively reduces the risk that couriers could access or retrieve additional data beyond what their duties require.

2.

Is there a risk of unintended disclosure of users’ private data?

Because our approach no longer requires sensitive information such as users’ real names or phone numbers, the risk of unintended disclosure of such data is significantly reduced. Additionally, address information is managed through selective disclosure, ensuring that only the minimum necessary data is shared. This design further minimizes the risk of users’ private information being disclosed unintentionally.

3.

Are necessary controls in place to enforce minimal data disclosure and monitor potential violations?

In our design, enforcement of minimal data disclosure and monitoring of potential violations is achieved through the combination of Trusted Execution Environments (TEEs) and the Express Behavior Log Chain. The TEE ensures that any data decryption requests come only from authorized couriers, while the logs recorded in the Express Behavior Log Chain provide a complete trail of data decryption and access activities. This ensures accountability and enables violation checks for specific employees.

4.

Are these behaviors subject to regulatory oversight?

These behaviors are subject to regulatory oversight. The logs stored in the Express Behavior Log Chain can be audited and reviewed by regulatory authorities, ensuring that courier activities during the logistics process are both constrained and fully auditable.

Security Requirements and Concerns on the Regulatory Authority Side

For regulatory authorities, their primary security concerns stem from whether they possess the ability to effectively enforce oversight and hold parties accountable. In other words, if a regulatory authority lacks such capabilities within the system, violations may go undetected or unpunished, significantly impacting the overall reliability and security of the system.

Specifically, the security needs and concerns on the regulatory authority side include:

• Are violations visible and auditable?
• Can specific personnel be identified to enable actual accountability for any violations?

For these security requirements and concerns, our proposed design provides effective safeguards and demonstrable risk mitigation. The detailed analysis is as follows:

• Are violations visible and auditable?

In our design, violations are both visible and auditable for regulatory authorities. The TEE records all operational requests from authorized QR code scanners and their corresponding outcomes into the Express Behavior Log Chain. These log entries are encrypted using the TEE’s private key and then further encrypted with the regulatory authority’s public key, ensuring the confidentiality, authenticity, and non-repudiation of the logs. With these security guarantees, regulatory authorities can trust the log information and conduct oversight based on the recorded activities.

2.

Can specific personnel be identified to enable actual accountability for any violations?

Each authorized QR code scanner is linked to a specific courier, which ensures that any suspicious activity recorded in the Express Behavior Log Chain can be traced back to the corresponding courier using the scanner’s device ID (SDID) recorded in the log. This mechanism guarantees that regulatory authorities can identify the specific personnel involved and hold them accountable for any violations.

5.3. Encryption/Decryption Performance Simulation

For the Encryption/Decryption Performance Simulation section, we focused on simulating the core functions of SA segmentation and ADF encryption/decryption within our design. Using Python’s Flask framework, we developed code to randomly generate addresses and perform encryption and decryption tests. To maximize multi-core CPU utilization, the implementation employed multiprocessing techniques. During the tests, the code randomly generated SAs composed of five ADFs each, and encrypted/decrypted the ADFs using the RSA-2048 algorithm [63,64]. The number of test addresses ranged from 10 to 1000 in multiple increments. For each round, we recorded the average encryption and decryption time per SA and per ADF to evaluate the efficiency and practicality of our design.

To better simulate the computational capabilities of different interacting parties, we selected three distinct computing platforms to represent the processing power of the seller, the TEE, and the QR code scanner, respectively.

5.3.1. Hardware Configuration

Hardware Environment Configuration for the Seller

To simulate the seller’s computational power, we selected the Intel i3-8100 CPU as the test platform. This processor features four cores and four threads, with a maximum clock speed of 3.6 GHz. Released in 2017, it serves as a representation of a modest-performance computer typical of small-scale sellers, allowing us to verify that our protocol design can broadly meet the needs of sellers with varying hardware capabilities.

The specific configuration of the test environment is as follows:

CPU: Intel i3-8100.

RAM: 16 GB DDR3 1600.

ROM: 128 GB NVME SSD.

OS: Windows 10 Enterprise LTSC 2021.

Hardware Environment Configuration for the TEE

For the TEE computational power simulation, we selected the Intel Xeon E5-2666 V3 as the CPU for our testing environment. This processor features 10 cores and 20 threads, with a maximum clock speed of 3.3 GHz. Released in 2014, it serves as a representative of outdated TEEs with limited computational resources. By choosing this setup, our goal is to evaluate whether our protocol design remains robust and efficient even under constrained computing conditions, ensuring broad applicability across diverse TEE deployment scenarios.

The specific configuration of the test environment is as follows:

CPU: Intel Xeon E5-2666 V3.

RAM: 16 GB DDR3 1333.

ROM: 128 GB NVME SSD.

OS: Windows 10 Enterprise LTSC 2021.

Hardware Environment Configuration for the QR Code Scanner

For the simulation of the QR code scanner’s computational capabilities, we selected an ARM-based platform to better reflect the real-world conditions of IoT devices. Specifically, we chose the S905L3A-B chip as the target device.

The S905L3A-B is a system-on-chip (SoC) developed by Amlogic, based on the S905X2 architecture and manufactured using a 12 nm process. It features a quad-core, quad-thread design based on the ARM Cortex-A53 architecture, with a maximum clock speed of 1.8 GHz.

This chip remains widely used in various smart IoT devices, such as set-top boxes and smart cameras, making it an excellent representative for simulating the processing power of low-performance handheld devices like QR code scanners.

The specific configuration of the test environment is as follows:

CPU: Amlogic S905L3A-B.

RAM: 2 GB LPDDR4 2133.

ROM: 8 GB eMMC.

OS: Linux armbain 6.12.21 aarch64.

5.3.2. Encryption and Decryption Operation Simulation Options

The specific simulation of encryption and decryption operations for the seller, the TEE, and the QR-code scanning device is based entirely on the detailed processes described above. Specifically, in our design, the seller primarily handles the fragmentation and on-chain encryption of address information (e.g., Expression 8); therefore, we focus on encryption performance testing for the seller.

The TEE, as described above, involves both encryption and decryption operations. Encryption mainly pertains to encrypting operational logs with the public key of the regulatory authority (RA) for on-chain storage (e.g., Expression 16), while decryption mainly refers to the process of decrypting specific address fragments (ADF) upon request from the QR-code scanning device and returning the results (e.g., Expression 18).

For the QR-code scanning device, both encryption and decryption operations are also involved. Its encryption operations mainly concern encrypting requests to the TEE for decrypting ADF data when scanning the delivery QR code. To ensure the security of the transmitted data, these requests are encrypted using the TEE’s public key (e.g., Expression 14). Decryption operations primarily involve processing the data returned from the TEE. To maintain the confidentiality of the decrypted ADF during transmission, the relevant data are encrypted with the QR-code scanning device’s public key (e.g., Expression 18).

Table 4. Encryption and Decryption Operation Statistics by Entity.

Entity	Encryption	Decryption
Seller	√	-
TEE	√	√
QR-code scanner	√	√

summarizes the encryption and decryption activities of each entity.

Based on this analysis, we conduct encryption performance simulation tests on the seller side, while both encryption and decryption performance simulation tests are carried out for the TEE and QR-code scanning device, respectively.

5.3.3. Results of the Encryption and Decryption Performance Simulation

Encryption Performance Simulation on the Seller Side

The results of the encryption performance tests in the simulated seller environment are shown in Figure 13, with the corresponding average performance line chart presented in Figure 14.

Based on the collected data, the implemented design clearly achieves millisecond-level efficiency in this environment. Furthermore, leveraging multiprocessing enhances encryption efficiency as data volume increases. These performance metrics strongly indicate that our design is well-suited for practical deployment by sellers in real-world scenarios.

Encryption and Decryption Performance Simulation on the TEE Side

The final performance testing results for the simulated TEE are as follows. Figure 15 presents the encryption performance statistics, while Figure 16 shows the decryption performance data.

The corresponding average performance line charts are displayed in Figure 17a and Figure 17b, respectively.

According to the data, despite being run in a typical TEE simulation environment with hardware released over a decade ago, our implementation still achieves millisecond-level performance. Benefiting from the high number of cores and threads, the system demonstrates increasing efficiency with larger data volumes, even though the CPU’s base clock speed is relatively modest. These performance results convincingly demonstrate that our protocol design is sufficiently lightweight and optimized for practical deployment, ensuring effective execution across a wide range of real-world TEEs.

Encryption and Decryption Performance Simulation on the QR-Code Scanner Side

The final performance test results for the simulated QR code scanner environment are as follows: Figure 18 presents the encryption performance statistics, while Figure 19 shows the decryption performance statistics.

The corresponding average time trendlines are depicted in Figure 20a for encryption and Figure 20b for decryption.

According to the data collected, our implementation under this ARM-based simulation environment was still able to perform encryption and decryption operations within millisecond-level latency. Despite the modest CPU specifications (only four cores and four threads at a relatively low clock speed), the performance remained efficient even as the volume of test data increased. Considering that, in practice, QR code scanners are unlikely to encounter such heavy computational loads, these results strongly demonstrate that our design can be effectively deployed on low-power, handheld IoT devices in real-world scenarios.

5.4. Performance Simulation of Blockchain Data Storage

This section presents an estimation of data volumes for different content uploaded to multiple blockchains in the proposed design, along with a simulation of on-chain storage performance.

5.4.1. Estimated Data Volumes Uploaded to Each Blockchain

Courier Equipment Registration Chain

The data uploaded to the Courier Equipment Registration Chain mainly involves the content shown in Expression 2. In this process, the courier company ID (CCID), the QR-code scanner device ID (SDID), and the CCID, SDID, and the QR-code scanner’s public key (PubSD) encrypted directly using the courier company’s private key are uploaded to the chain. Since we employ the RSA-2048 algorithm, the output of the private-key encryption is fixed at 256 bytes.

Assuming that the CCID is a 10-character string representing different courier companies, and the SDID is a 20-character string representing different QR-code scanners, their corresponding data sizes are 10 bytes and 20 bytes, respectively. Therefore, the estimated data volume uploaded to the Courier Equipment Registration Chain in each transaction is 286 bytes.

Express Address Storage Chain

The data uploaded to the Express Address Storage Chain mainly involves the content shown in Expression 8. In this process, the Express Address Storage Chain stores only the CID data generated by IPFS. For IPFS, any file is referenced by a single root CID, meaning one CID can represent a file of arbitrary size. Therefore, the data uploaded to the Express Address Storage Chain always corresponds to the fixed size of a single CID. Using the default IPFS configuration based on the SHA-256 hashing algorithm as an example, each CID occupies a fixed size of 32 bytes on-chain. It is also worth noting that when the Express Address Storage Chain stores only the 32-byte CID, the retrieval of the corresponding data requires the assistance of an IPFS search engine. If the IPFS search engine is not employed, the current tracking number (TN, 36 bytes in our design) must be additionally uploaded to the Express Address Storage Chain to demonstrate its association with the CID. In practical applications, the choice between these two approaches, namely using an external IPFS search engine to resolve the CID–TN relationship or recording the TN on-chain alongside the CID, can be determined by weighing the efficiency of the IPFS search engine against the gas cost of on-chain storage.

Express Behavior Log Chain

The data uploaded to the Express Behavior Log Chain mainly involves the content shown in Expressions 16 and 26, with Expression 16 representing the largest data volume and thus serving as the baseline metric.

In the process described in Expression 16, logs related to the courier’s ADF decryption requests are uploaded to the Express Behavior Log Chain. Each log entry includes the plaintext tracking number (TN), the address fragment number ADFN being decrypted, a timestamp (Ts), and the combined data {Pub_RA(Pri_TEE(TN, ADFN, CSID, SDID, Ts))}—first encrypted with the TEE’s private key and then with the regulatory authority’s (RA) public key.

Since Pri_TEE(TN, ADFN, CSID, SDID, Ts) uses the RSA-2048 algorithm, its output is fixed at 256 bytes. Because this exceeds the RSA-2048 single-block encryption limit of 245 bytes, Pub_RA(Pri_TEE(TN, ADFN, CSID, SDID, Ts)) is encrypted in segments, resulting in two 256-byte fragments plus approximately 3 bytes of metadata. Thus, the total size of Pub_RA(Pri_TEE(TN, ADFN, CSID, SDID, Ts)) is about 515 bytes.

Adding the 36-byte TN, 2-byte ADFN, and the standard 8-byte millisecond-level Unix timestamp, the total estimated data volume per log entry is 561 bytes.

Based on the analysis above,

Table 5. Estimated Data Volume Statistics for Upload to Each Blockchain.

Blockchain	Estimated Data Volume (Bytes)
Courier Equipment Registration Chain	286
Express Address Storage Chain	32
Express Behavior Log Chain	561

presents the estimated data volumes for uploads to each blockchain.

5.4.2. Test Environment Software and Hardware Configuration

The blockchain data storage tests are conducted using the Hardhat framework [65,66]. Hardhat is an advanced development and testing environment designed for smart contract development on Ethereum and Ethereum-compatible networks [67,68]. It provides a comprehensive and integrated set of tools aimed at improving the efficiency and quality of smart contract development. Hardhat allows users to quickly deploy private blockchain networks locally for data testing.

We implemented the relevant test scripts using Node.js 18.20.8 and built the local blockchain test network with Hardhat v2.19 and its Toolbox. This setup is used to simulate gas consumption and response times for the aforementioned blockchain data volume tests. The specific operating system and hardware configuration are as follows.

CPU: AMD Ryzen R5 5600H (configured to two cores and four threads via VMware to simulate limited resources).

RAM: 8 GB DDR4 2666.

ROM: 30 GB NVME SSD.

OS: Ubuntu 22.04.5 LTS.

5.4.3. Test Results Statistics and Analysis

In this test, we generate simulated data corresponding to the estimated data volumes for each blockchain described above. Each blockchain undergoes 10 write simulations to obtain the relevant gas consumption and response time data, with metrics such as the mean and standard deviation used as reference indicators. The final gas consumption results are presented in

Table 6. Gas Consumption in Simulated Performance Tests for Each Blockchain.

Blockchain	Data Volume (Bytes)	Mean Gas	Standard Deviation
Courier Equipment Registration Chain	286	32,684	32
Express Address Storage Chain	32	22,274	12
Express Behavior Log Chain	561	43,931	33

, while the response time data can be found in

Table 7. Response Time in Simulated Performance Tests for Each Blockchain.

Blockchain	Data Volume (Bytes)	Mean Response Time	Standard Deviation
Courier Equipment Registration Chain	286	7.40 ms	3.32
Express Address Storage Chain	32	8.90 ms	3.81
Express Behavior Log Chain	561	6.20 ms	1.33

.

The observed gas consumption and response times across all simulated blockchain scenarios demonstrate that the proposed design achieves an acceptable level of efficiency and performance overhead. Despite variations in data volume and blockchain platforms, the measured metrics remain within practical limits, indicating that the system can support real-world deployments without imposing excessive computational or financial costs. These results validate that the design balances security, functionality, and operational efficiency effectively.

Additionally, to mitigate potential cost increases or efficiency reductions caused by network congestion or fee volatility on the public mainnet, Layer 2 scaling solutions such as Rollups can be introduced to further enhance efficiency and reduce congestion. By employing L2 Rollup solutions—such as Optimistic Rollups or ZK Rollups [69,70]—it is possible to achieve tens to even hundreds of times lower transaction costs and significantly higher throughput, while still retaining the security guarantees of the L1 blockchain.

5.5. ZKP Generation and On-Chain Smart Contract Verification Performance Simulation

To demonstrate the acceptable efficiency of the ZoKrates zero-knowledge proof (ZKP) technology proposed in this study, we also conducted simulation tests and statistical analysis of the time and gas consumption required for local ZKP generation and on-chain smart contract verification. The software and hardware environment used for this test is the same as described in Section 5.4.2. The final test results are presented in

Table 8. Local ZKP Generation Time and On-Chain Verification Resource Usage.

Operation	Mean Execution Time	Mean Gas
Local proof.json Generation	1256 ms	-
On-Chain Smart Contract Verification	18.20 ms	235,954

.

The test results indicate that although generating proof.json locally requires approximately one second, this duration remains acceptable given the expected frequency of this operation on the user side and the perceived response time. On-chain verification demonstrates normal efficiency and can be effectively applied in practical scenarios. Similarly, using L2 rollups for proof verification at this stage can further reduce costs by an order of magnitude. Through batching, tens of thousands of verification operations can be aggregated into a single on-chain transaction, thereby substantially improving overall efficiency.

Moreover, as described in Step 16 of Section 4, if a given application scenario seeks to further reduce the gas costs associated with on-chain smart-contract verification, the TEE can perform zero-knowledge proof verification off-chain—provided that the user explicitly consents to delegate this verification authority to the TEE. This approach serves as a compromise, but it may inevitably deviate from the standard workflow defined by the protocol. Therefore, it is recommended only as an alternative option.

5.6. Performance Simulation of IPFS Storage and Comparative Evaluation Against Direct On-Chain Storage

In this simulation, we estimated the expected data volume to be uploaded to IPFS in the current design and conducted storage simulations based on this projection. The resulting response time data were then compared with the response times for storing equivalent data directly on-chain, thereby demonstrating the higher operational efficiency of the proposed approach.

The data uploaded in this process is as described in Expression 8. Each individual ADF upload consists of the plaintext seller ID (SID), the plaintext tracking number (TN), the address fragment number (ADFN), and the combination {TN, ADFN, Pub_TEE(ADF)} encrypted with the seller’s private key. The ADF en-crypted with the TEE public key produces a fixed output of 256 bytes under the RSA-2048 algorithm.

Assuming TN corresponds to the 36-character string shown in our demo software (Figure 11a), and ADFN is a maximum 2-character string (since the number of address fragments rarely exceeds 10), the total size of {TN, ADFN, Pub_TEE(ADF)} exceeds RSA-2048’s maximum input limit of 245 bytes. Consequently, this combination must be encrypted in two segments, resulting in 512 bytes. Accounting for the additional metadata required for segment encryption, we estimate approximately 3 extra bytes.

Assuming the seller ID (SID) is a 10-character string, the estimated output data volume for each ADF in Expression 8 is therefore 563 bytes. Since a single delivery ad-dress may be split into 5–10 ADFs for upload, the value of n in Expression 8 is expected to range from 5 to 10, corresponding to a total estimated data volume of 2815–5630 bytes.

Based on the above analysis, the expected size of the data to be uploaded ranges from approximately 2 KB to 6 KB. Using the software and hardware testing environment described in Section 5.4.2, we set up a local IPFS test environment and randomly generated encrypted data samples of 2 KB, 4 KB, and 6 KB. For each data size, we conducted 100 upload trials and calculated the average storage response time after excluding outliers.

Using the same environment, data, and testing procedure, we also performed direct on-chain storage tests to obtain the corresponding average storage response times. The detailed comparative results are presented in

Table 9. Statistical Simulation of Data Upload Performance for IPFS and Blockchain.

Data Volume (Bytes)	Average IPFS Storage Response Time	Average Blockchain Storage Response Time
2048	5.56 ms	6.70 ms
4096	5.98 ms	6.22 ms
6144	5.64 ms	6.66 ms

.

The results indicate that, compared with storing data directly on-chain, using IPFS to store encrypted address data achieves higher storage efficiency. The corresponding response times are sufficiently short to support efficient operation in logistics scenarios. Moreover, as shown in Table 7, when uploading data of these sizes to IPFS, the generated CID and its subsequent upload to the Express Address Storage Chain remain fixed at 32 bytes.

This not only maintains the storage efficiency advantage described above but also significantly reduces gas consumption. For instance, in our tests, the average gas consumption for directly uploading 2 KB, 4 KB, and 6 KB of data to the blockchain was 102, 684, 184, 342, and 266, 037, respectively. These values are substantially higher than the average gas consumption of 22, 274 required to store a 32-byte IPFS-generated CID on-chain, as reported in Table 7.

This demonstrates that, both in terms of gas cost and data upload response time, storing encrypted address data via IPFS provides superior performance compared to direct on-chain storage.

6. Conclusions

This paper proposes a self-sovereign identity (SSI) framework based on protocol tagging, built upon a privacy-enhancing paradigm that combines unlinkable identities with workflow-driven minimal data disclosure. The framework leverages SSI-derived sub-identities to achieve identity unlinkability and employs zero-knowledge proofs (zk-SNARKs) to enable verifiable SSI sub-identity authentication without revealing users’ real-world personal information. Data that must be disclosed in plaintext is protected through layered encryption and selectively decrypted according to workflow-driven policies, ensuring that participants access only the minimal information necessary to complete their tasks. Additionally, the protocol tagging mechanism supports the integration of multiple proof systems within a unified architecture, enhancing scalability and cross-domain interoperability.

As a representative application, we implement this framework in the logistics domain. In this context, sub-identities mitigate correlation attacks, while layered encryption enables the stepwise decryption of delivery addresses throughout the logistics workflow, maximizing user privacy protection while maintaining accountability and auditability across the process.

Future work will focus on two main directions: first, further developing and optimizing finer-grained plaintext selective disclosure paradigms; and second, improving the balance among privacy, computational efficiency, and compliance within the SSI framework.

Furthermore, the framework holds significant potential for deeper integration with mainstream SSI ecosystems, such as W3C Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), enabling further optimization of interoperability. Our protocol tagging mechanism can be further developed to encapsulate existing standard DIDs and VCs into higher-level privacy-preserving units. For example, a W3C-compliant VC can serve as input to the framework to generate a corresponding zero-knowledge proof VC, effectively upgrading from a “proof of possession” to proving attributes without revealing any plaintext information. This design leverages the trust foundations of current SSI ecosystems while providing enhanced privacy protection, offering a feasible pathway toward building a distributed identity network that is both interoperable and privacy-preserving. This will also constitute a key direction for our future research.