La présente invention concerne le domaine de l'émulation des cartes de paiement sans contact et plus particulièrement le routage de la communication sans contact au sein d'un dispositif comportant plusieurs circuits d'émulation de cartes de paiement sans contact.

Les cartes bancaires pouvant servir au paiement en magasin sont composées d'un composant de carte à puce hébergeant les applications bancaires. Ce composant dispose d'un haut niveau de sécurité et est appelé pour cela « élément de sécurité » ou SE pour (Secure Elément en anglais).

Lorsqu'une telle carte est utilisée pour un paiement, elle est introduite dans le lecteur d'un terminal de paiement. Une connexion s'établit alors entre le terminal de paiement et le SE pour réaliser le paiement. La connexion est une connexion physique utilisant les connecteurs physiques du SE.

Le paiement sans contact se développe. Il est basé sur l'utilisation lors du paiement d'une carte dite de paiement sans contact qui agrège typiquement d'une part le SE d'une carte de paiement classique et une étiquette de communication en champ proche dite NFC (Near Field Communication en anglais). Le terminal de paiement est alors équipé d'un lecteur d'étiquette NFC. Le fonctionnement est alors le même que pour une carte de paiement classique, la connexion physique étant remplacée par la connexion radio en champ proche du type NFC.

Les utilisateurs sont de plus en plus équipés de terminaux mobiles tels que les téléphones mobiles, les assistants numériques ou les ordinateurs portables. De plus en plus de ces terminaux sont dotés d'interfaces de communication radio en champ proche. On utilise alors ces terminaux pour réaliser un paiement sans contact. Il suffit de doter ces terminaux d'un élément de sécurité similaire à celui équipant les cartes de paiement sans contact pour permettre un usage du terminal mobile dans un mode d'émulation d'une carte de paiement sans contact. Dans ce mode d'émulation d'une carte de paiement sans contact, la communication entre le terminal de paiement et l'élément de sécurité est effectuée directement via le contrôleur NFC du dispositif sans être contrôlée par le processeur du terminal mobile et son système d'exploitation. Ceci est une obligation pour des raisons de sécurité notamment, un système corrompu ne doit pas être en mesure d'influer sur la communication sécurisée entre le terminal de paiement et l'élément de sécurité.

Plusieurs solutions d'implémentation d'éléments de sécurité sont possibles. L'élément de sécurité peut être implémenté au sein de la carte d'abonné ou carte SIM (Subscriber Identity Module en anglais) dans le cas où le terminal mobile est un téléphone mobile, ou une carte SIM sécurisée. Il peut également être implémenté sous la forme d'un composant de la carte mère du terminal mobile, ou encore au sein d'une carte additionnelle, par exemple une carte SD (Secure Digital en anglais). Il pourrait également s'agir d'une carte de paiement, par exemple reliée de manière appropriée au terminal. Un même terminal peut même comporter plusieurs éléments de sécurité différents susceptibles de communiquer avec un terminal de paiement au travers de l'interface radio à champ proche.

Dans un tel terminal se pose le problème d'acheminer les communications vers le bon élément de sécurité.

L'invention vise à résoudre les problèmes précédents par un procédé de routage des messages au sein du contrôleur NFC. Ce contrôleur dispose d'une table des différentes applications hébergées par les différents éléments de sécurité. Lorsque le contrôleur reçoit une requête pour la liste des applications contenues dans la carte de paiement virtuelle, il intercepte cette requête et répond avec la liste des différentes applications accessibles sur les différents éléments de sécurité. Quand une requête visant à sélectionner une application est reçue, le contrôleur mémorise l'élément de sécurité concerné et redirige tous les messages vers cet élément tant qu'il ne reçoit pas de nouvelle requête de sélection.

L'invention concerne un procédé de routage au sein d'un terminal mobile émulant une carte de paiement sans contact et comportant une pluralité d'éléments de sécurité pouvant dialoguer avec un composant de communication radio en champ proche, comportant les étapes suivantes : une étape de réception par le composant de communication radio d'un message provenant d'un terminal de paiement et qui comporte en outre, si la commande reçue est une commande de sélection destinée à recevoir la liste des applications disponibles : une étape de constitution de ladite liste à partir d'une table mémorisée, ladite liste contenant tout ou partie des applications disponibles dans l'ensemble des éléments de sécurité ; une étape d'envoi de ladite liste au terminal de paiement en réponse à la commande de sélection reçue et qui comporte en outre, si la commande reçue est une commande de sélection d'application : une étape de consultation de ladite table mémorisée pour identifier l'élément de sécurité hébergeant l'application sélectionnée ; une étape de mémorisation de l'élément de sécurité identifié comme élément de sécurité actif ; une étape de relais de ladite commande de sélection d'application à l'élément de sécurité actif et qui comporte en outre, pour toutes les autres commandes reçues, une étape de relais de ladite commande reçue à l'élément de sécurité actif.

Selon un mode particulier de réalisation de l'invention, ladite table mémorisée comportant pour chaque application un identifiant d'application qualifié de public en outre de son identifiant d'application au sein de l'élément de sécurité, celui-ci étant alors appelé identifiant réel, l'étape de constitution de la liste des applications constitue ladite liste à partir des identifiants publics et non pas des identifiants réels des applications et l'étape de relais de la commande à l'élément de sécurité comporte quant à elle une étape de remplacement de l'identifiant public par l'identifiant réel de l'application préalablement au relais de la commande à l'élément de sécurité actif.

Selon un mode particulier de réalisation de l'invention, il comporte en outre une étape de mise à jour de ladite table mémorisée lorsqu'intervient une modification dans l'architecture des éléments de sécurité du terminal mobile. Selon un mode particulier de réalisation de l'invention, ladite étape de mise à jour s'effectue sous le contrôle d'un module de mise à jour s'exécutant sur le processeur central dudit terminal.

Selon un mode particulier de réalisation de l'invention, il comporte en outre une étape de gestion des droits d'accès à ladite table par ledit module de mise à jour.

L'invention concerne également un terminal mobile émulant une carte de paiement sans contact et comportant une pluralité d'éléments de sécurité pouvant dialoguer avec un composant de communication radio en champ proche, comportant des moyens pour réceptionner par le composant de communication radio un message provenant d'un terminal de paiement et qui comporte en outre si la commande reçue est une commande de sélection destinée à recevoir la liste des applications disponibles : des moyens pour constituer ladite liste à partir d'une table mémorisée, ladite liste contenant tout ou partie des applications disponibles dans l'ensemble des éléments de sécurité ; des moyens pour envoyer ladite liste au terminal de paiement en réponse à la commande de sélection reçue et qui comporte en outre si la commande reçue est une commande de sélection d'application : des moyens pour consulter ladite table mémorisée pour identifier l'élément de sécurité hébergeant l'application sélectionnée ; des moyens pour mémoriser l'élément de sécurité identifié comme élément de sécurité actif ; des moyens pour relayer ladite commande de sélection d'application à l'élément de sécurité actif et qui comporte en outre pour toutes les autres commandes reçues des moyens pour relayer ladite commande reçue à l'élément de sécurité actif.

Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels :

La Fig. 1 illustre l'architecture générale d'un terminal mobile équipé de plusieurs éléments de sécurité.

La Fig. 2 détaille cette architecture dans un exemple de réalisation de l'invention.

La Fig. 3 illustre les échanges entre les différents composants du système lors d'une sélection d'application.

La Fig. 4 illustre l'organigramme de fonctionnement du module de routage au sein du contrôleur NFC dans un exemple de réalisation de l'invention. Nous appelons terminal mobile dans ce texte tout type de dispositif de traitement de l'information pouvant être porté par un utilisateur et susceptible d'héberger une interface de communication radio à champ proche du type NFC. Selon l'exemple de réalisation décrit, ce terminal est un terminal de téléphonie mobile, mais il peut également s'agir d'un assistant personnel numérique, d'un ordinateur portable ou autre.

L'architecture de ce dispositif est illustrée par la Fig. 1. Le terminal 1.1 dispose d'un processeur principal 1.3 qui permet le fonctionnement du système d'exploitation du terminal.

Un élément de sécurité est défini comme un composant constitué d'une unité de calcul et de mémoire. Ces éléments de sécurité sont prévus pour pouvoir héberger de manière sécurisée des applications diverses dont typiquement des applications bancaires. Ces applications bancaires sont destinées, entre autres, à permettre à l'utilisateur du terminal d'effectuer des paiements à l'aide de son terminal. Typiquement les éléments de sécurité hébergent également une unité de traitement crypto graphique utilisée pour les algorithmes de signature, chiffrement et déchiffrement de contenu à l'aide de certificats numériques. Ils hébergent les certificats permettant à l'utilisateur de s'authentifier auprès des services bancaires, etc. Le fonctionnement de ces éléments de sécurité est normalisé et peut être consulté sous la référence ISO 7816.

Nous rappelons ici qu'un élément de sécurité peut être implémenté au sein de la carte d'abonné ou carte SIM (Subscriber Identity Module en anglais) dans le cas où le terminal 1.1 est un téléphone mobile, ou encore une carte SIM sécurisée. Il peut également être implémenté sous la forme d'un composant de la carte mère du terminal 1.1, ou encore au sein d'une carte additionnelle, par exemple une carte SD (Secure Digital en anglais). Il pourrait également s'agir d'une carte de paiement reliée de manière appropriée au terminal 1,1. Un terminal 1.1 peut même comporter plusieurs éléments de sécurité différents susceptibles de communiquer avec un terminal de paiement au travers d'une interface radio à champ proche.

A la Fig. 1 , trois éléments de sécurité 1.5, 1.6 et 1.7 sont connectés au processeur central 1.3, par exemple via un lien série. Le processeur central 1.3 peut donc interagir avec ces éléments de sécurité 1.5, 1.6 et 1.7, leur envoyer des commandes et recevoir les réponses. Pour permettre au terminal 1.1 de fonctionner dans un mode d'émulation d'une carte de paiement sans contact, il est nécessaire d'adjoindre un composant 1.4 de communication radio en champ proche NFC au terminal. Ce composant 1.4 peut également communiquer grâce au bus avec le processeur central 1.3. Typiquement pour une utilisation autre que le paiement sans contact, le composant NFC est piloté par une application fonctionnant sur ce processeur central 1.3.

Par contre, pour le fonctionnement en émulation d'une carte de paiement sans contact, notamment pour des raisons de sécurité, la communication entre le composant NFC et un élément de sécurité est directe. Cette communication ne transite pas par le processeur central 1.3. Ainsi, même si le système d'exploitation fonctionnant sur ce processeur central 1.3 venait à être corrompu, le fonctionnement de la carte de paiement sans contact n'est pas menacé. Ce fonctionnement est parfait lorsque le terminal 1.1 n'héberge qu'un seul élément de sécurité.

Le problème qui se pose est de permettre un routage des communications entre le composant NFC 1.4 et les différents éléments de sécurité, en l'occurrence, à titre d'exemple les éléments de sécurité 1.5, 1.6 et 1.7..

La Fig. 2 illustre plus en détail l'architecture d'un exemple de réalisation. On retrouve le composant NFC 2.3 qui permet une communication avec un terminal de paiement 2.5. Le composant NFC peut communiquer avec une pluralité 2.6, 2.8 et 2.10 d'éléments de sécurité. L'appareil fonctionne toujours sous le contrôle d'un système d'exploitation qui tourne sur le processeur 2.1

La Fig. 2 représente en plus les diverses applications 2.7, 2.9 et 2.11 hébergées par chacun des éléments de sécurité 2.6, 28 et 2.10. L'invention est essentiellement mise en œuvre au sein du composant NFC 2.3 sous la forme d'un module de routage 2.4. Selon certains modes de réalisation particuliers de l'invention, un module 2.2 de gestion d'une table des applications disponibles peut être utilisé. Ce module fonctionne alors sur le processeur central 2.1 du terminal mobile 1.1. Nous allons détailler son fonctionnement plus loin.

La Fig. 3 illustre les échanges entre les différents composants du système lors d'une sélection d'application.

Le fonctionnement classique d'une carte de paiement sans contact est le suivant. Lorsque la carte entre dans le champ du lecteur équipant le terminal de paiement des échanges protocolaires de bas niveau ont lieu pour initialiser la connexion. Ces échanges ne sont pas décrits en détail ici. Ensuite, le terminal de paiement envoie une première commande de sélection appelée « SELECT PPSE » qui vise à demander à la carte la liste des applications présentes au sein de celle-ci. La carte répond à cette requête à l'aide d'une liste des applications disponibles et pour chaque application donne un identifiant d'application connu sous le nom de AID {Application IDentifier en anglais). Le terminal en choisit une dans la liste et la sélectionne à l'aide d'une commande « SELECT AID ». Tous les échanges suivants ont alors lieu entre le terminal et l'application sélectionnée tant qu'une nouvelle commande de sélection n'est pas envoyée par le terminal de paiement.

Dans le cadre du terminal mobile émulant une carte de paiement, nous avons une pluralité d'éléments de sécurité, chacun de ces éléments de sécurité correspondant à une carte de paiement sans contact.

Le terminal de paiement est représenté par la ligne 3.1 dans la Fig. 3. La ligne 3.2 représente le composant NFC du terminal mobile, tandis que les lignes 3.31, 3.32 et 3.33 représentent les différents éléments de sécurité hébergés dans le terminal mobile.

Lorsque le terminal envoie une commande « SELECT PPSE » 3.4 visant à réclamer la liste des applications bancaires disponibles, cette requête est reçue en premier lieu par le composant NFC 2.3. Cette requête est alors filtrée et reconnue comme telle par un module ad hoc, appelé module de routage et référencé 2.4 sur la Fig. 2. Le premier aspect innovant de l'invention consiste en cette interception et dans le fait que le module de routage intercepte la commande « SELECT PPSE » pour y répondre en lieu et place d'un des éléments de sécurité.

Le module de routage répond donc à la requête en renvoyant 3.5 une table des applications disponibles sur l'ensemble des éléments de sécurité. Cette table peut être constituée de diverses manières. Elle peut être configurée lors de l'initialisation du terminal ou fixée par l'opérateur ou encore par la banque dont l'utilisateur est client. Tout moyen de constituer la table est admissible. On peut également avoir une étape initiale où le module de routage envoie lui-même une commande « SELECT PPSE » à chacun des éléments de sécurité, recueille les réponses envoyées par chacun des éléments de sécurité puis constitue lui-même une table résultant d'une concaténation des listes reçues en réponse. Selon certains modes de réalisation, la table mémorisée dans le module de routage et renvoyée en réponse à la commande « SELECT PPSE » émise par le terminal de paiement peut ne pas contenir l'intégralité des applications disponibles sur les divers éléments de sécurité. Cette souplesse permet de gérer éventuellement des abonnements divers ou être fait pour toute autre raison. La table contient donc un sous-ensemble, contenant tout ou partie de l'ensemble des applications disponibles sur l'ensemble des éléments de sécurité. La table peut également être mémorisée par le module de routage au sein de tout espace de stockage disponible dans le terminal et son emplacement n'est pas limité au composant NFC lui-même.

La table contient également pour chaque application un identifiant de l'élément de sécurité qui l'héberge. De cette façon, lorsque le module de routage reçoit la commande 3.6 « SELECT AID », il peut retrouver l'élément de sécurité qui héberge l'application sélectionnée. Il mémorise alors cet élément de sécurité comme étant l'élément de sécurité actif lors de l'étape 3.7.

Il renvoie alors la requête de sélection d'application « SELECT AID » 3.8 à l'élément de sécurité concerné, en l'occurrence l'élément de sécurité 3.32 sur la Fig. 3. Tout le trafic subséquent en provenance du terminal de paiement est alors routé vers l'élément de sécurité actif. Le basculement vers un nouvel élément de sécurité actif intervient lors de la réception par le module de routage d'une nouvelle commande « SELECT AID » venant remettre en cause l'élément de sécurité actif courant.

Selon l'exemple de réalisation de l'invention, le module de routage fonctionne selon l'organigramme de la Fig. 4.

Lors de l'étape 4.1, le module reçoit une commande émise par le terminal de paiement via la connexion NFC. Cette commande est alors filtrée et traitée en fonction de sa nature. Trois cas sont distingués.

Dans le premier cas, la commande reçue est une commande « SELECT PPSE » destinée à obtenir la liste des applications disponibles au sein de la carte de paiement sans contact émulée par le terminal mobile. On passe alors à l' étape 4.2 de constitution de la liste des applications à partir de la table mémorisée, cette liste contenant tout ou partie des applications disponibles dans l'ensemble des éléments de sécurité. Une fois cette liste construite, elle est envoyée en réponse à la commande « SELECT PPSE » à destination du terminal de paiement lors d'une étape 4.3.

Dans le second cas, la commande reçue est une commande « SELECT AID ».

Lors d'une première étape 4.4, le module de routage consulte la table mémorisée pour retrouver l'élément de sécurité qui héberge l'application dont l'identifiant est passé en paramètre de la commande de sélection. Une fois cet élément de sécurité identifié, le module de routage mémorise ce nouvel élément de sécurité comme l'élément de sécurité actif courant, lors de l'étape 4.5. La commande de sélection est alors relayée à l'élément de sécurité actif lors de l'étape 4.6. De cette façon on mémorise d'une part quel est l'élément de sécurité concerné par la commande de sélection reçue et donc par les commandes suivantes et d'autre part on transmet cette commande pour une sélection effective de l'application désirée au sein de l'élément de sécurité.

Toute autre commande est traitée conformément à l'étape 4.7 qui se contente de relayer la commande à l'élément de sécurité actif. Avantageusement, un élément de sécurité actif est mémorisé par défaut au démarrage du terminal.

Il peut arriver qu'une même application soit présente dans au moins deux éléments de sécurité. Nous nous retrouvons alors avec deux applications ayant le même identifiant et localisées dans deux éléments de sécurité différents.

Avantageusement, la table mémorisée associe à chaque application un identifiant, qualifié d'identifiant public, pouvant être différent de l'identifiant réel de l'application au sein de l'élément de sécurité. Selon ce mode de réalisation, l'étape de constitution de la liste des applications 4.2 constitue ladite liste à partir des identifiants publics et non pas des identifiants réels des applications. L'étape 4.6 de relais de la commande à l'élément de sécurité comporte quant à elle une étape de remplacement de l'identifiant public par l'identifiant réel de l'application préalablement au relais de la commande à l'élément de sécurité actif. De cette façon, il est possible d'exposer des applications ayant le même identifiant hébergées dans deux éléments de sécurité différents.

Avantageusement, la table est mise à jour lorsqu' intervient une modification dans l'architecture des éléments de sécurité du terminal mobile. Par exemple, lors de l'insertion d'une nouvelle carte SIM ou encore d'une nouvelle carte SD contenant un élément de sécurité. La mise à jour est alors contrôlée par un module de mise à jour de la table, le module 2.2 s'exécutant sur le processeur du terminal.

Avantageusement, cette table est protégée par des droits d'accès. Ainsi, seul l'opérateur ou la banque peut modifier la table. L'accès à une application donnée ou même à un élément de sécurité donné peut alors être conditionné à des considérations commerciales et ne pas être automatique. Les droits d ' accès sont alors avantageusement gérés par ledit module de mise à jour de la table.