FR3000823A1

FR3000823A1 - Procede de securisation d'une transaction, par exemple bancaire, au sein d'un systeme, par exemple sans contact, systeme et carte a puce correspondants

Info

Publication number: FR3000823A1
Application number: FR1350069A
Authority: FR
Inventors: Olivier Rousseau; Olivier Rol
Original assignee: STMicroelectronics SA
Current assignee: STMicroelectronics SA
Priority date: 2013-01-04
Filing date: 2013-01-04
Publication date: 2014-07-11

Abstract

Dans une application particulière, on stocke dans le dispositif sans contact (WP), par exemple un téléphone NFC, une donnée image (INFM) de la donnée à protéger (Id), par exemple le numéro de carte bancaire. Cette donnée image transmise en clair à la place de l'identifiant est alors inexploitable par un tiers. Le serveur bancaire récupère l'identifiant à partir de la donnée image et par exemple d'une table de correspondance (TB) stockée de façon sécurisée dans le serveur (SV2).

Description

Procédé de sécurisation d'une transaction, par exemple bancaire, au sein d'un système, par exemple sans contact, système et carte à puce correspondants L'invention concerne la communication, par exemple sans fil, entre un dispositif, par exemple sans contact, et un lecteur, par exemple sans contact, et plus particulièrement la sécurisation de transactions bancaires entre un dispositif sans contact, par exemple un téléphone ou une carte à puce NFC, et un lecteur NFC, effectuées conformément au protocole EMV. La communication champ proche, plus connue par l'homme du métier sous la dénomination anglosaxonne NFC (« Near Field Communication ») est une technologie de connectivité sans fil qui permet une communication sur une courte distance, par exemple 10 cm, entre des dispositifs électroniques, comme par exemple des téléphones ou des cartes à puce sans contact, et des lecteurs. La technologie NFC est particulièrement adaptée pour connecter tout type de dispositif utilisateur et permet des communications rapides et faciles.

Un dispositif sans contact est un dispositif capable d'échanger des informations via une antenne avec un autre dispositif sans contact selon un protocole de communication sans contact. Un dispositif NFC, qui est un dispositif sans contact, est un dispositif compatible avec la technologie NFC.

La technologie NFC est une plate-forme technologique ouverte normalisée dans la norme ISO/IEC 18092 et ISO/IEC 21481 mais incorpore de nombreuses normes déjà existantes comme par exemple les protocoles type A et type B définis dans la norme IS0-14443 qui peuvent être des protocoles de communication utilisables dans la technologie NFC. Outre sa fonction classique de téléphone, un téléphone mobile cellulaire peut être utilisé (s'il est équipé de moyens spécifiques) pour échanger des informations avec un autre dispositif sans contact, par exemple un lecteur sans contact, en utilisant un protocole de communication sans contact. Ceci permet d'échanger des informations entre le lecteur sans contact et des éléments sécurisés situés dans le téléphone mobile. De nombreuses applications sont ainsi possibles comme la billetterie mobile dans les transports publics (le téléphone mobile se comporte comme un ticket de transport) ou bien le paiement mobile (le téléphone mobile se comporte comme une carte de paiement). Par ailleurs, Europay Mastercard Visa, abrégé par le sigle EMV, est un standard international de sécurité des cartes de paiement du type carte à puce initié par le consortium EMVCo. La majeure partie, voire l'intégralité des cartes bancaires à puce sont conformes au standard EMV de même que la majeure partie voire l'ensemble du parc des terminaux de paiement électroniques. Les différents livres regroupant les spécifications du standard EMV, en particulier la version 4.3 de novembre 2011, sont disponibles auprès du consortium EMVCo. Par ailleurs, des spécifications, intitulées « EMV Contactless Specifications for Payment Systems » et comportant dans la version 2.2 de juin 2012 disponible auprès du consortium EMVCo, quatre livres, ont trait notamment au protocole de communication sans contact utilisé pour effectuer des transactions bancaires entre deux dispositifs sans contact, et conforme à la norme EMV. Le protocole de communication pour la norme EMV sans contact est ainsi basé sur le protocole décrit dans la norme ISO/IEC 14443. Lors d'une transaction bancaire effectuée conformément au protocole EMV entre un téléphone sans contact ou une carte à puce sans contact et un lecteur, certaines données comme par exemple le numéro de carte bancaire, communément désigné par l'homme du métier sous l'acronyme anglosaxon de PAN (« Personal Account Number ») et défini dans la norme ISO 7812, le nom du titulaire, et la date d'expiration de la carte, sont, au début de ladite transaction, transmis en clair avec une signature depuis le téléphone ou la carte à puce vers le lecteur. Le lecteur vérifie la signature puis la transaction se poursuit, en général par une demande d'autorisation auprès de la banque du titulaire du compte. Il y a là une faille de sécurité. En effet, alors que le terminal vérifie la signature, le téléphone ou le dispositif sans contact qui communique avec le lecteur, ne vérifie pas l'authenticité du terminal de paiement. Par conséquent, un tiers mal intentionné muni d'un lecteur sans contact, peut aisément obtenir les coordonnées bancaires du détenteur du téléphone ou de la carte à puce sans contact, pour les utiliser par la suite frauduleusement, par exemple en effectuant des paiements sur internet. Par ailleurs, même si le lecteur est un terminal de paiement authentique, les coordonnées bancaires, et notamment le numéro de carte bancaire (PAN) circulent en clair sur le canal de communication sans fil au début de la transaction, et peuvent par conséquent être interceptés avec les mêmes conséquences frauduleuses potentielles. Il existe donc un besoin pour sécuriser de telles transactions bancaires. Selon un mode de mise en oeuvre et de réalisation, il est proposé un procédé et un système permettant de répondre à ce besoin, et qui prévoit de ne pas intervenir sur le lien NFC proprement dit ou sur le protocole EMV mais sur le stockage d'informations dans le dispositif sans contact destiné à communiquer avec un lecteur, de façon à stocker une donnée image de la donnée à protéger qui, même si elle est interceptée lors de son transit en clair, sera inexploitable par un tiers malveillant. Ensuite, la véritable donnée, qui est stockée dans un serveur sécurisé, par exemple dans une banque, sera récupérée par exemple à partir d'une table de concordance entre des données image et des données véritables. Et, l'élaboration de cette donnée image est faite en amont préalablement à toute transaction, et à l'extérieur du dispositif sans contact dans lequel elle est destinée à être stockée. De ce fait, selon ce mode de mise en oeuvre, non seulement il n'est nul besoin de modifier les protocoles NFC et EMV mais cette solution ne nécessite aucune modification structurelle et/ou logicielle des dispositifs sans contact et des lecteurs. Selon un aspect, il est donc proposé un procédé de sécurisation d'une transaction bancaire effectuée conformément au protocole EMV entre un dispositif sans contact, par exemple un dispositif NFC, et un serveur bancaire par l'intermédiaire d'un lecteur sans contact, par exemple un lecteur NFC, relié audit serveur bancaire et capable de communiquer avec le dispositif sans contact sur un canal de communication sans fil, ladite transaction bancaire devant prendre en compte un identifiant associé de façon biunivoque au dispositif sans contact ; cet identifiant comprend par exemple un numéro de carte bancaire (numéro PAN). Selon cet aspect, le procédé comprend préalablement à ladite transaction une élaboration d'une information image différente dudit identifiant et associée de façon biunivoque audit identifiant, et un stockage de cette information image dans une première mémoire du dispositif sans contact, et une mise à disposition du serveur d'éléments de récupération permettant de récupérer un identifiant à partir d'une information image associée.

Par ailleurs, toujours selon cet aspect, lors de ladite transaction, le procédé comprend une transmission au lecteur de ladite information image sur le canal de communication sans fil dans un champ de données dédié audit identifiant conformément au protocole EMV, une transmission de ladite information image depuis le lecteur vers le serveur, une récupération par le serveur de l'identifiant à partir de ladite information image et desdits éléments de récupération, et une poursuite de la transaction avec ledit identifiant, l'identifiant n'étant jamais transmis sur le canal de communication. Selon un mode de mise en oeuvre, la mise à disposition desdits éléments comprend un stockage dans le serveur d'une table de correspondance entre différents identifiants associés à différents dispositifs sans contact et les informations image correspondantes. Il serait également possible, dans le cas où la donnée image résulte d'un cryptage au moins partiel de l'identifiant, que les éléments de récupération comprennent alors l'algorithme de décryptage et une ou des clés de cryptage associées. Il est par ailleurs préférable que le procédé comprenne en outre, lors de ladite transaction, une transmission d'une indication indiquant que les données transmises dans ledit champ de données dédié sont représentatives d'une information image, le serveur détectant alors ladite indication. En effet, dans le cas où tous les dispositifs sans contact ne stockent pas de données image des données à protéger, la transmission de ladite indication permet au serveur de différencier une donnée image reçue d'un identifiant. Cette indication peut comporter un bit de la donnée image ou encore par exemple le numéro de série du lecteur. D'une façon générale, ledit identifiant est associé d'une façon biunivoque au dispositif sans contact, par exemple à l'application bancaire contenue dans le téléphone mobile cellulaire ou bien à la carte à puce proprement dite. En général, cet identifiant correspond à un numéro de carte bancaire. Cela étant, les données transmises en clair sur le canal de communication sans fil comportent, outre le numéro de carte bancaire, le nom du titulaire du compte et la date d'expiration de cette carte. Aussi, on pourrait également envisager que l'identifiant comprenne outre le numéro de carte bancaire, le nom du titulaire et/ou la date d'expiration, ou encore une combinaison du numéro de carte bancaire avec le nom et/ou la date d'expiration et/ou d'autres données.

Quoi qu'il en soit, ladite information image a de préférence le même format qu'un identifiant, ce qui permet en particulier de ne pas perturber le logiciel de traitement du lecteur. Ainsi, par exemple, lorsque l'identifiant comporte un en-tête de données, par exemple un code de réseau bancaire et un code banque, suivi d'un bloc de données représentatives d'un numéro de compte bancaire suivi d'un nombre de Luhn correspondant aux données de l'en-tête et dudit bloc, ladite information image comporte alors le même en-tête de données suivi d'un bloc de données image suivi d'un nombre de Luhn correspondant aux données de l'en-tête et aux données image. Le dispositif sans contact peut être un appareil de communication sans fil, par exemple un téléphone mobile cellulaire, équipé de moyens de communication sans contact mettant en oeuvre une application bancaire, ledit appareil de communication sans fil étant émule en mode carte. Le dispositif sans contact peut être aussi une carte à puce exclusivement sans contact.

En variante, le dispositif sans contact peut être une carte à puce à la fois à contacts et sans contact, comportant l'identifiant figurant, par exemple de façon sérigraphiée, sur une face de la carte, ladite carte comprenant des moyens de communication sans contact comportant ladite première mémoire accessible sur requête du lecteur, ainsi qu'une deuxième mémoire non accessible par le lecteur ; on stocke alors l'identifiant dans la deuxième mémoire et l'information image correspondante dans la première mémoire. Ainsi, une telle carte peut être utilisée de façon classique avec un lecteur à contact, celui-ci utilisant l'identifiant stocké dans la deuxième mémoire, ou bien avec un lecteur NFC par exemple, l'information image étant alors transmise à la place de l'identifiant. Selon un autre aspect, il est proposé un système comprenant un dispositif sans contact, un lecteur sans contact capable de dialoguer avec le dispositif sans contact sur un canal de communication sans fil lors d'une transaction bancaire effectuée conformément au protocole EMV et devant prendre en compte un identifiant associé de façon biunivoque au dispositif sans contact, un serveur relié au lecteur ; le dispositif comprend également une première mémoire stockant une information image différente dudit identifiant et associée de façon biunivoque audit identifiant, le dispositif étant configuré pour transmettre au lecteur lors de la ligne de transaction, ladite information image sur le canal de communication sans fil dans un champ de données dédié audit identifiant conformément au protocole EMV ; le lecteur comprend par ailleurs des moyens de traitement-lecteur configurés pour transmettre au serveur une information image reçue du dispositif, le serveur ayant accès à des élément de récupération permettant de récupérer un identifiant à partir d'une information image associée, le serveur comportant en outre des moyens de traitement-serveur configurés pour récupérer un identifiant à partir d'une information image et desdits éléments de récupération et pour poursuivre ladite transaction avec ledit identifiant, l'identifiant n'étant jamais destiné à être transmis sur le canal de communication sans fil. Selon un mode de réalisation, le serveur comprend une mémoire-serveur contenant une table de correspondance entre différents identifiants associés à différents dispositifs sans contact et les informations images correspondantes, ladite table formant lesdits éléments de récupération. Selon un mode de réalisation, le dispositif est en outre configuré pour, lors de ladite transaction, transmettre une indication indiquant que les données transmises dans ledit champ de données dédié sont représentatives d'une information image et les moyens de traitement-serveur sont configurés pour détecter ladite indication. Selon un autre aspect, il est proposé un dispositif sans contact, capable de communiquer avec un lecteur sans contact sur un canal de communication sans fil lors d'une transaction bancaire effectuée conformément au protocole EMV et devant prendre en compte un identifiant associé de façon biunivoque au dispositif sans contact, le dispositif comprenant des moyens de communication sans contact comportant une première mémoire stockant une information image différente dudit identifiant et associée de façon biunivoque audit identifiant, les moyens de communication sans contact étant configurés pour, sur requête, transmettre ladite information image sur le canal de communication sans fil dans un champ de données dédié audit identifiant conformément au protocole EMV. D'autres avantages et caractéristiques de l' invention apparaîtront à l'examen de la description détaillée de modes de mise en oeuvre et de réalisation, nullement limitatifs, et des dessins annexés sur lesquels : les figures 1 à 8 illustrent schématiquement différents modes de mise en oeuvre et de réalisation d'un procédé, d'un système et d'un dispositif sans contact selon l'invention. Sur la figure 1, la référence Id désigne un identifiant protéger, par exemple un numéro de carte bancaire. On élabore (étape 10) une information image INFM associée de façon biunivoque à cet identifiant. A titre d'exemple, lorsque l'identifiant Id est un numéro de carte bancaire classique tel que celui illustré sur la figure 2, l'information image INFM a le même format qu'un numéro de carte bancaire.

Plus précisément, sur la figure 2, l'identifiant Id, par exemple le numéro de carte bancaire (numéro PAN), comporte un en-tête ENT de six digits numériques permettant d'identifier le réseau bancaire (Visa, Mastercard, ...) auquel appartient ce numéro, ainsi que les identifiants de la banque qui a émis ce numéro.

Cet en-tête ENT est suivi d'un bloc de données BLD comportant au maximum 12 digits numériques et correspondant au numéro de compte bancaire du titulaire de la carte. Enfin, le dernier digit numérique est un nombre de Luhn NL1. Ce nombre de Luhn, obtenu par un algorithme classique et bien connu de l'homme du métier, à partir des digits numériques précédents, permet d'effectuer une première validation des digits numériques de l'en-tête ENT et du bloc de données BLD. Dans l'exemple décrit ici, seul le bloc BLD est modifié en un bloc de données image BLDI dans l'information image INFM. En effet, l'en-tête ENT est conservé de façon à pouvoir rediriger l'information INFM vers la banque du titulaire du compte. Par ailleurs, l'information INFM comporte également à la fin un nombre de Luhn NL2 obtenu à partir des digits numériques de l'en-tête ENT et des digits numériques du bloc de données image BLDI.

Plusieurs possibilités existent pour obtenir le bloc BLDI à partir du bloc BLD. On peut utiliser par exemple une fonction de hachage ou alors un algorithme de cryptage, par exemple symétrique, tel que l'algorithme AES sur 128 bits.

En variante, même si l'en-tête ENT n'est pas modifié, il peut être utilisé dans le calcul du bloc BLDI. Comme on va le voir plus en détails maintenant, cette information image INFM va être stockée dans un dispositif sans contact destiné à communiquer avec un lecteur sans contact et cette information image INFM sera communiquée dans le champ de données dédié à l'identifiant Id, ce dernier n'étant jamais transmis sur le canal de communication sans fil. Le dispositif sans contact peut être par exemple un téléphone mobile cellulaire compatible avec la technologie NFC ou bien une carte à puce sans contact. On suppose dans un premier temps que le dispositif sans contact est un téléphone mobile cellulaire possédant des moyens de communication sans contact MCM et dont un exemple d'architecture, conforme aux spécifications EMV mobile (sans contact), est illustré sur la figure 3. Sur cette figure, la référence WP désigne un appareil de communication sans fil compatible avec la technologie NFC, par exemple un téléphone mobile cellulaire NFC. Les moyens de communication sans contact MCM du téléphone WP comportent un élément sans contact ME, par exemple un contrôleur NFC, qui est responsable de la communication sans fil, par exemple une communication radiofréquence, avec un lecteur radiofréquence externe RDR par l'intermédiaire d'une antenne ANT1. Le protocole de communication est par exemple celui basé sur le protocole décrit dans la norme ISO/IEC 14443 1-4. Dans l'exemple décrit ici, les moyens MCM comportent par ailleurs deux éléments auxiliaires sécurisés (« Secure element », en langue anglaise) SE1 et 5E2 connectés au contrôleur NFC ME.

Un élément sécurisé est par exemple un élément configuré pour contenir des informations sécurisées ou protégées, par exemple des informations bancaires, des informations relatives à l'abonnement téléphonique.....

A titre d'exemple, l'élément sécurisé SE1 contient par exemple des applications radiofréquence RF compatibles avec la norme ISO/IEC 14443 exécutables en mode d'émulation carte, par exemples des applications bancaires ou de billetterie mobile. Le deuxième élément sécurisé SE2 est par exemple une carte du type UICC contenant les données de souscription au réseau téléphonique (applications SIM et USIM). On rappelle ici que les lettres UICC, telles que définies dans la norme ETSI TR 102 216 V3.00 (2003-09) désignent une carte à puce qui est conforme aux spécifications écrites et mise à jour par le projet ETSI de plateforme carte à puce (ETSI Smart Card Platform Project). Bien entendu, le téléphone WP est équipé d'une autre antenne ANT2 dans le cadre de sa fonction téléphonique normale. Les moyens MCM du téléphone WP comportent également un processeur MPR configuré pour gérer l'élément SE2 (UICC), le contrôleur NFC ME ainsi que les commandes d'entrée de l'utilisateur et la communication sur le réseau de téléphonie mobile. Dans l'exemple décrit ici, l'élément sécurisé SE1 qui contient l'application bancaire, est équipé d'une première mémoire MM1 destinée à stocker l'information image INFM associée de façon biunivoque à l'identifiant Id. Chaque élément sécurisé SE1, SE2 est connecté au contrôleur NFC ME à travers un lien SWP. Un lien SWP est un lien adapté pour supporter le protocole SWP (Single Wire Protocole).

Le protocole SWP est un protocole de communication point à point, orienté bits, entre un élément sécurisé et un élément sans contact et est spécifié dans la norme ETSI TS 102 613, par exemple la version V7.7.0 (octobre 2009).

Plus précisément, comme illustré sur la figure 4, le contrôleur NFC ME est le maître tandis que l'élément sécurisé SE est un esclave. Le maître et l'esclave sont mutuellement connectés par l'intermédiaire du lien SWP référencé LK.

Comme décrit dans la norme ETSI TS 102 613, le principe du protocole SWP est basé sur une transmission d'informations numériques dans un mode totalement bidirectionnel (Full Duplex Mode). Le signal 51 du maître vers l'esclave est transmis par une modulation numérique (L ou H) dans le domaine « tension », tandis que le signal S2 de l'esclave vers le maître est transmis par une modulation numérique (L ou H) dans le domaine « courant ». Quand le maître envoie S1 à l'état H, alors l'esclave peut tirer un courant (état H) ou non (état L) et transmet ainsi S2. En codant 51 avec une modulation de largeur d'impulsion, il est alors possible de transmettre un signal d'horloge ainsi que des données dans le mode « Full Duplex ». Comme pour l'élément sécurisé SE1, l'élément UICC est aussi connecté au contrôleur NFC par un lien SWP utilisant une interface HCI (Host Controller Interface) telle que décrite dans la norme ETSI TS 102 613 et ETSI TS 102 622. La figure 5 illustre un exemple de lien physique entre le contrôleur ME et l'UICC. Plus précisément, comme illustré sur cette figure et expliqué dans la norme ETSI TS 102 613, le contact C6 de l'UICC est connecté au port SWIO de l'élément sans contact ME pour la transmission des signaux 51 et S2. Comme illustré sur la figure 6, l'application bancaire, l'information image INFM, ainsi que les autres données relatives à l'application comme par exemple le nom de l'utilisateur, la date d'expiration, diverses clés de chiffrement ainsi que des seuils de paiement sont chargés dans l'élément sécurisé SE1 (étape 60). Ce chargement s'effectue de façon classique et connue en soi via l'opérateur téléphonique par le biais du réseau mobile cellulaire via l'antenne ANT2. La transmission est cryptée et les données reçues sont décryptées dans le téléphone.

On se réfère maintenant plus particulièrement à la figure 7 pour décrire un mode de réalisation d'un système SYS permettant une sécurisation d'une transaction bancaire. Dans le cadre d'un paiement effectué par un utilisateur avec son téléphone WP, le commerçant saisit le montant de la transaction sur le lecteur RDR et l'utilisateur présente son téléphone à proximité du lecteur RDR. Les moyens de traitement-lecteur MTL du terminal de paiement RDR, réalisés par exemple sous forme logicielle, activent alors l'application et émettent une requête en direction du téléphone en réponse à laquelle sont transmis en clair sur le canal de communication sans fil CH, l'information image INFM, le nom de l'utilisateur ainsi que la date d'expiration suivie d'une signature numérique. L'identifiant Id, en l'espèce le numéro de carte bancaire, n'est par conséquent pas transmis en clair sur le canal CH puisque de toute façon il n'est pas stocké dans la mémoire MM1 de l'élément sécurisé SE1 du téléphone. Cet identifiant est, comme on le verra plus en détail ci-après, stocké dans un serveur sécurisé de l'établissement bancaire dans lequel le titulaire du téléphone (de la carte) a son compte.

Cela étant, l'information image INFM, qui a le même format qu'un numéro de carte bancaire, est transmise en clair dans le champ de données dédié à l'identifiant (numéro de carte bancaire PAN) conformément au protocole EMV. Aussi, même si cette information image INFM est interceptée sur le canal CH ou bien résulte d'une requête émise par un lecteur piraté, cette information image INFM est totalement inexploitable pour le tiers malveillant car elle ne correspond pas à un véritable numéro de carte bancaire associé à un nom d'utilisateur et à une date d' expiration.

Cela étant, tout ceci est transparent pour le lecteur RDR puisque l'information image INFM a bien la forme d'un numéro de carte bancaire avec un numéro de Luhn correct. Les moyens MTL du lecteur RDR vérifient la signature de façon classique et connue en soi puis le terminal transmet au téléphone le montant à payer. Une fois que l'utilisateur a tapé par exemple son code PIN sur le clavier du téléphone, la transaction se poursuit par la génération par le téléphone d'un paquet de données comportant ledit montant ainsi que les données propres de l'utilisateur notamment l'information image INFM, ce paquet de données étant alors chiffré conformément au protocole EMV de façon classique et connue en soi. A ce stade, aucune donnée n'est transmise en clair sur le canal de communication CH. La transaction se poursuit alors de façon classique et connue en soi par une requête d'autorisation 0 transmise à l'établissement bancaire BK du titulaire du compte par l'intermédiaire d'un réseau interbancaire (non représenté à des fins de simplification de la figure), cette requête contenant l'information image INFM. La requête ainsi reçue est transmise (étape 0) à un premier serveur bancaire SV1.

Celui-ci comprend des premiers moyens de traitement-serveur MTSV1, réalisés généralement sous forme logicielle, qui vérifient la présence ou non (étape 20) de l'indication IND représentative de la présence d'une information image INFM en lieu et place d'un identifiant. Cette indication peut être tout simplement le numéro de série du lecteur (si le lecteur est un lecteur uniquement sans contact) ou bien (figure 2) un bit spécifique du bloc de données image de l'information image ayant par exemple une valeur logique donnée. En présence d'une telle indication, les moyens de traitement-serveur MTSV1 transmettent alors une demande de récupération de l'identifiant (étape 0) à des moyens de traitement-serveur MTSV2, également réalisés sous forme logicielle, d'un serveur sécurisé SV2. Le serveur sécurisé SV2 contient, dans cet exemple, dans une mémoire une table TB contenant un certain nombre d'identifiants (numéros de carte bancaire) d'un certain nombre de clients de la banque, et les informations image correspondantes INFM. Les moyens de traitement-serveur MTSV2 extraient alors l'identifiant Id et retransmettent (étape 0) cet identifiant Id correspondant à l'information INFM reçue, aux moyens de traitement MTSV1 du serveur SV1.

Ceux-ci alors traitent de façon classique et connue en soi (étape 0) la demande d'autorisation et renvoient le résultat correspondant (étape 0) qui est transmis via le réseau interbancaire (étape 0) au lecteur RDR.

Les serveurs SV1 et SV2 ont été présentés ici comme distincts. Cela étant les deux serveurs pourraient être réunis en un seul et même serveur. Dans le mode de réalisation de la figure 8, le dispositif sans contact susceptible de communiquer avec le lecteur RDR est cette fois- ci une carte à puce sans contact CRT munie d'une antenne ANT1. Le processeur de la puce MC de la carte comporte également des moyens classiques de communication sans contact. Par ailleurs, la puce comporte une première mémoire MM1 destinée à stocker l'information INFM de l'identifiant Id de la carte (ici le numéro PAN de la carte).

Cet identifiant Id est stocké dans une deuxième mémoire MM2. La mémoire MM1 est accessible via l'interface sans contact tandis que la mémoire MM2 n'est pas accessible via l'interface sans contact de la puce. Aussi, lors d'une requête d'un lecteur, que ce lecteur soit un lecteur authentique ou un lecteur piraté, seul le contenu de la mémoire MM1 pourra être communiqué et non pas celui de la mémoire MM2. L'identifiant Id de la carte est par ailleurs sérigraphié sur une face de la carte à puce, de même que le nom de l'utilisateur et la date d'expiration EXP L'utilisateur peut aussi bien utiliser sa carte avec un lecteur sans contact et ce de façon sécurisée comme indiqué ci avant, ou bien utiliser sa carte avec un lecteur classique à contact, la carte étant alors insérée dans le lecteur. Et, dans ce dernier cas, c'est le contenu de la mémoire MM2, c'est-à-dire l'identifiant Id de la carte, qui est communiqué au lecteur. L'invention n'est pas limitée aux modes de mise en oeuvre et de réalisation qui viennent d'être décrits mais en embrassent toutes les variantes.

Ainsi, l'information image INFM peut être mise à jour périodiquement voire même après chaque transaction effectuée. Cette mise à jour peut être effectuée dans le dispositif sans contact par l'intermédiaire du réseau mobile et de l'antenne ANT2.

De même, bien que les modes de mise en oeuvre et de réalisation qui viennent d'être décrits concernent une transaction bancaire effectuée conformément au protocole EMV, l'invention s'applique également à toute autre type de transaction entre un dispositif sans contact et un lecteur sans contact utilisant tout type de protocole dans lequel des données sensibles sont destinées à être transmises en clair. De telles données sensibles seront alors remplacées selon un aspect de l'invention par des données images comme décrit ci-avant. L'invention s' applique également à tout dispositif, pas nécessairement sans contact, capable de communiquer avec un lecteur pas nécessairement sans contact, sur un canal de communication, pas nécessairement sans fil, lors d'une transaction comme par exemple les cartes à puces classiques à contacts destinées à communiquer avec un lecteur à contacts.

En effet, il s'avère que lors d'une coopération entre une carte à puce à contacts et un lecteur à contacts (typiquement lorsque la carte est insérée dans le lecteur), certaines données sensibles peuvent transiter en clair depuis la carte vers le lecteur. C'est le cas notamment lorsque le protocole EMV est utilisé pour la mise en oeuvre de transactions bancaires. Ces données transitant en clair sont les mêmes que celles transitant sur le canal de communication sans fil lors d'une transaction bancaire effectuée selon le protocole EMV entre un dispositif sans contact et un lecteur sans contact. Il est donc possible pour un tiers malveillant d'utiliser un lecteur modifié capable de récupérer ces données sensibles à des fins frauduleuses. Il existe donc également un besoin pour sécuriser de telles transactions, en particulier bancaires, effectuées selon un protocole, tel que le protocole EMV, prévoyant une transmission en clair de données sensibles entre un dispositif, tel qu'une carte à puce à contacts, et un lecteur à contacts. En conséquence, selon un mode de mise en oeuvre et de réalisation, le procédé et le système selon l'invention permettent de répondre à ce besoin, sans intervenir sur le lien ou canal de communication proprement dit ou sur le protocole mais sur le stockage d'informations dans le dispositif, par exemple une carte à puce à contacts, destiné à communiquer avec un lecteur, par exemple un lecteur classique à contacts, de façon à stocker une donnée image de la donnée à protéger qui, même si elle est interceptée lors de son transit en clair, sera inexploitable par un tiers malveillant. Ensuite, d'une façon analogue à ce qui a été décrit ci-avant dans le cas d'une transmission NFC, la véritable donnée, qui est stockée dans un serveur sécurisé, par exemple dans une banque, sera récupérée par exemple à partir d'une table de concordance entre des données image et des données véritables. Et, la encore l'élaboration de cette donnée image est faite en amont préalablement à toute transaction, puis stockée dans le dispositif.

De ce fait, selon ce mode de mise en oeuvre, non seulement il n'est nul besoin de modifier les protocoles mais cette solution ne nécessite aucune modification structurelle et/ou logicielle des dispositifs, par exemple les cartes à puce à contacts, et des lecteurs classiques à contacts.

Claims

REVENDICATIONS1. Procédé de sécurisation d'une transaction, effectuée conformément à un protocole entre un dispositif et un serveur par l'intermédiaire d'un lecteur relié audit serveur et capable de communiquer avec le dispositif sur un canal de communication, ladite transaction devant prendre en compte un identifiant (Id) associé de façon biunivoque au dispositif, le procédé comprenant préalablement à ladite transaction une élaboration d'une information image (INFM) différente dudit identifiant et associée de façon biunivoque audit identifiant (Id) et un stockage de cette information image dans une première mémoire (MM1) du dispositif (WP), une mise à disposition du serveur d'éléments de récupération (TB) permettant de récupérer un identifiant à partir d'une information image associée et, lors de ladite transaction, une transmission au lecteur de ladite information image (INFM) sur le canal de communication (CH) dans un champ de données dédié audit identifiant conformément audit protocole, une transmission de ladite information image depuis le lecteur (RDR) vers le serveur (SV1, SV2), une récupération par le serveur de l'identifiant à partir de ladite information image et desdits éléments de récupération et une poursuite de la transaction avec ledit identifiant (Id), l'identifiant n'étant jamais transmis sur ledit canal de communication (CH).
2. Procédé selon la revendication 1, dans lequel le protocole est un protocole EMV et la transaction est une transaction bancaire effectuée conformément au protocole EMV entre ledit dispositif et un serveur bancaire par l'intermédiaire dudit lecteur.
3. Procédé selon la revendication 1 ou 2, dans lequel le dispositif est un dispositif sans contact et le lecteur est un lecteur sans contact capable de communiquer avec le dispositif sans contact sur un canal de communication sans fil (CH).
4. Procédé selon la revendication 3, dans lequel le dispositif sans contact est un appareil de communication sans fil (WP), parexemple un téléphone mobile cellulaire, équipé de moyens de communication sans contact mettant en oeuvre une application bancaire, ledit appareil de communication sans fil étant émule en mode carte.
5. Procédé selon la revendication 3, dans lequel le dispositif sans contact étant une carte à puce (CRT) comportant l'identifiant (Id) figurant sur une face de la carte, ladite carte comprenant des moyens de communication sans contact comportant la première mémoire (MM1) accessible sur requête du lecteur, ainsi qu'une deuxième mémoire (MM2) non accessible par le lecteur, on stocke l'identifiant dans la deuxième mémoire et l'information image correspondante dans la première mémoire.
6. Procédé selon l'une des revendications précédentes, dans lequel la mise à disposition desdits éléments comprend un stockage dans le serveur d'une table de correspondance (TB) entre différents identifiants associés à différents dispositifs et les informations images correspondantes.
7. Procédé selon l'une des revendications précédentes, comprenant en outre lors de ladite transaction, une transmission d'une indication (IND) indiquant que les données transmises dans ledit champ de données dédié sont représentatives d'une information image et le serveur détecte ladite indication.
8. Procédé selon l'une des revendications précédentes, dans lequel ledit identifiant (Id) correspond à un numéro de carte bancaire.
9. Procédé selon l'une des revendications précédentes, dans lequel ladite information image (INFM) a le même format qu'un identifiant (Id).
10. Procédé selon les revendications 8 et 9, dans lequel l'identifiant comporte un en-tête de données (ENT) suivi d'un bloc de données (BLD) représentatif d'un numéro de compte bancaire suivi d'un nombre de Luhn (NL1) correspondant aux données de l'en-tête et dudit bloc, et ladite information image (INFM) comporte le même entête de données (ENT) suivi d'un bloc de données image (BLDI) suivid'un nombre de Luhn (NL2) correspondant aux données de l'en-tête et aux données image.
11. Système, comprenant un dispositif (WP, CRT), un lecteur capable de dialoguer avec le dispositif sur un canal de communication lors d'une transaction effectuée conformément à un protocole et devant prendre en compte un identifiant associé de façon biunivoque au dispositif, un serveur (SV1, 5V2) relié au lecteur, le dispositif comprenant une première mémoire (MM1) stockant une information image (INFM) différente dudit identifiant (Id) et associée de façon biunivoque audit identifiant, le dispositif étant configuré pour transmettre au lecteur lors de ladite transaction, ladite information image sur le canal de communication dans un champ de données dédié audit identifiant conformément au protocole, le lecteur comportant des moyens de traitement-lecteur (MTL) configurés pour transmettre au serveur une information image reçue du dispositif, le serveur ayant accès à des éléments de récupération (TB) permettant de récupérer un identifiant à partir d'une information image associée et comportant des moyens de traitement-serveur (MTSV1, MTSV2) configurés pour récupérer un identifiant à partir d'une information image et desdits éléments de récupération et pour poursuivre ladite transaction avec ledit identifiant, l'identifiant n'étant jamais destiné à être transmis sur ledit canal de communication.
12. Système selon la revendication 11, dans lequel le protocole est un protocole EMV et la transaction est une transaction bancaire effectuée conformément au protocole EMV entre ledit dispositif et un serveur bancaire par l'intermédiaire dudit lecteur.
13. Système selon la revendication 11 ou 12, dans lequel le dispositif est un dispositif sans contact et le lecteur est un lecteur sans contact capable de communiquer avec le dispositif sans contact sur un canal de communication sans fil (CH).
14. Système selon la revendication 13, dans lequel le dispositif sans contact est un appareil de communication sans fil (WP), par exemple un téléphone mobile cellulaire, équipé de moyens de communication sans contact et incorporant une application bancairesans contact, ledit appareil de communication sans fil étant émule en mode carte.
15. Système selon la revendication 13, dans lequel le dispositif sans contact est une carte à puce (CRT) comportant en tant qu'identifiant un numéro de carte figurant sur une face de la carte, ladite carte comprenant des moyens de communication sans contact ladite première mémoire (MM1) accessible sur requête du lecteur, ainsi qu'une deuxième mémoire (MM2) non accessible par le lecteur, l'identifiant étant stocké dans la deuxième mémoire et l'information image correspondante étant stockée dans la première mémoire.
16. Système selon l'une des revendications 11 à 15, dans lequel le serveur comprend une mémoire-serveur contenant une table de correspondance (TB) entre différents identifiants associés à différents dispositifs sans contact et les informations images correspondantes, ladite table formant lesdits éléments de récupération.
17. Système selon l'une des revendications 11 à 16, dans lequel le dispositif est en outre configuré pour, lors de ladite transaction, transmettre une indication (IND) indiquant que les données transmises dans ledit champ de données dédié sont représentatives d'une information image et les moyens de traitement-serveur (MTSV1) sont configurés pour détecter ladite indication.
18. Système selon l'une des revendications 11 à 17, dans lequel ledit identifiant (Id) correspond à un numéro de carte bancaire.
19. Système selon l'une des revendications 11 à 18, dans lequel ladite information image (INFM) a le même format qu'un numéro de carte bancaire.
20. Système selon les revendications 18 et 19, dans lequel l'identifiant (Id) comporte un en-tête de données (ENT) suivi d'un bloc de données (BLD) représentatif d'un numéro de compte bancaire suivi d'un nombre de Luhn (NL1) correspondant aux données de l'en- tête et dudit bloc, et ladite information image (INFM) comporte le même en-tête de données (ENT) suivi d'un bloc de données image (BLDI) suivi d'un nombre de Luhn (NL2) correspondant aux données de l'en-tête et aux données image.
21. Dispositif, capable de communiquer avec un lecteur sur un canal de communication lors d'une transaction effectuée conformément à un protocole et devant prendre en compte un identifiant associé de façon biunivoque au dispositif, comprenant des moyens de communication (MCM) comportant une première mémoire (MM1) stockant une information image différente dudit identifiant et associée de façon biunivoque audit identifiant, les moyens de communication configurés pour, sur requête, transmettre ladite information image (INFM) sur le canal de communication dans un champ de données dédié audit identifiant (Id) conformément au protocole.
22. Dispositif selon la revendication 21, capable de communiquer avec le lecteur sur le canal de communication lors d'une transaction bancaire effectuée conformément au protocole EMV.
23. Système selon la revendication 21 ou 22, dans lequel le dispositif est un dispositif sans contact capable de communiquer avec le lecteur sur le canal de communication sans fil, lesdits moyens de communication étant des moyens de communication sans contact.
24. Dispositif selon la revendication 23, formant un appareil de communication sans fil, par exemple un téléphone mobile cellulaire (WP), dans lequel les moyens de communication sans contact sont configurés pour mettre en oeuvre une application bancaire, l'identifiant correspondant à un numéro de carte bancaire.
25. Dispositif selon la revendication 23, formant une carte à puce (CRT) comportant en tant qu'identifiant un numéro de carte figurant sur une face de la carte, ladite carte comprenant outre la première mémoire (MM1) stockant ladite information image, une deuxième mémoire (MM2) non accessible par le lecteur, l'identifiant étant stocké dans la deuxième mémoire.