FR3145816A1 - process of establishing an inviolable link between a digital file and variable data - Google Patents

Abstract

The present invention relates to a method for associating variable data with a file, the method comprising steps of: searching, by a processor (T1), for a first location for inserting data in a file (FL1); inserting at the first location in the file an identifier (BCI1) of a data block (BC1) of a register (RG1) accessible from a remote server (SRV), the data block storing a variable data item relating to the file; calculating a first cryptographic fingerprint (HS1) relating to a part of the content of the file including the identifier of the data block, using a fingerprint calculation function (HSH) providing a fingerprint depending on all the bytes of the part of the content of the file; and transmitting the fingerprint, the identifier of the data block, to the remote server, the variable data item being accessible by a request transmitted to the remote server, containing the identifier of the data block and the first fingerprint. Figure for abstract: Figure 1

Description

process of establishing an inviolable link between a digital file and variable data General technical field

The present invention relates generally to file systems and methods for ensuring the integrity and authenticity of digital files, whether distributed over a network or stored on a storage medium.

Definitions

In this description, the following terms and expressions should be understood as follows.

“Digital File” means any digital file or document or any part of such a file or document, capable of being manipulated separately in any file management system.

"Metadata" means data relating to other data. Metadata may be contained in the same file as the other data, or in a different location. Metadata may contain one or more pieces of information relating to the other data, including information specifying, among other things, the location, structure and/or nature of that other data.

"Digital fingerprint" of a digital file means data produced by a function that ensures the integrity of the contents of the file, such that if a byte of the file is modified, the digital fingerprint will be modified. In addition, the probability that two different files have the same fingerprint is very low. This function may be non-invertible, such as a cryptographic hash function applied to all or part of the contents of the file. A digital fingerprint is sometimes called a checksum, fingerprint, hash, message digest, digest, condensate or cryptographic fingerprint. The fingerprint calculation function may combine a hash function and a digital signature function applied to the result of the hash function.

"Digital Signature" means a digital fingerprint processed by a digital signature algorithm using a private key of a public/private key pair and an asymmetric cryptographic program, such as DSA (Digital Signature Algorithm) or ECDSA (Elliptic Curve DSA). A digital signature is used to guarantee the authenticity of a proof of the integrity of a file and to identify and authenticate the signer, by analogy with the handwritten signature of a paper document.

"Controlled insertion" means the insertion of any data into a file, at a location that the user can choose as freely as the type of file concerned allows. However, this does not exclude the possibility that the choice of this location may be carried out by a program, or be standardized.

"Non-destructive insertion" means an insertion of any data into a digital file, carried out without affecting the properties of the file, that is to say without affecting in particular its opening, its display or printing, and its execution if the file contains program instructions, by the same tools as before this insertion.

"Register" means a device providing a presumption of a precise sequential chronological order of changes in the state of an object. A register may be operated by a trusted third party, whether or not certified or approved. The data stored in such a register may be more or less verifiable and/or publicly accessible. In the case where the register is accessible in a dematerialized manner, for example via the Internet, it may be made accessible by requests offering different services, such as query, writing and authentication services. A register may free itself from a trusted third party by relying on a blockchain-type solution, public or private, allowing or not the execution of smart contracts and/or the storage of data.

State of the art

In the context of the widespread use of digital files, it is desirable to be able to replace printed or handwritten documents with digital files offering similar guarantees in terms of probative force. For example, it is desirable that such files can be used as evidence in the context of transactions involving, in particular, material assets or contractual relationships.

US Patent No. 10,218,714 describes a method for determining whether all or part of a digital file has been modified, by inserting into the file a fingerprint calculated from all the data forming the content of the file that may include metadata, excluding an area where the fingerprint is inserted. Thus, if the content of the file is modified, the fingerprint calculated on the modified content of the file is different from the fingerprint inserted into the file. If the fingerprint is replaced by a signature on the fingerprint, or if the file contains a fingerprint and a signature of this fingerprint, and if the public key of the expected signatory appears in the data participating in the calculation of the fingerprint, only the expected signatory could have generated this signature.

Furthermore, in the field of electronic document management, a conceptual framework called "data lineage" has been proposed, aimed at tracing the life cycle of data in order to determine the source of this data and the transformations it has undergone. This concept of data lineage makes it possible, for example, to associate a confidentiality classification with data that may change over time, successive versions of the data or mandatory destruction dates of the data. This process can be deployed within an infrastructure or an organization, by standard electronic document management systems, in particular to trace the authors, versions and managers of documents.

However, there is no tool to perform these tracking operations between infrastructures and between organizations. Indeed, once the document is extracted from its electronic document management system, it loses all its attributes allowing the aforementioned tracking operations. It is also not possible to ensure version tracking of the same document when it is removed from its document management system.

A general concept of transferable electronic documents (MLETR - "Model Law on Transferable Electronic Documents") has also been proposed in the form of a model law, allowing the tracing of successive owners and versions of a document having a commercial value. However, no implementation is suggested in this context to irrevocably give digital documents a status comparable to that of handwritten paper.

It has also been proposed to use a registry to track successive versions of documents under constraints imposing a particular file format and that any version allows the regeneration of the single previous version. This framework does not describe how to attach properties to an existing file, nor how to attest the existence of a plurality of versions, nor how to allow versions to be of distinct formats and constructions, nor finally how to irrevocably designate the registry considered for this traceability.

It has also been proposed to use the NFT ("Non-Fungible Token") technique to trace the ownership of a document, typically a work of art, using smart contract technology. This technique consists of generating data comprising a cryptographic token representing a digital object (for example a work of art) and a digital identity relating to the owner of the digital object. This data, which can thus constitute a title of ownership, is stored and authenticated using a blockchain protocol, in a decentralized digital register. However, nothing prevents a document from being associated with several blockchains, thus identifying several simultaneous owners.

It is therefore desirable to be able to reliably and unfalsifiably link all copies of a file to the same variable data and to be able to determine all the variable data linked to the file.

Embodiments relate to a method for associating variable data with a file, the method comprising steps consisting in: searching, by a processor, for a first location for inserting data in a file; inserting, by the processor, at the first location in the file an identifier of a data block of a register accessible from a remote server, the data block storing variable data relating to the file; calculating, by the processor, a first cryptographic fingerprint relating to a portion of the content of the file including the identifier of the data block, using a fingerprint calculation function, the first fingerprint depending on all the bytes of the portion of the content of the file; and transmitting the first fingerprint by the processor to the remote server, the variable data being accessible by a request transmitted to the remote server, containing the first fingerprint.

In this way, it is not possible to link the file to another data block without modifying the file's fingerprint. If the file is modified, its fingerprint is also modified. As a result, the link between the file and the variable data in the registry is broken, since this link is based on the file's fingerprint. Furthermore, if the modification of the data block containing the variable data can only be carried out by an authorized entity, only this entity can modify the variable data. In other words, the fingerprint prohibits the modification of the identifier of the data block present in the data block that contains the fingerprint, and the fingerprint cannot be obtained from any content other than that of the file. Reading the contents of the file cannot allow access to a data block other than the one designated by the identifier present in the file. This link between the file and the registry is present in all copies or occurrences of the file.

According to one embodiment, the method comprises steps consisting in: receiving by remote server a request for access to the data block containing the first fingerprint of the file; determining by the remote server whether a data block containing the first fingerprint is accessible; and executing by the remote server the access request, and providing by the remote server to a transmitter of the access request a report of execution of the access request.

According to one embodiment, the access request is a read request, the execution of the access request by the remote server comprising steps consisting of reading the data relating to the file identified by the first fingerprint contained in the data block and transmitting the read data to the sender of the access request, and/or the access request is a write request containing data to be written in the data block, the execution of the access request by the remote server comprising steps consisting of writing the data to be written in the data block.

According to one embodiment, the access request is transmitted in association with authentication data of the sender of the access request, the execution of the access request by the remote server comprising steps of authentication by the server of the sender of the access request on the basis of the authentication data, the access request being executed by the remote server only if the server has authenticated the sender of the access request.

According to one embodiment, the method comprises steps consisting in: searching, by the processor, for a second non-destructive insertion location of a data item in the file, the second location being outside the part of the content of the file on which the calculation of the first fingerprint relates; and inserting, by the processor, the first fingerprint at the second location in the file.

According to one embodiment, the part of the file content to which the fingerprint calculation function is applied is defined: by its extent in the file, or by the extent of a part of the file excluded from the fingerprint calculation.

According to one embodiment, the method comprises steps consisting in: calculating, by the processor, a second fingerprint relating to the part of the content of the file on which the calculation of the first fingerprint relates, using the fingerprint calculation function; and comparing, by the processor, the first fingerprint with the second fingerprint, and if the first and second fingerprints are not identical, then the link established by the file identifier is judged to be unintegrated by the processor.

According to one embodiment, the method comprises steps of inserting the fingerprint at at least one other location in the file, the verification of the fingerprint comprising applying the fingerprint calculation function to the content of the file by excluding all occurrences of the fingerprint in the file.

According to one embodiment, the method comprises steps consisting in: calculating, by the processor, a digital signature of the first fingerprint using a private key of a private and public key pair; and inserting, by the processor, the signature in the file outside the part of the content of the file on which the calculation of the first fingerprint relates, access to the data block being conditioned by the provision to the remote server of a valid digital signature verified using the public key of the private and public key pair.

According to one embodiment, the public key is inserted into a metadata in the part of the file on which the calculation of the first fingerprint is carried out.

According to one embodiment, the data block referenced by the identifier is a cryptographic block chain.

According to one embodiment, the calculation of each fingerprint comprises a step of inserting a predefined data item into the part of the file content before applying the fingerprint calculation function to the part of the file.

Embodiments may also relate to a computer program product comprising program file portions recorded on a computer-readable medium, configured to implement the steps of the method as previously defined.

According to one embodiment, at least a portion of the program is included in the file.

Brief description of the figures

Other advantages may also become apparent to those skilled in the art upon reading the examples below, given for illustrative purposes and illustrated by the appended figures, in which identical reference signs correspond to structurally and/or functionally identical or similar elements.

Figure 1 schematically represents a set of steps of a method executed to create a file and associate it with a register, according to one embodiment,

Figure 2 schematically represents a file associated with a register, according to one embodiment,

Figure 3 schematically represents a set of steps of a method for verifying the integrity of a file and reading variable data associated with the file, according to one embodiment,

Figure 4 schematically represents a set of steps of a method for verifying the integrity of a file and writing variable data associated with the file, according to one embodiment.

Detailed description

Figure 1 shows steps S1 to S5 of a method for creating a file from an existing file FL1. The method can be implemented by a terminal T1 and a server SRV interconnected, for example via a data transmission network NT. Thus, the terminal T1 and the server SRV can establish a client-server relationship between them. Figure 2 shows the file FL1 and a register RG1. Initially, the file FL1 can be empty or full.

Steps S1 to S4 are executed successively by the terminal T1. In step S1, the terminal T1 inserts a reference BCI1 to a data block BC1 of the register RG1 in the file FL1. This insertion is carried out in a controlled and potentially non-destructive manner, for example by encapsulating the reference BCI1 in a metadata. The reference BCI1 contains the information making it possible to find the register RG1 and the data block BC1 in the register. Depending on the case, this information may include in particular identification data (for example the address) of the server SRV in order to make it possible to determine which server should be contacted to access the data block BC1.

In step S2, the terminal T1 calculates a HS1 fingerprint of the FL1 file using a fingerprint calculation function HSH receiving as input all or part of the content of the file, including the BCI1 reference or the metadata including this reference and, where applicable, the identification data of the SRV server. The HSH function may be a cryptographic hash function and/or a digital signature function. In step S3, the terminal T1 inserts the HS1 fingerprint into the FL1 file at a location that will not be taken into account for calculating the fingerprint of the FL1 file. Step S3 is optional and therefore can be omitted, knowing that the HS1 fingerprint of the FL1 file can be recalculated from the FL1 file alone.

The HS1 fingerprint can be associated with a marker to find its location and extent in the FL1 file. The HS1 fingerprint can be digitally signed before being inserted into the FL1 file. The fingerprint calculation function can be applied to all or part of the FL1 file.

In step S4, the terminal T1 transmits the HS1 fingerprint to the SRV server. The HS1 fingerprint may be transmitted to the SRV server in the form of a request to update the data block BC1, possibly including the BCI1 identifier of the block BC1 where it must be recorded in the RG1 register, and possibly a digital signature of the HS1 fingerprint. In step S5, the SRV server receives the HS1 fingerprint and inserts it into the BC1 data block of the RG1 register.

In this way, consulting the RG1 register makes it possible to identify the FL1 file and conversely, consulting the FL1 file makes it possible to identify the RG1 register. When step S3 of inserting the HS1 fingerprint into the FL1 file is executed, the fingerprint can be used to find an occurrence of the FL1 file on the user's storage spaces by system IT tools. Furthermore, whether or not the HS1 fingerprint is inserted into the FL1 file, it can be confirmed by querying the SRV server, using the BCI1 identifier appearing in the FL1 file.

The BC1 data block may contain data relating to the FL1 file, which can be modified. Thus, a consultation of the RG1 register on the basis of the BCI1 identifier found in the FL1 file gives access to this modifiable data. On the other hand, if the BCI1 reference is modified in the FL1 file, the imprint calculated on the file thus modified is different from the HS1 imprint. It is therefore not possible to access the BCI1 data block from the modified file, nor to find the modified file from the HS1 imprint located in the BC1 data block of the register. Consequently, the existence of the HS1 imprint prohibits the modification of the BCI1 identifier in the FL1 file. Furthermore, the BCI1 identifier identifies with certainty the BC1 data block in the RG1 register, which contains the HS1 imprint which identifies with certainty the FL1 file. It should be noted that it is extremely difficult to generate a file with a predefined fingerprint, and that it is extremely unlikely (probability less than 10 ^-77 ) that two files have the same fingerprint. It is therefore extremely likely that the HS1 fingerprint was not inserted into the BC1 data block before it was calculated on the FL1 file after inserting the BCI1 identifier.

The links formed by the BCI1 and HS1 data between the FL1 file and the RG1 register do not depend on a physical storage location of the file or the register or on a file system such as NTFS (New Technology File System) or FAT (File Allocation Table). These links can be verified regardless of the copy of the FL1 file considered and the physical location where this copy is stored.

Write access to register RG1 carried out in step S5 may be limited to one or more duly authorized persons.

According to one embodiment, the FL1 file, possibly with its embedded HS1 fingerprint, is published on a platform identifying files by their fingerprint, for example on the IPFS ("InterPlanetary File System") model for fingerprints calculated on the entire file.

Figure 3 shows steps S11 to S18 of a method for read access to variable data associated with a file such as the file FL1, after having been processed during steps S1 and S2 and possibly S3, to receive a data block identifier BCI1 and to calculate the fingerprint HS1. The terminal T1 first executes steps S11 to S14. In step S11, the terminal T1 calculates a fingerprint HS2 of the file by applying the fingerprint calculation function HSH used in step S2 to the content of the file FL1. If the fingerprint HS1 has been inserted into the file FL1, it is excluded from the content of the file to which the HSH function is applied. For this purpose, the position of the fingerprint HS1 in the file can be identified using a marker. The marker may specify one or more excluded areas of the file content, to which the fingerprint calculation must be applied, or specify the area(s) of the file content to which the fingerprint calculation is applied. Step S12 is optional, in particular if the HS1 fingerprint does not appear in the FL1 file. In step S12, the terminal T1 compares the calculated HS2 fingerprint with the HS1 fingerprint previously associated with the FL1 file. If the HS1 and HS2 fingerprints match or are identical, the content of the FL1 file on which the fingerprint calculation is carried out has not been modified since the HS1 fingerprint was calculated. Otherwise, the FL1 file may have been modified, or the fingerprint calculation function used does not correspond to that used for calculating the HS1 fingerprint, or the extent of the content of the file on which the fingerprint calculation is carried out does not correspond to that taken into account for calculating the HS1 fingerprint. Step S12 may include other checks such as verifying a digital signature to determine the authenticity of the file.

The execution of steps S13, S14 may be conditioned on the success of the comparison of the HS1 and HS2 fingerprints in step S12. In step S13, the terminal T1 reads in the FL1 file the BCI1 identifier of the BC1 data block of the RG1 register where the data relating to the FL1 file are stored. In this step, the BCI1 identifier may be considered authentic if the comparison step S12 has been executed and successfully. In step S14, the terminal T1 may transmit to the SRV server a read request RQR for information relating to the FL1 file stored in the RG1 register. For this purpose, the RQR request contains information making it possible to identify the FL1 file, such as the HS2 fingerprint, and possibly all or part of the BCI1 identifier of the BC1 data block. In step S15, the SRV server receives this request and determines whether a data block of the register RG1 indeed contains the HS2 fingerprint transmitted in step S14, and possibly that the HS2 fingerprint is indeed in a data block of the register RG1, corresponding where appropriate to the part of the identifier BCI1 received. Step S15 makes it possible to determine that the received HS2 fingerprint has indeed been previously associated with the data block BC1 of the register RG1, possibly corresponding to the part of the identifier BCI1 received in step S14. The verification carried out in step S15 indirectly makes it possible to determine that the file FL1 is intact if the received HS2 fingerprint has indeed been calculated from the content of the file FL1. If the test carried out in step S15 is positive, then the SRV server executes steps S16 and S17. In step S16, the SRV server reads the information contained in the data block BC1 where the HS2 fingerprint is located. In step S17, the SRV server transmits the information Inf(BC1,HS2) read in the data block BC1 to the terminal T1. In step S18, the terminal T1 receives and uses the information Inf(BC1,HS2) received.

According to one embodiment, the information Inf(BC1,HS2) comprises a list of file identifiers (fingerprints) corresponding to different versions of the file FL1. This presupposes that each time a new version of the file FL1 is created, steps S1 to S5 are executed using the same identifier BCI1 of the data block BC1 and replacing the fingerprint appearing in the file with the new fingerprint calculated on the new version of the file. Thus, the data block BC1 comprises, for each version of the file FL1, a record containing the fingerprint of the version of the file. Thus, the variable data associated with the file FL1 in the data block BC1 is the fingerprint of the most recent known version (or according to the technical modalities, the list of known versions) of the file FL1, recorded successively in the data block BC1. The choice made by the user to consider that a file constitutes a new version of another file is arbitrary and depends neither on the production modalities nor on the format of the file. The RG1 registry can provide the list of version fingerprints of the same file, but does not provide access to the content of these versions.

According to one embodiment, the information Inf(BC1,HS2) comprises one or more smart contract states. According to one example embodiment, the file FL1 contains a digital artwork, and the data block BC1 contains one or more smart contract states containing data relating to the owner of the file FL1 such as owner identification data and data relating to the purchase by the owner of the digital artwork such as the purchase date and the purchase price. Thus, the variable data associated with the file FL1 in the data block BC1 comprises the list of transactions for transferring ownership of the artwork, successively recorded in the data block or BC1. Each transaction can gather data such as the date of the transaction, information on the identity of the new owner, and the amount of the transaction.

It should be noted that the RG1 register can be readable and verifiable by all or only by certain authorized persons, by activating steps S14 to S18. It is therefore possible even for an actor who does not hold the FL1 file or one of its recorded versions, to know for example the list of all versions of the FL1 file, as recorded in the RG1 register or the list of all transactions relating to the FL1 file, recorded in the RG1 register.

Figure 4 shows steps S21 to S28 of a method for writing access to variable data associated with a file such as the file FL1 after having been processed during steps S1 and S2 and possibly S3. Steps S21 to S23 may be identical to steps S11 to S13, respectively, with step S22 also being optional, in particular if the HS1 fingerprint has not been inserted into the file FL1.

Writing to the register RG1 may require the execution of an authentication procedure (step S24), for example between the terminal T1 if the latter must access the register RG1 in writing, and the server SRV. The authentication of the terminal T1 by the server SRV may be carried out by any means required by the server, such as the provision by the terminal to the server of an identifier and a password, or the provision of proof of the ability to sign with an identity expected by the server SRV. For this purpose, the register RG1 may store in association with the data block BC1, one or more public keys making it possible to verify a digital signature, the signature being generated using a signature calculation function receiving as input a data item and a private key corresponding to a public key stored by the server. If the authentication procedure fails in step S24, the server SRV may notify the terminal T1 in step S28. If the terminal T1 (or the user of the terminal) is authenticated, it can transmit to the server SRV a write request RQW containing the information to be written in the data block BC1 in the register RG1 (step S25). The write request contains the fingerprint of the file HS1 linked to the data block BC1, the data to be written DT, and possibly all or part of the identifier BCI1 of the data block BC1 where the write operation must be performed. Note that steps S24 and S25 can be performed simultaneously. In this case, the write request RQW contains the authentication information required by the server.

In step S26, the SRV server receives the write request RQW and checks that it can be carried out. To this end, it executes step S26 which may be identical to step S15. Thus, in step S26, the SRV server determines whether a data block of the register RG1 indeed contains the HS2 fingerprint of the file FL1 transmitted in step S25, and possibly that the HS2 fingerprint is indeed in a data block corresponding to the part of the BCI1 identifier transmitted. If the test carried out in step S26 is positive, then the SRV server executes steps S27 and S28. In step S27, the SRV server executes the operation of writing the data DT received in the BC1 data block identified in step S26. In step S28, it transmits to the terminal T1 a report message (positive or negative) of the execution of the write operation. This report message is negative if, for any reason, the SRV server did not perform the write request. Write access rules for the BC1 data block may be specified in the data block or associated with it. In this case, the SRV server is limited to reading and ensuring that these rules are taken into account, in particular to refuse or accept a write in the BC1 data block.

Step S27 may constitute a first writing in the data block BC1. This case may arise for example when the identifier BCl1 is not recognized in step S26 by the SRV server.

According to one embodiment, the RG1 register is managed by a trusted third party, guaranteeing the integrity and authenticity of the register data.

According to another embodiment, the data block BC1 is a cryptographic blockchain. In this case, the step S5 of inserting the HS1 fingerprint into the data block BC1 and the step S27 of writing into the data block BC1 are performed by generating data of a new transaction in the data block of the blockchain, including the HS1 fingerprint.

According to one embodiment, the BCI1 identifier references a smart contract in a blockchain. In this case, the RQR read and/or RQW write requests may contain the reference of a function associated with the smart contract to be executed by the SRV server.

According to one embodiment, the HS1 fingerprint is signed by transmitting a request to a time server providing a legal timestamp, for example according to the RFC3161 standard. The time server provides a timestamp data which can also be inserted into the FL1 file in step S3. The digital signature of the HS1 fingerprint is also inserted into the BC1 data block in steps S5 and S27.

According to one embodiment, the functions described above for updating the BC1 block chain are performed by several servers, called "miners", executing the same operations in parallel, as is generally done when recording a transaction in a block chain. The operations performed by the servers are called "mining" operations. This arrangement makes it possible to ensure greater security, in particular with regard to the content of the RG1 register, which is also generated identically and securely by several servers.

According to one embodiment, the HS1 fingerprint is transmitted in step S4 with an identifier of a group of files to which the FL1 file belongs. This file group identifier can be inserted into the FL1 file, for example, in a metadata item in step S1 and be taken into account in the calculation of the HS1 fingerprint performed in step S2. The group identifier is inserted into the BC1 data block in step S5. In this way, a read request such as that RQR transmitted in step S14, and including this file group identifier, can make it possible to obtain from the SRV server the fingerprints of all the files belonging to the group corresponding to the transmitted file group identifier. The fingerprints can then be used to find the corresponding files belonging to the file group. These provisions make it possible, for example, to obtain the fingerprints of all the versions of the same file, or of all the files associated with a given keyword, without limitation. It is therefore possible to reproduce the usual mechanisms of electronic document management, without requiring that the documents be collected in a particular storage space.

According to one embodiment, the FL1 file contains program instructions, and the HS1 fingerprint is inserted into the FL1 file for example, in a program comment, in a section of the file intended to receive metadata in clear text (pdf, jpg), or at the end of a binary file (zip, exe).

According to one embodiment, the FL1 file contains program instructions, and an instance of the HS1 fingerprint is inserted into the FL1 file at a location allowing it to be taken into account by the program, for example to allow the display of an optical code (e.g. QR Code or "Quick Response Code") exactly identifying the file for example in a format such as HTML ("HyperText Markup Language") or pdf ("portable document format").

According to an exemplary embodiment, step S14 and/or S25 further comprises the transmission to the SRV server of program instructions appearing in the file FL1, for example in the part subject to the fingerprint calculation to obtain the HS1 fingerprint. The transmitted program instructions are to be executed by the SRV server to perform operations on the data block BC1.

The fingerprint, depending on its type, can constitute the marker alone to locate it in the FL1 file. This is the case, for example, when the metadata is of a sufficiently specific format to be located in the file using a regular expression. Thus, the marker can be a specific format, a specific character string known to appear in the identification metadata of a data block, regular separators, etc. The formatting can be known implicitly since it is defined by default, for example, a metadata consisting of the first 30 characters of the hexadecimal representation of a "SHA256" fingerprint, with a separator hyphen every 5 characters.

The marker is not necessarily at the location of the fingerprint in the file, but may indicate this location, for example relative to the start or end of the file, or relative to the position of the marker in the file. Thus the marker may be associated with information useful for locating the fingerprint, such as a position defined relative to the marker, or relative to the start or end of the file. The HS1 fingerprint may be inserted in the FL1 file in the form or in a metadata item used to identify the file. When the fingerprint or the metadata that contains it does not by itself allow the fingerprint to be located, the marker may be inserted in the file or the metadata item.

In addition, the HS1 fingerprint, depending on its type, can provide information on its own about the calculation or calculation algorithm or encoding that allowed its generation. The fingerprint can also be associated with a metadata specifying the name of the calculation algorithm used to generate the fingerprint, such as "md5", or "sha1", or the name of the encoding, such as "hex" (for hexadecimal), "b64" (for base 64), or "bubble-babble". In addition, the algorithm or encoding can be known implicitly since it is defined by default. If the HS1 fingerprint is inserted in a metadata, this fingerprint calculation type information can be inserted in the same metadata as the fingerprint. The metadata containing the fingerprint calculation type information can also be inserted in a protected section as described above.

According to one embodiment, the HS1 fingerprint is inserted into the FL1 file in association with or in the form of a digital signature generated by applying a signature calculation function to the fingerprint of the file and a private key of a public/private key pair. The verification of the digital signature may consist in applying a corresponding signature verification function, to the triplet comprising the HS1 fingerprint, the signature and the public key of the public/private key pair, to prove that the signature validly signs the HS1 fingerprint by the private key, the HS1 fingerprint contained in the file not being taken into account in the calculation of the fingerprint.

One or more metadata contained in the FL1 file may provide the parameters necessary for verification. These parameters may indicate the type of algorithm used to generate the fingerprint and/or digital signature. These parameters may provide the email address of a signer, and/or the corresponding public key or a derivation of the latter. In all cases, it is preferable that these metadata be taken into account in the calculation of the HS1 fingerprint.

In case the digital signature of the HS1 fingerprint is calculated, it can be transmitted to the server at step S14 and/or S25. This allows the SRV server to verify that the RQR and/or RQW request is issued by the signer of the file itself who may be the only legitimate one to do so.

According to one embodiment, steps S1 to S3 are performed by a trusted third party to whom the FL1 file has been previously transmitted, for example the SRV server. In this way, it is ensured that the HS1 fingerprint is indeed that of the FL1 file in which the BCI1 identifier taken into account for calculating the fingerprint is found. However, the generation of the fingerprint by a trusted third party may pose the problem of the confidentiality of the content of the FL1 file. Proof that the HS1 fingerprint has indeed been calculated on a part of the FL1 file containing the BCI1 identifier may also be provided by a zero-knowledge proof establishment protocol in which the entity generating the proof does not need to know the content of the FL1 file. Thus, the confidentiality of the content of the FL1 file can be ensured.

According to one embodiment, one of the metadata of the FL1 file may contain information taken into account when calculating the HS1 footprint.

According to one embodiment, certain metadata of the FL1 file are taken into account when calculating the HS1, HS2 footprint, and others are excluded from this calculation.

According to one embodiment, the calculation of the HS1 fingerprint (step S2) comprises the prior insertion of a predefined data item into the FL1 file, possibly at the location of the HS1 fingerprint in the file. In this case, the calculation of the HS1 fingerprint takes into account the bits of the predefined data item inserted into the file. In this case, the calculation of the HS2 fingerprint (step S12) comprises the prior insertion of the predefined data item into the FL1 file, in place of and replacing the HS1 fingerprint when the latter is inserted into the FL1 file.

According to one embodiment, the HS1 fingerprint is introduced into the FL1 file in several locations, the fingerprint being calculated by excluding the bits of the fingerprint in all the locations where the fingerprint is inserted. For this purpose, a mark serving as a reference can be inserted in several locations in the FL1 file, the HS1 fingerprint being calculated by excluding the mark or not, then inserted in place of the mark at these locations. Thus, the fingerprint can be inserted in a useful area of the FL1 file, for example to be able to be viewed when the content of the file is displayed, in particular in the case where the metadata is not displayed by the file display software.

To verify that the HS1 fingerprint in the file was indeed calculated from the FL1 file, a marker can be used to find a first location where the fingerprint was inserted in the file, and the fingerprint thus found can be used to search for all other occurrences of the fingerprint in the file. The HS2 fingerprint is then calculated by excluding all occurrences of the HS1 fingerprint in the FL1 file, the mark being, if applicable, previously inserted in place of the occurrences of the HS1 fingerprint found in the FL1 file.

According to one embodiment, steps S2, S3 are executed several times in cascade to insert several fingerprints into the file FL1. Thus, each execution of steps S2, S3 introduces into the file FL1 a new fingerprint HS1, calculated on the file in the state in which it is at the start of each new execution of steps S2, S3, the fingerprint(s) inserted previously being taken into account in the calculation of a new fingerprint which is then inserted into the file FL1.

By allowing several HS1 fingerprints to be inserted in a file in cascade, the method therefore allows, in addition to the possibility of using calculation algorithms already known to be resistant, to protect against "pre-image" attacks on a fingerprint in a very robust way by combining several fingerprints in the same file. Indeed, a "pre-image" attack should succeed, not only produce a file that has exactly and all the same fingerprints, and which moreover can validly pass for the original file. This attack is already very difficult to carry out when there is only one fingerprint to counterfeit, and becomes practically impossible with known technologies when several fingerprints are combined in cascade.

According to one embodiment, certain metadata of the FL1 file comprises an invariable part and a variable part, and only the variable part of a metadata is not taken into account for the calculation of the HS1 fingerprint.

It will be clear to those skilled in the art that the present invention is susceptible to various variant embodiments and various applications. Thus, the embodiments previously described must be considered as illustrations, and may be modified within the scope defined by the scope of the appended claims. In particular, the issuer of the read requests RQR and write requests RQW issued in steps S14 and S25 is not necessarily the terminal T1, but any entity authorized to carry out readings and/or writings in the data block BC1 of the register RG1, and where applicable, previously identified by the server SRV.

Furthermore, it is possible to link the FL1 file to several data blocks in the RG1 register or in different registers accessible via different servers. For this purpose, several data block identifiers can be inserted in the part of the FL1 file on which the HL1 footprint calculation is based.

Furthermore, since a cryptographic fingerprint is unique, the HS1 fingerprint alone may in many cases be sufficient for the SRV server to identify the BC1 data block to be accessed, since the HS1 fingerprint already appears in the data block, for example at the end of step S5. As a result, the BCI1 identifier of the BC1 data block inserted in the FL1 file may be configured to identify only the SRV server and/or the RG1 register. As a result, in certain cases, the BCI1 identifier does not need to be transmitted, including partially, in these requests in steps S14 and S25, but is only used to determine how to address the RQR and RQW requests to the SRV server.

More generally, the BCI1 identifier of the BC1 data block inserted in the FL1 file can be configured to identify only the BC1 data block where the HS1 fingerprint is located, or to identify both the BC1 data block and the SRV server which provides access to the data block, or to identify only the SRV server if the latter can locate the BC1 data block solely on the basis of the HS2 fingerprint which was transmitted to it.

Furthermore, the present invention does not only apply to the traceability of versions or owners of files, but covers a very large number of situations, particularly in electronic document management (key words, classification information, etc.), as well as in industry (transfer of responsibility for maintenance, changes of parts in an assembly, etc.).

Claims (14)

A method of associating variable data with a file, the method comprising steps of:
search, by a processor (T1), for a first location for inserting data into a file (FL1);
inserting, by the processor, at the first location in the file an identifier (BCI1) of a data block (BC1) of a register (RG1) accessible from a remote server (SRV), the data block storing variable data relating to the file;
calculating, by the processor, a first cryptographic fingerprint (HS1) relating to a part of the content of the file including the identifier of the data block, using a fingerprint calculation function (HSH), the first fingerprint depending on all the bytes of the part of the content of the file; and
transmit the first imprint by the processor to the remote server, the variable data being accessible by a request transmitted to the remote server, containing the first imprint. The method of claim 1, comprising the steps of:
receive via remote server (SRV) an access request (RQR, RQW) to the data block (BC1) containing the first fingerprint (HS1) of the file;
determine by the remote server whether a data block containing the first fingerprint is accessible; and
execute by the remote server the access request, and provide by the remote server to a transmitter (T1) of the access request a report of execution of the access request. The method of claim 2, wherein:
the access request is a read request (RQR), the execution of the access request by the remote server (SRV) comprising steps consisting in reading the data relating to the file identified by the first fingerprint (HS1) contained in the data block (BC1) and transmitting the read data to the sender of the access request, and/or
the access request is a write request (RQW) containing data to be written in the data block (BC1), the execution of the access request by the remote server (SRV) comprising steps of writing the data to be written in the data block. Method according to claim 3, in which the access request (RQR, RQW) is transmitted in association with authentication data of the sender (T1) of the access request, the execution of the access request by the remote server comprising steps of authentication by the server of the sender of the access request on the basis of the authentication data, the access request being executed by the remote server (SRV) only if the server has authenticated the sender of the access request. Method according to one of claims 1 to 4, comprising steps consisting of:
searching, by the processor (T1), for a second non-destructive insertion location of data in the file (FL1), the second location being outside the part of the content of the file on which the calculation of the first fingerprint is carried out; and
insert, by the processor (T1), the first fingerprint at the second location in the file. Method according to claim 5, in which the part of the content of the file (FL1) on which the fingerprint calculation function (HSH) is applied is defined:
by its extent in the file (FL1), or
by the extent of a part of the file (FL1) excluded from the footprint calculation. A method according to claim 5 or 6, comprising steps of:
calculating, by the processor (T1), a second fingerprint (HS2) relating to the part of the content of the file on which the calculation of the first fingerprint (HS1) relates, using the fingerprint calculation function (HSH); and
compare, by the processor (T1), the first fingerprint with the second fingerprint, and if the first and second fingerprints are not identical, then the link established by the file identifier is judged to be unintegrated by the processor (T1). Method according to one of claims 5 to 7, comprising steps consisting in inserting the fingerprint (HS1) in at least one other location in the file (FL1), the verification of the fingerprint comprising the application of the fingerprint calculation function (HSH) to the content of the file by excluding all occurrences of the fingerprint in the file. Method according to one of claims 1 to 8, comprising steps consisting of:
calculating, by the processor (T1), a digital signature of the first fingerprint (HS1) using a private key of a private and public key pair; and
inserting, by the processor, the signature in the file (FL1) outside the part of the file content on which the calculation of the first fingerprint is carried out, access to the data block (BC1) being conditioned by the provision to the remote server (SRV) of a valid digital signature verified using the public key of the private and public key pair. Method according to claim 9, in which the public key is inserted into a metadata in the part of the file (FL1) on which the calculation of the first fingerprint (HS1) relates. Method according to one of claims 1 to 10, in which the data block (BC1) referenced by the identifier (BCI1) is a chain of cryptographic blocks. Method according to one of claims 1 to 11, in which the calculation of each fingerprint (HS1, HS2) comprises a step of inserting a predefined data item into the part of the file content (FL1) before applying the fingerprint calculation function (HSH) to the part of the file. Computer program product comprising program file portions recorded on a computer-readable medium, configured to implement the steps of the method according to one of claims 1 to 12. Computer program product according to claim 13, wherein at least part of the program is included in the file (FL1).