Medical data sharing and access control method based on block chain and edge computing

Abstract

The invention relates to the technical field of data security and privacy protection, in particular to a block chain and edge computing-based medical data sharing and access control method, which comprises an initialization process, a data creation and uploading process, a data access and sharing process and a data tracing and positioning process. According to the invention, the calculation and communication overhead in data transmission of the medical internet of things is reduced, and the sharing efficiency and security requirements of the medical data between a provider and a consumer can be met.

Description

Technical Field

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

[0002] With the rapid development of medical technology and information technology, the generation and sharing of medical data has become increasingly important in the field of healthcare, which not only affects people's quality of life, but also has a profound impact on the security of economically developing countries. In order to effectively respond to public health challenges, cross-regional data sharing is usually required for comprehensive analysis, but the data of a single hospital is often insufficient to provide complete information and cannot fully reflect the health status of the entire region, making it difficult to meet the needs of public health prediction and optimal allocation of medical resources. For example, epidemic prediction introduces a global defense system that relies on data sharing in multiple regions. Internet of Medical Things (IoMT) continuously generates and collects patients' health data, including physiological and pathological information, to support 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 cross-regional medical data sharing, breaking through the limitations of traditional data management models. The integration of these technologies is reshaping the way medical data is managed and used, creating new opportunities for more accurate medical predictions and more efficient public health responses.

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

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

[0005] ② Poor security: In a complex medical data sharing environment where no entity can be fully trusted, data security faces multiple sources of risk, each of which may 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 leakage: The cloud center or consumers may be interested in the privacy of data or patients.

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

[0009] ③ Accountability: Defensive measures alone cannot completely prevent malicious behavior. 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 may be three types of potential malicious entities:

[0010] (1) Provider: For example, data may come from a hacked Internet of Medical Things (IoMT) device or be leaked due to a doctor’s error.

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

[0012] (3) Cloud centers: They may be curious about shared data and there may even be a risk of improper use.

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

[0014] At the same time, attribute-based encryption (ABE) technology has been widely used in flexible and fine-grained access control. This technology assigns different access rights according to different attributes of users, which has significant advantages in protecting data privacy and identity privacy. However, the implementation of ABE usually requires a lot of computing resources. For devices with limited computing power such as Internet of Medical Devices (IoMT), its high computing requirements limit its practical application in doctors' daily diagnosis and treatment work.

[0015] On the other hand, as a trustworthy distributed computing and storage paradigm, blockchain ensures the security of the medical data sharing system and strengthens the ability to hold malicious behavior accountable with its decentralized, tamper-proof and traceable characteristics. Through blockchain technology, medical data can be safely shared among multiple institutions without relying on a single central institution. In addition, the application of smart contracts further realizes the automation and transparency of data access control and sharing processes.

[0016] However, existing medical data sharing schemes rarely consider the three issues of efficiency, security, and accountability at the same time. Therefore, it is necessary to propose an access control scheme that can share medical data securely and efficiently in an untrusted environment.

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

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

[0019] 1. Using RSA public keys to encrypt and decrypt data is a computationally expensive operation. If the amount of data is large or the data needs to be shared frequently, this method may lead to performance bottlenecks. Especially in the medical Internet of Things environment, the real-time requirements of data are 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 mechanisms to ensure that only designated hospitals can decrypt and obtain patients' health data, it does not clearly state how to prevent other entities or malicious actors from posing as authorized hospitals to access the data. If an attacker can obtain or impersonate the hospital's public key, this may lead to data leakage.

[0020] 2. It is not clear how to anonymize patient data during data sharing. The lack of a clear anonymization method may lead to the leakage of sensitive information, especially when the data is widely shared. Although the patent mentions the use of blockchain to record transactions, it does not mention how the system can track the source of data errors. Summary of the invention

[0021] The present invention aims to overcome the limitations of the existing technology 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 several edge nodes form a blockchain network, each hospital server and data consumer registers in the blockchain network, the data consumer and each doctor end registered in the hospital server generate public / private keys, and each doctor end also generates a group signature parameter; 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 upload process, IoT devices collect patient data, and the doctor customizes the access control policy for the sharable patient data. The data containing the access control policy is signed by the doctor and the patient and sent to the hospital server for storage. The hospital server verifies and desensitizes the data, encrypts the data using a symmetric encryption key, and transmits it to the corresponding edge node in the blockchain network. The edge node stores the data after successful verification.

[0024] In the data access and sharing process, data consumers access the policy information contract in the blockchain, build and send access requests, and the policy decision contract checks the correctness of the request format and draws the final decision result. If the decision is passed, the corresponding hospital server is found, and the hospital server calculates the relevant information and sends it to the edge node, which then sends the encrypted information to the data consumer.

[0025] Furthermore, data consumers include academic research institutions, medical service institutions, and drug research and development centers.

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

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

[0028] Furthermore, each doctor runs the KeyGen algorithm of the group signature algorithm to generate group signature parameters for its group member patients; the doctor will obtain the private key gdsk of the group manager and the private key P i Then get the corresponding private key gpsk i And the group public key gppk.

[0029] Furthermore, the hospital server uses a first counting Bloom filter to record fingerprints of IoT devices that are operating normally, and uses a second counting Bloom filter to record fingerprints of IoT devices that have stopped operating.

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

[0031] Step 2.1: IoT device detects patient P i , generate medical data m, and hash the medical data m with the device fingerprint Hash d Sent together to the aggregator to assist its doctor end D id Patient P i Status analysis;

[0032] Step 2.2: After the patient's consultation, if the patient agrees, the doctor will id Customizing access control policies To ensure that the rules and conditions for data sharing are clear; where φ is the predicate operation to determine whether the rules are met; Represents an aggregation operation; R t is a rule, t is a specific attribute involved in constructing 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 D id Use the private key Dsk id Generate signature in The signature algorithm for the doctor side, Hash d The fingerprint of the IoT device; the patient P i Generate a group signature using the group signature key The aggregator will contain the signature data of the access policy Sent to the hospital server for storage; PLC is the strategy;

[0034] Step 2.4: Hospital server verifies signature Check the existence of the IoT device in the first counting Bloom filter and the second counting Bloom filter, and desensitize the collected patient data m to obtain desensitized data m Dd ;

[0035] Step 2.5: Steps to generate proxy re-encryption key: Hospital server generates random number Compute proxy re-encryption key The shared key DCk used to encrypt data is obtained Where Gen(*) is the key generation algorithm, is the hospital's proxy re-encryption public key, and the subscript id is the identity ID of the server that calculates the proxy re-encryption key on the hospital server. is a finite field,

[0036] Step 2.6: The hospital server generates desensitized data m Dd Hash value Encrypt m with the data sharing key DCk Dd have to Encryption with RDk have to And use the public key Encrypt DCk and get

[0037] Step 2.7: The hospital server will encrypt the data Send to the corresponding edge node, and the edge node verifies After storing the data, the results are returned to the hospital server; Indicates the entity certificate of the hospital server.

[0038] Furthermore, the data creation and upload process also includes the process of updating the policy. The hospital server sends a The transaction is given to the strategy management contract to update the strategy.

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

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

[0041] Where x, a, and b are random numbers generated by the hospital server, g is the generator, H(*) is the hash function, and r is a random number. The re-encryption key is calculated using the following formula:

[0042]

[0043] Send {prk,X',capsule} to the edge node, capsule = {A,B,s}, The public key of the data consumer, is a power operation, capsule represents the key fragment required for re-encryption; X' is the auxiliary key generated in the process of generating the re-encryption key;

[0044] The edge node calculates A′=A prk ,B'=B prk And send encrypted data and {X, capsule′} to data consumers, capsule′={A′,B′,s};

[0045] Data consumers calculate and obtain decryption keys Use this key to decrypt the key Then use DCk to decrypt the obtained m Dd Data,m Dd This is desensitized data.

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

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

[0048] Step 4.2: After receiving the notification, the edge node searches for 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 receiving the encrypted data, the hospital server uses the key to decrypt it to obtain the original data

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

[0051] Beneficial effects of the present invention:

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

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

[0054] 3. The blockchain-based verifiable and traceable anonymization scheme designed by the present invention 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 IoT medical devices.

[0055] 4. The present invention 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 about by centralized trust.

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

[0057] 6. The present invention uses the traceability of blockchain and smart contracts to record all access operations within the system, ensuring that malicious visitors can be tracked and held accountable. DETAILED DESCRIPTION

[0058] The present invention is described in detail below with reference to specific embodiments.

[0059] The platform on which the method described in the present invention operates includes a multi-layer data storage system, a blockchain network, a smart contract module, a number of data consumers, a number of data providers, and a number of hospital servers.

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

[0061] Multi-layer data storage system: It consists of cloud servers, several edge nodes, and several hospital servers; each edge node is connected to several hospital servers in its area, and each edge node is connected to the cloud server. Multiple edge nodes are deployed in each area with multiple hospital servers.

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

[0063] Each edge node stores the sharable medical data and its access control policy after being encrypted and desensitized by the hospital server, and interacts with the hospital server to transmit the sharable medical data when the access request of the data consumer is verified.

[0064] Cloud servers are used to support remote work and provide backup for data of all edge nodes.

[0065] (2) Blockchain Network

[0066] The multi-layer data storage system consists of a cloud server, several edge nodes, and several hospital servers; multiple edge nodes are deployed in each area, each edge node is connected to multiple hospital servers in its responsible area, and each edge node is connected to a cloud server. Hospital servers and data consumers registered in the blockchain network have blockchain access identities and permissions. Each edge node and cloud server collaborates with each other through a consensus mechanism (such as the Byzantine Fault Tolerant Consensus Algorithm, PBFT) to jointly maintain a secure and reliable automated execution platform. The main functions of the platform include storing and managing various access control policies, while implementing fine-grained access control through the automatic execution of smart contracts. This mechanism not only prevents unauthorized access, but also ensures that data always maintains a high degree of security and integrity during transmission and sharing. In addition, the distributed nature and consensus mechanism of the platform make it highly fault-tolerant, able to deal with malicious behavior and network failures, and ensure the stable operation of the entire system and the security of 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 request format based on attributes, 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 environmental attributes. Subject attributes include name and / or position; object attributes include file name and / or data sensitivity level and / or data type and / or data format and / or data source; operation types include read and / or write and / or edit and / or delete and / or modify; environmental attributes include access time / or access location / or device type / or network security status / or data access purpose.

[0069] (4) Data Provider

[0070] The data provider consists of an IoT device and a doctor's end that are connected to the hospital server. The IoT device collects the medical data of hospital patients and provides it to the doctor's end together with the device fingerprint hash value. The doctor's end transmits the sharable medical data and its access control policy to the hospital server. The patient data collected by the IoT device can also be stored on 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 IoT devices, which are often targets of potential attacks due to their technical characteristics. Such attacks may lead to data leakage and misuse, which in turn may cause actual physical harm to patients and even threaten their lives.

[0071] (5) Data Consumers

[0072] Data consumers include one or more academic research institutions, medical service institutions, and drug research and development centers. Important entities 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 are not only to provide personalized medical advice, but also to play a key role in epidemic early warning and public health security. By deeply analyzing the data, these institutions can identify potential health threats and take timely countermeasures to help improve the efficiency of public health management and disease prevention and control.

[0073] The data consumer has a blockchain identity and the authority to access the blockchain; the data consumer accesses the policy information contract in the blockchain, constructs and sends access requests for requesting, obtaining and analyzing shared data, and can feedback the results.

[0074] The process included in the method of the present invention is described in detail below.

[0075] It includes the initialization process, data creation and upload process, data access and sharing process, and preferably also includes data tracing and positioning process. Each process is described below.

[0076] 1. Initialization process

[0077] In this phase, all entities build basic system models and generate cryptographic parameters. Cloud servers and edge nodes run a consortium blockchain that supports smart contracts, using the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm. Hospitals and patients establish access control policies.

[0078] The initialization process includes the steps of building a blockchain network, entity registration, data consumer generating a proxy re-encryption key, building a contract, generating a doctor's public / private key pair, generating group signature parameters, recording IoT device information, and generating a symmetric encryption key.

[0079] Steps to build a blockchain network: Cloud servers and edge nodes are responsible for forming a consortium blockchain network. The blockchain only allows authorized entities to send transactions to deploy or run smart contracts. In order to ensure data consistency, the PBFT consensus algorithm is used.

[0080] Entity registration steps: The entities include data providers and data consumers. Data providers include hospital servers, and data consumers include academic research institutions, medical service institutions, and drug research and development centers. These entities use their certificates C id Register with the certificate authority to obtain blockchain identity B id And the authority to access the blockchain. Assume that its certificate is C id , blockchain identity is B id , the certificate authority record mapping relationship (C id , B id ).

[0081] Steps for data consumers to generate proxy re-encryption keys: If data consumers want to obtain medical shared data, they execute the PRE.KeyGen algorithm of the proxy re-encryption algorithm to generate a public / private key pair (ppk, psk) for proxy re-encryption.

[0082] Steps to build a contract: The hospital server sends a transaction for building an access control contract, including a Policy Information Contract (PIC), a Policy Determination Contract (PDC), and a Policy Administration Contract (PAC). PIC records the attribute-based request format, PDC runs an algorithm to determine whether the access request meets the policy, and PAC records the access control policy PLC set by the hospital, which is the access policy for doctors and patients in this embodiment. The policy (PLC) defines a set of predicate operations used to determine whether the access request meets the policy conditions.

[0083] In this application, the four attributes SB, OB, OP, and EN together constitute the system attribute set, 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 elements constitute the attribute-based access request AAR.

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

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

[0086] OP: Operation type, such as read, write, edit, delete, modify, etc. All or one of them.

[0087] EN: Environmental conditions, such as access time, access location, device type, network security status, data access purpose, etc. All or one of them.

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

[0089] Specific examples:

[0090] Researcher Alice accesses files on the hospital server from her personal computer<heart rate.txt> The specific steps are as follows:

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

[0092] Step 2: Build AAR: Alice builds 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 PDC.

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

[0095] PDC requires PAC to identify the file name<heart rate.txt> Send the relevant access policy (PLC).

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

[0097] PIC = {"and", Note: Ensure that multiple conditions are met at the same time;

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

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

[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 4: PDC executes the decision: PDC runs the decision function J(AAR,PLC) to determine whether Alice can access the file based on her request and the policy set.<heart rate.txt> .

[0105] Steps to generate a doctor's public / private key pair: Each doctor's D id Have your own elliptic curve digital signature algorithm (ECDSA) public key Dpk id 、Private key Dsk id . Corresponding hospital server record mapping relationship (D id , Dpk id ).

[0106] Steps for generating group signature parameters: Each doctor terminal 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 the doctor is responsible for. The doctor will obtain the private key gdsk of the group manager and the private key P of the group member patient. i Then get the corresponding private key gpsk i , and also know the group public key gppk. i is the user number. The hospital server records the mapping relationship (D id , gdsk, gppk).

[0107] Steps to record IoT device information: The hospital server records the information of all IoT devices IoMT. In order to improve query efficiency, two counting Bloom filters (first counting Bloom filter and second counting Bloom filter) are used to determine the existence of the device, where the first counting Bloom filter records the fingerprint (hash value) of the IoT device IoMT that is operating normally. It is used to quickly determine whether the queried device belongs to the current valid device to avoid invalid queries. The second counting Bloom filter records the fingerprint (hash value) of the IoT device IoMT that has stopped working, which is used to determine whether the device has stopped working to avoid redundant queries for retired devices. The fingerprint of the device is generated based on the unique attribute information of the device. Commonly used device attribute information includes:

[0108] Unique identifier of the device (e.g. 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] Steps for generating symmetric encryption keys: The hospital server runs a key generation algorithm to generate symmetric encryption keys DCk and RDk, where DCk is used for data sharing and RDk is used to store original data.

[0113] 2. Data creation and upload process

[0114] At this stage, the IoT medical device (IoMT) detects the patient and generates sensory data. The aggregator will receive this data and review it with the doctor. The doctor will discuss with the patient and generate an access control policy. Then, this data along with the policy is sent to the local hospital server for storage, encrypted and desensitized, and then transmitted to the edge node in the region.

[0115] The process includes the steps of data detection and transmission, the steps of formulating access control policies, the steps of generating signatures and data transmission, the steps of data verification and desensitization, the steps of generating proxy re-encryption keys, the steps of data encryption and transmission, the steps of data storage, and the steps of updating policies. 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 uses the AES algorithm to generate symmetric keys and uses Golang to implement proxy re-encryption to ensure that doctors can specify who can decrypt the data. The re-encryption key is generated using Golang's goPBC library and the data is encrypted twice. The encrypted data is uploaded to the edge node for storage, and the policy information is recorded in the blockchain to ensure data security. The doctor side can implement the corresponding functions through web pages or applets. React (Web page) / React Native (APP) is used to provide an interactive interface for the doctor side, which is convenient for doctors to set policies, sign and upload data. Node.js or Python provides API services to handle operations such as signing, encryption, and policy upload. Use Python's PyCryptodome library for ECDSA and BBS04 group signatures. A database (such as MongoDB or PostgreSQL) is used at the back end to store non-sensitive metadata or operation logs.

[0116] Steps of data detection and transmission: The Internet of Things device (IoMT) detects the patient’s P i , generate data m and compare it with the device fingerprint hash value Hash d Sent together to the aggregator to assist doctor D id Patient P i status analysis.

[0117] Steps to developing an access control strategy: After the patient's visit, the doctor will talk to the patient i Discuss the issue of data sharing. If the patient agrees, the doctor’s corresponding doctor terminal D id Customize access control policies To ensure that the rules and conditions for data sharing are clear. Among them, φ is the predicate operation to determine 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] Steps for generating signature and data transmission: Doctor side D id Use the private key Dsk id Generate signature in The signature algorithm for doctors, Hash d The fingerprint of the IoT device. i Generate a group signature using the group signature key The aggregator will contain the signature data of the access policy Sent to the hospital server for storage.

[0119] Data verification and desensitization steps: The hospital server first verifies the signature Check the existence of the IoT device in the first counting Bloom filter and the second counting Bloom filter, and desensitize the collected patient data m (such as name, ID number, contact number, age and other sensitive information) to obtain desensitized data m Dd , to facilitate subsequent upload to the edge node.

[0120] The steps for the hospital server to generate the proxy re-encryption key are as follows: The hospital server generates a random number a, b∈Z p (Z p is a finite field that can be used to generate random numbers) and calculate the proxy re-encryption key And use K to encrypt the data shared key DCk, Among them, Gen(*) is the key generation algorithm, It is the proxy re-encryption public key of the hospital server, and the subscript id represents the identity ID of the hospital server.

[0121] Data encryption and transmission steps: The hospital server generates desensitized data m Dd Hash value Encrypt m with the data sharing key DCk Dd have to Encryption with RDk have to And use the public key Encrypt DCk and get

[0122] Data storage steps: The hospital server will encrypt the data Send to edge node, edge node verification After storing the data, the results are returned to the hospital server. Indicates the entity certificate of the hospital server.

[0123] Steps to update the policy: The hospital server sends a The transaction is used to update the PAC policy PLC. For example, update the visitor identity, etc.

[0124] 3. Data access and sharing process

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

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

[0127] Steps for data consumers to request access: Data consumers (such as academic research institutions, medical service institutions, etc.) access the PIC contract in the blockchain, which discloses the attribute set.

[0128] Steps to construct an access request: The data consumer constructs an access request AAR and its own proxy re-encryption public key based on its own attributes. The transaction is then sent to the PDC contract on the blockchain.

[0129] Steps to verify format and request strategy: The PDC contract checks the correctness of the request format and verifies the request based on the fingerprint of the data. Then, PDC verifies whether AAR satisfies the access policy. φ represents the aggregation operation, Represents a predicate operation, R t Represents a set of rules. Specifically, PDC first traverses all rules R t For each rule, the RuleCheck function is called to determine the attribute t of the SB, OB, OP, EN attribute set in the request. Determine whether its attribute value is within the range specified by the corresponding rule. If it is satisfied, return True, otherwise return False. The result of each rule check (True or False) will be added to the result set. After all rules are checked, call the FinalCheck function to determine whether all attributes contained in the request sent by the visitor meet the access conditions. Perform aggregation φ operations (such as AND, OR, etc.) on all results to obtain the final access decision. If all conditions in the AAR constructed by the data consumer meet the decision, the final decision result is True, indicating that the access request complies with the policy, and PDC will return True; otherwise, it returns False.

[0130] Steps to determine the corresponding hospital server: After the edge node / cloud server receives the access request in the blockchain and the decision result is met, it uses the public key of the data consumer Find the corresponding hospital server.

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

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

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

[0134]

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

[0136] The hospital server sends {prk,X',capsule} to the edge node, capsule = {A,B,s}. The public key of the data consumer, The capsule represents the parameters and signature required for data consumers to decrypt and ensure secure data transmission.

[0137] Steps of edge node calculation and transmission: Edge node calculates A′=A prk ,B′=B prk

[0138] And send encrypted data and {X, capsule′} to the data consumer, capsule′={A′,B′,s}.

[0139] Steps for data consumers to decrypt data: Data consumers calculate and obtain the decryption key Use this key to decrypt the key Then use DCk to decrypt the obtained m Dd Data.m Dd This is desensitized data.

[0140] 4. Data tracing and positioning process

[0141] At this stage, based on blockchain and group signature, the present invention provides a method to track the source of abnormal data. Hospitals can determine whether there is a problem with the patient, the equipment, or the data collection process. It also allows entities to file complaints against storage platforms, data providers, and data consumers with improper behavior.

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

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

[0144] Steps for record query and notification to hospital server: After receiving the notification, the edge node will search for the corresponding records Then according to the certificate Will Send to the corresponding hospital server.

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

[0146] Device existence check and repair steps: 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 location is successful and the subsequent process can be carried out. In this step,

[0147] If there is a problem with the data of the IoT device itself, the hospital will send staff to inspect and repair the equipment to ensure that the equipment operates normally and that data collection no longer has abnormalities.

[0148] If the patient's medical data is abnormal: When the system detects abnormal data, the hospital can determine whether the abnormality is caused by changes in the patient's own data through examination. For example, if the same testing equipment performs normally for other patients' data, but a patient's data is repeatedly abnormal, it may indicate that the patient has a specific health problem.

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

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

[0151] Through the recording and verification mechanism provided by the present invention, the hospital can check for any inconsistencies in the data collection, storage and upload 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 data collection process.

Claims

1. A medical data sharing and access control method based on blockchain and edge computing, characterized in that: Including initialization process, data creation and upload process, data access and sharing process, data tracing and positioning process; In the initialization process: the cloud server and several edge nodes form a blockchain network, each hospital server and data consumer registers in the blockchain network, the data consumer and each doctor end registered in the hospital server generate public / private keys, and each doctor end 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; In the data creation and upload process, IoT devices collect patient data, and the doctor customizes the access control policy for the sharable patient data. The data containing the access control policy is signed by the doctor and the patient and sent to the hospital server for storage. The hospital server verifies and desensitizes the data, encrypts the data using a symmetric encryption key, and transmits it to the corresponding edge node in the blockchain network. The edge node stores the data after successful verification. In the data access and sharing process, data consumers access the policy information contract in the blockchain, build and send access requests, and the policy decision contract checks the correctness of the request format and draws the final decision result. If the decision is passed, the corresponding hospital server is found, and the hospital server calculates the relevant information and sends it to the edge node, which then sends the encrypted information to the data consumer.

2. The method according to claim 1, characterized in that Data consumers include academic research institutions, medical service agencies, and drug research and development centers.

3. The method according to claim 1, characterized in that The policy information contract is used to record the attribute-based request format, the policy decision contract is used to determine the permissions for access requests, and the policy management contract is used to record the access control policies set by the data provider.

4. The method according to claim 3, characterized in that The attributes include subject attributes, object attributes, operation attributes, and environment attributes.

5. The method according to claim 3, characterized in that Each doctor runs the KeyGen algorithm of the group signature algorithm to generate group signature parameters for its group member patients; the doctor will obtain the private key gdsk of the group manager and the private key P i Then get the corresponding private key gpsk i And the group public key gppk.

6. The method according to claim 1, characterized in that The hospital server uses the first counting Bloom filter to record the fingerprints of IoT devices that are operating normally, and uses the second counting Bloom filter to record the fingerprints of IoT devices that have stopped operating.

7. The method according to claim 4, characterized in that Assume that the patient is P i , the doctor end is D id , the data creation and upload process is as follows: Step 2.1: IoT device detects patient P i , generate medical data m, and hash the medical data m with the device fingerprint Hash d Sent together to the aggregator to assist its doctor end D id Patient P i Status analysis; Step 2.2: After the patient's consultation, if the patient agrees, the doctor will id Customizing access control policies To ensure that the rules and conditions for data sharing are clear; where φ is the predicate operation to determine whether the rules are met; Represents an aggregation operation; R t is a rule, t is a specific attribute involved in constructing 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 D id Use the private key Dsk id Generate signature in The signature algorithm for the doctor side, Hash d The fingerprint of the IoT device; the patient P i Generate a group signature using the group signature key The aggregator will contain the signature data of the access policy Sent to the hospital server for storage; PLC is the strategy; Step 2.4: Hospital server verifies signature Check the existence of the IoT device in the first counting Bloom filter and the second counting Bloom filter, and desensitize the collected patient data m to obtain desensitized data m Dd ; Step 2.5: Steps to generate proxy re-encryption key: Hospital server generates random number Compute proxy re-encryption key The shared key DCk used to encrypt data is obtained Where Gen(*) is the key generation algorithm, is the hospital's proxy re-encryption public key, and the subscript id is the identity ID of the server that calculates the proxy re-encryption key on the hospital server. is a finite field, Step 2.6: The hospital server generates desensitized data m Dd Hash value Encrypt m with the data sharing key DCk Dd have to Encryption with RDk have to And use the public key Encrypt DCk and get Step 2.7: The hospital server will encrypt the data Send to the corresponding edge node, and the edge node verifies After storing the data, the results are returned to the hospital server; Indicates the entity certificate of the hospital server.

8. The method according to claim 7, characterized in that The data creation and upload process also includes the process of updating the policy. The hospital server sends The transaction is given to the strategy management contract to update the strategy.

9. The method according to claim 7 or 8, characterized in that In the data access and sharing process, after the edge node / cloud server finds the corresponding hospital server according to the access request, the hospital server generates a random number Calculate X = g x ,A=g a ,B=g b , calculate s, the calculation formula is as follows: s=b+r·H(A||B) Where x, a, and b are random numbers generated by the hospital server, g is the generator, H(*) is the hash function, and r is a random number. The re-encryption key is calculated using the following formula: Send {prk,X',capsule} to the edge node, capsule = {A,B,s}, The public key of the data consumer, is a power operation, capsule represents the key fragment required for re-encryption; X' is the auxiliary key generated in the process of generating the re-encryption key; The edge node calculates A′=A prk ,B′=B prk And send encrypted data and {X, capsule′} to data consumers, capsule′={A′,B',s}; Data consumers calculate and obtain decryption keys Use this key to decrypt the key Then use DCk to decrypt the obtained m Dd Data,m Dd This is desensitized data.

10. The method according to any one of claims 1 to 8, characterized in that: It also includes the data tracing and positioning process, which includes the following steps: Step 4.1: After detecting an abnormal data value, the data consumer notifies the corresponding edge node of this situation; Step 4.2: After receiving the notification, the edge node searches for the corresponding record Then according to the entity certificate of the hospital server Will Send to the corresponding hospital server; Step 4.3: Decryption and verification steps: After receiving the encrypted data, the hospital server uses the key to decrypt it to obtain the original data Step 4.4: The hospital server checks the first Bloom filter and the second Bloom filter to confirm the existence of the device. If the device does exist, the positioning is successful.

Images