FR3145816A1 - procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable - Google Patents

procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable Download PDF

Info

Publication number
FR3145816A1
FR3145816A1 FR2301413A FR2301413A FR3145816A1 FR 3145816 A1 FR3145816 A1 FR 3145816A1 FR 2301413 A FR2301413 A FR 2301413A FR 2301413 A FR2301413 A FR 2301413A FR 3145816 A1 FR3145816 A1 FR 3145816A1
Authority
FR
France
Prior art keywords
file
fingerprint
data
data block
access request
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.)
Granted
Application number
FR2301413A
Other languages
English (en)
Other versions
FR3145816B1 (fr
Inventor
Gabriel RISTERUCCI
Laurent HENOCQUE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Keeex
Original Assignee
Keeex
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Keeex filed Critical Keeex
Priority to FR2301413A priority Critical patent/FR3145816B1/fr
Priority to EP24703451.5A priority patent/EP4666202A1/fr
Priority to PCT/IB2024/051075 priority patent/WO2024170997A1/fr
Publication of FR3145816A1 publication Critical patent/FR3145816A1/fr
Application granted granted Critical
Publication of FR3145816B1 publication Critical patent/FR3145816B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Abstract

La présente invention concerne un procédé d’association de données variables à un fichier, le procédé comprenant des étapes de : recherche, par un processeur (T1), d’un premier emplacement d’insertion d’une donnée dans un fichier (FL1) ; insertion au premier emplacement dans le fichier d’un identifiant (BCI1) d’un bloc de donnée (BC1) d’un registre (RG1) accessible depuis un serveur distant (SRV), le bloc de données mémorisant une donnée variable relative au fichier ; calcul d’une première empreinte cryptographique (HS1) portant sur une partie du contenu du fichier incluant l’identifiant du bloc de données, à l’aide d’une fonction (HSH) de calcul d’empreinte fournissant une empreinte dépendant de tous les octets de la partie du contenu du fichier ; et transmission de l’empreinte l’identifiant du bloc de donnée au serveur distant, la donnée variable étant accessible par une requête transmise au serveur distant, contenant l’identifiant du bloc de donnée et la première empreinte. Figure pour l’abrégé : Figure 1

Description

procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable Domaine technique général
La présente invention se rapporte de manière générale aux systèmes de fichiers et aux procédés permettant d’assurer l’intégrité et l’authenticité des fichiers numériques, que ceux-ci soient distribués sur un réseau ou stockés sur un support de mémorisation.
Définitions
Dans la présente description, les termes et expressions suivantes doivent être compris comme suit.
"Fichier numérique" désigne tout fichier ou document numérique ou toute partie d’un tel fichier ou document, pouvant être manipulé séparément dans un système de gestion de fichiers quelconque.
"Métadonnée" désigne une donnée relative à une autre donnée. Une métadonnée peut figurer dans le même fichier que l'autre donnée, ou en un emplacement différent. Une métadonnée peut contenir une ou plusieurs informations relatives à l'autre donnée, y compris des informations spécifiant notamment l’emplacement, la structure et/ou la nature de cette autre donnée.
"Empreinte numérique" d’un fichier numérique désigne une donnée produite par une fonction permettant de garantir l'intégrité du contenu du fichier, de sorte que si un octet du fichier est modifié, l’empreinte numérique sera modifiée. En outre, la probabilité que deux fichiers différents aient la même empreinte est très faible. Cette fonction peut être non inversible telle que notamment une fonction de hachage cryptographique appliquée à tout ou partie du contenu du fichier. Une empreinte numérique est parfois nommée somme de contrôle, empreinte, hash, résumé de message, condensé, condensat ou encore empreinte cryptographique. La fonction de calcul d’empreinte peut combiner une fonction de hachage et une fonction de signature numérique appliquée au résultat de la fonction de hachage.
"Signature numérique" désigne une empreinte numérique traitée par un algorithme de signature numérique utilisant une clé privée d’une paire de clés publique/privée et d’un programme cryptographique asymétrique, tel que DSA (Digital Signature Algorithm) ou ECDSA (Elliptic Curve DSA). Une signature numérique permet de garantir l’authenticité d’une preuve d'intégrité d'un fichier et d'en identifier et authentifier le signataire, par analogie avec la signature manuscrite d'un document papier.
"Insertion réalisée de manière contrôlée" désigne une insertion de donnée quelle qu’elle soit dans un fichier, en un emplacement que l’utilisateur peut choisir aussi librement que le permet le type de fichier concerné. Toutefois, ceci n’exclut pas que le choix de cet emplacement puisse être réalisé par un programme, ou être normalisé.
"Insertion réalisée de manière non-destructive" désigne une insertion d’une donnée quelle qu’elle soit dans un fichier numérique, réalisée sans affecter les propriétés du fichier, c’est-à-dire sans affecter notamment son ouverture, son affichage ou impression, et son exécution si le fichier contient des instructions de programme, par les mêmes outils qu’avant cette insertion.
"Registre" désigne un dispositif fournissant une présomption d’un ordre chronologique séquentiel précis de modifications d'état d'un objet. Un registre peut être opéré par un tiers de confiance, qu'il soit ou non certifié ou agréé. Les données mémorisées dans un tel registre peuvent être plus ou moins vérifiables et/ou publiquement accessibles. Dans le cas où le registre est accessible de façon dématérialisée par exemple par internet, il peut être rendu accessible par des requêtes offrant différents services, comme des services d’interrogation, d’écriture et d’authentification. Un registre peut s’affranchir d’un tiers de confiance en se reposant sur une solution de type chaine de blocs ("blockchain"), publique ou privée, permettant ou non l'exécution de contrats intelligents ("smart contracts") et/ou le stockage de données.
Etat de la technique
Dans le contexte de l’utilisation généralisée de fichiers numériques, il est souhaitable de pouvoir remplacer les documents imprimés ou manuscrits par des fichiers numériques offrant des garanties analogues en termes de force probante. Par exemple, il est souhaitable que de tels fichiers puissent être utilisés en tant que preuves dans le cadre de transactions portant notamment sur des valeurs matérielles ou des relations contractuelles.
Le brevet US10 218 714 décrit un procédé permettant de déterminer si tout ou partie d’un fichier numérique a été modifié, grâce à l’insertion dans le fichier d’une empreinte calculée à partir de toutes les données formant le contenu du fichier pouvant inclure des métadonnées, à l’exclusion d’une zone où est insérée l’empreinte. Ainsi, si le contenu du fichier est modifié, l’empreinte calculée sur le contenu modifié du fichier est différente de l’empreinte insérée dans le fichier. Si l’empreinte est remplacée par une signature portant sur l’empreinte, ou si le fichier contient une empreinte et une signature de cette empreinte, et si la clé publique du signataire attendu figure dans les données participant au calcul de l'empreinte, seul le signataire attendu a pu générer cette signature.
Par ailleurs, dans le domaine de la gestion électronique de documents, il a été proposé un cadre conceptuel appelé "lignée de données" ("data lineage") visant à permettre de tracer le cycle de vie d’une donnée en vue de permettre de déterminer la source de cette donnée et les transformations qu’elle a subies. Ce concept de lignée de données permet par exemple d’associer à une donnée une classification de confidentialité pouvant évoluer au cours du temps, des versions successives de la donnée ou des dates de destruction obligatoire de la donnée. Ce procédé peut être déployé à l’intérieur d’une infrastructure ou d’une organisation, par des systèmes usuels de gestion électronique de documents, notamment pour tracer les auteurs, les versions et les responsables de documents.
Cependant, il n’existe aucun outil permettant de réaliser ces opérations de suivi entre infrastructures et entre organisations. En effet, une fois que le document est extrait de son système de gestion électronique de documents, il perd tous ses attributs permettant les opérations de traçage précitées. Il n’est pas non plus possible d’assurer un suivi de versions d’un même document lorsque ce dernier est sorti de son système de gestion de documents.
Il a également été proposé sous la forme d'une loi type un concept général de documents électroniques transférables (MLETR - "Loi Type sur les Documents Electroniques Transférables) permettant de tracer les propriétaires successifs et les versions d'un document ayant une valeur marchande. Aucune implémentation n'est toutefois suggérée dans ce contexte pour donner de manière irrévocable aux documents numériques un statut comparable à celui du papier signé de façon manuscrite.
Il a également été proposé d'utiliser un registre pour tracer les versions successives de documents sous des contraintes imposant un format particulier de fichiers et que toute version permette de régénérer l'unique version antérieure. Ce cadre ne décrit ni comment attacher des propriétés à un fichier existant, ni comment attester l'existence d'une pluralité de versions, ni comment permettre que les versions soient de formats et constructions distinctes, ni enfin comment désigner de manière irrévocable le registre considéré pour cette traçabilité.
Il a également été proposé d’utiliser la technique du NFT ("Non-Fungible Token" ou jeton non fongible) pour tracer la titularité d’un document, typiquement une œuvre d’art, en utilisant la technologie des contrats intelligents. Cette technique consiste à générer une donnée comprenant un jeton cryptographique représentant un objet numérique (par exemple une œuvre d’art) et une identité numérique relative au propriétaire de l’objet numérique. Cette donnée qui peut ainsi constituer un titre de propriété est stockée et authentifiée grâce à un protocole de chaine de blocs, dans un registre numérique décentralisé. Cependant, rien n’empêche qu’un document soit ainsi associé à plusieurs chaines de blocs identifiant ainsi plusieurs propriétaires simultanés.
Il est donc souhaitable de pouvoir lier de manière fiable et non falsifiable toutes les copies d’un fichier à une même donnée variable et de pouvoir déterminer toutes les données variables liées au fichier.
Des modes de réalisation concernent un procédé d’association de données variables à un fichier, le procédé comprenant des étapes consistant à : rechercher, par un processeur, un premier emplacement d’insertion d’une donnée dans un fichier ; insérer, par le processeur, au premier emplacement dans le fichier un identifiant d’un bloc de donnée d’un registre accessible depuis un serveur distant, le bloc de données mémorisant une donnée variable relative au fichier ; calculer, par le processeur, une première empreinte cryptographique portant sur une partie du contenu du fichier incluant l’identifiant du bloc de données, à l’aide d’une fonction de calcul d’empreinte, la première empreinte dépendant de tous les octets de la partie du contenu du fichier ; et transmettre la première empreinte par le processeur au serveur distant, la donnée variable étant accessible par une requête transmise au serveur distant, contenant la première empreinte.
De cette manière, il n’est pas possible de lier le fichier à un autre bloc de donnée sans modifier l’empreinte du fichier. Si le fichier est modifié, son empreinte est également modifiée. Il en résulte que le lien entre le fichier et la donnée variable dans le registre est rompu, puisque ce lien est basé sur l’empreinte du fichier. Par ailleurs, si la modification du bloc de donnée contenant la donnée variable ne peut être effectuée que par une entité habilitée, seule cette entité peut modifier la donnée variable. En d’autres termes, l’empreinte interdit de modifier l’identifiant du bloc de donnée présent dans le bloc de donnée qui contient l’empreinte, et l’empreinte ne peut pas être obtenue à partir d’un autre contenu que celui du fichier. La lecture du contenu du fichier ne peut pas permettre d’accéder à un bloc de donnée autre que celui qui est désigné par l’identifiant présent dans le fichier. Cette liaison entre le fichier et le registre est présente dans toutes les copies ou occurrences du fichier.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : recevoir par serveur distant une requête d’accès au bloc de donnée contenant la première empreinte du fichier ; déterminer par le serveur distant si un bloc de donnée contenant la première empreinte est accessible ; et exécuter par le serveur distant la requête d’accès, et fournir par le serveur distant à un émetteur de la requête d’accès un compte-rendu d’exécution de la requête d’accès.
Selon un mode de réalisation, la requête d’accès est une requête de lecture, l’exécution de la requête d’accès par le serveur distant comprenant des étapes consistant à lire les données relatives au fichier identifié par la première empreinte contenues dans le bloc de donnée et transmettre les données lues à l’émetteur de la requête d’accès, et/ou la requête d’accès est une requête de écriture contenant des données à écrire dans le bloc de données, l’exécution de la requête d’accès par le serveur distant comprenant des étapes consistant à écrire les données à écrire dans le bloc de données.
Selon un mode de réalisation, la requête d’accès est transmise en association avec une donnée d’authentification de l’émetteur de la requête d’accès, l’exécution de la requête d’accès par le serveur distant comprenant des étapes d’authentification par le serveur de l’émetteur de la requête d’accès sur la base de la donnée d’authentification, la requête d’accès étant exécutée par le serveur distant uniquement si le serveur a authentifié l’émetteur de la requête d’accès.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : rechercher, par le processeur, un second emplacement d’insertion non destructif d’une donnée dans le fichier, le second emplacement se trouvant en dehors de la partie du contenu du fichier sur laquelle porte le calcul de la première empreinte ; et insérer, par le processeur, la première empreinte au second emplacement dans le fichier.
Selon un mode de réalisation, la partie du contenu du fichier sur laquelle est appliqué la fonction de calcul d’empreinte est définie : par son étendue dans le fichier, ou par l’étendue d’une partie du fichier exclue du calcul d’empreinte.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : calculer, par le processeur, une seconde empreinte portant sur la partie du contenu du fichier sur laquelle porte le calcul de la première empreinte, à l’aide de la fonction de calcul d’empreinte ; et comparer, par le processeur, la première empreinte avec la seconde empreinte, et si les première et seconde empreintes ne sont pas identiques, alors le lien établi par l’identifiant le fichier est jugé non intègre par le processeur.
Selon un mode de réalisation, le procédé comprend des étapes consistant à insérer l’empreinte en au moins un autre emplacement dans le fichier, la vérification de l’empreinte comprenant l’application de la fonction de calcul d’empreinte au contenu du fichier en excluant toutes les occurrences de l’empreinte dans le fichier.
Selon un mode de réalisation, le procédé comprend des étapes consistant à : calculer, par le processeur, une signature numérique de la première empreinte à l’aide d’une clé privée d'une paire de clés privée et publique ; et insérer, par le processeur, la signature dans le fichier en dehors de la partie du contenu du fichier sur laquelle porte le calcul de la première empreinte, l’accès au bloc de donnée étant conditionné par la fourniture au serveur distant d’une signature numérique valide vérifiée à l’aide de la clé publique de la paire de clés privée et publique.
Selon un mode de réalisation, la clé publique est insérée dans une métadonnée dans la partie du fichier sur laquelle porte le calcul de la première empreinte.
Selon un mode de réalisation, le bloc de donnée référencé par l’identifiant est une chaine de blocs cryptographiques.
Selon un mode de réalisation, le calcul de chaque empreinte comprend une étape d’insertion d’une donnée prédéfinie dans la partie du contenu du fichier avant d’appliquer la fonction de calcul d’empreinte à la partie de fichier.
Des modes de réalisation peuvent également concerner un produit programme d’ordinateur comprenant des portions de fichier de programme enregistrées sur un support lisible par un ordinateur, configurées pour mettre en œuvre les étapes du procédé tel que précédemment défini.
Selon un mode de réalisation, au moins une partie du programme est inclus dans le fichier.
Brève description des figures
D’autres avantages pourront encore apparaître à l’homme du métier à la lecture des exemples ci-dessous, donnés à titre illustratif et illustrés par les figures annexées, dans lesquelles des signes de références identiques correspondent à des éléments structurellement et/ou fonctionnellement identiques ou similaires.
La figure 1 représente schématiquement un ensemble d’étapes d’un procédé exécuté pour créer un fichier et l’associer à un registre, selon un mode de réalisation,
La figure 2 représente schématiquement un fichier associé à un registre, selon un mode de réalisation,
La figure 3 représente schématiquement un ensemble d’étapes d’un procédé de vérification de l’intégrité d’un fichier et de lecture de données variables associées au fichier, selon un mode de réalisation,
La figure 4 représente schématiquement un ensemble d’étapes d’un procédé de vérification de l’intégrité d’un fichier et d’écriture de données variables associées au fichier, selon un mode de réalisation.
 Description détaillée
La figure 1 représente des étapes S1 à S5 d’un procédé de création d’un fichier à partir d’un fichier existant FL1. Le procédé peut être mis en œuvre par un terminal T1 et un serveur SRV interconnectés, par exemple par l’intermédiaire d’un réseau NT de transmission de données. Ainsi, le terminal T1 et le serveur SRV peuvent établir entre eux une relation client-serveur. La figure 2 représente le fichier FL1 et un registre RG1. Initialement, le fichier FL1 peut être vide ou plein.
Les étapes S1 à S4 sont exécutées successivement par le terminal T1. A l’étape S1, le terminal T1 insère une référence BCI1 à un bloc de donnée BC1 du registre RG1 dans le fichier FL1. Cette insertion est réalisée de manière contrôlée et potentiellement non-destructive, par exemple en encapsulant la référence BCI1 dans une métadonnée. La référence BCI1 contient les informations permettant de retrouver le registre RG1 et le bloc de données BC1 dans le registre. Selon les cas, ces informations peuvent comprendre notamment une donnée d’identification (par exemple l’adresse) du serveur SRV afin de permettre de déterminer à quel serveur il convient de s’adresser pour avoir accès au bloc de donnée BC1.
A l’étape S2, le terminal T1 calcule une empreinte HS1 du fichier FL1 à l’aide d’une fonction HSH de calcul d’empreinte recevant en entrée tout ou partie du contenu du fichier, y compris la référence BCI1 ou la métadonnée incluant cette référence et le cas échéant, la donnée d’identification du serveur SRV. La fonction HSH peut être une fonction de hachage cryptographique et/ou une fonction de signature numérique. A l’étape S3, le terminal T1 insère l’empreinte HS1 dans le fichier FL1 en un emplacement qui ne sera pas pris en compte pour le calcul de l’empreinte du fichier FL1. L’étape S3 est optionnelle et donc peut être omise, sachant que l’empreinte HS1 du fichier FL1 peut être recalculée à partir du fichier FL1 seul.
L’empreinte HS1 peut être associée à un repère permettant de retrouver son emplacement et son étendue dans le fichier FL1. L’empreinte HS1 peut être signée numériquement préalablement à son insertion dans le fichier FL1. La fonction de calcul d’empreinte peut être appliquée à tout ou partie du fichier FL1.
A l’étape S4, le terminal T1 transmet l’empreinte HS1 au serveur SRV. L’empreinte HS1 peut être transmise au serveur SRV sous la forme d’une requête de mise à jour du bloc de donnée BC1, incluant éventuellement l’identifiant BCI1 du bloc BC1 où elle doit être enregistrée dans le registre RG1, et éventuellement une signature numérique de l’empreinte HS1. A l’étape S5, le serveur SRV reçoit l’empreinte HS1 et l’insère dans le bloc de donnée BC1 du registre RG1.
De cette manière, la consultation du registre RG1 permet d’identifier le fichier FL1 et réciproquement, la consultation du fichier FL1 permet d’identifier le registre RG1. Lorsque l’étape S3 d’insertion de l'empreinte HS1 dans le fichier FL1 est exécutée, l’empreinte peut être utilisée pour trouver une occurrence du fichier FL1 sur les espaces de stockage de l'utilisateur par des outils informatiques système. Par ailleurs, que l’empreinte HS1 soit insérée ou non dans le fichier FL1, elle peut être confirmée en interrogeant le serveur SRV, à l’aide de l’identifiant BCI1 figurant dans le fichier FL1.
Le bloc de donnée BC1 peut contenir une donnée relative au fichier FL1, qui peut être modifiée. Ainsi, une consultation du registre RG1 sur la base de l’identifiant BCI1 trouvé dans le fichier FL1 donne accès à cette donnée modifiable. En revanche, si la référence BCI1 est modifiée dans le fichier FL1, l’empreinte calculée sur le fichier ainsi modifié est différente de l’empreinte HS1. Il n’est donc pas possible d’accéder au bloc de donnée BCI1 à partir du fichier modifié, ni de retrouver le fichier modifié à partir de l’empreinte HS1 se trouvant dans le bloc de donnée BC1 du registre. Par conséquent, l’existence de l’empreinte HS1 interdit la modification de l’identifiant BCI1 dans le fichier FL1. Par ailleurs, l’identifiant BCI1 identifie de manière certaine le bloc de donnée BC1 dans le registre RG1, lequel contient l’empreinte HS1 qui identifie de manière certaine le fichier FL1. Il est à noter qu’il est extrêmement difficile de générer un fichier ayant une empreinte prédéfinie, et qu’il est extrêmement peu probable (probabilité inférieure à 10-77) que deux fichiers aient la même empreinte. Il est donc extrêmement probable que l’empreinte HS1 n’a pas été insérée dans le bloc de donnée BC1 avant qu’elle soit calculée sur le fichier FL1 après insertion de l’identifiant BCI1.
Les liens formés par les données BCI1 et HS1 entre le fichier FL1 et le registre RG1 ne dépendent pas d’un emplacement physique de stockage du fichier ou du registre ou d’un système de fichiers tel que NTFS (New Technology File System) ou FAT (File Allocation Table). Ces liens peuvent être vérifiés quels que soient la copie du fichier FL1 considérée et l’emplacement physique où cette copie est stockée.
L’accès en écriture au registre RG1 réalisé à l’étape S5 peut être limité à une ou plusieurs personnes dûment habilitées.
Selon un mode de réalisation, le fichier FL1, éventuellement avec son empreinte HS1 embarquée, est publié sur une plateforme identifiant les fichiers par leur empreinte, par exemple sur le modèle de IPFS ("InterPlanetary File System") pour des empreintes calculées sur la totalité du fichier.
La figure 3 représente des étapes S11 à S18 d’un procédé d’accès en lecture à des données variables associées à un fichier tel que le fichier FL1, après avoir été traité durant les étapes S1 et S2 et éventuellement S3, pour recevoir un identifiant de bloc de donnée BCI1 et pour le calcul de l’empreinte HS1. Le terminal T1 exécute tout d’abord les étapes S11 à S14. A l’étape S11, le terminal T1 calcule une empreinte HS2 du fichier en appliquant la fonction de calcul d’empreinte HSH utilisée à l’étape S2 au contenu du fichier FL1. Si l’empreinte HS1 a été insérée dans le fichier FL1, celle-ci est exclue du contenu du fichier auquel est appliquée la fonction HSH. A cet effet, la position de l’empreinte HS1 dans le fichier peut être repérée à l’aide d’un repère. Le repère peut spécifier une ou plusieurs zones exclues du contenu du fichier, sur lequel le calcul d’empreinte doit être appliqué, ou spécifier la ou les zones du contenu du fichier auxquelles le calcul d’empreinte est appliqué. L’étape S12 est optionnelle, notamment si l’empreinte HS1 ne figure pas dans le fichier FL1. A l’étape S12, le terminal T1 compare l’empreinte calculée HS2 avec l’empreinte HS1 préalablement associée au fichier FL1. Si les empreintes HS1 et HS2 correspondent ou sont identiques, le contenu du fichier FL1 sur lequel porte le calcul d’empreinte n’a pas été modifié depuis le calcul de l’empreinte HS1. Dans le cas contraire, le fichier FL1 peut avoir été modifié, ou la fonction de calcul d’empreinte utilisée ne correspond pas à celle utilisée pour le calcul de l’empreinte HS1, ou encore l’étendue du contenu du fichier sur lequel porte le calcul d’empreinte ne correspond pas à celui pris en compte pour le calcul de l’empreinte HS1. L’étape S12 peut comprendre d’autres vérifications comme la vérification d’une signature numérique permettant de déterminer l’authenticité du fichier.
L’exécution des étapes S13, S14 peut être conditionnée au succès de la comparaison des empreintes HS1 et HS2 à l’étape S12. A l’étape S13, le terminal T1 lit dans le fichier FL1 l’identifiant BCI1 du bloc de donnée BC1 du registre RG1 où sont stockées les données relatives au fichier FL1. A cette étape, l’identifiant BCI1 peut être considéré comme authentique si l’étape S12 de comparaison a été exécutée et avec succès. A l’étape S14, le terminal T1 peut transmettre au serveur SRV une requête de lecture RQR d’informations relatives au fichier FL1 stockées dans le registre RG1. A cet effet, la requête RQR contient une information permettant d’identifier le fichier FL1, telle que l’empreinte HS2, et éventuellement tout ou partie de identifiant BCI1 du bloc de donnée BC1. A l’étape S15, le serveur SRV reçoit cette requête et détermine si un bloc de donnée du registre RG1 contient bien l’empreinte HS2 transmise à l’étape S14, et éventuellement que l’empreinte HS2 se trouve bien dans un bloc de donnée du registre RG1, correspondant le cas échéant à la partie de l’identifiant BCI1 reçue. L’étape S15 permet de déterminer que l’empreinte HS2 reçue a bien été précédemment associée au bloc de donnée BC1 du registre RG1, éventuellement correspondant à la partie de l’identifiant BCI1 reçue à l’étape S14. La vérification effectuée à l’étape S15 permet indirectement de déterminer que le fichier FL1 est intègre si l’empreinte reçue HS2 a bien été calculée à partir du contenu du fichier FL1. Si Si le test effectué à l’étape S15 est positif, alors le serveur SRV exécute les étapes S16 et S17. A l’étape S16, le serveur SRV lit les informations contenues dans le bloc de donnée BC1 où se trouve l’empreinte HS2. A l’étape S17, le serveur SRV transmet les informations Inf(BC1,HS2) lues dans le bloc de donnée BC1 au terminal T1. A l’étape S18, le terminal T1 reçoit et exploite les informations Inf(BC1,HS2) reçues.
Selon un mode de réalisation, les informations Inf(BC1,HS2) comprennent une liste d’identifiants (d’empreintes) de fichiers correspondant à différentes versions du fichier FL1. Ceci présuppose qu’à chaque création d’une nouvelle version du fichier FL1, les étapes S1 à S5 sont exécutées en utilisant le même identifiant BCI1 de bloc de donnée BC1 et en remplaçant l’empreinte figurant dans le fichier par la nouvelle empreinte calculée sur la nouvelle version du fichier. Ainsi le bloc de donnée BC1 comprend pour chaque version du fichier FL1 un enregistrement comportant l’empreinte de la version du fichier. Ainsi la donnée variable associée au fichier FL1 dans le bloc de donnée BC1 est l'empreinte de la plus récente version connue (ou selon les modalités techniques la liste des versions connues) du fichier FL1, enregistrées successivement dans le bloc de donnée BC1. Le choix fait par l'utilisateur de considérer qu'un fichier constitue une version nouvelle d'un autre fichier est arbitraire et ne dépend ni des modalités de production, ni du format du fichier. Le registre RG1 peut fournir la liste des empreintes de versions d’un même fichier, mais ne donne pas accès au contenu de ces versions.
Selon un mode de réalisation, les informations Inf(BC1,HS2) comprennent un ou plusieurs états de contrat intelligent. Selon un exemple de réalisation, le fichier FL1 contient une œuvre d’art numérique, et le bloc de donnée BC1 contient un ou plusieurs états de contrat intelligent contenant des données relatives au propriétaire du fichier FL1 comme des données d’identification du propriétaire et des données relatives à l’achat par le propriétaire de l’œuvre d’art numérique comme la date d’achat et le prix d’achat. Ainsi, la donnée variable associée au fichier FL1 dans le bloc de donnée BC1 comprend la liste des transactions de transfert de propriété de l’œuvre d’art, enregistrées successivement dans le bloc de donnée ou BC1. Chaque transaction peut rassembler des données telles que la date de la transaction, des informations sur l’identité du nouveau propriétaire, et le montant de la transaction.
Il est à noter que le registre RG1 peut être accessible en lecture et vérifiable par tous ou seulement par certaines personnes habilitées, en activant les étapes S14 à S18. Il est donc possible même pour un acteur ne détenant pas le fichier FL1 ou l’une de ses versions enregistrées, de connaitre par exemple la liste de toutes les versions du fichier FL1, telles qu’enregistrées dans le registre RG1 ou la liste de toutes les transactions portant sur le fichier FL1, enregistrées dans le registre RG1.
La figure 4 représente des étapes S21 à S28 d’un procédé d’accès en écriture à des données variables associées à un fichier tel que le fichier FL1 après avoir été traité durant les étapes S1 et S2 et éventuellement S3. Les étapes S21 à S23 peuvent être identiques aux étapes S11 à S13, respectivement, l’étape S22 étant également facultative, notamment si l’empreinte HS1 n’a pas été insérée dans le fichier FL1.
L’écriture dans le registre RG1 peut nécessiter l’exécution d’une procédure d’authentification (étape S24), par exemple entre le terminal T1 si celui-ci doit accéder au registre RG1 en écriture, et le serveur SRV. L’authentification du terminal T1 par le serveur SRV peut être réalisée par tout moyen requis par le serveur, comme la fourniture par le terminal au serveur d’un identifiant et d’un mot de passe, ou la fourniture d’une preuve de capacité à signer avec une identité attendue par le serveur SRV. A cet effet, le registre RG1 peut mémoriser en association avec le bloc de donnée BC1, une ou plusieurs clés publiques permettant de vérifier une signature numérique, la signature étant générée à l’aide d’une fonction de calcul de signature recevant en entrée une donnée et une clé privée correspondant à une clé publique mémorisée par le serveur. Si la procédure d’authentification échoue à l’étape S24, le serveur SRV peut le notifier au terminal T1 à l’étape S28. Si le terminal T1 (ou l’utilisateur du terminal) est authentifié, celui-ci peut transmettre au serveur SRV une requête d’écriture RQW contenant l’information à inscrire dans le bloc de donnée BC1 dans le registre RG1 (étape S25). La requête d’écriture contient l’empreinte du fichier HS1 lié au bloc de donnée BC1, les données à écrire DT, et éventuellement tout ou partie de l’identifiant BCI1 du bloc de donnée BC1 où l’opération d’écriture doit être effectuée. A noter que les étapes S24 et S25 peuvent être effectuées simultanément. Dans ce cas, la requête d’écriture RQW contient les informations d’authentification requises par le serveur.
A l’étape S26, le serveur SRV reçoit la requête d’écriture RQW et vérifie qu’elle est réalisable. A cet effet, il exécute l’étape S26 qui peut être identique à l’étape S15. Ainsi, à l’étape S26, le serveur SRV détermine si un bloc de donnée du registre RG1 contient bien l’empreinte HS2 du fichier FL1 transmise à l’étape S25, et éventuellement que l’empreinte HS2 se trouve bien dans un bloc de donnée correspondant à la partie de l’identifiant BCI1 transmise. Si le test effectué à l’étape S26 est positif, alors le serveur SRV exécute les étapes S27 et S28. A l’étape S27, le serveur SRV exécute l’opération d’écriture des donnés DT reçues dans le bloc de donnée BC1 identifié à l’étape S26. A l’étape S28 transmet au terminal T1 un message de compte rendu (positif ou négatif) de l’exécution de l’opération d’écriture. Ce message de compte rendu est négatif si, pour une raison quelconque, le serveur SRV n’a pas réalisé la requête d’écriture. Des règles d’accès en écriture au bloc de donnée BC1 peuvent être spécifiées dans le bloc de données ou associées à celui-ci. Dans ce cas, le serveur SRV se limite à lire et assurer la prise en compte de ces règles, notamment pour refuser ou accepter une écriture dans le bloc de donnée BC1.
L’étape S27 peut constituer une première écriture dans le bloc de donnée BC1. Ce cas peut se présenter par exemple lorsque l’identifiant BCl1 n’est pas reconnu à l’étape S26 par le serveur SRV.
Selon un mode de réalisation, le registre RG1 est géré par un tiers de confiance, garantissant l’intégrité et l’authenticité des données du registre.
Selon un autre mode de réalisation, le bloc de donnée BC1 est une chaine de blocs cryptographique (blockchain). Dans ce cas, l’étape S5 d’insertion de l’empreinte HS1 dans le bloc de donnée BC1 et l’étape S27 d’écriture dans le bloc de donnée BC1 sont effectuées en générant des données d’une nouvelle transaction dans bloc de donnée de la chaine de blocs, incluant l’empreinte HS1.
Selon un mode de réalisation, l’identifiant BCI1 référence un contrat intelligent dans une chaine de blocs. Dans ce cas, les requêtes de lecture RQR et/ou d’écriture RQW peuvent contenir la référence d’une fonction associée au contrat intelligent à exécuter par le serveur SRV.
Selon un mode de réalisation, l’empreinte HS1 est signée en transmettant une requête à un serveur de temps fournissant un horodatage légal, par exemple selon la norme RFC3161. Le serveur de temps fournit une donnée d’horodatage qui peut également être insérée dans le fichier FL1 à l‘étape S3. La signature numérique de l’empreinte HS1 est également insérée dans le bloc de donnée BC1 aux étapes S5 et S27.
Selon un mode de réalisation, les fonctions décrites ci-dessus de mise à jour de la chaine de blocs BC1 sont réalisées par plusieurs serveurs, appelés "mineurs", exécutant les mêmes opérations en parallèle, comme cela est généralement effectué lors de l’enregistrement d’une transaction dans une chaine de blocs. Les opérations réalisées par les serveurs sont appelées des opérations de "minage". Cette disposition permet d’assurer une plus grande sécurité en ce qui concerne notamment le contenu du registre RG1 qui est par ailleurs généré à l’identique et de manière sécurisée par plusieurs serveurs.
Selon un mode de réalisation, l’empreinte HS1 est transmise à l’étape S4 avec un identifiant d’un groupe de fichiers auquel le fichier FL1 appartient. Cet identifiant de groupe de fichiers peut être inséré dans le fichier FL1 par exemple dans une métadonnée à l’étape S1 et être pris en compte dans le calcul de l’empreinte HS1 effectué à l‘étape S2. L’identifiant de groupe est inséré dans le bloc de donnée BC1 à l’étape S5. De cette manière, une requête de lecture comme celle RQR transmise à l’étape S14, et incluant cet identifiant de groupe de fichiers, peut permettre d’obtenir du serveur SRV les empreintes de tous les fichiers appartenant au groupe correspondant à l’identifiant de groupe de fichiers transmis. Les empreintes peuvent ensuite être utilisées pour retrouver les fichiers correspondant appartenant au groupe de fichiers. Ces dispositions permettent par exemple d’obtenir les empreintes de toutes les versions d’un même fichier, ou de tous les fichiers associés à un mot clé donné, sans limitation. Il est donc possible de reproduire des mécanismes habituels de gestion électronique de documents, sans imposer que les documents soient rassemblés dans un espace de stockage particulier.
Selon un mode de réalisation, le fichier FL1 contient des instructions de programme, et l’empreinte HS1 est insérée dans le fichier FL1 par exemple, dans un commentaire de programme, dans une section du fichier destinée à recevoir des métadonnées en texte clair (pdf, jpg), ou à la fin d’un fichier binaire (zip, exe).
Selon un mode de réalisation, le fichier FL1 contient des instructions de programme, et une instance de l'empreinte HS1 est insérée dans le fichier FL1 à un emplacement permettant sa prise en compte par le programme, par exemple pour permettre l'affichage d'un code optique (ex. QR Code ou "Quick Response Code") identifiant exactement le fichier par exemple dans un format tel que HTML ("HyperText Markup Language") ou pdf ("portable document format").
Selon un exemple de réalisation, l’étape S14 et/ou S25 comprend en outre la transmission au server SRV d’instructions de programme figurant dans le fichier FL1, par exemple dans la partie soumise au calcul d’empreinte pour obtenir l’empreinte HS1. Les instructions de programme transmises sont à exécuter par le serveur SRV pour réaliser des opérations sur le bloc de donnée BC1.
L’empreinte selon son type peut constituer à elle seule le repère permettant de la localiser dans le fichier FL1. C’est par exemple le cas lorsque la métadonnée est d’un format suffisamment spécifique pour pouvoir être localisée dans le fichier au moyen d’une expression régulière. Ainsi le repère peut être une mise en forme spécifique, une chaîne de caractères spécifique connue pour figurer dans la métadonnée d’identification d’un bloc de données, des séparateurs réguliers, etc. La mise en forme peut être connue de façon implicite puisque définie par défaut, par exemple, une métadonnée constituée des 30 premiers caractères de la représentation hexadécimale d’une empreinte "SHA256", avec un tiret séparateur tous les 5 caractères.
Le repère n’est pas nécessairement à l’emplacement de l’empreinte dans le fichier, mais peut indiquer cet emplacement, par exemple par rapport au début ou à la fin du fichier, ou par rapport à la position du repère dans le fichier. Ainsi le repère peut être associé à une information utile à la localisation de l’empreinte, telle qu’une position définie par rapport au repère, ou bien par rapport au début ou à la fin du fichier. L’empreinte HS1 peut être insérée dans le fichier FL1 sous la forme ou dans une métadonnée utilisée pour identifier le fichier. Lorsque l’empreinte ou la métadonnée qui la contient ne permet pas à elle seule de localiser l’empreinte, le repère peut être inséré dans le fichier ou la métadonnée.
En outre, l’empreinte HS1 selon son type peut renseigner à elle seule sur le calcul ou algorithme de calcul ou encodage ayant permis sa génération. L’empreinte peut également être associée à une métadonnée spécifiant le nom de l’algorithme de calcul utilisé pour la génération de l’empreinte, tel que "md5", ou "sha1", ou le nom de l’encodage, tel que "hex" (pour hexadécimal), "b64" (pour base 64), ou "bubble-babble". En outre, l’algorithme ou l’encodage peut être connu de façon implicite puisque défini par défaut. Si l’empreinte HS1 est insérée dans une métadonnée, cette information de type de calcul d’empreinte peut être insérée dans la même métadonnée que l’empreinte. La métadonnée contenant l’information de type de calcul d’empreinte peut également être insérée dans une section protégée telle que décrite précédemment.
Selon un mode de réalisation, l’empreinte HS1 est insérée dans le fichier FL1 en association avec ou sous la forme d’une signature numérique générée en appliquant une fonction de calcul de signature à l’empreinte du fichier et une clé privée d’une paire de clés publique/privée. La vérification de la signature numérique peut consister à appliquer une fonction de vérification de signature correspondante, au triplet comprenant l’empreinte HS1, la signature et la clé publique de la paire de clés publique/privée, pour prouver que la signature signe valablement l’empreinte HS1 par la clé privée, l’empreinte HS1 contenue dans le fichier n’étant pas prise en compte dans le calcul de l’empreinte.
Une ou plusieurs métadonnées figurant dans le fichier FL1 peuvent fournir les paramètres nécessaires à la vérification. Ces paramètres peuvent indiquer le type d’algorithme utilisé pour générer l’empreinte et/ou la signature numérique. Ces paramètres peuvent fournir l’adresse de courrier électronique d’un signataire, et/ou la clé publique correspondante ou une dérivation de cette dernière. Dans tous les cas, il est préférable que ces métadonnées soient prises en compte dans le calcul de l’empreinte HS1.
Dans le cas où la signature numérique de l’empreinte HS1 est calculée, elle peut être transmise au serveur à l’étape S14 et/ou S25. Cela permet au serveur SRV de vérifier que la requête RQR et/ou RQW est émise par le signataire du fichier lui-même qui peut être le seul légitime à le faire.
Selon un mode de réalisation, les étapes S1 à S3 sont effectuées par un tiers de confiance à qui le fichier FL1 a été précédemment transmis, par exemple le serveur SRV. De cette manière, on est assuré que l’empreinte HS1 est bien celle du fichier FL1 dans lequel se trouve l’identifiant BCI1 pris en compte pour le calcul de l’empreinte. Cependant, la génération de l’empreinte par un tiers de confiance peut poser le problème de la confidentialité du contenu du fichier FL1. La preuve que l’empreinte HS1 a bien été calculée sur une partie du fichier FL1 contenant l’identifiant BCI1 peut également être apportée par un protocole d’établissement de preuve à connaissance nulle ("zero knowledge") dans lequel l’entité qui génère la preuve n’a pas besoin de connaître le contenu du fichier FL1. Ainsi, la confidentialité du contenu du fichier FL1 peut être assurée.
Selon un mode de réalisation, l’une des métadonnées du fichier FL1 peut contenir une information prise en compte lors du calcul de l’empreinte HS1.
Selon un mode de réalisation, certaines métadonnées du fichier FL1 sont prises en compte lors du calcul de l’empreinte HS1, HS2, et d’autres sont exclues de ce calcul.
Selon un mode de réalisation, le calcul de l’empreinte HS1 (étape S2) comprend l’insertion préalable d’une donnée prédéfinie dans le fichier FL1, éventuellement à l’emplacement de l’empreinte HS1 dans le fichier. Dans ce cas, le calcul de l’empreinte HS1 tenant compte des bits de la donnée prédéfinie insérée dans le fichier. Dans ce cas, le calcul de l’empreinte HS2 (étape S12) comprend l’insertion préalable de la donnée prédéfinie dans le fichier FL1, à la place et en remplacement de l’empreinte HS1 lorsque celle-ci est insérée dans le fichier FL1.
Selon un mode de réalisation, l’empreinte HS1 est introduite dans le fichier FL1 en plusieurs emplacements, l’empreinte étant calculée en excluant les bits de l’empreinte dans tous les emplacements où l’empreinte est insérée. A cet effet, une marque servant de repère peut être insérée en plusieurs emplacements dans le fichier FL1, l’empreinte HS1 étant calculée en excluant la marque ou non, puis insérée à la place de la marque à ces emplacements. Ainsi, l’empreinte peut être insérée dans une zone utile du fichier FL1, par exemple pour pouvoir être visualisée lorsque le contenu du fichier est affiché, notamment dans le cas où les métadonnées ne sont pas affichées par le logiciel d’affichage du fichier.
Pour vérifier que l’empreinte HS1 figurant dans le fichier a bien été calculée à partir du fichier FL1, un repère peut être utilisé pour retrouver un premier emplacement d’insertion de l’empreinte dans le fichier, et l’empreinte ainsi retrouvée peut être utilisée pour rechercher toutes les autres occurrences de l’empreinte dans le fichier. L’empreinte HS2 est alors calculée en excluant toutes les occurrences de l’empreinte HS1 dans le fichier FL1, la marque étant le cas échéant, préalablement insérée à la place des occurrences de l’empreinte HS1 trouvées dans le fichier FL1.
Selon un mode de réalisation, les étapes S2, S3 sont exécutées plusieurs fois en cascade pour insérer dans le fichier FL1 plusieurs empreintes. Ainsi, chaque exécution des étapes S2, S3 introduit dans le fichier FL1 une nouvelle empreinte HS1, calculée sur le fichier dans l’état où il se trouve au début de chaque nouvelle exécution des étapes S2, S3, la ou les empreintes insérées précédemment étant prises en compte dans le calcul d’une nouvelle empreinte qui est ensuite insérée dans le fichier FL1.
En permettant ainsi d’insérer dans un fichier, en cascade plusieurs empreintes HS1, le procédé permet donc, en plus de la possibilité d’utiliser des algorithmes de calcul déjà connus comme résistants, de se protéger des attaques de "pré image" sur une empreinte de façon très robuste en combinant plusieurs empreintes dans un même fichier. En effet, une attaque de "pré image" devrait pour aboutir, non seulement produire un fichier qui possède exactement et toutes les mêmes empreintes, et qui de surcroit puisse passer valablement pour le fichier d’origine. Cette attaque est déjà très difficile à réaliser lorsqu’il n’y a qu’une empreinte à contrefaire, et devient pratiquement impossible avec les technologies connues lorsque plusieurs empreintes sont combinées en cascade.
Selon un mode de réalisation, certaines métadonnées du fichier FL1 comprennent une partie invariable et une partie variable, et seule la partie variable d’une métadonnée n’est pas prise en compte pour le calcul de l’empreinte HS1.
Il apparaîtra clairement à l’homme de l’art que la présente invention est susceptible de diverses variantes de réalisation et diverses applications. Ainsi, les modes de réalisation précédemment décrits doivent être considérés à titre d’illustration, et peuvent être modifiés dans le domaine défini par la portée des revendications jointes. En particulier, l’émetteur des requêtes de lecture RQR et d’écriture RQW émises aux étapes S14 et S25 n’est pas nécessairement le terminal T1, mais toute entité habilitée à procéder à des lectures et/ou des écritures dans le bloc de donnée BC1 du registre RG1, et le cas échéant, préalablement identifiée par le serveur SRV.
Par ailleurs, il est possible de lier le fichier FL1 à plusieurs blocs de données figurant dans le registre RG1 ou dans différents registres accessibles par l’intermédiaire de différents serveurs. A cet effet, plusieurs identifiants de blocs de donnée peuvent être insérés dans la partie du fichier FL1 sur laquelle porte le calcul de l’empreinte HL1.
En outre, une empreinte cryptographique étant unique, l’empreinte HS1 peut dans de nombreux cas seule suffire au serveur SRV pour identifier le bloc de donnée BC1 à accéder, dès lors que l’empreinte HS1 figure déjà dans le bloc de donnée, par exemple à l’issue de l’étape S5. Il en résulte que l’identifiant BCI1 du bloc de donnée BC1 inséré dans le fichier FL1 peut être configuré pour identifier seulement le serveur SRV et/ou le registre RG1. Il en résulte dans certains cas que l’identifiant BCI1 n’a pas besoin d’être transmis, y compris partiellement, dans ces requêtes aux étapes S14 et S25, mais sert uniquement à déterminer comment adresser les requêtes RQR et RQW au serveur SRV.
Plus généralement, l’identifiant BCI1 du bloc de donnée BC1 inséré dans le fichier FL1 peut être configuré pour identifier seulement le bloc de donnée BC1 où se trouve l’empreinte HS1, ou bien identifier à la fois le bloc de donnée BC1 et le serveur SRV qui donne accès au bloc de donnée, ou encore identifier seulement le serveur SRV si ce dernier peut localiser le bloc de donnée BC1 uniquement sur la base de l’empreinte HS2 qui lui a été transmise.
Par ailleurs, la présente invention ne s’applique pas uniquement à la traçabilité des versions ou propriétaires des fichiers, mais couvre un très grand nombre de situations notamment en gestion électronique de documents (mots clé, informations de classification…), ainsi que dans l'industrie (transfert de responsabilité pour maintenance, changements de pièces dans un assemblage…).

Claims (14)

  1. Procédé d’association de données variables à un fichier, le procédé comprenant des étapes consistant à :
    rechercher, par un processeur (T1), un premier emplacement d’insertion d’une donnée dans un fichier (FL1) ;
    insérer, par le processeur, au premier emplacement dans le fichier un identifiant (BCI1) d’un bloc de donnée (BC1) d’un registre (RG1) accessible depuis un serveur distant (SRV), le bloc de données mémorisant une donnée variable relative au fichier ;
    calculer, par le processeur, une première empreinte cryptographique (HS1) portant sur une partie du contenu du fichier incluant l’identifiant du bloc de données, à l’aide d’une fonction (HSH) de calcul d’empreinte, la première empreinte dépendant de tous les octets de la partie du contenu du fichier ; et
    transmettre la première empreinte par le processeur au serveur distant, la donnée variable étant accessible par une requête transmise au serveur distant, contenant la première empreinte.
  2. Procédé selon la revendication 1, comprenant des étapes consistant à :
    recevoir par serveur distant (SRV) une requête d’accès (RQR, RQW) au bloc de donnée (BC1) contenant la première empreinte (HS1) du fichier ;
    déterminer par le serveur distant si un bloc de donnée contenant la première empreinte est accessible ; et
    exécuter par le serveur distant la requête d’accès, et fournir par le serveur distant à un émetteur (T1) de la requête d’accès un compte-rendu d’exécution de la requête d’accès.
  3. Procédé selon la revendication 2, dans lequel :
    la requête d’accès est une requête de lecture (RQR), l’exécution de la requête d’accès par le serveur distant (SRV) comprenant des étapes consistant à lire les données relatives au fichier identifié par la première empreinte (HS1) contenues dans le bloc de donnée (BC1) et transmettre les données lues à l’émetteur de la requête d’accès, et/ou
    la requête d’accès est une requête de écriture (RQW) contenant des données à écrire dans le bloc de données (BC1), l’exécution de la requête d’accès par le serveur distant (SRV) comprenant des étapes consistant à écrire les données à écrire dans le bloc de données.
  4. Procédé selon la revendication 3, dans lequel la requête d’accès (RQR, RQW) est transmise en association avec une donnée d’authentification de l’émetteur (T1) de la requête d’accès, l’exécution de la requête d’accès par le serveur distant comprenant des étapes d’authentification par le serveur de l’émetteur de la requête d’accès sur la base de la donnée d’authentification, la requête d’accès étant exécutée par le serveur distant (SRV) uniquement si le serveur a authentifié l’émetteur de la requête d’accès.
  5. Procédé selon l’une des revendications 1 à 4, comprenant des étapes consistant à :
    rechercher, par le processeur (T1), un second emplacement d’insertion non destructif d’une donnée dans le fichier (FL1), le second emplacement se trouvant en dehors de la partie du contenu du fichier sur laquelle porte le calcul de la première empreinte ; et
    insérer, par le processeur (T1), la première empreinte au second emplacement dans le fichier.
  6. Procédé selon la revendication 5, dans lequel la partie du contenu du fichier (FL1) sur laquelle est appliqué la fonction de calcul d’empreinte (HSH) est définie :
    par son étendue dans le fichier (FL1), ou
    par l’étendue d’une partie du fichier (FL1) exclue du calcul d’empreinte.
  7. Procédé selon la revendication 5 ou 6, comprenant des étapes consistant à :
    calculer, par le processeur (T1), une seconde empreinte (HS2) portant sur la partie du contenu du fichier sur laquelle porte le calcul de la première empreinte (HS1), à l’aide de la fonction (HSH) de calcul d’empreinte ; et
    comparer, par le processeur (T1), la première empreinte avec la seconde empreinte, et si les première et seconde empreintes ne sont pas identiques, alors le lien établi par l’identifiant le fichier est jugé non intègre par le processeur (T1).
  8. Procédé selon l’une des revendications 5 à 7, comprenant des étapes consistant à insérer l’empreinte (HS1) en au moins un autre emplacement dans le fichier (FL1), la vérification de l’empreinte comprenant l’application de la fonction (HSH) de calcul d’empreinte au contenu du fichier en excluant toutes les occurrences de l’empreinte dans le fichier.
  9. Procédé selon l’une des revendications 1 à 8, comprenant des étapes consistant à :
    calculer, par le processeur (T1), une signature numérique de la première empreinte (HS1) à l’aide d’une clé privée d'une paire de clés privée et publique ; et
    insérer, par le processeur, la signature dans le fichier (FL1) en dehors de la partie du contenu du fichier sur laquelle porte le calcul de la première empreinte, l’accès au bloc de donnée (BC1) étant conditionné par la fourniture au serveur distant (SRV) d’une signature numérique valide vérifiée à l’aide de la clé publique de la paire de clés privée et publique.
  10. Procédé selon la revendication 9, dans lequel la clé publique est insérée dans une métadonnée dans la partie du fichier (FL1) sur laquelle porte le calcul de la première empreinte (HS1).
  11. Procédé selon l’une des revendications 1 à 10, dans lequel le bloc de donnée (BC1) référencé par l’identifiant (BCI1) est une chaine de blocs cryptographiques.
  12. Procédé selon l’une des revendications 1 à 11, dans lequel le calcul de chaque empreinte (HS1, HS2) comprend une étape d’insertion d’une donnée prédéfinie dans la partie du contenu du fichier (FL1) avant d’appliquer la fonction (HSH) de calcul d’empreinte à la partie de fichier.
  13. Produit programme d’ordinateur comprenant des portions de fichier de programme enregistrées sur un support lisible par un ordinateur, configurées pour mettre en œuvre les étapes du procédé selon l’une des revendications 1 à 12.
  14. Produit programme d'ordinateur selon la revendication 13, dans lequel au moins une partie du programme est inclus dans le fichier (FL1).
FR2301413A 2023-02-15 2023-02-15 procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable Active FR3145816B1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2301413A FR3145816B1 (fr) 2023-02-15 2023-02-15 procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable
EP24703451.5A EP4666202A1 (fr) 2023-02-15 2024-02-06 Procédé d'établissement d'une liaison inviolable entre un fichier numérique et une donnée variable
PCT/IB2024/051075 WO2024170997A1 (fr) 2023-02-15 2024-02-06 Procédé d'établissement d'une liaison inviolable entre un fichier numérique et une donnée variable

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2301413A FR3145816B1 (fr) 2023-02-15 2023-02-15 procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable
FR2301413 2023-02-15

Publications (2)

Publication Number Publication Date
FR3145816A1 true FR3145816A1 (fr) 2024-08-16
FR3145816B1 FR3145816B1 (fr) 2025-03-14

Family

ID=86764903

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2301413A Active FR3145816B1 (fr) 2023-02-15 2023-02-15 procédé d’établissement d’une liaison inviolable entre un fichier numérique et une donnée variable

Country Status (3)

Country Link
EP (1) EP4666202A1 (fr)
FR (1) FR3145816B1 (fr)
WO (1) WO2024170997A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150365426A1 (en) * 2013-01-22 2015-12-17 Université D'aix-Marseille Method for checking the integrity of a digital data block
US20190044727A1 (en) * 2016-02-08 2019-02-07 Guy Scott A system and method for document information authenticity verification

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150365426A1 (en) * 2013-01-22 2015-12-17 Université D'aix-Marseille Method for checking the integrity of a digital data block
US10218714B2 (en) 2013-01-22 2019-02-26 Universite D'aix-Marseille Method for checking the integrity of a digital data block
US20190044727A1 (en) * 2016-02-08 2019-02-07 Guy Scott A system and method for document information authenticity verification

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BHOWMIK DEEPAYAN ET AL: "The Jpeg-Blockchain Framework For Glam Services", 2018 IEEE INTERNATIONAL CONFERENCE ON MULTIMEDIA & EXPO WORKSHOPS (ICMEW), 1 January 2018 (2018-01-01), pages 1 - 6, XP093081267, ISBN: 978-1-5386-4195-8, Retrieved from the Internet <URL:https://ieeexplore.ieee.org/stampPDF/getPDF.jsp?tp=&arnumber=8551519&ref=aHR0cHM6Ly9pZWVleHBsb3JlLmllZWUub3JnL2Fic3RyYWN0L2RvY3VtZW50Lzg1NTE1MTk=> DOI: 10.1109/ICMEW.2018.8551519 *

Also Published As

Publication number Publication date
FR3145816B1 (fr) 2025-03-14
WO2024170997A1 (fr) 2024-08-22
EP4666202A1 (fr) 2025-12-24

Similar Documents

Publication Publication Date Title
US11186111B1 (en) Digitally encoded seal for document verification
US20220029785A1 (en) Traceability of edits to digital documents via distributed ledgers
US20200162266A1 (en) Facilitating analytic services for provenance of digital documents
RU2409861C2 (ru) Способ заверения и последующего установления подлинности оригиналов бумажных или цифровых документов для доказательств
EP2949070B1 (fr) Procédé de vérification de l&#39;intégrité d&#39;un bloc de données numériques
US6401206B1 (en) Method and apparatus for binding electronic impressions made by digital identities to documents
US20200201964A1 (en) File verification database system
WO2019233951A1 (fr) Une application logicielle et un serveur informatique pour authentifier l&#39;identité d&#39;un créateur de contenu numérique et l&#39;intégrité du contenu du créateur publié
EP3543891B1 (fr) Procédé mis en oeuvre par ordinateur et système de suivi du cycle de vie de documents certifiés et ses programmes informatiques
WO2018158102A1 (fr) Procede et dispositif pour memoriser et partager des donnees integres
JP2020511018A (ja) デジタル・マークを生成するためのシステム及び方法
EP0619660A1 (fr) Procédé de signature d&#39;un fichier informatique et dispositif pour la mise en oeuvre
CN109447809B (zh) 一种结合区块链的视频主动识别方法
Kumar et al. The blockchain technology for secure and smart applications across industry verticals
EP3742699A1 (fr) Procédé d&#39;authentification forte d&#39;un individu
NL2028773B1 (en) Account management method of decentralized electronic contract deposit platform
WO2024170997A1 (fr) Procédé d&#39;établissement d&#39;une liaison inviolable entre un fichier numérique et une donnée variable
CH719096A1 (fr) Système et procédé pour fournir un jeton non-fongible durablement authentifiable
WO2020225292A1 (fr) Procede de generation d&#39;un code d&#39;archivage pour creer une empreinte d&#39;un contenu multimedias
EP0595720B1 (fr) Procédé et système d&#39;incription d&#39;une information sur un support permettant de certifier ultérieurement l&#39;originalité de cette information
BE1031409B1 (fr) Méthode, mise en œuvre par des moyens de traitement numérique, d’exploitation d’informations d’identification d’un ou plusieurs individus
WO2024251191A1 (fr) Procédé, appareil et support non transitoire lisible par ordinateur pour générer des données non clonables et non fongibles associées à des ressources numériques
EP3311341A1 (fr) Procédés d&#39;affiliation, d&#39;émancipation, et de vérification entre un tuteur et un tutoré.
WO2005124503A1 (fr) Procede d&#39;authentification universelle de documents
FR3093836A1 (fr) Identité numérique

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240816

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4