An anonymous cloud auditing method that supports dynamic tag aggregation

Abstract

The present invention proposes an anonymous cloud auditing method that supports dynamic aggregation of tags. It can not only achieve anonymous privacy protection for data uploaders but also dynamically aggregate tags according to the system operation status to improve storage efficiency. It mainly consists of the following steps: system initialization stage, key generation stage, tag generation stage, challenge stage, response stage, verification stage, and also includes the following optional steps: key expansion stage, aggregation stage. This method has the following characteristics: 1. It does not rely on ring signature or group signature technology to achieve the anonymous privacy protection function of data uploaders. A data tag is composed of only one group element before aggregation; 2. It supports aggregation operations on data tags. Multiple data tags can be aggregated into one tag to reduce storage overhead. The aggregated tags can execute the normal audit process without the need to verify the aggregated multiple index positions as a whole. That is, it can audit one or more specific positions after the aggregation of multiple tag index positions.

Description

Technical Field

[0001] This invention belongs to the field of computer security, specifically relating to an anonymous cloud auditing method that supports dynamic tag aggregation. Background Technology

[0002] In traditional cloud auditing methods, data uploaders use their private keys to calculate tags corresponding to the data and store the data and tags on a cloud server. Third-party auditors generate challenges using the uploader's public key and perform data integrity checks based on the cloud server's response. In this process, the third-party auditor needs the uploader's public key (i.e., the user who generated the tags) to complete the challenge calculation, thus usually possessing the uploader's identity. However, in certain scenarios, such as electronic voting and electronic auctions, it is necessary to protect the privacy of the uploader's identity, leading to the development of anonymous cloud auditing methods. Early anonymous cloud auditing primarily relied on ring signatures and group signatures, meaning the data tag essentially resembled a ring signature or group signature. Third-party auditors need the public keys of all users in the uploader group to perform the calculation, thus achieving true privacy protection for the uploader's identity. The core idea of ​​this auditing model is as follows: Figure 1 As shown. The above model can achieve anonymous auditing, but it also brings a problem: decreased storage efficiency. Due to the characteristics of ring signatures and group signatures, the number of elements in a signature is usually linearly related to the number of users in the user group. Even if some cryptographic schemes achieve a signature with a constant number of elements, it still consists of a relatively large number of elements (e.g., the short group signature scheme proposed by Boneh et al., which contains 11 elements). To address this problem, Wu et al. (Wu et al.: Privacy-Preserving Cloud Auditing with Multiple Uploaders. ISPEC 2016) proposed an anonymous cloud auditing algorithm based on an extended BLS structure. This scheme achieves anonymous auditing without relying on ring signatures and group signatures. The data tag calculated by the user is similar to a BLS signature, that is, a tag consists of only one group element. Compared with previous anonymous auditing work, this method greatly saves storage space and improves storage efficiency.

[0003] To further improve the storage efficiency of traditional cloud auditing processes, data tags can be aggregated to reduce storage overhead. This approach, also known as evolutionary tagging technology, extends cloud auditing methods based on BLS structures, such as Shacham-Waters cloud auditing. However, whether tag aggregation and recovery can be achieved in the same way for other cloud auditing methods with different structures remains unresearched.

[0004] With increasing emphasis on user privacy, more and more scenarios in practical applications require privacy protection for the identity of data uploaders. In systems such as electronic voting and electronic auctions, on the one hand, third-party auditing and notarization of data integrity are needed; on the other hand, the true identity of the data uploader must be protected for auditors to prevent the anonymity of voting or bidding from being compromised. Currently, a major anonymous cloud auditing method is the work proposed by Wu et al. at ISPEC 2016, based on an extended BLS structure. In this method, a data tag is similar to an extended BLS signature, consisting of only one element. However, there are currently no effective solutions for further improving the storage efficiency of this method, or for combining it with evolutionary tagging technology to aggregate data tags and further reduce storage overhead.

[0005] To achieve the above objectives, this invention proposes an anonymous cloud auditing method supporting dynamic tag aggregation. This method has the following characteristics: 1. It enables dynamic aggregation of data tags, allowing users to choose between traditional anonymous auditing or tag aggregation anonymous auditing based on their actual usage; 2. The anonymous auditing process is based on extended BLS structure data tags. Before aggregation, a tag consists of only one element. When a user chooses to perform an aggregation operation, the aggregation parameter size can be dynamically selected based on usage; 3. When a user chooses to perform an aggregation operation, only the key expansion algorithm needs to be run to generate an extended public key and an aggregation token. Subsequent challenge generation and tag aggregation operations are completed by a third-party auditor and the cloud server, respectively, making the operation transparent to the user; 4. For the user, there is no significant difference in the algorithm's execution and computational overhead before and after aggregation. Summary of the Invention

[0006] This invention proposes an anonymous cloud auditing method that supports dynamic tag aggregation. Based on traditional anonymous auditing, this method allows users to dynamically select how to aggregate data tags to save storage space, thereby further realizing an anonymous cloud auditing function with high storage efficiency, while giving users more flexible operational freedom.

[0007] To achieve the above objectives, the technical solution of the present invention is as follows: an anonymous cloud auditing method supporting dynamic tag aggregation, the method comprising the following steps:

[0008] Step 1: System Parameter Generation Phase: A necessary phase for system operation, run by a trusted organization or multiple parties. Input a security parameter 1. λ Output the global system parameter gp, i.e.

[0009] ParamGen(1 λ → gp;

[0010] Step 2: User Key Generation Stage: A necessary stage for system operation, run by the user. Input the global system parameter gp, output the public / private key pair (pk, sk), i.e.

[0011] KeyGen(gp)→(pk,sk);

[0012] Step 3: Key Expansion Preparation Phase: This is an optional phase that can be executed by the user. Inputs include the global system parameter gp, the user's original public key pk, private key sk, and a parameter n representing the aggregation strength. Outputs the expanded public key epk used for challenge calculation and the token tk used for tag aggregation. The user then sends the expanded public key epk and the token tk to a third-party auditor and a cloud server, respectively.

[0013] KeyExt(gp,pk,sk,n)→(epk,tk);

[0014] Step 4: Tag Calculation Phase: A necessary stage for system operation, run by the user. Input global system parameters gp, private key sk, and message m; output the tag t corresponding to the message; and upload message m and tag t to the cloud server.

[0015] TagGen(gp,sk,m)→t;

[0016] Step 5: Challenge Generation Phase: A necessary phase for system operation, run by a third-party auditor. This phase, in practical applications, needs to be divided into two categories depending on the specific circumstances. The first category is for traditional anonymous auditing, i.e., anonymous auditing of data when the user chooses not to perform key expansion operations; the second category is for anonymous auditing after dynamic tag aggregation, i.e., anonymous auditing of data when the user chooses to perform key expansion operations. Inputs include the global system parameter `gp`, the index set `I` selected for the challenge, and the outputs a challenge `chal` and a secret value `s` for verification. The third-party auditor sends the challenge `chal` to the cloud server and retains the secret value `s` for response verification. Specifically...

[0017] ■ Traditional anonymous auditing processes require inputting the complete public keys PK = {pk1, ..., pk} of the data uploader group. u},Right now

[0018] Challenge(gp,I,PK)→(chal,s);

[0019] ■After tag dynamic aggregation, the anonymous auditing process requires inputting the entire extended public key (EPK) of the data uploader group.

[0020] {epk1,…,epk u},Right now

[0021] Challenge(gp,I,EPK)→(chal,s);

[0022] Step 6: Tag Aggregation Phase: This is an optional execution phase for the system, run by the cloud server. Inputs include the global system parameter `gp`, the original tag `t` corresponding to the message, and the aggregation token `tk` sent by the user. Output is the aggregated tag `T` replacing the original tag `t`.

[0023] Aggregate(gp,t,tk)→T;

[0024] Step 7: Response Computation Phase: A necessary phase for system operation, run by the cloud server. In practical applications, this phase needs to be divided into two categories based on the specific tag storage situation. The first category is for traditional anonymous auditing processes, i.e., anonymous auditing of data when the user chooses not to perform key expansion and tag aggregation operations; the second category is for anonymous auditing after dynamic tag aggregation, i.e., anonymous auditing of data after the user chooses to perform key expansion operations and the cloud server has completed the tag aggregation operations. Input global system parameters gp, challenge chal, and the message set {m} stored at the corresponding location of the index set specified in the challenge. i The cloud server outputs a response, `res`, which is then sent to a third-party auditor for verification. Specifically...

[0025] ■ Traditional anonymous auditing processes require inputting the tag set {t} stored at the corresponding index location. i},Right now

[0026] Response(params, chal, {m i},{t i})→res;

[0027] ■After dynamic tag aggregation, the anonymous auditing process requires inputting the aggregated tag set {T} stored at the corresponding index location. k},Right now

[0028] Response(params, chal, {m i},{T k})→res;

[0029] Step 8: Response Verification Phase: A necessary phase for system operation, run by a third-party auditor. Inputs include the global system parameter `gp`, the challenge `chal`, the response `res`, and the secret value `s` generated during the challenge generation phase. Outputs a verification result of 1 or 0 (where 1 indicates successful audit verification, and 0 indicates verification failure).

[0030] Verify(params,chal,res,s)→1 / 0.

[0031] As a further improvement of the present invention, the key expansion preparation stage in step 3 and the tag aggregation stage in step 6 are optional operations to achieve the function of dynamic tag aggregation. Users can freely choose whether to perform the key expansion operation. When this stage is performed, an extended public key and an aggregation token are generated and sent to the third-party auditor and the cloud server respectively. The third-party auditor and the cloud server then use the extended public key to generate a challenge and an aggregation token respectively for tag aggregation.

[0032] As a further improvement of the present invention, the challenge phase in step 5 and the response phase in step 7 are further divided into two categories: one is the traditional anonymous audit process, and the other is the tag aggregation anonymous audit process, as detailed below:

[0033] ■ When the user chooses not to perform tag aggregation, the challenge generation phase involves a third-party auditor inputting the global system parameter gp, the selected index set I, and the public keys PK = {pk1, ..., pk} of the data uploader group. u}, output the challenge chal and secret value s; in the response computation phase, the cloud server inputs the global system parameter gp, the challenge chal, and the message set {m} stored at the corresponding position of the index set specified in the challenge. i} and label set {t i} and calculate the response res, i.e.

[0034] Challenge(gp,I,PK)→(chal,s);

[0035] Response(gp,chal,{m i},{t i})→res;

[0036] ■ After the user selects to perform the aggregation operation, the challenge generation phase involves a third-party auditor inputting the global system parameter gp, the selected index set I, and the extended public keys EPK = {epk1, ...,epk} of the data uploader group. u}, output the challenge chal and secret value s; in the response computation phase, the cloud server inputs the global system parameter gp, the challenge chal, and the message set {m} stored at the corresponding position of the index set specified in the challenge. i} and aggregate tag set {T k} and calculate the response res, i.e.

[0037] Challenge(gp,I,EPK)→(chal,s);

[0038] Response(gp,chal,{m i},{T k})→res.

[0039] The above scheme does not rely on ring signature or group signature technology to achieve anonymity and privacy protection for data uploaders. A data tag consists of only one group element before aggregation. This scheme supports data tag aggregation operations, allowing multiple data tags to be aggregated into one tag to reduce storage overhead. The aggregated tag can undergo normal auditing processes without requiring overall verification of multiple index positions. Auditing can be performed on one or more specific positions after aggregation from multiple tag index positions. As an improvement to the "dynamic aggregation" in this invention, steps 3 and 6 are optional. Users can choose not to execute these two steps in the early stages of system operation, at which point the system is equivalent to the anonymous cloud auditing method proposed by Wu et al., which has high efficiency. When system storage space is insufficient later, users can then choose to execute the above two steps to perform tag aggregation operations to free up more storage space. This provides greater flexibility for users, allowing for dynamic adjustments as needed. Compared with existing anonymous cloud auditing methods, this invention has the following characteristics:

[0040] (1) Supports dynamic aggregation of data tags. The key expansion preparation and tag aggregation stages are optional and can be executed by the user. Without executing these stages, the system is equivalent to traditional anonymous auditing. After executing these stages, the cloud server performs tag aggregation operations, further reducing storage overhead.

[0041] (2) Users can set the number of tags participating in the aggregation according to the system's running status, reflecting the characteristics of dynamic aggregation; (3) Challenge generation, tag aggregation, and response calculation based on aggregated tags are all completed by the third-party auditor and the cloud server. Users only need to execute the key expansion algorithm to achieve transparency of user operations. Attached Figure Description

[0042] Figure 1 A framework diagram of an anonymous cloud auditing system based on ring signatures and group signatures;

[0043] Figure 2 This is a flowchart of the present invention. Detailed Implementation

[0044] To enhance understanding of the present invention, the technical solution will be described in detail below with reference to the accompanying drawings.

[0045] Example 1: See Figure 2 An anonymous cloud auditing method that supports dynamic tag aggregation is described in the accompanying drawings. The specific implementation of this invention is as follows.

[0046] This invention consists of the following stages,

[0047] Step 1: System parameter generation stage: Assume BG(1 λ→ (e,p,G1,G2,G) T This is a bilinear group generation algorithm. The algorithm takes a security parameter of 1 as input. λ Output the prime number p-order cyclic group G1, G2, G... T Where e: G1×G2→G T The system operator inputs security parameter 1. λ Run BG(1) κ → (e,p,G1,G2,G) T Then, randomly select generators g1∈G1, g2∈G2 and hash function H:{0,1}. * →G1,H2:G T →{0,1} 2λ Z p This is an additive cyclic group modulo p. Output the global system parameter gp.

[0048] gp=(e,p,G1,G2,G T ,g1,g2,H,H2).

[0049] Step 2: User Key Generation Stage: The user inputs the global system parameter gp and selects a random number x∈Z. p And calculate Output the user's public / private key pair (pk, sk)

[0050]

[0051] Step 3: Key Expansion Preparation Phase: The user inputs the global system parameter gp, public / private key pair Given a parameter n representing the aggregation strength, calculate 2n group elements. Select n-1 random numbers r2, r3, ..., r n ∈Z p And calculate tk l =x 1-l +xr l ,l∈[2,n], output extended public key And the aggregate token tk. The extended public key epk consists of two parts: a 2n-dimensional vector epk. v and an extended matrix epk with n-1 rows and n columns m The aggregate token tk consists of n-1 numbers.

[0052]

[0053] tk={tk2,…,tk n};

[0054] Users send the extended public key epk and the aggregate token tk to the third-party auditor and the cloud server, respectively.

[0055] Step 4: Tag Calculation Phase: The user inputs the global system parameter gp, the private key sk=x, and the message m. A file identifier fid is assigned to the message, and the message is divided into Z according to the message space. p The elements m = (m1, m2, ...), m i ∈Z p Calculate each message group m i Corresponding tags The label t corresponding to the output message m is {t} i User-uploaded message m = {m} i} and the corresponding label t={t i To the cloud server.

[0056] Step 5: Challenge Generation Phase: The third-party auditor inputs the global system parameter gp, selects the challenge index set I, and selects a random number v for each index i∈I in set I. i ∈Z p Randomly select c∈Z p ;in

[0057] ■ If the user has not yet performed tag aggregation, enter the full public keys of the data uploader group. calculate as well as Output challenge chal and secret value s

[0058]

[0059] ■ If the user has already performed tag aggregation, enter the full extended public key of the data uploader group.

[0060]

[0061] Suppose the public / private key pair of the w-th data uploader in the group is... Then its extended public key is

[0062] r w,2 ,…,r w,n The random numbers used in the key expansion stage are:

[0063]

[0064] calculate as well as in

[0065]

[0066] Output Challenge and secret value The third-party auditor sends the challenge chal to the cloud server and saves the secret value s for verification of the response.

[0067] Step 6: Tag Aggregation Stage: The cloud server inputs the global system parameter gp, and the message m = {m i The corresponding original label t = {t} i The aggregate token tk sent by the user is {tk2, ...,tk}. n},tk l =x 1-l +xr l ,l∈[2,n], the corresponding original label {t i} Divide into groups of n, where First, calculate for each index i. Then, for the original tag t i calculate

[0068]

[0069] Then add the new tag {t i ′ Based on the previous groupings, perform multiplication within each group, that is, calculate the multiplication operation for the k-th group. Finally, the aggregate label {T} is output. k The cloud server stores aggregated tags to replace the original tags {t}. i This reduces storage overhead.

[0070] Step 7: Response Verification Phase: The cloud server inputs the global system parameter gp and challenges chal, where...

[0071] ■If the user has not yet performed tag aggregation, then Find the message set {m} corresponding to the index selected in the challenge. i}, tag set {t i} and the order w of the data uploader in the group, calculate

[0072]

[0073] The output response is res = (μ, σ).

[0074] ■If the user has already performed tag aggregation, then Find the message set {m} corresponding to the index selected in the challenge. i}, the set of aggregate tags to which the index position belongs {T k} and the order w of the data uploaders in the group, first calculate μ = ∑ i∈Iv i ·m i Then calculate based on index i and its associated aggregation tag T k The extended public key of the w-th data uploader in

[0075]

[0076] Calculate message packet m i Corresponding evolution tags

[0077]

[0078]

[0079] calculate And output the response res = (μ, σ).

[0080] The cloud server will send the response 'res' to a third-party auditor.

[0081] Step 8: Response Verification Phase: The third-party auditor inputs the global system parameter gp, the challenge chal, the response res = (μ, σ), and the secret value s generated in the challenge phase, and determines whether the following equations hold true:

[0082]

[0083] If the verification is successful, output 1; otherwise, output 0 to indicate that the verification failed.

[0084] The above description is merely one embodiment of the present invention and is detailed, but it should not be construed as limiting the scope of the patent. Any modifications or minor improvements made by those skilled in the art without inventive effort are similarly included within the scope of patent protection of this invention.

Claims

1. An anonymous cloud auditing method supporting dynamic tag aggregation, characterized in that, The method includes the following steps: Step 1: System Parameter Generation Phase: A necessary phase for system operation, run by a trusted organization or multiple parties, inputting a security parameter 1. λ Output the global system parameter gp, i.e. ParamGen(1 λ )→gp; Step 2: User Key Generation Stage: A necessary stage for system operation, run by the user. The user inputs the global system parameter gp and outputs a public / private key pair (pk, sk). KeyGen(gp)→(pk,sk); Step 3: Key Expansion Preparation Phase: This is an optional execution phase run by the user (data uploader). Inputs include the global system parameter gp, the user's original public key pk, private key sk, and a parameter n representing the aggregation strength. Outputs the expanded public key epk used for challenge calculation and the token tk used for tag aggregation. The user then sends the expanded public key epk and the token tk to a third-party auditor and the cloud server, respectively. KeyExt(gp,pk,sk,n)→(epk,tk); Step 4: Tag Calculation Phase: A necessary phase for system operation, run by the user. Inputting the global system parameter gp, private key sk, and message m, the system outputs the tag t corresponding to the message and uploads message m and tag t to the cloud server. TagGen(gp,sk,m)→t; Step 5: Challenge Generation Phase: This is a necessary phase for system operation, run by a third-party auditor. In practice, this phase is divided into two categories depending on the specific circumstances. The first category is for traditional anonymous auditing, where data is audited anonymously when the user chooses not to perform key expansion. The second category is for anonymous auditing after dynamic tag aggregation, where data is audited anonymously when the user chooses to perform key expansion. The third-party auditor inputs the global system parameter `gp`, selects the challenge index set `I`, and if the user chooses not to perform key expansion, inputs all public keys of the data uploader group; if the user chooses to perform key expansion, inputs all expanded public keys of the data uploader group. The auditor outputs the challenge `chal` and a secret value `s` for verification. The third-party auditor sends the challenge `chal` to the cloud server and retains the secret value `s` for response verification. Step 6: Tag Aggregation Phase: This is an optional execution phase for the system, run by the cloud server. Inputs include the global system parameter `gp`, the original tag `t` corresponding to the message, and the aggregation token `tk` sent by the user. Output is the aggregated tag `T` replacing the original tag `t`. Aggregate(gp,t,tk)→T; Step 7: Response Calculation Phase: This is a necessary phase for system operation, run by the cloud server. In practical applications, this phase needs to be divided into two categories based on the specific tag storage situation. The first category is for traditional anonymous auditing processes, i.e., anonymous auditing of data when the user chooses not to perform key expansion and tag aggregation operations; the second category is for anonymous auditing after dynamic tag aggregation, i.e., anonymous auditing of data after the user chooses to perform key expansion operations and the cloud server has completed tag aggregation operations. The cloud server inputs the global system parameter gp, challenges chal, and stores the message set {m} at the corresponding location of the index set specified in the challenge. i The system outputs a response `res`. When the user chooses not to perform tag aggregation, the response result is calculated using the stored message set and tag set. When the user chooses to perform tag aggregation, the cloud server first locates the corresponding aggregation tag based on the index position specified in the challenge, then calculates the evolution tag corresponding to the index position based on the aggregation tag, and then calculates the response result using the stored message set and evolution tag set. The cloud server sends the response `res` to a third-party auditor for verification. Step 8: Response Verification Stage: A necessary stage for system operation, run by a third-party auditor. Inputs are the global system parameter `gp`, the challenge `chal`, the response `res`, and the secret value `s` generated during the challenge generation stage. The output is a verification result of 1 or 0, where 1 indicates successful audit verification and 0 indicates verification failure. Verify(params,chal,res,s)→1 / 0.

2. The anonymous cloud auditing method supporting dynamic tag aggregation according to claim 1, characterized in that, The key expansion stage in step 3 is an optional execution stage, which is decided by the user. It reflects the dynamic aggregation operation of tags. When the user decides to execute the operation, an expansion key and an aggregation token are generated and sent to the third-party auditor and the cloud server respectively. Subsequently, the third-party auditor uses the expansion key to generate a new challenge, and the cloud server performs the tag aggregation operation.

3. The anonymous cloud auditing method supporting dynamic tag aggregation according to claim 1, characterized in that, The aggregation stage in step 6 implements the aggregation operation of data tags to reduce storage overhead. At the same time, the tag aggregation operation requires the user to first select to perform the key extension operation and generate an aggregation token to send to the cloud server to realize the dynamic aggregation function of tags.

Images