METHOD FOR ENHANCED RECORDING OF A DIGITAL FILE ASSOCIATED WITH INTERNATIONAL DATA

Abstract

METHOD FOR ENHANCED RECORDING OF A DIGITAL FILE ASSOCIATED WITH INTERNATIONAL DATA The present invention relates to a method for recording a digital file (FI), - according to a private type blockchain method with proof of authority, - a first terminal (SSC) being equipped with an acquisition device (CAPD) for monitoring data (DS) of the terminal (SSC), - the recording of the digital file (FI) on a blockchain being done in the form of an evidence capsule (CP) comprising: - the file (FI), - monitoring data (DS) acquired by the acquisition device (CAPD) during the recording of the file (FI) on the first terminal (SSC), characterized in that the evidence capsule (CP) comprises international data (DI) transmitted from an international space, outside the borders of any State. Abstract figure: Fig. 3

Description

TITLE OF THE INVENTION

[0001] METHOD FOR ENHANCED RECORDING OF A DIGITAL FILE ASSOCIATED WITH INTERNATIONAL DATA FIELD OF THE INVENTION

[0002] The invention relates to the technical field of computerized storage of digital files and in particular to recording methods implementing blockchain methods. STATE OF THE ART

[0003] In the legal field, digital files can be used as evidence, for example to prove that a contract was actually signed by the parties. A digital photograph can also help prove that an event actually took place on a given date and in a given place, because the digital file of the photograph includes metadata such as a timestamp of the shot, or the geolocation of the shot.

[0004] However, computer technologies allow digital files to be modified, so that these digital files are easily contested and are difficult to accept as evidence, because their probative force is not sufficient. They are only considered as beginnings of evidence.

[0005] There are secure terminals in which physical monitoring of the terminal is carried out, for example by means of sensors placed on the terminal. However, it is the server itself that is monitored, not the data recorded on it. Some courts therefore refuse to consider files from this server as probative, because they consider that the files may have been falsified: - before they are stored on the server, even if the recording is carried out using blockchain methods, or - between the time the file is downloaded from the server and the time it is produced in court.

[0006] Furthermore, when the file storage server is located in a country or State other than that where the dispute is being heard, the particular jurisdiction of the State where the dispute is being heard may make it extremely complicated to have said file accepted as sufficient evidence: conditions of territoriality, generation of the file and location of data storage may be preponderant.

[0007] This situation may occur in particular in the event of hacking of one or more servers located in a country where a dispute is taking place: digital evidence to be produced before the court where the dispute is taking place must be provided by another server, located in a third country.

[0008] Finally, there are methods of recording a digital file using a blockchain method, in which the file is divided into shards whose data volume is defined by the data volume of a block in the chain, depending on the blockchain method used. The shards are then recorded in different blocks.

[0009] However, these methods use public, decentralized blockchains, for which the location of the servers, or computers, is random and therefore uncontrolled. The capture of the elements to be produced as evidence may be carried out in one country, but the elements may be necessary as evidence in a jurisdiction of another country. Consequently, a digital file stored in this manner may not be admissible before the jurisdiction of a given territory. In addition, the blockchain method used may be illicit in certain countries, depending on whether mining is implemented as a proof-of-authority algorithm. SUMMARY

[0010] One of the aims of the invention is to overcome the drawbacks of the prior art by proposing a method for recording a digital file guaranteeing its authenticity, that is to say guaranteeing the fact that this file has not been falsified.

[0011] Another aim of the invention is to be able to provide evidential digital files, which can be used as evidence from a legal point of view, including in an international context.

[0012] For this purpose, a method for recording a digital file has been developed, - using a private type blockchain method, - a first terminal being equipped with a device for acquiring terminal monitoring data, - recording the digital file on a blockchain in the form of a capsule of evidence including: - the file, - monitoring data acquired by the acquisition device when saving the file on the first terminal.

[0013] According to the invention, the evidence capsule comprises international data issued by a validator of the blockchain method, from an international space, outside the borders of any State.

[0014] In this way, the authenticity of the digital file is ensured by the association of the file and the monitoring data within the same block chain, which provides the expected probative force: in fact, it is not possible to modify or falsify the digital file and its monitoring data without this being detectable, because the digital fingerprints of the following blocks in the chain would no longer correspond to that of the block comprising modified data.

[0015] The falsification of files recorded with the method according to the invention is not possible, the "balance of probabilities" used by the majority of courts or jurisdictions therefore allows these files to be used as evidence.

[0016] Moreover, since the proof capsule includes data issued by the validator from an international space, its probative force no longer depends solely on States subject to a particular jurisdiction, but includes extraterritorial elements that escape geopolitical considerations, which avoids any doubt of interventionism, both technological and legal.

[0017] Even if the digital file is acquired within a first State, subject to regulations, the proof capsule includes data coming from a neutral territory.

[0018] By "digital file" we mean the digital file itself, or its digital fingerprint ("hash" in English). Indeed, smaller files can be stored directly within the blockchain. On the other hand, larger files can slow down transfers and copies of the blockchain because the storage volume of the latter will increase too quickly, as new capsules of evidence are recorded.

[0019] It is possible to record on the chain either a file or its fingerprint, depending on a test on the volume of the file to be stored. For example: - we store the file if it weighs less than 512KB, or else - the digital fingerprint is stored if the file weighs more than 512 KB.

[0020] It is also possible to share a digital file into several shards, each shard being stored in a block of the chain.

[0021] In the remainder of the document, the “digital file” is described, whether it is the file as such or its digital fingerprint.

[0022] Monitoring data means any type of data relating to the terminal (such as a serial number or a MAC address), or to its environment (such as environmental conditions), or to its use (such as the timestamp of the recording or an identification of its user, for example a biometric fingerprint).

[0023] International data can be of different natures: - This may involve geolocation data, making it possible to certify that the evidence capsule was created in an international zone. This case is particularly suited to embodiments in which the evidence capsule is stored on a server located in an international zone, known as an “international server”. - It may also involve a replication of data stored in the international server, making it possible to certify that the evidence capsule could only have been created with the cooperation of material not subject to national jurisdiction. This case is particularly suited to embodiments in which the evidence capsule is stored on a server located in a State, called a “national server”.

[0024] It is understood that a capsule comprises at least one digital file, but may also contain several. This may be, for example, photographs of each of the pages of a contract or files of different natures such as photographs, videos, and a database in the form of bits or qubits.

[0025] The method implemented for the invention is of the private proof of authority algorithm type, so that the registration of new blocks does not require mining, but the registration of new blocks can only be done on terminals approved and controlled by the proof of authority in interaction with their environment.

[0026] Thus, with the proof of authority method, trust in the deposited evidence files is based on a system based on upstream verification of the identity of the terminals. Generally speaking, such blockchain methods are known per se and will not be detailed further.

[0027] Unlike a public blockchain method, the method according to the invention does not require the intervention of a large number of nodes, nor of several replications of the blockchain in order to prove its authenticity: this is based on the integrity of the private proof of authority: - This allows, among other things, a substantial saving in the necessary storage space, because the blockchain is not duplicated unnecessarily on too many servers. - Furthermore, since new blocks and transactions are verified by pre-approved terminals, the proof-of-authority model relies on a limited number of block validators: the system according to the invention can easily be deployed on a large scale.

[0028] In a particular embodiment: - the validator located in an international space issues either an opening block comprising international data, or a closing block comprising international data, or an opening block and a closing block each comprising international data; - the first terminal, called the “national server”, is located within a State, and - the evidence capsule includes the opening block and / or the closing block. In this way, the international server can be the validator, and the first terminal can be located in a state. The international server does not need to store the entire blockchain including the proof capsules. Its storage capacity requirement is reduced. The probative value of the proof capsules is nevertheless preserved, since each capsule contains data issued by the validator.

[0029] By "opening block" is meant a block in the chain that defines the start of a new proof capsule. It is not a "genesis block", corresponding to the first block in a chain, according to the meaning commonly used in this field.

[0030] Advantageously, the validator comprises a storage memory configured to record the opening and / or closing block on a higher blockchain, and the validator is configured to issue a proof of authority token comprising the opening and / or closing block. Thus: - the recording of opening and closing blocks is secure; - the issuance of a proof of authority token makes it possible to guarantee the authenticity of a proof capsule stored within a State, by comparison between: - the opening block data contained in the proof of authority token, with - the opening block data contained in the proof capsule. If the data is identical, then the authenticity of the proof capsule, as well as the integrity of the private blockchain method, is guaranteed. The same operation applies to the closing block.

[0031] In order to increase the probative force of the private blockchain method, the validator comprises a device for acquiring validator monitoring data, and the opening and / or closing block comprises the validator monitoring data. In this way, the bundle of indices, attesting to the authenticity of the proof capsule and especially, where applicable, of the proof of authority token, is reinforced.

[0032] In an embodiment adapted to nomadic use cases: - a second terminal acquires the file and additional monitoring data, then - the second terminal transmits the file and the additional monitoring data to the first terminal, and - the first terminal records the file and the additional monitoring data in the form of an evidence capsule comprising the file, the additional monitoring data of the second terminal and the monitoring data of the first terminal. Thus, file acquisition can be performed at multiple locations, and recording is centralized, making it easier to protect and monitor its integrity, compared to a multitude of second terminals. The second terminal is preferably a mobile terminal.

[0033] In order to ensure that the data is not tampered with before being recorded on the first terminal, the evidence capsule may be recorded on a remote blockchain on the second terminal, before being transmitted to the first terminal which records it in a local blockchain. Recording on a blockchain upon acquisition of the file prevents tampering operations, and this from its ac quisition. Since the blockchain method is private, it is possible to generate multiple remote blockchains in parallel for multiple second endpoints. The authenticity of each chain is guaranteed by the integrity of the proof of authority. The remote blockchain can therefore be built and evolve in a manner complementary to the local blockchain.

[0034] Still for the purpose of security, the evidence capsule may comprise an opening block and / or a closing block each issued by the first terminal, which are integrated into the capsule when it is recorded on the second terminal, and which limit the file and the additional monitoring data. In this way, the evidence capsule cannot be recorded on the second terminal without the first terminal having authorized it, by issuing an opening block and / or a closing block. The use of the opening block and the closing block also allows the first terminal to monitor the state of the second terminal. It is for example possible to detect if a second terminal has not been synchronized for too long.

[0035] The local blockchain and the remote blockchain each evolve in parallel, but mixing the data from the local blockchain with that from the remote blockchain makes it possible to strengthen the security of the whole.

[0036] In order to strengthen the admissibility of the digital file in the courts of several States, or countries, the capsule of evidence is transmitted simultaneously from the second terminal to the first terminal as well as to several auxiliary terminals located in several jurisdictions. The auxiliary terminals are similar to the first terminal and operate in an equivalent manner. The term "auxiliary terminal" is used only to differentiate these additional terminals from the first terminal, but in practice the first terminal and the auxiliary terminals are equivalent. They preferably operate in parallel, without a master / slave hierarchy.

[0037] In the case where the method implements auxiliary terminals, the evidence capsule further comprises opening blocks and / or closing blocks, each issued by the auxiliary terminals. The evidence capsule cannot be generated without involving the terminal present in each of the jurisdictions concerned. The probative force is further increased because the quantity of data included in the capsule's blockchain is increased. Falsification of the capsule would require intervention on each of the terminals, which is not feasible in practice. In addition, since the evidence capsule is considered to originate from the Country where it is registered, it is considered to be directly admissible in each of the jurisdictions where one of said terminals is located without it being necessary to implement multilateral treaties such as the Hague Convention of March 18, 1970.

[0038] To facilitate communication of the evidence capsule to a third party, for example to a judge, or even an insurer, each terminal is configured to issue a token corresponding to the evidence capsule, i.e. a unique digital file corresponding to said capsule. Advantageously, the issuance of a token is recorded in the blockchain.

[0039] Preferably, each token is unique and non-fungible. For the same storage volume reasons mentioned above: - the token may include the evidence capsule if its volume is limited, or - the token may include identification data to attest to its correspondence with the evidence capsule stored on a server, if the volume of the evidence capsule is too large.

[0040] Preferably, the validator is located in a location that is as difficult to access as possible, to prevent any physical attack. An effective way to prevent a hardware attack or physical access to the validator is to place it in a satellite in Earth orbit. The same principle applies to the international server.

[0041] In the case where the validator is placed in a satellite, communication between the validator and the first terminal is advantageously of the free space optical communications type. Thus, it is not possible to intercept the light beam without this attack being detected. This mode of communication is therefore more secure than communication by radio for example.

[0042] Advantageously, the file and the monitoring data are erased from a memory of the second terminal after having been transmitted to the first terminal. This makes it possible to guarantee the protection of sensitive data, such as personal data, in the event that the second terminal is stolen. This also makes it possible to manage the saturation of the storage memory of the second terminal.

[0043] To verify the good integrity of the terminals, the acquired monitoring data can be compared to an expected monitoring data, and a difference between the acquired monitoring data and the expected monitoring data triggers an alert to a proof of authority of the blockchain.

[0044] The invention also relates to a system comprising: - a validator located in an international space and configured to transmit international data to a first terminal, - the first terminal comprising: - means of receiving evidence data, such as a photo sensor or a network card; - means of acquiring monitoring data, such as a GPS sensor; - data storage means, such as a hard drive or SD card; - a computer program programmed to record a chain of blocks on the storage means, and to implement a method according to the characteristics aforementioned.

[0045] The invention finally relates to a digital token originating from a terminal for storing a digital file, the file being stored using a blockchain method, and the token comprising a proof capsule itself comprising: - the digital file; - monitoring data acquired when saving the file; - international data transmitted from international space.

[0046] Such a token makes it possible to guarantee that the file contained has not been tampered with since its acquisition. Brief description of the drawings

[0047] [Fig. 1] is a diagram illustrating a first embodiment in which a validator is in an international zone, and a first terminal is located within a State.

[0048] [Fig.2] is a diagram illustrating a second embodiment, in which the first terminal is in an international zone and performs the validator function, and the digital file is acquired by a second terminal.

[0049] [Fig.3] is a diagram illustrating a third embodiment, in which the va The lidator is located in the international zone, exchanges data with the first terminal located in the national zone, and the first terminal exchanges data with a second terminal configured to acquire the digital file.

[0050] [Fig.4] is a diagram illustrating a fourth embodiment, alternative to the third embodiment, wherein the validator communicates with the second terminal, and the second terminal communicates with the first terminal.

[0051] [Fig.5] is a simplified diagram illustrating a fifth embodiment which is a variant of the third embodiment implementing several validators and several terminals. DETAILED DESCRIPTION

[0052] With reference to [Fig.l], the method according to the invention essentially consists of recording on a memory (DQ) of a first terminal (SSC), and within the same local block chain (BU), a digital file (FI) associated with surveillance data (DS) as well as international data (DI).

[0053] Several surveillance data (SD) can be used to constitute a bundle of evidence. The more complete the bundle of evidence is, the greater the probative force of an evidence capsule (CP) containing the digital file (FI) is reinforced.

[0054] The monitoring data (DS) can therefore include, in a non-limiting manner: - a MAC address of the first terminal (SSC), making it possible to detect the generation of a falsified file from another terminal; - geolocation of the first terminal (SSC); - reading a fingerprint sensor from a second terminal (APP), making it possible to certify who was the user of the second terminal (APP) when acquiring the file (FI) - or even a combination of several data.

[0055] The blockchain method being of the private type, each terminal or server involved in the method has been approved by the proof of authority of the method, and is itself a “validator” of the blockchain method implemented, according to the terminology used in the technical field considered.

[0056] Nevertheless, international data (ID) is preferably issued by a higher-ranking validator (POA), specifically dedicated: - to the emission of international data (ID), - to the administration and writing permissions granted to other validators of the blockchain method. In the remainder of the document, the term “validator” will only refer to the highest-ranking validator (POA).

[0057] International data (ID) can be of different types: - it may be data whose international character is intrinsic, such as data from the geolocation of the validator (POA) at the time of the emission of the international data (DI): the simple reading of the geolocation data is sufficient to certify that the international data (DI) was emitted from a place located outside the borders of any State. - it may be data whose international character is extrinsic, such as a validator hardware identifier (POA), such as its MAC address: in this case, it is the comparison between the international data (ID) included in a proof capsule (PC) and the validator identifier (POA) which makes it possible to attest to the international character of the international data (ID).

[0058] One way to make the comparison may include the following steps: - the validator (POA) generates an international seal (IS), preferably unique; - the validator (POA) stores the international seal (IS) within a superior blockchain (MB) of the validator (POA); - the international data (DI) includes an imprint of the international seal (SI) or an encryption of the international seal (SI), which the validator (POA) generates and transmits to the first terminal (SSC).

[0059] When producing a proof capsule (PC) before a court, the probative force as well as the international character of the proof capsule (PC) can be proven by returning the international data (ID) to the validator (POA): the validator (POA), holder of the key which made it possible to generate the international data (ID) from the international seal (IS), attempts to decode the international data (ID) which is submitted to it: - if the decoding works, or if the decoding of the international data (ID) matches the international seal (IS) stored in the upper blockchain (MB), then the proof capsule (PC) is authentic, and its international character is proven. - if the decoding fails, or if the decoded data is not readable, or if the decoding of the international data (ID) does not match the international seal (IS), then the proof capsule (PC) is not authentic and comes from an attempted forgery. This forgery is nevertheless detected without difficulty.

[0060] This comparison method therefore allows the international validator (POA) to intervene during the production of the proof capsule (PC). This additional intervention by the validator (POA) adds a level of verification to strengthen the probative force of the proof capsule (PC), and also makes it possible to avoid the difficulties that the particular jurisdiction of a State could raise.

[0061] The geolocation of the validator (POA) can be obtained by known means, such as geo-positioning by satellite “GPS”, or even two-line orbital parameters (“TLE” according to the English “Two-Line Elements”).

[0062] The presence of international data (ID) issued by the validator (POA) of the blockchain method, within each proof capsule (PC), makes it possible to not make the proof of authority dependent on any State. In this way, each proof capsule (PC) is admissible to an institution before which it is produced, regardless of the State where this institution is located.

[0063] The first terminal (SSC) is capable, by means of the program that it executes, of issuing proof tokens (NFP) comprising the proof capsule (CP). The proof token (NFP) also comprises additional data (DAdd), added during the issuing of the proof token (NFP). The additional data (DAdd) may be, for example, a timestamp of the issuing of the token, an identifier of the user session having ordered the issuing of the proof token (NFP), etc.

[0064] The addition of additional data (DAdd) responds to the same need to strengthen the probative force, by adding elements to the bundle of evidence.

[0065] Several proof tokens (NFP) of the same capsule (CP) can be issued, but each time it is a copy, and each proof token (NFP) is non-fungible because it includes additional data (DAdd) which is specific to it. Proof tokens (NFP) are nevertheless transmissible.

[0066] The proof capsule (CP) is thus scalable: each transaction carried out, for example the transfer of the proof capsule (CP) from one terminal (APP, SSC) to another is recorded, and is traceable by means of this additional data (DAdd). When a proof token (NFP) is issued, it is therefore possible to trace the entire block chain contained in the proof token (NFP) and know on which terminal (APP, SSC) the capsule (CP) was acquired, stored, and at what time each transaction took place.

[0067] [Fig.l] also illustrates an embodiment in which the validator (POA) issues an opening block (Op) and a closing block (Cl), included in the record of the proof capsule (CP) on the first terminal (SSC). In this mode, the opening block (Op) and the closing block (Cl) comprise the international data (DI).

[0068] The entanglement of the blocks generated by the validator (POA) and by the server (SSC) protects the file (FI) from falsification.

[0069] By "opening block" is meant a block in the chain that defines the start of a new proof capsule (PC). It is not a "genesis block", corresponding to the first block in a chain in the sense commonly used in this field. The same applies to the "closing block".

[0070] The opening block (Op) and the closing block (Cl) may be complete blocks of the local blockchain (BU). Alternatively, the entanglement of the upper blockchain (MB) and the local blockchain (BU) may be achieved by exchanging only digital fingerprints (hash in English), in order to limit the volume of data exchanged. In the remainder of the document, the terms "opening block" and "closing block" cover these two embodiments.

[0071] In order to perfect the security of the method, the opening blocks (Op) and the closing blocks (Cl) include encrypted data whose security is reinforced by a method called “salting”, that is to say that data is added to the block before hashing, thus avoiding the risk of attacks.

[0072] Advantageously, the salting is dynamic, the added data being generated by a mathematical method (pseudo-random data), or preferably the added data are generated by a quantum computer (random data).

[0073] Preferably, the opening block (Op) is a block comprising: - encrypted and unique data, allowing the opening block (Op) to be identified, - international data (ID), - monitoring data (DS) acquired by a sensor (CAPD) of the validator (POA) during the emission of the opening block (Op), in order to constitute a bundle of indices attesting that the opening block (Op) is conclusive.

[0074] It is recalled that the opening block (Op) and the closing block (Cl) have a similar operation, and that the detailed technical characteristics for the opening block (Op) also apply to the closing block (Cl).

[0075] The opening block (Op) and the closing block (Cl) are also recorded on the upper block chain (MB) of the validator (POA), when they are issued. This makes it possible to keep a trace of them, in particular if the international data is extrinsic, and it is necessary to compare the international data (DI) contained in a proof capsule (CP) with international data (DI) contained in a memory (DQ) of the validator (POA).

[0076] In order to be able to carry out the comparison of the international data (DI) stored in the validator (POA) with those contained in the proof capsule (CP), the validator (POA) is programmed to issue an authority token (PT) comprising the international data (DI).

[0077] The Authority Token (PT) is issued in a similar manner to the Proof of Possession Token (NFP) and is therefore encrypted.

[0078] When issuing such an authority token (PT), additional data (DAdd) is added to its string, so that each authority token (PT) is non-fungible, and probative.

[0079] The validator (POA) is preferably arranged within a satellite, placed in orbit around the Earth. This solution makes it possible to secure the validator (POA) against a physical or material attack, due to its inaccessibility.

[0080] The communication between the validator (POA) and the first terminal (SSC) preferably comprises free-space optical communications, for example by laser. This type of communication prevents a third party from being able to intercept the communication signal, without the proof of authority of the method being able to detect it.

[0081] The validator (POA) can also be placed in international waters, whether: - on the surface, for example on a stationary vessel, or - underwater, for example in a submerged server placed on the seabed.

[0082] The first terminal (SSC) is equipped with means for acquiring monitoring data (CAPD), for example any sensor or any suitable reading means.

[0083] The first terminal (SSC) is also equipped with file acquisition means (CAPF), for example a photographic sensor, or a means of communication allowing it to receive the digital file (FI) transmitted by another terminal.

[0084] Of course, the first terminal (SSC) comprises a rewritable storage memory (DQ) for recording the digital file (FI) as well as the monitoring data (DS), and executes a computer program, programmed to carry out the acquisitions, the recordings and the steps of the method described.

[0085] The computer program may include subroutines or execute third-party applications, for example to control the sensor (CAPF) of the file (FI) or the sensor (CAPD) of the monitoring data (DS).

[0086] With reference to [Fig.2], the proof capsule (CP) as such may be recorded within a server (SSC) located in an international zone. In this case: - the first terminal (SSC) plays the role of validator (POA), - the digital file (DF) and the associated monitoring data (MD) are acquired by a second terminal (APP), - the second terminal (APP) transmits the digital file (FI) and the monitoring data (DS) acquired to the first terminal (SSC), - when recording the digital file (FI) and the surveillance data (DS), the first terminal (SSC) transmits international data (DI) so that they are integrated into the proof capsule (CP).

[0087] The second terminal (APP) is similar to the first terminal (SSC) in that it comprises digital file acquisition means (CAPF), monitoring data acquisition means (CAPF), a rewritable storage memory (DQ), and that it executes a computer program programmed to implement the steps described.

[0088] In order to simplify the following explanations, the first terminal (SSC) will be referred to as the “server”, and the second terminal (APP) as the “device”. Indeed, although the first terminal (SSC) and the second terminal (APP) can be of any suitable type, a preferred mode is to use a server (SSC) to which several mobile devices (APP) of the smartphone type are connected, the connection between the device (APP) and the server (SSC) preferably being made via the Internet network and / or via a mobile telephone network.

[0089] Preferably, the device (APP) is also capable of issuing proof of concept (NFP) tokens.

[0090] The use of a device (APP) makes it possible to acquire the files (FI) remotely, possibly using several devices (APP), but to save them centrally on the server (SSC).

[0091] In the mode illustrated in [Fig.2], the device (APP) does not record the file (FI) and the monitoring data (DS) in the form of a block chain and transmits them directly to the server (SSC).

[0092] As an alternative not shown, the device (APP) records the file (FI) and the monitoring data (DS) on a remote blockchain (MBL), in a memory of the device (APP).

[0093] In the mode of [Fig.2], the evidence capsule (CP) is therefore generated directly on the device (APP), and the file (FI) and the monitoring data (DS) are transmitted to the server (SSC) in the form of an evidence capsule (CP).

[0094] This mode makes it possible to guarantee that the file (FI), as soon as it is acquired on the device (APP), is not falsified without this being detectable by the analysis of the capsule's block chain (CP).

[0095] When the capsule (CP) is transmitted to the server (SSC), the latter records it on its local blockchain (BU).

[0096] This embodiment allows for all of the proof capsules (PCs) to be stored within an international zone. There are no servers located within a state.

[0097] With reference to [Fig.3], one embodiment of the invention comprises: - a validator (POA) placed in an international space; - a server (SSC) located within a State, and receiving the international data (DI) issued by the validator (POA), preferably in the form of opening (Op_POA) and closing (C1_POA) blocks; - a device (APP) configured to acquire the digital file (FI) and the monitoring data (DS).

[0098] In this mode: - The validator (POA) issues the opening block (Op_POA), and records it within a higher blockchain (MB), then - the first server (SSC): - integrates the opening block (Op-POA) of the validator (POA) within a local blockchain (BU); then - itself issues its own opening (Op_SSC) and closing (C1_SSC) blocks to the device (APP).

[0099] Thus, when the device (APP) writes a proof capsule (CP) on a remote blockchain (MBL), the proof capsule (CP) comprises: - the opening block (Op_POA) of the validator (POA), and which integrates international data (DI), - the opening block (Op_SSC) of the server (SSC), - the digital file (FI), - monitoring data (DS) acquired during recording of the digital file (FI), - the closing block (C1_SSC) of the server (SSC).

[0100] The device (APP) can then transmit the proof capsule (CP) to the server (SSC). During this transmission, additional data (DAdd) is added to the proof capsule (CP).

[0101] When the server (SSC) writes the proof capsule (CP) to the local blockchain (BU), the proof capsule (CP) includes: - the aforementioned data; - additional data (DAdd) added when the evidence capsule (CP) is sent by the device (APP) to the server (SSC); - preferably, monitoring data (DS) acquired by the server (SSC) at the time when the server (SSC) performs the registration; - the closing block (C1_POA) of the validator (POA), which also integrates international data (DI).

[0102] In this way, there is an entanglement of three blockchains in parallel. Hacking one of the blockchains is therefore greatly complicated. The use of opening blocks (Op) as well as closing blocks (Cl) multiplies the points of entanglement between the chains.

[0103] The use of opening (Op) and closing (Cl) blocks further allows the proof of authority of the blockchain to verify the behavior of a terminal (SSC, APP).

[0104] For example, the creation of a new capsule (CP) on the device (APP) may only be possible if the server (SSC) issues the opening block (Op). A device (APP) that is stolen could therefore be rendered inoperable, if the server (SCC) stops providing it with opening blocks (Op).

[0105] Similarly, the use of a closing block (Cl) makes it possible to authorize the return of a capsule (CP) to the server (SSC) only if control operations have been carried out: for example, if the device (APP) does not include biometric data sensors, the identity of the user of the device (APP) could be verified by another means before triggering the sending of the closing block (Cl) by the server (SSC).

[0106] The use of an opening block (Op) and a closing block (Cl) also makes it possible to verify that the capsule (CP) was indeed generated during a predefined time window, which further reinforces the security and probative force of the capsules (CP) generated.

[0107] This mode also allows to prepare proof capsules (CP) on the device (APP) even if it is offline and cannot communicate with the server (SSC): - the opening block (Op) is generated and then recorded on the remote blockchain (MBL) when the connection is established; then - the file (FI) and monitoring data (DS) are added to the remote blockchain (MBL) even if the device (APP) is offline; then - the closing block (Cl) is recorded on the remote blockchain (MBL) when the connection between the device (APP) and the server (SSC) is reestablished.

[0108] The Evidence Capsule (EC) is only uploaded to the server (SSC) when the connection is reestablished.

[0109] The evidence capsules (CP) can therefore be prepared offline on the device (APP), by acquiring the files (FI) and the monitoring data (DS), while waiting for the capsules (CP) to be completed with the closing block (Cl) as soon as the connection with the server (SSC) is reestablished.

[0110] The same advantages are obtained concerning the exchanges between the validator (POA) and the server (SSC), when opening (Op_POA) and closing (C1_POA) blocks issued by the validator (POA) are used.

[0111] The opening (Op_POA) and closing (C1_POA) blocks issued by the validator (POA) within the proof capsule (CP) constitute an additional validation of the registration on the blockchain, and originating from a neutral territory even though the digital file (FI) was recorded within a jurisdiction subject to regulation. This additional validation reinforces the security and probative force of operations subject to territorial validations, by adding an extraterritorial and neutral validation.

[0112] [Fig.4] illustrates an alternative mode in which the validator (POA) provides the blocks opening (Op) and closing (Cl) directly to the device (APP), so that the proof capsule (CP) is formed directly at the device (APP).

[0113] The device (APP) then provides the evidence capsule (CP) to the server (SSC) for archiving.

[0114] In this mode, it is possible for the server (SSC) to also provide opening (Op) and closing (Cl) blocks to the device (APP).

[0115] [Fig.5] illustrates a preferred embodiment in which: - several validators (POA1, POA2) each provide international data (ID), preferably within opening (Op_POA) and closing (C1_POA) blocks; - the file (FI) is acquired on a device (APP), which saves it with the monitoring data (DS) on a remote blockchain (MBL); - the proof capsule (CP) is recorded on several servers, namely a server (SSCI) and an auxiliary terminal (SSC2); - the registration of the capsule (CP) is subject to the emission of opening (Op) and closing (Cl) blocks by each of the servers (SSC) and validators (POA1, POA2).

[0116] In practice, the auxiliary terminal (SSC2) is preferably another server equivalent to the first terminal (SSCI). There is no hierarchy between these servers (SSCI, SSC2), and they operate in a similar manner.

[0117] A plurality of servers (SSC) makes it possible to duplicate backups of proof capsules (CP) and to distribute servers (SSC) within several States. However, the method implemented is private. It is not a so-called "distributed" method, in which the proof of authority algorithms are based on proof of work ("mining") or proof of stake.

[0118] Closing blocks (C1_POA) can be issued by validators (POA1, POA2): - either upstream of the communication of the evidence capsule (CP) from the device (APP) and to the servers (SSCI, SSC2); - either downstream of this communication, in order to validate the recording of the proof capsule (CP) received.

[0119] The capsule (CP) being recorded on several servers (SSC), it is duplicated and there are now as many capsules (CP) as there are servers (SSC).

[0120] This mode guarantees: - that the generation of the capsule (CP) was authorized, because the opening blocks (Op) were issued by the servers (SSC) and the validators (POA); - that the integrity of the device (APP) was recognized, because the closing blocks (Cl) were issued by the servers (SSC); - that the integrity of the servers (SSC) was recognized, because the closing blocks (Cl) were issued by the validators (POA); - that the digital file (DF) will be admissible as evidence in each State because the evidence capsule (EC) contains international data (ID) - that the admissibility of the digital file (FI) will be reinforced in each State where the servers (SSC) are located, because each of these servers (SSC) participated in the generation of the capsule (CP): - from its origin, via the emission of opening blocks (Op); and - until its registration on the servers (SSC), via the emission of closing blocks (Cl).

[0121] The presence of international data (ID) within each evidence capsule (EC) is already an element ensuring enhanced security and therefore greater admissibility within each State, but the fact that the evidence capsule (EC) is also recorded on a server (SSC) located within a particular State makes its admissibility to the authorities of that State incontestable, even though the criteria for accepting evidence there are very high.

[0122] When issuing a proof token (NFP) by one of the servers (SSC), we see that it includes: - the file (FI) whose authenticity is to be proven; - the monitoring data (DS) of the device (APP) having acquired the file (FI); - international data (DI), within the opening and closing blocks (Op, Cl) of each of the validators (POA); - each opening and closing block (Op, Cl) of each of the servers (SSC) involved; - monitoring data (DS) guaranteeing the integrity of the server (SSC2) from which the proof token (NFP) comes; - additional data (DAdd) added when issuing the proof token (NFP) by the server (SSC2).

[0123] Such a proof token (NFP) therefore comprises the file (FI) whose authenticity is to be proven, and a set of bundles of indices mixing data relating to each transaction carried out by the method, since the authorization of the acquisition of the file (FI) on the device (APP) until its production in court.

[0124] The number of servers (SSC) is not linked to the number of validators (POA).

[0125] Several servers (SSC) allow replication of backups of proof capsules (CP), as well as the presence of one of said backups in each of the territories where it will be necessary to produce proof.

[0126] Several validators (POA) make it possible to make the operation of the overall system more reliable, since a breakdown of a validator will necessarily be more complicated to repair, given the difficulty of accessing the validators (POA).

[0127] Furthermore, in the case of validators (POA) arranged in a satellite, it may be interesting to implement a satellite with a scrolling orbit, in order to limit costs: a single validator (POA) can scroll around the Earth's globe and successively exchange data with the different servers (SSC) above which it scrolls, as it goes.

[0128] In practice, a limited number of validators (POA), for example 3 or 5, makes it possible: - to limit the time interval between two passages of a validator (POA) with regard to a server (SSC), when the validators (POA) are each arranged in a satellite; - to constitute a replication of data recorded by the validators (POA), which is necessary to guarantee the durability of a backup; - preferably, an odd number of validators (POA) allows for a voting system to be set up between validators (POA) when it comes to authorizing or not the registration of a new block by a server (SSC): an odd number of validators (POA) guarantees that the vote does not provide a tie.

[0129] Like the management of a loss of connection between a device (APP) and a server (SSC), the disclosed method provides for the management of a loss of connection between a server (SSC) and a validator (POA): the registration of new blocks is put on hold until a validator (POA) verifies the conformity of the data to be registered, then authorizes the registration of the blocks in question by issuing a closing block (Cl-POA).

[0130] The verification carried out by the validator (POA) may include the verification of the time elapsed since the emission of the opening block (Op), the correct correspondence between the data of the opening block (Op) included in the proof capsule (CP) and the data of the opening block (Op) included in the memory (DQ) of the validator (POA), or even a comparison between the acquired monitoring data (DS) and an expected monitoring data (DS ref).

[0131] Indeed, in all embodiments, a comparison between the acquired monitoring data (DS) and an expected monitoring data (DS ref) is possible, and makes it possible to verify the integrity of the terminal used, whether it is the device (APP), server (SSC) or validator (POA).

[0132] The comparison can be for example: - a difference between the timestamp contained in the monitoring data (DS) of the terminal (SCC) and the timestamp contained in the additional data (DAdd) of the capsule (CP) emission: too great a difference may mean that the time of the device (APP) has been modified, for example in order to backdate a capsule (CP); - a comparison between the opening and / or closing blocks (Op, Cl) emitted by the server (SSC) and those contained in the capsules (CP) emitted by the device (APP): if the same block (Op, Cl) comes back several times, this could mean that a malicious user is trying to send fake capsules (CP) back to the server (SSC) whose generation has not been authorized.

[0133] When a difference is found, an alert is issued to the proof of authority. The proof of authority can then lock or quarantine the offending validator (POA), device (APP) or server (SSC).

[0134] It is recalled that the implemented blockchain method being of type "private method", all terminals implemented must be approved by the proof of authority to be able to execute the programs necessary to implement the method. The installation and / or operation of programs installed on servers (SSC), devices (APP) and validators (POA) is therefore subject to the proof of authority which authorizes or prevents the registration of blocks on the different chains (BU, MBL, MB).

[0135] Furthermore, the method and the proof token (NFP) may be configured differently from the examples given without departing from the scope of the invention, which is defined by the claims.

[0136] In a variant not shown, the file (FI) and the monitoring data (DS) are deleted from the device (APP) after having been transmitted to the server (SSC), whether the device (APP) includes a remote blockchain (MBL) or not.

[0137] In the first case, the remote blockchain (MBL) can be completely deleted from the device, in which case a new initialization block of the remote blockchain (MBL) must be provided to the device (APP) by the proof of authority.

[0138] Otherwise, only the blocks comprising the file (FI) and the monitoring data (DS) are deleted (as well as any downstream blocks in the chain), so that a new sequence of blocks can be created based on the remaining remote block chain (MBL).

[0139] In the case where the files (FI) include personal information, the deletion of the file (FI) from the device (APP) facilitates in particular the compliance of the process with the general regulation for the protection of personal data (GDPR).

[0140] To protect the confidentiality of the file (FI), the data can be saved in encrypted form.

[0141] Furthermore, the technical characteristics of the different embodiments and variants mentioned above can be, in whole or in part, combined with each other. Thus, the invention can be adapted in terms of costs, functionalities and performances.

Claims

Claims

1. Method for recording a digital file (FI), - according to a private type blockchain method with proof of authority, - a first terminal (SSC) being equipped with an acquisition device (CAPD) for monitoring data (DS) of the terminal (SSC), - the recording of the digital file (FI) on a blockchain being done in the form of an evidence capsule (CP) comprising: - the file (FI), - monitoring data (DS) acquired by the acquisition device (CAPD) during the recording of the file (FI) on the first terminal (SSC), characterized in that the evidence capsule (CP) comprises international data (DI) issued by a validator (POA) of the blockchain method, from an international space, outside the borders of any State.

2. Method according to claim 1, in which: - the validator (POA) located in an international space emits an opening block (Op) comprising international data (DI) and / or a closing block (Cl) comprising international data (DI), and - the first terminal (SSC) is located within a State, and the evidence capsule (CP) comprises the opening block (Op) and / or the closing block (Cl).

3. Method according to claim 2, wherein: - the validator (POA) comprises a storage memory configured to record the opening (Op) and / or closing (Cl) block on a higher block chain (MB), and - the validator (POA) is configured to issue an authority token (PT) comprising the opening (Op) and / or closing (Cl) block.

4. Method according to one of claims 2 or 3, in which the validator (POA) comprises an acquisition device (CAPD) for monitoring data (DS) of the validator (POA), and the opening (Op) and / or closing (Cl) block comprises the monitoring data (DS) of the validator (POA).

5. Method according to one of claims 2 to 4, in which: - a second terminal (APP) acquires the file (FI) and additional monitoring data (DS), then - the second terminal (APP) transmits the file (FI) and the additional monitoring data (DS) to the first terminal (SSC), and - the first terminal (SSC) records the file (FI) and the additional monitoring data (DS) in the form of an evidence capsule (CP) comprising the file (FI), the additional monitoring data (DS) of the second terminal (APP) and the monitoring data (DS) of the first terminal (SSC).

6. Method according to one of claims 2 to 5, in which the proof capsule (CP) is recorded on a remote blockchain (MBL) on the second terminal (APP), before being transmitted to the first terminal (SSC) which records it in a local blockchain (BU).

7. Method according to one of claims 2 to 6, in which the evidence capsule (CP) is transmitted from the device (APP) to several auxiliary terminals located in several jurisdictions.

8. Method according to one of claims 2 to 7, in which each terminal (APP, SSC) is configured to issue a proof token (NFP) comprising the proof capsule (CP).

9. Method according to one of claims 2 to 8, in which the validator (POA) is arranged in a satellite in Earth orbit, and a communication between the validator (POA) and the first terminal (SSC) is of the type of free space optical communications.

10. System comprising: - a validator (POA) located in an international space and configured to transmit international data (DI) to a first terminal (SSC), - the first terminal (SSC) comprising: - means for receiving evidence data (CAPF), such as a photo sensor or a network card; - means for acquiring surveillance data (CAPS), such as a GPS sensor; - data storage means (DQ), such as a hard disk or an SD card; - a computer program programmed to record a chain of blocks on the storage means (DQ), and to implement a method for recording an evidence capsule (CP) according to one of the preceding claims.

11. Digital proof token (NFP) from a terminal for storing a digital file (FI), the file (FI) being stored using a method by blockchain, characterized in that the proof token (NFP) comprises a proof capsule (CP) comprising: - the digital file (FI); - monitoring data (DS) acquired when saving the file (FI); - international data (ID) issued from international space.

Images