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)

Applications Claiming Priority (3)

Publications (1)

Family

ID=9508465

Family Applications (1)

Country Status (12)

Families Citing this family (5)

Family Cites Families (11)

• 1997
  • 1997-06-26 FR FR9707996A patent/FR2765362B1/fr not_active Expired - Fee Related
• 1998
  • 1998-06-19 TW TW087109858A patent/TW434504B/zh not_active IP Right Cessation
  • 1998-06-25 CN CN98800895A patent/CN1231042A/zh active Pending
  • 1998-06-25 AR ARP980103062A patent/AR016092A1/es unknown
  • 1998-06-25 CA CA002264896A patent/CA2264896A1/fr not_active Abandoned
  • 1998-06-25 BR BR9806014-7A patent/BR9806014A/pt not_active IP Right Cessation
  • 1998-06-25 KR KR1019997001615A patent/KR20000068374A/ko not_active Application Discontinuation
  • 1998-06-25 WO PCT/FR1998/001344 patent/WO1999000774A1/fr not_active Application Discontinuation
  • 1998-06-25 AU AU83439/98A patent/AU8343998A/en not_active Abandoned
  • 1998-06-25 EP EP98933716A patent/EP0944880A1/fr not_active Withdrawn
  • 1998-06-25 JP JP11505329A patent/JP2000503157A/ja active Pending
• 1999
  • 1999-02-25 NO NO990893A patent/NO990893L/no not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events