EP0944880A1 - Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires - Google Patents

Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires

Info

Publication number
EP0944880A1
EP0944880A1 EP98933716A EP98933716A EP0944880A1 EP 0944880 A1 EP0944880 A1 EP 0944880A1 EP 98933716 A EP98933716 A EP 98933716A EP 98933716 A EP98933716 A EP 98933716A EP 0944880 A1 EP0944880 A1 EP 0944880A1
Authority
EP
European Patent Office
Prior art keywords
file
link
files
security module
data
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.)
Withdrawn
Application number
EP98933716A
Other languages
German (de)
English (en)
Inventor
Jérôme AJDENBAUM
Patrice Hameau
Anne-France Presa
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull CP8 SA
Original Assignee
Bull CP8 SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull CP8 SA filed Critical Bull CP8 SA
Publication of EP0944880A1 publication Critical patent/EP0944880A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • 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/0806—Details of the card
    • G07F7/0813—Specific details related to card security
    • G07F7/0826—Embedded security module
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1416—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights
    • G06F12/1425—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block
    • G06F12/1441—Protection against unauthorised use of memory or access to memory by checking the object accessibility, e.g. type of access defined by the memory independently of subject rights the protection being physical, e.g. cell, word, block for a range

Definitions

  • Security module comprising means for creating links between main files and auxiliary files
  • the invention relates to a security module arranged to cooperate with an information processing device and comprising information processing means and information storage means, the storage means storing several files.
  • the term "security module” must be taken, either in its classic sense in which it designates a device intended, in a communication or information network, to be owned by an organization supervising the network and to be stored in a protected manner secret and fundamental parameters of the network such as cryptographic keys, that is to say - more simply a device allocated to various users of the network and allowing each of them to have access to it, this latter device also being susceptible to hold secret parameters.
  • the security module may take the form of a portable object of the smart card type.
  • the present invention relates in particular to micro-circuit cards and, more generally portable objects provided with integrated circuits comprising at least one microprocessor, a read only memory (ROM) containing an operating system of the card and one or more non-volatile memories. , programmable by the microprocessor. These non-volatile memories make it possible to store data and code.
  • the microprocessor controls the transfer of information and, if necessary, stores the data received from the outside or reads it to transmit it to the outside.
  • These objects have one or more means of communication.
  • the memories can be of EPROM, EEPROM, FeRAM, SRAM or FLASH technology.
  • This architecture defined in several levels is generally developed during the personalization of the card, that is to say before its use. It is however possible to add in use other directories or other data files, but this depends on the available space remaining in the programmable non-volatile memory. As this memory is of limited size, it is important not to waste space and to define during customization only the space necessary and sufficient for the proper functioning of directories and data files.
  • a great way not to waste space is to not duplicate information. Thus, it is necessary to avoid that the same information useful for several directories is written in an identical way in several places of the memory.
  • the hierarchical architecture of the directories prevents the sharing of the same data file between several directories. If two directories must have the same information, there is to date only the solution of creating two data files containing this same information inside.
  • the present invention solves this problem by avoiding the duplication of common information, while retaining the hierarchical links between data files and directories.
  • the multi-level structure can penalize access times to low-level data files or directories. Indeed, for to reach data from a lower level directory, in many cases it is necessary to select all the main higher level directories. For example, to go from one directory to another at the same level, you have to go up a tree structure to a first common directory then go back down, this by selecting intermediate directories. This successive selection mechanism is cumbersome and penalizing in time.
  • the present invention aims to solve these various problems: it provides a means of avoiding duplication in memory of identical data; it ensures the consistency of information shared between several files; Finally, it optimizes the search for information in remote directories, in the memory file tree.
  • a security module of the kind mentioned at the beginning of the presentation which includes:
  • means for creating a link arranged to create a link between at least one main file and an auxiliary file, the main file having a determined content and being made accessible to the processing means in the storage means thanks to location data, the means for creating a link associating said location data with the auxiliary file;
  • connection means arranged to make available processing means, when these execute an access request aiming to access the auxiliary file, said content of the main file using said location data.
  • Figure 1 shows a tree structure of several hierarchical levels in a map
  • Figure 2 shows a typical organization of directories and data files in a map
  • Figure 3 shows the detailed structure of two basic categories of files used in the invention
  • FIG. 4 is a flowchart detailing the steps of a file creation procedure according to the invention.
  • FIG. 5 is the diagram of a security module for which the invention is intended, cooperating with an information processing device.
  • the information processing device 51 represented in FIG. 5 comprises in a manner known per se a microprocessor 52 to which are connected a ROM memory 53, and a RAM memory 54, means 55 for cooperating, with or without physical contact, with a security module 58, and a transmission interface 57 allowing the information processing device to communicate with another similar device, either directly or through a communication network.
  • the device 51 can also be equipped with storage means such as floppy disks or removable or non-removable discs, input means (such as a keyboard and or a pointing device of the mouse type) and display means, these various means not being shown in FIG. 5.
  • the information processing device can be constituted by any computer device installed on a private or public site and able to provide means for managing information or issuing various goods or services, this device being permanently installed or portable. It can in particular also be a telecommunications device.
  • the security module 58 includes information processing means 59, a non-volatile memory 60, a volatile working memory RAM 64, and means 63 for cooperating with the information processing device.
  • This module is arranged to define, in the memory 60, a secret zone 61 in which information once recorded, are inaccessible from outside the module but only accessible to the processing means 59, and a free zone 62 which is accessible from outside the module for reading and / or writing information.
  • Each zone of the non-volatile memory 60 can comprise a non-modifiable part ROM and a modifiable part EPROM, EEPROM, or made up of RAM memory of the "flash" type, that is to say having the characteristics of an EEPROM memory with furthermore, access times identical to those of a conventional RAM.
  • security module 58 it will be possible in particular to use a microprocessor with self-programmable non-volatile memory, as described in US Patent No. 4,382,279 in the name of the Applicant.
  • the self-programming character of the memory corresponds to the possibility for a program fi located in this memory, to modify another program fj also located in this memory into a program gj.
  • the means to be used to carry out this autoprogramming can vary according to the technique used to design the information processing means 59, it is recalled that, in the case where these processing means are constituted by a microprocessor associated with a non-volatile memory and according to the aforementioned patent, these means can include:
  • this writing program can however be replaced by a writing automaton with logic circuits.
  • the microprocessor of the security module 58 is replaced - or at least supplemented - by logic circuits implanted in a semiconductor chip. Indeed, such circuits are capable of carrying out calculations, in particular of authentication and signature, thanks to wired, and not microprogrammed, electronics. They can in particular be of the ASIC type (from the English “Application Specifies Integrated Circuit”).
  • the security module 58 will be designed in monolithic form on a single chip.
  • the security nature of the security module may result from its location in a tamper-proof enclosure.
  • the non-volatile memory of the cards is organized into files which can be, as mentioned above, of two types: directory or elementary data file.
  • Each elementary file includes a header and a body containing information.
  • the level of hierarchy is specified in the header, there are also the file references, the state or life phase of the card, access conditions and size.
  • the header contains all the information that allows you to manage the information stored in the body.
  • Two or three levels are currently used. With reference to FIG. 1, and in general, the upper level is called "MAP”, and the lower levels “APPLICATION” or "SERVICE". We can perfectly consider cards with more than three levels; in the example cited, three levels are described.
  • the same card can be used for various applications such as: the bank, the municipality, the medical record, the cellular radiotelephone, which are represented by directories of APPLICATION level.
  • the municipal application there are parts such as public transport, access to the pool and library, payment for parking, which are represented by SERVICE level directories,
  • FIG. 2 illustrates an example of the hierarchical links between files in the programmable memory of a card.
  • the MAP directory contains two APPLICATION 1 and 2 directories and the basic file C1.
  • the APPLICATION 1 directory contains two SERVICE directories A1 -S1 and A1 -S2 and the basic file A1 -1.
  • the SERVICE directory A1 -S2 has only one elementary data file: A1 S1 -1.
  • the APPLICATION 2 directory has two SERVICE directories A2-S1 and A2-S2.
  • the SERVICE directory A2-S1 has two elementary data files: A2S1 -1 and A2S1 -2.
  • the SERVICE directory A2-S2 has a basic data file: A2S2-1.
  • the same information is used by two different directories.
  • the bank details of an individual carrying a card name and address of the holder, name and contact details of the bank, account number, information on the. credit ... etc. can be stored in an elementary file, included in the directory corresponding to the banking application, for example: the elementary file A1 -1 in the directory APPLICATION 1, described in FIG. 2.
  • the card can also be used as a city card; this application is managed by the APPLICATION 2 directory. It notably allows you to pay for public transport, access to the municipal library and certain cultural activities. paying (theater, cinema ). These services are managed by the two SERVICE directories A2-S1 and A2-S2, hierarchically dependent on the APPLICATION 2 directory.
  • the card serves as a means of payment, to pay, for example, journeys made by public transport, the money is debited directly from the bank account whose contact details are specified in the basic file A1-1. It is therefore necessary to make accessible from the SERVICE A2-S1 directory of the APPLICATION 2 directory, the information from the elementary file A1-1 of APPLICATION 1. This access is symbolized by the arrow in FIG. 2.
  • One way of carrying out the invention consists in creating and managing so-called "Link" files whose body is merged with that of other files.
  • the invention consists in being able to share the same file body between several files. This can be done by indicating, either in the header of the file, or in its body, the address where the data is actually located.
  • two files are represented, namely a target file 30 and a link file 31.
  • the following description concerns both the case where these files are data files and that where they represent directories. These directories contain either a tree structure of sub-directories giving access to data files, or data files which are directly attached to them, or both.
  • the term "data” includes both non-executable data and executable data or programs.
  • the target file 30 is organized, in this example, in two parts comprising a header 32 and a body 33.
  • the header 32 includes a first group of parameters known in themselves, namely: -a type, which indicates whether the file is a directory or a data file;
  • an identifier which designates the file within a directory which contains it; it is for example a name or a number;
  • the header 32 includes a second group of parameters which are specific to the inventory, namely:
  • -a ⁇ Link> parameter which can take two values: either the value 1, which indicates that this file is a link file, or the value 0 which indicates that it is not a link file; here, this parameter has the value 0;
  • Link ⁇ parameter which can take two values: either the value 1, which indicates that this file is a target file, or the value 0 which indicates that it is not a target file; here, this parameter has the value 1;
  • -an A-Link parameter which can take two values: either the value 1, which indicates that this file can be linked to a link file, or the value 0 which prevents it;
  • CA-a CA-Link parameter which defines creation conditions that the user must respect when he wants to create a link between this file and a link file: they can for example define keys or passwords to be presented by the user.
  • the header 32 finally includes a reference RC indicating to the microprocessor of the card a binary value of an RC memory address from which the aforementioned body 33 is stored.
  • the body 33 is stored in memory immediately following the header 32, so that the mention of the reference RC is not necessary.
  • the body 33 contains either a tree of subdirectories giving access to files data, either data files directly attached to it, or both;
  • the body 33 contains a set of data directly accessible for reading or modification, or executable by the microprocessor of the card.
  • the organization of the target file 30 could be different from that in two parts (header and body) presented in FIG. 3.
  • the parameters of the header 32 could be divided into specific areas of the body.
  • the link file 31 it comprises only one part, namely a header which has the same structure as that 32 of the target file 30, but has a content which differs therefrom as follows:
  • the A-Link and CA-Link parameters are generally not used, except in the particular case described below;
  • the "reference" is not that relating to a possible body attached to the link file, but an RFC reference specifying the location in memory of a target file thus linked to this link file. In this example, it is the target file 30.
  • the RFC reference is either preferably “physical” and constituted by a binary value of a memory address from which the aforementioned target file 32 is stored, or alternatively "Logical" and constituted by an access path specifying the identifiers of one or more directories from which the target file 32 is accessible.
  • the logical reference of the target file is easily usable because the physical addresses may constantly change. Taking as an example the case mentioned above, the logical reference is: [MAP ⁇ APPLICATION 1 ⁇ Data file A1-1].
  • link file has no body, but is linked to a specific target file, the body of which will thus be made available to the link file. It will be noted that, in a particular case, a second link file, different from the link file 31, could be linked, not directly to a target file, but for example to the link file 31. The situation would then be as follows:
  • the CA-Link parameter would be advantageously used in the header of the first link file to control the conditions for creating the second link file.
  • a microprocessor program In operation, when the user selects a file, a microprocessor program reads its header and tests its ⁇ Link> parameter. If it is equal to 0, the operation conforms to the prior art: the body is directly attached to this header.
  • the file is a link file.
  • the program therefore reads the RFC reference of this link file specifying the address or the path of a target file containing a body indirectly attached to the header of the link file. Before making the content of the body of the target file available to the user or the microprocessor, the program performs the following checks, by consulting the respective headers of the link file and the target file:
  • each access to the target file it checks compliance with the access conditions according to a procedure which will be specified below.
  • the program continues its procedure for accessing the content of the link file. If the size of the body of the target file is "zero bytes", that is to say if it contains nothing, the program stops and the card returns an error message. Otherwise, the program searches for the information contained in this body, from the RC address.
  • the file A1 -1 in the directory of application 1 was created in the form of a target file, and that the files A2S1 -1, A2S1 -2, A2S2-1 A2-S1 and A2-S2 service directories have been created in the form of link files. Consequently, the selection of a link file such as A2S1 -1 will give access to the content of the target file A1 -1.
  • the conditions of access to the body of the Target file must in all cases be respected, when executing a link between file-link and target file.
  • Several strategies are possible. The easiest way is to obey the access conditions defined in the header of the Target file: thus access to information in the Target file via the link file is only granted if the access conditions of the Target file are respected.
  • Another strategy consists in taking into account the access conditions of the target file when creating the link file. You must then verify that the access conditions entered in the header of the link file include all the access conditions of the Target file to which it will be linked.
  • a third strategy is applicable when the access conditions are expressed in the form of a binary value: it consists of combining the two access conditions. Concretely, this operation can be carried out by performing a logical AND between the two values. Access to information in the Target file via the link file is only granted if, at the same time, the access conditions for the Target and link files are respected.
  • A-Link parameter of a target file An important security development is to use the A-Link parameter of a target file to prevent it from being linked to another file. If the value of this parameter is "1", when creating a link file attached to this target file, the operation is completed and the content of the body of the target file is easily accessible by the file -link. If, however, the value of this field is "0", this target file cannot be linked to any other. When an attempt is made to create a link file designating a file with the A-Link field equal to "0", the operation is refused and the card returns an error message.
  • a first method therefore consists in testing the value> Link ⁇ . If this value is 1, the file that is being deleted is a Target file. The operation is then either prohibited or carried out but with a warning; in the latter case, the card control terminal must delete all the Link files linked to the deleted target file.
  • the counter is incremented.
  • the counter is decremented.
  • the value of the counter can be transmitted with the other header information: the user can thus know the number of link files attached to the selected target file.
  • the card program is equipped with a command, which can be activated from outside the card, making it possible to exchange the respective "link" statuses and "target" of two files.
  • a Target file that has become a Link file can be deleted without affecting other Link files.
  • the content of the new target file is then made up of that of the old target file. This is particularly easy when the body of files is physically separated headers.
  • the execution of this command is subject to the verification of the access conditions defined in the header of the old target file, and possibly to the verification of the conditions for creating links between files , defined by the CA-Link parameter in the directory of the new target file.
  • the value of the CP-Link counter of the old Target file is stored in the CP-Link counter of the new Target file.
  • Figure 4 illustrates a process for creating a file, whether it is a link file or not. It includes, in addition to steps specific to the invention and relating to the file-link, certain steps known in themselves and relating to the creation of any file, whatever its nature.
  • a file creation order is received by the card, accompanied by creation data: this data defines in particular the type and identifier of the file to be created and, if it is a file -link, the RFC reference (figure 3) of a target file to which it must be linked.
  • the card's operating system checks that the creation of a new file is possible in the current directory, also called "current" (step 2). Indeed, the creation of a new file is possibly subject to the proper prior presentation of keys defined by the access conditions of the header of the current directory. Then, we check that there is enough memory in the current directory to contain the new file (step 3). If one of these tests is negative, the creation order is interrupted (step 13), and the card then sends a message corresponding to the origin of the stop.
  • the operating system tests whether it is the creation of a normal file or the creation of a link file (step 4).
  • step 13 the creation operation is interrupted and the card sends an error message (step 13).
  • step 7 the A-Link parameter of the localized Target file is tested. If its value is "1", the operation can be completed. Otherwise, the Target file cannot be linked to any other.
  • the creation operation is then interrupted and the card sends an error message.
  • step 8 the operating system tests whether the possible keys defined in the conditions for creating the file-link, ie defined by the CA-link parameter of the target file, have been previously presented. If this is not the case, the creation operation is interrupted.
  • step 9 the operating system of the card verifies that the types of files and the conditions of access to the information are compatible. For this, the TYPE parameter of the Target file is compared to that transmitted in the creation data. If the values are different, or at least incompatible, as for example in the case of a creation order aiming to make a link between a data file and a directory, or a link between a data file of type "public" and a "secret” data file, then the creation operation is interrupted and the card sends an error message. This test is optional because another solution consists in forcing the data received for the Link file to be created, at the same value as that of the designated Target file: compatibility is certain in this case.
  • a last test carried out relates to the conditions of access to the information contained in the Target file (étapelO). This is to avoid bypassing the access conditions of the Target file by a Link file which would have more favorable access conditions.
  • One of the strategies described above consists in prohibiting the creation of a Link file having less restrictive access conditions than those of the Target file: the creation operation is then interrupted and the card sends an error message (step 13).
  • Another strategy consists in arranging, and therefore modifying, access conditions that are too favorable for the link file to make them at least as restrictive as those for the Target file. In this case, the test of step 10 becomes a calculation operation with modification, if necessary, of the access conditions transmitted in the command. Once the test steps have been completed, the creation of the Link file can take place.
  • step 11 the header of the Target file is updated. This mainly concerns the> Link ⁇ or Cp-Link parameter. If it is the> Link ⁇ parameter, the program checks that it has the value at "1", or otherwise sets it to this value. If, on the contrary, it is the Cp-Link counter, it is incremented by one.
  • step 12 a new file is effectively created, and the values of the header parameters of this file are determined in working memory from the creation data. These values are written to non-volatile programmable memory. If a Link file is created, a reference linked to the location of the Target file (physical or logical address) is written. Once all these steps have been completed, the card returns a correct status message and the new lerrrent file created is operational.
  • Target file The case of creating a Target file will not be detailed, since, when it is created, this file is analogous to a conventional file. It is only when it is linked to a link file that it becomes an effective target file.
  • a particularly interesting application of the invention and relating to link directories is that in which an electronic wallet directory is used by the card to allow payments.
  • This directory contains basic files containing keys, debit-credit zones, password validation zones, etc.
  • Such a directory can be used in various applications (transport, restaurant, central purchasing office): each 'they must therefore contain a link directory linked to the electronic purse directory, which then becomes a target directory.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un module de sécurité coopérant avec un dispositif de traitement de l'information et comportant des moyens de traitement de l'information et des moyens de stockage de l'information, ces derniers stockant plusieurs fichiers. Selon l'invention, le module de sécurité comprend: des moyens de création de liens agencés pour créer un lien entre au moins un fichier principal (30) et un fichier auxiliaire (31), le fichier principal ayant un contenu déterminé (33) et étant rendu accessible aux moyens de traitement dans les moyens de stockage grâce à des données de localisation (RFC), les moyens de création de lien associant au fichier auxiliaire (31) lesdites données de localisation; et des moyens de branchement agencés pour mettre à disposition des moyens de traitement, lorsque ceux-ci exécutent une demande d'accès visant à accéder au fichier auxiliaire (31), ledit contenu (33) du fichier principal (30) en utilisant lesdites données de localisation (RFC).

Description

Module de sécurité comportant des moyens de création de liens entre des fichiers principaux et des fichiers auxiliaires
L'invention est relative à un module de sécurité agencé pour coopérer avec un dispositif de traitement de l'information et comportant des moyens de traitement de l'information et des moyens de stockage de l'information, les moyens de stockage stockant plusieurs fichiers.
Le terme "module de sécurité" doit être pris, soit dans son sens classique dans lequel il désigne un dispositif ayant vocation, dans un réseau de communication ou d'information, à être détenu par un organisme supervisant le réseau et à stocker de façon protégée des paramètres secrets et fondamentaux du réseaα tels que des clés cryptographiques, soit comme désignant -plus simplement un dispositif attribué à divers usagers du réseau et permettant à chacun d'eux d'avoir accès à celui-ci, ce dernier dispositif étant lui aussi susceptible de détenir des paramètres secrets. Le module de sécurité pourra prendre la forme d'un objet portatif du type carte à puce.
La présente invention concerne notamment les cartes à micro-circuit et, plus généralement les objets portatifs dotés de circuits intégrés comportant au moins un microprocesseur, une mémoire morte (ROM) contenant un système d'exploitation de la carte et une ou plusieurs mémoires non volatiles, programmables par le microprocesseur. Ces mémoires non volatiles permettent de stocker des données et du code. Le microprocesseur contrôle le transfert des informations et, le cas échéant mémorise les données reçues de l'extérieur ou les lit pour les transmettre à l'extérieur. Ces objets possèdent un ou plusieurs moyens de communication. Les mémoires peuvent être de technologie EPROM, EEPROM, FeRAM, SRAM ou FLASH.
Grâce à l'évolution de la technologie, la taille de la mémoire ROM contenant le programme est de plus en plus importante ; ainsi les concepteurs de ce programme peuvent introduire de plus en plus de fonctions. Certaines de ces fonctions se rapportent directement à l'organisation de la mémoire programmable. Cette mémoire, dont la taille a aussi augmenté, est organisée hiérarchiquement en fichiers indépendants, cette organisation est décrite notamment dans la norme ISO 7816-4. De nos jours, les cartes peuvent servir à de multiples applications et pour cela elles possèdent souvent deux ou trois niveaux hiérarchiques appelés par exemple : CARTE, APPLICATION et SERVICE. A chaque niveau, les informations se rapportant à une même affectation sont regroupées en fichiers, ces fichiers comprenant deux niveaux de stockage , à savoir des "REPERTOIRES" et, dans chaque répertoire, des informations de même nature stockées dans des "FICHIERS DE DONNEES ".
Cette architecture définie en plusieurs niveaux s'élabore généralement lors de la personnalisation de la carte, c'est-à-dire avant son utilisation. Il est possible cependant de rajouter en utilisation d'autres répertoires ou d'autres fichiers de données , mais cela dépend de la place disponible restant dans la mémoire non volatile programmable. Cette mémoire étant de taille limitée, il est important de ne pas gaspiller d'emplacement et de définir lors de la personnalisation uniquement la place nécessaire et suffisante au bon fonctionnement des répertoires et des fichiers de données .
Un excellent moyen de ne pas perdre de place consiste à ne pas dupliquer les informations. Ainsi, il faut éviter que les mêmes informations utiles à plusieurs répertoires soient écrites de façon identique dans plusieurs endroits de la mémoire. Malheureusement, l'architecture hiérarchisée des répertoires empêche de partager un même fichier de données entre plusieurs répertoires. Si deux répertoires doivent posséder les mêmes informations, il n'existe à ce jour que la solution de créer deux fichiers de données comportant ces mêmes informations à l'intérieur. La présente invention résout ce problème en évitant la duplication d'informations communes, tout en conservant les liens hiérarchisés entre fichiers de données et répertoires.
Un autre problème est celui de la mise à jour de fichiers présents en plusieurs endroits de la mémoire : il faut en effet effectuer les modifications nécessaires en chaque endroit. Outre le fait que cette opération est longue, elle peut être perturbée par une interruption accidentelle du fonctionnement de la carte , avec pour conséquence probable une mise à jour incomplète de l'ensemble de ces fichiers , c'est-à-dire une mise à jour de certains fichiers, et pas des autres. La cohérence entre tous ces fichiers ne serait plus assurée.
Par ailleurs, la structure en plusieurs niveaux peut pénaliser les temps d'accès à des fichiers de données ou répertoires de bas niveaux. En effet, pour atteindre des données d'un répertoire d'un niveau inférieur, il faut dans de nombreux cas sélectionner tous les répertoires principaux de niveau supérieur. Par exemple, pour passer d'un répertoire à un autre de même niveau, il faut remonter une arborescence jusqu'à un premier répertoire commun puis redescendre, ceci en sélectionnant des répertoires intermédiaires. Ce mécanisme de sélection successive est lourd et pénalisant en temps.
La présente invention vise à résoudre ces différents problèmes : elle procure un moyen d'éviter la duplication en mémoire de données identiques ; elle assure la cohérence d'informations partagées entre plusieurs fichiers ; enfin, elle optimise la recherche d'informations dans des répertoires distants, dans l'arborescence des fichiers de la mémoire.
Elle concerne à cet effet un module de sécurité du genre cité au début de l'exposé, qui comprend :
-des moyens de création de lien agencés pour créer un lien entre au moins un fichier principal et un fichier auxiliaire, le fichier principal ayant un contenu déterminé et étant rendu accessible aux moyens de traitement dans les moyens de stockage grâce à des données de localisation, les moyens de création de lien associant au fichier auxiliaire lesdites données de localisation ;
-des moyens de branchement agencés pour mettre à disposition des moyens de traitement, lorsque ceux-ci exécutent une demande d'accès visant à accéder au fichier auxiliaire , ledit contenu du fichier principal en utilisant lesdites données de localisation.
D'autres détails et avantages de la présente invention apparaîtront au cours de la description suivante d'une forme de réalisation préféré mais non limitative, au regard des dessins annexés sur lesquels :
La figure 1 présente une arborescence de plusieurs niveaux hiérarchiques dans une carte ;
La figure 2 présente une organisation typique de répertoires et de fichiers de données dans une carte ; La figure 3 présente la structure détaillée de deux catégories fondamentales de fichiers utilisés dans l'invention ;
La figure 4 est un organigramme détaillant les étapes d'une procédure de création de fichier selon l'invention ; et La figure 5 est le schéma d'un module de sécurité auquel est destinée l'invention , coopérant avec un dispositif de traitement de l'information.
Le dispositif de traitement de l'information 51 représenté sur la figure 5 comprend de façon connue en soi un microprocesseur 52 auquel sont reliés une mémoire ROM 53, et une mémoire RAM 54, des moyens 55 pour coopérer, avec ou sans contact physique, avec un module de sécurité 58, et une interface de transmission 57 permettant au dispositif de traitement de l'information de communiquer avec un autre dispositif semblable, soit directement, soit au travers d'un réseau de communication.
Le dispositif 51 peut en outre être équipé de moyens de stockage tels que des disquettes ou disques amovibles ou non, de moyens de saisie (tels -qu'un clavier et ou un dispositif de pointage du type souris) et de moyens d'affichage, ces différents moyens n'étant pas représentés sur la figure 5. Le dispositif de traitement de l'information peut être constitué par tout appareil informatique installé sur un site privé ou public et apte à fournir des moyens de gestion de l'information ou de délivrance de divers biens ou services, cet appareil étant installé à demeure ou portable. Il peut notamment s'agir aussi d'un appareil de télécommunications. Par ailleurs, le module de sécurité 58 inclut des moyens de traitement de l'information 59, une mémoire non volatile 60, une mémoire volatile de travail RAM 64, et des moyens 63 pour coopérer avec le dispositif de traitement de l'information. Ce module est agencé pour définir, dans la mémoire 60, une zone secrète 61 dans laquelle des informations une fois enregistrées, sont inaccessibles depuis l'extérieur du module mais seulement accessibles aux moyens de traitement 59, et une zone libre 62 qui est accessible depuis l'extérieur du module pour une lecture et/ou une écriture d'informations. Chaque zone de la mémoire non volatile 60 peut comprendre une partie non modifiable ROM et une partie modifiable EPROM, EEPROM, ou constituée de mémoire RAM du type "flash", c'est-à-dire présentant les caractéristiques d'une mémoire EEPROM avec en outre des temps d'accès identiques à ceux d'une RAM classique.
En tant que module de sécurité 58, on pourra notamment utiliser un microprocesseur à mémoire non volatile autoprogrammable, tel que décrit dans le brevet américain n° 4.382.279 au nom de la Demanderesse. Comme indiqué en colonne 1 , lignes 13-25 de ce brevet, le caractère autoprogrammable de la mémoire correspond à la possibilité pour un programme fi situé dans cette mémoire, de modifier un autre programme fj situé également dans cette mémoire en un programme gj. Bien que les moyens à mettre en oeuvre pour réaliser cette autoprogrammation puissent varier selon la technique utilisée pour concevoir les moyens de traitement de l'information 59, on rappelle que, dans le cas où ces moyens de traitement sont constitués par un microprocesseur associé à une mémoire non volatile et selon le brevet précité, ces moyens peuvent inclure :
-des mémoires tampon de données et d'adresses, associées à la mémoire ; -un programme d'écriture dans la mémoire, chargé dans celle-ci et contenant notamment les instructions permettant le maintien d'une part de la tension de programmation de la mémoire, et d'autre part des données à écrire et de leurs adresses, pendant un temps suffisant, ce programme d'écriture pouvant toutefois être remplacé par un automate d'écriture à circuits logiques. Dans une variante, le microprocesseur du module de sécurité 58 est remplacé -ou tout du moins complété- par des circuits logiques implantés dans une puce à semi-conducteurs. En effet, de tels circuits sont aptes à effectuer des calculs, notamment d'authentification et de signature, grâce à de l'électronique câblée, et non microprogrammée. Ils peuvent notamment être de type ASIC (de l'anglais « Application Spécifie Integrated Circuit »). A titre d'exemple, on peut citer le composant de la société SIEMENS commercialisé sous la référence SLE 4436 et celui de la société SGS-THOMSON commercialisé sous la référence ST 1335.
Avantageusement, le module de sécurité 58 sera conçu sous forme monolithique sur une seule puce. En variante au microprocesseur à mémoire non volatile autoprogrammable décrit ci-dessus, le caractère sécuritaire du module de sécurité pourra résulter de sa localisation dans une enceinte inviolable.
La mémoire non volatile des cartes est organisée en fichiers qui peuvent être, comme rappelé précédemment, de deux types : répertoire ou fichier élémentaire de données. Chaque fichier élémentaire comprend un en-tête et un corps contenant des informations. Le niveau de hiérarchisation est précisé dans l'en-tête, on y trouve également les références du fichier, l'état ou phase de vie de la carte, les conditions d'accès et la taille. En règle générale, l'en-tête contient l'ensemble des informations qui permettent de gérer les informations stockées dans le corps. Deux ou trois niveaux sont actuellement utilisés. En référence à la figure 1 , et en général, le niveau supérieur est appelé "CARTE", et les niveaux inférieurs "APPLICATION" ou "SERVICE". On peut parfaitement envisager des cartes avec plus de trois niveaux ; dans l'exemple cité, trois niveaux sont décrits.
A titre d'exemple, une même carte peut être utilisée pour diverses applications telles que : la banque, la municipalité, le dossier médical, le radiotéléphone cellulaire, qui sont représentées par des répertoires de niveau APPLICATION. Dans l'application municipale, on trouve des parties telles que les transport publics, l'accès à la piscine et à la bibliothèque, le paiement du stationnement, qui sont représentées par des répertoires de niveau SERVICE,
La figure 2 illustre un exemple des liens hiérarchisés entre des fichiers dans la mémoire programmable d'une carte. Le répertoire CARTE contient deux répertoires APPLICATION 1 et 2 et le fichier élémentaire C1 . Le répertoire APPLICATION 1 contient deux répertoires SERVICE A1 -S1 et A1 -S2 et le fichier élémentaire A1 -1 . Le répertoire SERVICE A1 -S2 possède un seul fichier élémentaire de données : A1 S1 -1. Le répertoire APPLICATION 2 possède deux répertoires SERVICE A2-S1 et A2-S2. Le répertoire SERVICE A2-S1 possède deux fichiers élémentaires de données : A2S1 -1 et A2S1 -2. Le répertoire SERVICE A2-S2 possède un fichier élémentaire de données : A2S2-1 . Tous ces fichiers occupent une place non négligeable dans la mémoire limitée de la carte, il est donc important d'optimiser l'occupation mémoire et d'éviter de dupliquer les mêmes informations dans plusieurs emplacements différents. Dans certains cas, les mêmes informations sont utilisées par deux répertoires différents. Par exemple, les coordonnées bancaires d'un individu porteur d'une carte : nom et adresse du porteur, nom et coordonnées de la banque, numéro de compte, information sur le. crédit ...etc. peuvent être stockées dans un fichier élémentaire, inclus dans le répertoire correspondant à l'application bancaire, par exemple : le fichier élémentaire A1 -1 dans le répertoire APPLICATION 1 , décrit dans la figure 2.
La carte peut aussi servir de carte-ville ; cette application est gérée par le répertoire APPLICATION 2. Elle permet notamment de payer les transports en commun, d'accéder à la bibliothèque municipale et à certaines activités culturelles payantes (théâtre, cinéma...). Ces services sont gérés par les deux répertoires SERVICE A2-S1 et A2-S2, hiérarchiquement dépendants du répertoire APPLICATION 2. Lorsque la carte sert de moyen de paiement, pour payer par exemple les trajets effectués dans les transports en commun, l'argent est débité directement sur le compte bancaire dont les coordonnées sont précisées dans le fichier élémentaire A1-1. Il faut donc rendre accessible depuis le répertoire SERVICE A2-S1 du répertoire APPLICATION 2, les informations du fichier élémentaire A1-1 de APPLICATION 1. Cet accès est symbolisé par la flèche sur la figure 2. La solution consistant à reproduire les données n'est pas satisfaisante. Un autre exemple concerne les clés secrètes et les codes confidentiels : leurs valeurs peuvent être identiques lors de l'accès à différentes répertoires qui ne sont pas hiérarchiquement dépendants. Le problème est important si des clés de type RSA ( des inventeurs Rivest, Shamir et Adleman) stockées sur plus de 1024 bits sont utilisées. Un dernier exemple concerne les fichiers élémentaires de ratification : ces fichiers élémentaires servent à mémoriser les bonnes ou mauvaises présentations de clés ou codes. Le regroupement de plusieurs fichiers élémentaires de ratification correspondant à des clés différentes permet de gagner de la place et d'accroître la sécurité.
Une façon de réaliser l'invention consiste à créer et gérer des fichiers dits "Lien" dont le corps est confondu avec celui d'autres fichiers. L'invention consiste à pouvoir partager un même corps de fichier entre plusieurs fichiers. Ceci peut être réalisé en indiquant, soit dans l'en-tête du fichier, soit dans son corps, l'adresse où se situent effectivement les données.
Sur la figure 3, sont représentés deux fichiers, à savoir un fichier-cible 30 et un fichier-lien 31. La description qui suit concerne aussi bien le cas où ces fichiers sont des fichiers de données et celui où ils représentent des répertoires. Ces répertoires contiennent soit une arborescence de sous-répertoires donnant accès à des fichiers de données, soit des fichiers de données qui leur sont directement rattachés, soit les deux. Le terme « données » regroupe à la fois des données non exécutables et des données exécutables ou programmes.
Le fichier-cible 30 est organisé, dans cet exemple, en deux parties comprenant un en-tête 32 et un corps 33. L'en-tête 32 inclut un premier groupe de paramètres connus en eux-mêmes, à savoir : -un type, qui indique si le fichier est un répertoire ou bien un fichier de données ;
-un identifiant qui désigne le fichier au sein d'un répertoire qui le contient ; il s'agit par exemple d'un nom ou d'un numéro ; et
-des conditions d'accès qui donnent une liste de droits d'accès à ce fichier déterminé, pour tout usager : elles précisent par exemple si le fichier est accessible ou non en lecture ou écriture ; de façon connue en soi, la délivrance de ces droits peut être subordonnée à la présentation de clés ou mots de passe.
L'en-tête 32 inclut un second groupe de paramètres qui sont spécifiques à l'inventiorr, à savoir :
-un paramètre <Lien> qui peut prendre deux valeurs : soit la valeur 1 , qui indique que ce fichier est un fichier-lien soit la valeur 0 qui indique qu'il n'est pas un fichier-lien ; ici, ce paramètre a la valeur 0 ;
-un paramètre >Lien< qui peut prendre deux valeurs : soit la valeur 1 , qui indique que ce fichier est un fichier-cible, soit la valeur 0 qui indique qu'il n'est pas un fichier-cible ; ici, ce paramètre a la valeur 1 ; -un paramètre A-Lien qui peut prendre deux valeurs : soit la valeur 1 , qui indique que ce fichier peut être lié à un fichier-lien , soit la valeur 0 qui l'en empêche ; et
-un paramètre CA-Lien qui définit des conditions de création que l'usager devra respecter lorsqu'il voudra créer un lien entre ce fichier et un fichier- lien : elles pourront par exemple définir des clés ou mots de passe à présenter par l'usager.
L'en-tête 32 comporte enfin une référence RC indiquant au microprocesseur de la carte une valeur binaire d'une adresse mémoire RC à partir de laquelle est stocké le corps 33 précité. Dans une variante, le corps 33 est stocké en mémoire immédiatement à la suite de l'en-tête 32, de sorte que la mention de la référence RC n'est pas nécessaire.
Par ailleurs, si le fichier cible 30 est du type « répertoire » , le corps 33 contient soit une arborescence de sous-répertoires donnant accès à des fichiers de données, soit des fichiers de données qui lui sont directement rattachés, soit les deux ;
Si au contraire le fichier-cible 30 est du type « fichier de données », le corps 33 contient un ensemble de données directement accessibles pour lecture ou modification, ou exécutables par le microprocesseur de la carte .
En variante , l'organisation du fichier-cible 30 pourra être différente de celle en deux parties (en-tête et corps) présentée sur la figure 3. Ainsi par exemple , les paramètres de l'en-tête 32 pourront être répartis en des endroits spécifiques du corps. Quant au fichier-lien 31 , il ne comprend qu'une seule partie, à savoir un entête qui présente la même structure que celui 32 du fichier-cible 30, mais a un contenu qui en diffère de la façon suivante :
-s'agissant d'un fichier-lien , et non d'un fichier-cible, les paramètres A-Lien et CA-Lien ne sont en général pas utilisés, sauf dans le cas particulier décrit plus loin ;
-par ailleurs, la « référence » n'est pas celle relative à un éventuel corps rattaché au fichier-lien , mais une référence RFC précisant la localisation en mémoire d'un fichier-cible ainsi lié à ce fichier-lien. Dans cet exemple , c'est le fichier-cible 30. La référence RFC est soit de préférence « physique » et constituée par une valeur binaire d'une adresse mémoire à partir de laquelle est stocké le fichier-cible 32 précité, soit en variante « logique » et constituée par un chemin d'accès précisant les identifiants d'un ou plusieurs répertoires à partir desquels le fichier-cible 32 est accessible.
Dans le cas très particulier d'une gestion dynamique de la mémoire de la carte, celle-ci peut être ré-organisée par le microprocesseur afin d'optimiser l'occupation de la mémoire. L'emplacement des fichiers peut donc fluctuer, ainsi par conséquent que leurs adresses d'implantation. Dans ce cas, seule la référence logique du fichier-cible est facilement utilisable car les adresses physiques risquent de constamment changer. En prenant comme exemple le cas évoqué précédemment, la référence logique est : [CARTE → APPLICATION 1 → Fichier de données A1-1].
Il apparaît donc qu'un fichier-lien est dépourvu de corps, mais est lié à un fichier-cible déterminé, dont le corps sera ainsi mis à disposition du fichier-lien. On notera que, dans un cas particulier, un second fichier-lien, différent du fichier-lien 31 , pourrait être lié, non pas directement à un fichier-cible , mais par exemple au fichier-lien 31 . La situation serait alors la suivante :
-la référence contenue dans le second fichier-lien serait celle du fichier-lien 31 ;
-le paramètre CA-Lien serait avantageusement utilisé dans l'en-tête du premier fichier-lien pour contrôler les conditions de création du second fichier-lien .
En fonctionnement, lors de la sélection d'un fichier par l'usager , un programme du microprocesseur lit son en-tête et teste son paramètre <Lien>. S'il est égal à 0, le fonctionnement est conforme à l'art antérieur : le corps estdirectement rattaché à cet en-tête.
Si <Lien> est égal à 1 , le fichier est un fichier-lien. Le programme lit en conséquence la référence RFC de ce fichier-lien précisant l'adresse ou le chemin d'accès d'un fichier-cible contenant un corps indirectement rattaché à l'en-tête du fichier-lien. Avant de mettre à disposition de l'usager ou du microprocesseur le contenu du corps du fichier-cible , le programme effectue les vérifications suivantes, en consultant les en-têtes respectifs du fichier-lien et du fichier-cible :
-lors de la création du fichier-lien, il vérifie que le type du fichier-cible identifié est identique à celui du fichier-lien ; dans la négative, la procédure d'accès au fichier-lien est interrompue ;
-lors de chaque accès au fichier-cible, il vérifie le respect des conditions d'accès selon une procédure qui sera précisée plus loin.
Ces vérifications étant effectuées, le programme poursuit sa procédure d'accès au contenu du fichier-lien. Si la taille du corps du fichier-cible est « zéro octet » , c'est-à-dire s'il ne contient rien, le programme s'interrompt et la carte renvoie un message d'erreur. Sinon, le programme recherche les informations contenues dans ce corps, à partir de l'adresse RC. En reprenant l'exemple de la figure 2, on suppose que le fichier A1 -1 du répertoire de l'application 1 a été créé sous forme de fichier-cible, et que les fichiers A2S1 -1 , A2S1 -2, A2S2-1 des répertoires service A2-S1 et A2-S2 ont été créés sous forme de fichiers-lien. En conséquence, la sélection d'un fichier-lien tel que A2S1 -1 donnera accès au contenu du fichier-cible A1 -1 . Les conditions d'accès au corps du fichier-Cible, définies dans l'en-tête de celui-ci, doivent dans tous les cas être respectées, lors de l'exécution d'un lien entre fichier-lien et fichier-cible . Plusieurs stratégies sont possibles. La plus simple consiste à obéir aux conditions d'accès définies dans l'en-tête du fichier- Cible :ainsi l'accès des informations dans le fichier-Cible via le fichier-lien n'est accordé que si les conditions d'accès du fichier-Cible sont respectées.
Une autre stratégie consiste à prendre en compte les conditions d'accès du fichier-Cible lors de la création du fichier-lien. Il faut alors vérifier que les conditions d'accès inscrites dans l'en-tête du fichier-lien incluent toutes les conditions d'accès du fichier-Cible auquel il va être lié.
Une troisième stratégie est applicable lorsque les conditions d'accès s'expriment sous la forme d'une valeur binaire : elle consiste à cumuler les deux conditions d'accès. Concrètement, cette opération peut être réalisée en effectuant un ET logique entre les deux valeurs. L'accès des informations dans le fichier- Cible via le fichier-lien n'est accordé que si, à la fois, les conditions d'accès des fichiers-Cible et lien sont respectées.
A travers ces différentes stratégies, le lecteur comprend que l'objectif, au niveau du contrôle d'accès, consiste à proscrire toute possibilité de contourner les conditions d'accès d'un fichier en le liant à un fichier qui possède des conditions d'accès plus favorables. D'autres stratégies, connues de l'homme du métier, pourront être utilisées pour assurer la sécurité d'accès.
Un perfectionnement important concernant la sécurité consiste à utiliser le paramètre A-Lien d'un fichier-cible pour l'empêcher d'être lié à un autre fichier . Si la valeur de ce paramètre est "1", lors de la création d'un fichier-lien rattaché à ce fichier-cible , l'opération est menée à bien et le contenu du corps du fichier-Cible est bien accessible par le fichier-lien. Si en revanche la valeur de ce champ est "0", ce fichier-cible ne peut être lié à aucun autre. Lors d'une tentative de création d'un fichier-lien désignant un fichier dont le champ A-Lien égal à "0", l'opération est refusée et la carte rend un message d'erreur.
Un problème se pose lors de l'effacement, c'est-à-dire de la suppression de fichiers Lien/Cible. Si un fichier-Cible est effacé, l'accès par des fichiers-Liens aux informations qu'il contenait n'est plus possible. Les conséquences d'un tel effacement ne sont donc pas uniquement limitées au répertoire qui contenait ce fichier, mais peuvent se répercuter dans d'autres répertoires. La solution consiste soit à interdire l'effacement du fichier-Cible auquel est rattaché un ou plusieurs fichiers-Lien , soit à avertir l'utilisateur de la carte que certains fichiers ne sont plus opérationnels après cet effacement. Un première méthode consiste donc à tester la valeur >Lien<. Si cette valeur est 1 , le fichier que l'on est en train d'effacer est un fichier-Cible. L'opération est alors soit interdite , soit menée à bien mais avec un avertissement ; dans ce dernier cas, le terminal de commande de la carte doit effacer tous les fichiers-Lien liés au fichier-cible effacé. Pour effacer un fichier-Cible sans perturber le reste de la mémoire, il faut donc préalablement effacer tous les fichiers-Lien qui lui sont rattachés. Lorsque le dernier fichier-Lien est effacé, l'indicateur >Lien< prend la valeur "0" : il ne .s'agit donc plus d'un fichier-Cible. Un simple indicateur binaire n'est donc pas suffisant pour comptabiliser le nombre de fichiers-Lien sans devoir balayer chaque fois toute la mémoire non volatile de la carte . Une solution consiste à prévoir un compteur Cp-Lien à la place du paramètre >Lien<. Avantageusement, ce compteur est de 8 bits, ce qui autorise l'existence de 255 fichiers-Liens au maximum : ce nombre paraît largement suffisant pour des applications courantes. Ce compteur est incorporé dans l'en-tête du fichier-cible . Lors de la création du fichier-cible, le compteur Cp-Lien est mis à "00". A chaque nouvelle création d'un fichier-Lien qui est rattaché au fichier-cible , le compteur est incrémenté. A chaque effacement d'un fichier-Lien qui lui est rattaché, le compteur est décrémenté. Avantageusement, lors de la sélection de ce fichier-cible, la valeur du compteur peut être émise avec les autres information d'en-tête : l'utilisateur peut ainsi connaître le nombre de fichiers-Lien rattachés au fichier-cible sélectionné.
Pour résoudre le problème de l'effacement d'un fichier-Cible de façon plus adroite, le programme de la carte est équipé d'une commande, activable de l'extérieur de la carte, permettant d'échanger les statuts respectifs « lien » et « cible » de deux fichiers. Ainsi, un fichier-Cible devenu un fichier-Lien peut être effacé sans conséquence pour les autres fichiers-Lien. Le contenu du nouveau fichier-Cible est alors constitué par celui de l'ancien fichier-cible . Cette opération est particulièrement facile lorsque les corps de fichiers sont physiquement séparés des en-têtes. Pour des raisons de sécurité, l'exécution de cette commande est soumise à la vérification des conditions d'accès définies dans l'en-tête de l'ancien fichier-cible, et éventuellement à la vérification des conditions de création de liens entre fichiers, définies par le paramètre CA-Lien dans le répertoire du nouveau fichier-cible . Lors de l'exécution de cette commande d'échange, la valeur du compteur CP-Lien de l'ancien fichier-Cible est mémorisée dans le compteur CP- Lien du nouveau fichier-Cible.
La figure 4 illustre un procédé de création d'un fichier, qu'il s'agisse d'un fichier-lien ou non. Il inclut, outre des étapes spécifiques à l'invention et relatives au fichier-lien , certaines étapes connues en elles-mêmes et relatives à la création de tout fichier, quelle que soit sa nature. A l'étape 1 , un ordre de création de fichier est reçu par la carte, accompagné de données de création : ces données définissent notamment le type et l'identifiant du fichier à créer et, s'il s'agit d'un fichier-lien , la référence RFC (figure 3) d'un fichier-cible auquel il doit être lié.
Ensuite, le système d'exploitation de la carte vérifie que la création d'un nouveau fichier est possible dans le répertoire actuel, appelé aussi "courant" (étape 2). En effet, la création d'un nouveau fichier est éventuellement soumise à la bonne présentation préalable de clés définies par les conditions d'accès de l'en- tête du répertoire courant. Puis, on vérifie qu'il reste suffisamment de mémoire dans le répertoire courant pour contenir le nouveau fichier (étape 3). Si un de ces tests est négatif, l'ordre de création est interrompu (étape 13), et la carte renvoie alors un message correspondant à l'origine de l'arrêt.
Le système d'exploitation teste ensuite s'il s'agit de la création d'un fichier normal ou de la création d'un fichier-Lien (étape 4). Une différence importante entre un fichier normal et un fichier-lien, et sur laquelle peut porter le test réside dans les données de création, et principalement dans l'indication précise de la localisation du fichier-Cible (adresse physique ou logique). Si ce n'est pas un fichier-Lien, le programme saute directement à l'étape 12 décrite ci-après. Dans le cas contraire, les informations correspondant au fichier-Cible désigné sont recherchées et analysées à l'étape 5 ; puis le système d'exploitation effectue un certain nombre de tests pour s'assurer que le lien entrele fichier-cible désigné et le fichier-lien à créer est possible. Tout d'abord, on vérifie à l'aide des données de création que le fichier-Cible existe bien (étape 6). Si par contre, ces données ne correspondent à aucun fichier, l'opération de création est interrompue et la carte envoie un message d'erreur (étape 13). A l'étape 7, le paramètre A-Lien du fichier Cible localisé est testé. Si sa valeur est "1", l'opération peut être menée à bien. Sinon, le fichier-Cible ne peut être lié à aucun autre. L'opération de création est alors interrompue et la carte envoie un message d'erreur. A l'étape 8, le système d'exploitation teste si les éventuelles clés définies dans les conditions de création du fichier-Lien, c'est à dire définies par le paramètre CA-Lien du fichier-Cible, ont été préalablement présentées. Si ce n'est pas le cas, l'opération de création est interrompue.
A l'étape 9, le système d'exploitation de la carte vérifie que les types de fichiers et»les conditions d'accès aux informations sont compatibles. Pour ceja, le paramètre TYPE du fichier-Cible est comparé à celui transmis dans les données de création. Si les valeurs sont différentes, ou du moins incompatibles, comme par exemple dans le cas d'un ordre de création visant à faire un lien entre un fichier de données et un répertoire, ou un lien entre un fichier de données de type "public" et un fichier de données de type "secret", alors l'opération de création est interrompue et la carte envoie un message d'erreur. Ce test est facultatif car une autre solution consiste à forcer les données reçues pour le fichier-Lien à créer, à la même valeur que celles du fichier Cible désigné : la compatibilité est dans ce cas certaine.
Enfin, un dernier test effectué porte sur les conditions d'accès aux informations contenues dans le fichier-Cible (étapelO). Il s'agit d'éviter de contourner les conditions d'accès du fichier-Cible par un fichier-Lien qui posséderait des conditions d'accès plus favorables. Une des stratégies décrites précédemment consiste à interdire la création d'un fichier-Lien possédant des conditions d'accès moins restrictives que celles du fichier-Cible : l'opération de création est alors interrompue et la carte envoie un message d'erreur (étape 13). Une autre stratégie consiste à aménager, et donc modifier, des conditions d'accès trop favorables du fichier-lien pour les rendre au moins aussi restrictives que celles du fichier-Cible. Dans ce cas, le test de l'étape 10 devient une opération de calcul avec modification, si besoin, des conditions d'accès transmises dans la commande. Une fois les étapes de test franchies, la création du fichier-Lien peut intervenir. A l'étape 11 , l'en-tête du fichier-Cible est mise à jour. Cela concerne principalement le paramètre >Lien< ou Cp-Lien. S'il s'agit du paramètre >Lien<, , le programme vérifie qu'il possède la valeur à "1", ou sinon le met à cette valeur. S'il s'agit au contraire du compteur Cp-Lien, , celui-ci est incrémenté d'une unité.
Enfin à l'étape 12, un nouveau fichier est effectivement créé, et les valeurs des paramètres d'en-tête de ce fichier sont déterminées en mémoire de travail à partir des données de création. Ces valeurs sont écrites en mémoire programmable non volatile. Si c'est un fichier-Lien qui est créé, une référence liée à la localisation du fichier-Cible (adresse physique ou logique) est écrite. Une fois toutes ces étapes franchies, la carte rend un message d'état correct et le fichier nouvel lerrrent créé est opérationnel.
Le cas de la création d'un fichier-Cible ne sera pas détaillé, puisque, lors de sa création, ce fichier est analogue à un fichier classique. Ce n'est qu'au moment où il est lié à un fichier-lien qu'il devient un fichier-cible effectif.
Une application particulièrement intéressante de l'invention et relative aux répertoires-lien est celle où un répertoire porte-monnaie électronique est utilisé par la carte pour permettre des paiements. Ce répertoire contient des fichiers élémentaires contenant des clés, des zones débit-crédits, des zones de validation de mot de passe, etc.. Un tel répertoire peut être utilisé dans diverses applications (transport, restaurant, centrale d'achats) : chacune d'elles doit donc contenir un répertoire-lien lié au répertoire porte-monnaie électronique, lequel devient alors un répertoire-cible.

Claims

REVENDICATIONS
1. Module de sécurité agencé pour coopérer avec un dispositif de traitement de l'information et comportant des moyens de traitement de l'information et des moyens de stockage de l'information, les moyens de stockage stockant plusieurs fichiers , caractérisé en ce qu'il comprend :
-des moyens de création de lien agencés pour créer un lien entre au moins un fichier principal (30) et un fichier auxiliaire (31 ), le fichier principal ayant un contenu déterminé (33) et étant rendu accessible aux moyens de traitement dans les moyens de stockage grâce à des données de localisation (RFC), les moyens de création de lien associant au fichier auxiliaire (31 ) lesdites données de localisation ;
-des moyens de branchement agencés pour mettre à disposition des moyens de traitement, lorsque ceux-ci exécutent une demande d'accès visant à accéder au fichier auxiliaire (31 ), ledit contenu (33) du fichier principal (30) en utilisant lesdites données de localisation (RFC).
2. Module de sécurité selon la revendication 1 , dans lequel le fichier auxiliaire (31 ) contient un paramètre (<lien>) indiquant qu'il contient des données de localisation d'un fichier principal (30).
3. Module de sécurité selon la revendication 1 , dans lequel le fichier principal (30) contient un paramètre (>lien<) indiquant que ses données de localisation (RFC) sont associées à au moins un fichier auxiliaire (31).
4. Module de sécurité selon la revendication 3, dans lequel ledit paramètre (>lien<) est une valeur d'un compteur (Cp-Lien) agencé pour compter un nombre de fichiers auxiliaires.(31) qui sont liés à ce fichier principal (30).
5. Module de sécurité selon la revendication 1, dans lequel le fichier principal (30) contient un paramètre (A-Lien) indiquant si la mise à disposition de son contenu lors d'une demande d'accès au fichier auxiliaire (31 ) est autorisée ou non.
6. Module de sécurité selon la revendication 1 , dans lequel le fichier principal (30) contient un paramètre (CA-Lien) définissant des conditions de création à respecter par les moyens de traitement lors de la création d'un lien avec un fichier auxiliaire (31 ) déterminé.
EP98933716A 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires Withdrawn EP0944880A1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR9707996 1997-06-26
FR9707996A FR2765362B1 (fr) 1997-06-26 1997-06-26 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
PCT/FR1998/001344 WO1999000774A1 (fr) 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires

Publications (1)

Publication Number Publication Date
EP0944880A1 true EP0944880A1 (fr) 1999-09-29

Family

ID=9508465

Family Applications (1)

Application Number Title Priority Date Filing Date
EP98933716A Withdrawn EP0944880A1 (fr) 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires

Country Status (12)

Country Link
EP (1) EP0944880A1 (fr)
JP (1) JP2000503157A (fr)
KR (1) KR20000068374A (fr)
CN (1) CN1231042A (fr)
AR (1) AR016092A1 (fr)
AU (1) AU8343998A (fr)
BR (1) BR9806014A (fr)
CA (1) CA2264896A1 (fr)
FR (1) FR2765362B1 (fr)
NO (1) NO990893L (fr)
TW (1) TW434504B (fr)
WO (1) WO1999000774A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4565703B2 (ja) * 2000-05-16 2010-10-20 グローリー株式会社 データ記憶装置およびデータ記憶方法
KR20070030157A (ko) * 2004-06-14 2007-03-15 소니 가부시끼 가이샤 정보 관리 장치 및 정보 관리 방법
JP5124733B2 (ja) * 2006-04-25 2013-01-23 キヤノンＩｔソリューションズ株式会社 サーバ装置および情報共有システムおよびプログラムおよび記録媒体
CN102306170A (zh) * 2011-08-23 2012-01-04 北京握奇数据系统有限公司 一种存储及处理智能卡公共信息的方法及装置
WO2017163686A1 (fr) * 2016-03-23 2017-09-28 ソニー株式会社 Dispositif de traitement d'informations et procédé de traitement d'informations

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS63253493A (ja) * 1987-04-09 1988-10-20 Mitsubishi Electric Corp 情報記録システム
DE68915186T2 (de) * 1988-03-09 1994-08-25 Toshiba Kawasaki Kk Tragbarer elektronischer Apparat.
JP3017736B2 (ja) * 1988-03-09 2000-03-13 株式会社東芝 携帯可能電子装置
JPH04373040A (ja) * 1991-06-21 1992-12-25 Fujitsu Ltd ファイル管理方式
FR2696854A1 (fr) * 1992-10-09 1994-04-15 Kudelski Sa Fabrique Enreg Nag Système de traitement d'information utilisant un ensemble de cartes à mémoire.
FR2703800B1 (fr) * 1993-04-06 1995-05-24 Bull Cp8 Procédé de signature d'un fichier informatique, et dispositif pour la mise en Óoeuvre.
JPH0756781A (ja) * 1993-08-20 1995-03-03 Fujitsu Ltd ファイル管理方式
JPH0778098A (ja) * 1993-09-08 1995-03-20 Fujitsu Ltd ファイル管理システム
ATE152539T1 (de) * 1994-02-08 1997-05-15 Belle Gate Invest Bv Datenauswechselsystem mit tragbaren datenverarbeitungseinheiten
JPH07262214A (ja) * 1994-03-18 1995-10-13 Hitachi Ltd リンク情報管理方法
JP2912840B2 (ja) * 1994-12-07 1999-06-28 富士通株式会社 ファイル管理システム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9900774A1 *

Also Published As

Publication number Publication date
CA2264896A1 (fr) 1999-01-07
FR2765362B1 (fr) 2001-08-17
FR2765362A1 (fr) 1998-12-31
WO1999000774A9 (fr) 2007-07-26
TW434504B (en) 2001-05-16
NO990893L (no) 1999-03-17
KR20000068374A (ko) 2000-11-25
AU8343998A (en) 1999-01-19
CN1231042A (zh) 1999-10-06
BR9806014A (pt) 1999-10-13
NO990893D0 (no) 1999-02-25
WO1999000774A1 (fr) 1999-01-07
JP2000503157A (ja) 2000-03-14
AR016092A1 (es) 2001-06-20

Similar Documents

Publication Publication Date Title
EP0507669B1 (fr) Procédé de paiement électronique par carte à puce à l&#39;aide de jetons numérotés et carte pour sa mise en oeuvre
EP0089876B1 (fr) Procédé et dispositif de protection d&#39;un logiciel livré par un fournisseur à un utilisateur
EP0423035B1 (fr) Système de paiement ou de transfert d&#39;informations par carte à mémoire électronique porte-monnaie
EP0349413B1 (fr) Système de gestion de supports d&#39;informations portatifs
EP0114773B1 (fr) Procédé et dispositif pour habiliter le détenteur d&#39;un objet portatif tel qu&#39;une carte à accéder par cette carte à au moins un service dispensé par au moins un organisme habilitant
EP0744063B1 (fr) Procede de transaction par carte a puce
EP0552079B2 (fr) Carte à mémoire de masse pour microordinateur
FR2673476A1 (fr) Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur.
FR2777673A1 (fr) Dispositif de traitement de l&#39;information comprenant des moyens pour gerer une memoire virtuelle, et procede de stockage d&#39;informations associe
FR2681165A1 (fr) Procede de transmission d&#39;information confidentielle entre deux cartes a puces.
WO2001084512A1 (fr) Carte a puce multi-applicatives
WO1999000774A1 (fr) Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires
EP1388134A1 (fr) Procede et systeme de gestion de donnes destinees a etre stockees dans une carte a puce programmable
EP2912640B1 (fr) Procédé de gestion d&#39;identifiants dans une carte a circuit integré et carte a circuit integré correspondante
FR2638002A1 (fr) Procede de personnalisation pour cartes a microcalculateur et systeme pour sa mise en oeuvre
FR2806813A1 (fr) Systeme de gestion de memoire pour cartes a puce permettant a un utilisateur d&#39;avoir acces a certaines prestations dans le cadre notamment d&#39;une gestion informatisee des services de la ville
WO1997031343A1 (fr) Carte de gestion de comptes multiples et procede de mise en ×uvre
EP2304559B1 (fr) Procédé de basculement entre deux versions d&#39;une même application au sein d&#39;un dispositif de traitement de l&#39;information et ledit dispositif
FR2656126A1 (fr) Procede de generation d&#39;un nombre aleatoire dans un systeme a objets portatifs electroniques, et systeme pour la mise en óoeuvre du procede.
FR2789774A1 (fr) Procede de comparaison securise de deux registres memoire, et module de securite mettant en oeuvre ce procede
FR2833093A1 (fr) Procede d&#39;echange de blocs de donnees, procede d&#39;echange et de traitement de blocs de donnees, objet portatif, et automate pour la mise en oeuvre de procede
FR2770071A1 (fr) Systeme d&#39;identification de personnes
FR2795583A1 (fr) Module de securite
FR2632101A1 (fr) Systeme de transaction du type porte-monnaie electronique
EP1170921A1 (fr) Module de sécurité

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19990707

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): BE CH CY DE DK ES FI FR GB IE IT LI LU NL PT SE

17Q First examination report despatched

Effective date: 20010517

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20011128