Brevet FR2848366A1 — publié le 20040611

i L'invention concerne la communication entre la carte SIM d'un téléphone mobile et un point de télécommunications de type local, sur la base d'un lien instauré localement entre ces deux entités. En d'autres termes, l'invention concerne la communication entre la carte SIM d'un téléphone mobile et une entité placée à proximité de ce téléphone, entité du type incluant des moyens de traitement et de mémorisation de données. L'entité communicante est par exemple un ordinateur personnel, notamment dans le cas o il s'agit d'échanger des messages de type email entre le téléphone et l'ordinateur. L'entité communicante peut également être un distributeur de produits, par exemple des boissons, lorsque la carte SIM inclut une 15 application de porte-monnaie électronique pour l'achat de tels produits. L'entité communicante peut également être une borne internet publique. La carte SIM (Suscribe Identity Module) est l'élément permettant d'apporter la sécurité au réseau de téléphone mobile. Elle permet entre 20 autre l'authentification de l'abonné sur le réseau, le chiffrement des échanges (vocaux ou données) ainsi que la personnalisation du terminal mobile. Elle permet aussi d'autres services à valeur ajoutée notamment lorsque ces services implémentés sous forme d'applets JAVA utilisent la norme SIM Toolkit présente maintenant sur l'ensemble des cartes SIM. Dans leur état actuel, les cartes SIM peuvent communiquer avec un serveur applicatif distant par SMS (Short Message Service), par USSD (Unstructured Supplementary Service Data) ou par appel vocal. Dans de nombreuses situations, il est souhaitable de faire communiquer les applets (processus logique de carte SIM, typiquement programmé en langage 30 JAVA) SIM sur des liens locaux avec des points d'accès de proximité (PC, Bornes publiques, distributeurs, terminaux de paiement). Le lien local souhaité peut être par exemple de type IrDa (infrarouge), Bluetooth ou liaison radio basse fréquence ou filaire. Les normes GSM 11.14 et ETSI 31.111 qui décrivent les fonctions SIM Toolkit (principalement les fonctions qui permettent à la carte SIM de prendre la main sur le téléphone mobile) pour la carte SIM (réseaux deuxième génération) et pour la carte USIM (réseaux troisième génération) 5 apportent une solution théorique en définissant des fonctions de communication indépendantes du lien local (bearer indépendant protocol). Ces fonctions permettent à la carte SIM d'ouvrir un canal de communication sur un lien local à préciser, d'envoyerfrecevoir des données sur ce lien, de fermer le lien, etc. Cependant la définition des couches " transport " des liens locaux IrDa (infra-rouge) et Bluetooth est à produire dans cette norme. De plus, pour utiliser les possibilités de cette norme, celle-ci devra être implémentée non seulement par les encarteurs, mais aussi par les fabricants de terminaux, ce qui la rend encore fastidieuse à développer de nos jours. Dans le document FR 99 13 645, il a été proposé un mode de communication entre un équipement tiers et une carte SIM portée par un téléphone mobile, dans lequel mode de communication, la carte SIM pilote l'équipement tiers via un modem. Pour cela, des moyens de conversion sont utilisés entre la carte SIM 20 et son téléphone porteur qui transforme un premier dialogue entre carte SIM et téléphone en un second dialogue entre téléphone et équipement tiers. De cette façon, la carte SIM pilote l'équipement tiers via le téléphone. Ce mode de communication reste d'une complexité 25 d'implémentation élevée, notamment lorsque l'équipement tiers vise à fournir un service de proximité. Le but de l'invention est de permettre à une carte SIM, notamment à une carte SIM actuelle de type standard, d'exploiter des liens locaux de manière bidirectionnelle et ceci dans le but plus général de développer des 30 services de proximité. Le résultat technique obtenu tel qu'implémenté préférentiellement dans la carte SIM et dans le point d'accès, vise à offrir aux applets (applications) SIM Toolkit, et aux points d'accès, des services de communication locale sur des liens de type IrDa, Bluetooth ou câble série. Ce but est atteint selon l'invention grâce à un procédé d'échange de données bidirectionnel entre un processus logique (11) hébergé sur une 5 carte SIM (10) et un processus logique (21) hébergé sur une entité locale, caractérisé en ce qu'il fait appel à l'utilisation d'une mémoire de transit (13) portée par la carte SIM, les deux processus utilisant cette mémoire en alternance pour chacun y inscrire des données, que l'autre processus vient ensuite lire. On propose également selon l'invention une carte SIM hébergeant un processus logique et une mémoire, caractérisée en ce que le processus logique est conçu pour inscrire dans cette mémoire des données de communication destinées à un processus appartenant à une entité locale momentanément présente à proximité d'un téléphone équipé de la carte 15 SIM, et en ce que le processus logique de la carte SIM est également conçu pour détecter et lire dans cette mémoire des données inscrites par le processus de cette entité locale. On propose également selon l'invention un dispositif local communiquant, du type incluant un processeur et des moyens 20 d'émission/réception de données pour communiquer avec un téléphone mobile momentanément proche de ce dispositif, caractérisé en ce qu'il héberge un processus logique programmé pour utiliser la mémoire d'une carte SIM d'un téléphone mobile momentanément proche, en y inscrivant des données destinées à un processus logique de la carte SIM, ainsi que 25 pour lire dans cette mémoire des données inscrites par ce même processus de carte SIM. D'autres caractéristiques, buts et avantages de l'invention apparaîtront à la lecture de la description détaillée qui va suivre, faite en référence aux figures annexées sur lesquelles: - la figure 1 représente un ensemble téléphone mobile, carte SIM et borne locale selon l'invention; - la figure 2 est un organigramme représentatif d'un procédé d'échange selon l'invention. L'exemple privilégié de mise en oeuvre de l'invention, tel qu'il sera décrit maintenant, concerne le cas d'une implémentation de type Sim Toolkit sur la carte SIM 10 d'un téléphone GSM avec utilisation d'un lien IrDa (lien infrarouge connu en soi). Les éléments en jeu sont ici un point d'accès 20 noté également PA pour PointAccess, un terminal mobile 30 noté ME et la carte SIM 10 notée simplement SIM. Une application de type SIM toolkit, et qui met en oeuvre un service de proximité, est ici cliente d'un processus logique 11 hébergé sur la carte 10 SIM 10, ce processus de carte SIM étant ici dénommé AppletClient. La communication entre les processus s'effectue par l'intermédiaire d'un script de commandes. Les commandes échangées dans le script doivent être connues du point d'accès 20 (ici une borne locale), et connues d'une application 15 d'interface 12 installée sur la carte SIM, application appelée ci-après SimAccess. Le processus logique qui se trouve sur la borne locale (point d'accès PA), est ci-après dénommé PointAccess et est référencé 21 sur la figure 1. On fait également appel à un module 22 ayant la forme d'une API 20 (Application Program Interface) de communication (IrDa, Bluetooth ou série), et qui est localisé dans le point d'accès 20. Comme on le décrira par la suite, le script de commandes est échangé dans un buffer (mémoire tampon) de communication 13 qui est situé sur la carte SIM 10. Ce buffer, appelée ci-après SîMbuffer (ici une 25 mémoire de transit) est utilisé pour le processus logique SlMAccess 12 de la carte SIM pour la communication localisée. La procédure d'utilisation du buffer SIMBuffer 13 par le processus PointAccess 21 localisé sur le point d'accès 20 est la suivante. L'utilisation du buffer SIMBuffer 13 par le processus PointAccess 21 30 s'effectue de préférence par commandes AT telles que spécifiées dans les normes ETSI GSM 07.05 et 07.07. Le buffer SIMbuffer 13 peut être soit un fichier propriétaire de la carte SIM, soit un fichier EFSMs tel que spécifié dans la norme ETSI GSM 11.11. Dans le cas d'un fichier propriétaire, le buffer SIMBuffer 13 est par 5 exemple lu, effacé et écrit par la commande AT+CRSM. Cette commande vise à la base à inscrire des données sur une carte à puces, et par exemple une carte SIM répondant à la norme ISO 7816-3. Cette inscription est effectuée ici via le port IrDa, Bluetooth ou série d'un téléphone mobile. L'inconvénient de la commande AT+CRSM est que celle-ci n'est pas 10 implémentée sur tous les téléphones mobiles. Dans le cas de l'utilisation d'un fichier SMS en tant que buffer, le buffer SîMbuffer est préférentiellement lu par la commande AT+CMGR, et par ailleurs effacé et écrit par la commande AT+CMGW. La commande AT+CMGW vise initialement à accéder au fichier des SMS d'une carte SIM 15 via un port IrDa, Bluetooth ou série d'un téléphone mobile, par exemple par un PC pour utiliser le téléphone en tant que passerelle avec le réseau de téléphone mobile. L'avantage de cette variante est qu'elle fonctionne sur tous les téléphones mobiles. Dans le présent exemple (fig.2), la cinématique de communication 20 de type requête/réponse entre les processus PointAccess 21 et SimAccess 11 est celle énumérée ci-après. On entendra ici par lien local un lien de communication établi entre deux entités sur une distance nettement plus faible que celle séparant un téléphone de son serveur le plus proche dans un réseau cellulaire habituel. 25 Le lien local prend typiquement place sur une distance d'un ou de quelques mètres, voire sur quelques dizaines de mètres. Le terme lien, tel qu'appliqué à deux processus logiques, signifie l'existence d'un intervalle de temps pendant lequel chacun des deux processus est dans une configuration particulière correspondant à la mise 30 en oeuvre d'un échange de données avec l'autre processus. Ce lien s'établit par l'apparition de la configuration logique d'échange de part et d'autre, et se termine par la clôture du lien, à savoir la disparition de la configuration d'échange, de part et d'autre. En d'autres termes, chaque processus a, pendant la durée de vie d'un lien, la possibilité de la mise en oeuvre d'échanges avec l'autre processus. Sur la figure 2, on a représenté par des tirets en pointillés les 5 éléments précédemment mentionnés, et en outre l'utilisateur physique du téléphone, sous la référence 40. A l'étape 1, I'utilisateur active la liaison sans fil (IrDa) de son terminal positionne son terminal mobile devant le port IrDa du point d'accès PA 20. A l'étape 2, Le logiciel PointAccess 21, localisé sur le point d'accès 10 PA, détecte la présence du terminal mobile, établit une connexion sans fil (IrDa)avec le terminal mobile 30 et commence à lire en boucle le buffer de communication SIMBuffer 13. A l'étape 3, l'utilisateur 40 sélectionne à l'aide de son terminal mobile une commande dans un menu (SélectionMenultem) pour ouvrir une 15 sesson avec le Point d'Accès local 20 ". A l'étape 4, I'applet SIM Toolkit AppletClient 11 envoie une requête au processus logique PointAccess 21: elle fait appel à l'API SimAccess 12 en appelant une fonction d'envoi de requête: SlMAccess.Request (commandld, Params), Commandld étant l'identifiant de la commande 20 adressée au point d'accès PointAccess accompagnée de ses paramètres Params. A l'étape 5, suite à cette demande, le processus logique SimAccess 12 écrit dans le buffer SIMBuffer 13 la commande texte " REQ " suivie de la valeur de la variable Commandld et de ses paramètres Params.) Le logiciel SimAccess 12 se place dans un état de lecture périodique du buffer SIMBuffer 13 et attend une réponse de PointAccess 21. A l'étape 6, le processus PointAccess 21 qui lit en permanence lebuffer SIMBuffer 13 lit cette dernière commande 'REQ'+Commandld+Params et détecte ainsi la demande de requête d'une 30 application. A l'étape 7, le processus logique PointAccess 21 répond à l'applet SimAccess 11 en écrivant dans le buffer 13, après effacement de ce dernier, soit: a) la réponse 'RSP_ERROR (Errorld) en cas d'imcompréhension de la commande par le point d'accès 20 ou d'erreur de fonctionnement. Errorld représente l'identification de l'erreur. b) la réponse 'RSP_'+Commandld+RspParams, RspParams 5 représentant les paramètres de réponses dépendant de la commande en cas de succès. A l'étape 8, le logiciel SlMAccess 12 lit alors la réponse RSP_'+ Commandld+RspParams A l'étape 9, le logiciel SlMAccess 12 répond alors à l'applet cliente 10 AppletClient 11 en lui renvoyant les paramètres de réponse du processus PointAccess 21 RspParams ou l'identifiant de l'erreur en cas d'erreur. La borne 20 hébergeant le processus PointAccess et l'application SimAccess 12 effectuent tour à tour une lecture et une écriture de commandes dans le buffer 13, qui est donc utilisé à la façon d'une boîte 15 aux lettres commune par laquelle carte SIM 10 et borne 20 se répliquent tour à tour. Bien que l'on ait décrit ici un mode de réalisation spécifique, dans le cadre duquel le téléphone mobile déclenche lui-même l'établissement d'un lien de communication, une autre variante est également prévue, o la 20 borne locale remplit ce rôle. Ainsi, dans le cadre de l'invention, on notera la variante dans laquelle le lancement d'une application SIM Toolkit s'effectue dans la carte à l'initiative de la borne locale et non plus à l'initiative de téléphone mobile. On décrira maintenant une application plus spécifique, consistant en 25 un envoi sécurisé d'une donnée D à un point d'accès. Une première étape consiste pour l'utilisateur à positionner son terminal mobile devant le port IrDa du point d'accès PA. Dans une seconde étape, l'applet SIM Toolkit AppletClient 11, déclenchée par la sélection d'un menu par l'utilisateur 40, désire ouvrir une 30 session avec le processus PointAccess 21: elle fait appel à l'API SimAccess 12 en appelant une fonction d'ouverture de session SimAccess. Request (Open.LocalSession, Serviceld). Serviceld est, dans cette requête, I'identifiant alphanumérique de l'application cliente AppletClient. Ensuite, SimAccess écrit dans le buffer SimBuffer la commande texte 'REQ_OpenLocalSession(Serviceld)'. Puis le processus PointAccess 21, qui lit en permanence le buffer SlMBuffer 13 lit cette dernière commande 'REQOpenLocalSession' et détecte ainsi la demande de connexion locale d'une application. Ensuite, le processus PointAccess 21 répond à l'applet AppletClient 11 via SimAccess 12 en écrivant dans le buffer 13, après effacement de ce 10 dernier, la réponse'RSP'_OpenLocalSession(ack)', La variable boolénne " ack " peut prendre les valeurs suivantes: - 'TRUE': demande de connexion acceptée - 'FALSE': demande de connexion refusée Dans une étape suivante, si la demande de connexion est refusée 15 par PointAccess 21, alors le processus SimAccess 12 en avertit l'application cliente AppletClient 11 qui avertit l'utilisateur 40 et termine l'opération. Dans le cas contraire, le processus SimAccess 12 informe l'application cliente 11 du succès de la demande de connexion. Ensuite, I'applet cliente AppletClient 11 demande une 20 authentification du processus PointAccess 21 en utilisant la commande ExternalAuthentification(NumKeyl, alea)'. Ce paramètre NumKeyl est un numéro de clé utilisé pour le calcul du certificat. Le paramètre Alea est un aléa permettant l'authentification active du 25 point d'accès 20. Par une autre étape, le processus PointAccess 21 répond à l'applet AppletClient 11 via SimAccess 12 en écrivant dans le buffer SimBuffer 13, après effacement de ce dernier, la réponse RSP_ExternalAuthentification(certificat)'. La variable certificat contient le certificat d'authentification produit par le point d'accès 20. Dans une étape suivante, I'applet cliente Appletclient 11 calcule le certificat d'authentification avec la clé NumKeyl et vérifie l'égalité entre ce dernier certificat et le certificat retourné par PointAccess. Puis l'applet cliente AppletClient 11 peut alors envoyer son information sécurisée D. Dans un premier temps, elle peut optionnellement demander un PIN code à l'utilisateur de façon à protéger la donnée D. Ensuite, elle demande un aléa à PointAccess, ce dernier permettant de produire une signature de la donnée en utilisant la commande 'AskRandom()' Dans une étape suivante, le logiciel PointAccess répond à l'applet AppletClient 11 via SimAccess 12 en écrivant dans le buffer SIMBuffer 13, après effacement de ce dernier, la réponse 'RSP_AskRandom(alea)'. Ensuite, I'applet cliente Appletclient 11 calcule une signature du bloc de donnée [d, alea] avec la clé NumKey2 Puis elle envoie la donnée D au processus PointAccess 21 en utilisant la commande 'SendSignedData(D, NumKey2, signature)'. Le paramètre D est la donnée à transférer. Le paramètre NumKey2 est le numéro de la clé utilisée pour le calcul de la signature. Le paramètre signature est la signature produite par l'applet cliente AppletClient 1 1. Puis le processus PointAccess 21 qui lit en permanence le buffer SIMBuffer 13 lit cette dernière commande 'REQ SendSignedData(d, NumKey2, signature)' et détecte ainsi la demande d'envoi d'une donnée 25 sécurisée. Puis le processus PointAccess 21 répond à l'applet AppletClient 11 via SimAccess 12 en écrivant dans le buffer SIMBuffer 13, après effacement de ce dernier, la réponse 'RSP_SendSignedData (ack)'. La variable booléenne ack a pour valeur l'acquittement positif 30 (TRUE) ou négatif (FALSE). Enfin, I'applet cliente AppletClient 11 affiche un message à l'utilisateur lui indiquant le bon ou mauvais déroulement de l'opération. Dans l'architecture décrite ici, le point d'accès peut être considéré comme serveur et préférentiellement attend en permanence une demande de communication de la part d'un logiciel localisé sur la carte SIM. L'invention permet à un processus localisé sur une carte SIM 5 standard (sans nécessité d'ajout de fonctions spécifiques par l'encarteur) de dialoguer de manière bidirectionnelle avec un point d'accès externe en utilisant un lien local. L'implémentation du procédé se fait par l'intermédiaire d'un buffer de communication situé sur la carte SIM et accessible aussi bien par le point 10 d'accès que par le logiciel localisé sur la SIM. Le dialogue entre le logiciel localisé sur la carte SIM et le point d'accès s'effectue préférentiellement, mais non exclusivement, par un script de commandes qui est écrit et lu dans le buffer de communication, aussi bien par l'application de la carte SIM que par l'application de la borne 15 d'échange. il REVENDICATIONS 1. Procédé d'échange de données bidirectionnel entre un processus logique (11) hébergé sur une carte SIM (10) et un processus logique (21) hébergé sur une entité locale, caractérisé en ce qu'il fait appel à l'utilisation 5 d'une mémoire de transit (13) portée par la carte SIM, les deux processus utilisant cette mémoire en alternance pour chacun y inscrire des données, que l'autre processus vient ensuite lire. 2. Procédé selon la revendication 1, caractérisé en ce qu'il inclut une étape d'établissement d'un lien (1) de communication entre les deux 10 processus et une étape de clôture de ce lien. 3. Procédé selon la revendication 1 ou la revendication 2, caractérisé en ce que les processus respectifs (11, 21) de la carte SIM (10) et de l'entité locale (20) sont prévus pour surveiller l'apparition sur la mémoire de transit (13) d'une donnée inscrite par l'autre processus (1 1, 21) et lire cette 15 donnée une fois son apparition détectée. 4. Procédé selon la revendication 3, caractérisé en ce qu'au moins l'un des deux processus (11, 21) est prévu pour lire à répétition la mémoire de transit (13) afin de relever une donnée apparue entre deux lectures consécutives. 5. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que le processus de l'entité locale (21) lit et écrit dans la mémoire de transit (13) de la carte SIM (10) via un mode de communication appartenant au groupe constitué des communications optique, radiocommunication de proximité et filaire. 6. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que la mémoire de transit (13) est constituée par un fichier de la carte SIM (10) qui est également dédié à la mémorisation de textes de messagerie. 7. Procédé selon l'une quelconque des revendications 1 à 5, 30 caractérisé en ce que la mémoire de transit (13) est constituée par un fichier spécifiquement créé pour l'échange de données avec un entité locale. 8. Carte SIM (10) hébergeant un processus logique (11) et une mémoire (13), caractérisée en ce que le processus logique (11) est conçu pour inscrire dans cette mémoire (13) des données de communication destinées à un processus (21) appartenant à une entité locale (20) 5 momentanément présente à proximité d'un téléphone équipé de la carte SIM (10), et en ce que le processus logique (11) de la carte SIM est également conçu pour détecter et lire dans cette mémoire (13) des données inscrites par le processus (21) de cette entité locale (20). 9. Carte SIM selon la revendication 8, caractérisée en ce que le 10 processus logique hébergé sur la carte SIM est constitué d'une ou plusieurs applications programmées en langage JAVA. 10. Carte SIM (10) selon la revendication 8 ou 9, caractérisée en ce que le processus (11) hébergé sur la carte (10) est une application constituant un porte-monnaie électronique. 11. Carte SIM (10) selon la revendication 8 ou 9, caractérisée en ce que le processus logique (11) hébergé sur la carte SIM est une application de messagerie. 12. Ensemble comprenant un terminal mobile (30) et sa carte SIM (20), caractérisé en ce que la carte SIM (20) est conforme à l'une 20 quelconque des revendications 8 à 11. 13. Dispositif local (20) communicant, du type incluant un processeur et des moyens d'émission/réception (22) de données pour communiquer avec un téléphone mobile (10, 30) momentanément proche de ce dispositif (20), caractérisé en ce qu'il héberge un processus logique (21) programmé 25 pour utiliser la mémoire (13) d'une carte SIM (10) d'un téléphone mobile (10, 30) momentanément proche, en y inscrivant des données destinées à un processus logique de la carte SIM (10), ainsi que pour lire dans cette mémoire (13) des données inscrites par ce même processus (11) de la carte SIM (10). 14. Dispositif local communicant (20) selon la revendication précédente, caractérisé en ce qu'il est constitué par un ordinateur personnel. 15. Dispositif local communicant (20) selon la revendication 13, caractérisé en ce qu'il est constitué par une borne communicante publique. 16. Dispositif local communicant (20) selon la revendication 15, caractérisée en ce qu'il constitue un distributeur de produits de consommation.