JP2006092568A - Ic card and file management method for ic card - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an IC card and a file management method for IC card excellent in security, in which the effect of a transport key can be exhibited only when a subordinate person changes a transport key after he/she received the key from a superordinate person. <P>SOLUTION: The file management method for dividing a data memory in the IC card to a plurality of files and managing the plurality of divided files with key collation as a condition of access, respectively, comprises determining whether the key is changed or not, and determining that the key collation does not satisfy the condition of access in a case that no change of the key is determined, and the key collation satisfies the condition of access in a case that a change of the key is determined. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention manages, for example, a non-volatile memory and an IC card including an IC chip having a control element such as a CPU for controlling them, and a plurality of files set and divided in the memory in this IC card. The present invention relates to a file management method in an IC card.

  Recently, as portable data storage media, attention has been focused on an IC card incorporating an IC chip having a nonvolatile data memory and a control element such as a CPU (Central Processing Unit) for controlling the nonvolatile data memory.

This type of IC card divides the built-in data memory into a plurality of files, and each file stores data necessary for the operation of the application to be used. By entering an identification name or the like, a state where only the corresponding file can be selectively used is realized. For this reason, a plurality of application data is divided into files and stored in one IC card, thereby enabling multipurpose use.
A plurality of data files for storing data such as transaction data and a key file for storing key data can belong to these application files.

  In recent IC cards, information called access conditions is added to each file, and command access is performed on the condition that the key in the card indicated by this information is collated. Whether or not is possible is determined.

  By the way, in the process where such an IC card extends from the manufacturer to the card user, various processes such as card issuance processing / system basic information storage in the card are assumed. At this time, it is assumed that the parties involved in each process are also different.

  For example, the former is a card issuer (superior) and the latter is an application provider (subordinate). When the card issuer transfers the card access authority to the application provider, a temporary key generally referred to as a “transport key” is set in the IC card, and the application provider collates the temporary key. The application provider can access the IC card.

  At this time, since the card issuer also knows the transport key, in order to make the application provider know only the key only to itself, in general, by verifying this transport key, This is rewritten.

In addition, when the IPIN input by the cardholder matches the IPIN written in the card manufacturing process, a technique for writing the PIN and erasing the IPIN is known (see, for example, Patent Document 1).
That is, in this known technique, when the key collation matches, the next key (lower-order key) is written, and then the matched key (higher-order key) is deleted.
JP-A-62-44869

  However, as a problem of the above-described prior art, it affects the solution of problems such as when the data in the IC card is falsified. For example, considering that the expiration date for using an application in an IC card is generally changed by checking the key of the application provider, if this data is tampered with, Responsibility will be questioned.

  However, if the application provider uses the transport key without changing the above-described transport key, the card issuer can perform the same processing as the application provider. In other words, the card issuer is also suspected at the same time even though it is caused by the carelessness of the application provider.

Therefore, the result is contrary to the “delegation of management authority to the IC card” which is the original intention of applying the transport key.
However, obliging to rewrite the transport key and checking it uniquely in the IC card is not suitable for an application that requires only the convenience of the IC card.

  Further, in the conventional known technique, when the key collation is matched, the next key is written and then the matched key is deleted. Therefore, after the transport key is passed from the superior to the subordinate, Unless it changes the key, it cannot be disabled.

  Therefore, the present invention can prevent the effect from being exerted unless the lower party changes the key after passing the transport key from the upper party to the lower party. It is an object to provide a file management method in an IC card.

  In the IC card of the present invention, the initial key data is changed by comparing storage means for storing key data and data in a plurality of storage areas and the initial key data with the key data stored in the storage means. Determination means for determining whether or not the key data is not changed by the determination means, and blocking means for preventing the data from being processed in the plurality of storage areas. And a processing means for processing the data in the plurality of storage areas in response to a specific command when the determination means determines that the key data has been changed. File creation means for creating a file of the key data in each of the plurality of storage areas in response to a command of File creation by yl creation means characterized in that it is blocked by the blocking means before the key data is changed.

  The file management method in the IC card of the present invention is a file management method for managing access to a plurality of files in the memory in an IC card having at least a memory, and is a superordinate concept of a system using the memory Allows access to the file by collating a first key preset at the bottom of the file with a new key set by a subordinate concept of the system using the memory, wherein the superordinate concept is The first key is changed to a second key known only to the subordinate concept with reference to a key change access condition set in the first key, and the first key is changed to the second key. If it is changed to, the superordinate concept rejects the creation of a key below the file.

  The file management method in the IC card of the present invention is a file management method for managing access to a tree structure file including a higher-level concept file and a lower-level concept file in the memory in an IC card having at least a memory, An access condition is set for the upper concept file managed by the upper concept management program, an access condition is set for a file provided from the upper concept management program to the lower concept management program, and the lower concept is transferred from the higher concept management program. A transfer key to be transferred to the management program is set in the lower concept file with reference to the access condition of the lower concept file, and the transfer key is added to the lower concept file when the access condition of the upper concept file is satisfied. Set the subordinate concept file With reference to the access condition, and sets the file to the lower of the subgeneric file when the access condition is met.

  Further, the IC card of the present invention has at least a memory, and in the IC card including the tree structure file having the upper concept file and the lower concept file in the memory, the access condition is set and the upper concept management program The superordinate concept file to be used, the access condition is set, the subordinate concept file provided by the superordinate concept management program and used by the subordinate concept management program, and the access condition of the superordinate concept file is satisfied A first means for sometimes referring to the access condition of the higher level concept file and setting a transfer key to be transferred from the higher level concept management program to the lower level concept management program in the lower level concept file; Access the file With reference to the access condition of the subgeneric file when matter is satisfied, and a second means for setting the file to the lower of the lower concept file.

  According to the present invention, after the transport key is transferred from the superior to the inferior, it is possible to prevent the effect from being exhibited unless the inferior changes the key. A file management method in an IC card can be provided.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 shows a configuration example of a card handling device used as a terminal device such as a financial system or a shopping system, to which an IC card as a portable electronic device according to the present embodiment is applied. That is, this apparatus enables the IC card 1 to be connected to a control unit 3 comprising a CPU or the like via a card reader / writer 2, and the control unit 3 includes a keyboard 4, a CRT display device 5, a printer 6, and a floppy disk. A (registered trademark) disk device 7 is connected.

  FIG. 2 shows a configuration example of the IC card 1, and includes a control element (for example, CPU) 11 as a control unit, a non-volatile data memory 12 in which stored contents can be erased, a working memory 13, a program memory 14, The contact portion 15 is used to obtain electrical contact with the card reader / writer 2. Among these, the part (the control element 11, the data memory 12, the working memory 13, and the program memory 14) within the broken line is composed of one (or a plurality) of IC chips and is embedded in the IC card body.

  The data memory 12 is used for storing various data, and is composed of, for example, an EEPROM. The working memory 13 is a memory for temporarily storing processing data when the control element 11 performs processing, and is configured by a RAM or the like, for example. The program memory 14 is constituted by a mask ROM, for example, and stores a program of the control element 11 and the like.

  For example, as shown in FIG. 3, the data memory 12 is divided into a control area 120, a directory 121, a free area 122, and an area group 123. The area group 123 can have a plurality of data areas and key areas, and can be grouped by a concept called a data file (DF). Note that a master file (MF), which will be described later, is collectively managed as one form of data file.

The data file is a file for collectively managing data areas and key areas used in the corresponding application.
The data area is an area for storing data for reading and writing as necessary, such as transaction data.
The key area is, for example, an area used for storing a personal identification number, and is a target of writing / rewriting / collation, and cannot be read out.

  These areas are collectively assigned as an area group 123 as shown in FIG. These files or areas use the directory 121 in the data memory 12 so that the control element 11 recognizes their physical positions and the like.

Further, the control area 120 in FIG. 3 stores the top address information of the area group 123 and the top address information of the empty area 122.
As shown in FIG. 4, the directory 121 in FIG. 3 stores various definition information corresponding to each data file and area.

  FIG. 4A shows information defining the name of the data file. The definition information is given to the data PTN for identifying the data file name definition information in the directory 121, the file serial number DFSN assigned to the data file, the serial number PFSN of the parent file of the data file, and the data file. The file name DFname and data NL indicating its length, and data BCC for checking the validity of these data are configured.

FIG. 4B is information defining management information of the data file. This definition information includes data PTN for identifying data file name definition information in the directory 121, a file serial number DFSN assigned to this data file, a serial number PFSN of the parent file of this data file, a data file size DFS, this data AAID for identifying the data area in which the additional information of the file is stored, TYPE for specifying whether or not to output the additional information, UCF for prohibiting the key type, DFAC indicating the access condition of the data file, this It consists of DFST for holding the status of the data file, the data file located under the data file and the number of bytes US used by the area, and the data BCC for checking the validity of these data. The
In particular, the AAID outputs the contents of the data area shown in the AAID when necessary when a data file is selected by a data file selection command to be described later.

  FIG. 4C is information defining an area for storing various transaction data. This definition information includes data PTN for identifying the area definition information in the directory 121, a serial number DFSN of the data file to which the area belongs, an identification number AID for accessing the area, ATOP indicating the start address of the area, It consists of ASIZ indicating the area size, AAC indicating the access conditions of the area, AST holding the area status, and data BCC for checking the validity of these data.

  FIG. 4D shows information that defines areas for storing various key data. This definition information includes data PTN for identifying key area definition information in the directory 121, serial number DFSN of the data file to which this area belongs, identification number KID for accessing the area, and KTOP indicating the start address of the area. , KSIZ indicating area size, CF indicating key type, KAC indicating key access condition, KST holding key status, and data BCC for checking the validity of these data.

  The identification information PTN used for these is composed of, for example, 1 byte, and for the data file name definition (FIG. 4A), “00” is data file management information. "01" for those that define the data (Fig. 4 (b)), "02" for those that define the data area ((c) in the figure), and those that define the key area “03” is used for (FIG. 4D).

FIG. 5 shows an example of a file structure. In this figure, DFnn indicates a data file, Dnn indicates a data area, and Knn indicates a key area.
As shown in the figure, in the memory 12 in the IC card 1, data files DF1 and DF2 and key areas K00 and K01 and data areas D00 and D01 are set under the master file (MF). Yes.

  Further, data files DF1-1 and DF1-2, key areas K11 and K12, and data areas D11 and D12 are set under the data file DF1, respectively.

  Further, under the data file DF1-1, there are key areas K111 and K112 and data areas D111 / D112, and under the data file DF1-2, there are key areas K121 and K122 and data areas D121 and D122. Each is set.

  On the other hand, data files DF2-1 and DF2-2, key areas K21 and K22, and data areas D21 and D22 are set under the data file DF2.

  Further, under the data file DF2-1, key areas K211 and K212, data areas D211 and D212, and under the data file DF2-2, key areas K221 and K222, and data areas D221 and D222, Each is set.

  These various types of definition information are collectively stored in the directory 121 as shown in FIG. As shown in the figure, DFSN (file serial number) is automatically given to each definition information at the time of file creation. Based on the DFSN and the sequence number of the parent file stored in the data file definition information, the control element 11 recognizes the related state of each file.

  For example, in the definition information (serial number # 13) of the data file DF1-1, DFSN is “03” and PFSN is “01”. That is, this data file is given file sequence number '03' at the time of creation, and at the same time, recognizes that this data file is created under DF1, and assigns DFSN ('01') of data file DF1 as PFSN. To do.

  FIG. 7 shows a flow chart for explaining the operation for creating a data file (DF), which will be described below. When the IC card 1 receives a data file creation command input from the outside, it first recognizes a usable data file, that is, a data file in a current state (hereinafter referred to as a current DF) (ST1). In particular, immediately after the electrical activation to the IC card 1, the current DF becomes a master file (MF).

  When the current DF is recognized, next, information on file creation is referred to in the access condition information in the current DF definition information. This condition is compared only with the collation state holding area A on the RAM, which will be described later, and it is determined whether or not the collation state of the key requested by the access condition is established (ST2).

  If it has not been established, a response message indicating that the access conditions do not match is output, and the process returns to the command waiting state (ST3). If it is established, the file name (DF-ID) of the data file set in the command is extracted, and the parent FSN has the same value as the FSN of the current DF. Further, it is confirmed whether or not there is data file definition information having the same file name as the extracted file name (ST4).

  If it exists, a response message indicating an ID duplication abnormality is output, and the process returns to the command wait state (ST5). If the data file does not exist, the data file definition information shown in FIGS. 4A to 4C is generated from the data file creation data given by the command (ST6), and this is set in a predetermined area. Write (ST7).

  In this writing, when the writing is not normally completed (ST8), a response message indicating a data writing abnormality is output, and the process returns to the command waiting state (ST9). If the writing is normally completed (ST8), a response message indicating normal termination is output, and the process returns to the command waiting state (ST10).

  FIG. 8 shows a flowchart explaining the operation for creating a key elementary file (EF), which will be described below. When the IC card 1 receives a key EF creation command input from the outside, first, the current DF is recognized (ST11).

  When the current DF is recognized, next, information on file creation is referred to in the access condition information in the current DF definition information. This condition is compared only with the collation state holding area A on the RAM, which will be described later, and it is determined whether or not the collation state of the key requested by the access condition is established (ST12).

  If it has not been established, a response message indicating that the access conditions do not match is output, and the process returns to the command waiting state (ST13). If it is established, next, the elementary file name (EF-ID) specified in the command message is referred to, and the corresponding elementary file name is stored in the current DF to be accessed. It is checked whether or not it exists (ST14). If it exists, a response message indicating an ID duplication abnormality is output, and the process returns to the command wait state (ST15).

  If it does not exist, next, the size data of the key EF specified in the command message is referred to and compared with the free area size in the current DF to be accessed (ST16). In this comparison, it is checked whether or not the free area size is larger than the size of the specified key EF plus the size of the directory information used when the key EF is created. . If the former is larger than the latter, a response message indicating a specified size error is output and the process returns to the command wait state (ST17).

  If not, next, the type of key specified by the command message and the validity of the size are checked (ST18). At this time, if the key type is “authentication related key”, the size is, for example, 10 bytes, and if the key type is “collation key”, the size is, for example, 3 to 18 bytes. Is determined to be valid. If it is determined that it is not valid, a response message indicating a specified size matching error is output and the process returns to the command wait state (ST19).

  If it is determined that the size is valid, key EF definition information to be stored in the directory is generated based on the received command (ST20), and this is written in a predetermined area (ST21). At this time, the value of the eighth bit of the status information is determined depending on the first bit of the key type information specified in the command message. That is, a value similar to the latter bit value is set in the former bit.

  The eighth bit of the status information is a bit indicating whether or not the key data has been changed. When the bit is “1”, it indicates that no change has been made, and “0”. If there is, it indicates that the action was done.

  Therefore, when the first bit of the key type information is “1”, the eighth bit of the status information is not “0” unless the key is changed, and when the first bit is “0”. Regardless of whether or not the key is changed, the eighth bit of the status information is “0” (that is, it is equivalent to an implicit rewrite action).

  When writing the key EF definition information does not end normally (ST22), a response message indicating a data write error is output and the process returns to the command wait state (ST23). If the writing has been completed normally (ST22), a response message indicating normal termination is output and the process returns to the command waiting state (ST24).

  FIG. 9 shows a flow chart for explaining the operation for key data setting, which will be described below. When the IC card 1 receives a key data setting command input from the outside, first, the current DF is recognized (ST31).

  When the current DF is recognized, next, the elementary file name (EF-ID) specified in the command message is referred to, and whether the elementary file name exists in the current DF to be accessed. It is checked whether or not (ST32). If it does not exist, a response message signifying that there is no corresponding key ID is output, and the process returns to the command waiting state (ST33).

  If it exists, next, information on key data setting is referred to among the access condition information in the key EF definition information. This condition is compared only with the collation state holding area A on the RAM, which will be described later, and it is determined whether or not the collation state of the key requested by the access condition is established (ST34).

  If it has not been established, a response message indicating that the access conditions do not match is output, and the process returns to the command wait state (ST35). If it is established, next, it is confirmed whether or not key data exists in the corresponding key EF area (ST36). If it exists, response data indicating the presence of existing key data is output, and the process returns to the command wait state (ST37).

  If it does not exist, the validity of the key type specified in the command message and the size of the input key data is checked (ST38). At this time, if the key type is “authentication related key”, the size is, for example, 8 bytes, and if the key type is “verification key”, the size is, for example, 1 to 16 bytes. Is determined to be valid. If it is determined not to be valid, a response message indicating an abnormal input key data size is output, and the process returns to the command wait state (ST39).

  If it is determined that the size is valid, the size defined in the key EF definition information is compared with the size of the input key data (ST40). If the latter size plus “2”, for example, is larger than the former size, a response message indicating insufficient area size is output, and the process returns to the command waiting state (ST41).

  Otherwise, 1-byte length information and 1-byte BCC are added to the key data input by the received command, and this is stored in the key EF area (ST42). The response message is output to return to the command wait state (ST43).

  FIG. 10 shows a flow chart for explaining the operation for changing the key data, which will be described below. When the IC card 1 receives a key data change command input from the outside, first, the current DF is recognized (ST51).

  When the current DF is recognized, next, the elementary file name (EF-ID) specified in the command message is referred to, and whether the elementary file name exists in the current DF to be accessed. It is checked whether or not (ST52). If it does not exist, a response message signifying that there is no corresponding key ID is output, and the process returns to the command waiting state (ST53).

  If it exists, next, information on the key data change is referred to in the access condition information in the key EF definition information. This condition is compared with collation state holding areas A and B on the RAM, which will be described later, and it is determined whether or not the collation state of the key requested by the access condition is established (ST54).

  If it has not been established, a response message indicating that the access conditions do not match is output, and the process returns to the command wait state (ST55). If it is established, next, it is confirmed whether or not key data exists in the corresponding key EF area (ST56). If not, response data indicating no existing key data is output, and the process returns to the command wait state (ST57).

  If it exists, the validity of the key type specified in the command message and the size of the input key data is checked (ST58). At this time, if the key type is “authentication related key”, the size is, for example, 8 bytes, and if the key type is “verification key”, the size is, for example, 1 to 16 bytes. Is determined to be valid. If it is determined not to be valid, a response message indicating an abnormal input key data size is output, and the process returns to the command wait state (ST59).

  If it is determined that the size is valid, the size defined in the key EF definition information is compared with the size of the input key data (ST60). If the latter size plus “2”, for example, is larger than the former size, a response message indicating insufficient area size is output and the process returns to the command waiting state (ST61).

  Otherwise, 1-byte length information and 1-byte BCC are added to the key data input by the received command, and this is stored in the key EF area (ST62). Is output as a response message, and the process returns to the command wait state (ST63). At this time, the eighth bit of the status information in the key EF definition information is set to “0”.

  FIG. 11 shows a flow chart for explaining the operation for key collation, which will be described below. When the IC card 1 receives a key collation command input from the outside, it first recognizes the current DF (ST71).

  If the current DF is recognized, next, the directory 121 is searched to confirm whether or not the key EF definition information having the specified file name (ID) exists in the current DF (ST72). If it does not exist, a response message indicating no corresponding key ID is output, and the process returns to the command waiting state (ST73).

  If it exists, it is confirmed whether or not the key is locked (ST74). At this time, if it is determined that it is in the locked state, a response message indicating key lock is output, and the process returns to the command waiting state (ST75).

  If not, the key data in the command message is collated with the key data stored in the key EF (ST76). At this time, if they match (ST77), the collation bit designation information in the key EF definition information is referred to and the bit position designated by the information in the predetermined RAM area is “1”. (ST78). Next, the key-specific verification mismatch counter in the key EF definition information is cleared (ST79), a response message indicating normal termination is output, and the process returns to the command wait state (ST80).

  The predetermined RAM area is divided into collation state holding areas A and B. Which area the corresponding bit is set to “1” depends on the value of the eighth bit of the status information of the key in the key EF definition information. This bit indicates whether or not a change process has been performed on the key defined by the key EF definition information. As will be described later, the changed key is set to “0”. If it is “1”, it indicates that the key has not been changed. Further, when this is “0”, the corresponding bit of the collation state holding area A is set, and when it is “1”, the corresponding bit of the collation state holding area B is set.

  If it is determined that there is a mismatch in the key verification process (ST77), first, the verification bit designation information and the status information in the key EF definition information are referred to, and the same procedure as described above is performed. Predetermined bits in either the verification state holding area A or B are set to “0” (ST81).

  Next, the key-specific verification mismatch counter is incremented by one (ST82). At this time, if the count maximum value in the key EF definition information has not been reached (ST83), a response message indicating a mismatch of collation is output, and the process returns to the command wait state (ST84). If the maximum value has been reached, a response message indicating that the key has been locked is output, and the process returns to the command wait state (ST85).

  FIG. 12 shows a flow chart for explaining the operation for accessing the data EF, which will be described below. When the IC card 1 receives an externally input data EF access command, it first recognizes the current DF (ST91).

  When the current DF is recognized, next, the elementary file name (EF-ID) specified in the command message is referred to, and whether the elementary file name exists in the current DF to be accessed. It is checked whether or not (ST92). If it does not exist, a response message indicating that there is no corresponding key ID is output, and the process returns to the command wait state (ST93).

  If it exists, the access condition information corresponding to the access type (data read / write / change) is referred to among the access condition information in the data EF definition information. This condition is compared with a collation state holding area A on the RAM, which will be described later, and it is determined whether or not the collation state of the key requested by the access condition is established (ST94).

  If it has not been established, a response message indicating that the access conditions do not match is output, and the process returns to the command wait state (ST95). If it has been established, the corresponding data EF area is accessed (ST96), the processing result is output as a response message, and the command wait state is returned (ST97).

  According to this, for example, as an access condition for setting an application provider key (transport key), a key of an issuer that is a superior is required, and the change of the application provider transport key is It is assumed that the setting is made so that the key can be verified, and that the key verification of the application provider is required when executing another access command.

  In this case, the collation result of the application provider transport key before the change is stored in the collation state holding area B. Therefore, even if another access requires the verification of the application provider key, the verification result is not reflected in the verification status holding area A used for these accesses, and thus the effect of the key is exhibited. Can be realized.

Further, only in the case of the key change, since the comparison state holding areas A and B are referred to, the verification state established before the change can be referred to, so that the key change action is permitted.
In addition, since the collation state is reflected in the collation state holding area A by the collation of the key after the key change, the effect is exhibited with respect to the subsequent other accesses.

  Further, as in the present embodiment, since it is possible to set whether or not the change is made at this time by the type information of the key input when the key EF is created, it is possible to set each application provider individually. Upon request, a card issuer as a superior can selectively set various types.

  In the above embodiment, the key EF creation command processing is performed as the timing for setting the status information indicating whether or not the key has been changed in advance from the key type information. It may be performed during command processing.

  In the above-described embodiment, an IC card is exemplified as an electronic device that performs file management. However, the present invention is not limited to this, and any electronic device including a memory that requires file management is applicable.

The block diagram which shows the structural example of the card handling apparatus with which the IC card which concerns on embodiment of this invention is applied. The block diagram which shows the structural example of an IC card. The memory map figure which shows the structural example of a data memory. The figure which shows the format example of various definition information. The figure which shows the structural example of the file set in a data memory. The figure which shows the structural example of the directory set in a data memory. The flowchart explaining the operation | movement for data file creation. The flowchart explaining the operation | movement for key elementary file creation. The flowchart explaining the operation | movement for key data setting. The flowchart explaining the operation | movement for key data change. The flowchart explaining the operation | movement for key collation. The flowchart explaining the operation | movement for access to a data elementary file.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... IC card, 2 ... Card reader / writer, 3 ... Control part, 4 ... Keyboard, 5 ... CRT display device, 11 ... Control element, 12 ... Data memory, 13 ... Working memory, 14 ... Program memory, 15 ... Contact part, 120 ... Control area, 121 ... Directory, 123 ... Area group.

Claims (5)

Storage means for storing key data and data in a plurality of storage areas;
Determining means for determining whether the initial key data has been changed by comparing the initial key data with the key data stored in the storage means;
Blocking means for preventing data from being processed in the plurality of storage areas when it is determined by the determining means that the key data has not been changed;
Processing means for processing the data in the plurality of storage areas in response to a specific command when the determination means determines that the key data has been changed,
The processing means includes a file creation means for creating a file of the key data in each of the plurality of storage areas in response to a specific command, and the file creation by the file creation means changes the key data. An IC card previously blocked by the blocking means. In an IC card having at least a memory,
A file management method for managing access to a plurality of files in the memory,
Access to the file by collating a first key preset at a lower level of the file by a superordinate concept of the system using the memory with a new key set by a subordinate concept of the system using the memory Allow
The upper concept changes the first key to a second key known only to the lower concept with reference to a key change access condition set in the first key, and the first key A file management method in an IC card, wherein when the key is changed to the second key, the superordinate concept rejects creation of a key in the lower part of the file. In an IC card having at least a memory,
A file management method for managing access to a tree structure file including a higher-level concept file and a lower-level concept file in the memory,
Set access conditions for the upper concept file managed by the upper concept management program,
Set an access condition for a file provided from the upper concept management program to the lower concept management program,
A transfer key to be transferred from the higher-level concept management program to the lower-level concept management program is set in the lower-level concept file with reference to access conditions of the lower-level concept file;
When the access condition of the upper concept file is satisfied, the transport key is set in the lower concept file,
A file management method for an IC card, wherein the access condition of the lower-level concept file is referred to and a file is set under the lower-level concept file when the access condition is satisfied. In an IC card having at least a memory and including a tree structure file having a higher concept file and a lower concept file in the memory,
A superordinate concept file with access conditions set and used by the superordinate concept management program;
A subordinate concept file for which access conditions are set and which is provided by the superordinate concept management program and used by the subordinate concept management program;
When the access condition of the upper concept file is satisfied, the access condition of the upper concept file is referred to, and a transfer key transferred from the upper concept management program to the lower concept management program is transferred to the lower concept file. A first means for setting;
A second means for referring to the access condition of the lower-level concept file when the access condition of the lower-level concept file is satisfied, and for setting a file below the lower-level concept file;
An IC card comprising: A storage medium for creating a tree structure file having a higher-order concept file and a lower-order concept file, and storing a control program for information processing for managing access to each of the files by a control means,
The control program is
Create the upper concept file in which the access conditions are set by the upper concept management program,
Creating the lower-level concept file in which the lower-level concept file is provided by the higher-level concept management program and the access conditions are set so that it is used by the lower-level concept management program;
When the access condition of the upper concept file is satisfied, the access condition of the upper concept file is referred to, and a transfer key transferred from the upper concept management program to the lower concept management program is transferred to the lower concept file. Set,
A storage medium comprising: referring to the access condition of the lower level concept file when the access condition of the lower level concept file is satisfied, and setting a file below the lower level concept file.

Images