Brevet FR3098947A1 — publié le 20210122

Description Titre de l'invention : Procédé de traitement d'une transaction émise depuis une entité de preuve Domaine technique [0001] 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 ». Technique antérieure [0002] Sont apparues ces dernières années des bases de données appelées « chaines de blocs » (en anglais, « blockchain »). [0003] Une base de données de type chaîne de blocs est distribuée entre plusieurs noeuds de stockage d'un réseau. Les noeuds de stockage sont configurés pour valider des données écrites dans la base de données par la mise en oeuvre d'une méthode de recherche de consensus entre les noeuds 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é. [0004] 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 BitcoinG. La base de données du système BitcoinC) 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. [0005] 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, sua aphone) 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. [0006] 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. 2 100071 11 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 F1DO. [0008] Par exemple, on combine le premier facteur d'authentification possédé par l'utilisateur, dit authentificatcur, et quelque chose que l'utilisateur « sait » ou « est » (un code, un trait biométrique, etc.). [0009] Il est connu de mettre en oeuvre la transaction depuis un terminal mohile tel qu'un smartphone stockant ladite clé secrète (on connait ainsi des services de paiement mohile pour iOS ou Android - aussi bien des wallcts 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. [0010] Ainsi, une vraie authentification biométrique est accomplie car on combine « quelque chose que l'individu possède », i.c. son terminal mobile, et « quelque chose que l'individu est/sait » en tant que deuxième facteur. [0011] 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é. [0012] 11 serait ainsi souhaitable de permettre une nouvelle solution d'authentification forte d'un utilisateur cherchant à mettre un oeuvre une transaction, qui soit universelle, fiable et facile à mettre en oeuvre. Exposé de l'invention [0013] 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 : 3 - 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. [0014] Selon d'autres caractéristiques avantageuses et non-limitatives : [0015] 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 (h) 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. [0016] 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 oeuvre par des moyens de traitement de données d'une entité de confiance ou de l'entité de preuve d'une étape préalable (al) de : - Obtention de la donnée d'authentification candidate ; - génération de l'empreinte cryptographique de la donnée d'authentification candidate obtenue. [0017] 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. [0018] La preuve à divulgation nulle de connaissances est un objet cryptographique de type zkSNARK. [0019] 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. [0020] Les données d'authentification candidate et de référence sont des données bio- mé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. [0021] 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é. [0022] Ladite preuve à divulgation nulle de connaissances du fait que la donnée hiométrique candidate et la donnée hiomé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 hiométrique candidate et une donnée hiomé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é. [0023] 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. [0024] 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. [0025] L'entité de preuve est un dispositif électronique personnel à un utilisateur de type carte bancaire, terminal mobile ou ordinateur personnel. [0026] Ladite transaction est dans une hase 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 (h) et son ajout dans ladite hase de données de type chaîne de blocs [0027] 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. [0028] 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. Brève description des dessins [0029] D'autres caractéristiques, buts et avantages de l'invention ressortiront de la des- cription qui suit, qui est purement illustrative et non limitative, et qui doit être lue en regard des dessins annexés sur lesquels : [0030] [fie.la] La figure la représente de manière schématique un système de traitement d'une transaction, selon un premier mode de réalisation. [0031] [fie.lb] La figure lb représente de manière schématique un système de traitement d'une transaction, selon un deuxième mode de réalisation. [0032] [fig.lc] La figure le représente de manière schématique un système de traitement d'une transaction, selon un troisième mode de réalisation. [0033] [fig.2] La figure 2 est un organigramme d'étapes d'un procédé de traitement d'une transaction mis en oeuvre dans un système représenté en l'une des figure la, lb, le. [0034] Sur l'ensemble des figures, les éléments similaires portent des références identiques. Description des modes de réalisation [0035] Architecture [0036] En référence aux figures la, lb, le, on a représenté schématiquement trois cas de systèmes de transaction pour la mise en oeuvre 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 1 a, 1h, - Transaction sur une base de données de type chaîne de blocs (par exemple transfert de hitcoins) ; - 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. 100371 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). 100381 Le deuxième équipement 2 est détenu et contrôlé par une entité auprès de qui l'authentification doit être effectuée. 6 [0039] 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 val idcur de transaction dit « noeud de la chainc 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. [0040] L'un des équipements met en oeuvre 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 oeuvre l'authentification et fournit le résultat au deuxième équipement 2 qui vérifie cc résultat, dit entité de vérification. [0041] Le premier équipement 1 comporte des moyens de traitement de données 11, i.c. 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 oeuvre le procédé ci-après. [0042] Le premier équipement 1 comprend avantageusement une interface de commu- nication 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 oeuvre, 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. [0043] 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). [0044] 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. [0045] 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 oeuvre le procédé ci-après. [0046] Ces autres équipements 2, 3, 4 comprennent avantageusement eux aussi des in- terfaces de communication leur permettant de dialoguer à distance entre eux et avec le premier équipement 1. 7 [0047] 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. [0048] 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 oeuvre 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 [0049] Le troisième équipement 3 et/ou éventuellement le premier équipement 1 com- prennent à 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. [0050] Transactions [0051] 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 ». [0052] Selon un premier mode de réalisation illustré par la figure la, ladite transaction est sur une base de données de type chaîne de blocs (par exemple transfert de bitcoins). [0053] 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. [0054] 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. [0055] 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 8 clé privée propre à cette entité. Inversement, toute donnée signée lue dans la hase de données par un tiers titulaire d'un compte d'accès à la hase 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é. [0056] 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. [0057] De manière générale, toute transaction sur une hase de données de type chaîne dc 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 scriptPubKcy 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. [0058] Avantageusement, les données descriptives d'une transaction incluent en outre une « entrée », c'est à dire l'identifiant, noté proviens tx pour hitcoin, d'une ou plusieurs transactions précédentes (i.c. dont le bénéficiaire est l'émetteur dc la présente transaction) dont le montant de sortie est suffisant pour couvrir la transaction, i.c. justifiant la disponibilité des fonds objet dc la transaction. Une transaction équilibre toujours ses entrées et ses sorties. [0059] 11 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). [0060] 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. [0061] Selon un deuxième mode de réalisation illustré par la figure lb, 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. 9 [0062] 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. [0063] 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. [0064] Selon un troisième mode de réalisation illustré par la figure lc, 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 (Fun marchand est l'entité de vérification 2. [0065] 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 (lesdits 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). [0066] Authentification forte [0067] 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. [0068] Ainsi l'équipement 1 met en oeuvre 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. [0069] 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.c. un code attendu, et la donnée d'authentification est un code candidat, i.c. un code saisi par l'utilisateur qui va être vérifié. [0070] Selon une deuxième variante, ladite donnée d'authentification est une donnée bio- métrique, de sorte qu'on compare une donnée biométriquc 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. [0071] Dans cc 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. [0072] Enrôlement [0073] 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. [0074] 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. [0075] 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. [0076] 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. 11 [0077] Dans un mode de réalisation préféré, en référence à la figure 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 oeuvre 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). [0078] Typiquement, cette étape comprend : - l'obtention par l'entité de preuve 1 de la donnée d'authentification de référence, i.c. dans le cas de données hiomé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). [0079] 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 ». [0080] 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. [0081] 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. [0082] 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 12 de référence, et de l'empreinte cryptographique de la donnée hiomé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 hiométrique de référence à l'entité de vérification 2. [0083] Cette vérification peut être faite de nombreuses façons, et consiste simplement à vérifier que la donnée hiomé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. [0084] De façon générale, on comprendra que l'étape (a0) pourra être mise en oeuvre de n'importe quelle façon permettant de façon sécurisée de fournir au premier équipement 1 la donnée hiométrique de référence signée par une autorité par exemple gouvernementale ou bancaire. [0085] 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.c. être par exemple être mise en oeuvre à 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. [0086] Obtention de la donnée d'authentification candidate [0087] 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 hiométrique de référence. Comme expliqué, ces deux dernières peuvent être obtenues préalablement lors d'une étape (a0) d'enrôlement. [0088] En ce qui concerne la donnée d'authentification candidate, « fraîche », celle-ci peut être obtenue lors d'une étape préalable (al). 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. [0089] Il est important de comprendre que si l'étape d'enrôlement (a0) peut être mise en oeuvre des semaines avant la mise en oeuvre de l'authentification, l'étape (al) est au pire mise en oeuvre quelques minutes avant le reste du procédé, pour garantir la fraicheur » de la donnée d'authentification candidate. [0090] L'étape (al) est mise en oeuvre 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. [0091] En effet, l'entité de preuve 1 n'a pas nécessairement de moyens d'acquisition 13, 14 de la donnée (l'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 13 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 hiométrique 14. [0092] L'étape (al) ) 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. [0093] Dans le cas hiométrique, l'étape (al) ) comprend la génération de la donnée bio- métrique candidate à partir d'un trait hiométrique fourni par des moyens d'acquisition hiométrique 14, 34 de l'entité de preuve 1 ou l'entité de confiance 3. On note que si l'étape (al) ) peut être mise en oeuvre par l'entité de preuve 1, i.c. l'utilisateur peut utiliser un trait hiométrique fourni par les moyens d'acquisition hiomé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 hiométrique 34 sont capable de détecter le vivant, de sorte à s'assurer que la donnée hiométrique candidate est issue d'un trait « réel ». [0094] Enfin s'il y a lieu, l'entité de confiance 3 transmet à l'entité de preuve 1, au moins la donnée hiométrique candidate obtenue et optionnellement l'empreinte cryptographique générée de la donnée hiomé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é. [0095] Procédé général [0096] 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. [0097] 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. [0098] Le protocole Pinocchio présenté dans la publication « Bryan Pamo, Craig Gentry, 14 Ion Howell, and Mariana Raykova, Pinocchio: Ncarly Practical Vcrifiablc 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. [0099] Dans unc 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. [0100] 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/2e, voire inférieur à 1/2125 selon 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é. [0101] 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. [0102] 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. [0103] 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. [0104] Ainsi, dans le cas biométrique, la mise en oeuvre 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. [0105] 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. [0106] Ce type de comparaison est connu de l'Homme du Métier et ne sera pas décrit plus en détails ci-avant. [0107] 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. [0108] 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é. [0109] Génération de preuve [0110] De façon préférée, ladite preuve à divulgation nulle de connaissances est un objet cryptographique de type zkSNARK. [0111] 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 16 infinie et les preuves restent sécurisées malgré cela. [0112] La notion de preuve a ensuite été relâchée, le protocole ne cherchant à se protéger que d'un prouvcur qui aurait une puissance de calcul importante niais bornée. Le résultat du protocole n'est plus une preuve niais 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 prouvcur n'ont pas besoin d'interagir pour produire l'argument. [0113] 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 prouvcur d'effectuer une preuve à divulgation nulle de connaissance i.c. la preuve ne contient aucune information non triviale sur les entrées fournies par le prouvcur. [0114] 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, Ccdric Fournet, Jon Howell, Markulf Kohlwciss, Benjamin Kreutcr, Michacl Nachrig, 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. [0115] Pour prendre l'exemple du protocole Pinocchio, ce protocole comporte plusieurs parties : [0116] 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. [0117] 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 17 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. [0118] 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. [0119] 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. [0120] 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ômialcs. 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. [0121] 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 prouvcur 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. [0122] Ce polynôme «preuve », quand il est caché dans une courbe elliptique constitue un zkSNARK. [0123] 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 : [0124] Cas d'un code [0125] Entrée : l'empreinte cryptographiques du code de référence h n, r = H(t re 4, le résultat de la comparaison de l'empreinte cryptographiques du code de référence h ref et de l'empreinte cryptographiques du code candidat h fresh = H(1- r ), (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 t fres h Sortie : la preuve Tc que le prouveur connaît bien un code candidat /- fres h qui se hache en h fresh et dont le résultat de la comparaison est celui attendu ( h h r f r e 0' 18 [0126] Cas biométrique [0127] Entrée : les empreintes cryptographiques de la donnée biométrique candidate \ et de référence h = t le résultat de la com- hfres/1= H(tt.res re f 1, yen paraison des données biométriques candidate t ', h et de référence t re f (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 t fr,,, h et de référence Sortie : la preuve n que le prouveur connaît bien des données biométriques t fr. e s h et t re f qui se hachent en h fresh et h re.t. et dont le résultat de la comparaison est celui attendu. [0128] 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. [0129] Le protocole Zcrocash (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), cc qui reste élevé et largement améliorable. [0130] Le protocole ZKBoo, présenté dans la publication « ZKBoo : faster zero-knowledge for boolcan circuits » de Giacomelli, Madsen et Orlandi (Uscnix 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. [0131] Suite du procédé [0132] 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.). [0133] 11 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 19 pas transmises. [0134] 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. [0135] 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 (al) ) dans le cas biométrique). [0136] Si c'est le cas, l'utilisateur est authentifié, et dans une étape (d) la transaction peut être traitée (voir plus loin). [0137] 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.c. 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. [0138] 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. [0139] 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 oeuvre 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). [0140] Ainsi le présent procédé est optimal aussi bien pour l'utilisateur que pour les tiers. [0141] Cas chaîne de blocs [0142] La base de données est comme expliqué une base de données de type « chaîne de blocs », c'est-à-dire une hase dc données mémorisée par une pluralité de noeuds de stockage configurés pour valider des données écrites dans la hase de données par la mise en oeuvre d'une méthode de recherche de consensus entre les noeuds 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 dc la hase 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 dc 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. [0143] On peut prendre l'exemple d'une hase 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 wallcts, d'un certain montant en Bitcoins. [0144] La fonction principale assurée par une entité de vérification 2 est de valider les tran- sactions soumises à la chaîne de blocs, et si c'est un mineur il a en outre le rôle de « miner » des nouveaux hlocs de ladite chaîne de hlocs. 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. [0145] L'étape (c) s'inscrit alors dans une tache 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). [0146] 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 21 accédant à la hase 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 oeuvre ou du moins tentée par l'entité de vérification 2 si c'est un mineur. [0147] 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. [0148] 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é. [0149] Cc 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 nuplet 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. [0150] 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. [0151] 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. [0152] 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 ler janvier 1970 0 h, en secondes), - du niveau de difficulté, - du nonce. [0153] 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.c. 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 hase de données à la suite de la chaîne. Lc mineur est alors rémunéré, et les autres doivent recommencer à travailler sur un nouveau bloc. [0154] A cc 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. [0155] Cas bancaire [0156] 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. [0157] La transaction en elle-même pourra être mise en oeuvre de manière connue. [0158] Ensemble d'équipements [0159] 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 oeuvre du procédé selon le premier aspect. [0160] 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). [0161] 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. [0162] 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éhique de référence associé à un document officiel, et l'empreinte cryptographique de la donnée biométrique de référence. [0163] 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. 23 [0164] 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. [0165] L'éventuelle entité de confiance 3 comprend des moyens d'acquisition hiométriquc 34 et des moyens de traitement de données 31. [0166] Ces derniers sont configurés pour, le cas échéant : - générer la donnée d'authentification candidate de type hiométriquc à partir d'un trait hiométriquc fourni par les moyens d'acquisition hiométriquc 34 et l'empreinte cryptographique de la donnée hiométriquc candidate obtenue ; - transmettre à l'entité de preuve 1 au moins la donnée hiométriquc candidate obtenue (et généralement l'empreinte cryptographique de la donnée biographique candidate) ; et (éventuellement) à l'entité dc vérification 2 l'empreinte cryptographique générée de la donnée hiométriquc candidate. [0167] Produit programme d'ordinateur [0168] 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 dc 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 24 [Revendication I] REVENDICATIONSProcé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 ( I) 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 (I I) 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 ; [Revendication 2] [Revendication 3] (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. 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). 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/ 25 ou de l'empreinte cryptographique de la donnée biométrique de référence, le procédé comprenant la mise en oeuvre 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 (al) de : Obtention de la donnée d'authentification candidate ; génération de l'empreinte cryptographique de la donnée d'authentification candidate obtenue. [Revendication 4] [Revendication 5] [Revendication 6] [Revendication 7] [Revendication 8] [Revendication 9] 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 hiométrique de référence à partir d'un trait hiométrique de référence associé à un document officiel ; et de l'empreinte cryptographique de la donnée biométrique de référence. Procédé selon l'une des revendications 1 à 4, dans lequel la preuve à divulgation nulle de connaissances est un objet cryptographique de type zkSNARK. 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. 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 hiomé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. 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é. 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 res- 26 [Revendication 10] [Revendication 11] [Revendication 12] [Revendication 13] [Revendication 14] pectives les empreintes cryptographiques données, telles que leur distance selon la fonction de comparaison donnée est inférieure au seuil prédéterminé. 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. 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. 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. Procédé selon l'une des revendications 1 à 12, dans lequel ladite transaction est dans une hase 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 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 27 de l'entité de preuve (1) et la preuve à divulgation nulle de connaissance sont valides. [Revendication 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. [Revendication 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).