Fixed data processing

Abstract

Immutable data processing of a file by an ingestor includes receiving the file and processing the file by slicing the file into a number of parts, computing a digest for each part until all digests for the number of parts have been computed, computing a master hash as a combination of all of the digests for the number of parts, computing a master hash signature using the master hash and a private key of the ingestor, forming immutable data including a set of digests including all of the digests for the number of parts, the master hash, the master hash signature, and the public key of the ingestor, transmitting the immutable data to a verifier, and storing immutable metadata including the master hash, the master hash signature, the public key of the ingestor, and an identifier for the file in a trusted database.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE

[0001] This disclosure relates to immutable data, and more particularly, to using immutable data to verify that a received file is a pristine copy of the same ingested file. [Background technology]

[0002]

[0002] Immutability aims to show that a stored file has not been modified, either involuntarily or voluntarily. Intentional modification corresponds to an attacker changing at least one bit of the file. Therefore, a suitable solution for immutability should provide reliable proof that a file has not been modified and must detect all non-malicious modifications, malicious modifications by outsiders, and malicious modifications by untrusted insiders. Trusted insiders are entities that are authorized to modify files.

[0003]

[0003] Current solutions calculate a hash or cryptographic hash for a complete file and store the corresponding hash in a database. However, using a hash for a large monolithic file is not efficient when the stored file is large. Furthermore, hashing a large file is not compatible with modern cloud infrastructures that support multipart uploads and downloads (at the storage level, different parts of a file are uploaded and recombined simultaneously). Therefore, using current solutions, an attacker can upload his counterfeit file and register it in a trusted database (or distributed ledger). Summary of the Invention [Problem to be solved by the invention]

[0004]

[0004] The present disclosure provides for verifying that a received file is a pristine copy of the same file that was prepared by an ingester. [Means for solving the problem]

[0005]

[0005] In one implementation, a method for immutable data processing of a file by an ingestor is disclosed, the method including receiving the file and processing the file by slicing the file into a number of parts, computing a digest for each part until all digests for the number of parts have been computed, computing a master hash as a combination of all the digests for the number of parts, computing a master hash signature using the master hash and a private key of the ingestor, forming a set of digests including all the digests for the number of parts, immutable data including the master hash, the master hash signature, and a public key of the ingestor, transmitting the immutable data to a verifier, and storing immutable metadata including the master hash, the master hash signature, the public key of the ingestor, and an identifier for the file in a trusted database.

[0006]

[0006] In one implementation, the method further includes a first comparison step of comparing the master hash in the immutable data with a combination of the hashes of each part, a second comparison step of comparing the master hash signature in the immutable data with a digital signature of the master hash calculated using the public key, a third comparison step of comparing the hash of each part with each digest in the set of digests, and declaring the file untouched and uncorrupted when all three comparisons produce a true result. In one implementation, the method further includes a step of requesting verification that the master hash signature of the immutable metadata stored in the trusted database matches the master hash signature in the immutable data. In one implementation, the first comparison step includes: TIFF2024509486000002.tif6150 is true, where MH is the master hash and HR i is the digest of the i-th part stored in the trusted database. In one implementation, the second comparison step comprises: determining whether TIFF2024509486000003.tif6150 is true; pub is the public key provided by the immutable data, and Versign is the verification of the digital signature. In one implementation, the third comparison step comprises: determining whether TIFF2024509486000004.tif6150 is true; i is the digest of each part, and HR i is the digest of the ith part stored in the trusted database. In one implementation, the digest of each part is calculated as follows: TIFF2024509486000005.tif6150 where hash() is a hash function. In one implementation, the master hash is calculated as follows: TIFF2024509486000006.tif6150, where hash1() is a hash function and the symbol | represents the concatenation of the two parts. In one implementation, the master hash signature is calculated as follows: TIFF2024509486000007.tif6150 where K pri where x is the private key of the ingester and Sign is a digital signature. In one implementation, the method further includes sending a query to the trusted database to determine whether the master hash signature in the immutable data matches the master hash signature in the immutable metadata. In one implementation, the trusted database is a blockchain.

[0007]

[0007] In another implementation, an immutable data system is disclosed that includes an ingestor including a public key and a private key, the ingestor for receiving a file and processing the file by slicing the file into a plurality of portions, the ingestor generating immutable data including: (a) a set of digests of the plurality of portions, where the digest of each portion is computed as a hash of each portion, (b) a master hash computed as a combination of the set of digests, (c) a master hash signature computed using the master hash and the private key, and (d) the public key of the ingestor; and a trusted database for storing immutable metadata including the master hash, the master hash signature, the public key, and an identifier for the file.

[0008]

[0008] In one implementation, the system further includes a verifier for receiving the file and verifying that the file is intact by (a) comparing the master hash in the immutable data with a combination of the hashes of each part, (b) comparing the master hash signature in the immutable data with a digital signature of the master hash calculated using the public key, and (c) comparing the hash of each part with the digest of each part, where the file is declared intact and uncorrupted when all three comparisons produce a true result. In one implementation, the verifier verifies that the master hash signature in the immutable data matches the master hash signature of the immutable metadata stored in the trusted database, where the trusted database is a blockchain.

[0009]

[0009] In another implementation, a method is disclosed for verifying that a file is an intact copy of the same file prepared by an ingestor, the method including the steps of receiving a plurality of portions of the file, receiving immutable data including a set of digests of the plurality of portions, a master hash, a master hash signature, and a public key of the ingestor, a first comparison step of comparing the master hash in the immutable data with a combination of the hashes of each portion, a second comparison step of comparing the master hash signature in the immutable data with a digital signature of the master hash calculated using the public key of the ingestor, a third comparison step of comparing the hash of each portion with each digest, and declaring the file intact and uncorrupted when all three comparisons produce true results.

[0010] In one implementation, the portions of the file are generated by slicing the file into portions. In one implementation, each digest in the set of digests is calculated as a hash of each portion. In one implementation, the master hash is calculated as a combination of the set of digests. In one implementation, the master hash is calculated as follows: TIFF2024509486000008.tif6150, where hash1() is a hash function and the symbol | represents the concatenation of the two parts. In one implementation, the master hash signature is calculated using the master hash and the ingestor's private key. In one implementation, the master hash signature is calculated as follows: TIFF2024509486000009.tif6150 where K pri is the private key of the ingester, and Sign is a digital signature.

[0011]

[0011] Other features and advantages will become apparent from the present specification, which illustrates by way of example embodiments of the present disclosure.

[0012]

[0012] Details of the present disclosure, both as to its structure and operation, can be gleaned in part by studying the accompanying drawings, in which like parts are designated with like reference numerals. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram of an immutable data system according to one implementation of the present disclosure. [Figure 2A] FIG. 1 illustrates immutable data processing according to one implementation of the present disclosure. [Figure 2B] FIG. 2 illustrates trusted rooted fixity processing according to one implementation of the present disclosure. [Figure 3A] 1 is a flow diagram of a method for immutable data processing according to one implementation of the present disclosure. [Figure 3B] FIG. 2 is a flow diagram of a method for verifying that a file is a pristine copy of the same file prepared by an ingestor, according to one implementation of the present disclosure. [Figure 4A] FIG. 1 is a diagram of a computer system and a user according to an implementation of the present disclosure. [Figure 4B] FIG. 1 is a functional block diagram illustrating a computer system hosting an immutable data processing application in accordance with an implementation of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014]

[0020] As mentioned above, current solutions to the immutability problem compute a hash or cryptographic hash for a complete file and store the corresponding hash in a database. In some cases, the database is a blockchain. The use of a blockchain enforces the immutability of the stored hash. However, using a hash for a large monolithic file is inefficient when the stored file is large and may be subject to file forgery by an attacker. For example, in cloud infrastructures that support multipart upload and download, different parts of a file are uploaded and recombined simultaneously at the storage level. Thus, in this infrastructure, an attacker can upload his forged file and register it in the trusted database.

[0015]

[0021] Certain implementations of the present disclosure include a verification process to verify that the file is pristine (i.e., the received file is a pristine copy of the same file prepared by the Ingestor). After reading the following description, it will be clear how to implement the present disclosure in various implementations and applications. Although various implementations of the present disclosure are described herein, it should be understood that these implementations are presented by way of example only, and not by way of limitation. Thus, detailed descriptions of various implementations should not be construed as limiting the scope or breadth of the present disclosure.

[0016]

[0022] FIGURE 1 is a block diagram of an immutable data system 100 according to one implementation of the present disclosure. In the implementation shown in FIGURE 1, the immutable data system 100 includes an ingester 110, a verifier 120, and a trusted database 130. The ingester 110 includes a private key 116 and a public key 118. The ingester 110 receives files 102 and processes the files 102 to create immutable data 112 and a subset of information called immutable metadata 114. In one implementation, the trusted database 130 is a blockchain.

[0017]

[0023] In one implementation, the ingester 110 splits the file 102 into multiple parts. Process the file 102 by slicing it into TIFF2024509486000010.tif6150. In the above formula, each part (P x ) can have different lengths. The injector 110 then calculates the length of each portion P x Digest of (H i ) to calculate TIFF2024509486000011.tif6170Here, hash() is the hash function.

[0018]

[0024] Once the ingestor 110 has calculated all the digests, it calculates a master hash (MH) as follows: TIFF2024509486000012.tif6170Here, hash1() is the hash function and the symbol | represents the concatenation of the two parts.

[0019]

[0025] After the master hash (MH) is calculated, the ingestor 110 calculates the master hash signature (SMH) as follows: TIFF2024509486000013.tif6170 where K pri is the private key and Sign is the digital signature.

[0020]

[0026] In one implementation, the Ingestor 110 receives a set of digests, a Master Hash (MH), a Master Hash Signature (SMH), and a public key 118 (i.e., The ingester 110 generates immutable data 112 as a filename (e.g., TIFF2024509486000014.tif7150) for the file 102. The ingester 110 stores the master hash (MH), the master hash signature (SMH), the public key 118, and the identification of the file 102 as immutable metadata 114 in a trusted database 130.

[0021]

[0027] 2A is a diagram illustrating immutable data processing 200 according to one implementation of the present disclosure. In one implementation, the immutable data processing 200 includes processing a file 102 and immutable data 112. i To verify that the is intact, the following checks are performed (eg, by verifier 120): (a) Check if TIFF2024509486000015.tif6150 is true. In the above equation, MH 210 is the master hash. (b) Check if TIFF2024509486000016.tif6150 is true. In the above formula, K pub is the public key provided by the immutable data, and Versign is the verification of the digital signature. (c) Check if TIFF2024509486000017.tif6150 is true. In the above formula, H i is the partial digest H as defined by formula [1]. i It is.

[0022]

[0028] If all three checks (a), (b) and (c) performed by the verifier 120 are passed, the verification is successful.

[0023]

[0029] In one implementation, the verifier 120 also sends a query to the trusted database 130 as to whether the master hash signature (SMH) 220 matches the SMH stored in the trusted database 130. The trusted database 130 compares the received result with the immutable metadata 114 and returns to the verifier 120 that the file 102 is untouched when the comparison is positive. By signing the master hash with a private key, the SMH is cryptographically protected from an attacker, so that the attacker cannot forge a valid signature. Thus, it is possible to verify the immutability of one part without having access to the entire file and still prove that the verified part belongs to the complete file. In one implementation, the trusted database 130 is a blockchain.

[0024]

[0030] 2B illustrates a trusted root immutable process 230 according to one implementation of the present disclosure. In one implementation, the trusted root immutable process 230 can be used when creating immutable data from a file that already has a Message Digest 5 (MD5) hash. In this implementation, the trusted root immutable process: (a) the Corresponding File represents a valid unaltered file; (b) the corresponding file is a genuine copy of the file having the given MD5; Prove that.

[0025]

[0031] Thus, the trusted root immutable process 230 links the MD5 of the legacy file to the new format. For example, the root immutable process 230 securely links the MD5 of the master on the Linear Tape-Open (LTO) to the file in the cloud. Thus, the difference between the trusted root immutable process 230 and the immutable data process 200 of Figure 2A is in the master hash signature (SMH) 260, which includes both the master hash 240 and the legacy MD5 hash 250. The following formula defines the SMH: TIFF2024509486000018.tif6170

[0026]

[0032] In one implementation, the digest function is xxhash64, the master hash digest is SHA256, and the digital signature is an RSA-2048 of the hash value. The X509 certificate encapsulates the public key. Thus, in this implementation, equations [3] and [4] are replaced by the following: TIFF2024509486000019.tif6170TIFF2024509486000020.tif6170

[0027]

[0033] Immutable data is a file that contains at least the following fields: (a) Rooted is a Boolean value that is true if the file describes a rooted fixity. (b) Parts is an array of metadata, where each metadata is a content (P i ), the first part is the first element of the array, and it contains the "size" of the part, which is the number of bytes in the part, and the 64-bit digest of the part (i.e., H i ) and (c)MasterHash is a 256-bit master hash. (d) SignClear is the master hash signature in its binary form. (e) PEMClear is the PEM-encoded public key. (f) MD5 hash is the 16-byte MD5 hash used for root immutability; this is only meaningful if Rooted is true.

[0028]

[0034] 3A is a flow diagram of a method 300 for immutable data processing according to one implementation of the present disclosure. In the implementation shown in FIG. 3A, a file 102 is received and divided into multiple portions at step 310. Process the file 102 by slicing it into TIFF2024509486000021.tif6150. In the above formula, each part (P x ) can have different lengths. In step 320, each part P x Digest of (H i ) to calculate TIFF2024509486000022.tif6150Here, hash() is the hash function.

[0029]

[0035] If in step 322 it is determined that the digests of all parts have been calculated, then in step 330 a master hash (MH) is calculated as follows: TIFF2024509486000023.tif6150

[0030]

[0036] After the master hash (MH) is calculated, in step 332, a master hash signature (SMH) is calculated as follows: TIFF2024509486000024.tif7150 where K pri is the private key and Sign is the digital signature.

[0031]

[0037] In one implementation, in step 334, the set of digests, the master hash (MH), the master hash signature (SMH), and the public key 118 (i.e., The immutable data 112 is generated as a file name (e.g., .TIFF2024509486000025.tif7150) for the verifier 120. The generated immutable data 112 is sent to the verifier 120 for verification. Furthermore, in step 336, the immutable metadata 114 is stored in the trusted database 130 as the master hash (MH), the master hash signature (SMH), the public key 118, and the identification of the file 102. In one implementation, the trusted database 130 is a blockchain.

[0032]

[0038] In one implementation, a method 300 for immutable data processing includes a portion P i The following checks are performed, including a verification process to verify that the (at step 340) Check whether TIFF2024509486000026.tif6150 is true. In the above equation, MH 210 is the master hash. (at step 342) Check if TIFF2024509486000027.tif6150 is true. In the above formula, K pub is the public key provided by the immutable data, and Versign is the verification of the digital signature. (at step 344) Check whether TIFF2024509486000028.tif6150 is true. In the above formula, H i is the partial digest H as defined by formula [1]. i It is.

[0033]

[0039] If step 346 determines that all three checks performed in steps 340, 342 and 344 are passed, then the verification is successful.

[0034]

[0040] In one implementation, in step 350, a query is sent to the trusted database 130 to determine whether the master hash signature (SMH) 220 matches the SMH stored in the trusted database 130. In step 352, the received result is compared to the immutable metadata 114, and in step 354, when the comparison is positive, the file 102 is determined to be untouched. By signing the master hash with a private key, the SMH is cryptographically protected from an attacker, so that the attacker cannot forge a valid signature. Thus, it is possible to verify the immutability of a portion without having access to the entire file, and still prove that the verified portion belongs to the complete file. In one implementation, the trusted database 130 is a blockchain.

[0035]

[0041] FIG. 3B is a flow diagram of a method 360 for verifying that a file is an intact copy of the same file prepared by an ingestor, according to one implementation of the present disclosure. In the implementation shown in FIG. 3B, the method includes receiving a plurality of portions of a file in step 362. In step 364, immutable data is received that includes a set of digests of the plurality of portions, a master hash, a master hash signature, and the ingestor's public key. In step 366, the master hash in the immutable data is compared to the combination of the hashes of each portion. Then, in step 368, the master hash signature in the immutable data is compared to a digital signature of the master hash calculated using the ingestor's public key. In step 370, the hash of each portion is compared to each digest. When all three comparisons in step 372 produce a true result, in step 380, the file is declared intact and uncorrupted. If, in step 372, all three comparisons do not produce a true result, then, in step 382, ​​the file is declared corrupted.

[0036]

[0042] Figure 4A is a diagram of a computer system 400 and a user 402 in accordance with an implementation of the present disclosure. The user 402 uses the computer system 400 to implement an application 490 for immutable data processing as shown and described with respect to the system 100 of Figure 1 and the methods 300, 360 of Figures 3A and 3B.

[0037]

[0043] The computer system 400 stores and executes the immutable data processing application 490 of Figure 4B. Additionally, the computer system 400 can be in communication with a software program 404. The software program 404 can include the software code for the immutable data processing application 490. The software program 404 can be loaded onto an external medium, such as a CD, DVD, or storage drive, as described further below.

[0038]

[0044] Additionally, computer system 400 can be connected to a network 480. Network 480 can be connected in a variety of different architectures, such as a client-server architecture, a peer-to-peer network architecture, or other types of architectures. For example, network 480 can communicate with a server 485 that coordinates engines and data used in immutable data processing application 490. Also, network 480 can be different types of networks. For example, network 480 can be the Internet, a local area network or any variation of a local area network, a wide area network, a metropolitan area network, an intranet or extranet, or a wireless network.

[0039]

[0045] 4B is a functional block diagram illustrating a computer system 400 hosting an immutable data processing application 490 according to an implementation of the present disclosure. The controller 410 is a programmable processor that controls the operation of the computer system 400 and its components. The controller 410 loads instructions (e.g., in the form of a computer program) from the memory 420 or an embedded controller memory (not shown) and executes these instructions to control the system, e.g., to provide data processing. In so doing, the controller 410 provides a software system to the immutable data processing application 490. Alternatively, this service can be implemented as a separate hardware component in the controller 410 or the computer system 400.

[0040]

[0046] The memory 420 temporarily stores data for use by other components of the computer system 400. In one implementation, the memory 420 is implemented as RAM. In one implementation, the memory 420 also includes long-term or permanent memory, such as flash memory and / or ROM.

[0041]

[0047] Storage 430 stores data temporarily or long term for use by other components of computer system 400. For example, storage 430 stores data used by persistent data processing application 490. In one implementation, storage 430 is a hard disk drive.

[0042]

[0048] Media device 440 accepts removable media and reads and / or writes data to the inserted media. In one implementation, for example, media device 440 is an optical disk drive.

[0043]

[0049] User interface 450 includes components for receiving user input from a user of computer system 400 and presenting information to user 402. In one implementation, user interface 450 includes a keyboard, a mouse, audio speakers, and a display. Controller 410 uses the input from user 402 to coordinate the operation of computer system 400.

[0044]

[0050] I / O interface 460 includes one or more I / O ports to connect to corresponding I / O devices, such as external storage or supplemental devices (e.g., a printer or PDA). In one implementation, the ports of I / O interface 460 include ports such as USB ports, PCMCIA ports, serial ports, and / or parallel ports. In another implementation, I / O interface 460 includes a wireless interface for communicating wirelessly with external devices.

[0045]

[0051] Network interface 470 includes wired and / or wireless network connections, such as an RJ-45 supporting an Ethernet connection or a "Wi-Fi" interface (including but not limited to 802.11).

[0046]

[0052] Computer system 400 includes additional hardware and software typical of a computer system (e.g., power, cooling, operating system), although these components are not specifically shown in Figure 4B for simplicity. In other implementations, different configurations of computer systems may be used (e.g., different bus or storage configurations or multi-processor configurations).

[0047]

[0053] In one implementation, system 100 is an entirely hardware system including one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable gate / logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry, hi another implementation, system 100 is a combination of hardware and software.

[0048]

[0054] The description of the disclosed implementations is provided to enable any person skilled in the art to make or use the disclosure. Numerous modifications of these implementations will be readily apparent to those skilled in the art, and the principles defined herein may be applied to other implementations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the implementations shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

[0049]

[0055] Those skilled in the art will appreciate that the various exemplary modules and method steps described herein can be implemented as electronic hardware, software, firmware, or a combination thereof. To clearly illustrate this interchangeability of hardware and software, the various exemplary modules and method steps have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in various ways for each particular application, and such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. Additionally, the grouping of functions within a module or step is for ease of description. Certain functionality may be moved from one module or step to another without departing from the present disclosure.

[0050]

[0056] Not all features of each of the above embodiments are necessarily required in a particular implementation of the present disclosure. Furthermore, it should be understood that the description and drawings presented herein are representative of the subject matter broadly intended by the present disclosure. Furthermore, it should be understood that the scope of the present disclosure fully includes other implementations that may become apparent to those skilled in the art, and therefore, the scope of the present disclosure is not limited by anything other than the scope of the appended claims. [Explanation of symbols]

[0051] 100 Immutable Data Systems 102 Files 110 Injesta 112 Immutable Data 114 Immutable Metadata 116 Private key 118 Public Key 120 Verifier 130 Trusted Databases 200 Immutable Data Processing 210MH 220 Master Hash Signature (SMH) 230 Trusted Root Immutability 240 Master Hash 250 Legacy MD5 Hashes 260 Master Hash Signature (SMH) 300 Methods for Immutable Data Processing Takes 310 files and slices them into multiple parts 320 Digest of each part (H i ) 322 Have all the digests of the parts been calculated? Calculate 330 Master Hash (MH) 332 Calculate the Master Hash Signature (SMH) 334 Generate immutable data as a set of digests, MH, SMH, and public key, and send it to the verifier 336 Store immutable metadata in a trusted database as MH, SMH, public keys, and file identities 340 Perform master hash check 342 Perform digital signature verification 344 Perform digest checks on each part 346 Did it pass all the checks? 350 Query whether the SMH of the immutable data matches the SMH in the authoritative database 352 Match? 354 files are untouched A method to verify that the file is a pristine copy of the same file that was prepared by the 360 ​​Ingestor 362 Receiving multiple parts of a file 364 Receiving Immutable Data 366 Compare the master hash with the combination of the hashes of each part 368 Compare the master hash signature with the digital signature of the master hash 370 Compare the hash of each part with each digest 372 Are all three comparisons true? 380 files are untouched 382 File is damaged 400 Computer Systems 402 users 404 Software Programs 410 Controller 420 Memory 430 Storage 440 Media Devices 450 User Interface 460 I / O Interface 470 Network Interface 480 Network 485 Server 490 Immutable Data Processing Applications

Claims

1. 1. A method for fixity data processing of files by an ingester, the method comprising: receiving the file and processing the file by slicing the file into a number of portions; calculating a digest for each of the plurality of portions until all digests for the portions have been calculated; calculating a master hash as a combination of all of the digests of the portions; calculating a master hash signature using the master hash and the ingestor's private key; forming immutable data including a set of digests including all digests of the plurality of parts, the master hash, the master hash signature, and the ingestor's public key; transmitting the immutable data to a verifier; storing immutable metadata in a trusted database, the immutable metadata including the master hash, the master hash signature, the public key of the ingestor, and an identifier for the file; The method according to claim 1, further comprising:

2. a first comparison step of comparing a combination of the hashes of each portion with the master hash in the immutable data; a second comparison step of comparing the master hash signature in the immutable data with a digital signature of the master hash calculated using the public key; a third comparison step of comparing the hash of each portion with each digest in the set of digests; declaring the file pristine and uncorrupted when all three comparisons produce a true result; The method of claim 1 further comprising:

3. requesting verification that the master hash signature of the immutable metadata stored in the trusted database matches the master hash signature in the immutable data; The method of claim 2 further comprising:

4. The first comparison step comprises: is true; Including, where MH is the master hash and HR i is the digest of the i-th part stored in the database, 3. The method according to claim 2 .

5. The second comparison step comprises: is true; Including, In the above formula, K pub is the public key provided by the immutable data, and Versign is the verification of the digital signature.

3. The method according to claim 2 .

6. The third comparison step comprises: is true; Including, In the above formula, H i is the digest of each part, and HR i is the digest of the i-th part stored in the database, 3. The method according to claim 2 .

7. The digest of each part is calculated as follows: where hash() is a hash function.

2. The method according to claim 1 .

8. The master hash is calculated as follows: where hash1() is the hash function and the symbol | represents the concatenation of two parts.

2. The method according to claim 1 .

9. The master hash signature is calculated as follows: Here, K pri is the private key of the ingester, and Sign is a digital signature.

2. The method according to claim 1 .

10. sending a query to the trusted database to determine whether the master hash signature in the immutable data matches the master hash signature in the immutable metadata; The method of claim 1 further comprising:

11. The method of claim 1 , wherein the trusted database is a blockchain.

12. 1. An immutable data system, comprising: an ingestor comprising a public key and a private key, the ingestor for receiving a file and processing the file by slicing the file into a plurality of portions; The Injesta is (a) a set of digests of the plurality of parts, each digest of a part being computed as a hash of the part; and (b) a master hash computed as a combination of the set of digests; and (c) a master hash signature calculated using the master hash and the private key; and (d) the public key of the Injester; and an ingestor that generates immutable data including a trusted database for storing immutable metadata including the master hash, the master hash signature, the public key, and an identifier for the file; A system comprising:

13. a verifier for receiving the file and verifying that the file is intact, the verification comprising: (a) comparing a combination of the hashes of each portion with the master hash in the immutable data; (b) comparing the master hash signature in the immutable data with a digital signature of the master hash calculated using the public key; (c) comparing the hash of each portion with the digest of each portion; It is carried out by When all three comparisons produce a true result, the file is declared intact and uncorrupted. The system of claim 12 further comprising:

14. the verifier verifies that the master hash signature in the immutable data matches the master hash signature of the immutable metadata stored in the trusted database; The trusted database is a blockchain.

14. The system according to claim 13, characterized in that

15. 1. A method for verifying that a file is a pristine copy of the same file as prepared by an ingestor, the method comprising: receiving a plurality of portions of the file; receiving immutable data including a set of digests of the portions, a master hash, a master hash signature, and a public key of the ingestor; a first comparison step of comparing a combination of the hashes of each portion with the master hash in the immutable data; a second comparison step of comparing the master hash signature in the immutable data with a digital signature of the master hash calculated using the public key of the ingestor; a third comparison step of comparing a hash of each part with each digest; declaring the file untouched and uncorrupted when all three comparisons produce a true result; The method according to claim 1, further comprising:

16. 16. The method of claim 15, wherein the multiple portions of the file are generated by slicing the file into portions.

17. 16. The method of claim 15, wherein each digest in the set of digests is computed as a hash of each portion.

18. 16. The method of claim 15, wherein the master hash is computed as a combination of the set of digests.

19. 16. The method of claim 15, wherein the master hash signature is calculated using the master hash and the ingestor's private key.

20. The master hash signature is calculated as follows: Here, K pri is the private key of the ingester, and Sign is a digital signature.

20. The method according to claim 19.

Images