Data availability verification method, apparatus and device, and computer program product

Abstract

The invention discloses a data availability verification method and device, equipment and a computer program product, and relates to the technical field of blockchains, and the method comprises the steps: receiving user data sent by a client, carrying out the fragmentation encryption of the user data, obtaining first Merkel data of the user data, and sending the first Merkel data to the client; sending the first Merkel data to a spot check verification end; receiving an encrypted random number sent by the spot check verification end, obtaining a target verification parameter according to the encrypted random number and the first Merkel data, sending the target verification parameter to the spot check verification end, and performing parameter verification on the target verification parameter by the spot check verification end, and obtaining an access verification result of the user data. The access verification result is obtained by encrypting and verifying the user data, so that the problem that the cloud disk data cannot be always online and readable is solved, and the safety of user data storage is improved.

Description

Technical Field

[0001] The present application relates to the field of blockchain technology, and in particular to methods, devices, equipment and computer program products for verifying the availability of data. Background Art

[0002] The data is stored in the cloud disk through encryption algorithms, and the encrypted data is protected from unauthorized access and leakage. The data is encrypted when it is written to the cloud disk, and it is ensured that the data cannot be accessed or decrypted without authorization. Even if the cloud disk data is leaked, it cannot be decrypted. It is automatically decrypted when the authorized user reads the cloud disk data, thus ensuring the confidentiality and integrity of the cloud disk data.

[0003] At present, there is often a lack of a mechanism for regular data spot checks in cloud disk data storage systems. This means that the integrity and availability of user stored data cannot be fully guaranteed without regular inspection and verification, and the stored data cannot be guaranteed to be online at any time. Therefore, a method is needed to ensure that the user's stored data is always online and readable. At the same time, the cloud disk storing data may fail sometimes, and users do not know that the stored data is no longer accessible, so it is necessary to regularly check whether the data is effectively saved to ensure that it can be accessed online.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of the present application is to provide a data availability verification method, device, equipment and computer program product, aiming to solve the technical problem that cloud disk data cannot be always accessible online.

[0006] To achieve the above purpose, the present application proposes a method for verifying data availability, which is applied to a storage node and includes:

[0007] Receive user data sent by the client, encrypt the user data in segments, obtain first Merkel data of the user data, and send the first Merkel data to the spot check verification end;

[0008] Receive the encrypted random number sent by the random check verification end, obtain a target verification parameter according to the encrypted random number and the first Merkel data, send the target verification parameter to the random check verification end, and the random check verification end performs parameter verification on the target verification parameter to obtain an access verification result of the user data.

[0009] In one embodiment, the step of performing shard encryption on the user data to obtain the first Merkle data of the user data includes:

[0010] Filling and segmenting the user data to obtain fragmented data blocks of the user data;

[0011] Encrypting the sliced ​​data block by using a first encryption algorithm to obtain sliced ​​encrypted data of the user data;

[0012] The sharded encrypted data is re-encrypted by a second encryption algorithm to obtain first Merkle data of the sharded encrypted data.

[0013] In one embodiment, the step of obtaining a target verification parameter according to the encrypted random number and the first Merkel data includes:

[0014] Sign the encrypted random number using the private key of the storage node to obtain a signed random number of the encrypted random number;

[0015] Taking a modulus of the signature random number to determine an upload data block in the sliced ​​encrypted data;

[0016] Calculate the signature random number using a second encryption algorithm to obtain second Merkle data of the signature random number;

[0017] Building a Merkle proof tree based on the first Merkle data and the second Merkle data, and calculating a Merkle proof tree root of the Merkle proof tree and a Merkle proof path of the second Merkle data;

[0018] Based on the signature random number, the uploaded data block, the Merkle proof tree root, the Merkle proof path and the public key of the storage node, the target verification parameter of the sliced ​​encrypted data is obtained.

[0019] In one embodiment, the method is applied to a client, and the method includes:

[0020] Get user data of the user;

[0021] The user data is sent to a storage node, and the storage node performs shard encryption on the user data to obtain first Merkel data of the user data, and the first Merkel data is sent to a random check verification end. The storage node receives the encrypted random number sent by the random check verification end, obtains a target verification parameter according to the encrypted random number and the first Merkel data, and sends the target verification parameter to the random check verification end. The random check verification end performs parameter verification on the target verification parameter to obtain an access verification result of the user data.

[0022] In one embodiment, the method is applied to a random inspection verification terminal, and the method includes:

[0023] Receive first Merkel data sent by the storage node, where the first Merkel data is obtained by obtaining user data of a user from a client, sending the user data to the storage node, and the storage node sharding and encrypting the user data;

[0024] Periodically sending an encrypted random number to a storage node, the storage node obtaining a target verification parameter according to the encrypted random number and the first Merkel data, and sending the target verification parameter to a spot check verification end;

[0025] Receive the target verification parameter sent by the storage node, perform parameter verification on the target verification parameter and the first Merkel data, and obtain an access verification result of the user data.

[0026] In one embodiment, the step of performing parameter verification on the target verification parameter and the first Merkel data to obtain the access verification result of the user data includes:

[0027] Verify the signature random number using the public key of the storage node to obtain a first verification result of the signature random number;

[0028] Determine a data block to be verified in the first Merkel data based on the signature random number, verify the data block to be verified and the uploaded data block, and obtain a second verification result of the uploaded data block;

[0029] Calculate the signature random number using a second encryption algorithm to obtain third Merkle data of the signature random number;

[0030] Constructing a Merkle verification tree based on the first Merkle tree and the third Merkle tree, and calculating a Merkle verification tree root of the Merkle verification tree;

[0031] Compare and verify the Merkle verification tree root and the Merkle proof tree root to obtain a third verification result of the Merkle verification tree root;

[0032] Performing hash verification on the third Merkel data, the Merkel proof tree root, and the Merkel proof path to obtain a fourth verification result of the third Merkel data;

[0033] An access verification result of the user data is obtained based on the first verification result, the second verification result, the third verification result and the fourth verification result.

[0034] In one embodiment, the step of obtaining the access verification result of the user data based on the first verification result, the second verification result, the third verification result, and the fourth verification result includes:

[0035] If at least one of the first verification result, the second verification result, the third verification result and the fourth verification result is verification failure, the access verification result of the user data is verification failure;

[0036] If the first verification result, the second verification result, the third verification result and the fourth verification result are all verified to be passed, then the access verification result of the user data is verified to be passed.

[0037] In addition, to achieve the above purpose, the present application also proposes a data availability verification device, the data availability verification device comprising:

[0038] A data receiving module, used for receiving user data sent by a client, encrypting the user data in slices, obtaining first Merkel data of the user data, and sending the first Merkel data to a random inspection verification terminal;

[0039] A parameter generation module is used to receive the encrypted random number sent by the random check verification end, obtain a target verification parameter according to the encrypted random number and the first Merkel data, send the target verification parameter to the random check verification end, and the random check verification end performs parameter verification on the target verification parameter to obtain an access verification result of the user data.

[0040] In addition, to achieve the above-mentioned purpose, the present application also proposes a data availability verification device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, and the computer program is configured to implement the steps of the data availability verification method as described above.

[0041] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the data availability verification method described above are implemented.

[0042] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, it implements the steps of the data availability verification method described above.

[0043] One or more technical solutions proposed in this application have at least the following technical effects:

[0044] The embodiment of the present application proposes a method, device, equipment and computer program product for verifying the availability of data. The method receives user data sent by a client, encrypts the user data in pieces, obtains the first Merkel data of the user data, and sends the first Merkel data to a spot check verification terminal; receives an encrypted random number sent by the spot check verification terminal, obtains a target verification parameter based on the encrypted random number and the first Merkel data, sends the target verification parameter to the spot check verification terminal, and the spot check verification terminal performs parameter verification on the target verification parameter to obtain an access verification result of the user data. By encrypting and verifying the user data and obtaining the access verification result of the user data, the problem that the cloud disk data cannot be guaranteed to be always online and readable is solved, and the security of user data storage is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0046] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0047] Figure 1 A flowchart of the first embodiment of the method for verifying the availability of data in this application is provided;

[0048] Figure 2 A schematic diagram of the Merkle proof tree provided for the data availability verification method of this application;

[0049] Figure 3 A brief flowchart of the method for verifying the availability of data for this application;

[0050] Figure 4 A curve chart to verify the effectiveness of the method for verifying the availability of data in this application;

[0051] Figure 5 A schematic diagram of the module structure of a device for verifying the availability of data in an embodiment of the present application;

[0052] Figure 6 A schematic diagram of the device structure of the hardware operating environment involved in the data availability verification method in the embodiment of the present application.

[0053] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0054] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0055] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0056] The main solution of the embodiment of the present application is: receiving user data sent by the client, encrypting the user data in pieces, obtaining first Merkel data of the user data, and sending the first Merkel data to a random check verification end; receiving an encrypted random number sent by the random check verification end, obtaining a target verification parameter according to the encrypted random number and the first Merkel data, sending the target verification parameter to the random check verification end, and having the random check verification end perform parameter verification on the target verification parameter to obtain an access verification result of the user data.

[0057] In this embodiment, for the convenience of description, the following description is made by taking the availability verification device for identifying data as the execution subject.

[0058] The data is stored in the cloud disk through encryption algorithms, and the encrypted data is protected from unauthorized access and leakage. The data is encrypted when it is written to the cloud disk, and it is ensured that the data cannot be accessed or decrypted without authorization. Even if the cloud disk data is leaked, it cannot be decrypted. It is automatically decrypted when the authorized user reads the cloud disk data, thus ensuring the confidentiality and integrity of the cloud disk data.

[0059] At present, there is often a lack of a mechanism for regular data spot checks in cloud disk data storage systems. This means that the integrity and availability of user stored data cannot be fully guaranteed without regular inspection and verification, and the stored data cannot be guaranteed to be online at any time. Therefore, a method is needed to ensure that the user's stored data is always online and readable. At the same time, the cloud disk storing data may fail sometimes, and users do not know that the stored data is no longer accessible, so it is necessary to regularly check whether the data is effectively saved to ensure that it can be accessed online.

[0060] The present application provides a solution, which obtains access verification results by encrypting and verifying user data, thereby solving the problem that cloud disk data cannot be guaranteed to be always online and readable, and improving the security of user data storage.

[0061] It should be noted that the execution subject of this embodiment may be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a data availability verification device, etc. The following takes the data availability verification device as an example to illustrate this embodiment and the following embodiments.

[0062] Based on this, the present application embodiment provides a method for verifying the availability of data, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the method for verifying the availability of data in this application.

[0063] In this embodiment, the data availability verification is applied to the storage node, and the method includes steps S10 to S20:

[0064] Step S10, receiving user data sent by the client, encrypting the user data in segments, obtaining first Merkel data of the user data, and sending the first Merkel data to the spot check verification end.

[0065] It should be noted that a storage node refers to a device or system used to store user data. It is responsible for storing user data as encrypted files and promptly responding to random inspections by the inspection verification end to ensure that the encrypted files are accessible online.

[0066] In addition, it should be noted that the user terminal refers to the computer device or software application used by the user. The user logs in to the storage node through the user terminal based on the user's decentralized identifier DID (Decentralized Identifier). Each DID corresponds to a unique user account. DID is a digital identity ownership certificate issued by an autonomous decentralized platform. It is a cryptographically verifiable universal unique identifier (UUID) framework that can be created without the need for a central registration agency. DID has the characteristics of decentralization, user sovereignty and privacy protection, and can be applied in decentralized scenarios based on blockchain. Users log in to the storage node through the decentralized identifier DID to ensure user authorized login.

[0067] In addition, it should be noted that user data refers to data that is transmitted and stored in a storage node after a user logs in to the storage node through a client.

[0068] Specifically, the user logs in to the storage node using a decentralized identifier DID on the client, the client obtains the user data of the user, and sends the user data to the storage node. After receiving the user data, the storage node fills and splits the user data to obtain sharded data blocks of the user data; encrypts the sharded data blocks using a first encryption algorithm to obtain sharded encrypted data of the user data; and re-encrypts the sharded encrypted data using a second encryption algorithm to obtain the first Merkel data of the sharded encrypted data.

[0069] Step S20, receiving the encrypted random number sent by the random check verification end, obtaining a target verification parameter according to the encrypted random number and the first Merkel data, sending the target verification parameter to the random check verification end, and having the random check verification end perform parameter verification on the target verification parameter to obtain an access verification result of the user data.

[0070] It should be noted that the encrypted random number refers to the random number periodically generated by the blockchain system at fixed time intervals. In one embodiment of the present application, the fixed time interval is 5 minutes, that is, the blockchain system generates a random number every 5 minutes.

[0071] In addition, it should be noted that the random inspection and verification end includes the blockchain system. The blockchain system is a decentralized distributed database system, which consists of multiple nodes. Each node has a complete copy of the blockchain data. The blockchain system ensures data consistency and security through a consensus algorithm.

[0072] Specifically, the blockchain system periodically generates an encrypted random number at random, and sends the encrypted random number to a storage node. After receiving the encrypted random number, the storage node signs the encrypted random number by using the private key of the storage node to obtain a signature random number of the encrypted random number; modulo the signature random number to determine the uploaded data block in the sharded encrypted data; calculate the signature random number by using a second encryption algorithm to obtain the second Merkel data of the signature random number; construct a Merkel proof tree based on the first Merkel data and the second Merkel data, and calculate the Merkel proof tree root of the Merkel proof tree and the Merkel proof path of the second Merkel data; obtain the target verification parameters of the sharded encrypted data based on the signature random number, the uploaded data block, the Merkel proof tree root, the Merkel proof path and the public key of the storage node.

[0073] Through the above scheme, this embodiment receives the encrypted random number periodically sent by the spot check verification end through the storage node, obtains the target verification parameter in combination with the first Merkel data in the storage node, sends the target verification parameter to the spot check verification end for parameter verification, and obtains the access verification result of the user data, which solves the problem that the cloud disk data cannot be guaranteed to be always online and readable, and improves the security of user data storage.

[0074] Based on the above implementation scheme, in a feasible implementation scheme, the step of performing shard encryption on the user data to obtain the first Merkle data of the user data includes S11 to S13:

[0075] Step S11, filling and dividing the user data to obtain fragmented data blocks of the user data.

[0076] Specifically, after receiving the user data, the user data is first formatted and converted into a content addressable address file. The content addressable address file is a file in CAR (Content Addressable aRchives (CAR / .car), content addressable address) format. The CAR format can be used to store a byte sequence of a content addressable object in the form of IPLD block data. For example, the user data DATA is converted into a file in DATA.car format.

[0077] Further, the file in the DATA.car format is filled with "0" and the file is filled with bytes that are the nearest integer multiple of 31 to obtain the filled file. For example, the file in the DATA.car format is filled with "0" and the file is filled with bytes that are the nearest integer multiple of 31 to obtain the filled file data block KDATA.

[0078] Furthermore, the padded data block is evenly divided into 31 parts to obtain fragmented data blocks. For example, first calculate the length N of the data block KDATA KDATA = LengthOf(KDATA), where N KDATA is the length of the data block KDATA, and LengthOf() is the function for calculating the data length. i The first byte position is (N KDATA *(i-1)) / 31, the last byte position is (N KDATA *i) / 31-1, where i=1, 2, ..., 31. The fragmented data blocks are KDATA1, KDATA2, ..., KDATA 31 , KDATA={KDATA1, KDATA2,...,KDATA 31}.

[0079] Step S12: encrypt the sharded data block using a first encryption algorithm to obtain sharded encrypted data of the user data.

[0080] It should be noted that the first encryption algorithm refers to the AES (Advanced Encryption Standard) encryption algorithm, which is a symmetric encryption algorithm. The encryption and decryption processes of the AES encryption algorithm use the same key, and the encryption and decryption of data are realized through a series of complex transformation operations. The specific steps are key expansion, initial round, relay round and final round. Key expansion means that the original key is used to generate a series of subkeys, which are used in the subsequent encryption process; the initial round includes a byte substitution (SubBytes) and row shift (ShiftRows) operation; the byte substitution operation replaces each byte in the state matrix with the value in the S box, and the row shift operation cyclically shifts the rows of the state matrix. In the relay round, each round will perform a byte substitution, row shift, column mixing (MixColumns) and round key addition (AddRoundKey) operation. The column mixing operation realizes data obfuscation by multiplying the state matrix with the fixed matrix, and the round key addition operation is to perform an XOR operation on the expanded key and the state matrix. The final round is similar to the relay round, but the column mixing operation is no longer performed.

[0081] Specifically, the user uses the decentralized identifier DID to log in to the storage node on the client side, uses the decentralized identifier DID as the original key of the AES encryption algorithm, and encrypts the shard data blocks separately through the AES encryption algorithm to generate the corresponding shard encrypted data. For example, the user uses the decentralized identifier DID to log in to the storage node on the client side, uses the decentralized identifier DID as the original key of the AES encryption algorithm, and encrypts the shard data blocks KDATA1, KDATA2, ..., KDATA through the AES encryption algorithm. 31 , generate corresponding fragmented encrypted data SDATA1, SDATA2, ..., SDATA 31 , encrypted file SDATA = {SDATA1, SDATA2, ..., SDATA 31 The AES encryption algorithm is a symmetric encryption algorithm, and the user's decentralized identification DID key is also required to decrypt the encrypted data.

[0082] Step S13: re-encrypt the sharded encrypted data using a second encryption algorithm to obtain first Merkle data of the sharded encrypted data.

[0083] It should be noted that the second encryption algorithm refers to SHA256 (Secure Hash Algorithm 256), which is a cryptographic hash function that can convert data of any length (such as files, messages, etc.) into a fixed-length (256 bits, i.e. 32 bytes) hash value, which is represented by 64 hexadecimal characters. The specific steps of the SHA256 algorithm include the preprocessing stage (message padding and initialization of hash value), the message processing stage (message block and compression function), and the output stage (generating hash value).

[0084] Specifically, the sharded encrypted data is re-encrypted using the SHA256 encryption algorithm to obtain the first Merkle data of the sharded encrypted data. i =SHA256(SDATA i ), where i = 1, 2, ... 31, B i For the first Merkel data, SDATA i Encrypt data for the shard. i As the leaf value of the i-th leaf of the subsequent Merkle proof tree.

[0085] Furthermore, after the first Merkle data is calculated, the first Merkle data is written into the blockchain system of the random inspection verification end to put the data on the chain. For example, the storage node submits {user's DID, DAT.car file name, B1, B2, ..., B 31}, where B1, B2, ..., B 31 The order and values ​​between them cannot be changed.

[0086] Through the above scheme, this embodiment can improve the reading and writing speed of data by filling and splitting the user data, especially when processing large-scale data sets, it can significantly improve the efficiency of data processing; using the first encryption algorithm and the second encryption algorithm to encrypt the sharded data blocks can ensure the confidentiality of the data during transmission and storage, and prevent data leakage to unauthorized third parties.

[0087] Based on the above implementation scheme, in a feasible implementation manner, the step of obtaining the target verification parameter according to the encrypted random number and the first Merkel data includes S21 to S25:

[0088] Step S21, signing the encrypted random number by using the private key of the storage node to obtain a signed random number of the encrypted random number.

[0089] It should be noted that the private key and public key of the storage node are the private key and public key on the elliptic cryptographic curve ECC, the private key sk is used to sign information, and the public key pk is used to verify the signature.

[0090] Specifically, the private key of the storage node is obtained from the elliptic cryptographic curve ECC, and the encrypted random number sent by the blockchain system is signed by the private key to obtain the signed random number. For example, the encrypted random number R is signed by the private key of the storage node to obtain the signed random number RM.

[0091] Step S22, taking a modulus from the signature random number to determine the uploaded data block in the fragmented encrypted data.

[0092] Specifically, the signature random number RM is modulo 31 to obtain the value N, and the fragmented encrypted data SDATA is i The N+1th data SDATA N+1 As upload data chunks.

[0093] Step S23, calculating the signature random number by using a second encryption algorithm to obtain second Merkle data of the signature random number.

[0094] Specifically, the signature random number RM is modulo 32 and then added with 1 to obtain an intermediate number M between 1 and 32. M is used as the second Merkle data B. M The leaf sequence number in the subsequent Merkle proof tree is calculated by the second encryption algorithm SHA256 on the signature random number to obtain the second Merkle data, the second Merkle data B M The value is SHA256(RM).

[0095] Step S24, constructing a Merkle proof tree based on the first Merkle data and the second Merkle data, and calculating a Merkle proof tree root of the Merkle proof tree and a Merkle proof path of the second Merkle data.

[0096] It should be noted that the Merkle proof tree is based on the set {B1, B2, ..., B M ,……,B 31}. The Merkle tree (also called hash tree) is a typical binary tree structure, consisting of a root node, a set of intermediate nodes and a set of leaf nodes. The Merkle tree was first proposed by Merkle Ralf in 1980 and has been widely used in file systems and P2P systems (Peer-to-Peer). For example, git, blockchain, IPFS (InterPlanetary File System), etc. The bottom leaf node contains the stored data or its hash value; non-leaf nodes (including intermediate nodes and root nodes) are the hash values ​​of the contents of its two child nodes. The Merkle tree can be extended to the case of a multi-branch tree, in which case the content of the non-leaf node is the hash value of the content of all its child nodes.

[0097] Specifically, the second Merkle data BM is put into the first Merkle data set {B1, B2, ..., B 31}, we get the set of 32 elements {B1, B2, ..., B M ,……,B 31}, where M∈[1,32], the set {B1, B2, …, B M ,……,B 31 The 32 elements in} are used as Merkle tree leaves in order to construct a Merkle tree, namely, a Merkle proof tree. Based on the Merkle proof tree, the Merkle proof tree root CommD of the Merkle proof tree and the Merkle proof path D from the second Merkle data to the Merkle proof tree root are calculated.

[0098] For better understanding, please refer to Figure 2 , Figure 2 This is a schematic diagram of the structure of the Merkle proof tree. Figure 2 Medium SDATA i is the sharded encrypted data, B i is the first Merkle data, where i = 1, 2, ... 31, SHA256 is the second encryption algorithm, and CommD is the Merkle proof tree root. M ,……,B 31} Based on the construction principle of the Merkle tree, a Merkle proof tree is constructed. The first Merkle data is obtained by encrypting the sharded encrypted data with SHA256, that is, B i =SHA256(SDATA i ), and then according to the constructed Merkle proof tree, obtain the root value of the Merkle proof tree and the path from the second Merkle data to the root, that is, the Merkle proof path.

[0099] Step S25, based on the signature random number, the uploaded data block, the Merkle proof tree root, the Merkle proof path and the public key of the storage node, obtain the target verification parameters of the sharded encrypted data.

[0100] It should be noted that the private key and public key of the storage node are the private key and public key on the elliptic cryptographic curve ECC, the private key sk is used to sign information, and the public key pk is used to verify the signature.

[0101] Specifically, based on the signature random number, uploaded data block, Merkle proof tree root, Merkle proof path and public key of storage node, the target verification parameter of the sharded encrypted data is obtained. The data content of the target verification parameter includes {Merkle proof tree root CommD, encrypted random number R, signature random number RM, Merkle proof path D of the second Merkle data, public key of storage node, B N+1 , upload data block SDATA N+1}, submit the target verification parameters of the sharded encrypted data to the blockchain system.

[0102] Based on the above implementation scheme, in a feasible implementation mode, the method is applied to a client, and the method includes steps S30 to S40:

[0103] Step S30, obtaining user data of the user.

[0104] Specifically, obtain the user's decentralized identifier DID and user data, use the decentralized identifier DID to log in to the storage node on the client, and upload the user data on the client.

[0105] Furthermore, the client can also decrypt the encrypted data SDATA. After the client obtains the encrypted file SDATA from the storage node, it divides SDATA into 31 parts, namely SDATA1, SDATA2, ..., SDATA 31 , SDATA=SDATA1+SDATA2+……+SDATA 31 . Based on the user's DID as the key, the AES decryption algorithm is used to decrypt {SDATA1, SDATA2, ..., SDATA 31}, get KDATA = {KDATA1, KDATA2, ..., KDATA 31}, where KDATA=KDATA1+KDATA2+……+KDATA 31 . Remove the 0s at the end of KDATA to get the data.car file, which is the original file after decryption.

[0106] Step S40, sending the user data to a storage node, having the storage node perform shard encryption on the user data to obtain first Merkel data of the user data, sending the first Merkel data to a random check verification end, having the storage node receive the encrypted random number sent by the random check verification end, obtaining a target verification parameter based on the encrypted random number and the first Merkel data, sending the target verification parameter to the random check verification end, having the random check verification end perform parameter verification on the target verification parameter, and obtaining an access verification result of the user data.

[0107] Specifically, after the client obtains the user data, it submits the user data to the storage node, and the storage node stores the received user data under the user's corresponding login account. Then the user data is filled and split to obtain the sharded data blocks of the user data; the sharded data blocks are encrypted by the first encryption algorithm to obtain the sharded encrypted data of the user data; the sharded encrypted data is re-encrypted by the second encryption algorithm to obtain the first Merkel data of the sharded encrypted data; and the first Merkel data is sent to the blockchain system of the spot check verification end.

[0108] Furthermore, an encrypted random number sent by the blockchain system is received, and the encrypted random number is signed by the private key of the storage node to obtain a signature random number of the encrypted random number; the signature random number is modulo-ed to determine the uploaded data block in the sharded encrypted data; the signature random number is calculated by a second encryption algorithm to obtain the second Merkel data of the signature random number; a Merkel proof tree is constructed based on the first Merkel data and the second Merkel data, and the Merkel proof tree root of the Merkel proof tree and the Merkel proof path of the second Merkel data are calculated; based on the signature random number, the uploaded data block, the Merkel proof tree root, the Merkel proof path and the public key of the storage node, the target verification parameters of the sharded encrypted data are obtained, and the target verification parameters are sent to the blockchain system.

[0109] Furthermore, after receiving the target verification parameter, the blockchain system performs signature verification on the signature random number through the public key of the storage node in the target verification parameter to obtain a first verification result; determines the data block to be verified in the first Merkel data based on the signature random number, verifies the data block to be verified and the uploaded data block, and obtains a second verification result of the uploaded data block; calculates the signature random number through the second encryption algorithm to obtain the third Merkel data of the signature random number; constructs a Merkel verification tree based on the first Merkel tree and the third Merkel tree, calculates the Merkel verification tree root of the Merkel verification tree and the Merkel verification path of the third Merkel data; compares and verifies the Merkel verification tree root and the Merkel proof tree root to obtain a third verification result of the Merkel verification tree root; performs hash verification on the third Merkel data, the Merkel proof tree root and the Merkel proof path to obtain a fourth verification result of the third Merkel data; obtains the access verification result of the user data based on the first verification result, the second verification result, the third verification result and the fourth verification result. If at least one of the first verification result, the second verification result, the third verification result and the fourth verification result is verification failure, then the access verification result of the user data is verification failure; if the first verification result, the second verification result, the third verification result and the fourth verification result are all verified, then the access verification result of the user data is verification success.

[0110] Based on the above implementation scheme, in a feasible implementation mode, the method is applied to a random inspection verification end, and the method includes steps S50 to S70:

[0111] Step S50, receiving first Merkel data sent by the storage node, where the first Merkel data is obtained by the client acquiring user data of the user, sending the user data to the storage node, and the storage node encrypting the user data in fragments.

[0112] Specifically, the client obtains the user's DID and user data, logs in to the storage node through the DID, and sends the user data to the storage node. After receiving the user data, the storage node converts the user data into a car file format, and then fills and slices the data in the car file format to obtain a sharded data block of the user data; encrypts the sharded data block through a first encryption algorithm to obtain sharded encrypted data of the user data; re-encrypts the sharded encrypted data through a second encryption algorithm to obtain the first Merkel data of the sharded encrypted data, and sends the first Merkel data to the blockchain system of the spot check verification end.

[0113] Step S60: periodically send an encrypted random number to a storage node, the storage node obtains a target verification parameter according to the encrypted random number and the first Merkel data, and sends the target verification parameter to a spot check verification terminal.

[0114] Specifically, the blockchain system periodically generates encrypted random numbers and sends them to the storage node. For example, the blockchain system generates a random number every five minutes and sends it to the storage node. After receiving the random number, the storage node performs parameter verification with the first Merkle data to obtain the target verification parameter, and sends the target verification parameter to the blockchain system.

[0115] Step S70: receiving the target verification parameter sent by the storage node, performing parameter verification on the target verification parameter and the first Merkel data, and obtaining an access verification result of the user data.

[0116] Specifically, the signature random number is verified by the public key of the storage node to obtain a first verification result of the signature random number; based on the signature random number, the data block to be verified in the first Merkel data is determined, and the data block to be verified and the uploaded data block are verified to obtain a second verification result of the uploaded data block; the signature random number is calculated by a second encryption algorithm to obtain a third Merkel data of the signature random number; a Merkel verification tree is constructed based on the first Merkel tree and the third Merkel tree, and the Merkel verification tree root of the Merkel verification tree and the Merkel verification path of the third Merkel data are calculated; the Merkel verification tree root and the Merkel proof tree root are compared and verified to obtain a third verification result of the Merkel verification tree root; the third Merkel data, the Merkel proof tree root and the Merkel proof path are hashed to obtain a fourth verification result of the third Merkel data; based on the first verification result, the second verification result, the third verification result and the fourth verification result, an access verification result of the user data is obtained.

[0117] Based on the above implementation scheme, in a feasible implementation manner, the step of performing parameter verification on the target verification parameter and the first Merkel data to obtain the access verification result of the user data includes S71 to S77:

[0118] Step S71, verifying the signature random number through the public key of the storage node to obtain a first verification result of the signature random number.

[0119] Specifically, the public key of the storage node is obtained from the elliptic encryption curve ECC of the storage node, and the signature verification is performed on the random number RM signed by the ECC elliptic encryption algorithm based on the public key of the storage node to verify whether the signature random number is generated by the private key signature of the storage node. For example, the public key of the storage node is used to perform signature verification on RM to obtain data R', and verify whether R' and the encrypted random number R are consistent. If they are consistent, the first verification result of the signature random number is verification passed, and subsequent parameter verification is performed; if they are inconsistent, the first verification result of the signature random number is verification failed, and the parameter verification ends.

[0120] Step S72: determine the data block to be verified in the first Merkel data based on the signature random number, verify the data block to be verified and the uploaded data block, and obtain a second verification result of the uploaded data block.

[0121] Specifically, the signature random number R is modulo 31 to obtain N, and the data block B to be verified is obtained from the first Merkle data received from the blockchain system. N+1 , verify B N+1 and SHA256 (upload data block SDATA N+1 ) are equal, the second verification result is obtained. N+1 and SHA256 (upload data block SDATA N+1 ) are equal, the second verification result is verification passed, and subsequent parameter verification is performed; if B N+1 and SHA256 (upload data block SDATA N+1 ) are not equal, the second verification result is verification failure, and the parameter verification ends.

[0122] Step S73, calculating the signature random number by using a second encryption algorithm to obtain third Merkle data of the signature random number.

[0123] Specifically, the signature random number is calculated by the second encryption algorithm SHA256 to obtain the third Merkle data of the signature random number. For example, the signature random number RM is calculated by the SHA256 algorithm to obtain the third Merkle data, that is, B M '=SHA256(RM), where B M 'For the third Merkel data.

[0124] Step S74: construct a Merkle verification tree based on the first Merkle tree and the third Merkle tree, and calculate the Merkle verification tree root of the Merkle verification tree.

[0125] Specifically, obtain the first Merkle data set {B1, B2, ..., B 31}, the third Merkle data B M 'Put it into the M'th position in the first Merkle data set, and get a set of 32 elements {B1, B2, ..., B M ', ..., B 31}, where M'∈[1,32], the set {B1, B2, ..., B M ', ..., B 31The 32 elements in} are sequentially used as Merkle tree leaves to construct a Merkle tree, namely, a Merkle verification tree. Based on the Merkle verification tree, the Merkle verification tree root CommD' of the Merkle verification tree and the Merkle verification path from the third Merkle data BM' to the Merkle verification tree root CommD' are calculated.

[0126] Step S75, compare and verify the Merkel verification tree root and the Merkel proof tree root to obtain a third verification result of the Merkel verification tree root.

[0127] Specifically, the Merkel verification tree root CommD' is compared and verified with the Merkel proof tree root CommD in the target verification parameter to obtain the third verification result of the Merkel verification tree root. If CommD'=CommD, the third verification result is verification passed, and the subsequent parameter verification continues; if CommD'≠CommD, the third verification result is verification failed, and the parameter verification ends.

[0128] Step S76, performing hash verification on the third Merkel data, the Merkel proof tree root, and the Merkel proof path to obtain a fourth verification result of the third Merkel data.

[0129] Specifically, the third Merkle data B M 'Bring in the corresponding leaf position of BM in the Merkle proof tree, and compare the Merkle proof tree root, B M 'The Merkle proof path is hashed and verified. M 'Whether it is a leaf of the Merkle proof tree, the fourth verification result of the third Merkle data is obtained. If the third Merkle data is a leaf of the Merkle proof tree, the fourth verification result is a successful verification, and {the user's decentralized identifier DID, DATA.car file name, encrypted random number R, Merkle proof tree root CommD, signature random number RM, Merkle proof path D, public key of the storage node} is written into the blockchain system, indicating that the encrypted file SDATA of the DATA.car file is accessible. If the third Merkle data is not a leaf of the Merkle proof tree, the fourth verification result is a failed verification, indicating that the encrypted file SDATA of the DATA.car file is currently inaccessible.

[0130] Step S77, obtaining an access verification result of the user data based on the first verification result, the second verification result, the third verification result and the fourth verification result.

[0131] Specifically, if at least one of the first verification result, the second verification result, the third verification result and the fourth verification result is verification failure, then the access verification result of the user data is verification failure; if the first verification result, the second verification result, the third verification result and the fourth verification result are all verified, then the access verification result of the user data is verification success.

[0132] This embodiment uses the above solution to perform parameter verification on the target verification parameter and the first Merkle data to obtain the access verification result of the user data. If the verification is successful, it means that the encrypted file stored in the storage node is currently accessible online. If the verification fails, it means that the encrypted file stored in the storage node is currently unreadable. Therefore, it is ensured that the user's data is correctly stored by the storage node and can be accessed at any time, ensuring that the user's data can be accessed at any time.

[0133] Based on the above implementation scheme, in a feasible implementation manner, the step of obtaining the access verification result of the user data based on the first verification result, the second verification result, the third verification result and the fourth verification result includes S771-S772:

[0134] Step S771: If at least one of the first verification result, the second verification result, the third verification result and the fourth verification result is verification failure, the access verification result of the user data is verification failure.

[0135] Specifically, if at least one of the first verification result, the second verification result, the third verification result, and the fourth verification result is a verification failure, then the access verification result of the user data is a verification failure, indicating that the current user data cannot be accessed. The verification order of the parameter verification corresponding to the first verification result, the second verification result, the third verification result, and the fourth verification result is not limited, and the "first", "second", etc., represent the difference. In one embodiment of the present application, the parameter verification is performed in the order of the specific steps of step S70.

[0136] Step S772: If the first verification result, the second verification result, the third verification result and the fourth verification result are all verified to be passed, then the access verification result of the user data is verified to be passed.

[0137] Specifically, if the first verification result, the second verification result, the third verification result, and the fourth verification result are all verified to be passed, then the access verification result of the user data is verified to be passed, indicating that the current user data can be accessed.

[0138] For better understanding, please refer to Figure 3 , Figure 3The following is a brief flowchart of the data availability verification method. First, the decentralized identifier DID and user data of user A are obtained from the user client, and the original file data.car is obtained after the user data is formatted. The storage node B is logged in through the DID. Then the data.car file is sent to the storage node B. The storage node mainly includes an encryption storage module and a Merkel tree leaf chain module. The encryption storage module fills the data.car data with zeros to fill it into an integer multiple of 31 bytes, and then divides the filled file into 31 parts on average. The divided data blocks are then encrypted by the first encryption algorithm to obtain the sharded encrypted data SDATAi, the sharded encrypted data are numbered, and then the sharded encrypted data are re-encrypted by the SHA256 algorithm of the Merkel tree leaf chain module to generate the first Merkel data Bi=SHA256(SDATA i ), {user's DID, data.car file name, B1, B2, ..., B 31}Write to the blockchain system. Among them, the CAR file format is mainly used to store serialized DAG (directed acyclic graph) data structure, which is intended to be a serialized representation of any IPLD DAG as a concatenation of block data; the CAR file contains a CAR header data block, which contains the root CID (root CID), an IPLD DAG (InterPlanetary Linked Data DirectedAcyclic Graph) data block of any type, and a series of IPLD (InterPlanetary LinkedData) data blocks.

[0139] Furthermore, the blockchain system sends a random number R to the storage node every 5 minutes for random inspection. R is equal to the distributed random number DRAND at the current moment. The Merkle tree leaf on-chain module of the storage node B receives the random number R (encrypted random number) sent by the blockchain system, signs R with the private key of the storage node, and obtains RM (signed random number). RM is modulo 32 and then added by 1 to obtain the value M, which is an integer between 1 and 32. M is used as the second Merkle data B. M The sequence number in the first Merkle tree data, B M The value of B M=SHA256(RM), RM is modulo 31 to obtain the value N, the N+1th data block in the first Merkel data is read as the random data block (upload data block), and then a Merkel tree is constructed based on the first Merkel tree data and the second Merkel data to generate a dynamic random Merkel proof tree (the Merkel proof tree in this application), and the stacked Merkel root D (the Merkel proof tree root in this application) and the random Merkel path CommD (the Merkel proof path in this application) of the dynamic random Merkel proof tree are calculated, and then the target verification parameters are obtained, and the target verification parameters are submitted to the blockchain system for verification request, wherein the target verification parameters include {random Merkel root CommD, DRAND (encrypted random number), RM (signature random number), random Merkel path D, public key of the storage node, B N+1 , random data block (upload data block SDATA N+1 )}.

[0140] Furthermore, after receiving the target verification parameters, the blockchain network verifies the target verification parameters through the random Merkle path verification algorithm. If the verification is successful, it means that the encrypted file data.car is currently accessible, and {user A's DID, data.car file name, random number R (encrypted random number), CommD (Merkle proof tree root), RM (signature random number), random Merkle path D, storage node B's public key, B N+1 , random data block (upload data block SDATA N+1 )} is written into the blockchain system; if the verification fails, it means that the encrypted file data.car is currently inaccessible.

[0141] Furthermore, the embodiments of the present application also provide a spot check validity certification process of the present application:

[0142] Assume that the data is divided into N blocks, M of which are unavailable. Sample the N blocks of data, the number of sampling is x, and the probability of finding an unavailable data block after sampling x times is y.

[0143] The probability of finding an unavailable data block after one random check is:

[0144]

[0145] Therefore, the probability of finding an unavailable data block by spot checking x is:

[0146] y=1-(1-p) x

[0147] In one embodiment of the present application, N=31, then the image reference of probability y under different values ​​of M is Figure 4 , Figure 4This is a curve chart of the sampling times and the probability of discovery when the number of unavailable data blocks is 1 / 3 / 5 / 10. Figure 4 In the above equation, under the condition of sampling times x, the probabilities corresponding to different M values ​​are:

[0148] M=1, x=200, y=99.8%

[0149] M=3, x=60, y=99.7%

[0150] M=5, x=40, y=99.9%

[0151] M=10, x=15, y=99.7%

[0152] from Figure 4 As can be seen from the data, even if only one data block is unavailable, it can be discovered with a probability of more than 99% within 200 samples (calculated as about 16 hours with a sampling time of 5 minutes). Especially when the number of unavailable data blocks is greater than 1, it can be discovered in just dozens of times. Therefore, it can be proved that the data availability verification method of this application is effective.

[0153] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the method for verifying the availability of data of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0154] This application also provides a data availability verification device, please refer to Figure 5 , the data availability verification device comprises:

[0155] The data receiving module 501 is used to receive user data sent by the client, encrypt the user data in slices, obtain first Merkel data of the user data, and send the first Merkel data to the spot check verification end;

[0156] The parameter generation module 502 is used to receive the encrypted random number sent by the random check verification end, obtain the target verification parameter according to the encrypted random number and the first Merkel data, send the target verification parameter to the random check verification end, and the random check verification end performs parameter verification on the target verification parameter to obtain the access verification result of the user data.

[0157] The data availability verification device provided by the present application adopts the data availability verification method in the above-mentioned embodiment, which can solve the technical problem that the cloud disk data cannot be always online and accessible. Compared with the prior art, the beneficial effects of the data availability verification device provided by the present application are the same as the beneficial effects of the data availability verification method provided by the above-mentioned embodiment, and the other technical features in the data availability verification device are the same as the features disclosed in the above-mentioned embodiment method, which will not be repeated here.

[0158] The present application provides a data availability verification device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the data availability verification method in the above-mentioned embodiment one.

[0159] Reference below Figure 6 , which shows a schematic diagram of the structure of a data availability verification device suitable for implementing the embodiment of the present application. The data availability verification device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The data availability verification device shown is merely an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0160] like Figure 6As shown, the data availability verification device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the data availability verification device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the data availability verification device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows the data availability verification device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0161] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0162] The data availability verification device provided by the present application adopts the data availability verification method in the above embodiment, which can solve the technical problem that cloud disk data cannot be always online and accessible. Compared with the prior art, the beneficial effects of the data availability verification device provided by the present application are the same as the beneficial effects of the data availability verification method provided by the above embodiment, and the other technical features in the data availability verification device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0163] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0164] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0165] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the data availability verification method in the above-mentioned embodiment.

[0166] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0167] The computer-readable storage medium may be included in the data availability verification device; or may exist independently without being assembled into the data availability verification device.

[0168] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the data availability verification device, the data availability verification device: receives user data sent by the client, encrypts the user data in segments, obtains the first Merkel data of the user data, and sends the first Merkel data to the random check verification end; receives the encrypted random number sent by the random check verification end, obtains the target verification parameter according to the encrypted random number and the first Merkel data, sends the target verification parameter to the random check verification end, and the random check verification end performs parameter verification on the target verification parameter to obtain the access verification result of the user data.

[0169] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0170] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0171] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0172] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned data availability verification method, and can solve the technical problem that cloud disk data cannot be always online and accessible. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the data availability verification method provided in the above-mentioned embodiment, and will not be elaborated here.

[0173] The present application also provides a computer program product, including a computer program, which implements the steps of the data availability verification method as described above when executed by a processor.

[0174] The computer program product provided by this application can solve the technical problem that cloud disk data cannot be always online and accessible. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the data availability verification method provided by the above embodiment, which will not be repeated here.

[0175] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for verifying data availability, characterized in that: The method is applied to a storage node, and the method comprises: Receive user data sent by the client, encrypt the user data in segments, obtain first Merkel data of the user data, and send the first Merkel data to the spot check verification end; Receive the encrypted random number sent by the random check verification end, obtain a target verification parameter according to the encrypted random number and the first Merkel data, send the target verification parameter to the random check verification end, and the random check verification end performs parameter verification on the target verification parameter to obtain an access verification result of the user data.

2. The method according to claim 1, characterized in that The step of performing shard encryption on the user data to obtain the first Merkle data of the user data comprises: Filling and segmenting the user data to obtain fragmented data blocks of the user data; Encrypting the sliced ​​data block by using a first encryption algorithm to obtain sliced ​​encrypted data of the user data; The sharded encrypted data is re-encrypted by a second encryption algorithm to obtain first Merkle data of the sharded encrypted data.

3. The method according to claim 2, characterized in that The step of obtaining a target verification parameter according to the encrypted random number and the first Merkel data comprises: Sign the encrypted random number using the private key of the storage node to obtain a signed random number of the encrypted random number; Taking a modulus of the signature random number to determine an upload data block in the sliced ​​encrypted data; Calculate the signature random number using a second encryption algorithm to obtain second Merkle data of the signature random number; Building a Merkle proof tree based on the first Merkle data and the second Merkle data, and calculating a Merkle proof tree root of the Merkle proof tree and a Merkle proof path of the second Merkle data; Based on the signature random number, the uploaded data block, the Merkle proof tree root, the Merkle proof path and the public key of the storage node, the target verification parameter of the sliced ​​encrypted data is obtained.

4. A method for verifying data availability, characterized in that: The method is applied to a client, and the method comprises: Get user data of the user; The user data is sent to a storage node, and the storage node performs shard encryption on the user data to obtain first Merkel data of the user data, and the first Merkel data is sent to a random check verification end. The storage node receives the encrypted random number sent by the random check verification end, obtains a target verification parameter according to the encrypted random number and the first Merkel data, and sends the target verification parameter to the random check verification end. The random check verification end performs parameter verification on the target verification parameter to obtain an access verification result of the user data.

5. A method for verifying data availability, characterized in that: The method is applied to a random inspection verification terminal, and the method includes: Receive first Merkel data sent by the storage node, where the first Merkel data is obtained by obtaining user data of a user from a client, sending the user data to the storage node, and the storage node sharding and encrypting the user data; Periodically sending an encrypted random number to a storage node, the storage node obtaining a target verification parameter according to the encrypted random number and the first Merkel data, and sending the target verification parameter to a spot check verification end; Receive the target verification parameter sent by the storage node, perform parameter verification on the target verification parameter and the first Merkel data, and obtain an access verification result of the user data.

6. The method according to claim 5, characterized in that The step of performing parameter verification on the target verification parameter and the first Merkel data to obtain the access verification result of the user data includes: Verify the signature random number using the public key of the storage node to obtain a first verification result of the signature random number; Determine a data block to be verified in the first Merkel data based on the signature random number, verify the data block to be verified and the uploaded data block, and obtain a second verification result of the uploaded data block; Calculate the signature random number using a second encryption algorithm to obtain third Merkle data of the signature random number; Constructing a Merkle verification tree based on the first Merkle tree and the third Merkle tree, and calculating a Merkle verification tree root of the Merkle verification tree; Compare and verify the Merkle verification tree root and the Merkle proof tree root to obtain a third verification result of the Merkle verification tree root; Performing hash verification on the third Merkel data, the Merkel proof tree root, and the Merkel proof path to obtain a fourth verification result of the third Merkel data; An access verification result of the user data is obtained based on the first verification result, the second verification result, the third verification result and the fourth verification result.

7. The method according to claim 6, characterized in that The step of obtaining the access verification result of the user data based on the first verification result, the second verification result, the third verification result and the fourth verification result comprises: If at least one of the first verification result, the second verification result, the third verification result and the fourth verification result is verification failure, the access verification result of the user data is verification failure; If the first verification result, the second verification result, the third verification result and the fourth verification result are all verified to be passed, then the access verification result of the user data is verified to be passed.

8. A data availability verification device, characterized in that: The device comprises: A data receiving module, used for receiving user data sent by a client, encrypting the user data in slices, obtaining first Merkel data of the user data, and sending the first Merkel data to a random inspection verification terminal; A parameter generation module is used to receive the encrypted random number sent by the random check verification end, obtain a target verification parameter according to the encrypted random number and the first Merkel data, send the target verification parameter to the random check verification end, and the random check verification end performs parameter verification on the target verification parameter to obtain an access verification result of the user data.

9. A data availability verification device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data availability verification method according to any one of claims 1 to 7.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the method for verifying the availability of data according to any one of claims 1 to 7 are implemented.

Images