WO2007107829A2

WO2007107829A2 - A personal security token for at least two security environments and different access conditions thereupon

Info

Publication number: WO2007107829A2
Application number: PCT/IB2007/000626
Authority: WO
Inventors: Baozhu Yang
Original assignee: Axalto S.A.
Priority date: 2006-03-17
Filing date: 2007-03-02
Publication date: 2007-09-27
Also published as: WO2007107829A3; CN101039318A

Abstract

The inventions relates to a personal security token (10) for a mobile telecommunicaction terminal (20) said personal security token (10) comprising a memory and a processor, said memory storing a content file (11), an access condition list (ACL) to such file (11) under a first security environment and an access condition list (ACL) to such file (11) under a second security environment, the two access condition lists being both stored in a given file (12) which is divided into records, characterized in that the access condition list (ACL) under the first security environment and the access condition list (ACL) under the second security environment are stored in the same record (13) of the said given file (12), and the token (10) stores and runs a program for identifying wether the token (10) is currently actuated under the first security environment or under the second security environment and reading only the access condition list which corresponds to the current security environment.

Description

"A PERSONAL SECURITY TOKEN FOR AT LEAST TWO SECURITY ENVIRONMENTS AND DIFFERENT ACCESS CONDITIONS THEREUPON"

The invention relates to personal security tokens for authenticating an end user carrying such tokens when accessing a mobile telecommunication network.

The mostly known device of this type is the SIM card, but it an also be a USB type key token, a mass memory card with security credentials, ans any other kind of token carrying some necessary credentials for allowing access to the network.

Such tokens are typically compliant with international standard ISO7816. Personal security tokens of the kind store a set of files, each of which is divided in a series a records. Each given file is protected against forbidden reading or writing, primarily by a set of access conditions which are specifically associated with the file.

This set of access conditions is stored as an ACL (access condition list) which is specifically associated with such file.

When the file is used under multiple environments such as the 2G (second generation) environment or the 3G (third generation) environment, according to ISO7816, its ACL under each environment is saved to be one respective record in a specific file, which is the EFARR file (Refer to ISO7816-

9). A record is an elementary sub-division of a file. Each record typically has a

TLV format, i.e. Tag-Length-Value format. Therefore the EFARR file comprises a record for the 2G ACL, and record for the 3G ACL.

Typically, the ACL are not coded the same way according to the 2G specifications or according to the 3G specifications. For example, some files can be accessed either by 2G commands of the APDU type, either by 3G commands of the APDU type. APDU, Application Protocol Data Unit, is the communication unit between a reader and a card. The structure of an APDU is recited in ISO 7816 standard. So, these files have two ACLs, each ACL corresponding to one of the two security environments 2G or 3G.

These two ACLs correspond to two different records in the EFarr. So, when EFarr is accessed either in a 2G environment either in a 3G environment, some unnecessary records can be found in it. This may cause a quality issue, as a 3G mobile terminal will find some non-standard records in the Efarr in case the ACL or part of it is transmitted to the mobile terminal.

The purpose of the present invention is to solve the problem described above, i.e. that under specified security environment only the ACL relating to current security environment be available. Preferably, the solution should support all mobile terminals which comply with ISO7816.

This purpose is achieved by means of the invention as recited in the appended claims.

Other purposes, benefits and aspects of the invention will appear through the following description, which is made in reference to the appended unique figure, which illustrates a process according to the invention.

In the 3G standard specification, the access list conditions to access each file are stored into the records of a specific file called EFarr. The access list conditions, which indicate what privileges are given to what identity are coded in TLV format (Tag Length Value - Value is the data, length is the length of the data, tag codes the type of data). The format of the ACL, described in the ISO7816-9 is made of TLV containing other TLV.

The EF arr file is a file made of records. It means, that the data contained in the file is divided in records, these records being numbered from first to last. According to the 3G specification, one record of the EFarr file contains one ACL, which can correspond to many files. When a file is selected for being accessed, some data about its content can be returned by the card, upon the selection of this file. This data contains the number of the record which contains the ACL of this file. The 2G specification defines no means to get the ACL of a file the content thereof is to be accessed. EFarr is not defined in the 2G specification. But the 3G specification allows to have some EFarr records marked with a flag, which means: this record has a proprietary format. These records are allowed, and should be discarded by the mobiles according to the 3G spec.

In the following, the word "channel" will be used, which means that the card has the ability to identify whether the card is associated with a 2G or a

3G mobile terminal, i.e. whether the terminal communicates with the card under 2G or 3G implementation, i.e. channel. "2G channel" means that the

2G application has been selected.

As well known in the art, APDUs are elementary commands of the usual set of standardized commands to IC cards

Practically, the APDU used to access the file is a 2G APDU, which can be seen from the class of the APDU, i.e. AO as indicated in its header. 3G APDUs have class equal to Ox, where x is the logical channel.

"channel" is practically a pure identification of the currently used security environment (2G or 3G) by means of discriminating data transmitted to the card inside the APDUs (i.e. the SE id in the memo).

The operating system of a usual card 10 is programmed to recognize when a request is a 2G request or a 3G request. So a mechanism already has been programmed in a typical OS for recognizing the security environment underlying a request. Indeed, according to the standard specifications, the data coming from the card 10 that receives a 2G "select" APDU or a 3G "select" APDU is different depending on the fact that the APDU is a 2G or a 3G APDU.

To that purpose, the operating system tracks in the header of an APDU 15 sent by the mobile terminal 20 whether it contains "AO" or "Ox" class data.

In other words, the card 10 stores and runs an operating system which is able to easily recognize when a request for access to a file is a 2G or a 3G request.

The "channel" - which induces access to such or such type of ACL - can be any other type of detectable technical difference in a message exchanged with the card 10, i.e. any technical difference which would reflect whether 2G or 3G is currently used.

In an alternate example other than through the class byte (AO or Ox), the current security environment can be identified through a select application command. In this case, if the command class is AO, the operating system identifies that it is under a 2G environment because there is no defined

"select application" 2G command. If the command class is Ox, the operating system can use the 'Select application¹ APDU (defined in 102.221), in order to select the "2G application", in this case, the program can consider that it is under a 2G security environment despite the APDU class is Ox for the read record command.

If the command class is Ox, the operating system considers that it is in a 3G security environment as long as no select application of the 2G application has been done.

The algorithm which determines under which SEI the program currently is can be more complex and can vary according to the choices of implementation.

Any entity such as an end-user or a remote server or the mobile terminal may try to access to a file of the card.

Suppose the mobile terminal intends to access to a file 1 1. A file selection is done as follows. The mobile terminal 20 first sends an apdu command 15 which is "select file". The APDU command includes an APDU header and a file ID. The card replies if operation is OK and eventually provides the number of information bytes to be given to mobile terminal 20.

Then the mobile terminal 20 sends a "get response" APDU command 16. This command also includes an APDU header. The card 10 replies with the data.

In 2G spec, there is a specific format for the replied data. In 3g spec, the format is different and is compliant with 7816-9, and the data is called FCP.

The Operating system of the card therefore has to fetch the data, which will be called thereafter FCP data for simplifying the explanation.

Some ACL information which corresponds to the FCP data, and which indicates where the ACL lies, is stored in the file itself containing the FCP data, which information has the following TLV format:

8B + 04 + EFARFLFILEID + SEID + RecordNO EFARR_FILEID is the name of the used EFARR file 12 which is coded with two bytes, in which the ACL of the file 11 containing the FCP data is stored.

SEID is the current security environment which is coded on one byte.

At the time when the operating system of the card reads such information, the operating system knows whether the security environment is 2G or 3G because this SEID was determined when the card received the first APDU after power on.

Record NO is the number of the record 13 that contains the ACL of the current file 11 , i.e. the file which contains the FGP data.

The record as identified by such record number has the following content, which is under TLV format :

SEID 1 ;Length;ACL under SEID1 ;SEID2;Length;ACL under SEID2... In the EFARR file 12, the SEID (security environment identifier) may not be specified. But two kinds of format can be found: proprietary format with a tag which is 9C, see 7816-9 pagei 1 , section 8.5.2 , or a 7816-9 format with a tag which is 80. In such case, if the class of a "read record" APDU command is AO, then the operating system reads the ACL in the proprietary format (9C). If not, the operating system reads the ACL in the 7816-9 format. This way the operating system goes to the right place in the record. Once having identified the location of the record 13 storing the ACL, the operating system has to check whether the ACL allows the requesting entity to access or not to the file 11. Such requesting entity can be an end- user for access to the phonebook file or a PIN file (personal identifying number), can be a remote server for access to a setting file, or can be the mobile terminal as in the present example for access to a file which for example is necessary for further terminal/card communication.

For this purpose, the operating system compares the read content of the access condition list with attributes of a party requiring access to the said content file, so as to grant or deny access of the party to such content file.

When the OS gets to the record containing the ACL, the data that the OS is programmed to read is only the ACL under the current security environment. In some cases, the OS then transmits to the mobile terminal the content of the ACL, for example when the ACL requires the mobile terminal 20 to ask for further credentials, for example a PIN code or a password from the end-user.

In such cases, the OS transmits a record size (Length) and some record data (Value) of the record which correspond only to the current security environment. So from the side of the mobile terminal 20, there is only one available ACL and there is no way to get other ACLs under any other security environment; ^.

Several ACLs of the file 11 under different security environments are saved in one record 13 in the EFARR 12, but only one ACL is read by the OS under a given security environment.

The same record number is thus used to store several ACL data related to one file. Only when the EFarr file is read through one channel (mainly 2G channel or 3Gchannel), the data read in the file is different (mainly 2G format or 3G format).

This embodiment provides more security on the card, and thus makes the product more competitive.

It is compliant with ISO 7816 and there is no need to modify the mobile terminal. One other advantage of the invention is to avoid that the 3G mobile reads some 2G records that he does not understand. Even if, according to the 3G specification, these 2G records contain a specific tag that will make them be ignored by the 3G mobile, some mobiles can have some bugs when they meet such records, so that they just reject the card when such content is met.

Claims

1. A personal security token (10) for a mobile telecommunication terminal (20) said personal security token (10) comprising a memory and a processor, said memory storing a content file (11), an access condition list (ACL) to such file (11) under a first security environment and an access condition list (ACL) to such file (11) under a second security environment, the two access condition lists being both stored in a given file (12) which is divided into records, characterized in that the access condition list (ACL) under the first security environment and the access condition list (ACL) under the second security environment are stored in the same record (13) of the said given file (12), and the token (10) stores and runs a program for identifying whether the token (10) is currently actuated under the first security environment or under the second security environment and reading only the access condition list which corresponds to the current security environment.

2. The personal security token according to claim 1 , characterized in that the program which identifies whether the token (10) is currently actuated under the first security environment or under the second security environment and reads only the access condition list which corresponds to the current security environment is an operating system of the personal security token (10), and the operating system compares the read content of the access condition list with attributes of a party (20) requiring access to the said content file, so as to grant or deny access of the party (20) to such content file.

3. The personal token according to claim 1 or claim 2, characterized in that the operating system transmits data of the access condition list to the mobile telecommunication terminal (20) according to the current security environment only.

4. The personal token according to anyone of the preceding claims, characterized in that the record (13) storing the two access condition lists comprises at least two respective parts, each part being in the TLV - Tag Length Value - configuration.

5. The personal token according to anyone of the preceding claims, characterized in that the operating system is programmed for identifying the current security environment on the basis of the content of a header of an APDU command (15, 16) as received from the mobile terminal (20).

6. A method for accessing a file of a personal security token (10) which token (10) is hosted in a mobile telecommunication terminal (20), the method comprising a step of providing an access condition list (ACL) to such file (11 ) under a first security environment and an access condition list (ACL) to such file (11) under a second security environment both stored in the personal security token (10), the two access condition lists being both stored in a given file (12) which is divided into records, the method being characterized in that the access condition list (ACL) under the first security environment and the access condition list (ACL) under the second security environment are stored in the same record (13) of the said given file (12), and the method comprises the step of identifying by means of the token (10) whether the token (10) is currently actuated under the first security environment or under the second security environment and the token reading only the access condition list which corresponds to the current security environment.