Brevet FR2808359A1 — publié le 20011102

CARTE A PUCE MULTI-APPLICATIVES. La présente invention concerne de manière générale les cartes à puce, et plus particulièrement les cartes à puce multi-applicatives. Elle s'applique également à tout autre support portable à puce, tel que porte-clé à puce. Recommandations 7816-1 et 2 définissent les spécificités physiques des cartes a puce. puce d'une carte à puce est un composant électronique comprenant des ressources matérielles sous la forme de moins une zone de mémoire, et unité de traitement supportant des fonctions dites natives, qui sont intégrées par masquage dans la puce lors de sa fabrication. puce comprend, en outre, un système d'exploitation. Ce système d'exploitation défini dans le cadre de la présente invention comme un logiciel, ou une interface logicielle, d'accès aux et de gestion des ressources physiques matérielles (mémoires, unité d'entrée/sortie, interruptions, etc.... ) de la puce. système d'exploitation est typiquement inscrit dans une partie de mémoire de la puce. Ce système d'exploitation assure par exemple la gestion entrées/sorties, la gestion des interruptions, la gestion des fichiers/espaces mémoires. II rend ainsi possible le développement d'une application sans connaissance par le développeur des ressources physiques matérielles de la puce destinée à mettre en oeuvre cette application. Les ressources physiques sont en quelque sorte traduites par le système d'exploitation sous la forme de ressources logiques , telles que des commandes élémentaires. Lorsqu'un programme applicatif déterminé est exécuté par la puce de la carte, le système d'exploitation est mis à contribution dans les fonctions de gestion précitées. technologies de la carte à puce ont été marquées ces dernières années évolution importante, à savoir l'arrivée de cartes à puce dites "ouvertes". cartes à puce ont en effet évolué en n'étant au départ que des dispositifs propriétaires et dédiés à une ou des applications bien particulière(s) pour devenir des supports propres au développement d'applications ouvertes, à partir desquels tous les programmeurs peuvent développer des applications utilisant un langage commun standard. A titre d'exemple, le standard JavaCard TM promu et licensié par ou la solution Smart Card for VVindowsTM licensiée par MICROSOFT Corp. propose chacun une interface ouverte sous la forme de (1) - un logiciel type Machine Virtuelle offrant une interopérabilité de la carte indépendamment de son système d'exploitation, ce logiciel permettant notamment développement de programmes applicatifs dans un langage donné indépendamment du système d'exploitation ; et (2) - un logiciel d'interface de programmation, formant partie du système d'exploitation offrant une interopérabilité de la carte indépendamment du matériel, ou hardware en terminologie anglo-saxonne. Ces logiciels (1) (2) "masquent" l'unité de traitement et le système d'exploitation originels quels 'ils soient, et toute personne peut donc developper une quelconque application indépendamment des fonctions natives du système d'exploitation inclus initialement dans la carte. Il suffit à cette personne de connaître le langage informatique ouvert qui est supporté par la Machine Virtuelle de la carte. A titre d'exemple, ce langage informatique de développement d'application peut être Visual basic TM. L'objectif initial visé par la spécification d'une interface ouverte, qui est de permettre la définition d'une plate-forme ouverte et commune pour le développement d'une application par un tiers quelconque, est contrecarré par les offres multiples qui existent pour de telles interfaces ouvertes. D'une part, l'utilisateur de telles cartes devra posséder autant cartes qu'il existent de plateformes ouvertes permettant le développement d'applications, s'il souhaite accéder l'ensemble des applications existantes, ce qui à l'encontre de l'objectif visé de tels systèmes ouverts. II en résulte par ailleurs que chaque application développée pour une interface ouverte donnée devra être complètement conçue à nouveau lorsqu'elle devra être implémentée pour une autre interface ouverte. Afin de remédier aux inconvénients précités, l'invention fournit prévoit un support de type carte à puce comprenant une puce, la puce comprenant au moins une zone de mémoire et une unité de traitement, ladite au moins une zone de mémoire mémorisant un premier système d'exploitation, ou première interface logicielle d'accès à des ressources physiques. Le support se caractérise en ce que ladite au moins une zone de mémoire mémorise au moins second système d'exploitation, ou seconde interface logicielle d'accès à des ressources physiques, qui différent du premier système d'exploitation. Ainsi, applications développées pour chacun des deux systèmes d'exploitation peuvent etre mises en oeuvre par une même carte. Avantageusement, la mémoire mémorise en outre un programme pour initialiser l'un ou l'autre desdits premier et second systèmes d'exploitation, en résultat d'un échange de données entre ladite puce et une unité avec laquelle ladite puce communique. II peut être par ailleurs prévu qu'à chaque système d'exploitation est associé un couple de zones mémoire respectif, chaque couple de zones mémoire mémorisant un système d'exploitation respectif et des données utilisées produites par un programme applicatif, et que la puce mémorise, en outre, module de gestion mémoire pour refuser tout accès à l'un des systèmes d'exploitation et à des données d'un programme applicatif associé, par l'autre des systèmes d'exploitation ou par un quelconque autre programme applicatif défini pour cet autre système d'exploitation. Une unité pour communiquer avec un support de type carte conforme à l'invention comprend un moyen pour envoyer à ladite carte un message de sélection de système d'exploitation. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description qui suit, en référence dessins annexés correspondants dans lesquels - la Figure 1 une représentation schématique des couches matérielles et logicielles implementées dans une puce d'une carte à puce selon la technique antérieure; - la Figure 2 une représentation schématique des couches matérielles et logicielles implementées dans une puce d'une carte à puce selon l'invention - la Figure 3 un bloc-diagramme schématique d'une implémentation matérielle, ou hardware, d'une puce de carte selon l'invention; et - la Figure 4 est un organigramme d'un programme de sélection l'un quelconque des systèmes d'exploitation implémentés dans la puce de la carte à puce en résultat d'un échange de données entre ladite carte et une unite avec laquelle ladite carte communique. En référence ' la Figure 1, selon une réalisation donnée à titre d'exemple, dans une implémentation conventionnelle d'une interface ouverte par exemple type JavaCardTM dans une puce de carte à puce, la puce comprend une unité de traitement 1 (CPU) propre à exécuter des applications particulières 71, 73 ( Applets en terminologie anglo-saxonne). Des fonctions 2 de base (c'est a dire implémentées en software sous la forme d'un système d'exploitation originel) et/ou natives (c'est à dire implémentées dans le hardware de la puce) sont exécutées par la puce. Une machine virtuelle (Virtual Machine en littérature anglo-saxonne) 4 et des interfaces de programmation d'application (APIs) 3 sont mémorisées dans une zone mémoire de la puce. Ces machine 4 et interfaces de programmation d'application 3 comprennent chacune une partie qui est mise en oeuvre en fonction de l'unité de traitement 1 choisie, et une autre partie indépendante et identique quelque soit l'unité de traitement utilisée. La machine virtuelle 4 et les APIs 3 "masquent" l'unité de traitement CPU et le système d'exploitation originel quels qu'ils soient, et toute personne peut donc développer une quelconque application 71, 72, 73 indépendamment des fonctions natives et système d'exploitation inclus initialement dans la carte. Ces applications 71, 72, 73 peuvent, à titre d'exemple, être des applications bancaires, des applications de télécommunications, de porte-monnaie électronique, etc..... Un gestionnaire (non représenté) est utilisé pour sécuriser les accès aux différentes mémoires et zones de ces mémoires afin d'éviter par exemple l'accès par une application 71 à une zone de mémoire qui ne lui est pas allouée. Le repère 5 désigne un chargeur ( Loader en litterature anglo-saxonne). Ce chargeur 5 est un programme de software pour charger dans la puce de la carte les applications 71, 72, 73. II implémente un protocole d'échange avec un serveur distant ou une quelconque unité, tel que lecteur de carte, etc... avec laquelle la carte coopère pour le chargement d'applications, il assure le stockage dans la puce de cette application dans une zone de mémoire donnée, etc... Dans la description qui suit d'un support de type carte à puce, il est prévu selon l'invention que la puce intègre deux systèmes d'exploitation. En pratique, toujours selon l'invention, plus de deux systèmes d'exploitation peuvent être prévus. II est à noter que la demanderesse a mis au point une carte à puce de 2 Moctets, rendant possible l'intégration dans une puce de deux systèmes d'exploitation. En référence â Figure 2, une puce d'une carte à puce selon l'invention comprend une unité de traitement 1 (CPU) propre à exécuter premières applications 71, 72, 73, par exemple écrites en langage Visual ainsi que des secondes applications 81, 82, 83 par exemple écrite en langage JavaTM. En pratique, les applications 71, 72, 73, d'une part, et 81, 82, 83 ,d'autre peuvent être écrites dans un même langage, cela ne dépendant que Machines Virtuelles qui sont utilisées. Néanmoins, une application donnée devra préférentiellement être exécutée par l'un particulier des deux systèmes d'exploitation pour assurer son exécution dans un environnement approprié eu égard aux critères de sécurité, de temps de traitement, etc...., chaque système d'exploitation offrant un environnement particulier plus particulièrement adapté à certaines applications et pas à d'autres. Selon une caracteristique fondamentale de l'invention, au moins deux systèmes d'exploitation 20 21 sont mis en oeuvre dans la puce. L'homme du métier conviendra que chacune des références 20 et 21 ne repère qu'approximativement ce qu'il convient d'appeler Système d'exploitation , la définition système d'exploitation étant clairement admise dans le domaine technique cartes à puce. Chacun de ces deux systèmes d'exploitation est défini comme un ensemble de fonctions logicielles assurant la gestion des fonctions élémentaires matérielles (unité de traitement et mémoires) dans la puce. Certaines fonctions élémentaires matérielles peuvent être implémentées dans le hardware de la puce sous la forme de fonctions dites natives ou cablées, par exemple des fonctions de cryptographie. Dans la Figure 2, le premier système d'exploitation 20 est défini par la référence 2, et par une partie des éléments portant les références 4 et 3. Le second système d'exploitation 21 est défini par des portions des éléments portant les références 10, 11 et 12. Le premier système d'exploitation 20, déjà présenté en référence à la Figure 1, comprend une partie de la machine virtuelle 4 et des interfaces de programmation d'application (APIs) 3 qui sont mémorisées dans une zone de mémoire de la puce. Ces machine 4 et interface de programmation d'application 3 comprennent chacune une partie qui est mise en couvre en fonction du hardware utilisé, et une autre partie indépendante et identique quelque soit l'unité de traitement utilisée. outre, ces machine 4 et interface de programmation d'application 3 s'appuient les fonctions de base de système d'exploitation associées au repère 2. Les machine virtuelle 4 et les APIs 3 "masquent" l'unité de traitement CPU et système d'exploitation originel quels qu'ils soient, et toute personne peut donc developper une quelconque application 71, 72, 73 indépendamment des fonctions natives et système d'exploitation inclus initialement dans la carte. Ces applications 71, 72, 73 peuvent, à titre d'exemple, être des applications bancaires de télécommunications, de porte-monnaie électronique, etc..... Le second système d'exploitation, par exemple Smart Card for WindowsTM comprend pour sa part, un module de gestion des entrées/sorties 10, un module de cryptographie 11 et un module de gestion de fichiers 12. La puce mémorise, outre, des interfaces de programmation d'application (APIs) 14, un module de vérification des commandes et applications 13 et un module d'authentification et d'autorisation 15. Le second système d'exploitation est mis à contribution par la puce 1 pour exécuter les applications 71, 72, 73 qui sont supportées et exécutées au moyen d'un système d'exploitation différent de celui utilisé pour l'exécution des applications 8 1 , 82, 83. Les fonctions dites de base du système d'exploitation 21, telles que celles associées aux références 10, 11 et 12 sont ou bien implémentées en software (sous la forme d'un système d'exploitation originel) ou bien sous formes natives (c'est à dire implémentées dans le hardware de la puce). Comme montré dans la Figure 3, à chaque système d'exploitation et 21 est associé un couple de zones mémoire respectif (201, 202) et (211, 2) propre à memoriser lesdits systèmes d'exploitation et les données utilisées ou produites chaque programme applicatif. Un système d'exploitation donné et les données programme applicatif associé ne sont pas accessibles par un autre système d'exploitation ou par un quelconque autre programme applicatif défini pour cet autre système d'exploitation. Pour cela, un mécanisme de sécurité est prévu. L'unité de traitement 1 accède à travers un bus de données et de commande à différentes zones mémoire 201, 202 et 211, 212 à travers un module de gestion de mémoire M. Les zones mémoire 201, 21, sont des zones mémoire, typiquement ROM, qui mémorisent respectivement les systèmes d'exploitation et 21. Les zones mémoire de données 202, 212 sont des zones mémoire mémorisent respectivement les données propres à l'exécution d'un programme applicatif. Le module de gestion de mémoire M est sous la forme d'un programme logiciel qui gère l'accès et la sécurité des accès aux zones mémoire 201, 202 et 211, 212. Ce module de gestion de mémoire M opère de la manière suivante :lorsqu'un accès à une adresse donnée est demandé par l'unité de traitement 1, le module vérifie que l'adresse est une adresse d'une zone mémoire 201, 202 ou 211, 212 associée avec le seul des systèmes d'exploitation 20 ou 21 qui est actif au moment de la demande d'accès. Si tel est le cas, la demande d'accès est validée l'unité de traitement 1 accède alors à l'adresse mémoire demandée. Si tel n' le cas, le module de gestion de mémoire M renvoie un message d'interruption a l'unité de traitement 1. En référence à la Figure 4, il est maintenant expliqué en détails mécanisme d'activation de l'un ou l'autre des systèmes d'exploitation selon mode de réalisation préférentiel. Les deux systèmes d'exploitation cohabitant dans la carte, il est impératif de prévoir l'activation sélective de l'un ou l'autre de ces deux systèmes d'exploitation selon le programme applicatif à activer. L'invention prévoit d'utiliser avantageusement le fait qu'une carte opère en pratique en mode esclave, c'est à dire qu'elle exécute les opérations que lui demande d'exécuter une unité (lecteur, serveur distant, etc...) avec laquelle elle communique . Ainsi, à titre d'exemple, selon la Recommandation ISO 7816-4, la sélection d'un protocole, par exemple T=1 ou T=0, de communication entre l'unité et la carte est toujours décidée par cette unité, la puce dans la carte se limitant à activer circuits et éléments logiciels necessaires à l'activation du protocole sélectionne par l'unité. L'invention prévoit d'utiliser avantageusement cette caractéristique pour proposer que l'activation de l'un ou l'autre des systèmes d'exploitation se fasse à la demande de l'unité avec laquelle la carte communique: Comme montré dans la Figure 4, la carte à puce, introduite dans lecteur ou rentrant dans un champ électromagnétique, se trouve alimentée (Etape 30) par une source d'énergie. En réponse à cette alimentation, la carte active un module de boot , ou module logiciel de démarrage (Etape 31). Lors premier échange de données entre la carte (le module de boot) et l'unité, que lecteur, avec laquelle la carte communique, l'unité envoie à la carte un message de sélection de système d'exploitation. Ce message est reçu par la carte (Etape 32). En réponse à ce message, le module de boot initialise le système d'exploitation sélectionné (Etape typiquement en transmettant à l'unité de traitement 1 l'adresse d'une première instruction à exécuter du système d'exploitation sélectionné. Le systeme d'exploitation sélectionné est ainsi initialisé. L'application (porte-monnaie électronique, etc...) devant être mise en oeuvre est ensuite activée selon un schéma connu selon la technique antérieure pour le type d'application considéré (Etape 34). REVENDICATIONS 1 - Support type carte à puce comprenant une puce, ladite puce comprenant au moins zone de mémoire et une unité de traitement (1), ladite au moins une zone de mémoire (201, 202, 211, 212) mémorisant un premier système d'exploitation (20), ou première interface logicielle d'accès à des ressources physiques, caractérisé en ce que ladite au moins une zone de mémoire mémorise au moins second système d'exploitation (21), ou seconde interface logicielle d'accès à des ressources physiques, qui est différent du premier système d'exploitation (20). 2 - Support de type carte à puce conforme à la revendication 1, caracterisé en ce que ladite mémoire mémorise, en outre, un programme pour initialiser l'un ou l'autre desdits premier et second systèmes d'exploitation (20, 21), en résultat d'un échange de données entre ladite puce et une unité avec laquelle ladite puce communique. 3 - Support de type carte à puce conforme à l'une quelconque des revendications précédentes, caractérisé en ce qu'à chaque système d'exploitation ; 21) est associé un couple de zones mémoire respectif (201, 202; 211, 212), chaque couple de zones mémoire (201, 202; 211, 212) mémorisant un système d'exploitation respectif (20, 21) et des données utilisées ou produites par un programme applicatif (71, 72, 73; 81, 82, 83), et en ce que ladite puce mémorise, outre, un module de gestion mémoire (M) pour refuser tout accès à l'un des systèmes d'exploitation (20 ; 21) et à des données d'un programme applicatif (71, 72, 73 ; 81, 82, 83) associé, par l'autre (21, 20) des systèmes d'exploitation ou par un quelconque autre programme applicatif (81, 82, 83;71, 72, 73 )défini pour cet autre système d'exploitation. 4 - Unité pour communiquer avec un support de type carte à puce conforme à l'une quelconque des revendications précédentes, caractérisée en qu'elle comprend un moyen pour envoyer à ladite puce dudit support un message de sélection de système d'exploitation (31, 32).