FR3098947A1 - Procédé de traitement d’une transaction émise depuis une entité de preuve - Google Patents

Procédé de traitement d’une transaction émise depuis une entité de preuve Download PDF

Info

Publication number
FR3098947A1
FR3098947A1 FR1908239A FR1908239A FR3098947A1 FR 3098947 A1 FR3098947 A1 FR 3098947A1 FR 1908239 A FR1908239 A FR 1908239A FR 1908239 A FR1908239 A FR 1908239A FR 3098947 A1 FR3098947 A1 FR 3098947A1
Authority
FR
France
Prior art keywords
entity
proof
data
candidate
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1908239A
Other languages
English (en)
Other versions
FR3098947B1 (fr
Inventor
Aghiles ADJAZ
Sébastien BAHLOUL
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.)
Idemia Identity and Security France SAS
Original Assignee
Idemia Identity and Security France SAS
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 Idemia Identity and Security France SAS filed Critical Idemia Identity and Security France SAS
Priority to FR1908239A priority Critical patent/FR3098947B1/fr
Priority to US16/918,052 priority patent/US11810110B2/en
Publication of FR3098947A1 publication Critical patent/FR3098947A1/fr
Application granted granted Critical
Publication of FR3098947B1 publication Critical patent/FR3098947B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • 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
    • 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • 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/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/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/3247—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 digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication
    • 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/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Collating Specific Patterns (AREA)

Abstract

La présente invention concerne un procédé de traitement d’une transaction émise depuis une entité de preuve (1) connectée à une entité de vérification (2) ; l’entité de preuve (1) disposant au moins d’une clé secrète et d’une donnée d’authentification candidate, l’entité de vérification (2) disposant de l’empreinte cryptographique d’une donnée d’authentification de référence ; le procédé comprenant des étapes de : (a) génération par les moyens de traitement de données (11) de l’entité de preuve (1) de : une signature de l’entité de preuve (1) à partir de ladite clé secrète ; une preuve à divulgation nulle de connaissances du fait que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident ; (b) transmission à l’entité de vérification (2) de données de transaction comprenant au moins : ladite signature de l’entité de preuve (1) ; ladite preuve à divulgation nulle de connaissance ; (c) vérification par les moyens de traitement de données (21) de l’entité de vérification (2) que ladite signature de l’entité de preuve (1) et la preuve à divulgation nulle de connaissance sont valides ; (d) traitement de ladite transaction. Figure pour l’abrégé : Fig. 1a

Description

Procédé de traitement d’une transaction émise depuis une entité de preuve
La présente invention concerne un procédé de traitement d’une transaction émise depuis une entité de preuve, en particulier dans une base de données de type « chaîne de blocs ».
Sont apparues ces dernières années des bases de données appelées « chaines de blocs » (en anglais, « blockchain »).
Une base de données de type chaîne de blocs est distribuée entre plusieurs nœuds de stockage d’un réseau. Les nœuds de stockage sont configurés pour valider des données écrites dans la base de données par la mise en œuvre d’une méthode de recherche de consensus entre les nœuds de stockage. Une telle méthode est par exemple la méthode connue de « preuve de travail » (« proof of work » en anglais, ou simplement POW). Le contenu de la base de données est ainsi protégé contre des falsifications et ce malgré son caractère distribué.
La plus célèbre base de données de type « chaine de blocs » est celle utilisée dans le système de transaction de monnaie électronique Bitcoin®. La base de données du système Bitcoin® contient un historique de toutes les transactions passées effectuées entre des comptes d’utilisateurs du système. La nécessité d’avoir recours à une entité centralisée telle qu’une banque pour authentifier des transactions est ainsi supprimée.
On appelle « wallet » (en français portefeuille) un élément client stockant une clé privée d’un utilisateur et permettant d’effectuer des transactions sur la base de données de type « chaîne de blocs ». Si la plupart des wallets sont des logiciels clients installés sur un terminal personnel (ordinateur, smartphone) ou un serveur distant, certains wallets dits « hardware wallet » (en français portefeuille physique) prennent la forme d’un objet matériel tel qu’un token usb stockant la clé de manière autonome (et séparée du réseau) pour apporter un niveau de sécurité supérieur.
Actuellement les transactions sur une chaîne de blocs mais également celles utilisant un moyen de paiement électronique de type carte bancaire sont vérifiées en se basant sur un seul facteur d’authentification de type « quelque chose que l’utilisateur possède », en particulier ladite clé privée (stockée dans son « wallet »/sur la puce de sa carte bancaire/dans une enclave sécurisée d’un terminal personnel, etc.). Cela signifie qu’un attaquant qui arrive à récupérer une telle clé secrète d’un utilisateur peut très facilement usurper l’identité de ce dernier et effectuer des transactions à son insu.
Il serait souhaitable d’utiliser à la place des procédés d’authentification forte (i.e. à plusieurs facteurs d’authentification) très robustes, notamment tels que définis par les spécifications de l’alliance FIDO.
Par exemple, on combine le premier facteur d’authentification possédé par l’utilisateur, dit authentificateur, et quelque chose que l’utilisateur « sait » ou « est » (un code, un trait biométrique, etc.).
Il est connu de mettre en œuvre la transaction depuis un terminal mobile tel qu’un smartphone stockant ladite clé secrète (on connait ainsi des services de paiement mobile pour iOS ou Android - aussi bien des wallets de nombreuses blockchains, que des cartes bancaires dématérialisées) autorisant la transaction si une authentification supplémentaire sur le terminal mobile est réalisée avec succès : typiquement l’utilisateur doit saisir un code PIN ou présenter un trait biométrique (visage ou empreinte digitale) au smartphone.
Ainsi, une vraie authentification biométrique est accomplie car on combine « quelque chose que l’individu possède », i.e. son terminal mobile, et « quelque chose que l’individu est/sait » en tant que deuxième facteur.
Cependant, cela suppose que ledit terminal mobile est de confiance : le reste du système de transaction n’a pas l’assurance que la vérification du deuxième facteur a été effectuée de manière fiable et doit lui faire confiance, or le terminal de l’utilisateur pourrait avoir été piraté.
Il serait ainsi souhaitable de permettre une nouvelle solution d’authentification forte d’un utilisateur cherchant à mettre un œuvre une transaction, qui soit universelle, fiable et facile à mettre en œuvre.
La présente invention se rapporte ainsi selon un premier aspect à un procédé de traitement d’une transaction émise depuis une entité de preuve connectée à une entité de vérification ;
l’entité de preuve disposant au moins d’une clé secrète et d’une donnée d’authentification candidate, l’entité de vérification disposant de l’empreinte cryptographique d’une donnée d’authentification de référence ;
le procédé comprenant des étapes de :
(a) génération par les moyens de traitement de données de l’entité de preuve de :
- une signature de l’entité de preuve à partir de ladite clé secrète ;
- une preuve à divulgation nulle de connaissances du fait que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident ;
(b) transmission à l’entité de vérification de données de transaction comprenant au moins :
- ladite signature de l’entité de preuve ;
- ladite preuve à divulgation nulle de connaissance ;
(c) vérification par les moyens de traitement de données de l’entité de vérification que ladite signature de l’entité de preuve et la preuve à divulgation nulle de connaissance sont valides ;
(d) traitement de ladite transaction.
Selon d’autres caractéristiques avantageuses et non-limitatives :
L’entité de preuve dispose en outre de la donnée d’authentification de référence et/ou d’une empreinte cryptographique de la donnée d’authentification de référence, lesdites données de transaction transmises à l’étape (b) comprenant en outre ladite empreinte cryptographique de la donnée d’authentification de référence, et l’étape (c) comprenant la vérification par les moyens de traitement de données de l’entité de vérification que l’empreinte cryptographique reçue de la donnée d’authentification de référence correspond à celle dont dispose l’entité de vérification.
L’entité de preuve ne dispose initialement que de la donnée d’authentification de référence et/ou de l’empreinte cryptographique de la donnée biométrique de référence, le procédé comprenant la mise en œuvre par des moyens de traitement de données d’une entité de confiance ou de l’entité de preuve d’une étape préalable (a1) de :
- Obtention de la donnée d’authentification candidate ;
- génération de l’empreinte cryptographique de la donnée d’authentification candidate obtenue.
Le procédé comprend une étape encore antérieure (a0) de génération par les moyens de traitement de données de l’entité de preuve de la donnée biométrique de référence à partir d’un trait biométrique de référence associé à un document officiel ; et de l’empreinte cryptographique de la donnée biométrique de référence.
La preuve à divulgation nulle de connaissances est un objet cryptographique de type zkSNARK.
L’étape (a) comprend la vérification préalable que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident.
Les données d’authentification candidate et de référence sont des données biométriques candidate et de référence, l’entité de preuve disposant en outre de la donnée biométrique de référence, d’une empreinte cryptographique de la donnée biométrique candidate et de l’empreinte cryptographique de la donnée biométrique de référence, lesdites données de transaction transmises à l’étape (b) comprenant en outre ladite empreinte cryptographique de la donnée biométrique candidate.
La donnée biométrique candidate et la donnée biométrique de référence coïncident si leur distance selon une fonction de comparaison donnée est inférieure à un seuil prédéterminé.
Ladite preuve à divulgation nulle de connaissances du fait que la donnée biométrique candidate et la donnée biométrique de référence coïncident est une preuve à divulgation nulle de connaissances du fait qu’étant données deux empreintes cryptographiques, il existe une donnée biométrique candidate et une donnée biométrique de référence ayant pour empreintes cryptographiques respectives les empreintes cryptographiques données, telles que leur distance selon la fonction de comparaison donnée est inférieure au seuil prédéterminé.
Les données d’authentification candidate et de référence sont un code candidat et un code de référence, le code candidat et le code de référence coïncidant si leurs empreintes cryptographiques correspondent.
Ladite preuve à divulgation nulle de connaissances du fait que le code candidat et le code de référence coïncident est une preuve à divulgation nulle de connaissances du fait qu’étant donnée une empreinte cryptographique, il existe un code candidat ayant pour empreinte cryptographique une empreinte cryptographique du code candidat correspondant à ladite empreinte cryptographique donnée.
L’entité de preuve est un dispositif électronique personnel à un utilisateur de type carte bancaire, terminal mobile ou ordinateur personnel.
Ladite transaction est dans une base de données de type chaîne de blocs, l’étape (d) comprenant la génération d’un bloc contenant lesdites données de transaction transmise à l’étape (b) et son ajout dans ladite base de données de type chaîne de blocs
Selon un deuxième aspect, l’invention concerne un ensemble de traitement d’une transaction émise depuis une entité de preuve disposant au moins d’une clé secrète, comprenant ladite entité de preuve et une entité de vérification connectées, caractérisé en ce que :
l’entité de preuve comprend des moyens de traitement de données configurés pour générer une signature de l’entité de preuve à partir de ladite clé secrète et une preuve à divulgation nulle de connaissances du fait qu’une donnée d’authentification candidate et une donnée d’authentification de référence coïncident, et transmettre à l’entité de vérification des données de transaction comprenant au moins ladite signature de l’entité de preuve et ladite preuve à divulgation nulle de connaissance ;
l’entité de vérification comprend des moyens de traitement de données configurés pour vérifier que ladite signature de l’entité de preuve et la preuve à divulgation nulle de connaissance sont valides.
Selon un troisième et un quatrième aspect, l’invention concerne un programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon le premier aspect de traitement d’une transaction émise depuis une entité de preuve ; et un moyen de stockage lisible par un équipement informatique sur lequel un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon le premier aspect de traitement d’une transaction émise depuis une entité de preuve.
D’autres caractéristiques, buts et avantages de l’invention ressortiront de la description qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels :
La figure 1a représente de manière schématique un système de traitement d’une transaction, selon un premier mode de réalisation.
La figure 1b représente de manière schématique un système de traitement d’une transaction, selon un deuxième mode de réalisation.
La figure 1c représente de manière schématique un système de traitement d’une transaction, selon un troisième mode de réalisation.
La figure 2 est un organigramme d’étapes d’un procédé de traitement d’une transaction mis en œuvre dans un système représenté en l’une des figure 1a, 1b, 1c.
Sur l’ensemble des figures, les éléments similaires portent des références identiques.
Architecture
En référence auxfigures 1a, 1b, 1c, on a représenté schématiquement trois cas de systèmes de transaction pour la mise en œuvre du présent procédé de traitement d’une transaction avec authentification forte. Dans la suite de la transaction, on prendra l’exemple de trois contextes différents, correspondant respectivement aux figures 1a, 1b, 1c :
- Transaction sur une base de données de type chaîne de blocs (par exemple transfert de bitcoins) ;
- Transaction de type paiement par carte bancaire chez un marchand (dit « schéma EMV », pour Europay Mastercard Visa) ;
- Transaction de type paiement en ligne par carte bancaire.
Dans tous les cas le système comprend au moins deux équipements 1, 2. Le premier équipement 1 est avantageusement un équipement personnel à un individu, comme par exemple son téléphone mobile, ou « smartphone », une tablette électronique ou encore un ordinateur personnel, voire directement sa carte bancaire, et de façon générale un équipement client via lequel l’utilisateur souhaite effectuer la transaction (comme expliqué, appelé wallet dans un système à chaine de blocs). Dans tous les cas, le premier équipement 1 détient un secret de type clé secrète (on reviendra là-dessus plus loin).
Le deuxième équipement 2 est détenu et contrôlé par une entité auprès de qui l’authentification doit être effectuée.
Dans le cas d’une transaction sur une base de données de type chaîne de blocs, le deuxième équipement 2 est un dispositif valideur de transaction dit « nœud de la chaine de blocs » et notamment un « mineur » ou un autre wallet. Dans le cas d’une transaction par carte bancaire, il s’agit généralement d’un serveur marchand ou un serveur bancaire destiné à autoriser ou non une transaction bancaire.
L’un des équipements met en œuvre une authentification de l’utilisateur, et fournit ensuite le résultat à l’autre, qui procède à la vérification de ce résultat. A ce titre, selon un schéma connu, le premier équipement 1 est une entité, dite de preuve, qui met en œuvre l’authentification et fournit le résultat au deuxième équipement 2 qui vérifie ce résultat, dit entité de vérification.
Le premier équipement 1 comporte des moyens de traitement de données 11, i.e. un calculateur tel que par exemple un processeur, un microprocesseur, un contrôleur, un microcontrôleur, un FPGA etc. Ce calculateur est adapté pour exécuter des instructions de code pour mettre en œuvre le procédé ci-après.
Le premier équipement 1 comprend avantageusement une interface de communication lui permettant de dialoguer à distance avec le deuxième équipement 2 et d’autres éventuels équipements tel qu’un troisième équipement 3 qui est entité dite de confiance (fourni par un tiers reconnu par l’entité auprès de qui la transaction doit être mise en œuvre, par exemple un fournisseur de solution de sécurité), et/ou un quatrième équipement 4 qui est une entité dite d’autorité (par exemple gouvernementale). A noter que l’entité de vérification 2 et l’entité d’autorité 4 peuvent être confondues.
Le premier équipement peut également comprendre des moyens de stockage de données 12 (une mémoire, par exemple flash) une interface utilisateur 13 (typiquement un écran tactile), et éventuellement des moyens d’acquisition biométrique 14 (voir plus loin).
Cette interface de communication est de préférence la combinaison d’une interface de communication sans fil, par exemple de type Wifi ou Bluetooth ou réseau de téléphonie mobile (GPRS, 3G, 4G ou autre) et de tout autre réseau de communication aval.
Le deuxième équipement 2 (et le cas échéant le troisième et/ou le quatrième équipement(s) 3, 4) comporte quant à lui également des moyens de traitement de données 21 (respectivement 31, 41), i.e. un calculateur tel que par exemple un processeur, un microprocesseur, un contrôleur, un microcontrôleur, un FPGA etc. Ce calculateur est adapté pour exécuter des instructions de code pour mettre en œuvre le procédé ci-après.
Ces autres équipements 2, 3, 4 comprennent avantageusement eux aussi des interfaces de communication leur permettant de dialoguer à distance entre eux et avec le premier équipement 1.
Le deuxième équipement 2 et l’éventuel troisième équipement 3 sont typiquement disposés à proximité (par exemple tous les deux chez un marchand dans le schéma EMV, on verra plus loin des architectures possibles), et peuvent être à ce titre connectés filialement. Le quatrième équipement 4 est quant à lui typiquement un équipement distant.
De façon préférée, le premier équipement 1 et/ou l’éventuel troisième équipement 3 sont capables de générer une donnée biométrique à partir d’un trait biométrique d’un individu. Le trait biométrique peut par exemple être la forme du visage, ou un ou plusieurs iris de l’individu. L’extraction de la donnée biométrique est mise en œuvre par un traitement de l’image du trait biométrique qui dépend de la nature du trait biométrique. Des traitements d’images variés pour extraire des données biométriques sont connus de l’Homme du Métier. A titre d’exemple non limitatif, l’extraction de la donnée biométrique peut comprendre une extraction de points particuliers ou d’une forme du visage dans le cas où l’image est une image du visage de l’individu
Le troisième équipement 3 et/ou éventuellement le premier équipement 1 comprennent à ce titre des moyens d’acquisition biométrique 14, 34, typiquement un capteur d’image, par exemple un appareil photographique numérique ou une caméra numérique, adapté pour acquérir au moins une image d’un trait biométrique d’un individu.
Transactions
On suppose que la transaction est émise depuis l’entité de preuve 1. Dans tous les cas, on suppose que l’entité de preuve 1 dispose d’une clé secrète, qui classiquement lui permet de signer des données descriptives de la transaction. Plus précisément, les moyens de traitement de données 11 de l’entité de preuve peuvent dans la première étape (a) du procédé générer une signature de l’entité de preuve 1 à partir de ladite clé secrète, cette signature constituant un premier facteur d’authentification du type « ce que je possède ».
Selon un premier mode de réalisation illustré par la figure 1a, ladite transaction est sur une base de données de type chaîne de blocs (par exemple transfert de bitcoins).
On suppose qu’un compte d’accès en lecture et en écriture dans la base de données de type chaîne de blocs a été créé pour l’utilisateur de l’entité de preuve 1. La création du compte comprend l’attribution à l’utilisateur des deux clés mutuellement associées évoquées précédemment : une clé privée de signature, propre à l’utilisateur et une clé publique de vérification de signature également propre à l’utilisateur.
Les deux clés de l’utilisateur sont mémorisées dans une mémoire 12 de l’entité de preuve 1 sur commande de l’utilisateur, et/ou prédéterminées.
Toute donnée écrite dans la base de données à la demande d’une entité titulaire d’un compte d’accès à la base de données peut être signée avant son écriture au moyen de la clé privée propre à cette entité. Inversement, toute donnée signée lue dans la base de données par un tiers titulaire d’un compte d’accès à la base de données peut être vérifiée au moyen de la clé publique propre à l’entité, de sorte à obtenir la donnée originellement fournie par l’entité.
Ladite signature, notée ScriptSig pour Bitcoin, est par exemple effectuée en utilisant la cryptographie à courbes elliptiques, dite ECDSA. En l'occurrence, la courbe employée dans le système Bitcoin est secp256k1.
De manière générale, toute transaction sur une base de données de type chaîne de blocs est définie par un ensemble de données descriptives de la transaction, comprenant au moins une indication d’un montant de la transaction et une « sortie », c’est-à-dire la clé publique, ou du moins l’empreinte cryptographique de cette clé publique, notée scriptPubKey pour Bitcoin, du bénéficiaire (celui qui reçoit un certain montant d’une unité monétaire tel que des Bitcoin). Il peut y avoir plusieurs sorties, chacune associée à un montant.
Avantageusement, les données descriptives d’une transaction incluent en outre une « entrée », c’est à dire l’identifiant, noté previous tx pour bitcoin, d’une ou plusieurs transactions précédentes (i.e. dont le bénéficiaire est l’émetteur de la présente transaction) dont le montant de sortie est suffisant pour couvrir la transaction, i.e. justifiant la disponibilité des fonds objet de la transaction. Une transaction équilibre toujours ses entrées et ses sorties.
Il est alors facile de vérifier pour l’émetteur :
- qu’il possède la clé publique se hachant en l’empreinte cryptographique renseignée dans la sortie de ladite transaction précédente, et
- que sa signature correspond à cette clé publique (et donc qu’il possède bien la clé privée correspondante).
Par « empreinte cryptographique » d’une donnée (appelé également « condensat » ou « haché » de la donnée, de l’anglais « hash »), obtenue en appliquant une fonction de hachage cryptographique à la donnée (typiquement des familles SHA-1 ou SHA-2, en particulier SHA-256). L’empreinte a une taille fixe et ne révèle rien sur la donnée dont elle est issue : on ne peut pas retrouver la donnée d’origine à partir de cette empreinte, en tout cas tant que la fonction de hachage utilisée est considérée comme sûre. On peut cependant recalculer l’empreinte à partir de la donnée pour vérifier qu’elle est correcte.
Selon un deuxième mode de réalisation illustré par la figure 1b, la transaction est de type paiement par carte bancaire chez un marchand, i.e. une carte bancaire ou un terminal mobile émulant une carte bancaire est connecté à un terminal de paiement électronique (TPE) du marchand de type EFTPOS (Electronic funds transfer at point of sale). Cette connexion est de plus en plus souvent sans-contact (NFC), mais elle peut toujours être par insertion de la carte dans un lecteur.
Dans cette configuration, la carte/terminal mobile est l’entité de preuve 1, le TPE peut être est éventuellement une entité de confiance 3, et un serveur distant d’un organisme bancaire est l’entité de vérification 2. L’entité de preuve 1 est typiquement reliée à l’entité de vérification 2 via ladite entité de confiance 3.
Cette fois on utilise plutôt un chiffrement symétrique, c’est-à-dire qu’une clé privée est associé à la carte bancaire (physique ou dématérialisée), la clé privée étant d’une part stockée directement sur la puce de la carte si elle est physique ou dans une mémoire du terminal si elle est dématérialisée, et d’autre part stockée par le serveur bancaire. De manière classique, des données descriptives de la transaction sont saisies par le marchand sur le TPE, et envoyées à la carte/terminal pour être apposition de ladite signature en fonction de la clé secrète. De la même manière que pour les chaînes de blocs, un serveur distant bancaire pourra vérifier que cette signature est valide, et autoriser la transaction. Une chiffrement asymétrique (une clé privée et une clé publique) peut être utilisé de la même manière que dans le précédent mode de réalisation pour assurer le TPE que la carte utilisée est authentique et que ce n’est pas une copie.
Selon un troisième mode de réalisation illustré par la figure 1c, la transaction est de type paiement en ligne. Généralement, l’entité de preuve 1 est alors un terminal tel qu’un terminal mobile un ordinateur sur lequel l’utilisateur saisit le numéro de sa carte et/ou le cryptogramme visuel associé et/ou la date d’expiration de la carte, mais ce pourrait être directement la carte si elle dispose d’une connectivité réseau. Le serveur distant d’un marchand est l’entité de vérification 2.
Dans un tel cas, la clé secrète est constituée du n-uplet (préférablement le triplet) numéro de sa carte (dit « PAN ») et/ou le cryptogramme visuel associé (dit « CCV », CVC » ou « CVV ») et/ou la date d’expiration de la carte, qui constitue bien un facteur d’authentification du type « ce que je possède », la signature associée étant une empreinte cryptographique fonction desdits numéro de sa carte et/ou cryptogramme visuel associé et/ou date d’expiration de la carte. Cette empreinte cryptographique peut facilement être vérifiée par ledit serveur distant (soit par une fonction dédiée, soit en soumettant cette empreinte cryptographique à un serveur bancaire apte à la recalculer. Généralement, la banque vérifie à partir du numéro de carte et de la date de validité que le cryptogramme visuel reçu est bon).
Authentification forte
La présente invention vise à ajouter un deuxième facteur d’authentification (« ce que je sais » ou « ce que je suis ») au moment de l’initiation d’une transaction, tout en déportant une partie de la vérification.
Ainsi l’équipement 1 met en œuvre une authentification de l’individu, c’est-à-dire compare une donnée d’authentification dite candidate, car fraîchement acquise, à une donnée d’authentification de référence, c’est-à-dire attendue. Par donnée d’authentification, on entend toute donnée permettant d’identifier de manière discriminante un individu.
Selon une première variante, ladite donnée d’authentification est un code, par exemple un code PIN (par code on entend un mot de passe, c’est-à-dire une série de caractères tenue secrète). Alors, la donnée d’authentification de référence est un code de référence, i.e. un code attendu, et la donnée d’authentification est un code candidat, i.e. un code saisi par l’utilisateur qui va être vérifié.
Selon une deuxième variante, ladite donnée d’authentification est une donnée biométrique, de sorte qu’on compare une donnée biométrique dite candidate, car fraichement acquise sur l’individu, à une seule biométrique dite de référence, censée provenir du même individu, afin de vérifier que l’individu à partir duquel ont été obtenues les deux données est bien le même.
Dans ce cas, la donnée biométrique de référence utilisée pour l’authentification est avantageusement une donnée enregistrée dans un document d’identité de l’individu. Par exemple, la donnée biométrique peut être une image du visage figurant sur un document d’identité, ou encore une image du visage ou d’au moins un iris de l’individu enregistré dans une puce radiofréquence contenue dans le document.
Enrôlement
Comme expliqué, le présent procédé vise à ce que l’entité de vérification 2 n’ait besoin que de se voir présenter une preuve de l’authentification de l’individu, mais pas de données d’authentification. On comprend donc que l’entité de vérification 2 peut s’assurer « de ses propres yeux » de la réalité des deux facteurs d’authentification (i.e. du caractère fort de cet authentification), sans pour autant risque de compromettre les données d’authentification de l’utilisateur.
Ainsi, le prédicat de base est qu’au lancement du procédé l’entité de preuve 1 dispose d’une donnée d’authentification candidate, et d’une donnée d’authentification de référence et/ou d’une empreinte cryptographique de la donnée d’authentification de référence. L’entité de vérification 2 n’a besoin de disposer que de l’empreinte cryptographique de la donnée d’authentification de référence et/ou de l’empreinte cryptographique de la donnée d’authentification candidate.
Dans le cas de données biométriques, l’entité de preuve 1 dispose plus précisément de la donnée d’authentification candidate, d’une donnée biométrique de référence, d’une empreinte cryptographique de la donnée biométrique de référence, d’une empreinte cryptographique de la donnée biométrique candidate.
Comme expliqué l’empreinte cryptographique d’une donnée d’authentification peut ainsi être transmise à tout équipement sans dévoiler d’information sur la donnée en elle-même et donc sur la vie privée de l’utilisateur.
Dans un mode de réalisation préféré, en référence à lafigure 2, le procédé comprend une étape préalable (a0) « d’enrôlement » permettant la mise à disposition de la donnée d’authentification de référence (ou l’empreinte cryptographique de la donnée d’authentification de référence) sur l’entité de preuve 1. Cette étape peut être mise en œuvre longtemps avant le reste du procédé, et ne nécessite pas d’être réitérée à chaque occurrence du procédé (on peut par exemple prévoir une fois par an).
Typiquement, cette étape comprend :
- l’obtention par l’entité de preuve 1 de la donnée d’authentification de référence, i.e. dans le cas de données biométriques, la génération par les moyens de traitement de données 11 de l’entité de preuve 1 de la donnée biométrique de référence à partir d’un trait biométrique de référence associé à un document officiel (en particulier un document d’identité tel qu’un passeport ou une carte d’identité), ou dans le cas d’un code de référence celui-ci est généralement prédéterminé (typiquement, l’utilisateur reçoit sa carte bancaire avec son code) ; et/ou
- l’obtention par l’entité de preuve 1 de l’empreinte cryptographique de cette donnée d’authentification de référence (toujours par application d’une fonction de hachage donnée).
On comprend que l’entité de preuve 1 peut au final disposer de la donnée d’authentification de référence et/ou de son empreinte cryptographique. Par exemple, si la donnée d’authentification est un code, il suffit que l’entité de preuve 1 dispose de l’empreinte cryptographique du code de référence, alors que si c’est une donnée biométrique elle a besoin de la donnée de référence « non hachée ».
Cette étape (a0) peut être gérée par l’éventuelle entité d’autorité 4, qui peut générer ou valider la donnée d’authentification de référence, et transmettre à l’entité de vérification 2 l’empreinte cryptographique de cette donnée d’authentification de référence. Dans le mode de réalisation chaîne de blocs, on comprend que ladite empreinte cryptographique de la donnée biométrique de référence peut être stockée (en particulier par l’entité de preuve 1 elle-même) dans la chaîne de blocs, de sorte à être publiquement disponible y compris par l’entité de vérification 2.
A titre d’exemple, pour une donnée biométrique, l’utilisateur peut directement récupérer sur son terminal 1 le trait biométrique enregistré dans une puce radiofréquence contenue dans le document (si l’équipement 1 dispose d’un lecteur radiofréquence de type NFC), prendre une photographie de ce document avec ses moyens 14, ou encore une photographie de lui-même, le cas échéant en présence d’un représentant de l’autorité (par exemple à un guichet en mairie), puis faire valider par l’entité d’autorité 4 la donnée biométrique générée en tant que donnée de référence.
Ainsi, l’étape (a0) comprend préférentiellement la transmission à l’entité d’autorité 4 du document officiel (ou tout du moins d’une photographie), de la donnée biométrique de référence, et de l’empreinte cryptographique de la donnée biométrique de référence, et après vérification, la fourniture à l’entité de vérification de l’empreinte cryptographique de la donnée biométrique de référence à l’entité de vérification 2.
Cette vérification peut être faite de nombreuses façons, et consiste simplement à vérifier que la donnée biométrique de référence soumise à vérification est bien cohérente avec le document officiel, et que l’empreinte est bien celle de la donnée soumise.
De façon générale, on comprendra que l’étape (a0) pourra être mise en œuvre de n’importe quelle façon permettant de façon sécurisée de fournir au premier équipement 1 la donnée biométrique de référence signée par une autorité par exemple gouvernementale ou bancaire.
A noter que cette étape (a0) peut comprendre par ailleurs la génération et la fourniture à l’entité de preuve de ladite clé secrète, i.e. être par exemple être mise en œuvre à la commande de sa carte bancaire ou à l’ouverture de son compte auprès de la base de données de type chaîne de blocs.
Obtention de la donnée d’authentification candidate
On suppose comme expliqué que l’entité de preuve 1 dispose d’une part d’une donnée d’authentification candidate, et d’autre part d’une donnée d’authentification de référence et/ou d’une empreinte cryptographique de la donnée biométrique de référence. Comme expliqué, ces deux dernières peuvent être obtenues préalablement lors d’une étape (a0) d’enrôlement.
En ce qui concerne la donnée d’authentification candidate, « fraîche », celle-ci peut être obtenue lors d’une étape préalable (a1). En d’autres termes, l’entité de preuve 1 peut ne disposer initialement (i.e. à l’issue de l’étape (a0)) que de la donnée d’authentification de référence et/ou de l’empreinte cryptographique de la donnée d’authentification de référence.
Il est important de comprendre que si l’étape d’enrôlement (a0) peut être mise en œuvre des semaines avant la mise en œuvre de l’authentification, l’étape (a1) est au pire mise en œuvre quelques minutes avant le reste du procédé, pour garantir la « fraicheur » de la donnée d’authentification candidate.
L’étape (a1) est mise en œuvre par les moyens de traitement de données 11, 31 de l’entité de preuve 1 ou bien de l’éventuelle entité de confiance 3.
En effet, l’entité de preuve 1 n’a pas nécessairement de moyens d’acquisition 13, 14 de la donnée d’authentification candidate (cas de la carte bancaire par exemple). A ce titre, l’entité de confiance 3 pourra être un TPE comprenant un clavier 33 pour la saisie d’un code, voire un dispositif automatique fourni par les autorités de contrôle (et disposé par exemple à côté du TPE) équipé de ses propres moyens d’acquisition biométrique 34 tel qu’un scanner d’empreintes digitales ou une caméra. Alternativement un ordinateur utilisé comme wallet ou un terminal mobile utilisé comme carte bancaire dématérialisée a généralement sa propre interface 13 et ses propres moyens d’acquisition biométrique 14.
L’étape (a1) comprend tout d’abord l’obtention de la donnée d’authentification candidate, puis la génération de l’empreinte cryptographique de la donnée d’authentification candidate obtenue.
Dans le cas biométrique, l’étape (a1) comprend la génération de la donnée biométrique candidate à partir d’un trait biométrique fourni par des moyens d’acquisition biométrique 14, 34 de l’entité de preuve 1 ou l’entité de confiance 3. On note que si l’étape (a1) peut être mise en œuvre par l’entité de preuve 1, i.e. l’utilisateur peut utiliser un trait biométrique fourni par les moyens d’acquisition biométrique 14 de son propre équipement 1, utiliser si possible l’entité de confiance 3 est préféré de sorte à éviter que l’utilisateur « falsifie » la biométrie en mettant par exemple un masque. A ce titre, de façon préférée les moyens d’acquisition biométrique 34 sont capable de détecter le vivant, de sorte à s’assurer que la donnée biométrique candidate est issue d’un trait « réel ».
Enfin s’il y a lieu, l’entité de confiance 3 transmet à l’entité de preuve 1, au moins la donnée biométrique candidate obtenue et optionnellement l’empreinte cryptographique générée de la donnée biométrique candidate (en effet, l’entité de preuve peut elle-même la générer) ; et/ou à l’entité de vérification 2, (seulement) l’empreinte cryptographique générée de la donnée biométrique candidate, à des fins de vérification ultérieure. Par ailleurs il est préférentiellement prévu que la donnée biométrique candidate est effacée de l’entité de confiance 3 une fois transmise à l’entité de preuve 1, par sécurité.
Procédé général
Le présent procédé est non-interactif, c’est-à-dire qu’il ne nécessite qu’un « aller » d’information de l’entité de preuve 1 vers l’entité de vérification 2, et pas de « retour ». Et surtout comme expliqué, l’entité de vérification ne va recevoir ni la donnée d’authentification de référence ni la donnée d’authentification candidate (ni aucune donnée permettant de remonter jusqu’à ces dernières), bien qu’il soit pourtant possible pour l’entité de validation de savoir avec certitude si les données d’authentification candidate et de référence coïncident, et ce sans avoir besoin de faire particulièrement confiance en l’entité de preuve 1.
Pour cela, on utilise un protocole cryptographique générant une « preuve » que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident, cette preuve ne révélant rien d’autre que le fait que ces données biométriques sont bien possédées par le producteur de la preuve.
Le protocole Pinocchio présenté dans la publication « Bryan Parno, Craig Gentry, Jon Howell, and Mariana Raykova, Pinocchio: Nearly Practical Verifiable Computation, in Proceedings of the IEEE Symposium on Security and Privacy, IEEE, 21 May 2013 » a été un des premiers protocoles de calcul vérifiable permettant à l’exécutant de calculer de manière vérifiable l’application d’une fonction quelconque et au donneur d’ordre de vérifier la preuve associée en un temps de calcul inférieur à celui nécessaire pour réaliser le calcul lui-même.
Dans une première étape (a), les moyens de traitement de données 11 de l’entité de preuve 1 génèrent pour cela, outre une signature de l’entité de preuve 1 à partir de ladite clé secrète, d’une preuve à divulgation nulle de connaissances du fait que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident.
Ainsi, on peut lier les deux empreintes cryptographiques aux données d’authentification candidate et de référence mais on ne peut pas obtenir d’informations sur le contenu de ces données d’authentification. Le protocole cryptographique donne une preuve rapide à vérifier (moins d’une demi-seconde) et qu’on ne peut pas falsifier : il est quasi impossible (probabilité inférieure à 1/280, voire inférieur à 1/2128selon les paramètres choisis pour réaliser la preuve, celle-ci étant alors plus lente à réaliser) de faire accepter une preuve de l’affirmation ci-dessus si le processus ne s’est pas déroulé conformément à ce qui est spécifié.
Dans la réalisation de la preuve, l’entité de preuve 1 utilise la possibilité de réaliser des preuves à divulgation nulle de connaissance pour cacher les données d’authentification. Ainsi la preuve ne donne aucune information sur les données d’authentification elles-mêmes.
Naturellement, l’étape (a) comprend avantageusement la vérification préalable que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident (toujours sur l’entité de preuve 1, c’est-à-dire le terminal personnel de l’utilisateur), en comparant la donnée d’authentification candidate et la donnée d’authentification de référence, ou leurs empreintes cryptographique.
En effet, de façon connue,
- un code de référence et un code candidat coïncident si leurs empreintes cryptographiques correspondent, i.e. sont identiques. Cela explique pourquoi il n’est pas nécessaire que l’entité de preuve dispose du code de référence, mais seulement de son empreinte cryptographique. La preuve est alors plus précisément une preuve à divulgation nulle de connaissances du fait qu’étant donnée une empreinte cryptographique (en l’espèce de référence), il existe un code candidat ayant pour empreinte cryptographique une empreinte cryptographique candidate correspondant à ladite empreinte cryptographique donnée (puisque les empreintes cryptographiques des codes candidat et de référence sont identiques). Naturellement, il reste possible de comparer directement le code de référence et le code candidat ;
- une donnée biométrique candidate et une donnée biométrique de référence coïncident si leur distance selon une fonction de comparaison donnée est inférieure à un seuil prédéterminé. Deux données biométriques ne seront jamais exactement identiques de sorte qu’il n’est pour le coups pas possible de comparer directement leurs empreintes cryptographiques.
Ainsi, dans le cas biométrique, la mise en œuvre de la comparaison comprend le calcul d’une distance entre les données, dont la définition varie en fonction de la nature des données biométriques considérées. Le calcul de la distance comprend le calcul d’un polynôme entre les composantes des données biométriques, et avantageusement le calcul d’un produit scalaire.
Par exemple, dans le cas où les données biométriques ont été obtenues à partir d’images d’iris, une distance classiquement utilisée pour comparer deux données est la distance de Hamming. Dans le cas où les données biométriques ont été obtenues à partir d’images du visage d’individu, il est courant d’utiliser la distance euclidienne.
Ce type de comparaison est connu de l’Homme du Métier et ne sera pas décrit plus en détails ci-avant.
L’individu est authentifié si la comparaison révèle un taux de similarité entre la donnée candidate et la donnée de référence excédant un certain seuil, dont la définition dépend de la distance calculée.
La preuve est alors plus précisément une preuve à divulgation nulle de connaissances du fait qu’étant données deux empreintes cryptographiques, il existe une donnée biométrique candidate et une donnée biométrique de référence ayant pour empreintes cryptographiques respectives les empreintes cryptographiques données, telles que leur distance selon la fonction de comparaison donnée est inférieure au seuil prédéterminé.
Génération de preuve
De façon préférée, ladite preuve à divulgation nulle de connaissances est un objet cryptographique de type zkSNARK.
zkSNARK signifie « zero-knowledge Succinct Non Interactive ARgument of Knowledge », i.e. Argument de connaissance non interactive à divulgation nulle de connaissances. Il s’agit d’une primitive cryptographique construite autour de la notion de preuve. Les chercheurs en informatique théorique et en cryptographie se sont intéressés depuis longtemps à la notion de preuve. Il existe des résultats théoriques permettant de produire une preuve très courte et sécurisée d’un algorithme mais le temps pour réaliser cette preuve est hors de portée et le restera malgré l’augmentation de la puissance de calcul des ordinateurs. Une des raisons tient au pouvoir que l’on donne à l’entité qui réalise la preuve, l’entité de preuve 1 (appelée aussi le prouveur). Dans les résultats théoriques sur les preuves, le prouveur a une puissance de calcul infinie et les preuves restent sécurisées malgré cela.
La notion de preuve a ensuite été relâchée, le protocole ne cherchant à se protéger que d’un prouveur qui aurait une puissance de calcul importante mais bornée. Le résultat du protocole n’est plus une preuve mais un argument. C’est à partir de cette notion d’argument que les systèmes pratiques de calcul vérifiables se sont construits. Une exigence supplémentaire dans un système produisant un argument est que cet argument soit non interactif : le vérifieur et le prouveur n’ont pas besoin d’interagir pour produire l’argument.
Depuis 2010, des réalisations de zkSNARKs ont été présentées : il s’agit d’arguments dont la taille est courte (quelques éléments d’une courbe elliptique), qui ne nécessitent pas d’interactivité et qui de plus permettent au prouveur d’effectuer une preuve à divulgation nulle de connaissance i.e. la preuve ne contient aucune information non triviale sur les entrées fournies par le prouveur.
Il existe plusieurs protocoles qui réalisent concrètement des zkSNARKs, et l’homme du métier pourra les utiliser indifféremment dans le présent procédé :
- Le protocole Pinocchio déjà évoqué ;
- Le protocole Gepetto, présenté dans la publication « Craig Costello, Cedric Fournet, Jon Howell, Markulf Kohlweiss, Benjamin Kreuter, Michael Naehrig, Bryan Parno, and Samee Zahur, Geppetto: Versatile Verifiable Computation, in Proceedings of the IEEE Symposium on Security and Privacy, IEEE, 18 May 2015 », qui est une amélioration de Pinocchio
- Le protocole présenté dans la publication et suivantes « Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, Madars Virza. SNARKs for C: Verifying Program Executions Succinctly and in Zero Knowledge. In Proceedings of the 33rd Annual International Cryptology Conference, CRYPTO ’13, pages 90–108, 2013”, implémenté open-source sous la forme d’une librairie appelée libsnark, optimisant le protocole produisant un zkSNARK dans Pinocchio en améliorant l’expressivité, c’est-à-dire le type de programmes ou d’algorithme qu’il est possible de vérifier.
Pour prendre l’exemple du protocole Pinocchio, ce protocole comporte plusieurs parties :
1. Un programme classique est traduit sous la forme d’un circuit arithmétique, c’est-à-dire d’un ensemble de relations entre les entrées et les sorties du programme traduites uniquement à l’aide d’additions et de multiplications d’éléments d’un corps fini. Il faut remarquer que tous les programmes peuvent en théorie être traduits sous cette forme mais qu’une partie seulement de ces programmes admet une traduction efficace sous forme de circuit.
2. Le circuit arithmétique obtenu est représenté efficacement à l’aide de trois familles de polynômes auxquelles s’ajoute un polynôme supplémentaire, appelé polynôme cible. Ces familles de polynômes forment des « Quadratic Arithmetic Programs » (QAPs). Elles encodent les relations entre les entrées et les sorties de chaque porte multiplicative du circuit, les relations des portes additives étant intégrées dans la première porte multiplicative qui suit dans le calcul.
Ces QAPs sont reliés au calcul vérifiable par le point suivant : un calcul y = C(x) est correct pour une entrée x si et seulement si toutes les relations décrivant le circuit arithmétique correspondant sont satisfaites en fixant comme valeur d’entrée x et comme valeur de sortie y.
Les QAPs permettent en quelque sorte de compresser toutes les contraintes à vérifier dans une seule relations à vérifier : un polynôme construit à partir de la valeur x et des trois familles du QAP doit diviser le polynôme cible.
3. Un protocole cryptographique prend alors en entrée un QAP associé à un programme, génère des clés d’évaluation et de vérification qui utilisent des courbes elliptiques pour cacher les relations polynômiales. Le polynôme prouvant que le calcul a été effectué correctement est alors calculé directement à l’aide des relations cachées dans la courbe elliptique. La relation de divisibilité se traduit uniquement à l’aide d’un nombre constant d’éléments de la courbe elliptique, c’est-à-dire que la preuve est de taille constante. La vérification de cette preuve est extrêmement rapide.
Le protocole permet de plus d’obtenir que des entrées du calcul fournies par le prouveur soient privées : il permet de cacher les valeurs du prouveur dans la réalisation de la preuve en les multipliant par un multiple du polynôme cible, ce qui ne modifie pas le fait que le polynôme « preuve » soit divisible par le polynôme cible.
Ce polynôme « preuve », quand il est caché dans une courbe elliptique constitue un zkSNARK.
Le protocole Pinocchio permet à celui qui réalise la preuve de cacher certaines des entrées du calcul dont il fait la preuve. Dans le présent cas, il s’agit de réaliser le calcul suivant :
  • Cas d’un code
Entrée : l’empreinte cryptographiques du code de référence , le résultat de la comparaison de l’empreinte cryptographiques du code de référence et de l’empreinte cryptographiques du code candidat , (i.e. le booléen selon qu’elles coïncident ou non), et un vecteur d’initialisation IV
Entrée privée : le code candidat .
Sortie : la preuve π que le prouveur connaît bien un code candidat qui se hache en et dont le résultat de la comparaison est celui attendu ( .
  • Cas biométrique
Entrée : les empreintes cryptographiques de la donnée biométrique candidate et de référence , le résultat de la comparaison des données biométriques candidate et de référence (i.e. le booléen selon qu’elles coïncident ou non), et un vecteur d’initialisation IV
Entrée privée : les données biométriques candidate et de référence .
Sortie : la preuve π que le prouveur connaît bien des données biométriques et qui se hachent en et et dont le résultat de la comparaison est celui attendu.
A noter que sont connus des protocoles prévus pour la génération d’une preuve de bon déroulement d’une fonction de hachage, que l’homme du métier pourra directement utiliser même s’ils ne sont pas optimaux. La difficulté est d’obtenir un temps de calcul raisonnable pour réaliser la preuve et des tailles de clés d’évaluation et de vérification qui ne sont pas trop conséquentes.
Le protocole Zerocash (IEEE Security & Privacy 2014) de Ben-Sasson et al., propose la définition d’un circuit arithmétique pour vérifier la fonction de compression de SHA-256 qui comporte environ 30 000 portes multiplicatives. Ceci donne un temps de réalisation de preuve d’environ 5 secondes (par niveau de compression, vérifier la fonction de hachage entière qui comprend de nombreuses itérations de la fonction de compression sera nettement plus long), ce qui reste élevé et largement améliorable.
Le protocole ZKBoo, présenté dans la publication « ZKBoo : faster zero-knowledge for boolean circuits » de Giacomelli, Madsen et Orlandi (Usenix Security 2016) » permet de meilleures performances (preuve en 50 ms, vérification en 70 ms) par itération de la fonction de compression, mais la taille de la preuve est conséquente (800 Ko) d’autant plus qu’elle ne semble avoir été mesurée que sur une application de la fonction de compression.
Suite du procédé
Dans une étape (b), l’entité de preuve 1 transmet à l’entité de vérification 2 les données de transaction comprenant au moins :
- ladite signature de l’entité de preuve 1 ;
- ladite preuve à divulgation nulle de connaissance ;
- généralement d’autres données descriptives de la transaction (montant, clé publique de destinataire, etc.).
Il peut également y avoir l’empreinte cryptographique de la donnée d’authentification de référence et/ou l’empreinte cryptographique de la donnée d’authentification candidate, en particulier dans le cas biométrique, et si elles n’ont pas déjà été transmises. On répète que les données d’authentifications ne sont quant à elles pas transmises.
Dans une étape (c), les moyens de traitement de données 21 de l’entité de vérification 2 vérifient que ladite signature de l’entité de preuve 1 est valide, et que la preuve à divulgation nulle de connaissance est valide.
Il peut être également vérifié qu’une empreinte cryptographique reçue de la donnée d’authentification candidate et/ou de référence correspond à celle dont dispose l’entité de vérification 2 (en d’autres termes que la donnée de référence que l’on a utilisée est bien celle prévue, et/ou que la donnée candidate est la donnée fraîche extraite juste avant dans l’étape (a1) dans le cas biométrique).
Si c’est le cas, l’utilisateur est authentifié, et dans une étape (d) la transaction peut être traitée (voir plus loin).
La vérification de la signature de l’entité de preuve 1 est bien connue de l’homme du métier, par exemple en utilisant une clé publique, comme expliqué plus haut. La vérification de la preuve n’est pas interactive (l’entité de vérification 2 n’a pas besoin de contacter le prouveur, i.e. l’entité de preuve 1) et se fait simplement en temps constant en vérifiant que la preuve est valide, ce qui démontre (à une probabilité infime près) à l’entité de vérification 2 que la propriété prétendue est vraie, i.e. que l’utilisateur dispose d’une donnée d’authentification candidate et d’une donnée d’authentification de référence qui coïncident. Il se convainc ainsi que l’identité de l’utilisateur est confirmée (et que personne n’a usurpé une identité) malgré l’absence de donnée d’authentification.
Grâce à la preuve la confidentialité peut être totale (puisque la génération de la preuve ne nécessite pas de communication) sans que l’entité de vérification 2 ne prenne de risque puisque la preuve lui garantit que l’entité de preuve dispose bien des données d’authentification.
La preuve est courte (voir très courte – de l’ordre de quelques centaines d’octets), la transmettre avec les empreintes cryptographiques du document ne pose aucun problème de bande passante. De plus, la vérification de cette preuve est rapide (en temps constant, quelques dizaines de millièmes de secondes), ce qui n’augmente pas la charge de calcul au niveau des moyens de traitement de données 21 de l’entité de vérification 2, qui doit potentiellement gérer des centaines d’authentifications simultanées. La génération de la preuve est quant à elle plus lourde en termes de temps de calcul, mais comme l’étape (a) est mise en œuvre du côté premier équipement 1 qui est personnel (et n’est impliqué que dans l’authentification de son seul propriétaire), ce temps de calcul additionnel n’est pas problématique (de l’ordre de la seconde).
Ainsi le présent procédé est optimal aussi bien pour l’utilisateur que pour les tiers.
Cas chaîne de blocs
La base de données est comme expliqué une base de données de type « chaîne de blocs », c’est-à-dire une base de données mémorisée par une pluralité de nœuds de stockage configurés pour valider des données écrites dans la base de données par la mise en œuvre d’une méthode de recherche de consensus entre les nœuds de stockage. Une telle méthode est par exemple la méthode connue de « preuve par le travail » (« proof of work » en anglais). Le contenu de la base de données est ainsi protégé contre des falsifications et ce malgré son caractère distribué / décentralisé. Chaque bloc présente généralement :
- un contenu du bloc (ou « payload »), constitué généralement des données descriptives d’un ensemble de transactions ;
- un en-tête du bloc (ou « header »), contenant des données descriptives du bloc en lui-même, c’est-à-dire des informations telles qu’un identifiant du bloc, un identifiant du bloc précédent dans la chaîne de blocs, un nonce, un numéro de version, un horodatage, un niveau de difficulté, etc.
On peut prendre l’exemple d’une base de données conforme à celle utilisée par le système de transaction Bitcoin®. Ainsi, sont susceptible d’être mémorisées dans la base de données 3 des données descriptives d’une transaction, entre deux wallets, d’un certain montant en Bitcoins.
La fonction principale assurée par une entité de vérification 2 est de valider les transactions soumises à la chaîne de blocs, et si c’est un mineur il a en outre le rôle de « miner » des nouveaux blocs de ladite chaîne de blocs. Chaque fois qu'un ensemble de transactions est validé, il constitue un bloc. Si ce bloc remplit certains critères spécifiques à la chaîne de blocs du système de transaction (voir plus loin), il est alors ajouté au sommet de la chaîne et l’entité de vérification 2 qui a constitué ce bloc est récompensé pour son travail.
L’étape (c) s’inscrit alors dans une tâche existante de vérification de la validité des données de la transaction transmises à l’étape (b) préalable au minage d’un bloc, de sorte à s’assurer que la transaction n’est pas frauduleuse (vérification de la signature de l’émetteur i.e. l’entité de preuve 1, de l’existence du bénéficiaire, et le cas échéant de la disponibilité des fonds, mais également que la transaction n’est pas déjà dans un autre bloc). La preuve ainsi que ses éventuels entrées (empreinte cryptographique de la donnée d’authentification candidate et/ou de référence) peuvent être insérée dans un champ adapté, en particulier le OP_RETURN existant dans les transactions Bitcoin (d’une taille de 80 octets).
Si la vérification de l’étape (c) est concluante, l’étape (d) comprend en outre préférentiellement la génération et l’ajout à ladite base de données de type chaîne de blocs d’un nouveau bloc constitué des données descriptives d’un ensemble de transactions comprenant lesdites données de transaction reçues à l’étape (b), i.e. l’assemblage de cet ensemble de transaction en tant que contenu du bloc, de sorte que tout tiers accédant à la base de données pourra constater une fois que ce bloc est publié l’existence de la transaction, et accéder à toutes les données de vérification y compris la preuve et/ou les empreintes cryptographiques des données d’authentification candidate et/ou de référence. Cette étape est préférentiellement mise en œuvre ou du moins tentée par l’entité de vérification 2 si c’est un mineur.
Dans l’exemple de Bitcoin, au sein d'un bloc (dans son contenu), les transactions sont stockées sous la forme d'un arbre de Merkle. Ensuite, l’en-tête est adjoint au bloc, et il s’agit de la partie complexe.
De manière classique, cette partie consiste en la détermination de la valeur d’un nonce associé au bloc (et de façon générale des valeurs de l’en-tête du bloc) telle qu’un critère spécifique à la chaîne de blocs du système de transaction est vérifié.
Ce critère est préférentiellement au moins fonction du nonce et d’un fragment du contenu du bloc, notamment une condition sur une empreinte cryptographique d’un n-uplet d’au moins ledit nonce et le fragment du contenu du bloc, en particulier le fait (dans le cas de Bitcoin) que ladite empreinte cryptographique commence par un certain nombre de zéros selon le niveau de difficulté actuel. Le présent procédé ne sera pas limité à ce mode de réalisation, et la condition pourra par exemple porter sur une signature du bloc.
Ledit fragment du contenu du bloc est avantageusement une empreinte indirecte de l’ensemble des transactions du bloc, par exemple la racine de l’arbre des transactions du bloc si elles sont stockées sous la forme d’un arbre de Merkle.
Ladite empreinte cryptographique d’un n-uplet d’au moins ledit nonce et le fragment du contenu du bloc constitue avantageusement un identifiant du bloc.
De manière préférée, ledit n-uplet comprend avantageusement en outre l’identifiant du bloc précédent, et de manière particulièrement préférée il s’agit d’un sextuplet constitué :
- du numéro de version,
- de l'empreinte cryptographique du bloc précédent,
- dudit fragment du contenu du bloc (la racine de l'arbre des transactions du bloc),
- de l'horodatage (par exemple temps écoulé depuis le 1er janvier 1970 0 h, en secondes),
- du niveau de difficulté,
- du nonce.
En pratique, l’étape (d) est tentée simultanément par un grand nombre de mineurs, la détermination de la bonne valeur du nonce consiste généralement à tester un grand nombre de valeurs jusqu’à ce que le critère soit vérifié. Une fois la bonne valeur du nonce déterminée, toutes les données ci-dessus peuvent être renseignées dans l’en-tête du bloc, et ce bloc soumis aux autres entités de vérification 2, qui en vérifient la validité (en vérifiant ledit critère, i.e. en recalculant ladite empreinte cryptographique d’un n-uplet d’au moins ledit nonce et le fragment du contenu du bloc) avant de le rediffuser à leur tour, et de l’ajouter dans la base de données à la suite de la chaîne. Le mineur est alors rémunéré, et les autres doivent recommencer à travailler sur un nouveau bloc.
A ce stade-là, le bloc généré est public, et les transactions qu’il contient peuvent être vues par tous, y compris l’entité de preuve 1.
Cas bancaire
Si la transaction est de type paiement par carte bancaire chez un marchand ou en ligne, l’étape (d) comprend la réception en retour d’une autorisation de la transaction vers l’entité de preuve 1 et un équipement marchand (un TPE 3 ou un serveur marchand), de sorte à informer l’entité de preuve 1 que les données de transaction qu’elle a fournie sont correctes que la transaction va pouvoir être traitée.
La transaction en elle-même pourra être mise en œuvre de manière connue.
Ensemble d’équipements
Selon un deuxième aspect, est proposé un ensemble de traitement d’une transaction émise depuis une entité de preuve 1 pour la mise en œuvre du procédé selon le premier aspect.
L’ensemble comprend l’entité de preuve 1 (premier équipement) et une entité de vérification 2 (deuxième équipement) connectées, et le cas échant, une entité de confiance 3 (troisième équipement) et/ou une entité d’autorité 4 (quatrième équipement).
L’entité de preuve 1, qui est typiquement un dispositif personnel de l’utilisateur comme un smartphone, comprend des moyens de traitement de données 11 configurés pour générer une signature de l’entité de preuve 1 à partir d’une clé secrète dont elle dispose et une preuve à divulgation nulle de connaissances du fait qu’une donnée d’authentification candidate et une donnée d’authentification de référence coïncident, et transmettre à l’entité de vérification 2 des données de transaction comprenant au moins ladite signature de l’entité de preuve 1 et ladite preuve à divulgation nulle de connaissance.
Les moyens de traitement de données 11 peuvent en outre être configurés, si la donnée d’authentification est une donnée biométrique, pour générer la donnée biométrique de référence à partir d’un trait biométrique de référence associé à un document officiel, et l’empreinte cryptographique de la donnée biométrique de référence.
L’entité de vérification 2 quant à elle ne dispose préférentiellement jamais des données d’authentification de référence ou candidate, et seulement d’une empreinte cryptographique de la donnée biométrique de référence.
Elle comprend des moyens de traitement de données 21 configurés pour vérifier que ladite signature de l’entité de preuve 1 et la preuve à divulgation nulle de connaissance sont valides, et le cas échéant qu’une empreinte cryptographique reçue de la donnée d’authentification de référence correspond à une dont dispose l’entité de vérification 2.
L’éventuelle entité de confiance 3 comprend des moyens d’acquisition biométrique 34 et des moyens de traitement de données 31.
Ces derniers sont configurés pour, le cas échéant :
- générer la donnée d’authentification candidate de type biométrique à partir d’un trait biométrique fourni par les moyens d’acquisition biométrique 34 et l’empreinte cryptographique de la donnée biométrique candidate obtenue ;
- transmettre à l’entité de preuve 1 au moins la donnée biométrique candidate obtenue (et généralement l’empreinte cryptographique de la donnée biographique candidate) ; et (éventuellement) à l’entité de vérification 2 l’empreinte cryptographique générée de la donnée biométrique candidate.
Produit programme d’ordinateur
Selon un troisième et un quatrième aspects, l’invention concerne un produit programme d’ordinateur comprenant des instructions de code pour l’exécution (en particulier sur les moyens de traitement de données 11, 21, 31, 41 des entités 1, 2, 3, 4) d’un procédé selon le premier aspect de l’invention de traitement d’une transaction émise depuis une entité de preuve 1, ainsi que des moyens de stockage lisibles par un équipement informatique (une mémoire des entités 1, 2, 3, 4) sur lequel on trouve ce produit programme d’ordinateur

Claims (16)

  1. Procédé de traitement d’une transaction émise depuis une entité de preuve (1) connectée à une entité de vérification (2) ;
    l’entité de preuve (1) disposant au moins d’une clé secrète et d’une donnée d’authentification candidate, l’entité de vérification (2) disposant de l’empreinte cryptographique d’une donnée d’authentification de référence ;
    le procédé comprenant des étapes de :
    (a) génération par les moyens de traitement de données (11) de l’entité de preuve (1) de :
    • une signature de l’entité de preuve (1) à partir de ladite clé secrète ;
    • une preuve à divulgation nulle de connaissances du fait que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident ;
    (b) transmission à l’entité de vérification (2) de données de transaction comprenant au moins :
    • ladite signature de l’entité de preuve (1) ;
    • ladite preuve à divulgation nulle de connaissance ;
    (c) vérification par les moyens de traitement de données (21) de l’entité de vérification (2) que ladite signature de l’entité de preuve (1) et la preuve à divulgation nulle de connaissance sont valides ;
    (d) traitement de ladite transaction.
  2. Procédé selon la revendication 1, dans lequel l’entité de preuve (1) dispose en outre de la donnée d’authentification de référence et/ou d’une empreinte cryptographique de la donnée d’authentification de référence, lesdites données de transaction transmises à l’étape (b) comprenant en outre ladite empreinte cryptographique de la donnée d’authentification de référence, et l’étape (c) comprenant la vérification par les moyens de traitement de données (21) de l’entité de vérification (2) que l’empreinte cryptographique reçue de la donnée d’authentification de référence correspond à celle dont dispose l’entité de vérification (2).
  3. Procédé selon la revendication 2, dans lequel l’entité de preuve (1) ne dispose initialement que de la donnée d’authentification de référence et/ou de l’empreinte cryptographique de la donnée biométrique de référence, le procédé comprenant la mise en œuvre par des moyens de traitement de données (11, 31) d’une entité de confiance (3) ou de l’entité de preuve (1) d’une étape préalable (a1) de :
    • Obtention de la donnée d’authentification candidate ;
    • génération de l’empreinte cryptographique de la donnée d’authentification candidate obtenue.
  4. Procédé selon la revendication 3, comprenant une étape encore antérieure (a0) de génération par les moyens de traitement de données (11) de l’entité de preuve (1) de la donnée biométrique de référence à partir d’un trait biométrique de référence associé à un document officiel ; et de l’empreinte cryptographique de la donnée biométrique de référence.
  5. Procédé selon l’une des revendications 1 à 4, dans lequel la preuve à divulgation nulle de connaissances est un objet cryptographique de type zkSNARK.
  6. Procédé selon l’une des revendications 1 à 5, dans lequel l’étape (a) comprend la vérification préalable que la donnée d’authentification candidate et la donnée d’authentification de référence coïncident.
  7. Procédé selon l’une des revendications 1 à 6, dans lequel les données d’authentification candidate et de référence sont des données biométriques candidate et de référence, l’entité de preuve (1) disposant en outre de la donnée biométrique de référence, d’une empreinte cryptographique de la donnée biométrique candidate et de l’empreinte cryptographique de la donnée biométrique de référence, lesdites données de transaction transmises à l’étape (b) comprenant en outre ladite empreinte cryptographique de la donnée biométrique candidate.
  8. Procédé selon les revendications 6 et 7 en combinaison, dans lequel la donnée biométrique candidate et la donnée biométrique de référence coïncident si leur distance selon une fonction de comparaison donnée est inférieure à un seuil prédéterminé.
  9. Procédé selon la revendication 8, dans lequel ladite preuve à divulgation nulle de connaissances du fait que la donnée biométrique candidate et la donnée biométrique de référence coïncident est une preuve à divulgation nulle de connaissances du fait qu’étant données deux empreintes cryptographiques, il existe une donnée biométrique candidate et une donnée biométrique de référence ayant pour empreintes cryptographiques respectives les empreintes cryptographiques données, telles que leur distance selon la fonction de comparaison donnée est inférieure au seuil prédéterminé.
  10. Procédé selon la revendication 6, dans lequel les données d’authentification candidate et de référence sont un code candidat et un code de référence, le code candidat et le code de référence coïncidant si leurs empreintes cryptographiques correspondent.
  11. Procédé selon la revendication 10, dans lequel ladite preuve à divulgation nulle de connaissances du fait que le code candidat et le code de référence coïncident est une preuve à divulgation nulle de connaissances du fait qu’étant donnée une empreinte cryptographique, il existe un code candidat ayant pour empreinte cryptographique une empreinte cryptographique du code candidat correspondant à ladite empreinte cryptographique donnée.
  12. Procédé selon l’une des revendications 1 à 11, dans lequel l’entité de preuve (1) est un dispositif électronique personnel à un utilisateur de type carte bancaire, terminal mobile ou ordinateur personnel.
  13. Procédé selon l’une des revendications 1 à 12, dans lequel ladite transaction est dans une base de données de type chaîne de blocs, l’étape (d) comprenant la génération d’un bloc contenant lesdites données de transaction transmise à l’étape (b) et son ajout dans ladite base de données de type chaîne de blocs
  14. Ensemble de traitement d’une transaction émise depuis une entité de preuve (1) disposant au moins d’une clé secrète, comprenant ladite entité de preuve (1) et une entité de vérification (2) connectées, caractérisé en ce que :
    • l’entité de preuve (1) comprend des moyens de traitement de données (11) configurés pour générer une signature de l’entité de preuve (1) à partir de ladite clé secrète et une preuve à divulgation nulle de connaissances du fait qu’une donnée d’authentification candidate et une donnée d’authentification de référence coïncident, et transmettre à l’entité de vérification (2) des données de transaction comprenant au moins ladite signature de l’entité de preuve (1) et ladite preuve à divulgation nulle de connaissance ;
    • l’entité de vérification (2) comprend des moyens de traitement de données (21) configurés pour vérifier que ladite signature de l’entité de preuve (1) et la preuve à divulgation nulle de connaissance sont valides.
  15. Produit programme d’ordinateur comprenant des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 13 de traitement d’une transaction émise depuis une entité de preuve (1), lorsque ledit procédé est exécuté sur un ordinateur.
  16. Moyen de stockage lisible par un équipement informatique sur lequel un produit programme d’ordinateur comprend des instructions de code pour l’exécution d’un procédé selon l’une des revendications 1 à 13 de traitement d’une transaction émise depuis une entité de preuve (1).
FR1908239A 2019-07-19 2019-07-19 Procédé de traitement d’une transaction émise depuis une entité de preuve Active FR3098947B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1908239A FR3098947B1 (fr) 2019-07-19 2019-07-19 Procédé de traitement d’une transaction émise depuis une entité de preuve
US16/918,052 US11810110B2 (en) 2019-07-19 2020-07-01 Method of processing a transaction sent from a proof entity

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1908239A FR3098947B1 (fr) 2019-07-19 2019-07-19 Procédé de traitement d’une transaction émise depuis une entité de preuve
FR1908239 2019-07-19

Publications (2)

Publication Number Publication Date
FR3098947A1 true FR3098947A1 (fr) 2021-01-22
FR3098947B1 FR3098947B1 (fr) 2021-09-10

Family

ID=68806938

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1908239A Active FR3098947B1 (fr) 2019-07-19 2019-07-19 Procédé de traitement d’une transaction émise depuis une entité de preuve

Country Status (2)

Country Link
US (1) US11810110B2 (fr)
FR (1) FR3098947B1 (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200096248A (ko) * 2017-12-13 2020-08-11 엔체인 홀딩스 리미티드 암호 자료를 안전하게 공유하기 위한 시스템 및 방법
US11509464B2 (en) * 2019-06-13 2022-11-22 Luis Eduardo Gutierrez-Sheris System and method using a fitness-gradient blockchain consensus and providing advanced distributed ledger capabilities via specialized data records
US11514439B2 (en) * 2020-02-26 2022-11-29 Nice Ltd. System and method using zero knowledge proofs for alert sharing
FR3111721B1 (fr) * 2020-06-17 2023-08-11 Idemia Identity & Security France Procédé d’authentification d’un utilisateur sur un équipement client

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180270065A1 (en) * 2017-03-15 2018-09-20 NuID, Inc. Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
EP3468096A1 (fr) * 2017-10-04 2019-04-10 Idemia Identity & Security France Procédé de vérification d'une authentification biométrique

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1894923A (zh) * 2003-10-08 2007-01-10 史蒂芬·J·英格博格 用改进保密性技术来建立通讯的方法和系统
GB201611948D0 (en) * 2016-07-08 2016-08-24 Kalypton Int Ltd Distributed transcation processing and authentication system
GB201613233D0 (en) * 2016-08-01 2016-09-14 10Am Ltd Data protection system and method
US10861015B1 (en) * 2017-01-25 2020-12-08 State Farm Mutual Automobile Insurance Company Blockchain based account funding and distribution
US11139955B1 (en) * 2018-02-12 2021-10-05 Winklevoss Ip, Llc Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180270065A1 (en) * 2017-03-15 2018-09-20 NuID, Inc. Methods and systems for universal storage and access to user-owned credentials for trans-institutional digital authentication
EP3468096A1 (fr) * 2017-10-04 2019-04-10 Idemia Identity & Security France Procédé de vérification d'une authentification biométrique

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
CRAIG COSTELLOCEDRIC FOURNETJON HOWELLMARKULF KOHLWEISSBENJAMIN KREUTERMICHAEL NAEHRIGBRYAN PARNOSAMEE ZAHUR: "Proceedings of the IEEE Symposium on Security and Privacy", 18 May 2015, IEEE, article "Pinocchio: Nearly Practical Verifiable Computation"
DAVID CEREZO S\'ANCHEZ: "Zero-Knowledge Proof-of-Identity: Sybil-Resistant, Anonymous Authentication on Permissionless Blockchains and Incentive Compatible, Strictly Dominant Cryptocurrencies", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 22 May 2019 (2019-05-22), XP081599209 *
ELI BEN-SASSONALESSANDRO CHIESADANIEL GENKINERAN TROMERMADARS VIRZA: "SNARKs for C: Verifying Program Executions Succinctly and in Zéro Knowledge", PROCEEDINGS OF THE 33RD ANNUAL INTERNATIONAL CRYPTOLOGY CONFÉRENCE, CRYPTO, vol. 13, 2013, pages 90 - 108, XP047420165, DOI: 10.1007/978-3-642-40084-1_6
MANN CHRISTOPHER ET AL: "Two-factor authentication for the Bitcoin protocol", INTERNATIONAL JOURNAL OF INFORMATION SECURITY (IJIS), SPRINGER, HEIDELBERG, DE, vol. 16, no. 2, 5 April 2016 (2016-04-05), pages 213 - 226, XP036175020, ISSN: 1615-5262, [retrieved on 20160405], DOI: 10.1007/S10207-016-0325-1 *

Also Published As

Publication number Publication date
US11810110B2 (en) 2023-11-07
US20210019746A1 (en) 2021-01-21
FR3098947B1 (fr) 2021-09-10

Similar Documents

Publication Publication Date Title
EP3547270B1 (fr) Procédé de vérification d'une authentification biométrique
EP3468096B1 (fr) Procédé de vérification d'une authentification biométrique
EP0941525B1 (fr) Systeme d'authentification a carte a microcircuit
FR3098947A1 (fr) Procédé de traitement d’une transaction émise depuis une entité de preuve
FR3054905B1 (fr) Procede de generation de cle et procede de controle d'acces
FR2733379A1 (fr) Procede de generation de signatures electroniques, notamment pour cartes a puces
EP3767876A1 (fr) Procede de verification d'une transaction dans une base de donnees de type chaine de blocs
EP3686788A1 (fr) Procédé de vérification d'une authentification biométrique
EP3742699B1 (fr) Procédé d'authentification forte d'un individu
EP3731116B1 (fr) Procédé d'authentification d'un document d'identité d'un individu et d'authentification dudit individu
CA2888103C (fr) Procede de signature electronique a signature ephemere
EP3239902B1 (fr) Procede de verification d'une authentification ou d'une identification biometrique
WO2012156648A1 (fr) Acces protege par biometrie a des dispositifs electroniques
EP2509025A1 (fr) Procédé d'accès à une ressource protégée d'un dispositif personnel sécurisé
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
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
WO2007006771A1 (fr) Procede et dispositif d'autorisation de transaction
FR2877453A1 (fr) Procede de delegation securisee de calcul d'une application bilineaire
EP4241190A1 (fr) Procede d'authentification securise par le decouplage structurel des identifiants personnels et de services
WO2017077210A1 (fr) Procédé de verification d'identité lors d'une virtualisation
EP4099614A1 (fr) Procédés d'enrolement de données pour vérifier l'authenticité d'une donnée de sécurité ou de verification de l'authenticité d'une donnée de securité
WO2024145679A2 (fr) Monnaie à intégration biométrique
FR3089320A1 (fr) Vérification biométrique partagée entre un processeur et un élément sécurisé
FR2984648A1 (fr) Dispositif electronique individuel et procede de reponse par un dispositif electronique individuel a une sollicitation
CH716301A2 (fr) Procédé de signature d'une transaction destinée à une blockchain déployée sur un réseau pair-à-pair, au moyen d'une clé cryptographique distribuée parmi les noeuds d'un autre réseau pair-à-pair.

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20210122

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6