WO2006000531A1 - Procede de gestion d'une carte a puce multi-applicative - Google Patents

Procede de gestion d'une carte a puce multi-applicative Download PDF

Info

Publication number
WO2006000531A1
WO2006000531A1 PCT/EP2005/052684 EP2005052684W WO2006000531A1 WO 2006000531 A1 WO2006000531 A1 WO 2006000531A1 EP 2005052684 W EP2005052684 W EP 2005052684W WO 2006000531 A1 WO2006000531 A1 WO 2006000531A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
card
provider
security domain
identifier
Prior art date
Application number
PCT/EP2005/052684
Other languages
English (en)
Inventor
François Millet
Jean-François DURIX
Original Assignee
Gemplus
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Gemplus filed Critical Gemplus
Priority to EP05752666A priority Critical patent/EP1769470A1/fr
Priority to US11/630,399 priority patent/US20080034423A1/en
Publication of WO2006000531A1 publication Critical patent/WO2006000531A1/fr

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
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • 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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data

Definitions

  • the present invention relates, in general, to the field of so-called “smart cards” (Smartcards in the English terminology), in the sense that such cards constitute an electronic data medium, which is in the form of a reduced format card, with more than one processing capacity implemented by a microprocessor and its operating system and their environment (memories of different types, inputs / outputs).
  • the invention more particularly relates to multi-application smart cards, comprising a plurality of applications installed on the same card, thus allowing the execution of advanced applications, dedicated to various uses.
  • it is mainly the issuing entity of the card that is competent as regards the management of the contents of the card.
  • the different security domains are implemented on the card through applications specific, one for each security domain, to implement and enforce the mode of operation defined contractually between the card issuer and each application provider.
  • These specific security domain applications include the role of authenticating and verifying the applications of the associated application provider during the download process. They also offer common services for all the applications of a given application provider, otherwise the execution of the application on the card is not possible.
  • the security domain of an application provider is therefore the application, created on the card during its initialization, which guarantees the proper functioning of the applications of this provider installed on the card after its delivery.
  • it is essential to ensure that the application in question is linked to the security domain of the card associated with the card. provider of the application concerned.
  • the application provider owner of the application in question, is assured that the rules of operation and use of its application on the card, set by contract with the card issuer, will be respected.
  • it is the issuing entity of the card that specifies the security domain associated with the application during its download.
  • the management of the life cycle of applications of an application provider is placed under the authority of the card issuer, in accordance with the operating conditions initially provided for by contract between the issuing entity and the provider.
  • the card issuing entity is entitled to take control of the application of an application provider already installed on the card, in particular to lock it so as to control access to it or to remove it from the card, when the agreement between the supplier and the issuing entity has expired for example.
  • no specific mechanism is provided on the card to ensure that the authorization of the application provider has been given by the latter to allow the deletion or locking of one or its applications on the card .
  • This authorization is important to the extent that a card application remains the responsibility of the provider of this application and any action on it should normally be performed with the consent of the provider of the application.
  • an application is loaded, it most often imports other applications or APIs.
  • the present invention which is based on these various findings, aims to provide specific mechanisms to ensure the authorization of an application provider prior to any action performed on an application delivered by this provider on a multi-application card, so that the application provider can control the access and use of its applications on the card and thus ensure in particular the respect of its property rights.
  • the present invention thus aims at reinforcing the conditions of realization of the contractual links which underlie the cooperation between the card issuing entity and the application provider, With this objective in view, the invention thus relates to a method for managing a multi-application electronic device, comprising an operating system designed to support a plurality of applications, each application belonging to an application provider.
  • the method being characterized in that upon receipt of an application loading command on the device, said operating system verifies that said application is associated with a security domain corresponding to the security domain of the provider of said application and, if successful verification, authorizes its loading and installation on the device by attaching automatically to said security domain.
  • the verification step consists of searching among the security domains installed on the device, the one whose application provider identifier corresponds to the identifier of the application to be loaded.
  • the received load control comprises, in addition to the application to be loaded, the application provider identifier corresponding to the security domain to be associated, the check consisting in checking that said identifier corresponds to to the identifier of said application.
  • a step of controlling access to at least one application installed on the device performed by the security domain of the application provider to which said application is associated is implemented by the operating system of the device, to allow an action on said application.
  • the access control consists of requesting the production of an electronic signature and verifying said signature.
  • the action on the application may be to delete said application the device.
  • the action on the application can still consist in locking the use of said application.
  • the action on the application can still consist in the at least partial use of said application by a new application loaded on the device belonging to another application provider.
  • the applications consist of API application programming interfaces.
  • the invention also relates to a multi-application smart card, characterized in that it comprises means for implementing the method as just described.
  • the card is a JavaCard type card.
  • FIG. 1 schematically illustrates the mode of management of the contents of the card according to the invention, during the loading and installation phase of an application on the card
  • FIG. 2 illustrates an example of the management mode of the contents of the card according to the invention , in the case an application import already installed on the map.
  • the multi-application smart card is based in a preferred embodiment on the operating system JavaCard (registered trademark).
  • FIG. 1 thus illustrates, in this context, a management mode of a multi-application card 10 equipped with its operating system OS, during a phase of loading an application in the card.
  • the application loaded in the card consists of an API application programming interface provided by a provider of applications Pl.
  • a security domain SD (P1) provider application has been implemented on the map and includes all applications and application programming interfaces belonging to this particular application provider.
  • the programming interfaces form a set of Java libraries, which group together predefined procedures and objects, which can be used in a modular way and which make it possible to implement Java applications.
  • AID for "Application Identifier”
  • RID for "Registered Application Provider Identifier”
  • OS operating system of the card upon receipt of the loading command APIl API programming interface on the card, OS operating system of the card will automatically check, as illustrated by the reference 20 of Figure 1, that the security domain SD (Pl) chosen for this application has the same RID as the application in question.
  • the operating system OS searches in a list that it has at its disposal referencing all the security domains installed on the card, a security domain whose RID identifier corresponds to the AID identifier of API1 to be loaded.
  • the security domain SD (Pl) is then found and the operating system OS then authorizes the loading and installation of APIl programming interface on the card by attaching it automatically to the associated security domain SD (Pl).
  • the RID identifier of the application provider corresponding to the security domain that is to be associated with the programming interface API1 is transmitted at the same time as the latter.
  • the verification 20 simply consists in verifying the correspondence of this RID identifier with the identifier AID of the application, to ensure that the application loaded API1 is connected to the security domain SD (P1) associated with the provider of the service. In the case where the verification described in 20 fails, the loading of the programming interface API1 is rejected by the card.
  • Another object of the invention is also to ensure by specific means provided on the card that we have the authorization of the relevant application provider when the OS operating system wishes to access an application of this provider already installed on the map, in order to perform any action on this application.
  • this action can consist of deleting the application or locking the use of this application on the card.
  • a privilege is then set for the security domains associated with application providers who wish to control access to their applications on the card and that their authorization is formally requested. before any action to delete or lock their applications installed on the card.
  • specific information makes it possible to characterize such a security domain and can then be used by the card's operating system as a criterion for determining whether access authorization exists, when it wishes to access an associated application. to this security domain to delete it for example.
  • the operating system when it sees this privilege, will have to call a particular interface on this security domain for the latter to give his authorization to access the application concerned by the deletion.
  • an electronic signature is added in the command issued by the operating system and this signature must be previously verified by the associated security domain.
  • This access control to an application on the map; imposed by the security domain of the application provider to which this application is associated, is also implemented in the case where the action on the application consists of a use, at least partially, of said application by a new application loaded on the map belonging to another application provider. Indeed, when a new application or programming interface is loaded, to be able to operate, it may be made to use other programming interfaces already installed on the card and belonging to a security domain of another provider of software. applications. In which case, it is important, in order to preserve the property rights of this application provider, to allow the latter to control the use of its applications or APIs on the map.
  • FIG. 2 illustrates an example of this management mode of the contents of the card, in the case of an application import already installed on the card by an application belonging to another application provider.
  • An SD security domain (Pl) associated with the application provider Pl is installed on the multi-application smart card 10.
  • the application programming interfaces API1, API2 and API3 belonging to this provider P1 have already been loaded and installed. on the map according to the management mode explained above with reference to Figure 1, thus being associated with the SD security domain (Pl).
  • a programming API P2, from a P2 application provider different from Pl, is loaded on the card.
  • this API interface P2 Pl wants to use the application vendor APIL already on the map. In other words, it must import resources from this API1 in order to be loaded on the map.
  • the programming interface API1 which must be imported by the programming interface API P2 which is being loaded, belongs to an SD security domain (Pl) that wants to control its access.
  • a privilege is defined for the security domain SD (Pl), which allows the operating system of the card to know that this security domain requires the production of a signature to allow the connection to its programming interface. APIl associated.
  • the operating system OS of the card seeing this privilege, before authorizing the linking between the programming interfaces API P2 and APIl, will call an interface on the security domain SD (Pl) so that the latter gives his authorization.
  • the signature which has normally been given by the application provider P1 to allow connection to its programming interface API1, must be added when the API programming interface P2 is loaded onto the card.
  • the operating system uses the verification of the signature and the security domain SD (Pl) will verify the signature, to give its authorization to use the resources of its APIl programming interface. If the signature is verified successfully, the P2 API is installed on the card. If unsuccessful, the P2 API is not allowed to load because this means that this application is trying to use resources that it can not access.
  • the operating system identifies the list of applications already installed on the card that wants to use the application being loaded and determines the security domains associated with these applications. applications.
  • the operating system performs this access control.
  • the features of the present invention may more generally apply to any multi-application electronic device, including a system. operating system intended to support a plurality of applications.
  • the present invention can be applied to the management of the content of a PC-type microcomputer, the transmitting entity then referring to the owner of the PC.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Mathematical Physics (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Stored Programmes (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention concerne un procédé de gestion d'un dispositif électronique multi-applicatif (10), tel qu'une carte à puce multi-applicative, comprenant un système d'exploitation (OS) prévu pour supporter une pluralité d'applications, chaque application appartenant à un fournisseur d'applications disposant d'un domaine de sécurité qui lui est propre installé initialement sur la carte, ledit procédé étant caractérisé en ce que, à la réception d'une commande de chargement d'une application (API1) sur le dispositif, ledit système d'exploitation vérifie (20) que ladite application est associée à un domaine de sécurité correspondant au domaine de sécurité (SD(P1)) du fournisseur de ladite application et, en cas de succès de la vérification, autorise son chargement et son installation sur la carte en la rattachant automatiquement audit domaine de sécurité (SD(P1)).

Description

PROCEDE DE GESTION D'ONE CARTE A PUCE MULTI-APPLICATIVE
La présente invention concerne, de façon générale, le domaine des cartes à puce dites «' intelligentes » (Smartcard selon la terminologie anglo-saxonne) , au sens où de telles cartes constituent un support électronique de données, qui se présente sous la forme d'une carte à format réduit, doté de plus d'une capacité de traitement mise en œuvre par un microprocesseur et son système d'exploitation et leur environnement (mémoires de différents types, entrées/ sorties) . l'invention concerne plus particulièrement les cartes à puce multi-applicatives, comprenant une pluralité d'applications installées sur la même carte, permettant donc l'exécution d'applications évoluées, dédiées à des usages variés. Dans ce contexte, c'est principalement l'entité émettrice de la carte qui est compétente en ce qui concerne la gestion du contenu de la carte. Ainsi, elle est seule à pouvoir exécuter certaines fonctions de gestion des applications, telles que le chargement d'une application sur la carte, l'installation de l'application ou encore la suppression de l'application de la carte. Les applications installées sur la carte sont typiquement développées par l'entité émettrice de la carte dans un environnement sécurisé. Toutefois, un déploiement d'applications sur la carte uniquement sous l'autorité de l'entité émettrice de la carte présente des inconvénients, en terme de souplesse et d'adaptabilité aux différents besoins des utilisateurs notamment. D'ailleurs, on cherche de plus en plus à faire de la carte à puce un environnement d'exécution de programme ouvert, permettant un chargement dynamique d'applications. On cherche également à rendre plus souples et plus évolutive la gestion des applications cartes. On se place donc dans un contexte où les applications cartes ne sont plus développées sous le contrôle de l'entité émettrice de la carte, mais sont développées et proposées par des fournisseurs d'applications tiers, qui sont propriétaires de leurs applications. Ces applications propriétaires sont susceptibles d'être chargées dynamiquement dans la carte postérieurement à sa délivrance par l'entité émettrice, à travers un réseau quelconque par exemple. II est donc nécessaire dans ce cas, pour le fournisseur d'applications, de passer des arrangements contractuels, tant commerciaux que techniques, entre lui et l'entité émettrice de la carte, afin de définir les conditions d'utilisation de son ou ses applications susceptibles d'être installées sur la carte. Ce contrat passé entre le fournisseur d'applications et l'entité émettrice de la carte se traduit concrètement par l'installation sur la carte, lors de son initialisation, d'un domaine de sécurité associé au fournisseur d'applications, qui correspond en quelque sorte à un droit d'usage donné par l'entité émettrice de la carte au fournisseur d'application. Ainsi, chaque application ultérieurement chargée sur la carte doit être associée à un domaine de sécurité, qui est spécifié par l'entité émettrice de la carte lorsque l'application est téléchargée. Les différents domaines de sécurité sont implémentés sur la carte par l'intermédiaire d'applications spécifiques, une pour chaque domaine de sécurité, permettant de mettre en œuvre et de faire respecter le mode de fonctionnement défini contractuellement entre l'entité émettrice de la carte et chaque fournisseur d'applications. Ces applications spécifiques de domaine de sécurité ont notamment pour rôle d'authentifier et de vérifier les applications du fournisseur d'applications associé pendant le processus de téléchargement. Elles offrent également des services communs pour toutes les applications d'un fournisseur d'applications donné, sans quoi l'exécution de l'application sur la carte n'est pas possible. Le domaine de sécurité d'un fournisseur d'applications est donc l'application, créée sur la carte lors de son initialisation, qui est garante du bon fonctionnement des applications de ce fournisseur installées sur la carte postérieurement à sa délivrance. Ainsi, lors de la phase de chargement et d'installation d'une application sur une car.te multi- applicative, il est primordial de s'assurer que l'application en question est bien rattachée au domaine de sécurité de la carte associé au fournisseur de l'application concerné. De cette façon, le fournisseur d'applications, propriétaire de l'application en question, est assuré que les règles de fonctionnement et d'utilisation de son application sur la carte, fixées contractuellement avec l'entité émettrice de la carte, seront respectées. Or, jusqu'alors, c'est l'entité émettrice de la carte qui spécifie le domaine de sécurité associé à l'application lors de son téléchargement. Il n'existe pas de mécanismes spécifiques mis en œuvre sur la carte, permettant de renforcer les obligations contractuelles passées entre le fournisseur de l'application et l'entité émettrice de la carte, de sorte à ce que le fournisseur de l'application puisse être assuré que l'utilisation sur la carte de son application sera bien conforme à ce qui a été prédéfini, en d'autres termes que l'application chargée et installée sur la carte est bien rattachée à son domaine de sécurité. Par ailleurs, la gestion du cycle de vie des applications d'un fournisseur d'application est placée sous l'autorité de l'entité émettrice de la carte, conformément aux conditions de fonctionnement prévues initialement par contrat entre l'entité émettrice et le fournisseur. Ainsi, l'entité émettrice de la carte est habilitée à prendre la main sur l'application d'un fournisseur d'applications déjà installée sur la carte, notamment pour la verrouiller de sorte à en contrôler l'accès ou encore pour la supprimer de la carte, lorsque l'accord entre le fournisseur et l'entité émettrice a expiré par exemple. Là encore, aucun mécanisme spécifique n'est prévu sur la carte pour s'assurer que l'autorisation du fournisseur d'application a bien été donnée par ce dernier pour permettre la suppression ou le verrouillage d'une ou de ses applications sur la carte. Cette autorisation est importante dans la mesure où une application sur carte demeure de la responsabilité du fournisseur de cette application et toute action sur celle-ci devrait normalement être effectuée avec le consentement du fournisseur propriétaire de l'application. Egalement, dans le contexte d'une carte multi- applicative, lorsqu'une application est chargée, elle importe le plus souvent d'autres applications ou API (acronyme anglo-saxon pour « Application Programming Interface ») qui sont déjà installées sur la carte et qui sont nécessaires à sa mise en œuvre sur la carte. En effet, l'application a besoin de faire appel à des bibliothèques de programmes regroupant des collections de fonctions pour fonctionner et, dans le contexte d'une carte multi-applicative, l'application chargée doit indiquer ces bibliothèques de façon à ce que le système d'exploitation de la carte puisse faire l'édition de liens. Or, sur une carte à puce multi-applicative formant une plate-forme ouverte, il n'existe aucun mécanisme permettant de contrôler l'utilisation d'une API ou d'une application développée par un fournisseur par un autre fournisseur d'application. Ainsi, un fournisseur d'application peut utiliser toute API appartenant à un autre fournisseur d'application, au détriment des droits de propriété de ce dernier. Dans ce contexte, la présente invention, qui se fonde sur ces différents constats, a pour but de prévoir des mécanismes spécifiques, permettant de s'assurer de l'autorisation d'un fournisseur d'applications préalablement à toute action effectuée sur une application délivrée par ce fournisseur sur une carte multi-applicative, de sorte que le fournisseur d'applications puisse contrôler l'accès et l'utilisation de ses applications sur la carte et donc assurer notamment le respect de ses droits de propriété. La présente invention vise ainsi à renforcer les conditions de réalisation des liens contractuels qui sous-tendent la coopération entre l'entité émettrice de la carte et le fournisseur d'applications, Avec cet objectif en vue, l'invention a ainsi pour objet un procédé de gestion d'un dispositif électronique multi-applicatif, comprenant un système d'exploitation prévu pour supporter une pluralité d'applications, chaque application appartenant à un fournisseur d'applications disposant d'un domaine de sécurité qui lui est propre installé initialement sur le dispositif, ledit procédé étant caractérisé en ce que, à la réception d'une commande de chargement d'une application sur le dispositif, ledit système d'exploitation vérifie que ladite application est associée à un domaine de sécurité correspondant au domaine de sécurité du fournisseur de ladite application et, en cas de succès de la vérification, autorise son chargement et son installation sur le dispositif en la rattachant automatiquement audit domaine de sécurité. Selon un premier mode de réalisation, l'étape de vérification consiste à rechercher parmi les domaines de sécurité installés sur le dispositif, celui dont l'identifiant de fournisseur d'application correspond à l'identifiant de l'application devant être chargée. Selon un deuxième mode de réalisation, la commande de chargement reçue comprend, en plus de l'application devant être chargée, l'identifiant de fournisseur d'application correspondant au domaine de sécurité devant être associé, la vérification consistant à contrôler que ledit identifiant correspond à l'identifiant de ladite application. Selon une autre caractéristique de l'invention, une étape de contrôle de l'accès à au moins une application installée sur le dispositif effectué par le domaine de sécurité du fournisseur d'applications auquel ladite application est associée, est mise en œuvre par le système d'exploitation du dispositif, pour autoriser une action sur ladite application. De préférence, le contrôle d'accès consiste à requérir la production d'une signature électronique et à vérifier ladite signature. L'action sur l'application peut consister à supprimer ladite application le dispositif. L'action sur l'application peut encore consister à verrouiller l'utilisation de ladite application. L'action sur l'application peut encore consister en l'utilisation au moins partielle de ladite application par une nouvelle application chargée sur le dispositif appartenant à un autre fournisseur d'applications. Selon une variante, les applications consistent en des interfaces de programmation d'application API.
L' invention concerne également une carte à puce multi-applicative, caractérisé en ce qu'elle comprend des moyens pour la mise en œuvre du procédé tel qu'il vient d'être décrit. De préférence, la carte est une carte de type JavaCard. D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante donnée à titre d'exemple illustratif et non limitatif et faite en référence aux figures suivantes, dans lesquelles : -la figure 1 illustre schématiquement le mode de gestion du contenu de la carte selon l'invention, lors de la phase de chargement et d'installation d'une application sur la carte, et -la figure 2 illustre un exemple du mode de gestion du contenu de la carte selon l'invention, dans le cas d'une importation d'application déjà installée sur la carte. La carte à puce multi-applicative est basée dans un mode de réalisation préféré, sur le système d'exploitation JavaCard (marque déposée) . Suivant cette norme, les applications pour les cartes multi- applicatives sont programmées par les fournisseurs d'applications sous forme d'applets. la norme JavaCard introduit un moyen pour les applets d'interagir directement. Ainsi, une applet peut utiliser des modules d'une autre applet à travers une interface de partage. La figure 1 illustre donc dans ce contexte, un mode de gestion d'une carte multi-applicative 10 dotée de son système d'exploitation OS, lors d'une phase de chargement d'une application dans la carte. Plus précisément, selon cet exemple, l'application chargée dans la carte consiste en une interface de programmation d'application APIl fournie par un fournisseur d'applications Pl. Comme il a déjà été expliqué, un domaine de sécurité SD(Pl) pourace fournisseur d'applications a été implémenté sur la carte et regroupe l'ensemble des applications et des interfaces de programmation d'application appartenant à ce fournisseur d'applications en particulier. Les interfaces de programmation forment un ensemble de bibliothèques Java, qui regroupent des procédures et des objets prédéfinis, utilisables de façon modulaire et qui permettent de mettre en œuvre des applications Java. Ainsi, on cherche à s'assurer que l'interface de programmation APIl délivrée par le fournisseur d'application Pl, est rattachée au bon domaine de sécurité, à savoir le domaine de sécurité de Pl, SD(Pl) . Pour ce faire, on va utiliser un identifiant spécifique de l'application devant être chargée sur la carte et un identifiant spécifique de fournisseur d'application, permettant d'identifier le domaine de sécurité associé. En effet, lorsqu'un domaine de sécurité est créé sur la carte, il est associé à un fournisseur d'applications et il contient donc l'identifiant de ce fournisseur d'applications. Dans le contexte des cartes à puce multi- applicative, toutes les applications sont identifiées par un identifiant unique nommé AID (pour « Application Identifier ») , défini par la norme ISO/IEC 7816-5. Cet identifiant AID est codé sur 16 octets, dont les 5 premiers octets représentent au niveau de la norme l'identifiant RID (pour « Registered application provider Identifier ») permettant d'identifier l'organisme émetteur de l'application. Grâce à ces identifiants, à la réception de la commande de chargement de l'interface de programmation APIl sur la carte, le système d'exploitation OS de la carte va automatiquement vérifier, tel qu'illustré par la référence 20 de la figure 1, que le domaine de sécurité SD(Pl) choisi pour cette application possède bien le même RID que l'application en question. Selon un premier mode de réalisation, le système d'exploitation OS recherche dans une liste qu'il a à sa disposition référençant l'ensemble des domaines de sécurité installés sur la carte, un domaine de sécurité dont l'identifiant RID correspond à l'identifiant AID de l'interface de programmation APIl devant être chargée. Le domaine de sécurité SD(Pl) est alors trouvé et le système d'exploitation OS autorise alors le chargement et l'installation de l'interface de programmation APIl sur la carte en la rattachant automatiquement au domaine de sécurité associé SD(Pl). Selon un autre mode de réalisation, l'identifiant RID du fournisseur d'application correspondant au domaine de sécurité qu'on souhaite associer à l'interface de programmation APIl est transmis en même temps que cette dernière. Ainsi, la vérification 20 consiste simplement à vérifier la correspondance de cet identifiant RID avec l'identifiant AID de l'application, pour s'assurer que l'application chargée APIl est bien rattachée au domaine de sécurité SD(Pl) associé au fournisseur de l'application Pl. Dans le cas où la vérification décrite en 20 échoue, le chargement de l'interface de programmation APIl est rejeté par la carte. Ainsi, grâce aux mécanismes qui viennent d'être décrits, il est possible de s'assurer automatiquement, par l'intermédiaire du système d'exploitation de la carte, que l'interface APIl délivrée par le fournisseur d'applications Pl est installée sur la carte sous son bon domaine de sécurité SD(Pl) . Un autre objectif de l'invention consiste également à s'assurer par des moyens spécifiques prévus sur la carte que l'on a bien l'autorisation du fournisseur d'applications concerné lorsque le système d'exploitation OS souhaite accéder à une application de ce fournisseur déjà installée sur la carte, en vue de réaliser une action quelconque sur cette application. Notamment, cette action peut consister en la suppression de l'application ou en un verrouillage de l'utilisation de cette application sur la carte. Un privilège est alors défini pour les domaines de sécurité associés aux fournisseurs d'applications qui souhaitent contrôler l'accès à leurs applications sur la carte et que leur autorisation soit formellement demandée préalablement à toute action de suppression ou de verrouillage de leurs applications installées sur la carte. A cet effet, une information spécifique permet de caractériser un tel domaine de sécurité et peut alors être utilisée par le système d'exploitation de la carte comme critère pour déterminer si une autorisation d'accès existe, lorsqu'il souhaite accéder à une application associée à ce domaine de sécurité pour la supprimer par exemple. Ainsi, le système d'exploitation, lorsqu'il verra ce privilège, va devoir appeler une interface particulière sur ce domaine de sécurité pour que ce dernier donne son autorisation pour accéder à l'application concernée par la suppression. Concrètement, une signature électronique est rajoutée dans la commande émise par le système d'exploitation et cette signature doit être vérifiée préalablement par le domaine de sécurité associé. Ce contrôle d'accès à une application sur la- carte; imposé par le domaine de sécurité du fournisseur d'applications auquel cette application est associée, est également mis en œuvre dans le cas où l'action sur l'application consiste en une utilisation, au moins partielle, de ladite application par une nouvelle application chargée sur la carte appartenant à un autre fournisseur d'applications. En effet, lorsqu'une nouvelle application ou interface de programmation est chargée, pour pouvoir fonctionner, elle peut être amenée à utiliser d'autres interfaces de programmation déjà installées sur la carte et appartenant à un domaine de sécurité d'un autre fournisseur d'applications. Auquel cas, il est important, dans un souci de préserver les droits de propriété de ce fournisseur d'applications, de permettre à ce dernier de contrôler l'utilisation de ses applications ou API sur la carte. La figure 2 illustre un exemple de ce mode de gestion du contenu de la carte, dans le cas où d'une importation d'application déjà installée sur la carte par une application appartenant à un autre fournisseur d'applications. Un domaine de sécurité SD(Pl) associé au fournisseur d'applications Pl est installé sur la carte à puce multi- applicative 10. Les interfaces de programmation d'application APIl, API2 et API3 appartenant à ce fournisseur Pl ont déjà été chargées et installées sur la carte suivant le mode de gestion expliqué plus haut en référence à la figure 1, en étant donc associées au domaine de sécurité SD(Pl) . Une interface de programmation API P2, provenant d'un fournisseur d'applications P2 différent de Pl, est chargée sur la carte. Dans l'exemple de la *figure 2, cette interface API P2 souhaite utiliser l'APIl du fournisseur d'application Pl déjà installée sur la carte. En d'autres termes, elle doit importer des ressources de cette APIl pour pouvoir être chargée sur la carte. Or, l'interface de programmation APIl qui doit être importée par l'interface de programmation API P2 qui est en train d'être chargée, appartient à un domaine de sécurité SD(Pl) qui veut contrôler son accès. En effet, un privilège est défini pour le domaine de sécurité SD(Pl), qui permet au système d'exploitation de la carte de savoir que ce domaine de sécurité requiert la production d'une signature pour autoriser la connexion à son interface de programmation APIl associée. Le système d'exploitation OS de la carte, voyant ce privilège, avant d'autoriser l'édition de liens entre les interfaces de programmation API P2 et APIl, va appeler une interface sur le domaine de sécurité SD(Pl) pour que ce dernier donne son autorisation. Pour ce faire, la signature, qui a normalement été donnée par le fournisseur d'application Pl pour autoriser à se connecter à son interface de programmation APIl, doit être ajoutée lors du chargement de l'interface de programmation API P2 sur la carte. Dans le cas où l'API P2 devrait importer des ressources d'autres applications ou interfaces de programmation appartenant à Pl, il serait nécessaire d'ajouter une signature par applications ou interfaces de programmation importées. Le système d'exploitation fait alors appel à la vérification de la signature et le domaine de sécurité SD (Pl) va vérifier la signature, pour donner son autorisation à l'utilisation des ressources de son interface de programmation APIl. Si la signature est vérifiée avec succès, l'API P2 est installée sur la carte. En cas d'échec, le chargement de l'API P2 n'est pas autorisé, car cela signifie que cette application essaye d'utiliser des ressources auxquelles elle n'est pas habilitée à accéder. Ainsi, lorsqu'une application est en train d'être chargée, le système d'exploitation identifie la liste des applications déjà installées sur la carte que souhaite utiliser l'application en train d'être chargée et détermine les domaines de sécurité associés à ces applications. Si, parmi ces domaines de sécurité se trouvent des domaines de sécurité qui requièrent un contrôle d'accès pour autoriser l'utilisation de leurs applications, alors le système d'exploitation effectue ce contrôle d'accès. Bien que toute la description ci-dessus ait été faite en relation avec une carte à puce multi- applicative, il doit être compris que les caractéristiques de la présente invention peuvent s'appliquer plus généralement à tout dispositif électronique multi-applicatif, comprenant un système d'exploitation prévu pour supporter une pluralité d'applications. En particulier, la présente invention peut s'appliquer à la gestion du contenu d'un micro¬ ordinateur de type PC, l'entité émettrice se rapportant alors au propriétaire du PC.

Claims

REVENDICATIONS
1. Procédé de gestion d'un dispositif électronique multi-applicatif (10) , comprenant un système d'exploitation (OS) prévu pour supporter une pluralité d'applications, chaque application appartenant à un fournisseur d'applications disposant d'un domaine de sécurité qui lui est propre installé initialement sur le dispositif, ledit procédé étant caractérisé en ce que, à la réception sur le dispositif d'une commande de chargement d'une application (APIl) comprenant un identifiant représentatif du fournisseur d'applications, ledit système d'exploitation vérifie (20) que ledit identifiant identifie un domaine de sécurité correspondant au domaine de sécurité (SD(Pl)) du fournisseur de ladite application e±, en cas de succès de la vérification, autorise son chargement et son installation sur le dispositif en la rattachant automatiquement audit domaine de sécurité (SD(Pl)) .
2. Procédé selon la revendication 1, caractérisé en ce que l'étape de vérification consiste à rechercher parmi les domaines de sécurité installés sur le dispositif, celui dont l'identifiant de fournisseur d'application correspond à l'identifiant de l'application devant être chargée.
3. Procédé selon la revendication 1, caractérisé en ce que la commande de chargement reçue comprend, en plus de l'application devant être chargée, l'identifiant de fournisseur d'application correspondant au domaine de sécurité devant être associé, la vérification consistant à contrôler que ledit identifiant correspond à l'identifiant de ladite application.
4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'une étape de contrôle de l'accès à au moins une application installée sur le dispositif effectué par le domaine de sécurité du fournisseur d'applications auquel ladite application est associée, est mise en œuvre par le système d'exploitation du dispositif, pour autoriser une action sur ladite application.
5. Procédé selon la revendication 4, caractérisé en ce que le contrôle d'accès consiste à requérir la production d'une signature électronique et à vérifier ladite signature.
6. Procédé selon la revendication 4 ou 5, caractérisé en ce que l'action sur l'application consiste à supprimer ladite application le dispositif.
7. Procédé selon la revendication 4 ou 5, caractérisé en ce que l'action sur l'application consiste à verrouiller l'utilisation de ladite application.
8. Procédé selon la revendication 4 ou 5, caractérisé en ce que l'action sur l'application consiste en l'utilisation au moins partielle de ladite application par une nouvelle application chargée sur le dispositif appartenant à un autre fournisseur d'applications.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que les applications consistent en des interfaces de programmation d'application API.
10. Carte à puce multi-applicative, caractérisé en ce qu'elle comprend des moyens pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 9.
11. Carte à puce selon la revendication 10, caractérisé en ce que ladite carte est une carte de type JavaCard.
PCT/EP2005/052684 2004-06-23 2005-06-09 Procede de gestion d'une carte a puce multi-applicative WO2006000531A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05752666A EP1769470A1 (fr) 2004-06-23 2005-06-09 Procede de gestion d'une carte a puce multi-applicative
US11/630,399 US20080034423A1 (en) 2004-06-23 2005-06-09 Method Of Managing A Multi-Application Smart Card

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0406838 2004-06-23
FR0406838A FR2872309A1 (fr) 2004-06-23 2004-06-23 Procede de gestion d'une carte a puce multi-applicative

Publications (1)

Publication Number Publication Date
WO2006000531A1 true WO2006000531A1 (fr) 2006-01-05

Family

ID=34946218

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2005/052684 WO2006000531A1 (fr) 2004-06-23 2005-06-09 Procede de gestion d'une carte a puce multi-applicative

Country Status (4)

Country Link
US (1) US20080034423A1 (fr)
EP (1) EP1769470A1 (fr)
FR (1) FR2872309A1 (fr)
WO (1) WO2006000531A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2107490A2 (fr) 2005-09-29 2009-10-07 Research In Motion Limited Système et procédé de fourniture de services de signature numérique de code
US7797545B2 (en) 2005-09-29 2010-09-14 Research In Motion Limited System and method for registering entities for code signing services
US8340289B2 (en) 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1770586B1 (fr) * 2005-09-29 2008-12-17 Research In Motion Limited Gestion de comptes dans un système et procédé de fourniture de services de signature numérique de code
EP1770588B1 (fr) * 2005-09-29 2008-12-17 Research In Motion Limited Système et procédé de fourniture de services de signature numérique de code.
EP1770587A1 (fr) * 2005-09-29 2007-04-04 Research In Motion Limited Génération à distance d'empreinte par fonction de hachage dans un système et procédé de fourniture de services de signature numérique de code
WO2009007653A1 (fr) * 2007-07-03 2009-01-15 France Telecom Procédé de protection des applications installées sur un module sécurisé, terminal, module de sécurité et équipement communicant associés
FR2923041B1 (fr) * 2007-10-25 2011-08-19 Radiotelephone Sfr Procede d'ouverture securisee a des tiers d'une carte a microcircuit.
US8458800B1 (en) 2010-10-01 2013-06-04 Viasat, Inc. Secure smartphone
US8270963B1 (en) 2010-10-01 2012-09-18 Viasat, Inc. Cross domain notification
US9113499B2 (en) 2010-10-01 2015-08-18 Viasat, Inc. Multiple domain smartphone
US8495731B1 (en) * 2010-10-01 2013-07-23 Viasat, Inc. Multiple domain smartphone
US9052891B2 (en) * 2013-05-14 2015-06-09 International Business Machines Corporation Declarative configuration and execution of card content management operations for trusted service manager
CN104102507B (zh) * 2014-06-24 2017-05-10 飞天诚信科技股份有限公司 一种JavaCard应用功能扩展的实现方法
CN107360310B (zh) 2014-12-12 2019-12-13 华为技术有限公司 移动终端及其资源管理方法
CN111221583B (zh) * 2020-01-03 2022-02-25 广东岭南通股份有限公司 多智能卡启动管理装置及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998043212A1 (fr) * 1997-03-24 1998-10-01 Visa International Service Association Procede et dispositif de carte a puce multi-application permettant de telecharger une application sur la carte posterieurement a son emission
WO2000025278A1 (fr) * 1998-10-27 2000-05-04 Visa International Service Association Delegation de gestion pour applications de cartes a puce
EP1318488A2 (fr) * 2001-12-06 2003-06-11 Matsushita Electric Industrial Co., Ltd. Carte à puce capable d'avoir inslallé une pluralité de gérants de carte

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6971015B1 (en) * 2000-03-29 2005-11-29 Microsoft Corporation Methods and arrangements for limiting access to computer controlled functions and devices
JP3808297B2 (ja) * 2000-08-11 2006-08-09 株式会社日立製作所 Ｉｃカードシステム及びｉｃカード

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998043212A1 (fr) * 1997-03-24 1998-10-01 Visa International Service Association Procede et dispositif de carte a puce multi-application permettant de telecharger une application sur la carte posterieurement a son emission
WO2000025278A1 (fr) * 1998-10-27 2000-05-04 Visa International Service Association Delegation de gestion pour applications de cartes a puce
US6481632B2 (en) * 1998-10-27 2002-11-19 Visa International Service Association Delegated management of smart card applications
EP1318488A2 (fr) * 2001-12-06 2003-06-11 Matsushita Electric Industrial Co., Ltd. Carte à puce capable d'avoir inslallé une pluralité de gérants de carte

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2107490A2 (fr) 2005-09-29 2009-10-07 Research In Motion Limited Système et procédé de fourniture de services de signature numérique de code
EP2107490A3 (fr) * 2005-09-29 2009-10-14 Research In Motion Limited Système et procédé de fourniture de services de signature numérique de code
US7797545B2 (en) 2005-09-29 2010-09-14 Research In Motion Limited System and method for registering entities for code signing services
US8340289B2 (en) 2005-09-29 2012-12-25 Research In Motion Limited System and method for providing an indication of randomness quality of random number data generated by a random data service
US8452970B2 (en) 2005-09-29 2013-05-28 Research In Motion Limited System and method for code signing
US9077524B2 (en) 2005-09-29 2015-07-07 Blackberry Limited System and method for providing an indication of randomness quality of random number data generated by a random data service

Also Published As

Publication number Publication date
EP1769470A1 (fr) 2007-04-04
FR2872309A1 (fr) 2005-12-30
US20080034423A1 (en) 2008-02-07

Similar Documents

Publication Publication Date Title
WO2006000531A1 (fr) Procede de gestion d'une carte a puce multi-applicative
EP0446081B1 (fr) Procédé de chargement de programmes d'application dans un lecteur de carte à mémoire à microprocesseur et système destiné à sa mise en oeuvre
US6941270B1 (en) Apparatus, and associated method, for loading a mobile terminal with an application program installed at a peer device
CA2971670A1 (fr) Procede de traitement d'une transaction a partir d'un terminal de communication
EP3435269B1 (fr) Pare-feu logiciel
EP1649363B1 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
FR2817055A1 (fr) Execution d'une application dans un objet electronique portable a faible capacite de memoire
EP3132399A1 (fr) Procédé de traitement de données transactionnelles, dispositif et programme correspondant
EP1388134A1 (fr) Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable
EP2336938B1 (fr) Procédé de contrôle d'accès à une interface sans contact dans un circuit intégré à double interface de communication avec et sans contact
EP4125240A1 (fr) Element securise pre-personalise et personnalisation embarquee
FR2923041A1 (fr) Procede d'ouverture securisee a des tiers d'une carte a microcircuit.
EP3648491B1 (fr) Element securise multi-configurations et procede associe
FR2812419A1 (fr) Procede de securisation de l'acces a une carte utilisateur a microprocesseur
FR3090959A1 (fr) Traitement d’un service de tickets électroniques
FR2812101A1 (fr) Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant
EP4199411A1 (fr) Procédé de détermination d'une autorisation de mise en uvre d'une ressource composite, chaîne de blocs, dispositifs et programme correspondants
EP2115656B1 (fr) Procede de modification de secrets compris dans un module cryptographique, notamment en milieu non protege
EP4123492A1 (fr) Mise en partage d'une fonction d'une application définie en langage orienté objet
Akram et al. Feature Interaction Problems in Smart Cards with Dynamic Application Lifecycle and Their Countermeasures
WO2020148492A1 (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
FR2822257A1 (fr) Verification de la coherence de conditions d'acces de sujets a des objets dans un moyen de traitement de donnees
WO2003003317A1 (fr) Procede de verification des droits d'acces a des fichiers informatiques
WO2001063830A2 (fr) Acces au reseau avec niveaux de securite differents

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11630399

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

WWE Wipo information: entry into national phase

Ref document number: 2005752666

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2005752666

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11630399

Country of ref document: US