FR2864294A1 - Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant - Google Patents
Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant Download PDFInfo
- Publication number
- FR2864294A1 FR2864294A1 FR0314805A FR0314805A FR2864294A1 FR 2864294 A1 FR2864294 A1 FR 2864294A1 FR 0314805 A FR0314805 A FR 0314805A FR 0314805 A FR0314805 A FR 0314805A FR 2864294 A1 FR2864294 A1 FR 2864294A1
- Authority
- FR
- France
- Prior art keywords
- card
- execution
- application
- applet
- accounts
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07F—COIN-FREED OR LIKE APPARATUS
- G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
- G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
- G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
- G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
- G06Q20/357—Cards having a plurality of specified features
- G06Q20/3576—Multiple memory zones on card
- G06Q20/35765—Access rights to memory zones
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Microelectronics & Electronic Packaging (AREA)
- Computer Networks & Wireless Communication (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Storage Device Security (AREA)
Abstract
Cette carte à microcircuit (10) comporte une pluralité de comptes, une unité pour basculer d'un compte à un autre, une unité pour exécuter une application impliquant une intervention sur un compte et une unité (15) de mémorisation. L'unité de mémorisation (15) est adaptée à mémoriser des informations de droits d'exécution de l'application sur un ou plusieurs comptes. La carte à microcircuit (10) comporte en outre une unité (16, 26 ; 19, 24) pour interdire, en fonction des informations de droits d'exécution, l'exécution de l'application sur un ou plusieurs comptes spécifiques choisis parmi la pluralité de comptes, l'exécution de l'application sur les autres comptes restant autorisée.
Description
CARTE A MICROCIRCUIT MULTI-COMPTE
PERMETTANT LA RESTRICTION D'UNE FONCTIONNALITE A UN COMPTE
ET PROCEDE DE COMMUNICATION CORRESPONDANT
La présente invention se rapporte à une carte à microcircuit comportant plusieurs comptes appelée dans toute la suite carte à microcircuit multi-compte permettant de limiter l'exécution d'une fonctionnalité à un compte particulier de la carte à microcircuit, en interdisant l'exécution de cette fonctionnalité sur d'autres comptes de la carte à microcircuit. L'invention se rapporte aussi à un procédé de communication entre une telle carte à microcircuit et une ou plusieurs entités extérieures.
Entre autres exemples de cartes à microcircuit entrant dans le champ d'application de l'invention, on trouve les cartes SIM (module d'identification de l'abonné, en anglais "Subscriber ldentity Module") d'abonnement à un opérateur de réseau de télécommunications, les cartes bancaires, les cartes de contrôle d'accès, les cartes d'identité ou passeports ou autres documents officiels, les cartes mémoire, etc. Un "compte" de la carte à microcircuit est compris ici comme l'ensemble des fonctionnalités et des données de la carte à microcircuit qui se rapportent à un utilisateur. Un compte peut correspondre par exemple à un abonnement GSM (norme de télécommunications mobiles, en anglais "Global System for Mobile communications") ou à un compte bancaire, ces exemples n'étant bien entendu pas limitatifs.
Une carte à microcircuit mufti-compte peut par exemple comporter un premier compte utilisé pour un ensemble d'applications bancaires (telles que la consultation et la gestion de comptes bancaires ou de portefeuilles d'actions, le paiement d'achats, le retrait de sommes d'argent, etc.) et un deuxième compte utilisé pour un ensemble d'applications de transport (telles que l'accès à des portillons d'un réseau de transport en commun, le contrôle du nombre de personnes habilitées à franchir ces portillons, etc.).
Actuellement, on connaît des cartes à microcircuit multi-compte (comportant au moins deux comptes) uniquement dans le domaine des cartes d'abonnement à un opérateur de télécommunications mobiles.
2864294 2 Ainsi, par exemple, les abonnements "PRO/PERSO", c'est-à-dire correspondant à la fois à un compte professionnel et à un compte personnel, permettent, via un menu (offert par le "SIM toolkit" dans le cas du GSM) d'un terminal de téléphonie mobile ou tout autre type de terminal mobile (par exemple un assistant numérique personnel ou PDA en anglais "Persona! Digital Assistant"), de basculer du compte professionnel vers le compte personnel de l'utilisateur (par exemple pour la réalisation d'un appel téléphonique personnel) et vice versa.
Dans ce cas, une carte SIM attribuée à un abonné PRO/PERSO comporte deux nombres IMSI (identifiants internationaux d'abonné mobile, en anglais "International Mobile Subscriber Identity") respectivement attachés à chacun des deux comptes. La carte SIM permet en outre une facturation séparée pour chacun des comptes.
Un autre exemple connu de carte multi-compte faisant son apparition est une carte comportant un compte SIM et un compte USIM (module universel d'identification de l'abonné, en anglais "Universal Subscriber ldentity Module").
La demanderesse a cherché une solution permettant d'interdire l'exécution d'une fonctionnalité sur un des comptes d'une carte à microcircuit multicompte, tout en la laissant libre d'utilisation sur d'autres comptes de la même carte à microcircuit.
II est en effet utile de pouvoir différencier ainsi les divers comptes d'une même carte: on pourra ainsi permettre, par exemple, à l'utilisateur d'une carte PRO/PERSO d'accéder à des applications de jeux en ligne payantes lorsqu'il utilise son compte personnel et ne pas permettre cet accès lorsqu'il utilise son compte professionnel.
Par ailleurs, dans le souci de rechercher une solution satisfaisante, la demanderesse a souhaité tenir compte de l'importance croissante de l'interopérabilité des systèmes d'exploitation dans le domaine des cartes à microcircuit. L'interopérabilité des systèmes d'exploitation s'est considérablement développée avec l'apparition de plateformes JavaCard. Ainsi, le système d'exploitation d'une carte peut disposer d'une machine virtuelle JavaCard qui permet d'intégrer des composants logiciels, sous forme d'appliquettes, 2864294 3 développées de façon indépendante, par exemple par un client du fabricant de cartes.
Comme le sait l'homme du métier, une appliquette ou "applet" est une application dans le contexte JavaCard. Dans tout la suite de la description, on utilise pour simplifier le terme "applet", acronyme de l'anglais "APPlication Light wEighT', au sens de "appliquette". En termes de programmation, un applet est un objet, au sens de la programmation orientée objet.
Un applet est identifié par un identifiant d'application AID (en anglais "Application Identifier"). Un applet comporte notamment une série de méthodes, qui sont des programmes, dont certains peuvent être invoqués, c'est-à-dire dont l'exécution peut être lancée, par un terminal, par envoi de messages appropriés (du type d'une commande APDU) à une carte à microcircuit.
Parmi ces "méthodes", on trouve le "constructeur" de l'applet, qui permet d'instancier (en anglais "to instantiate") l'applet. Le constructeur porte le nom de l'applet et est invoqué par la méthode "new", bien connue de l'homme du métier. Cette méthode est lancée à chaque installation de l'applet.
De tels applets peuvent être chargés dans la carte à microcircuit, soit directement dans le code ROM (mémoire morte, en anglais "Read Only Memory") du système d'exploitation, soit dans l'EEPROM (mémoire morte programmable et effaçable électriquement, en anglais "Electrically Erasable Programmable Read Only Memory") lors des phases finales de la fabrication de la carte, par exemple en cours de pré-personnalisation ou de personnalisation, ou encore après livraison de la carte (c'est-à-dire en "post-issuance"), par exemple en mettant en oeuvre un mécanisme dit OTA (utilisant la voie hertzienne, en anglais "Over The Air"), qui consiste à charger l'applet par envoi à la carte d'un message du type message court (SMS, en anglais "Short Message Service") généralement crypté et soumis à authentification, pour des raisons de sécurité.
Un besoin est donc apparu de prévoir un mécanisme qui permette, dans un tel contexte, d'interdire le fonctionnement d'un applet sur au moins un compte d'une carte multi-compte. A la connaissance de la demanderesse, un tel mécanisme n'existe pas à l'heure actuelle.
La présente invention a pour but de remédier à cet inconvénient.
2864294 4 Dans ce but, l'invention propose une carte à microcircuit comportant une pluralité de comptes, une unité pour basculer d'un compte à un autre, une unité pour exécuter une application impliquant une intervention sur un compte et une unité de mémorisation, caractérisée en ce que: - l'unité de mémorisation est adaptée à mémoriser des informations de droits d'exécution de l'application précitée sur un ou plusieurs comptes, - la carte à microcircuit comporte en outre une unité pour interdire, en fonction des informations de droits d'exécution, l'exécution de l'application précitée sur un ou plusieurs comptes spécifiques choisis parmi la pluralité de comptes, l'exécution de l'application sur les autres comptes restant autorisée.
Ainsi, l'invention permet de restreindre l'utilisation d'une fonctionnalité, réalisée par une application, à un ou plusieurs comptes choisis parmi l'ensemble des comptes de la carte, sans empêcher que cette fonctionnalité soit offerte à l'utilisateur des autres comptes.
Cela permet corrélativement de développer une application indépendamment de ses futurs droits d'exécution, lesquels ne seront pris en compte qu'au moment du chargement de l'application dans la carte.
De même, l'unité d'interdiction peut être mise en oeuvre quel que soit le mode de déclenchement de l'exécution de l'application. L'invention apporte en cela une avancée significative, sachant qu'actuellement, il existe un très grand nombre de modes de déclenchement possibles d'une application par exemple, pour une carte d'abonnement à un opérateur de télécommunications mobiles comportant une plateforme JavaCard, on connaît près de 80 façons de déclencher une appliquette contenue dans la carte. Si on se bornait à adapter le menu correspondant à chaque compte, l'appliquette pourrait être lancée par un autre moyen, tel que la réception d'un message court (SMS) par le téléphone mobile.
Avantageusement, la carte à microcircuit comporte en outre une unité pour recevoir de l'extérieur, de façon sécurisée, les informations de droits d'exécution mentionnées ci-dessus.
Ainsi, l'émetteur de la carte peut donner accès en toute sécurité à des fonctionnalités différentes compte par compte.
2864294 5 Avantageusement, l'unité de mémorisation est adaptée à mémoriser une table de correspondance entre une pluralité d'applications, susceptibles d'être exécutées sur un compte de la pluralité de comptes, et des comptes de la pluralité de comptes, sur lesquels l'exécution d'une application est autorisée ou interdite. L'unité d'interdiction coopère avec cette table de correspondance, pour vérifier, à réception d'une commande impliquant le lancement de l'exécution d'une application, que l'exécution de cette application sur le compte en cours d'utilisation est autorisée.
Cette caractéristique est particulièrement simple à mettre en oeuvre.
Dans un mode particulier de réalisation, l'application est une appliquette.
Le contexte JavaCard est un domaine d'application privilégié, mais non exclusif, de l'invention. Dans ce contexte, l'application considérée est un applet Java. Dans ce cas, l'expression "exécution de l'applet" désigne, par abus de langage, l'exécution d'une ou plusieurs méthodes de cet applet.
Avantageusement, l'unité de mémorisation contient un ou plusieurs composants du "CAP file" ou fichier d'exécution de l'appliquette et ces composants contiennent les informations de droits d'exécution.
Cette caractéristique est simple à mettre en oeuvre et est en outre compatible avec la forme normalisée du "CAP file".
Dans un exemple particulier d'application de l'invention, la carte à microcircuit considérée consiste en une carte d'abonnement à un opérateur de télécommunications mobiles. Il s'agit de l'application immédiate de l'invention, puisqu'il existe des cartes multi-compte dans ce domaine.
Dans cet exemple, l'unité d'interdiction comporte avantageusement des menus d'affichage sur l'écran d'un téléphone mobile coopérant avec la carte qui diffèrent selon les comptes. Comme indiqué plus haut, cette caractéristique, combinée avec les autres caractéristiques de la carte à microcircuit conforme à l'invention, et en particulier son unité d'interdiction, permet d'interdire l'exécution d'une application indépendamment du mode de déclenchement de l'application.
II est ainsi fort aisé d'autoriser ou non l'utilisateur à faire exécuter une application donnée sur le compte qu'il est en train d'utiliser, en lui donnant ou non le choix, selon le menu disponible, de lancer cette application par sélection d'un élément du menu.
2864294 6 Dans le même but que celui indiqué plus haut, l'invention propose également un procédé de communication entre une carte à microcircuit telle que décrite succinctement ci-dessus et au moins une entité extérieure, remarquable en ce qu'il comporte une étape de configuration de la carte, consistant, pour l'entité extérieure, à transmettre de façon sécurisée à la carte les informations de droits d'exécution de l'application.
Les avantages du procédé de communication sont similaires à ceux de la carte à microcircuit et ne sont donc pas répétés ici.
Dans un mode particulier de réalisation, l'étape de configuration est intégrée à une étape d'installation définie par la norme d'infrastructure de cartes à microcircuit GlobalPlatform, par ajout d'un champ optionnel dans la commande d'installation.
Cette caractéristique est simple à mettre en oeuvre et est de plus compatible avec les normes actuelles, qu'il est très aisé d'adapter.
Dans un mode de réalisation où l'application est une appliquette, l'étape de configuration peut consister à transmettre à la carte un ou plusieurs composants du "CAP file" ou fichier d'exécution de l'appliquette; ces composants contiennent dans ce cas les informations de droits d'exécution.
Dans un mode particulier de réalisation, l'appliquette comporte des instructions pour enregistrer dans la carte des droits d'exécution contenus dans les informations de droits d'exécution.
Ces instructions sont avantageusement contenues dans le constructeur de l'appliquette.
Lorsque la carte à microcircuit comporte en mémoire, comme décrit brièvement plus haut, une table de correspondance entre des applications et des comptes, l'étape d'installation du procédé de communication conforme à l'invention peut comporter en outre une étape de création ou de mise à jour de cette table de correspondance.
Dans un mode particulier de réalisation, le procédé de communication comporte en outre une étape de chargement de l'application dans la carte.
Il est particulièrement commode de définir les droits d'exécution lors du chargement d'une application, au début de la vie d'une carte (en phase de personnalisation ou de pré-personnalisation) ou au cours de la vie de la carte (c'est-à-dire après livraison de celle-ci, i.e. en "post-issuance").
Dans le même but que celui indiqué plus haut, l'invention propose en outre une appliquette adaptée à s'exécuter sur un compte d'une carte à microcircuit telle que succinctement décrite ci-dessus, cette appliquette étant remarquable en ce qu'elle comporte des instructions pour enregistrer dans la carte des droits d'exécution contenus dans les informations de droits d'exécution.
Ces instructions sont avantageusement contenues dans le constructeur de l'appliquette.
Toujours dans le même but, l'invention propose aussi un fichier d'exécution d'une appliquette ou "CAP file", cette appliquette étant adaptée à s'exécuter sur un ou plusieurs comptes d'une carte à microcircuit telle que succinctement décrite ci-dessus, ce fichier étant remarquable en ce qu'il comporte un ou plusieurs composants contenant les informations de droits d'exécution de l'appliquette.
Les avantages de l'appliquette et du "CAP file" sont similaires à ceux de la carte à microcircuit et du procédé de communication conformes à l'invention et ne sont donc pas rappelés ici.
D'autres aspects et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit de modes particuliers de réalisation, donnés à titre d'exemples non limitatifs. La description est faite en référence aux dessins qui l'accompagnent, dans lesquels: - la figure 1 représente de façon schématique une carte à microcircuit conforme à l'invention, dans un premier mode particulier de réalisation; - les figures 2A et 2B représentent des exemples de réalisation d'une table de correspondance entre applications et comptes, conformément à la présente invention; - la figure 3 représente schématiquement un "CAP file" ou fichier d'exécution d'une appliquette avec des composants conformes à la présente invention, dans un mode particulier de réalisation; - la figure 4 illustre schématiquement une étape de configuration d'une carte à microcircuit et une étape de chargement d'une application dans la carte, ces étapes faisant partie d'un procédé de communication conforme à l'invention entre la carte et une entité extérieure; et - la figure 5 illustre schématiquement une commande d'installation conforme à l'invention, adaptée à partir de la norme GlobalPlatform, norme d'infrastructure de cartes à microcircuit.
Dans un premier mode particulier de réalisation de l'invention, illustré sur la figure 1, une carte à microcircuit 10 conforme à la présente invention comporte une unité centrale de traitement CU 12, auxquelles sont associées de façon classique une mémoire RAM 13, une mémoire EEPROM 15, une mémoire ROM 17 et un port d'entrées/sorties 18.
La mémoire EEPROM 15 est adaptée à mémoriser, sous diverses formes dont deux en particulier sont décrites plus en détail ci-après, des informations qui représentent des droits d'exécution d'une ou plusieurs applications sur un ou plusieurs des comptes de la carte, c'est-à-dire des informations qui indiquent si l'exécution d'une application sur un compte donné de la carte est autorisée ou non.
La carte à microcircuit 10 conforme à l'invention comporte en outre une unité d'interdiction, adaptée à interdire, en fonction des informations précitées de droits d'exécution, l'exécution de l'application sur un ou plusieurs comptes spécifiques choisis parmi l'ensemble des comptes de la carte, l'exécution de cette application restant autorisée sur les autres comptes. Comme on le verra par la suite, cette unité d'interdiction peut être constituée, soit par un ensemble composé d'un répartiteur 26 et d'une table de correspondance 16, soit par un ensemble composé d'une machine virtuelle 19 et d'un "CAP file" 24.
Dans le mode de réalisation de la figure 1, l'unité d'interdiction 12, 14 de la carte à microcircuit 10 comporte une table de correspondance T (désignée par le chiffre de référence 16 sur le dessin) entre les applets et les comptes autorisés ou interdits.
La table de correspondance 16 peut être réalisée de diverses façons. On donne ci-dessous à titre nullement limitatif, en liaison avec les figures 2A et 2B, des exemples d'implantation de cette table.
2864294 9 Enfin, la carte à microcircuit 10 conforme à la présente invention est adaptée à communiquer avec une entité extérieure 22, par l'intermédiaire d'un réseau 20.
Comme le montre la figure 2A, on peut définir pour chaque compte une liste d'applets autorisés à s'exécuter sur ce compte. Ces informations de droits d'exécution sont par exemple mémorisées dans la table 16 sous forme d'un fichier, par exemple un fichier linéaire (c'est-à-dire où un accès direct aux enregistrements est possible, par opposition à un fichier transparent, accessible bit à bit) EFAPPLET_x, où X désigne le compte concerné. La figure 2A montre que la table 16 mémorise, pour chaque champ du fichier: la taille du champ (en nombre d'octets, représentée arbitrairement dans la colonne de gauche sur le dessin), - le contenu du champ (représenté arbitrairement dans la colonne du milieu) et - la longueur du champ (en bits, représentée arbitrairement dans la colonne de droite).
Dans la variante illustrée sur la figure 2B, on définit, pour chaque applet, la liste des comptes sur lesquels l'exécution de cet applet est autorisée. La table de correspondance 16 mémorise ces informations des droits d'exécution par exemple sous la forme d'un fichier linéaire EFAPPLET définissant dans chaque enregistrement l'identifiant de l'applet ainsi que la liste des abonnements autorisés à y accéder. De même que dans l'exemple de la figure 2A, la table 16 mémorise, pour chaque champ du fichier, sa taille (en octets), son contenu et sa longueur (en bits).
Les fichiers EFAPPLET x et EFAPPLET peuvent tout aussi bien définir, soit les applets autorisés pour chaque compte et les comptes autorisés pour chaque applet, respectivement, soit les applets et les comptes interdits, respectivement.
Dans les exemples des figures 2A et 2B, les fichiers linéaires variables (EFAPPLET x et EFAPPLET) sont mémorisés dans la carte en mémoire non volatile, par exemple dans I'EEPROM ou dans une mémoire Flash. Leur mise à jour peut être effectuée à divers stades, tels que lors du chargement de l'applet dans la carte ou encore lors de la création d'un compte dans la carte, que ce soit au moment de la phase de pré-personnalisation de la carte, au moment de la 2864294 10 personnalisation de la carte, ou après livraison de celle-ci (c'est-à-dire en "postissuance").
Ces réalisations impliquent une adaptation du système d'exploitation de la carte. La table de correspondance coopère en effet avec le répartiteur D (désigné par le chiffre de référence 26 sur la figure 1) de la carte à microcircuit.
Pour mémoire, le répartiteur (en anglais "dispatcher") est défini par la norme GSM 11.14 et ses évolutions. C'est le programme du système d'exploitation réalisant l'interprétation des commandes et le lancement de l'exécution des programmes résultant de cette interprétation.
En particulier, les programmes dont l'exécution est lancée peuvent être des applets. Le répartiteur 26 selon l'invention est adapté à vérifier, avant de lancer l'exécution d'un applet, lorsqu'il reçoit une commande qu'il interprète comme nécessitant le lancement de l'exécution d'un applet, que l'exécution de cet applet est bien autorisée sur le compte en cours d'utilisation. Pour cela, le répartiteur 26 lit le fichier EFAPPLET x ou EFAPPLET.
Dans un deuxième mode particulier de réalisation de l'invention, on peut choisir de permettre le blocage de l'exécution d'un applet en ajoutant à cet effet un ou plusieurs composants dans le fichier d'exécution de l'applet, appelé aussi le "CAP file". Les informations de droits d'exécution sont alors contenues dans ce ou ces composants du "CAP file". Le "CAP file" est mémorisé en EEPROM dans la carte à microcircuit (il est désigné par le chiffre de référence 24 sur la figure 1).
Dans ce cas, la carte comporte une machine virtuelle JavaCard adaptée à interpréter ce ou ces composants du "CAP file" ; dans un tel cas, la machine virtuelle et le "CAP file" constituent l'unité d'interdiction 19, 24. Ils possèdent des indications sur les droits d'exécution de l'applet vis-à-vis du compte en cours d'utilisation. En fonction de ces indications, la machine virtuelle pourra autoriser ou interdire l'exécution de l'applet sur ce compte.
Pour mémoire, un applet est mémorisé dans une carte à microcircuit, par exemple en mémoire EEPROM ou ROM, sous la forme d'un fichier appelé "CAP file". Ce fichier d'exécution de l'applet est issu de la compilation des fichiers JavaCard. Pour exécuter l'applet, la carte comporte une machine virtuelle qui lit le "CAP file".
Comme le montre la figure 3, le "CAP file" 30 est composé d'un certain nombre d'enregistrements R1, R2, ..., Rn ou composants, appelés aussi TLV, où T désigne le type d'enregistrement ou identifiant (en anglais "Tag"), L désigne la longueur de l'enregistrement (en anglais "Length") et V désigne le contenu ou valeur de l'enregistrement (en anglais "Value"). La présence de l'identifiant permet de distinguer les différents types de composants: importation des applications, identification de l'application, code proprement dit, etc. Un de ces composants est le code de l'applet ou "byte code".
Le "CAP file" contient ainsi l'ensemble de l'applet ainsi que les paramètres nécessaires pour son installation et son fonctionnement.
La figure 3 montre également la définition typique d'un composant du "CAP file" : component { ul tag u2 size u3 info[] A la lecture du "CAP file", la machine virtuelle, lorsqu'elle rencontre un composant dont l'identifiant a une valeur prédéterminée, va lire l'attribut "info" pour déterminer sur quel compte l'applet peut s'exécuter. L'attribut "info" peut par exemple comporter la liste des droits d'exécution de l'applet.
La spécification JavaCard autorise l'ajout de composants dans le "CAP file", moyennant une taille de 128 à 255 bits pour l'identifiant.
Dans un exemple particulier de réalisation où la carte à microcircuit 10 est une carte SIM d'abonnement à un opérateur de réseau de télécommunications, si la carte comporte un nombre de comptes N1, l'unité d'interdiction 12, 14 est par exemple constituée par N2 menus différents s'affichant sur l'écran du téléphone mobile de l'utilisateur. D'une part, chacun des N2 menus est associé à un ou plusieurs des N1 comptes et d'autre part, à chacun des N1 comptes sont associés un ou plusieurs des N2 menus. Lors de l'utilisation d'un compte donné, seul les menus associés sont accessibles à l'utilisateur.
Dans un téléphone mobile comportant une carte à microcircuit incluant une plateforme JavaCard, la sélection d'un élément dans un menu sur l'écran du 2864294 12 téléphone peut entraîner l'exécution d'un applet correspondant à cet élément dans la carte SIM. Dans l'état de la technique, la carte à microcircuit se borne à mémoriser l'ensemble des menus affichés, tandis que conformément à la présente invention, la carte à microcircuit mémorise des menus différents selon les comptes utilisés et sélectionne pour affichage ceux qui sont associés au compte en cours d'utilisation. Par conséquent, lorsque l'utilisateur utilise un compte donné, il ne voit pas apparaître dans les menus associés les choix correspondant aux applets ne pouvant être exécutés sur ce compte.
La figure 4 illustre schématiquement une étape de configuration d'une carte à microcircuit, cette étape faisant partie d'un procédé de communication conforme à l'invention entre la carte 10 et une entité extérieure 22, qui peut par exemple être un opérateur de télécommunications. Lors de cette étape de configuration (plus particulièrement matérialisée sur le dessin par la flèche "droits"), l'entité extérieure 22 transmet de façon sécurisée à la carte les informations de droits d'exécution de l'application. L'unité d'entrée/sortie 18 de la carte 10 (voir figure 1), combinée à des moyens de réception d'un terminal de téléphonie mobile ou tout autre type de terminal (non représenté sur les dessins), permet à cette dernière de recevoir les informations de droits d'exécution de l'extérieur.
Ces informations de droits d'exécution peuvent comporter des identifiants de comptes de la carte sur lesquels l'exécution d'une application est autorisée ou interdite.
L'identifiant d'un compte peut être communiqué de façon directe à la carte. Dans l'exemple mentionné plus haut d'un compte PRO/PERSO d'un opérateur de télécommunications mobiles, cet identifiant peut être l'IMSI de l'un des deux abonnements (personnel ou professionnel).
L'identifiant d'un compte peut aussi être communiqué de façon indirecte. Par exemple, l'entité extérieure 22 peut communiquer à la carte 10 un identifiant précisant que c'est sur le compte professionnel que l'exécution de l'application est interdite, sans connaître l'IMSI, en utilisant simplement l'identifiant du compte professionnel. La carte est alors capable de retrouver l'IMSI concerné.
En variante, la carte peut communiquer avec non pas une, mais plusieurs entités extérieures, qui transmettront alors chacune de façon sécurisée les informations de droits d'exécution d'une ou plusieurs applications vis-à-vis des comptes de la carte.
Dans un mode particulier de réalisation, l'étape de configuration de la carte décrite ci-dessus est intégrée à l'étape d'installation telle que définie dans la norme GlobalPlatform. Pour cela, un champ supplémentaire optionnel est ajouté dans la commande d'installation.
Lorsque l'application est un applet, lors de l'étape de configuration, l'entité extérieure 22 transmet à la carte 10 un ou plusieurs composants du "CAP file", qui contiennent les informations de droits d'exécution de l'applet sur les comptes de la carte. De préférence, l'applet comporte dans son constructeur des instructions pour enregistrer dans la carte ses propres droits d'exécution. La table de correspondance est créée, si elle n'existe pas encore, ou mise
à jour, si elle a déjà été créée, au cours de l'étape d'installation.
Dans le mode particulier de réalisation de la figure 4, le procédé de communication selon l'invention comporte, outre l'étape de configuration de la carte, une étape de chargement de l'application dans la carte (plus particulièrement illustrée par la flèche "chargement").
II peut être utile de modifier les droits d'exécution d'un applet indépendamment du chargement de cet applet. Un opérateur d'un réseau de télécommunications mobiles peut autoriser l'exécution d'un applet sur un compte sur lequel elle était précédemment interdite, par exemple à la suite de la mise en place d'un nouveau service sur ce compte.
Pour cela, l'opérateur peut par exemple mettre à jour à distance le fichier EFAPPLET_X OU EFAPPLET décrit plus haut, par l'envoi d'un SMS sécurisé (c'est-à- dire typiquement crypté et authentifié, par des méthodes connues de l'homme du métier) à la carte, comme illustré sur la figure 4. Ce SMS comporte notamment la clé d'accès au fichier EFAPPLET X ou EFAPPLET et déclenche l'exécution d'une commande de mise à jour (par exemple: "Update Record") dans la carte.
Comme le montre la figure 5, lorsque l'étape de configuration de la carte est intégrée à l'étape d'installation définie par la norme GlobalPlatform et que la commande d'installation (INSTALL(INSTALL)) telle que définie par cette norme contient un champ supplémentaire optionnel, le contenu et la longueur de ce champ se présentent sous la forme illustrée en grisé sur le dessin.
2864294 14 Ainsi, dans l'exemple de réalisation illustré ici, le champ optionnel "Liste abonnés" (accompagné d'un paramètre "O" désignant ce caractère optionnel, figurant arbitrairement dans la colonne de gauche sur le dessin) comprend la liste des identifiants des comptes de la carte sur lesquels l'exécution de l'applet est autorisée ou interdite.
Cette commande d'installation est reçue par exemple sous la forme d'une commande APDU.
Le champ optionnel "Liste abonnés" est interprété par le gestionnaire d'application (constitué par du code stocké en ROM, faisant partie du système d'exploitation de la carte), qui met alors à jour toutes les informations nécessaires dans la carte, notamment la table de correspondance 16.
Tous les champs autres que les champs optionnels illustrés sur la figure 5 sont connus de l'homme du métier et définis dans la norme GlobalPlatform.
En variante, on peut inclure dans l'applet un programme d'enregistrement des droits d'exécution de l'applet sur la carte. De préférence, ce programme est dans le constructeur de l'applet, et par conséquent, dans le code de l'applet.
Cette variante présente l'avantage que le programme du constructeur est systématiquement lancé à chaque installation de l'applet. La mise à jour de l'enregistrement des droits d'exécution est ainsi garantie, par exemple, sous la forme d'une mise à jour de la table de correspondance 16 dans sa variante illustrée sur la figure 5.
Dans une autre variante, dans laquelle on choisit d'ajouter un composant dans le "CAP file", on peut utiliser des logiciels connus, tels que l'outil Converter de Sun Microsystems, pour réaliser la conversion d'un fichier objet, généralement appelé "fichier.class", en un fichier "CAP", généralement appelé "fichier.cap", après compilation du code JavaCard. Conformément à la présente invention, on peut modifier cet outil de façon qu'il ajoute automatiquement dans le "CAP file" le composant requis décrit plus haut.
A l'exception de la solution consistant à inclure dans l'applet un programme d'enregistrement des droits d'exécution de l'applet sur la carte, l'ensemble des modes particuliers de réalisation précédemment décrits présente un avantages en commun, à savoir, le fait que l'applet peut être développé 2864294 15 indépendamment des droits d'exécution. Ces derniers dont pris en compte uniquement au moment du chargement de I'applet dans la carte.
Claims (2)
16 REVENDICATIONS
1. Carte à microcircuit (10) comportant une pluralité de comptes, des moyens pour basculer d'un compte à un autre, des moyens pour exécuter une application impliquant une intervention sur un compte et des moyens (15) de mémorisation, caractérisée en ce que: - les moyens (15) de mémorisation sont adaptés à mémoriser des informations de droits d'exécution de ladite application sur un ou plusieurs comptes, - la carte à microcircuit (10) comporte en outre des moyens (16, 26; 19, 24) pour interdire, en fonction desdites informations de droits d'exécution, l'exécution de ladite application sur un ou plusieurs comptes spécifiques choisis parmi ladite pluralité de comptes, l'exécution de l'application sur les autres comptes restant autorisée.
2. Carte à microcircuit (10) selon la revendication 1, caractérisée en ce qu'elle comporte en outre des moyens (18) pour recevoir de l'extérieur, de façon sécurisée, lesdites informations de droits d'exécution.
3. Carte à microcircuit (10) selon la revendication 1 ou 2, caractérisée en ce que: - lesdits moyens (15) de mémorisation sont adaptés à mémoriser une table de correspondance (16) entre une pluralité d'applications, susceptibles d'être exécutées sur un compte de la pluralité de comptes, et des comptes de ladite pluralité de comptes, sur lesquels l'exécution d'une application est autorisée ou interdite; lesdits moyens (16, 26; 19, 24) d'interdiction coopérant avec ladite table de correspondance (16), pour vérifier, à réception d'une commande impliquant le lancement de l'exécution d'une application, que l'exécution de cette application sur le compte en cours d'utilisation est autorisée.
4. Carte à microcircuit (10) selon la revendication 1, 2 ou 3, caractérisée en ce que ladite application est une appliquette.
5. Carte à microcircuit (10) selon la revendication précédente, caractérisée en ce que les moyens de mémorisation contiennent un ou plusieurs 2864294 17 composants du "CAP file" (30) ou fichier d'exécution de l'appliquette et en ce que lesdits composants contiennent lesdites informations de droits d'exécution.
6. Carte à microcircuit (10) selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle consiste en une carte d'abonnement à un opérateur de télécommunications mobiles.
7. Carte à microcircuit (10) selon la revendication précédente, caractérisée en ce que les moyens (16, 26 19, 24) d'interdiction comportent des menus d'affichage sur l'écran d'un téléphone mobile coopérant avec la carte qui diffèrent selon les comptes.
8. Procédé de communication entre une carte à microcircuit (10) selon l'une quelconque des revendications précédentes et au moins une entité extérieure (22), caractérisé en ce qu'il comporte une étape de configuration de la carte (10), consistant, pour l'entité extérieure (22), à transmettre de façon sécurisée à la carte lesdites informations de droits d'exécution de ladite application.
9. Procédé selon la revendication précédente, caractérisé en ce que l'étape de configuration est intégrée à une étape d'installation définie par la norme d'infrastructure de cartes à microcircuit GlobalPlatform, par ajout d'un champ optionnel dans la commande d'installation.
10. Procédé selon la revendication 8 ou 9, dans lequel l'application est une appliquette, caractérisé en ce que ladite étape de configuration consiste à transmettre à la carte (10) un ou plusieurs composants du "CAP file" (30) ou fichier d'exécution de l'appliquette et en ce que lesdits composants contiennent lesdites informations de droits d'exécution.
11. Procédé selon la revendication précédente, caractérisé en ce que l'appliquette comporte des instructions pour enregistrer dans la carte (10) des droits d'exécution contenus dans lesdites informations.
12. Procédé selon la revendication précédente, caractérisé en ce que lesdites instructions sont contenues dans le constructeur de l'appliquette.
13. Procédé selon la revendication 9, pour communiquer avec une carte à microcircuit (10) selon la revendication 3, caractérisé en ce que ladite étape d'installation comporte en outre une étape de création ou de mise à jour de ladite table de correspondance (16).
2864294 18 14. Procédé selon l'une quelconque des revendications 8 à 13, caractérisé en ce qu'il comporte en outre une étape de chargement de ladite application dans la carte (10).
15. Appliquette adaptée à s'exécuter sur un compte d'une carte à microcircuit (10) selon l'une quelconque des revendications 1 à 7, caractérisée en ce qu'elle comporte des instructions pour enregistrer dans la carte des droits d'exécution contenus dans les informations de droits d'exécution.
16. Appliquette selon la revendication précédente, caractérisée en ce que lesdites instructions sont contenues dans le constructeur de l'appliquette.
17. Fichier d'exécution d'une appliquette ou "CAP file" (30), ladite appliquette étant adaptée à s'exécuter sur un ou plusieurs comptes d'une carte à microcircuit (10) selon l'une quelconque des revendications 1 à 7, ledit fichier étant caractérisé en ce qu'il comporte un ou plusieurs composants contenant lesdites informations de droits d'exécution de ladite appliquette.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0314805A FR2864294B1 (fr) | 2003-12-17 | 2003-12-17 | Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant |
| PCT/FR2004/003254 WO2005059847A1 (fr) | 2003-12-17 | 2004-12-16 | Carte a microcircuit multi-compte permettant la restriction d’une fonctionnalite a un compte et procede de communication correspondant |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0314805A FR2864294B1 (fr) | 2003-12-17 | 2003-12-17 | Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| FR2864294A1 true FR2864294A1 (fr) | 2005-06-24 |
| FR2864294B1 FR2864294B1 (fr) | 2006-03-24 |
Family
ID=34630248
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0314805A Expired - Fee Related FR2864294B1 (fr) | 2003-12-17 | 2003-12-17 | Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant |
Country Status (2)
| Country | Link |
|---|---|
| FR (1) | FR2864294B1 (fr) |
| WO (1) | WO2005059847A1 (fr) |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1998009257A1 (fr) * | 1996-08-30 | 1998-03-05 | Gemplus S.C.A. | Systeme et procede pour charger des applications dans une carte a puce |
| WO2000067212A1 (fr) * | 1999-04-29 | 2000-11-09 | Schlumberger Systemes | Procede de gestion de commandes dans plusieurs fichiers d'application et carte a puce pour la mise en oeuvre du procede |
| US6216014B1 (en) * | 1996-05-17 | 2001-04-10 | Gemplus | Communication system for managing safely and independently a plurality of applications by each user card and corresponding user card and management method |
| WO2001084512A1 (fr) * | 2000-04-28 | 2001-11-08 | Gemplus | Carte a puce multi-applicatives |
| WO2002076126A2 (fr) * | 2001-03-16 | 2002-09-26 | Schlumberger Systèmes | Module d'identification d'abonne permettant de gerer de maniere independante et sure une pluralite de commandes d'au moins un applet, plus particulierement pour un dispositif de communication mobile |
-
2003
- 2003-12-17 FR FR0314805A patent/FR2864294B1/fr not_active Expired - Fee Related
-
2004
- 2004-12-16 WO PCT/FR2004/003254 patent/WO2005059847A1/fr active Application Filing
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6216014B1 (en) * | 1996-05-17 | 2001-04-10 | Gemplus | Communication system for managing safely and independently a plurality of applications by each user card and corresponding user card and management method |
| WO1998009257A1 (fr) * | 1996-08-30 | 1998-03-05 | Gemplus S.C.A. | Systeme et procede pour charger des applications dans une carte a puce |
| WO2000067212A1 (fr) * | 1999-04-29 | 2000-11-09 | Schlumberger Systemes | Procede de gestion de commandes dans plusieurs fichiers d'application et carte a puce pour la mise en oeuvre du procede |
| WO2001084512A1 (fr) * | 2000-04-28 | 2001-11-08 | Gemplus | Carte a puce multi-applicatives |
| WO2002076126A2 (fr) * | 2001-03-16 | 2002-09-26 | Schlumberger Systèmes | Module d'identification d'abonne permettant de gerer de maniere independante et sure une pluralite de commandes d'au moins un applet, plus particulierement pour un dispositif de communication mobile |
Non-Patent Citations (1)
| Title |
|---|
| "globalplatform Card Specification Version 2.1.1", March 2003, GOLBALPLATFORM INC., XP002290114 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2005059847A1 (fr) | 2005-06-30 |
| FR2864294B1 (fr) | 2006-03-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0906603B1 (fr) | Systeme de communication permettant une gestion securisee et independante d'une pluralite d'applications par chaque carte utilisateur, carte utilisateur et procede de gestion correspondants | |
| EP2008483A1 (fr) | Procede de securisation de l'acces a un module de communication de proximite dans un terminal mobile | |
| EP2047697B1 (fr) | Personnalisation d'un terminal de radiocommunication comprenant une carte sim | |
| WO2002042912A1 (fr) | Execution d'une application dans un objet electronique portable a faible capacite de memoire | |
| EP1388134A1 (fr) | Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable | |
| WO2009007653A1 (fr) | Procédé de protection des applications installées sur un module sécurisé, terminal, module de sécurité et équipement communicant associés | |
| EP2912640B1 (fr) | Procédé de gestion d'identifiants dans une carte a circuit integré et carte a circuit integré correspondante | |
| WO2007144509A2 (fr) | Dispositif de memorisation amovible et appareil electronique aptes a l ' autre et procede de sauvegarde de donnees d ' environnement | |
| WO2000042731A1 (fr) | Procede de chargement securise de donnees entre des modules de securite | |
| FR2864294A1 (fr) | Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant | |
| WO2007080328A2 (fr) | Procédé de génération d'un profil pour la personnalisation d'une entité électronique et système associé | |
| EP3646215B1 (fr) | Procédé de contrôle d'accès à un module de sécurité | |
| EP1578064B1 (fr) | Procédé d'accès à un service par l'intermédiaire d'un terminal relié à un réseau de communication | |
| EP0974131B1 (fr) | Procede d'interpretation dynamique de donnees pour une carte a puce | |
| EP3648491B1 (fr) | Element securise multi-configurations et procede associe | |
| EP1413158B1 (fr) | Procede d'acces a un service specifique propose par un operateur virtuel et carte a puce d'un dispositif correspondant | |
| FR2765362A1 (fr) | Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires | |
| EP2284751B1 (fr) | Procédé de traçabilité et d'imputabilité dynamiques des échanges dans un environnement ouvert de type internet | |
| FR2795905A1 (fr) | Telephone mobile avec une architecture a plusieurs supports a puce | |
| WO2002008897A1 (fr) | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant | |
| FR3037685A1 (fr) | Procede et systeme ameliores de selection implicite d'une application dans un element securise, a partir d'un message recu | |
| EP3912065A1 (fr) | Autorisation du chargement d'une application dans un élément de sécurité | |
| EP1233383A1 (fr) | Procédé et dispositif de gestion d'applications de cartes à puce | |
| EP1337980A1 (fr) | Carte a puce avec descripteur d'application | |
| FR2798497A1 (fr) | Systeme et methode de chargement de donnees dans une carte a puce a travers un reseau de telecommunication au moyen de mels |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PLFP | Fee payment |
Year of fee payment: 13 |
|
| PLFP | Fee payment |
Year of fee payment: 14 |
|
| PLFP | Fee payment |
Year of fee payment: 15 |
|
| PLFP | Fee payment |
Year of fee payment: 17 |
|
| CA | Change of address |
Effective date: 20201228 |
|
| CD | Change of name or company name |
Owner name: IDEMIA FRANCE, FR Effective date: 20201228 |
|
| ST | Notification of lapse |
Effective date: 20210805 |