WO2002076126A2

WO2002076126A2 - Subscriber identity module for managing a plurality of commands of at least one applet

Info

Publication number: WO2002076126A2
Application number: PCT/IB2002/000760
Authority: WO
Inventors: Pierre Fargues
Original assignee: Schlumberger Systèmes; Schlumberger Malco, Inc
Priority date: 2001-03-16
Filing date: 2002-03-14
Publication date: 2002-09-26
Also published as: AU2002249488A1; WO2002076126A3; FR2822334A1

Abstract

The present invention relates to a subscriber identity module (SIM). This module comprises at least one type of resources (physical or logical). It also comprises control means (37) for controlling access to resources according to a chosen access control policy. According to the present invention, the different users of said resources form a user group (CM), and said control means (37) are subdivided into n channels (CHn, n=1 to 5), each channel being assigned to a respective user group (CM) and comprising at least one access right policy (PC1n, PC2n, PC3n, TK) defining authorized operations on different types of resource for each user group in question.

Description

SUBSCRIBER IDENTITY MODULE FOR INDEPENDENTALY AND SECURELY MANAGING A PLURALITY OF COMMANDS OF AT LEAST ONE APPLET, IN PARTICULAR FOR A MOBILE COMMUNICATIONS

DEVICE

Technical Field

This invention relates to a subscriber identity module for independently and securely managing a plurality of commands of at least one applet, in particular for a mobile communications device.

This invention may generally be applied to mobile communications, in particular within a cellular radio communication network such as GSM (Global System for Mobile communications) or the like. In such a network, in addition to the telephone communications application, various services may be provided to subscribers of the network .

Background of the invention

For the telephone communication application, the GSM 03.48, 11.11, and 11.14 recommendations are known, which define the transmission and application protocols that the subscriber identity unit and the mobile communications device must use in their dialogues during the telephone communications phase.

According to these recommendations, the files and data of the communications application are stored in a rewritable memory such and an EEPROM or the like, and are arranged as a tree with folders and sub-folders. In addition, with each file and/or data is associated an access control policy, which describes the conditions (via an authentication based on encrypted keys) to be met for the file and/or the data to be modified. Services other than communications may be related to banking operations, messaging functions, game software, on-demand information services, or other such applications .

CONFIRMATION COPf Most often, the applications services or programs

(also called "Applets") are now written in high level computer languages such as JAVA due to the great programming richness and security provided by this type of language .

In general, in order to control the execution of an applet's commands, the subscriber identity module uses the same access control policy as the one used for the files of the communications application. As a result, the communications application files, as well as the applet commands as a whole, are accessible through the same mechanism and are controlled according to the same access control policy.

This lack of access control for applet commands, for example, according to the nature and/or the action performed by the command, is not satisfactory in terms of security because the set of resources available in the module (files for the telephone application, applet commands, files in the EEPROM memory, control means, etc.) is accessible once the conditions for the access control policy have been verified. This results in an insufficient security for each resource in the module, in particular, in the applet commands.

Summary of the invention

The present invention specifically overcomes this drawback.

It provides a subscriber identity module, comprising : - at least one type of resource (physical and/or logical) ,

- control means adapted to control user access to resources according to the chosen access control policy, characterized in that - the different users of said resources are gathered into a user group,

- the control means are divided into n channels, one channel being associated with a respective user group and comprising at least one access right policy defining the operations authorized on various types of resource by the user group in question.

Thus, the division into n channels and the allocation of each channel to a type of respective user offers a number of possibilities for accessing resources while preserving a satisfactorily secure service.

Other features and advantages of the present invention will become more apparent from the following detailed description considered together with the drawings, in which :

Fig. 1 schematically shows a communications mobile device with its prior art subscriber identity module; - Fig. 2 schematically shows the main constituent means of a prior art subscriber identity module;

- Fig. 3 schematically shows the main constituent means of a subscriber identity module according to this invention; - Fig. 4 schematically shows an exemplary coding of flags for the first access control policy according to this invention;

Fig. 5 schematically shows another exemplary coding of flags for the first access control policy according to this invention;

- Fig. 6 schematically shows an exemplary coding of flags for the second access control policy according to this invention;

- Fig. 7 schematically shows an exemplary coding of flags for the third access control policy according to this invention;

Fig. 8 schematically shows an exemplary implementation of a module according to this invention;

- Fig. 9 schematically illustrates exemplary access control policies for five secure channels according to this invention; and

- Fig. 10 schematically illustrates the five secure channels of Fig. 9 as applied to the securing of resources and a subscriber identity module according to this invention.

Detailed description of embodiments of this invention Referring to Fig.l, there is shown a communications mobile equipment, ME, used by a subscriber AB . This equipment generally comprises a screen 2, a keyboard 4, an input/output interface 6 (such as an integrated circuit card reader), processor means 8, audio means 11, and radio communications means 10 with at least one telecommunications network, RS .

The mobile equipment ME comprises a subscriber identity module, SIM, such as an integrated circuit card. The SIM module includes an input/output interface 12, a processor unit 14, a RAM 16, a ROM 18, and a rewritable memory 20, such as an EEPROM or FLASH EPROM. A bus 22 couples the various above-mentioned components together in the subscriber identity module.

Generally, the input/output interface 12 in the SIM module cooperates with I/O 6 in equipment ME for bidirectional data exchange.

The interface 6 in equipment ME and interface 12 in module SIM may be of the contact or contactless type or both. As is well known, the processor unit 14 in the SIM module is able to carry out operations on its own for securing data with the memories 16 and 20 using access control means to be described in detail below. These operations can offer security services such as authentication, integrity, confidentiality, non- repudiation, or the like.

The module is made so as to provide an environment adapted for executing and programming applets written in a high level language such as the "Java" language from SUN MICROSYSTEM Co.

Referring to Fig. 2, the environment of a prior art SIM module comprises elements which at least partially reside in the ROM memory 18 or in the EEPROM rewritable memory 20.

The environment of the SIM module comprises a so- called "hardware" interface, including hardware components described in reference to Fig. 1.

The environment of the SIM module comprises a processor layer 26. This layer 26 is an Operating System, herein referred to as OS.

The module comprises a layer 28, called the "Java Virtual Machine" or JVM. This JVM layer executes the codes (bytecodes) of applets 30.

The EEPROM rewritable memory 20 includes a layer 34 adapted to contain at least one portion of a Programming

Application Interface layer, API, for programming applets. Another portion of the API layer may also reside in a ROM memory.

Applets 30 are also stored in the EEPROM memory 20. Here, they are individually designated API, AP2 and AP3. Furthermore, an interface 32 manages the communications between the module and the outside, in particular between applets and the outside, according to an application's protocol 36, APDU, or "Application Protocol Data Unit". This protocol 36 is for exchanging data from outside to the SIM module and vice-versa. In this applications protocol, there are two kinds of APDU commands, those which are sent from the outside to the module and the APDU replies which are sent from the module to the outside, in reply to commands. The APDU protocol is defined in the ISO 7816-3 specification.

In the present example, the telephone application (here a GSM application) is stored in ROM 18. On the other hand, data files 35 which, in particular, are used for executing the telephone application, are stored in EEPROM 20. Similarly, in the present example, memory 20 stores files 35 related to the user and/or to the communications network company RS . For example, these files 35 may contain any individual information about the subscriber AB, such as, in particular, his/her international subscriber number (IMSI identifier) , which is related to an individual authentication key Ki and to the authentication algorithm A3 required for executing the GSM application.

As is well known, in particular from the GSM 03.19, 11.11, and 11.14 standards, each data file 35 and each applet 30 include the same standard access control policy, which is controlled by control means 37 residing in part in memory 18 and in part in memory 20.

No flag or value of the standard access control policy depends on the module resource nature (applet 30, data file 35, control means 37, or the like) or on the action of the applet command. As a result, the set of module resources is accessible in the standard way and according to the same access control policy.

In order to overcome this drawback, to each resource 30, 35 of the module as well as to the control means 37, is associated a first control policy PCln specific to said resource and only applicable to at least one group of at least one command pertaining to said resource.

Referring to Fig. 3, four types of resource RE have been shown at RE1 for data files 35, RE2 for applet API, RE3 for applet AP2, and RE4 for control means 37.

According to the present invention, the control means 37 are adapted to control the execution of commands for resources RE according to a first access control policy PCln specific to each resource REn. In the present example, the access control means 37 are sub-divided into several access control channels CHn, namely CHI for resource RE1, CH2 for resource RE2, CH3 for resource RE3, and CH4 for resource RE4, respectively. In this example, it was chosen to associate a channel CHn to a resource REn. However, it will be shown below referring to Figs. 8 and 10, that this invention is not restricted to this example. In particular, as will be shown, a channel may be associated to several types of resource.

Referring to Fig. 4, there is shown an embodiment of a first access control policy PC12 dedicated to a resource RE2 formed by applet API.

In this example, there is a MANAGER CARD identity,

CM, and a DOMAIN SECURITY identity, SD. Generally, the identity CM is the telecommunications company in charge of the network. Identity SD is one offering a service, for example, such as a bank or a messaging system.

Referring to Fig. 4, commands are shown whose access is controlled according to the access control policy PC12. In this example, flags ID are assigned to groups of commands . These flags ID are coded on one byte, for example (if needed, the flags ID may be coded on more bits) .

In the example of Fig. 4, each bit is assigned to a group of commands individually shown as ID1 to ID6. In other words, the different ways of accessing to resources are defined through a respective flag IDn

(IDO-ID6) .

Flag ID1 is called "PERSO". It corresponds to the personalization of resources (file 35, applet 30, control means 37) in the SIM module. Flag ID2 is called the "CARD ADMIN" flag. It corresponds to the administration of module files 35.

Flag ID3 is called the "SYSTEM" flag. It corresponds to the diagnosis of the SIM module resources . Flag ID4 is called the "KEY ADMIN" flag. This flag corresponds to the administration of keys for the module's access control means 37.

Flag ID5 is called the "APPLET ADMIN" flag. It is related to the applet administration. Flag ID6 is called the " APPLET CONFIG" flag. This flag corresponds to the applet configuration.

A flag ID0, called the "DEFAULT" flag, is also provided. When the ID0 flag is enabled, the corresponding commands are authorized without requiring a particular access right.

Fig. 5 shows an example for coding the flags of the first access control policy PC12. According to this access control policy PCln, the right to execute a command or a group of commands depends on the way resources are accessed. Accessing a command or a group of commands of the access right policy PCln will depend, according to the present example, on the value of this IDn flag. In the present example, bit bl corresponds to flag ID3 of the access control policy PC12. When this bit bl is OFF, commands in the SYSTEM group are not accessible, whereas when bit bl is ON (1), commands in the SYSTEM group are accessible. The same applies for other bits 2 to 8 according to a coding defined as shown in Fig. 5. Here, the last two bits (b7 and b8) are not assigned to a particular group of commands . These may serve to define new command groups when needed. The Applicant has proposed to solve the problem of further increasing security in accessing data files (and, when needed, other resources) .

For that purpose, there is provided a second access control policy PC2n specifically assigned for accessing data files 35.

The control means 37 are also adapted to control access to said files (or another resource) according to said second specific access control policy PC2n. This access policy (PC2n) makes it possible to assign an authentication authority number (ADM0-ADM4) combined with a resource type controlled by its own access policy.

In this embodiment, the second access control policy PC2n is governed according to an authentication policy using cryptographic keys, the flags of said second policy PC2 being coded with a chosen bit number, for example over one byte, each bit being associated with an authentication authority. For example (Fig. 6) , bit b4 of policy PC2n is assigned to authentication authority ADM1.

Referring to Fig. 7, the module further comprises a third access control policy PC3n pertaining to the security degree assigned to the first access control policy PCln.

In this embodiment, the flags for the third control policy PC3n are coded over at least one byte, and a security degree is assigned to each bit. For example, security degrees are chosen from a group formed by ciphering (ciphering/no ciphering) , redundancy (redundancy check, RC) , signature (digital signature, DS) , verification (cryptographic checksum, CC) , incrementing (counter) , remote access, key verification (verify key) and external authentication (external auth) .

For example, bit b7 of policy PC3n relates to key verification "VERIFY KEY". If bit b7 is OFF (0), then key verification through comparison is not accessible. On the other hand, if bit b7 is ON (1) , then key verification (through comparison) is required. In this context, the key KLA allowing local access is used.

Quite advantageously, this third access control policy, which is related to the security level of the first access control policy, further improves secure and independent management of module resources .

Referring to Fig. 8, there is shown an embodiment of the module according to the present invention.

In this embodiment, n secure channels CHI to CHn are shown, each of which allows a secure and independent access to at least one resource RE of the module according to the above-described access control policies PCln to PC3n. The input to each secure channel is connected to the input interface ITE of the module. The first access control policy PCln is usually known as the "COMMAND DOMAIN". For example, making channel CHI secure is performed according to the first specific access control policy PC11, referred to as "COMMAND DOMAIN 1" .

The second access control policy PC2n is referred to as the "ACCESS DOMAIN". For example, making channel CHI secure is further controlled according to the second specific access control policy PC21, referred to as the

"ACCESS DOMAIN 1" .

As shown in Fig. 9, different access securing profiles according to the present invention are managed by Card Manager user groups CMn (n=l to 5) . Other types of user, such as the "DOMAIN SECURITY" identity, SD, previously defined, could have been sub-divided into several user groups and chosen to illustrate Fig. 9.

In this example, five secure channels CHI to CH5 (n=5) are shown.

Command groups managed independently according to the first access control policy PCln are shown again. These groups correspond to the SYSTEM, CARD ADMIN, PERSO, APPLET CONFIG, APPLET ADMIN, KEY ADMIN groups referred to in Figs. 4 and 5.

Also found again is the second access control policy PC2n, also referred to as the "ACCESS DOMAIN".

Also found again is the third security policy PC3n, referred to as the "SECURITY LEVEL". Finally, a key table TK is also provided, so as to assign keys according to the nature of resource access, namely local or remote.

Referring to Fig. 9, a correspondence is established between secure channel CHI, access control policy COMMAND DOMAIN, shown as PC11, access control policy "ACCESS DOMAIN", shown as PC21, and access control policy "SECURITY LEVEL", shown as PC31.

Channel CHI is schematically illustrated in Fig. 10. It then relates to making the resource formed by files 35 and the resource formed by applet 30-1 secure. According to policy PC11 shown in Fig. 9, the commands belonging to groups CARD ADMIN, APPLET CONFIG and APPLET ADMIN are authorized. In other words, channel CHI allows, according to policy PC11, administering files 35 to be administered, and applet 30-1 to be administered and configured. All other commands are forbidden, except for commands having their flag IDO in the ON state (non shown) .

According to policy PC21, the identity allowed to administer files 35 is identity ADM1.

According to policy PC31, local access to corresponding resources 35 and 30-1 is authorized on channel CHI with its associated security level (verify key) . Similarly, remote access to corresponding resources is authorized with its associated security (CC certificate and ciphering) .

With secure channel CH2, commands from the CARD ADMIN group are accessible. In other words, through channel CH2, applets 30-1 may be configured independently. There is no possible access with the KLA cryptographic key.

In the secure channel CH3 , only commands from the KEY ADMIN group are accessible. Channel CH3 thus makes it possible to manage the keys of control means 37 securely and independently. Local or remote accesses to the control means are enabled with all the security levels of policy PC33, except for redundancy RC and external authentication (external auth) .

With channel CH4, accessing files 35 (locally or remotely) is authorized with the authentication identity or authority ADM0. Accessing files 35 is possible with all the security levels of security policy PC3 except for ciphering, redundancy, and external authentication (external auth) .

In the secure channel CH4, no access to the CARD MANAGER commands is possible. It is also not possible to access files 35. Remotely accessing an applet 30-2 is possible with the security level CC.

Obviously, other secure channels with other access control policies may be set up so as to manage independently and securely module resources according to the present invention.

It is further understood that thanks to the present invention, it is possible to control the execution of a command or group of commands of a resource such as an applet according to a first access control policy specific to the module resource, so as to provide for an independent and secure execution of a plurality of commands for at least one resource such as an applet .

Claims

1. A subscriber identity module (SIM) comprising at least one type of resource (physical and/or logical) , control means (37) adapted to control user access to resources according to a chosen access control policy, characterized in that :

- the different users of said resources are gathered as a user group (CMn) ,

- the control means (37) are sub-divided into n channels (CHn, n=l to 5) , a channel being assigned to a respective user group (CMn) and comprising at least one access right policy (PCln, PC2n, PC3n, TK) defining privileges for each user group over different types of resource.

2. The module according to claim 1, characterized in that an access right policy (PCln) controls the right to execute a command or a group of commands on a type of resource .

3. The module according to claim 1, characterized in that an access policy (PC2n) serves to assign an authentication authority number associated with a resource type controlled by its own access policy.

4. The module according to claim 1, characterized in that an access policy (PC3n) depends on the security level of the channels assigned to the first access control policy PCln.

5. The module according to claim 2, characterized in that, according to the access right policy (PCln) , the right to execute a command or a group of commands depends on the kind of access to resources

(personalization (PERSO) , administration (CARD ADMIN) of module files, diagnosis (SYSTM) of module resources, administration of access control policies (KEY ADMIN) of the module, applet administration of an applet (APPLET ADMIN) , applet configuration (APPLET ADMIN) ) .

6. The module according to claim 2 or 5, characterized in that said different types of access to resources are defined by means of a respective flag IDn (ID0-ID6) and the access to the corresponding command or group of commands of the access right policy PCln depends on the value of said flag IDn.

7. The module according to claim 1, characterized in that said module further comprises one table of keys TK per channel CHn for granting or not granting the user group access to resources according to the access right policy PC3n.