Brevet FR2812419A1 — publié le 20020201

PROCEDE DE SECURISATION DE L'ACCES A AU MOINS UNE APPLICATION SUPPORTEE PAR UNE CARTE UTILISATEUR COOPERANT AVEC UN DES TERMINAUX D'UN SYSTEME DE COMMUNICATION ET TERMINAL POUR METTRE EN EUVRE CE PROCEDE La présente invention concerne un procédé de sécurisation de l'accès à au moins une application supportée par une carte utilisateur à microprocesseur. Cette carte utilisateur coopère avec un des terminaux de communication d'un système de communication. L'invention concerne également un terminal de communication mettant en ceuvre ce procédé. Un des domaines d'application, non exclusif, de l'invention est celui des terminaux mobiles de radiocommunication fonctionnant dans un système de radiocommunication cellulaire. L'invention s'applique notamment, mais non exclusivement, à un système selon le standard GSM (Groupe spécial Systèmes Mobiles publics de radiocommunication). Les terminaux d'un système de radiocommunication peuvent coopérer avec au moins une carte à puce intelligente, appelée en anglais "smart card". Chaque carte à puce contient au moins une application interne. Chaque application interne est susceptible de coopérer avec une application externe à la carte à puce. Par exemple, I'application externe peut être une application bancaire coopérant avec une carte utilisateur de type carte de paiement supportant l'application bancaire correspondante. De plus, lorsqu'une application externe désire accéder à l'application interne correspondante supportée par la carte à puce, cette application externe commence le protocole de connexion. Elle échange des données dites APDU (Applicative Protocol Data Unit en anglais: Unité d'échange de données de niveau applicatif) via l'interface logicielle du terminal ou API ( Application Programming interface en anglais: Interface de programmation de et vers l'application). Dans l'APDU, I'application externe indique son type (bancaire, ou autres) ou classe. Cette classe est indiquée dans l'un des octets de l'APDU, appelé octet "CLA". Le concept de plusieurs applications réunies sur une même carte est très avantageux pour l'abonné. En effet, celui-ci peut effectuer de façon simple et uniquement avec son terminal de nombreuses opérations telles que le paiement d'une commande effectuée également depuis son terminal. 2 2812419 Ainsi, plusieurs applications externes différentes peuvent avoir accès simultanément aux applications internes correspondantes sur la même carte à puce. Mais deux applications externes identiques ne doivent pas avoir accès simultanément à l'application interne correspondante sur la "smart card". Cette restriction d'accès doit être possible pour pallier les risques d'utilisation frauduleuse des applications de la carte à puce. Dans le cas d'une transaction entre une application externe bancaire et l'application bancaire de la carte à puce d'un abonné, une transaction entre une application pirate de type bancaire demandant l'accès à la "smart card" de l'abonné doit être évitée. D'autre part, au sein d'une carte à puce contenant plusieurs applications internes différentes, l'étanchéité entre les différentes applications internes est difficilement garantie. Ainsi, prenons le cas d'une première application externe X est déjà en communication avec 1' application interne X correspondante située sur la carte à puce. Si une application externe pirate X' veut communiquer avec l'application interne X, alors l'application X' pourrait se connecter sur une application interne Y située dans la carte à puce à proximité de l'application interne X. Puis cette application X' pourrait profiter d'un éventuel manque d'étanchéité entre les applications internes pour atteindre l'applicotion interne X. Dans l'état de la technique, on connaît le modèle du tout ou rien. Ce modèle fonctionne par exemple sur les équipements tel que les terminaux de communication permettant l'accès à internet ou "internet communication terminal" en anglais. Sur ce genre de terminaux, des applications peuvent être téléchargées de l'extérieur. Si le protocole de connexion utilisé par l'application externe est connu par le terminal alors l'application externe est dite "application autorisée" et peut accéder à l'application interne correspondante de la carte à puce. Cependant, si une autre application externe autorisée, et ayant la même classe que la première, demande l'accès à la même application interne de la carte à puce, la deuxième application peut également accéder à la même application interne sur la carte à puce et une interférence entre les deux applications externes a lieu. La solution antérieure n'est donc pas suffisante pour pallier le risque évoqué ci-dessus. L'invention résout ce problème en permettant à une application externe de réserver l'accès à l'application interne correspondante de la carte utilisateur pour elle seule. De manière plus précise, I'invention a pour objet un procédé pour sécuriser l'accès d'une application externe à au moins une carte utilisateur à microprocesseur. Ladite carte utilisateur est susceptible de contenir plusieurs applications internes, ladite application externe correspondant à une des applications internes. Ladite carte utilisateur coopère avec un terminal. Ladite application externe utilise un protocole de connexion à ladite carte utilisateur dans lequel, à chaque type d'application externe est associé un paramètre d'identification prédéterminé. Ce procédé comporte les étapes suivantes: - lorsqu'une première application externe est en connexion avec l'application interne correspondante sur ladite carte utilisateur, on détermine le paramètre d'identification de l'application, - si une deuxième application externe requiert la connexion à ladite carte utilisateur, on analyse le paramètre d'identification de ladite deuxième application, - si ledit paramètre d'identification est identique à celui de la première application connectée, on interdit l'accès pour ladite deuxième application externe à ladite application interne correspondante sur la carte utilisateur. En particulier, le procédé comporte un protocole de connexion entre I'application externe et l'application interne correspondante sur la carte utilisateur. Ce protocole résulte d'un échange d'APDU, contenant plusieurs octets, entre l'application externe et l'application interne située sur la carte utilisateur via l'interface logicielle du terminal, ledit paramètre d'identification étant représenté par au moins l'un des octets de l'APDU. 4 2812419 Le procédé comporte un protocole de connexion pendant lequel a lieu un échange d'APDU tel qu'au moins l'un des octets de l'APDU est l'octet CLA définissant la classe de l'application externe, chaque type d'application externe identique, susceptible de pouvoir échanger des APDU ayant un octet CLA identique, ledit paramètre d'identification étant l'octet CLA. Le procédé est tel que l'application externe d'une classe définie ayant effectué une réservation totale de l'accès à au moins une carte utilisateur, l'analyse dudit paramètre d'identification par l'interface logicielle sera effectuée sur toutes les classes possibles qui définissent une application externe. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante se rapportant à un mode de réalisation donné à titre d'exemple mais en aucun cas limitatif. Ce mode de réalisation fait référence aux dessins annexés. La figure 1 est un schéma synoptique d'une donnée de type APDU. La figure 2 est un schéma synoptique simplifié du dispositif selon l'invention mettant en oeuvre le procédé de sécurisation d'accès selon I'invention. La figure 3 est un organigramme du procédé de sécurisation de l'accès selon l'invention. En référence à la figure 1, lorsqu'une application externe désire accéder à l'application interne correspondante supportée par la carte à puce située dans un terminal d'un système de radiocommunication, cette application commence le protocole de connexion et échange des données dites APDU 1 avec le terminal. Cet APDU contient plusieurs octets. L'un de ces octets est l'octet CLA 2. Cet octet indique la classe de l'application externe. Deux applications externes de même type ont la même classe, par exemple deux applications de type bancaire. En référence à la figure 2, chaque terminal d'un système de radiocommunication coopère avec au moins une carte à puce 40. Chaque carte à puce 40 peut contenir plusieurs applications internes correspondant , 25, 35 à des applications externes 10, 20, 30. 2812419 Chaque application externe Ae(i) d'un type donné possède une classe donnée telle que CLA[Ae(i)]=i. Deux applications externes Ae(1) et Ae(2) 10 et 20 de type différent, donc de classe différente, auront un octet CLA de valeur différente CLA[Ae(1)]=l etCLA[Ae(2)]=2. Cette application externe peut être locale, telle l'application GSM d'un terminal GSM; ou peut être distante telle une application bancaire communiquant avec l'application bancaire de la "smart card". Dans ce qui suit, on entend par "blocage total", ce blocage total de l'accès à 'API donc à la carte à puce ayant été requis par une application externe, I'interdiction de l'accès à la carte à puce pour n'importe quelle autre application externe quelque soit sa classe. On entend également par "blocage partiel", ce blocage partiel de l'accès à l'API donc à la carte à puce ayant été requis par une première application externe, I'interdiction de l'accès à la carte à puce pour une deuxième application externe de même classe que la première. Sur la figure 3, dans l'étape 50, une application externe Ae(1) demande l'accès à l'application interne Ai(l) contenue dans une carte à puce d'un terminal d'un système de radiocommunication. Cette application externe envoie des données de type APDU pendant le protocole de connexion via l'interface logicielle du terminal (API). A cette application externe est associé un paramètre d'identification prédéterminé: I'octet CLA contenu dans l'APDU et tel que CLA[Ae(1)]= 1. On analyse la valeur de l'octet CLA. Ensuite, dans l'étape 60, I'API vérifie si l'accès à la "smart card" est bloqué par une autre application externe Ae(i) qui aurait demandé le blocage de l'accès à la carte à puce pour une autre application quelle que soit sa classe (ce qui constitue le blocage total): Si c'est le cas, alors on passe à l'étape 70 et la demande est rejetée. Si ce n'est pas le cas, alors on passe à l'étape 80. Dans l'étape 80, I'API vérifie si l'accès à la carte à puce est bloqué par une autre application externe Ae(i) ayant demandé un blocage partiel pour toute application de même classe, c'est-à-dire dont l'octet CLA a pour valeur CLA[Ae(i)]=i: Si c'est le cas, alors on passe à l'étape 90 o l'API analyse si i= 1 6 2812419 Si i=1 (les deux applications sont de même classe) alors la demande de connexion de Ael est rejetée. Si i<>1 (les deux applications sont de classes différentes) alors on passe à l'étape 110. Si ce n'est pas le cas, alors on passe à l'étape 1 00. Dans l'étape 100, I'application externe doit demander à l'API si elle désire un blocage total avant de passer à l'étape 130: Si ce n'est pas le cas, alors l'accès à la carte à puce sera bloqué pour toute application externe de même classe que l'application Ae(1) donc ayant un octet CLA égal à 1 dans l'étape 110 (réservation partielle de l'API). Si c'est le cas, alors l'accès à la carte à puce sera bloqué pour toute application externe quelle que soit sa classe dans l'étape 120 (réservation totale de l'API). Dans l'étape 130, l'application Ae(1) accède à l'application interne correspondante Ai(1) de la carte à puce. REVENDICATIONS 1. Procédé pour sécuriser l'accès d'une application externe à au moins une carte utilisateur à microprocesseur, ladite carte utilisateur étant susceptible de contenir plusieurs applications internes, ladite application externe correspondant à une des applications internes, ladite carte utilisateur coopérant avec un terminal, ladite application externe utilisant un protocole de connexion à ladite carte utilisateur dans lequel, à chaque type d'application externe est associé un paramètre d'identification prédéterminé, caractérisé en ce que: - lorsqu'une première application externe est en connexion avec l'application interne correspondante sur ladite carte utilisateur, on détermine le paramètre d'identification de l'application, - si une deuxième application externe requiert la connexion à ladite carte utilisateur, on analyse le paramètre d'identification de ladite deuxième application, - si ledit paramètre est identique à celui de la première application connectée, on interdit l'accès pour ladite deuxième application externe à ladite application interne correspondante sur la carte utilisateur. 2. Procédé selon la revendication précédente, dans lequel le protocole de connexion entre l'application externe et l'application interne correspondante sur la carte utilisateur résulte d'un échange d'APDU, contenant plusieurs octets, entre l'application externe et l'application interne située sur la carte utilisateur via l'interface logicielle du terminal, ledit paramètre d'identification étant représenté par au moins l'un des octets de l'APDU. 3. Procédé selon la revendication 2, dans lequel au moins l'un des octets de l'APDU est l'octet CLA définissant la classe de l'application externe, chaque type d'application externe identique, susceptible de pouvoir échanger des APDU ayant un octet CLA identique, ledit paramètre d'identification étant l'octet CLA. 4. Procédé selon l'une quelconque des revendications 2 et 3, caractérisé en ce que l'application externe d'une classe définie ayant effectué une réservation totale de l'accès à au moins une carte utilisateur, I'analyse dudit paramètre d'identification par l'interface logicielle sera effectuée sur toutes les classes possibles qui définissent une application externe. 8 2812419 5. Procédé selon l'une quelconque des revendications précédentes, fonctionnant dans un système de communication permettant une radiocommunication cellulaire, dans lequel lesdits terminaux de communication sont des terminaux de radiocommunication et lesdites cartes utilisateur sont des cartes à puce. 6. Terminal de radiocommunication coopérant avec au moins une carte utilisateur à microprocesseur pour la mise en oeuvre du procédé selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comporte des moyens d'exécution de commandes distincts, des moyens de mémorisation de données distincts pour chaque application de classe distincte et des moyens d'analyse d'au moins un paramètre d'identification contenu dans les données échangées pendant le protocole de connexion.