# Data Access Control Based on Blockchain in Medical Cyber Physical Systems

Authors: Fulong Chen; Jing Huang; Canlin Wang; Yuqing Tang; Cheng Huang; Dong Xie; Taochun Wang; Chuanxin Zhao
Journal: Security and Communication Networks
 (2021)

---

## Abstract

The current medical cyber physical systems involve a wide range of institutions and a large number of participants. Data sharing among distributed medical institutions is already a development trend. However, the security is worrying; e.g., the access to medical data lacks uniformity and standardization. What is more, data is easy to be tampered with and leaked. This has a very negative impact on the medical industry. Therefore, a strict and reliable access control mechanism for data in the medical cyber physical systems is a prerequisite for ensuring the implementation of modern medical functions. We deal with how to design effective access control in medical cyber physical systems. Combined with blockchain technology, we design the medical cyber physical systems based on blockchain data access control mechanism and unite data in the chain of union Fabric network resources access control. We qualitatively classify medical data, define the weight level of different data, design a medical data access framework based on blockchain, build an applicable model, formulate access control strategy, and specify the role assignment and access task matching of users, so as to achieve secure and effective data access control. The Hyperledger Fabric network is established as the alliance chain for managing access control rights distribution through smart contracts so as to achieve case-based medical data access control under the blockchain.


---

## Body

## 1. Introduction

Medical cyber physical systems (MCPS) [1] are involved in various medical institutions, government health management departments, and other medical or health institutions and the important part of smart IoT healthcare [2]. Electronic health records (EHR) include structured data, semistructured data, and unstructured data. These massive data provide support for basic information transmission. Patients are the main data providers. Medical data is directly related to patients’ privacy and life. Therefore, its importance is self-evident. To ensure the security of medical data and the privacy of patients is a necessary mechanism for MCPS. The mandatory implementation of access control for all users can stipulate that users can only access the specified resources, which is conducive to the standardized management of medical data access.The larger the amount of medical data, the more obvious the clinical characteristics, the more extensive the sources, the more diverse the structure, and the more promoted the progress of medical services. Clinically, the data of patients with the same condition are different; e.g., the symptoms of patients with pneumonia are different in temperature, breathing, muscle contraction, sleepiness, and so on. In addition, in large tertiary hospitals, a large number of doctors rely on modern medical equipment to obtain and analyze data, while in community hospitals, many doctors still rely on patients’ oral records, resulting in differences in medical data. Therefore, medical data itself is not easy to collect and store. If there is loss or malicious tampering, it will have a great impact on the diagnosis and treatment process. The types of medical data include structured data expressed in two-dimensional tables and logic, semistructured data difficult to store and transfer, and unstructured data with variable fields. The data must be firmly under control. Only patients have the highest authority for their own data, all data access and increase must be implemented according to the consensus reached by the system, and access records must not be erased, so as to ensure data sharing and data privacy protection.In 2018, there were 18 data leaks in the United States, involving more than 100,000 medical records. Among them, eight accidents even affected more than 500,000 medical records, and three accidents resulted in the disclosure of more than one million medical records. The attackers obtained a lot of public medical information. In the traditional medical database systems, patients do not participate in the management of their own medical information, so that patients may not know who uses their data and for what purpose. The administrator with the highest authority can modify the access records of medical data, resulting in the loss of credibility of the data and inability to determine whose data and when is leaked. The medical system formed in this way has no credibility, and the medical data has lost its practicability, which is also a huge blow to the medical and health system.In the MCPS, access control is an important means to ensure the security of medical data. It can manage the user’s rights, so that legitimate users can only access the data in the system according to their own permissions and prohibit unauthorized users to access the data, so as to ensure the safety of data and the normal operation of medical systems. Nowadays, access control is still an important means to protect data transmission and sharing. However, as the management methods become more and more complex and the security requirements become higher and higher, the access control authorization management becomes more difficult, the description of access control objects becomes more difficult, and the tamper resistance of access control mechanism is poor. In this paper, blockchain is combined with access control. Visitors must be prevented from having too much medical data. Traceability and lossless modification of blockchain can improve the credibility of access control mechanism. Because it is difficult for the current public chain to meet the requirements of high throughput, low energy consumption, and privacy protection, the alliance chain with higher potential in performance, privacy protection, and permission control is suitable for the blockchain in the medical environment. The entities involved in the medical blockchain must be recognized by the government, have certain credibility, and be strictly supervised by the health management department. In this way, the occurrence of malicious behavior is far less than that of public chains such as bitcoin. At the same time, after years of medical information development, each hospital has a relatively complete network, server, and database system. Therefore, the existing medical information system can provide a relatively secure and stable operation environment for the normal operation of Practical Byzantine Fault Tolerance (PBFT) algorithm. At the same time, because each node in the cluster running PBFT algorithm has the same state, the medical blockchain system avoids the centralization of transaction block or blockchain and achieves distributed trustworthiness.In this paper, the trusted mechanism of blockchain is used to design data access control in the MCPS. Section2 will discuss related works. In Section 3, the medical data access framework based on blockchain is introduced. In Section 4, an access control strategy of medical data based on blockchain is proposed. The scheme is analyzed in Section 5.


## 2. Related Works

At present, data security and privacy protection technology in the medical environment is still constantly updated, especially in access control. Yu et al. [3] solved the problems of data confidentiality and fine-grained and extensibility of access control by defining and implementing access policies based on data attributes and allowed data owners to delegate most of the computing tasks involved in fine-grained data access control to untrusted cloud servers that do not disclose the basic data content. Wang et al. [4] proposed a data access control model for a single user. Through the semantic dependency between data and the bottom-up integration process, the global visibility of reverse XML structure is realized, which effectively protects the privacy and has high access efficiency. Zhu et al. [5] proposed a practical construction of attribute hierarchy-based encryption (ABE-AH) based on forward and backward derivation functions for cloud storage services by using composite sequential bilinear groups. This mechanism defines the priority of attributes, improves the granularity of data access control in cloud environment, and significantly reduces the size of key and ciphertext. Chen and Lin [6] proposed a new authorization access control model, which stores patient data according to the privacy level and obtains corresponding information according to different authorization modes. The privacy levels are set according to the specific situation. However, this model only solved the problem of access control of medical information for legitimate authorized users and did not involve other types of medical information leakage and security protection.The access control studied by the above scholars all take into account the complexity of the medical environment and the difference of performance, which requires a third-party single-point entity or cloud server to make access control decisions, and the dependence on the third-party center is too high. Once the third-party center crashes, all nodes will be affected, and there is also the risk of data leakage. With the development of distributed computing, blockchain technology appears. Blockchain system uses chained block structure with time stamp to store data, so as to add time dimension to data. Each transaction on a block is password associated with two adjacent blocks, so that any transaction is traceable. Therefore, the combination of blockchain, a highly reliable technology, with the third-party center will greatly improve the reliability and performance and avoid the occurrence of single point of failure.Cruz et al. [7] introduced a kind of role-based access control- (RBAC-) smart contract (RBAC-SC) using smart contract. The platform uses Ethereum’s smart contract technology to realize cross organization role access. RBAC-SC uses smart contract and blockchain technology as a common infrastructure to express the essential trust and recognition relationship in RBAC and implements a challenge response authentication protocol to verify the ownership of user roles. Xue et al. [8] proposed an electronic medical information sharing model based on blockchain technology, which helps to solve the problem of information sharing difficulty between medical institutions. Dubovitskaya et al. [9] proposed a secure and reliable electronic medical record system based on the traceability of blockchain, proposed a framework for managing and sharing EMR data for cancer patient care, and implemented the framework in the form of prototype platform to ensure privacy, security, and availability, as well as fine-grained access control of EMR data. Di Francesco Maesa et al. [10] used blockchain technology to define access control system to ensure the auditability of access control policy evaluation and wrote smart contract with eXtensible Access Control Markup Language (XACML) policy and solidness deployed on Ethereum blockchain. This idea is similar to that proposed in this paper, which shows the availability of smart contract to implement access control policy. Zhang et al. [11] aimed at the problems of inconvenient sharing of medical data, easy tampering, and easy leakage of privacy data, based on RBAC, used information entropy technology to quantify medical data, and used the distributed characteristics of blockchain and its inherent security attributes to eliminate data islands and enable patients to manage their own medical data independently. Tang et al. [12] proposed an electronic prescription sharing scheme based on blockchain and conditional proxy reencryption. The conditional proxy reencryption scheme can provide an efficient ciphertext forwarding mechanism for electronic prescription sharing. Ma et al. [13] proposed a decentralized access control model based on block chain smart contract implementation. After meeting the conditions set by the user, the user can apply for authentication to the blockchain to obtain the permission to access user data and operate user data to achieve secure access control of user data.Through the above researches, we can see that the access control of medical data is still not perfect. At present, many scholars have been committed to combining the blockchain into the access control. However, the rights allocation, fine-grained access, and user management still need to be improved.


## 3. Medical Data Access Framework Based on Blockchain

Data is the basis of all applications in the MCPSs, and it is the most basic resource. Whether it is telemedicine, two-way referral, or artificial intelligence applications such as medical image detection and pattern recognition, a large amount of effective medical data are needed for testing. This work starts from the point that every access has a task. Combined with the concept of role and task, considering that access control can ensure the secure access after obtaining data, and blockchain can ensure the traceability of behavior, we design a medical data access framework based on blockchain, so as to improve the security of medical data protection.


### 3.1. Classification and Qualitative Analysis of Data

EHR mainly comes from patients. Therefore, patients have the highest authority of data, and they must know who can access their data, how to access it, and what to use it for. Other medical data come from medical institutions and medical devices themselves. The classification is shown in Table1.Table 1
Symbols and definitions.
ClassExampleEMR or EHRElectronic health records, diagnostic recordsAccess records, patient personal information, etc.Medical device dataEnvironmental data, network equipment data, medical device data, etc.Information of medical institutionsMedical big data sorting and trend analysis, etc.According to the sensitivity of medical data privacy protection, medical data is divided into four levels. The four types of data have different privacy sensitivity. The first type of privacy information has the highest sensitivity, and the corresponding weight should be the largest. The control of access rights should be stricter. The weight of the first, second, third, and fourth medical information decreases in turn, and the corresponding level gradually decreases.Data 1: personal information of patients, including the basic information of patients (name, gender, date of birth, telephone number, ID number, home address, etc.), is the patient’s personal privacy data, corresponding to the weight ofL1 which is used to represent the highest weight.Data 2: patient’s medical records, medical history, diagnosis and treatment records, and information collected by equipment, including patient’s medical record data (disease type, diagnosis date, symptom description, image data, diagnosis conclusion, hospitalization records, diagnosis doctor, hospital information, etc.), are related to diagnosis and important medical data, which helps to analyze and conquer the disease, corresponding to the weightL2.Data 3: clinical outcome analysis and big data analysis are obtained through clinical and information technology, which can be used by a government department to analyze the condition and understand the national health, mainly reflected in the data integrity, corresponding to the weightL3.Data 4: medical institution information, equipment information, and other information are mainly about the history and qualifications of medical institutions, the storage capacity of equipment, and some publicly available data, which can be found in an open network environment, corresponding to the weightL4.In this paper, the medical data is divided according to the weight, which is conducive to fine-grained distinction, increases the flexibility of medical data, and provides a good foundation for privacy protection of medical data. The fine-grained structure of medical data adopts the structure combined with access weight, and the formal definition of medical data is described in the following formula:(1)EHR=DataL=Data1Data2…Datanl1l2…ln.


### 3.2. Description of Subject and Object

In order to solve the problem of multiple users and complex tasks in the MCPS, the role-based access control model and task-based access control model are combined to classify users according to their roles. The access control authority is determined according to the task of the role, and the access authority, access policy, and access record are stored through the blockchain to ensure that the access authority cannot be tampered with, the access control can be made public, and the access record can be traced.The unified description of user (U), subject (S), object (O), role (R), and task (T) in the process of access control can better express the access policy and be better combined with the access control model. In this paper, we define the following concepts:(1)
User: all kinds of people participating in the MCPS, including the participants of medical institutions, the staff of health management departments, and the staff of medical insurance related institutions. Each user has its own account.(2)
Subject: users who make access requests include their own ID information, resource information, and task information. In the medical environment, they will be bound with the corresponding roles.(3)
Object: the access resources, namely, medical data resources, are divided intoData1, Data2, Data3, and Data4 according to the privacy sensitivity of data.(4)
Role: in the medical environment, according to the characteristics of each institution, the roles that can represent the users of the institution are formed, such as patients, doctors, nurses, administrators, and technicians.(5)
Task: every time the subject visits the object, the purpose is carried out with the task of communication in the MCPS, and different users have different tasks to access data according to their own needs.Different medical institutions have different departments. Although medical data is stored in the server of medical institutions, it is also classified and stored according to the department category. As shown in Figure1, the general departments of Grade 3A hospitals are classified, and different roles belong to different departments. In the process of access, users cannot exceed the authority and can only access data according to the permission scope of the user’s role. At the same time, when the subject accesses the data, the access control policy will also give the specific access path according to the specific access request information.Figure 1
Department classification.


### 3.3. Data Access Control Model Based on Blockchain

Considering that each user in the MCPS has its own tasks, and a large number of users can be reasonably allocated by role classification, the role-based access control model and task-based access control model are combined, and the blockchain-based task role access control model (B-TRAC) is proposed to ensure the security of access control policies and access permissions by relying on the characteristics of trusted blockchain.As shown in Figure2, it is the schematic diagram of B-TRAC. The role-based access control model (RBAC) and task-based access control model (TBAC) are combined with blockchain. The combination of RBAC and TBAC lies in the data transfer between roles and tasks. As the requester of access, users are assigned roles in the session to reduce the difficulty of visitor management. According to the characteristics of MCPs, every visit carries a task to apply. Therefore, the tasks in the medical environment are classified and mapped with roles, so that the access can be fine-grained and specific access requirements can be made clear. The expected task information and access control permission information are stored in the blockchain formed by each organization in the medical consortium as a node. The blockchain can ensure that it will not be tampered with and leave traces every time. By matching the task information in the access request with the expected task information in the blockchain, it can be concluded that the task of the access request is quite the same as the expected task in the blockchain. If it is different, access will be denied. If it is the same, the blockchain will give the corresponding access permissions to the corresponding visitors to complete the settings before access.Figure 2
Blockchain-based task role access control model.


### 3.4. Medical Data Access Control Architecture Based on Blockchain

Access to medical data is mainly for the personnel or medical equipment of medical institutions to collect data and send access requests. The framework of blockchain-based medical data access control (F-BMDAC) is shown in Figure3. In order to ensure that the policy and permission exchange are publicly visible on the blockchain, and to save blockchain resources, these two key data are stored on the blockchain. Other medical data are still stored on the server of the medical institution representing each node, and the server of the medical institution undertakes the work of identity authentication before access control.Figure 3
Framework of blockchain-based medical data access control.After the user sends the access request, the data security management module will analyze the access request, assign roles, analyze tasks, and request the medical data access permission from the blockchain data storage module. The blockchain module evaluates and obtains the permission database and feeds back the results. At the same time, the access to the permission information should also inform the patient to know the records of personal data being accessed. At the same time, the system administrator collects the access records and generates the access log.


## 3.1. Classification and Qualitative Analysis of Data

EHR mainly comes from patients. Therefore, patients have the highest authority of data, and they must know who can access their data, how to access it, and what to use it for. Other medical data come from medical institutions and medical devices themselves. The classification is shown in Table1.Table 1
Symbols and definitions.
ClassExampleEMR or EHRElectronic health records, diagnostic recordsAccess records, patient personal information, etc.Medical device dataEnvironmental data, network equipment data, medical device data, etc.Information of medical institutionsMedical big data sorting and trend analysis, etc.According to the sensitivity of medical data privacy protection, medical data is divided into four levels. The four types of data have different privacy sensitivity. The first type of privacy information has the highest sensitivity, and the corresponding weight should be the largest. The control of access rights should be stricter. The weight of the first, second, third, and fourth medical information decreases in turn, and the corresponding level gradually decreases.Data 1: personal information of patients, including the basic information of patients (name, gender, date of birth, telephone number, ID number, home address, etc.), is the patient’s personal privacy data, corresponding to the weight ofL1 which is used to represent the highest weight.Data 2: patient’s medical records, medical history, diagnosis and treatment records, and information collected by equipment, including patient’s medical record data (disease type, diagnosis date, symptom description, image data, diagnosis conclusion, hospitalization records, diagnosis doctor, hospital information, etc.), are related to diagnosis and important medical data, which helps to analyze and conquer the disease, corresponding to the weightL2.Data 3: clinical outcome analysis and big data analysis are obtained through clinical and information technology, which can be used by a government department to analyze the condition and understand the national health, mainly reflected in the data integrity, corresponding to the weightL3.Data 4: medical institution information, equipment information, and other information are mainly about the history and qualifications of medical institutions, the storage capacity of equipment, and some publicly available data, which can be found in an open network environment, corresponding to the weightL4.In this paper, the medical data is divided according to the weight, which is conducive to fine-grained distinction, increases the flexibility of medical data, and provides a good foundation for privacy protection of medical data. The fine-grained structure of medical data adopts the structure combined with access weight, and the formal definition of medical data is described in the following formula:(1)EHR=DataL=Data1Data2…Datanl1l2…ln.


## 3.2. Description of Subject and Object

In order to solve the problem of multiple users and complex tasks in the MCPS, the role-based access control model and task-based access control model are combined to classify users according to their roles. The access control authority is determined according to the task of the role, and the access authority, access policy, and access record are stored through the blockchain to ensure that the access authority cannot be tampered with, the access control can be made public, and the access record can be traced.The unified description of user (U), subject (S), object (O), role (R), and task (T) in the process of access control can better express the access policy and be better combined with the access control model. In this paper, we define the following concepts:(1)
User: all kinds of people participating in the MCPS, including the participants of medical institutions, the staff of health management departments, and the staff of medical insurance related institutions. Each user has its own account.(2)
Subject: users who make access requests include their own ID information, resource information, and task information. In the medical environment, they will be bound with the corresponding roles.(3)
Object: the access resources, namely, medical data resources, are divided intoData1, Data2, Data3, and Data4 according to the privacy sensitivity of data.(4)
Role: in the medical environment, according to the characteristics of each institution, the roles that can represent the users of the institution are formed, such as patients, doctors, nurses, administrators, and technicians.(5)
Task: every time the subject visits the object, the purpose is carried out with the task of communication in the MCPS, and different users have different tasks to access data according to their own needs.Different medical institutions have different departments. Although medical data is stored in the server of medical institutions, it is also classified and stored according to the department category. As shown in Figure1, the general departments of Grade 3A hospitals are classified, and different roles belong to different departments. In the process of access, users cannot exceed the authority and can only access data according to the permission scope of the user’s role. At the same time, when the subject accesses the data, the access control policy will also give the specific access path according to the specific access request information.Figure 1
Department classification.


## 3.3. Data Access Control Model Based on Blockchain

Considering that each user in the MCPS has its own tasks, and a large number of users can be reasonably allocated by role classification, the role-based access control model and task-based access control model are combined, and the blockchain-based task role access control model (B-TRAC) is proposed to ensure the security of access control policies and access permissions by relying on the characteristics of trusted blockchain.As shown in Figure2, it is the schematic diagram of B-TRAC. The role-based access control model (RBAC) and task-based access control model (TBAC) are combined with blockchain. The combination of RBAC and TBAC lies in the data transfer between roles and tasks. As the requester of access, users are assigned roles in the session to reduce the difficulty of visitor management. According to the characteristics of MCPs, every visit carries a task to apply. Therefore, the tasks in the medical environment are classified and mapped with roles, so that the access can be fine-grained and specific access requirements can be made clear. The expected task information and access control permission information are stored in the blockchain formed by each organization in the medical consortium as a node. The blockchain can ensure that it will not be tampered with and leave traces every time. By matching the task information in the access request with the expected task information in the blockchain, it can be concluded that the task of the access request is quite the same as the expected task in the blockchain. If it is different, access will be denied. If it is the same, the blockchain will give the corresponding access permissions to the corresponding visitors to complete the settings before access.Figure 2
Blockchain-based task role access control model.


## 3.4. Medical Data Access Control Architecture Based on Blockchain

Access to medical data is mainly for the personnel or medical equipment of medical institutions to collect data and send access requests. The framework of blockchain-based medical data access control (F-BMDAC) is shown in Figure3. In order to ensure that the policy and permission exchange are publicly visible on the blockchain, and to save blockchain resources, these two key data are stored on the blockchain. Other medical data are still stored on the server of the medical institution representing each node, and the server of the medical institution undertakes the work of identity authentication before access control.Figure 3
Framework of blockchain-based medical data access control.After the user sends the access request, the data security management module will analyze the access request, assign roles, analyze tasks, and request the medical data access permission from the blockchain data storage module. The blockchain module evaluates and obtains the permission database and feeds back the results. At the same time, the access to the permission information should also inform the patient to know the records of personal data being accessed. At the same time, the system administrator collects the access records and generates the access log.


## 4. Access Control Strategy of Medical Data Based on Blockchain

As the stage after identity authentication, access control is the means to determine the scope of data access. According to the proposed B-TRAC model and the F-BMDAC model, the data access control strategy based on blockchain in the MCPS is designed. The following describes in detail the role assignment, task assignment, task matching, and decision-making in the whole access control framework, as well as the access control permission management. Introducing the concept of role is beneficial to manage a large number of users, and introducing the concept of task is beneficial to refine each access request to achieve the purpose of fine-grained access control.The medical data in the MCPS is mainly stored in the server of each medical institution. The highest decision maker is the patient himself whether it can be accessed or not. Considering the high frequency utilization rate of medical data, patients authorize blockchain nodes in advance to manage data, and patients can check the access records of data at any time. When the access request is to consult data, the visitor and the blockchain node can exchange information and authorize access, but the authorization records and access records must be stored on the blockchain to ensure transparency.


### 4.1. User Role Assignment

The Central Server (CS) of each medical institution audits the access request (AR) information according to the authenticated information of the user node (UN), obtains the initial identity of the server, and assigns roles to the user according to the role type classification rules, which is recorded as(2)UN←R.Step 1.
CS audits AR information and obtains UN=ID,Task. According to the user’s ID information, the role R is assigned to the user, represented as(3)UN′=ID,Task,R.Step 2.
If theID in AR does not pass the registration in the authentication stage, the corresponding ID does not exist in CS and is not given the role, and the error information is recorded in the server log.


### 4.2. Task Information Matching

In order to enhance the practicability of MCPS, it is required that every access must carry the access task requirements; otherwise, it will not accept the access. At the same time, carrying access task is also for better decision-making, to distinguish the legitimacy of access. Access task (AC) is also determined according to the actual needs, as shown in Figure4. In the MCPS, the expected task (ET) need to be defined in Enquiry, Medical, Research, Insurance, and other access categories. Each access task should be classified according to the category to prevent malicious access and unauthorized access. Each access task is classified into the expected access task tree, which can ensure that each access application carries a legal access task. And at the same time, it can achieve fine-grained access requirements, make the specific category of each access clear, and form a mapping relationship between the access task and the user’s role.Figure 4
Expected access task tree.Whether the access control request can be allowed or not depends on whether the access task and the expected task match. The access task is carried by the access request, and the expected task is stored on the blockchain, which is the key to determining whether the access control request is allowed or not. The decision algorithm of access task matching is shown in Algorithm1.Algorithm 1: The decision algorithm of access task matching.
Input: access taskAT, expected taskETOutput: decision permit/reject(1)
permit← null;(2)
reject← null;(3)
Task←AT;(4)
fori=1to Task.lengthdo(5)
result← Decision (Task [i], ET); //Permission(6)
match(7)
ifresult is permittedthen(8)
Task.delete (Task [i]);(9)
permit.add (Task [i].PID);(10)
end(11)
else ifresult is rejectedthen(12)
Task.delete (Task [i]);(13)
reject.add (Task [i].PID);(14)
end(15)
end(16)
return permit, reject;The main tasks of the algorithm are as follows: (1) put all the expected task sets waiting for matching into the task as the buffering task set and (2) traverse the buffering task set to get the matching result sets including permit and reject, respectively.


### 4.3. User Permissions Management

The access users of medical data may come from different medical institutions and play different roles. Therefore, it is necessary to authorize, verify, update, and revoke the access permissions of users, as shown in Figure5. The specific process is as follows.Figure 5
Authority management of medical data.Authorization. According to the B-TRAC access control model, the blockchain platform grants the corresponding permission level of medical data access to different roles, noted as(4)R←P|Li•ni=1,2,3,4,and saves it in the log of the blockchain, where n is the update factor provided by the blockchain.Verification of Permissions. The user role R carries the access task AT. Under the condition that the user’s identity is legal, the server CS of the node responds to the medical data access according to the corresponding permissions of the user in the R←P permission level L.Update of Permissions. According to the access control model, when the authority is expired or the task value of medical data is added, the blockchain provides a new update factor rn′ in time to replace the previous rn value, calculates the new medical data access permission,(5)P′=P•rn′,and authorizes it to the corresponding role R, recorded as(6)R⇐P′.Revocation of Permissions. According to the need of access control, the blockchain sends permission revocation instruction R⟶revoke, that is, revoking the access permission corresponding to role R.


## 4.1. User Role Assignment

The Central Server (CS) of each medical institution audits the access request (AR) information according to the authenticated information of the user node (UN), obtains the initial identity of the server, and assigns roles to the user according to the role type classification rules, which is recorded as(2)UN←R.Step 1.
CS audits AR information and obtains UN=ID,Task. According to the user’s ID information, the role R is assigned to the user, represented as(3)UN′=ID,Task,R.Step 2.
If theID in AR does not pass the registration in the authentication stage, the corresponding ID does not exist in CS and is not given the role, and the error information is recorded in the server log.


## 4.2. Task Information Matching

In order to enhance the practicability of MCPS, it is required that every access must carry the access task requirements; otherwise, it will not accept the access. At the same time, carrying access task is also for better decision-making, to distinguish the legitimacy of access. Access task (AC) is also determined according to the actual needs, as shown in Figure4. In the MCPS, the expected task (ET) need to be defined in Enquiry, Medical, Research, Insurance, and other access categories. Each access task should be classified according to the category to prevent malicious access and unauthorized access. Each access task is classified into the expected access task tree, which can ensure that each access application carries a legal access task. And at the same time, it can achieve fine-grained access requirements, make the specific category of each access clear, and form a mapping relationship between the access task and the user’s role.Figure 4
Expected access task tree.Whether the access control request can be allowed or not depends on whether the access task and the expected task match. The access task is carried by the access request, and the expected task is stored on the blockchain, which is the key to determining whether the access control request is allowed or not. The decision algorithm of access task matching is shown in Algorithm1.Algorithm 1: The decision algorithm of access task matching.
Input: access taskAT, expected taskETOutput: decision permit/reject(1)
permit← null;(2)
reject← null;(3)
Task←AT;(4)
fori=1to Task.lengthdo(5)
result← Decision (Task [i], ET); //Permission(6)
match(7)
ifresult is permittedthen(8)
Task.delete (Task [i]);(9)
permit.add (Task [i].PID);(10)
end(11)
else ifresult is rejectedthen(12)
Task.delete (Task [i]);(13)
reject.add (Task [i].PID);(14)
end(15)
end(16)
return permit, reject;The main tasks of the algorithm are as follows: (1) put all the expected task sets waiting for matching into the task as the buffering task set and (2) traverse the buffering task set to get the matching result sets including permit and reject, respectively.


## 4.3. User Permissions Management

The access users of medical data may come from different medical institutions and play different roles. Therefore, it is necessary to authorize, verify, update, and revoke the access permissions of users, as shown in Figure5. The specific process is as follows.Figure 5
Authority management of medical data.Authorization. According to the B-TRAC access control model, the blockchain platform grants the corresponding permission level of medical data access to different roles, noted as(4)R←P|Li•ni=1,2,3,4,and saves it in the log of the blockchain, where n is the update factor provided by the blockchain.Verification of Permissions. The user role R carries the access task AT. Under the condition that the user’s identity is legal, the server CS of the node responds to the medical data access according to the corresponding permissions of the user in the R←P permission level L.Update of Permissions. According to the access control model, when the authority is expired or the task value of medical data is added, the blockchain provides a new update factor rn′ in time to replace the previous rn value, calculates the new medical data access permission,(5)P′=P•rn′,and authorizes it to the corresponding role R, recorded as(6)R⇐P′.Revocation of Permissions. According to the need of access control, the blockchain sends permission revocation instruction R⟶revoke, that is, revoking the access permission corresponding to role R.


## 5. Security Analysis and Discussion

### 5.1. Characteristic

#### 5.1.1. Principle of Minimum Privilege

It means to ensure that the user can obtain the minimum permission on the premise of ensuring the completion of the access request, so as to prevent the phenomenon of excessive authorization. Combining the concept of role with the concept of task can better manage users and refine the access of each user, effectively prevent users from malicious access, reduce the impact of illegal operation and false users on the MCPS, and minimize the loss in case of hacker attack.


#### 5.1.2. Principle of Separation of Duties

Roles all correspond to the concept of specific application background, such as patients, doctors, nurses, and managers, in the medical environment. Access permissions can be divided according to specific categories, which makes the management of access control very flexible and simple. In order to prevent users from having more permissions, the blockchain will assign permissions to the roles of users according to specific tasks. And patients can regularly query which visitors and access records their data access rights belong to. At the same time, this way can be fully applied in medical reimbursement to prevent the phenomenon of repeated reimbursement.


#### 5.1.3. Tamper Proof of Access Permissions and Policies

The specific permissions and policies of access control are stored on the blockchain and can be queried by all nodes on the blockchain, which shows the openness and transparency of access control. After completing the task matching, the blockchain node is authorized. Due to the credibility of the blockchain, the access permissions and policies cannot be tampered with.


#### 5.1.4. Fine-Grained Access Control

Patients have the highest control permissions over medical data. They can clearly specify the authorization and revocation of data permissions, including the time and frequency of sharing and the specific scope. Only authorized users are allowed to access the data specified by patients. Users are abstracted and classified by roles. Compared with a large number of users, roles can be more convenient for system management and reduce the burden of system administrators. By specific-to-each-visit task, in the medical task tree and fine-grained access control, we can avoid that each visit is not specific.


### 5.2. Security Analysis

#### 5.2.1. Security 1: Confidentiality of Medical Data

The patient data is stored in the server of the local medical institution, which cannot be accessed by unauthorized users. The data stored on the blockchain through hash operation and Merkle tree structure are digests. This kind of on-chain and off-chain storage structure can reduce the performance pressure of blockchain and avoid the direct disclosure of source data on the network.


#### 5.2.2. Security 2: Tamper-Resistant Medical Data

Each data block in the blockchain stores the hash value of its parent block, which is arranged in a certain sequence. The Practical Byzantine Fault-Tolerant (PBFT) algorithm can be used as a consensus algorithm in medical blockchain. PBFT algorithm does not need as much computing power as PoW algorithm to avoid “51% attack.” As a Byzantine Fault-Tolerant (BFT) algorithm, pbft algorithm has errors or malicious nodes less than or equal to those in the system to ensure the normal execution of distributed consensus process and the data cannot be tampered with.


#### 5.2.3. Effective Access and Sharing of Medical Data

The permission of data sharing is entirely determined by the data provider. Based on the principle of who provides data and who has the highest authority, the decision algorithm of access control policy must be satisfied in every access control decision.


#### 5.2.4. Single-Point Attack Risk

All information on the medical alliance blockchain is open and tamperable. The ledger in hash data is stored in the form of copies on each node in the network. In this way, the decentralized distributed structure does not have the problem of single-point attack in the traditional centralized organization.


#### 5.2.5. Anti-DDoS Attack

Distributed Denial of Service (DDoS) attack is a common problem in distributed system architecture. MCPS involves multiple domains and has the distributed features. The blockchain platform needs high-performance server as support, which ensures that the device is not a bottleneck. At the same time, in order to prevent a large number of useless users, the blockchain data not only limits the validity of permissions but also sends its authorization records to the data provider, so that it can resist DDoS attacks to a certain extent.


### 5.3. Security Proof of Blockchain

The security threat of blockchain mainly comes from the attacker’s attack on block and consensus mechanism, so as to achieve the purpose of modifying block data. We definep as the probability that the trusted node calculates and generates the next block, q as the probability that the malicious node of the attacker calculates and generates the next block, and qn as the probability that the attacker calculates n nodes to complete the attack, as shown in the following formula:(7)qn=1p≤qqpnp>q.In the case ofp>q, assuming that it takes an average time for the trusted node to calculate a block data, the length of the attacker’s forged blockchain will conform to Poisson distribution, and the mathematical expectation λ is shown in the following formula:(8)λ=n×qp.The Poisson distribution probability density function of new quantity that attackers forge new blocks of the blockchain multiplies the probability that the attacker successfully chases the trusted blockchain under this number, that is, the probability of the attacker successfully tampering with the block dataP is shown in formula [8]:(9)P=∑k=0∞λk⋅e−λk!⋅qpn−k,k≤n=1−∑k=0nλk⋅e−λk!⋅1−qpn−k,1,k>n.It is concluded that the attacker must obtain the function of 50% nodes in the blockchain network in order to control the whole blockchain data.


## 5.1. Characteristic

### 5.1.1. Principle of Minimum Privilege

It means to ensure that the user can obtain the minimum permission on the premise of ensuring the completion of the access request, so as to prevent the phenomenon of excessive authorization. Combining the concept of role with the concept of task can better manage users and refine the access of each user, effectively prevent users from malicious access, reduce the impact of illegal operation and false users on the MCPS, and minimize the loss in case of hacker attack.


### 5.1.2. Principle of Separation of Duties

Roles all correspond to the concept of specific application background, such as patients, doctors, nurses, and managers, in the medical environment. Access permissions can be divided according to specific categories, which makes the management of access control very flexible and simple. In order to prevent users from having more permissions, the blockchain will assign permissions to the roles of users according to specific tasks. And patients can regularly query which visitors and access records their data access rights belong to. At the same time, this way can be fully applied in medical reimbursement to prevent the phenomenon of repeated reimbursement.


### 5.1.3. Tamper Proof of Access Permissions and Policies

The specific permissions and policies of access control are stored on the blockchain and can be queried by all nodes on the blockchain, which shows the openness and transparency of access control. After completing the task matching, the blockchain node is authorized. Due to the credibility of the blockchain, the access permissions and policies cannot be tampered with.


### 5.1.4. Fine-Grained Access Control

Patients have the highest control permissions over medical data. They can clearly specify the authorization and revocation of data permissions, including the time and frequency of sharing and the specific scope. Only authorized users are allowed to access the data specified by patients. Users are abstracted and classified by roles. Compared with a large number of users, roles can be more convenient for system management and reduce the burden of system administrators. By specific-to-each-visit task, in the medical task tree and fine-grained access control, we can avoid that each visit is not specific.


## 5.1.1. Principle of Minimum Privilege

It means to ensure that the user can obtain the minimum permission on the premise of ensuring the completion of the access request, so as to prevent the phenomenon of excessive authorization. Combining the concept of role with the concept of task can better manage users and refine the access of each user, effectively prevent users from malicious access, reduce the impact of illegal operation and false users on the MCPS, and minimize the loss in case of hacker attack.


## 5.1.2. Principle of Separation of Duties

Roles all correspond to the concept of specific application background, such as patients, doctors, nurses, and managers, in the medical environment. Access permissions can be divided according to specific categories, which makes the management of access control very flexible and simple. In order to prevent users from having more permissions, the blockchain will assign permissions to the roles of users according to specific tasks. And patients can regularly query which visitors and access records their data access rights belong to. At the same time, this way can be fully applied in medical reimbursement to prevent the phenomenon of repeated reimbursement.


## 5.1.3. Tamper Proof of Access Permissions and Policies

The specific permissions and policies of access control are stored on the blockchain and can be queried by all nodes on the blockchain, which shows the openness and transparency of access control. After completing the task matching, the blockchain node is authorized. Due to the credibility of the blockchain, the access permissions and policies cannot be tampered with.


## 5.1.4. Fine-Grained Access Control

Patients have the highest control permissions over medical data. They can clearly specify the authorization and revocation of data permissions, including the time and frequency of sharing and the specific scope. Only authorized users are allowed to access the data specified by patients. Users are abstracted and classified by roles. Compared with a large number of users, roles can be more convenient for system management and reduce the burden of system administrators. By specific-to-each-visit task, in the medical task tree and fine-grained access control, we can avoid that each visit is not specific.


## 5.2. Security Analysis

### 5.2.1. Security 1: Confidentiality of Medical Data

The patient data is stored in the server of the local medical institution, which cannot be accessed by unauthorized users. The data stored on the blockchain through hash operation and Merkle tree structure are digests. This kind of on-chain and off-chain storage structure can reduce the performance pressure of blockchain and avoid the direct disclosure of source data on the network.


### 5.2.2. Security 2: Tamper-Resistant Medical Data

Each data block in the blockchain stores the hash value of its parent block, which is arranged in a certain sequence. The Practical Byzantine Fault-Tolerant (PBFT) algorithm can be used as a consensus algorithm in medical blockchain. PBFT algorithm does not need as much computing power as PoW algorithm to avoid “51% attack.” As a Byzantine Fault-Tolerant (BFT) algorithm, pbft algorithm has errors or malicious nodes less than or equal to those in the system to ensure the normal execution of distributed consensus process and the data cannot be tampered with.


### 5.2.3. Effective Access and Sharing of Medical Data

The permission of data sharing is entirely determined by the data provider. Based on the principle of who provides data and who has the highest authority, the decision algorithm of access control policy must be satisfied in every access control decision.


### 5.2.4. Single-Point Attack Risk

All information on the medical alliance blockchain is open and tamperable. The ledger in hash data is stored in the form of copies on each node in the network. In this way, the decentralized distributed structure does not have the problem of single-point attack in the traditional centralized organization.


### 5.2.5. Anti-DDoS Attack

Distributed Denial of Service (DDoS) attack is a common problem in distributed system architecture. MCPS involves multiple domains and has the distributed features. The blockchain platform needs high-performance server as support, which ensures that the device is not a bottleneck. At the same time, in order to prevent a large number of useless users, the blockchain data not only limits the validity of permissions but also sends its authorization records to the data provider, so that it can resist DDoS attacks to a certain extent.


## 5.2.1. Security 1: Confidentiality of Medical Data

The patient data is stored in the server of the local medical institution, which cannot be accessed by unauthorized users. The data stored on the blockchain through hash operation and Merkle tree structure are digests. This kind of on-chain and off-chain storage structure can reduce the performance pressure of blockchain and avoid the direct disclosure of source data on the network.


## 5.2.2. Security 2: Tamper-Resistant Medical Data

Each data block in the blockchain stores the hash value of its parent block, which is arranged in a certain sequence. The Practical Byzantine Fault-Tolerant (PBFT) algorithm can be used as a consensus algorithm in medical blockchain. PBFT algorithm does not need as much computing power as PoW algorithm to avoid “51% attack.” As a Byzantine Fault-Tolerant (BFT) algorithm, pbft algorithm has errors or malicious nodes less than or equal to those in the system to ensure the normal execution of distributed consensus process and the data cannot be tampered with.


## 5.2.3. Effective Access and Sharing of Medical Data

The permission of data sharing is entirely determined by the data provider. Based on the principle of who provides data and who has the highest authority, the decision algorithm of access control policy must be satisfied in every access control decision.


## 5.2.4. Single-Point Attack Risk

All information on the medical alliance blockchain is open and tamperable. The ledger in hash data is stored in the form of copies on each node in the network. In this way, the decentralized distributed structure does not have the problem of single-point attack in the traditional centralized organization.


## 5.2.5. Anti-DDoS Attack

Distributed Denial of Service (DDoS) attack is a common problem in distributed system architecture. MCPS involves multiple domains and has the distributed features. The blockchain platform needs high-performance server as support, which ensures that the device is not a bottleneck. At the same time, in order to prevent a large number of useless users, the blockchain data not only limits the validity of permissions but also sends its authorization records to the data provider, so that it can resist DDoS attacks to a certain extent.


## 5.3. Security Proof of Blockchain

The security threat of blockchain mainly comes from the attacker’s attack on block and consensus mechanism, so as to achieve the purpose of modifying block data. We definep as the probability that the trusted node calculates and generates the next block, q as the probability that the malicious node of the attacker calculates and generates the next block, and qn as the probability that the attacker calculates n nodes to complete the attack, as shown in the following formula:(7)qn=1p≤qqpnp>q.In the case ofp>q, assuming that it takes an average time for the trusted node to calculate a block data, the length of the attacker’s forged blockchain will conform to Poisson distribution, and the mathematical expectation λ is shown in the following formula:(8)λ=n×qp.The Poisson distribution probability density function of new quantity that attackers forge new blocks of the blockchain multiplies the probability that the attacker successfully chases the trusted blockchain under this number, that is, the probability of the attacker successfully tampering with the block dataP is shown in formula [8]:(9)P=∑k=0∞λk⋅e−λk!⋅qpn−k,k≤n=1−∑k=0nλk⋅e−λk!⋅1−qpn−k,1,k>n.It is concluded that the attacker must obtain the function of 50% nodes in the blockchain network in order to control the whole blockchain data.


## 6. Design and Verification of Hyperledger Prototype Platform

### 6.1. Experimental Environment

Access control mechanism is built on the basis of a more perfect identity authentication mechanism. In this section, through the Fabric 1.4 version of Hyperledger, with its membership module as the basis of identity management, and through the chain code services module, the access control mechanism is implemented with smart contract to complete the user (visitor) access (transaction) request to the ledger data. Considering the integrity of medical information physical fusion system in the actual operation, the data in the medical environment is described as a unified object. In order to take into account the heterogeneity of medical data and reduce the cost and complexity of medical informatization, the concept of attribute is used in the experiment to manage it uniformly. The premise of access control is identity authentication, and the foundation is certificate mechanism. There are three types of certificates in Fabric, such as Enrollment Certificate (ECert), Transaction Certificate (TCert), and TLS Certificate (TLSCert) used to guarantee the transmission security of communication link. The default signature algorithm of certificate is ECDSA, and the hash algorithm is SHA-256. ECert is issued to the principal who has provided the registration certificate to represent the identity of the principal in the Fabric. TCert is issued to users to control the permissions of each access. Each access can be different, so as to achieve anonymity. TLSCert controls the access of the network layer, which can verify the identity of the remote subject and prevent eavesdropping. In practical application, the identity of the main body is verified by ECert, and the authority management is achieved by checking the signature. For the administrator role in the blockchain, other operations depend on the definition in the MSP structure of the corresponding organization in the channel configuration, except that the installation chain code operation is to find and match the certificate list under the msp/admincerts path of the signed certificate root node.


### 6.2. Attribute Definition and Mapping of Object

Fabric network can restrict the ability of access nodes and users through PKI-based membership management. The decision algorithm of access control can be realized by the chain code of identity attribute when Hyperledger Fabric is running. In order to complete the extraction of attributes, the registration certificate of identity is required in membership. ECert contains one or more attribute names and corresponding attribute values as shown in Table2.Table 2
Attribute information mapping.
Attribute nameAttribute valueattrIDID of the attributeattrNameName of the attributeAttrValueValue of the attribute


### 6.3. Data Structure

In fact, blockchain connects all blocks through chain structure, which can be divided into internal block structure and inter block structure. Block is the node unit of the blockchain, and Genesis block is the starting node. The blockchain node is divided into block head and block body. After Genesis block, the block head of each blockchain contains the parent block hash, version number, consensus metadata, timestamp, status hash, Merkle root, and other information. Mining blockchain applications such as bitcoin also have the target difficulty value to control the mining difficulty. Block body contains block format, block size, transaction details or summary, and other information. As shown in Figure6, the blockchain node in Hyperledger Fabric is taken as a case to show the data structure of the blockchain. The application of blockchain is different, and the internal information is slightly different.Figure 6
Blockchain data structure.Merkle tree is applied in blockchain mainly for two reasons.


#### 6.3.1. PV-Simplified Payment Verification

If someone needs to verify whether a transaction information exists in the blockchain, he or she only needs to obtain the block header in the blockchain node and the complete Merkle tree where the transaction needs to be verified; that is, to perform a SPV proof: get the hash value of the transaction from the node, locate the block, download its complete Merkle tree, recalculate, and verify whether the Merkle root value is equal to the block head; that is, the verification is passed. Of course, SPV verification does not need to calculate all the hash values. It only needs to calculate the value on the binary tree path where the transaction information is located to complete the verification quickly. For the block containingn transactions, the complexity of SPV verification is log2n, which can ensure the integrity of the data.


#### 6.3.2. The Cost of Forging Merkle Roots Is Too High

Because of the irreversibility of hash operation, each node of the binary tree hashed from the bottom of the network is closely linked. If the data on the blockchain is maliciously damaged, the Merkle root and block header hash values will change, resulting in the block header hash change in the next block, thus causing the change of the nodes in the whole network. Therefore, if hackers want to attack blockchain nodes, they must control more than 51% of the computing power of the nodes. In the current complex large-scale heterogeneous network environment and the background of powerful data processing capacity, this situation is almost impossible to achieve, which ensures that the data can not be tampered with.


### 6.4. Management of Access Permissions

In the MCPS, different permissions of different users need to be set, which can be executed through the chain code in Fabric. In this paper, the user tag attribute is used to realize, and the chain code call is used to verify the permissions.User registration: when the SDK applies for a user, it specifies the user tag and obtains the corresponding tag when the chain code is executed to realize the chain code call permission verification. MSP stores copies of three types of certificates: administrator certificate admincerts, root certificate cacerts, and TLS root certificate tlscacerts. However, only the certificate is stored, and the private key is not stored. CA stores the root certificate of a functional certificate and its corresponding private key. The specific method of user registration in this paper is shown in Algorithm2.Algorithm 2: User registration.
Input: attrID, attrName, pwdOutput: user.setMspId which is the ID of the user in MSP(1)
FabricUser user← getUser (attrID, attrName, pwd);(2)
RegistrationRequest request←newRegistrationRequest (attrID, attrName, pwd);(3)
request.setSecret (pwd);(4)
request.addAttribute (new Attribute (”attrID ”));(5)
request.addAttribute (new Attribute (”attrName ”));(6)
request.addAttribute (new Attribute (”pwd ”));(7)
RegistrationRequest request = newRegistrationRequest (attribute);(8)
request.setSecret (pwd);(9)
if!user.getEnrollmentSecret ().equals(pwd) then(10)
throw new RuntimeException (” The password is(11)
abnormal. The password you set is inconsistent(12)
with the password in the system: yourPWD:”(13)
+pwd+,” system: ”+user.getEnrollmentSecret ());(14)
end(15)
user.setEnrollment (ca.enroll (NAME, pwd));Algorithm2 deals with the following functions:(1)
Taking the identity attribute, attribute name, and password as test cases(2)
Setting corresponding values for attribute information(3)
Testing the correctness of the password and outputting the ID in MSP.Chain code operation: the access initiator will belong to the corresponding organization org in the Fabric. The cryptogen tools provide certificates for different organizations and organize these certificates into the forms that can be directly used by the core components of peer and orderer. The chain code operation method of authority management in this paper is shown in Algorithm3.Algorithm 3: Permission management.
Input: the information of the access initiator, such as the organization org, the node peer, and the user IDOutput: the access log file of the subject and the operation record of the chain code(1)
logger.Info (Sprintf (”get args: %s,” args)); //Get the information of the access initiator(2)
/∗read org∗/(3)
iferr ! = nilthen(4)
logger.Error (fmt.Sprintf (”get deptAttrVal err: %s,” err.Error ()))(5)
end(6)
else(7)
ifdeptAttrVal = = dfthen(8)
logger.Info (fmt.Sprintf (”get deptAttrVal: %s,” dv));(9)
end(10)
else(11)
logger.Debug (fmt.Sprintf (”not found deptAttr”));(12)
end(13)
end(14)
/∗read peer∗/(15)
iferr ! = nilthen(16)
logger.Error (fmt.Sprintf (”get orgAttrVal err:%s,” err.Error ()));(17)
end(18)
else(19)
iforgAttrVal = = ofthen(20)
logger.Info (fmt.Sprintf (”got orgAttrVal: %s,” ov));(21)
end(22)
else(23)
logger.Debug (fmt.Sprintf (”not found orgAttr”));(24)
end(25)
end(26)
pv, pf, err \coloneq sinfo.GetAttributeValue (”peer”);(27)
/∗read user∗/(28)
iferr ! = nilthen(29)
logger.Error (fmt.Sprintf (”get peerAttrVal err: %s,” err.Error ()));(30)
end(31)
else(32)
ifpeerAttrVal = = pfthen(33)
logger.Info (fmt.Sprintf (”got peerAttrVal: %s,” pv));(34)
end(35)
else(36)
logger.Debug (fmt.Sprintf (”not found peerAttr”));(37)
end(38)
end(39)
iferr! = nilthen(40)
logger.Error(fmt.Sprintf (”get userAttrVal err: %s,” err.Error ()));(41)
end(42)
else(43)
ifuserAttrVal = = ufthen(44)
logger.Info (fmt.Sprintf (”got userAttrVal: %s,” uv));(45)
end(46)
else(47)
logger.Debug (fmt.Sprintf (”not found userAttr”));(48)
end(49)
end(50)
return shim.Success ( [] byte (”log”));The main tasks of Algorithm3 are as follows:(1)
Getting the initiation information of visitors(2)
Reading the corresponding org, peer, and user values(3)
Sending feedback read log


### 6.5. Experimental Analysis

Through the access to the case data in Fabric, set the user’s access permissions to different data, manage and classify users through attributes, and distinguish the permissions of the logged in user’s attribute information, and the experimental verification system achieves the effect of access control. The CA in MSP is responsible for the registration, management, and certificate issuance of users. org is used to represent a hospital in the MCPS, user is used to represent users, and peer is used to represent nodes other than users. As shown in Figure7, after setting the information of the node pair, we can query the relevant specific information by using membership to manage it. At the same time, we can query the digital signature information to ensure the traceability of each visit.Figure 7
Query node information and signature value.In the decision of access control policy, the policy identifier must sign a specific user to satisfy the policy. The access control policy is managed by the chain code, and the permission information and the accessed data are stored on the chain. When the data is accessed successfully, it is shown in Figure8.Figure 8
Data access.


## 6.1. Experimental Environment

Access control mechanism is built on the basis of a more perfect identity authentication mechanism. In this section, through the Fabric 1.4 version of Hyperledger, with its membership module as the basis of identity management, and through the chain code services module, the access control mechanism is implemented with smart contract to complete the user (visitor) access (transaction) request to the ledger data. Considering the integrity of medical information physical fusion system in the actual operation, the data in the medical environment is described as a unified object. In order to take into account the heterogeneity of medical data and reduce the cost and complexity of medical informatization, the concept of attribute is used in the experiment to manage it uniformly. The premise of access control is identity authentication, and the foundation is certificate mechanism. There are three types of certificates in Fabric, such as Enrollment Certificate (ECert), Transaction Certificate (TCert), and TLS Certificate (TLSCert) used to guarantee the transmission security of communication link. The default signature algorithm of certificate is ECDSA, and the hash algorithm is SHA-256. ECert is issued to the principal who has provided the registration certificate to represent the identity of the principal in the Fabric. TCert is issued to users to control the permissions of each access. Each access can be different, so as to achieve anonymity. TLSCert controls the access of the network layer, which can verify the identity of the remote subject and prevent eavesdropping. In practical application, the identity of the main body is verified by ECert, and the authority management is achieved by checking the signature. For the administrator role in the blockchain, other operations depend on the definition in the MSP structure of the corresponding organization in the channel configuration, except that the installation chain code operation is to find and match the certificate list under the msp/admincerts path of the signed certificate root node.


## 6.2. Attribute Definition and Mapping of Object

Fabric network can restrict the ability of access nodes and users through PKI-based membership management. The decision algorithm of access control can be realized by the chain code of identity attribute when Hyperledger Fabric is running. In order to complete the extraction of attributes, the registration certificate of identity is required in membership. ECert contains one or more attribute names and corresponding attribute values as shown in Table2.Table 2
Attribute information mapping.
Attribute nameAttribute valueattrIDID of the attributeattrNameName of the attributeAttrValueValue of the attribute


## 6.3. Data Structure

In fact, blockchain connects all blocks through chain structure, which can be divided into internal block structure and inter block structure. Block is the node unit of the blockchain, and Genesis block is the starting node. The blockchain node is divided into block head and block body. After Genesis block, the block head of each blockchain contains the parent block hash, version number, consensus metadata, timestamp, status hash, Merkle root, and other information. Mining blockchain applications such as bitcoin also have the target difficulty value to control the mining difficulty. Block body contains block format, block size, transaction details or summary, and other information. As shown in Figure6, the blockchain node in Hyperledger Fabric is taken as a case to show the data structure of the blockchain. The application of blockchain is different, and the internal information is slightly different.Figure 6
Blockchain data structure.Merkle tree is applied in blockchain mainly for two reasons.


### 6.3.1. PV-Simplified Payment Verification

If someone needs to verify whether a transaction information exists in the blockchain, he or she only needs to obtain the block header in the blockchain node and the complete Merkle tree where the transaction needs to be verified; that is, to perform a SPV proof: get the hash value of the transaction from the node, locate the block, download its complete Merkle tree, recalculate, and verify whether the Merkle root value is equal to the block head; that is, the verification is passed. Of course, SPV verification does not need to calculate all the hash values. It only needs to calculate the value on the binary tree path where the transaction information is located to complete the verification quickly. For the block containingn transactions, the complexity of SPV verification is log2n, which can ensure the integrity of the data.


### 6.3.2. The Cost of Forging Merkle Roots Is Too High

Because of the irreversibility of hash operation, each node of the binary tree hashed from the bottom of the network is closely linked. If the data on the blockchain is maliciously damaged, the Merkle root and block header hash values will change, resulting in the block header hash change in the next block, thus causing the change of the nodes in the whole network. Therefore, if hackers want to attack blockchain nodes, they must control more than 51% of the computing power of the nodes. In the current complex large-scale heterogeneous network environment and the background of powerful data processing capacity, this situation is almost impossible to achieve, which ensures that the data can not be tampered with.


## 6.3.1. PV-Simplified Payment Verification

If someone needs to verify whether a transaction information exists in the blockchain, he or she only needs to obtain the block header in the blockchain node and the complete Merkle tree where the transaction needs to be verified; that is, to perform a SPV proof: get the hash value of the transaction from the node, locate the block, download its complete Merkle tree, recalculate, and verify whether the Merkle root value is equal to the block head; that is, the verification is passed. Of course, SPV verification does not need to calculate all the hash values. It only needs to calculate the value on the binary tree path where the transaction information is located to complete the verification quickly. For the block containingn transactions, the complexity of SPV verification is log2n, which can ensure the integrity of the data.


## 6.3.2. The Cost of Forging Merkle Roots Is Too High

Because of the irreversibility of hash operation, each node of the binary tree hashed from the bottom of the network is closely linked. If the data on the blockchain is maliciously damaged, the Merkle root and block header hash values will change, resulting in the block header hash change in the next block, thus causing the change of the nodes in the whole network. Therefore, if hackers want to attack blockchain nodes, they must control more than 51% of the computing power of the nodes. In the current complex large-scale heterogeneous network environment and the background of powerful data processing capacity, this situation is almost impossible to achieve, which ensures that the data can not be tampered with.


## 6.4. Management of Access Permissions

In the MCPS, different permissions of different users need to be set, which can be executed through the chain code in Fabric. In this paper, the user tag attribute is used to realize, and the chain code call is used to verify the permissions.User registration: when the SDK applies for a user, it specifies the user tag and obtains the corresponding tag when the chain code is executed to realize the chain code call permission verification. MSP stores copies of three types of certificates: administrator certificate admincerts, root certificate cacerts, and TLS root certificate tlscacerts. However, only the certificate is stored, and the private key is not stored. CA stores the root certificate of a functional certificate and its corresponding private key. The specific method of user registration in this paper is shown in Algorithm2.Algorithm 2: User registration.
Input: attrID, attrName, pwdOutput: user.setMspId which is the ID of the user in MSP(1)
FabricUser user← getUser (attrID, attrName, pwd);(2)
RegistrationRequest request←newRegistrationRequest (attrID, attrName, pwd);(3)
request.setSecret (pwd);(4)
request.addAttribute (new Attribute (”attrID ”));(5)
request.addAttribute (new Attribute (”attrName ”));(6)
request.addAttribute (new Attribute (”pwd ”));(7)
RegistrationRequest request = newRegistrationRequest (attribute);(8)
request.setSecret (pwd);(9)
if!user.getEnrollmentSecret ().equals(pwd) then(10)
throw new RuntimeException (” The password is(11)
abnormal. The password you set is inconsistent(12)
with the password in the system: yourPWD:”(13)
+pwd+,” system: ”+user.getEnrollmentSecret ());(14)
end(15)
user.setEnrollment (ca.enroll (NAME, pwd));Algorithm2 deals with the following functions:(1)
Taking the identity attribute, attribute name, and password as test cases(2)
Setting corresponding values for attribute information(3)
Testing the correctness of the password and outputting the ID in MSP.Chain code operation: the access initiator will belong to the corresponding organization org in the Fabric. The cryptogen tools provide certificates for different organizations and organize these certificates into the forms that can be directly used by the core components of peer and orderer. The chain code operation method of authority management in this paper is shown in Algorithm3.Algorithm 3: Permission management.
Input: the information of the access initiator, such as the organization org, the node peer, and the user IDOutput: the access log file of the subject and the operation record of the chain code(1)
logger.Info (Sprintf (”get args: %s,” args)); //Get the information of the access initiator(2)
/∗read org∗/(3)
iferr ! = nilthen(4)
logger.Error (fmt.Sprintf (”get deptAttrVal err: %s,” err.Error ()))(5)
end(6)
else(7)
ifdeptAttrVal = = dfthen(8)
logger.Info (fmt.Sprintf (”get deptAttrVal: %s,” dv));(9)
end(10)
else(11)
logger.Debug (fmt.Sprintf (”not found deptAttr”));(12)
end(13)
end(14)
/∗read peer∗/(15)
iferr ! = nilthen(16)
logger.Error (fmt.Sprintf (”get orgAttrVal err:%s,” err.Error ()));(17)
end(18)
else(19)
iforgAttrVal = = ofthen(20)
logger.Info (fmt.Sprintf (”got orgAttrVal: %s,” ov));(21)
end(22)
else(23)
logger.Debug (fmt.Sprintf (”not found orgAttr”));(24)
end(25)
end(26)
pv, pf, err \coloneq sinfo.GetAttributeValue (”peer”);(27)
/∗read user∗/(28)
iferr ! = nilthen(29)
logger.Error (fmt.Sprintf (”get peerAttrVal err: %s,” err.Error ()));(30)
end(31)
else(32)
ifpeerAttrVal = = pfthen(33)
logger.Info (fmt.Sprintf (”got peerAttrVal: %s,” pv));(34)
end(35)
else(36)
logger.Debug (fmt.Sprintf (”not found peerAttr”));(37)
end(38)
end(39)
iferr! = nilthen(40)
logger.Error(fmt.Sprintf (”get userAttrVal err: %s,” err.Error ()));(41)
end(42)
else(43)
ifuserAttrVal = = ufthen(44)
logger.Info (fmt.Sprintf (”got userAttrVal: %s,” uv));(45)
end(46)
else(47)
logger.Debug (fmt.Sprintf (”not found userAttr”));(48)
end(49)
end(50)
return shim.Success ( [] byte (”log”));The main tasks of Algorithm3 are as follows:(1)
Getting the initiation information of visitors(2)
Reading the corresponding org, peer, and user values(3)
Sending feedback read log


## 6.5. Experimental Analysis

Through the access to the case data in Fabric, set the user’s access permissions to different data, manage and classify users through attributes, and distinguish the permissions of the logged in user’s attribute information, and the experimental verification system achieves the effect of access control. The CA in MSP is responsible for the registration, management, and certificate issuance of users. org is used to represent a hospital in the MCPS, user is used to represent users, and peer is used to represent nodes other than users. As shown in Figure7, after setting the information of the node pair, we can query the relevant specific information by using membership to manage it. At the same time, we can query the digital signature information to ensure the traceability of each visit.Figure 7
Query node information and signature value.In the decision of access control policy, the policy identifier must sign a specific user to satisfy the policy. The access control policy is managed by the chain code, and the permission information and the accessed data are stored on the chain. When the data is accessed successfully, it is shown in Figure8.Figure 8
Data access.


## 7. Conclusions and Future Works

In this paper, we start with the data resources of MCPS and, combining with the blockchain technology, put forward the access control mechanism to ensure the secure access of data. The MCPS combined with blockchain is a general trend, which can make use of the distributed and credibility of blockchain technology to disclose the records of each visit and ensure the secure storage of data [14]. The future work can be continued from two aspects. On the one hand, considering the complexity of medical environment and the difference of device performance, we can design lightweight access control mechanism to ensure access security in heterogeneous environment. On the other hand, we can set up a unified data access control mechanism to cooperate with various medical institutions to ensure the security of data. MCPS covers a wide range of institutions and involves people’s life safety and property interests, which is related to the development of hospitals, research institutes, insurance companies, and government departments [15]. Therefore, the comprehensive consideration of how to meet the access control standards of different users in different demand conditions will promote the development of the whole medical informatization and better guarantee the security of medical data.



---

*Source: 3395537-2021-10-28.xml*