Patent Description:
<CIT> discloses cloud data backup. Example methods may store backup data from a client computer on portions of data storage media associated with peer computers. A file may be encoded into segments using an error-tolerant encoding scheme, and the segments may be stored on peer computers. <CIT> discloses a method and system for authenticating software in a mobile terminal which: receives an execution instruction for software installed in said mobile terminal through an inputting means, generates a first error code for said software, extracts a mobile terminal identifier of said mobile terminal, generates a first authentication key by combining said mobile terminal identifier and said first error code, and executes said software when said first authentication key corresponds to a second authentication key stored in said mobile terminal. <CIT> discloses storing, retrieving, transmitting and receiving data (<NUM>) by a) separating the data into a plurality of data subsets (A, B); b) generating parity data (P) from the plurality of data subsets (A, B) such that any one or more of the plurality of data subsets may be recreated from the remaining data subsets and the parity data (P).

Attesting to the identity and authenticity of content has become more important and prevalent as the number of internet users increases. For example, anonymous and malicious actors may actively engage users through phishing, human engineering, and/or other forms of subversion to subvert legitimate content with fraudulent and malicious contents. Systems exist to test the authenticity of content such as public key signing, code signing, etc.; however, these systems have not grown and adapted as file formats and transmission costs have increased.

For example, some approaches to data recovery with authenticity and/or data validation/authentication rely on the entirety of file contents to be available to attest authenticity and are designed to test a limited set of file formats. In contrast, examples of the present disclosure provide an ability to test for authenticity early in the data retrieval process, reducing costs of retrieval for fraudulent data. Furthermore, examples of the present disclosure may present a data recoverability component that can be measured and monitored in real-time during data transfer and can mitigate costs associated with data retransmission. For instance, examples of the present disclosure may allow for data recovery such that a block of broken content can be replaced and/or repaired with a block of recovery content.

In addition, some approaches to data recovery with authenticity and/or data validation/authentication include using only Reed-Solomon codes, erasure code systems, cyclical-redundancy or other in-line recovery protocols, and/or code signing. However, these approaches include multiple costs including time, CPU utilization, network bandwidth utilization, network data transmission costs, and other opportunity costs. Additionally, these approaches include increasing costs and lengths of time to implement file signing schemes, and they may be limited to signing only some file types (e.g., executable file types). In addition, these approaches may require recovery data carried along with original data in a same packet (e.g., network packet). Further, these approaches may not assess and react to threats quick enough to avoid an attack or infection of their environment. For instance, these approaches may be unable to authenticate and/or validate date until all of the file contents have been delivered (e.g., downloaded), resulting in costs incurred from the entire delivery.

Furthermore, some approaches may result in increased costs to implement file signing schemes for large content. For instance, file signing may be done through a centralized authority to limit fraudulent signing or apply consistent processes (e.g., antivirus scanning) such as at an organizational level. In such an organizational level example, a company may have one identity for code signing that is shared as a resource to all potential signers. The process of signing in this model can be expensive due to network transmission and delays because the time to sign contents not only increases due to the size of contents to be signed and the strength (e.g., size) of the keys used to sign that content. For instance, as the size of an operating system grows, so does the process of signing binaries associated with the operating system.

In contrast, examples of the present disclosure can provide a safeguard resulting in accurate, authentic, and trustworthy file contents while the file contents are being downloaded. To address the threat of fraudulent data on the internet, examples of the present disclosure allow for an assessment and reaction to the threat, during delivery of file content. In addition, examples of the present disclosure do not embed the costs of recovery into the transmission of data, resulting in the costs of transmission being accrued only as needed. Further, examples of the present disclosure can provide attestation and authenticity to large file contents before an end user must download and potentially expose themselves to risks. For instance, the present disclosure validates file integrity and authenticity in real-time as file contents are being delivered to a user. In addition, examples of the present disclosure can allow for a user to begin using file contents prior to all of the file contents being available (e.g., before completion of delivery and/or download). Similarly, examples of the present disclosure can allow for a process to being using the file contents immediately upon validation and/or authorization, which can speed up further processing for a user.

<FIG> illustrates a diagram <NUM> of a file-based format according to an example. The file-based format can represent an entire file size. For instance, the file-based format can be a per-sector representation of an entire disk structure (e.g., an entire International Organization for Standardization (ISO) image, DVD ROM representation, hard drive image, etc.). Such a file-based format can provide a mechanism to validate file integrity and authenticity by validating file contents in real-time as the file contents are being delivered to a user and/or service. In such an example, a user may be able to choose to opt-out of the delivery (e.g., data transmission, download, etc.) at any point during delivery. For instance, a user can opt-out if they are suspicious that the file content is not authentic, has been tampered with, and/or contains too many errors to be reliable.

Diagram <NUM> includes file content <NUM>. File content <NUM> can include an item delivered to a user. For instance, a large image representing a hard drive of a platform may be delivered to a user. This item may include a large image (e.g., up to <NUM> Gigabytes) offered for download, for example. Such an item may include a number of individual files.

Diagram <NUM> also includes content hash portion <NUM> (also known as hash keys for parity data), authentication certificate portion <NUM> (also known as signatures over the hash key data), and recovery blocks <NUM>. Content hash portion <NUM> and authentication certificate portion <NUM> can be included in hash content area <NUM>. Hash content area can also include file content location information, file content hash information, and portions of the file content structure representation information.

The file contents is measured in hash blocks in the content hash portion <NUM>. The hash block sizes can be defined, and it may be desired that the hash blocks be relatively small compared to other hash blocks, such that they are quicker to measure, easier to download, and/or easier to recover. The file contents, as noted, can be measured in a block size and stored as individual hash blocks within content hash portion <NUM>. This measurement can be performed using a one-way function to calculate a value associated with each block, for example, and that value can be used in a determination of the quality and/or completeness of the file content in the hash block.

The hash blocks, which can also include recovery content, can represent the file contents, and a secure attestation can be made on that representation. As such, once the hash blocks are ready, they can be relied upon for validation and authentication. For instance, because the hash blocks are reliable, if a piece of material in the file content is later changed, the hash will break , so the initial file content can be retrieved and the file contents' integrity analyzed and validated.

Authentication certificate portion <NUM> can include authentication certificates (e.g., signing certificates, digital signatures, etc.) associated with each hash block within content hash portion <NUM>. Both content hash portion <NUM> and authentication certificate portion <NUM> can have sizes governed by the number of hash blocks being signed/authenticated. As such, the scale of the sizes of portions <NUM>, <NUM>, <NUM>, and <NUM> can vary, for instance, the sizes of content hash portion <NUM> and authentication certification portion <NUM> can be smaller or larger as compared to file content portion <NUM> than shown in <FIG>. In some examples, a user may be able to maintain and obtain the information present in the hash content area <NUM>, and this information can be used in an evaluation process of the file contents' validity and/or authenticity.

Recovery blocks portion <NUM> can include recovery blocks used to repair and/or replace broken file content. For instance, a hash of each recovery block may be found in the content hash portion <NUM>, but the recovery blocks may be generated using Reed-Solomon code. The recovery blocks contain recovery data used to repair and/or replace broken file content, but do not contain hashes.

<FIG> illustrates a diagram <NUM> of a data stream format according to an example. For instance, diagram <NUM> uses a data stream format and/or a file system metadata format to represent similar examples to those illustrated in <FIG>. The data stream format may be an alternative data stream format, which may allow for the forking of file data into existing files without affecting their functionality, size, or display. Additional streams may be added for additional attributes of data and maintained at a file system level. In such an example, file content portion <NUM>, recovery blocks portion <NUM> and hash content area <NUM> can be applied to individual data streams within a file system that supports data streams.

With respect to a file system metadata format, a file system can store the metadata associated with the file content including a file name, a length of the contents of a file, and/or a location of the file in the folder hierarchy, separate from the contents of the file.

In the example illustrated in <FIG>, the stream0 <NUM>, stream1 <NUM>, and stream2 <NUM> can represent a sequence of bytes, can include data written to a file, and can give additional information about a file than attributes and properties. Each data stream can maintain its own state for compression, encryption, and sparseness. For example, data stream0 <NUM> (also called default stream) includes file content <NUM>. File content <NUM> can include information delivered (or to be delivered) to a user (e.g., downloadable content). Data stream1 <NUM> can include recovery blocks <NUM> as described with respect to recovery blocks <NUM> of <FIG>, and data stream2 <NUM> can include hash content area <NUM>, which can include content hash portion <NUM> and authentication certification portion <NUM> as described in <FIG> with respect to hash content area <NUM>, content hash portion <NUM> and authentication certification portion <NUM>.

Though not illustrated in <FIG> and <FIG>, content hash portion <NUM>, <NUM>, recovery blocks portion <NUM>, <NUM>, and file content portion <NUM>, <NUM>, can include individual blocks of data. For instance, content hash portion <NUM>, <NUM> can include hash blocks, file content portion <NUM>, <NUM> can include content blocks, and recovery blocks portion <NUM>, <NUM> can include recovery blocks. The different blocks may have different sizes and relationships with respect to one another.

For instance, the hash blocks may be small in size (e.g., <NUM> bytes), but may map <NUM>:<NUM> to the content blocks. Content blocks may be the largest of the blocks (e.g., <NUM> megabyte), but as noted, may map <NUM>:<NUM> to the hash blocks. The recovery block sizes may be determined by the amount of data to be recovered (e.g., <NUM>-<NUM> kilobytes). The number of recovery blocks can be based on the number of content blocks.

In some examples, a source can deliver file contents to a user (e.g., via download). For instance, a user may request to download particular file contents, or a source may push the file contents to the user. The user may not be able to determine the authenticity of the source (e.g., whether the file contents are coming from who the user thinks they are), and/or the user may not be able to determine an integrity of the file contents (e.g., whether or not they are corrupt, broken, etc.). In such an example, the authenticity and integrity of the file contents <NUM>, <NUM> is validated using hash content area <NUM>, <NUM>.

For instance, file content <NUM>, <NUM> is measured in hash blocks and kept as individual hash blocks within content hash portion <NUM>, <NUM>. An authentication certificate associated with each of the hash blocks can be stored in authentication certification portion <NUM>, <NUM>. A one-way function can be used to calculate a value associated with each of the individual hash blocks, which can verify the completeness and quality of the file content hash blocks within content hash portion <NUM>, <NUM>. With these hash blocks now representing the entire file content <NUM>, <NUM>, the file content <NUM>, <NUM> can be delivered to a user.

As the file contents <NUM>, <NUM> are delivered to the user, the source of the file contents <NUM>, <NUM> can be authenticated at any time during the delivery process using authentication certificate portion <NUM>, <NUM>. For instance, the identity of the source of the file contents <NUM>, <NUM> can be tested and validated during delivery through a comparison to the contents of authentication certificate portion <NUM>, <NUM>. Should the validity of the source come into question, the delivery can be stopped at any time. For instance, if a user becomes suspicious, the user can opt-out of the delivery without having to complete the entire delivery (e.g., wait for a complete download).

Similarly, as the file contents <NUM>, <NUM> are delivered to the user, the integrity of the file contents <NUM>, <NUM> can be analyzed using content hash portion <NUM>, <NUM>. For instance, if during the analysis of the integrity, it is determined that the file contents <NUM>, <NUM> have been tampered with, are corrupt, are broken, etc., the delivery of file contents <NUM>, <NUM> can be stopped. In some examples, a user may opt out of the delivery at any time during delivery if such a determination is made, rather than waiting for delivery completion.

In some examples, if a determination is made using the contents of content hash portion <NUM>, <NUM> that file contents <NUM>, <NUM> are damaged, corrupt, tampered with, etc., those file contents <NUM>, <NUM> can be recovered and/or repaired during delivery. For instance, if one block of file content <NUM>, <NUM> is damaged, one recovery block from recovery block portion <NUM>, <NUM> can be used to recover and/or repair the damaged block during delivery. Similarly, if two blocks are damaged, two recovery blocks can be used to repair and/or recovery the damaged blocks during delivery. That is, for every one piece of damaged file content, one recovery block can be used to recover and/or repair. This can reduce the amount of recovery data needed for repair, thus reducing costs and time needed. Further, in some examples, any recovery block within recovery block portion <NUM>, <NUM> can be used to repair any block of damaged, lost, broken, etc. file content.

In some examples, it may be known as the file contents <NUM>, <NUM> are being delivered that a block of the file contents <NUM>, <NUM> is corrupt or not corrupt. In such an example where a corrupt block is discovered, a new, non-corrupt block can be grabbed from content hash portion <NUM>, <NUM> to provide recovery information for the corrupt block. Alternatively, a recovery block from recovery block portion <NUM>, <NUM> can be grabbed to provide recovery information for the corrupt block. This can be done during delivery of the file contents <NUM>, <NUM>, which may ensure authenticity and integrity of the file contents <NUM>, <NUM> before completion of delivery. For example, the hash blocks and/or the recovery blocks may be smaller than the original data blocks (e.g., file content blocks) for which they are providing recovery information (e.g., about <NUM>-<NUM> percent of the size). A recovery block - along with the corrupted data can be transformed/processed to recreate the original block. By using a Reed Solomon model to generate a recovery block, any recovery block can substitute for another block. All that may be needed is equal numbers of recovery blocks for equal parts (blocks) of corrupted data.

<FIG> illustrates a diagram of a computing system <NUM> including a processing resource <NUM>, a memory resource <NUM>, and a number of modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> according to an example. The computing system <NUM> can utilize instructions (e.g., software and/or firmware) hardware, and/or logic to perform a number of functions including those described herein. The computing system <NUM> can be a combination of hardware and program instructions configured to share information. The hardware, for example, can include a processing resource <NUM> and/or a memory resource <NUM> (e.g., computer readable medium (CRM), machine readable medium (MRM), etc., database, etc.).

A processing resource <NUM>, as used herein, can include a processor capable of executing instructions stored by a memory resource <NUM>. Processing resource <NUM> can be implemented in a single device or distributed across multiple devices. The program instructions (e.g., machine-readable instructions (MRI)) can include instructions stored on the memory resource <NUM> and executable by the processing resource <NUM> to implement a desired function (e.g., data recovery, data validation, and/or data authentication).

The memory resource <NUM> can be in communication with a processing resource <NUM>. A memory resource <NUM>, as used herein, can include memory components capable of storing instructions that can be executed by processing resource <NUM>. Such memory resource <NUM> can be a non-transitory CRM or MRM. Memory resource <NUM> can be integrated in a single device or distributed across multiple devices. Further, memory resource <NUM> can be fully or partially integrated in the same device as processing resource <NUM> or it can be separate but accessible to that device and processing resource <NUM>. Thus, it is noted that the computing system <NUM> can be implemented on a participant device, on a server device, on a collection of server devices, and/or a combination of the user device and the server device.

The memory resource <NUM> can be in communication with the processing resource <NUM> via a communication link (e.g., a path) <NUM>. The communication link <NUM> can be local or remote to a machine (e.g., a computing system) associated with the processing resource <NUM>. Examples of a local communication link <NUM> can include an electronic bus internal to a machine (e.g., a computing system) where the memory resource <NUM> is one of volatile, non-volatile, fixed, and/or removable storage medium in communication with the processing resource <NUM> via the electronic bus.

A module and/or modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can include MRI that when executed by the processing resource <NUM> can perform a number of functions including those described herein. The number of modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can be sub-modules of other modules. For example, the recover module I <NUM> and the recover module II <NUM> can be sub-modules and/or contained within the same computing system. In another example, the number of modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can comprise individual modules at separate and distinct locations (e.g., MRM, etc.).

Each of the number of modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can include instructions that when executed by the processing resource <NUM> can function as a corresponding engine. For example, the delivery module <NUM> can include instructions that when executed by the processing resource <NUM> can function as a delivery engine. Similar, each of the number of modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can include instructions that when executed by the processing resource <NUM> can function as engines.

In some examples, engines can be part of a system (not illustrated) including a database, a subsystem, and the number of engines. The subsystem can include the number of engines in communication with the database via a communication link (e.g., link <NUM> as referenced in <FIG>). The system can represent instructions and/or hardware of a network controller (e.g., system <NUM> as referenced in <FIG>, etc.).

The number of engines can include a combination of hardware and programming to perform functions including those described herein. The instructions can include instructions (e.g., software, firmware, etc.) stored in a memory resource (e.g., CRM, MRM, etc.) as well as hard-wired program (e.g., logic).

In some examples, the number of modules <NUM>, <NUM>, <NUM>, <NUM>, <NUM> can be used in a software-as-a-service delivery model. For instance, components of computing system <NUM> can exist in a single computing system or multiple computing systems (e.g., distributed). For example, a web server or other computing system that is trusted by the user can provide services to a server of individual data streams, and/or act on behalf of the user as a processing agent for recovery.

In an example, delivery module <NUM> can include instructions that when executed by the processing resource <NUM> can cause a computing system to deliver file contents to a user. For instance, an image representing an entire hard drive of a platform may be sent to a user. The user may request delivery in the form of a download or other delivery method, and/or the source of the file contents can push the delivery to the user. In some examples, the instructions can be further executable to deliver the file contents to a user within a same network as a source of the file contents. For instance, systems within a network can be in communication with one another and can delivery file contents to one another. Some examples may leverage access to content ranges instead of always starting at the beginning of file content, which can result in increased recoverability for network usage.

Authenticity module <NUM> includes instructions that when executed by the processing resource <NUM> cause a computing system to validate an authenticity of the file contents in real-time during the delivery. Validating the authenticity of the file contents can include validating authenticity of remote content before the actual file contents are downloaded. This can allow for the testing and validation of the identity of the file content source, and at any point during delivery, the source of the file contents can be determined.

In some examples, validation may be desired because during delivery of the file contents (e.g., the image mentioned above), the source of the file contents may be unclear, meaning the source is unknown and/or the identity of the source has been tampered with. Validation may also be desired, because even with an authentication certificate (e.g., a signature), there may not be a guarantee that the authentication certificate follows the image and/or that the authentication certificate has not been replaced. Further, in an example within a network, in an environment where data is moving from hard disk to hard disk and/or inside a network, data can be broken, lost, etc. within the file contents, so validation of the authenticity of the source of the file contents can be performed.

Integrity module <NUM> can include instructions that when executed by the processing resource <NUM> can cause a computing system to analyze an integrity of the file contents in real-time during the delivery. Analysis of the integrity of the file contents can include determining if any of the file contents is broken, lost, corrupt, tampered with, etc. Analysis of the integrity of the file contents may be desired because during delivery of the file contents (e.g., the image mentioned above), a connection may be lost, and/or the file contents may be corrupt, among other issues as noted above. At any point during delivery, a determination can be made that the file contents that have been download are correct or incorrect. Any one piece of broken file content can be replaced with any one piece of recovery content. This can be done during delivery, meaning a user does not have to wait for all of the file contents to download before determining a portion or all of the file contents are broken, incorrect, corrupt, etc..

Further, in an example within a network, in an environment where data is moving from hard disk to hard disk and/or inside a network, data can be broken, lost, etc. within the file contents, so analyzing an integrity of the file contents can be performed.

Recover module I <NUM> can include instructions that when executed by the processing resource <NUM> can cause a computing system to recover data to repair an authenticity issue determined during the authenticity validation. For instance, if a determination is made during delivery that an authentication certificate is invalid, that authentication certificate can be replaced with a new, valid authentication certificate based on contents of an authentication portion of a file system and/or a recovery block portion of the file system. The repair/replacement and/or recovery of the authentication certificate can be performed during delivery, in real-time, such that the user does not have to wait for completion of delivery. The user can know in real-time during delivery that the source of the file contents is authentic.

Recover module II <NUM> can include instructions that when executed by the processing resource <NUM> can cause a computing system to recover data to repair a file corruption issue determined during the analysis of the integrity of the file contents. For instance, data can be recovered to repair a file corruption issue by replacing a corrupt block with a recovery block. This can be performed in a one-to-one manner, such that any one block of broken file content can be repaired/replaced with one block of recovery data. This can result in having to recover the least amount of data as necessary being used to fixed corruption or other issues. For instance, in some examples, a failed hash block can be retransmitted individually once an error is found, which can correct transmission errors and/or I/O processing errors. Additionally or alternatively, a failed hash block can be recovered using one recovery block, correcting persistent errors in a source file.

In an example, computer system <NUM> can include a hash area module (not illustrated in <FIG>) can include instructions that when executed by the processing resource <NUM> can cause a computing system to create a content hash area comprising a representation of the file contents, wherein the representation includes a secure attestation. For instance, the content hash area can include file content hash blocks and associated authentication certificates. These can represent the entire file contents, and a secure attestation can be made on those file contents, which can be used for authentication and validation of the file contents and their source.

<FIG> illustrates a diagram of an example controller <NUM> including a processing resource, a memory resource, and a number of modules according to an example. For example, the controller <NUM> can be a combination of hardware and instructions for data recovery, data validation, and/or data authentication. The hardware, for example can include a processing resource <NUM> and/or a memory resource <NUM> (e.g., MRM, CRM, data store, etc.).

The processing resource <NUM>, as used herein, can include a number of processors capable of executing instructions stored by a memory resource <NUM>. The instructions (e.g., MRI) can include instructions stored on the memory resource <NUM> and executable by the processing resource <NUM> to implement a desired function (e.g., data recovery, data validation, and/or data authentication, etc.).

The memory resource <NUM>, as used herein, can include a number of memory components capable of storing non-transitory instructions that can be executed by processing resource <NUM>. Memory resource <NUM> can be integrated in a single device or distributed across multiple devices. Further, memory resource <NUM> can be fully or partially integrated in the same device as processing resource <NUM> or it can be separate but accessible to that device and processing resource <NUM>. Thus, it is noted that the controller <NUM> can be implemented on an electronic device and/or a collection of electronic devices, among other possibilities.

The memory resource <NUM> can be in communication with the processing resource <NUM> via a communication link (e.g., path) <NUM>. The communication link <NUM> can be local or remote to an electronic device associated with the processing resource <NUM>.

The memory resource <NUM> includes a number of engines (e.g., file contents engine <NUM>, validate engine <NUM>, recover engine <NUM>, deliver engine <NUM>, etc.). The memory resource <NUM> can include additional or fewer engines than illustrated to perform the various functions described herein.

The number of engines can include a combination of hardware and instructions to perform a number of functions described herein (e.g., data recovery, data validation, and/or data authentication, etc.). The instructions (e.g., software, firmware, etc.) can be downloaded and stored in a memory resource (e.g., MRM) as well as a hard-wired program (e.g., logic), among other possibilities.

The file contents engine <NUM> can deliver file contents to a user, for instance via a download. This delivery can take place inside or outside of a network setting. The validate engine <NUM> can validate the file contents in real-time during the delivery. For instance, the validation can include the controller <NUM> validating an authenticity of the file contents and an authenticity of hash blocks within a hash content area associated with the file contents in real-time before completion of the delivery. Additionally or alternatively, the validation can include the controller <NUM> analyzing an integrity of the file contents and an authenticity of hash blocks within a hash content area associated with the file contents in real-time before completion of the delivery. For instance, validated file contents can include file contents with an authenticated source, and file contents that are not corrupt, broken, lost, etc..

The recover engine <NUM> can use the validated file contents to recover the broken portion of the file contents in response to a determination that a portion of the file contents is broken. In some examples, recovering the broken portion can include the controller <NUM> redelivering the broken portion. Recovering the broken portion in some examples can also include the controller <NUM> replacing the broken portion with a recovery portion. For instance, a block of broken file content may be replaced with a block of recovery portion. This can be performed during delivery of the file contents.

The deliver engine <NUM> can deliver the recovered portion of the file contents to the user. For instance, the recovered portion can be delivered in real-time, during delivery to the user. The user does not have to wait for completion of delivery to receive the recovered portion. Further, the user does not have to wait for completion of delivery to learn that the file contents source is not authentic (e.g., not who they though was sending the file contents) and/or that the file contents are broken, corrupt, lost, etc. This can save the user time, costs, and concerns.

In some examples, the controller <NUM> can include instructions to allow the user to begin using the file contents before completion of the delivery (e.g., while delivery of the file contents are underway). For instance, all of the file contents may not be available to the user, but the portions that are available can be used. The available file contents may be validated and authenticated, so the user can safely use the available file contents.

In some examples, the controller <NUM> can allow a process to start using file contents before delivery is complete. For instance, the file contents can include an ISO image or a group of files (e.g., zip or other file archive format) such that once individual files in the underlying format are available, they have be authenticated and validated (e.g., unaltered, legitimate), so a further process can start using that content (e.g., mounting a file system stored within the ISO or zip content). This can speed up further processing for the user, in some examples.

<FIG> illustrates a diagram of a method <NUM> for data recovery with authenticity according to an example. At <NUM>, method <NUM> includes measuring contents of a file as hash blocks. A one way function can be used to calculate a value associated with each hash block, and that value can be used to determine a completeness and quality of the file content hash block. At <NUM>, method <NUM> includes collecting as data the hash blocks and an authentication certificate in a content hash area. Method <NUM> can also include collecting as data a location of contents of the file and a file structure represented as contents of the file in the content hash area. The information within the content hash area is used to validate an integrity of the file contents and authenticate a source of the file contents, as will be discussed further herein.

Method <NUM>, at <NUM> can include delivering the contents of the file and the authentication certification to a user. The contents of the file can be delivered via download, for instance, and can be delivered in-network, out-of-network, or both. At <NUM>, method <NUM> can include authenticating, in real-time during delivery, a source of the contents based on the data in the content hash area. For instance, using authentication certificate information within the content hash area, the authenticity of the source can be determined. If suspicions arise with respect to the authenticity of the source (e.g., a certificate has been tampered with, removed, etc.), delivery can stop, or the authentication certificate can be repaired and/or replaced during deliver and in real-time.

At <NUM>, method <NUM> includes validating, in real-time during delivery, an authenticity of the file contents based on the data in the content hash area. For instance, using the hash blocks, a determination can be made as to whether the file contents are corrupt, broken, lost, etc. Method <NUM> can include, at <NUM>, recovering the broken block using a recovery block associated with the content hash area in response to a determination that a block of the delivered contents of the file is broken. For instance, if a block is corrupt, broken, lost, etc., any recovery block can be used to repair/replace the broken block. The recovery block may be associated with the content hash area such that there is a hash of the recovery block in the content hash area. In some examples, recovering the broken block using a recovery block from the content hash area includes recovering a number of broken blocks using a same number of recovery blocks. For instance, if five blocks are broken, five recovery blocks can be used to recover the five broken blocks.

Method <NUM> can also include allowing a user to use a first portion of the contents of the file upon delivery completion of the first portion while delivery of a second portion of the contents of the file is still underway. For example, once a portion of the file contents is delivered, a user can begin using that portion before receiving the rest of the file contents. Method <NUM> can also include determining a size of the content hash area based on a number of the hash blocks within the content hash area associated with the authentication certificate. For instance, the content hash area size can vary and may be small relative to the actual file contents, allowing for a user to maintain and obtain information within the content hash area quickly. Further, with a smaller authentication certificate portion, the expense of signing and validating file contents can be reduced by using the smaller recovery has content as the source for signing material.

Method <NUM> can further include receiving instructions from a user to stop delivery of the file contents, and in response to receiving the instructions, ceasing delivery of the file contents. For instance, if it is determined that the source of the file contents is not authentic and/or that the integrity of the file contents is suspicious, a user can opt-out of the remainder of the delivery. This can save the user time and costs, as well as concern over having received unreliable file contents.

In the foregoing detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be utilized and that process, electrical, and/or structural changes can be made without departing from the scope of the present disclosure.

Claim 1:
A controller (<NUM>, <NUM>) comprising a processing resource (<NUM>, <NUM>) in communication with a memory resource (<NUM>, <NUM>) including instructions executable to:
measure file contents (<NUM>) as hash blocks (<NUM>);
collect, as data, the hash blocks (<NUM>) and an authentication certificate (<NUM>) in a content hash area (<NUM>);
deliver the file contents (<NUM>, <NUM>) and the authentication certificate (<NUM>) to a user;
the controller being characterised in that the processing resource in communication with the memory resource includes instructions executable to:
validate an authenticity of the file contents (<NUM>) in real-time during the delivery based on the data in the content hash area (<NUM>);
in response to a determination that a block of the delivered file contents (<NUM>) is broken, use a recovery block (<NUM>) associated with the content hash area (<NUM>) to recover the broken block of the delivered file contents (<NUM>); and
deliver the recovered block of the file contents to the user.