FR3136565A1 - Procédé d’enregistrement renforcé d’un fichier numérique - Google Patents
Procédé d’enregistrement renforcé d’un fichier numérique Download PDFInfo
- Publication number
- FR3136565A1 FR3136565A1 FR2205508A FR2205508A FR3136565A1 FR 3136565 A1 FR3136565 A1 FR 3136565A1 FR 2205508 A FR2205508 A FR 2205508A FR 2205508 A FR2205508 A FR 2205508A FR 3136565 A1 FR3136565 A1 FR 3136565A1
- Authority
- FR
- France
- Prior art keywords
- capsule
- terminal
- file
- ssc
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 239000002775 capsule Substances 0.000 claims abstract description 172
- 238000012544 monitoring process Methods 0.000 claims abstract description 55
- 239000008186 active pharmaceutical agent Substances 0.000 claims abstract description 35
- WQZGKKKJIJFFOK-GASJEMHNSA-N Glucose Chemical compound OC[C@H]1OC(O)[C@H](O)[C@@H](O)[C@@H]1O WQZGKKKJIJFFOK-GASJEMHNSA-N 0.000 claims abstract description 4
- 238000004590 computer program Methods 0.000 claims description 5
- 238000013500 data storage Methods 0.000 claims description 3
- 102100029464 Aquaporin-9 Human genes 0.000 description 3
- 101100190462 Caenorhabditis elegans pid-1 gene Proteins 0.000 description 3
- 101000771413 Homo sapiens Aquaporin-9 Proteins 0.000 description 3
- 101000921370 Homo sapiens Elongation of very long chain fatty acids protein 1 Proteins 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000004891 communication Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000005065 mining Methods 0.000 description 2
- 238000012549 training Methods 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 101100190464 Caenorhabditis elegans pid-2 gene Proteins 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013475 authorization Methods 0.000 description 1
- 230000006399 behavior Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000010076 replication Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6272—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database by registering files or documents with a third party
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- General Health & Medical Sciences (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Bioethics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
L’invention concerne un procédé d’enregistrement d’un fichier numérique (FI) selon une méthode par chaîne de blocs, sur un premier terminal (SSC) équipé d’un dispositif d’acquisition d’une donnée de surveillance (DS) du terminal (SSC). Selon l’invention, l’enregistrement du fichier numérique (FI) sur la chaîne de blocs se fait sous forme d’une capsule de preuves (CP) comprenant le fichier (FI) associé à une donnée de surveillance (DS) acquise par le dispositif (CAPD) lors de l’enregistrement du fichier (FI). Figure pour l’abrégé : Fig. 1
Description
L’invention se rapporte au domaine technique du stockage informatisé de fichiers numériques et en particulier aux méthodes d’enregistrement mettant en œuvre des méthodes de chaîne de blocs.
Dans le domaine juridique, des fichiers numériques peuvent être invoqués en tant que preuves, par exemple pour attester qu’un contrat a bel et bien été signé par les parties. Une photographie numérique peut aussi aider à prouver qu’un événement a bel et bien eu lieu à une date donnée et dans un lieu donné, car le fichier numérique de la photographie comprend des métadonnées où figurent par exemple un horodatage de la prise de vue, la géolocalisation de la prise de vue.
Toutefois, les technologies informatiques permettent de modifier aisément les fichiers numériques, de sorte que les fichiers numériques sont facilement contestables de sorte qu’ils sont difficilement acceptés en tant que preuve, car leur force probante n’est pas suffisante. Ils sont seulement considérés comme des commencements de preuves.
Il existe des terminaux sécurisés dans lesquels une surveillance matérielle du terminal est effectuée, par exemple au moyen de capteurs disposés sur le terminal. Néanmoins, c’est le serveur en tant que tel qui est surveillé, pas les données qui y sont enregistrées. Certains tribunaux refusent donc de considérer les fichiers issus de ce serveur comme probants, car ils considèrent que les fichiers peuvent avoir été falsifiés en amont de leur stockage sur le serveur, et ce même si l’enregistrement est réalisé par des méthodes de chaines de blocs, ou encore entre le moment où le fichier est téléchargé depuis le serveur et le moment de sa production au tribunal.
Au surplus, lorsque le serveur d’enregistrement du fichier est localisé dans un autre pays ou un autre Etat que celui où le litige est instruit, la juridiction particulière de l’Etat où le litige est instruit peut rendre extrêmement compliqué de faire accepter ledit fichier comme preuve suffisante : des conditions de territorialités et de localisation du stockage des données peuvent être prépondérantes.
Il existe enfin des méthodes d’enregistrement d’un fichier numérique par méthode de chaîne de blocs, dans lesquelles le fichier est découpé en tessons dont le volume de données est défini par le volume de données d’un bloc de la chaîne, selon la méthode de chaîne utilisée. Les tessons sont ensuite enregistrés dans différents blocs. Cependant, ces méthodes emploient des chaînes de blocs publiques pour lesquelles la localisation des serveurs (ou ordinateurs) est aléatoire et donc non maîtrisée. Par conséquent, un fichier numérique stocké de cette manière peut ne pas être recevable devant la juridiction d’un territoire donné d’autant que cette méthode est parfois illicite dans certains Pays selon la mise en œuvre ou non du minage.
L’un des buts de l’invention est de pallier les inconvénients de l’art antérieur en proposant un procédé d’enregistrement d’un fichier numérique garantissant son authenticité, c’est-à-dire garantissant le fait que ce fichier n’ait pas été falsifié.
Un autre but de l’invention est de pouvoir fournir des fichiers numériques probants, qui puissent être utilisés en tant que preuves d’un point de vue juridique et ce y compris dans un contexte international.
À cet effet, il a été mis au point un procédé d’enregistrement d’un fichier numérique selon une méthode par chaîne de blocs, sur un premier terminal équipé d’un dispositif d’acquisition d’une donnée de surveillance du terminal.
Selon l’invention, l’enregistrement du fichier numérique sur la chaîne de blocs se fait sous forme d’une capsule de preuves comprenant le fichier associé à une donnée de surveillance acquise par le dispositif lors de l’enregistrement ou stockage du fichier.
De cette manière, l’authenticité du fichier numérique est assurée par l’association du fichier et de la donnée de surveillance au sein de la même chaîne, ce qui confère la force probante attendue : en effet, il n’est plus possible de modifier ou de falsifier le fichier numérique et ses données de surveillance sans que cela ne soit détectable, car les empreintes numériques des blocs suivants de la chaîne ne correspondraient plus à celle du bloc comprenant une donnée modifiée. En effet, la falsification des fichiers enregistrés avec le procédé selon l’invention n’étant pas possible, « la balance des probabilités » utilisée par la majorité des tribunaux ou juridictions permet donc d’utiliser ces fichiers en tant que preuves.
Par « fichier numérique », on fait référence au fichier numérique en tant que tel, ou à son empreinte numérique (« hash » en anglais). En effet, des fichiers moins volumineux peuvent être stockés directement au sein de la chaîne de bloc. En revanche, des fichiers plus volumineux peuvent ralentir les transferts et les copies de la chaîne de bloc car le volume de stockage de cette dernière va augmenter trop rapidement, au fur et à mesure de l’enregistrement de nouvelles capsules de preuve.
Il est envisageable d’enregistrer sur la chaîne soit un fichier, soit son empreinte, en fonction d’un test sur le volume du fichier à stocker. Par exemple :
- on stocke le fichier s’il pèse moins de 512Ko, ou alors
- on stocke l’empreinte numérique si le fichier pèse plus de 512Ko.
- on stocke le fichier s’il pèse moins de 512Ko, ou alors
- on stocke l’empreinte numérique si le fichier pèse plus de 512Ko.
Dans la suite du document, on décrit le « fichier numérique », qu’il s’agisse du fichier en tant que tel ou bien de son empreinte numérique.
Par donnée de surveillance, on entend tout type de donnée relative au terminal (telle qu’un numéro de série ou une adresse MAC), ou à son environnement (telle que sa géolocalisation ou les conditions environnementales), ou à son utilisation (telle que l’horodatage de l’enregistrement ou une identification de son utilisateur, par exemple une empreinte biométrique).
Il est entendu qu’une capsule comprend au moins un fichier numérique, mais peut également en contenir plusieurs. Il peut s’agir par exemple des photographies de chacune des pages d’un contrat ou des fichiers de nature différentes comme des photographies, des vidéos, une base de données. La méthode mise en œuvre pour l’invention est du type à preuve d’autorité de ses chaines de blocs privés, de sorte que l’inscription de nouveaux blocs ne nécessite pas de minage, mais que l’inscription de nouveaux blocs ne peut être faite que sur des terminaux après avoir validé la agréés et contrôlés par la preuve d’autorité. Ainsi, avec la méthode de preuve d’autorité, la confiance au regard des fichiers de preuves déposés repose sur un système fondé sur une vérification en amont de l’identité des intervenants. De manière générale, les méthodes de chaînes de bloc avec algorithme de consensus sont connues en soi et ne seront pas plus détaillées.
A l’inverse d’une méthode de chaîne de bloc publique, le procédé selon l’invention ne nécessite pas l’intervention d’un nombre important de nœuds, ni de plusieurs réplications de la chaîne de blocs afin de prouver son authenticité : celle-ci repose sur l’intégrité de la preuve d’autorité, qui est privée. Cela permet entre autres une économie substantielle de l’espace de stockage nécessaire, car la chaîne de blocs n’est pas dupliquée inutilement sur un trop grand nombre de serveurs.
Selon un mode de réalisation particulier, le fichier et au moins une donnée de surveillance supplémentaire sont acquis sur un second terminal, tel qu’un téléphone intelligent, puis sont transmises au premier terminal, tel qu’un serveur, sur lequel est effectué l’enregistrement de la capsule de preuves comprenant le fichier, la donnée de surveillance supplémentaire du second terminal et la donnée de surveillance du premier terminal. L’acquisition des fichiers peut donc être effectuée sur plusieurs sites, et l’enregistrement est centralisé ce qui facilite sa protection et la surveillance de son intégrité.
Afin de garantir que les données ne sont pas falsifiées avant d’être enregistrées sur le premier terminal, la capsule de preuves est enregistrée sur une chaîne de blocs distante sur le second terminal, avant d’être transmise au premier terminal qui l’enregistre dans une chaine de blocs locale. L’enregistrement sur une chaîne de bloc dès l’acquisition du fichier empêche les opérations de falsification, et ce dès son acquisition.
Puisque la méthode de chaîne de blocs est privée, il est possible de générer plusieurs chaînes en parallèle, l’authenticité de chaque chaîne étant garantie par l’intégrité de la preuve d’autorité. La chaîne de bloc distante peut donc être constituée et évoluer indépendamment de la chaîne de bloc locale.
Toujours dans un but de sécurisation, la capsule de preuves comprend un bloc d’ouverture et/ou un bloc de fermeture chacun émis par le premier terminal, qui sont intégrés dans la capsule lors de son enregistrement sur le second terminal, et qui encadrent le fichier et la donnée de surveillance supplémentaire. De cette manière, la capsule de preuves ne peut pas être enregistrée sur le second terminal sans que le premier terminal ne l’ait autorisé, en émettant un bloc d’ouverture et/ou un bloc de fermeture. L’utilisation du bloc d’ouverture et du bloc de fermeture permet également au premier terminal de surveiller l’état du second terminal. Il est par exemple possible de détecter si un second terminal n’a pas été synchronisé depuis trop longtemps.
La chaîne de bloc locale et la chaîne de bloc distante évoluent chacune en parallèle, mais mêle les données de la chaîne de bloc locale avec celles de la chaîne de bloc distante permettant de renforcer la sécurisation de l’ensemble.
Par « bloc d’ouverture », on entend un bloc de la chaîne permettant de définir le début d’une nouvelle capsule de preuves. Il ne s’agit pas d’un « bloc de genèse », correspondant au premier bloc d’une chaîne selon le sens communément utilisé dans ce domaine.
De manière que le fichier numérique soit recevable auprès des juridictions de plusieurs états, ou pays, la capsule de preuves est transmise simultanément depuis le second terminal vers le premier terminal ainsi que vers plusieurs terminaux auxiliaires situés sur plusieurs juridictions. Les terminaux auxiliaires sont semblables au premier terminal et fonctionnent de manière équivalente. Le terme « terminal auxiliaire » n’est utilisé qu’afin de différencier ces terminaux supplémentaires du premier terminal, mais en pratique le premier terminal et les terminaux auxiliaires sont équivalents. Ils fonctionnent de préférence en parallèle, sans hiérarchie maître/esclave.
Dans le cas où le procédé met en œuvre des terminaux auxiliaires, la capsule de preuves comprend en outre des blocs d’ouverture et/ou des blocs de fermeture chacun émis par les terminaux auxiliaires. La capsule de preuves ne peut pas être générée sans que ne soit impliqué le terminal présent sur chacune des juridictions concernées. La force probante est encore augmentée car la quantité de données comprise dans la chaîne de blocs de la capsule est augmentée. Une falsification de la capsule impliquerait une intervention sur chacun des terminaux, ce qui n’est pas réalisable en pratique. De plus, la capsule de preuves étant considérée comme originaire du Pays où elle est enregistrée est considérée comme directement recevable auprès de chacune des juridictions où se trouve un desdits terminaux sans qu’il ne soit nécessaire de mettre en œuvre des traités multilatéraux tel que la convention de la Haye du 18 mars 1970.
Pour faciliter la communication de la capsule de preuves à un tiers, par exemple à un juge, ou encore un assureur, chaque terminal est configuré pour émettre un jeton correspondant à la capsule de preuves, c’est-à-dire un fichier numérique unique correspondant à ladite capsule. L’émission d’un jeton est inscrite dans la chaine de blocs. De préférence, chaque jeton est unique et non fongible. Pour les mêmes raisons de volume de stockage évoquées plus haut :
- le jeton peut comprendre la capsule de preuves si son volume est limité, ou
- le jeton peut comprendre des données d’identification permettant d’attester sa correspondance avec la capsule de preuves, si le volume de la capsule de preuves est trop important.
- le jeton peut comprendre la capsule de preuves si son volume est limité, ou
- le jeton peut comprendre des données d’identification permettant d’attester sa correspondance avec la capsule de preuves, si le volume de la capsule de preuves est trop important.
Avantageusement, selon un mode de réalisation, le fichier et la donnée de surveillance sont effacés d’une mémoire du second terminal après avoir été transmis au premier terminal. Cela permet de garantir la protection de données sensibles, telles que des données personnelles, au cas où le second terminal serait volé. Cela permet également de gérer la saturation de la mémoire de stockage du second terminal.
Pour vérifier la bonne intégrité des terminaux, la donnée de surveillance acquise est comparée à une donnée de surveillance attendue, et une différence entre la donnée de surveillance acquise et la donnée de surveillance attendue déclenche une alerte auprès d’une preuve d’autorité de la chaîne de blocs.
Dans un mode de réalisation, la capsule de preuves comprend des données d’identification de capsules comparables avec des données d’identification de capsules d’une autre capsule. Il est ainsi possible de constituer une base de données des données d’identification des capsules de preuves, et la comparaison des données d’identification des capsules permet de vérifier si des capsules sont compatibles entre elles, ce qui définit un contrat.
De manière à assurer un suivi des jetons émis, le stockage du jeton sur un appareil est enregistré sur une chaîne de blocs sous la forme d’une capsule de détention comprenant un identifiant unique de la capsule de preuves du jeton et une donnée d’identité du propriétaire de l’appareil, et de préférence une donnée de surveillance d’un dispositif d’acquisition de l’appareil acquise lors du stockage du jeton. L’identité du propriétaire du jeton peut être l’identité du propriétaire de l’appareil, ou l’identité de l’utilisateur ayant ouvert une session d’utilisation sur l’appareil ou sur le serveur ayant émis le jeton.
L’invention concerne également un terminal sécurisé comprenant :
- des moyens de réception de données de preuves, tel qu’un capteur photo ou une carte réseau ;
- des moyens d’acquisition de données de surveillance, tel qu’un capteur GPS ;
- des moyens de stockage de données, tel qu’un DD ou une carte SD ;
- des chaines de blocs enregistrées sur les moyens de stockage
- un programme d’ordinateur programmé pour mettre en œuvre un procédé selon les caractéristiques précitées.
- des moyens de réception de données de preuves, tel qu’un capteur photo ou une carte réseau ;
- des moyens d’acquisition de données de surveillance, tel qu’un capteur GPS ;
- des moyens de stockage de données, tel qu’un DD ou une carte SD ;
- des chaines de blocs enregistrées sur les moyens de stockage
- un programme d’ordinateur programmé pour mettre en œuvre un procédé selon les caractéristiques précitées.
L’invention concerne également un jeton numérique issu d’un terminal de stockage d’un fichier numérique, le terminal étant équipé d’un dispositif d’acquisition d’une donnée de surveillance, et le fichier étant stocké selon une méthode par chaîne de blocs, le jeton comprenant une capsule de preuves comprenant le fichier associé à une donnée de surveillance acquise par le dispositif lors du stockage du fichier.
Un tel jeton permet de garantir que le fichier contenu n’a pas été falsifié depuis son acquisition.
En référence à la , le procédé selon l’invention consiste essentiellement à enregistrer au sein de la même chaîne de blocs (BU) un fichier numérique (FI) ainsi qu’une donnée de surveillance (DS).
En pratique, plusieurs données de surveillance (DS) sont utilisées afin de constituer un faisceau d’indice. Plus le faisceau d’indice est complet, plus la force probante du fichier numérique (FI) est renforcée.
La donnée de surveillance (DS) peut donc comprendre, de manière non limitative :
- la lecture d’un capteur d’empreinte du premier terminal (SSC), permettant d’attester qui était l’utilisateur du terminal (SSC) lors de l’acquisition du fichier (FI) ;
- une adresse MAC du premier terminal (SSC), permettant de rendre détectable la génération d’un fichier falsifié depuis un autre terminal (SSC) ;
- une géolocalisation du premier terminal (SSC) ;
ou encore une combinaison de plusieurs données.
- la lecture d’un capteur d’empreinte du premier terminal (SSC), permettant d’attester qui était l’utilisateur du terminal (SSC) lors de l’acquisition du fichier (FI) ;
- une adresse MAC du premier terminal (SSC), permettant de rendre détectable la génération d’un fichier falsifié depuis un autre terminal (SSC) ;
- une géolocalisation du premier terminal (SSC) ;
ou encore une combinaison de plusieurs données.
Le premier terminal (SSC) est donc équipé de moyens d’acquisition de la donnée de surveillance (CAPD), par exemple tout capteur ou tout moyen de lecture adapté.
Le premier terminal (SSC) est également équipé de moyens d’acquisition du fichier (CAPF), par exemple un capteur photographique, ou encore un moyen de communication lui permettant de recevoir le fichier numérique (FI).
Bien entendu, le premier terminal (SSC) comprend une mémoire de stockage réinscriptible (DQ) pour enregistrer le fichier numérique (FI) ainsi que la donnée de surveillance (DS), et exécute un programme d’ordinateur, programmé pour effectuer les acquisitions, les enregistrements et les étapes du procédé décrits.
Le programme d’ordinateur peut comprendre des sous-programmes ou exécuter des applications tierces, par exemple pour piloter les capteurs (CAPF, CAPD) du fichier (FI) et/ou des données de surveillance (DS).
Le premier terminal (SSC) est apte, au moyen du programme qu’il exécute, à émettre des jetons de preuve (NFP) comprenant la capsule de preuves (CP). Le jeton (NFP) comprend également des données additionnelles (DAdd), qui peuvent être par exemple un horodatage de l’émission du jeton, un identifiant de la session utilisateur ayant ordonnée l’émission du jeton (NFP), etc.
Plusieurs jetons (NFP) de la même capsule (CP) peuvent être émis, mais il s’agit à chaque fois d’une copie et chaque jeton (NFP) est non fongible car il comprend des données additionnelles (DAdd) qui lui sont propres. Les jetons (NFP) sont néanmoins transmissibles.
En référence à la , le procédé met en œuvre un second terminal (APP) qui acquière le fichier (FI) ainsi que des données de surveillance supplémentaires (FI’). Le second terminal (APP) est semblable au premier terminal (SSC) en ce qu’il comprend des moyens d’acquisition du fichier numérique (CAPF), des moyens d’acquisition des données de surveillance (CAPF), une mémoire de stockage réinscriptible (DQ), et qu’il exécute un programme d’ordinateur programmé pour mettre en œuvre les étapes décrites.
Afin de simplifier les explications suivantes, le premier terminal (SSC) sera désigné sous le terme de « serveur », et le second terminal (APP) sous le terme « d’appareil ». En effet, bien que le premier terminal (SSC) et le second terminal (APP) puissent être de tout type adapté, un mode préféré est d’utiliser un serveur (SSC) auquel sont connectés plusieurs appareils (APP) nomades, de type téléphone intelligent, la connexion entre l’appareil (APP) et le serveur (SSC) se faisant de préférence par le réseau Internet et/ou par réseau de téléphonie mobile.
De préférence, l’appareil (APP) est également apte à émettre des jetons (NFP).
L’utilisation d’un appareil (APP) permet d’acquérir les fichiers (FI) de manière déportée, éventuellement au moyen de plusieurs appareils (APP), mais de les enregistrer de manière centralisée sur le serveur (SSC).
Sur le mode illustré à la , l’appareil (APP) n’enregistre pas le fichier (FI) et la donnée de surveillance (DS) sous forme de chaine de bloc et les transmet directement au serveur (SSC).
En référence à la , le mode illustré est similaire à celui de la hormis que l’appareil (APP) enregistre le fichier (FI) et la donnée de surveillance (DS) sur une chaine de bloc distante (MBL), dans une mémoire de l’appareil (APP).
Dans ce mode, la capsule de preuves (CP) est donc générée directement sur l’appareil (APP), et le fichier (FI) et la donnée de surveillance (DS) sont transmis au serveur (SSC) sous forme d’une capsule de preuves (CP).
Ce mode permet de garantir que le fichier (FI), dès son acquisition sur l’appareil (APP), n’est pas falsifié sans que cela ne soit détectable par l’analyse de la chaîne de blocs de la capsule (CP).
Lorsque la capsule (CP) est transmise au serveur (SSC), celui-ci l’enregistre sur sa chaîne de blocs local (BU).
On voit sur la que lors de l’émission de la capsule (CP), l’appareil (APP) rajoute de préférence des données additionnelles (DAdd) de manière similaire aux données additionnelles (DAdd) rajoutées lors de l’émission d’un jeton (NFP).
La capsule (CP) est ainsi évolutive : chaque transaction effectuée, par exemple le transfert de la capsule (CP) d’un terminal (APP, SSC) à un autre, est enregistrée et est traçable au moyen de ces données additionnelles (DAdd). Lorsqu’un jeton (NFP) est émis, on peut donc remonter toute la chaîne de bloc contenue dans le jeton (NFP) et savoir sur quel terminal (APP, SSC) la capsule (CP) a été acquise, stockée, à quel moment a eu lieu chaque transaction, etc.
Sur la :
- Au début, la capsule (CP) est générée sur l’appareil (APP) et ne comprend que le fichier (FI) et la donnée de surveillance supplémentaire (FI’).
- Ensuite, la transmission de la capsule (CP) au serveur (SSC) rajoute un premier bloc de données additionnelles (DAdd).
- Puis l’enregistrement de la capsule (CP) sur le serveur (SSC) complète la capsule (CP) avec des données de surveillance (DS) du serveur (SSC).
- Au début, la capsule (CP) est générée sur l’appareil (APP) et ne comprend que le fichier (FI) et la donnée de surveillance supplémentaire (FI’).
- Ensuite, la transmission de la capsule (CP) au serveur (SSC) rajoute un premier bloc de données additionnelles (DAdd).
- Puis l’enregistrement de la capsule (CP) sur le serveur (SSC) complète la capsule (CP) avec des données de surveillance (DS) du serveur (SSC).
La illustre un mode de réalisation dans lequel l’enregistrement de la capsule (CP) sur l’appareil (APP) comprend de surcroît un bloc d’ouverture (Op) et/ou un bloc de fermeture (Cl), chacun émis par le serveur (SSC).
Par cette intrication des blocs générés par le serveur (SSC) et par l’appareil (APP), la falsification du fichier (FI) sur l’appareil (APP) n’est pas possible.
Le bloc d’ouverture (Op) et le bloc de fermeture (Cl) sont également enregistrés sur la chaîne de blocs locale (BU) du serveur (SSC) lors de leur émission, ce qui permet d’en conserver une trace même si l’appareil (APP) ne renvoie pas de capsule (CP).
Le bloc d’ouverture (Op) et le bloc de fermeture (Cl) peuvent être des blocs complets de la chaîne de blocs locale (BU). En alternative, l’intrication de la chaîne de blocs locale (BU) et de la chaîne de blocs distante (MBL) peut être obtenue par l’échange d’empreinte numériques seulement (hash en anglais), afin de limiter le volume de données échangées. Dans la suite du document, les termes « bloc d’ouverture » et « bloc de fermeture » couvrent ces deux modes de réalisation.
Cette méthode permet à la preuve d’autorité de la chaine de blocs de vérifier le comportement de l’appareil (APP).
Par exemple, la création d’une nouvelle capsule (CP) peut n’être possible que si le serveur (SSC) émet le bloc d’ouverture (Op). Un appareil (APP) qui serait volé pourrait donc être rendu inopérant, en cessant si le serveur (SCC) cesse de lui fournir des blocs d’ouverture (Op).
De manière similaire, l’utilisation, d’un bloc de fermeture (Cl) permet de n’autoriser le retour d’une capsule (CP) vers le serveur (SSC) que si des opérations de contrôles ont été effectuées : par exemple si l’appareil (APP) ne comprend pas de capteurs de données biométriques, l’identité de l’utilisateur de l’appareil (APP) pourrait être vérifiée par un autre moyen avant de déclencher l’envoi du bloc de fermeture (Cl) par le serveur (SSC).
L’utilisation d’un bloc d’ouverture (Op) et d’un bloc de fermeture (Cl) permet également de vérifier que la capsule (CP) a bien été générée durant une fenêtre temporelle prédéfinie, ce qui renforce encore la sécurisation et la force probante des capsules (CP) générées.
Ce mode permet en outre de préparer des capsules de preuves (CP) sur l’appareil (APP) même s’il est hors ligne et ne peut pas communiquer avec le serveur (SSC) :
- le bloc d’ouverture (Op) est généré puis enregistré sur la chaîne de blocs distante (MBL) lorsque la connexion est établie ; puis
- le fichier (FI) et la donnée de surveillance (DS) sont ajoutées sur la chaîne de blocs distante (MBL) même si l’appareil (APP) est hors ligne ; puis
- le bloc de fermeture (Cl) est enregistré sur la chaîne de blocs distante (MBL) lorsque la connexion entre l’appareil (APP) et le serveur (SSC) est rétablie.
La capsule de preuves (CP) n’est téléversée sur le serveur (SSC) que lorsque la connexion est rétablie.
- le bloc d’ouverture (Op) est généré puis enregistré sur la chaîne de blocs distante (MBL) lorsque la connexion est établie ; puis
- le fichier (FI) et la donnée de surveillance (DS) sont ajoutées sur la chaîne de blocs distante (MBL) même si l’appareil (APP) est hors ligne ; puis
- le bloc de fermeture (Cl) est enregistré sur la chaîne de blocs distante (MBL) lorsque la connexion entre l’appareil (APP) et le serveur (SSC) est rétablie.
La capsule de preuves (CP) n’est téléversée sur le serveur (SSC) que lorsque la connexion est rétablie.
Les capsules de preuves (CP) peuvent donc être préparées hors connexion sur l’appareil (APP), par l’acquisition des fichiers (FI) et des données de surveillance (DS), dans l’attente de la complétion des capsules (CP) avec le bloc de fermeture (Cl) dès que la connexion avec le serveur (SSC) est rétablie.
La illustre un mode de réalisation préféré dans lequel :
- la capsule (CP) est enregistrée sur plusieurs serveurs, à savoir un serveur (SSC1) et un terminal auxiliaire (SSC2) ;
- le fichier (FI) est acquis sur un appareil (APP), qui l’enregistre avec la donnée de surveillance (DS) sur une chaîne de blocs distante (MBL) ;
- l’enregistrement de la capsule (CP) est soumis à l’émission de blocs d’ouverture (Op) et de fermeture (Cl) par chacun des serveurs (SSC).
- la capsule (CP) est enregistrée sur plusieurs serveurs, à savoir un serveur (SSC1) et un terminal auxiliaire (SSC2) ;
- le fichier (FI) est acquis sur un appareil (APP), qui l’enregistre avec la donnée de surveillance (DS) sur une chaîne de blocs distante (MBL) ;
- l’enregistrement de la capsule (CP) est soumis à l’émission de blocs d’ouverture (Op) et de fermeture (Cl) par chacun des serveurs (SSC).
En pratique, le terminal auxiliaire (SSC2) est de préférence un autre serveur équivalent au premier terminal (SSC1). Il n’y a pas de hiérarchie entre ces serveurs (SSC1, SSC2), et ils fonctionnent de manière semblable.
La capsule (CP) étant enregistrée sur plusieurs serveurs (SSC), elle est dupliquée et il y a désormais autant de capsules (CP) qu’il y a de serveurs (SSC).
Ce mode garantit :
- que la génération de la capsule (CP) était autorisée, car les blocs d’ouverture (Op) ont été émis par les serveurs (SSC) ;
- que l’intégrité de l’appareil (APP) était reconnue, car les blocs de fermeture (Cl) ont été émis par les serveurs (SSC) ;
- que le fichier (FI) sera recevable en tant que preuve dans chaque Etat où sont situés les serveurs (SSC), car chacun de ces serveurs (SSC) ont participé à la génération de la capsule (CP) :
* depuis son origine, via l’émission des blocs d’ouverture (Op) ; et
* jusqu’à son enregistrement sur les serveurs (SSC), via l’émission des blocs de fermeture (Cl).
- que la génération de la capsule (CP) était autorisée, car les blocs d’ouverture (Op) ont été émis par les serveurs (SSC) ;
- que l’intégrité de l’appareil (APP) était reconnue, car les blocs de fermeture (Cl) ont été émis par les serveurs (SSC) ;
- que le fichier (FI) sera recevable en tant que preuve dans chaque Etat où sont situés les serveurs (SSC), car chacun de ces serveurs (SSC) ont participé à la génération de la capsule (CP) :
* depuis son origine, via l’émission des blocs d’ouverture (Op) ; et
* jusqu’à son enregistrement sur les serveurs (SSC), via l’émission des blocs de fermeture (Cl).
Lors de l’émission d’un jeton (NFP) par un des serveurs (SSC),on voit que celui-ci comprend :
- le fichier (FI) dont l’authenticité est à prouver ;
- la donnée de surveillance (DI) de l’appareil (APP) ayant acquis le fichier (FI) ;
- chaque bloc d’ouverture et de fermeture (Op, Cl) de chacun des serveurs (SSC) mis en cause ;
- des données de surveillance (DS) garantissant l’intégrité du serveur (SSC2) dont provient le jeton (NFP) ;
- des données additionnelles (DAdd) rajoutées lors de l’émission du jeton (NFP).
- le fichier (FI) dont l’authenticité est à prouver ;
- la donnée de surveillance (DI) de l’appareil (APP) ayant acquis le fichier (FI) ;
- chaque bloc d’ouverture et de fermeture (Op, Cl) de chacun des serveurs (SSC) mis en cause ;
- des données de surveillance (DS) garantissant l’intégrité du serveur (SSC2) dont provient le jeton (NFP) ;
- des données additionnelles (DAdd) rajoutées lors de l’émission du jeton (NFP).
Un tel jeton numérique (NFP) comprend donc le fichier (FI) dont l’authenticité est à prouver, et un ensemble de faisceaux d’indices mêlant des données de surveillance (DS), chaque transaction depuis l’autorisation de l’acquisition du fichier (FI) sur l’appareil (APP) jusqu’à sa production devant un tribunal étant prouvée par les blocs d’ouverture, de fermeture et additionnels (Op, Cl, DAdd).
Un tel jeton (NFP) permet donc d’obtenir, au sein de chaque Etat où est disposé un serveur (SSC), un fichier (FI) recevable en tant que preuve.
Dans un mode de réalisation, la capsule de preuves (CP) comprend des données d’identification de capsules (TAG) comparables avec des données d’identification de capsules (TAG) d’une autre capsule (CP). La correspondance de données d’identification de capsules (TAG) de plusieurs capsules (CP) permet de définir si ces capsules (CP) sont compatibles entre elles. Cette correspondance peut être gérée :
- en utilisant les mêmes données d’identification de capsules (TAG) pour plusieurs capsules (CP), auquel cas on vérifie que les données d’identification de capsules (TAG) sont identiques ;
- en utilisant des données d’identification de capsules (TAG) différentes, mais partageant une même racine (ou une plage identique), auquel cas on vérifie que les données d’identification de capsules (TAG) partagent cette racine commune ;
- en utilisant uniquement des données d’identification de capsules (TAG) uniques, et pour lesquelles les correspondance autorisées sont enregistrées dans une base de donnée des correspondance, auquel cas on vérifie au sein de la base de données si les données d’identification de capsules (TAG) d’une première capsule (CP) correspondent aux données d’identification de capsules (TAG) de la seconde capsule (CP).
- en utilisant les mêmes données d’identification de capsules (TAG) pour plusieurs capsules (CP), auquel cas on vérifie que les données d’identification de capsules (TAG) sont identiques ;
- en utilisant des données d’identification de capsules (TAG) différentes, mais partageant une même racine (ou une plage identique), auquel cas on vérifie que les données d’identification de capsules (TAG) partagent cette racine commune ;
- en utilisant uniquement des données d’identification de capsules (TAG) uniques, et pour lesquelles les correspondance autorisées sont enregistrées dans une base de donnée des correspondance, auquel cas on vérifie au sein de la base de données si les données d’identification de capsules (TAG) d’une première capsule (CP) correspondent aux données d’identification de capsules (TAG) de la seconde capsule (CP).
Cette compatibilité permet de définir des appairages, ou des « contrats » entre plusieurs capsules (CP).
Dans un premier exemple, il s’agit de vérifier la compatibilité entre un matériel donné et du consommable destiné à alimenter ce matériel.
Dans un second exemple, il s’agit de vérifier l’adéquation entre le geste que doit pratiquer un praticien, et la formation qu’il a reçue.
Dans un troisième exemple, il s’agit de vérifier la correspondance d’un bon d’envoi de matériel, émis par un transporteur, avec un bon de réception.
Dans un quatrième exemple, il s’agit de s’assurer de la correspondance entre les obligations des parties à un contrat et leur exécution matérielle ou immatérielle.
. Dans tous les cas, les données d’identification de capsules (TAG) d’une première capsule (CP) sont comparées aux données d’identification de capsules (TAG) d’une seconde capsule (CP), au moyen d’une application dédiée.
Si les données d’identification de capsules (TAG) sont compatibles, alors le contrat est exécuté (avec les exemples précédents : le consommable peut être utilisé sur le matériel, le geste du praticien est autorisé, ou la marchandise est déclarée reçue).
En revanche, si elles ne sont pas compatibles, le contrat n’est pas exécuté et l’application dédiée peut signaler l’incompatibilité, ou encore empêcher l’appairage (avec les exemples précédents : le fonctionnement du matériel est empêché tant qu’un consommable compatible n’est pas présenté, le geste du praticien n’est pas autorisé et/ou l’événement est signalé à un organisme de formation).
Une fois qu’un contrat est exécuté, il peut être périmé dans la base de données des données d’identification de capsules (TAG), par exemple en modifiant un champ binaire de la base de données, ce qui passe le contrat de « à exécuter », à « exécuté ».
En référence à la , un mode de réalisation prévoit qu’il soit possible de suivre la détention, ou la propriété, des jetons (NFP).
Lorsqu’un jeton (NFP) est émis, celui-ci comprend un identifiant unique (UId), par exemple au sein des données additionnelles (DAdd).
Le jeton (NFP) est transmis à un premier propriétaire (P1), qui le stocke sur son appareil tiers (AT). De préférence, l’enregistrement sur l’appareil tiers (AT) implique l'acquisition d’une donnée de surveillance (DS), à l’instar des serveurs (SSC) et appareils (APP) précités. Avantageusement, une donnée d’identification (PId1) du premier propriétaire (P1) est également acquise.
La donnée d’identification (PId1) peut être une photo ou un scan d’une pièce d’identité, ou encore la connexion (via un identifiant et un mot de passe) à l’appareil tiers (AT) recevant le jeton (NFP), ou au serveur (SSC) ou à l’appareil (NFP) émettant le jeton (NFP).
L’identifiant unique (UId) du jeton (NFP), la donnée de surveillance (DS) de l’appareil tiers (AT) et la donnée d’identification (PId1) sont enregistrés au sein d’une capsule de détention (CD), qui permet d’attester la propriété dudit jeton (NFP) sans toutefois en reprendre tout son contenu.
De manière analogue aux fonctionnements précités, la capsule de détention (CD) peut être constituée directement sur l’appareil tiers (AT), ou bien sur un serveur (SSC).
Si le jeton (NFP) est transmis à un second propriétaire (P2), alors des données de surveillance (DS) et des données d’identification (PId2) ainsi que l’identifiant unique (UId) sont enregistrés au sein d’une nouvelle capsule de détention (CD2).
Les capsules de détention (CD) sont enregistrées sur la chaîne de bloc (BU) du serveur (SSC) afin de garantir l’authenticité des enregistrements, et la participation de la preuve d’autorité.
Dans le but de garantir la protection des données personnelles des propriétaires (P1, P2), les capsules de détention (CD) peuvent être enregistrées sur un serveur confidentiel (SSC-CONF). Ce serveur confidentiel (SSC-CONF) conserve une chaîne de blocs de détention (BD) sur laquelle sont enregistrées les capsules de détention (CD), afin d’en assurer la traçabilité et l’authenticité.
Le serveur confidentiel (SSC-CONF) transmet aux autres serveurs (SSC) du procédé des capsules de détention anonymisées (CD’), c’est-à-dire que les données d’identification (PId) sont censurées ou partiellement supprimées. Les capsules de détention anonymisées (CD’) comprennent néanmoins des données d’identification suffisantes pour pouvoir faire la correspondance entre les capsules de détentions anonymisées (CD’) et les capsules de détention d’origine (CD), par interrogation de la chaîne de bloc de détention (BD) par exemple.
Le suivi des détentions successives peut être effectué en consultant la chaîne locale (BU), en consultant la chaîne de détention (BD) si elle est mise en œuvre, ou encore en consultant des jetons de détention (DH) émis par le serveur (SSC), et contenant l’identifiant unique (UId) du jeton (NFP), et des données d’identifications (PId) des propriétaires successifs. La présence de données de surveillance (DS) augment la force probante des détentions.
Dans tous les cas, une comparaison entre la donnée de surveillance acquise (DS) et une donnée de surveillance attendue (DS ref) est envisageable, et permet de vérifier l’intégrité du terminal utilisé, qu’il s’agisse de l’appareil (APP), du serveur (SSC) ou d’un appareil tiers (AT).
La comparaison peut être par exemple :
- une différence entre l’horodatage contenu dans la donnée de surveillance (DS) du terminal (SCC) et l’horodatage contenu dans la donnée additionnelle (DAdd) de l’émission de la capsule (CP) : une différence trop importante peut signifier que l’heure de l’appareil (APP) a été modifiée, par exemple en vue d’antidater une capsule (CP) ;
- une comparaison entre les blocs d’ouverture et ou de fermeture (Op, Cl) émis par le serveur (SSC) et ceux contenus dans les capsule (CP) émises par l’appareil (APP) : si un même bloc (Op, Cl) revient plusieurs fois, cela peut signifier qu’un utilisateur mal intentionné essaye de renvoyer sur le serveur (SSC) de fausses capsules (CP) dont la génération n’a pas été autorisée.
- une différence entre l’horodatage contenu dans la donnée de surveillance (DS) du terminal (SCC) et l’horodatage contenu dans la donnée additionnelle (DAdd) de l’émission de la capsule (CP) : une différence trop importante peut signifier que l’heure de l’appareil (APP) a été modifiée, par exemple en vue d’antidater une capsule (CP) ;
- une comparaison entre les blocs d’ouverture et ou de fermeture (Op, Cl) émis par le serveur (SSC) et ceux contenus dans les capsule (CP) émises par l’appareil (APP) : si un même bloc (Op, Cl) revient plusieurs fois, cela peut signifier qu’un utilisateur mal intentionné essaye de renvoyer sur le serveur (SSC) de fausses capsules (CP) dont la génération n’a pas été autorisée.
Lorsqu’une différence est constatée, une alerte est émise à l’attention de la preuve d’autorité. Celle-ci peut ensuite verrouiller ou mettre en quarantaine l’appareil (APP) ou le serveur (SSC) incriminé.
Il est entendu que la méthode de chaîne de blocs mise en œuvre étant de type « méthode privée », tous les serveurs et appareils mis en œuvre doivent être approuvés par la preuve d’autorité pour pouvoir exécuter les programmes nécessaires à la mise en œuvre du procédé. L’installation et/ou le fonctionnement de programmes installés sur les serveurs (SSC), appareils (APP) et appareils tiers (AT) est donc soumis à la preuve d’autorité qui autorise ou empêche l’inscription de blocs sur les différentes chaînes (BU, MBL, BD).
Par ailleurs, le procédé et le jeton (NFP) peuvent être conformés différemment des exemples donnés sans sortir du cadre de l’invention, qui est défini par les revendications.
En variante non représentée, le fichier (FI) et la donnée de surveillance (DI) sont supprimées de l’appareil (APP) après avoir été transmises au serveur (SSC), que l’appareil (APP) comprenne une chaîne de blocs distante (MBL) ou non.
Dans le premier cas, la chaîne de blocs distante (MBL) peut être intégralement supprimée de l’appareil, auquel cas un nouveau bloc d’initialisation de la chaîne de blocs distante (MBL) doit être fournie à l’appareil (APP) par la preuve d’autorité.
Sinon, seuls les blocs comprenant le fichier (FI) et la donnée de surveillance (DS) sont supprimés (ainsi que d’éventuels blocs aval de la chaîne), de manière à pouvoir créer une nouvelle suite de blocs sur la base de la chaîne de blocs distante (MBL) restante.
Dans le cas où les fichiers (FI) comprennent des informations personnelles, la suppression du fichier (FI) de l’appareil (APP) facilite notamment la conformité du procédé avec le règlement général pour la protection des données personnelles (RGPD).
Pour protéger la confidentialité du fichier (FI), les données peuvent être enregistrées sous forme cryptée.
En outre, les caractéristiques techniques des différents modes de réalisation et variantes mentionnés ci-dessus peuvent être, en totalité ou pour certaines d’entre elles, combinées entre elles. Ainsi, l’invention peut être adaptée en termes de coûts, de fonctionnalités et de performances.
Claims (13)
- Procédé d’enregistrement d’un fichier numérique (FI) selon une méthode par chaîne de blocs, sur un premier terminal (SSC) équipé d’un dispositif d’acquisition d’une donnée de surveillance (DS) du terminal (SSC)
caractérisé en ce que l’enregistrement du fichier numérique (FI) sur la chaîne de blocs se fait sous forme d’une capsule de preuves (CP) comprenant le fichier (FI) associé à une donnée de surveillance (DS) acquise par le dispositif (CAPD) lors de l’enregistrement du fichier (FI). - Procédé selon la revendication 1, dans lequel le fichier (FI) et une donnée de surveillance (DS) supplémentaire sont acquis sur un second terminal (APP), puis sont transmis au premier terminal (SSC) sur lequel est effectué l’enregistrement de la capsule de preuves (CP) comprenant le fichier (FI), les données de surveillance (DS) du second terminal (APP) et du premier terminal (SSC).
- Procédé selon la revendication 2, dans lequel la capsule de preuves (CP) est enregistrée sur une chaîne de blocs distante (MBL) sur l’appareil (APP), avant d’être transmise au premier terminal (SSC) qui l’enregistre dans une chaine de blocs locale (BU).
- Procédé selon la revendication 3, dans lequel la capsule de preuves (CP) comprend un bloc d’ouverture (Op) et/ou un bloc de fermeture (Cl) chacun émis par le premier terminal (SSC), qui sont intégrés dans la capsule (CP) lors de son enregistrement sur l’appareil (APP), et qui encadrent le fichier (FI) et la donnée de surveillance (DS) du second terminal (APP).
- Procédé selon l’une des revendications 2 à 4, dans lequel la capsule de preuves (CP) est transmise depuis l’appareil (APP) vers plusieurs terminaux auxiliaires situés sur plusieurs juridictions.
- Procédé selon la revendication 5, dans lequel la capsule de preuves (CP) comprend en outre des blocs d’ouverture (Op) ainsi que des blocs de fermeture (Cl) chacun émis par les terminaux auxiliaires.
- Procédé selon l’une des revendications 2 à 6, dans lequel chaque terminal (APP, SSC) est configuré pour émettre un jeton (NFP) comprenant la capsule de preuves (CP).
- Procédé selon l’une des revendications 2 à 7, dans lequel le fichier (FI) et la donnée de surveillance (DS) sont effacés d’une mémoire (DQ) du second terminal (APP) après avoir été transmis au premier terminal (SSC).
- Procédé selon l’une des revendications 2 à 8, dans lequel la donnée de surveillance acquise (DS) est comparée à une donnée de surveillance attendue (DS ref), et une différence entre la donnée de surveillance acquise (DS) et la donnée de surveillance attendue (DS ref) déclenche une alerte auprès d’une preuve d’autorité de la chaîne de blocs.
- Procédé selon l’une des revendications 2 à 9, dans lequel la capsule de preuves (CP) comprend des données d’identification de capsules (TAG) comparables avec des données d’identification de capsules (TAG) d’une autre capsule (CP).
- Procédé selon la revendication 7, dans lequel le stockage du jeton (NFP) sur un appareil tiers (AT) est enregistré sur une chaîne de blocs sous la forme d’une capsule de détention (CD) comprenant un identifiant unique de la capsule de preuves contenue dans le jeton (NFP) et une donnée d’identité (PId) du propriétaire de l’appareil tiers (AT), et de préférence une donnée de surveillance (DS) acquise par un dispositif d’acquisition de l’appareil tiers( AT) lors du stockage du jeton (NFP).
- Terminal sécurisé comprenant :
- des moyens de réception de données de preuves, tel qu’un capteur photo ou une carte réseau ;
- des moyens d’acquisition de données de surveillance, tel qu’un capteur GPS ;
- des moyens de stockage de données, tel qu’un disque dur ou une carte SD ;
- des chaines de blocs enregistrées sur les moyens de stockage
- un programme d’ordinateur programmé pour mettre en œuvre un procédé selon l’une des revendications précédentes. - Jeton (NFP) numérique issu d’un terminal de stockage d’un fichier numérique, le terminal étant équipé d’un dispositif d’acquisition d’une donnée de surveillance, et le fichier étant stocké selon une méthode par chaîne de blocs, caractérisé en ce que le jeton comprend une capsule de preuves comprenant le fichier associé à une donnée de surveillance acquise par le dispositif lors du l’enregistrement du fichier.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2205508A FR3136565A1 (fr) | 2022-06-08 | 2022-06-08 | Procédé d’enregistrement renforcé d’un fichier numérique |
| PCT/EP2023/061769 WO2023237259A1 (fr) | 2022-06-08 | 2023-05-04 | Procede d'enregistrement renforce d'un fichier numerique |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2205508 | 2022-06-08 | ||
| FR2205508A FR3136565A1 (fr) | 2022-06-08 | 2022-06-08 | Procédé d’enregistrement renforcé d’un fichier numérique |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3136565A1 true FR3136565A1 (fr) | 2023-12-15 |
Family
ID=83188145
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2205508A Pending FR3136565A1 (fr) | 2022-06-08 | 2022-06-08 | Procédé d’enregistrement renforcé d’un fichier numérique |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3136565A1 (fr) |
| WO (1) | WO2023237259A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190163883A1 (en) * | 2016-05-13 | 2019-05-30 | nChain Holdings Limited | A method and system for verifying ownership of a digital asset using a distributed hash table and a peer-to-peer distributed ledger |
| US20190238327A1 (en) * | 2018-01-30 | 2019-08-01 | Baidu Online Network Technology (Beijing) Co., Ltd. | Cross-blockchain data access method, apparatus and system, and computer readable medium |
| US20200218795A1 (en) * | 2019-01-04 | 2020-07-09 | Comcast Cable Communications, Llc | Systems and methods for device and user authorization |
-
2022
- 2022-06-08 FR FR2205508A patent/FR3136565A1/fr active Pending
-
2023
- 2023-05-04 WO PCT/EP2023/061769 patent/WO2023237259A1/fr unknown
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190163883A1 (en) * | 2016-05-13 | 2019-05-30 | nChain Holdings Limited | A method and system for verifying ownership of a digital asset using a distributed hash table and a peer-to-peer distributed ledger |
| US20190238327A1 (en) * | 2018-01-30 | 2019-08-01 | Baidu Online Network Technology (Beijing) Co., Ltd. | Cross-blockchain data access method, apparatus and system, and computer readable medium |
| US20200218795A1 (en) * | 2019-01-04 | 2020-07-09 | Comcast Cable Communications, Llc | Systems and methods for device and user authorization |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023237259A1 (fr) | 2023-12-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1964077A1 (fr) | Procede de certification et d'authentification ulterieure de documents originaux papier ou numeriques pour constitution de preuves | |
| EP3803670A1 (fr) | Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié | |
| EP3552129B1 (fr) | Procédé d'enregistrement d'un contenu multimédia, procédé de détection d'une marque au sein d'un contenu multimédia, dispositifs et programme d'ordinateurs correspondants | |
| EP3241137B1 (fr) | Procede mis en oeuvre dans un document d'identite et document d'identite associe | |
| WO2009147163A1 (fr) | Procède de traçabilité et de résurgence de flux pseudonymises sur des réseaux de communication, et procède d'émission de flux informatif apte a sécuriser le trafic de données et ses destinataires | |
| BR102021002720A2 (pt) | Sistema de computador e dispositivo para controlar o uso de gravações de mídia seguras | |
| WO2006027495A1 (fr) | Protection et controle de diffusion de contenus sur reseaux de telecommunications | |
| FR3136565A1 (fr) | Procédé d’enregistrement renforcé d’un fichier numérique | |
| CA3093385A1 (fr) | Traitement securise de donnees | |
| WO2009132977A1 (fr) | Ressource de confiance integree a un dispositif de controle de donnees biometriques assurant la securite du controle et celle des donnees | |
| EP0900429A1 (fr) | Systeme securise de controle d'acces permettant le transfert d'habilitation a produire des cles | |
| FR3094521A1 (fr) | Procédés et dispositifs permettant de prouver la connaissance d’une donnée par un utilisateur d’une chaîne de blocs | |
| FR2747813A1 (fr) | Systeme securise de controle d'acces permettant l'invalidation automatique de cles electroniques volees ou perdues et/ou le transfert d'habilitation a produire des cles | |
| OA20698A (fr) | Procédé mis en œuvre par ordinateur d'établissement sécurisé d'un document de transfert de responsabilité d'un bien. | |
| WO2021084026A1 (fr) | Procede mis en œuvre par ordinateur d'etablissement securise d'un document de transfert de responsabilite d'un bien | |
| FR2898423A1 (fr) | Procede securise de configuration d'un dispositif de generation de signature electronique. | |
| FR3097666A1 (fr) | Procédé de stockage de données d’authentification de documents | |
| FR3013868A1 (fr) | Procede de transmission securisee d'une image d'un document d'identite electronique vers un terminal | |
| WO2022208016A1 (fr) | Procédé et système informatique de stockage decentralisé et de partage de fichiers numériques certifiés | |
| WO2023203301A1 (fr) | Procédé et système de gestion des droits d'accès dans une transaction équitable de données numériques | |
| EP3938957A1 (fr) | Procédé de réalisation d'une étiquette comportant un code de sécurité cache, et procédé de mise en oeuvre de l'étiquette obtenue | |
| FR3108425A1 (fr) | Procédé de traçabilité d’actions réalisées sur un site | |
| FR3113323A1 (fr) | Procede pour generer un document numerique securise stocke sur un terminal mobile et associe a une identite numerique | |
| Lee et al. | An on‐site digital investigation methodology for data leak case | |
| EP2312404A1 (fr) | Procédé de protection de documents dotés d'une carte sans contact contre la reproduction non autorisée et dispositif mettant en oeuvre un tel procédé |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20231215 |