An aggregation and recovery method for data auditing tags based on linear homomorphism verifiers

Abstract

The application provides an aggregation and recovery method for data auditing tags based on a linear homomorphism verifier, which is mainly used for aggregating a large number of tags in a data auditing system based on a linear homomorphism verifier which has been deployed and put into use at present, so as to save storage space; meanwhile, the aggregated tags can be recovered to complete data auditing. The method comprises the following steps: a key expansion stage, a token generation stage, a tag aggregation stage, a challenge stage, a response stage and a verification stage. The public parameters of the scheme system are consistent with the original system, a new initialization algorithm is not needed to generate the public parameters, the change to the original system is minimized, and the method is a general technology which can not only realize the aggregation and recovery of tags in the existing system under a traditional public key system, but also can be directly used for construction under an identity system and a certificateless system.

Description

Technical Field

[0001] This invention belongs to the field of computer security, specifically relating to a method for the aggregation and recovery of data audit tags based on linear homomorphic validators. Background Technology

[0002] Cloud storage is a crucial component of cloud computing technology, providing users with secure storage services for large-scale data. In cloud storage systems, data security and service pricing are paramount concerns for users and are key to service operators enhancing product competitiveness and market share. Data integrity is a core requirement of information system security, demanding that user data stored on the server not be illegally tampered with, deleted, or added to. To ensure the integrity of cloud storage data, cloud auditing technology has emerged. In a storage system providing cloud auditing, users upload data and simultaneously perform calculations to generate corresponding tags, uploading both the data and tags together. A third-party auditor, based on the user's basic information and storage status, audits the data on behalf of the user. First, a challenge is generated and sent to the cloud server. Upon receiving the challenge, the cloud server uses the stored data and tags to calculate the correct response and returns it to the third-party auditor. The auditor then verifies the response and informs the user of the audit results. To pass integrity auditing, the cloud server must properly store the user's data and tags to calculate the correct response, thereby ensuring the integrity of the user's data.

[0003] Current cloud auditing technologies have formed a relatively mature system. One mainstream technical approach is the Linear Homomorphic Authenticator (LHA) tool proposed by Shacham and Waters in 2008. Tags constructed using this tool possess linear homomorphic properties. Therefore, third-party auditors can select any number of storage location indexes to challenge during the audit process. The final challenge can be calculated using the homomorphic property as a constant number of elements. Simultaneously, the cloud server can also use the homomorphic property to calculate the response result of a constant number of elements from the data and tags corresponding to the multiple storage locations specified in the challenge. Throughout the entire audit process, the communication overhead is constant and independent of the number of selected location indexes. The LHA technology is widely adopted due to its low communication overhead and high computational efficiency. However, a common characteristic of this technology is that a data tag is similar to a digital signature, specifically a group element. In practical implementations, the size of a tag is the same as the data. Therefore, in auditing schemes using this technology, users not only need to store the data on the cloud server but also need to store tags of the same size as the data, resulting in a storage efficiency of 50%, which needs further improvement.

[0004] To address the aforementioned issues, Susilo et al. (W. Susilo et al.: Public Cloud Data Auditing Revisited: Removing the Tradeoff Between Proof Size and Storage Cost. ESORICS 2022) proposed a significant improvement in 2022: the evolution tag technique. This technique allows for tag aggregation and recovery while preserving the linear homomorphic property of tags. The only noteworthy point is that tag aggregation does not recover the original tags; instead, it recovers tag elements defined on a different group, called evolution tags. Although evolution tags differ from the original tags, they still retain the homomorphic property of the original tags and can therefore still be used for data auditing. This technique represents a significant improvement over current data auditing methods based on linear homomorphic validators. Tag aggregation can save substantial storage space, providing a highly storage-efficient data auditing method.

[0005] For data auditing systems that are not yet implemented or are planned for future deployment, the method proposed by Susilo can achieve the goal of high storage efficiency. However, for many systems that have already been deployed and put into use, there is currently no relevant research on how to upgrade and transform them. On the one hand, Shacham and Waters' linear homomorphic verifier technique, proposed in 2008, has been widely adopted and extended. The original article published by Shacham and Waters in 2008 (H. Shacham, B. Waters: Compact Proofs of Retrievability. ASIACRYPT 2008) has been cited more than 2000 times. On the other hand, many users are already familiar with the systems currently deployed and put into use, making a direct switch to a new system unsuitable. For example, deploying a new solution means updating the public parameters of the entire system and requiring users to regenerate their public and private key pairs. This operation will affect all users of the system, forcing them to upgrade, which may have a significant impact on some users who have purchased long-term membership services. Regenerating public and private key pairs means that users need to reapply for public key certificates and pay for them, which is an additional expense for many users who have just updated their public key certificates or whose public key certificates have not yet expired. Another important issue is that for systems that are already in use, data owners have already generated and stored a large number of data tag pairs, and there is no relevant research on how to process these existing tags.

[0006] To address the aforementioned issues, this invention proposes a method for the aggregation and recovery of data audit tags based on linear homomorphic validators. This method represents a transition from existing linear homomorphic validator-based data auditing methods to the improved method proposed by Susilo et al. Based on currently deployed and running systems, using existing publicly available system parameters, users can freely choose whether to upgrade. For users who choose to upgrade, their public key certificates can continue to be used until their expiration date, and the extended public key can be verified using the current public key. Existing tags can also be aggregated to save storage space, thereby achieving high storage efficiency in data auditing. Furthermore, this method has the following characteristics: during the token generation phase, users only need to authorize once; the server and third-party auditors can respectively use the authorized token for tag aggregation and challenge generation operations; this method is a general-purpose technology that can not only achieve tag aggregation and recovery in existing systems under traditional public key systems, but can also be directly used for construction under identity-based and certificate-free systems. Summary of the Invention

[0007] This invention proposes a method for the aggregation and recovery of data audit tags based on linear homomorphic validators. This method allows for the upgrading of an existing data auditing system, such as the method proposed in the Shacham-Waters 2008 paper, to a data auditing system with high storage efficiency, such as the method proposed in the Susilo et al. 2022 paper.

[0008] This invention is achieved through the following techniques.

[0009] A method for aggregation and recovery of data audit tags based on linear homomorphic validators, based on the current system public parameters params, the original public-private key pair (pk, sk) of the data owner, and a parameter n, consists of the following steps:

[0010] Step 1: Key Expansion Phase: Based on the currently public parameters params, the data owner inputs the original public key pk, private key sk, and parameter n, and outputs the expanded public key epk, i.e.

[0011] KeyExp(params,pk,sk,n)→epk;

[0012] Step 2: Token Generation Phase: Based on the currently public parameters params of the system, the data owner inputs the private key sk, parameter n, extended public key epk, and outputs the aggregate token. Challenge token σ, i.e.

[0013]

[0014] Step 3: Aggregation Phase: Based on the currently publicly available system parameters params, the cloud server inputs the currently stored tag {t} i},

[0015] Parameter n, aggregate token Output aggregate label {T j},Right now

[0016]

[0017] Step 4: Challenge Phase: Based on the currently public parameters params of the system, the third-party auditor inputs the data owner's extended public key epk, the challenge token σ, and outputs the challenge chal, i.e.

[0018] Challenge(params,epk,σ)→chal;

[0019] Step 5: Response Phase: Based on the currently publicly available system parameters params, the cloud server inputs the challenge chal, and stores the message {m} at the index position specified in the challenge. i} and the corresponding aggregation tag {T j The output is the response result res, i.e.

[0020] Respond(params, chal, {m i},{T j})→res;

[0021] Step 6: Verification Phase: Based on the publicly available parameters `params` in the current system, the third-party auditor inputs the challenge `chal`, the response result `res`, and the secret value `s` generated during the challenge generation process. The output is the verification result 1 / 0 (where 1 indicates successful verification and 0 indicates failed verification).

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

[0023] The key expansion phase, token generation phase, and aggregation phase of this method serve as supplements to the current system algorithm and are run by the corresponding objects; the challenge phase, response phase, and verification phase serve as upgrades to the system using this method, with the corresponding objects replacing the original algorithm and running it.

[0024] This method is applicable to data auditing systems based on linear homomorphic validators that have already been deployed and put into use. It allows for the aggregation and compression of data tags to save storage space while maintaining the existing system's operational status to the greatest extent possible. Therefore, this method needs to run on top of the existing data auditing system, specifically including the current system's public parameters `params`, the data owner's original public-private key pair (pk, sk), and a parameter `n` to define the number of tags that can be aggregated each time.

[0025] In steps (1)-(6), the current publicly available system parameters are used, and there is no need to rerun the initialization algorithm to generate the publicly available system parameters. Users can also freely choose whether to use this method, which will not affect the implementation of system functions, so as to minimize the modification of the original system by this method.

[0026] In the key expansion stage of step (1), the data owner generates an expanded public key epk from the current public key pk, which can be effectively verified by the original public key pk. Therefore, users do not need to reapply for a public key certificate to prove the validity of the expanded public key epk. This does not incur additional overhead for users whose current public key certificates have not expired or who plan to continue using the original system.

[0027] In step (2), the token generation stage only needs to be run once by the data owner to generate the required tokens and send them to the cloud server and the third-party auditor. The data owner does not need to participate in the calculations during subsequent auditing processes.

[0028] In the challenge and response phases of steps (4)-(5), the communication overhead between the two parties is also a constant, regardless of the number of indexes selected for the challenge.

[0029] Compared with existing technologies, the advantages of this invention are as follows: 1. The public parameters of the system are consistent with the original system, and no new initialization algorithm is needed to generate public parameters, minimizing the modification to the original system; 2. The user's extended public key can be effectively verified through the original public key. Users who have already applied for public key certificates can continue to use the original certificate and public key to verify the validity of the extended public key, further saving system overhead and user costs; 3. During the token generation stage, the user only needs to authorize once. The server and third-party auditors can use the authorized token to perform tag aggregation and challenge generation operations respectively. The communication overhead is constant and independent of the data size stored in the system and the number of indexes selected for the challenge; 4. This method has good scalability to the original system. Users can also choose whether to upgrade to adopt this method. Users who choose to adopt this method only need to run the above steps to replace the corresponding steps in the original system; users who choose to continue using the original system do not need to perform any operations. The system can provide services to both types of users simultaneously; 5. This method is a general technology that can not only realize tag aggregation and recovery of existing systems under traditional public key systems, but also be directly used for construction based on identity systems and certificateless systems. Attached Figure Description

[0030] Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0031] To enhance understanding of the present invention, the technical solution will be further described below in conjunction with the accompanying drawings and embodiments.

[0032] The above and other objects, features and advantages of the present invention will become more apparent from the accompanying drawings, which describe exemplary embodiments of the invention in more detail. In the exemplary embodiments of the invention, the same reference numerals generally represent the same parts.

[0033] Example 1:

[0034] See Figure 1 A method for aggregation and recovery of data audit tags based on linear homomorphic validators, based on the current system public parameters params, the original public-private key pair (pk, sk) of the data owner, and a parameter n, consists of the following steps:

[0035] Assume that params are the public parameters of the current system, specifically including the p-order bilinear groups G1, G2, G... T The bilinear mapping is e: G1×G2→G T The generator g of group G1 and the generator h of group G2, and the hash function H1:{0,1} * →G1. For a given data owner, the current public / private key pair is pk = h. a∈G2,sk=a∈Z p Z p This is a cyclic group modulo p. The system selects a parameter n, defines a function that can aggregate n original tags into a single aggregate tag, and then selects a hash function H2:{0,1}. * →Z p .

[0036] Step 1: Key Expansion Phase: Based on the public parameters params of the current system, the data owner's current public key pk = h a Private key sk = a, parameter n, data owner calculates extended public key.

[0037]

[0038] Step 2: Token Generation Phase: Based on the current system's public parameters params, private key sk = a, parameter n, and the data owner's extended public key epk, the data owner selects n-1 random numbers r2, r3, ..., r n ∈Z p And calculate

[0039]

[0040] Among them, aggregate token There are (n-1) in total; subsequently, the data owner calculates based on the extended public key epk.

[0041]

[0042]

[0043] …,

[0044]

[0045] Where the challenge token σ = {σ1,…,σ} n It consists of a total of n(n-1) group elements;

[0046] Step 3: Aggregation Phase: Based on the publicly available parameters params of the current system, data labels {t i}, parameter n, and the aggregation token provided by the data owner. The cloud server aggregates tags, combining the data tags {t} corresponding to a message. i} Divide into groups of n, where The cloud server first calculates integers j and l, satisfying i = j·n + l, l ∈ [2, n], and then calculates a new label for the i-th original data label.

[0047]

[0048] The cloud server then groups the calculated new tags into groups of n:

[0049] (t′ 0+1 ,t′ 0+2 ,…,t′ 0+n ),

[0050] (t′ n+1 ,t′ n+2 ,…,t′ n+n ),

[0051] …,

[0052] (t′ jn+1 ,t′ jn+2 ,…,t′ jn+n ),

[0053] …;

[0054] The cloud server aggregates and calculates the tags for each group and outputs the aggregated tag {T}. j},in

[0055] T j =t′ jn+1 ·t′ jn+2 ·…·t′ jn+n ;

[0056] Step 4: Challenge Phase: Based on the public parameters params of the current system, the data owner's extended public key epk, the challenge token σ, and a random number β∈Z selected by the third-party auditor. p Calculate based on the extended public key epk

[0057]

[0058] and Please note that tpk contains 2n-1 group elements, excluding... This item, as the secret value generated during the challenge phase, will be used in the subsequent verification phase; subsequently, the third-party auditor will calculate based on the challenge token σ.

[0059]

[0060]

[0061] …,

[0062]

[0063] And update the challenge token σ′={σ1′,σ2′,…,σ nFinally, the third-party auditor randomly selects an index set I from the location index of the data already uploaded by the data owner, and for each index i∈I in set I, selects a random number s. i ∈Z p The final challenge consists of tpk, an updated challenge token σ′, an index set I, and a random number s. i ,Right now

[0064] chal={tpk,σ′,(i,s i )|i∈I};

[0065] Step 5: Response Phase: Based on the publicly available parameters params of the current system, after receiving the challenge chal, the cloud server first locates the data {m} stored in the storage location corresponding to the index set specified in the challenge. i} and the corresponding aggregation tag {T j Here, the index i and the index j of the aggregation label satisfy i = j·n + l, l ∈ [2, n]; subsequently, for each index i, according to the data m i The corresponding aggregation tag T j Elements in tpk and the updated challenge tokens σ′={σ′1,σ′2,…,σ′ n The evolutionary label is calculated, taking i∈[1,n] as an example, i.e., i=0·n+l, and the corresponding aggregation label is T1. The specific process is as follows:

[0066]

[0067] Finally, the cloud server uses the evolution tag e corresponding to each index. i and random number s i ,calculate:

[0068]

[0069] The cloud server outputs the response result res = (H2(E), μ);

[0070] Step 6: Verification Phase: Based on the publicly available parameters `params` of the current system, a challenge `chal` is performed. After receiving the response `res`, the third-party auditor uses the secret value `s` generated in the challenge phase for verification. The specific calculations are as follows:

[0071]

[0072] And determine the equation Check if the equation is true. If the equation is true, output 1 to indicate that the verification passed; otherwise, output 0 to indicate that the verification failed.

[0073] This technical solution, based on the current publicly available system parameters, enables seamless upgrades for users of the current system. In step 1, the user calculates an extended public key using the current public key, and the validity of the extended public key can be verified using the current public key. Therefore, the user does not need to reapply for a public key certificate, providing a transitional method based on the current system. Step 2 allows the user to generate corresponding tokens to aggregate existing tags in the current system and audit stored data, thus optimizing the storage efficiency of the current system. Steps 4-6 are completed through interaction between a third-party auditor and the server, requiring only the data owner's extended public key. Both parties simply need to run the algorithm in this method to replace the algorithm in the original system, without the data owner's involvement.

[0074] 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. A method for aggregation and recovery of data audit tags based on linear homomorphic validators, characterized in that, The method includes the following steps: Step 1: Key Expansion Phase: Publicize parameters in the current system Based on this, the data owner enters the original public key. private key ,parameter Output extended public key ,Right now ； Step 2: Token Generation Phase: Publicly disclose parameters in the current system Based on this, the data owner enters their private key. ,parameter Extended public key Output aggregate token Challenge Token The aggregation token and challenge token are sent to the cloud server and the third-party auditor respectively. ； Step 3: Aggregation Phase: Publicize parameters in the current system Based on this, the cloud server inputs the currently stored tags. ,parameter Aggregation token Output and store aggregated tags At the same time, the original data tags are deleted to save storage space, where each aggregation tag... Depend on Original label Aggregated, that is ； Step 4: Challenge Phase: Publicize parameters in the current system Based on this, the third-party auditor inputs the data owner's extended public key. Challenge Token Output Challenge And send the challenge to the cloud server, that is ； Step 5: Response Phase: Publicize parameters in the current system Based on this, cloud server input challenge The message stored at the index location specified in the challenge. and the corresponding aggregation tags Output response results The response result will be returned to the third-party auditor, i.e. ； Step 6: Verification Phase: Publicly disclose parameters in the current system Based on this, third-party auditors input challenges Response results And the secret value generated during the challenge generation process. The output verification result is 1 / 0, where 1 indicates successful verification and 0 indicates failed verification. 。 2. The method for aggregation and recovery of data audit tags based on linear homomorphic validators according to claim 1, characterized in that, set up These are the publicly available parameters of the current system, specifically including Bilinear group of order The bilinear mapping is ,group generator Hequn generator Hash function For a given data owner, the current public / private key pair is: ,in For model The system selects a parameter from the cyclic group it forms. , defines The original tags are aggregated into one aggregate tag, and then a hash function is selected. , Step 1: Key Expansion Phase: Based on the public parameters of the current system The current public key of the data owner private key ,parameter The data owner calculates the extended public key. 。 3. The method for aggregation and recovery of data audit tags based on linear homomorphic validators according to claim 2, characterized in that, Step 2: Token Generation Phase: Based on the public parameters of the current system private key ,parameter and the data owner's extended public key Data owner selection random numbers And calculate ， Among them, aggregate token common One; subsequently, the data owner uses the extended public key. calculate , ， Challenge token ,common It consists of a group of elements.

4. The method for aggregation and recovery of data audit tags based on linear homomorphic validators according to claim 3, characterized in that, Step 3: Aggregation Phase: Based on the public parameters of the current system Data tags ,parameter and the aggregation token provided by the data owner The cloud server aggregates tags, combining the data tags corresponding to a message. According to each They are divided into groups of 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19 ... The cloud server first calculates the integer. and ,satisfy , for the Calculate new labels from original data labels. ； The cloud server will then calculate the new tags with Group them into sets of 1: , ； The cloud server aggregates and calculates the tags for each group and outputs the aggregated tags. ,in 。 5. The method for aggregation and recovery of data audit tags based on linear homomorphic validators according to claim 4, characterized in that, Step 4: Challenge Phase: Based on the publicly available parameters of the current system Extended public key of the data owner Challenge Token The third-party auditor selects a random number. ,according to calculate , and , CCP Individual group elements, not including This item, as a secret value generated during the challenge phase, will be used in the subsequent verification phase; Subsequently, the third-party auditor used the challenge token. calculate , ， And update the challenge token. Finally, the third-party auditor randomly selects a set of indexes from the location indexes where the data owner has already uploaded the data. and for the set Each index in Select a random number The final challenge includes Updated Challenge Tokens index set and random numbers ,Right now 。 6. The method for aggregation and recovery of data audit tags based on linear homomorphic validators according to claim 5, characterized in that, Step 5: Response Phase: Based on the publicly available parameters of the current system Cloud servers face challenges Next, first locate the data stored in the storage location corresponding to the index set specified in the challenge. and the corresponding aggregation tags The index here and the serial number of the aggregation tag satisfy ; Then, for each index According to the data The corresponding aggregation tag , elements in and updated challenge tokens Computational evolutionary tags, ,Right now The corresponding aggregation tag is The specific process is as follows: ； Finally, the cloud server uses the evolutionary tags corresponding to each index. and random numbers ,calculate: Cloud server output response results .

7. The method for aggregation and recovery of data audit tags based on linear homomorphic validators according to claim 6, characterized in that, Step 6: Verification Phase: Based on the publicly available parameters of the current system ,challenge The third-party auditor received Then, utilize the secret value generated during the challenge phase. Verification was conducted, among which The specific calculations are as follows: And determine the equation Check if the equation is true. If it is true, output the result. If the verification passes, output 0; otherwise, output 0. This indicates that the verification failed.

Images