Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
A PERSONAL TOKEN WITH SECURITY ARRANGEMENT FOR AVOIDING MISTAKEN DELETION OF DATA.
Document Type and Number:
WIPO Patent Application WO/2007/026209
Kind Code:
A1
Abstract:
The invention relates to a personal authenticating token comprising a microprocessor and a set of memorized instructions for controlling the microprocessor into monitoring an update command onto an elementary file and, when encountering said update command onto an elementary file, retrieving parameters of the update command which identify a location in the memory of the personal token where data is to be updated by said update command, retrieving the data which are present at said location and placing said data into a location in memory where said data can be recovered (80).

Inventors:
BARGHAV YUGANT (IN)
Application Number:
PCT/IB2006/002343
Publication Date:
March 08, 2007
Filing Date:
August 28, 2006
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
AXALTO SA (FR)
BARGHAV YUGANT (IN)
International Classes:
G07F7/10; G06F11/14; H04Q7/32
Domestic Patent References:
WO1996025743A11996-08-22
Foreign References:
EP1510924A12005-03-02
Attorney, Agent or Firm:
AXALTO S.A. (Ludovic, rue de la Verrerie Meudon, FR)
Download PDF:
Claims:

CLAIMS

1) A personal authenticating token comprising a microprocessor and a set of memorized instructions for controlling the microprocessor into monitoring an update command (40, 50) onto an elementary file (11 , 12, 21 , 22, 31 , 32) and, when encountering said update command onto an elementary file, retrieving parameters of the update command (40, 50) which identify a location in the memory of the personal token where data is to be updated by said update command, retrieving the data which are present at said location and storing said data into an other location (80) in memory where said data can be recovered.

2) A personal authenticating token according to claim 1 , characterized in that it stores an application for controlling the microprocessor into recovering said data in said location in memory where said data can be recovered and restoring said data at its original location in the elementary file (11 , 12, 21 , 22, 31 , 32).

3) A personal authenticating token according to claim 1 or claim 2, characterized in that the set of instructions retrieves low offset and high offset parameters in the update binary command (40) for identifying the location of the data in memory which have to be placed into the said location in memory where said data can be recovered.

4) A personal authenticating token according to claim 3, characterized in that the update command (40) is a "update binary" command.

5) A personal authenticating token according to claim 1 or claim 2, characterized in that the set of instructions controls the microprocessor into retrieving a record number in the update command (50) for identifying the location of the data in memory which have to be stored into the said location in memory where said data can be recovered.

6) A personal authenticating token according to claim 5, characterized in that the update command (50) is an "update record" command.

7) A personal authenticating token according to anyone of the preceding claims, characterized in that said set of instructions controls the microprocessor into performing an update command onto a file constituting the said location in memory where said data can be recovered with the data which are to be updated as identified by parameters of the encountered update command (40, 50), and the said set of instructions controls the microprocessor into then performing said encountered update command (40, 50).

8) A personal authenticating token according to anyone of the preceding claims, characterized in that it includes a master file and said location in memory where said data can be recovered is constituted by the master file.

9) A personal authenticating token according to anyone of the preceding claims, characterized in that the encountered update command (40, 50) is a remove command.

10) A method for updating an elementary file in a personal authenticating token said method comprising a step which consists in monitoring an update command (40, 50) onto an elementary file (11 , 12, 21 , 22, 31 , 32) and, when encountering said update command (40, 50), retrieving parameters of the update command which identify a location in the memory of the personal authenticating token where data is to be updated by said update command (40, 50), said method further comprising the step which consists in retrieving the data which are present at said location in memory and storing said data into an other location in memory where said data can be recovered (80).

Description:

A personal token with security arrangement for avoiding mistaken deletion of data

The invention relates to authenticating tokens such as SIM cards in the GSM network, but also such as any other authenticating token such as USB authenticating sticks or mass memory authenticating cards.

In accordance to "3GPP TS 11.11 Interface between a Subscriber Identity Module (SIM) and a Mobile Equipment (ME)", files are created at the time of personalization on a SIM card. An elementary file is typically defined as a file which contains access conditions and data. Access conditions typically are a set of security attributes associated with a file.

Three types of elementary files are utilized in a SIM. These three types all have one common feature. They are all composed of a header and a body part. However, all three files have different attributes as to how they can be accessed. Elementary structures for these three types of files are illustrated on figure 1a to 1c.

In the case of a transparent file (fig 1a), the body consists of a header 11 and of a sequence of bytes 12, therefore when reading or updating, the sequence of bytes 12 to be acted upon is referenced by a relative address (offset), which indicates the start position (in bytes), and the number of bytes to be read or updated. The first byte of a transparent elementary file has the relative address 1 OO 00". The total data length of the body of the elementary file is indicated in the header 11 of the elementary file. In the case of a linear fixed file (fig 1 b), the body consists of a header 21 and a sequence of records 22 all having the same (fixed) length. The first record is record number 1. The length of a record as well as this value multiplied by the number of records are indicated in the header of the elementary file.

In the case of a cyclic file (fig 1c), the file consists in a header 31 and a body 32 comprising a sequence of records. The body 32 stores records in

chronological order. When all records have been used for storage, then the next storage of data shall overwrite the oldest information.

Some of these Elementary file/s store data which is heavily accessed/modified from the subscribers during operation. These files may reside under GSM, Telecom, CDMA and or any other Dedicated file (DF). It may occur that during an active MS phase the subscriber intentionally removes a particular content of a transparent file, linear fixed file or a cyclic file.

On a later date the subscriber may then realize that he had actually removed an important content by mistake. The problem that the invention intends to solve is to protect the user against mistakenly erasing important data which may be present among elementary files. This problem is solved by way of the features of the invention as recited in the appended claims.

Other purposes, features and advantages of the invention will appear on reading the description which follows of a preferred implementation of the invention and of an embodiment of a system designed for this implementation, given as a non-limiting example, and referring to the attached drawings in which: Figures 1 a to 1c depict respective structures of a transparent elementary file, a linear elementary file, and a cyclic elementary file. - Figure 2 depicts a typical structure of an "update binary" command.

Figure 3 depicts a typical structure of an "update record" command. Figure 4 depicts a record content before and after a deletion process according to a preferred embodiment of the invention. Figure 5 depicts a process for restoring a file content according to a preferred embodiment of the invention.

For commercial GSM / CDMA (RUIM) there are a number of files that grant access conditions such that they can be "updated" by the subscriber.

As mentioned earlier during the execution of the APDU "Update" a different data access scheme is used for transparent and linear fixed or cyclic files. So for the three elementary files as depicted on figures 1 a to 1c only two

APDU commands are used as outlined below.

A first APDU command is called "Update Binary". This command triggers a function which allows the updating of the current elementary file, which shall be a transparent elementary file in this case, with a string of bytes.

The second APDU command is called "Update Record". This command triggers a function which allows the updating of one record in the current elementary file. The elementary file shall be of the fixed record or cyclic type (if the elementary file is a cyclic type, only the oldest record can be updated with the previous mode).

In the case of the "Update Binary" command the parameters of this command consist of a high offset and a low offset and of data to be updated.

Similarly, the parameters of the "Update Record" command consist of a field P1 , which contains the record number to be updated.

Once again the contents of P1 in question are extracted, i.e. picked up in the identified memory location in the card and saved in a complementary location before the update command is processed.

To that end, an implementation on the Update command is proposed below which can securely copy the contents of the elementary file in a buffer file before the APDU update command is executed.

In accordance with the present embodiment of the invention, the data within the selected record is picked up before the update command is pushed through.

Similarly, In order to save the contents of a transparent file, before the update binary command is executed the binary file in question is accessed and its contents are copied to the buffer file as illustrated below:

The structure of the update binary command onto an elementary file being updated and/or removed is illustrated on fig 2 under reference 40. From this APDU the P1 and P2 are picked up so that the contents of the elementary file being updated and/or removed are copied before deletion.

File Selection of Buffer File under the master file MF is made and an Update Binary command is executed onto the Buffer file thus copying and storing the contents safely.

Thθ Update Binary command is finally executed for the elementary file being updated as originally planned. In the whole of the present description, the word update may also signify "remove", i.e. updating current data into no substantial content. Similarly, in the case of record file, before the update record command is executed the contents of the selected record are copied to the buffer file as highlighted below.

The structure of the "Update Record" command of the elementary file being updated and/or removed is illustrated on figure 3 under reference 50. At receipt of this command, a specific application of the card extracts the P1 parameter from this command so that the contents of the elementary file at the location identified by P1 , i.e. the contents being updated and/or removed are copied into the buffer file before deletion.

An application is typically defined as consisting in a set of security mechanisms, files, data and protocols (excluding transmission protocols).

File selection of Buffer File under the master file MF is made and an "Update record" command is executed onto such Buffer file thus copying and storing the contents safely.

The master file is traditionally the unique mandatory file of a SIM card containing access conditions and optionally some dedicated files and/or some elementary files.

The "Update Record" command is finally executed onto the elementary file being updated and or removed as originally planned.

Finally a SIM resident applet is provided for restoring the contents from the buffer file. To that end the applet copies ,the selected record from the buffer file over to an empty record in the elementary file where it was originally removed from.

This applet is also utilized in the case of a Binary file.

In the example which is going to be described hereafter, the elementary file, called 6F3C is a linear fixed file which resides under DF 7F10. This elementary file contains information comprising short messages (and associated parameters)

which have either been received by the mobile equipment from the network, or are to be used as message originating from another mobile equipment.

A sample record content of the LF 6F3C is depicted on Figure 4 under reference 60. Using the mobile equipment the user wishes to remove the SMS. This in turn results with an execution of update command for 6F3C's record in question.

In the case of SMS the only change made is the first byte of the record which is updated to 00 from 01.

However, for other files such as ADN this is not the case. With ADN once a record is removed using the ME the file contents change to 'FF FF'.

Let us now consider that the first record, which has been removed must now be restored.

Figure 5 highlights the processes involved.

When the subscriber executes deletion upon 6F3C (Step 70) the contents of the record being removed are copied to the buffer file 6FXX (Step 80). The update command is then executed on 6F3C and thus it is removed (Step 90).

The applet as defined earlier is a simple tool to restore the contents of the buffer file to their original elementary file.

In the case of SMS, the record which is selected in the applet is removed from the buffer file and updated on its original elementary file. This allows the user to once again access the once deleted content. Finally, it should be noted that the above process is here the same for any elementary file and/or cyclic file.

In the case of transparent files however, the buffer file will simply contain the copy of the file which is removed with the file identifier. The described embodiments thus consist in restoring the eradicated contents of an elementary file via particular arrangements. A specific implementation mechanism of an update command is brought onto the SIM files, which implementation is utilized as an event handler for cloning the eradicated contents in a buffer file before removal. The subscriber then can restore the removed contents through a use of an applet present on the SIM.

The main but non restrictive application is retrieval of data that has been lost accidentally through the actions of the subscriber.