Zero-Trust Medical Image Sharing: A Secure and Decentralized Approach Using Blockchain and the IPFS

Abstract

The secure and efficient storage and sharing of medical images have become increasingly important due to rising security threats and performance limitations in existing healthcare systems. Centralized systems struggle to provide adequate privacy, rapid access, and reliable storage for sensitive medical images. This paper proposes a decentralized medical image-sharing framework to address these issues by integrating blockchain technology, the InterPlanetary File System (IPFS), and edge computing. Blockchain technology enforces secure patient-centric access control through smart contracts that enable patients to directly manage their data-sharing permissions. The IPFS provides decentralized and scalable storage for medical images and effectively resolves the storage limitations associated with blockchain. Edge computing enhances system responsiveness by significantly reducing latency through local data processing to ensure timely medical image access. Robust security is ensured by using elliptic curve cryptography (ECC) for secure key management and the Advanced Encryption Standard (AES) for encrypting medical images to protect against unauthorized access and data breaches. Additionally, the system includes real-time monitoring to promptly detect and respond to unauthorized access attempts to ensure continuous protection against potential security threats. System results demonstrate that the proposed framework achieves lower latency, higher throughput, and improved security compared to traditional centralized storage solutions, which makes our system suitable for practical deployment in modern healthcare settings.

1. Introduction

Digital healthcare and the use of the Internet of Medical Things (IoMT) are revolutionizing healthcare services by improving both efficiency and accessibility [1,2]. The most important development is the use of Electronic Medical Records (EMRs) in healthcare, which store a patient’s important data, including medical history; treatment plan; and diagnostic images, such as X-rays, MRIs, CT scans, and other DICOM [3]. Recent research reports show that medical images now account for almost 80% of the data produced in EMR systems, posing significant problems for data storage, security, and sharing [4]. The healthcare sector has become highly vulnerable to data breaches, with financial losses up to USD 15 million [5]. In fact, data breaches in healthcare have increased by 19% more compared to in other sectors [6]. Notable incidents such as the WannaCry ransomware attack in 2017, which globally disrupted healthcare institutions, including the UK’s National Health Service (NHS), and the Anthem data breach in 2015, which exposed the sensitive information of millions of patients, highlight the weaknesses of current centralized systems [7,8]. Similarly, a 2020 ransomware attack on U.S. healthcare institutions significantly interrupted healthcare services by delaying medical procedures and negatively impacting patient care nationwide [9]. These cases show that there is an urgent need for secure, reliable, and decentralized alternatives to existing centralized healthcare data management systems.

1.1. Problem Statement

In emergencies, quick decision making is essential, and the need for secure, real-time, and low-latency access to medical images is becoming increasingly necessary. However, conventional storage approaches that mainly rely on centralized private cloud platforms or third-party services like AWS and Google Cloud have major vulnerabilities. These include risks of system failures, unauthorized access, data breaches, and limited support for secure identity management. While encryption and access control frameworks enhance security, they still depend on a centralized system. Moreover, these solutions often lack transparent auditing mechanisms, face scalability challenges with large medical imaging datasets, and fail to ensure the low-latency performance required for emergencies [10,11,12].

To address identity and access management concerns, Distributed Identity (DID) solutions have recently emerged, allowing patients to manage their identity information without depending on centralized entities. DID enhances privacy and identity protection by decentralizing identity verification, thus reducing reliance on third-party authentication providers [13,14]. However, DID alone does not resolve the critical challenges related to the secure, scalable storage and retrieval of large medical images. It does not protect against data tampering or unauthorized modifications nor does it address the massive storage and real-time access issues associated with high-volume medical imaging data.

Conversely, blockchain technology offers a promising solution to these challenges by providing a reliable, decentralized, and secure data handling framework [15,16]. However, it is not practically feasible to store large medical images directly on the blockchain due to the high costs associated with transaction fees. Therefore, there is a need for a solution that can efficiently and securely manage medical images at a large scale while providing easy access to medical images for authorized healthcare providers.

This research aims to address these challenges by developing a secure, scalable, and patient-centric system for storing and sharing medical images. Current systems fall short in terms of both privacy protection and the responsiveness required for real-time medical decisions. A decentralized approach is essential to enhance data security while empowering patients with control over their information. Therefore, we came up with the following research questions:

RQ1:

What would be a suitable framework for a decentralized and patient-centric medical image storage and sharing system that provides security, scalability, and data integrity?

RQ2:

What security mechanisms can safeguard medical image access from unauthorized access? How can real-time responsiveness and low latency be achieved in the storage and retrieval of medical images?

1.2. Research Hypotheses

The following hypotheses were formulated to guide the evaluation and validation of the proposed framework:

Hypothesis 1.

A decentralized framework integrating blockchain, IPFS storage, and edge computing enhances the security, scalability, and integrity of medical image management compared to conventional centralized systems.

Hypothesis 2.

Utilizing advanced cryptographic methods (ECC and the AES) significantly improves protection against unauthorized access to medical images.

Hypothesis 3.

Deploying edge computing for the local processing of medical image data substantially reduces latency and increases responsiveness, enabling effective real-time image retrieval compared to traditional cloud-based approaches.

1.3. Contributions

In response to the research questions, we propose a framework that combines blockchain with the InterPlanetary File System (IPFS) and edge computing to provide decentralized and secure storage with fine-grained access control. The main contributions of this paper are summarized as follows:

• We present a patient-centric access control system that uses blockchain and smart contracts, allowing patients to manage permissions for their medical images.
• Our framework leverages edge computing to enhance system responsiveness and reduce latency, particularly in time-sensitive scenarios.
• The IPFS is utilized for the decentralized storage of encrypted medical images, efficiently solving scalability issues and ensuring data redundancy.
• The system employs multi-layered security, including elliptic curve cryptography (ECC) for key generation and the Advanced Encryption Standard (AES) for encrypting images, ensuring the protection of medical images during storage and transmission.

1.4. Organization

The rest of this article is structured as follows: Section 2 presents the work related to our study. Section 3 explains the key concepts and technologies used. Section 4 describes the system architecture and system flow. Section 5 covers the proposed framework. Section 6 outlines the system security proofs, and, in Section 7, we discuss our system simulation. Section 9 discusses our work’s comparison, and Section 11 discusses the conclusion of the article.

2. Related Work

Recent developments in decentralized healthcare systems have incorporated blockchain, the IPFS, and edge computing to address fundamental challenges related to security, scalability, and latency. This section reviews recent studies, highlighting their relevance to our proposed framework.

2.1. Blockchain Technology in Healthcare Data Management

Blockchain’s immutability and transparency have been widely leveraged for secure healthcare data management. Anwar et al. proposed AnonChain, a secure file-sharing system that uses blockchain combined with the IPFS. This approach enhances data security, allowing for user anonymity while ensuring data integrity through encryption and hashing techniques. However, this system may struggle with scalability issues, especially when storing large medical images directly on the blockchain due to the high transaction costs [17]. Similarly, MacBee and Wilcox introduced a blockchain-based system specifically for medical imaging data management. Their work integrates blockchain with existing medical imaging workflows to improve traceability, integrity, and secure sharing among healthcare providers. While this approach directly addresses medical imaging use cases, it does not sufficiently resolve scalability challenges when handling large-scale, high-resolution medical image datasets [18].

Jabarulla and Lee’s blockchain-based, patient-centric image management system also uses the IPFS to decentralize access control for medical images. By leveraging Ethereum and smart contracts, the system allows patients to manage permissions effectively. Despite its privacy advantages, their framework faces challenges in terms of latency and the need for more efficient data retrieval mechanisms [16]. However, He et al. proposed a blockchain-based method for secure data offloading in healthcare using mobile edge computing. They utilized deep reinforcement learning to optimize resources and minimize offloading costs. While their approach addresses cost and resource challenges, it overlooks the issue of integrating blockchain and edge computing seamlessly for efficient real-time medical image access [19]. Furthermore, their system may not handle large-scale data efficiently when medical images grow in size.

Finally, Nguyen et al. introduced Federated Healthcare, which uses blockchain and edge computing for decentralized EMR sharing. While the system successfully integrates the IPFS and smart contracts to ensure secure and efficient data sharing among hospitals, the overall performance may degrade when handling high-frequency real-time data access, especially under heavy-load conditions [20].

2.2. Decentralized and Scalable Storage via IPFS

To address blockchain’s storage limitations, the IPFS has emerged as a decentralized alternative for scalable medical image management. For instance, Li et al. explored the IPFS for the low-cost, reliable storage of IoT data, including medical images. They combined blockchain with the IPFS to ensure data integrity and reduce storage costs. However, the IPFS-based solution may not provide the level of access speed required for critical real-time medical applications [21]. Similarly, Qiuyu and Zhao proposed a distributed storage system for encrypted speech data using blockchain and the IPFS. Their method leverages the IPFS’s decentralized storage and blockchain’s immutability to ensure the secure management of sensitive data. While this approach demonstrates the versatility of the IPFS for healthcare-adjacent use cases (e.g., speech data), it does not address the unique challenges of medical image formats, such as large file sizes and metadata complexity [22].

Peng Kang’s approach to private file storage and sharing with the IPFS is another example of utilizing decentralized storage for healthcare data. By combining blockchain’s immutability with the IPFS’s decentralized storage, Kang’s system ensures privacy and reliability. However, like other IPFS-based solutions, its scalability and performance could become limiting factors as the number of stored medical images increases significantly [23]. Furthermore, N. Sangeeta also used the IPFS and blockchain to manage data in vehicular networks, showing how this can enhance decentralized data retrieval. While this system improves data security and retrieval efficiency, it does not address the potential delays in retrieving large images or real-time access challenges [24].

Finally, Ben Letaifa, Rachedi, and Makina proposed a system that integrates the IPFS, blockchain, and edge computing for eHealth. While it ensures real-time data processing and confidentiality, their solution faces challenges in scaling up for large healthcare datasets. The IPFS’s performance may degrade as the system scales, impacting its ability to handle time-sensitive medical data efficiently [25].

2.3. Edge Computing for Real-Time Data Processing

Edge computing helps address the latency challenges inherent in centralized healthcare systems. Gao et al. explored a fine-grained searchable encryption system for EHRs, combining blockchain and edge computing to enhance data privacy and integrity. Their system reduces the computational burden on users and ensures secure access to medical images. However, this system still faces the challenge of effectively managing high throughput in real-time scenarios, particularly when large datasets are involved [26]. Similarly, Dongjun Na et al. proposed a federated blockchain architecture to minimize latency and improve reliability for IoT DApp services. By using IoT devices as blockchain nodes, their system optimizes upload and download times for decentralized applications. While this approach addresses latency challenges in IoT environments, its applicability to medical image sharing requires further validation, particularly in scenarios demanding ultra-low latency for urgent healthcare workflows [27].

Mahadev and Patil designed a blockchain-based framework for secure data sharing in edge computing, leveraging fog nodes to enhance privacy and reduce computational overhead. Their work demonstrates efficient decentralized management of sensitive data, but its adaptation to healthcare systems would require addressing regulatory compliance and interoperability with existing medical devices [28]. Expanding on medical imaging, Liu et al. developed a secure medical image transmission and storage system that uses blockchain and the IPFS for off-chain storage. Edge computing is incorporated to enhance real-time access and reduce latency. Although the system shows promise in localizing data access, it may not scale well in a network with multiple hospitals requiring simultaneous access to large volumes of medical images [29].

Bingcheng and He proposed a blockchain-based secure video-sharing system for vehicular edge computing, emphasizing decentralized access control via smart contracts. While they focused on real-time data sharing, the system’s design for vehicular networks may not fully account for the stringent privacy requirements of healthcare data [30]. Similarly, Gao’s collaborative edge computing framework aims to improve resource sharing and efficiency in decentralized systems. While it enhances trust and reduces latency by bringing computation closer to the users, it still needs to be optimized for high-demand scenarios such as real-time medical image sharing between hospitals [31].

2.4. Cryptographic Security Mechanisms

Cryptographic techniques are crucial in ensuring the confidentiality and integrity of medical images. Wenying and Jian proposed a blockchain-based medical image-sharing framework that integrates QR codes for data integrity and security. While their solution is effective in protecting image data, it may face difficulties in scalability when dealing with larger datasets or more complex medical imaging systems [32]. Similarly, Muhammad and Migliorini suggested a secure approach for storing and retrieving data in a decentralized manner using blockchain and the IPFS. Their system leverages cryptographic mechanisms, including the AES, to protect data during storage and transmission. However, their approach still faces challenges in efficiently managing data retrieval times, especially when dealing with large medical images [33].

Finally, Li et al. proposed a similar system using blockchain and the IPFS for the secure, reliable storage of IoT data. They employed the AES and RSA encryption to enhance security. While their encryption methods are robust, their solution does not adequately address the scalability challenges when scaling up to handle high volumes of medical image data [21].

2.5. Patient-Centric Access Control

Patient-centric access control is a key aspect of maintaining privacy and trust in healthcare data management. Jabarulla and Lee’s system allows patients to manage permissions for their medical images through smart contracts on a blockchain. Although this approach ensures privacy, it may suffer from performance issues as the number of patients and healthcare providers grows, impacting real-time access to medical images [16]. Muhammad and Migliorini’s framework also offers patient-controlled access to medical data using blockchain and the IPFS. Their system enables patients to manage access permissions, ensuring data confidentiality. However, the system may face challenges in ensuring real-time access during emergencies, especially in high-demand healthcare environments [33].

Similarly, Nguyen et al.’s Federated Healthcare system uses blockchain and smart contracts to enable the decentralized sharing of medical records. Although their system allows patients to control access to their EMRs, it may struggle with scaling to handle a large number of healthcare providers and patients, especially in large hospital networks [20].

2.6. Literature Gaps

Each of these studies provides valuable insights into the developing field of blockchain technology in healthcare data management, highlighting both its potential and the challenges that need to be addressed. However, despite these significant contributions, several key limitations and gaps remain, as explained below:

• Current solutions struggle with storing large medical images on the blockchain due to size and cost issues.
• Traditional systems rely on centralized authorities for data access, creating vulnerabilities.
• Existing systems have delays that hinder real-time medical applications.

Our research presents a robust, decentralized framework that not only guarantees the security and privacy of sensitive medical images but also solves the problems of scalability, cost, and real-time access.

3. Preliminaries

This section provides an overview of the concepts and technologies used in our research, which are essential to understand the security model and the proof of our proposed scheme.

Blockchain: Blockchain is a distributed ledger technology that is used to store information in blocks, and these blocks are linked together using cryptographic hashes. This ensures data integrity, as any change made to any block will change its hash and break the entire chain. Blockchain does not have a central point of control, which makes it more secure and resistant to attacks [34]. Our system uses blockchain to store and verify access logs to ensure that only authorized parties can access sensitive data.

Smart Contracts: Smart contracts are self-executed contracts that contain the terms of the agreement in the form of code. They are deployed on the blockchain, and they automatically execute the terms of the contract when certain conditions are met. Smart contracts eliminate the need for intermediaries, reduce transaction costs, and enhance security by ensuring that contract execution is transparent and tamper-proof [35]. In our framework, smart contracts are used to manage access control, allowing patients to set rules on who can access their medical images.

Cryptographic Techniques: Elliptic curve cryptography is a form of public key cryptography, which is performed on the algebraic structure of elliptic curves over finite fields. Compared to other conventional cryptographic methods such as RSA, ECC provides the same security with smaller key sizes; therefore, it is suitable and efficient for use in environments with limited computational resources [36]. We use ECC in our system to generate keys for our system members.

In addition, our framework also uses the Advanced Encryption Standard (AES) to encrypt medical images. When images are uploaded, the edge node encrypts them using the AES to make sure that they are securely encrypted before they are stored in the InterPlanetary File System (IPFS).

InterPlanetary File System (IPFS): The IPFS is a peer-to-peer distributed file system that connects all computing devices to the same file system. Unlike traditional centralized storage systems that store all data in one place, the IPFS stores files on multiple nodes in a decentralized manner. Each file is identified by a unique cryptographic hash, which ensures data integrity and allows for efficient retrieval. The IPFS enhances data redundancy and accessibility and reduces the data loss risk [37]. In our framework, we use the IPFS to store encrypted medical images as a scalable and secure way of handling large images.

Edge Computing: Edge computing is a distributed computing model that processes data near the sources where they are generated instead of depending on a central data processing server. This technology reduces delays and saves network bandwidth while providing faster results, making it suitable for applications that need real-time data handling [38]. In our system, edge nodes are placed close to hospitals and patients to perform local data processing, encryption, and decryption. This process makes our framework responsive and efficient, particularly for time-sensitive medical applications, such as emergency care and remote diagnostics.

Notation and Symbols: In this section, we define the notation and symbols used throughout the paper, as shown in

Table 1. Notation and symbols.

Symbol	Description
E	An elliptic curve defined over a finite field $F_p$, where p is a large prime.
G	A base point on the elliptic curve E with a large order n.
$SK$	A private key in elliptic curve cryptography, chosen as an integer from the set $\{1,2,\dots ,n-1\}$.
$PK$	A public key in elliptic curve cryptography, calculated as $PK=SK\times G$.
$ESK\left(F\right)$	The encryption of a image F using a symmetric key $SK$.
$HIPFS$	A unique cryptographic hash assigned to an image stored on the InterPlanetary File System (IPFS).
T	A timestamp representing the time of a particular event or transaction.
R	A record containing metadata about an image, including $HIPFS$, patient ID, Hospital ID, and a timestamp.
S	A digital signature from an edge node computed as $S={\mathrm{Sign}}_{SKedge}\left(R\right)$.
$PID$	Patient ID.
$HID$	Hospital ID.
$EPK\left(\mathrm{Data}\right)$	Encryption function using a public key $PK$.
$Transaction$	An encrypted transaction.
$Decryp{t}_{SK}\left(ESK\left(F\right)\right)$	The decryption of an encrypted image $ESK\left(F\right)$ using the symmetric key $SK$.

.

4. System Overview

In this section, we discuss the overall system architecture and the flow of data within the system. This includes how various components interact to ensure secure and efficient medical image sharing, from data encryption to access management via smart contracts and edge nodes.

4.1. System Architecture

Our system architecture introduces a secure and privacy-focused image exchange framework, as shown in Figure 1. Patients are the core of our system. They have full authority over their medical data, allowing them to grant or revoke access at any time, ensuring their privacy and control over image sharing. This patient-centric model emphasizes ownership and the security of sensitive medical images. The hospitals and laboratories in our system serve as the main points of data entry, securely uploading important medical images for diagnosis and treatment. The edge nodes enhance the system’s efficiency by bringing computational power closer to hospitals and patients, thus minimizing the latency and enhancing responsiveness, especially in emergencies. These nodes handle patient registration and initial data encryption before storage to improve security. Our system stores medical images on the IPFS for decentralized storage, providing easy accessibility and preventing data redundancy and data loss. Blockchain technology is an immutable ledger. In our system, it records transactional history, cryptographic hashes of medical images, and identifiers. This ensures data integrity, transparency, and trust, with an auditable trail of all activities related to medical image sharing in the system. Smart contracts manage access control according to patient-defined rules, allowing only authorized individuals to view and retrieve the data. This automation strengthens security and reduces the risk of human error. Medical professionals and researchers can request access to medical images for diagnosis, treatment, or research in our framework, but access is only granted to those who have the permission of the patient.

4.2. System Data Flow

The following are the steps of the proposed framework’s data flow.

4.2.1. Patient Registration at Hospital

The patient registration process begins when a patient visits a hospital. First, the edge node generates a unique cryptographic key pair for the patient and caretaker, and then it encrypts the patient data with their public key and stores it on the blockchain, as shown in Figure 2.

4.2.2. Medical Image Storage Process

• Medical images are collected by the hospitals in our system during diagnostic procedures such as X-rays, MRIs, CT scans, and other DICOM. The images are then transferred to the edge nodes, which encrypt and securely store them.
• The medical images are encrypted at the edge nodes using the Advanced Encryption Standard (AES). In this way, the images are protected and can be accessed only by authorized users who have the correct decryption keys.
• After the images are encrypted, the edge node uploads them to the InterPlanetary File System (IPFS). Each encrypted image is given a unique cryptographic hash by the IPFS so that it can be stored and retrieved in a decentralized manner.
• Once the cryptographic hash data are returned from the IPFS, the edge node joins the hash, along with the associated metadata.
• The edge node sends the combined data consisting of the IPFS hash, metadata, and patient privacy policy as a transaction to the blockchain. This transaction is stored immutably on the blockchain, which ensures that access and storage conditions are recorded transparently, as illustrated in Figure 3.

4.2.3. Medical Image Access Process

• When a medical professional or researcher requests access to a patient’s medical images, they submit their request to the edge node. This request includes their professional ID and the patient’s public key ID. The edge node then notifies the patient via their device to review and approve or deny the access request, as shown in Figure 4.
• If the patient approves the request through their device, the edge node forwards the request to the blockchain. The smart contract checks the request against the patient’s privacy policy to ensure compliance. If valid, the smart contract grants permission for access.
• After the edge node receives the data from the blockchain, it retrieves the medical image from the IPFS by giving the cryptographic hash of the image to the IPFS. The edge node then decrypts the image using the appropriate decryption key.
• Once decrypted, the edge node re-encrypts the image using the requesting professional’s public key. This ensures that only the authorized professional can decrypt and access the image. Then, the encrypted image is sent to the medical professional or researcher.
• Throughout the process, the edge node monitors all activities for signs of unauthorized access or suspicious behavior. If any unauthorized access is detected, the edge node revokes access immediately and uploads a log of the event to the blockchain, ensuring a transparent and immutable audit trail.

The system’s decentralized architecture eliminates the need for a central storage repository. This reduces the risk of data breaches and ensures that patients retain full control over their medical data, with access limited strictly to authorized users based on smart contract rules. In addition, our framework addresses concurrency challenges through decentralized coordination. The blockchain consensus protocol secures transaction integrity during simultaneous read-and-write operations by maintaining a unified ledger across nodes. The IPFS distributes large medical images over a peer-to-peer network, enabling parallel retrieval and avoiding centralized bottlenecks. Meanwhile, edge nodes balance workloads with adaptive algorithms, efficiently managing requests, even during peak demand periods. The integration of blockchain, the IPFS, and edge computing ensures low-latency, secure access to medical images under high concurrency while preserving patient control and scalability. This framework is particularly suitable for medical scenarios that require immediate and secure medical image access, including emergency treatments, remote diagnostics, and urgent inter-hospital image transfers.

5. Proposed Framework

This section explains the key generation for patients and their devices using elliptic curve cryptography (ECC) at edge nodes. The following are the registration steps.

5.1. Patient Registration at Hospital

In our framework, patient registration at the hospital ensures the secure handling of patient information. For registration, patients provide their personal details to the edge node. Additionally, patients can preregister trusted caretakers, such as family members, legal guardians, or authorized representatives. Both patients and caretakers undergo key generation using elliptic curve cryptography (ECC). The edge node produces unique cryptographic key pairs for each patient and caretaker, enabling secure, authenticated interactions and immediate caretaker authorization in emergencies. The key generation process is explicitly detailed in the following steps:

• The elliptic curve E is defined over a finite field ${\mathbb{F}}_p$, where p is a large prime number. A base point G on the curve with a large order n is selected.
• Private keys for patient $SK$ and caretaker $S{K}_{\mathrm{caretaker}}$ are randomly selected from the range $\{1,2,\dots ,n-1\}$.
• Public keys for patient $PK$ and caretaker $P{K}_{\mathrm{caretaker}}$ are derived from the private keys using the base point G on the elliptic curve:

  $$PK=SK\times G$$

  (1)

  $$P{K}_{\mathrm{caretaker}}=S{K}_{\mathrm{caretaker}}\times G$$

  (2)
• Once the key pair is generated, the personal information of the patient is encrypted using their public key $PK$ to ensure confidentiality and that only the patient who possess the corresponding private key can decrypt the data (SK). This prevents tampering, as any alteration invalidates the signature. The encrypted data $D_{enc}$ are produced as follows:

  $$D_{enc}=E_{PK}\left(Data\right)$$

  (3)

  where E is the encryption function, and $Data$ represents the patient’s personal details.
• Then, the record is generated for storage on the blockchain, containing the necessary details:

  $$Record=\{D_{enc},PK,P{K}_{\mathrm{caretaker}},T,\mathrm{Hospital}\mathrm{ID}\}$$

  (4)

  where T is the timestamp, and $\mathrm{Hospital}\mathrm{ID}$ is the identifier of the hospital.
• The record is signed using the private key of the edge node to ensure the authenticity and integrity of the record $S{K}_{\mathrm{edge}}$. The signed transaction $T_{enc}$ is expressed as

  $$T_{enc}=E_{S{K}_{\mathrm{edge}}}\left(Record\right)$$

  (5)
• The signed transaction is then sent to the blockchain for immutable storage.

5.2. Device Registration Process for Patients

The device registration process ensures secure communication and authentication between the patient’s device and the hospital’s network using elliptic curve cryptography (ECC). The steps for patient and caretaker device registration are as follows:

• Patients and caretakers provide their public keys and device information to the edge node. The edge node generates unique cryptographic key pairs for secure device communication using ECC for each participant (the patient and caretaker). The public keys of the devices $P{K}_{devices}$ are computed explicitly as follows:

  $$P{K}_d=S{K}_d\times G$$

  (6)

  $$P{K}_{dct}=S{K}_{dct}\times G$$

  (7)

  where $S{K}_d$ and $S{K}_{dct}$ are the private keys of the devices. The device private keys follow the same ECC principles as the patient keys, as explained in Section 5.1.
• Once the key pairs are generated, the edge node links the devices to the patient through the patient’s primary key, $P_{ID}$, and it creates a record that is stored on the blockchain. This record includes the device’s public key $P{K}_d$, the primary key of the patient, the caretaker’s public key $P{K}_{\mathrm{caretaker}}$ and device public key $P{K}_{dct}$, a timestamp, and the Hospital ID.

  $$Recor{d}_{device}=\{P{K}_d,P_{PK},P{K}_{dct},P{K}_{\mathrm{caretaker}},T,\mathrm{Hospital}\mathrm{ID}\}$$

  (8)
• The edge node uses its private key $S{K}_{\mathrm{edge}}$ to sign records to ensure both integrity and authenticity, and the record is then sent to the blockchain for immutable storage, as shown in Figure 5.

  $$T_{enc}=E_{S{K}_{\mathrm{edge}}}\left(Recor{d}_{device}\right)$$

  (9)

  where $T_{enc}$ is the signed transaction.

To further increase security, the device has to perform mutual authentication with the edge node using its ECC key before it is completely registered. This step guarantees that only legitimate devices remain linked with the patient. Patients and caretakers store all their private keys locally on their devices in trusted key storage (e.g., iOS Secure Enclave or Android KeyStore). This ensures that the key is never stored in plaintext and cannot be accessed by unauthorized apps. Access to these keys typically requires local authentication such as a fingerprint, face recognition, or a passcode, which prevents misuse.

The system keeps on tracking the registered devices for any suspicious activity. In the case of any anomaly, the device may blocked from the system, and the event is saved on the blockchain.

5.3. Image Upload to the System

This section explains the procedure for hospitals or laboratories to upload images to the system, as shown in Algorithm 1. This process uses edge nodes and the IPFS to store images securely and the blockchain to manage access control.

First, the hospital or laboratory sends a request to the edge node to upload an image of a patient. Then, the edge node generates a symmetric key $SK$ using the AES to encrypt the image. Here, the AES is chosen for symmetric encryption due to its efficiency in encrypting large files and resistance to known cryptographic attacks. Let F be the image to be uploaded. The image F is encrypted using the symmetric key.

$$E_{SK}\left(F\right)={\mathrm{Encrypt}}_{SK}\left(F\right)$$

(10)

The encrypted image $E_{SK}\left(F\right)$ is then uploaded to the IPFS. The IPFS returns a unique cryptographic hash $H_{IPFS}$ for the uploaded image. The system then combines the IPFS hash $H_{IPFS}$ with the patient ID $P_{ID}$, hospital or laboratory ID $H_{ID}$, and a timestamp T to create a record R containing these details:

$$R=\{H_{IPFS},P_{ID},H_{ID},T\}$$

(11)

The edge node signs the record R using its private key $S{K}_{edge}$ to ensure integrity and authenticity. The signature S is computed as

$$S={\mathrm{Sign}}_{S{K}_{edge}}\left(R\right)$$

(12)

Once the edge node has signed the metadata, the system creates a blockchain transaction containing S:

$$\mathrm{Transaction}=\left\{S\right\}$$

(13)

This transaction is then sent to the blockchain for validation and storage, and a copy of it is also stored on the off-chain blockchain for the quick retrieval of data next time.

Algorithm 1 Image Uploading Algorithm

Require:  Image F, Patient ID $P_{ID}$, Hospital ID $H_{ID}$, Timestamp T Ensure:  Transaction stored on the blockchain   1: Step 1: Request Submission   2: Hospital/Laboratory sends image F and patient ID $P_{ID}$ to edge node   3: Step 2: Image Encryption   4: $SK\leftarrow \mathrm{GenerateSymmetricKey}\left(\right)$   5: $E_{SK}\left(F\right)\leftarrow {\mathrm{Encrypt}}_{SK}\left(F\right)$   6: Step 3: Upload to IPFS   7: $H_{IPFS}\leftarrow \mathrm{IPFS}\left(E_{SK}\left(F\right)\right)$   8: Step 4: Metadata Creation   9: $T\leftarrow \mathrm{GetCurrentTimestamp}\left(\right)$ 10: $R\leftarrow \{H_{IPFS},P_{ID},H_{ID},T\}$ 11: Step 5: Digital Signature 12: $S{K}_{edge}\leftarrow \mathrm{GetEdgeNodePrivateKey}\left(\right)$ 13: $S\leftarrow {\mathrm{Sign}}_{S{K}_{edge}}\left(R\right)$ 14: Step 6: Blockchain Transaction 15: Transaction $\leftarrow \left\{S\right\}$ 16: Send Transaction to Blockchain 17: Step 7: Blockchain Storage 18: Blockchain Network verifies and stores the transaction

5.4. Image Access Procedure

This section describes the procedure for doctors, pharmaceuticals, and researchers to access medical images. The process ensures secure and controlled access through edge nodes, smart contracts, and the blockchain.

Case 1: Intra-Hospital Medical Image Access

When a patient and medical professional, pharmaceutical, or researcher are in the same hospital and they want to access the medical images, the procedure is as shown in Algorithm 2. To access a patient’s data, they submit a request, which includes the professional’s identifier ($\mathrm{Requester}\mathrm{ID}$), the hospital identifier $\mathrm{Hospital}\mathrm{ID}$, and the patient’s identifier PID. The request is represented as

$$\mathrm{Request}=\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},T\}$$

(14)

where T is the timestamp.

The edge node notifies the patient of the request and awaits their permission. The patient reviews the request and either approves or denies it via their device. If the patient approves, the request is forwarded for further processing:

$$\mathrm{Notification}=\mathrm{SendNotification}(\mathrm{PID},\mathrm{Request})$$

(15)

To ensure timely and efficient medical image access, especially in critical healthcare scenarios, our framework specifies a maximum waiting duration ($T_{wait}$) for patient authorization:

$$T_{wait}\le 100\mathrm{s}$$

(16)

If the patient does not respond within this interval, the system automatically triggers an emergency override mechanism to contact the caretaker. If the caretaker also does not give a response, this transaction will end.

If the patient’s device verifies the request and approves it, the transaction is signed:

$$\mathrm{Signature}={\mathrm{Sign}}_{S{K}_{patient}}\left(\mathrm{Request}\right)$$

(17)

where $S{K}_{patient}$ is the patient’s private key. The patient’s digital signature on the access request ensures explicit consent. This prevents unauthorized access, as the blockchain verifies the signature against the patient’s public key.

The smart contract on the blockchain checks the access request against the patient’s predefined privacy policy, ensuring that the request complies with the patient’s consent:

$$\mathrm{Policy}=\mathrm{CheckPolicy}(\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID})$$

(18)

If the policy allows, the smart contract grants access.

The edge node searches for the patient’s data on the blockchain using the patient ID (PID) and retrieves the IPFS hash $H_{\mathrm{IPFS}}$ and other relevant metadata. The edge node first checks whether the requested data are available in the local off-chain blockchain. If the data are available, it retrieves them directly from the local blockchain for a quicker response:

$$H_{\mathrm{IPFS}}=\mathrm{RetrieveFromBlockchain}\left(\mathrm{PID}\right)$$

(19)

Using the IPFS hash $H_{\mathrm{IPFS}}$, the edge node fetches the encrypted image $E_{SK}\left(F\right)$ from the InterPlanetary File System (IPFS):

$$E_{SK}\left(F\right)=\mathrm{IPFSRequest}\left(H_{\mathrm{IPFS}}\right)$$

(20)

The edge node then decrypts the image using the symmetric key $SK$:

$$F={\mathrm{Decrypt}}_{SK}\left(E_{SK}\left(F\right)\right)$$

(21)

where F represents the decrypted medical image.

The edge node encrypts the image using the public key $P{K}_{\mathrm{requester}}$ of the medical professional or researcher requesting the data. Re-encrypting the image with the requester public key ensures end-to-end confidentiality. Only the requester’s private key can decrypt the image, preventing interception by unauthorized parties:

$$E_{P{K}_{\mathrm{requester}}}\left(F\right)={\mathrm{Encrypt}}_{P{K}_{\mathrm{requester}}}\left(F\right)$$

(22)

The encrypted image $E_{P{K}_{\mathrm{requester}}}\left(F\right)$ is then sent to the requester, ensuring that only the intended recipient can access the image:

$$\mathrm{Send}\left(E_{P{K}_{\mathrm{requester}}}\left(F\right)\right)\to \mathrm{Requester}$$

(23)

Once received, the requester will use their private key $S{K}_{\mathrm{requester}}$ to decrypt the image:

$$F={\mathrm{Decrypt}}_{S{K}_{\mathrm{requester}}}\left(E_{P{K}_{\mathrm{requester}}}\left(F\right)\right)$$

(24)

Throughout the process, the edge node monitors the access request for suspicious activities, including multiple failed access attempts, unauthorized access attempts using invalid cryptographic keys, unusual request frequencies, and repeated failed authentication. This monitoring is performed by analyzing logs and patterns in real time, and if an anomaly is detected, access is revoked, and the event is logged on the blockchain:

$$\mathrm{Anomaly}=\mathrm{DetectAnomaly}\left(\mathrm{Activity}\right)$$

(25)

$$\mathrm{Log}=\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},\mathrm{Activity},T\}$$

(26)

$$\mathrm{UpdateBlockchain}\left(\mathrm{Log}\right)$$

(27)

Algorithm 2 Intra-Hospital Medical Image Access

Require:  Patient ID PID, Requester ID, Hospital ID, Timestamp T Ensure:  Secure Image access or revocation and logging   1: Step 1: Access Request Submission   2: Requester sends access request with PID, Requester ID and Hospital ID to edge node   3: $\mathrm{Request}=\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},T\}$   4: Step 2: Patient Notification and Approval   5: Edge node notifies the patient via their device   6: $\mathrm{Notification}=\mathrm{SendNotification}(\mathrm{PID},\mathrm{Request})$   7: if Patient Approval then   8:       Step 3: Smart Contract Invocation   9:       Edge node forwards request to smart contract 10:       $\mathrm{Policy}=\mathrm{CheckPolicy}(\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID})$ 11:       if Policy == Allowed then 12:          Step 4: Data Retrieval from Blockchain 13:          if Data is available in off-chain storage then 14:              $H_{\mathrm{IPFS}}\leftarrow \mathrm{RetrieveFromOffChain}\left(\mathrm{PID}\right)$ 15:          else 16:              $H_{\mathrm{IPFS}}\leftarrow \mathrm{RetrieveFromBlockchain}\left(\mathrm{PID}\right)$ 17:          end if 18:          Step 5: Edge Node Data Processing 19:          $E_{SK}\left(F\right)\leftarrow \mathrm{IPFSRequest}\left(H_{\mathrm{IPFS}}\right)$ 20:          Step 6: Decryption 21:          $F\leftarrow {\mathrm{Decrypt}}_{SK}\left(E_{SK}\left(F\right)\right)$ 22:          Step 7: Data Transmission to Requester 23:          Encrypt the image F using the public key $P{K}_{\mathrm{requester}}$ 24:          $E_{P{K}_{\mathrm{requester}}}\left(F\right)\leftarrow {\mathrm{Encrypt}}_{P{K}_{\mathrm{requester}}}\left(F\right)$ 25:          Send the encrypted image $E_{P{K}_{\mathrm{requester}}}\left(F\right)$ to the requester 26:          Step 8: Decryption by the Requester 27:          Requester decrypts the image using their private key $S{K}_{\mathrm{requester}}$ 28:          $F={\mathrm{Decrypt}}_{S{K}_{\mathrm{requester}}}\left(E_{P{K}_{\mathrm{requester}}}\left(F\right)\right)$ 29:          Step 9: Anomaly Detection and Logging 30:          Edge node monitors for anomalies during the access process 31:          Anomaly ← DetectAnomaly(F) 32:          if Anomaly Detected then 33:              Revoke access 34:              Log $\leftarrow \{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},\mathrm{Activity},T\}$ 35:              UpdateBlockchain(Log) 36:          end if 37:       else 38:          Access Denied 39:       end if 40: else 41:       Access Denied 42: end if 43: return Success

Case 2: Inter-Hospital Medical Image Access

In this case, when a doctor, pharmaceutical, or researcher from one hospital wants to access patient data stored in another hospital, as shown in Algorithm 3, they will submit a request. This request includes the professional’s identifier $\mathrm{Requester}\mathrm{ID}$, the hospital identifier $\mathrm{Hospital}\mathrm{ID}$, and the patient’s identifier PID. The request is represented as

$$\mathrm{Request}=\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},T\}$$

(28)

The edge node $E1$ queries the blockchain to retrieve the address of the edge node $E2$ at the hospital where the patient data are stored. This approach saves time by eliminating the need for the system to communicate with multiple edge nodes to locate the patient data.

$$E1\to \mathrm{Blockchain}:\mathrm{Query}(\mathrm{Patient}\mathrm{ID})$$

(29)

The blockchain responds with the address of $E2$.

$E1$ forwards the data access request to $E2$, including the necessary details for verification:

$$E1\to E2:\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},T\}$$

(30)

Upon receiving the request, $E2$ verifies its authenticity by verifying the details against the blockchain to confirm that the request is valid and complies with existing records. If the request is authenticated, $E2$ proceeds to notify the patient of the request and awaits their permission. The patient reviews the request and either approves or denies it through their device. If the patient approves, the request is forwarded for further processing:

$$\mathrm{Notification}=\mathrm{SendNotification}(\mathrm{PID},\mathrm{Request})$$

(31)

$$T_{wait}\le 100\mathrm{s}$$

(32)

If the patient does not respond within this interval, the system automatically triggers an emergency override mechanism to contact the caretaker. If the caretaker also does not give a response, this transaction will end. If the patient’s device verifies the request and approves it, the transaction is signed:

$$\mathrm{Signature}={\mathrm{Sign}}_{S{K}_{\mathrm{Patient}}}\left(\mathrm{Request}\right)$$

(33)

where $S{K}_{\mathrm{Patient}}$ is the patient’s private key.

The smart contract on the blockchain checks the access request against the patient’s predefined privacy policy, ensuring that the request complies with the patient’s consent:

$$\mathrm{Policy}=\mathrm{CheckPolicy}\left(\mathrm{Patient}\mathrm{ID},\mathrm{requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID}\right)$$

(34)

If the policy allows, the smart contract grants access.

$E2$ retrieves the IPFS hash ($H_{\mathrm{IPFS}}$) of the encrypted medical image from the blockchain:

$$H_{\mathrm{IPFS}}=\mathrm{RetrieveFromBlockchain}\left(\mathrm{Patient}\mathrm{ID}\right)$$

(35)

$E2$ retrieves the encrypted image from the IPFS:

$$E_{SK}\left(F\right)=\mathrm{IPFSRequest}\left(H_{\mathrm{IPFS}}\right)$$

(36)

The edge node then decrypts the image using its symmetric key $SK$:

$$F={\mathrm{Decrypt}}_{SK}\left(E_{SK}\left(F\right)\right)$$

(37)

where F represents the decrypted medical image.

$E2$ encrypts the image using a symmetric key ($S{K}_{E1}$) generated for secure transfer to $E1$. The encrypted image is

$$E_{S{K}_{E1}}\left(F\right)={\mathrm{Encrypt}}_{S{K}_{E1}}\left(F\right)$$

(38)

In our system, elliptic curve Diffie–Hellman (ECDH) is used to securely exchange symmetric keys ($S{K}_{E1}$) between edge nodes (E1 and E2). This protocol ensures that the symmetric key is derived independently by both nodes, without the key ever being transmitted directly, thus preventing interception by unauthorized parties. Once the symmetric key ($S{K}_{E1}$) is securely derived and agreed upon by both nodes, it is used to encrypt and decrypt medical images between the nodes. The use of elliptic curve cryptography provides both strong security and computational efficiency, minimizing overhead while maintaining the robust protection of sensitive data. We use ephemeral keys and a 256-bit elliptic curve (secp256k1) to ensure secure and efficient key exchange, which is crucial for the inter-hospital image access procedure, where medical images are securely transferred between edge nodes at different locations.

$$E2\to E1:E_{S{K}_{E1}}\left(F\right)$$

(39)

$E1$ decrypts the image using the symmetric key $S{K}_{E1}$:

$$F={\mathrm{Decrypt}}_{S{K}_{E1}}\left(E_{S{K}_{E1}}\left(F\right)\right)$$

(40)

The edge node encrypts the image using the public key of the requester:

$$E_{P{K}_{\mathrm{requester}}}\left(F\right)={\mathrm{Encrypt}}_{P{K}_{\mathrm{requester}}}\left(F\right)$$

(41)

The encrypted image is then sent to the requester, ensuring that only the intended recipient can access the image:

$$\mathrm{Send}\left(E_{P{K}_{\mathrm{requester}}}\left(F\right)\right)\to \mathrm{requester}$$

(42)

Once received, the requester uses their private key to decrypt the image:

$$F={\mathrm{Decrypt}}_{S{K}_{\mathrm{requester}}}\left(E_{P{K}_{\mathrm{requester}}}\left(F\right)\right)$$

(43)

Throughout the process, edge nodes $E1$ and $E2$ monitor the access request for any unauthorized or suspicious activities.

$$\mathrm{Anomaly}=\mathrm{DetectAnomaly}\left(\mathrm{Activity}\right)$$

(44)

If an anomaly is detected, access is revoked, and the event is immutably logged on the blockchain:

$$\mathrm{Log}=\left\{\mathrm{Patient}\mathrm{ID},\mathrm{requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},\mathrm{Activity},\mathrm{Timestamp}\right\}$$

(45)

$$\mathrm{UpdateBlockchain}\left(\mathrm{Log}\right)$$

(46)

Algorithm 3 Inter-Hospital Medical Image Access Procedure

Require:  Patient ID (PID), Requester ID, Hospital ID, Timestamp (T) Ensure:  Secure image access or revocation and logging   1: Step 1: Access Request Submission   2: Requester submits access request with PID, Requester ID, Hospital ID and Timestamp (T) to $E1$   3: $\mathrm{Request}=\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},T\}$   4: Step 2: Query Blockchain for Target Edge Node Address   5: $E1$ queries blockchain for the address of the target edge node $E2$   6: $E1\to \mathrm{Blockchain}:\mathrm{Query}\left(\mathrm{PID}\right)$   7: Step 3: Forward Request to Target Edge Node   8: Blockchain provides $E2$’s address and $E1$ forwards the request to $E2$   9: $E1\to E2:\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},T\}$ 10: Step 4: Request Verification by $E2$ 11: $E2$ verifies the request against blockchain records 12: if Request is valid then 13:        Step 5: Patient Notification and Approval 14:        $E2$ notifies the patient and awaits their permission 15:        $\mathrm{Notification}=\mathrm{SendNotification}(\mathrm{PID},\mathrm{Request})$ 16:        if Patient approves then 17:           Patient signs the transaction 18:           $\mathrm{Signature}={\mathrm{Sign}}_{S{K}_{\mathrm{Patient}}}\left(\mathrm{Request}\right)$ 19:           Step 6: Smart Contract Validation 20:           Smart contract checks the request against the patient’s privacy policy 21:           $\mathrm{Policy}=\mathrm{CheckPolicy}(\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID})$ 22:           if Policy allows then 23:              Step 7: Data Retrieval and Decryption 24:              $E2$ retrieves IPFS hash from blockchain 25:              $H_{\mathrm{IPFS}}=\mathrm{RetrieveFromBlockchain}\left(\mathrm{PID}\right)$ 26:              $E2$ fetches the encrypted image from IPFS 27:              $E_{SK}\left(F\right)=\mathrm{IPFSRequest}\left(H_{\mathrm{IPFS}}\right)$ 28:              $E2$ decrypts the image using its symmetric key 29:              $F={\mathrm{Decrypt}}_{SK}\left(E_{SK}\left(F\right)\right)$ 30:              Step 8: Encryption for Secure Transfer to $E1$ 31:              $E2$ encrypts the image using a symmetric key $S{K}_{E1}$ 32:              $E_{S{K}_{E1}}\left(F\right)={\mathrm{Encrypt}}_{S{K}_{E1}}\left(F\right)$ 33:              $E2$ securely shares $S{K}_{E1}$ with $E1$ and transmits the encrypted image 34:              $E2\to E1:E_{S{K}_{E1}}\left(F\right)$ 35:              Step 9: Data Transmission and Decryption by Requester 36:              $E1$ decrypts the image using $S{K}_{E1}$ 37:              $F={\mathrm{Decrypt}}_{S{K}_{E1}}\left(E_{S{K}_{E1}}\left(F\right)\right)$ 38:              $E1$ encrypts the image using the requester’s public key 39:              $E_{P{K}_{\mathrm{Requester}}}\left(F\right)={\mathrm{Encrypt}}_{P{K}_{\mathrm{Requester}}}\left(F\right)$ 40:              $E1$ sends the encrypted image to the requester 41:              $\mathrm{Send}\left(E_{P{K}_{\mathrm{Requester}}}\left(F\right)\right)\to \mathrm{Requester}$ 42:              Requester decrypts the image using their private key 43:              $F={\mathrm{Decrypt}}_{S{K}_{\mathrm{Requester}}}\left(E_{P{K}_{\mathrm{Requester}}}\left(F\right)\right)$ 44:              Step 10: Anomaly Detection and Logging 45:              $E1$ and $E2$ monitor for anomalies during the process 46:              $\mathrm{Anomaly}=\mathrm{DetectAnomaly}\left(\mathrm{Activity}\right)$ 47:              if Anomaly detected then 48:                    Revoke access 49:                    $\mathrm{Log}=\{\mathrm{PID},\mathrm{Requester}\mathrm{ID},\mathrm{Hospital}\mathrm{ID},\mathrm{Activity},T\}$ 50:                    $\mathrm{UpdateBlockchain}\left(\mathrm{Log}\right)$ 51:              end if 52:           else 53:              Access denied 54:           end if 55:        else 56:           Access denied 57:        end if 58: else 59:        Access denied 60: end if

6. System Security Proofs

In this section, we provide formal security proofs and supporting lemmas to establish the integrity, confidentiality, and authenticity of the medical images and metadata stored and transmitted within our decentralized framework.

6.1. Security Proof for Data Access Procedure

Lemma 1.

Immutability and Collision Resistance of Blockchain-Logged Data.

We use a secure cryptographic hash function $H:{\{0,1\}}^{*}\to {\{0,1\}}^n$ to guarantee the integrity of the medical data stored on the blockchain. The fundamental property of cryptographic hash functions is that the probability of two distinct inputs generating the same hash is extremely low. This ensures that, once the medical image hashes are recorded on the blockchain, they cannot be altered without detection.

Proof. 

The blockchain uses SHA-256 to store the hashes of medical images and associated metadata. The probability P of a collision, i.e., two distinct inputs generating the same hash for SHA-256, is given by

$$P={\displaystyle \frac{N_m}{2^n}}$$

(47)

where $N_m$ is the number of distinct inputs, and $n=256$ is the output size of SHA-256 in bits. Even for large input sets such as $N_m=2^{30}$, the probability of a collision is

$$P={\displaystyle \frac{2^{30}}{2^{256}}}=2^{-226}\approx 1.5\times {10}^{-68}$$

(48)

This probability is practically negligible. Therefore, any modification to the data would result in a completely different hash, making tampering easily detectable. □

Corollary 1.

The integrity of the medical data accessed through the blockchain is ensured. Any unauthorized modification would be evident because the new data’s hash would not match the stored hash.

6.2. Security Proof for Image Uploading

Lemma 2.

Authenticity and Non-Repudiation via Digital Signatures.

Edge nodes are responsible for uploading medical image metadata to the blockchain. These nodes sign the transactions using their private keys, ensuring the authenticity and non-repudiation of the uploaded data. Since only the private key holder can sign the signature and make it valid, the edge node cannot later deny having signed it.

Proof. 

For any transaction involving a medical image, metadata $R=(\mathrm{HIPFS}\Vert \mathrm{PID}\Vert \mathrm{HID}\Vert T)$ are created. The edge node signs these metadata with its private key $S{K}_{\mathrm{edge}}$:

$$S={\mathrm{Sign}}_{S{K}_{\mathrm{edge}}}\left(R\right)$$

(49)

The blockchain validates the signature using the corresponding public key $P{K}_{\mathrm{edge}}$:

$${\mathrm{Verify}}_{P{K}_{\mathrm{edge}}}(S,R)\to \mathrm{True}/\mathrm{False}$$

(50)

The verification process recalculates the hash of R and compares it with the signed value in S. If the verification is valid, the blockchain confirms that the edge node indeed signed the transaction. Non-repudiation is ensured since only the holder of the private key could have created the signature. □

Corollary 2.

The digital signature guarantees that all transactions, including medical image uploads, are authentic and traceable, thus preserving system integrity.

6.3. Multi-Layer Encryption for Medical Image Hash and Metadata

Lemma 3.

Multi-Layer Encryption Ensures Data Integrity.

To ensure the confidentiality and integrity of medical images and metadata, the system employs multi-layer encryption. The AES is used to encrypt the medical images, while ECC is used for key management. This combination guarantees both confidentiality and integrity during transmission and storage.

Proof. 

A medical image is encrypted using the AES algorithm, which employs a symmetric key $SK$. The metadata $R=\{\mathrm{HIPFS},\mathrm{PID},\mathrm{HID},T\}$ are signed by the edge node using the Elliptic Curve Digital Signature Algorithm (ECDSA). This method is highly efficient and suitable for resource-constrained environments.

The signed metadata S and the original metadata R are then encrypted using the hospital’s public key $P{K}_{\mathrm{hospital}}$:

$$T_{\mathrm{enc}}={\mathrm{Encrypt}}_{P{K}_{\mathrm{hospital}}}(R\Vert S)$$

(51)

This encryption ensures that both the metadata and the signature are securely transmitted, preserving the confidentiality of the data. The AES secures the medical images, while the ECDSA digital signatures protect the metadata. Any attempt to tamper with the data would cause either the signature validation or the decryption process to fail, thus ensuring data integrity. □

Corollary 3.

This multi-layered encryption system combines the AES for symmetric encryption and ECC for key operations, which ensures both the confidentiality and integrity of the data throughout its lifecycle.

6.4. Hash Verification to Detect Tampering Between Blockchain and IPFS

Lemma 4.

Integrity Check through Blockchain and IPFS Hash Verification.

To guarantee the integrity of medical images, we use a hash verification mechanism that cross-checks the hash stored on the blockchain with the one retrieved from the IPFS. Any discrepancy between the two hashes indicates that the image has been tampered with.

Proof. 

Once a medical image is uploaded to the IPFS, it is assigned a cryptographic hash HIPFS, which uniquely identifies the image. This hash is then stored on the blockchain as part of the transaction metadata $R=\{\mathrm{HIPFS},\mathrm{PID},\mathrm{HID},T\}$.

When a medical professional requests the image, the system retrieves the hash HIPFS from the blockchain and compares it with the hash of the image retrieved from the IPFS. Let ${\mathrm{HIPFS}}_{\mathrm{IPFS}}$ be the hash returned by the IPFS during the image retrieval:

$${\mathrm{Verify}}_{\mathrm{Blockchain}}(HIPF{S}_{\mathrm{blockchain}},HIPF{S}_{\mathrm{IPFS}})=\left\{\begin{array}{cc}\mathrm{True},\hfill & \mathrm{if}HIPF{S}_{\mathrm{blockchain}}=HIPF{S}_{\mathrm{IPFS}}\hfill \\ \mathrm{False},\hfill & \mathrm{if}HIPF{S}_{\mathrm{blockchain}}\ne HIPF{S}_{\mathrm{IPFS}}\hfill \end{array}\right.$$

(52)

 □

Corollary 4.

This hash verification mechanism ensures that any attempt to tamper with the image, whether in storage or transmission, is immediately detectable. The blockchain’s immutability guarantees that the correct hash is always available for verification.

6.5. Security Analysis

The proposed system leverages a combination of the Advanced Encryption Standard (AES) and elliptic curve cryptography (ECC) to ensure robust security for medical image storage and sharing. The use of the AES ensures confidentiality by encrypting medical images, while ECC facilitates secure key management and digital signatures, enabling authenticity and non-repudiation. Blockchain technology ensures the immutability of transaction records, and the IPFS (InterPlanetary File System) provides decentralized, tamper-resistant storage. The system continuously cross-verifies the hashes stored on the blockchain with those retrieved from the IPFS to detect data tampering, thus ensuring data integrity.

This system is resilient against several types of attacks, including the following:

• Man-in-the-middle attacks: Due to the use of ECC for encrypted communication and digital signatures, unauthorized interception is prevented.
• Data tampering: The system’s blockchain-based immutable ledger and hash comparison with the IPFS ensure that any modification to the stored data is detected immediately.
• Brute-force attacks: The AES with high-entropy symmetric keys makes decryption by brute force computationally infeasible.
• Replay attacks: The blockchain timestamps and unique transaction IDs prevent attackers from reusing valid transactions to gain unauthorized access.

Thus, the system ensures data confidentiality, integrity, and authenticity, making it suitable for secure medical data sharing while mitigating common cyber threats.

7. Simulation

For a comprehensive performance evaluation of our system, we employed four computers, each configured with the following specifications: a Windows 11 OS, an Intel Core i5 processor, 32 GB RAM, and a 512 GB SSD. These computers are used as edge servers in the hospital. We utilized Truffle Node version 5.11.5 for the data environment, Ethereum (Ganache) version 7.9.1 for the blockchain simulation, and the JavaScript version 0.66.1 of the IPFS platform for storage on the edge system. Every edge node has an IPFS node to store data in a decentralized manner.

Firstly, we compared the image upload latencies of our IPFS with those of traditional cloud storage, as illustrated in Figure 6. The results showed that the IPFS demonstrated lower latency, with the upload times for medical images ranging from 10 MB to 100 MB. In contrast, traditional cloud storage showed significantly higher latencies for the same image sizes, highlighting the IPFS’s capability to efficiently manage medical data without requiring low-latency handling. This performance surpasses the healthcare industry’s recommended threshold of maintaining latency below 1 s for efficient medical data handling in emergency scenarios, as mentioned by Nguyen et al. [20].

We also analyzed the user registration performance of our system, as shown in

Table 2. User registration performance.

Number of Users	Time Taken (ms)	Throughput (tx/s)
100	2612	21.68
200	4244	29.64
300	6862	36.64
400	8922	47.14
500	10,230	59.64
600	11,876	65.71
700	13,028	77.90
800	14,893	90.43
900	15,594	100.52
1000	16,061	109.22

. We evenly divided the total number of users among all four nodes, so each node handled exactly 25% of the registrations process at each workload. We then computed throughput by summing the total registrations processed across all nodes and dividing by the total elapsed time. This setup ensured that our reported performance metrics accurately reflected the overall system behavior. As the number of users increased from 100 to 1000, the registration time rose from 2612 ms to 16,061 ms, while throughput improved from 21.68 tx/s to 109.22 tx/s. These results show the system’s ability to scale efficiently under increasing user demands. Notably, the throughput achieved (109.22 tx/s) significantly exceeds typical blockchain healthcare solutions, which generally manage around 20 transactions per second, as explained by Anwar et al. [17].

Furthermore, we analyzed the image upload performance of our system. The encryption times for image sizes ranging from 10 MB to 100 MB increased linearly, starting at 28 ms and peaking at 335 ms. The hashing times remained minimal, ranging from 7.5 ms to 116 ms, while the IPFS upload times spanned from 90 ms to 1500 ms, as illustrated in Figure 7. These results demonstrate the system’s ability to efficiently handle large images during upload operations. Our AES encryption performance aligns fully with NIST cryptographic standards (FIPS-197) [39], ensuring robust protection against brute-force attacks.

In terms of intra-hospital image access, the encryption times were between 25 ms and 315 ms, while the decryption times varied from 21 ms to 300 ms. The IPFS retrieval times, spanning from 75 ms to 950 ms, ensured rapid local access with minimal latency, demonstrating efficient data sharing within the hospital, as shown in Figure 8. This performance indicates that the system is well suited for intra-hospital operations, where quick access to medical images is critical for diagnosis and treatment. The latency results meet the healthcare standards, which require medical data retrieval within 1 second for critical clinical scenarios [26].

In terms of inter-hospital image access, as shown in Figure 9, the encryption and decryption times were slightly higher, starting at 53 ms and 43.5 ms, respectively, and peaking at 552 ms and 418 ms for 100 MB images. This increase is due to the additional encryption and decryption steps required for secure image sharing between edge servers and network communication. Despite this, the IPFS retrieval times remained almost the same as those observed in intra-hospital access, maintaining consistency and ensuring that the system remains efficient even when sharing data across different hospitals. Figure 10 shows our estimated gas costs in Wei for various smart contract operations, which were implemented in a solidity v0.8.25 framework of the Truffle Node. The throughput and latency analyses demonstrate the system’s efficiency in handling large medical images while ensuring secure, scalable, and high-speed operations, as shown in Figure 11 and Figure 12. In all scenarios, the system maintained optimal performance, with low latency for encryption, decryption, and retrieval, even as file sizes grow. The higher throughput in intra-hospital access and the controlled latency in inter-hospital access highlight its robustness for real-time medical data management, making it highly suitable for healthcare deployment.

8. Hypothesis Validation

The framework’s performance was evaluated through simulations replicating real-world healthcare workflows. The blockchain managed access control via smart contracts, while the IPFS decentralized medical image storage. Edge nodes, configured with the AES for image encryption and ECC for key management, processed data locally to minimize latency. Simulations tested upload/retrieval times, throughput, and security resilience across intra- and inter-hospital scenarios using medical images ranging from 10 MB to 100 MB.

Results of Hypotheses

This section evaluates the validity of the hypotheses through empirical results and the prior literature.

Hypothesis 4.

Our results validate H1: integrating blockchain, the IPFS, and edge computing reduced latency by 40% compared to centralized cloud systems while maintaining scalability. This aligns with Nguyen et al. [20], who reported latency reductions in decentralized EMR systems but faced throughput limitations (20 tx/s). Our framework achieved 109.22 tx/s, addressing the scalability gaps in the work by Anwar et al. [17] and McBee et al. [18], which struggled with large medical images.

Hypothesis 5.

The multi-layered encryption (AES + ECC) ensured confidentiality, with brute-force resistance meeting NIST standards [39]. The encryption times for 100 MB images remained under 335 ms, outperforming Muhammad et al. [33], where decryption delays affected real-time access. This corroborates Jabarulla and Lee’s [16] emphasis on patient-centric encryption but resolves their latency issues through edge-aided key management.

Hypothesis 6.

Edge computing reduced the intra-hospital retrieval latency to <500 ms, meeting healthcare standards [26]. While Gao et al. [26] and Liu et al. [29] utilized edge computing, their frameworks lacked IPFS integration, leading to higher storage costs. Our hybrid approach reduced costs by 60% compared to traditional blockchain solutions.

9. Comparison

Table 3. Comparison of key features across various frameworks.

Feature	[40]	[41]	[23]	[16]	[42]	Our Work
Decentralized System	Yes	Yes	Yes	Yes	Yes	Yes
Scalability	Yes	Yes	Yes	Yes	Yes	Yes
Traceability	Yes	Yes	Yes	Yes	Yes	Yes
IPFS	No	No	Yes	Yes	No	Yes
Edge Computing	No	No	No	No	Yes	Yes
Data Auditing and Provenance	Yes	Yes	Yes	Yes	Yes	Yes
User Authentication	Yes	Yes	Yes	Yes	Yes	Yes
Smart Contract	Yes	Yes	Yes	Yes	Yes	Yes

highlights advancements over prior works. Previous studies mainly [40,41,42] focus on decentralization through blockchain and smart contracts, but they often encounter scalability issues when handling large medical data. In contrast, our approach combines blockchain with the IPFS to gain more efficiency in data storage and retrieval. Furthermore, while many of these solutions fail to address the need for rapid data access, our framework incorporates edge computing, which reduces latency and enhances responsiveness in critical healthcare scenarios. All these works rely on single-layer encryption methods; however, we employ a multi-layered security approach, using elliptic curve cryptography (ECC) for key management and the Advanced Encryption Standard (AES) for data protection to provide more security. Although auditability has been acknowledged in all these works [16,23,40,41,42], our system improves it by immutably logging all data transactions, ensuring greater traceability and accountability in sensitive healthcare settings. Through these innovations, our framework overcomes the limitations of existing solutions, offering a more efficient, secure, and patient-centric approach to medical image sharing.

10. Limitations and Further Developments

While the proposed framework represents a significant advancement in secure medical image sharing, certain limitations should be acknowledged. One notable limitation is that the encryption and decryption processes in the framework require substantial computational resources, especially when processing large medical images. Although edge computing reduces latency by handling data locally, high-volume scenarios may overload edge nodes and affect responsiveness. Additionally, performance evaluations conducted in controlled environments may not fully reflect real-world healthcare settings characterized by variable network conditions and dynamic access demands.

Further developments will focus on enhancing the framework’s adaptability through the integration of machine learning, particularly for predictive anomaly detection and automated threat response. This development aims to strengthen the system’s resilience by enabling the early identification of security breaches and optimizing decision-making processes. Additionally, integrating research into more efficient cryptographic algorithms and hardware acceleration techniques will help reduce computational demands while maintaining high security standards. These advancements will address current limitations and improve the framework’s adaptability to manage future healthcare data more effectively.

11. Conclusions

This paper proposes a decentralized architecture for medical image sharing that eliminates the limitations of traditional systems. It enhances security, reduces costs, and improves retrieval speed by integrating blockchain, the IPFS, and edge computing. The blockchain ensures data integrity by maintaining an immutable record of access logs. The IPFS provides decentralized storage, which reduces reliance on a single server while lowering costs by 60% compared to traditional blockchain solutions. Edge computing optimizes performance by processing data closer to users and reducing retrieval latency to under 500 ms for large medical images, making the system 40% faster than cloud-based alternatives. Smart contracts automate access control, allowing patients to manage permissions without intermediaries. The system applies multi-layer encryption and cryptographic key management, ensuring resistance against unauthorized access and cyber threats. The integration of our system in existing healthcare infrastructures can bring scalability and interoperability while maintaining high security and efficiency.