CA3029152C - Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants - Google Patents

Abstract

L'invention se rapporte à un procédé d'authentification d'au moins une donnée, procédé mis en œuvre 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 la transmission par le terminal de communication d'au moins une donnée à signer au dispositif d'utilisateur, par l'intermédiaire d'une liaison de données sans fils en champs proche. Un tel procédé comprend : une étape d'obtention (10) de ladite donnée à signer (DaS); une étape d'obtention (20) d'un identifiant dudit terminal de communication (UiD); une étape signature (30), à l'aide d'une clé (K) dudit terminal de communication, de ladite donnée à signer (DaS) et dudit identifiant du terminal de communication (UiD), délivrant un couple de données signées (CDS); une étape de transmission (40) du couple de données signées (CDS) audit dispositif d'utilisateur; et une étape de réception (50), en provenance dudit dispositif d'utilisateur, d'une donnée chiffrée (DC), établissant l'authentification dudit couple de données signées.

Description

5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants. 1. Domaine [.'invention se rapporte au domaine de la securisation des donnees echangees par I'intermediaire d'un protocole de transmission de donnees sans contact. La technique se rapporte plus particulierement a la transmission de donnees de type NFC, dans laquelle on effectue une transmission entre un premier dispositif et un deuxieme dispositif separes d'une distance de I'ordre d'une dizaine de centimetre au plus. La technique ne s'applique pas et n'est pas destinee a s'appliquer dans Ie cadre de techniques de transmission de donnees de type WiFi, WiMax, LTE, dont les technologies de transmission sont differentes. 2. Art Anterieur De nombreux dispositifs de la vie quotidienne sont aptes a communiquer et a echanger des donnees entre eux. Une part croissante de dispositifs utilisent, pour ce faire, des protocoles d'echange de donnees dit "en champ proches" ou encore NFC. Parfois, ces techniques de transmission de donnees sont egalement appelees RFID. Cette appellation n'est pas correcte puisque NFC signifie communication en champ proche, tandis que RFID se rapporte a des moyens d'identification par frequence radio. Les deux utilisent des signaux radio pour toutes sortes de fins de reperage et de suivi, en remplagant parfois des codes a barres. Toutes deux utilisent des moyens de transmission de donnees a courte portee. Or, I'utilisation de ce type de technologic suscite encore des craintes et des interrogations de la part des utilisateurs. Nombreux sont ceux qui n'accordent pas ou peu confiance a ces technologies, plus particulierement lorsqu'il s'agit de les utiliser a des fins de traitement de donnees personnelles et/ou confidentielles. C'est par exemple Ie cas du paiement. Relativement recemment, des dispositifs de paiement sans contact ont fait leur apparition. II s'agit par exemple des cartes de paiement sans contact qui permettent d'effectuer un paiement (dont Ie montant est generalement plafonne) en apposant (ou en rapprochant) la carte de paiement d'un terminal de paiement compatible. II s'agit egalement des terminaux de communication, qui integrent egalement des "puces" sans contact : ces puces (egalement appelees "contactless chip") et qui offrent des capacites d'echange de donnees aux terminaux de communication, capacites qui peuvent etre utilisees pour effectuer des paiements, un peu comme si Ie terminal de communication imitait Ie comportement d'une5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 carte de paiement sans contact. De nombreuses rumeurs, souvent infondees, laissent entendre qu'une communication ou qu'un paiement realise sans contact serait peu sur. II est egalement souvent rapporte que les dispositifs seraient peu securises et qu'il serait possible de recuperer les donnees qui sont contenus dans ces dispositifs a I'insu de I'utilisateur. Bien que ces rumeurs soient souvent sans fondement, il existe cependant des risques lors de la transmission de donnees entre les dispositifs et notamment lors de la transmission de donnees de paiement. Les risques, cependant, ne proviennent pas de la technologic employee, en ellememe (NFC), mais generalement de I'utilisateur lui-meme. Ainsi par exemple, dans Ie cas d'un terminal de communication utilisant I'interface NFC pour effectuer un paiement, il est possible que I'utilisateur ait installe une application peu sure, voire une application malveillante, dont I'objectif est d'utiliser des donnees de paiement a des fins de fraudes. La situation est la meme du cote du terminal du commergant. Par exemple, dans Ie cadre d'une communication entre un dispositif d'utilisateur (un terminal de communication de type smartphone) et un terminal de paiement, notamment en utilisant des protocoles NFC pour Ie paiement, il est necessaire que Ie dispositif et Ie terminal authentifie des donnees. A cette fin, Ie dispositif met en oeuvre un protocole d'authentification avec Ie terminal (par exemple un terminal de paiement, une borne d'un marchand, ou tout autre dispositif approprie). Le terminal controle que la phase d'authentification a reussi et dans le cas contraire refuse la transaction ou declenche une alerte, ou met en oeuvre tout autre comportement juge approprie dans une telle situation. Dans les scenarios typiques, le terminal effectuant ces controles est, un dispositif securise (comme un terminal de paiement). II a ete congu pour prevenir la plupart des types possibles d'intrusion, tant materielles que logicielles. Mais si le terminal de paiement est un dispositif tiers (terminal de communication de type tablette, smartphone, ecran), alors la securite de ce terminal de communication (tiers) ne peut pas etre garantie, pas plus que I'origine des applications installees sur ce terminal (par le commergant lui-meme). Si le commergant n'est pas vigilant, il se peut que les applications installees sur ce terminal soient frauduleuses. On presente ci-apres un cas de dysfonctionnement possible, mis en oeuvre lors d'un paiement entre un terminal de communication et un dispositif d'utilisateur. On appelle "V" le5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 verificateur (par exemple Ie terminal ou I'appareil du marchand) et "P" Ie prouveur (dispositif de I'utilisateur : smartphone, tablette). Les protocoles de paiement travaillent habituellement de la fagon suivante, au cours de la transaction : V demande a P de signer numeriquement des donnees. P signe les donnees, conformement a ce qui est demande par V et transmet les donnees signees a V. Cette signature est verifiee par V, et si elle est correcte, alors la transaction est acceptee et transferee dans Ie reste de la chame de traitement des paiements. Une telle procedure est appelee un "defi-reponse" (challenge response) et est utilisee par exemple par les specifications EMV. Le probleme auquel II est propose de remedier est Ie suivant : si V fonctionne sur un dispositif non securise (i.e. un terminal de type tablette, PC ou autre, auquel on a adjoint des fonctionnalites de paiement) qui est infecte par un logiciel malveillant (installe par le commergant ou par un tiers mal intentionne), 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). Ceci peut etre realise par exemple lorsque le terminal du commergant force le dispositif de I'utilisateur a signer des messages arbitraires. Le dispositif de I'utilisateur, en position « d'esclave », est alors oblige de signer ces donnees. Le logiciel malveillant installe sur le terminal du commergant se sert ensuite de ces donnees signees pour creer des transactions frauduleuses. Cest le paradoxe de ces traitements cryptographiques : II est certain que les traitements realises sont bons (car ils mettent en oeuvre des traitements cryptographiques), en revanche, ('utilisation qui est faite des resultats de ces traitements cryptographiques ne peut pas etre garantie. 3. Resume L'invention ne pose pas ces problemes de Part anterieur. Plus particulierement, I'invention apporte une solution simple a la problematique prealablement identifiee. Cette solution est entierement compatible avec les dispositifs materiels existants. Plus particulierement, II est propose un procede d'authentification d'au moins une donnee, procede mis en oeuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un commergant et un dispositif d'utilisateur, procede du type comprenant la transmission par le terminal de communication d'au moins une donnee a signer5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 au dispositif d'utilisateur, par I'intermediaire d'une liaison de donnees sans fils en champs proche. Un tel procede comprend : une etape d'obtention de ladite donnee a signer ; une etape d'obtention d'un identifiant dudit terminal de communication ; une etape signature, a l'aide d'une cle dudit terminal de communication, de ladite donnee a signer et dudit identifiant du terminal de communication, delivrant un couple de donnees signees ; une etape de transmission du couple de donnees signees audit dispositif d'utilisateur ; et une etape de reception, en provenance dudit dispositif d'utilisateur, d'une donnee chiffree, etablissant l'authentification dudit couple de donnees signees. Ainsi, en signant les donnees qu'il transmet au dispositif d'utilisateur, Ie terminal de communications permet de certifier I'origine de ces donnees et done permet au dispositif d'utilisateur de verifier I'origine des donnees qu'il regoit. Selon une caracteristique particuliere, Ie procede comprend posterieurement a ladite etape de reception d'une donnee chiffree en en provenance dudit dispositif d'utilisateur : une etape de dechiffrage, par une unite de traitement securise dudit terminal de communication, de ladite donnee chiffree, delivrant une donnee signee ; une etape de verification de la validite de ladite donnee signee par rapport a une donnee de reference. Ainsi, Ie procede permet au terminal du commer^ant de verifier qu'il n'est pas luimeme victime d'une tentative de fraude de la part du dispositif d'utilisateur; On dispose ainsi d'un renforcement bilateral de la securite de la transaction en champs proche. Selon une caracteristique particuliere, ladite donnee de reference est egale a ladite donnee a signer. Ainsi, il y a une uniformite des donnees qui sont echangees entre Ie terminal de communication et Ie dispositif d'utilisateur : comme Ie terminal de communication possede deja la donnee a signer, il est aise de verifier que la donnee qu'il re^oit de la part du dispositif d'utilisateur est correcte.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 D PCT/EP2017/066362 Selon une caracteristique particuliere, que posterieurement a I'etape de verification de la validite de ladite donnee signee par rapport a la donnee de reference delivre un resultat positif, Ie procede comprend une etape de transmission, par Ie terminal de communication, de ladite donnee signee a un systeme de traitement de transaction de paiement. Ainsi, lorsque l'authentification des donnees est proprement realisee, la transaction de paiement est mise en oeuvre. Selon un mode de realisation particulier, ladite etape de signature comprend : une etape de transmission, de ladite donnee a signer et/ou dudit identifiant du terminal de communication, a une unite de traitement securise dudit terminal de communication, par une unite de traitement general dudit terminal de communication ; une etape de signature, par ladite unite de traitement securisee, a I'aide de ladite cle du terminal de communication, de ladite donnee a signer et/ou dudit identifiant du terminal de communication, delivrant respectivement une donnee signee et/ou un identifiant signe ; une etape de transmission, de ladite une donnee signee et/ou de I'identifiant signe a ladite une unite de traitement general dudit terminal de communication. On securise ainsi la production des donnees qui sont transmises au dispositif d'utilisateur en empechant que ces donnees ne soient forgees par d'autres applications presentes sur Ie terminal de communication. Selon un mode de realisation particulier ladite cle du terminal de communication est une cle privee appartenant a un couple {cle privee;cle publique}. Ainsi, on assure une securite plus grande en utilisant une architecture a cle publique. Selon un mode de realisation particulier, Ie procede comprend, au sein du dispositif d'utilisateur, entre I'etape de transmission du couple de donnees signees et I'etape de reception de la donnee chiffree : une etape de reception du couple de donnees signees par Ie dispositif d'utilisateur ; une etape de verification, a I'aide d'une cle, de la signature des donnees du couple de donnees signees; et lorsque la signature des donnees du couple de donnees signees est correcte :5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 une etape de signature, a l'aide d'une cle de signature tk, d'au moins une des donnees precedemment resues de la part du terminal du commer^ant, delivrant une donnee signee ; une etape de chiffrement de ladite donnee signee a l'aide d'une cle de chiffrement delivrant la donnee chiffree ; une etape de transmission de la donnee chiffree audit terminal du commer^ant. Selon un autre aspect, I'invention se rapporte egalement a un terminal de communication comprenant une unite de traitement generale, une memoire. Un tel terminal comprend une unite de traitement securisee et une memoire securisee et au moins un circuit reconfigurable de traitement de transaction de paiement avec un terminal d'utilisateur comprenant notamment une authentification d'une donnee, ledit terminal de communication comprenant : des moyens d'obtention d'une donnee a signer ; des moyens d'obtention d'un identifiant dudit terminal de communication ; des moyens de signature, a l'aide d'une cle dudit terminal de communication, de ladite donnee a signer et dudit identifiant du terminal de communication, delivrant un couple de donnees signees ; des moyens de transmission du couple de donnees signees audit dispositif d'utilisateur ; et des moyens de reception, en provenance dudit dispositif d'utilisateur, d'une donnee chiffree, etablissant l'authentification dudit couple de donnees signees. Selon un autre aspect, la technique se rapporte egalement a un terminal d'utilisateur qui comprend des moyens de mise en oeuvre du procede tel que decrit precedemment. Selon une implementation preferee, les differentes etapes des procedes selon I'invention sont mises en oeuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinees a etre executees par un processeur de donnees d'un module relais selon I'invention et etant con^u pour commander I'execution des differentes etapes des procedes. En consequence, I'invention vise aussi un programme, susceptible d'etre execute par un ordinateur ou par un processeur de donnees, ce programme comportant des instructions pour commander I'execution des etapes d'un procede tel que mentionne ci-dessus.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 Ce programme peut utiliser n'importe quel langage de programmation, et etre sous la forme de code source, code objet, ou de code intermediaire entre code source et code objet, tel que dans une forme partiellement compilee, ou dans n'importe quelle autre forme souhaitable. L'invention vise aussi un support d'informations lisible par un processeur de donnees, et comportant des instructions d'un programme tel que mentionne ci-dessus. Le support d'informations peut etre n'importe quelle entite 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 microelectronique, ou encore un moyen d'enregistrement magnetique, par exemple une disquette (floppy disc) ou un disque dur. D'autre part, le support d'informations peut etre un support transmissible tel qu'un signal electrique ou optique, qui peut etre achemine via un cable electrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut etre en particulier telecharge sur un reseau de type Internet. Alternativement, le support d'informations peut etre un circuit integre dans lequel le programme est incorpore, le circuit etant adapte pour executer ou pour etre utilise dans I'execution du procede en question. Selon un mode de realisation, l'invention est mise en oeuvre au moyen de composants logiciels et/ou materiels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien a un composant logiciel, qu'a un composant materiel ou a un ensemble de composants materiels et logiciels. Un composant logiciel correspond a un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de maniere plus generale a tout element d'un programme ou d'un logiciel apte a mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est decrit ci-dessous pour le module concerne. Un tel composant logiciel est execute par un processeur de donnees d'une entite physique (terminal, serveur, passerelle, routeur, etc.) et est susceptible d'acceder aux ressources materielles de cette entite physique (memoires, supports d'enregistrement, bus de communication, cartes electroniques d'entrees/sorties, interfaces utilisateur, etc.).5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 ° PCT/EP2017/066362 De la meme maniere, un composant materiel correspond a tout element d'un ensemble materiel (ou hardware) apte a mettre en oeuvre une fonction ou un ensemble de fonctions, selon ce qui est decrit ci-dessous pour Ie module concerne. II peut s'agir d'un composant materiel programmable ou avec processeur integre pour I'execution de logiciel, par exemple un circuit integre, une carte a puce, une carte a memoire, une carte electronique pour I'execution d'un micrologiciel (firmware), etc. Chaque composante du systeme precedemment decrit met bien entendu en oeuvre ses propres modules logiciels. Les differents modes de realisation mentionnes ci-dessus sont combinables entre eux pour la mise en oeuvre de I'invention. 4. Dessins D'autres caracteristiques et avantages de I'invention apparaitront plus clairement a la lecture de la description suivante d'un mode de realisation preferentiel, donne a titre de simple exemple illustratif et non limitatif, et des dessins annexes, parmi lesquels : la figure 1 presente un synoptique de la technique proposee authentifiant des donnees transmises entre un terminal de communication d'un commergant et un dispositif d'utilisateur ; la figure 2 presente un synoptique de la technique proposee realisant une signature de donnees au sein du terminal de communication du commergant ; la figure 3 represente schematiquement un terminal de communication du commergant selon la presente ; la figure 4 decrit represente schematiquement un dispositif d'utilisateur selon la presente. 5. Description 5.1. Principe general Comme explicite precedemment, Ie principe general de I'invention consiste notamment a integrer, dans Ie schema de "defi-reponse", une ou plusieurs contraintes additionnelles. La presente invention propose une modification protocolaire qui permet de resister aux attaques des terminaux comprenant des logiciels malveillants. A titre secondaire, cette modification protocolaire permet egalement de proteger les terminaux des commergants5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 eux-memes contre des reponses non sollicites provenant d'autres appareils (c'est a dire des appareils malveillants qui tenteraient d'attaquer un terminal de commergant authentique). Cette modification protocolaire offrant ainsi une couche supplementaire de protection contre d'autres types d'attaques (DoS "Deny of Serverce", Concurency Attacks - attaques par concurrence d'acces aux ressources-). Ainsi, lorsqu'une transaction de paiement est effectuee entre un terminal d'un commergant et un dispositif d'utilisateur, un processus de type "challenge/response" ("defi/reponse" en frangais) est mis en oeuvre afin que Ie terminal du commergant identifie (authentifie) Ie dispositif d'utilisateur (et vice versa). On suppose que Ie terminal du commergant n'est pas securise en tant que tel (il s'agit d'un telephone, d'une tablette ou d'un PC), mais qu'il dispose de ressources de securisation. Ces ressources de securisation peuvent par exemple prendre la forme d'un "secure element - SE" (element securise en frangais), d'un "Trusted Execution Environment - TEE" (environnement d'execution securise en frangais) ou encore d'un autre composant materiel ou logiciel dedie. On suppose, pour les explications qui vont suivre, que I'application de paiement du terminal du commergant s'appelle TPC, et qu'elle comprend un module de verification (d'identification) appele V (il s'agit par exemple d'un SE, d'un TEE ou plus generalement d'une unite de traitement securisee). On suppose egalement qu'il existe une application de paiement sur Ie dispositif d'utilisateur DU, et que Ie dispositif de I'utilisateur (DU) comprend un module de preuve (de confirmation d'identite) appele P (il s'agit par exemple d'un SE, d'un TEE ou plus generalement d'une unite de traitement securisee). Dans un autre mode de realisation, Ie dispositif d'utilisateur peut etre une carte de paiement classique, dans laquelle on a effectue des modifications protocolaires et materielles permettant de mettre en oeuvre la presente technique. Lors de la mise en oeuvre conjointe des applications de paiement TPC et DU, Ie procede mis en oeuvre est globalement Ie suivant : les donnees d'authentification qui sont transmises par V a P (c'est a dire les donnees de "challenge") sont signees numeriquement par l/lui-meme. la reponse transmise par P est chiffree, se sorte que seul V puisse en verifier la validite. Afin permettre une telle mise en oeuvre, il suffit de doter V d'une cle (publique) qui est connue de P.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 10 PCT/EP2017/066362 La logique sous-jacente a ce procede est que P ignore purement et simplement les demandes de signature qui ne proviennent pas directement de la partie securisee de V (i.e. par exemple depuis Ie « secure element » auquel V a acces ou depuis I'environnement de confiance auquel V a acces) : on suppose en effet que seule cette architecture est en mesure de realiser une signature numerique valide du challenge (defi) avant sa transmission a P. II existe une raison pour laquelle cette supposition est faite : les inventeurs ont eu I'idee de disposer la cle (par exemple publique) de signature (de I/) directement accessible par les ressources de securisation du terminal du commergant. Dans un mode de realisation, par exemple, les ressources de securisation conservent cette cle et elles ne la rendent accessible qu'a un nombre limite d'application de confiance (par exemple une seule : I'application de paiement installee sur Ie terminal du commergant). Par ailleurs, Ie « secure element » effectue lui-meme les operations de chiffrement pour Ie compte de I'application de paiement du terminal du commergant. Ainsi, dans la premiere etape, avant la transmission du defi ("challenge") au terminal de communication de I'utilisateur, Ie defi est signe par les ressources de securisation en utilisant la cle de V (la cle de I'application de paiement). Selon une caracteristique particuliere, cette cle est une cle publique. De plus, Ie fait que la reponse qui est transmise par P soit chiffree permet de se premunir de situations dans lesquelles un fraudeur detecte et rejoue des traces d'authentification valides (attaque par rejeu). L'attaque peut etre mise en oeuvre tant par une application malveillante installee sur l'appareil du marchand que par une application malveillante installee sur l'appareil du client. On decrit, en relation avec la figure 1, la technique proposee authentifiant des donnees transmises entre un terminal de communication d'un commergant et un dispositif d'utilisateur. On rappelle que I'on souhaite s'assurer que Ie dispositif d'utilisateur ne signe que des donnees qui proviennent legitimement du terminal de communication (faisant office de terminal de paiement) du commergant. La technique comprend ainsi : une etape d'obtention (10) de la donnee a signer (DaS) ; une etape d'obtention (20) d'un identifiant du terminal de communication (UiD) ; une etape signature (30), a I'aide d'une cle (K) du terminal de communication, de la donnee a signer (DaS) et de I'identifiant du terminal de communication (UiD), delivrant un couple de donnees signees (CDS) ;5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 une etape de transmission (40) du couple de donnees signees (CDS) au dispositif d'utilisateur ; et une etape de reception (50), en provenance du dispositif d'utilisateur, d'une donnee chiffree (DC), etablissant l'authentification du couple de donnees signees. En effet, selon la presente divulgation, Ie fait de recevoir une donnee chiffree en provenance du dispositif d'utilisateur enterine Ie fait que Ie couple de donnees signees a bien ete authentifie par Ie dispositif d'utilisateur. Ceci est pratique car il n'est pas necessaire de transmettre un accuse de reception ou une confirmation specifique de l'authentification. On reduit ainsi les echanges. En cas d'absence de reponse de la part du dispositif d'utilisateur, il est possible de deduire que les donnees transmises sont erronees (erreur de reception des donnees transmises par exemple). De son cote, Ie dispositif d'utilisateur verifie la signature des donnees transmises et ne transmet aucune reponse en cas d'absence d'authentification. Si Ie dispositif d'utilisateur repond, alors Ie procede se poursuit par une verification des donnees resues du dispositif d'utilisateur et il comprend : une etape de dechiffrage (60), par I'unite de traitement securise du terminal de communication, de la donnee chiffree (DC), delivrant une donnee signee (DS) ; une etape de verification (70) de la validite de la donnee signee (DS) par rapport a une donnee de reference (DR) ; une etape de transmission (80), par Ie terminal de communication, de la donnee signee (DS) a un systeme de traitement de transaction de paiement (STTP). Ces trois dernieres etapes permettent au terminal du commer^ant de ne pas etre dupe par des donnees « rejouees » arbitrairement par un dispositif d'utilisateur qui serait lui-meme frauduleux. Ainsi, la solution procuree possede I'avantage de proteger Ie dispositif de I'utilisateur (et I'utilisateur lui-meme) contre des demandes de signatures frauduleuses et de proteger Ie marchand contre de tentatives d'usurpation resues de la part du dispositif de I'utilisateur. L'avantage est done double du fait de la protection bilaterale. En fonction des modes de realisation, les cles utilisees pour la signature et Ie chiffrement peuvent soit etre des couples cles publiques/privees ou des cles symetriques servant a la fois au chiffrement et au dechiffrement.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 On decrit, en relation avec la figure 2, la technique proposee realisant une signature de donnees au sein du terminal de communication du commergant. Cette technique comprend : une etape de transmission (301), de ladite donnee a signer (DaS) et/ou dudit identifiant du terminal de communication (UiD), a une unite de traitement securise (UTS) dudit terminal de communication, par une unite de traitement general (UTG) dudit terminal de communication; une etape de signature (302), par ladite unite de traitement securisee, a I'aide de ladite cle du terminal de communication (K), de ladite donnee a signer (Das) et/ou dudit identifiant (UiD) du terminal de communication, delivrant respectivement une donnee signee (DS) et/ou un identifiant signe (UiDs) ; une etape de transmission (303), de ladite une donnee signee (DS) et/ou de I'identifiant signe (UiDs) a ladite une unite de traitement general dudit terminal de communication. 5.2. Description d'un mode de realisation Dans ce mode de realisation purement illustratif on suppose, pour plus de simplicity, que I'on utilise des mecanismes de signature et de chiffrement de type RSA (tant du cote du terminal du commergant que du dispositif de I'utilisateur). Dans ce mode de realisation, prealablement a la mise en oeuvre du protocole d'echange securise, on suppose que deux phases d'installation ont ete realisees : une du cote du terminal du commergant et une du cote du dispositif de I'utilisateur. 5.2.1. Phase d'installation du cote du terminal du commergant Le terminal du commergant est dote d'une cle privee sk. Cette dotation peut etre mise en oeuvre a n'importe quel moment. On suppose que cette cle privee sk est generee selon des techniques anterieures connues et qu'elle est placee au sein d'une ressource securisee du terminal du commergant. Idealement, cette cle privee est placee au sein d'un TEE (agissant comme une unite de traitement securisee) du terminal du commergant. On dispose egalement, pour le terminal du commergant, d'un identificateur unique (uid) qui est genere et signe (par exemple par I'operateur de I'application de paiement). L'application de paiement est egalement installee sur le terminal du commergant. Ces materiels (application de paiement, cle privee sk et identificateur unique uid) peuvent astucieusement etre installes en meme5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 temps sur Ie terminal du commergant, par I'intermediaire d'un processus d'installation securise (qui peut etre mis en oeuvre soit en ligne, soit sur site par un technicien agree, par exemple). En dernier lieu, la cle publique pk (correspondant a la cle privee sk) est mise a disposition dans une base de donnee, avec I'identifiant unique uid, afin de former un couple {cle publique pk; identifiant unique uid}. Le couple {pk; uid} fait I'objet d'une signature (par exemple par I'operateur de I'application de paiement si c'est lui qui a signe I'identifiant unique uid). Dans un mode de realisation specifique, la phase d'installation est realisee lors de I'installation d'une application de paiement sur un terminal de communication (de type smartphone, tablette, ou ordinateur) du commergant, ledit terminal de communication etant equipe d'un TEE et/ou d'un SE (egalement appele module V). Ce mode de realisation presente I'avantage de ne pas avoir a communiquer la cle privee sk au terminal de communication en tant que tel : cette donnee n'est communiquee qu'au SE ou au TEE. Ainsi, on assure que le terminal de communication (et surtout les eventuelles applications frauduleuse de ce terminal), ne puisse pas avoir acces a cette cle privee. 5.2.2. Phase d'installation du cote du dispositif de I'utilisateur Le dispositif de I'utilisateur, qui est par exemple un terminal de communication de type smartphone, une tablette, est egalement equipe d'un SE ou d'un TEE (agissant comme une unite de traitement securise). On rappelle que dans ce mode de realisation, le client souhaite regler avec son dispositif. Ce dispositif dispose done des donnees necessaires a la realisation d'un paiement. II peut s'agir, dans un mode de realisation specifique, de donnees de carte bancaire (nom du porteur, numero de Carte PAN, date de validite, code de verification). II peut egalement d'agir d'autres donnees, en fonction des modes de realisation. Dans le cadre de la presente technique, la phase d'installation consiste a deposer, dans le SE ou le TEE du dispositif de I'utilisateur (appele egalement module P), la cle de signature tk, qui est utilisee pour effectuer une signature des donnees signees (data et uid) transmises par le terminal du commergant, apres que le dispositif d'utilisateur ait verifie la validite des signatures apposees par le terminal du commergant. Cette installation peut typiquement etre mise en oeuvre par I'installation d'une application de paiement, comme cela est le cas de I'application de paiement installee sur le terminal du commergant.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 Une possibilite avantageuse est d'installer cette cle de signature en meme temps qu'une application bancaire : par exemple ('application bancaire du client. En effet, avec Ie developpement des applications bancaires (application qui permettent de gerer ses comptes depuis un smartphone o une tablette), une solution interessante, tant pour Ie client que pour la banque, peut consister a disposer d'une application bancaire qui permette egalement de realiser des paiements. Dans ce cas, les donnees necessaires au paiement ne sont pas necessairement des donnees de carte bancaire, mais peuvent etre des donnees specifiquement preparees par I'application bancaire de la banque, voire specifiquement preparee, au moment du paiement, par I'etablissement financier lui-meme (c'est a dire par un serveur auquel I'application bancaire du client est connectee). Pour effectuer un paiement, dans ce cas particulier, Ie client ouvre son application bancaire; selectionne Ie fait qu'il souhaite effectuer un paiement; saisit un eventuel code confidentiel (ou s'authentifie par exemple par voie biometrique); et appose son dispositif sur Ie terminal du commerfant. I'application bancaire reagit aux requetes du terminal du commerfant (comme explicite dans la presente) et Ie paiement est effectue. Pour la banque, comme pour Ie client, les benefices sont reels, tant en termes de securite de la transaction (faite par I'application bancaire), qu'en termes de fidelisation du client (qui n'est plus oblige d'effectuer un paiement avec une application tierce, dont il n'a pas de garantie, par exemple au niveau de la securite et de la confidentiality des donnees transmises et traitees). 5.2.3. Deroule de I'echange de donnees d'authentification Dans ce mode de realisation, I'authentification est mise en oeuvre de la maniere suivante : Le terminal du commenjant (ou Ie module IZ) transmet Ie couple {[uid]Sk, [data]sk} au dispositif de I'utilisateur (ou au module P); le couple de donnees {[uid]sk, [data]sk} comprend [uid]sk qui est I'identifiant unique signe avec la cle sk et des donnees [data]sk egalement signees avec la cle sk; alternativement, pour raccourcir le temps de traitement, le couple peut directement signe (une seule signature a la place de deux signatures) ; le dispositif de I'utilisateur (ou le module P) utilise I'identifiant unique uid pour obtenir la cle publique pk; par exemple, il telecharge cette cle publique sur un serveur dedie5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 ou encore, il recherche cette cle dans une base de donnees interne (par exemple un fichier texte ou un fichier xml) fourni par l'application de paiement ; Ie dispositif de I'utilisateur (ou Ie module P) utilise la cle publique pk pour verifier la validite de la signature de uid et de data; en cas d'erreur sur I'une ou I'autre de ces signatures (par exemple I'uid en clair n'est pas I'uid possede par Ie client), alors Ie client stoppe Ie processus (et ne repond pas au terminal du commergant); lorsque les deux signatures sont correctes (et que I'on peut en deduire qu'elles ont ete realisees par Ie terminal du commergant), Ie dispositif de I'utilisateur poursuit Ie traitement en signant les donnees [data] avec la cle tk et en chiffrant ces donnees signees avec la cle publique du terminal du commergant pk: Encpk([data]tk); puis il transmet ces donnees au terminal du commergant; Ie terminal du commergant receptionne les donnees en provenance du dispositif de I'utilisateur, puis dechiffre ces donnees a I'aide de sa cle privee sk, et verifie la signature des donnees. Si la signature des donnees est incorrecte, alors Ie processus est stoppe; dans Ie cas contraire, la signature est transmise au reseau de traitement des paiements. Ainsi, l'authentification des donnees transmises, lors d'une operation de paiement, entre un terminal d'un commergant et un dispositif d'utilisateur, en utilisant une communication en champs proche (NFC), permet de valider une transaction de maniere securitaire. 5.3. Autres caracteristiques et avantages On decrit, en relation avec la figure 3, un terminal de communication mis en oeuvre pour realiser une authentification de donnees dans Ie cadre d'un processus de paiement, selon Ie procede decrit prealablement. Par exemple, Ie terminal de communication, faisant office de terminal de paiement, comprend une memoire 31 comprenant notamment une memoire tampon, une unite de traitement general 32, equipee par exemple d'un microprocesseur, et pilotee par un programme d'ordinateur 33, et une unite de traitement securisee 34 (notee V precedemment), pilotee par un programme d'ordinateur 35, ces unites de traitement mettant en oeuvre Ie procede d'authentification tels que decrit precedemment pour effectuer un paiement aupres du commergant.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 A ('initialisation, les instructions de code du programme d'ordinateur 35 sont par exemple chargees dans une memoire avant d'etre executees par Ie processeur de I'unite de traitement securisee 34. L'unite de traitement 34 re$oit en entree au moins une donnee a authentifier. Le microprocesseur de I'unite de traitement securisee 34 met en oeuvre les etapes du procede d'authentification, selon les instructions du programme d'ordinateur 35 pour fournir, a I'unite de traitement generale 32, une donnee signee et le cas echeant une donnee representative de I'identifiant du terminal de communication (elle aussi signee). L'unite de traitement generale 32 effectue un traitement de ces donnees pour les transmettre a 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 memoire tampon 31, des moyens de communications, tels que des modules de communication reseau, des moyens de transmission de donnee et des circuits de transmission de donnees entre les divers composants du terminal de communication. Ces moyens peuvent se presenter sous la forme d'un processeur particulier implements au sein du terminal de communication. Selon un mode de realisation particulier, ce dispositif met en oeuvre une application specifique qui est en charge de la realisation des transactions, cette application etant par exemple fournie par le fabricant du processeur en question afin de permettre I'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'authenticite 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 reception de donnees en provenance de reseaux de communications. Ces moyens se presentent egalement comme des interfaces de communications permettant d'echanger des donnees sur des reseaux de communication, des moyens d'interrogations et de mise a jour de base de donnees. On decrit, en relation avec la figure 4, un dispositif d'utilisateur mis en oeuvre pour realiser une authentification de donnees dans le cadre d'un processus de paiement, selon le procede decrit prealablement.5 10 15 20 25 30 CA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 Par exemple, Ie dispositif d'utilisateur comprend une memoire 41 constituee d'une memoire tampon, une unite de traitement general 42, equipee par exemple d'un microprocesseur, et pilotee par un programme d'ordinateur 43, et une unite de traitement securisee 44 (notee P, precedemment), pilotee par un programme d'ordinateur 45, ces unites de traitement mettant en oeuvre Ie procede d'authentification tels que decrit precedemment pour effectuer un paiement aupres du commergant. A ('initialisation, les instructions de code du programme d'ordinateur 45 sont par exemple chargees dans une memoire avant d'etre executees par Ie processeur de l'unite de traitement securisee 44. L'unite de traitement securisee 44 regoit en entree, en provenance de I'unite de traitement generale, au moins une donnee a authentifier (donnee signee par Ie terminal de communication). Le microprocesseur de I'unite de traitement securisee 44 met en oeuvre les etapes du procede d'authentification, selon les instructions du programme d'ordinateur 45 pour fournir, a I'unite de traitement generale 42, au moins une donnee non signee. L'unite de traitement generale 42 effectue un traitement de ces donnees pour d'une part comparer des donnees de reference et les donnees issues du retrait des signatures puis, si ces donnees sont correctes, transmettre au moins une d'entre elle a l'unite de traitement securisee pour effectuer une signature de cette donnees avec une cle de signature et chiffrer cette nouvelle donnee signee avec une cle du terminal de communication. L'unite de traitement securisee transmet cette donnee a l'unite de traitement generale qui la transmet a nouveau les transmettre au terminal de communication (par exemple un smartphone, une tablette) d'un commergant. Pour cela, le dispositif d'utilisateur comprend, outre la memoire tampon 41, des moyens de communications, tels que des modules de communication reseau, des moyens de transmission de donnee et des circuits de transmission de donnees entre les divers composants du dispositif d'utilisateur. Ces moyens peuvent se presenter sous la forme d'un processeur particulier implemente au sein du dispositif d'utilisateur. Selon un mode de realisation particulier, ce dispositif met en oeuvre une application specifique qui est en charge de la realisation des transactions, cette application etant par exemple fournie par le fabricant du processeur en question afin de permettre ('utilisation dudit processeur ou par un fournisseur de solution de paiement pour des terminaux "ouverts". Pour ce faire, le processeur comprend des moyensCA 03029152 2018-12-21 WO 2018/002349 PCT/EP2017/066362 d'identification uniques. Ces moyens d'identification uniques permettent d'assurer l'authenticite du processeur. Par ailleurs, Ie dispositif comprend en outre les moyens de communication en champs proches, dits NFC et des moyens de transmission et de reception de donnees en provenance 5 de reseaux de communications. Ces moyens se presentent egalement comme des interfaces de communications permettant d'echanger des donnees sur des reseaux de communication, des moyens d'interrogations et de mise a jour de base de donnees. 10

Claims (3)

19 303432234.1 Revendications 1. Procédé d'authentification d'au moins une donnée, procédé mis en œuvre lors d'une transaction de paiement intervenant entre un terminal de communication d'un 5 commerçant et un dispositif d'utilisateur, procédé du type comprenant la transmission par le terminal de communication d'au moins une donnée à signer au 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 : - une étape d'obtention de ladite donnée à signer ; 10 - une étape d'obtention d'un identifiant dudit terminal de communication ; - une étape de signature, au sein d'une unité de traitement sécurisé dudit terminal de communication, à l'aide d'une clé privée appartenant à un couple dudit terminal de communication, de ladite donnée à signer et dudit identifiant du terminal de communication, délivrant un couple de données signées, cette étape de signature 15 comprenant : - une étape de transmission de ladite donnée à signer et dudit identifiant du terminal de communication, à ladite unité de traitement sécurisé dudit terminal de communication, par une unité de traitement général dudit terminal de communication ; 20 - une étape de signature, par ladite unité de traitement sécurisée, à l'aide de ladite clé privée du terminal de communication, de ladite donnée à signer et dudit identifiant du terminal de communication, délivrant respectivement une donnée signée et un identifiant signé ; - une étape de transmission de ladite une donnée signée et de l'identifiant signé 25 à ladite une unité de traitement général dudit terminal de communication, - une étape de transmission du couple de données signées audit dispositif d'utilisateur ; - une étape de réception, en provenance dudit dispositif d'utilisateur, d'une donnée chiffrée, établissant l'authentification dudit couple de données signées ; - une étape de déchiffrement, par une unité de traitement sécurisé dudit terminal de 30 communication, de ladite donnée chiffrée, délivrant une donnée signée ; CA 3029152 Date reçue / Received date 2024-07-0420 303432234.1 - une étape de vérification de la validité de ladite donnée signée par rapport à une donnée de référence, ladite donnée de référence étant égale à ladite donnée à signer ; et - lorsque l’étape de vérification délivre un résultat positif, une étape de transmission, 5 par le terminal de communication, de ladite donnée signée à un système de traitement de transaction de paiement.

2. Procédé d'authentification selon la revendication 1, caractérisé en ce qu'il comprend, au sein du dispositif d'utilisateur, entre l'étape de transmission du couple de données 10 signées et l'étape de réception de la donnée chiffrée : - une étape de réception du couple de données signées par le dispositif d'utilisateur ; - une étape de vérification, à l'aide d'une clé, de la signature des données du couple de données signées ; et lorsque la signature des données du couple de données signées est correcte : 15 - une étape de signature, à l'aide d'une clé de signature, d'au moins une des données précédemment reçues de la part du terminal du commerçant, délivrant une donnée signée ; - une étape de chiffrement de ladite donnée signée à l'aide d'une clé de chiffrement délivrant la donnée chiffrée; 20 - une étape de transmission de la donnée chiffrée audit terminal du commerçant.

3. Terminal de communication comprenant une unité de traitement générale, une mémoire, terminal 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 25 transaction de paiement avec un terminal d'utilisateur comprenant notamment une authentification d'une donnée, ledit terminal de communication comprenant : - des moyens d'obtention d'une donnée à signer ; - des moyens d'obtention d'un identifiant dudit terminal de communication ; - des moyens de signature, au sein d'une unité de traitement sécurisé dudit terminal de 30 communication, à l'aide d'une clé privée appartenant à un couple dudit terminal de CA 3029152 Date reçue / Received date 2024-07-0421 303432234.1 communication, de ladite donnée à signer et dudit identifiant du terminal de communication, délivrant un couple de données signées, ces moyens comprenant : - des moyens de transmission, de ladite donnée à signer et dudit identifiant du terminal de communication, à ladite unité de traitement sécurisé dudit 5 terminal de communication, par une unité de traitement général dudit terminal de communication; - des moyens de signature, par ladite unité de traitement sécurisée, à l'aide de ladite clé du terminal de communication, de ladite donnée à signer et dudit identifiant du terminal de communication, délivrant respectivement une 10 donnée signée et un identifiant signé; _ des moyens de transmission, par ladite unité de traitement sécurisée, de ladite une donnée signée et de l'identifiant signé à ladite une unité de traitement général dudit terminal de communication; - des moyens de transmission du couple de données signées audit dispositif 15 d'utilisateur ; - des moyens de réception, en provenance dudit dispositif d'utilisateur, d'une donnée chiffrée, établissant l'authentification dudit couple de données signées ; - des moyens de déchiffrement, par une unité de traitement sécurisé dudit terminal de communication, de ladite donnée chiffrée, délivrant une donnée signée; 20 - des moyens de vérification de la validité de ladite donnée signée par rapport à une donnée de référence, ladite donnée de référence étant égale à ladite donnée à signer ; et - des moyens de transmission, par le terminal de communication, de ladite donnée signée à un système de traitement de transaction de paiement. 25 4. Produit programme d'ordinateur stocké sur un support lisible par ordinateur comprenant des instructions de code de programme qui, lorsqu'elles sont exécutées sur un ordinateur mettent en œuvre le procédé selon l’une des revendications 1 et 2. CA 3029152 Date reçue / Received date 2024-07-04