1 Introduction

Under the background of big data, the medical career is continuously developing, paper medical record files no longer adapt to the current digital era, electronic medical record file information construction and improvement is the trend, and electronic medical data can make the storage of data more and more convenient. Medical data refers to the data generated by doctors during the treatment of patients, including basic patient data, incoming and outgoing data, electronic medical records, diagnosis and treatment data, medical imaging data, medical management, economic data, etc. To a certain extent, it also involves personal privacy information [1,2,3]. Currently, the storage of such private information in hospitals is mainly concentrated in HIS (Hospital Information System) system, which can provide healthcare professionals with practical tools to communicate patient information to relevant parties securely and reliably, and also develops identification and authentication schemes to guarantee the identity of all parties involved [4]. During the patient’s treatment process, physicians need to frequently view and use the patient’s relevant medical data through HIS system to reliably analyze the patient’s condition and ultimately conclude the most correct treatment plan. However, before a physician can obtain access to a patient’s medical data, the doctor needs to send an access request to HIS system indicating the purpose of access, and only physicians whose true identities are verified, and granted access rights can successfully obtain the intended resources, and how to improve the access efficiency of physicians in this process has been an urgent problem.

The emergence of the Bitcoin [5] system has led to the importance of blockchain technology. Blockchain allows for the elimination of intermediary third parties, promotes public trust, and transactions can be refined and verified at a granular level. Diversity and desirability allow it to be used almost anywhere, with rich and uncontrolled discussions covering almost all aspects of commerce, industry, finance, and governance [6]. Currently, blockchain technology has been applied in many fields, such as Internet of Things [7], healthcare [8], smart cities [9], government regulation [10], and asset management [11]. Blockchain is a distributed shared ledger technology that is transparent, tamper-proof, traceable, and decentralized. However, directly storing patients’ medical data in the blockchain master chain will result in an extremely large size of data on the master chain. In addition, the open and transparent nature of blockchain makes it extremely easy to leak patients’ medical data information, which will cause great harm to society and individuals. As shown in Table 1, some of the medical information privacy leaks and their impacts in the past 5 years. See the appendix for details.

Table 1 Some medical information privacy breaches in the last 5 years
Full size table

Access control, as one of the cornerstone technologies for privacy protection, can well prevent the leakage of medical information. Therefore, combining blockchain technology and access control technology can not only prevent privacy leakage of medical information to a certain extent, but also realize the problem of distributed storage and anti-tampering of medical information. However, the authentication method in the traditional access control model is too simple, and the execution of the access control policy is overly dependent on trusted third-party organizations, and the efficiency of processing access requests is low. Therefore, in this paper, we propose an access control model based on blockchain main-side chain collaboration (AC-BMS) for dealing with the problems of centralized storage, centralized authorization and improved access efficiency. Compared with existing models, AC-BMS model uses side chains to enhance the storage scalability of blockchain, which is better than the scaling method using replicated blocks; the proposed authentication scheme is also better than the traditional model in terms of security and computational complexity; the access control policy is contextualized to get rid of the third-party restrictions, and the main and side chain structure access control model applicable to HIS systems is designed to meet medical workers The access control model is designed to meet the efficient access needs of medical workers.

The original contribution points for this paper are as follows:

  1. (1)

    In order to cope with the problem that the performance of blockchain cannot meet the hospital HIS system’s low processing efficiency in the face of massive access request transactions in the medical big data environment and the serious data leakage within the hospital, we propose the storage expansion and functions expansion of blockchain based on the collaboration of blockchain main and side chains to make it meet the application requirements of the hospital HIS system, improve the access efficiency of medical workers, and reduce the privacy leakage of medical data caused by internal members of the hospital.

  2. (2)

    To verify the legitimate identity of the doctor, the identity verification scheme is designed in this study, which no longer relies on the third-party certification agency to promulgate the ID book, and divides the identity verification into three stages, and finally completes the identity verification by hashing the doctor’s medical care number and the registration password.

  3. (3)

    The traditional access control model adopts centralized access authorization, which is overly dependent on trusted third-party organizations, and the access control policy is easy to tamper with and has low security. We consider writing access authorization decisions into smart contracts to form Roll-up contracts, restricting access rights to doctors’ access behavior through contract rules, using the access requests sent by doctors as the trigger conditions of Roll-up contracts to automatically execute smart contracts to obtain access authorization rights and corresponding resources stored on the side chain.

The rest of this paper is organized as follows; Sect. 2 shows the current state of research on access control and blockchain, Sect. 3 introduces the AC-BMS model proposed in this study, Sect. 4 shows the experiments and analysis, and Sect. 5 concludes and outlooks this study.

2 Related work

Access control, as one of the key technologies of information security, is the process of granting access to authenticated users to implement access according to the access rights set by the system, which directly affects the security and efficiency of a system [12]. In recent years, many scholars at home and abroad have conducted a lot of research on access control technology. To predict the risk of access behavior and measure the user access trust value, authors in [13] proposed a spectral clustering and risk-based access control model (SC-RBAC) that is more applicable to big data healthcare scenarios, addressing the problem that traditional access control is difficult to apply to application scenarios with frequent changes in authorization and ultra-large data sets with limited resources. In contrast, authors in [14] propose an access control model based on the trustworthiness of the requesting user by building a regression analysis model for existing single-value quantitative access control models based on trust or risk, which cannot reflect the true trust or risk situation. In addition, to protect patients’ information security and prevent privacy leakage, a multi-player evolutionary game model for risky access control and a risky access control model based on fuzzy theory were respectively developed in literature [15] and literature [16], which effectively protects patients’ private privacy. Authors in [17] propose a Kerberos-based centralized authentication authorization (KCAA) scheme for group enterprises that lack support for centralized authorization, which leads to the problem of Kerberos applications failing to achieve cross-domain access control. Authors in [18] investigate the problem of diversity of access control models in system integration and designs a centralized authorization model that supports multiple access controls and centralizes authority authorization for multiple heterogeneous information systems. Authors in [19] propose an integrated access control model integrating generic centralized authorization and distributed authorization, IACM. Authors in [20] introduce a blockchain and FL-based platform that allows intelligent fog/edge nodes to make accurate decisions in a distributed manner. Using centralized cloud servers to support the dynamic computing power required by various immersive applications. Most of these access control solutions use centralized servers to accomplish authorization decisions. The centralized authorization approach is easy to manage but has security issues. To meet the growing number of access requests, a centralized access control mechanism is often used to manage users’ permissions and store access permission information in an authorization database [21]. This approach of storing and managing access rights’ information centrally will have a huge impact in case of tampering with the rights’ information, whereupon authors in [22] pointed out the shortcomings of relying on a centralized solution for authentication and ensuring secure transaction processing in many aspects such as scalability, management, data manipulation, non-persistence of data single point of failure, and vulnerability to cyber-attacks. Although existing approaches can guarantee a high level of data security to some extent, such as stream table sharing [23], and software attack live forensics [24], the common features of these approaches are reflected in the underlying over-centralization, where access control policies and identity attributes are stored in a single database owned by a trusted third party. The centralized storage approach can easily lead to data modification or leakage, and thus a new technique is urgently needed to address this challenge.

Blockchain, also known as distributed ledger technology, known for its important role in shaping the cryptocurrency space such as Bitcoin and Ether, is a transparent, decentralized, tamper-proof, traceable, publicly accessible digital database that provides integrity-protected data storage and can also be better seen as a convergence of several existing technologies: peer-to-peer (P2P) networks, cryptographic hash functions, trusted timestamps, fault-tolerant consensus, and digital signatures [9, 25]. Blockchain allows mutually untrusted entities to exchange financial values and interactions without relying on trusted third parties, while decentralized security and data storage is the purpose of blockchain development [26, 27]. The security issues associated with centralized authorization and centralized storage can be addressed to some extent using blockchain technology. For example, authors in [28] take advantage of the decentralization and transparency of blockchain technology and proposes a blockchain-based digital copyright protection system that uses the Interplanetary File System (IPFS) to store encrypted digital content and complete rights transactions and automatically issue licenses through smart contracts, realizing the licensing without any centralized server This enables the licensing and rights trading functions without any centralized server. Authors in [29] investigate the traditional data storage method with a centralized architecture and points out that this storage method is prone to trust and security issues, and therefore proposes a data access control scheme based on a combination of attribute encryption and blockchain, and combines blockchain technology with distributed storage. However, blockchain also has its performance bottlenecks, the most obvious of which is the very poor scalability of blockchain, so to enhance the scalability of blockchain, new blockchain scaling schemes have been proposed by the industry. Authors in [30] surveyed the existing blockchain solutions and found that the existing solutions are deficient in terms of communication and storage scalability as well as decentralization, and thus proposed LightChain, the first blockchain architecture that operates on a distributed hash table (DHT) of participating nodes, where each block and transaction is replicated in the DHT at the peering point and retrieved on demand. To extend Filecoin, the Proof-of-Replication (PoRep) proof system was designed in [31], which a server can use to prove to the network in a publicly verifiable way that it is using a unique resource to store one or more copies of a data file. In [32], a novel storage engine, BFT-Store, is proposed to improve storage scalability by integrating erosion encoding and Byzantine Fault Tolerance (BFT) consensus protocols, using a hybrid replication scheme to improve read performance. These solutions can replicate over blocks but lack sufficient storage scalability. Authors in [33] provide the first comprehensive study of state-of-the-art DHT-based architectures in edge and fog computing systems from an infrastructure and application perspective, noting that DHT-based solutions can enhance the storage scalability and efficiency of edge and fog computing infrastructures. However, few industry players have enhanced blockchain scalability by introducing side chain technology. The most essential purpose of the side chain is to speed up the scaling, which can provide specific functional expansion and performance improvement for functions that are currently not possible in the main chain. Side chains are linked to the parent chain by bi-directional anchoring, a method that enables assets to be swapped between the parent and side chains at predetermined rates [34]. Therefore, using side chain extensions to enhance the storage scalability of the blockchain is a better choice.

Blockchain technology and access control technology have been combined in the healthcare field, authors in [35] proposed a private blockchain based on a hospital healthcare data sharing and protection scheme to improve the electronic health system of the hospital that can store or access patients’ historical data while satisfying privacy protection. The centralized storage problem in the hospital cloud storage model is pointed out in [36], and blockchain technology is introduced to propose a decentralized storage system that combines the Interstellar File System, the Ethereum blockchain, and the ABE (Attribute Based Encryption) technology framework for access control model. Authors in [37] test the Bell-LaPadula model on a blockchain-based healthcare network to implement the dynamic access control function of smart contracts on blockchain networks to cope with the vulnerability to interference, privacy, and data security issues faced by current access control mechanisms. In contrast, for traditional access control policy protocols, which usually rely on trusted third-party storage, access control policy protocols are also not automatically enforced and usually rely on the assistance of third-party organizations, such as the EUROMED-ETS model mentioned in the literature [38], which is based on a trusted third-party architecture in which the public key certificates of participating hospitals and healthcare practitioners are stored in certificate authority.

Although the above-mentioned literature has solved the problems of centralized authorization and centralized storage in access control to a certain extent, the access control policy protocol has not been implemented automatically and still relies on the assistance of third-party organizations, and the storage method has been changed to off-chain storage. In practice, the access control method of HIS system not only has the problems of centralized authorization and centralized storage but also when receiving a large number of different types of access applications at the same time, the concurrently initiated access applications cannot be processed in time, which may cause HIS system’s access response to be slow and the quality of doctor-patient services to be degraded. Therefore, HIS system also requires high throughput and very short response time to improve access efficiency and fast transaction processing, whereupon authors in [39] considered the volume of transactions generated by blockchain-based audit trail applications and the throughput limitations of existing blockchains for recording a single ledger that is not only inefficient but also costly and proposed a scalable and efficient blockchain solution for audit applications, Block Trail. Divides the traditional blockchain system into multiple co-dependent layers, thus reducing time and space complexity and increasing throughput. On the other hand, authors in [40] propose a performance-optimized blockchain framework based on Deep Reinforcement Learning (DRL, Deep Reinforcement Learning) that meets the high throughput requirements of industrial IoT systems. However, in the healthcare big data environment, access control requires the blockchain to authenticate each access request. Although the blockchain structure is optimized accordingly when the number of nodes is high, even the most efficient authentication mechanism can significantly slow down access due to a large number of nodes.

3 AC-BMS model design

In this section, we first describe the basic architecture of the AC-BMS model in this paper and then elaborate on the model from three aspects: the main side chain collaboration aggregation structure, authentication, and Roll-up contracts.

3.1 AC-BMS model basic framework

The model in this paper combines blockchain technology and access control technology. It uses blockchain decentralization, tamper-proof and other characteristics to create a secure and trustworthy access environment and authenticate visitors, which guarantees the security and reliability of the information in the access process. As Fig. 1 shows the basic architecture of the model in this paper.

Fig. 1
figure 1

AC-BMS model basic architecture

Full size image

As shown in the figure, when doctors want to access the resources they need, they need to send an identity verification request to the hospital information system (HIS system for short) first, and HIS system completes the verification and feeds back the verification result according to the verification rules, and only doctors who pass the verification can send access applications to HIS system. Then, the information in the medical information access node on the main chain of Ethereum is used to find the side chain corresponding to the stored resources and obtain the resources. The information in the medical information access node includes the address information of the side chain corresponding to the resource. In addition, before obtaining the resources from the side chain, Roll-up contract is set up to verify the access rights and obtain the address information of the resource storage according to the contract rules.

3.2 Main side chain collaborative aggregation structure

The traditional blockchain single-chain model tends to package and store transactions within blocks on the chain, and with the increase of transactions, the performance of the main blockchain chain has been seriously affected, such as transaction throughput, transaction confirmation time, etc. Moreover, due to the open and transparent nature of the blockchain, private information similar to patient medical data type simply cannot be stored on a large scale on the main chain, while the side chain can be regarded as an independent chain or system, which can better provide services for patients and physicians. As in Fig. 2, the main and side chain collaborative aggregation structure, this study designs a main and multi-side blockchain aggregation structure, one Ethereum main chain and six side chains, the basic information of the side chains are stored within the blocks on the Ethereum main chain, and such information is publicly available, in this study the main chain blocks store the basic information of personal information chain, medical history information chain, hospitalization information chain, drug history information chain, examination information chain and medical insurance information chain. Each of the six side chains stores one type of information about patients, such as personal information of patients stored in the personal information chain, and Roll-up contracts are deployed on each of the six side chains. As the input condition of the contract, the contract rules will be automatically executed to verify and permit the doctor to access the target resource.

Fig. 2
figure 2

Main side chain collaborative aggregation structure

Full size image

3.3 Authentication

Traditional access control is divided into authentication and authorization, and identity authentication, as an important part of the authentication link, can well confirm the real identity of users and guarantee the security of access. In response to the problem of medical information leakage, but the actual investigation of the cause of the leakage or the leaker, we propose an authentication scheme for identity verification, compared with the traditional authentication scheme, the proposed authentication scheme in this paper can resist more types of attacks, please see the security analysis in Sect. 5 for details. The authentication scheme is divided into 3 phases: registration phase, pre-calculation phase, and authentication phase. We will describe each phase in detail below. The symbolic information used in this scheme is shown in Table 2.

Table 2 Definition of symbols
Full size table

3.3.1 Registration phase

First, HIS system server selects two prime numbers \(p\) and \(q\), where the value of \(p\) is greater than \(q\), such that satisfies \(p = 2q + 1\). Then HIS system server chooses its server password \(x\) (\(x \in Z\)) and the one-way hash function \(h\left( \cdot \right)\), which is a hash function that works in one direction and the hash value can be easily computed based on the pre-mapped values. Where the server password \(x\) must be protected by HIS system server. When a doctor registers a new legitimate user, he/she must submit the medical number \(ID\) and the doctor login password \(Pw\) to HIS system server in advance. \(\left( {ID,Pw} \right)\) will be used to verify the legitimacy of the doctor’s registration information. The steps in the registration phase are as follows.

Step 1: The doctor selects ID and Pw, and then submits a registration request \(R\) to HIS system server via a secure channel at \(R = \left( {ID,Pw} \right)\). The secure channel [41] allows network dissemination in an encrypted form to secure the data and can establish mutual trust by verifying identity.

Step 2: Upon receipt R, HIS system server verifies the legitimacy of the doctor’s registration information and calculates the verification code B, which is shown in Eq. (1).

$${\text{B}} = \left[ {h\left( {ID} \right)^{x} } \right]^{{Pw}{^{ - 1} }} \bmod p$$
(1)

Step 3: HIS system server stores ID, B and h (·) in the smart card.

3.3.2 Pre-calculation phase

In order to complete the authentication phase successfully, some exponential module operations need to be calculated in advance and used to solve the problem of high computational cost, so a precomputation phase is designed. In this phase, the computation of certain values that require expensive and time-consuming exponential operations is done in advance and stored in HIS system. When these values are needed, they can be easily and quickly extracted from HIS system, thus improving performance and efficiency. The precomputation phase proceeds as follows.

Step 1: The doctor randomly selects several values, \(r_{1i}\), where \(i = 1,2,3, \cdot \cdot \cdot ,c\), c is a positive integer, the size of c is determined by the storage capacity of HIS system. All values of \(r_{1i}\) are then sent to HIS system server via a secure channel.

Step 2: HIS system server uses the calculated values of B and the received \(r_{1i}\) (where \(i = 1,2,3, \cdot \cdot \cdot ,c\), c is a positive integer) to calculate each of the correspondings of \(B_{{r_{1i} }}\) and \(W_{{r_{1i} }}\), and then stores \(\left( {B_{{r_{1i} }} ,W_{{r_{1i} }} } \right)\) in the smart card. The calculation formula is as follows.

$$B_{{r_{1i} }} = B^{{r_{1i} }} = \left[ {h(ID)^{{x \cdot r_{1i} }} } \right]^{{Pw^{ - 1} }} \bmod p$$
(2)
$$W_{{r_{1i} }} = h\left( {ID} \right)^{{r_{1i} }} \bmod p$$
(3)

where \(B_{{r_{1i} }}\) represents the corresponding of \(r_{1i}\) verification code and \(W_{{r_{1i} }}\) is the corresponding of \(r_{1i}\) registration code.

Step 3: Once all of the \(\left( {B_{{r_{1i} }} ,W_{{r_{1i} }} } \right)\) stored in the smart card have been used, the doctor needs to repeat Steps 1 to 2 to generate a new set, which is then overwritten with the previous set.

Figure 3 summarizes the registration and pre-calculation phases, illustrating that HIS system server completes all operations and saves all data to the smart card, which is used to store the server authentication information and achieve two-way authentication between the user and the server.

Fig. 3
figure 3

Registration phase and pre-calculation phase

Full size image

3.3.3 Authentication phase

The authentication phase is the core phase of the whole identity verification, through which the real identity of the doctor can be effectively verified. In addition, after the above two stages, the basic data used in the process of the authentication stage has been saved in the smart card, which facilitates the smooth operation of the authentication stage. Figure 4 shows a summary of the authentication phase.

Fig. 4
figure 4

Authentication phase

Full size image

When a doctor wants to log into HIS system, he/she must first import his/her ID and Pw. The next authentication steps will be as follows.

Step 1: HIS system takes a set of \(\left( {B_{{r_{1i} }} ,W_{{r_{1i} }} } \right)\), where \(i = 1,2,3, \cdot \cdot \cdot ,c\), c is a positive integer, that has been pre-calculated and stored in the smart card. The doctor then uses the password Pw to calculate \(B_{{^{Pw} }}\) and \(R_{1}\), and sends the doctor’s \(ID\), \(R_{1}\) and \(W_{{r_{1i} }}\) to HIS system server. The formula for calculating \(B_{{^{Pw} }}\) and \(R_{1}\) are as follows.

$$B_{Pw} = B_{{r_{1i} }}^{Pw} = h\left( {ID} \right)^{{x \cdot r_{1i} }} \bmod p$$
(4)
$$R_{1} = h\left( {W_{{r_{1i} }} ||B_{Pw} ||ID} \right)$$
(5)

where the symbol “ || “ is the bit concatenation operator. For example, \(a||b\) will become \(ab\). \(B_{{^{Pw} }}\) is the authentication value calculated with the doctor login password.

Step 2: When HIS system server receives the message from the doctor, it will use the server password \(x\) to calculate \(B_{x}\).

$$B_{x} = W_{{r_{1i} }}^{x} \bmod p$$
(6)

Then use \(B_{x}\) to check if is equal to \(R_{1}\) and \(h\left( {W_{{r_{1i} }} ||B_{x} ||ID} \right)\) in step 1. If the result of the calculation is not equal to the value of \(R_{1}\), HIS system server rejects the request. Next, HIS system server generates a random number \(r_{2}\), and uses Eq. (7) to calculate the session key \(sk\), uses \(sk\) to calculate the hash value \(h_{1}\), and sends \(h_{1}\) and \(r_{2}\) to the doctor. The formula for calculating the hash value \(h_{1}\) is as follows.

$$sk = h\left( {B_{x} ||r_{2} } \right)$$
(7)
$$h_{1} = h\left( {sk||r_{2} } \right)$$
(8)

Step 3: When the doctor receives \(h_{1}\) and \(r_{2}\), the doctor uses \(B_{{r_{1i} }}\) and \(r_{2}\) to calculate \(sk^{\prime}\), and then the doctor checks whether the value of \(h_{1}\) in step 2 is equal to \(h\left( {sk^{\prime}||r_{2} } \right)\). If the result of the calculation is not equal to \(h_{1}\), the doctor rejects the message from HIS system server. In addition, the doctor will calculate the hash value \(h_{2}\) and send it to HIS system server. The calculation formula is as follows.

$$sk^{\prime} = h\left( {B_{{r_{1i} }} ||r_{2} } \right)$$
(9)
$$h_{2} = h\left( {ID||sk^{\prime}} \right)$$
(10)

Step 4: HIS system server will calculate whether the values of \(h\left( {ID||sk} \right)\) and \(h_{2}\) are equal. If they are equal, HIS system server will authenticate the doctor and grant him/her access to the system.

3.4 Roll-up contract design

Roll-up contract consists of three parts: an access control policy contract, a resource finding contract, and a real-time monitoring contract. The access control policy contract is mainly used to re-check the visitor’s identity and the division of the visitor’s access rights, the resource finding contract facilitates the visitor to get the requested resources, and the real-time monitoring contract can monitor and record the access process. The access control contract maintains a list of users. The resource lookup contract maintains a resource information table. The real-time monitoring contract maintains both a log list and a violation list. Figure 5 shows the composition of Roll-up contract.

Fig. 5
figure 5

Roll-up contract design

Full size image

3.4.1 Access control policy contract

When the doctor successfully passes the authentication, he/she can log into HIS system and then send the access request. In this paper, the study defines the user’s access request as \(R_{user} = \left\{ {user,p,s,t,{\text{Permission}}} \right\}\), which contains information about five aspects: user, treatment object, resource type, access time, and operation privilege, and the complete definition is as follows.

$$user = \left\{ {user_{1} ,user_{2} ,user_{3} , \ldots ,user_{n} } \right\}$$
(11)
$$p = \left\{ {p_{1} ,p_{2} ,p_{3} , \ldots ,p_{n} } \right\}$$
(12)
$$s = \left\{ {\begin{array}{*{20}l} {PersonalInfo,edical\, Records,\, Inpatient\, Info,} \\ {Drug\, History\, Info,\, Check\, Info,\, Medical\, Insurance\, Info} \\ \end{array} } \right\}$$
(13)
$$Permission = \left\{ {add, \, delete, \, modify, \, query} \right\}$$
(14)

user: represents the access request user, which is assumed to be \(Doctor_{1} ,Doctor_{2} ,Doctor{}_{3}, \ldots ,Doctor_{n}\) in this study. p: represents the patients treated, assumed in this study to be \(p_{1} ,p_{2} ,p_{3} , \ldots ,p_{n}\); \(s\): represents the patient’s medical resources, including six types of medical resources: personal information, medical history information, hospitalization information, drug history information, examination information, and medical insurance information. t: represents the current access time of the user. Permission: represents the operation privileges that users can perform, including adding, deleting, modifying, and checking.

The access control policy contract maintains a list of users, as shown in Table 3. The contents of the table give restrictions on the scope of access and operation rights of doctors, and only doctors who meet the limited conditions can be allowed to access the corresponding patient information.

Table 3 Example of the user list
Full size table

CheckPolicy(): As shown in Algorithm 1, the validity verification of user’s \(R_{user}\) and access rights granting functions are demonstrated and described. After a user passes authentication and initiates an access request to HIS system, the access control policy contract first needs to check the validity of the user-initiated access request \(R_{user}\), which should include at least the meta information of User, Patient, Resource type, Time, etc., and then retrieve the user list maintained by the contract, judge the correctness of the information content in \(R_{user}\), and then the user list maintained by the contract is retrieved, the correctness of the information in \(R_{user}\) is judged, and the user is granted the corresponding operation privileges, and the validity of the current access time is checked.

figure i

3.4.2 Resource finding contract

The resource lookup contract maintains a resource information table, as shown in Table 4, which records the location of all patient resource information stored on the side chain and allows the execution of this contract to quickly obtain the required patient information.

Table 4 Example of resource information representation
Full size table

FindPolicy(): As shown in Algorithm 2, the function to obtain the storage address of a target resource by an authorized user is demonstrated and described. The resource lookup contract obtains the patient set, {Patient}, and the resource set, {Source type}, by fetching the resource information list, which is used to check whether the input parameters p, s belong to {Patient}, {Source type}, and then obtains the addressID of s from the resource information list, while checking the execution result of the access control policy contract, and only authorized users can obtain the addressID of the corresponding resource, and the patient information required by the user can be obtained very quickly through the addressID.

figure j

3.4.3 Real-time monitoring contract

The real-time monitoring contract maintains a log list and a violation list, as shown in Tables 5 and 6. To regulate the doctor’s behavior, when the doctor exceeds the access rights, his/her behavior will be recorded in the violation list, and all of the doctor’s operation records from the time he/she gains access until the end of the access will be faithfully recorded in the log list.

Table 5 Example of a log list
Full size table
Table 6 Example of violation list
Full size table

MonitorPolicy(): As shown in Algorithm 3, the monitoring of user access operations is demonstrated and described. The contract forms access logs based on the user’s access requests, and the complete access logs include information such as user, p, s, permission, and Time, and are recorded in the access log list. If the user’s operation authority exceeds the limit in the user list, or the current access time is overdue, the user is marked as a violation user, and the violation record is formed based on the user’s access request, which includes user, Time, permission, s, etc. The violation record is written to the violation list, which can be used as powerful evidence for accountability afterward.

figure k

4 Experiment and analysis

In this section, we need to evaluate the performance and security of the model, focusing on the changes in the system in terms of scalability and access efficiency, security, and privacy after the introduction of authentication, blockchain side chain technology, and access control policy contracts.

4.1 Data sources

The data used for the experiments in this paper are obtained from a tertiary hospital in Kunming and a county people’s hospital in Yunnan Province, the collaborators of the authors’ project team. With 1200 GB of their medical data, there are 1360 tables and 2,139,373 records in the database. In this experiment, 2000 medical data resources in the database were extracted for simulation experiments.

4.2 Experimental environment

All experiments were conducted on a server equipped with a 2.30 GHz 64-bit, Intel(R) Core(TM) i5-6300HQ processor, 4 cores, 8 GB RAM, and operating system version Ubuntu Server 20.04.4 LTS. All simulated concurrent access tests were executed in Hyperledger Fabric 2.2.1, a federated blockchain with a PBFT consensus mechanism. Table 7 shows the base configuration of the server and blockchain.

Table 7 Basic setup
Full size table

4.3 Performance test and analysis

In this section, we need to evaluate the performance of the model, focusing on the changes in system scalability, access efficiency, and side chain performance after the introduction of authentication, blockchain side chain technology, and access control mechanisms.

4.3.1 Extensibility analysis

To highlight the superiority of the proposed scheme in this study, we compare and analyze AC-BMS model proposed in this paper with the scalability schemes proposed in the literature [30], literature [31], and literature [32], and the results of the comparative analysis are shown in Table 8. From the table, it can be seen that the side chaining is more suitable than the replicated block scaling approach in terms of the degree of storage scalability. Enhancing the storage scalability of blockchain by side chain scaling approach can make the blockchain-based access control model better than the existing solutions in terms of efficiency, security, throughput, and cost. Therefore, the scaling approach by creating multiple side chains is more effective.

Table 8 Scalability comparison analysis
Full size table

4.3.2 Access efficiency test and analysis

To verify the access efficiency advantage of the AC-BMS model proposed in this study under the condition of the high number of concurrent accesses, we compare the access control model proposed in this paper with the access control model proposed by Riabi [42] et al. Riabi et al. propose an IoT access control method based on fog computing and distributed hash tables (DHT) that approach is also applicable to smart healthcare. We conducted concurrent access tests using benchmark, a java client concurrency test program that simulates webbench and contains two important parameters, number of concurrences, and access time. In the experiment, we prepared a set of concurrent access experiments with 100, 200, 300, 400, and 500 trials to test the two models, and recorded the average access time of the two models when completing 100, 200, 300, 400, and 500 accesses, respectively. The experimental results are shown in Fig. 6.

Fig. 6
figure 6

Average access time consumption for completing access requests for different access control models

Full size image

Figure 6 shows that both the Riabi model and our proposed AC-BMS model show an increasing trend in access time as the number of visits increases, which is in line with the normal access rule: the larger the number of visits, the longer it takes to complete the visit. When the number of visits is 100, the Riabi model takes slightly less time than our model, but after the number of visits exceeds 100, the effect of our model gradually improves and the time taken is lower than that of the Riabi model. After 300 visits, our model is already much lower than the Riabi model in terms of visit time. Finally, the average access time of our model is calculated to be 2–3 s less than that of the Riabi model. This is because, in our proposed access control model, an identity precipitation phase is designed. In this phase, the computation of certain values that require expensive and time-consuming exponential operations is done in advance and stored in HIS system. When these values are needed, they can be easily and quickly extracted from HIS system. In addition, access control decisions are executed through smart contracts, and access rights are assigned on time by the developed contract rules for automation. The experimental results show that the access control model in this paper can improve access efficiency more effectively in a huge access count environment.

4.3.3 Side chain performance testing and analysis

To test the performance of the side chain, we focus on two aspects: transaction throughput and transaction latency. Throughput is the number of transactions processed by the system per unit of time, while latency refers to the time taken to perform a consensus round within the partition. The traditional blockchain-based access control model deploys the access control policy and smart contracts to be executed on the main chain, as in the literature [28, 37]. In contrast, in this study, we write the access control policy into a smart contract and deploy it on the Polygon side chain. To test the side-chain latency, we conduct a comparative experiment using the Ethereum test chain and the Polygon side-chain in the model of this paper. We selected 500 hospital medical staff, assuming that each medical staff performs only one access to HIS system, and the total number of accesses performed is 500. We let these 500 people access the Ethereum test chain and Polygon side chain respectively, and recorded the waiting time of each medical staff after the last medical staff finished accessing. Figure 7 shows the variation curves of the latency time of completing accesses on the Ethernet test chain and Polygon side chain with different numbers of concurrent accesses. The experimental results simulated on the Polygon side chain tend to be stable and remain around 0.4 s, and the change in access latency time is small even when the number of accesses increases. Therefore, the experimental results show that the Polygon side chain used in this model can effectively reduce the access latency to a certain extent and maintain a smooth level.

Fig. 7
figure 7

Comparison of the latency of completing accesses on the Ether test chain and Polygon side chain for different numbers of concurrent accesses

Full size image

After testing the Polygon side chain latency, we will test the throughput. The number of access requests processed by the model per unit of time is used in this study to measure the throughput of the Polygon side chain. We simulated 50 physicians sending 50, 150, 250, 350, 450, and 550 access requests to HIS system by using Docker containers and counted the number of access requests handled by the model for the different numbers of accesses to the access resource requests and access privilege verification requests. Figure 8 shows the number of access requests that the model responds to access resource requests and access privilege verification requests, and it can be seen that the average number of requests processed by the Polygon side chain for access resource requests and access privilege verification requests under different access counts is maintained at 288–296tx/s, which represents the stable throughput of Polygon side chain proposed in this study, and the throughput is maintained at 288–296tx/s. With reliable stability. Moreover, as the number of requests for access rights verification increases, the number of processed requests also increases, and more doctors will be able to obtain access rights and complete the visits successfully.

Fig. 8
figure 8

Number of access requests in the AC-BMS model in response to requests for access resources and requests for access rights verification

Full size image

4.4 System security analysis

Security and privacy are key indicators of access control performance. The authentication scheme proposed in this paper creates a secure access environment by strictly verifying the real identity of doctors and storing all medical data of patients using side chains. The following will demonstrate the security of our proposed access control model by combining several possible attack principles in the actual operation process.

4.4.1 Replay attack test analysis

Replay attack is an attacker who sends a packet that has already been received by the destination host to deceive the system, and is mainly used in the authentication process to undermine the correctness of the authentication. In the authentication scheme proposed in this paper, the add random number method is used, and adding random numbers is one of the common methods to deal with replay attacks. We use a test case to demonstrate that such attacks are not feasible in the model proposed in this paper. Suppose two doctors, Alice and Bob, and Bob is the perpetrator of the replay attack. Alice successfully registers and authenticates her identity according to the legitimate steps, while Bob improperly obtains Alice’s ID, \(R_{1}\) and \(W_{{r_{1i} }}\) in the first step of the authentication phase, Bob intends to use this information to carry out the replay attack, but since Bob does not know the random number \(r_{1i}\), he will not be able to pass in the next session of verifying whether \(h_{1}\) and \(h\left( {sk^{\prime}||r_{2} } \right)\) are equal, and after HIS system checks the random numbers, it will soon be able to determine Bob’s replay attack. Note: The ID, \(R_{1}\) and \(W_{{r_{1i} }}\) obtained by Bob are only the final calculated values, and the values of \(r_{1i}\) are almost impossible to be inferred from the values of \(W_{{r_{1i} }}\), so the replay attack can be effectively resisted by the authentication scheme of this model.

4.4.2 Password guessing attack test analysis

Password guessing attacks, where a malicious user tries to complete a login by guessing the end user’s password. Hackers typically analyze keywords used in the organization as well as those used by competitors and string together a set of commonly used keywords that may be used by employees to set passwords to access the company’s network. Instead of trying multiple passwords for a single user, hackers usually try the same set of passwords for multiple users until they finally get a correct one. And password guessing attack is not feasible in the authentication model proposed in this paper. The password \(Pw\) guessed by the malicious user is used in the first step of the authentication phase to calculate \(B_{{^{Pw} }}\) and \(R_{1}\), and \(R_{1}\) will be sent to HIS server for verification. In the case of blind guessing, the probability of actually guessing the correct password \(Pw\) is very low; even if it is correct, without knowing the other parameters (\(x\) and \(r_{1i}\)), HIS server will be able to detect that a user is trying to log in illegally once the \(R_{1}\) calculated and actual values are not equal.

4.4.3 Brute force cracking attack test analysis

Brute force cracking is a password attack executed by hackers using a large number of common or compromised passwords in a high-intensity attempt to access the network, actively guessing the passwords of legitimate user accounts by brute force. In simple terms, the passwords generated during a brute force attack are roughly the same, the only difference being that the greater the number and variety of characters, the slower the overall process. Similar to password guessing attacks, brute-force attacks rely on brute force to actively guess the passwords of legitimate user accounts. In this model, the guessed password \(Pw\) is used in the first step of the authentication phase to calculate \(B_{{^{Pw} }}\) and \(R_{1}\), and \(R_{1}\) will be sent to HIS server for verification. Even if the correct password \(Pw\) is obtained by brute force, without knowing the other parameters (\(x\) and \(r_{1i}\)), it is almost impossible for the calculated value of \(R_{1}\) to be equal to the actual value, and the user will not be able to pass the authentication by HIS server, thus confirming that the brute force password cracking attack is not possible in this model.

4.4.4 Disguise attack test analysis

Disguise attack is an attempt to log in to the system by a malicious user disguised as a legitimate user. In our model, the password and related parameters are protected by discrete logarithms (\(B_{Pw} = B_{{r_{1i} }}^{Pw} = h\left( {ID} \right)^{{x \cdot r_{1i} }} \bmod p\)), which greatly increases the complexity and difficulty of the computation and provides the message authentication code \(B_{{r_{1i} }}\) to calculate authentication code \(B_{Pw}\), which guarantees the correctness of the data source. A malicious user cannot correctly interpret the authentication message without knowing the password and associated parameters. Therefore, it is ineffective to launch an attack on this model using disguise attack, and malicious users attempting to log in to the system disguised as legitimate users will be disabled.

4.4.5 Checksum loss attack test analysis

Checksum value loss attack is an attack in which an internal member can steal or modify the password or user authentication table stored in the server database. In our proposed authentication scheme, smart cards are introduced, while the server is only involved in the computation and verification, and authentication information such as passwords and checksum values are stored in the smart cards. Since the server side does not need such information, the proposed authentication scheme will be resistant to checksum value loss attacks, while the servers can authenticate each other through their server passwords \(x\). Therefore, internal members will not be able to steal or change passwords.

4.4.6 Single-point failure analysis

In information systems, a single point of failure is a point in the entire system where if data tampering or data loss occurs at a particular information point thus causing the point to fail, it will cause the entire system to stop working. This is more common in centralized storage management, where an attacker only needs to attack the centralized server to tamper or steal the data information in the database, and the whole system will not work properly. The model in this paper is built based on blockchain and designed with a collaborative access control model of main and side chains, which can effectively avoid the single point of failure problem of centralized storage, and the chain hash pointer structure of the blockchain itself can ensure that the data on it cannot be arbitrarily deleted or changed, which is an effective guarantee for data integrity. The stored resources and access control policy are stored on the side chain, and the side chain, as a separate blockchain, can be an independent system, so any security risk on the side chain does not affect the main chain, let alone the security of the whole system.

4.5 Privacy security analysis

The privacy security analysis involved in this study will be made from two aspects, the first aspect is visitor identity information privacy security, i.e., the identity information privacy of medical professionals. The second aspect is data privacy security, i.e., the privacy of patient medical data stored in the side chain, while the information stored in the nodes and blocks on the main chain is regarded as public information in this study and no longer involves privacy protection.

4.5.1 Identity information privacy security analysis

Privacy refers to the private space, private activities, and private information that an individual or group does not want others to know. In the visitor authentication link proposed in this paper, the doctor’s medical care number \(ID\) and login password \(Pw\) are regarded as private information, and once the doctor’s private information is leaked, it may cause serious consequences. In the authentication scheme proposed in this paper, the hospital HIS system server only participates in the calculation and verification process of visitor authentication, and after obtaining the corresponding calculation results, \(\left( {ID,Pw} \right)\) will be cleared by the server, and no more sensitive information such as doctors’ accounts and passwords will be stored on the server, which avoids the risk of privacy leakage of doctors’ identity information due to server attack.

4.5.2 Data privacy security analysis

In terms of the privacy protection of patients’ medical data, we compare and analyze the AC-BMS model proposed in this paper with the mapping models proposed in the literature [15, 16, 20, 29, 35]. The comparison is done in six dimensions, such as whether it is based on blockchain, access control, storage method, trusted institution, session key, and privacy protection, and the results are shown in Table 9.

Table 9 Model comparison
Full size table

As can be seen from Table 8, existing data privacy protection schemes usually use only blockchain technology or access control technology, and there are relatively few studies that combine the two technologies. Most of the traditional blockchain-based storage methods use single-chain storage, and the traditional single-chain model does not guarantee that the data are completely isolated, even if the data are stored in the depository system and uploaded to the blockchain through the mapping relationship of the depository system, the risk of data leakage still occurs. The centralized data storage method is easy to manage, but the large volume of medical data leads to a large amount of private patient information leakage if the server of HIS system storing medical data is compromised. In this paper, six side chains are used to store patients’ medical data, and the nodes and blocks on the main chain only store some useful information that can be disclosed, and more medical data resources involving patients, etc. are reasonably stored to the side chains, which belongs to the multi-chain isolated storage model. The multi-chain model is to encapsulate different services into different blockchains and stores data in isolated encryption, while the multi-chain isolated storage model can overcome the defects of the single-chain storage model. In addition, the proposed model restricts the requesting visitors, who must be authenticated and authorized to access HIS system and obtain the patient data information on the side chain. At the same time, the Roll-up smart contract deployed on the side chain plays a supervisory role in the access behavior of the visitors and detects the subjects who access the patient data information on the side chain maliciously and prohibits them from accessing the patient data information on the side chain. Therefore, the blockchain access control model proposed in this study reduces patient data privacy leakage to a certain extent and provides good protection for patient data privacy security.

5 Conclusions

In the medical big data environment, the centralized storage and centralized authorization model in hospital information systems can lead to security issues, such as data tampering and privacy leakage. The traditional access control model is too simple in terms of identity verification, and the execution of access control policies relies more on trusted third-party organizations, which is inefficient in processing access requests. In order to solve the above problems, this paper proposes an access control model based on blockchain main side chain collaboration, AC-BMS. We firstly design a password-based authentication scheme using doctors’ identity information, and only doctors who pass the authentication can send access requests to HIS system. Secondly, we enhance the storage scalability of the blockchain by creating six side chains, each of which stores a certain type of medical data of the patient. Then, we contracted the access control policy and designed the Roll-up smart contract, which was deployed on the side chains to automatically execute the Roll-up contract to obtain the target resource using the access request as the trigger condition. Finally, simulation experiments in Hyperledger Fabric confirm that the model improves access efficiency and throughput when the number of accesses is multiplied, saves 2–3 s on average access time, floats stable latency time, basically stays at 0.4 s, maintains throughput at 288–296 txt/s, and is enhanced in terms of security, scalability and availability.

The future research plan is divided into two points: (1) as the policy of access control is written into Roll-up contracts in this study, based on the characteristics of smart contracts, which are not managed by third-party trusted institutions, once the contract is developed and effective, it will be automatically cyclic execution with the developed contract rules, the contract content cannot be modified, smart destruction of smart contracts, which will generate additional overhead, which is also a smart This is a major challenge for the development of smart contracts, so in the subsequent research we will continue to study smart contracts in depth, expecting to gain in this challenge. (2) This study does not consider the difficulty of recognizing the request type of Ethereum master chain nodes under high concurrent access requests, and we will consider classifying the access request types in the next step to reduce the complexity of master chain nodes’ recognition under high concurrent access requests.