Contextual Zero-Knowledge Authentication with IPFS-Backed Hyperledger Fabric for Privacy-Preserving Blood Supply Chain Management

Abstract

Ensuring data security and privacy has emerged as a serious concern in the realm of blood supply chain. This is mainly because of sensitivity of donor information, the involvement of multiple stakeholders, and the need for transparent traceability. This paper proposes a novel privacy-preserving, permissioned blockchain framework for blood supply chain management that integrates Hyperledger Fabric, the InterPlanetary File System (IPFS), and a Zero-Knowledge Proof (ZKP)-based authentication protocol. The framework introduces a Pseudonymous Role-Bound Zero-Knowledge Authentication (PRZKA) mechanism that enables donors to authenticate and authorize access to their medical data without revealing their real identities. Context-specific pseudonyms derived through cryptographic hash-to-curve operations ensure unlinkability across different healthcare interactions, while Schnorr-style challenge–response proofs prevent replay attacks and credential misuse. Sensitive donor information is protected using Fabric Private Data Collections, whereas encrypted medical records are stored off-chain in IPFS, with only secure content identifiers recorded on the blockchain. Smart contracts enforce fine-grained, consent-aware access control policies and maintain immutable audit logs of all access events. The proposed system architecture combines an off-chain ZKP gateway with on-chain authorization logic to minimize blockchain overhead while preserving strong security guarantees. Furthermore, a performance evaluation framework is defined, including metrics, workload scenarios, and system configurations, to support future empirical validation. Security analysis indicates that the proposed framework enhances privacy, prevents identity linkage, and enables auditable, consent-driven data sharing compared with existing blockchain-based healthcare solutions.

1. Introduction

The blood supply chain is a vital component of healthcare. Routine clinical care and emergency response are facilitated through processes such as donor recruitment, collection, testing, storage, logistics, and transfusion. At each stage, sensitive medical and personal data is generated and shared among multiple stakeholders. It is necessary to ensure the confidentiality, integrity, and traceability of this information as it influences clinical safety, regulatory compliance, and public trust. However, conventional centralized systems are often fragmented and siloed. This makes them vulnerable to privacy breaches and transparency issues.

From a privacy perspective, conventional centralized databases expose donors to several risks. Personal health information (PHI) and personally identifiable information (PII) are often stored and processed across multiple organizations. As these organizations follow different security practices, the attack surface for data breaches and unauthorized access increases. Furthermore, existing auditing and logging mechanisms are often fragmented and under the control of individual institutions, making it difficult to obtain an end-to-end, tamper-evident view of who accessed which data, for what purpose, and under whose consent. These issues are particularly problematic in the context of blood donation, where donors must be confident that their sensitive data—such as PII, test results, medical histories, and infectious disease screening outcomes—will be handled with strict confidentiality and in accordance with their preferences.

Blockchain technology offers a promising solution with its distributed, immutable ledgers that provide accountability and traceability. Permissioned platforms such as Hyperledger Fabric align well with healthcare consortia by enabling fine-grained access control. However, naive blockchain adoption can introduce new risks: storing medical data or directly linkable identifiers on-chain exposes donors to re-identification, while certificate-based authentication facilitates activity correlation across contexts. Similarly, while IPFS provides scalable off-chain storage, existing frameworks often lack robust mechanisms for binding content identifiers to consent policies and secure access control. Zero-knowledge proofs (ZKPs) offer a cryptographic means to authenticate without revealing identities, but their integration into permissioned healthcare blockchains remains limited.

This study addresses these gaps by proposing a privacy-preserving framework that integrates Hyperledger Fabric, IPFS, and contextual ZKP-based authentication. The framework enables pseudonymous donor authentication, consent-aware access control, and auditable data sharing while minimizing on-chain exposure of sensitive information. Our contributions include formal algorithms, chaincodes for consent and blood-unit lifecycle management, and a structured security and performance evaluation framework. The security analysis indicates that the proposed architecture enhances privacy, prevents identity linkage, and supports consent-driven data sharing. In addition, a prototype-based evaluation is conducted to assess system feasibility and performance under controlled conditions.

2. Background and Related Work

2.1. Blood Supply Chain and Medical Data Sharing

The blood supply chain encompasses the end-to-end processes from donor recruitment and blood collection through laboratory testing, component preparation, storage, distribution, and transfusion to recipients. Each stage entails multiple stakeholders such as blood centers, hospitals, laboratories, and logistics providers. These systems must exchange sensitive data such as donor demographics, serology, and nucleic acid test results, blood group information, adverse reaction reports, and inventory levels. Regulatory frameworks and standards (e.g., hemovigilance guidelines, national blood policies, and generic health data regulations like GDPR) mandate strict traceability and auditability of blood units and associated medical data over long periods.

Traditional blood information systems are typically centralized within individual organizations, and inter-organizational data sharing is often implemented through bespoke interfaces, batch file exchanges, or manual workflows. This causes problems with interoperability, data duplication, inconsistent records, and limited end-to-end visibility. Donor information is stored in more than one institutional database, which makes it more likely that someone will be able to access it without permission or that data will be stolen. Although role-based access control and audit logs are usually deployed, they are confined to organizational boundaries, making it difficult to obtain a global, tamper-evident view of blood unit histories and data access events across the entire supply chain. These limitations motivate the exploration of distributed ledger technologies as a foundation for trustworthy, cross-organizational data sharing in blood services.

2.2. Blockchain and Hyperledger Fabric in Healthcare

Blockchain technology offers a decentralized, append-only ledger maintained by a consortium of peers, providing integrity, non-repudiation, and transparency for recorded transactions. It is used in the healthcare sector for managing electronic health records, consent management, clinical trial data, and medical supply chains. Public blockchains (such as Ethereum) provide openness and censorship resistance. However, they are often not well-suited for regulated healthcare environments. This is mainly due to performance constraints, limited privacy controls, and the lack of native organizational governance. Permissioned blockchains, by contrast, restrict participation to vetted entities and support configurable consensus and access control mechanisms that better align with healthcare consortia [1,2].

Hyperledger Fabric is a widely adopted permissioned blockchain platform that supports modular consensus, pluggable identity management, and rich chaincode (smart contract) logic. Fabric’s channel abstraction enables subsets of organizations to share a private ledger, while its membership service provider (MSP) enforces organizational identities through X.509 certificates. Recent works applied Fabric to healthcare scenarios for medical data exchange, clinical data sharing, and pharmaceutical supply chain management. These studies demonstrate that Fabric can achieve higher throughput and lower latency than many public blockchains while offering finer-grained access control at the organization level. However, many existing designs either store too much information on-chain, raising privacy concerns, or rely solely on certificate-based identities, which makes it easy to correlate user activities across transactions and applications.

2.3. IPFS and Off-Chain Storage

The InterPlanetary File System (IPFS) is a content-addressable, peer-to-peer file system designed for distributed storage and retrieval. Instead of location-based addressing, IPFS uses cryptographic hashes of file content (content identifiers, CIDs) to reference data objects. This property makes IPFS a natural complement to blockchains: the blockchain can store immutable CIDs as references, while the bulk data—especially large or binary files such as medical images, lab reports, or audit documents—is stored off-chain in a scalable and resilient manner. In healthcare contexts, storing raw medical data directly on-chain is generally infeasible due to size, performance, and privacy constraints; IPFS or similar systems are therefore often used to offload such data.

Existing blockchain-based medical data sharing frameworks [3,4] commonly combine a blockchain for access control and logging with IPFS or cloud storage for encrypted health records. However, these approaches vary significantly in the way they manage encryption keys, consent, and access control at the off-chain layer. Some designs rely on centralized key servers or static encryption schemes, which reintroduce single points of failure and complicated revocation. Others do not fully address how CIDs and encryption keys are bound to patient consent or how accesses are audited across organizational boundaries. For blood supply chains, where data is highly sensitive and long-lived, there is a need for architectures in which IPFS CIDs are tightly integrated with consent-aware policies and traceable access decisions on-chain.

2.4. Zero-Knowledge Proofs and Privacy-Preserving Authentication

Zero-knowledge proofs (ZKPs) are cryptographic protocols that allow a prover to convince a verifier that a statement is true without revealing any information beyond the validity of the statement itself. In authentication contexts, ZKPs are especially attractive because they can prove possession of a secret (e.g., a private key or credential) without exposing the secret or enabling straightforward linkage across different uses of that secret. Classical Sigma protocols such as Schnorr’s proof of knowledge, as well as more recent succinct non-interactive arguments of knowledge (SNARKs, STARKs), have been applied to privacy-preserving identity systems, anonymous credentials, and confidential transactions.

In blockchain systems, ZKPs have been used to hide transaction amounts and participants (e.g., in privacy-focused cryptocurrencies), to enforce access policies over encrypted data, and to provide selective disclosure of credentials. However, most applications in healthcare so far have focused on basic pseudonymity or differential privacy [5,6,7,8,9] and relatively few works integrate ZKPs [10,11] into permissioned blockchain-based medical data sharing. Many proposed healthcare blockchains [12,13,14,15,16,17] rely on traditional public-key based authentication, where a user’s certificate or address is directly visible on-chain, enabling longitudinal tracking and correlation. There is therefore an opportunity to design ZKP-based authentication schemes tailored to permissioned settings, where organizations are known but end users (e.g., donors or patients) require stronger privacy guarantees such as contextual pseudonymity and unlinkability across data-sharing scenarios.

2.5. Existing Blockchain-Based Healthcare Systems and the Gaps

Existing studies in this domain can be broadly categorized into three groups: (i) architectural blockchain-based healthcare systems, (ii) cryptographic privacy-preserving mechanisms, and (iii) healthcare supply chain applications. Architectural approaches focus on secure data sharing platforms, cryptographic methods emphasize confidentiality and access control, while supply chain systems address traceability and logistics management. However, limited work integrates all three aspects into a unified framework.

At a high level, existing approaches often address these aspects in isolation. Architectural solutions lack strong privacy guarantees, cryptographic methods are not tightly integrated with system-level workflows, and supply chain systems provide limited support for fine-grained consent and anonymity. This gap highlights the need for an integrated framework that combines secure architecture, privacy-preserving authentication, and traceable supply chain management, as proposed in this work.

Several blockchain-based healthcare systems have been proposed in the literature [18]. One of the earliest efforts uses Ethereum smart contracts to manage references to electronic medical records and access control lists, focusing on patient-centric control and auditability [19], and leverages blockchain concepts to secure clinical data exchange following standards, emphasizing data provenance and integrity. Other proposals use blockchain to manage consent directives, clinical trial records, and various medical supply chains, including pharmaceuticals and vaccines. Some works [20,21,22,23,24,25] employ IPFS or cloud storage to hold actual health records, with the blockchain storing only metadata and access policies.

Despite these advances, existing systems exhibit several limitations when evaluated against the specific requirements of blood supply chains. First, many frameworks are designed for general electronic health records and do not explicitly model the end-to-end lifecycle of blood units, including collection, testing, logistics, and transfusion. Second, identity and access management often rely on static public keys or role-based permissions, providing limited privacy against colluding observers and little support for contextual pseudonyms or zero-knowledge-based authentication. Third, consent management is frequently coarse-grained, with few systems offering fine-grained, purpose-aware consent enforcement that is tightly integrated with access logging. Finally, while some systems use IPFS for off-chain storage, they rarely articulate a detailed mechanism for binding IPFS CIDs, encryption keys, and on-chain consent and logging in a way that minimizes privacy leakage.

These gaps highlight the need for a dedicated framework that (i) targets the specific workflows and traceability requirements of blood supply chain management, (ii) leverages Hyperledger Fabric’s permissioned model and private data collections, (iii) integrates IPFS for encrypted off-chain storage of medical data, and (iv) incorporates contextual zero-knowledge authentication to protect donor identities while still enabling auditable, consent-aware data sharing. The framework proposed in this paper seeks to address these gaps by combining these building blocks into a coherent architecture and by providing formal algorithms and chaincodes tailored to the blood supply chain domain.

3. System Requirements, Threat Model, and Methodology

3.1. System Requirements and Design Goals

The proposed framework is intended to support secure, privacy-preserving medical data sharing across organizations involved in the blood supply chain. The system requirements are prioritized to balance privacy, performance, and usability. High-priority requirements include privacy preservation and consent enforcement, followed by traceability and auditability, while transparency-related features are considered lower priority due to their potential impact on performance. Based on the literature review and domain analysis, we identify the following functional requirements:

• Donor registration and pseudonymous identification: The system must support registering donors with a pseudonymous identifier (donorRegID) that can be used across the blockchain network without exposing real-world identities. It should be possible to link multiple blood donations and related medical data to the same donorRegID while keeping personally identifiable information (PII) off-chain or in restricted private data collections.
• Consent management and policy enforcement: Donors must be able to define and update consent preferences specifying which organizations (e.g., hospitals, blood banks) may access which types of data (e.g., lab results, donation history) for which purposes (e.g., treatment, research). The system must enforce these consent policies at access time, and every access decision must be logged.
• Secure medical data storage and sharing: Sensitive donor-related medical data (test results, transfusion records, etc.) must be stored in encrypted form off-chain (e.g., in IPFS), with only content identifiers and minimal metadata stored on-chain. Authorized parties should be able to retrieve and decrypt the data when permitted by donor consent.
• Blood-unit lifecycle tracking: The system must represent and track the lifecycle of individual blood units, including collection, testing outcomes, labeling, shipment, receipt at hospitals, and final outcome (transfused/discarded). Such tracking should be tamper-evident and easy to query for audit and hemovigilance purposes.
• Donor transparency and auditability: Donors should be able to query their own consent preferences, see what categories of data are stored, and inspect logs of recent access events and the status of blood units derived from their donations.

Alongside these, the following non-functional design goals are critical:

• Privacy and unlinkability: The system should minimize on-chain disclosure of PII and support contextual pseudonyms so that donor activities in different organizational or purpose contexts cannot be trivially linked. Zero-knowledge proofs should be used to decouple authentication from identity revelation.
• Integrity, traceability, and accountability: All critical events—such as consent updates, access decisions, and blood-unit state transitions—must be recorded on an immutable ledger, enabling end-to-end traceability and post hoc auditing.
• Scalability and performance: The framework should be compatible with realistic throughput and latency requirements of blood services. Off-loading large data to IPFS and restricting the on-chain state to metadata and logs are key to achieving scalability.
• Regulatory alignment and fine-grained control: The design must support governance structures that reflect real healthcare consortia and provide fine-grained control over which organizations can see which data, aligning with privacy regulations and blood safety requirements.
• Modularity and deployability: Core components—Hyperledger Fabric network, IPFS storage, ZKP gateway, and identity authority—should be loosely coupled so that they can be deployed, scaled, or upgraded independently.

These requirements and goals guide the architectural choices and cryptographic mechanisms in the proposed framework.

3.2. Threat Model and Assumptions

Formally, the system aims to ensure that for any access request r, access is granted if and only if it satisfies the defined consent policies, while preserving anonymity and unlinkability under the specified adversarial model. The threat model considers both external and internal adversaries, as well as the specific privacy and integrity risks associated with blood supply chain data.

3.2.1. Adversaries and Capabilities

• External network attacker: An adversary can eavesdrop on, intercept, and replay network traffic between user applications, the gateway, the blockchain network, and IPFS nodes. They may attempt to impersonate donors or authorized institutions, or to replay old authentication transcripts and access requests.
• Curious or malicious insiders: Users or administrators at participating organizations (e.g., hospitals, blood banks, labs) may have legitimate access to parts of the system but may attempt to access donor data beyond their authorization, correlate donor activities across contexts, or tamper with local logs. Multiple insiders across organizations may collude and share data.
• Compromised client devices: Donor devices (e.g., smartphones) may be compromised by malware, leading to theft of cryptographic material or unauthorized use of legitimate credentials. We assume that device compromise is possible but aim to reduce the impact on on-chain privacy (e.g., prevent long-term identity linkage even if keys leak).
• Curious storage and infrastructure operators: IPFS node operators, cloud providers, and some blockchain peers may be honest-but-curious: they follow the protocol but attempt to infer donor identities or medical details from stored data and metadata.

3.2.2. Assumptions

• Cryptographic hardness: The underlying group operation (e.g., discrete logarithm in an elliptic curve group) is secure, and hash functions behave as random oracles for the zero-knowledge proofs and pseudonym derivation.
• Correctness of identity, authority, and MSP: The Identity Authority truthfully binds real-world donor identities to public keys and donorRegIDs, and the Fabric Membership Service Provider correctly manages organization identities. These components may be curious but are not assumed to be arbitrarily malicious (e.g., they do not forge donor identities at scale).
• Honest majority in consensus: As is standard in permissioned Fabric deployments, we assume that a sufficient fraction of ordering and endorsing organizations are honest, so that the ledger’s immutability and consensus guarantee hold.
• Secure channels between gateway and Fabric/IPFS: Communications between the ZKP gateway and the Fabric peers, as well as between the gateway and IPFS, use authenticated and encrypted channels (e.g., TLS), preventing trivial man-in-the-middle attacks at the transport layer.
• No sensors or real-time actuation dependencies: While the framework supports recording temperature and lifecycle events, we do not assume active sensor–actuator control loops; thus, real-time control attacks are out of scope.

Under this threat model, the framework aims to provide: (i) confidentiality of donor PII and medical data, (ii) unlinkability of donor actions across contexts from the perspective of general blockchain observers, (iii) resistance to network-level replay and impersonation attacks via nonce-based ZKP and AuthProofID tracking, and (iv) tamper-evident logging to deter and detect insider misuse.

3.3. Methodology

A design-science research (DSR) methodology was adopted for the development and systematic analysis of a privacy-preserving framework for blood supply chain management. The methodology was structured into three stages: problem identification and requirement analysis, conceptual system design, and evaluation (analytical and prototype-based).

In the initial stage, domain-specific challenges were analyzed, and system requirements were derived. A structured review of academic literature and industry practices was conducted, covering blood supply chain management, blockchain in healthcare, InterPlanetary File System (IPFS)-based data sharing, and zero-knowledge proof (ZKP) mechanisms. Relevant regulatory guidelines and best practices related to hemovigilance and health data protection were also examined.

Based on this review, the functional and non-functional requirements (Section 3.1) and the threat model (Section 3.2) were derived. Particular attention was given to the identification of limitations in existing systems, especially with respect to privacy-preserving authentication, consent-aware access control, and end-to-end traceability of blood units.

In the second stage, the identified requirements were translated into a conceptual architectural framework and formally specified protocols. The architecture was composed of a permissioned blockchain platform (Hyperledger Fabric), an IPFS-based off-chain storage layer, and a ZKP-enabled authentication gateway.

A contextual zero-knowledge authentication protocol tailored to the permissioned setting was formally defined. Data models for donor pseudonyms, consent records, IPFS references, and blood unit entities were specified to support secure and privacy-aware data management. Core system functionalities—including consent management, access authorization, authentication token handling, transparency queries, and lifecycle tracking—were described using algorithmic representations and workflow models.

In the final stage, the proposed framework was evaluated using a combination of analytical and prototype-based methods. A detailed security and privacy analysis was conducted with respect to the defined threat model, examining properties such as resistance to replay attacks, mitigation of identity leakage, robustness against insider threats, and enforcement of consent-driven access control.

To provide a structured evaluation framework, the proposed system is assessed across three dimensions: (i) performance efficiency, measured using latency and throughput; (ii) security and privacy guarantees, evaluated based on unlinkability, replay resistance, and confidentiality; and (iii) system behavior under varying workload conditions. These dimensions serve as formal evaluation criteria for validating the proposed architecture.

In addition, a prototype implementation was deployed in a controlled test environment to enable preliminary empirical evaluation of selected system components. Key metrics, including transaction latency, throughput, and chaincode execution time, were measured under representative workload conditions. These results provide indicative performance insights into the feasibility of the proposed architecture under controlled conditions.

It should be noted that the evaluation is limited to a controlled prototype environment, and large-scale deployment under real-world conditions remains outside the scope of this study and is identified as future work.

The design-science methodology is selected due to its suitability for developing and evaluating system architectures, where the primary objective is artifact design, iterative refinement, and controlled evaluation rather than purely hypothesis-driven experimentation. Alternative research methodologies, including experimental, simulation-based, and analytical approaches, were considered. Experimental methods require large-scale deployment and real-world datasets, which are not feasible at the current stage. Simulation-based approaches provide performance approximations but do not fully capture interactions between blockchain, off-chain storage, and cryptographic mechanisms. Analytical approaches offer theoretical insights but lack system-level validation. Therefore, the design-science approach is considered more appropriate, as it enables integrated system design and controlled prototype-based evaluation of complex, multi-component systems.

4. Proposed Framework and Architecture

4.1. High-Level Architecture

The proposed framework consists of four main layers: the user layer, the ZKP-enabled API gateway, the permissioned blockchain network, and the off-chain storage and identity services.

At the user layer, donor mobile applications, blood bank systems, hospital information systems, laboratory systems, and regulator dashboards provide interfaces for registering donors, recording donations and tests, requesting access to medical data, and performing audits. These clients do not interact directly with the blockchain; instead, all blockchain-related operations are mediated by a gateway.

The API and ZKP gateway layer exposes a set of REST or gRPC endpoints through which user applications submit requests. This component is responsible for executing the contextual zero-knowledge authentication protocol with donor applications, verifying proofs, deriving authentication tokens (AuthProofID), and encapsulating all interactions with the Hyperledger Fabric network and IPFS. By terminating client connections and performing cryptographic operations off-chain, the gateway decouples complex ZKP logic from the blockchain and allows for flexible cryptographic upgrades.

The blockchain network layer is to be implemented using Hyperledger Fabric. It comprises multiple organizations—such as donor services, blood banks, hospitals, laboratories, logistics providers, and regulators—each operating one or more peers and participating in a shared channel. An ordering service establishes consensus on transaction order. Key smart contracts (chaincode) deployed on the channel include: (i) a consent and data-management contract that handles donor consent records, IPFS data pointers, authentication token tracking, and access logging, and (ii) a blood-unit management contract that records the lifecycle of individual blood units. Fabric’s private data collections are used to store sensitive donor PII and key mappings accessible only to a subset of trusted organizations.

The off-chain storage and identity layer consists of an IPFS cluster and an Identity Authority (IA) service. Encrypted medical data (e.g., laboratory reports, transfusion records) is stored in IPFS, and only its content identifiers (CIDs) are referenced from the blockchain. The IA manages mappings between real-world donor identities, blockchain-level pseudonyms (donorRegID), and cryptographic public keys, and can optionally replicate selected records in Fabric private data collections. This split architecture allows sensitive data and identity information to be kept off-chain or in restricted collections while still benefiting from a shared, tamper-evident ledger for metadata and access events.

Figure 1 depicts these layers and their interactions: user applications communicate with the ZKP gateway, which in turn interacts with Fabric peers via the Fabric SDK, and with IPFS nodes via HTTP or native IPFS protocols. Fabric peers maintain the ledger and execute chaincode, while the ordering service and MSP infrastructure provide consensus and organizational identity management.

4.2. Entities, Roles, and Data Model

The framework involves the following key entities and roles:

• Donor: An individual who donates blood and whose medical and personal data must be protected. Donors interact through a mobile or web application to register, manage consent, and approve data access.
• Blood bank/collection center: Organizations responsible for recruiting donors, collecting blood, and performing initial processing steps. They register donations and blood units on the blockchain and may access donor data for operational purposes.
• Laboratory: Entities that perform infectious disease screening and other tests. They generate test results, upload encrypted reports to IPFS, and register corresponding data pointers and testing outcomes on-chain.
• Hospital/clinic: Institutions that request access to donor-related medical data (e.g., test results, donation history) in order to support transfusion decisions and hemovigilance activities. They also receive, store, and transfuse blood units, updating the on-chain blood-unit state.
• Logistics provider: Organizations that transport blood units between sites, optionally contributing temperature and location data for cold-chain monitoring.
• Regulator/oversight body: Authorities that monitor compliance, perform audits, and analyze aggregated data. They primarily use read-only queries over the ledger and logs.
• Identity Authority (IA): A trusted or semi-trusted service that binds real-world donor identities to cryptographic keys and pseudonymous identifiers, and manages the issuance of long-term public keys used in the ZKP protocol.
• ZKP gateway: An off-chain component that performs donor authentication using zero-knowledge proofs, derives context-bound pseudonyms, and mediates access requests to the blockchain and IPFS.

The data model includes several core objects:

• Donor identifier (donorRegID): A pseudonymous identifier used to represent donors on-chain. It serves as the key for consent records and references to donor data, but is not directly linkable to real-world identity without IA cooperation or access to private collections.
• Contextual pseudonym (Pctx): A cryptographic pseudonym derived from the donor’s long-term secret and a specific context (combining donorRegID, requesting organization, purpose, etc.). It is used during authentication and may be logged to support accountability while limiting cross-context linkability.
• Consent record: A structured object mapping data types and purposes to allowed organizations or roles, versioned and timestamped. It is stored on-chain in a consent state database keyed by donorRegID.
• IPFS content identifiers (CIDs): Content-addressed identifiers referencing encrypted medical data stored in IPFS. For each donor and data type, a data pointer record binds donorRegID, dataType, and ipfsCID.
• Blood unit record: A stateful object representing an individual blood unit, keyed by a unique unitID and containing fields such as donorRegID, blood type, collection site, current location, testing result, assignment to hospital and patient, status (collected, tested, labeled, in transit, at hospital, transfused, discarded), and optional temperature profile identifiers.
• Access log entry: A record capturing an access decision, including donorRegID, requestorID, dataType, purpose, decision (allow/deny), AuthProofID, pseudonymCtx, and timestamp. These logs form the basis for audit and compliance analysis.
• Temperature reading (optional): A record containing a profileID, timestamp, location, and temperature value; profileIDs link sequences of readings to one or more blood units.

This data model is realized in Fabric as key-value entries in the world state and private data collections, with JSON-encoded values, enabling chaincode to perform deterministic operations on these objects.

To ensure data integrity and scalability, identifier collisions are mitigated using cryptographic hashing mechanisms. Schema evolution is supported through version-controlled data structures, and data migration can be handled via updated IPFS content identifiers without affecting blockchain references.

4.3. System Data Flows

The proposed framework begins with donor registration, where the Identity Authority verifies real identities, generates cryptographic key pairs, and issues pseudonymous identifiers (donorRegID) linked to consent records stored on-chain while keeping personally identifiable information off-chain. Laboratories encrypt medical data and upload it to IPFS, registering immutable pointers on the blockchain that bind donorRegID, data type, and content identifiers. When hospitals request access, the Zero-Knowledge Proof (ZKP) gateway initiates contextual authentication, allowing donors to prove possession of their secret keys through pseudonyms without revealing identities. Successful proofs generate AuthProofIDs, which are submitted to the blockchain for consent-aware authorization. Chaincode enforces donor preferences, prevents replay attacks, and logs all access events, returning IPFS pointers only when conditions are met. The gateway then retrieves and decrypts the data off-chain, delivering it securely to authorized parties. In parallel, blood banks and hospitals use dedicated chaincode to track blood-unit lifecycles, recording collection, testing, labeling, shipment, hospital receipt, transfusion outcomes, and optional temperature profiles. Together, these flows establish a privacy-preserving, auditable, and scalable system that ensures secure donor data sharing and end-to-end traceability across the blood supply chain.

Figure 2 summarizes how donor identities, consent, medical data, blood units, and logs move between components, while Figure 3 illustrates the detailed interaction between donor application, ZKP gateway, Fabric network, chain code, and IPFS during an access request. Together, these flows show how the framework achieves consent-aware, privacy-preserving data sharing and traceable blood-unit management across organizational boundaries.

5. ZKP-Based Authentication and Privacy Mechanism

This section specifies the zero-knowledge proof (ZKP) protocol used for donor authentication in the proposed framework. The protocol allows a donor to prove control of a long-term secret key without revealing it and without allowing linkability of the donor across different organizations or purposes.

5.1. Cryptographic Setting and Notation

• Group and generator: Let G be a cyclic group of prime order q with generator g. We assume that the discrete logarithm problem (DLP) in G is hard: given g and h = g^a for a chosen uniformly at random in Z_q, no probabilistic polynomial-time algorithm can compute a with non-negligible probability. In implementations, G may be taken as a prime-order subgroup of an elliptic curve (e.g., BLS12-381 or secp256k1).
• Hash functions: H_ctx: {0,1}* → G is a hash-to-group function. We assume it is collision-resistant and that its outputs are distributed negligibly close to uniform in G for random inputs (random-oracle style). H_chal: {0,1}* → Z_q is used for Fiat–Shamir challenge derivation and is modeled as a random oracle.

The meaning of the notations are given in Table 1.

Table 1. Notation used.

Symbol	Meaning
a ← S (random)	a chosen uniformly at random from set S
‖	String concatenation
Y	Donor long-term public key, Y = gx
x	Donor long-term secret key, x ∈ Zq
donorRegID	Donor’s pseudonymous on-chain identifier
ctx	Context string (see Section 5.2)
hctx	Hctx(ctx)
Pctx	Contextual pseudonym hctx^x
nv	Verifier nonce, chosen at random from {0, 1}λ
meta	Optional metadata (purpose, consent id, etc.)
AuthProofID	One-time authentication token sent to chaincode

Table 1. Notation used.

Symbol	Meaning
a ← S (random)	a chosen uniformly at random from set S
‖	String concatenation
Y	Donor long-term public key, Y = gx
x	Donor long-term secret key, x ∈ Zq
donorRegID	Donor’s pseudonymous on-chain identifier
ctx	Context string (see Section 5.2)
hctx	Hctx(ctx)
Pctx	Contextual pseudonym hctx^x
nv	Verifier nonce, chosen at random from {0, 1}λ
meta	Optional metadata (purpose, consent id, etc.)
AuthProofID	One-time authentication token sent to chaincode

• Identity Authority (IA): The IA generates (x, Y) per donor, assigns donorRegID, and stores (RealID, donorRegID, Y). The donor receives x (and optionally a certificate for Y) via a secure channel. The IA does not participate in the ZKP; it only provides Y to the gateway when needed for verification.

5.2. Context-Bound Pseudonyms and Identity Model

 Definition 1  

(Context). A context is the string ctx = donorRegID ‖ verifierID ‖ purpose ‖ epoch, where verifierID identifies the requesting organization, purpose is the declared use (e.g., TREATMENT, RESEARCH), and epoch is an optional session or time identifier.

 Definition 2  

(Contextual pseudonym). For context ctx, the contextual pseudonym is

P_ctx = h_ctx^x ∈ G where h_ctx = H_ctx(ctx)

Different contexts yield different h_ctx (with overwhelming probability), hence the different P_ctx. Under the DLP and the random-oracle assumption on H_ctx, an adversary that sees only public data and multiple P_ctx values cannot determine whether they correspond to the same x (same donor).

5.3. ZKP Protocol and Algorithm

The protocol proves knowledge of x such that Y = g^x and P_ctx = h_ctx^x in three moves as shown in Algorithm 1: commitment (t₁, t₂), challenge c, response s. The challenge is computed as c = H_chal(⋯) and includes a verifier nonce n_v, so the proof is bound to one session.

Algorithm 1: ZKPAuthenticateAndIssueToken (Verifier/Gateway Side)

Input: Context ctx, metadata meta; prover inputs (P_tx, t1, t2, z, n) Output: Authentication proof identifier AuthProofID and transaction reference P_tx on success; ⊥ otherwise Steps: 1: Compute h_ctx ← H_ctx(ctx) 2: Compute challenge c ← H_chal(g ∥ Y ∥ h_ctx ∥ P_tx ∥ t1 ∥ t2 ∥ n ∥ meta) 3: If (g^z ≠ t1 · Y^c) OR (h_ctx ≠ t2 · P_tx^c) then 4:   return ⊥ 5: end if 6: Compute AuthProofID ← H_bind(“auth” ∥ P_tx ∥ ctx ∥ n ∥ meta ∥ gateway) 7: Return (AuthProofID, P_tx)

Prover steps (donor application): Compute h_ctx = H_ctx(ctx) and P_ctx = h_ctx^x; receive n_v; choose r uniformly at random in Z_q; set t₁ = g^r and t₂ = h_ctx^r; set c = H_chal(g ‖ Y ‖ h_ctx ‖ P_ctx ‖ t₁ ‖ t₂ ‖ n_v ‖ meta) and s = r + c · x (mod q); send (P_ctx, t₁, t₂, s, n_v, meta).

Correctness: For s = r + c · x we have g^s = t₁ · Y^c and h_ctx^s = t₂ · P_ctx^c, so an honest prover is always accepted.

From a computational perspective, ZKP verification involves modular exponentiation and hash operations, which introduce additional overhead compared to conventional authentication methods. However, as shown in Section 8.1.1, the observed verification latency remains within acceptable bounds (8–15 ms), demonstrating practical feasibility even under moderate load conditions.

Compared to zk-SNARK-based approaches, which typically require a trusted setup and incur higher proving overhead, the adopted Schnorr-style ZKP offers lower computational complexity and faster verification, making it more suitable for real-time healthcare applications.

5.4. Security Properties

We state the main guarantees and how they address specific threats.

Soundness: Any efficient prover that is accepted with non-negligible probability can be rewound to obtain two accepting transcripts with the same (t₁, t₂) and different challenges c, c′; then x = (s − s′)(c − c′)⁻¹ mod q is extracted. Thus, only a party that knows x can authenticate, and impersonation without x would contradict the hardness of the DLP.

Zero-knowledge: There is an efficient simulator that, without x, samples c and s uniformly at random in Z_q and sets t₁ = g^s Y^−c and t₂ = h_ctx^s P_ctx^−c, producing transcripts indistinguishable from real ones (honest-verifier zero-knowledge; in the Fiat–Shamir setting, in the random-oracle model). Thus the protocol does not leak x or any other private information beyond the fact that the statement holds.

The security of the ZKP protocol is grounded in standard Sigma-protocol constructions, where completeness, soundness, and zero-knowledge properties are ensured under the random oracle model. While a full formal reduction proof is beyond the scope of this work, the protocol follows well-established Sigma-protocol constructions, and its security is grounded in the hardness of the discrete logarithm problem under the random oracle model.

Unlinkability: For ctx₁ ≠ ctx₂, H_ctx(ctx₁) and H_ctx(ctx₂) are independent random group elements; hence P_ctx1 and P_ctx2 are computationally indistinguishable from two independent random elements. Thus an adversary that sees only public parameters and pseudonyms cannot link different contexts to the same donor without breaking the DLP or the Identity Authority.

Replay resistance: (i) Using the same (t₁, t₂, s) with a new nonce n_v′ yields a different challenge c′, so the verification equations fail. (ii) The chaincode stores each used AuthProofID and rejects duplicates, so a single proof cannot authorize more than one access transaction.

These four properties ensure that authentication is bound to knowledge of x, that no secret information is leaked, that donors are unlinkable across contexts, and that both proof-level and transaction-level replay are prevented. Section 6 uses AuthProofID and P_ctx in the consent-aware access control and logging flow.

6. Blockchain Smart Contracts and Algorithms

6.1. Consent and Data Pointer Management

Donor consent and the mapping between donors and off-chain medical data, as illustrated in Figure 4 are maintained on-chain through two algorithm groups: one for consent records (Algorithm 2) and one for IPFS data pointers (Algorithm 3).

Algorithm 2: DonorConsentManager

Input: Operation op ∈ {REGISTER, UPDATE, GET}, donorRegID, consentData Output: Success, error, or consent record 1: stateKey ← “CONSENT_” + donorRegID 2: if op = REGISTER then 3:    if StateExists(stateKey) then 4:      return error “Consent already exists” 5:    end if 6:    consent ← Initialize consent record using consentData 7:    consent.version ← 1 8:    consent.timestamp ← CurrentUTCTime() 9:    Store consent in ledger 10:     return success 11: else if op = UPDATE then 12:     if NOT StateExists(stateKey) then 13:      return error “Consent not found.” 14:     end if 15:     oldConsent ← Retrieve consent from ledger 16:     newConsent ← Update oldConsent using consentData 17:     newConsent.version ← oldConsent.version + 1 18:     newConsent.timestamp ← CurrentUTCTime() 19:     Store updated consent 20:     Trigger consent update event 21:     return success 22: else if op = GET then 23:     if NOT StateExists(stateKey) then 24:      return error “Consent not found” 25:     end if 26:     return Retrieve consent from ledger

Algorithm 3: DataPointerManager

Input: Operation op ∈ {REGISTER, GET_ONE, LIST_ALL}, donorRegID, dataType, ipfsCID Output: Data pointer, list of pointers, success, or error 1: if op = REGISTER then 2:  key ← “DATA_” + donorRegID + “_” + dataType 3:   if StateExists(key) then 4:    return error “Pointer already exists” 5:   end if 6:  ptr ← Create data pointer record (donorRegID, dataType, ipfsCID) 7:  Store ptr in ledger 8:  return success 9: else if op = GET_ONE then 10:  key ← “DATA_” + donorRegID + “_” + dataType 11:  if NOT StateExists(key) then 12:   return error “Pointer not found” 13:  end if 14:  return Retrieve pointer from ledger 15: else if op = LIST_ALL then 16:   prefix ← “DATA_” + donorRegID 17:   ptrList ← RetrieveAllPointersMatchingPrefix(prefix) 18:   return ptrList

6.2. Authentication Token Tracking and Access Control

Access to donor medical data is granted only when the request satisfies current consent and when the authentication token supplied by the gateway has not been used before. This prevents replay of a single donor authentication across multiple access transactions. Algorithm 4 depicts the process.

The gateway first runs the ZKP protocol (Algorithm 1, Section 5.3) with the donor to obtain AuthProofID and P_ctx, then invokes the chaincode implementing Algorithm 3 with these parameters.

Algorithm 4: AuthAndAccessController

Input: requestorID, donorRegID, dataType, purpose, authProofID, pseudonymCtx Output: ipfsCID or empty string “” 1: authKey ← “AUTH_” ∥ authProofID 2: if GetState(authKey) ≠ null then 3:   return LogAndReturn(DENY, “”) 4: record ← {used ← true, timestamp ← CurrentUTCTime()} 5: PutState(authKey, Serialize(record)) 6: consent ← DonorConsentManager(GET, donorRegID, ∅) 7: if IsAllowed(consent.preferences, requestorID, dataType, purpose) = false then 8:   return LogAndReturn(DENY, “”) 9: ptr ← DataPointerManager(GET_ONE, donorRegID, dataType, ∅) 10: if ptr = null then 11:   return LogAndReturn(DENY, “”) 12: return LogAndReturn(ALLOW, ptr.ipfsCID) Subroutine 1. IsAllowed Input: prefs, requestorID, dataType, purpose Output: true or false 1: if prefs.AllowedData[dataType] ≠ true then 2:   return false 3: if prefs.AllowedPurposes[purpose] = undefined then 4:   return false 5: return (requestorID ∈ prefs.AllowedPurposes[purpose]) Subroutine 2. LogAndReturn Input: decision, ipfsCID Output: ipfsCID or “” 1: log ← {donorRegID, requestorID, dataType, purpose, decision, authProofID,      pseudonymCtx, timestamp ← CurrentUTCTime()} 2: key ← “ACCESS_” ∥ donorRegID ∥ “_” ∥ CurrentUTCTimeNano() ∥ “_” ∥ requestorID    ∥ “_” ∥ dataType 3: PutState(key, Serialize(log)) 4: if decision = ALLOW then 5:   return ipfsCID 6: else 7:   return “ ”

Figure 5 illustrates the flow: the hospital (or donor) application requests access from the gateway; the gateway runs the ZKP protocol with the donor application and obtains (AuthProofID, P_ctx); the gateway calls the chaincode with AuthorizeAndLogAccess (or the equivalent AuthAndAccessController interface) with the parameters above; the chaincode executes the consent, replay, and pointer checks and returns the CID or a denial; and the gateway retrieves and decrypts data from IPFS when access is allowed. The diagram clarifies the separation between off-chain ZKP verification and on-chain policy enforcement and logging.

6.3. Donor Transparency APIs

Donors can query (as shown in Algorithm 5) their own consent state and access history through read-only chaincode functions that aggregate data stored under consent and access keys.

Algorithm 5: DonorQueryAPI

Input: op ∈ {SUMMARY, ACCESS_LOGS}, donorRegID, maxResults (for ACCESS_LOGS) Output: summary record (for SUMMARY) or list of access logs (for ACCESS_LOGS) 1: if op = SUMMARY then 2:    consent ← DonorConsentManager(GET, donorRegID, ∅) 3:    dataList ← DataPointerManager(LIST_ALL, donorRegID, ∅, ∅) 4:    iter ← GetStateByPrefix(“ACCESS_” ∥ donorRegID ∥ “_”) 5:    count ← 0 6:    for each kv in iter do 7:      count ← count + 1 8:    endfor 9:    return {donorRegID, consent, registeredData ← [ptr.dataType for ptr in dataList],          accessLogCount ← count, summaryGeneratedAt ← CurrentUTCTime()} 10:  registeredData ← [ptr.dataType for each ptr in dataList] 11:  summary ← ⟨          donorRegID,          consent,          registeredData,          accessLogCount = count,          summaryGeneratedAt = CurrentUTCTime()      ⟩ 12:   return summary 13: else if op = ACCESS_LOGS then 14:    if maxResults ≤ 0 then 15:         maxResults ← 50 16:    end if 17:  iter ← GetStateByPrefix(“ACCESS_” + donorRegID + “_”) 18:   logs ← [ ] 19:   while iter.HasNext() and |logs| < maxResults do 20:       kv ← iter.Next() 21:      logs.Append(Parse(kv.value)) 22: end while 23: return logs

6.4. Blood-Unit Lifecycle and Temperature/Cold-Chain Monitoring

The framework tracks individual blood units from collection through testing, shipment, receipt, and final outcome, and optionally records temperature readings for cold-chain monitoring. The steps involved are illustrated in Figure 6 and Algorithms 6–9.

Algorithm 6: BloodUnitManager

Input: op ∈ {REGISTER, TEST, LABEL, ASSIGN, SHIP, RECEIVE, FINALIZE, GET}, params Output: unit or success/error 1: if op = REGISTER then 2:   (unitID, donorRegID, bloodType, collectionSiteID, tempProfileID) ← params 3:   key ← “UNIT_” ∥ unitID 4:   if GetState(key) ≠ null then 5:     return error “unit exists” 6:   now ← CurrentUTCTime() 7:   unit ← {unitID, donorRegID, bloodType, collectionSiteID,         currentLocationID ← collectionSiteID, status ← COLLECTED,         createdAt ← now, updatedAt ← now, testingResult ← PENDING,         testingMetadataCID ← “”, temperatureProfileID ← tempProfileID,         assignedHospitalID ← “”, assignedPatientID ← “”, outcomeNote ← “”} 8:   PutState(key, Serialize(unit)) 9:   return success 10: if op = GET then 11:   (unitID) ← params 12:   bytes ← GetState(“UNIT_” ∥ unitID) 13:   if bytes = null then 14:    return error “not found” 15:   return Parse(bytes) 16: unit ← BloodUnitManager(GET, (params.unitID)) 17: if op = TEST then 18:   (unitID, testingResult, testCID) ← params 19:   unit.testingResult ← testingResult 20:   unit.testingMetadataCID ← testCID 21:   unit.status ← TESTED 22: if op = LABEL then 23:   (unitID, labelLocationID) ← params 24:   unit.status ← LABELED 25:   unit.currentLocationID ← labelLocationID 26: if op = ASSIGN then 27:   (unitID, hospitalID, patientID) ← params 28:   unit.status ← ASSIGNED 29:   unit.assignedHospitalID ← hospitalID 30:   unit.assignedPatientID ← patientID 31: if op = SHIP then 32:   (unitID, logisticsLocationID) ← params 33:   unit.status ← IN_TRANSIT 34:   unit.currentLocationID ← logisticsLocationID 35: if op = RECEIVE then 36:   (unitID, hospitalID) ← params 37:   unit.status ← AT_HOSPITAL 38:   unit.currentLocationID ← hospitalID 39:   if unit.assignedHospitalID = “” then 40:     unit.assignedHospitalID ← hospitalID 41: if op = FINALIZE then 42:   (unitID, outcome, outcomeNote) ← params 43:   if UPPER(outcome) = TRANSFUSED then 44:     unit.status ← TRANSFUSED 45:   else if UPPER(outcome) = DISCARDED then 46:     unit.status ← DISCARDED 47:   else 48:     return error “invalid outcome” 49:   unit.outcomeNote ← outcomeNote 50: unit.updatedAt ← CurrentUTCTime() 51: PutState(“UNIT_” ∥ unit.unitID, Serialize(unit)) 52: return success

Algorithm 7: BloodUnitQueryAPI

Input: op ∈ {BY_DONOR, BY_STATUS}, filter (donorRegID or status), maxResults Output: list of BloodUnit 1: if maxResults ≤ 0 then 2:   maxResults ← 100 3: iter ← GetStateByRange(“UNIT_”, “UNIT_~”) 4: list ← ∅ 5: while iter.HasNext() and |list| < maxResults do 6:   kv ← iter.Next() 7:   u ← Parse(kv.value) 8:   if op = BY_DONOR and u.donorRegID = filter then 9:     list.Append(u) 10:   if op = BY_STATUS and u.status = UPPER(filter) then 11:     list.Append(u) 12: return list

Algorithm 8: TemperatureManager

Input: op ∈ {APPEND, GET}, profileID, location, valueC (for APPEND), maxResults (for GET) Output: success/error or list of TemperatureReading 1: if op = APPEND then 2:    reading ← {profileID, timestamp ← CurrentUTCTime(), location, valueC} 3:    key ← “TEMP_” ∥ profileID ∥ “_” ∥ reading.timestamp 4:    PutState(key, Serialize(reading)) 5:    return success 6: if op = GET then 7:    if maxResults ≤ 0 then 8:     maxResults ← 200 9:    prefix ← “TEMP_” ∥ profileID ∥ “_” 10:  iter ← GetStateByPrefix(prefix) 11:  list ← ∅ 12:  while iter.HasNext() and |list| < maxResults do 13:    kv ← iter.Next() 14:    list.Append(ParseJSON(kv.value)) 15:  return list

Algorithm 9: ZKPAuthenticateAndIssueToken (Gateway/Verifier)

Input: ctx, meta, Y; from prover: P_ctx, t1, t2, s, n_v Output: AuthProofID, P_ctx) or ⊥ 1: h_ctx ← H_ctx(ctx) 2: c ← H_chal(g ∥ Y ∥ h_ctx ∥ P_ctx ∥ t1 ∥ t2 ∥ n_v ∥ meta) 3: if g^s ≠ t1 · Y^c or h_ctx^s ≠ t2 · P_ctx^c then 4:   return ⊥ 5: AuthProofID ← H_chal(“auth” ∥ P_ctx ∥ ctx ∥ n_v ∥ meta ∥ t_gateway) 6: return (AuthProofID, P_ctx)

The computational complexity of the proposed chaincode algorithms is as follows: state lookup operations are O(1) on average under key-value storage assumptions (e.g., Hyperledger Fabric state database implementations such as LevelDB/CouchDB), prefix-based queries may exhibit O(n) complexity in the worst case depending on dataset size due to range scanning over key-value stores, and access control evaluation is O(k), where k is the number of consent rules. These characteristics highlight the importance of indexing and efficient state management for scalability.

7. Security and Privacy Analysis

7.1. Privacy Preservation and Pseudonymity

The framework is designed so that donor identity and sensitive medical content are not exposed on the public ledger.

Pseudonymous identifiers: Donors are represented on-chain by donorRegID, which is not derived from real-world identity in a way that is verifiable by general participants. The mapping between real identity and donorRegID is held only by the Identity Authority (and optionally in Fabric private data collections restricted to a small set of organizations). Thus, observers who see only the ledger cannot resolve donorRegID to a real person without compromising the IA or a holder of the private collection.

Contextual pseudonyms in authentication: The ZKP protocol (Section 5) uses context-bound pseudonyms P_ctx. For different contexts (e.g., different hospitals or purposes), the donor derives different P_ctx values that are computationally unlinkable under the assumptions in Section 5.4. Access logs may record P_ctx and high-level metadata (e.g., dataType, purpose, requestorID) but do not record the donor’s long-term public key Y or the full ZKP transcript. Thus, authentication does not introduce a single long-term identifier that links all of a donor’s actions.

Off-chain storage of medical data: Medical records are stored in encrypted form in IPFS. The chaincode stores only content identifiers (CIDs) and metadata such as dataType and donorRegID. Possession of a CID does not reveal record content without the corresponding decryption keys, which are managed off-chain (e.g., by the gateway or donor-controlled devices). So the blockchain does not become a repository of plaintext health data.

Consent as metadata: Consent records indicate allowed data types, purposes, and requestor identifiers or roles, but do not contain PII. They support access control and audit without exposing who the donor is in the real world.

Donor privacy and pseudonymity are ensured through these mechanisms across identity, authentication, data storage, and consent.

7.2. Resistance to Replay, Man-in-the-Middle, and Ledger-Level Attacks

Replay of the ZKP transcript: The protocol binds the proof to a verifier-supplied nonce n_v. Reusing an old transcript (P_ctx, t1, t2, s) with a new n_v changes the challenge c, so the verification equations fail. Replay with the same n_v is prevented by the one-time use of n_v per session. Thus, an attacker cannot reuse a captured transcript to authenticate as the donor in a new session.

Replay of access transactions: The chaincode records each AuthProofID and rejects any transaction that reuses a previously used AuthProofID (Algorithm 3). So even if an attacker replays a valid gateway request (including a valid AuthProofID), the second submission is rejected and no new access is granted. This prevents a single authentication from authorizing multiple distinct access transactions.

Man-in-the-middle: We assume the gateway communicates with Fabric peers and IPFS over authenticated, encrypted channels (e.g., TLS). An attacker that only observes or modifies network traffic between the gateway and these services cannot forge valid Fabric transactions or alter IPFS content without breaking the channel security. The ZKP itself does not require a confidential channel for the proof (zero-knowledge holds), but the subsequent submission of AuthProofID and retrieval of CIDs should be over a secure channel so that tokens and CIDs are not stolen or altered in transit.

Ledger consistency: Fabric’s consensus and endorsement model ensures that once a transaction is committed, it is immutable and consistent across peers. An attacker cannot delete or alter past consent records, access logs, or data pointers without controlling a sufficient fraction of the ordering and endorsing organizations, which is outside the assumed threat model (Section 3.2).

7.3. Protection Against Identity Linkage and Traffic Analysis

Identity linkage: Cross-context linkage would require either (i) resolving donorRegID or P_ctx to the real identity, or (ii) linking different P_ctx values to the same donor. Moreover, it (i) requires compromise of the IA or a private data collection holder and (ii) is prevented by the unlinkability property of the ZKP (Section 5.4): under the DLP and random-oracle assumptions, different contexts yield pseudonyms that are indistinguishable from independent random group elements. So from the perspective of an observer that sees only public parameters and on-chain data, donors remain unlinkable across contexts.

Traffic analysis: The timing and volume of communication between the gateway, Hyperledger Fabric network, and IPFS nodes may be analyzed by an adversary to infer access patterns. While the current prototype does not explicitly implement traffic obfuscation mechanisms, the framework is designed to support such countermeasures at the deployment level.

To mitigate potential side-channel risks, techniques such as request batching, randomized transaction delays, and message padding can be incorporated to reduce traffic distinguishability. Secure communication protocols (e.g., TLS) and network-level protections (e.g., VPNs or private networks) further limit information leakage.

However, the framework does not fully mitigate risks posed by a strong global traffic analysis adversary.

Limited on-chain metadata: Access logs store donorRegID, requestorID, dataType, purpose, decision, AuthProofID, P_ctx, and timestamp. They do not store the decryption key, the full ZKP transcript, or the content of the accessed record. So even with access to the ledger, an attacker cannot recover medical content or the donor’s secret key from the log alone.

7.4. Insider and Collusion Attacks; Role of Private Data Collections and IA

Consent enforcement: Access is granted only if the donor’s current consent allows the requested access (requestorID, dataType, purpose). A malicious insider at a hospital cannot obtain access for a purpose or data type not permitted by consent. Consent is stored and enforced on-chain, so local policy overrides at a single organization do not bypass the donor’s preferences.

Audit trail: Every access attempt (allow and deny) is logged with the parameters above. Auditors and regulators can see who requested what, when it was requested, and whether the request was granted. This deters abuse and supports accountability. Immutability of the ledger prevents insiders from deleting or altering logs without consensus-level control.

Private data collections (PDCs): Donor PII and mappings (e.g., real identity to donorRegID, or donorRegID to Y) can be stored in Fabric PDCs so that only a subset of organizations (e.g., IA, primary blood bank) can read them. Peers that do not belong to the PDC’s distribution policy do not receive the private payload and cannot use it to de-pseudonymize donors. So the blast radius of a single compromised peer is limited.

Identity Authority: The IA is a single point of trust for the binding (RealID, donorRegID, Y). Compromise of the IA could allow bulk de-pseudonymization. The design therefore assumes the IA is protected (e.g., operationally and by access control) and does not collude with arbitrary parties. Optional replication of critical mappings in PDCs can reduce dependence on a single IA database.

Collusion: If several organizations collude and pool their views (e.g., multiple P_ctx values and request patterns), they might improve inference about donor identity. The protocol does not claim formal anonymity against such collusion; it reduces linkability from on-chain and protocol data and relies on governance and consent to limit which organizations can request access and for what purposes. The framework tolerates collusion among up to two organizations without compromising unlinkability under the defined threat model. However, large-scale collusion involving multiple organizations may increase the risk of inference attacks through correlation of access patterns.

7.5. Comparison with Existing Blockchain-Based Healthcare Systems

Table 2. Comparison with existing blockchain-based healthcare systems.

References	Application	Privacy Mechanism	Consent Model	Off-Chain Storage	Privacy Approach	ZKP Support	Blood Supply Focus	Blockchain Platform
[1]	Patient- centric healthcare data sharing	Encryption + hash verification	Patient consent via smart contracts	IPFS	Encrypted medical records stored off-chain with blockchain storing only hashes	No	No	Hyperledger Fabric
[2]	Healthcare access control system	Attribute-Based Access Control (ABAC)	Policy-based access control	Local hospital storage	Attribute-based authorization policies enforced through blockchain transactions	No	No	Hyperledger Fabric
[3]	EHR Sharing	(MA-ABE), Paillier Homomorphic Encryption	Organizational access policies	Distributed/cloud storage	Secure provenance tracking using cryptographic signatures and immutable ledger	No	No	Hyperledger Fabric
[8]	Blood donation and distribution tracking	Basic cryptographic authentication	Organizational permission model	Not clearly defined	Permissioned access with blockchain logging of blood unit transactions	No	Yes	Hyperledger Fabric
[12]	Medical supply monitoring with IoT sensors	Encryption + IoT device authentication	Organizational access policies	Cloud storage	Secure sensor data transmission with encrypted IoT data recorded on blockchain	No	Partial	Hyperledger Fabric
[21]	Secure healthcare data sharing	Encryption + hash verification	Smart contract-based access control	IPFS	Encrypted medical records stored in IPFS with blockchain maintaining secure references	No	No	Hyperledger Fabric/Ethereum
[22]	Electronic Health Record sharing	Public-key cryptography	Patient- controlled access permissions	External hospital databases	Access control through smart contracts and cryptographic key management	No	No	Ethereum
Proposed Framework	Privacy-preserving blood supply chain management	Contextual Zero-Knowledge Proof authentication + encryption	Fine-grained donor consent management	IPFS	ZKP-based authentication, encrypted off-chain storage, pseudonymous identifiers, and consent-controlled data access	Yes	Yes	Hyperledger Fabric

summarizes how the proposed framework compares with representative existing systems in terms of application domain, privacy mechanism, consent model, off-chain storage, support for zero-knowledge proofs, and focus on blood supply chain management. The comparison highlights key architectural and functional differences across systems, including the use of permissioned blockchain platforms, off-chain storage mechanisms, and advanced privacy-preserving techniques.

The comparison presented in Table 2 is based on architectural and functional characteristics. Due to the lack of standardized benchmarking datasets and reproducible implementations across existing healthcare blockchain systems, quantitative comparison is not feasible. Therefore, the analysis focuses on structural and design-level differences to provide a meaningful evaluation of the proposed framework.

8. Performance Evaluation Framework and Methodology

The proposed framework has been implemented as a functional prototype and evaluated under controlled experimental conditions. The evaluation focuses on key performance indicators, including transaction latency, throughput, and data retrieval efficiency. Performance measurements were collected under varying request loads and concurrency levels. The results provide indicative insights into system behavior and feasibility rather than definitive validation under large-scale deployment conditions.

8.1. Evaluation Metrics

8.1.1. Transaction Latency

Transaction latency in the proposed system consists of multiple stages, including client request submission, endorsement by peers, ordering, and ledger commit. Additional latency may be introduced by Zero-Knowledge Proof (ZKP) verification at the gateway.

For critical operations such as AuthorizeAndLogAccess, the end-to-end latency was estimated based on measured prototype observations as follows:

Total Latency ≈ ZKP Verification Time + Fabric Endorsement + Ordering + Commit + IPFS Retrieval

(1)

To quantify the impact of ZKP verification, latency measurements were obtained from a prototype deployment environment.

As shown in Figure 7, ZKP verification latency increases gradually with the number of authentication requests, ranging from approximately 8 ms to 15 ms. This indicates that the cryptographic overhead introduced by the authentication protocol remains within acceptable bounds for real-time healthcare applications under the evaluated conditions.

Fabric-related latency components (endorsement, ordering, and commit) are observed to increase under higher load conditions; however, the total observed transaction latency remained within sub-second bounds, indicating the feasibility of on-chain authorization and audit logging under the evaluated conditions.

To further illustrate the contribution of individual latency components, an approximate breakdown is provided below.

The values represent indicative proportions derived from observed overall system behavior and are provided to illustrate the relative contribution of each latency component rather than precise independent measurements.

8.1.2. Throughput

System throughput was measured as transactions per second (TPS) under different concurrency levels, including low-load, medium-load, and peak scenarios.

Throughput is influenced by:

• Number of concurrent clients (e.g., donors, hospitals);
• Complexity of chaincode logic;
• Endorsement policy configuration.

The separation of authentication (off-chain) and authorization (on-chain) reduces computational load on the blockchain network, which supports higher throughput compared with fully on-chain verification approaches.

Under prototype-based evaluation, throughput was measured under varying concurrency levels to assess system performance. The measurements were averaged over multiple experimental runs to ensure consistency.

As shown in Figure 8, throughput increases with the number of concurrent clients up to a moderate level, reaching a peak of approximately 120 TPS. Beyond this point, throughput declines due to increased network contention and transaction processing overhead. This behavior is consistent with the performance characteristics of permissioned blockchain systems.

Routine access operations exhibited stable throughput due to lightweight consent verification, while high-concurrency scenarios showed controlled degradation. Batching and parallel endorsement mechanisms were observed to mitigate performance drops under peak load conditions.

These results suggest that the proposed framework can support practical workload levels under controlled conditions.

8.1.3. Chaincode Execution Time

Chaincode execution time was used to measure the execution duration of smart contract logic during the endorsement phase. It depends on:

• Consent verification complexity;
• Access policy evaluation;
• Logging operations.

Since sensitive data is stored off-chain and only metadata is processed on-chain, chaincode execution remains lightweight. Observations from the prototype suggest that execution overhead is relatively low compared to network-related latency.

8.1.4. IPFS Retrieval Performance

The performance of the off-chain storage layer was evaluated by measuring retrieval time for encrypted medical records from IPFS under varying file sizes and caching conditions.

As shown in Figure 9, retrieval time increases with file size and is significantly lower under cache-hit conditions compared to cache-miss scenarios. These results support the use of IPFS as a scalable off-chain storage solution for medical data under the evaluated conditions.

8.2. Evaluation Methodology

The evaluation was conducted using a prototype-based setup designed to simulate realistic operational conditions.

8.2.1. Proposed Testbed Configuration

• A Hyperledger Fabric network with configurable organizations (2–10).
• Each organization hosts multiple peers and certificate authorities.
• An IPFS cluster for distributed storage of encrypted medical records.
• Off-chain ZKP gateway for authentication

8.2.2. Workload Scenarios

To reflect realistic blood supply chain operations, the following workloads were considered:

• W1: Donor Registration Burst—Large numbers of donors registering simultaneously, simulating mass blood donation campaigns.
• W2: Routine Access—Hospitals and laboratories accessing donor records and test results for scheduled transfusion procedures.
• W3: Emergency Mode—High-concurrency data access during mass-casualty or disaster situations where rapid authentication and data retrieval are required.

8.2.3. Measurements and Monitoring

Performance metrics were collected using controlled prototype-based experiments in a local test environment comprising a Hyperledger Fabric network, an IPFS node, and a simulated ZKP authentication module. Latency, throughput, and storage retrieval performance were measured under varying request loads and concurrency levels. Each experiment was executed multiple times, and the reported results represent averaged observations. The corresponding results are presented in

Table 3. ZKP Verification Latency Results.

Requests	Latency (ms)
10	8.4
50	10.2
100	12.0
200	14.5

,

Table 4. Estimated Transaction Latency Breakdown (Analytical Approximation).

Component	Approx Contribution
Endorsement	~40%
Ordering	~30%
Commit	~30%

,

Table 5. Throughput under varying concurrency levels.

Concurrent Clients	Throughput (TPS)
10	42
50	118
100	96
200	70

and

Table 6. IPFS Retrieval Performance.

File Size	Retrieval Time (ms)
1 MB	20
5 MB	45
10 MB	80
20 MB	140

and Figure 7, Figure 8 and Figure 9.

The blockchain performance metrics evaluated in the prototype-based experiments are:

• End-to-end latency: Time from the application API request to the final commit event on the ledger.

T_e2e = T_endorsement + T_ordering + T_commit

(2)

• Endorsement latency: Time required for peers to execute chaincode and generate endorsement responses.

T_endorsement = T_proposal + T_execution + T_response

(3)

• Ordering latency: Time taken by the ordering service to sequence transactions into blocks.

T_ordering = T_queue + T_block + T_consensus

(4)

• Commit latency: Time required for peers to validate and commit transactions to the ledger.

T_commit = T_validation + T_{ledger_write} + T_event

(5)

While the latency components (endorsement, ordering, and commit) are analytically defined to characterize transaction processing, the prototype-based evaluation focuses on overall transaction latency and ZKP verification overhead. The individual latency components were not measured independently but are represented to provide a conceptual decomposition of the total latency.

In addition to blockchain metrics, the performance of the off-chain storage layer was evaluated using IPFS-specific indicators:

• Content Identifier (CID) lookup time: Time required to locate and retrieve encrypted medical records using their content identifiers.
• Cache hit ratio: The proportion of retrieval requests served from local or nearby caches, which directly impacts data access latency.

All reported measurements are derived from controlled prototype-based experiments and represent averaged observations across multiple runs. The evaluated results, presented in Table 2, Table 3 and Table 4 and Figure 7, Figure 8 and Figure 9, collectively provide a comprehensive view of system performance by capturing both blockchain transaction processing behavior and off-chain data retrieval efficiency under representative workload conditions.

8.3. Observed Performance Trade-Offs

The integration of blockchain, IPFS, and zero-knowledge authentication introduces several performance trade-offs.

• Security vs. latency: ZKP verification introduces computational overhead but significantly enhances privacy and authentication security.
• Decentralization vs. throughput: Increasing the number of peers improves fault tolerance but may increase consensus latency.
• On-chain vs. off-chain storage: Storing only content identifiers on the blockchain reduces ledger size but introduces dependency on IPFS retrieval time.

8.4. Limitations and Potential Optimizations

8.4.1. Limitations

(i)

The presented evaluation is based on a prototype implementation conducted in a controlled environment. While the results provide indicative assessment of system feasibility and performance characteristics, large-scale deployment under production-grade infrastructure remains part of future work.

(ii)

ZKP verification cost depends on the chosen curve and implementation; a full comparison of curves and libraries is outside the current scope.

(iii)

IPFS performance is highly dependent on topology, replication, and caching; results will vary by environment

(iv)

The threat model does not comprehensively address real-time sensor–actuator control or denial-of-service resilience.

Formal scalability bounds (e.g., under Byzantine or rational behavior) are not derived; scalability is intended to be assessed empirically using the defined metrics.

8.4.2. Potential Optimizations

(i) Caching: The gateway can cache decrypted content or CIDs for recently accessed records (subject to consent and policy) to reduce IPFS load and latency.

(ii) Batching: Multiple Fabric transactions can be batched where the application allows (e.g., multiple data pointer registrations or blood-unit updates) to improve throughput.

(iii) Indexing and pruning: Chaincode state can be indexed or partitioned by donorRegID, time, or unit status to keep query and execution time stable as data grows; old access logs or temperature readings can be pruned or archived.

(iv) ZKP implementation: Efficient cryptographic curves and optimized libraries can reduce ZKP verification time.

(v) Private Data Optimization: Endorsement and dissemination policies can be tuned to limit private data sharing only to required peers, reducing bandwidth and storage overhead.

These results suggest that the proposed framework can achieve practical performance under controlled conditions.

9. Conclusions and Future Work

This study addressed the critical challenge of enabling secure, privacy-preserving, and consent-aware data sharing in blood supply chain systems. A novel framework was proposed that integrates Hyperledger Fabric, IPFS, and a Zero-Knowledge Proof (ZKP)-based authentication mechanism to support decentralized and privacy-preserving management of donor data and blood unit traceability.

The proposed Pseudonymous Role-Bound Zero-Knowledge Authentication (PRZKA) protocol enables donors to authenticate and authorize access using pseudonyms, ensuring unlinkability across different contexts while resisting replay attacks through Schnorr-style proofs. In addition, the hybrid blockchain architecture combines off-chain ZKP verification with on-chain authorization, reducing blockchain overhead while maintaining strong security guarantees. The use of private data collections and encrypted off-chain storage ensures confidentiality of sensitive medical data, while smart contracts enforce fine-grained, consent-aware access control and maintain immutable audit trails.

The findings of this study have important implications for multi-stakeholder healthcare systems. The framework enhances protection of donor identities and sensitive medical data, aligning with regulatory requirements such as GDPR and HIPAA, and preventing identity linkage across different operational contexts. Furthermore, the integration of blockchain and off-chain components improves scalability and system performance under realistic workloads, while ensuring transparency, accountability, and stakeholder confidence through auditable and consent-driven data sharing mechanisms.

A prototype-based performance evaluation was conducted under controlled experimental conditions to assess the feasibility of the proposed system. The results indicate that ZKP verification latency remains within acceptable bounds, demonstrating the practicality of combining blockchain, off-chain storage, and ZKP-based authentication for secure and auditable healthcare data sharing.

Future work will focus on extending the prototype to large-scale deployments, optimizing ZKP protocols for improved computational efficiency, and integrating IoT-based sensing devices for real-time monitoring of blood storage and logistics conditions.