[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO1999000774A9 - 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
WO1999000774A9
WO1999000774A9 PCT/FR1998/001344 FR9801344W WO9900774A9 WO 1999000774 A9 WO1999000774 A9 WO 1999000774A9 FR 9801344 W FR9801344 W FR 9801344W WO 9900774 A9 WO9900774 A9 WO 9900774A9
Authority
WO
WIPO (PCT)
Prior art keywords
file
link
files
target
security module
Prior art date
Application number
PCT/FR1998/001344
Other languages
English (en)
Other versions
WO1999000774A1 (fr
Inventor
Jerome Ajdenbaum
Patrice Hameau
Anne-France Presa
Original Assignee
Bull Cp8
Jerome Ajdenbaum
Patrice Hameau
Anne-France Presa
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, Jerome Ajdenbaum, Patrice Hameau, Anne-France Presa filed Critical Bull Cp8
Priority to JP11505329A priority Critical patent/JP2000503157A/ja
Priority to AU83439/98A priority patent/AU8343998A/en
Priority to EP98933716A priority patent/EP0944880A1/fr
Priority to BR9806014-7A priority patent/BR9806014A/pt
Priority to CA002264896A priority patent/CA2264896A1/fr
Publication of WO1999000774A1 publication Critical patent/WO1999000774A1/fr
Priority to NO990893A priority patent/NO990893L/no
Publication of WO1999000774A9 publication Critical patent/WO1999000774A9/fr

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 a plurality of files.
  • the term "security module” must be taken, either in its conventional sense, in which it designates a device intended, in a communication or information network, to be held by a body supervising the network and to store in a protected manner. secret and fundamental parameters of the network such as cryptographic keys, or as more simply designating a device allocated to various users of the network and allowing each of them to have access to it, the latter device being also likely 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 equipped with integrated circuits comprising at least one microprocessor, a read-only memory (ROM) containing a card operating system and one or more non-volatile memories. programmable by the microprocessor. These non-volatile memories are used to store data and code.
  • the microprocessor controls the transfer of information and, where appropriate, stores the data received from the outside or reads them for transmission 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 usually developed during the personalization of the card, that is to say before use. It is possible, however, to add other directories or other data files in use, but this depends on the available space remaining in the programmable non-volatile memory. Since this memory is limited in size, it is important not to waste any space and to define during customization only the necessary and sufficient place for the proper functioning of directories and data files.
  • the structure in several levels can penalize the access times to data files or directories of low levels. Indeed, for to reach data from a directory of a lower level, it is necessary in many cases to select all top-level main directories. For example, to go from one directory to another of the same level, you have to go up a tree to a first common directory and then go back down, this by selecting intermediate directories. This successive selection mechanism is cumbersome and time-consuming.
  • the present invention aims to solve these various problems: it provides a way to avoid the duplication in memory of identical data; it ensures the coherence of information shared between several files; finally, it optimizes the search for information in remote directories, in the tree of the files of the memory.
  • link creation 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 by means of location data, the link creation means associating the auxiliary file with said location data;
  • connecting means arranged to provide processing means, when they execute an access request to access the auxiliary file, said content of the main file using said location data.
  • Figure 1 shows a tree 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 a diagram of a security module for which the invention is intended, cooperating with an information processing device.
  • the information processing device 51 shown in FIG. 5 comprises, in a manner known per se, a microprocessor 52 to which a ROM 53, and a RAM 54, are connected, 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 may also be equipped with storage means such as floppies or removable disks or not, input means (such as a keyboard and / or a pointing device of the mouse type) and display means, these various means are not shown in FIG. 5.
  • the information processing device may be constituted by any computer apparatus installed on a private or public site and capable of providing information management or delivery means. of various goods or services, this device being permanently installed or portable, it may 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 area 61 in which information once recorded, are inaccessible from outside the module but only accessible to the processing means 59, and a free area 62 which is accessible from the outside of the module for reading and / or writing information.
  • Each zone of the non-volatile memory 60 may comprise a non-modifiable portion ROM and an modifiable portion EPROM, EEPROM, or constituted by RAM of the "flash" type, that is to say having the characteristics of an EEPROM with in addition, access times identical to those of a conventional RAM.
  • non-volatile memory self-programmable As a security module 58, it will be possible to use a microprocessor with non-volatile memory self-programmable, as described in US Patent No. 4,382,279 in the name of the Applicant. As indicated in Column 1, lines 13-25 of this patent, the self-programmable nature 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 in a program gj. Although the means to implement this self-programming may 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 processor. nonvolatile memory and according to the aforementioned patent, these means may include:
  • 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 able to perform calculations, including authentication and signing, through the wired electronics, not microprogrammed. They can in particular be of ASIC type (of the English "Application Specifies Integrated Circuit").
  • ASIC Application Specifies Integrated Circuit
  • the security module 58 will be designed in monolithic form on a single chip.
  • the security character of the security module may result from its location in a tamperproof enclosure.
  • the non-volatile memory of the cards is organized into files which can be, as recalled above, of two types: directory or elementary file of data.
  • Each elementary file includes a header and a body containing information.
  • the level of hierarchy is specified in the header, there are also the references of the file, the state or phase of life of the map, the access conditions and the size
  • the header contains all the information that makes it possible to manage the information stored in the body
  • Two or three levels are currently used With reference to FIG. and in general, the higher level is called “CARD”, and the lower levels "APPLICATION” or "SERVICE”
  • the same card can be used for various applications such as the bank, the municipality, the medical file, the cellular radiotelephone, which are represented by level directories APPLICATION
  • applications such as the bank, the municipality, the medical file, the cellular radiotelephone, which are represented by level directories APPLICATION
  • level directories APPLICATION
  • parts such as public transport, access to the pool and library, payment for parking, which are represented by SERVICE level directories,
  • Figure 2 illustrates an example of the hierarchical links between files in the programmable memory of a card
  • the CARD directory contains two directories APPLICATION 1 and 2 and the elementary file C1
  • the directory APPLICATION 1 contains two directories SERVICE A1-S1 and A1-S2 A1-1
  • the SERVICE A1-S2 directory has a single elementary data file A1S1-1
  • the APPLICATION 2 directory has two directories SERVICE A2-S1 and A2-S2
  • the directory SERVICE A2-S1 has two elementary files of data A2S1-1 and A2S1-2
  • the SERVICE A2-S2 directory has a basic A2S2-1 data file.
  • 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, credit information etc. can be stored in a basic file, included in the directory. corresponding to the banking application, for example the elementary file A1-1 in the directory APPLICATION 1, described in Figure 2
  • the map can also serve as a city map, this application is managed by the directory APPLICATION 2 It allows to pay for public transportation, access to the municipal library and some cultural activities paying (theater, cinema ). These services are managed by the two directories SERVICE A2-S1 and A2-S2, hierarchically dependent on the directory APPLICATION 2.
  • the card serves as means of payment, to pay for example the journeys made in the public transport, the money is debited directly to the bank account whose coordinates are specified in the basic file A1-1. It is therefore necessary to make accessible from the directory SERVICE A2-S1 of the directory APPLICATION 2, the information elementary file A1 -1 APPLICATION 1. This access is symbolized by the arrow in Figure 2.
  • the solution consisting in reproducing data n ' is not satisfactory.
  • Another example concerns secret keys and confidential codes: their values can be identical when accessing different directories that are not hierarchically dependent. The problem is important if RSA type keys (inventors Rivest, Shamir and Adleman) stored on more than 1024 bits are used.
  • a final example concerns basic ratification files: these basic files are used to memorize good or bad key or code presentations. Consolidation of several basic ratification files for different keys saves space and increases security.
  • One way to achieve the invention is to create and manage so-called "Link" files whose body is confused 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 specifying, either in the header of the file, or in its body, the address where the data are actually located.
  • two files are represented, namely a target file 30 and a link file 31.
  • the description that follows concerns both the case where these files are data files and the one where they represent directories. These directories contain either a tree of subdirectories giving access to data files, data files that are directly attached to them, or both.
  • the term "data” includes both non-executable data and executable or program data.
  • the target file 30 is organized, in this example, into two parts comprising a header 32 and a body 33.
  • the header 32 includes a first group of parameters known per se, 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; and access conditions that give a list of access rights to this determined file, for any user: they specify for example whether the file is accessible or not read or write; in a manner known per se, the delivery of these rights may be subject to the presentation of keys or passwords.
  • the header 32 includes a second group of parameters that are specific to the invention, 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 ⁇ 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;
  • a parameter A-Link 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-Link parameter which defines the conditions of creation that the user will have to respect when he wants to create a link between this file and a file-link: they will be able for example to define keys or passwords to present by the user.
  • the header 32 finally includes a reference RC indicating to the microprocessor of the card a binary value of a memory address RC from which is stored the body 33 mentioned above.
  • the body 33 is stored in memory immediately after the header 32, so that the mention of the reference RC is not necessary.
  • the body 33 contains either a tree of sub-directories giving access to files data, either data files that are 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 may be different from that in two parts (header and body) shown in FIG. 3.
  • the parameters of the header 32 may be divided into specific places 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 that differs in the following way:
  • 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 reference RFC is preferably "physical” and consists of a binary value of a memory address from which the above-mentioned target file 32 is stored, or alternatively "Logical" and consisting of a path specifying the identifiers of one or more directories from which the target file 32 is accessible.
  • the microprocessor In the very particular case of a dynamic management of the memory of the card, it can be reorganized by the microprocessor to optimize the memory occupancy.
  • the location of the files can therefore fluctuate, as well as their location addresses.
  • only 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, whose body will thus be made available to the link-file.
  • 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 the following :
  • the parameter CA-Link would advantageously be used in the header of the first link-file to control the conditions of creation of the second link-file.
  • a microprocessor program In operation, during the selection of a file by the user, a microprocessor program reads its header and tests its ⁇ Link> parameter. If it is equal to 0, the operation is in accordance with the prior art: the body is directly attached to this header.
  • the file is a link-file.
  • the program reads accordingly 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.
  • the program carries out the following checks, by consulting the respective headers of the link-file and the target-file:
  • the program continues its procedure of access to the contents of the file-link. If the body size of the target file is "zero byte", that is, if it does not contain anything, the program aborts and the card returns an error message. Otherwise, the program searches the information contained in this body, from the address RC.
  • the program searches the information contained in this body, from the address RC.
  • the file A1-1 in the application directory 1 was created as a target file, and that the files A2S1-1, A2S1-2, A2S2-1 service directories A2-S1 and A2-S2 have been created as link-files. As a result, selecting a link-file such as A2S1-1 will give access to the contents of 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 so access to the information in the target-file via the link-file is granted only if the conditions of the target-file are respected
  • Another strategy is to take into account the access conditions of the target-file during the creation of the link-file. It must then be verified that the access conditions entered in the header of the link-file include all the conditions. access of the target file to which he is going to be heir
  • a third strategy is applicable when the conditions of access are expressed in the form of a binary value it consists in cumulating the two conditions of access Concretely, this operation can be realized by performing a logical AND between the two values L ' access to information in the target-file via the link-file is granted only if both the access conditions of the Target and link files are respected.
  • the reader understands that the objective, at the level of access control, is to prohibit any possibility of circumventing the access conditions of a file by linking it to a file that has conditions of access. More favorable access Other strategies, known to those skilled in the art, may be used to ensure access security
  • An important security enhancement is to use the A-Link parameter of a target-file to prevent it from being inherited from another file. If the value of this parameter is "1", when creating a link-file attached to this target-file, the operation is carried out and the content of the body of the target-file is accessible by the link-file If, however, the value of this field is "0", this file- target can not be linked to any other When an attempt is made to create a link-file designating a file whose A-Link field is equal to "0", the operation is refused and the card returns an error message
  • the solution consists in either prohibiting the deletion of the target file to which one or more Link files are attached, or warning the user of the card that some files are no longer operational after this deletion.
  • a first method is to test the value> Link ⁇ . If this value is 1, the file being erased is a Target file. The operation is then either prohibited or carried out but with a warning; in the latter case, the control terminal of the card must erase all the linked files linked to the deleted target file.
  • the counter is incremented.
  • the counter is decremented.
  • the value of the counter can be emitted with the other header information: the user can thus know the number of link files attached to the selected target file.
  • the program of the card is equipped with a command, activatable from outside the card, to exchange the respective statuses "link" and "target” two files.
  • a file-Target become a file-Link can be deleted without consequence for the other files-Link.
  • the content of the new target file is then constituted by that of the old target file. This is especially easy when the file bodies are physically separate 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 method of creating a file, whether it is a file-link 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, along with 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 operating system of the card verifies 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 hold the new file (step 3). If one of these tests is negative, the creation order is interrupted (step 13), and the card then returns 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).
  • An important difference between a normal file and a link-file, and on which the test can be carried out resides in the creation data, and mainly in the precise indication of the location of the Target-file (physical or logical address). If it is not a link file, the program jumps directly to step 12 described below.
  • the information corresponding to the designated target file is searched for and analyzed in step 5; then the operating system performs a number of tests to ensure that the link between the designated target file and the link file to be created is possible. First, it is verified using the creation data that the target file exists (step 6).
  • 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 can not be linked to any other file.
  • the creation operation is then interrupted and the card sends an error message.
  • step 8 the operating system tests whether any keys defined in the conditions for creating the link file, that is to say defined by the CA-Link parameter of the Target-file, were previously presented. If this is not the case, the creation operation is interrupted.
  • step 9 the operating system of the card verifies that the file types eWes access conditions 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 to link a data file and a directory, or a link between a "public" type data file and a data file of type "secret", then the creation operation is interrupted and the card sends an error message. This test is optional because another solution consists in forcing the received data for the link file to be created, to the same value as those of the designated Target file: the compatibility is in this case certain.
  • a last test carried out concerns the conditions of access to the information contained in the Target file (etapelO). It is necessary to avoid circumventing the conditions of access of the Target-file by a file-Link which would have more favorable conditions of access.
  • One of the strategies described previously is to prohibit the creation of a file-Link having access conditions less restrictive than those of the file-Target: the creation operation is then interrupted and the card sends an error message (step 13).
  • Another strategy consists of modifying, and thus modifying, the access conditions of the link file to make them at least as restrictive as those of the target-file. In this case, the test of step 10 becomes a calculation operation with modification, if necessary, access conditions transmitted in the command. Once the test steps are completed, the creation of the link file can take place.
  • step 11 the header of the target file is updated. This mainly concerns the parameter> Link ⁇ or Cp-Link. If this is the> Link ⁇ parameter, the program checks whether it has the value at "1", or else sets it to this value. If it is instead the counter Cp-Link, it is incremented by one unit.
  • step 12 a new file is actually created, and the values of the header parameters of this file are determined in working memory from the creation data. These values are written in nonvolatile programmable memory. If it is a link-file that is created, a reference related to the location of the target-file (physical or logical address) is written. Once all these steps are completed, the card renders a correct status message and the newly created file is operational.
  • a particularly interesting application of the invention and relating to directories-link is that where an electronic wallet directory is used by the card to allow payments.
  • This directory contains basic files containing keys, credit debit zones, password validation zones, etc.
  • Such a directory can be used in various applications (transport, restaurant, central purchasing): each they must therefore contain a directory-link linked to the electronic wallet directory, which then becomes a target-directory.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (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 jqu'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 A1S1-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'inventiorη à 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 II 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 hé
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 hé à 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 eWes conditions d'accès aux informations sont compatibles. Pour cela, 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 nouvellement 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
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é.
PCT/FR1998/001344 1997-06-26 1998-06-25 Module de securite comportant des moyens de creation de liens entre des fichiers principaux et des fichiers auxiliaires WO1999000774A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP11505329A JP2000503157A (ja) 1997-06-26 1998-06-25 メインファイルと補助ファイルとの間にリンク生成手段を備えたセキュリティモジュール
AU83439/98A AU8343998A (en) 1997-06-26 1998-06-25 Security module comprising means generating links between main files and auxi liary files
EP98933716A 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
BR9806014-7A BR9806014A (pt) 1997-06-26 1998-06-25 Módulo de segurança compreendendo meios de criação de ligações entre arquivos principais e arquivos auxiliares.
CA002264896A CA2264896A1 (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
NO990893A NO990893L (no) 1997-06-26 1999-02-25 Sikkerhetsmodul omfattende midler for generering av lenker mellom filer og hjelpefiler

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR97/07996 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

Publications (2)

Publication Number Publication Date
WO1999000774A1 WO1999000774A1 (fr) 1999-01-07
WO1999000774A9 true WO1999000774A9 (fr) 2007-07-26

Family

ID=9508465

Family Applications (1)

Application Number Title Priority Date Filing Date
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

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 グローリー株式会社 データ記憶装置およびデータ記憶方法
WO2005121976A1 (fr) * 2004-06-14 2005-12-22 Sony Corporation Dispositif de gestion d’informations et procede de gestion d’informations
JP5124733B2 (ja) * 2006-04-25 2013-01-23 キヤノンＩｔソリューションズ株式会社 サーバ装置および情報共有システムおよびプログラムおよび記録媒体
CN102306170A (zh) * 2011-08-23 2012-01-04 北京握奇数据系统有限公司 一种存储及处理智能卡公共信息的方法及装置
JP6947166B2 (ja) * 2016-03-23 2021-10-13 ソニーグループ株式会社 情報処理装置及び情報処理方法

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 情報記録システム
EP0332117B1 (fr) * 1988-03-09 1994-05-11 Kabushiki Kaisha Toshiba Appareil électronique portatif
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 ファイル管理システム
DE69402955T2 (de) * 1994-02-08 1997-08-14 Belle Gate Investment B.V., Den Haag Datenauswechselsystem mit tragbaren Datenverarbeitungseinheiten
JPH07262214A (ja) * 1994-03-18 1995-10-13 Hitachi Ltd リンク情報管理方法
JP2912840B2 (ja) * 1994-12-07 1999-06-28 富士通株式会社 ファイル管理システム

Also Published As

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

Similar Documents

Publication Publication Date Title
EP0423035B1 (fr) Système de paiement ou de transfert d&#39;informations par carte à mémoire électronique porte-monnaie
EP0018889B1 (fr) Procédé pour prolonger la validité d&#39;une zone de travail de la mémoire d&#39;un support d&#39;enregistrement
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
EP0990204B1 (fr) Carte a puce comprenant des moyens pour gerer une memoire virtuelle, procede et protocole de communication associes
EP0552079B2 (fr) Carte à mémoire de masse pour microordinateur
FR2681165A1 (fr) Procede de transmission d&#39;information confidentielle entre deux cartes a puces.
FR2673476A1 (fr) Procede securise de chargement de plusieurs applications dans une carte a memoire a microprocesseur.
FR2716021A1 (fr) Procédé et système de transaction par carte à puce.
EP0565389A1 (fr) Procédé de personnalisation d&#39;une carte à puce
EP0552077B1 (fr) Carte à mémoire de masse pour microordinateur avec facilités d&#39;exécution de programmes internes
WO2001084512A1 (fr) Carte a puce multi-applicatives
FR2817055A1 (fr) Execution d&#39;une application dans un objet electronique portable a faible capacite de memoire
WO1999000774A9 (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
EP0838053B1 (fr) Procede et dispositif permettant a un programme fige de pouvoir evoluer
EP2912640B1 (fr) Procédé de gestion d&#39;identifiants dans une carte a circuit integré et carte a circuit integré correspondante
CA2046320C (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
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
EP0910839B1 (fr) Procede de stockage des unites de valeur dans une carte a puce de facon securisee et systeme de transaction monetaire avec de telles cartes
EP1129430B2 (fr) Procede et dispositif de controle du cycle de vie d&#39;un objet portatif, notamment d&#39;une carte a puce
FR2789774A1 (fr) Procede de comparaison securise de deux registres memoire, et module de securite mettant en oeuvre ce procede
FR2933214A1 (fr) Procede de basculement entre deux versions d&#39;une meme application au sein d&#39;un dispositif de traitement de l&#39;information et ledit dispositif
EP0609156A1 (fr) Système détecteur de falsification d&#39;informations mémorisées
FR2795583A1 (fr) Module de securite

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 98800895.5

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA CN JP KR NO SG US

AL Designated countries for regional patents

Kind code of ref document: A1

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

WWE Wipo information: entry into national phase

Ref document number: 1998933716

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 1999 505329

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2264896

Country of ref document: CA

Ref document number: 2264896

Country of ref document: CA

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 1019997001615

Country of ref document: KR

Ref document number: 09242976

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 83439/98

Country of ref document: AU

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1998933716

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1019997001615

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1998933716

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1019997001615

Country of ref document: KR