Self-auditing method quickly verifiable in distributed storage

Abstract

The application discloses a self-auditing method capable of being quickly verified in distributed storage, which comprises the following steps: initializing public parameters and signing an intelligent contract, generating a public key and a private key; dividing a file into blocks and zones and generating corresponding labels and audit auxiliary information, the labels being sent to a storage service provider; the storage service provider verifying the labels after receiving the labels; the intelligent contract generating an audit challenge and sending the audit challenge to the storage service provider, the storage service provider starting self-auditing, generating corresponding evidence and verifying the evidence; and a user updating data according to virtual coordinates.The application adopts a homomorphic hash technology to significantly improve the audit efficiency in multiple dimensions in view of the efficiency and safety problems of data auditing in distributed storage.In consideration of the time sensitivity of a file, the application also supports a fast dynamic operation, which greatly reduces the calculation overhead.In addition, in order to strengthen the integration with a blockchain, the self-auditing process is seamlessly integrated with a consensus algorithm.

Description

TECHNICAL FIELD

[0001] The present application relates to distributed storage and self-auditing and data updating technology, and particularly relates to a self-auditing method capable of being quickly verified in distributed storage. BACKGROUND

[0002] Distributed storage refers to a storage architecture in which data is stored in multiple physical locations (usually different servers, nodes or data centers). Each storage node holds a part of the data, and they are connected through a network to form a unified storage system. There are still some problems in the current distributed storage, such as the security problem of the existing system model after introducing a third-party auditor, low auditing efficiency, and not supporting block-level data updating.

[0003] The traditional distributed storage auditing model includes a user, a third-party auditor and a storage service provider. However, auditing through a third-party auditor may lead to the leakage of user privacy. Therefore, self-auditing removes the third-party auditor to improve the security of the entire auditing process. The user generates a (v, k+1, 1)-configuration through SBIBD technology, which enables the storage service provider to complete the audit without a third-party auditor. The specific construction process of SBIBD is as follows:

[0004] V = {0, 1,..., v-1} is a set containing v elements, and B = {B0, B1,..., B b-1} is a set containing b elements, where B i is a subset of V and has a length of k. If T = {V, B} satisfies the following conditions, it is called a (b, v, r, k, l)-configuration. In V, the element a appears exactly in r elements of B. In V, the element pair (a, b) appears exactly in l elements of B. k < v, which means that none of the elements in B contains all the elements of V.

[0005] For a (b, v, r, k, l)-configuration, if k = r and b = v are satisfied, it is called a symmetric balanced incomplete block design, also known as (v, k+1, l)-configuration. The premise of this configuration is bk = vr and r(k-1) = l(v-1).

[0006] In traditional data updating, a large number of labels need to be recalculated every time, which wastes a lot of computing resources. Virtual coordinates can greatly reduce the computing overhead by decoupling labels and indexes.

[0007] In summary, existing self-auditing schemes face several challenges, as the inherent complexity of self-auditing usually requires additional computational and communication operations, resulting in increased overhead. Some schemes utilize techniques such as hash functions and two-phase commit to speed up verification, while others support batch auditing through polynomial commitments and document identifiers; in addition, label aggregation using RSA key encryption technology and prime hash functions is combined with a single-layer authentication mechanism for fast dynamic operations.

[0008] However, current self-auditing schemes are optimized for specific audit stages. Strengthening each stage individually does not bring significant efficiency improvements. On the contrary, optimizing multiple stages simultaneously is expected to significantly improve audit efficiency. However, not adopting a holistic optimization approach may increase computational and communication overheads. Summary of the Invention

[0009] Purpose of the invention: The purpose of the present invention is to address the deficiencies in the prior art and to provide a self-auditing method that can be quickly verified in distributed storage.

[0010] Technical solution: A self-auditing method for distributed storage that can be quickly verified includes the following steps:

[0011] Step (1): Initialize relevant public parameters based on the input security parameter λ. At the same time, the user signs a relevant smart contract with the storage service provider to generate a (v,k+1,1)-configuration table.

[0012] Among them, the user generates two multiplication cyclic groups (G1, G T ), select g from G1 as the generator, and generate the bilinear map e:G1×G1→G T ; and generating a homomorphic hash function H having homomorphic properties;

[0013] Step (2): The user first generates a private key α← R Z P and x← R Z p , and then use the private key α to generate the public key y = g α , use the private key x to generate a homomorphic tag, and then broadcast the obtained public and private keys to all storage service providers;

[0014] Step (3): The user divides the file into n file blocks, each file block m i Each is divided into multiple sectors m i,j , and generate the corresponding homomorphic label σ i,j and audit auxiliary information, and send the file blocks and corresponding homomorphic tags to the corresponding storage service provider;

[0015] Step (4): The storage service provider verifies the received file blocks and homomorphic tags and stores them after verification.

[0016] Step (5): The smart contract generates challenge information Ω based on the number of file blocks and other information, and sends it to the storage service provider, and then starts self-audit;

[0017] Step (6): After receiving the challenge information, the storage service provider generates corresponding evidence and completes the aggregation and rapid verification of evidence with other storage service providers. The specific method is as follows:

[0018] Step (6.1), Storage Service Provider SSP i After receiving the challenge information Ω, generate the corresponding evidence σ i and μ i After each storage service provider generates the corresponding evidence, they conduct two rounds of interaction according to the (v,k+1,1)-configuration to generate the final evidence. The method is as follows:

[0019] If j∈E i , SSP j I will put some of my evidence (σ i ,μ i ) sent to SSP i , but because j∈E j , so SSP j No need to send proof to yourself. i After receiving k parts of evidence sent from other storage service providers, the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0020] If i∈E j , SSP j The intermediate evidence (P ji, Γ ji ) sent to SSP i , will be passed through the intermediate evidence (P ij ,Γ ij ) Calculate the final evidence (P, Γ);

[0021] Step (6.2): ​​The storage service provider obtains the complete evidence and verifies it;

[0022] Step (6.3): The storage service provider sends the verification results to the smart contract, and the smart contract uploads the results and challenge information to the blockchain to form an audit log;

[0023] Step (7): The user implements real-time data update based on the virtual coordinate structure.

[0024] Further, the detailed method of step (3) is as follows:

[0025] Step (3.1), the user divides the file m = ({m 1,1 ,...,m 1,s},...,{m n,1 ,...,m n,s}) into n blocks in order, and each file block is divided into s sectors;

[0026] Step (3.2), the user selects id← R Z P and w← R Z P to generate auxiliary information, while the user initializes the virtual coordinate set VI = ({VI 1,1 ,...,VI 1,s},...,{VI n,1 ,...,VI n,s}) where each element is randomly assigned a value and id will serve as the identifier of the file;

[0027] Step (3.3), for sector m i,j , the user generates the corresponding label σ i,j through formula (1);

[0028]

[0029] Step (3.4), for file block m i , the user generates label verification information which can help the storage service provider verify file block m i , i and j represent the index subscript of traversal;

[0030] Step (3.5), the user sends the file block and homomorphic label, label verification information, virtual coordinate set information to the corresponding storage service provider and smart contract; at the same time, the user deletes the local file copy and only retains the virtual coordinate set for file update.

[0031] Further, the specific process of step (4) is as follows:

[0032] Step (4.1), after receiving the file block and homomorphic label, label verification information, virtual coordinate set information, the storage service provider SSP i calculates as the auxiliary information of the verification label, CS represents the size of the file block set received by SSP i ;

[0033] Step (4.2), based on the information obtained in step (4.1), SSP i Verify the correctness of the received label using formula (2);

[0034]

[0035] Step (4.3), after verification, SSP i The file block and homomorphic label, label verification information and virtual coordinate set are stored. If the verification fails, SSP i The data will be reported to the user as correct.

[0036] Furthermore, the specific process of generating the challenge in step (5) is as follows:

[0037] Step (5.1), based on the input challenge parameter c, the smart contract randomly selects c numbers from [1,n] to form the challenge index set I = {idx1,...,idx c}, and select a parameter for each element in I to form a parameter set Q = {q j} j∈I ,q j ← R Z P ;

[0038] Step (5.2), based on the result (I, Q), the smart contract will calculate As audit support information;

[0039] In step (5.3), the smart contract sends a challenge message Ω = {B, I, Q} to each storage service provider.

[0040] Furthermore, the specific process of aggregating and verifying the evidence in step (6) is as follows:

[0041] Storage Service Provider (SSP) i After receiving the challenge information Ω = {B, I, Q}, the corresponding evidence is generated through formulas (3) and (4);

[0042]

[0043] In the above formula, m iI[j] , Q[j] are intermediate variables used to verify data integrity;

[0044] When SSP i After receiving k parts of evidence sent from other storage service providers, use formulas (5) and (6) to calculate the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0045]

[0046] The formula for calculating the final evidence (P, Γ) is as follows:

[0047]

[0048] When the storage service provider gets the complete evidence, calculate the intermediate variables Finally, the storage service provider will verify the evidence using formula (9);

[0049] e(P,g)=e(A*H(Γ)*H(w) B ,y)(9).

[0050] Furthermore, the specific process of data updating in step (7) is as follows:

[0051] Step (7.1), when the user needs to m ij Modified to hour;

[0052] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates The user will then Sent to the corresponding storage service provider, The data is sent to the smart contract, and the storage service provider will verify it after receiving it. If the verification is passed, a confirmation message will be sent to the smart contract. After the smart contract receives the confirmation message, the correct storage And send confirmation information to the user;

[0053] Step (7.2), when the user Insert into m ij and m ij+1 hour;

[0054] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates If inserted before the first sector Insert after the last sector The user will Sent to the corresponding storage service provider, The data is sent to the smart contract, and the storage service provider receives it for verification. If it is verified, a confirmation message will be sent to the smart contract. After the smart contract receives the confirmation message, the data is stored correctly. And send confirmation information to the user;

[0055] Step (7.3), the user wants to delete m ij hour;

[0056] The user will send the index information to the storage service provider and the smart contract; when the storage service provider deletes the corresponding file and label, it will send a confirmation message to the smart contract and the user; after receiving the confirmation message, the smart contract will delete the corresponding virtual index information and send a confirmation message to the DO; after the deletion is completed, all subsequent blocks and virtual indexes must be moved forward.

[0057] Advantages: Compared with the prior art, the present application has the following advantages

[0058] (1) To solve the problem of low efficiency of the current self-audit scheme, the present application uses homomorphic hash technology to realize batch auditing, allowing users to audit multiple files with minimal resource consumption; at the same time, label aggregation and fast verification are realized to improve audit efficiency and reduce computational overhead.

[0059] (2) To perform label recalculation in dynamic operations, the present application realizes fast dynamic operations by using a virtual index structure, allowing dynamic operations to be performed without recalculating a large number of labels, thereby significantly reducing computational overhead. In addition, the present application can be applied to blockchain storage and integrated with consensus algorithms to improve versatility.

[0060] (3) The present application first discloses a scheme for distributed storage self-audit, which has higher security and lower communication and computational cost compared with other schemes through security analysis and experimental evaluation. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 The system model diagram of the present application;

[0062] Figure 2 The flowchart of evidence aggregation in step (6) of the present application;

[0063] Figure 3 The efficiency diagram of label generation in an embodiment of the present application;

[0064] Figure 4 The efficiency diagram of label verification in an embodiment of the present application;

[0065] Figure 5 The efficiency diagram of evidence generation in an embodiment of the present application;

[0066] Figure 6 The efficiency diagram of evidence verification in an embodiment of the present application. DETAILED DESCRIPTION

[0067] The technical scheme of the present application will be described in detail below, but the protection scope of the present application is not limited to the described embodiments.

[0068] As Figure 1As shown, the present application mainly relates to three entities, namely a user, a smart contract and a storage service provider. At present, most distributed storage systems introduce a third-party auditor or audit organizer, which is responsible for sending audit requests, distributing files, aggregating evidence, etc. However, the third-party auditor may be curious about the user's information, thereby leading to privacy leakage.

[0069] To solve the defects of the prior art, the present application uses the SBIBD technology to realize self-auditing, but self-auditing requires two rounds of interaction, therefore, the present application also uses the homomorphic hash technology to realize batch auditing, which can audit multiple files at a time. At the same time, the present application also improves the verification speed, aggregates a large amount of repeated information together for verification, greatly improving the auditing efficiency; and even to support fast dynamic operation, the present application also designs an efficient virtual coordinate structure to manage label index changes and avoid label recalculation.

[0070] To facilitate understanding of the technical solutions, the content of the (v, k+1, 1)-configuration configuration to realize the self-auditing process is introduced first, wherein v=k ∧2 +k+1, k is a prime number.

[0071] First, according to the formula (10), (11) to construct B={B0, B1,..., B b-1}, wherein |B i |=k+1, B ij represents the jth element of B i .

[0072]

[0073] When B={B0, B1,..., B b-1} is obtained, E={E0, E1,..., E b-1} is constructed according to formula (12), and in self-auditing, the storage service provider needs to interact based on E.

[0074]

[0075] The present application provides a (7, 3, 1)-configuration according to the above algorithm, as shown in Table 1.

[0076] Table 1

[0077]

[0078]

[0079] The homomorphic hash function is a homomorphic hash function satisfying the following properties, which can greatly improve the efficiency of auditing. The homomorphic hash function has homomorphism and non-falsifiability.

[0080] The homomorphism means that for two messages (A, B) and parameters (α, β), it must satisfy: H(αA+βB)=H(A) α *H(B) β .

[0081] The unforgeability property is that there is no algorithm with polynomial time complexity that can forge (A, B, C, α, β) satisfying the following conditions: C! = αA + βB and H(C) = H(A) α *H(B) β .

[0082] To facilitate understanding of the technical solution of this embodiment, the meanings of the relevant variables are explained, and the specific contents are shown in Table 2.

[0083] Table 2

[0084]

[0085]

[0086] The self-auditing method for distributed storage that can be quickly verified in this embodiment includes the following steps:

[0087] Step (1): Initialize relevant public parameters based on the input security parameter λ. At the same time, the user signs a relevant smart contract with the storage service provider to generate a (v,k+1,1)-configuration.

[0088] In which, the user generates two multiplication cyclic groups (G1, G T ), select g from G1 as the generator, and generate the bilinear map e:G1×G1→G T ; and generating a homomorphic hash function H with homomorphic properties;

[0089] Step (2): The user first generates a private key α← R Z P and x← R Z p , and then use the private key α to generate the public key y = g α , use the private key x to generate a homomorphic tag, and then broadcast the obtained public and private keys to all storage service providers;

[0090] Step (3): The user divides the file into n file blocks, each file block m i Each is divided into multiple sectors m i,j , and generate the corresponding homomorphic label σ i,j and audit auxiliary information, and send the file blocks and corresponding homomorphic tags to the corresponding storage service provider;

[0091] Step (4): The storage service provider verifies the received file blocks and homomorphic tags and stores them after verification.

[0092] Step (5): The smart contract generates challenge information Ω based on the number of file blocks and other information, and sends it to the storage service provider, and then starts self-audit;

[0093] Step (6): After receiving the challenge information, the storage service provider generates corresponding evidence and completes the aggregation and rapid verification of evidence with other storage service providers. The specific method is as follows:

[0094] Step (6.1), Storage Service Provider SSP i After receiving the challenge information Ω, generate the corresponding evidence σ i and μ i After each storage service provider generates the corresponding evidence, they conduct two rounds of interaction according to the (v,k+1,1)-configuration to generate the final evidence. The method is as follows:

[0095] If j∈E i , SSP j I will put some of my evidence (σ i ,μ i ) sent to SSP i , when SSP i After receiving k parts of evidence sent from other storage service providers, the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence;

[0096] If i∈E j , SSP j The intermediate evidence (P ji, Γ ji ) sent to SSP i , will be passed through the intermediate evidence (P ij ,Γ ij ) Calculate the final evidence (P, Γ);

[0097] Step (6.2): ​​The storage service provider obtains the complete evidence and verifies it;

[0098] Step (6.3): The storage service provider sends the verification results to the smart contract, and the smart contract uploads the results and challenge information to the blockchain to form an audit log;

[0099] Step (7): The user implements real-time data update based on the virtual coordinate structure.

[0100] Furthermore, the detailed method of step (3) is:

[0101] Step (3.1), the user will file m=({m 1,1 ,...,m 1,s},...,{m n,1 ,...,m n,s}) is divided into n blocks in sequence, and each file block is divided into s sectors;

[0102] Step (3.2), user selects id← R Z P and w← R Z P To generate auxiliary information, the user initializes the virtual coordinate set VI = ({VI 1,1 ,...,VI 1,s},...,{VI n,1 ,...,VI n,s}), where each element is randomly assigned a value and id will be used as the identifier of the file;

[0103] Step (3.3), for sector m i,j , the user generates the corresponding label σ through formula (1) i,j ;

[0104]

[0105] Step (3.4), for file block m i , the user will generate label verification information Can help storage service providers verify file block m i , i and j represent the index subscripts of traversal;

[0106] In step (3.5), the user sends the file block, homomorphic label, label verification information, and virtual coordinate set information to the corresponding storage service provider and smart contract; at the same time, the user deletes the local file copy and only retains the virtual coordinate set for file update.

[0107] Furthermore, the specific process of step (4) is as follows:

[0108] Step (4.1), Storage Service Provider SSP i After receiving the file block and homomorphic label, label verification information, and virtual coordinate set information, calculate As auxiliary information for verifying the label, CS stands for SSP i The size of the received file chunk set;

[0109] Step (4.2), based on the information obtained in step (4.1), SSP iThe correctness of the received label is verified by formula (2);

[0110]

[0111] After the verification in step (4.3), the SSP i The file block and the homomorphic label, the label verification information and the virtual coordinate set are stored, and if the verification fails, the SSP i The user will be reported that the data is correct.

[0112] Further, the specific process of the step (5) of generating the challenge is as follows:

[0113] Step (5.1), according to the input challenge parameter c, the smart contract randomly selects c numbers from [1, n] to form a challenge index set I = {idx1,..., idx c}, and selects a parameter for each element in I to form a parameter set Q = {q j} j∈I , q j ← R Z P ;

[0114] Step (5.2), according to the obtained (I, Q), the smart contract will calculate as the audit auxiliary information;

[0115] Step (5.3), the smart contract sends the challenge information Ω = {B, I, Q} to each storage service provider.

[0116] Further, the specific process of the step (6) of aggregating and verifying the evidence is as follows:

[0117] After receiving the challenge information Ω = {B, I, Q}, the storage service provider SSP i generates the corresponding evidence by formula (3), (4);

[0118]

[0119] In the above formula, m iI[j] , Q[j] are intermediate variables for verifying data integrity;

[0120] When the SSP i receives the k partial evidence sent from other storage service providers, it uses formula (5), (6) to calculate the intermediate evidence (P ij , Γ ij ) for completing the final aggregation of the evidence;

[0121]

[0122]

[0123] The formula for calculating the final evidence (P, Γ) is as follows:

[0124]

[0125] When the storage service provider gets the complete evidence, calculate the intermediate variables Finally, the storage service provider will verify the evidence using formula (9);

[0126] e(P,g)=e(A*H(Γ)*H(w) B ,y)(9).

[0127] Furthermore, the specific process of data updating in step (7) is as follows:

[0128] Step (7.1), when the user needs to m ij Modified to hour;

[0129] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates The user will then Sent to the corresponding storage service provider, The data is sent to the smart contract, and the storage service provider will verify it after receiving it. If the verification is passed, a confirmation message will be sent to the smart contract. After the smart contract receives the confirmation message, the correct storage And send confirmation information to the user;

[0130] Step (7.2), when the user Insert into m ij and m ij+1 hour;

[0131] First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates If inserted before the first sector Insert after the last sector The user will Sent to the corresponding storage service provider, The data is sent to the smart contract, and the storage service provider receives it for verification. If it is verified, a confirmation message will be sent to the smart contract. After the smart contract receives the confirmation message, the data is stored correctly. And send confirmation information to the user;

[0132] Step (7.3), the user wants to delete m ij hour;

[0133] The user will send the index information to the storage service provider and the smart contract; when the storage service provider deletes the corresponding file and label, it will send a confirmation message to the smart contract and the user; after the smart contract receives the confirmation message, it will delete the corresponding virtual index information and send a confirmation message to the DO; after the deletion is completed, all subsequent blocks and virtual indexes must be moved forward.

[0134] The embodiment runs on a virtual machine with a windows operating system and 16GB RAM, and the CPU of the host is Core i5-8400. In addition, the number of storage service providers is 7, the number of sectors is 32, and the size of each sector is 32 bytes. Table 3 is the time required for each operation.

[0135] Table 3

[0136] OP T(ms) [CAT mul ]]> 2.467 <![CDATA[T exp ]]> 11.56 <![CDATA[T pair ]]> 100.32 <![CDATA[H n ]]> 1.2 [CAT ap ]]> 1.5 <![CDATA[T mp ]]> 1.64 <![CDATA[T ep ]]> 2.56

[0137] Figure 3 For the efficiency comparison of the present application and other schemes in the label generation stage, Figure 3 It can be seen that the efficacy of EPM is the most obvious, and the efficiency of DASA is obviously lower, mainly due to the use of file encoding in data retrieval, but this approach will accelerate the expansion of label counting. The present application presents an intermediate efficiency, balancing between the extremes of EPM and DASA.

[0138] In the label verification stage, only EPM and the present application scheme are compared and analyzed, because DASA does not have a corresponding algorithm, and by using the inherent label aggregation characteristics in the present application, the efficiency of the present application exceeds that of the EPM manifold, showing more than ten times the advantage. In addition, with the increase of the number of labels, this advantage is expected to be exponentially magnified, and this trend is illustrated in Figure 4 .

[0139] In the evidence generation stage, EPM appears as an efficiency paradigm, surpassing the present application and DASA, as Figure 5 shown. However, it is worth noting that the computational overhead in EPM is mainly dependent on the number of copies and challenge blocks retained in each storage service provider, while DASA and the present application are mainly affected by the number of file blocks and challenge blocks contained in each storage service provider. When the number of copies and file blocks is equal, the speed of the present application and DASA is superior to EPM. DASA needs more computational burden in proof generation, making its efficiency the lowest.

[0140] In the verification stage, the present application becomes the epitome of efficiency, as Figure 6As shown in the figure, the present invention features fast verification speeds, requiring only a few milliseconds. This is attributed to the present invention's ability to aggregate large amounts of information during the verification phase, significantly improving verification efficiency. In stark contrast, EPM requires tens of milliseconds, while DASA, with its significantly heavier overhead, requires hundreds of milliseconds due to the lack of information aggregation.

Claims

1. A self-auditing method for distributed storage that can be quickly verified, characterized in that: The following steps are involved: Step (1): Initialize relevant public parameters based on the input security parameter λ. At the same time, the user signs a relevant smart contract with the storage service provider to generate a (v, k+1, 1)-configuration table. In which, the user generates two multiplication cyclic groups (G1, G T ), select g from G1 as the generator, and generate the bilinear map e:G1×G1→G T ; and generating a homomorphic hash function H with homomorphic properties; Step (2): The user first generates a private key α← R Z P and x← R Z p , and then use the private key α to generate the public key y = g α , use the private key x to generate a homomorphic tag, and then broadcast the obtained public and private keys to all storage service providers; Step (3): The user divides the file into n file blocks, each file block m i Each is divided into multiple sectors m i,j , and generate the corresponding homomorphic label σ i,j and audit auxiliary information, and send the file blocks and corresponding homomorphic tags to the corresponding storage service provider; Step (4): The storage service provider verifies the received file blocks and homomorphic tags and stores them after verification. Step (5): The smart contract generates a challenge message Ω based on the number of file blocks and sends it to the storage service provider, which then initiates a self-audit. Step (6): After receiving the challenge information, the storage service provider generates corresponding evidence and completes the aggregation and rapid verification of evidence with other storage service providers. The specific method is as follows: Step (6.1), Storage Service Provider SSP i After receiving the challenge information Ω, generate the corresponding evidence σ i and μ i After each storage service provider generates the corresponding evidence, they conduct two rounds of interaction according to the (v,k+1,1)-configuration to generate the final evidence. The method is as follows: If j∈E i , SSP j I will put some of my evidence (σ i ,μ i ) sent to SSP i , when SSP i After receiving k parts of evidence sent from other storage service providers, the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence; If i∈E j , SSP j The intermediate evidence (P ji, Γ ji ) sent to SSP i , will be passed through the intermediate evidence (P ij ,Γ ij ) Calculate the final evidence (P, Γ); Step (6.2): ​​The storage service provider obtains the complete evidence and verifies it; Step (6.3): The storage service provider sends the verification results to the smart contract, and the smart contract uploads the results and challenge information to the blockchain to form an audit log; Step (7): The user implements real-time data update based on the virtual coordinate structure.

2. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The detailed method of step (3) is: Step (3.1), the user sets the file m=({m 1,1 ,...,m 1,s },...,{m n,1 ,...,m n,s }) is divided into n blocks in sequence, and each file block is divided into s sectors; Step (3.2), user selects id← R Z P and w← R Z P To generate auxiliary information, the user initializes the virtual coordinate set VI = ({VI 1,1 ,...,VI 1,s },...,{VI n,1 ,...,VI n,s }), where each element is randomly assigned a value and id will be used as the identifier of the file; Step (3.3), for sector m i,j , the user generates the corresponding label σ through formula (1) i,j ; Step (3.4), for file block m i , user-generated tag verification information Help storage service providers verify file chunk m i , i and j represent the index subscripts of traversal; In step (3.5), the user sends the file block, homomorphic label, label verification information, and virtual coordinate set information to the corresponding storage service provider and smart contract; at the same time, the user deletes the local file copy and only retains the virtual coordinate set for file update.

3. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The specific process of step (4) is as follows: Step (4.1), Storage Service Provider SSP i After receiving the file block and homomorphic label, label verification information, and virtual coordinate set information, calculate Only used as auxiliary information for verifying labels, CS stands for SSP i The size of the received file chunk set; Step (4.2), based on the information obtained in step (4.1), SSP i Verify the correctness of the received label using formula (2); Step (4.3), after verification, SSP i The file block and homomorphic label, label verification information and virtual coordinate set are stored. If the verification fails, SSP i The data will be reported to the user as correct.

4. The self-auditing method for distributed storage with rapid verification according to claim 1, characterized in that: The specific process of generating the challenge in step (5) is as follows: Step (5.1), based on the input challenge parameter c, the smart contract randomly selects c numbers from [1,n] to form the challenge index set I = {idx1,...,idx c }, and select a parameter for each element in I to form a parameter set Q = {q j } j∈I ,q j ← R Z P ; Step (5.2), based on the result (I, Q), the smart contract will calculate As audit support information; In step (5.3), the smart contract sends a challenge message Ω = {B, I, Q} to each storage service provider.

5. The self-auditing method for distributed storage with rapid verification according to claim 1, characterized in that: The specific process of aggregating and verifying evidence in step (6) is as follows: Storage Service Provider (SSP) i After receiving the challenge information Ω = {B, I, Q}, the corresponding evidence is generated through formulas (3) and (4); In the above formula, m iI[j] , Q[j] are intermediate variables used to verify data integrity; When SSP i After receiving k parts of evidence sent from other storage service providers, use formulas (5) and (6) to calculate the intermediate evidence (P ij ,Γ ij ) is used to complete the final aggregation of evidence; The formula for calculating the final evidence (P, Γ) is as follows: When the storage service provider gets the complete evidence, calculate the intermediate variables Finally, the storage service provider will verify the evidence using formula (9); e(P,g)=e(A*H(Γ)*H(w) B ,y) (9)。 6. The self-auditing method for distributed storage that can be quickly verified according to claim 1 is characterized in that: The specific process of data updating in step (7) is as follows: Step (7.1), when the user needs to m ij Modified to hour; First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates The user will then Sent to the corresponding storage service provider, The data is sent to the smart contract, and the storage service provider will verify it after receiving it. If the verification is passed, a confirmation message will be sent to the smart contract. After the smart contract receives the confirmation message, the correct storage And send confirmation information to the user; Step (7.2), when the user Insert into m ij and m ij+1 hour; First the user calculates the new virtual coordinates Calculate new homomorphic labels using new virtual coordinates If inserted before the first sector Insert after the last sector The user will Sent to the corresponding storage service provider, The data is sent to the smart contract, and the storage service provider receives it for verification. If it is verified, a confirmation message will be sent to the smart contract. After the smart contract receives the confirmation message, the data is stored correctly. And send confirmation information to the user; Step (7.3), the user wants to delete m ij hour; Users will send index information to storage service providers and smart contracts; When the storage service provider deletes the corresponding file and tag, it will send a confirmation message to the smart contract and the user; after receiving the confirmation message, the smart contract will delete the corresponding virtual index information and send a confirmation message to DO; After the deletion is complete, all subsequent blocks and virtual indices must be moved forward.

Images