JP2002279390A - Data access control system, memory-mounted device, data access control method, and program storage medium - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a data access control system for realizing an improved control configuration to the access to a memory in a device. SOLUTION: A memory-mounted device receives an access control ticket from an access appliance and permits the access appliance described on the ticket on the conditions that the authentication is established, based on the authentication rule described on the ticket, and identification data of the access appliance described on the ticket is confirmed. Various kinds of authentication modes and ticket modes can be set for each access to realize access control capable of setting the security level, according to the memory access. A category or an identifier of a ticket issuing means and a utilizing means is stored in the ticket and can be verified by the device.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a data access control system, a memory mounted device, a data access control method, and a program storage medium. More specifically, a data access control system that issues a command from an access device to a memory-equipped device to execute access control in processing of data stored in the memory unit, a memory-equipped device, and a data access control A method and a program storage medium.

[0002]

2. Description of the Related Art Conventionally, tape media, floppy (registered trademark) disks, hard disks, optical disks, semiconductor media, and the like have been used as devices having a memory. Among them, semiconductor media has attracted attention as a device capable of securely managing a memory in a device. The reason is that the semiconductor memory can easily realize a structure that is not easily accessed from outside, that is, a tamper-resistant structure.

In the tamper-resistant structure, for example, a device has a single-chip configuration made of a semiconductor, and the chip is provided with a control unit, a memory controller, a nonvolatile memory, a voltage detecting means, a frequency detecting means, and the like. This is realized by a configuration sandwiched between dummy layers such as an aluminum layer so that reading and writing cannot be performed.

A conventional memory structure of such a secure device will be described with reference to FIG. 96 "Conventional memory structure". The memory in FIG. 96 shows a memory configuration that can be used, for example, as electronic money. As shown in FIG. 96, the memory area is roughly divided into three. That is,
A data area, a memory management area, and a system area.

[0005] The data area stores data based on the "data structure" stored at the head of each data.
In this example, user name, address, telephone number, amount, memo, and log are stored. The memory management area stores a storage address for accessing each data in the data area, an access method, an access authentication key, and the like. For example, it is shown that access to data 1 (user name) in the data area can be performed only by reading (Read) by using the access authentication key (0123...). In the system area, a device identifier (I
D) A memory management key or the like, which is an authentication key for securing a memory area in the data area, is stored.

The data area of the memory device shown in FIG. 96 can be divided into a plurality of data areas.
Different service entities, for example, electronic money, may be managed by different electronic money service providing entities (ex. Different banks). The data of each divided area is obtained by a user, for example, a reader / writer (dedicated reader / writer, PC, etc.) as a device access device provided in a store selling goods using electronic money, in addition to the individual service provider. , And (ex. Update of balance data) are executed.

The relationship between the administrator and the user of a secure device having a plurality of divided data areas as shown in FIG. 96 is shown in FIG. 97, "Memory Administrator / User". As shown in FIG. 97, there are a memory manager who is a subject of issuing a secure device, and a memory user who has a memory area allocated by the memory manager and uses the allocated memory. There are data 1 users to data 6 users as memory users. The memory user is, for example, a bank or a store according to the example of the electronic money described above.

A memory manager knows a memory management key for access control for securing a memory area, and allocates a memory (divided data area) of each memory user using the memory management key. . Also,
The memory user knows the access authentication key for accessing the data in each data area, and can use this access authentication key to access the memory in the assigned data area. As an access mode, data reading (Read) and writing (Wri) are performed.
te), reduction of the balance (Decrement), etc., and it is possible to individually set an access authentication key according to each processing mode and set whether or not individual processing is possible.

For example, data 4 in the memory shown in FIG.
Is the amount data, and as shown in FIG. 97, the user of the data 4 reduces the data 4 (Decrement).
And read / write processing. As shown in the table at the lower right of FIG. 96, the process of decrementing (Decrement) of data 4 and reading and writing (Rea)
d / Write), the access key is different,
It is necessary to access the memory using an access key corresponding to each process.

FIG. 98 is a view for explaining a memory securing process in which a memory manager allocates a certain data area in a memory device to a memory user. As shown in the “method of securing memory” in FIG. 98, the memory administrator operates a memory securing reader / writer (R / W: Reader) shown on the left side of the figure.
/ Writer) to execute a process of securing a data area for the memory device shown on the right side of FIG. A memory securing reader / writer (R / W: Reader / Writer) has a secure NVRAM (Non-Vo) for holding a memory management key.
latile RAM). Note that R for memory
/ W is a dedicated read / write R /
Even if W, secure device is USB, PCM
In the case of a device having an I / F such as CIA, a device readable and writable through these interfaces, for example, P
C may be used.

In order to secure a memory using R / W, first, a device ID is read from a secure device. Next, in the R / W, the memory management key and the device I
An authentication key is generated using D, and mutual authentication is performed with the secure device using the generated authentication key. Mutual authentication processing is, for example, mutual authentication using a common key method (ex.ISO / IEC9798-2)
It is executed according to.

After successful mutual authentication, the R / W encrypts the data structure, the data size, the access method, and the access authentication key with the session key and, if necessary, the M for data verification.
A command is sent to the secure device with an AC (Message Authentication Code) value added. Upon receiving the command, the secure device decrypts the received data, performs data tampering verification as needed by MAC verification processing, and then allocates a memory area to a data area of the memory according to the data size in the received data. The data structure is written in the secured area, and the address, access method, and access authentication key of the secured memory are written in the memory management area.

In this way, a plurality of divided data areas are set in the memory device. Next, a memory access method for a memory device having a plurality of divided data areas will be described according to the “memory access method” of FIG. The reader / writer on the left side of FIG. 99 is a memory access reader / writer (R / W) possessed by the memory user, and is composed of a dedicated R / W or a PC as in the above-described memory securing R / W. The memory access reader / writer (R / W) includes a secure NVRAM for holding an access authentication key. In order to access the data area of the secure device using the R / W, first, a device ID is read from the secure device. Next, in the R / W, an authentication key is generated using the access authentication key and the device ID, and mutual authentication is performed with the secure device using the generated authentication key. After the successful mutual authentication, the R / W makes a predetermined access to the data in the data area corresponding to the access authentication key.

At this time, since an access method is defined in the memory management area, for example, as shown in “memory access method” in FIG. 99, access authentication for decrement of data 4 (money data) is performed. If successful,
Even if the data 4 can be reduced, addition or free rewriting cannot be performed. As described above, by setting the access authentication key used for the authentication process to be different according to each access mode, the security of each data can be improved. For example, even if the R / W for reduction processing is stolen and the NVRAM in the R / W for reduction processing is stolen, the data 4 (money data) in the secure device in FIG. It is possible to reduce the possibility that a large increase process is performed.

[0015] Generally, a deposit terminal can enhance security like an ATM, but a dispensing terminal is often used as a money collecting machine at the time of delivery of goods at a store or the like. The risk of theft is high and it is difficult to increase the degree of security. Therefore, a configuration in which the access authentication key is different for data access is effective.

[0016]

SUMMARY OF THE INVENTION In the above-mentioned conventional use of a memory device having a divided data area, in a process of securing a data area of a memory and an access process of each data area, authentication using a memory management key is performed. Each process is executed by executing a process or an authentication process using an access authentication key. Specifically, these processes are configured to apply a common key by a DES encryption algorithm, for example, It does not assume authentication by a method or verification by a public key method.

The configuration in which the common key is applied to the memory management key and the access authentication key as described above has an advantage that the authentication and the access permission are executed in one process, but the leakage of the authentication key causes the memory access by the leaked key. However, there is a drawback that it becomes possible, which is a security problem.

In order to reduce the cost of a reader / writer (R / W) for executing access to a memory device, a configuration in which an encryption algorithm is not implemented in the reader / writer (R / W) is also conceivable. With such a configuration, authentication between devices and encryption of communication data cannot be performed at all, and it is not suitable as a reader / writer for a device that holds user money data, other user private information, and the like. .

The present invention has been made in view of the above-mentioned state of the art, and various types of access control tickets are assigned to each device in response to access to a memory area divided into a plurality of partitions. Alternatively, it is intended to realize an independent management configuration of data in each partition by issuing a process under the management of the partition management entity and executing a process based on a rule described in each ticket in a device equipped with a memory. And

Further, the memory-equipped device receives an access control ticket configured as access control data from the access device, performs authentication based on the authentication rule described in the access control ticket, and performs authentication based on the authentication rule described in the access control ticket. By allowing data access under the condition that the identification data of the access device is confirmed, access to the memory can be executed under more secure management, and various authentication modes and ticket modes can be set for each access. It is an object of the present invention to provide a data access control system, a memory-mounted device, a data access control method, and a program storage medium that realize access management with a security level set according to memory access processing.

[0021]

SUMMARY OF THE INVENTION A first aspect of the present invention is as follows.
A data access control system for issuing a command from an access device to a memory-equipped device having a memory part capable of storing data and executing a process on data stored in the memory part, wherein the memory-equipped device is An access control ticket configured as access control data for the data stored in the memory unit is received from the access device, authentication based on the authentication rule described in the access control ticket is established, and the access control ticket The data access control system is characterized in that the data access is allowed under the condition that the identification data of the described access device is confirmed.

Further, in one embodiment of the data access control system of the present invention, the access control ticket specifies an authentication method that allows either or any of a public key authentication method and a common key authentication method as an authentication method. An authentication type is described as information, and the memory-equipped device is configured to execute an authentication process according to an authentication type described in an access control ticket received from an access device.

Further, in one embodiment of the data access control system of the present invention, the access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device receives the access control ticket from an access device. Based on the category or identifier of the issuing means of the access control ticket described in the access control ticket, a confirmation process is performed to confirm that the ticket is a ticket issued by a valid issuing means. It is characterized in that the access is permitted.

Further, in one embodiment of the data access control system of the present invention, the access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device receives the access control ticket from an access device. The ticket is validly issued based on a comparison between the category or identifier of the access control ticket issuing means described in the access control ticket described above and the user information stored in the public key certificate of the access control ticket issuing means. It is characterized by executing a confirmation process of a ticket issued by the means, and permitting data access on condition of the confirmation.

Further, in one embodiment of the data access control system of the present invention, the access control ticket stores a category or an identifier of an access device which is a means for using the access control ticket, and Based on the category or identifier of the access device, which is the use device of the access control ticket described in the access control ticket received from the access device, executes a process of confirming that the ticket is a ticket provided by a valid use device. The data access is permitted under the condition of the confirmation.

Further, in one embodiment of the data access control system of the present invention, the access control ticket stores a category or an identifier of a use means of the access control ticket, and the memory-equipped device receives the category from the access device. Based on a comparison between the category or identifier of the access device that is the use means of the access control ticket described in the access control ticket and the user information stored in the public key certificate of the use means of the access control ticket, The present invention is characterized in that a confirmation process is performed to confirm that the ticket is a ticket provided by a valid use means, and that data access is permitted on condition of the confirmation.

Further, in one embodiment of the data access control system of the present invention, the memory section of the memory-equipped device has at least one partition area as a memory area managed by a corresponding partition manager, the memory mounting device generates an authentication table associating the access device and a public key system authentication information and the session key obtained by the partition authentication or device authentication performed during a session or a common key system authentication information and the session key, It is characterized by having the structure which does.

Further, a second aspect of the present invention is a memory-equipped device having a memory unit capable of storing data,
Control means for issuing a command from the access device to execute processing on the data stored in the memory unit, wherein the control unit performs, as access control data for the data stored in the memory unit, from the access device; Receiving the configured access control ticket, permitting data access on condition that authentication based on the authentication rule described in the access control ticket is completed and identification of the access device described in the access control ticket is confirmed. A memory-equipped device is characterized in that the memory-equipped device is characterized in that:

Further, in one embodiment of the memory-equipped device of the present invention, the access control ticket includes, as an authentication method, either public key authentication method or common key authentication method, or authentication method designation information indicating that the authentication method is permitted. The control type is configured to execute an authentication process according to the authentication type described in the access control ticket received from the access device.

Further, in one embodiment of the memory-equipped device of the present invention, the access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the control means controls the access received from the access device. Based on the category or identifier of the issuing unit of the access control ticket described in the control ticket, a confirmation process is performed to confirm that the ticket is a ticket issued by a valid issuing unit, and data access is performed on condition of the confirmation. It is characterized in that it is an allowable configuration.

Further, in one embodiment of the memory-equipped device of the present invention, the access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the control means controls the access received from the access device. The ticket is authorized by the issuing means based on a comparison between the category or identifier of the issuing means of the access control ticket described in the control ticket and the user information stored in the public key certificate of the issuing means of the access control ticket. The present invention is characterized in that a confirmation process for executing the issued ticket is executed, and data access is permitted on condition of the confirmation.

Further, in one embodiment of the memory-equipped device of the present invention, the access control ticket stores a category or an identifier of an access device which is a use unit of the access control ticket, and the control unit includes an access device. Based on the category or identifier of the access device that is the use means of the access control ticket described in the access control ticket received from, based on the confirmation processing that the ticket is a ticket provided by a valid use means, The data access is permitted under the condition of the confirmation.

In one embodiment of the memory-equipped device of the present invention, the access control ticket stores a category or an identifier of a use unit of the access control ticket, and the control unit stores the access control ticket received from the access device. Based on a comparison between the category or identifier of the access device that is the use means of the access control ticket described in the control ticket and the user information stored in the public key certificate of the use means of the access control ticket,
The present invention is characterized in that a confirmation process is performed to confirm that the ticket is a ticket provided by a valid use means, and that data access is permitted on condition of the confirmation.

Further, in one embodiment of the memory-equipped device of the present invention, the memory part of the memory-equipped device has one or more partition areas each as a memory area managed by a corresponding partition manager. The control unit is configured to generate an authentication table in which public key type authentication information and a session key obtained by partition authentication or device authentication executed during a session with the access device, or a common key type authentication information and a session key are associated. It is characterized by having.

Further, according to a third aspect of the present invention, a command is issued from an access device to a memory-equipped device having a memory unit capable of storing data, and processing is performed on data stored in the memory unit. A data access control method, wherein the memory-equipped device receives, from the access device, an access control ticket configured as access control data for data stored in the memory unit, and the device described in the access control ticket. A data access control method is characterized in that data access is permitted on condition that authentication based on an authentication rule is established and identification data of an access device described in the access control ticket is confirmed.

Further, in one embodiment of the data access control method according to the present invention, the access control ticket specifies an authentication method in which either or any of a public key authentication method and a common key authentication method is permitted as an authentication method. An authentication type is described as information, and the memory-equipped device performs an authentication process according to an authentication type described in an access control ticket received from an access device.

Further, in one embodiment of the data access control method of the present invention, the access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device receives the access control ticket from an access device. Based on the category or identifier of the issuing means of the access control ticket described in the access control ticket, a confirmation process is performed to confirm that the ticket is a ticket issued by a valid issuing means. Access is allowed.

Further, in one embodiment of the data access control method of the present invention, the access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device receives the category from the access device. The ticket is validly issued based on a comparison between the category or identifier of the access control ticket issuing means described in the access control ticket described above and the user information stored in the public key certificate of the access control ticket issuing means. Confirmation processing of the ticket issued by the means is executed, and data access is permitted on condition of the confirmation.

Further, in one embodiment of the data access control method of the present invention, the access control ticket stores a category or an identifier of an access device which is a means for using the access control ticket, and the memory-mounted device includes: Based on the category or identifier of the access device, which is the use device of the access control ticket described in the access control ticket received from the access device, executes a process of confirming that the ticket is a ticket provided by a valid use device Then, data access is permitted under the condition of the confirmation.

Further, in one embodiment of the data access control method of the present invention, the access control ticket stores a category or an identifier of a use means of the access control ticket, and the memory-equipped device receives the category or identifier from an access device. Based on a comparison between the category or identifier of the access device that is the use means of the access control ticket described in the access control ticket and the user information stored in the public key certificate of the use means of the access control ticket, A confirmation process is performed to confirm that the ticket is a ticket provided by a valid use unit, and data access is permitted on condition of the confirmation.

Further, in one embodiment of the data access control method of the present invention, the memory section of the memory-equipped device has at least one partition area as a memory area each managed by a corresponding partition manager, The memory-equipped device generates an authentication table in which public key authentication information and a session key obtained by partition authentication or device authentication executed during a session with the access device, or a common key authentication information and a session key are associated with each other. It is characterized by doing.

Further, according to a fourth aspect of the present invention, in a memory-equipped device having a memory unit capable of storing data, a command is issued from an access device to perform processing on data stored in the memory unit on a computer system. A program storage medium for providing a computer program to be executed by the computer;
Receiving, from the access device, an access control ticket configured as access control data for data stored in the memory unit;
A step of permitting data access on condition that the authentication based on the authentication rule described in the access control ticket is established and that the identification data of the access device described in the access control ticket is confirmed. It is on the program storage medium.

The program storage medium of the present invention is a medium that provides a computer program in a computer-readable format to a general-purpose computer system that can execute various program codes. The form of the medium is not particularly limited, such as a recording medium such as a CD, an FD, and an MO, and a communicable medium.

Such a program storage medium defines a structural or functional cooperative relationship between the computer program and the storage medium for realizing a predetermined computer program function on a computer system. Things. In other words, by installing the computer program into the computer system via the storage medium, a cooperative operation is exerted on the computer system, and the same operation and effect as the other aspects of the present invention can be obtained. You can do it.

Still other objects, features and advantages of the present invention are:
It will become apparent from the following more detailed description based on the embodiments of the present invention and the accompanying drawings. In this specification, a system is a logical set configuration of a plurality of devices, and is not limited to a configuration in which devices of each configuration are in the same housing.

[0046]

Embodiments of the present invention will be described below in detail with reference to the drawings. The description will be made according to the following items. A. Description of configuration entity and ticket of data processing system using device A1. Outline of data management system using memory-mounted device A2. Device configuration A3. Configuration of Device Manager A4. Configuration of Partition Manager A5. Configuration of ticket user (reader / writer as device access device) A6. Public key certificate A7. Data stored in memory section of device A7.1. Device-specific information and in-device partition information area A7.2. Partition area A8. Data format of each ticket A8.1. Partition Registration Ticket (PRT) A8.2. File Registration Ticket (FRT) A8.3. Service permission ticket (SPT) A8.4. Data update ticket (DUT) Description of details of device distribution to users, various settings for devices, and device use processing B1. Flow from initial device registration to use B2. Initial registration processing by device manufacturing entity B3. Jurisdiction process of device manager B3.1. Device registration processing by device manager B3.2. Public key certificate issuance processing under device manager management B4. Jurisdiction process of partition manager B4.1. Partition setting registration / deletion processing using partition registration ticket (PRT) under management of partition manager B4.2. Public key certificate issuance processing under the control of partition manager B4.3. Processing procedure in each method of partition generation processing B4.4. File generation and deletion processing using file registration ticket (FRT) B4.5. Processing procedure in each method of file generation processing B4.6. Service (file access) process using service permission ticket (SPT) B4.7. Processing procedure in each access processing method using service permission ticket (SPT) B5. Device data update process using data update ticket (DUT)

[0047]

Embodiment [A1. Outline of data management system using memory-mounted device] FIG. 1 is a diagram for explaining the outline of a data management system of the present invention. The memory-mounted device (hereinafter referred to as a device) 100 is manufactured by a device manufacturing entity (manufacturer) 500, and a device manager (DM: Devi) as a device management entity.
ce Manager) 200 provided to the user and used. The form of providing the device to the user may be any form such as lending or selling (including transfer).

In the device 100, the memory area is divided into partitions as a plurality of data storage areas, and each partition (Partition A, B... Z) has various service entities (A, B,... Z) 300A to 300Z. It is used for various services under the management of Partition Manager.

In the partition setting registration processing for the device 100, the file registration registration processing in the partition set in the device, and the access processing for each registered file, a valid ticket issuer (Ticket Issuer) is issued. Require an access control ticket for the specified device.

In the partition setting registration process for the device 100, a valid ticket issuing means (Ticket I
ssuer) issued a partition registration ticket (PR
T: Partition Registration Ticket)
In the file setting registration process in the partition set in the device, a valid ticket issuing means (Tick
et Issuer) issued a file registration ticket (FR
T: File Registration Ticket)
Access to each file requires a service permission ticket (SPT) issued by a valid ticket issuer.

Each ticket includes, for example, a partition registration ticket (PRT) in addition to an access rule for the device 100, for example, a rule relating to a mutual authentication process between a reader / writer that performs various processes such as reading and writing for the device and the device. For example, a partition size that can be set, a file registration ticket (FRT) that can be set, a file size that can be set, and a service permission ticket (SPT) that can be accessed (ex.
Data reading, writing, etc.), and information on the ticket issuer, the ticket user, and other information. Further, an ICV (Integrity Check) for falsification check on the ticket storage data is used.
Value) is recorded, and processing within the range recorded in the ticket can be executed on condition that there is no tampering of the ticket. The details of these tickets will be described later.

In the example shown in FIG. 1, a ticket issuing means (Ticket Issuer) for issuing a partition registration ticket (PRT) is a device manager (DM) 20.
0, and the file registration ticket (F) is stored in the service entity A, 300A as the partition manager.
RT) and a ticket issuer (Ticket Issuer) for issuing a service permission ticket (SPT). It should be noted that the configuration in FIG.
To 300Z have basically the same configuration as the service subject A. Each service subject has a file registration ticket (FRT) and a service permission ticket (S
A ticket issuing means (TicketIssuer) for issuing a PT) is set.

Although the service entity and the partition manager (PM) are shown as the same entity in FIG. 1, these entities do not necessarily need to be the same entity, and the partition as a memory area set in the device is not necessary. And a service entity that borrows a partition that is a memory area managed by the partition manager from the partition manager under a predetermined contract, stores various files in the borrowed partition, and provides services. It may exist as an entity. In the following description, an example of a configuration in which a service entity functions as a partition manager will be described to simplify the description.

The partition manager (PM) as each of the service entities 300A to 300Z issues a partition registration ticket (PRT) to the device manager (DM) 200 under a predetermined contract, for example, by paying a corresponding price. Make a request and, under the permission of the device manager (DM), the ticket issuing means (Ticket Issuer) in the device manager (DM) issues a partition registration ticket (PRT) to the partition manager (PM) as each service entity I do.

Each service entity (partition manager (PM)) 300 has a communication interface (I / F).
The user accesses the device 100 owned by the user via the PC, executes processes such as authentication and verification according to the rules recorded in the partition registration ticket (PRT) received from the device manager (DM) 200, and registers the partition. A setting registration process of the partition within the permission range recorded in the ticket (PRT) is executed. This processing will be described later in detail.

The communication I / F may be an interface capable of performing data communication with an external device (device) irrespective of wired or wireless. For example, when the device has a USB connection configuration, a USB I / F; I for IC card type
Reader / writer for C card, public line, communication line,
A device having various communication functions such as the Internet or a device connectable to these communication devices is configured as a data communication I / F according to each communication method.

Further, the service subject 30 is provided in the device 100.
When a partition of 0 is set, each service entity 3
00 accesses the user-owned device 100 via the communication interface (I / F), and
No. 00 executes processing such as authentication and verification in accordance with the rules recorded in the file registration ticket (FRT) issued by the ticket issuer (Ticket Issuer), and within the permitted range recorded in the file registration ticket (FRT). Execute the setting registration process of the file. This processing will be described later in detail.

Further, each service entity 300 accesses the device 100 owned by the user via the communication interface (I / F), and issues a service permission ticket (SPT) issued by the ticket issuing means (Ticket Issuer) of each service entity. , And performs access (ex. Data reading, writing, etc.) processing within the permitted range recorded in the service permission ticket (SPT). This processing will be described later in detail.

As shown in FIG. 1, a code management organization 400 is set above the device manager 200 and the partition manager 300, and performs a process of allocating a code as identification information of each entity to each device manager and partition manager. I do. The codes assigned to these managers are stored data of access control tickets such as the partition registration ticket (PRT) and the file registration ticket (FRT) described above.

Before the device 100 is provided (ex. Lent, sold) to the user and used by the user, a device manager (DM) 200 for managing the provided device is set, and a device manager code and other devices are provided in the provided device. The management information of the manager is written. Details of these data will be described later.

The relationship between public key certificate issuance processing and each entity in the data management system using the memory device of the present invention will be described with reference to FIG.

FIG. 2 shows a device manager as a device management entity, two partition managers 300 A and 300 B, and a code management organization 400 for assigning an identification code to the device manager 200 as a management entity of each partition set in the device. Is shown. Further, the device manager 20
In response to a public key certificate issuance request from the registration authority 210 under the jurisdiction of the device manager 200, each device (partition registration ticket (PR
T) Issuing means (PRT Issuer) 210 or a device corresponding public key certificate (CERT) corresponding to the device 100
-DEV-issued Certificate Authority (CA)
(DEV): Certificate Authority 610, devices under the jurisdiction of partition managers 300A, 300B (file registration ticket (FRT) issuing means (FRTI)
ssuer) 310, service permission ticket issuing means (SP
T) 320, a reader / writer 711-714 as a device access device as a ticket user, or a partition manager compatible certificate authority (CA (PAR)) that issues a partition corresponding public key certificate (CERT-PAR) corresponding to a partition of the device 100. ): Certificat
e Authority) 620 and 630.

In FIG. 2, the certificate authority is a device manager-compatible certificate authority: CA (Certificate Authority) fo
r DM (or CA (DEV)) 610 and CAs for PAR (or CA (PAR)) 620 and 630 corresponding to partition managers are shown, but the only CA having both functions is shown. Or a common certificate authority corresponding to a plurality of partition managers and a separate certificate authority corresponding to a device manager can be provided freely.

The device manager 200 and the partition managers 300 A and 300 B have their own public key certificates, public key certificates of devices (ticket issuing means, ticket users) managed by each manager, or public keys from the device 100. A certificate issuance request is received, the received issuance request is verified, and after the verification, a process of transferring the certificate issuance request to the certificate authority is performed, and a process of managing the issued public key certificate is performed. Registration Authority (RA:
Registration Authority) 220,330.

The public key certificate issued from each of the certification authorities (CA) 610, 620, and 630 through the registration authorities (RA) 220 and 330 is stored in the device 100, and the processing for the device 100 is performed, for example, on the partition. It is used for setting processing, for example, file setting processing as processing for a partition, mutual authentication processing at the time of file access processing, and the like, or the above-described validity verification processing of each ticket. Details of the public key certificate issuance processing and each processing using the public key certificate will be described later.

In FIG. 2, the device 100 has partition managers 1 and 300A as partitions.
Management partition: PM1Area, partition manager 2, 300B management partition: PM
2Area and a device manager 200
Has a DMArea as a management area.

The device manager 200 has a partition registration ticket issuing means (PRT Issuer) 210, and the partition manager 300 has a file registration ticket issuing means (FRT Issuer) 310 and a service permission ticket issuing means (SPT Issuer) 320.
Each ticket is issued.

Partition Manager 1,300A
Is a configuration having dedicated reader / writers (interfaces for reading and writing data to devices) 711 to 713 which are different for each ticket of PRT, FRT, and SPT.
A configuration having a common reader / writer 714 for each ticket is shown. The reader / writer can have various configurations as described above.

Further, a specific example of the entity will be described with reference to FIG. FIG. 3 assumes two service entities of East-West Railway Company and North-South Railway Company as partition managers as service entities that provide services using partitions set in devices. The figure shows an example of a device usage configuration assuming an organization called the Japan Railways Group as a device manager for registering settings.

Tozai Railway Co., Ltd. sets and registers a plurality of files in its own partition: PM1 set in the user's device. That is, a commuter pass file, a prepaid file, and other files. The partition manager as each service entity can register various files in the partition assigned by the device manager set according to the service provided by itself. However, a file registration ticket (FRT) is required for file setting registration.

Tozai Railway Co., Ltd. functions as a partition manager that manages one partition of the device: PM1Area. Partition: PM1
Area is being managed by Japan Railway Group PRTIssuer by the Japan Railway Group as a device manager.
In accordance with the rules recorded in the partition registration ticket (PRT) issued by the user, authentication, verification, and the like are performed, and the partition registration ticket (PRT) is set by the partition registration ticket (PRT) within the permitted range. And granted to East-West Railway Company.

Tozai Railway Co., Ltd. sets various files in the assigned partition: PM1Area according to the service provided by itself. For example, it is a commuter pass file and a prepaid file, and in a data storage area in the commuter pass file, various data necessary as commuter pass management data such as a commuter pass user name, a use period, and a use section are recorded. In the prepaid file, a user name, a prepaid amount, balance data, and the like are recorded. In this file setting process, FRTIs of East-West Railway
Processing such as authentication and verification is performed according to the rules recorded in the file registration ticket (FRT) issued by the user, and the setting is performed by setting and registering the files within the permitted range recorded in the file registration ticket (FRT). Is done.

The devices in which various files are set are used by the user. For example, a user can use the device by setting the device in a ticket gate provided with a reader / writer as a device access device. For example, a legitimate reader / writer provided for a ticket gate accesses the commuter pass file and reads the use section. Further, the prepaid file is accessed, and the process of updating the balance data in the prepaid file is executed.

Which file in the device is accessed and what processing (read, write, reduce e
Whether to execute tc) is recorded in the service permission ticket (SPT) issued by the service permission ticket (SPT) issuing means (SPT issuer) of the East-West Railway. For example, these tickets are stored in a reader / writer as a legitimate device access device provided for a ticket gate, and processes such as authentication between devices and ticket verification are executed in accordance with rules recorded in the tickets. If the reader / writer as the device access device and the device are valid devices and the use ticket is valid, processing within the permitted range recorded in the service permission ticket (SPT) (ex. Reading and writing of data in the file) ,, Etc.) will be executed.

Partition registration ticket (PRT),
A ticket issuing means (Ticket Issuer) for issuing various tickets such as a file registration ticket (FRT) and a service permission ticket (SPT), and a ticket user (Tick) using the ticket issued by the ticket issuing means.
FIG. 4 shows a general correspondence relationship between E. et User).

The ticket issuing means (Ticket Issuer)
As described with reference to FIG. 1 and others, the partition registration ticket (P
RT), a file registration ticket (FRT), and a service permission ticket (SPT). The ticket user (Ticket User) is a device or means that uses the ticket issued by the ticket issuing means. Specifically, for example, a reader / writer or the like as a device access device that executes processing such as writing and reading data to and from the device. Devices correspond.

As shown in FIG. 4, a ticket user can store and use a plurality of tickets. Also, a configuration in which only a single ticket, for example, a service permission ticket (SPT) that permits execution of only reading of section data of a commuter pass file described with reference to FIG. 3 is stored, and processing of reading section data only is executed. It is also possible to use

For example, in a ticket gate only for reading a commuter pass of a railway company which is a certain service subject (partition manager), a service permission ticket (SP) that permits only the reading of section data of the above-mentioned commuter pass file is provided.
A reader / writer as a device access device storing only T) is set, and section data is read from a device owned by the user. For example, a commuter pass,
The reader / writer as the ticket access device that performs both the prepaid processing is provided with a service permission ticket (SPT) permitting only the reading of the section data of the commuter pass file, and the remaining data reduction processing of the prepaid file. It is also possible to store a service permission ticket (SPT) in which the file is permitted and to execute processing for both the commuter pass file and the prepaid file.

The partition registration ticket (PR
T), a file registration ticket (FRT), and a service permission ticket (SPT), and a ticket user (ex. Reader / writer) that can execute all processes such as partition registration, file registration, and data access in a file. Can also be configured. As described above, the executable process of the ticket user is determined by the ticket applicable to the ticket user.

[A2. Device Configuration] Next, a device having a memory in which a data storage area is divided into a plurality of partitions will be described. FIG. 5 shows a configuration diagram of the device.

As shown in FIG. 5, the device 100 has a CPU (Centra) having a program execution function and an arithmetic processing function.
l, a communication interface 10 having an interface function for communication processing with an external device such as a reader / writer as a device access device.
2, various programs executed by the CPU 101,
For example, a ROM (Read
Only Memory) 103, the load area of the execution program,
In addition, a RAM (Random Access Memory) 104 that functions as a work area in each program process, a cryptographic device that performs an encryption process such as an authentication process with an external device, a generation of a digital signature, a verification process, and a process of encrypting and decrypting stored data. The processing unit 105 stores, for example, an EEPROM (Electrically Erasab) in which the above-described partitions and files are set and stored, and device-specific information including various key data is stored.
le 10)
6. Memory unit 106 (ex. EEPROM) 1
The information stored in 06 will be described in detail later.

FIG. 6 shows the data storage configuration of the memory unit 106. The memory unit is, for example, an EEPROM (Electrically
This is a flash memory which is one form of electrically rewritable nonvolatile memory called Erasable Programmable ROM (Erasable Programmable ROM).

As shown in FIG. 6, in this embodiment,
It has a data storage area of 32 bytes per block and the number of blocks is 0xFFFF, and has a partition area, an unused area, device-specific information, and an in-device partition information area as main areas.

In the partition area, a partition which is a management area by the above-described partition manager is set and registered. Although the memory shown in FIG. 6 shows an example in which a partition has already been set, a newly manufactured device has no partition set and has no partition area. As described above, the partition is a partition registration ticket (PRT) issuing unit (PRT) managed by the device manager.
Issuer) issues a predetermined procedure based on the PRT ticket issued by the partition manager, ie, a partition registration ticket (PRT).
Set in the memory in the device according to the rules set in.

The device-specific information and the in-device partition information area are required when executing device setting registration processing by executing device access information, device manager information, setting partition information, and device access. Key information and the like are stored. Details of these stored information will be described later. The data stored in the device unique information area can be used as data corresponding to IDm as a device unique value applied at the time of mutual authentication described later.

As shown in the figure, the partition area further has one or more file areas, unused areas, partition-specific information, and intra-partition file areas. The file area is an area for storing a file set for each service, for example, for a commuter pass or a prepaid service as described above by a service entity as a partition manager. The unused area is an area in which a file can be further set. The partition-specific information and the file information area in the partition store, for example, information on files in the partition, key information necessary for file access processing, and the like. Details of these stored information will be described later.

[A3. Configuration of Device Manager] Next, the configuration of the device manager will be described with reference to FIG. The device manager is a management entity of a device provided (sold or lent) to a user.

The device manager 200 is a partition that enables partition setting for a device in response to a request from a partition manager serving as a service entity that provides a service using a partition set as a divided area of a memory unit in the device. partition registration ticket to issue a registration ticket (PRT) (PRT) issuing means (PRT Issuer) 210
Having.

Further, the device manager 200 transmits a device-related public key certificate (CERT-DE) corresponding to the device.
V). The device manager 200 receives the public key certificate issuance request from the device, verifies the received issuance request, and after the verification, transmits the certificate issuance request to a certificate authority (CA (DEV): Certificate Authority) 610.
Registration Authority (RA: Registra) that performs processing to transfer to public key certificates and manages issued public key certificates.
It has a function as an Action Authority 220.

As shown in FIG. 7, the device manager 2
The partition registration ticket (PRT) issuance means (PRT Issuer) 210 includes a control means 211 and a database 212. The database 212 stores, as issuance management data of the partition registration ticket (PRT), data for ticket issuance management. Data, for example, the partition manager identifier of the ticket issuance destination, the ticket identifier, the ticket user (ex. Reader / writer, PC, e
tc) Data in which an identifier or the like is associated is stored.

Further, a registration authority (RA: Registration Autho)
rity) 220 has a control unit 221 and a database 222 for managing issuance of a public key certificate. As issuance management data of a public key certificate, for example, a device identifier that has issued the public key certificate, Identifier (serial number)
And the like are stored.

A partition registration ticket (PRT) issuing means (PRT Issuer) of the device manager 200
The control unit 211 of 210 executes a process of issuing a partition registration ticket (PRT) by data communication with the partition manager. In addition, the registration office (R
A: Control means 221 of Registration Authority 220
Executes a process of issuing a public key certificate to the device, and at this time, executes communication with the device and communication with the device manager compatible certificate authority (CA (DEV)) 610. Details of these processes will be described later. Here, the configuration of the control units 211 and 221 will be described with reference to FIG.

Each of the control means 211 and 221 is realized by, for example, a configuration similar to that of a PC as data processing means, and specifically has a configuration as shown in FIG. 8, for example. The configuration of the control means will be described. The control unit 2111 executes a central processing unit (CPU: C
Central Processing Unit). ROM
(Read only Memory) 2112 is a memory that stores an execution processing program such as an encryption processing program. RA
M (Random Access Memory) 2113 is a control unit 211
1 is used as a storage area for execution programs, such as a database management program, a cryptographic processing program, a communication program, and the like, and as a work area in the processing of each of these programs.

The display unit 2114 includes a liquid crystal display device, a CRT
Under the control of the control unit 2111, and displays data at the time of executing various programs, for example, data contents to be processed. The input unit 2115 includes a keyboard and a pointing device such as a mouse, for example.
Commands and data inputs from these input devices are output to the control unit 2111. HDD (Hard Disk Drive)
Reference numeral 2116 stores programs such as a database management program, an encryption processing program, a communication program, and various data.

The drive 2117 is, for example, an HD (Hard D)
isk), magnetic disk such as FD (Floppy Disk), CD
-It has a function of controlling access to various recording media such as an optical disk such as a ROM (Compact Disk ROM), a magneto-optical disk such as a mini disk, and a semiconductor memory such as a ROM and a flash memory. Various recording media such as magnetic disks store programs, data, and the like. The communication interface 2118 functions as an interface for wired or wireless communication such as a network, cable connection, or telephone line, and functions as a communication interface with each entity such as a user device, a partition manager, and a certificate authority.

[A4. Configuration of Partition Manager] Next, the configuration of the partition manager will be described with reference to FIG. The partition manager is a management entity of a partition set in a device provided (sold or lent) to a user.

Using the partition registration ticket (PRT) given by the device manager, the partition manager 300 sets a partition as a divided area in the memory section in the user's device according to the rules recorded in the given PRT. Provide a service using the set partition.

Services are set in the set partition.
It is possible to set a file according to the data.
However, it is necessary to obtain a file registration ticket (FRT) for the file setting process, and to obtain a service permission ticket (SPT) for data access such as reading and writing of data in the file. is there. The file setting and data access processing are executed by a ticket user, specifically, for example, a reader / writer as a dedicated device access device using the ticket.

The partition manager 300 issues a file registration ticket (FRT) issuing means (FR) as a ticket issuing processing means for such a ticket user.
T Issuer) 310 and service permission ticket (S
PT) issuing means (SPT Issuer) 320.

Furthermore, the partition manager 300
Issues a partition-related public key certificate (CERT-PAR) corresponding to each partition of the device. The partition manager 300 receives the public key certificate issuance request from the device, verifies the received issuance request, and verifies the certificate issuance request after the verification.
R): Registration Authority (RA: Registration Authority) that performs processing to transfer to Certificate Authority (620) and manages issued public key certificates.
y) It has the function of 330.

As shown in FIG. 9, the file registration ticket (FRT) issuing means (FRT Issuer) 310 of the partition manager 300 has a control means 311 and a database 312, and the database 312 stores the file registration ticket (FRT). Issuance management data, such as ticket issuance management data, for example, a ticket user (ex. Reader / writer, PC, et
c) Store data in which identifiers, ticket identifiers, etc. are associated.

Further, the service permission ticket (SPT) issuing means (SPT Isss) of the partition manager 300
uer) 320 includes a control unit 321 and a database 32
The database 322 includes, as service management ticket (SPT) issuance management data, data for ticket issuance management, for example, a ticket user (ex. A reader / writer as a device access device, a PC, etc) Stores data in which identifiers, ticket identifiers, and the like are associated.

Further, a registration authority (RA: Registration Autho)
rity) 330 has a database 332 for managing the issuance of public key certificates, and includes, for example, a device identifier, a partition identifier, and an identifier of the public key certificate as public key certificate issuance management data. (Serial number) and the like are stored.

File Registration Ticket (FRT) Issuing Means (FRT Issuer) of Partition Manager 300
The control unit 311 of the user 310 (ex. Reader / writer as a device access device, PC, et.
c), the file registration ticket (F
RT) issuance processing, and the service permission ticket (S
PT) Control means 3 of ticket issuer 320
Reference numeral 21 executes a service permission ticket (SPT) issuance process by data communication with a ticket user (ex. A reader / writer as a device access device, PC, etc). Also, RA (Registration Authori)
The control unit 331 of the ty) 330 executes a process of issuing a public key certificate to the device. At this time, communication with the device, a partition manager compatible certificate authority (CA (PA
R)) Perform communication with 620. Details of these processes will be described later.

The configuration of the control means 311, 321, 331 of the partition manager 300 is the same as that of the device manager described above with reference to FIG. 8, and a description thereof will be omitted.

[0106] [A5. Configuration of Ticket User (Reader / Writer as Device Access Device)] The reader / writer as a device access device sets a partition for a device, sets a file, reads data,
It is configured as a device that executes various processes such as writing, subtracting and adding money data. The processing for the device follows the rules recorded in the partition registration ticket (PRT), file registration ticket (FRT), or service permission ticket (SPT) applied at the time of processing. That is, all processing on the device is limited by these applied tickets.

FIG. 10 shows a configuration example of a reader / writer as a device access device. As shown in FIG. 10, the reader / writer 700 has a CPU (Central Processing Unit) 701 having a program execution function and an arithmetic processing function, and has a device, a ticket issuing unit (Ticket Issuer).
A communication interface 702 having an interface function for communication processing with an external device, a ROM (Read Only Memory) 703 storing various programs executed by the CPU 701, for example, an encryption processing program, a load area of an execution program, RAM (Random Access) functioning as a work area in each program processing
Memory) 704, an encryption processing unit 705 for performing encryption processing such as authentication processing with an external device, generation and verification processing of an electronic signature, encryption and decryption processing of stored data, authentication processing, encryption,
For example, an EEPROM (Electrically Eras) storing various key data for decryption processing and information unique to a reader / writer.
memory section 7 composed of ableProgrammable ROM)
06.

[A6. Public Key Certificate] In using a device having a partitioned memory area of the present invention,
Each entity, ticket issuing means, ticket user,
In data communication between devices, etc., confirm that the data sending side and the data receiving side are mutually legitimate data transmission / reception targets, and then transfer the necessary information. As a technique for realizing this, encryption processing of transfer data, signature generation for data, and verification processing are applied.

The encrypted data can be returned to usable decrypted data (plaintext) by a decryption process according to a predetermined procedure. Data encryption and decryption methods using an encryption key for such information encryption processing and a decryption key for decryption processing are well known in the art.

There are various types of data encryption / decryption methods using an encryption key and a decryption key. One example is a so-called public key encryption method. In the public key cryptosystem, the keys of a sender and a receiver are different, one key is used as a public key that can be used by an unspecified user, and the other key is used as a secret key for keeping secret.
For example, the data encryption key is a public key, and the decryption key is a secret key. Alternatively, it is used in a mode in which the authenticator generation key is a secret key and the authenticator verification key is a public key.

Unlike a so-called common key encryption method that uses a common key for encryption and decryption, in a public key encryption method, a secret key that needs to be kept secret is only required to be held by a specific user. Is advantageous. However, the public key cryptosystem has a slower data processing speed than the common key cryptosystem, and is often used for objects with a small amount of data, such as private key distribution and digital signatures. A representative public key cryptosystem is RSA (Rivest-Shamir-Adleman) cryptosystem. This is a very large two prime number (eg, 150
Digit), and makes use of the difficulty of performing a factorization of a product of two large prime numbers (for example, 150 digits).

In the public key cryptosystem, an unspecified number of public keys can be used, and a certificate for certifying whether the distributed public key is valid, that is, a so-called public key certificate is used. Many methods are used. For example, the user A generates a pair of a public key and a secret key, sends the generated public key to a certificate authority, and obtains a public key certificate from the certificate authority. User A publishes the public key certificate to the public. An unspecified user obtains a public key through a predetermined procedure from a public key certificate, encrypts a document or the like, and sends it to the user A. The user A is a system for decrypting an encrypted document or the like using a secret key. In addition, the user A signs a document or the like using a private key, and an unspecified user obtains a public key from a public key certificate through a predetermined procedure and verifies the signature. .

A public key certificate is a certificate issued by a certificate authority (CA) in a public key cryptosystem. When a user submits his / her ID, public key, etc. to the certificate authority, the public key certificate is issued. The certificate is created by adding information such as the ID and expiration date of the certificate authority on the side and further adding a signature by the certificate authority.

FIG. 11 shows an outline of the format of the public key certificate. An outline of each data will be described. The version number of the certificate indicates the version of the public key certificate format. The serial number of the certificate is a serial number (SN), which is a serial number of a public key certificate set by a public key certificate issuing authority (certificate authority: CA). The signature algorithm (algorithm) and algorithm parameters (parameters) of the signature algorithm identifier field (Signature algorithm Identifier) are fields for recording the signature algorithm of the public key certificate and its parameters. Note that the signature algorithm includes elliptic curve cryptography and RSA. When elliptic curve cryptography is applied, parameters and key length are recorded. When RSA is applied, key length is recorded. The name of the issuing authority (certificate authority: CA) is a format (Distin) in which the issuer of the public key certificate, that is, the name (Issuer) of the public key certificate issuing authority (CA) can be identified.
guished Name). In the validity period of a certificate, a start date and time and an end date and time, which are valid dates of the certificate, are recorded. In the user name (Subject) of the public key certificate, the identification data of the authentication target person who is the user is recorded. Specifically, for example, the ID of the user device,
An identifier such as an ID of the service provider or a category is recorded. User public key field (subject Public K
ey Info) key algorithm (algorithm) and key (subjec)
t Public key) is a field for storing a key algorithm as the user's public key information and the key information itself. In the option area, user attribute data and other optional data associated with issuance and use of the public key certificate are recorded. As attribute data, a device manager code (DMC) and a partition manager code (PMC) are recorded as group information of a user. Here, the user is a user of the public key certificate, and is, for example, a device manager, a partition manager, a ticket user, a ticket issuing unit, or a device.

[0115] In the option area, categories indicating ticket users, ticket issuing means, entities such as devices, device managers, and partition managers, and device types are recorded as category information.

When the device manager also serves as a partition registration ticket issuing means (PRT Issuer), a partition registration ticket issuing means code (PRTIC: PRT Issuer Code) described later can be set as a device manager code (DMC). ,Also,
If the partition manager also serves as a file registration ticket issuing unit and a service permission ticket issuing unit,
File registration ticket issuing means code (FRTIC: FR
T Issuer Code) and a service permission ticket issuing means code (SPTIC: SPT Issuer Code) can be set as a partition manager code (PMC). These codes are used for each ticket (PRT, F
RT, SPT, etc.).

Further, a unique code different from the device manager code (DMC) and the partition manager code (PMC) may be assigned to each ticket issuing means. In this case, the code is assigned by the code management organization described above.

The signature of the issuing authority is the public key certificate issuing authority (C
A) is a digital signature executed on the data of the public key certificate using the private key of A), and the user of the public key certificate is verified using the public key of the public key certificate issuing authority (CA). To check whether the public key certificate has been tampered with.

A method for generating a digital signature using a public key cryptosystem will be described with reference to FIG. The processing shown in FIG. 12 is performed by EC-DSA ((Elliptic Curve Digital Signa
3 is a flow of a process for generating digital signature data using the tureAlgorithm) and IEEE P1363 / D3). Here, Elliptic Curve Cryptography is used as public key cryptography.
(Hereinafter, referred to as ECC) will be described. Note that, in the data processing device of the present invention, in addition to elliptic curve cryptography, for example, RS
A cipher ((Rivest, Shamir, Adleman) etc. (ANSI X9.3
1)) can also be used.

The steps in FIG. 12 will be described. In step S1, p is a characteristic, and a and b are coefficients of an elliptic curve (elliptic curve: y ² = x ³ + ax + b, 4a ³ + 27b ² ≠ 0
(Mod p)), G is the base point on the elliptic curve, r
Is the order of G, and Ks is a secret key (0 <Ks <r). In step S2, the hash value of the message M is calculated, and f = Hash (M).

Here, a method of obtaining a hash value using a hash function will be described. The hash function is a function that receives a message, compresses the message into data having a predetermined bit length, and outputs the data as a hash value. With a hash function, it is difficult to predict the input from the hash value (output). When one bit of the data input to the hash function changes, many bits of the hash value change, and the same hash value It has a feature that it is difficult to find different input data. As the hash function, MD4, MD5, SHA-1, or the like may be used, or DES-CBC may be used. In this case, the final output value MAC (check value: IC
V) corresponds to a hash value.

Subsequently, in step S3, a random number u (0 <u
<R) is generated, and a coordinate V (Xv, Yv) obtained by multiplying the base point by u is calculated in step S4. The addition and doubling on the elliptic curve are defined as follows.

[0123]

## EQU1 ## P = (Xa, Ya), Q = (Xb, Yb), R = (Xc, Y
c) = P + Q, when P ≠ Q (addition), Xc = λ ² −Xa−Xb Yc = λ × (Xa−Xc) −Ya λ = (Yb−Ya) / (Xb−Xa) When P = Q (doubled), Xc = λ ² −2Xa Yc = λ × (Xa−Xc) −Ya λ = (3 (Xa) ² + a) / (2Ya)

[0124] While slow u multiplication to calculate the (velocity of the point G with these, .G performing the most straightforward calculation method as follows: a 2 × G, 4 × G · · calculates, 2 u 2 ⁱ × G (where G is i
(I is a bit position counted from the LSB of u)).

In step S5, c = Xvmod r is calculated. In step S6, it is determined whether or not this value becomes 0. If not, d = [(f + cKs) in step S7.
/ U] mod r is calculated, and it is determined whether or not d is 0 in step S8. If d is not 0, c and d are output as digital signature data in step S9. Suppose r
Is 160 bits long, the digital signature data is 320 bits long.

If c is 0 in step S6, the flow returns to step S3 to generate a new random number again. Similarly, if d is 0 in step S8, the process returns to step S3 to generate a random number again.

Next, a method of verifying an electronic signature using a public key cryptosystem will be described with reference to FIG. Step S11
Where M is a message, p is a characteristic, a and b are coefficients of an elliptic curve (elliptic curve: y ² = x ³ + ax + b, 4a ³ + 27b ² ≠ 0
(Mod p)), G is the base point on the elliptic curve, r
Is the order of G, G and Ks × G are the public keys (0 <Ks <
r). In step S12, it is verified whether the digital signature data c and d satisfy 0 <c <r and 0 <d <r. If this is satisfied, in step S13, the message M
Is calculated, and f = Hash (M) is set. Next, h = 1 / d mod r is calculated in step S14, and h1 = fh mod r and h2 = chmod in step S15.
Calculate r.

In step S16, the h already calculated
Using 1 and h2, the point P = (Xp, Yp) = h1 × G
+ H2 · Ks × G is calculated. Since the digital signature verifier knows the base points G and Ks × G, FIG.
The scalar multiplication of the point on the elliptic curve can be performed in the same manner as in step S4 of the above. Then, in a step S17, it is determined whether or not the point P is an infinity point.
(Actually, the determination of the point at infinity is made in step S16. That is, P = (X, Y) and Q = (X, −
When Y) is added, λ cannot be calculated, and it is known that P + Q is a point at infinity). Xp in step S18
The mod r is calculated and compared with the digital signature data c. Finally, if the values match, the process proceeds to step S19, where it is determined that the electronic signature is correct.

When it is determined that the electronic signature is correct, it is understood that the data has not been falsified and that the person holding the private key corresponding to the public key has generated the electronic signature.

If the digital signature data c or d does not satisfy 0 <c <r and 0 <d <r in step S12, the flow advances to step S20. Step S17
In step S2, when the point P is a point at infinity,
Go to 0. Furthermore, in step S18, Xp
The process also proceeds to step S20 when the value of mod r does not match the digital signature data c.

If it is determined in step S20 that the electronic signature is incorrect, whether the data has been falsified
It can be seen that the person holding the private key corresponding to the public key did not generate the electronic signature.

The device in the system of the present invention is a public key certificate (CERT-DEV) corresponding to the device issued to the device via the management registration authority of the device manager.
Is stored in the device, and a public key certificate (CE) corresponding to the partition issued to the partition of the device through the management registration authority of the partition manager.
RT-PAR) in each partition of the device. These public key certificates are processed for a device, that is, a partition registration setting process applying a partition registration ticket (PRT) and a file registration ticket (F
RT) to apply file registration and data processing to apply a service permission ticket (SPT), mutual authentication between a ticket user (ex. A reader / writer as a device access device) and a device, signature generation, verification processing, etc. Applied to Specific examples of these processes will be described later using a flow.

[A7. Data Stored in Memory Unit of Device] Next, data stored in a device having a partitioned memory area according to the present invention will be described.
As described above with reference to FIG.
It has a memory unit composed of an EPROM, and has a partition area, an unused area, device-specific information, and an in-device partition information area as main areas. The data stored in each of these areas will be sequentially described below with reference to the drawings.

(A7.1. Device Specific Information and Intra-device Partition Information Area) First, each data of the device specific information and the in-device partition information area will be described. The device-specific information and the in-device partition information area include information on a device manufacturing entity, information on a device manager, setting partition information, and key information required when executing access to the device and executing partition setting registration processing. Is stored.

FIG. 14 shows a manufacturing information block (Manufactur
e Information Block). The numerical value of each area indicates the number of bytes. As described with reference to FIG. 6, in the configuration of the present embodiment, one block is composed of 32 bytes. The gray part in the figure may be encrypted data or may not be encrypted.

Manufacturing information block (Manufacture Informat
ion Block) stores the following data. * Writable Flag: Flag to determine whether writing to the block is permitted (ex.0xffff: Write permitted, others: Write disabled) * Manufacture Code: Card manufacturing plant identification number * Manufacture Equipment Code: Card manufacturing line number * Manufacture Date: Date of card production. For example, 2001 1
Set the month 1 as 0x0000 * Manufacture Serial Number: Card manufacturing serial number * Device Vender Code: IC chip supplier company number * Device Code: IC chip model number * Device Parameter: Other parameters

Since the information written in these blocks is unique, IDm is defined as a device unique identifier based on the information. The device (Devi
ce) The unique identifier is the manufacturing information block (Manufacture Info
It is also possible to adopt a configuration in which the information is obtained from the entire information written in the rmation block, a part of the written information, or operation data obtained based on the written information.

FIG. 15 shows a device management information block (De
vice Management Information Block). Device Management Information Block (Device Management
Information Block) stores the following data.

* Writable Flag: flag for determining whether writing to the block is permitted (ex. 0xffff: writing permitted, others: writing not allowed) * DMC (Device Manager Code): Device manager code (DM: Device Manager) Identification number * DMC Version: Device manager code (DMC)
Version. For example, it is used as a comparison condition when updating the DMC. * Total Block Number in Device: Device
Total number of blocks in the block * Free Block Number in Device: Device
Number of free blocks in partition * Partition Number: Number of currently registered partitions (Partition) * Pointer of Free Area: Pointer of free area

FIG. 16 shows the data structure of a public key device key definition block (Device Key Definition Block (PUB)). Public key device key definition block (Device K
The following data is stored in the eyDefinition Block (PUB).

* PUB_CA (DEV) Pointer: A certificate authority corresponding to a device manager (CA (DEV)) that issues a public key certificate via a registration authority under the jurisdiction of the device manager.
* PUB_CA (DEV) Size: Size of the public key of the CA (DEV) * PRI_DEV Pointer: Pointer to the block where the private key of the device is stored * PRI_DEV Size: Size of the private key of the device (Device) * PARAM_DEV Pointer: Pointer to the block in which the public key parameter of the device (Device) is stored * PARAM_DEV Size: Size of the public key parameter of the device (Device) * CERT_DEV Pointer: Pointer to the block storing the public key certificate of the device (Device) issued by the CA (DEV) * CERT_DEV Size :: Public key of the device (Device) issued by the CA (DEV) Certificate size * CRL_DEV Pointer: Pointer to the block where the revocation list (Revocation List) of the device (Device) is stored * CRL_DEV Size: Device (Devi) ce) Revocation List size * PRTIC (PRT Issuer Category): Partition registration ticket (PRT) issuer category * PRTIC Version: Partition registration ticket (PR
T) Version of Issuer Category (PRTIC) * DUTIC_DEV (DUT Issuer Category): Issuer Category of Data Update Ticket (DUT) * DUTIC_DEV Version: Issuer of Data Update Ticket (DUT)
Version of

The revocation list in the above data is a list of unauthorized devices, for example, a device exclusion list issued by the administrator of the device distribution system, and is a list of identification data of unauthorized devices. is there. If the device set in the reader / writer as the device access device is a device described in the revocation list, measures such as stopping the processing are taken.

For example, when always distributing the latest revocation list to a reader / writer as all device access devices executing a process for a device and executing a process for a device, executing or stopping the process with reference to the list Is determined. Alternatively, the latest revocation list is browsed via a network by a communication function of a reader / writer as a device access device to acquire unauthorized device information described in the list, and execution or stop of processing is determined. Specific processing using the revocation list will be described later in the description using the flow.

[0144] Further, the data update ticket in the above data (DUT: Data UpdateTicket) is the access restriction ticket for limiting allow updating when performing update processing of various data stored in the device Yes, similar to the above-described PRT, FRT, and SPT tickets, this ticket records an access rule for the device. This data update ticket (DU
T: Data Update Ticket) will be described in more detail later.

FIG. 17 shows the data structure of a common key device key definition block (Device). Common key system device key definition block (Device
The following data is stored in the KeyDefinition Block (Common)).

* Mkauth_DEV_A Pointer: Pointer of master key for bidirectional individual key authentication (MKauth_DEV_A) * Mkauth_DEV_A Size: Master key for bidirectional individual key authentication
(MKauth_DEV_A) size * Kauth_DEV_B Pointer: Bidirectional individual key authentication key (Kauth_DEV
DEV_B) pointer * Kauth_DEV_B Size: Two-way individual key authentication key (Kauth_DEV
_B) size * Kprt Pointer: Partition registration ticket (PR
Pointer to the block in which the T) MAC verification key (Kprt) is stored * Kprt Size: Partition registration ticket (PRT)
* Kdut_DEV1-4 Pointer: Pointer to the block where the MAC verification key (Kdut) of the data update ticket (DUT) is stored * Kdut_DEV1-4 Size: Data update ticket (DUT) ) Size of the MAC verification key (Kdut) * IRL_DEV Pointer: Pointer to a block in which the device ID (Device ID) of the unauthorized device is stored as a revocation list (Revocation List) of the device (Device) * IRL_DEV Size : Size of Revocation List of Device

The method of two-way individual key authentication and MAC (Message Authenticate Code) verification processing shown in the above data will be described in detail later. Also, Kdut_D
There are four types of EV, (Kdut_DEV1, Kdut_DEV2), (Kdut_D
Used for EV3, Kdut_DEV4) pair. For example, Kdut_DEV
1 and 3 are used for MAC generation, and Kdut_DEV2 and 4 are used for encryption.

FIG. 18 shows a device key area (Device Key A).
rea). Device key area (Device Ke
y Area) stores the following data. Note that version information is also stored in each storage key of the device key area. When the key is updated, the version is also updated.

* IRL_DEV: exclusion device (Device), exclusion device (reader / writer as device access device,
Revocation list (Revocation) in which identifiers (ID) of ticket users such as PCs and ticket issuing means) are registered.
List (Device ID)) * CRL_DEV: Public key certificate identifier (ex. Serial number: SN) of excluded device (Device), excluded device (reader / writer as device access device, ticket user such as PC, ticket issuing means) List (Revocation List (Certificate)) with registered * Kdut_DEV1: Data Update Ticket (DUT)
* Kdut_DEV2: Data update encryption key * Kdut_DEV3: Data update ticket (DUT)
* Kdut_DEV4: Data update encryption key * Kprt: MA of partition registration ticket (PRT)
C verification key * CERT_DEV: Device (Device) issued by CA (DEV) that issues a public key corresponding to the device manager
* PRI_DEV: Private key of the device * PARAM_DEV: Public key parameter of the device * PUB_CA (DEV): Public key of the certification authority CA (DEV) that issues the public key corresponding to the device manager * Kauth_DEV_B: Common key for two-way individual key authentication * MKauth_DEV_A: Master key for two-way individual key authentication

The device key area (Device K) shown in FIG.
ey Area) stores Kauth_DEV_A: a common key for two-way individual key authentication, and MKauth_DEV_B: a master key for two-way individual key authentication. These keys are used when there is no request for the device to perform a common key authentication process. May not be stored, and Kprt: partition registration ticket (P
The RT) MAC verification key may not be stored if the device does not execute the ticket verification process.

Further, IRL_DEV: Excluded device (Device)
Revocation List (Device ID) in which the device identifier (ID) of the device is registered, CRL_DEV: Revocation List (Revocation) in which the public key certificate identifier (ex. Serial number: SN) of the excluded device (Device) is registered Regarding the List (Certificate), if there is no revoked (excluded) device, or if the revocation list is acquired using another source, the revocation list may not be stored. Good.

FIG. 19 shows the data structure of a partition definition block.
Partition Definition B
lock) stores the following data.

* PMC (Partition Manager Code): Code (PMC) assigned to the partition manager. For example a number. * PMC Version: Partition manager code (P
MC) version * Partition Start Position: Partition (Partit
ion) Storage start address * Partition Size: Partition size

The above is the device specific information of the memory section of the device and each data of the in-device partition information area.

(A7.2. Partition area) Next,
Each data of the partition area will be described. The partition area is a management area of the partition manager. As described above, based on the PRT ticket issued by the partition registration ticket (PRT) issuing means (PRT Issuer) managed by the device manager, the partition manager as each service entity performs a predetermined procedure, that is, a partition registration ticket (PRT). Set the memory in the device according to the set rules. Hereinafter, the data configuration of the partition area will be described.

FIG. 20 shows the data structure of a partition management information block. Partition management information block (Part
The following data is stored in the partition management information block).

* PMC (Partition Manager Code): Number of the partition (Partition) holder * PMC Version: Partition manager code (P
MC) version * Total Block Number in Partition: Total number of blocks in partition (Partition) * Free Block Number in Partition: Number of free blocks in partition (Partition) * Pointer of Free Area: Partition (Partitio)
Pointer of unused area in n) * File Number: Number of files (File) currently registered in the partition

FIG. 21 shows the data structure of a public key system partition key information block (Partition Key Definition Block (PUB)). The following data is stored in the public key system partition key information block (Partition Key Definition Block (PUB)).

* PUB_CA (PAR) Pointer: Pointer to a block in which the public key of the certification authority CA (PAR) that issues the public key certificate via the registration authority of the partition manager is stored. * PUB_CA (PAR) Size : The size of the public key of the certification authority CA (PAR) * PRI_PAR Pointer: Pointer to the block storing the private key of the partition (Partition) * PRI_PAR Size: The size of the private key of the partition (Partition) * PARAM_PAR Pointer: Partition pointer * PARAM_PAR public key parameters to the block, which is stored in the (partition) size: partition (partition) public key parameters of size * CERT_PAR pointer of: public key of the partition that issued the certificate authority CA (PAR) is (partition) Pointer to the block where the certificate is stored * CERT_PAR Size: The party issued by the CA (PAR) * CRL_PAR Pointer: Pointer to the block that stores the revocation list (Revocation List) of the partition (Partition) * CRL_PAR Size: Revocation list (Revocation) of the partition (Partition) List) * FRTIC (FRT Issuer Category): File registration ticket (FRT) issuer category * FRTIC Version: File registration ticket (FRT) issuer category (FRTIC) version * DUTIC_PAR (DUT Issuer Category): Data update ticket (DUT) Issuer Category * DUTIC_PAR Version: Version of Data Update Ticket (DUT) Issuer Category (DUTIC)

[0160] FIG. 22, the common key system partition key information block (Partition Key Definition Block (Common))
Shows the data structure. The following data is stored in the common key system partition key information block (Partition Key Definition Block (Common)).

* Mkauth_PAR_A Pointer: Pointer of master key for bidirectional individual key authentication (MKauth_PAR_A) * Mkauth_PAR_A Size: Master key for bidirectional individual key authentication
(MKauth_PAR_A) size * Kauth_PAR_B Pointer: Two-way individual key authentication key (Kauth_PAR
PAR_B) pointer * Kauth_PAR_B Size: Two-way individual key authentication key (Kauth_PAR
_B) size * Kfrt Pointer: File registration ticket (FRT) M
Pointer to the block where the AC verification key (Kfrt) is stored * Kfrt Size: MA of file registration ticket (FRT)
Size of C verification key (Kfrt) * Kdut_PAR1-4 Pointer: Pointer to block where MAC verification key (Kdut) of data update ticket (DUT) is stored * Kdut_PAR1-4 Size: Data update ticket (DUT) Size of the MAC verification key (Kdut) * IRL_PAR Pointer: Revocation list (Re) storing the ID of the device excluded from the partition (Partition)
Pointer to the block where the Revocation List-Device ID is stored * IRL_PAR Size: Size of the revocation list (Revocation List-Device ID) of the partition (Partition)

The method of two-way individual key authentication and MAC (Message Authenticate Code) verification processing shown in the above data will be described in detail later. Also, Kdut_P
There are four types of AR, (Kdut_PAR1, Kdut_PAR2), (Kdut_P
AR3, Kdut_PAR4) are used in pairs. For example, Kdut_PAR
1 and 3 are used for MAC generation, and Kdut_PAR2 and 4 are used for encryption.

FIG. 23 shows a partition key area (Partit
3 shows a data configuration of an ion key area. The following data is stored in the partition key area (Partition Key Area). The partition key area (Partition Key Ar
Version information is also stored in each storage key of ea). When the key is updated, the version is also updated.

* IRL_PAR: Revocation List (Revocation List (R)) in which an identifier (ID) of a partition access exclusion device (Device), an exclusion device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing means) is registered. Device ID)) * CRL_PAR: Partition access exclusion device (Dev
ice), the public key certificate identifier (ex. serial number: S) of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit)
N) registered revocation list (Revocation Lis
t (Certificate) * Kdut_PAR1: Data update ticket (DUT)
MAC verification key * Kdut_PAR2: Data update encryption key * Kdut_PAR3: Data update ticket (DUT)
* Kdut_PAR4: Data update encryption key * Kfrt: File registration ticket (FRT) MAC verification key * CERT_PAR: Public key certificate of the partition (Partition) issued by the certification authority CA (PAR) * PRI_PAR : Private key of partition * PARAM_PAR: Public key parameter of partition * PUB_CA (PAR): Public key of certificate authority CA (PAR) * Mkauth_PAR_A: Master key for bidirectional individual key authentication * Kauth_PAR_B: Bidirectional Common key for individual key authentication

FIG. 24 shows a file definition block (FD)
B: File Definition Block). The following data is stored in the file definition block.

* File ID: File (File) identification name * File Start Position: File (File) start address * File Size: File (File) size * SPTIC (SPT Issuer Category): Service permission ticket (SPT) issuer category * SPTIC Version: Service permission ticket (SPT) issuer category (SPTIC) version * File Structure Type Code: File structure type (Fi
le Structure Type) code * Acceptable Authentication Type: Indicates the acceptable authentication type. File Structure Type
And the bits of this field (up to 16 in this example) correspond to the access mode defined for. Details will be described below. * Acceptable Verification Type: Indicates the acceptable verification type. For each file structure type, the defined access mode and each bit of this field (up to 16 in this example) correspond. Details will be described below. * Kspt: Key for MAC verification of service permission ticket (SPT) (Kspt)

The above-mentioned acceptable authentication type (Acceptable Authe
ntication Type) for each file structure type (File Str
ucture Type) is an allowable authentication type set so that each bit of this field (up to 16 in this example) corresponds to the access mode defined for the corresponding access mode. If the bit corresponding to the mode is set to 1, it is assumed that the public key authentication has been completed and executed unless the authentication is completed. Thus, when executing a command having a higher importance (for example, payment processing), public key authentication is obligatory and security can be ensured. The same control is possible by using a ticket, but the allowable authentication type (AcceptableAuthenticati
Unlike the ticket, the “on Type” is stored in the device as a part of a file definition block (FDB), so that this information is not changed after the file is generated. Therefore, by using this when it is desired to give a strong constraint that never changes the allowable authentication type, it is possible to provide a minimum guarantee of security.

In addition, the above-mentioned allowable verification type (Acceptable V
erification Type is the file structure type (File S
An allowable verification type is set so that each bit (in this example, up to 16 bits) of this field corresponds to the access mode defined with respect to (tructure Type). For example, when an access mode is executed, If the bit corresponding to the mode is set to 1, it is assumed that the ticket is not executed unless the ticket verification by the public key method is completed. In this example, since each field is made up of 2 bytes, only a maximum of 16 access modes can be associated with each other. However, by increasing the field size as necessary, it is possible to adopt a configuration in which more commands are associated with each other. it can.

In the configuration of the present embodiment, when the allowable authentication type (Acceptable Authentication Type) and the allowable verification type (Acceptable Verification Type) are set to “1”, the setting that requires authentication or verification of the public key method is required. However, these fields are configured in units of 2 bits, and when the value is “11”, the public key method, when the value is “01”, the common key method, “00”, “10”
In this case, the setting may be finely divided, such as allowing either the public key method or the common key method.

The file structure type (Fi
le Structure Type) is a code indicating the structure of a file generated in the partition. FIG. 25 shows an example of the correspondence between the file structure and the code.

The file structure includes various structures (File Structure) shown in FIG.
~ 0007 is assigned. The meaning of each structure is shown below.

* Random: Data having this file structure is a file from which all reading and writing can be performed at random. * Purse: Data having this file structure is money amount information data, and is a data file that can be subjected to value change processing such as subtraction (Sub) and addition (Add). * Cyclic: Data with this file structure is circular (Cycl
ic) is a file structure in which data can be written. * Log: Data having this file structure is a log data file, which is a record information file for each data processing information. * Key: Indicates that the data file having this file structure is a key information file. * Compound file: Compound structure of the above various file structures (E
x. Purse and Log). Different codes (0006: composite file 1, 0007: composite file 2 in the figure) are assigned to the composite file according to the combination pattern.

The data stored in the memory section of the device has been described above. Specific processing using these data will be described later.

[A8. Data Format of Each Ticket] As described above, a valid ticket issuing means (Ticket
Issuer) issued partition registration ticket (P
RT (Partition Registration Ticket), a valid ticket issuing means (Ticket Issue)
r) issued a file registration ticket (FRT: File Re
gistration ticket) and a service permission ticket (SPT: Service Perm) issued by a valid ticket issuer (Ticket Issuer) for access to each file.
ission Ticket). Also, as described briefly above in the data description section of the memory section of the device,
A data update ticket (DUT) is required for updating the device storage data.

Each of these tickets is constituted by a data string in which an access rule for a device is described as binary data. The ticket is transmitted from the ticket user, for example, a reader / writer as a device access device to the device in accordance with the processing for the device. The device that has received the ticket executes the ticket validity verification process, and if the device is successfully verified, various processes (ex. Partition generation, file generation, data access) are executed according to the rules recorded in the ticket. . Hereinafter, the data format of each of these tickets will be described.

(A8.1. Partition Registration Ticket (PRT)) Partition Registration Ticket (PRT: Pa
rtition Registration Ticket) is an access control ticket applied at the time of partition setting registration processing for a device. A ticket user (ex. Reader / writer as a device access device) under the control of the partition manager uses a PRT issued by a ticket issuer (Ticket Issuer) under the control of a valid device manager and according to the procedure recorded in the PRT. By accessing, the partition can be set within the restrictions recorded in the PRT.

FIG. 26 shows a partition registration ticket (P
RT: Partition Registration Ticket (RT) data format. Partition registration ticket (PR
T: Partition Registration Ticket) stores data described below.

* Ticket Type: Type of ticket. * Format Version: Format version of ticket (Ticket) * Ticket Issuer: Identifier of device manager (= D
MC) * Serial Number: Serial number of ticket (Ticket) * Size of Ticket: Size of ticket (Ticket) * Authentication Flag: Whether mutual authentication with device is necessary in the process of using ticket (Ticket) Flags that indicate * Ticket User's affiliation (Group): Ticket (Ticket) user's affiliation * Authentication Type: Type of mutual authentication of device (Device) (Public key authentication or Common key authentication, or any of them is possible (Any )) * Ticket User identifier: Identification data (category or identifier) that identifies the ticket user. This field is linked with [Authentication Type], and when [Authentication Type] is public key authentication: An identification name (DN: Distinguished Name) or a category (Category) or a serial number (SN) is stored. In the case of common key authentication, an authentication ID is stored. If authentication is not required, storage is not mandatory. * PMC: Partition Manager code (Partition Ma
nager Code) as the partition definition block (Pa
rtition Definition Block) * PMC Version: Partition manager code (P
MC) version * Operation Type: Specify whether to create or delete a Partition (Generate / Delete) * Partition Size: Size of Partition * Integrity Check Type: Validity of Ticket Type of publicity verification value (Public key method (Public) / Common key method (Commo
n)) * Integrity Check Value: Validity verification value of ticket (Public key method: Signature, Common key method: MAC)

Note that the partition registration ticket (PR
T) Ticket (Tick) issued by the issuing means (PRT Issuer)
et) to the ticket user, in the case of the public key method, a partition registration ticket (PRT)
Public key certificate (CERT_PRTI) of issuing means (PRT Issuer)
Also send it together. Public key certificate (CE
The attribute of (RT_PRTI) is the PRT issuing means (P
RT Issuer) (PRTIC).

In the [Authentication Type] in which the type of mutual authentication of the device (Device) is recorded (public key authentication or common key authentication, or any of them is possible (Any)), the mutual authentication using a ticket is executed. The authentication type to be recorded is recorded. Specifically, as will be described in detail later, one of device authentication and partition authentication,
Alternatively, information indicating whether to execute both types of authentication, and whether to execute the public key method or the common key method, or whether any type of authentication is possible is recorded.

In the [Integrity Check Value] field for recording the validity verification value (public key method: Signature, common key method: MAC) of the ticket (Ticket),
In the case of the public key method, a signature based on the secret key of the partition registration ticket issuing means (PRT Issuer) (FIG. 12)
Is generated and stored. The device manager itself issues a partition registration ticket (PRT Issue)
In the case of r), a signature is generated using the secret key of the device manager. At the time of the signature verification process (see FIG. 13), the corresponding CA (DEV) public key is used. Therefore, it is necessary for the device that executes the ticket verification to obtain the public key (public key certificate) of the partition registration ticket issuing means (PRT Issuer) (ex. Device manager) upon receipt of the ticket or in advance.

After verifying the public key certificate (CERT_PRTI) of the partition registration ticket (PRT) issuing means (PRT Issuer), the partition registration ticket (PRT) issuing means (PRT) extracted from the public key certificate (CERT_PRTI).
Issuer) public key to ICV (Integrity Check Valu
e) Signature verification becomes possible. These processes will be described later using a flow.

(A8.2. File Registration Ticket (FR
T)) File Registration Ticket (FRT: File Registrat)
ion ticket) is an access control ticket applied when setting and registering a file in the partition set for the device. Ticket issue means under a valid partition manager
Using the FRT issued by r) and accessing the device by a ticket user (ex. a reader / writer as a device access device) in accordance with the procedure recorded in the FRT, setting a file within the restrictions recorded in the FRT. Can be.

FIG. 27 shows a file registration ticket (FRT:
File Registration Ticket). File Registration Ticket (FRT: File Registratio)
n Ticket) stores data described below.

* Ticket Type: type of ticket (Ticket) * Format Version: format version of ticket (Ticket) * Ticket Issuer: identifier of partition manager (= PMC) * Serial Number: serial number of ticket (Ticket) * Size of Ticket: Ticket (Ticket) size * Authentication Flag: Flag indicating whether or not mutual authentication with the device (Device) is required in ticket (Ticket) use processing * Ticket User's affiliation (Group): Ticket (Ticket) use * Authentication Type: Mutual authentication type of device (Public key authentication or symmetric key authentication, or any of them is possible (Any)) * Ticket User identifier: Identifies ticket user Identification data (category or identifier) This field is linked with [Authentication Type], and [Authentication Type] is public key authentication. In the case of, the identification name (DN: Distinguished Name) or the category (Category) or the serial number (CN) is stored. In the case of the common key authentication, the authentication ID is stored. If authentication is not required, storage is not mandatory. * SPTIC: Service permission ticket issuing means code * SPTIC Ver: Service permission ticket issuing means code (SPTIC) version * File ID: File generated in partition (Fil
e) Identifier (ID) * Operation Type: File creation or deletion specification
(Generate / Delete) * File Size: Size of generated file (File) * File Structure: File structure of generated file (File) * Acceptable Authentication Type: Defined by this ticket Bit string indicating the type of mutual authentication (either public key, public key, or secret key is possible) required to execute the access mode for the file * Acceptable Verification Type: The access mode for the file defined by this ticket A bit string indicating the type of service permission ticket (SPT) verification required for execution (either a public key method, a public key, or a common key is possible) * Kspt_Encrypted: File definition block (File Defin
service permission ticket (S
Data Kfrt (Kspt) obtained by encrypting the MAC verification key Kspt of the PT with the MAC verification key Kfrt of the file registration ticket of the partition * Integrity Check Type: Type of the validity verification value of the ticket (Ticket) (public key method (Public) / Common key method (Commo
n)) * Integrity Check Value: Validity verification value of ticket (Public key method: Signature, Common key method: MAC)

The ticket (Ticket) issued by the file registration ticket (FRT) issuing means (FRT Issuer)
Is transmitted to the ticket user, in the case of the public key method, the public key certificate (CERT_FRTI) of the file registration ticket (FRT) issuing means (FRT Issuer) is also transmitted. Public key certificate of FRT issuing means (CERT_FRT
The attribute (I) of the file registration ticket (F)
RT) It matches the identifier (FRTIC) of the issuing means (FRT Issuer).

[Authentication Type] in which the type of mutual authentication of the device (Device) is recorded (public key authentication or common key authentication, or any of them is possible (Any)) is executed as mutual authentication using a ticket. The authentication type to be recorded is recorded. Specifically, as will be described in detail later, one of device authentication and partition authentication,
Alternatively, information indicating whether to execute both types of authentication, and whether to execute the public key method or the common key method, or whether any type of authentication is possible is recorded.

[0188] In the [Integrity Check Value] field for recording the validity verification value (public key method: Signature, common key method: MAC) of the ticket (Ticket),
In the case of the public key method, a signature (see FIG. 12) based on the secret key of the file registration ticket issuing means (FRT Issuer) is generated and stored. The partition manager itself is a file registration ticket issuing means (FRT issue
When r) is also used, a signature is generated using the private key of the partition manager. In the signature verification process (see FIG. 13), the public key of the file registration ticket issuing unit is used. Therefore, the device that executes the ticket verification needs to obtain the public key (public key certificate) of the file registration ticket issuing means (FRT Issuer) (ex. Partition manager) upon receipt of the ticket or in advance.

After verifying the public key certificate (CERT_FRTI) of the file registration ticket (FRT) issuing means (FRT Issuer), the file registration ticket (FRT) issuing means (FRT Issuer) extracted from the public key certificate (CERT_FRTI) With this public key, signature verification of an ICV (IntegrityCheck Value) can be performed. These processes will be described later using a flow.

(A8.3. Service permission ticket (SP
T)) Service permission ticket (SPT: Service Permis)
sion ticket) is an access control ticket that is applied when accessing each data in the partition set for the device and executing data read, data write, subtraction of money amount, addition, etc. is there. SP issued by a ticket issuer under the valid partition manager
By using T to access a device by a ticket user (ex. A reader / writer as a device access device) according to a procedure recorded in the SPT, data processing can be performed within the restrictions recorded in the SPT.

The service permission ticket (SPT: Se
The rvice permission ticket) includes a format that permits access to only one file among files set in the partition and a format that permits access to a plurality of files. Each format will be described.

FIG. 28 shows a service permission ticket (SPT: Servic) in the form of permitting access to only one of the files set in the partition.
e Permission Ticket).
Service Permission Ticket (SPT)
icket) stores data described below.

* Ticket Type: Type of ticket. * Format Version: Format version of ticket (Ticket) * Ticket Issuer: Identifier of partition manager (= PMC) * Serial Number: Serial number of ticket (Ticket) * Size of Ticket: Size of ticket (Ticket) * Authentication Flag: Ticket Flag indicating whether mutual authentication with the device (Device) is necessary in the use processing of (Ticket) * Affiliation of Ticket User (Group): Affiliation of ticket (Ticket) user * Authentication Type: Mutual of device (Device) Authentication type (public key authentication or symmetric key authentication, or any of them is possible (Any)) * Ticket User identifier: Identification data (category or identifier) that identifies the ticket user. Authentication Type], and if [Authentication Type] is public key authentication: Distinguished Name (DN) Gori (the Category) or serial number (CN) is stored, when the common key authentication: authentication ID is stored. If authentication is not required, storage is not mandatory. * File ID: Access file (Fil
e) Identifier (ID) * File Access Mode: File (File
le) Access Mode (Access Mode) * Integrity Check Type: Type of validity verification value of ticket (Ticket) (Public key method (Public) / Common key method (Commo)
n)) * Integrity Check Value: Validity verification value of ticket (Public key method: Signature, Common key method: MAC)

The ticket (Ticket) issued by the service permission ticket (SPT) issuing means (SPT Issuer)
Is transmitted to the ticket user, in the case of the public key method, the public key certificate (CERT_SPTI) of the service permission ticket (SPT) issuing means (SPT Issuer) is also transmitted. Public key certificate of the SPT issuing means (CERT_SPT
The attribute of (I) is (SPT) issuing means (SPT)
Issuer) identifier (SPTIC).

In a configuration in which the service permission ticket (SPT) issuing means (SPT Issuer) also serves as the partition manager, the code of the service permission ticket (SPT) issuing means (SPT Issuer) is set as a partition manager code (PMC). It is possible.

[Authentication Type] in which the type of mutual authentication of the device (Device) is recorded (public key authentication or common key authentication, or any of them is possible (Any)) is executed as mutual authentication using a ticket. The authentication type to be recorded is recorded. Specifically, as will be described in detail later, one of device authentication and partition authentication,
Alternatively, information indicating whether to execute both types of authentication, and whether to execute the public key method or the common key method, or whether any type of authentication is possible is recorded.

In the [Integrity Check Value] field for recording the validity verification value (public key method: Signature, common key method: MAC) of the ticket (Ticket),
In the case of the public key method, a signature (see FIG. 12) based on the secret key of the service permission ticket issuing means (SPT Issuer) is generated and stored. The partition manager itself is a service permission ticket issuing means (SPT Issue
When r) is also used, a signature is generated using the private key of the partition manager. In the signature verification process (see FIG. 13), the public key of the service permission ticket (SPT) issuing means (SPT Issuer) is used. Therefore, the device that performs the ticket verification may execute the service permission ticket issuing means (SPTI) upon receipt of the ticket or in advance.
It is necessary to obtain the public key (public key certificate) of the ssuer (ex. partition manager).

After verifying the public key certificate (CERT_SPTI) of the service permission ticket (SPT) issuing means (SPT Issuer), the service permission ticket (SPT) issuing means (SPT Issuer) extracted from the public key certificate (CERT_SPTI) With this public key, signature verification of an ICV (IntegrityCheck Value) can be performed. These processes will be described later using a flow.

In the above description of the ticket format,
File Access Mode: File to be granted access (Fil
The mode recorded in the access mode (Access Mode) to e) and the access mode will be described with reference to FIG.

The data generated as a file is various such as user identification data, amount data, encryption key data, log data, or composite file data.
An access process corresponding to each data, that is, data reading, writing, erasing, adding, subtracting, encrypting, decrypting... Is performed on the access data.

File A of service permission ticket (SPT)
In ccess Mode, among such various access modes,
Defines which access mode is allowed. FIG. 29 shows a list of the access modes. FIG.
Is an example, and other access modes can be set according to data stored in the device.

File access mode [File Access Mode] for the file indicated by [File ID: identifier (ID) of access file (File) in partition] set in service permission ticket (SPT)
Can be executed. If the file access mode set in the service permission ticket (SPT) is read (Read), data in the file can be read. If the file access mode set in the service permission ticket (SPT) is write (Write), data can be written in the file.

[0203] Such access mode, file structure (File Structure) described above settable modes (see FIG. 25) is limited. For example, if the file structure is
If it is purse, it is amount data, and addition (add) and subtraction (S
ub) and other access modes can be set. FIG. 30 shows an example of such a file structure, a settable access mode, and a command transmitted from a reader / writer as a device access device to a device.

In FIG. 30, the file structure is Random.
And an access mode and a command example that can be set for a composite file.

For example, in the case where the file structure is Random and the access mode is read (Read), the command allowable by the device is [Read].
Only. Similarly, the file structure is Random.
, The access mode is encrypted read (R
In the case of (ead), the only command that can be accepted by the device is encrypted reading [EncRead].

In the case of a composite file having a file structure including Purse and Log, if the access mode is a deposit system, the only command that can be accepted by the device is Deposit [Deposit]. Similarly, in the case of a compound file having a file structure including Purse and Log, if the access mode is the withdrawal type, a command allowable by the device is extracted [Wit
hddraw], Receipt generation [Make Receipt]
t], receipt reading [Read Receipt]
Becomes

As an allowable command (see FIG. 30) corresponding to the deposit system in the file access mode (see FIG. 29),
Define the above deposit command (Deposit Command), set the file access mode (File Access Mode) of the access permission ticket to [Deposit], and specify the composite file that constitutes electronic money as the file ID (File ID) Generates an access permission ticket (SPT) and sends it from the file access device to the device, along with a deposit command (Deposit Command).
By transmitting the deposit amount data, for example, it is possible to execute sequential processing such as adding X yen to the file [Purse] in the composite file and writing the processing record to the file [Log] in the composite file. Become. Details of these processes will be described later.

In addition to the one shown in FIG. 30, various combinations of access modes and commands are possible, and are set according to the actual usage of the device.

The device stores the definition data of the command permitted for each file stored in the memory unit in FIG.
And executes the command only when a command input from the access device is a command defined in the definition data. The definition data of the command permitted for the composite file includes the sequence command composed of a plurality of commands executable corresponding to each of the plurality of files included in the composite file as described above.

[0210] A specific file to be processed is set in the file ID (File ID) field of the service permission ticket (SPT), and a predetermined access mode is set to the file access mode (File Access Module) of the service permission ticket (SPT).
de), the service permission ticket (S
PT) can be controlled. Specific processing will be described later using a flow.

Next, FIG. 31 shows a service permission ticket (SPT: Service Peer) in the form of permitting access to a plurality of files among the files set in the partition.
rmission Ticket). Service Permission Ticke (SPT)
In t), data described below is stored.

* Ticket Type: Type of ticket. * Format Version: Format version of ticket (Ticket) * Ticket Issuer: Identifier of partition manager (= PMC) * Serial Number: Serial number of ticket (Ticket) * Size of Ticket: Size of ticket (Ticket) * Authentication Flag: Ticket Flag indicating whether mutual authentication with the device (Device) is necessary in the use processing of (Ticket) * Affiliation of Ticket User (Group): Affiliation of ticket (Ticket) user * Authentication Type: Mutual of device (Device) Authentication type (public key authentication or symmetric key authentication, or any of them is possible (Any)) * Ticket User identifier: Identification data (category or identifier) that identifies the ticket user. Authentication Type], and if [Authentication Type] is public key authentication: Distinguished Name (DN) Gori (Category) is stored, in the case of a common key authentication:
The authentication ID is stored. If authentication is not required, storage is not mandatory. * File ID: Access file (Fil
e) Identifier (ID) * File Access Mode: File (File
le) Access mode (Access Mode) * Group of Target File: File that allows access (Fi
le) Group (Group) * Target File ID: Identifier (ID) of file (File) to be allowed to access * Read / Write Permission: Processing mode (Reading) for file (Target File) to be allowed to access (Read), Write (Write))
Permission * Integrity Check Type: Type of validity verification value of ticket (Ticket) (Public key method (Public) / Common key method (Commo
n)) * Integrity Check Value: Validity verification value of ticket (Public key method: Signature, Common key method: MAC)

As described above, Group of Target File: By defining a group (Group) of a file (File) to which access is permitted and recording it in the ticket, access to a plurality of files in the partition is limited to a single service permission ticket (File). SPT).

Note that the service permission ticket (SP
T) Ticket (Tick) issued by issuing means (SPT Issuer)
et) to the ticket user, in the case of the public key system, the public key certificate (CERT_SPTI) of the service permission ticket (SPT) issuing means (SPT Issuer) is also transmitted. Public key certificate of the SPT issuing means (CERT_SPT
The attribute (I) of the service permission ticket (S)
PT) matches the identifier (SPTIC) of the issuing means (SPT Issuer).

[0215] device (Device) mutual authentication of the type of (public key authentication, or, common key authentication, or either soluble (Any)) in the recorded the [Authentication Type], run as a mutual authentication using a ticket The authentication type to be recorded is recorded. Specifically, as will be described in detail later, one of device authentication and partition authentication,
Alternatively, information indicating whether to execute both types of authentication, and whether to execute the public key method or the common key method, or whether any type of authentication is possible is recorded.

After verifying the public key certificate (CERT_SPTI) of the service permission ticket (SPT) issuing means (SPT Issuer), the service permission ticket (SPT) issuing means (SPT Issuer) extracted from the public key certificate (CERT_SPTI) With this public key, signature verification of an ICV (IntegrityCheck Value) can be performed. These processes will be described later using a flow.

(A8.4. Data Update Ticket (DUT)) Data Update Ticket (DUT: Da)
ta Update Ticket) is an access control ticket applied when accessing various data stored in the device and executing data update processing.
By using a DUT issued by a valid data update ticket (DUT) issuing means (Ticket Issuer) and accessing a device by a ticket user (ex. A reader / writer as a device access device) in accordance with a procedure recorded in the DUT, Data processing can be performed within the limits recorded in.

The data update ticket (DU)
T: Data Update Ticket) is for executing a ticket DUT (DEV) applied to execute an update process of a data item managed by the device manager and an update process of a data item in a partition managed by the partition manager. DUT (PA
R). Ticket: DUT (DEV) issuing means is under the control of the device manager.
(PAR) issuing means is under the control of the partition manager.

FIG. 32 shows two data update tickets (DUT: Data Update Ticket) and DUT (DE
V), DUT (PAR) data format.
Data Update Ticket (DUT: Data Update Ti)
cket) stores data described below.

* Ticket Type: Type of ticket (Ticket) (DUT (DEV) / DUT (PAR)) * Format Version: Format version of ticket (Ticket) * Ticket Issuer: identifier of device / partition manager. Type (Ticket Typ
e) If DUT (DEV), DMC, DUT (PAR)
* Serial Number: Serial number of ticket (Ticket) * Size of Ticket: Size of ticket (Ticket) * Affiliation (Group) of Ticket User: Affiliation of ticket user * Ticket User identifier: Ticket (Ticket) Identification data for identifying the user (category or identifier) This field is data associated with [Authentication Type]. When [Authentication Type] is public key authentication: DN (Distinguished Name) or Category is stored, and in case of common key authentication:
The authentication ID is stored. If authentication is not required, storage is not mandatory. * Authentication Type: Mutual authentication type of the device (Public key authentication or symmetric key authentication, or any type (Any)) * Encrypted Flag: Whether the data to be updated is encrypted ( Encryption: Encrypted / Non-encryption: none) * Old Data Code: Old data code to be updated (Cod
e) * Data Version Rule: Version condition when updating data * Data Version Condition: Version value when updating data * Size of New Data: Size of new data to be updated * New Data: New data to be updated (encryption) In some cases). * New Data Version: Version of data to be updated * Integrity Check Type: Type of validity verification value of ticket (Ticket) (Public key method (Public) / Common key method (Commo
n)) * Integrity Check Value: Validity verification value of ticket (Public key method: Signature, Common key method: MAC)

Data Update Ticket (DUT: Da)
ta Update Ticket)
The condition is expressed by a combination of these two fields, [Data Version Rule: Version condition when updating data] and [Data Version Condition: Version value when updating data].

The version condition [Da
ta Version Rule] has three types: Any, Exact, and Older. Any can update data irrespective of the version condition, and Exact follows [Data Version Con
dition], the data can be updated if the value is the same as the value specified in [Dition], and the Older can update the data only when the New Data Version is newer. If the version condition [Data Version Rule] is Any or Older,
[Data Version Condition] is not used or ignored.

[Authentication Type] in which the type of mutual authentication of the device (Device) is recorded (public key authentication or common key authentication, or any of them is possible (Any)) is executed as mutual authentication using a ticket. The authentication type to be recorded is recorded. Specifically, as will be described in detail later, one of device authentication and partition authentication,
Alternatively, information indicating whether to execute both types of authentication, and whether to execute the public key method or the common key method, or whether any type of authentication is possible is recorded.

Data Update Ticket-DUT (D
In a configuration in which the device manager also functions as the EV) issuing means (DUT Issuer), the code (ticket user (Ticket User)) of the data update ticket-DUT (DEV) issuing means (DUT Issuer) is the device manager code (DMC). It is possible to set as. Also, Data Update Ticket-DUT (PA
R) In a configuration in which a partition manager also functions as an issuance unit (DUT Issuer), the code of the data update ticket-DUT (PAR) issuance unit (DUT Issuer) can be set as a partition manager code (PMC). .

In the [Authentication Type] in which the type of mutual authentication of the device (Device) is recorded (public key authentication or common key authentication, or any of them is possible (Any)), mutual authentication using a ticket is executed. The authentication type to be recorded is recorded. Specifically, as will be described in detail later, one of device authentication and partition authentication,
Alternatively, information indicating whether to execute both types of authentication, and whether to execute the public key method or the common key method, or whether any type of authentication is possible is recorded.

In the [Integrity Check Value] field for recording the validity verification value of the ticket (Ticket) (public key method: Signature, common key method: MAC),
In the case of the public key method, a signature based on a secret key of a device update ticket issuing unit (DUT Issuer) (FIG. 1)
2) is generated and stored. The device manager itself issues device update registration ticket issuing means (DU)
T Issuer), a signature is generated using the secret key of the device manager. When the partition manager itself also serves as a device update registration ticket issuing means (DUIssuer), a signature is generated using the secret key of the partition manager. In this case, the public key of the device manager or the partition manager is used in the signature verification processing (see FIG. 13). Therefore, the device that performs the ticket verification may receive a device update ticket or a device update ticket issuing device (DUT issuer) (ex.
Device Manager or Partition Manager)
It is necessary to obtain the public key (public key certificate) of

Device Update Ticket (DUT)
Public key certificate (CERT_DUTI) of issuing means (DUT Issuer)
After the verification of the data update ticket (DUT) issued from the public key certificate (CERT_DUTI),
T Issuer) public key to ICV (Integrity Check Va)
lue) signature verification.

Data Update Ticket (DUT: Da
FIG. 33 shows an example of data updated by applying the “ta Update Ticket”.

[0229] to the updated data, as shown in FIG. 33,
It includes a device manager code, a device manager code version, a partition manager code, a partition manager code version, each ticket issuing means code, a MAC generation key and version of each ticket, a revocation list, and the like. Each of these data to be updated is a data update ticket (DU)
T: Data Update Ticket), and is updated according to the rules recorded in the DUT. The specific procedure of the update process will be described later using a flow. The device manager code version, the partition manager code version, and other version information are updated together with the update processing of the data to which each version is added. These version information is a data update ticket (DUT).
Is stored in

[B. Description of device distribution to user, various settings for device, and details of device use processing] Next, processing up to the use of a device having the above-described partitioned memory area, and further details of device use processing The flowchart will be described with reference to other drawings. The procedure of the description is performed according to the following items.

B1. Flow from initial device registration to use B2. Initial registration processing by device manufacturing entity B3. Jurisdiction process of device manager B3.1. Device registration processing by device manager B3.2. Public key certificate issuance processing under device manager management B4. Jurisdiction process of partition manager B4.1. Partition setting registration / deletion processing using partition registration ticket (PRT) under management of partition manager B4.2. Public key certificate issuance processing under the control of partition manager B4.3. File generation and deletion processing using file registration ticket (FRT) B5. Service (file access) processing using service permission ticket (SPT) B6. Device data update process using data update ticket (DUT)

[B1. Flow from Device Initial Registration to Use] A device having an EEPROM (flash memory) is manufactured by a device manufacturing entity (manufacturer), initial data is written by a device manager, and provided to a user (ex. Sales, loan). Will be used. In order for a user to receive a service using a device from various service entities, a partition by a partition manager is set in a memory unit of the device, and a file storing data for providing a service is set in the set partition. There is a need.

Also, various processes for the device, that is, partition setting using a partition registration ticket (PRT), a file registration ticket (FR
In various processes such as file setting using T) and data access using a service permission ticket (SPT), a device and a ticket user (ex. A reader as a device access device) for executing a process on the device. Writer).
For example, mutual authentication processing for confirming that both are valid devices and devices, signature generation and verification processing for guaranteeing and confirming the validity of transfer data, and data encryption and decryption processing are also performed. The configuration of the present invention proposes a configuration using a public key certificate for these processes. Therefore, a public key certificate issuance process and a device storage process are executed for the device before the device uses the service.

For example, a mutual authentication process using a public key certificate is executed between a device and a ticket user (ex. A reader / writer as a device access device) for executing a process on the device, and the validity of both is verified. Partition registration ticket (PRT) on condition that it is confirmed
Various processes are performed, such as setting of a partition using a file, a file setting using a file registration ticket (FRT), and data access using a service permission ticket (SPT). Further, an electronic signature is added to the data transferred to each other as necessary, and the data is verified. Further, the encryption and decryption processing of the transfer data is executed as needed.

FIG. 34 is a diagram schematically showing a flow from manufacture of a device to use. Each of these processes will be described in detail later with reference to the flow, but each stage shown in FIG. 34 will be briefly described for understanding the overall process.

[0236] 1. First, the device is manufactured by a manufacturing entity. When a device is manufactured, a device code as identification data (ID) of each device is assigned to each device. At the manufacturing stage, various manufacturing information (Manufacture Information Block (see FIG. 14)) such as a device code and a manufacturing code is written in the device and stored in the memory of the device.

[0237] 2. Next, before the device manager provides the device to the user, the device manager manages device management information (Device Management Information (see FIG. 15)) such as its own ID and the public key of the certificate authority (PUB CA (DEV)). Key (see FIG. 18)) and other information are stored in the memory.

[0238] 3. The device in which the management information is written by the device manager is provided to the user.

[0239] 4. Next, the user executes a process of obtaining a public key certificate corresponding to the device, and stores the obtained public key certificate (CERT DEV) corresponding to the device in the device key area (see FIG. 18) of the device.

[0240] 5. A service entity (partition manager) that sets a partition in the memory section of the device and intends to provide a service requests the device manager to set the partition, receives a license, and receives a partition registration ticket (PRT).
Also, the public key (PUB CA (PAR)) of the certificate authority used in the communication processing with the device is specified.

6. The device executes communication with a ticket user (ex. A reader / writer as a device access device) managed by the partition manager, performs a partition registration process using a partition registration ticket (PRT), and performs a process of registering a partition. The public key (PUB CA (PAR)) is stored in the partition key area (see FIG. 23).

[0242] 7. The device in which the partition is set transmits a request for issuing a partition-related public key certificate to the partition manager, and stores the obtained partition-related public key certificate (CERT PAR) in the partition key area (see FIG. 23).

The above-mentioned processing for partition setting 5 to 7 is executed for each partition manager which intends to provide a service by setting a partition.
Multiple partitions are registered on the device.

[0244] 8. Next, the partition manager
In the partition set in the device, for example, the setting registration processing of the file corresponding to the service is executed by applying the file registration ticket (FRT).

9.10. By registering files in the set partition, for example, electronic money,
Various services defined by data in the file, such as commuter passes, can be executed. A service permission ticket (SPT) is applied to processes such as reading and writing data in a file. That is, only when a service permission ticket (SPT) issued by a valid ticket issuing unit is applied, data reading, writing, and the like are executed in accordance with rules recorded in the SPT.

Although not shown in the figure, the data to be updated (ex. Data) in the data stored in the device using a data update ticket (DUT) as necessary.
An update process of the device manager code, the device manager code version, the partition manager code, the partition manager code version, each ticket issuing means code, the MAC generation key and version of each ticket, the revocation list, and the like is executed. The device manager code version, the partition manager code version, and other version information are updated together with the update processing of the data to which each version is added. These version information are stored in a data update ticket (DUT: Data Upd
ate Ticket).

Hereinafter, the details of each process will be described with reference to the flow and other drawings.

[B2. Initial Registration Process by Device Manufacturing Entity] First, the initial registration process by the device manufacturing entity will be described with reference to FIG. FIG.
5 shows the processing of the registration device of the device manufacturing entity (Manufacture), and the right side shows the processing of the device (see FIG. 5). The device manufacturing entity (Manufacture)
Is configured as a reader / writer (see FIG. 10) as a dedicated device access device capable of performing data read / write processing on a device.

First, in step S101, the registration device sends a manufacturing information block (MIB: Manu) to the device.
A read command of a write flag (Writable Flag) of the facture information block (see FIG. 14) is transmitted. When the device receives the command (S121),
A write (Writable) flag in the manufacturing information block (MIB) of the memory section of the device is transmitted to the registration device (S12).
2) Do it.

The registration device that has received the write (Writable) flag in the manufacturing information block (MIB) (S102) determines whether or not the write flag (Writable Flag) is set to writable (0xffff) (S1).
03). If the write flag (Writable Flag) is not set to writable (0xffff), the following manufacturing information block (MIB: Manufacture Informat)
ion block) write processing cannot be executed, and the processing ends as an error.

When the write flag (Writable Flag) is set to be writable (0xffff), the device manufacturing information block (MIB: Manufacture Inform)
(see FIG. 14), and transmits MIB data to the device together with the MIB write command (S105).

The device that has received the MIB write command and the MIB data (S123) verifies the MIB write flag (Writable Flag) (S124), and makes the write flag (Writable Flag) writable (0xf).
If the setting is not set to (ffff), the writing process of the following manufacturing information block (MIB: Manufacture Information Block) cannot be executed, and the process ends as an error. Write flag (Writable Flag) is set to writable (0xf)
If it is set to (ffff), the received MIB data is written to the MIB area (S125).

When the MIB data writing process is completed, a write completion notification is transmitted to the registration device (S126). The registration device that has received the write completion notification (S106) transmits an initial registration completion command to the device (S107), and the device that has received the initial registration completion command (S127) has a manufacturing information block (MIB: Manufacture Information).
The write flag (Writable Flag) of the (Block) is set to non-writable (0x0000) (S128), and a write completion notification is transmitted to the registration device (S129).

Upon receiving the write end notification (S108), the registration apparatus sends a manufacturing information block (MI
B: Manufacture Information Block (See Fig. 14)
Is transmitted (S109). When the device receives the command (S130), a write flag (Writable Flame) in the manufacturing information block (MIB) of the memory unit of the device is received.
g) is transmitted to the registration device (S131).

The registration device that has received the write flag (Writable Flag) in the manufacturing information block (MIB) (S110) determines whether or not the write flag (Writable Flag) is set to write disabled (0x0000) (S111). ). Writable Flag
Is not set to write disabled (0x0000), it indicates that normal MIB data write processing has not been completed, and the processing is terminated as an error. Writing flag (Writable Flag) is not writable (0x000)
If it is set to 0), the process ends assuming that the normal MIB data writing process has ended.

[B3. Device Manager Jurisdiction]
Next, the jurisdiction process of the device manager will be described. Here, a process that is executed before the use of the device is started will be described. The processing of the device manager executed before the start of use of the device includes a device management information block (DMIB: Device Management Information Block) in the memory section of the device.
Management Information Block), Public Key Device Key Definition Block (DKDB: Device Key Definition)
Block (PUB)), common key device key definition block (D
KDB: Device Key Definition Block (Common), device registration processing executed as data writing processing to a device key area (Device Key Area), and device corresponding public key certificate (CERT DE
V). Hereinafter, details of these processes will be described.

[B3.1. Device Registration Processing by Device Manager] Initial registration processing involving storage processing of device management information and the like for a device by a device manager will be described with reference to the flow of FIG. In the flow shown in FIG. 36 and subsequent figures, the processing on the initial registration device of the device manager (DM) is on the left, and the device (FIG.
Reference). The device manager (D
The initial registration device of M) is a device (ex. A reader / writer as a device access device, a PC) that can perform data read / write processing on a device, and has a configuration corresponding to the reader / writer as a device access device in FIG.

First, in step S201, a read command of the identifier IDm of the device is output to the device. The device receives the command (S211)
Then, the device identifier IDm is transmitted to the registration device (S21).
2) Do it.

[0259] receives an identifier IDm of the device (S20
2) In step S203, the registered device performs a device management information block (DMIB: De
vice Management Information Block (See Fig. 15)
A read command of a write flag (Writable Flag) is transmitted. The device receives the command (S213)
Then, a write flag (Writable Flag) in the device management information block (DMIB) of the memory section of the device
Is transmitted to the registration device (S214).

A write flag (Writable Flag) in the device management information block (DMIB) is received (S20).
4) The registered device performs the write flag (Writable Fla
It is determined whether or not g) is set to writable (0xffff) (S205). Write flag (Writab
le flag) is not set to writable (0xffff), the following device management information block (DM
The writing process of IB: Device Management Information Block cannot be executed and ends as an error.

If the write flag (Writable Flag) is set to writable (0xffff), a device manager code (DMC) and a DMC version write (DMC Write) command are transmitted to the device (S206). This code is data previously assigned to the device manager by a code management organization (see FIGS. 1 to 3).

Receives DMC Write command (S215)
The device that performed the writing is a DMIB write flag (Writable F
lag) (S216), and a write flag (Writabl)
e Flag) is not set to writable (0xffff), the following device management information block (DMI)
B: Device Management Information Block) write processing cannot be executed, and the processing ends as an error. The write flag (Writable Flag) is set to be writable (0xffff).
f), the received device manager code (DMC) and DMC version are
Write to the B area (S217).

When the write processing of the device manager code (DMC) and the DMC version is completed, a write completion notification is transmitted to the registration device (S218). The registration device that has received the write completion notification (S207) transmits a device total block number (DeviceTotal Block Number) write command to the device (S208).

[0264] Device Total Blo
The device that has received the (ck Number) write command (S219) writes the DMIB write flag (Writable Flag).
g) is verified (S220), and a write flag (Writable
Flag) is not set to writable (0xffff), the following device management information block (DMI)
B: Device Management Information Block) write processing cannot be executed, and the processing ends as an error. The write flag (Writable Flag) is set to be writable (0xffff).
If it is set to f), the received device total block number (Device Total Block Number) is written to the DMIB area (S221). In addition, the device has a DMI
Device free block count information area in area B (Free Block
Write TB-4 to Number in Device (S22)
2). TB is Device Total Blo
ck Number). Note that four blocks of TB-4 are manufacturing information blocks (MIB: Manufacture Informat
ion Block), Device Management Information Block (DMIB: D)
evice Management Information Block), public key device key definition block (DKDB: Device Key Definit)
ion Block (PUB)), Device Key Definition Block (DKDB: Common Key)
Is shown.

Next, the device determines the number of partitions (Partition Numb) in the device management information block (DMIB).
er) Write 0 in the area (S223). At this point, no partition is set in the device. In addition, the pointer of the free area of the DMIB (Pointer of
0 is written in the Free Area (S224), and the completion of the writing process is transmitted to the registration device (S225).

The registration apparatus which has received the write processing completion notification from the device (S209) determines whether or not to use a common key for device authentication (S231). The authentication process will be described in detail later, but it is possible to perform a public key authentication method or a common key authentication method, and the device manager can set an authentication method required for the device. Becomes If the device is a device that performs common key authentication, the device manager sets information necessary for common key authentication (ex. A master key for generating an authentication key, etc.) in the device, and the device does not execute common key authentication. In such a case, such information is not stored in the device. The device manager sets data in the device that can execute either the common key authentication, the public key authentication, or both methods according to the authentication method adopted by the device.

As shown in FIG. 37, when using a common key for device authentication, steps S232 to S233 and S24
If steps 1 to S245 are executed and a common key is not used for device authentication, these steps are omitted.

When the common key is used for device authentication, in step S232, the registration device sends a common key authentication data write command as MKauth_DEV_A: master key for bidirectional individual key authentication, Kauth_DEV_B: common key for bidirectional individual key authentication, IRL_DEV. : Revocation list (Revo) that registers the device identifier (ID) of the excluded device (Device)
Send the cation list (Device ID) and its version information to the device.

In step S241, the device receives the above-described write command, and in step S242,
After confirming that the write flag (Writable Flag) of the DMIB is writable, the received data is written into the device key area (see FIG. 18) (S243). Next, the pointer, the size, and the number of free blocks in the device generated by the data writing are adjusted (S244), and a write completion notification is transmitted to the registration device (S245).

The registration device that has received the write end notification (S233) determines in step S234 whether to use a public key for device authentication. As shown in FIG. 37, when a public key is used for device authentication, step S2
When steps S35 to S239 and S246 to S254 are executed and a public key is not used for device authentication, these steps are omitted.

When the public key is used for device authentication, in step S235, the registration device issues a public key authentication data write command as PUB_CA (DEV): the public key of the certification authority CA (DEV) that issues the device manager corresponding public key, PARAM_DEV: public key parameter of device (Device), CRL_DEV: revocation list (Revocation List (Certificate)) in which public key certificate identifier (ex. Serial number: SN) of excluded device (Device) is registered,
And transmitting these version information to the device.

In step S246, the device receives the above-described write command, and in step S247,
After confirming that the write flag (Writable Flag) of the DMIB is writable, the received data is written to the device key area (see FIG. 18) (S248). Next, the pointer, the size, and the number of free blocks in the device generated by data writing are adjusted (S249), and a write completion notification is transmitted to the registration device (S250).

The registration device that has received the write completion notification (S236) transmits a key pair generation command of a public key and a secret key to the device (S237). In this embodiment, the key pair is generated by the device. However, the key pair may be generated by the registration device and provided to the device.

The device that has received the key pair generation command (S251) uses the public key (PUB DEV) and the secret key (PRI DE) in the encryption processing unit (see FIG. 5) in the device.
V), and writes the generated key into the device key area (see FIG. 18) (S252). The public key (P
UB DEV), the CERT of the device key area
-Temporarily store in the DEV area, and then use the public key (PUB
When the public key certificate storing the DEV is received, the public key certificate is replaced with the public key certificate (CERT). Next, the pointer, the size, and the number of free blocks in the device generated by the data writing are adjusted (S253), and the generated and stored public key is transmitted to the registration device (S254).

The registration device sends a public key (PUB) from the device.
DEV) is received and stored in a database (DB (DEV) (see FIG. 7)) in the device manager together with the device identifier IDm of the device previously received from the device.

Next, the registered device of the device manager is:
Partition Registration Ticket (PRT: Partition Regi
It is determined whether a common key is used for the verification process of the stration ticket (S261). For the ticket verification, a common key method based on MAC value verification and the like, and a public key method for performing signature generation using a private key and verifying a signature using a public key described with reference to FIGS. Can be applied, and the device manager can set the verification processing method adopted by the device. The device manager uses the P
Data that can execute either the common key, the public key, or both methods is set in the device according to the RT ticket verification method.

If the device manager is a device that executes common key authentication, the device manager sets information (ex. PRT) necessary for PRT verification in the common key system.
(Verification common key) is set in the device, and if the device does not execute the common key authentication, such information is not stored in the device.

As shown in FIG. 38, when the common key method is used for PRT verification, steps S262 to 263, S27
When steps 1 to S275 are executed and the common key is not used for PRT verification, these steps are omitted.

When the common key is used for PRT verification, in step S262, the registration device transmits Kprt: the MAC verification key of the partition registration ticket (PRT) and version information to the device as a PRT verification common key write command.

In step S271, the device receives the above-mentioned write command, and in step S272,
After confirming that the write flag (Writable Flag) of the DMIB is writable, the received data is written into the device key area (see FIG. 18) (S273). Next, the pointer, the size, and the number of free blocks in the device generated by the data writing are adjusted (S274), and a write completion notification is transmitted to the registration device (S275).

The registration apparatus that has received the write end notification (S263) determines in step S264 whether to use a public key for PRT verification. As shown in FIG.
When a public key is used for PRT verification, Step S265
If steps S266 and S276 to S282 are executed and the public key is not used for PRT verification, these steps are omitted.

When the public key is used for PRT verification, in step S265, the registration device sends a PRT verification data write command as PRTIC (PRT Issuer Category):
Partition registration ticket (PRT) issuer category, PUB_CA (DEV): public key of certificate authority CA (DEV) that issues a device manager-compatible public key, PARAM_DEV: public key parameter of device, CRL_DEV: excluded device (Device) ), And a revocation list (Revocation List (Certificate)) in which the public key certificate identifier (ex. Serial number: SN) is registered, and the version information thereof are transmitted to the device.

[0283] In step S276, the device receives the above-described write command, and in step S277,
After confirming that the write flag (Writable Flag) of the DMIB is writable, in step S278, the PRTIC (PRTIssuer Category): partition registration ticket (PRT) issuer category in the received data is set to a public key device key definition block. (DKDB: Device Key
The write version information is written to the definition block (PUB) (see FIG. 16) in the version area of the block.

Next, in step S279, the device determines whether or not the public key data of the certificate authority CA (DEV) that issues the public key corresponding to the device manager has been written. In step S280, PUB_CA (DEV), PARAM_DEV, CRL_DE
Write V to the device key area (see FIG. 18). Next, adjustment of the pointer, size, and the number of free blocks in the device caused by data writing is executed (S281).
A write completion notification is transmitted to the registration device (S282).

The registration apparatus that has received the write end notification (S266) determines in step S291 whether the device is a device that supports updating of the common key data. Some of the data stored in the device are data update tickets (DUTs) described above as data to be updated (see FIG. 32).
Can be updated using. The data to be updated is
This is as described above with reference to FIG. In the update process using this data update ticket (DUT: Data Update Ticket), either the common key method or the public key method is possible, and the device manager can use either method or both methods depending on the device. Set the executable data to the device.

[0286] If the device is a device that executes data update using the common key system, information necessary for data update processing using the common key system (ex. MAC verification key of data update ticket (DUT), etc.)
Is set in the device, and if the device does not execute the common key authentication, such information is not stored in the device.

As shown in FIG. 39, when a common key method is used for data update processing using a data update ticket (DUT: Data Update Ticket), step S29 is performed.
If steps S2 to S293 and S301 to S305 are executed and the common key method is not used for updating data, these steps are omitted.

When the common key is used for data update, in step S292, the registration device uses the Kdut_DEV1: MAC key of the data update ticket (DUT) as a data update ticket (DUT: Data Update Ticket) verification common key write command. Kdut_DEV2: Data update encryption key, Kdut_DEV3: Data update ticket (DUT) MAC verification key, Kdut_DEV4: Data update encryption key and their version information are transmitted to the device.

In step S301, the device receives the above-mentioned write command, and in step S302,
After confirming that the write flag (Writable Flag) of the DMIB is writable, the received data is written into the device key area (see FIG. 18) (S303). Next, the pointer, the size, and the number of free blocks in the device generated by the data writing are adjusted (S304), and a write completion notification is transmitted to the registration device (S305).

In step S294, the registration apparatus that has received the write completion notification (S293) transmits the data update ticket (DU) using the public key method to the device.
It is determined whether or not data update processing using T: Data Update Ticket is supported. As shown in FIG.
If the public key method is supported, steps S295-S
296, S306 to S310 are executed, and when the public key method is not supported, these steps are omitted.

If the public key method is supported, in step S295, the registration device transmits a DUTIC_DEV (DUT Issuer Categor) as a data update ticket (DUT: Data Update Ticket) issuer code write command.
y): Data update ticket (DUT: Data Updat)
e Ticket) Sends issuer category and version information to the device.

[0292] In step S306, the device receives the above-mentioned write command, and in step S307,
After confirming that the write flag (Writable Flag) of the DMIB is writable, in step S308, the received data is stored in the public key device key definition block (D
KDB (PUB): Device Key Definition Block (PU
B)) (S308). Next, the pointer, the size, and the number of free blocks in the device generated by data writing are adjusted (S309), and a write completion notification is transmitted to the registration device (S310).

The registration apparatus that has received the write end notification (S296) transmits a device manager (DM) initial registration completion command to the device in step S321. In step S332, the device that has received the command (S331) performs mutual authentication, verification of the partition registration ticket (PRT), and verification of the data update ticket (DUT). It is determined whether data that can be processed has been set. If these data are insufficient, any of the processes cannot be executed, and the initial registration by the device manager is determined to be an error, and the process ends.

[0294] In step S332, mutual authentication, verification of a partition registration ticket (PRT), and verification of a data update ticket (DUT) are performed. If it is determined that the setting has been completed, the device determines in step S333 that the device management information block (DMIB: Device Management In
The writing (Writable) flag of the formation block is set to writing disabled (0x0000), and a writing completion notification is transmitted to the registration device (S334).

The registration device that has received the write completion notification (S322) sends a device management information block (DMIB) to the device.
k) (see Fig. 15)) write flag (Writable Fla
The read command of g) is transmitted (S323). Upon receiving the command (S335), the device transmits a write flag (Writable Flag) in the device management information block (DMIB) of the memory unit of the device to the registration device (S336).

A write flag (Writable Flag) in the device management information block (DMIB) is received (S32).
4) The registered device performs the write flag (Writable Fla
It is determined whether or not g) is set to write disable (0x0000). Writable Flag
Is not set to write disable (0x0000), it indicates that normal DMIB data write processing has not been completed, and the processing is terminated as an error. The write flag (Writable Flag) is not writable (0x00)
If it is set to (00), the process ends assuming that the normal DMIB data writing process has ended.

Device Manufacturing Entity (Manufacture)
Registration by the registration device (FIG. 35) and initial registration by the device manager (FIG. 36 to FIG. 36).
FIG. 41 shows an example of the configuration of data stored in the memory of the device in a state where the processing flow of FIG. 40) has been completed. FIG. 41 shows a manufacturing information block (Manufacture Information Block) and a device management information block (Device Management Information Bloc) described with reference to FIG. 6, and FIGS.
k), public key device key definition (Device Key Definition)
Block (PUB)), common key device key definition block (Dev
ice Key Definition Block (Common)) and a device key area. At this point, no partitions have been formed in the memory.

Manufacturing Information Block (Manufacture Informat
As described with reference to FIG. 14, a device code and the like as device-specific information are written in the ion block). This manufacturing information block (Manufacture Informatio
The information written in (n Block), a part of the written information, or operation data obtained based on the written information corresponds to the device identifier (IDm).

The device key area (Device K) shown in FIG.
ey Area) stores Kauth_DEV_B: a common key for two-way individual key authentication, and MKauth_DEV_A: a master key for two-way individual key authentication. These keys are used when there is no request for the device to perform a common key authentication process. May not be stored, and Kprt: partition registration ticket (P
The RT verification MAC key may not be stored if the device does not execute the ticket verification process using the common key.

[0300] In addition, IRL_DEV: exclusion device (Device)
Revocation List (Device ID) in which the device identifier (ID) of the device is registered, CRL_DEV: Revocation List (Revocation) in which the public key certificate identifier (ex. Serial number: SN) of the excluded device (Device) is registered Regarding List (Certificate), if there is no revoked (excluded) device at the time of device issuance, or if the revocation list is acquired using another source, the revocation list is not stored. It may be configured.

[B3.2. Issuing Process of Public Key Certificate Under Device Manager Management] Next, the issuing process of the device corresponding public key certificate by the device manager will be described with reference to FIG. For the device, it can be applied to the device-wide public key certificate (CERT DEV) applicable to the authentication of the entire device, the processing for each device, and the authentication and other verification processing for the processing for a specific partition in the device. A public key certificate corresponding to a partition (CERT PAR) can be stored. The public key certificate for partition (CERT PAR)
Settings can be stored for each partition set in the device.

The device-compatible public key certificate (CERT D)
EV) is stored in a device key area (Device Key Area) (see FIG. 18), which is a memory area under the jurisdiction of the device manager.
ERT PAR) is a partition key area (Partit) which is a memory area under the control of each partition manager.
ion Key Area) (see FIG. 23).

The device-compatible public key certificate (CERT D)
The EV is issued by a procedure for giving a device a public key certificate issued by a certificate authority (CA for DM) (see FIGS. 2 and 3) via a registration authority under the jurisdiction of the device manager. The management of the public key certificate (CERT DEV) issued by the registration authority (database 222 (see FIG. 7)) is executed.

Also, the partitioning public key certificate (C
The ERT PAR is issued by a procedure for giving a device a public key certificate issued by a certificate authority (CA for PM) (see FIGS. 2 and 3) through a registration authority under the jurisdiction of the partition manager. Public key certificate issued by the competent registration authority (CERT P
AR) (database 332 (see FIG. 9)).

Referring to FIGS. 42 and 43, a description will be given of a procedure for issuing a device-related public key certificate (CERT DEV) to a device by the registration authority of the device manager. Note that the registration bureau (R
A) FIG. 44 shows the relationship between the issuing device (DM), the certificate authority (CA), and the user device from which only the configuration is extracted.
As shown in FIG. 44, the control means 221 has an encryption processing means. The encryption process is performed by executing a program related to the encryption process under the control of the control unit (CPU (2111 in FIG. 8)).

[0306] Figure 42, in FIG. 43, the left side CERT (public key certificate) jurisdiction registration station device manager issuing device, specifically, the processing of the control unit 221 in the configuration diagram of a device manager shown in FIG. 7, The right side is the processing of the device.

First, in step S351, CERT
The issuing device is a device-compatible public key certificate (CERT D
The user information of the device to which the EV is issued is acquired, the certificate issuance is permitted (determined), and a communication path with the device to be issued is secured. The user information of the device for which the device corresponding public key certificate (CERT DEV) is to be issued can be acquired, for example, from data generated at the time of initial registration of the device. Alternatively, the user's name, address, telephone number, e-mail address, and the like may be separately obtained through another route. Note that the user information may be acquired from the device after setting a communication path with the device. The communication path may be secured as a communication path capable of transmitting and receiving data regardless of whether it is wired or wireless.

Next, the CERT issuing device proceeds to step S35
In step 2, an authentication data generation command including a random number is transmitted to the device. The device that has received the authentication data generation command (S361) adds the device secret key (PR) to the combined data of the received random number R and the device identifier (IDm).
A digital signature (S) generation process (see FIG. 12) is executed by applying IDEV) (S362). The device is
Device identification data (IDm) and signature (S)
Transmit to T issuing device.

[0309] Upon receiving the identification data (IDm) and the signature (S) from the device (S353), the CERET issuing device:
The stored device public key (PUB DEV) is acquired from the database DB (DEV) 222 using the received device identification data (IDm) as a search key. further,
The signature (S) is verified (see FIG. 13) by applying the obtained device public key (PUB DEV) (S35).
5) Do it. If the verification is not successful, it is determined that the data transmitted from the device is invalid data, and the process ends.

If the verification is successful, the certificate authority (CA f
or DM) 610 is requested to issue a device corresponding public key certificate (CERT DEV) (S357). The device manager receives the device corresponding public key certificate (CERT DEV) issued by the certificate authority 610 (S
358) and transmit it to the device (S359).

The device that has received the device-related public key certificate (CERT DEV) from the device manager (registration authority) receives the certificate using the certificate authority's public key (PUB CA (DEV)) stored in the device key area in advance. The signature verification of the obtained device-compatible public key certificate (CERT DEV) is executed. That is, the public key certificate has a signature executed with the private key of the certificate authority (see FIG. 11), and the signature is verified (S366).

If the signature verification fails, it is determined that the certificate is not a valid public key certificate, and an error notification is issued to the CERT issuing device (S385).

If the signature verification is successful, the device public key (PUB DEV) stored in the device corresponding public key certificate (CERT DEV) is compared with the device public key (PUB DEV) stored in the own device. (S3
82) If they do not match, an error notification is executed. If they match, the received device-compatible public key certificate (CE
RT DEV) is stored in the device key area (see FIG. 18) (S383). Prior to the issuance of the device corresponding public key certificate (CERT DEV), the public key (PUB DEV) generated by the own device is stored in this area, and the valid device corresponding public key certificate (CERT DEV) is issued. At that point, the device-compatible public key certificate (CER
TDEV) to store the information.

The device-compatible public key certificate (CERT D)
When the storage of the EV) is completed, the storage processing end notification is issued by the CERT.
The data is transmitted to the issuing device (S384). The CERT issuing device receives the storage processing end notification (S371), confirms the storage success (S372), and ends the processing. If the storage success cannot be confirmed, the process ends as an error.

FIG. 45 shows a device-specific public key certificate (CE
FIG. 4 is a diagram illustrating a data transmission / reception process between the device manager 200, the device 100, and each entity of the certificate authority (CA) 610 in the issuance process of the RT DEV.

No. in FIG. The processing is executed in the order of 1 to 14. The processing No. 1 device manager 2
00 from the device 100 (ID
m), device public key (PUB DEV) acquisition processing,
And process No. The registration process of the device identifier (IDm) 2 is a process executed in the initial registration by the device manager.

A public key certificate corresponding to a device (CERT D)
EV) issuance procedure, the processing No. From 3.
3. Acquisition of customer information from the device by the device manager; 4. Registration of customer information (not required if already registered); 5. acquisition of a device identifier (IDm) from the device; Based on the obtained device identifier (IDm), a database search is executed to execute a corresponding public key (PUB).
DEV), 7. Authentication processing between the device and the device manager. This processing is omitted in the processing in FIGS. 42 and 43, but in FIGS. 42 and 43, signature verification is executed when a device identifier (IDm) is obtained from the device. Authentication was omitted by confirming the transmission data of the communication partner. It is desirable to execute at least one or both of the signature verification in FIGS. 42 and 43 and the authentication in FIG. Note that the details of the authentication process are described in B.2 below. 4. This will be described in the section of the jurisdiction process of the partition manager.

[0318] 8. 8. A request from the device manager to the certificate authority to issue a device-related public key certificate; 9. Generation of device-compatible public key certificate (CERT DEV);
10. Data registration of the generated public key certificate in the certificate authority,
11. Distribution of a public key certificate from a certificate authority (CA) 610 to the device manager 200; Update device manager database (register public key certificate issuance information), 1
3. 13. transmission of a device-compatible public key certificate (CERT DEV) from the device manager to the device;
Public key certificate for devices (CERT
DEV) is written and stored in the device key area as described above.

[0319] Through the above processing, the device obtains the device corresponding public key certificate (CERT DEV) and stores it in the memory unit. This device-compatible public key certificate (CE
FIG. 46 shows a data storage configuration of each block of the memory after storing the (RTDEV) in the device key storage area of the memory. FIG. 46 shows the manufacturing information block (Manufacture Information Bl) described with reference to FIG. 6 and FIGS.
ock), Device Management Information Block (Device Management
Information Block), public key device key definition (Devi
ce Key Definition Block (PUB)), Device Key Definition Block (Commo
n)), indicating a device key area. At this point, no partitions have been formed in the memory.

A device key area (Device Key area) shown in FIG.
Area) contains a device-compatible public key certificate (CERT DE
V) is stored. Public key certificate for device (CER)
Before the issuance of a TDEV, a public key (PUB DEV) generated by the device is stored in this area. When a public key certificate for a device (CERT DEV) is received,
An overwrite process is performed using a device-compatible public key certificate (CERT DEV). If there are pointers, sizes, and management data due to this overwriting process, necessary change processes are executed.

[B4. Jurisdiction Processing of Partition Manager] Next, jurisdiction processing of the partition manager will be described. Here, a process that is executed before the use of the device is started will be described. The processing of the partition manager executed before the start of use of the device includes a process of setting a partition in the memory unit of the device and a process of issuing a partition corresponding public key certificate (CERT PAR) to the device. Less than,
The details of these processes will be described. The process of setting a partition includes a mutual authentication process (device authentication or partition authentication) between the device and the partition manager, a partition registration ticket (PR
T: Partition Registration Ticket). The processing for deleting a partition can be basically executed according to the same procedure as that for creating a partition.

[B4.1. Partition Setting Registration and Deletion Processing Using Partition Registration Ticket (PRT) Under Partition Manager Management] First, the partition setting registration and deletion processing using the partition registration ticket (PRT) (see FIG. 26) will be described. The flow of FIG. 47 and subsequent drawings will be described with reference to other drawings. As described above, the partition setting process includes a mutual authentication process (device authentication or partition authentication) between the device and the partition manager, a partition registration ticket (PRT: Partitio).
n Registration Ticket).
These processes will also be described.

The partition setting registration / deletion processing flow shown in FIG. 47 will be described. In FIG. 47, the left side shows the processing of the partition creation / deletion device of the partition manager, and the right side shows the processing of the device (see FIG. 5). Note that the partition manager
The deletion device is a device (ex. A reader / writer as a device access device, a PC) that can perform data read / write processing on the device, and corresponds to the reader / writer as the device access device in FIG. First, FIG.
, An outline of the partition creation / deletion processing will be described, and then details of each processing included in this processing will be sequentially described using the flow of FIG. 48 and subsequent figures.

First, steps S401 and S41 in FIG.
At 0, a mutual authentication process is performed between the partition creation / deletion device and the device. The two means for executing data transmission / reception mutually confirm whether or not the other party is a correct data communicator, and thereafter perform necessary data transfer. The process of confirming whether the other party is the correct data communicator is the mutual authentication process. One preferable data transfer method is to generate a session key during the mutual authentication process, and to perform data transmission by performing an encryption process using the generated session key as a shared key.

In the mutual authentication processing in the system of the present invention, either device authentication or partition authentication is executed. Either common key authentication or public key authentication is applied to each of them. These will be described later.

The processing to be executed as the mutual authentication processing is the partition registration ticket (PRT) to be applied.
(See FIG. 26) * Authentication Flag: A flag indicating whether or not mutual authentication with the device is necessary in the use process of the ticket (Ticket) * Authentication Type: Type of mutual authentication of the device (public key) Authentication, or symmetric key authentication, or any (Any).

When the authentication processing has failed (S402, S4
No in 11) indicates that it is not possible to confirm that they are valid devices and devices, and the following processing is not executed and the processing ends as an error.

If the authentication process is successful, the partition creation / deletion device sends a partition registration ticket (PRT) to the device.
Send Partition registration ticket (PRT)
Is a partition registration ticket (P) managed by the device manager at the request of the partition manager.
RT) A ticket issued to the partition manager by the issuance means (PRT Issuer). The partition registration ticket (PRT) is an access control ticket for the device, and has the data format configuration of FIG. 26 described above.

The partition registration ticket (PR
T) to the ticket user, in the case of the public key method, a partition registration ticket (PRT)
Public key certificate (CERT_PRTI) of issuing means (PRT Issuer)
Also send it together. Public key certificate (CE
The attribute (RT_PRTI) is the identifier of the partition registration ticket (PRT) issuing means (PRT User)
(PRTIC).

The device which has received the partition registration ticket (PRT) (S412) executes the validity of the received ticket (PRT) and the user check processing (S4).
13). The processing for verifying the validity of the ticket is executed by applying either MAC verification using a common key method or signature verification processing using a public key method. User check is the device that sent the ticket (ticket user)
This is a process for checking the validity of the ticket, and is executed as a process for verifying a match between the identification data of the authentication partner and the ticket user identifier (see FIG. 26) recorded on the ticket, etc., when mutual authentication has been established. You. Details of these processes will be described later.

In the device, the reception ticket (PR
T) If the validity of the ticket and the user cannot be confirmed as a result of the user check processing (S4)
14 is a partition registration ticket (PR
T) Notify the partition creation / deletion device of the reception error (S418). If the ticket and the validity of the user can be confirmed (Yes in S414), a process of creating or deleting a partition in the memory unit in the device is executed in accordance with the rules described in the received partition registration ticket (PRT). . The details of this processing will be described later using another flow.

According to the description of the partition registration ticket (PRT), when the partition generation or deletion processing is successful (Yes in S416), the PRT reception success is notified to the partition creation / deletion device (S417).
On the other hand, the creation or deletion of the partition failed (S
If No at 416), a PRT reception error is notified to the partition creation / deletion device (S418).

The partition creation / deletion device is PRT
The reception result is received (S404), the PRT processing result is determined, and if the PRT reception result is an error (N in S405)
In o), the process ends as an error, the PRT reception result is successful (Yes in S405), and if the process is partition generation, the partition initial data write process (S406, S419) is executed. The initial data write processing will be described later in detail using another flow. When the process of writing the partition initial data is completed, and when the result of the PRT reception is successful (Yes in S405) and the process is to delete the partition, the session clear command is transmitted and received (S407, S4).
20) is executed, the authentication table generated on the device side is discarded (S421), and the process ends. The authentication table is
This is a table generated in the mutual authentication processing in steps S401 and S410, the details of which will be described later.

As described above, using the partition registration ticket (PRT), a new partition is created in the device, or a created partition is deleted. Hereinafter, the mutual authentication process (S
401, S410), ticket validity and user check (S413), partition generation and deletion processing (S
415), partition initial data write processing (S
406, S419) will be described in detail.

(Mutual Authentication Processing) Step S40 in FIG.
1, the mutual authentication process executed in S410 will be described. The mutual authentication process described below is performed for another ticket, that is, a file registration ticket (FRT: Fi
le Registration Ticket), service permission ticket (S
The device access process using a PT (Service Permission Ticket) and a data update ticket (DUT: Data Update Ticket) is also performed as needed.

FIG. 48 shows a processing flow of the mutual authentication processing. In FIG. 48, the left side shows the processing of the authentication device of the partition manager, and the right side shows the processing of the device (see FIG. 5). Note that the authentication device of the partition manager is a device that can perform data read / write processing on the device (ex.
PC) having a configuration corresponding to the reader / writer in FIG.

In step S431 of FIG. 48, the authentication device reads an authentication method required for using the partition registration ticket (PRT) from the ticket and determines the authentication method.
The authentication mode is not limited to the authentication method described in the ticket.
For example, device authentication and partition authentication may be determined according to a method specified by an access device (ex. Reader / writer).

The determined authentication methods are A (1) to A (n). Various authentication processing modes are set in the setting registration or deletion processing of the partition to which the partition registration ticket (PRT) is applied. For example, setting and registering a partition requires device authentication for a device, and deleting a partition requires both device authentication and partition authentication to be deleted. In this way, a setting that requires authentication of either one or both can be described in the partition registration ticket (PRT) according to the processing. The authentication method required in the PRT use processing is described in [Authentication Type] of the partition registration ticket (PRT), and the authentication apparatus reads out the authentication method required for using the partition registration ticket (PRT) from the ticket and determines the authentication method. Then, the authentication processing procedure is defined as A (i): A (1) to A (n).

In step S432, the first authentication processing method A (1) is read, and it is determined whether the authentication method of A (1) is device authentication or partition authentication (S433). Execute (S434, S441), and execute partition authentication if it is partition authentication (S435, S44).
2) Do it. As a result of the authentication processing with the device, if the authentication is not successful, the processing ends as an error. If the authentication is successful, i is incremented in step S437, and the process returns to step S433, where the next authentication method is determined, and the authentication is executed according to the method. These processes are called A
The steps from (1) to A (n) are executed, and if all the authentications succeed, the process proceeds to the next step.

The device authentication processing will be described with reference to the flow shown in FIG. In FIG. 49, the left side shows the processing of the device authentication device of the partition manager, and the right side shows the processing of the device (see FIG. 5). The device authentication device of the partition manager is a device (ex. A reader / writer as a device access device, a PC) capable of reading and writing data to and from the device.
Has a configuration corresponding to a reader / writer as a device access device.

In step S451, the device authentication device determines whether a public key authentication scheme using a public key is applied to device authentication processing based on the partition registration ticket (PRT). The device authentication is executed by either the public key method or the common key method, and the specification of the execution method is described in the ticket.

If the common key method is specified, the processing in steps S452 to S455 and S461 to S465 in FIG. 49 is not executed, and the flow advances to step S456. If the public key method is specified, the device authentication device proceeds to step S
At 452, a public key device authentication start command is transmitted to the device. The device receives the command (S46).
1) Then, referring to the public key device key definition block (see FIG. 16) in the memory section of the device, it is verified whether or not the device corresponding public key certificate (CERT DEV) is stored (S462). If the device-compatible public key certificate (CERTDEV) is not stored, mutual authentication using the public key method cannot be executed, and it is determined that an error has occurred, and the process ends.

A public key certificate corresponding to a device (CERT D)
When it is confirmed that the EV is stored, in steps S453 and S463, mutual authentication and key sharing processing using a public key certificate issued by a device manager compatible certificate authority (CA (DEV)) are executed. You.

The mutual authentication and key sharing processing by the public key method will be described with reference to FIG. FIG. 50 shows a 160-bit elliptic curve cryptosystem (EC
5 shows a mutual authentication sequence using C). FIG.
Although ECC is used as a public key cryptosystem in this embodiment, other systems than the public key cryptosystem can be applied. Also, the key size need not be 160 bits. In FIG. 50, B first generates a 64-bit random number Rb.
Send to Upon receiving this, A newly generates a 64-bit random number Ra and a random number Ak smaller than the characteristic p.
Then, a point Av = Ak × obtained by multiplying the base point G by Ak.
G is obtained, and a digital signature A.G for Ra, Rb, Av (X coordinate and Y coordinate) is obtained. Generate Sig and send it back to B along with A's public key certificate. Here, Ra and Rb are each 6
Since the X coordinate and the Y coordinate of the Av are 4 bits and the X coordinate and the Y coordinate of the Av are 160 bits, an electronic signature for a total of 448 bits is generated.

When using the public key certificate, the user verifies the electronic signature of the public key certificate by using the public key of the public key certificate authority (CA) held by the user, and After successful verification of the public key, the public key is extracted from the public key certificate, and the public key is used. Therefore, all users who use the public key certificate have a common public key certificate issuing authority (C
It is necessary to hold the public key of A). The method of verifying the digital signature has been described with reference to FIG.

[0346] public key certificate of A, Ra, Rb, Av, electronic signature A. B that has received Sig, R that A has transmitted
Verify that b matches the one generated by B. As a result, if they match, the electronic signature in the public key certificate of A is verified with the public key of the certificate authority, and the public key of A is extracted. Then, using the public key of the extracted A, the digital signature A.
Verify Sig. After successfully verifying the electronic signature, B authenticates A as valid.

Next, B generates a random number Bk smaller than the characteristic p. And the point B obtained by multiplying the base point G by Bk
v = Bk × G, and a digital signature B.V. for Rb, Ra, Bv (X coordinate and Y coordinate). Generate Sig and send it back to A along with B's public key certificate.

B public key certificate, Rb, Ra, Bv, digital signature A that has received Sig, R that B has transmitted
Verify that a matches the one generated by A. As a result, if they match, the electronic signature in B's public key certificate is verified with the public key of the certificate authority, and B's public key is extracted. Then, using the public key of B, the digital signature B.
Verify Sig. After successfully verifying the electronic signature, A authenticates B as valid.

If both are successfully authenticated, B becomes Bk
XAv (Bk is a random number, but Av is a point on an elliptic curve, so a scalar multiplication of a point on the elliptic curve is required), A calculates Ak × Bv, and calculates the X coordinate of these points The lower 64 bits are used as a session key for subsequent communication (when the common key encryption is a 64-bit key length common key encryption). Of course, the session key may be generated from the Y coordinate, and may not be the lower 64 bits. In the secret communication after the mutual authentication, the transmission data may not only be encrypted with the session key but also may be digitally signed.

In the verification of the electronic signature and the verification of the received data, if an invalid or inconsistent is found, the processing is interrupted assuming that the mutual authentication has failed.

In such a mutual authentication process, the transmission data is encrypted using the generated session key, and the data communication is performed mutually.

Returning to FIG. 49, the description of the flow will be continued. If the mutual authentication and key sharing processing as described above are successful in steps S453 and S463, the device proceeds to step S453.
At 464, CRL_DEV stored in the device key area (see FIG. 18) of the memory unit of the device: excluded device (D
evice), the public key certificate identifier (ex. serial number: S) of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit)
N) registered revocation list (Revocation Lis
With reference to t (Certificate), it is verified whether the device authentication device that is the communication partner has been revoked. If revoked, the partition creation process cannot be permitted, and the process ends as an error.

[0353] If you have not been revoked, the step S
At 465, the session key Kses generated in the mutual authentication and key sharing process and the identifier (DN :) in the public key certificate of the communication partner (a reader / writer as a device access device constituting the device authentication device, a PC, etc.).
Distinguished Name), serial number, and category are stored in an authentication table in which the device manager code (DMC) is used as a key.

On the other hand, the device authentication device also performs step S4.
At 54, check if the device has been revoked
L_DEV: Public key certificate identifier (e) of an exclusion device (Device), an exclusion device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit)
x. The determination is made with reference to a revocation list (Revocation List (Certificate)) in which the serial number (SN) is registered. The device authentication device can acquire the revocation list (CRL_DEV) from the registration authority (RA (PAR)). If revoked, the partition creation process cannot be permitted, and the process ends as an error.

If not revoked, step S
At 455, the session key Kses generated in the mutual authentication and key sharing process and the communication partner (device)
Distinguished Nam (DN) in the public key certificate of
e) The serial number and category are stored in an authentication table in which the device manager code (DMC) is used as a key.

FIG. 51 shows an example of an authentication table generated in the device, and FIG. 52 shows an example of an authentication table generated in a reader / writer (PC is also possible) as a device access device as an authentication device.

FIG. 51 shows device authentication and partitions 1 and 2 serving as partition authentication described later.
7 is an example of an authentication table generated in the device at the time when the authentication of No. 2 is completed. As a group, a device manager code (DM
C) In the case of partition authentication, a partition manager code (PMC) is recorded, and respective data is stored according to each authentication method executed. In the case of the public key authentication method, as described above, the session key Kses
And a distinguished name (DN: Distinguishe) in a public key certificate of a communication partner (a reader / writer as a device access device).
d Name), serial number, and category are stored in a table. In the case of common key authentication, the session key Kses
And an identifier (ID RW) of a communication partner (a reader / writer as a device access device).

The authentication table is discarded when the session is cleared. The device can confirm the authentication state of the device and each partition by referring to the information in the table, and can confirm the session key to be used.

On the other hand, FIG. 52 shows an authentication table on the reader / writer side as a device access device. This example is also an example of the authentication table at the time when the device authentication and the authentication of the partitions 1 and 2 as the partition authentication are completed. The basic configuration is the same as the authentication table in the device. As a group, a device manager code (DM) is used for device authentication.
C) In the case of partition authentication, a partition manager code (PMC) is recorded, and respective data is stored according to each authentication method executed. In the case of the public key authentication method, as described above, the session key Kses
And the distinguished name (DN: Distinguished Name), serial number, and category in the public key certificate of the communication partner (device) are stored in a table. In the case of common key authentication,
The session key Kses and the identifier (ID RW) of the communication partner (device) are stored. The authentication table on the reader / writer side is also destroyed when the session is cleared. On the reader / writer side as a device access device,
By referring to the information in the authentication table, it is possible to determine the presence or absence of the authentication state of the device and the partition, and it is possible to confirm the session key to be used.

Returning to FIG. 49, description of the device authentication processing will be continued. If the device authentication device determines in step S451 that the device authentication method is not the public key method, the device authentication device outputs a common key device authentication command to the device in step S456. When the device receives the command (S466), the common key device key definition block (FIG.
It is verified whether or not the master key for bidirectional individual key authentication (MKauth_DEV) used for the common key authentication is stored (S467). If the master key for two-way individual key authentication (MKauth_DEV) is not stored, mutual authentication using the common key method cannot be executed, and it is determined that an error has occurred, and the process ends.

A master key for bidirectional individual key authentication (MKauth_
If it is confirmed that DEV) is stored, mutual authentication and key sharing using the master key are executed in steps S457 and S468.

[0362] Mutual authentication and key sharing processing based on a common key method using a master key will be described with reference to FIG. In FIG. 53, A and B are entities that execute authentication using a common key method using a master key.
Is the identifier IDa of itself, the common key K for bidirectional individual key authentication,
a, having a master key MKb for two-way individual key authentication,
Is the identifier IDb of itself, the common key K for bidirectional individual key authentication,
b. It has a master key MKa for two-way individual key authentication. In the example of FIG. 53, the DES algorithm (ex. DES, triple DES) is used as the common key encryption method, but other encryption methods can be applied as long as the same common key encryption method is used.

First, B generates a 64-bit random number Rb and transmits Rb and its own IDb IDb to A. Upon receiving this, A newly generates a 64-bit random number Ra
Is generated, and the common key Kb for bidirectional individual key authentication is obtained by DES encryption processing of IDb using the master key MKb for bidirectional individual key authentication. Further, using the keys Ka and Kb,
The data is encrypted in the CBC mode of DES in the order of Ra, Rb, IDa, and IDb, and returned to B together with its own identifier IDa.

[0364] Upon receiving this, B first obtains the bidirectional individual key authentication common key Ka by DES encryption processing of the IDa using the bidirectional individual key authentication master key MKa. Further, the received data is decrypted with the keys Ka and Kb. It verifies that Rb and IDb of Ra, Rb, IDa, and IDb obtained by decryption match those transmitted by B. If the verification passes, B authenticates A as valid.

Next, B is used as a session key.
A 4-bit random number Kses is generated, and the keys Kb and Ka are used to generate Db in the order of Rb, Ra, IDb, IDa, and Kses.
The data is encrypted in the CBC mode of the ES and returned to A.

[0367] Upon receiving this, A
Decrypt with a and Kb. Ra, Rb, I obtained by decoding
It is verified whether Da and IDb match those transmitted by A. If the verification passes, A authenticates B as valid. After mutually authenticating each other, the session key Kses is used as a common key for secret communication after authentication.

[0367] Note that, when the received data is verified, if an invalid or mismatch is found, the process is stopped assuming that the mutual authentication has failed.

[0368] The common key authentication using the master key associated with the stored data in the system of the present invention is a diagram for explaining the flow of data in FIG. 54. As shown in FIG. 54, a reader / writer (R /
W) generates a 64-bit random number Rb, and transmits Rb and its own ID, IDrw, to the device (Device). The device (Device) receiving this
A new 64-bit random number Ra is generated, and the DES of IDrw based on the master key MKauth_DEV_A for bidirectional individual key authentication is generated.
Common key Kauth_DEV for two-way individual key authentication by encryption processing
Get _A. Further, keys Kauth_DEV_A and Kauth_DEV_B
, The data is encrypted in the order of Ra, Rb, and IDrw, for example, in a DES-CBC mode as an encryption algorithm, and returned to a reader / writer (R / W) as a device access device together with its own identifier IDm.

A reader / writer (R / W) receiving this
Is a master key MKauth_DEV_ for two-way individual key authentication.
A bidirectional individual key authentication common key Kauth_DEV_B is obtained by the DES encryption processing of IDm by B. Further, it decrypts the received data with the keys Kauth_DEV_A and Kauth_DEV_B. It verifies whether Rb and IDrw obtained by decoding match those transmitted by a reader / writer (R / W) as a device access device. If this verification is passed, the reader / writer (R / W) authenticates the device (Device) as valid.

Next, the reader / writer (R / W) generates a 64-bit random number Kses used as a session key, and generates a common key Kauth_DEV_A, Kauth_
Using DEV_B, DES in the order of Rb, Ra, Kses
The data is encrypted in, for example, a triple DES mode as an algorithm, and is returned to the device (Device).

[0371] The device that has received the data exchanges the received data with the bidirectional individual key authentication common keys Kauth_DEV_A and Kauth_DEV_.
Decrypt with B. Ra, Rb, IDrw obtained by decryption
Is matched with the one transmitted by the device (Device). If this verification is passed, the device (Dev
ice) authenticates the reader / writer (R / W) as valid, and after the authentication, uses the session key Kses as a common key for secret communication.

Note that IDm as a unique value of the device
Can apply a value based on the data stored in the device manager management area as described above using the device memory format of FIG.

As described above, according to the mutual authentication and the key sharing process using the common key method using the master key, the individual key of the communication partner generated by executing the process based on the master key of the communication partner and the own key of the communication partner are used. Since the two keys of the individual keys are set as the common key and mutual authentication is performed by the common key method using the set two keys, the conventional common key in which the common key is stored in the device or the access device in advance. more secure authentication system and method compared to the key authentication is achieved.

Returning to FIG. 49, the description of the flow will be continued. If the above-described mutual authentication and key sharing processing are successful in steps S457 and S468, the device proceeds to step S457.
At 469, the IRL_DEV stored in the device key area (see FIG. 18) of the memory unit of the device: the excluded device (D
evice), a revocation list (Revocation List (ID)) in which identifiers (IDs) of excluded devices (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing means) are registered, and the communication partner Verify whether a certain device authentication device has been revoked. If revoked, the partition creation process cannot be permitted, and the process ends as an error.

If not revoked, step S
In 470, the session key Kses generated in the mutual authentication and key sharing process and the identification information (IDrw) of the communication partner (a reader / writer as a device access device constituting the device authentication device, PC, etc.) are stored in a device manager code (DMC) Is stored in an authentication table (see FIG. 51) associated with the key.

On the other hand, the device authentication device also performs step S4.
At 58, it is determined whether the device has been revoked.
RL_DEV: Refers to the revocation list (Revocation List (ID)) in which the identifiers (ID) of the exclusion device (Device) and the exclusion device (a reader / writer as a device access device, a ticket user such as a PC, and a ticket issuing means) are registered. Judgment. The device authentication device can acquire the revocation list (IRL_DEV) from the registration authority (RA (PAR)). If revoked, the partition creation process cannot be permitted, and the process ends as an error.

If not revoked, step S
In step 459, the session key Kses generated in the mutual authentication and key sharing process and the communication partner (device)
Identification information (IDm) of the device manager code (D
MC) as a key and stored in an authentication table (see FIG. 52).

The above process is a device authentication process executed between a device and a reader / writer as a device access device controlled by the partition manager.

Next, steps S435 and S44 in FIG.
2 will be described with reference to FIGS. 55 and 56. In the setting registration or deletion processing of the partition to which the partition registration ticket is applied, either the device authentication or the partition authentication, or both authentications are required according to the processing as described above. These settings are described in the partition registration ticket (PRT). If the partition registration ticket (PRT) includes a description for executing the partition authentication, the partition authentication is executed.

Each step of the processing flow of FIGS. 55 and 56 will be described. In FIG. 55, the left side shows the processing of the partition authentication device of the partition manager, and the right side shows the processing of the device (see FIG. 5). Note that the partition authentication device of the partition manager is a device (ex. Reader / writer, PC as a device access device) capable of performing data read / write processing on a device, and has a configuration corresponding to the reader / writer as a device access device in FIG. Have.

[0381] The partition authentication device executes the step S4
At 71, a partition A existence check command for executing the existence confirmation of the partition A to be authenticated is output to the device. Command is received (S48
The device that has performed 1) checks whether the partition A exists in the memory unit of the device (S482). Here, as the partition identifier A, for example, a partition manager code (PMC) is used.
The device is, for example, a partition definition block (PD
B: The presence or absence of a partition can be determined based on the stored PMC of the Partition Definition Block. When the presence or absence of a partition by the device is determined, a check result is transmitted to the partition authentication device.

The partition authentication device that has received the check result (S472) verifies the check result (S47).
3) If a result indicating that there is no partition is received, authentication is not possible, and the process ends with an error. If the check result indicates that a partition exists, the partition authentication device determines in step S474 whether to apply a public key authentication method using a public key to the partition authentication process based on the partition registration ticket (PRT). Is determined. Similar to the device authentication described above, the partition authentication is executed in either the public key method or the common key method, and the specification of the execution method is described in the ticket.

If the common key method is specified, the processing in steps S475 to S478 and S484 to S488 in FIG. 55 is not executed, and the flow advances to step S491. If the public key method is specified, the partition authentication device transmits a public key partition A authentication start command to the device in step S475. Upon receiving the command (S484), the device refers to the public key system partition key definition block (see FIG. 21) in the memory section of the device and refers to the partition A-compatible public key certificate (CERT).
PAR) is stored (S485).
I do. Public key certificate for partition A (CERT
If PAR is not stored, the public key mutual authentication cannot be performed, and it is determined that an error has occurred, and the process is terminated.

A public key certificate corresponding to partition A (CE
RT PAR) is stored,
In steps S476 and S486, mutual authentication and key sharing processing using a public key certificate issued by a partition manager compatible certification authority (CA (PAR)) are executed.

The mutual authentication and key sharing processing by the public key method is the same as the sequence shown in FIG. 50 described in the previous device authentication processing, and the description is omitted. However, the public key certificate used in the partition authentication is a partition manager compatible certificate authority (C
A (PAR)), and the public key (PUB CA) of the partition manager-compatible certificate authority (CA (PAR)) is used to verify the signature of the public key certificate.
(PAR)). Public key (PUB CA (PA
R)) are stored in the partition key area (see FIG. 23). In such a mutual authentication process, the transmission data is encrypted using the generated session key, and data communication is performed with each other.

In steps S476 and S486, FIG.
If the mutual authentication and the key sharing process according to the sequence shown in FIG. 0 are successful, the device determines in step S487 that the CRL_PAR stored in the partition key area (see FIG. 23) of the memory portion of the device:
A revocation list (Revocation List (Certi) in which the public key certificate identifier (ex. Serial number: SN) of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, and a ticket issuing unit) is registered.
With reference to ficate), it verifies that the partition authentication device that is the communication partner has not been revoked. If revoked, the process of creating or deleting a partition cannot be permitted, so the process ends as an error.

If not revoked, step S
At 488, the session key Kses generated in the mutual authentication and key sharing process and the identification name (DN: Distinguished) in the public key certificate of the communication partner (a reader / writer as a device access device constituting the partition authentication device, a PC, etc.). Name), serial number, category, partition manager code (PMC)
Is stored in the authentication table associated with the key as a key.

On the other hand, in step S477, the partition authentication device also checks whether the device has been revoked. CRL_PAR: exclusion device (Device), exclusion device (reader / writer as device access device, ticket user such as PC, ticket issuing means) ) Is determined with reference to a revocation list (Revocation List (Certificate)) in which the public key certificate identifier (ex. Serial number: SN) is registered. The device authentication device can acquire the revocation list (CRL_PAR) from the registration authority (RA (PAR)). If revoked, partition creation or deletion cannot be allowed, so
The process ends as an error.

If not revoked, step S
At 478, the session key Kses generated in the mutual authentication and key sharing process and the communication partner (device)
Distinguished Nam (DN) in the public key certificate of
e) The serial number and the category are stored in an authentication table in which the partition manager code (PMC) is used as a key. As a result, for example, the authentication table shown in FIG. 51 is generated in the device, and the authentication table shown in FIG. 52 is generated in a reader / writer (PC is also possible) as a device access device as a partition authentication device. FIGS. 51 and 52 show examples of the authentication table generated in the device and the reader / writer as the device access device when the device authentication and the authentication of the partitions 1 and 2 as the partition authentication are completed.

[0390] In the case of partition authentication, a partition manager code (PMC) is recorded, and data is stored according to each authentication method executed. In the case of the public key authentication method, as described above, the session key K
ses and the distinguished name (DN:
Distinguished Name), serial number, and category are stored in a table. In the case of common key authentication, a session key Kses and an identifier of a communication partner are stored. The authentication table is destroyed when the session is cleared. The reader / writer as a device and device access device can confirm the authentication status of the device and each partition by referring to the information in the table,
The session key to be used can be confirmed.

The description of the partition authentication processing will be continued with reference to the flowcharts of FIGS. 55 and 56. If the partition authentication device determines in step S474 that the partition authentication method is not the public key method, the partition authentication device outputs a common key partition A authentication command to the device in step S491. Upon receiving the command (S501), the device refers to the common key system partition key definition block (see FIG. 22) in the memory portion of the device and obtains the master key (MKauth_PAR_A) for bidirectional individual key authentication used for common key authentication. It is verified whether or not it is stored (S502). If the master key for two-way individual key authentication (MKauth_PAR_A) is not stored, mutual authentication using the common key method cannot be executed, and it is determined that an error has occurred, and the process ends.

A master key for bidirectional individual key authentication (MKauth_
When it is confirmed that PAR_A) is stored, mutual authentication and key sharing processing using the master key are executed in steps S492 and S503. Mutual authentication and key sharing processing using the common key method are the same as the sequence described with reference to FIGS. 53 and 54 in the previous device authentication, and thus description thereof is omitted. However, the key to be applied in the case of the partition authentication is defined in the partition key definition block (see FIG. 22), and the bidirectional individual key authentication common key (Kauth_PAR_B) stored in the partition key area (see FIG. 23), and Master key for bidirectional individual key authentication (MKauth_PAR_A).

When the mutual authentication and key sharing processing of the common key method are successful in steps S492 and S503, the device determines in step S504 the IRL_ stored in the partition key area (see FIG. 23) of the memory section of the device.
PAR: Refers to a revocation list (Revocation List (ID)) in which identifiers (IDs) of rejected devices (Device) and rejected devices (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit) are registered. Then, it verifies whether the partition authentication device that is the communication partner has been revoked. If revoked, the process of creating or deleting a partition cannot be permitted, so the process ends as an error.

If not revoked, step S
At 505, the session key Kses generated in the mutual authentication and key sharing process and the identification information (IDrw) of the communication partner (a reader / writer as a device access device constituting a device authentication device, a PC, etc.) are stored in a partition manager code (PMC). Is stored in an authentication table (see FIG. 51) associated with the key.

On the other hand, in step S493, the partition authentication device also checks whether the device has been revoked. IRL_PAR: Excluded device (Device), excluded device (reader / writer as device access device, ticket user such as PC, ticket issuing means) Revocation List (I) that registers the identifier (ID) of
Judgment is made with reference to D)). The partition authentication device is
Register the revocation list (IRL_PAR) with the registration authority (RA (P
AR)). If revoked, the process of creating or deleting a partition cannot be permitted, so the process ends as an error.

If not revoked, step S
At 494, the session key Kses generated in the mutual authentication and key sharing process and the communication partner (device)
The identification information (IDm) is stored in an authentication table (see FIG. 52) in which the partition manager code (DMC) is used as a key.

The above processing is the partition authentication processing executed between a device and a reader / writer as a device access device under the control of the partition manager. By such mutual authentication, authentication between the device or partition and the reader / writer as the device access device is established, sharing of the session key is achieved, and encrypted communication of the communication data using the session key becomes possible.

[0398] The above-described device authentication processing and partition authentication processing are performed in accordance with another ticket, that is, a file registration ticket (FRT).
Service Permission Ticket (SPT)
icket), data update ticket (DUT: Data)
This is a process that is also performed as needed when device access using Update Ticket) is performed. These will be described later in the description of processing using each ticket.

(Ticket validity and user check) Next, details of the ticket validity and user check processing in the device in step S413 in the partition creation / deletion processing flow of FIG. 47 are shown in FIGS. 57 and 58.
This will be described using the flow of FIG.

Note that the ticket validity and user check processing described below is performed for another ticket, that is, a file registration ticket (FRT: File Registration Ticke).
t), Service Permission Ticket (SPT: Service Permiss)
ion Ticket), Data Update Ticket (DUT:
FIG. 5 is a process performed as needed in the device access process using the Data Update Ticket.
7, the flow of FIG. 58 is configured as a processing flow common to each ticket.

The validity of the ticket and the user check process are performed by the ticket user (ex. A reader / writer as a device access device,
This is a process executed by the device (see FIG. 5) based on a ticket received from a PC or the like. The device checks the validity of the ticket and the validity of the user who is the ticket user (ex. A reader / writer as a device access device, a PC, etc.) in the user check processing, and then checks the validity of the ticket and the restricted range described in the ticket. Allow processing within.

The validity of the ticket and the details of the user check process will be described with reference to the flowcharts of FIGS. 57 and 58. The device that has received the ticket from the ticket user (ex. A reader / writer as a device access device, a PC, etc.) verifies the ticket type in step S511 in FIG. 57, and the ticket is a partition registration ticket (PRT). It is determined whether or not. The ticket type is recorded in each ticket (FIGS. 26, 27, 28, 31, and 3).
2).

[0403] ticket type partition registration ticket (PRT: Partition Registration Ticket) if it is to perform a step S512~S514, partition registration ticket (PRT: Partition Registra
If not (Operation Ticket), the process proceeds to step S515.

[0404] ticket type partition registration ticket (PRT: Partition Registration Ticket) if it is, in step S512, the type of the validity verification value of the ticket to the described Integrity Check Type (ticket (Ticket) (public key system ( Public) / shared key method (C
ommon))) It is determined whether the setting is the public key method (Public).

[0405] Type of Integrity Validation Value (Integrity Check Ty
If (pe) is the public key method (Public), step S51
Proceed to 3 to execute various processes. The process executed in step S513 is first a process of verifying the public key certificate (CERT) of the ticket issuer (Ticket Issuer) using the public key PUB CA (DEV) of the certificate authority (CA (DEV)) corresponding to the device manager. It is.

As described above, when transmitting the ticket (Ticket) issued by the partition registration ticket (PRT) issuing means (PRT Issuer) to the ticket user, in the case of the public key method, the partition registration ticket (PRT) is issued. (PRT) Issuing means (PRT Issuer) public key certificate (CE
RT_PRTI) is also sent to the device. In addition, PR
Attributes of public key certificate (CERT_PRTI) of T issuing means (Attri
bute) matches the identifier (PRTIC) of the partition registration ticket (PRT) issuing means (PRT User).

The public key certificate (see FIG. 11) is provided with a signature executed with the private key of the CA (DEV) corresponding to the device manager, and this signature is attached to the CA (CA (DEV)). DEV)) public key PUB
Verification is performed using CA (DEV). The signature generation and verification are executed, for example, as processing according to the flowcharts of FIGS. 12 and 13 described above. By this signature verification, it is determined whether or not the ticket issuer's public key certificate (CERT) is a legitimate public key certificate (CERT) that is not falsified.

[0408] Further, in step S513, the code as the category of the user recorded in the option area of the public key certificate (CERT) of the ticket issuing means whose validity has been confirmed by signature verification is stored in the DKDB in the device.
(Device Key Definition Block) (PUB) recorded ticket issuing means code (PRTIC: PRT Issuer Cod)
j) Whether or not it matches e) is determined.

As described in the description of the public key certificate in FIG. 11, each ticket (PRT, FRT) is included in the public key certificate.
RT, SPT, etc.), the affiliation code of the ticket issuing means (Ticket Issuer), in this case, PRTI
C (PRT Issuer Code) is recorded. The code in this optional area and the DKDB (Device Key
Confirm that the received ticket (PRT) is a ticket issued by a valid ticket issuing unit by confirming the match of the ticket issuing unit code (PRTIC: PRT Issuer Code) recorded in the Definition Block (PUB) I do.

[0410] Further, the device stores the CRL_DE stored in the device key area (see Fig. 18) in the memory section of the device.
V (device), the public key certificate identifier of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit) (ex.
Refer to the revocation list (Revocation List (Certificate)) in which the serial number (SN) is registered.
It is determined whether the ticket issuing means (Ticket Issuer) has not been revoked.

Further, the signature recorded in the partition registration ticket (PRT) (see FIG. 26) which is the reception ticket, that is, Integrity Check Value (Ticket (Ti
cket) (public key method: signature (Signatur
e) Perform the verification in ()) to confirm that the ticket has not been tampered with. The signature verification is executed, for example, according to the same sequence as the flow in FIG.

As described above, (1) Ticket Issuer
uer) public key certificate (CERT) is a legitimate public key certificate (CERT) that has not been tampered with;
(2) The code recorded in the option area of the public key certificate (CERT) of the ticket issuer (Ticket Issuer) and the DKDB (Device Key Definition Bl) in the device
ock) (PUB) recorded ticket issuing means code (PR
TIC: PRT Issuer Code), (3) that ticket issuer (Ticket Issuer) has not been revoked, (4) signature of received ticket (PRT) (Signatur
Confirmation that the ticket is not falsified by the verification in e). It is determined that the validity of the ticket has been successfully verified on condition that all the above confirmations have been made. If any of the above (1) to (4) is not confirmed, it is determined that the validity of the ticket cannot be confirmed, and the partition registration ticket (P
Processing using RT (Partition Registration Ticket) is stopped.

[0413] In addition, in step S512, is described in the ticket was Integrity Check Type (ticket (Tick
If it is determined that the setting of the type (public key method (Public) / common key method (Common)) of the validity verification value of (et) is the common key method (Common), the process proceeds to step S514 and the MAC
(Message Authentication Code) Performs verification. The device determines the M of the partition registration ticket (PRT) stored in the device key area (see FIG. 18) of the device.
An AC verification key: Kprt is used to execute a ticket MAC verification process.

FIG. 59 shows an MA using the DES encryption processing configuration.
An example of generating a C value will be described. As shown in the configuration of FIG. 59, the target message is divided into 8-byte units (hereinafter, the divided messages are referred to as M1, M2,..., MN).
First, the initial value (Initial Value (hereinafter referred to as IV))
And M1 are XORed (the result is I1).
Next, I1 is put into the DES encryption unit, and the MAC verification key:
Encrypt using Kprt (output is E1). Then, E1 and M2 are XORed, and the output I2
Into the DES encryption unit, and encrypts the DES using the key Kprt (output E2). Hereinafter, this is repeated, and encryption processing is performed on all messages. The last EN that appears is a message authentication code (MAC).
Code)). Note that partial data constituting data to be verified can be used as the message.

[0415] For example, an ICV (Integrity Ch.
eck Value) is compared with the ICV generated by the data receiving side based on the received data. If the same ICV is obtained, it is guaranteed that the data has not been tampered with. If the ICVs are different, it is determined that the data has been tampered with. . For example, the data generated by the data transmission side when data is
The CV uses the partition registration ticket (PR
As described in the description regarding the format of T), the information is stored in the ICV (Integrity Check Value) field of the PRT. The ICV generated by the device is compared with the ICV stored in the received ticket (PRT). If they match, it is determined that the ticket is valid. If they do not match, it is determined that the ticket has been tampered, and the ticket is used. Cancel processing.

[0416] The information described in the ticket by the above processing
The ticket verification processing when the Integrity Check Type is the common key method is completed.

[0417] Returning to the flow of Fig. 57, description of ticket validity and user check processing will be continued. In step S511, the ticket type is a partition registration ticket (PRT: Partition Registration Ticke).
If not, the ticket type is verified in step S515 to determine whether the ticket is a file registration ticket (FRT: File Registration Ticket).

When the ticket type is a file registration ticket (FRT: File Registration Ticket),
Steps S516 to S518 are executed, and if it is not a file registration ticket (FRT: File Registration Ticket), the process proceeds to step S519.

[0419] If the ticket type is a file registration ticket (FRT: File Registration Ticket),
In step S516, the Inte described in the ticket
grityCheck Type (Type of validity verification value of ticket (Ticket) (Public key method (Public) / Common key method (Common)))
It is determined whether or not the setting is public key method (Public).

The type of the validity verification value (Integrity Check Ty
If (pe) is the public key method (Public), step S51
Proceed to 7 to execute various processes. First, the process executed in step S517 includes the public key PUB CA (PA) of the partition manager compatible certificate authority (CA (PAR)).
R) is a process for verifying the public key certificate (CERT) of the ticket issuer (Ticket Issuer).

When the ticket (Ticket) issued by the file registration ticket (FRT) issuance means (FRT Issuer) is transmitted to the ticket user, in the case of the public key system, the file registration ticket (FRT) issuance means ( FRT Is
suer) 's public key certificate (CERT_FRTI) is also sent to the device. Note that the attribute (Attribute) of the public key certificate (CERT_FRTI) of the FRT issuing unit matches the identifier (FRTIC) of the file registration ticket (FRT) issuing unit (FRT Issuer).

The public key certificate (see FIG. 11) has a signature executed with the private key of the CA (PAR) corresponding to the partition manager, and this signature is assigned to the CA (CA (PAR)). PAR)) using the public key PUB CA (PAR). The signature generation and verification are executed, for example, as processing according to the flowcharts of FIGS. 12 and 13 described above. By this signature verification, it is determined whether or not the ticket issuer's public key certificate (CERT) is a legitimate public key certificate (CERT) that is not falsified.

In step S517, the user's affiliation code recorded in the option area of the public key certificate (CERT) of the ticket issuing means whose validity has been confirmed by signature verification and the PKDB (Partition Ke
It determines whether or not it matches the ticket issuing means code (FRTIC: FRT Issuer Code) recorded in the y Definition Block (PUB).

The public key certificate includes each ticket (PRT, FRT) as described in the description of the public key certificate in FIG.
RT, SPT, etc.), the affiliation code of the ticket issuing means (Ticket Issuer), in this case FRTI
C (FRT Issuer Code) is recorded. The code in this optional area and the PKDB (PartitionK
The received ticket (FRT) is a ticket issued by a valid ticket issuing unit by confirming the match of the ticket issuing unit code (FRTIC: FRT Issuer Code) recorded in the ey Definition Block (PUB) Check.

Further, the device is stored in the partition key area (see FIG. 23) in the memory section of the device.
CRL_PAR (rejection device (Device), revocation list (ex. Serial number: SN) in which the public key certificate identifier (ex. Serial number: SN) of the exclusion device (reader / writer as device access device, ticket user such as PC, ticket issuing means) Revocation List (Certificate)) to determine whether the ticket issuing means (Ticket Issuer) has been revoked.

[0426] Further, the recorded signed a received ticket file registration ticket (FRT) (see FIG. 27),
That is, Integrity Check Value (Ticket)
Verification value (public key method: Signature))
And verify that the ticket has not been tampered with. The signature verification is executed, for example, according to the same sequence as the flow in FIG.

As described above, (1) Ticket issuer (Ticket Iss
uer) public key certificate (CERT) is a legitimate public key certificate (CERT) that has not been tampered with;
(2) The code recorded in the option area of the public key certificate (CERT) of the ticket issuer (Ticket Issuer) and the PKDB (Partition Key Definition) in the device
Block) (PUB), the matching of the ticket issuing means code (FRTIC: FRT Issuer Code), (3) that the ticket issuing means (Ticket Issuer) has not been revoked, (4) the signature of the received ticket (FRT) (Signat
ure) to confirm that the ticket has not been tampered with.
The validity verification of the file registration ticket (FRT) is determined to be successful on condition that all the above confirmations are made. If any of the above (1) to (4) is not confirmed, it is determined that the validity of the file registration ticket (FRT) cannot be confirmed, and the process using the file registration ticket (FRT) is stopped. .

[0428] Also, in step S516, the Integrity Check Type (ticket (Tick
If it is determined that the setting of the type (public key method (Public) / common key method (Common)) of the validity verification value of (et) is the common key method (Common), the process proceeds to step S518 and the MAC
(Message Authentication Code) Performs verification. The device stores the M of the file registration ticket (FRT) stored in the partition key area (see FIG. 23) of the device.
Using the AC verification key: Kfrt, the MAC verification process of the ticket is executed. The MAC verification processing is executed according to the MAC value generation processing using the DES encryption processing configuration of FIG. 59 described above.

For example, an ICV (Integrity Ch) generated at the time of data generation by the data transmitting side, which is guaranteed not to be falsified,
eck Value) is compared with the ICV generated by the data receiving side based on the received data. If the same ICV is obtained, it is guaranteed that the data has not been tampered with. If the ICVs are different, it is determined that the data has been tampered with. . For example, the data generated by the data transmission side when data is
As described in the description of the format of the file registration ticket (FRT) in FIG.
It is stored in the ICV (Integrity Check Value) field of T. The ICV generated by the device is compared with the ICV stored in the received ticket (FRT). If they match, it is determined that the ticket is valid. If they do not match, it is determined that the ticket has been altered, and the ticket is used. Cancel processing.

[0430] The information described in the ticket by the above processing
The file registration ticket (FRT) verification processing when the Integrity Check Type is the common key method is completed.

[0431] In step S515, the ticket type is a file registration ticket (FRT: File Registratio).
n Ticket), the process proceeds to step S51.
In step 9, the ticket type is verified and the ticket is a service permission ticket (SPT).
Is determined.

If the ticket type is a service permission ticket (SPT: Service Permission Ticket), steps S520 to S522 are executed. If the ticket type is not a service permission ticket (SPT: Service Permission Ticket), the process proceeds to step S523.

If the ticket type is a service permission ticket (SPT: Service Permission Ticket), in step S520, the
IntegrityCheck Type (Type of validity verification value of ticket (Ticket) (Public key method (Public) / Common key method (Commo
n)) It is determined whether the setting of ()) is a public key method (Public).

The type of integrity check value (Integrity Check Ty
If (pe) is the public key method (Public), step S52
Proceed to 1 to execute various processes. First, the process executed in step S521 includes the public key PUB CA (PA) of the partition manager compatible certificate authority (CA (PAR)).
R) is a process for verifying the public key certificate (CERT) of the ticket issuer (Ticket Issuer).

When the ticket (Ticket) issued by the service permission ticket (SPT) issuance means (SPT Issuer) is transmitted to the ticket user, in the case of the public key method, the service permission ticket (SRT) issuance means ( SPT Is
suer) 's public key certificate (CERT_SPTI) is also sent to the device. Note that the attribute (Attribute) of the public key certificate (CERT_SPTI) of the SPT issuing means is the identifier (SPT) of the service permission ticket (SPT) issuing means (SPT Issuer).
IC).

The public key certificate (see FIG. 11) has a signature executed with the private key of the CA (PAR) corresponding to the partition manager, and this signature is provided to the CA (CA (PAR) corresponding to the partition manager). PAR)) using the public key PUB CA (PAR). The signature generation and verification are executed, for example, as processing according to the flowcharts of FIGS. 12 and 13 described above. By this signature verification, it is determined whether or not the ticket issuer's public key certificate (CERT) is a legitimate public key certificate (CERT) that is not falsified.

[0437] Further, in step S521, the user's belonging code recorded in the option area of the public key certificate (CERT) of the ticket issuing means whose validity has been confirmed by signature verification and the file definition block (FDB) in the device. : File Definition Block) recorded ticket issuing means code (SPTIC: SPT Issuer Code)
Is determined.

As described in the description of the public key certificate in FIG. 11, each ticket (PRT, FRT) is included in the public key certificate.
RT, SPT, etc.), the affiliation code of the ticket issuing means (Ticket Issuer), in this case SPTI
C (SPT Issuer Code) is recorded. The code in this optional area and the FDB (File Definit
ticket issuing means code (S
By confirming that PTIC (SPT Issuer Code) matches, it is confirmed that the received ticket (SPT) is a ticket issued by a valid ticket issuing unit.

Further, the device is stored in the partition key area (see FIG. 23) in the memory section of the device.
CRL_PAR (rejection device (Device), revocation list (ex. Serial number: SN) in which the public key certificate identifier (ex. Serial number: SN) of the exclusion device (reader / writer as device access device, ticket user such as PC, ticket issuing means) is registered Revocation List (Certificate))) to determine whether the ticket issuing means (Ticket Issuer) has been revoked.

Further, the signature recorded in the service permission ticket (SPT) (see FIGS. 28 and 31) which is a received ticket, that is, the integrity check value (validity verification value of the ticket (Ticket) (public key method: signature ( Signat
ure)) to verify that the ticket has not been tampered with. The signature verification is executed, for example, according to the same sequence as the flow in FIG.

As described above, (1) Ticket issuer (Ticket Iss
uer) public key certificate (CERT) is a legitimate public key certificate (CERT) that has not been tampered with;
(2) The code recorded in the option area of the public key certificate (CERT) of the ticket issuer (Ticket Issuer) and the ticket issuing means code (SPTIC: SPT) recorded in the FDB (File Definition Block) in the device
Issuer Code), (3) Ticket issuing means (Ticke
(4) Confirm that the ticket has not been tampered with by verifying the signature of the received ticket (SPT). The service permission ticket (SP
It is determined that the validity verification of T) is successful. If any of the above (1) to (4) is not confirmed, it is determined that the validity of the service permission ticket (SPT) cannot be confirmed, and the process using the service permission ticket (SPT) is stopped. .

In step S520, the Integrity Check Type (ticket (Tick
If the setting of the type (public key method (Public) / common key method (Common)) of the validity verification value of et) is determined to be the common key method (Common), the process proceeds to step S522 and the MAC
(Message Authentication Code) Performs verification. The device checks the M of the service permission ticket (SPT) stored in the file definition block (see FIG. 24) of the device.
An AC verification key: Kspt is used to execute a ticket MAC verification process. The MAC verification processing is executed according to the MAC value generation processing using the DES encryption processing configuration of FIG. 59 described above.

[0443] For example, an ICV (Integrity Ch) generated at the time of data generation by the data transmitting side, which is guaranteed not to be falsified, is used.
eck Value) is compared with the ICV generated by the data receiving side based on the received data. If the same ICV is obtained, it is guaranteed that the data has not been tampered with. If the ICVs are different, it is determined that the data has been tampered with. . For example, the data generated by the data transmission side when data is
The CV uses the service permission ticket (SP
As described in the description of the format of T), the information is stored in the ICV (Integrity Check Value) field of the SPT. The ICV generated by the device is compared with the ICV stored in the received ticket (SPT). If they match, it is determined that the ticket is valid. If they do not match, it is determined that the ticket has been tampered, and the service permission ticket ( Processing using SPT) is stopped.

With the above-described processing, the service permission ticket (SPT) verification processing when the Integrity Check Type described in the service permission ticket (SPT) is the common key method is completed.

In step S519, the ticket type is a service permission ticket (SPT: Service Permissi
on Ticket), it is determined in step S5
23, the ticket type is verified, and the ticket is a data update ticket-DEV (DUT: Data Update T
icket (DEV)) (see FIG. 32). As described above, the data update ticket (DUT) is an access permission ticket for executing update processing of various data stored in the memory unit of the device, and is a data update ticket applied to processing for updating management data of the device manager. -DEV (DUT (DEV))
Update ticket-PAR (D) applied to the process of updating the management data of the partition manager and the partition manager
UT (PAR)).

If the ticket type is data update ticket-DEV (DUT (DEV)), steps S524 to S528 are executed, and a data update ticket (DEV) (DUT: Data Update Ticket (DE)) is executed.
If not V)), the flow proceeds to step S529.

If the ticket type is data update ticket-DEV (DUT (DEV)), in step S524 the Integrit described in the ticket
y It is determined whether or not the setting of Check Type (the type (public key method (Public) / common key method (Common))) of the validity verification value of the ticket is the public key method (Public).

The type of the validity verification value (Integrity Check Ty
If (pe) is the public key method (Public), step S52
Proceed to 5 to execute various processes. The process executed in step S525 is a process of first verifying the public key certificate (CERT) of the ticket issuer (Ticket Issuer) using the public key PUB CA (DEV) of the certificate authority (CA (DEV)) corresponding to the device manager. It is.

Data Update Ticket-DEV (D
When transmitting the ticket (Ticket) issued by the UT (DEV) issuing means (DUT Issuer) to the ticket user, in the case of the public key method, the data update ticket (DUT) issuing means (DUTIssuer) is disclosed. Key certificate (C
ERT_DUTI) is also sent to the device. DU
Attributes of public key certificate (CERT_DUTI) of T issuing means (Attri
bute) is the DKDB (PUB) (Device K
The identifier matches the identifier (DUTIC) of the ticket issuing means code (DUTIC_DEV) recorded in the ey Definition Block (PUB).

The public key certificate (see FIG. 11) has a signature executed with the secret key of the CA (DEV) corresponding to the device manager, and this signature is added to the CA (DEV (CA (DEV)). DEV)) public key PUB
Verification is performed using CA (DEV). The signature generation and verification are executed, for example, as processing according to the flowcharts of FIGS. 12 and 13 described above. This signature verification determines whether the ticket issuer's public key certificate (CERT) is a legitimate public key certificate (CERT) that is not falsified.

Further, in step S525, the user's affiliation code recorded in the option area of the public key certificate (CERT) of the ticket issuing means, whose validity has been confirmed by signature verification, and the DKDB (PUB) ( De
vice key definition block (PUB) recorded ticket issuing means code (DUTIC_DEV: DUT Issuer Category
for Device).

The public key certificate includes each ticket (PRT, FRT) as described in the description of the public key certificate in FIG.
RT, SPT, DUT) issuance code, which is the issuing code of the Ticket Issuer (Ticket Issuer), in this case DU
TIC (DUT Issuer Code) is recorded. The code of this optional area and the DKDB (PU
B) Ticket issuing means code (DUTIC_DEV: DUT Issuer C) recorded in (Device Key Definition Block) (PUB)
Attory for Device) (see FIG. 16), it is confirmed that the received ticket (DUT) is a ticket issued by a valid ticket issuing means.

Further, the device stores the CRL_DE stored in the device key area (see FIG. 18) in the memory section of the device.
V (device), the public key certificate identifier of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit) (ex.
Refer to the revocation list (Revocation List (Certificate)) in which the serial number (SN) is registered.
It is determined whether the ticket issuing means (Ticket Issuer) has not been revoked.

Further, a data update ticket-DEV (DUT (DEV)) which is a reception ticket (FIG. 32)
(See Integrity Check Va)
Performs verification of the validity verification value (public key method: Signature) of the lue (Ticket) to check whether the ticket has been tampered with. Similar to the verification, for example, it is executed according to the same sequence as the flow of FIG.

As described above, (1) Ticket issuer (Ticket Iss
uer) public key certificate (CERT) is a legitimate public key certificate (CERT) that has not been tampered with;
(2) The code recorded in the option area of the public key certificate (CERT) of the ticket issuer (Ticket Issuer) and the DKDB (PUB) (Device Key Def) in the device
Initiation block code (DUTIC_DEV: DUT Issuer Category for Device) recorded in the inition block (PUB)
(3) that the ticket issuer (Ticket Issuer) has not been revoked, (4) the received ticket (DU)
T) Verify that the ticket is not falsified by verifying the Signature. The data update ticket-DEV (D
UT (DEV)) is determined to be valid. The above (1)
If any of (4) to (4) is not confirmed, it is determined that the validity of the data update ticket-DEV (DUT (DEV)) cannot be obtained, and the data update ticket-DEV (DUT (DEV)) is used. The performed processing is stopped.

In step S524, the Integrity Check Type (ticket (Tick
If the setting of the type (public key method (Public) / common key method (Common)) of the validity verification value of (et) is determined to be the common key method (Common), the data update ticket is determined in step S526. -DEV (DUT (DEV))
Is the Kdut_DEV1 (MAC key for data update ticket (DUT) verification) or Kdut_DEV2 (encryption key for data update) stored in the device key area (see FIG. 18) Determine whether or not.

Data Update Ticket-DEV (D
The data indicated by the Old Data Code (the code of the old data to be updated) described in the UT (DEV) is stored in the device key area (see FIG. 18), and the Kdut_DEV1 (the MAC key of the data update ticket (DUT)) is stored in the device key area. ) Or Kdut_DEV2 (encryption key for data update)
In step S528, MAC verification processing is executed using Kdut_DEV3 (MAC verification key of the data update ticket (DUT)) stored in the device key area (see FIG. 18), and the data update ticket-DEV
Data indicated by Old Data Code (code of old data to be updated) described in (DUT (DEV)) is used for Kdut_DEV1 (MAC verification of data update ticket (DUT)) stored in the device key area (see FIG. 18). If it is not Kdut_DEV2 (encryption key for data update), the device key area (FIG.
8) using Kdut_DEV1 (MAC key for data update ticket (DUT)) stored in MAC
Perform verification processing.

As described above, when the MAC verification key is properly used, the data to be updated is the Kdut_DEV.
If it is 1 (MAC key for data update ticket (DUT)) or Kdut_DEV2 (encryption key for data update), use of these key data is stopped for some reason, for example, leakage of key information. This is to avoid MAC verification using the update target data because the information is scheduled. The MAC verification processing is executed according to the MAC value generation processing using the DES encryption processing configuration of FIG. 59 described above.

When the device newly stores Kdut_DEV1 (the MAC key for the data update ticket (DUT)) in the device key area (see FIG. 18) of the device, it stores the previously stored Kdut_DEV3 (data update ticket). (DUT) MAC swap key, that is, swap processing. In addition, a new Kd
When storing ut_DEV2 (data update encryption key), swapping with the previously stored Kdut_DEV4 (data update encryption key), that is, replacement processing is performed.

By swapping Kdut_DEV1 and Kdut_DEV3, and swapping Kdut_DEV2 and Kdut_DEV4, Kdut_DEV3 (key for verifying the MAC of the data update ticket (DUT)) and Kdut_DEV4 (encryption key for data update) are always processed. The pair is Kdut_DEV1 (MAC key for data update ticket (DUT) MAC), Kdut_DEV2
It is maintained at a newer version than the (data update encryption key) pair. In other words, Kdut_DEV1 and Kdut_DEV2
Keys are always used keys, Kdut_DEV3 and Kdut_DEV4
Updates the Kdut_DEV1 and Kdut_DEV2 in an emergency, and has a role as a backup key that is replaced with the currently used Kdut_DEV1 and Kdut_DEV2 keys. These processes will be further described later in the description of the data update process using the data update ticket (DUT).

For example, an ICV (Integrity Ch) generated by the data transmitting side at the time of data generation, which is guaranteed to be free from tampering,
eck Value) is compared with the ICV generated by the data receiving side based on the received data. If the same ICV is obtained, it is guaranteed that the data has not been tampered with. If the ICVs are different, it is determined that the data has been tampered with. . For example, the data generated by the data transmission side when data is
The CV uses the data update ticket (DU) shown in FIG.
As described in the description regarding the format of T), the ICV of the data update ticket (DUT) is used.
(Integrity Check Value) field.

The ICV generated by the device and the data update ticket-DEV (DUT
(DEV)), and if they match, it is determined that the ticket is valid. If they do not match, it is determined that the ticket has been tampered with, and the data update ticket-DEV (DUT (DEV)) Cancel the process using.

The Integ described in the data update ticket-DEV (DUT (DEV)) by the above processing
The data update ticket-DEV (DUT (DEV)) verification processing when the rity Check Type is the common key method is completed.

In step S523, the ticket type is data update ticket-DEV (DUT (DUT (DUT
EV)), the ticket is a data update ticket-PAR (DUT (PAR))
(See FIG. 32)). The data update ticket-PAR (DUT (PAR)) is a ticket applied to the process of updating the management data of the partition manager.

[0465] In this case, in step S529, the ticket to the described Integrity Check Type (ticket (Ticket type of validity verification value of) (public key system (Public)
/ Common Key Method (Common))) is set to Public Key Method (Public)
Is determined.

The type of the validity verification value (Integrity Check Ty
If (pe) is the public key method (Public), step S53
The process proceeds to 0, and various processes are executed. The process executed in step S530 first includes the public key PUB CA (PA) of the partition manager compatible certificate authority (CA (PAR)).
R) is a process for verifying the public key certificate (CERT) of the ticket issuer (Ticket Issuer).

Data Update Ticket-PAR (D
When transmitting the ticket (Ticket) issued by the UT (PAR) issuing means (DUT Issuer) to the ticket user, in the case of the public key method, the data update ticket (DUT) issuing means (DUTIssuer) is disclosed. Key certificate (C
ERT_DUTI) is also sent to the device. DU
Attributes of public key certificate (CERT_DUTI) of T issuing means (Attri
bute) is the PKDB (PUB) (Pqrtitio) in the device.
n Key Definition block) matches the ticket issuing means code (DUTIC_PAR).

The public key certificate (see FIG. 11) is provided with a signature executed with the private key of the partition manager corresponding CA (PAR (PAR)). PAR)) using the public key PUB CA (PAR). The signature generation and verification are executed, for example, as processing according to the flowcharts of FIGS. 12 and 13 described above. By this signature verification, it is determined whether or not the ticket issuer's public key certificate (CERT) is a legitimate public key certificate (CERT) that is not falsified.

In step S530, the user's affiliation code recorded in the option area of the public key certificate (CERT) of the ticket issuing means whose validity has been confirmed by signature verification, and the PKDB (PUB) ( Pq
(DUTIC_PAR: DUT Issuer Category forPa)
rtition).

The public key certificate contains each ticket (PRT, FRT) as described in the description of the public key certificate in FIG.
RT, SPT, DUT) issuance code, which is the issuing code of the Ticket Issuer (Ticket Issuer), in this case DU
TIC (DUT Issuer Code) is recorded. The code in this optional area and the PKDB (PU
B) Ticket issuing means code (DUTIC: DUT Issuer Category) recorded in (Pqrtition Key Definition block)
By confirming the match (see FIG. 21), it is confirmed that the received ticket (DUT) is a ticket issued by a valid ticket issuing unit.

[0471] Further, the device stores the CRL_DE stored in the device key area (see FIG. 18) in the memory section of the device.
V (device), the public key certificate identifier of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit) (ex.
Refer to the revocation list (Revocation List (Certificate)) in which the serial number (SN) is registered.
It is determined whether the ticket issuing means (Ticket Issuer) has not been revoked.

Further, a data update ticket-PAR (DUT (PAR)) which is a reception ticket (FIG. 32)
(See Integrity Check Va)
Performs verification of the validity verification value (public key method: Signature) of the lue (Ticket) to check whether the ticket has been tampered with. Similar to the verification, for example, it is executed according to the same sequence as the flow of FIG.

As described above, (1) Ticket Issuer (Ticket Iss
uer) public key certificate (CERT) is a legitimate public key certificate (CERT) that has not been tampered with;
(2) The code recorded in the option area of the public key certificate (CERT) of the ticket issuer (Ticket Issuer) and the PKDB (PUB) (Pqrtition Key) in the device
Matching of the ticket issuing means code (DUTIC_PAR: DUT Issuer Category for Partition) recorded in the Definition block), (3) that the ticket issuing means (Ticket Issuer) has not been revoked, (4) the received ticket (DU)
T) Verify that the ticket is not falsified by verifying the Signature. Data Update Ticket-PAR (D, provided that all the above confirmations have been made
UT) is verified as valid. If any of the above (1) to (4) is not confirmed, it is determined that the validity of the data update ticket-PAR (DUT (PAR)) cannot be obtained, and the data update ticket-PAR is determined.
Processing using PAR (DUT (PAR)) is stopped.

In step S529, the Integrity Check Type (ticket (Tick
If the setting of the type (public key method (Public) / common key method (Common)) of the validity verification value of (et) is determined to be the common key method (Common), in step S531, the data update ticket is determined. -PAR (DUT (PAR))
The data indicated by Old Data Code (code of old data to be updated) described in the partition key area (FIG. 23)
Kdut_PAR1 (data verification ticket (DUT) MAC verification key) or Kdut_PAR
2 (data update encryption key).

Data Update Ticket-PAR (D
The data indicated by the Old Data Code (the code of the old data to be updated) described in the UT (PAR) is stored in the partition key area (see FIG. 23). Kdut_PAR1 (the MAC key of the data update ticket (DUT)) )
Alternatively, in the case of Kdut_PAR2 (data update encryption key), in step S533, MAC verification is performed using Kdut_PAR3 (MAC key for data update ticket (DUT)) stored in the partition key area (see FIG. 23). Execute the data update ticket
-Old Data Co described in PAR (DUT (PAR))
Data indicated by de (code of old data to be updated) is stored in the partition key area (see FIG. 23).
AR1 (MAC of data update ticket (DUT)
Verification key) or Kdut_PAR2 (Data update encryption key)
If not, in step S532, a MAC verification process is executed using Kdut_PAR1 (MAC verification key of the data update ticket (DUT)) stored in the partition key area (see FIG. 23).

[0476] As described above, the proper use of the MAC verification key is performed when the data to be updated is Kdut_PAR.
If it is 1 (MAC key for data update ticket (DUT) MAC verification key) or Kdut_PAR2 (encryption key for data update), use of these key data is stopped for some reason, for example, leakage of key information. This is to avoid MAC verification using the update target data because the information is scheduled. The MAC verification processing is executed according to the MAC value generation processing using the DES encryption processing configuration of FIG. 59 described above.

For example, an ICV (Integrity Ch) generated at the time of data generation by the data transmitting side, which is guaranteed not to be falsified,
eck Value) is compared with the ICV generated by the data receiving side based on the received data. If the same ICV is obtained, it is guaranteed that the data has not been tampered with. If the ICVs are different, it is determined that the data has been tampered with. . For example, the data generated by the data transmission side when data is
The CV uses the data update ticket (DU) shown in FIG.
As described in the description regarding the format of T), the ICV of the data update ticket (DUT) is used.
(Integrity Check Value) field.

[0478] The ICV generated by the device and the data update ticket-PAR (DUT
(PAR)), and if they match, it is determined that the ticket is valid. If they do not match, it is determined that the ticket has been tampered with, and the data update ticket-PAR (DUT (PAR)) Cancel the process using.

The Integ described in the data update ticket-PAR (DUT (PAR)) by the above processing
The data update ticket-PAR (DUT (PAR)) verification processing when the rity Check Type is the common key method is completed.

After the validity of the ticket has been confirmed in the above processing, the flow advances to step S541 in FIG.
A user check, that is, a check of a reader / writer (or PC or the like) as a device access device that is executing communication with the device as a ticket user is executed.

[0481] In step S541, the device
Received ticket (PRT, FRT, SPT, or DU
T) Authentication Flag (a flag indicating whether or not mutual authentication with the device (Device) is necessary in the use process of the ticket (Ticket)) is checked. If the flag indicates that authentication is not required, the process ends without executing the process.

In the flag check processing in step S541, if the flag indicates that authentication is necessary,
Proceeding to step S542, the authentication table (see FIG. 51) is referred to using the affiliation (group) of the ticket user (a reader / writer, a PC, or the like as a device access device that intends to execute a process for applying a ticket to the device) as a key.

Next, in step S543, the Authentication Type of the received ticket (the type of mutual authentication of the device (Device) (public key authentication or common key authentication,
Alternatively, any of the data recorded as “Any”) is checked. If both are “Any”, the process proceeds to step S544, and the mutual authentication data of the group checked in step S542 is stored in the authentication table (see FIG. 51). )
It is determined whether it is stored in the. Mutual authentication information of the corresponding group is stored in the table, and the ticket user (a reader / writer as a device access device or a PC that executes a process applying a ticket to the device).
Etc.) and the device are determined to be mutually authenticated, it is determined that the validity of the ticket user (ex. Reader / writer as a device access device) has been confirmed, and the process is determined to be a successful user check. To end. If the mutual authentication information of the corresponding group is not stored in the authentication table (see FIG. 51), it is determined that the user check has not been completed, and the process ends with an error.

In step S543, any type of Authentication Type (mutual authentication type of device (public key authentication or common key authentication, or data recording any (Any))) of the received ticket can be used. If not (Any), it is determined in step 545 whether the Authentication Type is public key authentication.

If the Authentication Type is public key authentication, the flow advances to step S546 to determine whether the public key mutual authentication data of the group checked in step S542 is stored in the authentication table (see FIG. 51). The table stores the public key mutual authentication information of the corresponding group, and the mutual authentication between the ticket user (a reader / writer as a device access device, a PC, etc., which attempts to execute a process for applying a ticket to the device) and the device is public key authentication. If it is determined that the processing has been established, the process proceeds to step S547, and it is determined whether the ticket user identifier exists in the processing target ticket (PRT, FRT, SPT, or DUT). In step S548, an identifier or category or serial (SN) recorded as identification data (DN) in a public key certificate of an authentication partner (a reader / writer as a device access device as a ticket user) in step S548
Then, it is determined whether or not the identifier, the category, or the serial (SN) recorded as the identification data of the ticket user stored in the ticket matches. If they match, the process ends as the user confirmation is successful.

In step S546, in step S5
The public key mutual authentication data of the group checked in 42 is not stored in the authentication table (refer to FIG. 51), and the ticket user (a reader / writer as a device access device for executing a process applying a ticket to a device, a PC) Etc.) and the mutual authentication between the devices has not been established as the public key authentication process, it is determined that the user check has not been completed, and the process ends with an error.

In step S548, the identification data (D) in the public key certificate of the authentication partner (such as a reader / writer as a device for accessing the device as the ticket user) is stored.
If it is determined that the identifier or category or serial (SN) recorded as N) does not match the identifier of the ticket user stored in the ticket, the user check is determined to be incomplete, and the process ends with an error.

[0488] If the ticket user identifier does not exist in the ticket, the process in step S548 is not executed, and the process ends as the user confirmation is successful.

[0489] In step S545, the Authentication Type of the received ticket (the data in which the type of mutual authentication of the device (Device) (public key authentication or common key authentication, or any of which is acceptable (Any))) is the public key. If it is determined that the authentication is not the authentication, the process proceeds to step S549, and it is determined whether the common key mutual authentication data of the group checked in step S542 is stored in the authentication table (see FIG. 51). The common key mutual authentication information of the corresponding group is stored in the table, and the ticket user (a reader / writer as a device access device for executing a process applying a ticket to a device, a PC)
Etc.) and the mutual authentication between the devices is determined to have been established as the common key authentication process, step S55
0, and the ticket to be processed (PRT, FRT, SPT
Or, if it is determined whether or not the ticket user identifier exists in the DUT, the identification data (IDr) of the authentication partner (a reader / writer as a device access device as the ticket user) is determined in step S551.
It is determined whether or not w) matches the identifier of the ticket user stored in the ticket. If they match, the process ends as the user confirmation is successful.

[0490] In step S549, in step S5
The common key mutual authentication data of the group checked in 42 is not stored in the authentication table (see FIG. 51), and the ticket user (a reader / writer as a device access device for executing a process applying a ticket to a device, a PC) If it is determined that the mutual authentication between the device and the device has not been established as the common key authentication process, it is determined that the user check has not been completed, and the process ends with an error.

[0491] In addition, also used when it is determined that the identification data (IDrw) and ticket user stored in the ticket identifier of the authentication partner in step S551 (such as reader-writer as the device access equipment is the ticket user) does not match It is determined that the user check is not completed, and the process ends with an error.

If the ticket user identifier does not exist in the ticket, or if all ticket users can use the ticket, the process in step S550 is not executed, and the process ends as the user confirmation is successful.

Step S4 in the flow of FIG.
13 is the ticket validity and user check processing executed by the device.

(Partition creation / deletion processing) Next, details of the partition generation / deletion processing based on the partition registration ticket (PRT) executed in step S415 shown in the flow of FIG.
This will be described with reference to the processing flow of FIG. The partition creation / deletion process is a process executed by a device that has received a partition registration ticket (PRT) from a ticket user (ex. A reader / writer as a device access device, a PC, etc.) based on the partition registration ticket (PRT). is there.

In step S601 in FIG. 60, the device receives the received partition registration ticket (PR
T: The processing type recorded in the Partition Registration ticket, that is, the Operation Type (partition (Pa)
rtition) Verify whether to create or delete (Create / Delete). Operation type (Operation T
If (ype) is the creation of a partition (Partition), the process from step S602 is executed, and if it is the deletion of a partition (Partition), the process from step S621 is executed.

First, the partition creation processing will be described. In step S602, the device verifies whether a partition having the same code as the partition manager code (PMC) described in the partition registration ticket (PRT) exists in the memory unit of the device. This determination is made by the reception ticket (PR) in the partition definition block (see FIG. 19) of the memory section of the device.
The determination can be made by verifying whether the same code as the description code of T) is described.

If a partition having the same code (PMC) already exists in the device, the existence of a duplicate partition having the same code is not allowed, the partition is not generated, and the process ends with an error. If a partition with the same code does not exist in the device, step S
In 603, the number of free blocks (Free B) in the device of the device management information block (see FIG. 15)
lock Number in Device) and the partition size (Pa) described in the partition registration ticket (PRT).
Then, it is determined whether or not an empty block area larger than the partition size (Partion Size) described in the ticket (PRT) exists in the memory section of the device. If it does not exist, a partition of the size described in the PRT cannot be created, and the process ends with an error.

If it is determined that a free block area larger than the partition size (Partion Size) described in the ticket (PRT) exists in the memory portion of the device,
Proceeding to step S604, the partition definition block (PDB) area (see FIG. 19) is referred to as the top block of the free area in device (Free Area in Device) by referring to the free area pointer (Pointerof Free Area) in the device management information block. Secure.

Next, the device copies (S605) the partition manager code (PMC) described in the partition registration ticket (PRT) into the secured partition definition block (PDB) area,
Copy of PMC version described in (S606)
Execute

Further, the partition definition block (P
DB) partition start position (Partitio
n Start Position), Pointer of Free Are of the device management information block (see FIG. 15)
The copy process of a) is executed (S607), and the partition size (Pa) described in the partition registration ticket (PRT) is added to the partition size (Partion Size) of the partition definition block (PDB) area.
rtion Size) (S608).

Next, the device management information block (FIG. 15)
The value copied to the partition size (Partion Size) of the partition definition block (PDB) area is added (S609) to the free area pointer (Pointer of Free Area) of the device management information block (see FIG. 15). Device) (FreeBl)
ock Number in Device) to the partition size (Pa
(rtion Size) +1 is subtracted (S610). Note that +1
Means a block for a partition definition block (PDB).

Next, 1 is added to the number of partitions (Partition Number) of the device management information block (see FIG. 15), that is, the generated number of partitions (1) is added (S611).

Next, in step S631 of FIG. 61, the uppermost block of the generated partition area is stored in a partition management information block (PMIB: partition).
Management Information Block) (see FIG. 20), and the set partition management information block (P
MIB) Partition Manager Code (PMC)
The PMC of the partition registration ticket (PRT) is copied in the field of the partition registration ticket (PRT) (S632), and the PMC version of the partition registration ticket (PRT) is copied in the PMC version field of the partition management information block (PMIB) (S633). ,
Total Block number in Partit of Partition Management Information Block (PMIB)
ion) field contains the partition registration ticket (PR
The copy processing of the partition size (Partion Size) of T) is executed (S634).

[0504] Furthermore, the number of free partition blocks (Free B) in the partition management information block (PMIB)
In the lock number in Partition field, enter the partition registration ticket (PRT) partition size (Pa
rtion Size) -3 is recorded (S635). Note that -3
Means three blocks, a partition management information block (PMIB), a common key system partition key definition block (PKDB (common)), and a public key system partition key definition block (PKDB (PUB)) which are already scheduled to be used. It means subtracting.

Further, 0 is entered in the number of files (File Number) of the partition management information block (PMIB) (S636). At this point, no files are set in the partition. The file settings can be set using a file registration ticket (FRT). The file registration process using the file registration ticket (FRT) will be described later.

[0506] Further, the pointer of free area of the partition management information block (PMIB)
The start position (Start Position) of the partition definition block (PDB) is copied to ea), and the partition setting registration is completed.

Next, steps S621 to S628 in FIG.
Will be described. In step S621, the partition registration ticket (PRT)
Partition manager code (PM
It is verified whether a partition having the same code as in C) exists in the memory section of the device. This determination can be made by verifying whether the same code as the description code of the reception ticket (PRT) is described in the partition definition block (see FIG. 19) of the memory section of the device.

If no partition having the same code (PMC) exists in the device, it is impossible to delete the partition, and the process ends with an error. If a partition with the same code exists in the device, step S
At 622, it is determined whether a partition created after the partition to be deleted exists in the device. If not, the partition to be deleted is the latest partition, and the partition definition block (PDB) (see FIG. 19) of the partition to be deleted is deleted in step S629.

If it is determined in step S622 that a partition generated after the partition to be deleted exists in the device, the data of the partition (post-partition) generated later is added to the size (PS) of the partition to be deleted. , A process of shifting the partition definition block (PDB) of the subsequent partition one block higher is executed (S624). In addition, the partition start position (Partition Start position) recorded in the partition definition block (PDB) of the subsequent partition
Portion) is subtracted from the size of the deleted partition (PS) (S625).

[0510] After the processing in step S625 or S629, in step S626, the device (Device) in the device management information block (DMIB) (see Fig. 15) is read.
Free Block Number in Device
Is added to the size (PS) +1 of the deletion partition. +1 means a block for a partition definition block (PDB) of the deleted partition.

Next, in step S627, the size (PS) of the deleted partition is subtracted from the value of the free area pointer (Pointer of Free Area) in the device management information block (see FIG. 15). Further, step S62
8, device management information block (see FIG. 15)
1 is subtracted from the number of partitions (Partition Number), that is, the number of deleted partitions (1) is subtracted, and the partition deletion processing based on the partition registration ticket (PRT) ends.

The above is the partition registration ticket (PRT) of step S415 in the processing flow of FIG.
Partition generation and deletion processing based on the

(Initial Partition Registration) Next, FIG.
The details of the partition initial data write processing of steps S406 and S419 in the processing flow of, that is, the partition initial registration processing based on the partition registration ticket (PRT) will be described with reference to the flow of FIG.

In the processing flows shown in FIGS. 62, 63 and 64, the left side shows the processing of the initial registration device under the control of the partition manager, and the right side shows the processing of the device (see FIG. 5). The initial registration device under the control of the partition manager is a device (ex. A reader / writer or a PC as a device access device) capable of performing data read / write processing on the device, and corresponds to the reader / writer as a device access device in FIG. Having a configuration. As shown in the processing flow of FIG. 47, before the processing of FIG. 62 starts, mutual authentication is established between the initial registration device and the device, and the ticket and the user (the ticket user are the ticket user) in the ticket validity and user check. It is assumed that the validity of a reader / writer as a device access device has been confirmed, and the partition generation processing based on the partition registration ticket (PRT) has been completed. 62, 63, and 64.
Data is transmitted and received between devices as data encrypted using the session key Kses generated during mutual authentication.

[0515] In step S641 in Fig. 62, the initial registration device determines whether to use a common key for partition authentication. This determination is based on the authentication of the partition registration ticket (PRT) (see FIG. 26) to be used.
This is performed with reference to the Type (Device) mutual authentication type (public key authentication, common key authentication, or any type of Any) field.

As shown in FIG. 62, when a common key is used for partition authentication, steps S642 to 643, S
When steps S651 to S654 are executed and a common key is not used for partition authentication, these steps are omitted.

[0517] If the common key is used for the partition authentication, in step S642, the initial registration device sends MKauth_PAR_A:
Master key for two-way individual key authentication, Kauth_PAR_B: Common key for two-way individual key authentication, IRL_PAR: Excluded device (Device)
A revocation list (Device ID) in which the device identifier (ID) of this is registered, and the version information thereof are transmitted to the device.

[0518] In step S651, the device receives the write command described above, and in step S652,
Write the received data to the partition key area (see FIG. 23). Next, a pointer generated by writing data,
The size and the number of free blocks in the device are adjusted (S653), and a write completion notification is transmitted to the registration device (S654).

[0519] Upon receiving the write end notification (S643), the registration device determines in step S644 whether to use a public key for partition authentication. As shown in FIG. 62, if a public key is used for partition authentication, steps S645 to 649 and S655 to S662 are executed. If no public key is used for partition authentication, these steps are omitted.

[0520] When the public key is used for the partition authentication, in step S645, the registration device issues a public key authentication data write command as PUB_CA (PAR): public information of a certificate authority CA (PAR) that issues a public key certificate corresponding to the partition manager. Key, PARAM_PAR: public key parameter of partition (Partition), CRL_PAR: revocation list (Revo) in which public key certificate identifier (ex. Serial number: SN) of excluded device (Device) is registered
cation list (Certificate)) and their version information.

[0521] In step S655, the device receives the above-mentioned write command, and in step S656,
Write the received data to the partition key area (see FIG. 23). Next, a pointer generated by writing data,
The size and the number of free blocks in the device are adjusted (S657), and a write completion notification is transmitted to the registration device (S658).

The registration device that has received the write end notification (S646) transmits a key pair generation command of a public key and a secret key to the device (S647). In this embodiment, the key pair is generated by the device. However, the key pair may be generated by the registration device and provided to the device.

The device that has received the key pair generation command (S659) uses the public key (PUB PAR) and the secret key (PRI PA) in the encryption processing unit (see FIG. 5) in the device.
R) is generated, and the generated key is written in the partition key area (see FIG. 23) (S660). Next, the pointer, the size, and the number of free blocks in the device generated by the data writing are adjusted (S661), and the generated and stored public key is transmitted to the registration device (S662).

[0524] registration device, public key from the device (PUB
PAR) is received (S648), and stored in the database (DB (PAR)) (see FIG. 9) in the partition manager together with the device identifier IDm previously received from the device.

[0525] Next, the registration device of the partition manager registers a file registration ticket (FRT: File Registrat).
It is determined whether or not a common key is used in the verification process of the (ion ticket) (S671). For the ticket verification, it is possible to apply any of the common key method by MAC value verification or the like, or the public key method of generating a signature using a private key and verifying a signature using a public key, as described above. , The verification processing method adopted by the device can be set. The partition manager sets in the device data that can execute either the common key or the public key, or both, depending on the FRT ticket verification method adopted by the device.

When the partition manager is set to execute the common key authentication in the verification processing of the file registration ticket (FRT: File Registration Ticket), information necessary for the FRT verification of the common key method (ex. FRT verification common key) ) Is set in the device, and if the device does not execute the common key authentication, such information is not stored in the device.

As shown in FIG. 63, when using the common key method for FRT verification, steps S672 to 673, S68
If steps 1 to S684 are executed and a common key is not used for FRT verification, these steps are omitted.

[0528] If the common key is used for FRT verification, in step S672, the registration device uses the Kfrt: file registration ticket (F
RT) and transmits the MAC verification key and version information to the device.

[0529] In step S681, the device receives the above-described write command, and in step S682,
Write the received data to the partition key area (see FIG. 23). Next, a pointer generated by writing data,
The size and the number of free blocks in the device are adjusted (S683), and a write completion notification is transmitted to the registration device (S684).

The registration device that has received the write end notification (S673) determines in step S674 whether to use a public key for FRT verification. As shown in FIG.
When using a public key for FRT verification, step S675-
If steps 676 and S685 to S690 are executed and the public key is not used for FRT verification, these steps are omitted.

[0531] If the public key is used for FRT verification, in step S675, the registration device sends an FRT verification data write command as FRTIC (FRT Issuer Category):
File registration ticket (FRT) issuer category, PUB_
CA (PAR): PARAM_PAR, the public key of the certificate authority CA (PAR) that issues the public key certificate corresponding to the partition manager
: Public key parameter of the partition,
CRL_PAR: A revocation list (Certificate) in which a public key certificate identifier (ex. Serial number: SN) of an exclusion device (Device) is registered, and version information thereof are transmitted to the device.

[0532] In step S685, the device receives the above-mentioned write command, and in step S686,
FRTIC (FRT Issuer Category) in the received data: The file registration ticket (FRT) issuer category is set to the public key partition key definition block (PKDB: Partition Ke).
Write the write version information to the y definition block (PUB) (see FIG. 22) in the version area of the block.

Next, in step S687, the device determines whether or not the public key data of the certificate authority CA (PAR) that issues the public key certificate corresponding to PUB_CA (PAR): partition manager has been written. If not, in step S688, PUB_CA (PAR), PARAM
_PAR and CRL_PAR in the partition key area (see Fig. 23)
Write to. Next, the pointer, the size, and the number of free blocks in the device generated by the data writing are adjusted (S689), and a write completion notification is transmitted to the registration device (S690).

[0534] The registration device that has received the write end notification (S676) next determines in step S701 whether or not to use a device that supports updating of the common key data. Some of the data stored in the device are data update tickets (DUTs) described above as data to be updated (see FIG. 32).
Can be updated using. The data to be updated is
This is as described above with reference to FIG. In the update process using this data update ticket (DUT: Data Update Ticket), either the common key method or the public key method is possible, and the partition manager uses either the method or the method according to the set partition. Both types of data can be set on the device.

When the partition manager is configured to execute data update using the common key method for the set partitions, information necessary for data update processing using the common key method (ex. Data update ticket (DUT))
MAC verification key, etc.) is set in the partition key area of the device, and if the device does not execute the common key authentication, a process of not storing such information in the partition key area of the device is performed.

As shown in FIG. 64, when the common key method is used for data update processing using a data update ticket (DUT: Data Update Ticket), step S70 is performed.
Steps 2 to 703 and S711 to S714 are performed, and when the common key method is not used for data update, these steps are omitted.

[0537] When the common key is used for data update, in step S702, the registration device uses the data update ticket (DUT: Data Update Ticket) verification common key write command as Kdut_PAR1: the MAC key of the data update ticket (DUT), Kdut_PAR2: Data update encryption key, Kdut_PAR3: Data update ticket (DUT) MAC verification key, Kdut_PAR4: Data update encryption key and their version information are transmitted to the device.

[0538] In step S711, the device receives the above-mentioned write command, and in step S712,
Write the received data to the partition key area (see FIG. 23). Next, a pointer generated by writing data,
The size and the number of free blocks in the device are adjusted (S713), and a write completion notification is transmitted to the registration device (S714).

[0539] In step S704, the registration apparatus that has received the write end notification (S703) supports the data update process in which the partition set in the device uses a data update ticket (DUT: Data Update Ticket) using the public key method. It is determined whether or not to perform. As shown in FIG. 64, if the public key method is supported, steps S705 to 706 and S715 to S718 are executed. If the public key method is not supported, these steps are omitted.

If the public key method is supported, in step S705, the registration device sends a DUTIC_PAR (DUT Issuer Categor) as a data update ticket (DUT: Data Update Ticket) issuer code write command.
y): Data update ticket (DUT: Data Updat)
e Ticket) Sends issuer category and version information to the device.

[0541] In step S715, the device receives the above-mentioned write command, and in step S716,
The received data is stored in a public key partition key definition block (PKDB (PUB): Partition Key Definition Blo
ck (PUB)). Next, the pointer, the size, and the number of free blocks in the device generated by data writing are adjusted (S717), a write end notification is transmitted to the registration device (S718), and the registration device receives the write end notification (S706). And terminate the processing.

FIG. 65 shows an example of the configuration of data stored in the memory of the device in a state where the initial registration processing (the processing flow in FIGS. 62 to 64) by the partition manager has been completed.
The partition key area in the partition area shown in FIG.
In 4), the following data transmitted from the registration device is written. * IRL_PAR: Partition access elimination device (Dev
ice), a revocation list (Revocation List (Device ID)) in which identifiers (IDs) of excluded devices (a reader / writer as a device access device, a ticket user such as a PC, and a ticket issuing means) are registered. * CRL_PAR: Partition access excluded device (Dev
ice), the public key certificate identifier (ex. serial number: S) of the excluded device (a reader / writer as a device access device, a ticket user such as a PC, a ticket issuing unit)
N) registered revocation list (Revocation Lis
t (Certificate) * Kauth_PAR_B: Common key for two-way individual key authentication * Mkauth_PAR_A: Master key for two-way individual key authentication * Kdut_PAR1: Data update ticket (DUT)
MAC verification key * Kdut_PAR2: Data update encryption key * Kdut_PAR3: Data update ticket (DUT)
* Kdut_PAR4: Data update encryption key * Kfrt: File registration ticket (FRT) MAC verification key

Also, * PUB_PAR: public key of partition (Partition) * PRI_PAR: secret key of partition (Partition) is generated and written in the device.

Also, * PARAM_PAR: public key parameter of partition (Partition) * PUB_CA (PAR): public key of certificate authority CA (PAR) common key system partition key information block (Partition Ke)
y Definition Block (Common)) Public key partition key information block (Partition Ke
y Definition Block (PUB)) Partition management information block
nt Information Block) is data to be written when a partition is generated (see processing flow diagrams 60 and 61).

[B4.2. Public Key Certificate Issuing Process Under Partition Manager Management] Next, the process of issuing a partition corresponding public key certificate by the partition manager will be described with reference to FIG. The device has a device-specific public key certificate (CERT) applicable to the authentication of the entire device and the processing for each device.
DEV) and a partition-related public key certificate (CERT PAR) applicable to authentication or other verification processing at the time of processing for a specific partition in the device. Public key certificate for partition (CER)
TPAR) can be set and stored for each partition set in the device.

[0546] The partitioning public key certificate (CER)
T PAR) is issued by a procedure for giving a device a public key certificate issued by a certificate authority (CA for PM) (see FIGS. 2 and 3) through a registration authority under the jurisdiction of the partition manager. A public key certificate (CERTP) issued by the registration authority of the partition manager
AR) (database 332 (see FIG. 9)).

According to FIGS. 66 and 67, a partition-related public key certificate (CERT) for the set partition by the registration authority of the partition manager.
PAR) issuance processing will be described. FIGS. 66 and 67
On the left side, the CERT (public key certificate) issuing device of the registration authority under the jurisdiction of the partition manager, specifically,
The processing of the control unit 331 in the configuration diagram of the partition manager shown in FIG. 9 is the processing of the device on the right side.

First, in step S721, CERT
The issuing device executes the partitioning public key certificate (CER).
It acquires user information of a device to be issued a T PAR (T PAR), permits (determines) certificate issuance, and secures a communication path with the device to be issued. The user information of the device for which the partition-related public key certificate (CERT PAR) is to be issued can be obtained, for example, from data generated at the time of initial registration of the device. Note that the user information may be acquired from the device after setting a communication path with the device. The communication path may be secured as a communication path capable of transmitting and receiving data regardless of whether it is wired or wireless.

Next, the CERT issuing device executes the step S72.
In step 2, an authentication data generation command including a random number R is transmitted to the device. The device that has received the authentication data generation command (S731) stores the device secret key (P) in the combined data of the received random number R and the device identifier (IDm).
The digital signature (S) generation process (see FIG. 12) is executed by applying the RI PAR (S732). The device sends the device identification data (IDm) and signature (S) to C
Transmit to the ERT issuing device.

The CERT issuing device that has received the identification data (IDm) and the signature (S) from the device (S723) uses the received device identification data (IDm) as a search key to open the stored device from the database DB (PAR) 332. Obtain a key (PUB PAR). Further, a signature (S) verification process (see FIG. 13) is executed by applying the obtained device public key (PUB PAR) (S725).
I do. If the verification is not successful, it is determined that the data transmitted from the device is invalid data, and the process ends.

If the verification is successful, the certificate authority (CA f
or PM) 620 to issue a partition-related public key certificate (CERT PAR) (S72).
7) Yes. The partition manager issues a partitioning public key certificate (CERT) issued by the certificate authority 620.
PAR) is received (S728) and transmitted to the device (S7).
29)

A partition manager (registration authority) issues a partition-related public key certificate (CERT PAR).
Receives the public key (PUB CA) of the certificate authority stored in the partition key area (see FIG. 23) in advance.
(PAR)) to verify the signature of the received partition-related public key certificate (CERT PAR).
That is, the public key certificate has a signature executed with the private key of the certificate authority (see FIG. 11), and the signature is verified (S735).

If the signature verification fails, it is determined that the certificate is not a valid public key certificate, and an error notification is issued to the CERT issuing device (S745).

If the signature verification has succeeded, the device public key (PUB PAR) stored in the partition corresponding public key certificate (CERT PAR) is compared with the device public key (PUB PAR) stored in the own device. (S741) If not, an error notification is executed. If they match, the received partition-related public key certificate (CERT PAR) is stored in the partition key area (see FIG. 23) (S743). Before the issuance of the partition-related public key certificate (CERT PAR), the public key (PU
B PAR), and when a valid partition-related public key certificate (CERT PAR) is issued, stores as a process of overwriting with the partition-related public key certificate (CERT PAR).

[0555] The partitioning public key certificate (CER)
T PAR), the storage processing end notification is sent to C
The data is transmitted to the ERT issuing device (S744). The CERT issuing device receives the storage processing end notification (S751), confirms the storage success (S752), and ends the processing. If the storage success cannot be confirmed, the process ends as an error.

[B4.3. Processing Procedure in Each Method of Partition Generation Processing] As described above, in the partition setting registration processing, mutual authentication is performed between the reader / writer as a device access device managed by the partition manager and the device, and the partition registration ticket (PRT) Is set based on the partition. As described above, the mode of the mutual authentication processing is one of two types, that is, the public key mutual authentication and the common key mutual authentication. The ticket (PRT) verification processing is also performed by the public key signature verification and the common key MAC Either of two types of verification will be performed. That is, the processing modes are roughly divided into: (A) mutual authentication (public key), ticket (PRT) verification (public key), (B) mutual authentication (public key), ticket (PRT) verification (common key) (C) There are four modes: mutual authentication (common key), ticket (PRT) verification (common key), (D) mutual authentication (common key), and ticket (PRT) verification (public key).

The processing for these four aspects will be described mainly with reference to a certificate authority (CA (DM)), a device manager (DM), a partition manager (PM), a device, and data transfer processing executed between each entity. A brief explanation will be given.

(A) Mutual authentication (public key), ticket (P
RT) Verification (Public Key) First, data transfer between entities when the public key method is applied to the mutual authentication process and the public key method is applied to the ticket (PRT) verification will be described with reference to FIG. In the following, in order to simplify the description, as shown in FIG. 68, there is one certificate authority (CA), one registration authority is set in the device manager, and the device manager public key certificate (Cert.DM) ) And a partition manager public key certificate (Cert. PM) are issued via these registration authorities and certificate authorities. The means for issuing the partition registration ticket (PRT) is a device manager (DM), and the signature on the partition registration ticket (PRT) is executed using the secret key of the device manager.

Data transfer is performed between the entities in the order of the numbers shown in the figure. Hereinafter, the processing will be described according to the respective numbers. (1) The public key certificate (C) of the device manager (DM)
ert. DM) and a public key certificate (Cert. D)
M) is issued to the device manager by a certificate issuing procedure via the registration authority in response to an issuance request of the device manager by the certificate authority (CA). (2) Issuing a public key certificate (Cert. PM) of the partition manager (PM), and issuing a public key certificate (Cer. PM)
t. PM) is issued by the certificate authority (CA) to the partition manager by a certificate issuing procedure via the registration authority in response to an issuance request of the partition manager.

(3) Partition Registration Ticket (PR
T) Issuing Process The partition registration ticket (PRT) is issued to the partition manager (PM) by the partition registration ticket issuing means (PRT Ticket Issuer) managed by the device manager. In this case, a signature (Signature) using the secret key of the device manager is generated (see FIG. 12) and added to the PRT in order to generate and verify the signature in the public key system. (4) PRT and DM public key certificate (Cert. D
M) Partition registration ticket issuing means (PRTTicket I) managed by the supply device manager for the PM
ssuer), the partition registration ticket (PRT) is transmitted to the partition manager together with the DM public key certificate (Cert.DM).

(5) Mutual Authentication between PM and Device A target device for which a partition is to be created in accordance with the issued PRT, and a partition manager (specifically, a reader / writer as a device access device as a ticket user) Executes the public key mutual authentication (see FIG. 50).

(6) PRT and DM public key certificate (C
ert. Supply of DM to Device When mutual authentication between the PM and the device is established, the partition manager (PM) transmits a partition registration ticket (PRT) and a DM public key certificate (Cert.DM) to the device. The device receives the partition registration ticket (PRT)
(1) The ticket issuer (Ticket Issuer) = the public key certificate (CERT) of the DM is a valid public key certificate (CERT) that is not falsified, and (2) the ticket issuer (Ticket Issuer) The code recorded in the option area of the public key certificate (CERT) and the D
Ticket issuing means code (PRTIC: PRT Issuer) recorded in KDB (Device Key Definition Block) (PUB)
Code), (3) Ticket Issuing Means (Ticket Issu)
er) has not been revoked, and (4) the receipt of the ticket (PRT) is verified to confirm that the ticket has not been tampered with by verifying the signature, and the PRT user stored in the PRT ticket (in this case, Is a PM: a reader / writer as a device access device that is a ticket user) and a matching identifier or category or serial (SN) recorded as identification data (DN) of the received public key certificate of the partition manager,
Verification of the PRT user (PM: reader / writer as a device access device) is performed by confirming that mutual authentication has been completed (see FIGS. 57 and 58).

(7) Generation of Partition Verification of partition registration ticket (PRT), PRT
If the issuer (PRT Issuer) and the PRT user are successfully verified, a partition is generated in the memory section of the device according to the rules described in the partition registration ticket (PRT) (see FIGS. 60 and 61).

(8) Write Key Data When the partition is created in the memory section of the device,
The process of storing various keys in the generated partition is executed. (9) Reading of public key, (10) Issuing of public key certificate Public at the time of authentication processing for various services for the generated partition (authentication processing for using services such as partition generation, file generation, file access, data update, etc.) When performing key authentication, the device generates a key pair of a public key and a secret key, sends the generated public key to the partition manager, issues a public key certificate via a registration authority and a certification authority, and issues the certificate. The obtained public key certificate is stored in the partition key area (see FIG. 23). At this time, the public key certificate issued to the generated public key storage area is stored. Note that (9) and (1)
The process of 0) is an authentication process (partition generation, file generation,
This may be executed in the case of a configuration in which public key authentication is performed at the time of authentication processing when using services such as file access and data update.

[0565] Through the above processing, partition generation processing is executed in accordance with the mutual authentication (public key) and ticket (PRT) verification (public key) methods.

(B) Mutual authentication (public key), ticket (P
RT) Verification (Common Key) Next, data transfer between entities when the public key method is applied to the mutual authentication process and the common key method is applied to the ticket (PRT) verification will be described with reference to FIG. Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers.

(1) Partition Manager (PM)
Of the public key certificate (Cert.PM), and the public key certificate (Cert.PM) is issued to the device manager by a certificate issuance request from the certificate authority (CA) to the partition manager in accordance with the partition manager's issuance request. Issued to

(2) Partition Registration Ticket (PR
T) Issuing Process The partition registration ticket (PRT) is issued to the partition manager (PM) by the partition registration ticket issuing means (PRT Ticket Issuer) managed by the device manager. In this case, the MAC (Message Authentication Co
de) (see FIG. 59) is added to the PRT. (3) Supply of PRT to PM The partition registration ticket (PRT) issued by the partition registration ticket issuing means (PRT Ticket Issuer) managed by the device manager is transmitted to the partition manager.

(4) Mutual Authentication between PM and Device A target device for which a partition is to be created in accordance with the issued PRT, and a partition manager (specifically, a reader / writer as a device accessing a ticket user) Executes the public key mutual authentication (see FIG. 50).

(5) Sending PRT The partition manager sends the issued partition registration ticket (PRT) to the device. The device receives the partition registration ticket (PRT)
Of the PRT issuer (PRT
Issuer), and as identification data (DN) of the PRT user (in this case, PM: reader / writer as a device access device that is the ticket user) stored in the PRT ticket and the received public key certificate of the partition manager. Verification of the PRT user (PM: reader / writer as a device access device) by confirming the match of the recorded identifier or category or serial (SN) and confirming that mutual authentication has been completed (FIG. 5
7, see FIG. 58).

(6) Generation of Partition Verification of partition registration ticket (PRT), PRT
If the issuer (PRT Issuer) and the PRT user are successfully verified, a partition is generated in the memory section of the device according to the rules described in the partition registration ticket (PRT) (see FIGS. 60 and 61). (7) Write key data When the partition is created in the memory part of the device,
The process of storing various keys in the generated partition is executed.

(8) Reading of public key, (9) Issuance of public key certificate Authentication processing for various services for generated partitions (authentication processing for services such as partition generation, file generation, file access, and data update) When performing public key authentication, the device generates a key pair of a public key and a private key, sends the generated public key to the partition manager, and issues a public key certificate through the registration authority and certificate authority. Then, the issued public key certificate is stored in the partition key area (see FIG. 23). At this time, the public key certificate issued to the generated public key storage area is stored. This (8),
The process of (9) is executed in the case of a configuration in which public key authentication is performed at the time of authentication processing at the time of various services (authentication processing at the time of using services such as partition generation, file generation, file access, and data update) for the created partition. do it.

[0573] Through the above processing, partition generation processing is executed according to the mutual authentication (public key) and ticket (PRT) verification (common key) methods.

(C) Mutual authentication (common key), ticket (P
RT) Verification (Common Key) Next, data transfer between entities when the common key method is applied to the mutual authentication processing and the ticket (PRT) verification is applied will be described with reference to FIG. Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers.

(1) Partition Registration Ticket (PR
T) Issuing Process The partition registration ticket (PRT) is issued to the partition manager (PM) by the partition registration ticket issuing means (PRT Ticket Issuer) managed by the device manager. In this case, MAC (see FIG. 59) is added to the PRT as a verification value of the common key system.

(2) Supply of PRT to PM The partition registration ticket (PRT) issued by the partition registration ticket issuing means (PRT Ticket Issuer) managed by the device manager is transmitted to the partition manager.

(3) Mutual Authentication between PM and Device A target device for which a partition is to be generated in accordance with the issued PRT, and a partition manager (specifically, a reader / writer as a device access device which is a ticket user) Performs mutual authentication using the common key method (see FIGS. 53 and 54).

(4) Transmission of PRT The partition manager sends the issued partition registration ticket (PRT) to the device. The device receives the partition registration ticket (PRT)
Of the PRT issuer (PRT
Issuer), furthermore, the PRT user (in this case, PM: reader / writer as a device access device as a ticket user) stored in the PRT ticket is matched with the partition manager identifier, and mutual authentication has been completed. By checking the PRT user (P
M: Verification of a reader / writer as a device access device (see FIGS. 57 and 58) is executed.

(5) Generation of Partition Verification of partition registration ticket (PRT), PRT
If the issuer (PRT Issuer) and the PRT user are successfully verified, a partition is generated in the memory section of the device according to the rules described in the partition registration ticket (PRT) (see FIGS. 60 and 61).

(6) Write Key Data When the partition is created in the memory section of the device,
The process of storing various keys in the generated partition is executed. (7) Reading of public key, (8) Issuing of public key certificate It is made public at the time of authentication processing at the time of various services for the generated partition (authentication processing at the time of using services such as partition generation, file generation, file access, and data update). When performing key authentication, the device generates a key pair of a public key and a secret key, sends the generated public key to the partition manager, issues a public key certificate via a registration authority and a certification authority, and issues the certificate. The obtained public key certificate is stored in the partition key area (see FIG. 23). At this time, the public key certificate issued to the generated public key storage area is stored. This (7),
The process of (8) is executed in the case of a configuration in which public key authentication is performed at the time of authentication processing at the time of various services for the created partition (authentication processing at the time of using services such as partition generation, file generation, file access, and data update). do it.

With the above processing, partition generation processing according to the mutual authentication (common key) and ticket (PRT) verification (public key) methods is executed.

(D) Mutual authentication (common key), ticket (P
RT) Verification (Public Key) Next, data transfer between entities when the common key method is applied to the mutual authentication processing and the public key method is applied to the ticket (PRT) verification will be described with reference to FIG. Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers.

(1) Issuing a public key certificate (Cert.DM) of the device manager (DM), and issuing a public key certificate (C
ert. DM) is issued by the certificate authority (CA) to the device manager by a certificate issuing procedure via the registration authority in response to an issuance request of the device manager.

(2) Partition Registration Ticket (PR
T) Issuing Process The partition registration ticket (PRT) is issued to the partition manager (PM) by the partition registration ticket issuing means (PRT Ticket Issuer) managed by the device manager. In this case, a signature (Signature) using the secret key of the device manager is generated (see FIG. 12) and added to the PRT in order to generate and verify the signature in the public key system. (3) PRT and DM public key certificate (Cert. D
M) Partition registration ticket issuing means (PRTTicket I) managed by the supply device manager for the PM
ssuer), the partition registration ticket (PRT) is transmitted to the partition manager together with the DM public key certificate (Cert.DM).

(4) Mutual Authentication between PM and Device A target device for which a partition is to be created in accordance with the issued PRT, and a partition manager (specifically, a reader / writer as a device accessing device as a ticket user) Performs mutual authentication using the common key method (see FIGS. 53 and 54).

(5) PRT and DM public key certificate (C
ert. Supply of DM to Device When mutual authentication between the PM and the device is established, the partition manager (PM) transmits a partition registration ticket (PRT) and a DM public key certificate (Cert.DM) to the device. The device receives the partition registration ticket (PRT)
(1) The ticket issuer (Ticket Issuer) = the public key certificate (CERT) of the DM is a valid public key certificate (CERT) that is not falsified, and (2) the ticket issuer (Ticket Issuer) The code recorded in the option area of the public key certificate (CERT) and the D
Ticket issuing means code (PRTIC: PRT Issuer) recorded in KDB (Device Key Definition Block) (PUB)
Code), (3) Ticket Issuing Means (Ticket Issu)
er) has not been revoked, and (4) the receipt of the ticket (PRT) is verified to confirm that the ticket has not been tampered with by verifying the signature, and the PRT user stored in the PRT ticket (in this case, Is a PM: a reader / writer as a device access device as a ticket user) and an identifier or a category or a serial (SN) recorded as identification data (DN) in a public key certificate of a partition manager and mutual authentication. PRT user (PM: reader / writer as device access device)
(See FIGS. 57 and 58).

(6) Generation of Partition Verification of partition registration ticket (PRT), PRT
If the issuer (PRT Issuer) and the PRT user are successfully verified, a partition is generated in the memory section of the device according to the rules described in the partition registration ticket (PRT) (see FIGS. 60 and 61).

(7) Write Key Data When the partition is created in the memory section of the device,
The process of storing various keys in the generated partition is executed. (8) Reading of public key, (9) Issuance of public key certificate The public key is issued for authentication processing for various services for the generated partition (authentication processing for using services such as partition generation, file generation, file access, and data update). When performing key authentication, the device generates a key pair of a public key and a secret key, sends the generated public key to the partition manager, issues a public key certificate via a registration authority and a certification authority, and issues the certificate. The obtained public key certificate is stored in the partition key area (see FIG. 23). At this time, the public key certificate issued to the generated public key storage area is stored. This (8),
The process of (9) is executed in the case of a configuration in which public key authentication is performed at the time of authentication processing at the time of various services (authentication processing at the time of using services such as partition generation, file generation, file access, and data update) for the created partition. do it.

[0589] Through the above processing, partition generation processing is executed according to the mutual authentication (common key) and ticket (PRT) verification (public key) methods.

[B4.4. File Registration Ticket (FR
T) File Generation and Deletion Processing Using T] Next, processing for generating or deleting a file by applying a file registration ticket (FRT) to a partition generated in a device will be described. The flow from FIG. 72 onwards will be described with reference to other drawings. In the file creation and deletion processing, mutual authentication processing (device authentication or partition authentication) between a device and a reader / writer (partition manager) as a device access device, a partition registration ticket (FRT: File Registration)
Ticket).

[0591] The file generation and deletion processing flow shown in Fig. 72 will be described. In FIG. 72, the left side shows the processing of the file creation / deletion device of the partition manager, and the right side shows the processing of the device (see FIG. 5). The file creation / deletion device of the partition manager is a device (ex.
A reader / writer as a device access device (PC) corresponds to the reader / writer as the device access device in FIG. First, an outline of the file creation / deletion processing will be described with reference to FIG. 72, and then details of the file creation / deletion operation included in this processing will be described with reference to the flow of FIG.

First, steps S801 and S81 in FIG.
At 0, a mutual authentication process is performed between the file creation / deletion device and the device. The two means for executing data transmission / reception mutually confirm whether or not the other party is a correct data communicator, and thereafter perform necessary data transfer. The process of confirming whether the other party is the correct data communicator is the mutual authentication process. A session key is generated at the time of the mutual authentication process, and encryption is performed using the generated session key as a shared key to transmit data.

The mutual authentication processing is the same processing as described in the section of the partition generation / deletion processing, and the partition authentication is executed. Either common key authentication or public key authentication processing is applied to each of them. This mutual authentication process is the same as that shown in FIG.
Since the processing is the same as that described with reference to FIG.

Note that the processing to be executed as the mutual authentication processing is the file registration ticket (FRT) (FIG. 27) to be applied.
*) Authentication Flag: A flag indicating whether mutual authentication with the device is required in the process of using the ticket. * Authentication Type: The type of mutual authentication of the device (public key authentication or , Common key authentication, or any one of them (Any)).

If the authentication processing has failed (S802, S8
No in 11) indicates that it is not possible to confirm that they are valid devices and devices, and the following processing is not executed and the processing ends as an error.

[0596] If the authentication processing is successful, the file creation / deletion apparatus sends the file registration ticket (F
RT: File Registration Ticket). The file registration ticket (FRT) is a ticket issued by a file registration ticket (FRT) issuing unit (FRT Issuer) managed by the partition manager. The file registration ticket (FRT) is an access control ticket for the device, and has the data format configuration of FIG. 27 described above.

[0597] The file registration ticket (FRT)
Is transmitted to the ticket user, in the case of the public key method, the public key certificate (CERT_FRTI) of the file registration ticket (FRT) issuing means (FRT Issuer) is also transmitted. Public key certificate of FRT issuing means (CERT_FRT
The attribute (I) is an identifier (FRTIC) of a file registration ticket (FRT) issuing means (FRT Issuer).
Matches.

The device that has received the file registration ticket (FRT) (S812) transmits the received ticket (FR
T) and executes the user check process (S813)
I do. The processing for verifying the validity of the ticket is executed by applying either MAC verification using a common key method or signature verification processing using a public key method. User check
This is a process of checking the validity of the device (ticket user) that has transmitted the ticket. Mutual authentication has been established, the identification data of the authentication partner, and the ticket user identifier recorded in the ticket (see FIG. 27). This is executed as a process for verifying a match with the above. These processes are the same as those described with reference to FIGS. 57 to 59 in the description of the application process of the partition registration ticket (PRT), and thus description thereof is omitted.

In the device, the received ticket (FR
T) If the validity of the ticket and the user cannot be confirmed as a result of the user check processing and the validity of the user (S8)
(No in 14) notifies the file creation / deletion device of the file registration ticket (FRT) reception error (S818). If the validity of the ticket and the user is confirmed (Yes in S814), a file is created or deleted in the memory unit in the device in accordance with the rules described in the received file registration ticket (FRT). . Details of this processing will be described later using another flow.

According to the description of the file registration ticket (FRT), the file is successfully created or deleted (S81).
If 6), create a file indicating that FRT reception was successful.
The deletion device is notified (S817). On the other hand, if the file generation or deletion processing has failed (No in S816), an FRT reception error is notified to the file creation / deletion device (S818).

The file creation / deletion device receives the FRT reception result (S804), determines the FRT processing result, and
When the RT reception result is an error (No in S805)
Terminates the processing as an error, executes the transmission / reception of the session clear command (S806, S819) when the FRT reception result is successful (Yes in S805), and discards the authentication table generated on the device side (S820). ,
The process ends. The authentication table is stored in step S801,
This is a table generated in the mutual authentication process of S810, and is the partition registration ticket (PRT) described above.
51, that is, the same as the configuration shown in FIG.

[0602] As described above, the file registration ticket (FR
Using T), a file is created in a partition set in the device, or a process of deleting a created file is executed. Hereinafter, the file generation and deletion processing (S815) included in this processing will be described with reference to FIG.

(File creation / deletion processing) Details of the partition creation / deletion processing based on the file registration ticket (FRT) executed in step S815 shown in the flow of FIG. 72 will be described with reference to the processing flow of FIG. . The file creation / deletion process is performed by a device that has received a file registration ticket (FRT) from a ticket user (ex. A reader / writer as a device access device, a PC, etc.).
This is a process executed based on.

In step S821 of FIG. 73, the device receives the received file registration ticket (FRT: File
The processing type recorded in the Registration Ticket, that is, the Operation Type (partition (Partition) creation / deletion specification (Generate / Delete)
e))) is verified. The operation type (Operation Type)
If the file is to be created, steps S822 and subsequent steps are executed. If the file is to be deleted, steps S841 and subsequent steps are executed.

First, the file creation processing will be described. In step S822, the device determines the file identifier (I) described in the file registration ticket (FRT).
It verifies whether a file with the same ID as in D) exists in the processing target partition of the device. This judgment is
It can be determined by verifying whether the same file ID as the file ID described in the reception ticket (FRT) is described in the file definition block (see FIG. 24) of the partition area set in the memory section of the device. It is.

If a file with the same ID already exists in the device, it is not allowed to have a duplicate file with the same ID in the same partition, so that the file is not generated and the process ends with an error. Same ID
If the file does not exist in the processing target partition, in step S823, the number of free blocks in the partition (Free Block Number in Partition) of the partition management information block (see FIG. 20) and the file registration ticket (FRT) are described. The file size (File Size) described above is compared with the file size (File Size) described in the ticket (FRT), and it is determined whether or not a free block area larger than the file size (File Size) exists in the partition to be processed by the device. If the file does not exist, a file having the size described in the FRT cannot be generated, and the process ends with an error.

If it is determined that a free block area equal to or larger than the file size (File Size) described in the ticket (FRT) is present in the partition to be processed in the memory section of the device, the flow advances to step S824 to execute the partition management information block. Free area pointer (Pointer
With reference to the Free Area in Free Area, a file definition block (FDB) area (see FIG. 24) is secured in the highest block of the Free Area in Partition.

Next, the device executes a copy of the file ID described in the file registration ticket (FRT) in the secured file definition block (FDB) area (S825), and further executes the file definition block (FD).
B) File start position of area (File Start Posit)
), a copy process of a free area pointer (Pointer of Free Area) of the partition management information block (see FIG. 20) is executed (S826).

[0609] In step S827, the file size (File S) of the file definition block (FDB) is determined.
ize), service permission ticket issuing means code (SPT)
IC), and version, (SPTIC Version),
File structure type (File Structure Type Code), authentication method (Accept
able Authentication Type), the specified verification method (Acce
Each corresponding data described in the file registration ticket (FRT) is copied into each of the ptable VerificztionTypes.

[0610] Next, in step S828, is stored in the file registration ticket (FRT) Kspt_Encrypted
(Data Kfrt obtained by encrypting the MAC verification key Kspt of the service permission ticket (SPT) described in the file definition block with the MAC verification key Kfrt of the file registration ticket of the partition
(Kspt)) is the key K for file verification ticket MAC verification
Decrypt using frt and file definition block (FDB)
To be stored. The MAC verification key Kfrt of the file registration ticket has already been stored in the partition key area when the partition was generated.

Next, in step S829, the number of free blocks (Free Block Numeric) in the partition (Partition) of the partition management information block (see FIG. 20)
mberin Partition) to File Size (File Size)
Subtract +1. Note that +1 means a block for a file definition block (FDB).

Next, in step S830, the generated file size (File Size) is added to the free area pointer (Pointer of Free Area) of the partition management information block (see FIG. 20), and in step S831, the partition management information block is generated. Files (Fi
le Number), that is, the number of generated files (1).

[0613] Next, in step S832, File Structure, which is stored in the file registration ticket (FRT)
(File structure of generated file (File) (Structur
e) Perform the initialization process according to (1). For example, if the file structure is random, processing such as resetting to 0 is performed, and if the file structure is cyclic, processing such as resetting pointers and data to 0 is executed. By these processes,
A new file is created in the created partition.

Next, steps S841 to S848 in FIG. 73 are performed.
File deletion processing will be described. Step S84
In step 1, it is verified whether a file having the same ID as the file ID described in the file registration ticket (FRT) exists in the partition to be processed in the memory section of the device. This determination can be made by verifying whether the same file ID as the file ID described in the reception ticket (FRT) is described in the file definition block (see FIG. 24) of the memory unit of the device. .

If there is no file with the same file ID in the partition to be processed by the device, it is impossible to delete the file, and the process ends with an error. If a file with the same ID exists in the processing target partition of the device, in step S842, it is determined whether a file generated after the deletion target file exists in the processing target partition. If not, the file to be deleted is the latest file, and the file definition block (FDB) (see FIG. 24) of the file to be deleted is deleted in step S849.

In step S842, if it is determined that the file generated after the file to be deleted exists in the partition to be processed, the data of the file generated after (file after) is changed to the size (file size) of the file to be deleted. FS), the process of shifting to lower order is executed (S8).
43) Then, a process of shifting the file definition block (FDB) of the subsequent file one block higher is executed (S8).
44). The file start position (File Start Block) recorded in the file definition block (FDB) of the subsequent file
Portion) is subtracted from the size of the deleted file (FS) (S845).

[0617] After the processing in step S845 or S849, in step S846, the number of free blocks in the partition of the partition management information block (PMIB) (see FIG. 20) (Free Block Number in Partiti).
on) is added to the size of the deleted file (FS) +1.
+1 is the file definition block (FD
B).

Next, in step S847, the size (FS) of the deleted file is subtracted from the value of the free area pointer (Pointer of Free Area) of the partition management information block (PMIB) (see FIG. 20). Further, in step S848, the number of files (File Num) in the partition management information block (PMIB) (see FIG. 20)
ber), 1 is subtracted, that is, the number of deleted files (1) is subtracted, and the file deletion process based on the file registration ticket (FRT) ends.

The above is the file generation and deletion processing based on the file registration ticket (FRT) in step S815 in the processing flow of FIG. 72.

FIG. 74 shows an example of the configuration of data stored in the memory of the device in a state where the file generation processing by the partition manager has been completed. Partition shown in FIG. 74
In the (Partion) area, File Definition Blocks (1-N)
ck) Partition Key Area Common key system partition key information block (Partition Ke)
y Definition Block (Common)) Public key partition key information block (Partition Ke
y Definition Block (PUB)) Partition management information block
Each data of the information block (nt information block) is data written at the time of file generation or partition generation. File areas (File Data Areas 1 to N) are secured as file areas in the partition to be processed by the file generation processing.

[B4.5. Processing Procedure in Each Method of File Generation Processing] In the above-described file setting registration processing, mutual authentication is performed between a device managed by the partition manager and a reader / writer as a device access device that is a file registration ticket user, and file registration is performed. A file is set based on the ticket (FRT). The mode of the mutual authentication processing is one of two types of public key mutual authentication and common key mutual authentication. The ticket (FRT) verification processing is also performed by public key signature verification.
Either of two types of common key MAC verification is executed. That is, the processing modes are roughly divided into: (A) mutual authentication (public key), ticket (FRT) verification (public key) (B) mutual authentication (public key), ticket (FRT) verification (common key) (C) There are four modes: mutual authentication (common key), ticket (FRT) verification (common key), (D) mutual authentication (common key), and ticket (FRT) verification (public key).

The processing for these four aspects is performed by a certificate authority (CA (PM)), a partition manager (P
M), devices, and data transfer processing executed between the entities will be briefly described with reference to the drawings.

(A) Mutual authentication (public key), ticket (F
RT) Verification (Public Key) First, data transfer between entities when a public key method is applied to mutual authentication processing and a public key method is applied to ticket (FRT) verification will be described with reference to FIG.

Data transfer is performed between the entities in the order of the numbers shown in the figure. Hereinafter, the processing will be described according to the respective numbers. (1) File registration ticket issuing means (FRT Issue
r) public key certificate (Cert. FRT Issuer), file registration ticket issuing means (FRT Issuer)
The public key certificate (Cert. FRT Issuer) is issued by a file registration ticket issuing means (FRT Issuer), and is issued by a certificate issuing procedure via a registration authority (RA).
R)). The partition manager is a file registration ticket issuing unit (FRT Issuer)
In this case, the public key certificate of the partition manager (PM) can be used as the public key certificate of the file registration ticket issuing means (FRT Issuer).

(2) File Registration Ticket User (FR
T User) issuance of a public key certificate (Cert. FRT User), file registration ticket user (FRT User: specifically, a public key certificate of a reader / writer as a device access device for transmitting a ticket to a device) The certificate (Cert.FRT User) is issued by the partitioning certificate authority (CA (PAR)) by a certificate issuing procedure via the registration authority (RA) in response to an issuance request from the file registration ticket user (FRT User). . Note that a configuration in which the partition manager also serves as a file registration ticket user (FRT User) is possible. In this case, the file registration ticket user (FRT User) is used.
The public key certificate of the partition manager (PM) can be used as the public key certificate of the user.

(3) File registration ticket (FRT) generation processing The file registration ticket (FRT) is generated by a file registration ticket issuing unit (F) managed by the partition manager.
RT Ticket Issuer). In this case, a signature (Signature) using a private key of a file registration ticket issuing unit (FRT Ticket Issuer) is generated (see FIG. 12) to execute signature generation and verification in the public key system, and F
Added to RT.

(4) FRT and File Registration Ticket Issuing Means (FRT Ticket Issuer) Public Key Certificate (Ce
rt. Supply of FRT Issuer to File Registration Ticket User (FRT User) The file registration ticket (FRT) issued by the file registration ticket issuing means (FRT Ticket Issuer) managed by the partition manager is the file registration ticket issuing means (FRT Ticket Issuer) The file registration ticket user (FRT User) is transmitted together with the public key certificate (Cert. FRT Issuer), that is, a device (ex. Reader / writer as a device access device) that transmits a ticket to the device.

(5) Mutual Authentication between File Registration Ticket Issuing Means and Device The partition manager (specifically, a reader / writer as a device access device that is a file registration ticket user (FRTUser)) issues file registration ticket issuing means (FRT). Ticket Issuer) issues a file registration ticket (FRT) to a target device for which a file is to be generated according to the ticket user (FRT U
The public key certificate (Cert. FRT User) of the public key (ser) is transmitted to the device, and mutual authentication using the public key method (see FIG. 50) is executed.

(6) FRT and File Registration Ticket Issuer (FRT Ticket Issuer) Public Key Certificate (Ce
rt. FRT Issuer) supply to devices Partition Manager (PM) when mutual authentication between device and partition manager (PM) is established
(Specifically, file registration ticket users (FRT Use
r), a reader / writer as a device access device) sends a file registration ticket (FR
T) and file registration ticket issuing means (FRT T
icket Issuer) Public Key Certificate (Cert. FRT Issue
Send r).

The device checks (1) the ticket issuer (Ticket) for the received file registration ticket (FRT).
Issuer) public key certificate (CERT FRT Issuer) is a valid public key certificate (CERT) that is not falsified, (2) public key certificate (CERTFRT Issuer) of ticket issuer (Ticket Issuer) The code recorded in the option area of the device and the PKDB (Partit
(3) that the ticket issuing means (Ticket Issuer) has not been revoked, (4) the received ticket (FRT) )
Verify that the ticket is not falsified by verifying the signature of the FRT user (FRT user) and the ticket user (FRT User) stored in the FRT ticket. Public key certificate (Cert. FRT Us)
er), the FRT user (the reader as a device access device) confirms that the identifier or category recorded as the identification data (DN) matches the serial (SN) name (DN) and confirms that the mutual authentication has been completed. Writer) (see FIGS. 57 and 58).

[0631] (7) SPTIC and Kspt in the FDB
The device registers the file definition block (FDB: File Def.
service ticket (SPT) user (SPTIC) (ex. a reader / writer as a device access device that accesses data in a device file) and Kspt (service permission ticket (SP)
The MAC verification key (Kspt) of T) is registered (steps S827 and S828 in the flow of FIG. 73).

(8) Secure File Data Area The device secures a file area having the size described in the file registration ticket (FRT) in the partition to be processed.

By the above processing, the file generation processing according to the mutual authentication (public key) and ticket (FRT) verification (public key) methods is executed.

(B) Mutual authentication (public key), ticket (F
RT) Verification (Common Key) Next, data transfer between entities when the public key method is applied to the mutual authentication processing and the common key method is applied to ticket (FRT) verification will be described with reference to FIG.

[0635] order of the numbers shown in Fig data transfer between the entities is performed. Hereinafter, the processing will be described according to the respective numbers.

(1) File Registration Ticket User (FR
T User) issuance of a public key certificate (Cert. FRT User), file registration ticket user (FRT User: specifically, a public key certificate of a reader / writer as a device access device for transmitting a ticket to a device) The certificate (Cert.FRT User) is issued by the partitioning certificate authority (CA (PAR)) by a certificate issuing procedure via the registration authority (RA) in response to an issuance request from the file registration ticket user (FRT User). . Note that a configuration in which the partition manager also serves as a file registration ticket user (FRT User) is possible. In this case, the file registration ticket user (FRT User) is used.
The public key certificate of the partition manager (PM) can be used as the public key certificate of the user.

(2) File registration ticket (FRT) generation processing The file registration ticket (FRT) is generated by a file registration ticket issuing unit (F) managed by the partition manager.
RT Ticket Issuer). In this case, the MAC (Message Authenticatio
n Code) (see FIG. 59) is added to the FRT.

(3) Supply of FRT to File Registration Ticket User (FRT User) The file registration ticket (FRT) issued by the file registration ticket issuing means (FRT Ticket Issuer) managed by the partition manager is the file registration ticket user (FRT). User), that is, transmitted to a device that transmits a ticket to the device (ex. A reader / writer as a device access device).

(4) Mutual Authentication between File Registration Ticket Issuing Means and Device The partition manager (specifically, a reader / writer as a device access device that is a file registration ticket user (FRTUser)) issues file registration ticket issuing means (FRT). A ticket user (FRT U)
The public key certificate (Cert. FRT User) of the public key (ser) is transmitted to the device, and mutual authentication using the public key method (see FIG. 50) is executed.

(5) Supply to FRT Device When mutual authentication between the partition manager (PM) and the device is established, the partition manager (PM)
(Specifically, file registration ticket users (FRT Use
r), a reader / writer as a device access device) sends a file registration ticket (FR
T). The device performs a MAC verification process on the received file registration ticket (FRT),
Verification of the RT issuer (FRT Issuer), and further as identification data (DN) of the FRT user (a reader / writer as a device access device as a ticket user) stored in the FRT ticket and the received public key certificate of the partition manager. The FRT user (P) can confirm the identity of the recorded identifier or category or the serial (SN) name (DN) and confirm that they have been mutually authenticated.
M: Verification of a reader / writer as a device access device (see FIGS. 57 and 58) is executed.

(6) SPTIC and Kspt in FDB
The device registers the file definition block (FDB: File Def.
In the Inition Block), a service permission ticket (SPT) issuer category (SPTIC) (ex. a reader / writer as a device access device that accesses data in a device file) and Kspt (MAC verification of a service permission ticket (SPT)) The registration key (Kspt) is registered (steps S827 and S828 in the flow of FIG. 73).

(8) Securing File Data Area The device secures a file area having the size described in the file registration ticket (FRT) in the partition to be processed.

With the above processing, the file generation processing according to the mutual authentication (public key) and ticket (FRT) verification (common key) methods is executed.

(C) Mutual authentication (common key), ticket (F
RT) Verification (Common Key) Next, data transfer between entities when the common key method is applied to the mutual authentication process and the ticket (FRT) verification is applied will be described with reference to FIG.

Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers.

(1) File registration ticket (FRT) generation processing The file registration ticket (FRT) is generated by a file registration ticket issuing unit (F) managed by the partition manager.
RT Ticket Issuer). In this case, the MAC (Message Authenticatio
n Code) (see FIG. 59) is added to the FRT.

(2) Supply of FRT to File Registration Ticket User (FRT User) The file registration ticket (FRT) issued by the file registration ticket issuing means (FRT Ticket Issuer) managed by the partition manager is the file registration ticket user (FRT). User), that is, transmitted to a device that transmits a ticket to the device (ex. A reader / writer as a device access device).

(3) Mutual Authentication between File Registration Ticket Issuing Means and Device The partition manager (specifically, a reader / writer as a device access device which is a file registration ticket user (FRTUser)) issues file registration ticket issuing means (FRT). Mutual authentication using a common key method (see FIGS. 53 and 54) is performed with a device that is to generate a file according to the file registration ticket (FRT) issued by the Ticket Issuer.

(4) Supply to FRT Device When mutual authentication between the partition manager (PM) and the device is established, the partition manager (PM)
(Specifically, file registration ticket users (FRT Use
r), a reader / writer as a device access device) sends a file registration ticket (FR
T). The device performs a MAC verification process on the received file registration ticket (FRT),
Verification of the RT issuer (FRT Issuer), furthermore, matching of the identifier of the FRT user (reader / writer as a device access device which is the ticket user) stored in the FRT ticket with the received partition manager identifier has been confirmed, and mutual authentication has been completed. Then, verification of the FRT user (PM: reader / writer as a device access device) is executed (see FIGS. 57 and 58).

(6) SPTIC and Kspt in FDB
The device registers the file definition block (FDB: File Def.
In the Inition Block), a service permission ticket (SPT) issuer category (SPTIC) (ex. a reader / writer as a device access device that accesses data in a device file) and Kspt (MAC verification of a service permission ticket (SPT)) The registration key (Kspt) is registered (steps S827 and S828 in the flow of FIG. 73).

(8) Securing File Data Area The device secures a file area having the size described in the file registration ticket (FRT) in the partition to be processed.

[0652] Through the above processing, the file generation processing according to the mutual authentication (common key) and ticket (FRT) verification (common key) methods is executed.

(D) Mutual authentication (common key), ticket (F
RT) Verification (Public Key) Next, data transfer between entities when a common key method is applied to mutual authentication processing and a public key method is applied to ticket (FRT) verification will be described with reference to FIG.

Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers. (1) File registration ticket issuing means (FRT Issue
r) public key certificate (Cert. FRT Issuer), file registration ticket issuing means (FRT Issuer)
The public key certificate (Cert. FRT Issuer) is issued by a file registration ticket issuing means (FRT Issuer), and is issued by a certificate issuing procedure via a registration authority (RA).
R)). The partition manager is a file registration ticket issuing unit (FRT Issuer)
In this case, the public key certificate of the partition manager (PM) can be used as the public key certificate of the file registration ticket issuing means (FRT Issuer).

(2) File registration ticket (FRT) generation processing The file registration ticket (FRT) is a file registration ticket issuing unit (F) managed by the partition manager.
RT Ticket Issuer). In this case, a signature (Signature) using a private key of a file registration ticket issuing unit (FRT Ticket Issuer) is generated (see FIG. 12) to execute signature generation and verification in the public key system, and F
Added to RT.

(3) FRT and File Registration Ticket Issuing Means (FRT Ticket Issuer) Public Key Certificate (Ce
rt. Supply of FRT Issuer to File Registration Ticket User (FRT User) The file registration ticket (FRT) issued by the file registration ticket issuing means (FRT Ticket Issuer) managed by the partition manager is the file registration ticket issuing means (FRT Ticket Issuer) The file registration ticket user (FRT User) is transmitted together with the public key certificate (Cert. FRT Issuer), that is, a device (ex. Reader / writer as a device access device) that transmits a ticket to the device.

[0657] (4) file registration ticket issuing means and (reader-writer as the device access apparatus is specifically a file registration ticket user (FRTUser)) mutual authentication partition manager between devices, file registration ticket issuing means (FRT Mutual authentication using a common key method (see FIGS. 53 and 54) is performed with a device that is to generate a file according to the file registration ticket (FRT) issued by the Ticket Issuer.

(5) FRT and File Registration Ticket Issuer (FRT Ticket Issuer) Public Key Certificate (Ce
rt. FRT Issuer) supply to devices Partition Manager (PM) when mutual authentication between device and partition manager (PM) is established
(Specifically, file registration ticket users (FRT Use
r), a reader / writer as a device access device) sends a file registration ticket (FR
T) and file registration ticket issuing means (FRT T
icket Issuer) Public Key Certificate (Cert. FRT Issue
Send r).

The device checks (1) the ticket issuer (Ticket) for the received file registration ticket (FRT).
Issuer) public key certificate (CERT FRT Issuer) is a valid public key certificate (CERT) that is not falsified, (2) public key certificate (CERTFRT Issuer) of ticket issuer (Ticket Issuer) The code recorded in the option area of the device and the PKDB (Part
(3) that the ticket issuance means (Ticket Issuer) has not been revoked, (4) the received ticket (FRT)
Verify that the ticket is not falsified by verifying the signature of the FRT user (FRT user) and the ticket user (FRT User) stored in the FRT ticket. Verification of the FRT user (a reader / writer as a device access device) by confirming that the identifiers match each other and confirming that mutual authentication has been completed (FIG. 5).
7, see FIG. 58).

(6) SPTIC and Kspt in FDB
The device registers the file definition block (FDB: File Def.
In the Inition Block), a service permission ticket (SPT) issuer category (SPTIC) (ex. a reader / writer as a device access device that accesses data in a device file) and Kspt (MAC verification of a service permission ticket (SPT)) The registration key (Kspt) is registered (steps S827 and S828 in the flow of FIG. 73).

(7) Securing File Data Area The device secures a file area having the size described in the file registration ticket (FRT) in the partition to be processed.

With the above processing, the file generation processing according to the mutual authentication (common key) and ticket (FRT) verification (public key) methods is executed.

[B4.6. Service permission ticket (SP
T) Service (File Access) Process] Next, a service permission ticket (SRT) (FIGS. 28 and 31)
The file access process using (see) will be described. The flow of FIG. 79 and subsequent drawings will be described with reference to other drawings.
The file access process includes a mutual authentication process (device authentication or partition authentication) between the device and the file access device, a service permission ticket (S
PT: Service Parmission Ticket).

In the flow of FIG. 79, the left side shows the processing of the file access device, and the right side shows the processing of the device (see FIG. 5). Note that the file access device is a management device of the partition manager, and is a device (ex. A reader / writer or a PC as a device access device) capable of performing data read / write processing on a device, and a reader / writer as a device access device in FIG. Is equivalent to First, the outline of the file access process by the file access device will be described with reference to FIG. 79, and then the details of each process included in this process will be sequentially described with reference to the flow of FIG.

First, steps S851 and S86 in FIG.
At 0, a mutual authentication process is performed between the file access device and the device. Execute data transmission / reception 2
The two means mutually confirm whether or not the other party is a correct data communicator, and thereafter perform necessary data transfer. The process of confirming whether the other party is the correct data communicator is the mutual authentication process. A session key is generated at the time of the mutual authentication process, and encryption is performed using the generated session key as a shared key to transmit data.

[0666] The mutual authentication process is the same process as described in the section of the partition generation and deletion process, and the partition authentication is executed. Either common key authentication or public key authentication processing is applied to each of them. This mutual authentication process is the same as that shown in FIG.
Since the processing is the same as that described with reference to FIG.

The processing to be executed as the mutual authentication processing is the service permission ticket (SPT) (FIG. 2) to be applied.
8, see FIG. 31) * Authentication Flag: A flag indicating whether mutual authentication with a device is necessary in the process of using a ticket (Ticket) * Authentication Type: Type of mutual authentication of the device (Device) It is determined by key authentication or symmetric key authentication, or any.

If the authentication processing has failed (S852, S8
No at 61) indicates that it is not possible to confirm that they are valid devices and devices, and the following processing is not executed and the processing ends as an error.

[0669] device is processed is also possible to allow the file access of a plurality of different partition based on a plurality of service permission ticket (SPT). For example,
It is possible to permit file access in a plurality of different partitions based on a plurality of service permission tickets (SPTs), provided that the device authentication is established.
The file access rule for each partition is described in a service permission ticket (SPT) configured as access control data. The device receives a plurality of service permission tickets (SPT) from the access device, and each ticket performs device authentication. If the request is made, file access in each partition is permitted on condition that device authentication has been established in accordance with the description.

[0670] If each of the plurality of service permission tickets (SPTs) defines different authentication conditions, the device may execute the plurality of service permission tickets (SPTs) on the condition that the partition authentication set in each service permission ticket (SPT) is established. Access to the specified file of the service permission ticket (SPT) of the user is permitted.

Next, in step S853, the file access device transmits a service permission ticket (SPT) to the device. The service permission ticket (SPT) is a service permission ticket (SP) managed by the partition manager.
T) A ticket issued by an issuing means (SPT Issuer). The service permission ticket (SPT) is an access control ticket for the device, and has the data format configuration of FIGS. 28 and 31 described above.

[0672] The service permission ticket (SPT)
Is transmitted to the ticket user, in the case of the public key method, the public key certificate (CERT_SPTI) of the service permission ticket (SPT) issuing means (SPT Issuer) is also transmitted. Public key certificate of the SPT issuing means (CERT_SPT
The attribute of (I) is the FDB (File
This matches the ticket issuing means code (SPTIC) recorded in the Definition Block).

The device that has received the file registration ticket (SPT) (S862) transmits the received ticket (SR
T) is executed and the user is checked (S863)
I do. The processing for verifying the validity of the ticket is executed by applying either MAC verification using a common key method or signature verification processing using a public key method. User check
This is a process for checking the validity of the device (ticket user) that has transmitted the ticket. Mutual authentication has been completed, and the identification data of the authentication partner and the ticket user identifier recorded in the ticket (FIG. 28, FIG. 28). 31) is executed as a process for verifying a match with the above. These processes are the same as those described with reference to FIGS. 57 to 59 in the description of the application process of the partition registration ticket (PRT), and thus description thereof is omitted.

In the device, the reception ticket (SP
T) If the validity of the ticket and the user cannot be confirmed as a result of the user check processing and the validity of the user (S8)
(No at 64) notifies the file access device of a service permission ticket (SPT) reception error (S868). When the validity of the ticket and the user can be confirmed (Yes in S864), the file open processing stored in the memory unit in the device is executed according to the rule described in the received service permission ticket (SPT). . Details of this processing will be described later using another flow.

According to the description of the service permission ticket (SPT), the file open processing succeeds (Y in S866).
es) Then, the SPT reception is notified to the file access device (S867). On the other hand, if the file open processing has failed (No in S866), an SPT reception error is notified to the file access device (S868).

The file access device receives the SPT reception result (S854), determines the result of the SPT processing,
If the T reception result is an error (No in S855),
The process ends as an error, and the SPT reception result succeeds (S
If Yes in 855, it is determined whether or not all SPT transmissions have been completed (S856). If there is an untransmitted SPT, step S853 and subsequent steps are repeated.

If all SPT transmissions have been completed, file access according to the service permission ticket (SPT) is executed in steps S857 and S869, and after the file access processing is completed, transmission / reception of the session clear command (S858, S870) ) Is performed to discard the authentication table generated on the device side (S871), and the process ends. For details on the file access process,
Details will be described later using another flow. The authentication table is a table generated in the mutual authentication process in steps S851 and S860, and has the same configuration as that described in the item of the application process of the partition registration ticket (PRT), that is, the same configuration as that of FIG. It is.

As described above, the service permission ticket (SP
Using T), an access process to a file in a partition set in the device is executed. Hereinafter, the file open process included in this process (S86
5), various file access processing (S857, S86)
9) will be described.

(File open processing) File open processing (FIG. 79, S865) in accordance with the flow of FIG.
Will be described. The file open process is a process executed according to a service permission ticket (SPT) received by the device.

[0680] In step S881, the device:
It is determined whether the file specified in the received service permission ticket (SPT) has been generated in the device and exists. The file ID of the file to be processed is recorded in the service permission ticket (SPT) (see FIGS. 28 and 31), and the presence or absence of a file having the same ID is determined by referring to, for example, a file definition block (FIG. 24). I do. If a file with the same ID as the ID described in the ticket does not exist, processing is impossible, and the processing ends with an error.

If a file with the same ID as the ID described in the ticket exists, in step S882
Service permission ticket (S
Ticket issuer described in the PT
= PMC: Partition managerCode) and an entry in which a file ID described in a service permission ticket (SPT) is associated.

Further, in step S883, the file access mode described in the service permission ticket (SPT) in association with the entry generated in the file open table [File Access Mode: access mode to the file (File) to which access is permitted (Access Mod
e)], and in step S884, an access permission group file [Group of Target File: a group of files (File) permitted to access] described in the service permission ticket (SPT) is written. In step S885, the service Write the access permission file identifier [Target File ID: identifier (ID) of the file (File) permitted to access] described in the permission ticket (SPT), and further, step S886.
, Processing mode data [Read / Write Permission: File (File) (Access target file (Target Fil)) for the target file (Target File) described in the service permission ticket (SPT).
e)), the writing process of the processing mode (permission of reading (Read) and writing (Write))] is performed. In addition,
The processing for the target file is not limited to reading and writing, and various processing can be set.

FIG. 8 shows a configuration example of the file open table.
1, shown in FIG. The file open table is a table in which information on a file in an access processing state in a device, an access mode, and other information is recorded. The description information of a service permission ticket (SPT) received by the device is recorded and stored in a storage unit of the device. .

[0684] A service permission ticket in a form in which the ticket permits access to only one file (FIG. 28)
), The file open table contains * Ticket Issuer: ticket issuing means (Ticket Issuer)
Identifier * File ID: Access file (Fil
e) Identifier (ID) * File Access Mode: File (File
le) Access mode information is stored. FIG. 81 shows a configuration example of the file open table in this case.

As shown in FIG. 81, in the file open table, a ticket issuer which is group information: a partition manager code (PMC) is described as an identifier of a ticket issuing means (Ticket Issuer), a partition is determined, and a file ID is determined. , The file is identified, and an executable access mode (ex. Read (READ), write (Write), encryption / decryption (Enc, Dec)) can be determined in the file access mode.

If the service permission ticket (SPT) is a service permission ticket of a format permitting access to a plurality of files among the files set in the partition (see FIG. 31), * Group is added to the above information. of Target File: File that allows access (Fi
le) Group (Group) * Target File ID: Identifier (ID) of file (File) to be allowed to access * Read / Write Permission: Processing mode (Reading) for file (Target File) to be allowed to access (Read), Write (Write))
The permission information is written to the table. FIG. 82 shows a configuration example of the file open table in this case.

As shown in FIG. 82, the file open table set in correspondence with the service permission ticket in a format permitting access to a plurality of files includes
In addition to the data shown in FIG. 1, a partition manager code (PM) as partition identification data as a group of target files (File) to which access is permitted
C), a file ID as an identifier (ID) of the target file (File) to which access is permitted, and a processing mode for the target file (Target File).
d / Write Permission] data is stored, and executable processes for a plurality of files can be determined.

[0688] The process of executing access to a plurality of files is, for example, a case of executing a process of encrypting data stored in file B using a key stored in file A. For this purpose, file B needs to give permission for a read request for file A. In this case, file B is a source file,
The file to which permission is given is called a target file.

[0689] As described above, the device transmits the service permission ticket (SP) received during the session with the access device.
T), a ticket issuer (PM)
C)) as the partition manager code (PM
C), generating a file open table in which a file identifier as identification data of the file that has been subjected to the file open processing is associated with an access mode described in a service permission ticket (SPT), and referring to the file open table. It is possible to determine whether to execute the received command from the access device.

(File Access Processing) Next, details of the file access processing executed in steps S857 and S869 of FIG. 79 will be described.

First, the access processing when the file open table shown in FIG. 81 is generated will be described with reference to FIG.
This will be described with reference to FIG. Two file access devices (R / W: reader / writers as device access devices) 750 and 760 are shown on the left side of the figure, and a partition portion of the device 100 in which the file is generated is shown on the right side.

The file access device (R / W: reader / writer) 750 sends an access permission ticket of file ID: [0x0002] file access mode: [read: Read] to the device 100 after mutual authentication with the device. It is assumed that the validity of the ticket, the ticket issuer, and the user have been successfully verified.

At this time, the entry of the second row of the file open table shown in FIG. 81 is generated in the device. This entry indicates that access mode [Read: Read] processing can be executed for the file ID [0x0002] in the partition identified by the partition manager code (PMC1).

At this time, the file access device (R /
(W: reader / writer) 750 generates a command and transmits it to the device. For example, file ID [0x00
02]: Read Comm
When the device receives and (0x0002), the device checks the entry of the file open table,
It is confirmed that the access mode [Read: Read] processing can be executed for the file ID [0x0002], and the read processing is executed.

[0695] In addition, file access unit (R / W: reader-writer) 750 is, for example, a file ID [0x00
02]: Write Com
mand (0x0002) or file ID [0
x0001] data encryption processing command: Encr
In a case where the option command (0x0001) is transmitted to the device, the device that has received the command checks the entry of the file open table, and writes [Write: Writ] for the file ID [0x0002].
e] and that the [encryption processing] of the file ID [0x0001] is not permitted by the service permission ticket (SPT) received from the file access device (R / W: reader / writer) 750. , Stop the process.

[0696] After mutual authentication with the device, the file access device (R / W: reader / writer) 760 sends the file ID: [0x0001] file access mode: [encryption / decryption processing: Enc].
& Dec] is transmitted to the device 100, and the validity of the ticket, the ticket issuer, and the user are successfully verified.

At this time, the entry of the first line of the file open table shown in FIG. 81 is generated in the device. This entry indicates that the process in the access mode [encryption / decryption process: Enc & Dec] can be executed for the file ID [0x0001] in the partition identified by the partition manager code (PMC1).

At this time, the file access device (R /
(W: reader / writer) 760 generates a command and transmits it to the device. For example, file ID [0x00
01] encryption command [Encryption Co
mmand (0x0001)], the device checks the entry in the file open table, and confirms that the access mode [encryption / decryption processing: Enc & Dec] can be executed for the file ID: 0x0001. Then, an encryption process is performed.

[0699] In addition, file access unit (R / W: reader-writer) 760 is, for example, a file ID [0x00
02]: Read Comm
and (0x0002) to the device,
The device that has received the command checks the entry in the file open table, and checks the file ID [0x0002].
It is confirmed that the processing of [Read: Read] is not permitted by the service permission ticket (SPT) received from the file access device (R / W: reader / writer) 760, and the processing is stopped.

As described above, based on the service permission ticket (SPT) received by the device from the reader / writer serving as the device access device as the service permission ticket user, the device sets the file open table in accordance with the processing flow of FIG. Based on the generated file open table, whether or not each command can be executed from a reader / writer as a file access device is determined, and processing is performed according to the determination.

Next, an access process when executing a process for two files will be described with reference to FIG. Two file access devices (R /
W: reader / writer) 770 and 780, and the right side shows a partition portion of the device 100 in which the file is generated.

First, an example of execution of processing using a service permission ticket (SPT) (see FIG. 31) specifying a target file will be described.

After mutual authentication with the device, the file access device (R / W: reader / writer) 770 receives the SPT format 1 file ID: [0x0001] file access mode: [encryption / decryption processing: Enc]
& Dec] and SPT format 2 File ID: [0x0002] Target file group: [PMC1] Target file ID: [0x0001] Read / write permission: [Read: Read] It is assumed that the validity of the ticket, the ticket issuer, and the user have been successfully verified.

At this time, an entry of the file open table shown in FIG. 82 is generated in the device. This entry contains the partition manager code (PMC
File ID [0] in the partition identified by 1)
[x0001] is a key file, which is opened so as to enable encryption and decryption. File ID [0
x0002] is a data file, and reading from the outside is performed in a file access mode (File Access Mod).
This is impossible because the column of e) is blank and the file ID [0
[x0001] is opened for the purpose of enabling [Read: Read], and is set as an entry in the file open table.

At this time, the file access device (R /
(W: reader / writer) 770 generates a command and transmits it to the device. For example, file ID [0x00
02], and an internal encryption command using the file ID [0x0001]: Internal Encrypt
ption Command (0x0001, 0x00
02), and when the device receives the command, the device checks the entry of the file open table, and performs the [encryption processing] of the target file group [PMC1] and the target file [0x0001] for the file ID [0x0002]. ] Is determined to be executable, the data of the file ID [0x00002] is read, and encryption using the key (key) of the file ID [0x00001] is executed to encrypt the encrypted data. Send to access device.

According to the processing using the service permission ticket (SPT) designating the target file (see FIG. 31), data read from one file is encrypted using an encryption key stored in another file. Processing for acquiring data becomes possible, and there is no possibility that decrypted data leaks to the outside.

Next, instead of the service permission ticket (SPT) specifying the target file (see FIG. 31),
The processing when a plurality of service permission tickets (SPTs) (see FIG. 28) that specify processing for a single file are used will be described.

[0708] After mutual authentication with the device, the file access device (R / W: reader / writer) 780 performs SPT format 1, file ID: [0x0002] file access mode: [read: Read] or SPT format 2. file ID: [0x0001] file access mode: encryption decryption processing: Enc
& Dec] to the device 100,
It is assumed that the validity of the ticket, the ticket issuer, and the user have been successfully verified.

At this time, each entry of the first row and the second row of the file open table shown in FIG. 81 is generated in the device. In this entry, access mode [encryption / decryption processing: Enc & Dec] processing can be executed on the file ID [0x0001] in the partition identified by the partition manager code (PMC1), and the partition manager code (PM
File ID in the partition identified in C1):
Access mode [Read: Re
ad] can be executed.

At this time, the file access device (R /
(W: reader / writer) 780 generates a command and transmits it to the device. First, the file ID: [0x0
002] data read command: Read Com
When the device receives the command “mand (0x0002)”, the device confirms the entry in the file open table, confirms that the access mode [Read: Read] can be executed for the file ID: 0x0002, and executes the read process. Execute and send the read data to the file access device.

Next, the file access device (R / W: reader / writer) 780 further generates a command and transmits it to the device. File ID [0x0001]
(Data) encryption command [Encr]
yption Command (0x0001, Dat
a)] is received by the device, the device confirms the entry in the file open table, and checks the file ID [0].
x0001], it is confirmed that the processing of the access mode [encryption / decryption processing: Enc & Dec] can be executed, the encryption processing is executed, and the encrypted data [Encrypt] is executed.
data] to a file access device (R /
W: reader / writer).

As described above, in the case where a plurality of service permission tickets (SPT) (see FIG. 28) specifying processing for a single file are used instead of the service permission ticket (SPT) specifying target files (see FIG. 31). In this case, the process of reading the data to be encrypted is executed, and the number of data transfer processes between the file access device 780 and the device increases. Also, data is read out of the device without being encrypted.

[0713] On the other hand, a service permission ticket (SPT)
(See FIG. 31) includes a plurality of file identifiers for identifying a plurality of data files to be accessed, and one of the plurality of file identifiers is set as a target file identifier and read or write permission data for the target file is set. Is stored, and the encryption processing using the encryption key stored in the data file is set as the access mode of the other data file, the memory-equipped device receives the service permission ticket (SPT) from the access device. Then, as processing in accordance with the designated access mode, reading of the target file and encryption processing using the encryption key are executed, and internal encryption processing in the memory-equipped device can be executed. In addition, it is possible to prevent data from leaking out of the device without being encrypted.

[0714] Ticket issuing means for issuing a service permission ticket (SPT) is a ticket issuing means under the control of a partition manager which is an entity for managing a memory area of a memory-mounted device. By individually issuing a service permission ticket (SPT) in which an access mode is set, a configuration is realized in which different types of access can be executed according to each access device.

(Usage of Session Key) Note that data transmitted and received between the file access device and the device is often data to be prevented from being leaked to the outside, such as device user information or money amount information.
Therefore, data transmitted and received between the file access device and the device is subjected to encryption processing, and a MAC (Message Authentication Code) is used as a tampering check value.
It is desirable to use data added with e).

For data encryption, it is possible to use a session key generated in a mutual authentication process performed between the file access device and the device.
As described above, the mutual authentication includes device authentication for a device and partition authentication as authentication for each partition. When accessing a file that has already been generated in a partition, there are several options as to which encryption key to apply when transferring data.

For example, as shown in FIG.
0 and the access device 800, a session key Kses1 generated by device authentication, a session key Kses2 generated by partition authentication with a partition corresponding to the partition manager code (PMC1), and a partition manager code (PMC2). Key Kses3 generated by partition authentication with the partition to be executed
There may be.

[0718] These are stored until the session is cleared in the authentication table (see Figs. 51 and 52) generated at the time of mutual authentication.

[0719] A reader / writer (PC or other communication device) as a device access device that executes device-to-device communication determines which of the plurality of session keys is to be used to execute encrypted communication as a rule. A configuration in which a session key is applied in advance according to a determined rule is possible.

If file access in a plurality of different partitions is permitted on condition that all the authentications of the partition authentication or the device authentication which are the authentication conditions set corresponding to the plurality of different partitions are permitted, a plurality of authentication processes are performed. As a result, a unique integrated session key is generated based on the acquired plurality of session keys, and encryption processing of communication data with the access device is executed based on the integrated session key.

[0721] One method as an integrated session key generation method is that a plurality of session keys Kses1 to Kses1 through a mutual authentication process between a reader / writer (PC or other communication device) as a device access device for performing communication between devices. When KsesN is generated, an exclusive OR process (ex. 8 byte process) of the plurality of session keys Kses1 to KsesN is executed, and the operation result is used as a session key for encrypting communication data. That is, Kses = Kses1 XOR Kses2 XOR Kses3... XOR: Kses calculated by exclusive OR processing (ex. 8 byte processing) is used as the session key.

[0722] Devices and Between the reader writer as the device access apparatus for performing communication with the device (PC other communication devices), operates an exclusive session key stored in both the authentication table session its output value A rule of using as a key is determined, and a session key is calculated based on the rule and used for encrypting communication data. Similarly, another session key shared at the time of mutual authentication, for example, a session key generated at the time of public key authentication, or session key generation data, for example, communication data during a session using the lower 64 bits of the Y coordinate. A MAC value can be added. By transmitting this MAC value together with communication data (which may be encrypted data) and performing MAC verification processing on the receiving side, it is possible to prevent data tampering on the communication path. Refer to FIG. 59 described above for the MAC generation and verification processing.

[0723] Alternatively, a plurality of session keys Kses1 to KsesN obtained by mutual authentication processing between a reader / writer (a PC or other communication device) as a device access device that executes communication between devices.
, A rule is set that selects any one key (ex. The latest session key) and applies it as a data encryption key in the subsequent communication processing, and selects a session key according to the rule. A configuration used for encrypting communication data may be adopted.

[0724] The above-described calculation or selection processing of a plurality of session keys is performed not only for encrypted communication between the file access device and the device, but also for all tickets (PRT, FRT, SPT, DUT) users (devices). The present invention can be applied to a case where a plurality of session keys are generated by mutual authentication in an encrypted communication process between a device such as a reader / writer as an access device that performs data communication with a device) and the device. According to each ticket user and the device, what rules are to be applied to calculate or select the session key to be applied from a plurality of session keys as a rule in advance, execute after confirming the rules with each other, or Measures such as recording rules in each ticket can be adopted.

Next, referring to FIGS. 86 and 87, an access process to a device by the file access device (FIG. 7)
A representative example of the procedure in steps S857 and 869 in the processing flow of No. 9 will be described.

The process (Normal) when accessing only one file will be described with reference to FIG. 86, and the process (Combination) when accessing a plurality of files will be described with reference to FIG. 87. I do.

First, the processing (Normal) in the case of executing access to only one file in FIG. 86 will be described. In the flow of FIG. 86, the left side shows the processing of the file access device, and the right side shows the processing of the device (see FIG. 5). In the file access process, when transferring data between the file access device and the device, the session key Kse acquired in the mutual authentication process is used.
From the s or a plurality of session keys, the operation matrices are encrypted using the selected session keys, and a MAC for falsification check is generated and verified.

[0728] The file access device determines in step S89
At 1, send an access command to the device.
This command specifies a file ID to be accessed and an access mode.
File ID [0x0002] as described using
Data read command: Read Command
(0x0002) or file ID [0x00
01] encryption command [Encryption Co
mmand (0x0001)].

Upon receiving a command from the file access device (S901), the device determines whether or not the file ID and access mode included in the command are recorded as permitted entries in the file open table (S902). . If there is no entry of the file ID and the access mode corresponding to the command in the file open table, the process according to the command is not executed, and an access error is transmitted to the file access device (S908).

If the file ID and access mode entry corresponding to the command exists in the file open table, in step S903, it is recorded in the file definition block (FDB) (see FIG. 24) of the corresponding partition in the memory of the device. Refers to the file access authentication method (Acceptable Authentication Type: the authentication method specified when accessing a specific file (File)), and the authentication level (public key authentication) required to execute the access command for the file to be accessed. Is required).

[0731] In step S903, the file access authentication method (Acce) of the file definition block (FDB) is used.
If the ptable Authentication Type) is a setting that requires public key authentication, in step S904, it is determined whether public key authentication has been completed as the authentication of the authentication level required for the access command. If
An access error is transmitted to the file access device without executing the processing according to the command (S908). Whether the authentication is completed or not completed is determined based on an authentication table (see FIG. 51) set at the time of the mutual authentication.

In step S903, the file access authentication method (Acce
ptable Authentication Type) is a setting that requires public key authentication, and if it is determined in step S904 that the public key authentication has been completed, or if the file access authentication method (Ac) of the file definition block (FDB) is used.
If ceptable Authentication Type does not require public key authentication, then in step S905, the file access recorded in the file definition block (FDB) of the corresponding partition in the memory of the device (see FIG. 24) Verification method (Acceptable Verificatio
n Type: When accessing a specific file (File),
(Verification method to be specified), and confirms the verification level (whether the public key method needs to be verified) required to execute the access command for the file to be accessed.

[0733] In step S905, the file access verification method (Acce
If the “ptable Verification Type” is a setting that requires public key ticket verification, it is determined in step S906 whether the public key ticket verification as a verification of the verification level required for the access command has been completed. If the verification has not been completed, the process according to the command is not executed, and the access error is transmitted to the file access device (S908).

In step S905, the file access verification method (Acce
ptable Verification Type) is a setting that requires public key ticket verification, and if it is determined in step S906 that the public key ticket verification has been completed, or if file access in the file definition block (FDB) is performed. Verification method (Acceptable Verification
If Type does not require public key ticket verification, in step S907, processing of the access command received from the file access device is executed, and the result is transmitted to the file access device.

[0735] Receive access command result (S892)
The determined file access device determines whether or not to execute another file access (S893). If another file access is to be executed, the steps S891 and subsequent steps are repeated, and no other file access is executed. Ends the processing.

Next, processing for accessing a plurality of files with reference to FIG. 87 (combination)
n) will be described. In the flow of FIG. 87, the left side is a file access device, and the right side is a device (see FIG. 5).
Is shown. In the file access process,
When data is transferred between the file access device and the device, the data is encrypted using the session key Kses obtained in the mutual authentication process or a session key calculated or selected from a plurality of session keys, and a MAC for falsification check. Are generated and verified.

[0737] The file access device, step S91
At 1, send an access command to the device.
This command specifies a file ID (source) to be accessed, a target file ID, and an access mode. For example, for the source file ID [0x0002] described with reference to FIG. Command [Inte that specifies execution of internal encryption processing using the key of file ID [0x0001]
rnal Encryption Command (0x
0001, 0x0002)].

[0738] Upon receiving the command from the file access device (S921), the device determines whether or not the entry of the target file ID in the file open table has permission for the access command (S922). Target file I of file open table
If there is no access command permission in the entry of D, the process according to the command is not executed, and an access error is transmitted to the file access device (S934).

If the access command permission exists in the entry of the target file ID of the file open table, in step S923, the file is recorded in the file definition block (FDB) (see FIG. 24) of the corresponding partition in the memory of the device. Refers to the file access authentication method (Acceptable Authentication Type: the authentication method specified when accessing a specific file (File)), and the authentication level (public key authentication) required to execute the access command for the target file to be accessed. Is required).

In step S923, the file access authentication method (Acce) of the file definition block (FDB) set for the target file to be accessed is set.
If ptable Authentication Type) is a setting that requires public key authentication, in step S924, it is determined whether public key authentication has been completed as the authentication of the authentication level required for the access command. If
An access error is transmitted to the file access device without executing the processing according to the command (S934). Whether the authentication is completed or not completed is determined based on an authentication table (see FIG. 51) set at the time of the mutual authentication.

[0741] In step S923, the file access authentication method (Acce) of the file definition block (FDB) set for the target file to be accessed is set.
ptable Authentication Type) is a setting that requires public key authentication, and it is determined in step S924 that the public key authentication has been completed, or the file access authentication method (Ac) of the file definition block (FDB)
If the ceptable Authentication Type does not require public key authentication, then in step S925, the file access recorded in the file definition block (FDB) (see FIG. 24) of the corresponding partition in the memory of the device. Verification method (Acceptable Verificatio
n Type: When accessing a specific file (File),
(Verification method to be specified), and confirms the verification level (whether the public key method needs to be verified) required to execute the access command for the target file to be accessed.

In step S925, the file access verification method (Acce) of the file definition block (FDB) set for the target file to be accessed is set.
If the “ptable Verification Type” is a setting that requires public key ticket verification, it is determined in step S 926 whether the public key ticket verification as the verification of the verification level required for the access command has been completed. However, if the verification has not been completed, the process according to the command is not executed, and an access error is transmitted to the file access device (S934).

In step S925, the file access verification method (Acce) of the file definition block (FDB) set for the target file to be accessed
ptable Verification Type) is a setting requiring public key ticket verification, and if it is determined in step S926 that the public key ticket verification has been completed, or if file access of the file definition block (FDB) is performed. Verification method (Acceptable Verification
If (Type) is a setting that does not require public key ticket verification, then in step S927, the access method (Read / Write) of the file specified by the target file ID included in the access command is set to the command. Check based on

[0744] The device determines whether or not the file specified by the source file ID included in the command from the file access device is open for the access method (Read / Write) included in the access command (S928). I do. If there is no access method (Read / Write) for executing the command in the file open table, the process according to the command is not executed, and an access error is transmitted to the file access device (S934).

If the file open table has an access method (Read / Write) corresponding to the command,
In step S929, the file access authentication method (Ac) recorded in the file definition block (FDB) (see FIG. 24) of the corresponding partition in the memory of the device.
ceptable Authentication Type: Specific file (Fil
e) At the time of access, refer to the specified authentication method) and confirm the authentication level (whether public key authentication is required) required to execute the access command for the source file to be accessed.

In step S929, the file access authentication method (Acceptab) of the file definition block (FDB) set for the source file to be accessed is set.
If the authentication type is a setting that requires public key authentication, it is determined in step S930 whether or not public key authentication has been completed as the authentication of the authentication level required for the access command. In this case, the process according to the command is not executed, and the access error is transmitted to the file access device (S934). Whether the authentication is completed or not completed is determined based on an authentication table (see FIG. 51) set at the time of the mutual authentication.

[0747] In step S929, the file access authentication method (Acceptab) of the file definition block (FDB) set for the source file to be accessed is set.
le Authentication Type) is a setting that requires public key authentication. If it is determined in step S930 that public key authentication has been completed, or if the file access authentication method (Accept
If the setting does not require public key authentication, then in step S931, the file access verification recorded in the file definition block (FDB) (see FIG. 24) of the corresponding partition in the memory of the device is determined. Method (Acceptable Verification
Type: The verification level required to execute the access command for the source file to be accessed by referring to the specified verification method when accessing a specific file (File) (whether verification of the public key method is required) Check.

In step S931, the file access verification method (Acceptab) of the file definition block (FDB) set for the source file to be accessed
If the “le Verification Type” is a setting that requires public key ticket verification, it is determined in step S932 whether the public key ticket verification as verification of the verification level required for the access command has been completed. If the verification has not been completed, an access error is transmitted to the file access device without executing the processing according to the command (S
934).

[0749] In step S931, the file access verification method (Acceptab) of the file definition block (FDB) set for the source file to be accessed is set.
le Verification Type) is a setting that requires public key ticket verification, and if it is determined in step S932 that public key ticket verification has been completed, or if file access in the file definition block (FDB) has been performed. Verification method (Acceptable Verification Typ
If e) is a setting not requiring public key ticket verification, in step S933, the process of the access command received from the file access device is executed, and the result is transmitted to the file access device.

The access command result is received (S912).
The determined file access device determines whether or not to execute another file access (S913). If another file access is to be executed, the steps S911 and the subsequent steps are repeated, and no other file access is executed. Ends the processing.

[0751] The file access processing described above, the data specified are explained by assuming the processing when stored by a single file structure in the file,
It is also possible to store different file structure data in one file and execute the same processing as the above-described sequential processing for a plurality of files by one command for one file.

FIG. 88 is a view for explaining a configuration for executing sequential processing on data in one file by one command for one file.

[0753] As shown in the figure, the file is an electronic money file, and includes [Purse] as money data, "Log" as usage log data, and [Key] as key data for encrypting or decrypting data. Be composed.

For example, as shown in FIG. 88 (a), a deposit command (Deposit Command) is defined, X yen is added to [Purse] as the amount data in the file (S941), and it is possible to adopt a configuration to execute the two processes of [Purse] to write a record obtained by adding the X circle (S942) to "log" as the usage log data.

As the allowable command (see FIG. 30) corresponding to the deposit system in the file access mode (see FIG. 29) described above, the deposit command (Deposit Comman
d), set the file access mode (File Access Mode) of the access permission ticket to "Deposit",
As a file ID (File ID), an access permission ticket (SP
T) is generated and transmitted from the file access device to the device, and then a deposit command (DepositComman
By transmitting the deposit amount data together with d), the device as shown in FIG. 88A can execute the sequential processing on the data in one file.

As shown in FIG. 88 (b), a receipt generation command (Make Receipt Command) is defined, X yen is subtracted from [Purse] as the amount data in the file (S945), and the file The record obtained by subtracting the X circle from [Purse] is written in “Log” as the use log data in (S946), and “Log” is further written.
g ”as the encryption key data for the data
[3], a three-step process of applying a signature and transmitting (S947) is also possible.

[0757] In this case, file access mode (Fig. 2
9) (see FIG. 30) corresponding to the withdrawal system (see FIG. 30).
pt Command), set the file access mode (File Access Mode) of the access permission ticket to “withdrawal”, and specify the composite file that constitutes electronic money as the file ID (File ID). After generating the (SPT) and transmitting it from the file access device to the device, the receipt generation command (Make
By transmitting the withdrawal amount data together with the Receipt Command), the device as shown in FIG. 88B can execute the sequential processing on the data in one file.

[0758] As described above, when the processing file specified in the service permission ticket (SPT) is a composite file, the device selects a file to be processed by the command received from the access device from the composite file and executes the processing. . If the data processing command from the access device is a sequence processing command including a series of multiple processes, the device specifies the processing target file of each command included in the sequence processing command specified by the service permission ticket (SPT). Select and execute sequentially from within the compound file.

[B4.7. Service permission ticket (SP
Processing Procedure in Each Access Processing Method Using T)]
In the access registration file setting and registration process using the service permission ticket (SPT) described above, the partition manager manages the service registration ticket (SPT).
PT) Mutual authentication is performed between a reader / writer as a device access device as a user and a device,
File access based on the service permission ticket (SPT) is performed. The mode of the mutual authentication processing is either public key mutual authentication or common key mutual authentication, and the ticket (SPT) verification processing is also of two types: public key signature verification and common key MAC verification. Will be executed. That is, the processing mode is roughly divided into (A) mutual authentication (public key), ticket (SPT) verification (public key), (B) mutual authentication (public key), ticket (SPT) verification (common key) (C) There are four modes: mutual authentication (common key), ticket (SPT) verification (common key), (D) mutual authentication (common key), and ticket (SPT) verification (public key).

The processing for these four aspects is performed by a certificate authority (CA (PM)), a partition manager (P
M), a reader / writer as a device access device as an SPT ticket user, a device, and a data transfer process executed between each entity will be briefly described with reference to the drawings.

(A) Mutual authentication (public key), ticket (S
PT) Verification (Public Key) First, data transfer between entities when a public key method is applied to mutual authentication processing and a public key method is applied to ticket (SPT) verification will be described with reference to FIG.

Data transfer is performed between the entities in the order of the numbers shown in the figure. Hereinafter, the processing will be described according to the respective numbers. (1) Issuing a public key certificate (Cert.PM) of the partition manager (PM), and issuing a public key certificate (Cert.PM) of the partition manager (PM) by an issuance request from the partition manager (PM)
The certificate is issued from the partitioning certificate authority (CA (PAR)) by a certificate issuing procedure via the registration authority (RA). In this configuration, the partition manager also serves as a service permission ticket issuing means (SPT Issuer), and the service permission ticket issuing means (SPTI
The public key certificate of the partition manager (PM) is used as the public key certificate of the ssuer.

(2) Service permission ticket user (SP
T User) issuance of a public key certificate (Cert. RW) of a reader / writer (R / W) as a device access device, and a service permission ticket user (SPT User: specifically, a ticket is transmitted to the device) The public key certificate (Cert.R / W) of the reader / writer (R / W) as the device access device to perform is a reader / writer (R / W) that is a service permission ticket user (SPT User).
W), a certificate issuance procedure via a registration authority (RA) is performed, and a partitioning certificate authority (C) is issued.
A (PAR)). Note that the partition manager uses the service permission ticket user (SPT).
The public key certificate of the partition manager (PM) can be used as the public key certificate of the service permission ticket user (SPT User).

(3) Generating Service Permission Ticket (SPT) The service permission ticket (SPT) is a service permission ticket issuing means (S
PT Ticket Issuer). In this case, a signature (Signature) using a private key of the service permission ticket issuing means (SPT Ticket Issuer) is generated (see FIG. 12) to execute signature generation and verification in the public key system, and the process proceeds to S.
Added to PT.

(4) A reader / writer as a device access device which is a service permission ticket user (SPT User) of a partition manager public key certificate (Cert. PM) as an SPT and a service permission ticket issuing means (SPT Ticket Issuer) R / W) service permission ticket issuing means for management of the supply partition manager for (issued service permission ticket by SPTTicket Issuer) (SPT) is, partition manager public key certificate as a service permission ticket issuing means (SPT Ticket Issuer) (Cert. PM)
With service permission ticket user (SPT User)
Is a reader / writer (R
/ W).

(5) Mutual authentication between a reader / writer (R / W) as a device access device and a device The reader / writer, which is a service permission ticket user (SPT User), issues service permission ticket issuing means (SPT).
Ticket Issuer) issued service permission ticket (S
(PT), a ticket user (SPT User) for a device to be accessed for file access.
Public key certificate (Ce) of reader / writer (R / W)
rt. RW) to the device, and performs mutual authentication using the public key method (see FIG. 50).

(6) Supply of Partition Manager Public Key Certificate (Cert. PM) as SPT and Service Permission Ticket Issuing Means (SPT Ticket Issuer) to Device Reader / Writer (R / W) as Device Access Device
When mutual authentication between the device and the device is established, the reader / writer (R / W) as the ticket user (SPT User)
Service permission ticket (SPT) and service permission ticket issuance means (SPT Ticket Is
suer) as a partition manager public key certificate (Cert.PM).

[0768] The device checks (1) the ticket issuer (Ticket) for the received service permission ticket (SPT).
Issuer) is that the partition manager public key certificate (Cert. PM) is a legitimate public key certificate (CERT) that is not falsified, and (2) the public key certificate (Ticket Issuer) of the ticket issuer. CERTP
M) and the code recorded in the FDB (File Definition Block) in the device.
PTIC), (3) Ticket Issue Means (Ticket Issue)
r) is not revoked, and (4) verification of the ticket is not falsified by verifying the signature of the received ticket (SPT). Further, the SPT user (ticket user) stored in the SPT ticket is checked. Data (DN) of the public key certificate (Cert. RW) of the reader / writer as the user and the ticket user (SPT User)
Verification of the SPT user (reader / writer as a device access device) by confirming the match of the identifier or category or serial (SN) name (DN) recorded as 58 (see FIG. 58).

(7) File Access The device accesses the file to be processed according to the rules described in the service permission ticket (SPT).

[0770] Through the above processing, file access processing according to the mutual authentication (public key) and ticket (SPT) verification (public key) methods is executed.

(B) Mutual authentication (public key), ticket (S
PT) Verification (Common Key) Next, data transfer between entities when the public key method is applied to the mutual authentication processing and the common key method is applied to the ticket (SPT) verification will be described with reference to FIG.

[0772] Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers.

(1) Service permission ticket user (SP
T User) issuance of a public key certificate (Cert. RW) of a reader / writer (R / W) as a device access device, and a service permission ticket user (SPT User: specifically, a ticket is transmitted to the device) The public key certificate (Cert.R / W) of the reader / writer (R / W) as the device access device to perform is a reader / writer (R / W) that is a service permission ticket user (SPT User).
W), a certificate issuance procedure via a registration authority (RA) is performed, and a partitioning certificate authority (C) is issued.
A (PAR)). Note that the partition manager uses the service permission ticket user (SPT).
The public key certificate of the partition manager (PM) can be used as the public key certificate of the service permission ticket user (SPT User).

(2) Generating Service Permission Ticket (SPT) The service permission ticket (SPT) is a service permission ticket issuing means (S
PT Ticket Issuer). In this case, the MAC (Message Authenticatio
n Code) (see FIG. 59) is added to the SPT.

[0775] (3) issued by SPT of services permission ticket user (SPT User) in which the reader writer as the device access equipment (R / W) service permission ticket issuing means for managing the supply partition manager for (SPTTicket Issuer) The service permission ticket (SPT) is transmitted to a reader / writer (R / W) as a service permission ticket user (SPT User).

(4) Mutual authentication between reader / writer (R / W) and device The reader / writer as a device access device which is a service permission ticket user (SPT User) issues service permission ticket issuing means (SPT Ticket Issuer). A public key certificate (Cert. RW) of a reader / writer (R / W) as a ticket user (SPT User) is issued to the device to be accessed for file access according to the service permission ticket (SPT). , And performs public key mutual authentication (see FIG. 50). The public key certificate of the partition manager (PM) can be used.

(5) Supply to SPT device Reader / writer (R / W) as device access device
When mutual authentication between the device and the device is established, the reader / writer, which is a service permission ticket user (SPT User),
A service permission ticket (SPT) is transmitted to the device. The device performs a MAC verification process on the received service permission ticket (SPT), verifies the SPT issuer (SPT Issuer), and further checks the SPT user (a reader / writer as a ticket user) and the ticket user stored in the SPT ticket. (SPT User) identifier or category or serial (S) recorded as the identification data (DN) of the public key certificate (Cert. RW)
N) Verification of the SPT user (reader / writer as a device access device) by confirming that the name (DN) matches and confirming that mutual authentication has been completed (FIGS. 57 and 58)
See).

(6) File Access The device accesses the file to be processed according to the rules described in the service permission ticket (SPT).

[0779] Through the above processing, file access processing according to the mutual authentication (public key) and ticket (SPT) verification (common key) methods is executed.

(C) Mutual authentication (common key), ticket (S
PT) Verification (Common Key) Next, data transfer between entities when the common key method is applied to the mutual authentication process and the ticket (SPT) verification is applied will be described with reference to FIG.

Data transfer is performed between the entities in the order of the numbers shown in the figure. Hereinafter, the processing will be described according to the respective numbers.

(1) Generating Service Permission Ticket (SPT) The service permission ticket (SPT) is a service permission ticket issuing means (S
PT Ticket Issuer). In this case, the MAC (Message Authenticatio
n Code) (see FIG. 59) is added to the SPT.

(2) Supply of SPT to Service Permission Ticket User (SPT User) The service permission ticket (SPT) issued by the service permission ticket issuing means (SPT Ticket Issuer) managed by the partition manager is a service permission ticket user (SPT User). User) is transmitted to a reader / writer as a device access device.

(3) Reader / writer (R / W) as device access device and reader / writer (R / W) as device access device that is a mutual authentication service permission ticket user (SPT User) between devices
Is a service permission ticket issuing means (SPT Ticket Is
Suer) performs mutual authentication using a common key method (see FIGS. 53 and 54) with a device that is to generate a file in accordance with the service permission ticket (SPT) issued by the device.

(4) Supply to SPT device Reader / writer (R / W) as device access device
When mutual authentication between the device and the device is established, the reader / writer, which is a service permission ticket user (SPT User),
A service permission ticket (SPT) is transmitted to the device. The device performs MAC verification processing on the received service permission ticket (SPT), verifies the SPT issuer (SPT Issuer), and further checks the SPT user (a reader / writer as a ticket user) and the ticket user stored in the SPT ticket. Verification of the SPT user (a reader / writer as a device access device) is performed by confirming that the identifiers of the (SPT User) match and confirming that mutual authentication has been completed (see FIGS. 57 and 58).

(5) File Access The device accesses the file to be processed according to the rules described in the service permission ticket (SPT).

[0787] Through the above processing, file access processing is performed according to the mutual authentication (common key) and ticket (SPT) verification (common key) methods.

(D) Mutual authentication (common key), ticket (S
PT) Verification (Public Key) Next, data transfer between entities when a common key method is applied to mutual authentication processing and a public key method is applied to ticket (SPT) verification will be described with reference to FIG.

Data transfer is performed between the entities in the order shown in the figure. Hereinafter, the processing will be described according to the respective numbers. (1) Issuing a public key certificate (Cert.PM) of the partition manager (PM), and issuing a public key certificate (Cert.PM) of the partition manager (PM) by an issuance request from the partition manager (PM)
The certificate is issued from the partitioning certificate authority (CA (PAR)) by a certificate issuing procedure via the registration authority (RA). In this configuration, the partition manager also serves as a service permission ticket issuing means (SPT Issuer), and the service permission ticket issuing means (SPTI
The public key certificate of the partition manager (PM) is used as the public key certificate of the ssuer.

(2) Generating Service Permission Ticket (SPT) The service permission ticket (SPT) is a service permission ticket issuing means (S
PT Ticket Issuer). In this case, a signature (Signature) using a private key of the service permission ticket issuing means (SPT Ticket Issuer) is generated (see FIG. 12) to execute signature generation and verification in the public key system, and the process proceeds to S.
Added to PT.

(3) A reader / writer as a device access device which is a service permission ticket user (SPT User) of a partition manager public key certificate (Cert. PM) as an SPT and a service permission ticket issuing means (SPT Ticket Issuer) R / W) The service permission ticket (SPT) issued by the service permission ticket issuing means (SPT Ticket Issuer) managed by the partition manager is a partition manager public key certificate as the service permission ticket issuing means (SPT Ticket Issuer). (Cert. PM)
With service permission ticket user (SPT User)
That is, a device that transmits a ticket to a device (ex. A reader / writer as a device access device)
Sent to.

(4) Mutual authentication between a reader / writer (R / W) as a device access device and a device A reader / writer as a device access device, which is a service permission ticket user (SPT User), issues service permission ticket issuing means (SPT). Ticket Issuer) issues a service permission ticket (SPT) issued with the target device to execute the file access,
Mutual authentication using a common key method (see FIGS. 53 and 54) is executed.

(5) Supply of Partition Manager Public Key Certificate (Cert. PM) as SPT and Service Permission Ticket Issuing Means (SPT Ticket Issuer) to Device Mutual authentication between the reader / writer (R / W) and the device is established. Then, the service permission ticket user (SPT User)
The reader / writer as a device access device is
Service permission ticket (SPT) and service permission ticket issuance means (SPT Ticket Is
suer) as a partition manager public key certificate (Cert.PM).

The device determines (1) the ticket issuer (Ticket) for the received service permission ticket (SPT).
The partition manager public key certificate (Cert.PM) as the issuer) is a valid public key certificate (CERT) that is not falsified, and (2) the partition manager public key as the ticket issuer (Ticket Issuer) The code recorded in the optional area of the certificate (Cert. PM) and the FDB (File D
e) ticket issuance code (SPTIC) recorded in the efinition Block), (3) Ticket issuance means (Ticket)
Issuer) has not been revoked, and (4) verification of the received ticket (SPT) by verifying the signature (Signature) confirms that the ticket has not been tampered with.
SPT user (reader / writer as ticket user) and ticket user (SPT Use) stored in the ticket
The verification of the SPT user (reader / writer) (see FIGS. 57 and 58) is executed by confirming that the identifiers of r) match and confirming that mutual authentication has been completed.

(6) File Access The device executes access to the file to be processed according to the rules described in the service permission ticket (SPT).

[0796] Through the above processing, file access processing in accordance with the mutual authentication (common key) and ticket (SPT) verification (public key) methods is executed.

[B5. Data Update Ticket (D
Device Update Process Using UT)] Next, a data update ticket (DUT: Data Update Tick)
The data update process of the device using et) will be described. Data Update Ticket (DUT: Data Upd)
ate Ticket) is an access control ticket applied when updating various data stored in the device. DU issued by a valid data update ticket (DUT) issuing means (Ticket Issuer)
By using T to access a device by a ticket user (ex. A reader / writer as a device access device) according to a procedure recorded in the DUT, data processing can be performed within the restrictions recorded in the DUT.

[0798] As described above, the data update ticket (DUT: Data Update Ticket) is a ticket DUT (DEV) applied to execute an update process of a data item managed by the device manager, and a partition manager management. There is a ticket DUT (PAR) (see FIG. 32) applied to execute the update process of the data item in the partition to be executed.

[0799] A process of applying a data update ticket (DUT) to data stored in a device to execute data update will be described. The flow of FIG. 93 and subsequent drawings will be described with reference to other drawings. The data update process includes a mutual authentication process (device authentication or partition authentication) between a device and a reader / writer as a device access device that executes data update, and a data update ticket (DUT: Data Update Ticket) validity verification process. Is included.

The data update processing flow shown in FIG. 93 will be described. In FIG. 93, the left side is a data updating device,
The right side shows the processing of the device (see FIG. 5). Note that the data updating device is a device (ex. A reader / writer as a device access device, a PC) that can perform data read / write processing on a device, and corresponds to the reader / writer as a device access device in FIG. First, FIG.
The outline of the data update process will be described using FIG.
Details of the data update operation included in this processing will be described with reference to the flow of FIG.

[0801] First of all, step S951 of FIG. 93 and S96
At 0, a mutual authentication process is performed between the data update device and the device. The two means for executing data transmission / reception mutually confirm whether or not the other party is a correct data communicator, and thereafter perform necessary data transfer. The process of confirming whether the other party is the correct data communicator is the mutual authentication process. A session key is generated at the time of the mutual authentication process, and encryption is performed using the generated session key as a shared key to transmit data.

The mutual authentication processing is the same processing as described in the section on partition generation and deletion processing, and either device authentication or partition authentication is executed. Either common key authentication or public key authentication processing is applied to each of them. This mutual authentication processing is the same processing as that described with reference to FIGS.

[0803] It should be noted that the process should be executed as mutual authentication process, data update ticket to apply (DUT)
(See FIG. 32) * Authentication Type: Determined by the type of mutual authentication of the device (Public key authentication, Common key authentication, or Any (Any)).

If the authentication processing has failed (S952, S9
No at 61) indicates that it is not possible to confirm that they are valid devices and devices, and the following processing is not executed and the processing ends as an error.

[0805] If the authentication process is successful, the data update device sends a data update ticket (D
UT: Data Update Ticket). The data update ticket (DUT) is a ticket issued by a data update ticket (DUT) issuing unit (DUT Issuer) under the control of the device manager or the partition manager. The data update ticket (DUT) is an access control ticket for the device, and has the data format configuration of FIG. 32 described above.

Note that the data update ticket (DU)
When transmitting T) to the ticket user, in the case of the public key method, a data update ticket (DUT)
Public key certificate (CERT_DUTI) of issuing means (DUT Issuer)
Also send it together. Public key certificate (CE
RT_DUTI) is the DKD in the device
B (PUB) (Device Key Definition Block) recorded ticket issuing means code (DUTIC_DEV) and PKDB
(PUB) The identifier (D) of the ticket issuing means code (DUTIC_PAR) recorded in (Partition Key Definition Block)
UTIC).

[0807] The device that has received the data update ticket (DUT) (S962) executes the validity check of the received ticket (DUT) and the user (S9).
63). The processing for verifying the validity of the ticket is executed by applying either MAC verification using a common key method or signature verification processing using a public key method. User check is the device that sent the ticket (ticket user)
This is a process for checking the validity of the authentication process. Mutual authentication has been established, and is executed as a process for verifying a match between the identification data of the authentication partner and the ticket user identifier (see FIG. 32) recorded in the ticket. You. These processes are
In the above description of the process of applying the partition registration ticket (PRT), the process is the same as that described with reference to FIGS.

[0808] In the device, reception ticket (DU
T) When the validity of the ticket and the user cannot be confirmed as a result of the user check processing (S9)
No. 64 is a data update ticket (DU)
T) Notify the data updating device of a reception error (S968). If the ticket and the validity of the user can be confirmed (Yes in S964), the data (see FIG. 33) stored in the memory unit in the device according to the rules described in the received data update ticket (DUT) Execute the update process. Details of this processing will be described later using another flow.

According to the description of the data update ticket (DUT), the data update processing is successful (Y in S966).
es), the DUT reception success is notified to the data updating device (S967). On the other hand, the data update process failed (S
If No in 966, a DUT reception error is notified to the data updating device (S968).

[0810] The data updating device receives the DUT reception result (S954), determines the DUT processing result, and if the DUT reception result is an error (No in S955), ends the processing as an error and terminates the DUT reception result. Succeeded (S955
If Yes, the session clear command is transmitted and received (S956, S969), the authentication table generated on the device side is discarded (S970), and the process ends. The authentication table is a table generated in the mutual authentication process of steps S951 and S960, and has the same configuration as that described in the item of the application process of the partition registration ticket (PRT), that is, the same configuration as that of FIG. .

[0811] As described above, the data stored in the device is updated using the data update ticket (DUT). Hereinafter, the data update operation (S965) included in this processing will be described with reference to FIG.

[0812] The processing flow in Fig. 94 is processing executed in the device that has received the data update ticket (DUT).
This is executed after mutual authentication with the device that transmitted T) has been established and the ticket has been successfully verified.

First, in step S971, the device searches for the version of the data to be updated from the old data code (Old Data Code) of the data update ticket (DUT) to be updated. For example, if the update target is the device manager code (DMC), the version is recorded in the device management information block (see FIG. 15). If the update target is the partition manager code (PMC), the version is recorded in the partition management information block (see FIG. 15). 20) is recorded. The version of the partition registration ticket (PRT) issuing means (PRT Issuer) is included in the device definition block (see FIG. 16). Further, the revocation list (IRL DEV, CRL DEV) includes version information in the revocation list. As described above, the storage destination of the version information is determined according to the information, and the device stores the old data code (Ol
d Data Code) to search for the version of the data to be updated.

Next, in step S972, the device updates the data recorded in the data update ticket (DUT) with the version condition [Data Versi
on Rule], it is determined whether or not the setting is [Any].

[0815] As described above, the version condition [Data Version Rule] for updating data is Any, Exact, O
There are three types of lder. Any is the version (Versio
n) Data can be updated regardless of conditions. Exact can update data when the value specified in the following [Data Version Condition] is the same. Older can update data only when New Data Version is newer. It becomes possible. If the version condition [DataVersion Rule] is Any or Older
In the case of, [Data Version Condition] is not used or ignored.

If the setting of [Data Version Rule] of the data update ticket (DUT) is not [Any], processing according to the version condition [Data Version Rule] is executed. This step is S973 to S975.

At step S973, the data update ticket (DUT) version condition [Data Version
Rule], it is determined whether or not the setting is [EXACT]. [EXACT] is [Data Version Condi
When the value is the same as the value specified in [Action], it indicates that the data can be updated. If the setting is [EXACT], in step S974, it is determined whether the version of the update target data [Old Data] matches the version value recorded in [Data Version Condition] of the data update ticket (DUT). . The process proceeds to the next step only when they match, and when they do not match, the update process is not executed and the process ends with an error.

At step S973, the version condition [Data Version R] of the data update ticket (DUT) is set.
ule] is not [EXACT], the setting is [Older]. The setting of [Older]
[New Data Versio] indicating the version of new data [New Data] of the data update ticket (DUT) from the version of the update target data [Old Data].
n] is set to update only when it is newer. In the case of this [Older] setting, in step S975, the [New Data Ver] indicating the version of the new data [New Data] of the data update ticket (DUT) from the version of the update target data [Old Data].
sion] is newer, the process proceeds to the next step only when it is newer, and when they do not match, the update process is not executed and the process ends with an error.

Next, in step S976, the device sets the data update ticket (DUT) [Encryp
ted Flag]. [Encrypted Flag] indicates whether data to be updated is encrypted (encryption: Encrypt
ed / unencrypted: none). [Encrypted
Flag] indicates that the data to be updated is non-encrypted data, the new data [New] of the data update ticket (DUT) is determined in step S977.
[Data] is replaced with the old data to be updated [Old Data] stored in the memory unit of the device, and the process ends. If a version is added to the update target data, the data update ticket (D
A process for storing the version (New Data Version) of the data to be updated stored in the UT (Data Update Ticket) in the version storage area set corresponding to the update data in the device is executed.

[0820] In step S976, the [Encrypted Flag] of the data update ticket (DUT) is read.
But the data to be updated is encrypted (encryption: Enc
rypted), in step S978, the data update ticket (D
Verify [Ticket Type] of (UT). [Ticket Type]
Is the type of ticket (Ticket) (DUT (DEV) / D
UT (PAR)). DUT (DE
V) indicates that the data update ticket (DUT) is a ticket for executing the update processing of the data item managed by the device manager, and the DUT (PAR)
This indicates that the ticket is applied to execute an update process of a data item in a partition managed by the partition manager.

[0821] If the ticket type [Ticket Type] is DU
If T (DEV) is indicated, steps S979 to S979
Execute 982 and show DUT (PAR),
Steps S983 to S986 are executed.

[0822] If the ticket type [Ticket Type] is DU,
If T (DEV) is indicated, in step S979, the data update ticket (DUT (DEV)
The data indicated by the Old Data Code (code of old data to be updated) described in (V)) is stored in the device key area (FIG.
Kdut_DEV1 (data verification ticket (DUT) MAC verification key) or Kdut_DEV
2 (data update encryption key).

[0823] The data update ticket (DUT (D
EV)), the data indicated by the Old Data Code (code of the old data to be updated) described in the device key area (FIG. 1).
8), Kdut_DEV2 (key for verifying the MAC of the data update ticket (DUT)), Kdut_DEV2
If it is (the data update encryption key), the process proceeds to step S98.
0, the device key area of the device (see FIG. 18)
Data update ticket (DUT (DEV)) using Kdut_DEV4 (encryption key for data update) stored in
KDEV_DEV as new data [New Data] stored in
1. Decrypt Kdut_DEV2 and overwrite Kdut_DEV1 and Kdut_DEV2 stored in the device key area of the device. The version (New Data Ver.) Of the data to be updated stored in the data update ticket (DUT (DEV))
is stored in the version storage area set in correspondence with the update data in the device, in this case, the device key area of the device (see FIG. 18).

Next, in step S981, Kdut_D stored in the device key area of the device (see FIG. 18)
EV1 (MAC of Data Update Ticket (DUT)
A swap between the verification key) and Kdut_DEV3 (a MAC key for the data update ticket (DUT)), that is, a replacement process is performed, and Kdut_DEV2 (a data update encryption key) and Kdut_DEV4 (a data update encryption key) are performed. , That is, a swap process, and the process ends.

[0825] By swapping Kdut_DEV1 and Kdut_DEV3 and swapping Kdut_DEV2 and Kdut_DEV4, Kdut_DEV3 (MAC key for data update ticket (DUT)) and Kdut_DEV4 (encryption key for data update) are always processed. pair Kdut_DEV1 (MAC verification key of the data update ticket (DUT)), Kdut_DEV2
(Data update encryption key) pair is maintained at a newer version, and the rewrite target is always Kdut_DEV1, Kdut
The processing set as dut_DEV2 becomes possible.

[0827] In step S979, the data indicated by the Old Data Code (the code of the old data to be updated) described in the data update ticket (DUT (DEV)) is stored in the device key area (see Fig. 18). Kdut_DEV1 (Data update ticket (DUT)
If it is not Kdut_DEV2 (data update encryption key), then in step S982, Kdut_D stored in the device key area of the device (see FIG. 18).
The new data [New Data] stored in the data update ticket (DUT (DEV)) is decrypted using EV2 (data update encryption key), and the old data code (update) of the data update ticket (DUT (DEV)) is updated. Overwriting the area indicated by the old data code). If a version is added to the update target data, the data update ticket (DUT (DE
V)), a process of storing the version of the data to be updated (New Data Version) stored in the version storage area set corresponding to the update data in the device is executed.

[0827] On the other hand, if the ticket type [Ticket Type] indicates DUT (PAR) in step S978, steps S983 to S986 are executed.

[0827] If the ticket type [Ticket Type] is DU
If T (PAR) is indicated, in step S983, the data update ticket (DUT (PA
R)) indicates Kdut_PAR1 (the MAC key of the data update ticket (DUT)) stored in the partition key area (see FIG. 23) or the data indicated by the Old Data Code (the code of the old data to be updated) described in ,
It is determined whether or not it is Kdut_PAR2 (data update encryption key).

[0827] The data update ticket (DUT (P
AR)), Kdut_PAR1 (MAC key of the data update ticket (DUT)) stored in the partition key area (see FIG. 23) of the data indicated by the Old Data Code (code of the old data to be updated), Kdut_P
If it is AR2 (encryption key for data update), step S
In 984, a data update ticket (DUT) is created using Kdut_PAR4 (encryption key for data update) stored in the partition key area (see FIG. 23) of the device.
(PAR)), and decrypts Kdut_PAR1 and Kdut_PAR2 as new data [New Data], and overwrites Kdut_PAR1 and Kdut_PAR2 stored in the partition key area of the device. The data update ticket (DUT
(PAR)), the version (New Data Version) of the data to be updated is stored in the version storage area set corresponding to the update data in the device, in this case, the partition key area of the device (FIG. 23). reference)
Is also executed.

Next, in step S985, the data stored in the partition key area (see FIG. 23) of the device is read.
Swap between Kdut_PAR1 (MAC key for data update ticket (DUT)) and Kdut_PAR3 (MAC key for data update ticket (DUT))
That is, the exchange process is performed, and swap between Kdut_PAR2 (data update encryption key) and Kdut_PAR4 (data update encryption key), that is, the exchange process is performed, and the process ends.

[0831] By swapping Kdut_PAR1 and Kdut_PAR3, and swapping Kdut_PARV2 and Kdut_PAR4, Kdut_PAR3 (MAC key for data update ticket (DUT) MAC verification) and Kdut_PAR4 (encryption key for data update) are always used. Is a pair of Kdut_PAR1 (data update ticket (DUT) MAC verification key), Kdut_PAR
Kdut_PAR is maintained at a newer version than pair 2 (encryption key for data update).
1. The processing set as Kdut_PAR2 becomes possible.

[0832] In step S983, data indicated by Old Data Code (code of old data to be updated) described in the data update ticket (DUT (PAR)) is stored in the device key area (see Fig. 18). Kdut_DEV1 (Data update ticket (DUT)
If it is not Kdut_DEV2 (data update encryption key), it is stored in the partition key area of the device (see FIG. 23) in step S986.
The new data [NewData] stored in the data update ticket (DUT (PAR)) is decrypted using Kdut_PAR2 (data update encryption key), and the Old DataCode (updated) of the data update ticket (DUT (PAR)) is decrypted. Overwrite the area indicated by the old data code).
If a version is added to the data to be updated, the data update ticket (DUT (PUT
AR)), the version of the data to be updated (New Data Version) is stored in the version storage area set corresponding to the update data in the device.

The above processing is a data update operation based on a data hop date ticket executed in the device.

As understood from the flow described above, Kdut_DEV1 (a key for verifying the MAC of the data update ticket (DUT)) in which the data to be updated is stored in the device key area Kdut_DEV2 (an encryption key for data update) or a partition key If Kdut_PAR1 (data update ticket (DUT) MAC verification key) Kdut_PAR2 (data update encryption key) stored in the area, a process different from other update processes is executed.

[0832] These Kdut_DEV1 (the MAC key of the data update ticket (DUT)), Kdut_DEV2
(Data update encryption key), Kdut_PAR1 (Data update ticket (DUT) MAC verification key), Kdut_PAR
FIG. 95 shows a brief summary of the update process for 2 (data update encryption key), and the process will be described. Description will be made in the order of (1) to (3) in FIG. The processing is
Since Kdut_DEV1,2 is the same as Kdut_PAR1,2, a case where Kdut_DEV1,2 is updated will be described.

(1) Data Update Ticket (DU)
Kdut_D as new data [New Data] to be stored in T)
After EV1 and Kdut_DEV2 are encrypted using Kdut_DEV4 (data update encryption key) stored in the device key area (see FIG. 18) of the device, the data update ticket (D
UT) and a data update ticket (DU)
T) to the device. At this time, Kdut_DEV1, Kdu
Ticket issuers who can update t_DEV2 are Kdut_DEV3, Kdut_
You have to know DEV4.

(2) Data Update Ticket (DU)
The device receiving T) decrypts Kdut_DEV1 and Kdut_DEV2 as new data [New Data] stored in the data update ticket (DUT) using Kdut_DEV4 (data update encryption key) stored in the device key area of the device. Kdut_DEV stored in the device key area of the device
1. Overwrite Kdut_DEV2.

(3) Next, the device stores the Kdut_DEV newly stored in the device key area (see FIG. 18) of the device.
1 (the MAC verification key of the data update ticket (DUT)) and the previously stored Kdut_DEV3 (the MAC verification key of the data update ticket (DUT)) are swapped, that is, replaced. Further, the newly stored Kdut_DEV2 (data update encryption key) is swapped with the previously stored Kdut_DEV4 (data update encryption key), that is, swap processing is performed.

[0839] This swap processing between Kdut_DEV1 and Kdut_DEV3 and swap processing between Kdut_DEV2 and Kdut_DEV4 always causes Kdut_DEV3 (a key for MAC verification of a data update ticket (DUT)) and Kdut_DEV4 (an encryption key for data update). The pair is Kdut_DEV1 (MAC key for data update ticket (DUT) MAC), Kdut_DEV2
It is maintained at a newer version than the (data update encryption key) pair. In other words, Kdut_DEV1 and Kdut_DEV2
Keys are always used keys, Kdut_DEV3 and Kdut_DEV4
Updates the Kdut_DEV1 and Kdut_DEV2 in an emergency, and has a role as a backup key that is replaced with the currently used Kdut_DEV1 and Kdut_DEV2 keys.

[0840] It should be noted, Kdut_DEV1 (MAC verification key of the data update ticket (DUT)), Kdut_DEV2 (encryption key for data update) is used as a pair, also, Kdut
_DEV3 (MA of data update ticket (DUT)
The C verification key) and Kdut_DEV4 (data update encryption key) are also used as a pair.

The present invention has been described in detail with reference to the specific embodiments. However, it is obvious that those skilled in the art can modify or substitute the embodiment without departing from the spirit of the present invention. That is, the present invention has been disclosed by way of example, and should not be construed as limiting. In order to determine the gist of the present invention, the claims described at the beginning should be considered.

[0832] The series of processes described in the specification can be executed by hardware, software, or a combination of both. When processing by software is performed, the program recording the processing sequence is installed in a memory in a computer built in dedicated hardware and executed, or the program is stored in a general-purpose computer capable of executing various processing. It can be installed and run.

For example, the program can be recorded in a hard disk or a ROM (Read Only Memory) as a recording medium in advance. Alternatively, the program is a floppy disk, CD-ROM (Compact Disc Read Only Me
mory), MO (Magneto optical) disk, DVD (Digit
al Versatile Disc), a magnetic disk, a semiconductor memory, etc., can be temporarily or permanently stored (recorded) in a removable recording medium. Such a removable recording medium can be provided as so-called package software.

[0844] The program can be installed in the computer from the above-described removable recording medium, or can be wirelessly transferred from a download site to the computer, or connected to the computer via a network such as a LAN (Local Area Network) or the Internet. The computer can receive the transferred program and install it on a recording medium such as a built-in hard disk.

[0845] The various processes described in the specification are as follows.
It may be executed not only in chronological order according to the description, but also in parallel or individually according to the processing capability of the device that executes the process or as necessary. Also, in this specification, a system is a logical set configuration of a plurality of devices,
The devices of each configuration are not limited to those in the same housing.

[0846]

As described above, according to the data access control system, the memory mounted device, the data access control method, and the program storage medium of the present invention,
The memory-equipped device receives the access control ticket from the access device, and conditioned upon establishment of authentication based on the authentication rule described in the access control ticket and confirmation of the identification data of the access device described in the access control ticket. Since data access is allowed, various authentication modes and ticket modes can be set for each access, and access management with a security level set according to memory access processing is realized.

Further, according to the data access control system, the memory mounted device, the data access control method, and the program storage medium of the present invention, the category or identifier of the ticket issuing means and the use means is stored in the access control ticket. Since the device can be verified, access control at a high security level can be performed.

Further, according to the data access control system, the memory mounted device, the data access control method, and the program storage medium of the present invention, various types of access to the memory area divided into a plurality of partitions can be performed. An access control ticket is issued under the management of each device or partition management entity, and processing based on the rules described in each ticket can be executed in the memory-equipped device, enabling an independent management configuration of data in each partition. Is achieved.

[Brief description of the drawings]

FIG. 1 is a system configuration schematic diagram (part 1) for explaining the outline of the system configuration of the present invention.

FIG. 2 is a system configuration schematic diagram (part 2) for explaining the outline of the system configuration of the present invention.

FIG. 3 is a system configuration schematic diagram (part 3) for explaining a specific example of the system configuration of the present invention;

FIG. 4 is a diagram illustrating a relationship between an access control ticket issuing unit and a use unit in the system of the present invention.

FIG. 5 is a diagram showing a device configuration having a memory unit in the system of the present invention.

FIG. 6 is a diagram showing a memory format of the device of the present invention.

FIG. 7 is a diagram showing a device manager configuration in the system of the present invention.

FIG. 8 is a diagram showing a configuration of control means of a device manager in the system of the present invention.

FIG. 9 is a diagram showing a partition manager configuration in the system of the present invention.

FIG. 10 shows a reader / writer (R) in the system of the present invention.
/ W) is a diagram showing a configuration.

FIG. 11 is a diagram illustrating a format of a public key certificate that can be used in the system of the present invention.

FIG. 12 is a diagram showing a flow of a public key signature generation process that can be used in the system of the present invention.

FIG. 13 is a diagram showing a flow of a public key signature verification process usable in the system of the present invention.

FIG. 14 is a diagram showing a data configuration of a manufacturing information block in data stored in a memory unit in the device of the present invention.

FIG. 15 is a diagram showing a data configuration of a device management information block in data stored in a memory unit in the device of the present invention.

FIG. 16 is a diagram showing a data configuration of a public key device key definition block in data stored in a memory unit in the device of the present invention.

FIG. 17 is a diagram showing a data configuration of a common key device key definition block in data stored in a memory unit in the device of the present invention.

FIG. 18 is a diagram showing a data configuration of a device key area in data stored in a memory unit in the device of the present invention.

FIG. 19 is a diagram showing a data configuration of a partition definition block in data stored in a memory unit in the device of the present invention.

FIG. 20 is a diagram showing a data configuration of a partition management information block in data stored in a memory unit in the device of the present invention.

FIG. 21 is a diagram showing a data configuration of a public key system partition key definition block in data stored in a memory unit in the device of the present invention.

FIG. 22 is a diagram showing a data configuration of a common key system partition key definition block in data stored in a memory unit in the device of the present invention.

FIG. 23 is a diagram showing a data configuration of a partition key area in data stored in a memory unit in the device of the present invention.

FIG. 24 is a diagram showing a data configuration of a file definition block in data stored in a memory unit in the device of the present invention.

FIG. 25 is a diagram illustrating a type of a file structure in data stored in a memory unit in the device of the present invention.

FIG. 26 is a diagram showing a format of a partition registration ticket (PRT) as an access control ticket applied in the system of the present invention.

FIG. 27 shows a file registration ticket (FR) as an access control ticket applied in the system of the present invention.
It is a figure which shows the format of T).

FIG. 28 shows a service permission ticket (SP) as an access control ticket applied in the system of the present invention.
FIG. 9 is a diagram showing a format (Example 1) of T).

FIG. 29 shows a service permission ticket (SP) as an access control ticket applied in the system of the present invention.
It is a figure explaining the type of file access mode using T).

FIG. 30 shows a service permission ticket (SP) as an access control ticket applied in the system of the present invention.
FIG. 4 is a diagram illustrating a file structure to be accessed using T).

FIG. 31 shows a service permission ticket (SP) as an access control ticket applied in the system of the present invention.
FIG. 9 is a diagram showing a format (Example 2) of T).

FIG. 32 is a diagram showing a format of a data update ticket (DUT) as an access control ticket applied in the system of the present invention.

FIG. 33 is a diagram illustrating data to be updated using a data update ticket (DUT) as an access control ticket applied in the system of the present invention.

FIG. 34 is a diagram illustrating an outline of processing up to device use in the system of the present invention.

FIG. 35 is a diagram showing a device initial registration processing flow by a device manufacturing entity in the system of the present invention.

FIG. 36 is a diagram showing a device registration processing flow (part 1) by the device manager in the system of the present invention.

FIG. 37 is a diagram showing a device registration process flow (part 2) by the device manager in the system of the present invention.

FIG. 38 is a diagram showing a device registration process flow (part 3) by the device manager in the system of the present invention.

FIG. 39 is a diagram showing a device registration process flow (part 4) by the device manager in the system of the present invention.

FIG. 40 is a diagram showing a device registration process flow (part 5) by the device manager in the system of the present invention.

FIG. 41 is a diagram illustrating data stored in a device after device initial registration processing by a device manager in the system of the present invention.

FIG. 42 is a diagram showing a public key certificate issuance processing flow (part 1) by the device manager in the system of the present invention.

FIG. 43 is a diagram showing a public key certificate issuance processing flow (part 2) by the device manager in the system of the present invention.

FIG. 44 is a diagram illustrating a public key certificate issuing process by a device manager in the system of the present invention.

FIG. 45 is a diagram illustrating a public key certificate issuing process by a device manager in the system of the present invention.

FIG. 46 is a diagram illustrating data stored in a device after a public key certificate issuance process by a device manager in the system of the present invention.

FIG. 47 is a diagram showing a flow of a partition creation / deletion process for a device in the system of the present invention.

FIG. 48 is a flowchart (part 1) for explaining a mutual authentication process with a device in the system of the present invention;

FIG. 49 is a flowchart (part 2) for describing a mutual authentication process with a device (device authentication) in the system of the present invention.

FIG. 50 is a diagram illustrating a mutual authentication process with a device in a public key system in the system of the present invention.

FIG. 51 is a diagram illustrating the configuration of an authentication table generated in a device after mutual authentication processing with a device in the system of the present invention.

FIG. 52 is a diagram illustrating a configuration of an authentication table generated in a reader / writer after a mutual authentication process with a device in the system of the present invention.

FIG. 53 is a diagram illustrating a mutual authentication process using a common key method with a device in the system of the present invention.

FIG. 54 is a diagram illustrating a mutual authentication process using a common key method with a device in the system of the present invention.

FIG. 55 is a flowchart (part 3) for explaining the mutual authentication processing (partition authentication) with a device in the system of the present invention.

FIG. 56 is a flowchart (part 4) for explaining the mutual authentication process (partition authentication) with a device in the system of the present invention.

FIG. 57 is a flowchart (part 1) illustrating a ticket validity and user check process in the system of the present invention.

FIG. 58 is a flowchart (part 2) for explaining the validity of a ticket and the user check process in the system of the present invention.

FIG. 59 is a flowchart (part 1) for explaining a MAC generation method applicable to the validity of a ticket in the system of the present invention.

FIG. 60 is a flowchart (part 1) for describing partition creation and deletion operations in the system of the present invention.

FIG. 61 is a flowchart (part 2) for describing partition creation and deletion operations in the system of the present invention.

FIG. 62 is a flowchart (part 1) for describing an initial partition registration process in the system of the present invention;

FIG. 63 is a flowchart (part 2) for describing the partition initial registration process in the system of the present invention;

FIG. 64 is a flowchart (part 3) for describing the partition initial registration process in the system of the present invention;

FIG. 65 is a diagram for describing device storage data after a partition initial registration process in the system of the present invention.

FIG. 66 is a view for explaining a public key certificate issuance process by the partition manager in the system of the present invention (part 1);

FIG. 67 is a view for explaining a public key certificate issuance process by the partition manager in the system of the present invention (part 2).

FIG. 68 is a diagram illustrating processing in a case where public key authentication and public key ticket verification are executed in partition generation processing by the partition manager in the system of the present invention.

FIG. 69 is a diagram for describing processing when public key authentication and common key ticket verification are executed in partition generation processing by the partition manager in the system of the present invention.

FIG. 70 is a diagram for explaining processing in a case where a common key scheme authentication and a common key scheme ticket verification are executed in the partition generation processing by the partition manager in the system of the present invention.

FIG. 71 is a view for explaining processing in a case where common key authentication and public key ticket verification are executed in partition generation processing by the partition manager in the system of the present invention.

FIG. 72 is a flowchart illustrating a file generation / erasure process using a file registration ticket (FRT) in the system of the present invention.

FIG. 73 is a flowchart illustrating a file generation / deletion operation using a file registration ticket (FRT) in the system of the present invention.

FIG. 74 is a diagram illustrating device storage data after file generation using a file registration ticket (FRT) in the system of the present invention.

FIG. 75 is a view for explaining processing in a case where public key system authentication and public key system ticket verification are executed in a file generation process using a file registration ticket (FRT) in the system of the present invention.

FIG. 76 is a view for explaining processing when public key authentication and common key ticket verification are executed in a file generation process using a file registration ticket (FRT) in the system of the present invention.

FIG. 77 is a view for explaining processing in a case where common key system authentication and common key system ticket verification are executed in a file generation process using a file registration ticket (FRT) in the system of the present invention.

FIG. 78 is a view for explaining processing in a case where a common key scheme authentication and a public key scheme ticket verification are executed in a file creation processing using a file registration ticket (FRT) in the system of the present invention.

FIG. 79 is a diagram showing a file access processing flow to which a service permission ticket (SPT) is applied in the system of the present invention.

FIG. 80 is a diagram showing a file open operation flow to which a service permission ticket (SPT) is applied in the system of the present invention.

FIG. 81 is a diagram (example 1) illustrating a file open table configuration generated by a file open operation using a service permission ticket (SPT) in the system of the present invention.

FIG. 82 is a diagram (example 2) illustrating a file open table configuration generated by a file open operation using a service permission ticket (SPT) in the system of the present invention.

FIG. 83 is a diagram (example 1) illustrating an example of a file access process using a service permission ticket (SPT) in the system of the present invention.

FIG. 84 is a diagram (example 2) illustrating an example of a file access process to which a service permission ticket (SPT) is applied in the system of the present invention.

FIG. 85 is a diagram illustrating handling of a session key generated by authentication in the system of the present invention.

FIG. 86 is a flowchart (example 1) illustrating an example of file access processing using a service permission ticket (SPT) in the system of the present invention.

FIG. 87 is a flowchart (example 2) illustrating an example of a file access process using a service permission ticket (SPT) in the system of the present invention.

FIG. 88 is a diagram for explaining an example of access processing of a compound file to which a service permission ticket (SPT) is applied in the system of the present invention.

FIG. 89 illustrates a file access process using a service permission ticket (SPT) in the system of the present invention.
FIG. 9 is a diagram illustrating processing when public key authentication and public key ticket verification are executed.

FIG. 90 illustrates a public key authentication, a process using a service permission ticket (SPT) in the system of the present invention.
FIG. 9 is a diagram for describing processing when a common key type ticket verification is executed.

FIG. 91 is a flowchart illustrating processing performed by a service permission ticket (SPT) in the system of the present invention.
FIG. 9 is a diagram for describing processing when a common key type ticket verification is executed.

FIG. 92 is a flowchart illustrating processing using a service permission ticket (SPT) in the system of the present invention.
FIG. 11 is a diagram illustrating processing when public key ticket verification is performed.

FIG. 93 is a diagram showing a data update processing flow using a data update ticket (DUT) in the system of the present invention.

FIG. 94 is a diagram showing a data update operation flow using a data update ticket (DUT) in the system of the present invention.

FIG. 95 is a diagram illustrating an example of data update processing using a data update ticket (DUT) in the system of the present invention.

FIG. 96 is a diagram showing a conventional memory structure.

FIG. 97 is a diagram illustrating a conventional relationship between a memory manager and a user.

FIG. 98 is a diagram illustrating a conventional memory area securing process.

FIG. 99 is a diagram illustrating a conventional memory access method.

[Explanation of symbols]

REFERENCE SIGNS LIST 100 device 200 device manager 300 partition manager 400 code management agency 500 device manufacturing entity 210 partition registration ticket (PRT) issuing means 220 registration authority (RA) 310 file registration ticket (FRT) issuing means 320 service permission ticket (SPT) issuing means 330 Registration Authority (RA) 610,620 Certificate Authority (CA) 711-714 Reader / Writer (R / W) 721-722 Ticket User 101 CPU 102 Communication IF 103 ROM 104 RAM 105 Cryptographic Processing Unit 106 Memory Unit (EEPROM) 211,221 Control means 212, 222 Database 2111 Control unit 2112 ROM 2113 RAM 2114 Display unit 2115 Input unit 2116 HDD 2117 Dry 2118 Communication I / F 311, 321, 331 Control means 312, 322, 332 Database 701 CPU 702 Communication IF 703 ROM 704 RAM 705 Encryption processing unit 706 Memory unit (EEPROM)

──────────────────────────────────────────────────続 き Continued on the front page (51) Int.Cl. ⁷ Identification symbol FI Theme coat ゛ (Reference) G06K 17/00 G06K 19/00 R H04L 9/32 H04L 9/00 675A 675B (72) Inventor Taizo Shirai 6-35 Kita Shinagawa, Shinagawa-ku, Tokyo Sonny Corporation (72) Inventor Masayuki Takada 6-35 Kita Shinagawa, Shinagawa-ku, Tokyo Sonny Corporation F-term (reference) 5B017 AA07 BA06 BA07 CA14 5B035 AA13 BB09 CA11 CA38 5B058 CA27 KA02 KA04 KA08 KA31 KA33 KA35 YA20 5B085 AE09 AE12 AE23 AE29 CC01 5J104 AA07 KA02 NA38

Claims (22)

[Claims] 1. A data access control system for issuing a command from an access device to a memory-equipped device having a memory unit capable of storing data to execute processing on data stored in the memory unit. The mounted device receives, from the access device, an access control ticket configured as access control data for data stored in the memory unit, and establishes authentication based on the authentication rule described in the access control ticket; and data access control system, characterized in that the configuration allowing data access, subject to confirmation of the identification data of the access device described in the access control ticket. 2. The access control ticket describes an authentication type as authentication method designation information indicating that any one or both of a public key authentication method and a common key authentication method is allowed as the authentication method. 2. The data access control system according to claim 1, wherein the data access control system is configured to execute an authentication process according to an authentication type described in an access control ticket received from the access device. 3. 3. The access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. Claims are characterized in that, based on the category or identifier of the issuing means, a confirmation process is performed to confirm that the ticket is a ticket issued by a valid issuing means, and data access is permitted on condition of the confirmation. Item 2. The data access control system according to item 1. 4. The access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. Based on a comparison between the category or identifier of the issuing unit and the user information stored in the public key certificate of the issuing unit of the access control ticket, a process of confirming that the ticket is issued by a valid issuing unit is performed. The data access control system according to claim 1, wherein the data access control system is configured to execute the data access on condition of the confirmation. 5. The access control ticket stores a category or an identifier of an access device that is a use unit of the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. A configuration in which, based on a category or an identifier of an access device that is a use unit of an access control ticket, a process of confirming that the ticket is a ticket provided by a valid use unit is performed, and data access is permitted on condition of the confirmation. 2. The data access control system according to claim 1, wherein: 6. The access control ticket stores a category or an identifier of a use means of the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. The ticket is a ticket provided by a valid user based on a comparison between the category or identifier of the access device as the user and the user information stored in the public key certificate of the user of the access control ticket. 2. A configuration for executing a confirmation process of the fact that data access is permitted on condition of the confirmation.
A data access control system according to claim 1. 7. The memory unit of the memory-equipped device has one or more partition areas each as a memory area managed by a corresponding partition manager, and the memory-equipped device is in a session with the access device. 2. The authentication method according to claim 1, further comprising the step of generating an authentication table in which the public key system authentication information and the session key acquired by the partition authentication or the device authentication executed in the first step or the common key system authentication information and the session key are associated. A data access control system as described. 8. A memory-equipped device having a memory unit capable of storing data, comprising control means for issuing a command from an access device to execute processing on data stored in said memory unit, wherein said control means Receiving an access control ticket configured as access control data for data stored in the memory unit from the access device, establishing authentication based on an authentication rule described in the access control ticket, and performing the access control. A memory-equipped device characterized in that data access is permitted on condition that identification data of an access device described in a ticket is confirmed. 9. The access control ticket describes an authentication type as authentication method designation information indicating that any one of or both a public key authentication method and a common key authentication method is allowed as an authentication method. 9. The memory-mounted device according to claim 8, wherein an authentication process is executed in accordance with an authentication type described in an access control ticket received from the access device. 10. The access control ticket stores a category or an identifier of an access control ticket issuing unit, and the control unit issues the access control ticket described in the access control ticket received from the access device. Based on the category or identifier of the means, execute confirmation processing that the ticket is a ticket issued by a valid issuing means,
9. The memory-mounted device according to claim 8, wherein a data access is allowed under the condition of the confirmation. 11. The access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the control means issues the access control ticket described in the access control ticket received from the access device. Executes a process of confirming that the ticket is issued by a valid issuing unit based on a comparison between the category or identifier of the unit and the user information stored in the public key certificate of the issuing unit of the access control ticket. 9. The memory-mounted device according to claim 8, wherein a data access is permitted under the condition of the confirmation. 12. The access control ticket stores a category or an identifier of an access device that is a use unit of the access control ticket, and the control unit stores the access control ticket described in the access control ticket received from the access device. Based on the category or identifier of the access device that is the control ticket usage means, a confirmation process is performed to confirm that the ticket is a ticket provided by a valid usage means, and data access is permitted on condition of the confirmation. The memory-mounted device according to claim 8, wherein: 13. The access control ticket stores a category or an identifier of a use unit of the access control ticket, and the control unit uses the access control ticket described in the access control ticket received from the access device. The ticket is a ticket provided by a valid user based on a comparison between the category or identifier of the access device as the device and the user information stored in the public key certificate of the user using the access control ticket. 9. The memory-mounted device according to claim 8, wherein the device is configured to execute a confirmation process of (1) and permit data access on condition of the confirmation. 14. The memory unit of the memory-equipped device has one or more partition areas each as a memory area managed by a corresponding partition manager, and the control unit executes a session during a session with the access device. 9. The apparatus according to claim 8, further comprising: generating an authentication table in which the public key scheme authentication information and the session key acquired by the executed partition authentication or the device authentication or the common key scheme authentication information and the session key are associated with each other. Device with memory. 15. A data access control method for issuing a command from an access device to a memory-equipped device having a memory unit capable of storing data and executing a process on data stored in the memory unit. The mounted device receives, from the access device, an access control ticket configured as access control data for data stored in the memory unit, and establishes authentication based on the authentication rule described in the access control ticket; and A data access control method, wherein data access is permitted on condition that the identification data of the access device described in the access control ticket is confirmed. 16. The access control ticket describes an authentication type as authentication method designation information indicating that any one or both of a public key authentication method and a common key authentication method is allowed as the authentication method. 16. The data access control method according to claim 15, wherein the device performs an authentication process according to an authentication type described in an access control ticket received from the access device. 17. The access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. 16. The method according to claim 15, wherein a confirmation process is performed to confirm that the ticket is a ticket issued by a valid issuing unit based on a category or an identifier of the issuing unit, and data access is permitted on condition of the confirmation. Data access control method as described. 18. The access control ticket stores a category or an identifier of a means for issuing the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. Based on a comparison between the category or identifier of the issuing unit and the user information stored in the public key certificate of the issuing unit of the access control ticket, a process of confirming that the ticket is issued by a valid issuing unit is performed. 16. The data access control method according to claim 15, wherein the method is executed, and data access is permitted on condition of the confirmation. 19. The access control ticket stores a category or an identifier of an access device which is a means for using the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. Based on the category or identifier of the access device that is a means of using the access control ticket, execute confirmation processing that the ticket is a ticket provided by a valid use means, and permit data access on condition of the confirmation. The data access control method according to claim 15, wherein: 20. The access control ticket stores a category or an identifier of a use means of the access control ticket, and the memory-equipped device stores the access control ticket described in the access control ticket received from the access device. The ticket is a ticket provided by a valid user based on a comparison between the category or identifier of the access device as the user and the user information stored in the public key certificate of the user of the access control ticket. run the confirmation processing that the data access control method according to claim 15, characterized in that to allow data access condition the confirmation. 21. The memory section of the memory-equipped device has one or more partition areas each as a memory area managed by a corresponding partition manager, and the memory-equipped device is in a session with the access device. 16. The data according to claim 15, wherein an authentication table is generated in which the public key scheme authentication information and the session key acquired by the partition authentication or the device authentication executed in advance, or the common key scheme authentication information and the session key are associated with each other. Access control method. 22. A computer program for issuing a command from an access device in a memory-equipped device having a memory part capable of storing data and causing a computer system to execute processing on data stored in the memory part. A program storage medium, the computer program comprising: receiving, from the access device, an access control ticket configured as access control data for data stored in the memory unit; A step of permitting data access on condition that the authentication based on the authentication rule is established and that the identification data of the access device described in the access control ticket is confirmed.