A medical data sharing and access control method based on blockchain and edge computing

Abstract

The application relates to the technical field of data security and privacy protection, in particular to a medical data sharing and access control method based on a blockchain and edge computing, which comprises an initialization process, a data creation and uploading process, a data access and sharing process and a data tracing and positioning process. The application reduces the calculation and communication overhead in medical Internet of Things data transmission, and can meet the efficiency and security requirements of medical data sharing between providers and consumers.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of data security and privacy protection, and particularly relates to a medical data sharing and access control method based on a blockchain and edge computing. BACKGROUND

[0002] With the rapid development of medical technology and information technology, the generation and sharing of medical data have become increasingly important in the field of healthcare, not only affecting people's quality of life, but also having a profound impact on the safety of developing economies. In order to effectively respond to public health challenges, cross-regional data sharing is often required for comprehensive analysis, and the data of a single hospital is often insufficient to provide complete information, making it difficult to fully reflect the health status of the entire region and meet the needs of public health forecasting and optimal allocation of medical resources. For example, the prediction of epidemics introduces a global defense system, which relies on the sharing of data from multiple regions. Internet of Medical Things (IoMT) continuously generates and collects health data of patients, including physiological and pathological information, supporting precision medicine and personalized treatment. In recent years, the widespread application of IoMT and the rise of cloud computing have provided technical support for large-scale medical data sharing across regions, breaking through the limitations of traditional data management models. The integration of these technologies is reshaping the management and use of medical data, creating new opportunities for more accurate medical predictions and more efficient public health responses.

[0003] In a typical cloud-based medical data sharing model, the cloud centrally manages and stores data from data providers through a database and transmits it to multiple institutions (such as medical service institutions, academic research institutions, and pharmaceutical research centers) from the same region. Although this database-based cloud architecture has certain advantages in data management and transmission, it still has the following shortcomings:

[0004] ① Low efficiency: When handling a large number of concurrent data requests, the cloud architecture faces bandwidth bottlenecks and high latency problems, resulting in decreased data transmission efficiency and inability to meet the needs of real-time medical data processing.

[0005] ② Poor security: In a complex medical data sharing environment where all entities cannot be fully trusted, data security faces multiple sources of risk, each of which can pose a serious threat to the security of the system.

[0006] (1) Illegal data requests: Consumers may attempt to access unauthorized data.

[0007] (2) Potential privacy leaks: Cloud centers or consumers may be interested in data or patient privacy.

[0008] (3) Profit-driven collusion: Consumers can collude with the cloud center to obtain unauthorized data.

[0009] ③ Accountability: Defensive measures alone cannot completely prevent malicious behavior, and the system must also have the ability to trace and hold accountable in order to identify and track malicious actors. In a cloud-based data sharing system, there are three types of potential malicious entities that may be faced:

[0010] (1) Providers: For example, data may come from an Internet of Medical Things (IoMT) that has been attacked or leaked due to a doctor's mistake.

[0011] (2) Consumers: They may try to obtain unauthorized data.

[0012] (3) Cloud center: They may be curious about the shared data, or even risk improper use.

[0013] Although cloud computing can meet the basic needs of cross-regional medical data sharing, it still faces challenges such as bandwidth, latency, and privacy protection in practical applications. As an emerging technology, edge computing reduces data transmission latency by processing data near the data source, improving data processing speed and efficiency. The introduction of edge computing can provide location-aware, bandwidth-sufficient, fast-response, and privacy-focused low-cost services, which have shown great potential in supporting smart medical applications and have attracted widespread attention from the academic community.

[0014] Meanwhile, Attribute-Based Encryption (ABE) technology has been widely used in flexible and fine-grained access control. This technology assigns different access permissions based on different user attributes, which has significant advantages in protecting data privacy and identity privacy. However, the implementation of ABE usually requires a large amount of computing resources, which limits its practical application in doctors' daily work due to the limited computing power of Internet of Medical Things (IoMT) devices.

[0015] On the other hand, blockchain, as a reliable distributed computing storage paradigm, ensures the security of the medical data sharing system and strengthens the accountability of malicious behavior with its characteristics of decentralization, tamper resistance, and traceability. Through blockchain technology, medical data can be securely shared among multiple institutions without relying on a single central authority. In addition, the application of smart contracts further automates and transparentizes the data access control and sharing process.

[0016] However, existing medical data sharing solutions rarely consider efficiency, security, and accountability simultaneously. Therefore, it is necessary to propose an access control scheme that can securely and efficiently share medical data in an untrusted environment.

[0017] The patent closest to the present invention is: a medical data sharing method based on blockchain (authorization number CN 114979210 B, authorized on May 7, 2024). This patent provides a medical data sharing method based on blockchain, which solves the problems of low efficiency and privacy protection of medical data sharing.

[0018] The main defects of this patent (publication number CN 114979210 B) are as follows:

[0019] 1. Using RSA public key encryption and decryption of data is a computationally expensive operation, which may cause performance bottlenecks if the data volume is large or needs to be shared frequently. Especially in the medical Internet of Things environment, the real-time requirement of data is high, and the traditional encryption and decryption process may slow down the speed of data transmission and sharing. Although the system uses RSA encryption and public key mechanism to ensure that only the designated hospital can decrypt and obtain the patient's health data, it does not explicitly state how to prevent other entities or malicious participants from pretending to be authorized hospitals to access data. If the attacker can obtain or impersonate the public key of the hospital, it may lead to data leakage.

[0020] 2. It is not clear how to anonymize patient data during data sharing. Without a clear anonymization method, sensitive information may be leaked, especially in cases where data is widely shared. Although the patent mentions using blockchain to record transactions, it does not mention how the system can trace the source of data errors. SUMMARY

[0021] The present invention aims to overcome the limitations of the prior art and proposes a medical data sharing access control method based on blockchain and edge computing. It includes initialization process, data creation and upload process, data access and sharing process, data tracing and positioning process;

[0022] In the initialization process: the cloud server and a number of edge nodes form a blockchain network, and each hospital server and data consumer registers in the blockchain network. The data consumer and each doctor terminal registered in the hospital server generate public / private keys, and each doctor terminal also generates group signature parameters. The hospital server sends a transaction to build an access control contract, which includes a policy information contract, a policy decision contract, and a policy management contract. The hospital server generates a symmetric encryption key;

[0023] In the data creation and uploading process, the Internet of Things device collects patient data, the doctor end customizes the access control policy of the sharable patient data, the data containing the access control policy is sent to the hospital server for storage after being signed by the doctor end and the patient, the hospital server performs data verification and desensitization, uses a symmetric encryption key to encrypt the data and transmits it to the corresponding edge node in the blockchain network, and the edge node stores the data after verification success;

[0024] In the data access and sharing process, the data consumer accesses the policy information contract in the blockchain, constructs and sends an access request, the policy decision contract checks the correctness of the request format and obtains the final decision result, such as the decision passes, the corresponding hospital server is found, the hospital server calculates the relevant information and sends it to the edge node, and the edge node sends the encryption to the data consumer.

[0025] Further, the data consumer includes academic research institutions, medical service institutions, and pharmaceutical research centers.

[0026] Further, the policy information contract is used to record the attribute-based request format, the policy decision contract is used to determine the access request permission, and the policy management contract is used to record the access control policy set by the data provider.

[0027] Further, the attributes include subject attributes, object attributes, operation attributes, and environment attributes.

[0028] Further, each doctor end runs the KeyGen algorithm of the group signature algorithm to generate group signature parameters for its group member patients; the doctor end obtains the private key gdsk of the group manager, and the group member patient P i The corresponding private key gpsk is obtained i And the group public key gppk.

[0029] Further, the hospital server uses a first count Bloom filter to record the fingerprints of the Internet of Things devices running normally, and uses a second count Bloom filter to record the fingerprints of the Internet of Things devices that have stopped working.

[0030] Further, assuming that the patient is P i , the doctor end is D id , and the data creation and uploading process is as follows:

[0031] Step 2.1: The Internet of Things device detects the patient P i , generates medical data m, and sends the medical data m and the device fingerprint hash Hash d to the aggregator to assist the status analysis of the patient P id of the doctor end D i ;

[0032] Step 2.2: After the patient's visit, if the patient agrees, the doctor will... id Custom access control policies To ensure that the rules and conditions for data sharing are clear; where φ is the predicate operation used to determine whether the rules are met; Represents an aggregation operation; R t For each rule, t is a specific attribute involved in constructing the AAR; SB is the subject attribute, OB is the object attribute, OP is the operation attribute, and EN is the environment attribute.

[0033] Step 2.3: Doctor's End D id Using the private key Dsk id Generate signature in For the doctor's signature algorithm, Hash d For fingerprints of IoT devices; patient P i Generate a group signature using the group signature key. The aggregator will include signed data containing access policies. Send to the hospital server for storage; PLC is the strategy.

[0034] Step 2.4: Hospital server verifies signature The presence of IoT devices in the first and second count Bloom filters was checked, and the collected patient data m was desensitized to obtain desensitized data m. Dd ;

[0035] Step 2.5: Generating the proxy re-encryption key: The hospital server generates a random number. Calculate the proxy re-encryption key Used to encrypt the data sharing key DCk, to obtain Where Gen(*) is the key generation algorithm. This is the hospital's proxy re-encryption public key, and the index 'id' represents the identity ID of the server that calculates the proxy re-encryption key on the hospital server. For a finite field, ENC is the encryption function;

[0036] Step 2.6: The hospital server generates de-identified data m Dd hash value Encrypt m using the data sharing key DCk Dd have to Encrypt using RDk have to Using public key Encrypt DCk to obtain

[0037] Step 2.7: The hospital server sends the encrypted data to the corresponding edge node, which verifies and stores the data, then returns the result to the hospital server. represents the entity certificate of the hospital server.

[0038] Further, in the data creation and upload process, there is also a process of updating the strategy. The hospital server sends a transaction containing to the strategy management contract to update the strategy.

[0039] Further, in the data access and sharing process, the edge node / cloud server finds the corresponding hospital server according to the access request, and the hospital server generates a random number X = g x A = g a B = g b , calculates s, and the calculation formula is as follows:

[0040] s = b + r * H(A || B)

[0041] where x, a, b are random numbers generated by the hospital server, g is the generator, H(*) is the hash function, and r is the random number; calculate the re-encryption key, and the calculation formula is as follows:

[0042]

[0043] Send {prk, X', capsule} to the edge node, capsule = {A, B, s}, the public key of the data consumer, is the power operation, and capsule represents the key fragments required for re-encryption; X' is an auxiliary key generated in the process of generating the re-encryption key; is the hospital's proxy re-encryption private key.

[0044] The edge node calculates A' = A prk B' = B prk and sends the encrypted data and {X, capsule'} to the data consumer, capsule' = {A', B', s};

[0045] The data consumer calculates to obtain the decryption key uses the key to decrypt the key Then use DCk to decrypt the obtained m Dd data, m Dd is the de-identified data.

[0046] Further, it also includes a data traceability and positioning process, which includes the following steps:

[0047] Step 4.1: After detecting abnormal data values, the data consumer notifies the corresponding edge node of this situation;

[0048] Step 4.2: After receiving the notification, the edge node searches the corresponding record Then according to the entity certificate of the hospital server Will Send to the corresponding hospital server;

[0049] Step 4.3: Decryption and verification steps: After the hospital server receives the encrypted data, it is decrypted using the key to obtain the original data S DS For the original function;

[0050] Step 4.4: The hospital server checks the first and second Bloom filters to confirm the existence of the device, and if the device does exist, the positioning is successful.

[0051] Advantages of the present application:

[0052] 1. The present application constructs a multifunctional edge-blockchain model, which reduces the calculation and communication overhead in medical Internet of Things data transmission, and can meet the efficiency and security requirements of medical data sharing between providers and consumers.

[0053] 2. The present application proposes an edge computing assisted contract based access control mechanism, which realizes trusted fine-grained access control.

[0054] 3. The verifiable and traceable anonymization scheme based on blockchain designed by the present application ensures the confidentiality of the patient's identity and shared data through group signature and proxy re-encryption technology, while supporting the tracking of damaged Internet of Things medical devices.

[0055] 4. The present application introduces blockchain smart contract technology to decentralize the management of PIP, PAP and PDP functions, fundamentally eliminating the dependence on a single centralized entity and effectively reducing the potential risks brought by centralized trust.

[0056] 5. The present application uses group signature and proxy re-encryption technology to improve the privacy protection capability in the data sharing process, ensuring the high confidentiality and identity anonymity of data in the multi-party transmission process, and realizing safe, flexible and fine-grained dynamic access control.

[0057] 6. The present application uses the traceability of the blockchain to record all access operation behaviors in the system through the smart contract, ensuring that malicious access can be tracked and held accountable. DETAILED DESCRIPTION

[0058] The application will be described in detail below with reference to specific embodiments.

[0059] The platform running the method described in the application includes a multi-layer data storage system, a blockchain network, a smart contract module, a plurality of data consumers, a plurality of data providers, and a plurality of hospital servers.

[0060] (1) Multi-layer data storage system

[0061] The multi-layer data storage system is composed of a cloud server, a plurality of edge nodes, and a plurality of hospital servers. Each edge node is connected to a plurality of hospital servers in its region, and each edge node is connected to the cloud server. Each region with multiple hospital servers deploys multiple edge nodes.

[0062] Each hospital server locally stores data that has not been disclosed, such as administrative data, financial data, medical image files, etc. It also stores the mapping relationship between the identity information of each doctor and their public key, the device information of Internet of Things devices, and shareable medical data and its access control policy. It can also generate symmetric encryption keys, upload data, and calculate services to support data sharing. Each hospital server has a blockchain access identity and the authority to access the blockchain.

[0063] Each edge node stores shareable medical data and its access control policy after encryption and desensitization processing by the hospital server, and interacts with the hospital server to deliver shareable medical data if the access request of the data consumer is verified.

[0064] The cloud server is used to support remote work and provide backup for the data of all edge nodes.

[0065] (2) Blockchain network

[0066] The multi-layer data storage system is composed of a cloud server, a plurality of edge nodes, and a plurality of hospital servers. Each region deploys multiple edge nodes, each edge node is connected to multiple hospital servers in its responsible region, and each edge node is connected to the cloud server. The hospital servers and data consumers registered in the blockchain network have a blockchain access identity and authority. Each edge node and the cloud server cooperate with each other through a consensus mechanism (such as the Byzantine Fault Tolerance consensus algorithm, PBFT) to jointly maintain a secure and reliable automated execution platform. The main functions of this platform include storing and managing various access control policies, and implementing fine-grained access control through the automatic execution of smart contracts. This mechanism not only prevents unauthorized access, but also ensures that data remains highly secure and complete during transmission and sharing. In addition, the distributed nature of the platform and the consensus mechanism enable it to have high fault tolerance, capable of dealing with malicious behavior and network failures, ensuring the stable operation of the entire system and the security of the data.

[0067] (3) Smart contract module

[0068] The smart contract module is used to manage the access control mechanism of data consumers, which includes a policy information contract, a policy management contract and a policy decision contract. The policy information contract is used to record the attribute-based request format, the policy decision contract is used to determine whether the access request meets the policy, and the policy management contract is used to record the access control policy set by the data provider. The attributes include subject attributes, object attributes, operation attributes and environment attributes. The subject attributes include name and / or position; the object attributes include file name and / or data sensitivity level and / or data type and / or data format and / or data source; the operation type includes reading and / or writing and / or editing and / or deleting and / or modifying; and the environment attribute includes access time / or access location / or device type / or network security state / or data access purpose.

[0069] (4) Data provider

[0070] The data provider is composed of an Internet of Things device and a doctor terminal in communication connection with the hospital server. The Internet of Things device collects medical data of patients in the hospital and provides the medical data together with a device fingerprint hash value to the doctor terminal. The doctor terminal transmits the sharable medical data and its access control policy to the hospital server. The patient data collected by the Internet of Things device can also be stored in the hospital server. Patients usually rely on external hospital collaboration platforms to share personal health data to obtain better medical services on the basis of ensuring personal privacy protection and maintaining autonomous ownership. These data mainly come from medical Internet of Things devices, and these devices are often the target of potential attacks due to their technical characteristics. Such attacks can lead to data leakage and misuse, which can cause actual physical harm to patients and even threaten the safety of patients' lives.

[0071] (5) Data consumer

[0072] The data consumer includes one or several of academic research institutions, medical service institutions and pharmaceutical research centers. Important subjects participating in data sharing include academic research institutions and medical service institutions, which actively request, obtain and analyze shared data, and feed back the results to patients or hospitals. The responsibilities of these institutions not only provide personalized medical advice, but also play a key role in epidemic warning and public health safety. By in-depth analysis of data, these institutions can identify potential health threats and take timely measures to help improve the efficiency of public health management and disease prevention and control.

[0073] The data consumer has a blockchain identity and access permission to the blockchain; the data consumer accesses a policy information contract in the blockchain, builds and sends an access request for requesting, obtaining and analyzing shared data, and can feed back the result.

[0074] The method comprises the following steps of:

[0075] The method comprises the following steps of:

[0076] I. Initialization process

[0077] In this stage, all entities build a basic system model and generate encryption parameters. The cloud server and edge node run a consortium blockchain supporting smart contracts, using the PBFT (practical Byzantine fault tolerance) consensus algorithm. The hospital and patient establish access control policies.

[0078] The initialization process comprises the following steps of:

[0079] The step of building a blockchain network: the cloud server and edge node are responsible for building a consortium blockchain network. The blockchain only allows permitted entities to send transactions to deploy or run smart contracts. In order to ensure data consistency, the PBFT consensus algorithm is used.

[0080] The step of entity registration: the entities include data providers and data consumers. The data providers include hospital servers, and the data consumers include academic research institutions, medical service institutions, pharmaceutical research centers, etc. These entities use their certificates C id to register with the certificate authority, obtain a blockchain identity B id and access permission to the blockchain. Assuming that the certificate is C id , the blockchain identity is B id , and the certificate authority records the mapping relationship (C id , B id ).

[0081] The step of the data consumer generating a proxy re-encryption key: the data consumer wants to obtain medical shared data and executes the PRE.KeyGen algorithm of the proxy re-encryption algorithm to generate a proxy re-encryption public / private key pair (ppk, psk).

[0082] The step of constructing contract: the hospital server sends a transaction for constructing access control contract, including policy information contract (PIC), policy determination contract (PDC) and policy administration contract (PAC). PIC records the format of attribute-based request, PDC runs the algorithm to determine whether the access request meets the policy, and PAC records the access control policy PLC set by the hospital side, which is the access policy for doctors and patients in this embodiment. The policy (PLC) defines a set of predicate operations for determining whether the access request meets the policy condition.

[0083] In this application, SB, OB, OP, EN, the four attributes together constitute the attribute set of the system, which is used to describe the characteristics of the access request. SB is the subject attribute, OB is the object attribute, OP is the operation attribute, and EN is the environment attribute. These attribute tuples constitute the attribute-based access request AAR.

[0084] SB: subject attribute, including all or one of attributes such as name (Name) and position (Position).

[0085] OB: object attribute, including all or one of attributes such as file name (FileName), data sensitivity level, data type, data format, and data source.

[0086] OP: operation type, such as all or one of read, write, edit, delete, modify, etc.

[0087] EN: environmental conditions, such as all or one of access time, access location, device type, network security status, and data access purpose.

[0088] Attribute-based request format: AAR. Each access request in the system contains a set of related attributes.

[0089] Specific case:

[0090] The process of researcher Alice accessing the file <heart rate.txt> in the hospital server through her personal computer. The specific steps are as follows:

[0091] Step one: Alice requests PIC: Alice requests PIC to understand the format of access request (AAR).

[0092] Step two: Constructing AAR: Alice constructs the following access request (AAR):

[0093] AAR = {(Name, Alice), (Position, Researcher), (FileName, heart rate.txt), (Action, read), (Time, 2024-10-24 12:00:00)} and sends this request to the PDC.

[0094] Step three: PDC requests PAC to send policy (PLC).

[0095] The PDC asks the PAC to send the relevant access policy (PLC) based on the file name <heart rate.txt>.

[0096] PAC sends policy (PIC): The PAC sends the following policy:

[0097] PIC = {"and", Note: Ensure that multiple conditions are met simultaneously;

[0098] (ID, I), Note: The ID set of the company;

[0099] (Position, Researcher), Note: Researcher identity;

[0100] (FileName, heartrate.txt), Note: The file operated is <heartrate.txt>;

[0101] (Action, read or write), Note: The operation type is read or write;

[0102] (Time, not null), Note: Time is not null (i.e., a specified time range is required).

[0103] }

[0104] Step four: PDC executes decision: The PDC runs the decision function J(AAR, PLC) to determine whether Alice can access the file <heart rate.txt> based on her request and the policy set.

[0105] Step to generate doctor public / private key pair: Each doctor terminal D id has its own elliptic curve digital signature algorithm (ECDSA) public key Dpk id , private key Dsk id . The hospital server records the mapping relationship (D id , Dpk id ).

[0106] Step of generating group signature parameters: each doctor end D id Run the KeyGen(n) algorithm of the group signature algorithm to generate group signature parameters for its patients, where n represents the number of patients under the responsibility of the doctor. The doctor will obtain the private key of the group manager gdsk, and the private key of the group member patient P i Then the corresponding private key gpsk is obtained i At the same time, the group public key gppk is also known. i is the user number. The hospital server records the mapping relationship (D id , gdsk, gppk).

[0107] Step of recording information of Internet of Things devices: the hospital server records information of all Internet of Things devices IoMT. In order to improve the query efficiency, two counting Bloom filters (first counting Bloom filter and second counting Bloom filter) are used to determine the existence of the device, wherein the first counting Bloom filter records the fingerprints (hash values) of the Internet of Things devices IoMT running normally, which is used to quickly determine whether the queried device belongs to the currently valid device, avoiding invalid queries. The second counting Bloom filter records the fingerprints (hash values) of the Internet of Things devices IoMT that have stopped working, which is used to determine whether the device has stopped working, avoiding redundant queries to retired devices. The fingerprint of the device is generated based on the unique attribute information of the device. Common device attribute information includes:

[0108] Unique identifier of the device (such as MAC address, device serial number)

[0109] Hardware information (such as CPU ID, storage device ID)

[0110] Network information (such as IP address)

[0111] Other specific device parameters (such as device type, manufacturer information, etc.)

[0112] Step of generating symmetric encryption key: the hospital server runs a key generation algorithm to generate symmetric encryption keys DCk and RDk. Among them, DCk is used for data sharing, and RDk is used for storing original data.

[0113] II. Data creation and upload process

[0114] At this stage, the Internet of Things medical devices (IoMT) detect patients and generate sensing data. The aggregator will receive these data and review them with the doctor. The doctor will discuss with the patient and generate an access control policy. Then, these data are sent to the local hospital server storage together with the policy, and after encryption and desensitization, they are transmitted to the edge node in the region.

[0115] The process includes the steps of data detection and transmission, access control policy formulation, signature generation and data transmission, data verification and desensitization, proxy re-encryption key generation, data encryption and transmission, data storage, and policy update. In this embodiment, the policy is uploaded to the chain code of Hyperledger Fabric through fabric-sdk-go and stored on the blockchain. The hospital server generates a symmetric key using the AES algorithm and implements proxy re-encryption using Golang to ensure that the doctor can specify who can decrypt the data. The re-encryption key is generated using the goPBC library of Golang, and the data is encrypted twice. The encrypted data is uploaded to the edge node storage, and the policy information is recorded on the blockchain to ensure data security. The doctor end can realize the corresponding function through the webpage or applet, etc. React (Web webpage) / React Native (APP) is used to provide the interaction interface of the doctor end, making it convenient for doctors to set policies, sign, and upload data. Node.js or Python provides API services to handle signature, encryption, policy upload, and other operations. ECDSA and BBS04 group signature are implemented using the PyCryptodome library of Python. A database (such as MongoDB or PostgreSQL) is equipped in the backend to store non-sensitive metadata or operation logs.

[0116] Data detection and transmission step: Internet of Things (IoMT) device (IoMT) detects patient P i , generates data m, and sends it to the aggregator along with the device fingerprint hash value Hash d to assist the doctor D id in analyzing the status of patient P i .

[0117] Step of formulating access control policy: After the patient's visit, the doctor discusses data sharing with the patient P i . If the patient agrees, the doctor's corresponding doctor end D id will customize the access control policy to ensure that the rules and conditions of data sharing are clear. Among them, φ is a predicate operation that judges whether the rules are met; represents an aggregation operation; such as and, or, t-out-of-n; R t is a rule, and t is a specific attribute involved in building AAR, such as user role, resource type, access time, etc.

[0118] Step of generating signature and data transmission: The doctor end D id uses the private key Dsk id to generate a signature wherein is a signature algorithm of the doctor, Hash d is a fingerprint of the IoT device. The patient P i uses the group signature key to generate a group signature The aggregator sends the signature data containing the access policy to the hospital server for storage.

[0119] The step of data verification and de-identification: the hospital server first verifies the signature checks the existence of the IoT device in the first and second count Bloom filters and de-identifies the collected patient data m (such as name, ID number, contact number, age, and other sensitive information) to obtain de-identified data m Dd for subsequent uploading to the edge node.

[0120] The step of the hospital server generating a proxy re-encryption key: the hospital server generates random numbers a, b ∈ Z p (Z p is a finite field that can be used to generate random numbers), calculates the proxy re-encryption key and encrypts the data sharing key DCk with K, obtaining wherein Gen(*) is a key generation algorithm, is the proxy re-encryption public key of the hospital server, and the subscript id represents the identity ID of the hospital server.

[0121] The step of data encryption and transmission: the hospital server generates the hash value of the de-identified data m Dd encrypts m Dd with the data sharing key DCk, obtaining encrypts obtains and encrypts DCk with the public key , obtaining

[0122] The step of data storage: the hospital server sends the encrypted data to the edge node, which verifies and stores the data, and then returns the result to the hospital server. represents the entity certificate of the hospital server.

[0123] The step of updating the policy: the hospital server sends a transaction containing to the PAC to update the policy PLC. For example, updating the visitor identity. ​​

[0124] III. Data access and sharing process

[0125] In this process, data consumers can obtain the required data from edge nodes or cloud servers after passing through the access control mechanism managed by the smart contract.

[0126] The process includes the steps of data consumer requesting access, building access request, format verification and policy request, data transmission, operating hospital server, edge node calculation and transmission, and data consumer decrypting data.

[0127] Step of data consumer requesting access: data consumers (such as academic research institutions, medical service institutions, etc.) access the PIC contract in the blockchain, and the contract discloses the attribute set.

[0128] Step of building access request: the data consumer builds access request AAR and its own proxy re-encryption public key transaction according to its own attributes, and then sends it to the PDC contract on the blockchain.

[0129] Step of verifying format and request policy: the PDC contract checks the correctness of the request format, and obtains the corresponding policy from the PAC contract according to information such as the fingerprint of the data . Then, the PDC verifies whether the AAR satisfies the access policy φ represents the aggregation operation, represents the predicate operation, R t represents the rule set. Specifically, the PDC first traverses all rules R t , for each rule, calls the RuleCheck function to determine the attribute t of the SB, OB, OP, EN attribute set in the request, whether its attribute value is within the range specified by the corresponding rule, if it satisfies, return True, otherwise return False. The result of each rule check (True or False) will be added to the result set. After all rule checks are completed, the FinalCheck function is called to determine whether all attributes included in the request sent by the access requester satisfy the access condition. The results are aggregated by the φ operation (such as and, or, etc.) to obtain the final access decision. If all conditions in the AAR built by the data consumer satisfy the decision, the final decision result is True, indicating that the access request meets the policy, and the PDC will return True; otherwise, return False.

[0130] Step of determining the corresponding hospital server: the edge node / cloud server receives the result that the access request meets the decision in the blockchain, and finds the corresponding hospital server through the public key of the data consumer .

[0131] Hospital server transmission step: the corresponding hospital server checks the result in the blockchain, generates a random number x∈Z p , calculates X=g x , A=g a , B=g b , calculates s, and the calculation formula is as follows:

[0132] s=b+r·H(A||B)

[0133] s is a signature value, which is used to verify the integrity of the capsule and the authenticity of the data. This signature can ensure that the data has not been tampered with. Wherein, x is a random number, g is a generator, a and b are random numbers generated by the hospital server, X, A, and B are the outputs of the power operation. H is a hash function. r is a random number. The re-encryption key is calculated, and the calculation formula is as follows:

[0134]

[0135] An auxiliary key X' is generated in the process of generating the re-encryption key, which is used to ensure the authorized control of data decryption. X' is associated with a specific access policy, which is used in the decryption step in the re-encryption process, further ensuring that only authorized consumers can decrypt the data.

[0136] The hospital server sends {prk, X', capsule} to the edge node, and capsule={A, B, s}. The public key of the data consumer, is the power operation. capsule represents the parameters and signature required by the data consumer for decryption, ensuring the safe transmission of data.

[0137] Edge node calculation and transmission step: the edge node calculates A'=A prk , B'=B prk

[0138] and sends the encrypted data and {X, capsule'} to the data consumer, and capsule'={A', B', s}.

[0139] Data consumer decryption step: the data consumer calculates the decryption key using the key Then use Dck to decrypt the obtained m Dd data. m Dd is the de-identified data.

[0140] Four, data traceability and positioning process

[0141] At this stage, based on blockchain and group signature, the application provides a method to trace the source of abnormal data. The hospital can determine whether the problem is with the patient, the device, or the data collection process. It also allows entities to file complaints against storage platforms, data providers, and data consumers who have engaged in improper behavior.

[0142] The process includes the steps of abnormal data detection and notification, record query and notification of the hospital server, data decryption and verification, device existence check and repair.

[0143] Abnormal data detection and notification step: After detecting abnormal data values, the data consumer notifies the corresponding edge node. Assuming that the data comes from the edge node, the data consumer provides the fingerprint of the data For confirmation.

[0144] Record query and notification of the hospital server step: After receiving the notification, the edge node searches for the corresponding record Then according to the certificate Will Send to the corresponding hospital server.

[0145] Data decryption and verification step: After the hospital server receives the encrypted data, it uses the key to decrypt it to obtain the original data

[0146] Device existence check and repair step: The hospital server first checks the first Bloom filter CBF1 and the second Bloom filter CBF2 to confirm the existence of the device. If the device does exist, the localization is successful and the subsequent process can proceed. In this step,

[0147] If the problem is with the data of the IoT device itself, the hospital sends staff to check and repair the device to ensure that the device is functioning properly and that data collection is no longer abnormal.

[0148] If the patient's medical data is abnormal: When the system detects abnormal data, the hospital's inspection can determine whether the abnormality is due to changes in the patient's own data. For example, if the same detection device shows normal data for other patients, but a patient's data is repeatedly abnormal, it may indicate that the patient has a specific health problem.

[0149] The doctor can use the group signature mechanism to verify that the data is indeed from the patient (through the patient's signature information), thereby excluding the source of the data error.

[0150] If there is an issue in the patient medical data collection process: If tampering or errors occur during data transmission or storage, the blockchain's tamper-proof nature will record the timestamp and signature of each operation. On the blockchain, the hospital server can trace back the data transmission path, ensuring the integrity of each stage through group signatures and hash values.

[0151] With the record and verification mechanism provided by the present application, the hospital can check any inconsistencies in the data collection, storage and uploading process. If the hash checksum and signature show that the data has been changed during transmission or storage, it can be confirmed that the problem lies in the process of data collection.

Claims

1. A method for medical data sharing and access control based on blockchain and edge computing, characterized in that, The initialization process, the data creation and uploading process, the data access and sharing process, and the data tracing and positioning process are included. In the initialization process, the cloud server and a plurality of edge nodes are combined to form a blockchain network, the hospital servers and data consumers are registered in the blockchain network, the data consumers perform a proxy re-encryption algorithm to generate a proxy re-encryption public / private key pair, and the doctors' terminals registered in the hospital servers generate public / private keys; the doctors' terminals also generate group signature parameters; the hospital servers send transactions to construct an access control contract, and the access control contract includes a policy information contract, a policy decision contract and a policy management contract; The hospital servers generate a symmetric encryption key; the policy information contract is used to record an attribute-based request format, the policy decision contract is used to determine the permission of an access request, and the policy management contract is used to record an access control policy set by a data provider; In the data creation and uploading process, the Internet of Things device collects patient data, the doctors' terminals customize an access control policy of the sharable patient data, the data containing the access control policy is sent to the hospital servers for storage after being signed by the doctors' terminals and the patient, the hospital servers perform data verification and desensitization, the data is encrypted by using the symmetric encryption key and is transmitted to the corresponding edge node in the blockchain network, and the edge node stores the data after verification; In the data access and sharing process, the data consumer accesses the policy information contract in the blockchain, constructs and sends an access request, the policy decision contract checks the correctness of the request format and obtains a final decision result, if the decision is passed, the corresponding hospital server is found, the hospital server calculates relevant information and sends it to the edge node, and the edge node sends the encryption to the data consumer; Assume that the patient is P i , the doctor is D id , and the data creation and uploading process is as follows: Step 2.1: IoT device detects patient P i , generates medical data m and sends medical data m along with device fingerprint hash Hash d to aggregator to assist its attending physician end D id in state analysis of patient P i ; Step 2.2: After the patient's visit, if the patient agrees, the doctor end D id Customized access control policy To ensure that the rules and conditions of data sharing are clear; wherein φ is a predicate operation for judging whether the rules are met; Indicates an aggregation operation; R t is a rule, t is a specific attribute involved in the construction of AAR; SB is the subject attribute, OB is the object attribute, OP is the operation attribute, and EN is the environment attribute; Step 2.3: Doctor's End D id Using the private key Dsk id Generate signature in For the doctor's signature algorithm, Hash d For fingerprints of IoT devices; patient P i Generate a group signature using the group signature key. The aggregator will include signed data containing access policies. The data is sent to the hospital server for storage; the PLC is the policy; and gppk is the group public key. For the patient's private key; Step 2.4: Hospital server verifies signature checking the presence of the loT device in the first count Bloom filter and the second count Bloom filter and de-identifying the collected patient data m to obtain de-identified data m Dd ; Step 2.5: The step of generating a proxy re-encryption key: the hospital server generates a random number Computing the proxy re-encryption key For encrypting the data sharing key DCk, we have where Gen(*) is a key generation algorithm, is the proxy re-encryption public key of the hospital, the subscript id is the identity ID of the hospital server computing the proxy re-encryption key server, is a finite field, Step 2.6: The hospital server generates de-identified data m Dd the hash value of m Encrypt m with data sharing key DCk Dd Encrypt with RDk and encrypt DCk using public key to obtain ​​ Step 2.7: The hospital server sends the encrypted data to the corresponding edge node, which verifies and stores the data, and returns the result to the hospital server. represents the entity certificate of the hospital server.

2. The method of claim 1, wherein, The data consumer includes an academic research institution, a medical service institution and a drug research and development center.

3. The method of claim 1, wherein, The attributes include subject attributes, object attributes, operation attributes and environment attributes.

4. The method of claim 1, wherein, Each doctor end runs the KeyGen algorithm of the group signature algorithm to generate group signature parameters for its group member patients; the doctor end obtains the private key gdsk of the group manager and the group member patients P i Then the corresponding private key gpsk i and the group public key gppk are obtained.

5. The method of claim 1, wherein, The hospital servers use a first count Bloom filter to record the fingerprints of the Internet of Things devices that are in normal operation, and use a second count Bloom filter to record the fingerprints of the Internet of Things devices that stop operating.

6. The method of claim 1, wherein, In the data creation and upload process, there is also a process of updating the policy, the hospital server sends a transaction containing to the policy management contract to update the policy.

7. The method of claim 1 or 6, wherein, In the data access and sharing process, the edge node / cloud server finds the corresponding hospital server according to the access request, and the hospital server generates a random number Compute X = g x A = g a B = g b , and compute s, the calculation formula is as follows: s is a signature value, wherein x, a and b are random numbers generated by the hospital servers, g is a generator, H(*) is a hash function, and r is a random number; the re-encryption key is calculated, and the calculation formula is as follows: The data tracing and positioning process is also included, and the process includes the following steps: Send {prk, X', capsule} to edge node, capsule = {A, B, s}, Data consumer's public key, For power operation, capsule represents the key fragments required for re-encryption; X' is an auxiliary key generated in the process of generating the re-encryption key; For hospital's proxy re-encryption private key; Edge node computes A' = A prk B' = B prk and sends encrypted data and {X, capsule '} to data consumer, capsule ' = {A ' , B ' , s}; Data consumer computing obtains decryption key Uses the key to decrypt the key Then uses DCk to decrypt the obtained m Dd Data, m Dd is de-identified data.

8. The method according to any one of claims 1 to 6, characterized in that, Step 4.1: After detecting an abnormal data value, the data consumer notifies the corresponding edge node of the situation; Step 4.4: The hospital server checks the first Bloom filter and the second Bloom filter to confirm the existence of the device, and if the device does exist, the positioning is successful. Step 4.2: After receiving the notification, the edge node searches the corresponding record Then according to the entity certificate of the hospital server Will Send to the corresponding hospital server; S DS For the original function; Step 4.3: Decryption and verification steps: After the hospital server receives the encrypted data, it decrypts it using the key to obtain the original data ​

Images