Patent ID: 12242420

DETAILED DESCRIPTION

As described above, the current solutions for a fixity issue calculate a hash or cryptographic hash for the 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, when the stored file is large, using a hash for a large monolithic file is not efficient and may be subject to forging of the file by an attacker. For example, in a cloud infrastructure that supports multipart upload and download, different parts of the file are concurrently uploaded and recombined at the storage level. Thus, in this infrastructure, an attacker may upload its forged file and register it in the trusted database.

Certain implementations of the present disclosure include a verification process to verify that the file is pristine (i.e., that a received file is a pristine copy of the same file that an ingester prepared). After reading below descriptions, it will become apparent how to implement the disclosure in various implementations and applications. Although various implementations of the present disclosure will be described herein, it is understood that these implementations are presented by way of example only, and not limitation. As such, the detailed description of various implementations should not be construed to limit the scope or breadth of the present disclosure.

FIG.1is a block diagram of a fixity data system100in accordance with one implementation of the present disclosure. In the illustrated implementation ofFIG.1, the fixity data system100includes an ingester110, a verifier120, and a trusted database130. The ingester110includes a private key116and a public key118. The ingester110receives and processes the file102to create fixity data112and a subset of information called fixity metadata114. In one implementation, the trusted database130is a blockchain.

In one implementation, the ingester110processes the file102by slicing it102into several parts {P0, P1, . . . , Pn}, where each part (Px) may have a different length. The ingester110then calculates a digest (Hi) of each part Pxas follows:
∀iϵ{1 . . .n},Hi=hash(Pi),  [1]where hash( ) is a hash function.

Once the ingester110calculates all digests, it calculates the master hash (MH) as follows:
MH=hash1(H1| . . . |Hn),  [2]where hash1( ) is a hash function andsymbol | represents concatenating two parts.

After the master hash (MH) is calculated, the ingester110calculates the master hash signature (SMH) as follows:
SMH=Sign{Kpri}(MH),  [3]where Kpriis the private key, andSign is a digital signature.

In one implementation, the ingester110generates the fixity data112as the set of digests, master hash (MH), master hash signature (SMH), and the public key118(i.e., {{H1, H2, . . . Hn}, MH,SMH, Kpub}). The ingester110stores the master hash (MH), the master hash signature (SMH), the public key118, and the identification of the file102as the fixity metadata114in the trusted database130.

FIG.2Ais a diagram illustrating a fixity data processing200in accordance with one implementation of the present disclosure. In one implementation, the fixity data processing200includes processing the file102and the fixity data112. To verify that part Pihas not been impaired, following checks are performed (e.g., by the verifier120):(a) whether MH==hash(HR1| . . . |HRn) is true,where MH210is master hash;(b) whether Versign{Kpub}(MH,SMH) is true,where Kpubis the public key provided by fixity data,Versign is the verification of digital signature;(c) whether Hi==HRiis true,where Hiis the digest of part Hias defined by (1).

The verification succeeds if all three checks (a), (b), and (c) made by the verifier120pass.

In one implementation, the verifier120also sends an inquiry to the trusted database130whether the master hash signature (SMH)220matches the SMH stored in the trusted database130. The trusted database130compares the received result with the fixity metadata114and returns to the verifier120that the file102is pristine when the comparison is positive. Since the SMH is cryptographically protected from an attacker by using a private key to sign the master hash, the attacker is not able to forge a valid signature. Therefore, it is possible to verify one part's fixity without access to the entire file while still proving that the verified part belongs to the complete file. In one implementation, the trusted database130is a blockchain.

FIG.2Bis a diagram illustrating a trusted rooted fixity processing230in accordance with one implementation of the present disclosure. In one implementation, a trusted rooted fixity processing230may be used when creating fixity data from a file that already has a Message Digest 5 (MD5) hash. In this implementation, the rooted fixity processing proves the following:(a) the corresponding file presents a valid fixity;(b) the corresponding file is a genuine copy of a file with a given MD5.

Thus, the trusted rooted fixity processing230links the MD5 of a legacy file to the new format. For example, the rooted fixity processing230securely links the MD5 of a master on a Linear Tape-Open (LTO) to a file in the cloud. Accordingly, the difference between the trusted rooted fixity processing230and the fixity data processing200inFIG.2Ais in the master hash signature (SMH)260, which encompasses both the master hash240and the legacy MD5 hash250. The following equation defines SMH:
SMH=Sign{Kpri}(MH|MD5).  [4]

In one implementation, the digest function is xxhash64, the master hash digest is SHA256 and the digital signature is RSA-2048 of the hashed value. An X509 certificate encapsulates the public key. Thus, in this implementation, the equations [3] and [4] are replaced by
SMH=RSA{Kpri}(SHA256(MH)),  [5]
SMH=RSA{Kpri}(SHA256(MH|MD5)).  [6]

The fixity data is a file containing at least the following fields:(a) Rooted is a Boolean value, which is true if the file described a rooted fixity;(b) Parts is an array of metadata, where each metadata describes one part of the content (Pi), the first part being the first element of the array and holding at least: ‘Size’ that defines the number of bytes of the part; and ‘Hash’ that is the 64-bit digest of the part (i.e., Hi);(c) MasterHash is the 256-bit master hash;(d) SignClear is the master hash signature in its binary form;(e) PEMClear is the PEM-encoded public key; and(f) MD5 hash is the 16-byte MD5 hash used for rooted fixity, which is meaningful only if Rooted is true.

FIG.3Ais a flow diagram of a method300for fixity data processing in accordance with one implementation of the present disclosure. In the illustrated implementation ofFIG.3A, a file102is received and processed, at step310, by slicing it102into several parts {P0, P1, . . . , Pn}, where each part (Px) may have a different length. A digest (Hi) of each part Pcis calculated, at step320, as follows:
∀iϵ{1 . . .n},Hi=hash(Pi),where hash( ) is a hash function.

Once it is determined, at step322, that digests for all parts have been calculated, the master hash (MH) is calculated, at step330, as follows:
MH=hash1(H1| . . . |Hn).

After the master hash (MH) is calculated, the master hash signature (SMH) is calculated, at step332, as follows:
SMH=Sign{Kpri}(MH),where Kpriis the private key, andSign is a digital signature.

In one implementation, the fixity data112is generated, at step334, as a set of digests, master hash (MH), master hash signature (SMH), and the public key118(i.e., {{HR0, HR1, . . . , HRn}, MH, SMH, Kpub}). The generated fixity data112is sent to the verifier120for verification processing. Further, the fixity metadata114is stored in the trusted database130, at step336, as the master hash (MH), the master hash signature (SMH), the public key118, and the identification of the file102. In one implementation, the trusted database130is a blockchain.

In one implementation, the method300for fixity data processing includes verification processing to verify that part Pihas not been impaired, following checks are performed:

(at step340) whether MH==hash1(HR1| . . . |HRn) is true,

where MH210is master hash;
(at step342) whether Versign{Kpub}(MH,SMH) is true,where Kpubis the public key provided by fixity data,Versign is verification of digital signature;
(at step344) whether Hi==HRiis true, where Hiis the digest of part Hias defined by [1].

The verification succeeds if it is determined, at step346, that all three checks made at steps340,342, and344pass.

In one implementation, an inquiry is sent to the trusted database130, at step350, to determine whether the master hash signature (SMH)220matches the SMH stored in the trusted database130. The received result is compared, at step352, with the fixity metadata114and a determination is made, at step354, that the file102is pristine when the comparison is positive. Since the SMH is cryptographically protected from an attacker by using a private key to sign the master hash, the attacker is not able to forge a valid signature. Therefore, it is possible to verify one part's fixity without access to the entire file while still proving that the verified part belongs to the complete file. In one implementation, the trusted database130is a blockchain.

FIG.3Bis a flow diagram of a method360for verifying that a file is a pristine copy of a same file that an ingester prepared in accordance with one implementation of the present disclosure. In the illustrated implementation ofFIG.3B, the method includes receiving a plurality of parts of the file, at step362. At step364, fixity data including a set of digests of a plurality of parts, a master hash, a master hash signature, and a public key of the ingester, is received. The master hash in the fixity data is compared, at step366, with a combination of hash of each part. The master hash signature in the fixity data is then compared, at step368, with a digital signature of the master hash calculated using the public key of the ingester. A hash of each part is compared, at step370, with each digest. The file is declared, at step380, as pristine and not impaired when all three comparisons produce true results, at step372. The file is declared, at step382, as impaired when not all three comparisons produce true results, at step372.

FIG.4Ais a representation of a computer system400and a user402in accordance with an implementation of the present disclosure. The user402uses the computer system400to implement an application490for fixity data processing as illustrated and described with respect to the system100inFIG.1and the methods300,360inFIGS.3A and3B.

The computer system400stores and executes the fixity data processing application490ofFIG.4B. In addition, the computer system400may be in communication with a software program404. Software program404may include the software code for the fixity data processing application490. Software program404may be loaded on an external medium such as a CD, DVD, or a storage drive, as will be explained further below.

Furthermore, the computer system400may be connected to a network480. The network480can be connected in various different architectures, for example, client-server architecture, a Peer-to-Peer network architecture, or other type of architectures. For example, network480can be in communication with a server485that coordinates engines and data used within the fixity data processing application490. Also, the network can be different types of networks. For example, the network480can be the Internet, a Local Area Network or any variations of Local Area Network, a Wide Area Network, a Metropolitan Area Network, an Intranet or Extranet, or a wireless network.

FIG.4Bis a functional block diagram illustrating the computer system400hosting the fixity data processing application490in accordance with an implementation of the present disclosure. A controller410is a programmable processor and controls the operation of the computer system400and its components. The controller410loads instructions (e.g., in the form of a computer program) from the memory420or an embedded controller memory (not shown) and executes these instructions to control the system, such as to provide the data processing. In its execution, the controller410provides the fixity data processing application490with a software system. Alternatively, this service can be implemented as separate hardware components in the controller410or the computer system400.

Memory420stores data temporarily for use by the other components of the computer system400. In one implementation, memory420is implemented as RAM. In one implementation, memory420also includes long-term or permanent memory, such as flash memory and/or ROM.

Storage430stores data either temporarily or for long periods of time for use by the other components of the computer system400. For example, storage430stores data used by the fixity data processing application490. In one implementation, storage430is a hard disk drive.

The media device440receives removable media and reads and/or writes data to the inserted media. In one implementation, for example, the media device440is an optical disc drive.

The user interface450includes components for accepting user input from the user of the computer system400and presenting information to the user402. In one implementation, the user interface450includes a keyboard, a mouse, audio speakers, and a display. The controller410uses input from the user402to adjust the operation of the computer system400.

The I/O interface460includes 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 a PDA). In one implementation, the ports of the I/O interface460include ports such as: USB ports, PCMCIA ports, serial ports, and/or parallel ports. In another implementation, the I/O interface460includes a wireless interface for communication with external devices wirelessly.

The network interface470includes a wired and/or wireless network connection, such as an RJ-45 or “Wi-Fi” interface (including, but not limited to 802.11) supporting an Ethernet connection.

The computer system400includes additional hardware and software typical of computer systems (e.g., power, cooling, operating system), though these components are not specifically shown inFIG.4Bfor simplicity. In other implementations, different configurations of the computer system can be used (e.g., different bus or storage configurations or a multi-processor configuration).

In one implementation, the system100is a system configured entirely with hardware 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. In another implementation, the system100is configured with a combination of hardware and software.

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

Those of skill in the art will appreciate that the various illustrative modules and method steps described herein can be implemented as electronic hardware, software, firmware or combinations of the foregoing. To clearly illustrate this interchangeability of hardware and software, various illustrative modules and method steps have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled persons can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure. In addition, the grouping of functions within a module or step is for ease of description. Specific functions can be moved from one module or step to another without departing from the present disclosure.

All features of the above-discussed examples are not necessarily required in a particular implementation of the present disclosure. Further, it is to be understood that the description and drawings presented herein are representative of the subject matter that is broadly contemplated by the present disclosure. It is further understood that the scope of the present disclosure fully encompasses other implementations that may become obvious to those skilled in the art and that the scope of the present disclosure is accordingly limited by nothing other than the appended claims.