FR2822334A1 - Module d'idente d'abonne a gestion independante et securisee d'une pluralite de commandes d'au moins une appliquette, notamment pour un equipement mobile de communication - Google Patents
Module d'idente d'abonne a gestion independante et securisee d'une pluralite de commandes d'au moins une appliquette, notamment pour un equipement mobile de communication Download PDFInfo
- Publication number
- FR2822334A1 FR2822334A1 FR0103604A FR0103604A FR2822334A1 FR 2822334 A1 FR2822334 A1 FR 2822334A1 FR 0103604 A FR0103604 A FR 0103604A FR 0103604 A FR0103604 A FR 0103604A FR 2822334 A1 FR2822334 A1 FR 2822334A1
- Authority
- FR
- France
- Prior art keywords
- module
- access control
- access
- control policy
- applet
- 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.)
- Pending
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- 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
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/06—Authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/08—Access security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
Abstract
Le module d'identité d'abonné (SIM) comprend une première mémoire (ROM) contenant une application de communication permettant à l'équipement mobile (ME) d'accéder à un réseau de communication, et un interpréteur (JVM) d'appliquettes écrites en langage haut-niveau, et une seconde mémoire (EEPROM) contenant une pluralité de ressources qui supportent chacune au moins une appliquette ou des fichiers (35). A chaque ressource (REn) du module ainsi qu'aux moyens de contrôle (37) est associée une première police de contrôle d'accès spécifique à la ressource (PCln) et qui s'applique à un groupe de commandes appartenant à ladite ressource. Les moyens de contrôle (37) sont aptes à contrôler l'exécution des commandes dudit groupe en fonction de la première police de contrôle d'accès spécifique (PCln).
Description
<Desc/Clms Page number 1>
Module d'identité d'abonné à gestion indépendante et sécurisée d'une pluralité de commandes d'au moins une appliquette, notamment pour un équipement mobile de communication.
La présente invention concerne un module d'identité d'abonné à gestion indépendante et sécurisée d'une pluralité de commandes d'au moins une appliquette, notamment pour un équipement mobile de communication.
Elle trouve une application générale en télécommunication mobile, notamment au sein du réseau de communication radiocellulaire de type GSM (pour Global System for Mobile communications) ou analogue. Dans ce genre de réseau, outre l'application de communication téléphonique, différents services peuvent être fournis à des abonnés du réseau.
Pour l'application de communication téléphonique, on connaît les recommandations GSM 03.48, 11.11, et 11.14 qui définissent les protocoles de transmission et d'application que le module d'identité d'abonné et l'équipement mobile de communication doivent utiliser lors de leurs dialogues en phase de communication téléphonique.
Selon ces recommandations, les fichiers et les données de l'application de communication sont stockés dans une mémoire réinscriptible de type EEPROM ou analogue et sont agencés selon une arborescence à répertoires et sous-répertoires. De plus, à chaque fichier et/ou donnée est attachée une police de contrôle d'accès qui décrit les conditions (via une authentification à base de clés cryptographiques) à réaliser pour intervenir dans le fichier et/ou la donnée.
Les services autres que celui de communication peuvent être en relation avec des opérations bancaires, des fonctions de messageries, des programmes de jeu, des services d'informations à la demande ou d'autres applications analogues.
<Desc/Clms Page number 2>
Le plus souvent, ces services ou programmes applicatifs (ou appliquettes pour"Applets"en langue anglo-saxonne) sont désormais rédigés en langage informatique de haut niveau du type JAVA en raison de la grande richesse de programmation et de sécurité que confère ce genre de langage.
Généralement, pour contrôler l'exécution des commandes d'une appliquette, le module d'identité d'abonné utilise la même police de contrôle d'accès que celle utilisée pour les fichiers de l'application de communication.
Il en résulte que les fichiers de l'application de communication ainsi que l'ensemble des commandes des appliquettes sont accessibles de la même façon et sont contrôlés selon la même police de contrôle d'accès.
Cette absence de contrôle d'accès au niveau des commandes de l'appliquette en fonction par exemple de la nature et/ou de l'action de la commande n'est pas satisfaisante en terme de sécurité car l'ensemble des ressources du module (fichiers de l'application téléphonique, commandes des appliquettes, fichiers de la mémoire EEPROM, moyens de contrôle, etc) est accessible dès que l'on vérifie les conditions de la police de contrôle d'accès. Il en résulte une sécurité insuffisante au niveau de chaque ressource du module, notamment au niveau des commandes des appliquettes.
La présente invention remédie justement à cet inconvénient.
Elle porte sur un module d'identité d'abonné destiné à coopérer avec un équipement mobile de communication, le module d'identité d'abonné étant du type comprenant : - une première mémoire propre à contenir une application de communication permettant à l'équipement mobile d'accéder à un réseau de communication, et un interpréteur d'appliquettes écrites en langage haut-niveau,
<Desc/Clms Page number 3>
- une seconde mémoire propre à contenir une pluralité de ressources qui supportent chacune au moins une appliquette ou des fichiers de données relatifs au moins à l'application de communication, - des moyens de traitement propres à exécuter l'application de communication et à utiliser l'interpréteur pour interpréter au moins une appliquette afin d'exécuter les commandes appartenant à ladite appliquette, et - des moyens de contrôle propres à contrôler l'accès à l'application de communication ainsi qu'aux commandes de l'appliquette en fonction d'une police de contrôle d'accès choisie.
Selon une définition générale de l'invention, à chaque ressource du module ainsi qu'aux moyens de contrôle est associée au moins une première police de contrôle d'accès spécifique à la ressource et qui s'applique à au moins un groupe d'au moins une commande appartenant à ladite ressource et les moyens de contrôle sont aptes à contrôler l'accès' audit groupe de commandes en fonction de ladite première police de contrôle d'accès spécifique.
Ainsi grâce à l'invention, il est possible de contrôler l'exécution d'une commande ou d'un groupe de commandes d'une ressource telle qu'une appliquette en fonction d'une première police de contrôle d'accès spécifique à la ressource du module, ce qui permet de gérer de façon indépendante et sécurisée l'exécution d'une pluralité de commandes d'au moins une ressource telle qu'une appliquette.
En pratique, les indicateurs de la première police de contrôle d'accès sont codés sur un nombre choisi de bits, par exemple sur un octet, à chaque bit étant attribué un groupe de commandes.
De préférence, les groupes de commandes appartiennent à un ensemble formé par la personnalisation des ressources du
<Desc/Clms Page number 4>
module, l'administration des fichiers du module, le diagnostic sur les ressources du module, l'administration des polices de contrôle d'accès du module, l'administration de l'appliquette, la configuration de l'appliquette.
Selon un mode de réalisation de l'invention, l'accès aux ressources est de type local, distant, ou autre.
Selon un autre aspect de l'invention, une seconde police de contrôle d'accès est attribuée spécifiquement à l'accès aux fichiers de données, et les moyens de contrôle sont aptes en outre à contrôler l'accès auxdits fichiers de données en fonction de ladite seconde police de contrôle d'accès spécifique.
Ainsi, grâce à l'invention, l'accès aux fichiers de données du module est également sécurisé de façon indépendante, ce qui offre de nombreuses possibilités d'accès aux fichiers tout en conservant un service de sécurité satisfaisant.
En pratique, la seconde police de contrôle d'accès est régie selon une authentification à clés cryptographiques, les indicateurs de ladite seconde police étant codés sur un nombre choisi de bits, par exemple un octet, et à chaque bit étant attribué une autorité d'authentification.
Très avantageusement, le module comprend en outre une troisième police de contrôle d'accès relative au degré de sécurité de la première police de contrôle d'accès, ce qui améliore encore la gestion sécurisée et indépendante des ressources du module.
En pratique, les indicateurs de la troisième police de contrôle d'accès sont codés sur un nombre choisi de bits, par exemple un octet, et à chaque bit étant attribué un degré de sécurité.
Par exemple, les degrés de sécurité appartiennent au groupe formé par le chiffrement, la redondance, la signature, la
<Desc/Clms Page number 5>
vérification, l'incrémentation, l'accès à distance, la vérification des clés, et l'authentification externe. D'autres caractéristiques et avantages de l'invention apparaîtront à la lumière de la description détaillée ciaprès et des dessins dans lesquels : - la figure 1 représente schématiquement un équipement mobile de télécommunication avec son module d'identité d'abonné selon l'art antérieur ; - la figure 2 représente schématiquement les moyens essentiels et constitutifs d'un module d'identité d'abonné de l'art antérieur ; - la figure 3 représente schématiquement les moyens essentiels et constitutifs d'un module d'identité d'abonné selon l'invention ; - la figure 4 représente schématiquement un exemple de codage des indicateurs de la première police de contrôle d'accès selon l'invention ; - la figure 5 représente schématiquement un autre exemple de codage des indicateurs de la première police de contrôle d'accès selon l'invention ; - la figure 6 représente schématiquement un exemple de codage des indicateurs de la seconde police de contrôle d'accès selon l'invention ; - la figure 7 représente schématiquement un exemple de codage des indicateurs de la troisième police de contrôle d'accès selon l'invention ; - la figure 8 représente schématiquement un exemple de mise en place du module selon l'invention ;
<Desc/Clms Page number 6>
- la figure 9 illustre schématiquement des exemples de polices de contrôle d'accès pour cinq canaux sécurisés selon l'invention ; et - la figure 10 illustre schématiquement les cinq canaux sécurisés de la figure 9 appliqués à la sécurisation des ressources d'un module d'identité d'abonné selon l'invention.
En référence à la figure 1, on a représenté un équipement mobile de télécommunication ME pour un abonné AB. L'équipement comprend de façon générale un écran 2, un clavier 4, une interface entrée/sortie 6 (par exemple de type lecteur de carte à circuit intégré), des moyens de traitement 8, des moyens audio 11 et des moyens de radiocommunication 10 avec au moins un réseau de télécommunication RS.
L'équipement mobile ME comprend un module d'identité d'abonné SIM du type carte à circuit intégré. Le module SIM comporte une interface entrée/sortie 12, une unité de traitement 14, une mémoire vive 16, une mémoire morte 18, et une mémoire réinscriptible 20, de type EEPROM ou FLASH EPROM. Un bus 22 relie entre eux les différents éléments du module d'identité d'abonné mentionnés ci-avant.
De façon générale, l'interface entrée/sortie 12 du module SIM coopère avec l'entrée/sortie 6 de l'équipement ME pour l'échange bi-directionnel de données.
L'interface 6 de l'équipement ME et l'interface 12 du module SIM peuvent être du type à contacts, sans contact ou mixte.
De façon connue, l'unité de traitement 14 du module SIM est capable d'effectuer de façon autonome des opérations de sécurisation de données avec les mémoires 16 et 20 à l'aide de moyens de contrôle d'accès que l'on décrira plus en détail ci-après. Ces opérations peuvent offrir des services de sécurité de type authentification, intégrité, confidentialité, non répudiation ou analogue.
<Desc/Clms Page number 7>
Le module est construit pour fournir un environnement propre à exécuter et programmer des appliquettes écrites en langage évolué, tel que le langage"java"de la société SUN MICROSYSTEMS.
En référence à la figure 2, l'environnement d'un module SIM de l'art antérieur comprend des éléments qui sont au moins partiellement logés dans la mémoire de type ROM 18 ou dans la mémoire réinscriptible de type EEPROM 20.
L'environnement du module SIM comprend une interface 24 dite "hardware", contenant les éléments matériels décrits en référence à la figure 1.
L'environnement du module SIM comprend une couche 26, de type processeur. Cette couche 26 est appelée OS pour"Operating System", c'est-à-dire système d'exploitation.
Le module comprend une couche 28 appelée machine virtuelle java ou JVM pour"Java Virtual Machine". Cette couche JVM exécute les codes (bytecodes) des appliquettes 30.
La mémoire réinscriptible de type EEPROM 20 contient une couche 34 apte à loger au moins une partie d'une couche API pour"Application Programming Interface"qui correspond à une interface de programmation des appliquettes. Une autre partie de la couche API peut être également logée en mémoire ROM.
Les appliquettes 30 sont également logées dans la mémoire de type EEPROM 20. Elles sont individualisées ici en API, AP2 et AP3.
Une interface 32 pilote en outre la communication entre le module et l'extérieur, et particulièrement entre les appliquettes et l'extérieur selon un protocole applicatif 36 dit APDU pour"Application Protocole Data Unit". Ce protocole 36 permet d'échanger des données entre l'extérieur et le module SIM et réciproquement.
<Desc/Clms Page number 8>
Dans ce protocole applicatif, on distingue les commandes APDU qui sont envoyées de l'extérieur vers le module et les réponses APDU qui sont envoyées du module vers l'extérieur, en réponse aux commandes. Le protocole APDU est défini dans le document ISO 7816-3.
En pratique, l'application téléphonique (ici l'application GSM) est stockée dans la mémoire de type ROM 18. En revanche, les fichiers de données 35 qui permettent notamment d'exécuter l'application téléphonique sont stockés dans la mémoire de type EEPROM 20. De même, la mémoire 20 stocke les fichiers 35 relatifs à l'utilisateur et/ou à l'opérateur du réseau de communication RS. Par exemple, ces fichiers 35 peuvent contenir toutes les informations individuelles de l'abonné AB tels que notamment son numéro international d'abonné (identifiant IMSI) qui est lié à une clé d'authentification individuelle Ki et à l'algorithme d'authentification A3 nécessaire à l'exécution de l'application GSM.
De façon connue, notamment d'après les normes GSM 03.19, 11.11, et 11.14, chaque fichier de données 35 et chaque appliquette 30 comprend une même police de contrôle d'accès standard contrôlée par des moyens de contrôle 37 disposés en partie dans la mémoire 18 et en partie dans la mémoire 20.
Aucun indicateur ou valeur de la police de contrôle d'accès standard n'est fonction de la nature de la ressource du module (appliquette 30, fichier de données 35, moyen de contrôle 37, ou autre) ou de l'action de la commande de l'appliquette. Il en résulte que l'ensemble des ressources du module est accessible de façon standard et selon la même police de contrôle d'accès.
Afin de remédier à cet inconvénient, on associe à chaque ressource 30,35 du module ainsi qu'aux moyens de contrôle 37 une première police de contrôle PC1 spécifique à ladite ressource et qui s'applique à au moins un groupe d'au moins une commande appartenant à ladite ressource.
<Desc/Clms Page number 9>
En référence à la figure 3, on a identifié quatre ressources RE, individualisées en RE1 pour les fichiers de données 35, en RE2 pour l'appliquette API, en RE3 pour l'appliquette AP2 et en RE4 pour les moyens de contrôle 37.
Selon l'invention, les moyens de contrôle 37 sont aptes à contrôler l'exécution des commandes des ressources RE en fonction d'une première police de contrôle d'accès PCln spécifique à chaque ressource REn.
En pratique, les moyens de contrôle d'accès 37 sont décomposés en plusieurs canaux de contrôle d'accès CHn, respectivement CH1 pour la ressource RE1, CH2 pour la ressource RE2, CH3 pour la ressource RE3, et CH4 pour la ressource RE4.
En référence à la figure 4, on a représenté un exemple de représentation de la première police de contrôle d'accès PC12 dédiée à la ressource RE2 formée par l'appliquette API.
Dans cet exemple, on distingue l'identité CARTE MANAGER CM, et l'identité SECURITE DOMAINE SD. L'identité CM est généralement l'opérateur de télécommunication qui gère le'réseau.
L'identité SD est celle qui offre par exemple un service, telle qu'une banque ou une messagerie.
En référence à la figure 4, on a représenté des commandes dont l'accès est contrôlé par la police de contrôle d'accès PC12. En pratique, des indicateurs ID sont affectés aux commandes. Ces indicateurs ID sont par exemple codés sur un octet (le cas échéant, les indicateurs ID peuvent être codés sur davantage de bits).
Dans l'exemple de la figure 4, à chaque bit est attribué un groupe de commandes individualisé en IDl à ID6.
L'indicateur IDl est appelé"PERSO". Il correspond à la personnalisation des ressources (fichier 35, appliquette 30, moyen de contrôle 37) du module SIM.
<Desc/Clms Page number 10>
L'indicateur ID2 est appelé"CARD ADMIN". Il correspond à l'administration des fichiers 35 du module.
L'indicateur ID3 est appelé"SYSTEM". Il correspond au diagnostic sur les ressources du module SIM.
L'indicateur ID4 est appelé"KEY ADMIN". Cet indicateur correspond à l'administration des clés des moyens de contrôle d'accès 37 du module.
L'indicateur ID5 est appelé"APPLET ADMIN". Il correspond à l'administration de l'appliquette.
L'indicateur ID6 est appelé"APPLET CONFIG". Cet indicateur correspond à la configuration de l'appliquette.
Un indicateur IDO, appelé"DEFAULT"est également prévu. La validation de l'indicateur IDO se traduit par l'autorisation des commandes correspondantes, sans présentation d'un droit d'accès particulier.
En référence à la figure 5, on a représenté un autre exemple de codage des indicateurs de la première police de contrôle d'accès PC12.
Dans cet exemple, le bit bl correspond à l'indicateur ID3 de la police de contrôle d'accès PC12. Lorsque ce bit bl est à l'état bas, les commandes appartenant au groupe SYSTEM ne sont pas accessibles tandis qu'avec bl à l'état haut (1), les commandes appartenant au groupe SYSTEM sont accessibles. Il en est de même pour les autres bits 2 à 8 selon le codage défini en référence à la figure 5. Les deux derniers bits (b7 et b8) ne sont pas ici attribués à un groupe de commandes particulier. Ils peuvent servir à la définition de nouveaux groupes de commandes le cas échéant.
Le Demandeur s'est posé le problème d'apporter en outre une sécurisation au niveau de l'accès aux fichiers de données (et le cas échéant aux autres ressources).
<Desc/Clms Page number 11>
Pour cela, il est prévu une seconde police de contrôle d'accès PC2n attribuée spécifiquement à l'accès aux fichiers de données 35.
Les moyens de contrôle 37 sont aptes à contrôler en outre l'accès auxdits fichiers (ou à une autre ressource) en fonction de ladite seconde police de contrôle d'accès spécifique PC2n.
En pratique, la seconde police de contrôle d'accès PC2n est régie selon une authentification à clés cryptographiques, les indicateurs de ladite seconde police PC2n étant codés par exemple sur un octet, à chaque bit étant attribuée une autorité d'authentification.
Par exemple (figure 6), le bit b4 de la police PC2n est attribué à l'autorité d'authentification ADM1.
En référence à la figure 7, le module comprend en outre une troisième police de contrôle d'accès PC3n relative au degré de sécurité attribué à la première police de contrôle d'accès PCIn.
En pratique, les indicateurs de la troisième police de contrôle d'accès PC3n sont codés sur au moins un octet, à chaque bit étant attribué un degré de sécurité.
Par exemple, les degrés de. sécurité appartiennent au groupe formé par le chiffrement (ciphering/no ciphering), la redondance (RC redundancy check), la signature (DS digital signature), la vérification (CC cryptographic checksum), l'incrémentation (counter), l'accès à distance (remote access), la vérification des clés (verify key) et l'authentification externe (external auth).
Par exemple, le bit b7 de la police PC3n est relatif à la vérification des clés VERIFY KEY. Si le bit b7 est à l'état bas (0), alors la vérification des clés par comparaison n'est pas accessible. En revanche, si le bit b7 est à l'état haut
<Desc/Clms Page number 12>
(1) alors la vérification des clés (par comparaison) est exigée. Dans ce contexte, la clé KLA pour un accès local est utilisée.
En référence à la figure 8, on a représenté un exemple de mise en oeuvre du module selon l'invention.
Dans cet exemple, on distingue n canaux sécurisés CH1 à CHn qui permettent chacun l'accès sécurisé et indépendant à au moins une ressource RE du module selon les polices de contrôle d'accès PCln à PC3n décrites ci-avant. L'entrée de chaque canal sécurisé est connecté à l'interface d'entrée ITE du module.
La première police de contrôle d'accès PCln est appelée en langage anglo-saxon"COMMAND DOMAIN", pour domaine des commandes. Par exemple, la sécurisation du canal CH1 est pilotée selon la première police de contrôle d'accès spécifique PC11, appelée"COMMAND DOMAIN 1".
La seconde police de contrôle d'accès PC2n est appelée en langage anglo-saxon"ACCESS DOMAIN", pour domaine d'accès.
Par exemple, la sécurisation du canal CH1 est contrôlée en outre selon la seconde police de contrôle d'accès spécifique PC21, appelée"ACCESS DOMAIN 1".
En référence à la figure 9, différents profils de sécurisation d'accès selon l'invention sont gérés par la carte MANAGER CM. Dans cet exemple, on distingue cinq canaux sécurisés CH1 à CH5 (n=5).
On retrouve les groupes de commandes gérés de façon indépendante selon la première police de contrôle d'accès PCln. Ces groupes correspondent aux groupes SYSTEM, CARD ADMIN, PERSO, APPLET CONFIG, APPLET ADMIN, KEY ADMIN, mentionnés en référence aux figures 4 et 5.
On retrouve également la seconde police de contrôle d'accès PC2n, appelée encore"ACCESS DOMAIN".
<Desc/Clms Page number 13>
On retrouve aussi la troisième police de sécurité PC3n, appelée encore"SECURITY LEVEL", pour degré de sécurité.
Enfin, une table de clés TK est également prévue, afin d'attribuer des clés selon la nature de l'accès aux ressources, c'est-à-dire local ou distant.
En référence à la figure 9, on a fait correspondre au canal sécurisé CH1, la police de contrôle d'accès COMMAND DOMAIN individualisée en PC11, la police de contrôle d'accès ACCESS DOMAIN individualisée en PC21, et la police de contrôle d'accès SECURITY LEVEL individualisée en PC31.
Le canal CH1 est illustré schématiquement en figure 10. Il concerne ici la sécurisation de la ressource formée par les fichiers 35 et la sécurisation de la ressource formée par l'appliquette 30-1. Selon la police PC11 représentée en figure 9, les commandes appartenant aux groupes CARD ADMIN, APPLET CONFIG et APPLET ADMIN sont autorisées. En d'autres termes, le canal CH1 permet, selon la police PC11, l'administration des fichiers 35, et l'administration et la configuration de l'appliquette 30-1. Toutes les autres commandes sont interdites, à l'exception des commandes dont l'indicateur IDO est à l'état haut (non représentées).
Selon la police PC21, l'identité capable d'administrer les fichiers 35 est l'identité ADM1.
Selon la police PC31, l'accès local aux ressources correspondantes 35 et 30-1 est autorisé sur le canal CH1 avec la sécurité associée (vérification des clés ou verify key). De même, l'accès à distance aux ressources correspondantes est autorisé avec la sécurité associée (certificat CC et chiffrement).
Selon le canal sécurisé CH2, les commandes appartenant au groupe CARD ADMIN sont accessibles. En d'autres termes, on peut à travers le canal CH2 configurer de façon indépendante les appliquettes 30-1. Il n'y a pas d'accès possible à
<Desc/Clms Page number 14>
distance. Seul l'accès local est possible avec la clé cryptographique de type KLA. Dans le canal sécurisé CH3, seules les commandes appartenant au groupe KEY ADMIN sont accessibles. Le canal CH3 permet ainsi d'administrer de façon sécurisée et indépendante les clés des moyens de contrôle 37. Les accès local et à distance aux moyens de contrôle sont validés avec tous les degrés de sécurité de la police PC33, sauf redondance RC et authentification externe (external auth).
Selon le canal CH4, l'accès aux fichiers 35 (local ou à distance) est autorisé avec l'identité ou l'autorité d'authentification ADMO. L'accès aux fichiers 35 est possible avec tous les degrés de sécurité de la police de sécurité PC3 sauf chiffrement, redondance et authentification externe (external auth).
Dans le canal sécurisé CH5, aucun accès aux commandes de la CARD MANAGER n'est possible. Il n'est pas possible non plus d'accéder aux fichiers 35. Un accès à distance à l'appliquette 30-2 est possible avec le degré de sécurité CC.
Bien évidemment, d'autres canaux sécurisés avec d'autres polices de contrôle d'accès peuvent être mis en place afin de gérer de façon indépendante et sécurisée les ressources du module selon l'invention.
Claims (10)
1. Module d'identité d'abonné (SIM) destiné à coopérer avec un équipement mobile de communication (ME), le module d'identité d'abonné (SIM) étant du type comprenant : - une première mémoire (ROM) propre à contenir une application de communication permettant à l'équipement mobile (ME) d'accéder à un réseau de communication, et un interpréteur (JVM) d'appliquettes écrites en langage haut-niveau, - une seconde mémoire (EEPROM) propre à contenir une pluralité de ressources qui supportent chacune au moins une appliquette ou des fichiers relatifs à l'utilisateur et/ou à l'opérateur du réseau de communication, ainsi qu'à ladite seconde mémoire, - des moyens de traitement propres à exécuter l'application de communication et à utiliser l'interpréteur (JVM) pour interpréter l'appliquette afin d'exécuter les commandes appartenant à ladite appliquette, et - des moyens de contrôle propres à contrôler l'accès aux fichiers de l'application de communication ainsi qu'aux commandes de l'appliquette en fonction d'une police de contrôle d'accès choisie, caractérisé en ce qu'à chaque ressource (REn) du module ainsi qu'aux moyens de contrôle (37) est associée au moins une première police de contrôle d'accès spécifique à la ressource (PCln) et qui s'applique à au moins un groupe d'au moins une commande appartenant à ladite ressource et en ce que les moyens de contrôle (37) sont aptes à contrôler l'exécution des commandes dudit groupe en fonction de ladite première police de contrôle d'accès spécifique (PCln).
2. Module selon la revendication 1, caractérisé en ce que les indicateurs (ID) de la première police de contrôle d'accès (PCln) sont codés sur un nombre de bits choisi.
<Desc/Clms Page number 16>
3. Module selon la revendication 2, caractérisé en ce que les groupes de commandes appartiennent à un ensemble formé par la personnalisation (PERSO) des ressources (35,37, 30) du module (SIM), à l'administration (CARD ADMIN) des fichiers du module, au diagnostic (SYSTEM) sur les ressources du module (SIM), à l'administration des polices de contrôle d'accès (KEY ADMIN) du module, à l'administration de l'appliquette (APPLET ADMIN), à la configuration de l'appliquette (APPLET ADMIN).
4. Module selon l'une des revendications précédentes, caractérisé en ce que l'accès à une ressource est de type local, distant, ou autre.
5. Module selon la revendication 4 caractérisé en ce qu'une seconde police de contrôle d'accès (PC2n) est attribuée spécifiquement à l'accès aux fichiers de données (35), et en ce que les moyens de contrôle (37) sont aptes en outre à contrôler l'accès auxdits fichiers (35) en fonction de ladite seconde police de contrôle d'accès spécifique (PC2n).
6. Module selon la revendication 5, caractérisé en ce que la seconde police de contrôle d'accès (PC2n) est régie selon une authentification à clés, les indicateurs de ladite seconde police étant codés sur un nombre choisi et à chaque bit étant attribué une autorité d'authentification.
7. Module selon l'une des revendications précédentes, caractérisé en ce qu'il comprend en outre une troisième police de contrôle d'accès (PC3n) relative au degré de sécurité de la première police de contrôle d'accès (PCln).
8. Module selon la revendication 7, caractérisé en ce que les indicateurs de la troisième police de contrôle d'accès (PC3n) sont codés sur un nombre choisi, à chaque bit étant attribué un degré de sécurité prédéterminé.
9. Module selon la revendication 8, caractérisé en ce que les degrés de sécurité appartiennent au groupe formé par le
<Desc/Clms Page number 17>
chiffrement, la redondance, la signature, la vérification, l'incrémentation, l'accès à distance, la vérification des clés, l'authentification externe.
10. Module selon l'une des revendications précédentes, caractérisé en ce que les moyens de contrôle (37) sont décomposés en n canaux sécurisés selon au moins la première police de contrôle d'accès (PCln).
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0103604A FR2822334A1 (fr) | 2001-03-16 | 2001-03-16 | Module d'idente d'abonne a gestion independante et securisee d'une pluralite de commandes d'au moins une appliquette, notamment pour un equipement mobile de communication |
| PCT/IB2002/000760 WO2002076126A2 (fr) | 2001-03-16 | 2002-03-14 | 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 |
| AU2002249488A AU2002249488A1 (en) | 2001-03-16 | 2002-03-14 | Subscriber identity module for managing a plurality of commands of at least one applet |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0103604A FR2822334A1 (fr) | 2001-03-16 | 2001-03-16 | Module d'idente d'abonne a gestion independante et securisee d'une pluralite de commandes d'au moins une appliquette, notamment pour un equipement mobile de communication |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| FR2822334A1 true FR2822334A1 (fr) | 2002-09-20 |
Family
ID=8861215
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| FR0103604A Pending FR2822334A1 (fr) | 2001-03-16 | 2001-03-16 | Module d'idente d'abonne a gestion independante et securisee d'une pluralite de commandes d'au moins une appliquette, notamment pour un equipement mobile de communication |
Country Status (3)
| Country | Link |
|---|---|
| AU (1) | AU2002249488A1 (fr) |
| FR (1) | FR2822334A1 (fr) |
| WO (1) | WO2002076126A2 (fr) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1582053A2 (fr) * | 2002-12-31 | 2005-10-05 | Motorola, Inc. | Systeme et procede d'autorisation repartie pour acceder a un dispositif de communication |
| EP1643465A1 (fr) * | 2004-09-29 | 2006-04-05 | Sony Corporation | Appareil de traitement d'information et méthode |
| WO2009027743A2 (fr) | 2007-08-31 | 2009-03-05 | Vodafone Group Plc | Sécurité de dispositif de télécommunication |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2864294B1 (fr) * | 2003-12-17 | 2006-03-24 | Oberthur Card Syst Sa | Carte a microcircuit multi-compte permettant la restriction d'une fonctionnalite a un compte et procede de communication correspondant |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2748834A1 (fr) * | 1996-05-17 | 1997-11-21 | Gemplus Card Int | 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 |
| EP0973350A2 (fr) * | 1998-07-17 | 2000-01-19 | Phone.Com Inc. | Méthode et appareil permettant contrôle d'accès à services locales d'appareils mobiles |
| WO2000069183A2 (fr) * | 1999-05-11 | 2000-11-16 | Nokia Corporation | Supports de stockage d'informations |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5544246A (en) * | 1993-09-17 | 1996-08-06 | At&T Corp. | Smartcard adapted for a plurality of service providers and for remote installation of same |
| EP0932865B1 (fr) * | 1996-10-25 | 2002-08-14 | SCHLUMBERGER Systèmes | Utilisation de langage de programmation evolue avec un controleur microprogramme |
-
2001
- 2001-03-16 FR FR0103604A patent/FR2822334A1/fr active Pending
-
2002
- 2002-03-14 WO PCT/IB2002/000760 patent/WO2002076126A2/fr active Search and Examination
- 2002-03-14 AU AU2002249488A patent/AU2002249488A1/en not_active Abandoned
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2748834A1 (fr) * | 1996-05-17 | 1997-11-21 | Gemplus Card Int | 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 |
| EP0973350A2 (fr) * | 1998-07-17 | 2000-01-19 | Phone.Com Inc. | Méthode et appareil permettant contrôle d'accès à services locales d'appareils mobiles |
| WO2000069183A2 (fr) * | 1999-05-11 | 2000-11-16 | Nokia Corporation | Supports de stockage d'informations |
Non-Patent Citations (1)
| Title |
|---|
| GUTHERY: "JAVA CARD: Internet Computing on a Smart Card", IEEE INTERNET COMPUTING, IEEE SERVICE CENTER, PISCATAWAY, NJ, US, 1 February 1997 (1997-02-01), pages 57 - 59, XP002077647, ISSN: 1089-7801 * |
Cited By (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1582053A2 (fr) * | 2002-12-31 | 2005-10-05 | Motorola, Inc. | Systeme et procede d'autorisation repartie pour acceder a un dispositif de communication |
| EP1582053A4 (fr) * | 2002-12-31 | 2006-04-12 | Motorola Inc | Systeme et procede d'autorisation repartie pour acceder a un dispositif de communication |
| EP1643465A1 (fr) * | 2004-09-29 | 2006-04-05 | Sony Corporation | Appareil de traitement d'information et méthode |
| US7416124B2 (en) | 2004-09-29 | 2008-08-26 | Sony Corporation | Information processing apparatus and method, recording medium, and program |
| US8126947B2 (en) | 2004-09-29 | 2012-02-28 | Sony Corporation | Information processing apparatus and method, recording medium, and program |
| US8407198B2 (en) | 2004-09-29 | 2013-03-26 | Sony Corporation | Information processing apparatus and method, recording medium, and program |
| US8838561B2 (en) | 2004-09-29 | 2014-09-16 | Sony Corporation | Information processing apparatus and method, recording medium, and program |
| US9098711B2 (en) | 2004-09-29 | 2015-08-04 | Sony Corporation | Information processing apparatus and method, recording medium, and program |
| EP3399506A1 (fr) * | 2004-09-29 | 2018-11-07 | Sony Corporation | Appareil et procédé de traitement d'informations |
| US10769284B2 (en) | 2004-09-29 | 2020-09-08 | Sony Corporation | Information processing apparatus and method, recording medium, and program |
| WO2009027743A2 (fr) | 2007-08-31 | 2009-03-05 | Vodafone Group Plc | Sécurité de dispositif de télécommunication |
| WO2009027743A3 (fr) * | 2007-08-31 | 2009-04-16 | Vodafone Plc | Sécurité de dispositif de télécommunication |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2002076126A2 (fr) | 2002-09-26 |
| AU2002249488A1 (en) | 2002-10-03 |
| WO2002076126A3 (fr) | 2002-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP2656578B1 (fr) | Gestion de canaux de communication dans un dispositif de telecommunication couple a un circuit nfc | |
| EP1688818A1 (fr) | Procédé de gestion sécurisée de l'éxécution d'une application | |
| US20110145917A1 (en) | Method and system for facilitating memory and application management on a secured token | |
| EP2492819B1 (fr) | Procédé et appareil de protection d informations résidant sur une carte mémoire | |
| FR2748834A1 (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 | |
| WO2007119032A1 (fr) | Procede de securisation de l'acces a un module de communication de proximite dans un terminal mobile | |
| EP1395962A1 (fr) | Deploiement d'application depuis une carte a puce | |
| EP0841801A1 (fr) | Procédé de restriction de durée des communications téléphoniques et équipement téléphonique utilisant un tel procédé | |
| WO2001084512A1 (fr) | Carte a puce multi-applicatives | |
| CN111245620B (zh) | 一种在终端中的移动安全应用架构及其构建方法 | |
| FR2822334A1 (fr) | Module d'idente d'abonne a gestion independante et securisee d'une pluralite de commandes d'au moins une appliquette, notamment pour un equipement mobile de communication | |
| FR2810481A1 (fr) | Controle d'acces a un moyen de traitement de donnees | |
| WO2004062243A2 (fr) | Systeme et procede d'autorisation repartie pour acceder a un dispositif de communication | |
| EP1636694A1 (fr) | Caracteristique de controle d'acces a distance servant a limiter l'acces a des elements de fichier de configuration | |
| FR2822256A1 (fr) | Verification de la conformite d'acces a des objets dans un systeme de traitement de donnees avec une politique de securite | |
| EP1636767B1 (fr) | Methode d'allocation de ressources securisees dans un modue de securite | |
| FR2923041A1 (fr) | Procede d'ouverture securisee a des tiers d'une carte a microcircuit. | |
| FR3090254A1 (fr) | Accès sécurise à des données chiffrées d’un terminal utilisateur | |
| 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 | |
| EP1526431A1 (fr) | Contrôle d'accès à des périphériques d'un microprocesseur | |
| FR3004884A1 (fr) | Element securise pour terminal de telecommunications | |
| FR2817107A1 (fr) | Signature electronique sur le reseau gsm/gprs et umts | |
| FR2933559A1 (fr) | Procede d'installation d'une application de gestion et procede de gestion de donnees d'application d'un module de securite associe a un terminal mobile | |
| WO2002008897A1 (fr) | Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant |