FR 3053549 A1 20180105 FR 1656240 A 20160630 1 Procédé d'authentification de données de paiement, dispositifs et programmes correspondants. 1. Domaine L'invention se rapporte au domaine de la sécurisation des données échangées par l'intermédiaire d'un protocole de transmission de données sans contact. La technique se rapporte plus particulièrement à la transmission de données de type NFC, dans laquelle on effectue une transmission entre un premier dispositif et un deuxième dispositif séparés d'une distance de l'ordre d'une dizaine de centimètre au plus. La technique ne s'applique pas et n'est pas destinée à s'appliquer dans le cadre de techniques de transmission de données de type WiFi, WiMax, LTE, dont les technologies de transmission sont différentes. 2. Art Antérieur De nombreux dispositifs de la vie quotidienne sont aptes à communiquer et à échanger des données entre eux. Une part croissante de dispositifs utilisent, pour ce faire, des protocoles d'échange de données dit "en champ proches" ou encore NFC. Parfois, ces techniques de transmission de données sont également appelées RFID. Cette appellation n'est pas correcte puisque NFC signifie communication en champ proche, tandis que RFID se rapporte à des moyens d'identification par fréquence radio. Les deux utilisent des signaux radio pour toutes sortes de fins de repérage et de suivi, en remplaçant parfois des codes à barres. Toutes deux utilisent des moyens de transmission de données à courte portée. Or, l'utilisation de ce type de technologie suscite encore des craintes et des interrogations de la part des utilisateurs. Nombreux sont ceux qui n'accordent pas ou peu confiance à ces technologies, plus particulièrement lorsqu'il s'agit de les utiliser à des fins de traitement de données personnelles et/ou confidentielles. C'est par exemple le cas du paiement. Relativement récemment, des dispositifs de paiement sans contact ont fait leur apparition. Il s'agit par exemple des cartes de paiement sans contact qui permettent d'effectuer un paiement (dont le montant est généralement plafonné) en apposant (ou en rapprochant) la carte de paiement d'un terminal de paiement compatible. Il s'agit également des terminaux de communication, qui intègrent également des "puces" sans contact : ces puces (également appelées "contactless chip") et qui offrent des capacités d'échange de données aux terminaux de communication, capacités qui peuvent être utilisées pour effectuer des paiements, un peu comme si le terminal de communication imitait le comportement d'une 3053549 2 carte de paiement sans contact. De nombreuses rumeurs, souvent infondées, laissent entendre qu'une communication ou qu'un paiement réalisé sans contact serait peu sûr. Il est également souvent rapporté que les dispositifs seraient peu sécurisés et qu'il serait possible de récupérer les données qui sont contenus dans ces dispositifs à l'insu de l'utilisateur. Bien que 5 ces rumeurs soient souvent sans fondement, il existe cependant des risques lors de la transmission de données entre les dispositifs et notamment lors de la transmission de données de paiement. Les risques, cependant, ne proviennent pas de la technologie employée, en elle-même (NFC), mais généralement de l'utilisateur lui-même. Ainsi par exemple, dans le cas d'un terminal de communication utilisant l'interface NFC pour effectuer un paiement, il est possible 10 que l'utilisateur ait installé une application peu sure, voire une application malveillante, dont l'objectif est d'utiliser des données de paiement à des fins de fraudes. La situation est la même du côté du terminal du commerçant. Par exemple, dans le cadre d'une communication entre un dispositif d'utilisateur (un terminal de communication de type smartphone) et un terminal de paiement, notamment en 15 utilisant des protocoles NFC pour le paiement, il est nécessaire que le dispositif et le terminal authentifie des données. À cette fin, le dispositif met en oeuvre un protocole d'authentification avec le terminal (par exemple un terminal de paiement, une borne d'un marchand, ou tout autre dispositif approprié). Le terminal contrôle que la phase d'authentification a réussi et dans le cas contraire refuse la transaction ou déclenche une alerte, ou met en oeuvre tout 20 autre comportement jugé approprié dans une telle situation. Dans les scénarios typiques, le terminal effectuant ces contrôles est, un dispositif sécurisé (comme un terminal de paiement). Il a été conçu pour prévenir la plupart des types possibles d'intrusion, tant matérielles que logicielles. Mais si le terminal de paiement est un dispositif tiers (terminal de communication de type tablette, smartphone, écran), alors la 25 sécurité de ce terminal de communication (tiers) ne peut pas être garantie, pas plus que l'origine des applications installées sur ce terminal (par le commerçant lui-même). Si le commerçant n'est pas vigilant, il se peut que les applications installées sur ce terminal soient frauduleuses. On présente ci-après un cas de dysfonctionnement possible, mis en oeuvre lors d'un 30 paiement entre un terminal de communication et un dispositif d'utilisateur. On appelle "V" le 3053549 3 vérificateur (par exemple le terminal ou l'appareil du marchand) et "P" le prouveur (dispositif de l'utilisateur : smartphone, tablette). Les protocoles de paiement travaillent habituellement de la façon suivante, au cours de la transaction : V demande à P de signer numériquement des données. P signe les données, 5 conformément à ce qui est demandé par V et transmet les données signées à V. Cette signature est vérifiée par V, et si elle est correcte, alors la transaction est acceptée et transférée dans le reste de la chaîne de traitement des paiements. Une telle procédure est appelée un "défi-réponse" (challenge response) et est utilisée par exemple par les spécifications EMV. 10 Le problème auquel il est proposé de remédier est le suivant : si V fonctionne sur un dispositif non sécurisé (i.e. un terminal de type tablette, PC ou autre, auquel on a adjoint des fonctionnalités de paiement) qui est infecté par un logiciel malveillant (installé par le commerçant ou par un tiers mal intentionné), alors ce logiciel peut abuser le terminal du client P. Un tel abus peut par exemple prendre la forme d'une succession de transactions (invisibles). 15 Ceci peut être réalisé par exemple lorsque le terminal du commerçant force le dispositif de l'utilisateur à signer des messages arbitraires. Le dispositif de l'utilisateur, en position « d'esclave », est alors obligé de signer ces données. Le logiciel malveillant installé sur le terminal du commerçant se sert ensuite de ces données signées pour créer des transactions frauduleuses. 20 C'est le paradoxe de ces traitements cryptographiques : il est certain que les traitements réalisés sont bons (car ils mettent en oeuvre des traitements cryptographiques), en revanche, l'utilisation qui est faite des résultats de ces traitements cryptographiques ne peut pas être garantie. 3. Résumé 25 L'invention ne pose pas ces problèmes de l'art antérieur. Plus particulièrement, l'invention apporte une solution simple à la problématique préalablement identifiée. Cette solution est entièrement compatible avec les dispositifs matériels existants. Plus particulièrement, il est proposé un procédé d'authentification d'au moins une donnée, procédé mis en oeuvre lors d'une transaction de paiement intervenant entre un 30 terminal d'un commerçant et un dispositif d'utilisateur, procédé qui comprend la création d'un triplet d'authentification, comprenant un code d'authentification et deux composants de 3053549 4 signature, ce triplet étant construit par la dispositif d'utilisateur et n'étant vérifiable que par le terminal du commerçant. Pour ce faire, il est divulgué un procédé d'authentification d'au moins une donnée, procédé mis en oeuvre lors d'une transaction de paiement intervenant entre un terminal de 5 communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche, procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur : une étape d'obtention, à partir du message m, d'une donnée aléatoire t et d'une 10 fonction de hachage H, d'un code d'authentification S1; une étape d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Sl, d'un premier composant de signature S2 ; une étape d'obtention, à partir du message m, de la donnée aléatoire t, de la clé 15 publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification Sl, d'un deuxième composant de signature S3; une étape de transmission, au terminal de communication, du code d'authentification SI, et des deux composants de signature S2 et S3. 20 Un tel procédé permet de créer un triplet qui peut être transmis au terminal de communication pour permettre une vérification, en aveugle, de la validité (et de la connaissance) par le dispositif d'utilisateur, du message m. Selon un autre aspect, il est également divulgué un procédé d'authentification qui comprend, au sein du terminal de communication : 25 une étape d'obtention, à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Sl, d'une première valeur de référence, notée Ufrii; une étape d'obtention, à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Sl, 30 d'une deuxième valeur de référence, notée Up.21; 3053549 5 une étape de vérification que la première valeur de référence Ufrii est égale à la deuxième valeur de référence U [r21 ; et, lorsque les deux valeurs sont égales : une étape de vérification que la valeur H(U[r21) et/ou H(U[ri]) est égale à S1. une étape de délivrance d'une assertion d'authentification lorsque l'étape de 5 vérification précédente est positive. Ainsi, sans avoir fait référence au message, il est possible de vérifier la validité du triplet reçu. Selon un mode de réalisation particulier, le procédé comprend, pour ledit dispositif d'utilisateur, préalablement à ladite étape d'obtention d'un code d'authentification, une phase 10 de détermination d'un ensemble de paramètres de chiffrement, comprenant : une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la première clé privée (x), ladite clé privée étant un élément du groupe G ; une étape d'obtention de la deuxième clé privée (y), ladite clé privée étant un élément 15 du groupe G ; une étape de calcul, à partir de la première clé privée (x), d'une clé publique X telle que X est une exponentiation du générateur g par la clé privée x, X=gx ; une étape de calcul, à partir de la première clé privée (y), d'une clé publique Y telle que Y est une exponentiation du générateur g par la clé privée y, Y=gY. 20 Selon un mode de réalisation particulier, le procédé comprend, pour ledit terminal de communication du commerçant, préalablement à ladite étape d'obtention d'une première valeur de référence, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant : une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; 25 une étape d'obtention de la clé privée (z), ladite clé privée étant un élément du groupe G; une étape de calcul, à partir de la clé privée (z), d'une clé publique Z telle que Z est une exponentiation du générateur g par la clé privée z, Z=gz. Selon un mode de réalisation particulier : 30 l'étape d'obtention du code d'authentification .S1 met en oeuvre le calcul suivant : .S1 = H(m I I t), ou l l est l'opérateur de concaténation ; 3053549 6 l'étape d'obtention du premier composant de signature 52 met en oeuvre le calcul suivant : S2= (Mi it)L si ; l'étape d'obtention du deuxième composant de signature 53 met en oeuvre le calcul suivant : S3= (M 1 1 t)Zys1 5 Selon un mode de réalisation particulier : l'étape d'obtention de la première valeur de référence Ufrii met en oeuvre le calcul suivant : U frii = S2Xzsl ; l'étape d'obtention de la deuxième valeur de référence Ufry met en oeuvre le calcul suivant :U[r2]= s3y-zs1 . 10 Selon un autre aspect, il est également divulgué un dispositif d'utilisateur comprenant une unité de traitement général, une mémoire, dispositif comprenant une unité de traitement sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal de communication comprenant notamment une authentification d'une donnée, ledit dispositif d'utilisateur comprenant : 15 des moyens d'obtention, à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S1; des moyens d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S1, d'un premier composant de signature 52 ; 20 des moyens d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification Sl, d'un deuxième composant de signature S3, des moyens de transmission, au terminal de communication, du code 25 d'authentification Sl, et des deux composants de signature S2 et S3. Un tel dispositif d'utilisateur se présente généralement sous la forme d'un terminal de communication de type téléphone intelligent. Selon un autre aspect, il est également divulgué un terminal de commerçant comprenant une unité de traitement général, une mémoire, terminal caractérisé comprenant 30 une unité de traitement sécurisé et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un dispositif d'utilisateur 3053549 7 comprenant notamment une authentification d'une donnée, ledit terminal de commerçant comprenant : des moyens d'obtention, à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, 5 et du code d'authentification Si, d'une première valeur de référence, notée Ufrii; des moyens d'obtention, à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Si, d'une deuxième valeur de référence, notée Ufry ; des moyens de vérification que la première valeur de référence U[rii est égale à la 10 deuxième valeur de référence U [r21 ; et, lorsque les deux valeurs sont égales : des moyens de vérification que la valeur H(U[r21) et/ou H(U[rii) est égale à S1. des moyens de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive. Un tel terminal de commerçant peut se présenter sous la forme d'un terminal de type 15 smartphone ou tablette. Un tel terminal peut également se présenter sous la forme d'un terminal de paiement auquel on adjoint les moyens précédemment décrits. Selon une implémentation préférée, les différentes étapes des procédés selon l'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de 20 données d'un module relais selon l'invention et étant conçu pour commander l'exécution des différentes étapes des procédés. En conséquence, l'invention vise aussi un programme, susceptible d'être exécuté par un ordinateur ou par un processeur de données, ce programme comportant des instructions pour commander l'exécution des étapes d'un procédé tel que mentionné ci-dessus. 25 Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un processeur de données, 30 et comportant des instructions d'un programme tel que mentionné ci-dessus. 3053549 8 Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy disc) ou un disque 5 dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. 10 Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un mode de réalisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce 15 document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en oeuvre une fonction ou un ensemble de 20 fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). 25 De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique 30 pour l'exécution d'un micrologiciel (firmware), etc. 3053549 9 Chaque composante du système précédemment décrit met bien entendu en oeuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en oeuvre de l'invention. 5 4. Dessins D'autres caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante d'un mode de réalisation préférentiel, donné à titre de simple exemple illustratif et non limitatif, et des dessins annexés, parmi lesquels : la figure 1 présente un synoptique de la technique proposée pour la création 10 d'éléments de signature à destination du terminal du commerçant ; la figure 2 présente un synoptique de la technique proposée pour la vérification d'éléments de signature reçus d'un dispositif d'utilisateur ; la figure 3 représente schématiquement un terminal de communication du commerçant selon la présente ; 15 la figure 4 décrit représente schématiquement un dispositif d'utilisateur selon la présente. 5. Description 5.1. Principe général Comme explicité précédemment, le principe général de l'invention consiste 20 notamment à intégrer, en plus d'un schéma de "défi-réponse" (ou à la place de ce schéma), une ou plusieurs opérations additionnelles. La présente invention propose une modification protocolaire qui permet de résister aux attaques des terminaux comprenant des logiciels malveillants. À titre secondaire, cette modification protocolaire permet également de protéger les terminaux des commerçants eux-mêmes contre des réponses non sollicités provenant 25 d'autres appareils (c'est à dire des appareils malveillants qui tenteraient d'attaquer un terminal de commerçant authentique). Cette modification protocolaire offrant ainsi une couche supplémentaire de protection contre d'autres types d'attaques (DoS "Denial of Seryerce", Concurency Attacks - attaques par concurrence d'accès aux ressources-). Classiquement, lorsqu'une transaction de paiement est effectuée entre un terminal 30 d'un commerçant et un dispositif d'utilisateur, un processus de type "challenge/response" ("défi/réponse" en français) est mis en oeuvre afin que le terminal du commerçant identifie 3053549 10 (authentifie) le dispositif d'utilisateur (et vice versa) par l'intermédiaire de l'échange d'un message m. La présente technique permet de se passer d'un schéma de ce type. Il n'est ainsi plus nécessaire de réaliser un processus de type « défi réponse ». La technique mise en oeuvre n'est donc pas une technique de type « défi-réponse » (qui est un processus interactif) ; il ne 5 s'agit pas non plus d'une nouvelle signature (qui est vérifiable publiquement) ; il ne s'agit pas non plus d'un code d'authentification de message (qui n'est possible qu'en cas de partage d'une clé secrète). Plus particulièrement, l'approche retenue par la présente technique est de faire en sorte que le dispositif de l'utilisateur puisse prouver qu'il a légitimement signé le message 10 « m » (les données) à authentifier, sans pour autant avoir à transmettre ce message (le message peut par exemple être connu de part et d'autre : par le terminal du commerçant et par le dispositif d'utilisateur. Ainsi, au lieu de signer de manière traditionnelle le message et de le transmettre (c'est-à-dire de transmettre le message signé), on adopte une stratégie de transmission de preuve de signature de ce message (qui peut être complémentaire soit à la 15 transmission de ce message, soit au partage de la connaissance du message entre le terminal du commerçant et le dispositif d'utilisateur). On suppose que le terminal du commerçant n'est pas sécurisé en tant que tel (il s'agit d'un téléphone, d'une tablette ou d'un PC), mais qu'il dispose de ressources de sécurisation. Ces ressources de sécurisation peuvent par exemple prendre la forme d'un "secure element - 20 SE" (élément sécurisé en français), d'un "Trusted Execution Environment - TEE" (environnement d'exécution sécurisé en français) ou encore d'un autre composant matériel ou logiciel dédié. On suppose, pour les explications qui vont suivre, que l'application de paiement du terminal du commerçant s'appelle TPC, et qu'elle comprend un module de vérification (d'identification) appelé V (il s'agit par exemple d'un SE, d'un TEE ou plus généralement d'une 25 unité de traitement sécurisée, qui peut même être distante, c'est-à-dire non présente dans le terminal). On suppose également qu'il existe une application de paiement sur le dispositif d'utilisateur DU, et que le dispositif de l'utilisateur (DU) comprend un module de preuve (de confirmation d'identité) appelé P (il s'agit par exemple d'un SE, d'un TEE ou plus généralement d'une unité de traitement sécurisée). Dans un autre mode de réalisation, le dispositif 30 d'utilisateur peut être une carte de paiement classique, dans laquelle on a effectué des 3053549 11 modifications protocolaires et matérielles permettant de mettre en oeuvre la présente technique. D'une manière générale, la présente technique combine les principes de signatures de Schnorr et d'échange de clés Diffie-Hellman (pour l'hypothèse d'absence de solution 5 calculatoire). Toutefois, à la différence des signatures de Schnorr (qui comprend un couple de données), la technique mise en oeuvre utilise une signature comprenant un triplet de données. L'utilisation d'un tel triplet, en lieu et place d'un couple (tel que défini dans la signature de Schnorr) permet de de créer (de manière sécurisée) une restriction supplémentaire : seul un destinataire particulier peut vérifier la signature (à la différence des signatures de Schnorr qui 10 sont publiquement vérifiables). Par ailleurs, à la différence du procédé classique de Schnorr, la technique repose sur l'utilisation d'un couple de clé privées et d'un couple de clé publiques, qui est mis à la disposition du dispositif d'utilisateur (et/ou du module de preuve). On décrit, en relation avec les figures 1 et 2, la technique proposée authentifiant des 15 données entre un terminal de communication d'un commerçant et un dispositif d'utilisateur. Comme explicité précédemment, on suppose que V et P ont chacun, par leurs propres moyens, obtenus la connaissance des données à authentifier (le message m). Lors de la mise en oeuvre conjointe des applications de paiement TPC et DU, le procédé mis en oeuvre est le globalement le suivant : 20 le module P calcule (10), à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, un code d'authentification S1; le module P calcule (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z de V, d'une première clé privée x de P et du code d'authentification Sh un premier composant de signature S2 ; 25 le module P calcule (30), à partir du message m, de la donnée aléatoire t, de la clé publique de V, d'une deuxième clé privée de P et du code d'authentification Si, un deuxième composant de signature S3 ; le module P transmet (40), au terminal du commerçant (ou au module V), le code d'authentification S1, et les deux composants de signature 52 et S3. 30 Ces étapes, effectuées sur le dispositif d'utilisateur (ou le module P) sont mises en oeuvre sur la base d'une part de clés privées (deux) à disposition du dispositif d'utilisateur et 3053549 12 d'une clé publique du terminal du commerçant. Dans cet exemple, on suppose que m est connu de part et d'autre avant, et c'est juste l'aléa t qui est transmis, avec (S1, S2, S3) qui « signe » le message. La clé publique du terminal du commerçant est soit transmise par le terminal du 5 commerçant à l'initialisation de la transaction de paiement, soit obtenue, par exemple à partir d'une base de données, accessible depuis le dispositif d'utilisateur. La donnée aléatoire t est, quant à elle, unilatéralement choisie par le dispositif d'utilisateur. Il va de soi que cette clé publique devrait, selon les bonnes pratiques, être certifiée par une autorité reconnue. Toutefois cela n'est pas nécessaire au fonctionnement de l'invention, et n'est même pas utile 10 dans certaines applications. La clé publique utilisée pour le destinataire de la signature n'est pas nécessairement la clé publique du terminal commerçant. Ce pourrait être par exemple celle du processeur de paiement (le module V), le terminal ne faisant que relayer l'information. À partir des données reçues (Si, S2 et S3), le terminal du commerçant (ou le module V, ou un destinataire distant), va vérifier (en réalisant un calcul sur ces données) qu'elles sont 15 bien synonymes de la connaissance (par le dispositif d'utilisateur ou par P) du message m. Pour ce faire, le terminal du commerçant (ou le module V): calcule (50), à partir du premier composant de signature S2, de la clé publique X (correspondant à la clé privée x), de sa propre clé privée z, et du code d'authentification Si, une première valeur de référence, notée Ufrii 20 calcule (60), à partir du deuxième composant de signature S3, de la clé publique Y (correspondant à la clé privée y), de sa propre clé privée z, et du code d'authentification Si, une deuxième valeur de référence, notée U[,21; vérifie (70) que la première valeur de référence Ufrii est égale à la deuxième valeur de référence U[,21; et, lorsque les deux valeurs sont égales : 25 vérifie (80) que la valeur H(U[r21) est égale à S. Lorsque l'étape de vérification (80) est positive, le procédé délivre une assertion d'authentification. En fonction du résultat de cette vérification le procédé une étape de transmission (90), par le terminal de communication, d'une donnée de validation de transaction à un système de traitement de transaction de paiement (STTP). 30 Ainsi, lorsque les deux vérifications précédentes sont vraies, on en déduit que le dispositif d'utilisateur (ou le module P) connaît le message m. Pour mettre en oeuvre le 3053549 13 procédé tel que décrit précédemment, dans le cadre d'une opération de paiement intervenant entre le dispositif d'utilisateur et le terminal du commerçant, selon la présente, il n'est nécessaire de ne disposer (en commun) que deux éléments : la fonction de hachage H : cette fonction de hachage est utilisée par le module P pour 5 calculer le premier code d'authentification S1 et par le module V pour vérifier que le hachage de U [r21 est égal au premier code d'authentification SI ; Le module V et le module P partage donc la connaissance de cette fonction de Hachage ; des paires de {clés publiques ; clés privées} qui sont utilisées pour créer les éléments de signatures ; 10 le message m : le message m est déterminé par le terminal du commerçant et par le dispositif d'utilisateur ; À l'aide de la technique proposé, il n'est pas nécessaire que le dispositif d'utilisateur transmette la valeur de ce message m au terminal du commerçant : il suffit qu'il transmette la preuve qu'il en a connaissance. Comme le message m ne transite pas par le réseau, il ne peut 15 pas être intercepté et modifié. Il n'est donc pas possible de modifier les composantes de la transaction de paiement. Par ailleurs, à l'aide de cette technique, seul le terminal du commerçant (ou le module V) est en mesure de vérifier la validité des données transmises par le dispositif d'utilisateur (ou le module P). De plus, il n'est même pas nécessaire que le terminal du commerçant (ou le 20 module V), dispose du message m. En effet, dans la technique proposée, le message m n'est pas utilisé par le commerçant : seul le code d'authentification S1 est utilisé. Dès lors, le code d'authentification S1 peut être utilisé comme preuve de la validité de la transaction de paiement, sans qu'il soit nécessaire, pour le terminal du commerçant, d'avoir connaissance de ce message. Ainsi, le code d'authentification de message S1 peut, en fonction de mode de 25 réalisation, prendre la place des codes d'authentification traditionnellement utilisés dans les protocoles de paiement, et plus particulièrement dans les protocoles de paiement mis en oeuvre dans la cadre des spécifications EMV. On comprend, à lecture de ce qui précède, que les procédés mis en oeuvre tant dans le terminal du commerçant que dans le dispositif d'utilisateur, sont indépendants. On comprend également que le terminal du commerçant et le 30 dispositif d'utilisateur sont indépendant l'un de l'autre. Dès lors, il est possible de mettre en 3053549 14 oeuvre les procédés et dispositifs décrits dans un système qui comprendra un dispositif d'utilisateur et un terminal de commerçant effectuant une transaction de paiement. 5.2. Mode de réalisation Dans ce mode de réalisation purement illustratif, la technique proposée consiste, 5 notamment en une modification des signatures de Schnorr, adaptée pour deux utilisateurs (terminal du commerçant et dispositif d'utilisateur). La sécurité de la technique proposée est notamment basée sur l'hypothèse Décisionnelle Diffie-Heliman (DDH) qui est une hypothèse de dureté de calcul basée sur des groupes cycliques (« Decisional Diffie-Heliman assomption » en anglais). 10 Dans ce mode de réalisation, préalablement à la mise en oeuvre du protocole d'échange sécurisé, on suppose que deux phases d'installation ont été réalisées : une du côté du terminal du commerçant et une du côté du dispositif de l'utilisateur. En premier lieu, la technique proposée est mise en oeuvre en se basant sur un groupe G convenant à la problématique des signatures de Schnorr, avec un générateur g. 15 Un groupe de Schnorr est un sous-groupe de Zpx le groupe multiplicatif des entiers modulos p pour un nombre premier p. Pour générer un tel groupe, on génère p, q, et r tels que p=qr+1, avec p et q étant des nombres premiers. Pour obtenir le générateur g de ce groupe, on applique la méthode suivante : pour chaque entier h strictement supérieur à 1 et strictement inférieur à p : 20 - si hr E 1 (mod p) alors passer à l'entier suivant ; ^ sinon, la valeur g = hr (mod p) est un générateur sous-groupe de Zpx d'ordre a; Ce groupe possède une ainsi une taille donnée. La taille de ce groupe et ses autres paramètres sont typiquement déterminés préalablement. Dans un mode de réalisation 25 particulier, la taille du groupe G est de l'ordre de 21°24 (nombre 2 élevé à la puissance 1024) : cela signifie que la taille du nombre premier p est de l'ordre de 21024. Dans ce mode de réalisation, le groupe G et le générateur g correspondant ont fait l'objet d'un paramétrage préalable, tant dans le dispositif du client que dans le terminal du commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de 30 l'application de paiement du côté du commerçant ou de l'application de paiement du côté du 3053549 15 Dans d'autres modes de réalisation, ce paramétrage est réalisé lors de la transaction de paiement. Le terminal du commerçant et le dispositif d'utilisateur s'entendent sur les paramètres du groupe. Dans ce cas, compte tenu du fait que le groupe est renégocié à chaque transaction la taille de ce groupe peut être réduite, par exemple de moitié (2512) ou plus (2256). 5 5.2.1. Phase d'installation du côté du dispositif de l'utilisateur Le dispositif de l'utilisateur, qui est par exemple un terminal de communication de type smartphone, une tablette, est également équipé d'un SE ou d'un TEE (agissant comme une unité de traitement sécurisé). On rappelle que dans ce mode de réalisation, le client 10 souhaite régler avec son dispositif. Ce dispositif dispose donc des données nécessaires à la réalisation d'un paiement. Il peut s'agir, dans un mode de réalisation spécifique, de données de carte bancaire (nom du porteur, numéro de Carte PAN, date de validité, code de vérification). Il peut également d'agir d'autres données, en fonction des modes de réalisation. Dans le cadre de la présente technique, la phase d'installation consiste ainsi 15 notamment à déposer, dans le SE ou le TEE du dispositif de l'utilisateur (appelé également module P), les clés privées x et y utilisée pour construire les éléments de signatures. Cette installation peut typiquement être mise en oeuvre par l'installation d'une application de paiement, comme cela est le cas de l'application de paiement installée sur le terminal du commerçant. 20 Sur la base de ce groupe G et du générateur sélectionné g : le dispositif d'utilisateur (ou le module de preuve P) obtient ou génère une clé privée comprenant deux nombres entiers premiers (x,y) et, sur la base de cette clé privée, calcule une clé publique (X,Y), dans laquelle : X = gx ; Y = gY ; Ainsi, dans ce mode de réalisation, les deux nombres entiers premiers (x,y) constituent chacun une clé privée du dispositif d'utilisateur tandis que les deux nombres entiers X et Y constituent chacun la clé publique correspondant à ces deux clés privées. Dans ce mode de réalisation, les deux paires de clés privées/clé publiques ont fait 30 l'objet d'un paramétrage préalable dans le dispositif du client. Ce paramétrage préalable peut 25 a a 3053549 16 avoir été fait par exemple avant l'installation de l'application de paiement du côté du dispositif d'utilisateur. Dans d'autres modes de réalisation, la sélection de ces clés est réalisée lors de la transaction de paiement. Avant d'initier la transaction de paiement, le dispositif d'utilisateur 5 effectue le choix de ses couples {clés privées/clés publiques}, sur la base du groupe G et du générateur g. Lorsque l'ensemble des paramètres est négocié au moment de la transaction (Groupe G, générateur g, clés publiques et privées) les tailles de ces paramètres peuvent avantageusement être réduites, du fait de la relative unicité des paramètres en eux-mêmes : ils ne sont en effet utilisés que pour une transaction, ce qui limite de manière importante les 10 possibilités de fraude de la part d'un attaquant. Une possibilité avantageuse est d'installer ces clés (et paramètres de groupes) en même temps qu'une application bancaire : par exemple l'application bancaire du client. En effet, avec le développement des applications bancaires (application qui permettent de gérer ses comptes depuis un smartphone o une tablette), une solution intéressante, tant pour le 15 client que pour la banque, peut consister à disposer d'une application bancaire qui permette également de réaliser des paiements. Dans ce cas, les données nécessaires au paiement ne sont pas nécessairement des données de carte bancaire, mais peuvent être des données spécifiquement préparées par l'application bancaire de la banque, voire spécifiquement préparée, au moment du paiement, par l'établissement financier lui-même (c'est à dire par un 20 serveur auquel l'application bancaire du client est connectée). Pour effectuer un paiement, dans ce cas particulier, le client ouvre son application bancaire; sélectionne le fait qu'il souhaite effectuer un paiement; saisit un éventuel code confidentiel (ou s'authentifie par exemple par voie biométrique); et appose son dispositif sur le terminal du commerçant. L'application bancaire réagit aux requêtes du terminal du 25 commerçant (comme explicité dans la présente) et le paiement est effectué. Pour la banque, comme pour le client, les bénéfices sont réels, tant en termes de sécurité de la transaction (faite par l'application bancaire), qu'en termes de fidélisation du client (qui n'est plus obligé d'effectuer un paiement avec une application tierce, dont il n'a pas de garantie, par exemple au niveau de la sécurité et de la confidentialité des données transmises et traitées). 30 Pour la mise en oeuvre de cette technique, il importe que le terminal du commerçant ait connaissance des clés publiques X et Y : soit le dispositif d'utilisateur fournit ces clés lors de 3053549 17 la transaction, soit le terminal du commerçant est à même d'obtenir ces clés auprès d'un tiers de confiance. Dans ce dernier cas, selon la présente, le dispositif d'utilisateur dispose d'un identifiant unique (Uid), lequel est associé, auprès du tiers de confiance, au deux clés publiques X et Y. Lorsque le terminal du commerçant souhaite obtenir ces clés publiques, il 5 transmet, au tiers de confiance, une requête d'obtention des clés en se basant sur l'identifiant (Uid) du dispositif d'utilisateur. Préalablement à cette transmission, le dispositif d'utilisateur a transmis son identifiant unique au terminal du commerçant (par exemple lors de l'initialisation de la transaction). 5.2.2. Phase d'installation du côté du terminal du commerçant 10 Sur la base de ce groupe G et du générateur sélectionné g : le terminal du commerçant (ou le module de vérification V) obtient ou génère une clé privée z, (nombre premier entier aléatoire) et sur la base de cette clé privée, calcule une clé publique Z, telle que : Z = gz ; Dans ce mode de réalisation, la paire de clé privée/clé publique a fait l'objet d'un 15 paramétrage préalable dans le terminal du commerçant. Ce paramétrage préalable peut avoir été fait par exemple avant l'installation de l'application de paiement du côté du terminal du commerçant. Comme précédemment, dans d'autres modes de réalisation, la sélection de ces clés peut être réalisée lors de la transaction de paiement. 20 De même, comme précédemment, le dispositif d'utilisateur prend connaissance de la clé publique Z du terminal du commerçant. Soit le terminal du commerçant transmet cette clé directement au dispositif du client, soit le dispositif du client utilise un identifiant unique du terminal du commerçant (Cid) pour obtenir cette clé publique auprès d'un tiers de confiance. Dans un mode de réalisation spécifique, la phase d'installation est réalisée lors de 25 l'installation d'une application de paiement sur un terminal de communication (de type smartphone, tablette, ou ordinateur) du commerçant, ledit terminal de communication étant équipé d'un TEE et/ou d'un SE (également appelé module V). Ce mode de réalisation présente l'avantage de ne pas avoir à communiquer la clé privée z au terminal de communication en tant que tel : cette donnée n'est communiquée qu'au SE ou au TEE. Ainsi, on assure que le 30 terminal de communication (et surtout les éventuelles applications frauduleuse de ce terminal), ne puisse pas avoir accès à cette clé privée. 3053549 18 5.2.3. Déroulé de l'authentification Dans ce mode de réalisation, l'authentification est mise en oeuvre de la manière suivante : le module P effectue une transformation du message m, sous une forme numérique, 5 afin que ce message m corresponde à un élément du groupe G : pour ce faire, le message m est transformé en binaire (représentation binaire du message m) et la forme binaire est utilisée pour obtenir une forme numérique, la forme numérique correspondant à un élément du groupe G ; d'autres méthodes peuvent être envisageables en fonctions des applications ; 10 le module P sélectionne aléatoirement (ou pseudo aléatoirement) un élément t du groupe G; le module P calcule, à partir du message m, de la donnée aléatoire t et de la fonction de hachage H, un code d'authentification S1 selon la formule suivante : o S1 = H(m I I t), ou I I est l'opérateur de concaténation ; 15 le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique Z, de la première clé privée x de P et du code d'authentification SI, le premier composant de signature S2, selon la formule suivante : o S2 = (m//t)Zxs1 le module P calcule, à partir du message m, de la donnée aléatoire t, de la clé publique 20 Z, de la deuxième clé privée y de P et du code d'authentification SI, le deuxième composant de signature S3; o S3 = 011 i i tes1 le module P transmet, au terminal du commerçant (ou au module V), le code d'authentification SI, et les deux composants de signature S2 et 53. 25 Ainsi, le dispositif d'utilisateur n'a pas transmis le message m, ni même une version signée de celui-ci car ce dernier se trouve être concaténé avec un aléa (t), avant d'être haché pour produire Sl. Dès lors, un attaquant, qui intercepterait par exemple le code d'authentification SI, ne pourrait pas, à partir de celui-ci, inférer le contenu du message m. Les méthodes de calcul des valeurs 51, 52 et S3 utilisent x et y (qui sont privées et donc 30 connues du signataire seul, c'est-à-dire le dispositif d'utilisateur), et de Z (qui est la clé publique du destinataire, c'est-à-dire le terminal de paiement). Essentiellement, S2 et S3 sont 3053549 19 des quantités créées à partir de ces trois informations et du message m. L'exponentiation garantit la protection des clés privées, et la multiplication du message par la quantité exponentiée protège son contenu. De son côté, le terminal du commerçant reçoit les données Si, S2 et S3. Sur la base de 5 ces données, il va déterminer (avec un doute raisonnable), que ces données correspondent bien aux résultats de calculs effectués sur la base du message m. Pour ce faire, le terminal du commerçant met en oeuvre les étapes suivantes : calcule, à partir du premier composant de signature S2, de la clé publique X (correspondant à la clé privée x), de sa propre clé privée Z, et du code 10 d'authentification Si, une première valeur de référence, notée Ufrii O U[r1] = s2X zsl calcule, à partir du deuxième composant de signature S3, de la clé publique Y (correspondant à la clé privée y), de sa propre clé privée Z, et du code d'authentification Si, une deuxième valeur de référence, notée U[r21; 15 o U[r2] = s3y-zs1 vérifie que la première valeur de référence Ufrii est égale à la deuxième valeur de référence Ufry ; et, lorsque les deux valeurs sont égales : vérifie que la valeur H(U[r2]) est égale à Si. Si la valeur de H(U[r2]) est égale à Si, alors le terminal du commerçant dispose d'une 20 information d'une certitude suffisante pour estimer que le dispositif d'utilisateur est bien en possession du message m et que celui-ci est authentique. Dès lors, le terminal du commerçant peut terminer la transaction (par exemple il peut transmettre Si au système de paiement pour validation de la transaction). Explicité autrement, Le terminal du commerçant effectue les calculs suivants : 25 o Ufrii= s2X-zs1 = (m l It)ZA(x 51) X^(-z Si) = (m l l t)g^(z x 51) g^(- z x 51) = (m l lt) et u[r21 = s3y-zsi. _ O (m l It)ZA(y 51) Y"(-z 51) = 30 [m l l t)g"(yz 51) g^(-yz 51) = (m l lt) 3053549 20 Ainsi, l'authentification des données transmises, lors d'une opération de paiement, entre un terminal d'un commerçant et un dispositif d'utilisateur, en utilisant une communication en champs proche (NFC), permet de valider une transaction de manière 5 sécuritaire. 5.3. Autres caractéristiques et avantages On décrit, en relation avec la figure 3, un terminal de communication mis en oeuvre pour réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement. 10 Par exemple, le terminal de communication, faisant office de terminal de paiement, comprend une mémoire 31 comprenant notamment une mémoire tampon, une unité de traitement général 32, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 33, et une unité de traitement sécurisée 34 (notée V précédemment), pilotée par un programme d'ordinateur 35, ces unités de traitement mettant 15 en oeuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant. À l'initialisation, les instructions de code du programme d'ordinateur 35 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de traitement sécurisée 34. L'unité de traitement 34 reçoit en entrée au moins un code 20 d'authentification et deux éléments de signature. Le microprocesseur de l'unité de traitement sécurisée 34 met en oeuvre les étapes du procédé d'authentification, selon les instructions du programme d'ordinateur 35 pour fournir, à l'unité de traitement générale 32, une donnée représentative de validation de transaction et le cas échéant transmettre, à un système de traitement, une donnée de validation de transaction. L'unité de traitement générale 32 25 effectue un traitement de ces données pour les transmettre à un dispositif d'un client (par exemple un smartphone, une tablette) dans le cadre d'une transaction de paiement. Pour cela, le terminal de communication comprend, outre la mémoire tampon 31, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et des circuits de transmission de données entre les divers 30 composants du terminal de communication. 3053549 21 Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du terminal de communication. Selon un mode de réalisation particulier, ce dispositif met en oeuvre une application spécifique qui est en charge de la réalisation des transactions, cette application étant par exemple fournie par le fabricant du processeur en 5 question afin de permettre l'utilisation dudit processeur ou par un fournisseur de solution de paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur. Par ailleurs, le dispositif comprend en outre les moyens de communication en champs 10 proches, dits NFC et des moyens de transmission et de réception de données en provenance de réseaux de communications. Ces moyens se présentent également comme des interfaces de communications permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données. On décrit, en relation avec la figure 4, un dispositif d'utilisateur mis en oeuvre pour 15 réaliser une authentification de données dans le cadre d'un processus de paiement, selon le procédé décrit préalablement. Par exemple, le dispositif d'utilisateur comprend une mémoire 41 constituée d'une mémoire tampon, une unité de traitement général 42, équipée par exemple d'un microprocesseur, et pilotée par un programme d'ordinateur 43, et une unité de traitement 20 sécurisée 44 (notée P, précédemment), pilotée par un programme d'ordinateur 45, ces unités de traitement mettant en oeuvre le procédé d'authentification tels que décrit précédemment pour effectuer un paiement auprès du commerçant. À l'initialisation, les instructions de code du programme d'ordinateur 45 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur de l'unité de 25 traitement sécurisée 44. L'unité de traitement sécurisée 44 reçoit en entrée, un message m dont il est nécessaire de prouver la connaissance. Le microprocesseur de l'unité de traitement sécurisée 44 met en oeuvre les étapes du procédé d'authentification, selon les instructions du programme d'ordinateur 45 pour fournir, à l'unité de traitement générale 42, au moins un code d'authentification et deux éléments de signature à transmettre à un terminal de 30 commerçant. L'unité de traitement générale 42 effectue la transmission de ces données. 3053549 22 Pour cela, le dispositif d'utilisateur comprend, outre la mémoire tampon 41, des moyens de communications, tels que des modules de communication réseau, des moyens de transmission de donnée et des circuits de transmission de données entre les divers composants du dispositif d'utilisateur. 5 Ces moyens peuvent se présenter sous la forme d'un processeur particulier implémenté au sein du dispositif d'utilisateur. Selon un mode de réalisation particulier, ce dispositif met en oeuvre une application spécifique qui est en charge de la réalisation des transactions, cette application étant par exemple fournie par le fabricant du processeur en question afin de permettre l'utilisation dudit processeur ou par un fournisseur de solution de 10 paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend des moyens d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticité du processeur. Par ailleurs, le dispositif comprend en outre les moyens de communication en champs proches, dits NFC et des moyens de transmission et de réception de données en provenance 15 de réseaux de communications. Ces moyens se présentent également comme des interfaces de communications permettant d'échanger des données sur des réseaux de communication, des moyens d'interrogations et de mise à jour de base de données. 20 REVENDICATIONS1. Procédé d'authentification d'au moins une donnée, procédé mis en oeuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commerçant et un dispositif d'utilisateur, procédé du type comprenant l'authentification par le terminal de communication d'au moins un message m générée par le dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche, procédé caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur : une étape d'obtention (10), à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S1; une étape d'obtention (20), à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification Sl, d'un premier composant de signature S2 ; une étape d'obtention (30), à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification Sl, d'un deuxième composant de signature S3; une étape de transmission (40), au terminal de communication, du code d'authentification Sl, et des deux composants de signature S2 et S3. 2. Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, au sein du terminal de communication : une étape d'obtention (50), à partir du premier composant de signature S2, d'une clé publique X du dispositif d'utilisateur, d'une clé privée z du terminal de communication, et du code d'authentification Sl, d'une première valeur de référence, notée Ufrii; une étape d'obtention (60), à partir du deuxième composant de signature S3, d'une clé publique Y du dispositif d'utilisateur, de la clé privée z, et du code d'authentification Sl, d'une deuxième valeur de référence, notée U[r2]; une étape de vérification (70) que la première valeur de référence Ufrii est égale à la deuxième valeur de référence Ufry ; et, lorsque les deux valeurs sont égales : 3053549 24 une étape de vérification (80) que la valeur H(U[r21) et/ou H(1411) est égale à S.I. une étape de délivrance d'une assertion d'authentification lorsque l'étape de vérification précédente est positive. 5 3. Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, pour ledit dispositif d'utilisateur, préalablement à ladite étape d'obtention (10) d'un code d'authentification, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant : une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; 10 une étape d'obtention de la première clé privée (x), ladite clé privée étant un élément du groupe G ; une étape d'obtention de la deuxième clé privée (y), ladite clé privée étant un élément du groupe G ; une étape de calcul, à partir de la première clé privée (x), d'une clé publique X telle 15 que X est une exponentiation du générateur g par la clé privée x, X=gx ; une étape de calcul, à partir de la première clé privée (y), d'une clé publique Y telle que Y est une exponentiation du générateur g par la clé privée y, Y=gY. 4. Procédé d'authentification selon la revendication 2, caractérisé en ce qu'il comprend, 20 pour ledit terminal de communication du commerçant, préalablement à ladite étape d'obtention (50) d'une première valeur de référence, une phase de détermination d'un ensemble de paramètres de chiffrement, comprenant : une étape d'obtention d'un groupe de Schnor (G) et d'un générateur de ce groupe (g) ; une étape d'obtention de la clé privée (z), ladite clé privée étant un élément du groupe 25 G ; une étape de calcul, à partir de la clé privée (z), d'une clé publique Z telle que Z est une exponentiation du générateur g par la clé privée z, Z=gz. 5. Procédé d'authentification selon la revendication 3, caractérisé en ce que : 30 l'étape d'obtention (10) du code d'authentification .S1 met en oeuvre le calcul suivant : Sl= H(m I I t), ou l l est l'opérateur de concaténation ; 3053549 25 l'étape d'obtention (20) du premier composant de signature S2 met en oeuvre le calcul suivant : S2= On i i tesi ; l'étape d'obtention (30) du deuxième composant de signature S3 met en oeuvre le calcul suivant : S3= (In i i t)Zysi - 5 6. Procédé d'authentification selon la revendication 4, caractérisé en ce que : l'étape d'obtention (50) de la première valeur de référence Ufrii met en oeuvre le calcul suivant : U frii = S2Xzsl ; l'étape d'obtention (60) de la deuxième valeur de référence Ufry met en oeuvre le calcul suivant :U[r2]=3s y-zsi. 10 7. Dispositif d'utilisateur comprenant une unité de traitement générale, une mémoire, dispositif caractérisé en ce qu'il comprend une unité de traitement sécurisée et une mémoire sécurisée et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal de communication comprenant notamment une authentification d'une donnée, ledit Dispositif d'utilisateur comprenant : 15 des moyens d'obtention, à partir du message m, d'une donnée aléatoire t et d'une fonction de hachage H, d'un code d'authentification S1; des moyens d'obtention, à partir du message m, de la donnée aléatoire t, d'une clé publique Z du terminal de communication, d'une première clé privée x du dispositif d'utilisateur et du code d'authentification S1, d'un premier composant de signature S2 ; 20 des moyens d'obtention, à partir du message m, de la donnée aléatoire t, de la clé publique de Z du terminal de communication, d'une deuxième clé privée y du dispositif d'utilisateur et du code d'authentification Sl, d'un deuxième composant de signature S3 ; des moyens de transmission, au terminal de communication, du code 25 d'authentification Sl, et des deux composants de signature S2 et S3. 8. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou stocké sur un support lisible par ordinateur et/ou exécutable par un microprocesseur, caractérisé en ce qu'il comprend des instructions de code de programme pour l'exécution d'un procédé d'authentification selon la revendication 1, 30 lorsqu'il est exécuté sur un ordinateur.