Method and apparatus for verifying data integrity

Abstract

A method, apparatus, and device for verifying data integrity, including a computer program stored on a computer readable medium. One of the methods includes obtaining data content recorded on a blockchain, an encrypted data piece, a signature, and an encrypted hash value; decrypting the encrypted data piece to generate a decrypted data piece; parsing the decrypted data piece according to the data content to recover a sequence of random numbers used to create an original data piece corresponding to the encrypted data piece; calculating a hash value according to the data content, the encrypted data piece, and the signature; encrypting the hash value using the recovered sequence of random numbers; and determining the integrity of the data content by comparing the hash value encrypted using the recovered sequence of random numbers with the encrypted hash value recorded on the blockchain.

Description

Technical Field

[0001] This specification relates generally to computer technology, and more specifically to methods and apparatus for verifying data integrity. Background Technology

[0002] A blockchain system, also known as a distributed ledger system (DLS) or consensus system, enables participating parties to store data securely and immutably. Without referring to any specific use case, a blockchain system can include any DLS and can be used in public, private, and consortium blockchain networks. Public blockchain networks are open to all entities for use and participation in consensus processing. Private blockchain networks are provided to specific entities that centrally control read and write permissions. Consortium blockchain networks are provided to a selected group of entities that control consensus processing, and include an access control layer.

[0003] Blockchain systems are implemented using peer-to-peer (P2P) networks, where nodes communicate directly with each other, eliminating the need for a fixed central server. Each node in a P2P network can initiate communication with another node in the network. A blockchain system maintains one or more blockchains. A blockchain is a data structure used to store data such as transactions, preventing malicious parties from tampering with and manipulating the data.

[0004] While blockchain systems can securely and immutably record data, they may lack the ability to pre-check data integrity or trustworthiness. For example, if a user sends data to a blockchain system for recording, but a malicious party intercepts and manipulates the data before the blockchain system receives it, the lack of a mechanism to check the integrity of the received data means the blockchain system may continue to record the manipulated data, compromising the integrity of the data recorded on the blockchain. Summary of the Invention

[0005] In one aspect, a computer-implemented method for verifying data integrity includes: acquiring data content recorded on a blockchain, an encrypted data clip, a signature, and a cryptographic hash value; decrypting the encrypted data clip to generate a decrypted data clip; parsing the decrypted data clip based on the data content to recover a random number sequence used to create an original data clip corresponding to the encrypted data clip; calculating a hash value based on the data content, the encrypted data clip, and the signature; encrypting the hash value using the recovered random number sequence; and determining the integrity of the data content by comparing the hash value encrypted using the recovered random number sequence with the cryptographic hash value recorded on the blockchain.

[0006] On the other hand, an apparatus for verifying data integrity includes: one or more processors; and one or more computer-readable storage devices coupled to the one or more processors and having instructions stored thereon, which are executable by the one or more processors to: acquire data content recorded on a blockchain, encrypted data fragments, a signature, and a cryptographic hash value; decrypt the encrypted data fragments to generate decrypted data fragments; parse the decrypted data fragments according to the data content to recover a random number sequence used to create an original data fragment corresponding to the encrypted data fragments; calculate a hash value based on the data content, the encrypted data fragments, and the signature; encrypt the hash value using the recovered random number sequence; and determine the integrity of the data content by comparing the hash value encrypted using the recovered random number sequence with the cryptographic hash value recorded on the blockchain.

[0007] In another aspect, a non-transitory computer-readable medium stores instructions that, when executed by a processor of a device, cause the device to perform a method for verifying data integrity. The method includes: acquiring data content recorded on a blockchain, an encrypted data fragment, a signature, and a cryptographic hash value; decrypting the encrypted data fragment to generate a decrypted data fragment; parsing the decrypted data fragment based on the data content to recover a random number sequence used to create an original data fragment corresponding to the encrypted data fragment; calculating a hash value based on the data content, the encrypted data fragment, and the signature; encrypting the hash value using the recovered random number sequence; and determining the integrity of the data content by comparing the hash value encrypted using the recovered random number sequence with the cryptographic hash value recorded on the blockchain. Attached Figure Description

[0008] The accompanying drawings, which are included and form part of this document, illustrate embodiments. In the following description with reference to the drawings, unless otherwise stated, the same numerals in different drawings represent the same or similar elements.

[0009] Figure 1 This is a schematic diagram of a blockchain system according to an embodiment.

[0010] Figure 2 This is a schematic diagram of a computing device for implementing nodes in a blockchain system, according to an embodiment.

[0011] Figures 3A-3C This is a flowchart of a method for verifying data integrity according to an embodiment.

[0012] Figure 4 This is a schematic diagram depicting a data segment created based on data content and a random number sequence, according to an embodiment.

[0013] Figure 5 This is a flowchart of a method for verifying data integrity according to an embodiment.

[0014] Figure 6 This is a block diagram of an apparatus for verifying data integrity according to an embodiment. Detailed Implementation

[0015] Embodiments of this specification provide methods and apparatus for verifying data integrity. The methods and apparatus allow users to sign data content using signatures in some manner, thereby enabling the verification of the data content's integrity using the signatures. The methods and apparatus can also verify the authenticity of the signatures. Furthermore, the methods and apparatus can utilize a blockchain system to record information for verifying the integrity of the data content and the authenticity of the signatures, and in some embodiments, the methods and apparatus can utilize one or more smart contracts executed on the blockchain system to perform the verification.

[0016] The embodiments disclosed in this specification have one or more technical effects. In some embodiments, the methods and devices can process user signatures in a manner that allows the signature to be used to verify data integrity. This provides the methods and devices with the ability to determine whether data content has been modified after a user signs the data content, thereby improving data integrity. In some embodiments, the methods and devices can process the signature so that the authenticity of the signature can be verified. This allows the methods and devices to determine whether the signature was provided by the claimed signer, thereby further improving data integrity. In some embodiments, the methods and devices can process the signature in a way that prevents it from being forged. This enables the methods and devices to improve data security because even if a malicious party obtains the secret information (e.g., a personal identification code) of the signer used to generate the signature, the malicious party may still be unable to forge the signer's signature. Furthermore, in some embodiments, the methods and devices can implement voice signatures. This makes the methods and devices more user-friendly because users do not need to record the keys required to generate their signatures. Furthermore, in some embodiments, the methods and devices can utilize blockchain systems to record information for verifying data content integrity and signature authenticity. This allows the methods and devices to record information in data structures that can prevent malicious parties from tampering with and manipulating it.

[0017] A blockchain is a data structure used to store data such as transactions in a way that prevents malicious parties from tampering with and manipulating the data. Transactions stored in this way are likely immutable and subsequently verified. A blockchain consists of one or more blocks. Each block is linked to the preceding block by including its cryptographic hash. Each block may also include a timestamp, its own cryptographic hash, and one or more transactions. Transactions that have typically been verified by nodes in the blockchain system can be hashed and encoded into a data structure such as a Merkle tree. In a Merkle tree, the data at the leaf nodes is hashed, and all hashes in each branch of the tree can be linked at the root of that branch. This process continues along the tree to the root, where hashes representing all the data in the tree are stored. The hashes of transactions claimed to be stored in the tree can be quickly verified by determining whether they are consistent with the tree's structure.

[0018] A blockchain system comprises a network of computing nodes that manage, update, and maintain one or more blockchains. This network can be a public blockchain network, a private blockchain network, or a consortium blockchain network. For example, many entities, such as hundreds, thousands, or even millions, can operate in a public blockchain network, and each entity operates at least one node in the public blockchain network. Therefore, a public blockchain network can be considered a public network concerning the participating entities. Sometimes, a majority of entities (nodes) must sign each block for it to be valid and added to the blockchain of the blockchain network. Exemplary public blockchain networks include specific peer-to-peer payment networks that utilize a distributed ledger called a blockchain.

[0019] Typically, public blockchain networks support public transactions. Public transactions are shared by all nodes within the public blockchain network and stored in the global blockchain. The global blockchain is a blockchain replicated across all nodes, and all nodes are in a state of full consensus relative to the global blockchain. To achieve consensus (e.g., agreeing to add a block to the blockchain), consensus protocols are implemented in public blockchain networks. Examples of consensus protocols include Proof-of-Work (PoW) (e.g., implemented in some cryptocurrency networks), Proof-of-Stake (PoS), and Proof-of-Authority (PoA).

[0020] Typically, a private blockchain network can be provided for a specific entity, which centrally controls read and write permissions. This entity controls which nodes can participate in the blockchain network. Therefore, private blockchain networks are often referred to as permissioned networks, which restrict who is allowed to participate in the network and their level of participation (e.g., only in certain transactions). Various types of access control mechanisms can be used (e.g., existing participants vote to add new entities, and the governing body can control access).

[0021] Typically, consortium blockchain networks are private among the participating entities. In a consortium blockchain network, consensus processing is controlled by a set of authorized nodes, one or more of which are operated by their respective entities (e.g., financial institutions, insurance companies). For example, a consortium of ten (10) entities (e.g., financial institutions, insurance companies) can operate a consortium blockchain network, with each entity operating at least one node within the network. Therefore, a consortium blockchain network can be considered a private network associated with the participating entities. In some examples, each entity (node) must sign each block for the block to be valid and added to the blockchain. In some examples, at least a subset of the entities (nodes) (e.g., at least seven entities) must sign each block for the block to be valid and added to the blockchain.

[0022] Figure 1 A schematic diagram of a blockchain system 100 according to an embodiment is shown. (Reference) Figure 1 The blockchain system 100 may include multiple nodes, such as nodes 102-110, configured to operate on blockchain 120. Nodes 102-110 may form a network 112, such as a peer-to-peer (P2P) network. Each of nodes 102-110 may be a computing device, such as a computer or computer system, configured to store a copy of blockchain 120, or software, such as processing or an application, running on the computing device. Each of nodes 102-110 may have a unique identifier.

[0023] Blockchain 120 can include, for example Figure 1 A growing list of records in the form of blocks B1-B5. Each of blocks B1-B5 may include a timestamp, the cryptographic hash of the previous block, and the data of the current block, which could be transactions such as currency transactions. For example, ... Figure 1 As shown, block B5 may include a timestamp, the cryptographic hash of block B4, and the transaction data of block B5. Furthermore, for example, a hash operation can be performed on the previous block to generate the cryptographic hash of the previous block. Hash operations can convert inputs of various lengths into fixed-length cryptographic outputs using hash algorithms such as SHA-256.

[0024] Nodes 102-110 can be configured to perform operations on blockchain 120. For example, when a node (e.g., node 102) wants to store new data on blockchain 120, it can generate a new block to be added to blockchain 120 and broadcast this new block to other nodes in network 112, such as nodes 104-110. Based on the validity of the new block, such as the validity of its signature and transactions, other nodes can determine to accept the new block, allowing node 102 and other nodes to add the new block to their respective copies of blockchain 120. As this process is repeated, more and more data blocks can be added to blockchain 120.

[0025] Figure 2 An example of implementing a node (e.g., node 102) in a blockchain system is shown according to an embodiment. Figure 1 A schematic diagram of the computing device 200. (See reference) Figure 2 The computing device 200 may include a communication interface 202, a processor 204, and a memory 206.

[0026] Communication interface 202 facilitates communication between computing device 200 and other nodes in the network (e.g., nodes 104-110). Figure 1 Communication between devices. In some embodiments, communication interface 202 is configured to support one or more communication standards, such as Internet standards or protocols, Integrated Services Digital Network (ISDN) standards, etc. In some embodiments, communication interface 202 may include one or more of the following: Local Area Network (LAN) card, cable modem, satellite modem, data bus, cable, wireless communication channel, radio-based communication channel, cellular communication channel, Internet Protocol (IP) based communication device, or other communication device for wired and / or wireless communication. In some embodiments, communication interface 202 may be based on public cloud infrastructure, private cloud infrastructure, or hybrid public / private cloud infrastructure.

[0027] Processor 204 may include one or more dedicated processing units, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or various other types of processors or processing units. Processor 204 is coupled to memory 206 and configured to execute instructions stored in memory 206.

[0028] Memory 206 may store processor-executable instructions and such as blockchain 120 ( Figure 1The memory 206 may include any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, or magnetic disk or optical disk. When instructions in memory 206 are executed by processor 204, computing device 200 can perform operations on blockchain 120.

[0029] Users of a blockchain system (such as blockchain system 100) can use blockchain system 100 to record various types of information. For example, in some embodiments, users can use blockchain system 100 to record data content such as documents and files. Users can also use blockchain system 100 to record information that can be used to verify the integrity of the recorded data content.

[0030] Figures 3A-3C A flowchart of a method 300 for verifying data integrity according to an embodiment is shown together. For illustrative purposes, Figures 3A-3C The text describes, for example, Blockchain 120 (…). Figure 1 Blockchain. Blockchain can be implemented to support various types of users or parties, including individuals, businesses, banks, financial institutions, and other types of companies and organizations. For illustrative purposes, Figures 3A-3C The text describes a user, referred to as a User. In some embodiments, the User can utilize an application running on a computing device (on...). Figures 3A-3C In this context, the interaction between the user application (referred to as "User Application") and the blockchain is described.

[0031] In step 302, the user application can generate a random number sequence s. As will be described in detail below, this random number sequence s can be used to help verify data integrity. In step 304, the user application can generate a commitment value for the random number sequence s. In some embodiments, the user application can compute the commitment value based on a commitment scheme. In some embodiments, the commitment scheme can include cryptographic primitives that allow the user application to make a commitment to s while keeping s hidden from other users. In some embodiments, the commitment scheme used can be a Pedersen commitment scheme, such as the one disclosed by Torben Pryds Pedersen in "Secure and Verifiable Secret Sharing in Non-Interactive Information Theory," see Lecture Notes in Computer Science, Advances in Cryptography—CRYPTO91 Proceedings, Vol. 576, pp. 129-140, 1991, which is incorporated herein by reference in its entirety. For illustrative purposes, the commitment value of s can be represented as comm(s,r), where r is the random number used to generate the commitment value.

[0032] In step 306, the user application can submit a commitment value comm(s,r) to the blockchain for recording. In step 308, the blockchain can record the commitment value comm(s,r). This way, if a malicious party or user attempts to change the random number sequence s, the change can be detected.

[0033] In step 310, the user can provide or specify data content that they want to record on the blockchain. For illustrative purposes, data content can be represented as "content," and it can be provided or specified in various ways. For example, a user can identify existing data content (e.g., a file already existing on a computing device) and request the user application to retrieve the identified data content. In another example, a user can create data content (e.g., using a user application or other application), and the user application can receive the data content at or shortly thereafter when it is created. In some embodiments, data content may include one or more documents. Alternatively or additionally, data content may include other file types, including, for example, voice recordings, chatbot conversations, and other types of audio / video files.

[0034] In step 312, the user application can create an original data clip based on the data content `content` and the random number sequence `s`. In some embodiments, the user application can create the data clip by extracting multiple data points from the data content `content` according to the random number sequence `s`. For example, as... Figure 4As shown, if the data content includes voice recordings and the random number sequence s is [9,3,6,3,7], the user application can create the data clip by extracting the first data from the 9th position in the content (e.g., 9 seconds after the start of the voice recording), where 9 is the first number in s. The user application can then advance the extraction position by 3 (3 being the next number in s) and extract the second data from the 12th position in the content. Figure 4 As shown, the user application can continue to advance the extraction position based on the next number in s and extract other data from the content. The user application can concatenate multiple extracted data to form a data clip.

[0035] It should be understood that the above extraction process is presented as an example only and is not intended to be limiting. It should also be understood that similar techniques can be applied to other types of data content, including documents. In this way, user applications can create data clips to include multiple randomly selected data items from the data content, effectively binding the data clip to the data content. Binding the data clip to the data content can be beneficial because a malicious party may be unable to create or forge the data clip without knowing the data content. Binding the data clip to the data content also prevents a malicious party from bypassing step 312 by reusing another data clip created for another data content.

[0036] refer to Figure 3BIn step 314, the user application can obtain the public key of the verifier, which may be, for example, a smart contract executing on the blockchain or another user. In some embodiments, the user application can obtain the public key from the blockchain, thus eliminating the need for the user application to store any keys locally. In some embodiments, the verifier may be another user capable of verifying the integrity of the data content. Alternatively, in some embodiments, the verifier may include one or more smart contracts executing on the blockchain. A smart contract is a computer protocol implemented in the form of computer code that is incorporated into the blockchain to facilitate, verify, or enforce the negotiation or performance of agreed terms or conditions. For example, a blockchain user may use programming languages ​​such as C++, Java, Solidity, Python, etc., to program agreed terms into a smart contract, and the smart contract may automatically execute on the blockchain when the terms are met, such as executing a transaction. As another example, a smart contract may include multiple subroutines or functions, each of which may be a series of program instructions that perform a specific task. A smart contract may be operational code that executes without any human interaction, either fully or partially. In step 316, the user application can encrypt the data clip using the verifier's public key. For illustrative purposes, this encrypted data fragment can be represented as En(clip,PK) Verifier ).

[0037] In step 318, the user application may receive a signature sig from the user. In some embodiments, receiving a signature sig from the user may indicate that the user has signed the data content. In some embodiments, the signature sig may include a digital signature generated using an encryption key. In some embodiments, the signature sig may include a voice signature, which allows the user to sign the data content by stating a personal identification number (PIN), as disclosed in U.S. Patent No. 7,606,768, “Voice Signature With Strong Binding,” the entire contents of which are incorporated herein by reference. It is conceivable that in certain situations, including, for example, collecting data through chatbot conversations, the use of voice signatures may be necessary. Some users may also prefer voice signatures because they do not require the private key typically needed to generate and protect their digital signatures.

[0038] In step 320, the user application can encrypt the data fragment En(clip,PK) Verifier The signature sig is appended to the data content to create the appended data D = content + En(clip, PK). VerifierIn step 322, the user application can calculate the hash value H = hash(D) of the additional data. In step 324, the user application can encrypt the hash value using a random number sequence s. For illustrative purposes, the encrypted hash value can be represented as EH = En(H,s).

[0039] In step 326, the user application can submit data content (content) and encrypted data fragment En(clip, PKV). erifier The user application submits the plaintext value of data content (content) and the signature (sig) to the blockchain for recording. In some embodiments, the user application may submit the plaintext value of data content (content) and the signature (sig) to the blockchain. In some embodiments, the user application may encrypt the data content (content) and / or the signature (sig) before submitting them to the blockchain. In step 328, the blockchain may record the data submitted by the user application, including the data content (content), the encrypted data fragment En(clip, PK), and the signature (sig). Verifier ), signature sig and cryptographic hash value EH.

[0040] refer to Figure 3C In step 330, a validator (e.g., a smart contract executed on the blockchain or another user) can retrieve data submitted by the user application from the blockchain. In some embodiments, the retrieved data may include data content (content), encrypted data fragments (En(clip, PK)). Verifier ), signature sig and cryptographic hash value EH.

[0041] In step 332, the verifier can use their private key to decrypt the encrypted data fragment En(clip, PK). Verifier The data clip is obtained. In step 334, the verifier can parse the data clip according to the data content to recover the random number sequence s. For illustrative purposes, the recovered random number sequence can be represented as s′, and if the recovery is successful, the recovered random number sequence s′ should be equal to s. For example, as Figure 4 As shown, the verifier can parse the data clip based on the data content and determine the position of each extracted data point. The verifier can then reconstruct the random number sequence s′ based on the determined positions. However, if the data clip is forged, the verifier may be unable to reconstruct the random number sequence.

[0042] In some embodiments, in step 336, the validator may submit the recovered random number sequence s′ to the blockchain for recording. In some embodiments, the validator may append the recovered random number sequence s′ to the data obtained from the blockchain in step 330 and submit the appended data to the blockchain for recording. Submitting the recovered random number sequence s′ to the blockchain for recording makes the recovered random number sequence s′ published, and in some embodiments, method 300 may prohibit the reuse of any published random number sequence to improve security.

[0043] Furthermore, in some embodiments, the validator can verify the correctness of the recovered random number sequence s′ based on the commitment value comm(s, r) recorded on the blockchain (in step 308). For example, in some embodiments, the user application can release a random number r for generating the commitment value comm(s, r), which allows the validator to use the random number r to calculate the commitment value of the recovered random number sequence s′ and determine whether it matches the commitment value comm(s, r) recorded on the blockchain (in step 308). If the two commitment values ​​do not match, the validator can refuse further processing because the mismatch indicates that the validator did not correctly recover the random number sequence s′ (e.g., because the data fragment clip is forged) or that the random number sequence s was modified after the commitment value comm(s, r) was recorded on the blockchain (in step 308) (e.g., unintentionally or intentionally by a user or a malicious party). On the other hand, if the commitment value of the recovered random number sequence s′ matches the commitment value comm(s, r) recorded on the blockchain, the verification process can continue.

[0044] In step 338, the validator can, based on the data content obtained from the blockchain and the encrypted data fragment En(clip, PK), Verifier The verifier calculates the hash value H′ using the signature sig and the hash value H′. For example, the verifier can calculate the hash value H′ = hash(content + En(clip, PK)). VerifierIn step 340, the verifier can encrypt the hash value H′ using the recovered random number sequence s′. For illustrative purposes, the encrypted hash value H′ can be represented as EH′ = En(H′, s′), and the encrypted hash value should be equal to EH obtained from the blockchain. If EH′ ≠ EH, the verifier can determine that the integrity of the data content and / or the authenticity of the signature sig has been compromised. That is, if the data content and / or signature sig recorded on the blockchain are different from the data content and / or signature used by the user to calculate EH (e.g., if a malicious party alters the data content or forges the signature sig recorded on the blockchain), this difference can be identified because EH′ ≠ EH. In this case, the verifier can refuse to accept the data content and the signature sig. Otherwise, if EH′ = EH, the verifier can accept the data content and the signature sig.

[0045] In some embodiments, in step 342, the verifier may perform one or more additional verifications. For example, if the data content includes a voice recording and the signature sig includes a voice signature, the verifier may utilize a voice analyzer, including, for example, an AI-based voice analyzer, to compare the voice contained in the data content with the voice contained in the signature sig to determine the authenticity of the signature sig (e.g., to determine whether the content and sig were spoken by the same person). In another example, if the signature sig is a digital signature, the verifier may use an appropriate verification algorithm to verify the authenticity of the digital signature. In some embodiments, if the data content and signature sig pass verification steps 340 and 342, the verifier may accept the data content and signature sig. In this way, method 300 can provide a mechanism for the blockchain to determine the integrity of the received data content. In some embodiments, if the integrity of the data content is not verified, the blockchain may refuse to record the data content.

[0046] Figure 5 A flowchart of a method 500 for verifying data integrity according to an embodiment is shown. Method 500 can be executed by one or more nodes in a blockchain system, for example, blockchain system 100 (…). Figure 1 Nodes 102-110 in blockchain system 100. Nodes 102-110 in blockchain system 100 can, for example, in blockchain 120 ( Figure 1 Operations are performed on the blockchain. Blockchain 120 can be implemented as the blockchain in the example above.

[0047] In step 502, for example, node 102 can obtain the data content, encrypted data fragments, signature, and cryptographic hash value recorded on the blockchain. The data content, encrypted data fragments, signature, and cryptographic hash value can be obtained by a user (e.g., user (…)). Figure 3B Step 326) is recorded on the blockchain, and node 102 can obtain the recorded data to verify the integrity of the data content and the authenticity of the signature.

[0048] In step 504, node 102 can decrypt the encrypted data fragment to generate a decrypted data fragment. As mentioned above, the user who recorded the encrypted data fragment on the blockchain may have already encrypted the data fragment using node 102's public key, allowing node 102 to decrypt the encrypted data fragment using its corresponding private key.

[0049] In step 506, node 102 can parse the decrypted data fragment according to the data content to recover the random number sequence used to create the original data fragment. (See above reference...) Figure 4 As described, in some embodiments, node 102 can parse the decrypted data fragment based on the data content to determine the positions of the data extracted to create the original data fragment. Node 102 can then recover the random number sequence based on the determined positions. In some embodiments, the blockchain can record a commitment value for the random number sequence used to create the original data fragment. In such embodiments, as described above, node 102 can determine whether the recovered random number sequence is correct based on the commitment value recorded on the blockchain.

[0050] In step 508, node 102 can calculate a hash value based on the data content, encrypted data fragments, and signature. In step 510, node 102 can encrypt the hash value using a recovered random number sequence, and in some embodiments, node 102 can record the recovered random number sequence on the blockchain to prevent it from being reused to encrypt the hash value. As mentioned above, the hash value encrypted using the recovered random number sequence should match the encrypted hash value recorded on the blockchain. Therefore, in step 512, node 102 can determine the integrity of the data content by comparing the hash value encrypted using the recovered random number sequence with the encrypted hash value recorded on the blockchain. In some embodiments, if the hash value encrypted using the recovered random number sequence matches the encrypted hash value recorded on the blockchain, node 102 can accept the integrity of the data content. Otherwise, if the hash value encrypted using the recovered random number sequence does not match the encrypted hash value recorded on the blockchain, node 102 can refuse to accept the integrity of the data content.

[0051] In some embodiments, node 102 may further determine the authenticity of the signature. For example, if the data content includes a voice recording and the signature includes a voice signature, node 102 may compare the voice contained in the data content with the voice contained in the signature to determine the authenticity of the voice signature. In another example, if the signature is a digital signature, node 102 may use an appropriate verification algorithm to verify the authenticity of the digital signature. In some embodiments, if the signature is authentic, node 102 may accept the integrity of the data content. Otherwise, node 102 may reject the integrity of the data content.

[0052] Figure 6 This is a block diagram of an apparatus 600 for verifying data integrity according to an embodiment. Apparatus 600 may be a software processing implementation and may correspond to method 500. Figure 5 ). refer to Figure 6 The device 600 may include a processing module 602, an encryption / decryption module 604, and a determination module 606.

[0053] Processing module 602 can acquire data content, encrypted data fragments, signatures, and cryptographic hash values ​​recorded on the blockchain, and provide the acquired data to encryption / decryption module 604. Encryption / decryption module 604 can decrypt the encrypted data fragments to generate decrypted data fragments. Processing module 602 can then parse the decrypted data fragments according to the data content to recover the random number sequence used to create the original data fragments. Processing module 602 can also calculate a hash value based on the data content, encrypted data fragments, and signature, and provide the hash value to encryption / decryption module 604. Encryption / decryption module 604 can encrypt the hash value using the recovered random number sequence and provide the hash value encrypted using the recovered random number sequence to determination module 606. As described above, determination module 606 can determine the integrity of the data content by comparing the hash value encrypted using the recovered random number sequence with the cryptographic hash value recorded on the blockchain.

[0054] Each of the above modules can be implemented as software, hardware, or a combination of software and hardware. For example, each of the above modules can be implemented using a processor to execute instructions stored in memory. Furthermore, each of the above modules can be implemented using one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the described methods. Further, for example, each of the above modules can be implemented using a computer chip or entity, or by using a product with specific functionality. In one embodiment, device 600 can be a computer, and the computer can be a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email transceiver, game console, tablet computer, wearable device, or any combination of these devices.

[0055] For the implementation process of the function and role of each module in device 600, please refer to the corresponding steps in the above method. For simplicity, details are omitted here.

[0056] In some embodiments, a computer program product may include a non-transitory computer-readable storage medium having stored computer-readable program instructions thereon for causing a processor to perform the methods described above.

[0057] Computer-readable storage media can be tangible devices that store instructions for use by an instruction execution device. Such computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punched cards or raised structures with instructions recorded thereon, and any suitable combination thereof.

[0058] The computer-readable program instructions used to perform the above methods can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​and traditional procedural programming languages. The computer-readable program instructions can be executed entirely as a standalone software package on the computing device, or partially on the first computing device and partially on a second computing device located remotely from the first computing device. In the latter case, the second remote computing device can be connected to the first computing device via any type of network, including a local area network (LAN) or a wide area network (WAN).

[0059] Computer-readable program instructions may be provided to a processor of a general-purpose or special-purpose computer or other programmable data processing apparatus to produce a machine, such that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, create a mechanism for carrying out the methods described above.

[0060] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this document. In this regard, the boxes in the flowcharts or block diagrams may represent segments or portions of software programs or code, which include one or more executable instructions for implementing a particular function. It should also be noted that in some alternative embodiments, the functions mentioned in the boxes may not occur in the order shown in the figures. For example, two boxes shown consecutively may actually be executed substantially simultaneously, or these boxes may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each box in the figures and / or flowcharts, as well as combinations of boxes in the figures and flowcharts, may be implemented by a hardware-based system for a special purpose performing a specified function or action, or by a combination of special-purpose hardware and computer instructions.

[0061] It should be understood that, for clarity, certain features of this disclosure described in the context of different embodiments may also be provided in combination in a single embodiment. Conversely, for brevity, various features of this disclosure described in the context of a single embodiment may also be provided individually or in any suitable sub-combination, or suitably provided in any other described embodiment of this disclosure. Unless otherwise stated, certain features described in the context of various embodiments are not essential features of those embodiments.

[0062] Although this disclosure has been described in conjunction with specific embodiments, many substitutions, modifications, and variations will be apparent to those skilled in the art. Therefore, the following claims encompass all such substitutions, modifications, and variations that fall within the scope of the claims.

Claims

1. A computer-implemented method for verifying data integrity, the method comprising: Retrieve data content, encrypted data fragments, signatures, and cryptographic hash values ​​recorded on the blockchain; Decrypt the encrypted data segment to generate a decrypted data segment; The decrypted data segment is parsed according to the data content, and the position of each data item in the decrypted data segment in the data content is determined. Based on the determined position, a random number sequence is recovered to create the original data segment corresponding to the encrypted data segment. Calculate the hash value based on the data content, the encrypted data fragment, and the signature; The hash value is encrypted using the recovered random number sequence; The integrity of the data content is determined by comparing the hash value encrypted using the recovered random number sequence with the cryptographic hash value recorded on the blockchain.

2. The method according to claim 1, further comprising: In response to determining that the hash value encrypted using the recovered random number sequence matches the cryptographic hash value recorded on the blockchain, the integrity of the data content is accepted.

3. The method according to claim 1 or 2, further comprising: In response to the determination that the hash value encrypted using the recovered random number sequence does not match the cryptographic hash value recorded on the blockchain, the integrity of the data content is rejected.

4. The method according to claim 1 or 2, further comprising: Determine the authenticity of the signature; In response to determining that the signature is authentic, the integrity of the data content is accepted.

5. The method according to claim 4, further comprising: In response to the determination that the signature is not authentic, the integrity of the data content is rejected.

6. The method according to claim 1 or 2, further comprising: The recovered random number sequence is recorded on the blockchain to prevent it from being used again to encrypt the hash value.

7. The method according to claim 1 or 2, wherein, The original data fragment is created by extracting multiple data points from the data content according to the random number sequence, and the position of each data point in the data content is determined by the corresponding number in the random number sequence.

8. The method according to claim 1 or 2, further comprising: Record the commitment value of the random number sequence used to create the original data fragment on the blockchain; Based on the commitment value recorded on the blockchain, it is determined whether the recovered random number sequence is correct.

9. The method according to claim 1 or 2, wherein, The data content includes voice recordings.

10. The method according to claim 1 or 2, wherein, The signature includes a voice signature.

11. An apparatus for verifying data integrity, comprising: One or more processors; One or more computer-readable storage devices are coupled to the one or more processors and have instructions stored thereon that can be executed by the one or more processors to perform the method as described in any one of claims 1 to 10.

12. An apparatus for verifying data integrity, the apparatus comprising a plurality of modules for performing the method of any one of claims 1 to 10.

13. A non-transitory computer-readable medium storing instructions that, when executed by a processor of a device, cause the device to perform the method of any one of claims 1 to 10.

Images