Anonymous cloud auditing method supporting dynamic aggregation of labels

Abstract

The invention provides an anonymous cloud auditing method supporting dynamic label aggregation, which not only can realize anonymous privacy protection for data uploaders, but also can perform dynamic label aggregation according to system operation conditions so as to improve storage efficiency. The method mainly comprises the following steps: a system initialization stage, a key generation stage, a label generation stage, a challenge stage, a response stage and a verification stage, and further comprises the following selectable execution steps: a key expansion stage and an aggregation stage. The method has the following characteristics: 1, an anonymous privacy protection function of a data uploader is realized without the help of a ring signature or group signature technology, and one data label is only composed of one group element before aggregation; 2, the aggregation operation on the data tags is supported, a plurality of data tags can be aggregated into one tag to reduce the storage overhead, the aggregated tags can execute a normal auditing process, and the aggregated index positions do not need to be subjected to overall verification, namely, the data tags can be subjected to normal auditing after being aggregated by the index positions of the tags; wherein one or more specific positions are audited.

Description

Technical Field

[0001] The present invention belongs to the field of computer security, and in particular relates to an anonymous cloud auditing method that supports dynamic tag aggregation. Background Art

[0002] In traditional cloud auditing methods, the data uploader uses a private key to calculate the label corresponding to the data, and stores the data and label on the cloud server. The third-party auditor generates a challenge through the public key of the data uploader, and performs data integrity detection through the response of the cloud server. In this process, the third-party auditor needs the public key of the data uploader, that is, the user who generates the label, to complete the calculation of the challenge, so the identity of the data uploader is usually known. However, in some scenarios, such as electronic voting and electronic auction activities, the identity privacy of the data uploader needs to be protected, and anonymous cloud auditing methods have emerged. Early anonymous cloud audits mainly relied on ring signatures and group signature technologies, that is, data labels are essentially similar to a ring signature or group signature. When a third-party auditor conducts an audit, he needs to calculate the public keys of all users in the uploader group, thereby realizing the privacy protection of the true identity of the data uploader. The idea of ​​this audit model is as follows: Figure 1 As shown. The above model can achieve an anonymous audit process, but it also brings a problem: reduced storage efficiency. Due to the characteristics of ring signatures and group signatures, the number of elements that make up a signature is usually linearly related to the number of users in the user group. Even if certain cryptographic schemes achieve a signature with a constant number of elements, it still consists of a relatively large number of elements (for example, the short group signature scheme proposed by Boneh et al. 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 an anonymous audit process without the use of ring signatures and group signatures. The data label calculated by the user is similar to a BLS signature, that is, a label consists of only one group element. Compared with previous anonymous audit 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, is an extension of BLS-based cloud auditing methods, such as Shacham-Waters cloud auditing. However, whether tag aggregation and recovery can be similarly achieved for cloud auditing methods with other structural types has not yet been studied.

[0004] With increasing attention paid to user privacy, privacy protection for the identity of data uploaders is increasingly required in practical applications. In systems such as electronic voting and electronic auctions, third parties are required to audit and notarize data integrity. Furthermore, auditors must protect the true identity of data uploaders to prevent the anonymity of voting or bidding from being compromised. Currently, a leading anonymous cloud auditing method is the work based on an extended BLS structure proposed by Wu et al. at the ISPEC 2016 conference. In this method, a data tag is similar to an extended BLS signature and consists of only one element. However, there is currently no effective solution to further improve the storage efficiency of this method, or to combine it with evolutionary labeling technology to aggregate data tags to further reduce storage overhead.

[0005] In order to achieve the above objectives, the present invention proposes an anonymous cloud audit method that supports dynamic aggregation of tags. The method has the following characteristics. 1. Dynamic aggregation of data tags is realized, and users can choose traditional anonymous audit or tag aggregation anonymous audit according to actual usage; 2. The anonymous audit process is based on the extended BLS structure data tag. The previous tag before aggregation is composed of only one element. When the user chooses to perform the aggregation operation, the parameter size for aggregation can be dynamically selected according to the usage; 3. When the user chooses to perform the aggregation operation, it is only necessary to run the key expansion algorithm to generate the extended public key and aggregation token. The subsequent challenge generation and tag aggregation operations are completed by the third-party auditor and the cloud server respectively, and the operation is transparent to the user; 4. For the user before and after aggregation, there is no significant difference in the operation and computational overhead of the algorithm. Summary of the Invention

[0006] The present invention proposes an anonymous cloud auditing method that supports dynamic tag aggregation. Based on traditional anonymous auditing, this method allows users to dynamically choose 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 operating freedom.

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

[0008] Step 1: System parameter generation phase: This is a necessary phase for system operation and is run by a trusted organization or multiple parties. Enter a security parameter 1 λ , output global system parameter gp, that is

[0009] ParamGen(1 λ )→gp;

[0010] Step 2: User key generation phase: This is a necessary phase for system operation and is run by the user. Input global system parameter gp and output public and private key pair (pk, sk), i.e.

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

[0012] Step 3: Key expansion preparation phase: The system can choose to execute the phase, which is run by the user. Input the global system parameter gp, the user's original public key pk, the private key sk, a parameter n used to represent the aggregation strength, and output the extended public key epk used for subsequent challenge calculation and the token tk used for tag aggregation. The user then sends the extended public key epk and the token tk to the third-party auditor and the cloud server respectively, that is,

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

[0014] Step 4: Label calculation phase: This is a necessary phase for system operation and is run by the user. Input global system parameters gp, private key sk and message m, output the label t corresponding to the message, and upload the message m and label t to the cloud server, i.e.

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

[0016] Step 5: Challenge generation phase: This is a necessary phase for system operation and is run by a third-party auditor. In actual applications, this phase needs to be divided into two categories based on specific circumstances. The first category is for traditional anonymous auditing, that is, anonymous auditing of data when the user chooses not to perform key expansion operations; the second category is for anonymous auditing after dynamic aggregation of tags, that is, anonymous auditing of data when the user chooses to perform key expansion operations. Input the global system parameter gp, the index set I selected by the challenge, output 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. Specifically,

[0017] ■The traditional anonymous audit process requires the input of all public keys of the data uploader group PK={pk1,…,pk u},Right now

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

[0019] ■After tags are dynamically aggregated, the anonymous audit process requires the input of all extended public keys (EPKs) of the data uploader group.

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

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

[0022] Step 6: Tag aggregation phase: The system can choose to execute the phase, which is run by the cloud server. Input the global system parameter gp, the original tag t corresponding to the message, the aggregation token tk sent by the user, and output the aggregated tag T to replace the original tag t, that is,

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

[0024] Step 7: Response calculation phase: This is a necessary phase for system operation and is run by the cloud server. In actual applications, this phase needs to be divided into two categories based on the specific tag storage situation. The first category is for the traditional anonymous audit process, that is, when the user chooses not to perform key expansion and tag aggregation operations, the data is audited anonymously; the second category is for anonymous auditing after dynamic tag aggregation, that is, when the user chooses to perform key expansion operations and the cloud server performs tag aggregation operations, the data is audited anonymously. Input the global system parameter gp, the challenge chal, the message set {m stored at the corresponding position of the index set specified in the challenge i}, output the response res, and the cloud server sends the response res to the third-party auditor for verification.

[0025] ■The traditional anonymous audit process requires re-entering the label set stored at the corresponding index position {t i},Right now

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

[0027] ■After the tags are dynamically aggregated, the anonymous audit process needs to input the aggregated tag set stored at the corresponding index position {T k},Right now

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

[0029] Step 8: Response Verification Phase: This is a necessary phase for system operation and is run by a third-party auditor. Input the global system parameter gp, challenge chal, response res, and the secret value s generated in the challenge generation phase, and output the verification result 1 or 0 (where 1 indicates audit verification passed and 0 indicates verification failed), that is,

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

[0031] As a further improvement to the present invention, the key expansion preparation phase in step 3 and the tag aggregation phase in step 6 are optional operations to implement dynamic tag aggregation. Users can freely choose whether to perform the key expansion operation. After executing this phase, an extended public key and aggregation token are generated and sent to a third-party auditor and cloud server, respectively. The third-party auditor and cloud server then use the extended public key to generate a challenge and 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, namely, one is the traditional anonymous audit process and the other is the tag aggregation anonymous audit process, as follows:

[0033] ■When the user chooses not to perform the tag aggregation operation, the third-party auditor inputs the global system parameter gp, the selected index set I, and the public keys of the data uploader group PK = {pk1,…,pk u}, outputs the challenge chal and the secret value s; in the response calculation phase, the cloud server inputs the global system parameter gp, the challenge chal, and the message set {m i} and the tag set {t i}, and calculate the response res, that is

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

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

[0036] ■When the user chooses to perform the aggregation operation, the third-party auditor inputs the global system parameter gp, the selected index set I, and the extended public key EPK of the data uploader group = {epk1,…,epk u}, outputs the challenge chal and the secret value s; in the response calculation phase, the cloud server inputs the global system parameter gp, the challenge chal, and the message set {m i} and the aggregation tag set {T k}, and calculate the response res, that is

[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 the anonymous privacy protection function of the data uploader. A data label is composed of only one group element before aggregation; the scheme supports the aggregation operation of data labels, and can aggregate multiple data labels into one label to reduce storage overhead. The aggregated label can execute the normal audit process, and there is no need to verify the aggregated multiple index positions as a whole, that is, after the aggregation of multiple label index positions, one or more specific positions can be audited. As an improvement of "dynamic aggregation" in the present invention, it is reflected in the optional execution of steps 3 and 6. The user can choose not to execute the above two steps in the early stage of system operation. At this time, the system is equivalent to the anonymous cloud audit method proposed by Wu et al., which has higher efficiency; when the system storage space is insufficient in the later stage, the user chooses to execute the above two steps again and perform label aggregation operations to free up more storage space. The user's use is more flexible and can be dynamically adjusted as needed. Compared with the existing anonymous cloud audit method, the present 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 performed by the user. When these stages are not performed, the system is equivalent to traditional anonymous auditing. After the above stages are performed, the cloud server performs tag aggregation operations, further reducing storage overhead.

[0041] (2) Users can set the number of tags involved in aggregation according to the status of the system operation, reflecting the characteristics of dynamic aggregation; (3) Challenge generation, tag aggregation, and response calculation based on aggregated tags are all completed by third-party auditors and cloud servers. Users only need to execute the key expansion algorithm, making the operation transparent to users. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figure 1 This is a framework diagram of an anonymous cloud audit system based on ring signatures and group signatures;

[0043] Figure 2 It is a process framework diagram of the present invention. DETAILED DESCRIPTION

[0044] In order to deepen the knowledge and understanding of the present invention, the technical solution is described in detail below with reference to the accompanying drawings.

[0045] Example 1: See Figure 2 , an anonymous cloud audit method that supports dynamic tag aggregation, according to the accompanying drawings, the specific implementation method of the present invention is as follows.

[0046] The present invention consists of the following stages,

[0047] Step 1: System parameter generation phase: Assume that BG(1 λ)→(e,p,G1,G2,G T ) is a bilinear group generation algorithm. The algorithm inputs the security parameter 1 λ , output prime number p-order cyclic group G1, G2, G T , where e:G1×G2→G T The system operator enters security parameters 1 λ , run BG(1 κ )→(e,p,G1,G2,G T ), then randomly select generator g1∈G1,g2∈G2 and hash function H:{0,1} * →G1,H2:G T →{0,1} 2λ , where Z p is an additive cyclic group modulo p. Output global system parameter gp,

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

[0049] Step 2: User key generation phase: The user inputs the global system parameter gp and selects a random number x∈Z p and calculate Output user public and private key pair (pk, sk)

[0050]

[0051] Step 3: Key expansion preparation phase: The user enters the global system parameter gp, public and private key pair and 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. Among them, 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 aggregation token tk consists of n-1 numbers.

[0052]

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

[0054] The user sends the extended public key epk and aggregate token tk to the third-party auditor and cloud server respectively.

[0055] Step 4: Label calculation phase: The user inputs the global system parameter gp, the private key sk=x and the message m, assigns the file identifier fid to the message and divides the message into Z according to the message space p The element m on m=(m1,m2,…),m i ∈Z p , calculate each message group m i Corresponding tags Output message m corresponding to the label t = {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 the set I i ∈Z p , randomly select c∈Z p ;in

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

[0058]

[0059] ■If the user has performed tag aggregation, enter the extended public keys of all data uploaders.

[0060]

[0061] Assume that the public and private key pair of the wth data uploader in the group is , then its extended public key is

[0062] r w,2 ,…,r w,n Indicates the random number used in the key expansion phase.

[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 response verification.

[0067] Step 6: Tag aggregation phase: The cloud server inputs the global system parameter gp, and the message m={m i}The original label t={t i}, the aggregate token tk sent by the user = {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, for each index i, calculate Then the original label t i calculate

[0068]

[0069] Then add the new tag {t i ′}According to the previous grouping, perform the multiplication operation within the group, that is, calculate the kth group Finally, the aggregated label {T k}, the cloud server stores the aggregated tags instead of the original tags {t i}, thereby reducing 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 corresponding to the index selected in the challenge {m i}, tag set {t i} and the order w of the data uploader in the group, calculate

[0072]

[0073] Output response res = (μ, σ).

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

[0075]

[0076] Calculate message group m i Corresponding evolutionary labels

[0077]

[0078]

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

[0080] The cloud server sends the response res to the 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 equation holds:

[0082]

[0083] If true, output 1, indicating that the verification is successful; otherwise, output 0, indicating that the verification fails.

[0084] The above content is only one embodiment of the present invention, and its detailed description does not limit the scope of the invention. Any modification or minor improvement made by those skilled in the art without creative work shall be included in the scope of the patent protection of the present invention.

Claims

1. An anonymous cloud audit method supporting dynamic tag aggregation, characterized in that: The method comprises the following steps: Step 1: System parameter generation phase: A necessary phase for system operation, operated by a trusted organization or multiple parties, inputting a security parameter 1 λ , output the global system parameter gp, that is ParamGen(1 λ )→gp; Step 2: User key generation phase: This is a necessary phase for system operation. It is run by the user, inputs the global system parameter gp, and outputs the public-private key pair (pk, sk), that is, KeyGen(gp)→(pk,sk); Step 3: Key expansion preparation phase: The system can choose to execute the phase, which is run by the user, input the global system parameter gp, the user's original public key pk, the private key sk, a parameter n used to represent the aggregation strength, and output the subsequent extended public key epk used to calculate the challenge and the token tk used for tag aggregation. The user then sends the extended public key epk and the token tk to the third-party auditor and the cloud server respectively, that is, KeyExt(gp,pk,sk,n)→(epk,tk); Step 4: Label calculation phase: This is a necessary phase for system operation. It is run by the user, who inputs the global system parameter gp, the private key sk and the message m, outputs the label t corresponding to the message, and uploads the message m and label t to the cloud server, i.e. TagGen(gp,sk,m)→t; Step 5: Challenge generation phase: This is a necessary phase for system operation and is run by a third-party auditor. In actual applications, this phase needs to be divided into two categories according to specific circumstances. The first category is for traditional anonymous auditing, that is, 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, that is, anonymous auditing of data when the user chooses to perform key expansion operations. The global system parameter gp is input, the index set I selected by the challenge is selected, and the challenge chal and a secret value s for verification are output. 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: The system can choose to execute the phase, which is run by the cloud server. It inputs the global system parameter gp, the original tag t corresponding to the message, and the aggregation token tk sent by the user, and outputs the aggregated tag T to replace the original tag t, that is, Aggregate(gp,t,tk)→T; Step 7: Response calculation phase: This is a necessary phase for system operation and is run by the cloud server. In actual applications, this phase needs to be divided into two categories according to the specific label storage situation. The first category is for the traditional anonymous audit process, that is, the data is audited anonymously when the user chooses not to perform key expansion and label aggregation operations; the second category is for anonymous auditing after dynamic label aggregation, that is, the user chooses to perform key expansion operations and the cloud server performs anonymous auditing of data after the label aggregation operation is completed. Enter 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 }, output the response res, the cloud server sends the response res to the third-party auditor for verification, Step 8: Response verification phase: a necessary phase for system operation, run by a third-party auditor, inputting the global system parameter gp, the challenge chal, the response res and the secret value s generated in the challenge generation phase, and outputting the verification result 1 or 0 (where 1 indicates that the audit verification is passed and 0 indicates that the verification fails), that is, Verify(params,chal,res,s)→1 / 0.

2. According to claim 1, an anonymous cloud audit method supporting dynamic tag aggregation is characterized in that: The key expansion phase in step 3 is an optional execution phase. It is up to the user to decide whether to execute it, reflecting the dynamic aggregation operation of tags. When the user decides to execute the operation, the extended key and aggregation token are generated and sent to the third-party auditor and the cloud server respectively; subsequently, the third-party auditor uses the extended key to generate a new challenge, and the cloud server performs the tag aggregation operation.

3. According to claim 1, an anonymous cloud audit method supporting dynamic tag aggregation is characterized in that: The challenge phase in step 5 is divided into two categories to apply the dynamic aggregation operation of tags, as follows: In the traditional audit process, a third-party auditor uses all the public keys of the data uploader group to generate a challenge to ensure the identity privacy of the real data uploader; the tag aggregation anonymous audit process requires the user to first choose to perform a key extension operation, generate an extended public key and send it to the third-party auditor, and then the third-party auditor uses all the extended public keys of the data uploader group to generate a challenge, which can also ensure the identity privacy of the real data uploader.

4. According to claim 1, an anonymous cloud audit method supporting dynamic tag aggregation is 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 choose to perform a key expansion operation and generate an aggregation token to send to the cloud server to realize the dynamic aggregation function of tags.

5. According to claim 1, an anonymous cloud audit method supporting dynamic tag aggregation is characterized in that: The response phase in step 7 is divided into two cases to apply the dynamic aggregation operation of tags, as follows: When the user chooses not to perform the tag aggregation operation, the response phase is similar to other anonymous cloud auditing methods, and the third-party auditor calculates the response result using the stored message set and tag set; When the user chooses to perform a tag aggregation operation, the cloud server first locates the tag aggregation result according to the index position specified in the challenge, then calculates the evolved tag corresponding to the index position based on the aggregated tag, and then calculates the response result using the stored message set and evolved tag set.

Images