Brevet FR3146777A1 — publié le 20240920

Procédé de certification de partage d’un fichier, procédé de confirmation de partage d’un fichier et dispositifs correspondants Un procédé de certification par un premier dispositif (A) d’un partage d’un fichier (file) à au moins un deuxième dispositif (B), est mis en œuvre par ledit premier dispositif (A) et comprend : - une réception (E2), en provenance dudit deuxième dispositif (B), d’un accusé de réception (ack_file) par le deuxième dispositif du fichier chiffré (c_file), - un stockage (E3), dans un espace de stockage numérique (BDD1), d’une première donnée (d1) chiffrée et déchiffrable par le deuxième dispositif, et dudit accusé de réception (ack_file) du fichier chiffré (c_file), - une réception (E6), en provenance dudit deuxième dispositif, d’une deuxième donnée (d2), - une vérification (E7) si la deuxième donnée (d2) est égale à la première donnée (d1), et, en cas de vérification positive, déclenchement (E8) d’une transmission à destination du deuxième dispositif (B) d’une clef de déchiffrement (k_file) du fichier chiffré (c_file). Figure pour l’abrégé : figure 1 procédé de certification de partage d’un fichier, procédé de confirmation de partage d’un fichier et dispositifs correspondants 1. Domaine de l’invention L’invention concerne le domaine du partage de fichiers numériques. Plus précisément, l’invention vise une solution de certification de partage de fichiers. 2. Art antérieur Avec la numérisation croissante du commerce, de plus en plus d’échanges contractuels se déroulent partiellement ou totalement de manière numérique. Au cours de ces échanges, un contrat doit donc être signé. Au cours d’une signature en présentiel d’un contrat papier, au moins un exemplaire par partie d’un contrat est signé. Avant cette signature, chaque partie peut s’assurer que les exemplaires à signer sont identiques, et que la ou les autres parties les ont bien reçus. Chaque partie signataire peut en outre vérifier l’identité des autres parties signataires. Cependant, lorsque le contrat est sous forme numérique, cette vérification du caractère identique des exemplaires (numériques) du contrat n’est pas possible. A fortiori , lorsque la signature d’un tel contrat numérique est réalisée à distance, il n’est pas possible de vérifier l’identité de chaque partie du contrat. Il n’existe, à ce jour, pas de solution fiable et simple à mettre en œuvre pour vérifier à distance qu’un contrat a bien été reçu par une partie signataire. En outre, il n’existe pas non plus de manière fiable de conserver le résultat d’une telle vérification, de sorte à pouvoir prouver qu’un tel contrat a bien été obtenu par les parties signataires, en cas de litige. L’invention vient améliorer la situation. 3. Exposé de l’invention A cet effet, l’invention propose un procédé de certification par un premier dispositif d’un partage d’un fichier à au moins un deuxième dispositif, le procédé étant mis en œuvre par ledit premier dispositif et comprenant : - une réception, en provenance dudit deuxième dispositif, d’un accusé de réception par le deuxième dispositif du fichier chiffré, - un stockage, dans un espace de stockage numérique, d’une première donnée chiffrée et déchiffrable par le deuxième dispositif, et dudit accusé de réception du fichier chiffré, - une réception, en provenance dudit deuxième dispositif, d’une deuxième donnée, - une vérification de si la deuxième donnée est égale à la première donnée, et, en cas de vérification positive, déclenchement d’une transmission à destination du deuxième dispositif d’une clef de déchiffrement du fichier chiffré. Ainsi, grâce à ce procédé de certification, le premier dispositif (dispositif « certificateur » du partage du fichier à partager) est en mesure de pouvoir certifier la bonne réception du fichier chiffré par le deuxième dispositif auquel est destiné le fichier à partager (dispositif « destinataire »). Cette certification est réalisée à l’aide de la comparaison entre la première donnée et la deuxième donnée, une égalité entre ces deux données signifiant que l’identité du dispositif destinataire est bien vérifiée. Une fois cette garantie obtenue, le premier dispositif fournit, directement ou indirectement, à ce deuxième dispositif destinataire la clef de déchiffrement permettant de déchiffrer le fichier à partager. Le fait d’inscrire, au sein d’un espace de stockage numérique (base de données, registre, chaîne de blocs, …), l’accusé de réception et la première donnée permet avantageusement de pouvoir conserver une trace de la bonne réception, par le deuxième dispositif, du fichier à partager sous forme chiffrée. Au moment de la transmission de la première donnée chiffrée, le premier dispositif a connaissance de la première donnée « en clair », mais pas le deuxième dispositif. Ainsi, la comparaison par le premier dispositif entre la première donnée et la deuxième donnée, que seul le deuxième dispositif destinataire peut obtenir en déchiffrant la première donnée chiffrée, permet au premier dispositif de s’assurer de l’identité du dispositif destinataire. Ainsi, ce procédé d’un genre nouveau permet à un premier dispositif de s’assurer de l’identité du deuxième dispositif auquel le fichier chiffré est destiné. Ce procédé permet en outre au premier dispositif de vérifier que le deuxième dispositif détient effectivement, grâce à l’accusé de réception, une copie du fichier chiffré. Le premier dispositif, grâce à ce procédé, peut vérifier la validité de ces deux conditions (identité et bonne réception) avant de transmettre au deuxième dispositif la clef de déchiffrement. Le fait de stocker dans la première base de données cette première donnée chiffrée et l’accusé de réception du fichier chiffré permet de conserver une trace de cette réception. Selon un exemple de réalisation, le premier dispositif est un dispositif orchestrateur, mettant à disposition d’un utilisateur un service de certification de partage de fichier. Le dispositif orchestrateur joue ainsi un rôle d’équipement tiers durant le partage du fichier entre un dispositif émetteur d’un émetteur et le dispositif destinataire. Selon un exemple de réalisation, le premier dispositif est un dispositif émetteur cherchant à certifier le partage d’un fichier entre lui-même et le dispositif destinataire. Selon un exemple de réalisation, le premier dispositif obtient un premier condensé du fichier chiffré, et dans lequel l’accusé de réception du fichier chiffré comprend un deuxième condensé du fichier chiffré tel qu’obtenu par le deuxième dispositif, la réception du premier condensé déclenchant une vérification de si ledit premier condensé est égal au deuxième condensé, et, en cas de vérification positive, un déclenchement dudit stockage, dans le premier espace de stockage numérique, de ladite première donnée chiffrée et d’au moins le premier condensé. Ainsi, le premier dispositif peut vérifier de manière certaine que le deuxième dispositif a bel et bien reçu le fichier chiffré, grâce à cette comparaison des condensés (« hash » en anglais). De par les propriétés du condensé, celui-ci peut jouer le rôle à lui seul d’un accusé de réception, par le deuxième dispositif, dudit fichier chiffré. Le résultat de cette vérification peut être inscrit dans la première base de données, éventuellement en même temps que la première information et la première donnée chiffrée et de l’accusé de réception comprenant ledit condensé. Utiliser un condensé permet en outre au premier dispositif de s’assurer de l’intégrité du fichier chiffré tel que reçu par le deuxième dispositif. Selon un exemple de réalisation, le procédé de certification comprend en outre : - une réception, en provenance du deuxième dispositif, d’un accusé de réception de ladite clef de déchiffrement, et - un stockage, dans un deuxième espace de stockage numérique, dudit accusé de réception de ladite clef de déchiffrement. Ainsi, le premier dispositif peut également stocker dans la deuxième base de données une preuve que le deuxième dispositif destinataire a bel et bien reçu la clé de déchiffrement, permettant de déchiffrer le fichier chiffré dont le premier dispositif a déjà obtenu l’accusé de réception par le deuxième dispositif. Le stockage de ce deuxième accusé de réception peut être distinct du premier accusé réception, et déclenché immédiatement après la comparaison des premières données (ou jetons de session). Cela permet de générer une preuve de réception du fichier chiffré distincte d’une preuve de réception de la clef. En variante, la première base de données et la deuxième base de données sont une même base de données. Le stockage des deux accusés de réception peut éventuellement être simultané. Ainsi, le premier dispositif génère une preuve unique à la fois de la réception par le deuxième dispositif du fichier chiffré et de sa clef de déchiffrement. Cela permet ainsi de pouvoir vérifier, dans le futur, de manière transparente et pérenne cette garantie de réception que le premier dispositif a inscrite dans la base de données. Selon un exemple de réalisation, l’accusé de réception de la clef de déchiffrement comprend un condensé d’un fichier déchiffré, et dans lequel le stockage dudit accusé de réception de la clef de déchiffrement comprend la vérification de si le condensé du fichier déchiffré en provenance du deuxième dispositif est identique à un condensé du fichier déchiffré que le premier dispositif détermine à l’aide du fichier chiffré et de la clef de déchiffrement. Ainsi, grâce à la comparaison des condensés du fichier déchiffré, le premier dispositif peut garantir que le deuxième dispositif a bien obtenu la clef de déchiffrement et, plus important encore, que la clef de déchiffrement a bien permis de déchiffrer le fichier chiffré. De fait, cette vérification et l’inscription du condensé du fichier déchiffré permet de conserver une trace sûre et fiable de la bonne réception du fichier par le deuxième dispositif. Selon un exemple de réalisation, au moins un espace de stockage numérique est une chaîne de blocs. Le fait que le stockage de la première donnée et de l’accusé de réception du fichier chiffré, éventuellement de l’accusé de réception de la clef de déchiffrement, est réalisé dans une chaîne de blocs permet avantageusement d’obtenir une preuve dont l’inscription est transparente et infalsifiable. La preuve ainsi stockée, ou inscrite, est ainsi disponible sans limite de temps, à des tiers. Cela permet par ailleurs que le premier dispositif ne puisse pas revenir a posteriori sur une certification inscrite dans la chaîne de blocs. L’invention concerne également un procédé de confirmation de partage à au moins un deuxième dispositif, le procédé étant mis en œuvre par le deuxième dispositif ayant obtenu un fichier chiffré et comprenant : - une transmission, à destination d’un premier dispositif, d’un accusé de réception du fichier chiffré, - une transmission, à destination du premier dispositif, d’une deuxième donnée obtenue par déchiffrement d’une première donnée chiffrée obtenue par le deuxième dispositif suite à la transmission de l’accusé de réception du fichier chiffré, - une réception, en provenance du premier dispositif, d’une clef de déchiffrement du fichier chiffré. Selon un exemple de réalisation, le procédé de confirmation de partage comprenant en outre : - une obtention, à partir du fichier chiffré, d’un condensé de celui-ci, et - une transmission, à destination du premier dispositif, du condensé ainsi obtenu. Selon un exemple de réalisation, le procédé de confirmation de partage comprend en outre : - une transmission, à destination du premier dispositif, d’un accusé de réception de ladite clef de déchiffrement. Selon un exemple de réalisation, l’accusé de réception de la clef de déchiffrement comprend un condensé du fichier déchiffré obtenu par le deuxième dispositif à l’aide du fichier chiffré et de la clef de déchiffrement. L’invention concerne en outre sur un premier dispositif pour la certification d’un partage d’un fichier à au moins un deuxième dispositif, le premier dispositif comprenant : - des moyens de réception, en provenance dudit deuxième dispositif, d’un accusé de réception par le deuxième dispositif du fichier chiffré, - des moyens de stockage, dans un espace de stockage numérique, d’une première donnée chiffrée et déchiffrable par le deuxième dispositif, et dudit accusé de réception du fichier chiffré, - des moyens de réception, en provenance dudit deuxième dispositif, d’une deuxième donnée, - des moyens de vérification de si la deuxième donnée est égale à la première donnée, et, en cas de vérification positive, des moyens de déclenchement d’une transmission à destination du deuxième dispositif d’une clef de déchiffrement du fichier chiffré. L’invention concerne en outre un deuxième dispositif pour la confirmation d’un partage d’un fichier, le procédé étant mis en œuvre par le deuxième dispositif ayant obtenu un fichier chiffré et comprenant : - des moyens de transmission, à destination d’un premier dispositif, d’un accusé de réception du fichier chiffré, - des moyens de transmission, à destination du premier dispositif, d’une deuxième donnée obtenue par déchiffrement d’une première donnée chiffrée obtenue par le deuxième dispositif suite à la transmission de l’accusé de réception du fichier chiffré, - des moyens de réception, en provenance du premier dispositif, d’une clef de déchiffrement du fichier chiffré. L’invention concerne en outre un produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé tel qu’énoncé ci-avant, lorsqu’il est exécuté par un processeur. Un tel programme d’ordinateur peut être enregistré sur un support d'enregistrement lisible par un ordinateur. Ce support d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une clé USB ou un disque dur. D'autre part, un tel support d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens, de sorte que le programme d’ordinateur qu’il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet. Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé objet de l’invention précité. 4. Liste des figures D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante d’un mode de réalisation particulier, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : représente un procédé de certification de fichiers et un procédé de confirmation de partage de fichiers selon un mode de réalisation de l’invention ; représente un exemple particulier des procédés de la ; représente un exemple particulier des procédés de la ; représente un exemple particulier des procédés de la ; représente un exemple particulier des procédés de la ; représente un premier dispositif selon un mode de réalisation de l’invention ; représente un deuxième dispositif selon un mode de réalisation de l’invention. 5. Description détaillée 5.1. Principe général Il est fait référence à la , qui représente les principales étapes d’un procédé de certification de fichiers et d’un procédé de confirmation de partage de fichiers selon un mode de réalisation de l’invention. Le principe général de l’invention est de fournir un procédé de certification, par un premier dispositif A, d’un partage à un deuxième dispositif B, d’un fichier à partager, ci-après appelé « fichier ». Ce procédé permet, selon au moins un mode de réalisation, de vérifier la bonne réception du fichier par le deuxième dispositif et de s’assurer de l’identité du deuxième dispositif. Ce procédé permet par exemple de reproduire, numériquement et entre deux terminaux distants, les bonnes propriétés d’une signature en présentiel d’un contrat papier. Bien que la raison d’être de l’invention naisse des contraintes des échanges contractuels entre parties, elle ne se limite pas à ce seul contexte contractuel. Ainsi, le fichier peut être tout type de fichier numérique, notamment textuel ou multimédia. Au préalable des étapes E1 à E9 décrites ci-après, le deuxième dispositif obtient un fichier chiffré c_file. Ce fichier chiffré c_file peut avoir été transmis par le premier dispositif A, directement ou indirectement, à destination dudit deuxième dispositif B. En variante, le deuxième dispositif B peut avoir obtenu ce fichier chiffré c_file par un autre biais, par exemple via un serveur de partage ou tout autre équipement tiers, ou en provenance d’un dispositif ayant généré ce fichier, également appelé dispositif émetteur. Le fichier chiffré c_file est associé à une clef de déchiffrement (k_file), qui, à ce stade n’est pas détenue par le deuxième dispositif B. Le premier dispositif A peut par exemple avoir chiffré lui-même le fichier à partager, ou en variante avoir obtenu une paire fichier chiffré/clef de déchiffrement fournie par un équipement tiers. Alternativement, le premier dispositif A peut n’avoir en sa possession que la clef de déchiffrement k_file, voire ne détenir ni la clef de déchiffrement, ni le fichier chiffré. Dans une étape E1, le deuxième dispositif B transmet, à destination du premier dispositif A, un accusé de réception ack_file du fichier chiffré c_file. Différents exemples d’accusé de réception seront décrits ci-après. Dans une étape E2, le premier dispositif A reçoit, en provenance du deuxième dispositif B, ledit accusé de réception ack_file par le deuxième dispositif B du fichier chiffré c_file. Dans une étape E3, le premier dispositif A obtient une première donnée d1. Différentes façons d’obtenir cette première donnée d1 seront décrites ci-après. Le premier dispositif A peut par exemple générer la première donnée d1. Ensuite, le premier dispositif A peut chiffrer la première donnée d1, de sorte que le deuxième dispositif B puisse la déchiffrer. Ensuite, le premier dispositif A peut transmettre, à destination d’un serveur hébergeant un premier espace de stockage numérique BDD1, ladite première donnée chiffrée c_d1 et l’accusé de réception ack_file du fichier chiffré c_file. Le chiffrement de la première donnée d1 de sorte que le deuxième dispositif B puisse déchiffrer la première donnée chiffrée c_d1 peut par exemple être réalisé à l’aide d’une clef publique kpb_B du deuxième dispositif B, celui-ci pouvant déchiffrer cette première donnée chiffrée c_d1 avec une clef privée kpv_B. En variante, le chiffrement peut être symétrique, c’est-à-dire réalisé avec une clef de chiffrement détenue par le premier dispositif A et le deuxième dispositif B. Dans une étape E4, la première donnée d1, chiffrée, est stockée dans le premier espace de stockage numérique BDD1. Dans une étape E5, le deuxième dispositif B obtient la première donnée d1 sous forme chiffrée c_d1. Suite à l’obtention de cette première donnée chiffrée c_d1, le deuxième dispositif B déchiffre celle-ci, de sorte à obtenir une deuxième donnée d2. Le deuxième dispositif B transmet ensuite cette deuxième donnée d2 au premier dispositif A. En principe, si le deuxième dispositif B est le dispositif auquel le fichier à partager est destiné, cette deuxième donnée d2 est censée être identique à la première donnée d1, connue du premier dispositif A. Le deuxième dispositif B peut avoir reçu directement cette première donnée chiffrée c_d1 en provenance du premier dispositif A. En variante, le deuxième dispositif B peut avoir obtenu cette première donnée chiffrée c_d1 par un équipement tiers, la transmission de cette première donnée chiffrée c_d1 étant par exemple déclenchée par le stockage de celle-ci dans le premier espace de stockage numérique. Ces différents exemples seront décrits ci-après. Le premier dispositif A reçoit cette deuxième donnée d2 dans une étape E6. Dans une étape E7, le premier dispositif A vérifie si la deuxième donnée d2 est égale à la première donnée d1. En cas de vérification positive, cela signifie effectivement que le deuxième dispositif B est bien le deuxième dispositif auquel le fichier est destiné. Quand cette vérification est positive, la clef de déchiffrement k_file est transmise dans une étape E8 à destination du deuxième dispositif B, ce dernier la recevant dans une étape E9. Cette transmission de la clef de déchiffrement peut être réalisée directement par le premier dispositif A, ou via un équipement tiers. En alternative, la vérification de l’identité entre la première donnée d1 et la deuxième donnée d2 peut déclencher l’émission d’un message à un équipement tiers qui à son tour transmet la clef de déchiffrement k_file au deuxième dispositif B. Ainsi, grâce aux procédés de certification (côté premier dispositif A) et de confirmation (côté deuxième dispositif B) de partage d’un fichier selon le mode de réalisation décrit ci-dessus, le premier dispositif A est en mesure de vérifier la bonne réception d’un fichier chiffré, mais également de vérifier l’identité du deuxième dispositif B avant de lui transmettre la clef de déchiffrement, tout en conservant une trace des échanges au cours du partage. La première donnée d1 joue ainsi un rôle d’identifiant, potentiellement unique et propre à une session de partage, permettant au deuxième dispositif B de récupérer le code de déchiffrement auprès du premier dispositif A. Il a été décrit ci-avant un stockage simultané de la première donnée chiffrée c_d1 et de l’accusé de réception ack_file. Le procédé décrit permet, en variante, un stockage par le premier dispositif A de la première donnée chiffrée c_d1 de manière découplée de la réception de l’accusé de réception ack_file en provenance du deuxième dispositif B. Dans un tel cas de figure, le deuxième dispositif B peut obtenir la première donnée chiffrée c_d1 (directement en provenance du premier dispositif A, ou depuis un équipement tiers), et transmettre la deuxième donnée d2. En parallèle (ou avant, ou après), le deuxième dispositif B peut obtenir le fichier chiffré c_file, et transmettre au premier dispositif A l’accusé de réception ack_file, le premier dispositif A le stockant dans le premier espace de stockage numérique. Dans un exemple de réalisation, le partage peut être réalisé avec plusieurs terminaux destinataires. Dans un tel cas de figure, la première donnée chiffrée c_d1 peut être chiffrée de manière symétrique, avec une clef de déchiffrement commune à plusieurs terminaux destinataires. Ainsi, chacun de ces terminaux est en mesure de déchiffrer la première donnée chiffrée c_d1. Il est possible aussi d’utiliser une clef de chiffrement symétrique par un deuxième dispositif. De manière alternative, la première donnée d1 peut être chiffrée en une pluralité de premières données chiffrées c_d1_B1, c_d1_B2… c_d1_Bn pour n terminaux destinataires B1… Bn avec n entier, chaque première donnée chiffrée c_d1_Bi (avec i entier) étant chiffrée avec une clef publique kpb_Bi du deuxième dispositif Bi. Il est possible de combiner des cas de chiffrement symétriques et asymétriques. Par la suite, le premier dispositif A est appelé dispositif certificateur, et le deuxième dispositif B est appelé dispositif destinataire d’un fichier à partager. Le dispositif certificateur peut notamment être intégré à un dispositif émetteur du fichier à partager, ou distinct du dispositif émetteur du fichier à partager. 5.2. Description d’un premier exemple de réalisation de l’invention Il est fait référence à la , qui représente un premier exemple de réalisation des procédés de certification de fichiers et de confirmation de partage de fichiers. Dans le mode de réalisation décrit ici, le premier espace de stockage numérique est une base de données BDD1, hébergée sur un serveur tiers. Alternativement, le dispositif certificateur A peut héberger lui-même cette première base de données. Dans une étape F1, le dispositif certificateur A transmet, directement ou indirectement, une version chiffrée c_file du fichier à partager, à destination dudit dispositif destinataire B. Le fichier chiffré c_file est associé à une clef de déchiffrement (k_file) détenue par le dispositif certificateur A. Le dispositif certificateur A peut soit chiffrer lui-même le fichier à partager, soit avoir obtenu une paire fichier chiffré/clef de déchiffrement fournie par un équipement tiers. Dans une étape F2, le dispositif destinataire B reçoit le fichier chiffré c_file en provenance du dispositif certificateur A. Durant cette étape, le dispositif certificateur A ne transmet pas la clef de déchiffrement k_file, qu’il conserve. Dans une étape F3, le dispositif destinataire B transmet, à destination du dispositif certificateur A, un accusé de réception ack_file du fichier chiffré c_file. Différents exemples d’accusé de réception seront décrits ci-après. Dans une étape F4, le dispositif certificateur A reçoit, en provenance du dispositif destinataire B, ledit accusé de réception ack_file du fichier chiffré c_file. Le partage advient au cours d’une session de partage, c’est-à-dire d’une fenêtre logique et/ou temporelle dont l’objet porte au moins sur le partage de ce fichier. Dans une étape F5, le dispositif certificateur A détermine une première donnée d1 identifiant la session de partage en cours. La première donnée d1 peut comprendre plusieurs informations déterministes et/ou aléatoires, comme on le verra ci-après, l’important selon cet exemple de réalisation étant que cette première donnée d1 identifie de manière univoque la session en cours, et que seul le dispositif certificateur A puisse y avoir accès à sa détermination tant qu’il ne la transmet pas à d’autres terminaux. Dans une étape F6, le dispositif certificateur A chiffre la première donnée d1 à l’aide d’une clef publique kpb_B du dispositif destinataire B. Ensuite, le dispositif certificateur A transmet, à destination d’un serveur hébergeant une première base de données BDD1, ladite première donnée chiffrée d1 et l’accusé de réception ack_file du fichier chiffré c_file. Dans une étape F7, la première donnée d1, chiffrée, est stockée dans la première base de données BDD1 par ce serveur. Dans une étape F8, le dispositif certificateur A transmet, directement ou indirectement, la première donnée chiffrée c_d1 avec la clef publique kpb_B à destination du dispositif destinataire B. Quand la transmission est directe, le dispositif certificateur A peut transmettre cette première donnée chiffrée c_d1 en tant que telle au dispositif destinataire B, éventuellement via un équipement tiers. Quand la transmission est indirecte, le dispositif certificateur A peut transmettre au dispositif destinataire B une information lui permettant d’obtenir cette première donnée d1, comme par exemple une adresse ou un identifiant permettant au dispositif destinataire B d’obtenir cette information dans la première base de données BDD1. Cet identifiant peut par exemple être un identifiant d’inscription id_tag_c_d1 résultant d’une inscription de la première donnée chiffrée c_d1 dans une chaîne de blocs, comme on le verra ci-après. Dans une étape F9, le dispositif destinataire B reçoit la première donnée d1 chiffrée à l’aide de sa propre clef publique kpb_B. Le dispositif destinataire B déchiffre cette première donnée d1 chiffrée avec sa clef privée kpv_B, de sorte à obtenir une deuxième donnée d2. En principe, si le dispositif destinataire B est le dispositif auquel le fichier à partager est destiné, cette deuxième donnée d2 est censée être identique à la première donnée d1, en possession du dispositif certificateur A. Dans une étape F10, le dispositif destinataire B transmet cette deuxième donnée d2 au dispositif certificateur A. Comme pour les autres transmissions décrites ci-avant, celle-ci peut être directe ou indirecte. Le dispositif certificateur A reçoit cette deuxième donnée d2 dans une étape F11. Dans une étape F12, le dispositif certificateur A vérifie si la deuxième donnée d2 est égale à la première donnée d1. En cas de vérification positive, cela signifie effectivement que le dispositif destinataire B est bien le dispositif destinataire auquel le fichier est destiné. Quand cette vérification est positive, le dispositif certificateur A transmet dans une étape F13, à destination du dispositif destinataire B, la clef de déchiffrement k_file servant à déchiffrer le fichier chiffré c_file transmis précédemment au dispositif destinataire B. Le dispositif destinataire B reçoit cette clef de déchiffrement k_file dans une étape F14. 5.3 Accusé de réception du fichier chiffré L’accusé de réception ack_file peut être un message signé par le dispositif destinataire. Ainsi, le dispositif certificateur est en mesure, à la réception de l’accusé de réception ack_file, d’en attester l’authenticité, ce qui offre de bonnes garanties quant à l’identité du dispositif destinataire. Dans un exemple de réalisation, l’accusé de réception ack_file peut comprendre ou prendre la forme d’un condensé hash_B du fichier chiffré c_file reçu par le dispositif destinataire B. Plus précisément, le dispositif destinataire B peut, dans l’étape F2, appliquer une fonction de hachage F1 au fichier chiffré c_file, résultant en un condensé hash_B. De son côté, avant ou à la réception du condensé hash_B, le dispositif certificateur A peut appliquer cette même fonction de hachage F1 sur le fichier chiffré c_file dont il détient une copie, et obtenir un deuxième condensé hash_A. Le dispositif certificateur A peut alors comparer le condensé hash_B, qu’il a reçu du dispositif destinataire B, et le condensé hash_A qu’il a obtenu lui-même. Si ces deux condensés hash_A et hash_B sont identiques, alors le dispositif certificateur A obtient la garantie que le dispositif destinataire B est bien en possession d’une version du fichier chiffré c_file identique à la sienne. Cela permet par exemple de s’assurer que le fichier chiffré c_file n’a pas été altéré lors de sa transmission au dispositif destinataire. En effet, une altération ne serait-ce que d’un seul octet du fichier chiffré c_file résulterait en un condensé hash_B différent du condensé hash_A, de par les propriétés mathématiques de la fonction de hachage F1. Le dispositif certificateur A peut conditionner le stockage de la première donnée chiffrée kpb_B(d1) dans la première base de données (étape F7) au fait que ces deux condensés hash_A et hash_B soient identiques. Le stockage de ce condensé hash_B = hash_A peut être réalisé en clair sur la base de données BDD1, puisque de par les propriétés mathématiques de la fonction de hachage, il n’est pas possible à partir de ce condensé de remonter au fichier chiffré c_file. Ainsi, dans cet exemple d’accusé de réception, le condensé hash_B transmis par le dispositif destinataire B peut jouer un double rôle, à la fois d’accusé de réception du fichier chiffré et de preuve de l’intégrité de la transmission de celui-ci. Il est possible d’envisager, en alternative d’une fonction de hachage, une fonction de type CRC ( Cyclic Redundancy Check ou code de redondance cyclique) pour vérifier l’intégrité du fichier chiffré transmis au dispositif destinataire B. D’autres types d’accusé de réception peuvent également être envisagés. 5.4 Accusé de réception de la clef Il est fait référence à la , qui décrit une variante améliorée du procédé de la . Les étapes F1 à F14 sont similaires à celles décrites ci-avant, en relation avec la . Dans le procédé de la , le dispositif destinataire, dans une étape F15, transmet, à destination du dispositif certificateur A, un accusé de réception ack_key de la clef de déchiffrement k_file qu’il a reçu à l’étape F14. Le dispositif certificateur A reçoit cet accusé de réception ack_key dans une étape F16. Dans une étape F17, le dispositif certificateur A transmet l’accusé de réception ack_key de la clef de déchiffrement à un serveur hébergeant une deuxième base de données BDD2. Cet accusé de réception ack_key de la clef de déchiffrement est ainsi stocké dans la deuxième base de données dans une étape F18. Il est à noter que la première base de données BDD1 et la deuxième base de données BDD2 peuvent être la même base de données, ou alternativement deux bases de données distinctes. Dans le cas où ces deux bases de données sont distinctes, elles peuvent être hébergées sur un même serveur, ou sur deux serveurs distincts. En variante, comme cela sera décrit ci-après, l’une et/ou l’autre de ces deux bases de données peut être une chaîne de blocs, stockée de manière décentralisée. Le fait que le dispositif certificateur A stocke dans la deuxième base de données BDD2 l’accusé de réception ack_key de la clé de déchiffrement, que lui a transmis le dispositif destinataire B, permet de conserver une trace que ce dernier a bien obtenu la clef de déchiffrement. Cet accusé de réception ack_key peut comprendre ou prendre la forme d’un message signé par le dispositif destinataire B. En variante, cet accusé de réception ack_key peut prendre la forme d’un condensé hash_B’ du fichier déchiffré, ce condensé hash_B’ étant obtenu par le dispositif destinataire B à partir du fichier déchiffré à l’aide de la clef de déchiffrement k_file qu’il a reçu à l’étape F14. A la réception de ce condensé hash_B’, le dispositif certificateur A peut obtenir un condensé hash_A’ du fichier déchiffré à l’aide de la clef de déchiffrement (dont il dispose), puis comparer les deux condensés hash_A’ et hash_B’. Si ces deux condensés sont identiques, alors le dispositif certificateur A obtient la certitude que le dispositif destinataire a bien en sa possession le fichier déchiffré. Cette vérification peut être une condition pour que le dispositif certificateur inscrive dans la deuxième base de données BDD2 l’accusé de réception de la clef de déchiffrement. Ainsi, le stockage de cet accusé de réception de la clef de déchiffrement sous forme de condensé du fichier déchiffré permet de vérifier, postérieurement et par des tiers comme par le dispositif certificateur A, que le fichier a bien été déchiffré par le dispositif destinataire B. Cela permet en outre de vérifier l’intégrité du fichier déchiffré, ce qui est très avantageux d’autant plus si l’intégrité du fichier chiffré c_file n’a pas été vérifiée au préalable. Le stockage de l’accusé de réception ack_key peut être distinct de celui du premier accusé de réception ack_file. Cela permet de générer une preuve de réception du fichier chiffré distincte d’une preuve de réception de la clef. En variante, la première base de données et la deuxième base de données sont une même base de données. Le stockage des deux accusés de réception peut éventuellement être simultané, voire concaténé. Dans ce cas de figure, le dispositif certificateur A peut réaliser l’étape F6 de stockage de la première donnée après la réception de l’accusé de réception ack_key de la clef de déchiffrement, et concaténer les deux accusés de réception ack_file et ack_key. Ainsi, le premier dispositif génère une preuve unique à la fois de la réception par le deuxième dispositif du fichier chiffré et de sa clef de déchiffrement. 5.5 Utilisation d’une chaîne de blocs comme espace de stockage numérique Dans un mode de réalisation, le premier et/ou le deuxième espace de stockage numérique est une chaîne de blocs. La ou les étapes de stockage d’une donnée d (comme par exemple la donnée chiffrée c_d1, l’accusé de réception ack_file ou l’accusé de réception ack_key) au sein d’une telle chaîne de blocs peuvent alors comprendre, côté dispositif certificateur A : Une inscription de la donnée d au sein de la chaîne de blocs, sous la forme d’une inscription référencée ci-après « tag », Une réception, en réponse à cette inscription, d’un identifiant d’inscription id_tag_d de la donnée d ainsi inscrite. Ainsi, de manière optionnelle, en lieu et place de la transmission de la première donnée chiffrée c_d1 au dispositif destinataire B, il est possible de transmettre l’identifiant d’inscription id_tag_c_d1 de celle-ci au dispositif destinataire B. Le dispositif destinataire B peut ensuite obtenir, à l’aide de l’identifiant d’inscription id_tag_c_d1, la première donnée chiffrée c_d1 au sein de la chaîne de blocs. L’inscription de la première donnée chiffrée c_d1 au sein de la chaîne de blocs peut déclencher l’émission automatique d’une notification, à destination du dispositif destinataire B, comprenant l’identifiant d’inscription id_tag_c_d1 de la première donnée chiffrée c_d1. Ainsi, dans ce cas de figure, le dispositif certificateur A n’a pas besoin de transmettre lui-même la première donnée chiffrée c_d1 au dispositif destinataire B. L’émission d’une telle notification automatique peut être réalisée à l’aide d’une adresse du dispositif destinataire B jointe à la première donnée chiffrée c_d1 et à l’accusé de réception ack_file que le dispositif certificateur A fait inscrire dans la chaîne de blocs. Cette émission automatique de notification peut être également mise en œuvre par un serveur hébergeant une base de données classique. Il est possible d’utiliser, en lieu et place d’une chaîne de bloc, un service tiers mettant à disposition une base de données servant de registre, pour autant que ce registre soit infalsifiable, transparent et accessible aux tiers. 5.6 Contenu de la première donnée La première donnée d1 peut comprendre un jeton, ou token en anglais. Un tel jeton, token_A, peut être généré aléatoirement. Ainsi, seul le dispositif certificateur A détient ce jeton. En outre, la première donnée d1 peut comprendre au moins un des éléments de session suivants : un identifiant unique de partage, par exemple une adresse URL à laquelle le fichier chiffré est stocké) ; un horodatage, i.e. une date et/ou un horaire de la session de partage en cours ; une adresse du dispositif destinataire B, comme par exemple une adresse email, une adresse IP, une adresse MAC… En variante, certains au moins de ces éléments peuvent ne pas être compris dans la première donnée d1 — qui est stockée sur la première base de données en étant chiffrée avec la clef publique kpb_B du dispositif destinataire B — mais concaténés avec la première donnée d1 chiffrée. Ainsi, ces éléments peuvent être inspectés librement par un tiers sans avoir besoin de la clef privée kpv_B du dispositif destinataire B. Ces tiers peuvent ainsi constater la date du partage et/ou le destinataire du partage. Dans le cas où une adresse du dispositif destinataire B est concaténée avec la première donnée chiffrée c_d1, cette adresse du dispositif destinataire B peut être utilisée pour réaliser l’émission d’une notification automatique d’une inscription dans une chaîne de blocs ou une base de données comme expliqué ci-avant. De manière alternative à une génération aléatoire, le jeton token_A peut être généré en concaténant un ou plusieurs des éléments de session listés ci-avant, puis en appliquant une deuxième fonction de hachage F2, distincte de la fonction de hachage F1 appliquée au fichier chiffré c_file, à laquelle le dispositif certificateur a accès. Ainsi, dans ce cas comme dans le cas d’une génération aléatoire, seul le dispositif certificateur A a connaissance de la méthode pour générer la première donnée d1. 5.7 Dispositif certificateur en tant que fournisseur de service Il est fait référence à la . Les étapes F1 à F18 sont, sauf mention contraires, similaires à celles décrites ci-avant. Dans cet exemple de réalisation, le dispositif certificateur A est un dispositif orchestrateur, aussi appelé data manager . Le dispositif orchestrateur A met à disposition d’utilisateurs un service de certification de partage. Ici, un utilisateur d’un dispositif émetteur U souhaite partager un fichier avec le dispositif destinataire B. Dans une étape G1, le dispositif émetteur U émet, à destination du dispositif orchestrateur A une requête de partage req1. La requête de partage peut comprendre le fichier, le fichier chiffré, un identifiant du fichier chiffré, et/ou un lien de partage du fichier (chiffré ou non), ce dernier étant stocké sur un serveur de partage tiers. De manière alternative, la requête de partage req1 peut présenter un contenu plus générique et ne pas contenir d’information relative au fichier à partager en tant que tel. Par exemple, le dispositif orchestrateur A peut mettre à disposition du dispositif émetteur U un service de partage d’un fichier prédéterminé standard, le dispositif émetteur U se contentant simplement d’émettre une requête contenant une identification du dispositif destinataire B, le fichier à partager étant déjà déterminé. Le dispositif orchestrateur A reçoit cette requête de partage req1, et déclenche le procédé de certification de partage décrit ci-avant. Lorsque le dispositif orchestrateur A reçoit l’accusé de réception ack_file du fichier chiffré, à l’étape F4, le dispositif orchestrateur A transmet dans une étape G3 cet accusé de réception ack_file au dispositif émetteur U. En variante, le dispositif orchestrateur A peut transmettre au dispositif émetteur U un accusé de réception ack_ack_file de l’accusé de réception ack_file du fichier chiffré c_file. Le dispositif émetteur reçoit cet accusé de réception ack_ack_file dans une étape G4 et peut constater que le fichier chiffré a ainsi été bien reçu par le dispositif destinataire B. La réalisation de l’étape G3 de transmission de l’accusé de réception du fichier chiffré peut être conditionnée à la vérification de l’égalité entre les données d1 et d2 réalisée dans l’étape F5. Dans le cas où un accusé de réception ack_key de la clef de déchiffrement k_file est retourné par le dispositif destinataire B au dispositif orchestrateur A, à l’étape F16, le dispositif orchestrateur A transmet dans une étape G5 cet accusé de réception ack_key au dispositif émetteur U. En variante, le dispositif orchestrateur A peut transmettre au dispositif émetteur U un accusé de réception ack_ack_key de l’accusé de réception ack_key de la clef de déchiffrement k_file. Le dispositif émetteur reçoit cet accusé de réception ack_ack_key dans une étape G6 et peut constater que la clef de déchiffrement a ainsi été bien reçue par le dispositif destinataire B. La réalisation de l’étape G5 de transmission de l’accusé de réception de la clef de déchiffrement peut être conditionnée à la vérification de l’égalité entre un condensé hash_A’ du fichier non chiffré déterminé par le dispositif orchestrateur A en interne et un condensé hash_B’ du fichier non chiffré déterminé par le dispositif destinataire B à la suite de la réception de la clef de déchiffrement. Si le dispositif orchestrateur A ne dispose pas du fichier non chiffré (soit directement soit en ayant à disposition le fichier chiffré et la clef de déchiffrement), la vérification de l’égalité des condensés peut être réalisée par le dispositif émetteur U. Les deux accusés de réception ack_ack_file et ack_ack_key peuvent être groupés en un seul accusé de réception rendant compte de la bonne réception, par le dispositif destinataire B, de tous les éléments (fichier chiffré, clef de déchiffrement) lui permettant d’obtenir le fichier déchiffré. Comme cela a été expliqué ci-avant, dans un mode de réalisation particulier, l’accusé de réception ack_ack_file peut comprendre ou prendre la forme d’un identifiant d’inscription id_tag_ack_file résultant de l’inscription de l’accusé de réception ack_file dans une chaîne de blocs. Ainsi, cet accusé de réception étant inscrit dans une telle chaîne de blocs, il est possible de conserver une trace transparente et infalsifiable que tout tiers peut consulter sans limite de temps. Dans un tel cas, le dispositif émetteur U reçoit cet identifiant d’inscription id_tag_ack_file, et obtient auprès de la chaîne de blocs l’accusé de réception ack_file. Cette obtention de l’accusé de réception ack_file du fichier chiffré peut également être mise en œuvre pour obtenir l’accusé de réception de la clef de déchiffrement. 5.8 Dispositif certificateur en tant que dispositif émetteur Dans un autre exemple de réalisation de l’invention, le dispositif certificateur est un dispositif souhaitant partager un fichier, encore appelé dispositif émetteur. Il peut par exemple s’agir d’un dispositif utilisateur de type ordinateur ou smartphone. Alternativement, ce dispositif émetteur peut-être par exemple un serveur d’une entreprise, ce serveur générant et émettant des contrats pour souscrire à un service ou un produit. Dans les deux cas, selon cet exemple de réalisation de l’invention, un même dispositif joue à la fois le rôle de dispositif certificateur et le rôle de dispositif émetteur. 5.9 Inscription dans une chaîne de blocs par le dispositif destinataire Il est fait référence à la , qui représente une alternative au procédé de la . Les étapes F1 à F16 sont, sauf mention contraires, similaires à celles décrites ci-avant. Dans ce mode de réalisation, l’espace de stockage numérique est de préférence une chaîne de blocs BC. Le dispositif destinataire B, avant d’envoyer l’accusé de réception ack_file du fichier chiffré au dispositif certificateur (étape F3), peut selon cet exemple de mise en œuvre inscrire dans une étape H1 l’accusé de réception ack_file dans une chaîne de blocs BC. L’accusé de réception ack_file est inscrit dans une étape H1’. Un identifiant d’inscription id_tag_ack_file est généré dans une étape H2’. Le dispositif destinataire B reçoit en réponse l’identifiant d’inscription id_tag_ack_file dans une étape H2. Le dispositif transmet ensuite l’identifiant d’inscription id_tag_ack_file dans l’étape F3. A la réception par le dispositif certificateur A de l’accusé de réception ack_file comprenant cet identifiant d’inscription id_tag_ack_file (étape F4), le dispositif certificateur A peut émettre dans une étape H3 une requête comprenant cet identifiant d’inscription id_tag_ack_file à destination de la chaîne de blocs. La requête comprenant l’identifiant d’inscription id_tag_ack_file est reçue dans une étape H3’. L’accusé de réception ack_file est déterminé dans une étape H4’ à l’aide de l’identifiant d’inscription id_tag_ack_file. En réponse, dans une étape H4, le dispositif certificateur A obtient l’accusé de réception ack_file. Le dispositif certificateur A peut optionnellement vérifier l’identité du dispositif destinataire B ayant inscrit cet accusé de réception ack_file dans la chaîne de blocs, de par les propriétés de la chaîne de blocs. Cette vérification supplémentaire renforce la sécurité du procédé de certification. De manière alternative ou complémentaire à l’inscription par le dispositif destinataire B, dans la chaîne de blocs, de l’accusé de réception ack_file, le dispositif destinataire B peut procéder de manière similaire pour l’accusé de réception ack_key de la clef de déchiffrement. Le dispositif destinataire B peut ainsi, avant d’envoyer l’accusé de réception ack_key de la clef de déchiffrement k_file au dispositif certificateur (étape F15), inscrire dans une étape H5 l’accusé de réception ack_key dans la chaîne de blocs BC, ou une autre chaîne de blocs distincte. L’accusé de réception ack_key est inscrit dans une étape H5’. Un identifiant d’inscription id_tag_ack_key est généré dans une étape H6’. Le dispositif destinataire B reçoit en réponse l’identifiant d’inscription id_tag_ack_key dans une étape H6. Le dispositif transmet ensuite l’identifiant d’inscription id_tag_ack_key dans l’étape F15. A la réception par le dispositif certificateur A de l’accusé de réception ack_key comprenant cet identifiant d’inscription id_tag_ack_key (étape F16), le dispositif certificateur A peut émettre dans une étape H7 une requête comprenant cet identifiant d’inscription id_tag_ack_key à destination de la chaîne de blocs. La requête comprenant l’identifiant d’inscription id_tag_ack_key est reçue dans une étape H7’. L’accusé de réception ack_key est déterminé à l’aide de l’identifiant d’inscription id_tag_ack_key dans une étape H8’. En réponse, dans une étape H8, le dispositif certificateur A obtient l’accusé de réception ack_key. Le dispositif certificateur A peut optionnellement vérifier l’identité du dispositif destinataire B ayant inscrit cet accusé de réception ack_key dans la chaîne de blocs, de par les propriétés de la chaîne de blocs. Cette vérification supplémentaire renforce la sécurité du procédé de certification. Il est à noter que, dans ce mode de réalisation, le dispositif certificateur A n’a pas besoin d’inscrire lui-même les accusés de réception ack_file et ack_key dans la chaîne de blocs, car ceux-ci le sont déjà par le dispositif destinataire B. Dans le cas où l’accusé de réception ack_key comprend un condensé hash_B’ du fichier déchiffré (décrit ci-avant), le dispositif certificateur A peut mettre en œuvre la vérification de l’égalité entre ce condensé hash_B’ et un condensé hash_A’ qu’il détermine à partir du fichier déchiffré de son côté. Ce mode de réalisation où le dispositif destinataire B inscrit lui-même dans la chaîne de blocs le condensé du fichier déchiffré hash_B’ est particulièrement avantageux en ce qu’il permet d’obtenir une preuve infalsifiable et irréfutable que le dispositif destinataire B a bel et bien pu obtenir, grâce au procédé décrit ci-avant, le fichier déchiffré. En effet, il serait impossible au dispositif destinataire B d’obtenir un tel condensé et de l’inscrire dans la chaîne de blocs s’il n’avait pas pu déchiffrer le fichier au préalable. Si le dispositif certificateur A est du type orchestrateur mettant à disposition d’un dispositif émetteur U un service de certification de partage de documents, le dispositif certificateur peut, dans une étape postérieure à l’étape H8, transmettre au dispositif émetteur un accusé de réception certifiant la bonne réception par le dispositif destinataire B du fichier. Cet accusé de réception peut comprendre l’identifiant d’inscription id_tag_ack_file obtenu à l’étape H4. Cet accusé de réception peut aussi comprendre l’identifiant d’inscription obtenu à l’étape H8, quand celle-ci est mise en œuvre, c’est-à-dire que le dispositif certificateur A reçoit un accusé de réception ack_key de la clef de déchiffrement. L’identifiant d’inscription de l’accusé de réception de la clef de déchiffrement est particulièrement utile au dispositif émetteur U quand l’accusé de réception ack_key comprend le condensé hash_A’ du fichier déchiffré, car le dispositif émetteur, quand il possède une copie du fichier déchiffré, peut en contrôler lui-même l’intégrité. De manière plus générale, il est possible de résumer le procédé de certification mis en œuvre par le dispositif certificateur A, dans cette variante où l’accusé de réception est inscrit par le dispositif destinataire et non par le dispositif certificateur, de la façon suivante : - réception, en provenance du dispositif destinataire B, d’une information (comme l’identifiant id_tag_ack_file) permettant d’obtenir un accusé de réception ack_file du fichier chiffré c_file auprès d’un premier espace de stockage numérique (comme la chaîne de blocs ci-dessus), - stockage, dans un deuxième espace de stockage numérique, de la première donnée d1 chiffrée et déchiffrable par le deuxième dispositif, - réception, en provenance dudit deuxième dispositif, d’une deuxième donnée d2, - vérification de si la deuxième donnée d2 est égale à la première donnée d1, et, en cas de vérification positive, déclenchement d’une transmission à destination du dispositif destinataire B d’une clef de déchiffrement k_file du fichier chiffré c_file. Le procédé de confirmation de partage selon cette variante, exécuté par le dispositif destinataire, comprend : - stockage, dans un premier espace de stockage numérique, d’un accusé de réception ack_file du fichier chiffré c_file, - transmission, à destination du premier dispositif A, d’une information permettant au premier dispositif d’obtenir ledit accusé de réception ack_file du fichier chiffré c_file, - transmission, à destination du premier dispositif A, d’une deuxième donnée d2 obtenue par déchiffrement d’une première donnée d1 chiffrée obtenue par le deuxième dispositif suite à la transmission de l’information permettant au premier dispositif d’obtenir l’accusé de réception ack_file du fichier chiffré c_file, - réception, en provenance du premier dispositif A, d’une clef de déchiffrement k_file du fichier chiffré c_file. Ainsi, ce procédé permet avantageusement de faire inscrire par le dispositif destinataire, dans l’espace de stockage numérique (comme une chaîne de blocs) l’accusé de réception du fichier chiffré. Cela permet de conserver une trace d’une telle réception, et en particulier cela permet au dispositif destinataire de ne pas avoir à faire confiance au dispositif certificateur pour ce qui est d’inscrire cet accusé de réception. 5.10 Dispositifs On présente finalement, en relation avec les figures 6 et 7, les structures simplifiées d’un dispositif certificateur A et d’un dispositif destinataire B selon un mode de réalisation de l’invention. Comme illustré en , un premier dispositif A selon un mode de réalisation de l’invention comprend une mémoire 100, une unité de traitement 110, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 120, mettant en œuvre des étapes du procédé de certification selon au moins un mode de réalisation de l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 120 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 110. Le processeur de l’unité de traitement 110 met en œuvre des étapes du procédé de certification de partage décrit précédemment, selon les instructions du programme d’ordinateur 120, pour : - recevoir, en provenance dudit deuxième dispositif B, un accusé de réception ack_file par le deuxième dispositif du fichier chiffré c_file, - stocker, dans un espace de stockage numérique BDD1, une première donnée d1 chiffrée et déchiffrable par le deuxième dispositif, et ledit accusé de réception ack_file du fichier chiffré c_file, - recevoir, en provenance dudit deuxième dispositif, une deuxième donnée d2, - vérifier si la deuxième donnée d2 est égale à la première donnée d1, et, en cas de vérification positive, déclencher une transmission à destination du deuxième dispositif B d’une clef de déchiffrement k_file du fichier chiffré c_file. Comme illustré en , un deuxième dispositif B selon un mode de réalisation de l’invention comprend une mémoire 200, une unité de traitement 210, équipée par exemple d’une machine de calcul programmable ou d’une machine de calcul dédiée, par exemple un processeur P, et pilotée par le programme d’ordinateur 220, mettant en œuvre des étapes du procédé de certification selon au moins un mode de réalisation de l’invention. A l’initialisation, les instructions de code du programme d’ordinateur 220 sont par exemple chargées dans une mémoire RAM avant d’être exécutées par le processeur de l’unité de traitement 210. Le processeur de l’unité de traitement 210 met en œuvre des étapes du procédé de certification de partage décrit précédemment, selon les instructions du programme d’ordinateur 220, pour : - transmettre, à destination du premier dispositif A, un accusé de réception ack_file du fichier chiffré c_file, - transmettre, à destination du premier dispositif A, une deuxième donnée d2 obtenue par déchiffrement d’une première donnée d1 chiffrée obtenue par le deuxième dispositif suite à la transmission de l’accusé de réception ack_file du fichier chiffré c_file, - recevoir, en provenance du premier dispositif A, d’une clef de déchiffrement k_file du fichier chiffré c_file. Procédé de certification par un premier dispositif (A) d’un partage d’un fichier (file) à au moins un deuxième dispositif (B), le procédé étant mis en œuvre par ledit premier dispositif (A) et comprenant : - une réception (E2), en provenance dudit deuxième dispositif (B), d’un accusé de réception (ack_file) par le deuxième dispositif du fichier chiffré (c_file), - un stockage (E3), dans un espace de stockage numérique (BDD1), d’une première donnée (d1) chiffrée et déchiffrable par le deuxième dispositif, et dudit accusé de réception (ack_file) du fichier chiffré (c_file), - une réception (E6), en provenance dudit deuxième dispositif, d’une deuxième donnée (d2), - une vérification (E7) si la deuxième donnée (d2) est égale à la première donnée (d1), et, en cas de vérification positive, déclenchement (E8) d’une transmission à destination du deuxième dispositif (B) d’une clef de déchiffrement (k_file) du fichier chiffré (c_file). Procédé de certification selon la revendication 1, dans lequel le premier dispositif (A) obtient un premier condensé (hash_A) du fichier chiffré (c_file), et dans lequel l’accusé de réception (ack_file) du fichier chiffré (c_file) comprend un deuxième condensé (hash_B) du fichier chiffré tel qu’obtenu par le deuxième dispositif, la réception du premier condensé (hash_B) déclenchant une vérification de si ledit premier condensé (hash_A) est égal au deuxième condensé (hash_B), et, en cas de vérification positive, un déclenchement dudit stockage, dans le premier espace de stockage numérique (BDD1), de ladite première donnée (d1) chiffrée et d’au moins le premier condensé. Procédé de certification selon l’une des revendications précédentes, comprenant en outre - une réception, en provenance du deuxième dispositif, d’un accusé de réception (ack_key) de ladite clef de déchiffrement, et - un stockage, dans un deuxième espace de stockage numérique, dudit accusé de réception (ack_key) de ladite clef de déchiffrement. Procédé selon la revendication 3, dans lequel l’accusé de réception de la clef de déchiffrement comprend un condensé d’un fichier déchiffré, et dans lequel le stockage dudit accusé de réception de la clef de déchiffrement comprend la vérification de si le condensé du fichier déchiffré en provenance du deuxième dispositif est identique à un condensé du fichier déchiffré que le premier dispositif détermine à l’aide du fichier chiffré (c_file) et de la clef de déchiffrement (k_file). Procédé de certification selon l’une des revendications précédentes, dans lequel au moins un espace de stockage numérique est une chaîne de blocs. Procédé de confirmation de partage à au moins un deuxième dispositif (B), le procédé étant mis en œuvre par le deuxième dispositif ayant obtenu un fichier chiffré (c_file) et comprenant : - une transmission (E1), à destination d’un premier dispositif (A), d’un accusé de réception (ack_file) du fichier chiffré (c_file), - une transmission (E5), à destination du premier dispositif (A), d’une deuxième donnée (d2) obtenue par déchiffrement d’une première donnée (d1) chiffrée obtenue par le deuxième dispositif suite à la transmission de l’accusé de réception (ack_file) du fichier chiffré (c_file), - une réception (E9), en provenance du premier dispositif (A), d’une clef de déchiffrement (k_file) du fichier chiffré (c_file). Procédé de confirmation de partage selon la revendication 6, comprenant en outre : - une obtention, à partir du fichier chiffré (c_file), d’un condensé (hash_B) de celui-ci, et - une transmission, à destination du premier dispositif (A), du condensé (hash_B) ainsi obtenu. Procédé de confirmation de partage selon l’une des revendications 6 ou 7, comprenant en outre : - une transmission, à destination du premier dispositif (A), d’un accusé de réception (ack_key) de ladite clef de déchiffrement. Procédé de confirmation de partage selon la revendication 8, dans lequel l’accusé de réception (ack_key) de la clef de déchiffrement (k_file) comprend un condensé du fichier déchiffré obtenu par le deuxième dispositif (B) à l’aide du fichier chiffré (c_file) et de la clef de déchiffrement (k_file). Premier dispositif pour la certification d’un partage d’un fichier (file) à au moins un deuxième dispositif (B), caractérisé en ce que le premier dispositif (A) comprend : - des moyens de réception (E2), en provenance dudit deuxième dispositif (B), d’un accusé de réception (ack_file) par le deuxième dispositif du fichier chiffré (c_file), - des moyens de stockage (E3), dans un espace de stockage numérique (BDD1), d’une première donnée (d1) chiffrée et déchiffrable par le deuxième dispositif, et dudit accusé de réception (ack_file) du fichier chiffré (c_file), - des moyens de réception (E6), en provenance dudit deuxième dispositif, d’une deuxième donnée (d2), - des moyens de vérification (E7) si la deuxième donnée (d2) est égale à la première donnée (d1), et, en cas de vérification positive, des moyens de déclenchement (E8) d’une transmission à destination du deuxième dispositif (B) d’une clef de déchiffrement (k_file) du fichier chiffré (c_file). Deuxième dispositif pour la confirmation d’un partage d’un fichier, le procédé étant mis en œuvre par le deuxième dispositif ayant obtenu un fichier chiffré (c_file) et comprenant : - des moyens de transmission (E1), à destination d’un premier dispositif (A), d’un accusé de réception (ack_file) du fichier chiffré (c_file), - des moyens de transmission (E5), à destination du premier dispositif (A), d’une deuxième donnée (d2) obtenue par déchiffrement d’une première donnée (d1) chiffrée obtenue par le deuxième dispositif suite à la transmission de l’accusé de réception (ack_file) du fichier chiffré (c_file), - des moyens de réception (E9), en provenance du premier dispositif (A), d’une clef de déchiffrement (k_file) du fichier chiffré (c_file). Produit programme d’ordinateur comprenant des instructions de code de programme pour la mise en œuvre d’un procédé selon l’une des revendications 1 à 9, lorsqu’il est exécuté par un processeur.