Blockchain and homomorphic encryption-based medical data sharing privacy protection system

Abstract

The present application relates to the technical field of computer information security and medical data processing, and particularly relates to a medical data sharing privacy protection system based on a blockchain and homomorphic encryption, which comprises a data representation and preprocessing layer, an access control and task execution layer, and a result trusted guarantee layer. The preprocessing layer maps original data to a specific mathematical structure according to medical data semantic features and target computing tasks through implicit computable coding, and adapts to standard homomorphic operation. The access control layer defines fine-grained access strategies and dynamically generates task binding tokens in combination with attribute-based encryption and smart contracts. The result guarantee layer realizes lightweight computing result verification by fusing verification labels and threshold secret sharing technology. Under the premise of guaranteeing the privacy and security of medical data, the system improves data sharing adaptability and result credibility, and is suitable for medical data alliance collaborative sharing scenarios.

Description

Technical Field

[0001] This invention relates to the interdisciplinary field of computer information security and medical data processing, and more specifically, to a privacy protection system for medical data sharing based on blockchain and homomorphic encryption. Background Technology

[0002] Medical data sharing is a core support for promoting medical research and innovation and optimizing clinical diagnosis and treatment services. However, it contains patients' private information and needs to be protected during the sharing process. This need has driven medical data privacy protection technology to become a research hotspot in the industry.

[0003] Existing technologies have significant shortcomings: traditional encryption schemes require decryption before computation can be performed, failing to balance data sharing efficiency and privacy security; some homomorphic encryption schemes require custom-designed circuits for complex medical calculations, resulting in poor adaptability and low computational efficiency; access control is mostly coarse-grained authorization, making it difficult to match the diverse permission requirements in medical scenarios such as "hospital level, research field, and ethical status"; furthermore, verification of computation results often requires repeated homomorphic operations, leading to time-consuming, labor-intensive, and costly practices. In addition, existing solutions lack a dynamic binding mechanism between computational tasks and access permissions, making them prone to the risk of permission abuse.

[0004] To address the aforementioned technical challenges, this invention proposes a medical data sharing privacy protection system based on blockchain and homomorphic encryption. Through a layered architecture design and deep integration with core encryption, access control, and verification technologies, it achieves privacy security, precise permissions, and reliable results in medical data sharing. Summary of the Invention

[0005] In view of the shortcomings of existing technologies, the purpose of this invention is to provide a privacy protection system for medical data sharing based on blockchain and homomorphic encryption.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A privacy protection system for sharing medical data based on blockchain and homomorphic encryption includes a data representation and preprocessing layer, an access control and task execution layer, and a result trust assurance layer.

[0008] The data representation and preprocessing layer adopts a data preprocessing method based on implicitly computable encoding. Before data encryption, the original medical data is encoded and mapped to a specific mathematical structure according to the semantic features of the medical data and the target computation task, so that the subsequent standard homomorphic encryption operation corresponds to medically meaningful computation.

[0009] The access control and task execution layer adopts a tokenized access control method based on attribute-based encryption and smart contracts. Attribute-based encryption defines fine-grained access policies, and blockchain smart contracts verify the legality of tasks and the matching of access attributes. Homomorphic computation tokens bound to tasks are dynamically generated, and data nodes provide encrypted data and pre-computed verification tags after verifying the tokens.

[0010] The result trust assurance layer adopts a lightweight computation result verification mechanism based on fusion verification tags. The computation node returns the encrypted result and the aggregated verification tag. The randomly selected verification node partially decrypts and verifies the tag through threshold secret sharing technology to confirm the correctness of the result.

[0011] Furthermore, the implementation process of the data representation and preprocessing layer is as follows:

[0012] A task description library is maintained. Each supported analysis task in the library corresponds to a set of predefined medical feature extraction functions and target medical calculation functions. The entries in the task description library include task identifier, applicable medical data types, input and output specifications of medical feature extraction functions, and operation logic of target medical calculation functions. When data nodes share data, feature vectors are first extracted from the original medical data through the corresponding medical feature extraction functions, and then subsequent encoding and mapping are carried out according to the operation logic of the target medical calculation functions, so that the preprocessing process is accurately matched with the medical calculation task.

[0013] Furthermore, the implementation method of the encoding mapping is as follows:

[0014] For each analysis task and the selected homomorphic encryption scheme, an invertible mapping function from the medical feature space to a specific algebraic structure is designed so that the target medical computation function can be transformed into a standard homomorphic operation on the algebraic structure. When the target medical computation function is a linear or low-order polynomial function, the corresponding homomorphic operation after mapping is only ciphertext addition or a small number of multiplication operations, so there is no need to customize a dedicated homomorphic computation circuit for complex medical computations.

[0015] Furthermore, the implementation process of attribute-based encryption in the access control and task execution layer is as follows:

[0016] The system employs a ciphertext policy attribute-based encryption scheme, where an authoritative institution generates public and private key components based on bilinear pairings. The access policy uses a Boolean expression where attribute field == attribute value, supporting AND / OR logic combinations. The attribute field is a predefined field specific to the medical scenario. The data owner encrypts and stores the data key or core decryption parameters using the ciphertext policy attribute-based encryption public key and the access policy, achieving fine-grained access control for medical data.

[0017] Furthermore, the method for generating the homomorphic computation token is as follows: the smart contract uses a secure cryptographic hash function to perform a hash operation on the task's unique identifier, the allowed homomorphic operation descriptor, the data storage index, the timestamp, and a random number to generate a token; before generating the token, the smart contract first verifies whether the attribute set of the computing node meets the corresponding access policy, and only issues the token after the verification is passed, and the random number is generated by the contract's deterministic pseudo-random number generator to ensure that the token cannot be reused, thereby binding the token to the computing task.

[0018] Furthermore, the implementation process of the verification tag in the result trust assurance layer is as follows:

[0019] When a data node generates encrypted data, it selects a random vector with the same dimension as the medical feature vector, calculates the inner product of the random vector and the medical data as the verification value, encrypts the verification value using the same public key and parameters as the data encryption, generates a verification tag, and stores it in association with the encrypted data. When a computing node performs homomorphic operations to obtain the result ciphertext, it performs a linear aggregation operation on the verification tags of multiple data nodes that is completely corresponding to the data operation, and generates an aggregated verification tag.

[0020] Furthermore, the method for selecting the verification node is as follows:

[0021] First, a verification node pool is constructed. The node pool consists of authorized nodes in the consortium blockchain that meet the preset computing power and reputation value requirements. The computing power and reputation value are set according to the security requirements of the medical data processing scenario. The smart contract uses the hash value of the current block as a random seed to uniformly and randomly sample verification nodes from the verification node pool to ensure the randomness and reliability of the selection of verification nodes.

[0022] Furthermore, the implementation process of the threshold secret sharing technology is as follows:

[0023] During the system initialization phase, a private key share is allocated to the verification nodes through a distributed key generation protocol. During the verification process, the selected verification node uses its own private key share to partially decrypt the aggregated verification tag and submits the partial decryption result to the blockchain. After the smart contract collects at least a preset threshold number of valid partial decryption results, it recovers the complete verification plaintext through the Lagrange interpolation algorithm, compares it with the inner product result of the decrypted ciphertext, and completes the verification of the calculation result without repeating the homomorphic calculation.

[0024] Compared with the prior art, the present invention has the following beneficial effects:

[0025] 1. A preprocessing method using implicitly computable encoding is employed, and invertible mapping functions are designed for different medical analysis tasks. This transforms medical computations into standard homomorphic operations on algebraic structures, eliminating the need for customized computational circuits. This design not only hides the computational intent through encoding, ensuring semantic privacy of medical data, but also improves the adaptability of homomorphic encryption to medical tasks, avoiding efficiency losses caused by complex circuit designs. It effectively solves the problems of existing homomorphic encryption schemes being difficult to adapt to medical scenarios and having low computational efficiency.

[0026] 2. This system integrates attribute-based encryption with smart contract-based tokenized access control. Fine-grained policies are defined using Boolean expressions ("attribute field == attribute value"), supporting AND / OR logic combinations to precisely match diverse permission requirements in medical scenarios. Simultaneously, the smart contract generates a unique task token after verifying attribute matching, enabling dynamic binding of permissions and tasks. This mechanism avoids the risk of permission abuse associated with coarse-grained authorization and strengthens security through the non-reusable nature of tokens, addressing the technical shortcomings of existing access control systems, such as insufficient precision and the inability to decouple permissions from tasks. Attached Figure Description

[0027] Figure 1 A block diagram of a privacy protection system for sharing medical data based on blockchain and homomorphic encryption;

[0028] Figure 2 This is a flowchart illustrating the implementation of the data representation and preprocessing layer of the present invention.

[0029] Figure 3 This is a flowchart illustrating the implementation of the access control and task execution layer of this invention.

[0030] Figure 4 This is a flowchart illustrating the implementation of the reliability assurance layer for the results of this invention. Detailed Implementation

[0031] Example, refer to Figure 1 The medical data sharing privacy protection system based on blockchain and homomorphic encryption in this embodiment includes a data representation and preprocessing layer, an access control and task execution layer, and a result trust guarantee layer.

[0032] Data Representation and Preprocessing Layer: Based on implicitly computable coding, this data preprocessing method maps the semantic features of medical data to specific mathematical structures before encryption, according to the target computational task. This allows subsequent standard homomorphic encryption operations to naturally correspond to medically meaningful computations, thereby hiding the computational intent and improving efficiency. For example... Figure 2 As shown, the specific implementation process is as follows:

[0033] To optimize the efficiency of specific medical computing tasks and protect the computational intent, this invention pre-encrypts the original medical data vector before standard homomorphic encryption. Perform preprocessing encoding;

[0034] Step S101, Medical Feature Extraction and Task Association:

[0035] The system maintains a task description library, which lists each supported analysis task. Corresponding to a predefined medical feature extraction function and a target computation function For example, for tasks assessing trends in blood glucose control, It can extract blood glucose value sequences over multiple consecutive days, and This can be a function that calculates a moving average or trend slope. This occurs when data nodes are ready to share data to support a task. When, first apply Obtain the feature vector .

[0036] The construction rules for the task description library are as follows: Each task entry in the library includes a task ID, applicable medical data types, and... Input / output field specifications The operational logic; function examples for different medical tasks:

[0037] Hypertension risk assessment task: Extract systolic / diastolic blood pressure sequences, age, BMI, and family medical history markers; For a predefined logistic regression scoring function, take the feature vector as input and output the risk level.

[0038] ECG rhythm analysis task: Extract the RR interval sequence and QRS wave width; This is a function for calculating heart rate variability.

[0039] Step S102: Mapping to a homomorphic-friendly mathematical structure:

[0040] Design a method to map a medical feature space to a certain algebraic structure. (e.g., polynomial ring) Invertible mapping function of ) The design of this mapping is crucial and must satisfy the following conditions for the task: Target medical computing There exists a ring "Standard" calculations This makes the equation true:

[0041] ;

[0042] in, and This is a standard homomorphic encryption algorithm. This means that the encoded data... Homomorphic encryption is used to obtain Then, in the ciphertext Perform standard homomorphic operations (Such as ciphertext addition and multiplication), the result obtained after decryption is exactly the required medical calculation result. .

[0043] The core of implicitly computable coding lies in designing invertible mapping functions. medical feature vectors Mapping to homomorphic friendly algebraic structures (e.g., polynomial rings). For linear or low-order polynomial medical computation functions, the mapping function can be directly constructed through linear transformation or low-order polynomial interpolation; for nonlinear or high-order functions, piecewise polynomial approximation, Taylor series expansion, or feature embedding based on neural networks can be used to approximate the original function into standard operations on an algebraic structure.

[0044] The specific design process is as follows:

[0045] (1) Task analysis: Defining the target medical calculation function The mathematical form and computational logic;

[0046] (2) Structure selection: Select a suitable algebraic structure based on the characteristics of homomorphic encryption schemes (such as CKKS and BFV). ;

[0047] (3) Mapping construction: Design an invertible mapping , making The above can be represented as a standard homomorphic operation. ;

[0048] (4) Reversibility verification: ensure There is an inverse mapping And can recover medical significance from the calculation results;

[0049] The existence of mapping functions depends on the continuity of the medical computation function and the expressive power of its algebraic structure. For most medical computation functions with smoothness properties, mapping functions that meet the conditions can be constructed using the above methods. The system pre-sets mapping function templates for common tasks in the task description library and supports dynamically adding mapping rules for new tasks;

[0050] Specific design example of the mapping function: Taking the blood glucose control trend task as an example, the feature vector , To determine the number of consecutive monitoring days, the algebraic structure is selected. , Let be a secure prime number for a homomorphic encryption scheme, determined by the security parameters of the CKKS / BFV scheme. The specific form is:

[0051] ;

[0052] Its inverse mapping To extract the polynomial coefficients, i.e. ( ).

[0053] The encoding mapping relationship is as follows:

[0054] ;

[0055] in, Represents the medical feature vector space; Indicates the task Designed from eigenvectors to algebraic structures medium elements The mapping function; for The inverse mapping will The elements in the code are decoded back into the feature space; For in algebraic structures A set of homomorphic operations (such as addition and multiplication) defined above, whose combination corresponds to the encryption of data. The execution; These are post-processing functions that may be needed (such as rounding and standardization).

[0056] Determination method: function and For each task It is designed in conjunction with a selected homomorphic encryption scheme (such as CKKS or BFV). Typically, When the function is linear or a low-order polynomial, efficient methods can be constructed. , making This method involves only encrypted additions or a small number of multiplications. It eliminates the need to custom-design homomorphic computing circuits for complex medical calculations; computing nodes simply perform standard, efficient homomorphic operations. Without needing to know its medical meaning.

[0057] Access Control and Task Execution Layer: A tokenized access control method based on attribute-based cryptography and smart contracts is employed. Attribute-based cryptography (ABE) defines fine-grained access policies, which are verified by the blockchain smart contract, which dynamically generates homomorphic computation tokens bound to the task. After verifying the token, data nodes provide encrypted data and a pre-computed verification tag. For example... Figure 3 As shown, the specific implementation process is as follows:

[0058] Step S201, Policy Definition and Key Generation:

[0059] Authoritative organizations (entities recognized by the Medical Data Sharing Alliance and possessing data security management qualifications, such as medical data management institutions under the National Health and Family Planning Commission or third-party electronic certification institutions approved by the National Information Security Management Agency) define attribute-based access policies. .For example, The data owner uses the public key of the ABE encryption scheme. and strategy Symmetric key for data Alternatively, other key parameters used to decrypt the final result can be encrypted to obtain ciphertext. And store it in a blockchain or distributed storage;

[0060] Specific implementation rules for the ABE scheme:

[0061] Scheme type: Ciphertext policy attribute base encryption (CP-ABE);

[0062] Public key generation: based on bilinear pairing (elliptic curve) ), by an authoritative organization through safety parameters generate: , A component of the private key of an authoritative institution;

[0063] Strategy Syntax rules: Use Boolean expressions of "attribute field == attribute value", supporting AND / OR logical operations; attribute fields are predefined system fields, such as hospital level, research field, ethical status, etc., and attribute values ​​are the legal values ​​of the corresponding fields, such as top-tier hospital, cardiovascular, approved, etc.

[0064] Step S202, Task Request and Token Generation:

[0065] A computing node sends a computing task request to a blockchain smart contract, declaring its attribute set in the request. and task description The smart contract executes the following logic:

[0066] a. Verification Legality:

[0067] Legality verification standards: It must include the task ID, target data type, and expected computation operation type. Three required fields; check during validation:

[0068] (1) The task ID is not duplicated;

[0069] (2) The target data type belongs to the medical data types supported by the system (such as blood glucose data, electrocardiogram data);

[0070] (3) Expected calculation operation type It belongs to a predefined set of homomorphic operations (such as ciphertext addition and low-order ciphertext multiplication).

[0071] b. Judgment Does it meet the strategy corresponding to the target data? ;

[0072] c. If the verification passes, the contract generates a unique homomorphic computation token bound to this task. The token contains the task ID and the allowed operation type. (corresponding to) ), data index, timestamp, and a temporarily generated random number. ;

[0073] d. The contract will The necessary verification parameters (such as partial feature hashes of the expected result) are recorded on the blockchain, and the token is sent to the computing node;

[0074] The token generation logic is as follows:

[0075] ;

[0076] in, A secure cryptographic hash function (such as SHA-256);

[0077] A unique task identifier assigned by a smart contract;

[0078] This refers to the standard operation descriptor defined in step S102;

[0079] This indicates the off-chain storage index of the requested ciphertext data;

[0080] Indicates the current timestamp;

[0081] This represents a random number generated by the smart contract to ensure the uniqueness of the token;

[0082] This represents the ABE attribute matching validation function;

[0083] Value selection criteria: All input parameters are obtained from blockchain transaction and contract states. Generated by a deterministic pseudorandom number generator of the contract.

[0084] The result reliability assurance layer is based on a lightweight computation result verification mechanism using fused verification tags. Computation nodes return encrypted computation results and aggregated verification tags. A group of randomly selected verification nodes use threshold secret sharing technology to partially decrypt and verify the tags, thereby confirming the correctness of the result with high probability and low cost. Figure 4 As shown, the specific implementation process is as follows:

[0085] Step S301, Verify tag generation and distribution:

[0086] Data nodes are processing data. Generate homomorphic ciphertext At the same time, calculate a verification label The tag is generated using the linear homomorphism of homomorphic encryption. Specifically, a random vector is selected. (or a fixed vector), calculate the data The dot product with this vector is used as the verification value. Then, use encryption. The same public key and parameters, for Homomorphic encryption is performed to obtain the ciphertext of the verification tag. .Will With ciphertext Associated storage;

[0087] random vector Parameter rules:

[0088] Dimension: Similar to medical feature vectors The dimensions are consistent;

[0089] Value range: , Consistent with the secure prime number of homomorphic encryption schemes;

[0090] Generation method: Generated by smart contract At that time, the hash value of the previous block is used as the seed to generate a cryptographically secure pseudo-random number generator (CSPRNG); the fixed vector is only used in low-security scenarios, and its value is a predefined public vector of all 1s. .

[0091] Step S302, Aggregation Calculation and Tag Return:

[0092] The compute node obtains ciphertext from multiple data nodes. and its corresponding tags Then, execute the homomorphic operation specified in the contract. Obtain the encrypted result Furthermore, due to the linear nature of homomorphic encryption, performing the exact same linear aggregation operation (denoted as ) on the tag... ), which can obtain aggregated verification tags The computing nodes will Submit to the blockchain;

[0093] The specific relationship between the generation and aggregation of verification tags is as follows:

[0094]

[0095]

[0096]

[0097] in, It is a pre-agreed or smart contract-issued random vector that serves as a "challenge" for verification;

[0098] Indicates inner product operation; Indicates and The corresponding linear aggregation operation performed on the verification label;

[0099] Determination method: Vector It can be randomly generated by a smart contract when generating tokens and included in the token, ensuring the independence of each verification.

[0100] Step S303, Threshold decryption verification:

[0101] The smart contract received Then, a set of nodes is randomly selected from the verification node pool (e.g., Threshold scheme); each selected verification node Using the private key share it holds right Partial decryption was performed, and a partial decryption result was obtained. and submit it to the blockchain;

[0102] Verification node pool and selection rules:

[0103] Verification node pool: Composed of authorized nodes in the consortium blockchain that meet the following criteria: computing power ≥ 1 CPU core, reputation score ≥ 90 points (based on historical verification behavior scoring); the reputation score is determined as follows:

[0104] Scoring indicators and quantification rules:

[0105] Verification accuracy: defined as the number of tasks that were correctly verified divided by the total number of verification tasks assigned, with a weight of 60%.

[0106] Response speed: Requires a response within 30 seconds of task assignment and verification completion within 10 minutes; weight 20%.

[0107] Malicious behavior: Forging verification results, leaking encrypted information, and intentionally delaying responses beyond the threshold are clearly defined as malicious behavior, which will trigger an immediate deduction of points, with a weight of 20%.

[0108] Deduction or reinstatement rules:

[0109] Deductions: 10 points per instance for verification accuracy <80%; 5 points per instance for response or verification timeout; 20 points per instance for malicious behavior (minimum deduction of 60 points per instance).

[0110] Recovery: 5 points per round for completing 10 consecutive valid verifications (accuracy ≥ 95% and response meets the standard);

[0111] Selection method: Using the hash value of the current blockchain block as a random seed, uniform random sampling is performed to select... Nodes ( The value is usually set according to the system size. );

[0112] Threshold setting: (like hour, The private key share is generated during system initialization via the Distributed Key Generation (DKG) protocol;

[0113] The threshold decryption and verification are as follows:

[0114]

[0115]

[0116] ;

[0117] The specific implementation of the threshold decryption algorithm: This invention adopts a scheme combining Shamir threshold secret sharing with CKKS homomorphic encryption.

[0118] : Verification Node Use your own private key share ,right Performing component-level modular multiplication on the (CKKS ciphertext) yields a partial decryption result. ;

[0119] Collect at least indivual Then, the complete plaintext is calculated using Lagrange interpolation. :

[0120] ;

[0121] in, To verify the node The identifier value, The set of nodes participating in the decryption;

[0122] This represents the threshold part decryption algorithm for homomorphic encryption schemes;

[0123] Indicates verification node The share of private keys held;

[0124] For a combination function, when a sufficient number of ( ) effective At that time, the plaintext can be recovered. ;

[0125] This represents the set of verification node indices that participated in the partial decryption;

[0126] Value selection criteria: Threshold and the total number of verification nodes According to the system security model preset, for example Private key shares are generated during system initialization using the Distributed Key Generation (DKG) protocol.

[0127] If the equation If true, it proves that the computing node correctly performed the aggregation calculation. The entire verification process requires only one lightweight threshold decryption and one inner product calculation, without repeating the entire homomorphic calculation, and without leaking the original data.

[0128] Through the detailed description of the above embodiments, the medical data sharing privacy protection system based on blockchain and homomorphic encryption of the present invention constructs a full-process medical data sharing system encompassing privacy protection, access control, and result reliability through a layered architecture and collaborative core technologies. The data preprocessing layer overcomes the compatibility bottleneck between homomorphic computation and medical computing, the access control layer strengthens fine-grained access security, and the result assurance layer balances reliability and efficiency with lightweight verification. The system deeply integrates the decentralized and reliable characteristics of blockchain, the privacy computing capabilities of homomorphic encryption, and the precise authorization advantages of attribute-based encryption, effectively solving problems such as the imbalance between privacy protection and sharing efficiency, imprecise access control, and labor-intensive result verification in existing technologies. It provides secure and reliable technical support for medical data alliance sharing and cross-institutional medical research, facilitating the compliant release of medical data value.

[0129] The above formulas are all dimensionless calculations, and the preset parameters in the formulas should be set by those skilled in the art according to the actual situation.

[0130] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0131] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0132] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0133] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0134] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0135] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A medical data sharing privacy protection system based on blockchain and homomorphic encryption, characterized in that, It includes a data representation and preprocessing layer, an access control and task execution layer, and a result reliability assurance layer; The data representation and preprocessing layer employs a data preprocessing method based on implicitly computable encoding. Before data encryption, it maps the original medical data to a specific mathematical structure based on the semantic features of the medical data and the target computational task, ensuring that subsequent standard homomorphic encryption operations correspond to medically meaningful calculations. The implementation process of the data representation and preprocessing layer is as follows: Maintain a task description library. Each supported analysis task in the library corresponds to a set of predefined medical feature extraction functions and target medical calculation functions. The entries in the task description library include task identifier, applicable medical data types, input and output specifications of the medical feature extraction functions, and operation logic of the target medical calculation functions. When data nodes share data, feature vectors are first extracted from the original medical data through the corresponding medical feature extraction functions, and then subsequent encoding and mapping are carried out according to the operation logic of the target medical calculation functions to ensure that the preprocessing process is accurately matched with the medical calculation task. The access control and task execution layer adopts a tokenized access control method based on attribute-based encryption and smart contracts. Attribute-based encryption defines fine-grained access policies, and blockchain smart contracts verify the legality of tasks and the matching of access attributes. Homomorphic computation tokens bound to tasks are dynamically generated, and data nodes provide encrypted data and pre-computed verification tags after verifying the tokens. The implementation process of attribute-based encryption is as follows: a ciphertext policy attribute-based encryption scheme is adopted, and an authoritative institution generates public and private key components based on bilinear pairing; the access policy adopts a Boolean expression of attribute field == attribute value, supporting AND / OR logic combination, where the attribute field is a predefined field specific to the medical scenario; the data owner stores the data key or core decryption parameters after encrypting them with the ciphertext policy attribute-based encryption public key and the access policy, thereby realizing fine-grained access control of medical data; The method for generating the homomorphic computation token is as follows: the smart contract generates a token by performing a hash operation on the unique identifier of the task, the allowed homomorphic operation descriptor, the data storage index, the timestamp, and the random number using a secure cryptographic hash function. Before the token is generated, the smart contract first verifies whether the attribute set of the computing node meets the corresponding access policy. The token is only issued after the verification is passed. The random number is generated by the contract's deterministic pseudo-random number generator to ensure that the token cannot be reused and to bind the token to the computing task. The result trust assurance layer adopts a lightweight computation result verification mechanism based on fusion verification tags. The computation node returns the result ciphertext and aggregate verification tags. The randomly selected verification node partially decrypts and verifies the tags through threshold secret sharing technology to confirm the correctness of the result. The verification tag implementation process is as follows: When a data node generates encrypted data, it selects a random vector with the same dimension as the medical feature vector, calculates the inner product of the random vector and the medical data as the verification value, encrypts the verification value using the same public key and parameters as the data encryption, generates a verification tag, and stores it in association with the encrypted data; when a computing node performs homomorphic operations to obtain the result ciphertext, it performs a linear aggregation operation on the verification tags of multiple data nodes that is completely corresponding to the data operation, and generates an aggregated verification tag.

2. The medical data sharing privacy protection system based on blockchain and homomorphic encryption according to claim 1, characterized in that, The implementation method of the encoding mapping is as follows: For each analysis task and the selected homomorphic encryption scheme, an invertible mapping function from the medical feature space to a specific algebraic structure is designed so that the target medical computation function can be transformed into a standard homomorphic operation on the algebraic structure. When the target medical calculation function is a linear or low-order polynomial function, the corresponding homomorphic operation after mapping is only ciphertext addition or a small number of multiplication operations, so there is no need to customize a dedicated homomorphic calculation circuit for complex medical calculations.

3. The medical data sharing privacy protection system based on blockchain and homomorphic encryption according to claim 1, characterized in that, The method for selecting the verification node is as follows: First, a verification node pool is constructed. The node pool consists of authorized nodes in the consortium blockchain that meet the preset computing power and reputation value requirements. The computing power and reputation value are set according to the security requirements of the medical data processing scenario. The smart contract uses the hash value of the current block as a random seed to uniformly and randomly sample verification nodes from the verification node pool to ensure the randomness and reliability of the selection of verification nodes.

4. The medical data sharing privacy protection system based on blockchain and homomorphic encryption according to claim 1, characterized in that, The implementation process of the threshold secret sharing technology is as follows: During the system initialization phase, a private key share is allocated to the verification nodes through a distributed key generation protocol. During the verification process, the selected verification node uses its own private key share to partially decrypt the aggregated verification tag and submits the partial decryption result to the blockchain. After the smart contract collects at least a preset threshold number of valid partial decryption results, it recovers the complete verification plaintext through the Lagrange interpolation algorithm, compares it with the inner product result of the decrypted ciphertext, and completes the verification of the calculation result without repeating the homomorphic calculation.

Images