IPFS-blockchain-based delegation model for internet of medical robotics things telesurgery system

Abstract

The concept of the Internet of Medical Robotics Things (IoMRT) is where intelligent robots assess surrounding events, combine information from their sensors, use both local and dispersed intelligence to determine the best course of action, and move or command objects. Telesurgery is one application of IoMRT (TS). With 5G-enabled Tactile Internet (TI) enabling telesurgery (TS), there is ample opportunity to provide exceptional, accurate, ultra-responsive, and real-time virtual surgical procedures. The potential for accurate surgical diagnosis involving the exchange of patient electronic medical records (EMR) with several doctors using an assistant robot (AR) could be greatly useful in the medical field. As a part of this, permission delegation has emerged as a novel approach for data sharing in TI. Robust control of access guidelines combined with a configurable permission scheme promise secure EMR exchange. The present research proposes a multi-hop permission delegation strategy for EMR exchange based on blockchain technology and with configurable delegation depth. Furthermore, the original EMRs are stored on the interplanetary file system (IPFS). Permission delegation uses smart contracts and proxy re-encryption technology. Attribute-based encryption, which offers fine-grained management of access, is used to guarantee data security. Blockchain is also utilized to accomplish immutability and traceability. Delegators may regulate the depth of delegation by using smart contracts. The suggested approach satisfies the intended aims, according to analysis of the protocol. Lastly, the Ethereum test chain is used to assess and put the suggested method into practice. The outcomes of the conducted experiments demonstrate that the suggested protocol operates better than the competitors.

Keywords:

• Internet of medical robotics things (IoMRT)
• blockchain
• data security
• permission delegation
• access control
• smart contract

1. Introduction

Globally, medical care is a critical issue for every person and every country. Doctors oversee and keep an eye on each patient's health, either in person or virtually. In the past, this was achieved manually, where patients had to come to the hospital to speak with doctors about their concerns. This meant it was an expensive, difficult, and drawn-out procedure. Later, as a result of developments in technology for communication, physicians can now virtually expand their practices using a novel approach known as telemedicine (Tanwar et al., 2020). This makes it easier to provide real-time healthcare services remotely. As a consequence of rapidly developing information technology, the Internet of Medical Robotic Things (IoMRT) is growing popular in the medical field. For example, telesurgery (TS), sometimes known as remote surgery, is one of the most interesting areas in the field of telemedicine (Gupta et al., 2020). Using surgical robots at one end, telesurgery helps physicians to perform live surgery remotely over wireless communication channels (WCC). Real-time and live applications, such as TS, do not accept any delay or inaccurate patient information and thus it may lead to the death. In this work, patient information that is shared by the delegator is the key point for investigating. Sharing electronic health records (EMRs) enables physicians to provide patients with excellent medical treatment (Alamer & Basudan, 2022; Basudan, 2022; Gao et al., 2022; Liu et al., 2023). An assistant robot (AR) is used to distribute medical history data for this purpose. Consequently, it has progressively decreased medical resource asymmetry, expenses, and isolated islands of medical knowledge, while increasing efficiency and modernizing the siloed nature of the conventional medical industry.

EMRs are subject to stringent privacy control measures; data security is therefore essential for data sharing (Agarwal et al., 2023; Alamer, 2024b, 2024a; Alamer & Basudan, 2022; Das & Namasudra, 2023; Xu et al., 2023). Patients ought to be in complete control of their health information. Generally, access control is an essential strategy for guaranteeing data security in networks that share data. The majority of access control systems in use today depend on permission from the data owner. The ongoing communication among data owners and users is necessary for such systems. Patients find it challenging to stay online all the time and are opposed to repeated disruption. Granting authorization to a delegatee, or an AR, in order to relieve the data owners of some of their burden, is a viable alternative. Scherrer and Perrig (2021) describes in details the security, privacy, trust, and anonymity issues. Furthermore,in order to use simulated real-life in cybersecurity scenarios, Deng et al. (2021) applied Problem-based learning with Knowledge Graph (KG)-based guidance for hands-on labs in cybersecurity training by using an online laboratory environment. In the SDN-based Iot models, Wani and Khaliq (2021) proposed an intrusion detection system for to address the issues of an optimum protection against prevailing powerful threats in cyber world that produced in lightweight security protocols.Regarding intrusion detection systems, Hooshmand and Hosahalli (2022) proposed a model using one-dimensional in Convolutional neural networks architecture. They applied transformation the performance towards the task of network anomaly detection in cybersecurity. By granting flexible permission assignment to other users, like physicians, access control can be implemented.

The majority of permission delegation systems are cloud-based that also offers significant amounts of storage capacity and thus the cloud can make it easier for different stakeholders to share information (Sivan & Zukarnain, 2021). Using the Amazon cloud platform, Joshi et al. (2019) created an authorization system for EMR services that enabled medical service providers to receive permissions from cloud-based EMRs. The ciphertext-policy attribute-based encryption (CP-ABE) library was utilized in this project. By decentralizing various levels of key publishing authority, Ahuja and Mohanty (2017) integrated CP-ABE with an organizational framework to create an extendable permission delegation system. In order to address the issue of key delegation misuse during the authorization delegation procedure, the cloud was deployed as a trusted storage solution. Chen et al. (2020) also suggested a ciphertext-policy hierarchical attribute-based encryption system called CP-HABE-AKDA, which guards against key-delegation misuse. To guarantee key delegation privacy, a rigorous top-to-bottom key delegation was implemented using an ordered graph. In addition, the concept for implementing searchable functionalities using cloud computing was initially put up by Xu et al. (2019) and may achieve multi-keyword and key range searches in digital medical networks. However, there was a limitation in that the data was limited to being accessed by patients or their doctors. Subjects were given the flexibility to organize multi-hop delegation paths based on their judgments, in a study from Wang et al. (2021). Healthcare practitioners may search for and access data that is prioritized from high to low based on urgency by using autonomous delegation of authorization. However, because the cloud is an observant but reliable semi-entity, cloud-based permission delegation systems are susceptible to security threats including collusion attacks and single point of failure. Despite this, research indicates the use of blockchain is a viable solution to address these issues (Zhang & Lin, 2018).

Decentralization, openness, anonymity, and robustness are some benefits of blockchain. Blockchain is extensively utilized in the domains of finance, healthcare, and the internet of vehicle (IoV) (Alamer, 2024a; Assiri, 2023; Haleem et al., 2021; Li et al., 2023; Liu et al., 2023; Sharma et al., 2023; Wang et al., 2022; Xu et al., 2023; Yaqoob et al., 2021). Permission delegation was first included in the Bitcoin blockchain by researchers, who also tokenized permissions and managed token transfers using transactions (Zyskind & Nathan, 2015). Thus, the integration of federated learning (FL) and blockchain leads to a new paradigm which potentially transforms into decentralized, secure, and privacy-enhancing systems (Alamer, 2024b). Liu et al. (2023) used generative adversarial networks, blockchain, and differential privacy to create a new privacy protection framework (BFG) for decentralized environments. The framework can effectively resist attacks and successfully avoid a single point of failure. A blockchain application for a healthcare management system with strict authentication was presented by Deepa et al. (2022). The SHA-256 hash technique was utilized to provide the network with strong security protocols through strict authentication in the cloud. Ethereum blockchain technology is used in this application to provide decentralized storage. Using Internet of Things resources, Alamer (2024b) presented a privacy-preserving federated learning with a secure collaborative for malware detection models. To improve the security of the delegation process, Deebak and Hwang (2023) included the period's validation in the permission procedure. Lacking the support of any reliable third parties, Chen et al. (2023) established broad capabilities via smart contracts for the IoT by employing blockchain events. Further to this, Wang et al. (2023) committed to solve the problem of unauthorized access weaknesses in permission delegation. Additionally, Sharma et al. (2023) presented a Distributed Application (DA) that protects privacy and uses blockchain technology for the creation and upkeep of healthcare certificates. In order to generate and issue medical records, the distributed program acts as an interface between the blockchain network and system objects such as healthcare facilities, verifiers, and conventional authorities. In a cloud context, Vidhya and Kalaivani (2023) employed blockchain to finish permission delegation, but they were unable to grant access to additional users. A Blockchain-based architecture for health data sharing was proposed by Sabrina et al. (2023) to facilitate the sharing of electronic health records between clinicians and patients inside the country's healthcare system. The scenario was used to create a safe Blockchain-based data exchange episode in a lab simulation setting, which should spark a new trend of patients and healthcare providers exchanging electronic health records. Using attribute-based encryption (ABE), Srinivas et al. (2023) introduced a unique framework to store and share the data in a safe manner. Still, these systems only account for one-hop delegation. The benefit of the decentralized InterPlanetary File System (IPFS) protocol is modified in the suggested method in order to facilitate data storage in a blockchain setting. Consequently, a distributed data storage-based paradigm that is dependable, safe, and effective is needed.

Rights of access are not restricted to single-hop permission delegation in real-world healthcare circumstances. Patients struggling financially look for organizations and groups that might be willing to pay for their medical records. Owing to their physical and energetic constraints, patients lack sufficient energy and time to individually answer each permission request. It is necessary to be granted access permission in order to assign others such permission. Patients utilizing delegators who are able to assign authority to more individuals. Delegating multiple hop access rights can increase data availability flexibility while lessening the need for authorization from data owners. Finding a balance between data security and permission delegation is crucial.

To address these issues, the EMR sharing system develops a multi-hop permission delegation approach with configurable delegation depth. A patient may assign access privileges to an assignee. To optimize the significance of the information and expand the versatility of the information exchange system, delegates with access rights can subsequently grant rights to additional users, like surgeons. A transmission chain is formed by authorized users. Patients can make certain that they oversee their data on the transmission chain by configuring policies for access control and delegation depth. The principal contributions are outlined below.

1. To facilitate the exchange of data, a multi-hop delegation paradigm combining blockchain and IPFS is developed. The initial EMR is transmitted to IPFS for distributed storage, with symmetric encryption techniques utilized to guarantee data security during storage. The symmetric key is encrypted using CP-ABE and a policy monitoring access control is established to limit the delegatee's characteristics. The intended ciphertext conversion is completed with the help of the proxy re-encryption technique. Only those who have paid for the service and complied with the terms of access are able to decode this. Blockchain technology assures data storage and transaction security through the utilization of smart contracts that faithfully carry out multi-hop delegation supervision and ciphertext conversion.

2. A method of encryption known as ciphertext-policy attribute-based proxy re-encryption (CP-PRABE) is developed, enabling multi-hop delegation and offering users granular access. The patient formulates the policy for access on the ciphertext and uses CP-ABE to provide fine-grained access control. In order to accomplish effective ciphertext conversion without altering the patient's access policy, the proxy re-encryption key construction is enhanced. As a result, computing overhead is greatly reduced. Through smart contracts, the patient determines the degree of delegation of access authority for each data transfer chain. By doing this, throughout the multi-hop delegation process, the patient maintains control over the data.

3. The deployed smart contracts are the access smart contract (ASC), the delegation depth smart contract (DDSC), and the delegation smart contract (DSC). The patient can restrict the delegatee's ability to access data via DDSC by changing the delegation depth for each delegatee. A delegatee with zero delegation depth can no longer exchange data. DSC has the ability to convert ciphertext into forms that different delegatees can decode and fill out. Furthermore, there is a substantial decrease in communication overhead as this method does not call for contact among the delegator and delegatee. In order to provide identity verification, ASC searches delegation data within a predetermined time frame. Furthermore, the Ethereum platform is used to implement the smart contracts, and assessments are carried out regarding the protocol effectiveness and smart contract time cost.

The structure of this article is as follows. The problem description, system architecture, and security objectives are presented in Section 2, while the fundamental ideas of the proposed authentication protocol are shown in Section 3. Section 4 presents the proposed protocol, which is a blockchain-based multi-hop permission delegation mechanism. Section 5 reports a security analysis, and Section 6 assesses the suggested protocol's performance. This work is summarized in Section 7.

2. Problem statement

The problem statement section analyzes the system architecture and also conducts an in-depth examination of the security threats and finally outlines the goals.

2.1. System architecture

Figure 1 illustrates the system model, which includes the blockchain network, IPFS, control center (CC), delegator, and delegatees. Smart contracts and blockchain ledgers make up the blockchain network. Presume that the data user in the specified blockchain has the authority to grant access to the EMRs. The protocol encrypts HER and stores them in IPFS using symmetric encryption. Additionally, the ciphertext-policy attribute-based encryption transforms the symmetric key and file location data, which is then recorded in the blockchain. The network and proxy re-encryption facilitate delegation rights between the stakeholders involved as the smart contract manages the delegation depth. For example, a patient may direct to a hospital for important diagnosis that may lead to surgical intervention. He can have the AR from the hospital to be alongside with him and can authorize him to communicate with surgeons from external hospitals (telesurgery). In this way, the AR has the access for patient health records and thus it can delegate different surgeons to access the patient health records.

• Control center (CC) generates system parameters which are then keyed in into the blockchain and can be accessed publicly. The delegatees are given private keys based on the specific features of the CC.

• A delegator may be a patient or any authorized user. In the proposed system model, the patient can provide two types of authorization for the AR. First authorization is to allow the AR to access the EMRs. Furthermore, the AR will also have a right to delegate other surgeons to access the EMRs. Second authorization is related to data generated during surgery. Patient can also authorize the AR to collect the data during surgery and store it in the blockchain. They are the ones who generate, upload and preserve the encrypted EMRs. Besides, they are in charge of designing control policies and delegating permission to the surgeons who may need to access the EMRs. They are also the ones who handle the delegation depth. Authorized users such as AR, can choose to re-delegate their access permission.

• Delegatees are the other data users like the surgeons who aim to access EMRs from delegators. They must conform to the access control policies because they can be granted access rights and assigned authority by the delegator. They can either be a new delegator who will deploy their access rights.

• InterPlanetary File System (IPFS) is a distributed storage. It can safely share and preserve different types of files if it has the hash value designed to match he file content. All the EMRs that are encrypted are stored in the IPFS and the users can access them using the hash address provided.

• Blockchain and smart contracts. Blockchain preserves the key ciphertext, re-encrypted keys and system parameters. On the other hand, smart contracts provide re-encrypted ciphertexts and manage the depth of delegation.

Figure 1. System model.

2.2. Security threat

In the system model, the blockchain is defined as a distributed technology used for permanent data storage. The smart manages preset functions but permanently operates after its set. The delegator is the only person that can be fully trusted with the system. When there is a malicious threat or attack, the processes are altered with and the EMR are at risk. There are instances where the delegatee collaborates with other data users are forcefully try to gain the right over the data.

2.3. Security goals

In order to address this threat, the protocol seeks to achieve these goals:

• To maintain data confidentiality and integrity. The system aims to protect data integrity and confidentiality as they share the data. In instances where there are gaps on the integrity of the records, the medical officers are likely to offer substandard treatment or even result to medical complications. Besides, it is a privacy violation to leak the medical information of the patient. This also affects the healthcare institution and the medical experts involved because their reputation is at stake. Therefore, it is important for only the users and authorized individuals to gain access to the EMRs because they cannot risk tampering with them.

• To resist conspiracy attacks. There are various semi-trusted agencies such as the attacker collaborating with the proxy to access the data or a multi-hop delegation situation which enables patients or healthcare providers to private access the data by working with other delegatees. Thus, the system should be made to protect the patient data even if there are attempts of malicious attacks that conspire with the authorized users.

• Fine-grained access control. There must be a fine-grained access control which can be achieved by only allowing the delegator to manage the policies on data access. It is impossible for the external attackers to get the access that is determined by the original owner.

• Multi-hop delegation. It is important to design this to minimize the user's workloads. There are also instances when the patients find it challenging to manage the delegation depth. Therefore, it is recommended to implement a multi-hop delegation system that will facilitate patient control and security.

3. Preliminaries

3.1. Bilinear pairing

Definition 3.1

Bilinear Pairing

Assume that G is a prime order additive group of order p. P is the generator of G. $G_T$ is a multiplicative cyclic group of the same prime order p. An $\hat{e}$ bilinear map If $G\times G⟶G_T$ meets the following criteria, it can be considered an admissible bilinear map.

1. Bilinear: For all $a,b\in Z_p^{\ast }$,$\hat{e}(\mathrm{aP},\mathrm{bP})=\hat{e}(P,P{)}^{\mathrm{ab}}$.

2. Nondegenerate: There exists $1_{G_T}\in G_T$ such that $e(P,P)\ne 1_{G_T}$.

3. Computable: $\hat{e}$ is efficiently computable.

3.2. Complexity assumptions

The access structure $(\tau ,\phi )$ for linear secret-sharing schemes (LSSS) is defined, where φ is an injective function from $\{1,2,\dots ,l\}$ features, and τ is a $l\times n$ matrix. Take into consideration the column vector $\tau \cdot \nu$, which represents the vector of l shares of the secret s, s being the secret to be shared, and $r_2,\dots ,r_n$ representing the random choices. It is the share of $\phi (i)$ that is $(\tau \cdot \nu {)}_i$. Since S meets the access structure, defined as $\eta =\{\phi (i)\in S\}$, let us assume that $S\in (\tau ,\phi )$ is an authorized set. Then, if $\{{\gamma }_i\}$ are legitimate shares of any secret s, then there are constants $\{{\varpi }_i{\}}_{i\in l}$ such that $\sum _{i\in l}\varpi (i){\gamma }_i=s$.

3.3. Ciphertext-policy attribute-based proxy re-encryption (CP-ABPRE) framework

The implementation of a multi-hop CP-ABPRE protocol which has below processes (Liang et al., 2013):

• $\mathbf{\text{Setup}}(\eta ,\mathrm{Uni})⟶(\mathrm{para}{m}_{\mathrm{pub}},\mathrm{msk})$: Consider the security parameter η and an attribute universe Uni as input, it outputs the public parameter $\mathrm{para}{m}_{\mathrm{pub}}$ and has a master secret key msk.

• $\mathbf{\text{KeyGen}}(\mathrm{para}{m}_{\mathrm{pub}},\mathrm{msk},S)⟶s{k}_s$: Given the public parameter $\mathrm{para}{m}_{\mathrm{pub}}$, the master key msk and an attribute set S as input, the private key $s{k}_s$ is outputted.

• $\mathbf{\text{ReKeyGen}}(\mathrm{para}{m}_{\mathrm{pub}},s_{j-1},s_j)⟶r{k}_{j-1⟶j}$: In order to send the ciphertext, it outputs a re-encryption key $r{k}_{j-1⟶j}$ upon receiving $\mathrm{para}{m}_{\mathrm{pub}}$, the secret value $s_{j-1}$ for user j.

• $\mathbf{\text{Enc}}(\mathrm{para}{m}_{\mathrm{pub}},(\tau ,\phi ),m)⟶C_0$: It produces an original ciphertext $C_0$ that can be further encrypted after receiving $\mathrm{para}{m}_{\mathrm{pub}}$, an access structure $(\tau ,\phi )$, and plaintext m.

• $\mathbf{\text{ReEnc}}(\mathrm{para}{m}_{\mathrm{pub}},r{k}_{j-1⟶j},C_{j-1})⟶C_j$: It outputs the $j^{\mathrm{th}}$ level ciphertext $C_j$ given the input of the $j-1^{\mathrm{th}}$ level ciphertext $C_{j-1}$, the public parameter $\mathrm{para}{m}_{\mathrm{pub}}$, and a re-encryption key $r{k}_{j-1⟶j}$.

• $\mathbf{\text{Dec}}(\mathrm{para}{m}_{\mathrm{pub}},s{k}_s,C_0)⟶m$: The plaintext m is output given the input of an original ciphertext $C_0$, the private key $s{k}_s$, and the public parameter $\mathrm{para}{m}_{\mathrm{pub}}$.

• ${\mathbf{\text{Dec}}}_{\mathbf{\text{R}}}(\mathrm{para}{m}_{\mathrm{pub}},s{k}_j,C_j)⟶m$: Given the public parameter $\mathrm{para}{m}_{\mathrm{pub}}$, the private key $s{k}_j$ and $j^{\mathrm{th}}$ level ciphertext $C_j$ as input, the plaintext m is outputted.

3.4. Blockchain

This is a technology that supports the crypto-currency in the form of a Bitcoin (Nakamoto & Bitcoin, 2008). Its features include decentralized, irreversible and programmable. In other words, it is defined as a data storage and verification mechanism that is managed by encrypted data blocks. There is also an agreement algorithm designed from a distributed nodes that collect and manage all the data uploaded in the system. The smart contract or automated scripts are also used in the system to manage the data. The technology can be grouped into, public, private, and consortium (Yuan & Wang, 2016). Consortium blockchain can only be accessed by the consortium users. These people control those who access the transactions based on the regulations that they set. Moreover, smart contracts are also decentralized and autonomous. They are automatically integrated after the contract is officially implemented. The smart contracts are implemented using the decentralized storage and the confirmation program codes. This makes it possible to confirm the fairness and impartiality of the system (Bodkhe et al., 2020). The propose protocol uses blockchain to delegate permission and manage all the important information.

4. Proposed protocol

This section provides a summary of the proposed protocol as illustrated in Figure 2, followed by discussing the protocol in detail and smart contract design.

Figure 2. Proposed protocol.

4.1. Protocol overview

The system workflow is consider as follows:

• The system setup stage is where all the users register their account in the consortium blockchain for them to access the services. The CC generates limits and attribute keys $s{k}_j$ that are provided to the people depending on their features. Then the patients upload their EMR $C_m$ that is encrypted to the IPFS which is hashed and passed to the hash address $H_{C_m}$. After this, they send the encrypted symmetric key and hash address $C_0$. There are nodes hat verify the data that has been uploaded and creates another block based on a consensus mechanism.

• The delegation stage is where the data users who seek to access the data send their request by sending a fee to the delegator. The DDSC confirms if the user is authorized to re-deploy. If it fails, then they are refunded their payment. If it agrees the delegator that had re-assigned the data rights creates a matching re-encryption key $r{k}_{j-1⟶j}$ and sends it to the blockchain having the address of the user. They also create the depth De of delegation for the delegatee. After the DSC gets the re-encryption key $r{k}_{j-1⟶j}$, it confirms that the ciphertext $C_j$ located in the upper part is secure. The DSC re-encrypt it $C_{j-1}$ with $r{k}_{j-1⟶j}$ if he confirms that all the conditions are addressed. This verified delegatee can be tasked as the new delegator to realize multi-hop delegation. They are the ones who would then handle the same procedure in case there are other individuals who seek delegation permission. However, this automatically stops once their depth De of delegation completes and gets to zero.

• The final is the data sharing stage whereby the delegatee receives the symmetric key and hash address after they have decrypted the ciphertext $C_j$. They then transfer the access request to IPFS while attaching it to the address. The IPFS generates the access smart contract (ASC) that examines if they have the permission to get the data. It then passes the result and the delegatee gets the original ciphertext $C_m$ from IPFS. They then decrypt it.

4.2. Protocol description

1. System setup stage. This stage is done by CC and performs the following:

   • The system takes into account the attribute universe Uni and a security parameter η. Next, the CC chooses random generators $P_1,P_2\in G$, and $Z=z\cdot P_1$, as well as a random value $z\in Z_p^{\ast }$.

   • Chooses a bilinear pairing $\hat{e}:G\times G⟶G_T$, and sets the following three hash functions: $H_1:\{0,1{\}}^{2k}⟶Z_p^{\ast }$, $H_2:\{0,1{\}}^{\ast }⟶G$, $H_3:\{0,1{\}}^{\ast }⟶G$.

   • Public parameters for the system are as follows: $\mathrm{para}{m}_{\mathrm{pub}}=(Z,G,G_T,\hat{e},P_1,P_2,\hat{e}(P_1,P_1),H_1,H_2,H_3)$.

   • All users must register with the CC, including delegators and delegatees. Based on these system users' characteristics, the CC issues private keys. To be more specific, it selects a random value $d\in Z_p^{\ast }$ and computes $\mathrm{ke}{y}_1=z\cdot d\cdot P_1+P_1$, $\mathrm{ke}{y}_2=d\cdot P_1,\mathrm{\forall \chi }\in S$, $L_{\chi }=d\cdot H_2(\chi )$, where χ is an attribute in the attribute set S.

   • CC transmits the private key $s{k}_s=(\mathrm{ke}{y}_1,\mathrm{ke}{y}_2,\mathrm{\forall \chi }\in S,L_{\chi })$ to these user using a secure channel. They must ensure that their private keys are secure.

2. Delegation stage. This stage is done either by the patient or AR and performs the following:

   • Encrypting the original EMR.

     		–	Using symmetric encryption, the delegator encrypts the original EMR before sending it to IPFS. The hash address $H_{C_m}$ of these data is sent by the IPFS.
     		–	The delegator delivers $C_0$ to the system after coding the symmetric key $k_{\mathrm{sym}}$ and hash address $H_{C_m}$ into $C_0$.
     		–	An LSSS $(\tau ,\phi (i))$ is chosen by the delegator; τ is a $l\times n$ matrix, and $\phi (i)$ is the function that connects the rows of τ to features.
     		–	The delegator sets $s=H_1(k_{\mathrm{sym}})$ and a random vector $\nu =(s,x_1,\dots ,x_n),$ where $x_1,\dots ,x_n\in Z_p^{\ast }$. He/she also sets ${\gamma }_i=\nu \cdot {\tau }_i$ for i=1 to l, where ${\tau }_i$ is the vector equivalent to the $i^{\mathrm{th}}$ row of τ.
     		–	The delegator selects $r_1,\dots ,r_l\in Z_p^{\ast }$, set $Y_1=k_{\mathrm{sym}}\cdot \hat{e}(P_1,P_1{)}^s,Y_2=s\cdot P_1,Y_3=s\cdot P_2,\{B_i={\gamma }_i\cdot Z+(-r_i)\cdot H_2(\phi (i)),C_i=r_i\cdot P_1{\}}_{i=1}^l,F=H_3(Y_1,Y_2,\{B_i,C_i{\}}_{i=1}^l)$.
     		–	Finally, the delegator generates original ciphertext $C_0=(Y_1,Y_2,Y_3,\{B_i,C_i{\}}_{i=1}^l,F),\phi (i)$ are the attributes that make up the access system $(\tau ,\phi )$.

   • Re-encryption keys and re-encryption ciphertext. Given the $(j-1{)}^{\mathrm{th}}$ conversion of the level ciphertext. It is only the $j^{\mathrm{th}}$ delegatee that has the freedom to decrypt it. The stage entails producing re-encryption keys and re-encryption ciphertext. Anyone wanting to access the EMR transfer tokens to the delegator using an account activating DDSC. This DDSC determines the level of the delegation depth $D{e}_{j-1}$. If the delegation depth is zero, they are refunded their payment. The ReKeyGen performs as includes:

     		–	The delegator uses the re-encryption keys for the requesters other than the private key generation. The delegator examines the credibility status of the requesters to identify if they can achieve the multi-hop delegation. The delegator is also in charge of choosing the maximum number of users to delegate and he delegation depths using parameter De.
     		–	Delegatees that want an access rights requests it from the delegator, who then sends then a secret value $s_j$ for user j, and signs the $s_j$.
     		–	The delegator sends $(s_j,\mathrm{sign}(s_j))$ to the user and then sends to DSC by generating the re-encryption key $r{k}_{j-1⟶j}=\{\hat{e}(P_1,P_1{)}^{s_j},j=1,\hat{e}(P_1,P_1{)}^{s_j-s_{j-1}},j>1$.
     		–	The delegation depth $D{e}_j$ is set and transmitted to the DDSC.

     During the delegation stage, the system signal DSC which concludes the proxy re-encryption process. This procedure can either re-encrypt the $j-1^{\mathrm{th}}$ ciphertext to the $j^{\mathrm{th}}$, or re-encrypt the ciphertext that was originally delivered to the first stage. The $1^{\mathrm{th}}$ delegation's re-encryption procedure is demonstrated as an example in the following. The multi-hop delegation techniques are the same in the actual world; Figure 3 shows how they relate to one another. Re-encrypt $C_0$'s $0^{\mathrm{th}}$ ciphertext to $1^{\mathrm{st}}$ $C_1$'s ciphertext as follows:

     $C_0=(Y_1,Y_2,Y_3,\{B_i,C_i{\}}_{i=1}^l,F)$ and re-encryption key $r{k}_{0⟶1}=\hat{e}(P_1,P_1{)}^{s_1}$, where

     		–	$Y_1=k_{\mathrm{sym}}\cdot \hat{e}(P_1,P_1{)}^s$,
     		–	$Y_2=s\cdot P_1$,
     		–	$Y_3=s\cdot P_2$,
     		–	$\{B_i={\gamma }_i\cdot Z+(-r_i)\cdot H_2(\phi (i))$,
     		–	$C_i=r_i\cdot P_1{\}}_{i=1}^l$,
     		–	$F=H_3(Y_1,Y_2,\{B_i,C_i{\}}_{i=1}^l)$.

     Verify the $0^{\mathrm{th}}$ ciphertext by determining if the ensuing equations are true. (1) $\begin{array}{rl}& \hat{e}(Y_2,P_2)\stackrel{?}{=}\hat{e}(P_1,Y_3)\end{array}$(1) (2) $\begin{array}{rl}& \hat{e}(\sum _{i\in l}\varpi (i)\cdot B_i,P_1)\stackrel{?}{=}\hat{e}(Y_2,Z){\mathrm{\Pi }}_{i\in l}(\hat{e}(-1)\cdot C_i,\varpi (i)\cdot H_2(\phi (i))\end{array}$(2) (3) $\begin{array}{rl}& H_3(Y_1,Y_2,\{B_i,C_i{\}}_{i=1}^l)\stackrel{?}{=}F\end{array}$(3) Unless Equation 1(1) $\begin{array}{rl}& \hat{e}(Y_2,P_2)\stackrel{?}{=}\hat{e}(P_1,Y_3)\end{array}$(1) holds, output ⊥. Otherwise, continue to compute the following: $\begin{array}{rl}{Y}_{1,1}& =Y_1\cdot r{k}_{0⟶1}\\ & =k_{\mathrm{sym}}\cdot \hat{e}(P_1,P_1{)}^{s+s_1},\\ Y_{1,2}& =Y_2,\\ Y_{1,3}& =Y_3,\\ \{B_{1,i}{\}}_{i=1}^l& =\{B_i{\}}_{i=1}^l,\\ \{C_{1,i}{\}}_{i=1}^l& =\{C_i{\}}_{i=1}^l,\\ F_1& =H_3(Y_{1,1},Y_{1,2},\{B_{1,i},C_{1,i}{\}}_{i=1}^l)\end{array}$

3. Data sharing stage. This stage discusses the process of data access using the users, who can be delegator and the delegatee. The phase covers the following algorithms:

   • DecByDelegator. Decryption by the delegator DecByDelegator, the delegator uses their provate key to decrypt the original ciphertext. Parse the original ciphertext $C_0=(Y_1,Y_2,Y_3,\{B_i,C_i{\}}_{i=1}^l,F)$, and the private key $s{k}_s$ (for an attribute set S) as $s{k}_s=(\mathrm{ke}{y}_1,\mathrm{ke}{y}_2,\mathrm{\forall \chi }\in S,L_{\chi })$. Output ⊥ in the event that Equation 1(1) $\begin{array}{rl}& \hat{e}(Y_2,P_2)\stackrel{?}{=}\hat{e}(P_1,Y_3)\end{array}$(1) fails. As an alternative, keep calculating the following:

     		–	Compute $E=$ $\hat{e}(Y_2,\mathrm{ke}{y}_1)/({\mathrm{\Pi }}_{i\in l}(\hat{e}(B_i,\mathrm{ke}{y}_2)\hat{e}(C_i,L_{(}\phi (i)){)}^{\varpi (i)}$, and $k_{\mathrm{sym}}^{\mathrm{\prime }}=Y_1/E$.
     		–	Output $k_{\mathrm{sym}}^{\mathrm{\prime }}$ if $Y_3=H_1(k_{\mathrm{sym}}^{\mathrm{\prime }})\cdot P_2$, and output ⊥ otherwise.

   • DecByDelegatee. Delegatees' decryption DecByDelegatee: The delegatees use the private keys they were given to decrypt the ciphertext after they have the re-encrypted version of the attributes matched to the access policies. This results in the first level ciphertext's $1^{\mathrm{st}}$ description, which is subsequently sent to the multi-hop delegated ciphertext decryption.

     Given the re-encrypted ciphertext $C_1=(Y_{1,1},Y_{1,2},Y_{1,3},\{B_{1,i},C_{1,i}{\}}_{i=1}^l,F_1)$ and the private key $s{k}_1=(\mathrm{ke}{y}_{1,1},\mathrm{ke}{y}_{1,2},\mathrm{\forall \chi }\in S,L_{1\chi })$, and compute the following:

     		–	Compute $E_1=$ $$\begin{gathered} \hat{e}(Y_{1,2},\mathrm{ke}{y}_{1,1})/({\mathrm{\Pi }}_{i\in l}(\hat{e}(B_{1,i},\mathrm{ke}{y}_{1,2}) \\ \cdot \hat{e}(C_{1,i},L_{1,(\phi (i)})){)}^{\varpi (i)} \end{gathered}$$, and $k_{\mathrm{sym}}^{\mathrm{\prime }}=Y_{1,1}/E_1\cdot \hat{e}(P_1,P1{)}^{s_1}$.
     		–	Output $k_{\mathrm{sym}}^{\mathrm{\prime }}$ if $Y_{1,3}=H_1(k_{\mathrm{sym}}^{\mathrm{\prime }})\cdot P_2$, and output ⊥ otherwise.

4. Data storage stage. In this stage, the AR will collect data about patients during their surgery and the data will be encrypted using the encrypted scheme in (Nie et al., 2022). Following that, a transaction containing the ciphertext will be transmitted to the patient's blockchain profile.

   Correctness: $\begin{array}{rl}\hat{e}(Y_2,P_2)& =\hat{e}(s\cdot P_1,P_2)\\ & =\hat{e}(s\cdot P_2,P_1)\\ & =\hat{e}(Y_3,P_1)\\ \hat{e}(\sum _{i\in l}\varpi (i)\cdot B_i,P_1)& =\hat{e}(\sum _{i\in l}\varpi (i)({\gamma }_i\cdot Z-r_i{H}_2(\phi (i))),P_1)\\ & =\hat{e}(s\cdot Z,P_1)\hat{e}(\sum _{i\in l}-\varpi (i)r_i{H}_2(\phi (i)),P_1)\\ & =\hat{e}(s\cdot Z,P_1){\mathrm{\Pi }}_{1\in l}\hat{e}(-\varpi (i)r_i{H}_2(\phi (i)),P_1)\\ & =\hat{e}(s\cdot Z,P_1){\mathrm{\Pi }}_{1\in l}\hat{e}(-C_i,\varpi (i)H_2(\phi (i)))\\ E& =\hat{e}(Y_2,\mathrm{ke}{y}_1)/({\mathrm{\Pi }}_{i\in l}(\hat{e}(B_i,\mathrm{ke}{y}_2)\hat{e}(C_i,L_{\phi }(i)){)}^{\varpi (i)}\\ & =\hat{e}(s\cdot P_1,z\cdot d\cdot P_1+P_1)/({\mathrm{\Pi }}_{i\in l}(\hat{e}(z\cdot {\gamma }_i\cdot P_1\\ & +(-r_i)\cdot H_2(\phi (i)),d\cdot P_1)\cdot \hat{e}(r_i\cdot P_1,d\cdot H_2(\phi (i))){)}^{\varpi (i)}\\ & =\hat{e}(s\cdot P_1,z\cdot d\cdot P_1+P_1)/(\hat{e}(z\cdot d\cdot P_1,P_1{)}^{{\mathrm{\Sigma }}_{i\in l}{\gamma }_i\cdot \varpi (i)}\\ & =\hat{e}(s\cdot P_1,P_1)\\ Y_1/E& =k_{\mathrm{sym}}\cdot (\hat{e}(P_1,P_1{)}^s)/\hat{e}(s\cdot P_1,P1)\\ & =k_{\mathrm{sym}}\\ E_1& =\hat{e}(Y_{1,2},\mathrm{ke}{y}_{1,1})/({\mathrm{\Pi }}_{i\in l}(\hat{e}(B_{1,i},\mathrm{ke}{y}_{1,2})\hat{e}(C_{1,i},L_{1,(\phi (i)})){)}^{\varpi (i)}\\ & =\hat{e}(s\cdot P_1,z\cdot d\cdot P_1+P_1)/({\mathrm{\Pi }}_{i\in l}(\hat{e}(z\cdot {\gamma }_i\cdot P_1\\ & +(-r_i)\cdot H_2(\phi (i)),d\cdot P_1)\cdot \hat{e}(r_i\cdot P_1,d\cdot H_2(\phi (i))){)}^{\varpi (i)}\\ & =\hat{e}(s\cdot P_1,z\cdot d\cdot P_1+P_1)/(\hat{e}(P_1,z\cdot d\cdot P_1{)}^{{\mathrm{\Sigma }}_{i\in l}{\gamma }_i\cdot \varpi (i)}\\ & =\hat{e}(s\cdot P_1,P_1)\\ Y_{1,1}/E_1\cdot \hat{e}(P_1,P_1^{s_1})& =k_{\mathrm{sym}}\cdot (\hat{e}(P_1,P_1{)}^{s+s_1})/\hat{e}(s\cdot P_1,P1)\hat{e}(P_1,P_1{)}^{s_1})\\ & =k_{\mathrm{sym}}\cdot (\hat{e}(P_1,P_1{)}^{s+s_1})/\hat{e}(P_1,P1{)}^{s+s_1}\\ & =k_{\mathrm{sym}}\end{array}$

Figure 3. Multi-hop delegation process.

4.3. Smart contract

Smart contracts are useful in assisting the system to achieve all the requirements. The interface between smart contracts for Ethereum involves the following phases:

• The delegators are required to create the depth of delegation for their delegatees using DDSC. The DDSC then authenticates if all the delegators are qualified before they are permitted to re-delegation. Besides, this is only possible if they achieve all the conditions under delegation depth. A new encryption key is transmitted to DSC and it completes the delegation algorithm of re-encrypting the ciphertext for the delegatee to decrypt. The delegatee requests IPFS to send a file address as the IPFS signals the ASC to verify if the delegatee is authorized to access it.

• The primary functions of the smart contract are to authorize, delegate and verify. A user $Y_{D}e{e}_j$ transfers token to a delegator $Y_{\mathrm{delegato}{r}_j-1}$ or the patient through blockchain in order to get the EMR of the patient. The system performs the authorize function during a transaction. This is achieved when the DDSC examines if the delegation depth level $D{e}_{j-1}$ of the delegator and if it is more than zero. The delegator is permitted to produce a re-encryption key $r{k}_{j-1⟶j}$ for the user's use if they have enough delegation depth. With the use of DDSC, the delegator additionally assigns delegation depth $D{e}_j$ to the delegatee. The delegatee's depth of delegation is stored by DDSC, which also displays the progress to the delegator. The delegation function in the DSC is then generated by $r{k}_{j-1⟶j}$, and it uses the Delegation algorithm to change the ciphertext. The function then undergoes IPFS whereby after the system gets the access request from the user, it performs the verifying function. This helps to determine if the system contains all the records on blockchain if the process takes less than ten minutes to complete. The results are then returned to the IPFS.

For more information regarding security definition and security Proof, it is worth pointing out to Deng et al. (2020), Wang and Zhang (2020), Gao et al. (2022) in order to avoid rewriting the wheel.

5. Security analysis

The security analysis part examines how this protocol accomplishes its anticipated goals as required. Then, comparisons of security properties with other competitive schemes are described.

5.1. Security goals achievements

• The anticipated scheme has the potential to attain data confidentiality and integrity. This is achieved through the use of encryption and signatures. Encryptions in this case entail using both symmetric and attribute-based proxy re-encryption. After the EMRs are encrypted using the symmetric key, they are condensed into the IPFS. It is the delegator that overlooks the access of the key and provides the file address using the CP-ABPRE. Most importantly, it is only the symmetric key and the file location that can facilitate the de-encryption of the original data. The delegator then includes a signature into the algorithm. They are then stored in blockchain Exactly, the security of the $0^{\mathrm{th}}$ ciphertext $C_0$ is determined by the equation $C_0=(Y_1,Y_2,Y_3,\{B_i,C_i{\}}_{i=1}^l,F),\phi (i)$. The symmetric key $k_{\mathrm{sym}}$ is placed in $Y_1=k_{\mathrm{sym}}\cdot \hat{e}(P_1,P_1{)}^s$, and other limits are designed to ensure the safety of the original information. This is evident from the Equation 3(3) $\begin{array}{rl}& H_3(Y_1,Y_2,\{B_i,C_i{\}}_{i=1}^l)\stackrel{?}{=}F\end{array}$(3) , whereby, is a signature. $Y_1,Y_2,\{B_i,C_i{\}}_{i=1}^l$ are controlled by F. The honesty of $Y_3$ is controlled by $Y_2$ as seen in the Equation 2(2) $\begin{array}{rl}& \hat{e}(\sum _{i\in l}\varpi (i)\cdot B_i,P_1)\stackrel{?}{=}\hat{e}(Y_2,Z){\mathrm{\Pi }}_{i\in l}(\hat{e}(-1)\cdot C_i,\varpi (i)\cdot H_2(\phi (i))\end{array}$(2) which guarantees that the access policy are protected and effective. Altering the data in any way results to an invalid equation 1(1) $\begin{array}{rl}& \hat{e}(Y_2,P_2)\stackrel{?}{=}\hat{e}(P_1,Y_3)\end{array}$(1) , which forces the system to continue with the decryption process.

• This proposed scheme can attain collusion resistance. There are possibilities that malicious attackers may collaborate with proxy to get the private information if these existing proxy schemes are used. This is because they are re-encrypted. Thus, this proposed one uses trustworthy blockchain instead of proxy which makes it impossible to conspire with intruders. There are also chances that the intermediate authorized delegatee may conspire with system attackers and get the patient information. This is achieved by ensuring that the ciphertext changes into a strong encryption form that only the authorized user can reach. This is done during the delegation phase. Besides, this system makes it impossible for intruders to decrypt the data even if the delegatee publicizes their access features. Even if the file location and symmetric key $k_{\mathrm{sym}}$ are accessed by attackers, then they will still be unable to reach the information. This is because the system is designed in a way that hinders the smart contract from opening the consent record. Finally, the unchangeable feature of blockchain makes it challenging to trace the evil delegatee.

• Fine-grained access control is achievable with the proposed protocol. Aspects at S of user j are added to the private key $s{k}_j=(\mathrm{ke}{y}_{j,1},\mathrm{ke}{y}_{j,2},\mathrm{\forall \chi }\in S,L_{\mathrm{j\chi }})$ to generate the key. Here, $\mathrm{ke}{y}_{j,1}=z\cdot d\cdot P_1+P_1$, $\mathrm{ke}{y}_{j,2}=d\cdot P_1$, $\mathrm{\forall }\chi \in S$, and $L_{\mathrm{j\chi }}=d\cdot H_2(\chi ))$ are the parameters. The delegator creates access policy in the ciphertext using the attribute-based encryption. In this phase, they can decrypt the ciphertext partly. However, it I only possible if the attribution of the users align with the access policy generated by delegator. This also provides $E_j$. However, the system fails to decrypt the ciphertext if they fail to match the access policy.

• Multi-hop delegation can be achieved with the proposed protocol. Since the patient will control the delegation depth, multi-hop delegation can be achieved. This will be achieved through generating a secret value $s_j$ and passing it to the users. This facilitates the generation of the re-encryption key. The delegator employs DDSC to determine the appropriate delegation depth De for the users. Besides, it also enables the ciphertext to be converted in a way that it will only be decrypted by the patients when in the DSC. They then decrypt it using the private key that they generated and $s_j$. If there is the need to re-delegate, then they will repeat the same process until the depth De gets to zero.

5.2. Comparisons of security properties

Table 1 compares the proposed scheme security properties with those of other schemes (Joshi et al., 2019), Xu et al. (2019), Wang et al. (2021). The results show that each of these protocols meet privacy protection as they share their data or searches. Researchers, Joshi et al. (2019) and Wang et al. (2021) employed the use of CPABE to attain fine-grained access control. Joshi et al. (2019) used a broker to ensure there is access control but they failed to consider the impacts of the broker on the system. As a result, they were unable to attain collusion resistance. Xu et al. (2019) used data search and focused on health testing as they strived to keep the patient information confidential. However, they failed to realized data sharing and multi-hop delegation. They also made their assumption on the surgeon being reliable rather than confirming if it was valid. They failed to develop fine-grained access control, and failed to show what would happen if there was a malicious attack. Despite this, Wang et al. (2021) was able to achieve multi-hop delegation. The only issue was that the system users was to be determined prior by the patients. Thus, is evident that it was not flexible enough. Another issue from the system by Wang et al. (2021) was that they made an assumption that the cloud server was safe and would not be impacted by other users, hence they were unable to prove if the system was resistance to collusion. An analysis of these results from the Table 1 illustrates that the proposed scheme has the capability to address all these issues and achieve the delegation goal.

Table 1. Comparison of security properties.

properties	privacy preservation	fine-grained access control	collusion resistance	multi-hop delegation
Joshi et al. (2019)	√	√	×	×
Xu et al. (2019)	√	×	×	×
Wang et al. (2021)	√	√	×	√
The proposed	√	√	√	√

6. Performance evaluation

6.1. Experimental environment

The section uses Java and the JPBC library to apply the algorithm. Besides, it also employed an Ethereum test platform in Ubuntu to organize the smart contracts. The system outlines the parameter setting and then goes further to present an analysis of the computation and interaction overhead of this anticipated protocol. The final phase is an analysis and designing of the smart contract on the Ethereum test platform. The system security parameter $\eta =128$. It also uses type A combination on the elliptic curve on field $F_p$ for some prime p=3mod4. Besides, cryptographic primitives are implemented using Java and the JPBC library. The description of the computer used was Intel(R) Core i7 with a CPU of @1.90GHz, an 8 GB RAM and a Windows 11 operating system.

The system constructed an Ubuntu test chain from Ganache which was a client version. It was encoded onto smart contracts in a solidity language prior to being keyed in to the blockchain. The structure employed Nodejs Web3js library to enable the smart contract to associate with the blockchain and determining the time it takes to facilitate a transaction. This is due to its inability to directly record the time as it is being published in the smart contracts. All the users are required to create a blockchain account so that they can access EMR and facilitate a transaction to their delegator. First, the conversion signals the DDSC to determine the delegation depth for the specific delegatees and transmits it to the blockchain. The delegator then activates the DCS to transmit the ciphertext after they transit the re0encryption code to it. The delegatees are requires to request the delegators to provide them with the original EMR from the IPFS and triggers the ASC to confirm if they meet the conditions for access.

6.2. Communication overhead

Table 4 describes $\mid G\mid ,\mid G_T\mid$, and $\mid Z_p^{\ast }\mid$. Its size in $Z_p^{\ast }$ is tiny and must be recognized. The findings by Wang and Zhang (2020) help to show the comparison with other related works. $\mid S\mid$ shows the total number of users' attributes, and $\mid L\mid$ shows those found in the attribute structure. Communication overhead is determined during registration, data storage and sharing. The registration step shows how the CC transmits the private key that has been created to all the users. The keys have three parts, $\mathrm{ke}{y}_1,\mathrm{ke}{y}_2,L_{\chi }$. The length of $L_{\chi }$ is based on the attribute $\mid S\mid$. This brings the total length to $(\mid S\mid +2\mid G\mid )$. The delegation phase, determines the cost from the interaction between the delegator and smart contract and it is a result of $r{k}_{j-1⟶j}$, that Its length is $\mid Z_p^{\ast }\mid +\mid G_T\mid$. When the original ciphertext $C_0$ is transmitted, it facilitates the most communication costs, especially when the data are being stored. This adds the total length to $(2\mid L\mid +2)\mid G\mid +\mid G_T\mid$. The computational cost in the data sharing process is based from analysing all the three levels of ciphertext $C_1$,$C_2$,$C_3$ so that to provide performance. Their lengths are constant which makes $(2\mid L\mid +2)\mid G\mid +\mid G_T\mid$. This is compared to Wang and Zhang (2020) and Deng et al. (2020) as shown in Table 3.

Table 2. Proposed protocol communication overhead.

Stages	Registration	delegation	Data storage $C_0$
Wang and Zhang (2020)	$(\mid S\mid +2)\mid G\mid$	$(2\mid L\mid +\mid S\mid +2)\mid G\mid$	$(\mid L\mid +3)\mid G\mid$
Deng et al. (2020)	$(2\mid S\mid +2)\mid G\mid$	$(2\mid S\mid +5)\mid G\mid$	$(3\mid L\mid +2)\mid G\mid +\mid G_T\mid$
The proposed	$(\mid S\mid +2)\mid G\mid$	$\mid Z_p^{\ast }\mid +\mid G_T\mid$	$(2\mid L\mid +2)\mid G\mid +\mid G_T\mid$

Table 3. Communication overhead of $C_1$,$C_2$ and $C_3$ ciphertexts.

Stages	Data sharing $C_1$	Data sharing $C_2$	Data sharing $C_3$
Wang and Zhang (2020)	$(4\mid L\mid +5)\mid G\mid +\mid G_T\mid$	$(6\mid L\mid +7)\mid G\mid +2\mid G_T\mid$	$(8\mid L\mid +9)\mid G\mid +3\mid G_T\mid$
Deng et al. (2020)	$4\mid G\mid +\mid G_T\mid$	–	–
The proposed	$(2\mid L\mid +2)\mid G\mid +\mid G_T\mid$	$(2\mid L\mid +2)\mid G\mid +\mid G_T\mid$	$(2\mid L\mid +2)\mid G\mid +\mid G_T\mid$

Table 4. Experimental parameters.

Parameter	Description
$\mid G\mid$	The bit length of an attribute found in group G
$\mid G_T\mid$	The bit length of an attribute found in group $G_T$
$\mid Z_p^{\ast }\mid$	The bit length of an attribute found in $Z_p^{\ast }$
$\mid S\mid$	The total number of users' attributes.
$\mid L\mid$	The attribute structure.

The communication overhead is compared with Wang and Zhang (2020) and Deng et al. (2020) as shown in Table 2. The benefits can be seen in the delegation and data sharing stages. The re-encryption code size for this projected scheme is $\mid Z_p^{\ast }\mid +\mid G_T\mid$. It is also worth noting that it is only the user, who is the patient that has the control on access strategy due to security purposes. Based on the comparison, the other schemes, Wang and Zhang (2020) and Deng et al. (2020) recreates the access policy after the re-encryption key is created. Moreover, the solution failed to meet the multi-hop delegation. However, Wang and Zhang (2020) protocol can achieve multi-hop delegation. This is because it applies LSSS in all the ciphertext levels. This results to communication overhead. Generally, this overhead that occurs between the delegatee and the delegator stays constant in this proposed scheme.

6.3. Computational cost

The computational cost was determined by simulating the cryptographic algorithms on all stakeholders including the patient, CC, delegator and delegatee. Wang and Zhang (2020) determined the computational cost and is demonstrated in Figure 4 and Figure 6. The results are then recorded by creating various delegation levels and features. The first is the system setup phase whereby the algorithm produces key system features and master keys. The second which is the registration phase provides a dissimilar key for all stakeholders depending on their attributes. The delegator provides ciphertext after an algorithm encrypt in the next phase which is data storage. During the delegation stage which is where the delegator creates a re-encryption code through ReKeyGen. It is the DSC that facilitates the algorithm. This is to provide a ciphertext to be given to the delegatee. The data access phase is where the delegator decrypts the ciphertexts deploys them to the DecByDelegator and DecByDelegatees algorithms. This is also where level 1 and $j^{\mathrm{th}}$ ciphertext are used to explain this computation.

Figure 4. In-depth computational cost at delegatees.

Figure 5. Time consumption of transactions. (a) Transactions cost (b) Gas cost of transaction.

Figure 6. Computational cost comparison. (a) CC computation (b) patients computation (c) delegators computation and(d) delegatees computation.

The computational cost of the delegatee is experienced by DecByDelegatees procedure, and influenced by the depth of delegation. Figure 4 demonstrates the delegation depth which is set from two to twelve and the costs are recorded. Based on the illustration, the computational cost of this proposed scheme remains constant and small despite how many levels of delegation depths are added. This is different from the one demonstrated by Wang and Zhang (2020) whereby the computational growth is expected to increase by about two hundred ms as the delegation depths are added. The findings are different because Wang and Zhang (2020) created a protocol where $j^{\mathrm{th}}$ level ciphertext decrypts. It also decrypts j−1 level ciphertexts one at a time. This is unlike the proposed one where it is expected that the current ciphertext level will be the one that decrypts.

Moreover, the users attributes in a given system also contribute to the computational overhead. Figure 6 demonstrate how the computational overhead of the delegate, patient, CC and delegator change based on the number of attributes. When there are many attributes, the computational cost grows. See Figure 6 (a) to identify how the computational cost is impacts by CC during the registration phase. Further the computational overhead as demonstrated by Wang and Zhang (2020) shows is higher compared to this projected protocol. This is because the current one does not give search keys. Moreover, Wang and Zhang (2020) had a higher and costly computational overhead than the current one due to encrypt algorithm (see Figure 6). This is because (Wang & Zhang, 2020) integrated a random filling mechanism to help in attaining the XOR operation rather than using multiplication. The algorithm encrypt does not facilitate operations with XOR.

The computational cost of ReKeyGen algorithm used by users in the delegation phase as shown in Figure 6 (c), show that the one by Wang and Zhang (2020) is better compared to the proposed one. This is because the one by Wang and Zhang (2020) only resets the policy that grant access and makes the computational overhead similar to the Encrypt. However, the proposed scheme must create a bilinear map which makes the computational overhead to be close to 7 ms. Figure 6 (d)shows the computational overhead needed to decrypt with the algorithm DecByDelegatee. Both of them demonstrate that the computational cost of the delegatees grows based on the attributed. This is due to the fact that they all employ the linear secret sharing scheme. Besides, its timing depends on the attribute. Generally, if the proposed scheme is paralleled to the one by Wang and Zhang (2020), then it is evident that the proposed one needs less computational costs. This is because the original ciphertext is authenticated and stored in the blockchain as the delegation process continues. Moreover, one of the features of blockchain is that it cannot be tampered with hence no need for repeat verification process.

6.4. Smart contracts time cost

The Figure 5 demonstrates that it takes about 90.42 ms for authorize transaction to reach the blockchain. Thus, the transaction cost comes from the implementation of the rekey algorithm in DDSC. To implement a delegation algorithm in the DSC, it requires close to 41.30 ms transaction delegation cost. Verifying a transaction takes close to 40.77 ms and this is due to having to determine if the user is valid and determining the access time. Generally, the total gas cost for all the three is approximately 0.015201, 0.014408, and 0.007101 ethers. The consumption of time and gas are between the allowed range.

7. Conclusions and future work

In this article, a multi-hop permission delegation technique built around blockchain technology with configurable delegation depth is demonstrated in the EMR system. Delegatees with access privileges can assign those rights to additional users to optimize the data value and flexibility of the data sharing network. The method of symmetric encryption is used for uploading the original EMR encrypted to IPFS for distributed storage. A policy for access control is established to limit the delegatee's characteristics and accomplish the required ciphertext transformation, and the symmetric key is encrypted. Blockchain technology ensures data storage and transaction security; on Ethereum, smart contracts faithfully carry out multi-hop delegation monitoring and ciphertext versioning. The computing expenses and communication overhead of the algorithms are compared and experimented with. As part of future research work, federated learning will be integrated to facilitate the Internet of Medical Robotics Things (IoMRT) applications to achieve the machine learning model. The plan is to deploy trustworthy Federated Learning Model for the Internet of Robotic Things.

Disclosure statement

No potential conflict of interest was reported by the author(s).

Additional information

Funding

The author extends his appreciation to the Deputyship for Research & Innovation, Ministry of Education in Saudi Arabia for funding this research work through project number ISP-2024.