FR3133244A1 - Certification de données multi-facteurs - Google Patents

Certification de données multi-facteurs Download PDF

Info

Publication number
FR3133244A1
FR3133244A1 FR2201791A FR2201791A FR3133244A1 FR 3133244 A1 FR3133244 A1 FR 3133244A1 FR 2201791 A FR2201791 A FR 2201791A FR 2201791 A FR2201791 A FR 2201791A FR 3133244 A1 FR3133244 A1 FR 3133244A1
Authority
FR
France
Prior art keywords
certifying
certificate
user terminal
module
instance
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
Application number
FR2201791A
Other languages
English (en)
Inventor
Nicolas Thomas
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Inkan Link
InkanLink
Original Assignee
Inkan Link
InkanLink
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Inkan Link, InkanLink filed Critical Inkan Link
Priority to FR2201791A priority Critical patent/FR3133244A1/fr
Priority to PCT/EP2023/055078 priority patent/WO2023166009A1/fr
Publication of FR3133244A1 publication Critical patent/FR3133244A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/602—Providing cryptographic facilities or services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H04L9/3268—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements using certificate validation, registration, distribution or revocation, e.g. certificate revocation list [CRL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Module (1) de traitement d’instances certifiantes (100) de données numériques, ledit module comportant un identifiant de l' utilisateur (200) et de systèmes certificateurs (300), dans lequel chacune des instances certifiantes est associée à une adresse de stockage, à un terminal utilisateur, et à un registre non répudiable comportant une liste ordonnée d’éléments, chacun des éléments comportant : une attestation générée par l’un des systèmes certificateurs, une attestation comportant un type d’attestation, un condensat d’un document, un horodatage par le système certificateur de l’instant de génération de ladite attestation ; une signature électronique de ladite attestation ; un horodatage par le module de traitement de l’instant d’ajout de l’élément dans la liste ordonnée ; possiblement un pointeur vers le document. Figure à publier : Figure 2

Description

Certification de données multi-facteurs
L’invention se situe dans le domaine de l’informatique du chiffrement et des systèmes garantissant la non répudiation, par exemple les chaînes de blocs, pour l’anglaisblockchains.
 État de la technique antérieure
Le monde de la cyber sécurité se focalise sur la chasse aux mauvais acteurs.
Les systèmes de certifications de données, existant reposent uniquement sur l’authentification des acteurs. Au mieux, les systèmes existants tels que PGP, S/MIME permettent de chiffrer et signer. Ils sont peu utilisés dans la pratique, requièrent une forte administration et connaissance technique de l’ensemble des acteurs qui l’utilise.
Un inconvénient de ce système de certification de donnée est qu’il est basé sur une source unique d’information. La solidité du système dépend exclusivement de la formation de l’ensemble des acteurs.
Un but de l’invention est notamment de remédier à tout ou partie des inconvénients précités.
Selon un premier aspect de l’invention, il est proposé un module de traitement d’instances certifiantes de données numériques, le module comportant un identifiant de l'utilisateur et de systèmes certificateurs, dans lequel chacune des instances certifiantes est associée à une adresse de stockage, à un terminal utilisateur, et à un registre non répudiable comportant une liste ordonnée d’éléments, chacun des éléments comportant :
  • une attestation générée par l’un des systèmes certificateurs, l’attestation comportant un type d’attestation, un condensat d’un document, un horodatage par le système certificateur de l’instant de génération de ladite attestation,
  • une signature électronique de ladite attestation,
  • un horodatage par le module de traitement de l’instant d’ajout de l’élément dans la liste ordonnée,
  • optionellement un pointeur vers le document éléctronique (par exemple une adresse mémoire dans un dispositif de stockage sur un réseau), en clair ou chiffré par une clef asymétrique détenue par le créateur du MFC.
Selon un deuxième aspect de l’invention, il est proposé un système comportant au moins un client, au moins un système certificateur, et un module de traitement d’instance selon le premier aspect de l’invention, ou l’un ou plusieurs de ses perfectionnements.
Selon un autre aspect de l’invention, il est proposé un procédé mis en œuvre dans un système selon le deuxième aspect de l’invention, ou l’un ou plusieurs de ses perfectionnements.
Le procédé peut comporter une étape de vérification de l’intégrité d’un fichier par un terminal utilisateur, ledit fichier étant reçu d’un autre terminal utilisateur.
L’étape de vérification de l’intégrité du fichier comporte alors les étapes suivantes, mises en œuvre au niveau du terminal utilisateur :
  • calculer un condensat du fichier reçu,
  • recevoir de l’autre terminal utilisateur une adresse de stockage d’une instance certifiante,
  • générer une requête de réception d’instance certifiante à partir de ladite adresse de stockage et l’envoyer au module,
  • recevoir du module l’instance certifiante associée à ladite adresse de stockage,
  • parcourir la liste d’éléments de l’instance certifiante reçue pour déterminer la présence ou l’absence d’un condensat d’une attestation qui soit le même que le condensat calculé.
Si la présence du condensat calculé est vérifiée, l’étape de vérification de l’intégrité du fichier peut comporter une ou plusieurs étape de vérification des autres attestations de la liste ordonnée d’éléments de ladite instance certifiante.
 Description des figures
D'autres avantages et particularités de l'invention apparaîtront à la lecture de la description détaillée de mises en œuvre et de modes de réalisation nullement limitatifs, au regard de dessins annexés sur lesquels :
  • illustre un exemple de réalisation d’un système selon l’invention,
  • illustre un cas d’utilisation d’un système selon l’invention,
  • illustre les différentes étapes d’une certification par un système selon l’invention,
  • illustre un diagramme de séquence d’échanges au sein du système selon l’invention.
Description de modes de réalisation
Les modes de réalisation décrits ci-après n’étant nullement limitatifs, on pourra notamment considérer des variantes de l'invention ne comprenant qu'une sélection de caractéristiques décrites, par la suite isolées des autres caractéristiques décrites, si cette sélection de caractéristiques est suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à l'état de la technique antérieure. Cette sélection comprend au moins une caractéristique, de préférence fonctionnelle sans détails structurels, ou avec seulement une partie des détails structurels si cette partie uniquement est suffisante pour conférer un avantage technique ou pour différencier l'invention par rapport à l'état de la technique antérieure.
Sur les figures un élément apparaissant sur plusieurs figures conserve la même référence.
Définitions
Condensat : un condensat est le résultat d’une fonction de hachage qui crée une empreinte des documents, données etc. Un condensat sert à valider l’intégrité de données.
Certification digitale : un procédé utilisant le chiffrement et la cryptographie asymétrique pour assurer la provenance des données numériques.
est un schéma d’un mode de réalisation d’un système selon l’invention.
Le système selon l’invention comporte : un module 1 de traitement d’instances certifiantes (100) de données numériques, ledit module comportant un identifiant de l' utilisateur (200) et de systèmes certificateurs (300).
Chacune des instances certifiantes est associée à une adresse de stockage de ladite instance, à un terminal utilisateur propriétaire de ladite instance, et à un registre (en anglaisledger) non répudiable. Le registre comporte une liste ordonnée d’éléments.
Chacun des éléments de la liste d’éléments ordonnées :
  • une attestation générée par l’un des systèmes certificateurs, une attestation comportant un type d’attestation, un condensat d’un document,
  • un horodatage par le système certificateur de l’instant de génération de ladite attestation,
  • une signature électronique de ladite attestation,
  • un horodatage par le module de traitement de l’instant d’ajout de l’élément dans la liste ordonnée,
  • possiblement un pointeur vers le document.
Le registre peut être implémenté en tant que “smart contract” sur un registre distribué sans permissions, tel qu’une blockchain, ou tout autre implémentation qui garantit la non répudiation des transactions sur le registre.
Une instance certifiante est initialisée par une étape d’enregistrement d’un d’acteur, identifiable par clefs asymétriques, et création d’une clef de chiffrement des données stockées l’instance certifiante.
Le module 1 implémente une fonction d’ajout d’une attestation à une instance certifiante.
Le module 1 implémente une fonction de transfert d’une instance certifiante à un autre terminal utilisateur.
Le module 1 implémente une fonction de vérification de l’ensemble des attestations d’une instance certifiante à réception d’un condensat et de l’instance certifiante.
Le module 1 peut être configuré pour accepter une requête de partage des attestations composant d’un registre d’une instance certifiante avec autorisation de l’acteur propriétaire du MFC.
Les attestations
Une attestation est générée par tout système certificateur qui a une donnée en lien avec le type d’attestation demandé par un terminal utilisateur ou un autre système numérique.
Une attestation comporte un condensat obtenu à partir d’un fichier du système certificateur qui permettent de valider le type d’attestation. Un type d’attestation correspond à une affirmation du terminal utilisateur. Cela peut être notamment : un fichier (par exemple une photographie, ou un fichier audio), une localisation, une signature, un audit (par exemple une vérification humaine des systèmes ayant généré le condensat ou encore un audit automatisé), , une proximité, une présence de témoin, une résidence, un achat, une preuve de propriété,, une délégation Les attestations de type délégation. La délégation permet de signer "au nom” d’une personne ou d’une entreprise. Ce type d’attestation est important pour pouvoir changer la clé d’un système certificateur, et pour autant conserver la trace que la signature était reconnue à une date antérieure au changement de clé.L’attestation est signée électroniquement et horodatée par le système certificateur, signature qui peut permettre d’identifier l’entreprise ou le responsable de la signature.
L’instance certifiante peut être configurée pour chiffrer l’attestation dans son stockage et ainsi la rendre accessible uniquement au terminal utilisateur associé à l’instance certifiante, c’est-à-dire son propriétaire. La clef publique de l’acteur propriétaire sera alors utilisée par défaut pour chiffrer l’attestation.
Il est possible qu’un système certificateur certifie l’absence de données liées à un terminal utilisateur. Dans ce cas le condensat aura la valeur “absence vérifiée”, par exemple codée par la valeur -1, ou « absence » codée par la valeur « -2 » . « absence vérifiée » correspond à un cas où il y a une donnée qui prouve que l’affirmation à certifier est fausse. Par exemple, pour la localisation d’un téléphone portable, la valeur “absence” signifie que le système n’a pas de données liées au terminal utilisateur.
On pourra invalider une attestation précédente en ajoutant une nouvelle attestation avec le condensat “erreur”. La transaction invalidée sera pointée par son identifiant dans le registre.
Exemple de mise en œuvre d’un système selon l’invention
La illustre un exemple de réalisation d’un procédé mis en œuvre dans un système selon l’invention.
Un utilisateur utilise son téléphone mobile pour générer un fichier, qui comprend une photographie, localisée par le GPS de son téléphone mobile, et des métadonnée.
L’utilisateur adresse une requête de création d’instance au module 1, en lui adressant un condensat du fichier généré et une signature électronique du condensat, ce qui est illustré par les étapes 1 et 2 de la .
Le module 1 crée une instance certifiante MFC associée au terminal utilisateur.
Un premier élément est ajouté au registre de l’instance certifiante MFC. Le premier élément comporte :
  • une attestation générée par l’utilisateur, l’attestation comportant un type d’attestation de type fichier, le condensat du fichier généré, un horodatage par le système certificateur de l’instant de génération de ladite attestation,
  • une signature électronique de ladite attestation,
  • un horodatage par le module 1 de l’instant d’ajout de l’élément dans la liste ordonnée.
Par suite, l’utilisateur adresse à un système certificateur une requête d’attestation pour ce fichier. Pour cela, le terminal utilisateur envoie au système certificateur, un type d’attestation requis, ainsi qu’un identifiant du terminal utilisateur auprès du service certificateur de cette entreprise.
Dans l’exemple représenté, le système certificateur est prévu pour certifier l’accès du terminal utilisateur au système wifi de l’entreprise, ce qui est illustré par l’étape 3 de la .
A réception de la requête, le système certificateur collecte des données auprès d’un système d’information pour générer un fichier relatif au type d’attestation requis, à l’identifiant du terminal utilisateur.
Le système certificateur calcule par la suite un condensat et génère une attestation comportant un horodatage par le système certificateur de l’instant de création de l’attestation. L’attestation est envoyée, ainsi que sa signature électronique, à destination du terminal utilisateur.
A réception de l’attestation et de la signature électronique par le terminal utilisateur, ce dernier adresse ses éléments, ainsi que l’adresse de l’instance certifiante au module 1.
Le module 1 est alors configuré pour ajouter l’attestation et sa signature électronique comme nouvel élément à la liste ordonnée d’éléments de l’instance.
Par suite, l’utilisateur peut adresser une nouvelle requête d’attestation pour ce fichier à un autre système certificateur.
Dans l’exemple représenté sur , étape 4, le procédé comporte l’ajout d’une attestation (ou lien) de vérification de proximité avec un téléphone d’un employé.
Dans l’exemple représenté sur , étape 5, le procédé comporte en outre l’ajout d’une attestation (ou lien) de vérification de la photo par un employé.
La illustre un exemple de séquence d’un procédé mis en œuvre dans un système selon l’invention. Les références sont ici spécifiquement liées à la .
Un utilisateur 1 utilise 1 une application mobile configurée pour communiquer avec le système selon l’invention. Ladite application mobile crée d’une part une photographie et d’autre part adresse 3 une requête de création d’instance au module en lui adressant un condensat du fichier généré et une signature électronique du condensat, ce qui est illustré par les étapes 1 et 2 de la .
Le module crée 4 une instance certifiante MFC associée au terminal utilisateur, comportant un registre.
Le module renvoi 5 une adresse de l’instance certifiante à l’application mobile.
L’application mobile reçoit 6 un agrégat de la photo.
L’application mobile adresse 7 une requête d’ajout d’attestions auprès du module en lui adressant l’adresse de l’instance certifiante, un condensat du fichier généré et une signature électronique du condensat
Un premier élément est ajouté 8 au registre de l’instance certifiante MFC. Le premier élément comporte :
  • une attestation générée par l’application, l’attestation comportant un type d’attestation de type fichier, le condensat du fichier généré, un horodatage par le système certificateur de l’instant de génération de ladite attestation,
  • une signature électronique de ladite attestation,
  • un horodatage par le module 1 de l’instant d’ajout de l’élément dans la liste ordonnée,
Par suite l’application mobile requiert 9 l’ajout de la localisation GPS auprès du module.
Un deuxième élément est ajouté 10 au registre l’instance certifiante. Par suite, l’utilisateur adresse 11 à un système certificateur une requête d’attestation pour ce fichier. Pour cela, le terminal utilisateur envoie au système certificateur, un type d’attestation requis, ainsi qu’un identifiant du terminal utilisateur auprès du service certificateur de cette entreprise.
Dans l’exemple représenté, le système certificateur est prévu pour certifier l’accès du terminal utilisateur au système wifi de l’entreprise.
A réception de la requête, le système certificateur collecte des données auprès d’un système d’information pour générer un fichier relatif au type d’attestation requis, à l’identifiant du terminal utilisateur.
Le système certificateur calcule par la suite un condensat 12 et génère une attestation comportant un horodatage par le système certificateur de l’instant de création de l’attestation. Dans l’exemple illustré, l’attestation est envoyée 13, ainsi que sa signature électronique, à destination du moduel.
Le module 1 est alors configuré pour ajouter 14 l’attestation et sa signature électronique comme nouvel élément à la liste ordonnée d’éléments de l’instance.
Vérification de l’intégrité d’un fichier
Le procédé selon l’invention peut comporter une étape de vérification de l’intégrité d’un fichier par un terminal utilisateur, le fichier étant reçu d’un autre terminal utilisateur.
A cet effet, le terminal utilisateur met en œuvre les étapes suivantes :
  • calculer un condensat du fichier reçu,
  • recevoir de l’autre terminal utilisateur une adresse de stockage d’une instance certifiante,
  • générer une requête de réception d’instance certifiante à partir de ladite adresse de stockage et l’envoyer au module (1),
  • recevoir du module (1) l’instance certifiante associée à ladite adresse de stockage,
  • parcourir la liste ordonnées d’éléments de l’instance certifiante reçue pour déterminer la présence ou l’absence d’un condensat d’un attestation qui soit le même que le condensat calculé
Si la présence du condensat calculé est vérifiée, l’étape de vérification de l’intégrité du fichier peut comporter une ou plusieurs étapes de vérification des autres attestations de la liste ordonnée d’éléments de ladite instance certifiante.
A cet effet, le terminal utilisateur peut adresser, par exemple de manière itérative, une requête de vérification à chacun des systèmes certificateurs, comportant l’attestation.
A réception de ladite requête de vérification, le système certificateur peut vérifier l’intégrité de l’attestation en calculant de nouveau le condensat lié au fichier utilisé pour générer l’attestation, et le comparer avec le condensat contenu dans l’attestation reçue. Si les deux condensats sont égaux, le système certificateur adresse une réponse positive au terminal utilisateur, sinon il adresse une réponse négative.
Le terminal utilisateur peut ainsi s’assurer de l’intégrité du fichier reçu auprès de plusieurs systèmes certificateurs, augmentant ainsi sa confiance dans l’intégrité du fichier reçu.
Bien sûr, l’invention n’est pas limitée aux exemples qui viennent d’être décrits et de nombreux aménagements peuvent être apportés à ces exemples sans sortir du cadre de l’invention. De plus, les différentes caractéristiques, formes, variantes et modes de réalisation de l’invention peuvent être associés les uns avec les autres selon diverses combinaisons dans la mesure où ils ne sont pas incompatibles ou exclusifs les uns des autres.

Claims (3)

  1. Module (1) de traitement d’instances certifiantes (100) de données numériques, ledit module comportant un identifiant d’un terminal utilisateur (200) et de systèmes certificateurs (300),
    dans lequel
    chacune des instances certifiantes est associée à une adresse de stockage, à un terminal utilisateur, et à un registre non répudiable comportant une liste ordonnée d’éléments, chacun des éléments comportant :
    une attestation générée par l’un des systèmes certificateurs, l’attestation comportant un type d’attestation, un condensat d’un document, un horodatage par le système certificateur de l’instant de génération de ladite attestation,
    une signature électronique de ladite attestation,
    un horodatage par le module de traitement de l’instant d’ajout de l’élément dans la liste ordonnée,
    optionellement un pointeur vers le document.
  2. Système de certifications de données comportant au moins un terminal utilisateur (200), au moins un système certificateur, et un module de traitement d’instance selon la revendication précédente.
  3. Procédé de certifications de données mis en œuvre dans un système de certifications de données selon la revendication précédente, comportant une étape de vérification de l’intégrité d’un fichier par un terminal utilisateur, ledit fichier étant reçu d’un autre terminal utilisateur, ladite étape comportant les étapes suivantes, mises en œuvre au niveau du terminal utilisateur :
    1. calculer un condensat du fichier reçu,
    2. recevoir de l’autre terminal utilisateur une adresse de stockage d’une instance certifiante,
    3. générer une requête de réception d’instance certifiante à partir de ladite adresse de stockage et l’envoyer au module (1),
    4. recevoir du module (1) l’instance certifiante associée à ladite adresse de stockage,
    5. parcourir la liste ordonnées d’éléments de l’instance certifiante reçue pour déterminer la présence ou l’absence d’un condensat d’un attestation qui soit le même que le condensat calculé
FR2201791A 2022-03-01 2022-03-01 Certification de données multi-facteurs Pending FR3133244A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2201791A FR3133244A1 (fr) 2022-03-01 2022-03-01 Certification de données multi-facteurs
PCT/EP2023/055078 WO2023166009A1 (fr) 2022-03-01 2023-03-01 Certification de données multi-facteurs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2201791 2022-03-01
FR2201791A FR3133244A1 (fr) 2022-03-01 2022-03-01 Certification de données multi-facteurs

Publications (1)

Publication Number Publication Date
FR3133244A1 true FR3133244A1 (fr) 2023-09-08

Family

ID=82781114

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2201791A Pending FR3133244A1 (fr) 2022-03-01 2022-03-01 Certification de données multi-facteurs

Country Status (2)

Country Link
FR (1) FR3133244A1 (fr)
WO (1) WO2023166009A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10476666B2 (en) * 2017-09-08 2019-11-12 FTR Labs Pty Ltd Method and system for verifying a recording
US20200259653A1 (en) * 2019-02-13 2020-08-13 Merck Patent Gmbh Methods and systems for token-based anchoring of a physical object in a distributed ledger environment
US10911243B1 (en) * 2018-12-14 2021-02-02 Wells Fargo Bank, N.A. Time-based digital signature

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10476666B2 (en) * 2017-09-08 2019-11-12 FTR Labs Pty Ltd Method and system for verifying a recording
US10911243B1 (en) * 2018-12-14 2021-02-02 Wells Fargo Bank, N.A. Time-based digital signature
US20200259653A1 (en) * 2019-02-13 2020-08-13 Merck Patent Gmbh Methods and systems for token-based anchoring of a physical object in a distributed ledger environment

Also Published As

Publication number Publication date
WO2023166009A1 (fr) 2023-09-07

Similar Documents

Publication Publication Date Title
US11151236B2 (en) File verification database system
US8656166B2 (en) Storage and authentication of data transactions
WO2019101227A2 (fr) Système et procédé de mise en œuvre de certificats numériques basés sur une chaîne de blocs
US11025430B2 (en) File provenance database system
US20110231645A1 (en) System and method to validate and authenticate digital data
US20210135880A1 (en) System and method for generating digital marks
US11139960B2 (en) File redaction database system
EP3543891B1 (fr) Procédé mis en oeuvre par ordinateur et système de suivi du cycle de vie de documents certifiés et ses programmes informatiques
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é
US20220329446A1 (en) Enhanced asset management using an electronic ledger
US20230066630A1 (en) System and method for ensuring document integrity with non-fungible tokens
US8799675B2 (en) System and method for electronic certification and authentication of data
US20210037009A1 (en) Biometric data sub-sampling during decentralized biometric authentication
US20200412541A1 (en) Authentication ledger interactions for decentralized biometric authentication
US20210044429A1 (en) Biometric data protection during decentralized biometric authentication
US10700877B2 (en) Authentication of a new device by a trusted device
JP2023098847A (ja) 装置、方法、コンピュータプログラム（プライバシー保護ブロックチェーンの選択的監査プロセス）
FR3133244A1 (fr) Certification de données multi-facteurs
CN112115101B (zh) 一种云存储中数据的确定性删除方法及系统
CN112884484A (zh) 基于区块链的企业身份认证方法及系统
Lewison et al. Rich credentials for remote identity proofing
US20230237200A1 (en) Digital witness systems and methods for authenticating and confirming the integrity of a digital artifact
CN117544351A (zh) 区块链数据处理方法、装置、设备及存储介质
JP2024503173A (ja) デジタルメディアを登録し、デジタルメディアの登録を検証する方法及びシステム
JP2005039337A (ja) 電子文書保護システム

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20230908

PLFP Fee payment

Year of fee payment: 3