A medical data sharing and access control platform 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 platform based on a blockchain and edge computing, which comprises a multilayer data storage system, a blockchain network, an intelligent contract module, a plurality of data consumers, a plurality of data providers and a plurality of hospital servers. 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 the providers and the 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 platform 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: The cloud center or consumers may be interested in data or patient privacy.

[0008] (3) Profit-driven collusion: Consumers may 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 the daily work of doctors with limited computing power such as Internet of Medical Things (IoMT).

[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, non-tamperability, 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 platform based on blockchain and edge computing. The platform includes a multi-layer data storage system, a blockchain network, an intelligent contract module, a number of data consumers, a number of data providers, and a number of hospital servers.

[0022] The multi-layer data storage system is composed of a cloud server, a number of edge nodes, and a number of hospital servers. Multiple edge nodes are deployed in each region, and each edge node connects to multiple hospital servers in its responsible region. Each edge node is connected to the cloud server.

[0023] The blockchain network is composed of the cloud server and each edge node, and realizes data transmission. The hospital servers and data consumers registered in the blockchain network have blockchain access identities and permissions.

[0024] The smart contract module is used for managing an access control mechanism of a data consumer, and includes a policy information contract, a policy management contract and a policy decision contract, the policy information contract is used for recording an attribute-based request format, the policy decision contract is used for determining whether an access request meets a policy, and the policy management contract is used for recording an access control policy set by a data provider;

[0025] 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 a patient in the hospital and provides the medical data together with a device fingerprint hash value to the doctor terminal, and the doctor terminal is used for transmitting shareable medical data and an access control policy thereof to the hospital server;

[0026] The hospital server stores a mapping relationship between identity information of each doctor terminal and a public key thereof, device information of the Internet of Things device, shareable medical data and an access control policy thereof, and can generate a symmetric encryption key, upload data and calculate a service to support data sharing;

[0027] The edge node stores shareable medical data and an access control policy thereof after encryption and desensitization processing by the hospital server, and interacts with the hospital server to deliver the shareable medical data in a case where an access request of a data consumer is verified;

[0028] The cloud server is used for supporting remote work.

[0029] Further, the data consumer includes one or more of an academic research institution, a medical service institution and a drug research and development center.

[0030] Further, the attribute includes a subject attribute, an object attribute, an operation attribute and an environment attribute.

[0031] Further, the subject attribute includes a name and / or a position, the object attribute includes, for example, a file name and / or a data sensitivity level and / or a data type and / or a data format and / or a data source, the operation type includes reading and / or writing and / or editing and / or deleting and / or modifying, and the environment attribute includes an access time or an access location or a device type or a network security state or a data access purpose.

[0032] Further, the hospital server uses a first counting Bloom filter to record fingerprints of Internet of Things devices that are in normal operation, and uses a second counting Bloom filter to record fingerprints of Internet of Things devices that stop operating.

[0033] Further, the doctor terminal transmits shareable medical data and an access control policy thereof to the hospital server and saves the same to the edge node in the following specific method:

[0034] It is assumed that the shared medical data is from a patient P i, patient data is m, and the corresponding doctor side is D id Then the following steps are executed:

[0035] Step 2.1: Doctor side D id Custom access control policy PLC = {φ, (φ t , R t )|t∈Τ=SB∪OB∪OP∪EN} to ensure that the rules and conditions of data sharing are clear; wherein φ is a predicate operation for judging whether the rules are met; φ t represents 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;

[0036] Step 2.2: Doctor side D id uses the private key Dsk id to generate a signature wherein is the signature algorithm of the doctor side, Hash d is the fingerprint of the Internet of Things device; 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; PLC is the policy; is the patient private key;

[0037] Step 2.3: The hospital server verifies the signature checks the existence of the Internet of Things device in the first count Bloom filter and the second count Bloom filter, and performs desensitization processing on the collected patient data m to obtain desensitized data m Dd ;

[0038] Step 2.4: The hospital server generates a proxy re-encryption key: the hospital server generates a random number calculates the proxy re-encryption key for encrypting the data sharing key DCk, obtaining wherein Gen(*) is a key generation algorithm, is the hospital's proxy re-encryption public key, the subscript id is the identity ID of the hospital's proxy re-encryption key server, Z p is a finite field; ENC is an encryption function.

[0039] Step 2.5: The hospital server generates the hash value Dd of the desensitized data m encrypts m with the data sharing key DCkDd get encrypted with RDk get and use the public key encrypt DCk, get

[0040] Step 2.6: The hospital server sends the encrypted data to the edge node, which verifies the entity certificate of the hospital server and stores the data, and then returns the result to the hospital server. The entity certificate of the hospital server is represented. Further, the edge node interacts with the hospital server, and the specific method of transferring sharable medical data is as follows:

[0041] Further, the edge node interacts with the hospital server, and the specific method of transferring sharable medical data is as follows:

[0042] After the edge node finds the corresponding hospital server according to the access request, the hospital server 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:

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

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

[0045]

[0046] 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 parameters and signature required for the data consumer to decrypt; X' is an auxiliary key generated in the process of generating the re-encryption key; is the hospital's proxy re-encryption private key.

[0047] 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}.

[0048] Further, the data consumer calculates to obtain the decryption key Use the key to decrypt the key​​ Then the obtained m is decrypted using DCk Dd Data.

[0049] Further, the data consumer can also feed back abnormal data values to the edge node for abnormal positioning, and the specific method is:

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

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

[0052] Step 4.3: decryption and verification step: 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;

[0053] Step 4.4: The hospital first 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.

[0054] Further, the strategy management contract can update the strategy, and the specific method is: the hospital server sends a transaction containing To the strategy management contract to update the strategy.

[0055] The beneficial effects of the present application are:

[0056] 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.

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

[0058] 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.

[0059] 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.

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

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

[0062] The application will be described in detail below in combination with specific embodiments.

[0063] The platform described in the application comprises 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.

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

[0065] 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 is deployed with multiple edge nodes.

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

[0067] Each edge node stores sharable medical data and its access control strategy after encryption and desensitization processing by the hospital server, and interacts with the hospital server to deliver sharable medical data under the condition that the access request of the data consumer is verified.

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

[0069] (2) Blockchain network

[0070] The multi-layer data storage system is composed of a cloud server, a plurality of edge nodes, and a plurality of hospital servers. Multiple edge nodes are deployed in each region, each edge node connects 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 blockchain access identities and permissions. Each edge node and the cloud server cooperate with each other through a consensus mechanism (such as the Byzantine fault-tolerant consensus algorithm, PBFT) to jointly maintain a safe and reliable automated execution platform. The main functions of the 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, enabling it to respond to malicious behavior and network failures, ensuring stable operation of the entire system and the safety of data.

[0071] (3) Smart contract module

[0072] 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 environment 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 reading and / or writing and / or editing and / or deleting and / or modifying; and environment attributes include access time or access location or device type or network security status or data access purpose.

[0073] (4) Data provider

[0074] The data provider is composed of an Internet of Things device and a doctor's end connected in communication with the hospital server. The Internet of Things device collects medical data of patients in the hospital and provides it together with the device fingerprint hash value to the doctor's end. The doctor's end transmits shareable 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 often rely on external hospital collaboration platforms to share personal health data to obtain better medical services while ensuring personal privacy protection and maintaining autonomous ownership. These data mainly come from medical Internet of Things devices, and these devices are often potential targets of 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.

[0075] (5) Data consumer

[0076] The data consumer includes one or several of academic research institutions, medical service institutions, and pharmaceutical research centers. Important participants in data sharing include academic research institutions and medical service institutions, etc., 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 control.

[0077] The data consumer has a blockchain identity and the right to access the blockchain; the data consumer accesses the policy information contract in the blockchain, builds and sends an access request to request, obtain, and analyze shared data, and can feed back the results.

[0078] The operation process of the application is described in detail below.

[0079] It includes an initialization process, a data creation and uploading process, a data access and sharing process, and preferably a data tracing and positioning process. Each process is described below.

[0080] I. Initialization process

[0081] 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. Hospitals and patients establish access control policies.

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

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

[0084] The step of entity registration: the entities include data providers and data consumers. Data providers include hospital servers, and 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 and obtain a blockchain identity B idand the permission to access the blockchain. Assume that its certificate is C id , the blockchain identity is B id , and the certificate authority records the mapping relationship (C id , B id ).

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

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

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

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

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

[0090] OP: operation type, such as all or one of read, write, edit, delete, modify, and the like.

[0091] EN: environmental condition, such as all or one of access time, access location, device type, network security state, and data access purpose.

[0092] Attribute-based request format: AAR. Each access request in the system contains a related attribute set.

[0093] Specific Case:

[0094] Researcher Alice accesses the file <heart rate.txt> in the hospital server through her personal computer. The specific steps are as follows:

[0095] Step 1: Alice requests PIC: Alice requests the format of the access request (AAR) from PIC.

[0096] Step 2: Construct AAR: Alice constructs the following access request (AAR):

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

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

[0099] PDC requires PAC to send the relevant access policy (PLC) according to the file name <heart rate.txt>.

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

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

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

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

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

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

[0106] (Time, not null), Note: Time is not null (i.e. needs to specify the time range).

[0107] }

[0108] Step 4: PDC Decision Execution: The PDC executes the decision function J(AAR, PLC) to determine whether Alice can access the file based on her request and the set of policies.<heart rate.txt> .

[0109] Steps to generate a doctor's public / private key pair: Each doctor's terminal D id Having its own Elliptic Curve Digital Signature Algorithm (ECDSA) public key Dpk id Private key Dsk id The corresponding hospital server records the mapping relationship (D). id Dpk id ).

[0110] The steps to generate group signature parameters: Each doctor's end D id The KeyGen(n) algorithm, a group signature algorithm, is run to generate group signature parameters for the doctor's patients, where n represents the number of patients the doctor is responsible for. The doctor receives the group administrator's private key gdsk, and the group member patient P... i Then obtain the corresponding private key gpsk i We also learned the group public key gppk. i represents the user ID. The hospital server records the mapping relationship (D). id (gdsk, gppk).

[0111] The steps for recording IoT device information are as follows: The hospital server records information for all IoT device IoMTs (Internet of Things). To improve query efficiency, two count Bloom filters (first count Bloom filter and second count Bloom filter) are used to determine the presence of devices. The first count Bloom filter records the fingerprints (hash values) of normally functioning IoT device IoMTs, which is used to quickly determine whether the queried device belongs to the currently valid devices, avoiding invalid queries. The second count Bloom filter records the fingerprints (hash values) of inactive IoT device IoMTs, used to determine whether the device has stopped working, avoiding unnecessary queries for retired devices. The device fingerprint is generated based on the device's unique attribute information. Commonly used device attribute information includes:

[0112] Unique identifiers of the device (such as MAC address, device serial number)

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

[0114] Network information (such as IP address)

[0115] Other specific equipment parameters (such as equipment type, manufacturer information, etc.)

[0116] The steps for generating a symmetric encryption key are as follows: The hospital server runs a key generation algorithm to generate symmetric encryption keys DCk and PDk. DCk is used for data sharing, and PDk is used to store the original data.

[0117] II. Data Creation and Upload Process

[0118] At this stage, Internet of Things (IoMT) devices detect patients and generate sensor data. An aggregator receives this data and reviews it with the doctor. The doctor discusses the data with the patient and generates access control policies. This data, along with the policies, is then sent to a local hospital server for storage, where it is encrypted and anonymized before being transmitted to edge nodes in the region.

[0119] The process includes steps such as data detection and transmission, defining access control policies, generating signatures and transmitting data, data verification and de-identification, generating proxy re-encryption keys, data encryption and transmission, data storage, and updating policies. In this embodiment, the policy is uploaded to the Hyperledger Fabric chaincode via fabric-sdk-go and stored on the blockchain. The hospital server uses the AES algorithm to generate a symmetric key and uses Golang to implement proxy re-encryption, ensuring that doctors can specify who can decrypt the data. The goPBC library in Golang is used to generate a re-encryption key and perform secondary encryption on the data. The encrypted data is uploaded to edge nodes for storage, and the policy information is recorded in the blockchain to ensure data security. Doctors can implement corresponding functions through web pages or mini-programs. React (web page) / React Native (app) is used to provide an interactive interface for doctors, facilitating policy setting, signing, and data uploading. Node.js or Python provides API services to handle operations such as signing, encryption, and policy uploading. The PyCryptodome library in Python is used for ECDSA and BBS04 group signatures. Equip the backend with a database (such as MongoDB or PostgreSQL) to store non-sensitive metadata or operation logs.

[0120] Data detection and transmission steps: Internet of Things (IoMT) devices detect patient P i Generate data m and combine it with the device fingerprint hash value. d Send them together to the aggregator to assist Doctor D. id Perform patient P i State analysis.

[0121] Steps for developing access control policies: After the patient's visit, the doctor will communicate with the patient's P... iThe issue of data sharing is discussed. If the patient's consent is obtained, the doctor's corresponding client (D)... id Custom access control policies will be implemented with it. This ensures that the rules and conditions for data sharing are clearly defined. Here, φ represents the predicate operation used to determine whether the rules are met. Represents an aggregation operation; such as and, or, t-out-of-n; R t For each rule, t represents a specific attribute involved in constructing the AAR, such as user role, resource type, access time, etc.

[0122] Steps for generating signatures and transmitting data: Doctor's side D id Using the private key Dsk id Generate signature in Hash is the signature algorithm for doctors. d For fingerprints used in IoT devices. Patient P i Generate a group signature using the group signature key. The aggregator will include signed data containing access policies. It is sent to the hospital's server for storage.

[0123] Data verification and anonymization steps: The hospital server first verifies the signature. The presence of IoT devices in the first and second count Bloom filters is checked, and the collected patient data m (such as sensitive information like name, ID number, contact number, age, etc.) is anonymized to obtain anonymized data m. Dd This is to facilitate subsequent uploading to edge nodes.

[0124] The steps for the hospital server to generate the proxy re-encryption key are as follows: The hospital server generates random numbers a, b∈Z p (Z p (A finite field, which can be used to generate random numbers) Calculate the proxy re-encryption key And use K to encrypt the data sharing key DCk, thus obtaining Where Gen(*) is the key generation algorithm. The public key is used to re-encrypt the proxy key for the hospital server, and the subscript id represents the identity ID of the hospital server.

[0125] The steps of data encryption and transmission: 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 get and use the public key encrypt DCk, get

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

[0127] Update strategy step: the hospital server sends a transaction containing to the PAC to update the strategy PLC. For example, update the visitor identity, etc.

[0128] III. Data access and sharing process

[0129] 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.

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

[0131] Data consumer requests access: data consumers (such as academic research institutions, medical service institutions, etc.) access the PIC contract in the blockchain, which discloses the attribute set.

[0132] Constructing access request step: the data consumer constructs an 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.

[0133] Verify format and request policy step: 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 etc. Then, the PDC verifies whether the AAR satisfies the access policy φ represents the aggregation operation, R represents the predicate operation, and t R represents the rule set. Specifically, the PDC first traverses all rules R t For each rule, call the RuleCheck function to determine the attribute t of the SB, OB, OP, EN attribute set in the request, ​​If the attribute value is within the range specified by the corresponding rule, 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 contained in the request sent by the visitor meet the access conditions. Aggregate the results φ operation (such as and, or, etc. operation), to get the final access decision. If all conditions in the AAR built by the data consumer are met, the final decision result is True, indicating that the access request meets the policy, and the PDC will return True; otherwise, return False.

[0134] Step of determining the corresponding hospital server: After the edge node / cloud server receives the result of the access request meeting the decision in the blockchain, it generates a random number x∈Z Find the corresponding hospital server.

[0135] Step of transmission by the hospital server: 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, the calculation formula is as follows:

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

[0137] s is a signature value 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, 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:

[0138]

[0139] An auxiliary key X' will be 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 and is used in the decryption step in the re-encryption process, further ensuring that only authorized consumers can decrypt the data.

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

[0141] Edge node computes and transmits the step: edge node computes A' = A prk , B' = B prk

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

[0143] Data consumer decrypts data step: data consumer computes to obtain decryption key using the key to decrypt the key Then use DCk to decrypt the obtained m Dd Data. m Dd is de-identified data.

[0144] Four, data traceability and positioning process

[0145] At this stage, based on blockchain and group signature, the present application provides a method for tracing 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 with improper behavior.

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

[0147] 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.

[0148] Record query and notification of hospital server step: after receiving the notification, the edge node searches for the corresponding record Then according to the certificate send to the corresponding hospital server.

[0149] Data decryption and verification step: after receiving the encrypted data, the hospital server decrypts it using the key to obtain the original data

[0150] 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 positioning is successful and the subsequent process can be carried out. In this step,

[0151] If the problem is with the data from the IoT device itself, the hospital dispatches staff to inspect and repair the device, ensuring that the device is functioning properly and that data collection is no longer anomalous.

[0152] If the problem is with the patient’s medical data: When the system detects anomalous data, inspection by the hospital can determine whether the anomaly is due to changes in the patient’s data itself. For example, if the same detection device is showing normal data for other patients, but a particular patient’s data is repeatedly anomalous, this can suggest that the patient has a particular health issue.

[0153] The doctor can use the group signature mechanism to verify that the data is indeed from the patient (through the patient’s signature information), thus ruling out the source of the data error.

[0154] If the problem is with the patient’s medical data collection process: If tampering or errors occur during data transmission or storage, the blockchain’s tamper-proof nature records 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.

[0155] Through the recording and verification mechanism provided by the present application, 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 platform based on blockchain and edge computing, characterized in that, The platform includes a multi-layered data storage system, a blockchain network, a smart contract module, several data consumers, several data providers, and several hospital servers; 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 region, each edge node is connected to multiple hospital servers in its region, and each edge node is connected to the cloud server. The blockchain network is composed of cloud servers and various edge nodes to realize data transmission; hospital servers and data consumers registered within the blockchain network have blockchain access identities and permissions. The smart contract module is used to manage the access control mechanism for data consumers. It 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 data provider consists of an IoT device and a doctor's terminal that are connected to the hospital server. The IoT device collects the medical data of patients in the hospital and provides it to the doctor's terminal along with the device fingerprint hash value. The doctor's terminal is used to transmit the shareable medical data and its access control policies to the hospital server. Each hospital server stores the mapping relationship between the doctor's identity information and its public key, the device information of IoT devices, shareable medical data and its access control policies, and can generate symmetric encryption keys, upload data, and compute services to support data sharing. Each edge node stores shareable medical data and its access control policies after being encrypted and de-identified by the hospital server. When the access request of the data consumer is verified, it interacts with the hospital server to transfer the shareable medical data. The data consumer can execute the proxy re-encryption algorithm to generate a public / private key pair for proxy re-encryption; Cloud servers are used to support remote work.

2. The platform as described in claim 1, characterized in that, Data consumers include one or more academic research institutions, medical service institutions, and drug research and development centers.

3. The platform as described in claim 1, characterized in that, The attributes include subject attributes, object attributes, operation attributes, and environment attributes.

4. The platform as described in claim 3, characterized in that, Subject attributes include name and / or job title; object attributes include file name and / or data sensitivity level and / or data type and / or data format and / or data source; operation type includes read and / or write and / or edit and / or delete and / or modify; environment attributes include access time or access location or device type or network security status or data access purpose.

5. The platform as described in claim 1, characterized in that, The hospital server uses a first count Bloom filter to record the fingerprints of normally functioning IoT devices and a second count Bloom filter to record the fingerprints of IoT devices that have stopped functioning.

6. The platform as described in claim 1, characterized in that, The specific method by which the doctor transmits shareable medical data and its access control policies to the hospital server and saves it to the edge node is as follows: Assume that the shared medical data originates from patient P. i Patient data is m, and the corresponding doctor data is D. id Then perform the following steps: Step 2.1: Doctor's End D id Custom access control strategy PLC = {φ, (φ t R t )|t∈Τ=SB∪OB∪OP∪EN} to ensure that the rules and conditions for data sharing are clear; where φ is the predicate operation for judging whether the rules are satisfied; φ t 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. Step 2.2: 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 strategy; and gppk is the group public key. For the patient's private key; Step 2.3: 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 ; Step 2.4: The hospital server generates 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. Z represents the hospital's proxy re-encryption public key, where id is the identity ID of the server that calculates the proxy re-encryption key for the hospital. p For a finite field, ENC is the encryption function; Step 2.5: 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 RDk is a symmetric encryption key; Step 2.6: The hospital server encrypts the data. The data is sent to the edge node, which verifies the entity certificate of the hospital server. After storing the data, the results are returned to the hospital server; This refers to the physical certificate of the hospital server.

7. The platform as described in claim 6, characterized in that, The specific method by which edge nodes interact with hospital servers to transfer shareable medical data is as follows: After the edge node finds the corresponding hospital server based on the access request, the hospital server generates a random number x∈Z. p Calculate X = g x A = g a B = g b Calculate s using the following formula: 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 the random number; the re-encryption key is calculated using the following formula: Send {prk,X',capsule} to the edge node, where capsule = {A,B,s}. Public key of data consumer The exponentiation is used; the capsule represents the parameters and signature required for data consumer decryption; X' is the auxiliary key generated during the process of generating the re-encryption key. Re-encrypt the private key for the hospital's agent; Edge node calculation A' = A prk ,B'=B prk And send encrypted data and {X,capsule ' For data consumers, capsule ' ={A ' B ' ,s}.

8. The platform as described in claim 7, characterized in that, Data consumer calculates and obtains decryption key Use this key to decrypt the key Then use DCk to decrypt the obtained m Dd data.

9. The platform as described in claim 7, characterized in that, Data consumers can also report abnormal data values ​​to edge nodes for anomaly localization. The specific method is as follows: Step 4.1: After detecting abnormal data values, the data consumer notifies the corresponding edge nodes of this situation; Step 4.2: After receiving the notification, the edge node searches for the corresponding record. Then according to the certificate 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. S DS It is a primitive function; Step 4.4: The hospital first checks the first and second Bloom filters to confirm the existence of the device. If the device is indeed present, the location is successful.

10. The platform as described in claim 7, characterized in that, The strategy management contract can update the strategy, specifically by the hospital server sending a message containing... The transactions are sent to the strategy management contract to update the strategy.

Images