An automated auditing method for secure data storage

Abstract

The present invention discloses an automated auditing method for secure data storage. First, when deploying the smart contract, the present invention defines a storage task structure and a task list for users to view and record. The client initiates a new task and pays a fee, and the server participates in the bidding. Then the client selects the target server. Next, the client transfers the file off-chain to the server and uploads the metadata at the same time. After receiving the file, the server calculates the new metadata and uploads it, and pays a deposit at the same time. If the two pieces of metadata are the same, the storage begins; otherwise, the task terminates. In the auditing stage, the server obtains a random index periodically and then performs the audit. If the audit is successful, the server obtains a part of the remuneration; otherwise, the task fails and the server loses the deposit. The present invention can be applied to various blockchain types, makes full use of the characteristics of the blockchain such as decentralization and verifiability, and can flexibly nest the existing PoR scheme, thus ensuring that the present invention has the characteristics of high security, fairness, and practicality.

Description

Technical Field

[0001] The present invention belongs to the technical fields of data storage and blockchain, and relates to an automated auditing method for secure data storage. Background Art

[0002] Proofs of Retrievability (PoR) is a cryptographic technique that provides both data storage proof and data recovery capabilities. In cloud storage, this technique helps clients check (also known as audit) the integrity and correctness of cloud data without downloading all the data, and supports timely repair of damaged data to ensure the availability of cloud data. However, most existing PoR schemes are implemented in the channel between two participants (i.e., the client and the server), and the opacity of the interaction can easily lead to trust issues and disputes of interest.

[0003] To solve this problem, scholars introduced an honest third-party auditor, but this mechanism that requires full trust faces potential risks such as collusion attacks and single points of failure. Although blockchain technology with characteristics such as decentralization and verifiability provides a new solution idea, existing blockchain-based data storage auditing protocols are limited to private blockchains / consortium blockchains or rely on specially constructed blockchains. In addition, traditional PoR schemes have not been improved and cannot be directly implemented in blockchains, making it difficult to be effectively applied and promoted.

[0004] The above content is only used to assist in understanding the technical solution of the present invention, and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] In view of the above problems, the present patent designs an automated auditing method for secure data storage based on blockchain technology. By deploying and invoking smart contracts, it can not only nest existing PoR schemes, but also does not require the participation of a third-party auditor (i.e., the audit is only executed by the server invoking the smart contract algorithm), effectively improving fairness and practicality. The present invention solves the current situation of prominent trust problems in existing PoR schemes and special construction of data storage auditing protocols, nests the PoR scheme into the blockchain while realizing automatic auditing and fair transactions, meeting the development needs of security, efficiency, and convenient application.

[0006] For the purpose of the present invention, the present invention proposes an automated auditing method for secure data storage, and its process is as follows:

[0007] 1) Deploy a smart contract on the blockchain and initialize a structure Task and a task list Tasks; among them, the task list Tasks is used to record the information in the structure Task; the data structure of the structure Task includes the unique identifier ID of the task, the client address client, the server address list server, the task fee F, the storage time T, the audit times N, the metadata M for auditing, the index list I, and the storage start time t;

[0008] 2) The client uploads the relevant information of its data file to be stored file to the blockchain by calling the smart contract and pays the fee V F , and the blockchain generates a storage task A according to the relevant information and the structure Task and stores it in the task list Tasks; each server sends a cooperation request to the client that initiates the storage task A; the blockchain first determines whether there is a cooperation server for the storage task A, if not, it saves the addresses of the corresponding servers to the record corresponding to the storage task A in the task list Tasks; the client selects a target server ds as the cooperation server;

[0009] 3) The client uploads the metadata M of the data file c to the blockchain, and sends the ciphertext Enc(file) of the data file to the target server ds through a secure channel; the target server ds restores the data file according to the received ciphertext Enc(file), and uploads the metadata M of the data file s to the blockchain, and pays the deposit V D ; the blockchain detects whether M c is consistent with M s , if consistent, it saves the metadata of the data file and the current time to the record corresponding to the storage task A in the task list Tasks as the metadata M for auditing and the storage start time t, and at this time the target server ds starts to store the data file;

[0010] 4) The target server ds sends an audit request for the ciphertext Enc(file) to the blockchain, the blockchain generates a file block index i of the ciphertext Enc(file) according to the audit request and returns it to the target server ds, and then the target server ds calculates a metadata M according to the file block B corresponding to the index i and the storage proof Π new and sends it to the blockchain, and the blockchain detects whether M new is consistent with M. If consistent, the target server ds obtains a part of the remuneration provided by the client; otherwise, the client receives compensation.

[0011] Further, the method for generating the storage task A is as follows: The client inputs the task fee F, the storage time T, and the number of audits N, and pays the fee V. F ; The blockchain uses the hash algorithm on the current block number, timestamp, miner address, and gas limit of the transaction fee to randomly generate a unique identifier ID for the storage task A, adds A to the task list Tasks, and records the information corresponding to A (client, F, T, N, ID); sends the unique identifier ID of the storage task A to the client.

[0012] Further, the server checks Tasks, selects the storage task A and inputs the corresponding ID; the blockchain queries in Tasks according to the input ID whether the storage task A has reached a cooperation intention.

[0013] Further, if the time interval t′ between two adjacent audit requests satisfies T / N ≤ t′ < 2T / N, a valid file block index i is generated.

[0014] Further, if M new is consistent with M, the target server ds obtains a partial remuneration V provided by the client F / N; otherwise, the client receives a compensation V R +V D ; where V R is the remaining part of V F .

[0015] Further, if the audit is completed within the specified time T, the remuneration received by the target server ds is V F -V R +V D , and the client receives V R ; where V F -V R is all the remuneration obtained by the correct audit of the target server ds so far.

[0016] The specific steps of the present invention are as follows:

[0017] Step 1. Initialization (Setup) step: When the data storage system deploys a smart contract on the blockchain, the initialization (Setup) step is automatically triggered. Define the structure Task (including the unique identifier ID of the task, the client address client, the server address list server, the task fee F, the storage time T, the number of audits N, the metadata M for auditing, the index list I, and the storage start time t), and the task list Tasks. Among them, the initial state of Tasks is an empty list, which is used to record Task in subsequent steps. For the specific parameter symbol definitions, refer to (1. Symbols and definitions) in the specific implementation manner.

[0018] Step 2. Storage Task Generation (Task Creation) Step: In this step and subsequent steps, the operations of the client and the server are almost all implemented by calling the smart contract algorithms deployed on the blockchain, and the relevant information is uploaded to the blockchain. Specifically, the client uploads the information related to the storage task, the server freely sends a cooperation request (bid) to the target task, and the client selects the target server to reach a cooperation intention.

[0019] · Algorithm 1. Client Initiates Storage Task Module (UploadTask): This algorithm is called by client U. According to its own storage requirements, it inputs the task fee F, storage time T, and audit times N, and pays the fee V F . This algorithm uses the hash algorithm to randomly generate a unique identifier ID for the new task A with the current block number, timestamp, miner address, and transaction fee (i.e., gas) limit, adds A to the task list Tasks, and records the information corresponding to A (client, F, T, N, ID), where client is the address of U (i.e., the parameter msg.sender that calls this algorithm). The algorithm outputs ID as the return value received by client U.

[0020] · Algorithm 2. Server Bidding Module (SubmitServer): This algorithm is called by the server. The server can view Tasks, freely select the target task and input its corresponding ID. Here, it is assumed that both server j and server k hope to complete task A, and they each call Algorithm 2. This algorithm queries A in Tasks according to the ID and judges whether a cooperation intention has been reached. If the length of server corresponding to task A is greater than 1, and there is only one valid server address in server while other positions are empty (i.e., client U has executed Algorithm 3), it means that the task has reached a cooperation intention, and an error is output; otherwise, the address of this server (i.e., msg.sender) is recorded in Tasks.

[0021] · Algorithm 3. Client Selects Server Module (ChangeServer): This algorithm is called by client U, inputs the ID corresponding to task A, and a certain target server ds (assumed to be server j here) selected by the client from multiple bidding servers. This algorithm searches for A in Tasks and checks whether the client address client recorded therein is the address of the current client U that calls this algorithm (i.e., msg.sender), thereby judging whether A is initiated by client U. If so, it clears all server addresses that bid for this task except ds and visually displays the target server specified by U; otherwise, an error is output. At this point, no server can call the SubmitServer module to initiate a bid anymore.

[0022] Step 3. Metadata Issuance Step: This step is used to confirm whether the metadata from the client and the server is consistent. Both Algorithm 4 and Algorithm 5 need to determine the correspondence between the caller and the task pointed to by the input ID, that is, the client can only process the tasks it initiates, and the server can only process the tasks it provides services for.

[0023] · Algorithm 4. Client Upload Metadata Module (UploadMeta): This algorithm is called by the client, and the input is the task ID and the metadata M calculated by the client based on the outsourced file file c (usually including information such as a hash tree built on the outsourced file blocks); at the same time, the client sends the ciphertext Enc(file) of the outsourced file to the target server ds through an off-chain secure channel, where Enc represents the encryption algorithm.

[0024] · Algorithm 5. Verify Metadata Module (VerifyMeta): This algorithm is called by the target server ds, and the input is the task ID and the metadata M calculated by ds based on the received file (that is, file obtained by decrypting the ciphertext Dec(Enc(file))), s and at the same time pay the deposit V D If M c = M s , in the task list Tasks on the blockchain, record it as metadata M and record this moment as t, and the target server ds starts to store file; otherwise, return the fee V F to the client, and return the deposit V D to the target server ds.

[0025] Step 4. Audit Execution Step: In this step, the target server ds audits according to the randomly indexed packed storage proof to obtain the remuneration, and repeats this step until the specified time T. Both Algorithm 6 and Algorithm 7 still need to judge the correspondence between the caller and the task pointed to by the algorithm input ID.

[0026] · Algorithm 6. Generate Index Module (IndexGen): This algorithm is called by the target server ds, and the input is the task ID. This algorithm performs the following operations: The time interval t' between two adjacent calls only outputs a valid random index i pointing to the outsourced file block when T / N ≤ t' < 2T / N; otherwise, it is regarded as ds missing the audit. The algorithm first automatically records the invalid index false in Tasks, and then returns the valid index i to ds. The time interval t' is set here to ensure that the target server ds performs audits evenly and avoid it performing audits continuously to obtain the remuneration V in the shortest time F (that is, not meeting the client's storage time requirement T).

[0027] · Algorithm 7. Audit Module (Audit): This algorithm is called by the target server ds, and the input is the task ID, the valid index i generated by the IndexGen module, the file block B pointed to by i, and the storage proof Π. This algorithm calculates the new metadata M new and compares it with M in Tasks. If M new = M, it means that ds correctly stores the file and obtains a partial reward V F / N, and the algorithm outputs 1; otherwise, the client receives the compensation V R +V D (that is, the remaining part V F of V R plus the deposit V D ), and the algorithm outputs 0. After the audit is completed at the specified time T, the target server ds obtains V F -V R +V D (where V F -V R is all the rewards obtained by the target server ds for correctly performing the audit so far), and the client receives V R (if ds misses part of the audit, then V R ≠ 0), and task A ends.

[0028] The advantages of the present invention are as follows:

[0029] In most current PoR schemes, the interaction channels between the client and the server are opaque, lacking an effective supervision mechanism or relying heavily on a completely trusted third party, which is extremely likely to lead to trust issues and interest disputes. Although blockchain technology is expected to solve these problems, the existing blockchain-based data storage audit protocol has a special structure and fails to directly embed the PoR scheme, making it difficult to meet the development needs of fair transactions and application convenience.

[0030] The automated audit method for secure data storage designed based on blockchain technology in the present invention is a general architecture that can embed existing PoR schemes, and only needs to change the algorithm input (PoR schemes often use hash proofs during audits). In particular, the present invention does not require an audit server or any other third party to assist in the audit, and only requires the server to call the smart contract algorithm to complete the audit (that is, the smart contract acts as the audit server). In addition, the present invention can be applied to various blockchain types such as public blockchains, private blockchains, and consortium blockchains, solving the trust problem of PoR schemes and the cumbersome structure of data storage audit protocols from the source, and better meeting the actual needs of fairness and practicality. Description of the Drawings

[0031] Figure 1 It is a flowchart of the implementation of the storage task generation and metadata confirmation steps.

[0032] Figure 2 It is a flowchart for the implementation steps of the audit. Detailed implementation manners

[0033] The present invention will be further described in detail below with reference to the accompanying drawings. The examples given are only used to explain the present invention and are not intended to limit the scope of the present invention.

[0034] 1. Symbols and definitions

[0035] Task: The data structure for storing tasks.

[0036] Tasks: A list of storage tasks composed of multiple Tasks.

[0037] ID: The unique identifier of the storage task.

[0038] client: The address of the client.

[0039] server: A list containing the address of the bidding server.

[0040] F: The cost of the storage task.

[0041] T: The storage time of the file.

[0042] N: The number of audits to be completed during storage.

[0043] M: Metadata for auditing.

[0044] M c : Metadata obtained by the client initializing the file.

[0045] M s : Metadata obtained by the server initializing the received file.

[0046] M new : Metadata calculated based on the input content of the server calling Audit during the audit.

[0047] ds: The target server selected by the client.

[0048] i: A valid index for auditing, pointing to a certain block of the file.

[0049] false: An invalid index used to mark missed audits.

[0050] I: A list containing valid or invalid indexes corresponding to each audit.

[0051] t: The moment when the storage task starts.

[0052] V F : The cost paid by the client when initiating the storage task, VF = F.

[0053] V D : The deposit paid by the server, V D ≥ V F .

[0054] V R : During storage, V F The remaining part of, 0 ≤ V R ≤ V F .

[0055] Enc: The encryption algorithm for off-chain file transmission.

[0056] Dec: The decryption algorithm for obtaining the client file.

[0057] file: The file entrusted by the client to the server for storage.

[0058] 2. Automated Audit Method for Secure Data Storage

[0059] The present invention mainly includes four parts: initialization (Setup), storage task generation (Task Creation), metadata confirmation (Metadata Issuance), and audit execution (Audit Execution). Among them, it includes seven smart contract algorithms on the blockchain: the client initiates a storage task (UploadTask), the server bids (SubmitServer), the client selects a server (ChangeServer), the client uploads metadata (UploadMeta), verifies the metadata (VerifyMeta), generates an index (IndexGen), and audits (Audit). The process of the present invention is as Figure 1 , Figure 2 shown, including the client, the server, and the smart contract. Among them, transfer is the transfer algorithm; specifically as follows:

[0060] Step 1. Initialization (Setup): This step is automatically triggered when the data storage system deploys a smart contract on the blockchain, defining the structure Task (including the unique identifier ID of the task, the client address client, the list of server addresses server, the task fee F, the storage time T, the number of audits N, the metadata M for auditing, the index list I, and the storage start time t), and the task list Tasks. Among them, the initial state of Tasks is an empty list and is used to record Task in subsequent steps. The specific parameter symbol definitions are shown in (1. Symbols and Definitions) in the specific implementation manner.

[0061] Step 2. Storage Task Creation: In this step and subsequent steps, the operations of the client and the server are almost all implemented by calling the smart contract algorithms deployed on the blockchain, and the relevant information is uploaded to the blockchain. Specifically, the client uploads the information related to the storage task, the server freely sends a cooperation request (bid) to the target task, and the client selects the target server to reach a cooperation intention.

[0062] · Algorithm 1. Client Initiates Storage Task Module (UploadTask): This algorithm is called by client U. According to its own storage requirements, it inputs the task fee F, storage time T, and audit times N, and pays the fee V F . This algorithm uses the hash algorithm to randomly generate a unique identifier ID of the new task A with the current block number, timestamp, miner address, and gas limit (i.e., gas). Add A to the task list Tasks and record the information corresponding to A (client, F, T, N, ID), where client is the address of U (i.e., the parameter msg.sender that calls this algorithm). The algorithm outputs ID as the return value received by client U.

[0063] · Algorithm 2. Server Bidding Module (SubmitServer): This algorithm is called by the server. The server can view Tasks, freely select the target task and input its corresponding ID. Here, it is assumed that both server j and server k hope to complete task A, and they each call Algorithm 2. This algorithm queries A in Tasks according to the ID and judges whether a cooperation intention has been reached. If the length of server corresponding to task A is greater than 1, and there is only one valid server address in server while other positions are empty (i.e., client U has executed Algorithm 3), it means that the task has reached a cooperation intention and an error is output; otherwise, record the address of this server (i.e., msg.sender) to Tasks.

[0064] · Algorithm 3. Client Selects Server Module (ChangeServer): This algorithm is called by client U. Input the ID corresponding to task A and a certain target server ds (assumed to be server j here) selected by the client from multiple bidding servers. This algorithm searches for A in Tasks and checks whether the client address client recorded therein is the address of the current client U that calls this algorithm (i.e., msg.sender), thereby judging whether A is initiated by client U. If so, clear all server addresses that bid for this task except ds, and visually display the target server specified by U; otherwise, output an error. At this point, no server can call the SubmitServer module to initiate a bid anymore.

[0065] Step 3. Metadata Issuance: This step is used to confirm whether the metadata from the client and the server are consistent. Both Algorithm 4 and Algorithm 5 need to determine the correspondence between the caller and the task pointed to by the input ID, that is, the client can only process the tasks it initiates, and the server can only process the tasks for which it provides services.

[0066] · Algorithm 4. Client Upload Metadata Module (UploadMeta): This algorithm is called by the client, and the input is the task ID and the metadata M calculated by the client based on the outsourced file file c (usually including information such as a hash tree built on the outsourced file blocks); at the same time, the client sends the ciphertext Enc(file) of the outsourced file to the target server ds through an off-chain secure channel, where Enc represents the encryption algorithm. There are multiple servers in the cloud. When the client wants to store the data file in the cloud, the client only selects one of the servers as the target server.

[0067] · Algorithm 5. Verify Metadata Module (VerifyMeta): This algorithm is called by the target server ds, and the input is the task ID and the metadata M calculated by ds based on the received file (that is, file obtained by decrypting the ciphertext Dec(Enc(file))) s , and at the same time pay the deposit V D . If M c = M s , in the task list Tasks on the blockchain, record it as metadata M and record this moment as t, and the target server ds starts to store file; otherwise, return the fee V F to the client, and return the deposit V D to the target server ds.

[0068] Step 4. Audit Execution: In this step, the target server ds audits according to the randomly indexed packaged storage proof to obtain the remuneration, and repeats this step until the specified time T. Both Algorithm 6 and Algorithm 7 still need to determine the correspondence between the caller and the task pointed to by the algorithm input ID.

[0069] · Algorithm 6. Generate Index Module (IndexGen): This algorithm is called by the target server ds, and the input is the task ID. This algorithm performs the following operations: The time interval t' between two adjacent calls only outputs a valid random index i pointing to the outsourced file block when T / N ≤ t' < 2T / N; otherwise, it is regarded as ds missing the audit. The algorithm first automatically records the invalid index false in Tasks, and then returns the valid index i to ds. The time interval t' is set here to ensure that the target server ds performs audits evenly and avoid it performing audits continuously to obtain the remuneration V in the shortest timeF (i.e., the requirement of the client storage time T is not met).

[0070] · Algorithm 7. Audit Module (Audit): This algorithm is called by the target server ds, and the input is the task ID, the valid index i generated by the IndexGen module, the file block B pointed to by i, and the storage proof Π. This algorithm calculates the new metadata M new and compares it with M in Tasks. If M new = M, it indicates that ds correctly stores the file and obtains a partial reward V F / N, and the algorithm outputs 1; otherwise, the client receives the compensation V R +V D (i.e., the remaining part V of V F plus the deposit V R ), and the algorithm outputs 0. After the audit is completed at the specified time T, the target server ds gets V D -V F +V R +V D (where V F -V R is all the rewards obtained by the target server ds for correctly performing the audit so far), and the client receives V R (if ds omits part of the audit, then V R ≠0), and task A ends.

[0071] Although specific embodiments of the present invention are disclosed for illustrative purposes, which are intended to help understand the content of the present invention and implement it accordingly, those skilled in the art can understand that: without departing from the spirit and scope of the present invention and the appended claims, various substitutions, changes, and modifications are possible. Therefore, the present invention should not be limited to the content disclosed in the best embodiments, and the scope of protection required by the present invention is defined by the scope of the claims.

Claims

1. An automated auditing method for secure data storage, the steps of which include: 1) Deploy a smart contract on the blockchain and initialize a structure Task and a task list Tasks; wherein, the task list Tasks is used to record the information in the structure Task; the data structure of the structure Task includes the unique identifier ID of the task, the client address client, the server address list server, the task fee F, the storage time T, the number of audits N, the metadata M for auditing, the index list I, and the storage start time t; 2) The client uploads the relevant information of the data file to be stored, file, to the blockchain by invoking the smart contract and pays the fee V F , and the blockchain generates a storage task A based on the relevant information and the structure Task and stores it in the task list Tasks; each server sends a cooperation request to the client that initiated the storage task A; the blockchain first determines whether there is already a cooperation server for the storage task A, and if not, saves the addresses of the corresponding servers to the record corresponding to the storage task A in the task list Tasks; the client selects a target server ds as the cooperation server; 3) The client uploads the metadata M of the data file c to the blockchain, and sends the ciphertext Enc(file) of the data file to the target server ds through a secure channel; the target server ds restores the data file according to the received ciphertext Enc(file), uploads the metadata M of the data file s to the blockchain, and pays a deposit V D ; the blockchain detects M c and M s to check if they are consistent. If they are consistent, the metadata of the data file and the current time are saved in the record corresponding to task A in the task list Tasks as the metadata M for auditing and the storage start time t. At this time, the target server ds starts to store the data file; 4) The target server ds sends an audit request for the ciphertext Enc(file) to the blockchain. The blockchain generates a file block index i of the ciphertext Enc(file) according to the audit request and returns it to the target server ds. Then, the target server ds calculates a unary data M based on the file block B corresponding to the index i and the storage proof Π new and sends it to the blockchain, and the blockchain detects M new to check if they are consistent. If they are consistent, the target server ds obtains a partial remuneration provided by the client; otherwise, the client receives compensation.

2. The method according to claim 1, wherein The method for generating the storage task A is as follows: The client inputs the task fee F, the storage time T, and the number of audits N, and pays the fee V F ; The blockchain uses the hash algorithm to generate a unique identifier ID for the storage task A based on the current block number, timestamp, miner address, and the gas limit of the transaction fee, adds A to the task list Tasks, and records the information corresponding to A (client, F, T, N, ID); sends the unique identifier ID of the storage task A to the client.

3. The method according to claim 2, wherein The server views Tasks, selects the storage task A and inputs the corresponding ID; the blockchain queries whether the storage task A has reached a cooperation intention in Tasks according to the input ID.

4. The method according to claim 1 or 2 or 3, characterized in that If the time interval t′ between two adjacent audit requests satisfies T / N ≤ t′ < 2T / N, an effective file block index i is generated.

5. The method according to claim 1 or 2 or 3, characterized in that, If M new is consistent with M, then the target server ds obtains the partial remuneration V provided by the client F / N; otherwise, the client receives the compensation V R +V D ; where V R is the remaining part of V F .

6. The method according to claim 5, characterized in that, If the audit is completed within the specified time T, the remuneration received by the target server ds is V F -V R +V D , the client receives V R ; where V F -V R is all the remuneration obtained from the correct audit of the target server ds so far.

Images