Iot system and working method based on attribute encryption and signature

Abstract

The application belongs to the technical field of data encryption, and particularly relates to an Internet of Things system based on attribute encryption and signature and a working method. The system comprises an attribute authorization institution, a patient terminal, a data owner terminal, a cloud service provider and a data user terminal. The attribute authorization institution is an honest but curious entity, generates system parameters, and generates an intermediate signature key and an intermediate decryption key for the patient and the data user respectively; the patient terminal introduces a first random secret to generate a complete signature private key and performs offline signature; the data owner terminal performs attribute encryption on medical data, generates online signature by using offline signature, and then uploads to the cloud; and the data user terminal verifies the signature, introduces a second random secret to generate a complete decryption private key, and performs decryption. The application retains the simplicity of the single attribute institution architecture, and eliminates the dependence on a fully trusted institution through a key coordination generation mechanism.

Description

Technical Field

[0001] This invention belongs to the field of data encryption technology, specifically an Internet of Things system and its working method based on attribute encryption and signature. Background Technology

[0002] The statements in this section merely refer to the background art related to this invention and do not necessarily constitute prior art.

[0003] Medical data is highly sensitive and confidential, typically requiring fine-grained access control and authentication privacy protection during its transmission and sharing. Attribute-Based Encryption (ABE) and Attribute-Based Signature (ABS) are currently key technologies for achieving these security goals. ABE supports flexible access policies by binding decryption permissions to user attributes; ABS allows users to anonymously authenticate data based on attributes, protecting the privacy of the signer.

[0004] However, existing encryption and signature schemes generally rely on the strong trust assumption: that is, the attribute authority in the system must be completely trustworthy. Under this assumption, the attribute authority independently generates and distributes all user keys. In this "strong trust" model, the attribute authority can unilaterally possess all users' private keys. Once the authority is compromised or internal misconduct occurs, the data confidentiality and authentication security of the entire system will collapse simultaneously.

[0005] To address the aforementioned strong trust issues, existing technologies attempt to reduce reliance on a single institution by distributing trust. However, such solutions typically require multiple institutions to remain continuously online without collusion, increasing system deployment complexity and communication overhead, and introducing additional synchronization and coordination mechanisms. In resource-constrained medical IoT terminal device scenarios (such as wearable monitoring devices and mobile data acquisition terminals), these complex models are often difficult to deploy in practice, leading to an irreconcilable conflict between security and practicality in existing solutions. Summary of the Invention

[0006] This solution provides an IoT system and methodology based on attribute encryption and signatures, enabling fine-grained access control and source authentication of medical data under partially trusted attribute authorities.

[0007] The first aspect of this invention discloses an Internet of Things (IoT) system based on attribute encryption and signature, comprising: The attribute authorization authority, configured as an "honest but curious" entity, is used to generate publicly available system parameters and the master key, and to generate intermediate signature keys for patients and intermediate decryption keys for data users in response to requests from patients and data users, respectively. The patient terminal is configured to: receive an intermediate signature key sent by an attribute authorization agency, generate a complete signature private key by introducing a first random secret, perform offline signature calculation on medical data using the complete signature private key, generate an offline signature and send it to the data owner; The data owner terminal is configured to: receive offline signatures sent by the patient terminal, obtain plaintext medical data and determine access control policies, perform attribute-based encryption operations on the plaintext medical data using publicly available system parameters to generate ciphertext, perform online signature operations on the ciphertext using the offline signature to generate an online signature, and associate the ciphertext with the online signature and upload it to the cloud service provider. The cloud service provider is configured as an "honest but curious" entity to store encrypted data uploaded by the data owner's terminal and its corresponding online signature; The data user terminal is configured to: obtain the target ciphertext and its online signature from the cloud service provider, verify the online signature using publicly available system parameters, and if the verification is successful, receive the intermediate decryption key sent by the attribute authorization authority, generate a complete decryption private key by introducing a second random secret, and use the complete decryption private key to decrypt the ciphertext and recover the plaintext medical data.

[0008] Furthermore, the attribute authorization authority is configured to: during system initialization, select large prime numbers to construct a cryptographic group, define a bilinear mapping, and set a global attribute set, and generate system public parameters and master keys through randomly selected secret parameters.

[0009] Furthermore, the patient terminal holds a set of patient attributes and requests an intermediate signature key from the attribute authorization authority based on this set of attributes; the intermediate signature key is generated by the attribute authorization authority using a threshold secret sharing method based on the patient's set of attributes.

[0010] Furthermore, the patient terminal introduces a first random secret to generate a complete signature private key. Specifically, a secret parameter is randomly selected locally on the patient terminal, and this secret parameter is fused and calculated with the intermediate signature key issued by the attribute authorization authority to generate a complete signature private key that is only known to the patient.

[0011] Furthermore, the data user terminal holds the data user's attribute set and requests an intermediate decryption key from the attribute authorization agency based on the attribute set; the intermediate decryption key is generated by the attribute authorization agency based on the data user's attribute set.

[0012] Furthermore, the data user terminal introduces a second random secret to generate a complete decryption private key. Specifically, a secret parameter is randomly selected locally on the data user terminal, and this secret parameter is fused with the intermediate decryption key issued by the attribute authorization authority to generate a complete decryption private key that is only known to the data user.

[0013] Furthermore, when the data owner's terminal performs attribute-based encryption operations, it binds the access control policy to the ciphertext, ensuring that the data user's attribute set meets the requirements of the access control policy, thereby achieving successful decryption.

[0014] Furthermore, the offline signature calculation performed by the patient terminal can be completed in advance; the data owner terminal performs an online signature operation, binding the offline signature generated by the patient terminal with the current ciphertext to generate a formal signature that corresponds one-to-one with the ciphertext.

[0015] Furthermore, after obtaining the target ciphertext and its online signature from the cloud service provider, the data user terminal verifies the online signature using publicly available system parameters. Specifically, the data user terminal selects a subset of attributes from its held attribute set that meets the threshold requirements, and uses the attribute subset to verify and calculate each component in the online signature. If the result of the verification calculation is equal to the predetermined value in the publicly available system parameters, the verification passes, confirming that the ciphertext originates from a legitimate patient and has not been tampered with; if they are not equal, the verification fails, and subsequent decryption operations are rejected.

[0016] A second aspect of the present invention discloses a method for operating an Internet of Things (IoT) system based on attribute encryption and signature, comprising the following steps: After initialization, the attribute authorization agency generates public system parameters and a master key, and in response to requests from patients and data users, generates an intermediate signature key for patients and an intermediate decryption key for data users, respectively. The patient terminal receives the intermediate signature key sent by the attribute authorization agency, generates a complete signature private key by introducing a first random secret, performs offline signature calculation on the medical data using the complete signature private key, generates an offline signature, and sends it to the data owner. The data owner terminal receives the offline signature sent by the patient terminal, obtains the plaintext medical data and determines the access control policy, performs attribute-based encryption on the plaintext medical data using publicly available system parameters to generate ciphertext, performs online signing on the ciphertext using the offline signature to generate an online signature, and uploads the ciphertext and online signature together to the cloud service provider. Cloud service providers store encrypted data uploaded by the data owner's terminal and its corresponding online signature; After obtaining the target ciphertext and its online signature from the cloud service provider, the data user terminal verifies the online signature using publicly available system parameters. If the verification is successful, it receives the intermediate decryption key sent by the attribute authorization authority, generates a complete decryption private key by introducing a second random secret, and uses the complete decryption private key to decrypt the ciphertext and recover the plaintext medical data.

[0017] Compared with existing technologies, one or more of the above technical solutions have the following beneficial effects: In this scheme, the attribute authorization authority only generates the intermediate key. The patient terminal and the data user terminal each introduce their own independent first and second random secrets locally to complete the construction of the complete signing private key and the complete decryption private key. Through this "key collaborative generation" mechanism, even if the attribute authorization authority is modeled as an "honest but curious" entity, it cannot recover any user's complete private key on its own. Thus, without introducing complex mechanisms such as multi-institutional collaboration and threshold synchronization, the risk of single-point key escrow is eliminated, and dependence on a fully trusted attribute authority is achieved. Attached Figure Description

[0018] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0019] Figure 1 A schematic diagram of an Internet of Things (IoT) system model based on attribute encryption and signature provided for one or more embodiments of the present invention; Figure 2 This is a schematic diagram illustrating the working process of an Internet of Things (IoT) system based on attribute encryption and signature, provided for one or more embodiments of the present invention. Detailed Implementation

[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0021] It should be noted that the following detailed descriptions are exemplary and intended to provide further illustration of the invention. Unless otherwise specified, all technical and scientific terms used in this invention have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains.

[0022] The strong trust assumption refers to the assumption that the attribute authority is a "fully trusted" entity in traditional attribute-based encryption and signature systems. This means that system designers assume the authority will strictly adhere to the protocol, never engage in illegal data acquisition, be unbreakable, and have complete control over user keys. Under this assumption, the attribute authority independently generates all user private keys and distributes them through a secure channel; the user does not participate in the key creation process. While this "centralized key escrow" model simplifies system design, it places the entire system's security on the trustworthiness of a single entity.

[0023] The core problem arising from the strong trust assumption lies in "key escrow risk." If a malicious actor emerges within the institution, or if the institution's servers suffer an external attack leading to the leakage of the master key, the attacker can use the master key to recover all users' private keys. In a medical IoT scenario, this means that attackers can decrypt all encrypted medical data and forge any patient's signature, thereby destroying the system's confidentiality and authentication security. Furthermore, because users never participate in key generation, they cannot know whether their keys have been leaked and find it difficult to protect themselves locally.

[0024] To address the security risks arising from the strong trust assumption, existing technologies primarily employ two improvement schemes: one is to introduce multiple attribute institutions and distribute trust through a threshold mechanism, requiring collaboration among multiple institutions to complete key generation; the other is to adopt a distributed or multi-center architecture, expanding a single trust point into multiple trust points. These schemes disperse risk by increasing the number of trust nodes, which reduces dependence on a single institution to some extent, but also introduces new problems: complex key negotiation protocols, synchronization mechanisms, and network communication are required between multiple institutions, significantly increasing system deployment difficulty; threshold schemes require multiple institutions to be continuously online and non-colluding, which is often difficult to meet in real-world medical IoT environments; furthermore, the complex interaction process brings additional communication and computational overhead, contradicting the resource-constrained capacity of medical terminal devices.

[0025] This demonstrates a contradiction between existing technologies in "reducing trust dependence" and "maintaining system simplicity and efficiency." To address this, this solution provides an IoT system and methodology based on attribute encryption and signatures. It employs a key generation mechanism of "partially trusted institutions + local user collaboration," eliminating single points of trust and making users a part of the key generation process. Simultaneously, it integrates attribute encryption and offline-online signatures, preserving the simplicity of a single-attribute institution architecture while achieving risk diversification.

[0026] Example 1: The system in this scheme is supported by the "partially trusted authority" model, and is therefore named ABES-PTA, which stands for Attribute-Based Encryption and Signature with Partially Trusted Authority.

[0027] The system consists of five main entities: Attribute Authorization Authority (AA), Patients, Data Owner (DO), Cloud Service Provider (CSP), and Data User (DU).

[0028] The Attribute Authorization Authority (AA) is responsible for system initialization and the generation of intermediate keys, and is assumed to be an "honest but curious" entity. Specifically, the AA will strictly follow the protocol to correctly generate and distribute some keys, but may attempt to infer the sensitivity or access patterns of patient data.

[0029] Cloud service providers (CSPs) are also modeled as "honest but curious," meaning they strictly adhere to system protocols but may attempt to extract additional information from the stored content. Most data users (DUs) are considered honest and do not collude or share their keys. Data owners (DOs) hold the plaintext data and are similarly considered honest entities.

[0030] It should be noted that the "honest but curious" entities referred to in this scheme are entities that strictly adhere to the preset protocol algorithm during system operation and will not actively deviate from the protocol or maliciously disrupt system functionality; however, they may attempt to infer additional sensitive information from intermediate data, access records, and other information obtained during protocol execution. This scheme ensures, through mechanisms such as key collaborative generation and user-local secret injection, that even if such entities are "curious," they cannot obtain the user's complete private key or directly decrypt data, thus achieving a balance between security and practicality under reasonable assumptions.

[0031] The "honest but curious" assumption in this scheme is implemented through specific mechanisms. First, the Authorizing Authority (AA) generates only a portion of the key, while the complete private key must be generated locally by the user using random numbers; therefore, the AA cannot possess the complete private key. Second, random numbers are introduced during key generation and encryption, making the intermediate data random and difficult to deduce. Furthermore, functional separation between entities in the system (AA, CSP, and user) prevents a single entity from obtaining complete sensitive information. Through these simple mechanisms, even if "curious" behavior occurs, it is impossible to obtain the user's private data.

[0032] Combination Figure 1 Describe the specific responsibilities of each entity: Attribute Authorization Authority (AA): The Attribute Authorization Authority is responsible for generating partial encryption keys for patients and data users. By introducing a partial key generation mechanism, the single point of trust assumption is effectively reduced, thereby improving the overall security of the IoT medical data sharing environment.

[0033] Patients: Patients are the primary data source in the IoT healthcare environment and possess their own set of attributes. After obtaining partial keys from an attribute authorization authority, patients can generate complete private keys. Patients perform an offline signing phase on their medical data and send the signing result to the data owner to complete the subsequent online signing process. In this solution, the entity "Patients" can be a software terminal installed on the patient's mobile phone or a wearable device worn by the patient. This solution collectively refers to "Patients" as "Patient Terminals."

[0034] Data Owner (DO): The data owner is responsible for data collection, encryption, and the generation of the final signature. They encrypt the data using attribute-based encryption according to access control policies and perform an online signing process on the encrypted data to generate the final ciphertext signature. The DO then uploads the ciphertext and its corresponding signature to the cloud. In this solution, the data owner (DO) entity can be server software or an edge gateway deployed within the hospital.

[0035] Cloud Service Provider (CSP): The CSP is responsible for storing encrypted data and its corresponding signature. As an "honest but curious" entity, the CSP cannot decrypt the data or verify the signature content.

[0036] Data Users (DUs): Data users are typically authorized medical personnel (DUs refer to multiple data users) and each holds their own set of attributes. In collaboration with the attribute authorization authority, each DU obtains a corresponding decryption key. When accessing data, the DU first verifies the signature to confirm the authenticity and origin of the data; if the access control policy is satisfied, it can further decrypt and obtain the encrypted data. In this scheme, the entity of a data user (DU) can be an application installed on the doctor's computer or tablet.

[0037] This scheme includes initialization, key generation, encryption, signing, and verification processes, combined with... Figure 2 This document describes the specific working process of this solution: Step 1: System initialization.

[0038] This step is used to complete system initialization, establishing the basic environment and rules required for system operation. Specifically, the Attribute Authorization Authority (AA) selects the mathematical structure (such as an elliptic curve group) on which the system depends, determines the set of attributes in the system, and assigns a unique identifier to each attribute. Based on this, public system parameters are generated for use by all participants, and a master key is generated and securely stored by the AA for subsequent key generation. Through the above process, the basic framework of the system is constructed.

[0039] The specific process is as follows: System initialization ( ) → ( MP, MK This is executed by the AA. During the system initialization phase, the AA inputs security parameters. Choose large prime numbers The structural order is group and ,set up Define a generator and a bilinear mapping. 。

[0040] AA defines a global set of attributes and randomly select To calculate At the same time, define a hash function. Used for mapping operations in subsequent signing / verification. Among them, the global attribute collection... This represents the complete set of all possible attributes in the system, forming the basis for subsequent access control and key generation. Specifically, in practice, patients or data users will only select a subset of attributes relevant to themselves from this set and participate in key generation and access control policy construction based on these attributes. Therefore, the global attribute set is used to uniformly define the value range of attributes in the system, while specific user attributes are subsets of this set.

[0041] Ultimately, AA released the system's public parameters. and securely store the master key. This is to support the subsequent generation and distribution of intermediate keys to patients and data users.

[0042] Step 2: The Attribute Authorization Authority (AA) generates an intermediate key.

[0043] Building upon step one, the Attribute Authority (AA) generates partial key components related to the user's attributes. For patients, the AA constructs an intermediate signing key; for data users (such as doctors), it generates an intermediate decryption key. These keys are in an incomplete state and cannot be directly used for signing or decryption operations; they are then sent to the corresponding users via a secure channel.

[0044] The specific process is as follows: ( ) , This is executed by the AA and sent to Patients and DUs respectively. The AA only generates an "intermediate key" when issuing keys to reduce single point of trust.

[0045] AA first randomly selects polynomial of degree ,satisfy This is used for threshold binding of attribute components. For the signature attribute set of Patients. AA selects those that satisfy attribute subset and for each Select random number Based on this, the intermediate signature key for Patients is generated. Then it is sent to Patients via a secure channel.

[0046] In this scheme, the threshold value t is a parameter pre-set during the system initialization phase, used to specify the minimum number of attributes that must be satisfied. (Selection) The subset of attributes is used to implement threshold control, meaning that the relevant calculation or verification can only be valid if at least t attributes are satisfied. (Random number) The attribute-authorizing authority randomly selects the key during the key generation process. This randomization is used to randomize the key components corresponding to each attribute, thereby preventing intermediate data from being inferred and improving system security. Subsequent random selections are all based on the same purpose.

[0047] For the set of decryption attributes of a data user (DU) AA directly generates intermediate decryption key components based on its properties. And send it to the corresponding DU. In this way, even if the AA is honest but curious, it is difficult for the AA to construct the complete private key of any entity on its own.

[0048] Step 3: The patient generates a complete signature key.

[0049] The patient refines the intermediate signing key locally. Specifically, the patient introduces a random secret number known only to themselves and combines it with existing key components to generate a complete signing private key. Because this process is performed locally and contains information unknown to the AA, the AA cannot deduce the patient's final private key, thus ensuring the independence and security of the key.

[0050] The specific process is as follows: （ ）→ ， Performed by the patients.

[0051] Patients received the intermediate signature key from AA. Then, a local random secret (the first random secret) is introduced to complete the signing private key, thus ensuring that the complete signing capability is solely controlled by Patients. Specifically, Patients randomly selects... Make it belong to the model The set of non-zero integers, calculate Will Publicly disclosed as a public parameter. Next, Patients randomly select one with a frequency of [number missing]. polynomial and order It is used to secretly fuse the threshold polynomial components of AA with the patient's own.

[0052] Finally, Patients generated a fully signed private key. .get Afterwards, the patient can perform calculations for the offline signing stage of the medical data and send the offline signing result to the data owner (DO) so that the DO can generate the final "signed ciphertext" and upload it to the CSP in the subsequent online signing and encryption stages.

[0053] Step 4: The data user generates a complete decryption key.

[0054] In this step, the data user (such as a doctor) refines the intermediate decryption key locally. Specifically, after receiving the intermediate decryption key generated by AA, the doctor introduces a random secret number that is only known to them and combines it with existing key components to generate a complete decryption private key.

[0055] The specific process is as follows: ( ) This is performed by the data user (DU). Upon receiving the intermediate decryption key from the AA... Afterwards, DU generates the complete decryption private key locally to ensure that decryption capabilities are solely controlled by itself. DU first randomly selects a local secret random number. (Second random secret), making it belong to the modulus The set of non-zero integers, and calculate Then This parameter is published as a public parameter and used in subsequent ciphertext decryption calculations. Next, DU locally generates a parameter with a count of [number missing]. polynomial and order This is used to fuse its own secret randomness with the intermediate key provided by AA. Ultimately, DU is based on its own set of attributes. Calculate the complete decryption key Through this process, even if AA holds the master key and observes the protocol execution, it cannot recover DU's complete decryption private key. (Generation) Then, DU will have the ability to decrypt encrypted text in the cloud while satisfying access control policies.

[0056] Step 5: The patient performs offline signature.

[0057] This step involves the patient pre-completing the main calculations in the signature, generating an intermediate signature result independent of the specific data, and providing it to the data owner to support the rapid completion of subsequent online signatures.

[0058] The specific process is as follows: Offline signing ( → This process is performed by the patients. After generating the complete signing private key, the patients use this private key to perform calculations for the offline signing phase of the medical data, thereby reducing the computational overhead of subsequent online signing.

[0059] Specifically, Patients randomly selects a random number. k Make it belong to the model Given a set of non-zero integers, construct a random message. and random values Based on this, define the chameleon hash function. Subsequently, Patients used their own signing private key. And the attribute set S, calculate the offline signature component. .

[0060] Ultimately, the patient generates an offline signature. This offline signature is sent to the data owner, the DO. This offline signature is independent of the specific plaintext data and can be calculated in advance, significantly reducing the computational burden on patients during the actual data upload phase.

[0061] Step Six: The data owner encrypts the data.

[0062] The data owner (DO) encrypts the patient's medical data and binds access policies to control access permissions. Specifically, after obtaining the patient's plaintext data, the DO sets the corresponding access policy and encrypts the data using the system's public key and a random number, establishing a connection between the ciphertext and the attributes specified in the policy.

[0063] The specific process is as follows: Data encryption （ ）→ ， Executed by DO 。 Upon receiving the offline signature from Patients, the DO is responsible for encrypting the medical data and preparing for subsequent access control and verification. (Given a plaintext message) and access policies DO randomly selects a random number Make it belong to the model The set of non-zero integers is used to calculate the core components of the ciphertext using publicly available system parameters. DO computation This generates the final ciphertext. This encryption process tightly binds plaintext data to the access policy, ensuring that only the set of attributes satisfies the policy. Only the DO can successfully decrypt the ciphertext. After generating the ciphertext, the DO uploads it along with the subsequent online signature result to the CSP to support secure storage and controlled access.

[0064] Step 7: The data owner performs an online signature.

[0065] The data owner combines the patient's pre-generated offline signature to complete the online signature generation. Specifically, the DO uses the offline signature result to perform a simple calculation on the current ciphertext, binding the original offline signature result with the ciphertext to generate the corresponding complete signature. Finally, a complete data packet containing the ciphertext and its signature is formed and uploaded to the cloud server.

[0066] The specific process is as follows: Online signature ( → Executed by DO.

[0067] After encrypting the data, the DO uses the patient's pre-generated offline signature to compare it with the actual plaintext message. The relevant ciphertext is then used for online signing. Specifically, DO uses the core components of the ciphertext. As input, the random parameters contained in the offline signature are adaptively updated, thereby binding the offline signature to the current ciphertext.

[0068] DO based on ciphertext components Calculate new random value And based on this, the final online signature is generated. Through this online signing process, offline signatures that were originally unrelated to the specific message are effectively converted into legitimate signatures that correspond one-to-one with the current encrypted data.

[0069] DO then sent the final ciphertext. E and its corresponding online signature They are sent together to the CSP for storage.

[0070] Step 8: Data user verification signature.

[0071] After retrieving data from the cloud server, doctors first verify the signature to confirm the data's authenticity and integrity. Specifically, doctors select a set of attributes that meet the policy requirements based on their own characteristics, and then perform verification calculations using the system's public key and relevant parameters in the signature. If the verification equation holds true, it indicates that the data source is trustworthy and has not been tampered with; otherwise, it is considered invalid data and further processing is rejected.

[0072] The specific process is as follows: Signature verification ( → Executed by DU.

[0073] After DU retrieves the encrypted text and its online signature from the cloud, it first verifies the validity of the signature using publicly available system parameters to confirm the authenticity and integrity of the data. DU then selects a subset of attributes from its own attribute set that meets the threshold requirements. ,in The online signature is then verified based on this subset of attributes.

[0074] Specifically, DU checks whether the following verification equation holds true: .

[0075] If the above equation holds true, it means that the signature corresponding to the ciphertext is valid, the data was indeed generated by a legitimate patient and has not been tampered with during transmission and storage, and DU outputs a verification result of 1; otherwise, it outputs 0 and rejects subsequent data decryption operations.

[0076] Step Nine: After successful signature verification, the doctor uses their private decryption key to decrypt the ciphertext and obtain the original medical data. The doctor first determines whether their attribute set satisfies the access policy set during encryption; if so, they use the key to further reconstruct the plaintext data. If the doctor's attributes do not satisfy the access policy, the above calculations cannot be performed correctly, and no valid information can be obtained.

[0077] The specific process is as follows: Data Decryption ( → m Alternatively, ⊥, executed by DU. After successful signature verification, DU attempts to decrypt the ciphertext to recover the original plaintext. DU first sets its own decryption attribute set. Access policies contained in the ciphertext Perform matching and select a subset of attributes from the intersection that meets the threshold requirements. and .

[0078] Subsequently, DU decrypted the private key. And the ciphertext components, calculate the reconstruction factor .

[0079] Given that the attribute set satisfies the access policy, the computation can correctly reconstruct the exponent term, thus enabling DU to pass. The original plaintext message is recovered. If the attribute set of DU does not satisfy the access policy AA, the above reconstruction process cannot be completed, and the system outputs... This indicates that decryption failed.

[0080] In traditional schemes, the attribute authority holds the complete user key, posing a risk of excessive single-point power. This scheme breaks down key generation into two stages: the attribute authority generates only an intermediate key (step two), while the user constructs the complete key locally by introducing a random secret (steps three and four). This design ensures that even if the attribute authority is "honest but curious," it cannot recover any user's complete private key independently, fundamentally eliminating the risk of key escrow and achieving secure key management under the assumption of partially trusted institutions.

[0081] When encrypting data, the data owner can bind the access policy to the ciphertext (step six). Only data users whose attribute set meets the policy can recover the plaintext using their complete decryption key (step nine). This mechanism ensures that medical data can only be accessed by authorized personnel (such as doctors in specific departments or with specific titles), achieving precise control over "who can see what data" and solving the problem of data confidentiality protection.

[0082] Patients generate signatures using their own attributes (steps five and seven), and data users verify the signature's validity before decryption (step eight). The signature is bound to the specific ciphertext; any tampering with the data will result in verification failure. This mechanism ensures that the data indeed originates from legitimate patients and has not been tampered with, resolving issues of data authenticity and integrity. Simultaneously, the signing process employs a two-stage offline-online design (steps five and seven), completing the heavy computational tasks in advance, significantly reducing the real-time computational burden on resource-constrained terminal devices (such as wearable medical devices).

[0083] prove.

[0084] Proof of Correctness: In this system, authorized users can not only decrypt ciphertext but also verify the source of data files. To prove the correctness of the proposed scheme, the correctness of the decryption algorithm and signature verification algorithm is analyzed below.

[0085] Signature verification: After receiving the ciphertext and its corresponding signature, DU first needs to verify the validity of the signature to confirm the authenticity of the message source. Based on the properties of the chameleon hash function, the following relationship holds: .

[0086] The above equation shows that although the random parameters are adjusted during the online signing stage, the hash value remains unchanged, thus ensuring the consistency between the offline and online signatures during the verification stage. Therefore, the correctness of the signature can be verified using the following equation:

[0087] =

[0088] =

[0089] =

[0090] =

[0091] =

[0092] = .

[0093] Decryption proof: After receiving the intermediate attribute key from AA, DU generates its complete decryption key. When the attribute set of a DU satisfies a predefined access control policy, the decryption algorithm can guarantee the correct recovery of the original plaintext from the ciphertext. The correctness of this decryption process can be demonstrated by the following derivation:

[0094]

[0095] .

[0096] Therefore, the original plaintext can be correctly recovered in the following way: .

[0097] Security Proof: This scheme provides a formal analysis of the ABES-PTA system and proves, under standard cryptographic assumptions, that the system satisfies security properties such as unforgeability and indistinguishability. The specific analysis is as follows.

[0098] Unforgeability: If there exists a probabilistic multinomial-time adversary A If a valid signature can be forged in this scheme with a non-ignorable advantage, then there must exist a simulator. B It can solve computational CDH problems or disrupt the joint generation mechanism of attribute keys in the original scheme.

[0099] prove.

[0100] This solution employs a selective attribute set security model. (Simulator) B The following steps reduce signature forgery attacks to a low-level, difficult problem.

[0101] Initialization phase: Opponent Pre-declare challenge attribute set emulator B Receive a CDH instance and set the system master public key to Set the user's public key to Thus implicitly making Subsequently, the simulator generates global system parameters. and the master key Keep it private.

[0102] System setup phase: The simulator runs the Setup algorithm and transmits system parameters and the master public key. Send it to the adversary, and the master key Confidential. Meanwhile, the simulator randomly selects... , making Thus implicitly satisfying . Query phase: Key extraction. When the adversary has access to the attribute set... Initiate a key query and satisfy the following conditions: At that time, the simulator first constructs and expand it to , making Then define Next, the simulator constructs two polynomials. and , making and for each Random assignment Then, a signature private key component is generated: when When, define ,when When, define ,make This verifies that the private key generated in the two scenarios described above is distributed in a consistent manner.

[0103] Query phase: Query signature. The adversary can, if satisfied... attribute set The above request is for a signature. The simulator randomly selects... A set of attributes ,in Regarding the query message Simulator generates signature ,in

[0104] Challenge phase: When the opponent has not queried a message Output a valid forged signature At that time, the signature must satisfy the following verification equation:

[0105] Speculation phase:

[0106]

[0107]

[0108]

[0109]

[0110] Therefore, the simulator will return the final value. This is a solution to the computational CDH problem; otherwise, it means that the joint generation mechanism of attribute keys between the AA and the user is broken, which contradicts the security assumptions of the system. In summary, if an adversary can break this scheme with a non-negligible advantage, it must mean that the CDH difficulty problem can be solved, or the joint generation mechanism of attribute keys can be broken, thus violating the security assumptions on which this scheme relies.

[0111] Ciphertext indistinguishability: If the computational CDH problem is in a group If the difficulty lies in the middle, then this scheme can achieve the indistinguishability of ciphertext.

[0112] Proof: This solution passed the challenger test. With opponents Safe games between To define the security of the attribute encryption scheme.

[0113] Initialization phase: Opponent First, submit a challenge access strategy. Challenger Return the system public key to the adversary MP and the master key MK Keep it private.

[0114] Query Phase: During the key query phase, the adversary... It can adaptively request any set of attributes. The private key, as long as the attribute set Unsatisfied with the challenge access strategy Challengers use randomly generated... polynomial of degree and To simulate all such private keys, where the two polynomials satisfy the fixed-point condition. , here and From CDH instance For each queried attribute Its corresponding key component is generated as This distribution is consistent with the distribution in real key generation algorithms. Therefore, the adversary... It is impossible to distinguish between simulated keys and real keys.

[0115] Challenge Phase: Opponent Submit two messages of equal length , The challenger randomly selects a bit. and randomly select Then, satisfy the challenge access strategy attribute subset The following is the construction of the ciphertext. The components of the ciphertext are calculated as follows: , here All from CDH instances Therefore, there is This embeds the CDH challenge into the ciphertext. Simultaneously, a valid signature is generated. And return along with the ciphertext, that is

[0116] Guessing Phase: In this phase, the opponent outputs one bit. As its pair of random bits The conjecture; if and only if The opponent wins the safe game.

[0117] This solution constructs a simulator. B， Use the opponent The advantages of using this approach to solve the CDH problem. Given a CDH instance... emulator B set up And use these values ​​exactly as in the actual solution. The opponent All key queries initiated are performed using simulated polynomials. and This ensures that the distribution of each private key component is completely consistent with the actual scheme.

[0118] During the challenge phase, the simulator B The item is placed in the following manner Embedded into ciphertext: computation If the opponent With non-negligible advantages Distinguish messages The encryption result can also be distinguished. This means the opponent has already obtained information about... Information. Therefore, the simulator B It can be calculated And thus obtain This contradicts the assumption of the difficulty of the CDH problem.

[0119] Therefore, if there exists a probabilistic multinomial time (PPT) opponent... If the indistinguishability of ciphertext can be broken with a non-negligible probability, then there must exist a probabilistic multinomial-time simulator. B The CDH problem can be solved in polynomial time, thus violating the safety assumption of this scheme. The theorem is proved.

[0120] Example 2: This embodiment provides a working method for an IoT system based on attribute encryption and signature, including the following steps: After initialization, the attribute authorization agency generates public system parameters and a master key, and in response to requests from patients and data users, generates an intermediate signature key for patients and an intermediate decryption key for data users, respectively. The patient terminal receives the intermediate signature key sent by the attribute authorization agency, generates a complete signature private key by introducing a first random secret, performs offline signature calculation on the medical data using the complete signature private key, generates an offline signature, and sends it to the data owner. The data owner terminal receives the offline signature sent by the patient terminal, obtains the plaintext medical data and determines the access control policy, performs attribute-based encryption on the plaintext medical data using publicly available system parameters to generate ciphertext, performs online signing on the ciphertext using the offline signature to generate an online signature, and uploads the ciphertext and online signature together to the cloud service provider. Cloud service providers store encrypted data uploaded by the data owner's terminal and its corresponding online signature; After obtaining the target ciphertext and its online signature from the cloud service provider, the data user terminal verifies the online signature using publicly available system parameters. If the verification is successful, it receives the intermediate decryption key sent by the attribute authorization authority, generates a complete decryption private key by introducing a second random secret, and uses the complete decryption private key to decrypt the ciphertext and recover the plaintext medical data.

[0121] This scheme effectively disperses risk while maintaining the simplicity of a single-attribute institution architecture: the attribute authorization institution only generates an intermediate key, and the patient terminal and data user terminal each introduce their own independent first and second random secrets locally to complete the construction of the complete signing and decryption private keys. This "key collaborative generation" mechanism ensures that even if the attribute authorization institution is modeled as an "honest but curious" entity, it cannot independently recover any user's complete private key. Thus, without introducing complex mechanisms such as multi-institutional collaboration and threshold synchronization, it eliminates the risk of single-point key escrow and achieves independence from a fully trusted attribute institution.

[0122] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. An Internet of Things (IoT) system based on attribute encryption and signature, characterized in that, include: The attribute authorization authority, configured as an "honest but curious" entity, is used to generate publicly available system parameters and the master key, and to generate intermediate signature keys for patients and intermediate decryption keys for data users in response to requests from patients and data users, respectively. The patient terminal is configured to: receive an intermediate signature key sent by an attribute authorization agency, generate a complete signature private key by introducing a first random secret, perform offline signature calculation on medical data using the complete signature private key, generate an offline signature and send it to the data owner; The data owner terminal is configured to: receive offline signatures sent by the patient terminal, obtain plaintext medical data and determine access control policies, perform attribute-based encryption operations on the plaintext medical data using publicly available system parameters to generate ciphertext, perform online signature operations on the ciphertext using the offline signature to generate an online signature, and associate the ciphertext with the online signature and upload it to the cloud service provider. The cloud service provider is configured as an "honest but curious" entity to store encrypted data uploaded by the data owner's terminal and its corresponding online signature. The data user terminal is configured to: obtain the target ciphertext and its online signature from the cloud service provider, verify the online signature using publicly available system parameters, and if the verification is successful, receive the intermediate decryption key sent by the attribute authorization authority, generate a complete decryption private key by introducing a second random secret, and use the complete decryption private key to decrypt the ciphertext and recover the plaintext medical data.

2. The IoT system based on attribute encryption and signature as described in claim 1, characterized in that, The attribute authorization authority is also configured to: during system initialization, select large prime numbers to construct a cryptographic group, define a bilinear mapping, and set a global attribute set, and generate system public parameters and master keys through randomly selected secret parameters.

3. The IoT system based on attribute encryption and signature as described in claim 1, characterized in that, The patient terminal holds a set of patient attributes and requests an intermediate signature key from the attribute authorization authority based on this set of attributes. The intermediate signature key is generated by the attribute authorization authority using a threshold secret sharing method based on the patient's set of attributes.

4. The IoT system based on attribute encryption and signature as described in claim 1, characterized in that, The patient terminal introduces a first random secret to generate a complete signature private key. Specifically, a secret parameter is randomly selected locally on the patient terminal, and this secret parameter is fused with the intermediate signature key issued by the attribute authorization authority to generate a complete signature private key that is only known to the patient.

5. The IoT system based on attribute encryption and signature as described in claim 1, characterized in that, The data user terminal holds the data user's attribute set and requests an intermediate decryption key from the attribute authorization agency based on the attribute set; the intermediate decryption key is generated by the attribute authorization agency based on the data user's attribute set.

6. The IoT system based on attribute encryption and signature as described in claim 1, characterized in that, The data user terminal introduces a second random secret to generate a complete decryption private key. Specifically, a secret parameter is randomly selected locally on the data user terminal, and this secret parameter is fused with the intermediate decryption key issued by the attribute authorization authority to generate a complete decryption private key that is only known to the data user.

7. The IoT system based on attribute encryption and signature as described in claim 1, characterized in that, When the data owner terminal performs attribute-based encryption, it binds the access control policy to the ciphertext, ensuring that the data user's attribute set meets the requirements of the access control policy, thereby achieving successful decryption.

8. The Internet of Things system based on attribute encryption and signature as described in claim 1, characterized in that, The offline signature calculation performed by the patient terminal can be completed in advance; The data owner's terminal performs an online signing operation, binding the offline signature generated by the patient's terminal with the current ciphertext to generate a formal signature that corresponds one-to-one with the ciphertext.

9. The Internet of Things system based on attribute encryption and signature as described in claim 1, characterized in that, After obtaining the target ciphertext and its online signature from the cloud service provider, the data user terminal verifies the online signature using publicly available system parameters. Specifically, the data user terminal selects a subset of attributes from its held attribute set that meets the threshold requirements, and uses the attribute subset to verify and calculate each component in the online signature. If the result of the verification calculation is equal to the predetermined value in the publicly available system parameters, the verification passes, confirming that the ciphertext originates from a legitimate patient and has not been tampered with; if they are not equal, the verification fails, and subsequent decryption operations are rejected.

10. A method for operating an Internet of Things (IoT) system based on the attribute encryption and signature described in any one of claims 1-9, characterized in that, Includes the following steps; After initialization, the attribute authorization agency generates public system parameters and a master key, and in response to requests from patients and data users, generates an intermediate signature key for patients and an intermediate decryption key for data users, respectively. The patient terminal receives the intermediate signature key sent by the attribute authorization agency, generates a complete signature private key by introducing a first random secret, performs offline signature calculation on the medical data using the complete signature private key, generates an offline signature, and sends it to the data owner. The data owner terminal receives the offline signature sent by the patient terminal, obtains the plaintext medical data and determines the access control policy, performs attribute-based encryption on the plaintext medical data using publicly available system parameters to generate ciphertext, performs online signing on the ciphertext using the offline signature to generate an online signature, and uploads the ciphertext and online signature together to the cloud service provider. Cloud service providers store encrypted data uploaded by the data owner's terminal and its corresponding online signature; After obtaining the target ciphertext and its online signature from the cloud service provider, the data user terminal verifies the online signature using publicly available system parameters. If the verification is successful, it receives the intermediate decryption key sent by the attribute authorization authority, generates a complete decryption private key by introducing a second random secret, and uses the complete decryption private key to decrypt the ciphertext and recover the plaintext medical data.

Images