FR3129744A1 - Procédé de traitement d’une transaction impliquant l’utilisation d’un identifiant public, dispositif, système et programmes d'ordinateurs correspondants. - Google Patents
Procédé de traitement d’une transaction impliquant l’utilisation d’un identifiant public, dispositif, système et programmes d'ordinateurs correspondants. Download PDFInfo
- Publication number
- FR3129744A1 FR3129744A1 FR2112760A FR2112760A FR3129744A1 FR 3129744 A1 FR3129744 A1 FR 3129744A1 FR 2112760 A FR2112760 A FR 2112760A FR 2112760 A FR2112760 A FR 2112760A FR 3129744 A1 FR3129744 A1 FR 3129744A1
- Authority
- FR
- France
- Prior art keywords
- event
- multimedia data
- public
- identifier
- data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 50
- 238000012545 processing Methods 0.000 title claims abstract description 27
- 238000004590 computer program Methods 0.000 title claims description 8
- 238000004891 communication Methods 0.000 claims description 48
- 238000012795 verification Methods 0.000 claims description 25
- 230000008569 process Effects 0.000 claims description 12
- 230000005540 biological transmission Effects 0.000 claims description 8
- 238000010200 validation analysis Methods 0.000 claims description 6
- 230000006870 function Effects 0.000 description 9
- 230000004044 response Effects 0.000 description 9
- 230000015654 memory Effects 0.000 description 7
- 239000000463 material Substances 0.000 description 6
- 238000003780 insertion Methods 0.000 description 5
- 230000037431 insertion Effects 0.000 description 5
- 238000012790 confirmation Methods 0.000 description 4
- 238000004364 calculation method Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000013527 convolutional neural network Methods 0.000 description 2
- 238000013135 deep learning Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000004931 aggregating effect Effects 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000004880 explosion Methods 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 238000005242 forging Methods 0.000 description 1
- 201000011243 gastrointestinal stromal tumor Diseases 0.000 description 1
- 238000004377 microelectronic Methods 0.000 description 1
- 238000003672 processing method Methods 0.000 description 1
- 238000011144 upstream manufacturing Methods 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
Classifications
-
- 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
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Technology Law (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Multimedia (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Storage Device Security (AREA)
Abstract
L’invention se rapporte à un procédé de traitement de données multimédias comprenant une association d’un évènement, réalisé pour le compte d’une entité disposant d’un identifiant public se présentant sous la forme d’une chaine de caractères, à des données multimédias. Le procédé est mis en œuvre au sein d’un système électronique et il comprend la mise en œuvre des étapes suivantes : - obtention d’au moins une donnée représentative d’un évènement, sous la forme d’un identifiant public d’évènement ; - sélection des données multimédias à associer à l’identifiant public d’évènement ; et - postérieurement à une étape de vérification de la disponibilité des données multimédias, inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue des données multimédias sélectionnées. Fig. 1
Description
1. Domaine
L’invention se rapporte au domaine du traitement de transactions impliquant des utilisateurs identifiés. L’invention se rapporte plus spécifiquement au traitement de transactions dans lesquelles des utilisateurs mettent en œuvre une identité publiquement vérifiable. Des telles transaction sont par exemple basées sur la mise en œuvre d’identités publiques connues ou non d’une entité auprès de laquelle la transaction est réalisée.
2. Art antérieur
Avec l’accroissement de moyens de communication et des capacités de traitements de données multimédia sur des terminaux de communication de petite taille, la diffusion, par tout à chacun, de contenus multimédias sur les réseaux sociaux a entrainé une explosion de la présence de contenus en ligne. Le plus souvent, ces contenus multimédias présentent un intérêt mineur voire ne présentent pas d’intérêt. Cependant, la diffusion du contenu multimédia, en elle-même, n’est pas contrôlée. Par exemple, il est fréquent que des évènements soient captés/capturés par un utilisateur et postés sous la forme de photos ou de vidéos sur un réseau social. Ces post peuvent avoir un caractère diffamant ou bien choquant et devraient être retirés du réseau social en question, et la plateforme éditrice du réseau social devrait s’assurer que ces contenus multimédias ne soient pas à nouveau postés. Pourtant, face au problème de modération, les plateformes sont souvent bien incapables de repérer efficacement les contenus pouvant poser problèmes. Techniquement, la modération des contenus est effectuée selon deux modalités différentes : la première méthode consiste en l’utilisation de réseaux de neurones artificiels (à base d’apprentissage profond, Deep Learning) pour repérer les contenus offensants ou problématiques, et éliminer ces contenus au fur et à mesure de leur apparition ; la deuxième méthode consiste en l’utilisation de groupe de modérateurs, qui sont des personnes physiques chargées d’éliminer ces contenus. Force est de constater, cependant que ces deux techniques n’empêchent pas la rediffusion de ces contenus, qui sont sauvegardés sur les terminaux des utilisateurs pour être postés soit sous des formes modifiées soit sur d’autres réseaux.
Une autre problématique à laquelle les utilisateurs sont confrontés est le vol ou la réutilisation de contenus multimédias originaux à des fins de désinformation ou de réappropriation. Un des problèmes techniques pour contrer de tels vols ou réappropriation est d’identifier la première diffusion d’un contenu. Par exemple, lorsqu’un évènement survient (par exemple un évènement impliquant des personnes connues, une catastrophe humanitaire, une manifestation, etc.) et qu’un utilisateur capture des données multimédias relatives à cet évènement, la diffusion de ces données multimédias sur les réseaux n’est pas contrôlée. L’utilisateur qui diffuse ces données multimédias relatives à un évènement, quel qu’il soit, perd quasiment immédiatement le contrôle de ces données multimédias une fois qu’elles ont été diffusées. Par la suite, il est très simple, pour un utilisateur malveillant, de détourner ces données multimédias pour les réutiliser dans un autre contexte (par exemple à des fins de désinformation) ou pour se les approprier à la place du détenteur original.
Pour pallier ces problèmes, des méthodes ont été proposées, notamment à base de marquage (« watermark », « digital fingerprint »). Ces méthodes de marquage présentent un intérêt pour identifier le propriétaire d’un contenu. En revanche, ces méthodes ne sont efficaces que lorsque le propriétaire initie un marquage avant que la publication du contenu multimédia ne soit effectuée. Lorsque le marquage est effectué après une première diffusion, par exemple sur un réseau social, il ne représente plus une preuve de propriété et il ne peut plus servir de base pour un filtrage de contenus. Ce marquage « tardif » ne peut pas non plus servir de base à l’éviction automatique des contenus postés sur les réseaux sociaux pour faciliter le travail des plateformes, car le contenu diffusé à l’origine (i.e. sans marquage) peut toujours faire l’objet de diffusion ultérieures.
Il est donc nécessaire de disposer d’un mécanisme qui permette de traiter ce type de situation de manière simple tout en assurant une certaine facilité de traitement pour l’utilisateur.
3. Résumé de l’invention
La technique qui est présentée ici a été réalisée en conservant ces problématiques de l’art antérieur à l’esprit. Plus particulièrement, cette technique permet de résoudre au moins certains des inconvénients de l’art antérieur. Elle offre une association forte entre un premier évènement (comprenant l’utilisation d’un identifiant public) et des données multimédias, association qui peut être vérifiée par un observateur extérieur et dont l’intégrité est garantie par les propriétés cryptographiques des chaînes de blocs. Les données multimédias ne sont pas enregistrées directement dans la chaîne de blocs, améliorant ainsi la rapidité du processus de traitement de la transaction, et notamment l’insertion de la transaction dans la chaine de blocs. Surtout, elle permet à l’entité d’enregistrement de l’évènement de certifier l’existence de cette transaction en utilisant l’identifiant public de l’entité utilisé dans le premier évènement.
Plus particulièrement, l’invention se rapporte à un procédé de traitement de données multimédias comprenant une association d’un évènement, réalisé pour le compte d’une entité disposant d’un identifiant public à des données multimédias, procédé mis en œuvre au sein d’un système électronique. Un tel procédé comprend la mise en œuvre des étapes suivantes :
- obtention d’au moins une donnée représentative d’un évènement, sous la forme d’un identifiant public d’évènement ;
- sélection des données multimédias à associer à l’identifiant public d’évènement ; et
- postérieurement à une étape de vérification de la disponibilité des données multimédias, inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue des données multimédias sélectionnées.
Ainsi, grâce à la technique mise en œuvre, il est possible de disposer, au sein d’une chaîne de blocs, d’une association entre une représentation d’en évènement et des données multimédia, lesquelles sont créées ou sélectionnées par l’utilisateur lui-même. De cette manière l’utilisateur peut utiliser, de manière simple, des données multimédias qu’il a lui-même créé ou sélectionné, par exemple à des fins de communication, tout en assurant que la transaction qui est associée à cet identifiant, permette, au travers de l’association faite au sein de la chaîne de blocs, de certifier cette association. De plus, la vie privée des entités bénéficiaires est préservée puisque seul l’identifiant public de l’entité bénéficiaire est utilisé pour créer cette association, et non pas un identifiant privé (que l’entité bénéficiaire souhaite pouvoir conserver sécrète ou à tout le moins discrète).
Selon une caractéristique particulière, l’étape d’obtention d’une donnée représentative d’un évènement, sous la forme d’un identifiant public d’évènement, comprend les étapes suivantes :
- obtention d’une représentation instantanée d’évènement, comprenant la concaténation d’au moins une donnée initiale et d’une donnée représentative d’un identifiant public de l’entité associée audit évènement ;
- obtention d’une clé secrète à partir de la représentation instantanée d’évènement ;
- obtention d’une clé publique à partir de la clé secrète ;
- obtention de l’identifiant public d’évènement de transaction à partir de la clé publique.
Ainsi, la génération de l’identifiant public d’évènement (qui va être associé à la transaction) est basée sur un processus cryptographique, par exemple mis en œuvre par l’utilisateur lui-même, par l’intermédiaire d’un terminal qu’il possède (par exemple un terminal de de communication ou un terminal de commerce), permettant de garantir l’unicité de cet identifiant public d’évènement.
Selon une caractéristique particulière, l’étape de sélection des données multimédias à associer à l’identifiant public d’évènement comprend :
- une étape de sélection, par le utilisateur, des données multimédias à associer à ladite transaction, représentées par un fichier ;
- une étape d’obtention d’une donnée représentative d’une validité des données multimédias sélectionnées ; et
- lorsque la donnée représentative d’une validité des données multimédias sélectionnées est négative, une étape de rejet des données multimédias sélectionnées.
Selon une caractéristique particulière, l’étape d’obtention, d’une donnée représentative d’une validité des données multimédias sélectionnées comprend :
- une étape de transmission, à un dispositif de vérification, d’un fichier représentant les données multimédias sélectionnées par le utilisateur ;
- une étape de détermination, par le dispositif de vérification, d’un identifiant unique des données multimédias ; et
- une étape de vérification, par le dispositif de vérification, de la validité de l’identifiant unique des données multimédias en fonction de critères de validation prédéterminés.
Selon un mode de réalisation particulier, l’étape de vérification de la disponibilité des données multimédias comprend :
- une étape d’obtention d’une empreinte d’une donnée représentative des données multimédias ;
- une étape d’obtention, auprès de la chaîne de blocs, d’une donnée représentative de l’existence de l’empreinte au sein de la chaîne de blocs ;
- lorsque la donnée représentative de l’existence de l’empreinte au sein de la chaîne de blocs est positive, une étape de rejet des données multimédias ;
- lorsque la donnée représentative de l’existence de l’empreinte au sein de la chaîne de blocs est négative, mise en œuvre de l’étape d’inscription.
Selon une caractéristique particulière, l’étape d’inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue de l’étape de vérification de la validité des données multimédias comprend :
- une étape d’obtention d’une clé publique associée à la représentation instantanée d’évènement ;
- une étape d’obtention de l’identifiant public d’évènement à partir de la clé publique associée à la représentation instantanée d’évènement ;
- une étape d’obtention d’une empreinte cryptographique d’une donnée représentative de des données multimédias ;
- une étape de signature, à l’aide d’une clé privée d’une entité de confiance, de l’identifiant public d’évènement et de l’empreinte cryptographique de la donnée représentative des données multimédias, délivrant une signature intermédiaire ;
- une étape de formation d’une transaction destinée à être insérée dans la chaîne de blocs, la transaction comprenant l’identifiant public d’évènement, l’empreinte cryptographique de la donnée représentative des données multimédias et la signature intermédiaire ;
- une étape de signature de la transaction avec la clé privée associée à l’identifiant public d’évènement, cette clé privée correspondant à la clé publique associée à la représentation instantanée d’évènement ; et
- une étape d’insertion de la transaction au sein de la chaîne de blocs.
Selon un mode de réalisation particulier, les étapes d’obtention de la première donnée représentative de l’évènement, sous la forme d’un identifiant public d’évènement et l’étape de sélection des données multimédias à associer à l’identifiant public d’évènements sont mises en œuvre au sein d’un terminal de communication en possession du utilisateur ; l’étape de vérification de la disponibilité dudit des données multimédias est mise en œuvre au sein d’un dispositif de vérification implémentant un service d’identification (et de certification) auquel le terminal de communication communique l’identifiant public d’évènement et les données multimédias ; et l’étape d’inscription, au sein de la chaîne de blocs, de la transaction, est initiée par l’intermédiaire du terminal de communication, après réception, en provenance du dispositif de vérification implémentant le service d’identification, d’une transaction partielle, comprenant une signature du service d’identification, ladite transaction partielle étant complétée par le terminal de communication après signature à l’aide de la clé privée associée à l’identifiant public d’évènement.
Ainsi, il est possible, à partir d’une application installée sur un terminal d’un utilisateur, de produire une association entre des données multimédias, librement choisies (ou créées) par l’utilisateur, tout en garantissant que les règles de mises en œuvre, centralisées, de choix de ces données multimédias soient respectées, et en garantissant la résolution des problèmes posés par les techniques de l’art antérieur précédemment mentionnées.
Selon une caractéristique particulière, l’étape de calcul, par le dispositif de vérification, des descripteurs, comprend au moins une étape de sélection des descripteurs à calculer en fonction du type de contenu multimédia reçus.
Selon un autre aspect, l’invention se rapporte également à un système électronique d’association d’un évènement impliquant l’utilisation d’un identifiant public d’une entité à des données multimédias, système caractérisé en ce qu’il comprend la mise en œuvre des moyens suivants :
- obtention d’au moins une donnée représentative d’un évènement, sous la forme d’un identifiant public d’évènement ;
- sélection des données multimédias à associer à l’identifiant public d’évènement ; et
- postérieurement à la mise en œuvre de moyens de vérification de la disponibilité des données multimédias, mise en œuvre de moyens d’inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue des données multimédias associées à l’identifiant public d’évènement.
Un tel système comprend notamment un terminal de communication d’utilisateur comprenant un module matériel de prise de vue couplé à un module matériel de traitement de ces prises de vue selon le procédé précédemment décrit, afin de permettre une association entre des données multimédias capturées par le module de prise de vue avec certains paramètres d’évènements utilisés par le module matériel de traitement.
Selon une implémentation préférée, les différentes étapes des procédés selon la présente divulgation sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un terminal d’exécution selon la présente technique et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau d’un terminal de communication, d’un serveur distant et/ou d’une chaîne de blocs, dans le cadre d’une répartition des traitements à effectuer et déterminés par un code source scripté ou un code compilé.
En conséquence, la présente technique vise aussi des programmes, susceptibles d’être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus.
Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
La présente technique vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus.
Le support d'informations peut être n'importe quelle entité ou terminal 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 un support mobile (carte mémoire) ou un disque dur ou un SSD.
D'autre part, le support d'informations 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. Le programme selon la présente technique peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations 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é en question.
Selon un mode de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels.
Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.).
De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc.
Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels.
Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique.
4. Dessins
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
- représente le procédé de traitement comprenant l’association des données multimédias et de l’identifiant public d’évènement au sein d’une chaine de blocs ;
- représente le procédé d’inscription dans une chaine de blocs;
- représente une architecture physique simplifiée d’un terminal de communication pouvant convenir à la réalisation du procédé décrit.
5. Description d’un mode de réalisation
5.1. Rappels du principe
Le principe consiste à construire une preuve numérique unique et infalsifiable de la survenance d’un évènement, cet évènement impliquant l’utilisation d’un identifiant public d’une entité (personne physique ou morale) et à placer cette preuve numérique au sein du terminal de communication de l’utilisateur. À l’aide d’un telle preuve numérique, insérée au sein d’une chaine de blocs sous la forme d’une transaction, il est possible de vérifier d’une part la réalité d’un évènement survenu à un instant donné et d’autre part de certifier que cet évènement comprend bien la participation d’une entité donnée, vérifiée par l’utilisation d’un identifiant public associé à cette entité. Dès lors, il est envisageable de réaliser une publication ou une utilisation de cette preuve à des fins par exemple juridiques. Ainsi, à la différence de la simple photographie, dont la validité ou la conformité peuvent être contestées, la présente technique permet au contraire de créer une preuve irréfutable de la survenance d’un évènement en associant cet évènement et des données multimédias qui le représentent au sein d’une chaine de blocs ; une fois inscrite sein de la chaine, la transaction (et les données qui y sont associées par l’intermédiaire du procédé de la présente) est infalsifiable et il est possible de reconstruire l’intégralité de la preuve en appliquant le procédé décrit pour vérifier qu’elle correspond bien à la transaction insérée dans la chaine de blocs. La construction de la preuve numérique et l’insertion de celle-ci dans la chaine de blocs sous la forme d’une transaction comprend, en relation avec les figures 1 et 2 :
- une étape d’initialisation (10), au cours de laquelle l’utilisateur obtient au moins une donnée initiale (DI), comprenant par exemple une donnée textuelle et/ou des données de localisation (coordonnées, nom de rue, nom de quartier ou de centre commercial) ; cette initialisation peut être enclenchée par l’utilisateur lui-même à l’aide d’un terminal de communications à sa disposition ou de tout type de terminal comme un terminal de paiement ou une caisse enregistreuse par exemple ;
- une étape d’obtention (20) d’un identifiant public (PubId) d’une entité avec (au sein de) laquelle l’évènement se produit ; cette obtention peut être mise en œuvre en requérant, auprès de l’entité en question, cet identifiant public, qui se présente par exemple sous la forme d’une chaine de caractères ; cet identifiant public peut par exemple être le nom d’une marque associée à une entreprise, un nom d’entreprise, un nom commun ou d’usage, un nom de scène, un identifiant de réseau social, etc.
- une étape optionnelle de vérification (30) de l’identifiant public (PubId) fourni délivrant une donnée de confirmation d’identifiant (ConfId) ;
- lorsque l’étape de vérification de l’identifiant public est mise en œuvre et que la donnée de confirmation de l’identifiant (ConfId) indique un identifiant public invalide (N), une étape de rejet (40) de la création de la transaction ;
- lorsque l’étape de vérification de l’identifiant public est mise en œuvre et que la donnée de confirmation de l’identifiant (PubId) indique un identifiant public valide (Y), ou bien lorsque l’étape de vérification de l’identifiant public n’est pas mise en œuvre, une étape de création (50) de la transaction au sein de la chaine de blocs (BC).
L’étape de création (50) de la transaction au sein de la chaine de blocs comprend, quant à elle :
- une étape d’obtention (51) d’au moins une donnée représentative de l’évènement, sous la forme d’un identifiant public d’évènement (iPubE), à partir des données initiales (DI) précédemment obtenues ;
- une étape de sélection (ou de création) (52) des données multimédias (DMM) à associer à l’identifiant public d’évènement (iPubE) ; et
- postérieurement à une étape de vérification (53) de la disponibilité des données multimédias (Y), inscription (54), au sein d’une chaîne de blocs (BC), d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue de l’étape de sélection des données multimédias.
L’étape d’obtention (20) d’un identifiant public (PubId) d’une entité peut comprendre notamment la demande exprimée par l’utilisateur, d’obtenir cet identifiant auprès de l’entité (personne physique ou morale) concernée par l’évènement, et la saisie de celle-ci ou bien la saisie immédiate par l’utilisateur de cet identifiant public si celui-ci le connait ou bien encore l’obtention électronique de l’identifiant public (par exemple par scan d’un code QR à disposition de l’utilisateur ou par requêtage à un service de fourniture d’identifiant public ou un service de vérification, comme par exemple un serveur transactionnel ou un serveur bancaire, sur la base de données en possession de l’utilisateur – comme des données numériques de carte d’identité ou de carte bancaire par exemple).
Une fois en possession de cet identifiant public, une étape de vérification de l’identifiant public peut optionnellement être mise en œuvre, par exemple en fonction de la manière dont l’identifiant public a été obtenu par l’utilisateur (notamment si l’utilisateur a saisi manuellement l’identifiant public). Cette étape peut comprendre la transmission, à un serveur spécifique, d’une requête de vérification de validité de l’identité publique. Plus particulièrement, l’identifiant public obtenu est transmis à un serveur de vérification. Ce serveur comprend des moyens de réception de requêtes en provenance de terminaux d’utilisateurs et des moyens de détermination d’un score de validité et des moyens de transmission du score de validité au terminal d’utilisateur requérant. Le score de validité peut prendre plusieurs formes (par exemple une valeur comprise entre 0 et 1 ou un entier non borné ou bien un booléen) ou bien il peut agréger plusieurs informations provenant de plusieurs sources différentes. Quoi qu’il en soit, le score est transmis au terminal d’utilisateur. En fonction du score, et d’un seuil configurable par l’utilisateur au sein du terminal de communication, l’identifiant public est considéré comme valide ou comme invalide. Par exemple, lorsque le score associé à l’identifiant public est inférieur à 0,5, celui-ci est considéré comme invalide et le procédé est interrompu.
5.2. Création d’un identifiant public d’évènement
Comme explicité précédemment, le procédé objet de la présente suppose la survenance d’un évènement à disposition de l’utilisateur. La création d’un identifiant (public) d’évènement comprend, notamment, comme indiqué précédemment, l’utilisation d’une identité publique d’une entité impliquée dans l’évènement et dont l’obtention a été décrite. Dans cet exemple de réalisation, l’évènement est lié à une paire de clé publique/privée. Ces clés sont utilisées pour prouver la propriété des données multimédias de l’évènement. Leur possession équivaut à celle de la représentation de l’évènement lui-même.
Dans cet exemple de réalisation, décrit en relation avec la , on met en œuvre la création d’un identifiant public d’évènement sur le terminal de communication de l’utilisateur. La première étape consiste donc à générer le matériel cryptographique nécessaire. Cette étape de génération du matériel cryptographique s’effectue uniquement sur le terminal de communication de l’utilisateur. Elle ne nécessite pas de connexion à un service extérieur. On utilise, dans ce mode de réalisation, un générateur aléatoire avec une entropie convenable. Astucieusement, ce générateur aléatoire est celui présent au sein d’un environnement sécurisé du terminal de communication ou d’un TEE de celui-ci (comme la carte SIM insérée dans le terminal de communication peut être utilisée à cette fin).
En premier lieu, une concaténation est effectuée à partir de plusieurs données initiales à disposition de l’utilisateur. Dans un exemple de réalisation, ces données initiales comprennent par exemple des coordonnées de localisation ou encore des données multimédias enregistrées par l’utilisateur (son video, photo) ou encore des données textuelles (ticket de caisse par exemple) sous forme numérique ou physique. En sus, l’identité publique d’une entité associée à l’évènement est également disponible. La concaténation est effectuée en obtenant une première chaine de caractères de l’identité publique et une deuxième chaine de caractères issue des données à disposition de l’utilisateur, et délivre la représentation instantanée d’évènement. Ces deux chaines sont concaténées et une fonction de hachage est utilisée pour dériver la clé secrète associée à la représentation instantanée d’évènement (par exemple la fonction de hachage SHA-256).
Dans un autre exemple de réalisation, l’utilisateur dispose de données multimédia (par exemple une photo), de données numériques textuelles représentatives de l’évènement et de l’identité publique de l’entité associée à l’évènement. Les données multimédia subissent un traitement d’unicité (permettant d’obtenir un identifiant textuel sous la forme d’une chaine de caractères, comme par exemple une signature MD5 ou autre), et ces trois données sont concaténées. Des données de localisation (coordonnées GPS ou autres données de localisation, tel que le nom d’un emplacement, le nom d’une rue, d’une place ou d’une boutique) peuvent également être ajoutées pour former un quadruplet de chaines de caractères qui sont concaténées. Ces données de localisation peuvent également remplacer les données textuelles. Cette représentation instantanée de l’évènement est ensuite utilisée pour former du matériel cryptographique.
Plus particulièrement, la clé secrète est dérivée de la représentation instantanée de l’évènement via la fonction de hachage SHA-256. La clé publique associée à la clé privée est ensuite dérivée de la clé secrète en utilisant le mécanisme de génération de clés de ECDSA sur une courbe elliptique idoine. Enfin, l’identifiant public de l’évènement est obtenu en appliquant la fonction de hachage RIPEMD160 à la clé publique. Cet identifiant public a une taille comprise entre 160bits et 320bits, permettant un usage facilité de cette chaine de taille réduite (20 à 40 caractères).
Quelle que soit la solution retenue, le terminal de l’utilisateur dispose d’un ensemble de matériels cryptographiques associée à l’évènement et notamment un identifiant public et non mémorisable de l’évènement. Cet identifiant public de l’évènement est ensuite utilisé pour effectuer l’association avec les données multimédias (qui peuvent être les mêmes que celles précédemment utilisées pour créer l’identifiant public de l’évènement, ou bien être totalement différentes).
5.3. Sélection des données multimédias à associer à l’identifiant d’évènement
Dans ce mode de réalisation, un contenu multimédia est représenté dans la chaîne de blocs par un jeton non-fongible. Pour garantir l’unicité des contenus et préserver les intérêts de chacun, la création d’un tel jeton est soumise, dans ce mode de réalisation, à l’autorisation préalable du service d’identification (IdS).
Cependant, préalablement à cette autorisation, l’utilisateur sélectionne un contenu multimédia associé à l’évènement (il peut s’agir d’un contenu qu’il vient capter, par exemple une photo ou une vidéo) représenté par un fichier enregistré sur le terminal d’utilisateur. Ce fichier est appelé contenu original, et un identifiant unique peut être dérivé de celui-ci. Le contenu original de base est celui qui est associé à l’évènement par l’utilisateur.
Or, selon l’invention, dans ce mode de réalisation, on ne souhaite pas d’une part que des contenus multimédias n’appartenant pas à l’utilisateur puissent être utilisés et d’autre part on ne souhaite pas qu’un utilisateur soit dépossédé d’un contenu original lui appartenant. La raison principale est qu’à la recherche de véracité dans la survenu des évènements, il n’est pas souhaitable que les contenus multimédias utilisés soient pillés par des personnes à des fins de réappropriation ou de désinformation, comme cela a été explicité précédemment.
Ainsi, pour palier le problème lié à des variations non autorisées dans les contenus multimédias, une requête est transmise, via l’application s’exécutant sur le terminal de communication de l’utilisateur, au service d’identification (IdS). L’utilisation du service d’identification créé un point de centralisation du processus, dans ce mode de réalisation, ce qui permet de garantir une certaine unicité de la validation des contenus multimédias, avec cependant le point faible lié à cette centralisation et à l’éventuelle compromission ou indisponibilité du service d’identification. Cette requête contient, dans ce mode de réalisation le fichier du contenu multimédia ainsi que l’identifiant d’évènement. Cette transmission conjointe permet ainsi au service d’identification de jouer le rôle d’entité de validation du contenu multimédia sélectionné (créé) par l’utilisateur.
À la réception de la requête, le service d’identification commence par déterminer un identifiant unique au contenu multimédia reçu. Il s’agit par exemple de réaliser une signature du contenu multimédia reçu, d’horodater cette réception, et d’identifier le terminal de communication de provenance. L’étape suivante consiste à calculer des descripteurs du contenu multimédia reçu. On peut par exemple utiliser de courts descripteurs d'image globaux tels que GIST ou VLAD ou des descripteurs basés sur des réseaux de neurones convolutifs (CNN), qui fournissent des représentations de signature efficaces avec des vecteurs à 128 dimensions. On peut également utiliser des agrégats de descripteurs locaux discriminants, par exemple SIFT ou SURF. La détermination des descripteurs à utiliser est fonction des conditions de mise en œuvre opérationnelles et des formats des contenus multimédia (vidéo/photo/son). En tout état de cause, le service d’identification sélectionne, pour un type de contenu donné, des descripteurs spécifiques pour ce type de contenu et s’assure ainsi d’une uniformité de l’identification des contenus multimédia transmis. La sélection des descripteurs est opérée a priori et est paramétrée.
À partir de ces descripteurs, une représentation unique du contenu multimédia est calculée (soit par agrégation de l’ensemble des descripteurs soit en intégrant ces descripteurs dans une base de données). Ces descripteurs sont ensuite comparés à des descripteurs déjà présents, soit dans la base du service d’identification (IdS), soit en communiquant avec d’autres services d’identification de contenus multimédia qui sont connectés au réseau de communication.
La comparaison des descripteurs permet de déterminer si le contenu multimédia soumis est original ou bien s’il s’agit d’une réutilisation d’un contenu multimédia existant. Dans ce deuxième cas, le contenu multimédia est considéré comme invalide.
Lorsque le contenu multimédia est invalide au regard des règles mises en œuvre, le service d’identification transmet, en réponse à la requête du terminal de communication, une réponse d’irrecevabilité (réponse négative). L’utilisateur est alors invité à sélectionner un nouveau contenu multimédia.
Si les descripteurs sont valides (et par la même occasion le contenu multimédia associé à ces descripteurs), le service d’identification peut alors effectuer une vérification (optionnelle) de disponibilité. Pour ce faire, le service d’identification calcule l’empreinte du contenu multimédia en appliquant une fonction de hachage sur les descripteurs du contenu multimédia. On note qu’en effectuant un calcul d’empreinte sur les descripteurs, et non pas sur le contenu multimédia lui-même, on permet ainsi de « bloquer » toute autre requête émanant d’un autre utilisateur, qui choisirait une variation de ce contenu multimédia (un autre utilisateur proche du premier utilisateur). Le service d’identification interroge alors la chaîne de blocs pour savoir si l’empreinte des descripteurs du contenu multimédia correspond à une empreinte existante.
S’il est déterminé que l’empreinte des descripteurs existe déjà dans la chaîne de blocs, Le service d’identification transmet alors, en réponse à la requête du terminal de communication, une réponse d’indisponibilité (réponse négative). L’utilisateur est alors invité à sélectionner un nouveau contenu multimédia.
Lorsque l’empreinte n’est pas encore enregistrée dans la chaîne de blocs, cela signifie que le contenu multimédia est disponible à l’enregistrement. Le service d’identification forme alors partiellement une transaction de création de l’association « identifiant public d’évènement/contenu multimédia » et y inclut sa signature.
La transaction contient l’empreinte (des descripteurs) du contenu multimédia (et non le contenu multimédia lui-même), ainsi que l’identifiant d’évènement fourni par le terminal de communication lors de la transmission de la requête d’interrogation du service d’identification. Cette transaction est transmise par le service d’identification au terminal de l’utilisateur en réponse à la requête de création précédemment transmise.
Alternativement à cet exemple de réalisation, le calcul des descripteurs et de l’empreinte de ces descripteurs peut être réalisée au sein du terminal de communication de l’utilisateur. Ceci permet notamment d’accélérer les transmissions d’information et les traitements, notamment en réduisant fortement le volume d’information à transmettre. De plus, cela permet également de se passer du service d’identification, dans certains cas de figure au moins, et permet de se contenter d’utiliser un service de publication. Par exemple, lorsque le contenu multimédia est une photo ou une vidéo qui vient d’être capturée par le terminal de communication, et que le terminal de communication est en mesure de disposer de cette information, il n’est pas nécessairement utile de faire appel à un service d’identification. Auquel cas, le terminal de communication peut mener à bien, en local, les étapes de calcul des descripteurs et des empreintes et effectuer lui-même la pré-signature de la transaction à l’aide d’une clé privée (par exemple une clé privée d’un TEE ou d’un Secure Element ou tout autre moyen cryptographique valide).
5.4. Insertion de la transaction dans un registre non modifiable
Après avoir reçu une réponse positive du service d’identification, l’association « empreinte des descripteurs du contenu multimédia/identifiant de l’évènement » peut alors être enregistrée au sein de la chaîne de blocs.
En réponse à la requête de création de l’empreinte des descripteurs du contenu multimédia (soit par l’intermédiaire du service d’identification connecté au terminal de communication, soit en interne au sein du terminal de communication lui-même), le terminal de communication dispose d’une transaction partielle de création de cet transaction de la chaine de blocs contenant l’identifiant de l’évènement obtenu préalablement, l’empreinte des descripteurs du contenu multimédia, et la signature de ces deux données par le service d’identification à l’aide de sa clé privée. Pour compléter cette transaction, le terminal de communication signe celle-ci avec la clé privée associée à l’évènement, obtenues à l’issue de la concaténation et du hachage des données initiales. Cette signature doit correspondre à la clé publique déjà référencée dans la transaction partielle (c’est-à-dire qu’il s’agit de la clé privée correspondant à la clé publique de l’évènement).
Une fois la transaction complétée, elle est transmise à la chaîne de blocs par l’intermédiaire d’un nœud. La transaction est diffusée dans le réseau de nœuds jusqu’à être réceptionnée par des nœuds forgeurs (lorsque de telles distinctions existent entre les nœuds). Au moins un nœud valide la transaction reçue et l’incluent dans un bloc. Du point de vue des nœuds, une transaction reçue est considérée comme valide lorsque :
- l’empreinte des descripteurs (sélectionnés) du contenu multimédia n’est pas déjà enregistrée dans la chaîne de blocs ; cette étape est similaire à la vérification de disponibilité effectuée par le service d’identification ;
- la signature de l’empreinte des descripteurs du contenu multimédia et de l’identifiant de l’évènement effectuée par le service du service d’identification est valide suite à sa vérification à l’aide de la clé publique du service d’identification ; Cette clé publique est accessible aux nœuds de la chaîne, soit sur demande soit le service est lui-même un nœud de la chaine ;
- la signature de la transaction (par la clé privée de l’identité auto-souveraine) est valide et correspond à la clé publique signée (par l’intermédiaire de l’identifiant de l’évènement) par le service d’identification ; cette étape revient à vérifier que la transaction a bien été émise par le dispositif de communication de l’utilisateur à partir des données initiales. En effet, au sein d’une chaîne de blocs, pour qu’une transaction soit valide, elle doit contenir la signature (avec la clé privée) de l’émetteur (identifié par son adresse, qui est dérivée de la clé publique).
Lorsque ces trois conditions sont réunies, la transaction est validée et inscrite au registre. Cela créé un jeton unique appartenant à l’utilisateur identifié par l’empreinte du contenu multimédia et représentant un évènement que l’utilisateur a enregistré. Ceci complète la création de l’évènement dans cet exemple de réalisation.
5.5. Publication de l’évènement en lien avec l’entité
Lorsque le terminal de communication obtient confirmation de la création de la transaction dans la chaine de blocs, il est en mesure de réaliser une publication de l’évènement référencé dans la chaine. Le contenu multimédia dont les descripteurs et l’empreinte ont été calculés est alors téléversé vers un service de publication de contenus (tels qu’un réseau social par exemple), et associé à l’utilisateur (par le biais de son terminal de communication). La publication mentionne également, de manière complémentaire, l’identifiant public de la personne physique ou morale associée à l’évènement (par exemple par l’utilisation d’un hashtag) ajouté au contenu multimédia téléversé vers le service de publication de contenus. De manière complémentaire, l’adresse de la transaction dans la chaine de blocs est également transmise au service de publication de contenus. A réception de ces éléments, le service de publication de contenus, d’une part effectue classiquement la publication des éléments reçus et d’autre part recherche et identifie la transaction dans la chaine de blocs à partir des éléments reçus. Astucieusement, une fois cette vérification effectuée, le service de publication de contenus peut apposer, sur la publication, une marque certifiant son authenticité. De cette manière, les utilisateurs qui prendrons connaissance de cette publication sont en mesure de déterminer son authenticité et peuvent par ailleurs relayer une information elle-même authentique.
5.6. Autres caractéristiques et avantages
On présente, en relation avec la , une architecture simplifiée d’un terminal de communication (TC) apte à effectuer tout ou une partie du traitement tel que présenté précédemment. Un terminal de communication comprend un premier module électronique comprenant une mémoire 31, une unité de traitement 32 équipée par exemple d’un microprocesseur, et pilotée par un programme d’ordinateur 33. Le terminal de communication comprend optionnellement, pour des fonctionnalités de sécurité, comme la génération de matériels cryptographiques, un deuxième module électronique comprenant une mémoire sécurisée 34, qui peut être fusionnée avec la mémoire 31 (comme indiqué en pointillés, dans ce cas la mémoire 31 est une mémoire sécurisée), une unité de traitement sécurisée 35 équipée par exemple d’un microprocesseur sécurisée et de mesure physiques de protection (protection physique autour de la puce, par treillis, vias, etc. et protection sur les interfaces de transmission de données), et pilotée par un programme d’ordinateur 36 spécifiquement dédié à cette unité de traitement sécurisée 35, ce programme d’ordinateur 36 mettant en œuvre tout ou une partie du procédé de traitement d’une transaction tel que précédemment décrit. Le groupe composé de l’unité de traitement sécurisée 35, de la mémoire sécurisée 34 et du programme d’ordinateur dédié 36 constitue le module sécurisé (PS) du terminal de communication. Dans au moins un mode de réalisation, la présente technique est mise en œuvre sous la forme d’un ensemble de programmes installés en partie ou en totalité sur cette portion sécurisée du terminal de traitement de transaction. Dans au moins un autre mode de réalisation, la présente technique est mise en œuvre sous la forme d’un composant dédié (CpX) pouvant traiter des données des unités de traitement et installé en partie ou en totalité sur la portion sécurisée du dispositif de traitement. Par ailleurs, le dispositif comprend également des moyens de communication (CIE) se présentant par exemple sous la forme de composants réseaux (Wi-Fi, 3G/4G/5G, filaire) qui permettent au dispositif de recevoir des données (I) en provenance d’entités connectées à un ou plusieurs réseaux de communication et des transmettre des données traitées (T) à de telles entités.
Un tel dispositif comprend, en fonction des modes de réalisation :
- des moyens d’obtention d’une donnée représentative d’un évènement ; et notamment :
- des moyens d’obtention des données initiales telles que précédemment décrites ;
- des moyens d’obtention d’une clé secrète à partir des données initiales ;
- des moyens d’obtention d’une clé publique à partir de la clé secrète ;
- des moyens d’obtention de l’identifiant de l’évènement à partir de la clé publique.
- des moyens de saisie ou de sélection d’un contenu multimédia (et éventuellement des moyens de génération d’empreintes et de descripteurs associés) ;
- des moyens de vérification de la validité de l’empreinte des descripteurs du contenu multimédia, soit directement, soit par transmission d’une requête idoine à un dispositif de validation au sien d’un réseau de communication ;
- des moyens de formation d’une transaction d’insertion dans une chaîne de blocs, à l’aide notamment de l’identifiant de l’évènement et/ou de données reçus d’un service de vérification/validation d’empreinte des descripteurs du contenu multimédia ;
- des moyens de transmission de requête d’insertion de la transaction dans une chaîne de blocs.
Comme explicité précédemment, ces moyens sont mis en œuvre par l’intermédiaire de modules et/ou de composants, par exemple sécurisés. Ils permettent ainsi d’assurer la sécurité des transactions réalisées tout en garantissant une plus grande maintenabilité du dispositif.
De plus, un tel terminal peut comprendre un générateur d’aléa avec une entropie suffisante de façon à garantir la sécurité des clés privées générées par le terminal. Si le terminal ne dispose pas d’un générateur d’aléa avec un niveau de sécurité suffisante, le matériel cryptographique lié à l’identité auto-souveraine peut être généré en amont et importé sur le terminal.
Claims (9)
- Procédé de traitement de données multimédias comprenant une association d’un évènement, réalisé pour le compte d’une entité disposant d’un identifiant public se présentant sous la forme d’une chaine de caractères, à des données multimédias, procédé mis en œuvre au sein d’un système électronique, le procédé comprenant la mise en œuvre des étapes suivantes :
- obtention d’au moins une donnée représentative d’un évènement, sous la forme d’un identifiant public d’évènement ;
- sélection des données multimédias à associer à l’identifiant public d’évènement ; et
- postérieurement à une étape de vérification de la disponibilité des données multimédias, inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue des données multimédias sélectionnées. - Procédé de traitement de données multimédias selon la revendication 1, caractérisé en ce que l’étape d’obtention d’une donnée représentative d’un évènement, sous la forme de l’identifiant public d’évènement, comprend les étapes suivantes :
- obtention d’une représentation instantanée d’évènement, comprenant la concaténation d’au moins une donnée initiale et d’une donnée représentative d’un identifiant public de l’entité associée audit évènement ;
- obtention d’une clé secrète à partir de la représentation instantanée d’évènement ;
- obtention d’une clé publique à partir de la clé secrète ;
- obtention de l’identifiant public d’évènement de transaction à partir de la clé publique. - Procédé de traitement de données multimédias selon la revendication 1, caractérisé en ce que l’étape de sélection des données multimédias à associer à l’identifiant public d’évènement comprend :
- une étape de sélection des données multimédias à associer à ladite transaction, représentées par un fichier ;
- une étape d’obtention d’une donnée représentative d’une validité des données multimédias sélectionnées ; et
- lorsque la donnée représentative d’une validité des données multimédias sélectionnées est négative, une étape de rejet des données multimédias sélectionnées. - Procédé de traitement de données multimédias selon la revendication 3 caractérisé en ce que l’étape d’obtention, d’une donnée représentative d’une validité des données multimédias sélectionnées comprend :
- une étape de transmission, à un dispositif de vérification, du fichier des données multimédias sélectionnées ;
- une étape de détermination, par le dispositif de vérification, d’un identifiant unique des données multimédias ; et
- une étape de vérification, par le dispositif de vérification, de la validité de l’identifiant unique des données multimédias en fonction de critères de validation prédéterminés. - Procédé selon la revendication 1, caractérisé en ce que l’étape de vérification de la disponibilité des données multimédias comprend :
- une étape d’obtention d’une empreinte d’une donnée représentative des données multimédias ;
- une étape d’obtention, auprès de la chaîne de blocs, d’une donnée représentative de l’existence de l’empreinte au sein de la chaîne de blocs ;
- lorsque la donnée représentative de l’existence de l’empreinte au sein de la chaîne de blocs est positive, une étape de rejet des données multimédias ;
- lorsque la donnée représentative de l’existence de l’empreinte au sein de la chaîne de blocs est négative, mise en œuvre de l’étape d’inscription. - Procédé de traitement de données multimédias selon la revendication 1 caractérisé en ce que, l’étape d’inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue de l’étape de vérification de la validité des données multimédias comprend :
- une étape d’obtention d’une clé publique associée à la représentation instantanée d’évènement ;
- une étape d’obtention de l’identifiant public d’évènement à partir de la clé publique associée à la représentation instantanée d’évènement ;
- une étape d’obtention d’une empreinte cryptographique d’une donnée représentative de des données multimédias ;
- une étape de signature, à l’aide d’une clé privée d’une entité de confiance, de l’identifiant public d’évènement et de l’empreinte cryptographique de la donnée représentative des données multimédias, délivrant une signature intermédiaire ;
- une étape de formation d’une transaction destinée à être insérée dans la chaîne de blocs, la transaction comprenant l’identifiant public d’évènement, l’empreinte cryptographique de la donnée représentative des données multimédias et la signature intermédiaire ;
- une étape de signature de la transaction avec la clé privée associée à l’identifiant public d’évènement, cette clé privée correspondant à la clé publique associée à la représentation instantanée d’évènement ; et
- une étape d’insertion de la transaction au sein de la chaîne de blocs. - Procédé selon la revendication 1, caractérisé en ce que les étapes d’obtention de la première donnée représentative de l’évènement, sous la forme d’un identifiant public d’évènement et l’étape de sélection des données multimédias à associer à l’identifiant public d’évènements sont mises en œuvre au sein d’un terminal de communication en possession d’un utilisateur ; l’étape de vérification de la disponibilité dudit des données multimédias est mise en œuvre au sein d’un dispositif de vérification implémentant un service d’identification auquel le terminal de communication communique l’identifiant public d’évènement et les données multimédias ; et l’étape d’inscription, au sein de la chaîne de blocs, de la transaction, est initiée par l’intermédiaire du terminal de communication, après réception, en provenance du dispositif de vérification implémentant le service d’identification, d’une transaction partielle, comprenant une signature du service d’identification, ladite transaction partielle étant complétée par le terminal de communication après signature à l’aide de la clé privée associée à l’identifiant public d’évènement.
- Système électronique d’association d’un évènement impliquant l’utilisation d’un identifiant public d’une entité à des données multimédias, système caractérisé en ce qu’il comprend la mise en œuvre des moyens suivants :
- obtention d’au moins une donnée représentative d’un évènement, sous la forme d’un identifiant public d’évènement ;
- sélection des données multimédias à associer à l’identifiant public d’évènement ; et
- postérieurement à la mise en œuvre de moyens de vérification de la disponibilité des données multimédias, mise en œuvre de moyens d’inscription, au sein d’une chaîne de blocs, d’une transaction basée au moins sur l’identifiant public d’évènement et sur une donnée issue des données multimédias sélectionnées. - Produit programme d’ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu’il comprend des instructions de code de programme pour l’exécution d'un procédé selon l’une des revendications 1 à 8, lorsqu’il est exécuté sur un processeur.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2112760A FR3129744A1 (fr) | 2021-11-30 | 2021-11-30 | Procédé de traitement d’une transaction impliquant l’utilisation d’un identifiant public, dispositif, système et programmes d'ordinateurs correspondants. |
| PCT/EP2022/083532 WO2023099418A1 (fr) | 2021-11-30 | 2022-11-28 | Procédé de traitement d'une transaction impliquant l'utilisation d'un identifiant public, dispositif, système et programmes d'ordinateurs correspondants |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR2112760 | 2021-11-30 | ||
| FR2112760A FR3129744A1 (fr) | 2021-11-30 | 2021-11-30 | Procédé de traitement d’une transaction impliquant l’utilisation d’un identifiant public, dispositif, système et programmes d'ordinateurs correspondants. |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR3129744A1 true FR3129744A1 (fr) | 2023-06-02 |
Family
ID=81307413
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR2112760A Pending FR3129744A1 (fr) | 2021-11-30 | 2021-11-30 | Procédé de traitement d’une transaction impliquant l’utilisation d’un identifiant public, dispositif, système et programmes d'ordinateurs correspondants. |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR3129744A1 (fr) |
| WO (1) | WO2023099418A1 (fr) |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190044727A1 (en) * | 2016-02-08 | 2019-02-07 | Guy Scott | A system and method for document information authenticity verification |
| US20200145387A1 (en) * | 2017-07-11 | 2020-05-07 | Swirlds, Inc. | Methods and apparatus for efficiently implementing a distributed database within a network |
| US20210209373A1 (en) * | 2017-10-26 | 2021-07-08 | Seagate Technology Llc | Media authentication using distributed ledger |
-
2021
- 2021-11-30 FR FR2112760A patent/FR3129744A1/fr active Pending
-
2022
- 2022-11-28 WO PCT/EP2022/083532 patent/WO2023099418A1/fr unknown
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20190044727A1 (en) * | 2016-02-08 | 2019-02-07 | Guy Scott | A system and method for document information authenticity verification |
| US20200145387A1 (en) * | 2017-07-11 | 2020-05-07 | Swirlds, Inc. | Methods and apparatus for efficiently implementing a distributed database within a network |
| US20210209373A1 (en) * | 2017-10-26 | 2021-07-08 | Seagate Technology Llc | Media authentication using distributed ledger |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2023099418A1 (fr) | 2023-06-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11798008B2 (en) | Blockchain-based product authentication system | |
| US11139976B2 (en) | System and method, which using blockchain and mobile devices, provides the validated and authenticated identity of an individual to a valid and authenticated requestor | |
| CN109417549A (zh) | 使用集中式或分布式分类账来提供信息证明的方法和设备 | |
| US20220215382A1 (en) | Blockchain-based product authentication system | |
| CN116432247A (zh) | 一种基于区块链的侵权存证方法及设备 | |
| CN104156862A (zh) | 一种基于微信平台的二维码防伪防窜货查询***和方法 | |
| CN103559221B (zh) | 一种进行多媒体数据处理的方法、装置和浏览器 | |
| WO2013021107A1 (fr) | Procede, serveur et systeme d'authentification d'une personne | |
| EP3803670A1 (fr) | Une application logicielle et un serveur informatique pour authentifier l'identité d'un créateur de contenu numérique et l'intégrité du contenu du créateur publié | |
| WO2023279059A2 (fr) | Registres distribués à entrées de registre contenant des charges utiles pouvant être rédigées | |
| WO2019129939A1 (fr) | Procede d' horodatation de posteriorite de representations numeriques de grandeurs analogiques grace a des consignes d'acquisition probantes fondees sur l'alea d'une blockchain | |
| WO2018104114A1 (fr) | Procédé d'enregistrement d'un contenu multimédia, procédé de détection d'une marque au sein d'un contenu multimédia, dispositifs et programme d'ordinateurs correspondants | |
| TWI803721B (zh) | 用於激勵數位身份驗證之系統及方法 | |
| CN111596890A (zh) | 一种基于分布式协议的区块链随机数种子生成方法、设备及介质 | |
| WO2020064890A1 (fr) | Procede de traitement d'une transaction, dispositif, systeme et programme correspondant | |
| US20230055835A1 (en) | Systems and Methods for Using a Non-Fungible Digital Asset to Facilitate Accessing an Access-Restricted Resource | |
| EA035281B1 (ru) | Способ осуществления транзакции по передаче цифровой ценности и система передачи цифровых ценностей для его осуществления | |
| FR3061971A1 (fr) | Procede d'authentification en deux etapes, dispositif et programme d'ordinateur correspondant | |
| EP3731116B1 (fr) | Procédé d'authentification d'un document d'identité d'un individu et d'authentification dudit individu | |
| EP3262553B1 (fr) | Procede de transaction sans support physique d'un identifiant de securite et sans jeton, securise par le decouplage structurel des identifiants personnels et de services | |
| WO2023099418A1 (fr) | Procédé de traitement d'une transaction impliquant l'utilisation d'un identifiant public, dispositif, système et programmes d'ordinateurs correspondants | |
| FR3040519A1 (fr) | Methode de securisation et de verifiabilite d’un vote electronique | |
| US20230274268A1 (en) | Systems and methods for minting non-fungible tokens at a point of sale | |
| EP3284209B1 (fr) | Procédés de génération et de vérification d'une clé de sécurité d'une unité monétaire virtuelle | |
| FR3113323A1 (fr) | Procede pour generer un document numerique securise stocke sur un terminal mobile et associe a une identite numerique |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 2 |
|
| PLSC | Publication of the preliminary search report |
Effective date: 20230602 |
|
| PLFP | Fee payment |
Year of fee payment: 3 |