A hierarchical access control and sharing model for healthcare data with on-chain-off-chain collaboration

Abstract

Healthcare data is growing rapidly and data sharing is becoming increasingly important among hospitals. However, traditional methods are prone to data leakage and threaten patient privacy. To ensure data security and realize sharing and access control, combining blockchain technology, attribute-based encryption and ciphertext policy (CP-ABE) and AES symmetric encryption algorithm, this paper proposes a hierarchical attribute-based encryption algorithm based on master-sidechain (MSC-CP-ABE) and a collaborative access control and sharing model with on-chain and off-chain (AC-CSS). The algorithm encrypts hierarchically based on data sensitivity, the ciphertext is stored in the interplanetary file system (IPFS), and the encrypted address and key are stored in the side chain, which is convenient for indexing in the main chain. The vectorized access policy implements policy hiding, combines on-chain and off-chain, saves blockchain space, achieves hierarchical access control, and improves security and efficiency. Simulation experiments show that the main sidechain model proposed in this paper has better performance in terms of transaction delay and throughput. Compared with existing models, the algorithm proposed in this paper has certain advantages in data encryption and decryption time and key generation time.

Keywords

Cp-abe master-side chain symmetric encryption access control smart contracts

1 Introduction

As electronic healthcare data [1, 2] becomes more commonplace, hospitals tend to centralize the management of this data in private databases in order to protect the security of patient information and business interests. However, this centralized approach to data management limits the ability to analyze complex diseases and increases the risk of a single point of attack on the system. In addition, this approach restricts patients’ access to their own medical data, making it difficult to provide a complete medical history at the time of referral and potentially compromising treatment outcomes. Insurance companies and research organizations also face difficulties in accessing and using medical data without violating privacy.

Access control [3, 4] is key to protecting medical privacy, but centralized management is prone to systematic failures. Traditional access control that relies on trusted third parties is both expensive and potentially unfair. Designing secure and fair systems is an urgent challenge.

Satoshi Nakamoto’s 2008 white paper on Bitcoin [5] ignited interest in blockchain technology, a decentralized and secure distributed ledger technology [6]. Blockchain has expanded into several domains, including the Internet of Things [7], healthcare [8], smart cities [9], and the metaverse [10]. Ripple Labs [11] introduced the crossledger protocol in 2012, facilitating interconnections between payment systems. In 2014, Blockstream introduced wedge-shaped sidechain technology [12], enhancing the efficiency and security of asset transfers. In conjunction with access control and cross-chain technology, blockchain enables a secure distributed access control system that ensures the safe exchange of data and prevents leakage.

CP-ABE (Ciphertext-Policy Attribute-Based Encryption) [13] is an attribute-based encryption scheme that allows fine-grained attribute-based access control. The data owner sets policies to manage who can decrypt the data. IPFS (Interplanetary File System) [14] is a distributed file system that retrieves files by content ID rather than location, ensuring high availability and content invariance. In order to solve the problems in healthcare data sharing, such as dependence on third parties, storage centralization, inefficiency and privacy issues, a model combining master-sidechain technology and hierarchical attribute-based encryption (MSC-CP-ABE) is proposed, aiming to improve the access efficiency and security of healthcare data sharing. The main research work of this paper is as follows:

1. An on-chain-off-chain collaborative hierarchical access control and sharing model (AC-CSS) for medical data is proposed to address fine-grained access and attribute encryption in medical data sharing

2. In the proposed MSC-CP-ABE algorithm, medical data is graded according to sensitivity, high and medium sensitivity data is encrypted with AES attributes and low sensitivity data is encrypted with direct attributes to achieve graded access control.

3. Combining on-chain and off-chain storage to solve blockchain storage problems, the main sidechain includes one main chain and three sidechains, storing ciphertext addresses and keys according to data sensitivity. Using homomorphic RSA to protect attribute privacy, P-TL smart contract verifies the timeliness and correctness of transactions on the side chains.

2 Related work

2.1 Blockchain related applications

In recent years, blockchain’s tamper-proof nature has led to its widespread use in healthcare data sharing. Combined with artificial intelligence [15], cloud computing [16], and big data [17], blockchain has revolutionized the construction of scalable IT systems and facilitated healthcare data sharing.

Liao et al. [18] developed a blockchain-based medical image segmentation framework that enhances model generalization. Shen [19] proposed a decentralized blockchain federated learning approach to accurately predict traffic flow. Jiang [20] used blockchain to issue e-vouchers to help small and medium-sized enterprises (SMEs) to raise funds, but lacked access control. Bhaskar [26] used blockchain to connect electric vehicles with sensors to ensure secure energy transactions. Literature [21] combines cloud mining and blockchain technology to optimize computing resources. Literature [22] constructed a blockchain-based cloud payment framework.Xiong et al. [23] shifted intensive computation to cloud storage for efficiency, but at the expense of decentralization. Literature [24] designed a privacy protection mechanism, which has the risk of leakage despite improving efficiency. Cheng et al. [25] proposed a cross-chain consensus mechanism, which is low-cost and scalable but difficult to verify datasecurity.

The above mentioned techniques in the literature such as federated learning, cloud computing and cross-chain modeling improve the efficiency of data sharing, but access control and encryption measures have not yet been fully implemented, posing the risk of poisoning attacks, single point of failure and privacy breaches that threaten the security of healthcare data.

Table 1
Symbols in this paper

Symbol Meaning

$𝔾$ , $𝔾_{T}$ The group of multiplicative cycles of order prime p

Z _N Finite field

N ⁺ Positive integers greater than 0

α Security parameters

S User attribute set

${SK}_{\vec{u}}$ User private key

M Medical data in plaintext

δ Access control policy

AA Attribute authorization center

MSK Master key

PK _ak Attribute authorization center public key

PK _global Global public key

u Storage address in IPFS

m Symmetric encryption key

CT Medical data cipher

$\vec{x}$ Vector generated by access policy

$\vec{u}$ Vector generated by attribute set

BPK Public key registered in AA

BSK Private key registered in AA

R (.) RSA encryption algorithm

$𝔾_{0}$ , $𝔾_{1}$ $𝔾_{0}$ , $𝔾_{1}$ element lengths

Symbol	Meaning
$𝔾$ , $𝔾_{T}$	The group of multiplicative cycles of order prime p
Z _N	Finite field
N ⁺	Positive integers greater than 0
α	Security parameters
S	User attribute set
${SK}_{\vec{u}}$	User private key
M	Medical data in plaintext
δ	Access control policy
AA	Attribute authorization center
MSK	Master key
PK _ak	Attribute authorization center public key
PK _global	Global public key
u	Storage address in IPFS
m	Symmetric encryption key
CT	Medical data cipher
$\vec{x}$	Vector generated by access policy
$\vec{u}$	Vector generated by attribute set
BPK	Public key registered in AA
BSK	Private key registered in AA
R (.)	RSA encryption algorithm
$𝔾_{0}$ , $𝔾_{1}$	$𝔾_{0}$ , $𝔾_{1}$ element lengths

2.2 Access control programs

Access control is one of the essential methods of privacy protection, which can avoid the leakage of medical information; in this section, some related work in the area of access control is presented.

Access control is crucial in the field of healthcare big data. Jiang et al. [27] proposed a spectral clustering and risk-based access control model (SC-RBAC) for healthcare big data scenarios, and a risk quantification and usage control-based access control model (RQ-UCON) [28] to enhance the privacy protection of healthcare data, but there is a risk of information leakage. Smart contract is a self-validating and executing transaction protocol [29], and Xie et al. [30] proposed a traceable access control mechanism based on blockchain. Lin et al. [31] proposed a secure mutual recognition authorization system based on blockchain, and Wang et al. [32] proposed a new pairing-less and certificate-less scheme. In recent years, researches have used blockchain to establish attribute-based access control systems, e.g., Li et al. [33] proposed an access control model for IoT, Gao et al. [34] implemented secure access control through blockchain and proposed secure cryptographic policies and attribute-hiding access control schemes based on blockchain. Li [35] et al. proposed a new no-pairing and no-certificates scheme and a new pairing and certificate-free scheme based on smart contract and homomorphic cryptosystem pairless and certificate-less schemes to realize the dynamic permission change function. He et al. [36] designed a cross-chain electronic medical record system, while an intuitive fuzzy trust access control model was proposed in the literature [37] to realize adaptive dynamic accesscontrol.

Although the adoption of blockchain, attribute encryption, and smart contracts can enhance the security of data sharing, these solutions still face privacy breach risks, low intelligence, and scalability issues. In addition, healthcare data on-chain is subject to storage constraints, which affects storage and sharing efficiency and limits scalability.

3 Prerequisite knowledge

3.1 Bilinear mapping

Definition 1. (Composite Order Bilinear Groups [38]) Let $𝔾$ and $𝔾_{T}$ be two multiplicative cyclic groups of order prime p. Let $\hat{e}$ : $𝔾$ × $𝔾_{T}$ ? $𝔾_{T}$ be a bilinear map satisfying the following properties:

1. Bilinear: $\forall a, b \in 𝔾, \exists u, v \in Z_{N}$ , then $\hat{e} (a^{u}, b^{v}) = \hat{e} {(a, b)}^{uv}$ ,

2. Non-degeneracy: $\exists g \in 𝔾$ , such that $\hat{e} (g, g) \neq 1$ ,

3. Computability: $\forall a, b \in 𝔾$ ,then $\hat{e} (a, b)$ can be computed efficiently.

3.2 RSA cryptosystems with homomorphic encryption properties

The RSA [39] cryptosystem is a public-key cryptosystem with multiplicative homomorphic properties, described as follows.

1. Key generation phase: Choose two unequal prime numbers, p and q, at random and compute n = p × q, φ (n) = (p - 1) × (q - 1)).Choose an integer c such that gcd(φ (n) , c) = 1, 1 < c < φ (n).Compute d such that d ∗ e ≡ 1modφ (n).Get public key k_pub ={ n, c }, private key k_msk ={ n, d }.

2. Encryption phase: First of all, the plaintext is grouped into bit strings so that the corresponding decimal number of each group is less than n, and then DO one encryption for each group m in turn, The sequence formed by the ciphertexts of all packets is the encryption result of the original message, i.e., m satisfies 0 ≤ m < n, The encrypted ciphertext CT_R is: CT_R = R (m) ≡ m^c (mod n),Where 0 ≤ CT_R < n.

3. Decryption phase: for CT_R, the decryption algorithm is: m = D (CT_R) ≡ CT_R^d (mod n). In fact,R (m) is homomorphic in terms of multiplication, i.e. $\begin{matrix} R (m_{1}) \times R (m_{2}) & = ({m_{1}}^{c} (\mod n)) \times {(m_{2}}^{c} (\mod n)) \\ = {m_{1}}^{c} \times {m_{2}}^{c} (\mod n) \\ = R (m_{1} \times m_{2}) \end{matrix}$ (1)

4 AC-CSS model design

This section describes the AC-CSS architecture, interaction flow, healthcare data sharing construction, master-side blockchain interaction and P-TL smart contract.

4.1 AC-CSS system model

As shown in Fig. 1, the AC-CSS model proposed in this paper consists of five entities: attribute authorization center, data owner, data user, star file system, and master side chain.

Fig. 1

CP-ABE Access Control Tree Structure.

1. Attribute Authorities (AA). AA is responsible for managing user attributes and generating user attribute keys.

2. Data Owner (DO). DO uses MSC-CP-ABE algorithm to encrypt medical data with AES hierarchical encryption and then uploads it to IPFS with defined access control policy. To improve efficiency, DO sends the encrypted file address and symmetric key to the side chain through the storage transaction Tb_sto.

3. Data User (DU). DUs provide services to healthcare workers and others by obtaining encrypted data addresses and keys, then retrieving and decrypting them from IPFS. DUs broadcast privacy-preserving proof-of-access broadcasts using the RSA system for blockchain authentication. The P-TL contract is responsible for the authentication process. After successful authentication, DUs that meet policy and timing requirements can access the ciphertext. Malicious DUs cannot decrypt because they do not meet policy requirements.

4. Interplanetary File System (IPFS). Stores all encrypted data of DO, realizes distributed storage of ciphertext data, reduces blockchain storage overhead, and facilitates DO storage and DU access.

5. Master-side chain (MSC). The system consists of a main chain that indexes the side chains, and a side chain that establishes a P-TL contract depository to verify the Proof, storing the indexes and symmetric keys of ciphertexts of different sensitivity levels. It verifies access rights, obtains resource addresses, completes on-chain authentication, and handles transactions and communications between Tb_sto and Tb_acc, enabling DUs to obtain ciphertext addresses and keys.

4.2 Overview of the AC-CSS model transaction process

In Fig. 2, the AC-CSS model transaction flow is divided into four phases: initialization phase, the ciphertext storage phase, the on-chain phase, and the access phase.

Fig. 2

AC-CSS transaction flow.

Initialization phase: In this phase, DO and DU send registration requests and attributes to AA, which responds to DO keys PK, MSK, BSK_DO, BPK_DO, responds to DU keys PK, BSK_DU, BPK_DU, and initializes the bilinear mapping group and RSA system parameters.

Ciphertext storage phase: At this stage, DO generates access policies based on the attribute sets, encrypts the data using the MSC-CP-ABE algorithm, and stores it in IPFS. IPFS returns the address u to DO to ensure that the data is stored securely.

On-chain phase: In this phase, DO creates a stored transaction Tb_sto with cipher address and hiding policy to send to the MSC. DU matches the local policy $\vec{x}$ with the set of attributes $\vec{u}$ and generates a Proof, which is submitted to the MSC mainchain and broadcasted to the sidechain nodes to trigger validation. p- The TL smart contract verifies the timeliness of the Proof on the sidechain. The TL smart contract verifies the Proof timeliness on the sidechain. After validation, DO sends key and access transaction Tb_acc to MSC to record access history for tracking and accountability.

Access Phase: After consensus is reached, the DU obtains the ${SK}_{\vec{u}}$ key, which is stored locally by the DO and distributed to the DU only through a secure channel to which the MSC does not have access.The DU uses the ciphertext address, the symmetric decryption key, and the ${SK}_{\vec{u}}$ key to obtain and decrypt the medical data.

The Proof is an identifier that ensures that the hidden access policy matches the attribute and is used to validate the access rights. The DU locally matches the policy by checking for $\vec{x} • \vec{u} = 0$ , and if it matches the Proof is generated by the RSA system. This Proof is sent to the MSC node for homomorphic validation $R (\vec{x}) • R (\vec{u}) = R (0)$ to confirm its validity, cryptographically protecting the DU privacy. The specific Proof generation and validation processes are described in Sections 4.4 and 4.5, respectively. In order to cope with the storage limitations of the blockchain, the ciphertext can be stored in IPFS, and the MSC is provided with the address, decryption key, and checksum to ensure the data integrity and enhance the scalability and security of thesystem.

4.3 Construction of medical data-sharing programs

Medical data are categorized into high, medium and low levels according to the Medical Data Security Guidelines. High sensitivity data such as name and phone number have a high impact after leakage; medium sensitivity such as age and region still have medical value after blurring; and low sensitivity is other medical data. In this paper, access control classifies data based on user identity, specialty and trust level.

Definition 2. The user’s identity level is: $\begin{matrix} {Level}_{id} = {{level}_{id}^{1}, \dots, {level}_{id}^{n} ∣ n \in N^{+}} \end{matrix}$ (2) Where ${level}_{id}^{1} \leq {level}_{id}^{2} \leq \dots \leq {level}_{id}^{n}$ .

Definition 3. The user’s professional rank is: $\begin{matrix} {Level}_{pr} = {{level}_{pr}^{1}, \dots, {level}_{pr}^{n} ∣ n \in N^{+}} \end{matrix}$ (3) Where ${level}_{pr}^{1} \leq {level}_{pr}^{2} \leq \dots \leq {level}_{pr}^{n}$ .

Definition 4. The user’s trust level is: $\begin{matrix} {Level}_{ts} = {{level}_{ts}^{1}, \dots, {level}_{ts}^{n} ∣ n \in N^{+}} \end{matrix}$ (4) Where ${level}_{ts}^{1} \leq {level}_{ts}^{2} \leq \dots \leq {level}_{ts}^{n}$ .

The article defines three levels of identity, specialty, and trust levels, i.e., n = 3, with the high level encompassing the low level of access. As an example, high, medium and low sensitive data M_High, M_Medium, M_Low are identified with corresponding encryption policy attributes:

The low-sensitive access policy for:

$\begin{matrix} δ = “ {level}_{id}^{1} {level}_{id}^{2} {level}_{id}^{3} 1 of 3^{″} \end{matrix}$ (5)

All the identity levels of ${level}_{id}^{1}, {level}_{id}^{2}$ ,and ${level}_{id}^{3}$ can access the low-sensitive data, as shown in Fig. 3(a).

Fig. 3

Schematic diagram of access control tree transformation.

The medium-sensitive access policy for:

$\begin{matrix} δ & = “ ({level}_{id}^{1} {level}_{id}^{2} {level}_{id}^{3} 1 of 3 \\ and {level}_{pr}^{1} {level}_{pr}^{2} {level}_{pr}^{3} 1 of 3) 2 of 2^{″} \end{matrix}$ (6)

That is to say, all the people with identity levels ${level}_{id}^{1}, {level}_{id}^{2}$ and ${level}_{id}^{3}$ and specialty levels ${level}_{pr}^{1}, {level}_{pr}^{2}$ , and ${level}_{pr}^{3}$ can access it, as in Fig. 3(b).

The highly-sensitive access policy for: $\begin{matrix} δ & = “ ({level}_{id}^{1} {level}_{id}^{2} {level}_{id}^{3} 1 of 3 \\ and {level}_{pr}^{1} {level}_{pr}^{2} {level}_{pr}^{3} 1 of 3) \\ 2 of 2 ({level}_{ts}^{1} {level}_{ts}^{2} {level}_{ts}^{3} 1 of 3) 2 of 2)^{″} \end{matrix}$ (7)

That is to say, only the personnel whose identity level is ${level}_{id}^{1}, {level}_{id}^{2}, {level}_{id}^{3}$ , professional level is ${level}_{pr}^{1}, {level}_{pr}^{2}, {level}_{pr}^{3}$ , and trust level is ${level}_{ts}^{1}, {level}_{ts}^{2}, {level}_{ts}^{3}$ are allowed to access it, as shown in Fig. 3(c). In practice, the access policy for low-sensitive data is often influenced by the high-sensitive data policy. Therefore, in this paper, we merge the access control trees of the three, taking the low-sensitive data tree as the left child node of the left child node of the root node, the medium-sensitive data policy as the right child node of the left child node, and the high-sensitive policy as the right child node. This merging strategy reduces the leaf nodes by about 50% and reduces the computational overhead. The MSC-CP-ABE algorithm combines symmetric encryption and CP-ABE to symmetrically encrypt and then attribute encrypt the medium- and high-sensitive data, and directly attribute encrypt the low-sensitive data to realize the hierarchical access control and shorten the encryption and decryption time.

The MSC-CP-ABE access control algorithm consists of four phases: initialization phase, encrypted storage phase, on-chain phase, and decryption phase, which includes four algorithms: Setup, Enc, KeyGen, and Dec.

1. System initialization phase: Input the security parameter α. DO performs the following initialization algorithm.

Setup (α) → (PK, MSK): Choose a bilinear group $𝔾$ with order prime p and generating element g. Define the bilinear map $\hat{e} : 𝔾 \times 𝔾 \to 𝔾_{T} .$

Generate global public key: PK_global = (G, g).

The attribute authorization center randomly selects β, γ ∈ Z_N to generate the master key and public key: MSK = (g^β, γ), ${PK}_{ak} = (h = g^{γ}, {\hat{e} (g, g)}^{β})$ .

Finally, the public key of the system is obtained as: $\begin{matrix} PK = (𝔾, g, h = g^{γ}, \hat{e} (g, g)^{β}) \end{matrix}$ (8)

2. Ciphertext storage phase: At this stage, the Enc algorithm is used to encrypt and store the data. Since M_Low is low-sensitivity data, AES symmetric encryption is not performed on M_Low to save AES keys and improve efficiency.The encryption algorithm is as follows:

Enc (PK, M_High, M_Medium, M_Low, δ) → CT: Encrypt the plaintext M_High, M_Medium, M_Low under the access structure δ and output the ciphertext CT. The encryption process is as follows:

Generate access control tree: same as CP-ABE algorithm.

Recursively compute the access control tree: for each node x choose a polynomial q_x,the degree d_x of the polynomial q_x is 1 less than the threshold k_x of that node, i.e., d_x = k_x - 1. Select the random number s_High ∈ Z_n starting from the root node x_High, generate a polynomial for the root node as q_High, set q_High (0) = s_High, generate a polynomial for the left child node of the root nodex_Medium generate polynomial to q_Meduim, set q_Meduim (0) = s_Meduim = q_High (index (x_Medium)), for the left child node of the root node x_Low generate polynomial to q_Low, set q_Low (0) = s_Low = q_Medium (index (x_Low)), for the other nodes x, select the polynomial q_x, such that q_x (0) = q_parent(x) (index (x)), parent (x) is the parent node of node x, and d_x points are randomly selected to define the q_x.

AES symmetric encryption: randomly select $m_{High}, m_{Medium} \in 𝔾_{T}$ , as AES symmetric encryption key to encrypt m_High, m_Medium to get the ciphertext. $\begin{matrix} C & = ({C 1}_{High} = AES . encrypt (m_{High}, M_{High}), \\ {C 1}_{Medium} = AES . encrypt (m_{Medium}, M_{Medium}), \\ {C 1}_{Low} = M_{Low}) \end{matrix}$ (9)

To reduce the storage overhead of the blockchain, the ciphertext C is stored in IPFS, and then IPFS returns the ciphertext download link u.

To realize policy hiding embed the access structure δ vectorized representation of $\vec{x}$ into theciphertext.

Compute the ciphertext: Let the set of all leaf nodes in the access structure δ be Y, then the ciphertexts of plaintexts M_High, M_Medium, M_Low under the access structure δ are: $\begin{matrix} CT & = ({\vec{x}, \tilde{C}}_{High} = m_{High} {\hat{e} (g, g)}^{β s_{High}}, \\ C_{High} = h^{s_{High}}, \\ C_{Medium} = m_{Medium} {\hat{e} (g, g)}^{β s_{Medium}}, \\ C_{Medium} = h^{s_{Medium}}, \\ C_{Low} = M_{Low} {\hat{e} (g, g)}^{β s_{Low}}, C_{Low} = h^{s_{Low}} \\ \forall y \in Y : C_{y} = g^{q_{y} (0)}, C_{y}^{'} = H_{1} {(att (y))}^{q_{y} (0)}) \end{matrix}$ (10)

3. Stages on the blockchain: For trusted security access control management, the DO sends the ciphertext address with the access policy to the MSC via a stored transaction, i.e., $\begin{matrix} {Tx}_{sto} = {S, u, m, checkCode, sign} \end{matrix}$ (11)

The storage transaction Tx_sto contains the sign S, the ciphertext address u, the symmetric key m, the integrity check code checkCode and the signature sign. The checkCode is the hash value of the ciphertext C and is used to verify the integrity. The message digest MD is computed by H (S, u, m, checkCode) and sign is the digital signature of MD by the DO private key BSK_DO. Any DU can check the integrity of the ciphertext with checkCode and verify the origin of the transaction with sign.

After the generation of Tx_sto, it is broadcasted to other nodes of MSC to verify the validity of the transaction through signature verification and verify the ciphertext and symmetric decryption key through checkCode. The details are shown in Algorithm 1.

The validity of Tx_sto is verified by comparing the message digest MD′ with the MD obtained by decrypting the signature with BPK_DO. If MD′ = MD, it is considered valid.DO sends ciphertext address u and symmetric key m to MSC to save storage space. To ensure the integrity of the ciphertext, checkCode′ is checked for equality with the checkCode in Tx_sto. After verification, it is packed into blocks for PBFT consensus.

To obtain the key from DO and ensure the privacy of the attributes, DU generates $\vec{u}$ locally based on the attribute set, and then matches it with $\vec{x}$ from MSC, once it satisfies $\vec{x} • \vec{u} = 0$ , then it means that the match is successful and DU will generate a Proof to trigger the smart contract for verification. A special note is needed: $\begin{matrix} Proof = {T, {BPK}_{DU}, u, R (\vec{u}), m, sign} \end{matrix}$ (12)

Where T represents the time of Proof generation, BPK_DU denotes the public key registered by DU in AA, u denotes the ciphertext storage location to be accessed by DU, $R (\vec{u}) = (R (u_{1}), R (u_{2}), \dots, R (u_{n}))$ is the result of encrypting each element of $\vec{u}$ with RSA cryptosystem, m denotes the symmetric key of the data to be accessed, and sign is the digital signature of DU to Proof.

Algorithm 1 Verify-AST()//Validating stored transactions

Input: Tx_sto,BPK_DO

Output: True or False

1: MD′ = H (S, u, m, checkCode)//Calculate the message digest of the transaction

2: MD = Compute_{BPK
_DO} (sign)//Signature verification with BPK_DO public key

3: if MD′ = MD then

4: Obtain the CT according to the u_i

5: checkCode′ = H (CT)// Calculate the message digest of the CT

6: if checkCode′ = checkCode then

7: return True

8: end if

9: end if

10: return False

After verifying the validity of the Proof′s signature, an access transaction can be generated for a DU that satisfies the hidden access policy defined by the DO. In addition, to ensure that any DU with a valid signature proof does have access rights, it broadcasts the proof to other nodes in the MSC and triggers each smart contract to verify whether the DU has access rights. The verification process and its smart contract setup are described in the next section.

After that, DO generates an access transaction for a valid Proof. DO calculates the message summary of the transaction MD = H (A, BPK_DU, u, T_stemp) according to the current time T_stemp, DO verifies the MD with signature sign = Sign_{BSK
_DO} (MD), the smart contract verifies the access and generates the access transaction. $\begin{matrix} {Tx}_{acc} = {A {, T_{stemp}, BPK}_{DU}, u, sign} \end{matrix}$ (13)

Where A is used to identify the access transaction, T_stemp denotes the time when the Tx_acc was generated, and sign is used to prove that the Tx_acc was indeed sent by the DO. Note that the publisher of the Tx_acc needs to be the same as the u owner of the data stored in the Tx_acc.

4. Visiting phase: In this phase, the DU authorized by MSC can get the key ${SK}_{\vec{u}}, thekey {SK}_{\vec{u}}$ is generated by the DO running the key generation algorithm KeyGen, and then the DU locally decrypts the algorithm Dec to get the data. Therefore, the access process can be described as follows.

$KeyGen (MSK, S, K) \to {SK}_{\vec{u}}$ :

DO choose random number x ∈ Z_N, compute g^x and send (S, K = g^x) to the attribute authorization center.

The attribute authorization center selects a random r ∈ Z_N, computes D′ = K^(β+r)/γ = g^{x•(β+r)/γ}, and sends D′ to the user. For each attribute j ∈ S pick a randomr_j ∈ Z_N. Then compute the key SK₁ and return SK₁ to the user. $\begin{matrix} {SK}_{1} = (\forall j \in S : D_{j} = g^{r} • {H_{1} (j)}^{r_{j}}, D_{j}^{'} = g^{r_{j}}) \end{matrix}$ (14)

The user calculates D = (D′) ^1/x = g^(β+r)γ: $\begin{matrix} {SK}_{\vec{u}} & = (D = g^{(β + r)} γ, \\ \forall j \in S : D_{j} = g^{r} • {H_{1} (j)}^{r_{j}}, D_{j}^{'} = g^{r_{j}}) \end{matrix}$ (15)

$Dec (PK, CT, S, {SK}_{\vec{u}}) \to M_{i} or #$ : The decryption algorithm takes the public key PK, the ciphertext CT, the attribute set S and the key ${SK}_{\vec{u}}$ as inputs, and if the attribute set S satisfies the access policy δ, i.e., $\vec{x} • \vec{u} = 0$ , then it outputs the message I, otherwise, it outputs the termination symbol #. The specific process is as follows:

Recursive computation of access control tree: same as CP-ABE algorithm. The recursive calculation to the left child of the root node left child node get ${\hat{e} (g, g)}^{r • q_{Low} (0)} = {\hat{e} (g, g)}^{{rs}_{Low}}$ ; The recursive calculation to the root node’s left child node get ${\hat{e} (g, g)}^{r • q_{Medium} (0)} = {\hat{e} (g, g)}^{{rs}_{Medium}}$ ; The recursive calculation to the root node to get ${\hat{e} (g, g)}^{r • q_{High} (0)} = {\hat{e} (g, g)}^{{rs}_{High}}$ .

Compute plaintext:

Compute highly-sensitive plaintexts: $\begin{matrix} M_{High} = AES . decrypt (\frac{{\tilde{C}}_{High}}{\frac{\hat{e} (C_{High}, D)}{{\hat{e} (g, g)}^{{rs}_{High}}}}, {C 1}_{Hign}) \\ = AES . decrypt (\frac{m_{High} • {\hat{e} (g, g)}^{β s_{High}}}{\frac{\hat{e} (h^{s_{High}}, g^{\frac{β + r}{γ}})}{{\hat{e} (g, g)}^{{rs}_{High}}}}, {C 1}_{Hign}) \\ = AES . decrypt (m_{High}, {C 1}_{Hign}) = M_{High} \end{matrix}$ (16)

Similarly, compute medium-sensitive plaintexts: $\begin{matrix} M_{Medium} = \\ AES . decrypt (\frac{{\tilde{C}}_{Medium}}{\frac{\hat{e} (C_{Medium}, D)}{{\hat{e} (g, g)}^{{rs}_{Medium}}}}, {C 1}_{Medium}) = \\ AES . decrypt (\frac{m_{Medium} • {\hat{e} (g, g)}^{β s_{Medium}}}{\frac{\hat{e} (h^{s_{Medium}}, g^{\frac{β + r}{γ}})}{{\hat{e} (g, g)}^{{rs}_{Medium}}}}, \\ {C 1}_{Medium}) = AES . decrypt (m_{Medium}, \\ {C 1}_{Medium}) = M_{Medium} \end{matrix}$ (17)

Compute low-sensitive ciphertexts: $\begin{matrix} M_{Low} & = (\frac{{\tilde{C}}_{Low}}{\frac{\hat{e} (C_{Low}, D)}{{\hat{e} (g, g)}^{{rs}_{Low}}}}) \\ = (\frac{M_{Low} • {\hat{e} (g, g)}^{β s_{Low}}}{\frac{\hat{e} (h^{s_{Low}}, g^{\frac{β + r}{γ}})}{{\hat{e} (g, g)}^{{rs}_{Low}}}}) = M_{Low} \end{matrix}$ (18)

4.4 Master-side chain interaction

As shown in Fig. 5, the traditional blockchain single-chain model faces problems such as insufficient storage space, long transaction confirmation time, and reduced efficiency. For this reason, this paper proposes the main side chain blockchain model, which consists of one Ethernet main chain and three Ethernet side chains to enhance storage space and performance. The main chain stores the basic information of the side chains, such as location and name, without privacy. The sidechains, on the other hand, store addresses and symmetric keys for different sensitivity information. P-TL contracts are deployed on the three sidechains. When a main chain node broadcasts the Proof of a DU to a side chain, the Proof is automatically used as an input to the contract, and rules are enforced to verify the DU access rights.

Fig. 4

Master-side chain interaction.

Fig. 5

P-TL smart contract composition.

4.5 P-TL smart contract

The P-TL contract consists of PVC and real-time monitoring; PVC limits the policy lifecycle, ensures that keys are only obtained through Proof during the permitted time, and real-time monitoring blocks malicious behaviors.PVC restricts visitors by categorizing the access time and maintains transaction logs; real-time monitoring maintains both the logs and the violation list. Figure 5 shows the P-TL structure.

Definition 5. For different data, the average access time was derived from the local historical browsing time records: $\begin{matrix} \bar{T} = \frac{1}{n} \sum_{i = 1}^{n} t_{i} \end{matrix}$ (19) Low sensitivity data timeout (1+0.5) $\bar{T}$ violation, medium sensitivity data timeout (1+0.3) $\bar{T}$ violation, high sensitivity data timeout (1+0.1) $\bar{T}$ violation.

Definition 6. After DU completes local attribute matching, it submits Proof to the P-TL contract for verification. If Proof is valid and timely, it is transferred to DO; if not, the transaction is canceled. In this study, define the information related to the ciphertext key of DO as ${Cip}_{DO} = \bar{T}, U, M, \vec{x}$ , which contains four aspects of information: access average time, ciphertext address, symmetric key, and hiding strategy $\bar{T} = {{\bar{T}}_{1}, \dots, {\bar{T}}_{i}}, U = {u_{1}, \dots u_{i}}, M = {m_{1}, \dots, m_{i}}, \vec{x} = {x_{1}, \dots x_{n}}$

Proof Verification Contract (PVC): The contract maintains a table of cryptographic key information, which is sent by the DO and stored in the blockchain. By matching Proof and entering Proof, k_pub, Cip_DO, only successful validation allows the DU to obtain the cipher corresponding to the IPFS address, otherwise the transaction is canceled.

ProofVc(): In Algorithm 2, the user submits Proof and $\vec{x}$ to the P-TL contract, inputs the RSA public key k_pub = {n, c} and the ciphertext message <Time, u, m>. First verify $R (\vec{u})$ , then check T, u, m in Proof. Successful validation outputs True to continue the transaction Tx_acc, failure outputs False to terminate the transaction.

Table 2

Example of ciphertext key-related information

Allowed access time	Symmetric key	Hide strategy	Ciphertext address
${\bar{T}}_{1}$	m ₁	${\vec{x}}_{1}$	u _i
${\bar{T}}_{2}$	m ₂	${\vec{x}}_{2}$	u ₂
⋯	⋯	⋯	⋯

Real-time contract monitoring: The log and violation lists are shown in Tables 3 and 4. In order to regulate DU behavior, timeout visits will be recorded in the violation list; the doctor’s full operation will be faithfully recorded in the log list.

Table 3

Example of a log list

Access time	DU Public Key	Ciphertext access address	Symmetric key
T ₁	${BPK}_{DU}^{1}$	u ₁	m ₁
T ₂	${BPK}_{DU}^{2}$	u ₂	m ₂
⋯	⋯	⋯	⋯

Table 4

Example of a log list

Incorrect access time	Violation of DU public key	Ciphertext address for access violation
T ₂	${BPK}_{DU}^{2}$	u ₂
T ₃	${BPK}_{DU}^{3}$	u ₃
⋯	⋯	⋯

Algorithm 2 ProofVc()//Check Proof

Input: Proof, k_pub, Cip_DO//Enter information about the Proof, RSA public key and cipher key.

Output: True or False

1: Input $Proof, k_{pub} = (n, c) < Time, U, M, \vec{x} > \leftarrow {Cip}_{DO}$

2: for 1 ≤ i ≤ n do

3: R (x_i) = mⁱ (mod n)// The RSA cryptosystem encrypts each element

4: end for

5: $\vec{x} = (x_{1}, x_{2}, \dots x_{n}) \leftarrow getinfo ({Cip}_{DO})$ // Hiding strategy for obtaining ciphertexts with DO

6: $R (\vec{x}) = (R (x_{1}), R (x_{2}), \dots, R (x_{n}))$ // Generate encrypted access policies

7: $R (\vec{u}) = (R (u_{1}), R (u_{2}), \dots, R (u_{n})) \leftarrow getinfo (Proof)$ // Obtaining encrypted data in the Proof

8: result = R (u₁) • R (x₁) + R (u₂) • R (x₂) + ⋯ + R (u_n) • R (x_n)// Multiply the encrypted vectors

9: $\bar{T} U, M \leftarrow getinfo ({Cip}_{DO})$ // Getting data information in Cip_DO

10: T, u, m ← getinfo (Proof )// Get partial elements in Proof

11: if result = R (0) then// Verify the result and get the correct access rights

12: if $T < \bar{T}$ then// Verify that the time in Proof exceeds the average access time

13: if u = U and m = M then:

14: return True

15: end if

16: else Determine that the access data is that kind of sensitive information

17: if T< The maximum access time has not been exceeded// Determine whether T exceeds the maximum access time

18: return True

19: end if

20: end if

21: end if

22: return False

RT-Monitor(): Algorithm 3 demonstrates the user access monitoring function, where records include T, BPK_DU, u, m. If permissions are exceeded or timeout is exceeded, the violation is flagged and logged for accountability purposes.

Algorithm 3 RT-Monitor()//Monitor the visitor’s access behavior, generate access logs, when the visitor has a violation, generate a violation record

Input: $Proof, \bar{T}$

Output: Log list table and Violation list table

1: APR ← makeRecord (Proof)// Generate access logs APR

2: APR = T ∥ BPK_DU ∥ u ∥ m //" ∥" denotes the bit connective,A ∥ B denotes AB

3: write APR into Log list table

4: return Log list table

5: T ← getinfo (Proof)// Get Proof generation time

6: $\bar{T} \leftarrow getinfo ({Cip}_{DO})$ // Obtaining the allowed time in the Cip_DO

7: Determine the sensitivity of the data

8: if T>The maximum access time has not been exceeded then

9: mark Proof^∗//∗ Representing a signal of violation

10: VIPR ← makeVIRecode (Proof)// Generate a record of violations VIPR

11: VIPR = T ∥ BPK_DU ∥ u

12: write VIPR into Violation list table

13: return Violation list table

14: end if

15: return Log list table and Violation list table

5 Security analysis

This section analyzes the security of our system and the security of the MSC-CP-ABE algorithm.

5.1 System security

The system proposed in this paper ensures that healthcare data is secure at every stage of the lifecycle, data encryption, storage, sharing, and access.

1. Data encryption: In this paper, different encryption methods are used according to the sensitivity, high and medium sensitivity data are combined with AES and attribute encryption, and key generation is done collaboratively by the authorization center and the users to avoid unilateral errors affecting the security of keys and ciphertexts.

2. Data storage: IPFS solves the problem of data leakage and corruption that can occur in local storage due to hardware errors. Some of the data is stored with symmetric encryption, so that even if IPFS is attacked, the exposed medical data can only provide low sensitivity information, while the high and medium sensitivity data remains secure and the low sensitivity information has no impact on patients.

3. Data sharing: The medical data sharing method proposed in this paper combines on-chain and off-chain processing. On-chain, the validity of Proof is verified by P-TL smart contract, and the data related to the ciphertext contains only the key address and the policy hidden vector, which makes it difficult to satisfy the access policy even if it is stolen; off-chain, the DU obtains the ciphertext address from the IPFS and then completes two decryptions within the DU to obtain the plaintext, which does not involve any other entities and ensures that the data sharing is secure.

4. Data access: MSC-CP-ABE algorithm is adopted to access medical data to realize hierarchical access control. On-chain users do not participate in data access, and off-chain users obtain ciphertext from IPFS, effectively resisting illegal attacks and ensuring data security.

In conclusion, this paper has verified the security of the system and recognizes that data security can be ensured at all stages including data encryption, storage, sharing, and access.

5.2 MSC-CP-ABE algorithm security

Betancourt et al. [13] ensured the security of CP-ABE under the DBDH assumption. The security of AES symmetric encryption standard adopted by the US federal government is recognized. In this paper, the CP-ABE based MSC-CP-ABE algorithm incorporates AES to provide layered encryption for data of different sensitivities with no lesser security than CP-ABE and AES, the proof of which is given below.

Definition 7. The CP-ABE algorithm and the AES symmetric encryption algorithm are secure.

Theorem 1. The MSC-CP-ABE algorithm proposed in this paper is not less secure than the CP-ABE algorithm and AES symmetric encryption algorithm.

Proof. Comparing the CP-ABE algorithm:

1. Setup: The public key PK of MSC-CP-ABE and CP-ABE is the same; the master key MSK is kept by the attribute authorization center, which does not reduce the security.

2. Enc: In MSC-CP-ABE, AES symmetric keys are used to encrypt high, medium and low sensitivity data, while CP-ABE encrypts plaintext directly. The encryption of m_High, m_Medium and the encryption of M_Low are the same as that of CP-ABE, which uses the access structure δ. To hide the strategy, the ciphertext contains the vectorization strategy $\vec{x}$ , which enhances the security of the Enc algorithm.

3. KenGen: The key SK₁ in MSC-CP-ABE is generated as in CP-ABE, D = g^(β+r)γ is based on discrete logarithmic difficulty is generated by the authorization center and the user. Users cannot derive the master key g^β, gamma from h = g^γ, D′ = g^x(β+r)/γ, and K = g^x, which ensures that the system security is not compromised.

4.Dec:Compared to CP-ABE, the user in MSC-CP-ABE matches the attributes first. If $\vec{x} \cdot \vec{u} = 0$ , i.e., the set of attributes S satisfies δ, then the high and medium sensitivity plaintexts are obtained by decryption with AES key.The attribute decryption process is the same in CP-ABE.

The MSC-CP-ABE algorithm is at least as secure as CP-ABE at four steps. It is no less secure than AES by encrypting (decrypting) plaintext using AES symmetric keys.The vectorized access policy further enhances the security of MSC-CP-ABE.

Theorem 2. If a user complies with the access policy for low-sensitive data only, he/she will not be able to access medium-sensitive and high-sensitive data.

Proof. The user can recursively get ${\hat{e} (g, g)}^{{rs}_{Low}}$ by the left child x_Low of the left child of the root node. Because the user does not conform to the access policy of the sensitive data, the left child x_Medium of the root node cannot recursively get ${\hat{e} (g, g)}^{{rs}_{Medium}}$ . It does not conform to the access strategy of highly sensitive data, so it cannot recursively get x_High from the root node to get ${\hat{e} (g, g)}^{{rs}_{High}}$ . Moreover, the generated polynomial values of the left and right child nodes are not correlated, and the user cannot infer s_Medium = q_Medium (0) and s_High = q_High (0) from s_Low = q_Low (0), that is, from ${\hat{e} (g, g)}^{{rs}_{Low}}$ to ${\hat{e} (g, g)}^{{rs}_{Medium}}$ and ${\hat{e} (g, g)}^{{rs}_{High}}$ .

6 Performance analysis and simulation experiment analysis

In this section, we will analyze the model functionality, test and analyze the sidechain interaction performance, and compare the performance of the proposed algorithms and systems.

6.1 Functional analysis

Table 5 compares the performance of this paper’s scheme with literature [13 , 41], in terms of hierarchical access control. Literature [13 , 40] only supports a single policy, which increases the computation and storage cost; literature [35] does not realize flexible hierarchical access control; and literature [41] lacks policy hiding, which is a security risk. In contrast, this paper realizes the fusion of blockchain and access proof, while providing hierarchical access control and policy hidingfunctions.

Table 5
Function Comparison

Literature source Hierarchical access control Proof of access Policy hiding Blockchain technology

Literature [13] ✗ ✗ ✗ ✗

Literature [35] ✗ ✓ ✓ ✓

Literature [40] ✗ ✗ ✗ ✗

Literature [41] ✓ ✗ ✗ ✗

This paper ✓ ✓ ✓ ✓

Literature source	Hierarchical access control	Proof of access	Policy hiding	Blockchain technology
Literature [13]	✗	✗	✗	✗
Literature [35]	✗	✓	✓	✓
Literature [40]	✗	✗	✗	✗
Literature [41]	✓	✗	✗	✗
This paper	✓	✓	✓	✓

6.2 Algorithm performance analysis

In this paper, the proposed MSC-CP-ABE access control algorithm is compared with the literature [13 , 41]. Literature [13] provides the basic CP-ABE algorithm, literature [35] proposes the OHP-CP-ABE optimization scheme, while literature [41] introduces the CP-ABE encryption scheme with multiple authorization centers. Table 6 shows the results of comparing the ciphertext lengths for high, medium and low sensitivity data.

Table 6
Comparison of storage overhead

Literature Source Ciphertext Length System public key length User key length

Literature [13] $(6 t + 3) 𝔾_{0} + 3 𝔾_{1}$ $2 𝔾_{0} + 𝔾_{1}$ $(2 k + 1) 𝔾_{0}$

Literature [35] $(6 t + 3) 𝔾_{0} + 3 𝔾_{1}$ $2 𝔾_{0} + 𝔾_{1}$ $(2 k + 1) 𝔾_{0}$

Literature [41] $(6 t + 3) 𝔾_{0} + 3 𝔾_{1}$ $4 𝔾_{0} + 𝔾_{1}$ $(4 k + 1) 𝔾_{0}$

This paper $(3 t + 3) 𝔾_{0} + 3 𝔾_{1}$ $2 𝔾_{0} + 𝔾_{1}$ $(2 k + 1) 𝔾_{0}$

Literature Source	Ciphertext Length	System public key length	User key length
Literature [13]	$(6 t + 3) 𝔾_{0} + 3 𝔾_{1}$	$2 𝔾_{0} + 𝔾_{1}$	$(2 k + 1) 𝔾_{0}$
Literature [35]	$(6 t + 3) 𝔾_{0} + 3 𝔾_{1}$	$2 𝔾_{0} + 𝔾_{1}$	$(2 k + 1) 𝔾_{0}$
Literature [41]	$(6 t + 3) 𝔾_{0} + 3 𝔾_{1}$	$4 𝔾_{0} + 𝔾_{1}$	$(4 k + 1) 𝔾_{0}$
This paper	$(3 t + 3) 𝔾_{0} + 3 𝔾_{1}$	$2 𝔾_{0} + 𝔾_{1}$	$(2 k + 1) 𝔾_{0}$

Literature [13] and [35] do not support multi-level access control, which leads to an increase in the length of ciphertexts with different sensitivities that need to be stored separately; literature [41] makes the system public key and user key larger due to the multi-attribute authorization center. In contrast, this paper adopts single-attribute authorization center to maintain the stability of public key and key length, and is the shortest in ciphertext length, system public key and user key.

6.3 Simulation experiment

The experimental data comes from the cooperative unit - Kunming City, a tertiary-level A hospital and a county people’s hospital in Yunnan Province, which contains a total of 1,200G of text, image, and imaging data, involving 1,360 data tables and 2,139,373 records. Doctor access logs are used in the experiment to simulate doctor access behavior.

The experiments were performed using the Java implementation of the JPBC library on a machine configured with the Ubuntu Server 20.04.5 LTS operating system, Intel(R) Core(TM) i5-10400F CPU, and 16GB RAM. All concurrent tests were performed on Hyperledger Fabric 2.3.1, a federated blockchain with a PBFT consensus mechanism. The article analyzes the main sidechain performance, examines the key generation and encryption/decryption times for different attribute algorithms, and evaluates them with comparative experiments.

6.3.1 Master-side chain performance testing and analysis

This paper uses JMeter to test the performance of Inquire and Transaction transactions, as well as the sidechain performance of a healthcare data sharing system. Inquire is used for data querying, while Transaction is used for data transactions. The latter involves multiple nodes and requires more nodes to participate in the transaction sequencing and packing, thus resulting in a lower throughput than Inquire for the same level of concurrency of the system. Inquire is used for data querying and Transaction is used for data transactions. its latency is higher than Inquire and its throughput is lower.

As shown in Figs. 6 and 7.The Inquire and Transaction transactions were tested in concurrency experiments with 100-500 and 50-250 runs, respectively; the Inquire transaction had a maximum average latency of 2.9s and a maximum throughput of 215 transactions per second; the Transaction transaction had a maximum average latency of 8.1s and a maximum throughput of 120 transactions per second. As shown in Fig. 8. Sidechaining meets acceptable standards in concurrency experiments (50-450 times) with a maximum average latency of 0.8s and a maximum throughput of 276 transactions per second.

Fig. 6

Latency and throughput of Inquire transactions

Fig. 7

Latency and throughput of Transaction transactions.

Fig. 8

Transaction latency and throughput of side chains.

6.3.2 Analysis of numerical experiments

Comparing the literature [13] and [41], the effect of the number of attributes on the key generation and encryption/decryption time is analyzed, and the number of attributes included in the selected access policy are 2, 4, 6, 8, 10, 12, 14, 16. The experiments show that with the increase of the user attributes, the key generation and encryption/decryption time grows as shown in Fig. 9. The key generation time of this paper’s scheme is between the two literatures, and the decryption time of this paper’s scheme is the shortest for a large number of attributes, which makes this algorithm more preferable considering that the data is often encrypted once and decrypted many times.

Fig. 9

Effect of number of attributes on key generation time.

Fig. 10

Effect of number of attributes on encryption and decryption time.

7 Summary and perspective

To solve the problem of medical data sharing, this paper proposes an access control model AC-CSS based on hierarchical attribute encryption in the main sidechain, combining CP-ABE and AES algorithms to realize multilevel access control MSC-CP-ABE.Fine-grained access control and policy hiding are realized by ciphertext policy hiding and sensitivity classification. The RSA homomorphic encryption is utilized to protect user attribute privacy, and the P-TL smart contract is validated in the side-chain verification Proof. experiments verify the feasibility and security of the model. Nevertheless, there are problems such as long key generation time, difficulty in request identification under high concurrency, and single point of failure that may be triggered by third-party generation of master key, which will be the focus of future research.

Footnotes

Acknowledgements

This work was supported by the National Natural Science Foundation of China (No. 72471206, 71972165, 61763048, 72164037), Key Projects of Basic Research for Science and Technology Foundation of Yunnan Province (No. 202001AS070031), the Central Government’s Special Program for Guiding Local Science and Technology Development (No. 202307AB110009), Science and Technology Foundation of Yunnan Province Education Department (No. 2023J0657).

References

Ting

X.U.

and Guangjun

Y.U.

, A study on the current status of open sharing of domestic healthcare data, China Digital Medicine 15(09) (2020), pp. 64-66+103 (In Chinese).

Jingjin

, et al., A study on the current status of healthcare data sharing in the maternal and child specialty alliance in the Yangtze River Delta region, China Digital Medicine 18(02) (2023), pp. 93–98 (In Chinese).

Sandhu

R.S.

and Samarati

, Access control: principle and practice, IEEE Communications Magazine 32(9) (1994), pp. 40–48.

Noh

, Firdaus

and Rhee

K.H.

, Commentary: Integrated blockchain-deep learning approach for analyzing the electronic health records recommender system, Frontiers in Public Health (2023), 11.

Nakamoto

, Bitcoin: A Peer-to-Peer Electronic Cash System. 2008.

, The blockchain: State-of-the-art and research challenges. Journal of Industrial Information Integration 15 (2019), pp. 80–90.

Thang

P.C.

, et al., Multimedia Privacy, Security, and Protection within the Blockchain: A Review. in 2022 5th International Conference on Contemporary Computing and Informatics (IC3I) 2022

Xie

, et al., Applications of Blockchain in the Medical Field: Narrative Review, Journal of Medical Internet Research 23(10), 2021.

Liu

, Fan

H.Y.

and Qi

J.Y.

, Blockchain Technology, Cryptocurrency: Entropy-Based Perspective, Entropy 24(4), 2022.

10.

Mozumder

M.A.I.

, et al., Metaverse for Digital Anti-Aging Healthcare: An Overview of Potential Use Cases Based on Artificial Intelligence, Blockchain, IoT Technologies, Its Challenges, and Future Directions. Applied Sciences-Basel 13(8), 2023.

11.

Hope-Bailie

and Thomas

, Interledger: Creating a Standard for Payments, Proceedings of the 25th International Conference Companion on World Wide web, 2016.

12.

Back

S.A.

, et al., Enabling Blockchain Innovations with Pegged. 2014.

13.

Bethencourt

, Sahai

and Waters

, Ciphertext-Policy Attribute-Based Encryption. in 2007 IEEE Symposium on Security and Privacy (SP ’07) 2007.

14.

Chen

Y.L.

, et al., An improved P2P File System Scheme based on IPFS and Blockchain. in IEEE International Conference on Big Data (IEEE Big Data) 2017. Boston, MA.

15.

Fang

and Lei

, Blockchain for Edge AI Computing: A Survey, Journal of Applied Sciences 38(1) (2020), pp. 1–21.

16.

Gai

K.K.

, et al., Blockchain Meets Cloud Computing: A Survey, IEEE Communications Surveys and Tutorials 22(3) (2020), pp. 2009–2030.

17.

Deepa

, et al., A survey on blockchain for big data: Approaches, opportunities, and future directions, Future Generation Computer Systems-the International Journal of Escience 131 (2022), pp. 209–226.

18.

Liao

X.R.

, et al., A Blockchain Enabled Federal Domain Generalization Based Architecture for Dependable Medical Image Segmentation. in 6th IEEE Advanced Information Technology, Electronic and Automation Control Conference (IEEE IAEAC). 2022. Beijing, PEOPLES R CHINA.

19.

Shen

C.Z.

, et al., A Blockchain Based Federal Learning Method for Urban Rail Passenger Flow Prediction. in 23^rd IEEE International Conference on Smart Transportation Systems (ITSC). 2020. Electr Network.

20.

Jiang

, et al., A trust transitivity model of small and mediumsized manufacturing enterprises under blockchain-based supply chain finance, International Journal of Production Economics 247 (2022), pp. 108469.

21.

Qiu

, et al., Cloud Computing Assisted Blockchain-Enabled Internet of Things, IEEE Transactions on Cloud Computing 10(1) (2022), pp. 247–257.

22.

Zhang

Y.H.

, et al., Outsourcing Service Fair Payment Based on Blockchain and Its Applications in Cloud Computing, IEEE Transactions on Services Computing 14(4) (2021), pp. 1152–1166.

23.

Xiong

Z.H.

, et al., Cloud/Fog Computing Resource Management and Pricing for Blockchain Networks, IEEE Internet of Things Journal 6(3) (2019), pp. 4585–4600.

24.

Chen

, et al., Blockchain for Health IoT: A privacypreserving data sharing system, Software: Practice and Experience 52 (2022), pp. 2026–2044.

25.

Cheng

J.R.

, et al., PoEC: A Cross-Blockchain Consensus Mechanism for Governing Blockchain by Blockchain, Cmc-Computers Materials & Continua 73(1) (2022), pp. 1385–1402.

26.

Bhaskar

K.B.R.

, Prasanth

and Saranya

, An energyefficient blockchain approach for secure communication in IoTenabled electric vehicles, International Journal of Communication Systems (2022), 35.

27.

Jiang

, et al., An access control model for medical big data based on clustering and risk, Information Sciences 621 (2023), pp. 691–707.

28.

Jiang

, et al., Risk and UCON-based access control model for healthcare big data, Journal of Big Data 10(1) (2023), pp. 104.

29.

Delmolino

, et al., Step by step towards creating a safe smart contract, in InternationalWorkshops on Financial Cryptography and Data Security, FC 2016 and 3rd Workshop on Bitcoin and Blockchain Research, BITCOIN 2016, 1st Workshop on Advances in Secure Electronic Voting Schemes, VOTING 2016, and 4th Workshop on Encrypted Computing and Applied Homomorphic Cryptography, WAHC 2016, K. Rohloff, et al., Editors. 2016, Springer, pp. 79–94.

30.

Xie

, et al., Blockchain-based access control mechanism for data traceability, Journal on Communications 41(12), 2020.

31.

Lin

, et al., BSeIn: A blockchain-based secure mutual authentication with fine-grained access control system for industry 4.0, Journal of Network and Computer Applications 116 (2018), pp. 42–52.

32.

Wang

W.Z.

, et al., Blockchain-Based Reliable and Efficient Certificateless Signature for IIoT Devices, IEEE Transactions on Industrial Informatics 18(10) (2022), pp. 7059–7067.

33.

Z.Y.

, et al., An IoT-Applicable Access Control Model Under Double-Layer Blockchain, IEEE Transactions on Circuits and Systems Ii-Express Briefs 68(6) (2021), pp. 2102–2106.

34.

Gao

, et al., TrustAccess: A Trustworthy Secure Ciphertext-Policy and Attribute Hiding Access Control Scheme Based on Blockchain, IEEE Transactions on Vehicular Technology 69(6) (2020), pp. 5784–5798.

35.

F.Q.

, et al., EHRChain: A Blockchain-Based EHR System Using Attribute-Based and Homomorhic Cryptosystem, IEEE Transactions on Services Computing 15(5) (2022), pp. 2755–2765.

36.

Quanquan

, et al., Security Sharing Scheme of medical data based on cross-chain, Computer System Application 32(05) (2023) ,pp. 97-104 (In Chinese).

37.

Jiang

, et al., An electronic medical record access control model based on intuitionistic fuzzy trust, Information Sciences 658 (2024), pp. 120054.

38.

Lewko

and Waters

, Decentralizing Attribute-Based Encryption. in Advances in Cryptology EUROCRYPT 2011. 2011. Berlin, Heidelberg: Springer Heidelberg.

39.

Ç.K. Koç, Montgomery Arithmetic, in Encyclopedia of Cryptography and Security, H.C.A. van Tilborg and S. Jajodia, Editors. 2011, Springer US: Boston, MA. pp. 799–803.

40.

Wang

, et al., An Efficient File Hierarchy Attribute-Based Encryption Scheme in Cloud Computing, IEEE Transactions on Information Forensics and Security 11(6) (2016), pp. 1265–1277.

41.

Hur

, Improving Security and Efficiency in Attribute-Based Data Sharing, IEEE Transactions on Knowledge and Data Engineering 25(10) (2013), pp. 2271–2282.

A hierarchical access control and sharing model for healthcare data with on-chain-off-chain collaboration

Abstract

Keywords

1 Introduction

2 Related work

2.1 Blockchain related applications

3 Prerequisite knowledge

3.1 Bilinear mapping

3.2 RSA cryptosystems with homomorphic encryption properties

4.1 AC-CSS system model

5.1 System security

5.2 MSC-CP-ABE algorithm security

6 Performance analysis and simulation experiment analysis

6.1 Functional analysis

Table 5 Function Comparison Literature source Hierarchical access control Proof of access Policy hiding Blockchain technology Literature [13] ✗ ✗ ✗ ✗ Literature [35] ✗ ✓ ✓ ✓ Literature [40] ✗ ✗ ✗ ✗ Literature [41] ✓ ✗ ✗ ✗ This paper ✓ ✓ ✓ ✓

6.3.1 Master-side chain performance testing and analysis

Footnotes

Acknowledgements

References

Table 5
Function Comparison

Literature source Hierarchical access control Proof of access Policy hiding Blockchain technology

Literature [13] ✗ ✗ ✗ ✗

Literature [35] ✗ ✓ ✓ ✓

Literature [40] ✗ ✗ ✗ ✗

Literature [41] ✓ ✗ ✗ ✗

This paper ✓ ✓ ✓ ✓