JPH10105472A - Method for managing access of memory - Google Patents

Abstract

PROBLEM TO BE SOLVED: To transfer the right of access to a data file or a memory area from a high-order person to a low-order person by eliminating a participation to the data file from the high-order person. SOLUTION: In an IC card constituted by dividing a memory into plural files, the low-order person changes a transport key which is set by the high- order person into the key (b') which can be known only by himself while referring to an access condition for changing the key, which is set in the key EF, turns-on a transport bit which is given to the data file(DF), generates data EF-b required by himself under the data file(DF) by referring to an EF generating access condition which is set in DF and generates the key EF-c required by himself under DF by referring to the EF generating access condition which is set in DF.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to an electronic device such as an IC card having a built-in non-volatile memory and an IC chip having a control element such as a CPU for controlling the non-volatile memory. A memory access management method for managing access to a plurality of files.

[0002]

2. Description of the Related Art Recently, as a portable data storage medium, a non-volatile data memory and an IC card having a built-in IC chip having a control element such as a CPU (Central Processing Unit) for controlling the same have been attracting attention. Have been.

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

In this multipurpose IC card, it is required that the authority of the card issuer and the authority of the application provider be clearly separated.

This authority can be realized by clarifying the range of access to the IC card when the passwords assigned to the parties are collated.

In a conventional IC card, when a card issuer provides a file to an application provider,
Set the transport key for the application provider in the file. The application provider
When you receive this card, you must first replace the transport key with a provider key that only you can know,
The management in the file given to the application provider can be performed by the provider key.

[0007] Here, information defining an environment in which management within a file can be performed generally includes an access condition given to the file. That is, the file provided by the card issuer to the application provider should be given an access condition that the application provider key needs to be verified.

One of the management actions in the above-mentioned file is to set a file to be used in an application. It is considered that this action includes the setting of the transport key for the application provider described above.

In this case, if the access condition of the file is set so that only the application provider manages the file, the publisher must be satisfied to set the transport key for the application provider. Since the application provider key does not exist, the issuer cannot set the transport key forever.

In order to avoid this, a method of setting either an application provider key or an issuer key as an access condition given to the file is conceivable.

That is, when the publisher sets the transport key for the application provider in the file,
The access condition is satisfied by collating the issuer key, while the access condition is satisfied by collating the own application provider key when the application provider performs another management action in the file. The access condition may be set as follows.

However, in this case, the access conditions set for the file can be accessed by both the publisher and the application provider, and the management authority for the file is changed from the publisher (higher-ranked person) to the application provider ( It can not be said that it was delegated to (lower).

[0013]

As described above, when the publisher sets the transport key for the application provider in the file, the access condition is satisfied by checking the publisher key, while the application is provided. When the user performs another management action in the file, if the access condition is satisfied by checking the application provider key of the user, the access condition set in the file is There has been a problem that the management authority cannot be said to be delegated from the issuer (superordinate) to the application provider (subordinate).

Accordingly, the present invention provides, for example, a memory access management which can eliminate the involvement of a superior in a data file and delegate the right to access the data file or the memory area from a superior to a subordinate. The aim is to provide a method.

[0015]

A memory access management method according to the present invention divides a memory into a plurality of files and manages access to the plurality of divided files, respectively. The first key is set in advance under the file by the superior of the system that
A memory access management method in which a lower party of a system using the memory is capable of setting a new key and enabling access to the file by collation of these keys, First set by the person
Is changed to a second key which can be known only by a lower order person by referring to the access condition for key change set in the first key, and when the key is changed to the second key, It is characterized in that the creation of a key under the file by a superior is rejected.

A memory access management method according to the present invention divides a memory into a plurality of files and manages access to the plurality of divided files, respectively.
A first key is set beforehand under a file by a higher-ranking person of the system using the memory, and a lower-ranking person of the system using the memory can newly set a key. A memory access management method for enabling access to said file by collating said key, wherein a first key set by said higher-ranking person is changed to an access for key change set in said first key. It is characterized in that the condition is changed to a second key which can be known only by a lower order person by referring to the condition, and the creation of a key under the file by the upper order person is rejected.

According to the file access management method of the present invention, in a file access management method for managing access to a file having a tree structure composed of a higher-order file and a lower-order file, To set the access conditions for the file to be provided from the higher level administrator to the lower level administrator, and set the transport key for the transfer from the higher level administrator to the lower level administrator to the lower level file. To set the transport key to the lower file, refer to the access condition of the upper file of the file, and if the access condition of the upper file is satisfied, set the transport key to the lower file. When setting a file, refer to the access condition of the lower-level file to satisfy this access condition. Characterized in that to perform the setting of the file if it has.

According to the portable information processing apparatus of the present invention, in a portable information processing apparatus having a tree-structured file composed of an upper-level file and a lower-level file, an access condition is set and used by an upper-level administrator. Satisfy the access condition of this upper file by referring to the upper file, the lower file which access conditions are set and provided by the upper administrator and used by the lower administrator, and the access condition of the upper file. In this case, the first means for setting a transport key for delivery from a higher-level manager to a lower-level manager in a lower-level file, and the access condition of the lower-level file is referred to to satisfy the access condition. And a second means for setting a file under a lower-level file.

The medium storing the control program for an information processing apparatus according to the present invention is an information processing apparatus which creates a file having a tree structure composed of an upper file and a lower file, and manages access to each file by a control means. In a medium storing a device control program, the control program causes the control means to create a higher-level file in which access conditions are set by a higher-level manager; and a lower-level file provided by a higher-level manager. A step of creating an lower-level file in which access conditions are set for use by an administrator; and a step of referring to an access condition of a higher-level file, and if the access condition of the higher-level file is satisfied, a higher-level administrator A step to set the transport key for transfer to the subordinate administrator in the subordinate file. When, it is composed of a step of setting the file under the subordinate file when it refers to the access condition of the subordinate file satisfies the access conditions characterized by storing the control program.

[0020]

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 shows an example of a configuration 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. is there. That is, this device allows the IC card 1 to be connected to the control unit 3 including a CPU or the like via the card reader / writer 2 and the keyboard 4
It is configured by connecting an RT display device 5, a printer 6, and a floppy disk device 7.

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 storage contents can be erased
2, a working memory 13, a program memory 14, and a contact portion 15 for obtaining electrical contact with the card reader / writer 2. Of these, the portions within the broken lines (control element 11, data memory 1
2, the working memory 13 and the program memory 14) are composed of one IC chip (or a plurality)
Furthermore, as known from Japanese Utility Model Laid-Open No. 2-17381,
The IC chip 10 and the contact portion 15 are integrated into an IC module and 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, for example, a RAM. The program memory 14 is configured by, for example, a mask ROM, and stores a 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, for example, a personal identification number.
It is a target of collation and cannot be read.

These areas are collectively allocated 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 free area 12
2 is stored.

The directory 121 shown in FIG. 3 stores various definition information corresponding to each data file and area, as shown in FIG.

FIG. 4A shows information defining the name of a 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 a 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

Here, a specific bit (for example, the eighth bit) of the DFST is used as a transport bit indicating whether or not the transport key of the DF has been changed.

In particular, the AAID outputs the contents of the data area indicated by the data file as required when a data file is selected by a data file selection command described later.

FIG. 4C shows 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 shows 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.

The 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 structure of a file.
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, the data files DF1 and DF2 are located under the master file (MF), 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, key areas K111 and K112 and data areas D1
11 / D112, and under the data file DF1-2, key areas K121 and K122 and data areas D121 and D122 are set, respectively.

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

Under the data file DF2-1, key areas K211 and K212, 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 a 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, the DFSN is "03" and the 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 flowchart 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).

Upon recognizing the current DF, next, the access condition information in the current DF definition information refers to information relating to file creation. 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 there is, a response message indicating an ID duplication error 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 completed normally (ST8), a response message indicating an abnormal data writing is output, and the process returns to the command waiting state (ST9). When the writing is completed normally (ST
8) A response message indicating normal termination is output, and the process returns to the command waiting state (ST10).

FIG. 8 shows a key elementary file (E
F) A flowchart for explaining the 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).

After recognizing the current DF, next, the access condition information in the current DF definition information refers to information on file creation. 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 not, then the size data of the key EF specified in the command message is referred to, and
The size is compared with the size of the free area in the current DF to be accessed (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, the validity of the key type and size 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).

If the size is determined to be valid, 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 the 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 operation has not been performed, and when the bit is “0”, it indicates that the change operation 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 the case of, the eighth bit of the status information is "0" (that is, it is equivalent to an implicit rewriting operation) regardless of whether or not the key is changed.

In writing the key EF definition information,
If the writing has not been completed normally (ST22), a response message indicating a data writing error 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 is a flow chart for explaining the operation for creating a transport key elementary file (EF), which will be described below.
When the IC card 1 is connected to the transport E
When the F creation command is received, first, the current DF is recognized (ST101).

When the current DF is recognized, it is checked whether the transport bit in the status information DFST set in the data file (DF) is on (ST102).

If the transport bit is on, the command is rejected, a response message indicating that transport is impossible is output, and the process returns to the command waiting state (ST103). If the transport bit is off, this transport key EF
Create commands are allowed. This transport bit is turned off when the data file is created, and turned on when the transport key itself is changed by the key change command.

When the transport key EF creation command is permitted, the access condition of the parent data file (DF) of the current DF 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 or not the collation state of the key required by the access condition has been established (ST104).

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 (ST105). 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. Check whether it exists (ST10)
6). If there is, a response message indicating an ID duplication error is output and the process returns to the command waiting state (ST1)
07).

If it does not exist, next, the size data of the key EF specified in the command message is referred to, and
A comparison is made with the size of the free area in the current DF to be accessed (ST108). In this comparison,
It is checked whether or not the free area size is larger than the size of the designated 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 the specified size abnormality is output, and the process returns to the command waiting state (ST109).

If not, then the validity of the type and size of the key specified in the command message is checked (ST110). 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 (ST111).

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 (ST11).
2) Write this in a predetermined area (ST113). 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 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 operation has not been performed, and when the bit is “0”, it indicates that the change operation 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 the case of, the eighth bit of the status information is "0" (that is, it is equivalent to an implicit rewriting operation) regardless of whether or not the key is changed.

In writing the key EF definition information,
If the writing has not been completed normally (ST114), a response message indicating a data writing error is output, and the process returns to the command waiting state (ST115). If the writing has been completed normally (ST114), a response message indicating normal termination is output, and the process returns to the command waiting state (ST116).

FIG. 10 is a flowchart for explaining the operation for setting key data, 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 (E
By referring to (F-ID), it is checked whether or not the 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 there is, the information regarding the key data setting is referred to among the access condition information in the key EF definition information. 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 present,
The response data indicating that there is existing key data is output, and the process returns to the command waiting state (ST37).

If not, 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, 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).

Here, 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 contains information of 1 byte length and 1 byte.
The byte BCC is added and stored in the key EF area (ST42), the processing result is output as a response message, and the process returns to the command waiting state (ST43).

FIG. 11 is a flowchart 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
By referring to (F-ID), it is checked whether or not the elementary file name exists in the current DF to be accessed (ST52). If not, 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, the information relating to the change of the key data among the access condition information in the key EF definition information is referred to next. 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 contains 1-byte length information and 1 byte.
The byte BCC is added and 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. 12 shows a flowchart 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).

When the current DF is recognized, the directory 121 is searched to determine whether key EF definition information having the specified file name (ID) exists 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 there is, it is checked whether 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 collation processing that there is no match (ST77), first, the key E
Referring to the collation bit designation information and the status information in the F definition information, and according to the same procedure as described above, a predetermined bit in either the collation state holding area A or B is set to "0" (ST81). .

Next, the key-specific collation mismatch counter is set to 1
Only one is incremented (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 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).

The collation state holding area A is used when a file is created.
It is referred to when the key EF is created, when the key data is created, or when the key data is changed, and the collation state holding area B is referred to when the key data is changed.

As described above, if the key has been changed, the collation state holding area A is turned on. If the key has not been changed, the bit of the collation state holding area B is turned on.
The key must be changed at the time of creation of F and at the time of creation of key data. When the key is changed, the collation state holding areas A and B are referred to, so that the key can be changed whether the key has been changed or not changed.

FIG. 13 is a flowchart 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, the elementary file name (E
With reference to (F-ID), it is checked whether the 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 there is, the access condition information corresponding to the type of access (data read / write / change) is referred to from 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 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).

Next, a procedure for creating each file in the IC card in such a configuration will be described.

First, at the time of manufacturing an IC card, in order to set (create) an elementary file of a transport key to be passed to the card issuer, as shown in FIG. MF)
A “key EF-a” is created under the subordinate, and a transport key is set here.

Subsequently, the key elementary file EF
The setting in -a is set in accordance with the flowchart of FIG. 10. When setting a key, the access condition for key setting assigned to the key EF-a is referred to.

When the issuer receives the card in this state,
The transport key is changed according to the flowchart of FIG. That is, as shown in FIG. 15, the issuer changes the transport key set by the manufacturer to a key (a ') that can be known only by itself. This change includes the key EF
Refer to the access condition for key change set in. At this point, the transport bit assigned to the master file (MF) is turned on, and thereafter, creation of a key under the master file (MF) by the manufacturer is rejected.

Next, the issuer creates the data EF-a required by the issuer under the master file (MF).
In this case, the E set in the master file (MF)
Refer to F creation access conditions.

The publisher creates a data file (DF) to be released to the application provider under the master file (MF). The setting of the DF is performed according to the flow of FIG. 7, and in this case, the master file (MF)
Is referred to the data file (DF) creation access condition set in.

Next, the publisher issues the data file (D
F) Create a transport key EF-b to be handed over to the application provider. The creation of the transport key EF-b is performed according to the flow of FIG. 9, and in this case, the access condition to be referred to is the data file (D
Reference is made to the access condition given to the master file (MF), which is the parent file, instead of the one given to F).

Next, the issuer sets a transport key in the transport key EF-b. The setting of the transport key is performed according to the flow of FIG.
In this case, the access condition for key setting, which is given to the target key EF-b, is referred to.

In this state, when the application provider receives the card, as shown in FIG. 16, the application provider changes the transport key set by the issuer to a key (b ') that can be known only by itself. For this change, the access condition for key change set in the key EF is referred to. At this point, the data file (D
The transport bit assigned to F) is turned on, and thereafter, creation of a key under the data file (DF) by the issuer is rejected.

Next, the application provider stores the data EF-b required by the application provider in a data file (DF).
Create under your control. The creation of the data EF-b is performed according to the flow shown in FIG. 7. In this case, the access condition for creating the EF set in the data file (DF) is referred to.

The application provider creates a key EF-c required by itself under the data file (DF). The creation of the key EF-c is performed according to the flow of FIG. 8, and in this case also, the access condition for creating an EF set in the data file (DF) is referred to.

The commands are as follows. In particular, the command format is different from the normal key EF creation command and the transport key EF creation command. Has been identified.

That is, a normal key EF creation command and a transport key EF creation command are distinguished. In the case of a transport key EF creation command, processing is performed according to the flowchart of FIG. 8 is performed.

Area (elementary file) creation command Command code A / AID (EF-ID) / ASIZ / AAC Key EF creation command Command code B / KID / KSIZ / CF / AAC Transport key EF creation command Command code C / KID / KSIZ / CF / AAC When creating the transport key EF under the current DF, the access condition of the parent DF of the current DF is referred to. The access condition of the parent DF is set by the superior, and the transport key EF can be created by the superior.

When setting the transport key to the transport key EF, the access condition of the EF is referred to. However, the access condition of the EF is set by the superior when the transport key EF is created. The superior sets the access conditions of the transport key EF so that the transport key can be set.

When the application provider sets a key EF under the current DF, the key EF of the current DF is set.
The access condition for creation is referred to, but the access condition of the DF is set by a superior at the time of creation of the DF.

However, after the change of the transport key, the processing using the access conditions of the DF (creation of the data EF and the key EF) can be performed only by the application provider, so that the classification of the access right becomes clear.

Further, when the upper party sets the key after the change of the transport key as an access condition for creating the key EF, the application provider sets the key EF used by itself after changing the transport key. ,
An environment in which the access condition of the DF can be satisfied by the collation bit designation information in the key definition information of the key EF used by itself is prepared.
The access condition of the DF for creation of F is satisfied, and creation of data EF is enabled.

In this way, although the superior sets the DF access conditions, only the application provider can satisfy the DF access conditions without knowing the contents.

As described above, according to the embodiment of the present invention, a key required to create an EF (or DF) under a data file (DF) is added to the data file (DF). This access condition can be realized without specifying a higher-level key (in this embodiment, the issuer becomes a higher-level person for the application provider).

Therefore, the file (or memory area) that the application provider wants to manage by itself can be protected only by its own key.

As a result, the issuer is no longer involved in the data file (DF), and the authority of access to the file (or memory area) is delegated from the issuer to the application provider. Become.

It is noted that the transport bit in this embodiment is off when the data file (DF) is created, and turns on when the transport key itself is changed by the key change command. However, the present invention may be implemented by, for example, a command for turning on a transport bit without interlocking with the key change command. In this case, the access condition used for executing the command refers to the access condition set in the target file.

Further, in the above-described embodiment, an IC card is exemplified as the electronic device for performing memory access management. However, the present invention is not limited to this, and an electronic device having a memory that requires memory access management may be used. If applicable, it is applicable.

[0122]

As described above in detail, according to the present invention, for example, the involvement of a superior in the data file is eliminated, and the authority of access to the data file or the memory area is transferred from the superior to the subordinate. And a memory access management method capable of performing the above.

[Brief description of the 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 view showing an example of the structure of a file set in a data memory.

FIG. 6 is a view 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 creating a transport key elementary file.

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

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

FIG. 12 is a flowchart illustrating an operation for key matching.

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

FIG. 14 is a view for explaining creation of a file for an IC card by a manufacturer.

FIG. 15 is a view for explaining creation of a file for an IC card by an issuer.

FIG. 16 is a diagram for explaining file creation for an IC card by an application provider.

[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 (14)

[Claims] The present invention divides a memory into a plurality of files, and manages access to the plurality of divided files, respectively. A higher order person of a system using the memory stores a first key under a file. Is set in advance,
A memory access management method in which a lower party of a system using the memory is capable of setting a new key, and which is capable of accessing the file by collating these keys. The first key set by the third party is changed to a second key that can be known only by a lower order person by referring to the access condition for key change set in the first key, and the second key is changed to the second key. A memory access management method characterized by rejecting the creation of a key under a file by the upper party when changed. 2. A system in which a memory is divided into a plurality of files and access to the plurality of divided files is managed, and a first key is stored under a file by a superior of a system using the memory. Is set in advance,
A memory access management method in which a lower party of a system using the memory is capable of setting a new key, and which is capable of accessing the file by collating these keys. The first key set by the third party is changed to a second key that only the lower party can know by referring to the access condition for key change set in the first key, and the file is controlled by the upper party. A memory access management method characterized by rejecting the creation of a key. 3. A file access management method for managing access to a file having a tree structure including an upper file and a lower file, wherein an access condition is set for an upper file managed by an upper manager; When setting access conditions for files provided by a higher-level administrator to lower-level administrators and setting a transport key for transfer from a higher-level administrator to a lower-level administrator in a lower-level file, the Refer to the access condition of the upper file of the file, and if the access condition of the upper file is satisfied, set the transport key to the lower file, and set the transport key to the lower file. Refer to the access condition of the lower-level file and set the file if this access condition is satisfied. File access management method characterized in that as. 4. The apparatus according to claim 1, wherein the lower-level file is provided with identification information indicating whether or not a transport key can be set, and the setting of the transport key for the file is prohibited based on the identification information. 4. The file access management method according to claim 3, wherein: 5. The apparatus according to claim 4, wherein when the transport key for the lower-level file is changed, the identification information is updated so as to prohibit the setting of the transport key for the file thereafter. File access management method described in. 6. The file access management method according to claim 4, wherein the identification information indicating whether a transport key can be set in the lower-level file is updated based on a special command. 7. The transport key setting for the lower-level file is performed by a command for setting a transport key, and when setting a file under the lower-level file, the command is different from the command for setting a transport key. 4. The file access management method according to claim 3, wherein the method is performed by a command. 8. A portable information processing apparatus having a tree-structured file composed of an upper-level file and a lower-level file, wherein an access condition is set and an upper-level file to be used by a higher-level administrator, Refers to the lower-level files provided by the higher-level administrator and used by the lower-level administrator, and the access conditions of the higher-level file. A first means for setting a transport key for transfer to a lower-level manager in a lower-level file; and referring to an access condition of the lower-level file and subordinate to the lower-level file when the access condition is satisfied. A portable information processing apparatus, comprising: second means for setting a file. 9. The method according to claim 9, wherein the lower-order file has a storage area for identification information indicating whether or not a transport key can be set, and has means for prohibiting setting of a transport key for the file based on the identification information. 9. The portable information processing apparatus according to claim 8, wherein: 10. The apparatus according to claim 8, further comprising means for updating the identification information so as to prohibit the setting of the transport key for the file when the transport key for the lower-level file is changed. A portable information processing device according to claim 1. 11. The portable information storage medium operates based on a command supplied from an external device, and the identification information indicating whether a transport key can be set in the lower-level file is a special command supplied from the external device. 9. The portable information processing apparatus according to claim 8, further comprising means for updating based on the information. 12. The portable information storage medium operates based on a command supplied from an external device, and setting of a transport key to a lower-level file by the first means is performed by a transport key setting command. 9. The portable information processing apparatus according to claim 8, wherein the second means operates to set a file under a lower-order file by a command different from a command for setting a transport key. . 13. A medium storing a control program for an information processing device for creating a tree-structured file composed of an upper file and a lower file and controlling access to each file by a control means, wherein Creating a higher-level file for which access conditions have been set by a higher-level manager with respect to the control means; and setting an access condition provided by the higher-level manager for use by the lower-level manager. Creating the file of the upper level, and referring to the access condition of the upper level file, if the access condition of the upper level file is satisfied, a transport key for transfer from the upper level administrator to the lower level administrator is obtained. Refer to the step of setting the lower file and the access condition of the lower file, and Medium storing an information processing apparatus control program characterized by storing the control program is composed of a step of setting the file under the subordinate file if you are satisfied Seth conditions. 14. A module in which a program memory storing the control program for the information processing device, a data memory to which the file is allocated, a control circuit for managing access to the file, and an interface with an external device are included in one module. 14. A medium storing the control program for an information processing device according to claim 13, wherein the control program is configured to: