Internet of Things medical privacy data attribute matching function encryption method and device, equipment and medium

Abstract

The invention relates to an attribute matching function encryption method, device and equipment for Internet of Things medical privacy data and a medium, and the method comprises the steps: sending a system global public key parameter and a medical data sender access strategy expected by a medical data receiver to a cloud server, and carrying out the cloud server based on the system global public key parameter and an authentication ciphertext component, attribute matching verification is carried out on the ciphertext set uploaded by the medical data sender and an expected medical data sender access strategy provided by the medical data receiver, and if matching succeeds, the successfully matched ciphertext set is sent to the medical data receiver; the medical data receiver inputs the received ciphertext set based on the decryption key of the medical data receiver, verifies whether the attribute of the medical data receiver meets the access strategy of the medical data receiver in the ciphertext set or not, and if the attribute of the medical data receiver meets the access strategy of the medical data receiver in the ciphertext set, decrypts the inner product privacy calculation result of the medical privacy data of the Internet of Things through bilinear pairing operation, aggregation operation and mask removal operation. According to the invention, the overall security baseline of the Internet of Things medical system is improved.

Description

Technical Field

[0001] This application relates to the field of data security, and in particular to an encryption method, device, electronic device and computer-readable storage medium for attribute matching function of Internet of Things medical privacy data. Background Technology

[0002] With the continuous advancement of smart healthcare and digital health management, the Internet of Things (IoT) has been deeply integrated into the modern healthcare system. Smart wearable devices, medical sensors, and implantable monitoring terminals are widely used in daily patient monitoring and clinical diagnosis, continuously collecting multi-dimensional physiological data such as heart rate, blood pressure, blood oxygen saturation, and respiratory rate, providing core support for remote monitoring, intelligent diagnosis, and precision medicine. Compared to traditional manual recording or offline data collection methods, medical data generated by IoT devices has distinct characteristics such as large scale, high sampling frequency, diverse dimensions, and strong continuity, propelling medical decision-making and biomedical research to new heights. Limited by the computing power, storage capacity, and energy supply of IoT terminal devices, medical IoT systems typically rely on cloud platforms for centralized data storage and analysis, forming a cloud-assisted IoT healthcare architecture, significantly improving system scalability and data processing efficiency.

[0003] However, cloud environments are generally considered semi-trusted environments. Medical data inevitably faces potential security threats such as privacy breaches, data tampering, and the injection of falsified data during outsourced storage, cross-institutional sharing, and remote computing. Medical data is highly sensitive; security incidents not only infringe on patients' privacy rights but may also lead to serious consequences such as misdiagnosis and medical disputes. Furthermore, the traditional "decrypt before computation" model significantly increases the risk of data exposure and is unsuitable for resource-constrained medical terminals. Researchers often only need the results of specific function calculations, not the original data, creating an urgent need for privacy-preserving computation of encrypted data.

[0004] To address these challenges, encryption primitives such as matching encryption and functional encryption have been extensively studied. Matching encryption supports bilateral access control, allowing patients and researchers to specify access policies in both directions. Attribute-based matching encryption enables finer-grained access control, but it only supports an "all or nothing" decryption mode and cannot perform direct computation on encrypted data. Functional encryption enables privacy-preserving computation on encrypted data, disclosing specific function results only to authorized users, but it lacks a data source authentication mechanism, making it vulnerable to data poisoning attacks, and it does not support bilateral access control. Currently, there is no solution that can organically integrate attribute-based fine-grained bilateral access control, privacy-preserving computation of encrypted data, and data source authentication within a unified framework, making it difficult to meet the actual needs of cloud-assisted IoT healthcare. Therefore, a new encryption technology is urgently needed to overcome existing bottlenecks.

[0005] Currently, existing encryption methods for attribute matching of medical privacy data mainly suffer from the following technical defects, including:

[0006] First, the granularity of access control is not fine enough, making it difficult to adapt to complex IoT healthcare scenarios. Most existing encryption schemes for matching functions are based on identity systems. In IoT healthcare scenarios, the number of users and devices is vast and their roles are diverse; relying solely on a unique identifier is insufficient to flexibly describe complex access policies.

[0007] Secondly, it cannot simultaneously meet the dual requirements of "two-way access control" and "privacy computation." Traditional matching encryption typically presents an "all or nothing" decryption mode, meaning the receiver either obtains all the plaintext or nothing, making it impossible to perform statistical analysis (such as calculating only the average heart rate) without revealing the original data. While conventional functional encryption supports ciphertext computation, it lacks a two-way access control mechanism. The sender cannot restrict which receivers can perform computations on the ciphertext, making it difficult to control the privacy boundaries of medical data.

[0008] Third, the lack of an effective data source authentication mechanism makes it vulnerable to poisoning attacks. In cloud-assisted architectures, conventional functional encryption schemes often assume the data source is trustworthy and lack verification functionality for the origin of the encrypted data. Malicious IoT terminals or compromised edge devices may inject forged physiological data (data poisoning). The cloud server, unaware of this, may perform function calculations on the forged data, leading to incorrect medical diagnoses and seriously threatening the security and reliability of the smart healthcare system.

[0009] In summary, existing encryption methods for attribute matching of medical privacy data suffer from several problems, including insufficient granularity of access control, difficulty in adapting to complex IoT medical scenarios, inability to simultaneously meet the dual requirements of "two-way access control" and "privacy computing," lack of effective data source authentication mechanisms, and vulnerability to poisoning attacks. The applicant has made corresponding explorations to address these issues. Summary of the Invention

[0010] The purpose of this application is to solve the above-mentioned problems by providing an attribute matching encryption method, corresponding device, electronic device and computer-readable storage medium for Internet of Things medical privacy data.

[0011] To achieve the various objectives of this application, the following technical solution is adopted:

[0012] An attribute matching encryption method for IoT medical privacy data, proposed to meet one of the purposes of this application, includes:

[0013] The key generation center generates the system's global public key parameters and the system's master private key;

[0014] The system's global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector are sent to the key generation center. The key generation center generates the encryption key for the medical data sender and the decryption key for the medical data receiver based on the system's master private key.

[0015] The system's global public key parameters and the medical data recipient's access policy are sent to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the medical data recipient's access policy to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. The ciphertext set is then uploaded to the cloud server. The authentication ciphertext component is obtained by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function.

[0016] The system global public key parameters and the medical data recipient's desired medical data sender access policy are sent to the cloud server. The cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the desired medical data sender access policy provided by the medical data recipient based on the system global public key parameters and the authentication encrypted component. If the match is successful, the successfully matched encrypted set is sent to the medical data recipient.

[0017] The medical data recipient, based on its own decryption key, inputs the received ciphertext set and verifies whether its own attributes meet the access policy of the medical data recipient in the ciphertext set. If they do, the inner product privacy calculation result of the IoT medical privacy data is obtained by decrypting through bilinear pairing operation, aggregation operation and mask removal operation.

[0018] Optionally, the expression for the system's global public key parameter is:

[0019] ;

[0020] The expression for the system master private key is:

[0021] ;

[0022] in, This represents the system's global public key parameter; Denotes the order of the bilinear group. , , , It is a large prime number; Describing the first subgroup Generators; Indicates the function vector index. ; Describing the first subgroup random elements; Represents a bilinear mapping; , express Random numbers in the data, Modulus an integer addition group; Indicates the length of the function vector; Describing the first subgroup Group elements in; express Random numbers in the data; Indicates attribute index, Represents the complete set of attributes. For the complete set of attributes Element; Indicates the third subgroup The generator.

[0023] Optionally, the step of the key generation center generating an encryption key for the medical data sender and a decryption key for the medical data receiver based on the system master private key includes:

[0024] The key generation center uses the attribute set of the medical data sender. And the system master private key, select group random numbers in and the third subgroup random elements in , The encryption key of the medical data sender is calculated. The encryption key Including the encryption key base components for medical data senders Components associated with encryption key attributes The formula for calculating the encryption key for the medical data sender includes:

[0025] , ;

[0026] in, This represents the encryption key used by the sender of the medical data; This represents the basic component of the encryption key for the sender of medical data, which is a subgroup. * Group elements in; This represents the component associated with the encryption key attribute of the medical data sender, which is a subgroup. * Group elements in; express Random numbers in the data; , Indicates the third subgroup Random elements in; The first attribute in the attribute set of the medical data sender One attribute, ; This represents the set of attributes of the sender of medical data. , ;

[0027] The key generation center uses the attribute set of the medical data recipient. Function vector And the system master private key, select group random numbers in and the third subgroup random elements in The decryption key of the medical data recipient is calculated. The decryption key Includes a decryption key function vector association component for medical data recipients. Decryption key basic components and decryption key attribute association component Generate the decryption key for the recipient of the medical data. The calculation formulas include:

[0028] , , ;

[0029] in, The decryption key function vector associated component represents the decryption key of the medical data recipient, which is a subgroup. * Group elements in; This represents the basic component of the decryption key for the recipient of medical data, which is a subgroup. * Group elements in; This represents the component associated with the decryption key attribute of the medical data recipient, which is a subgroup. * Group elements in; The first function vector represents the first function vector. One portion, ; express Random numbers in the data; For the third subgroup Random elements in; The first attribute set representing the recipient of medical data One attribute, ; This represents the set of attributes of the recipient of medical data. , .

[0030] Optionally, the step of the medical data sender calculating a ciphertext set containing a basic ciphertext component and an authentication ciphertext component based on its own encryption key, by inputting the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the access policy of the medical data receiver, includes:

[0031] The medical data sender uses its own encryption key. Plaintext data vectors of input IoT medical privacy data A subset of attributes of the medical data sender and access policies for medical data recipients Select group random numbers in The basic ciphertext components are calculated, which include:

[0032] , , ,

[0033] , , ;

[0034] in, A plaintext data vector representing IoT medical privacy data; This represents a subset of attributes belonging to the sender of medical data. This indicates the access policy of the recipient of the medical data; A matrix representing the access policies of medical data recipients. The generated secret share; This indicates the mapping attribute in the system's global public key parameters. Bound public key component This indicates the encryption key of the medical data sender. Basic components; Indicates the third subgroup Random elements in; This represents the core components of the basic ciphertext; This represents a basic ciphertext auxiliary component; Indicates a random component in the underlying ciphertext; This indicates the underlying ciphertext access control component; This indicates a basic encrypted authentication auxiliary component; This represents the component associated with the basic ciphertext key. group Random numbers in the array.

[0035] Optionally, the step of obtaining the authenticated ciphertext component by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function includes:

[0036] Concatenate the basic ciphertext components into a bit string. It is represented as:

[0037] ;

[0038] in, This represents the bit string resulting from the concatenation of the basic ciphertext components; A matrix representing the access policies of medical data recipients. The row dimension; A matrix representing the access policies of the recipients of medical data;

[0039] Determine the subset of sender attributes With the complete set of attributes The correspondence, select group random numbers in The pre-component for determining the authentication ciphertext is calculated and represented as follows:

[0040] ;

[0041] in, This indicates the authentication ciphertext pre-component; This indicates the encryption key of the medical data sender. Attribute-related components; Represents a subset of sender attributes The One attribute; Represents the sender attribute The bound system public key component; Indicates the third subgroup Random elements in;

[0042] Using collision-resistant hash functions For the bit string The signature is performed, and the authentication ciphertext component is calculated, which is represented as follows:

[0043] ;

[0044] in, Represents a collision-resistant hash function; This indicates the authentication ciphertext component;

[0045] The ciphertext set is obtained from the basic ciphertext component and the authentication ciphertext component. The encrypted text set is then uploaded to the cloud server.

[0046] Optionally, the cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the expected medical data sender access policy provided by the medical data receiver based on the system global public key parameters and the authentication encrypted component. If the match is successful, the step of sending the successfully matched encrypted set to the medical data receiver includes:

[0047] The cloud server receives the encrypted data set uploaded by the medical data sender. and the desired sender access policy provided by the medical data recipient. ;

[0048] Based on the system's global public key parameters, combined with the authentication ciphertext component in the ciphertext set. Basic Ciphertext Key Association Component Basic encrypted authentication auxiliary components Calculate the intermediate vector and reconstruction coefficients ;

[0049] The property matching validation equation is expressed as follows: ,

[0050] in, Indicates the intermediate vector; Represents the linear secret-sharing reconstruction coefficients;

[0051] If the attribute matching verification equation is true, the match is successful, and the set of successfully matched ciphertext is sent to the medical data recipient.

[0052] Optionally, the medical data recipient, based on its own decryption key, inputs the received ciphertext set to verify whether its own attributes satisfy the access policy of the medical data recipient in the ciphertext set. If satisfied, the step of decrypting to obtain the inner product privacy calculation result of the IoT medical privacy data through bilinear pairing operation, aggregation operation, and mask removal operation includes:

[0053] The medical data recipient uses its own decryption key. Verify whether its own attributes satisfy the access policy of the medical data recipient in the encrypted set. ;

[0054] If its own attributes satisfy the access policy, then determine the set of indexes that satisfy the policy. and the corresponding decryption and reconstruction coefficients ;

[0055] Based on decryption key function vector association component Decryption key basic components Decryption key attribute association component With basic ciphertext auxiliary components Basic Ciphertext Random Component Basic Ciphertext Access Control Component The bilinear pairing and aggregation operations on rows are represented as follows:

[0056] ;

[0057] Based on the core components of basic ciphertext The results of bilinear pairing and aggregation operations are then subjected to a mask removal operation to recover the inner product privacy calculation result, which is represented as follows:

[0058] ;

[0059] in, Represents the inner product of the plaintext data vector and the function vector; This indicates the result of the inner product privacy calculation.

[0060] An encryption device for attribute matching function of Internet of Things medical privacy data, provided for another purpose of this application, includes:

[0061] The system parameter initialization module is configured to generate the system global public key parameters and the system master private key by the key generation center.

[0062] The user key generation module is configured to send the system global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector to the key generation center. The key generation center generates the encryption key of the medical data sender and the decryption key of the medical data receiver based on the system master private key.

[0063] The ciphertext generation and uploading module is configured to send the system's global public key parameters and the access policy of the medical data recipient to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the access policy of the medical data recipient to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. The ciphertext set is then uploaded to the cloud server. The authentication ciphertext component is obtained by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function.

[0064] The attribute matching verification module is configured to send the system global public key parameters and the medical data recipient's expected medical data sender access policy to the cloud server. The cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the expected medical data sender access policy provided by the medical data recipient based on the system global public key parameters and the authentication encrypted component. If the match is successful, the successfully matched encrypted set is sent to the medical data recipient.

[0065] The receiver decryption module is configured so that the medical data receiver, based on its own decryption key, inputs the received ciphertext set, verifies whether its own attributes meet the access policy of the medical data receiver in the ciphertext set. If it does, the inner product privacy calculation result of the IoT medical privacy data is obtained by decrypting through bilinear pairing operation, aggregation operation and mask removal operation.

[0066] An electronic device provided for another purpose of this application includes a central processing unit and a memory, the central processing unit being configured to invoke and run a computer program stored in the memory to perform the steps of the attribute matching function encryption method for Internet of Things medical privacy data described in this application.

[0067] A computer-readable storage medium is provided for another purpose of this application, which stores, in the form of computer-readable instructions, a computer program implemented according to the attribute matching function encryption method for IoT medical privacy data, which, when called by a computer, executes the steps included in the corresponding method.

[0068] Compared to existing technologies, the encryption methods for attribute matching of medical privacy data in this application suffer from several drawbacks. Firstly, the access control granularity is not fine enough, making it difficult to adapt to complex IoT-based medical scenarios. Secondly, it cannot simultaneously meet the dual requirements of "two-way access control" and "privacy computing," and it lacks an effective data source authentication mechanism, making it vulnerable to poisoning attacks. This application, however, offers the following advantages, including but not limited to:

[0069] Firstly, this application integrates the attribute sets of the medical data sender and receiver (such as department, position, equipment type, patient disease, etc.) into the encryption system. The sender must meet the receiver's desired access policy, and the receiver must also meet its own preset access policy in the ciphertext set in order to complete the ciphertext forwarding and decryption calculation. Compared with traditional identity-based encryption schemes, this achieves more flexible attribute-level permission control, which can accurately adapt to the complex interaction scenarios of massive devices and multi-level medical personnel in IoT medical systems, and strictly adheres to the "least privilege" principle for medical data access.

[0070] Secondly, this application breaks away from the traditional "all or nothing" decryption mode of matching encryption and the lack of sender access control in traditional functional encryption, deeply integrating bidirectional access control with privacy computing. The receiver does not need to decrypt to obtain the original medical data; it can obtain the inner product calculation results of IoT medical privacy data (such as average heart rate, weighted blood pressure statistics, etc.) only through bilinear pairing operations, aggregation operations, and mask removal operations. This not only meets the needs of remote diagnosis and medical research for analyzing medical data but also fundamentally protects the patient's original privacy data from being leaked, adapting to the actual needs of researchers who only require calculation results of specific functions.

[0071] Thirdly, this application introduces an authenticated ciphertext component during the ciphertext generation stage. This component is obtained by signing the bit string concatenated from the basic ciphertext component using a collision-resistant hash function. During the attribute matching and verification stage, the cloud server can verify whether the ciphertext was generated by a legitimate medical data sender based on this authenticated ciphertext component. This mechanism compensates for the lack of data source authentication in traditional functional encryption schemes, effectively preventing malicious IoT terminals and compromised edge devices from injecting forged physiological data, avoiding erroneous medical diagnoses caused by cloud servers calculating based on false data, and ensuring the authenticity and integrity of medical data throughout the entire process of collection, uploading, and cloud computing.

[0072] Fourth, the encryption, verification, and decryption processes in this application are all designed based on lightweight computational operations such as exponentiation of bilinear groups, resulting in low computational overhead and no need to occupy large amounts of computing power and storage resources. This is suitable for the limited computing power and insufficient energy supply characteristics of IoT medical terminals such as smart wearable devices and medical sensors, meeting the needs of scenarios involving real-time collection, uploading, and computation of medical data. Simultaneously, the system's global parameters and master / private key separation design, along with the introduction of random numbers and random elements from a third subgroup for key and ciphertext randomization, enable the solution to adaptively select for security under plaintext attacks. This effectively resists common network threats such as eavesdropping attacks and multi-party collusion attacks, improving the overall security baseline of the IoT medical system.

[0073] Furthermore, this application delegates the attribute matching and verification of encrypted data to the cloud server, automating access control without manual intervention. This reduces invalid transmission of medical data and improves the efficiency of data flow between the sender, cloud server, and receiver, making it suitable for medical scenarios with high real-time data requirements, such as emergency rooms and remote consultations. Simultaneously, the solution's attribute set, access strategy, and function vectors can be flexibly customized. Adding new medical roles, device types, or computational requirements does not require modification of the core computational process, easily adapting to diverse IoT-based medical business scenarios such as smart hospitals, cross-institutional medical data sharing, and medical big data research. Attached Figure Description

[0074] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0075] Figure 1 This is a flowchart illustrating the encryption method for attribute matching of IoT medical privacy data in this embodiment of the application.

[0076] Figure 2 This is an exemplary architecture diagram of the IoT medical privacy data attribute matching encryption system in the embodiments of this application;

[0077] Figure 3 This is a schematic diagram of the encryption device for attribute matching function of IoT medical privacy data in the embodiments of this application;

[0078] Figure 4 This is a schematic diagram of the structure of the computer device in the embodiments of this application. Detailed Implementation

[0079] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0080] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0081] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0082] Those skilled in the art will understand that although the various methods in this application are described based on the same concept and thus present commonality among them, they can be performed independently unless otherwise specified. Similarly, the various embodiments disclosed in this application are all based on the same inventive concept; therefore, concepts expressed in the same way, as well as concepts that are appropriately changed for convenience but are expressed differently, should be understood equivalently.

[0083] Unless otherwise expressly stated, the various embodiments disclosed in this application can be combined in a cross-cutting manner to flexibly construct new embodiments, as long as such combination does not depart from the inventive spirit of this application and can meet the needs of the prior art or solve a certain deficiency in the prior art. Those skilled in the art should be aware of such modifications.

[0084] Please see Figure 1 as well as Figure 2 In one embodiment of the IoT medical privacy data attribute matching encryption method of this application, the method includes:

[0085] Step S10: The key generation center generates system global public key parameters and system master private key. The system global public key parameters include the order of the bilinear group, the generator of the first subgroup, the random elements in the first subgroup, the bilinear mapping, the function vector length, and the complete set of attributes. The system master private key includes random numbers and the generator of the third subgroup. The complete set of attributes includes the attribute set of the medical data sender and the attribute set of the medical data receiver.

[0086] In some embodiments, the expression for the system global public key parameter is:

[0087] ;

[0088] The expression for the system master private key is:

[0089] ;

[0090] in, This represents the system's global public key parameter; Denotes the order of the bilinear group. , , , It is a large prime number; Describing the first subgroup Generators; Indicates the function vector index. ; Describing the first subgroup random elements; Represents a bilinear mapping; , express Random numbers in the data, Modulus an integer addition group; Indicates the length of the function vector; Describing the first subgroup Group elements in; express Random numbers in the data; Indicates attribute index, Represents the complete set of attributes. For the complete set of attributes Element; Indicates the third subgroup The generator.

[0091] Step S20: Send the system global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector to the key generation center. The key generation center generates the encryption key of the medical data sender and the decryption key of the medical data receiver based on the system master private key.

[0092] The key generation center generates system global public key parameters and system master private key. The system global public key parameters include the order of the bilinear group, the generator of the first subgroup, random elements in the first subgroup, the bilinear mapping, the function vector length, and the complete set of attributes. The system master private key includes random numbers and the generator of the third subgroup. The complete set of attributes includes the attribute set of the medical data sender and the attribute set of the medical data receiver. Then, the system global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector are sent to the key generation center. The key generation center generates encryption keys for the medical data sender and decryption keys for the medical data receiver based on the system master private key.

[0093] In some embodiments, the attribute set of the medical data sender describes a set of tags (e.g., "cardiology patient," "home blood glucose meter," "diabetes type") that define the identity and characteristics of the medical data sender (e.g., patient, medical device), used to bind data sources and permissions. The attribute set of the medical data receiver describes a set of tags (e.g., "cardiology attending physician," "epidemiology researcher") that define the identity and permissions of the medical data receiver (e.g., doctor, researcher), used to limit the scope of data access. The function vector defines a vector of statistical calculation targets (e.g., average blood pressure, heart rate correlation) that the medical data receiver can only obtain, ensuring that the receiver can only obtain calculation results such as inner product and cannot reconstruct the original patient data.

[0094] In some embodiments, the step of the key generation center generating an encryption key for the medical data sender and a decryption key for the medical data receiver based on the system master private key includes:

[0095] The key generation center uses the attribute set of the medical data sender. And the system master private key, select group random numbers in and the third subgroup random elements in , The encryption key of the medical data sender is calculated. The encryption key Including the encryption key base components for medical data senders Components associated with encryption key attributes The formula for calculating the encryption key for the medical data sender includes:

[0096] , ;

[0097] in, This represents the encryption key used by the sender of the medical data; This represents the basic component of the encryption key for the sender of medical data, which is a subgroup. * Group elements in; This represents the component associated with the encryption key attribute of the medical data sender, which is a subgroup. * Group elements in; express Random numbers in the data; , Indicates the third subgroup Random elements in; The first attribute in the attribute set of the medical data sender One attribute, ; This represents the set of attributes of the sender of medical data. , .

[0098] As can be seen from the above embodiments, the medical data sender can be a patient or medical device, etc., and the encryption key... Attribute association component Directly bind the attribute set of the medical data sender. (Such as "cardiology patients," "smart blood glucose meters," etc.) Only entities with legitimate attributes can generate valid encrypted data. For example, when a smart blood pressure monitor uploads data, the system can verify whether the data source is the patient's exclusive device, preventing malicious devices from forging false health data to interfere with diagnosis and treatment.

[0099] Encryption Key Basic Components Index by Function Vector Different physiological indicators (such as blood pressure, heart rate, and blood sugar) are encrypted independently. The leakage of a single indicator will not affect the security of other data. For example, a patient's blood sugar data and electrocardiogram data are isolated from each other during transmission. Even if one data stream is intercepted, all health information will not be exposed.

[0100] Introducing a third subgroup random elements , Combining the system's master private key and a random number This makes the key structure complex and difficult to crack, so even if some components are leaked, the complete key cannot be recovered. For example, when a large number of IoT devices are connected to a hospital, it can effectively prevent multiple devices from colluding to crack the key, ensuring the security of the system under large-scale deployment.

[0101] The key generation center uses the attribute set of the medical data recipient. Function vector And the system master private key, select group random numbers in and the third subgroup random elements in The decryption key of the medical data recipient is calculated. The decryption key Includes a decryption key function vector association component for medical data recipients. Decryption key basic components and decryption key attribute association component Generate the decryption key for the recipient of the medical data. The calculation formulas include:

[0102] , , ;

[0103] in, The decryption key function vector associated component represents the decryption key of the medical data recipient, which is a subgroup. * Group elements in; This represents the basic component of the decryption key for the recipient of medical data, which is a subgroup. * Group elements in; This represents the component associated with the decryption key attribute of the medical data recipient, which is a subgroup. * Group elements in; The first function vector represents the first function vector. One portion, ; express Random numbers in the data; For the third subgroup Random elements in; The first attribute set representing the recipient of medical data One attribute, ; This represents the set of attributes of the recipient of medical data. , .

[0104] As can be seen from the above embodiments, the medical data recipients include cardiologists, epidemiologists, etc., and the decryption key of the medical data recipients... Attribute association component Attribute set of the recipient of medical data (For example, "cardiologist" or "epidemiologist"), only recipients who meet the attribute requirements can decrypt the corresponding data. For example, cardiologists can only view data of cardiology patients, and interns cannot access sensitive indicators, strictly adhering to the "least privilege" principle for medical data.

[0105] Decryption key function vector association component for medical data recipients In By directly defining the recipient's computational needs, the recipient can only obtain statistical results (such as average blood pressure and correlation analysis), without being able to reconstruct the original medical data of individual patients. For example, when epidemiologists calculate the prevalence of hypertension in a region, they do not need to see the specific blood pressure values ​​of any patients, but only obtain the summary statistical results, truly achieving "data usable but invisible".

[0106] Basic components of decryption keys for medical data recipients With its simple structure and high computational efficiency based on bilinear groups, it is suitable for doctors to quickly decrypt and view data on mobile devices such as smartphones and tablets. For example, emergency room doctors can quickly decrypt patients' real-time monitoring data through a mobile app during ward rounds, improving diagnostic and treatment efficiency.

[0107] Step S30: Send the system global public key parameters and the access policy of the medical data recipient to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, the attribute subset of the medical data sender, and the access policy of the medical data recipient to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. The ciphertext set is then uploaded to the cloud server. The authentication ciphertext component is obtained by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function.

[0108] The system's global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector are sent to the key generation center. The key generation center generates an encryption key for the medical data sender and a decryption key for the medical data receiver based on the system's master private key. Then, it sends the system's global public key parameters and the medical data receiver's access policy to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the medical data receiver's access policy to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. This ciphertext set is then uploaded to the cloud server. The authentication ciphertext component is obtained by signing a bit string concatenated from the basic ciphertext components using a collision-resistant hash function.

[0109] In some embodiments, the step of the medical data sender calculating a ciphertext set containing a basic ciphertext component and an authentication ciphertext component based on its own encryption key, by inputting a plaintext data vector of IoT medical privacy data, a subset of attributes of the medical data sender, and the access policy of the medical data receiver, includes:

[0110] The medical data sender uses its own encryption key. Plaintext data vectors of input IoT medical privacy data A subset of attributes of the medical data sender and access policies for medical data recipients Select group random numbers in The basic ciphertext components are calculated, which include:

[0111] , , ,

[0112] , , ;

[0113] in, A plaintext data vector representing IoT medical privacy data; This represents a subset of attributes belonging to the sender of medical data. This indicates the access policy of the recipient of the medical data; A matrix representing the access policies of medical data recipients. The generated secret share; This indicates the mapping attribute in the system's global public key parameters. Bound public key component This indicates the encryption key of the medical data sender. Basic components; Indicates the third subgroup Random elements in; This represents the core components of the basic ciphertext; This represents a basic ciphertext auxiliary component; Indicates a random component in the underlying ciphertext; This indicates the underlying ciphertext access control component; This indicates a basic encrypted authentication auxiliary component; This represents the component associated with the basic ciphertext key. group Random numbers in the array.

[0114] As demonstrated by the above embodiments, for the medical data sender, for multi-dimensional physiological data such as blood pressure, heart rate, and blood glucose in IoT healthcare, encrypted components are independently generated according to the indicator dimension. Leakage of data in a single dimension will not affect the security of other health information, achieving hierarchical privacy protection for medical data. The encrypted key association component is directly bound to the sender's encryption key, ensuring that only patients or devices holding legitimate encryption keys can generate valid encrypted data. This prevents malicious devices from forging false health data at the source, ensuring the authenticity and traceability of medical data. Based on the exponentiation design of bilinear groups, the computational overhead is low, making it suitable for IoT devices with limited computing power, such as smart bracelets and home blood glucose meters, meeting the needs of real-time medical data upload scenarios while ensuring security.

[0115] For recipients of medical data, the access control component embeds a secret share of the recipient's access policy. Only recipients who meet the access policy can decrypt the data, achieving fine-grained permission management of "visible only to authorized roles," which meets the requirements for hierarchical access to medical data. The core encrypted component combines the original medical data with a random mask, hiding the original data while retaining the ability for subsequent statistical calculations. This lays the foundation for doctors or researchers to conduct privacy-preserving computational scenarios such as disease analysis and epidemiological statistics without touching the original data. The authentication auxiliary component supports subsequent data source authentication, verifying whether the encrypted data comes from a legitimate sender and has not been tampered with, preventing malicious tampering of medical data during transmission or storage, and ensuring the integrity and reliability of diagnostic and treatment data.

[0116] In a further embodiment, the step of obtaining the authentication ciphertext component by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function includes:

[0117] Concatenate the basic ciphertext components into a bit string. It is represented as:

[0118] ;

[0119] in, This represents the bit string resulting from the concatenation of the basic ciphertext components; A matrix representing the access policies of medical data recipients. The row dimension; A matrix representing the access policies of the recipients of medical data;

[0120] Determine the subset of sender attributes With the complete set of attributes The correspondence, select group random numbers in The pre-component for determining the authentication ciphertext is calculated and represented as follows:

[0121] ;

[0122] in, This indicates the authentication ciphertext pre-component; This indicates the encryption key of the medical data sender. Attribute-related components; Represents a subset of sender attributes The One attribute; Represents the sender attribute The bound system public key component; Indicates the third subgroup Random elements in;

[0123] Using collision-resistant hash functions For the bit string The signature is performed, and the authentication ciphertext component is calculated, which is represented as follows:

[0124] ;

[0125] in, Represents a collision-resistant hash function; This indicates the authentication ciphertext component;

[0126] The ciphertext set is obtained from the basic ciphertext component and the authentication ciphertext component. The encrypted text set is then uploaded to the cloud server.

[0127] As can be seen from the above embodiments, concatenating all basic ciphertext components into a bit string and performing hash signing ensures that any component being tampered with, deleted, or replaced will result in signature verification failure. This fundamentally prevents medical data from being maliciously tampered with during transmission or cloud storage, ensuring the integrity and reliability of diagnostic and treatment data.

[0128] The authentication ciphertext component directly binds a subset of sender attributes to the encryption key. Only senders with legitimate attributes and keys can generate valid signatures, completely preventing external devices or malicious users from forging patient data or impersonating legitimate devices to upload information, thus ensuring the authenticity and reliability of medical data sources.

[0129] The authentication component is deeply bound to a subset of the sender's attributes. Subsequent cloud server verification can precisely check whether the sender's identity matches the recipient's expected access policy, achieving a strong association between "attribute-ciphertext-permission." This allows for precise access control of medical data down to the individual attribute level, strictly meeting medical privacy compliance requirements. In cross-hospital and cross-regional medical data sharing scenarios, the authentication ciphertext component can serve as a trusted credential, enabling recipients to verify the data's source and integrity without relying on third parties, reducing the trust costs of cross-institutional medical data transfer.

[0130] Employing a collision-resistant hash function and introducing a third subgroup of random elements and additional random numbers, the signature result cannot be reverse-derived or forged due to collisions. This effectively resists common network threats such as replay attacks and man-in-the-middle attacks, ensuring system security when large-scale IoT medical device access is achieved. The authentication component reuses the attribute association component of the sender's encryption key, deeply coupling key security with ciphertext security. Even if part of the ciphertext is leaked, it cannot generate valid authentication information without the legitimate key, further enhancing the overall security level of medical data.

[0131] Step S40: Send the system global public key parameters and the medical data recipient's desired medical data sender access policy to the cloud server. The cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the desired medical data sender access policy provided by the medical data recipient based on the system global public key parameters and the authentication encrypted component. If the matching is successful, the successfully matched encrypted set is sent to the medical data recipient.

[0132] The system's global public key parameters and the medical data recipient's access policy are sent to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the medical data recipient's access policy to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. After uploading the ciphertext set to the cloud server, the system's global public key parameters and the medical data recipient's desired medical data sender access policy are sent to the cloud server. The cloud server, based on the system's global public key parameters and the authentication ciphertext component, performs attribute matching verification between the ciphertext set uploaded by the medical data sender and the desired medical data sender access policy provided by the medical data recipient. If the match is successful, the successfully matched ciphertext set is sent to the medical data recipient.

[0133] In some embodiments, the cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the expected medical data sender access policy provided by the medical data receiver based on the system global public key parameters and the authentication encrypted component. If the match is successful, the step of sending the successfully matched encrypted set to the medical data receiver includes:

[0134] The cloud server receives the encrypted data set uploaded by the medical data sender. and the desired sender access policy provided by the medical data recipient. ;

[0135] Based on the system's global public key parameters, combined with the authentication ciphertext component in the ciphertext set. Basic Ciphertext Key Association Component Basic encrypted authentication auxiliary components Calculate the intermediate vector and reconstruction coefficients ;

[0136] The property matching validation equation is expressed as follows: ,

[0137] in, Indicates the intermediate vector; Represents the linear secret-sharing reconstruction coefficients;

[0138] If the attribute matching verification equation is true, the match is successful, and the set of successfully matched ciphertext is sent to the medical data recipient.

[0139] As demonstrated by the above examples, the cloud server, based on an authentication ciphertext component, verifies whether the sender's attributes match the receiver's expected access policy. Only ciphertext with completely matching attributes is forwarded, achieving precise control that "only sender data that meets the receiver's requirements can be accessed." This prevents irrelevant or unauthorized data from flowing in, strictly complying with medical data privacy regulations. For example, cardiologists only receive data from cardiology patients; health data of diabetic patients is automatically blocked, preventing cross-departmental data leakage. The receiver's expected access policy is verified on the cloud server side, eliminating the need for post-encryption verification, reducing the scope of sensitive data transmission, and mitigating the risk of unauthorized access at the source.

[0140] The verification equation embeds signature information from a collision-resistant hash function, automatically verifying whether the ciphertext set has been tampered with, deleted, or replaced. If data is maliciously modified during transmission or storage, verification will fail, ensuring the integrity and reliability of medical data. The authentication ciphertext component is deeply bound to the sender's encryption key and attributes. Only senders with legitimate keys and attributes can pass verification, completely preventing external devices or malicious users from forging patient data or impersonating legitimate devices to upload information, ensuring the authenticity and trustworthiness of medical data sources.

[0141] Based on a bilinear mapping-based verification equation, combined with random numbers and linear secret-sharing reconstruction coefficients, this system effectively resists common network threats such as replay attacks, man-in-the-middle attacks, and collusion attacks, ensuring system security when large-scale IoT medical devices are connected. The verification process uses only public key parameters and ciphertext components, without involving any private key information, thus avoiding the risk of key leakage. Simultaneously, it allows the cloud server to complete permission verification without accessing the original data, achieving "data usable but invisible."

[0142] Step S50: The medical data recipient, based on its own decryption key, inputs the received ciphertext set and verifies whether its own attributes meet the access policy of the medical data recipient in the ciphertext set. If they do, the inner product privacy calculation result of the IoT medical privacy data is obtained by decrypting through bilinear pairing operation, aggregation operation and mask removal operation.

[0143] The system's global public key parameters and the medical data recipient's desired access policy for the medical data sender are sent to the cloud server. The cloud server, based on the system's global public key parameters and the authentication ciphertext component, performs attribute matching verification between the ciphertext set uploaded by the medical data sender and the desired access policy for the medical data sender provided by the medical data recipient. If the match is successful, the successfully matched ciphertext set is sent to the medical data recipient. The medical data recipient, based on its own decryption key, inputs the received ciphertext set to verify whether its own attributes meet the access policy of the medical data recipient in the ciphertext set. If they do, the inner product privacy calculation result of the IoT medical privacy data is obtained through bilinear pairing operation, aggregation operation, and mask removal operation.

[0144] In some embodiments, the medical data recipient, based on its own decryption key, inputs the received ciphertext set to verify whether its own attributes satisfy the access policy of the medical data recipient in the ciphertext set. If satisfied, the step of decrypting to obtain the inner product privacy calculation result of the IoT medical privacy data through bilinear pairing operation, aggregation operation, and mask removal operation includes:

[0145] The medical data recipient uses its own decryption key. Verify whether its own attributes satisfy the access policy of the medical data recipient in the encrypted set. ;

[0146] If its own attributes satisfy the access policy, then determine the set of indexes that satisfy the policy. and the corresponding decryption and reconstruction coefficients ;

[0147] Based on decryption key function vector association component Decryption key basic components Decryption key attribute association component With basic ciphertext auxiliary components Basic Ciphertext Random Component Basic Ciphertext Access Control Component The bilinear pairing and aggregation operations on rows are represented as follows:

[0148] ;

[0149] Based on the core components of basic ciphertext The results of bilinear pairing and aggregation operations are then subjected to a mask removal operation to recover the inner product privacy calculation result, which is represented as follows:

[0150] ;

[0151] in, Represents the inner product of the plaintext data vector and the function vector; This indicates the result of the inner product privacy calculation.

[0152] As demonstrated in the above embodiments, the recipient verifies whether its own attributes conform to the access policy carried in the ciphertext before decryption. Only users with sufficient permissions can proceed with the subsequent decryption process, preventing unauthorized roles such as interns and external researchers from viewing sensitive medical data from the outset, strictly adhering to the minimum access requirements for medical data. For example, only attending physicians in cardiology can decrypt cardiology patient data; interns or personnel from other departments cannot access any information. By using index sets and reconstruction coefficients, aggregation calculations are performed only on ciphertext components that meet the access policy, achieving fine-grained control of "authorization by attribute, decryption by permission," allowing access permissions for medical data to be precise down to specific indicators and role levels.

[0153] The entire decryption process does not restore any of the patient's original physiological data. It ultimately outputs only the inner product of the plaintext data vector and the function vector (such as mean blood pressure, heart rate correlation, etc.). This satisfies the data utilization needs of medical research and disease analysis while completely protecting the patient's privacy. For example, when epidemiologists calculate the prevalence of hypertension in a region, they can only obtain summary statistics and cannot view the specific blood pressure values ​​of any individual patient. By using bilinear pairing and aggregation operations to first remove the random mask and then restore the inner product result, the accuracy of the calculation is ensured while preventing the leakage of original data during the calculation process, achieving a balance between privacy and utility.

[0154] The aggregation and mask removal operations based on bilinear groups are computationally efficient, making them suitable for doctors to quickly decrypt and obtain statistical results on mobile devices such as smartphones and tablets. This meets the real-time requirements of medical scenarios such as emergency rooms and remote consultations. The decryption process relies on the recipient's exclusive decryption key, combined with a random number and linear secret sharing mechanism, which can effectively resist common threats such as collusion attacks and replay attacks. Even if some key components are leaked, valid results cannot be recovered, ensuring the computational security of medical data.

[0155] As can be seen from the above embodiments, compared with the prior art, the encryption method for attribute matching function of medical privacy data in the prior art has problems such as insufficient granularity of access control, difficulty in adapting to complex IoT medical scenarios, inability to simultaneously meet the dual requirements of "two-way permission control" and "privacy computing", and lack of effective data source authentication mechanism, making it vulnerable to poisoning attacks. The present application has, but is not limited to, the following beneficial effects:

[0156] Firstly, this application integrates the attribute sets of the medical data sender and receiver (such as department, position, equipment type, patient disease, etc.) into the encryption system. The sender must meet the receiver's desired access policy, and the receiver must also meet its own preset access policy in the ciphertext set in order to complete the ciphertext forwarding and decryption calculation. Compared with traditional identity-based encryption schemes, this achieves more flexible attribute-level permission control, which can accurately adapt to the complex interaction scenarios of massive devices and multi-level medical personnel in IoT medical systems, and strictly adheres to the "least privilege" principle for medical data access.

[0157] Secondly, this application breaks away from the traditional "all or nothing" decryption mode of matching encryption and the lack of sender access control in traditional functional encryption, deeply integrating bidirectional access control with privacy computing. The receiver does not need to decrypt to obtain the original medical data; it can obtain the inner product calculation results of IoT medical privacy data (such as average heart rate, weighted blood pressure statistics, etc.) only through bilinear pairing operations, aggregation operations, and mask removal operations. This not only meets the needs of remote diagnosis and medical research for analyzing medical data but also fundamentally protects the patient's original privacy data from being leaked, adapting to the actual needs of researchers who only require calculation results of specific functions.

[0158] Thirdly, this application introduces an authenticated ciphertext component during the ciphertext generation stage. This component is obtained by signing the bit string concatenated from the basic ciphertext component using a collision-resistant hash function. During the attribute matching and verification stage, the cloud server can verify whether the ciphertext was generated by a legitimate medical data sender based on this authenticated ciphertext component. This mechanism compensates for the lack of data source authentication in traditional functional encryption schemes, effectively preventing malicious IoT terminals and compromised edge devices from injecting forged physiological data, avoiding erroneous medical diagnoses caused by cloud servers calculating based on false data, and ensuring the authenticity and integrity of medical data throughout the entire process of collection, uploading, and cloud computing.

[0159] Fourth, the encryption, verification, and decryption processes in this application are all designed based on lightweight computational operations such as exponentiation of bilinear groups, resulting in low computational overhead and no need to occupy large amounts of computing power and storage resources. This is suitable for the limited computing power and insufficient energy supply characteristics of IoT medical terminals such as smart wearable devices and medical sensors, meeting the needs of scenarios involving real-time collection, uploading, and computation of medical data. Simultaneously, the system's global parameters and master / private key separation design, along with the introduction of random numbers and random elements from a third subgroup for key and ciphertext randomization, enable the solution to adaptively select for security under plaintext attacks. This effectively resists common network threats such as eavesdropping attacks and multi-party collusion attacks, improving the overall security baseline of the IoT medical system.

[0160] Furthermore, this application delegates the attribute matching and verification of encrypted data to the cloud server, automating access control without manual intervention. This reduces invalid transmission of medical data and improves the efficiency of data flow between the sender, cloud server, and receiver, making it suitable for medical scenarios with high real-time data requirements, such as emergency rooms and remote consultations. Simultaneously, the solution's attribute set, access strategy, and function vectors can be flexibly customized. Adding new medical roles, device types, or computational requirements does not require modification of the core computational process, easily adapting to diverse IoT-based medical business scenarios such as smart hospitals, cross-institutional medical data sharing, and medical big data research.

[0161] Please see Figure 3An encryption device for attribute matching function of Internet of Things medical privacy data, provided to suit one of the purposes of this application, includes: wherein, The system parameter initialization module 1100 is configured to generate system global public key parameters and system master private key parameters by the key generation center. The system global public key parameters include the order of the bilinear group, the generator of the first subgroup, random elements in the first subgroup, the bilinear mapping, the function vector length, and the complete set of attributes. The system master private key includes random numbers and the generator of the third subgroup. The complete set of attributes includes the attribute set of the medical data sender and the attribute set of the medical data receiver. The user key generation module 1200 is configured to send the system global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector to the key generation center. The key generation center generates an encryption key for the medical data sender and a decryption key for the medical data receiver based on the system master private key. The ciphertext generation and uploading module 1300 is configured to send the system global public key parameters and the access policy of the medical data receiver to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data and a subset of the medical data sender's attributes. The system calculates a ciphertext set containing a basic ciphertext component and an authentication ciphertext component, based on the access policy of the medical data recipient. This ciphertext set is then uploaded to a cloud server. The authentication ciphertext component is obtained by signing a concatenated bit string of the basic ciphertext components using a collision-resistant hash function. An attribute matching verification module 1400 is configured to send the system's global public key parameters and the medical data recipient's desired medical data sender access policy to the cloud server. The cloud server, based on the system's global public key parameters and the authentication ciphertext component, performs attribute matching verification between the ciphertext set uploaded by the medical data sender and the desired medical data sender access policy provided by the medical data recipient. If a match is successful, the successfully matched ciphertext set is sent to the medical data recipient. A receiver decryption module 1500 is configured to allow the medical data recipient to input the received ciphertext set using its own decryption key and verify whether its attributes satisfy the medical data recipient's access policy in the ciphertext set. If satisfied, the inner product privacy calculation result of the IoT medical privacy data is obtained through bilinear pairing, aggregation, and mask removal operations.

[0162] Based on any embodiment of this application, please refer to Figure 4 Another embodiment of this application also provides an electronic device, which can be implemented by a computer device, such as... Figure 4The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, a database, and computer-readable instructions. The database may store control information sequences. When executed by the processor, the computer-readable instructions enable the processor to implement an attribute-matching encryption method for IoT medical privacy data. The processor provides computing and control capabilities to support the operation of the entire computer device. The memory stores computer-readable instructions, which, when executed by the processor, enable the processor to execute the attribute-matching encryption method for IoT medical privacy data of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0163] In this embodiment, the processor is used to execute... Figure 3 The specific functions of each module are described, and the memory stores the program code and various types of data required to execute these modules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required to execute all modules in the attribute matching encryption device for IoT medical privacy data of this application. The server can call the server's program code and data to execute the functions of all modules.

[0164] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the attribute matching function encryption method for IoT medical privacy data described in any embodiment of this application.

[0165] This application also provides a computer program product, including a computer program / instruction that, when executed by one or more processors, implements the steps of the attribute matching encryption method for IoT medical privacy data described in any embodiment of this application.

[0166] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0167] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for encrypting IoT medical privacy data using attribute matching, characterized in that, include: The key generation center generates the system's global public key parameters and the system's master private key; The system's global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector are sent to the key generation center. The key generation center generates the encryption key for the medical data sender and the decryption key for the medical data receiver based on the system's master private key. The system's global public key parameters and the medical data recipient's access policy are sent to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the medical data recipient's access policy to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. The ciphertext set is then uploaded to the cloud server. The authentication ciphertext component is obtained by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function. The system global public key parameters and the medical data recipient's desired medical data sender access policy are sent to the cloud server. The cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the desired medical data sender access policy provided by the medical data recipient based on the system global public key parameters and the authentication encrypted component. If the match is successful, the successfully matched encrypted set is sent to the medical data recipient. The medical data recipient, based on its own decryption key, inputs the received ciphertext set and verifies whether its own attributes meet the access policy of the medical data recipient in the ciphertext set. If they do, the inner product privacy calculation result of the IoT medical privacy data is obtained by decrypting through bilinear pairing operation, aggregation operation and mask removal operation.

2. The encryption method for attribute matching function of IoT medical privacy data according to claim 1, characterized in that, The expression for the system's global public key parameter is: ； The expression for the system master private key is: ； in, This represents the system's global public key parameter; Denotes the order of the bilinear group. , , , It is a large prime number; Describing the first subgroup Generators; Indicates the function vector index. ; Describing the first subgroup random elements; Represents a bilinear mapping; , express Random numbers in the data, Modulus an integer addition group; Indicates the length of the function vector; Describing the first subgroup Group elements in; express Random numbers in the data; Indicates attribute index, Represents the complete set of attributes. For the complete set of attributes Element; Indicates the third subgroup The generator.

3. The encryption method for attribute matching function of IoT medical privacy data according to claim 2, characterized in that, The steps of the key generation center generating the encryption key for the medical data sender and the decryption key for the medical data receiver based on the system master private key include: The key generation center uses the attribute set of the medical data sender. And the system master private key, select group random numbers in and the third subgroup random elements in , The encryption key of the medical data sender is calculated. The encryption key Including the encryption key base components for medical data senders Components associated with encryption key attributes The formula for calculating the encryption key for the medical data sender includes: ， ； in, This represents the encryption key used by the sender of the medical data; This represents the basic component of the encryption key for the sender of medical data, which is a subgroup. * Group elements in; This represents the component associated with the encryption key attribute of the medical data sender, which is a subgroup. * Group elements in; express Random numbers in the data; , Indicates the third subgroup Random elements in; The first attribute in the attribute set of the medical data sender One attribute, ; This represents the set of attributes of the sender of medical data. , ; The key generation center uses the attribute set of the medical data recipient. Function vector And the system master private key, select group random numbers in and the third subgroup random elements in The decryption key of the medical data recipient is calculated. The decryption key Includes a decryption key function vector association component for medical data recipients. Decryption key basic components and decryption key attribute association component Generate the decryption key for the recipient of the medical data. The calculation formulas include: ， ， ； in, The decryption key function vector associated component represents the decryption key of the medical data recipient, which is a subgroup. * Group elements in; This represents the basic component of the decryption key for the recipient of medical data, which is a subgroup. * Group elements in; This represents the component associated with the decryption key attribute of the medical data recipient, which is a subgroup. * Group elements in; The first function vector represents the first function vector. One portion, ; express Random numbers in the data; For the third subgroup Random elements in; The first attribute set representing the recipient of medical data One attribute, ; This represents the set of attributes of the recipient of medical data. , .

4. The encryption method for attribute matching function of IoT medical privacy data according to claim 2, characterized in that, The step of the medical data sender calculating a ciphertext set containing a basic ciphertext component and an authentication ciphertext component, based on its own encryption key, by inputting the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the access policy of the medical data receiver, includes: The medical data sender uses its own encryption key. Plaintext data vectors of input IoT medical privacy data A subset of attributes of the medical data sender and access policies for medical data recipients Select group random numbers in The basic ciphertext components are calculated, which include: ， ， ， ， ， ； in, A plaintext data vector representing IoT medical privacy data; This represents a subset of attributes belonging to the sender of medical data. This indicates the access policy of the recipient of the medical data; A matrix representing the access policies of medical data recipients. The generated secret share; This indicates the mapping attribute in the system's global public key parameters. Bound public key component This indicates the encryption key of the medical data sender. Basic components; Indicates the third subgroup Random elements in; This represents the core components of the basic ciphertext; This represents a basic ciphertext auxiliary component; Indicates a random component in the underlying ciphertext; This indicates the underlying ciphertext access control component; This indicates a basic encrypted authentication auxiliary component; This represents the component associated with the basic ciphertext key. group Random numbers in the array.

5. The encryption method for attribute matching function of IoT medical privacy data according to claim 4, characterized in that, The steps for obtaining the authenticated ciphertext component by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function include: Concatenate the basic ciphertext components into a bit string. It is represented as: ； in, This represents the bit string resulting from the concatenation of the basic ciphertext components; A matrix representing the access policies of medical data recipients. The row dimension; A matrix representing the access policies of the recipients of medical data; Determine the subset of sender attributes With the complete set of attributes The correspondence, select group random numbers in The pre-component for determining the authentication ciphertext is calculated and represented as follows: ； in, This indicates the authentication ciphertext pre-component; This indicates the encryption key of the medical data sender. Attribute-related components; Represents a subset of sender attributes The One attribute; Represents the sender attribute The bound system public key component; Indicates the third subgroup Random elements in; Using collision-resistant hash functions For the bit string The signature is performed, and the authentication ciphertext component is calculated, which is represented as follows: ； in, Represents a collision-resistant hash function; This indicates the authentication ciphertext component; The ciphertext set is obtained from the basic ciphertext component and the authentication ciphertext component. The encrypted text set is then uploaded to the cloud server.

6. The encryption method for attribute matching function of IoT medical privacy data according to any one of claims 2 to 5, characterized in that, The cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the expected medical data sender access policy provided by the medical data receiver, based on the system global public key parameters and the authentication encrypted component. If the match is successful, the step of sending the successfully matched encrypted set to the medical data receiver includes: The cloud server receives the encrypted data set uploaded by the medical data sender. and the desired sender access policy provided by the medical data recipient. ; Based on the system's global public key parameters, combined with the authentication ciphertext component in the ciphertext set. Basic Ciphertext Key Association Component Basic encrypted authentication auxiliary components Calculate the intermediate vector and reconstruction coefficients ; The property matching validation equation is expressed as follows: , in, Indicates the intermediate vector; Represents the linear secret-sharing reconstruction coefficients; If the attribute matching verification equation is true, the match is successful, and the set of successfully matched ciphertext is sent to the medical data recipient.

7. The encryption method for attribute matching function of IoT medical privacy data according to any one of claims 2 to 5, characterized in that, The medical data recipient, based on its own decryption key, inputs the received ciphertext set to verify whether its own attributes satisfy the access policy of the medical data recipient in the ciphertext set. If satisfied, the recipient then decrypts the data using bilinear pairing, aggregation, and mask removal operations to obtain the inner product privacy calculation result of the IoT medical privacy data. This process includes: The medical data recipient uses its own decryption key. Verify whether its own attributes satisfy the access policy of the medical data recipient in the encrypted set. ; If its own attributes satisfy the access policy, then determine the set of indexes that satisfy the policy. and the corresponding decryption and reconstruction coefficients ; Based on decryption key function vector association component Decryption key basic components Decryption key attribute association component With basic ciphertext auxiliary components Basic Ciphertext Random Component Basic Ciphertext Access Control Component The bilinear pairing and aggregation operations on rows are represented as follows: ； Based on the core components of basic ciphertext The results of bilinear pairing and aggregation operations are then subjected to a mask removal operation to recover the inner product privacy calculation result, which is represented as follows: ； in, Represents the inner product of the plaintext data vector and the function vector; This indicates the result of the inner product privacy calculation.

8. An encryption device for attribute matching function of Internet of Things medical privacy data, characterized in that, include: The system parameter initialization module is configured to generate the system global public key parameters and the system master private key by the key generation center. The user key generation module is configured to send the system global public key parameters, the attribute set of the medical data sender, the attribute set of the medical data receiver, and the function vector to the key generation center. The key generation center generates the encryption key of the medical data sender and the decryption key of the medical data receiver based on the system master private key. The ciphertext generation and uploading module is configured to send the system's global public key parameters and the access policy of the medical data recipient to the medical data sender. The medical data sender, based on its own encryption key, inputs the plaintext data vector of the IoT medical privacy data, a subset of the medical data sender's attributes, and the access policy of the medical data recipient to calculate a ciphertext set containing a basic ciphertext component and an authentication ciphertext component. The ciphertext set is then uploaded to the cloud server. The authentication ciphertext component is obtained by signing the bit string concatenated from the basic ciphertext components using a collision-resistant hash function. The attribute matching verification module is configured to send the system global public key parameters and the medical data recipient's expected medical data sender access policy to the cloud server. The cloud server performs attribute matching verification on the encrypted set uploaded by the medical data sender and the expected medical data sender access policy provided by the medical data recipient based on the system global public key parameters and the authentication encrypted component. If the match is successful, the successfully matched encrypted set is sent to the medical data recipient. The receiver decryption module is configured so that the medical data receiver, based on its own decryption key, inputs the received ciphertext set, verifies whether its own attributes meet the access policy of the medical data receiver in the ciphertext set. If it does, the inner product privacy calculation result of the IoT medical privacy data is obtained by decrypting through bilinear pairing operation, aggregation operation and mask removal operation.

9. An electronic device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images