JPH09265433A - File managing method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a file management method capable of suppressing the display of the effect of a transport key until a slave person chanegs the key transferred from a master person to the slave person and having excellent security. SOLUTION: In this method, a file managment is executed by dividing the data memory of an IC card into plural files and managing the divided files by means of key collation as an access condition. In this case, whether the key is changed or not is judged, and at the time of judging no change of the key, the execution of key collation is turned to a state not satisfied as an access condition. At the time of judging the change of the key, key collation is turned to a state satisfied as an access condition.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to, for example, a nonvolatile memory and an IC card having an IC chip having a control element such as a CPU for controlling these, and a plurality of files divided and set in the memory. File management method for managing files.

[0002]

2. Description of the Related Art Recently, as a portable data storage medium, an IC card having a non-volatile data memory and an IC chip having a control element such as a CPU (Central Processing Unit) for controlling them has been noticed. Has been done.

In this type of IC card, the built-in data memory is divided into a plurality of files, and each file stores the data necessary for the application to be used during operation. By inputting an application identification name or the like from the device, a state in which only corresponding files can be selectively used is realized. Therefore, by dividing a plurality of application data into files and storing them in one IC card, multi-purpose use is possible.

These application files include
A plurality of data files for storing data such as transaction data and a key file for storing key data can be assigned.

In recent IC cards, information called an access condition is added to each file, and the key in the card indicated by this information must be verified. , Command access is determined.

[0006] By the way, in the process in which such an IC card extends from the manufacturer to the card user, various processes such as card issuing processing / storing system basic information in the card are assumed. At this time, the parties involved in each process may be different.

For example, the former is the card issuer (upper person)
And the latter is the application provider (subordinate). When the card issuer transfers the card access authority to the application provider, a temporary key generally called 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 for the application provider to know the key only to himself,
In general, this transport key is collated to rewrite it.

[0009]

However, as a problem of the above-mentioned prior art, it affects the solution of the problem when the data in the IC card is falsified. For example, considering that the expiration date of application use in the IC card is generally changed by checking the key of the application provider, if this data is tampered with, the application provider's key You will be held responsible.

However, when the application provider uses the above-mentioned transport key without changing it, the card issuer can perform the same processing as the application provider. That is, the card issuer is also suspected at the same time, although it is caused by the carelessness of the application provider.

Therefore, the result is contrary to "transfer of management authority to IC card" which is originally intended to apply the transport key. However, obligating the rewriting of the transport key and uniquely checking it in the IC card are not suitable for applications that require only the convenience of the IC card.

Therefore, the present invention is capable of preventing the effect of the transport key from being exerted unless the lower person changes the key after passing the transport key from the upper person to the lower person. The purpose is to provide a file management method.

[0013]

A file management method according to the present invention is a file management method in which a memory is divided into a plurality of files, and the plurality of divided files are respectively managed under key access conditions as access conditions. If it is determined that the key has not been changed, and if it is determined that the key has not been changed, it is determined that the key has been changed when the key is collated at this time and the condition for access is not satisfied. Then, at this time, when the key is collated, the condition is satisfied as an access condition.

In the file management method of the present invention, the key is changed in the file management method in which the memory is divided into a plurality of files and each of the divided plurality of files is managed with the key verification as an access condition. If it is determined that the key has not been changed by this determination, when the key is collated at this time, it is determined that the condition is not satisfied as an access condition other than the key change, and the key is changed. If it is determined, when the key is collated at this time, the condition for access is satisfied.

Further, in the file management method of the present invention, the memory is divided into a plurality of files, and the plurality of divided files are respectively managed in a key matching condition as an access condition. If it is determined that the key has not been changed by this determination, if the key is collated at this time, the condition for access is not satisfied, and if it is determined that the key has been changed, then When the key is checked, the condition for access is satisfied, or when the key is checked regardless of whether the key is changed, the condition for access is satisfied. It is characterized in that either of the states can be selected.

In the file management method of the present invention, the key is changed in the file management method in which the memory is divided into a plurality of files, and the plurality of divided files are respectively managed under the access conditions of collating keys. If it is determined that the key has not been changed by this determination, when the key is collated at this time, it is determined that the condition is not satisfied as an access condition other than the key change, and the key is changed. If it is judged, at this time, if the key is verified, the condition is satisfied as an access condition, or if the key is verified regardless of whether the key is changed or not, the access is confirmed. It is characterized in that it is possible to select either one of the conditions to be satisfied.

In the file management method of the present invention, the key is changed in the file management method in which the memory is divided into a plurality of files, and the plurality of divided files are respectively managed by the key matching as an access condition. If it is determined that the key has not been changed by this determination, if the key is collated at this time, the condition for access is not satisfied, and if it is determined that the key has been changed, then When the key is checked, the condition for access is satisfied, or when the key is checked regardless of whether the key is changed, the condition for access is satisfied. One of the states is selected, and attribute information for instructing this selection is set in the key. .

Further, in the file management method of the present invention, the memory is divided into a plurality of files, and the plurality of divided files are respectively managed by the key matching as an access condition. If it is determined that the key has not been changed by this determination, when the key is collated at this time, it is determined that the condition is not satisfied as an access condition other than the key change, and the key is changed. If it is judged, at this time, if the key is verified, the condition is satisfied as an access condition, or if the key is verified regardless of whether the key is changed or not, the access is confirmed. Select one of the conditions to be satisfied, and set the attribute information for instructing this selection in the key. It is characterized in.

Further, the file management method of the present invention comprises at least a memory, the memory is divided into a plurality of files, and data is stored for each of the plurality of divided files. Is a file management method for managing key verification as an access condition. It is determined whether or not the key has been changed, and if this judgment determines that the key has not been changed, then the key verification is performed at this time. If the key is changed when it is determined that the access condition is not satisfied and the key is changed at this time, the condition is satisfied when the key is collated at this time.

According to the present invention, it is determined whether or not the key has been changed, and when it is determined that the key has not been changed, when the key is collated, it is determined that the condition is not satisfied as an access condition and it is determined that the key has been changed. , When the key is verified, the condition is satisfied as an access condition, so that the effect is exhibited unless the lower person changes the key after passing the transport key from the upper person to the lower person. Whether or not this method is applied can be selectively set at the time of file registration.

[0021]

BEST MODE FOR CARRYING OUT THE INVENTION Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 shows an application of an IC card as a portable electronic device according to this embodiment.
For example, a configuration example of a card handling device used as a terminal device of a financial system or a shopping system is shown. That is, this device enables the IC card 1 to be connected to the control unit 3 including a CPU via the card reader / writer 2, and the control unit 3 includes a keyboard 4, a CRT display device 5, a printer 6, and the like.
Also, the floppy disk device 7 is connected.

FIG. 2 shows an example of the configuration of the IC card 1, in which a control element (for example, a CPU) as a control unit is shown.
11. Non-volatile data memory 1 whose stored contents can be erased
2, a working memory 13, a program memory 14, and a contact portion 15 for making electrical contact with the card reader / writer 2. Of these, the part within the broken line (control element 11, data memory 1
2. The working memory 13 and the program memory 14) are composed of one (or a plurality of) IC chips and are 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 holding processing data when the control element 11 performs processing, and is composed of, for example, a RAM. The program memory 14 is composed of, for example, a mask ROM, and stores the program of the control element 11 and the like.

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

The data file is a file for collectively managing a data area and a key area used by a 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 an area used for storing a personal identification number, for example, and is used for writing / rewriting / writing.
It is a target of collation and cannot be read. Note that these areas are collectively assigned as an area group 123, as shown in FIG. The control element 11 recognizes the physical position of each of these files or areas by using the directory 121 in the data memory 12.

Further, in the control area 120 of FIG. 3, the start address information of the area group 123 and the empty area 12 are set.
The top address information of 2 is stored. As shown in FIG. 4, the directory 121 of FIG. 3 stores various definition information corresponding to each data file and area.

FIG. 4A is information defining the name of the data file. This definition information is stored in the directory 12
1, the data PTN for identifying the data file name definition information, the file serial number DFSN assigned to this data file, the serial number PFSN of the parent file of this data file, the file name DFname given to this data file and its length Data NL indicating the
Data B for checking the validity of these data
It is composed of CC.

FIG. 4B shows information defining management information of the data file. The definition information includes data PTN for identifying data file name definition information in the directory 121, a file serial number DFSN assigned to the data file, a serial number PFSN of a parent file of the data file, a data file size DFS, and a data file. 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, and UC for inhibiting the type of key
F, DFAC indicating the access condition of the data file, DFST for holding the state of the data file, the number of bytes US used by the data file and area located under the data file, and the Data BCC for checking validity
Consists of

Further, particularly when the data file is selected by the data file selection command described later, the AAID outputs the contents of the data area indicated therein as necessary.

FIG. 4C is information defining an area for storing various transaction data and the like. The definition information includes data PTN for identifying the area definition information in the directory 121, the serial number DFSN of the data file to which the area belongs, the identification number AID for accessing the area, ATOP indicating the head address of the area, ASIZ indicating the area size, AAC indicating the access condition of the area, AST holding the state of the area, and data BCC for checking the validity of these data
Consists of

FIG. 4D is information defining an area for storing various key data. The definition information includes data PTN for identifying key area definition information in the directory 121, a serial number DFSN of a data file to which the area belongs, an identification number KID for accessing the area, and a KTOP indicating a head address of the area. , KSIZ indicating an area size, CF indicating a key type, KAC indicating a key access condition, and K holding a key state
ST and data BCC for checking the validity of these data.

Identification information PTN used for these
Is composed of, for example, 1 byte, and "00" is used for defining the name of the data file (FIG. 4A), while management information for the data file is defined (FIG. 4B )), '02' for the one defining the data area ((c) in the figure), and '02' for the one defining the key area ((d) in FIG. 4). '03' is used respectively.

FIG. 5 shows an example of the file structure.
In this figure, DFnn represents 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, under the master file (MF), the data files DF1 and DF2 and the key area K0.
0, K01 and data areas D00, D01 are respectively set.

Under the data file DF1,
The data files DF1-1 and DF1-2 have key areas K11 and K12 and data areas D11 and D12.
Are set respectively.

Under the data file DF1-1, there are key areas K111 and K112 and a data area D1.
11 / D112, and key areas K121 and K122 and data areas D121 and D122 are set under the data files DF1-2, respectively.

On the other hand, under the data file DF2,
The data files DF2-1 and DF2-2 also include key areas K21 and K22 and data areas D21 and D22.
Are set respectively.

Under the data file DF2-1, there are key areas K211, K212 and a data area D2.
11 and D212, and key areas K221 and K222 and data areas D221 and D222 are set under the data file DF2-2.

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 assigned to each definition information when a file is created. This D
The control element 11 recognizes the related state of each file based on the FSN and the sequence number of the parent file stored in the data file definition information.

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 a file sequence number '03' at the time of creation, and at the same time recognizes that this data file is created under the control of DF1, and gives DFSN ('01') of the data file DF1 as PFSN. I 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, first, it recognizes a usable state, that is, a data file in a current state (hereinafter, referred to as a current DF) (ST1). In particular, immediately after the electrical activation of the IC card 1, the current DF becomes a master file (MF).

When the current DF is recognized, next, the information regarding the file creation is referred to in the access condition information in the current DF definition information. This condition and R
Only the collation state holding area A on the AM is compared to determine whether the collation state of the key required by the access condition has been established (ST2).

If not 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 same value as the FSN of the current DF is included as the parent FSN. ,
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 waiting state (ST5). If it does not exist, data file definition information shown in FIGS. 4A to 4C is generated based on the data for data file creation given by the command (ST6), and this is stored in a predetermined area. Write (ST
7).

In this writing, if the writing is not normally completed (ST8), a response message indicating a data writing abnormality is output and the state returns to the command waiting state (ST9). When the writing is completed normally (ST
8), output a response message indicating normal termination, and return to the command waiting state (ST10).

FIG. 8 shows a key elementary file (E
F) A flow chart illustrating an operation for creation is shown, which will be described below. IC card 1
When a key EF creation command input from outside is received, first, the current DF is recognized (ST11).

When the current DF is recognized, next, the information regarding the file creation is referred to in the access condition information in the current DF definition information. This condition and R
Only the collation state holding area A on the AM is compared to determine whether the collation state of the key required by the access condition has been established (ST12).

If not 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 the elementary file name has been established, the elementary file name (EF-ID) specified by the command message is referred to, and the current elementary file name to be accessed is stored in the current DF. It is checked whether it exists (ST14). If there is, a response message indicating an ID duplication error is output, and the process returns to the command waiting state (ST15).

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

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

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

The eighth bit of this status information is a bit indicating whether or not the key data has been changed,
When the bit is "1", it indicates that the change action has not been performed, and when the bit is "0", it indicates that the action has been performed.

Therefore, when the first bit of the key type information is "1", the eighth bit of the status information does not become "0" unless the key is changed, and "0". In this case, the 8th bit of the status information is "0" regardless of whether or not the key is changed (that is, it is equivalent to the implicit rewriting action).

In writing the key EF definition information,
If the writing has not been completed normally (ST22), a response message indicating a data writing abnormality is output, and the process returns to the command waiting state (ST23). When the writing is completed normally (ST22), a response message indicating normal completion is output, and the process returns to the command waiting state (ST2).
4).

FIG. 9 shows a flow chart for explaining the operation for setting the key data, which will be described below. When the IC card 1 receives the 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 (E
F-ID), and it is checked whether or not the relevant elementary file name exists in the current DF to be accessed (ST32). If the key ID does not exist, a response message indicating that there is no corresponding key ID is output, and the process returns to the command waiting state (ST33).

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

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

If it does not exist, the type of the key designated by the command message and the correctness of the size of the input key data are checked (ST38). At this time, when the key type is “authentication related key”, the size is, for example, 8 bytes. When the key type is “verification key”, the size is, for example, 1 to 16 bytes. Is determined to be valid. If it is determined that the input key data size is not valid, a response message indicating an input key data size error is output and the process returns to the command waiting state (ST3).
9).

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

Otherwise, the key data input by the received command has 1-byte length information and 1
A byte BCC is added, this is stored in the key EF area (ST42), the processing result is output as a response message, and the state returns to the command waiting 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 (E
(F-ID), and it is checked whether or not the relevant elementary file name exists in the current DF to be accessed (ST52). 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 waiting state (ST53).

If it exists, then the access condition information in the key EF definition information is referred to, which is information about the key data change. 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 required by the access condition has been established (ST54).

If not established, a response message indicating that the access conditions do not match is output, and the process returns to the command waiting state (ST55). If the key data has been established, it is checked whether key data exists in the corresponding key EF area (ST56). If not, response data indicating that there is no existing key data is output, and the process returns to the command waiting 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, when the key type is “authentication related key”, the size is, for example, 8 bytes. When the key type is “verification key”, the size is, for example, 1 to 16 bytes. Is determined to be valid. If it is determined that the input key data size is not valid, a response message indicating an abnormal input key data size is output, and the process returns to the command waiting state (ST59).

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

Otherwise, the key data input by the received command has 1-byte length information and 1
A byte BCC is added, this is stored in the key EF area (ST62), the processing result is output as a response message, and the process returns to the command waiting 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 verification, 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).

When the current DF is recognized, the directory 121 is searched next to confirm whether or not the key EF definition information having the designated file name (ID) is present in the current DF (ST72). . If not, a response message indicating that there is 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 the key is locked, a response message indicating the key lock is output, and the process returns to the command waiting state (ST75).

If not, the key data in the command message is compared with the key data stored in the key EF (ST76). At this time, if they match (ST77), reference is made to the collation bit designation information in the key EF definition information, and the bit position designated by the information in the predetermined RAM area is set to "1". (ST78). Next, the key-specific collation mismatch counter in the key EF definition information is cleared (ST79), a response message indicating a normal end is output, and the process returns to the command waiting state (ST80).

The predetermined RAM area is divided into collation state holding areas A and B. Which area has the corresponding bit 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 described later, if the bit is “0”, the changed key is changed. 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 in the key matching process that they do not match (ST77), first, the key E
By referring to the collation bit designation information in the F definition information and the status information, the predetermined bit in either of the collation state holding areas A or B is set to "0" according to the same procedure as described above (ST81). .

Next, the collation mismatch counter unique to the key is set to 1
Only increment by one (ST82). At this time, if the count maximum value in the key EF definition information has not been reached (ST83), a response telegram indicating a collation mismatch is output, and the process returns to the command waiting state (ST84). Also,
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 waiting state (ST8).
5).

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 a data EF access command input from the outside, first,
The current DF is recognized (ST91).

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

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

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

According to this, for example, as the access condition for setting the application provider key (transport key), the key of the issuer who is the higher order is required, and the change of the application provider transport key is required. Is set so that it can be done by matching the key, and when executing other access commands,
It is assumed that the application provider key matching is set to be required.

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 needs to collate the application provider key, the collation result is not reflected in the collation state holding area A used for these accesses, and thus the effect of the key is exerted. Not what can be achieved.

Further, only in the case of the key change, since the collation state holding areas A and B are referred to, the collation state established before the change can be referred to, and accordingly, the key changing action is permitted.

Further, 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 exerted for other subsequent accesses. Further, as in the present embodiment, it is possible to set whether or not to make a pseudo change at this point by the type information of the key that is input when the key EF is created. The request allows the higher-ranking card issuer to selectively set various types.

In the above embodiment, the key E is set as the timing for setting the status information indicating whether the key has been changed in advance from the key type information.
Although the F creation command is being processed, it may be performed during the command processing of setting a key, for example.

Further, in the above-mentioned embodiment, the IC card is exemplified as the electronic device for performing file management, but the present invention is not limited to this, and any electronic device having a memory that requires file management can be applied. Is.

[0087]

As described above in detail, according to the present invention, after the transport key is passed from the superior to the inferior, the effect is not exerted unless the inferior changes the key. It is possible to provide a file management method with excellent security.

[Brief description of drawings]

FIG. 1 is a block diagram showing a configuration example of a card handling device to which an IC card according to an embodiment of the present invention is applied.

FIG. 2 is a block diagram showing a configuration example of an IC card.

FIG. 3 is a memory map diagram showing a configuration example of a data memory.

FIG. 4 is a diagram showing a format example of various definition information.

FIG. 5 is a diagram showing a structural example of a file set in a data memory.

FIG. 6 is a diagram showing a configuration example of a directory set in a data memory.

FIG. 7 is a flowchart illustrating an operation for creating a data file.

FIG. 8 is a flowchart illustrating an operation for creating a key elementary file.

FIG. 9 is a flowchart illustrating an operation for setting key data.

FIG. 10 is a flowchart illustrating an operation for changing key data.

FIG. 11 is a flowchart illustrating an operation for key verification.

FIG. 12 is a flowchart illustrating an operation for accessing a data elementary file.

[Explanation of symbols]

1 ... IC card, 2 ... Card reader / writer, 3 ...
... control unit, 4 ... keyboard, 5 ... CRT display device, 11 ... control element, 12 ... data memory, 1
3 ... Working memory, 14 ... Program memory,
15 ... Contact part, 120 ... Control area, 121 ...
... directory, 123 ... area group.

Claims (7)

[Claims] 1. In a file management method in which a memory is divided into a plurality of files, and the divided plurality of files are respectively managed by matching a key as a condition of access, it is determined whether or not a key is changed. If it is determined that the key has not been changed, if the key is collated at this time, the condition for access is not satisfied, and if it is determined that the key has been changed, the key is collated at this time. , A file management method characterized in that the access condition is satisfied. 2. A file management method in which a memory is divided into a plurality of files, and the plurality of divided files are respectively managed by using a key collation as an access condition, and it is determined whether or not the key has been changed. If it is determined that the key has not been changed, if the key is collated at this time, the condition is not satisfied as an access condition other than the key change, and if it is determined that the key has been changed, the key of the key is changed at this time. A file management method characterized in that, when a collation is performed, the condition for access is satisfied. 3. A file management method in which a memory is divided into a plurality of files, and the plurality of divided files are respectively managed with key collation as an access condition, it is determined whether or not a key has been changed. If it is determined that the key has not been changed, if the key is collated at this time, the condition for access is not satisfied, and if it is determined that the key has been changed, the key is collated at this time. , The condition is satisfied as an access condition, or the key is verified regardless of whether the key is changed, the condition is satisfied as an access condition. A file management method characterized by being selectable. 4. A file management method in which a memory is divided into a plurality of files, and the plurality of divided files are respectively managed by using key collation as an access condition, and it is determined whether or not the key has been changed. If it is determined that the key has not been changed, if the key is collated at this time, the condition is not satisfied as an access condition other than the key change, and if it is determined that the key has been changed, the key of the key is changed at this time. When the collation is performed, the condition is satisfied as the access condition, or when the key is collated regardless of whether the key is changed, the condition is satisfied as the access condition. A file management method characterized by being able to select either 5. A file management method in which a memory is divided into a plurality of files, and the plurality of divided files are respectively managed with a key collation as an access condition, it is determined whether or not the key has been changed. If it is determined that the key has not been changed, if the key is collated at this time, the condition for access is not satisfied, and if it is determined that the key has been changed, the key is collated at this time. , The condition is satisfied as an access condition, or the key is verified regardless of whether the key is changed, the condition is satisfied as an access condition. A file management method for selecting, and setting attribute information for instructing the selection in the key. 6. A file management method in which a memory is divided into a plurality of files, and the plurality of divided files are respectively managed by using a key collation as an access condition, and it is determined whether or not the key has been changed. If it is determined that the key has not been changed, if the key is collated at this time, the condition is not satisfied as an access condition other than the key change, and if it is determined that the key has been changed, the key of the key is changed at this time. When the collation is performed, the condition is satisfied as the access condition, or when the key is collated regardless of whether the key is changed, the condition is satisfied as the access condition. A file management method characterized in that any one of the above is selected, and attribute information for instructing this selection is set in the key. . 7. An IC card comprising at least a memory, wherein the memory is divided into a plurality of files, and data is stored for each of the plurality of divided files. It is a file management method to manage each as a condition, and it is judged whether the key has been changed, and if it is judged that the key has not been changed by this judgment, if the key is collated at this time, the access condition The method for managing a file of an IC card is characterized in that, when it is determined that the key has been changed and the key is verified at this time, the condition is satisfied as an access condition.