Verifiable revocation multi-authority attribute-based encryption method and system

Abstract

The application discloses a verifiable revocation multi-authority attribute-based encryption and decryption method and system, which comprises the following steps: when any data user is revoked, a corresponding authority attribute institution updates a revocation list and a verifiable commitment and publishes them; a data owner updates an aggregated revocation state according to the latest verifiable commitment, generates an update key based on the aggregated revocation state before and after the update, and sends the update key to a cloud server; the cloud server updates a ciphertext package according to the update key and generates a cryptographic proof for proving the correctness of the update operation of the ciphertext; any data user verifies the consistency of the revocation state and the correctness of the update operation according to the latest verifiable commitment and the cryptographic proof before decrypting the latest ciphertext package; and the data user decrypts the latest ciphertext package after the verification. Therefore, the data user can verify the correctness of the update operation of the cloud server before decryption.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and in particular to a verifiable and revocable multi-authority attribute-based encryption and decryption method and system. Background Technology

[0002] In cloud computing and multi-party data sharing scenarios, Multi-Authority Cipher Policy Attribute-Based Encryption (MA-CP-ABE) is an effective technology for achieving cross-domain, fine-grained access control. In this mechanism, data owners can formulate complex access policies to encrypt data, which can only be decrypted by users whose attributes satisfy the policy. Attributes are managed by different, independent authorities, making it ideal for cross-organizational collaboration scenarios.

[0003] However, the dynamic nature of user permissions, especially the revocation of user permissions, is a critical issue that such systems must address. When a user leaves the company or their permissions change, their access rights must be revoked promptly. In existing technologies, some solutions attempt to implement user revocation by introducing an update key and verifying it through a computation process outsourced to a cloud server. For example, when a user's attributes are revoked, an authoritative body generates an update key, which the cloud server uses to update the associated ciphertext, rendering the revoked user's old key invalid.

[0004] Nevertheless, existing technologies still have at least the following drawbacks: users cannot effectively verify whether the cloud server is performing the ciphertext update based on the latest global revocation state; the cloud server may maliciously or unintentionally use old revocation information to update the ciphertext or perform incorrect update operations; and users lack effective means to detect such improper behavior before decryption, which may make the old key of the revoked user still valid, thus greatly reducing the reliability of the entire revocation process. Summary of the Invention

[0005] This invention provides a verifiable and revocable multi-authority attribute-based encryption and decryption method and system to address the deficiency in existing technologies where the user side lacks effective means to verify whether the cloud server is performing ciphertext updates based on the latest global revocation state before decryption.

[0006] This invention provides a verifiable and revocable multi-authority attribute-based encryption / decryption method, comprising: When any data user is revoked, the corresponding authoritative attribute agency updates its revocation list and verifiable commitment and publishes it publicly. The verifiable commitment is generated based on the revocation list. The data owner updates the aggregate revocation status according to the latest verifiable commitment, and generates an update key based on the aggregate revocation status before and after the update and sends it to the cloud server. The aggregate revocation status is obtained by the data owner aggregating all the verifiable commitments. The cloud server updates the ciphertext packet according to the update key and generates a cryptographic proof to prove the correctness of the update operation of the ciphertext. The ciphertext packet is obtained by encrypting the shared data based on the aggregate revocation state. Before decrypting the latest ciphertext, any data user verifies the consistency of the revocation state and the correctness of the update operation based on the latest verifiable commitment and the cryptographic proof. After successful verification, the data user decrypts the latest encrypted packet.

[0007] In one implementation, the encryption algorithm for the shared data is an attribute-based encryption algorithm.

[0008] In one implementation, after updating the aggregate revocation status, the data owner also updates the binding identifier that has a cryptographic mapping relationship with the aggregate revocation status according to the updated aggregate revocation status, and sends the updated binding identifier to the data user who has not revoked the data. The encryption of the shared data is based on the binding identifier, and the update key is generated based on the difference between the binding identifier before and after the update; The ciphertext packet update step includes: updating the binding identifier used when encrypting the shared data according to the update key to obtain the updated ciphertext packet; The latest decryption steps of the encrypted packet include: decrypting the latest encrypted packet according to the latest binding identifier.

[0009] In one implementation, the encryption steps for the shared data include: The shared data is encrypted based on the binding identifier, the target access control policy, and the random sharing vector.

[0010] In one implementation, the target access control policy is constructed based on the Linear Secret Sharing Scheme (LSSS).

[0011] In one implementation, an initialization step is also included; The initialization steps include: The authoritative attribute agency generates the initial verifiable commitment based on the initial revocation list and publishes it publicly; The data owner aggregates multiple initial verifiable commitments to obtain an initial aggregate revocation state, and encrypts the shared data based on the initial aggregate revocation state to obtain an initial ciphertext packet, which is then sent to the cloud server.

[0012] In one implementation, the initialization step further includes: The system's common parameters are generated by the Trusted Center; Each of the aforementioned authoritative attribute institutions generates its own private master key based on the system's public parameters, and generates matching attribute private keys for each of the data users it manages based on its own private master key; The encryption of the shared data by the data owner is also based on the private master keys of each of the authoritative attribute institutions; The data user decrypts the encrypted packet based on their own attribute private key.

[0013] In one implementation, the cryptographic proof is a non-interactive zero-knowledge proof.

[0014] In one implementation, the aggregation step of the plurality of verifiable commitments includes: cryptographically accumulating the plurality of verifiable commitments.

[0015] This invention also provides a verifiable and revocable multi-authority attribute-based encryption / decryption system, comprising: The authoritative attribute agency module is used to support the corresponding authoritative attribute agency to update its revocation list and verifiable commitments and publish them publicly when any data user is revoked. The verifiable commitments are generated based on the revocation list. The data owner module is used to support the data owner in updating the aggregate revocation status according to the latest verifiable commitment, and to generate an update key based on the aggregate revocation status before and after the update and send it to the cloud server. The aggregate revocation status is obtained by the data owner by aggregating all the verifiable commitments. The cloud server module is used to support the cloud server in updating the ciphertext packet according to the update key and generating a cryptographic proof to prove the correctness of the update operation of the ciphertext packet, wherein the ciphertext packet is obtained by encrypting shared data based on the aggregate revocation state; The data user module is configured to support any data user in verifying the consistency of the revocation state and the correctness of the update operation based on the latest verifiable commitment and the cryptographic proof before decrypting the latest ciphertext packet; and to support the data user in decrypting the latest ciphertext packet after the verification is successful.

[0016] This invention provides a verifiable and revocable multi-authoritative attribute-based encryption and decryption method and system. By cryptographically binding the ciphertext to the aggregated state of revocation commitments issued by all authoritative attribute institutions, and requiring the cloud server to generate cryptographic proofs when updating the ciphertext, data users can publicly and independently verify the correctness of the cloud server's update operation before decryption, without relying on the cloud server's trustworthiness. This fundamentally solves the problem of ineffective supervision of cloud server update operations. Furthermore, by requiring both data owners and data users to operate and verify based on the "aggregated revocation state" of all authoritative attribute institutions, any inconsistent or expired revocation information issued by any authoritative institution will be detected during the data user's verification phase. This ensures the uniformity of the global revocation state and eliminates the possibility of the revoked user exploiting state inconsistency vulnerabilities for attacks. In summary, this invention constructs a secure closed loop of "verification before decryption." Data users will only decrypt after simultaneously verifying the consistency of the revocation state and the correctness of the cloud update. This mechanism prevents cloud service providers from launching rollback attacks by replaying old encrypted messages or issuing false update certificates, and also prevents revoked users from regaining decryption capabilities by colluding with cloud service providers or a single dishonest authority. The entire revocation process is transparent and traceable, achieving secure, reliable, and accountable user revocation. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the verifiable revocation multi-authority attribute-based encryption / decryption method provided by the present invention. Figure 1 ; Figure 2 This is a flowchart illustrating the verifiable revocation multi-authority attribute-based encryption / decryption method provided by the present invention. Figure 2 . Detailed Implementation

[0019] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples. The following examples are for illustrative purposes only and should not be construed as limiting the scope of the invention.

[0020] In the description of this invention, it should be noted that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing the invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0021] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "connected" and "linked" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0022] This application provides a verifiable and revocable multi-authority attribute-based encryption and decryption method and system, aiming to solve the technical problem in multi-authority attribute-based encryption (MA-ABE) systems where the user side lacks an effective means to verify whether the cloud server is performing ciphertext updates based on the latest global revocation state before decryption. This solution introduces a dual verification mechanism before decryption, constructing a secure and reliable encryption and decryption method and system that allows the user side to effectively verify whether the cloud server is correctly performing ciphertext updates before decryption.

[0023] One embodiment of this application provides a verifiable and revocable multi-authority attribute-based encryption / decryption method, specifically including: When any data user is revoked, the corresponding authoritative attribute agency performs step S110: updates its revocation list and verifiable commitment and publishes them publicly. The verifiable commitment is generated based on the revocation list.

[0024] When the data owner detects any verifiable commitment update, it executes step S120: update the aggregate revocation status according to the latest verifiable commitment, and generate an update key based on the aggregate revocation status before and after the update and send it to the cloud server. The aggregate revocation status is obtained by the data owner aggregating all verifiable commitments.

[0025] When the cloud server detects an update to the aggregate revocation status, it executes step S130: updating the ciphertext packet according to the update key and generating a cryptographic proof to demonstrate the correctness of the update operation of the ciphertext. The ciphertext packet is obtained by encrypting the shared data based on the aggregate revocation status.

[0026] Before any data user can decrypt the latest ciphertext, they must first perform step S140: verify the consistency of the revocation state and the correctness of the update operation based on the latest verifiable commitment and cryptographic proof.

[0027] Only after both verifications pass can the data user proceed to step S150: decrypt the latest ciphertext packet.

[0028] Specifically, refer to Figure 1 and Figure 2 The above method can be applied to various cross-institutional data sharing systems, such as cross-institutional medical data sharing systems. A data sharing system includes an authoritative institution 301, a data owner 302, a cloud server 303, and data users 304.

[0029] The core of the method in the above embodiments lies in the fact that when any data user's data is revoked, the corresponding authoritative authority updates its internally maintained revocation list and generates a new verifiable commitment based on the updated list, which is then publicly released to the entire network. This transforms the originally opaque and localized revocation behavior into a public and verifiable cryptographic event. By releasing a commitment instead of directly publishing the revocation list, the privacy of the revocation details is protected, and a basis is provided for subsequent verification of the consistency of the revocation status.

[0030] Furthermore, the data owner, acting as the manager of the data, continuously monitors verifiable commitments issued by all authoritative bodies. Once a new commitment is detected, the data owner updates its locally maintained aggregated revocation state based on the latest commitments from all authorities. This aggregated revocation state is a snapshot of the global revocation state. Subsequently, the data owner generates a specific update key based on the differences between the aggregated revocation states before and after the update, ensuring that the update key is precisely associated with a specific revocation event. In this way, the data owner transforms distributed revocation events into a unified instruction driving encrypted updates, providing a unique and correct input for subsequent update operations on the cloud server, avoiding update chaos caused by multiple concurrent revocation events.

[0031] Subsequently, the data owner sends the generated update key to the cloud server. The cloud server then performs the update operation on the encrypted packet stored in the cloud based on the received update key. Crucially, the cloud server must also generate a cryptographic proof during the update process to demonstrate the correctness of its update operation. This aims to address the potential malicious or erroneous behavior of cloud servers in the background technology. This cryptographic proof acts as an immutable "operation receipt," assuring the data user that the cloud server performed the update solely based on the update key provided by the data owner, and without tampering, forging, or skipping the update. By introducing a verifiable update mechanism, the cloud server is transformed from a trusted entity into a computing service provider whose behavior can be publicly audited.

[0032] In the final stage of the entire process, and crucial for ensuring a secure closed loop, no data user immediately performs decryption before requesting data from the cloud server and preparing to decrypt the latest ciphertext packet. Instead, the user first performs a double verification process. The first verification is "revocation state consistency verification," where the data user independently obtains the latest verifiable commitments from various authoritative institutions, calculates the aggregated revocation state, and compares it with the state information provided by the cloud server to ensure that they have obtained a globally consistent and up-to-date revocation view. The second verification is "update operation correctness verification," where the user uses cryptographic proof to verify whether the cloud server's update operation is genuine and accurate. This mandatory "verify first, then decrypt" step ensures that the ciphertext is not obtained by the revoked user. This is because if the cloud server has not correctly updated the ciphertext packet, the packet can still be cracked by the revoked user's old key. If the ciphertext is directly provided to the data user for decryption, the revoked user may obtain the plaintext. Through the mandatory "verify first, then decrypt" process, only encrypted packets that have passed verification will be granted decryption access. Furthermore, verified encrypted packets require the latest key to be decrypted, and users of revoked data do not possess the new key.

[0033] Therefore, this application solves the problem that the user side lacks an effective means to verify whether the cloud server performs ciphertext updates based on the "latest and consistent" global revocation state before decryption, so as to ensure that users cannot obtain plaintext data that has been revoked.

[0034] In one specific implementation, verifiable commitments are generated based on the Pedersen commitment scheme. Pedersen commitments possess perfect concealment and computational binding, typically taking the form C = g^m * h^r, where m is the message to be committed to (e.g., the hash of a revocation list), and r is a random blinding factor. The advantage of using Pedersen commitments lies in their security, which can be reduced to difficult problems such as discrete logarithms, providing a solid cryptographic security foundation for this scheme. Furthermore, Pedersen commitments exhibit homomorphism, particularly additive homomorphism, meaning that the aggregation of multiple commitments (e.g., multiplying commitments from multiple authorities) is algebraically equivalent to the summation of the commitments. This makes the computation of aggregating revocation states efficient and concise, significantly improving the system's performance and practicality.

[0035] In one specific implementation, the cryptographic proof is a non-interactive zero-knowledge proof (NIZK). NIZK allows a prover (cloud server) to prove the truth of a statement (e.g., "I have correctly updated the ciphertext") to a verifier (data user) without multiple interactions and without revealing any additional knowledge (e.g., the update key itself). It ensures both the efficiency of the verification process (completed in a single communication) and the privacy of sensitive information such as the update key, preventing potential information leakage risks. Thus, it achieves verifiability while balancing system privacy and efficiency.

[0036] In one specific implementation, the encryption algorithm for shared data is an attribute-based encryption algorithm. Attribute-based encryption (ABE) is an advanced public-key cryptosystem that implements a "one-to-many" encryption mode. The data owner defines an access policy during encryption, and only data users whose attribute set satisfies this policy can decrypt the data. Combining the verifiable revocation framework of this embodiment with attribute-based encryption can address the security challenges posed by changes in user permissions (especially revocation) in dynamic environments while achieving fine-grained access control, providing a complete technical solution for building a comprehensive, secure, and reliable data sharing system.

[0037] Furthermore, to more tightly bind the ciphertext packet to the revocation state, after updating the aggregate revocation state, the data owner can update a binding identifier that has a cryptographic mapping relationship with the updated aggregate revocation state, and securely send the updated binding identifier to the data users whose data has not been revoked. Accordingly, the encryption of shared data will be based on this binding identifier, and the update key will be generated based on the difference between the binding identifiers before and after the update. Thus, the ciphertext packet update step is concretized as updating the binding identifier embedded in the ciphertext packet according to the update key, while the decryption step requires the user to provide the latest binding identifier. By introducing the intermediate variable of the "binding identifier," a direct and computable strong correlation is established between the validity of the ciphertext packet and a specific version of the global revocation state. Any change in the revocation state will lead to a change in the binding identifier, and the latest ciphertext packet needs to be decrypted using the latest binding identifier. Only data users whose data has not been revoked can obtain the latest binding identifier, further preventing revoked users from continuing to crack the ciphertext packet.

[0038] Specifically, the encryption steps for shared data include encrypting the shared data based on a binding identifier, a target access control policy, and a random sharing vector. For example, the binding identifier can be multiplied or added with a secret number chosen during encryption, thus deeply embedding its value into the ciphertext structure. In this way, the binding identifier is no longer an external label of the ciphertext but part of its internal structure. Any attempt to decrypt or tamper with the ciphertext without updating the binding identifier will be prevented at the cryptographic level, thereby greatly enhancing the strength and security of the binding.

[0039] Furthermore, the target access control policy is built based on the Linear Secret Sharing Scheme (LSSS).

[0040] It should be noted that, in order for the entire method to start successfully, any encryption / decryption method has an initialization step.

[0041] In one specific implementation, the initialization steps of the verifiable revocation multi-authoritative attribute-based encryption and decryption method in this embodiment include: the authoritative attribute agency generates an initial verifiable commitment based on an initial revocation list and publishes it publicly; the data owner aggregates multiple initial verifiable commitments to obtain an initial aggregated revocation state, and encrypts the shared data based on the initial aggregated revocation state to obtain an initial ciphertext packet and sends it to the cloud server.

[0042] Specifically, encrypting shared data based on the initial aggregation revocation state includes: establishing an initial binding identifier that has a cryptographic mapping relationship with the initial aggregation revocation state; encrypting the shared data based on the initial binding identifier, the target access control policy, and the random sharing vector to obtain the initial ciphertext packet.

[0043] The above initialization steps provide a clear and consistent starting point for the dynamic evolution of the entire method (i.e., subsequent undoing and updates).

[0044] Furthermore, the initialization steps also include: the trusted center generating system public parameters; each authoritative attribute institution generating its own private master key based on the system public parameters, and generating matching attribute private keys for each data user it manages based on its own private master key; the data owner encrypting shared data based on the private master keys of each authoritative attribute institution; and the data user decrypting the ciphertext based on its own attribute private key.

[0045] In the process of establishing a complete system, a trusted center typically first generates system-level public parameters, such as the definition of a bilinear group, public generators, and hash functions, and publishes them to the entire network. Subsequently, each authoritative attribute authority generates its own public-private key pair (e.g., a private master key) based on these public parameters, and uses its private master key to generate matching attribute private keys for each data user within its jurisdiction, based on their attributes. When encrypting data, the data owner relies not only on the aggregated revocation status but may also need to use the public keys of each authoritative attribute authority. Correspondingly, when decrypting, data users must use attribute private keys obtained from each authoritative authority and bound to their attributes and identity. This series of detailed initialization processes constructs the complete trust foundation and key system necessary for the operation of a multi-authoritative attribute-based encryption system.

[0046] Reference Figure 2 The following example provides a detailed explanation of the verifiable revocation multi-authority attribute-based encryption / decryption method in this embodiment. The example includes: Step S1: A trusted center first generates system-level common parameters.

[0047] Given a security parameter λ, choose two prime-order cyclic groups. G and Its group hierarchy is p Select bilinear mapping and generator Define a hash function. and and define the mapping function. F Used to map strings interpreted as attributes to groups. G The elements in.

[0048] Then, randomly select group elements. and Determine the data user set and a collection of authoritative institutions And output global parameters: .

[0049] Step S2: Each authoritative attribute authority generates its own private master key based on the system's public parameters and generates an initial verifiable commitment based on the initial revocation list, and publishes it publicly.

[0050] For each authoritative attribute institution Randomly select the first secret parameter Second secret parameter And calculate public key parameters Then, the initial undo list is set to an empty set. Randomly select the third secret parameter And calculate the initial revocation commitment value. The hash value of the cancellation list is Finally, output the public parameters. and its own private master key The private master key contains the initial revocation list.

[0051] Step S3: Each authoritative attribute authority generates a matching attribute private key for each data user under its management based on its own private master key. This mainly consists of two steps: (1) Each authoritative attribute agency receives the identity information and attributes of the data users under its management.

[0052] (2) Randomly select elements from the set of real numbers and generate attribute private keys based on the identity information of the data user and the attributes they possess, including the first attribute private key subkey and the second attribute private key subkey.

[0053] Specifically, for those authorized by attribute licensing agencies Each attribute managed Randomly select a random number And calculate the first attribute private key subkey corresponding to the data user under this attribute. ,in For user identity, and the second attribute private key subkey Subsequently, the key components corresponding to each attribute are combined to obtain the attribute private key generated by the authoritative attribute authority for the data user. The attribute private key is then sent to the corresponding data user. The data user will need to use this attribute private key during the subsequent ciphertext decryption process.

[0054] Step S4: The data owner aggregates multiple initial verifiable commitments to obtain an initial aggregate revocation state, establishes an initial binding identifier that has a cryptographic mapping relationship with the initial aggregate revocation state, and encrypts the shared data based on the initial binding identifier, the target access control policy, the random sharing vector, and the private master keys of each authoritative attribute institution to obtain the initial ciphertext packet. The encryption algorithm for the shared data is an attribute-based encryption algorithm.

[0055] Specifically, let The structure of the target access control policy, wherein, For the linear secret sharing scheme matrix, Used to store matrix Each row is mapped to a corresponding property. Representation matrix The mapping relationship between each row and the corresponding authoritative attribute institution. The data owner first calculates the aggregation revocation status. ,in, , And define the revocation state root as Further calculation of the binding identifier that has a cryptographic mapping relationship with the aggregate revocation state. Subsequently, the data owner randomly selected a random number. Construct vector and And for the matrix Each line calculate and Next, randomly select a random number. And calculate the zeroth component of the ciphertext. One component of ciphertext Second component of the ciphertext Third component of the ciphertext and the fourth component of the ciphertext .in, and For matrix The x The relevant parameters are stored in the private master key of the authoritative authority corresponding to the line. Finally, the data owner outputs the ciphertext packet. .

[0056] As can be seen from the way this ciphertext packet is constructed, it requires the use of aggregated revocation status and binding identifiers that have a cryptographic mapping relationship with it, as well as the private master keys of various authoritative institutions.

[0057] The above steps complete the initialization of the verifiable and revocable multi-authority attribute-based encryption / decryption method.

[0058] Step S5: When any data user is revoked, the corresponding authoritative attribute agency updates its revocation list and verifiable commitments and publishes them publicly.

[0059] For each authoritative attribute institution First, calculate the cancellation flag. Then add it to the current cancellation list to get the updated cancellation list. Then, randomly select and calculate And a new revocation commitment Finally, authoritative institutions. Issue a new revocation commitment and the updated cancellation list Distribute to data owners.

[0060] Step S6: The data owner updates the aggregate revocation status based on the latest verifiable commitment, updates the binding identifier that has a cryptographic mapping relationship with the aggregate revocation status based on the updated aggregate revocation status, sends the updated binding identifier to the data user who has not revoked, and generates an update key based on the difference between the binding identifier before and after the update.

[0061] The data owner constructs a new revocation state root. And calculate the new binding identifier. ,in This indicates the previous binding identifier. Subsequently, the data owner generates an update key. and the generated update key This information is sent to the cloud server as a public update. Send to all data users that have not been revoked (in this example, the data owner sends the revocation status root that is mapped to the binding identifier to the data user, which is equivalent to sending the binding identifier to the data user).

[0062] Step S7: The cloud server updates the ciphertext packet based on the update key and generates a cryptographic proof to demonstrate the correctness of the update operation. This cryptographic proof is a non-interactive zero-knowledge proof.

[0063] Given a public update key The cloud server first calculates the updated ciphertext component. Then calculate the new aggregate revocation commitment. And set up a cumulative cancellation commitment ,in , Subsequently, the cloud server constructed an updated ciphertext. To verify the correctness of the update process, the cloud server was randomly selected. ,calculate Further calculations and obtained and Thus constructing a proof Finally, the cloud server outputs the updated encrypted packet. .

[0064] Step S8: When requesting the ciphertext packet, the data user performs verification of the consistency of the reversal state and the correctness of the ciphertext update.

[0065] Data users obtain the updated encrypted packet Then, the data user first calculates based on the latest revocation commitment. and Then verify whether the cumulative revocation of commitments is satisfied. And further verify the equation. Is the condition true? Output 1 if both of the above verification conditions are true; otherwise, output 0.

[0066] Step S9: After successful verification (output 1), the data user decrypts the latest encrypted packet based on the latest binding identifier and the attribute key they possess.

[0067] The user first calculates the latest binding identifier. And find the satisfaction constants in , To satisfy the access control policy's attribute set. Subsequently, the data user uses the first component of the ciphertext. The second component of the ciphertext Third component of the ciphertext Fourth component of the ciphertext and the first attribute subkey Second attribute subkey To calculate the decryption part A : .

[0068] In obtaining the decrypted part A Afterwards, the data user uses the attribute private key and follows the formula. Restoring plaintext M .

[0069] As can be seen from the above embodiments, the verifiable revocation multi-authority attribute-based encryption and decryption method in this application has the following technical effects: 1. Achieved publicly verifiable revocation: By cryptographically binding the ciphertext to the aggregated state of revocation commitments issued by all authoritative attribute institutions, and requiring the cloud server to generate cryptographic proofs when updating the ciphertext, data users can publicly and independently verify the global consistency of the revocation operation and the correctness of the cloud update before decryption, without relying on the trustworthiness of the cloud server. This fundamentally solves the problem of ineffective supervision of cloud server update operations.

[0070] 2. Ensures consistency of revocation status: By requiring data owners and data users to operate and verify based on the "aggregated revocation status" of all authoritative attribute institutions, any inconsistent or expired revocation information issued by any authoritative institution will be detected during the data user's verification stage, thereby ensuring the uniformity of the global revocation status and eliminating the possibility of the revoked user exploiting the inconsistency vulnerability for attack.

[0071] 3. Enhanced Security and Accountability: This application establishes a secure closed loop of "verify first, then decrypt." Data users will only decrypt data after simultaneously verifying the consistency of the revoked state and the correctness of the cloud update. This mechanism prevents cloud service providers from launching rollback attacks by replaying old encrypted text or issuing false update proofs, and also prevents revoked users from regaining decryption capabilities by colluding with cloud service providers or a single dishonest authority. The entire revocation process is transparent and traceable, achieving secure, reliable, and accountable user revocation.

[0072] In one embodiment of this application, a verifiable and revocable multi-authoritative attribute-based encryption and decryption system is also provided. This system aims to implement the aforementioned methods into specific functional entities and modules, realizing the technical solution of the present invention in the form of a product. Physically, this system can be deployed in a distributed network environment consisting of servers of authoritative attribute institutions, terminal devices of data owners, cloud server clusters, and terminal devices of data users.

[0073] The system specifically includes: an authoritative attribute agency module, a data owner module, a cloud server module, and a data user module. These modules are not isolated hardware units, but rather refer to software or a combination of hardware and software deployed on corresponding physical devices to achieve specific functions. Among them: The authoritative attribute agency module is used to enable the corresponding authoritative attribute agency to update its revocation list and verifiable commitments and publish them publicly when any data user is revoked. The verifiable commitments are generated based on the revocation list.

[0074] The data owner module is used to support data owners in updating the aggregate revocation status based on the latest verifiable commitments, and to generate an update key based on the aggregate revocation status before and after the update and send it to the cloud server. The aggregate revocation status is obtained by the data owner by aggregating all verifiable commitments.

[0075] The cloud server module is used to support the cloud server in updating the ciphertext packet according to the update key and generating cryptographic proofs to prove the correctness of the update operation of the ciphertext. The ciphertext packet is obtained by encrypting shared data based on the aggregated revocation state.

[0076] The data user module is used to support any data user in verifying the consistency of the revocation state and the correctness of the update operation based on the latest verifiable commitment and cryptographic proof before decrypting the latest ciphertext packet; and after the verification is successful, it supports the data user in decrypting the latest ciphertext packet.

[0077] Specifically, the authoritative attribute institution module is typically deployed on the servers of various authoritative attribute institutions (such as hospitals and research institutes). Its core function is to manage user attributes and revocation status. The data owner module typically runs on the data owner's personal computer or server. This module is the central hub for policy formulation and update initiation. The cloud server module is deployed in the data center of a cloud service provider. It plays the role of data storage and computing outsourcing. The data user module runs on the devices of the data users who ultimately need to access the data, such as mobile phones and laptops. This module is the last line of defense for security. It is used to ensure that data users, after obtaining the latest encrypted packet from the cloud server module, must perform two-factor authentication before decryption.

[0078] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0079] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0080] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A verifiable and revocable multi-authority attribute-based encryption / decryption method, characterized in that, include: When any data user is revoked, the corresponding authoritative attribute agency updates its revocation list and verifiable commitment and publishes it publicly. The verifiable commitment is generated based on the revocation list. The data owner updates the aggregate revocation status according to the latest verifiable commitment, and generates an update key based on the aggregate revocation status before and after the update and sends it to the cloud server. The aggregate revocation status is obtained by the data owner aggregating all the verifiable commitments. The cloud server updates the ciphertext packet according to the update key and generates a cryptographic proof to prove the correctness of the update operation of the ciphertext. The ciphertext packet is obtained by encrypting the shared data based on the aggregate revocation state. Before decrypting the latest ciphertext, any data user verifies the consistency of the revocation state and the correctness of the update operation based on the latest verifiable commitment and the cryptographic proof. After successful verification, the data user decrypts the latest encrypted packet.

2. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 1, characterized in that, The encryption algorithm for the shared data is an attribute-based encryption algorithm.

3. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 1, characterized in that, After updating the aggregate revocation status, the data owner also updates the binding identifier that has a cryptographic mapping relationship with the aggregate revocation status according to the updated aggregate revocation status, and sends the updated binding identifier to the data user who has not revoked the data. The encryption of the shared data is based on the binding identifier, and the update key is generated based on the difference between the binding identifier before and after the update; The ciphertext packet update step includes: updating the binding identifier used when encrypting the shared data according to the update key to obtain the updated ciphertext packet; The latest decryption steps of the encrypted packet include: decrypting the latest encrypted packet according to the latest binding identifier.

4. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 3, characterized in that, The encryption steps for the shared data include: The shared data is encrypted based on the binding identifier, the target access control policy, and the random sharing vector.

5. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 4, characterized in that, The target access control policy is constructed based on the Linear Secret Sharing Scheme (LSSS).

6. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 1, characterized in that, It also includes an initialization step; The initialization steps include: The authoritative attribute agency generates the initial verifiable commitment based on the initial revocation list and publishes it publicly; The data owner aggregates multiple initial verifiable commitments to obtain an initial aggregate revocation state, and encrypts the shared data based on the initial aggregate revocation state to obtain an initial ciphertext packet, which is then sent to the cloud server.

7. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 6, characterized in that, The initialization step also includes: The system's common parameters are generated by the Trusted Center; Each of the aforementioned authoritative attribute institutions generates its own private master key based on the system's public parameters, and generates matching attribute private keys for each of the data users it manages based on its own private master key; The encryption of the shared data by the data owner is also based on the private master keys of each of the authoritative attribute institutions; The data user decrypts the encrypted packet based on their own attribute private key.

8. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 1, characterized in that, The cryptographic proof is a non-interactive zero-knowledge proof.

9. The verifiable and revocable multi-authority attribute-based encryption / decryption method according to claim 1, characterized in that, The aggregation step of the plurality of verifiable commitments includes: cryptographically accumulating the plurality of verifiable commitments.

10. A verifiable and revocable multi-authority attribute-based encryption / decryption system, characterized in that, include: The authoritative attribute agency module is used to support the corresponding authoritative attribute agency to update its revocation list and verifiable commitments and publish them publicly when any data user is revoked. The verifiable commitments are generated based on the revocation list. The data owner module is used to support the data owner in updating the aggregate revocation status according to the latest verifiable commitment, and to generate an update key based on the aggregate revocation status before and after the update and send it to the cloud server. The aggregate revocation status is obtained by the data owner by aggregating all the verifiable commitments. The cloud server module is used to support the cloud server in updating the ciphertext packet according to the update key and generating a cryptographic proof to prove the correctness of the update operation of the ciphertext. The ciphertext packet is obtained by encrypting shared data based on the aggregate revocation state. The data user module is used to support any data user in verifying the consistency of the revocation state and the correctness of the update operation based on the latest verifiable commitment and the cryptographic proof before decrypting the latest ciphertext packet; And after successful verification, the data user is allowed to decrypt the latest encrypted packet.

Images